이제 생성형 AI 시대를 넘어 에이전틱 AI 시대로 본격적으로 돌입했다. AI 에이전트가 코드를 쓰고, 장애를 분석하고, 이메일 초안을 쓰고, 계약서를 검토할 수 있게 되면서 회사 업무의 대부분은 AI 에이전트가 먼저 수행하고 사람은 승인하는 구조로 빠르게 바뀌고 있다. 여기서 고민해야 하는 문제는 위임의 방법이다. 부서별로 CS 에이전트, 영업 에이전트를 만드는 방식은 직관적이지만 책임과 권한이 흐려진다. 오히려 직원 한 명 한 명을 대표하는 AI 에이전트를 두고, 그 바탕에 조직이 합의한 언어인 온톨로지(Ontology)를 두는 방식이 보다 책임성 있는 AI 네이티브 회사를 만들 수 있다. 직원마다 대표 AI 에이전트를 만드는 에이전트경험(AX: Agent Experience)디자인 방식에 대해서 알아보자.
위임의 기본 값이 바뀐다: 사람이 해야만 하는 일만 남긴다
에이전틱 AI 시대의 업무 설계는 “무엇을 AI에게 맡길까”가 아니라 “무엇을 사람에게 남길까”에서 출발한다. 고객을 직접 만나고 전화로 관계를 맺는 일처럼 대면이 필요한 행위를 빼면, 회사 업무의 상당 부분은 규칙과 데이터와 일반적인 지능만 있으면 수행할 수 있다. 시스템 장애를 모니터링하고 원인을 분석해 조치 안을 만든 뒤 승인만 요청하는 일, 새 고객 문의가 오면 과거 이메일 이력을 조회해 답장 초안을 쓰는 일, 수백 항목의 보안 질의서에 초안을 채우는 일, 변호사에게 보내기 전 법률 검토 초안을 만드는 일이 모두 여기에 속한다.
이 관점을 끝까지 밀고 가면 회사 전체를 AI로 시뮬레이션할 수 있는 상태가 목표가 된다. 사람은 워크플로에서 조금씩 빠져나오고, 빠져나온 시간에 다음 일을 모의하고 결정한다. 여기서 에이전트는 도구가 아니라 동료이자 핵심 업무 수행 직원이고, 사람은 실행자가 아니라 승인자이자 설계자가 된다. 위임의 기본값이 ‘사람이 한다’에서 ‘에이전트가 먼저 한다’로 바뀌는 것이다.
직원마다 자신의 대표 AI 에이전트를 두어야 하는 이유
업무를 에이전트에게 위임할 때 가장 먼저 떠오르는 방식은 기능별 에이전트다. CS 에이전트, 영업 에이전트, 개발 에이전트를 만들어 부서의 일을 맡기는 것이다. 그러나 이 방식은 곧 한계에 부딪힌다. 에이전트가 틀렸을 때 누가 책임지는지, 누가 규칙을 고치는지가 불분명해지고, 에이전트마다 권한을 어디까지 줄지 정하기도 애매해진다. 결국 에이전트를 관리하는 새로운 직무가 생기고, 위임은 오히려 관리 부담으로 돌아온다.
대안은 위임의 단위를 사람으로 잡는 것이다. 직원마다 자신을 대표하는 AI 에이전트를 하나씩 두고, 동료가 그 사람을 멘션하면 에이전트가 먼저 그 사람이 했을 법한 답과 일을 수행한다. 본인은 나중에 확인해 맞으면 넘기고, 틀리면 무엇이 틀렸는지 교정 로그를 남긴다. 이 구조에서는 오너십이 분명하다. 내 에이전트의 품질은 내 책임이고, 권한도 나의 권한을 그대로 따른다. 무엇보다 시차가 다른 곳에 있는 동료, 휴가 중인 동료, 다른 업무로 옮긴 동료가 병목이 되지 않는다. 인수인계 없이도 그 사람의 판단 방식과 업무 맥락이 에이전트를 통해 조직에 계속 흐르기 때문이다. 대표 에이전트는 사람의 부재를 메우는 대리인이자, 개인의 암묵지를 조직에 남기는 그릇이 된다.
AI DESIGNER COMMUNITY
AI와 새로운 세상을 만들어가는 디자이너들과 함께 성장하세요.
대표 에이전트의 구조: 소울, 위키, 온톨로지
사람을 대표하는 에이전트는 세 개의 층으로 설계할 수 있다. 첫째는 소울(Soul) 층이다. 그 사람이 업무를 수행하며 사내 메신저에 남긴 대화를 기반으로 소울 문서(soul.md)로 정리한다. 여기에는 말투뿐 아니라 언제 대화에 개입하고 언제 한발 물러서는지 같은 판단의 습관이 담긴다.
둘째는 위키(Wiki) 층이다. 그 사람이 평소 보는 데이터, 참여한 회의와 대화 기록, 작성한 메일과 계약서처럼 개인이 쌓아 온 업무 맥락을 에이전트가 읽을 수 있는 지식으로 연결한다. 외국어 메일의 경우 특정 고객과의 계약 관행 같은 그 사람만 알던 노하우가 여기에 남는다.
셋째는 온톨로지(Ontology) 층이다. 누가 담당하든 회사 전체가 똑같이 지켜야 하는 규칙, 이를테면 고객 응대 원칙이나 매출 집계 기준은 개인 에이전트 안이 아니라 회사 공용 저장소 한 곳에 둔다. 핵심은 분리다. 개인의 고유한 경험은 소울과 위키에, 조직의 규칙은 온톨로지에 격리해 두고 이를 조합하면, 사람 단위로 에이전트를 만들어도 규칙은 흩어지지 않는다. 지적인 주체가 고유한 경험을 가진 채 조직의 규칙을 지키며 일한다는 점에서, 이 구조는 사람이 회사에서 일하는 방식을 그대로 담는 것이다.
온톨로지로 구축해야 하는 일은 무엇인가?
온톨로지라는 말은 흔히 개체와 관계의 그래프로 이해되지만, 업무 위임의 관점에서는 한 데이터 분석 기업이 제시한 정의가 더 쓸모 있다. 데이터(Data), 로직(Logic), 액션(Action)의 세 요소에 감사(Audit)와 권한(Permission)을 더한 다섯 요소다. 창고로 비유하면 이해가 쉽다. 페인트 회사에게는 창고의 색이 중요한 데이터지만 물류 회사에게는 크기와 적재 가능한 품목이 중요하다. 로직은 “창고가 비었다”를 무엇으로 정의할지다. 텅 빈 상태만 비었다고 할 수도, 열 개 들어갈 곳에 두 개만 있어도 비었다고 할 수도 있다. 액션은 비었을 때 무엇을 하는가이고, 권한은 누가 채우고 뺄 수 있는가, 감사는 1년 뒤에도 누가 접근했는지 추적할 수 있는가다.
모든 업무를 온톨로지로 만들 필요는 없다. 기준은 두 가지다. 이것이 절대 틀려서는 안 되는가, 그리고 조직 안에서 사람마다 다르게 말하면 문제가 생기는가. 발주를 넣거나 계약서에 금액을 쓰는 일, 매출 지표를 집계하는 일은 여기에 해당한다. 해외 고객이 국내에서 결제한 매출을 어느 지역 매출로 볼지를 사람마다 다르게 말하고 있다면, 그 정의가 온톨로지의 출발점이다. 반면 이메일 초안처럼 약간의 변주가 오히려 도움이 되는 일은 프롬프트와 위키, 그리고 충분히 똑똑한 모델의 지능에 맡기면 된다.
온톨로지는 회사의 모든 것을 담는 창고가 아니라,
어겨서는 안 되는 언어만 골라 담는 금고에 가깝다.
온톨로지 구축: 암묵지를 언어로 꺼내는 과정
온톨로지는 자동으로 만들어지지 않는다. 대화 기록과 문서에서 후보를 뽑아낼 수는 있지만, “우리는 앞으로 이것을 이렇게 부르고 이렇게 판단한다”고 확정하는 일은 결국 의사 결정자의 몫이다. 그래서 구축은 기술보다 언어를 정하는 과정에 가깝다. 출발점은 각 직원이 자기 업무를 최대한 자세한 업무 규칙으로 서술하는 것이다. 기준은 간단하다. 똑똑하지만 이 분야를 전혀 모르는 동료에게 문서 하나만 건네고 한 달 휴가를 떠난다면, 마음이 편하려면 무엇이 적혀 있어야 하는가를 생각해보자.
이렇게 모인 서술에서 공통 개념이 드러나고, 같은 단어의 다른 뜻이 발견된다. 내가 말하는 ‘고객’과 동료가 말하는 ‘고객’이 다르면 둘을 분리하고, 서버 오류만 ‘장애’라고 여겼는데 대화 기록을 보니 고객 문의로 들어온 불편도 장애로 다뤄 왔다면 정의를 넓힌다. 확정된 정의는 공용 저장소 하나에 스키마 형태로 쌓고, 사람과 에이전트가 모두 수정 요청을 올릴 수 있게 한다. 대신 정기적으로 규칙 충돌을 점검하는 과정을 둔다. 이 과정에서 가장 큰 가치는 온톨로지라는 결과물보다, 알아서 잘하던 일을 언어로 꺼내는 과정 자체에서 조직의 AI 활용 역량이 자란다는 데 있다.
AI &UX/UI DESIGN CLASS
AI 네이티브 방식의 UX/UI 디자인을 공부하고 AI-DTQ 자격증도 취득하세요.
위임의 안전장치와 신뢰의 인터페이스
에이전트가 자율적으로 행동한다고 믿으려면, 그 행동이 정해진 울타리 안에서만 일어난다는 보장이 있어야 한다. 한두 번 잘하는 것을 보고 백만 번으로 확장하면 사고가 날 확률은 통계적으로 1에 가까워진다. 그래서 대표 에이전트에는 세 가지 안전장치가 필요하다. 첫째는 권한이다. 쿼리 실행, 상태 변경, 환불처럼 실제로 무언가를 바꾸는 요청은 요청한 사람의 ID를 보고 걸러낸다. 권한이 많은 사람일수록 에이전트가 ‘무엇을 하면 안 되는가’를 먼저 정의해야 한다. 둘째는 격리다. 한 사람의 에이전트가 고장 나도 다른 사람의 에이전트는 영향을 받지 않아야 한다. 셋째는 승인 지점이다. 에이전트는 실행 직전까지 준비하고, 되돌릴 수 없는 결정은 사람이 누른다.
안전장치만큼 중요한 것이 신뢰의 인터페이스다. 에이전트는 어떤 도구를 호출했고, 어떤 위키와 스킬을 참조했으며, 어떤 온톨로지 규칙에 비추어 결론을 냈는지를 항상 로그로 남겨야 한다. 이 로그를 관리자 페이지에 쌓아 두고 일주일에 한 번 확인하라고 하면 아무도 보지 않는다. 일하는 대화 맥락 안에 근거를 바로 보여줄 때, 사람은 모든 로그를 읽지 않아도 누가 봐도 이상한 답을 쓱 보고 고칠 수 있다. 계약처럼 반드시 확인해야 하는 일만 꼼꼼히 보고 나머지는 흐름 속에서 걸러내는 것, 이 검토의 동선을 설계하는 일이 AX 디자인의 핵심 과제다.
위임을 문화로 만들면 사람이 병목임이 드러난다
직원별 대표 에이전트는 기술 구조이기 전에 문화적 결정이다. 내 에이전트는 나를 대신하는 존재이므로, 동료의 에이전트가 대화를 훌륭하게 마무리하는 것을 보면 “내 에이전트는 왜 이 정도일까”라는 자연스러운 동기가 생긴다. 에이전트가 정말 잘하면 동료는 나를 부르고도 에이전트와의 대화로 일을 끝낸다. 이를 제도로 만들려면 정기적으로 모여 “내 역할에서 20%를 어떻게 덜어내고 있는가”를 공유하고, 여기서 나온 좋은 패턴은 모든 에이전트에 일괄 반영하면 된다. 에이전트마다 위키를 붙여 주거나 매일의 대화 기록을 읽게 하는 개선이 한 사람의 실험에서 조직 전체의 표준이 되는 순환이다.
그런데 위임이 깊어질수록 역설이 드러난다. 두 주자가 이어달리기로 200km를 달리는데 한 명은 시속 100km, 다른 한 명은 시속 1km라면 평균 속도는 약 2km에 불과하다. 조화평균의 원리다. 빠른 주자를 빛의 속도로 만들어도 전체 속도는 2km를 넘지 못하지만, 느린 주자를 시속 10km로 끌어올리면 전체 속도는 몇 배로 뛴다. 조직에서 느린 주자는 에이전트가 아니라 사람이다. 에이전트를 튜닝하는 일도 중요하지만, 결국 투자해야 할 곳은 사람의 문제 정의 능력과 사고력이다. 그래서 평가의 기준도 바뀐다. 실패한 것은 괜찮지만, 그 실패의 순환에서 무엇을 배웠는지를 묻는 것이다.
AI DESIGNER COMMUNITY
AI와 새로운 세상을 만들어가는 디자이너들과 함께 성장하세요.
한계와 과제: 누가 검토하고, 무엇을 복제하는가
이 방식에는 분명한 한계가 있다. 첫째는 검토의 집중이다. 공용 온톨로지에 사람과 에이전트가 수정 요청을 쏟아 내면, 이를 검토하고 규칙 충돌을 점검하는 부담은 전체 맥락을 아는 소수에게 쏠린다. 작은 조직에서는 한 사람이 감당할 수 있지만, 조직이 커지면 이 검토 자체가 새로운 병목이 된다.
둘째는 복제의 윤리다. 사람을 대표하는 에이전트를 만들기 위해 수개월치 대화를 분석하는 일은 곧 개인의 말과 판단을 데이터로 축적하는 일이다. 이것이 평가와 감시의 도구로 쓰이지 않으려면, 무엇을 학습시키고 무엇을 기록하지 않을지를 본인이 결정할 수 있어야 한다.
셋째는 사람의 가치에 대한 불안이다. 이전에 내가 하던 일을 모두 에이전트가 하고 나는 명령만 내리게 될 때, 생산성을 기준으로 살아온 사람은 자신의 가치를 어디서 찾아야 할지 흔들린다. 위임이 조직의 효율을 높이는 만큼, 조직은 구성원이 생산성 이후의 가치를 찾을 수 있도록 도와야 할 책임도 함께 진다.
디자이너는 위임할 수 있는 조직을 설계한다
에이전틱 AI 시대에 경쟁력은 얼마나 좋은 모델을 쓰느냐보다 얼마나 많은 업무를 안전하게 위임할 수 있느냐에서 갈린다. 그리고 위임의 품질은 에이전트 자체보다 에이전트가 일하는 환경, 즉 각 사람의 경험을 담은 소울과 위키, 조직이 합의한 언어인 온톨로지, 그리고 근거를 보여주고 승인을 받는 인터페이스에 달려 있다. 이것은 곧 에이전트를 사용자로 바라보고 그가 일할 세계를 만드는 AX 디자인의 영역이다.
그래서 디자이너가 던지는 질문도 달라진다. “어떤 에이전트를 만들까”에서 “각 사람의 경험과 조직의 언어를 어떻게 분리하고 연결해야 업무를 위임할 수 있을까”로, 그리고 “사람은 어디서 멈춰 서서 무엇을 판단해야 하는가”로 이동하고 있다.
에이전트경험(AX)디자이너들과 소통하며 함께 성장하고 싶다면?
AI 에이전트경험(AX)디자인을 공부하고 AX-DTQ 기술자격증도 취득하고 싶다면?
해당 콘텐츠는 유훈식 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
