Forter는 프로그래밍 전문 지식의 필요성을 줄이고 분석가와 엔지니어가 아이디어를 신속하게 실험할 수 있는 환경을 설계한 뒤, 2주 동안 진행된 실전 구축 스프린트에서 약 200명이 AI 에이전트 구축에 참여하도록 했다. 회사의 수석 엔지니어인 Ben Maraney는 이 경험을 에이전트 구축의 모든 과제를 한꺼번에 해결하려 하기보다 불필요한 복잡성을 제거하는 과정에서 얻은 교훈으로 소개한다.
시작: 5주 기한의 실전 스프린트
목표는 연구개발팀이 자체 에이전트를 만들도록 교육하는 것이었다. 여기에는 법률, 심리학, 과학 분야의 배경을 가진 분석가들도 포함됐으며, 이들 중 일부는 이전에 SQL을 작성해 본 적이 없었다. 팀은 5주 안에 환경을 준비한 뒤 2주 동안 구축 스프린트를 진행해야 했다. 따라서 설계는 도구, 플랫폼, 사용자 앞의 장애물 제거라는 세 가지 축에 집중했다.
분산된 도구 대신 중앙 MCP 서버
Forter는 MCP 프로토콜 기반의 내부 서버를 사용했으며, 이를 Toolchain이라고 명명했다. 이 서버는 도구를 검색하고 실험하며 각 에이전트에 필요한 연결을 생성할 수 있는 단일 인터페이스를 제공했다. 또한 사용자가 에이전트에 필요한 도구만 선택할 수 있도록 해, 혼란을 일으키거나 부적절한 도구를 사용하게 만들 수 있는 광범위한 접근 권한을 부여하지 않았다.
도구 수는 팀 설립 당시 약 20개에서 스프린트 시작 시점에는 약 60개로, 스프린트 종료 2주 후에는 거의 100개로 늘어났다. 저장소를 통합하고 명확한 예시와 설정 파일을 마련한 덕분에 새로운 도구를 신속하게 추가할 수 있었으며, 토큰 소비와 도구 사용량을 모니터링하는 등의 거버넌스 기능도 제공했다.
짧은 기간 안에 맞춤형 검색 증강 생성(RAG) 시스템을 구축하는 대신, Forter는 Toolchain을 Confluence, Asana, Jira, Slack, Salesforce 같은 내부 소스를 검색하는 데 사용되는 Glean 플랫폼과 연결했다. 그리고 관련 문서와 구절 검색, 문서 전체 읽기, 에이전트가 지정한 질문이나 주제에 따른 요약이라는 세 가지 유형의 도구를 제공했다.
코딩 없는 플랫폼에서 맞춤형 솔루션까지
Forter는 빠르고 코딩이 거의 필요 없는 대화형 경험을 제공하기 위해 LibreChat을 사용했다. 사용자는 에이전트가 호출한 도구, 전송한 질의와 매개변수, 받은 결과를 확인할 수 있었다. 이는 에이전트의 동작을 이해하고 문제를 조기에 발견하는 데 도움이 됐지만, MCP 통합이 때때로 불안정했고 버전 관리와 맞춤 설정에 대한 제어도 제한적이었다.
더 복잡한 사례를 위해 회사는 개발자에게 코드 전체를 제어하고 도구와 하위 에이전트를 추가할 수 있게 하는 템플릿 저장소를 제공했다. 그러나 특히 분석가에게는 설정과 배포가 더 느렸다. 이후 Forter는 AI Hub라는 내부 인터페이스를 만들어 모델을 선택하고, 시스템 메시지를 작성하며, 도구를 지정한 뒤 몇 단계만으로 에이전트를 공유할 수 있도록 했다.
비대화형 에이전트에는 Strands 프레임워크와 Argo Workflows를 사용해 일정이나 Jira 및 Asana 티켓 생성 같은 이벤트에 따라 실행했다. Maraney는 기존의 일정 관리 및 실행 시스템이 있다면 에이전트 전용의 새로운 구조가 필요하지 않을 수 있다고 설명한다.
실제로 무엇을 구축했는가?
사용 사례에는 분석가가 더 나은 가설과 실험을 수립하도록 돕고, 사고 후 보고서를 검토하며, Snowflake와 Databricks 노트북을 사용해 판매자의 성능 저하를 분석하는 에이전트가 포함됐다. 또한 회사는 Layla와 Penny 같은 전문가 에이전트를 개발해 코드, 설정, 데이터에 접근하고 거래 의사결정 및 결제와 관련된 질문에 답하도록 했다. Layla는 시스템에 대한 지식이 어느 한 개인보다 넓어지면서 고객 성공팀과 지원팀으로도 사용이 확대됐다.
비대화형 에이전트의 사례로는 유사한 판매자를 바탕으로 신규 판매자를 위한 초기 설정을 제안하고, 지원 티켓이 접수되면 초기 조사를 준비하며, 이상 상태 알림을 분석하고 코드 변경 사항과 연결하는 기능이 있었다. Forter는 사고 대응 에이전트도 시험했지만, 겉보기에는 뛰어난 결과가 실제로는 BetterNext 보고서에 과거에 사람들이 작성한 근본 원인 분석을 주로 복사한 데 의존하고 있다는 사실을 발견했다.
실무적으로 무엇이 달라지는가?
이 경험은 관찰 가능성이 부차적인 기능이 아니라는 점을 보여준다. 에이전트가 의존하는 도구, 매개변수, 결과를 표시하는 것은 사고 대응 에이전트가 실제로 근본 원인을 추론하지 않았다는 사실을 발견하는 데 필수적이었다. 이에 따라 Forter는 이후 Langfuse를 추가해 에이전트 세션, 도구 호출, 작업 흐름을 추적했다.
또한 이 경험은 여러 플랫폼을 사용하는 것이 의도적인 선택일 수 있음을 보여준다. 즉, 빠른 실험을 위한 코딩 없는 플랫폼, 맞춤 설정을 위한 소프트웨어 솔루션, 이벤트나 일정에 따라 작동하는 에이전트를 함께 사용하는 방식이다. 반면 회사는 에이전트마다 별도의 저장소를 만드는 모델에서 문제를 겪었고, 추적과 같은 공통 기능을 쉽게 도입하기 위해 서로 연결된 에이전트를 더 적은 수의 저장소에 통합하는 방식으로 돌아갔다.
Maraney는 적합성, 일관성, 안전성과 같은 일반적인 평가 지표가 품질에 대해 잘못된 인상을 줄 수 있다고도 경고한다. 유용한 평가는 답변의 정확성, 적절한 도구 사용, 올바른 맥락 검색을 시험해야 하는데, 이는 더 어렵고 좋은 답변이 무엇을 의미하는지에 대한 정확한 지식이 필요하다. 따라서 인간이 의사결정 과정에 참여하는 내부 실험에서는 고급 평가를 미룰 수 있지만, 이를 평가의 영구적인 대안으로 여겨서는 안 된다.
확장 이니셔티브에는 법무 및 보안팀도 조기에 참여해야 하며, 특히 데이터가 처리되고 보관되는 위치와 관련된 사항이 중요하다. Maraney는 Amazon Bedrock 같은 클라우드 서비스를 사용하고 데이터 미보존 정책을 문서화한 것이 이러한 우려를 조직의 통제 범위 안에서 다루는 데 도움이 됐다고 설명한다. 그 결과 모든 에이전트를 별도의 승인 사례로 전환하지 않고도 문제를 처리할 수 있었다.