테크 회사의 제품 담당자라면 개발자와 한 번 쯤은 싸워봤을 것이다. 다음은 제품 담당자와 개발자가 싸우게 되는 전형적인 상황.
새로운 제품을 기획하면서 제품 담당자는 기존에 있는 기능들과 코드를 조금 변형하고 이래저래 짜깁기 해서 새로운 기능을 구현하면 당장 내일도 제품 출시가 가능하다고 하고, 엔지니어는 그런 멍청한 방법은 제대로된 해결책이 아니라고 하며 새로운 infrastructure를 만들고 새로운 코드들을 짜야한다고 한다.
생각해 보면 두 사람의 주장 모두 일리가 있다. 기존에 있던 코드를 계속해서 변경하고 여기 저기에 덕지덕지 붙여 제품을 구현하다 보면 코드가 프랑켄슈타인처럼 되어 관리와 디버깅이 매우 까다로워지며, 또한 추후 확장성에도 문제가 있을 수 있다. 간단히 말해 개발자들이 가장 싫어하는 기술 부채가 (technical debt) 눈덩이 처럼 불어나는 것이다. 하지만 그렇다고 항상 새로운 판에서 완벽한 코드만 짜려고 하다간 크리스마스에 맞춰 내야 하는 제품이 초복이 넘어 출시되는 위험이 생긴다. ‘네가 맞다. 너도 맞다’의 황희 정승 코스프레 늪에 빠져 어쩔 줄 몰라할 때 제품 담당자는 다음과 같은 말로 개발자를 설득한다: ‘완벽함은 좋음의 가장 큰 적이야. 일단 내가 제안한 대로 하면 어느 정도 좋게 구현이 되니깐, 일단 빨리 만들어서 우리 가설을 증명한 후에 제대로 만들자.’
겨우 설득해서 진도를 뺀 제품 담당자는 안도의 한숨을 쉬지만 개발자는 이 결정에 대해서 탐탁해 하지 않는다. 제품 담당자는 본인이 극적인 타협을 끌어내어 시간 내에 제품을 출시할 수 있었는데 자신을 고마워 하지는 못할 망정 왜 탐탁해 하지 않는지 이해가 되지 않는다.
개발자의 입장이 되어보자. 물론 좋은 제품과 기능들을 사용자들에게 전달하고 싶은 마음은 제품 담당자 못지 않을 것이다. 하지만 제품 출시에 대한 개발자들의 평가는 해당 제품을 구현하는데 존재하는 기술적인 문제들은 어떻게 멋지고 깔끔하게 풀었는지가 큰 요소가 되고, 이러한 engineering craftmanship을 코드로 표현하고 동료들에게 인정을 받아야 한다. 특히 큰 테크 회사인 경우 해당 업무의 특수성에 대해 잘 모르는 사람이 일반적인 잣대로 업무 성과를 평가할 수 있기 때문에 개발자의 실력을 대변하는 코드가 다른 개발자가 봤을 때 깨끗하고 좋아야 한다. 엘레강스한 코드를 짜고 멋진 시스템 아키텍쳐를 구현할 수 있는데, 제품 담당자의 ‘빨리빨리’ 압박으로 프랑켄슈타인 코드를 만들어 동료들에게 검사를 맡아야 하는 개발자의 마음이 좋을리 없다. 심지어 성과 평가에 반영이 안된다고 한들, 문제를 해결하고 새로운 것을 만드는 것이 주된 업무인 개발자의 (= developer) 입맛에 맞을리 없다. 한두 번은 어떻게 넘어가더라도 그것이 반복되는 일상이 된다면 아마 개발자들은 그 제품 담당자를 떠나버릴 것이다.
다시 제품 담당자의 입장으로 돌아가자. 개발자의 입장을 생각해 보니 미안하긴 한데, 그렇다고 위에서 언급했듯이 무조건 완벽 코드 모드로 가서 망부석이 될 수는 없지 않은가? 이런 경우 개발자들이 모인 회의 자리에서 해당 개발자의 업무를 인정해 주고 그것이 왜 전략적으로 중요한지 강조를 하여 그의 사기를 북돋아 주거나, 성과 평가 때 코드 및 기술 문서와 더불어 본인의 기여도를 보여줄 수 있도록 임원 보고서에 개발자를 참조, 혹은 기술적으로 새롭게 접근하기로 결정된 프로젝트로 해당 개발자를 추천하는 배려 등이 노련한 제품 담당자들이 개발자들의 신뢰를 되찾을 수 있는 방법들이다. 나도 예전 링크드인 온라인 사업부를 담당했을 때 기존 사용자 경험을 조금씩 바꾸어 가면서 성과를 최적화 시키는 그로스 해킹팀에 배정된 개발자들은 두 스프린트 단위로 프로젝트를 교체할 수 있도록 하였고, 기능을 전체 팀 앞에서 시연하는 ‘데모 데이’에서 지난 성과를 나누고 기여한 개발자들을 축하해 주었으며, 가끔씩 사장님 / 부사장님을 초대해 해당 업무의 중요성을 팀원들이 느낄 수 있게 자리를 마련했던 경험이 있다. (사족: 꼬아서 보는 사람들은 임원들이 팀을 방문하는 행위가 오히려 더 부담되고 ‘쫀다고’ 생각할 수 있겠으나 실리콘밸리에서는 팀에게 사기를 진전시키는 가장 좋은 수단 중 하나이다. (‘와~ 내가 하는 일이 사장님이 신경 쓸 정도로 회사에서 중요하고 의미 있구나!’))
흔히 제품 관리는 50% 과학, 50% 예술이라고 한다. 성공적인 제품에 필요한 기획, 사용자에 대한 인사이트, 기술에 대한 높은 이해도, 프로젝트 관리 기법 등은 과학적인 사고 방식이 치중된 제품 담당자의 필수 실력이라고 한다면, 위와 같이 핵심 내부 이해관계자인 개발자들의 입장을 이해하고 타협과 조율을 아름답게 끌어내는 실력은 분명 제품 관리의 감성적이고 예술적인 영역이라고 볼 수 있다. 좌뇌와 우뇌를 동시에 총 가동해야 하는 이런 제품 담당자의 길… 단연코 쉽지 않지만 정말 매력적인 직업이라 생각하고, 또 이런 경험을 할 수 있다는 것에 감사하다.
