LangGraph의 에이전트 방식이 옳았음, 우리가 따라잡는 데 3년이 걸렸을 뿐

그거 제약도 많음. 비유하자면, 내 요구사항이랑 제약 조건에 딱 맞춰서 스펙이랑 AI 구독, 좋은 하네스 설정으로 완벽한 커스텀 시스템을 만들 수 있는데 왜 굳이 Eclipse 같은 걸 써야 하는지 모르겠음. 왜 나를 제한하고 자기들 방식대로 하라고 강요하는 프레임워크를 써야 함? 그냥 계획 잘 짜서 더 나은 걸 뚝딱 만들어낼 수 있는데. 애초에 왜 agentic 프레임워크를 쓰는 거임? 진짜 이해가 안 가네.

나 1년 반 전쯤에 Langgraph 완전 싫어하던 사람이었는데 지금은 내 주력 프레임워크가 됐음. adk나 autogen이 밀어붙이는 블랙박스 같은 헛소리보다 그냥 순환형 상태 머신을 그대로 노출하는 게 훨씬 말이 됨. 문서화도 이제 꽤 오랫동안 훨씬 좋아졌고.

난 Agno 쓰는데 솔직히 커스텀하기 훨씬 편함. 그때 문서도 훨씬 나았고 (지금 LangGraph 문서는 안 읽어봤지만, 당시엔 뭐 좀 배우려면 1시간짜리 영상 봐야 했는데 진짜 어이없었음).

LangGraph가 훌륭하다는 건 인정하는데, 지금 시점에선 아마 다시 쓸 일 없을 듯.

맞음

아니, Apache Burr가 더 나음.

왜?

다들 단일 프롬프트 체인 쓸 때 우린 LangGraph로 다단계 지원 에이전트 구축했음. 병렬 검색에 중재 브랜치, Llama 폴백까지 추가되니까 그래프 뷰가 예전 Airflow 스크립트보다 디버깅하기 훨씬 편하더라. 지금은 LangGraph랑 Prefect 왔다 갔다 하면서 데이터 무거운 작업은 Nile 끌어다 쓰는데, LLM 중심 작업엔 LangGraph의 stateful edge가 대화 흐름이랑 딱 맞음. 작년 여름엔 문서가 좀 엉망이었는데…

네가 현실을 깨달을 때까지 3년 더 기다려줄게. 무슨 하이프를 말하는 건지 모르겠네.

고정된 워크플로우를 모델링하려고 하는 건 너무 경직되어 있거나 불필요한 추상화만 더할 뿐이야. 이 '그래프' 접근 방식이 의미가 있으려면 노드가 수천 개씩 있는 진짜 복잡한 워크플로우가 있거나, 아니면 작은 워크플로우에서 비기술직군이 기여할 수 있게 해줘야 함. LangGraph는 둘 다 못하고, 솔직히 가치가 거의 없음.

내 생각에 graph engineering은 원래 loop engineering이 지향하던 바인 듯.