개발자는 누구인가?

저는 개인적으로 '엔지니어(Engineer)'를 '개발자'라고 부르는 것을 싫어합니다. 기획자, UX디자이너 등 제품을 개발하는데 관여한 모든 사람이 개발자이기 때문입니다.

 

이 모든 '개발자'들은 각자의 전문성을 가지고 함께 제품 개발을 통해 문제를 해결해야 합니다. 그리고 더 나은 해결책을 만들기 위해 이들을 어떻게든 좀 더 가깝게 붙여놔도 모자란데, '개발자/비개발자라 나누는 구조'는 문제가 있다고 생각합니다. 게다가 사실상 기획자나 UX디자이너를 비개발자라 부르는 것은 완전히 틀린 말이기도 합니다. 

 

물론 관용적으로 또는 말을 줄이기 위해 엔지니어에게 개발자라는 이름을 붙일수도 있는거지... '너무 민감하다'고 보실 수도 있습니다.

그러나
조직에서 역할에 대한 용어는
매우 중요합니다.

수평적인 조직을 만들고자 직위를 없애고, 영어 이름을 쓰며 존댓말을 쓰지 못하게 하는 회사들을 생각해보면 금방 이해가 될 것입니다. 

 

그렇기 때문에 저는 PUBLY에서 '개발자'라는 단어를 가급적 쓰지 않기로 마음먹었습니다. 그리고 이글은 이러한 생각을 이해하는 저와 같은 '엔지니어'분들께 드리고 싶은 이야기입니다.

PUBLY, 미디어 '기술' 회사

제가 이 글을 쓰는 이유 중 하나는 PUBLY는 콘텐츠 중심의 회사이고, 그렇기 때문에 제품팀에서 엔지니어의 역할이 별로 크지 않을 것이라 생각하는 사람이 많기 때문입니다.

아마존(Amazon)의 제프 베조스(Jeff Bezos)는 워싱턴 포스트(Washington Post, 이하 WP)를 인수하고, 지난 2년간 엔지니어를 3배 가까이 늘렸습니다. 그리고 현재 WP는 스스로를 실리콘 밸리의 어느 회사와도 대적할 수 있는 미디어 기술 회사(Media and Technology Company)라 자부합니다. 

* 관련 기사: Bezos takes page from Amazon to push WaPost to future

 

PUBLY 역시
콘텐츠 비즈니스를 혁신하는
국내 최고의 기술 회사로
거듭나고자 합니다.  

저희의 비전에 공감하시는,
능력 있는 많은 분들께서
저희 팀과 함께해주시기를 바랍니다.

엔지니어가 부족하면, 그들의 시간을 아껴주세요.

요즘 대부분의 IT 기업에서는 '항상 엔지니어가 부족하다'는 이야기를 합니다. 그러나 정작 그 부족하다는 엔지니어의 시간을 아끼는 노력은 얼마나 하는지 의문스럽습니다.
 

예전에 참여했던 한 그로스 해킹 관련 세션에서 연사가 스모크 테스트(Smoke Test: 실제 제품을 개발하지 않고 아이디어를 검증하기 위한 테스트, 더 자세한 설명은 이곳에서)에 대해 설명하면서, 반 농담으로 "엔지니어는 바쁘다. 그들의 시간을 아껴주고, 동시에 과연 개발할 가치가 있는 피쳐(Feature)인지 알아보기 위해 테스트를 한다"는 이야기를 한 적이 있었습니다.

지구 상에 새로운 아이디어는 없다는 말처럼, 아이디어는 사실상 넘쳐납니다. 그리고 그것을 구현할 수 있는 것은 엔지니어 뿐입니다. 결국 수많은 아이디어가 그 구하기 힘든 몇몇 사람에게 몰리고, 착한 엔지니어는 그 모든 것을 구현합니다.

이것이 Product Debt,
Technical Debt의 시작입니다.

Product Debt, 제품 부채?

• 반복적인 개발을 통해 제품을 만드는 과정에서 생긴 다수의 기능이 오히려 제품의 Identity나 확장성을 해치는 것

• 제대로 관리/운영되지 않는 기능들로 인해 애초에 의도했던 경험을 사용자에게 주지 못하는 상태 

* 참고 글: Product design debt versus Technical debt

즉, Product Debt이 생기는 이유는 개발하지 말아야 할 것을 개발한 경우와 개발 후 없애야 할 것을 없애지 못한 경우로 나눌 수 있습니다. 전자는 다양한 비용 및 그 성과에 대한 고민 없이 기능은 많을수록 좋다는 생각에 일단 개발하자는 경우입니다. 그리고 후자는 성과가 전혀 나오지 않음에도 불구하고, 이미 시간을 들여 만든 기능을 굳이 없애야겠냐는 생각에 그대로 두는데서 발생합니다.

 

Technical Debt 또한 이와 비슷한 사연을 가지고 시작되지만, 의미하는 바는 조금 다릅니다. 똑같은 제품의 모습을 하고 있더라도 그것을 구성하고 있는 기술적인 퀄리티는 천차만별인 경우가 많습니다. 그리고 이런 기술적인 차이는 잦은 에러율이나 제품의 확장성을 저해하는 결과를 가져옵니다.

 

따라서 '너무 늦지 않게' 기존의 기술적인 퀄리티를 적정 수준으로 고쳐나가는 과정은 필요합니다. 하지만 이런 상태를 판단하고, 추가적인 개발을 한동안 멈추자고 결정하는 일은 쉽지 않습니다. '적정 수준의 퀄리티'라는 것이 주관적일 수 있고, 이 과정에서 다른 문제가 발생하기도 하므로 다른 구성원을 설득시키기 어렵기 때문입니다. 특히 팀의 주요 구성원이 기술적인 이해도가 떨어질 경우 이는 더욱 어려워지기 마련입니다.

 

이전 글에서 이미 밝혔듯 제가 PUBLY에 합류했을 때, 저희 서비스는 마찬가지의 문제를 가지고 있었습니다. 5개월이 지난 지금에서야 하는 말이지만... 원래 PUBLY의 두 Co-founder는 제가 합류한 후, 모바일 앱을 연내 진행하길 원했다고 합니다.

 

그러나 막상 일을 시작해보니 앱은 커녕 한동안은 웹 서비스를 꽤 많은 부분 고쳐야 하는 상황이었습니다. 물론 서비스 런칭까지 험난한 과정을 겪은 PUBLY 팀의 상황을 감안하면 이해할 수 있는 수준이었지만, 이 상태의 웹을 들고 앱까지 런칭하는 것은 기름통을 들고 불구덩이에 뛰어드는 것이라 판단했습니다. 

이후 5개월 간 저희 팀은
Product Debt에서 벗어나
더 좋은 제품을 만들기 위해, 
'문제 중심'으로
PUBLY라는 제품을
꼼꼼히 개선하고 있습니다.

제가 생각하는 문제 중심의 사고는 아래와 같은 질문을 제품팀 전원, 나아가 PUBLY 팀 전체가 던지는 것에서 시작합니다. 관련하여 지난 5개월 간 저희 팀에서 실제 벌어진 일들은 다음 글에서 좀 더 자세히 이야기하겠습니다.

솔루션 중심의 사고에서 문제 중심의 사고로
 

• 문제는 존재하는가?

• 문제는 '진짜' 문제인가?

• 문제를 해결할 수 있는 가장 좋은 방법은?
 

다음 글 바로가기: PUBLY 제품팀, 6개월 간의 변화