Version 간 결과 비교/분석

Thu, 20 Aug 2026 00:00:00 +0900

LangGraph를 사용하기 이전(전부 4o모델) vs 모델 분기 비교 실험

결과

Metric	Baseline	Routing V2	Change (%)
Runs	85.0000	85.0000	0.0000
Total Cost ($)	0.8520	0.7277	-14.5903
Avg Cost ($)	0.0100	0.0086	-14.5903
Mean Latency (s)	4.6433	7.5294	+62.1563
P50 Latency (s)	4.2594	7.3486	+72.5282
P95 Latency (s)	7.2314	9.9255	+37.2561
P99 Latency (s)	9.4063	13.0560	+38.8006

LLM-based routing은 비용을 감소시켰지만 sequential LLM calls로 P95 latency가 너무 증가하는 문제점이 생겼다. Total Cost와 Latency의 문제를 둘 다 잡는 다른 방법에 대한 고민이 필요해보였다..

LLM Router 까지 두어서 LLM 모델을 두 번 처리하는 게 문제였기에, LLM Router를 제거하고 lightweight intent classifier로 대체 하려고 함.

기존 LLM Router 대신 sentenceTransformer + LogisticRegression 기반 classifier로 구현하고자 함.

`v1` vs `v2` vs `v3`

Metric	V1 Baseline	V2 LLM Router	V3 Classifier
Runs	85	85	85
Total Cost ($)	0.8557	0.7401	0.7224
Avg Cost / Run ($)	0.0101	0.0087	0.0085
Mean Latency (s)	4.1386	6.2194	3.3433
P50 Latency (s)	3.1119	5.4087	3.1164
P95 Latency (s)	7.4149	11.0379	7.0132
P99 Latency (s)	12.9387	11.9233	8.7200
API Calls	85	85	67
API Call Rate (%)	100.00	100.00	78.82
Extract Rule Correctness	0.8941	0.9048	0.9024
Extract Rule Correctness (if routed)	-	0.9048	0.8780
Route Correctness	-	1.0000	0.9756

V3는 V1 대비 비용 15.58%, 평균 Latency 19.22% 감소했고, LLM API 호출도 21.18% 절감함.
정확도는 V1 0.8941 → V3 0.9024로 유지·소폭 개선되어, 성능 저하 없이 비용과 응답 속도를 함께 개선함.

LangGraph 도입 검토 및 데이터셋 설계

Mon, 17 Aug 2026 00:00:00 +0900

`LangGraph` 도입하는 게 맞을까?

LangGraph를 비용 최적화 를 위해 도입하는 게 좋을 거 같음.

현재 version은 ChatGPT 4o 모델을 활용해 사용자 자연어 처리를 함.
- 현재 얼마의 비용이 청구되는 지에 대한 정확한 판단이 필요함. 문제 설정 필요
- 하지만 사용자 명령이 만약 안녕, ㅎ2, ㅎㅎ 라면? 굳이 모든 명령들을 전부 4o 모델로 처리할 필요가 있을까??
- 사용자의 명령을 중요도 낮음, 약간 중요, 매우 중요 등으로 나눠서, 이에 맞는 수준의 모델로 라우팅해주는 게 좋을 거 같음. 나중에 구현할 기능

Version 01.

flowchart TD START([사용자 입력
prompt + pending 플래그]) --> R{의도 라우터
gpt-4o-mini} R -->|잡담 / 인사 / ㅎㅎ| S[단순 응답
gpt-4o-mini
tool 없음] S --> END1([END
채팅 응답만]) R -->|알림 규칙 관련| P{pending?} P -->|false| E[규칙 추출
gpt-4o
extract_notification_rule] P -->|true| C[재질문 후속 분류
gpt-4o-mini] C -->|supplement
보충| M[이전 명령 + 보충
합친 prompt] C -->|new_command
새 명령| N[이번 prompt만] M --> E N --> E E -->|tool 성공| OK[confirm 문장
gpt-4o] E -->|정보 부족| ASK[재질문 메시지
ok=false] OK --> END2([END
규칙 저장]) ASK --> END3([END
앱이 pending 유지])

Version 02.

flowchart TD START([사용자 입력
prompt + pending + pendingOriginal]) --> ENTRY{pending=true
AND pendingOriginal 있음?} ENTRY -->|Yes| RP[resolve_pending] ENTRY -->|No| R[의도 라우터
gpt-4o-mini
route_intent] R -->|chitchat
잡담/인사/ㅎㅎ| S[단순 응답
gpt-4o-mini
tool 없음] S --> END1([END
ok=false
failReason=chitchat
needsSupplement=false]) R -->|extract
알림 규칙 관련| RP RP --> C{pending 분류?
gpt-4o-mini} C -->|pending 아님| N[이번 prompt만] C -->|supplement
보충| M[이전 명령 + 보충
합친 prompt] C -->|new_command
새 명령| N M --> E[규칙 추출
gpt-4o
function calling] N --> E E -->|성공| OK[confirm 문장
gpt-4o] E -->|정보 부족| ASK[재질문
ok=false
needsSupplement=true] E -->|충돌/앱 미해결 등| FAIL[실패
ok=false
needsSupplement=false] OK --> END2([END
규칙 저장]) ASK --> END3([END
앱이 pending 유지]) FAIL --> END4([END
pending 해제])

LangGraph 도입 시 (`Routing 버전`을 추가), 확인 사항

A버전에 비해 B버전에서, 정확도가 많이 떨어지지 않는지
비용 및 속도가 얼마나 줄어드는지

Evaluation Dataset 구성 기준

Evaluation Dataset이 특정 유형에 편중되지 않도록, 주요 평가 축을 intent, time, target으로 나누고 각 카테고리 별 최소 케이스 수를 정의했습니다.

전체 Dataset: 85 cases
주요 카테고리 별 최소 5 cases 이상 확보
ok=true 케이스에서는 time, target 세부 유형이 모두 포함되도록 구성

Coverage 확인

모든 주요 카테고리에서 최소 5개 이상의 평가 케이스를 확보하여, 특정 입력 유형이 Dataset에서 완전히 누락되는 것을 방지했습니다.

축	값	개수	기준	상태
A. intent	`mute`	44	≥5	OK
A. intent	`allow`	14	≥5	OK
A. intent	`reject`	27	≥5	OK
B. time (ok=true 58건)	`duration`	38	≥5	OK
B. time	`until_absolute`	5	≥5	OK
B. time	`relative_delay`	5	≥5	OK
B. time	`daily`	5	≥5	OK
B. time	`weekly`	5	≥5	OK
C. target (ok=true 58건)	`all`	11	≥5	OK
C. target	`single_app`	29	≥5	OK
C. target	`multi_app`	5	≥5	OK
C. target	`content`	6	≥5	OK
C. target	`app_and_content`	7	≥5	OK

References

LangGraph 도입해야 한다면 내 프로젝트 서비스를 최적화시켜줄 수 있는 최적의 참조 논문은..?

Reasoning과 Action을 번갈아 수행하면서 외부 환경 / 도구와 상호작용하는 구조

같은 LLM이 Generator, Feedback Provider, Refiner 역할을 수행하면서 반복적으로 결과 개선
별도의 Supervised Training이나 RL 없이도 여러 task에서 one-shot generation보다 성능 개선 보고

자연어 reflection 형태로 memory에 저장하고 다음 attempt에 활용하는 구조
LangGraph에서 state / memory / retry loop를 설계할 때 굉장히 자연스럽게 연결

틀린 모델이 자기 답을 평가하면 틀릴 수 있음.
검색엔진, 코드 실행기 같은 외부 도구의 피드백을 사용해 검증

여러 reasoning candidate를 만들고 평가하면서 search / branching / backtracking

전체 문제를 먼저 작은 subtask로 나눈 뒤 실행
특히 Zero-shot CoT에서 발생하는 missing-step 등의 문제를 해결하려는 접근

reasoning과 tool observation을 분리

Tool Calling의 중요한 초기 연구
LLM이 언제 어떤 API를 사용할지를 결정하는 것 자체를 연구한 논문

같은 여러 Agent 간 interaction을 일반화한 프레임워크 연구
LLM, human input, tool을 조합한 customizable/conversable agent를 구성하고 다양한 conversation pattern을 정의

기획 |

Version 간 결과 비교/분석

결과

v1 vs v2 vs v3

LangGraph 도입 검토 및 데이터셋 설계

LangGraph 도입하는 게 맞을까?

Version 01.

Version 02.

LangGraph 도입 시 (Routing 버전을 추가), 확인 사항

Evaluation Dataset 구성 기준

Coverage 확인

References

`v1` vs `v2` vs `v3`

`LangGraph` 도입하는 게 맞을까?

LangGraph 도입 시 (`Routing 버전`을 추가), 확인 사항