# 왜 LangGraph 도입 후 코드가 더 복잡해졌나 — 실패에서 배운 기록

> Clean Markdown view of GeekNews topic #31628. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31628](https://news.hada.io/topic?id=31628)
- GeekNews Markdown: [https://news.hada.io/topic/31628.md](https://news.hada.io/topic/31628.md)
- Type: news
- Author: [neocode24](https://news.hada.io/@neocode24)
- Published: 2026-07-21T06:01:42+09:00
- Updated: 2026-07-21T06:01:42+09:00
- Original source: [neocode24.com](https://neocode24.com/blog/langgraph-spaghetti-lessons-from-failure)
- Points: 3
- Comments: 2

## Topic Body

"상태 관리와 흐름 제어가 깔끔해지겠지"라는 기대로 LangGraph를 도입했는데, 오히려 코드가 복잡해졌습니다.  
 프레임워크를 도입하고도 구조가 나빠질 수 있다는 걸 직접 겪고 정리한 경험에 대한 기록과 공유입니다.  
  
 진단해보니 상태는 이러했는데  
  
- 그래프에 노드가 하나뿐. current_step → END 구조라 조건부 엣지도 분기도 없었고, graph.invoke()가 함수를 직접 호출하는 것과 똑같음. Step 전환은 그래프 밖 서비스 코드가 판단하는 형태.  
- 같은 상태를 두 곳에 저장. LangGraph MemorySaver(인메모리)와 자체 PostgreSQL Checkpointer가 동일 세션을 이중으로 저장·복원하면서 불일치 발생.  
- 8,700여 줄 정도의 3개 LangGraph 실행 코드 (Executor)에 중복. 실질 핵심 로직은 "LLM 호출 + 프롬프트 조립" 정도였고, 나머지 대부분은 상태 관리·조건 분기·에지케이스 패치.  
  
 표면적으로는 프레임워크의 실제 기능(조건부 엣지, 내장 체크포인터, Human-in-the-Loop)을 쓰지 않고 껍데기로만 도입한 게 문제였는데, 더 파고들었더니 원인은 따로 있었습니다.  
  
- 대부분 바이브 코딩으로 만들어졌지만, 제작 과정중에 내부 코드나 설계 원칙을 깊이 들여다보지 않고, 매번 요구사항과 의도만 정리해 구현을 이어간 방식.  
- 문제는 바이브 코딩 자체가 아니라 검증 없는 진행이었음. 눈앞의 기능을 최적화할 뿐 전체 구조의 책임 경계는 지켜주지 않음. 이중 체크포인팅도, 흩어진 상태도, 중복된 로직도 전부 부분 최적화의 누적.  
- 설계자가 없었던 게 아니라, 프레임워크가 무엇을 책임지도록 설계됐는지 충분히 이해하지 못한 채 그 위에서 지시만 내린 상태가 진짜 원인.  
  
그래서 반성하고, 이렇게 되돌렸습니다.  
  
- 독립 토폴로지 + thread_id 격리로 세션 분리  
- State에는 메타데이터만 두고 본문은 Store로 이동  
- regex 파싱 대신 네이티브 tool_use 사용  
- 테스트 가능하도록 노드 분리  
- 프레임웍크에 대한 정확한 이해와 활용 구조가 필요했던 나 자신  
  
 "어떻게 쓰는가"가 아니라 "어떻게 잘못 썼는가"에 대한 기록/공유 입니다.

## Comments



### Comment 62169

- Author: daigom
- Created: 2026-07-21T20:16:50+09:00
- Points: 1

langchain langgraph를 사용하는 모든 경우는 AI SDK로 대체 가능한 듯

### Comment 62174

- Author: neocode24
- Created: 2026-07-21T21:17:53+09:00
- Points: 1
- Parent comment: 62169
- Depth: 1

그러게요. 공감합니다. SDK 의존성이 생기긴 하겠지만, 런닝커브가 높아서 차라리 나을듯 합니다.