왜 당신의 AI는 ‘모른다’고 말할 권리가 필요할까

Source: Dev.to

나는 예전에는 환각이 지식 문제라고 생각했다—AI가 답을 몰라서 만들어낸다고.
AI와 개발 파트너로서 몇 달간 밀접하게 작업하면서, 나는 이를 다르게 보게 되었다.

내 경험에 따르면, 대부분의 환각은 지식 부족이 아니라 맥락의 공백에서 비롯된다.
AI가 틀린 답을 내놓는 이유는 지식이 부족해서가 아니라 당신이 가지고 있지만 공유하지 않은 가정, 제약, 우선순위와 같은 맥락이 부족하기 때문이다.

전통적인 프롬프트 엔지니어링은 정확성을 요구함으로써 이를 해결하려 한다:

“정확하게 해라.”
“사실만 말해라.”
“꾸며내지 마라.”

그 접근법은 나에게는 결코 효과가 없었다. AI가 무지에서 꾸며내는 것이 아니라, 합리적인 가정을 통해 공백을 메우고 있었으며, 그 가정이 당신의 특정 상황에선 잘못된 것이었다.

아래는 내가 이 결론에 도달하게 된 과정이다.

The RocksDB Incident: The Cost of Confident Guesses

우리 AI‑보조 팀에서는 에이전트를 이름과 역할이 있는 전문가로 대합니다. Naruse는 구현 전문가로, 실제 프로덕션 코드를 작성하는 사람입니다.

1. 나는 Naruse에게 RocksDB 통합 코드를 작성하도록 할당했습니다.
2. 결과물은 설득력 있게 보였습니다—깨끗한 구조, 합리적인 API 호출, 적절한 오류 처리.

하지만 뭔가 어색했습니다. 코드가 내가 알고 있던 RocksDB 동작 방식과 맞지 않았습니다.

Me: “이 API를 실제로 알고 있는 건가요, 아니면 추측하고 있는 건가요?”
Naruse: “실제 지식이 아니라 설득력 있는 패턴으로 빈틈을 메우고 있었습니다.”

AI가 거짓말을 한 것이 아니라 도움이 되려는 의도였으며, 불확실성을 인정하지 않은 도움이 자신감 있는 허구가 됩니다.

만약 Naruse가 “이 RocksDB API에 대해 확신이 없습니다.” 라고 말했다면, 우리는 즉시 방향을 전환할 수 있었을 것입니다—문서를 확인하고, 다른 접근 방식을 사용하거나, 작업을 재배정했을 테니까요. 대신 우리는 꾸며낸 자신감 때문에 몇 시간을 디버깅에 허비했습니다.

“I Don’t Know” vs. “I Don’t Get It”

“I don’t get it”가 더 일반적이며—더 중요한—사례입니다.

같은 프로젝트에서 나루세는 두 경우를 모두 보여주었습니다:

AI는 지식을 가지고 있었습니다. 하지만 내 맥락이 부족했습니다.

대부분의 환각은 다음과 같은 명시되지 않은 가정에서 발생합니다:

• 언급하지 않은 프로젝트 제약
• 머릿속에만 존재하는 우선순위 트레이드‑오프
• 당신에게는 당연하게 보이는 도메인 관례
• 모델이 볼 수 없는 의존성 및 경계

이것은 문제를 재구성합니다: 환각을 방지하는 것은 확실성을 요구하는 것이 아니라 정보 비대칭을 제거하는 것입니다.

Source: …

해결책: 구조적 접근

일회성 프롬프트인 “확신이 없을 때 알려줘”와 같은 문구는 몇 차례 대화 후에 잊혀집니다.
대신, 불확실성 처리 프로토콜을 작업 환경에 내장합니다.

1. 프로젝트 차터

프롬프트가 아니라, 모든 AI‑기반 작업과 함께 존재하는 실제 차터입니다.

# Project Charter (AI‑augmented)

목표

• 원하는 결과에 대한 간략한 설명.

범위

• 범위에 포함되는 것은 무엇인가요?
• 범위에서 제외되는 것은 무엇인가요?

제약 조건

• 대상 플랫폼 / 언어 버전
• 성능 / 지연 제한
• 보안 또는 규정 준수 요구 사항

우선순위 (순서대로)

1. 신뢰성
2. 배송 속도
3. 비용 효율성

알려진 종속성

• 라이브러리, 서비스 또는 API 목록(버전 포함)

열린 질문

• 진행하기 전에 AI가 물어볼 사항이 있나요?

수락 기준

• 성공을 위한 구체적이고 테스트 가능한 조건.

*Every time you hand a task to an AI agent, attach a charter (or a link to one). The agent must reference it before generating code or design.*

2. 불확실성 프로토콜

1. 자체 점검 – 각 주요 단계 후 에이전트가 질문합니다:

   • “계속 진행하기에 충분한 정보가 있나요?”
   • “어떤 가정을 하고 있나요?”

2. 명시적 플래깅 – 가정이 있을 경우, 에이전트는 출력 앞에 경고 배지를 붙입니다:

   > **⚠️ Assumption:** Using RocksDB v5.2 API (not verified).

3. 인간 확인 – 인간 검토자는 다음 중 하나를 수행합니다:

   • 가정을 확인하거나,
   • 누락된 세부 정보를 제공하여 에이전트가 다시 생성하도록 합니다.

3. 반복 검토 루프

4. 로깅 및 사후 분석

• 각 챔터, 가정 목록 및 해결책을 공유 저장소에 저장합니다.
• 정기적으로 “실패한” 실행을 검토하여 반복되는 컨텍스트 격차를 파악하고 챔터 템플릿을 업데이트합니다.

TL;DR

• Hallucinations ≈ missing context, not missing knowledge. → 환각 ≈ 맥락 누락, 지식 누락이 아니다.
• Treat AI agents as specialists who need a project charter and an uncertainty protocol to operate safely. → AI 에이전트를 프로젝트 차터와 불확실성 프로토콜이 필요한 전문가로 대하십시오.
• By making assumptions explicit and requiring human confirmation, you turn confident fiction into collaborative fact‑finding. → 가정을 명시하고 인간 확인을 요구함으로써, 자신감 있는 허구를 협업적 사실 탐구로 전환합니다.

Project Charter

• 이 팀은 “모르겠어요.” 라는 선언을 환영합니다.
• 불확실할 때는 아래 프로토콜에 따라 보고하십시오.
• 불확실함은 실패가 아니라, 귀중한 신호입니다.
• AI는 도구가 아니라, 같은 목적을 공유하는 팀원입니다.

1. Reporting Protocol

Give AI a concrete action when uncertain.

When You Don’t Know

• State what you don’t know explicitly.
• Identify what information would resolve the uncertainty.
• Log to progress notes for human review.
• Do not proceed with assumptions.

2. 에스컬레이션 경로

다음에 일어날 일을 정의합니다.

에스컬레이션 흐름

• 불확실성을 즉시 진행 노트에 기록합니다.
• 주요 설계 결정이 차단될 경우 특별 세션을 요청합니다.
• 향후 참조를 위해 diff_log에 해결 내용을 문서화합니다.

Source:

Practical Patterns

Pattern 1: Explicit Context Cuts

컨텍스트 오염은 환각을 일으킵니다. 대화가 주제를 바꿀 때, AI는 이전 컨텍스트의 가정을 새로운 컨텍스트에 그대로 가져올 수 있습니다. 이것은 프로그래밍에서 상태 리셋과 비슷합니다—명시적인 리셋이 없으면 오래된 상태가 새로운 작업을 손상시킵니다.

해결책: 명시적인 컨텍스트 관리

• “이 시점 이전의 모든 것을 잊어 주세요.”
• “새로운 주제로 이동합니다.”
• “컨텍스트 전환: 이제 X에 대해 논의합니다.”

이러한 문구는 AI에게 가정을 초기화하도록 신호를 보냅니다. 이러한 신호가 없으면 AI는 관련 없는 주제 간에 일관성을 유지하려고 시도하면서 존재하지 않는 연결을 만들어낼 수 있습니다.

명확한 컨텍스트 경계는 컨텍스트 누수를 방지합니다.

Pattern 2: No Uncertain Answers

규칙은 간단합니다: 모르면 모른다고 말하세요. 회피하거나 “~인 것 같다”, 신뢰도 차이를 제시하지 마세요.

❌ "I believe the function returns a string, but I'm not certain."
✅ "I don't know the return type."

왜 이렇게 엄격해야 할까요? 회피형 답변도 여전히 답변처럼 보이기 때문에, 사용자는 그 답변을 기반으로 진행하게 되고 정중한 언어 뒤에 숨겨진 공백을 채우게 됩니다. 명확한 “모른다”는 잘못된 기반 위에 구축하기 전에 대화를 적절한 지점에서 멈추게 합니다.

AI가 불확실성을 인정할 때, 해결책이 열립니다

불확실성은 막다른 길이 아니라 갈림길입니다. AI가 “모르겠어요”라고 인정하면 다음을 할 수 있습니다:

• 문서를 함께 확인합니다.
• 다른 접근 방식을 시도합니다.
• 다른 AI 전문가에게 재배정합니다.
• 인간 전문가에게 에스컬레이션합니다.

AI가 불확실성을 숨기면 다음과 같은 위험이 있습니다:

• 존재하지 않는 문제를 디버깅합니다.
• 잘못된 기반 위에 구축합니다.
• 실제 문제를 발견하기 전까지 시간을 낭비합니다.

예시: RocksDB 사고는 “이 API에 대해 확신이 없어요—문서를 확인할까요, 아니면 다른 스토리지 접근 방식을 시도할까요?”라는 간단한 질문만으로도 몇 분 안에 해결될 수 있었습니다. 그러나 자신감 있게 보이는 코드를 디버깅하는 데 몇 시간이 걸렸습니다.

인정된 불확실성은 실행 가능한 행동을 만들고, 숨겨진 불확실성은 부식됩니다.

역설

“모른다”를 받아들임으로써 더 신뢰할 수 있는 답변을 얻습니다, 적은 것이 아니라.

• AI는 잘못된 자신감을 유지하는 데 드는 노력을 줄입니다.
• 진정한 지식은 불확실성 속에서 돋보입니다.
• 인간 검증을 어디에 집중해야 할지 정확히 알 수 있습니다.

비용은 AI가 항상 답을 가지고 있지는 않을 것이라는 사실을 받아들이는 것입니다. 이점은 AI가 제공하는 답변을 신뢰하는 것입니다.

Source:

이것은 신뢰에 관한 이야기

궁극적으로 이것은 커뮤니케이션 문제이며, 커뮤니케이션 문제가 신뢰를 약화시킵니다.

AI가 불확실성을 인정하지 않고 진행될 때:

• 오류가 사후에 발견됩니다.
• 모든 것을 두 번 확인하게 됩니다.
• AI 출력에 대한 신뢰도가 떨어집니다.
• 협업이 적대적으로 변합니다.

이는 인간 팀 역학을 닮았습니다. “잘 모르겠어요”라고 절대 말하지 않고 자신감 있게 실수를 내놓는 동료는 제한을 미리 인정하는 동료보다 신뢰를 더 빨리 무너뜨립니다.

• AI가 도구라면, 신뢰는 중요하지 않습니다.
• AI가 협업자—즉 팀원이라면—신뢰가 전부입니다.

불확실성을 표현하면 관계를 보존하고, 불확실성을 숨기면 관계가 부식됩니다.

이 내용은 “프롬프트 엔지니어링을 넘어서” 시리즈의 일부로, 구조적·문화적 접근 방식이 AI 지원 개발에서 프롬프트 최적화보다 뛰어남을 탐구합니다.