IT회사에서 케케묵은 도요타 생산방식이라니요?

TPS, Andon, 돌고 돌아 본질로

이번 주, 나는 도요타 생산방식(TPS)의 본질을 절실히 깨달았다. IT 회사의 Product Owner에게 TPS라니. 거의 100년 된 방식 아닌가. 빠르게 달리는 IT 프로덕트에 무슨 소용이 있겠어? 라고 생각했다면 당신도 지난 주까지의 나와 같다. 나도 상관없다고 생각했다. 그런데 아주 큰 상관이 있다는 것을 배웠다.

이번 주 한 도메인에서 데이터 생성 전략을 바꾸면서 이슈가 발생했다. 특정 기간 동안 리프레시된 데이터가 줄어든 것이다. 원래는 두 달에 한 번 데이터를 몰아서 보내는 방식이었는데, 용량과 비용 문제, 리스크를 줄이기 위해 daily cap을 두고 데이터를 평탄하게 분배했다. 내부적으로는 좋은 변화였고 장기적으로도 이득이다. 그러나 다운스트림에는 단기적으로 부정적인 영향이 있었다. 이 데이터를 받는 팀은 과거 60일까지만 백필윈도우를 열어두기 때문에 리프레시가 지연되면 업데이트를 받지 못한다. 이를 알고 있던 나에게 이는 충분히 예측가능한 이슈였고 심지어 도메인 내부에는 메트릭 저하를 한동안 감안해달라고 공유까지 했다. 그럼에도 나는 다운스트림에 이를 알리는 것을 깜빡했다. 아니 실은 크게 중요하게 생각하지 못했다고 고백하는 것이 맞을 것이다.

당시 모두가 새로운 메트릭에 집중하느라 이미 과거의 것이 되어버린 이 메트릭의 중요성을 간과했다. 하지만 사람들이 과거의 메트릭에 관심이 없는 이유는 그것이 잘 돌아가고 있기 때문이다. 삐끗하는 순간, 모두가 관심을 갖는다. 결국 내 책임은 상황과 관계없이 모든 종류의 메트릭을 정상 범위 안에 유지하는 것이다. 벗어나는 일이 생기면 무조건 공유해야 한다. 공유하면 모두의 책임이지만, 공유하지 않으면 오로지 나의 책임이다. 더 중요한 것은, 공유해야만 문제를 예방할 수 있다는 점이다. 좋은 의도로 전략을 바꾸었어도 예상되는 메트릭의 Andon을 충분히 공유하지 않았던 것이 나의 패착이었다.

며칠 후 매니저와의 1:1에서 다른 주제를 얘기하던 중 우연히 그는 이렇게 말했다. “이 도메인은 계속 네가 봐야 하고 시간을 덜 쓸 방법을 찾아야 한다. 자동화하는 것이 Product의 일이기도 하다.” 그 순간 유레카처럼 깨달았다. 바로 Jidoka가 필요한 것이다. 책에서만 봤던 TPS의 개념이 내 현실에 연결됐다. 제조업 이야기라고 치부했던 TPS가 IT에도 그대로 적용된다. 회사는 사람을 쉽게 늘려주지 않는다. 새로운 일을 하려면 기존 일을 자동화해야 한다. 이를 위해 DA 리소스를 적극 활용하고, Feedback loop와 Andon 모니터링을 강화해야 한다. 그 순간 모든 퍼즐이 맞춰졌다. 이번 이슈를 곰곰이 생각해 보며 나는 메트릭을 달성하는 방식은 비교적 자동화했지만 Andon을 충분히 고려하지 않고, 예상되는 상황을 커뮤니케이션하지 않았다는 것을 깨달았다. TPS의 Jidoka(자동화+사람의 지혜)의 프레임으로 본다면 내가 만든 것은 반쪽짜리 자동화였다.

CEO가 2년 전 PO들에게 TPS에 관한 책을 읽고 퀴즈를 풀라는 지시를 내린 적이 있다. 그때는 ‘이게 IT 프로덕트에 무슨 소용이람?’이라고 생각했지만, 지금은 내 시야가 좁았음을 인정한다. 어떤 프로덕트를 만들든, 어떤 도메인을 Own하든, 성장하려면 현재 메트릭을 자동화하고 다음 단계로 넘어가야 한다. 시스템의 자동화(Jidoka), 자동화 후 모니터링하는 Feedback loop, 그리고 Andon을 설정해 적시에 알림을 가동하는 것. 이 모든 것이 TPS의 기둥이다. - 한편 TPS의 첫번째 기둥인 JIT(Just In Time)는 이미 IT에 깊이 뿌리내렸다. MVP를 런치하고 빠르게 Iterate 하는 것은 필요한 것을 필요한 때에 필요한 만큼만 생산하는 JIT와 일맥상통한다.

공장에서 나온 개념이라고 공정에만 적용될 거라 생각했던 나는 정말 어리숙했다. 특히 Andon은 빼놓을 수 없다. 고백하자면 작년까지는 PRD를 작성할 때 Andon에 큰 공을 들이지 않았다. Problem statement, Root cause, Metric에 대부분의 시간을 쏟았다. 하지만 올해 Retail 쪽을 맡은 VP와 일하기 시작하며 Andon의 중요성을 조금씩 깨달았다. Retail은 운영과 시스템이 유기적으로 돌아야 하는 영역이라 TPS가 가장 유용하게 적용되었다. 점점 프로덕트를 정의할 때 Andon을 함께 고려하고 피드백 알림을 설정했지만, 알림이 실제로 사람들에게 닿을지 확신이 없었다. 나조차 매일 정신없이 바쁜데 이런 알림을 누가 챙길까 싶었다. 다음 프로젝트로 넘어가면 이전 프로젝트는 덜 중요해지기 마련이다.

그러나 이번 같은 이슈가 쌓일수록, 메트릭이 가드레일을 벗어날수록 Andon은 반드시 관리되어야 한다는 것을 깨달았다. Andon을 명확히 지정하고, 기준을 넘으면 지체 없이 알리는 것이 시스템을 안정적으로 운영하는 방법이다. 이제 나는 Andon의 중요성에 완전히 설득당했다. 내 역할은 일을 지속적으로 자동화하고 시스템을 잘 돌아가게 만드는 것이다. 자동화의 목적은 최소한의 노력만 남기고 다음 메트릭으로 넘어가기 위함이다. 과거 여러 파트를 넘나들며 메트릭만을 위해 달리던 때 느꼈던 막연한 불편함도 여기서 비롯됐다. 오너십이 없는 도메인에서는 현재의 메트릭만이 유일한 목표이기 때문에 피드백과 Andon은 크게 집중하지 않고 다음 메트릭으로 달려갔다. 그러나 시스템을 장기적으로 발전시키려면 Jidoka와 Andon이 필수다.

마지막으로 남은 과제는 Andon을 어떻게 효과적으로 커뮤니케이션하느냐이다. 지나친 경고는 불필요한 불안을, 과소한 경고는 위험을 초래한다. 나는 보통 후자, 내 매니저는 전자의 방식으로 소통한다. 두 가지 방식의 반응을 모두 경험하며 느낀 것은, 결국 사람들은 기나 긴 소통 끝에 “그래서 필요한 게 정확히 뭔데?”라는 질문으로 돌아간다는 점이다. 감정적 소모를 줄이고 효율적으로 일하려면, 필요한 것을 숫자로 명확히 정리해 들고 가야 한다. 이것이 커뮤니케이션의 본질이다. 앞으로는 Andon의 피드백 루프를 세팅하는 데 그치지 않고, 실제로 알람이 왔을 때 이를 인지하고 사람들에게 효과적으로 커뮤니케이션하는 것에 힘쓸 것이다. 이만큼 더 성숙하고, E2E로 볼 수 있는 매니저로 성장하기를 기대한다.

추천 책: 더 골 1. 꼭 읽어보기를 추천한다. 고전인데 쉽게 TPS를 실전에 적용할 수 있게 도와준다.

출처 yes24

추천 책 2: High output management. 역시 고전.

출처 yes24