AI 에이전트, 업무 규모를 100배 키우는 핵심

2026.01.12

AI 에이전트, 업무 규모를 100배 키우는 핵심

사용 가능한 에이전트를 구축하는 실전 가이드

2026.01.12 - 05:03:08

AI Agent

Web3 심층 보도에 집중하고 흐름을 통찰

사용 가능한 에이전트를 구축하는 실전 가이드

글: vas

번역: AididiaoJP, Foresight News

AI는 마법이 아니며, "AI 프로그램 하나 만들고 자동으로 모든 걸 처리해 주며 수익만 기다리면 되는" 수준도 아니다. 대부분의 사람들은 사실 AI가 정확히 무엇인지조차 제대로 이해하지 못하고 있다.

진정한 의미를 아는 사람들(전체의 5% 미만)조차 스스로 구축하려 시도하면 거의 실패한다. 에이전트는 '환각'을 일으키거나, 작업 도중 어디까지 진행했는지 잊어버리거나, 도구를 사용해서는 안 될 때 잘못 호출하는 등의 오류를 범한다. 데모에서는 완벽하게 작동하지만, 실제 운영 환경에 배포하자마자 바로 무너진다.

나는 이미 1년 넘게 AI 프로그램을 배포해 왔다. 소프트웨어 경력을 Meta에서 시작했지만, 반년 전 회사를 그만두고 기업용 AI 에이전트를 실제 운영환경에 배포하는 회사를 창업했다. 현재 연간 재curring 수입은 300만 달러에 달하며 계속 성장 중이다. 이는 우리가 다른 사람보다 더 똑똑해서가 아니라, 수많은 시행착오와 실패를 거쳐 비로소 성공의 공식을 터득했기 때문이다.

아래는 내가 실제로 쓸 수 있는 에이전트를 만들면서 얻은 모든 교훈들이다. 초보자든 전문가든, 또는 그 중간에 있든 모두에게 적용될 만한 내용이다.

첫 번째 교훈: 맥락이 전부다

이 말은 매우 당연하게 들릴지도 모른다. 하지만 너무나 중요하기 때문에 반복해서 강조할 가치가 있다. 많은 사람들이 AI 에이전트를 만드는 것은 단순히 다양한 도구들을 연결하는 것이라고 생각한다. 모델을 선택하고 데이터베이스 접근 권한을 열어주면, 이후는 알아서 잘 돌아갈 것이라 믿는다. 그러나 이런 방식은 즉시 실패한다. 이유는 다음과 같다.

에이전트는 무엇이 중요한지 모른다. 다섯 단계 전에 무슨 일이 있었는지 알지 못하며, 현재 단계만 보고 다음에 무엇을 해야 할지 추측하다가(대개는 틀린) 운에 맡긴다.

맥락(context)은 백만 달러짜리 에이전트와 가치 없는 에이전트를 가르는 가장 핵심적인 차이점이다. 다음 요소들에 특히 집중하고 최적화해야 한다.

에이전트가 기억하는 것: 현재 작업뿐 아니라 상황에 이르게 된 전체 역사도 포함되어야 한다. 예를 들어 송장 이상을 처리할 때, 에이전트는 이상이 어떻게 발생했는지, 원본 송장을 누가 제출했는지, 어떤 정책이 적용되는지, 해당 공급업체가 지난번 문제는 어떻게 해결했는지 등을 알아야 한다. 이러한 이력 정보가 없다면 에이전트는 추측만 하게 되며, 이는 AI를 쓰지 않는 것보다 더 나쁘다. 사람이 처리했다면 이미 문제가 해결되었을 가능성이 크기 때문이다. 이것이 바로 "AI 진짜 쓰기 어렵다"고 불평하는 사람들이 존재하는 이유다.

정보의 흐름: 여러 개의 에이전트를 운영하거나 한 에이전트가 다단계 프로세스를 처리할 경우, 정보는 각 단계 사이를 정확하게 전달되어야 하며, 유실되거나 손상되거나 오해되어서는 안 된다. 요청을 분류하는 에이전트는 깨끗하고 구조화된 맥락을 문제 해결 담당 에이전트에게 반드시 전달해야 한다. 인수인계가 엄격하지 않으면 후속 단계 전체가 어그러진다. 즉 각 단계마다 검증 가능한 구조화된 입력과 출력이 필요하다. 예를 들어 Claude Code의 /compact 기능은 서로 다른 LLM 세션 간에도 맥락을 전달할 수 있다.

에이전트의 비즈니스 영역 이해도: 법률 계약 심사 작업을 하는 에이전트는 어떤 조항이 중요한지, 리스크는 어떻게 평가되는지, 회사의 실제 정책은 무엇인지 명확히 알고 있어야 한다. 그냥 문서 덩어리를 던져주고 스스로 핵심을 파악하길 기대해서는 안 되며, 이는 당신의 책임이다. 또한 구조화된 방식으로 자원을 제공하여 에이전트가 진정한 도메인 지식을 갖출 수 있도록 해야 한다.

망각한 맥락 관리는 다음과 같은 형태로 나타난다: 이미 얻은 답변을 잊어 동일한 도구를 반복 호출하거나, 잘못된 정보를 받아 잘못된 도구를 사용하거나, 이전 단계와 모순되는 결정을 내리거나, 매번 과거 유사 작업의 명백한 패턴을 무시하고 작업을 완전히 새로운 것으로 취급한다.

반면 좋은 맥락 관리는 에이전트를 숙련된 비즈니스 전문가처럼 만들어 준다. 별도로 정보 간 관계를 설명해주지 않아도 스스로 연결 고리를 만들 수 있게 된다.

결국 맥락이란 "데모용" 에이전트와 "실제 운영환경에서 작동하며 성과를 내는" 에이전트를 가르는 핵심 요소다.

두 번째 교훈: AI 에이전트는 생산성 증폭기다

틀린 생각: "이걸 도입하면 더 이상 사람을 고용할 필요 없다."

올바른 생각: "이걸 도입하면 세 명이 예전 열다섯 명의 일을 할 수 있다."

에이전트는 일부 인간의 노동을 대체하게 될 것이며, 이를 부정하는 것은 자기기만일 뿐이다. 하지만 긍정적인 측면도 있다. 에이전트는 인간의 판단 자체를 대체하지 않는다. 오히려 인간의 판단 주변에 생기는 마찰을 제거한다. 예를 들어 자료 탐색, 데이터 수집, 비교 검토, 형식 정리, 작업 분배, 팔로업 알림 등 말이다.

예를 들어 재무팀은 여전히 예외 상황에 대한 결정을 내려야 하지만, AI 에이전트 덕분에 결산 주간 동안 70% 시간을 누락된 서류 찾는 데 쓰지 않고, 그 시간을 실제 문제 해결에 집중할 수 있게 된다. 에이전트가 기초 작업을 모두 수행하고, 인간은 최종 승인만 하면 된다. 고객들에게 서비스를 제공하면서 경험한 바에 따르면, 기업들이 이로 인해 인력을 감축하지는 않는다. 직원들의 업무 내용이 번거로운 수작업에서 더 가치 있는 작업으로 전환된다. 적어도 지금은 그렇다. 물론 장기적으로 AI가 더 발전함에 따라 이 상황은 바뀔 수도 있다.

실제로 에이전트로부터 혜택을 받는 회사들은 인간을 프로세스에서 아예 배제하려는 회사들이 아니라, 직원들이 대부분의 시간을 '기초 준비 작업'에 쓰고 있으며, 실제 가치 창출에는 거의 시간을 쓰지 않는다는 점을 인식한 회사들이다.

이런 사고방식으로 에이전트를 설계하면, 더 이상 '정확도'에 집착할 필요가 없다. 에이전트는 자신이 잘하는 일을 하고, 인간도 자신이 잘하는 일에 집중하면 된다.

이는 또한 더 빠른 배포가 가능함을 의미한다. 에이전트가 모든 극단적인 경우까지 처리할 필요는 없다. 일반적인 사례는 잘 처리하고, 복잡하거나 예외적인 사례는 인간에게 넘기기만 하면 된다. 단, 충분한 맥락을 함께 제공하여 인간이 신속하게 해결할 수 있도록 해야 한다. 적어도 현재 단계에서는 그렇게 해야 한다.

세 번째 교훈: 메모리 및 상태 관리

에이전트가 한 작업 내에서 그리고 작업 간에 정보를 어떻게 저장하는지는, 그것이 규모를 확장할 수 있는지를 결정한다.

흔히 쓰는 세 가지 패턴이 있다.

독립형 에이전트: 처음부터 끝까지 전체 워크플로우를 단독으로 처리한다. 모든 맥락이 한곳에 있으므로 구현하기 가장 쉽다. 하지만 프로세스가 길어질수록 상태 관리가 어려워진다. 세 번째 단계에서 내린 결정을 열 번째 단계에서도 사용해야 하는데, 컨텍스트 윈도우가 꽉 차거나 메모리 구조가 잘못되면 후반부 의사결정이 초기 정보 없이 이루어져 오류가 발생한다.

병렬형 에이전트: 동일한 문제의 서로 다른 부분을 동시에 처리한다. 속도는 빠르지만 조율 문제가 발생한다. 결과를 어떻게 통합할 것인가? 두 에이전트가 모순된 결론을 낼 경우는 어떻게 할 것인가? 정보 통합 및 충돌 해결을 위한 명확한 프로토콜이 필요하다. 일반적으로 충돌이나 경쟁 조건을 처리하기 위해 '심판'(사람 혹은 다른 LLM)이 추가로 필요하다.

협업형 에이전트: 순차적으로 작업을 인수인계한다. A 에이전트가 분류하고, B에게 조사를 맡기고, C에게 해결 실행을 위임한다. 명확한 단계가 있는 워크플로우에 적합하지만, 인수인계 단계가 가장 취약하다. A가 학습한 정보를 B가 바로 활용할 수 있는 형식으로 전달해야 한다.

대부분의 사람들이 저지르는 실수는 이들을 단순한 '구현 방식'으로만 보는 것이다. 실제로는 이들 선택은 아키텍처 결정이며, 당신의 에이전트 능력 한계를 직접 결정한다.

예를 들어 판매 계약 승인을 처리하는 에이전트를 만들 때, 하나의 에이전트가 전 과정을 책임질 것인지, 아니면 라우팅 에이전트를 두어 가격 검토, 법무 검토, 임원 승인 등 전문성이 다른 여러 에이전트에게 작업을 분배할 것인지 결정해야 한다. 결국 당신이 실제 비즈니스 프로세스를 얼마나 명확히 이해하고 있는지, 그리고 그 프로세스를 에이전트에게 제대로 전수할 수 있는지가 관건이다.

어떻게 선택해야 할까? 각 단계의 복잡성, 단계 간 전달해야 할 맥락의 양, 그리고 실시간 협업이 필요한지 아니면 순차적 실행이 맞는지에 따라 달라진다.

아키텍처를 잘못 선택하면, 몇 달 동안 버그가 아닌 문제를 디버깅하느라 시간을 낭비하게 된다. 그것은 사실 버그가 아니라, 당신의 설계, 해결하고자 하는 문제, 제시한 솔루션 사이의 아키텍처 불일치일 뿐이다.

네 번째 교훈: 사후 보고가 아니라 실시간 이상 차단

AI 시스템을 만들 때, 많은 사람들의 첫 번째 반응은 "대시보드를 만들자, 정보를 표시해서 사람들이 무슨 일이 일어났는지 볼 수 있게 하자"는 것이다. 제발, 더 이상 대시보드는 만들지 말자.

대시보드는 쓸모없다.

재무팀은 이미 어떤 영수증이 누락되었는지 알고 있고, 영업팀도 이미 어떤 계약이 법무팀에서 멈춰 있는지 알고 있다.

에이전트는 문제 발생 즉시 그것을 차단하고, 해당 담당자에게 넘겨주며 해결에 필요한 모든 정보를 제공하고, 즉시 실행을 유도해야 한다.

송장은 왔는데 서류가 불완전한가? 단순히 보고서에 기록하지 말고, 즉시 표시하고 누구에게 어떤 자료를 보충해야 하는지 확인한 후, 공급업체, 금액, 적용 정책, 구체적으로 무엇이 누락되었는지 포함한 완전한 맥락과 함께 문제를 담당자에게 전달하라. 또한 문제가 해결될 때까지 해당 거래를 장부에 기록하지 못하도록 차단하라. 이 단계가 매우 중요하다. 그렇지 않으면 문제는 조직 내到处に '누수'처럼 퍼지고, 나중에 보완하려 해도 이미 늦는다.

계약 승인이 24시간 이상 정체되었는가? 주간 회의 때까지 기다리지 말고, 자동으로 업그레이드 절차를 밟고 거래 세부사항을 첨부하여 승인자가 시스템을 여기저기 찾아볼 필요 없이 신속하게 결정할 수 있게 하라. 긴박감을 가져야 한다.

공급업체가 마일스톤을 제때 완료하지 못했는가? 누군가 발견하기를 기다리지 말고, 자동으로 비상 대응 계획을 트리거하여 누군가 문제를 인식하기 전에 대응 프로세스를 시작하라.

당신의 AI 에이전트의 책임은 문제를 더 이상 무시할 수 없게 만들고, 해결을 극도로 쉽게 만드는 것이다.

간접적으로 대시보드를 통해 문제를 드러내는 것이 아니라, 직접 문제를 노출시켜야 한다.

이것은 대부분의 기업이 AI를 사용하는 방식과 정반대다. 그들은 AI로 '문제를 보기 위해' 사용하지만, 당신은 AI로 '문제를 해결하도록 강요하기 위해', 그것도 빠르게 하기 위해 사용해야 한다. 문제 해결률이 거의 100%에 도달한 후에야 비로소 대시보드를 만들지 말지 고민해봐야 한다.

다섯 번째 교훈: AI 에이전트 vs 일반 SaaS의 경제성 분석

기업들이 아무도 쓰지 않는 SaaS 도구를 계속 구매하는 데는 이유가 있다.

SaaS는 구매하기 쉽다. 데모가 있고, 견적이 있으며, 요구사항 목록에 체크박스를 넣을 수 있다. 누군가 승인만 하면, 마치 일이 진전된 것처럼 느껴진다(하지만 실제로는 그렇지 않은 경우가 많다).

AI 기반 SaaS를 구매하는 것은 최악이다. 대개 그냥 방치된다. 실제 업무 흐름에 통합되지 않으며, 또 하나의 로그인해야 하는 시스템이 될 뿐이다. 데이터 마이그레이션을 강요받고, 한 달 후엔 관리해야 할 공급업체가 하나 더 늘어날 뿐이다. 12개월 후에는 사용을 중단하지만, 전환 비용이 너무 커서甩不掉(甩不掉), 결국 '기술 부채(technical debt)'가 된다.

반면 기존 시스템을 기반으로 맞춤 제작한 AI 에이전트는 이런 문제를 근본적으로 방지한다.

이미 사용 중인 도구 안에서 작동하므로 새로운 작업 플랫폼을 만들지 않으며, 기존 업무를 더 빠르게 완료하도록 돕는다. 에이전트가 작업을 처리하고, 인간은 결과만 확인하면 된다.

진정한 비용 비교는 '개발비 vs 라이선스 비용'이 아니라 더 단순한 논리다.

SaaS는 '기술 부채'를 축적한다: 도구를 하나 살 때마다 유지보수해야 할 연동이 하나씩 늘고, 언젠가 곧 낡아질 시스템이 하나씩 늘며, 인수되거나 전환되거나 문을 닫을 수 있는 공급업체가 하나씩 늘어난다.

자체 제작 에이전트는 '역량(capability)'을 축적한다: 개선할 때마다 시스템이 더 똑똑해지고, 새 워크플로우를 추가할 때마다 가능성의 폭이 넓어진다. 투자는 복리로 성장하며, 시간이 지남에 따라 가치가 하락하지 않는다.

그래서 나는 지난 1년 동안 계속 말해왔다. 일반적인 AI SaaS는 미래가 없다. 산업 데이터도 이를 뒷받침하고 있다. 대부분의 AI SaaS를 도입한 기업들은 6개월 이내에 사용을 중단했으며, 생산성 향상을 전혀 경험하지 못했다. 진정으로 AI로부터 혜택을 본 기업들은 모두 맞춤형 에이전트를 보유한 회사들이다. 자체 개발이든 제3자에게 의뢰했든 상관없이 말이다.

이 때문에 초기에 에이전트를 도입한 기업들은 장기적인 구조적 우위를 갖게 된다. 그들은 점점 더 강해지는 인프라를 건설하고 있는 반면, 다른 사람들은 언젠가 교체해야 할 도구를 빌려쓰고 있을 뿐이다. 이 분야가 매달 격변하는 시대에, 일주일이라도 낭비하면 제품 로드맵과 전체 비즈니스에 큰 손실이 된다.

여섯 번째 교훈: 빠르게 배포하라

AI 에이전트 프로젝트를 1년 후에야 출시하려 한다면, 이미 패배한 것이다.

계획은 현실을 따라가지 못한다. 당신이 설계한 워크플로우는 실제 업무 방식과 맞지 않을 가능성이 높으며, 예상하지 못한 edge case들이 가장 중요할 수 있다. 12개월 후에는 AI 분야가 이미 하늘과 땅 차이만큼 변했을 수 있으며, 당신이 만든 것은 이미 낡은 물건이었을지도 모른다.

최대 3개월 이내에 반드시 운영 환경에 배포해야 한다.

정보가 폭발하는 이 시대에 진정한 역량은 정보를 효과적으로 활용하고, 그것과 협력하며 살아가는 방법을 아는 것이다. 실제로 일을 해야 한다: 실제 과제를 처리하고, 실제 결정을 내리고, 추적 가능한 기록을 남겨야 한다.

내가 가장 흔히 보는 문제는 내부 개발 팀들이 본래 3개월이면 끝날 AI 프로젝트를 6~12개월 걸린다고 추정하거나, 더 나쁜 경우는 입으로는 3개월이라 말하면서도 각종 '예기치 못한 이유'를 내세워 계속 기한을 연기한다는 것이다. 전적으로 그들을 탓할 수는 없다. AI 분야가 실제로 복잡하기 때문이다.

그러므로 진정으로 AI를 이해하는 엔지니어가 필요하다. AI가 어떻게 규모를 확장하는지, 실제 현장에서 어떤 문제가 발생하는지, AI의 능력과 한계를 명확히 아는 사람 말이다. 현재 '아는 척'만 하는 개발자들이 너무 많다. AI는 뭐든지 다 할 수 있다고 생각하는 이들인데, 이는 현실과 너무 멀리 떨어져 있다. 만약 당신이 엔터프라이즈급 AI 애플리케이션 분야에 진입하려는 소프트웨어 엔지니어라면, AI의 실제 능력 한계를 탄탄히 이해해야 한다.