클로드는 왜 멈추지 않았는가 — Fable 후기

지난 글 클로드는 왜 자꾸 멈추는가에서 클로드가 자꾸 멈추는 이유를 봤습니다. 이번엔 반대 경험인데, 결론부터 말하면 모델 얘기는 아닙니다.

며칠 전 공개된 Fable 5를 잠깐 써봤습니다. (지금은 미국 정부의 수출통제 지시로 접근이 중단돼 더는 못 씁니다.) 데스크탑 앱 하나를 7시간 넘게 한 번도 “이거 어떻게 할까요”로 멈추지 않고 만들더군요. 처음엔 모델이 똑똑해서겠거니 했습니다.

그런데 같은 작업 환경에 Opus 4.8을 붙여봤더니, 체감 퀄리티는 조금 덜해도 오래 일하는 건 똑같이 됐습니다. 여기서 생각이 정리됐습니다. 강한 모델은 환경이 좀 부실해도 알아서 잘합니다. 그러면 거꾸로, 환경을 손보면 다른 모델로도 그만큼 끌어올릴 수 있지 않을까. 이 글은 그 시도입니다.

7시간

지난 글에서, 클로드가 멈추는 가장 큰 원인은 능력 부족이 아니라 “스스로 결정하기 애매한 분기가 너무 자주 나오는 일”을 시켰기 때문이라고 적었습니다. 이번 7시간 동안엔 그 분기가 거의 안 생겼습니다. 시나리오 13개, 태스크 17개를 구현하고 검증하고 커밋할 때까지, 메인 세션이 “다음에 뭐 하지”를 고민하는 자리가 없었습니다.

그게 모델 덕인지 환경 덕인지 궁금해서, 작업 환경을 직접 들여다봤습니다.

작업 환경 비교

사실 이건 새 모델이 나온 김에 작업 방식을 바꿔본 것뿐입니다. 그전까지 저는 일을 할 일(태스크) 중심으로 관리했고, 그게 잘 맞아서 계속 그렇게 쓰고 있었습니다. 시나리오 중심 방식도 예전부터 갖춰뒀지만, 할 일 중심이 워낙 잘 돌아가서 적극적으로 쓰진 않고 있었죠. 그러다 새 모델이 나오니 “이번엔 시나리오 중심으로 해볼까” 싶어 그냥 바꿔본 겁니다. (둘 다 제가 쓰는 작업관리 도구인데, 도구 이름은 중요하지 않으니 접어두겠습니다.) 추측하지 않으려고 양쪽의 실제 코드와 작업 기록을 직접 확인했습니다.

• 할 일 중심: “할 일”을 트리로 쌓습니다(계획 → 그룹 → 태스크). 태스크 하나가 곧 요구이자 작업단위입니다.
• 시나리오 중심: 요구를 “이런 상황에서(Given) 이렇게 하면(When) 이렇게 된다(Then)” 라는 자연어 시나리오로 먼저 적습니다. 그리고 그 시나리오를 만족시킬 태스크를 그 아래로 분해하는데, 각 태스크는 “나는 어느 시나리오를 위한 작업인가”를 참조로 들고 있습니다.

태스크는 이번에도 미리 다 만들어뒀습니다. 그래서 둘의 차이는 태스크를 언제 만드느냐가 아니라, 무엇을 중심에 두느냐 — 할 일이냐, 요구(시나리오)냐 — 에 있었습니다.

왜 오래 갔는지에 대한 가설

기록을 보고 세운 가설은 둘입니다.

하나, 모델이 매 순간 다음 작업을 스스로 정할 수 있었습니다. 시나리오는 “관찰 가능한 결과”를 자연어로 못 박은 안정적인 기준입니다. 태스크가 그걸 참조하니, 모델은 늘 “아직 만족 안 된 시나리오는 뭐고, 그걸 위한 다음 작업은 뭐냐”를 국소적으로 정할 수 있었습니다. 사용자에게 물으러 올라올 일이 줄어듭니다. 반대로 할 일 중심에선 태스크가 할 일이자 요구라서, 애매할 때 기댈 행동 기준이 없습니다 — 그래서 멈추거나 묻습니다. (돌이켜보면, 지난 글의 9천 개짜리 검증 작업이 오래 돌았던 것도 “문제를 발견하면 그때 태스크를 만든다”는 식이라 비슷한 결을 우연히 가졌던 거였습니다.)

둘, 일을 메인이 직접 안 했습니다. 이게 기록에서 가장 선명했습니다. 할 일 중심 환경의 작업 기록을 보니 실제 작업을 메인 세션이 6천 번 넘게 직접 했고, 별도 에이전트에게 넘긴 건 손에 꼽았습니다. 반면 시나리오 중심에선 구현이 매번 새 에이전트로 빠졌습니다. 그 에이전트는 자기 컨텍스트에서 한 기능을 끝내고 압축 보고만 남기고 사라지므로, 메인의 컨텍스트가 깨끗하게 유지됩니다. 오래 버티는 본질이 이겁니다 — 메인이 직접 다 떠안으면 몇 기능 못 가 컨텍스트가 구현 디테일로 오염되고, 길어질수록 길을 잃습니다.

재밌는 건 둘 다 제가 “이렇게 해라”라고 의도한 게 아니라는 점입니다. 환경이 위임을 강제하느냐 아니냐에서 자연스럽게 갈린 흐름이었습니다.

모델이 메운 것, 그리고 옮길 수 있는 것

여기까지면 “환경만 잘 짜면 아무 모델이나 된다”로 들릴 수 있는데, 그렇진 않았습니다. Fable 5가 Opus 4.8보다 나았던 건 “오래”가 아니라 판단의 정확도와 결과 퀄리티였습니다. 강한 모델은 덜 갖춰진 환경도 자기 머리로 덮습니다.

그래서 제 질문은 이렇게 됩니다. 그 머리가 속으로 하던 걸 환경이 밖에서 대신 공급하면, 다른 모델도 따라가지 않을까? 이번에 옮길 수 있겠다고 본 것들입니다(특정 도구가 아니라 일반 원칙으로).

• 다음 작업과 위임 지시문(태스크 정보·기대 결과·보고 형식)을 모델이 매번 손으로 쓰는 대신 환경이 찍어주기. 잘 쓰인 지시문을 따르는 건 어느 모델이든 잘합니다. 약한 건 지시문을 잘 쓰는 쪽이죠.
• 거부·에러 메시지를 “복붙 가능한 교정 명령”으로 주기. “인자가 틀렸다”에서 멈추거나 루프를 도는 일이 사라집니다.
• “끝났다”를 모델 양심이 아니라 코드 검증으로 정의하기. 증거(테스트·파일·라인) 없이는 완료가 안 되게.
• 막힘 → 정지가 아니라, 막힘 → 근거 있는 잠정 결정 기록 → 진행.

다른 작업에서 까다로운 벽에 막힌 적이 있습니다. 그때 Opus 4.8은 “이건 환경 한계다” 라고 적고 일을 접었습니다. 같은 벽을 Fable 5는 ① 쓰던 도구의 버전을 의심해 최신으로 올리고 ② 도구 내부에 로그를 박아 중간 산출물을 들여다봐서 진짜 원인(설정 한 줄)을 찾아 넘었습니다. 차이는 능력이라기보다 절차였습니다. 그리고 이 절차도 환경으로 내릴 수 있습니다.

왜 한쪽은 쉽게 접었을까요. 제 환경을 뜯어보니, “완료”에는 증거를 깐깐하게 요구하면서 “못 하겠다”에는 거의 아무것도 안 물었습니다. 그러면 어려운 일에서 가장 싼 출구가 “막혔다고 선언하기”가 됩니다. 포기를 완료만큼 비싸게(증상·시도한 것·근본 원인을 적게) 만들면, 한 번 더 파게 됩니다.

그래서 고쳐볼 것

그래서 위에서 옮길 수 있겠다고 본 것들 — 다음 작업·지시문 자동 생성, 에러를 교정 명령으로, 검증을 코드로, 막힘을 잠정 결정으로 — 을 제 환경에 하나씩 옮겨보려고 합니다. 모델이 머릿속에서 대신 해주던 걸, 환경이 밖에서 만들어주게 하는 방향입니다.

마무리

다 옮길 수는 없습니다. 시나리오 자체를 잘 쓰는 일, “이 수치는 버그가 아니라 설계 결함이다”를 알아보는 감각은 여전히 모델 몫이 큽니다. 위의 전부도 정답이 아니라, 써보고 코드를 읽은 뒤의 현재 가설입니다.

다만 방향은 이렇게 잡았습니다. 이번처럼 어떤 모델은 며칠 만에 사라지기도 하지만, 작업 환경은 제가 짭니다. 그러니 더 좋은 모델을 기다리기만 하기보다, 지금 쓸 수 있는 모델에서 성능을 더 잘 끌어낼 수 있도록 환경을 깎는 일을 계속 시도해보려고 합니다.