본문 바로가기
카테고리 없음

Claude Code 서브에이전트 하네스 직접 짜보니 — 여러 프로젝트에 붙이며 버린 패턴

by 마이티제이 2026. 6. 19.
반응형

저는 Claude Code로 일하면서, 한동안은 모든 작업을 메인 세션 하나에서 처리했습니다. 그러다 작업이 커질수록 메인 컨텍스트가 금세 무거워졌고, "이건 따로 떼서 시키면 되지 않을까" 싶어 서브에이전트와 멀티에이전트 구성에 손을 댔습니다.

여러 프로젝트에 하네스(에이전트와 그 검증 절차를 묶은 작업 구조)를 붙여 보면서, 처음 생각과 달랐던 지점이 꽤 있었습니다. 특히 "쪼개면 무조건 이득"이라는 막연한 기대가 몇 번 깨졌습니다. 직접 구축하며 남은 기록을 정리합니다.

서브에이전트는 '또 하나의 나'가 아니다

먼저 짚고 갈 게 있습니다. 서브에이전트는 메인 세션과 분리된 일회성 격리 컨텍스트입니다. 메인이 쌓아온 맥락을 공유하는 분신이 아니라, 매번 새로 시작하는 별도의 작업 단위에 가깝습니다.

그래서 핸드오프가 생각보다 손실이 큽니다. 메인이 머릿속에 들고 있는 배경을 서브에이전트는 모르기 때문에, 입력을 메인이 추려서 넘겨줘야 합니다. 이걸 모르고 "알아서 잘하겠지" 하고 던지면 거의 어긋났습니다.

가장 크게 버린 패턴 — 통째로 던지기

제가 가장 먼저 버린 방식은 "레포 전체를 읽고 분석해"처럼 대용량 입력을 통째로 던지는 것이었습니다.

서브에이전트에게 다중 파일 디렉토리나 워크스페이스 전체를 탐색하게 시키면, 그 에이전트의 컨텍스트가 한도까지 차오르다가 스스로를 압축하는 과정을 반복합니다. 그러다 결과물을 제대로 못 내고 멈추거나, 일부만 처리하고 끝나는 경우가 생겼습니다.

한 번은 이걸 수치로 확인한 적이 있습니다. 파일을 하나도 읽지 않고 예/아니오 다섯 개만 답하면 되는 가벼운 진단용 서브에이전트가, 약 16만 토큰을 소모했습니다(제 환경에서 1회 측정한 값입니다). 실제 작업량은 0에 가까운데도요. 서브에이전트가 시작 시점에 상속하는 기본 맥락 자체가 그만큼 무겁다는 뜻이었습니다.

여기서 얻은 원칙은 단순합니다. 큰 입력을 통째로 주지 말고, 메인이 경로나 발췌로 잘라서 준다. 레포라면 핵심 파일 경로만, 긴 문서라면 필요한 구간만요. 작은 파일 하나를 읽고 작은 산출물 하나를 쓰는 정도로 좁힌 서브에이전트는 안정적으로 끝났습니다.

언제 쪼개고, 언제 메인이 사수하나

그다음 고민은 "그래서 무엇을 떼어내느냐"였습니다. 제가 정리한 기준은 한 줄입니다.

"메인의 누적 맥락이나 사람과의 왕복 없이, 프롬프트만으로 독립해서 끝낼 수 있는 조각인가?"

이 질문에 "그렇다"면 위임 후보입니다. 제가 주로 떼어낸 일은 이런 것들이었습니다.

  • 넓게 훑는 검색·탐색
  • 다른 작업과 독립적인 기능 한 덩어리
  • 2차 의견 리뷰(다른 시각의 검수)
  • 본문과 별개로 만드는 부수 산출물(품질 검사, 문서, 테스트 명세)

반대로 메인이 끝까지 들고 있어야 했던 일은 따로 있었습니다.

  • 방향을 정하는 결정
  • 여러 결과를 합치고 충돌을 조정하는 통합
  • 최종 검증

방향 결정과 통합을 서브에이전트에 넘기면, 맥락이 끊겨 헛도는 경우가 많았습니다.

작성자와 검수자를 분리한 이유

멀티에이전트에서 가장 효과가 분명했던 건 역할 분담, 그중에서도 작성자와 검수자를 나눈 것이었습니다.

같은 에이전트가 자기 글을 쓰고 자기가 검수하면, 통과시키려는 편향이 생깁니다. 자기 결과물에는 너그러워지거든요. 그래서 초안을 쓰지 않은 별도 컨텍스트가 검수를 맡게 했습니다. 만드는 쪽과 점검하는 쪽을 분리하는 방식입니다.

두 가지를 의도적으로 정했습니다. 첫째, 검수 에이전트에는 수정 권한을 주지 않았습니다. 검수자는 합격/불합격 판정과 그 이유만 돌려주고, 실제 수정은 작성 단계가 합니다. 점검하는 사람이 직접 고쳐버리면 "왜 통과인지"가 흐려지니까요.

둘째, 재시도 횟수는 메인이 셉니다. 서브에이전트는 매번 새로 시작하는 일회성이라 자기가 몇 번째 시도인지 기억하지 못합니다. 그래서 불합격이면 메인이 그 이유를 작성 단계에 전달해 다시 쓰게 하고, 횟수 관리도 메인이 맡았습니다.

하네스를 시작하는 체크리스트

여러 번 붙여 보고 남은, 처음 구성할 때의 순서입니다.

  • 메인 세션은 한 번에 하나의 작업 단위에만 대응시키세요. 한 세션에서 여러 갈래를 동시에 끌고 가면 맥락이 엉킵니다.
  • 떼어낼 조각인지부터 판단하세요. 프롬프트만으로 독립해 끝나면 위임, 방향·통합·최종 검증이면 메인이 사수.
  • 서브에이전트에 줄 입력은 메인이 먼저 잘라서 주세요. "통째로 읽어"는 피하고, 경로나 발췌로 좁히는 게 안전했습니다.
  • 검수가 필요하면 작성자와 다른 에이전트에 맡기고, 그 검수자에겐 수정 권한 대신 판정만 맡기세요.
  • 마지막으로, 쪼개는 것 자체가 목적이 되지 않게 하세요. 작은 일까지 굳이 위임하면 핸드오프 비용이 더 큽니다. 효과가 분명한 자리에만 붙이는 게 제 결론이었습니다.
반응형