장기 실행 애플리케이션 개발을 위한 에이전트 운영 프레임워크 설계

Claude로 frontend design과 장기 자율 코딩의 품질을 함께 끌어올리기 위해, 생성과 평가를 분리한 multi-agent 구조를 설계했다. 핵심은 모델이 자기 작업을 지나치게 관대하게 평가하는 문제를 끊고, 외부 피드백을 반복 루프로 흘려보내는 데 있었다.

초기에는 context resets와 구조화된 handoff로 긴 작업에서 문맥 붕괴와 이른 종료 성향을 줄였다. 하지만 더 복잡한 과제에서는 여전히 성능 한계가 드러났고, 특히 자기 평가가 들어가는 순간 에이전트가 결과를 과대평가하는 문제가 반복됐다.

frontend 디자인에서는 이를 더 명확히 다뤘다. design quality, originality, craft, functionality 네 가지 기준을 만들고, 생성기와 평가기 모두 같은 기준으로 보게 했다. 이때 design quality와 originality를 더 높게 두어, 안전하고 평범한 기본형 대신 더 대담한 시각적 선택을 유도했다.

평가기에는 Playwright MCP를 붙여 실제 페이지를 직접 탐색하게 했고, 스크린샷만 보는 것이 아니라 클릭과 이동을 통해 구현을 검증하게 했다. 이 반복은 보통 5~15회 진행됐고, 한 번의 전체 세션은 최대 4시간까지 이어졌다. 반복이 거듭될수록 점수와 구현의 개성은 대체로 좋아졌지만, 마지막 결과보다 중간 결과가 더 마음에 드는 경우도 적지 않았다.

흥미로운 점은 평가 문구 자체가 결과물의 성격을 바꿨다는 것이다. 예를 들어 “museum quality” 같은 표현은 디자인을 특정 미학으로 수렴시키는 방향으로 작동했고, 한 사례에서는 네덜란드 미술관 사이트가 3D room과 체크무늬 바닥, 방 기반 내비게이션을 가진 공간형 경험으로 급격히 진화했다.

이 접근은 full-stack 개발로도 확장됐다. 최종 구조는 Planner, Generator, Evaluator의 3-agent 아키텍처였다.

• Planner: 1~4문장짜리 요청을 제품 명세로 확장하고, 구현 세부보다 제품 맥락과 고수준 설계에 집중한다.
• Generator: 한 번에 한 기능씩 sprint 단위로 구현한다. 스택은 React, Vite, FastAPI, SQLite(후에 PostgreSQL)였다.
• Evaluator: 실제 앱을 사용하듯 검증하며 UI, API, DB 상태를 점검하고, 기능성·시각적 완성도·코드 품질까지 기준에 따라 채점한다.

각 sprint가 시작되기 전에 생성기와 평가기가 sprint contract를 협상해 “완료”의 정의를 먼저 합의했다. 또한 모든 에이전트는 파일을 통해 상태를 넘겨받아 다음 세션이 이어받을 수 있게 했고, 이 구조 덕분에 장기 실행 작업에서도 맥락과 품질을 함께 유지할 수 있었다.