AI 에이전트 프레임워크 선택: 기술의 탈을 쓴 비즈니스 결정
모델, 도구, 상태, 평가, 운영 책임을 기준으로 AI 에이전트 구현 방식을 선택하고 바꿀 수 있게 설계하는 방법입니다.
Summary
에이전트 프레임워크 선택은 라이브러리 선호보다 제품 운영 방식에 가까운 결정입니다. 사용자가 맡기는 일, 외부 도구의 위험, 상태 보관, 사람 검토, 평가와 장애 대응을 감당할 수 있어야 합니다.
OpenAI Agents SDK, Anthropic의 도구 사용 안내, LangGraph, Google ADK는 각각 다른 구현 방식을 제공합니다. 어느 하나가 모든 팀의 표준은 아닙니다. 중요한 것은 특정 공급자나 프레임워크를 바꿔도 제품의 핵심 계약과 평가 기준을 유지할 수 있는지입니다.
When to Use
- PoC를 실제 사용자 파일럿으로 옮기기 전에 구현 방식을 정할 때
- 여러 모델·검색·사내 도구를 하나의 작업 흐름으로 연결할 때
- 프레임워크를 도입했지만 관측성·재시도·권한 관리 책임이 불명확할 때
- 모델 또는 벤더 전환 가능성을 검토할 때
1. 데모보다 먼저 정할 제품 계약
프레임워크를 비교하기 전에 아래 항목을 문서로 합의합니다.
| 항목 | 확인할 질문 |
|---|---|
| 작업 경계 | 에이전트가 끝까지 처리할 일과 사람에게 넘길 일을 어떻게 나누는가 |
| 도구 권한 | 읽기, 쓰기, 승인, 취소를 어떤 수준으로 허용하는가 |
| 상태 | 대화·작업·도구 결과를 어디에 얼마나 보관하고, 다시 실행할 수 있는가 |
| 실패 | 시간 초과, 부분 성공, 중복 실행, 공급자 제한에 어떻게 대응하는가 |
| 평가 | 실제 작업을 대표하는 사례로 어떤 결과를 통과로 볼 것인가 |
| 책임 | 배포·비용·데이터·품질·장애를 누가 확인하고 되돌리는가 |
이 질문에 답하지 못하면 프레임워크를 바꿔도 같은 문제가 다시 생깁니다.
2. 비교 기준은 다섯 가지다
| 기준 | 확인 방법 | 피해야 할 신호 |
|---|---|---|
| 도구 호출 | 입력 검증, 권한, 승인, 오류 반환을 제품 코드에서 통제할 수 있는가 | 모델 출력만 믿고 쓰기 작업을 실행 |
| 상태와 재개 | 작업 ID, 단계, 중간 결과를 저장하고 중단 후 재개할 수 있는가 | 한 요청 안에 모든 상태를 숨김 |
| 관측성 | 모델·프롬프트·도구·데이터 버전과 실패 이유를 연결할 수 있는가 | 성공 로그만 남음 |
| 평가 | 변경 전후 같은 대표 사례를 자동·사람 검토로 비교할 수 있는가 | 데모가 잘 되면 출시 |
| 이식성 | 인터페이스와 테스트를 유지한 채 모델 또는 도구를 교체할 수 있는가 | 벤더 SDK 호출이 화면과 비즈니스 규칙에 흩어짐 |
“멀티 모델을 지원한다”는 말은 이식성을 보장하지 않습니다. 도구 스키마, 구조화 출력, 스트리밍 이벤트, 안전 정책, 비용·한도가 다르므로 실제 전환 테스트가 필요합니다.
3. 가장 작은 운영 가능한 구조로 시작한다
초기에는 다음 구조면 충분한 경우가 많습니다.
화면 또는 API
→ 작업 서비스
→ 모델 어댑터
→ 도구 어댑터
→ 상태 저장소와 감사 로그
→ 평가와 운영 대시보드- 화면은 작업 진행 상태와 사람 승인 요청을 보여 줍니다.
- 작업 서비스는 작업 ID, 재시도, 시간 제한, 취소를 책임집니다.
- 모델 어댑터는 공급자별 호출을 한곳에 모읍니다.
- 도구 어댑터는 입력 검증, 권한, 멱등성, 오류 처리를 통일합니다.
- 상태·로그에는 재현에 필요한 버전과 결과만 남깁니다.
프레임워크는 이 구조를 더 빠르게 구현하도록 돕는 수단입니다. 상태 머신, 멀티 에이전트 협업, 긴 작업 재개가 아직 필요 없다면 단순한 서비스 코드와 공급자 SDK가 더 적절할 수 있습니다.
4. 프레임워크별 검증 질문
| 선택지 | 적합할 수 있는 상황 | 도입 전 검증할 질문 |
|---|---|---|
| 공급자 SDK와 얇은 서비스 계층 | 단일 작업 흐름, 빠른 PoC, 직접 제어가 중요한 경우 | 재시도·상태·평가를 팀이 직접 운영할 준비가 되었는가 |
| 에이전트 SDK | 핸드오프, 도구 호출, 추적 같은 공통 개념이 필요한 경우 | 공급자 특화 기능과 제품 계약을 어떻게 분리할 것인가 |
| 그래프·워크플로우 프레임워크 | 분기, 승인, 재개, 장기 실행이 중요한 경우 | 상태 스키마와 버전 이전을 누가 관리하는가 |
| 멀티 에이전트 프레임워크 | 역할 분담이 실제 품질 또는 처리시간을 개선할 때 | 역할 추가가 평가 가능성과 장애 분석을 더 어렵게 하지 않는가 |
공식 시작 문서의 예제를 그대로 서비스 구조로 삼지 않습니다. 예제는 개념을 보이기 위해 단순화되어 있으므로 인증, 권한, 비용, 데이터 보존, 관측성을 따로 설계해야 합니다.
5. 공급자 한도와 가격은 설계 입력값이다
요금, 모델 제공 여부, 사용 한도, 티어 조건은 자주 변합니다. 특정 금액이나 분당 처리량을 문서에 고정하지 않고 아래 절차로 확인합니다.
- 출시할 계정과 조직에서 실제 모델·도구 접근 권한을 확인합니다.
- 해당 공급자의 공식 가격·사용 한도 페이지를 배포 당일 다시 확인합니다.
- 예상 피크 요청, 입력·출력 길이, 도구 호출, 재시도를 넣어 부하 시험을 합니다.
- 제한 또는 장애 때 큐, 재시도, 대체 경로, 사람 연결이 작동하는지 확인합니다.
- 한도 초과와 비용 급증을 감지할 지표와 담당자를 정합니다.
OpenAI와 Anthropic 모두 모델·계정별 사용 한도와 도구 조건을 공식 문서에서 제공하지만, 실제 값은 조직·모델·지역·계약에 따라 다를 수 있습니다. 제품 목표치는 그 문서와 자체 부하 시험 결과를 바탕으로 정합니다.
6. 의사결정 기록(ADR) 템플릿
| 항목 | 기록할 내용 |
|---|---|
| 결정 | 선택한 구현 방식과 적용 범위 |
| 작업 | 사용자가 맡기는 일, 성공 조건, 사람이 검토할 구간 |
| 대안 | 검토한 SDK·프레임워크와 제외 이유 |
| 제약 | 데이터, 보안, 지연 시간, 비용, 팀 역량 |
| 인터페이스 | 모델·도구·상태·이벤트의 교체 가능한 경계 |
| 검증 | 평가 사례, 부하 시험, 실패·복구 시험 결과 |
| 되돌리기 | 기능 플래그, 버전 고정, 데이터 이전, 중단 절차 |
| 재검토 | 다음 검토 시점과 변경을 촉발할 신호 |
7. 출시 전 체크리스트
- 실제 사용자 작업을 대표하는 평가 사례가 있다.
- 쓰기·결제·외부 전송 작업에는 승인 또는 명시적 권한 확인이 있다.
- 작업 ID와 상태가 있어 중단·재시도·중복 실행을 처리할 수 있다.
- 모델, 프롬프트, 도구, 데이터 버전을 실패 사례와 연결할 수 있다.
- 공급자 한도·가격·접근 권한을 현재 공식 문서와 실제 계정에서 확인했다.
- 모델 또는 도구를 하나 교체해도 핵심 평가가 유지되는지 시험했다.
- 되돌릴 수 있는 배포 방식과 운영 담당자가 정해져 있다.