소개: 장애를 흉터가 아닌 이야기로 바꿀 때

대부분의 조직에서 장애는 작은 재난처럼 느껴집니다. 웹사이트가 멈추고, 필드에서 중요한 칩이 오동작하고, 한 제품 라인의 전원 서브시스템이 죽어버립니다. 그 다음에 무엇을 하느냐가, 이 사건이 반복되는 고통이 될지, 아니면 강력한 집단 학습의 원천이 될지를 좌우합니다.

많은 경우, 팀은 장애 후 리뷰(Post‑Incident Review, PIR)를 서둘러 끝냅니다. 하지만 그건 사실상 교묘히 포장된 ‘책임 추궁 회의’이기도 합니다. 누가 망가뜨렸지? 왜 이걸 못 잡았어? 어떤 체크리스트를 무시한 거야? 이런 식이죠. 결과는 뻔합니다. 사람들은 정보를 숨기고, 사실을 완곡하게 말하고, 똑같은 실수를 반복합니다.

하지만 장애를 다루는 또 다른 방식이 있습니다. 함께 만들어 가는 이야기로 보는 것입니다.

각 장애를 작은 천 조각, 즉 **‘종이 실패 패치(paper failure patch)’**로 보고, 그것들을 모아 하나의 큰 **‘신뢰성 퀼트(reliability quilt)’**로 꿰매는 **장애 스토리 바느질 모임("sewing circle")**을 떠올려보세요. 개별적으로 보면 각 패치는 아주 소박합니다. PIR 한 건, 문서 한 편, 회고 한 번에 불과합니다. 하지만 다 모이면 그것들은 조직 안에서 쌓여온 지혜의 지도를 그려줍니다.

이 글에서는 그 퀼트를 어떻게 만들어 갈 수 있는지 살펴봅니다. 소프트웨어 실무뿐 아니라, SGMICRO 같은 회사의 고신뢰 아날로그·전력 관리 엔지니어링에서, 필드에서 매일 조용히 문제 없이 동작해야 하는 칩을 뒷받침하는 ‘실패 이후 학습’의 방식까지 함께 참고합니다.

비난 게임에서 학습 엔진으로

**장애 후 리뷰(PIR)**는 자주 관리적 잡무 정도로 취급됩니다. “이거 빨리 처리하고 원래 일로 돌아가자”는 식의 형식적인 절차 말이죠. 이 태도는 지금 막 드러난 가장 소중한 원재료, 바로 시스템의 생생한 현실을 낭비하는 일입니다.

잘 설계된 PIR은 다음과 같은 역할을 합니다.

• 장애를 비난이 아닌 구조화된 학습 기회로 전환합니다.
• 무엇이 잘못됐는지만이 아니라, 당시 사람들이 어떻게 시스템을 이해하고 있었는지를 함께 담습니다.
• 설계, 모니터링, 문서, 팀 간 조율에서의 빈 구석과 단절 지점을 드러냅니다.

이를 위해 PIR은 누구 탓인지 기록하는 문서에서 무엇을 배웠는지 기록하는 문서로 바뀌어야 합니다. 그러려면 세 가지 의도적인 설계가 필요합니다.

1. 블레임리스(blameless) 프레이밍. 개인의 무능 탓이 아니라, 당시 주어진 조건, 트레이드오프, 눈에 보이던 신호에 초점을 맞춥니다.
2. 시스템적 질문. “우리 시스템은 어떻게 이 행동이 합리적으로 보이게 만들었는가?”, “어떤 신호가 없었거나 오해를 불렀는가?”를 묻습니다.
3. 미래 효용성. 그 자리에 없었던 미래의 엔지니어도 문서를 읽고 상황과 맥락을 이해하며, 배움을 재사용할 수 있도록 작성합니다.

PIR을 법적·관리적 기록이 아니라 학습 도구로 다루면, 엔지니어는 더 솔직해지고, 리더는 시스템 리스크를 더 명확히 볼 수 있으며, 실제 신뢰성도 나아집니다.

복잡한 시스템에서 실패는 비정상이 아니라 기본값

분산 서비스, 믹스드 신호 SoC, 아날로그 전원 스테이지 같은 복잡한 사회·기술 시스템에서는, 실패는 예외가 아니라 필연입니다. 부품은 특성값이 떠 있고, 입력은 변동하며, 운영자는 방해를 받습니다. 가정은 낡고, 환경은 변합니다.

고신뢰 조직은 다음과 같은 불편한 진실을 받아들입니다.

• 완전히 실패 없는 시스템은 존재하지 않는다.
• 대부분의 놀라움은 단일 부품이 아니라 상호작용에서 나온다.
• 모든 실패 모드를 사전에 예측하는 것은 불가능하다.

그래서 이들은 모든 실패를 없애려 하기보다, 다음에 집중합니다.

• 실패를 일찍 감지하기 (좋은 관측성, 타깃 테스트, 필드 피드백)
• 영향을 제한하기 (회로 보호, 피처 플래그, 우아한 성능 저하)
• 각 사건에서 깊이 배우기 (철저하지만 실용적인 장애 분석)

아날로그와 전력 관리 엔지니어링에서는 이런 사고방식이 직무 자체에 녹아 있습니다. 이상적인 부하와 온도에서 벤치 위에서만 잘 동작하는 전압 레귤레이터는 좋은 레귤레이터가 아닙니다. 당연한 전제는 이겁니다. 현실 세계 = 예상치 못한 상황 투성이. 설계, 검증, 실패 후 분석 프로세스가 처음부터 이 현실을 전제로 설계됩니다.

소프트웨어와 서비스도 여기서 배울 수 있습니다. 각 장애를 존재 자체를 부끄럽게 만드는 사건처럼 여기지 말고, 복잡한 시스템을 운영하면서 언젠가 반드시 마주칠 결과물로 받아들이는 것입니다. 단, 그 대신 매번 교훈을 뽑아내고 조직 전체와 나누는 데 진심으로 투자한다는 전제를 깔고 말이죠.

바느질 모임: 스토리텔링을 신뢰성 인프라로

기술적인 엄격함만으로는 충분하지 않습니다. 심리적 안전감이 필요합니다. 사람들이 헷갈렸던 순간, 아슬아슬했던 상황(near‑miss), 나중에 보면 너무 ‘당연한 실수’들을 기꺼이 털어놓을 수 있어야 합니다.

여기서 **"바느질 모임(sewing circle)"**이라는 은유가 중요합니다.

형식적이고 딱딱한 회의에서, 사람들이 방어적인 태도로 미리 정제된 타임라인만 발표하는 장면 대신, 이런 장면을 상상해 보세요.

• 정기적인 장애 스토리 공유 세션이 열리고, 엔지니어들은 각자 하나의 “패치”(장애 이야기나 아슬아슬했던 사례)를 들고 옵니다.
• 사람들은 기술적인 실패뿐 아니라, 당시 자신의 **멘탈 모델(mental model)**을 이야기합니다. 무엇을 믿고 있었는지, 어떤 판단이 합리적으로 보였는지, 어떻게 잘못된 길로 이끌렸는지까지요.
• 동료들은 비난이 아닌 호기심에서 나온 질문을 던집니다. “그 알럿을 그냥 넘기게 만든 요인은 뭐였나요?” “어떤 신호가 더 있었더라면 도움이 됐을까요?”

시간이 지나면 조직 문화가 이렇게 바뀝니다.

• 실패 이야기를 공유하는 것이 자신의 가치를 드러내는 기여로 여겨지고, 고해성사가 아닙니다.
• 신입·후배들은 자신이 겪지 않은 사건에서도 **대리 경험(vicarious experience)**을 쌓게 됩니다.
• 장애 서사는 개별 팀의 무용담이 아니라, 조직 전체의 공동 기억이 됩니다.

좋은 바느질 모임에는 다음을 책임지는 퍼실리테이터가 있습니다.

• 블레임리스를 지켜줍니다. (“여기는 책임을 묻는 자리가 아닙니다.”)
• 사건 사이의 공통 패턴을 짚어줍니다. (“이건 지난 분기 전원 브라운아웃 때 봤던 패턴과 비슷하네요.”)
• 스토리텔링이 실제 쓸 수 있는 산출물, 즉 종이 실패 패치로 이어지게 합니다.

종이 실패 패치: 문서를 퀼트 조각으로 보기

모든 PIR, 회고, 필드 실패 분석, 장애 보고서는 하나의 **"종이 실패 패치(paper failure patch)"**입니다. 그냥 작은 천 조각 하나죠. 그 자체로는 아주 지역적이고 제한적인 이야기처럼 보입니다. 하지만 다음을 잘 해두면:

• 검색 가능하고 접근 쉬운 공간에 보관하고,
• 일관된 구조(요약, 타임라인, 기여 요인, 배운 점, 후속 조치)를 사용하며,
• 시스템 영역, 실패 모드, 패턴으로 태깅한다면,

…이제부터 그것들을 모아 **신뢰성 퀼트(reliability quilt)**를 꿰매기 시작할 수 있습니다.

좋은 패치에 담겨야 할 것들

가치 있는 실패 패치는 보통 이런 내용을 포함합니다.

• 컨텍스트: 어떤 시스템, 어떤 버전, 어떤 환경, 어떤 부하 상태였는지.
• 무엇이 실패했는지: 사용자가 본 증상, 모니터링이 본 신호, 엔지니어가 관측한 현상.
• 어떻게 발견했는지: 알럿, 고객 신고, 내부 관찰 등.
• 타임라인: 시각과 주요 의사결정 지점이 분명히 드러나는 순서도.
• 기여 요인: 단일 ‘루트 원인’이 아니라, 함께 작용한 여러 요인들.
• 시스템적 인사이트: 우리의 프로세스, 도구, 조직 구조가 결과에 어떤 영향을 주었는지.
• 구체적 변화: 설계 수정, 가드레일, 테스트 추가, 모니터링 개선, 문서 보완 등.

각 패치는 개별적으로 보면 영향 범위가 작습니다. 하지만 1~2년만 쌓여도:

• 패턴이 보입니다. 특정 서브시스템에 대한 반복적인 오해, 취약한 연동 지점, 환경 변화에 반복적으로 민감한 부분 등.
• 온보딩과 교육 자료가 저절로 생깁니다. 실제 사례 기반의, 살아 있는 예제들 말이죠.
• 전략적 우선순위가 선명해집니다. 어디에 리디자인, 도구, 문서 개선 투자를 해야 하는지.

핵심은 이 문서들을 단순 컴플라이언스 산출물이 아니라, 살아 있는 연결형 지식 자산으로 다루는 것입니다.

하드웨어 안전에서 소프트웨어 장애까지: 더 깊은 통찰을 위한 CAST

오늘날 많이 쓰이는 시스템 관점 분석 방법론 상당수는 물리 시스템 안전 분야에서 태어났습니다. 항공, 자동차, 산업 제어, 반도체 제조 등이 그 예입니다. 그중 하나가 바로 **CAST(Causal Analysis based on STAMP)**입니다.

CAST는 “루트 원인이 뭐냐?”를 묻지 않습니다. 대신 이렇게 묻습니다.

• 제어 루프(control loop)(피드백, 모니터링, 의사결정)는 어떻게 동작했고, 어디서 실패했는가?
• 어떤 **제약(constraint)**을 전제로 삼았고, 무엇이 위반되었거나 아예 없었는가?
• 조직 구조, 도구, 인센티브가 결과에 어떤 형태로 작용했는가?

CAST식 사고를 소프트웨어·서비스 장애에 적용한다는 것은 곧 다음을 의미합니다.

1. 시스템을 단순 부품 집합이 아니라 **제어 구조(control structure)**로 모델링합니다. 누가/무엇이 어떤 변수를 어떤 범위 안에 유지하려 하는지 정의합니다.
2. 정보 흐름과 지연에 주목합니다. 어떤 신호가 없었는지, 늦게 도착했는지, 잘못 해석됐는지 살펴봅니다.
3. **운영 절차, 대시보드, 런북(runbook)**도 하나의 컨트롤러로 보고, 설계 결함의 영향을 받는 대상으로 다룹니다.

예를 들어, 프로덕션 API 장애가 있었다고 해서, 그 원인이 그냥 “버그 있는 배포 한 번”이라고만 말할 수는 없습니다. CAST 관점에서 보면 다음과 같은 것들이 함께 보일 수 있습니다.

• 롤백을 느리고 부담스럽게 만드는 배포 프로세스.
• 미세한 드리프트보다 노이즈 감소를 지나치게 우선시한 모니터링 설정.
• 신중한 스테이징을 꺼리게 만드는, 기능 출시를 강하게 압박하는 조직 문화.

이런 통찰은 “X 엔지니어가 나쁜 코드를 배포했다”는 식의 결론보다 훨씬 깊습니다. 사건 전체의 빈도를 줄이거나, 관리 난이도를 낮출 수 있는 구조적 레버를 보여주기 때문입니다.

하드웨어와 아날로그 엔지니어링 팀들은 이미 이런 시스템 관점 분석을 수년간 사용해, 필드에서의 치명적 실패를 예방해 왔습니다. 소프트웨어와 서비스 조직도 그 도구와 마인드셋을 그대로 가져다 쓸 수 있습니다.

고신뢰 아날로그·전력 관리 엔지니어링에서 배우는 것들

SGMICRO와 같은 회사의 아날로그·전력 관리 엔지니어링 분야는, 실패 이후 학습이 어떻게 실제 신뢰성으로 전환되는지 잘 보여주는 구체적인 사례입니다.

여기서 걸려 있는 것은 가볍지 않습니다.

• 전력 관리 IC와 아날로그 프론트엔드는 절대 조용히 망가지면 안 되는 제품의 심장부에 자리 잡는 경우가 많습니다. 의료 기기, 산업 시스템, 인프라 장비 등이 그렇습니다.
• 이 칩들은 험한 환경에서 일합니다. 극한 온도, 노이즈 많은 전원, 예측하기 어려운 부하 조건 등.

요구되는 신뢰성을 달성하기 위해 팀이 하는 일은 다음과 같습니다.

• 단순 기능이 아니라 실패 시 거동까지 파고드는 디자인 리뷰를 광범위하게 수행합니다.
• 해피 패스(happy path)를 훨씬 넘어서는 **코너 케이스 검증(corner‑case validation)**을 진행합니다.
• 필드에서 디바이스가 실패하면, **엄격한 필드 실패 분석(field‑failure analysis)**을 통해 사건의 연쇄를 해부합니다.
• 거기서 얻은 통찰을 설계 룰, 레이아웃 가이드라인, 테스트 플랜, 애플리케이션 노트에 되먹임합니다.

이 각각의 분석이 곧 하나의 종이 실패 패치가 됩니다.

• 실패 리포트 한 건이, 새로운 디레이팅(derating) 가이드라인으로 이어집니다.
• 포스트모템 한 건이, 레퍼런스 디자인에 새로운 레이아웃 제약 조건을 추가하게 만듭니다.
• 필드 사건 하나가, 새로운 ‘신뢰성 설계(Design for Reliability)’ 체크리스트를 탄생시킵니다.

이 문서들이 시간이 지나며 쌓이면, 미래 제품들이 예상 밖의 상황에서도 훨씬 안정적으로 동작할 수 있도록 돕는 신뢰성 퀼트가 형성됩니다. 새로 합류한 엔지니어는 단순히 회로도만 물려받는 게 아니라, 고생해서 얻은 교훈의 문화와 지식 집합까지 함께 물려받습니다.

소프트웨어와 서비스 조직도 이를 그대로 따라 할 수 있습니다.

• 장애를, 하드웨어 팀이 필드 리턴을 대하는 것만큼 진지하게 다루고,
• 각 사건을 패턴, 설계 원칙, 가드레일로 일반화하는 입력값으로 삼으며,
• 실패 이후 학습을 신뢰성의 핵심 축으로 두고, 부수적인 업무로 취급하지 않는 것입니다.

결론: 지금부터 당신의 신뢰성 퀼트를 꿰매기 시작하라

장애는 앞으로도 계속 일어납니다. 회로는 때때로 오동작하고, 서비스는 멈추고, 통합 지점은 가장자리가 갈라질 것입니다. 모든 실패를 막을 수는 없습니다. 하지만 그 실패들이 당신 조직 안에서 무엇으로 남을지는 선택할 수 있습니다.

만약 당신이:

• 블레임리스이면서 구조화된 PIR을 정착시키고,
• 실패를 복잡한 시스템에서 나오는 당연한 데이터 포인트로 바라보며,
• 솔직한 공유를 장려하는 스토리텔링 바느질 모임을 만들고,
• 각 사건을 빠짐없이 종이 실패 패치로 남기고,
• CAST 같은 시스템 분석 방법을 적용해 더 깊은 패턴을 찾아내고,
• 아날로그·전력 관리 같은 고신뢰 분야에서, 실패 이후 학습을 필수 조건으로 삼는 태도를 배운다면,

…각 장애는 더 이상 흉터로만 남지 않습니다. 조직이 쌓아 온, 현실에서 시스템이 실제로 어떻게 동작하는지에 대한 이해가 눈에 보이는 형태로 모여 있는 신뢰성 퀼트의 한 조각이 됩니다.

시간이 지나면, 이 퀼트는 단순히 신뢰성을 기록하는 데 그치지 않습니다.

이 퀼트가 곧 신뢰성을 만들어냅니다.