LightAgent·Hermes 같은 오픈소스 AI 에이전트를 회사 업무에 붙이기 전 볼 운영표 2026

Posted on by

오픈소스 AI 에이전트는 2026년에 “한 번 써볼 장난감”에서 “회사 업무에 붙여도 되나”라는 질문으로 넘어왔다. LightAgent는 memory, MCP, skill, multi-agent collaboration, self-learning을 강조하고, Hermes Agent는 경험에서 스킬을 만들고 persistent memory와 여러 실행 채널을 붙이는 방향을 내세운다. 말만 들으면 사내 운영 자동화가 갑자기 책상 위로 걸어 들어오는 느낌이다.

그런데 회사 업무에 붙일 때 진짜 질문은 “똑똑하냐”보다 “어디까지 하게 둘 거냐”다. 파일을 읽고, 메모리를 남기고, 스킬을 학습하고, Slack이나 CLI 같은 채널로 실행되는 순간 에이전트는 그냥 챗봇이 아니다. 업무 흐름 안에서 행동하는 작은 런타임이 된다.

이 글은 LightAgent나 Hermes를 설치해서 성능을 비교하는 후기가 아니다. 2026년 6월 1일 기준 공개 GitHub 문서, LightAgent 논문, Hermes Agent 공개 repo, 그리고 내 로컬 워크스페이스의 AGENTS.md·skills·publisher preflight 운영 경험을 기준으로 “회사 업무에 붙이기 전 무엇을 잠가야 하나”를 정리한 운영표다. 데모는 빨리 켜지고, 운영은 느리게 터진다. 그래서 먼저 느린 표를 만든다.

먼저 봐야 할 6칸

LightAgent와 Hermes류 에이전트를 검토할 때 첫 화면에서 기능 목록만 보면 전부 좋아 보인다. memory, skills, MCP, session, self-learning, messaging, cron 같은 단어는 자동화 욕심을 아주 정중하게 자극한다. 문제는 이 단어들이 편의 기능이면서 동시에 운영 리스크라는 점이다.

첫 검토표는 아래처럼 잡는 편이 낫다. 기능을 켜기 전에 이 기능이 실패했을 때 무엇이 남고, 누가 멈추고, 어디까지 복구할 수 있는지를 먼저 본다.

항목 물어볼 질문 회사 업무 첫 기준
권한 파일, 네트워크, 외부 API를 어디까지 열 것인가 read-only부터 시작
메모리 무엇을 장기 기억으로 남길 것인가 고객정보·비밀키·개인정보 금지
스킬 학습 실패 경험을 자동으로 스킬화해도 되는가 사람 리뷰 후 등록
실행 채널 Slack, Telegram, CLI 중 어디서 명령을 받을 것인가 채널별 권한 분리
로그 프롬프트와 결과를 어디까지 남길 것인가 원문보다 결정 흔적 중심
중단 언제 자동 실행을 멈출 것인가 오류 반복, 비용 초과, 범위 이탈

1. 메모리는 장점이 아니라 감사 대상이다

Hermes류 에이전트에서 가장 매력적인 부분은 “나를 기억한다”는 느낌이다. 지난 작업, 선호, 반복 실패, 자주 쓰는 스킬을 기억하면 확실히 편해진다. 회사 입장에서는 같은 기능이 바로 감사 대상이 된다. 에이전트가 무엇을 기억했고, 왜 기억했고, 언제 지울 수 있는지 설명할 수 있어야 한다.

개인 자동화에서는 “지난번처럼 해줘”가 편하다. 회사 업무에서는 그 문장이 위험할 수 있다. 지난번 작업에 고객명, 내부 URL, API 키 힌트, 미공개 매출 수치가 섞여 있었다면 장기 메모리는 편의 기능이 아니라 데이터 보관 정책의 일부가 된다.

그래서 첫 운영 기준은 단순하다. 장기 메모리는 기본 차단하고, 사람이 승인한 운영 규칙만 넣는다. 예를 들어 “배포 전 테스트 명령은 npm test다”는 메모리에 남겨도 되지만, “A 고객은 민감하게 반응한다” 같은 문장은 업무 편의보다 리스크가 크다. 기억력 좋은 동료도 인사팀 규정은 지켜야 한다.

2. 스킬 학습은 자동 등록보다 리뷰 큐가 먼저다

LightAgent와 Hermes가 말하는 skill이나 self-learning loop는 매력적이다. 반복 업무를 하면서 더 나은 절차를 배운다면 생산성이 올라간다. 하지만 회사 업무에서 자동 스킬 등록을 무작정 허용하면, 잘못된 우회 절차도 “배운 것”으로 굳을 수 있다.

내 로컬 블로그 운영에서도 비슷한 문제가 있다. 글을 발행할 때는 channel gate, preflight, publisher dry-run, sheet sync 같은 절차가 있고, 실패하면 그 실패를 바로 규칙으로 승격하지 않는다. 먼저 왜 실패했는지 보고, 재사용 가능한 규칙인지, 특정 날짜의 예외인지 나눈다. 에이전트 스킬도 같은 흐름이 필요하다.

회사에 붙인다면 스킬은 세 단계로 나누는 편이 안전하다. 후보 스킬, 검토 완료 스킬, 운영 스킬이다. 후보 스킬은 에이전트가 제안할 수 있지만 실행 권한은 없다. 검토 완료 스킬은 샌드박스에서만 실행한다. 운영 스킬은 버전과 소유자, 롤백 방법을 가진다. 귀찮아 보여도 이 정도가 없으면 “자동 학습”이 “자동 습관화”로 바뀐다.

3. MCP와 외부 도구는 이름부터 위험도를 드러내야 한다

LightAgent는 MCP/SSE 통합을 내세우고, 여러 오픈소스 에이전트도 도구 연결을 핵심 기능으로 둔다. 도구 연결은 에이전트의 손발이다. 문제는 손발이 생기면 사고도 손발 달고 온다는 점이다. 파일 읽기, GitHub 이슈 생성, Slack 메시지 전송, 결제 API 호출은 같은 “tool”이라는 단어 안에 넣기엔 위험도가 너무 다르다.

도구 이름에는 귀여운 별칭보다 위험도가 보여야 한다. github-read, github-issue-draft, github-pr-write, slack-read, slack-send-approved처럼 이름만 봐도 실행 범위를 알 수 있어야 한다. 팀원이 로그를 봤을 때 “이 에이전트가 무엇을 했는지”를 추측하지 않아도 되는 구조가 좋다.

특히 회사 업무에서는 쓰기 도구를 기본 차단하는 편이 낫다. 첫 주에는 read-only 조사, 두 번째 주에는 draft 생성, 세 번째 주에만 승인 후 write를 여는 식이다. 자동화는 단계적으로 열어도 늦지 않다. 오히려 처음부터 다 열면 나중에 줄이는 게 더 힘들다.

4. 실행 채널은 편의가 아니라 공격면이다

Hermes Agent나 OpenClaw류 도구는 Telegram, Discord, Slack, CLI 같은 채널 연결을 강조한다. 이건 개인에게는 정말 편하다. 회사에서는 채널이 늘어날수록 인증, 권한, 감사, 명령 오해 가능성이 같이 늘어난다.

예를 들어 Slack에서 “지난번 자료 정리해서 보내줘”라고 쳤을 때, 에이전트가 어느 워크스페이스를 보고, 어떤 파일을 읽고, 누구에게 보낼 수 있는지 경계가 필요하다. CLI에서 실행되는 명령과 Slack에서 들어온 명령은 같은 신뢰 수준이 아니다. 말투는 비슷해도 보안 문맥은 다르다.

운영표에는 채널별 허용 작업을 따로 적어야 한다. Slack은 질문 응답과 초안 링크까지만, CLI는 로컬 read-only 조사까지만, GitHub는 draft PR 생성까지만 같은 식이다. 채널을 나누지 않으면 가장 약한 채널의 보안 수준이 전체 에이전트의 기준이 된다.

5. 로그는 모든 원문보다 결정 흔적이 중요하다

에이전트 운영에서 로그를 남겨야 한다는 말은 쉽다. 실제로는 무엇을 남기느냐가 더 어렵다. 모든 프롬프트와 파일 원문을 남기면 나중에 디버깅은 쉬울 수 있지만, 그 로그 자체가 민감 데이터 묶음이 된다. 반대로 로그를 너무 줄이면 사고가 났을 때 설명을 못 한다.

첫 기준은 네 가지 로그다. 실행 로그에는 언제, 누가, 어떤 범위에서 실행했는지 남긴다. 도구 로그에는 어떤 도구가 호출됐고 성공했는지 실패했는지 남긴다. 결정 로그에는 왜 자동화가 멈췄는지, 왜 사람 승인이 필요했는지 남긴다. 리뷰 로그에는 사람이 확인한 결과와 반려 이유를 남긴다.

이렇게 나누면 원문 덤프를 줄이면서도 운영 설명이 가능해진다. “에이전트가 뭔가 했는데요”는 회사에서 가장 쓸모없는 로그 문장이다. 최소한 “무엇을 하려 했고, 어디서 멈췄고, 누가 승인했는지”는 남아야 한다.

6. 첫 도입은 업무 자동화보다 업무 관찰부터

처음부터 고객 메일 답장, 배포, 결제, DB 변경을 맡기는 것은 과하다. 첫 도입은 업무 관찰이 낫다. 예를 들어 회의록에서 액션 아이템 후보를 뽑고, 오래된 이슈를 분류하고, 문서 중복을 찾아내고, 실패한 CI 로그를 읽어 원인 후보를 표로 만드는 작업이다.

이런 작업은 에이전트가 틀려도 사람이 바로 확인할 수 있다. 결과물이 보고서라서 되돌리기도 쉽다. 반대로 고객에게 메시지를 보내거나, production 설정을 바꾸거나, 결제·개인정보·법무 문서를 건드리는 작업은 첫 달에 열지 않는 편이 좋다.

내 기준의 첫 30일 플랜은 이렇다. 1주차는 read-only 조사만 허용한다. 2주차는 내부 문서 초안과 이슈 분류까지 허용한다. 3주차는 샌드박스 안에서만 패치 초안을 만들게 한다. 4주차는 승인된 스킬 1~2개만 제한적으로 운영한다. 자동화는 멋있게 시작하는 것보다 오래 살아남는 게 중요하다.

도입 전 운영표

단계 허용 작업 금지 작업 통과 기준
0단계 문서 읽기, 코드 검색, 이슈 분류 파일 수정, 외부 전송 로그와 범위가 남음
1단계 보고서 작성, PR 설명 초안 자동 PR 생성, Slack 전송 사람이 결과를 승인
2단계 샌드박스 패치 초안 production 접근 테스트 명령과 diff 확인
3단계 승인된 반복 스킬 실행 개인정보·결제·배포 자동화 소유자·버전·롤백 기준 존재

내 기준의 채택 판단

LightAgent나 Hermes 같은 오픈소스 AI 에이전트를 회사 업무에 붙일 수 있느냐고 묻는다면, 답은 “가능하지만 바로 운영 자동화로 보지 말자”다. 먼저 관찰자, 그다음 초안 작성자, 그다음 제한된 실행자 순서가 맞다. 처음부터 팀원처럼 대하면, 입사 첫날 root 권한을 주는 것과 비슷하다.

좋은 에이전트의 기준은 데모 영상에서 얼마나 멋있게 움직이느냐가 아니다. 권한이 좁을 때도 쓸모가 있는지, 실패했을 때 멈출 수 있는지, 메모리를 지울 수 있는지, 스킬이 버전 관리되는지, 사람이 리뷰할 수 있는지다. 이 다섯 개를 통과하면 그때부터 기능 비교가 의미 있다.

FAQ

LightAgent와 Hermes 중 무엇을 먼저 봐야 하나?

회사 업무 기준이라면 기능 수보다 운영 경계가 더 중요하다. memory, skill, MCP, messaging, cron 같은 기능이 무엇까지 가능한지 보고, read-only로 시작할 수 있는 쪽부터 검토하는 편이 낫다.

오픈소스 AI 에이전트는 사내 데이터에 붙여도 되나?

가능 여부는 도구 이름이 아니라 배포 구조와 권한 설계에 달려 있다. 사내 데이터에 붙이기 전에는 저장 위치, 로그 정책, 외부 API 호출, 장기 메모리, 권한 회수 방법을 먼저 확인해야 한다.

self-learning 기능은 켜는 게 좋나?

처음부터 자동 등록은 피하는 편이 좋다. 에이전트가 제안한 스킬을 후보 큐에 넣고, 사람이 검토한 뒤 버전과 소유자를 붙여 운영 스킬로 승격하는 방식이 안전하다.

Slack이나 Telegram으로 명령하게 해도 되나?

할 수는 있지만 채널별 권한을 분리해야 한다. 메시징 채널은 초안 생성과 알림까지만 허용하고, 파일 수정이나 외부 전송은 별도 승인 또는 CLI에서만 허용하는 식이 낫다.

관련 글

참고 자료