급한 불 끄느라 바쁜 조직에서 벗어나는 법

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

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

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

1부 ‘급한 불 끄기 바쁜 프로덕트의 문제점’에서는 프로덕트 조직에서 나타나는 위험 신호에 대해 이야기하며, 주로 문제점에 초점을 맞췄습니다. 이번 글에서는 이러한 문제를 해결하기 위한 전략과 전술에 대해 다루고자 합니다.

1부에서 제가 강조했던 주요 문제들은 다음과 같습니다.

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

이번 글은 주로 프로덕트 및 소프트웨어 개발 리더를 대상으로 작성되었지만, 이 과정에 관여하는 모든 분들에게 유용한 내용이 될 겁니다.

급한 불 끄기는 그만

말은 쉽지만, 막상 실행하자니 어렵게 느껴지죠?

급한 불을 끄기식 해결을 줄이는 방법에는 여러 가지가 있지만, 다른 문제들과 마찬가지로 첫 번째 단계는 문제를 인지하는 것입니다. 회사의 경영진이 이 문제를 인정하고 이를 우선순위로 삼기로 결정하는 순간이 중요한 첫걸음입니다. 당연한 이야기처럼 들릴 수 있지만, 실제로 급한 불부터 끄는 해결은 경영진이 중요한 것보다 시급한 것에 집착하면서 발생합니다. 그러므로 내부에서든 외부에서든, 누군가가 이 문제를 지적하는 것이 필요합니다.

여기서부터는 로저 본이 쓴 ‘급한 불 끄기는 그만(Stop Fighting Fires)’라는 하버드 비즈니스 리뷰(HBR) 기사에서 몇 가지 아이디어를 정리했습니다.

전술적 방법

• 불을 끄지 말고 태워 없앱니다. 만약 비즈니스나 제품 일부가 지속적으로 문제가 되고, 중요한 일에 집중하지 못한다면 그 부분을 아예 없애버리세요. 문제를 일으키는 제품이나 운영을 과감히 중단하는 것이 답입니다. 더 많은 문제를 일으키는 제품이라면 주저하지 말고 정리하는 것입니다.
• 주저하지 말고 우선순위를 정해 모든 일을 분류합니다. 브랜든 추(Brandon Chu)가 그의 유명한 글 ‘철저한 우선순위(Ruthless Prioritization)’에서 말했듯, 목표를 더 빠르게 달성할 방법은 항상 존재합니다. 가차 없이 우선순위 설정하는 것이 익숙하지 않을 수 있지만, 리더는 팀원들이 불필요한 것들을 과감히 제거하도록 도전시킬 책임이 있습니다.
• 외부에 도움을 요청합니다. 팀 외부에서 임시로 문제 해결자를 찾는다면, 팀원들은 중요한 일에 집중할 수 있고 외부 인력이 문제를 처리할 수 있습니다. 이는 효율적일 뿐만 아니라, 팀 사기를 높이는 데에도 효과적입니다. 대부분의 팀원들은 문제 해결보다는 새로운 기능 개발처럼 재미있고 보람 있는 일에 집중하고 싶어 합니다.

전략적 방법

• 소프트웨어 개발 전략을 변경합니다. 저는 모든 방법을 시도해 보았습니다. 길고 상세한 로드맵, 로드맵 없는 접근, 간트 차트 기반의 계획, 주어진 자원을 고려한 짧은 주기(appetite-based cycles), 공격적인 OKR, 그리고 완전히 목표 없는 방식까지 말이죠. 결론적으로 제품 전략에 대한 만능 레시피는 없습니다. 전략이 효과적이지 않다면 새로운 방식을 시도하세요. 또한 회사 상황에 따라 전략을 유연하게 변경하는 것이 중요합니다. 단, 방향을 극단적으로 바꾸는 진자운동(pendulum swing)은 반드시 피해야 합니다.
• 핵심이 아닌 제품과 기능은 외부에서 해결합니다. 비즈니스의 핵심이 아닌 부분에 에너지를 낭비하지 마세요. 제품의 일부를 완전히 외부에 아웃소싱하면 팀이 해당 문제와 유지 관리 비용에서 벗어날 수 있습니다.
• 개별 문제가 아닌 문제가 속한 범위를 해결합니다. 같은 유형의 문제를 묶어 근본 원인을 파악하고 해결해야 합니다. 처음에는 더 많은 비용이 드는 것처럼 보일 수 있지만, 이는 미래의 문제를 예방하고 결국 더 큰 효과를 가져옵니다.

문화적 방법

• 침착함을 유지합니다. 리더는 차분해야 합니다. 대부분의 경우, 해결되지 않은 버그가 생명을 위협하지는 않습니다. 리더가 불안해하면 팀원들도 불안해지기 마련입니다. 리더의 침착함이 팀의 분위기를 좌우합니다.
• 임시방편을 용납하지 않습니다. 이는 주로 기술 리더들의 역할이지만, 제품 관리자들 역시 빠르고 조잡한 해결책을 강요해서는 안 됩니다. 임시방편은 결국 언젠가 갚아야 할 빚, 즉 기술 부채가 됩니다.
• 모든 비용을 들여 마감 기한을 맞추지 않습니다. PM은 기한을 맞추어야 하는 역할을 가진 것은 사실입니다. 하지만 여기서 중요한 것은 ‘모든 비용을 들여서’입니다. 대부분의 마감 기한은 자체적으로 설정된 것이기 때문에 유연하게 대처해야 합니다.
• 급한 불 끄기식 문제 해결을 칭찬하지 않습니다. 주말에 4시간 동안 버그를 고친 엔지니어를 칭찬하지 마세요. 잘못된 행동이라는 것이 아니라, 이건 잘못된 문화의 신호이기 때문입니다. 조직은 장기적이고 체계적인 문제 해결을 실천하고, 땜질할 문제가 많지 않은 관리자들을 인정하고 보상해야 합니다.

IT 사고방식에서 프로덕트 사고방식으로 전환하기

우버(Uber)는 “기술 회사”일까요, 아니면 “프로덕트 회사”일까요? 꽤 어려운 질문일 수 있습니다. 가장 쉽게 답하면, “기술 중심의 프로덕트 회사”라고 말할 수 있겠지만, 그렇게 말하는 사람은 거의 없습니다. 이 질문이 별거 아닌 것 같지만, 회사에서 많은 사람들의 공통 대답이 그 조직의 문화와 사고방식임을 담고 있습니다.

명확한 데이터는 없지만 많은 회사가 엔지니어들에 의해 설립되었고, 일반적으로 CTO보다 CPO의 수가 더 적다고 생각합니다. 이로 인해 시장에서는 IT 사고방식이 지배적이 되었고, 고객 경험은 이보다 뒤로 밀려나는 경우가 많습니다.

기술은 필수적이라 부담이 되거나, 그 자체가 목적이 되어서는 안 됩니다. 기술은 가치를 제안하는 데 일부가 될 수 있으며, 반드시 그렇게 되어야 합니다. 창업자들이 회사를 설립하는 이유는 다양하지만, 기술은 그중 하나일 뿐입니다. 결국 모든 회사는 어떤 방식으로든 인간의 삶을 진보시키기 위해 존재합니다. 그리고 핵심 목표가 사람들을 돕는 것이라면, 기술은 자연스럽게 부차적인 수단이 됩니다.

이제 각자 우리 회사 사람들은 어떤 배경을 가지고 있을지 생각해 봅시다. 99%의 대부분은 금융, 마케팅, 엔지니어링, 디자인, 경영학, 인사관리 등을 전공한 사람들이 있을 것입니다. “사람들의 삶이 더 나아지도록 돕는 방법”을 전공한 사람은 거의 없을 겁니다. 결국 프로덕트 회사란 기술을 만드는 방법을 아는 사람들과 이를 통해 돈을 버는 방법을 아는 사람들이 모인 곳입니다. 이 모든 설명은 왜 “IT 중심 사고”가 일반적이고, “제품 중심 사고”는 낯설어하는지를 설명하기 위함입니다.

이것이 리서처를 채용하는 것이 제품 중심 사고로 전환하는 데 있어 가장 혁신적인 이유입니다. 리서처들은 고객 경험과 사람들이 더 나아갈 수 있도록 돕는 일에 열정적이며, 프로덕트 조직에 이들을 두지 않는 것은 큰 손실입니다. 보통 리서처는 심리학이나 커뮤니케이션과 같은 배경을 가진 경우가 많습니다. 물론 PM, 디자이너도 리서치를 수행할 수 있고 또 그렇게 해야 하지만,  전문 리서처가 있는 것과는 문화적으로 큰 차이가 있습니다.

또 다른 문제는 프로덕트 기술을 IT 기술처럼 취급할 때 나타납니다. 즉, 고객 중심의 가치를 창출하기보다는 내부 운영 효율성이나 기술적 구현에만 초점을 맞추는 이러한 상황에서 나타납니다. 이를 해결하기 위해 제품 관리 분야의 선구자인 ‘마티 케이건’은 몇 가지 행동 방안을 제안했으며, 여기에 제 의견을 더해 소개하려 합니다.

• 고객용 기술과 내부 직원용 기술을 명확히 구분해야 합니다. 두 기술은 요구사항이 다르고, 필요한 기술과 역량도 다릅니다. 따라서 이를 담당할 인력, 프로세스, 자원이 각각 다르게 필요하다는 점을 인지해야 합니다. (이 주제에 대해서는 아래에서 더 다루겠습니다.)
• 디자이너를 프로덕트 디자이너로 전환해야 합니다.이 주제는 별도의 글로 다룰 만큼 중요한 문제입니다. 관심이 있다면 아론 트레비스의‘UX 디자인과 프로덕트 디자인의 명확한 차이점’을 참고하세요.
• 모든 작업은 PM의 검토를 거쳐야 합니다. 작업의 기술적 수준에 관계없이, 모든 일이 PM의 검토를 거치도록 하면, 기술 중심이 아닌 사용자 관점에서 작업할 수 있습니다. 가장 효율적인 방법은 아닐 수 있지만, 이는 중요한 문화적 변화를 불러옵니다.
• 대규모 소프트웨어의 요구사항을 이해하고, 이를 충족할 수 있는 엔지니어를 채용해야 합니다. 이들은 '회사 내부 업무용 소프트웨어'와는 다른 요구사항을 이해하고 있어야 합니다.
• 개발 과정은 단순히 산출물이 아닌 사용자와 비즈니스에 긍정적인 변화를 불러오는 성과에 초점을 맞춰야 합니다. 작업이 끝났다는 것만으로 '완료'로 간주하지 말고, 실제로 사용자의 행동 변화가 일어나야 '완료'로 간주해야 합니다.
• PM은 비즈니스 전반에 대해 포괄적인 관점을 가져야 합니다. 제품 조직 외부에서 일어나는 모든 일(마케팅, 영업, 인사, 운영 등)을 이해하고, 이를 비판적으로 분석할 수 있어야 합니다. 이러한 요소들은 모두 제품, 비즈니스, 그리고 팀에 영향을 미칩니다.

생산성에 집착하는 문화 피하기

제프 고덜프의 훌륭한 강연 중에 애자일이 무엇인지 설명합니다. 그는 애자일이란 단순히 계획을 따르게 아니라, 변화에 대응하는 것이라고 이야기합니다. 그러나 현실은 많은 조직이 애자일을 학습이나 민첩성, 방향 수정보다는, 단순히 소프트웨어를 만들고 좋은 코드 몇 줄을 작성하는 데 집중하는 도구로 오해하고 있습니다. (참고 : 애자일이란 무엇인가)

여러분도 아마 CEO가 엔지니어들이 아무것도 하지 않을 때 놀라는 장면을 본 적이 있을 겁니다. 그 반응을 이해하지 못하는 것은 아닙니다. 회사는 인건비를 회수해야 하기 때문이죠. 하지만 소프트웨어를 마구 생산하는 건 해결책이 아닙니다.

해결책은 고객 가치를 창출하는 것입니다. 고객 가치는 한 줄의 코드에서 나올 수도 있고, 심지어 코드를 삭제할 때 나올 수도 있습니다. 이를 체계적으로 해결하는 방법 중 하나는 개발 과정에 ‘정리 기간(cool-down period)’을 도입하는 것입니다. 이 기간 동안 엔지니어들은 버그 수정, 새로운 아이디어 탐색, 새로운 기술 가능성 실험 등 원하는 일에 집중할 수 있습니다.

‘Shape up’이라는 제품 방법론에서는 6주의 개발 기간과 2주의 정리 기간을 가질 것을 권장합니다. 이 기간 동안에는 작업 없이 숨을 고르고, 필요할 때 회의를 열며, 다음에 무엇을 할지 고민할 수 있습니다.

미래를 위한 20% 시간

스타트업 프로덕트 회사들은 지속적인 혁신과 현상 유지 사이에서 균형을 맞추는 데 어려움을 겪곤 합니다. 혁신이 정말 필요하지만, 현실적으로 필요한 실험을 위해 시간과 자원을 확보해야 합니다. 그러나 자원은 항상 부족하고, 운영을 유지하면서 동시에 혁신을 추구하는 일은 달리면서 신발 끈을 묶는 것과 같죠.

이 난제를 해결하는 한 가지 방법은 간단한 규칙을 따르는 것입니다. 오늘 수익을 가져다주는 일에 80%의 시간을 사용하고, 미래 수익을 가져다줄 일에 20%의 시간을 투자하는 것입니다. 이 규칙은 에릭 슈미트(전 구글 CEO)가 빌 게이츠로부터 들은 조언이며, 그의 저서 ‘구글은 어떻게 일하는가’에 자세히 설명되어 있습니다.

책에서도 설명되었듯, 이 규칙을 실제로 따르는 것은 보기보다 어려울 수 있습니다. 리더들은 새로운 제품이 수익을 내기까지 걸리는 시간을 종종 과소평가합니다. 새롭고 반짝이는 아이템은 기존의 핵심 비즈니스보다 매력적으로 보일 수 있지만, 지루해 보이는 기존 사업이 회사의 고정비를 책임지고 있습니다. 이 핵심 사업에서 실수를 저지르면 회복하기가 매우 어려울 수 있습니다.

그럼에도 불구하고, 핵심 80%에 집중하는 것만큼 중요한 것은 20%의 시간을 혁신에 할애하는 것입니다. 여기서 말하는 것은 구글의 유명한 ‘20% 룰’이 아닙니다. 제가 말하는 것은 리더십에서 시작되는 명확하고 전략적인 혁신입니다. 이를 간과하면 새로운 경쟁자가 비즈니스를 위협할 뿐만 아니라, 팀원들이 혁신할 기회를 잃고 동기 부여를 상실할 위험이 있습니다.

혁신을 멈춘 기존 회사들은 보통 하루아침에 무너지지는 않습니다. 브랜드에 의존해 몇 년간 생존할 수도 있죠. 하지만 오늘날 좋은 회사가 빠르게 성장할 수 있는 동력이, 동시에 그 회사를 빠르게 몰락하게 만드는 원인이 될 수 있다는 사실을 인식하는 것도 중요합니다.

명확하게 고객용 제품과 내부 직원용 제품 구분하기

두 제품은 요구사항도 다르고, 필요한 기술과 역량도 다르며, 프로세스와 자원도 각각 다릅니다. 둘 다 중요하지만, 이 둘은 성격이 다르고 대부분은 유저용 제품에 맞춰져야 합니다.

내부 직원용 제품

• 엄격한 책임이 요구되지 않습니다.
• 제품 관리가 선택 사항입니다.
• 마감 기한이 자율적으로 설정되며 유연합니다.
• 속도보다는 품질이 더 중요합니다.
• 실험을 반드시 허용하지는 않습니다.

고객용 제품

• 모든 작업에 책임이 요구됩니다.
• 제품 관리는 필수적입니다.
• 출시 시기가 매우 중요합니다.
• 품질보다 속도를 우선시합니다. 이는 “더 빨리 출시된 제품이 더 늦게 출시된 제품보다 고객에게 더 가치 있다”라는 원칙 때문입니다.
• 실험을 염두에 두고 설계됩니다.

내부 운영 제품은 아웃소싱하거나 상용 소프트웨어를 활용하세요. 그래야 최고의 인재와 자원을 고객을 위한 제품에 집중할 수 있습니다.

작업 시간 분배

저를 아는 동료라면 누구나 제 가장 강력한 무기가 무엇인지 알고 있을 겁니다. 바로 제품 개발 주기입니다. 그리고 제품 개발 주기를 경험해 본 사람이라면, 그 비결이 작업 시간 분배에 있다는 것도 알 것입니다. 제품 개발 주기에 대해서는 여기서 깊이 다루지 않겠습니다. 이미 관련된 많은 글과 문헌이 있으니까요. 특히 Basecamp 팀의 ‘제품 개발 방법론(Shape Up)’은 현재까지 가장 좋은 자료로 손꼽힙니다. 대신, 작업 시간 분배가 왜 그렇게 중요한지를 설명해 보겠습니다.

IT 사고방식이나 기술 중심의 회사에서는 흔히 추정 기반 개발이라는 패러다임이 존재합니다. 여기서는 회사가 엔지니어들의 속도에 맞춰 움직이며, 특정 기능이 배포되기까지 걸리는 시간을 엔지니어들이 결정합니다. 그러나 이 방식의 문제는 소프트웨어 개발에서 추정 자체가 매우 어렵다는 데 있습니다. 특히 레거시 코드에 의존하는 회사에서는 엔지니어들이 기존 시스템의 작동 방식을 끊임없이 파악해야 하는 경우가 많습니다. 만약 모든 추정이 빗나가고 마감 기한을 지속적으로 놓치고 있다면, 멈춰서 이를 고민해 볼 필요가 있습니다.

작업 시간 분배는 조직 전체를 한 단계 끌어올립니다. 리더들이 어떤 계획의 목표를 결정하게 하고, 제품 팀이 모든 작업을 개발 주기에 맞추도록 만듭니다. 이 방식은 어떻게 소프트웨어를 가장 잘 만들고, 얼마나 오래 걸릴지라는 논의에서 벗어나, 고객 가치와 가장 중요한 것이 무엇인지에 초점을 맞추게 합니다. 고객 가치와 출시 시기를 중심으로 논의하는 것은 진정한 제품 중심 조직으로 거듭나는 가장 중요한 요소입니다. 이를 실현하기 위해 제품 개발 주기나 다른 작업 시간 분배 기법을 활용할 수 있습니다.

PM의 권한을 중심으로

최근 밀라노에서 열린 Product Heroes 커뮤니티에서 발표할 기회가 있었는데, Q&A 시간에 누군가 이런 질문을 했습니다.

“우리는 발견 단계에 시간을 할애할 여유가 없으면 어떻게 해야 하나요?”

저는 이렇게 답했습니다.

“시간을 할애하시든가, 아니면 새로운 직장을 찾으세요.”

지금 돌아보면 약간 과한 표현이지만, 전달하려고 했던 메시지는 이겁니다. 조직은 제품 관리를 신뢰하거나 그렇지 않거나 둘 중 하나라는 것입니다. 여기서 ‘조직’이란 회사의 리더십을 의미합니다. 만약 리더가 리서치, 과학적 실험, 지속적인 반복의 중요성을 진정으로 믿지 않는다면, 문제를 해결할 방법은 없습니다. 이 문제를 해결해 줄 마법 같은 프로세스나 방법론은 존재하지 않습니다.

이러한 상황에서 싸워야 하는 책임은 리더(CPO, VP, Head of Product)에게 있습니다. 하지만 조직이 제품 관리의 중요성을 제대로 이해하거나 이를 위한 환경을 조성하지 않기 때문에, 많은 PM이 전략적인 역할을 수행하기보다는, 단순히 기능 요청을 정리하고 전달하는 ‘백로그 관리자’ 역할에 머무는 경우가 흔합니다.

이 문제를 해결하기 위해 다음 규칙들을 추천합니다.

• 이해관계자들이 PM을 건너뛰어 기술팀에 직접 접근하지 말아야 합니다.
• 가능한 한 위에서 내려오는(top-down) 의사결정을 피해야 합니다.
• PM이 없는 회의에서 의사결정이 이루어지지 않도록 합니다.
• PM이 해결책을 강요받기보다는 문제를 더 잘 이해할 수 있도록 돕습니다.

이러한 규칙은 프로세스를 통해 실행할 수 있습니다. 하지만 이것만으로 충분하지 않을 수 있습니다. 규칙은 깨지기 마련이니까요. 이때 필요한 것이 진정한 리더십입니다. 제품 리더로서 PM을 조직의 중심에 세워야 합니다. 이를 달성하기 위해 추천하는 전략은 다음과 같습니다.

• PM이 정기적인 제품 시연을 주도하게 합니다. 이는 PM이 자신의 역량을 뽐내고 동시에 제품 문화를 전파할 수 있는 좋은 기회입니다.
• PM이 회사의 전체 회의에서 성과와 비즈니스 결과를 발표하도록 합니다. 전체 회의가 없더라도, OKR 점수화, 대시보드 지표 공유 등 회사가 사용하는 방식으로 성과를 정기적으로 공유할 수 있습니다.
• PM이 의사결정을 주도하도록 밀어줍니다. 예를 들어, PM이 미션 회의를 소집하고, 이해관계자를 관리하는 방법을 배우도록 하세요.
• PM이 고객의 목소리가 되게 합니다. 이를 위해 PM이 원본 고객 피드백에 직접 접근하도록 하고, 이를 조직 전체에 공유하게 하세요.
• 고객 가치를 창출하는 데 진정으로 헌신한 사람들에게 보상을 제공함으로써 건강한 문화를 만듭니다. 보상은 반드시 구체적이어야 합니다. 일반적으로 이는 급여 인상, 승진, 보너스 또는 다른 형태의 중요한 보상을 포함하며, 이를 통해 다른 사람들에게 명확한 메시지를 전달할 수 있습니다.

결론

이 문제를 해결할 단 하나의 정답은 없으며, 마법 같은 해결책도 없습니다. 다만 분명한 사실은 이 문제는 조직 문화와 깊이 연결되어 있다는 점입니다. 이를 해결하려면 진정한 리더십이 필요합니다. 여기서 ‘진정한’ 리더십이란, 문제가 발생했을 때 침묵하지 않고, 이를 과감히 지적하며 실제로 행동에 나설 수 있는 리더를 말합니다.

잘못된 프로덕트 문화는 결국 비즈니스 실패로 이어집니다. 제품-시장 적합성을 달성하지 못하면, 자금이 고갈되거나 경쟁사에 밀려 시장에서 사라지게 됩니다. 이는 단순히 PM만의 문제가 아니라, 조직 전체가 함께 고민하고 해결해야 할 과제입니다.

부서 간 소통이 단절된 회사들은 프로덕트 문화를 받아들이는 데 어려움을 겪습니다. 프로덕트 문화란 고객을 조직의 중심에 두는 것을 의미합니다. 고객이 중심이 된다면, 마케팅 목표, 재무 목표, 채용 목표 등 다른 모든 것은 부차적인 문제가 됩니다. 중요한 것은 오직 제품-시장 적합성을 달성하는 것입니다.

<참고>

• ‘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
• ‘Shape Up — Stop Running in Circles and Ship Work that Matters’ by Ryan Singer

<원문>

Symptoms of a broken product culture — Part 2

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