AI 생성 문서의 숨겨진 신뢰 문제

Source: Dev.to

AI‑생성 문서에서 숨겨진 신뢰 문제

프로젝트에 대해 AI가 처음으로 문서를 생성했을 때, 완벽해 보였습니다: 명확한 구조, 자신감 있는 어조, 전문적인 언어. 바로 그게 문제였습니다.

일주일 뒤, 문서를 검토하려고 했을 때 나는 기본적인 질문에 답할 수 없었습니다:

이 문서의 어느 부분이 내 요구사항에서 나온 것이고, 어느 부분이 AI가 만들어낸 것인가?

모든 내용이 동일한 자신감으로 쓰여 있었고, 어떤 내용을 신뢰하고 어떤 내용을 검증해야 할지 알 방법이 없었습니다.

AI가 문서를 만들 때는 다음을 구분하지 못합니다:

• 명시적으로 제공한 사실
• 기존 문서에서 추론한 정보
• 빈틈을 메우기 위해 만든 가정
• 일반적인 업계 관행

이 모든 것이 페이지 상에서는 똑같이 보입니다. 처음에는 편리하게 느껴지지만, 나중에는 실제로 옳은 것과 단지 그럴듯하게 들리는 것을 구별할 수 없게 되므로 위험해집니다.

모든 진술에 출처 태그 달기

개념은 간단하지만 실제로는 강력합니다: AI가 모든 진술에 출처 태그를 달도록 요구합니다. 각 주장마다 출처를 명시해야 합니다.

태그 정의

예시 재작성

[explicit] The API uses REST architecture with JSON responses.
[inferred] Authentication requires Bearer tokens.
   └─ "All endpoints require authentication" (REQUIREMENTS.md L.23)
[assumed] Rate limiting is set to 100 requests per minute.
[general] Error responses follow RFC 7807 format.

이제 검토 작업이 명확해집니다: 어디에 집중해야 할지 정확히 알 수 있습니다. [inferred] 태그는 가장 위험한 경우가 많습니다. AI는 사후 합리화에 매우 능숙해서, 먼저 결론을 내린 뒤 이를 뒷받침할 듯한 텍스트를 찾아냅니다.

검증 가능한 추론 강제

규칙: 모든 [inferred] 진술에는 출처에서 발췌한 그대로의 인용문이 포함되어야 합니다.

[inferred] Retry policy allows 3 attempts
   └─ "External API calls should retry up to 3 times" (API_DESIGN.md L.28)

인용문이 결론을 뒷받침하지 않으면 문제가 즉시 드러납니다. 인용문이 없으면 직접 문서를 찾아야 하지만, 인용문이 있으면 검증에 몇 초면 충분합니다.

Source: …

태그가 필요한 경우

모든 문서에 태그가 필요한 것은 아닙니다. 규칙은 간단합니다: 다른 사람들이 진실로 의존할 문서에 태그를 붙이세요.

소스 코드는 이미 검증 메커니즘(테스트)을 가지고 있습니다. 문서는 그렇지 않으며, 소스 태그가 누락된 검증 메타데이터를 제공합니다.

용어 변동 처리

Source attribution alone breaks down when terminology drifts.

# API_DESIGN.md
[explicit] Retry policy allows 3 attempts

# SERVICE_SPEC.md
[inferred] Re‑execution strategy permits 3 tries

# TEST_SPEC.md
[inferred] Fault recovery mechanism uses 3 retries

같은 개념에 대한 세 가지 다른 이름 때문에 grep 검색과 영향 분석이 실패하고 신뢰성이 떨어집니다.

대화형 통합

정적인 용어집 대신 AI‑인간 대화 중에 용어를 통합합니다:

Human: “재실행 횟수를 5로 늘려야 합니다.”
AI: “‘재실행’이라고 말씀하셨는데, 기존 문서의 ‘retry policy (#retry‑policy)’와 같은 의미인가요?”
Human: “네.”
AI: “알겠습니다. retry policy를 5회 시도로 업데이트합니다.”

용어 변동은 손상이 퍼진 뒤가 아니라 입력 시점에 잡히게 됩니다. 이는 단일 사용자 워크플로에서는 잘 작동하지만, 여러 사용자가 동시에 작업할 경우 서로 다른 진실이 병렬로 나타날 수 있어 문제가 됩니다. 이를 해결하려면 공유 인프라가 필요합니다: 동기화된 용어집, 버전 관리된 용어, 혹은 직렬화된 워크플로—이것은 또 다른 종류의 문제입니다.

실용적인 가이드

• 새 프로젝트: 첫날부터 AI를 도입하고, 태그와 통합 용어를 깔끔하게 유지합니다.
• 레거시 시스템: 질문 기반 통합을 사용하고, 이후 태그 규칙을 적용합니다.
• 경계: 새로운 작업은 프로토콜을 따르고, 레거시는 수정될 때까지 그대로 둡니다.

출처 표기가 AI를 완벽하게 만들지는 않으며, 실수를 방지하지도 않습니다. 하지만 실수를 드러나게 합니다. AI가 확신한 부분과 추측한 부분을 볼 수 있을 때, 인간의 판단을 적용해야 할 위치를 알 수 있습니다. 이러한 가시성은 AI 협업 개발에 대한 신뢰의 기반입니다.

---

이 기사는 Beyond Prompt Engineering 시리즈의 일부로, 체계적(우연이 아닌)인 AI 활용 방식을 탐구합니다.