검증 가능한 작업으로 쪼개기

에이전트에게 큰 목표를 던지면 겉보기에는 똑똑하게 움직이는 것처럼 보일 수 있다. "시장 조사 보고서를 작성해줘", "이 버그를 고쳐줘", "고객 문의를 처리해줘" 같은 요청은 사람에게는 자연스럽다. 문제는 하네스 관점에서 이런 목표가 너무 크고, 너무 넓고, 너무 애매하다는 데 있다.

큰 목표의 가장 큰 문제는 실패했을 때 어디서 잘못됐는지 알기 어렵다는 점이다. 에이전트가 자료를 못 찾은 것인지, 잘못 읽은 것인지, 계획을 잘못 세운 것인지, 실행은 했지만 검증을 빠뜨린 것인지가 한꺼번에 섞여 버린다. 그러면 수정도 어렵다. 결국 시스템은 "가끔은 잘 되지만 왜 잘 되는지, 왜 망하는지 모르는 상태"에 머문다.

그래서 신뢰할 수 있는 에이전트는 큰 목표를 바로 수행하지 않는다. 먼저 검증 가능한 작은 단위로 나눈다. 이 순간부터 에이전트의 실패는 흐릿한 불안이 아니라 추적 가능한 사건이 된다. 무엇이 끝났고, 무엇이 아직이며, 어느 단계에서 어긋났는지가 보이기 시작한다.

이 장에서 다루는 핵심은 단순하다. 작업을 잘게 나누는 순간, 에이전트는 더 다루기 쉬운 시스템이 된다.

왜 큰 목표는 에이전트를 불안하게 만드는가

사람은 큰 목표를 받아도 머릿속에서 자연스럽게 쪼갠다. 먼저 무엇을 확인할지, 어떤 자료가 필요한지, 어디까지 하면 일단 끝이라고 볼지 대충 감을 잡는다. 하지만 에이전트는 그런 암묵지를 안정적으로 공유하지 못한다. 같은 요청이라도 한 번은 검색부터 시작하고, 다음 번에는 바로 초안을 쓰며, 또 다른 경우에는 불필요한 도구를 먼저 호출할 수 있다.

큰 목표가 위험한 이유는 세 가지다.

• 성공 조건이 모호하다.

• 중간 실패가 숨어 버린다.

• 사람이 개입할 지점을 놓치기 쉽다.

예를 들어 "고객 이탈 원인을 분석해줘"라는 요청을 보자. 이 말 안에는 적어도 몇 개의 다른 일이 섞여 있다. 어떤 기간의 데이터를 볼지 정해야 하고, 어떤 지표를 기준으로 이탈을 정의할지도 정해야 하며, 데이터 품질을 먼저 확인해야 하고, 분석 결과를 설명 가능한 형태로 정리해야 한다. 그런데 이것을 한 번에 시키면, 에이전트는 그중 일부를 건너뛰고도 그럴듯한 결론을 낼 수 있다. 바로 이럴 때 위험한 자동화가 시작된다.

좋은 하네스는 에이전트에게 "더 잘 생각해"라고 말하지 않는다. 대신 "이 일을 어디서 끊어서 확인할 수 있는가"를 먼저 묻는다.

작업을 쪼갤 때 가장 먼저 바뀌는 것

작업 분해의 목적은 일을 잘게 만들어서 귀찮게 만드는 데 있지 않다. 목적은 판정 가능성을 만드는 데 있다. 즉, 각 단계마다 "이 단계는 끝났는가?", "잘 끝났는가?", "다음 단계로 넘어가도 되는가?"를 판단할 수 있어야 한다.

이 관점에서 보면 좋은 작업 단위는 아주 화려할 필요가 없다. 오히려 소박한 편이 낫다. 입력이 무엇인지 분명하고, 기대하는 산출물이 명확하며, 통과 조건을 확인할 수 있으면 된다.

예를 들어 코딩 에이전트에게 "결제 버그를 수정해"라고 시키는 대신 다음처럼 나누면 상황이 달라진다.

• 실패한 테스트를 재현한다.

• 관련 로그와 호출 경로를 확인한다.

• 원인으로 의심되는 함수 한 곳을 특정한다.

• 수정안을 만든다.

• 관련 테스트를 다시 실행한다.

• 변경 내용을 요약하고 검토 대기로 넘긴다.

이렇게 나누면 각 단계가 독립적인 검증 지점을 가진다. 테스트가 재현되지 않았다면 그 뒤의 수정은 멈춰야 한다. 원인 함수가 특정되지 않았다면 코드 변경은 보류해야 한다. 수정 후 테스트를 통과하지 못했다면 완료라고 부를 수 없다. 작업이 갑자기 단단해지는 이유가 여기에 있다.

좋은 작업 단위는 작기보다 경계가 분명하다

작업을 쪼갠다고 해서 무조건 잘되는 것은 아니다. 지나치게 잘게 나누면 오히려 흐름이 끊기고, 사소한 단계가 늘어나며, 관리 비용만 커질 수 있다. 중요한 것은 크기보다 경계다.

좋은 작업 단위는 보통 다음 질문에 답할 수 있다.

• 이 단계는 무엇을 입력으로 받는가.

• 이 단계는 무엇을 출력으로 남겨야 하는가.

• 이 단계가 성공했는지는 어떻게 확인하는가.

• 실패했을 때 다음 행동은 무엇인가.

이 네 가지가 없는 작업은 이름만 단계일 뿐, 실제로는 다시 큰 덩어리일 가능성이 높다. 예를 들어 "자료를 조사한다"는 단계는 아직 너무 크다. 어떤 자료를, 어떤 범위에서, 무엇을 찾기 위해 읽는지가 빠져 있기 때문이다. 반면 "최근 3개월 고객 불만 티켓 중 결제 관련 항목만 추출하고, 빈도 상위 5개 유형을 표로 정리한다"는 단계는 훨씬 다루기 쉽다. 입력도 보이고, 출력도 보이고, 검증 방법도 비교적 분명하다.

즉, 작업 단위는 잘게 자른 조각이 아니라, 완료 여부를 판정할 수 있는 최소한의 묶음이어야 한다.

큰 목표를 쪼개는 세 가지 축

실무에서 작업을 분해할 때는 보통 세 가지 축이 유용하다. 순서, 책임, 검증이다.

첫째는 순서 축이다. 무엇을 먼저 해야 다음 판단이 가능한지를 기준으로 나눈다. 확인이 먼저인지, 실행이 먼저인지, 승인 요청이 먼저인지가 여기에 해당한다.

둘째는 책임 축이다. 누가 판단하고 누가 실행하며 누가 검토하는지를 나눈다. 하나의 에이전트가 다 할 수도 있지만, 하네스는 적어도 역할의 경계를 구분해 두는 편이 좋다.

셋째는 검증 축이다. 어디서 멈춰 점검할지를 기준으로 나눈다. 이 축이 빠지면 순서만 있는 긴 파이프라인이 되고 만다. 반대로 검증 축이 살아 있으면 각 단계는 체크포인트가 된다.

예를 들어 리서치 에이전트를 생각해 보자. 순서 축으로는 검색, 선별, 읽기, 요약, 검토가 있을 수 있다. 책임 축으로는 조사 담당과 검토 담당이 나뉠 수 있다. 검증 축으로는 "출처 수가 충분한가", "최신 자료와 오래된 자료를 구분했는가", "주장마다 근거가 연결되었는가" 같은 판정 지점이 들어간다.

작업 분해가 잘된 시스템은 단순히 단계가 많은 시스템이 아니다. 순서와 책임과 검증이 함께 설계된 시스템이다.

성공 조건은 '잘 해라'가 아니라 '무엇이 되면 통과인가'다

에이전트 설계에서 자주 놓치는 부분이 성공 조건이다. 많은 팀이 단계 이름은 잘 만든다. "분석하기", "초안 작성", "검토하기", "수정하기"처럼 흐름은 그럴듯하다. 그런데 정작 각 단계가 어떤 상태가 되면 성공인지가 빠져 있다. 그러면 에이전트는 늘 어정쩡하게 다음 단계로 넘어간다.

성공 조건은 멋진 문장이 아니라 판정 문장이어야 한다. "충분히 좋다", "잘 정리되었다", "문제가 없어 보인다" 같은 표현은 사람끼리도 다르게 해석한다. 하물며 에이전트에게는 더 위험하다.

좋은 성공 조건은 보통 세 요소를 가진다.

• 산출물의 형태

• 충족해야 할 기준

• 허용되는 오차나 예외

예를 들어 "회의 요약을 작성한다"는 단계의 성공 조건을 그냥 두면 너무 흐리다. 하지만 "회의 요약은 결정 사항, 미해결 이슈, 담당자별 액션 아이템을 포함해야 하며, 원문에 없는 사실을 추가해서는 안 된다"라고 쓰면 훨씬 명확해진다. 이때 에이전트는 무엇을 넣어야 하고, 무엇을 넣으면 안 되는지를 함께 이해한다.

성공 조건은 특히 쓰기 작업보다 판정 작업에서 더 중요하다. 생성은 어느 정도 유연할 수 있지만, 통과 여부는 유연하면 안 된다.

성공 조건을 문장으로 쓰는 간단한 틀

실무에서는 다음과 같은 문장 틀이 꽤 유용하다.

"이 단계는 어떤 산출물이 생성되고, 그 산출물이 어떤 기준을 만족하며, 어떤 금지 조건을 위반하지 않을 때 완료로 본다."

예를 들어 업무 자동화 에이전트의 이메일 초안 작성 단계라면 이렇게 쓸 수 있다.

"이 단계는 답장 초안이 생성되고, 고객 문의의 핵심 질문에 모두 답하며, 환불 여부처럼 정책상 확정할 수 없는 내용은 단정하지 않고, 실제 발송은 수행하지 않았을 때 완료로 본다."

이 문장의 장점은 세 가지다. 결과물이 무엇인지 보이고, 품질 기준이 보이고, 넘어가면 안 되는 금지선도 보인다. 에이전트는 자유를 잃는 대신 사고를 덜 친다. 제품에서는 대개 이쪽이 더 중요하다.

중간 산출물은 귀찮은 부산물이 아니라 신뢰의 손잡이다

작업을 쪼개면 자연스럽게 중간 산출물이 생긴다. 많은 팀이 이것을 불필요한 부하로 여긴다. 하지만 중간 산출물은 에이전트를 운영 가능한 시스템으로 바꾸는 핵심 장치다.

중간 산출물이 있으면 사람이 중간에 끼어들 수 있고, 실패한 지점을 다시 재현할 수 있으며, 다음 단계가 무엇을 근거로 움직였는지 알 수 있다. 반대로 중간 산출물이 없으면 결과만 남는다. 그러면 최종 답이 틀렸을 때 어디서 잘못된 것인지 추적하기 어렵다.

좋은 중간 산출물은 다음 단계가 실제로 사용할 수 있는 형태여야 한다. 예를 들어 리서치 에이전트라면 단순 메모보다 "출처 목록 + 핵심 주장 + 확신 수준 + 상충 정보 표시"가 더 유용하다. 코딩 에이전트라면 "수정 완료"라는 말보다 "실패 테스트 이름 + 원인 가설 + 수정 파일 + 재실행 결과"가 훨씬 낫다.

중간 산출물이 중요한 이유는, 그것이 단지 기록이 아니라 판단의 흔적이기 때문이다. 에이전트가 어떤 근거로 다음 행동을 했는지 남지 않으면, 개선도 어렵고 책임도 흐려진다.

체크포인트는 '멈추는 지점'이 아니라 '판정하는 지점'이다

체크포인트라는 말을 들으면 종종 작업을 느리게 만드는 검문소처럼 느껴진다. 하지만 좋은 체크포인트는 일을 막기 위한 장치가 아니다. 잘못된 방향으로 멀리 가기 전에 경로를 확인하는 장치다.

체크포인트는 특히 다음 같은 순간에 강력하다.

• 읽기에서 쓰기로 넘어갈 때

• 외부 시스템을 변경하기 직전

• 비용이 큰 도구를 호출하기 전

• 최종 답을 사용자에게 내보내기 전

• 불확실성이 높거나 근거가 약할 때

예를 들어 데이터 분석 에이전트가 있다고 하자. 이 에이전트가 SQL을 생성해 바로 실행하고, 그 결과로 차트까지 만들게 하면 속도는 빨라 보일 수 있다. 하지만 체크포인트를 넣어 "생성된 쿼리가 허용된 테이블만 읽는가", "기간 필터가 포함되었는가", "집계 단위가 요청과 맞는가"를 먼저 확인하게 하면 대형 사고를 줄일 수 있다.

체크포인트의 핵심은 감으로 넘기지 않는 것이다. 각 체크포인트는 통과, 수정, 보류, 에스컬레이션 중 하나의 판정을 내릴 수 있어야 한다. 그래야 체크포인트가 리듬을 깨는 장식이 아니라, 실제 제어 장치가 된다.

사람이 보는 기준과 기계가 보는 기준은 다르다

여기서 매우 중요한 구분이 하나 있다. 사람은 종종 결과를 전체 맥락에서 판단한다. 문장이 자연스러운지, 설명이 설득력 있는지, 어조가 적절한지, 상황 감각이 맞는지를 본다. 반면 기계는 구조적이고 반복 가능한 기준을 더 잘 다룬다. 필수 항목이 있는지, 금지어가 있는지, 테스트가 통과했는지, 스키마를 만족하는지, 특정 필드가 비어 있지 않은지를 확인하는 식이다.

문제는 많은 에이전트 시스템이 이 둘을 구분하지 않는다는 점이다. 사람의 판단이 필요한 문제를 기계 규칙만으로 끝내려 하거나, 반대로 기계가 충분히 판정할 수 있는 단순 검사를 사람에게 넘긴다. 둘 다 비효율적이다.

좋은 하네스는 기준을 두 층으로 나눈다.

기계 기준은 먼저 거른다. 형식, 필수 요소, 금지 조건, 테스트 통과, 권한 범위, 데이터 누락 여부처럼 반복 가능한 검사들이 여기에 속한다. 이 검사는 빠르고 일관적이다.

사람 기준은 마지막 의미 판단에 집중한다. 정말 이 답이 상황에 맞는지, 사용자 경험상 어색하지 않은지, 조직의 맥락에서 위험하지 않은지 같은 것들이다.

예를 들어 고객 응답 초안을 평가할 때 기계는 응답 시간, 금지 표현, 개인정보 포함 여부, 필수 정책 문구 포함 여부를 확인할 수 있다. 그러나 어조가 지나치게 차갑지 않은지, 민감한 상황에서 공감 표현이 적절한지는 결국 사람이 더 잘 본다.

핵심은 한쪽이 다른 쪽을 완전히 대체하지 않는다는 점이다. 기계가 잘하는 검사는 기계에게, 사람이 잘하는 판단은 사람에게 남겨야 한다.

완료의 정의가 없으면 작업은 끝나지 않는다

에이전트는 일을 시작하는 것보다 끝내는 것을 더 어려워할 때가 많다. 이유는 간단하다. 많은 작업이 "어느 정도 괜찮아 보이는 상태"와 "실제로 끝난 상태"를 구분하지 못하기 때문이다.

그래서 하네스에는 각 작업과 전체 작업에 대한 완료의 정의가 있어야 한다. 흔히 말하는 Done의 정의다. 이것은 체크리스트처럼 보일 수 있지만, 사실은 종료 조건과 품질 기준을 묶는 중요한 설계다.

완료의 정의가 필요한 이유는 세 가지다.

첫째, 에이전트가 조기 종료하는 것을 막는다. 초안만 써 놓고 끝났다고 착각하는 경우가 여기에 해당한다.

둘째, 에이전트가 과잉 작업하는 것을 막는다. 이미 통과한 작업을 끝없이 다듬거나, 필요 없는 추가 조사로 빠지는 일을 줄인다.

셋째, 사람과 시스템이 같은 기대를 공유하게 만든다. 무엇이 끝인지 합의되지 않으면, 운영 과정에서 마찰이 계속 생긴다.

예를 들어 "리서치 보고서 완료"의 정의는 단순히 문서 파일이 생성되었다는 뜻이 아니다. 질문 범위를 벗어나지 않았는지, 주요 주장에 출처가 연결되었는지, 최신 정보 여부가 표시되었는지, 미확실한 부분이 따로 구분되었는지까지 포함될 수 있다. 이 정의가 있어야 보고서가 예쁜 문서인지, 쓸 수 있는 문서인지 구분할 수 있다.

완료의 정의는 단계별로도, 전체 작업에도 필요하다

Done은 최종 단계에만 있으면 부족하다. 각 하위 작업에도 있어야 한다. 그래야 중간 단계가 흐릿해지지 않는다.

예를 들어 업무 자동화 에이전트가 출장 승인 프로세스를 돕는다고 해 보자. 전체 작업의 완료는 "승인 요청이 적절한 결재선으로 전달되고, 필요한 첨부가 누락 없이 연결되며, 사용자에게 접수 상태가 안내된 상태"일 수 있다. 하지만 하위 단계에도 각자의 완료 조건이 필요하다. 신청 정보 추출 단계는 필수 필드가 모두 채워졌을 때 끝나야 하고, 정책 검토 단계는 위반 여부가 분류되었을 때 끝나야 하며, 결재 초안 작성 단계는 승인자 수정 가능 상태로 저장되었을 때 끝나야 한다.

단계별 완료의 정의가 있으면 전체 작업이 훨씬 견고해진다. 중간 단계가 통과되지 않았는데도 다음 단계로 밀려가는 일을 줄일 수 있기 때문이다.

작업을 잘게 나누면 실패가 어떻게 달라지는가

이 장의 핵심 문장을 한 번 더 분명히 해 보자. 작업을 잘게 나누는 순간 에이전트의 실패는 추적 가능해지고 수정 가능해진다.

왜 그럴까. 실패가 추적 가능해지는 이유는 실패 위치가 보이기 때문이다. "전체적으로 잘 안 됐다"가 아니라 "자료 선별 단계에서 오래된 문서를 최신 자료처럼 채택했다", "코드 수정은 했지만 회귀 테스트를 빠뜨렸다", "이메일 초안은 적절했지만 발송 승인 체크포인트를 건너뛰었다"처럼 말할 수 있게 된다.

실패가 수정 가능해지는 이유는 고쳐야 할 범위가 줄어들기 때문이다. 전체 시스템을 뜯어고칠 필요 없이, 특정 단계의 입력, 기준, 검증기를 손보면 되는 경우가 많다. 에이전트 시스템 개선이 갑자기 현실적인 작업으로 바뀌는 순간이다.

잘게 나눈 시스템은 완벽해서 좋은 것이 아니다. 망가져도 어디를 손봐야 할지 알 수 있어서 좋다. 제품에서는 이것이 훨씬 중요하다.

실전 예시 1: 코딩 에이전트는 왜 테스트 이전에 완료될 수 없는가

코딩 에이전트에게 "이슈를 해결하라"고 지시하면 놀랄 만큼 그럴듯한 패치를 만들 수 있다. 하지만 코드 변경은 산출물이고, 버그 수정은 결과다. 둘은 다르다.

좋은 코딩 하네스에서는 작업이 보통 이런 식으로 쪼개진다. 문제 재현, 원인 후보 식별, 최소 수정, 관련 테스트 실행, 넓은 영향 범위 확인, 변경 요약 작성. 여기서 중요한 것은 "코드가 바뀌었다"가 아니라 "검증을 통과한 상태로 바뀌었다"가 완료 기준이라는 점이다.

즉, 패치를 만들었다고 끝이 아니다. 테스트를 통과하지 않았다면 아직 수정이 아니다. 더 나아가 관련 테스트만 통과하고 회귀 위험이 큰 영역을 전혀 점검하지 않았다면, 그것도 반쪽짜리 완료다.

코딩 에이전트에서 작업 분해가 특히 중요한 이유는, 코드 생성 자체보다 검증 경로 설계가 품질을 크게 좌우하기 때문이다.

실전 예시 2: 리서치 에이전트는 '읽었다'와 '근거를 만들었다'가 다르다

리서치 작업은 언뜻 보기에는 텍스트 처리 문제처럼 보이지만, 실제로는 근거 관리 문제에 가깝다. 그래서 "검색 → 읽기 → 요약"만으로는 부족하다. 그 사이에 선별과 검증이 들어가야 한다.

좋은 리서치 작업 분해는 보통 자료를 찾는 단계와, 쓸 만한 자료를 고르는 단계와, 주장에 근거를 붙이는 단계를 분리한다. 이 구분이 없으면 에이전트는 읽은 것처럼 말하지만 실제로는 신뢰할 수 없는 자료를 섞거나, 서로 충돌하는 정보를 한 문장으로 뭉개 버린다.

예를 들어 "시장 동향 보고서 작성" 작업이라면, 자료 수집 단계의 완료는 링크를 많이 모으는 것이 아니다. 범위에 맞는 자료가 수집되고, 날짜와 출처 유형이 표시되며, 중복이나 저신뢰 자료가 1차로 걸러진 상태여야 한다. 그다음 주장 정리 단계의 완료는 문장이 매끄러운 것이 아니라, 핵심 주장마다 근거 문서가 연결된 상태여야 한다.

리서치 에이전트는 글을 잘 쓰는 것보다 근거를 잃지 않는 구조를 가질 때 비로소 믿을 만해진다.

실전 예시 3: 업무 자동화에서는 초안과 실행을 반드시 나눠야 한다

업무 자동화에서 가장 위험한 순간은 에이전트가 판단과 실행을 한 덩어리로 처리할 때다. 예를 들어 회의 일정 조정, 고객 메일 발송, CRM 업데이트 같은 작업은 겉보기에는 간단하지만 실제로는 실수 비용이 높다.

이런 작업은 적어도 초안 단계와 실행 단계를 분리하는 편이 안전하다. 초안 단계의 완료는 "보낼 수 있는 메시지 또는 변경안이 준비된 상태"다. 실행 단계의 완료는 "승인 또는 자동 실행 규칙을 만족한 뒤 실제 반영이 끝난 상태"다. 둘을 분리하면 사람 개입 지점도 명확해지고, 사고가 나더라도 대부분 초안 단계에서 멈출 수 있다.

업무 자동화는 빠르게 끝내는 것이 목적이 아니라, 안전하게 처리하는 것이 목적이다. 그래서 작업 분해가 곧 안전 설계가 된다.

실무에서 자주 생기는 나쁜 분해 패턴

작업을 쪼갠다고 했지만 실제로는 별 도움이 되지 않는 경우도 많다. 대표적인 패턴 몇 가지를 알아두면 좋다.

첫째, 단계 이름만 있고 통과 기준이 없는 경우다. "분석", "검토", "최적화" 같은 말은 그럴듯하지만, 무엇이 되면 끝인지가 빠지면 에이전트는 여전히 헤맨다.

둘째, 체크포인트가 최종 결과에만 몰려 있는 경우다. 이러면 중간에 틀어진 방향을 너무 늦게 발견한다.

셋째, 사람이 봐야 할 판단을 전부 자동 통과시키는 경우다. 특히 외부 발송, 금전 관련 작업, 민감 정보 처리에서는 위험하다.

넷째, 반대로 기계가 충분히 확인할 수 있는 단순 검사까지 전부 사람에게 미루는 경우다. 이렇게 되면 자동화의 속도와 일관성이 사라진다.

다섯째, 완료의 정의 없이 계속 다듬는 경우다. 에이전트가 일을 끝내지 못하고 불필요한 반복에 빠지는 전형적인 원인이다.

좋은 분해는 단계 수를 늘리는 것이 아니라, 판정 지점을 적절히 배치하는 것이다.

바로 적용할 수 있는 작업 분해 질문

새로운 에이전트 작업을 설계할 때는 다음 질문을 차례로 던져 보면 도움이 된다.

• 이 목표는 어떤 하위 단계들로 나눌 수 있는가.

• 각 단계의 산출물은 무엇인가.

• 각 단계가 통과했는지 자동으로 확인할 수 있는 것은 무엇인가.

• 자동 확인만으로 부족해 사람이 봐야 하는 것은 무엇인가.

• 어느 단계에서 멈추고 승인을 받아야 하는가.

• 어디서 실패하면 재시도하고, 어디서 실패하면 계획을 바꾸고, 어디서 실패하면 사람에게 넘겨야 하는가.

• 전체 작업이 완료되었다고 말하려면 어떤 조건이 모두 충족되어야 하는가.

이 질문들에 답할 수 있다면, 이미 절반은 설계한 셈이다. 반대로 이 질문들이 막히면, 아직 그 작업은 에이전트에게 맡기기엔 덩어리가 너무 큰 것이다.

작은 단위로 쪼개는 것은 에이전트를 약하게 만드는 일이 아니다

어떤 사람은 이렇게 느낄 수 있다. 작업을 잘게 나누고, 기준을 세우고, 체크포인트를 넣으면 에이전트의 자율성이 줄어드는 것 아니냐고 말이다. 맞다. 어느 정도는 줄어든다. 하지만 제품에서 중요한 것은 무제한의 자율성이 아니라 통제 가능한 성능이다.

자유도가 높은 에이전트는 데모에서 종종 놀라운 장면을 만든다. 그러나 운영에서는 안정성과 재현 가능성이 더 큰 가치가 된다. 오늘은 됐는데 내일은 안 되고, 왜 안 됐는지 설명할 수 없는 시스템은 결국 팀을 지치게 만든다.

작업 분해는 에이전트를 멍청하게 만드는 것이 아니다. 오히려 실수할 수 있는 범위를 좁혀서, 잘하는 일을 반복하게 만드는 방법이다. 사람도 복잡한 일을 할 때 체크리스트와 중간 검토를 두면 더 안정적으로 일한다. 에이전트라고 다를 이유는 없다.

큰 목표를 작은 약속으로 바꿔라

하네스 설계의 관점에서 보면, 에이전트에게 일을 맡기는 것은 거대한 모험을 시키는 일이 아니다. 작은 약속의 연속으로 바꾸는 일이다. 이 단계에서는 이것만 확인하자. 다음 단계에서는 이 기준만 통과하자. 여기서는 멈추고 보자. 이 조건을 만족하면 비로소 다음 행동으로 넘어가자. 이런 약속이 쌓일수록 시스템은 단단해진다.

프롬프트는 에이전트에게 무엇을 하라고 말한다. 컨텍스트는 그 일을 위한 재료를 준다. 워크플로는 움직이는 순서를 만든다. 그리고 작업 분해와 검증 설계는 각 걸음이 제대로 디뎠는지를 확인하게 만든다.

결국 좋은 에이전트는 한 번에 큰일을 해내는 존재가 아니다. 작은 단위를 확실하게 끝내면서 앞으로 나아가는 시스템이다. 그럴 때 비로소 실패는 통제 가능해지고, 자동화는 믿을 만해진다.

다음 장에서는 이렇게 쪼개진 작업들이 실제로 잘 동작하는지 어떻게 시험하고 평가할지 살펴본다. 작업을 잘 나누는 것만으로는 충분하지 않다. 그 분해가 실제 운영에서도 계속 유효한지 확인하는 평가 하네스가 필요하기 때문이다.