PM, 창업자, 그리고 "블랙박스(black box)"라는 말에 지친 모든 이들을 위한 관측성 (observability) 쉬운 설명 가이드.

당신의 회사가 운영하는 AI는 블랙박스입니다. 인상적인 공상 과학 영화 같은 방식이 아닙니다. 지루하고 비용이 많이 드는 방식이죠. 고객이 챗봇이 이상한 답변을 했다고 말하거나, "요약" 버튼을 누르는 데 11초가 걸렸다고 하는데, 아무도 그 이유를 설명하지 못하는 상황 말입니다. 요청(Request)은 들어가고 답변(Answer)은 나오지만, 그 중간 과정은 모두가 조용히 파헤치기를 포기하기로 합의한 미스터리 영역으로 남습니다.

여기 아무도 쉬운 언어로 설명해주지 않는 부분이 있습니다. 그 상자를 열기 위해 만들어진 소프트웨어 카테고리가 통째로 존재하며, 그 이름은 아주 투박합니다. 바로 관측성 (observability) 입니다. 이름은 끔찍하지만, 개념은 단순하며, 한 번 이해하고 나면 이전으로 돌아갈 수 없습니다.

커피를 마시며 친구에게 설명하듯 보여드리겠습니다. 코드 없이, 스크린샷 하나씩, 처음부터 끝까지 하나의 비교를 통해 설명하겠습니다.

하나의 비교로 이해하는 전체 개념

대시보드를 테이프로 가리고 앞 유리를 검게 칠한 자동차를 운전하지는 않을 것입니다. 속도계도, 연료 게이지도, 엔진 체크 경고등도 없으며, 얼마나 빨리 가고 있는지 혹은 엔진에 불이 붙었는지조차 알 수 없습니다. 그런 상태로 고속도로에 합류한다면 제정신이 아닐 것입니다.

대부분의 팀이 AI를 운영하는 방식이 바로 이와 같습니다.

관측성 (observability)은 단지 대시보드를 다시 설치하는 것뿐입니다. 현재 시스템이 어떻게 작동하고 있는지 알려주는 계기판 세트이자, 모든 여정을 조용히 기록하는 블랙박스(dashcam)를 갖추는 것입니다. 그래야 문제가 발생했을 때 추측하는 대신, 영상을 되감아 정확히 무슨 일이 일어났는지 확인할 수 있습니다.

그게 전부입니다. 나머지는 세 개의 화면을 읽는 법을 배우는 과정일 뿐입니다.

화면 1: 단일 요청의 블랙박스 재생

엔지니어들은 이를: 트레이스 (trace)라고 부릅니다.
실제로는: 단일 여정의 블랙박스 영상입니다.

누군가 당신의 AI에게 질문을 던졌습니다. 이것은 그 질문 하나가 시작부터 끝까지 거쳐온 여정의 기록입니다. 각 막대(bar)는 여정의 한 구간을 나타냅니다. 맨 위의 막대는 전체 주행 경로이며, 그 아래에 중첩된 막대는 AI 모델에서의 실제 정지 지점이고, 그 길이는 해당 정지에 소요된 시간입니다.

이것을 읽기 위해 코드를 읽을 필요는 없습니다. 블랙박스 영상이 당신이 정확히 어디에서 교통 체증을 겪었는지 보여주는 것과 마찬가지로, 시간이 어디에 쓰였는지 한눈에 확인할 수 있습니다. 만약 모델 막대가 길다면, 모델이 느렸던 것입니다. 만약 구간이 누락되었거나 빨간색이라면, 그곳에서 무언가 고장 난 것입니다. 고객이 "2시 14분에 느렸어요"라고 말할 때, 엔지니어는 2시 14분의 영상을 불러오며, 정답은 회의에서 논쟁하는 것이 아니라 밀리초(milliseconds) 단위로 그곳에 명시되어 있습니다.

그것이 바로 "AI가 느린 것 같았다"와 "모델 호출(model call)에 1.1초가 소요되었습니다, 여기 데이터가 있습니다"의 차이입니다.

화면 2: 대시보드 (the dashboard)

엔지니어들이 부르는 명칭: 서비스 대시보드(service dashboard) 또는 APM (Application Performance Monitoring).
실제 정체: 진짜 대시보드. 실시간 게이지.

하나의 트레이스(trace)는 하나의 여정입니다. 이것은 그 모든 여정을 한꺼번에 지켜보는 패널이며, 자동차가 움직이는 동안 당신 앞에 있는 게이지들의 집합입니다. 세 가지가 중요하며, 당신은 이미 이 세 가지를 모두 이해하고 있습니다.

• 얼마나 빠르게 응답하는가 (지연 시간 (latency)). 모두가 주시하는 바늘입니다. 이 수치가 올라가면 제품이 느릿느릿하게 느껴집니다.
• 얼마나 열심히 일하고 있는가 (처리량 (throughput)). RPM처럼 얼마나 많은 요청(requests)이 들어오고 있는지를 나타냅니다.
• 얼마나 뜨겁게 돌아가고 있는가 (에러율 (error rate)). 나쁘게 끝난 여정의 비율입니다. 이는 빨간색을 향해 올라가는 온도계와 같습니다.

안정적이던 바늘이 갑자기 튀어 오르는 것을 알아차리기 위해 "p99"가 무엇인지 알 필요는 없습니다. 그저 움직이는 것을 보기만 하면 됩니다. 이것이 바로 당신의 제품을 위한 게이지 클러스터(gauge cluster)입니다.

화면 3: 엔진 체크 경고등 (the check-engine light)

엔지니어들은 이를 다음과 같이 부릅니다: 경고(alert).
실제로는 이렇습니다: 엔진 체크 경고등(the check-engine light). 당신이 길가에 멈춰 서기 전에 켜지는 바로 그것입니다.

처음 두 개의 화면은 당신이 직접 찾아 나설 때를 위한 것입니다. 이 화면은 당신을 찾아옵니다. 당신이 기준선(line)을 설정하면(

• 완전히 멈추지는 않지만 느려집니다 (slow). 1초 걸리던 모델 호출이 5초가 걸리기 시작합니다. 오류도 없고, 멈춤도 없습니다. 그저 자동차가 미스터리하게 기어가고 있고, 승객들은 조용히 차에서 내릴 뿐입니다.
• 부드럽게 실패합니다 (fails softly). 모델이 타임아웃(timeout)되거나 가드레일(guardrail)이 거부하면, 당신의 앱은 빛을 발하는 대신 어깨를 으쓱하며 대신 밋밋한 결과물을 내놓습니다.
• 환각 (hallucinates)을 일으킵니다. 완벽한 초록색 신호와 함께 자신감 넘치고 틀린 답을 내놓습니다. 내부 시스템(under the hood)의 그 어떤 것도 무엇이 잘못되었는지 인지하지 못합니다.
• 에이전트(Agents)가 상황을 더 악화시킵니다. AI 에이전트가 5단계를 수행하는데 3단계에서 도랑에 빠졌다면, "에이전트가 실수했다"라는 말은 쓸모가 없습니다. 블랙박스(dashcam)는 어떤 입력값으로, 몇 번째 단계에서, 얼마나 오래 머물렀는지를 당신에게 보여줍니다.

계측기(gauges)가 없다면 이 모든 상황은 그저 어쩔 수 없다는 식의 반응(shrug)으로 끝납니다. 하지만 계측기가 있다면, 각각의 상황은 특정 시간에 특정 화면에 나타나는 구체적인 막대그래프가 됩니다. 당신은 무엇이 일어났는지 논쟁하는 것을 멈추고, 문제를 해결하기 시작합니다.

"하지만 실제로 이걸 해보긴 했나요?" 네, 약 15분 정도면 됩니다.

타당한 질문입니다. 밖에서 보기에는 이런 내용들을 쓰기가 쉽기 때문입니다. 그래서 제가 정확히 무엇을 실행했는지 알려드리겠습니다. 명령어를 보는 것만으로 눈이 피로해진다면 이 박스를 건너뛰거나 엔지니어에게 전달해도 좋습니다.

저는 설치 프로그램과 5줄짜리 설정 파일, 그리고 http://localhost:8080에서 실행해 주는 명령어 하나를 사용하여 제 노트북에 SigNoz (오픈 소스 관측성(observability) 도구)를 설치했습니다:

curl -fsSL https://signoz.io/foundry.sh | bash
foundryctl cast -f casting.yaml

그런นั้น, 저는 아주 작은 대역(stand-in) "AI" 서비스를 그곳으로 연결했습니다. 기록 부분은 이를 위한 오픈 표준인 OpenTelemetry를 사용했습니다. 대부분은 자동이며, 코드 변경 없이 실행 명령어 앞에 접두사(prefix)를 붙이는 것만으로 가능합니다:

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
OTEL_SERVICE_NAME=ai-gateway opentelemetry-instrument python app.py

제가 수동으로 추가한 한 가지는 각 호출에 모델 이름과 토큰 수(token counts)를 태깅하는 몇 줄의 코드였습니다. 상단의 블랙박스(dashcam) 스크린샷에 단순히 "a request"가 아닌 gen_ai.request.model이 표시되는 이유가 바로 이것입니다. 이러한 태깅(tagging) 여부가 "무언가가 느렸다"와 "llama-3-8b 호출이 느렸다"를 가르는 차이를 만듭니다. 그 후 트래픽을 보냈고, 의도적으로 호출의 약 6%가 실패하도록 설정한 뒤, "5개 이상의 오류 발생 시"라는 알림(alert) 라인을 하나 설정했습니다. 1분도 채 되지 않아 게이지(gauges)를 포함한 서비스가 자동으로 나타났습니다.

재현할 수 있도록 버전을 명시합니다: SigNoz v0.133.0, OpenTelemetry Python 패키지는 0.65b0입니다. 위의 모든 스크린샷은 마케팅 페이지가 아닌, 실제로 작동 중인 시스템에서 가져온 것입니다. 만약 엔지니어들이 이것이 엄청난 작업(huge lift)이라고 말한다면, 솔직한 버전은 이렇습니다: 대시보드를 설치하는 데는 오후 한나절이면 충분하며, 그 대가는 그 이후의 모든 오후에 돌아옵니다.

다른 것은 다 잊더라도 이것만은 기억하세요

"관측 가능성 (Observability)"는 단순한 약속을 담은 좋지 않은 단어입니다: 당신의 AI가 예상치 못한 행동을 할 때, 당신은 그 이유를 알 수 있게 된다는 것입니다.

게이지를 직접 읽을 필요는 없습니다. 하지만 게이지가 존재한다는 사실을 알고 있어야 하며, 팀에게 당신의 AI 기능에 대해 게이지가 활성화되어 있는지 물어봐야 합니다. 그리고 "그것은 블랙박스(black box)입니다"라는 답변을 더 이상 수용하지 마세요. 왜냐하면 AI는 블랙박스가 아니며, 블랙박스일 필요도 없기 때문입니다. 당신은 결코 눈을 가린 채 운전하지 않을 것입니다. 당신의 AI도 그런 식으로 출시하지 마십시오.

이곳의 스크린샷은 소규모 OpenTelemetry-instrumented 데모를 사용하는 셀프 호스팅(self-hosted) SigNoz에서 가져온 것입니다. 대시보드를 직접 확인하고 싶다면, signoz.io와 opentelemetry.io 두 곳부터 시작해 보시기 바랍니다.