LLM으로 소프트웨어를 만드는 방법 - 아키텍트-개발자-리뷰어 다중 에이전트 워크플로우
목차
개요
Stavros가 공개한 LLM 기반 소프트웨어 개발 방법론을 정리한다. 핵심은 아키텍트-개발자-리뷰어로 구성된 다중 에이전트 시스템을 운영하여 수만 줄 규모의 프로젝트를 낮은 결함률로 유지하는 것이다. 저자는 “프로그래밍의 즐거움보다 무언가를 만드는 것에 관심이 있었고, LLM이 그것을 가능하게 했다”고 말한다.
배경
LLM 모델의 코드 품질은 세대를 거듭하며 극적으로 향상되었다. 초기에는 모든 코드 라인을 하나하나 검토해야 했지만, 현재 Opus 4.6 수준에서는 아키텍처 수준에서만 확인하면 충분하다. 이제 코드 작성 능력보다 시스템 아키텍처 설계와 올바른 기술적 선택을 내리는 엔지니어링 스킬이 훨씬 중요해졌다.
핵심 내용
3단계 에이전트 시스템
저자는 아키텍트, 개발자, 리뷰어 세 역할을 분리한 다중 에이전트 시스템을 운영한다.
| 역할 | 모델 | 담당 업무 |
|---|---|---|
| 아키텍트 | Claude Opus 4.6 | 사용자와 직접 대화하며 상세한 설계 계획 수립 |
| 개발자 | Claude Sonnet 4.6 | 아키텍트의 계획을 엄격하게 구현 |
| 리뷰어 | Codex, Gemini, Opus 혼합 | 독립적으로 코드 검토 및 비평 |
복수 모델을 사용하는 이유는 세 가지다. 첫째, 토큰 비용을 절약할 수 있다. 둘째, 서로 다른 모델이 서로 다른 문제를 포착한다. 셋째, 역할별 권한 분리가 가능하다.
아키텍트는 독립적인 고수준 결정을 내릴 수 없고, 반드시 사용자의 “approved” 확인을 받아야 진행한다. 개발자는 아키텍트가 정의한 태스크만 구현하며 독립적인 설계 결정을 하지 않는다. 리뷰어는 구현 세부사항을 모르는 상태에서 독립적으로 검토한다.
실제 사례 - 이메일 기능 추가
Stavrobot이라는 개인 LLM 어시스턴트에 이메일 지원을 추가한 과정이 공개되었다. 초기 대화에서 아키텍트가 “인바운드 방식인지, 양방향 여부, 첨부파일 처리 방법” 등 설계 질문을 제시했다. 저자와 약 30분간 협의한 후 6개 태스크로 분할하여 약 1시간 만에 완성했다. 와일드카드 이메일 매칭을 통한 도메인 수준 허용 목록 기능도 구현되었다.
이 방식으로 만든 프로젝트들
| 프로젝트 | 설명 |
|---|---|
| Stavrobot | 캘린더, 리서치, 리마인더를 관리하는 개인 LLM 어시스턴트 |
| Middle | 음성 메모 펜던트와 트랜스크립션 |
| Sleight of Hand | 불규칙하게 째깍거리는 예술적 벽시계 |
| Pine Town | 멀티플레이어 협업 드로잉 캔버스 |
의미와 시사점
이 워크플로우의 성공 요인은 네 가지로 정리된다. 코딩 전에 강력한 아키텍처 이해를 확보하는 것이 첫 번째다. 일관된 리뷰 패턴으로 다양한 오류 클래스를 포착하는 것이 두 번째다. 원샷 프롬프팅이 아닌 반복적 대화를 통해 요구사항을 정제하는 것이 세 번째다. 도메인 전문성으로 LLM의 의사결정을 안내하는 것이 네 번째다.
반면 실패하는 경우도 명확하다. 개발자가 기반 기술을 이해하지 못하면 아키텍처 실수가 반복을 거듭하며 누적된다. 이는 LLM이 코딩을 대신해도 엔지니어링 역량이 여전히 핵심이라는 점을 보여준다.
한국어 커뮤니티에서는 모델별 역할 배분에 대한 논의가 있었다. 일부는 “계획은 저렴한 모델, 구현은 고급 모델”을 사용하는 반면, 저자는 반대 방식을 택했다. “내가 필요한 커스텀 도구를 손쉽게 만들어 생산성을 높이는 것”이 현재 시대의 가치라는 평가도 나왔다.
결론
LLM으로 소프트웨어를 만드는 핵심은 코드 작성이 아니라 아키텍처 설계에 있다. 다중 에이전트 시스템에서 각 역할을 명확히 분리하고, 반복적 대화를 통해 요구사항을 정제하면 수만 줄 규모의 프로젝트도 낮은 결함률로 유지할 수 있다. 도구가 필수적으로 지원해야 할 기능은 서로 다른 제공자의 복수 모델 동시 사용과 에이전트 간 자율적 통신이다.