들어가며
안녕하세요. KT Responsible AI담당에서 AI Agent 안전성을 연구하고 있는 주민욱, 정동영, 배세윤입니다.
요즘 AI 소식을 따라가다 보면 매주 새로운 모델과 Agent가 등장합니다. 더 긴 문서를 읽고, 더 많은 도구를 쓰고, 사람 대신 여러 단계를 알아서 처리합니다. 자연스럽게 관심은 "이 Agent가 무엇을 할 수 있는가"에 쏠립니다.
그런데 서비스를 운영하는 입장에서는 그 다음 질문이 더 중요해집니다.
배포된 AI Agent가 지금 이 순간 사용자에게 어떤 말을 하고 있을까?
운영자가 확인해야 할 위험 징후가 응답 속에 섞여 있지는 않을까?
상용 서비스에서는 하루에도 수많은 AI 응답이 사용자에게 전달됩니다. 그 응답을 모두 사람이 읽어볼 수는 없습니다. 하지만 읽지 않는다고 해서 위험이 사라지는 것은 아닙니다.
조금 더 구체적으로 생각해보겠습니다.
Agent가 고객에게 부적절한 표현을 하고 있다면?
응답에 전화번호나 주민등록번호 같은 개인정보가 섞여 나간다면?
대화나 외부 문서에 의해 Agent의 기억이 오염되고, 그 영향이 나중에 다른 응답으로 드러난다면?
서버가 살아 있는지, 응답이 느리지 않은지, 에러율이 올라가지 않았는지는 이미 많은 시스템이 잘 보고 있습니다. 하지만 AI가 무슨 내용을 말했는지, 그 내용이 안전한지를 지속적으로 들여다보는 체계는 아직 익숙하지 않습니다.
이 글은 그 빈칸을 채우기 위해 만든 AI Agent Safety Monitoring 시스템의 개발기입니다. Safety Monitoring은 사고를 사전에 차단하는 기술이라기보다, 배포 후 실제 운영 응답에서 위험 징후를 탐지하고 사람이 확인할 수 있도록 돕는 체계입니다. 왜 필요하다고 봤는지, 무엇을 이상행위로 정의했는지, 그리고 실제로 만들면서 어떤 문제에 부딪혔는지를 순서대로 풀어보겠습니다.
1. 왜 "배포 후" 모니터링인가
AI 안전의 마지막 빈칸
AI 서비스의 안전 체계는 크게 배포 전과 배포 후로 나눠볼 수 있습니다.
배포 전에는 안전 학습, 학습 데이터 정제, 모델·Agent 평가, Guardrail 적용 같은 활동이 비교적 명확합니다. 이미 많은 조직이 하고 있고, 관련 도구도 계속 늘고 있습니다.
반면 배포 이후는 조금 다릅니다. 실제 사용자가 들어오고, 실제 대화가 쌓이고, 서비스별 맥락이 생긴 뒤에 Agent가 어떤 응답을 내고 있는지 지속적으로 확인하는 체계는 아직 표준화되어 있지 않습니다. 국정원 AI 보안 가이드라인, NIST AI RMF, OWASP 등 보안 가이드 같은 문서에서도 배포 후 모니터링의 필요성을 이야기하지만, 운영 환경에 연동 가능한 형태의 통합 솔루션은 많지 않습니다.
저희가 채우려 한 것은 이 마지막 단계였습니다.
여기서 중요한 점은 Safety Monitoring의 역할입니다. Safety Monitoring은 사용자의 모든 요청을 실시간으로 막거나 사고를 사전에 완전히 차단하는 장치가 아닙니다. 이미 배포된 서비스에서 생성되고 기록된 응답을 분석해, 운영자가 확인해야 할 위험 징후를 빠르게 찾고 근거와 함께 보여주는 체계에 가깝습니다.
Safety Monitoring은 인프라 관제와 다릅니다.
여기서 먼저 구분해야 할 것이 있습니다. 저희가 말하는 Safety Monitoring은 기존 System Monitoring과 같은 서버 관제와 성격이 다릅니다.
| 구분 |
System Monitoring |
Safety Monitoring |
|---|---|---|
| 핵심 질문 |
서비스가 잘 작동하는가 |
AI가 한 말이 안전한가 |
| 주요 신호 |
CPU, 메모리, 지연, 에러율, 트래픽 |
유해표현, PII 노출, 이상 행위 패턴 |
| 대표 사례 |
서버 다운, DDoS, 응답 지연 |
정상 응답 속에 포함된 위험한 내용 |
System Monitoring은 서비스가 잘 작동하는지를 봅니다. 서버가 살아 있는지, 응답 시간이 늘지 않았는지, 트래픽이 튀지 않았는지, 에러율이 올라가지 않았는지를 확인합니다. 운영에 반드시 필요한 영역입니다.
하지만 AI Agent의 이상 행위는 서버 에러로 드러나지 않을 때가 많습니다. 욕설을 출력해도, 개인정보를 포함해도 서버 입장에서는 에러가 아닌 정상 응답일 수 있습니다.
즉 DDoS, 서버 다운, 응답 지연 같은 인프라 장애는 System Monitoring의 영역입니다. Safety Monitoring은 그보다 좁고 다른 문제를 봅니다. AI가 사용자에게 실제로 내보낸 말의 안전성이 대상입니다.
2. 무엇을 "이상 행위"으로 볼 것인가
시스템을 만들기 전에 가장 먼저 고려한 것은 '이상 행위'에 대한 기준이었습니다. 규제와 가이드는 "이상 행위를 모니터링하라"고 말하지만, 정작 무엇을 이상행위로 볼지에 대한 구체적인 사항들은 직접 정해야 했습니다.
저희는 AI 모델과 Agent에서 발생할 수 있는 위험을 국내외 AI보안가이드라인을 참고하여 크게 AI 이상행위 5종으로 정리했습니다.
| 유형 | 설명 |
|---|---|
| 개인정보 유출 |
개인정보(PII)가 응답에 포함되는 경우 |
| 기밀정보 유출 |
사내 시스템 정보나 미공개 문서가 외부로 드러나는 경우 |
| 유해표현 노출 |
성적, 차별, 폭력, 자해 관련 부적절한 표현이 포함되는 경우 |
| 직접 공격 |
사용자가 Jailbreak, Prompt Injection 등으로 모델을 직접 조종하려는 경우 |
| 간접 공격 |
Memory, RAG, Tool 등 2차 경로를 통해 악성 지시가 주입되는 경우 |
어디까지 볼 것인가
AI Agent는 단순히 입력을 받아 응답만 내는 구조가 아닙니다. 사용자 입력, Memory, Tool 호출, RAG 문서, 최종 응답이 서로 얽혀 있습니다. 그래서 무엇을 볼지뿐 아니라 어느 지점부터 관찰할지도 정해야 했습니다.
저희는 먼저 모델 응답(Response) 부터 시작했습니다. 어떤 경로로 문제가 생겼든, 결국 사용자에게 전달되는 마지막 접점은 모델의 응답이기 때문입니다. 운영 관점에서도 가장 먼저 확인해야 하는 곳이었습니다.
사용자 입력, Memory, Tool/RAG까지 포함한 확장 구조는 뒤의 멀티 에이전트 확장 방향에서 다시 다루겠습니다.
3. 가상 시나리오로 보는 Agent 이상 행위
조금 추상적으로 들릴 수 있어, AX Tech Connect 2026에서 소개한 AICC 상담 Agent 예시를 기준으로 설명해보겠습니다. 아래 이미지는 실제 고객 서비스에서 발생한 사례가 아니라, Safety Monitoring의 필요성과 동작 방식을 설명하기 위해 구성한 가상의 설명용 시나리오입니다.
이 예시의 핵심은 단순합니다. 일반적인 유해 요청은 기존 안전 장치가 거부할 수 있지만, Jailbreak처럼 우회된 입력에서는 서버 오류 없이 정상 응답처럼 보이는 출력 안에 부적절한 표현이 포함될 가능성이 생깁니다.
여기서 중요한 점은 시스템 관점에서는 여전히 "정상 응답"처럼 보일 수 있다는 것입니다. 서버는 살아 있고, 응답 시간도 정상이고, API 호출도 실패하지 않았습니다. System Monitoring만 보면 문제가 없어 보이지만, 사용자가 받은 응답의 내용까지 보면 운영자가 확인해야 할 위험 징후가 있을 수 있습니다.
Safety Monitoring은 바로 이 지점을 보기 위한 체계입니다. 이 시스템은 응답이 생성되기 전에 모든 위험을 사전에 차단하는 기술이 아닙니다. 대신 배포 후 운영 로그에 남은 모델 응답을 분석해, 위험 가능성이 있는 응답을 찾아내고 담당자가 Dashboard에서 확인할 수 있게 합니다.
이 예시에서 핵심은 "사고를 완전히 막았다"가 아니라, 배포 후 운영 중에 위험 징후를 놓치지 않고 확인할 수 있게 만들었다는 점입니다. 실제 운영에서는 모든 응답을 사람이 직접 읽을 수 없기 때문에, 시스템이 먼저 위험 가능성이 있는 응답을 좁혀주고 담당자가 근거를 확인하는 구조가 필요합니다.
내부 검토 과정에서도 이런 사후 점검 체계의 필요성을 확인했습니다. 구체적인 내용은 공개 범위상 다루지 않지만, 이 경험은 배포 후 실제 응답을 지속적으로 확인하는 체계가 필요하다는 판단으로 이어졌습니다.
4. 해결하고자 하는 문제들
무엇을 볼지 정하고 나면 구현은 쉬울 것 같았습니다. 로그를 가져오고, 위험한 응답을 찾고, 대시보드에 보여주면 된다고 생각했습니다. 하지만 실제로 시스템을 만들다 보니 단순한 탐지 파이프라인 이상의 문제가 있었습니다.
저희가 풀어야 했던 문제는 크게 세 가지였습니다.
첫 번째는 많은 로그 중 무엇을 볼 것인가였습니다.
상용 서비스의 운영 로그 대부분은 정상 응답입니다. 그중 일부에만 운영자가 확인해야 할 위험 징후가 섞여 있을 수 있습니다. 모든 응답을 사람이 읽는 것은 불가능하고, 모든 응답을 대형 모델로 정밀 평가하는 것도 비용과 처리 시간 측면에서 부담이 큽니다.
그래서 처음부터 "모든 로그를 깊게 평가하자"가 아니라, 많은 응답 중 위험 가능성이 있는 후보를 효율적으로 줄이는 구조가 필요했습니다. 현재 파이프라인은 Azure Log Analytics Workspace에서 응답 로그를 조회한 뒤, 대표 샘플을 구성하고, Safety 특화 sLM을 활용해 1차 후보를 줄이는 방식으로 설계했습니다.
이 단계의 목적은 최종 판정이 아닙니다. 사람이 볼 필요가 있는 후보를 줄이는 것입니다. 운영 환경에서는 탐지 정확도뿐 아니라 처리 비용, 분석 주기, 운영 검토 부담까지 함께 고려해야 하기 때문입니다.
두 번째는 어떤 기준으로 위험하다고 판단할 것인가였습니다.
"위험한 응답을 찾는다"는 말은 쉽지만, 실제 시스템 안에서는 훨씬 구체적인 기준이 필요했습니다. 개인정보처럼 형식이 비교적 분명한 정보는 정규식과 규칙 기반 탐지로 1차 확인할 수 있습니다. 다만 공개 글에서는 이를 실제 유출 사례처럼 보이게 쓰기보다, 응답에 개인정보로 해석될 수 있는 값이 포함되는 가능성을 점검한다고 보는 편이 더 적절합니다.
반면 유해표현은 단순 키워드만으로 판단하기 어렵습니다. 같은 단어라도 맥락에 따라 위험도가 달라지고, 사용자가 인용한 표현인지 Agent가 직접 생성한 표현인지에 따라서도 판단이 달라집니다. 그래서 성적, 차별, 폭력, 자해와 같은 카테고리별 기준을 나누고, LLM-as-a-Judge가 단순 라벨뿐 아니라 판단 근거를 함께 남기도록 했습니다.
여기서 중요한 것은 Judge 모델 자체보다 판단 기준의 명확성이었습니다. 기준이 흐릿하면 모델이 아무리 좋아도 결과를 운영자가 신뢰하기 어렵습니다. 반대로 기준이 명확하면 오탐과 미탐을 검토할 때도 무엇을 고쳐야 하는지 알 수 있습니다.
세 번째는 최종 판단을 어디까지 자동화할 것인가였습니다.
Safety Monitoring에서 자동화는 필요하지만, 모든 결정을 AI에게 맡길 수는 없습니다. Judge 모델도 오탐과 미탐이 있고, Safety 영역은 서비스 맥락에 따라 해석이 달라질 수 있습니다. 같은 문장이라도 상담 맥락, 교육 맥락, 신고 대응 맥락에서 위험도가 다르게 보일 수 있습니다.
그래서 저희는 이 시스템의 역할을 "자동 조치"가 아니라 사람이 확인해야 할 지점을 좁혀주는 것으로 정의했습니다. Sampling은 볼 대상을 줄이고, Screening은 위험 가능성이 높은 후보를 추리고, Evaluation은 판단 근거를 붙입니다. 담당자는 수많은 원문 로그를 처음부터 뒤지는 대신, 시스템이 추려낸 후보와 Reasoning을 보고 최종 확인에 집중할 수 있습니다.
정리하면 이 시스템이 해결하려는 문제는 단순히 Unsafe 개수를 세는 것이 아닙니다. 사람이 모든 응답 로그를 직접 읽지 않아도, 운영 중 위험 가능성이 있는 응답을 빠르게 발견하고, 그 근거를 확인할 수 있게 만드는 것입니다.
5. 전체 파이프라인
현재 시스템은 Azure Log Analytics Workspace에 이미 저장된 AI 모델 응답 정보를 1시간 단위 배치로 조회해 분석합니다. 전체 응답을 그대로 가져오기보다 조회 단계에서 대표 샘플을 구성하고, 후속 모델 단계로 넘기기 전에 PII 탐지와 마스킹을 먼저 수행합니다.
이후 Safety 특화 sLM이 위험 후보를 1차로 줄이고, LLM-as-a-Judge가 유해표현 여부와 판단 근거를 생성합니다. 최종 결과는 Dashboard에서 확인할 수 있고, 담당자가 검수한 사례는 프롬프트, 모델, 평가 시나리오 개선에 다시 활용됩니다.
현재 파이프라인의 핵심은 사용자에게 이미 전달되었거나 운영 로그에 기록된 응답 중, 위험 가능성이 있는 것을 빠르게 발견하고 확인하는 것입니다. 즉 이 시스템은 응답 생성을 사전에 차단하는 장치가 아니라, 배포 후 운영 단계에서 위험 징후를 탐지하고 담당자의 판단을 돕는 모니터링 체계입니다.
먼저 모델 응답 정보를 안정적으로 분석하는 기반을 만들고, 이후 사용자 입력이나 Tool/RAG 로그까지 관찰 지점을 넓혀갈 수 있습니다.
6. 개발하며 배운 것
이 프로젝트를 진행하며 크게 두 가지를 배웠습니다.
첫째, 핵심은 모델보다 기준이었습니다.
처음에는 파이프라인을 잘 만들고 좋은 Judge 모델을 붙이면 대부분 해결될 거라고 생각했습니다. 하지만 실제로 가장 오래 걸린 일은 모델을 고르는 일이 아니라, 무엇을 위험하다고 볼 것인지를 정하는 일이었습니다. 유해표현이라고 해도 모든 불쾌한 표현이 같은 위험은 아니고, 개인정보라고 해도 어떤 형식을 어디까지 탐지할지 정해야 합니다. 직접 공격과 간접 공격도 마찬가지입니다. 이름은 익숙하지만, 운영 시스템 안에서 판단 가능한 기준으로 바꾸려면 훨씬 더 구체적인 문장이 필요했습니다. 이 기준이 흐릿하면 뒤의 모든 단계가 흔들립니다.
Safety Monitoring에서 중요한 일은 단순히 "위험한 말을 찾아라"가 아니라, 우리 조직이 어떤 위험을 어떤 근거로 위험하다고 판단할 것인지 합의 가능한 형태로 만드는 것이었습니다.
둘째, 자동화의 목적은 사람을 대체하는 것이 아니었습니다.
AI가 AI를 평가한다고 해서 마지막 판단까지 모두 AI에게 맡길 수는 없습니다. Judge도 오탐과 미탐이 있고, 특히 Safety 영역은 문맥과 서비스 상황에 따라 판단이 달라질 수 있습니다. 그렇다고 사람이 모든 응답 로그를 직접 볼 수도 없습니다. 결국 필요한 것은 사람을 없애는 자동화가 아니라, 사람이 봐야 할 지점을 정확히 좁혀주는 자동화였습니다.
그래서 파이프라인의 역할도 명확해졌습니다. Sampling은 볼 대상을 줄이고, Screening은 위험 가능성이 높은 후보를 추리고, Evaluation은 판단 근거를 붙입니다. 담당자는 수많은 원문 로그를 처음부터 뒤지는 대신, 시스템이 추려낸 후보와 Reasoning을 보고 최종 판단에 집중할 수 있습니다. 자동화가 판단을 대신하는 것이 아니라, 사람이 더 좋은 판단을 할 수 있도록 시야를 정리해주는 구조입니다.
이 관점은 이후 개선 방향에도 영향을 줬습니다. 좋은 Monitoring 시스템은 단순히 Unsafe 개수를 세는 시스템이 아니라, 사람이 납득할 수 있는 근거를 남기고, 그 근거가 다시 프롬프트, 모델, 평가 시나리오 개선으로 이어지게 해야 합니다.
7. 다음 단계: Judge 개선과 이상행위 확대
아직 해야 할 일은 많지만, 당장은 두 방향에 집중하려 합니다.
첫 번째는 Judge 개선입니다.
현재 구조에서는 Screening 이후 LLM-as-a-Judge가 유해표현 여부와 판단 근거를 생성합니다. 이 단계의 품질이 좋아질수록 사람이 확인해야 하는 후보의 품질도 좋아집니다. 앞으로는 Judge의 경량화와 성능 개선을 함께 추진하려 합니다.
경량화 측면에서는 더 작은 모델이나 효율적인 추론 구성을 검토해 분석 비용과 처리 시간을 줄여야 합니다. 운영 로그는 계속 쌓이기 때문에, Judge 단계가 무거워지면 분석 주기와 검토 속도에 바로 영향을 줍니다. 성능 측면에서는 실제 운영에서 나온 오탐·미탐 사례를 기준과 Prompt에 다시 반영해, 놓친 표현은 줄이고 과하게 위험하다고 본 케이스는 조정해야 합니다.
특히 중요한 것은 단순히 모델을 바꾸는 것이 아니라, 사람이 납득할 수 있는 Reasoning을 안정적으로 남기는 일입니다. Judge가 틀린 사례는 실패 로그가 아니라 다음 기준을 개선할 재료입니다. 어떤 표현을 놓쳤는지, 어떤 문맥에서 과하게 위험하다고 봤는지, Reasoning이 충분했는지를 계속 확인해야 합니다.
두 번째는 이상행위 탐지 범위 확대입니다.
현재는 모델 응답 지점에서 PII와 유해표현을 중심으로 보고 있습니다. 하지만 앞에서 정의한 AI 이상행위는 5종입니다. 앞으로는 기밀정보 유출, 직접 공격, 간접 공격까지 탐지 범위를 넓혀야 합니다. 특히 Agent 환경에서는 위험이 최종 응답에서만 시작되지 않습니다. 사용자 입력, Memory, Tool, RAG처럼 여러 경로를 거쳐 문제가 만들어질 수 있습니다.
그래서 장기적으로는 모델 응답뿐 아니라 Agent 실행 흐름의 여러 관찰 지점으로 확장해야 합니다. 지금은 사용자에게 나간 말을 보는 단계라면, 다음에는 그 말이 어떤 입력과 어떤 컨텍스트를 거쳐 만들어졌는지까지 볼 수 있어야 합니다. 그래야 단순히 "위험한 응답이 나왔다"에서 멈추지 않고, "왜 그런 응답이 나왔는가"까지 분석할 수 있습니다.
최종적으로는 IT Observability가 시스템 상태를 관찰하듯, AI Agent의 전 구간을 안전 관점에서 관찰하는 AI Agent Safety Observability에 가까워지는 것이 목표입니다. 아직은 시작점이 모델 응답 정보이지만, 이 시작점이 있어야 더 넓은 관찰 체계로 확장할 수 있습니다.
마무리
AI Agent가 "잘 배포됐다"는 말과 "안전하게 운영되고 있다"는 말은 다릅니다. 개발과 평가를 통과했다는 것은 알려진 조건에서 문제가 없었다는 뜻에 가깝습니다. 실제 사용자가 들어오고, 실제 대화가 쌓이고, 실제 도구가 연결된 뒤에도 안전한지는 다시 봐야 합니다.
Safety Monitoring은 그 질문에 답하기 위한 시도입니다. 아직 완벽하지는 않습니다. 현재는 LAW에 저장된 모델 응답 정보를 중심으로 PII와 유해표현을 탐지하는 단계이고, 앞으로 더 많은 이상행위와 관찰 지점으로 확장해야 합니다.
실제로 서비스를 운영해보면 Safety Monitoring 데이터는 여러 방식으로 쓰입니다. 사업·운영 부서는 고객 이슈를 빨리 알아차리는 신호로 보고, 개발 부서는 프롬프트나 모델을 고칠 단서로 봅니다. 평가 부서는 운영에서 반복되는 사례를 다음 평가셋의 재료로 활용할 수 있습니다.
이 글에서 소개한 핵심 구현은 GitHub에 공개해두었습니다. 각 조직의 서비스 구조와 로그 형태는 다르겠지만, 배포 이후 모델 응답을 수집하고, PII를 마스킹하고, 위험 후보를 선별한 뒤, Judge로 다시 확인하는 흐름은 충분히 변형해서 활용할 수 있다고 생각합니다.
Safety는 한 번 적용하고 끝나는 기능이 아니라, 운영 속에서 계속 발견하고 고쳐가는 과정에 가깝습니다. 비슷한 고민을 하고 있다면 저장소의 코드를 출발점으로 삼아 직접 실행해보고, 각자의 서비스 로그와 정책에 맞게 바꿔보셔도 좋겠습니다.
긴 글 읽어주셔서 감사합니다.