사내 AI Agent 운영 로그, 어디까지 남겨야 할까
AI Agent를 업무에 붙인 뒤 문제를 추적하고 책임 있게 운영하기 위해 남겨야 할 로그와 남기지 말아야 할 데이터를 정리합니다.
요약: AI Agent 운영 로그는 “감시”보다 “복구와 개선”을 위한 장치입니다. 누가, 언제, 어떤 입력으로, 어떤 도구를 호출했고, 어디에서 사람이 승인했는지만 남겨도 대부분의 장애·보안·품질 이슈를 추적할 수 있습니다.
AI Agent를 PoC로 만들 때는 “일단 돌아가는지”가 중요합니다. 그런데 실제 업무에 연결하는 순간 질문이 바뀝니다.
“이 작업을 왜 했지?”, “고객 정보가 프롬프트에 들어갔나?”, “결재 없이 메일이 발송됐나?” 같은 질문에 답할 수 있어야 운영이 됩니다.
그래서 사내 AI Agent에는 처음부터 거창한 관제 시스템보다, 나중에 원인을 재현할 수 있는 최소 로그 설계가 먼저 필요합니다.
핵심 요약
- 업무 로그는 결과물만이 아니라 입력, 도구 호출, 승인 지점, 예외 상황을 함께 남겨야 합니다.
- 개인정보·계약서 원문·비밀번호처럼 민감한 원문 데이터는 로그에 그대로 남기지 않는 것이 기본입니다.
- 처음부터 모든 토큰을 저장하기보다, 업무 위험도에 따라 “요약 로그 → 상세 로그 → 감사 로그”로 단계를 나누는 편이 안전합니다.
- 사람 승인 루프가 있는 업무라면 승인자, 승인 시각, 승인 전후 변경 내용을 남겨야 책임 소재가 흐려지지 않습니다.
왜 AI Agent는 일반 자동화보다 로그가 더 중요할까?
RPA나 단순 API 자동화는 규칙이 비교적 고정되어 있습니다. 실패해도 “몇 번째 단계에서 오류가 났는지”를 보면 원인을 찾기 쉽습니다.
반면 AI Agent는 매번 입력을 해석하고, 도구를 선택하고, 중간 추론을 거쳐 다음 행동을 정합니다. 같은 요청처럼 보여도 참고한 문서, 호출한 도구, 승인 여부에 따라 결과가 달라질 수 있습니다.
운영 로그의 목적은 AI를 믿지 못해서가 아니라, 문제가 생겼을 때 사람이 빠르게 설명하고 복구할 수 있게 만드는 것입니다.
최소로 남겨야 할 7가지 로그
1. 요청자와 업무 맥락
누가 요청했는지, 어느 부서·프로젝트·고객 건인지, 어떤 업무 유형인지 남깁니다. 개인 이름을 직접 저장하기 어렵다면 사내 ID나 해시 처리된 식별자를 사용해도 됩니다.
2. 입력 요약과 민감정보 처리 여부
프롬프트 전문을 모두 저장하기보다, “견적 메일 초안 작성”, “계약서 조항 요약”처럼 업무 목적을 요약해 남깁니다. 원문을 저장해야 한다면 보관 기간, 접근 권한, 마스킹 기준을 별도로 정해야 합니다.
3. 사용한 지식 출처
RAG를 붙였다면 어떤 문서 묶음, 버전, 검색어, 상위 참조 문서를 사용했는지 남깁니다. 그래야 답변 오류가 모델 문제인지, 오래된 문서 문제인지 구분할 수 있습니다.
4. 호출한 도구와 외부 시스템
Slack 메시지 발송, CRM 조회, Notion 페이지 수정, 이메일 초안 생성처럼 Agent가 호출한 도구를 시간순으로 남깁니다. 쓰기 작업은 읽기 작업보다 더 자세히 기록하는 편이 좋습니다.
5. 사람 승인 루프
메일 발송, 결제, 고객 안내, 데이터 삭제처럼 되돌리기 어려운 작업은 승인자와 승인 시각을 남깁니다. 승인 전 AI 제안 내용과 승인 후 실제 실행 내용이 달라졌다면 그 차이도 기록합니다.
6. 실패와 중단 사유
권한 부족, 문서 미발견, 정책 위반 가능성, 모델 응답 실패, 외부 API 오류를 구분해 남깁니다. “실패” 한 단어만 남으면 다음 개선 포인트를 찾기 어렵습니다.
7. 최종 결과와 후속 조치
완료 여부, 생성된 링크, 보낸 메시지 ID, 담당자 알림 여부를 남깁니다. 특히 고객 접점 업무는 결과물이 어디에 남았는지 추적 가능해야 합니다.
남기지 말아야 할 것
- 비밀번호, API 키, 세션 쿠키, 인증 토큰
- 주민등록번호·계좌번호 등 업무 목적상 필요 없는 고위험 개인정보
- 계약서·진료·법무 문서 원문 전체처럼 접근 통제가 필요한 자료
- 모델의 모든 중간 추론을 무기한 보관하는 방식
로그는 많이 남길수록 안전해지는 것이 아닙니다. 나중에 유출되면 더 큰 리스크가 되는 데이터도 있습니다. 운영팀이 실제로 확인할 항목만 남기고, 원문이 필요한 경우에는 별도 보관소와 권한 정책을 분리하는 편이 안전합니다.
업무 위험도별 로그 단계
낮은 위험: 개인 생산성 보조
회의록 요약, 아이디어 정리, 내부 초안 작성처럼 외부 시스템에 직접 쓰지 않는 업무입니다. 요청 시각, 업무 유형, 결과 생성 여부 정도로도 충분한 경우가 많습니다.
중간 위험: 사내 시스템 조회·수정
Notion, CRM, 스프레드시트처럼 내부 데이터에 접근하거나 수정하는 업무입니다. 접근한 데이터 범위, 수정 전후 요약, 실패 사유, 담당자 알림 여부를 남겨야 합니다.
높은 위험: 고객 접점·금전·권한 변경
고객에게 메시지를 보내거나, 견적·결제·계정 권한에 영향을 주는 업무입니다. 승인 로그, 실행 로그, 롤백 방법, 알림 이력을 반드시 분리해서 남깁니다.
도입 전에 정할 체크리스트
작게 시작하는 운영 설계 예시
처음부터 SIEM이나 대형 관제 시스템을 붙일 필요는 없습니다. 파일럿 단계에서는 작업 ID 하나를 기준으로 요청, 검색, 도구 호출, 승인, 결과를 이어 붙일 수 있게 만드는 것이 우선입니다.
- 모든 Agent 실행에 고유한 작업 ID를 붙입니다.
- 입력 전문 대신 업무 목적과 데이터 출처를 요약해 남깁니다.
- 외부 시스템에 쓰는 작업은 실행 전 사람 승인 여부를 확인합니다.
- 실패 사유를 사람이 이해할 수 있는 코드로 분류합니다.
- 주 1회 로그를 보고 반복 실패 업무와 불필요한 승인 단계를 정리합니다.
HeyRatty 관점에서는 “AI가 얼마나 똑똑한가”보다 “문제가 생겼을 때 운영자가 설명할 수 있는가”가 더 중요합니다. 설명 가능한 자동화가 되어야 팀 안에서 오래 쓰입니다.
FAQ
Q. 프롬프트 전문을 전부 저장해야 하나요?
항상 그럴 필요는 없습니다. 내부 문서나 개인정보가 섞이는 업무라면 전문 저장이 오히려 리스크가 됩니다. 먼저 요약 로그를 기본으로 두고, 고위험 업무만 제한된 권한으로 상세 로그를 남기는 방식을 권장합니다.
Q. 모델 응답이 틀렸을 때 무엇을 먼저 봐야 하나요?
사용한 지식 출처, 검색 결과, 도구 호출 순서를 먼저 봅니다. 많은 오류는 모델 자체보다 오래된 문서, 부족한 권한, 잘못된 검색 범위에서 시작됩니다.
Q. 로그를 많이 남기면 보안 감사에 유리한가요?
필요한 로그를 일관되게 남기는 것은 도움이 됩니다. 하지만 민감정보를 과하게 저장하면 별도의 보호 대상이 늘어납니다. “누가 무엇을 왜 실행했는지”를 설명할 수 있는 최소 단위가 기준이 되어야 합니다.
Q. HeyRatty는 어떤 부분을 도와줄 수 있나요?
현재 업무 흐름을 기준으로 Agent가 자동 실행해도 되는 구간, 사람이 승인해야 하는 구간, 로그로 남겨야 하는 항목을 함께 정리합니다. 이후 Slack, Notion, Google Workspace, 사내 도구와 연결되는 파일럿 자동화까지 단계적으로 설계할 수 있습니다.
참고 및 이미지 출처
NIST AI Risk Management Framework: AI 시스템 위험을 식별·관리하기 위한 프레임워크
OWASP Top 10 for Large Language Model Applications: LLM 애플리케이션 보안 리스크 참고
이미지: Wikimedia Commons / 123net / “123Net Data Center (DC2)” / CC BY-SA 3.0 / 원본 https://commons.wikimedia.org/wiki/File:123Net_Data_Center_(DC2).jpg