Ultracode를 믿고 맡겨도 되는 순간 — Convergence를 Evaluation Signal로 만들기

이 글은 결론이 먼저 있고, 그 결론을 어떻게 자동화할 수 있을지 설계 공간을 탐색하는 글이다. 결론은 이렇다:

사람이 Claude와 협업할 때 사람이 실제로 기여하는 것은 동의가 아니라 반박이다. 이 반박이 소진되어 더 이상 나올 게 없는 지점 — 아이디어와 output이 모호함 없이 합의된 지점 — 이 바로 사람이 손을 떼고 ultracode처럼 자율 실행에 넘겨도 되는 지점이다.

문제는 이 지점을 지금은 순전히 사람의 직관으로 판단한다는 것이다. “어느 정도 잘한다고 느낄 때” 라는 표현 자체가 이미 measurement가 아니라 vibe라는 뜻이다. 이 글은 그 vibe를 관찰 가능한 신호로 바꿀 수 있는지를 탐색한다.

1. 사람의 역할은 Critic이지 Approver가 아니다

Adversarial Feedback Loop 설계 에서 정리했던 연구들의 공통 결론 하나를 사람에게 그대로 적용할 수 있다: 순수 언어 비평(자기 자신에 대한 승인/거부)은 약한 신호이고, 외부의, 독립적인 반박이 강한 신호다.

멀티 에이전트 시스템에서는 이 “외부의 독립적 반박”을 Critic 에이전트나 tool-grounded verifier가 맡는다. 사람이 루프 안에 있는 협업에서는 그 역할을 사람이 맡고 있다 — 다만 그 사실이 명시적으로 인식되지 않을 뿐이다. 사람이 “좋아요, 진행하세요”라고 말할 때 그건 정보가 거의 없다. 사람이 “이 부분은 내 의도와 다른데, 왜냐하면…“이라고 말할 때 그게 실제 신호다.

이렇게 보면 사람-Claude 협업의 구조는 Self-Refine의 루프와 동일하다:

Claude: GENERATE
사람:   FEEDBACK (localization + instruction, 즉 어디가 왜 틀렸고 어떻게 고쳐야 하는지)
Claude: REFINE
사람:   FEEDBACK
...

차이는 Critic이 LLM이 아니라 사람이라는 것, 그리고 이 루프가 명시적인 종료 조건 없이 “사람이 지칠 때” 혹은 “사람이 만족할 때” 끝난다는 것이다. 이 종료 조건을 명시적으로 만드는 것이 이 글의 목표다.

2. 종료 지점의 정의 — Fixed Point, Not Approval

루프가 끝나야 하는 시점은 사람이 “좋다”고 느끼는 시점이 아니라, 반박이 더 이상 생성되지 않는 시점이다. 이 둘은 다르다.

승인 기반 종료: 사람이 피로해지거나, 시간이 없거나, 대충 괜찮아 보여서 멈춘다. 이건 가짜 수렴이다 — 루프가 실제로 fixed point에 도달한 게 아니라 사람이 검증을 포기한 것이다.
수렴 기반 종료: 사람이 계속 반박을 시도했지만, 최근 N번의 라운드에서 반박이 아이디어의 본질을 바꾸지 못했다. Claude의 output이 사람이 가진 모델과 실질적으로 같은 지점에 도달했다.

이 구분이 중요한 이유는, chapter 8 에서 다뤘던 SPC(Self-Play Critic)의 설계 원리와 정확히 대칭적인 우려가 여기에도 적용되기 때문이다. SPC에서는 Generator와 Critic이 같은 prior를 공유하면 “합의”가 진짜 검증이 아니라 조기 동의가 될 수 있다고 지적했다. 사람-Claude 루프에서도 마찬가지다: 사람이 Claude의 설명에 설득당해서 반박을 멈추는 것과, 실제로 반박할 거리가 소진된 것은 겉보기엔 같지만 다른 사건이다.

3. 지금 사람이 실제로 하고 있는 판단

이 부분을 더 정확히 뜯어보면, “모호함 없이 합의되었다”는 판단은 사실 하나의 신호가 아니라 여러 개의 암묵적 신호가 겹쳐서 만들어진다. 내가 실제로 ultracode를 돌리기 전에 확인하는 것들을 나열해보면:

최근 피드백의 성격이 구조적(architectural)에서 지엽적(cosmetic)으로 바뀌었는가. 처음에는 “이 방향 자체가 틀렸다”는 피드백을 주다가, 나중에는 “변수명을 이렇게 바꿔줘” 수준의 피드백만 남는다. 이건 JudgeFlow의 block-level 책임 진단 에서 말하는 “수정 범위가 좁아진다”는 것과 같은 신호를, 사람의 피드백 자체에 적용한 것이다.
같은 쟁점이 반복해서 등장하지 않는가. 새로운 라운드마다 완전히 새로운 문제가 나오는 게 아니라, 이전에 다뤘던 지점을 다시 건드리게 되는 빈도가 줄어든다.
Claude가 스스로 모호함을 표시하는 지점이 사라졌는가. Claude가 “이 부분은 두 가지 해석이 가능한데 어느 쪽을 원하시나요”라고 묻는 지점이 초반에는 자주 나오다가, 나중에는 나오지 않는다.
내가 반박을 시도했는데 반박거리를 찾지 못했는가. 이게 가장 직접적인 신호다 — 의도적으로 비판적으로 보려고 했는데 비판할 게 없다는 사실 자체.

이 네 가지는 전부 사후적으로는 관찰 가능하지만, 지금은 세션 안에서 암묵적으로만 추적되고 명시적으로 측정되지는 않는다.

4. 측정 가능한 신호로 바꾸기 — Handoff Readiness의 후보 지표

위 네 가지를 관찰 가능한 proxy로 옮겨보면:

암묵적 판단	측정 가능한 proxy
피드백이 구조적 → 지엽적으로 이동	라운드별 diff의 범위 (파일 수, 변경된 섹션 수) 가 단조 감소하는가
같은 쟁점의 반복 감소	라운드별 피드백 텍스트의 주제 클러스터링 — 새 클러스터 생성 빈도가 감소하는가
Claude의 자기표시 모호함 소멸	응답에 등장하는 명시적 질문/불확실성 표지(“어느 쪽을 원하시나요”, “확인이 필요합니다”)의 개수 추세
반박 시도 실패	사람이 피드백을 남긴 후 그 피드백이 실제로 output을 바꿨는지 (edit distance) — 라운드가 진행될수록 “피드백을 줬는데 결과가 거의 안 바뀜”이 늘어나는가

이 네 지표를 합쳐서 하나의 Handoff Readiness Score를 정의할 수 있을 것 같다. 정확한 가중치나 함수 형태는 실험이 필요하지만, 구조는 간단하다:

라운드 r에서:
  scope(r)      = 이번 라운드 diff가 건드린 범위 (구조적 vs 지엽적, 0~1)
  novelty(r)    = 이번 라운드 피드백이 새로운 주제인지 (기존 클러스터와의 거리)
  ambiguity(r)  = Claude 응답의 미해결 질문 개수
  feedback_yield(r) = 피드백 이후 실제 output 변화량

readiness(r) = 최근 k개 라운드에 걸친
               scope, novelty, ambiguity, feedback_yield 의
               동시 감소 추세

readiness(r)가 일정 임계값을 넘으면 — 즉 최근 몇 라운드 동안 네 지표가 모두 바닥에 가까워지면 — 이게 “이제 ultracode를 돌려도 된다”는 자동 추천 신호가 될 수 있다.

5. 이게 왜 그냥 “기준을 고정”하는 것보다 어려운가

여기서 chapter 8 의 AutoGen AgentEval 부분에서 나온 원칙이 다시 등장한다: 평가 기준 자체가 변별력이 있는지 검증해야 한다. Handoff Readiness Score도 마찬가지 문제를 갖는다 — 만약 이 점수가 항상 몇 라운드 후에 임계값을 넘는다면 (task 난이도와 무관하게), 그건 실제 수렴을 측정하는 게 아니라 그냥 “N라운드가 지나면 높아지는 시계”에 불과하다. 변별력이 있으려면:

쉬운 task와 어려운 task에서 readiness가 도달하는 라운드 수가 달라야 한다. 같다면 신호가 아니라 노이즈다.
의도적으로 미완성 상태에서 readiness를 측정했을 때 낮게 나와야 한다. (일종의 negative control.)
사람이 실제로 “이제 됐다”고 판단한 시점과 상관관계가 있어야 한다. 이건 결국 이 스코어를 검증하려면 사람의 판단 데이터가 필요하다는 뜻이고, 처음에 없애려던 바로 그 vibe-based 판단이 ground truth로 다시 들어온다는 역설이 있다. 다만 이 역설은 나쁜 게 아니다 — 처음에는 사람 판단을 label로 써서 신호를 캘리브레이션하고, 이후에는 그 신호가 사람 없이도 예측력을 유지하는지 검증하면 된다.

6. 조기 hand-off의 위험 — 가짜 수렴과 진짜 수렴을 구분하기

Handoff Readiness Score를 설계할 때 가장 위험한 실패 모드는 가짜 낮은 신호가 아니라 가짜 높은 신호다. 즉, 실제로는 수렴하지 않았는데 readiness가 높게 나와서 ultracode가 너무 일찍 돌아가는 경우다. 이게 일어나는 경로는 최소 두 가지다:

사람이 지쳐서 반박을 멈춘 경우. feedback_yield가 낮아지는 이유가 “더 고칠 게 없어서”가 아니라 “사람이 더 이상 자세히 안 봐서” 일 수 있다. 이 둘은 관찰 가능한 신호만으로는 구분하기 어렵다 — 외부에서 볼 때 둘 다 “피드백이 줄어든다”로 보인다.
Claude가 설득력 있게 설명해서 반박이 억제된 경우. SPC 논리와 같다 — Critic(사람)의 반박 능력 자체가 상대방의 설명 품질에 좌우될 수 있다. Claude가 실제로 옳아서가 아니라 그럴듯하게 방어해서 반박이 안 나올 수 있다.

이 둘을 구분하려면 readiness score 하나로는 부족하고, 최소한 Reflexion의 tool-grounded verification 원칙 처럼 사람의 주관적 판단과 독립적인 외부 검증(테스트 통과 여부, 빌드 성공, 실제 배포 후 동작 등)이 readiness score와 함께 확인되어야 한다. 즉 최종 설계는:

handoff 조건 = (readiness score가 임계값을 넘음)
             AND (독립적 검증 가능한 항목이 있다면 그것도 통과)

두 조건 중 하나만으로는 불충분하다.

7. 지금 당장 할 수 있는 것

완전 자동화된 readiness score를 만들기 전에, 지금 세션 안에서도 할 수 있는 것들이 있다:

세션이 길어질 때 라운드별 diff 범위를 스스로 요약해서 보여주는 습관. “이번 수정은 구조를 안 건드리고 3개 라인만 바꿨습니다” 같은 self-report는 사람이 readiness를 판단하는 데 직접적인 재료가 된다.
모호함이 있으면 명시적으로 표시하고, 없으면 명시적으로 “표시할 모호함 없음”이라고 말하는 습관. 지금은 모호함이 없을 때 조용히 진행하는 경우가 많은데, 이게 “모호함이 있었지만 확인을 안 했다”와 구분되지 않는다.
ultracode를 돌리기 직전에, 최근 몇 라운드의 피드백 성격을 스스로 되짚어 보고 사람에게 한 줄로 보고하는 것. “최근 3라운드 피드백은 전부 지엽적 수정이었습니다, 넘겨도 괜찮아 보입니다” 같은 문장이 사람의 최종 판단을 대체하진 않지만, 판단 재료를 명시적으로 만든다.

이건 자동화된 스코어가 아니라 사람의 직관을 보조하는 관찰 가능한 텍스트 신호지만, 6절에서 말한 “가짜 수렴” 문제를 줄이는 데는 이 정도로도 의미가 있다 — 적어도 판단의 근거가 암묵적인 vibe에서 명시적인 관찰로 한 단계 옮겨간다.

8. 한 줄 결론

사람이 Claude와 협업할 때 진짜 가치는 반박에 있고, ultracode에 넘겨도 되는 시점은 그 반박이 소진되는 fixed point다. 지금은 이 지점을 전적으로 감으로 판단하고 있지만, 피드백의 범위·새로움·미해결 모호함·실제 output 변화량 같은 관찰 가능한 신호들을 추적하면 이 판단을 최소한 부분적으로는 명시화할 수 있다. 다만 이 신호들은 “가짜 수렴”(사람이 지쳐서 멈춘 것)과 “진짜 수렴”(반박할 게 정말 없는 것)을 구분하지 못한다는 근본적인 한계가 있고, 이걸 보완하려면 사람의 주관적 판단과 독립적인 외부 검증이 항상 같이 있어야 한다.

Adversarial Feedback Loop 설계 — 이 글의 출발점. Critic의 피드백 소스·범위·타이밍에 대한 설계 원칙들이 여기서는 “사람이 Critic인 경우”로 확장된다.
Dynamic Workflows and Ultracode — ultracode 자체의 메커니즘과, “언제 워크플로우를 트리거할지”를 Claude가 세션 내에서 판단하는 현재 방식. 이 글은 그 판단을 사람 쪽에서 어떻게 더 명시적으로 만들 수 있는지를 다룬다.
Implicit Instruction — 세션을 넘어선 학습 루프. Handoff Readiness Score가 여러 세션에 걸쳐 캘리브레이션된다면, 그 캘리브레이션 결과 자체가 implicit instruction의 한 형태가 될 수 있다.