코딩 에이전트 모델 조합 — 키미 설계 vs 페이블+GPT5.6 Sol 구현

저녁 시간, 한 참여자가 짧게 화두를 던졌다. "백엔드를 그렇게잘한다던데"라는 문장이었다. 키미라는 모델의 백엔드 역량에 대한 소문을 확인해보고 싶다는 취지였는데, 곧이어 다른 참여자가 "키미는 프론트를 잘해여!"라며 반대되는 체감평을 내놓으면서 대화가 갈렸다. 이어진 반응은 "백엔드는 기본은 하니깐여 다들"이라는 절충적인 평가였다.

처음 화두를 던진 참여자는 직접 검증에 나섰던 경험을 전했다. 키미에게 설계를 맡긴 뒤 "클로드한테 검수시켰더니 거의 한 문서짜리 수정내용"을 받았다고 밝혔고, 결국 "키미한테 열심히 설계시켰으니 코덱스보고 감수하고 구현하라해야겠녜용"이라며 역할을 재조정하는 쪽으로 정리했다. 비슷한 시점에 다른 참여자는 "그거 gpt 5.6 으로하는게 많이쓰는 패턴이신거같더라고여"라며 구현 단계에 특정 모델을 쓰는 흐름이 이미 자리잡고 있다는 관측을 보탰다.

설계와 구현을 분리해서 계산하는 방식

이 지점에서 한 참여자가 구체적인 조합을 제시했다. "키미가 설계 괜찮게 하나요?"라는 질문에 이어 "전 체감상 페이블이 설계하기에 가성비 젤 좋은 느낌이던데"라고 밝혔고, 곧바로 "페이블 설계 gpt5.6 sol 구현"이라는 조합을 구체적으로 소개했다. 다른 참여자는 "돈만 많으면 페이블 쓸 것 같습니다"라며 비용 부담을 언급했지만, 조합을 제시한 참여자는 "설계는 구현보단 돈이 덜들기도 하고.."라며 "셀계 망하면 기술부채가 나중에 넘 심한느낌이라" "설계에 돈쓰는건 전 안아까운거같아여"라고 설계 단계에 투자하는 이유를 풀어냈다. 실제 작업 방식도 구체적으로 공유됐는데, "5.6 sol로 해두고 칼질해서 1/3 토막까지 깎으면, 적어도 빠진 스펙은 안생기는듯요"라는 설명이었다. 다른 참여자는 "페이블잘쓰면 오히려 토큰이 세이브"라며 이 조합의 효율성에 동의했고, 또 다른 참여자는 "키미는 백엔드도 잘합니다"라며 애초의 체감평을 다시 뒤집기도 했다.

대화 전체를 관통한 것은 단일 모델의 우열이 아니라 역할별 배분이었다. 설계·구현·검증을 서로 다른 모델에 나눠 맡기는 방식이 이미 여러 참여자 사이에서 관행처럼 자리잡고 있었고, 그 배분의 기준은 성능뿐 아니라 비용 구조였다. 설계 단계에서 잘못된 방향을 잡으면 이후 구현에서 발생하는 기술부채가 훨씬 크다는 인식이 공유됐고, 그래서 상대적으로 저렴한 설계 단계에 돈을 쓰는 편이 전체 비용을 아끼는 길이라는 계산이 여러 차례 반복됐다.

이런 흐름은 코딩 에이전트를 쓰는 실무자들이 이제 '어떤 모델이 제일 좋은가'보다 '어느 단계에 어떤 모델을 배치할 것인가'를 더 중요한 질문으로 다루고 있음을 보여준다. 설계·구현·검증을 서로 다른 모델로 쪼개는 조합이 늘어날수록, 모델 선택 자체보다 파이프라인 설계 능력이 실무 생산성을 가르는 변수가 될 가능성이 크다.