전통적인 SaaS는 제품 팀이 미리 정의한 워크플로를 실행합니다. AI 에이전트는 목표를 달성하기 위해 런타임에 일부 단계를 선택합니다. 이 차이로 인해 권한, 테스트, 인터페이스, 실패 처리, 단위 비용이 달라집니다.
많은 제품에는 두 방식이 함께 들어 있습니다. 고객 지원 애플리케이션은 일반 코드로 고객을 인증하고 청구서를 조회한 뒤, 모호한 결제 문의를 조사할 때 에이전트를 사용할 수 있습니다. 제품 전체를 에이전트형이라고 부르면 엔지니어가 제어해야 할 경계가 가려집니다.
워크플로가 결정되는 방식
SaaS에서는 제품이 허용된 경로를 코드로 정합니다. 사용자가 청구서를 선택하고 환불을 클릭한 뒤 금액을 확인하면 결과가 표시됩니다. 요청이 시작되기 전부터 인터페이스와 백엔드는 가능한 상태를 알고 있습니다.
에이전트는 목표에서 시작해 주어진 컨텍스트에 따라 도구를 선택합니다. 검색 결과, 도구 오류, 모델 선택이 달라지면 두 실행이 서로 다른 경로를 택할 수 있습니다. 애플리케이션에는 어떤 경로가 허용되는지 정하는 엄격한 규칙이 여전히 필요합니다.
OpenAI의 에이전트 구축 실전 가이드는 복잡한 판단, 깨지기 쉬운 규칙, 상당한 비정형 데이터가 있는 워크플로에 에이전트를 권장합니다. 일반 코드로 판단을 표현할 수 있다면 고정 워크플로가 더 명확한 설계입니다.
엔지니어링 관점의 차이
| 영역 | 전통적인 SaaS | AI 에이전트 애플리케이션 |
|---|---|---|
| 워크플로 | 코드에 미리 정의됨 | 허용된 경계 안에서 실행 중 선택됨 |
| 인터페이스 | 알려진 상태를 위한 화면과 엔드포인트 | 목표, 컨텍스트, 도구, 생성된 중간 단계 |
| 인가 | 사용자 작업이 알려진 엔드포인트에 매핑됨 | 선택한 모든 도구와 다운스트림 작업에 인가 필요 |
| 테스트 | 알려진 입력에 대한 예상 출력 | 작업 성공, 도구 선택, 금지된 작업, 실행 간 편차 |
| 실패 | 대개 알려진 단계에서 오류가 표시됨 | 잘못된 단계나 출처를 토대로 그럴듯한 답을 만들 수 있음 |
| 복구 | 요청을 재시도하거나 오류 표시 | 완료된 효과를 조정한 뒤 체크포인트에서 재개 |
| 비용 | 주로 요청과 인프라에 비례 | 토큰, 도구 호출, 재시도, 실행 시간에도 비례 |
| 관측성 | 요청, 서비스, 데이터베이스 트레이스 | 기존 트레이스에 모델, 도구, 정책, 평가 기록 추가 |
메모리, 도구, 상태, 내구성 실행을 다루는 애플리케이션 아키텍처는 이런 차이에서 출발합니다.
가장 먼저 달라지는 권한 설계
SaaS 버튼은 좁은 작업 하나를 수행하는 엔드포인트 하나를 호출할 수 있습니다. 에이전트는 스무 개의 도구 중에서 골라 제품 팀이 작성하지 않은 순서로 조합할 수 있습니다. 백엔드는 현재 사용자, 테넌트, 리소스를 기준으로 모든 호출을 인가해야 합니다. 시스템 프롬프트의 문장 하나로 접근 권한을 부여하거나 제거할 수는 없습니다.
OWASP의 Excessive Agency 지침은 과도한 기능, 권한, 자율성을 구분합니다. 이 기준으로 워크플로에 필요 없는 도구를 제거하고, 남은 도구의 자격 증명 범위를 좁히며, 영향이 큰 작업 전에 승인을 요구하세요.
테스트는 동작 중심으로 바뀝니다
단위 테스트는 환불 함수가 음수를 거부한다는 사실을 증명할 수 있습니다. 하지만 사용자가 환불을 요청했을 때만 에이전트가 항상 환불 도구를 선택한다는 사실까지 증명하지는 못합니다. 따라서 에이전트 평가에는 대표 작업, 예상 도구 선택, 금지된 작업, 반복 실행이 필요합니다.
출력만 확인해서는 부족합니다. 다른 테넌트의 레코드를 읽고 만든 정답도 심각한 실패입니다. 프로덕션 전 AI 에이전트 평가 가이드는 작업과 트레이스 검증을 함께 다룹니다.
인터페이스는 불확실성을 드러내야 합니다
전통적인 SaaS는 일반적으로 결제 완료, 실패, 대기처럼 알려진 상태를 표시합니다. 에이전트에는 불완전한 근거나 서로 충돌하는 출처가 있을 수 있습니다. 제품은 에이전트가 사용한 정보, 확신하지 못하는 부분, 다음으로 제안하는 작업을 보여 줘야 합니다.
승인 화면에는 정확한 효과를 표시해야 합니다. "계속"은 정보가 부족합니다. "청구서 1842를 $42.00 환불"이라고 쓰면 검토자가 승인할 대상을 구체적으로 알 수 있습니다.
에이전트가 적합하지 않은 경우
규칙이 안정적이고 입력이 구조화되어 있으며 올바른 작업을 코드로 직접 표현할 수 있다면 워크플로를 결정론적으로 유지하세요. 인증, 할당량 적용, 결제 정산, 권한 검사, 데이터베이스 제약 조건은 에이전트가 호출하더라도 일반 코드에 있어야 합니다.
정돈되지 않은 컨텍스트를 판단한 결과에 따라 작업 순서가 달라질 때 에이전트를 사용하세요. 작은 도구 모음만 제공하고, 절대 달라져서는 안 되는 규칙은 백엔드가 강제하게 합니다.
워크플로 하나의 경계를 그리세요
워크플로 하나를 골라 모든 단계를 결정론적 코드, 모델 판단, 사람의 승인, 외부 부수 효과로 표시하세요. 달라질 이유가 없는 모델 단계는 코드로 되돌립니다. 외부 효과에 명시적인 ID와 복구 경로가 없다면 프로덕션으로 진행하지 마세요.
아래 프롬프트는 애플리케이션을 리팩터링하지 않은 채 코딩 에이전트가 이 경계를 찾게 합니다.