퍼블리가 개발자를 생각하는 방법
왜 퍼블리에서는 개발자를 소프트웨어 엔지니어라고 부를까?
오늘 콘텐츠의 주인공 퍼블리 CPO 승국. 2016년부터 지금까지 함께하고 있어요!2016년 10월 퍼블리 멤버십 아티클로 발행된 승국의 '제품' 이야기 전문을 브런치에도 공유합니다. 이땐 승국이 퍼블리 CPO로 합류한지 약 5개월 정도 된 시점이었어요. 국내에서 제품이라는 개념이 생소할 때부터 승국은 퍼블리를 제품 중심의 조직으로 만들기 위해 토대를 탄탄히 쌓아왔는데요.
이때와 지금의 퍼블리 제품의 성격과 내용은 많이 달라졌지만, 제품 조직을 꾸리고 일하는 방식에 대한 승국의 철학은 크게 달라지지 않았습니다. 처음부터 치열하게 고민하고 설정한 방향이기 때문일 것입니다. '개발'하지 말고 '제품'해야 하고, '개발자'가 아니라 '소프트웨어 엔지니어'라고 이야기하는 승국의 제품 철학이 많은 분들께 도움이 되길 바라며, 승국이 연재했던 두 편의 글을 브런치에서도 공개합니다!
(※ 2016년에 작성된 글이라 아웃데이트 된 부분이 있습니다. 고려하여 읽어 주세요!)
개발자는 누구인가?
저는 개인적으로 '엔지니어(Engineer)'를 '개발자'라고 부르는 것을 싫어합니다. 기획자, UX디자이너 등 제품을 개발하는데 관여한 모든 사람이 개발자이기 때문입니다.
이 모든 '개발자'들은 각자의 전문성을 가지고 함께 제품 개발을 통해 문제를 해결해야 합니다. 그리고 더 나은 해결책을 만들기 위해 이들을 어떻게든 좀 더 가깝게 붙여놔도 모자란데, '개발자/비개발자라 나누는 구조'는 문제가 있다고 생각합니다. 게다가 사실상 기획자나 UX디자이너를 비개발자라 부르는 것은 완전히 틀린 말이기도 합니다.
물론 관용적으로 또는 말을 줄이기 위해 엔지니어에게 개발자라는 이름을 붙일수도 있는거지... '너무 민감하다'고 보실 수도 있습니다.
그러나
조직에서 역할에 대한 용어는
매우 중요합니다.
수평적인 조직을 만들고자 직위를 없애고, 영어 이름을 쓰며 존댓말을 쓰지 못하게 하는 회사들을 생각해보면 금방 이해가 될 것입니다.
그렇기 때문에 저는 퍼블리에서 '개발자'라는 단어를 가급적 쓰지 않기로 마음먹었습니다. 그리고 이글은 이러한 생각을 이해하는 저와 같은 '엔지니어'분들께 드리고 싶은 이야기입니다.
엔지니어가 부족하면, 그들의 시간을 아껴주세요.
요즘 대부분의 IT 기업에서는 '항상 엔지니어가 부족하다'는 이야기를 합니다. 그러나 정작 그 부족하다는 엔지니어의 시간을 아끼는 노력은 얼마나 하는지 의문스럽습니다.
예전에 참여했던 한 그로스 해킹 관련 세션에서 연사가 스모크 테스트(Smoke Test: 실제 제품을 개발하지 않고 아이디어를 검증하기 위한 테스트, 더 자세한 설명은 이곳에서)에 대해 설명하면서, 반 농담으로 "엔지니어는 바쁘다. 그들의 시간을 아껴주고, 동시에 과연 개발할 가치가 있는 피쳐(Feature)인지 알아보기 위해 테스트를 한다"는 이야기를 한 적이 있었습니다.
지구 상에 새로운 아이디어는 없다는 말처럼, 아이디어는 사실상 넘쳐납니다. 그리고 그것을 구현할 수 있는 것은 엔지니어 뿐입니다. 결국 수많은 아이디어가 그 구하기 힘든 몇몇 사람에게 몰리고, 착한 엔지니어는 그 모든 것을 구현합니다.
이것이 제품 부채(Product Debt),
기술 부채(Technical Debt)의 시작입니다.
Product Debt, 제품 부채?
• 반복적인 개발을 통해 제품을 만드는 과정에서 생긴 다수의 기능이 오히려 제품의 Identity나 확장성을 해치는 것
• 제대로 관리/운영되지 않는 기능들로 인해 애초에 의도했던 경험을 사용자에게 주지 못하는 상태
* 참고 글: Product design debt versus Technical debt
즉, 제품 부채(Product Debt)가 생기는 이유는 개발하지 말아야 할 것을 개발한 경우와 개발 후 없애야 할 것을 없애지 못한 경우로 나눌 수 있습니다. 전자는 다양한 비용 및 그 성과에 대한 고민 없이 기능은 많을수록 좋다는 생각에 일단 개발하자는 경우입니다. 그리고 후자는 성과가 전혀 나오지 않음에도 불구하고, 이미 시간을 들여 만든 기능을 굳이 없애야겠냐는 생각에 그대로 두는데서 발생합니다.
기술 부채(Technical Debt) 또한 이와 비슷한 사연을 가지고 시작되지만, 의미하는 바는 조금 다릅니다. 똑같은 제품의 모습을 하고 있더라도 그것을 구성하고 있는 기술적인 퀄리티는 천차만별인 경우가 많습니다. 그리고 이런 기술적인 차이는 잦은 에러율이나 제품의 확장성을 저해하는 결과를 가져옵니다.
따라서 '너무 늦지 않게' 기존의 기술적인 퀄리티를 적정 수준으로 고쳐나가는 과정은 필요합니다. 하지만 이런 상태를 판단하고, 추가적인 개발을 한동안 멈추자고 결정하는 일은 쉽지 않습니다. '적정 수준의 퀄리티'라는 것이 주관적일 수 있고, 이 과정에서 다른 문제가 발생하기도 하므로 다른 구성원을 설득시키기 어렵기 때문입니다. 특히 팀의 주요 구성원이 기술적인 이해도가 떨어질 경우 이는 더욱 어려워지기 마련입니다.
제가 생각하는 문제 중심의 사고는 아래와 같은 질문을 제품팀 전원, 나아가 퍼블리 팀 전체가 던지는 것에서 시작합니다.
솔루션 중심의 사고에서 문제 중심의 사고로
• 문제는 존재하는가?
• 문제는 '진짜' 문제인가?
• 문제를 해결할 수 있는 가장 좋은 방법은?
기술로 커리어 시장을 혁신하는 퍼블리!
함께 패러다임을 바꾸고 세상을 뒤집을 동료를 찾고 있어요.
더 자세한 내용이 궁금하다면 아래 링크를 클릭하세요!
