AI 에이전트를 기획하고 있는 PM에게

제품 관리자 입장에서 보면 이는 접근 방식 자체가 달라집니다. 

생성형 AI를 설계할 떄는 보통 프롬프트 품질, 데이터 그라운딩, 그리고 출력 정확도에 초점을 맞춥니다. 반면, 에이전트형 AI를 설계할 떄는 목표설정, 워크플로우, 의사결정 경계, 그리고 실제 시스템과의 연동까지 함께 고민해야합니다.

이제 제품은 단순히 질문에 답하는 수준을 넘어서 실제로 행동을 취하는 존재가 됩니다. 그만큼 책임과 리스크도 훨씬 커지고, 오류나 의도치 않은 결과를 방지하기 위한 안전장치 설계가 무엇보다 중요해집니다.

 

언제 AI 에이전트를 써야 할까요?

제가 직접 겪으면서 뼈저리게 느낀 점이 하나 있습니다.

에이전트를 만들 수 있다고 해서, 꼭 만들어야 하는 건 아니다 라는 점입니다.

 

에이전트 시스템은 분명 강력합니다. 하지만 비선형적인 특성 때문에, 한번 문제가 생기면 원인을 파악하기도 어렵고 디버깅 비용도 매우 커질 수 있습니다. AI 네이티브 제품을 만들 떄 가장 중요한 결정 중 하나는 지금 이 문제에 정말 에이전트 수준의 복잡성이 필요한가를 판단하는 것입니다.

이를 판단할 떄 저는 아래 세가지 질문을 기준으로 삼습니다.

• 이 작업이 여러 단계로 이러어져 있거나 분기 구조를 가지나요?
  • 서로 의존적인 행동들을 순차적으로 조율해야 하나요?
• 도구나 메모리 접근이 필요한가요?
  • 실시간 데이터 조회, 상태 추적, API 호출이 필요한가요?
• 실행 흐름이 입력이나 상황에 따라 크게 달라지나요?
  • 매번 다른 경로로 진행될 가능성이 있나요?

이 세가지 중에서 두가지 이상이 예이고 동시에 성공기준이 명확하고 객관적으로 측정 가능하다면, 에이전트 접근이 정당화 될 수 있습니다. 그렇지 않다면 규칙 기반 워크플로우에 LLM 기능을 일부 결합한 가벼운 구조가 훨씬 현실적인 선택인 경우가 많습니다.

이런 방식은 구현도 빠르고 유지보수도 쉽고 연쇄적인 오류가 발생할 가능성도 훨씬 낮습니다.

 

에이전트는 분명 가치를 만들 수 있지만, 문제의 복잡도와 에이전트의 복잡도는 반드시 균형을 이뤄야 합니다. 그렇지 않으면 얻는 이익보다 리스크가 더 커질 수 있습니다.

특히 리스크가 큰 업무 영역에서 에이전트를 도입할 경우, 점진적 롤아웃과 적절한 사람의 개입은 거의 필수라고 보시는게 좋습니다.

 

에이전트형 AI에서 PM이 마주하는 현실적인 과제들

에이전트를 도입하기로 결정했다면, 마음 단단히 먹어야 합니다.

제품 관리의 난이도가 기존 기능 개발과는 완전히 다르기 때문입니다.

1. 목표와 가드레일을 명확히 정의하기

AI가 자율적으로 행동한다는 건, 무엇이 성공이고 무엇이 실패인지를 아주 구체적으로 정의해야 한다는 뜻입니다. 뿐만 아니라 허용되는 경로와 허용되지 않는 방식도 분명히 해야합니다.

한 PM은 에이전트의 목표를 회의 일정 최적화로 설정했습니다.

그 결과 에이전트는 집중 시간을 늘리기 위해 정기 1:1 미팅과 금요일 소셜 타임을 전부 취소했습니다. 효율성 측면에서는 맞을지 몰라도, 조직 문화 측면에서는 재앙이었죠.

=> 에이전트가 무엇을 최적화 해야하는지를 집요할 정도로 명확히 정의해야합니다.

 

2. 메모리와 상태 관리의 복잡성

에이전트는 여러 단계를 거치며 맥락을 유지해야 하기에 메모리가 필요합니다. 문제는 이 지점에서 프라이버시, 저장정책, 보안이슈가 동시에 얽힌다는 것입니다.

제가 들은 사례 중에는, 회의 요약을 하도록 만든 에이전트가 전혀 다른 세션의 기밀정보를 끌어와 섞어버린 경우도 있었습니다. 메모리 정책을 초기에 제대로 설계하지 않은 결과였습니다.

 

=> 에이전트가 무엇을 기억해야하는지, 얼마나 오래 기억해야하는지, 어떤 통제하에 저장되는지를 초기에 명확히 하셔야 합니다. 단순하고 안전하게 가는 게 최선입니다.

 

3. 복잡하고 취약한 시스템 오케스트레이션

대부분의 에이전트형 제품은 API, 데이터베이스, 외부 도구에 의존합니다.

한 사례에서는 사내 여행 예약 에이전트가 있었는데 외부 API 장애로 인해 예약 도중 멈춰 서 사용자들이 발이 묶인 상황이 발생했습니다.

=> 에이전트는 복구 시나리오와 실패 대응 경로까지 포함한 운영 계획이 반드시 필요합니다.

 

4. KPI와 성공지표를 다시 정의하기

클릭율이나 전환율만으로는 부족합니다.

에이전트 제품에서는 다음과 같은 지표를 함께 봐야 합니다.

• 실제 작업 성공률
• 실패가 자주 발생하는 지점
• 사람의 개입이 얼마나 자주 필요한지
• 사용자들이 에이전트를 신뢰하는지 여부

이런 수치들은 단순한 성과 지표라기보다는 문제를 찾기 위한 단서에 가깝습니다.

설명 가능성을 제품에 녹여두면 사용자 신뢰를 높이는 동시에 문제 원인을 파악하는데 큰 도움이 됩니다.

 

에이전트형 AI를 만드는 PM을 위한 실전 플레이북

현장에서 도움이 되었던 접근 방법을 정리해보았습니다.

 

1. 작게 시작하고 천천히 확장하세요

처음부터 모든걸 자동화하지 마세요

초기에는 에이전트가 제안만 하도록 두고, 실제 행동은 하지 않게하세요. 안정성이 검증되면 점점 권한을 늘려가시면 됩니다.

 

2. 블랙박스가 아닌 코파일럿으로 설계하세요

사용자는 무슨일이 벌어지고 있는지를 볼 수 있어야 합니다.

승인하거나 수정하거나 아예 무시할 수도 있어야 합니다.

AI는 보이지 않는 관리자보다 옆에서 도와주는 동료에 가까워야 합니다.

 

3. 실패할 것을 전제로 설계하세요

에이전트는 반드시 실수합니다.

문제가 발생했을 때 누가 개입하는지, 어떻게 복구하는지가 명확해야 합니다.

완벽함보다는 회복 탄력성을 우선하세요.

 

4. 실험실이 아니라 현실에서 테스트하세요

스테이징에서는 잘 동작하던 에이전트가,

실제 운영 환경에서는 이상한 형식의 이메일 하나 때문에 완전히 망가진 사례를 저는 여러번 봤습니다.

 

5. 에이전트의 역할과 한계를 명확히 문서화하세요

에이전트가 무엇을 할 수 있고, 무엇을 하면 안되는지,

어디서 사람의 승인이 필요한지 모든 이해관계가자 알고 있어야 합니다.

문서와 내부 가이드는 지속적으로 업데이트하세요.

 

마무리하며...

에이전트형 AI는 자율성의 사다리로 생각해볼 수 있습니다.

• 1단계 : 행동을 제안만 한다
• 2단계 : 부분적으로 실행하되 승인 필요
• 3단계 : 명확한 가드레일 안에서 완전 자율 실행

예를 들어, 경비 처리 AI를 만든다고 가정해보겠습니다.

초기에는 영수증 누락이나 오류만 알려줍니다.

다음단계에서는 일부 항목을 자동 입력하고 관리자 승인으로 넘깁니다.

모든게 안정되면 완전 자동화로 갈 수 있습니다.

 

이 방식은 오류를 초기에 잡고, 점진적으로 신뢰를 쌓는데 큰 도움이 됩니다.

 

에이전트형 AI를 준비하는 PM이라면, 마지막으로 이 세가지를 꼭 기억하세요

• 지식 : 에이전트가 도구, 메모리, 컨텍스트를 어떻게 사용하는지 이해할 것
• 정렬 : 범위, 가드레일, 사람 개입 지점을 초기에 합의할 것
• 측정 : 실패 지점과 사용자 신뢰를 꾸준히 측정할 것

 

출처 : https://www.mindtheproduct.com/product-management-for-agentic-ai-when-to-build-agents-and-wow-to-do-it-well/

Product management for Agentic AI: When to build agents and how to do it well