AI 에이전트를 조직의 자산으로 만드는 방법

어느 회의를 가도 AI를 써야 한다는 말이 빠지지 않습니다. 그런데 정작 어떻게 쓸 것인가에 대해서는 답이 조금씩 다릅니다. 도구를 하나 더 결제하면 되는 일인지, 팀 워크숍을 몇 번 돌리면 되는 일인지. 2026년 하반기 AI 전환 방향을 정리하며, 업무 경험을 조직에 남기는 방법에 집중했습니다. 결론부터 말하면, AI를 기존 업무 위에 얹는 기능으로 보지 않기로 했습니다. 일하는 방식 자체를 에이전트 위에서 다시 짜는 쪽으로 가닥을 잡았습니다.

얼마나 쓰느냐가 아니라, 얼마나 잘 쓰느냐

많은 조직이 AI 활용도를 성과로 잡습니다. 몇 명이 얼마나 자주 쓰는가, 워크숍을 몇 번 돌렸는가, 라이선스 활용률이 몇 퍼센트인가. 첫걸음으로는 의미가 있습니다. 다만 사용량만으로 업무 성과를 판단하기는 어렵습니다. 워크숍에서 얻은 경험도 프롬프트와 작업 절차, 검증 기준으로 기록하지 않으면 조직 차원에서 재사용하기 어렵습니다.

그래서 기준을 바꿨습니다. 사용자 수나 호출 횟수, 토큰량 대신 우리 업무에 맞는 에이전트가 얼마나 효율적으로 일하는가, 그리고 그 에이전트가 얼마나 누적 자산으로 쌓이는가를 봅니다. 에이전트는 한 번 잘 만들어 두면 운용하고, 재사용하고, 확장할 수 있습니다. 에이전트 자체가 자산이 되는 것입니다.

• 운영 효율성 — 반복·정형 작업이 얼마나 자동화되는지, 호출당 비용은 어떤지, 산출물 품질은 유지되는지. 목표는 담당자가 판단과 기획, 결과 검토에 더 많은 시간을 쓸 수 있도록 하는 것입니다
• 누적 자산 — 운영 중인 에이전트와 사내 RAG 자산이 매 분기 쌓여 가는 것. 작년에 만든 에이전트가 올해 신입의 첫 출근날부터 작동하고 있다면, 그것이 자산화된 상태입니다

스스로에게 던지는 질문은 하나로 줄었습니다. 우리의 에이전트들은 이번 분기 회사를 얼마나 효율적으로 만들었고, 자산으로 얼마나 쌓였는가.

도구와 업무 흐름을 연결하는 허브

AI 전환의 핵심은 도구를 몇 개 쓰느냐가 아니라 그 도구들을 무엇을 중심으로 엮느냐입니다. 그래서 AI 에이전트 워크스페이스가 자동화 흐름의 중심, 곧 허브가 되는 구조를 택했습니다. 슬랙·메일·광고 매체·노션 같은 외부 도구는 Webhook으로 이벤트를 허브에 보냅니다. 반대편에서 LLM·AI 디자인 도구·AI 개발 도구·사내 시스템은 MCP로 허브와 양방향으로 연결됩니다. 가운데 허브 안에는 자동화 엔진과 지식·오케스트레이션 계층이 자리합니다.

허브를 두는 이유는 연결 방식을 재사용하기 위해서입니다. N개의 도구와 M개의 시스템을 모두 개별 연결한다고 가정하면 연결 수는 N×M입니다. 각 도구와 시스템을 공통 허브에 연결하는 단순화된 모델에서는 N+M으로 표현할 수 있습니다. 실제 연동 수와 작업량은 API, 권한, 업무 흐름에 따라 달라집니다. 핵심은 새 도구를 추가할 때 기존 연동을 재사용하고, 개별 연결을 수정해야 하는 범위를 줄이는 데 있습니다.

고객 문의 처리를 예로 들면 다음과 같은 흐름을 설계할 수 있습니다. 고객이 홈페이지 문의 폼을 하나 남기면 그 이벤트가 Webhook을 타고 허브로 들어옵니다. 허브는 사내 RAG에서 관련 서비스와 과거 견적 이력을 찾아 맥락을 붙이고, MCP로 연결된 LLM에게 초안 답변과 예상 견적 범위를 뽑게 합니다. 결과는 다시 슬랙으로 담당자에게 알림이 갑니다. 담당자는 답변의 사실관계와 견적 조건, 고객에게 공개할 정보의 범위를 검토한 뒤 발송합니다. 허브는 이 과정의 실행 순서와 결과 전달을 관리하고, 최종 판단은 담당자가 맡습니다.

Webhook과 MCP를 나눈 것은 방향과 성격이 다르기 때문입니다. Webhook은 무슨 일이 생겼다는 신호가 바깥에서 허브로 들어오는 단방향 통로입니다. 문의가 왔다, 메일이 도착했다, 캠페인 지표가 바뀌었다 같은 이벤트를 받는 입구입니다. 반면 MCP는 허브가 이 도구를 지금 이렇게 써 달라고 지시하고 결과를 되받는 양방향 통로입니다. 들어오는 것은 Webhook, 부리는 것은 MCP. 이 둘을 분리해 두면 언제 반응할지와 무엇을 할지가 깔끔하게 나뉩니다.

이 구조에서 확인할 것은 연동의 재사용 가능성입니다. 도구별로 필요한 인증과 권한, 데이터 형식을 정리하고 공통으로 쓸 수 있는 연결을 먼저 구축합니다. 새 도구를 추가할 때는 기존 연결을 활용할 수 있는지, 별도 개발과 유지보수가 얼마나 필요한지 검토합니다.

마지막으로, 허브는 원칙을 새기기에도 좋은 자리입니다. 자동화가 빨라질수록 통제는 오히려 더 중요해집니다. 도구마다 흩어져 있으면 누가 무엇을 했는지 추적하기 어렵지만, 모든 흐름이 허브를 지나가면 감사 로그와 권한 격리, 스타일 잠금을 한곳에서 걸 수 있습니다. 어떤 에이전트가 어떤 데이터에 접근했는지 남기고, 브랜드 톤을 벗어난 산출물을 걸러내고, 민감한 시스템은 권한을 나눠 두는 것을 개별 도구가 아니라 허브 차원에서 관리합니다. 이러한 기준을 공통으로 적용하고 실행 기록을 점검할 수 있도록 하는 것이 허브의 또 다른 역할입니다.

하나의 워크스페이스, 두 개의 트랙

허브가 정해졌으면 그 위에 무엇을 올릴지를 정해야 합니다. 성격이 다른 두 트랙으로 나눴습니다. 모든 에이전트를 같은 무게로 다루면 오히려 비효율적이기 때문입니다. 개별 업무에 빠르게 적용할 에이전트와 전문 영역을 지속적으로 운영할 에이전트는 구축 범위와 관리 방식이 다릅니다.

• Micro Agent 트랙 — 보고서 작성, 규정 검토, 데이터 분석처럼 단일 목적의 소형 에이전트입니다. 작은 범위로 만들고 빠르게 검증하며, 업무가 달라지면 수정하거나 교체합니다. 검증한 프롬프트와 작업 절차는 다음 업무에서도 활용합니다
• Professional Agent 트랙 — SEO/GEO 최적화나 사이트 운영처럼 전문 영역을 전담합니다. 브랜드 자료와 업무 기준을 연결하고, 운영 결과를 바탕으로 지식과 워크플로우를 갱신합니다. 정기적인 점검과 개선을 전제로 운영합니다

Micro는 개별 업무의 빠른 적용에, Professional은 전문 영역의 지속적인 운영에 초점을 둡니다. 두 트랙 모두 하나의 워크스페이스에서 공용 인프라와 권한·검증 기준을 공유합니다.

업무 영역에 따른 네 개의 라인업

두 트랙 위에 네 개의 라인업을 배치했습니다. 가운데 코어 플랫폼인 AI 에이전트 워크스페이스를 두고, Track 1에는 A와 D 라인이, Track 2에는 B와 C 라인이 얹힙니다. 공개된 서비스는 아래 라인업에서 바로 확인할 수 있습니다.

• LINE A · 콘텐츠 & 전략 — 전략 기획, 카피라이팅, 번역, 서비스 기획과 운영 업무 지원, 마케팅 리포트
• LINE D · 디자인 & 제작 — 텍스트 목업, 카피라이팅, 기획안 점검, 3D 오브젝트, 번역
• LINE B · 검색 최적화 — SEO 분석, GEO 최적화, 검색 트렌드 모니터링, 키워드 리포트와 콘텐츠 최적화
• LINE C · 사이트 운영 점검 — NX SENTINEL을 통한 사이트 상태·보안 설정 점검, SEO·GEO·웹 접근성 진단, 회차별 결과 기록과 변화 추적

AI 에이전트, 이렇게 만든다

각 에이전트는 정의 → 구축 → 검증 → 운영의 4단계로 만듭니다. 단계마다 목표와 산출물, 판단 기준을 기록해 담당자가 바뀌어도 작업을 이어 갈 수 있도록 합니다.

정의에서는 자동화할 업무와 목표, 성공 기준, 적용 범위를 정합니다. 구축에서는 자료와 도구 연결, 프롬프트와 워크플로우 설계, 프로토타입 구현을 진행합니다. 업무에 필요한 자료를 준비하고 적합한 연동 방식을 선택한 뒤, 작은 범위에서 결과물을 확인합니다.

검증에서는 담당자가 결과의 사실관계와 품질을 확인하고, 정의 단계에서 정한 기준에 따라 운영 전환 여부를 판단합니다. 운영에서는 실행 결과와 오류를 모니터링하며 프롬프트, 워크플로우, 검증 기준을 갱신합니다. 검증한 구성과 운영 기록을 함께 남겨야 다음 업무에서도 재사용할 수 있습니다.

페이지 개선 에이전트를 예로 들면 네 단계는 다음과 같습니다.

• 01 정의 — 개편할 페이지와 고칠 기준을 정합니다. 검색 노출·본문 구조·웹 접근성 가운데 무엇을 볼지, 어디까지 고쳐지면 된 것으로 볼지를 여기서 정합니다
• 02 구축 — 사이트 진단 결과와 브랜드 자료, 필요한 도구를 연결합니다. 확인·대조·수정안 작성 순서를 설계하고, 한 페이지를 대상으로 초안을 만들어 형식과 톤을 다듬습니다
• 03 검증 — 담당자가 수정안을 원본과 대조해 사실과 톤을 확인합니다. 정의 단계에서 정한 기준에 따라 반영 여부를 판단합니다
• 04 운영 — 페이지가 바뀔 때마다 같은 순서로 돌립니다. 검증한 프롬프트와 판단 기준을 남겨 다음 개편에서도 활용할 수 있도록 합니다

이해를 돕기 위한 예시입니다. 실제 적용 시 데이터와 검증 범위는 프로젝트에 맞춰 조정합니다.

이 프로세스를 지탱하는 원칙은 세 가지입니다. 첫째, 작게 시작합니다. 완벽한 설계보다 개념 검증 초안이 먼저입니다. 돌아가는 것을 보고 다듬는 편이 빠르고 안전합니다. 둘째, 검증을 먼저 설계합니다. 무엇을 사람이 확인할지를 도입과 동시에 정합니다. 검증 없는 자동화는 위험만 키웁니다. 셋째, 자산으로 남깁니다. 프롬프트와 워크플로우를 문서화해 재사용합니다. 한 번의 제작이 다음 프로젝트의 출발선이 되도록 합니다.

운영 기록이 다음 프로젝트의 기반이 됩니다

NX AGENT는 하나의 허브에서 두 트랙과 네 라인업을 운영하는 구조를 지향합니다. 각 업무에서 검증한 프롬프트와 워크플로우, 판단 기준을 함께 남기고 다음 프로젝트에 활용합니다. 이 기록이 쌓이면 팀은 이미 확인한 방법을 바탕으로 새로운 업무를 시작할 수 있습니다.

그리고 이것은 계획 단계의 이야기가 아닙니다. 아이파트너즈는 현재 AI 전환을 진행 중입니다. 앞서 그린 허브와 트랙, 라인업을 실제 업무에 하나씩 올리며 만든 에이전트를 검증하고 운영으로 넘기는 일을 이어 가고 있습니다.