이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
챗봇에게 장애 티켓을 보여주고 “원인 좀 찾아줘”라고 물으면 설명은 잘 나옵니다. 그런데 관련 로그를 찾고, 이전 장애를 확인하고, 처리안을 티켓에 남기는 일은 결국 사람이 이어서 하게 되죠. 이 다음 단계까지 연결하려고 나오는 말이 Agentic AI입니다.
Agentic AI는 모델 하나의 이름이 아닙니다. 목표를 받은 시스템이 현재 상태를 보고, 필요한 도구를 고르고, 결과를 확인한 뒤 다음 행동을 정하는 방식입니다. OpenAI도 에이전트를 모델이 업무 흐름을 관리하고 도구를 선택하며, 실패하면 멈추거나 사용자에게 넘길 수 있는 시스템으로 설명합니다(OpenAI 가이드).
다만 여기서 “스스로 일한다”는 말을 너무 크게 받아들이면 곤란해요. 실제로는 읽기, 제안, 승인 뒤 실행처럼 권한과 책임을 잘게 나누는 편이 안전합니다. Agentic AI를 도입할 때도 멋진 데모보다 이 경계부터 정하는 것이 먼저입니다.
Agentic AI는 챗봇과 무엇이 다를까
가장 단순한 챗봇은 질문을 받고 한 번 답합니다. 고정 워크플로는 개발자가 정한 순서대로 검색 → 요약 → 메일 초안을 실행합니다. 반면 Agentic AI는 같은 목표 안에서도 “정보가 부족하니 먼저 로그를 찾자”, “결과가 애매하니 다른 지식 문서를 더 보자”처럼 다음 단계를 고를 수 있습니다.
이 셋은 칼로 자르듯 나뉘지 않습니다. 에이전트와 워크플로의 스펙트럼을 정리한 글처럼, 자율성이 조금씩 높아지는 연속선으로 보는 편이 실무에 맞아요. 순서와 규칙이 확실한 일은 코드로 고정하고, 애매한 문서를 읽거나 예외를 분류하는 부분만 모델에 맡길 수 있습니다.
최근 관심도 이 지점에 있습니다. 대화에서 그럴듯한 답을 만드는 데서 끝내지 않고, 검색·API·사내 시스템 같은 도구를 통해 여러 단계를 마치는 쪽으로 무게가 옮겨갔습니다. 그렇다고 모든 자동화가 에이전트가 되는 것은 아닙니다. Google Cloud도 요약, 번역, 단순 분류처럼 절차가 뚜렷한 일에는 더 단순한 방식이 효율적일 수 있다고 안내합니다(구성요소 선택 가이드).
장애 티켓 하나가 흐르는 Agentic AI 구조
반복되는 “배포 뒤 로그인 오류가 늘었다”는 티켓을 예로 들어볼게요. 좋은 구조는 모델에게 권한을 한꺼번에 주는 것이 아니라, 한 번의 실행 루프를 보이게 만듭니다.
- 입력과 상태: 티켓 내용, 서비스 이름, 허용된 시간 범위, 이미 확인한 사실을 실행 상태에 기록합니다. 같은 로그를 계속 찾지 않게 하는 기준점입니다.
- 계획과 오케스트레이션: LLM이 지금 필요한 다음 행동을 고릅니다. 단, “로그 조회는 두 번까지”, “10분이 지나면 사람에게 넘김” 같은 종료 조건은 코드로 둡니다.
- 검색과 메모리: 런북, 과거 장애 기록, 변경 이력을 가져옵니다. 여기서 메모리는 무조건 길게 저장하는 대화 로그가 아니라, 다음 판단에 필요한 사실을 남기는 공간에 가깝습니다.
- 도구: 로그 검색 API, 모니터링 조회, 티켓 댓글 초안 같은 좁은 기능을 연결합니다. MCP(Model Context Protocol)는 호스트·클라이언트·서버 구조에서 도구와 리소스를 노출하는 표준 인터페이스라, 도구 연결을 분리할 때 쓸 수 있습니다(MCP 아키텍처 명세).
- 평가와 재시도: “원인 후보에 근거 링크가 있는가”, “확신이 낮으면 추가 검색이 필요한가”를 확인합니다. 기준을 못 넘으면 다른 조회를 시도하고, 횟수를 넘기면 종료합니다.
- 가드레일과 사람 승인: 읽기 전용 조회는 자동으로 허용할 수 있어도, 배포 롤백이나 고객에게 보내는 공지는 사람 승인 뒤에만 실행합니다. 입력 검증, 최소 권한, 실행 로그도 이 경계에 함께 둡니다.
이 흐름은 에이전틱 AI 입문 가이드가 설명하는 도구 호출과 메모리의 조합을 실제 업무 단위로 풀어 본 것입니다. 모델의 답변 자체보다, 어떤 상태에서 어떤 도구를 왜 불렀는지 남기는 편이 나중에 문제를 찾기 쉽습니다.
고정 워크플로, 단일 에이전트, 멀티 에이전트 중 무엇부터 쓸까
처음부터 역할 이름이 많은 멀티 에이전트 구조를 만들 필요는 없습니다. 선택 기준은 “누가 더 똑똑해 보이는가”가 아니라, 흐름이 얼마나 바뀌는지와 실패를 얼마나 쉽게 추적할 수 있는지입니다.
| 구조 | 잘 맞는 일 | 장점 | 먼저 확인할 점 |
|---|---|---|---|
| 고정 워크플로 | 순서와 규칙이 명확한 처리 | 비용과 결과가 예측하기 쉽습니다 | 예외가 생기면 규칙이 빠르게 늘어납니다 |
| 단일 에이전트 | 문서 조사처럼 도구 선택이 필요한 좁은 업무 | 프롬프트와 도구를 한곳에서 다듬기 쉽습니다 | 도구 수와 업무 범위가 커지면 판단이 흐려질 수 있습니다 |
| 멀티 에이전트 | 서로 다른 전문 영역을 나누고 합쳐야 하는 복잡한 업무 | 역할별 평가와 권한 분리가 가능합니다 | 호출 수, 지연, 비용, 전달 오류가 함께 늘어납니다 |
OpenAI는 중앙 관리자가 전문 에이전트를 도구처럼 부르는 방식과, 에이전트끼리 넘겨받는 방식을 멀티 에이전트의 대표 패턴으로 소개합니다(오케스트레이션 설명). 하지만 처음에는 하이브리드가 편합니다. 티켓 생성, 권한 확인, 승인, 저장처럼 결정적인 단계는 코드로 고정하고, 원인 후보를 찾고 처리안을 쓰는 일부 단계만 Agentic AI에 맡겨보세요.
이 접근은 Agentic AI 개발 가이드가 강조하는 승인과 감사 흔적의 필요성과도 닿아 있습니다. 설계를 복잡하게 하기보다, 한 단계의 도구 사용을 재현할 수 있는지 먼저 확인하면 됩니다.
어디까지 맡길지 사례로 나누기
권한을 한 번에 넓히지 말고, 각 업무에서 AI가 할 수 있는 행동을 세 칸으로 나눠보세요.
| 업무 | AI가 먼저 해도 되는 일 | 사람을 거칠 일 | 외부 상태 변경 |
|---|---|---|---|
| 소프트웨어 개발 | 코드베이스 검색, 수정안·테스트 제안 | PR 검토, 병합 판단 | 승인 뒤 브랜치·PR 생성 |
| 사내 지식 조사 | 허용된 문서 검색, 근거 포함 요약 | 중요한 해석과 공유 범위 확인 | 보통 없음 |
| 고객 문의 | 의도 분류, 관련 정책·주문 정보 조회 | 예외 처리와 민감한 답변 확인 | 환불·계정 변경은 승인 뒤 |
| 운영 리포트 | 지표 조회, 초안과 이상 징후 제안 | 원인 해석과 배포 결정 | 알림 발송·티켓 변경은 승인 뒤 |
개발 업무는 테스트 결과라는 피드백이 있어 작은 루프부터 만들기 좋습니다. Anthropic도 코딩 에이전트가 테스트 결과로 반복할 수 있지만, 넓은 요구사항과의 일치는 사람 검토가 중요하다고 설명합니다(Building Effective AI Agents). 예전에 정리한 SSH는 되는데 SFTP는 안 될 때처럼, 실행 명령 하나가 데이터를 바꿀 수 있는 환경이라면 특히 읽기와 쓰기 권한을 구분해야 합니다.
“스스로 일하는 AI”를 업무 자동화로 연결한 사례도 같은 이유로 참고할 만합니다. 모델이 모든 결정을 대신한다는 약속보다, 제안·승인·실행의 순서를 업무에 맞게 고정하는 편이 운영하기 좋습니다.
작게 시작할 때 먼저 정할 것
첫 대상은 반복되지만 예외가 아주 많지 않은 일로 잡아보세요. 예를 들어 “지난 24시간의 장애 티켓에서 근거 링크가 있는 처리안 초안 만들기”처럼 입력과 성공 기준이 한 문장으로 정리되는 일이 좋습니다.
- 성공 기준: 처리안에 어떤 근거가 있어야 완료인지, 답하지 못하면 누구에게 넘길지 정합니다.
- 권한: 처음에는 조회 전용 도구만 연결합니다. 쓰기 작업은 승인 후에만 허용합니다.
- 종료 조건: 도구 호출 횟수, 시간, 비용 한도와 재시도 횟수를 코드로 둡니다.
- 기록과 평가: 입력, 선택한 도구, 결과, 최종 판단을 남기고 실제 티켓 몇 건으로 결과를 비교합니다.
Agentic AI의 첫 버전은 사람을 없애는 장치가 아니라, 사람이 확인할 만한 초안을 근거와 함께 가져오는 동료에 가깝습니다. 이 좁은 루프가 안정되면 읽기 전용 도구를 늘리고, 그다음에만 승인 뒤 실행 범위를 넓혀보면 됩니다.
참고: OpenAI의 실전 에이전트 가이드, Anthropic의 설계 패턴, Google Cloud의 Agentic AI 아키텍처 구성요소, MCP 아키텍처 명세