하네스 안에는 뭐가 들어있나
안녕하세요! 재니미입니다.
지난 글 「에이전트와 하네스, 실제로 어떻게 움직이나」에서 “이 버그 좀 고쳐줘”라는 요청 하나를 예로 들어서, 하네스가 메시지를 모으고 모델을 부르고 도구를 실행하는 루프를 따라가봤습니다. 그때는 그 전체를 그냥 “하네스”라는 상자 하나로 뭉뚱그려 불렀는데, 실제로 그 상자 안은 여러 조각으로 나뉘어 있습니다.
호주 정부 ASD(Australian Signals Directorate)와 ACSC(Australian Cyber Security Centre)가 2026년 9월 발표한 “Agentic AI Harnesses” 가이드는 이 상자를 11개 구성요소로 쪼갭니다. 이번 글에서는 그 11개가 각각 뭘 하는지, 지난 글의 예시에 대응시켜가며 봤습니다.
이 글은 ASD·ACSC 공식 가이드 “Agentic AI Harnesses – The layer above the model”를 읽고 정리한 것입니다.
11개 구성요소
| 구성요소 | 정의 |
|---|---|
| 모델 인터페이스 | 하네스와 LLM 서비스 사이를 오가는 창구 |
| 도구 레지스트리 | 쓸 수 있는 도구와 그 기능을 정의해두는 곳 |
| 컨텍스트 매니저 | 모델에 어떤 정보를 줄지 고르는 곳 |
| 실행 환경 | 도구 호출이 실제로 실행되는 곳 |
| 권한 시스템 | 민감한 작업의 승인·권한을 통제하는 곳 |
| 메모리·세션 저장소 | 대화·진행 상황을 세션 사이에도 유지하는 곳 |
| 감사·관측 | 활동을 기록해 모니터링·사고 대응에 쓰는 곳 |
| 프롬프트·정책 레이어 | 지시·업무 규칙·조직 정책을 담아두는 곳 |
| 커넥터 레이어 | 하네스 바깥의 데이터·시스템과 연결하는 곳 |
| 업데이트·공급망 경로 | 하네스 자체를 새 버전으로 올리는 통로 |
| 사용자 인터페이스 | 사용자가 보고 승인·개입하는 수단 |
하나씩 보면 이렇습니다.
- 모델 인터페이스: 지난 글 1단계에서 “하네스가 메시지·시스템 프롬프트·도구 목록을 묶어서 모델에 보낸다”고 했던 부분이 바로 이 컴포넌트입니다.
- 도구 레지스트리: “파일 읽기, 파일 쓰기, 명령 실행” 같은 도구 목록을 정의해두는 곳입니다. 여기 정의가 허술하면, 예를 들어 도구 설명이 애매하면 모델이 엉뚱한 도구를 고르는 일이 늘어납니다.
- 컨텍스트 매니저: 지난 글에서 “검색 결과를 다시 모델에 넣어준다”고 했던 부분이 여기서 벌어집니다. 검색 결과를 통째로 넣을지 필요한 부분만 추려서 넣을지 정하는 곳이라, 잘못하면 민감한 정보를 실수로 노출하거나 정작 중요한 맥락을 빼먹을 수 있습니다.
- 실행 환경: 지난 글에서 “하네스가 도구 호출을 실제로 실행한다”고 했던 부분입니다. 그 실행이 내 컴퓨터에서 일어나는지, 격리된 샌드박스 안에서 일어나는지가 여기서 정해집니다.
- 권한 시스템: 실행 환경에서 그 행동을 허용할지 말지를 정하는 곳입니다. “파일 쓰기는 자동으로 허용하되, 명령 실행은 매번 사용자 승인을 받는다” 같은 규칙이 여기 있습니다.
- 메모리·세션 저장소: 대화 기록이나 지금까지의 진행 상황을 세션 사이에도 유지하는 곳입니다. 다만 민감하거나 오래됐거나 조작된 내용이 그대로 남아있을 수도 있습니다.
- 감사·관측: 어떤 도구가 언제 호출됐는지 기록해두는 로그입니다. 나중에 뭔가 잘못됐을 때 “왜 이 순서로 실행됐지”를 되짚어보려면 이 기록이 있어야 합니다.
- 프롬프트·정책 레이어: 시스템 지시, 업무 규칙, 조직 정책을 담아 에이전트 행동을 이끄는 곳입니다. 다른 시리즈에서 다룬 “다시 확인해라” 같은 지시가 쌓이는 곳도 결국 여기입니다.
- 커넥터 레이어: 사내 데이터베이스나 외부 API처럼, 하네스 바깥의 시스템과 연결하는 부분입니다. RAG 저장소나 MCP 도구가 여기 해당합니다.
- 업데이트·공급망 경로: 하네스 자체(Claude Code, Antigravity 같은 도구)를 새 버전으로 올릴 때 쓰는 통로입니다. 새 기능이 들어오는 통로인 동시에, 취약점이 섞여 들어올 수도 있는 통로입니다.
- 사용자 인터페이스: 사용자가 에이전트 활동을 얼마나 볼 수 있고, 승인이나 개입을 어떻게 할 수 있는지를 결정합니다. 도구 호출이 터미널에 하나하나 다 찍히는 것과, 최종 결과만 채팅창에 보여주는 것은 같은 하네스라도 완전히 다른 사용자 인터페이스입니다.
왜 이렇게 쪼개서 보나
가이드는 이 목록을 조직의 “구성 표면(configuration surface)“이라고 부릅니다.
“These components are the organisation’s configuration surface: most of the practical controls over an agentic AI system—such as which tools are exposed, what is permitted, which approvals are required, and which connectors are attached—are settings within this list.”
풀어보면, 실제로 우리가 손댈 수 있는 지점은 거의 다 이 11개 항목 안에 있다는 뜻입니다. “이 에이전트가 안전한가”라는 크고 막연한 질문을, “이 11개 항목이 각각 어떻게 설정돼 있는가”라는 구체적이고 하나씩 점검할 수 있는 질문으로 쪼갤 수 있게 됩니다. 예를 들어 지난 글의 예시로 치면, 모델이 “명령 실행”을 아무 승인 없이 바로 해버리는 게 걱정된다면 그건 모델의 문제가 아니라 권한 시스템 설정의 문제입니다.
1편·2편과 연결해보면
1편에서는 하네스를 실체가 있는 소프트웨어라고 정의했고, 2편에서는 그 하네스가 도구를 부르고 결과를 돌려받는 루프를 실제로 따라가봤습니다. 이번 가이드는 그 실체를 11조각으로 쪼개서, 조직이 통제해야 할 지점을 하나씩 짚어준 것에 가깝습니다. 즉 1편이 “하네스가 뭔지”, 2편이 “하네스가 어떻게 도는지”였다면, 이번 편은 “하네스를 열면 뭐가 있는지”입니다.
가이드는 한 걸음 더 나가서 이렇게 말합니다.
“Organisations control the harness, not the LLM.”
모델은 계속 바뀌고 대체되지만, 이 11개 부품으로 이뤄진 하네스 생태계는 조직에 더 오래 남는 자산이라는 게 가이드의 핵심 주장입니다.
그런데 이 11개는 통제 지점인 동시에, 뒤집어보면 공격이 들어올 수 있는 지점이기도 합니다. 가이드는 이 점을 이렇게 짚습니다.
“Every external tool, data source, connector and memory store the harness adds is a new path into the system.”
도구 레지스트리에 도구를 하나 추가할 때마다, 커넥터 레이어에 외부 시스템을 하나 더 연결할 때마다, 그만큼 새로운 경로가 하나씩 생긴다는 뜻입니다. 하네스를 안전하게 만드는 부품과 하네스를 공격받기 쉽게 만드는 부품이 결국 같은 11개 목록이라는 게, 이 가이드가 이 구성요소들을 이렇게까지 자세히 나눈 이유이기도 합니다.
다음 편에서는 이 지점을 더 파고들어서, 구성요소마다 구체적으로 어떤 보안 리스크로 이어지는지, 가이드가 제시한 다섯 가지 리스크 범주(권한, 설계·구성, 행동, 구조, 책임소재)를 하나씩 다루겠습니다.
감사합니다.