LangGraph와 AGENTS 기반 CLI를 어떻게 나눠서 볼까

AI를 실제 개발 업무에 넣는 방식은 크게 두 갈래로 나뉜다고 봅니다.
하나는 프로젝트 안에 AGENTS.md, .workflow, SKILL.md 같은 규칙 문서를 잘 깔아두고, Codex CLI나 Claude Code 같은 구독형 에이전트를 직접 붙잡고 쓰는 방식입니다.
다른 하나는 LangGraph 같은 오케스트레이션 프레임워크로 계획, 구현, 검증, 승인 같은 절차를 그래프로 고정해서 시스템처럼 굴리는 방식입니다.

둘 중 하나가 무조건 더 낫다고 말하기는 좀 어렵습니다..
결국 누가 쓰는지, 얼마나 반복적으로 쓰는지, 절차를 어느 정도까지 강제해야 하는지에 따라 달라집니다.

LangGraph 쪽은 뭘 하려는 건가요?

예제로 보면 보통 이런 구조를 잡습니다.

• main graph가 큰 stage를 조립
• 복잡한 부분만 subgraph로 분리
• planning graph에서 계획 초안과 검증 체크리스트 생성
• implementation graph에서 실제 수정
• validation graph에서 check, build, biome 같은 실행 검증
• 실패하면 repair loop로 다시 복구

이 흐름의 좋은 점은 절차가 문서가 아니라 실행 구조가 된다는 겁니다.
계획을 세우고, review를 거치고, validation에 실패하면 다시 repair로 돌아가는 걸 시스템이 직접 강제할 수 있습니다.

AGENTS 기반 CLI 방식의 장점

이쪽의 가장 큰 장점은 빠르고 싸다는 겁니다.
이미 강한 모델을 구독하고 있다면, 오케스트레이션 시스템을 따로 만들지 않아도 프로젝트 규칙 문서만 잘 정리해두는 걸로 꽤 높은 품질이 나옵니다.

특히 이런 상황에서는 꽤 강합니다.

• 빠른 실험
• 작은 범위 수정
• 탐색적 리팩터링
• 문제 정의가 계속 바뀌는 작업

사람이 중간에 바로 개입해서 방향을 틀 수 있고, AI도 그 문맥에 맞춰 유연하게 움직일 수 있습니다.
이 유연성은 생각보다 큽니다.

AGENTS 기반 CLI 방식의 한계

반대로 약점도 분명합니다.
절차가 문서로만 존재합니다.

planning -> review -> validation을 아무리 잘 적어둬도, 모델이 항상 그 순서를 똑같이 지킨다고 보장할 수는 없습니다. 어떤 날은 계획이 약하고, 어떤 날은 검증이 부족하고, 어떤 날은 review를 건너뛴 것처럼 보이는 응답이 나옵니다.

그리고 편차가 큽니다.
잘 쓰는 사람은 잘 쓰고, 못 쓰는 사람은 같은 도구를 써도 품질이 잘 안 나옵니다. 팀 공용 표준을 만들기엔 이 부분이 꽤 큽니다.

LangGraph 방식의 장점

LangGraph의 가장 큰 장점은 절차를 실행 구조로 고정할 수 있다는 점입니다.

• 수정 전에 승인 넣기
• review 실패 시 재구현 루프 돌리기
• validation 실패 시 repair 후 재검증하기
• 사람이 개입해야 하는 시점에서 interrupt 걸기

이런 걸 문서가 아니라 시스템으로 강제할 수 있습니다.

그래서 여러 사람이 비슷한 방식으로 써야 하거나, 공용 시스템으로 운영해야 하거나, retry와 approval을 무적권 지키게 해야 하는 상황에선 가치가 확실히 생깁니다.

또 하나는 관찰 가능성입니다.
중간에 무슨 계획이 나왔는지, 어디서 실패했는지, 어떤 review finding이 있었는지 상태를 시스템이 들고 다니기 때문에 운영과 개선이 더 쉬워집니다.

LangGraph 방식의 한계

좋은 graph를 만든다는 건 생각보다 귀찮습니다..
그냥 노드 몇 개 잇는다고 끝나는 게 아니라,

• 어떤 상태를 남길지
• 어느 단계까지 분리할지
• 사람 개입은 어디 넣을지
• 실패 시 어디로 복구할지

이걸 다 설계해야 합니다.

잘 만들면 강력하지만, 잘못 만들면 과한 추상화와 유지보수 비용만 늘어납니다.
그리고 유연성은 분명히 줄어듭니다. 사람이 붙어서 탐색적으로 일하는 상황에서는 오히려 CLI 에이전트가 더 자연스럽게 느껴질 수 있습니다.

비용도 생각해야 합니다.
LangGraph는 보통 API 호출 기반이라서, planning, review, repair, validation이 다 쪼개질수록 호출 수가 금방 늘어납니다.

결국 뭐가 맞는가

저는 둘을 이렇게 봅니다.

• AGENTS 기반 CLI는 설명된 절차
• LangGraph는 실행되는 절차

문서에 절차를 적어두는 것만으로 충분한 상황도 많습니다.
근데 그 절차를 항상 같은 순서로 지키게 해야 한다면, 그때부터는 LangGraph가 필요해집니다.

질문은 AGENTS가 있으면 LangGraph가 왜 필요하지?가 아닙니다.
이 절차를 문서로만 관리해도 충분한가, 아니면 시스템으로 강제해야 하는가 쪽이 더 맞습니다.

현실적인 결론

실무적으로는 둘 중 하나만 고집하는 것보다 섞는 게 제일 현실적입니다.

초기에는:

• AGENTS.md
• .workflow
• skill

이런 문서로 규칙을 잡고, 빠른 실험은 CLI 에이전트로 합니다.

그다음 반복적으로 돌아가야 하는 부분만 LangGraph로 올리는 겁니다.

• 승인 절차
• 재시도 루프
• repair loop
• validation loop

이런 것들입니다.

결국 문서는 규칙의 출처로 남고, 그래프는 그 규칙을 실행 경로로 바꾸는 역할을 맡는 셈입니다.
이 두 층을 분리해서 운영할 수 있으면, 단일 CLI보다 더 안정적인 팀 공용 시스템을 만들 수 있습니다.