오픈소스 에이전트를 붙이면 자가학습이 될까 — Hermes Agent와 자체 구축의 차이

신진형 · 에스엘파워 · 2026.07.05

“자가 학습 기능이 내장된 오픈소스 에이전트가 있는데, 굳이 ERP에 컬럼과 테이블과 학습 루프를 직접 만들어야 하나?” AI 에이전트 기반 ERP를 설계하다 보면 반드시 마주치는 질문입니다. Nous Research의 Hermes Agent를 사례로, 에이전트 프레임워크의 ‘자가 학습’과 업무 시스템의 ‘자가 학습’이 왜 다른 것인지 검토한 기록입니다.

두 방안은 양자택일 관계가 아닙니다. 서로 다른 층(layer)의 학습을 담당하기 때문입니다. Hermes Agent 같은 에이전트 프레임워크의 자가 학습은 “일하는 방법”을 배우는 절차적 학습(스킬 자동 생성·개선, 사용자 모델링, 대화 기억)이고, ERP에 필요한 자가 학습의 핵심은 “판단이 옳았는가”를 업무 결과로 검증하는 의사결정 학습(감사 컬럼, 판단 원장, 결과 채점, 사람 피드백 폐루프)입니다. 프레임워크를 붙여도 후자는 저절로 생기지 않습니다. 합리적인 답은 층을 나누는 것입니다 — 의사결정 학습 루프는 자체 구축하고, 에이전트 프레임워크는 그 위에 얹는 접점·오케스트레이션 레이어로, 보안 검토를 전제로, 제한적으로 활용하는 구조입니다.

Hermes Agent는 무엇인가 — 사실 확인

Hermes Agent(Nous Research, MIT 라이선스)는 개인용 범용 AI 에이전트 프레임워크입니다. 공식 슬로건은 “The agent that grows with you”이고, 공개 문서가 밝히는 실체는 다음과 같습니다(2026-07-04 열람 기준).

기능	실제 내용 (README 기준)
학습 루프 (built-in learning loop)	에이전트가 큐레이션하는 메모리 + 주기적 자기 알림(nudge), 복잡한 작업 후 스킬 자동 생성, 사용 중 스킬 자가 개선, 과거 대화 전문 검색 + LLM 요약, Honcho 기반 사용자 모델링
실행 환경	CLI/TUI, 저가 VPS부터 GPU 클러스터까지, Docker·SSH·서버리스 등 6종 백엔드
접점	Telegram·Discord·Slack·WhatsApp·Signal·이메일 게이트웨이, 음성 메모 전사
자동화·확장	내장 cron 스케줄러, 서브에이전트 병렬 실행, MCP 서버 연동, 도구 RPC 스크립팅
모델	200+ 모델 자유 선택, 특정 모델 종속 없음

두 방식의 ‘학습’은 서로 다른 것을 배운다

같은 "자가 학습"이라도 배우는 대상이 다릅니다. 에이전트 프레임워크는 절차(how)를, ERP 학습 루프는 판단의 정오(whether right)를 배웁니다. 전자는 후자를 대체하지 못합니다.

구체적인 예로 보면 차이가 분명합니다. HR 에이전트가 승진 추천을 냈을 때 —

에이전트 프레임워크가 배우는 것	ERP 학습 루프가 배우는 것
”승진 검토 요청이 오면 인사 API를 이 순서로 조회하고, 보고서는 이 형식으로 쓴다”는 절차(스킬). 다음에 같은 요청이 오면 더 빠르고 매끄럽게 처리합니다. 그러나 그 추천이 3개월 뒤 옳았는지는 알 길이 없습니다 — 업무 결과 데이터와 연결돼 있지 않기 때문입니다.	결재권자가 “일부 맞음 — 조직 규모도 봐야 함”이라고 남긴 사유, 30일 후 자동 채점된 결과 점수, 1,000건에서 발견된 승인 패턴. 즉 판단 품질 자체가 개선됩니다. 그리고 이 모든 것이 DB에 남아 감사·증빙이 됩니다.

“에이전트 프레임워크의 ‘자가 학습’과 업무 시스템의 ‘자가 학습’을 혼동하는 것이 요즘 가장 흔한 착시다. 전자는 에이전트가 유능해지는 것이고, 후자는 조직의 의사결정 데이터가 자산화되는 것이다. 프레임워크를 갈아 끼워도 후자는 따라오지 않는다 — 후자는 당신의 DB 스키마와 업무 코드에 살기 때문이다.” — 엔터프라이즈 AI 아키텍트 관점의 공통 견해

의사결정 학습 루프를 실제로 어떻게 짓는지는 〈자가학습 설계 청사진〉에 정리했습니다.

정면 비교 — 자체 구축 vs 프레임워크 연동

평가 축	① 자체 구축 (컬럼+테이블+학습 로직)	② Hermes 연동 + 업무별 에이전트 배정
학습의 대상	판단 품질 — 업무 결과로 검증되는 의사결정 학습	절차·맥락 — 스킬·메모리·사용자 모델 중심, 업무 결과와 미연결
감사·증빙	강함 — 감사 컬럼+판단 원장이 그대로 내부통제 증빙	약함 — 학습 산출물이 파일·로컬 DB에 산재, “왜 그렇게 판단했나”의 법적 증빙 곤란
HITL 통제	내장 — 민감 업무는 승인 큐 통과가 구조적으로 강제	별도 구축 — 명령 승인(allowlist)은 있으나 업무 결재 워크플로와는 무관
초기 구축 속도	느림 — 학습 엔진+스키마+도메인별 코드, 수개월 단위	빠름 — 설치 즉시 대화·스킬·cron·메신저 접점 확보
운영 편의	직접 개발 — 스케줄러·알림·채널 연동을 직접 구현	우수 — 메신저 게이트웨이, cron, 서브에이전트, 모델 스위칭 기본 제공
보안·데이터 주권	내부 통제 — 데이터가 ERP 경계 안에 머무름	신중 필요 — 셸 실행 권한을 가진 외부 프로세스 + 외부 모델 API로 인사·회계·계약 데이터가 흐르는 경로 발생
멀티유저	ERP 권한체계 그대로	개인 지향 — 1인 사용자 전제 설계. 부서별 권한 분리·직무 분리(SoD)는 자체 몫
종속·지속성	내부 유지보수 부담	MIT라 코드 종속은 낮으나, 빠르게 변하는 오픈소스 — 기업 SLA·장기 로드맵 보장 없음
비용	개발 인건비 중심	라이선스 무료, 그러나 통합·보안 감사·운영 비용은 별도 발생 (숨은 비용)

”업무별 에이전트를 배정하면 자가 학습이 된다”는 기대의 검증

부분적으로만 사실입니다. 기대를 층별로 나눠 보면 이렇습니다.

기대	실현 여부	이유
도메인별 에이전트가 반복 업무의 절차를 점점 잘하게 된다	대체로 실현	스킬 자동 생성·자가 개선, 대화 기억은 실제 내장 기능
에이전트가 우리 회사 결재권자의 판단 기준을 배운다	제한적	메모리에 단편적으로 남을 수는 있으나, 구조화된 수정 사유·피드백 수집이 없어 통계적 학습 불가
에이전트의 추천이 실제 업무 결과로 검증되어 개선된다	미실현	결과 검증 파이프라인이 없음. ERP DB의 결과 데이터와 연결하는 코드는 결국 직접 만들어야 함
학습 내용이 감사 가능한 형태로 남는다	미실현	파일 기반 메모리·스킬은 “누가 언제 어떤 근거로”의 증빙 요건을 충족하지 못함
여러 부서가 권한 분리된 상태로 각자의 에이전트를 쓴다	미실현	개인용 설계. 멀티테넌시·직무분리는 별도 구축 필요

요컨대 프레임워크에 업무별 에이전트를 배정하면 **“일 잘하는 비서”**는 빨리 얻지만, **“판단이 검증되고 개선되는 ERP”**는 얻지 못합니다. 후자를 원하면 판단 원장·피드백·결과 검증을 ERP 쪽에 구축해야 하고, 그 순간 자체 구축 작업의 대부분이 그대로 필요해집니다.

세 가지 전문가 시점

“프레임워크 도입으로 절약되는 것은 에이전트 런타임(대화·도구 호출·스케줄링·채널)이지, 도메인 학습 루프가 아니다. 런타임은 사서 쓰고 루프는 직접 만든다 — 이것이 표준 답안이다. 거꾸로 루프를 외부에 맡기고 런타임을 직접 만드는 회사는 없다.” — ① 엔터프라이즈 아키텍트 관점

“인사·급여·계약 데이터가 셸 접근 권한을 가진 외부 오픈소스 프로세스를 경유해 외부 LLM API로 나가는 구조는, 그 자체로 개인정보·내부통제 감사 대상이다. 개인용으로는 훌륭한 보안 모델(명령 승인, DM 페어링)이 기업 기준으로는 출발점일 뿐이다. 도입한다면 격리된 파일럿, 비민감 도메인, 읽기 전용 연동부터.” — ② 보안·컴플라이언스 관점

“Hermes의 스킬 자동 생성은 배울 점이 많다 — ‘복잡한 작업이 끝나면 절차서를 스스로 남긴다’는 발상은 ERP의 Reflection 엔진에 그대로 이식할 수 있다. 채택 여부와 무관하게 이 프로젝트는 자체 루프 설계의 좋은 레퍼런스다. 다만 이들의 학습 루프에 결과(Outcome) 검증이 없다는 점이, 개인 비서와 업무 시스템의 요구 차이를 정확히 보여준다.” — ③ ML 시스템 운영 관점

결론 — 층을 나눠서 취한다

권장 구조. 어떤 에이전트 런타임을 쓰든 판단은 반드시 가운데 레이어(자체 구축)를 통과해 기록·승인·검증됩니다. 런타임은 교체 가능한 부품, 학습 레이어는 회사의 자산입니다.

이 구조의 이점은 명확합니다. 에이전트 런타임이 무엇이든 판단은 반드시 ERP의 학습 레이어를 통과하므로 감사·학습·통제가 유지되고, 런타임이 마음에 안 들면 갈아 끼우면 됩니다. 반대로 런타임에 학습을 맡기면 도구 교체가 곧 학습 자산의 소실이 됩니다. “어떤 작업에 어떤 모델을 붙이고, 그 선택을 나중에 바꿀 수 있게 하는가”라는 같은 원칙을 LLM 선택에 적용한 기록은 〈어떤 LLM을 도입할 것인가〉에 있습니다.

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.