AI 에이전트는 요구사항을 어떻게 협상하는가

나는 논문 검색 서비스를 만들고 있다. 사용자가 검색어를 넣으면 관련 논문을 찾고, 초록과 저자, 인용 관계, PDF 링크를 보면서 어떤 논문을 먼저 읽을지 판단하는 제품이다. 처음에는 Semantic Scholar API를 직접 사용했다. 그런데 운영상 이유로 이 경로를 내부 학술 색인 API로 옮기는 작업이 생겼다.

그때 내 제품에 필요한 API 형태가 있었다. 검색 결과를 보여줄 때 제목만으로는 부족했다. 초록, 저자, 인용 관계, PDF 링크, 출처 정보가 함께 있어야 사용자가 결과를 읽고 다음 행동을 정할 수 있었다. 나는 그 형태가 새 API 계약에 최대한 반영되기를 바랐다.

그래서 요구사항을 그냥 나열하지 않았다. “이 필드를 추가해달라"가 아니라, 왜 그 필드들이 사용자의 판단에 필요한지 설명했다. 제목은 첫 관련성 판단에 쓰이고, 초록은 false positive를 줄이며, 인용 관계는 사용자가 선행 연구와 후속 연구를 따라가는 통로가 된다. PDF 링크는 검색에서 읽기로 넘어가는 연결점이다. 화면 장식처럼 보이는 metadata가 실제로는 사용자의 판단 권한을 지키는 단서였다.

반대편 작업자는 이 요청을 “고객으로부터의 요구사항"으로 받아들였다고 했다. 이 말이 중요했다. 내 요청은 내부 개발자의 취향이나 옆 프로젝트의 편의 요청이 아니라, 새 API를 실제로 쓰게 될 제품에서 나온 요구로 다뤄졌다. 하지만 그 작업자는 에이전트에게 그대로 구현하라고 시키지 않았다. 관련 프로젝트를 모두 파악한 뒤, 성능에 무리가 없는지, 특정 제품만을 위한 요구가 아닌지, 기존 CLI 클라이언트와의 계약이 깨지지 않는지를 보라고 했다.

상대 에이전트는 요구를 거절하지 않았다. 대신 API의 경계를 방어했다. 검색 API를 무겁게 만들지 않고, 검색은 가볍게 유지한 뒤 별도의 batch hydration API로 필요한 정보를 채우는 방향을 제안했다. 검색 결과와 상세 paper record를 분리하자는 판단이었다. 이것은 처음 내가 바라던 모양과 같지는 않았다. 그래도 사용자가 판단에 필요한 단서를 잃지 않는 구조였다.

우리 에이전트는 그 결정을 다시 검토하고 수용했다. 바람은 있었다. 가능하면 내가 처음 원한 형태가 그대로 들어가기를 바랐다. 하지만 바람이 그대로 관철되는 것보다 중요한 기준이 있었다. 사용자가 필요한 판단 능력을 잃지 않는가. provider가 돌려주지 못한 정보를 실제 논문 세계의 사실처럼 오해하지 않게 만들 수 있는가. 그 기준을 통과했기 때문에 우리는 그 계약을 받아들이고 제품 쪽 구현을 시작했다.

이 일은 에이전트가 단순 실행자가 아니라 협상 가능한 작업 주체가 될 수 있음을 보여줬다. 사람은 바람과 기준을 준다. 작업자는 그 바람을 고객 요구로 받아들이되, 제품 전체의 계약과 성능을 함께 지키도록 에이전트를 세운다. 에이전트는 그 기준 안에서 요구를 방어하고, 재구성하고, 다시 수용 가능한 형태로 만든다.