[프리즘] 미래 인재, '에이전트 보스'의 3가지 핵심 역할 (2/3)
페이지 정보
작성자 작성일 2026-10-21 10:16 조회 16 댓글 0본문
* 본 콘텐츠는 IGM 트렌드 리포트 '프리즘'에 수록된 글로, 총 3편으로 나누어 연재합니다. 이전 글(1/3) 읽기
1. Build: “어떤 업무를 에이전트화 할 것인가?”
1) 문제를 정의하라
에이전트 구축의 첫 단계는 ‘어떤 문제를 해결할 것인가?’를 명확히 정의하는 것이다. 너무 거창하게 생각할 필요 없다. 우선 반복해서 같은 자료를 찾아야 하는 영역, 데이터가 넘치지만 충분히 활용하지 못하는 영역, 지나치게 많은 시간이 소요되는 영역과 같이 병목 지점이 어디인지 찾아본다. 예를 들어, “고객 의견을 직접 취합해 전달하는 구조라 제품 반영까지 3개월이 걸린다”, “매주 5개 채널에서 매출 데이터를 취합하고 가공하는 데만 8시간 소요된다”와 같이 구체적으로 정의해야 한다. 반면, 문제라고 생각이 들더라도 일회성 업무이거나 명확한 프로세스가 아직 없거나, 실제로 시간을 크게 절약해주지 못한다면 에이전트를 만드는 대신, AI 챗으로 지원받는 것이 낫다.
문제와 관련된 업무를 최소 단위인 과업으로 쪼갠다. 가령, ‘매출 데이터 취합 및 보고서 작성’ 업무를 △데이터 수집 △형식 통일 △매출 증감률 계산 △주요 증감 항목 추출 △이상치 탐지 △보고서 작성 등처럼 잘게 해체하는 것이다. 이렇게 분해해보면 AI가 잘할 수 있는 영역과 사람이 꼭 해야 하는 영역을 가늠해볼 수 있다. 중요한 것은 단순히 자동화할 일을 찾는 것이 아니라, AI에게 하나의 독립된 역할로 맡길 수 있는 일을 찾는 것이다. MIT 슬론 경영 리뷰에 따르면, ‘자동화하기 쉬운 곳이 아니라 자동화할 가치가 있는 곳에 에이전트를 활용하고, 원하는 결과를 중심으로 프로세스를 다시 설계해야 한다’고 강조한다.
3) AI 에이전트의 직무기술서를 만들어라
에이전트를 팀에 합류시키기 전에, 사람 직원을 채용할 때처럼 직무기술서를 구체화해줘야 한다. 가장 먼저 방법이 아니라 ‘목표’를 명시해야 한다. 산을 오른다고 생각해보자. 한 걸음 한 걸음 내딛는 것은 ‘과업’이고, 정상에 도착하는 것이 ‘결과’다. 어디가 정상인지부터 명확히 정해야 한다. AI의 강점은 그 정상에 도달하기 위한 방법을 사람이 생각하는 것보다 더 잘 찾아낼 수 있다는 데 있다. 즉 방법을 말해주기 보다, 목표를 달성한다면 어떤 모습일지 ‘완료 기준’을 정의하는 것이 중요하다. 단순히 “이메일을 처리해줘”가 아니라, “완료란, 매일 오전 9시까지 받은 편지함이 비어 있고, 답장 초안이 내 어투로 작성되어 있으며, 내가 직접 처리해야 할 메일은 맨 위에 표시되어 있는 상태를 의미해”와 같이 완료된 모습을 그려주는 것이다. 달성하고자 하는 기준이 정의되어 있지 않다면, 에이전트도 그 목표에 도달할 수 없다.
다음으로, 직무기술서에 포함해야 할 것은 에이전트의 ‘정체성’이다. 핵심 역할(책임 범위), 소통 스타일, 작업 방식, 타협할 수 없는 원칙 등을 담는 것이다. 정체성이 모호하면 월권 행위를 하거나, 같은 질문에도 매번 다른 답을 내놓거나, 매번 사람에게 물어보는 등 업무에 병목을 발생시킬 수 있다. 다만, 이 내용을 사람이 일일이 처음부터 다 쓸 필요는 없다. 해결하려는 문제와 목표가 명확하다면, AI 대화창에 “이런 문제를 해결하려 하는데, 이 에이전트의 정체성을 담은 직무기술서를 작성해 줘. 정확하게 채우기 위해 필요한 질문을 하고 나서 작성해줘”라고 요청한다. AI가 초안을 잡고 사람이 이를 수정하는 방식이 훨씬 효율적이다.
2. Delegate: “어떤 방식으로 맡길 것인가?”
AI 에이전트를 처음 도입할 때는 하나의 에이전트가 특정 과업을 맡고, 사람이 그 결과를 활용하는 형태로 시작하기 쉽다. 하지만 에이전트가 맡는 역할과 자율성이 점차 확대되면 두 개 이상의 에이전트가 협력해 하나의 목표를 수행하는 멀티 에이전트 시스템으로 발전하게 된다.
멀티 에이전트가 일하는 방식은 대표적으로 네 가지가 있다. 가장 기본적인 구조는 ‘순차형’이다. 예를 들어 ‘신사업 진출 검토’라는 과업을 수행할 때, 마켓 리서처, 경쟁사 분석가, 사업 타당성 분석가, 재무 분석가, 보고서 작성가 등 에이전트가 각각 투입된다고 가정해보자. 마켓 리서치 에이전트가 시장 데이터를 수집한 뒤, 경쟁사 분석가가 경쟁사를 분석하고, 이를 기반으로 사업성을 판가름하고 재무를 분석한 후 보고서를 뽑아내는 방식이다. 단계별 선후 관계가 명확하고 앞선 데이터가 반드시 존재해야 하는 과업에 적합하다.
반대로, 서로 의존하지 않는 과업은 ‘병렬형’으로 처리할 수 있다. 시장 규모, 경쟁사, 고객 니즈를 여러 에이전트가 동시에 조사한 뒤 결과를 모아 종합하는 방식이다. 시간 단축이 중요한 과업에서는 여러 에이전트가 각자의 일을 동시에 수행하도록 설계할 수 있다.
과업이 복잡해지면 ‘계층형’ 구조도 활용할 수 있다. 상위 에이전트가 컨트롤 타워가 되어, 전체 목표를 바탕으로 하위 에이전트들에게 일을 나누고 결과를 취합하는 방식이다. 사람이 담당하던 위임과 관리의 역할이 에이전트 사이로 확장되는 것이다.
여기에 더해, 외부에서 유입되는 요청에 따라 담당 에이전트를 연결하는 ‘라우팅 방식’을 결합할 수도 있다. 가령 고객 문의가 들어오면, 제품 문의는 제품 전문 에이전트에게, 계약 관련 문의는 법무 전문 에이전트에게 맡기는 식이다. 사람의 개입 없이 유입 단계부터 최적의 전담 인력으로 업무를 나눌 수 있다.
그렇다면 에이전트를 많이 연결할수록 좋을까? 그렇지는 않다. 단순 반복 업무라면 한 사람이 수십 개의 에이전트를 다룰 수 있지만, 내·외부 시스템과 연동해 실행하거나, 전략적으로 민감한 과업일수록 사람의 역할이 더욱 커진다. 오늘날 AI에게 맡기는 업무 복잡성이 증가하는 지금, 에이전트 연결을 무작정 늘릴수록 사람이 점검해야 할 부담도 함께 커질 수밖에 없다. 앞으로 조직은 너무 과하지도, 부족하지도 않도록 사람과 에이전트의 비율을 설계해야 하는 과제를 안고 있다. 마이크로소프트는 이를 ‘사람-에이전트 비율(Human-Agent Ratio)’으로 정의하며, 최적의 비율은 역할, 과업, 프로젝트의 특성에 따라 달라진다고 설명한다.
*Source: Microsoft / IGM 재구성
3. Manage: “에이전트가 제대로 일하고 있는지 어떻게 판단하고 개선할 것인가?”
에이전트에게 과업을 위임했다고 끝이 아니다. 처음에는 잘 작동하던 에이전트가 시간이 지나면서 엉뚱한 결과를 내놓을 수도 있고, 목표와 어긋난 결과를 내놓을 수도 있다. 리더가 사람 직원의 성과를 확인하고 피드백하는 것처럼, 에이전트 역시 지속적인 코칭이 필요하다. 다만 사람이 모든 결과를 매번 검토하면 에이전트를 도입한 의미가 사라진다. 따라서 에이전트 보스는 '적절한 때에 개입하는 구조(Human-on-the-loop)'를 만들어야 한다. 평소에는 에이전트가 스스로 일하게 두되, 할인율 한도를 넘기거나 계약 체결처럼 중요한 판단이 필요한 순간에만 사람의 승인을 거치도록 기준을 정해두는 것이다.
또한 그 개입의 순간마다 피드백을 기록해야 한다. 에이전트의 오답을 단순히 바로잡는 데 그치지 않고, 발생한 예외 상황과 사람의 수정 이력을 데이터로 쌓아 나가야 한다. 이를 통해 에이전트의 직무기술서와 일하는 방식을 다듬음으로써, 한 번 쓰고 마는 자동화가 아니라 계속해서 개선되는 ‘학습 루프(Feedback Loop)’를 구축할 수 있다. 이 데이터는 조직 관점에서도 대체 불가능한 자산이 된다. 매일 쌓이는 예외 처리 기록, 에이전트의 오류 패턴, 사람이 개입한 이유와 같은 기록 속에는 에이전트가 어떤 한계에 부딪히는지, 어떤 기준이 현장에서 실제 작동하는지가 그대로 담겨 있기 때문이다. 이러한 피드백 과정을 데이터로 체계적으로 쌓아두는 조직만이 에이전트 성능을 빠르게 고도화하고, 일하는 방식에서의 경쟁력을 끌어올릴 수 있다.
마지막으로, 에이전트가 창출한 실질적 가치를 평가해야 한다. 반복 업무를 줄인 생산성 지표를 넘어, 비용 절감이나 매출 기회 발굴, 새로운 인사이트 도출과 같이 실제 비즈니스 투자수익률(ROI)을 만들어냈는지 살펴봐야 한다. 이러한 성과 평가 데이터가 확보되어야 어떤 에이전트를 조직 전체로 확대 적용하고, 어떤 에이전트를 보완하거나 정리할지 명확히 판단할 수 있다.
* '3편: 에이전트 보스를 현실로 만든 프론티어 기업 사례'는 다음 글에서 이어집니다.
