회사에서 Notion 내 다른 부서에 AI 에이전트 도입을 추진하고 FDE 방식을 사용하는 기업에 구현을 지원하는 업무를 하면서 몇 가지 패턴이 나타났습니다. 저는 영업, 인사이드 세일즈, 마케팅, 제품 개발, 고객 성공 등 다양한 분야의 에이전트를 구축해왔지만, 모두 현장 수준의 공통 장벽과 기업 수준의 조직적 장벽에 직면합니다. 이 두 가지는 모두 피할 수 없으며, 대부분의 기업이 같은 지점에서 막히는 것 같습니다.
▍현장 장벽
① 과업 범위가 너무 좁아지는 문제
"리드가 들어오면 자동으로 조사하는" 영업용 에이전트를 만들어 보려고 했습니다. 전체 워크플로를 상상했습니다. 잠재 고객이 리스트에 추가되면 에이전트가 내부 및 외부 정보를 조사하고 분석한 후 이메일 초안을 작성하는 방식이었죠. 먼저 리드 데이터베이스에 새 항목이 추가될 때 정보를 조사하는 부분부터 구축하기 시작했고, 기반이 마련되면 이메일 작성 자동화는 쉬울 거라고 생각했습니다.
하지만 초기 빌드를 설정하고 현장 팀에 소유권을 넘겼는데도 몇 주가 지나도록 이메일 초안을 자동화하지 않았습니다. 인터뷰를 해보니 그들은 "리드를 조사해주는 것만으로도 이미 매우 편리합니다!"라고 말했습니다. 팀은 이메일 초안까지 갈 수 있다는 사실을 인지하지 못했거나, 그 정도로 자동화하는 아이디어 자체를 떠올리지 못한 겁니다. 또한 어렵게 느껴져서 망설이는 모습도 보였습니다.
에이전트 구현이 정체되는 첫 번째 패턴은 바로 이것입니다. 작업 범위를 너무 좁게 잡아서 에이전트를 구축했음에도 불구하고 수익이 낮은 방식으로만 사용되는 것입니다. 결국 고립된 기능이나 사소한 작업에만 사용되고 맙니다.
② 너무 커서 멈추는 문제
두 번째 문제는 그 반대입니다. 복잡한 비즈니스 프로세스를 에이전트로 만들려고 하다 보니 프로세스 자체가 고해상도로 구조화되어 있지 않다는 것을 깨닫게 됩니다. 사람마다 하는 방식이 다르거나, 암묵적 지식이 너무 많습니다. 너무 철저하게 하려고 하면 인터뷰 단계에서만 시간이 녹아내리고, 구축 단계까지 도달하지 못합니다. 이해 관계자가 늘어나고 합의 형성 비용이 기하급수적으로 증가합니다. 초기의 열정은 점차 사라져 버립니다...
이는 프로젝트 관리에서의 범위 설정 문제입니다. 에이전트로 무엇을 하고 싶은가? 어떤 결과를 얻고 싶은가? 결과가 정해지면 에이전트에 필요한 충분하고도 필요한 범위가 결정됩니다. 막연하게 "에이전트로 업무 효율화"를 목표로 하면 진흙탕에 빠지게 됩니다.
③ 소유권 부재
추진자가 열정을 가지고 구축하더라도 개선이나 버그 수정에 대한 책임이 모호하면 사용이 점차 줄어듭니다. 추진자도 결국 지치게 됩니다. 이상적으로는 현장 팀이 에이전트를 자신의 것으로 키워나가야 합니다. 이것이 없으면 처음 3개월은 좋아 보여도 확장에 실패합니다. 이해 관계자가 늘어나고, 특히 작업 범위가 커질수록 합의와 확인이 필요해지며, 주인의식(누가 소유하는가)이 점점 희미해집니다.
이 세 가지는 독립적인 문제가 아니라 모두 연결되어 있습니다. 범위 설계가 잘못되면 소유권이 확립되지 않고, 소유자가 없으면 범위가 확장되지 않습니다.
▍조직적 장벽
현장 장벽을 극복하더라도 기업에서는 "일단 돌아가는 것"을 만드는 것 이상의 네 가지 벽이 더 있습니다.
④ 토큰 자본의 투명성
부서별로 토큰 소비량을 볼 수 있더라도 "어떤 작업을 했고 어떤 결과를 얻었는지"가 불분명한 경우가 많습니다. 이는 토큰 자본 및 토큰 관리 측면에서 문제가 되어 예산을 정당화할 수 없게 만듭니다. 결과적으로 경영진은 토큰을 단순한 소비 비용으로만 보고 "그래서 비용이 얼마나 드는 거죠?"라고 묻게 됩니다.
⑤ 거버넌스
누가 에이전트를 만들 수 있고, 누가 볼 수 있으며, 누가 관리하는가? 이것이 모호하면 조직은 "떠돌이 에이전트"나 실행은 되지만 아무도 사용하지 않는 "좀비 에이전트"로 넘쳐나게 됩니다. 아무도 책임을 지지 않고, 예산도 확보되지 않으며, 토큰이 낭비되고, 보안 위험이 증가하다가 결국 모든 것이 중단됩니다.
⑥ 관찰 가능성 (Observability)
에이전트가 몇 번 실행되었는지, 얼마나 자주 성공했는지, 어디서 실패했는지. 이는 운영의 최소 요건이지만 많은 도구가 이 부분에서 취약합니다. 보이지 않는 것은 개선할 수 없습니다. 관찰 가능성이 있어야만 에이전트 개선을 위한 피드백 루프를 구축할 수 있습니다.
⑦ 모델 선택의 유연성
특정 LLM 제공업체에 지나치게 의존하는 것은 위험입니다. 성능이 일시적으로 저하되면 어떻게 할까요? 장애로 중단되면 어떻게 할까요? 수출 제한으로 사용할 수 없게 되면 어떻게 할까요? 즉시 다른 제공업체로 전환할 수 없다면 비즈니스 운영에 직접 연결된 에이전트를 구현할 수 없습니다. AI는 이제 인프라가 되었지만, 극단적인 의존이 현재는 맹목적으로 용인되고 있습니다.
요약
에이전트 구현은 기술적 논의처럼 보이지만, 실제로는 비즈니스 설계와 소유권에 관한 문제입니다. "AI가 정말 대단하다"는 수준에서 끝나지 않으려면 거버넌스와 관찰 가능성을 위한 기반이 먼저 필요합니다.
너무 작지도 않고, 너무 크지도 않으며, 책임을 가진 누군가가 키워가는 것. 그리고 조직이 이를 뒷받침하는 시스템. 현장과 조직이 모두 정렬될 때 에이전트가 비로소 자리잡을 수 있다고 생각합니다.
