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]을 나무라지 않아야 한다. 예상 가능한 문제들은 최선을 다해서 사전 테스트를 통해서 문제가 생기지 않도록 해야 하며, 예상하지 못했던 문제가 발생했다면 포스트모텀(사후 부검, 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 [본문으로]