Poka-yoke

포카요케(Poka-yoke)는 일본어이며, 실수를 방지하는 것을 말한다. 특정 조각을 같은 모양의 구멍에 맞추어 통과 시키는 장난감을보면 개념을 쉽게 이해할 수 있다. 별 모양의 조각을 선택하고 네모나 세모 모양의 구멍에 끼우면 통과를 못하게되고 자연스럽게 실수를 막을 수 있게된다. 모양 맞추기 게임의 핵심은 같은 모양을 찾아서 맞추는 것이겠지만, 다른 관점에서 해석해 보면 중요한 통찰을 얻을 수 있다. 다른 모양의 조각은 원천적으로 통과하지 못하도록 설계했다는 것이다. 다음은 위키피디아에 있는 포카요케관련 설명이며, 실수를 사전에 방지한다는 의미를 갖고 있다.

Poka-yoke  (ポカヨケ, [poka joke]) is a Japanese term that means "mistake-proofing" or "inadvertent error prevention". A poka-yoke is any mechanism in a process that helps an equipment operator avoid (yokeru) mistakes (poka) and defects by preventing, correcting, or drawing attention to human errors as they occur. The concept was formalized, and the term adopted, by Shigeo Shingo as part of the Toyota Production System.^[각주:1]

 

Poka-yoke (https://www.poka.io/en/blog/expanding-the-meaning-of-poka-yoke-in-lean-manufacturing)

이 단어를 처음 들었던 곳은 지속적 전달(Continuous Delivery) 저자인 Jez Humble의 워크샵^{[각주:2] [각주:3]}이었다. 지속적 전달의 개념과 파이프라인, 검증 자동화, 버전 관리, 인프라스트럭처 관리, 안전한 배포방법, 모니터링^[각주:4]에 대한 이야기를 하다가 워크샵이 거의 끝날 때 쯤, 강사였던 Jez는 ATM기기에서 카드 리더기 방향이 한쪽으로만 가능하도록 설계된 그림을 보여주었다. 그림을 설명하면서 소프트웨어 엔지니어링에도 비슷한 설계가 필요하다고 강조했다. 소프트웨어를 개발하고 운영하는 과정에서 신뢰성을 극도로 높히기 위해서는 사람의 실수로 의한 문제들이 발생하지 않도록 방지하는 시스템이 중요하다는 이야기를 하였다. 그러면서 포카요케라는 용어를 설명했다.

소프트웨어 개발 팀은 안정적인 서비스 운영을 위해서 안전장치를 늘 고민해야 한다. 문제가 생겼을 때 더 똑똑하지 못함을 탓하거나 미리 작업을 전파하지 않음^[각주:5]을 따지기보다, 1/ 예상 가능한 문제는 미리 고민해서 사전 테스트를 통해 검증하도록 해야 하며, 2/ 예상하지 못했던 문제는 포스트모텀(사후 부검, Post-mortem)이나 오류 분석(CoE)을 통해 원인을 찾고 재발 방지 방안을 마련해야 한다. 플랫폼이나 시스템 자체를 개선해서 애초에 실수가 일어나지 않도록 만드는 작업이 진짜 제대로된 재발 방지 대책인 것이다. 다시 말해서 포스트모텀에서 분석한 결과는 백로그(Backlog)에 넣어서 시스템 설계에 반영해야 하며, 당장 백로그에 넣기 어렵다면 런북(Runbook)에 추가해서 운영 할 때 주의할 수 있도록 만들어야 한다. 런북에 추가하는 것인 임시방편이어야 하며, 최종적으로는 런북의 내용들도 지속적으로 백로그에 넣어 플랫폼 개선 계획에 반영해야 한다.^[각주:6] 사용자 실수를 방지하기 위해서 위험 요소를 미리 제거하고 사용자 개입을 원칙적으로 최소화 하는 것은 가장 좋은 재발 방지 방법이다.

---

 

1. Poka-yoke - Wikipedia [본문으로]
2. 90-Minuite Coffee Break (90분의 커피 브레이크) [본문으로]
3. Pilot Light [본문으로]
4. 강의 시간이 부족해서 모니터링 부분은 짧게 언급하고 넘겼다 [본문으로]
5. 슬랙이나 메신저에 작업을 미리 알리지 않는 것을 소통 부족으로 생각하는 경우를 종종 봤다. 그러나 그건 소통 부족도 아닐뿐더러 좋은 엔지니어링 습관이 아니다. 모두가 각자의 책임아래 다른 서비스에 대한 의존없이 오류 예산(Error Budgets) 범위 안에서 자율적으로 배포하고 롤백하는 것이 진짜 제대로된 마이크로서비스이며 클라우드 네이티브이기 때문이다. 서비스간 영향때문에 혹은 혹시 모를 고객 영향이 생길까 걱정이 되서 공지를 해야한다고 강조하는 것은 위험 요소를 미리 고민한 경력 많은 리더십으로 보일 수 있겠지만, 안전 장치를 미리 구성하고 장애를 격리하는 높은 수준의 아키텍처를 구현하는데 오히려 걸림돌이 될 수있다. [본문으로]
6. Runbook [본문으로]