역할을 먼저 쓰고 도구를 나중에 고른다 — 에이전트 설계 10문답

에이전트를 여럿 굴리기 시작하면 질문이 조직 운영 쪽으로 옮겨 간다. "몇 개를 만들어야 하나", "누가 무엇을 결정하나", "충돌은 어떻게 막나" 같은 것들이다. 사람 조직에서 익숙한 질문인데 답이 그대로 옮겨지지는 않는다.

이 글은 에이전트 설계와 멀티에이전트에 걸린 열 문항에 결론부터 답한다. 다른 편보다 문항 수는 적지만 답 하나가 걸치는 범위가 넓다 — 구조 선택, 충돌 방지, 모델 배분, 리더의 범위가 서로 물려 있기 때문이다.

도입 순서와 규약 파일은 도입과 표준화 Q&A, 확장 메커니즘은 확장 메커니즘 Q&A, 운영·권한·비용·장애는 운영과 거버넌스 Q&A에 있다. 수치마다 그 값의 출처 성격을 먼저 밝히는 규칙은 도입과 표준화 Q&A의 마지막 문항에 있다.

핵심 판정 기준 정리

설계 구간에서 반복해 등장하는 갈림길들이다. 값이 아니라 무엇으로 가르는가가 요점이다. 아래 분류는 이 글이 열 문항을 배열하며 정리한 것이다.

Q. 도구 선정보다 역할 정의가 먼저인 이유는 무엇인가

경계가 흐린 정의로는 도구를 아무리 붙여도 엉뚱한 일을 하기 때문이다.

원 자료의 비유는 채용이다. 사람을 뽑을 때 직무기술서를 먼저 쓰듯 에이전트도 정의서를 먼저 쓴다. 정의서는 세 섹션으로 나뉜다 — 역할, 절차, 제약이다. 그리고 그 안에서 실제로 판정을 좌우하는 것은 담당과 비담당의 경계다. "무엇을 한다"만 적고 "무엇은 하지 않는다"를 비워 두면 호출 조건이 정해지지 않는다.

description 필드도 같은 역할을 한다. 그 문장이 "언제 이 역할을 부르는가"를 정하므로 라우팅 키가 된다. 도구 목록은 그다음에 이 경계에 맞춰 좁힌다.

정의서 한 장의 필드 구성은 에이전트 한 명을 정의한다, 여럿을 트리거가 겹치지 않게 묶는 방법은 JD 5필드에서 하루가 도는 데까지에 있다.

Q. AI 산출물의 품질은 무엇으로 보증하나

생성자와 검증자를 다른 에이전트로 분리한다. 원 자료가 규칙으로 못 박은 자리다.

여기에 두 가지가 더 붙는다. 출력 형식을 계약으로 강제하는 것 — 원 자료는 JSON 스키마·마크다운 섹션 템플릿·검증 전담 에이전트 중 하나 이상을 반드시 두라고 한다. 형식이 고정되지 않으면 후속 단계가 파싱에 실패하고 재현성이 남지 않는다. 그리고 재시도 상한이다 — 원 자료 기준은 3회이며, 초과하면 사람에게 넘긴다. 상한 없는 재시도는 비용 폭발로 이어진다.

프롬프트 쪽 장치도 같은 방향이다. 완성된 산출물 예시를 넣어 형식을 보여 주고, 판정은 임계값 표로 결정론화하고, 외부로 나가는 것에는 승인 게이트를 건다.

같은 스키마로 쓰인 정의서 30종에서 이 안전장치들이 실제로 얼마나 균질한지는 형식은 복제되지만 안전장치는 복제되지 않는다에 대조표로 있다.

Q. AI가 사람 판단을 대체해도 되는 경계는 어디인가

되돌릴 수 있는가와 외부로 나가는가 두 축이다.

되돌릴 수 있는 일은 잘못돼도 원복 비용이 작으므로 자동화 여지가 넓다. 반대로 결과가 조직 밖으로 나가면 회수가 사실상 불가능해진다. 두 축을 놓고 보면 사람이 최종 결정해야 하는 자리가 세 갈래로 좁혀진다 — 신뢰도 임계 미달·법적 책임 발생·프로덕션 변경이다.

원 자료의 정의서들이 이 경계를 실제로 어떻게 그었는지가 참고가 된다. 광학 문자 인식 신뢰도가 일정 값 아래로 떨어지면 자동 처리를 멈추고 사람에게 넘기는 식으로 임계를 숫자로 고정한 사례가 있고, 지표 쪽에서는 "이상 감지는 자동, 해석은 사람"으로 같은 작업을 감지와 판단으로 쪼갠 사례가 있다.

두 사례의 공통점은 경계를 문장이 아니라 판정 가능한 형태로 적었다는 점이다. "신중히 판단한다"는 게이트가 되지 못한다.

면책·경계 섹션이 30종 중 몇 개에만 있는지는 형식은 복제되지만 안전장치는 복제되지 않는다에, 애초에 무엇을 자동화 대상으로 고를지 판단하는 두 도구는 합격선 5축과 자동화 대상 선정에 있다.

Q. 멀티에이전트 구조는 무엇으로 고르나

먼저 물을 것은 구조가 아니다. "이 일에 정말 팀이 필요한가" 다. 멀티에이전트는 단일 대비 토큰이 배수로 든다.

팀이 필요하다고 판정되면 구조는 셋이다. 순서 의존이면 파이프라인, 독립 작업이면 분업, 판단이 계속 필요하면 팀장-팀원이다. 셋은 우열이 아니라 서로 다른 비용·속도·실패 모드를 갖는다.

수평 자율 협업이 더 나아 보이는 직관도 여기서 갈린다. 원 자료가 Google/MIT 2025 연구에서 인용한 값으로는 리더를 경유하는 구조의 오류 증폭이 4.4배, 팀원끼리 자율 결정하는 구조가 17.2배다. 실전 구조는 대체로 셋의 혼합이다.

축별 대조 매트릭스와 거기 적힌 비용 값들의 단위가 서로 다르다는 단서, 실무 배치를 어디에 두는지, 세 패턴의 실패 모드 네 개씩과 판단 흐름도는 협업 패턴 3종과 격리 3계층, 팀이 첫 턴에 멈추는 자리는 팀을 굴리면 첫날 무엇이 멈추는가에 있다.

Q. 병렬 실행의 충돌은 무엇으로 막나

격리 축을 골라서 막는다. 논리·세션·물리 세 축은 상하 관계가 아니라 각각 다른 것을 분리하고, 겹쳐 쓸 수도 있다.

그리고 격리만으로는 부족한 자리가 있다. 산출물 소유권을 사전에 배정해야 한다 — 같은 파일을 둘이 동시에 고치지 않도록 오너를 미리 정하는 것이고, 사후 조정이 아니라 사전 분장이다. 저장 단계에서는 순서를 명시하고 병렬을 금지하며, 중복 실행에 대비해 멱등성 가드와 내용 해시 유일 제약을 건다.

세 축이 각각 무엇을 나누고 무엇으로 고르는지, 비교표와 선택 흐름은 협업 패턴 3종과 격리 3계층, 파일 소유권과 종료 프로토콜은 팀을 굴리면 첫날 무엇이 멈추는가에 있다.

Q. 에이전트가 늘면 무엇이 먼저 깨지나

라우팅이다. 비용과 디버깅 난이도도 같은 구간에서 함께 오르지만, 판정을 먼저 무너뜨리는 것은 라우팅 쪽이다.

에이전트가 늘면 트리거 키워드가 겹치기 시작하고, 어느 것을 부를지 판정이 흔들린다. 잠재 경로 수는 개수의 제곱에 가깝게 늘어 10개면 이미 45개 조합이다.

그래서 개수는 목표가 아니라 통제 대상이다. 원 자료의 도입 순서는 핵심 5개로 시작해 10개까지, 나머지는 사용 빈도를 회고한 뒤다. "30개를 갖추면 자동화된다"는 방향이 아니라 "필요한 5~10개로 시작해 회고 후 조정한다"는 방향이다.

구간별 경로 수와 오류율 변화, 라우팅이 무너지는 메커니즘과 구간별 운영 모델은 잠재 경로는 개수의 제곱으로 는다, 개수로 도입 순서를 끊는 근거는 개발조직에 옮길 것에 있다.

Q. 모델은 무엇을 기준으로 계층화하나

작업의 성격이다. 원 자료의 구분은 "복잡한 판단·창작·진단"과 "분류·기록·정형 리포트"이고, 앞쪽이 상위 모델, 뒤쪽이 경량 모델이다.

전원을 상위 모델로 두면 비싸고 느리다. 사람 조직에서 설계와 검수는 시니어가, 반복 구현은 그 아래가 맡는 원가 구조와 같다. 원 자료의 정의서 30종 실측 배분은 상위 10 대 경량 20이다.

비용 레버는 계층화 하나가 아니라 셋이다 — Phase 분리, 모델 계층화, 병렬화 판정이다.

셋째 레버가 병렬화가 항상 이득이 아니라는 것을 말한다 — 순서 의존 작업을 병렬로 밀면 오히려 나빠진다.

세 레버 각각의 절감 수치와 그 값이 어떤 출처에서 왔는지는 팀을 굴리면 첫날 무엇이 멈추는가, 모델 배분의 실물 표는 30개 에이전트 카탈로그에 있다.

Q. 리더 에이전트는 실무를 어디까지 하나

하지 않는다. 리더의 책임은 조율·승인·종료 셋으로 한정된다.

이유는 취향이 아니라 구조다. 리더가 실무를 잡으면 팀장-팀원 구조의 대표 실패 모드인 리더 병목이 그대로 발생한다. 리더의 컨텍스트는 팀 전체 작전을 담은 유일한 장소다.

세 책임 각각의 세부 항목과 금지 4항, 종료 프로토콜은 팀을 굴리면 첫날 무엇이 멈추는가, 팀장-팀원 구조의 병목은 협업 패턴 3종과 격리 3계층에 있다.

Q. 의사결정 기록은 무엇에 남기나

파일이다. 대화에만 있는 결정은 컨텍스트가 압축될 때 사라진다.

기록에서 핵심은 무엇을 거부했는지다. 무엇을 왜 버렸는지가 있어야 재논의가 새 정보 위에서만 열린다.

이 기록은 세션 승계용 상태 파일과는 다른 산출물이다. 상태 파일은 "지금 어디까지 했나"를 넘기고, 결정 기록은 "왜 이렇게 정했나"를 남긴다. 컨텍스트 외부화라는 점만 같다.

네 항목의 기록 형식과 상태 파일과의 구분은 팀을 굴리면 첫날 무엇이 멈추는가, 무엇을 파일로 빼야 세션이 끊겨도 결정이 남는지는 70%에서 끊는 것이 더 빠르다에 있다.

Q. AI를 들이면 사람의 일은 무엇이 되나

실행에서 기준 수립으로 옮겨 간다. 일이 줄어드는 것이 아니라 층이 바뀐다.

앞의 아홉 문항 중 상당수가 같은 방향을 가리킨다. 임계값을 정하는 것, 담당과 비담당의 경계를 긋는 것, 승인 지점을 어디에 둘지 정하는 것 — 이 셋은 에이전트가 대신할 수 없고, 셋 다 정해지지 않으면 자동화가 성립하지 않는다. 반복 실행이 옮겨 갈수록 그 반복이 어떤 조건에서 멈춰야 하는지를 정하는 일이 늘어난다.

도입이 성공한 경우의 공통점도 같은 자리에 있다. 원 자료가 드는 것은 범위를 좁혀 소수로 시작하고 검증 후 확장하는 패턴이며, 그 "검증"의 기준을 정하는 것이 사람의 몫이다.

정의서에 경계 섹션이 왜 존재하는지는 형식은 복제되지만 안전장치는 복제되지 않는다, 조직에 실제로 옮겨지는 것이 에이전트가 아니라 그것이 강제하던 형식이라는 관찰은 개발조직에 옮길 것에 있다.

용어 정리

여기까지가 "누가 무엇을 맡고 어디서 사람이 끊나"의 판단이다. 구조를 정하고 나면 다음 질문은 "그래서 매일 무엇을 보고 있나"로 옮겨 간다. 권한·시크릿·관측·장애·비용, 그리고 도입 효과를 무엇으로 판정하는지는 운영과 거버넌스 Q&A에서 이어 다룬다.