Architectural Design Decisions in AI Agent Harnesses — Hu Wei의 에이전트 설계 분석

에이전트에게 문서 수정 작업을 맡긴다. 담당 에이전트는 예제를 고치다 테스트가 실패하자 하위 에이전트에게 “테스트를 통과시켜 달라”고 위임한다. 하위 에이전트는 실패한 테스트와 파일 경로만 받는다. 앞서 담당 에이전트가 확인한 “이전 버전의 예제는 계속 동작해야 한다”는 조건은 받지 못했다. 하위 에이전트는 옛 예제를 지우고 테스트를 통과시킨다. 이어 배포 명령까지 실행할 수 있는 도구가 보이지만, 그 명령에 대한 승인은 받은 적이 없다.

이 사례는 설명을 위해 만든 완전한 가상 상황이다. 실제 제품의 사고나 논문 속 프로젝트의 관찰 기록이 아니다. 그래도 어떤 설계를 살펴봐야 하는지는 드러난다. 하위 에이전트가 왜 존재하는지, 어떤 정보를 넘기는지, 보이는 도구를 누가 실행할 수 있는지, 실행 환경은 어디까지 접근할 수 있는지, 결과를 누가 어떤 순서로 확인하는지. 다섯 질문은 비슷해 보여도 서로 다른 실패를 막는다.

Hu Wei의 Architectural Design Decisions in AI Agent Harnesses, arXiv v1은 이런 질문을 따라 에이전트 시스템을 비교한다. 2026년 4월 20일 제출된 v1을 기준으로 읽었다.

저자는 대규모 언어 모델(LLM) 주위에서 도구 실행, 상태 유지, 위임, 실행 통제, 작업 순서를 맡는 기반을 편의상 ‘에이전트 하네스’라고 부른다. 새로운 엄격한 제품 분류를 제안하는 용어는 아니다.

논문은 공개 에이전트 시스템 70개를 읽고 그 기반의 설계 결정을 비교한다. “가장 많이 쓰인 구조를 선택하라”는 식으로 읽기보다는, 기능을 추가할 때 어떤 경계까지 함께 살펴야 하는지 찾으며 읽는 편이 유용하다. 논문 PDF p.2, pp.7–9

위임을 추가하는 순간 생기는 다섯 질문

논문은 하위 에이전트 구조, 컨텍스트 관리, 도구 시스템, 안전 장치, 오케스트레이션을 다섯 초점 차원으로 잡는다. 저자는 여러 프로젝트에서 반복해서 나타나고 서로 비교할 수 있는 결정을 골랐다. 모든 에이전트 시스템의 설계를 빠짐없이 다루는 목록은 아니다. 특히 하위 에이전트 구조는 누가 누구에게 일을 맡기는지라는 구성이고, 오케스트레이션은 일이 어떤 순서와 조건에서 진행되는지라는 제어다. 에이전트가 하나여도 복잡한 작업 순서는 있을 수 있고, 에이전트가 여러 개여도 정교한 워크플로가 없을 수 있다. 논문 PDF 표 2 및 §3.3, pp.8–9

하위 작업의 역할을 정한다

가상 사례에서 먼저 물을 것은 위임이 필요한가다. 담당 에이전트가 예제와 테스트를 함께 읽을 수 있다면 하위 에이전트를 만들지 않아도 된다. 위임을 택했다면 역할의 경계가 생긴다. 하위 에이전트가 “실패 테스트만 고친다”는 좁은 역할인지, 문서 전체를 다시 설계할 수 있는 역할인지에 따라 같은 요청의 의미가 달라진다.

논문의 표 4는 단일 에이전트만 둔 프로젝트 21개를 포함해, 기본 생성·도구 호출을 통한 위임·중앙 조정자와 작업자·재귀적 위임 등 여러 구조를 나란히 놓는다. 위임 단계를 늘린다고 더 나은 구조가 되는 것은 아니다. 다음은 그중 세 구조를 문서 수정 작업에 대입한 비교다. 개수는 논문의 관찰값이고 작업 예시는 이 글에서 구성했다. 논문 PDF 표 4 및 §4.1, pp.13–14

도구 위임에서는 담당 에이전트가 작업과 제약을 인자로 전달하고, 하위 작업의 반환값으로 변경 파일과 검증 결과를 받는다. 중앙 조정 구조에서는 조정자가 예제 수정과 호환성 검사를 각각 맡긴 뒤 두 결과를 모을 수 있다. 두 작업자가 같은 파일을 고쳤다면 조정자가 충돌을 해결해야 한다. 재귀 위임에서는 작업자도 다시 일을 나누므로, 결과가 부모에게 돌아오는 단계마다 원래 제약이 보존됐는지 확인해야 한다.

도구 호출 방식만으로 모든 역할과 완료 조건이 정해지지는 않는다. 중앙 조정자 구조도 위임 수단으로 도구를 쓸 수 있다. 위 분류는 프로젝트에서 우세하게 관찰한 패턴이며, 서로 배타적인 구현 부품 목록은 아니다. 가상 사례의 “이전 버전 예제 유지” 조건은 어느 구조에서든 작업 인자와 완료 검사에 남아 있어야 한다.

목표와 제약을 상태로 넘긴다

다음은 무엇을 전달하고 남길 것인가다. 실패 테스트 이름은 작업을 시작할 단서일 뿐, “이전 버전 예제를 유지한다”는 제약을 대신하지 못한다. 작업 목표, 이미 내린 결정, 바꾸면 안 되는 조건, 현재 파일 상태, 아직 확인하지 못한 가정을 하위 에이전트가 볼 수 있어야 한다.

긴 대화를 통째로 복사하면 필요한 조건이 묻히거나 토큰 한도에 걸릴 수 있다. 짧은 요약만 보내면 결정을 내린 근거가 빠질 수 있다.

그래서 컨텍스트는 저장 위치를 고르는 문제에 그치지 않는다. 논문도 지속 범위, 압축, 토큰 예산, 다음 프롬프트에 무엇을 다시 넣을지까지 같은 차원에서 다룬다.

파일에 상태를 남기는 방식, 여러 보존 전략을 섞는 방식, 기억을 층으로 나누는 방식은 이 질문에 대한 서로 다른 선택이다. 예를 들어 작업 파일에는 전체 결정 기록을 남기고 다음 프롬프트에는 현재 목표와 제약만 넣을 수 있다. 요약에서 “이전 버전 유지”가 빠졌다면 원본 파일이 남아 있어도 그 프롬프트로 실행하는 작업은 제약을 모른다. 어디에 보관했는지와 실제 실행 때 무엇을 읽혔는지는 다르다. 논문은 각 방식의 분포를 조사했지만, 어느 방식이 우리 작업에서 정보 손실을 가장 적게 만드는지는 측정하지 않는다. 논문 PDF §4.2·표 5, pp.14–15

도구 목록과 실행 권한을 구별한다

이제 어떤 도구가 어떤 경로로 실행되는가를 따져야 한다. 하위 에이전트에게 테스트 도구를 보여 주는 것과 배포 도구를 보여 주는 것은 다른 결정이다.

도구를 코드에 고정할 수도, 명시적 레지스트리에 넣을 수도, 프로토콜이나 플러그인으로 찾게 할 수도 있다. 논문은 등록 방식뿐 아니라 발견 방식과 실제 실행 경로를 함께 조사한다. 가상 사례의 하위 에이전트는 목록에서 배포 명령을 찾을 수 있었다. 하지만 찾을 수 있다고 실행까지 허용된 것은 아니다. 목록에는 가능한 동작의 인터페이스가 담기고, 실행 허가는 별도로 판단한다. 표 6의 명시적 레지스트리 24개나 외부 도구 연결 규약인 MCP를 우선한 10개도 이 구분을 설명하는 분류이지, 채택률을 따라 하라는 권고가 아니다. 논문 PDF §4.3·표 6, pp.15–17

원문 표 6의 전체 범주와 개수를 한국어 표로 옮겼다. 조사된 구현을 저자가 분류한 결과이며, 각 방식의 품질 순위가 아니다.

승인·격리·감사는 대신할 수 없다

안전 장치도 구체적으로 나눠 보자. 가상 사례에서는 승인, 격리, 감사가 각각 다른 일을 한다. 승인은 “이 주체가 지금 이 동작을 해도 되는가”를 실행 전에 판단한다. 격리는 허용된 동작 또는 잘못 허용된 동작이 파일·네트워크·프로세스 어디까지 닿는지 제한한다. 감사 기록은 누가 무엇을 시도했고 어떤 결과가 났는지 나중에 확인할 근거를 남긴다.

논문의 승인·격리·감사 구분을 도입의 가상 사례에 적용한 비교다. 원문 표 7·8의 채택 비율을 재현한 표는 아니다.

승인받은 테스트 실행도 넓은 파일 접근 권한을 가지면 예상 밖의 파일을 바꿀 수 있다. 반대로 격리된 환경에서 실행한다는 이유만으로 배포 승인이 생기지 않는다. 좋은 로그도 이미 일어난 변경을 되돌리지는 못한다. 논문이 승인, 격리, 감사를 별도 관찰 변수로 둔 이유를 이 사례에서 이해할 수 있다. 논문의 ‘프로세스 분리’, ‘컨테이너 격리’ 같은 범주 이름만으로 실제 파일·네트워크 제한이나 보안 보증 수준을 판정해서는 안 된다. 논문 PDF §4.4·표 7–8, pp.17–18, 부록 B 표 17, p.43

완료를 받아들이는 조건을 정한다

마지막으로 언제 완료로 처리할 것인가가 남는다. 하위 에이전트가 “테스트 통과”를 반환한 순간, 담당 에이전트가 원래 요청을 완료했다고 선언해도 될까? 가상 사례에서는 아니다. 바뀐 예제가 이전 버전과 맞는지 확인하고, 하위 작업의 결과를 원래 목표와 대조한 뒤, 배포가 별도 승인 대상이면 그 상태를 유지해야 한다.

이것이 오케스트레이션의 일이다. 명령형 순서, 선언형 워크플로, 이벤트에 따른 진행 방식 중 어느 쪽이든 위임 결과를 받아들이는 조건과 다음 행동의 트리거를 정해야 한다. 논문의 표 9도 워크플로 정의 방식과 계획 방식을 서로 다른 축으로 보고한다. 하위 에이전트의 존재 자체가 결과 검증 순서를 정해 주지는 않는다. 논문 PDF §3.3, p.9, 표 9, pp.19–20

원문 표 9의 두 축과 비율을 옮기고, 마지막 열에 가상 작업 예시를 붙였다. 각 축 안에서 합계가 100%다. 여섯 행을 하나의 분포로 합치거나, 반올림된 비율을 정확한 프로젝트 수로 바꾸지 않는다.

선언형 워크플로 안에서 ReAct를 수행할 수도 있다. 작업 순서를 어디에 표현하는가와 다음 행동을 어떻게 계획하는가는 별개라는 뜻이다. 어느 조합이든 “이전 버전 예제를 유지했는가”라는 완료 조건은 따로 검사해야 한다.

이 다섯 차원은 각자 다른 질문에 답한다. 상태 전달을 고치면 이전 버전 조건을 알 수 있지만 배포 권한은 생기지 않는다. 배포 도구를 숨기면 무단 실행 경로가 줄어들지만 잘못된 예제 수정은 그대로 남을 수 있다. 격리를 강화해도 “테스트 통과”를 “원래 요청 완료”로 잘못 해석하는 순서는 고쳐지지 않는다. 이 구분은 논문에 나온 특정 구현의 효과를 재현한 결과가 아니라, 다섯 설계 축을 가상 실패에 적용해 얻은 설계 추론이다.

앞의 가상 사례를 한 흐름으로 정리했다. 제약을 전달하고, 허용된 도구로 실행한 뒤, 원래 요구사항을 기준으로 결과를 검사해야 위임이 끝난다.

논문이 관찰한 것은 ‘묶음’이지 인과법칙이 아니다

저자는 2026년 3월 23일에 프로젝트 명단을 고정하고, 저장소 검색·관련 연구·수작업 검토·인접 프로젝트 추적으로 후보를 모았다. 최종 70개 중 67개는 저자가 오픈소스 저장소로, 3개는 공개 자료에 근거한 비교 사례로 분류했다. 프로젝트마다 구현 코드와 기술 자료를 조사하고, 일부 큰 저장소는 범위를 밝힌 표본 읽기를 허용했다. 연구 보조 에이전트가 탐색을 도왔지만 최종 코딩 판단은 사람이 확인했다고 저자는 설명한다.

저자는 공개된 시스템을 한 시점에 조사해 설계 선택을 분류했다. 특정 모델의 성공률을 실험한 연구는 아니다. “70개 중 몇 개”라는 수치는 이 표본과 분류 규칙 안에서만 읽어야 하며, 시장 전체의 보급률을 뜻하지 않는다. 논문 PDF §3.1–3.4·표 1, pp.7–10, §3.9, pp.12–13

저자는 복잡한 하위 에이전트 구조와 정교한 컨텍스트 관리, 실행 격리와 정책형 보안, 확장 가능한 도구 등록과 발견성이 함께 등장하는 경향을 보고한다. 이 방향은 앞의 가상 사례로 설명할 수 있다. 위임이 깊어질수록 전달해야 할 중간 상태가 늘고, 실행 가능한 도구가 넓어질수록 행동을 통제할 지점이 중요해진다.

그렇다고 그럴듯하다는 설명만으로 논문이 인과를 입증했다고 볼 수는 없다. 저자도 동시 출현을 인과 방향, 통계적 유의성, 표본 밖 일반화의 증거로 읽지 말라고 명시한다.

같은 조직 규모나 제품 목표가 두 설계를 함께 낳았을 수도 있다. 논문 PDF §5.1, pp.20–21, §5.4, pp.25–26

표의 분모를 직접 확인해 본다

인용할 숫자에서 분모부터 확인해 보자. 논문은 support를 70개 프로젝트 중 선택 A와 B를 모두 갖춘 비율로 정의한다. 표 6에는 MCP 우선 도구 시스템이 10개라고 나온다. 그렇다면 “MCP 우선”과 어떤 다른 특성이 함께 나타나는 support는 최대 10/70, 약 0.14다.

그런데 표 10에는 “MCP 우선 도구 → 강한 발견성”의 support가 0.62로 적혀 있다. 교집합은 한쪽 집합보다 클 수 없으므로, 공개된 정의와 이 두 표를 그대로 적용하면 값이 맞지 않는다.

조건부 비율이나 다른 범주·분모를 사용했을 가능성은 있지만, 원문은 그 계산을 재현할 자료를 제시하지 않는다. 왜 값이 다른지는 확인되지 않았으므로 잘못을 숨겼다고 단정할 수도 없다. 이 상태에서는 해당 숫자를 설계 효과의 크기로 인용하기 어렵다. 논문 PDF §3.7, p.12, 표 6, p.16, §5.1·표 10, pp.20–21

검토 범위도 숫자 해석에 영향을 준다. 부록에는 프로젝트 목록과 범주 정의가 있지만, 프로젝트별 전체 코딩 행렬과 개별 근거 경로는 본문 밖의 내부 감사 자료로 보관한다고 적혀 있다. 논문은 15개 프로젝트를 다시 검토해 합의 전 필드별 일치율 94%를 얻었다고 보고한다. 공개 독자는 그 결과나 각 프로젝트의 범주 배정을 원자료로 독립 재계산하기 어렵다.

또 다섯 ‘전형적 패턴’은 군집 알고리즘으로 발견한 독립된 종류가 아니다. 저자가 반복되는 설계 묶음을 읽고 각 프로젝트에 우세한 패턴 하나를 배정한 설명적 정리다. 그러므로 ‘다중 에이전트 오케스트레이터’나 ‘균형형 CLI’라는 이름을 품질 등급으로 읽을 이유는 없다. 논문 PDF §3.4, pp.10–11, §6.1·표 14, pp.26–27, 부록 B, pp.42–43

원문 표 14의 분류와 개수를 재구성했다. 한 프로젝트에 우세 패턴 하나를 배정한 값이므로, 서로 겹치지 않는 본질적인 다섯 종류가 발견됐다는 뜻은 아니다.

다음 설계 검토에서 써볼 한 가지 방법

새 하위 에이전트를 도입하려는 작업 하나를 고른 뒤, 실행 경계를 따라 짧게 적어 보자. 누가 일을 나누는가 → 어떤 상태와 제약을 넘기는가 → 어떤 도구가 보이는가 → 각 동작은 누가 승인하고 어디서 실행되는가 → 어떤 결과를 확인해야 원래 작업이 끝나는가. 이 다섯 답이 한 문장으로 뭉개진다면, 기능 목록보다 먼저 그 경계를 분리할 필요가 있다. 위임이 필요 없는 작업이라면 단일 에이전트를 유지하는 것도 논문이 보여 준 실제 선택지다.

논문은 어떤 묶음이 실제 작업 성공률을 높이는지, 어느 격리 방식이 특정 환경을 안전하게 만드는지, 어떤 순서로 기능을 도입해야 하는지 시험하지 않았다. 그 판단에는 자신이 다루는 작업의 실패 조건과 실행 권한을 따로 확인해야 한다. 이 논문을 참고할 때도 전달·실행·완료의 책임을 나눠 보는 데 초점을 두면 좋겠다. 어떤 구조가 인기 있는지보다 내 작업에서 각 책임을 누가 맡을지 묻는 것이다. 논문 PDF §7.3, p.33, §8.3, p.35