AI 에이전트 설계는 소프트웨어 엔지니어링 — 시스템 사고로 만드는 법

핵심 메시지

• 에이전트로 코드를 짜는 단계를 넘어, 에이전트 기반 시스템의 아키텍처를 설계하는 단계로 올라가야 한다.
• 구성 요소는 다르지만 규율은 같다 — 시스템 사고, 워크플로 설계, 책임 분리 같은 기존 엔지니어링 원칙이 그대로 적용된다.
• 코드는 결정론에, 에이전트는 판단에, 사람은 권한 행사에 쓴다.
• 에이전트 간 인수인계는 자유 형식 텍스트가 아니라 구조화된 계약(스키마)으로 안전하게 만든다.
• 멱등성·위협 모델링·유지보수성까지 설계에 내재화해야 시스템이 오래간다.

쉽게 이해하기

발표자는 이주(이사)할 집을 찾아주는 ‘릴로케이션 스카우트’ 에이전트를 예로 들며, 에이전트를 일회성 프롬프트로 다루는 것과 재사용 가능한 시스템으로 설계하는 것의 차이를 보여준다. 많은 사람이 에이전트로 코딩하면서 ‘재미있는 부분을 빼앗겼다’는 막연한 불안을 느끼지만, 한 단계 위로 올라가 아키텍처를 설계하면 엔지니어링의 스릴은 그대로 남는다고 말한다.

핵심 주장은 ‘에이전트는 시스템이 아니라 시스템의 일부’라는 것이다. 에이전트는 파일·도구·사람·다른 에이전트와 함께 더 큰 시스템 안에 놓인다. 그래서 ‘그냥 코딩 에이전트에게 다 만들게 하면 되지 않나’라는 접근은 실수이며, 경계·책임·의존성·실패 방식을 먼저 따져야 한다.

거대한 프롬프트는 거대한 함수·비대한 서비스와 같은 ‘코드 스멜’이다. 예외와 안전 수칙을 계속 덧붙이다 보면 프롬프트 하나가 모든 일을 떠안게 되고, 에이전트는 계획에서 벗어난다. 해법은 분해(decomposition)와 책임 분리 — 표준화 로직은 스킬로, 통근 시간 계산은 단순 스크립트로, 동네 조사는 하위 에이전트로 분리한다.

모듈화도 동일하다. 재사용 함수·라이브러리처럼 에이전트 스킬과 하위 에이전트를 재사용 가능한 모듈로 만든다. 다만 모든 것을 추상화할 필요는 없고, 추상화 비용이 더 클 수 있다는 점 또한 엔지니어링적 판단의 영역이다.

마지막으로 계약(구조화 출력), 상태 관리와 멱등성, 위협 모델링, 그리고 유지보수성을 강조한다. 결정은 회의록처럼 묻혀서는 안 되고 질의 가능한 구조화된 메모리에 기록돼야 하며, 같은 작업을 두 번 실행해도 안전하도록 멱등하게 설계해야 한다.

주요 인사이트

• ‘목표(goal)’만으로는 부족하다. 에이전트에는 경로(path) — 무엇을 모으고, 기준에 비추어 평가하고, 행동하는 워크플로 — 가 필요하며, 그 경로가 나머지 아키텍처의 형태를 결정한다.
• 코드는 결정론(정확한 답이 있는 작업), 에이전트는 판단(해석·불확실성), 사람은 권한(최종 승인)으로 역할을 나누면 시스템이 더 싸고 안정적이 된다.
• 출력을 다른 시스템이 받아 행동해야 한다면 계약(스키마)이 필요하다. 출력의 형태를 정의하지 못한다면, 아직 무엇을 만들라고 요청하는지조차 명확히 이해하지 못한 것이다.
• 모델 출력은 흔들리므로, 재시도 시 요청을 슬쩍 바꿔 ‘새 작업’처럼 보이게 만들 위험이 있다. 멱등성은 시스템 차원에서 강제해야 한다.
• 에이전트가 읽는 매물 설명·리뷰 등은 ‘지시’가 아니라 ‘증거’인 신뢰할 수 없는 입력으로 다루고, 자동 이메일·예약 같은 행동에는 사람 승인이라는 보호벽을 둬 폭발 반경을 줄인다.

자주 묻는 질문

관련 AI 소식