구글이 공유한 머신 러닝의 첫번째 규칙은 “Don’t be afraid to launch a product without machine learning.” 이다. 이를통해 가장 먼저 메트릭을 정의하고, 동작하는 파이프라인을 만들고, 실패하고, 펑가하고, 개선할 수 있기 때문이다.

Stripe의 머신 러닝 엔지니어인 Emmanuel Ameisen 역시 “ML is an iterative process where the fastest way to make progress is to see how a model fails.” 라고 했다.

이 접근은 소프트웨어 개발에도 응용할 수 있다. 개발의 최종 목표는 impact 을 만들어 내는 것인데, 똘똘한 아이디어가 반드시 최종 사용자의 큰 행복 증가와 일치하는건 아니기 때문이다. 티안나게 멍청한 구현이 갈 길을 알려줄 수 있고, 대부분의 경우 그 길은 열띤 토론을 통해 찾아냈던 방향과는 다르다.

이것은 매우 테크니컬한 문제에도 크게 다르지 않다. 메트릭을 찾고, 가장 바보같은 구현으로 어디까지 도달가능한지 보고, 조금씩 만들어가며 정말 그 길로 가는지, 얼마나 도달할지를 보는걸 반복하는 것이 기술적으로 말이 되고 될것만 같아서 곧바로 모든 자원을 투자하는 것보다 낫다. 남들도 바보는 아니라 직관만으로 개선 가능한 과실은 이미 다 따갔다.

조직의 은총을 받은 경우에도 다르지 않다. 리더쉽에서 내린 목표도 실은 구체적인 구현을 콕 찝어 이걸 하기만 한다면 무슨 사단이 나도 괜찮다고 한 것 까지는 아니다. 생각해보면 그들도 산업 환경에 영향을 받아 자원을 집중한 실험을 한 것이고, 결국에는 메트릭을 바란다. 그리고 그 메트릭이 아주 매력적이어야 조직이 잘 살 수 있다.

이렇게 일하는건 어떤면에서는 엔지니어의 본능과 상충된다. 어려운 문제나 좋은 추상화 토의라해도 impact과 연결되어 있지 않다는 증거가 있다면 단호히 가로막아야만 운영이 가능하기 때문이다.

완전히 새로운 일은 추정이 불가능하다. 이 부분은 누구에게나 어려운 점인 것 같다.  어떤 경우는 UX 스터디를 가상의 결과를 손으로 만들어 비교 평가 할 수 있다. 설문 조사를 할 수도 있고, 유사 사례 연구나, 완전히 같지는 않지만 비슷한 데이터로 토이를 만들어 볼 수도 있다.  그러나 완전히 새로운 영역 에서 추정을 아주 잘 하는 경우는 거의 보지 못했다.