LLM으로 소프트웨어를 만드는 방법

하네스 도구 (Harness)

OpenCode / Pi

 

- 하네스의 필수 요건 두 가지

여러 회사의 다양한 모델 사용 가능

커스텀 에이전트가 서로 자율적으로 호출 가능

 

 

 

 

 

복수 모델 사용의 필요성

특정 모델을 한 사람이 간주할 수 있으며, 컨텍스트를 초기화해도 같은 의견, 강점, 약점을 유지하는 경향

모델에게 자기가 쓴 코드를 리뷰하게 하면 자기 동의 경량이 있어 거의 무의미 하지만, 다른 모델에게 리뷰를 맡기면 품질이 크게 향상됨

 

Codex 5.4는 꼼꼼하고 까다로워서 리뷰에 적합. Opus 4.6은 본인이 내렸을 결정과 잘 일치, Gemini 3 Falsh도 다른 모델이 놓친 해법을 제시하는 경우 있음

 

최적의 결과를 위해 모든 모델의 혼합 사용이 필요

 

 

 

 

 

워크 플로우

아키텍트 > 개발자 > 리뷰어

 

워크 플로우는 아키텍트, 개발자, 1~3명의 리뷰어로 구성, 이들은 OpenCode 에이전트 (스킬 파일)로 설정됨

 

- 복수 에이전트 사용의 세 가지 이유

비싼 모델 (Opus)는 계획 수립에, 저렴한 모델 (Sonnet)은 코드 작성에 사용하여 토큰 절약

서로 다른 모델로 리뷰하여 각기 다른 문제를 포착

역할별 권한 분리 가능 (읽기 전용, 쓰기 가능 등)

 

스킬 파일은 직접 수작업으로 작성 (LLM이 작성하면 무의미)

 

 

 

 

 

아키텍트 역할

아키텍트 (Opus 4.6)은 유일하게 직접 대화하는 에이전트이며 가장 강력한 모델이어야 함

매우 구체적인 기능이나 버그 수정 목표를 제시하고, 목표, 제약, 트레이드 오프를 확정할 때까지 최대 30분간 대화 진행

 

결과물은 개별 파일과 함수 수준의 상당히 저수준의 계획

 

단순 프롬프팅이 아니라 LLM의 도움으로 계획을 형성하는 과정

LLM이 틀리거나 본인 방식과 다를 때 많이 교정하며, 이 것이 프로젝트를 "자기 것"으로 만드는 핵심 기여

 

"apporved" 라는 단어를 명시적으로 말할 때까지 구현을 시작하지 않도록 설정

일부 모델은 스스로 이해했다고 판단하면 성급하게 구현에 착수하는 경향을 가짐

 

승인 후 아키텍트가 작업을 태스크로 분할하여 계획 파일에 상세히 기록하고 개발자를 호출

 

 

 

 

 

개발자 역할

개발자는 더 약하고 토큰 효율적인 모델 (Sonnet 4.6) 사용 가능

계획이 재량의 여지를 최소화하므로, 역할은 엄격하게 계획의 변경사항을 구현하는 것

구현 완료 후 리뷰어를 호출

 

 

 

 

 

 

리뷰어 역할

각 리뷰어가 독립적으로 계획과 diff를 검토하고 비평

최소 Codex를 항상 사용하고, 때로 Gemini 추가, 중요 프로젝트에는 Opus도 추가

피드백은 개발자에게 돌아가며, 리뷰어 간 불일치 시 아키텍트에게 에스컬레이션

Opus는 올바른 피드백을 선택하는데 뛰어나며, 너무 까다로운 (구현 대비 실질적 문제 가능성이 낮은) 피드백은 무시하기도 함

 

 

 

 

 

 

 

Reference

https://news.hada.io/topic?id=27576

내가 LLM으로 소프트웨어를 만드는 방법 | GeekNews