Part 1. AI Observability란 무엇인가
(1) Observability란?
Observability는 소프트웨어 분야에서 사용되는 개념으로, 우리말로는 ‘관찰 가능성’이라고 합니다. 단순히 시스템을 감시하는 것을 넘어, 시스템이 실제로 어떻게 동작하고 있는지를 이해할 수 있게 하는 것을 의미합니다. 로그·메트릭·트레이스와 같은 다양한 신호를 활용해, 단순히 “문제가 있다”를 넘어 “왜 그런 결과가 나왔는지”까지 추론할 수 있게 합니다.
자주 함께 언급되는 개념은 Monitoring입니다. Monitoring은 사전에 정해 둔 지표와 임계값(예: 응답시간, 에러율)을 기준으로 시스템이 정상 범위를 벗어났는지 감지하고 알람을 울리는 활동입니다. ‘무엇이, 언제 잘못됐는지’를 빠르게 알려 줍니다. Observability는 Monitoring을 포함하면서, 한 걸음 더 나아가 ‘왜 그런 결과가 나왔는지’까지 따라갈 수 있게 합니다. 이상을 감지하는 단계’를 넘어 ‘원인을 이해하는 단계’까지 아우릅니다.
(2) Why AI Observability
AI 서비스는 내부 동작이 잘 드러나지 않는 불투명성(opacity) 탓에 "왜 이런 결과가 나왔을까?", "왜 정확도가 갑자기 떨어졌을까?", "왜 특정 입력에서만 이상하게 동작할까?"와 같은 질문에 답하기 어렵고, 그만큼 시스템을 투명하게(transparency) 관측하려는 요구가 커지고 있습니다.
AI 시스템은 하나의 모델만으로 동작하지 않습니다. 데이터 수집과 전처리, 피처(feature) 생성, 모델 추론, 후처리로 이어지는 여러 단계가 맞물려 하나의 결과를 만듭니다. 그래서 결과가 어긋났을 때 그 원인이 입력 데이터의 변화(데이터 드리프트) 때문인지, 특정 전처리 단계 때문인지, 모델 자체 때문인지를 단계별로 따라가며 살펴봐야 합니다. AI Observability는 이렇게 여러 단계에 걸친 동작을 들여다볼 수 있게 해 줍니다.
더욱 까다로운 점은 무엇이 ‘좋은 결과’인지를 기술 지표만으로 판단하기 어렵다는 것입니다. 예를 들어 추천 모델이 어떤 상품을 권했을 때 그것이 고객에게 정말 적절한 추천인지, 혹은 이상거래 탐지 모델이 특정 거래를 막았을 때 그 판단이 서비스 정책에 맞는지는 정확도 수치만으로는 알기 어렵습니다. 결국 무엇이 좋은 결과인지는 기술 지표를 넘어, 서비스와 사용자 맥락에서 함께 판단해야 합니다.
AI Observability는 AI 시스템의 로그, 메트릭, 트레이스를 통해 동작 과정을 드러내고, 개발자와 서비스 기획자가 같은 데이터를 보며 함께 분석하고 판단할 수 있는 기반을 제공합니다. 마치 의사가 MRI를 통해 몸속을 살펴보고 진단하듯, AI Observability는 AI 시스템 내부를 시각화 하는 렌즈가 됩니다.
Part 2. 대화형 AI 서비스와 Observability
최근 금융 서비스를 비롯한 다양한 디지털 플랫폼에서, 사용자의 질문에 자연어로 답하고 필요한 정보를 찾아 주거나 다음 행동까지 안내하는 '대화형 AI'가 빠르게 늘고 있습니다.
1.
대화형 AI는 흔히 떠올리는 단순 챗봇과는 다릅니다. 한 번 묻고 한 번 답하는 수준이 아니라, 여러 차례 오가는 대화의 맥락을 기억하고, 필요한 정보를 검색하거나 내부 기능을 호출하며, 때로는 사람 상담으로 연결하는 복합적인 흐름 위에서 동작합니다.
2.
편리한 만큼, 문제가 생겼을 때 '어디서' 잘못됐는지 찾기는 더 어려워집니다. 답이 어색한 이유가 모델 때문인지, 검색 때문인지, 맥락 이해의 실패 때문인지, 아니면 애초에 풀리지 않은 대화였는지가 한눈에 드러나지 않기 때문입니다.
대화형 AI 서비스를 관측하려고 하면, 데이터는 대체로 두 갈래로 나뉩니다. API 성능·장애·로그처럼 '지금 정상인가'를 빠르게 보는 실시간 운영 신호와 다른 하나는 대화 원본과 처리 내역을 쌓아 두고 사후에 분석·감사하는 축적형 데이터입니다.
문제는 이 둘이 잘 만나지 않는다는 것입니다. 실시간 지표에서 에러나 지연이 보여도, 그 요청이 '어떤 대화에서' 비롯됐는지를 축적된 원본 대화와 곧바로 잇기가 쉽지 않습니다. 분석이 복잡해질수록 담당자는 여러 화면을 오가며 조각난 데이터를 모아, 머릿속에서 다시 이어 붙여야 합니다.
“에러가 늘었다”는 사실은 금방 알 수 있어도, “어떤 대화에서, 왜 문제가 됐는지”를 이해하는 데에는 시간이 걸립니다. 운영의 관점과 사용자 경험의 관점을 하나로 이어 주는 자리가 비어 있는 셈입니다. 개별 요청이 아니라 '하나의 대화'를 기준으로 흩어진 신호를 다시 엮어야, 운영 이슈와 답변 품질, 사용자 경험이 끊김 없이 하나의 이야기로 읽히게 됩니다. 이것이 대화형 AI 서비스의 Observability가 지향하는 지점입니다.
Part 3. 대화형 AI 서비스 Observability 실험
가상의 은행 고객상담 사례로 답변 품질, RAG 정확성, 실제 문제 해결 여부 등 10가지 Observability 시나리오를 [표 1]과 같이 구성해 실험했습니다. 실제 고객 데이터 대신 은행 상담 상황을 가정한 합성 대화를 사용했고, 하나의 대화를 질문부터 검색·모델 응답·기능 호출·상담원 연결까지 처음부터 끝까지 이어서 볼 수 있도록 관측 환경을 구성했습니다.
[표 1] 실험 시나리오
이를 위해 대화가 거쳐 가는 모든 단계(질문 접수, 자료 검색, 모델 응답, 기능 호출, 상담원 연결)를 각각 기록 단위(span)로 계측하고, 같은 대화에서 나온 기록에는 공통 식별자(trace ID)를 붙여 하나의 흐름(trace)으로 묶었습니다. 각 기록에는 질문 유형·검색 결과 수·해결 여부 같은 속성(attribute)을 함께 남겨, 나중에 원하는 기준으로 모아 보거나 걸러 볼 수 있게 했습니다. 이렇게 계측한 데이터를 바탕으로, 운영에 특히 의미 있다고 본 다섯 가지를 정리하면 다음과 같습니다.
첫째, 문제가 '모델'이 아니라 '처리 과정'에 있는 경우가 많았습니다.
최종 답변만 보면 똑같이 '부실한 답'이지만, 자료를 찾는 검색 단계를 별도 기록으로 남기고 거기에 '찾은 자료 수'를 적어 둔 덕분에 원인을 구분할 수 있었습니다. 검색 기록이 비어 있는데 답이 부실하면 검색 단계의 문제, 자료는 찾았는데 답이 부실하면 답을 만드는 단계의 문제였습니다. 실제로 검색 기록이 비어 있던 대출 거절 사유 질문에서 검색 범위를 넓히자 찾은 자료가 1건에서 3건으로 늘었고, 답변의 근거도 또렷해졌습니다. 어느 단계를 고쳐야 할지는, 단계별 기록을 나눠 봤을 때 분명해졌습니다.
둘째, 같은 오답처럼 보여도 원인은 달랐습니다.
최종 답변만 보면 똑같이 '부실한 답'이지만, 자료를 찾는 검색 단계를 별도 기록으로 남기고 거기에 '찾은 자료 수'를 적어 둔 덕분에 원인을 구분할 수 있었습니다. 검색 기록이 비어 있는데 답이 부실하면 검색 단계의 문제, 자료는 찾았는데 답이 부실하면 답을 만드는 단계의 문제였습니다. 실제로 검색 기록이 비어 있던 대출 거절 사유 질문에서 검색 범위를 넓히자 찾은 자료가 1건에서 3건으로 늘었고, 답변의 근거도 또렷해졌습니다. 어느 단계를 고쳐야 할지는, 단계별 기록을 나눠 봤을 때 분명해졌습니다.
셋째, 답변이 끝났다고 고객의 문제가 끝난 것은 아니었습니다.
그래서 답변 생성 여부와 별개로, 각 대화의 결과를 '해결’, ‘부분 해결’, ‘상담원 이관’, ‘이탈'로 판정해 대화 기록에 속성으로 남겼습니다. 이 속성으로 다시 모아 보니 4개 대화 중 2개만 실제 해결이었고, 1개는 상담원 연결, 1개는 부분 해결로 다시 문의할 가능성이 남았습니다. 특히 근거가 부족한데도 단정적으로 답한 대화는 사용자 불만 신호가 높았습니다. '답변을 생성했다'는 사실만으로는 보이지 않던 진짜 해결률이, 결과를 속성으로 남겨 두었기에 드러났습니다.
넷째, 평균은 생각보다 많은 것을 가립니다.
각 대화 기록에 질문 유형과 프롬프트 버전을 속성으로 남겨 두었기 때문에, 전체 평균이 아니라 이 기준으로 해결률을 다시 모아 볼 수 있었습니다. 전체 해결률은 실험상 10건 중 7건 수준이었지만, 질문 유형별로 갈라 집계하니 숫자가 달라졌습니다. 상품 추천처럼 설명이 필요한 질문에 짧게만 답한 경우 해결률이 약 54%까지 내려갔고, 같은 질문이라도 비교 기준을 풀어 설명한 경우 약 85%까지 올라갔습니다. 그래서 해당 질문 유형은 프롬프트가 비교 기준을 반드시 풀어 설명하도록 보완했습니다. 평균 하나만 봤다면 지나쳤을 구간을, 속성 기준으로 좁혀 개선할 수 있었습니다.
다섯째, 평가 결과 자체도 그대로 믿기 어려웠습니다.
평가에는 AI 평가(LLM-as-a-Judge)를 썼는데, 같은 대화에 서로 다른 기준의 평가 점수를 여러 개 붙여 나란히 비교할 수 있게 했습니다. 그렇게 모아 보니 어떤 기준을 적용하느냐에 따라 같은 답변의 점수가 갈렸습니다. AI 평가가 빠르고 편리하지만 기준에 따라 결과가 달라질 수 있다는 사실 자체가, 한 대화에 여러 평가를 함께 붙여 봤기 때문에 드러난 것입니다. 그래서 점수가 엇갈리거나 위험 신호가 있는 대화를 우선 추려 사람이 다시 검토·보정하도록 했고, 관측이 보여 주는 신호를 어떻게 해석하고 판단할지는 다시 사람의 몫으로 남습니다.
(주: 실제 고객 데이터가 아니라 사내 검증 실험에서 만든 은행 상담형 합성 대화 기준이며, 대화 내역은 원문 일부를 줄인 예시입니다.)
Part 4. 대화형 AI Observability와 사람의 판단
앞선 실험에서 보았듯, 관측은 무엇이 일어났는지를 보여 주지만 그것이 좋은 답이었는지, 고객의 문제가 풀렸는지에 대한 최종 판단은 사람의 몫으로 남습니다. 사실 이렇게 사람의 판단이 개입하는 일은 금융에서 새삼스러운 것이 아닙니다.
금융 업무는 규칙과 숫자로 움직일 것처럼 보이지만, 실제로는 사람의 판단이 중요한 영역이 여전히 많습니다. 자금세탁방지 업무 중 의심거래보고(STR)는 명확한 기준도 중요하지만, 담당자의 경험과 직감에 기반해 이루어지고, 고객의 얼굴과 신분증을 대조하거나, 상황에 맞는 상품을 추천하고 서비스를 안내하는 일 역시 정답이 하나로 정해져 있지 않은 주관적 판단이 더 중요한 영역입니다.
AI가 본격적으로 활용되기 시작한 곳도 이러한 업무들입니다. 안면인식 AI는 사람의 판단을 “같다/다르다”가 아닌 “93% 확률로 일치한다”라는 수치로 표현합니다. 사람의 주관성을 기계가 수치화한 것입니다. AI Observability는 이 수치가 어떻게 만들어졌는지, 어떤 요소들이 결과에 영향을 미쳤는지를 확인할 수 있게 해줍니다.
대화형 AI는 여기서 한 단계 더 나아갑니다. 확률값 대신 문장으로 답하며, 사람의 상담과 안내를 대체합니다. 고객에게 하나의 답변을 제시하지만, 그 결과에 대해서는 다시 “왜 그렇게 답했는가”라는 설명이 필요합니다. 이 설명은 숫자가 아니라 맥락과 언어로 제공되며, 해석과 판단은 다시 사람의 몫이 됩니다.
대화형 AI에 대한 Observability는 이러한 판단을 돕기 위한 관측의 관점입니다. 목적은 기존 AI Observability와 같지만, 성능과 이유를 수치가 아닌 '설명'으로 바라본다는 점에서 들여다보는 대상이 달라집니다.
중요한 것은 모델의 점수를 매기는 일이 아니라, 대화형 AI가 실제 사용자와 만나는 장면에서 무엇이 일어나는지를 이해하는 일입니다. 답변의 유무나 평균 점수가 아니라, 하나의 대화가 어떤 맥락을 거쳐 어떤 결과로 이어졌는지가 핵심입니다.
그래서 대화 단위로 신호를 엮어, 문제가 실제로 해결됐는지, 답변의 근거는 충분했는지, 어떤 흐름을 거쳐 답이 나왔는지, 얼마나 확신에 차 있었는지를 함께 살펴보게 됩니다. 이런 관점은 “성능이 떨어졌다”는 추상적인 진단을 넘어, 어디에서 왜 문제가 생겼는지를 설명할 수 있게 해 줍니다.
결국 대화형 AI Observability는 정답을 대신 내려주는 도구라기보다, 사람이 더 나은 판단을 내릴 수 있도록 돕는 기반에 가깝습니다. 대화형 AI 서비스의 동작을 깊이 이해하고 사용자 관점에서 최적의 판단을 내리기 위해 개발자뿐 아니라 '서비스 기획자'의 참여도 함께 중요해지고 있습니다. 대화형 AI 서비스가 확산될수록, 이런 관측 체계는 AI를 통제하기 위한 수단이 아니라 사람과 AI가 함께 일하기 위한 공통의 이해 지점으로서 더 중요해질 것입니다.
카카오뱅크 금융기술연구소
Financial Tech Lab