슬랙 채널이 빨간 불로 가득 찬 밤은 개발팀에 익숙한 장면이다. 한 B2B SaaS 팀은 프로덕션 에러를 슬랙 웹훅과 서버 로그 검색으로만 처리하고 있었다. 알림은 하루 평균 150~200건이었다. 그중 실제로 사람이 바로 고쳐야 할 이슈는 손에 꼽혔다. 나머지는 중복, 봇 트래픽, 이미 알려진 클라이언트 예외였다.
이 글은 그 팀이 센트리(Sentry)를 도입해 알림 피로를 줄이고, 릴리즈 단위로 에러를 추적하며, 배포 게이트까지 연결하기까지 약 4주간 겪은 과정을 문제·시도·결과 순으로 정리한 사례 기록이다. 도구 홍보가 아니라, 도입 초반에 터진 실패와 정책 재설계에 초점을 둔다.
문제: 슬랙 알림은 많은데 원인은 안 보이는 상태
팀은 Next.js 프론트엔드와 Node.js API, 백그라운드 워커로 구성된 구독형 제품을 운영했다. 인원은 풀타임 개발 네 명, 온콜은 주 단위 로테이션이었다. 장애 대응 도구는 사실상 세 가지뿐이었다. 클라우드 로그 검색, 슬랙 웹훅, 배포 후 수동 스모크 테스트.
표면적으로는 동작했다. 서버가 500을 내면 슬랙에 메시지가 왔다. 문제는 신호 대 잡음 비율이었다. 같은 널 포인터 예외가 사용자 수만큼 반복 전송됐고, 프론트엔드 스크립트 로드 실패는 브라우저·광고 차단 조합마다 다른 스택으로 쏟아졌다. 온콜 담당자는 알림을 끄고 싶어졌고, 끄면 진짜 장애를 놓칠까 봐 다시 켰다.
결정적 계기는 결제 웹훅 타임아웃이었다. 핵심 경로는 30분 가까이 간헐 실패했는데, 슬랙에는 이미 알려진 프론트 에러 수십 건이 위에 쌓여 있었다. 로그에서 상관관계 아이디를 찾아 재현하는 데 두 시간이 걸렸다. 팀 리드가 회고에서 남긴 문장은 단순했다. “우리는 알림을 받는 조직이지, 관측하는 조직이 아니다.”
시도 1: 로그 검색과 스프레드시트로 버틴 2주
첫 대응은 도구 구매가 아니라 프로세스였다. 온콜 담당자가 아침·저녁으로 슬랙 알림을 스프레드시트에 옮겨 중복을 표시하고, 우선순위를 매기는 루틴을 만들었다. 심각도는 P1~P3, 재현 여부와 영향 사용자 수를 수동 기입했다.
효과는 이틀 정도였다. 사람이 필터 역할을 하니 채널 소음은 줄었지만, 비용이 온콜 개인의 집중력으로 전가됐다. 주말 로테이션에서는 스프레드시트가 비었고, 월요일 아침에 미분류 알림이 쌓였다. 로그 검색 쿼리도 사람마다 달랐다. 어떤 개발자는 상태 코드로 찾고, 어떤 개발자는 예외 메시지로 찾아 같은 이슈를 두 번 추적했다.
팀은 이 단계에서 한 가지를 배웠다. 관측 부재의 본질은 “도구가 없다”가 아니라 “이슈를 그룹핑하고 소유자를 붙일 공통 단위가 없다”는 점이었다. 스프레드시트의 한 행이 되어야 할 대상이, 로그 한 줄과 슬랙 메시지 사이에 떠 있었다.
알림 폭주 상태에서 팀이 먼저 정리한 것 — 이슈 단위로 묶이지 않은 원시 에러 스트림
시도 2: 자체 구축 대신 센트리를 고른 이유
후보는 세 갈래였다. 첫째, 오픈소스 스택으로 자체 수집기를 만든다. 둘째, 클라우드 모니터링 제품의 APM·로그 묶음을 확장한다. 셋째, 에러 추적에 특화된 센트리 클라우드를 쓴다.
자체 구축은 매력적이었지만 기각됐다. 수집 SDK, 샘플링, 소스맵 업로드, 이슈 머지 규칙까지 만들면 본업인 제품 기능보다 관측 플랫폼 유지보수가 커질 가능성이 높았다. 기존 모니터링 제품은 이미 인프라 지표용으로 쓰고 있었지만, 프론트·백엔드 예외를 이슈 단위로 묶고 릴리즈에 태깅하는 워크플로는 센트리 쪽이 팀에 더 직관적이었다.
선정 기준은 네 가지였다. (1) 브라우저와 Node 모두 공식 SDK가 있을 것, (2) 릴리즈·환경(environment) 구분이 가능할 것, (3) 슬랙·이슈 알림 규칙을 세밀히 조절할 수 있을 것, (4) 소스맵으로 난독화 전 스택을 볼 수 있을 것. 센트리는 이 네 항목을 문서와 무료/유료 플랜 범위 안에서 충족한다고 판단했다. 셀프호스팅 옵션도 있었지만, 초기에는 운영 부담을 줄이려고 클라우드로 시작했다.
1주차: SDK를 켠 직후 이슈가 폭주한 이유
1주차 목표는 단순했다. 프론트와 API에 SDK를 붙이고, 스테이징에서 테스트 예외를 한 건 보낸 뒤 프로덕션에 배포한다. 설치 자체는 반나절이면 끝났다. 문제는 그다음 아침이었다.
프로덕션 트래픽이 들어오자 센트리 이슈 목록이 수백 개로 불어났다. 원인은 세 겹이었다. 첫째, 개발·프리뷰 배포 URL에서도 DSN이 동작해 로컬 하이드레이션 경고까지 수집됐다. 둘째, 샘플링을 100%로 둔 채 봇·크롤러 404 래핑 예외를 그대로 받았다. 셋째, 이슈 그룹핑 기본값만으로는 메시지 문자열 미세 차이 때문에 사실상 같은 버그가 여러 이슈로 쪼개졌다.
팀은 급히 환경 변수를 나눴다. 프로덕션 DSN만 활성화하고, 프리뷰·로컬은 전송을 막았다. 브라우저 SDK에는 허용 도메인과 무시할 에러 패턴을 넣었다. 네트워크 단절성 TypeError, 확장 프로그램 스택, 광고 스크립트 출처는 필터 목록으로 빼냈다. 1주차의 교훈은 명확했다. “SDK 설치 = 관측 완성”이 아니라 “수집 정책 설계의 시작”이었다.
센트리 도입 초반 — 샘플링·무시 규칙·환경 분리 없이 켠 뒤 발생한 이슈 폭주 구간
2주차: 샘플링·핑거프린트·소유 팀 태그를 다시 짠 과정
2주차에는 수집량을 줄이는 것이 아니라, 줄이면서도 중요한 신호를 남기는 쪽을 목표로 잡았다. 트랜잭션 트레이스는 낮은 샘플 레이트로 두고, 에러 예외는 우선 높게 유지한 뒤 노이즈 클래스를 규칙으로 제거하는 순서를 택했다. 반대로 모든 것을 낮추면 희귀하지만 치명적인 결제 오류가 안 보일 수 있다는 우려 때문이었다.
백엔드에는 서비스 태그(api, worker, webhook)와 고객 세그먼트(무료/유료)를 커스텀 태그로 붙였다. 프론트에는 라우트 이름과 릴리즈 버전을 넣었다. 같은 “undefined property”라도 결제 페이지와 설정 페이지를 구분할 수 있게 되자, 우선순위 논의가 가능해졌다.
핑거프린트 규칙도 손봤다. 동적 아이디가 메시지에 섞여 이슈가 쪼개지는 패턴을 찾아, 스택의 상위 프레임 기준으로 묶이도록 조정했다. 완벽하지는 않았다. 다만 스프레드시트 시절보다 “이건 어제 그 이슈”라는 합의가 팀 채널에서 먼저 나오기 시작했다. 온콜 핸드오프 문서에 센트리 이슈 링크를 붙이는 관행도 이 주에 정착했다.
3주차: 릴리즈 트래킹과 소스맵이 바꾼 디버깅 속도
3주차 핵심은 배포 파이프라인 연결이었다. CI에서 빌드 아티팩트를 만들 때 릴리즈 이름을 깃 커밋 SHA 단축 해시로 정하고, 소스맵을 센트리에 업로드한 뒤 앱 배포를 진행하도록 순서를 고정했다. 소스맵 업로드가 실패하면 배포를 막지 않고 경고만 내던 초기 설정은 하루 만에 폐기됐다. 난독화된 스택만 보이는 이슈가 다시 늘었기 때문이다.
효과가 가장 컸던 화면은 릴리즈 상세였다. “어제 배포 이후 신규 이슈”와 “회귀로 다시 늘어난 이슈”를 같은 페이지에서 볼 수 있게 되자, 블레임 논의가 사람 이름이 아니라 커밋 범위로 옮겨갔다. 한 번은 마케팅 랜딩 실험 배포 직후 특정 브라우저에서만 클라 예외가 급증했다. 릴리즈 필터로 실험 브랜치 배포를 집어내 30분 안에 피처 플래그로 내렸다.
워커와 웹훅 경로에도 동일한 릴리즈 문자열을 심었다. 예전에는 API는 정상이고 워커만 깨진 상황을 로그 시간대를 맞춰 추측해야 했다. 이제는 같은 릴리즈 아래 이슈 분포로 “웹은 조용하고 워커만 붉은색”을 바로 확인했다. 디버깅 시간이 평균적으로 크게 줄었다는 것이 팀 내부 회고의 공통 평가였다. 정확한 분 단위 통계를 외부에 공개할 수준은 아니었지만, 온콜 티켓의 첫 응답까지 걸리는 체감 시간은 반나절에서 한두 시간 안으로 모이는 경우가 많아졌다.
CI에서 릴리즈 생성·소스맵 업로드 후 앱을 배포하는 순서를 고정한 뒤 회귀 탐지 속도가 달라졌다
4주차: 슬랙 알림 정책과 온콜 에스컬레이션
마지막 주는 알림을 “다시 믿게 만드는” 작업이었다. 센트리 이슈가 정리돼도 슬랙으로 모든 이벤트를 보내면 1주차와 같은 피로가 재발한다. 팀은 알림을 세 층으로 나눴다.
첫째, 즉시 호출 층. 결제·인증·데이터 삭제처럼 비즈니스 치명 경로에서 신규 이슈가 발생하거나, 동일 이슈가 짧은 시간에 임계치를 넘으면 온콜 채널과 개인 멘션을 보낸다. 둘째, 근무 시간 리뷰 층. 일반 API 5xx 증가나 프론트 다수 사용자 영향 이슈는 평일 업무 채널로만 보낸다. 셋째, 대시보드 전용 층. 이미 알려진 이슈, 무시 규칙에 가까운 클라이언트 노이즈는 알림 없이 주간 리뷰에서만 본다.
이슈 소유 규칙도 문서화했다. 태그의 서비스 값에 따라 1차 담당 스쿼드를 정하고, 24시간 내 상태(확인 중/수정 중/무시/해결)를 갱신하도록 했다. “무시”는 삭제가 아니라 근거를 남기는 상태로 취급했다. 예를 들어 특정 구형 웹뷰의 수정 불가 버그는 이슈에 근거 링크를 달고 알림만 껐다. 4주차 말 슬랙의 즉시 호출 알림은 하루 수 건 수준으로 줄었고, 채널을 음소거하는 사람이 사라졌다.
결과: 4주 후 달라진 것과 아직 남은 구멍
4주 후 팀이 내부적으로 정리한 변화는 다음 네 가지였다. (1) 프로덕션 예외를 이슈 단위로 공유할 공통 언어가 생겼다. (2) 배포와 에러 증가를 같은 타임라인에서 보게 됐다. (3) 온콜 핸드오프가 로그 쿼리 복붙 대신 이슈 링크 중심으로 바뀌었다. (4) 알림 채널이 다시 신뢰 가능한 매체가 됐다.
한계도 분명했다. 센트리는 에러와 성능 트랜잭션에 강하지만, 비즈니스 퍼널 분석 도구를 대체하지 않는다. “결제 전환율이 떨어진 이유”를 이슈 목록만으로 설명할 수는 없었다. 또한 샘플링을 공격적으로 낮춘 구간에서는 희귀 레이스가 안 잡힐 위험이 남아, 치명 경로만 예외적으로 높은 수집률을 유지하는 정책을 계속 조정해야 했다.
비용 측면에서는 이벤트 볼륨 과금 구조를 초기에 오해했다. 노이즈를 줄이기 전 첫 주 사용량이 예산을 위협했고, 그 때문에 2주차 정책 재설계가 사실상 강제됐다. 관측 도구 도입 비용은 구독료만이 아니라, 필터 규칙을 설계하는 엔지니어링 시간과 같다. 이 문장을 팀 리드가 분기 보고서에 그대로 넣었다.
다른 팀이 가져갈 도입 플레이북
이 사례를 다른 제품 팀에 이식할 때 팀이 추천한 순서다. 도구 이름보다 순서가 중요하다.
1단계 — 신호 정의. 어떤 경로가 P1인지 먼저 적는다. 결제, 로그인, 데이터 손실, 권한 우회 후보를 문장으로 남긴다. 도구 없이 할 수 있는 작업이다.
2단계 — 환경 분리. 로컬·프리뷰·프로덕션 DSN과 전송 on/off를 분리한다. 이 단계를 건너뛰면 이슈 목록이 개발 잡음으로 오염된다.
3단계 — 최소 SDK와 무시 규칙. 프론트·백엔드에 SDK를 붙인 뒤, 첫 48시간은 “수집 과다”를 전제로 무시 패턴을 매일 갱신한다.
4단계 — 릴리즈·소스맵을 CI에 고정. 업로드 실패를 경고로만 두지 않는다. 스택이 읽히지 않으면 도구 가치가 급감한다.
5단계 — 알림 3층 구조. 즉시 호출 / 근무 시간 리뷰 / 대시보드 전용. 모든 이슈를 슬랙으로 보내지 않는다.
6단계 — 소유와 주간 리뷰. 이슈 상태 갱신 규칙과 주 1회 노이즈 감사. 관측은 설치가 아니라 운영 습관이다.
같은 스택이 아니어도 이 순서는 유지된다. 데이터독·그라파나·클라우드 로그를 쓰는 팀도 “이슈 단위·릴리즈 단위·알림 계층” 세 축만 맞으면 유사한 효과를 노릴 수 있다.
이 사례가 특히 참고될 팀
인원 3~10명 규모로 구독 제품을 운영하며, 아직 에러를 이슈 트래커 없이 슬랙과 로그만으로 보는 팀에 가장 직접적이다. 트래픽이 폭증하기 전, 알림 피로가 온콜 문화를 망가뜨리기 전에 도입하는 편이 싸다. 이미 APM이 있어도 프론트 예외와 릴리즈 회귀를 약하게 보는 팀도 보완 도구로 검토할 만하다.
반대로 이벤트 수가 극도로 적고 단일 서버 로그로 전부 재현 가능한 초초기 MVP라면, 구독 도구보다 구조화 로그와 요청 아이디 표준화가 먼저일 수 있다. 이 팀도 “로그가 엉망인 상태”에서 센트리만 얹었다면 태그 품질이 낮아 효과를 못 봤을 것이다. 최소한 요청 아이디와 배포 버전 문자열을 앱 전역에 심는 작업은 병행하는 편이 안전하다.
단일 서비스, 배포 빈도가 낮고, 에러 재현이 로그 한 줄로 끝나는 초기에 가깝다. 다만 프론트와 백엔드를 동시에 고치거나, 주 수회 이상 배포하거나, 온콜이 2인 이상으로 돌아가기 시작하면 이슈 그룹핑과 릴리즈 단위 비교가 없는 상태는 비용이 급격히 커진다. 이 사례 팀은 알림 150건을 넘기기 전에 도입했어야 했다고 회고했다.
Q. 도입 첫 주에 이슈가 폭주하면 구독을 바로 올려야 하나?
먼저 환경 분리와 무시 규칙을 점검하는 편이 맞다. 로컬·프리뷰 이벤트, 봇, 확장 프로그램, 이미 알려진 클라 예외가 볼륨의 상당 부분을 차지하는 경우가 많다. 이 팀은 플랜을 올리기 전에 필터를 손봐 비용을 통제했다. 과금 충격은 대개 “트래픽 성공”이 아니라 “수집 정책 부재”에서 온다.
Q. 소스맵 업로드를 배포 실패 조건으로 묶어도 되나?
팀 규모와 배포 긴급도에 따라 다르다. 이 사례에서는 초기엔 경고만 두었다가, 읽히지 않는 스택이 반복되자 업로드 실패 시 배포를 멈추는 쪽으로 바꿨다. 핫픽스 파이프라인을 따로 두는 팀도 있다. 최소 기준은 “프로덕션에서 스택을 사람 읽기 형태로 볼 수 있는가”다. 그것이 안 되면 에러 추적 도구의 절반 이상은 죽은 것과 같다.
Q. 알림을 줄이면 장애를 놓치지 않나?
줄이는 대상은 이벤트가 아니라 중복과 비치명 소음이다. 치명 경로의 신규 이슈와 급증은 즉시 호출 층에 남겨야 한다. 이 팀은 결제·인증 태그를 별도 규칙으로 분리해 알림 총량을 줄이면서도 핵심 신호는 강화했다. 모든 알림을 끄고 대시보드만 보는 방식은 권하지 않는다.
Q. 프론트엔드만 센트리, 백엔드는 다른 도구를 써도 되나?
가능하다. 다만 릴리즈 이름과 요청 상관 아이디를 양쪽에서 공유하지 않으면 원인 추적이 다시 로그 수작업으로 돌아간다. 도구가 달라도 식별자 표준은 하나로 맞추는 것이 이 사례의 숨은 전제였다. 여력이 되면 한 제품으로 맞추는 편이 온보딩 비용이 낮다.
Q. 스타트업이 셀프호스팅과 클라우드 중 무엇을 고르는 게 나은가?
관측 플랫폼 운영 인력이 없다면 클라우드로 시작하는 편이 이 팀 판단과 같다. 데이터 상주·규정 때문에 셀프호스팅이 강제되는 조직이 아니라면, 초기에는 필터·릴리즈·알림 설계에 시간을 쓰는 쪽이 제품 속도에 유리하다. 나중에 이벤트 규모와 규정 요구가 커지면 이전을 검토하면 된다.
