自前ハーネスを持つ意味：AgentCore managed harnessとの分業線

2026 년 4 월 22 일, AWS 는 Amazon Bedrock AgentCore 에 'managed agent harness'(Preview) 를 추가했습니다. 모델 / 시스템 프롬프트 / 도구를 설정으로 선언하는だけで 에이전트가 작동하는 구조로, 오케스트레이션 코드는 AWS 측이 관리하며 제공합니다.

이번 릴리스가 주목받는 것은 기능 그 자체보다는 AWS 가 "agent harness"라는 용어를 채택한 점입니다. Martin Fowler氏が 2026 년 2 월에 Harness Engineering 정리 글을 쓰신 후, Anthropic 과 OpenAI 도 공식적으로 'harness'를 쓰기 시작했고, 클라우드 벤더가自社 서비스 에 동일한 용어를 적용하게 된 흐름의 결과입니다.

자신이 직접ハーネス 를 구성해 온 입장에서 보면, managed harness 는 무엇을 대신해주고 무엇이 내 손에 남는지에 대해 궁금합니다. 본 글에서는 이 분업선을 정리합니다. Claude Desktop 과 여러 MCP 서버, Markdown 의 지식으로 업무 자동화 에이전트를 운영해 온 경험을 바탕으로, AgentCore managed harness 와의 대응 관계를 나열하겠습니다.

'다져본' 글은 이미 몇 편 발표되었으므로, 본 글은 그 전단계인 '탑승 / 탑승 안 함 / 탑승 순서' 판단 자료를 제공하는 위치입니다. 공식 블로그와 문서, 기존 해석 글을 출처로 참조하며, 자전 운영 경험을 바탕으로 대응과 판단 축을 정리하겠습니다.

AWS 가 "managed harness" 를 내보낸

위에서 언급된 공식 블로그에서는 에이전트에 반드시 오케스트레이션 레이어가 있고, 그 레이어를 움직이기 위해서는 계산 자원 / 코드 실행의 샌드박스 / 도구 연결 / 영구 스토리지 / 오류 회복 등 기반이 필요하며, 이를 agent harness 라고 정리합니다. managed harness 는 AWS 측이 관리하여 제공하는 harness 로, 이용자는 모델 / 시스템 프롬프트 / 도구를 설정으로 선언하는だけで 작동하는 에이전트를 얻을 수 있습니다.

여기서 'ハーネス'라는 단어가 지칭하는 범위를 한 번 정해 두겠습니다.ハーネス 는 벤더 측이 내장한 내부 이야기로서도, 이용자 측이 외부에 구성하는 환경으로서도 사용되며, 문맥에 따라 의미가 달라지는 용어입니다. Fowler氏의 정리 외에도 watany氏が Zenn 에서 내부 / 외부의 혼란을 정리했습니다.

본 글은 '자신이 외부 환경을 구성해 온 입장에서', 즉 이용자 측ハーネス 를 실제로 운영해 온 관점에서 작성합니다. AgentCore managed harness 는 벤더 측 내부ハーネス 를 관리화한 것으로 보이지만, 이용자 측에서는 지금까지 자신이 만들어온 외부ハーネス 의 일부 위임이 가능해졌다고 읽을 수도 있습니다. 이 이중성은 자전 운영과의 분업선을 생각할 출발점이 됩니다.

자전ハーネス 의 구성, 빈 공간이었던 네 가지 레이어

자신이 직접 구성해 온ハーネス 의 구성을 AgentCore 의 컴포넌트와 대응시키겠습니다. 지금까지 자신이 운영해 온 환경은 대략 다음 세 요소로 이루어져 있으며, 각각 AgentCore 의 어떤 것과 대응하는지를 나열합니다.

자전ハーネス	AgentCore 측	대응의 정도
Markdown 의 지식 파일군 (agents/, knowledge/ 하위)	AgentCore Memory	유사한 역할, 영구화 및 검색 메커니즘이 다름
MCP 서버군 (작업 관리 / 캘린더 / 채팅 / 문서 관리 등)	AgentCore Gateway	MCP 에 통합되므로 비슷함
Claude Desktop	AgentCore Runtime	에이전트 루프 실행 기반, 규모가 다름
...	...

위 세 가지는 '자신이 직접 구성한 부분'과 'AgentCore 가 동일한 역할을 관리하여 제공하는 부분'의 대응 관계입니다. 아래 네 가지는 자전ハーネス 에서 빈 공간이었던 레이어로, 즉 AgentCore 가 제공하지만 자신의 운영에서는 커버하지 않은 부분입니다.

여기서 궁금한 것은, 빈 공간 네 가지는 '없어도 괜찮았으므로 작성하지 않은 것'인지, '있었으면 좋았으나 포기한 것'인지에 대한 것입니다. 두 가지의 의미는 다릅니다. 전자는 managed harness 를 도입해도 가치가 작고, 후자는 가치가 나옵니다.

네 가지를 순서대로 확인하겠습니다.

Identity 는 여러 사용자가 에이전트를 사용할 때 인증 및 권한 관리입니다. 자전ハーネス 는 개인의 단말에서 작동하므로 인증은 단말 로그인에 맡겨져, 에이전트 단위 인증은 필요하지 않았습니다. 이는 '한 사람으로 사용할 경우' 불필요합니다. 조직에서 에이전트를 공유하려는 순간, 누가 어떤 MCP 에 대해 무엇을 호출할 수 있는지에 대한 제어가 문제가 되며, 빈 공간이 포기 형태로 표출됩니다.

Policy 는 에이전트가 도구를 호출할 때 경계를 명시적으로 정의하는 구조로, AWS 의 오픈소스 정책 언어 Cedar 를 기반으로 자연어로 정책을 생성할 수 있습니다. 자전ハーネス 에서 MCP 서버 측의 범위와 지식으로 '하지 않는 것'을 문서화하여 느슨한 경계를 그리지만, 이는 규칙이지 강제력이 아닙니다. 구현 가능한 강한 경계로 쓰고 싶었으나, 자전 Cedar 와 같은 구조를 작성하는 동기가 없었고, 포기한 영역입니다.

Observability 는 에이전트의 실행 로그·트레이스·메트릭스를 CloudWatch 로 출력하여 가시화하는 메커니즘입니다. 자체용 하드웨어 (self-hosted harness) 의 경우 Claude Desktop 의 대화 기록과 각 MCP 서버가 개별적으로 출력하는 로그만 존재하며, 가로 연결을 통해

이 세 가지는 언어화하기 어렵고, 미리 직접 운영해 보지 말라는 판단입니다. 처음부터 managed harness로 구성하면, 이러한 판단이「처음부터 최적 배치되어 있는 것처럼」생깁니다. 실제로는 전제를 고정하는 것일 뿐이지만, 고정된 전제 안에서 움직이는 한은 설계 판단 자체의 존재가 보이지 않게 됩니다.

처음부터 managed harness으로 잘 않나요

여기서 예상되는 반론이 있습니다.「처음부터 managed harness로 구성하면, 직접 구성할 필요가 없지 않은가」라는 것입니다.

이 반론에는 부분적으로 동의합니다. 조직에서 본番를 운영할 에이전트를 처음부터 0 에서 구성한다면, managed harness 로 들어가는 것이 빠르다고 생각합니다. 다만, 그 설계가「처음부터 보이는 것」은 거의 없습니다. 에이전트를 실제로 사용해 보아야 비로소 지식의粒度，도구의 과부족, 책임의 경계가 보입니다. 이 발견의 흐름을, 틀이 정해진 managed harness 위에서 돌리는 것과, 자유도가 높은 직접ハーネス에서 돌리는 것과 비교하면, 얻는 학습량이 달라집니다.

또 다른 관점에서, 직접 운영으로 얻은 판단은 managed harness 에 실었을 때 설계도로서 재사용할 수 있습니다. 설계도를 가지고 managed harness 로 들어오면, 일단 움직이는 것은 만들 수 있지만, 왜 그렇게 구성했는지 설명하기 어려운 시스템이 남습니다.「일단 실어서 개선을 계속한다」가 성립하는지 여부는 혼자 개선하는지 여러 사람으로 개선하는지에 따라 달라집니다. 한 사람이라면 직접ハーネス과 managed harness 의 반복 속도의 차이는 작을 수 있지만, 여러 사람으로 개선하는 단계에서는 harness.json의 선언적 변경과 배포 단위의 반복이 운영 부채로 작용합니다.

실어 순서: 개인 운영과 조직 운영의 분기점

managed harness 를 채택할지 말지는 운영 규모로 갈라지는 것이 자연스럽습니다. 세 단계로 나누어 확인합니다.

한 사람으로 사용하는 개인 운영 단계에서는, 직접ハーネス이 충분할 때가 많습니다. 지식 파일의 편집과 이용이 밀접하게 연결되어 있고, 사용해 보아 발견한 순간에 Markdown 을改写하는 반복이 빠르게 돌아기 때문입니다. Identity 도 Observability 도, 한 사람으로 움직이는 한은 결핍으로 인식하기 어렵고, 있으면 좋을지도 모른다는 정도에 머물러 있습니다. 실험 단계에서는 이 자유도가 학습 속도에 직결됩니다.

조직에서 여러 사람이 에이전트를 사용하는 운영으로 확장하는 단계에서, 공백이었던 네 층이 일시에 문제화됩니다. 누가 어떤 에이전트를 어떻게 사용했는지 감사 로그가 필요해지고 (Observability), 공유 환경에서 임의로 도구를 치면 안 되는 상황이 나오므로 경계가 필요해지고 (Policy), 멤버별 인증 정보 관리가 필요해지고 (Identity), 에이전트의 응답 품질을 지속적으로 측정하고 싶습니다 (Evaluations). 이 단계에서 managed harness 의 가치가 앞면에 나옵니다. 직접 네 층을 쓰는 노력과 AgentCore 에 실어 넣는 노력을 비교하면, 후자가 현실적입니다.

과도기에는 하이브리드 전략이 취해질 수 있습니다. 개인의 탐색 단계는 직접ハーネス 그대로 계속하고, 조직으로 운영할 확정된 경로만 managed harness 에 실어 나가는 형태입니다. 설계가 굳어진 에이전트를 순서대로 AgentCore 로 옮기고, 아직 움직이면서 학습하는 에이전트는 손에 남깁니다.

실어 순서에도 기준이 있습니다. 조직 확장으로 처음 필요한 것은 Identity 와 Observability, 다음으로 Policy, 마지막으로 Evaluations 입니다. Identity 가 없으면 공유 자체가 성립하지 않습니다. Observability 가 없으면 조직으로서 운영 판단을 할 수 없습니다. Policy 는 사고가 발생한 후에야 늦은 경우가 많으므로, 조직 확장의 초기에 두는 것이 안심입니다. Evaluations 은 운영이 돌아오기 시작해서 품질 측정을 넣는 순서로 괜찮습니다.

ハーネス은 원래 에이전트를 만드는 쪽과 쓰는 쪽의 경계에 있던 개념이었습니다. AWS 가 managed harness 를 내어 놓았으니, 지금까지 직접 구성해 오던 일부가 설정으로 선언하면 움직이는 기구로 바뀌었습니다. Identity·Observability·Policy 와 같이, 직접에서는 반드시 포기했던 층이 손에 닿는 곳이라는 의미는 작지 않습니다.

그래도, 왜 에이전트를 움직이는지, 지식에 무엇을 남기는지, 도구에 어디까지 권한을 주는지에 대한 설계 판단은 설정으로 선언할 수 있는 형태는 아닙니다. 판단의 근거는 여전히 자신의 레포지토리의 커밋 기록과 작업 로그에 남아갑니다. 직접ハーネス을 구성해 온 경험은 managed 로 실어 넣어도 가치가 사라지지 않는 종류의 지식으로, 손에 남깁니다. managed harness 의 정비에 의해, 직접 구성하는 층과 인간이 판단하는 층의 경계가, 지금까지보다 명확히 보이는 것이라 할 수 있습니다.

---

주의사항: 번역 과정에서 원문의 구조 (서론/본론/결론) 를 유지하고, 전문 용어는 영문 병기했습니다. 숫자와 고유명사는 원문과 일치시켰습니다. 제목은 원문이 문장이 아니므로 그대로 유지했습니다.