요즘 개발자들 사이에서 은근히 자주 들리는 이름이 있죠. 바로 LangGraph예요. 저도 처음 들었을 때는 솔직히 그랬습니다. “아 또 뭐가 나왔나 보다… LangChain도 아직 다 못 씹어먹었는데?” 이런 마음이었거든요.
그런데 말이죠. 막상 써보니까 느낌이 좀 달랐어요. 단순히 새로운 라이브러리 하나 더 배워야 하는 수준이 아니라, 에이전트 워크플로우를 바라보는 방식 자체를 바꿔버리는 쪽에 가깝더라고요. 특히 LLM으로 뭔가 자동화하려고 하다 보면, 처음엔 간단해 보여도 금방 복잡해지잖아요. 질문 받고, 검색하고, 정리하고, 답변하고… 여기까진 괜찮은데, 중간에 조건이 붙고 예외가 생기고 사용자가 엉뚱한 말을 하기 시작하면 그때부터 머리가 슬슬 아파집니다.
20년 가까이 개발하면서 느낀 건데, 새로운 기술이 진짜 쓸 만한지는 예제 코드가 예쁜지가 아니라, 현장에서 꼬였을 때 얼마나 덜 괴롭게 풀리느냐로 갈리는 것 같아요. 그런 면에서 LangGraph는 꽤 괜찮은 도구입니다. 오늘은 너무 딱딱한 설명 말고, 제가 실제로 만져보면서 느낀 점이랑 LLM 토큰 아끼는 방법, 프롬프트 효율화, 그리고 설정에서 미리 챙겨두면 좋은 현실적인 팁들을 편하게 이야기해볼게요.
LangGraph는 그냥 체인이 아니라, 흐름을 그래프로 보는 방식이에요
예전에는 LLM 기반 기능을 만들 때 보통 “체인”으로 생각을 많이 했어요. 사용자의 질문이 들어오면 검색하고, 검색 결과를 요약하고, 그걸 바탕으로 답변하고. 이렇게 쭉 이어지는 흐름이죠. 단순한 기능이라면 이 방식도 충분히 좋습니다. 괜히 복잡하게 갈 필요 없어요.
문제는 현실의 업무 흐름이 그렇게 얌전하지 않다는 거예요. 사용자가 질문을 했는데 그게 단순 문의인지, 환불 요청인지, 기술 장애 신고인지, 아니면 그냥 불만 토로인지 먼저 판단해야 할 때가 있잖아요. 또 어떤 경우엔 검색이 필요하고, 어떤 경우엔 내부 DB를 조회해야 하고, 어떤 경우엔 사람에게 넘겨야 합니다. 여기서부터 기존의 선형 체인은 조금씩 버거워져요.
LangGraph는 이런 흐름을 Node와 Edge로 구성된 그래프로 다룹니다. 쉽게 말하면, 각각의 작업 단계를 노드로 만들고, 그 사이를 엣지로 연결하는 방식이에요. 그리고 중요한 건 이 흐름이 꼭 한 방향으로만 쭉 가는 게 아니라는 점입니다. 조건에 따라 다른 길로 빠질 수도 있고, 다시 이전 단계로 돌아갈 수도 있고, 특정 상태가 만족될 때까지 반복할 수도 있어요.
뭐랄까, 여행 일정 짜는 느낌하고도 좀 비슷합니다. 제주도에 갔다고 해볼게요. 원래는 아침에 오름 올라가고, 점심 먹고, 해변 가고, 저녁에 시장 들르는 코스였는데 갑자기 비가 와요. 그러면 오름은 접고 카페나 전시관으로 방향을 틀잖아요. 날씨가 괜찮아지면 다시 바닷가로 가고요. 에이전트 워크플로우도 딱 이래요. 현실에서는 늘 조건이 생기고, 예외가 생기고, 사람이 예상하지 못한 입력을 던집니다.
복잡한 if-else를 그래프로 꺼내놓는 느낌
제가 LangGraph를 처음 괜찮다고 느낀 순간은 고객 문의 자동 처리 흐름을 만들 때였어요. 사용자가 “환불해주세요”라고 입력하면, 시스템은 그냥 환불해주면 되는 게 아니잖아요. 주문 정보도 봐야 하고, 결제 상태도 확인해야 하고, 배송이 이미 시작됐는지도 봐야 하고, 환불 정책도 체크해야 합니다.
이걸 코드 안에서 if-else로 계속 밀어붙이면 어느 순간 이런 상태가 됩니다. “어… 이 조건은 어디서 걸러졌지?”, “이 케이스는 왜 상담원 연결로 안 갔지?”, “여기서 LLM을 왜 또 호출하고 있지?” 이런 식으로요. 개발자라면 다들 한 번쯤 겪어봤을 겁니다. 분명 처음엔 깔끔했는데, 운영하면서 조건 하나씩 붙이다 보면 어느새 괴물이 되어 있는 코드...
LangGraph로 바꾸면 흐름이 눈에 보입니다. 예를 들어 이런 식이에요.
- 사용자 요청 분석 노드
- 주문 정보 조회 노드
- 환불 가능 여부 판단 노드
- 자동 환불 처리 노드
- 상담원 연결 노드
- 사용자 안내 메시지 생성 노드
각 노드는 자기 일만 합니다. 그리고 다음에 어디로 갈지는 상태와 조건에 따라 결정해요. 이게 별거 아닌 것 같아도, 유지보수할 때 진짜 차이가 큽니다. 특히 팀 단위로 개발할 때는 “이 흐름이 어디로 빠지는지”를 코드만 보고 파악하는 것보다 그래프 구조로 보는 게 훨씬 편해요.
LLM 토큰 아끼려면 상태 관리를 대충 하면 안 됩니다
LLM 붙여서 뭔가 만들다 보면 처음에는 신기해서 이것저것 다 넣게 됩니다. 사용자 대화 전체 넣고, 시스템 설명 넣고, 이전 처리 결과 넣고, 혹시 모르니까 로그 비슷한 것도 넣고… 그러다 어느 날 비용 리포트를 보면 살짝 정신이 번쩍 들어요. “아, 이게 다 돈이었지?” 하고요.
토큰 비용은 생각보다 빨리 불어납니다. 특히 에이전트 구조에서는 LLM을 한 번만 호출하는 게 아니라 여러 번 호출하잖아요. 분류할 때 한 번, 검색어 만들 때 한 번, 결과 요약할 때 한 번, 답변 작성할 때 또 한 번. 여기서 매번 전체 대화 히스토리를 다 넘기면 비용이 눈덩이처럼 커져요.
그래서 LangGraph를 쓸 때 제가 가장 신경 쓰는 부분이 상태 관리입니다. 각 노드에 필요한 정보만 넘기는 거예요. 정말 필요한 것만요. 이게 말은 쉬운데, 실제로는 습관을 좀 바꿔야 합니다. 개발하다 보면 “혹시 모르니까 이것도 넣자”라는 마음이 생기거든요. 그런데 LLM에서는 그 “혹시”가 비용이 됩니다.
각 노드에는 필요한 컨텍스트만 넘기세요
예를 들어 검색 노드가 있다고 해볼게요. 이 노드의 역할은 사용자의 질문을 바탕으로 검색 키워드를 만들거나 검색을 실행하는 거예요. 그럼 이 노드에 전체 대화 내역 30줄이 다 필요할까요? 대부분은 아닙니다. 사용자 질문, 이전 단계에서 정리된 의도, 필요하다면 짧게 요약된 배경 정도면 충분한 경우가 많아요.
저는 보통 이런 식으로 나눕니다.
- 원본 사용자 질문: 사용자가 실제로 입력한 문장
- 의도 분류 결과: 환불, 기술 문의, 일반 질문 같은 간단한 카테고리
- 필요한 요약 컨텍스트: 이전 대화 전체가 아니라 2~3줄 요약
- 노드별 출력값: 다음 단계에 꼭 필요한 형태로 정리된 결과
이렇게 하면 토큰이 확 줄어듭니다. 그리고 재밌는 건, 토큰을 줄였는데 오히려 답변 품질이 좋아질 때도 있어요. LLM이 쓸데없는 정보를 덜 보니까 자기 역할에 더 집중하는 느낌이랄까요. 사람도 회의 자료 80페이지 던져주면 핵심 놓치잖아요. LLM도 비슷합니다.
조건부 엣지로 쓸데없는 LLM 호출을 줄이는 게 진짜 큽니다
Conditional Edge는 LangGraph에서 꽤 맛있는 기능입니다. 노드의 결과를 보고 다음 노드를 동적으로 결정할 수 있거든요. 이걸 잘 쓰면 불필요한 LLM 호출 자체를 줄일 수 있어요.
예를 들어 사용자가 “비밀번호 변경은 어디서 해요?”라고 물었다고 해볼게요. 이런 질문은 굳이 복잡한 검색 에이전트를 돌릴 필요가 없을 수 있습니다. 이미 FAQ에 있는 내용이면 바로 답변하면 되죠. 그런데 사용자가 “지난달 결제된 내역 중에 기업카드로 처리된 건만 정리해서 세금계산서 발행 가능 여부 알려줘”라고 하면 얘기가 달라집니다. DB 조회도 필요하고, 정책 확인도 필요하고, 답변도 조심스럽게 만들어야 해요.
이럴 때 조건부 엣지로 흐름을 나눠두면 좋아요.
- 단순 FAQ 성격이면 바로 답변 노드로 이동
- 정책 확인이 필요하면 문서 검색 노드로 이동
- 사용자 데이터 조회가 필요하면 DB 조회 노드로 이동
- 민감하거나 예외적인 요청이면 상담원 연결 노드로 이동
제가 운영하던 내부 도구에서도 비슷한 방식으로 분기 처리를 넣었는데, 체감상 비용 절감이 꽤 컸습니다. 정확히 모든 케이스가 동일하진 않지만, 한 달 기준으로 토큰 사용량이 30% 가까이 줄어든 적도 있었어요. 사실 이때 좀 놀랐습니다. 모델을 바꾸거나 거창한 최적화를 한 게 아니라, “안 불러도 되는 LLM을 안 부르게 한 것”만으로 효과가 나왔거든요.
프롬프트는 길게 쓰는 것보다 역할을 잘 나누는 게 낫더라고요
처음 LLM 개발을 시작하면 프롬프트 하나에 모든 걸 다 넣고 싶어집니다. 너는 친절해야 하고, 정확해야 하고, 검색도 잘해야 하고, 요약도 잘해야 하고, JSON도 잘 만들어야 하고, 예외도 처리해야 하고… 이렇게요. 저도 그랬습니다. 긴 시스템 프롬프트 하나 만들어놓고 “이 정도면 알아서 잘하겠지” 했어요.
근데 실제로 돌려보면 꼭 그렇진 않더라고요. 프롬프트가 길어질수록 LLM이 중요한 지시를 놓치기도 하고, 노드마다 필요 없는 지시까지 계속 들고 다니니까 토큰도 낭비됩니다. 그래서 LangGraph에서는 노드별 시스템 메시지를 따로 가져가는 방식이 훨씬 잘 맞습니다.
노드별로 System Message를 작게 쪼개세요
검색 노드라면 검색에 집중하면 됩니다. 요약 노드라면 요약만 잘하면 되고요. 분류 노드라면 분류 기준을 명확히 주는 게 더 중요합니다.
예를 들면 이런 식이죠.
- 분류 노드: 사용자의 요청을 환불, 기술 문의, 계정 문의, 일반 질문 중 하나로 분류해줘.
- 검색 노드: 사용자의 질문에서 검색에 필요한 핵심 키워드만 추출해줘.
- 요약 노드: 검색 결과에서 답변에 필요한 핵심 내용만 3문장 이내로 정리해줘.
- 답변 생성 노드: 사용자가 이해하기 쉬운 말투로 답변하되, 모르는 내용은 추측하지 마.
이렇게 역할을 나눠두면 각 LLM 호출이 훨씬 가벼워집니다. 그리고 디버깅도 쉬워져요. 답변이 이상할 때 “검색이 문제였나?”, “요약에서 빠졌나?”, “최종 답변 노드가 말을 지어냈나?”를 나눠서 볼 수 있으니까요. 이 차이가 운영 단계에서는 꽤 큽니다.
max_tokens는 노드마다 다르게 잡는 게 좋습니다
이건 은근히 많이 놓치는 부분인데요. 모든 노드에 같은 max_tokens를 걸어두면 생각보다 낭비가 생깁니다. 분류 노드는 사실 짧게 답하면 됩니다. “환불” 또는 “기술 문의” 정도면 충분할 때도 많아요. 그런데 여기에 max_tokens를 1000으로 열어두면 LLM이 가끔 친절함을 과하게 발휘합니다. 설명까지 줄줄 붙여요. 고맙긴 한데… 필요 없죠.
저는 보통 이런 식으로 감을 잡습니다.
- 분류 노드: 50~100 tokens 정도
- 검색어 생성 노드: 100~200 tokens 정도
- 요약 노드: 300~500 tokens 정도
- 최종 답변 노드: 서비스 성격에 따라 500~1200 tokens 정도
물론 정답은 없습니다. 서비스마다 다르고, 모델마다 다르고, 사용자 기대치도 달라요. 다만 한 가지는 분명합니다. 모든 노드를 똑같이 취급하면 비용도, 품질도 애매해질 가능성이 높아요. 작은 일은 작게 처리하고, 큰 일에만 넉넉한 자원을 주는 게 좋습니다. 이건 사람 일하는 방식하고도 비슷하죠.
설정에서 미리 챙겨두면 나중에 덜 울어요
개발할 때는 “일단 돌아가게 만들자”가 중요할 때가 많습니다. 저도 압니다. 일정은 늘 빠듯하고, 데모는 내일이고, PM은 오늘도 슬랙에서 웃는 이모지를 보내며 압박하고 있죠. 그런데 LLM 워크플로우는 설정을 대충 해두면 운영에서 꼭 한 번은 뒤통수를 맞습니다.
LangGraph를 쓸 때 제가 꼭 챙기는 설정들이 있어요. 대단한 비법이라기보다는, 몇 번 아파보고 나서 생긴 습관에 가깝습니다.
Recursion Limit은 꼭 의식하고 잡아두세요
Recursion Limit은 그래프가 얼마나 깊게 또는 반복적으로 실행될 수 있는지를 제한하는 설정입니다. 에이전트가 스스로 판단해서 도구를 호출하고 다시 판단하는 구조에서는 루프가 생길 수 있어요. 의도한 루프면 괜찮지만, 의도하지 않은 루프는 비용과 장애를 같이 데리고 옵니다.
저는 복잡한 워크플로우에서는 Recursion Limit을 너무 낮게 두지 않되, 무한정 풀어두지도 않습니다. 보통 예상 가능한 최대 흐름보다 조금 여유 있게 잡고, 별도로 반복 횟수나 실패 횟수를 상태에 기록해요. 예를 들어 같은 검색을 세 번 이상 반복하면 fallback으로 빠지게 한다든지요.
이거 안 해두면 진짜 이상한 일이 생깁니다. 에이전트가 “정보가 부족하네?” 하고 검색하고, 또 부족하다고 검색하고, 또 검색하고… 보고 있으면 약간 안쓰럽기도 한데 비용은 안 안쓰럽습니다.
Checkpointer는 운영 환경에서 거의 보험 같은 존재입니다
Checkpointer는 각 단계의 상태를 저장해두는 기능이라고 보면 됩니다. 이걸 켜두면 중간에 에러가 나도 처음부터 다시 시작하지 않고, 저장된 지점에서 이어갈 수 있어요.
예를 들어 10단계짜리 워크플로우가 있다고 해볼게요. 8단계까지 잘 갔는데 9단계에서 외부 API가 잠깐 죽었습니다. Checkpointer가 없으면 처음부터 다시 돌려야 할 수도 있어요. 그러면 이미 쓴 토큰도 아깝고, 사용자도 기다리고, 로그도 복잡해집니다. 반면 상태가 저장돼 있으면 마지막 성공 지점에서 다시 이어갈 수 있죠.
제가 예전에 내부 자동화 작업을 만들 때, 긴 문서를 분석해서 여러 단계로 리포트를 만드는 플로우를 돌린 적이 있었어요. 처음엔 Checkpointer를 대충 넘겼는데, 중간에 네트워크 오류가 나면서 거의 다 처리한 작업을 처음부터 다시 돌린 적이 있습니다. 그날 이후로는 긴 흐름에는 무조건 상태 저장을 먼저 챙깁니다. 진짜로요. 커피 한 잔 마시며 기다리던 여유가 갑자기 한숨으로 바뀌는 경험, 한 번이면 충분합니다.
Timeout과 fallback은 사용자 경험을 지키는 안전벨트예요
LLM 호출은 가끔 느려집니다. 모델 상태 때문일 수도 있고, 네트워크 문제일 수도 있고, 외부 도구 호출이 꼬였을 수도 있어요. 그래서 Timeout 설정은 꼭 필요합니다. 무한정 기다리게 두면 사용자 입장에서는 서비스가 멈춘 것처럼 느껴지거든요.
저는 보통 노드 성격에 따라 30초에서 60초 사이로 제한을 둡니다. 단순 분류나 검색어 생성은 더 짧게 잡고, 긴 답변 생성이나 문서 분석은 조금 더 여유를 줘요. 그리고 Timeout이 발생하면 바로 실패 처리하는 게 아니라 fallback 노드로 보내는 편입니다.
fallback 방식은 여러 가지가 있어요.
- 더 가벼운 모델로 다시 시도하기
- 캐시된 응답이 있으면 우선 반환하기
- 사용자에게 “조금 더 확인이 필요해요”라고 안내하기
- 상담원이나 수동 처리 큐로 넘기기
중요한 건 사용자를 막다른 골목에 세워두지 않는 겁니다. 에이전트가 완벽하게 답하지 못하더라도, 다음 액션을 안내해주면 사용자 경험은 훨씬 덜 무너져요.
Logging은 귀찮아도 나중에 나를 살려줍니다
Logging은 진짜 귀찮습니다. 인정합니다. 개발할 때는 기능 만드는 것도 바쁜데, 각 노드의 입력과 출력, 토큰 사용량, 모델 응답, 에러까지 다 기록하려면 손이 많이 가요. 그런데 운영에서 문제가 생기면 결국 로그가 답입니다.
LangGraph를 쓸 때는 각 노드가 어떤 입력을 받았고, 어떤 출력을 냈고, 다음 노드로 왜 이동했는지를 남겨두는 게 좋습니다. 특히 LLM 기반 시스템은 일반적인 코드보다 결과가 덜 결정적이기 때문에, 나중에 “왜 이런 답변이 나갔지?”를 추적할 수 있어야 해요.
저는 보통 이런 항목들을 남깁니다.
- 노드 이름
- 입력 상태
- LLM에 보낸 프롬프트
- LLM 응답
- 사용한 모델명
- 입력 토큰과 출력 토큰
- 다음 노드로 이동한 이유
- 에러 메시지와 재시도 여부
이렇게 해두면 나중에 토큰을 많이 잡아먹는 노드도 찾을 수 있고, 프롬프트가 너무 장황한 곳도 보입니다. 어느 노드에서 hallucination이 자주 발생하는지도 확인할 수 있고요. 솔직히 말하면, 로그 잘 쌓아둔 팀이 LLM 서비스 운영을 훨씬 빨리 안정화합니다. 감으로 고치는 데는 한계가 있어요.
LangGraph를 쓸수록 설계의 중요성이 더 크게 느껴집니다
LangGraph는 좋은 도구입니다. 그런데 만능은 아니에요. 이걸 쓰면 모든 에이전트가 갑자기 똑똑해지고, 모든 워크플로우가 자동으로 예뻐지는 건 아닙니다. 결국 중요한 건 설계예요. 어떤 상태를 들고 갈지, 어떤 노드로 나눌지, 어디서 LLM을 부를지, 어디서는 그냥 코드로 처리할지. 이 판단이 훨씬 중요합니다.
저도 처음에는 그래프를 멋지게 만들고 싶어서 이것저것 많이 넣었습니다. 노드도 많이 쪼개고, 조건도 세세하게 넣고, 혹시 모를 예외까지 다 처리하려고 했어요. 그런데 어느 순간 보니까 그래프 자체가 너무 복잡해져서, 이걸 만든 저도 흐름을 다시 따라가야 하더라고요. 그때 좀 민망했습니다. 도구를 잘 쓰려다가 도구에 끌려간 느낌이었거든요.
지금은 원칙을 조금 단순하게 가져갑니다. 가장 단순한 그래프로 시작하고, 실제 문제가 생길 때만 복잡도를 추가한다. 이게 제일 낫더라고요. 처음부터 완벽한 에이전트를 만들려고 하면 대부분 과하게 설계됩니다. 반대로 핵심 흐름만 먼저 만들고, 운영 데이터를 보면서 분기와 노드를 추가하면 훨씬 현실적인 구조가 나와요.
처음부터 거창하게 만들 필요는 없습니다
처음 LangGraph를 도입한다면, 저는 작은 업무부터 시작해보는 걸 추천합니다. 예를 들면 고객 문의 분류, 사내 문서 검색 답변, 회의록 요약, 장애 티켓 분류 같은 것들이요. 이런 작업은 흐름이 비교적 명확하면서도 조건 분기의 효과를 보기 좋습니다.
처음부터 “자율적으로 모든 업무를 처리하는 슈퍼 에이전트”를 만들려고 하면 거의 반드시 꼬입니다. 멋있긴 한데, 운영은 멋으로만 굴러가지 않거든요. 작은 그래프 하나를 안정적으로 만들고, 거기서 토큰 사용량과 실패 케이스를 관찰해보는 게 훨씬 낫습니다.
생각해보면 여행도 그렇잖아요. 처음 가는 도시에서 아침 7시부터 밤 11시까지 코스를 꽉 채워놓으면, 계획표는 근사한데 사람은 지칩니다. 오히려 꼭 가고 싶은 곳 몇 군데만 정해두고, 나머지는 현장에서 기분 따라 움직일 때 더 좋은 기억이 남을 때가 많아요. LangGraph 설계도 좀 비슷합니다. 큰 방향은 잡되, 처음부터 모든 길을 포장하려고 하지는 않는 게 좋아요.
LLM 에이전트 개발에서 LangGraph가 주는 현실적인 장점
제가 느낀 LangGraph의 가장 큰 장점은 “복잡한 흐름을 구조적으로 다룰 수 있다”는 점입니다. LLM을 단순 호출하는 단계에서는 크게 와닿지 않을 수 있어요. 그런데 에이전트가 도구를 쓰고, 상태를 기억하고, 조건에 따라 판단하고, 중간에 실패하면 복구해야 하는 수준으로 가면 이야기가 달라집니다.
그때부터는 코드 몇 줄의 문제가 아니라 운영 가능한 구조의 문제가 됩니다. 그리고 LangGraph는 이 지점에서 꽤 좋은 선택지가 됩니다.
- 상태 기반 워크플로우를 명확하게 설계할 수 있습니다.
- 조건부 분기를 통해 불필요한 LLM 호출을 줄일 수 있습니다.
- 노드별 프롬프트로 역할을 세분화할 수 있습니다.
- Checkpointer로 긴 작업의 안정성을 높일 수 있습니다.
- Logging을 통해 비용과 품질을 계속 개선할 수 있습니다.
다만, 이 장점들은 그냥 LangGraph를 설치한다고 생기지 않습니다. 설계를 해야 생겨요. 상태를 어떻게 정의할지, 노드를 얼마나 잘게 나눌지, 어떤 조건에서 어떤 경로를 탈지 계속 고민해야 합니다. 조금 귀찮지만, 이 고민이 쌓이면 나중에 시스템이 훨씬 덜 흔들립니다.
그래서 LangGraph를 어떻게 시작하면 좋을까요?
처음 시작할 때는 너무 많은 걸 한 번에 하려고 하지 않는 게 좋습니다. 제 기준에서는 아래 정도만 잡고 시작해도 충분해요.
- 사용자 입력을 받는 시작 노드 만들기
- 의도를 분류하는 노드 만들기
- 단순 질문과 복잡한 질문을 나누는 조건부 엣지 만들기
- 검색이 필요한 경우에만 검색 노드 호출하기
- 최종 답변 노드에서 사용자에게 자연스럽게 응답하기
- 각 노드의 입력, 출력, 토큰 사용량을 로깅하기
이 정도만 해도 LangGraph의 감이 옵니다. 그리고 여기서부터 조금씩 확장하면 됩니다. 환불 처리 노드를 붙일 수도 있고, DB 조회 노드를 넣을 수도 있고, 사람 검토가 필요한 흐름을 추가할 수도 있어요. 중요한 건 작게 시작하는 겁니다.
사실 개발 오래 하다 보면 늘 같은 교훈으로 돌아오게 됩니다. 복잡한 문제를 한 번에 멋지게 해결하려고 하면 대부분 힘들어져요. 작게 만들고, 관찰하고, 고치고, 다시 붙이는 방식이 결국 오래갑니다. LLM 에이전트 개발도 똑같아요.
LangGraph는 도구고, 진짜 실력은 흐름을 설계하는 데서 나옵니다
LangGraph를 써보면 확실히 편합니다. 특히 에이전트 워크플로우가 복잡해질수록 “아, 이래서 그래프로 다루는구나” 하는 순간이 와요. 하지만 도구가 좋아졌다고 해서 설계 고민이 사라지는 건 아닙니다. 오히려 더 선명하게 드러납니다.
어떤 정보가 상태에 남아야 하는지, 어떤 노드는 LLM을 쓰고 어떤 노드는 일반 코드로 충분한지, 어디서 비용이 새고 있는지, 사용자가 기다릴 수 있는 시간은 어느 정도인지. 이런 질문들을 계속 던져야 합니다. 귀찮지만, 이게 진짜예요.
개인적으로는 LangGraph를 “LLM 에이전트를 잘 정리해주는 지도”처럼 보고 있습니다. 지도가 있다고 여행이 자동으로 좋아지는 건 아니지만, 적어도 길을 잃었을 때 돌아올 기준은 생기잖아요. LangGraph도 그렇습니다. 복잡한 흐름 속에서 지금 어디에 있는지, 다음에 어디로 가야 하는지, 왜 그 길로 가는지를 보여주는 도구에 가깝습니다.
만약 지금 LLM으로 뭔가 자동화하고 있는데 코드가 점점 꼬이고 있다면, 한 번쯤 LangGraph를 검토해보셔도 좋습니다. 처음부터 거창하게 말고요. 작은 워크플로우 하나만 그래프로 옮겨보세요. 그러다 보면 어느 순간 느껴질 겁니다. “아, 이거 그냥 유행어가 아니라 꽤 실전적인데?” 하고요.
저는 앞으로 LLM 기반 개발에서 이런 흐름 설계 능력이 점점 더 중요해질 거라고 봅니다. 모델은 계속 좋아지겠지만, 좋은 모델을 어디서 어떻게 부를지는 여전히 개발자의 몫이니까요. 그리고 그 지점에서 LangGraph는 꽤 든든한 선택지가 될 수 있습니다. 너무 과장하지 않고 말해도, 이건 한번 배워둘 만합니다. 진짜로요.
댓글
댓글 쓰기