이제 때가 됐다고 본다. 모델들이 일을 해내는 능력이 계속 좋아져, 이제 나오는 대부분의 신규 모델이 동작하는 코드를 작성할 수 있는 수준에 이르렀다. 이제는 모델이 아키텍처와 코드 품질을 좋게 만드는 벤치마크가 필요하다. DevBench나 ArchBench 같은 것이 말이다. 안타깝게도 이런 벤치마크는 다소 주관적이고 모호하다. 강화학습으로 만들 수 있겠지만, 이상적으로는 기계학습 연구자가 아닌 경험 많은 소프트웨어 엔지니어가 어딘가 루프에 참여하는 방식으로 신중하게 진행해야 할 것이다.

Claude Code가 실질적인 작업을 할 수 있게 된 이후로 이런 벤치마크를 기다려왔다. 내 생각에 벤치마크는 두 가지 장기 실행 부분으로 구성될 것이다. 정의된 기능 세트를 제공해야 하는 복잡한 멀티 모듈 시스템을 설계하고 만드는 것. 복잡도는 도메인 객체 곱하기 기능으로 측정하거나 벤치마크 제작자가 임의로 평가할 것이다. 시스템에 대한 모숩되고 상충하는 변경 사이클의 반복도 포함된다. 이것이 실제 프로덕션 IT 시스템이 감내해야 하는 현실이다. 즉 말이 되거나 안 되는 기묘하고 유동적인 비즈니스 요구사항이지만 비즈니스 쪽은 계속 밀어붙인다.

코드 품질은 충분히 주관적이다. 어차피 대부분의 모델은 각종 정적 분석을 통과할 것이다. 아마도 최선의 자동화/벤치마크 옵션은 가장 지능적인 상위 10개 모델 등으로 구성된 앙상블 LLM(또는 다른 유형의 모델)이 각기 여러 번(다른 시드/엔트로피) 실행한 평균 점수로 채점하는 방식일 것이다.

그렇다. 일부 모델은 '이 기능을 구현하라'고만 지시받는 것이 아니라 그 방향의 프롬프트와 여유가 주어지면 기술적으로 이미 좋은 아키텍처를 만들 수 있다고 생각한다. 관건은 좋은 관습을 모델의 기본 방식으로 실제로 내재화하는 것이다. 아직도 모델의 주석을 전반적으로 좋게 만들 마법의 단어는 찾지 못했다. 우리 팀은 AGENTS.md에 '주석을 쓰지 말라'고 넣어두고 필요한 곳에 사람이 주석을 달도록 하는 방안을 검토해왔다.

이게 어떻게 작동할지 모르겠다. 고객이 0명인 상태에서 MVP를 배포하려 할 때 Claude가 고도로 복잡한 이벤트 기반 마이크로서비스 아키텍처로 밀어넣을 필요는 없다. 제품을 최대한 빨리 출시하는 데 집중해야 한다. 실제로 필요해졌을 때 리팩토링하면 된다.