1000번째 배포 회고 : 소프트웨어가 가진 본질적인 특징

저는 바로 이 커리어리를 만든(!) 퍼블리에서 APM(Associate Product Manager)로 1년 반 정도 일했는데요, 퍼블리가 정말 좋은 제품팀 문화를 가지고 있는 회사라는 걸 재직 기간 내내 느꼈습니다. 이 얘기를 서두에 작성한 이유는, 오늘 오전에 휴튼 질문 패키지*의 코드를 수정하여 배포했는데 정말 우연히 이것이 휴튼의 1000번째(!) 배포라는 걸 알게 됐기 때문입니다. 아니 벌써 1000번이나 배포했다고? 하며 제가 퍼블리에서 배운, 소프트웨어 제품이 가진 본질적인 특징에 대해 다시 생각해보게 되었어요. (*https://heuton.kr/question-package) 퍼블리에서 온보딩 기간동안 제품팀이 일하는 방식에 대해 설명을 하며 강조하는 것 중 하나가 우리는 소프트웨어 제품을 만든다는 사실입니다. 여기에 너무 당연하지만 또 너무 중요한 사실이 있는데, 바로 소프트웨어는 극단적으로는 하루에도 수십수백번, 또 매우 빠르게, 그리고 꾸준히 개선/수정을 하며 사실상 무한한 최적화를 할 수 있다는 것입니다. 이것이 하드웨어 제품과의 가장 크게 다른 점이죠. 이 특징 하나 때문에 제품팀이 일하는 방식이 결정됩니다. 이 특징으로 인해 초기에는 제품의 다소 낮은 완성도가 용인되기도 하고, 완성도보다는 속도가 우선시되어 제품을 매우 빠르게 출시할 수 있고, 그 덕분에 사용자의 반응을 빠르게 확인하고 이터레이션을 돌릴 수 있는 것이죠. 사소한 개선을 끊임없이 할 수 있다는 것도 이 특징이 가져오는 장점입니다. 과거에 현대자동차에서 PM(Project Manager)을 하던 친구가 일하는 방식을 본 적이 있는데, 제품(자동차)의 기획/개발부터 출시까지 1년~1년 반 정도가 걸렸던 것 같아요. (몇 년 전 기억이라 정확하지는 않습니다) 아무튼 그 긴 기간동안 모든 부서들이 착착착 맞춰 일해서 마지막에 짠! 하고 멋진 제품을 내놓는 것이죠. 그렇기 때문에 예를 들어 트렁크 문을 이렇게 만들지 저렇게 만들지 결정하는 데만 몇 주를 쏟았다고도 합니다. 소프트웨어는 근본적으로 다릅니다. 우리는 보통 그 기간을 ‘스프린트’라는 이름으로 1~3주 단위로 잘게 쪼개서 채우니까요. 소프트웨어는 트렁크 문을 이렇게도 만들어보고 저렇게도 만들어보고 그렇게도 만들어본 뒤에 셋 다 세상에 내놓아볼 수 있으니까요. 하나로 결정한 뒤에도 고객이 원하는 방향으로 조금씩 (바로바로) 개선할 수 있으니까요. 물론 이것이 마냥 장점이냐고 물으면 꼭 그렇다고 할 수는 없을 것 같습니다. 앞서 말씀드린 것처럼 소프트웨어는 초기의 다소 낮은 완성도가 용인되는데 이것은 제품의 특성에 따라 치명적인 리스크로 작용할 수도 있기 때문입니다. 또 저는 개발자가 아니라 깊이 알지는 못하지만, 이렇게 무지성으로 배포하는 것이 가져오는 단점도 분명 있을 거예요. 아무튼 소프트웨어가 가진 당연하지만 중요한 본질적인 특징을 이해하고 있으면 이 제품을 어떤 프로세스로 발전시키고, 나아가 제품팀, 더 나아가 회사 자체가 어떻게 일하는지까지도 더 깊이 고민해볼 수 있을 것 같습니다.