LangGraph vs CrewAI, 멀티 에이전트 프레임워크 실무 선택 기준
조사와 작성과 검증. 세 단계를 에이전트 셋에게 나눠 맡겼더니 첫날 막힌 건 두 번째 에이전트가 첫 결과를 어떻게 받느냐였어요. LangGraph와 CrewAI는 이 지점에서 갈립니다. 상태를 개발자가 설계하게 하느냐, 역할과 목표만 적으면 프레임워크가 알아서 넘기느냐.
먼저 답을 놓고 갈게요. 검증과 재시도와 중단이 섞인 업무 자동화라면 LangGraph, 사람 조직도를 그대로 옮긴 초안 생산 라인이라면 CrewAI입니다. 팀이 2명 이하라면 CrewAI 쪽이 덜 아파요.
어떤 기준으로 둘을 갈랐나
제 환경부터 밝힐게요. 한국어 블로그 자동발행 파이프라인을 프레임워크 없이 직접 짜서 매일 돌립니다. 수집 3채널이 물어 온 주제가 작가 3명을 거쳐 결정론 게이트 16종을 지나 발행돼요.
그래서 기준을 셋으로 좁혔어요. 상태관리는 단계 사이 데이터의 모양을 누가 정하는가, 디버깅은 열두 번째 단계가 틀렸을 때 세 번째로 되감을 수 있는가, 러닝커브는 새 팀원이 에이전트 흐름을 이해하는 데 며칠이 걸리는가.
속도와 토큰 비용은 뺐어요. 같은 모델을 호출하니 프레임워크보다 프롬프트 설계가 차이를 만듭니다.
조사부터 검증까지, 두 프레임워크는 어디서 갈라지나요?
같은 과제를 두 프레임워크로 짜봤어요. 주제 하나를 받아 자료를 모으고 초안을 쓰고 검증까지 가는 흐름입니다.
CrewAI는 배역부터 적습니다. 조사원과 작가와 검수자에게 목표를 붙이고 작업 세 개를 순서대로 늘어놓으면, 앞 작업의 산출물이 다음 에이전트의 맥락으로 따라 들어가요. 제가 직접 짠 프로토타입이 처음 끝까지 돌아가는 데는 40분 남짓 걸렸습니다.
기대와 달랐던 건 검수자가 반려를 낸 다음이었어요. 작가 에이전트를 다시 부르고 싶은데 순차 흐름에는 되감기를 놓을 자리가 없더군요. 조건 분기를 넣으려면 크루 바깥에 파이썬 제어문을 쌓게 되고, 그 순간 조직도처럼 읽히던 프레임워크의 장점이 흐려집니다.
LangGraph는 순서가 반대예요. 상태의 모양부터 정의합니다. 주제와 수집자료와 초안과 검증결과 칸을 만들면 노드가 그 칸을 채우죠. 검증 노드 뒤에 조건 엣지를 달아 통과면 종료, 실패면 작가 노드로 돌아가게 그렸어요. 재시도 상한도 상태의 숫자 칸 하나로 관리했습니다.
대신 첫 실행까지 오래 걸렸어요. 상태 칸을 세 번 갈아엎었거든요. 초안을 문자열 하나로 뒀더니 검증자가 어느 문단이 문제인지 돌려줄 자리가 없더군요. 이 설계 비용은 다단계 자동화의 본질이라, CrewAI로 시작하면 나중에 몰아서 치릅니다.
디버깅이 막혔을 때 어느 쪽이 빨리 풀릴까요?
멀티 에이전트 자동화에서 제일 비싼 시간은 실행 시간이 아니라 왜 이렇게 나왔는지 모르는 시간입니다.
LangGraph는 체크포인트를 전면에 둡니다. 단계마다 상태를 저장해 두니 실패 지점부터 다시 돌릴 수 있고, 사람이 중간에 값을 고쳐 이어가는 흐름도 구조 안에 있어요. 승인이 낀 사내 업무 자동화라면 이 하나로 선택이 갈립니다.
CrewAI에서 겪은 막힘은 종류가 달랐어요. 로그는 친절한데, 세 번째 에이전트가 왜 저 문장을 근거로 삼았는지 되짚으려면 프롬프트에 무엇이 실려 갔는지부터 파야 했습니다. 편리함과 답답함이 한 몸이더라고요.
품질 판정을 LLM에게만 맡겼다가 같은 입력에 다른 결론이 나오는 걸 겪고, 차단 권한을 결정론 게이트 16종으로 옮겼습니다. 어느 프레임워크를 고르든 이 분리가 없으면 회귀 추적이 막힙니다.
프레임워크가 대신 해주지 않는 세 가지
둘 중 무엇을 골라도 제가 정해야 하는 몫이 남아요.
첫째는 재시도 상한. 저희는 단계마다 최대 3회, 그 뒤엔 건너뛰기입니다. 이게 없으면 실패한 에이전트끼리 서로를 부르며 돌아요.
둘째는 병렬 범위예요. 저희는 수집 3채널과 검증자 4명처럼 독립인 단계에만 걸었습니다. 상태를 공유하는 단계를 겹쳐 돌리면 산출물이 덮어써져 자동화 디버깅이 막혀요. LangGraph는 병렬이 그래프에 보이지만 CrewAI는 옵션 한 줄로 켜집니다.
셋째는 실패를 어디에 남기느냐. 어제와 오늘의 판정이 왜 갈렸는지는 프레임워크가 기록해주지 않아 저희는 감사 로그를 따로 쌓았습니다.
저는 어디서 갈라졌나
CrewAI 구성을 접은 계기는 반려 처리였어요. 작가 에이전트를 다시 부르는 경로를 그리려다 프레임워크 바깥에 제어문을 쌓고 있더군요. 그때 기준이 섰어요. 흐름이 한 방향이면 역할 기반이 이기고, 되돌아오는 화살표가 하나라도 있으면 그래프 기반이 이깁니다.
그래서 지금은 이렇게 나눕니다. 리서치 요약처럼 한 번 흘러가고 끝나는 자동화라면 CrewAI로 이번 주에 띄우세요. 승인과 반려와 재시도가 섞이면 LangGraph 설계 비용을 초반에 치르는 편이 쌉니다. 단계가 3개 이하이고 분기가 없다면 둘 다 권하지 않아요. 저희 파이프라인 초기가 그랬어요. 함수 몇 개면 됐습니다.
정리
갈림길은 되돌아오는 화살표의 유무예요. 저는 프레임워크를 고르기 전에 상태의 모양을 종이에 그려봅니다. 어떤 칸이 필요하고 누가 고치는지 다섯 줄로 못 적으면, 어떤 도구를 얹어도 두 달 뒤 같은 자리에서 막히더라고요.
두 프레임워크 모두 변화가 빠릅니다. 옵션 이름과 API 세부는 공식 문서에서 확인해 주세요.
자주 묻는 질문
Q. 두 프레임워크를 한 프로젝트에 섞어 써도 되나요?
A. 됩니다. 그래프 노드 하나 안에서 역할 기반 크루를 실행하는 식이죠. 재시도 상한은 바깥 그래프 한 곳에만 두세요.
Q. 러닝커브 차이는 며칠쯤인가요?
A. 제 경우 새 팀원이 합류해 혼자 수정할 수 있게 되기까지 역할 기반은 반나절, 그래프 기반은 이틀쯤 걸렸어요. 두 달째 유지보수 시간은 반대로 뒤집혔습니다.
Q. 에이전트를 몇 개까지 늘리는 게 현실적인가요?
A. LLM 에이전트가 5개를 넘어가면 각자의 실패 모드를 사람이 기억하지 못해요. 늘리기 전에 로그 포맷부터 통일하는 편을 권합니다.