URL: https://www.youtube.com/watch?v=rTojoVotlD8 날짜: 2026-10-03 채널: aiDotEngineer 발표자: Marina Petzel (Datadog) 원문 제목: Your LLM App Returned 200 OK. It Was Still Wrong. — Marina Petzel, Datadog
📌 핵심 질문 / 이 영상이 다루는 핵심 논점
==생성형 AI 애플리케이션은 서버가 200 OK를 반환하고 전통적인 골든 시그널이 정상이어도, 답변의 품질·안전·비용 측면에서 실패할 수 있으므로 비용(cost)·안전(safety)·품질(quality)을 별도의 관측 계층으로 추가해야 한다.==
- 전통적인 애플리케이션은 같은 입력에 같은 출력이 나와 회귀 테스트가 잘 작동하지만, LLM은 같은 프롬프트에도 매번 다른 답을 만들 수 있다.
- 토큰 수, 사용 모델, 컨텍스트 윈도에 따라 비용이 달라지고, 프롬프트 인젝션·PII 유출 같은 공격은 500 오류 없이도 성공할 수 있다.
- 답변의 관련성·정확성·완전성·사용자 만족도는 HTTP 상태 코드만으로 측정할 수 없다.
응답 시간·오류·트래픽·포화도라는 기존 골든 시그널은 계속 필요하다. 다만 생성형 AI의 비결정성, 변동 비용, 새로운 공격면, 주관적인 품질을 다루려면 기존 운영 지표 위에 비용·안전·품질을 측정하는 계층을 더해야 한다.
1. 전통적인 골든 시그널만으로는 부족한 이유
생성형 AI 시스템의 운영 성공 여부는 “서비스가 응답했는가”를 넘어 “얼마나 효율적이고 안전하며 유용한 응답을 냈는가”까지 확인해야 한다.
1.1. 기존 관측의 출발점: LETS 골든 시그널
-
전통적인 애플리케이션의 기본 지표
- 응답 시간(response time): 요청이 얼마나 빨리 처리되는지 측정한다.
- 오류(errors): 애플리케이션이 실패했는지 확인한다.
- 트래픽(traffic): 시스템에 들어오는 요청량을 파악한다.
- 포화도(saturation): 시스템 자원이 얼마나 한계에 가까운지 확인한다.
- LETS라는 묶음: 이 네 가지를 애플리케이션 유효성 판단의 골든 시그널로 사용해 왔다.
-
기존 지표가 여전히 필요한 이유
- 기반 운영성: 생성형 AI 서비스도 느려지거나 오류가 발생하거나 자원을 고갈시킬 수 있으므로 전통 지표를 버릴 수 없다.
- 판단 범위의 한계: 전통 지표는 시스템이 작동하는지 알려주지만, 토큰을 낭비하는지·답변이 안전한지·사용자 질문에 제대로 답했는지는 알려주지 않는다.
1.2. 생성형 AI 애플리케이션의 네 가지 차이
-
비결정적 출력
- 전통 시스템의 예측 가능성: 같은 입력이 들어오면 언제나 같은 출력이 나오는 것을 전제로 한다.
- LLM의 변동성: 같은 프롬프트라도 매번 다른 응답이 나올 수 있다.
- 테스트 방식의 변화: 표준 회귀 테스트만으로는 충분하지 않으며, 실제 운영 환경에서 품질을 계속 평가해야 한다.
-
변동하는 비용 구조
- 기존 컴퓨팅 비용: 실행 코드를 탑재한 장치나 고정된 인프라 비용을 중심으로 예측한다.
- LLM 비용: 입력·출력 토큰 수, 선택한 모델, 컨텍스트 윈도 크기에 따라 매번 달라진다.
- 운영 요구: 지출이 통제 불능으로 늘어나기 전에 실시간 비용 추적이 필요하다.
-
새로운 공격면
- 기존 위협: SQL 인젝션과 크로스 사이트 스크립팅 같은 공격을 주로 걱정했다.
- 생성형 AI 위협: 프롬프트 인젝션(prompt injection), 보호 장치 우회(jailbreak), 개인정보 유출이 새로운 핵심 문제가 됐다.
- 오류 코드의 사각지대: 이런 보안 사고는 서버가 500 오류를 내지 않고 정상 응답을 반환하면서도 발생할 수 있다.
-
주관적인 품질
- 이진 판단의 한계: 전통 시스템은 작동하거나 작동하지 않는 것으로 비교적 명확히 평가한다.
- 연속적인 평가: 생성형 AI 출력은 관련성, 정확성, 완전성, 유해성처럼 여러 축에서 정도의 차이로 평가된다.
- 200 OK의 함정: 서버가 200 OK를 반환해도 답변이 사용자에게 도움이 되지 않거나 사실과 다를 수 있다.
2. 비용 관측: 예산을 초과하기 전에 원인을 찾아라
생성형 AI 비용은 사용자 증가와 대체로 선형적으로 늘어난다는 전통적인 가정에서 벗어나므로, 비용이 어디에서 생기는지 세밀하게 분류해야 한다.
2.1. 비용 폭증을 만드는 세 가지 패턴
-
토큰 크리프(token creep)
- 조용한 컨텍스트 확대: 엔지니어나 제품 관리자가 품질을 높이려고 컨텍스트 윈도를 재무 검토 없이 늘린다.
- 구체적 사례: 4,000토큰 컨텍스트가 32,000토큰으로 늘어나면 사용량과 비용이 최대 8배까지 뛸 수 있다.
- 사업 영향: 이 변화 하나가 매달 수천 달러의 추가 비용으로 이어질 수 있다.
-
모델 드리프트(model drift)
- 모델 교체: 팀이 저렴하고 빠른 Haiku 4.5에서 더 강력하고 비싼 Opus 4.8로 이동한다.
- 품질과 비용의 교환: 더 나은 품질을 기대할 수 있지만 요청당 Opus 비용은 최대 15배 높을 수 있다.
- 숨은 증가: 요청량이 그대로여도 한 달 안에 전체 비용이 급격히 불어날 수 있다.
-
최적화되지 않은 중복 호출
- 캐시 부재: 효과적인 캐싱 계층이 없으면 동일한 질의가 비싼 API를 반복 호출한다.
- 중복 지출: 같은 모델 출력에 반복적으로 비용을 내면서 지출의 상당 부분이 낭비된다.
- 연구 수치: 발표자가 소개한 연구에서는 때때로 전체 지출의 70%가 중복 호출에서 발생한다고 본다.
2.2. 비용 배분을 위한 분류 계층
-
기능(feature) 수준
- 분류 기준: 상호작용이 채팅인지 요약인지처럼 기능의 목적을 태그한다.
- 활용 방법: 제품의 어느 영역이 예산을 소비하는지 파악하고 제품 로드맵의 우선순위를 정한다.
-
사용자(user) 수준
- 식별자 부여: 사용자 ID나 조직명을 호출에 연결한다.
- 비용 회수와 청구: 정확한 과금과 비용 회수가 가능해진다.
- 악용 탐지: 예산을 고갈시키기 전에 비정상적으로 많은 사용 패턴을 빠르게 찾아낸다.
-
모델(model) 수준
- 모델 태깅: GPT-5.5처럼 모델 버전과 OpenAI·Anthropic 같은 제공자를 함께 기록한다.
- 최적화 근거: 모델별 실제 비용을 비교해 값비싼 모델이 정말 필요한 영역인지 판단한다.
-
엔드포인트(endpoint) 수준
- 환경·지역 분류: 호출을 리전과 운영 환경에 연결한다.
- 인프라 계획: 테스트와 프로덕션, 지역별 분포가 전체 지출에 미치는 차이를 파악해 인프라를 계획한다.
3. 안전 관측: 저렴한 시스템도 안전하지 않을 수 있다
비용을 통제해 재무팀을 만족시키더라도, 민감한 정보가 새어 나가면 애플리케이션은 여전히 실패한다. 안전 지표는 매우 엄격한 임계값을 가져야 한다.
3.1. 프롬프트 공격과 보호 장치 우회
-
프롬프트 인젝션 비율
- 측정 대상: 사용자의 지시를 조작하거나 시스템의 의도와 다른 행동을 유도하려는 시도를 감지한다.
- 인프라 조건: 인프라 설계에 안전 제어가 없으면 공격이 통과하므로 애초에 방어 계층을 설계해야 한다.
- 방어 기법: 패턴 매칭과 전문 분류 모델로 의심스러운 입력을 탐지한다.
-
보호 장치 우회 시도
- 공격의 형태: 사용자는 복잡한 시나리오를 만들어 보안 제한을 우회하려고 계속 시도한다.
- 운영 방식: 시스템 요구사항을 넘는 패턴을 명시적으로 정의해 절대적인 차단선으로 취급한다.
- 목표값: 이상적으로는 우회 시도의 100%를 예방한다.
3.2. PII와 유해 콘텐츠
-
개인식별정보 공개율(PII Disclosure Rate)
- 검사 대상: 모델 출력에서 사회보장번호, 신용카드 번호, 기타 개인식별정보를 찾는다.
- 탐지 수단: 정규표현식(regex)과 개체명 인식(named entity recognition)을 사용한다.
- 프로덕션 목표: 프로덕션 출력의 허용 가능한 PII 공개율은 0%다.
-
콘텐츠 안전성
- 평가 질문: 출력이 공격적이거나 유해하거나 특정 주제에 편향돼 있는지 판단한다.
- 측정 수단: 모든 출력을 독성(toxicity) 분류기에 통과시켜 위험 점수를 계산한다.
- 운영 목표: 명확한 임계값을 정하고 유해 콘텐츠 위험을 가능한 한 낮춘다.
4. 품질 관측: 200 OK 뒤에 숨은 환각을 측정하라
비용이 예산 안에 있고 보안이 안전해도, 사용자 질문에 틀린 답을 주면 생성형 AI 애플리케이션의 핵심 목적을 달성하지 못한다.
4.1. 답변 품질을 구성하는 다섯 지표
-
환각률(hallucination rate)
- 정의: 기반 데이터로 뒷받침되지 않는 주장을 포함한 응답의 비율이다.
- 검증 방법: 사람의 수동 검토와 자동 팩트체킹을 함께 사용해 엄격하게 평가한다.
-
관련성 점수(relevance score)
- 정의: 응답이 실제로 사용자의 질문을 다뤘는지 측정한다.
- 기법: BERT 계열 모델 유사도와 임베딩 유사도처럼 질문과 답변의 의미적 거리를 계산하는 방법을 사용할 수 있다.
-
사용자 만족도(user satisfaction)
- 수집 방식: 좋아요·싫어요 버튼, 별점, NPS를 제품에 넣어 사용자의 직접 피드백을 모은다.
- 권장 목표: 긍정 평가 비율을 최소 80~85%까지 확보하는 것을 목표로 한다.
-
응답 완전성(completeness)
- 정의: 답변이 사용자의 의도를 완전하게 충족했는지 확인한다.
- 평가 방법: 대규모 언어 모델을 심사자(judge)로 활용해 누락된 요구사항이 있는지 평가한다.
-
RAG 검색 품질
- 전제: 검색 증강 생성(Retrieval-Augmented Generation, RAG)을 사용한다면 생성 모델뿐 아니라 검색 계층도 관측해야 한다.
- 핵심 질문: 검색된 문서가 사용자의 질의와 모두 관련 있는지 확인한다.
- 측정 지표: Top-K 정확도와 정규화 할인 누적 이득(Normalized Discounted Cumulative Gain, NDCG)을 추적한다.
- 난이도 변화: 컨텍스트가 커질수록 가장 관련성 높은 문서를 골라내기 어려워지므로 검색 품질을 별도로 관리해야 한다.
4.2. 품질 평가를 운영 루프에 넣기
-
다차원 평가
- 단일 점수의 한계: 환각이 낮아도 질문과 무관하거나 불완전한 답변일 수 있다.
- 결합 판단: 사실성, 관련성, 만족도, 완전성, RAG 검색 품질을 함께 봐야 개선 방향이 보인다.
-
실시간·지속 평가
- 운영 환경의 변화: 모델과 프롬프트, 데이터, 사용자 의도가 계속 변하므로 출시 전 테스트만으로는 충분하지 않다.
- 품질 모니터링: 실제 트래픽에서 품질 지표를 계속 수집해 200 OK 응답의 실질적 유용성을 확인한다.
5. 기존 운영 지표 위에 새 관측 계층을 추가하라
생성형 AI의 관측은 전통적인 모니터링을 대체하는 것이 아니라, 그 위에 비용·안전·품질이라는 별도 층을 올리는 방식으로 완성된다.
5.1. 통합 관측 모델
-
기초 계층
- 운영 상태: 응답 시간, 오류, 트래픽, 포화도를 계속 본다.
- 기능 정상성: 서비스가 요청을 처리하고 인프라가 버티는지 확인한다.
-
생성형 AI 계층
- 비용: 토큰 크리프, 모델 드리프트, 중복 호출을 추적하고 기능·사용자·모델·엔드포인트별로 배분한다.
- 안전: 프롬프트 인젝션, 보호 장치 우회, PII 공개, 유해 콘텐츠를 엄격한 임계값으로 차단한다.
- 품질: 환각률, 관련성, 만족도, 완전성, RAG 검색 품질을 운영 데이터로 평가한다.
5.2. 엔지니어링 책임의 확장
-
추가된 책임
- 구축을 넘어 운영까지: 엔지니어는 애플리케이션을 만들고 실행시키는 데서 끝나지 않는다.
- 복합적인 성공 기준: 비용을 감당할 수 있고 안전하며 사용자에게 유용한지를 함께 책임져야 한다.
-
Datadog의 제안
- 모니터링 제품: Datadog은 AI 애플리케이션이 제대로 작동하는지와 수정이 필요한 문제가 있는지를 파악하도록 에이전트 모니터링 제품을 제공한다.
- 현장 지원: 발표자는 행사장 파빌리온에서 제품을 직접 살펴볼 수 있다고 안내했다.
- 체험 유도: 무료 체험용 QR 코드와 추가 상담을 제공하고, Marina Petzel에게 QR 코드로 연락할 수 있다고 마무리했다.
주요 발언 모음
“생성형 AI 애플리케이션을 제대로 만들려면 우리가 모니터링해야 할 새로운 지표가 있다.”
“같은 프롬프트가 매번 다른 응답을 만들 수 있으므로 표준 회귀 테스트만으로는 충분하지 않다.”
“서버의 ‘200 OK’ 응답이 최종 사용자에게 도움이 되거나 정확한 답변이었다는 뜻은 아니다.”
“비용과 안전을 통제했더라도 모든 애플리케이션, 특히 생성형 애플리케이션에서 가장 중요한 기준은 출력 품질이다.”
“전통적인 지표를 버리자는 것이 아니라, 그 위에 생성형 애플리케이션과 더 관련 있는 비용·안전·품질 계층을 추가하자는 것이다.”
핵심 데이터 & 수치
- 4개 골든 시그널: 응답 시간, 오류, 트래픽, 포화도(LETS)다.
- 컨텍스트 확대 사례: 4,000토큰에서 32,000토큰으로 늘어나면 비용이 최대 8배까지 증가할 수 있다.
- 모델 교체 사례: Haiku 4.5에서 Opus 4.8로 옮기면 요청당 비용이 최대 15배 높아질 수 있다.
- 중복 비용 연구 수치: 캐시가 없을 때 전체 지출의 70%가 중복 호출일 수 있다.
- PII 목표: 프로덕션 출력의 개인식별정보 공개율은 0%여야 한다.
- 보호 장치 우회 목표: 우회 시도는 이상적으로 100% 차단해야 한다.
- 사용자 만족도 목표: 긍정 평가 비율은 최소 80~85%를 지향한다.
- RAG 품질 지표: Top-K 정확도와 NDCG를 사용한다.
결론 및 시사점
- 200 OK를 성공으로 간주하지 않는다: HTTP 상태 코드는 전달 성공만 말할 뿐, 답변의 사실성·관련성·완전성을 보장하지 않는다.
- 기존 골든 시그널을 유지한다: 응답 시간·오류·트래픽·포화도는 시스템 운영의 기초이므로 제거하지 않는다.
- 비용을 태깅한다: 기능·사용자/조직·모델/제공자·엔드포인트/환경별로 호출을 분류하면 비용 폭증의 원인과 제품별 수익성을 볼 수 있다.
- 비용 변화를 배포 이벤트로 취급한다: 컨텍스트 윈도 확대, 모델 교체, 캐시 변경은 품질 개선만이 아니라 예산 변화이므로 재무 검토와 함께 진행한다.
- 안전 지표에는 엄격한 목표를 둔다: PII 공개율 0%와 보호 장치 우회 차단을 운영 기준으로 삼고, 정규식·개체명 인식·분류 모델을 조합한다.
- 품질을 다차원으로 측정한다: 환각률 하나만 보지 말고 관련성·만족도·완전성·RAG 검색 품질까지 함께 추적한다.
- 사람과 모델을 함께 심사자로 쓴다: 수동 검토, 자동 팩트체킹, LLM-as-a-judge, 사용자 피드백을 결합해야 실제 품질을 가까이 측정할 수 있다.
- 운영 중 지속 평가한다: 모델과 데이터와 사용 패턴이 바뀌므로 사전 회귀 테스트에 머물지 말고 실시간 트래픽에서 비용·안전·품질을 계속 평가한다.
핵심 요약 (20줄)
- 전통적인 골든 시그널인 응답 시간, 오류, 트래픽, 포화도는 생성형 AI에서도 운영의 기초다.
- 같은 프롬프트가 매번 다른 답을 만들기 때문에 표준 회귀 테스트만으로 품질을 보장할 수 없다.
- 실제 운영 환경에서 답변 품질을 지속적으로 평가해야 한다.
- LLM 비용은 토큰 수, 사용 모델, 컨텍스트 윈도 크기에 따라 동적으로 변한다.
- 4,000토큰 컨텍스트를 32,000토큰으로 늘리면 비용이 최대 8배까지 뛸 수 있다.
- Haiku 4.5에서 Opus 4.8로 바꾸면 요청당 비용이 최대 15배 높아질 수 있다.
- 캐시가 없으면 동일한 API 호출이 반복되어 지출의 70%가 중복될 수 있다.
- 비용은 기능, 사용자나 조직, 모델과 제공자, 엔드포인트와 환경별로 분류해야 한다.
- 프롬프트 인젝션과 보호 장치 우회는 500 오류 없이도 시스템을 공격할 수 있다.
- 패턴 매칭과 전문 분류 모델로 프롬프트 공격을 감지하고 엄격한 차단선을 세워야 한다.
- 프로덕션 출력의 개인식별정보 공개율 목표는 0%다.
- 정규표현식과 개체명 인식으로 사회보장번호와 신용카드 번호 같은 민감정보를 찾아야 한다.
- 독성 분류기로 공격적·유해·편향된 콘텐츠의 위험도를 측정해야 한다.
- 생성형 AI의 가장 중요한 성공 기준은 예산과 안전을 넘어선 출력 품질이다.
- 환각률은 기반 데이터가 지지하지 않는 주장을 담은 응답의 비율이다.
- 관련성 점수는 답변이 사용자의 질문을 실제로 다뤘는지 보여준다.
- 좋아요·싫어요, 별점, NPS로 사용자 만족도를 수집하고 80~85% 긍정 평가를 목표로 삼을 수 있다.
- 완전성 평가는 답변이 사용자의 의도를 빠짐없이 충족했는지 확인한다.
- RAG 시스템은 Top-K 정확도와 NDCG로 검색 문서의 관련성을 별도로 평가해야 한다.
- 기존 운영 지표 위에 비용·안전·품질 계층을 추가해야 200 OK 뒤의 실패를 발견할 수 있다.
