Claude 장시간 코딩 흔들림, Harness로 잡기

제목: Claude가 오래 일하면 흐트러지는 이유, Anthropic이 제안한 Harness 디자인이 해답이에요

Claude로 코딩을 길게 돌리다 보면, 처음엔 똑똑했는데 뒤로 갈수록 맥락이 흔들리거나 결과물이 “그럴듯한데 별로”인 순간이 오죠.
Anthropic은 이 문제를 정면으로 다루면서, **장시간 작업을 안정적으로 굴리는 Harness(에이전트 협업 구조)**를 공개했어요.

1) 장시간 코딩에서 터지는 두 문제: Context anxiety & Self-evaluation bias

요약하면 Anthropic이 본 핵심 문제는 2가지예요. 오래 일할수록 모델이 스스로 무너지는 패턴이 반복된다는 거죠.
이걸 단순히 “프롬프트를 더 잘 쓰자”로 해결하기 어렵기 때문에, 구조적으로 잡는 접근을 택합니다.

• Context anxiety(맥락 불안): 작업이 길어질수록 앞뒤 일관성이 깨지고, 이전 결정을 잊거나 충돌하는 설계를 내요. 특히 UI/UX나 아키텍처처럼 누적 의사결정이 중요한 작업에서 치명적이에요.
• Self-evaluation bias(자기평가 편향): 결과가 별로여도 모델이 스스로 “잘 됐습니다”라고 칭찬하는 경향이 있어요. 이러면 사용자는 신뢰하기 어렵고, 수정 루프도 약해집니다.

즉, 문제는 “능력 부족”이라기보다 장시간 실행 환경에서의 품질 관리 메커니즘 부재에 가까워요.

2) 해결책: 여러 에이전트로 나누는 Harness, GAN에서 아이디어를 가져오다

요약하면 Harness는 Claude를 1명으로 쓰지 않고, 역할이 다른 여러 에이전트가 서로 견제하며 결과를 다듬는 구조예요.
Anthropic은 이를 설명하면서 GAN(Generative Adversarial Networks, 생성자-판별자 구조)의 아이디어를 참고했다고 말합니다.

구성은 크게 이렇게 잡아요.

• Generator(생성자): 코드/디자인을 실제로 만들어내는 역할이에요. 빠르게 초안을 만들고, 요구사항을 구현합니다.
• Evaluator(평가자): 생성 결과를 “좋다”가 아니라 냉정하게 깨는 역할을 맡아요. 버그, 설계 결함, UX 어색함 같은 걸 집요하게 지적합니다.

이 구조가 중요한 이유는, 장시간 작업에서 가장 위험한 순간이 “그럴듯한 결과물이 나왔고, 모델도 잘했다고 말하는” 지점인데요. Evaluator가 있으면 자기만족 루프를 끊고 품질 기준을 강제할 수 있어요.

3) 프론트엔드 품질을 올리는 방법: 4가지 스코어링 기준 + 5~15회 리비전

요약하면 Anthropic은 프론트엔드에서 흔히 나오는 “다 비슷비슷한 안전한 디자인”을 피하려고, 평가 기준 자체를 UI 미감/창의성에 맞춰 설계했어요.
그 결과, 단발성 출력보다 **5~15번 반복 개선(revision)**을 돌릴 때 훨씬 예쁘고 유니크해졌다고 합니다.

핵심은 Evaluator가 점수로 평가하도록 만든 4가지 스코어링 기준이에요. 여기서 중요한 포인트는 “기능만 맞으면 OK”가 아니라, 미학(aesthetics)과 창의성(creativity)을 강조해서 제너릭한 결과를 의도적으로 떨어뜨린다는 점입니다.

실제 사용 시나리오는 이렇게 잡아볼 만해요.
예를 들어 랜딩 페이지를 만든다면 Generator가 구조/컴포넌트를 만들고, Evaluator는 “너무 흔한 카드 UI다”, “타이포 계층이 약하다”, “브랜드 톤이 없다”처럼 디자인 피드백을 강제해요. 그러면 1회차는 평범해도, 반복하면서 결과물이 눈에 띄게 좋아지는 흐름을 만들 수 있어요.

4) 풀스택은 3인조로: Planner - Generator - Evaluator가 안정적이에요

요약하면 풀스택은 프론트보다 변수(데이터 모델, API, 상태, 예외, 배포 등)가 많아서, 단순 생성/평가만으로는 방향성이 흔들릴 수 있어요.
그래서 Anthropic은 Planner(기획/설계)를 추가한 3에이전트 구조를 권합니다.

• Planner: 요구사항을 작업 단위로 쪼개고, 아키텍처/우선순위를 잡아요. 장시간 작업에서 “지금 뭘 하고 있었지?”를 방지하는 핵심 역할입니다.
• Generator: Planner의 계획을 따라 구현하고, 실행 가능한 결과물을 냅니다.
• Evaluator: 테스트 관점/사용자 관점/보안 관점에서 결함을 공격적으로 찾고 재작업을 요구합니다.

실제로 사이드 프로젝트로 웹앱을 만드는 상황을 떠올리면, 혼자 코딩하는 Claude는 속도는 빠르지만 중간에 설계가 바뀌거나 예외 처리가 누락되는 경우가 많아요. Planner가 있으면 최소한 “이 앱의 뼈대”가 유지되고, Evaluator가 있으면 “작동은 하는데 불안한 앱”에서 벗어나기 쉬워요.

5) 같은 게임 요구사항 비교: 단독 실행 vs Harness, 속도 대신 ‘완성도’가 달라져요

요약하면 Anthropic이 보여준 비교는 현실적이에요. 혼자 돌리면 빠르지만 버그가 심각하고, Harness를 쓰면 시간/비용은 늘지만 품질이 크게 올라간다는 결론이죠.
특히 “플레이 가능한 게임 + 예쁜 UI + 추가 AI 지원”처럼 결과물의 완성도가 확 달라졌다고 합니다.

정리하면 이런 트레이드오프예요.

• Claude 단독: 빠르고 싸지만, 큰 작업에서 심각한 버그/누락이 터지기 쉽습니다. 일관성 유지와 자체 검증이 약하니까요.
• Harness 사용: 더 오래 걸리고 비싸지만, 버그 감소 + UI 품질 상승 + 전체 경험 개선이 가능합니다.

팀 개발에서도 비슷해요. 급하게 MVP를 찍을 때는 단독도 가능하지만, 데모/론칭처럼 “보여줘야 하는 결과물”이라면 Harness가 오히려 비용 대비 효율이 나올 수 있어요.

6) 모델이 강해질수록 Harness는 ‘덜어내기’가 필요해요 (Opus 4.6 예시)

요약하면 Anthropic은 Harness를 만능으로 보지 않아요. 모델이 강해질수록, 예전엔 필요했던 장치가 오히려 오버헤드가 될 수 있다고 말합니다.
예시로 “Opus 4.6처럼 더 강해지면 불필요한 요소는 제거하라”는 제안이 나와요.

이 관점이 중요한 이유는, 결국 Harness도 토큰/시간/비용을 먹는 구조이기 때문이에요. 모델이 자체적으로 맥락 유지나 자기비판을 더 잘하게 되면, 평가 루프를 줄이거나 에이전트 수를 줄이는 식으로 최적화하는 게 합리적이죠.
즉, Harness는 고정된 템플릿이 아니라 모델 역량에 맞춰 조절하는 운영 도구라고 보는 게 맞아요.

마무리: Claude로 “큰 작업”을 한다면, 이제는 구조를 바꿔볼 타이밍이에요
긴 코딩 세션에서 흔들리는 맥락과 과한 자기만족은, 능력 문제가 아니라 프로세스 문제일 때가 많아요. Anthropic의 Harness는 그 프로세스를 “다중 역할/상호 견제”로 바꾸는 실전적인 방법이고요.

지금 Claude로 사이드 프로젝트나 에이전트 시스템을 만든다면, 다음 중 하나만이라도 적용해보세요: Evaluator를 분리해서 냉정한 리뷰를 강제하기, 혹은 풀스택이라면 Planner까지 포함한 3에이전트 루프로 바꾸기요.
한 번이라도 “결과물은 그럴듯한데 계속 불안하다”를 겪었다면, 이 방식이 체감 차이를 줄 가능성이 큽니다.