지금까지 우리가 써온 AI(ChatGPT 같은 것)가 **'똑똑한 레시피 북'**이었다면, 이 논문이 말하는 '에이전틱 AI(Agentic AI)'는 **'스스로 요리하는 보조 요리사'**입니다.
기존의 AI (레시피 북 단계): 여러분이 요리를 하다가 "파스타 어떻게 만들어?"라고 물어보면 레시피를 알려줍니다. 하지만 재료를 사고, 불을 조절하고, 접시에 담는 건 여전히 여러분의 몫이죠. AI는 그저 옆에서 말로만 도와주는 '도구'일 뿐입니다.
에이전틱 AI (보조 요리사 단계): 이제 AI에게 "오늘 저녁에 손님 5명 올 거니까 파스타 코스 준비해 줘"라고 말합니다. 그러면 AI는 스스로 냉장고를 확인하고, 부족한 재료를 주문하고, 면을 삶고, 소스를 만듭니다. 여러분은 완성된 요리가 괜찮은지만 확인하면 됩니다.
🚧 왜 기업들은 '보조 요리사'를 채용하지 못할까요? (현재의 문제점)
논문은 많은 회사가 이 단계로 넘어가지 못하는 이유를 몇 가지 꼽습니다.
"레시피만 공부하고 있어요" (기술에만 집착): 요리 실력을 키우는 게 아니라, 더 좋은 레시피 북(코드)을 만드는 데만 혈안이 되어 있습니다. 정작 "어떤 요리를 만들 것인가?"라는 비즈니스 목표는 놓치고 있죠.
"주방장이 너무 깐깐해요" (전통적인 방식 고수): 예전 방식대로 모든 동작을 하나하나 명령하려고 합니다. AI에게 자유를 주어 스스로 판단하게 해야 하는데, "소금은 정확히 3.5g 넣어!"라고 일일이 간섭하니 AI의 능력이 발휘되지 않습니다.
"주방장과 요리사가 대화를 안 해요" (소통 부재): 기술팀(엔지니어)은 기계만 보고, 현장 직원(비즈니스 팀)은 요리만 합니다. 서로 어떤 맛을 원하는지, 어떤 상황에서 예외가 생기는지 공유가 안 되니 맛없는 요리가 나옵니다.
🚀 성공적인 전환을 위한 4가지 비결 (논문의 제안)
논문은 기업들이 '스스로 일하는 AI 팀'을 만들기 위해 이렇게 해야 한다고 말합니다.
"메뉴부터 제대로 정하세요" (도메인 중심): 무작정 AI를 도입하는 게 아니라, "우리 회사에서 가장 반복적이고 귀찮은 업무(예: 예약 확인, 송장 발행)가 무엇인가?"를 먼저 찾아내야 합니다.
"주방을 분업화하세요" (에이전트 분해): 한 명의 AI에게 모든 걸 시키지 마세요. '재료 손질 담당 AI', '불 조절 담당 AI', '플레이팅 담당 AI'처럼 역할을 나누어 전문성을 높여야 합니다.
"사람은 '총괄 셰프'가 되세요" (Human-in-the-loop): 사람이 직접 칼질을 하는 게 아니라, 여러 AI 요리사들이 만든 요리를 최종적으로 검수하고 승인하는 '총괄 셰프(Orchestrator)' 역할을 맡아야 합니다. 그래야 효율적이면서도 사고를 막을 수 있습니다.
"작고 빠른 팀을 만드세요" (소규모 팀): 거대한 조직이 모여 회의만 하기보다는, AI 도구를 능숙하게 다루는 소수의 '천재 요리사 팀'이 빠르게 실험하고 수정하며 발전시켜야 합니다.
💡 요약하자면?
이 논문은 **"AI를 단순한 '계산기'나 '백과사전'으로 쓰지 말고, 우리 회사의 업무 흐름(Workflow) 속에서 스스로 움직이는 '팀원'으로 만드세요. 단, 사람은 그 팀원들을 지휘하는 '지휘자'가 되어야 합니다."**라고 조언하고 있습니다.
[기술 요약] 조직의 에이전틱 AI(Agentic AI) 전환을 위한 실무 가이드
1. 문제 정의 (Problem Statement)
현재 많은 조직이 AI를 도입하고 있지만, 대부분은 단순한 'AI 보조 도구(AI-assisted tools)' 단계에 머물러 있습니다. 즉, 인간이 주도하고 AI는 단편적인 작업(코드 생성, 요약 등)만 돕는 '도구 중심적' 워크플로우에 국한되어 있습니다. 논문은 조직이 자율적인 추론과 실행이 가능한 **'에이전틱 AI(Agentic AI)'**로 나아가지 못하는 핵심 원인을 기술적 한계가 아닌 조직적/운영적 장벽에서 찾습니다.
전통적 소프트웨어 공학 마인드셋의 한계: 결정론적(Deterministic)이고 경직된 기존 개발 방식은 확률적(Probabilistic)이고 적응적인 에이전틱 시스템에 부적합함.
도메인 지식의 결여: 엔지니어링 팀이 비즈니스 프로세스에 내재된 암묵적 지식(Tacit knowledge)과 예외 처리 규칙을 충분히 통합하지 못함.
엔지니어링 중심의 병목 현상 착각: 구현(Coding) 자체가 병목이 아니라, 문제 정의와 워크플로우 설계가 핵심임에도 불구하고 여전히 개발 인력 확보에만 집중함.
협업 모델 부재: 비즈니스 팀과 엔지니어링 팀 간의 단절된 협업 구조로 인해 실제 운영 요구사항과 괴리된 시스템이 구축됨.
2. 방법론 (Methodology)
본 논문은 단순한 이론 제시를 넘어, 실제 비즈니스 도메인에 적용 가능한 **'실무적 전환 프레임워크'**를 제안합니다.
도메인 중심의 워크플로우 분해: 수동 프로세스를 단순 자동화하는 것이 아니라, 인지적 책임(정보 추출, 검증, 필터링, 합성 등)에 따라 여러 개의 **특화된 AI 에이전트(Specialized Agents)**로 분해합니다.
인간 중심의 오케스트레이션 모델 (Human-in-the-loop): 인간을 단순 작업자가 아닌, 여러 에이전트 워크플로우를 관리하고 감독하는 **'오케스트레이터(Orchestrator)'**로 재정의합니다. 이를 위해 Model Context Protocol (MCP) 서버를 사용하여 에이전트 워크플로우를 표준화된 인터페이스로 노출합니다.
AI 네이티브 개발 방법론 (Agentsway): AI를 단순 도구가 아닌 개발 프로세스의 참여자로 활용합니다. Claude Code와 같은 AI 보조 도구를 사용하여 에이전트 생성, 프롬프트 설계, 워크플로우 구성을 가속화합니다.
소규모 다기능 팀 구성: 대규모 조직 대신, 도메인 전문가와 엔지니어가 결합된 3~4인 규모의 작고 자율적인 팀이 빠르게 반복(Iteration)하며 시스템을 구축합니다.
3. 주요 기여 (Key Contributions)
패러다임 전환 제시: 에이전틱 AI 도입을 기술적 과제가 아닌 조직적 전환(Organizational Transition) 문제로 규정함.
실무 프레임워크 제안: 도메인 분석 → 에이전트 위임 → 인간 중심 오케스트레이션 → AI 기반 개발로 이어지는 단계적 가이드를 제공함.
운영 모델 정립: MCP를 활용하여 에이전트 워크플로우를 모듈화된 서비스로 만들고, 인간이 자연어로 이를 제어하는 새로운 운영 모델을 제시함.
개발 효율성 증명: AI를 이용해 AI 시스템을 구축하는 방식이 개발 비용을 낮추고 변화에 대한 적응력을 높임을 입증함.
4. 결과 및 평가 (Results & Evaluation)
논문은 관광 중소기업(SME)의 운영 프로세스 자동화 사례를 통해 제안된 가이드를 검증했습니다.
대상 워크플로우: 수동 예약 관리, 일정 계획(Planning), 운송 관리(Transport Management).
구현 내용:
Planning Workflow: 이메일 읽기, 예약 필터링, 활동 가용성 확인, 계획서 생성 에이전트들이 협력하여 복잡한 일정표를 자동 생성.
Transport Management Workflow: 생성된 계획을 바탕으로 차량 배정, 경로 최적화, 제약 조건(날씨, 용량 등)을 고려한 운송 스케줄 생성.
평가 결과:
에이전트들이 다중 제약 조건(Multi-constraint) 하에서 논리적 추론을 성공적으로 수행함.
단일 모델의 성능보다 워크플로우 수준의 협업에서 실질적인 비즈니스 가치가 창출됨을 확인.
인간 관리자는 LM Studio와 같은 인터페이스를 통해 복잡한 실행 과정 없이 결과물을 검토하고 승인하는 '감독자' 역할로 전환 가능함을 입증.
5. 의의 (Significance)
본 연구는 기업이 AI를 단순한 '비서'로 쓰는 단계를 넘어, **'자율적인 업무 수행 주체'**로 전환하기 위한 실질적인 로드맵을 제공합니다. 특히, 기술적 완성도에만 매몰되지 않고 비즈니스 도메인 지식, 팀 구조, 인간-AI 협업 모델을 통합적으로 설계해야 한다는 점을 강조함으로써, 향후 기업의 AI 전략 수립에 있어 매우 중요한 실무적 지침이 됩니다.