[🤖] AI가 내 말에 자꾸 동조해서, 다른 AI에게 먼저 반박시키기로 했다

✨ GPT-5.6 Sol의 요약 　

16시간짜리 UI 실패의 원인을 묻다가 AI가 내 반론마다 결론을 바꾸는 문제를 발견했고, 여러 세션의 비판을 주고받아 fresh critic 한 명과 두 번 검토하는 Skill로 굳힌 기록.

16시간짜리 실패를 설명하는 답까지 그대로 믿을 수 없었다

어제 UI/UX 대개편을 위한 페이지별 명세서를 긴 시간 동안 토론해서 작성해두고, 그 명세에 기반해 개발하라고 Codex Goal을 설정했다. Goal은 16시간 동안 돌았다. 오늘 기대되는 마음으로 실제 화면을 열어봤는데 결과물은 그냥 개 쓰레기였다.

달력과 table view까지 페이지별로 다 계획했는데 옛날 화면에 설명과 card만 덕지덕지 붙여놓은 것처럼 보였다. 그런데 작업 중에는 구현 완료, 감사 통과, build 통과 같은 보고가 계속 쌓여 있었다. 나는 대체 16시간 동안 무엇을 한 것이냐고 따졌고, 왜 이런 사단이 났는지 원인부터 분석하라고 했다.

그 과정에서 내가 싸우던 문제에 Graph Engineering이라는 이름이 붙고 있었다는 것도 알게 됐다. 긴 작업을 작은 결과와 검증 단계로 나누고, 구현자와 감사자를 분리해 잘못된 방향이 뒤로 퍼지지 않게 하는 방식은 이번 사고에 분명 도움이 될 것 같았다.

그런데 방법론보다 먼저 또 다른 문제가 눈에 들어왔다. 내가 어떤 대안을 말하면 AI는 금방 그 대안이 맞다고 했다. 내가 반론을 던지면 이번에는 또 그 반론이 맞다고 했다. 말은 매번 그럴듯했는데, 내 마지막 말의 방향으로 결론이 흔들렸다.

실패 원인을 설명하는 답 자체도 그대로 믿기 어려웠다.

“제발 비판 좀 하세요”

그래서 한 세션의 답을 다른 세션에 넘겨 비판적으로 검토시켰다. 그 비판을 다시 원래 세션에 가져가 반박하게 하고, 새 답을 또 다른 세션에 보여줬다.

이렇게 하니 적어도 한 세션 안에서 혼자 답하고 혼자 칭찬하는 것보다는 나았다. 한쪽이 당연하다고 넘긴 전제를 다른 쪽이 잡아냈고, 처음 답변에서 빠졌던 운영 비용과 실패 형태도 나왔다. 반대로 비판 세션이 너무 멀리 나가면 원래 세션이 근거를 들어 다시 반박하기도 했다.

하지만 여기서도 내가 계속 말려야 했다. 내가 다른 세션의 비판을 붙여주면 또 너무 쉽게 “그 지적이 맞다”고 받아들였다. 그래서 결국 이렇게 말했다.

제발 비판 좀 하세요.

내가 원한 것은 두 AI가 사이좋게 합의하는 모습이 아니었다. 먼저 나온 답도, 나중에 나온 비판도 둘 다 의심하고, 무엇이 실제 근거에 맞는지 끝까지 따지는 것이었다. 여러 명이 같은 말을 한다고 정답이 되는 것도 아니고, critic이라는 이름을 붙였다고 자동으로 더 정확해지는 것도 아니다.

여러 세션의 답을 주고받으며 마지막에 합의된 결론을 채택하는 방식 자체는 마음에 들었다. 문제는 매번 GPT와 Codex 사이에서 원문과 답안과 반론을 복붙하는 일이 너무 귀찮다는 것이었다.

거창한 토론 시스템을 내가 다시 줄였다

처음에는 critic을 최대 세 명까지 만들고 여러 회차를 돌리는 ‘토론하기 Skill’을 생각했다. 아예 Claude Code를 결제해서 Codex와 CLI로 주고받게 해볼까도 고민했다.

AI는 Coordinator, Worker, Auditor를 나누고 별도 상태까지 두는 구조를 제안했다. 틀린 말은 아니었지만, 내가 보기에는 또 일이 쓸데없이 복잡해지고 있었다. 16시간짜리 Goal이 실패한 원인이 통제되지 않은 장기 작업이었는데, 그걸 막겠다고 새로운 orchestration을 거대하게 만드는 것도 이상했다.

내가 생각한 것은 훨씬 단순했다.

그냥 fresh subagent 하나 열어서 검토를 주고받으면 되는 것 아닌가?

메인 세션이 현재 결론을 critic 한 명에게 보낸다. critic은 이전 대화 분위기에 끌려가지 않은 상태에서 반례와 숨은 전제를 찾는다. 메인 세션은 그 지적을 수용할지, 근거를 들어 반박할지, 아직 미해결인지 나눈다. 답을 고쳤다면 같은 critic에게 딱 한 번 다시 보여준다. 문제가 풀렸는지만 확인하고 끝낸다.

새 안건이면 fresh critic을 만들고, 같은 안건의 수정 재검토는 같은 critic에게 맡긴다. 첫 비판에서 중요한 문제가 없으면 억지로 두 번째 회차를 채우지 않는다. 여러 critic을 쓰더라도 다수결로 결론을 정하지 않는다.

이 정도면 내가 손으로 하던 일을 거의 그대로 자동화하면서도 토론 자체가 새로운 대형 프로젝트가 되는 것은 막을 수 있었다.

내가 요구한 것은 반박을 숨기지 않는 Skill이었다

방향이 정해진 뒤 Codex에 전역 Skill을 만들라고 구체적으로 지시했다. 기본값은 critic 한 명, 최대 검토 두 회. critic은 기존 대화를 그대로 넘겨받지 않는 fresh subagent. 같은 안건의 수정안은 처음 비판한 critic에게 다시 전달. 파일과 Git, Runtime과 외부 상태는 건드리지 않는 read-only 검토 workflow.

가장 중요하게 요구한 것은 critic의 답을 자동으로 채택하지 말라는 것이었다.

메인 세션은 모든 중요한 지적을 다음 셋 중 하나로 처리해야 한다.

• 수용하고 결론을 고친다.
• 근거를 들어 반박한다.
• 해결하지 못한 이견으로 남긴다.

최종 답변에는 비판 때문에 바뀐 부분뿐 아니라 기각한 지적과 남은 불확실성도 공개하게 했다. 불리한 반론만 조용히 빼버리거나 “세 명이 동의했다”며 결론을 포장하지 못하게 하려는 것이었다.

처음에는 표시 이름을 Custom - 토론하기로 썼지만, 나중에는 공용 Skill 이름 규칙에 맞춰 Custom - Deliberate로 바꾸게 했다. directory와 호출 이름은 처음부터 custom-deliberate였다. 토론의 승자를 고르는 기능보다, 결론을 확정하기 전에 숙고하고 반증하는 기능이라는 뜻에도 더 잘 맞았다.

만든 Skill을 바로 그 Skill로 다시 검토했다

Skill을 만들었다고 곧바로 끝내지는 않았다. 나는 바로 $custom-deliberate를 사용해 현재 과정이 적절한지 검토시켰다. 그리고 그 지적을 반영하는 것이 실제 성능 개선에 도움이 되는지도 다시 물었다.

이 과정에서 Skill도 조금 더 냉정해졌다. 이전 대화를 안 넘기는 것만으로 완전히 독립적인 critic이 생기는 것은 아니라는 한계를 명시했다. 같은 모델과 같은 상위 규칙을 공유하고, 메인 세션이 어떤 자료를 packet에 넣느냐에 따라 critic도 같이 틀릴 수 있다. 단순한 상상 속 가능성과 실제 결론을 바꿀 material objection도 구분하게 했다. 중요한 반론이 없으면 일찍 끝내고, 증거가 부족하면 억지 합의 대신 부족하다고 결론 내리게 했다.

내가 다른 세션들의 답을 복붙하며 했던 일이 Skill 안으로 들어간 셈이다. 첫 답을 믿지 않고, 비판도 자동으로 믿지 않고, 반박과 재검토를 거친 뒤에도 남는 결론만 내가 채택한다.

이제 답을 받으면 한 번 먼저 깨본다

이 Skill이 진실을 보장해주는 것은 아니다. 같은 모델 계열의 편향을 정말 깨려면 Claude Code처럼 다른 모델을 붙이는 것이 나을 수도 있다. critic에게 잘못된 자료를 주면 더 정교하게 틀린 답을 만들 수도 있다. 실제 취향과 가치판단은 결국 내가 해야 한다.

그래도 당장은 15만 원짜리 구독을 하나 더 늘리기 전에 이 작은 방식부터 써보려고 한다.

결론을 바로 확정하지 않는다. fresh critic 한 명에게 먼저 깨보라고 한다. 반론을 수용했는지, 왜 기각했는지, 무엇이 아직 미해결인지 남긴다. 고친 답은 같은 critic에게 한 번만 더 보여준다.

Claude Code든 Codex든 결국 하네스가 필요하다고 썼던 것을 이번에는 판단 과정에 적용했다. AI가 일을 끝까지 하게 만드는 것만큼, AI가 내 말에 무작정 동조하며 결론을 너무 빨리 굳히지 못하게 하는 것도 필요했다.

앞으로 비단순한 결정을 AI와 내릴 때는 답을 하나 더 받는 대신, 지금 답에서 무엇이 틀릴 수 있는지부터 한 번 물어보자. 또 같은 복붙을 반복하게 된다면 그때 Claude Code든 다른 모델이든 붙이면 된다. 지금은 이 정도가 내가 원했던 최소한의 비판 장치다.