에이전트 시스템도 소프트웨어 공학 원칙이 필요하다
에이전트(Agent) 기반 시스템이 빠르게 확산되면서, 많은 팀이 "일단 돌아가게 만들기" 방식으로 구현을 시작한다. 프롬프트를 이어붙이고, 툴 호출을 스크립트처럼 연결하는 방식이다. Jake Mannix는 이런 구조를 "1970년대 BASIC 코드"에 비유한다. 전역 상태가 난무하고, 관심사가 분리되지 않으며, 변경 한 줄이 전체를 흔드는 구조다. 규모가 커질수록 이 문제는 기술 부채가 아니라 운영 리스크가 된다.
백엔드 개발자 입장에서 보면 이 문제는 낯설지 않다. REST API 설계 초기에도 비슷한 혼란이 있었다. 엔드포인트마다 다른 포맷, 버전 없는 스키마, 내부 구현이 그대로 노출된 인터페이스. 에이전트 시스템은 지금 그 시기를 반복하고 있다.
중간 프로토콜 레이어와 가상 툴 아키텍처
이 문제를 해결하는 핵심 개념이 중간 프로토콜 레이어(intermediate protocol layer) 다. 에이전트가 외부 서비스나 내부 API를 직접 호출하는 대신, 버전 관리와 캡슐화가 적용된 가상 툴(virtual tools) 을 통해 간접적으로 접근하는 구조다.
이 구조가 제공하는 세 가지 핵심 기능은 다음과 같다.
- 인터페이스 매핑(interface mapping): 내부 구현이 바뀌어도 에이전트가 바라보는 툴 인터페이스는 안정적으로 유지된다. 의존성 역전 원칙과 동일한 발상이다.
- 동적 스키마 프로젝션(dynamic schema projection): 컨텍스트나 권한에 따라 툴이 노출하는 스키마를 런타임에 조정할 수 있다. 불필요한 필드를 숨기거나, 역할별로 다른 뷰를 제공하는 것이 가능하다.
- 런타임 오염 추적(runtime taint tracking): 외부 입력이 시스템 내부로 어디까지 전파되는지 추적한다. 데이터 유출 경로를 코드 변경 없이 사전에 차단할 수 있다.
// 직접 호출 방식 (안티패턴)
externalApiClient.fetchUserData(userId);
// 가상 툴을 통한 간접 호출
virtualToolRegistry.invoke("user-data-tool@v2", Map.of("userId", userId));
두 번째 방식은 호출부가 내부 구현을 알 필요가 없고, 레지스트리 레벨에서 버전 전환, 권한 검사, 오염 추적을 일괄 처리할 수 있다.
실무에서 이 구조가 중요한 이유
에이전트 시스템의 보안 위협 중 많은 부분이 프롬프트 인젝션을 통한 데이터 유출이다. 에이전트가 외부 입력을 그대로 툴 파라미터로 넘기거나, 내부 API 응답을 필터링 없이 다음 단계로 전달하면 의도치 않은 정보가 외부로 빠져나갈 수 있다. 런타임 오염 추적은 이 흐름을 가시화하고 차단점을 명시적으로 설정할 수 있게 한다.
개발 속도 측면에서도 이 구조는 유리하다. 가상 툴 인터페이스가 안정적이면 에이전트 로직과 백엔드 구현을 독립적으로 변경할 수 있다. 팀이 나뉘어 병렬 작업하기도 쉽고, 특정 툴만 목(mock)으로 교체해 테스트하는 것도 자연스럽게 가능해진다. 이는 마이크로서비스 환경에서 계약 테스트(contract testing)가 주는 이점과 본질적으로 같다.
정리
- 에이전트 시스템도 캡슐화, 버전 관리, 관심사 분리 등 전통적인 소프트웨어 공학 원칙이 동일하게 적용되어야 한다.
- 중간 프로토콜 레이어와 가상 툴 구조는 인터페이스 안정성을 보장하면서 내부 구현 변경을 자유롭게 한다.
- 런타임 오염 추적은 데이터 유출 경로를 사전에 식별하고 차단하는 실질적인 보안 수단이다.