| 항목 | 기록 |
|---|---|
| 문제 | OLAP 도입 뒤에도 마케팅·경영본부·임원진의 통계 요청이 이어졌다. 요청을 해석하고, 적절한 시스템에서 실행한 뒤, 결과를 전달하는 과정이 담당자의 컨텍스트 스위칭과 대기 시간에 의존했다. |
| 기존 방식과 비용 | 인프라·백엔드·신규 개발·운영을 함께 담당하는 동안 통계 요청 대응에 주 1일 수준이 들었다는 회고가 있다. 이는 기록 기반 집계 전까지 검증 대기 값이다. |
| 제안/판단 | 여러 운영 시스템의 설정을 각 사용자에게 맡기면 교육·지원 비용이 반복된다고 판단했다. 한 번의 쉬운 설정으로 필요한 읽기 전용 도구에 접근하게 하는 내부 MCP 플랫폼을 만들었다. |
| 기술 선택 | Grafana·OLAP·NAS·Ncloud를 4개 MCP 서비스와 26개 도구로 연결했다. 도구 단위 권한과 감사 로그를 두어 접근을 통제하고, 운영 데이터의 탐색 경로를 표준화했다. |
| 구현 범위 | 서비스와 도구 설계, 접근 흐름, 감사 가능한 호출 구조, 운영·온보딩 문서화를 포함한다. Slack 알림 후 기존의 Grafana 접속 → Explore 이동 → 로그 조건 설정 → 소스 대조 단계를 MCP 대화 안에서 연속 수행해 초기 분석 진입 절차와 컨텍스트 스위칭을 줄이는 흐름을 구성했다. |
| 내 기여 | 플랫폼 구조와 도구 경계를 설계·구현하고, 여러 운영 시스템을 단일 설정 흐름으로 연결했다. 개발팀의 호평과 사용 피드백을 반영해 운영 진입 단계를 다듬었다. |
| 정량 결과 | MCP 4서비스 · 26도구, 보존 기간 관측 사용자 5명, 호출 성공 245/246 (99.59%). |
| 연결 데이터 | MCP 운영 범위 (DATA-SCALE-MCP) · 관측 사용자 (DATA-SCALE-MCP-USERS) · MCP 호출 신뢰성 (DATA-QUALITY-MCP) · 통계 요청 대응 후보 (DATA-PENDING-MCP-REQUEST) · 장애 초기 확인 후보 (DATA-PENDING-MCP-TRIAGE) |
| 측정 한계 | 호출·사용자 수는 보존 감사 로그 기준이다. 5명은 전체 누적 사용자가 아니고, 245/246은 응답 성공 여부라 업무 결과 정확성이나 사용자 만족도를 뜻하지 않는다. |
| 남은 검증 | 통계 요청 대응 투입은 요청 접수·해석·실행·전달 기록으로 재측정한다. 장애 초기 분석 절차는 정확한 전후 시각을 확보하지 못해 정량화하지 않는다. 전체 장애 해결시간이나 MTTR로 표현하지 않는다. |
| 공개 주의사항 | 내부 Grafana URL, 사용자명, 로그 원문, 요청 본문, SQL, 테이블·컬럼명은 공개하지 않는다. |
근거
지표는 포트폴리오 정본 data/metrics.yml(2026-08-31 기준)의 DATA-* 항목이다. 원본 응답·행 데이터는 저장하지 않는다.
- DATA-SCALE-MCP · MCP 운영 플랫폼: 4서비스 · 26도구
- DATA-SCALE-MCP-USERS · MCP 보존 기간 관측 사용자: 5명
- DATA-QUALITY-MCP · MCP 호출 성공: 245/246 (99.59%)
검증 대기
기존 기록에서 찾았지만 같은 조건의 실행 기록을 다시 확인하지 못한 값이다. 확정 지표와 섞지 않는다.
- DATA-PENDING-MCP-REQUEST · 통계 요청 대응 투입: 주 1일 수준 — 검증 대기. 필요한 것: 요청 접수·해석·실행·전달 기록을 기간·담당자 기준으로 집계
- DATA-PENDING-MCP-TRIAGE · 장애 초기 분석 절차: 기존 다단계 도구 이동 → MCP 대화 안에서 연속 수행 — 검증 대기. 필요한 것: Slack 알림·MCP 호출·원인 확인 시각을 확보할 수 있을 때 초기 분석 진입 단계만 측정
공개 범위
이 글은 포트폴리오 정본의 공개 요약이다. 원본 업무 데이터와 회사·약국·서버·공급사 식별정보는 뺐다. 내부 Grafana URL, 사용자명, 로그 원문, 요청 본문, SQL, 테이블·컬럼명은 공개하지 않는다.