AI 개발자를 위한 Langfuse 입문부터 실전까지

현재 기준으로 Langfuse는 v4가 정식 배포되어 있고, OpenTelemetry 기반의 LLM/Agent Observability, Prompt Management, Evaluation, Dataset/Experiment 등을 하나의 플랫폼에서 제공합니다. oai_citation:0‡Langfuse

AI 개발자를 위한 Langfuse 입문부터 실전까지

대상: LLM/AI 개발을 처음 시작하는 개발자
목표: Langfuse를 설치하고, LLM 호출을 추적하고, 비용·성능·품질을 분석하고, 프롬프트와 모델을 개선하는 것까지 이해한다.

1. Langfuse가 도대체 왜 필요한가?

AI 개발을 처음 하면 보통 이런 코드부터 시작합니다.

text

사용자 질문
    ↓
LLM 호출
    ↓
LLM 답변
    ↓
사용자에게 출력

예를 들어:

text

사용자:
"대한민국의 수도는?"

AI:
"서울입니다."

처음에는 이것만으로 충분합니다.

그런데 실제 서비스를 만들면 문제가 생깁니다.

1.1 AI가 갑자기 이상한 답을 한다

어제는 잘 대답했는데 오늘은 엉뚱한 답을 합니다.

개발자는 궁금합니다.

text

왜 틀렸지?

하지만 서버 로그에는 이렇게만 남아 있습니다.

text

POST /api/chat
200 OK

이것만으로는 원인을 알 수 없습니다.

실제로는 다음을 확인해야 합니다.

text

사용자 질문
    ↓
어떤 System Prompt를 사용했는가?
    ↓
어떤 모델을 사용했는가?
    ↓
Temperature는?
    ↓
RAG 검색 결과는?
    ↓
Tool 호출은?
    ↓
LLM에게 실제로 전달된 Prompt는?
    ↓
LLM의 원본 응답은?
    ↓
Token은 얼마나 사용했는가?
    ↓
비용은 얼마인가?
    ↓
전체 응답 시간은?

이것을 하나의 흐름으로 기록해 주는 것이 Tracing입니다.

Langfuse는 LLM 호출뿐 아니라 Retrieval, Embedding, Tool 실행 등 AI 애플리케이션 내부의 여러 작업을 추적할 수 있습니다. (Langfuse)

2. 한 문장으로 이해하는 Langfuse

가장 쉽게 표현하면:

Langfuse는 AI 애플리케이션의 블랙박스 기록 장치 + 성능 분석기 + 프롬프트 관리도구 + AI 품질 테스트 도구다.

일반 웹 개발에서 생각하면 이해하기 쉽습니다.

일반 웹 개발	AI 개발	Langfuse
Access Log	LLM 요청	Trace
API 호출	Model 호출	Generation
SQL 실행	RAG 검색	Span
사용자 Session	AI 대화	Session
APM	LLM Observability	Langfuse
테스트	AI 품질 평가	Evaluation
Git	Prompt 버전	Prompt Management
성능 모니터링	Token/Latency/Cost	Dashboard

즉,

text

일반 애플리케이션
        │
        ├── 로그
        ├── APM
        ├── DB 모니터링
        └── 테스트

를 AI 애플리케이션에서는

text

AI Application
      │
      ▼
   Langfuse
      │
      ├── Trace
      ├── Prompt
      ├── Token
      ├── Cost
      ├── Latency
      ├── Evaluation
      ├── Dataset
      └── Experiment

처럼 관리할 수 있습니다.

3. Langfuse가 특히 AI 개발에서 중요한 이유

LLM은 일반적인 프로그램과 다릅니다.

일반 프로그램:

text

입력 A
 ↓
항상 같은 코드
 ↓
결과 B

LLM:

text

입력
 ↓
Prompt
 ↓
Model
 ↓
Context
 ↓
RAG
 ↓
Tool
 ↓
LLM
 ↓
확률적인 결과

즉, 결과가 항상 동일하지 않습니다.

그래서 AI 개발에서는

"코드가 실행됐는가?"

보다

"AI가 왜 이런 답을 만들었는가?"

가 중요합니다.

Langfuse의 Tracing은 이러한 AI 애플리케이션의 실행 과정을 구조적으로 기록하기 위해 만들어졌습니다. (Langfuse)

4. Langfuse의 전체 구조

AI 시스템을 다음과 같이 생각하면 됩니다.

text

                    ┌──────────────┐
                    │    사용자    │
                    └──────┬───────┘
                           │
                           ▼
                 ┌─────────────────┐
                 │ AI Application  │
                 │                 │
                 │ Spring / Node   │
                 │ Python / Agent  │
                 └────────┬────────┘
                          │
              ┌───────────┼───────────┐
              │           │           │
              ▼           ▼           ▼
           Prompt       RAG         Tool
              │           │           │
              └───────────┼───────────┘
                          ▼
                    ┌──────────┐
                    │   LLM    │
                    └────┬─────┘
                         │
                         ▼
                  ┌──────────────┐
                  │   Langfuse   │
                  ├──────────────┤
                  │ Trace        │
                  │ Prompt       │
                  │ Token        │
                  │ Cost         │
                  │ Latency      │
                  │ Evaluation   │
                  └──────────────┘

Langfuse는 SDK, OpenTelemetry, 다양한 프레임워크 통합 및 LiteLLM 같은 LLM Gateway를 통해 Trace를 수집할 수 있습니다. (Langfuse)

5. 가장 먼저 알아야 할 핵심 용어

Langfuse를 처음 사용할 때 아래 6개만 먼저 이해하면 됩니다.

5.1 Trace

한 번의 AI 요청 전체 과정

예:

text

Trace
│
├── 사용자 질문
│
├── RAG 검색
│
├── Prompt 생성
│
├── LLM 호출
│
└── 최종 답변

예를 들어:

text

"삼성전자의 현재 주가는?"

라는 질문 하나가 하나의 Trace가 될 수 있습니다.

6. Observation

Trace 안에서 발생한 개별 작업입니다.

예:

text

Trace
│
├── Retrieval
│
├── Prompt
│
├── LLM Generation
│
└── Tool Call

Langfuse의 현재 데이터 모델에서는 개별 작업을 Observation으로 다루며, 여러 Observation이 trace_id로 하나의 Trace에 묶입니다. (Langfuse)

쉽게 말하면:

text

Trace = 한 번의 업무

Observation = 그 업무 안에서 한 단계

7. Generation

LLM 모델을 실제로 호출한 작업입니다.

예:

text

Generation

Model:
gpt-5.x

Input:
"대한민국의 수도는?"

Output:
"서울입니다."

Input Tokens:
120

Output Tokens:
20

Latency:
850 ms

Cost:
$0.00x

AI 개발자에게 가장 중요한 Observation 중 하나입니다.

8. Session

여러 Trace를 하나의 대화 또는 사용자 작업으로 묶습니다.

예:

text

Session: user-123

 ├── Trace 1
 │   "안녕하세요"
 │
 ├── Trace 2
 │   "서울의 날씨는?"
 │
 └── Trace 3
     "내일은?"

즉:

text

Observation
     ↓
Trace
     ↓
Session

구조로 생각하면 쉽습니다.

9. 설치 방법

Langfuse를 사용하는 방법은 크게 두 가지입니다.

text

방법 1
Langfuse Cloud

방법 2
Self-hosted
Docker

처음 공부하는 경우에는 Cloud가 가장 쉽습니다.

회사 내부 데이터나 자체 인프라에서 운영하려면 Self-hosted를 선택할 수 있습니다.

Langfuse는 공식적으로 Cloud와 Self-hosting을 모두 지원합니다. (Langfuse)

10. 방법 A — Langfuse Cloud

가장 간단한 방법입니다.

공식 사이트:

https://langfuse.com/

회원가입 후 Project를 생성합니다.

Project를 만들면 다음과 같은 인증정보를 받습니다.

text

LANGFUSE_PUBLIC_KEY
LANGFUSE_SECRET_KEY
LANGFUSE_BASE_URL

예:

text

LANGFUSE_PUBLIC_KEY=pk-lf-xxxx
LANGFUSE_SECRET_KEY=sk-lf-xxxx
LANGFUSE_BASE_URL=https://cloud.langfuse.com

공식 SDK는 이 환경변수를 사용하여 Trace를 Langfuse로 전송합니다. (Langfuse)

11. 방법 B — Docker로 Self-hosting

개발 서버에 Docker가 설치되어 있다면 직접 실행할 수 있습니다.

공식 저장소:

https://github.com/langfuse/langfuse

text

git clone --depth=1 https://github.com/langfuse/langfuse.git

cd langfuse

docker compose up

공식 저장소에서도 Docker Compose를 이용한 로컬 실행 방법을 제공하고 있습니다. (GitHub)

실행하면 Langfuse뿐 아니라 필요한 데이터 저장 계층도 함께 구성됩니다.

현재 Langfuse v4 Docker 구성에는 PostgreSQL, ClickHouse, Redis, MinIO 등의 구성요소가 사용됩니다. (GitHub)

12. Self-hosted 구조를 이해하자

대략적으로:

text

                Langfuse Web
                     │
                     ▼
              ┌─────────────┐
              │  Langfuse   │
              │ Application  │
              └──────┬──────┘
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
 PostgreSQL      ClickHouse      Redis
       │
       │
       └────────── MinIO

각 구성요소의 역할을 아주 단순하게 생각하면:

text

PostgreSQL
→ 애플리케이션 설정/메타데이터

ClickHouse
→ 대량의 관측 데이터 분석

Redis
→ Queue / Cache 등

MinIO
→ Object Storage

실제 운영에서는 공식 Self-hosting 문서의 버전 및 구성요건을 따라가는 것이 좋습니다. (Langfuse)

13. 첫 번째 AI 프로그램 연결하기

이제 진짜 중요한 부분입니다.

예제로 Python을 사용하겠습니다.

설치:

text

pip install langfuse

현재 Langfuse 공식 Getting Started에서도 Python SDK 설치 방식으로 pip install langfuse를 안내합니다. (Langfuse)

14. 환경변수 설정

.env

text

LANGFUSE_PUBLIC_KEY=pk-lf-xxxx
LANGFUSE_SECRET_KEY=sk-lf-xxxx
LANGFUSE_BASE_URL=https://cloud.langfuse.com

중요:

text

Secret Key

는 절대로 Git에 올리면 안 됩니다.

15. OpenAI 호출 추적하기

Langfuse는 OpenAI SDK와 쉽게 연결할 수 있습니다.

개념적으로:

text

기존 코드

Application
   ↓
OpenAI

를

text

Application
   ↓
Langfuse Instrumentation
   ↓
OpenAI

로 만드는 것입니다.

Langfuse 공식 문서에서는 OpenAI SDK를 거의 Drop-in 방식으로 연결하여 Model 호출을 자동 추적할 수 있도록 제공합니다. (Langfuse)

16. 가장 중요한 것은 코드가 아니라 Trace

AI 애플리케이션을 실행한 후 Langfuse 화면을 열어보면 다음과 같은 정보를 확인할 수 있습니다.

text

Trace
────────────────────────

Input
"대한민국의 수도는?"

Model
gpt-5.x

Prompt
...

Output
"서울입니다."

Latency
850 ms

Tokens
...

Cost
...

이제부터 AI 개발이 달라집니다.

기존:

text

AI가 이상하게 답했다.

에서

text

왜 이상하게 답했는지 확인한다.

로 바뀝니다.

17. RAG를 사용하면 Langfuse의 가치가 더 커진다

AI 서비스가 RAG를 사용한다고 생각해봅시다.

text

사용자 질문
     ↓
Embedding
     ↓
Vector DB
     ↓
문서 검색
     ↓
Prompt 생성
     ↓
LLM
     ↓
답변

답변이 잘못되었습니다.

그런데 원인이 무엇인지 모릅니다.

가능성은 여러 가지입니다.

text

① 검색이 잘못됨
② 검색 결과가 부족함
③ Prompt가 잘못됨
④ Context가 잘림
⑤ LLM이 잘못 해석함
⑥ Model 자체의 문제

Langfuse Trace를 보면:

text

Trace
│
├── Embedding
│
├── Retrieval
│     └── 검색된 문서
│
├── Prompt
│
├── Generation
│
└── Final Answer

처럼 전체 과정을 볼 수 있습니다.

이것이 LLM Observability의 핵심 가치입니다.

18. Agent를 사용하면 더욱 중요하다

Agent는 더 복잡합니다.

text

사용자
 ↓
Agent
 ↓
LLM
 ↓
Tool 선택
 ↓
검색 API
 ↓
LLM
 ↓
Database
 ↓
LLM
 ↓
최종 답변

일반 로그만 보면 상당히 어렵습니다.

Langfuse에서는 이런 여러 단계를 Trace와 Observation으로 연결하여 Agent 실행 과정을 볼 수 있습니다. (Langfuse)

19. Prompt Management

Langfuse를 단순 로그 시스템으로만 사용하면 절반만 사용하는 것입니다.

Langfuse의 중요한 기능 중 하나가 Prompt Management입니다.

예를 들어 코드에 직접:

text

너는 전문 금융 분석가다.
...

라고 작성하지 않고 Langfuse에서 관리합니다.

text

Prompt: stock-analysis

Version 1
Version 2
Version 3
Version 4

이렇게 Prompt를 버전 관리할 수 있습니다.

Langfuse는 Prompt를 버전별로 관리하고 Trace와 연결하여 어떤 Prompt 버전이 어떤 결과를 냈는지 비교할 수 있습니다. (Langfuse)

20. 왜 Prompt 버전 관리가 필요한가?

예를 들어:

text

v1
정중하게 답변하세요.

v2
전문가 수준으로 답변하세요.

v3
전문가 수준으로 답변하되
초보자가 이해할 수 있도록 설명하세요.

v3가 가장 좋은 결과를 냈다고 합시다.

그런데 개발자가 코드를 수정하다가 Prompt를 바꿔버립니다.

그러면 문제가 생깁니다.

text

어떤 Prompt가 좋은 결과를 만들었는가?

Langfuse를 사용하면:

text

Prompt v1
   ↓
결과 / 비용 / 평가

Prompt v2
   ↓
결과 / 비용 / 평가

Prompt v3
   ↓
결과 / 비용 / 평가

를 비교할 수 있습니다.

21. Model 비교

AI 시스템에서는 Model도 계속 바뀝니다.

예:

text

GPT
Claude
Gemini
Qwen
Llama
DeepSeek

또는 자체 서버:

text

vLLM
 ↓
Qwen
Llama
DeepSeek

이런 구조가 될 수 있습니다.

Langfuse에서는 Model별 Trace를 비교할 수 있습니다.

예:

Model	품질	평균 Latency	비용
Model A	91	800ms	$0.02
Model B	94	1200ms	$0.04
Model C	88	500ms	$0.01

그러면 단순히

"이 모델이 더 좋아 보인다."

가 아니라

"품질 3점 상승을 위해 비용 2배를 지불할 가치가 있는가?"

라는 엔지니어링 판단을 할 수 있습니다.

22. Token과 Cost를 왜 봐야 하는가?

LLM은 일반 API와 다르게 사용량에 따라 비용이 발생하는 경우가 많습니다.

예:

text

사용자 질문
+
System Prompt
+
RAG Context
+
Conversation History

이것들이 모두 Token을 증가시킵니다.

결국:

text

Prompt가 길어짐
      ↓
Input Token 증가
      ↓
비용 증가
      ↓
Latency 증가

Langfuse에서는 Token Usage와 비용을 추적하여 이러한 문제를 분석할 수 있습니다. (Langfuse)

23. Latency 분석

AI 서비스가 느립니다.

그런데 어디가 느린지 모릅니다.

Langfuse Trace를 보면:

text

전체 요청
  3.8 sec
     │
     ├── DB 검색
     │    100ms
     │
     ├── Vector Search
     │    300ms
     │
     ├── LLM
     │    3,200ms
     │
     └── 후처리
          200ms

처럼 병목을 찾을 수 있습니다.

그러면:

text

DB 문제인가?
RAG 문제인가?
LLM 문제인가?
Network 문제인가?

를 구분할 수 있습니다.

24. Evaluation — AI에게도 테스트가 필요하다

전통적인 개발:

text

JUnit
   ↓
테스트
   ↓
Pass / Fail

AI 개발:

text

LLM
 ↓
답변
 ↓
좋은 답인가?

문제가 있습니다.

LLM 답변은 단순한 문자열 비교만으로 평가하기 어렵습니다.

예:

text

정답:
"서울"

AI:
"대한민국의 수도는 서울입니다."

문자열은 다르지만 정답입니다.

따라서 AI에서는 별도의 Evaluation이 필요합니다.

Langfuse는 LLM-as-a-Judge, 코드 기반 평가, 사용자 피드백, 수동 평가, Dataset/Experiment 등의 평가 방법을 제공합니다. (Langfuse)

25. 가장 쉬운 Evaluation

예를 들어 AI 답변에 다음과 같은 Score를 줄 수 있습니다.

text

정확성
0 ~ 1

관련성
0 ~ 1

친절성
0 ~ 1

예:

text

Trace #1234

Accuracy
0.95

Relevance
0.91

Helpfulness
0.88

이런 데이터가 쌓이면 Prompt나 Model을 변경했을 때 품질이 좋아졌는지 확인할 수 있습니다.

26. LLM-as-a-Judge

사람이 모든 답변을 직접 평가할 수 없습니다.

그래서 다른 LLM에게 평가를 시킬 수 있습니다.

text

Model A
 ↓
답변 생성

Model B
 ↓
Model A의 답변 평가

예:

text

질문:
"대한민국 수도는?"

답변:
"서울입니다."

Judge:
정확성 = 1.0

이것이 LLM-as-a-Judge입니다.

Langfuse는 이를 온라인/오프라인 Evaluation 흐름에 사용할 수 있습니다. (Langfuse)

27. Dataset

좋은 질문과 정답을 모아놓습니다.

예:

text

Dataset: stock-qa

1.
질문: 삼성전자 본사는?
정답: 수원

2.
질문: 현대자동차 본사는?
정답: 서울

3.
질문: ...

이것을 AI 애플리케이션의 테스트 데이터로 사용할 수 있습니다.

28. Experiment

이제 Prompt를 변경해 봅니다.

text

Prompt v1
vs
Prompt v2

같은 Dataset에 실행합니다.

text

              Accuracy

Prompt v1       87%
Prompt v2       93%

그러면 Prompt v2가 실제로 좋아졌다는 것을 데이터로 확인할 수 있습니다.

Langfuse는 Dataset과 Experiment를 이용해 이런 개발 단계의 반복적인 비교 평가를 지원합니다. (Langfuse)

29. 여기까지를 하나의 개발 사이클로 보면

Langfuse의 진짜 가치는 다음 사이클입니다.

text

             ┌─────────────┐
             │   개발한다  │
             └──────┬──────┘
                    ↓
             ┌─────────────┐
             │   Trace     │
             └──────┬──────┘
                    ↓
             ┌─────────────┐
             │    분석     │
             └──────┬──────┘
                    ↓
             ┌─────────────┐
             │ Prompt 개선 │
             └──────┬──────┘
                    ↓
             ┌─────────────┐
             │   Evaluate  │
             └──────┬──────┘
                    ↓
             ┌─────────────┐
             │   Deploy    │
             └──────┬──────┘
                    │
                    └──────────→ 다시 Trace

즉:

개발 → 관찰 → 분석 → 개선 → 평가 → 배포 → 다시 관찰

이 반복 구조를 만드는 것이 Langfuse입니다.

30. LiteLLM과 Langfuse는 어떤 관계인가?

이 부분은 AI 플랫폼을 설계할 때 매우 중요합니다.

둘은 경쟁 제품이라기보다 역할이 다릅니다.

text

                  AI Application
                         │
                         ▼
                     LiteLLM
                  LLM Gateway
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
        OpenAI         vLLM           Gemini
          │              │              │
          └──────────────┼──────────────┘
                         │
                         ▼
                     Langfuse
                   Observability

쉽게 말하면:

text

LiteLLM
→ "어떤 모델에게 요청할 것인가?"

Langfuse
→ "무슨 일이 일어났는가?"

입니다.

LiteLLM은 여러 LLM Provider와 모델을 하나의 Gateway 형태로 다루는 데 사용하고, Langfuse는 그 호출을 관찰하고 분석하는 데 사용합니다.

Langfuse 공식 문서에서도 LiteLLM 같은 LLM Gateway를 통한 Trace 수집을 지원합니다. (Langfuse)

31. vLLM과 Langfuse

vLLM은 역할이 또 다릅니다.

text

vLLM
→ GPU에서 LLM 추론을 빠르게 실행하는 서버 엔진

LiteLLM
→ 여러 모델을 하나의 API Gateway로 통합/라우팅

Langfuse
→ LLM 호출을 기록하고 분석/평가

전체 구조:

text

                    Application
                         │
                         ▼
                    LiteLLM
                  정책 / Routing
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
            vLLM                 External
              │                   Models
              ▼
         Local LLM
              │
              └──────────┬──────────┘
                         ▼
                     Langfuse
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
        Trace          Cost          Evaluation

이 구조는 AI 플랫폼을 직접 구축할 때 상당히 자연스러운 형태입니다.

32. Semantic Router와 함께 생각하면

앞서 이야기한 구조까지 합치면:

text

                         사용자
                           │
                           ▼
                  ┌─────────────────┐
                  │ Policy Engine   │
                  │ 보안/권한/정책   │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │ Semantic Router │
                  │ 의도/도메인 분류 │
                  └────────┬────────┘
                           │
                           ▼
                     ┌───────────┐
                     │ RouteLLM  │
                     │ 모델 선택 │
                     └─────┬─────┘
                           │
                           ▼
                     ┌───────────┐
                     │  LiteLLM  │
                     │ LLM Gateway│
                     └─────┬─────┘
                           │
             ┌─────────────┼──────────────┐
             ▼             ▼              ▼
           vLLM         OpenAI         Gemini
             │             │              │
             └─────────────┼──────────────┘
                           ▼
                      Langfuse
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
            Trace        Cost       Evaluation

각자의 역할이 명확합니다.

구성요소	한마디 역할
Policy Engine	해도 되는 요청인가?
Semantic Router	무슨 종류의 요청인가?
RouteLLM	어떤 모델이 적합한가?
LiteLLM	모델 호출을 어떻게 통합할 것인가?
vLLM	로컬 GPU에서 모델을 어떻게 실행할 것인가?
Langfuse	실제로 무슨 일이 일어났는가?

33. 처음부터 모든 기능을 사용할 필요는 없다

AI 초보 개발자라면 다음 순서가 좋습니다.

Level 1

text

LLM 호출
+
Langfuse Trace

먼저 이것만 합니다.

Level 2

text

Trace
+
Token
+
Latency
+
Cost

AI 시스템의 실제 사용량을 파악합니다.

Level 3

text

Prompt Management

Prompt를 코드에서 분리합니다.

Level 4

text

RAG
+
Trace

검색 결과와 LLM 응답을 연결합니다.

Level 5

text

Evaluation
+
Dataset

AI 품질을 수치화합니다.

Level 6

text

Experiment
+
Model 비교
+
Prompt 비교

본격적인 AI Engineering을 시작합니다.

Level 7

text

LiteLLM
+
vLLM
+
Semantic Router
+
Policy Engine
+
Langfuse

AI 플랫폼 아키텍처 수준으로 발전합니다.

34. 처음 개발할 때 추천하는 프로젝트 구조

예를 들어 Node.js/TypeScript라면:

text

ai-service/
│
├── src/
│   ├── llm/
│   │   ├── client.ts
│   │   └── model.ts
│   │
│   ├── prompt/
│   │   └── prompt.ts
│   │
│   ├── rag/
│   │   └── retrieval.ts
│   │
│   ├── agent/
│   │   └── agent.ts
│   │
│   └── evaluation/
│       └── evaluator.ts
│
├── .env
├── package.json
└── README.md

그리고:

text

Application
    │
    ├── Prompt
    │
    ├── RAG
    │
    ├── Agent
    │
    └── LLM
          │
          ▼
      Langfuse

로 Trace를 남깁니다.

35. 개발자가 Langfuse 화면에서 가장 먼저 봐야 할 것

처음 접속하면 기능이 많아 보이지만 우선 다음 순서로 보세요.

① Traces

text

내 AI 요청이 실제로 어떻게 실행됐는가?

② Generations

text

어떤 Model이 호출됐는가?

③ Latency

text

어디에서 시간이 걸렸는가?

④ Token / Cost

text

얼마나 비싼가?

⑤ Prompt

text

어떤 Prompt를 사용했는가?

⑥ Evaluation

text

답변 품질은 좋은가?

36. AI 개발자가 반드시 가져야 할 사고방식

전통적인 개발에서는:

text

Code
 ↓
Test
 ↓
Deploy

가 중요합니다.

AI 개발에서는:

text

Code
 ↓
Prompt
 ↓
Model
 ↓
Context
 ↓
Trace
 ↓
Evaluation
 ↓
Improve

가 중요합니다.

즉 AI 개발은 단순히

"LLM API를 호출하는 개발"

이 아닙니다.

진짜 AI Engineering은:

LLM이 어떤 과정을 거쳐 결과를 만들었는지 관찰하고, 그 결과를 측정하고, 더 좋은 결과를 반복적으로 만들어가는 과정

입니다.

37. Langfuse를 한 문장으로 다시 정리

처음에는 이렇게 기억하면 됩니다.

text

Langfuse
=
AI 애플리케이션의 관찰 카메라

조금 더 정확하게 표현하면:

text

Langfuse
=
Tracing
+ Prompt Management
+ Cost/Latency Analysis
+ Evaluation
+ Dataset
+ Experiment
+ Feedback

공식적으로도 Langfuse는 Observability, Prompt Management, Evaluation을 AI 개발 lifecycle의 핵심 기능으로 제공하고 있습니다. (Langfuse)

38. 최종적으로 만들고 싶은 구조

AI 플랫폼을 장기적으로 구축한다면 다음 구조를 목표로 하면 좋습니다.

text

                         ┌─────────────┐
                         │    User     │
                         └──────┬──────┘
                                │
                                ▼
                     ┌──────────────────┐
                     │  API / Backend   │
                     └────────┬─────────┘
                              │
                              ▼
                     ┌──────────────────┐
                     │  Policy Engine   │
                     └────────┬─────────┘
                              │
                              ▼
                     ┌──────────────────┐
                     │ Semantic Router  │
                     └────────┬─────────┘
                              │
                              ▼
                     ┌──────────────────┐
                     │    RouteLLM      │
                     └────────┬─────────┘
                              │
                              ▼
                     ┌──────────────────┐
                     │     LiteLLM      │
                     │   LLM Gateway    │
                     └────────┬─────────┘
                              │
                ┌─────────────┼─────────────┐
                ▼             ▼             ▼
             ┌──────┐     ┌──────┐     ┌──────┐
             │ vLLM │     │OpenAI│     │Gemini│
             └──┬───┘     └──┬───┘     └──┬───┘
                │             │             │
                └─────────────┼─────────────┘
                              │
                              ▼
                     ┌──────────────────┐
                     │     Langfuse     │
                     ├──────────────────┤
                     │ Trace            │
                     │ Prompt           │
                     │ Token            │
                     │ Cost             │
                     │ Latency          │
                     │ Evaluation       │
                     │ Dataset          │
                     │ Experiment       │
                     └──────────────────┘

이 구조를 이해하면 각각의 도구가 왜 필요한지 자연스럽게 연결됩니다.

39. 입문자가 실제로 따라 할 순서

다음 순서대로 진행하면 됩니다.

40. 가장 중요한 결론

AI 개발을 처음 시작한다면 Langfuse를 처음부터 넣는 것을 권장합니다.

이유는 단순합니다.

text

Langfuse가 없으면

"AI가 이상하다."
        ↓
     추측한다.

Langfuse가 있으면:

text

"AI가 이상하다."
        ↓
Trace 확인
        ↓
Prompt 확인
        ↓
RAG 확인
        ↓
Model 확인
        ↓
Token 확인
        ↓
Latency 확인
        ↓
Evaluation 확인
        ↓
원인 발견
        ↓
개선

즉 Langfuse는 AI의 결과를 보는 도구가 아니라 AI가 결과를 만드는 과정을 이해하기 위한 도구라고 생각하는 것이 가장 좋습니다.

그리고 앞으로 구축하려는 AI 플랫폼에서 역할을 구분하면 아주 명확합니다.

text

Policy Engine
    = 정책

Semantic Router
    = 의도 분류

RouteLLM
    = 모델 선택

LiteLLM
    = 모델 호출 Gateway

vLLM
    = 모델 실행 엔진

Langfuse
    = 관찰 + 분석 + 평가

이 6개를 하나의 시스템으로 연결하면 단순한 "LLM API 호출 프로그램"에서 관리 가능한 AI 플랫폼으로 발전시킬 수 있습니다.

공식 자료

특히 지금 단계에서는 Trace → Prompt → Cost/Latency → Evaluation 이 네 가지를 먼저 익히는 것이 좋습니다. 그다음에 지금 앞서 이야기했던 Policy Engine + Semantic Router + RouteLLM + LiteLLM + vLLM + Langfuse를 실제 Docker 기반으로 하나씩 연결하면 전체 AI 플랫폼 구조가 훨씬 쉽게 이해됩니다.

AI 개발자를 위한 Langfuse 입문부터 실전까지

중년개발자