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 사이에도 커뮤니케이션이 중요합니다. 기능조직에서는 사실 서로 얘기 안 해도 돼요. 자기 태스크에 집중하면 되니까.

근데 사실 커뮤니케이션을 하다 보면 생산성이 떨어지기 쉽거든요. 그래서 특히 제품조직에서 '생산성을 떨어뜨리지 않는 커뮤니케이션'에 대한 고민을 많이 했어요. 덕분에 지금 제품조직의 커뮤니케이션 시스템이 엄청 고도화되었는데...

그 부분은 제품조직 중간관리자인 신영님과 얘기하는 게 더 좋을 것 같은데요?