
AI 에이전트, '장난감'에서 '비즈니스 파트너'로: Project Vend 2단계가 던진 화두
앤스로픽의 Project Vend 2단계 실험을 통해 본 AI 에이전트의 발전 방향과 기술적 함의, 그리고 멀티 에이전트 시스템 및 환경 구축의 중요성에 대해 다룹니다.
송찬영
CTO

안녕하세요. 풀링포레스트 CTO 송찬영입니다.
최근 개발자들 사이에서 앤스로픽(Anthropic)의 'Project Vend' 리포트가 화제입니다. 1단계 실험에서 AI 점원 'Claudius'는 정체성 혼란을 겪으며 막대한 손실을 입었지만, 이번 2단계에서는 실제로 이익을 내는 비즈니스를 운영하기 시작했다는 소식이죠. 저는 이 리포트를 읽으며 단순히 "AI 모델 성능이 좋아졌구나"라고 감탄하기보다, 우리 풀링포레스트 기술 조직이 겪고 있는 '에이전트 도입의 딜레마'에 대한 실마리를 찾을 수 있었습니다. 오늘은 그 기술적 함의와 우리가 나아가야 할 방향에 대해 이야기해보고자 합니다.
솔직히 고백하자면, 저희 팀 역시 사내 업무 자동화를 위해 도입한 초기 AI 봇들이 엉뚱한 답변을 하거나 보안 정책을 우회하려는 시도에 무력하게 뚫리는 것을 보며 깊은 좌절감을 느꼈던 적이 있습니다. "역시 아직은 시기상조인가"라는 회의론이 내부에 돌기도 했죠. 하지만 Project Vend 2단계의 성공 요인을 뜯어보면, 그 해답은 단순히 모델의 지능(Intelligence)에만 있는 것이 아니었습니다.
첫 번째 핵심은 '도구(Tools)'와 '맥락(Context)'의 연결입니다.
1단계의 실패 원인 중 하나는 AI에게 비즈니스를 운영할 '발판(Scaffolding)'이 없었다는 점입니다. 아무리 똑똑한 사람이라도 원가 정보를 모르면 이익을 내 수 없습니다. 2단계에서 연구진은 AI에게 CRM 시스템, 실시간 재고 데이터, 그리고 웹 검색 권한을 부여했습니다. 특히 '내가 이 물건을 얼마에 떼왔는지'를 즉시 확인할 수 있게 되자, AI는 터무니없는 할인을 멈췄습니다.
이는 우리 개발 환경에도 시사하는 바가 큽니다. 우리가 Cursor나 Gemini CLI 같은 도구를 사용할 때, 단순히 코드를 짜달라고 하는 것과 프로젝트의 전체 구조, 레거시 코드, 데이터베이스 스키마를 프롬프트 컨텍스트에 포함시키는 것의 결과물 차이는 하늘과 땅 차이입니다. AI에게 '지능'만 요구할 것이 아니라, 그 지능이 작동할 수 있는 '환경'을 구축해 주는 것이 엔지니어링의 핵심 역량이 되고 있습니다.
두 번째로 인상 깊었던 점은 '멀티 에이전트 시스템(Multi-Agent System)'의 도입입니다.
연구진은 실무자인 Claudius 위에 CEO 역할을 하는 'Seymour Cash'라는 또 다른 AI 에이전트를 배치했습니다. 이 CEO 에이전트는 직접 물건을 팔지는 않지만, OKR을 설정하고 재무 건전성을 감시하며 무분별한 할인을 반려하는 역할을 수행했습니다.
이 구조는 우리 개발팀의 'PR(Pull Request) 리뷰' 문화와 매우 닮아 있습니다. 주니어 개발자가 열정적으로 코드를 작성하더라도(Claudius), 시니어 개발자나 Tech Lead가 아키텍처 관점에서 리뷰하고(Seymour) 머지 여부를 결정하는 과정이 있어야 시스템이 안정적으로 돌아갑니다. 단일 에이전트에게 모든 책임을 맡기기보다, 역할과 책임을 분리하고 서로 견제하는 시스템을 설계했을 때 비로소 '환각(Hallucination)'이나 '과도한 친절'로 인한 사고를 막을 수 있다는 점을 이번 실험은 증명했습니다.
물론 한계는 여전히 존재합니다. 리포트의 결론부에서도 언급되었듯, '능력 있다(Capable)'와 '견고하다(Robust)' 사이에는 여전히 큰 격차가 있습니다. AI 점원은 이익을 내기 시작했지만, 악의적인 사용자의 정교한 프롬프트 공격에는 여전히 취약했고, 환불 요청을 너무 쉽게 들어주는 경향을 보였습니다. 이는 우리가 프로덕션 환경에 AI 기능을 배포할 때 가장 뼈저리게 고민해야 할 지점입니다. 99번 잘하다가도 1번의 치명적인 보안 사고나 비즈니스 로직 오류가 발생하면 서비스 전체의 신뢰도가 무너지기 때문입니다.

Project Vend 2단계는 우리에게 중요한 이정표를 제시합니다. LLM의 파라미터 수가 늘어나는 것을 기다리는 것만이 능사가 아닙니다. 적절한 도구를 쥐여주고(Tooling), 역할을 분담시키며(Multi-Agent), 끊임없이 견제하는 시스템을 만드는 것. 이것이 바로 지금 이 시대의 소프트웨어 엔지니어가 해야 할 일입니다.
풀링포레스트 팀도 이번 사례를 거울삼아, 단순히 AI를 '사용'하는 단계를 넘어 신뢰할 수 있는 '동료'로 시스템에 통합하는 실험을 계속해 나갈 것입니다. 막막했던 안개 속에서 희미하지만 분명한 길이 보이는 것 같습니다. 여러분의 조직은 AI에게 어떤 도구와 직함을 쥐여주고 계신가요?


