Claude Code, 프롬프트보다 하네스가 먼저입니다

요즘 Claude Code를 설치하고 바로 프롬프트부터 넣는 경우를 자주 봅니다. 물론 프롬프트도 중요합니다. 다만 실제로 결과 차이를 더 크게 만드는 지점은 프롬프트 문장 자체보다 작업을 굴리는 구조, 즉 하네스(harness) 설계에 더 가깝다고 생각합니다.

최근 Anthropic Labs 팀의 Prithvi Rajasekaran이 2026년 3월 24일 공개한 글인 Harness design for long-running application development 는 이 지점을 아주 명확하게 보여줬습니다. 핵심은 단일 에이전트에게 모든 것을 맡기는 대신, 역할이 분리된 여러 에이전트를 하네스 구조로 엮어 장시간 작업을 안정적으로 수행하게 만드는 방식입니다.

그래서 하네스가 정확히 무엇인가

하네스라는 말은 처음 들으면 조금 추상적입니다. 그런데 실무적으로 보면 아주 낯선 개념은 아닙니다.

하네스는 쉽게 말해 에이전트를 한 번 호출하는 것이 아니라, 계획하고 만들고 검증하고 다시 돌리는 운영 구조 입니다. 즉 모델 바깥에 있는 실행 프레임입니다.

여기에는 보통 이런 것들이 들어갑니다.

• 어떤 역할의 에이전트를 둘 것인지
• 각 에이전트가 어떤 입력을 받고 어떤 결과를 내야 하는지
• 무엇을 성공으로 판단할 것인지
• 실패를 누가 판정할 것인지
• 재시도와 수정 루프를 어떻게 돌릴 것인지

조금 더 단순하게 말하면 이렇습니다.

• 프롬프트는 “이번에 무엇을 시킬까”에 가깝습니다
• 하네스는 “이 작업을 어떤 공정으로 굴릴까”에 가깝습니다

프롬프트가 작업 지시서라면, 하네스는 작업장 배치와 검수 라인에 가깝습니다. 그래서 Claude Code를 잘 쓴다는 말도, 프롬프트 문장을 길고 그럴듯하게 쓰는 사람보다는 에이전트가 헛소리를 하더라도 중간에 걸러지게 만드는 구조를 만든 사람에 더 가까울 때가 많습니다. 모델에게 자유를 주는 것과 방목하는 것은 다른 이야기입니다.

하네스가 들어가면 무엇이 달라지는가

구성도를 먼저 보면 전체 구조는 아래와 같습니다.

graph LR
    U["사용자 요청"] --> P["기획자"]
    P --> G["생성자"]
    G --> E["평가자"]
    E -->|"수정 필요"| G
    E -->|"통과"| O["결과물"]

이 구조에서 중요한 점은 생성자가 결과물을 내는 순간 끝나는 것이 아니라, 평가자가 별도 기준으로 다시 확인한다는 점입니다.

즉 하네스는 에이전트를 더 많이 붙이는 기술이라기보다, 생성 루프에 검증 루프를 강제로 심는 기술 에 가깝습니다.

왜 단일 에이전트는 자주 무너질까요

긴 코딩 작업을 하나의 에이전트에게 통째로 맡기면 보통 두 가지 문제가 발생합니다.

첫째는 문맥이 길어질수록 에이전트가 서둘러 작업을 마무리하려는 현상입니다. 대화창이 길어지고 상태가 복잡해질수록, 아직 검증되지 않은 결과물을 그럴듯하게 마감해버리는 경우가 많습니다.

둘째는 자기 객관화 실패입니다. 본인이 방금 만든 코드나 디자인을 스스로 평가할 때 지나치게 관대한 판정을 내리는 경향이 있습니다. 특히 디자인처럼 정답이 명확하지 않은 영역에서는 이 문제가 더 심해집니다.

결국 문제는 모델 성능만의 문제가 아니라, 생성과 평가를 같은 루프 안에 묶어둔 구조의 문제라고 볼 수 있습니다. 혼자 만들고 혼자 만족하고 혼자 배포하는 구조는 사람 팀에서도 위험한데, 에이전트라고 다를 이유는 없습니다.

진짜 차이는 생성자와 평가자를 분리하는 데서 시작됩니다

이 글에서 인상적이었던 부분은 생성자와 평가자를 아예 별도 에이전트로 분리한 점입니다.

• 생성자는 실제 산출물을 만듭니다
• 평가자는 결과물을 검증하고 점수를 매깁니다
• 필요하면 기획자가 짧은 요청을 상세한 작업 계획으로 확장합니다

특히 평가자는 Playwright 같은 도구로 직접 브라우저를 열고 버튼을 눌러보면서 애플리케이션을 테스트합니다. 즉, “잘 된 것 같습니다” 수준의 자기 보고가 아니라 실제 동작 기반 검증이 들어갑니다.

여기서 중요한 포인트는 평가자가 단순 리뷰어가 아니라는 점입니다. 평가자는 생성자와 미리 이번 스프린트에서 무엇을 만들고, 무엇으로 성공 여부를 판단할지 합의합니다. 이른바 스프린트 계약이 들어가면, 개발이 중간에 산으로 가는 확률이 크게 줄어듭니다.

많은 사람이 “에이전트가 스스로 잘 판단하겠지”를 기대하는데, 실제 장기 작업에서는 그 기대가 꽤 자주 무너집니다. 기준 없는 자율성은 대개 자유로운 드리프트로 끝납니다.

디자인 품질도 결국 기준을 넣으면 관리할 수 있습니다

원래 디자인은 주관적인 영역이라 AI가 잘 다루기 어렵다고 생각하기 쉽습니다. 그런데 평가 기준을 명시적으로 넣으면 얘기가 달라집니다.

글에서 제시한 기준은 대략 다음과 같습니다.

• 디자인 품질
• 독창성
• 기술적 완성도
• 기능성

이 중 독창성에 높은 가중치를 주자, AI가 흔한 템플릿 스타일을 벗어나 더 과감한 결과물을 만들기 시작했다는 점이 흥미로웠습니다. 결국 모델에게 창의성을 기대하기 전에, 무엇을 독창적이라고 볼지부터 시스템 차원에서 정의해줘야 한다는 뜻으로 읽혔습니다.

AI에게 “예쁘게 만들어주세요”라고만 해놓고 결과가 밋밋하다고 실망하는 것은, 요구사항 없이 대시보드를 시켜놓고 인사이트가 없다고 화내는 것과 조금 비슷합니다.

비용은 늘어나도 결과 품질은 전혀 다른 단계로 갑니다

사례도 인상적이었습니다. 단일 에이전트는 짧은 시간과 적은 비용으로 겉보기 결과물을 빠르게 내지만, 실제로는 멈추거나 불완전한 애플리케이션이 나오기 쉬웠습니다. 반면 하네스를 적용한 다중 에이전트 구조는 더 긴 시간과 더 많은 비용이 들더라도 훨씬 완성도 높은 결과물을 만들었습니다.

이 대목에서 중요한 것은 “더 비싼 방법”이라는 사실보다, 비용을 어디에 쓰느냐가 달라졌다는 점입니다. 단순 생성에 비용을 몰아주는 것이 아니라, 기획과 검증에 예산을 배분하면서 실패 비용을 줄이는 구조가 된 것입니다.

즉, 돈을 더 써서 모델을 더 오래 말하게 한 것이 아니라, 돈을 써서 헛일을 덜 하게 만든 셈입니다.

데이터 엔지니어 관점에서 특히 흥미로운 이유

저는 이 글을 보면서 데이터 엔지니어링과 굉장히 닮아 있다고 느꼈습니다.

데이터 파이프라인도 비슷합니다. 수집, 정제, 적재, 검증이 한 덩어리로 뭉쳐 있으면 처음에는 빨라 보이지만, 규모가 커질수록 어디서 깨졌는지 추적이 어려워집니다. 반대로 역할을 분리하고 각 단계마다 검증 기준을 명시하면 시스템은 조금 복잡해지더라도 운영 가능성이 높아집니다.

예를 들어 데이터 엔지니어는 보통 아래를 분리합니다.

• 데이터를 만드는 단계
• 데이터를 검증하는 단계
• 품질 기준을 관리하는 단계
• 배포 가능 여부를 판정하는 단계

AI 에이전트 시스템도 같은 패턴으로 가고 있습니다. 생성자는 ETL의 변환 작업자에 가깝고, 평가자는 데이터 품질 검증 레이어에 가깝습니다. 기획자는 스키마 정의나 데이터 계약(data contract)을 담당하는 역할과 닮아 있습니다.

결국 앞으로의 AI 엔지니어링은 “좋은 프롬프트를 쓰는 법”보다 “좋은 파이프라인과 검증 루프를 설계하는 법”에 더 가까워질 가능성이 높습니다. 이건 데이터 엔지니어에게 꽤 익숙한 사고방식입니다.

모델이 좋아질수록 시스템은 오히려 단순해질 수도 있습니다

또 하나 흥미로운 부분은, 모델이 똑똑해질수록 기존의 복잡한 스프린트 구조를 오히려 줄일 수 있었다는 점입니다. 흔히 모델이 좋아지면 더 복잡한 제어 구조가 필요할 것 같지만, 실제로는 기본 추론 능력이 올라가면서 시스템 오버헤드를 줄일 수 있는 경우가 생깁니다.

이건 데이터 플랫폼에서도 종종 보던 흐름입니다. 기본 엔진 성능이 좋아지면, 예전에는 필요했던 우회 구조나 보조 프로세스를 걷어낼 수 있습니다. 결국 중요한 것은 현재 모델 능력에 맞는 최소한의 하네스를 설계하는 일입니다.

정리

Claude Code를 제대로 쓰는 사람은 프롬프트만 다듬지 않습니다. 작업을 분해하고, 생성과 평가를 분리하고, 검증 계약을 먼저 설계합니다.

이 글을 보고 다시 느낀 것은 하나입니다. 앞으로 AI 활용의 경쟁력은 모델 사용 여부가 아니라, 장시간 실행 작업을 얼마나 안정적으로 굴리는 시스템을 설계할 수 있느냐에서 갈릴 가능성이 높습니다.

데이터 엔지니어 입장에서는 낯선 이야기가 아닙니다. 결국 좋은 결과는 좋은 모델 하나에서 나오지 않습니다. 좋은 파이프라인, 좋은 검증 기준, 좋은 운영 구조에서 나옵니다.

그래서 제 생각은 단순합니다. Claude Code에서 먼저 만져야 할 것은 프롬프트 문장 몇 줄이 아니라 하네스입니다. 프롬프트는 그 다음입니다. 모델이 똑똑해질수록 이 차이는 더 커질 것 같습니다.