언제 프레임워크로 넘어가야 하는가

여기까지 왔다면 직접 짠 루프로 도구 하나짜리 에이전트는 충분히 만들 수 있습니다. 그런데 실무에서는 도구가 열 개, 스무 개로 늘고, 에이전트가 다른 에이전트를 호출해야 하는 순간이 옵니다. 그때 LangGraph, CrewAI, AutoGen 같은 프레임워크를 붙일지 말지 고민하게 됩니다. 이 장은 그 판단 기준에 관한 이야기입니다.

프레임워크가 실제로 대신해 주는 것

프레임워크가 주는 건 크게 세 가지입니다. 첫째, 5장에서 직접 짠 루프 같은 걸 반복 짜지 않도록 감싸주는 실행기. 둘째, 에이전트 여러 개를 조율하는 오케스트레이션(누가 먼저 실행되고, 결과를 누구에게 넘기는지). 셋째, 상태를 그래프나 상태 머신으로 표현해서 복잡한 분기를 관리하는 도구.

# LangGraph 스타일 의사코드 — 실제 API는 버전마다 다르다
graph = StateGraph(AgentState)
graph.add_node("researcher", researcher_agent)
graph.add_node("writer", writer_agent)
graph.add_edge("researcher", "writer")
graph.set_entry_point("researcher")
app = graph.compile()

에이전트가 하나고 도구가 대여섯 개인 수준이라면, 이 이점은 대부분 필요 없습니다. 5장의 while 루프로 충분하고, 오히려 프레임워크가 강요하는 추상화(노드, 엣지, 상태 스키마)를 배우는 비용이 더 큽니다.

신호: 이럴 때 넘어갈 만하다

넘어갈 신호는 코드량이 아니라 구조의 복잡도입니다. 제가 실제로 판단 기준으로 쓰는 건 이렇습니다.

• 에이전트가 서로 다른 역할(리서치, 작성, 검증)로 나뉘고, 각자 독립된 컨텍스트와 도구 세트를 가져야 한다.
• 한 에이전트의 출력이 다른 에이전트의 입력이 되는 파이프라인이 두 단계를 넘어간다.
• 실행 상태를 중간에 저장했다가 나중에 재개해야 한다(사람 승인을 기다리는 human-in-the-loop 같은 경우).

반대로 이런 이유로는 넘어가지 마세요. "다들 쓰니까", "나중에 복잡해질 수도 있으니 미리", "직접 짜는 게 왠지 아마추어 같아서". 세 번째가 특히 흔한 착각인데, 제가 본 프로덕션 사고의 상당수는 팀이 프레임워크 내부 동작을 완전히 이해하지 못한 채 커스터마이징하려다 생긴 것들이었습니다. 5장의 루프를 직접 짜 봤다면 최소한 프레임워크가 뭘 대신해 주는지는 정확히 압니다.

프레임워크를 붙여도 바뀌지 않는 것

프레임워크를 쓰든 안 쓰든, 3장의 Tool Use 계약(스키마와 tool_use_id 매칭), 6장의 ReAct 원리, 8장의 실패 패턴은 그대로 적용됩니다. 프레임워크는 이걸 대신 처리해 주는 게 아니라 감싸서 보여줄 뿐입니다. 그래서 프레임워크의 로그에서 이상 동작이 보일 때, 결국 원인을 추적하려면 그 아래 있는 순수 API 호출과 메시지 배열을 들여다봐야 하는 경우가 많습니다. 프레임워크 문서만 읽고 이 책의 앞 장들을 건너뛰면, 딱 이 지점에서 막힙니다.

제 개인적인 기준

저는 팀 프로젝트에서는 도구가 셋을 넘고 역할 분리가 필요해지는 시점부터 프레임워크를 검토합니다. 개인 프로젝트나 프로토타입 단계에서는 거의 항상 직접 짠 루프로 끝까지 갑니다 — 어차피 요구사항이 어떻게 바뀔지 이 시점에서는 아무도 모르고, 프레임워크의 추상화가 그 불확실한 방향과 맞을지도 알 수 없기 때문입니다. 이건 정답이라기보다 제 경험에서 나온 기준이니, 팀 사정에 따라 얼마든지 다를 수 있습니다.