Unclebae
School Dev Ops Stubs
Learn Devops and Do Devops

Improve your product quality from mistake and error

실수와 오류로 부터 배우는 품질향상

사람은 누구나 실수를 한다. 사람이기 때문에 실수를 한다.

작은 실수도 있지만, 매우 큰 치명상을 입는 실수도 있고, 기업에서는 막대한 손실을 가져올 수 있는 실수도 존재한다. 이런 치명적인 실수를 우리는 사고라고 부르기도 한다.

증권회사에서 $1,000 짜리 1주를 팔아야하는 것을 실수로, 1$에 1000주를 팔아서 밀리언 달러의 손해를 보게 된다. 실제 이러한 사건이 발생했으며 다음에서 찾아 볼 수 있다.Fat-finger error

IT 업무 관점에서 볼 때 실수로 인해서 고객에게 불편을 안겨주거나, 심지어는 고객을 잃는 경우도 있다.

누구나 실수와 사고를 일으킬 수 있기 때문에 이러한 것들을 완젼히 제거하기는 불가능하다. 그러나 한가지 긍정적인 방법은 이런 실수를 다시 발생하지 않도록 대응책을 마련할 수 있다.

이번 아티클에서는 실수와 장애에 대처하는 방법들에 대해서 알아보고, 어떻게 발전해 나아가야할 지에 대해서 고민해 보고자 한다.

실수와 오류

사전적인 의미로 실수는 사람이 인지하지 못한 일이 일어나는 것으로 왜 발생했는지를 알고 있는 것을 말한다. 반면 오류(error)는 지식의 부족으로 인해서 문제를 일으키는 것을 이야기 한다.

컴퓨터가 수행하는 일에서 실수는 존재하지 않는다. 그러나 오류는 발생할 수 있다. 사람은 이러한 실수와 오류 둘다 만들어내며, 사람의 실수가 컴퓨터의 오류를 만들어 내기도 한다.

이렇게 분리한 이유는 실수와 오류가 가지는 특성으로 인해서 대응 방식이 조금 다르기 때문이다.

실수의 경우에는 실수를 방지하기 위한 방법이 사용되며, 실수를 하지 않게 가이드라인을 제시하거나, 제약조건을 주는 형태로 진행이 될 것이다.

오류의 경우에는 사전에 미리 알 수 없는 일이 발생하므로, 오류를 검출하고, 오류에 대해서 대응하는 체계를 가지는 방향으로 진행이 될 것이다.

서로 진행하는 방향은 약간 다를 수 있으나, 중요한 것은 단순히 인지하는 것을 넘어서 실수와 오류를 통해서 배움이 있어야 하며, 이러한 배움을 조직과 시스템에 반영하여 개선하는데 그 목적을 두어야 할 것이다.

품질

품질을 살펴보자. 깊이있는 내용을 논하기에는 일단 필자의 전문분야가 아니라 더 논할 수 없겠다.

그러나 최소한 필자의 생각으로 품질은 가격대비 우수한 제품을 말한다고 정의내리고 싶다. 낮은 가격에서도 높은 품질을 유지한다면 제품 가격은 자연히 올라갈 것이고, 높은 가격임에도 품질이 낮다면 제품 가격은 떨어져야하거나, 더이상 팔리지 않게 될 것이다.

제품을 구매하는 입장이 아니라 제공하는 입장에서도 제품에 들어가는 리소스에 비례해서 품질이 높다, 낮다라는 평가를 받게 될 것이다. IT 제품인 소프트웨어라면 이러한 리소스에 투입된 인력, 자동화, 조직문화, 오류를 대처하는 마인드셋과 실천력 이 모든것 역시 포함된다고 할 수 있다.

소프트웨어의 품질이 좋다는 것은 보통 이렇게 이야기 할 수 있을 것이다.

  • 빠른 반응속도 (1초 이내 응답)
  • 편리한 UX (직관적으로 사용할 수 있으며, 필요한 서비스를 적절한 시점에 유도하는등)
  • 고객의 실수를 미연에 방지하는 메커니즘 (잘못된 고객의 실수로 인해서 고객에게 시간, 금전 피해를 주지 않도록 하기)
  • 장애없이 사용할 수 있는 소프트웨어 (제품의 이슈로 고객이 제품을 사용할 수 없는 상태가 되지 않도록 고가용성 제공)
  • 고객의 니즈를 빠르게 반영하여 업그레이드 되는 제품 (고객의 불편, 니즈를 캐치하여 제품에 반영하는 가시성 있는 로드맵)

위와 같은 측면에서 문제를 정의하고, 진단하며, 빠르게 대응할 수 있는 시스템을 갖출 필요가 있다. 이런 시스템은 한번의 기획으로 완성되지 않으며, 반복되는 이슈와 문제로 부터 배우고, 이를 실제 제품에 반영하는 과정을 통해서 달성 할 수 있다.

장애를 대응하는 기존 방법

우선 장애를 대응하는 기존 방법부터 알아볼 필요가 있다.

일반적인 장애 보고서는 다음과 같다.

  • 장애 발생시간 및 종료시간
    • 발생시간: 2020-12-01 11:00
    • 장애인지: 2020-12-01 11:05
    • 장애조치: 2020-12-01 11:20
    • 종료시간: 2020-12-01 11:30
    • 총 리드타임: 30분
  • 장애 등급
    • 2등급
    • 일부 고객이 제품을 장바구니에 담지 못하는 현상
  • 장애 영향도
    • 해당 시간 평균 사용유저수: 10,000명
    • 해당 시간 오류 경험유저수: 100명
    • 일부 사용자가 제품에 장바구니를 30분간 담지 못하는 현상 발생
  • 장애 원인
    • 잘못된 프런트 소스 배포로 인해서 잘못된 버젼을 사용한 고객이 장바구니에 제품을 담지 못하는 현상 발생
  • 장애 처리상황
    • 롤백 후 웹서버 캐싱 초기화로 장애 해결
  • 재발방지 대책
    • 잘못된 소스 코드가 배포 되지 않도록 리뷰강화
    • 스테이지 테스트 강화

어떻게 보면 매우 쳬계적이며, 모든 것이 다 갖춘 문서이다. 그러나 실제 사용시 구체적이지 않으며, 대안 역시 표면적이다.

이 보고서에서 얻을 수 있는 정보

  • 장애 시간이 30분 정도이다.
  • 1%의 장애이지만 실제 고객에게 영향을 준 등급이 높은 장애이다.
  • 잘못된 소스가 배포된 장애
  • 리뷰를 강화해서 재발을 방지하자.
  • 스테이지 테스트를 강화하자.

위 정보로 우리가 과연 제품의 퀄리티 향상을 보장할 수 있을까? 무언가 부족하다.

부족한 부분

  • 장애의 근본 원인이 잘못된 소스인가?
  • 잘못된 소스를 리뷰하는 구체적인 방법은 무엇인가?
  • 테스트를 강화하는 구체적인 방법은 무엇인가?

위 보고서에서 좀더 향상된 방법은 무엇일까?

이제부터 몇가지 방법들을 살펴 보면서 위 보고서에서 어떤 부분을 보충하면 좋을지 고민해보자.

그리고 장애뿐만 아니라 제품을 개선할 수 있는 다양한 포인트를 위한 방법이 무엇인지에 대한 도구들을 알아보자.

Postmortem

Postmortem 은 많은 기업에서 특정 문제가 발생했을때 문제의 원인을 분석하고, 문제로 인해 어떠한 영향을 회사가 받게 되었으며, 이러한 문제를 어떻게 방지할 수 있는지를 파악하여 손실을 줄이고, 나아가 서비스와 제품의 질을 향상 시키거나, 직원의 행동을 개선하여 발생할 수 있는 손실을 최소화 하는 과정이다.

정의

Postmortem 부검이라는 의미이다. 이는 시체를 부검하여 그 사람이 왜 어떻게 죽게 되었는지를 간접 혹은 직접적인 사인을 밝히는 것을 말한다.

수행원칙

Postmortem 은 다음과 같은 과정을 통해서 수행이 된다.

  1. 사고를 우선 수습한다.
  2. 모든 관계자가 참석하는 미팅을 수행한다.
  3. 문제가 발생한 시간을 분석한다.
  4. 잘 수행한 일과 말못된 일 모두를 나열해본다.
  5. 책임자를 문책하지 않는다. (이 부분이 가장 어렵다.)
  6. 개선책을 도출한다.
  7. 공개하고 개선사항을 실천한다.

위 과정을 통해서 수행하는 이유를 우선 이해 해 보자.

한마디로 말해서, 문제가 발생하고 문제를 해결한 과정을 회고하면서 스스로를 돌아보고, 발견된 문제점들을 개선하기 위한 일련의 과정이다.

즉, 우리가 Postmortem 을 수행하는 근본 목적은 회고를 통해서 문제점을 개선하여, 실제적으로는 기업의 손실을 최소화 하거나, 더 향상된 제품을 만드는데 목적이 있는 것이다.

장점

  • 보고를 위한 문서 작성이 필요없다.
  • 개인의 문제가 아니라. 모두의 문제임을 인식할 수 있는 공동의 장을 만들어준다. (개인에게 책임을 묻지 않는다.)
  • 장애 과정을 구체적으로 살펴 보면서 발견된 다양한(문화, 도구, 대응체계, 개인의 자세) 문제점들을 복합적으로 생각해 보고 토론해 볼 수 있는 시간을 가질 수 있다.
  • 구체적인 방안과 실천사항이 만들어 진다.
  • 전체 조직에 공개함으로 해서 투명한 이슈 관리 및 모두가 공동의 목표를 공유하며, 나아가 문제를 바라보는 문화를 변경하도록 돕는다.

단점

  • 도입이 쉽지 않다.
    • 모임 시간을 마련해야한다.
    • 개선을 위한 시간 역시 필요하다.
    • 문제에 대한 심각성을 이해하지 못하게 된다.

사실 단점은 사람이 바라보는 Postmortem 표면적인 부분에 대해서만 이야기 한 것이다. 정말 이슈를 지금처럼 단순한 미봉책으로 해결하고 빨리 다음 스텝으로 넘어가야한다는 단순한 생각으로 인해 도입이 쉽지 않다는 것이다.

하지만 우리는 목적을 명확히 해야한다.

장애가 미치는 영향이 작은 사건이라도 많이 발생하면 형편없는 서비스를 제공할 수 밖에 없을 것이다.

큰 장애가 매번 발생하고, 표면적 문제만 대응한다면, 그 회사의 제품은 더이상 매력이 없을 것이고, 심지어는 회사에 존폐에도 영향을 줄 것이다.

도구

지금까지 Postmortem 에 대해서 살펴 보았다.

개략적인 절차는 이미 이야기한바와 같이 다음과 같다.

  1. 문제를 해결한다.
  2. 관련자가 모두 참여한 Postmortem 회의를 연다.
  3. 시간에 따른 문제 발생과 해결과정을 함께 살펴본다.
  4. 근본 원인을 파악한다.
  5. 재발 방지 및 근본 원인을 해결할 수 있는 해결책을 제시한다.
  6. 실천사항을 도출한다.
  7. 전체 조직에 공유하고 실천사항을 실천한다.
  8. 실천 결과를 리뷰한다.

위 과정을 거쳐 Postmortem 이 이루어 진다. 각 주요 단계마다 매우 훌륭한 도구가 존재하며 우리는 다음 3가지 방법에 대해서 살펴볼 것이다.

  • 근본 원인을 파악하는 방법
  • 재발방지를 위한 해결책 제시
  • 해결책과 실천과정 그리고 리뷰 방법

위 도구들에 대해서 이제 하나씩 살펴보자.

문제를 분석하는 도구 (5Why)

장애가 발생하면 장애가 발생한 근본 원인을 이해하는 것이 매우 중요한 시작 포인트라고 할 수 있다.

처음 이야기 했듯이 문제가 발생하면 피상적인 원인을 나열하고, 재발 방지를 올바르게 도찰하지 못한다면, 아마도 동일한 문제가 계속해서 발생하게 될 것이다.

이런 방법으로는 우리가 원하는 개선을 얻기는 어려울 것이다.

문제의 근본 원인을 분석하는 훌륭한 기법으로 5Why 가 있다.

정의

문제에 대한 근본 원인과 핵심에 대해 구체적으로 파고 들며 5단계에 걸쳐 질문을 하고 답변을 하면서 근본 문제를 파악해 나가는 기법

5why 는 도토타의 창립자인 사키치 도요타에 의해서 1930년대 개발되었다. 이 말은 “go and see” 의 도요타의 철학이 담겨 있으며, 의사 결정시 실제 데이터와 현상을 깊이있게 분석하는 실천적 기법이다.

대표 사례

미국 워싱턴 주 재퍼슨 기념관 사례는 5why의 매우 훌륭한 사례이며, 어떻게 5why 를 통해 문제 해결을 하는지에 대한 모범 사례라고 할 수 있다.

  • 문제: 돌로 된 재퍼슨 기념관의 벽이 어느날 심하게 부식되어 있다는 것을 인지하고, 유지보수가 불가피 하게 되었음
    • 방문객들은 기념관의 관리가 부실하여 이런 문제가 발생한 것이라고 불평함
    • 기념관의 이미지가 저하됨
    • 보수 비용이 증가하였으며, 보수 담당자들은 청결 유지를 위해 많은 시간이 소요되고 있었음
    • 비둘기 똥을 제거하기 위해서 독성이 강한 세제를 사용하여 부식을 가속화
  • 표면적 해결책:
    • 비둘기가 날아들지 않도록 캠페인 (비둘기에게 먹이를 주지 마세요) 수행
    • 효과가 없이 여전히 비둘기 똥으로 인한 이슈 발생
  • 5Why의 도입
    • 문제 정의: 기념관의 대리석 벽이 심하게 부식되고 있다.
    • Why 1: 왜 기념관의 대리석이 부식되고 있는가?
      • A: 대리석을 독성이 강한 세제를 사용하여 자주 닦아서 그렇다.
    • Why 2: 왜 세제로 대리석을 자주 닦는가?
      • A: 기념관에 비둘기가 많이 찾아오며, 배설물들이 많이 떨어지기 때문이다.
    • Why 3: 왜 비둘기가 많은가?
      • A: 주변에 비둘기가 좋아하는 거미들이 많이 서식하고 있다.
    • Why 4: 왜 거미들이 많은가?
      • A: 전등을 일찍 켜서 거미들의 먹이인 나방이 많이 날아들기 때문이다.
    • Why 5: 왜 전등을 일찍 켜는가?
      • A: 직원들이 일찍 퇴근하며 퇴근하면서 전등을 바로 켜기 때문이다.
  • 해결책:
    • 전등 켜는 시간을 2시간으로 미루도록 직원들이 퇴근 시간을 조정하여 문제가 해결되었음

위 문제는 재퍼슨 기념관의 부식의 근본 원인을 Deep Dive 하면서 피상적인 수준에서 문제의 근본 원인을 파악하여, 문제 발생 원인을 제거하거나 완화하는 방법을 채택하였고, 이로 인해 발생한 이슈를 해결할 수 있었다는 것을 보여준다.

우리의 뇌는 어떻게(HOW)에 대한 질문을 하면 과부하가 걸리며, 굳어진다고 한다. 반면 Why 에 대한 질문을 하게 되면 뇌는 스스로 답을 끌어내게 된다. 결과에 대한 원인을 분석하여 인과관계를 분명히 밝히기 위한 조작 과정이 발현된다고 한다.

장점

  • 방법이 단순하다
    • 가끔 5why 가 아니라. (3번째 물음에서 답이 나오거나, 6 ~ 7번 까지 물음을 해야 답이 나올수도 있다.)
  • 문제의 근본 원인을 정의하는데 도움을 준다.
  • 문제의 다른 원인들에 대한 관계 역시 정의가 가능하다.

단점

  • 올바른 질문을 해야한다.
    • 현실적이고, 통제 가능한 질문이어야한다. (왜 나는 키가 작은가?) –> 어떠한 답이 나올 수 있는가?
  • 복수개의 원인이 있는 문제인경우 5why 로는 해결이 쉽지 않다.
  • 대답시 근거가 있고, 검증이 가능한 사실만으로 대답을 해야한다.

정리

지금까지 문제를 정의하고 근본 원인이 무엇인지에 대해 깊이있게 분석하는 방법을 알아 보았다.

5why는 매우 간단하면서도, 강력한 원인 분석 기법이며, 누구나 사용할 수 있는 쉬운 기법이다.

문제를 잘 정리해야 올바른 답변이 나온다는 것을 이해 해야하며, Postmortem 을 통해 문제를 분석하고 해결해 나가는 과정에서 매우 중요한 과정이라고 할 수 있을 것이다.

근본 원인을 확인했다면, 이제는 문제가 재발하지 않을 수 있는 방법에 대해서 알아보자.

Poka yoke (실수 피하기)

정의

포카요케는 일본어로 토요타의 시게오신고에 의해서 처음 고안된 것으로 ‘실수를 피하다’ 라는 의미이다. 처음에는 “빠가요케” 로 바보 방지였으나, 용어가 순화되어 포카요케 로 변경되었다.

이는 품질 관리 측면에서 실수를 방지하도록 행동을 제한하거나, 정확한 동작을 수행하게끔 강제하는 여러가지 제약조건을 두어 실패를 방지하는 방법을 말한다.

이를테면 자동차 기어가 P에 있어야 시동이 걸리도록 해서 급발진이나, 안전 문제가 발생하지 않도록 제한하는 방법이 그 예라고 할 수 있다.

장점

  • 사람들을 돕고, 프로세스가 올바르게 진행될 수 있도록 하는데 가치를 둔다.
  • 실수가 일어나지 않도록 미연에 방지하는 역할을 한다.
  • 제품의 퀄리티를 극적으로 향상 시키고, 신뢰성 및 결함을 제거하는 역할을 한다.
  • 비용이 거의 들지 않는다.
  • 교육 시간을 절감한다.
  • 지속적인 개선을 기반으로 접근하는 방법이다.
  • 안전을 지키도록 해준다.
    • 실수하지 않도록 안정된 상태에서 작업이 진행되도록 한다.
    • 공정에서는 작업자의 안전을 지켜준다.
  • 비용을 절감한다.
    • 문제가 있는 제품을 덜 생산함으로써 낭비를 줄인다.
    • 재 작업을 위한 시간을 줄인다.
    • 고쳐야할 결함을 차단하여 시간, 비용을 세이브 한다.

적용절차.

  1. 오퍼레이션이나, 작업 플로우를 획득하고, 문제가 발생할 위치를 찾아본다.
  2. 문제 원인을 분석한다. (5why등 이용)
  3. 올바른 포카요케 방법을 채택한다.
    1. 에러를 만들지 않는 방법
    2. 에러가 만들어지면 알람을 주는 방법
  4. 실수에 집착하지 않고, 보상적 방법의 접근법을 취한다.
  5. 감지를 위한 다양한 측정지표를 찾는다. 혹은 체크 리스트
  6. 방법을 테스트하고, 동작을 확인한다.
  7. 훈련하고, 수행을 평가하여, 성공을 측정한다.

적용사례

  1. 자동차 기어를 P에 두어야 시동이 걸리게 하기
    1. 자동차가 의도치 않게 움직이는 것을 방지한다.
    2. 자동차 시동을 걸기전에 파킹에 두어야 시동이 걸리게 제약을 만든다.
    3. 이후 운전자에게 반복적인 습관으로 내제화 하도록 만든다.
  2. 시스템 배포
    1. 시스템 배포시 첫번째 배포가 이루어 지고, 서비스 체크 (liveness, readiness)가 완료 되어야 다음 배포 진행
    2. 카나리 배포후 시스템 메트릭 분석후 특정 임계값이 넘어야 나머지 배포할 수 있도록 배포 버튼이 노출
  3. 소스 리뷰
    1. N명의 개발자의 리뷰 결과가 올라오거나, 리뷰 회의를 통해서만 배포 되도록 강제하는것

위 예제들과 같이 포카요케는 작업 공정 과정에서 발생하는 문제 발생 가능성에 제약 조건을 걸어 올바른 절차로 수행될 수 있도록 조정하는 것이다.

잘못된 poka-yoke 피하기

  • 포카요케는 단순하게 에러를 방지하고, 실수를 방지하는 모든 방법을 말한다.
  • 누군가의 실수, 잘못을 찾아내려 하지마라. (오류와 실패라는 것에 집중하고, 타인의 문제는 생각하지 마라, 자신의 문제에 집중하라.)
  • 다른 회사나 조직의 케이스 대신에 자신의 조직이 집중하고 달성하고자 하는 것이 무엇인지에 집중한다.

KPTA 검토 방법

이제 문제를 예방하기 위한 대책도 마련 되었다. 그 다음은 문제 가장 효과적인 방안을 실천할 수 있도록 의사결정을 하는 과정이 남아있다.

이런 방안을 선택하고, 실천하는 효과적인 방법에 대해서 알아보자.

정의

KPTA 는 Agile 방법론에서 회고시 주로 사용하는 방법이며, OKR 실천편 (아마노 마사루-한국경제신문) 이라는 책에도 매우 잘 소개 되어 있는 방법이다.

  • Keep: 유지해야하는것, 좋은것 계속하면 도움이 되는 사항들
  • Problem: 문제사항, 이슈
  • Try: 시도 해볼만한 대안들, 방법, 도구 등등.
  • Action: 실제 시도할 액션 아이템 및 실천 평가

KPTA 는 위 내용과 같이 어떠한 일을 수행함에 있어서 계속 유지하거나, 문제점이라는 것을 인식하고, 대응방안을 마련하며, 의사결정을 통해 실천사항등을 도출하여 이후 이러한 실천 사항을 평가하는 과정을 거친다.

지금까지 Postmortem 을 통해서 내용을 이해 했다면 Postmortem 의 과정을 통해 다양한 도구들을 이용하고, 실제 실천사항을 만들고, 이들을 평가하는 과정이 있음을 알 수 있다.

Keep

Postmortem 에서 문제가 발생했고, 문제를 해결하기 까지 과정을 분석하면서 우리는 이미 잘 수행하고 있는 몇가지를 추릴 수 있을 것이다.

예를 들면

  • 문제 인지가 매우 빠르게 진행되었다면 문제 인지를 빠르게 수행할 수 있도록 해온 모니터링-alarm 시스템을 더 강화하고, 타 조직에 전파를 하거나, 시스템 구축을 할 수 있도록 계속 유지해야한다.
  • 문제를 정의할때 이것이 문제라는 것을 여러 로그와 시간을 통해 쉽게 찾아 냈다면 그것도 역시 Keep 의 항목이 된다.
  • 또한 조직의 보고 체계라든지, Postmortem 회의 소집이라든지 과정이 우수하다면 우리는 유지하고 강화하는 방향이 필요하다.

Ploblem

문제를 해결하려면 우선 그 문제가 무엇인지 정의부터 해야한다. 정의된 문제들을 모두가 알 수 있도록 기술하고 공유해야할 필요가 있다.

예를 들면

  • 장애 발생시 장애 인지가 매우 느렸다면 이것 역시 문제이다.
  • 실제 장애 상황 그 자체 역시 문제이다.
  • 동일한 일이 다시 발생 되었다면 그것 역시 문제가 될 것이다.

그러나 무엇보다 중요한 것은 현재 발생한 장애의 정확한 문제에 우선 촛점을 맞추는 작업이 필요하다.

Try

문제가 정의 되었다면, 문제가 발생되지 않는 다양한 아이디어를 수집하는 과정이 필요하다. 누군가를 비난하지 않고, 제품의 퀄리티와 발전적인 조직 문화를 위해서 해야할 다양하게 시도해 볼 만한 것들을 나열한다.

이전에 소개한 포카요케는 try에 들어갈 내용을 집중적으로 고민하는 과정이 될 것이다.

그리고 Keep 에 나열된 내역 역시 try 의 사항이 될 수 있다. 계속해서 유지해야하거나, 혹은 더 강화 시켜봐야할 아이템들이 여기에 속하게 된다.

예를 들면

  • 시스템 배포시에 메트릭 분석 시스템을 넣고, 특정 임계치를 통과한 경우만 배포를 승인하도록 하자.
  • 시스템 메트릭의 튀는 구간이 발생할때 메시지를 전송하게하고, 해당 로그를 쉽게 찾아가게 링크를 달자.
  • AB테스트를 해보자.

등등 다양한 시도 방법들이 있다. 시도 방법은 5why를 통한 근본 원인을 해결하는데 집중된 아이템들이 되어야 할 것이다.

Action

시간은 제한적이다. 모든 대응방안을 다 수행할 수 없을 것이며, 그렇게 하는것은 불가능하다. 우리는 선택과 집중이 필요하며, 이때 의사결정을 통해 Action Item 을 선택하는 것이다.

어려 Try 사항중에 지금 가장 필요한 순서대로 목록화를 한다. 그리고 의사 결정을 통해서 해당 액션 아이템들이 반영될 일정을 산정하고, 성공적으로 반영되는 지표를 정의한다.

익션 아이템이 선정이 되면, 이후 개발, 반영 과정을 통해서 결과를 리뷰하는 시간을 갖는다. 리뷰 결과 지난번 대비 얼마나 향상 되었는지, 적용이후에 동일한 이슈가 발생되지 않거나, 횟수가 줄었다는 등의 지표를 리뷰하는 것이 필요하다.

공표

지금까지 Postmortem 의 과정, 도구들에 대해서 살펴 보았다.

어려 관계자들이 모여서 함께 검토하고, 새로운 액션아이템을 만들어 내고, 제품을 더 향상시키는 일련의 정신활동을 해온 것이다.

문제에서 단순히 누구를 탓하고 책임을 면하는 것이 아니라, 우리 내부에서 문제를 분석하고, 우리 모두의 일이라는 것을 이해하고, 모두의 목표인 제품, 서비스, 문화 등의 개선을 위한 아이템들까지 찾아 졌다면, 이제는 모든 사람에게 공표하는 것이다.

이를 통해 다음과 같은 긍정적인 효과를 기대할 수 있다.

  • 개인의 문제가 아닌 모든 사람의 문제로 인식한다.
  • 제품의 문제부터 해결과정을 공유하면서 문화로 자리 잡게 된다.
  • 동일한 실수를 반복하는 횟수를 전사적으로 줄여주며, 우수 케이스들을 차용할 수 있는 환경을 만든다.
  • 제품의 퀄리티 역시 향상된다.
  • 액션 아이템을 반영한이후 평가 결과 역시 공유하여, 대안의 효과를 공유할 수 있으며, 전사에 도입역시 가능하다.

이처름 공표는 자신의 치부를 드러내는 것을 넘어, 모든 구성원의 모델로서 동작하게 된다.

실수로 부터 배움이 자산이 되도록

실수로 인해서 혹은 알수 없는 장애로 인해서 손실을 입는 현상은 언제 어디서나 발생할 수 있다.

그러나 이런 상황을 단순히 미봉책으로 넘기게 되면, 늘 똑같은 실수로 인해서 힘들어 질 수 있다.

중요한 것은 문제로 부터 배움과 발전이 되는 과정으로 이어지는 것이다. 이렇게 하기 위해서는 문제를 깊이있게 분석하고, 근본 원인을 찾아서, 문제를 제거하거나, 발생하지 않도록 다양한 아이디어를 도출하고, 선택과 집중으로 실제 실천함으로써, 경쟁력을 높여 가는 것이 Postmortem의 가치라고 하겠다.

또한 이런 일련의 과정이 실수를 저지른 당사자만의 문제를 넘어서 우리 모두의 문제로 인식하고, 함께 해결해 나가는 것이야 말로 Postmortem 에서 중요하게 생각하는 가치이다.

마지막으로 아인슈타인의 말을 남기고 마무리 하고자 한다.

  • “만약 곧 죽을 상황에 처해있고, 목숨을 구할 방법을 단 한시간 안에 찾아야 한다면, 나는 1시간 중 55분은 올바른 질문을 찾는데 사용하겠다. 올바른 질문을 찾고나면, 정답을 찾는데는 5분도 걸리지 않을 것이다.”

Postmortem 을 왜 하는지에 대한 가장 명확한 이유가 아닐까?

참고자료:

  • 포카요케 6가지 테크닉: https://www.cmc-consultants.com/blog/6-poka-yoke-mistake-proofing-techniques-that-most-factories-overlook
  • What Is the Poka-Yoke Technique?: https://kanbanize.com/lean-management/improvement/what-is-poka-yoke
  • How to Implement Poka-Yoke (Mistake-Proofing) Effectively: https://www.cmc-consultants.com/blog/how-to-implement-poka-yoke-mistake-proofing-effectively

  • The Ultimate Guide to Poka Yoke: https://tulip.co/resources/poka-yoke/

  • postmorterm: https://brunch.co.kr/@svillustrated/13
  • 전문가 기고: 실리콘밸리 기업의 실패 대응법: https://news.kotra.or.kr/user/globalBbs/kotranews/8/globalBbsDataView.do?setIdx=246&dataIdx=163218
  • 에어비엔비 사례: https://news.sbs.co.kr/news/endPage.do?news_id=N1005164080

  • 커밋실수사례: https://medium.com/kimjimin-company/%ED%8F%AC%EC%8A%A4%ED%8A%B8%EB%AA%A8%ED%85%9C-1-%EC%BB%A4%EB%B0%8B-%EC%8B%A4%EC%88%98%EB%A1%9C-%EC%9D%B8%ED%95%9C-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%9E%A5%EC%95%A0-f60e778680a6

  • 5why: https://m.blog.naver.com/toto_0093/220796522798
  • 5why: https://m.blog.naver.com/jiwoo6941/220246908212
  • 5why 기법: https://thod.tistory.com/entry/5why-design-research-techniques
  • 브런치 5why: https://brunch.co.kr/@hfeel/19
  • 도요타 5why: https://ibetfuture.tistory.com/96
  • [자본시장 속으로] 기업의 양성평등과 5Why: https://www.etoday.co.kr/news/view/1944050
  • how to use 5why: https://www.mindtools.com/pages/article/newTMC_5W.htm
  • DETERMINE THE ROOT CAUSE: 5 WHYS : https://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/
  • The 5 Whys Process We Use to Understand the Root of Any Problem: https://buffer.com/resources/5-whys-process/
  • How to conduct a 5 why: https://blog.thinkreliability.com/how-to-conduct-a-5-why
  • What is the 5 Whys Analysis?: https://blog.infraspeak.com/5-whys-analysis/
  • 5-Why Examples [The Best and The Worst!] : https://www.taproot.com/best-5-why-examples/

Table of Contents