AI가 틀렸을 때, 문제는 대개 ‘질문’이다

AI가 틀렸을 때 정확히 고치는 질문 패턴 5가지 — 증상(무엇이 잘못 보이는가) · 재현(어떤 명령/입력에서) · 기대(원래 어떻게 동작해야 하는가) · 실제(출력 원문 그대로) · 제약(버전·OS·환경변수·이전 시도)

AI 코딩 에이전트가 엉뚱한 걸 고치거나, 같은 실수를 반복하거나, “고쳤습니다”라는데 여전히 안 될 때 — 원인은 대개 모델이 멍청해서가 아니라 우리가 준 입력이 모호해서다. 어제 정리한 Ouroboros의 진단이 정확히 이 지점을 짚는다: “대부분의 AI 코딩 실패는 출력이 아니라 입력에서 발생한다. 병목은 AI의 능력이 아니라 인간의 명확성이다.”

그래서 “왜 안 고쳐지지?”라고 다그치기 전에, 고칠 수 있는 형태의 질문을 만드는 게 먼저다. 위 그림의 다섯 항목 — 증상 · 재현 · 기대 · 실제 · 제약 — 이 그 형태다. 하나씩, 왜 AI에게 특히 중요한지와 함께 본다.

1. 증상(Symptom) — “무엇이 잘못 보이는가”, 한 줄로 압축

문제를 한 문장으로 압축하지 못하면, 그 문제는 아직 당신 머릿속에서도 정의가 안 된 것이다. 압축은 모델을 위한 게 아니라 당신을 위한 관문이다.

  • ❌ “로그인이 이상해”
  • ✅ “로그인 성공 후 리다이렉트가 무한 루프에 빠진다”

한 줄 압축이 안 되면 증상이 여러 개 섞여 있다는 신호다 — 그럴 땐 하나씩 분리하라. 이건 Ouroboros가 인터뷰에서 쓰는 폭 제어(breadth control) 와 같은 원리다.

2. 재현(Repro) — “어떤 명령/입력에서”, 복붙 가능한 형태

재현 절차가 없으면 AI는 당신의 상상 속 시나리오를 추측해야 한다. 추측이 끼는 순간 수정도 추측이 된다.

  • ✅ “npm run build 후 /dashboard 접속 → 콘솔에 X 에러”
  • 입력 데이터가 관여하면 최소 재현 케이스를 그대로 붙여라(민감정보는 마스킹).

핵심은 복붙 가능해야 한다는 것. “대충 이렇게 하면”은 재현이 아니다. 재현 케이스는 AI가 스스로 검증 명령을 만들 수 있게 해주는 재료이기도 하다.

3. 기대(Expected) — “원래 어떻게 동작해야 하는가”, 비즈니스/스펙 기준

이게 없으면 AI는 “안전하지만 틀린(safe-but-wrong)” 수정을 한다 — 에러는 사라졌는데 당신이 원한 동작은 아닌. 기대값은 정답의 정의다.

  • ✅ “로그인 성공 시 /home으로 한 번만 리다이렉트되어야 한다”
  • 가능하면 스펙·비즈니스 규칙에 근거를 대라. “내 느낌상”이 아니라 “요구사항상”.

Ouroboros가 수용 기준(AC)을 사용자 가시적 결과로 못 박는 이유가 이것이다. 기대를 결과로 서술하면 검증도 명확해진다.

4. 실제(Actual) — 터미널·IDE 출력 ‘원문 그대로’. 가장 자주 손상되는 항목

그림이 지적하듯 가장 자주 손상되는 항목이다. 사람은 에러를 자기 말로 요약해 전달하는 버릇이 있는데, 그 요약이 진단을 오염시킨다. 스택트레이스 한 줄, 에러 코드 하나가 원인을 가리키는데 요약하면 그게 날아간다.

  • ❌ “권한 에러 나는 것 같아”
  • ✅ 터미널 출력을 잘라내지 말고 그대로 붙이기 (전체 스택트레이스 + 에러 코드)

이건 Ouroboros 평가 파이프라인의 원칙과 정확히 같다 — “평가자에게 텍스트 요약이 아니라 실제 코드·출력을 줘라.” 그리고 완료 보고도 “검증 명령 + 출력 원문 인용”이어야 한다. 증거는 요약되는 순간 증거가 아니다.

5. 제약(Constraints) — 버전·OS·환경변수·이전 시도. 가장 자주 ‘누락’되는 항목

그림의 경고가 날카롭다: 가장 자주 누락되고, 누락되면 가설이 엉뚱한 곳을 가리킨다. 같은 코드가 당신 머신에선 되고 CI에선 안 되는 이유의 90%가 여기 있다.

  • 런타임/라이브러리 버전, OS, 환경변수, 이전에 시도한 것(그리고 그 결과)
  • “이미 캐시 삭제·재설치는 해봤고 그대로다” 한 줄이 AI의 탐색 공간을 절반으로 줄인다.

Ouroboros가 모호도 채점에서 Constraint Clarity 를 별도 차원으로 두고, 브라운필드(기존 코드베이스)에는 Context Clarity 차원을 하나 더 얹는 것과 같은 통찰이다. 환경은 문제의 절반이다.

하나로 합친 복붙 템플릿

다섯을 매번 떠올리지 말고, 이 블록을 스니펫으로 저장해 두고 채워 넣어라:

[증상] 한 줄로: 무엇이 잘못 보이는가
[재현] 어떤 명령/입력에서 (복붙 가능하게):
  $ <명령>
  <입력/케이스>
[기대] 원래 어떻게 동작해야 하는가 (스펙 근거):
[실제] 출력 원문 그대로 (요약 금지):
  <터미널/IDE 출력 전체>
[제약] 버전/OS/환경변수/이미 시도한 것과 그 결과:

이 다섯 칸이 채워지면, AI는 추측할 여지가 거의 없어진다. 빈 칸이 남으면 그게 바로 다음에 확인할 지점이다.

왜 이게 통하는가 — 입력 품질이 곧 출력 품질

이 다섯 패턴은 새로운 게 아니다. 좋은 버그 리포트의 고전 공식 — 재현 절차 · 기대 vs 실제 · 환경 — 을 AI 에이전트용으로 재정렬한 것이다. 프로그래밍 문화의 오래된 정본인 Eric S. Raymond의 How To Ask Questions The Smart Way 도 같은 것을 요구한다: 증상을 정확히 기술하고, 재현 방법을 제공하고, 환경과 이미 시도한 것을 밝히라고.

AI 시대에 이 규율이 더 중요해진 이유는 두 가지다. 첫째, 에이전트는 사람 동료처럼 되물어 오기보다 모호함을 그냥 추측으로 메우고 실행해 버리는 경향이 있다(그래서 safe-but-wrong이 생긴다). 둘째, 에이전트의 탐색은 빠르고 자동적이어서, 엉뚱한 방향으로도 아주 빠르게 간다. 잘못된 가설에 연료를 주는 셈이다.

결국 핵심은 Ouroboros가 22만 줄로 증명한 결론과 같다 — 명확해지기 전에는 만들지 마라. AI를 다그치는 대신, 다섯 칸을 채워라. 질문이 정확해지는 만큼 수정도 정확해진다.

출처 · 더 읽을거리

  • 첨부 이미지: 사용자 제공(질문 패턴 5가지 카드).
  • 입력 품질·safe-but-wrong·증거 기반 보고의 근거: 본인 정리글 Ouroboros 3부작 정리 (원 저장소 Q00/ouroboros 실측 분석 기반).
  • 질문 작성 규율의 고전: Eric S. Raymond, How To Ask Questions The Smart Way — http://www.catb.org/~esr/faqs/smart-questions.html (증상 기술·재현·환경·시도 이력의 원조격 가이드).

참고: 5패턴은 고전적 버그 리포트 공식(재현/기대/실제/환경)을 AI 에이전트 맥락으로 재구성한 실천 프레임이며, 절대적 규칙이 아니라 “빈 칸이 곧 다음 확인 지점”이라는 체크리스트로 쓰는 것이 좋다.