# 인시던트 대응 모범 사례: 솔로 dev를 위한 실전 가이드

URL: https://whatshouldibuildnext.com/ko/journal/incident-daeeung-mobeom-sarye
Type: blog
Locale: ko
Published: 2026-08-29
Updated: 2026-08-31

---

> 인시던트 대응은 대기업만의 전유물이 아니다. 솔로 dev도 새벽 3시의 장애를 4분 안에 해결할 수 있다. 알람 설정부터 런북 작성, 퍼블릭 상태 페이지까지, 이번 주말에 완성하는 최소 인시던트 대응 시스템.

## 인시던트 대응 모범 사례: 솔로 dev가 새벽 3시에도 버티는 법

**인시던트 대응 모범 사례**는 대기업 팀을 위해 쓰인다. 솔로 개발자를 위한 건 거의 없다. 사이드 프로젝트를 출시하고, 유저가 생기고, 어느 날 아침 누군가의 트윗으로 세 시간째 다운됐다는 걸 안다. 알람도 없었고, 런북도 없었고, 상태 페이지도 없었다.

이게 솔로 빌더의 장애 시나리오다. 보안 침해가 아니라, 인프라 대재앙도 아니라. 아무도 알려주지 않았고, 아무 계획도 없었고, 유저가 나보다 먼저 알았다.

40페이지짜리 플레이북이나 엔터프라이즈 툴 스택이 필요한 게 아니다. 세 가지만 있으면 된다: 뭔가 망가진 걸 알기, 뭘 해야 할지 알기, 관심 있는 사람에게 상태를 알리기. 이 가이드는 빌더 관점에서 각각을 다룬다. 직접 만들어야 할 것과 기존 툴을 연결할 것까지.

## 솔로 온콜일 때 제일 먼저 터지는 게 뭔가

첫 번째 인시던트를 혼자 처리할 때, 실제로 고치는 데 4분 걸리기 전에 어디에 뭐가 있는지 찾는 데 12분을 쓴다.

그게 진짜 비용이다. 다운타임이 아니라, 아무것도 적어두지 않은 1인 팀의 조율 오버헤드. 환경 변수는 어디에? 어떤 서비스가 실제로 장애인가? 전체 유저에 영향인가, 특정 고객만인가? 인시던트의 골든 타임 동안 미리 답해뒀어야 할 것들을 뒤지고 있다.

복잡한 툴이 답이 아니다. 새벽 3시 전에 그 질문들에 답해두는 게 답이다.

유용한 테스트 하나: 지금 당장 프로덕션 API가 다운됐다고 상상해보자. 10분이 있다. 관련 로그를 찾고, 실패한 컴포넌트를 파악하고, 지금 열려있지 않은 탭 두 개 이상 열지 않고 롤백이나 핫픽스를 할 수 있나? 안 된다면, 그게 정확히 인시던트 대응이 해결하는 문제다.

![밤늦게 책상에 앉아 여러 알림과 서버 모니터링 화면을 보는 솔로 개발자](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/2586d5-inline1.webp)

## 인디 개발자 인시던트 대응에 실제로 필요한 세 가지

뭔가를 만들기 전에, 시스템이 해야 할 일을 명확히 하자:

- 
**문제를 감지하기**: 유저가 DM 보내기 전에

- 
**뭘 해야 할지 알려주기**: 반쯤 잠든 상태에서 알람만 가지고 있을 때

- 
**유저에게 알리기**: 상황을 더 악화시키지 않으면서

PagerDuty부터 직접 만든 크론 잡까지, 모든 인시던트 대응 툴은 이 세 가지 역할 중 하나에 매핑된다. 세 가지를 모두 하는 가장 단순한 버전을 만들고, 거기서 멈춰라.

엔터프라이즈 버전으로 가고 싶은 유혹이 있다: 온콜 스케줄, 에스컬레이션 정책, P0부터 P5까지 심각도 레벨, 포스트모템 템플릿. 엔지니어 20명에 유저 50만 명이면 적합하다. dev 1명에 유저 500명이면, 그 추상화들은 주말을 태우고 사용되지 않는다. 최소 버전은 이번 주말에 만들 수 있다. 그걸 먼저 ship해라.

## 알람 레이어 구축: 오탐 문제가 먼저다

자체 알람을 만들어본 dev는 다 같은 얘기를 한다: 처음 만든 룰이 틀렸고, 2주 동안 노이즈에 시달리다 페이저를 꺼버렸다.

중요한 체크 하나부터 시작해라. 헬스 체크 엔드포인트 하나면 충분하다.

`# 간단한 헬스 체크 엔드포인트 (Express/Node)
app.get('/health', (req, res) => {
  res.json({ status: 'ok', timestamp: Date.now() });
});`그다음 60초마다 핑을 보내는 크론 잡을 연결해라. 세 번 연속 실패하면 문자가 온다. 이게 첫 번째 알람 레이어다. 유저에게 영향을 주는 인시던트의 80%를 잡는다.

이 설정의 오탐률은 거의 0이다. 서비스가 실제로 다운됐을 때 페이지되고, 캘리브레이션되지 않은 임계값을 CPU 스파이크가 트리거했을 때가 아니다. 알람에서 제일 어려운 건 그거다: 알람은 매번 사실이어야 한다, 아니면 무시하도록 훈련된다.

로그 기반 알람은 업타임 체크가 작동하고 신뢰된 뒤에 온다. 셀프 호스팅 스택에선 Grafana가 낮은 비용에 잘 처리한다. Datadog은 서비스가 두세 개 이상이고 배포 파이프라인과 쉬운 통합이 있는 통합 뷰를 원할 때 의미가 생긴다.

## 런북은 밤 11시에 써서 새벽 3시에 읽는 문서다

런북은 문서가 아니다. 문서는 뭔가가 어떻게 작동하는지 설명한다. 런북은 스트레스를 받고, 반쯤 잠들어 있고, 압박 아래 있는 미래의 나에게 지금 당장 정확히 뭘 해야 하는지 알려준다.

솔로 프로젝트에서 작동하는 포맷:

- 
**뭐가 망가졌나?** 한 문장, 관찰 가능한 증상만

- 
**긴급한가?** 지금 결제 유저에게 영향을 주는가?

- 
**뭘 해야 하나?** 3-5개 번호 매긴 단계, 제일 빠른 것부터

이게 전부다. 인시던트가 없을 때 쓰고, 인시던트 이후에 실제로 유용했는지 검토하고 업데이트해라.

런북을 어디에 저장하느냐는 쓰는 습관보다 덜 중요하다. Notion 페이지, 레포의 Markdown 파일, 공유 문서. 테스트: 새벽 3시, 반쯤 잠든 상태에서 폰으로 30초 내에 열 수 있나?

레포 파일보다 Notion을 택하는 실용적인 이유는 모바일 접근성이다. 방금 배포한 것 때문에 불안한 감이 있어서 폰 옆에 자고 있다면, 그게 중요하다. GitBook은 구조화된 걸 선호하고 퍼블릭 개발자 문서로도 쓰고 싶다면 괜찮은 옵션이다.

![인시던트 대응 의사결정 플로우차트가 적힌 노트와 랩탑 터미널이 있는 개발자 책상](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/4f1cbf-inline2.webp)

## 퍼블릭 상태 페이지: 장애 시 유저가 실제로 원하는 것

유저들은 리얼타임 옵저버빌리티 대시보드가 필요한 게 아니다. 두 가지만 알고 싶다: 모두에게 장애인가, 그리고 담당자가 알고 있는가?

최소 상태 페이지에는 세 가지 요소가 있다:

- 
상태 인디케이터: 최대 세 가지 상태 (정상, 저하, 중단)

- 
현재 상태가 마지막으로 업데이트된 타임스탬프

- 
장애 시 평범한 언어로 된 한 줄 설명

인시던트 중에 상태 페이지를 확인하는 유저들은 아키텍처 다이어그램을 읽는 게 아니다. 내 설정 문제가 아니라는 걸 알아서 자기 쪽 트러블슈팅을 멈추고 싶은 것이다.

이걸 만드는 데 네 시간 미만이면 된다:

- 
엔드포인트에서 상태를 가져오는 JavaScript 스니펫이 있는 정적 HTML 페이지

- 
두 개 필드가 있는 Supabase 테이블: status (enum)와 message (text)

- 
헬스 체크 결과에 따라 상태를 업데이트하는 크론 잡

- 
수동 메시지를 쓸 때 인증 뒤의 admin 엔드포인트

어려운 건 빌드가 아니다. 인시던트 중에 바로 수정하러 뛰어들지 않고 업데이트하는 습관이다. 업데이트는 30초 걸리고 고객 지원 이메일 15개를 아낀다.

이걸 직접 만드는 또 다른 이유: 상용 상태 페이지 툴은 근본적으로 JSON 엔드포인트와 정적 HTML 페이지인 것에 월 $30에서 $100을 청구한다. 한 번 만들고 소유해라. 유저들에게 Statuspage.io가 필요한 게 아니다. 메인 도메인이 다운됐을 때도 작동하는 URL이 필요한 것이다.

![서비스 상태 인디케이터와 업타임 그래프가 있는 다크 UI의 상태 페이지 대시보드](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/dd8fe9-inline3.webp)

## 혼자만 탓할 사람이 있을 때의 포스트모템

엔터프라이즈 포스트모템은 개인을 탓하지 않고 시스템적 실패를 찾는 것에 관한 거다. 솔로일 때는 내가 시스템이다. 심리는 다르지만, 실천은 여전히 중요하다.

혼자 포스트모템을 쓰는 이유: 쓰지 않으면 같은 종류의 문제를 두 번 풀게 된다. 세 달 뒤 추가하지 않은 인덱스 때문에 데이터베이스 쿼리가 락됐을 때, 전에 비슷한 걸 고친 기억이 어렴풋이 날 텐데 뭘 했는지는 기억 안 난다.

AI 지원을 쓰면 포스트모템 재구성에 약 15분이면 되는 반면, 수동으로는 60-90분이 걸린다. 5분 포맷으로 인시던트 직후에 써라:

- 
무슨 일이 있었나 (한 단락, 사실만, 비난 언어 없이)

- 
어떻게 고쳤나

- 
시스템에서 바꿀 것 하나

- 
프로세스에서 바꿀 것 하나

런북과 같은 곳에 써라. 다음 런북 업데이트의 인풋이 된다. 6개월이 지나면, 어떤 엔터프라이즈 포스트모템 툴도 솔로 빌더에게 복제해주지 않는 시스템 실패 패턴의 경량 기록이 생긴다.

## 직접 만들까, 기존 툴을 연결할까?

솔직한 답은 지금 어느 위치에 있느냐에 달려 있다.

결제 유저가 없다면: 전부 직접 만들어라. 헬스 체크 크론, 상태 페이지, Notion 런북. 패턴을 배우기 딱 맞는 프로젝트다. 주말에 ship된다. 인시던트 대응이 실제로 뭘 필요로 하는지 가르쳐준다. 나중에 이걸 제품으로 만들어 팔기로 결정하면, 내 자신에게 먼저 요구사항을 검증한 거다.

오늘 업타임에 의존하는 결제 유저가 있다면: 기존 툴부터 시작해라. Grafana Cloud 무료 티어 연결하고, 업타임 모니터 설정하고, 오늘 오후 Notion 런북 페이지 하나 열어라. 지금 당장 커버리지가 필요하고, 3주 빌드 후가 아니라.

단계에 관계없이 직접 만들 가치가 있는 것: 상태 페이지. 소유하고, 별도 도메인에 호스팅하고, 이번 주말에 만들어라. 복잡도가 정당화될 때까지 나머지는 기존 무료 티어로 연결할 수 있다.

## 어떤 인시던트 대응 가이드도 얘기하지 않는 것

문제는 툴이 아니다. '알람 설정해야겠다'와 '실제로 알람을 설정했다' 사이의 48시간이다.

대부분의 솔로 dev 스택에는 하루 만에 첫 번째 인시던트 대응 레이어를 만들 옵저버빌리티 프리미티브가 충분히 있다. 헬스 체크 엔드포인트는 어딘가 있다. 로그는 어딘가 있다. 배포 파이프라인에 에러 핸들링이 있다. 빠진 건 90분의 집중적인 연결 작업이다: 헬스 체크에서 업타임 모니터로, 업타임 모니터에서 SMS나 텔레그램 알람으로, 런북 세 개가 있는 Notion 페이지 하나, Supabase 상태 엔드포인트가 있는 정적 페이지.

유저에게 ship하는 프로젝트가 아니다. 나 자신을 위해 ship하는 프로젝트다.

이번 주말에 만들어라. 새벽 3시에 뭔가 터졌는데 40분 동안 찾는 대신 4분에 고치고 나면, 왜 인시던트 대응 모범 사례가 존재하는지 이해하게 된다. 엔터프라이즈 팀이 요구해서가 아니라, 대안이 더 나쁘기 때문에.

## FAQ

### 인시던트 대응 시스템을 구축하는 데 얼마나 걸리나?

최소 버전은 하루면 된다. 헬스 체크 엔드포인트, 업타임 모니터, Notion 런북 하나. 상태 페이지를 추가하면 4시간이 더 걸린다. 주말 프로젝트로 충분하다.

### 솔로 개발자에게 PagerDuty 같은 유료 온콜 툴이 필요한가?

초기에는 아니다. 크론 잡 기반의 헬스 체크에 SMS나 텔레그램 알람을 연결하면 유저에게 영향을 주는 인시던트의 80%를 잡는다. 유료 툴은 팀이 생기거나 서비스가 세 개 이상 될 때 고려해도 늦지 않다.

### 알람 오탐 문제를 어떻게 줄이나?

처음에는 체크 하나만 시작해라. 3번 연속 실패 시 알람. 임계값 기반 알람은 캘리브레이션이 필요하고 오탐이 많다. 업타임 체크가 안정적으로 작동한 뒤에 로그 기반 알람을 추가해라.

### 런북을 어디에 저장하는 게 좋나?

새벽 3시에 폰으로 30초 내에 열 수 있는 곳. Notion이 모바일 접근성이 좋고, GitBook은 퍼블릭 문서로 병행하기 좋다. 레포 Markdown도 괜찮지만 모바일에서 접근성이 떨어진다.

### 상태 페이지를 직접 만드는 게 정말 더 나은가?

비용 측면에서 그렇다. 상용 툴은 월 $30에서 $100이다. 직접 만들면 Supabase 테이블 하나와 정적 HTML 페이지로 4시간 만에 동일한 기능을 가진다. 한 번 만들면 평생 소유한다.

### 포스트모템을 혼자 쓰는 게 의미 있나?

있다. 같은 종류의 문제를 두 번 풀지 않기 위해서다. AI 지원을 쓰면 포스트모템 재구성에 약 15분이면 되는 반면, 수동으로는 60-90분이 걸린다. 5분 포맷으로 인시던트 직후에 써라.

### MTTR을 얼마나 줄일 수 있나?

자동화된 인시던트 대응 시스템은 MTTR을 최대 80%까지 줄일 수 있다. 핵심은 툴이 아니라 '어디에 뭐가 있는지' 미리 답해두는 것이다. 수동 조율에서 낭비되는 12분을 없애는 게 시작이다.