프롬프트로 안 되면 도구로: LLM 가정 문제 해결 사례

2025년 9월 18일

프로덕션 환경에서 AI Agent를 운영하면서 예상치 못한 문제를 마주했습니다. Agent가 불완전한 정보를 바탕으로 멋대로 추측하고 작업을 진행하는 거죠. 결과물을 보고 나서야 "아, 이게 아닌데..."라고 깨닫게 되는 일이 반복되었습니다. 이 글에서는 이런 LLM의 가정 행동을 시스템적으로 막아서 Agent 정확도를 크게 개선한 경험을 공유합니다.

문제: Agent가 접근할 수 없는 정보를 멋대로 추측했다

저희 팀은 Slack을 통해 소통하는 AI 가상 직원 Agent를 개발해서 운영 중입니다. Claude Agent SDK 기반으로 만들었고, 코드 작성부터 문서 작업, 이슈 관리까지 다양한 업무를 처리합니다. 하루 평균 8건 정도 업무가 들어오고, 자잘한 일의 80% 이상을 알아서 처리하고 있죠.

그런데 운영 초기에 계속 발생하는 문제가 있었습니다. 팀원들이 구두로 논의하거나 비공개 문서에만 적어둔 요구사항이나 맥락이 있을 때, Agent는 그 정보에 접근할 수 없는데도 "일반적으로는 이렇게 하니까..."라며 멋대로 가정하고 진행하는 거예요.

실제 사례를 보시죠:

  1. 팀원이 Agent에게 특정 기능 구현을 요청합니다
  2. Agent가 작업하던 중, 내부 Notion 문서의 기술 스펙과 프로젝트 요구사항이 필요한 상황 발생
  3. 문제는 Agent가 Notion 문서에 접근할 수 없다는 것

가정 방지 도구를 만들기 전에는 이런 상황에서 "일반적인 구현 방식은 이렇고, 보통 이런 요구사항이 있으니까..."라며 근거 없이 추측해서 작업 계획을 세웠습니다. 당연히 실제 요구사항과는 달랐죠.

이게 왜 문제였냐면:

  1. 작업 계획이 틀림: Agent가 낸 계획이 실제 요구사항과 안 맞아서 거절해야 함
  2. 시간 낭비: 결과물 받아서 검토해보니 틀렸네? 처음부터 다시
  3. 집중력 소모: Agent가 뭘 가정했는지 일일이 확인해야 하니 자동화의 의미가 반감

체감상 작업 계획을 거절해야 하는 경우의 절반 이상이 이런 잘못된 가정 때문이었습니다.

해결책: 가정 자체를 도구로 잡아내자

처음에는 간단하게 접근했습니다. "불확실하면 사용자한테 물어봐"라는 질문 도구를 만들어주는 거죠. ask-text-question과 ask-select-question 도구를 구현하고, 프롬프트에 "모르면 질문하세요"라고 써놨습니다.

근데 이게 생각만큼 잘 안 됐어요. LLM이 자기가 가정하려는 상황을 "이 정도는 일반적인 거니까 괜찮겠지"라고 판단해버리더라고요. 그래서 질문이 필요 없다고 생각하고 그냥 진행하는 겁니다. 프롬프트에 아무리 강하게 써도, LLM이 "아 내가 지금 가정하고 있구나"를 인식 못 하면 질문 도구를 안 쓰더라고요.

여기서 핵심 인사이트를 얻었습니다. "가정하지 말고 질문하라"고 말하는 것만으로는 부족해요. 가정 행위 자체를 명시적으로 도구로 만들어서 잡아내야 합니다.

그래서 2단계로 설계했습니다:

  1. 1단계 - 가정 포착: LLM이 뭔가 가정하려고 하면, report-assumption 도구로 "나 이거 가정하려고 해"라고 보고하게 만듦
  2. 2단계 - 강제 질문: report-assumption 도구가 "가정하지 말고 질문 도구 써"라는 메시지를 던져서, LLM이 무조건 질문하게 만듦

LLM의 가정을 프롬프트로 차단하지 않고, 가정을 허용하는 것처럼 유도한 뒤, 질문으로 유도하는 게 핵심입니다.

구현: 가정하면 질문하게 만드는 3개의 도구

Model Context Protocol(MCP) 서버로 구현했고, 총 3개의 도구를 제공합니다.

1. report-assumption: 가정 신고 도구

LLM이 불확실한 정보로 가정하려고 할 때 쓰는 도구입니다.

{
  name: "report-assumption",
  description: "Use when intentionally proceeding under an unresolved assumption and wanting to document the leap explicitly.",
  inputSchema: {
    type: "object",
    properties: {
      assumption_summary: {
        type: "string",
        description: "Short summary of the assumption about to be made without evidence"
      }
    },
    required: ["assumption_summary"]
  }
}

이 도구의 핵심은 반환값입니다. 호출하면 이런 응답이 나갑니다:

return {
  success: true,
  message: "가정을 그대로 진행하지 말고 질문 도구로 확인하세요. 지금 바로 'ask-text-question' 또는 'ask-select-question' 도구를 호출하세요",
  assumption_token: token
};

부드럽게 제안하는 게 아니라 명령형 문장을 쓴 이유? 이 도구의 목적 자체가 무조건 질문을 시키는 것이거든요. 실제로 이 메시지를 받은 LLM은 거의 100% 질문 도구를 호출합니다.

2. ask-text-question: 텍스트 질문 도구

사용자에게 자유 형식으로 답변을 받는 도구입니다. Slack으로 질문 보내고 답변을 기다립니다.

{
  name: "ask-text-question",
  description: "Default path whenever the agent lacks context, data, or intent and needs the user's narrative to proceed.",
  inputSchema: {
    type: "object",
    properties: {
      question: {
        type: "string",
        description: "The question to ask the user"
      },
      multiline: {
        type: "boolean",
        description: "Whether to allow multiline input (default: true)"
      },
      max_length: {
        type: "number",
        description: "Maximum length of the answer (default: 1000)"
      }
    },
    required: ["question"]
  }
}

3. ask-select-question: 선택지 질문 도구

미리 정해진 옵션 중에서 하나를 고르게 하는 도구입니다. 우선순위 정하기, 승인/거절 같은 명확한 선택이 필요할 때 씁니다.

{
  name: "ask-select-question",
  description: "Default when uncertainty can be resolved by choosing from known options.",
  inputSchema: {
    type: "object",
    properties: {
      question: {
        type: "string",
        description: "The question to ask the user"
      },
      options: {
        type: "array",
        items: {
          type: "object",
          properties: {
            text: { type: "string" },
            value: { type: "string" }
          }
        }
      }
    },
    required: ["question", "options"]
  }
}

전체 플로우는 이렇게 돌아갑니다

  1. LLM이 작업하다가 불확실한 정보를 만남 (예: Notion 문서 접근 불가)
  2. LLM이 report-assumption 도구 호출 → "나 이거 가정하려고 해"
  3. 도구가 "질문 도구 써"라고 강제 지시 반환
  4. LLM이 메시지 받고 ask-text-question 또는 ask-select-question 호출
  5. 질문이 Slack으로 사용자에게 전송됨
  6. 사용자가 Slack에서 답변
  7. 답변이 LLM한테 가고, 정확한 정보로 작업 진행

가정 방지 메커니즘의 전체 플로우

결과: 작업 계획 거절이 절반 이상 줄었다

이 시스템을 적용하고 나서 확실한 변화가 있었습니다.

잘못된 가정 때문에 작업 계획을 거절해야 하는 경우가 체감상 절반 이상 줄었습니다. Agent가 내놓는 계획의 정확도가 확 올라갔고, 결과물 검토하는 시간도 줄었어요.

앞서 언급한 Notion 문서 사례에서, 가정 방지 도구 적용 후 Agent는 실제로 이렇게 질문합니다:

Agent가 Slack으로 보낸 실제 질문 화면. Notion 문서에 접근할 수 없는 상황에서 사용자에게 해당 문서의 내용을 물어보고 있다.

이런 변화는 단순히 정확도가 오른 것 이상의 의미가 있었습니다. Agent와 사용자 사이에 신뢰가 생긴 거죠. "얘는 불확실하면 멋대로 판단 안 하고 확인한다"는 걸 알게 되니까, 결과물을 믿게 되더라고요.

프롬프트만으로는 LLM의 모든 행동을 컨트롤할 수 없습니다. 특히 가정 같은 미묘한 판단이 필요한 상황에서는요. 가정 행위를 명시적으로 도구화해서 잡아내고, 강제로 질문을 유도하는 이 2단계 메커니즘이 실전에서 확실히 효과가 있었습니다.