Shippy 프로젝트 소개: 왜 갑자기 화제일까?
최근 AI 업계에서 가장 많이 회자되는 키워드 중 하나가 바로 AI 에이전트 개발입니다. 그 흐름을 주도한 사례 가운데 Shippy라는 프로젝트가 큰 주목을 받고 있습니다. Shippy는 단순히 질문에 답하는 챗봇을 넘어, 스스로 판단해 외부 도구를 호출하고 작업을 끝까지 완수하는 ‘에이전트 구조’를 본격적으로 구현한 서비스입니다.
왜 갑자기 화제일까요? 핵심은 그동안 엔지니어들이 머릿속으로만 상상하던 ‘자율적으로 일하는 AI’를 실제로 배포 가능한 수준으로 끌어올렸기 때문입니다. 무엇보다 가치를 더하는 부분은, 구축 과정에서 얻은 현실적인 노하우를 거리낌 없이 공유했다는 점입니다. 이론이 아닌 실전 데이터, 그리고 시행착오가 그대로 녹아 있어, 에이전트를 만들어 보고자 하는 개발자들 사이에서 필독 사례로 불리고 있습니다.
교훈 1: 명확한 역할(Role) 정의가 성패를 가른다
첫 번째 교훈은 생각보다 평범하지만, 가장 많이 간과되는 부분이기도 합니다. 바로 에이전트의 역할을 명확하게 정의해야 한다는 점입니다. 시스템 프롬프트 한 줄, 혹은 첫 지시문에 “너는 무엇을 하고, 무엇을 해서는 안 되는가”를 분명히 적어야 합니다.
추정컨대, 역할이 모호할수록 환각(Hallucination) 발생 빈도가 눈에 띄게 높아지는 경향이 있었습니다. ‘범용 비서’처럼 막연한 정체성을 부여하면, 모델은 답을 찾기 어려운 상황에서도 그럴듯한 문장을 만들어내려 합니다. 반면 “이 에이전트는 A 작업만 수행하며, A 범위를 벗어나면 정중하게 거절한다”처럼 경계가 뚜렷하면 출력의 안정성이 크게 향상되었습니다.
Shippy팀은 이 문제를 운영적으로 해결했습니다. 시스템 프롬프트를 한 덩어리의 텍스트가 아니라 모듈화된 구성요소로 설계한 것입니다. 역할, 금지 행동, 도구 사용 규칙, 응답 톤 등을 분리해 두면, 사용자 피드백이나 정책 변화에 따라 일부 모듈만 교체해 즉시 업데이트할 수 있습니다. 결과적으로 동일한 모델을 그대로 두면서도 에이전트의 행동을 빠르게 진화시킬 수 있었습니다.
교훈 2: 도구(Tool) 호출은 ‘제한과 검증’이 핵심이다
두 번째 교훈은 도구 호출(Tool Calling)에 관한 것입니다. 에이전트가 강력해지는 이유 자체가 외부 도구를 자유자재로 쓸 수 있기 때문이지만, 동시에 그 지점이 가장 큰 위험 지점이기도 합니다. Shippy는 이 부분을 매우 엄격하게 통제했습니다.
첫째, 에이전트가 호출 가능한 도구를 화이트리스트 방식으로 제한했습니다. 미리 정의된 함수 목록 외에는 어떤 도구도 사용할 수 없도록 설계해, 예기치 못한 권한 남용을 차단했습니다. 둘째, 모든 호출은 스키마(Schema) 검증을 거쳐야만 실행되도록 가드레일을 두었습니다. 입력 파라미터의 타입과 형식이 명세에 맞지 않으면 즉시 거부되며, 잘못된 인자로 인한 시스템 오류를 사전에 방지할 수 있습니다.
여기서 얻은 시사점은 분명합니다. LLM의 추론 능력과 도구의 결정적(Deterministic) 실행 능력을 적절히 결합하는 것이 안정성을 비약적으로 끌어올린다는 것입니다. 모델이 “무엇을 할지”를 정하면, 도구는 정해진 절차대로 “실제로 그것을 정확히 수행”합니다. 이 구분이 흐려질수록 사고도 함께 커집니다.
교훈 3: 메모리(Memory)와 상태 관리의 새로운 접근
세 번째 교훈은 에이전트 고유의 메모리 설계입니다. 단순한 챗봇이라면 “이전 대화 내용을 이어 붙인다” 정도면 충분하지만, 실제 작업을 수행하는 에이전트는 훨씬 복잡한 상태를 다뤄야 합니다.
Shippy는 대화 로그를 그대로 누적하는 대신, 작업 단위로 컨텍스트를 요약·저장하는 방식을 채택했습니다. 예를 들어 “지금까지 어떤 단계를 거쳤는지”, “다음에 무엇을 해야 하는지” 같은 정보를 작업 메모리에 압축해 기록합니다. 이렇게 하면 토큰 비용을 줄이면서도 핵심 맥락은 잃지 않을 수 있습니다.
또한 장기 메모리와 단기 작업 메모리를 분리한 점도 주목할 만합니다. 사용자 프로필이나 반복적으로 등장하는 선호도 같은 정보는 장기 저장소에서, 현재 진행 중인 작업의 중간 상태는 단기 저장소에서 관리합니다. 이 분리 덕분에 여러 세션에 걸쳐 작업을 이어가도 일관성이 유지되며, 비용과 성능 사이의 균형도 자연스럽게 맞춰졌습니다. 에이전트가 진짜로 ‘연속성 있는 작업자’처럼 느껴지게 만드는 핵심 장치였습니다.
교훈 4 & 5: 평가(Evaluation)와 반복 개선 문화
네 번째와 다섯 번째 교훈은 서로 맞물려 있어 함께 다루는 것이 자연스럽습니다. 첫째, 자동화된 평가 파이프라인을 매 변경마다 실행했다는 점입니다. 기존 소프트웨어에서 단위 테스트와 통합 테스트를 CI(지속적 통합) 단계에서 돌리듯, Shippy팀도 에이전트의 응답을 자동으로 채점하는 테스트 스위트를 운영했습니다.
둘째, 실패 사례를 데이터셋으로 축적해 프롬프트와 도구 로직을 지속 개선하는 사이클을 만들었습니다. 평가 결과가 좋지 않은 케이스는 사람이 다시 분석하고, 그 내용을 다시 평가셋에 반영했습니다. 이는 단순한 품질 관리를 넘어, 에이전트가 스스로 학습하는 조직 문화와도 닮아 있습니다.
추정컨대, 이러한 ‘에이전트용 DevOps’ 문화가 향후 에이전트 개발의 사실상 표준이 될 가능성이 높습니다. 모델만 잘 만드는 시대는 지났고, 평가 인프라와 개선 루프를 갖췄느냐가 제품 경쟁력을 가르는 시점이 오고 있습니다.
정리: 내 프로젝트에 적용할 다음 단계
지금까지 살펴본 다섯 가지 교훈을 한눈에 정리하면 다음과 같습니다.
- 명확한 역할 정의: 시스템 프롬프트를 모듈화해 경계와 책임을 분명히 한다.
- 제한과 검증 기반의 도구 호출: 화이트리스트와 스키마 검증으로 안전성을 확보한다.
- 메모리 분리 설계: 장기 기억과 단기 작업 기억을 구분해 비용과 성능을 균형 있게 관리한다.
- 자동화된 평가 파이프라인: 모든 변경에서 회귀 테스트를 자동 수행한다.
- 실패 기반 반복 개선 문화: 실패 사례를 자산으로 전환하는 학습 루프를 만든다.
이 교훈들을 바로 자신의 프로젝트에 적용해 보고자 한다면, 다음 단계를 권합니다. 먼저 현재 사용 중인 시스템 프롬프트를 모듈 단위로 분리해 보고, 도구 목록을 화이트리스트로 다시 정리하세요. 그리고 사용자 로그에서 실패 사례 10개만 직접 모아 “이 케이스를 자동으로 잡아낼 수 있는 평가 항목이 무엇이었을까”를 떠올려 보는 것입니다. 그 질문에서 출발하는 것이 가장 현실적인 시작점이 될 것입니다.
