개발 리더 의사결정 문서

기술 이슈 대응 AI 파이프라인 개선안

마지막 업데이트 2026-08-04

진행자 수업 보고와 CS 고객 신고를 하나의 증거 흐름으로 연결하고, AI가 초동 분류·증거 정렬·조치 초안을 맡도록 전환한다. 목표는 LogRocket 조회를 빠르게 하는 것이 아니라, LogRocket이 없어도 조사 가능한 자체 증거 체계를 만드는 것이다.

작성일: 2026-08-04 · 범위: 운영/CS 인입, 기술 이슈 트리아지, 근본 원인 분석, 고객·백로그 조치 의사결정

결론: LogRocket 자동화가 아니라 자체 증거 파이프라인

권고: LogRocket MCP와 세션 리플레이를 원본 진단 저장소가 아닌 보조 증거로 둔다. 자체 구조화 이벤트를 수업 단위로 장기 보존하고, Slack 인입부터 사람 승인까지 하나의 이슈 레코드로 추적한다.

AI가 수행자동
기술 이슈 후보 판정, 수업·세션 매칭, 양측·서버 증거 정렬, 원인 후보·누락 정보·조치 초안 작성

사람이 승인승인
원인 확정, 고객 기기 테스트·교체 안내, 백로그 생성과 우선순위, 긴급 공지와 종결

LogRocket·영상 역할
브라우저 증상과 사용 맥락을 재확인하는 링크·확인 지점. 미수집·조회 불가 시에도 이슈 분석이 멈추지 않아야 한다.

현행 프로세스의 비효율

수업 종료진행자 Slack 수기 보고
안정성·반응·이슈

→

Harry 판단기술 이슈면 Chulsu 멘션
CS 채널도 별도 인입

→

수동 조사·조치LogRocket/영상/서버 로그 비교
고객 안내 또는 백로그

구간	현재 병목	운영·개발 영향
인입	자유 서술이라 증상 시각, 영향, 즉시 조치, 영상 링크가 누락되거나 표현이 제각각이다.	기술 이슈 여부를 사람이 재해석해야 하고, 같은 수업의 진행자·고객 신고가 분리된다.
판정	Harry의 수기 판정과 멘션이 단일 병목이다. 비기술 관찰, 긴급 장애, 증거 부족의 기준도 일관되지 않다.	긴급성 판단이 늦고, 개발 조사 요청의 품질이 인입자 숙련도에 좌우된다.
조사	날짜·아동 정보로 세션을 찾은 뒤 `roomId`로 진행자 세션을 다시 매칭해야 한다.	쌍 매칭 비용과 오매칭 위험이 크며, 아동·진행자·서버를 한 시간축에서 비교하기 어렵다.
증거	LogRocket MCP는 전체 raw log·리플레이·장기 보존을 보장하지 않는다.	세션 누락·1개월 보존 만료 시 분석이 보류되고, 반복 이슈·배포 회귀 추세를 축적하지 못한다.
조치·학습	고객 안내와 백로그 판단이 원문 신고·근거·결과와 표준 구조로 연결되지 않는다.	동일 이슈의 재발·조치 효과·고객 재신고율을 측정하기 어렵다.

권장 목표 구조

수업 메타데이터와 각 계층의 구조화 이벤트가 조사 기준이 되고, 외부 서비스와 영상은 그 증거를 보강한다.

진행자 보고Slack 원문·영상 링크
즉시 조치

CS 신고고객 증상·재현 정보
영향 범위

증거 묶음lessonId/roomId
클라이언트·서버 시간축

AI 트리아지분류·원인 후보·확신도
근거와 누락 항목

사람 승인고객 안내·추가 조사
백로그·종결·학습

이슈 레코드의 최소 계약

영역	필수 정보	의도
상관관계	`technicalIssueId`, `lessonId`, `roomId`, 참여자 역할, 발생 시각, 인입 원문 링크	진행자·CS 신고와 아동·진행자·서버 기록을 한 사건으로 묶는다.
진단 이벤트	`sessionId`, `eventName`, UTC `occurredAt`, `releaseVersion`, `traceId`	배포·기기·서버·AI 이벤트를 시간축으로 비교하고 회귀를 찾는다.
증거 상태	증거 링크, 출처, 누락 여부, 보존 만료 시각, 확신도	AI가 모르는 것을 확정처럼 말하지 못하게 하고 재조사 가능성을 남긴다.
결정 이력	권장 조치, 승인자, 고객 안내/백로그 링크, 종결 사유	조치의 책임과 결과를 인입 원문까지 되돌릴 수 있게 한다.

개인정보 경계: AI 분석 입력에는 아동 실명과 불필요한 대화 원문을 넣지 않고 내부 식별자·마스킹된 요약을 사용한다. 원본 영상·리플레이는 역할 기반 열람과 감사 기록이 전제다.

자동화 경계와 승인 책임

단계	AI/시스템 자동화	사람의 책임
수집	자동 Slack 원문 보존, 필드 추출, 동일 수업 후보 연결	잘못된 수업·세션 매칭 정정
트리아지	자동 기술 이슈 가능성, 도메인, 영향도, 긴급 후보, 중복 이슈 제시	긴급도·실제 기술 이슈 여부 확정
근본 원인 분석	자동 양측·서버 이벤트 정렬, 최근 배포/기기/네트워크/서버 원인 후보와 증거 인용	영상·리플레이 확인, 반증 검토, 근본 원인 확정
후속 조치	자동 고객 안내·추가 테스트·백로그 초안 및 근거 작성	필수 승인 고객 발송, 백로그 생성, 우선순위·종결 결정
학습	자동 지문 군집화, 릴리스별 발생 증가, 증거 결손률 집계	분류 규칙·런북·알림 정책 변경 승인

AI 출력에는 항상 증거 링크 또는 “증거 없음”, 확신도, 대안 가설, 추가로 필요한 데이터를 포함한다. 원인 단정이나 자동 외부 실행은 허용하지 않는다.

단계별 도입 로드맵

Phase 0 — 운영 스키마와 책임 체계
진행자 보고·CS 신고의 최소 필드, 이슈 상태, 책임자별 SLA를 정의한다. 이슈가 있는 보고에는 증상 시각·영향·즉시 조치·영상 링크를 유도한다.
완료 기준: 모든 인입이 추적 ID, 원문 링크, 수업 후보, 상태를 가진다.

Phase 1 — 상관관계와 최소 자체 진단 로그
클라이언트·API·Socket/SFU·AI/STT/TTS 이벤트에 공통 키와 릴리스 버전을 넣고 수업 종료 후 장기 보관한다.
완료 기준: lessonId/roomId만으로 아동·진행자·서버의 단일 타임라인을 조회한다.

Phase 2 — AI 트리아지 초안
Slack 인입을 트리거로 분류, 증거 수집, 원인 후보, 누락 항목, 조치 초안을 같은 스레드에 생성한다.
완료 기준: 운영자는 수동 세션 검색 없이 신고·증거·승인 상태를 한 곳에서 확인한다.

Phase 3 — 군집화와 릴리스 감시
증상 지문, 버전, 기기, 브라우저, 도메인별 발생 추이를 집계하고 배포 뒤 증가한 후보를 관찰 경보로 표시한다.
완료 기준: 주간 단위 반복 이슈, 고객 영향, 배포 상관 후보, 증거 결손률을 확인한다.

Phase 4 — 선택적 자체 세션 리플레이
구조화 로그로 해결되지 않는 UI·조작 문제에 한해 도입한다. LogRocket 기능 전체 복제가 목적이 아니며 마스킹·보존·열람 통제가 선행된다.
완료 기준: 리플레이 부재가 분석 중단 사유가 되지 않는다.

효과와 측정 지표

기대 효과	측정 지표	목표 설정 방식
초동 대응 속도	인입→분류 초안, 인입→승인된 1차 분석의 중앙값	현행 4주 기준선을 측정한 뒤 각각 80%, 50% 단축을 목표로 한다.
증거 완결성	아동·진행자·서버 타임라인을 모두 확보한 이슈 비율	Phase 1 이후 90% 이상
매칭 정확도	사람이 수정한 수업/세션 매칭 비율	5% 미만
반복 이슈 감지	두 번째 신고 이내에 같은 지문으로 군집화된 비율	80% 이상
고객 조치 품질	안내 후 재신고율, 해결 확인율	유형별 현행 기준선 대비 개선
외부 의존 축소	LogRocket 부재로 조사가 보류된 이슈 비율	월별 감소 추세

초기 성공 기준은 AI가 얼마나 “똑똑하게” 보이는지가 아니다. 증거 누락률, 사람 수정률, 조사 리드타임을 먼저 측정해 데이터 계약과 운영 규칙을 보정한다.

위험과 통제

위험 AI 원인 단정모든 주장에 증거·확신도·대안 가설·누락 데이터를 붙이고, 사람 승인 전 고객·백로그 시스템을 실행하지 않는다.

위험 민감 데이터 확대원본 음성·영상 기본 보관을 피하고, 마스킹·최소 보존·RBAC·열람 감사 로그를 적용한다.

위험 비용과 로그 노이즈도메인별 필수 이벤트부터 시작한다. 정상 세션은 샘플링하고, 이슈 수업은 예외적으로 증거 묶음을 보존한다.

위험 상관관계 키 누락이벤트 계약 테스트와 배포 검증으로 차단한다. 누락은 추정으로 메우지 않고 insufficient_evidence로 표기한다.

위험 Slack 알림 피로중복 억제와 심각도별 알림 정책을 적용하고, 분석 초안은 별도 채널 폭주 대신 기존 신고 스레드에 귀속한다.