급한 불 끄기 바쁜 프로덕트의 문제점

본문은 요즘 IT와 번역가 Yuna가 함께 미겔 카루에고(Miguel Carruego)의 글 <Symptoms of a broken product culture — Part 1>을 번역한 글입니다. 필자인 미겔 카루에고는 바르셀로나를 기반으로 활동하며, 비즈니스 목표와 사용자 요구를 연결하는 데 탁월한 전문성을 가진 COO입니다. 이 글은 잘못된 프로덕트 문화의 증상을 다루는 1부로, 조직이 흔히 겪을 수 있는 주요 문제들을 살펴봅니다. 이어지는 2부에서는 이러한 문제를 해결하기 위한 실질적인 전략을 소개합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

잘못된 프로덕트 문화의 증상 1부

제가 잘못된 관리 결정을 할 때마다 1센트를 받았다면, 지금쯤 부자가 되어 이런 글을 쓰고 있지 않았을 겁니다. 농담은 이쯤 하고, 짧지만 나름 유능했던 제 제품 리더십 경험에서 얻은 교훈 중 하나는 위험 신호들이에요. 당시에는 보지 못했지만, 지금 돌아보니 분명히 보이죠. 이 글은 빈센트 첸의 “규모에 맞는 제품 변화”라는 글에서 영감을 받아 작성했는데요. 이 글이 제게 큰 깨달음을 주었고 생각을 정리하는 데도 많은 도움이 됐습니다. 다룰 주제가 많아서 이번 글에서는 문제를 중심으로 이야기하고, 다음 편에서는 이 문제를 해결하기 위한 전략을 이야기하려고 합니다.

급한 불 끄기

모든 회사에는 사람들이 처리할 수 있는 시간보다 더 많은 문제가 존재합니다. 작은 문제를 간과할 수 있는 환경에서는 최선의 결과가 나올 수 있습니다. 하지만 최악의 경우, 계속해서 긴급한 문제에만 대처하느라 운영에 필요한 자원이 고갈되고 맙니다. 매니저와 엔지니어들은 하나의 과제를 끝내지도 못한 채 다음 문제로 뛰어들게 되죠. 

문제를 해결하려는 시도는 결국 무의미한 임시방편으로 끝나버리고, 팀의 생산성은 급격히 떨어집니다. 업무 관리는 지금 당장 해결해야 할 문제를 고르는 끝없는 저글링 게임으로 변하고, 과로에 지친 직원들을 어디에 배치할지 결정하는 것 또한 큰 숙제가 됩니다.

아르헨티나에서는 이를 ‘캐러멜 잼(dulce de leche) 속에서 노를 젓는 것’이라고 표현한다고 하더군요. 만약 이 상황이 익숙하게 들리신다면, 여러분의 조직도 급한 불을 끄고 있을 가능성이 큽니다. 다음과 같은 증상을 경험해 보셨을지도 모릅니다.

• 모든 문제를 해결할 시간이 부족합니다. 해결해야 할 문제가 이를 제대로 다룰 수 있는 문제 해결사(엔지니어, 매니저, 또는 지식 노동자)의 수를 초과했죠.
• 해결책이 불완전합니다. 많은 문제가 임시로 해결될 뿐 근본적으로 해결되지는 못했습니다. 겉으로 드러나는 현상은 처리했지만 근본 원인은 고쳐지지 않았습니다.
• 문제가 재발하거나 확산됩니다. 불완전한 해결책 때문에 기존의 문제가 다시 나타나거나, 조직의 다른 곳에서 새로운 문제가 생기곤 했죠.
• 중요성보다 긴급성이 우선됩니다. 진행 중인 문제 해결 노력과 장기적인 활동(예: 새로운 프로세스 개발)이 반복적으로 중단되거나 연기됩니다. 눈앞의 문제부터 대처하는 데만 집중할 수밖에 없기 때문입니다.
• 많은 문제가 위기로 발전합니다. 문제들이 쌓이다가 마감 직전에 폭발하곤 했습니다. 그 결과, 문제를 해결하기 위해 영웅적인 노력이 필요해졌죠.
• 성과가 저하됩니다. 제대로 해결되지 않은 문제들이 쌓이고, 잃어버린 기회들이 많아지면서 조직 전체의 성과가 급격히 떨어졌습니다.

이런 상황에서 가장 큰 문제는 긴급 대처 과정에서 엔지니어들이 효율적인 해결책을 찾기보다, 빠르고 조잡한 해결책을 내놓을 수밖에 없다는 점입니다. 문제의 근본 원인을 파악할 시간이 부족해 직관적으로 진단한 뒤, 이를 검증하기도 전에 즉흥적으로 코드를 변경하곤 했습니다. 짧은 수정으로 문제가 완전히 해결되지 않았을 경우(대개 해결 여부도 모호합니다), 그 변경 사항을 그대로 둔 채 다른 접근 방식을 시도했죠. 이렇게 체계적으로 문제를 다루지 못하면서 결국 문제 해결에 실패하는 상황으로 이어졌습니다. 임시방편은 체계적인 문제 해결보다 시간이 더 오래 걸렸을 뿐만 아니라, 문제의 근본 원인을 해결하지도 못했습니다.

결국 임시방편은 독이 됩니다. 임시로 처리한 문제는 새로운 문제를 만들어내고, 해결하지 못한 기존 문제들까지 계속 재발하게 되죠. 들어오는 문제 중 상당수가 되살아난 오래된 문제들로 채워지게 됩니다. 엔지니어의 작업 환경은 점점 혼란스러워지고, 실험을 진행하거나 문제를 명확히 규명하기도 점점 어려워집니다. 심지어 조직의 문제 해결 능력이 완전히 붕괴되어 전반적인 성과가 크게 하락하기도 합니다.

IT 중심 사고 vs 제품 중심 사고

마티 케이건이 설명했듯이, IT 중심 사고를 가진 기업은 사용자 중심 제품 기술을 내부 IT 기술처럼 관리하려고 합니다. 하지만 이러한 접근은 나쁜 고객 경험을 초래할 뿐만 아니라, 조직에도 어려움을 가져옵니다.

그렇다면 왜 사용자 중심 제품은 IT 제품과 다를까요? 여러 이유가 있습니다. IT 제품은 직원들이 회사의 지시에 따라 사용해야 하는 도구입니다. 반면, 사용자 제품은 모든 사용자가 스스로 구매 결정을 내립니다. 사용자가 원하지 않으면 사용하지 않습니다. 또한 IT 제품은 기업이 교육 과정, 매뉴얼 숙지, 전문 서비스 등을 요구할 수 있지만, 사용자 중심 제품은 사용자가 즉각적으로 이해하고 사용할 수 있어야 합니다. 그렇지 않으면 단 한 번의 클릭으로 경쟁사로 넘어갈 수 있습니다.

IT 제품은 사용자 규모와 동시 접속자 수를 수백 명 단위로 측정합니다. 반면, 사용자 중심 제품은 수십만, 때로는 수백만 명을 대상으로 합니다. 또한 IT 제품에서 문제가 발생하면 이를 해결해야 하는 대상은 직원들입니다. 하지만 사용자 제품에서 서비스 중단과 같은 문제가 발생할 경우, 이는 곧 매출에 영향을 미치고 바로 CEO의 주목을 받는 심각한 사안으로 이어집니다.

사실 대부분의 사용자 중심 제품은 IT 제품보다 정의, 설계, 구현, 테스트, 배포, 지원 측면에서 훨씬 더 높은 기준을 요구합니다. 이는 보통 연봉 수준에도 반영됩니다. 필요한 제품 경험을 가진 사람을 찾는 것은 IT 경험을 가진 사람을 찾는 것보다 훨씬 더 어렵습니다.

두 사고방식의 차이는 다음과 같이 요약할 수 있습니다.

IT 중심 사고

제품 중심 사고

느린 결과 도출

정확히 애자일 용어로 말하자면, 스크럼 방식을 사용하는 팀에서 속도란 스크럼 팀이 스프린트 동안 제품 백로그의 작업 항목을 완료하여 고객에게 전달할 수 있는 형태로 만든 평균 작업량을 나타냅니다. 이는 보통 번다운 차트로 측정됩니다. 속도와 관련된 문제 중 하나는 작업량과 계획 정확성을 혼동할 수 있다는 점입니다. 

예를 들어, 팀이 작업을 보수적으로 추정하면 속도가 부풀려질 가능성이 있습니다. 어떤 팀이 실제로 두 시간이 걸리는 작업을 네 시간이 걸릴 것이라고 추정하거나, 해당 작업의 점수를 2점 대신 4점으로 설정한다면, 이 팀의 속도는 더 높아 보일 것입니다(이를 종종 점수 부풀리기라고 부릅니다). 이러한 이유로 좋은 속도나 나쁜 속도는 본질적으로 존재하지 않습니다.

결국 결과가 아닌 산출물의 속도에만 초점을 맞추는 문제는 고객 입장에서 아무런 의미가 없습니다. 아무리 뛰어난 지속적 통합/지속적 배포(CI/CD) 프로세스를 갖추고 있더라도, 고객이 제품에서 얻는 가치를 직접적으로 향상시키지 않는다면 이는 무의미합니다.

결과를 만들어내기 위해서는 상황에 따라 기존 방식을 개선하는 혁신과 근본적인 변화를 이끄는 혁신이 모두 필요합니다. 하지만 모든 조직이 빠르게 근본적인 변화를 요구하는 혁신에 대응할 준비가 되어 있는 것은 아닙니다.

혼돈의 일정

잘못된 프로덕트 문화의 또 다른 명확한 증상은 계속해서 일정이 바뀌는 상황입니다. 만약 환경이 변할 때마다 우선순위와 일정이 함께 흔들린다고 느낀다면, 이제는 제품 비전을 점검해야 할 때입니다.

이 문제의 근본 원인은 보통 두 가지 중 하나입니다. 첫째, 명확하고 견고한 제품 비전이 없거나, 둘째, 제품 비전이 너무 약해 비즈니스 환경을 견디지 못하는 경우입니다. 비전의 부재는 단순히 일정의 혼란을 초래할 뿐만 아니라, 팀 구조 정의, 비즈니스 도메인 설정, 우선순위 조정, OKR(목표 및 주요 결과) 설정 등 여러 가지 문제를 유발합니다.

제품 비전을 점검하려면 다음 체크리스트를 확인해 보세요.

• 고객 중심적인가?
• 도전적이지만 비현실적이지 않은가?
• 경쟁사와 차별화되는가?
• 미래를 내다보고 있는가?

하지만 비전 부족만이 모든 문제의 원인은 아닙니다. 일정이 계속해서 바뀌는 상황은 비효율적인 프로세스, 불명확한 의사결정 체계, 또는 조직 문화의 문제에서도 비롯될 수 있습니다. 따라서 문제를 해결하려면 제품 비전뿐만 아니라 조직의 프로세스와 문화를 함께 점검해야 합니다.

무너진 신뢰

앞서 언급된 모든 문제의 결과로 인해 프로덕트 조직이 신뢰를 잃고 있습니다. 이해관계자들은 프로세스, 제품 관리자, 제품 디자이너, 그리고 그 외의 모든 요소를 진행을 방해하는 장애물로 간주합니다. 소프트웨어 개발 조직은 실질적인 가치를 제공하지 못한다는 부정적인 평판을 얻게 됩니다.그리고 여러분도 잘 아시다시피, 신뢰는 회사의 효율성을 높이는 데 중요한 역할을 합니다. 서로 간에 개방적이고 솔직한 소통이 가능해지려면, 어느 정도의 신뢰가 전제되어야 합니다. 직원들 간의 비효율적인 소통은 워크플로우를 느리게 하고, 생산성을 저하시킬 뿐만 아니라 비용을 증가시킬 수 있습니다.

이러한 상황이 발생하고 있음을 나타내는 대표적인 위험 신호 중 하나는 이해관계자들이 제품 관리자나 기존의 변경 요청 프로세스를 완전히 건너뛰고, 직접 엔지니어들과 소통하여 작업을 제품에 반영하려고 시도하는 경우입니다.

결론

아직 프로덕트 문화가 정확히 무엇인지 명확히 정의하지 못했습니다. 프로덕트 문화는 단발성 팀 빌딩 활동의 연속도 아니고, 모든 상황에 적용할 수 있는 “제품 방식”의 정답 가이드도 아닙니다. 이는 누군가가 처방해줄 수 있는 것이 아니라, 발견해야 하는 것입니다. 무엇보다 중요한 점은, 프로덕트 문화는 우리 모두가 함께 만들어갈 수 있다는 사실입니다. 제가 지금 프로덕트 문화가 무엇인지 확실히 말할 수는 없지만, 적어도 무엇이 프로덕트 문화가 아닌지는 설명했습니다.

따라서 만약 여러분의 조직에서 아래와 같은 신호를 발견한다면,

• 급한 불 끄기식 문제 해결
• IT 중심 사고
• 느린 결과 도출
• 혼돈의 일정
• 무너진 신뢰

이제는 행동에 나설 때일지도 모릅니다. 다음 편에서는 이러한 문제에 맞서 싸울 수 있는 전략과 전술에 대해 더 깊이 이야기해 보겠습니다.

<참고>

• Stop Fighting Fires by Roger Bohn — Harvard Business Review
• Moving from an IT to a Product Organization by Marty Cagan — SVPG
• How Google Works. By Eric Schmidt & Jonathan Rosenberg
• Transforming Product Culture at Scale by Vincent Chan
• How to write and communicate an effective product vision by Product Board

<원문>

Symptoms of a broken product culture — Part 1

©️위 번역글의 원 저작권은 Miguel Carruego에게 있으며, 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다