실행 결과 검증부터 코어와 스킬까지 — 에이전트 런타임 구조 분석

TL;DR — AI 에이전트 제품 구성을 확인할 때는 설치 전제 세 가지, 코어와 스킬이라는 두 층, 교체 가능한 세 갈래, 여덟 항목의 기본 제공 여부를 순서대로 봅니다. Hermes Agent는 여덟 항목 가운데 일곱을 공식 문서에 기능으로 밝혔고, 실행 결과 검증 하나만 근거가 없습니다.

AI 에이전트 도입을 맡은 담당자가 프로덕션 운영 환경에 제품을 들이기 전에, 왜 이 제품이어야 하는지를 설명하기 위해 던지는 질문은 하나로 모입니다. 이 제품은 어떤 형태로 조직에 들어오고, 무엇으로 나뉘며, 우리가 요구할 항목을 어디까지 기본으로 채워 주는가 하는 것입니다. 이 글은 클라우드네이티브TV가 공개한 영상 ‘Hermes Agent 아키텍처 – 02. 기업이 AI 에이전트에 요구할 8가지'(6분 남짓)를 장면별로 풀어, 영상을 보지 않은 독자도 AI 에이전트 제품 구성을 어떻게 확인하는 방식으로 따라갈 수 있게 정리했습니다. 영상은 앞 편에서 세운 여덟 가지 요구 기준을 실제 오픈소스 런타임에 처음으로 대 보는 두 번째 파트입니다. 왜 이 순서로 확인하는지, 그리고 확인된 사실과 확인되지 않은 빈칸을 어떻게 나눠 말하는지가 핵심입니다.

아래 영상은 오픈소스 런타임 Hermes Agent의 설치 전제와 구조, 그리고 여덟 항목 대조표를 6분 동안 차례로 보여 줍니다.

영상에서 다루는 순서는 다음과 같습니다.

• 런타임 본체와 바깥 세 갈래로 이뤄진 구조
• 설치 전제 세 가지와 공식 문서가 밝히지 않은 정량 사양
• 코어와 스킬 두 층의 관계
• 세 갈래의 교체 가능성과 모델을 바꿀 때의 비용
• 여덟 항목의 기본 제공 여부를 한 장에 모은 대조표
• 근거가 없는 마지막 항목 하나

1. 제품은 어떤 덩어리로 나뉘는가?
2. 우리 인프라에 들어오려면 무엇이 필요한가?
3. CPU와 메모리 같은 정량 사양은 얼마로 잡아야 하는가?
4. 코어와 스킬은 무엇이 다른가?
5. 모델 제공자 갈래는 얼마나 열려 있는가?
6. 교체 가능하다는 말에는 어떤 비용이 붙는가?
7. 여덟 항목 가운데 몇 개가 기본으로 제공되는가?
8. 빈칸으로 남은 항목은 무엇이고 왜 먼저 드러내는가?

영상이 보여 주는 AI 에이전트 제품 구성의 첫 그림은 한가운데 놓인 런타임 본체와 그 바깥으로 뻗은 세 갈래입니다. 가운데 파란 상자가 런타임 본체이고, 위쪽이 요청을 주고받는 채널, 왼쪽이 도구와 검색 백엔드, 오른쪽이 모델 제공자입니다. 세 갈래에는 모두 교체 가능이라는 표시가 붙어 있습니다.

런타임이라는 말부터 짚어 둘 필요가 있습니다. 영상은 런타임을 요청을 받아 판단을 모델에 맡기고, 도구를 실행한 다음 결과를 돌려주기까지의 과정을 관리하는 실행 환경이라고 풀어 줍니다. 그러니 런타임은 모델 그 자체가 아니라 모델을 부리는 실행 환경이고, AI 에이전트 제품 구성을 본다는 것은 이 실행 환경이 어떤 부품으로 조립되어 있는지를 본다는 뜻입니다. 같은 이름의 에이전트라도 부품의 나뉨새가 다르면 조직이 감당할 일이 달라집니다. Hermes Agent는 Nous Research가 공개한 오픈소스 에이전트 런타임입니다.

▲ 런타임 본체와 세 갈래 구조 (영상 0:19)

이 그림이 중요한 까닭은 이후의 모든 확인이 이 지도 위에서 이뤄지기 때문입니다. 화면 위쪽의 핵심 문구는 세 개의 축이 따로 나뉜 구조라서 모델을 바꿔도 채널 설정과 스킬은 그대로 유지된다고 요약합니다. 도입 담당자는 AI 에이전트 제품 구성을 평가할 때 이 한 문장을 기준으로 삼아, 제품을 바꿀 때 무엇이 함께 움직이고 무엇이 그대로 남는지를 가늠할 수 있습니다. 반대로 이런 구분이 없는 제품이라면 모델 하나를 바꾸려고 연동 전체를 다시 손봐야 할 수 있으니, 구조 그림을 먼저 요구하는 편이 안전합니다.

세 갈래를 나눠 보는 방식은 점검표를 만들 때도 쓸모가 있습니다. 채널은 사람이 요청을 넣는 입구, 도구와 검색 백엔드는 에이전트가 손을 뻗는 범위, 모델 제공자는 판단을 맡기는 두뇌에 해당합니다. 입구와 손과 두뇌를 따로 적으면 어느 쪽이 조직의 보안 정책과 부딪히는지 하나씩 가려낼 수 있습니다.

영상은 구조를 보기에 앞서 우리 인프라에 들어올 수 있는 제품인지부터 확인합니다. 설치 전제는 화면 위쪽 카드 세 장이 전부입니다. 에이전트 코어를 실행하는 런타임인 Python 3.11, 연동 도구 실행에 필요한 런타임인 Node.js, 그리고 코드와 문서를 빠르게 훑는 검색 도구인 ripgrep입니다.

▲ 설치 전제 세 가지 (영상 1:47)

영상의 해석은 간명합니다. 목록이 짧아서 대부분의 사내 서버는 추가 구매 없이 이 조건을 채운다는 것입니다. 설치 전제가 길고 낯선 제품은 도입 전에 인프라팀의 사전 작업이 늘어나고 일정이 흔들리지만, 이 제품은 그런 부담이 작다는 뜻입니다.

공식 저장소가 밝힌 실행 범위도 넓다고 합니다. 화면에는 5달러짜리 가상 사설 서버에서도 실행 가능하다는 점, GPU 클러스터와 서버리스 인프라까지 지원 범위를 선언했다는 점, 시범 단계와 운영 단계가 같은 코드베이스에서 출발한다는 점이 적혀 있습니다. 마지막 항목은 도입 담당자에게 특히 반가운 소식입니다. 시범 운영에 쓴 구성이 그대로 운영으로 이어질 수 있으면, 도입 초기에 인프라 사양을 미리 정하지 않아도 검토에 착수할 수 있기 때문입니다.

화면 맨 아래에는 주황색 경고줄이 하나 더 있습니다. 상시 구동을 계획한다면 먼저 확인할 조건으로, Windows의 리눅스 호환 계층인 WSL에서는 systemd 지원이 불안정해 재시작이나 유휴 종료 뒤 서비스가 중단될 수 있고, 실제 배치는 리눅스 서버나 컨테이너 환경을 권장한다는 내용입니다. 개발자 노트북에서 돌려 본 구성을 그대로 운영 환경으로 옮기려는 팀이라면 이 줄을 놓치지 말아야 합니다.

설치 전제가 짧다는 장점을 짚던 영상은 곧 방향을 바꿔 오른쪽 칸을 보라고 말합니다. 공식 문서가 밝히지 않은 값이 그곳에 있습니다. 최소 CPU 코어 수, 최소 메모리 용량, 최소 디스크 용량이 모두 명시되어 있지 않습니다. 영상은 이 세 가지를 나란히 적은 뒤 작업량에 맞는 사양은 시험 설치를 거쳐 조직이 직접 측정해야 한다고 정리합니다.

▲ 정량 사양은 명시가 없다 (영상 2:28)

여기서 영상이 쓰는 비유가 인상적입니다. 집을 구할 때 역세권이라는 말만 듣고 계약할 수는 없다는 것입니다. 걸어서 몇 분인지는 직접 걸어 봐야 알듯이, 사양도 말로 된 범위만으로는 가늠되지 않고 *실제 작업량으로 재 봐야 안다*는 이야기입니다. 정성적인 범위 서술은 실행이 특정 인프라에 묶이지 않는다는 설계 방향을 보여 줄 뿐, 정량적인 보증까지 포함하지는 않는다는 각주도 화면 아래쪽에 작게 붙어 있습니다.

이 대목은 도입 문서를 쓰는 사람에게 실무적인 교훈을 줍니다. 견적서에 서버 사양 한 줄을 적어야 하는 순간이 오더라도, 그 숫자를 찾을 수 없다는 사실부터 기록해 두어야 합니다. 빈칸을 추정치로 채워 근거처럼 보이게 만들면 나중에 운영 환경에서 사양이 모자랄 때 책임 소재가 흐려집니다. 영상이 정량 사양의 부재를 별도 칸으로 떼어 보여 주는 것도 같은 이유입니다.

영상은 시험 설치를 거쳐 직접 측정하라고만 말하고 절차는 다루지 않습니다. 일반적인 부하 시험 관행에 따라 풀어 보면 다음과 같은 순서로 정리할 수 있습니다. 배경이 되는 개념은 성능 시험과 용량 계획 문서에서 확인할 수 있습니다.

먼저 에이전트에게 실제로 맡길 작업을 대표하는 시나리오를 두세 개 고릅니다. 다음으로 동시에 들어오는 요청 수를 단계적으로 올리면서 CPU, 메모리, 디스크 사용량을 기록합니다. 마지막으로 평소 사용량의 몇 배까지 여유를 둘지를 조직이 정해 최소 사양이 아니라 권장 사양으로 문서에 남깁니다. 이 기록은 이후 AI 에이전트 제품 구성을 다른 제품과 견줄 때에도 같은 잣대로 재사용할 수 있습니다. 이렇게 하면 공식 문서에 없는 수치도 *조직이 직접 만든 근거*를 갖게 됩니다.

구조 그림의 가운데 상자를 확대해 보면 안에 두 층이 있습니다. 코어는 대화를 주고받으며 실제 작업을 진행하는 고정된 실행 본체이고, 스킬은 코어가 필요할 때 불러오는 절차 기억 문서입니다. 영상은 이 코어와 스킬의 관계를 먼저 확인해야 제품의 확장성을 읽을 수 있다고 말합니다.

▲ 코어와 스킬 두 층 (영상 3:19)

기준은 단순합니다. 기능이 코어 안에 박혀 있는지, 아니면 스킬로 계속 늘어나는지에 따라 확장성이 갈립니다. 코어에 박힌 기능은 제품 공급자가 새 버전을 낼 때만 바뀌지만, 스킬로 늘어나는 기능은 조직이 자기 절차를 문서로 쌓아 가며 키울 수 있습니다. 화면은 코어를 고정된 실행 본체, 스킬을 쌓이고 갱신되는 층으로 구분해 적어 둡니다.

이 구분은 뒤에서 나올 대조표와도 이어집니다. 여덟 항목의 첫 번째인 절차 기억을 제품이 어떻게 제공하는지가 바로 스킬 체계에 달려 있기 때문입니다. 조직의 반복 업무를 에이전트에 맡길 계획이라면 스킬이 어떻게 만들어지고 갱신되는지를 도입 검토의 첫머리에 두는 편이 좋습니다.

세 갈래 가운데 오른쪽 갈래인 모델 제공자는 영상이 가장 먼저 짚는 교체 대상입니다. 영상은 도구와 모델 갈래는 선택지를 이름까지 밝혔다고 말합니다. 반면 채널 갈래는 통칭 수준까지만 공개되어 있다는 점을 대비시킵니다.

▲ 모델 제공자 갈래의 선택지 (영상 1:04)

이 말은 갈래마다 공개한 정보의 깊이가 다르다는 뜻입니다. 모두 교체 가능이라는 같은 표시가 붙어 있어도, 어떤 선택지가 실제로 있는지를 이름까지 확인할 수 있는 갈래와 통칭만 확인되는 갈래는 검증 가능성이 다릅니다. 도입 담당자는 교체 가능이라는 표지 하나로 안심하지 말고, 우리 조직이 쓰는 모델과 메신저가 목록에 실제로 있는지를 갈래별로 대조해야 합니다.

특히 채널 갈래는 조직이 쓰는 사내 메신저가 지원 대상에 들어 있는지를 직접 확인해야 하는 부분입니다. 통칭 수준의 공개는 문서만으로는 지원 여부를 단정할 수 없다는 신호이므로, 시험 설치 때 사용할 채널을 하나 골라 실제로 요청이 오가는지를 점검 목록에 올려 두는 것이 좋습니다.

세 갈래에 교체 가능 표시가 붙은 의미를 영상은 이렇게 풀어 줍니다. 한 갈래를 바꾸려고 나머지를 함께 바꿀 필요가 없다는 것입니다. 전등을 갈아 끼우려고 건물 배선을 다시 하지는 않는다는 비유가 이어집니다. 구성 요소가 독립적이라는 점은 제품 구성을 평가할 때 분명한 장점입니다.

▲ 교체 가능성과 운영 비용 (영상 3:33)

다만 영상은 아래 주황색 줄을 함께 보라고 당부합니다. 모델을 바꾸는 순간 프롬프트 캐시가 초기화되고, 전환 직후 첫 요청은 대화 전체를 다시 읽는 비용을 치릅니다. 그래서 교체 가능성은 운영 비용과 함께 따져야 합니다. 바꿀 수 있다는 사실과 바꿔도 공짜라는 사실은 다릅니다.

실무에서는 이 한 줄이 모델 전환 계획에 영향을 줍니다. 모델을 자주 갈아 끼우는 운영 방식이라면 전환 직후의 비용 증가를 예산에 넣어 두어야 하고, 전환을 한밤중이나 요청이 적은 시간대에 모으는 식의 운영 규칙도 필요해집니다. 구조는 유연하지만 유연함에는 가격이 있다는 점을 영상은 구조 그림 바로 아래에 적어 두었습니다. 이 한 줄 덕분에 AI 에이전트 제품 구성의 장점과 비용을 같은 화면에서 함께 읽을 수 있습니다.

구조를 확인한 영상은 여덟 항목을 이 제품에 하나씩 대 봅니다. 대조표는 두 번째 파트의 결론이고 뒤에 이어지는 모든 확인의 뼈대입니다. 표는 왼쪽부터 항목, 제품 기본 제공 여부, 근거 출처, 그리고 자세히 다루는 쪽 번호로 이뤄집니다.

▲ 8가지 항목별 기본 제공 여부 (영상 4:34)

결과부터 말하면 일곱은 제공이고 하나는 제공 없음입니다. 영상이 짚는 대응은 다음과 같습니다. 작업에 대한 기억은 스킬 체계가 맡고, 채널 통합은 채널 게이트웨이가 맡습니다. 실행 격리와 권한 분리, 위험 명령 승인은 공식 보안 문서가 밝힌 여덟 계층 안에 들어 있습니다. 화면의 근거 출처 칸에는 스킬 문서와 FAQ, 기능 개요 문서, 보안 문서, 연동 문서가 항목마다 달리 적혀 있습니다.

화면의 대조표를 항목 순서대로 옮기면 다음과 같습니다.

이 표가 말하는 범위도 영상은 분명히 합니다. 표가 보여 주는 것은 공식 문서에 기능으로 나와 있다는 사실까지입니다. 식당 메뉴판에 요리 이름이 적혀 있다는 것과 그 요리가 늘 같은 맛으로 나온다는 것은 다른 이야기라는 비유가 따라옵니다. 문서에 적혀 있다는 확인과 실제 운영에서 견고하다는 확인은 수준이 다르므로, 이 표를 곧바로 운영 적합 판정으로 읽으면 안 됩니다.

표의 맨 아래 주황색 줄이 이번 영상의 중심입니다. 여덟 번째 항목인 실행 결과 검증은 보안 문서에도, 기능 문서에도 나오지 않습니다. 화면에는 제공 없음이라는 표시와 함께 근거로 삼을 공식 기술이 없다고 적혀 있고, 자세히 다루는 곳은 네 번째 파트로 안내됩니다.

▲ 빈칸으로 남은 실행 결과 검증 (영상 5:37)

영상은 이 빈칸을 지금 드러내 두어야 뒤의 이야기가 근거를 갖는다고 설명합니다. 채워진 일곱만 앞세우고 빈 하나를 뒤로 미루면 듣는 쪽은 여덟이 다 채워진 자료로 받아들이게 되기 때문입니다. 제품 소개 자료가 흔히 빠지는 함정을 스스로 막아 둔 셈입니다.

도입 담당자에게 남는 일은 분명합니다. 이 항목은 제품이 해 주지 않으므로 조직이 어떻게 메울지 따로 설계해야 합니다. 영상은 마지막에 전체 발표 자료가 아래 링크에 있다고 안내하고, 에이전트 제품을 고르는 기준을 계속 보려면 구독해 달라는 말로 끝납니다. 이어지는 파트가 어떻게 이 빈칸을 다루는지가 다음 확인 지점입니다. 정리하면 AI 에이전트 제품 구성의 확인은 채워진 칸을 세는 일보다 비어 있는 칸을 찾아 이름을 붙이는 일에 가깝습니다. 비어 있는 칸에 이름이 붙어 있어야 담당 부서와 확인 기한도 붙일 수 있기 때문입니다.

AI 에이전트 제품 구성은 설치 전제, 두 층, 세 갈래, 여덟 항목의 기본 제공 여부를 차례로 확인하고, 문서에 없는 값은 빈칸으로 남겨 조직이 직접 메우는 순서로 점검해야 합니다.

AI 에이전트 제품 구성은 무엇부터 확인하나요?

런타임 본체와 바깥 세 갈래의 구조를 먼저 보고, 그다음 설치 전제와 여덟 항목의 기본 제공 여부를 확인합니다. 영상은 구조 그림을 모든 확인의 지도로 삼고, 마지막에 여덟 항목 대조표로 결론을 모읍니다.

Hermes Agent 설치 전제는 무엇인가요?

Python 3.11, Node.js, ripgrep 세 가지가 전부라고 영상은 설명합니다. 목록이 짧아서 대부분의 사내 서버는 추가 구매 없이 이 조건을 채우고, 5달러짜리 가상 서버부터 GPU 클러스터까지 실행 범위를 선언했다고 합니다.

CPU와 메모리 사양은 얼마로 잡아야 하나요?

공식 문서에 최소 CPU 코어 수, 메모리, 디스크 수치가 명시되어 있지 않아 시험 설치로 직접 측정해야 합니다. 영상은 역세권이라는 말만 듣고 계약할 수 없는 것처럼, 실제 작업량에 맞는 크기는 조직이 가늠해야 한다고 설명합니다.

코어와 스킬은 무엇이 다른가요?

코어는 작업을 진행하는 고정된 실행 본체이고, 스킬은 코어가 필요할 때 불러오는 절차 기억 문서입니다. 기능이 코어 안에 박혀 있는지 스킬로 계속 늘어나는지에 따라 제품의 확장성이 갈린다고 영상은 설명합니다.

모델을 바꾸면 비용이 드나요?

모델을 바꾸는 순간 프롬프트 캐시가 초기화되어 전환 직후 첫 요청이 대화 전체를 다시 읽는 비용을 치릅니다. 채널 설정과 스킬은 그대로 유지되지만, 영상은 교체 가능성을 운영 비용과 함께 따져 보라고 설명합니다.

여덟 항목 가운데 기본 제공되지 않는 것은 무엇인가요?

여덟 번째 항목인 실행 결과 검증이며, 보안 문서와 기능 문서 어디에도 근거가 없습니다. 나머지 일곱은 공식 문서에 기능으로 명시되어 있지만, 영상은 문서에 적힌 것과 실제 운영에서 견고한 것은 수준이 다르다고 덧붙입니다.

AI 에이전트 제품 구성을 더 깊이 살펴볼 때 볼 원 영상과 이어서 읽을 글, 개념 문서를 모았습니다.

• 에이전틱 AI 거버넌스 가이드 — 승인과 감사 절차 설계
• AI 에이전트란 무엇인가 — 에이전트 구조의 기본 개념
• 에이전틱 AI란 무엇인가 — 에이전트가 판단과 실행을 이어 가는 방식
• LLM이란 무엇인가 — 에이전트 뒤에 붙는 모델의 기본 원리
• Hermes Agent 아키텍처 – 02. 기업이 AI 에이전트에 요구할 8가지 — 클라우드네이티브TV, 이 글이 정리한 원 영상
• MSAP.ai 솔루션 문의 — 도입 검토 상담
• MSAP.ai 홈페이지 — 제품과 자료 모음
• Intelligent agent — 에이전트 개념의 일반 설명
• Software performance testing — 시험 설치와 부하 시험의 일반 개념
• Capacity planning — 용량 계획의 일반 개념
• Principle of least privilege — 권한 분리의 일반 원칙
• Chatbot — 응답형 도구의 일반 개념