벤더 지원 케이스에는 실제 운영에서 얻은 강한 힌트가 많이 담깁니다. 그러나 티켓·메일·첨부 로그·릴리스 노트·지식 문서가 분산되어 있으면, 비슷한 문제가 다시 발생했을 때 그 힌트를 다시 찾기 어렵습니다. Vendor Support RCA Copilot은 이 반복을 줄이기 위해, Outlook의 긴 지원 메일 스레드를 사람이 검토할 수 있는 한국어 RCA 초안으로 바꾸는 Azure AI 기반 프로토타입입니다.
이 글에서 말하는 Copilot은 티켓을 대신 답변하는 챗봇이 아니다. 새 incident의 관찰 사실을 고정하고, 과거 지원 기록과 제품 문서에서 관련 근거를 찾고, 현재 환경에서 검증할 질문을 구성하는 조사 워크스페이스에 가깝다. 지원 조직의 가장 값비싼 자산은 답변 문장 자체보다, 어떤 조건에서 무엇을 확인했고 왜 그 결론을 신뢰했는지에 있다. 그 맥락이 사라지면 검색 결과가 많아져도 운영자는 다시 처음부터 조사하게 된다.
네 시간의 구현에서 무엇을 끝까지 가져갔는가
이 프로젝트는 2026 Cheonha Jeil Lip Coding Competition에서 키보드 입력 없이 음성 코딩으로 약 네 시간 안에 구현·배포한 솔로 프로젝트다. 시간 제약이 컸기 때문에 “지원 메일을 모두 이해하는 완전한 지식 시스템”을 목표로 잡지 않았다. 대신 MSP 엔지니어가 긴 메일 스레드에서 필요한 맥락을 읽고, RCA를 생성하고, 사람이 검토한 뒤 문서·Slack으로 넘기는 하나의 닫힌 흐름을 끝까지 만드는 데 집중했다.
그 선택은 기능을 적게 넣기 위한 것이 아니라, 결과물이 실제 업무 흐름에 남을 수 있는지를 검증하기 위한 것이었다. 데모에서 보이는 티켓 목록, 메일 스레드, RCA 생성, 섹션별 수정, Word 내보내기, Slack 공유는 서로 독립된 화면이 아니다. 각각이 “누가 어떤 근거를 읽고, 어떤 내용을 검토한 뒤, 어디에 공유하는가”라는 같은 질문에 답해야 했다.
메일 스레드를 RCA 여섯 섹션으로 바꾸는 흐름
초기 MVP에서 사용자는 Support Tickets 목록에서 티켓 하나를 연다. 메일 스레드와 첨부된 맥락을 읽은 뒤 RCA 생성을 실행하면, 백엔드는 메일 내용을 구조화하고 생성 결과를 스트리밍한다. 결과는 다음 여섯 섹션으로 나뉜다.
- 장애 요약 — 사용자 영향과 현재 증상을 짧게 고정한다.
- 타임라인 — 메일과 운영 이벤트를 시간순으로 남긴다.
- 근본 원인 — 원인으로 판단한 근거와 전제를 설명한다.
- 조치 내역 — 이미 수행한 완화·복구 작업을 구분한다.
- 재발 방지 대책 — 다음 변경 또는 확인이 필요한 항목을 제안한다.
- 미해결 사항 — 아직 근거가 부족하거나 추가 확인이 필요한 질문을 남긴다.
여기서 중요한 것은 여섯 개의 그럴듯한 문단을 만드는 일이 아니다. 모든 섹션이 메일 원문과 현재 조사 조건으로 다시 돌아갈 수 있어야 한다. 예를 들어 타임라인의 한 항목은 어느 메일·시각에서 왔는지, 근본 원인 문장은 어떤 관찰과 조건에 기대는지, 미해결 사항은 무엇을 확인하면 해소되는지를 보여 줘야 한다. 생성 결과는 바로 전송되지 않으며, 엔지니어가 섹션별로 수정하고 검토한 뒤에만 export 또는 공유 흐름으로 넘어간다.
실제 아키텍처가 지키는 경계
아키텍처의 중심은 React SPA와 Azure Functions를 나눈 경계다. App Service에서 실행되는 프론트엔드는 Microsoft Entra ID를 통해 로그인하고, API 호출에는 토큰을 사용한다. Azure Functions는 Microsoft Graph API로 Outlook 메일 스레드를 조회하고, GitHub Models의 GPT-4o 및 Copilot SDK Agent로 RCA 초안을 만든다. 생성·검토·문서화·공유는 백엔드 흐름에서 서로 다른 책임으로 나뉜다.
Storage Account는 RCA 문서와 운영 데이터를 보관하고, Application Insights는 로그·성능 신호를 남긴다. Key Vault에는 GitHub Models 토큰과 Slack webhook처럼 런타임에 필요한 비밀값을 두고, Functions의 Managed Identity가 이를 참조한다. 즉 비밀값을 코드나 배포 설정에 직접 박아 넣지 않는다. GitHub Actions는 Bicep 기반 인프라 배포, 프론트엔드·백엔드 빌드, 품질 검사, secret scan, health check를 연결한다.
이 그림에서 화살표가 많아 보이는 이유는 기술을 과시하기 위해서가 아니다. 메일을 읽는 경로, AI가 결과를 생성하는 경로, 사람이 검토한 결과가 Word와 Slack으로 나가는 경로, 그리고 시크릿·로그·배포가 통제되는 경로를 분리해야 운영자가 각 책임과 위험을 확인할 수 있기 때문이다.
다중 Agent가 답변의 범위를 나누는 방식
Copilot SDK 기반 흐름은 하나의 거대한 프롬프트가 모든 일을 맡는 구조가 아니다. MailParserAgent가 메일 스레드를 파싱·정리하고, RCAGeneratorAgent가 한국어 RCA 여섯 섹션을 만든다. ReviewAssistantAgent는 재생성·질의응답·검토를 돕고, ExportAgent는 Word 생성과 Slack 공유를 담당한다. CI/CD의 QualityGuardAgent는 lint, test, secret scan 같은 품질 경계를 지킨다.
이 역할 분리는 결과를 더 길게 만들기 위한 장치가 아니다. 메일에서 관찰한 사실을 정리하는 단계, 그 사실로 RCA 초안을 구성하는 단계, 사람이 결과를 수정하는 단계, 외부로 공유하는 단계를 구분하기 위한 것이다. 특히 공유 단계가 생성 단계와 분리되어 있으므로, 모델이 만든 문장이 승인 없이 Slack 채널이나 문서로 전달되지 않는다.
지원 티켓을 데이터가 아니라 사건 기록으로 읽기
하나의 지원 티켓에는 여러 종류의 정보가 섞여 있다. 고객이 설명한 증상, 실제 로그와 스크린샷, 담당자가 요청한 추가 정보, 벤더의 가설, 해결을 위해 수행한 조치, 그리고 후속 버전에서 바뀐 동작이 모두 같은 대화 안에 남는다. 이 조각을 통째로 임베딩해 검색하면, 그럴듯한 문장을 가져올 수는 있어도 무엇이 관찰 사실이고 무엇이 추정인지 알기 어렵다.
그래서 수집 단계부터 케이스를 사건 단위로 재구성하는 것이 필요하다. 시간, 제품 버전, 구성·정책, 발생 조건, 관찰 신호, 실행한 조치, 결과, 확인되지 않은 가정을 분리한다. 첨부 로그는 원문과 출처를 유지하되, 조사에 필요한 시간 창과 신호로 연결한다. 이 구조가 있으면 Copilot은 “비슷한 티켓 5건” 대신 “현재 incident와 조건이 겹치는 2건, 그러나 버전과 설정이 다른 지점”을 보여 줄 수 있다.
조사 흐름은 현재 증거에서 시작한다
새 incident가 들어오면 먼저 현재의 문제 진술을 짧게 고정한다. 어떤 서비스가, 언제부터, 어떤 사용자 영향과 함께, 무엇이 달라졌는지 적는다. 이어서 라이브 환경에서 얻은 로그·메트릭·이벤트·변경 이력을 관찰 사실로 별도 저장한다. 이 단계가 먼저여야 과거 지식이 현재 상황을 덮어쓰지 않는다.
그 다음에 Copilot은 제품 문서와 지원 케이스를 후보로 가져온다. 각 후보에는 유사한 점뿐 아니라 적용 조건과 차이를 붙인다. 예를 들어 과거 케이스가 특정 버전의 timeout 설정에서 발생했다면, 현재 환경의 버전과 설정값이 확인되기 전에는 remediation이 아니라 검증 질문으로 보여 준다. 운영자가 후보를 열었을 때는 원문 인용, 출처 링크, 조사에 쓸 수 있는 확인 명령 또는 콘솔 경로를 함께 볼 수 있어야 한다.
검색 결과가 곧 결론이 되지 않게 하기
가장 위험한 형태는 과거 케이스와 키워드가 비슷하다는 이유만으로 원인을 확정하는 것입니다. Copilot은 유사 케이스를 찾더라도 그것을 “가능한 조사 방향”으로 취급합니다. 현재 incident에서 확인된 신호, 과거 사례의 조건, 아직 확인되지 않은 차이를 분리해야 합니다.
따라서 결과는 정답 한 줄이 아니라 다음 정보를 함께 제공합니다.
- 현재 문제의 관찰 사실과 출처
- 참고한 지원 케이스·문서와 관련성
- 원인 주장에 필요한 추가 검증
- 운영자가 검토할 수 있는 다음 조사 단계
이 형식은 지원 케이스를 검색 결과에서 증거 후보로 낮추는 장치다. 예전 티켓에서 “이 버전에서는 설정 X가 원인이었다”는 사실은 유용하지만, 현재 cluster의 버전·설정·관찰 신호가 같은지 확인하기 전에는 결론이 될 수 없다. Copilot은 유사도 점수보다 조건의 차이를 먼저 보이게 해야 한다.
답변에는 반증 경로가 함께 있어야 한다
조사 보조 도구가 신뢰를 얻으려면, 가장 그럴듯한 가설뿐 아니라 그것이 틀렸음을 보여 줄 수 있는 증거도 제안해야 한다. “설정 X가 원인일 가능성이 높다”는 주장에는 현재 설정값, 같은 시간대의 로그 신호, 변경 이력 중 무엇이 그 주장을 지지하는지 붙인다. 동시에 설정이 정상일 때 다음으로 확인할 가설도 남긴다.
이 반증 경로가 없으면 운영자는 자연어로 정리된 문장을 결론처럼 받아들이기 쉽다. 반대로 출처와 확인 질문이 함께 있으면, Copilot의 결과는 숙련자가 주니어 조사자에게 넘기는 조사 메모처럼 작동한다. 이 프로젝트에서 품질의 기준은 답변이 매끄러운가가 아니라, 조사자가 10분 뒤 같은 근거를 다시 확인할 수 있는가다.
지식에는 승격 절차가 필요하다
지원 기록에는 민감한 환경 정보나 일회성 해결책이 섞여 있을 수 있습니다. 재사용 가능한 지식으로 바꾸기 전에 식별 정보 제거, 근거 검토, 적용 조건 확인이 필요합니다. 승인된 케이스만 지식으로 승격하고, 그 지식이 어떤 버전·조건에서 유효했는지 남기는 이유입니다.
승격 과정에는 적어도 세 경계가 필요하다. 첫째, 티켓 본문과 첨부에서 고객·환경 식별 정보를 분리한다. 둘째, 실제 근거와 벤더의 추정·운영자의 해석을 구분한다. 셋째, 해결책이 유효했던 제품 버전·구성·적용 조건을 기록한다. 이 단계를 건너뛰면 검색은 빨라져도 재사용 지식의 신뢰도는 급격히 낮아진다.
이 프로젝트에서 중요한 것은 자동 답변의 양이 아닙니다. 조사자가 더 빠르게 질문을 세우고, 답변을 현재 증거로 검증하고, 검증된 학습만 다음 incident에 가져갈 수 있게 만드는 것입니다.
Human-in-the-Loop은 승인 버튼 하나가 아니다
사람이 마지막에 “승인”을 누른다고 해서 모든 과정이 안전해지는 것은 아니다. 사람이 어떤 근거를 보고, 어떤 조건에서 재사용 가능하다고 판단했는지, 승인 뒤에도 원문과 추론을 추적할 수 있는지가 중요하다. Copilot의 검토 화면은 후보 지식, 현재 증거, 미확인 차이, 제안된 다음 질문을 한 곳에 두어야 한다. 승인자는 답변을 예쁘게 고치는 사람이 아니라, 재사용할 수 있는 운영 지식의 경계를 정하는 사람이다.
민감 정보 처리도 이 흐름 안에 있어야 한다. 검색용 인덱스를 만들기 전에 고객·환경 식별자와 토큰·비밀값을 마스킹하고, 원문 접근 권한을 별도로 관리한다. 또한 지식으로 승격된 문서에는 적용 제품 버전, 설정 조건, 마지막 검토일, 근거 출처를 남긴다. 시간이 지나 제품 동작이 바뀌면 과거 지식이 조용히 잘못된 답을 만들 수 있기 때문이다.
보안은 기능의 마지막 체크박스가 아니다
지원 메일에는 고객 환경, 장애 시각, 설정, 계정·연락처 같은 민감한 내용이 섞일 수 있다. 그래서 이 프로젝트에서 보안은 생성 모델 뒤에 붙인 문구가 아니라 데이터 흐름의 조건으로 두었다. Entra ID와 MSAL/OIDC는 사용자 인증과 토큰 경계를 맡고, HTTPS only와 제한된 CORS는 브라우저 경로를 좁힌다. Key Vault와 Managed Identity는 런타임 시크릿 접근을 분리하고, CI/CD의 gitleaks secret scan은 저장소와 배포 이전 단계에서 실수를 발견한다.
Responsible AI의 기준도 같은 방향이다. RCA 섹션에는 메일 원문에서 온 근거를 다시 확인할 수 있어야 하고, AI가 만든 내용은 사람의 검토·수정 없이 자동 전송되지 않는다. 사용자 입력을 프롬프트에 분리해 넣고, 메일 원문을 근거로 하지 않는 주장을 줄이며, 결과 화면에는 검토 필요성을 분명하게 남긴다. 이 경계가 있어야 자동화가 반복 문서 작업을 줄이면서도, 사고 판단의 책임까지 가려 버리지 않는다.
지원 업무의 흐름을 바꾸는 최소 단위
이 프로토타입이 목표로 하는 최소 흐름은 단순하다. 새 incident에서 관찰 사실을 먼저 고정하고, 관련 문서·케이스를 후보로 모은 뒤, 현재 환경에서 확인할 수 있는 질문으로 변환한다. 검증된 결과만 사람이 승인해 지식으로 승격하고, 다음 incident는 그 지식을 참고하되 현재 evidence부터 다시 쌓는다. 이 순환이 있어야 지원 기록은 과거의 대화 로그를 넘어, 운영 팀이 재사용할 수 있는 조사 자산이 된다.
프로토타입에서 먼저 검증할 것
초기에는 모든 지원 채널을 연결하는 것보다, 한 종류의 incident에서 조사 시간이 실제로 줄어드는지를 확인하는 편이 낫다. 예를 들어 특정 제품의 반복적인 연결 실패를 대상으로 삼고, 현재 관찰 → 후보 케이스 → 차이 확인 → 조사 메모 → 승인된 지식이라는 흐름을 끝까지 만든다. 이때 측정할 것은 추천 수가 아니라, 조사자가 출처를 따라갈 수 있는 비율, 잘못된 유사 사례를 얼마나 빨리 제외하는지, 다음 incident에서 같은 질문을 덜 반복하는지다.
Vendor Support RCA Copilot은 지원 업무를 자동으로 닫는 시스템이 아니라, 지원 경험을 검증 가능한 형태로 축적하는 도구를 지향한다. 따라서 결과물도 단일한 “정답”이 아니라 현재 근거, 가설, 반증 질문, 안전한 다음 조치가 함께 있는 RCA 초안이어야 한다. 그 구조가 갖춰질 때 과거 케이스는 검색을 위한 텍스트 묶음이 아니라, 다음 장애 대응을 더 안전하게 만드는 운영 자산이 된다.
검색 품질보다 중요한 운영 품질
유사 케이스를 얼마나 많이 찾는지는 쉽게 측정할 수 있지만, 운영 품질을 그대로 말해 주지는 않는다. 더 중요한 지표는 조사자가 제시된 출처를 실제로 열어 보는 비율, 현재 환경과 다른 조건을 빠르게 제외하는 시간, 승인된 지식을 다음 incident에서 다시 검증할 수 있는지다. 좋은 Copilot은 결과를 많이 보여 주는 도구가 아니라, 잘못된 확신을 줄이고 조사자의 다음 질문을 더 정확하게 만드는 도구여야 한다.
이 기준으로 보면 초기 제품의 성공도 답변 클릭 수가 아니라 조사 흐름의 추적 가능성으로 판단해야 한다. 어떤 후보가 왜 제안됐고, 어떤 증거로 채택·배제됐고, 누가 어떤 조건에서 지식으로 승인했는지 남아 있어야 한다. 이 기록이 쌓여야 지원 조직은 개인의 기억에 의존하지 않고, 검증된 경험을 안전하게 재사용할 수 있다.
지식이 오래될 때의 안전장치
지원 케이스는 제품 버전과 환경이 바뀌면서 빠르게 오래된 지식이 될 수 있다. 그래서 승인된 지식에도 적용 조건, 근거 출처, 마지막 검토 시각, supersede 여부를 남겨야 한다. 새 incident에서 과거 사례를 찾았을 때도 Copilot은 유사도를 답으로 내는 대신, 현재 환경에서 다시 확인할 차이와 검증 항목을 먼저 보여 준다.
이 안전장치가 있어야 경험을 축적하면서도 과거의 해결책을 맹목적으로 반복하지 않는다. Vendor Support RCA Copilot의 목적은 케이스를 더 빨리 닫는 일이 아니라, 근거가 있는 지원 경험을 시간이 지나도 검토 가능한 운영 지식으로 만드는 일이다.
댓글