"AI 에이전트 비용은 인건비인가?" — AI 에이전트 BPO를 직접 구현하는 쪽의 대답

얼마 전 어떤 신문 기사를 보니, **"사원이 되어 가는 AI 에이전트, 비용은 인건비? 인사와 IT의 경계를 녹인다"**라는 기사를 실었다.

읽고 나서 나도 모르게 "그거, 저희는 이미 설계 사상으로 구현하고 있는데요"라는 말이 튀어나왔다.

필자는 이미 PersonaOS라는 **"AI 에이전트를 '사원'으로서 기업에 파견하는 BPO 플랫폼"**을 만들어서 무료로 테스트 버전을 공개하고 있다. 신문에서 "앞으로 일어날 일"로 쓴 논점은, 우리에게는 "어떻게 만들지 이미 정해 둔 선택" 그 자체였다.

이 글은 언론이 던진 세 가지 질문 — ① 비용은 인건비인가 ② 그 속은 무엇인가 ③ 인사와 IT의 경계는 정말 녹는가 — 에 대한, 구현하는 쪽의 대답이다.

---

질문 ①: 비용은 "인건비"인가?

답은 Yes다. 비유가 아니라 과금 모델 차원에서 그렇게 만들고 있다.

많은 AI 프로덕트는 "툴"로 팔린다. 좌석 수(시트)나 API 호출 수, 기능 언락으로 과금하는 SaaS 모델이다. PersonaOS는 여기서 명확하게 키를 틀었다.

도구를 팔지 않는다. 사람(AI 에이전트)을 파견한다.

채용 담당 에이전트, 경리 담당 에이전트 — 전문 페르소나를 "사원"으로 기업에 배치하고, 업무량에 대해 맨먼스로 계약한다. 가격이 "좌석 수"가 아니라 "해낸 업무"에 연동된다. 이건 요금표의 사정이 아니라, 프로덕트의 심지(= 절대 굽히지 않는 불변 조건)로 맨 처음에 고정했다.

언론이 "비용은 인건비?"라고 물었을 때, 시장은 아직 "SaaS인가 인력인가" 사이에서 헤매고 있다. 내 대답은, 과금 단위를 인건비 쪽으로 옮긴 순간 프로덕트를 만드는 방식이 전부 바뀐다는 구현상의 사실이다. 시트 과금이라면 "기능을 얼마나 싣는가"를 겨루지만, 맨먼스 과금이라면 "그 '사원'이 실제로 업무를 끝냈는가"만이 가치가 된다. Doing over Talking — 절차서를 돌려주는 게 아니라, 실제로 조작해서 업무에 반영한다. 이것이 BPO를 자처하기 위한 전제가 된다.

특히 한국에서 이 모델을 검토한다면 두 가지를 짚어 둘 필요가 있다. 첫째, 파견근로자보호법상 "파견"은 사람을 전제로 하므로 AI 에이전트 "파견"은 법적 파견이 아니라 업무위탁(BPO) 계약이며, 비용도 회계상 인건비가 아닌 외주용역비 등으로 계상하는 것이 일반적이다(본문의 "인건비"는 과금 단위 설계의 비유에 가깝다). 둘째, 채용·경리처럼 개인정보를 다루는 업무를 AI BPO에 맡기면 개인정보보호법 제26조의 처리위탁에 해당해 위탁 계약서 작성·수탁자 감독 의무가 발생하므로, 뒤에 나오는 테넌트 분리·감사 로그 같은 통제 설계가 계약 요건과 직결된다.

---

질문 ②: 그 "사원"의 속은 무엇인가?

답은 전부 Claude다. 우리는 에이전트를 "자작"하지 않는다.

여기가 엔지니어 독자에게 가장 전하고 싶은 설계 판단이다. PersonaOS의 아키텍처는 "뇌·손"으로 깔끔하게 나뉘어 있다.

• 뇌 = Claude (Managed Agents) — LLM 추론·브라우저 조작·판단은 전부 클라우드의 매니지드 에이전트 실행 기반이 맡는다.
• 손 = 자사 앱 — DB 쓰기, 외부 API 호출, 트리거 수신, 세션 라이프사이클 관리. 역할은 이 세 카테고리로 한정한다.

왜 추론 루프나 프롬프트 오케스트레이션 같은 에이전트를 자체적으로 떠안지 않는가. 모델의 진화 속도에 계속 올라타 있기 위해서다. 기반 모델이 똑똑해질 때마다 "사원"이 저절로 유능해지는 구조로 만들어 두면, 우리는 업무 인터페이스의 품질에만 집중하면 된다. 반대로 추론 루프를 자작한 순간 그것이 기술 부채가 되어, 모델 진화의 혜택을 스스로 막아 버린다.

"기반 벤더의 새 프리미티브는 적극적으로 받아들인다. 하지만 추론 엔진의 주축은 갈아타지 않는다" — 프리미티브 채택과 주축 교체를 혼동하지 말아야 한다. 이것도 심지로 명문화해 두었다.

여기서 Managed Agents는 Anthropic이 2026년 4월 퍼블릭 베타로 공개한 "Claude Managed Agents"를 가리킨다. 샌드박스 코드 실행, 체크포인트, 자격 증명 관리, 범위 지정 권한, 실행 추적까지 갖춘 관리형 에이전트 하네스 + 프로덕션 인프라로, 에이전트 루프를 직접 만들지 않고 클라우드에서 돌릴 수 있게 해 준다.

공식 소개: https://claude.com/blog/claude-managed-agents

여담: 이 판단을 지키기 위해 우리는 매일 도는 자기 개선 스카우트 에이전트를 따로 돌리고 있다. 외부의 AI 에이전트/BPO 뉴스와 기반(Anthropic)의 업데이트를 매일 모아, "프로덕트의 심지를 깨지 않고 받아들일 수 있는 것만" 골라 제안하게 한다. 이번에 이 신문기사를 물어 온 것도 그 에이전트다. 이 글 자체가, 어떤 의미에서는 AI 에이전트가 찾아온 화제에 대한 인간 쪽의 대답이기도 하다.

---

질문 ③: "인사와 IT의 경계"는 정말 녹는가?

답은 녹는다. 다만 "녹이면 안 되는 경계"를 동시에 긋지 않으면, 그냥 사고가 된다.

신문 헤드라인의 핵심은 여기에 있다고 본다. 지금까지 "AI 도입"은 정보시스템 부서(IT)의 일이었다. 하지만 PersonaOS가 노리는 건 비엔지니어 백오피스 담당자가 한국어로 "사원"에게 일을 부탁할 수 있는 세계다. 툴 설정도 API 연동도 아닌, 채용·온보딩의 경험으로 AI를 받아들인다. 1페르소나 = 1에이전트 = 1업무 플로. "경리 담당을 한 명 늘린다"는 감각에 가깝다. 이 의미에서 인사와 IT의 경계는 분명히 녹는다.

그런데 여기서부터가 구현의 본론이다. "사원"에게 전권을 위임해서는 안 된다. 경계를 녹이는 것과 통제를 내려놓는 것은 별개다. 우리는 오히려 녹이면 안 되는 경계를 기술로 단단히 긋고 있다:

• 되돌릴 수 없는·외부 작용이 있는 조작에는 인간 승인(HITL)을 끼운다 — 발송·지불·확정 같은 되돌릴 수 없는 행위는 리스크 등급에 따라 인간의 게이트를 거친다. "사원"은 제안까지만 하고, 방아쇠는 사람이 당긴다.
• 툴 접근은 단일 게이트에 집약한다 — 에이전트가 DB나 외부 API를 직접 만지는 것을 허용하지 않는다. 모든 조작을 하나의 제어층(MCP) 경유로 강제해서 테넌트 분리와 감사를 담보한다.
• 멀티 테넌트는 행(row) 레벨에서 경계 이탈을 봉쇄한다 — 여러 기업의 "사원"이 같은 기반에 함께 얹혀 있어도, 데이터가 org를 넘나들지 않는 설계를 토대에 둔다.

즉 PersonaOS의 대답은, "경계를 녹인다" = "무질서하게 만든다"가 아니다라는 것이다. 인사와 IT의 벽은 녹이지만, "AI에게 맡겨도 되는 범위"와 "사람이 쥐는 범위"의 경계는 오히려 종래보다 명시적으로 긋는다. 이 선 긋기야말로 BPO, 즉 업무를 맡는 책임의 실체라고 생각한다.

---

정리: 이건 미래 예측이 아니라, 이미 내린 설계 판단

신문 기사는 "앞으로 일어날 일"이라는 톤으로 쓰여 있었다. 구현하는 쪽에서 보면 세 질문의 답은 이렇게 된다:

언론의 질문	구현 쪽의 대답
비용은 인건비인가?	Yes. 과금 단위를 인건비 쪽에 두면 프로덕트를 만드는 방식이 전부 바뀐다
속은 무엇인가?	전부 Claude. 에이전트를 자작하지 않고 기반의 진화에 계속 올라탄다
인사와 IT의 경계는 녹는가?	녹는다. 다만 "사람이 쥐는 경계"는 기술로 단단히 다시 긋는다

"AI 에이전트의 비용은 인건비"는 캐치카피가 아니라 한번 고르면 되돌릴 수 없는 설계상의 분기점이다. SaaS로 팔 것인가, "사원"으로 파견할 것인가. 우리는 후자를 택했고, 그 귀결로 뇌(Claude)·손(앱)·통제(HITL/게이트/테넌트 분리)를 지금의 형태로 만들었다.

언론이 시장에 질문을 던져 준 것은 좋은 징조라고 생각한다. 이제 그 질문에 구현으로 계속 답해 나가는 것이 나의 일이다.