에이전트 프레임워크

AI 에이전트를 만들 때마다 반복되는 상태 관리, 도구 연동, 여러 에이전트의 협업 같은 뼈대 코드를 미리 제공하는 도구로, 흐름이 복잡하거나 오래 도는 에이전트를 만들 때 쓴다. 인프라 코드를 직접 짜지 않고 역할과 흐름 설계에 집중할 수 있으며, 프레임워크마다 흐름을 표현하는 방식이 달라 만들 에이전트의 모양에 맞춰 고르면 된다.

직접 짜면 인프라 코드가 대부분

에이전트를 처음부터 만들면 비즈니스 로직보다 상태 관리, 에러 처리, 도구 호출 라우팅 같은 인프라 코드가 훨씬 많아진다. 모델이 도구를 부르면 실행하고 결과를 다시 넣는 루프, 실패 시 재시도, 중간 상태 저장을 매번 새로 짜야 한다.

프레임워크는 이 부분을 미리 만들어 둔다. 오래 도는 에이전트는 멈췄다가 이어서 실행하거나 사람이 승인한 뒤 다음 단계로 넘어가는 기능이 필요한데, LangGraph처럼 이를 기본으로 지원하는 프레임워크가 많다.

만드는 순서는 비슷하다

어떤 프레임워크를 고르든 대체로 아래 순서로 만든다.

처음엔 에이전트 하나와 도구 몇 개로 시작하고, 역할이 확실히 나뉠 때만 멀티에이전트로 늘리는 편이 디버깅하기 쉽다.

빠르게는 CrewAI, 세밀하게는 LangGraph

CrewAI는 "리서처", "라이터", "에디터" 같은 역할만 정의하면 협업 구조를 알아서 잡아 줘서 아이디어를 빨리 확인할 때 좋다. 실제 서비스에서 분기·재시도·사람 승인까지 통제해야 하면 LangGraph로 옮기는 팀이 많다. Claude Agent SDK는 Claude Code를 움직이는 기반을 그대로 가져다 쓰는 형태라, Claude로 코드나 파일을 다루는 에이전트라면 가장 빠른 출발점이다.

단순한 일엔 오히려 짐이 된다

도구 한두 개를 부르는 정도라면 모델 API의 도구 호출 기능만으로 충분하다. 프레임워크를 얹으면 추상화 층이 늘어 에러 위치를 찾기 어려워지고, 프레임워크 업데이트에 맞춰 코드를 고쳐야 하는 부담도 생긴다. 흐름이 복잡해지거나 상태 저장이 필요해질 때 도입해도 늦지 않다.

여러 단계를 거치는 자동화에 주로 쓴다

가장 흔한 건 검색·실행·검토가 여러 번 오가는 작업을 맡기는 방식이다. 한 번 묻고 끝나는 챗봇보다는, 도구를 여러 번 부르고 중간 결과에 따라 다음 단계가 바뀌는 일에 쓰인다.