핵심 요약
장시간 자율 코딩의 성패는 "모델이 잘하길 바라는 것"이 아니라, 잘할 수밖에 없게 만드는 하네스(오케스트레이션 + 피드백 구조) 설계에 달려 있다.
주관적인 디자인 품질과 객관적인 소프트웨어 품질 모두에서, 생성(Generator)과 평가(Evaluator)를 분리하고 기준을 명시하면 반복 개선 루프가 강력해진다.
모델이 좋아질수록 하네스는 사라지기보다 "필요한 지점"으로 이동하므로, 지속적으로 단순화/강화 요소를 재검증해야 한다.
왜 '그냥 한 에이전트로 오래 돌리기'가 무너지는가
장시간 작업에서 흔한 첫 번째 붕괴 원인은 문맥이 길어지며 작업 일관성이 떨어지는 것이다. 컨텍스트 창이 차면서 앞서 한 결정이 뒤엉키고, 어떤 모델은 한계가 다가온다고 "느끼면" 일을 서둘러 마무리하려는 경향(일종의 컨텍스트 불안)을 보인다.
이를 막는 방법은 크게 두 가지다. 대화를 요약해 같은 에이전트가 계속 가게 만드는 "압축(컴팩션)"은 연속성은 지키지만, 불안 자체를 완전히 없애진 못한다. 반면 "리셋"은 새 에이전트를 띄워 깨끗한 상태로 다시 시작하되, 상태를 넘겨줄 구조화된 인수인계 산출물이 필요하다. 리셋은 효과가 크지만 오케스트레이션 복잡도와 토큰/지연 비용을 추가로 만든다.
두 번째 붕괴 원인은 자기평가의 관대함이다. 에이전트는 자신이 만든 결과를 평가하라고 하면, 실제 품질이 평범하거나 결함이 있어도 "괜찮다"고 결론내리기 쉽다. 디자인처럼 정답이 없는 영역에서는 특히 심하고, 테스트가 있는 코딩에서도 "이 정도면 됐지" 같은 나쁜 판단이 성능을 갉아먹는다.
결론은 단순하다. 만드는 역할과 판단하는 역할을 분리해야 한다. 생성기에게 "스스로 냉정해져라"를 요구하는 것보다, 독립 평가자를 "의심 많은 심사자"로 튜닝하는 편이 훨씬 쉽다.
GAN에서 빌린 핵심: 생성기-평가자 루프
이 글의 중심 아이디어는 GAN의 직관을 엔지니어링 방식으로 가져오는 것이다. 생성기는 결과물을 만들고, 평가자는 기준에 따라 채점/비평하며, 생성기는 그 피드백을 받아 다음 버전을 만든다.
이 구조의 장점은 "막연한 개선"이 아니라 "특정 기준을 만족시키는 개선"이 반복된다는 데 있다. 피드백이 구체적일수록 생성기는 더 빠르게 수렴하고, 평가자가 독립적일수록 '봐주기'가 줄어든다.
다만 평가자도 LLM이므로 기본 성향은 관대할 수 있다. 그래서 평가자에는 예시(퓨샷)와 점수 분해를 넣어 채점 습관을 교정하고, 무엇을 중시하는지(가중치)를 명시해 일관성을 만든다.
주관적 미감을 '채점 가능'으로 바꾸는 디자인 기준 4종
"이 디자인 예뻐?"는 사람마다 달라 채점이 흔들린다. 대신 "좋은 디자인 원칙을 충족하나?"로 바꾸면 평가가 가능해진다. 이를 위해 4개 축을 만든다: 전체적인 디자인 완성도(일관된 무드/정체성), 독창성(템플릿/기본 컴포넌트 느낌 탈피), 공예적 완성(타이포·간격·대비 같은 기본기), 기능성(사용성).
핵심은 가중치다. 모델은 기본적으로 기능성과 기본기는 무난히 달성하는 경향이 있으니, 실제로 부족한 '완성도'와 '독창성'에 더 큰 벌점/보상을 걸어야 출력이 안전지대에서 벗어난다. 흔한 "AI스러운 전형"을 명시적으로 감점 대상으로 넣는 것도 같은 이유다.
이 기준을 생성기와 평가자 모두에게 주면, 생성기는 처음부터 방향성이 생겨 베이스라인이 올라가고, 평가자 피드백이 들어오면 반복마다 더 과감한 탐색(때로는 미드-코스의 큰 방향 전환)까지 유도된다. 한 예로, 미술관 웹사이트가 반복 끝에 단순 랜딩 페이지를 넘어 CSS 3D 공간 갤러리로 '도약'하는 식의 변화가 나온다.
평가자는 '스크린샷 심사'가 아니라 '직접 조작'이어야 한다
디자인 평가에서 중요한 장치가 하나 더 있다. 평가자가 정지 이미지 한 장만 보고 판단하면, 상호작용/레이아웃/상태 변화에서 드러나는 품질을 놓친다.
그래서 평가자에게 Playwright 같은 브라우저 자동화 도구를 붙여 실제 페이지를 탐색하게 한다. 평가자는 스스로 클릭하고 이동하며 화면을 관찰한 뒤, 기준별 점수와 상세 비평을 작성한다. 이 방식은 벽시계 시간이 길어지는 단점이 있지만, 평가의 신뢰도가 올라가고 피드백이 "수정 가능한 지적"으로 바뀐다.
풀스택으로 확장: 플래너·생성기·평가자 3인조
프론트엔드 디자인에서 검증한 패턴은 풀스택 개발에도 자연스럽게 이어진다. 코드 리뷰와 QA는 구조적으로 디자인 평가자와 같은 역할이기 때문이다.
여기서 아키텍처는 3개 페르소나다. 플래너는 1~4문장짜리 요청을 "충분히 큰" 제품 스펙으로 확장한다. 단, 너무 이른 구현 세부사항을 박아두면 틀린 결정이 아래로 전염되므로, 플래너는 제품 맥락과 큰 설계를 중심으로 쓰게 하고 구현은 여지를 남긴다. 또한 AI 기능을 제품에 섞을 기회를 적극적으로 찾게 만든다.
생성기는 스펙을 바탕으로 기능을 단계적으로 구현한다(초기 버전은 스프린트 단위). 평가자는 실제 실행 중인 앱을 Playwright로 조작하며 UI/API/DB까지 사용자의 관점에서 검증한다. 그리고 기능성, 제품 깊이, 시각 디자인, 코드 품질 같은 기준을 임계값으로 채점해, 하나라도 미달이면 실패 처리하고 구체적 수정 지시를 준다.
'스프린트 계약'으로 스펙과 테스트를 연결하기
스펙을 의도적으로 고수준으로 쓰면, "뭘 만들면 완료인지"가 애매해진다. 이 간극을 메우는 장치가 스프린트 계약이다.
각 스프린트 시작 전에 생성기와 평가자가 "이번 덩어리에서 무엇이 완료인지"를 협상한다. 생성기가 구현 계획과 검증 방법을 제안하면, 평가자가 "그게 스펙에 맞는지, 테스트 가능한지"를 점검한다. 합의된 뒤에만 코드를 쓰게 하면, 결과물이 스펙에서 이탈하거나 '보여주기용'으로 끝나는 확률이 줄어든다.
에이전트 간 의사소통을 파일 기반 산출물로 고정하면(한쪽이 파일 작성, 다른 쪽이 읽고 수정/추가), 컨텍스트가 흔들려도 작업 상태가 명시적으로 남아 장기 실행에 유리해진다.
비용 대비 품질: "혼자 20분" vs "하네스 6시간"
단일 에이전트로 빠르게 만든 앱은 겉보기엔 그럴듯해도, 실제로 써보면 핵심 기능이 깨지는 경우가 잦다. 반대로 플래너-생성기-평가자 하네스는 훨씬 비싸고 오래 걸리지만, 스펙 확장(더 많은 기능)과 실제 동작(플레이 가능한 수준)에서 차이가 크게 난다.
이 차이를 만든 결정적 요소는 평가자의 "실제 조작 기반 QA"와 "계약 기반 완료 정의"다. 평가자는 드래그/키 입력/라우팅/DB 상태 같은 구체 행동으로 버그를 적발하고, 실패 원인을 코드 위치 수준으로 적어 생성기가 바로 고치게 만든다.
QA 평가자도 튜닝이 필요하다: '봐주기'와 '피상 테스트' 제거
LLM은 기본적으로 QA에 약하다. 초기에 평가자는 문제를 발견하고도 "큰 문제 아니다"라고 스스로 합리화하며 통과시키거나, 얕게 클릭 몇 번만 하고 끝내기 쉽다.
개선 방법은 단순 반복이다. 평가 로그를 읽고, 사람의 판단과 어긋난 사례를 모아 프롬프트를 수정한다. 이 루프를 여러 번 돌리면 평가자는 더 집요해지고, 엣지 케이스를 더 자주 건드리며, "통과 기준"이 안정된다. 그래도 완벽하진 않아서 미세한 UX 문제나 깊은 기능의 버그는 남을 수 있고, 이는 추가 튜닝 여지로 남는다.
모델이 좋아지면 하네스를 '덜어내야' 한다: 스프린트 제거 사례
하네스의 각 구성 요소는 "모델이 혼자 못 하는 것"에 대한 가정이다. 모델이 발전하면 그 가정이 틀어지고, 불필요한 장치가 비용만 늘린다. 그래서 새 모델이 나오면 하네스를 스트레스 테스트하고, 짐이 된 부분을 떼어내는 재설계가 필요하다.
예로 더 강해진 모델에서는 스프린트 분해 없이도 2시간 넘게 일관된 빌드가 가능해져, 스프린트 구조를 제거하고 평가도 매 스프린트가 아니라 "마지막에 한 번"으로 줄일 수 있었다. 다만 평가자가 완전히 불필요해지는 건 아니다. 과제가 모델의 신뢰 경계 밖에 걸릴 때(예: 핵심 상호작용이 자꾸 스텁으로 남는 경우) 평가자는 여전히 값비싼 보험이 된다.
AI 기능을 '버튼'이 아니라 '도구 쓰는 에이전트'로 만들기
앱에 AI를 얹는다고 해서 단순히 "프롬프트 입력 → 텍스트 출력"이면 제품 기능과 분리된 장식이 되기 쉽다. 이 하네스는 생성기에게 앱 내부 도구를 실제로 호출해 기능을 수행하는 에이전트를 만들도록 유도했고, 이는 최신 지식/패턴이라 추가 프롬프트 튜닝이 필요했다.
충분히 다듬으면, 에이전트가 템포/키 설정, 트랙 생성, 편곡 같은 앱의 핵심 조작을 자율로 수행하는 수준까지 도달한다(단, 청각처럼 모델이 본질적으로 못 하는 감각은 QA/품질 루프에 한계가 남는다).
인사이트
하네스 설계는 "에이전트가 똑똑해지길 기도하는 일"이 아니라, 역할 분리(생성/판정), 기준의 명문화(채점 가능한 언어), 실제 실행 기반 검증(브라우저/도구), 그리고 완료 정의의 계약화로 성능을 구조적으로 끌어올리는 일이다.
새 모델이 나올 때마다 하네스는 반드시 재점검하라. 어떤 장치는 이제 필요 없을 수 있고(비용 절감), 어떤 장치는 여전히 경계 영역에서 결정적일 수 있다(품질 보증).
실천 팁은 간단하다. 먼저 "무엇이 좋은 결과인지"를 3~5개 기준으로 문장화하고, 생성기와 분리된 평가자에게 도구(브라우저/테스트/린터)를 쥐여 준 뒤, 실패 시 바로 수정 가능한 수준의 피드백 포맷을 강제하라.
출처 및 참고 : Harness design for long-running application development \ Anthropic
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.