추측의 종말

에이전트 실패담을 모아보면 패턴이 있다. 능력이 모자라서 실패하는 경우는 생각보다 적다. 대부분은 잘못된 가정 위에서 유능하게 일한 경우다. “당연히 REST겠지”, “당연히 운영 DB는 아니겠지”, “당연히 이 브랜치겠지” — 추측은 조용히 코드가 되고, 코드가 된 추측은 PR 리뷰에서야 발각된다.

그래서 최근 코딩 에이전트들이 갖추기 시작한 한 가지 능력이 흥미롭다. 일하다 멈추고, 사람에게 구조화된 질문을 던지는 도구. Claude Code의 AskUserQuestion, 그리고 OpenAI Codex CLI의 request_user_input이다. 이 글은 이 작아 보이는 프리미티브가 왜 하네스 엔지니어링의 관점에서 중요한지에 대한 고찰이다.

왜 ‘구조화된’ 질문인가

에이전트는 원래도 질문할 수 있었다 — 채팅으로. 그런데 이 도구들은 자유 대화가 아니라 폼(form) 을 던진다. Claude Code의 AskUserQuestion은 한 번에 1~4개 질문, 질문당 2~4개 선택지, 복수선택 여부, 선택지별 미리보기(코드 스니펫·목업)까지 명세하고, 항상 “Other”(자유 입력)가 자동으로 붙는다. Codex의 request_user_input은 질문마다 탭이 생기는 설문 UI로, 키보드만으로 탭을 오가며 답한다.

자유 대화 대비 구조화의 이득은 명확하다:

인지 부하가 낮다. “어떻게 할까요?”는 사람에게 백지 작문을 시키지만, “(a) 섀도우 모드 (b) 강제 모드 (c) 라이브러리만”은 비교 판단만 시킨다. 답변 시간이 문단에서 한 글자로 줄어든다.
결정이 기록이 된다. 선택지와 선택 결과가 구조화돼 있으니 “왜 이렇게 됐지?”의 답이 대화 로그에 감사 가능한 형태로 남는다. 스펙 문서에 “결정: (a), 사유: …”로 옮기기도 쉽다.
선택지 설계가 곧 분석이다. 좋은 객관식을 만들려면 에이전트가 먼저 결정 공간을 분해해야 한다. 트레이드오프를 정리하고 추천안에 근거를 붙이는 과정 자체가 얕은 추측을 걸러낸다.
“Other”가 안전판이다. 구조화의 위험(선택지 밖 정답)은 자유 입력 탈출구가 상쇄한다.

한 줄로: 질문 도구의 본질은 질문이 아니라 선택지 설계다. 에이전트에게 “물어봐도 된다”를 주는 게 아니라, “물으려면 결정 공간을 먼저 정리하라”는 규율을 주는 것이다.

두 구현, 두 철학

기능은 닮았지만 배치가 다르고, 그 차이가 철학을 드러낸다.

	Claude Code `AskUserQuestion`	Codex CLI `request_user_input`
가용 범위	상시 — 어느 단계든 호출 가능	Plan 모드 한정 (기본 모드에선 비활성)
UI	질문 칩 + 선택지, 옵션별 미리보기	질문별 탭 + Submit 탭, 키보드 내비게이션
암묵 철학	질문은 상시 프리미티브다	질문은 계획 단계의 부속이다

Claude 쪽 설계는 “모호함은 계획 단계에만 있는 게 아니다”라는 입장이다. 구현 중간에도, 마이그레이션 직전에도, 되돌리기 어려운 결정 앞에서는 멈추고 물어야 한다. Codex 쪽은 질문을 계획의 일부로 본다 — 계획이 확정되면 실행은 묻지 않고 달린다는 그림이다.

흥미로운 것은 커뮤니티의 반응이다. Codex 저장소에는 request_user_input을 기본 모드에서도 열어달라는 이슈가 여러 건 쌓여 있고(#11892, #29104, #11536), 아예 AskUserQuestion을 코덱스에 이식하는 커뮤니티 스킬까지 나왔다. 사용자들이 몸으로 투표한 셈이다 — 질문은 상시 도구여야 한다고.

하네스 관점 — 질문은 가장 작은 게이트다

이 시리즈에서 다뤄온 하네스들을 겹쳐 보면 이 프리미티브의 위치가 보인다.

Ouroboros의 interview는 “숨은 가정을 소크라테스식 질문으로 폭로한 뒤에야 스펙을 확정”하는 매크로 절차다. AskUserQuestion은 그 원자 단위 — 인터뷰 한 문항의 도구화다.
Superpowers 브레인스토밍 스킬의 규칙(“한 번에 한 질문, 객관식 선호, 설계 승인 전 구현 금지”)은 이 도구가 있어야 실행 가능한 절차다. 도구와 절차가 맞물릴 때, “추측하지 말고 물어라”는 지침이 아니라 워크플로가 된다.
결과적으로 질문은 가장 작은 게이트다. 아키텍처 편의 ArchUnit이 “경계 위반을 빌드 실패로” 만들었듯, 질문 도구는 “가정 위반을 대화 중단으로” 만든다. 잘못된 길로 10분 달리는 것보다 3초 멈추는 게 싸다.

실전 — UI가 없는 채널에서 밤새 벌어진 일

이 글이 관념이 아닌 이유: 어젯밤 이 패턴으로 실제 기능 하나가 main에 머지됐다.

상황은 이렇다. 나는 텔레그램으로 에이전트에게 지시를 내리고 있었다. 텔레그램에는 AskUserQuestion의 예쁜 UI가 없다. 그래서 에이전트는 도구 대신 패턴을 이식했다 — 결정이 필요할 때마다 (a)/(b)/(c) 번호 객관식 + 추천안 + 근거를 메시지로 보내고, 나는 한 글자로 답했다.

그날 밤의 결정 로그: 게이트 운용 모드(섀도우/강제/라이브러리) → 근거성 판정 방식(구조화 JSON/문장 임베딩/인용 마커) → 검증 입력 소스 → 임베딩 이중 트랙 — 그리고 나중에는 구현 중 발견된 설계 충돌(스프링 빈 등록 여부)까지 같은 형식으로 올라왔다. 각 결정은 한 글자 답변으로 확정됐고, 스펙 문서에 그대로 박제됐고, 아침이 되기 전에 테스트 수백 개가 초록인 채로 머지가 끝났다.

여기서 두 가지를 배웠다. 첫째, 도구가 없어도 패턴은 이식된다 — 구조화된 질문의 가치는 UI가 아니라 형식에 있다. 둘째, 역설적으로 그래서 도구화가 더 가치 있다 — 패턴을 매번 손으로 빚는 대신 프리미티브로 보장하면, 어떤 에이전트든 어떤 채널이든 같은 규율을 갖는다.

기대효과, 그리고 정직한 한계

기대효과 네 가지로 정리한다.

재작업의 전진 배치 — 가장 비싼 발견(잘못된 가정)이 PR 리뷰에서 질문 시점으로 당겨진다. 이 시리즈가 반복해온 명제의 인터랙션 버전.
결정 감사 로그 — “누가 언제 왜 이 길을 골랐나”가 구조화된 형태로 남는다. 에이전트가 한 일의 책임 소재가 또렷해진다.
비동기 협업의 최소 단위 — 사람이 자리에 없어도 되는 작업과, 사람의 판단이 필요한 순간이 도구 호출 단위로 분리된다. 심야의 텔레그램 한 글자 답변으로 개발이 굴러가는 그림이 그 증거다.
신뢰의 축적 — 에이전트가 “모르면 묻는다”는 확신이 생기면, 더 큰 작업을 맡길 수 있다. 질문 능력은 자율성의 반대가 아니라 자율성의 전제다.

한계도 셋 적는다.

결정 떠넘기기. 질문 도구가 있으면 에이전트가 스스로 판단해야 할 것까지 묻고 싶어진다. 관례적 기본값이 있는 결정, 코드를 읽으면 알 수 있는 사실은 묻지 않는 게 규율이다 — 질문 게이트는 “사용자만 답할 수 있는 결정”에만 서야 한다.
프레이밍 편향. 선택지를 설계하는 자가 답을 유도할 수 있다. 추천안을 첫 번째에 놓고 “(추천)”을 붙이는 관행은 효율적이지만, 잘못된 추천이면 편향을 증폭한다. Other 탈출구와 사용자의 회의(懷疑)가 견제 장치다.
타이밍의 기술. 너무 이르면 성가시고, 너무 늦으면 이미 코드가 됐다. 언제 물을 것인가는 여전히 모델의 판단력에 달렸고, 이 판단력 자체는 도구가 보장해주지 않는다.

맺으며

코딩 에이전트의 진화를 한 축으로 요약하면 “출력의 품질”에서 “입력의 품질“로의 이동이다. 더 좋은 코드보다 더 정확한 가정. AskUserQuestion과 request_user_input은 그 이동의 가장 작은 실물이다 — 에이전트가 유능해지는 만큼, 멈추고 묻는 능력이 그 유능함의 방향을 잡는다.

질문할 줄 아는 에이전트가, 결국 믿고 맡길 수 있는 에이전트다.

Sources:

시리즈: 아키텍처 규율은 어떻게 에이전트의 하네스가 되는가 · Superpowers × OMC × Ouroboros 3축 스택 · Ouroboros 0.35→0.50 구조 진화 · 에이전트도 워크로드다