---

---

세 모델로 일하기 — 하청·작업단위·감리

코드를 짤 때 나는 세 가지 LLM을 쓴다. 가끔 사람들이 묻는다 — 왜 세 가지냐고. 하나로 충분하지 않냐고. 답은: 하나로는 부족하기 때문이 아니다. 세 모델이 잘하는 일이 각각 다르기 때문이다.

이게 단순한 모델 선호의 차이가 아니다. 모델마다 어떤 cognitive scale에서 일하는가가 다르다. 그 차이를 알고 나면, 각 모델에 어떤 종류의 일을 맡길지가 자연스럽게 정해진다.

세 모델, 세 역할

내 workflow는 이렇게 굴러간다:

Gemini = 하청. 광범위한 탐색이 필요한 일을 맡긴다. 새로운 영역의 자료 조사, 큰 코드베이스의 overview 파악, 여러 가능성을 펼쳐놓고 보는 작업. Gemini는 숲을 보는 모델이다. 더 정확히는 Amazon rainforest scale에서 본다. 광활하고 다양하다. 디테일은 약하지만 전체 그림이 빠르게 그려진다.

Claude = 작업단위. 실제 구현 작업의 main body를 맡긴다. 한 feature를 plan하고 implement하는 중간 granularity의 작업. Claude는 forest와 trees 사이 어딘가에서 일한다. 전체 맥락을 잡으면서 디테일도 어느 정도 보장한다. 가장 자주 쓴다.

Codex = 감리. 검수와 정교한 다듬기를 맡긴다. Claude가 구현한 결과를 trees 단위로 점검한다. 빠진 edge case, 미묘한 type mismatch, 일관성 없는 naming. Codex는 나무를 보는 모델이다. 숲은 잘 못 보지만 나무는 매우 잘 본다.

이 세 역할이 처음부터 의도된 게 아니다. 각 모델을 한참 써보고 나서, 얘는 이런 일을 잘 하는구나가 점점 드러난 거다. Role은 모델의 cognitive style에서 자연 발생했다.

Flow가 작동하는 방식

전형적인 작업 flow는 이렇다.

새 feature를 구현해야 한다. 먼저 Gemini한테 던진다. "이 영역에 어떤 접근들이 있는지, 어떤 trade-off가 있는지 폭넓게 보고 싶다." Gemini는 Amazon scale로 답한다. 가능성이 너무 많아서 그중 내가 원하지 않는 것들까지 다 포함된다. 그게 OK다. 내가 직접 큐레이션해서 방향을 잡는다.

방향이 잡히면 Claude한테 옮긴다. "이 방향으로 implement해줘." Claude는 작업단위로 implementation을 만든다. Plan을 짜고, 단계를 나누고, 코드를 쓴다. 중간에 분기점이 있으면 멈추고 물어본다. Claude의 강점은 작업의 모양을 잡는 데 있다.

Implementation이 나오면 Codex한테 검수를 맡긴다. "이 코드에 빠진 게 뭔가." Codex는 trees 단위로 들여다본다. Edge case, error handling, naming consistency, performance hot spot. 종종 Codex의 검수가 Claude가 못 본 것을 잡는다. 반대로 Codex가 가져온 변경은 큰 그림에서 보면 잘못된 방향인 경우가 있어서, 그때는 내가 다시 큐레이션한다.

세 모델이 한 작업의 다른 layer에서 일한다. 단일 모델로 이걸 하려면 prompt를 매우 careful하게 디자인해야 한다. 세 모델을 쓰면 각자의 강점이 role assignment로 자연스럽게 활용된다.

함의 — 단일 모델 가정의 종료

이 workflow가 일반화 가능한지는 별도 문제다. 모든 사용자가 세 모델을 다 쓸 필요는 없다. 그리고 모델들이 변하고 있다 — 지금 Gemini가 잘하는 걸 1년 뒤에는 Claude가 더 잘할 수도 있다.

그래도 한 가지가 분명해진다 — 단일 모델 가정의 시대는 끝나가고 있다. 도구를 디자인할 때 "Claude를 위한 도구", "GPT를 위한 도구"로 specialize하는 건 점점 의미가 줄어든다. 같은 도구가 다른 모델에 의해 다른 role로 쓰일 수 있어야 한다.

내가 만드는 vault tool은 이걸 의식하고 디자인됐다. 도구 description은 모델-specific하지 않다. JSON output은 어떤 모델이든 파싱할 수 있다. Error code는 model-agnostic하다. Tool description이 어떤 모델한테는 잘 통하고 어떤 모델한테는 안 통하는 자리가 없게 노력한다.

이게 항상 잘 되지는 않는다. 모델마다 읽기 습관이 다르다. Gemini는 description의 첫 문장을 더 잘 본다. Claude는 description의 왜 쓰는가 부분에 sensitive하다. GPT는 schema에서 단서를 더 많이 끌어낸다. 그래도 모델-agnostic이라는 design goal은 유효하다.

세 모델로 일하기는 불편함이기도 하다. 한 모델로 끝낼 수 있으면 더 단순하다. 그러나 작업의 cognitive layer가 여러 개라는 걸 받아들이면, 각 layer에 fit한 모델을 쓰는 게 더 자연스러워진다.

도구를 디자인한다는 건 모델을 위한 인터페이스를 디자인하는 게 아니다. 작업의 cognitive scale을 표현하는 일이다. 모델은 그 표현에 자기 cognitive style을 맞춰 들어온다.

---