CI/CD

인공지능 에이전트 개발 프레임워크 선택법

게시일 2026년 08월 17일

Kvmjet · 약 12분 읽기

인공지능 에이전트 개발 프레임워크 선택법은 업무의 결정성, 상태 복잡도, 권한 요구를 먼저 확인한 뒤 결정해야 합니다. 단순 호출이나 정해진 작업 흐름이면 가벼운 개발 도구를 선택하고, 중단·재개·승인·복구가 필요할 때만 작업 흐름 프레임워크를 검토하세요.

이 글은 새 에이전트 프로젝트를 고르는 개발자와 기술 책임자를 위한 내용입니다. 개념 증명을 운영 환경으로 옮기려는 팀, 프레임워크가 너무 무거워졌거나 도구 호출 오류로 다시 개발한 팀에도 적합합니다.

프레임워크가 정말 필요한 업무인지 먼저 구분해야 합니다

인공지능 에이전트 프로젝트에 프레임워크가 필요한지는 모델의 성능보다 업무 흐름으로 판단해야 합니다.

다음과 같은 작업은 일반 함수나 결정성 있는 코드로 충분합니다.

입력 형식이 일정하고 결과 형식도 고정된 작업
외부 도구를 한 번만 호출하는 질의
실패하면 전체 작업을 다시 실행해도 되는 배치
승인이나 장기 상태가 필요 없는 요약, 분류, 변환 작업

반대로 다음 조건이 있으면 에이전트 실행 환경이 유용해집니다.

모델이 여러 도구 중 하나를 선택해야 합니다.
작업이 여러 단계로 나뉘고 중간 결과를 보존해야 합니다.
사용자의 승인 후 결제, 삭제, 배포 같은 작업을 실행합니다.
실패한 단계부터 다시 시작해야 합니다.
여러 전문 에이전트가 역할을 나눠야 합니다.

OpenAI의 공식 개발 도구도 단순한 모델 호출과 실행 흐름, 도구 실행, 세션 관리를 구분합니다. 짧은 응답 중심이라면 직접 실행 흐름을 관리할 수 있지만, 도구와 세션을 런타임에서 관리해야 한다면 상위 실행 도구가 적합하다고 설명합니다. 공식 실행 구조 안내를 기준으로 첫 분류를 진행할 수 있습니다.

가벼운 개발 도구와 작업 흐름 프레임워크는 어떻게 나눌까요?

가벼운 에이전트 개발 도구는 코드 중심으로 빠르게 시작하기 좋습니다. 팀이 이미 사용하는 언어와 테스트 체계를 그대로 유지할 수 있다는 점이 장점입니다.

가벼운 개발 도구가 맞는 경우

에이전트 수가 적습니다.
상태를 데이터베이스나 애플리케이션 코드에서 직접 관리할 수 있습니다.
도구 호출 순서가 짧습니다.
모델이나 공급자를 바꿀 가능성이 큽니다.
디버깅을 일반 코드 추적 방식으로 처리하고 싶습니다.

단점도 분명합니다. 재시도, 중복 실행 방지, 체크포인트, 작업 큐를 직접 설계해야 합니다. 처음에는 코드가 짧아 보여도 운영 단계에서 주변 코드가 빠르게 늘어날 수 있습니다.

작업 흐름 프레임워크가 맞는 경우

여러 단계의 실행 순서를 명확히 표현해야 합니다.
중간 상태를 저장하고 나중에 재개해야 합니다.
사람의 승인이나 외부 이벤트를 기다려야 합니다.
단계별 관찰과 재실행이 중요합니다.

LangGraph 공식 문서는 중단이 발생하면 그래프 상태를 저장하고 외부 입력을 기다린 뒤 실행을 재개할 수 있다고 설명합니다. 운영 환경에서는 지속 가능한 체크포인터를 사용해야 한다는 점도 명시합니다. 중단과 상태 저장 안내를 검토하면 작업 흐름 프레임워크의 필요성을 구체적으로 판단할 수 있습니다.

주의: 작업 흐름 프레임워크를 선택해도 실패 복구 정책이 자동으로 완성되는 것은 아닙니다. 어떤 상태를 저장하고, 어느 단계부터 재개하며, 재실행할 수 없는 도구를 어떻게 보호할지 별도로 정의해야 합니다.

결정성 있는 단계와 자유로운 모델 판단이 섞인 프로젝트라면 전부를 자율 에이전트로 만들지 마세요. 파일 검증, 권한 확인, 금액 계산처럼 오류 비용이 큰 부분은 일반 코드로 고정하고 모델은 판단이 필요한 구간에만 배치하는 편이 안전합니다.

도구 호출은 연결 개수보다 통제 수준을 봐야 합니다

도구 호출이 많다고 좋은 에이전트가 되는 것은 아닙니다. 도구가 늘면 모델이 잘못된 도구를 선택할 가능성, 잘못된 인자를 전달할 가능성, 같은 작업을 반복할 가능성이 함께 커집니다.

선택할 프레임워크에서 다음 항목을 확인하세요.

인자 형식을 강제하는 스키마가 있는가
호출 시간 제한과 재시도 횟수를 설정할 수 있는가
실행 전 권한 승인이나 사람의 확인을 넣을 수 있는가
같은 요청이 반복되어도 결과가 중복 처리되지 않는가
도구 입력과 출력이 별도 로그로 남는가
오류를 모델에게 다시 넘길지 즉시 중단할지 정할 수 있는가

OpenAI 공식 문서는 함수 도구에 자동 인자 스키마와 검증을 적용할 수 있고, 도구별 시간 제한과 오류 처리를 설정할 수 있다고 안내합니다. 또한 도구는 호스팅 도구, 로컬 실행 도구, 함수 호출, 에이전트 호출, 실험적 도구의 5가지 범주로 나뉩니다. 도구 종류와 검증 안내를 비교 기준으로 활용할 수 있습니다.

입력과 출력만 검사하는 구조도 부족할 수 있습니다. 공식 가이드에는 입력 검사와 출력 검사가 각각 존재하며, 여러 에이전트가 도구를 호출하는 흐름에서는 도구 호출마다 검사를 적용해야 한다고 설명합니다. 보호 장치 안내를 확인해 권한 경계를 설계하세요.

현장 사례: 고객지원 에이전트

고객지원 에이전트가 주문 조회, 환불, 계정 잠금 해제를 모두 호출한다고 가정하겠습니다. 단순 개발 도구는 연결 자체를 빠르게 만들 수 있지만, 환불에는 승인 단계와 중복 실행 방지가 필요합니다.

이 경우에는 다음처럼 분리하는 편이 좋습니다.

주문 조회: 자동 실행
환불 가능 여부 확인: 결정성 코드로 검증
환불 실행: 사람 승인 후 실행
처리 결과 기록: 고정된 형식으로 저장
실패 시 재시도: 같은 요청 번호로 멱등성 확인

도구 수보다 중요한 것은 어떤 도구가 어떤 조건에서 실행되는지 설명할 수 있는가입니다.

확장 기능이 실제로 열려 있는지 확인해야 합니다

프레임워크 설명에 확장 가능하다는 문구가 있어도 실제로는 핵심 코드를 수정해야 하는 경우가 있습니다. 다음 네 가지 경계를 문서와 최소 실험으로 확인하세요.

모델 교체

현재 모델의 호출 형식에 강하게 묶여 있지 않은지 확인합니다. 모델 교체가 설정 한 줄로 가능한지, 메시지 형식과 도구 결과 변환 코드를 다시 작성해야 하는지 구분해야 합니다.

저장소 교체

메모리 저장소에서 운영용 데이터베이스로 바꿀 수 있어야 합니다. 저장소 인터페이스가 공개되어 있는지, 체크포인트 형식이 문서화되어 있는지 확인하세요.

작업 흐름 조합

한 작업 흐름을 다른 흐름의 단계로 넣을 수 있어야 합니다. 조합이 불가능하면 프로젝트가 커질수록 복사 코드가 늘어납니다.

중간 처리 장치

인증, 감사 로그, 속도 제한, 마스킹을 공통으로 넣을 수 있는지 살펴보세요. 확장 지점이 없다면 결국 프레임워크 내부를 수정하게 됩니다.

OpenAI의 다중 에이전트 안내는 전문 에이전트를 도구처럼 호출하는 방식과 작업을 다른 에이전트로 넘기는 방식을 구분합니다. 전자는 관리자가 최종 대화를 통제할 때, 후자는 전문 에이전트가 직접 이어받아야 할 때 적합합니다. 다중 에이전트 조합 안내를 통해 필요한 조합 형태를 먼저 정하세요.

다중 에이전트는 언제 도입할 가치가 있을까요?

다중 에이전트 프레임워크는 팀 간 협업, 역할 분리, 독립적인 전문 지식이 실제로 필요할 때 선택해야 합니다. 단일 에이전트가 도구와 지침을 충분히 최적화하지 않은 상태에서 다중 구조로 이동하면 원인 추적이 어려워집니다.

AutoGen 공식 문서도 단순한 작업은 단일 에이전트로 시작하고, 단일 에이전트로 해결되지 않을 때 팀 구조로 옮기라고 안내합니다. 다중 구조는 조정 장치가 더 필요하므로 단순한 업무보다 높은 관리 비용을 감수해야 합니다. 팀 구조 선택 안내를 참고하세요.

다중 구조를 검토할 조건은 다음과 같습니다.

역할별 지침과 권한이 명확히 다릅니다.
각 역할의 결과를 독립적으로 평가할 수 있습니다.
한 에이전트가 모든 도구를 보는 것이 보안상 부적절합니다.
병렬 처리나 전문 역할 간 검토가 실제 병목을 줄입니다.
단일 에이전트의 도구 선택 실패를 수정해도 요구 수준에 미치지 못합니다.

그 외에는 단일 에이전트와 작업 흐름 조합부터 시작하세요. 에이전트 수가 늘어날수록 문맥 전달, 종료 조건, 비용 추적, 오류 귀속이 함께 복잡해집니다.

운영 배포 전에 검증할 항목은 무엇일까요?

개념 증명이 성공했다는 이유만으로 장기 실행 환경에 배포해서는 안 됩니다. 다음 순서로 최소 실패 작업을 만들어 검증하세요.

정상 작업을 고정합니다. 입력, 예상 도구, 정상 결과를 기록합니다.
도구 시간 초과를 재현합니다. 호출이 멈췄을 때 재시도되는지 확인합니다.
중복 실행을 시험합니다. 같은 요청을 두 번 보내도 결제, 삭제, 등록이 한 번만 처리되는지 봅니다.
중간 중단을 넣습니다. 승인 직전과 도구 실행 직후에 프로세스를 종료합니다.
상태 복구를 확인합니다. 처음부터 다시 실행하지 않고 저장된 단계에서 이어지는지 확인합니다.
권한을 분리합니다. 조회 도구와 변경 도구를 다른 계정 또는 다른 승인 경로로 나눕니다.
관찰 기록을 점검합니다. 모델 판단, 도구 인자, 결과, 오류, 재시도 횟수를 추적합니다.
사람의 인계 경로를 시험합니다. 자동 처리가 불가능할 때 담당자가 작업을 이어받을 수 있어야 합니다.

배포 전 선택 점검표

[ ] 업무가 일반 함수가 아닌 에이전트 판단을 실제로 요구하는지 확인했습니다.
[ ] 상태 저장 위치와 보존 기간을 정했습니다.
[ ] 도구마다 시간 제한, 재시도, 멱등성 정책을 정했습니다.
[ ] 민감한 도구에 승인 단계를 넣었습니다.
[ ] 모델 교체와 저장소 교체를 최소 실험으로 확인했습니다.
[ ] 실패한 작업을 특정 단계부터 재개했습니다.
[ ] 단일 에이전트로 해결 가능한지 먼저 검증했습니다.
[ ] 최종 후보를 2개 이하로 줄였습니다.
[ ] 두 후보에 같은 실패 시나리오를 적용했습니다.

운영 환경의 실행 조건도 함께 확인해야 합니다. 장시간 작업은 접속을 끊어도 계속 실행되어야 하고, 인증서와 비밀 값은 원격 환경에 남는 범위를 관리해야 합니다. 인프라 구성 안내와 원격 환경 도움말을 참고하면 원격 개발 환경에서 접속, 지속 실행, 백업 범위를 점검하는 데 도움이 됩니다.

최종 선택은 세 가지 조건으로 좁히면 됩니다

업무가 짧고 결정성 있으면: 가벼운 에이전트 개발 도구를 선택합니다.
상태 저장과 중단·재개가 필요하면: 작업 흐름 프레임워크를 선택합니다.
역할 분리와 독립 권한이 필요하고 단일 구조가 한계에 도달하면: 다중 에이전트 프레임워크를 선택합니다.

생산 환경 배포가 목표라면 기능 목록보다 추적, 복구, 권한 경계를 먼저 보세요. 프레임워크 이름이나 인기 순위는 팀의 운영 조건을 대신 판단해 주지 않습니다.

현재 개발 환경이 개인 컴퓨터나 공유 가상 서버라면 장시간 실행, 고정된 접속 경로, 자원 경쟁이 문제로 남을 수 있습니다. 특히 도구 호출 테스트와 상태 복구 실험을 동시에 진행할 때는 환경이 자주 바뀌고, 작업이 중단되며, 로그 보존 위치도 분산되기 쉽습니다.

이런 검증을 짧게 진행하려면 Kvmjet의 Mac 클라우드 요금과 대여 주기를 확인해 보세요. 해당 안내에는 원격 접속과 지속 실행을 고려한 이용 방식이 설명되어 있습니다. 장기 고정 부하에는 직접 구매가 더 적합할 수 있지만, 에이전트 프레임워크의 실패 복구와 권한 격리를 시험하는 단계라면 필요한 기간만 Mac 환경을 확보하는 편이 운영 판단을 빠르게 만들 수 있습니다.