AI로 사실과 의견 구분을 맡길 때 나중에 재현하려면 남겨야 할 정보

AI에게 사실과 의견을 나누게 할 때 결과 문장만 저장하면 나중에 같은 결론에 도달하기 어렵습니다. 원문과 판단 기준, 실행 조건, 근거, 사람의 최종 판단을 함께 남겨야 결과를 재현하고 오류를 고칠 수 있습니다.

사실과 의견을 나누는 판정 단위

사실은 외부 자료나 관찰 기록으로 참과 거짓을 확인할 수 있는 주장입니다. 의견은 선호, 평가, 해석, 예측처럼 같은 자료를 보고도 판단 기준에 따라 달라질 수 있는 표현입니다.

AI에게 “사실인가요?”라고만 묻기보다 문장을 더 작은 주장 단위로 나누는 것이 좋습니다. 한 문장 안에 확인 가능한 정보와 작성자의 평가가 섞여 있으면 AI가 전체를 사실 또는 의견 중 하나로 밀어 넣을 가능성이 커집니다.

판정표에는 사실, 의견만 두지 말고 보류 상태도 두는 편이 안전합니다. 근거가 없거나 자료끼리 충돌할 때 억지로 이분법을 적용하면, 의견을 사실처럼 저장하거나 사실을 단순한 견해로 낮추게 됩니다.

판정 기준은 짧고 관찰 가능하게 작성해야 합니다. “객관적인 문장은 사실”보다 “원문에서 확인할 수 있고 인용 위치를 지정할 수 있으면 사실 후보”처럼 쓰면 사람도 AI도 같은 기준을 적용하기 쉽습니다.

AI 판정을 재현하는 실행 맥락

같은 입력을 다시 넣는 것만으로는 충분하지 않습니다. 모델 스냅샷은 특정 시점에 고정된 모델 버전이라는 뜻인데, 스냅샷이 바뀌면 같은 지시문도 다르게 해석될 수 있으므로 가능한 경우 고정 버전을 기록해야 합니다.

고정 버전을 쓰기 어려운 서비스라면 모델 이름만 남기지 말고 실행 시점의 모델 식별자와 사용한 서비스 경로를 함께 보관합니다. 결과가 달라졌을 때 모델이 바뀐 것인지, 프롬프트가 수정된 것인지, 연결된 자료가 달라진 것인지 분리해서 확인할 수 있어야 합니다.

프롬프트를 파일이나 관리 화면에서 불러왔다면 템플릿 ID, 변수값, 버전을 기록합니다. 대화창에 직접 입력한 경우에도 시스템 지시, 개발자 지시, 사용자 입력, 예시 문장을 각각 보존해야 하며, 나중에 읽기 좋게 다듬은 문안을 원본처럼 덮어쓰지 않아야 합니다.

웹 검색, 파일 검색, 함수 호출처럼 외부 도구를 연결했다면 도구의 이름과 실행 결과도 판정 기록에 묶어야 합니다. 검색어만 남기면 어떤 페이지가 반환됐는지 알 수 없고, 파일 검색이라면 당시 색인된 문서와 현재 문서가 달라졌을 때 같은 결과를 재현하기 어렵습니다.

응답의 상태, 원문 출력, 사용량 정보도 보관 대상입니다. 특히 후처리 과정에서 문장을 수정했다면 AI가 처음 낸 출력과 사람이 편집한 최종본을 별도 필드로 나눠야 어느 단계에서 사실과 의견의 경계가 바뀌었는지 추적할 수 있습니다.

API를 사용하는 환경에서는 서버가 돌려준 x-request-id와 호출자가 지정한 X-Client-Request-Id를 함께 기록하면 장애나 중복 실행을 찾기 쉽습니다. 요청 ID는 내용 자체를 재현해 주지는 않지만, 어떤 호출이 해당 결과를 만들었는지 연결하는 고리 역할을 합니다.

사실과 의견 판정표를 설계하는 방법

판정표의 한 행에는 하나의 주장만 넣는 것이 좋습니다. 주장, 분류, 근거, 판단 이유, 보류 사유를 나누면 나중에 특정 문장만 다시 검토할 수 있고, 한 문장의 일부가 잘못 분류된 경우에도 전체 기록을 폐기하지 않아도 됩니다.

사실 판정에는 “근거가 있는가”와 “근거가 주장을 직접 뒷받침하는가”를 구분해 넣습니다. 자료가 존재한다는 이유만으로 그 자료가 해당 결론을 증명하는 것은 아니므로, 근거의 존재와 근거의 적합성을 따로 확인해야 합니다.

의견 판정에는 누가 어떤 기준으로 평가했는지가 중요합니다. “효율적이다”, “위험하다”, “좋은 선택이다” 같은 표현은 사실처럼 보일 수 있으므로 평가 주체, 비교 기준, 적용 범위를 함께 적어야 합니다.

인과관계나 의도에 관한 문장은 더 조심해야 합니다. 사건이 앞뒤로 이어졌다는 사실과 앞선 사건이 뒤의 원인이라는 주장은 다르므로, AI에게 시간 순서와 인과 근거를 별도로 출력하게 하는 편이 낫습니다.

AI의 답변을 평가할 때는 문체와 내용 기준을 미리 정합니다. 평가 또는 eval은 이런 기준으로 테스트 입력을 실행하고 결과를 분석한 뒤 프롬프트를 개선하는 방식이므로, 좋은 답변 하나를 보고 시스템 전체가 안정적이라고 판단하지 않도록 도와줍니다.

테스트 입력은 실제 업무에서 자주 틀리는 사례를 포함해야 합니다. 사실과 의견이 섞인 문장, 근거가 부족한 문장, 서로 다른 자료가 충돌하는 문장을 넣고 기대하는 분류와 이유를 사람의 기준으로 먼저 작성하면 모델 변경 뒤에도 비교할 수 있습니다.

재현 가능한 기록을 운영하는 방식

NIST AI RMF 1.0은 2023년 1월 26일 공개된 프레임워크로, AI 시스템의 지식 한계와 출력이 사람에게 어떻게 사용되고 감독되는지를 문서화하는 방향을 제시합니다. 이를 실무에 적용하면 AI가 모르는 영역과 사람의 재검토가 필요한 조건을 판정표에 별도 항목으로 둘 수 있습니다.

외부 자료를 가져오는 시스템이라면 제3자 소프트웨어와 데이터의 위험도 기록해야 합니다. 자료의 작성 주체, 사용 권한, 변경 여부, 검색이나 변환 과정에서 생긴 제한을 남겨야 결과가 맞더라도 어떤 경로로 만들어졌는지 설명할 수 있습니다.

NIST AI RMF 1.0은 AI의 지식 한계, 출력 활용 방식과 인간 감독, 제3자 소프트웨어와 데이터 위험, 시험 세트와 지표와 도구, 출력 해석과 검증을 문서화하는 항목을 제시한다.

개인정보와 비공개 자료는 재현성보다 먼저 보호해야 합니다. 원문 전체를 모든 사람에게 공유하는 대신 접근 권한을 나누고, 업무에 필요한 식별 정보만 남긴 가림본과 제한된 원본을 구분해 관리해야 합니다.

기록을 수정할 때는 기존 결과를 지우기보다 새 버전을 추가합니다. 기준을 바꾼 이유, 수정한 프롬프트, 다시 판정한 문장, 사람의 승인 여부를 이어 붙이면 과거 결론과 현재 결론이 왜 달라졌는지 설명할 수 있습니다.

재현에는 두 수준이 있습니다. 같은 문장을 그대로 다시 얻는 재현은 모델과 실행 환경의 변화 때문에 어려울 수 있지만, 같은 근거와 기준으로 같은 결론에 도달하는 감사 가능한 재현은 충분히 설계할 수 있습니다.

마지막으로 AI의 분류 결과와 사람의 최종 결정을 분리합니다. AI가 사실이라고 표시했더라도 검토자가 의견으로 바꾸거나 보류할 수 있어야 하며, 그 차이와 판단 이유를 남겨야 자동화가 사람의 판단을 조용히 대체하는 일을 막을 수 있습니다.

자주 묻는 질문 FAQ

Q1) AI에게 사실과 의견을 한 번에 구분해 달라고 해도 되나요?

가능하지만 결과를 그대로 확정하지 않는 것이 좋습니다. 먼저 문장을 주장 단위로 나누고, 사실과 의견 외에 보류 상태를 허용해야 근거가 부족한 문장을 억지로 분류하지 않습니다. 최종 판정은 사람이 근거와 기준을 확인한 뒤 남기는 방식이 안전합니다.

Q2) 대화형 AI를 사용하면 어떤 정보를 저장해야 하나요?

대화 원문과 함께 사용한 지시문, 모델 정보, 실행 시점, 연결한 자료와 도구, AI의 원래 답변을 보관해야 합니다. 서비스가 제공한다면 요청 ID와 응답 상태, 사용량 정보도 기록합니다. 편집한 최종본은 AI 원문과 분리해 저장해야 변경 지점을 확인할 수 있습니다.

Q3) 같은 답변이 다시 나오지 않으면 기록이 실패한 것인가요?

그렇지는 않습니다. 모델 버전이나 서비스 동작이 바뀌면 같은 입력에서도 표현과 세부 내용이 달라질 수 있습니다. 중요한 것은 당시의 입력, 기준, 근거, 실행 조건, 사람의 결정을 다시 확인해 결론의 형성 과정을 설명할 수 있는지입니다.