안정성의 본질

프로덕션 장애는 늘 사소한 균열에서 시작해서 시스템 전체를 삼키지. 안정성이란 이 균열이 장애로 번지는 걸 막는 능력이야.

사건의 시작부터 보자. 이건 실화야. 어느 항공사의 체크인 시스템이 통째로 먹통이 됐거든. 엔지니어들이 로그를 뒤져보니 DB 커넥션 풀 고갈이 눈에 띄었는데, 정작 DB 서버 자체는 멀쩡했어. CPU 정상, 디스크 정상. 진짜 원인은 훨씬 깊은 곳에 있었지. 특정 쿼리가 예상 못 한 null을 만나서 SQL 예외를 던졌고, 이 예외가 catch되지 않으면서 스레드가 커넥션을 반환하지 못한 채 죽어버린 거야. 한 번이면 괜찮았겠지만, 같은 조건의 요청이 반복되면서 커넥션이 하나씩 사라졌어. 풀이 말라가고, 새 요청은 대기하다 타임아웃, 그 타임아웃이 상위 시스템으로 번지면서 **연쇄 장애(cascade failure)**가 터진 거지.

이 사례가 보여주는 건 명확해. 장애는 "빵" 하고 터지는 게 아니라 균열(crack)처럼 느리게 퍼진다는 거야. try-catch 빠뜨린 것, finally에서 커넥션 반환 안 한 것, 풀 대기 타임아웃 안 건 것, 모니터링 없는 것 — 하나하나는 코드 리뷰에서 잡을 수 있는 사소한 실수잖아. 근데 이것들이 조합되면 전체 시스템을 무너뜨려. 개발 환경에서 100건 테스트 데이터로 "잘 되네" 하는 건 아무 의미 없어. 프로덕션에는 수백만 건 속에 예상 못 한 null이 숨어있거든. 저자가 이 책 전체에서 반복하는 말이 있어 — 소프트웨어는 **냉소적(cynical)**이어야 한다고. 외부 시스템을 믿지 마. 자기 자신도 믿지 마. 모든 **통합 지점(integration point)**은 잠재적 폭탄이야.

그렇다면 안정적인 시스템이란 뭘까? 트랜잭션 처리 능력이 시간이 지나도 유지되는 시스템이야. 여기서 트랜잭션은 DB 트랜잭션만이 아니라 로그인, 주문, 검색 같은 의미 있는 작업 단위 전부를 말하는 거지. 이 능력을 깨뜨리는 건 두 종류야. 뉴스에 나와서 트래픽이 10배 뛰는 것 같은 갑작스러운 임펄스(impulse), 그리고 메모리 누수가 서서히 쌓이는 것 같은 지속적인 스트레스(stress). 안정적인 시스템은 둘 다 흡수할 수 있어야 해.

항공사 사례를 다시 보면, null 값에서 시작해서 예외 미처리, 커넥션 미반환, 풀 고갈, 타임아웃, 연쇄 장애로 이어지는 **장애 체인(failure chain)**이 있었잖아. 저자의 핵심 통찰은 장애가 단일 원인으로 발생하지 않는다는 거야. 항상 체인이 있어. 그리고 그 체인의 시작점이 균열(crack) — 소프트웨어의 작은 결함, 예상 못 한 입력, 리소스 한계 같은 것들이지. 균열 자체를 완전히 없앨 수는 없어. 대신 균열이 장애로 확대되는 걸 막아야 해. 선박의 **격벽(bulkhead)**처럼, 한 구역에 물이 차도 배 전체가 가라앉지 않게 하는 거야. **결함(fault)**이 **오류(error)**가 되고 **장애(failure)**가 되는 과정에서, 좋은 시스템은 결함을 가지고 있되 장애로 이어지지 않아. 이게 **내결함성(fault tolerance)**의 본질이거든.

결국 시스템은 혼자 존재하지 않잖아. DB, 외부 API, 메시지 큐, 캐시 — 이 연결점들이 **통합 지점(integration point)**이고, 동시에 장애가 전파되는 통로야. 경계 바깥에서 일어나는 일은 통제 불가능하니까, 경계에서의 방어가 핵심이야. 저자의 철학을 한 문장으로 — "소프트웨어는 냉소적이어야 한다." 외부도, 사용자도, 자기 자신도 믿지 마.

---

정리

1장 읽고 기억할 거 세 가지:

1. 장애는 균열처럼 느리게 퍼져 — 잡히지 않은 예외 하나가 리소스 누수와 연쇄 장애를 통해 전체 시스템을 멈출 수 있어.
2. 안정성은 임펄스와 스트레스를 흡수하는 능력이야 — 장애 체인을 끊는 게 핵심 전략이고, 균열 자체를 없애는 건 불가능해.
3. 통합 지점은 장애의 고속도로야 — 시스템 경계에서의 방어(타임아웃, 서킷 브레이커)가 안정성의 첫걸음이야.