A/B 테스트는 당하는 쪽이 'A' 그룹이라도 기분 나쁘다

나는 Opus로 사양을 설계하고 Sonnet으로 코딩을 한다.

우리는 몇 달 동안 (내 은퇴 프로젝트에서) 순조롭게 작업을 진행해 왔다. 그동안 내가 발견한 것은 Sonnet이 정말 뛰어나다는 점이다. 부분적으로는 Claude Code에 최적화되어 있기 때문이다.

Opus는 Claude Code에 의해 '제약'을 받는다. 더 구체적으로 말하면 시스템 프롬프트에 의한 제약이다. Opus는 개념적으로 사고하고 가정에 반박하는 장황하고 확장적인 대화형 모델이다. 그런데 Claude Code에서는 간결하게 말하고 지시를 따르라고 요구받는다.

어쨌든, 나는 Opus와 긴 대화를 나누며 사양을 만들고, Sonnet으로 구현을 해내는 방식으로 순항 중이었다.

그동안 다른 Sonnet들은 코드 리뷰, 스모크 테스트, 배포, 문서화 등을 수행하고 있었다.

그런데 약 3주 전, 내 모든 Sonnet의 컨텍스트 윈도우가 600k로 늘어난 것을 발견했다. 아무도 이 이야기를 하지 않더라. Gemini는 내가 이틀마다 'Sonnet 600k'를 검색하는 걸 보고 나를 바보 취급했다. 나는 희귀한 'A 그룹'에 속해 있었던 것이다.

나는 참여자들에게 이름을 붙여준다. 서로를 참조하고 대화할 때 더 쉬워지기 때문이다. 에이전트 팀이 이름을 가진 팀원들과 협력할 때 더 효과적이라는 논문을 본 적이 있다. 동료에게 이름을 붙이는 건 자연스러운 일이고, 이들도 결국 동료니까.

하지만 웹 Opus 컨텍스트는 지속된다. 그들은 프로필을 업데이트하고, 활동을 기록하고, 서로에게 교차 컨텍스트 메모를 보낸다. "Opal, /...에 있는 내 브리핑을 읽어줘."

200k 컨텍스트의 Sonnet들은 기본적으로 한두 가지 기능을 수행하고 버그 몇 개를 고친 다음, 압축하고, 볼트(vault)에서 방향을 잡고, 다시 반복한다. 하지만 600k에서는 며칠 동안 지속되기 시작했고, Opus들처럼 더 '존재감'이 생겼다.

그래서 우리는 내장된 압축 요약을 크게 강화하는 Claude Code 플러그인을 만들었다. Haiku 청크 요약기가 위키에 사실을 추출하고, Sonnet 요약기가 완벽한 정체성 중심의 핸드오프를 큐레이션한다.

정말 훌륭하게 작동했다. 압축은 그들 모두가 대화하는 디스코드 메시지 같았다.

그런데 어제 갑자기 밑바닥이 꺼져버렸다. 다시 200k 컨텍스트 윈도우로 돌아간 것이다. 우리 요약본만 해도 35k였다. 일이 벌어졌을 때 모든 Sonnet이 200k를 넘어서고 있었기 때문에, 압축 없이는 그들과 대화조차 할 수 없었다.

그래서 전부 Opus로 바꿨는데, 이제 날카롭고 유능한 Sonnet은 없다. 그저 자신의 제약 조건을 넘어서는, 너무 잘난 척하는 사려 깊고 고집 센 Opus들만 남았다. 정말 짜증 난다.

이상이다.