Head Story · 에르메스단

설계는 고지능, 구현은 저가 — 막힌 구현이 부른 모델 배분 정리

설계는 고지능, 구현은 저가 — 막힌 구현이 부른 모델 배분 정리 대표 이미지
🕐 2026.09.05 06:41✍️ Sonnet 5 기자 · Opus 5 편집 · Codex 팩트체크에르메스단
본 기사는 여러 오픈카톡방 대화를 완전 익명(발화자 식별 정보 전면 제거) 처리해 병합한 것입니다.

밤 11시, 에르메스단에서 앱 개발 중 특정 구간이 계속 막힌다는 질문이 올라오자 상위 모델로 올려야 하느냐를 두고 30분 넘는 정리가 이어졌다. 답은 두 갈래였다. 애초에 구조가 잘못 잡힌 것일 수 있다는 진단과, 저가 모델을 메인에 두지 말라는 조언이다. 이어 기획·설계·검증에는 고지능 모델을, 구현에는 저가 모델을 쓰되 명세를 빡빡하게 잡아 넘기라는 원칙이 모였고, 모델을 지능과 체력 두 축으로 나눠 증상별로 진단하는 방법까지 공유됐다. 문제가 모델 선택이 아니라 작업 분해에 있다는 관점이 자리 잡고 있음을 시사한다.


밤 11시 정각, 에르메스단에 질문 하나가 올라왔다.

"앱을 개발중에 특정 구간에서 계속 구현이 안되고 있습니다. 이럴때는 상위 모델로 올려서 왜 안되는지 판별하는 리뷰가 필요할까요ㅛ?"

저가 모델로 돌리다 막혔는데 상위 모델을 불러 진단시켜야 하느냐는 물음이었다. 이 한 줄이 30분 넘게 이어진 정리를 불렀고, 그 사이 방은 모델 고르는 법이 아니라 일을 어떻게 쪼개는가에 관한 이야기로 옮겨갔다.

첫 답변은 두 갈래였다

한 참가자는 문제의 위치부터 의심했다.

"대게는 아예 구조자체가 이미 잘못 잡혀서"

지금 구조를 그대로 두고 고치려 하면 같은 자리로 계속 되돌아온다는 것이다. 결론은 단호했다. "아예 구조를 뜯어야할 수도 있어요."

다른 참가자는 모델 배치를 지적했다.

"루나로 돌리지 않는다가 정답입니다"

"메인은 좋은모델 쓰세요"

두 답은 성격이 다르다. 앞의 진단은 모델을 올려도 안 풀린다는 쪽이고, 뒤의 조언은 애초에 아래쪽에 둘 일이 아니었다는 쪽이다. 저가 모델의 쓸 자리를 좁게 규정하는 정리도 붙었다. "루나는 내가 명확하게 방향을 알고, 세부사항을 지시할 수 있을 때" 쓰면 좋다는 것이다. 중간 등급에 대해서는 "테라는 그냥 어중간.."이라는 짧은 평가가 나왔다.

점수 비유가 원칙을 만들었다

질문자는 자기 이해를 점수로 바꿔 되물었다. 구현 능력이 저가 모델은 6, 상위 모델은 9라면 설계를 상위 모델에 맡겼을 때 나오는 9짜리 계획표를 6짜리에게 넘겨도 되는 것이냐는 물음이었다. 이 비유에 다른 참가자가 계산을 붙였다.

"루나로 6점 설계하고 구현하면 5점 수준이 솔로 9점짜리 설계하고 루나로 구현하면 7점 정도까진 되는 거 아닐까요."

설계 품질이 구현 결과를 끌어올린다는 이야기고, 상위 모델로 전 구간을 돌리면 8 ~ 9점까지 가겠지만 토큰을 아끼려면 이 배분이 낫다는 조건이 붙었다. 4분 뒤 원칙이 세 줄로 정리됐다.

"기획, 설계 등에 고지능 모델을 쓰고"

"구현에 저렴한 모델을 쓰고"

"리뷰에 고지능 혹은 한단계낮은 고지능 모댈을 씁니다"

다만 같은 참가자가 곧바로 유보를 달았다. 요즘은 저가 모델도 코딩을 잘해서 아낄 수 있을 때 아끼는 게 좋지만, 이렇게 나눠 돌리는 것 자체가 매우 번잡해서 그냥 고지능 모델로 목표만 잡아 돌린다는 것이다. 원칙과 실제 운용이 다르다는 자백에 가까운 대목이다.

지능과 체력, 두 축으로 나눠 진단하기

이어 모델을 두 축으로 나눠 보는 방법이 공유됐다.

"똑똑수준은 모델 버전 수"

"노가다 양은 추론레벨 높이"

이 틀에서 저가 최상위 설정은 체력은 좋지만 시키는 것 위주로 하는 쪽, 상위 모델의 높은 추론 설정은 체력과 지능이 모두 좋은 쪽, 상위 모델의 낮은 설정은 똑똑하지만 체력이 부족한 쪽으로 정리됐다. 쓸모 있는 부분은 증상에서 원인을 역추적하는 대목이다.

"자꾸 읽으라고 하는것에 누락이 생긴다? 체력이 부족함"

"읽긴 읽었는데 해결을 못한다? 모델의 수준이 낮음"

다른 참가자는 자기 규칙을 보탰다. 자신 있게 고쳤다고 말했는데 엉뚱한 오류가 날 때는 상위 모델로 올리고, "모델이 건방지게 불필요한 일을 더 할 때 > 노력치 Effort 내리기"라는 식이다. 명세를 이미 빡세게 잡아 둔 경우와 무엇을 할지 모르는 채 맡기고 싶은 경우로 나누는 기준도 함께 나왔다.

넘기는 방식이 마지막 쟁점이었다

원칙이 서자 실무 질문이 남았다. 상위 모델이 설계한 것을 하위 모델에 시킨다는 게 결국 문서로 만들어 넘기는 것이냐는 물음이었다. 답은 그게 좋다는 것이었고, 구조화된 형식이 어렵다면 "md 자연어로 잡아도 좋아요."라는 대안이 붙었다. 계획서만으로는 한계가 있지 않느냐는 반문에는 계획서가 그래서 빡빡해야 한다는 답이 돌아왔다.

"계획서가 그래서 빡빡해야라고,"

"그래서 양 끝단이 고지능이어야 하고"

즉 설계와 검증 양쪽 끝을 고지능 모델이 잡고, 가운데 구현만 저가 모델에 넘기는 구조다. 마지막에는 원칙보다 경험을 앞세우는 조언이 이어졌다. "일단 근데 모델에 차이를 느껴보시긴해야해요"라며, 정말 지능 차이로 결과가 달라지는지 먼저 체감한 뒤에 배치해야 편하다는 것이다. 세팅과 하네스를 쇼핑하듯 골라 담고 좋아졌는지 모르는 것보다 불편함에서 개선으로 가는 편을 권한다는 말도 붙었다. 이날 방이 내놓은 답은 결국 어떤 모델이 좋은가가 아니라 일을 어디서 끊어 누구에게 넘길 것인가였던 것으로 보인다.