보안 업무를 위한 AI 에이전트 플랫폼 「SAGE」 개발기 1편: 판단은 사람에게 남기는 설계

안녕하세요. 사내 보안 업무에 AI를 접목하는 일을 하고 있는 Security Development Division(LINE Plus Security R&D)팀입니다.

이 글은 사내에서 운영 중인 사이버 보안 관련 AI 에이전트 플랫폼 SAGE의 기술·운영 관점을 다룬 1편입니다. 보안 도메인에 AI 도입을 검토 중인 보안 분야 담당자분들께 참고가 될 만한 설계 결정과 운영 방식을 정리해 보았습니다.

본격적인 이야기에 앞서, 저희가 어떤 방향을 향하고 있는지를 간단히 설명하겠습니다.

보안 업무에 AI를 도입하려 할 때 논의는 흔히 양 극단으로 치우칩니다. 한쪽은 ‘사람 개입 없이 스스로 판단하는 완전한 자율형 에이전트’를 처음부터 완성형으로 만들려는 접근입니다. 하지만 이 접근 방식은 실무 적용 과정에서 한계가 드러나곤 합니다. 그럴듯하지만 부정확한 답변이 잘못된 판단의 근거가 될 수 있다는 있다는 단점이 보안에서는 다른 영역보다 훨씬 치명적이기 때문입니다. 다른 한쪽은 위험이 커 보여 도입 자체를 미루는 접근입니다. 이 접근 방식은 미뤄지는 만큼 담당자가 흩어진 규정과 사례를 일일이 찾는 반복 업무를 계속 처리해야 한다는 단점이 있습니다.

저희는 이 두 극단 사이에서, 사람의 판단을 대신하지 않고 판단 준비를 돕는 일부터 시작해 단계적으로 넓혀 가는 쪽을 택했습니다. 그리고 다음과 같이 3단계에 걸쳐 도입하는 방식을 설계했습니다.

• 1단계 — 사람의 판단을 돕는 단계: AI가 1차 정리와 근거 수집을 맡고, 보안 판단과 예외 승인 같은 책임 있는 결정은 사람이 합니다.
• 2단계 — 에이전트들이 협업하는 단계: 여러 에이전트가 역할을 나눠 맡아, 사람이 직접 손대야 하는 영역을 점차 좁혀 갑니다.
• 3단계 — 정형 영역부터 자동화하는 단계: 충분히 검증되고 형태가 일정한 업무부터 사람 개입을 최소화합니다.

이 세 단계는 명확히 분리할 수 있는 단계가 아닙니다. 실제 SAGE 안에서도 제한된 범위 안에서 여러 에이전트가 역할을 나눠 협업하거나 정형화된 일부 작업을 자동화하는 시도를 이미 시작했습니다. 다만 이번 글에서는 1단계, 즉 AI가 사람의 판단을 대신하지 않고 판단 준비를 돕는 방식을 중심으로 살펴보려고 합니다.

자율 에이전트라는 구상은 매력적입니다. 하지만 실제 복잡한 업무에서는 사람의 개입이 다시 필요했고, 그 과정에서 저희는 자율 에이전트의 한계를 충분히 지켜보았습니다. 그 결과가 앞서 말씀드린 3단계 도입 프로세스입니다. 실제로 작동하는 1단계를 먼저 안정화한 뒤, 검증된 만큼만 다음 단계로 넓혀 가는 것입니다. 이어지는 내용도 이 관점에서, 사람과 AI가 함께 일하는 현재 저희의 구조와 운영 방식을 중심으로 설명합니다.

참고로 본 글에 등장하는 답변 형식 · 운영 룰 · 검증 단계 설명은 실제 시스템의 의도를 풀어 쓴 것입니다. 사내 컴포넌트의 실제 이름, 지시문 원문, 개별 규정 문서명 및 실제 운영 수치는 보안을 위해 의도적으로 일반화하여 표현했습니다.

보안 업무에 AI를 적용할 때 마주하는 벽

"이 데이터를 외부 서비스에 올려도 되나요?"

보안 부서에 들어오는 이러한 유형의 질문에 답변하는 과정에는 보통 다음과 같은 확인 작업이 숨어 있습니다.

• 어떤 데이터인지(정보 등급), 어디로 가는지(외부 전송·국외 송수신·위탁), 무엇을 쓰는지(생성 AI·외부 SaaS)에 따라 서로 다른 규정 조항을 확인해야 합니다.
• 같은 종류의 상담이 과거에 어떻게 종결되었는지 확인해야 합니다.
• 운영 팀이 알고 있는 ‘요즘 자주 반려되는 사유’, ‘이 메시지는 사실 다른 원인’ 같은 정보가 답의 단서가 되기 때문에 이를 확인해야 합니다.

문제는 각 자료가 업무 영역과 시스템에 따라 서로 다른 곳에 흩어져 있다는 점이었습니다. 사내 규정·가이드는 Confluence 문서에 정리돼 있고, 보안 컨설팅 상담의 과거 이력과 사실 관계는 Jira 티켓에 적혀 있으며, 보안 운영 문의에 답변하는 과정에서 누적된 처리 노하우는 Slack 히스토리와 담당자의 머릿속에 남아 있습니다. 즉, 한 건의 답변을 만들기 위해 담당자가 여러 영역에 산재돼 있는 여러 자료를 오가야 하는 어려움이 있었고, 그 결과 담당자의 숙련도에 따라 답변 품질과 처리 시간의 편차가 크게 벌어졌습니다.

다음 그림은 보안 상담 한 건이 처리되는 모습을 시간의 흐름에 따라 단순화해 나열한 것입니다. 그림에서 색으로 구분해 둔 '담당자' 단계가 모두 사람의 시간이 들어가는 부분입니다.

저희가 풀고 싶었던 것은 단순합니다. 이 단계들을 사람이 ‘더 빠르고 안전하게’ 처리할 수 있도록 돕는 일이었습니다. 이는 AI가 한 줄 답변을 자동으로 만들어내는 일이 아니라, 답변 직전까지의 1차 정리를 끝내 두는 동료를 만드는 일에 가까웠습니다.

저희가 계획한 SAGE의 목표를 좀 더 풀어 보면 이렇습니다.

• 현재 단계에서는 공식 판단이나 확정 답변을 생성하기보다, 담당자가 빠르게 대응할 수 있도록 1차 자료 정리와 근거 확보를 자동화합니다.
• Slack 채널 문의처럼 좀 더 빠른 대응이 필요한 환경에서는 AI가 먼저 안전한 1차 안내를 제공해 대응 공백을 줄입니다.
• 추가 정보가 필요한 부분은 AI가 먼저 짚어 두어, 담당자와 의뢰자 사이의 추가 확인 라운드 자체를 줄입니다.
• 결과적으로 담당자의 숙련도 차이에서 오는 답변 품질·시간 편차를 줄이고, 의뢰자는 보다 일관된 품질의 응대를 더 빨리 받을 수 있도록 합니다.
• 의뢰자와 담당자 모두에게 ‘어떤 자료·규정을 봐야 하는지’를 빠르게 알려 줍니다.

이 글에서는 그 목표를 위해 만든 SAGE의 세 진입점 — 보안 상담 어시스턴트(Jira 기반), 보안 운영 안내 어시스턴트(Slack 기반), 보안 분석 워크벤치(담당자용 웹) — 을 어떤 구조로 만들고, 어떻게 운영하고 있는지 하나씩 차례로 설명드리겠습니다.

SAGE는 어떤 시스템인가요 — 전체 구조 한눈에 보기

SAGE는 단일한 챗봇이 아니라, 세 개의 진입점이 같은 보안 지식 자산과 공통 AI 오케스트레이션 레이어를 공유하는 플랫폼입니다. 진입점마다 ‘작동 시점’, ‘답변이 도달하는 위치’, ‘답변에 들어가는 정보의 형태’가 다릅니다. 또한 각 진입점에서 시작하는 워크플로는 하나의 거대한 AI 에이전트로 구성된 워크플로가 아니라, 세부 작업 단계마다 전담 AI 에이전트를 둔 멀티 에이전트 워크플로입니다.

플랫폼 전체 구조

세 진입점 비교

다음은 세 진입점의 특성을 비교한 표입니다.

항목	보안 상담 어시스턴트(Jira 기반)	보안 운영 안내 어시스턴트(Slack 기반)	보안 분석 워크벤치(담당자용 웹)
운영 단계	사내 파일럿 운영 중	실 운영 중	실 운영 중
트리거	티켓 생성 · 댓글 이벤트	채널 메시지	담당자가 직접 실행
주 사용자	상담 의뢰자 및 보안 컨설팅 담당자	사내 임직원 및 보안 운영 담당자	보안 담당자(ISM · 운영 등) + 일부 기능은 전 임직원으로 확대 중
답변 위치	티켓 코멘트	Slack 스레드	웹 UI 결과창
답변의 목적	보안 상담을 위한 근거·의견·확인 항목 제공	사용자에게 안전한 1차 안내 제공	담당자용 분석 도구
사용자 직접 노출	티켓에 자동 댓글로 노출	Slack 스레드에 자동 안내 노출	실행한 사용자의 화면에만 노출
사람 검토 방식	자동 댓글 후 담당자 검토	자동 게시 후 필요 시 후속 검토	담당자 직접 실행 및 검토
답변 책임 경계	담당자용 참고 제안(공식 판단 아님)	사용자용 참고 안내(공식 판단 아님)	담당자 검토용 분석 결과

이 표에서 가장 중요한 행은 ‘답변 책임 경계’입니다. 보안 상담 어시스턴트는 담당자가 답변을 쓰기 전에 책상 위에 정리된 자료를 놓아 두는 역할이고, 보안 운영 안내 어시스턴트는 담당자가 즉시 응대하지 못하는 시점에도 사용자가 안전한 1차 안내를 받을 수 있게 하는 역할입니다. 보안 분석 워크벤치는 같은 워크플로를 담당자 본인이 직접 실행할 때 사용하는 분석 도구입니다.

세 진입점의 노출 방식은 다르지만, 목적은 같습니다. 이번 글에서 다루는 단계의 목표는 보안 담당자를 대체하는 것이 아닙니다. 담당자의 손이 닿기 전에 자료를 모아 1차 정리를 끝내 두고, 담당자의 1차 응대가 어려운 시점에는 사용자가 다음 행동을 시작할 수 있는 안내를 먼저 제공해서, 담당자가 더 빠르고 일관되게, 더 높은 품질로 답변하고 검토할 수 있도록 돕는 것이 목적입니다.

기술 스택 한눈에 보기

위 구조의 각 영역이 실제로 어떤 도구로 구성되어 있는지 살펴보겠습니다.

영역	사용 기술/도구	역할
AI 워크플로 오케스트레이션	Langflow	로우코드 기반 AI 에이전트 · 워크플로 구성과 실행
생성 모델(LLM)	GPT 계열(OpenAI)	AI 에이전트의 의도 분류 · 추론 · 답변 생성
관찰성 · 트레이스	Langfuse	실행 트레이스 적재, 주간 운영 리포트의 데이터 소스
외부 시스템 통합(도구 호출)	MCP(Model Context Protocol, Atlassian 계열 등)	Jira · Confluence 읽기 / 쓰기, 규정·가이드 원문 실시간 조회를 AI 에이전트의 도구로 노출
벡터 검색(RAG(retrieval-augmented generation), 검색 증강 생성)	OpenSearch Vector Store + Embedding Model	과거 상담 · 운영 노하우 임베딩 인덱스
사내 지식 소스	Confluence 위키 · Jira 티켓	규정 · 가이드 본문과 상담 이력
워크벤치 백엔드	FastAPI	REST API · UI 라우터 · Langflow 프록시
워크벤치 프론트엔드	htmx 기반 웹 UI	서버 렌더링 + 부분 갱신
세션 · 공유 저장소	인메모리 키-값 저장소	세션 · 공유 데이터 저장

실제 추론과 답변 생성은 GPT 계열(OpenAI) 모델이 맡고 있으며, 워크플로의 난이도·비용에 따라 모델 크기와 추론 강도(reasoning effort)를 워크플로마다 다르게 선택합니다. 가벼운 분류·정규화에는 작은 모델을, 규정 해석이나 복잡한 상담 정리에는 더 큰 모델·더 높은 추론 강도를 쓰는 식입니다.

이 구성에서 Langflow는 워크플로 구성과 실행을 맡고, GPT 계열 모델은 추론과 답변 생성을 담당합니다. Langfuse는 실행 과정을 관찰하고, MCP는 Jira · Confluence 같은 외부 시스템을 AI 에이전트가 호출할 수 있는 도구로 연결합니다. OpenSearch · Confluence · Jira는 과거 상담, 규정, 운영 노하우를 찾기 위한 지식 소스로 사용합니다. 각 진입점이 위 도구를 실제로 어떻게 조합해 쓰는지는 이어지는 장에서 워크플로 단위로 풀어 보겠습니다.

보안 상담 어시스턴트(Jira 기반) — 보안 상담 티켓의 첫 검토를 돕기

풀고 싶었던 문제

세 진입점 중 워크플로를 가장 정교하게 설계한 것이 보안 상담 어시스턴트입니다. 보안 상담 티켓이 시스템 관점에서 가장 ‘길고 복잡한’ 입력이기 때문입니다.

보안 상담 티켓의 평균적인 모습은 이렇습니다.

• 본문 자체가 깁니다. 신청 부서·사용 데이터 항목·외부 송수신 여부·일정·첨부 자료 같은 항목이 줄줄이 들어갑니다.
• 댓글 흐름에 정보를 정정한 이력이 끼어 있을 수 있습니다. 처음에 적은 정보가 댓글에서 수정되거나, 같은 질문에 대한 새 조건이 추가되기도 합니다.
• 참고 자료 링크(다른 티켓 번호 · 위키 URL 등)가 본문과 댓글 곳곳에 존재합니다.

담당자(보통 ISM(Information Security Manager) 역할의 보안 담당자)는 이 입력을 받아 답변을 쓰기 전에 보통 다음 단계를 거칩니다.

1. 티켓 본문과 댓글 다시 읽기
2. 비슷한 과거 상담 찾기
3. 관련 규정 조항 떠올리기
4. 어떤 정보가 더 필요한지 정리하기
5. 모은 근거와 본인의 전문 지식을 합쳐 분석하고, 어떻게 답할지 판단하기

보안 상담 어시스턴트의 목적은 이 가운데 손이 많이 가는 1~4단계(읽기·검색·근거·정리)를 자동으로 끝내 두는 것입니다. 가장 중요한 5단계(근거를 종합해 분석하고 판단하는 일)는 그대로 담당자에게 남깁니다. 즉 답변을 대신 쓰는 것이 아니라, 담당자가 분석과 판단을 시작할 때 책상 위에 ‘이미 정리된 자료’가 놓여 있게 만드는 것입니다.

참고로 현재 보안 상담 어시스턴트는 사내 파일럿 운영 단계에 있습니다. 실 운영 티켓을 대상으로 자동 댓글이 게시되지만, 모든 출력은 담당자 검토를 전제로 합니다. 사용 피드백은 사내 정기 설문 채널을 통해 실제 보안 상담 업무 담당자로부터 일정 주기로 수집하고 있으며, 그 피드백을 바탕으로 답변 정책과 워크플로를 점진적으로 개선하고 있습니다.

작동 흐름 — 티켓이 처리되는 과정

한 건의 티켓이 누구와 어떤 순서로 상호작용하며 처리되는지를 시퀀스 형태로 보면 다음과 같습니다.

내부적으로 보안 상담 어시스턴트는 하나의 거대한 AI 에이전트가 아니라, 각 단계를 전담하는 여러 AI 에이전트가 이어 붙은 멀티 에이전트 플로로 구성돼 작동합니다. 이 흐름은 크게 다음 다섯 단계로 정리할 수 있습니다.

근거 수집 단계에는 네 개의 보조 워크플로가 등장하며 각각 호출 조건이 다릅니다.

보조 워크플로	호출 조건
규정 검토	외부 송신 · 국외 이전 · 위탁 같은 규정 축이 한 가지라도 걸리면 호출
유사 과거 상담 검색	사례 비교가 담당자 판단을 실제로 줄여 줄 가능성이 높을 때만 호출
정보 등급 판정	정보 등급 다툼이 핵심 쟁점일 때만 호출
조항 인용 보강	1차 근거가 모인 뒤, 답변 마무리 단계에서 필요한 경우에만 호출

AI 답변 정책

담당자가 검토하기 좋은 형태를 유지하기 위해 답변의 형식과 분량, 근거를 다루는 방식을 정책으로 정해 두었습니다.

AI의 댓글은 답변이 아니라 참고 제안으로만

보안 상담에서는 AI가 그럴듯하게 단정하는 것이 가장 위험합니다. 따라서 보안 상담 어시스턴트의 댓글은 다음과 같은 분리된 블록 구조로 작성됩니다.

구분	AI 에이전트가 정리하는 내용
먼저 볼 점	현재 문의에서 담당자가 우선 확인해야 할 쟁점
리스크	현 기재 내용 기준으로 문제가 될 수 있는 지점
판단 관점	규정 · 데이터 흐름 · 위탁 · 외부 서비스 이용 등 판단 축
누락 정보	답변 전에 추가로 받아야 할 정보
담당자 액션	담당자가 확인 · 비교 · 재상담해야 할 구체적 작업
참고 근거	관련 규정 · 문서 · 과거 상담의 보조 근거

블록 단위 구조에는 두 가지 의도가 있습니다.

• 첫째, 담당자가 어떤 티켓이든 같은 자리에서 같은 종류의 정보를 찾을 수 있게 만들기 위해서입니다. 답변마다 형식이 달라지면 결국 사람이 다시 정리해야 합니다.
• 둘째, 모델이 ‘창의적으로 답변 양을 늘리는 것’을 막기 위해서입니다.

또 한 가지 분명히 정해 둔 점은, 다음과 같은 사항을 금지해 AI 에이전트가 결론을 만들지 않게 만드는 것입니다.

• "이건 가능합니다” 혹은 “불가능합니다"와 같은 확정 판단
• "접수했습니다”, “처리하겠습니다”, “검토했습니다”와 같은 운영 팀 담당자처럼 보이는 표현
• 임의 추측에 기반한 규정 해석

답변 정책 안에 이런 표현을 명시적으로 금지하는 이유는 단순합니다. AI 코멘트가 ‘이미 운영 팀이 답한 것’처럼 보이는 순간 사람의 책임 경계가 흐려집니다. ‘AI는 정리·근거 모음·다음 행동 안내까지만 하고, 결론은 항상 사람에게 남긴다’는 원칙을 표현 차원에서도 명확히 고정해 두는 것이 휴먼 인 더 루프(human-in-the-loop) 운영, 즉 사람의 검토가 필수 단계로 들어가 있는 구조를 가능하게 합니다. 보안 상담 어시스턴트에서는 AI의 출력이 담당자의 검토·수정·승인 단계를 통과해야 공식 답변으로 이어집니다.

복잡도에 따라 답변 형태를 바꾸는 구조

보안 상담 어시스턴트는 티켓이 들어올 때마다 그 상담의 복잡도를 먼저 가늠한 뒤, 거기에 맞춰 답변의 깊이와 분량을 바꿉니다.

복잡도는 사람이 직관으로 매기지 않습니다. 보안 상담을 까다롭게 만드는 여러 검토 축(데이터의 흐름, 외부 노출 가능성, 계약·운영 구조, 정보 등급의 모호함 등 보안 도메인에서 반복적으로 등장하는 판단 요소들)을 내부 정책으로 정의해 두고, 각 축이 이번 상담에 해당하는지를 점검합니다. 그 점검 결과를 내부 조합 값으로 합쳐 간단 · 보통 · 복잡 세 단계 중 어디에 가까운지를 결정합니다(구체적인 축의 종류·가중치·임계값은 운영 정책 영역에 속하기 때문에 본 글에서는 추상화해 표현합니다).

세 단계의 답변은 대략 다음과 같이 달라집니다.

• 간단(simple): 담당자가 먼저 봐야 할 포인트와 1차 담당자 액션 한두 건만 짧게 정리합니다.
• 보통(medium): 위에 더해 리스크, 판단 관점, 추가로 받아야 할 정보 블록을 함께 보여 줍니다.
• 복잡(complex): 위에 더해 사전 조건, 추가 상담 트리거, 참고 문서 후보, 유사 사례 보강까지 펼쳐 보입니다.

이 설계에는 두 가지 약속이 들어 있습니다.

• 간단한 상담에는 의도적으로 짧게 답합니다. 단일 카테고리의 평이한 신청에 길게 정리된 답변이 붙으면 담당자가 핵심을 놓쳐 본문을 다시 읽게 만들 수 있습니다.
• 애매한 케이스는 낮은 복잡도로 잡습니다. 보통과 복잡 사이처럼 등급이 경계에 걸리면, 더 낮은 쪽으로 분류 합니다. AI가 ‘이건 복잡하다’고 잘못 보고 과도하게 긴 답변을 생성하는 것이, ‘이건 간단하다’고 짧게 답하는 것보다 담당자에게 더 큰 부담이라고 판단했기 때문입니다.

인용은 검증된 것만 노출

보안 답변은 ‘문서 어디의 어떤 문장’이 근거인지가 보일 때 신뢰가 생깁니다. 이에 따라 1차 검토에서 모인 조항 후보를 그대로 답변에 첨부하지 않고, 실제 위키 본문과 대조해 검증된 인용에만 검증 표시를 붙입니다. 본문 일치가 확인되지 않은 후보는 답변에 단정형 인용으로 노출하지 않습니다. 이때 규정·가이드 본문은 임베딩해 둔 사본이 아니라 MCP로 그때그때 원문을 실시간 조회해 대조합니다(임베딩 검색은 과거 상담·운영 노하우 쪽에 씁니다).

또한 여러 근거가 서로 충돌하면 금지 → 조건부 → 추가 확인 필요 → 특이사항 없음 순으로 더 엄격한 근거 정렬 기준을 적용합니다. AI가 “괜찮습니다”라고 단정해 버린 뒤 담당자가 뒤늦게 "사실 안 됩니다"로 정정해야 하는 상황을 시스템 차원에서 줄이자는 의도입니다.

가상 시나리오로 살펴보는 실제 처리 결과

이해를 돕기 위해, 실제와 유사한 상담 한 건을 사내 정보가 드러나지 않도록 가공해 가져왔습니다.

상담 내용: 한 부서가 업무용 대시보드 데이터를 매일 자동으로 가져와 사내 분석용 DB에 적재하려고 시스템 연동을 신청했습니다. 이 데이터는 외부로 나가지는 않지만, 사내에서 일정 등급 이상으로 분류된(사내 한정) 자료입니다. 이렇게 사내 시스템끼리 연결해도 괜찮은지를 문의해 왔습니다.

보안 상담 어시스턴트는 이 건을 '보통(medium)' 난이도로 보고, 다음과 같이 1차 정리해 주었습니다.

• 먼저 볼 점: 사내 시스템 간 연동 자체는 막히는 일이 아니지만, 통신 요건과 데이터가 쌓이는 쪽의 통제(접근 권한 · 보관 기간 · 꼭 필요한 권한만 부여)가 전제로 확인되어야 합니다.
• 리스크가 될 점: 구성도 · 데이터 흐름 · 항목 목록이 첨부되지 않으면 무엇이 어떻게 바뀌는지 확인이 부족해집니다. 그리고 — 만약 이 데이터가 나중에 외부 생성 AI로 들어가는 경로가 있다면, 그건 사내 연동과는 전혀 다른 논점이라 따로 확인해야 합니다.
• 추가로 필요한 정보: 두 시스템이 각각 어디에 있고 어떤 경로 · 암호화로 통신하는지, 가져온 데이터의 보관 기간 · 삭제 · 접근 기록은 어떻게 남는지, 그리고 이 데이터가 외부 AI에 투입 · 참조되는 구성이 있는지.
• 참고할 근거 (규정 · 가이드 링크 + 원문 인용): 위에서 짚은 항목마다, 근거가 되는 사내 규정 · 세부 지침 · 가이드 문서로 바로 가는 링크와 그 문서에서 그대로 가져온 원문 문장을 함께 달아 둡니다. 덕분에 답변을 쓰는 담당자도, 문의를 올린 사람도 "왜 이렇게 정리됐는지"를 출처에서 직접 확인하고, 봐야 할 문서로 한 번에 이동할 수 있습니다.
• 담당자 다음 액션: 구성도 · 통신 경로 · 암호화 · DB 접근 주체를 한 장으로 정리하고, 보관 기간 · 삭제 방침 · 최소 권한 설계를 정리해 필요 시 담당 부서와 확인.

보시는 바와 같이 보안 상담 어시스턴트는 "연결해도 된다” 혹은 “안 된다"를 단정하지 않습니다. 대신 현재 정보만으로 확인할 수 있는 점과 답변 전에 더 확인해야 할 지점을 구분해 둡니다. 예를 들어 "혹시 이 데이터가 외부 AI로도 흘러가나요?"처럼 사용자가 적지 않았지만 답이 크게 달라질 수 있는 조건을 먼저 짚어 주면서 담당자가 놓치기 쉬운 부분을 줄여 줍니다.

정기적인 피드백을 받으며 파일럿 단계 운영 중

보안 상담 어시스턴트는 현재 파일럿 단계입니다. 따라서 실제 보안 상담 업무 담당자가 자동 댓글을 보고 의견을 남길 수 있는 통로를 별도로 마련해 두었습니다. 각 담당자는 사내 정기 설문 채널을 통해 다음 항목과 관련해 정기적으로 피드백을 남기고 있습니다.

피드백 항목	무엇을 보는가
유용했던 부분	어떤 답변 블록이 실제 업무 검토에 도움이 됐는지
부족했던 부분	어떤 블록이 비어 있거나 잘못 짚었는지
인용 정확성	인용된 규정 · 사례가 실제로 관련 있었는지
누락된 판단 축	AI 에이전트가 짚었어야 할 검토 축이 빠져 있었는지
자유 의견	그 외에 개선이 필요한 부분

저희는 담당자가 남긴 피드백을 검토하면서 같은 종류의 패턴이 반복적으로 지적되면 이를 답변 정책의 규칙으로 옮깁니다. 이렇게 누적된 규칙이 다음 주기 답변에 반영되며, 그 결과를 다시 다음 설문에서 확인하는 사이클로 운영하고 있습니다.

보안 운영 안내 어시스턴트(Slack 기반) — 운영 채널의 1차 안내 답변

보안 상담 어시스턴트가 ‘길고 복잡한 입력’을 다룬다면, 보안 운영 안내 어시스턴트는 즉시 답변해야 하는 짧은 입력을 다룹니다.

다루는 채널의 특성과 어시스턴트의 목적

보안 운영 안내 어시스턴트는 현재 사내 보안 운영 문의 채널에서 실제로 운영되고 있습니다. 이 채널의 특성은 다음과 같습니다.

• 단말 보안 · 인증 · 외부 저장장치 · VPN 등의 보안 운영 도구 관련 사용자 문의가 모이는 곳입니다.
• 채널은 공개되어 있고, 사용자 누구나 글을 올리거나 답글을 볼 수 있습니다.
• 응답 시간이 곧 사용자 경험인 채널이라, 담당자가 즉시 응답하지 못하는 시간대에 대응 공백이 생기기 쉽습니다.

보안 운영 안내 어시스턴트가 이 채널에서 맡는 역할을 한 줄로 표현하면 이렇습니다.

"담당자가 답하기 전에, 사용자가 안전하게 다음 행동을 시작할 수 있는 1차 안내를 먼저 제공한다."

즉 이 안내 자체로 문제를 종결하는 것이 아니라, 사용자가 추가 정보를 모으거나, 안전한 1차 조치를 시도하거나, 적절한 담당자를 만날 수 있도록 길을 열어 두는 것이 목표입니다. 이렇게 함으로써 담당자가 자리를 비웠을 때 사용자의 대기 시간을 줄일 수 있고, 자리로 돌아온 담당자가 본격 응대를 시작할 때 어시스턴트가 이미 짚어 둔 정보를 토대로 더 빠르게 결론에 도달할 수 있습니다.

작동 흐름

운영 문의 채널의 워크플로도 단일 AI 에이전트가 아니라, 검색을 전담하는 AI 에이전트와 안내 답변을 작성하는 AI 에이전트, 이렇게 두 단계로 분리되어 있습니다. 각 단계를 하나씩 살펴보겠습니다.

사용자 문의가 들어오면, 먼저 사내 운영 노하우와 과거 상담 임베딩에서 ‘이 케이스에서 미리 봐 둬야 할 점’, ‘자주 등장하는 정답 패턴’, ‘지금 바로 해도 안전한 1차 조치’ 같은 정보를 모읍니다. 이 단계에서는 답변을 만들지 않고 분류/근거/즉시 실행해도 안전한 조치 후보/추정 원인을 한데 모은 정보 묶음(이하 '근거 패킷')을 만들어 다음 단계로 넘기는 데 집중합니다.

그다음, 그 근거 패킷을 들고 사내 규정 및 가이드 문서를 확인해 2차 검증을 거친 뒤 비로소 사용자용 1차 안내를 작성합니다. 사내 규정 본문이 안내 답변의 우선 근거이고, 운영 노하우는 그 근거를 보강하는 역할입니다. 검증이 안 되면 ‘일반론 + 담당 팀에 넘기기’ 방향으로 자동 전환합니다. 여기서 '담당 팀에 넘기기'란, AI가 공식 판단을 내리는 대신 담당 그룹을 멘션해 사람이 이어받도록 하는 것을 말합니다.

이렇게 두 단계로 분리한 구조 덕분에 운영 노하우가 빠르게 누적되어도 그 내용이 곧바로 사용자 답변에 단정형으로 들어가지 않습니다. 답변에 단정형으로 들어가려면 그 답변의 근거가 될 수 있는 사내 규정 본문이 있어야 합니다.

AI 답변 정책

이 채널의 답변 정책은 무엇을 어떻게 답할지에 대한 원칙과, 그 원칙을 운영 현장의 피드백으로 계속 갱신하는 구조로 이루어져 있습니다.

표면 증상에 속지 않기

이 채널에서 가장 자주 마주치는 함정은 표면 증상과 실제 원인이 다른 케이스입니다. 사용자가 "VPN이 안 돼요"라고 적었다고 해서, 자동으로 VPN 트러블슈팅으로 가지 않습니다. 그 뒤에 단말 보안 솔루션 상태나 MDM 등록 상태, 계정 상태와 같은 실제 원인이 숨어 있을 수 있기 때문입니다.

보안 운영 안내 어시스턴트는 표면 증상과 실제 원인을 의도적으로 분리해서 보도록 설계되어 있습니다. 답변 정책의 큰 원칙은 다음과 같습니다.

상황	피해야 할 것	우선해야 할 것
표면 증상이 원인이 아닐 수 있는 케이스	단순 키워드 기반의 라우팅	단말 보안 · 인증 상태 같은 실제 원인 분리 후 라우팅
일반 트러블슈팅	광범위한 점검 리스트 나열	직접 해당 케이스에 도움되는 한 가지 다음 행동

답변은 인사 · 본문 · (선택)참고 문서 · 주의 문구('AI 참고 안내이며 공식 판단이나 승인이 아님')의 네 부분으로 나눈 구조를 따르며, 문의가 들어온 언어와 동일한 언어로만 작성합니다. 즉 한국어 문의에는 한국어, 일본어 문의에는 일본어, 영어 문의에는 영어로만 답합니다.

운영 팀의 의견을 개발 팀에서 지속적으로 반영할 수 있는 구조로 설계

저희가 SAGE를 만들면서 가장 중요하게 여긴 의사결정 하나를 꼽으라면, 이 시스템을 ‘개발 팀이 한 번 지시문(프롬프트)을 잘 정리하면 끝’이라는 가정으로 만들지 않았다는 것입니다. 그 대신 운영 팀에서 매주 누적되는 사례를 검토해 문제 패턴과 이상적인 답변 방향을 정리하면, 개발 팀에서 그 내용을 답변 정책의 별도 영역에 지속해서 반영할 수 있도록 구조를 나눠 두었습니다.

실제 문의의 맥락과 이상적인 답변 방향을 가장 잘 아는 운영 팀에서는 운영 업무 중 반복해서 나타나는 케이스별 규칙을 개발 팀으로 전달합니다. 예를 들어 다음과 같습니다(실제 규칙은 추상화).

• 외부 저장 장치 신청이 거부됐다는 문의가 오면, 거부 사유 확인 전에 호스트명과 시리얼 번호의 오기재 · 교차 입력을 먼저 의심한다.
• VPN 접속 실패 문의가 와도, 특정 단말 보안 도구의 상태가 단서로 나오면 일반 헬프데스크로 보내지 말고 그 도구의 재설치 안내를 먼저 한다.
• 인증 도구의 단말기 변경 / 분실 케이스는 다른 케이스와 다른 신청 폼으로 안내한다.

위와 같이 운영 팀에서 반복되는 실패 패턴과 개선 가이드를 운영 언어로 정리해서 전달하면 개발 팀은 그 내용을 시스템 지시문과 답변 정책에 안전하게 반영합니다. 이때 시스템 전체 지시문을 건드리는 것이 아니라 이 영역의 규칙만 추가 · 수정 · 비활성화합니다. 이렇게 하면 ‘이번 주에 같은 실수가 다섯 번 반복됐다’ → ‘다음 주부터는 그렇게 답하지 않게 한다’는 개선을 작은 단위로 반영할 수 있습니다.

여기서 핵심은 ‘답변 정책 전체를 다시 수정하지 않고, 한 섹션만 수정한다’는 것입니다. 정책 전체를 통째로 수정하면 의도하지 않은 부작용이 다른 케이스로 번지기 쉬운데, 한 줄짜리 규칙으로만 다루도록 영역을 분리해 두면 변경의 영향 범위가 좁아집니다. 이를 통해 운영 팀 입장에서는 ‘문제 패턴과 개선 가이드 전달 → 개발 팀에서 규칙 반영 → 다음 답변에서 확인’이라는 빠른 피드백 루프를 확보할 수 있습니다.

매주 더 정확해지는 피드백 루프

Slack 답변 맨 아래에는 "도움이 됐어요”, “아쉬워요"처럼 답변을 평가하는 버튼이 함께 붙습니다. 사용자가 이 버튼을 누르면 피드백 루프가 시작됩니다.

이 피드백 루프는 사람이 검토자로서 품질 개선 사이클의 필수 단계로 참여하는 휴먼 인 더 루프 리뷰(human-in-the-loop review) 구조입니다. AI의 참고 제안이 담당자 검토를 거쳐야 공식 답변으로 이어지는 보안 상담 어시스턴트와 달리, 이 채널에서는 1차 안내가 사용자에게 먼저 자동 게시됩니다. 따라서 사람의 개입 지점을 답변 한 건 한 건의 승인이 두지 않고, 게시된 답변 전체를 주기적으로 검토해 답변 정책에 반영하는 쪽에 두었습니다. AI의 답변과 사용자 반응을 자동으로 수집해서 정리하면, 운영 팀은 그중 복잡하거나 품질 개선이 필요한 케이스를 검토해 다음 답변 정책에 반영합니다.

단계	누가	무엇이 산출되나
① 수집	시스템(자동)	모든 AI 답변과 사용자 반응(👍 / 👎 / 무반응), 담당자 호출 클릭 흔적이 관찰성 도구에 적재됩니다
② 리포트	시스템(자동, 주 1회)	한 주의 관측 건수, 카테고리 분포, 부정 피드백 케이스별 입력 · 출력 · 근거가 정리된 마크다운 리포트가 자동 생성됩니다
③ 검토	운영 팀	부정 피드백 사례마다 ⓐ 문제점 정리, ⓑ 이상적인 1차 답변안, ⓒ 개발 팀에 전달할 개선 가이드의 3단 코멘트를 직접 작성합니다.
④ 반영	개발 팀	위 코멘트를 바탕으로 답변 정책의 피드백 규칙을 갱신합니다. 이를 통해 다음 주 동일 케이스에서는 답변이 달라집니다.

보안 분석 워크벤치(담당자용 웹) — 담당자가 직접 고르는 분석 도구

보안 상담 어시스턴트와 보안 운영 안내 어시스턴트가 ‘이벤트가 트리거하는’ 반응형 시스템이라면, 보안 분석 워크벤치는 보안 담당자가 직접 원하는 순간에 워크플로를 골라 실행하는 담당자 주도형 분석 도구입니다.

누가 언제 쓰나요

보안 분석 워크벤치는 사내 보안 담당자(ISM 등)가 브라우저에서 사용하는 웹 UI입니다. 사내 인증 시스템과 연동되어 있어, 허가된 보안 담당자만 접근할 수 있습니다.

이 시스템의 특징은 트리거가 사람이라는 점입니다. 채널 메시지나 티켓 이벤트를 기다리는 것이 아니라, 담당자가 ‘지금 이 자료를 분석해야겠다’고 결정한 순간에 워크플로를 골라 실행하는 방식입니다.

4종 워크플로

현재 보안 분석 워크벤치에는 다음과 같은 네 가지 워크플로가 포함돼 있습니다.

워크플로	무엇을 해주나요
기밀성 구분 판정(정보 등급 판정)	입력 데이터 · 문서가 사내 기밀성 기준상 어느 등급에 해당하는지 후보를 제안
유사 사례 검색	입력한 상담 내용과 비슷한 과거 보안 상담 티켓을 찾아 비교
보안 규정 · 프로세스 안내	"이런 경우 어떤 규정을 따라야 하나요?"처럼 일상 언어로 질문하면, 관련 규정을 찾아 결론을 먼저 안내하고 그 근거가 된 규정 문장을 원문 그대로 함께 제시
협력사 보안 준수 사항 체크	협력사와 함께 업무를 진행할 때 지켜야 할 보안 준수 사항을 갖추고 있는지 살펴보고, 보완이나 추가 확인이 필요한 부분을 정리

네 워크플로 모두 하나의 챗봇 UI에 무리하게 통합하지 않았습니다. 입력과 출력의 형태가 다른 별도의 도구로 분리했습니다. 기밀성 구분 판정에는 짧은 텍스트가 입력으로 들어가고, 협력사 보안 준수 사항 체크 등에는 점검 문서 전체에 가까운 긴 입력이 들어가기 때문에 각자 다른 결과 화면이 적합합니다.

이 네 가지가 끝은 아닙니다. 현장에서 새로 필요해지는 도구는 그때그때 설계 및 구현해 계속 추가해 나갈 계획입니다.

운영 모델 — 여러 부서가 함께 만들고 운영합니다

이번 섹션에서는 시스템 이야기에서 사람 이야기로 잠깐 넘어가 보겠습니다.

코어 팀과 협업 부서

현재 워크플로와 채널, 도구 구현과 인프라 운영 같은 기술 영역은 Security Development Division이 담당하고 있습니다.

협업하는 보안 부서는 진입점과 워크플로마다 다릅니다. 각 부서가 사용하는 규정 · 답변 톤 · 근거 문서도 모두 다르기 때문에, ‘전체에 적용되는 하나의 정답’을 만드는 대신 ‘업무 라인마다 다른 규칙 묶음을 두고 운영 팀의 개선 가이드를 해당 묶음에 반영한다’는 구조가 자연스럽게 자리 잡았습니다.

AI와 사람의 역할 분담

세 진입점은 모두 ‘AI가 공식 판단을 확정하지 않는다’는 원칙을 공유하지만, 출력이 사용자에게 노출되는 방식은 다릅니다. 그래서 운영 모델도 하나의 표준 모델을 설정한 것이 아니라 진입점별로 책임 모델로 나눴습니다.

진입점	AI(SAGE)가 하는일	사람(담당자)가 하는 일	책임 경계
보안 상담 어시스턴트	티켓을 읽고 관련 규정 · 사례 · 누락 정보를 정리해 담당자용 참고 제안 댓글을 게시	댓글을 검토하고 부서 정책에 맞춰 공식 답변 작성 및 확정	AI 댓글은 담당자 검토용 참고 제안이며 공식 판단이 아님
보안 운영 안내 어시스턴트	정해진 응답 원칙에 따라 사용자용 1차 안내를 Slack 스레드에 자동 게시하고, 근거가 부족하면 담당 팀에 넘김	필요 시 스레드를 이어받아 정정 · 보완 · 최종 처리	AI 안내는 공식 판단이나 승인이 아님
보안 분석 워크벤치	사용자가 선택한 워크플로에 따라 분석 결과 · 근거 · 후보를 화면에 제공	결과를 검토해 실제 업무 판단에 활용	실행한 사용자의 검토용 참고 자료이며, 활용 판단의 책임은 사용자에게 있음
피드백 루프	사용자 반응 · 실행 트레이스 · 설문 피드백을 모아 리포트로 정리	운영 팀이 문제 패턴과 이상 답변 방향을 정리하고, 개발 팀이 답변 정책의 규칙으로 반영	정책 갱신은 운영 팀 검토와 기술 반영을 거쳐 적용

운영 원칙은 단순합니다.

• 현재 단계에서는 사람의 판단을 대체하지 않습니다. 담당자가 답변을 시작하기 전에 들이는 1차 정리 시간을 줄이고, 담당자가 바로 응대하기 어려운 순간에는 정해진 범위 안에서 안전한 1차 안내를 제공하는 것이 목표입니다.
• 단정하지 않습니다. 모든 자동 응답은 참고 제안이나 참고 안내임을 명시하며, 공식 판단이나 승인을 대신하지 않습니다.
• 수치보다 패턴을 봅니다. 일주일에 답변이 몇 건이고 피드백 비율이 어떻다는 숫자도 분명 의미가 있지만, 저희가 그보다 더 깊이 보는 것은 ‘어떤 종류의 답변에 운영 팀의 손이 가장 많이 가는가’와 같은 패턴입니다. 패턴은 규칙으로 옮길 수 있지만, 단순 비율은 그대로 옮기기 어렵기 때문입니다.

만들면서 배운 것

SAGE를 만들고 운영하면서 저희가 얻은 것을 네 가지로 줄여 보겠습니다. 이것이 정답은 아닙니다. 다루는 데이터나 업무 프로세스, 책임 경계가 달라지면 답도 달라질 수 있기 때문입니다. 저희 상황에 맞는 선택이라고 할 수 있겠습니다.

범용 챗봇 대신 도메인별 워크플로로 나눴습니다

모든 질문을 하나의 AI 에이전트에 맡기면 답변은 그럴듯해질 수 있지만, 저희 경험으로는 업무 책임과 근거 우선순위가 흐려지기 쉬웠습니다. 그래서 보안 상담 · 운영 문의 · 정보 분류 · 절차 안내 · 규정 검토를 서로 다른 워크플로로 나눴습니다. 저희 상황에서는 이렇게 하는 것이 더 안정적이었습니다. 특히 새 보안 부서나 새 케이스가 합류할 때 기존 워크플로를 건드리지 않고 새로 붙일 수 있는 구조가 유용했습니다. 분리가 잘 되어 있으면 한쪽의 정책 변경이 다른 쪽 답변을 흔들지 않았습니다.

AI가 답을 단정하기보다는 무엇을 확인해야 하는지를 짚도록 했습니다

보안 관련 도메인의 업무에서 가장 위험한 것은 정보가 부족한데도 AI가 그럴듯한 결론을 내버리는 것입니다. 그래서 저희는 판단에 필요한 정보가 빠졌다면 "지금은 판단할 수 없다"고 말하고, 동시에 "어떤 자료 · 규정 · 정보를 봐야 하는지"를 짚도록 했습니다. 현재 단계에서 좋은 답변은 AI가 결론을 대신 내리는 것이 아니라, 사람이 최종 판단을 이어갈 수 있도록 근거와 확인 항목을 정리해 주는 것이었습니다.

검색 품질은 모델보다 자료의 정리·인덱싱에 더 좌우됐습니다

RAG 기반 AI 에이전트의 답변 품질은, 적어도 저희 경험으로는 모델의 똑똑함보다 ‘찾아야 할 자료가 얼마나 잘 정리되고 구조화되어 있는가’에 더 크게 좌우됐습니다. 같은 모델이라도 규정·가이드·과거 사례·운영 매뉴얼이 검색하기 좋은 형태로 정리돼 있으면 근거를 정확히 집어 왔고, 그렇지 않으면 엉뚱한 문서를 가져오거나 "근거 없음"에서 멈추곤 했습니다.

근거가 되는 자료 자체가 잘 정리되어 있어야 한다는 점은 모델이나 워크플로 바깥의 일입니다. 현재 이 부분은 각 자료를 관리하는 담당 부서들이 꾸준히 정리하고 최신 상태로 다듬어 주고 있으며, 그 토대 위에서 AI 에이전트의 검색이 작동하고 있습니다. 저희가 직접 맡는 부분은, 이렇게 정리된 자료를 다음과 같이 AI 에이전트가 더 잘 찾을 수 있는 형태로 만드는 쪽입니다.

• 필요한 경우 큰 줄기를 미리 인덱싱해 둡니다. 세부 문서를 바로 뒤지기 전에 ‘어떤 종류의 질문이 어떤 규정·문서 묶음으로 이어지는지’ 같은 상위 인덱스를 먼저 두면 검색의 길잡이가 됩니다.
• 문서 본문에 흩어져 있는 처리 히스토리나 맥락 같은 추가 정보를 임베딩해 두어, 본문 표현만으로는 걸리지 않는 질문에도 관련 근거가 검색되도록 합니다.

이 작업은 한 번에 끝나지 않습니다. 자료가 계속 바뀌고 새로운 사례가 쌓이기 때문에 인덱싱과 임베딩을 다듬는 일은 시간이 많이 드는 작업이며, 운영하면서 꾸준히 고도화해 나가고 있는 영역입니다.

운영 피드백을 별도 기능이 아니라 핵심 워크플로로 두었습니다

AI 에이전트는 배포했다고 저절로 좋아지지 않았습니다. 저희는 실제 문의 · 사용자 반응 · 운영 담당자가 제시한 이상적인 답변안 · 정기 리포트 · 설문 기반 피드백을 바탕으로 계속 고쳐 왔습니다.

SAGE에서는 이 피드백 루프가 품질 개선의 중심이었고, 운영 팀의 개선 가이드를 한 줄의 규칙으로 반영할 수 있는 영역을 답변 정책 안에 분리해 두는 것이 핵심 설계 결정 중 하나였습니다. 보안 운영의 언어로 개선 방향을 정리하면, 개발 팀이 이를 작은 규칙으로 옮겨 다음 주기 답변에 반영합니다. 답변 검토는 운영 담당자가 맡고, 정책 갱신은 개발 팀이 수행하며, 그 결과가 다시 운영 피드백으로 돌아오는 이 사이클이 보안 도메인에서 사람과 AI의 협업이 실제로 작동하는 모습이라고 생각합니다.

다음 이야기

이번 글은 SAGE의 기술 설계와 운영 관점을 다뤘습니다. SAGE는 저희 Security Development Division이 워크플로 · 인프라 · 기술 방향을 맡고, AI 에이전트의 업무 정의 · 정책 결정 · 피드백은 협업하는 보안 부서들과 함께 만들어 가고 있습니다.

그중에서도 서두에서 말씀드린 세 단계 중 1단계(사람이 최종 판단을 쥐고 AI가 1차 정리를 돕는 방식)에 초점을 맞췄습니다. 현재 여러 에이전트가 협업하는 구조와 정형 업무 자동화를 이미 일부 워크플로에서 시도하고 있지만, 검증된 만큼만 실무에서 확인하며 넓혀 갈 생각입니다. 다음 편에서는 그다음 단계의 진행 상황과 협업 부서 관점의 이야기를 이어가 보려 합니다.

돌아보면, 보안 업무에 AI를 적용할 때 정말 중요한 것은 어떤 모델이나 도구를 도입하느냐보다, 사람과 AI 사이의 책임 경계를 어디에 그어 두느냐였습니다.

긴 글 읽어 주셔서 감사합니다. 다음 편에서 다시 뵙겠습니다.