랭그래프 운영 실전 정리: 그래프 API와 함수형 API 선택, 로컬 배포, 랭스미스 추적과 평가 문제

핵심 메시지

• 랭그래프는 노드와 엣지로 선언적으로 짜는 그래프 API와 함수 위에서 구현하는 함수형 API를 모두 제공하며, 둘 중 하나를 고르기보다 목적에 맞춰 섞어 쓰는 것도 가능하다.
• 그래프 API의 가장 큰 장점은 시각화이고, 요즘은 코드를 AI에게 맡기는 경우가 많아 문법 자체보다 각 방식의 차이와 선택 이유를 이해하는 수준이면 충분하다는 것이 발표자의 견해다.
• 배포가 가장 어려운 지점인데, 서버가 상시 켜져 있어야 하는 구조라 서버리스 환경으로는 대체하기 어렵고 클라우드 비용 문제가 따라온다.
• 로컬 개발 서버를 백그라운드로 띄우고 헬스 체크를 거친 뒤 파이썬 SDK나 REST API 중 편한 방식으로 호출하면, 유료 클라우드 없이도 배포와 동작 확인을 실습할 수 있다.
• 운영에서 진짜 어려운 것은 평가다. 도메인 담당자가 질문·답변 쌍조차 만들기 어렵고 합격 기준에 대한 합의도 힘들어서, 2~3주 열심히 개발한 시스템이 실제로는 쓰이지 않는 경우가 대부분이라는 경험이 공유된다.

쉽게 이해하기

이 발표는 랭그래프 문서의 운영 관련 장들을 실습 위주로 정리한 스터디 녹화다. 발표자는 API 선택, 배포, 디버깅과 관찰이라는 세 가지 질문을 순서대로 다룬다. 실습 환경은 로컬 LLM 기준으로 꾸렸고, 올라마 위에 가벼운 모델을 올려 성능보다 기본 동작을 확인하는 데 초점을 맞췄다. 필요한 패키지는 랭그래프와 랭그래프 SDK, 랭스미스, 랭체인 올라마, 랭체인 코어 등으로 정리된다.

첫 번째 주제는 그래프 API와 함수형 API의 선택이다. 그래프 API는 노드와 엣지를 등록해 선언적으로 흐름을 구성하는 방식이고, 함수형 API는 익숙한 프로그래밍 방식대로 함수 위에서 구현하는 방식이다. 발표자는 정답은 없고 상황에 맞게 고르면 되며 두 방식을 함께 쓸 수도 있다고 말한다. 다만 그래프 API 쪽이 시각화에서 유리하고, 최근 흐름이 온톨로지를 포함해 모든 것을 노드 형태로 연결하는 쪽이라 계속 그래프 API를 써 보려 한다는 개인적인 방향도 덧붙인다.

예제는 두 방식을 나란히 보여 준다. 그래프 API 예제는 질문 노드와 축약 노드, 경로를 정하는 라우트 노드를 만들어 답변이 200자보다 길면 축약 노드를 거치고 짧으면 그대로 끝내는 조건 분기를 구성한다. 함수형 API 예제는 작업 단위를 등록해 하나의 워크플로우 안에서 요약과 제목 생성을 실행시킨다. 이어서 두 방식을 섞은 예제도 나오는데, 복잡한 조율은 그래프가 맡고 실제 생성은 함수형 쪽이 담당해 제목과 요약을 함께 내놓는 구조다.

두 번째 주제인 배포에서는 현실적인 제약이 드러난다. 혼자 쓸 것이라면 로컬에 아무 방식으로나 띄워도 되지만, 서버를 계속 켜 두려면 클라우드가 필요하고 관리형 클라우드는 유료이며, 요청이 들어올 때만 살아나는 서버리스 플랫폼은 상시 리소스를 전제로 하는 이 구조를 대신하지 못한다고 발표자는 답한다. 대안으로는 랭그래프 개발 서버를 로컬에서 띄워 실습하는 방법과 클라우드 신규 가입 무료 크레딧을 몇 달간 활용하는 방법이 제시된다. 실습은 애플리케이션 설정 파일이 정상적으로 실행되는지 확인한 뒤 개발 서버를 백그라운드로 띄워 헬스 체크를 하고, 파이썬 SDK나 헤더를 만들어 HTTP로 요청을 보내는 REST API 중 편한 방식으로 호출해 스트림 응답을 확인하는 순서로 진행된다.

세 번째 주제는 관찰과 평가다. LLM 개발에서 가장 큰 문제는 디버깅, 즉 어느 지점에서 왜 그런 답이 나왔는지 확인하는 일이다. 랭스미스 API 키와 프로젝트를 등록하면 추적 데이터가 쌓이고, 전역적으로 보다가 프로젝트별로, 다시 메타데이터와 태그 단위로 좁혀 들어가는 방식으로 분석할 수 있다. 사내 데이터를 다룰 때는 익명화 도구로 민감 정보를 마스킹해 두면 예외 처리가 조금 필요하더라도 훨씬 편하게 작업할 수 있다는 경험도 공유된다.

주요 인사이트

• 발표자는 요즘 코드를 직접 보지 않고 AI에게 맡기는 경우가 많다고 말하면서도, 그래서 오히려 각 API의 차이와 용도를 아는 것이 중요하다고 짚는다. AI가 목적을 듣고 특정 방식을 제안했을 때 왜 그것이 좋은지 이해할 수 있는 수준이면 충분하다는 기준이다.
• 배포 논의에서 서버리스가 만능이 아니라는 점이 분명해진다. 요청이 있을 때만 깨어나는 구조는 상시 실행 리소스를 전제로 하는 워크플로우 서버를 대체하지 못한다.
• 평가는 정답이 없는 영역으로 남는다. 질문·답변 쌍의 점수가 일정 기준을 넘으면 만족할 것인가에 대한 합의 자체가 어렵고, 무엇보다 도메인 담당자가 그 평가용 데이터를 직접 만들지 못한다는 점이 가장 큰 난관으로 지목된다.
• 운영자 입장에서 종료 조건이 없다는 점이 문제로 언급된다. 개발은 끝낼 수 있어도 평가와 개선은 끝나지 않아, 발표자는 도메인 담당자가 던진 질문들을 모아 하나의 온톨로지로 정리하고 프롬프트에 반영하는 방식을 시도하고 있다고 밝힌다.
• 발표의 마무리는 기술이 아니라 사용에 관한 이야기다. 배포보다 중요한 것은 추적과 모니터링, 피드백이 하나의 생애주기로 이어지는 것이며, 도메인이 쓰는 말과 시스템이 어긋나는 순간 그 시스템은 그대로 버려진다는 지적이다.

자주 묻는 질문

관련 AI 소식