서버리스부터 LLM 에이전트까지: 분산 시스템의 블랙박스를 여는 관측성(Observability) 아키텍처 가이드

서버리스부터 LLM 에이전트까지: 분산 시스템의 블랙박스를 여는 관측성(Observability) 아키텍처 가이드

"어디서 터졌는지"를 아는 것과, "왜 그렇게 터졌는지"를 아는 것은 완전히 다른 차원의 문제입니다.

최근의 IT 인프라는 그 어느 때보다도 복잡해졌습니다. 전통적인 단일 서버 애플리케이션은 사라지고, 서버리스 함수, 엣지 컴퓨팅 노드, 그리고 비결정론적인 LLM 에이전트가 엮인 거대한 마이크로서비스 생태계가 주류가 되었습니다. 이 복잡성은 엄청난 유연성과 확장성을 가져다주었지만, 동시에 운영 측면에서는 거대한 '블랙박스'를 만들어냈습니다.

단순히 CPU 사용률이 100%인지, 메모리가 부족한지 확인하는 기존의 모니터링(Monitoring) 방식으로는 더 이상 충분하지 않습니다. 요청이 A 서비스에서 시작해, 큐를 거쳐, 서버리스 함수를 호출하고, 외부 LLM API를 거쳐 최종 사용자에게 돌아오는 이 복잡한 여정 속에서, 병목 지점이나 근본 원인(Root Cause)을 찾아내는 것은 마치 미로 속에서 실마리를 찾는 것과 같습니다.

이 글은 바로 그 '블랙박스'를 열어, 시스템의 모든 단계를 투명하게 추적할 수 있는 완벽한 관측성(Observability) 아키텍처 구축 로드맵을 제시합니다. 백엔드 아키텍트, 시니어 개발자, DevOps 엔지니어라면 반드시 숙지해야 할 내용을 담았습니다.

🔍 모니터링을 넘어, 관측성(Observability)으로의 전환

가장 먼저 용어의 정의를 명확히 할 필요가 있습니다. 많은 분들이 이 두 개념을 혼용합니다.

**모니터링(Monitoring)**은 "미리 정해진 지표(Metric)가 기준치를 벗어났을 때 알려주는 것"에 가깝습니다. (예: "CPU 사용량이 90%를 넘었습니다. 경고!") 이는 사후 대응적이며, '무엇이 잘못되었는지'에 초점을 맞춥니다.

반면, **관측성(Observability)**은 시스템의 내부 상태를 외부에서 관찰하여, 아직 예상치 못한 문제가 발생했을 때도 그 원인을 추론해낼 수 있는 능력을 의미합니다. 이는 시스템의 동작 원리 자체를 이해하고, '왜 이런 현상이 발생했는지'를 파고드는 능동적인 접근 방식입니다.

관측성은 다음 세 가지 핵심 축을 통해 구현됩니다.

1. Metrics (지표): 시간에 따른 수치 변화를 추적합니다. (예: 초당 요청 수(RPS), 평균 응답 시간(Latency)). 무엇이 얼마나 많이 일어났는가?
2. Logs (로그): 특정 시점에 발생한 이벤트의 기록입니다. (예: "사용자 ID 123이 로그인에 실패함.") 언제 어떤 일이 일어났는가?
3. Traces (추적): 하나의 요청이 시스템의 여러 컴포넌트를 거치는 전체 경로를 시각화합니다. 어떤 경로를 거쳐서, 어느 단계에서 시간이 지연되었는가?

분산 시스템에서 가장 중요한 것은 바로 이 Traces입니다. 요청이 A $\rightarrow$ B $\rightarrow$ C 순서로 간다고 가정해 봅시다. A와 B가 모두 정상 응답 코드를 반환했더라도, C에서 3초가 걸렸다면, 이 3초의 병목 지점을 정확히 짚어낼 수 있어야 합니다. 이것이 트레이싱이 제공하는 가치입니다.

🛠️ 핵심 툴 비교 분석: Prometheus, Jaeger, 그리고 OpenTelemetry

관측성을 구현하기 위해 시장에는 수많은 툴이 존재합니다. 하지만 이들을 효과적으로 사용하려면 각 툴의 역할을 명확히 이해해야 합니다.

💡 OpenTelemetry: 모든 것을 하나로 묶는 '언어'

Prometheus와 Jaeger는 각자의 영역에서 최고입니다. Prometheus는 '숫자'에, Jaeger는 '흐름'에 특화되어 있죠. 하지만 이 둘을 사용하려면, 각 서비스마다 데이터를 수집하는 방식이 다르고, 데이터 포맷도 다릅니다. 이것이 바로 운영의 복잡성을 가중시키는 원인입니다.

**OpenTelemetry(OTel)**는 이 문제를 해결하기 위해 등장했습니다. OTel은 단순히 라이브러리라기보다는, **분산 시스템에서 발생하는 모든 관측성 데이터를 수집하고, 표준화된 포맷(Context, Span, Attribute)으로 변환하는 '표준화된 데이터 포맷 및 API'**입니다.

OTel을 사용하면, 어떤 언어(Python, Go, Java)로 작성된 서비스든, 어떤 클라우드 환경(AWS, GCP, On-Premise)에서 돌아가든, 동일한 방식으로 트레이스 데이터를 생성할 수 있게 됩니다. 이것이 바로 Vendor Lock-in을 방지하는 핵심 열쇠입니다.

🚀 실전 아키텍처: LLM 서비스의 트레이싱 예시

최근 LLM 기반 서비스는 복잡한 호출 체인(Chain)을 가집니다. 사용자의 요청이 들어오면, **[프롬프트 전처리] $\rightarrow$ [벡터 DB 검색] $\rightarrow$ [LLM 호출] $\rightarrow$ [후처리]**와 같은 여러 단계가 순차적으로 발생합니다.

이 복잡한 흐름을 추적(Tracing)하는 것이 핵심입니다.

1. 문제: 각 단계가 독립적인 API 호출로 이루어져 있어, 어느 단계에서 병목 현상이 발생하는지 알기 어렵습니다.
2. 해결: OTel(OpenTelemetry) 표준을 사용하여, 모든 호출을 하나의 Trace ID로 묶습니다.
3. 결과: 트레이싱 뷰어에서 전체 요청의 흐름(Span)을 한눈에 파악할 수 있으며, 가장 시간이 오래 걸린 Span(예: 벡터 DB 검색)을 즉시 식별하고 최적화할 수 있습니다.

이것이 바로 현대 분산 시스템에서 관찰 가능성(Observability)을 확보하는 핵심입니다.

요약 및 실천 가이드

결론적으로, 현대의 분산 시스템 개발자는 '어떻게 코드를 짤까'를 넘어, '어떻게 이 코드가 동작하는 과정을 완벽하게 관찰할까'에 초점을 맞춰야 합니다. OTel 표준을 도입하여 모든 서비스 호출에 트레이싱을 적용하는 것이 가장 중요한 첫걸음입니다.