퍼블리 제품조직이 원하는 건 '골'이 아니라 '승리'다
2021년 7월 CPO 승국 인터뷰
2021년 7월 진행한 퍼블리 제품조직 리더들의 인터뷰 아티클 전문을 브런치에도 공유합니다. 커리어테크 스타트업 퍼블리의 경쟁력은 '프로덕트'에서 나옵니다. 프로덕트를 중심으로 일하는 스타트업에서 개발자, 아니 소프트웨어 엔지니어는 어떻게 일할까요? CPO 승국, VP of Engineering 신영, Tech Lead 재용과의 인터뷰를 통해 생생한 이야기를 들어보세요.
Editor's Comment
"퍼블리에 좋은 분들을 적극적으로 모셔올 수 있느냐에 다음 1년의 성패가 걸려 있다고 생각해요. 그래서 저부터 채용에 많은 시간과 에너지를 쓰려고 해요."
"며칠 전 타운홀 미팅 때 공언한 바 있는데, 제 구글 캘린더의 80%는 채용을 위한 시간으로 짜여져 있어야 해요. 그게 저의 3분기 목표입니다."
시리즈 B 투자를 유치하고 나서, 박소령 CEO가 한 말입니다. 실제로 퍼블리는 최근 채용에 리소스를 집중하고 있는데요. 그중에서도 소프트웨어 엔지니어 포지션은 신입, 경력 모두 열어두고 채용 속도를 높이고 있습니다.
입사 혹은 이직을 고민 중인 소프트웨어 엔지니어 여러분을 위해, 퍼블리의 제품조직을 총괄하고 있는 이승국 CPO를 만났습니다. 퍼블리의 프로덕트 방향성은 무엇인지, 소프트웨어 엔지니어들이 어떤 환경에서 일하고 있는지 자세히 알고 싶으시다면, 아래 인터뷰가 도움이 될 것입니다.
Not 개발자, But 소프트웨어 엔지니어
안녕하세요, 자기소개 부탁드려요.
승국(이하 생략): 퍼블리 CPO이자 CTO, 이승국입니다. 2016년 5월 31일에 입사해서 지금까지 제품조직을 이끌고 있습니다.
퍼블리에서는 '개발자', '개발조직'이란 용어를 안 쓰더라고요. 개발조직 대신 제품조직, 개발자 대신 소프트웨어 엔지니어라고 부르는 이유가 있나요?
보통 개발자라는 말 많이 쓰는데, 저는 내부 엔지니어들과 얘기할 때 한 번도 개발자라는 표현을 쓴 적이 없어요. 별 거 아닌 것 같아도 이런 단어 하나가 매우 중요합니다. 우리 인간은 이름을 통해 본질을 이해하거든요. '난 개발자야'라고 생각할 때보다 '난 소프트웨어 엔지니어야'라고 생각할 때 훨씬 더 '내가 어떤 일을 하는지' 실감하게 되는 거죠.
개발자라는 표현만으로는 엔지니어의 역할이 뭔지 생각하면서 일하기가 어려워요. 그래서 실제로 많은 조직의 '개발자'들은 일방적으로 업무를 할당받는 사람이 되기도 하죠. 원래 소프트웨어 엔지니어는 주어진 태스크만 해결하는 사람이 아닙니다. 기존 기술을 활용해 소프트한 프로덕트를 만들고, 이 프로덕트로 어떻게 사업을 성공시킬 수 있을지를 항상 고민하는 분들이죠.
'소프트한 프로덕트'을 만든다는 게 어떤 뜻인가요?
소프트웨어에 soft라는 단어가 왜 들어갔을까요? 부드럽다는 건 그만큼 유연하게 변하기 쉽다는 거예요. 2004년에 생긴 페이스북 앱은 17년 동안 계속 바뀌어 왔어요. 지금은 이름만 그대로지 같은 프로덕트라고 볼 수 없을 정도죠.
코카콜라처럼 '하드한 프로덕트'은 한 번 만들어두면 쉽게 바꿀 수가 없어요. 비교적 변화를 주기 쉬운 '브랜딩'이 하드웨어 비즈니스에서 중요한 이유죠.
하지만 소프트웨어의 특징은 지속적으로 변한다는 겁니다. 그래서 IT 기업에서는 프로덕트 매니저(product manager)가 중요하고, 프로덕트 조직(product team)이 중요해요. 고객을 만족시켜 수익을 창출하는 것이 모든 비즈니스의 목적이라고 했을 때, 소프트웨어 비즈니스의 성패는 시시각각 변하는 고객의 니즈에 발맞춰 얼마나 빨리 프로덕트를 변화시킬 수 있느냐에 달려 있으니까요.
소프트하게 프로덕트를 계속 변화시키기 위해 중요하게 생각하시는 것이 있다면 어떤 걸까요?
프로덕트가 계속 변화하다 보면, 그 과정에서 복잡해지기 쉬워요. 프로덕트가 복잡해지면 프로덕트를 만지는 사람들의 생산성은 낮아집니다. 프로덕트는 계속 개선되어야 하고, 그러면서도 개개인의 생산성은 높게 유지되어야 하는데... 그럼 어떻게 해야 할까요?
프로덕트 개선을 집 수리에 비유하자면, 집 안에 사람이 살고 있기 때문에(이용자들이 프로덕트를 쓰고 있기 때문에) 집을 안 부수고도(프로덕트를 초기화하지 않고도) 고칠 수 있어야 해요. 그러려면 애초에 집을 지을 때부터 구조를 잘 만들어둬야겠죠.
그래서 퍼블리 제품조직은 프로덕트의 구조, 아키텍처에 투자를 많이 합니다. 아키텍처 자체가 중요하다기보다는, 엔지니어들의 높은 생산성을 유지하기 위해, 나아가 사업의 성공을 위해 아키텍처를 고민하는 거죠. 우린 10년, 20년 뒤에도 이 프로덕트를 고치고 있을 거니까.
Not 기능조직, But 목적조직
제품조직에서 사업의 성공까지 고민해야 하나요?
그래서 퍼블리의 제품조직은 '기능조직'이 아니라 '목적조직'으로 구성돼요. 엔지니어 전원이 '사업 성공'이라는 목표를 갖고 프로덕트를 만드는 거죠.
기능조직과 목적조직의 차이를 이해하기 쉽게 축구 비유를 들어볼게요. 옛날엔 수비수는 수비만 하고, 공격수는 공격만 했어요. 수비수에게 중요한 건 골 안 먹는 거고, 공격수에게 중요한 건 골 넣는 거였죠. 이게 기능조직의 방식이에요.
근데 요즘은 '토탈사커'라고 해서 수비수도 공격하고, 공격수도 수비하죠. 이제 목적조직의 방식이에요. 목적조직에게 중요한 건 골 안 먹기, 골 넣기가 아니라 이기는 거예요. 퍼블리 제품조직에게 중요한 것이 눈앞의 태스크가 아니라 프로덕트의 성공인 것처럼요.
목적조직으로 일하는 게 엔지니어 개인에게는 어떤 장점이 있을까요?
보통 기업이 엔지니어에게 요구하는 역할은 주어진 태스크 해결에 집중하는 것입니다. 근데 이럴 경우, 엔지니어 입장에선 내가 뭘 만드는지 모르고 일하게 될 수 있어요. 퍼블리가 선호하는 방식은 엔지니어에게 태스크(task)가 아니라 피처(feature)를 할당하는 거예요. 그럼 엔지니어는 하나의 피처를 완성시키기 위해 프론트엔드부터 백엔드까지 전체 과정을 진행하게 돼요.
보통 기능조직에서는 엔지니어에게 태스크를 할당할 때 엄청 세부적인 지시가 나가요. 매번 해당 태스크의 맥락을 이해시켜야 하니까. 하지만 저희 제품조직의 엔지니어는 '우리가 이 피처를 왜 만드는지, 사용자가 어떤 식으로 이 피처를 사용하게 될지' 등 목적만 갖고도 피처를 만들 수 있어요. 사업 성공에 대한 얼라인먼트가 맞춰져 있기에 가능한 일이죠.
그래서 퍼블리는 채용할 때도 프론트엔드/백엔드/ios/ 이렇게 세부적으로 나눠 뽑지 않아요. 요즘 T자형 인재의 중요성이 강조되는데, 프론트/백엔드가 나눠져 있으면 T자형으로 성장하는 데 한계가 있어요. 반면 퍼블리에서는 프론트에 특화된 분, 백엔드를 선호하는 분들이 각각 '자기만의 장점이 있는 풀스택 엔지니어'로 성장하고 계십니다.
자율성이 주어지는 만큼 엔지니어 입장에서는 부담도 될 것 같아요.
퍼블리 제품조직에서 제일 중요하게 생각하는 것 중 하나가 실수에 대해 개인을 비난하지 않는 거예요. 축구 못하는 애들이 골 먹으면 뭐라고 하는지 아세요? '골키퍼 때문이다, 수비 때문이다...'
아니거든요. 골 먹은 건 시스템 탓이에요. 왜 골키퍼가 공격수와 1:1 상황을 맞닥뜨리게 되었는가. 왜 수비수 수가 부족했나. 모두에게 책임이 있단 말이에요. 책임의 퍼센티지는 조금씩 다를 수 있지만. 골을 먹었다는 건 여러 겹의 방어벽이 다 깨진 거예요. 개선을 위해 문제의 원인을 찾을 수는 있지만 최종적인 누군가만을 비난할 수 없는 일이죠.
마찬가지로, 버그가 나면 담당 엔지니어를 비난할 게 아니에요. 버그는 원래 생기는 거고, 이걸 막으려고 QA 같은 거 하는 거잖아요. '누구 잘못이야?'가 아니라 '왜 못 잡아냈을까' 혹은 '크리티컬한가, 아님 허용해도 되는 수준의 버그인가', '얼마나 빨리 발견했나' 등에 대한 회고가 훨씬 더 중요해요.
목적조직으로 일할 때 어려운 점도 있나요?
기능조직에 비해 영역 구분이 확실하지 않다 보니, 헷갈리기 쉬워요. '공격수가 수비를 왜 저렇게 열심히 해?', '수비수가 왜 여기까지 올라와?' 싶은 거죠. 왔다갔다 하면서 그레이 영역(gray zone)이 생기기도 하고요. '여기 공 떨어지면 누가 받아야 되지?'
그래서 축구 코치들이 항상 하는 얘기가 있어요. "서로 얘기를 많이 해라." 목적조직에서는 엔지니어-디자이너-PM 사이에도 커뮤니케이션이 중요합니다. 기능조직에서는 사실 서로 얘기 안 해도 돼요. 자기 태스크에 집중하면 되니까.
근데 사실 커뮤니케이션을 하다 보면 생산성이 떨어지기 쉽거든요. 그래서 특히 제품조직에서 '생산성을 떨어뜨리지 않는 커뮤니케이션'에 대한 고민을 많이 했어요. 덕분에 지금 제품조직의 커뮤니케이션 시스템이 엄청 고도화되었는데...
그 부분은 제품조직 중간관리자인 신영님과 얘기하는 게 더 좋을 것 같은데요?
다음 글에서는 퍼블리에서 VP of Engineering으로 일하고 있는 신영이 '퍼블리의 엔지니어들이 생산성 높은 협업을 위해 어떻게 일하고 있는지' 들려드립니다.
기술로 커리어 시장을 혁신하는 퍼블리!
함께 패러다임을 바꾸고 세상을 뒤집을 동료를 찾고 있어요.
더 자세한 내용이 궁금하다면 아래 링크를 클릭하세요!
