시작하며
현재 우리 서비스 상태 관리는 고객 관점에서 잘 되고 있나요…? 🤔 이 물음에서 “핑크와드” 라는 프로젝트가 탄생하게 되었습니다.
카카오페이증권에서는 모니터링, 옵저버빌리티, 트레이싱같이 기술 영역에서의 서비스 상태 가시화는 고도화되어 있지만, 상대적으로 “고객 관점에서의 서비스 상태” 가 어떤지는 파악하기 어려운 상황이었습니다.
특히 장애가 발생했을 때를 생각해 보면:
- “지금 고객들이 실제로 어떤 불편을 겪고 있을까?”
- “고객센터에서는 이 상황을 어떻게 설명해야 할까?”
- “언제쯤 정상화될 수 있을까?”
이런 질문들에 대한 답을 빠르게 파악하기 어려웠고, 이는 고객 경험과 직결되는 중요한 문제였습니다
안녕하세요! 카카오페이증권 DevOps 팀의 테라, 데릭입니다. 오늘은 이런 고민에서 출발한 서비스 상태 가시화 프로젝트 “핑크와드” 를 소개해 드리려고 합니다.
프로젝트 탄생 배경
본 프로젝트는 주요 서비스 및 애플리케이션의 상태를 가시화하고, 장애 관리 프로세스를 자동화하는 것을 목표로 시작되었습니다.
이때, 핑크와드 는 게임 롤(리그 오브 레전드) 의 “제어 와드” 란 아이템의 다른 이름인데요, 게임 내에서 팀원들의 시야를 밝혀 각종 함정을 밝혀내는 역할을 수행합니다.
따라서 카카오페이증권의 서비스 구석구석을 밝히고 숨겨진 장애를 빠르게 파악하기 위한 프로젝트의 이름으로 채택하게 되었습니다.
내부적으로는 귀엽고 깜찍하게 “핑와” 라고 줄여 부르고 있습니다.
AS-IS 장애 프로세스
먼저 지금까지의 장애 프로세스를 한 번 설명드리겠습니다.
- 장애가 발생합니다.
- 다양한 경로 (모니터링 시스템, 사내 제보, 고객 문의 등) 를 통해 장애 상황을 감지한 후, 누군가가 *장애 등록 기능을 직접 호출합니다.
- *장애 등록 기능 : 지라 티켓(이하 장애 보고서)을 생성하고, 슬랙 채널 방을 생성하여 전사에 공지합니다.
- 새로 생성된 슬랙 채널방에 담당자들을 초대하고, 해당 장애에 대한 확인 및 현황 공유를 진행합니다.
- 동시에 서비스 담당자는 조치를 진행합니다.
- 해당 장애로 인한 고객 문의가 들어온 경우, 고객센터 크루들도 슬랙 채널에 조인하여 현황을 확인한 후 응대합니다.
- 이후 장애 조치가 완료되면, 장애 보고서에 상세 내용을 작성하고 포스트모템을 진행합니다.
어찌 보면 상당히 평범한 프로세스이지만, 다음과 같은 문제들이 존재하였습니다.
AS-IS 프로세스에서의 문제
- 장애 영향도 파악 및 관련 담당자 확인에 병목 현상이 발생하는 경우가 많았습니다.
- 또한, 게이트웨이성 서비스의 담당자들은 해당 게이트웨이를 사용하는 모든 서비스의 장애 상황마다 호출되었습니다.
- 서비스 담당자는 장애에 대응하느라 실시간 현황을 공유하기 어려웠습니다.
- 고객센터 크루들이 고객 응대에 필요한 정보를 빠르게 파악하기 어려웠습니다.
- 이 경우 콜센터 고객 대기 시간이 증가하였고, 고객 이탈률도 증가하였습니다.
- 장애를 조치한 내역 및 타임라인 등을 장애 보고서에 작성하는 데 많은 리소스가 소모되었습니다.
- 장애 상황에 대한 커뮤니케이션을 위해 슬랙 채널이 별도로 생성되어 있었지만, 급한 상황에서는 장애를 탐지한 채널에서도 커뮤니케이션을 이어가는 경우가 자주 있었기 때문에 전체 내용을 한 번에 확인하기 힘들었습니다.
따라서 자동으로 장애를 탐지하고, 자동으로 담당자를 찾아주며, 자동으로 장애 커뮤니케이션 내용들을 요약하고 장애 보고서를 작성해 주는 시스템을 기획하게 되었습니다.
TO-BE 장애 프로세스
이 프로젝트의 가장 큰 목적은 다음과 같습니다.
- 고객센터 혹은 비 개발 크루를 포함한 카카오페이증권 전체 크루가 현재 서비스의 상황에 대해서 인프라/애플리케이션 단위의 지엽적인 상황이 아니라 실제 고객에게 영향을 주는 고객 서비스 관점에서 영향도와 상황을 쉽게 확인할 수 있게 하는 것.
- 영향도와 장애 처리 상황을 기술관점의 용어가 아닌 모든 크루가 이해할 수 있는 자연어 기반으로 확인할 수 있게 하는 것.
- 장애인지/정리/관리 프로세스에 대한 수작업을 자동화 하는 것.
이 목표들을 구체화한 자동화된 장애 프로세스는 다음과 같이 구현하고자 하였습니다.
- 장애 발생 시 핑와는 웹훅을 받고, 자동으로 장애 등록 프로세스를 수행합니다.
- 웹훅에 들어있는 정보를 통해 핑와는 관련 담당자를 식별하여 초대합니다. 동시에 핑와 대시보드에서 관련 서비스들을 장애 상태로 표현합니다.
- 장애 조치 관련 정보를 입력하기 위한 폼을 제공합니다.
- 관련 담당자 중 아무나 장애 원인 및 영향도와 복구 예상 시각을 쉽게 작성할 수 있습니다.
- 해당 폼을 통해 작성된 정보는 슬랙에서도, 대시보드에서도 쉽게 확인할 수 있습니다.
- 슬랙 채널에서의 대화 내용을 주기적으로 요약하여 대시보드에 제공합니다.
- 장애가 해소된 후, 장애 보고서와 포스트모템용 문서를 자동으로 생성합니다.
- 장애 보고서는 슬랙 채널에서의 대화 내용을 기반으로 AI가 초안을 작성해 줍니다.
아키텍처
TO-BE 장애 프로세스를 구현하기 위한 아키텍처를 설명해 드리기 전에, 카카오페이증권의 내부 플랫폼들을 간략히 소개해 드리겠습니다.
- 춘시리
- 백엔드로 Amazon Bedrock을 사용하고 있는 내부 챗봇입니다.
- 챗봇 용도로 개발되었지만, 간단하게 LLM을 활용하고 싶은 앱들을 위해 내부적으로 LLM API 를 제공하고 있습니다.
- WECAN
- 내부 생산성 플랫폼 입니다.
- 카카오페이증권 애플리케이션/인프라플랫폼들의 메타데이터(담당자, 소스코드 경로, 배포 내역 등)를 관리하고 있습니다.
- 카카오페이증권 애플리케이션 배포를 수행하며, 그 이력을 관리합니다.
- Grafana, OpenSearch
- 그라파나에서는 메트릭을, 오픈서치에서는 로그를 확인하고 있습니다.
- 각 플랫폼에서는 알림 설정을 할 수 있습니다.
핑크와드는 이런 내부 플랫폼들을 최대한 활용하는 방안으로 개발되었습니다. 최종 아키텍처는 다음과 같습니다.
🔒 핑와를 구성하는 모든 애플리케이션은 연구개발망에 위치합니다.
- 핑와 FE
- 장애가 난 경우, 관련 서비스들을 장애로 표시합니다.
- 서비스 상세 화면에서 장애 관련 정보(요약 포함)들을 표시합니다.
- 장애 상세 화면에서 장애와 연관된 애플리케이션 정보들을 맵으로 표시합니다.
- 핑와 BE
- 그라파나, 오픈서치에서 장애 감지 시 웹훅을 받습니다.
- 웹훅을 받은 경우, 파라미터 등으로부터 관련 애플리케이션을 확인합니다.
- 애플리케이션의 메타데이터를 위캔으로부터 받아옵니다.
- 신규 장애라고 판단이 된 경우, 장애보고서와 슬랙 채널 방을 생성하고 장애공유방에 공유합니다.
- 이때 해당 애플리케이션과 관련된 서비스를 장애라는 정보를 DB에 적재합니다.
- 슬랙 채널방에서는 장애 관련하여 다양한 상호작용 커맨드를 제공합니다.
- 장애가 해소된 경우, 장애 보고서 & 포스트모템 문서 초안을 작성하여 공유합니다. (w. 춘시리)
- 핑와 배치
- 슬랙 채널방의 내용을 주기적으로 요약하여 저장합니다. (w. 춘시리)
- 장애 관련 정보를 입력하도록 주기적으로 안내합니다.
- 장애 복구 예상 시각이 지나도 해소되지 않는 경우, 확인 알림을 발송합니다.
핑크와드 개념/대시보드/기능 소개
기능들을 더 자세히 살펴보기 전에, 내부적으로 정의한 개념들에 대해 설명하고 넘어가겠습니다.
핑크와드 내부 개념
- 서비스
- 대고객 서비스의 큰 분류를 의미합니다.
- 예시로는 계좌/홈/주문 등이 있습니다.
- 고객이 실제로 인식하고 구분하는 서비스 분류를 기준으로 삼았습니다.
- 리소스
- 장애를 감지할 수 있는 단위 입니다.
- 리소스 기준으로 장애를 감지하고 알림을 걸 수 있습니다.
- 애플리케이션/인프라플랫폼으로 나뉩니다.
- 2-1. 애플리케이션: 위캔에서 관리되는 서비스 애플리케이션 단위입니다.
- 2-2. 인프라플랫폼: 애플리케이션들이 사용하는 인프라 플랫폼들을 뜻합니다. (ex: 데이터베이스, 레디스, 카프카, 쿠버네티스 클러스터)
- 장애
- 내부적으로 관리되는 장애 티켓 단위입니다.
이들를 관계도로 표현하면 다음과 같습니다.
대시보드 - 서비스 상태 가시화
🔒 본 글에 첨부된 모든 이미지는 개발 환경에서 수행된 가짜 장애 시나리오임을 밝힙니다.
대시보드는 타 서비스들의 status 페이지를 참고하여 개발되었습니다.
📌 [참고] 타 서비스들의 status 페이지들은 실제 고객들을 대상으로 한 페이지, 즉 대고객 서비스입니다. 그러나 저희는 내부 고객센터/비개발 크루들을 위한 페이지가 목표였기 때문에 실제 장애와 관련 애플리케이션들에 대한 자세한 정보까지 포함하게 되었습니다.
대시보드의 최우선 목표는 “개발직군이 아닌 모든 크루가 장애 채널에서 이야기되는 모든 내용을 다 확인하지 않더라도 현재/과거의 장애 상세 내용을 쉽게 확인할 수 있게 하기” 입니다. 이를 위해 구현한 항목들은 다음과 같습니다.
- 메인 대시보드 화면에서 “현재 장애가 진행 중인 서비스” 를 붉게 표시합니다.
- 현재 진행 중인 장애가 있는 경우, 메인 대시보드 우측 내비게이션에서 장애별 AI 요약 현황을 표시합니다.
- 서비스 상세 페이지에서는 최근 장애(*현재 진행중이거나 24시간 내로 해결된 장애)들에 대한 자세한 정보를 확인할 수 있습니다.
장애 상세 페이지에서는 해당 장애와 연관된 서비스/리소스 맵을 확인할 수 있습니다.
이 맵을 통해
- 어떤 리소스로부터 장애가 발생하였고
- 어떤 리소스와 서비스들이 영향을 받는지
- 각 리소스와 서비스의 담당자는 누구인지
를 누구나 쉽게 확인할 수 있게 되었습니다.
추가로, 실제 고객센터에서는 “지나간 장애에 영향을 받은 고객의 문의”를 받는 경우도 많으므로 장애 캘린더와 검색 기능도 구현하였습니다.
슬랙봇 - 장애 프로세스 자동화
먼저 자동으로 장애를 감지하기 위해, 그라파나와 오픈서치에서 트리거할 수 있는 웹훅 엔드포인트를 개발해 두었습니다. 그리고 모든 애플리케이션에 대해 공통으로 “Nginx에서의 5XX 에러율이 5% 이상인 경우” 알림을 걸어두었습니다.
📌 [참고] 위 기준은 DevOps팀에서 일괄적으로 적용하기 위한 러프한 공통 알림 기준입니다. 실제로는 각 개발팀에서 애플리케이션 특성에 맞게 알림 쿼리와 임계치를 추가/수정하여 사용하고 있습니다.
임계치에 도달하게 되어 알림이 발생하는 경우 자동으로
- 장애보고서 생성
- 슬랙 채널 생성 (이하 장애 채널)
- 장애 공유 채널에 공유
- 장애 채널에 담당자 초대
프로세스가 진행됩니다.
이때, 해당 애플리케이션과 연관된 서비스도 장애와 연관시켜 대시보드에서 곧바로 장애임을 확인할 수 있게 됩니다.
📌 [참고] 그라파나로부터 장애를 감지한 경우, Grafana Image Renderer 플러그인을 활용해 대시보드 패널 이미지들을 같이 발송해 줍니다.
📌 [참고] 만약 현재 진행 중인 장애가 있는 경우엔 자동으로 신규 장애가 등록되진 않으며 담당자들을 호출해 “현재 진행 중인 장애와 연관된 감지인지 또는 신규 장애인지” 를 한 번 물어보게 됩니다.
📌 [참고] 별도 커맨드를 통해 수동으로 장애를 등록하는 것도 가능합니다.
장애 채널이 생성되면, 해당 채널에는 장애 원인/발생 시각/복구 예상 시각/영향도 를 수정할 수 있는 메시지가 발송됩니다.
위 메시지에서 크루들이 손쉽게 정보를 수정할 수 있으며, “장애가 해소된 경우 클릭” 버튼을 클릭해 장애가 해소되었음을 알릴 수 있습니다.
만약 위 메시지에 정보가 업데이트되지 않는 경우, 5분마다 한 번씩 입력해달라는 메시지를 발송합니다.
또한 아래 정보를 빠르게 확인할 수 있는 메시지를 발송해 주고, 롤백 버튼을 제공합니다.
- 최근 배포된 애플리케이션 이력
- 최근 변경된 인프라플랫폼 작업 히스토리
장애 채널 내에서는 장애 관련 서비스/리소스 를 직접적으로 추가할 수 있습니다. 서비스/리소스가 추가되는 경우, 관련 담당자들은 자동으로 해당 장애 채널에 초대됩니다.
장애 채널 내에서의 모든 메시지는 LLM(춘시리)을 통해 중요한 메시지인지 아닌지를 검증받고, 중요한 메시지로 판단된 경우 DB에 적재됩니다. DB에 적재된 중요한 메시지들 기준으로 5분마다 배치가 돌며 AI 요약이 진행됩니다.
장애가 해소된 경우, 장애 보고서와 포스트모템용 문서의 초안을 작성해 줍니다.
장애 보고서 초안을 확인해 보면 다음과 같습니다.
위캔 - 애플리케이션 관리
실제 서비스와 리소스 정보는 위캔 대시보드에서 관리할 수 있습니다.
각 서비스 담당자는 신규 서비스를 추가하거나 기존 서비스의 담당자를 변경할 수 있습니다.
실제 효과
정량적 성과
핑크와드 프로젝트 배포 후, 장애 대응에서 다음과 같은 개선 효과를 확인했습니다.
- 장애 프로세스 67% 단축 (서비스 담당자 기준)
- 장애 보고서 작성 시간 80% 감소 (서비스 담당자 기준)
- 고객 응대 정보 파악 시간 90% 감소 (고객센터 기준)
하지만 더 중요한 건 실제 현장에서 느끼는 변화였습니다.
실제 사용자 후기
고객센터:
핑크와드 덕분에 장애 파악이나 대응에서 고객센터가 크게 도움받았어요. DevOps팀에서 많이 도와주셔서 다행입니다.
프로덕트팀 개발자:
장애 탐지부터 등록, 회고(포스트모템)까지 한 번에 관리하기 쉬워져서 너무 좋습니다.
이전 장애 등록 도구는 복잡한 구조였는데, 이제는 자동 등록은 물론 담당자 호출까지 가능해졌어요.
매번 작성해야 하는 회고 문서와 티켓 타임라인도 자동으로 정리되어서, 장애 해결 후 해야 할 일이 많이 줄었습니다. ㅎㅎ
프로덕트팀 PM:
핑크와드 최고예요! 체계적인 프로세스가 정말 멋있습니다!
장애 상황에서 장애 내용 외에 챙겨야 할 프로세스를 간결하게 보여줘서 안정감이 있었어요. 포스트모템까지 자연스럽게 이어져서 복기하고, 동일한 실수를 방지할 수 있게 되었습니다.
장애 상황 확인을 위한 슬랙 채널도 자동으로 만들어져서 커뮤니케이션이 일원화되어 좋았습니다.
- 장애 대응 타임라인을 실시간으로 확인할 수 있어서 좋았어요.
- 고객센터, 컴플라이언스 등 유관 부서가 함께 참여해서 사용자 영향 범위를 즉시 공유할 수 있었어요.
가장 큰 변화
수치상의 개선도 의미 있지만, 진짜 변화는 “장애 상황에서의 심리적 안정감” 이었습니다.
예전에는 장애가 발생하면 “뭘 해야 하지? 누구에게 알려야 하지? 어떻게 보고해야 하지?”라는 불안감이 먼저 들었습니다. 하지만 이제는 핑크와드가 필요한 프로세스를 자동으로 진행해 주니까, 온전히 장애 해결에만 집중할 수 있게 되었어요.
특히 고객센터나 컴플라이언스 같은 비개발 부서에서도 “지금 무슨 일이 일어나고 있는지, 언제쯤 해결될지” 를 쉽게 파악할 수 있게 되면서 전사 차원의 소통이 훨씬 원활해졌습니다.
더 발전할 핑크와드
앞으로 추가 개발 예정인 기능들입니다.
1. VOC 자동 취합 시스템
기존에는 장애 해소 후 고객센터에서 관련 VOC를 수동으로 취합해 리포팅했습니다. 내부 VOC 플랫폼과 통합하여 고객센터에서 VOC와 장애를 연결하기만 하면 자동으로 리포팅되도록 개발 중입니다.
2. 반자동 장애 조치 봇
LLM과 MCP를 활용해 장애 조치를 직접 수행할 수 있는 봇으로 발전시키려 합니다. 내부 서비스를 직접 제어하는 것은 위험하므로, 슬랙에서 사람의 승인을 받고 진행하는 형태로 설계하고 있습니다.
마치며
핑크와드 프로젝트는 DevOps 엔지니어 5명이 약 2개월간 몰입해서 작업했습니다. 별도 PM 없이 개발자 5명이 진행하다 보니 우여곡절이 많았어요.
처음에는 “이런 걸 원하시겠지? 저런 걸 원하시겠지?” 하며 상상으로 기획하다가 갈아엎은 계획들이 참 많습니다. 하지만, 이 과정에서 가장 중요한 깨달음을 얻었습니다.
“DevOps 엔지니어의 시선을 버리고, 진짜 고객 관점에서 바라보기”
실제 사용자들의 질문은 이런 것들이었어요:
- 고객센터: “지금 고객들에게 뭐라고 안내해야 할까요?”
- 프로덕트팀: “이 장애가 우리 서비스에 어떤 영향을 주나요? 담당자는 누구인가요?”
- 경영진: “언제까지 복구될 수 있나요?”
구현하기 위한 기술이 아닌 실제 서비스 임팩트와 고객 경험에 집중하면서, 완전히 다른 관점의 솔루션을 만들 수 있었습니다.
가장 어려웠던 점들
1. 용어 정의의 혼란
같은 단어라도 사람마다 생각하는 개념이 달랐습니다. “서비스 장애”라고 했을 때 누군가는 비즈니스 서비스를, 누군가는 애플리케이션을 떠올렸어요.
2. 고객 중심 사고의 부족
내부 크루들이 고객이므로 충분한 인터뷰를 통해 기획해야 했는데, 처음에는 개발자 관점에서만 생각했던 것이 가장 큰 실수였습니다.
그럼에도 불구하고, 모두가 끝까지 포기하지 않고 동일한 목표로 달려와서 좋은 결과를 만들 수 있었습니다.
같이 작업했던 스티브, 리나, 벨 그리고 프로젝트에 어려움이 생길 때마다 도와주신 DevOps 팀원들에게 다시 한번 감사의 인사를 남깁니다.