AI 에이전트를 서비스에 붙일 때 개발보다 먼저 설계해야 할 것

한줄 요약

AI 에이전트 도입의 실패는 기술 선택이 아니라 위임 범위 설계에서 시작된다.

AI 에이전트를 서비스에 통합하는 프로젝트는 이제 외주 개발 의뢰 중에서도 빠르게 늘고 있는 유형이다. 그런데 실제 프로젝트를 진행해 보면 클라이언트가 가장 먼저 던지는 질문은 대부분 "어떤 모델 쓸 거예요?" 혹은 "자동화 얼마나 가능해요?"다. 기술 스펙부터 확인하려는 것이다. 하지만 에이전트 프로젝트에서 진짜 문제는 거의 항상 다른 곳에서 터진다. 에이전트가 어디까지 혼자 움직이고, 어느 시점에 사람의 판단을 받아야 하는지를 처음부터 제대로 설계하지 않았을 때다.

AI 에이전트 프로젝트, 왜 자꾸 엎어지나

에이전트가 포함된 서비스는 일반 앱이나 웹과 구조적으로 다르다. 기존 서비스는 사용자가 버튼을 누르고 결과를 확인하는 구조다. 에이전트가 들어오면 사용자는 목표만 말하고, 중간 과정은 에이전트가 처리한다. 이 구조에서 사용자 경험의 핵심은 '조작 편의성'이 아니라 '위임 신뢰도'로 바뀐다.

문제는 이 변화를 인식하지 못한 채 개발을 시작하는 경우가 많다는 점이다. 에이전트가 어떤 작업을 자율적으로 수행할 수 있고, 어떤 상황에서는 반드시 사용자 확인을 받아야 하는지, 실패했을 때 사용자에게 무엇을 보여줘야 하는지를 개발 단계 전에 정리해두지 않으면 개발이 한참 진행된 이후에 구조 자체를 뒤엎어야 하는 상황이 생긴다. 실제로 이런 이유로 에이전트 프로젝트가 중간에 리셋되는 경우가 적지 않다.

개발 전에 반드시 답해야 할 세 가지 질문

외주 개발사 입장에서 에이전트 프로젝트 킥오프 전에 클라이언트와 반드시 정리하는 항목이 있다. 기술 스택보다 우선순위가 높다.

첫째, 에이전트가 혼자 처리해도 되는 구간은 어디인가. 반복적이고 규칙이 명확하며, 결과가 잘못돼도 쉽게 되돌릴 수 있는 작업이 여기에 해당한다. 데이터 조회, 정렬, 필터링, 요약 생성 같은 것들이다. 이 구간은 에이전트에 완전히 넘겨도 사용자 신뢰를 해치지 않는다.

둘째, 반드시 사람의 승인이 필요한 지점은 어디인가. 돈이 움직이거나, 개인정보가 외부로 나가거나, 되돌리기 어려운 행동이 실행되는 순간은 에이전트가 단독으로 결정해서는 안 된다. 이 지점을 '신뢰 체크포인트'라고 부른다. 어디에 체크포인트를 놓을지는 서비스 성격에 따라 다르지만, 설계 단계에서 명시적으로 정의해두지 않으면 개발자가 임의로 처리하거나 아예 빠지게 된다.

셋째, 에이전트가 실패했을 때 사용자에게 무엇을 보여주는가. 에이전트는 반드시 실패한다. 조건에 맞는 결과가 없거나, 외부 API가 응답하지 않거나, 사용자 의도를 잘못 해석하는 상황은 무조건 발생한다. 이때 "처리할 수 없습니다"라는 메시지 하나만 띄우는 에이전트는 사용자 신뢰를 잃는다. 실패 원인이 무엇인지, 다음에 어떻게 하면 되는지를 구체적으로 안내하는 설계가 처음부터 포함되어야 한다.

---

에이전트 도입 후 평가 기준도 달라져야 한다

기존 서비스는 전환율, 이탈률, 클릭 수 같은 지표로 성과를 측정한다. 에이전트가 들어오면 이 지표만으로는 서비스가 잘 작동하는지 알 수 없다.

에이전트 기반 서비스에서 실질적으로 의미 있는 지표는 다르다. 사용자가 에이전트에 작업을 실제로 위임하는 비율, 위임한 작업 중 사용자가 개입 없이 완료된 비율, 에이전트 실행을 중간에 취소하거나 되돌리는 빈도, 동일한 작업을 다시 에이전트에 맡기는 재위임율 같은 것들이다. 간단히 말하면, 사용자가 에이전트를 믿고 다시 쓰는지를 봐야 한다.

이 지표를 개발 초기부터 어떻게 수집하고 분석할지 설계해두지 않으면 서비스를 출시한 후에도 에이전트가 제대로 작동하고 있는지 판단할 근거가 없다.

에이전트 프로젝트를 외주로 진행할 때 현실적인 조언

에이전트 기능을 포함한 서비스를 외주 개발로 진행하는 경우, 클라이언트 측에서 준비해야 할 것이 있다.

기술 요구사항 명세서보다 위임 시나리오 문서가 먼저다. 에이전트가 어떤 상황에서 무엇을 하고, 어떤 상황에서는 멈추는지를 텍스트로 정리해야 개발사가 정확하게 구현할 수 있다. 이 문서 없이 "AI가 알아서 처리하게 해주세요"라는 방식으로 진행하면 개발사마다 다르게 해석해서 구현하고, 결국 클라이언트가 원하는 것과 전혀 다른 결과물이 나온다.

또한 에이전트 프로젝트는 일반 앱 개발보다 QA 단계가 복잡하다. 고정된 입력과 출력을 검증하는 게 아니라 다양한 사용자 의도와 예외 상황을 시뮬레이션해야 한다. 이 과정에 충분한 시간과 비용을 배분하지 않으면 출시 이후 사용자 신뢰 문제가 반드시 발생한다.

에이전트를 서비스에 넣는다는 건 단순히 기능 하나를 추가하는 게 아니다. 사용자가 서비스를 사용하는 방식 자체가 바뀐다. 그 변화를 처음부터 설계하는 팀이 결국 출시 후에도 살아남는다.