일상적인 개발을 위해 정말 가장 진보된 AI 모델이 필요할까요?

새로운 AI 모델이 출시될 때마다 대화는 익숙한 패턴을 따릅니다. 사람들은 벤치마크 (benchmarks)를 비교하고, 추론 능력 (reasoning capabilities)에 대해 논쟁하며, 코딩 점수와 컨텍스트 윈도우 (context window) 크기를 축하합니다. 우리 모두는 최신 모델이 무엇을 할 수 있는지에 대해 흥분합니다.

저 또한 흥분합니다. 하지만 최근 저는 스스로에게 다른 질문을 던지기 시작했습니다: 일상적인 업무를 위해 실제로 가장 진보된 모델이 필요할까?

나의 기본 선택

오랫동안 Sonnet은 저의 주요 코딩 어시스턴트였습니다. 더 새롭고 더 유능한 모델들이 출시된 후에도, 저는 소프트웨어 개발 작업에 대해 지속적으로 강력한 결과를 제공했기 때문에 Sonnet을 계속 사용했습니다. 최근 코드 리팩터링 (refactoring) 작업을 하던 중, 저는 궁금증이 생겼습니다. 평소 사용하던 모델을 자동으로 사용하는 대신, 더 작고 저렴한 대안과 비교해 보기로 했습니다.

간단한 실험

설정은 간단했습니다. 저는 두 모델에 동일한 파일과 동일한 작업인 '코드 리팩터링'을 주었습니다. 결과는 흥미로웠습니다:

Sonnet: 76.1 크레딧 (credits)
Haiku: 13.3 크레딧 (credits)

이는 약 5.7배 더 저렴합니다. 당연히 저는 더 비싼 모델이 더 나은 결과를 낼 것이라고 예상했습니다. 하지만 결과는 그렇지 않았습니다.

나를 놀라게 한 결과물

솔직히 말씀드리면, 저는 Haiku의 솔루션이 더 마음에 들었습니다. 기존 파일에 점진적인 변경을 가하는 대신, Haiku는 코드를 세 개의 더 작은 파일로 나누었습니다. 구조가 더 깔끔하고 유지보수하기 쉬워 보였습니다. 더욱 놀라웠던 점은 Haiku가 우리의 Copilot 지침에 정의된 코딩 표준을 더 일관되게 따랐다는 것입니다.

결과물이 완벽하지는 않았습니다. Sonnet의 결과물도 마찬가지였습니다. 하지만 최종 결과물을 비교했을 때, 저는 거의 6배나 저렴한 모델이 만들어낸 작업물을 더 선호하고 있는 저 자신을 발견했습니다. 이는 우리 중 많은 이들이 하는 가정, 즉 **'더 크고 더 비싸다고 해서 자동으로 더 나은 것은 아니다'**라는 점을 다시 생각하게 만들었습니다.

하네스 (Harness)는 우리가 생각하는 것보다 더 중요하다

이 실험은 지난 1년 동안 제가 배워온 사실을 다시 한번 확인시켜 주었습니다. 모델의 능력 (Model capability)은 방정식의 한 부분일 뿐이라는 점입니다.

저희 저장소(Repository)에서는 제가 **AI 개발 하네스 (AI development harness)**라고 부르는 것을 구축하는 데 상당한 노력을 기울여 왔습니다. AI를 우리의 코드베이스를 마법처럼 이해하는 챗봇으로 취급하는 대신, 다음과 같은 구조화된 환경을 제공합니다.

저장소별 지침 (Repository-specific instructions)
코딩 표준 및 컨벤션 (Coding standards and conventions)
아키텍처 가이드 (Architectural guidance)
개발 워크플로우 (Development workflows)
프로젝트 구성 방식에 대한 컨텍스트 (Context)
리뷰 및 검증 기대치 (Review and validation expectations)

저는 이전 기사에서 이 접근 방식에 대해 작성한 적이 있습니다: Beyond Coding: How I Built an AI Harness to Automate My Development Lifecycle.

제가 발견한 것은 이러한 가드레일 (Guardrails)이 마련되면, 작은 모델들이 많은 사람들이 예상하는 것보다 훨씬 더 유능해진다는 사실입니다. 모델은 더 이상 무엇이 "좋은" 것인지 추측하려고 애쓸 필요가 없습니다. 저장소, 아키텍처, 그리고 지침이 이미 기대치를 정의하고 있기 때문입니다. 여러 면에서 AI 하네스는 승수 효과 (Force multiplier)를 일으킵니다.

어쩌면 우리는 잘못된 것을 최적화하고 있는지도 모른다

팀들이 일관되지 않은 AI 결과를 경험할 때, 가장 먼저 나오는 반응은 종종 _"더 큰 모델을 사용하자"_입니다. 때로는 그것이 옳은 결정일 수도 있지만, 저는 우리가 더 중요한 질문을 간과하고 있는 것은 아닌지 점점 더 의구심이 듭니다. 우리는 모델이 성공할 수 있는 올바른 환경을 구축했는가?

프롬프트 품질은 여전히 중요하다

이번 실험을 통해 얻은 또 다른 교훈은 작업의 명확성 (Task clarity)이 여전히 믿기지 않을 정도로 중요하다는 점입니다. 잘 설명된 작업은 플래그십 모델 (Flagship model)과 작은 모델 사이의 격차를 크게 줄일 수 있습니다. 리팩터링 (Refactoring), 테스트 작성, 문서 생성, 또는 알려진 패턴 구현과 같은 대부분의 일상적인 소프트웨어 엔지니어링 작업은 최첨단 연구 문제가 아닙니다. 이러한 작업에는 작은 모델만으로도 충분히 능력을 발휘할 수 있는 경우가 많습니다.

벤치마크가 아닌 결과물을 위한 최적화

AI 산업은 자연스럽게 지능(intelligence)에 집중하지만, 실제 운영 환경(production environments)에서의 질문은 _"어떤 모델이 벤치마크(benchmark)에서 가장 높은 점수를 받았는가?"_가 아닙니다. 질문은 다음과 같습니다:

작업이 완료되었는가?
결과물이 유지보수 가능한가?
프로젝트 표준(standards)을 준수했는가?
비용이 정당화되었는가?
팀이 경제적으로 사용량을 확장(scale)할 수 있는가?

때로는 사용 가능한 가장 진보된 모델을 사용하는 것이 답이 될 수도 있습니다. 하지만 점점 더 저는 더 나은 답이 다음과 같다는 것을 발견하고 있습니다: 문제를 안정적으로 해결할 수 있는 가장 저렴한 모델을 사용하라.

마치며

새로운 모델이 출시될 때마다 여전히 설레지만, 이번 실험은 목표가 가장 똑똑한 모델을 사용하는 것이 아니라 최선의 결과물을 얻는 것이라는 점을 다시 한번 상기시켜 주었습니다.

AI 산업은 모델의 지능을 논하는 데 많은 시간을 소비합니다. 저는 우리가 **하네스 품질 (harness quality)**을 논하는 데 더 많은 시간을 써야 한다고 생각합니다. 왜냐하면 가드레일(guardrails), 표준(standards), 그리고 컨텍스트(context)가 갖춰지면, 5.7배 더 저렴한 모델이 때로는 똑같이 좋거나 심지어 더 나은 결과를 전달할 수 있기 때문입니다.