[강의 노트] 장기 실행 어플리케이션 개발을 위한 AI 하네스(Harness) 설계 전략
1. 서론: 단순 프롬프팅의 한계와 하네스 설계의 필요성
AI 에이전트 아키텍처를 설계하는 엔지니어로서 우리는 한 가지 명확한 진실을 마주하고 있습니다. 단순한 프롬프트 엔지니어링만으로는 Claude와 같은 최첨단 모델이 가진 잠재력의 ‘천장(Ceiling)‘을 뚫을 수 없다는 점입니다. 특히 복잡한 풀스택 어플리케이션을 빌드하거나 주관적인 미학적 완성도가 요구되는 영역에서 모델은 종종 일관성을 잃거나 평범한 결과물에 안주합니다.
이러한 병목을 해결하기 위한 전략적 선택이 바로 하네스(Harness) 설계입니다. 우리는 단순히 모델에게 명령을 내리는 것이 아니라, 모델이 최상의 성능을 낼 수 있도록 강제하는 ‘구조적 작업 환경’을 구축해야 합니다. 본 강의에서는 주관적 취향(디자인)과 객관적 정확성(코딩)을 모두 정복하기 위해 GAN(Generative Adversarial Networks) 에서 영감을 얻은 ‘생성자-평가자’ 구조를 활용하여, 장기 실행(Long-running) 에이전트의 한계를 극복하는 아키텍처를 분석합니다.
2. 나이브(Naive) 구현의 주요 실패 모드 분석
모델이 복잡한 작업에서 이탈하는 원인은 단순한 지능 부족이 아니라, 아키텍처 부재로 인한 ‘심리적/기술적 결함’에 있습니다.
2.1 문맥 불안(Context Anxiety)과 모델별 대응 전략
컨텍스트 윈도우가 채워질 때 모델이 작업을 성급하게 마무리하거나 지시사항을 누락하는 현상을 ‘문맥 불안’ 이라 정의합니다.
- Claude Sonnet 4.5: 이 모델에서는 문맥 불안이 강하게 나타나므로, 컨텍스트를 완전히 비우고 ‘구조화된 아티팩트’를 통해 상태를 전달하는 ‘컨텍스트 리셋(Reset)’ 이 필수적이었습니다.
- Claude Opus 4.5/4.6: 최신 모델은 긴 문맥 유지 능력이 비약적으로 향상되었습니다. 따라서 리셋 대신 ‘자동 압축(Compaction)’ 을 통해 연속성을 유지하면서도 불안 증세를 극복할 수 있게 되었습니다. 엔지니어는 모델 버전에 따라 이 리셋과 압축의 트레이드오프를 결정해야 합니다.
2.2 자기 평가의 한계와 ‘회의적 평가자’의 도입
LLM은 자신이 생성한 결과물에 대해 비정상적으로 관대한 경향이 있습니다. 특히 디자인처럼 정답이 없는 영역에서 “이 정도면 훌륭하다”라고 스스로를 설득하며 타협합니다.
- 전략적 해법: 생성자와 평가자를 완전히 분리해야 합니다. 모델은 타인의 작업을 비판할 때 훨씬 더 날카로운 통찰을 보여줍니다. 우리는 평가자에게 **‘회의적 페르소나(Skeptical Persona)‘**를 부여하여, 모델이 스스로를 방어하려는 심리를 차단하고 생성자가 지속적으로 한계에 도전하도록 강제해야 합니다.
3. 프런트엔드 디자인: 주관적 품질의 정량화 및 피드백 루프
미학적 품질을 정량화하는 것은 하네스 설계의 핵심입니다. 모호한 “아름다움”을 측정 가능한 “지표”로 치환하는 과정을 살펴봅니다.
3.1 4대 평가 기준 (Grading Criteria)
- 디자인 품질(Design Quality): 구성 요소의 파편화가 아닌, 색상/타이포그래피/레이아웃이 하나의 정체성을 형성하는가?
- 독창성(Originality): ‘AI Slop(예: 흰색 카드 위의 보라색 그라데이션)‘과 같은 뻔한 패턴을 지양하고, 의도적인 창의적 선택이 보이는가?
- 기술적 정밀도(Craft): 간격(Spacing), 대비(Contrast), 계층 구조 등 기본기가 견고한가?
- 기능성(Functionality): 사용자가 인터페이스를 직관적으로 이해하고 목적을 달성할 수 있는가?
3.2 평가자 보정(Calibration) 및 동적 테스트
- Few-shot 교정: 상세한 점수 분석 예시를 통해 평가자의 ‘취향’을 인간 설계자의 기준에 정렬시킵니다.
- Playwright MCP 활용: 평가자는 정적 스크린샷이 아니라, 실제 페이지를 클릭하고 탐색하며 인터랙션의 깊이를 테스트합니다. 이는 정적인 시각 평가를 넘어선 ‘경험적 평가’를 가능케 합니다.
3.3 창의적 도약의 메커니즘
5~15회의 반복 루프는 단순히 버그를 잡는 과정이 아닙니다. 네덜란드 미술관 사례에서 보듯, 9회차까지 평범한 다크 모드였던 디자인이 10회차에서 **‘3D CSS 공간 경험’**으로 완전히 재창조되는 ‘창의적 도약’은 오직 집요한 피드백 루프 안에서만 발생합니다.
4. 풀스택 코딩을 위한 3-에이전트 아키텍처
4.1 Planner (기획자): 연쇄적 오류(Cascading Errors) 방지
기획자는 모호한 프롬프트를 상세 제품 명세서(Spec)로 확장합니다.
- 핵심 통찰: 기획자는 세부적인 기술 구현(Granular Technicals)보다는 제품의 컨텍스트와 야망 있는 기능 범위에 집중해야 합니다. 초기에 기술적 세부사항을 잘못 정의하면 하위 단계에서 수정 불가능한 연쇄적 오류가 발생하기 때문입니다.
4.2 Generator (생성자): 스프린트와 버전 관리
기획된 명세를 스프린트 단위로 나누어 구현합니다. React, FastAPI 스택을 활용하며, 각 작업 단계마다 Git을 사용하여 버전 간 일관성을 유지합니다.
4.3 Evaluator (평가자): 협상 기반의 완료 정의
- 스프린트 계약(Sprint Contract): 작업 시작 전, 생성자와 평가자는 ‘무엇이 완료인가’에 대해 **협상(Negotiation)**합니다. 평가자는 생성자의 제안을 검토하고, 합의된 테스트 기준이 수립될 때까지 반복 소통합니다.
- 회의적 튜닝(Skeptical Tuning): 평가자는 사용자의 관점에서 Playwright를 통해 시스템을 ‘공격’하듯 테스트하며, 하드 임계값(Hard Threshold)을 적용해 엄격하게 통과 여부를 결정합니다.
5. 실전 사례 분석 및 데이터 검증
5.1 비교 데이터 분석: 레트로 게임 메이커 (V1 Harness / Opus 4.5)
| 구분 | Solo 실행 (Baseline) | Full Harness (V1) |
| 소요 시간 | 20분 | 6시간 |
| 비용 | $9 | $200 |
| 기능 구현 | 기본 UI 구성, 실제 작동 불가 | 16개 기능 구현, AI 엔진 포함, 실제 플레이 가능 |
| 주요 결함 | 런타임 오류, 캐릭터 이동 불가 | 일부 물리 엔진 오차 제외 완벽 작동 |
분석: 하네스는 비용을 20배 증가시키지만, ‘동작하지 않는 쓰레기’를 ‘비즈니스 가치가 있는 제품’으로 전환시키는 유일한 방법입니다.
5.2 평가자가 발견한 구체적 기술 실패 사례
- Rectangle fill tool: 드래그 시 시작점과 끝점에만 타일이 찍히는 논리 오류 적발.
- Delete key handler: 조건문(
selection || selectedEntityId)의 누락으로 인해 특정 상황에서 객체 삭제가 불가능한 버그 식별. - API Route Matching (핵심 사례): FastAPI에서
PUT /frames/reorder경로가 정수형 ID 경로 뒤에 배치되어, ‘reorder’를 정수로 인식해 발생하는 422 Validation Error 포착.
6. 하네스 설계의 진화: 모델 발전과 복잡성의 최적화
모델의 지능이 향상됨에 따라 AI 엔지니어의 역할은 ‘불필요한 스캐폴딩을 제거하는 것’으로 변화합니다.
6.1 Opus 4.6 기반 아키텍처 슬림화
Claude 4.6은 더 긴 시간 동안 에이전트 태스크를 유지할 수 있습니다. 이에 따라 복잡한 ‘스프린트 구조’를 제거하고도 높은 성능을 낼 수 있게 되었습니다.
6.2 DAW(Digital Audio Workstation) 사례 분석 (V2 Harness / Opus 4.6)
- 데이터: 총 소요 시간 약 4시간, 비용 $124.70.
- 성과: 2시간 이상의 연속 빌드를 통해 브라우저 기반 음악 제작 프로그램 구축. 녹음 기능의 스터브(Stub) 처리와 같은 세밀한 누락을 평가자가 최종적으로 잡아냄.
6.3 전략적 임무: 경계의 이동 (The Next Frontier)
하네스는 고정된 장치가 아닙니다. 모델의 내재된 능력(Native Capability)이 확장되면, 기존의 하네스 요소는 ‘불필요한 오버헤드’가 됩니다. 우리의 임무는 모델이 스스로 할 수 있게 된 영역의 스캐폴딩을 과감히 철거하고, 모델이 여전히 정복하지 못한 ‘다음 경계(Next Frontier)‘로 하네스를 이동시켜 더 고차원적인 복잡성을 해결하는 것입니다.
7. 핵심 요약 및 체크리스트
Strategic “So What?”
- 비즈니스 측면: 9를 들여 쓰레기를 만드는 것보다 훨씬 경제적입니다.
- 기술적 측면: 하네스는 모델의 ‘문맥 불안’과 ‘자기 평가 편향’을 제어하는 제어 시스템입니다.
성공적인 하네스 설계를 위한 체크리스트
- 모델별 컨텍스트 전략: Sonnet 4.5라면 ‘리셋’을, Opus 4.6이라면 ‘자동 압축’을 적용했는가?
- 회의적 평가자: 평가자가 생성자의 결함을 찾아내도록 ‘회의적 페르소나’와 ‘Few-shot’으로 튜닝되었는가?
- 협상 프로세스: 생성자와 평가자가 작업을 시작하기 전 ‘완료의 정의(Contract)‘에 합의하는가?
- 연쇄 오류 방지: 기획자(Planner)가 지나치게 세부적인 기술 사양에 매몰되어 하위 에이전트의 유연성을 차단하고 있지 않은가?
- 스캐폴딩 최적화: 최신 모델의 능력 향상에 맞춰 제거할 수 있는 복잡한 구조가 있는가?