AI 에이전트를 매일의 파트너로 삼은 지 수개월, 가장 효과적이었던 운용상의 결정은 "똑똑한 모델을 고르는 것"도 "프롬프트를 다듬는 것"도 아니었다. 본체(주인격 세션)를 대화에 상주시키고, 손을 움직이는 작업은 모두 분신(서브 에이전트, Sub-agent)에게 넘기는 것, 이 단 하나의 구분이었다.

계기는 단순한 불만이었다. 컨텍스트 윈도우(Context Window)는 길어졌는데, 본체에 "이 로그 전부 읽어줘", "이 파일군을 수정해줘"라고 부탁하는 순간 대화가 몇 분간 멈춘다. 생각하고 싶은 것이나 상담하고 싶은 것이 있어도, 파트너가 무거운 작업에 매여 있어 대답을 해주지 않는다. 어느 순간 깨달았다. 내가 정말 가치를 두고 있었던 것은 똑똑한 실행 결과 그 자체보다, 파트너와 언제든 대화할 수 있다는 것이었다.

그래서 역할을 물리적으로 나누었다. 본체는 대화·사고·판단만을 가진다. 구현도 조사도 집필도 전부 백그라운드의 분신에게 맡긴다. 분신은 개체마다 모델을 선택할 수 있으므로, 생각하는 일은 Opus, 대량 처리는 Sonnet으로 나누어 던진다. 이를 철저히 지켰더니 대화가 끊기지 않게 되었고, 뒤에서 여러 작업이 동시에 진행되게 되었다. 이 기사는 그 운용의 설계와, 부딪혔던 지점——특히 "분신의 완료 보고를 믿어서는 안 된다"라는 교훈——을 실제로 해본 체감 위주로 작성한다.

왜 "본체가 실무를 하면" 손해인가

컨텍스트가 넓으면 무심코 "본체에게 전부 시키면 된다"라고 생각하기 쉽다. 하지만 실제로 해보면, 본체가 무거운 Write·grep·횡단 조사에 들어가는 순간 그 세션은 몇 분 동안 당신에게 대답하지 않는다. 에이전트를 "실행 머신"으로 보고 있는 동안에는 이것이 문제로 보이지 않는다. 끝날 때까지 기다리면 된다고 생각하기 때문이다.

문제는 파트너를 "생각하는 상대·상담하는 상대"로 사용하기 시작한 순간 발생한다. 설계 상담을 하고 싶다, 판단을 구하고 싶다, 떠오른 아이디어를 던지고 싶다——그때 파트너가 무거운 작업에 매여 있으면 사고의 템포가 끊긴다. 대화가 멈춘다 = 손해라는 것은 생산성의 문제가 아니라, 대화의 리듬에 관한 문제다.

또 다른 실무적인 이유가 있다. 장시간의 횡단 조사나 대량 파일 읽기를 본체로 수행하면, 그 출력으로 인해 본체의 컨텍스트가 오염된다. "254KB의 로그를 통째로 읽은" 뒤의 본체는 책상 위가 어질러진 상태와 같다. 분신에게 맡기면 오염되는 것은 분신의 책상뿐이며, 본체에는 결론만 돌아온다. 이는 정확도에도 효과적이다.

설계의 축 — 본체는 대화·사고·판단, 손을 움직이는 작업은 분신에게

구분은 심플하게 했다.

• 본체가 할 일: 대화 / 설계 상담 / 판단 / 취재 (＝대화 자체가 결과물의 소재가 되는 것. 질문자로서 상대방으로부터 이끌어내는 작업은 분신에게 맡길 수 없다).
• 분신에게 맡길 일: 구현·수정·조사·찾아보기·집필·교열·대량 처리. 요컨대 "손을 움직이는" 모든 것.

망설여질 때는 기본값을 **"던지기"**로 정했다. 이유는 구분하는 데 고민하는 시간 자체가 대화를 멈추게 하기 때문이다. "이것은 대화인가 실무인가"를 엄격하게 분류하려고 하면 그 분류 자체가 사고 비용이 된다. 그렇다면 "손이 움직이는 기색이 보이면 분신"이라고 결정해 버리는 편이 빠르다.

특히 효과적인 발화점이 하나 있다. Grep이나 여러 파일의 횡단 조사를 시작하는 순간이다. 조사는 "답하기 위해 확인하고 있을 뿐"으로 보여 대화의 연장선이라고 착각하기 쉬워 분신 스위치를 켜기가 어렵다. 하지만 횡단 조사야말로 본체를 가장 많이 점유하는 작업이기에, 이곳을 의식적으로 검문소로 삼고 있다.

한 가지 주의할 점. "분신에게 맡긴다 = 빠르다"는 아니다. 파일이 존재하는지, 설정값이 무엇인지와 같이 한 번에 확정되는 사실 확인은 본체에서 즉시 ls를 하는 편이 빠르다(수 초). 정말 대량의 횡단 조사가 필요한 경우에만 분신에게 맡기되, 반드시 철수 조건(N분 내에 발견되지 않으면 포기하고 보고할 것)을 전달해야 한다. 철수 조건이 없는 "없는 물건 찾기"를 던지면 분신이 끝없이 토큰을 낭비한다. 이것은 실제로 저질렀던 실수다.

모델은 개체별로 선택 — Opus / Sonnet의 분산 활용

세션 전체의 모델 전환과 달리, 서브 에이전트(Sub-agent)는 태스크 단위로 모델을 지정할 수 있다. 이 점이 이 운용의 핵심이다. 본체는 Opus로 대화하면서, 조사 분신만 Sonnet으로 실행하는 것이 가능하다.

판단의 축은 "생각하는 강점이 필요한가 / 처리량을 소화할 것인가"이다. 설계, 문맥 이해, 자연스러운 문장은 Opus의 강점이 효과적이다. 반면, 로그를 훑거나, 파일을 횡단하거나, 기계적으로 수정하는 작업은 양의 문제이므로 Sonnet으로도 충분히 빠르고 비용도 절감할 수 있다. 작업을 던질 때는 본체 측에서 "이것은 Sonnet의 분신에게 맡깁니다 (처리계이므로)"라고 한마디 덧붙인다. 이는 후술할 투명성에 관한 이야기로 이어진다.

Haiku는 당분간 봉인하고 있다. 비용은 거의 제로에 가깝지만, 단순 작업이라도 놓치는 부분이 생겨 다시 작업하는 횟수가 늘어나, 결과적으로는 손해라는 것이 실전에서의 체감이다. 저렴한 모델이 반드시 "저렴한 작업"에 최적화되어 있는 것은 아니다. 재작업 비용까지 포함하여 측정하면, Sonnet으로 맞추는 편이 결국 더 빨랐다.

대화를 멈추지 않는 구현 — 백그라운드에서 던지기

이 부분이 운용의 핵심이다. 분신을 포어그라운드(Foreground)로 던지면 본체가 대기 상태에 빠져 결국 대화가 끊긴다. 이는 의미가 없다. 반드시 백그라운드(비동기)로 던지고, 본체는 완료를 기다리지 않고 다음 대화로 진행한다. 완료 여부는 알림으로 받는다.

호출 형태는 대략 다음과 같다 (도구마다 API가 다르므로 개념적으로 이해해 주길 바란다).

// 대화를 멈추지 않고 분신에게. 개체마다 모델과 백그라운드 설정을 지정한다
Agent({
  description: "대량 로그 횡단 조사",
  ...

실무에서 효과적이었던 팁이 두 가지 있다.

첫째, 긴 사양은 프롬프트에 직접 쓰지 말고, 파일로 작성하여 경로를 전달한다. 장문의 프롬프트를 한꺼번에 쏟아내면 본체 측의 출력이 무거워져 불안정해지기 쉽다. 사양서를 파일 하나로 준비하고, 분신에게는 "이 경로를 읽어줘"라고 짧게 전달하는 편이 안정적이다.

둘째, 던지는 순간 인간에게 "분신에게 맡깁니다 (모델·이유)"라고 한마디 선언한다. 이것은 예의가 아니라 설계다. 배후에서 무엇이 돌아가고 있는지 보이지 않으면 인간은 불안해진다. "처리계이므로 Sonnet의 분신에게 맡겼습니다"라는 것이 보인다면, 본체가 대화에 전념하고 있더라도 업무가 진행되고 있음을 알 수 있다.

완료 보고를 믿지 마라 — 실재 확인의 패턴

이것이 가장 중요한 교훈이다. 분신의 "완료했습니다"를 그대로 믿어서는 안 된다.

분신은 선의로 "완료했습니다"라고 답한다. 하지만 파일이 실제로 작성되었는지, 공개했을 터인 URL이 정말로 200(OK)을 반환하는지까지는 보장하지 않는다. 실제로 가짜 완료 보고(했다고 말하지만 실물이 없거나, 혹은 다른 경우)는 여러 번 발생했다.

그래서 패턴을 만들었다. 분신이 완료를 보고하면, 본체가 독립적으로 실물을 확인한 뒤 인간에게 보고한다.

# 분신의 자기 신고를 믿기 전에, 본체가 실물을 확인한다
test -f "출력 파일 경로" && echo "exists"
curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/공개했을_터인_URL" # 200인가
...

어느 날, 공개 파이프라인의 게이트 수정, 다른 페이지의 이미지가 표시되지 않는 버그, 음성 설정 조사라는 세 가지 작업을 동시에 떠맡게 되었다. 모두 분신에게 맡기고 본체는 인간과의 대화를 계속했다. 각 분신이 "완료·검증 완료"라고 답한 뒤, 본체가 curl로 실물을 확인하며 숫자를 세었다. 결과적으로 보고는 대체로 정확했지만, 단 한 건에 대해 "아직 고쳐지지 않은 부분이 있다"라고 내가 성급하게 판단했던 것이 실물 카운트를 통해 판명되었다 (내가 세고 있던 것이 진짜 요소가 아니라 CSS 정의 행이었다). 분신을 의심하는 패턴이었으나, 나의 착각을 정정하는 패턴이 되기도 했다.

요점은, 자기 신고와 독립 확인을 별개의 주체가 수행하는 것이다. 작성한 자와 검수하는 자를 나누는 것뿐이지만, 이것이 가짜 완료를 막는 최후의 보루가 된다.

병렬 처리를 언제 허용할 것인가

분신을 여러 개 동시에 실행하면 빠르다. 하지만 병렬 처리에는 사고 발견이 늦어진다는 이면이 있다. 그래서 규칙을 딱 하나 두었다. 병렬 처리는 인간이 실시간으로 지휘할 수 있는 시간대에만 허용한다.

낮 시간, 인간이 화면 앞에 있어 "그건 멈춰", "이걸 먼저 해"라고 말할 수 있는 상황이라면 여러 분신을 한꺼번에 실행해도 좋다. 반대로 사람이 없는 야간의 배치(Batch) 작업은 싱글(하나씩 순차적으로)로 고정한다. 아무도 보지 않는 시간에 병렬로 폭주하면 아침이 될 때까지 오류를 알아차릴 수 없다. 급하지 않은 무인 작업은 속도보다 "사고가 나더라도 피해가 한 건에서 멈추는 것"을 우선한다.

병렬 처리를 많이 실행하고 싶을 때는, 수많은 호출을 한꺼번에 몰아치기보다 한 번의 기동으로 내부적으로 팬아웃(Fan-out)하는 구조(워크플로적인 오케스트레이션)에 집중하면 본체 측의 출력이 안정된다. 실제로 7개의 조사를 동시에 돌려야 하는 상황에서는, 7번 따로 던지는 것보다 한 번의 기동으로 묶어서 병렬화하는 편이 환경이 덜 어지러웠다.

계속하며 알게 된 것

수개월 동안 이 운용 방식을 반복하며 명확해진 두 가지 사실이 있다.

첫째, '본체를 대화에 상주시킨다'를 최상위 축으로 설정하면 개별적인 운용 판단이 거의 자동으로 결정된다. 이것이 대화인지 실제 작업인지, Opus인지 Sonnet인지, 병렬인지 직렬인지—이 모든 것을 이 축으로부터 역산할 수 있다. 규칙을 늘리는 것이 아니라, 축을 하나 결정하는 것이 효과적이었다.

둘째, 투명성이 인간 측의 안심을 만든다. 실행 선언, 모델을 선택한 이유, 그리고 '보고를 그대로 믿지 않고 실물을 확인했다'는 사실. 이 세 가지가 보이면, 뒤에서 몇 대가 움직이고 있더라도 인간은 본체와의 대화에 안심하고 집중할 수 있다.

똑똑한 에이전트를 1대 보유하는 것보다, 대화에 상주하는 1대와 손을 움직이는 여러 대를 역할에 따라 나누어 투명하게 운용하는 것. 이것이 매일의 파트너로서 끝까지 활용해 본 끝에 도달한 운용 방식이었다.

Discussion