해봄의 아카이브
DevRel을 채용해야하는 시기, 그리고 하면 안되는 조직
Haebom
많은 기업들이 개발자 관계(DevRel) 직군을 채용하지만, 명확한 목적 없이 단순히 필요하다는 이유로 고용하는 경우가 많습니다. 이는 종종 실패로 이어집니다. 실제로 한 2018~23년까지 국내에서도 DevRel 직군 채용이 활발했었고 의지를 보이는 기업들이 많았는데 최근 보면 눈에 띄게 줄었습니다. (검색량 추이, 각 회사 블로그글 업로드 추이 등을 보면)
사실 DevRel이라는 직군 자체의 첫 등장은 무척 인상 깊었습니다. 구글 및 아마존 등에서 이를 적극적으로 활용했고 각종 기술행사와 콘텐츠로 개발자들에게 매력적인 회사가 되게 만들어 우수한 인력을 유치하고 그 인력이 다시 또 인력을 유치하는 이런 선순환이 어찌보면 많은 이들이 생각하는 DevRel 이였습니다. 마케팅, 인사채용, 브랜딩, 개발 등 다양한 분야에 발을 걸치고 있는 직군이였습니다. 역으로 말하면 모두 전문은 아닌게 문제이긴 했습니다.
문제는 타이밍이야!
최근 페이스북, 트위터, 슬랙에서 DevRel 팀을 이끌고 최근에 DevRel 외주(?) 회사를 차린 Bear Douglas가 트위터에 DevRel을 언제 채용해야하고, 어떤 일을 수행해야하는지에 대해 글을 썼습니다. 간단하게 요약하면,
1.
DevRel의 비즈니스 영향력은 측정 가능하지만, 측정 시스템 구축에는 비용이 들 수 있음
2.
기존 업무(기술 문서 작성, 개발자 지원 등)의 규모가 감당하기 어려워질 때 DevRel을 채용해야 함
3.
DevRel은 조직 내에서 그 목적을 이해하는 리더 아래에 속해야 함 → 회사의 핵심 제품이 개발자 도구일 때는 마케팅 부서에, 생태계 API나 비핵심 제품을 다룰 때는 제품 또는 엔지니어링 부서에 속하는 경우가 많음
DevRel은 회사가 필요로 하는 바에 따라 다양한 역할을 수행합니다. 엔지니어가 문서화에 한계를 느끼면 기술 작가를, 창업자가 해커톤과 밋업 참석이 버거워지면 개발자 지원 담당자를 채용하는 식입니다. DevRel 채용 시 흔한 실수로는 DevRel이 하나의 직무라고 생각하거나, 전략 변화 대신 사람을 문제 삼는 것 등이 있습니다.
좋은 DevRel 팀원은 상호 보완적 역량을 갖추고, 커리어 목표와 조직의 니즈가 잘 맞아야 합니다. 예컨대 제품 중심 업무라면 개발자 지원보다는 제품 지향적 인재를, 아웃리치가 중요하다면 교육 콘텐츠 제작과 확산에 열정적인 인재를 뽑는 게 좋겠죠.
테크니컬 라이팅의 경우 그들이 쓴 글을 읽어보고, 쓰기 과정에 대해 질문하는 것이 검증에 도움됩니다. 신규 콘텐츠 외에도 문서 구조 개선, 문서화 시스템 구축, UX 개선, 스타일 가이드 제작 등 이 직군이 맡을 만한 일은 많습니다. 다만, 대부분 음 어느정도 기술문서와 콘텐츠 정도만 뽑고 필요 없다는 식으로 미뤄놓습니다. (외주로 돌리는 경우를 많이 봤습니다.)
사실 주변에 DevRel 하시는 분들 중에 영상편집까지도 하는 경우도 무척 많이 봤습니다. 완전한 올라운더....
이럴거면 채용을 할 이유가 없...
이런 경우가 대표적으로 DevRel의 존재 이유를 모를 때, 벌어지는 일입니다. DevRel의 소속은 DevRel을 잘 이해하고 지원하는 조직이 좋습니다. 마케팅은 예산이 크고, BD는 목표가 분명하며, 엔지니어링은 채용과 급여 면에서 유리합니다. 하지만 무엇보다 리더의 지원과 이해가 중요합니다.
개발자 인플루언서는 특정 분야를 폭넓게 교육하거나, 제품으로 멋진 것을 만들어내는 방식으로 영향력을 얻습니다. 기존 팔로워보다는 제품의 잠재력을 보여줄 수 있는 인재를 채용하는 게 좋습니다.
DevRel의 성과 측정은 어렵지만 불가능하지 않습니다. 개별 프로젝트 차원의 성공 지표를 활용하면 측정이 용이합니다. 우수인재 유치, 개발자들의 자발적 프로젝트 참여, 그리고 온/오프라인 행사를 통한 구매 전환 등이 그 예겠죠.
결국 DevRel의 가치를 입증하려면 팀원 각자가 회사 성공에 필수적인 일을 맡는 것이 중요합니다. 새로운 제품 출시에는 문서화, 샘플 코드, 고객/파트너 관리 등이 반드시 필요하니까요. DevRel이 없어서는 안 될 존재가 된다면 조직 내 위상은 저절로 높아질 것입니다.
마치며
DevRel은 무척 어려운 직군입니다. 최고 책임자 혹은 리더의 신뢰와 지지가 없으면 애초에 운영자체가 안되고 구성원들이 이걸 해야하는 이유가 설득이 안되어 있을 경우 운영자체가 어려워 지는 경우가 많습니다. DevRel의 특성상 혼자서 할 수 있는 업무가 무척 적기에 이런 점은 더 그렇습니다. 구성원들에게 문서, 발표, 강의 등을 요청하려해도 그들이 그것에 필요성을 못 느끼면 DevRel도 할 수 있는게 별로 없습니다. 그럼 당연히 DevRel 성과도 떨어지겠죠.
개인적으로 DevRel은 전체적인 PM이고 CEO, CTO 등이 DevRel 활동에 대한 믿음을 보이고 꾸준한 지원과 구성원들의 적극적 참여를 유도 하는게 핵심이기에 어찌보면 "우리 조직에 DevRel이 필요해"라는 확실한 확신이 없을 때 DevRel을 채용하여 모두가 힘들어지는 경험만 피하면 좋을 것 같습니다. 다 잘되자고 하는 일인데 귀찮아하면 하는 사람 입장에서도 하기 싫어지잖아요.
사족
한편으론 왜 DevRel이 부상했다가 사라졌는지를 생각해보아야 한다고 생각합니다. 분명 누군가는 "불필요"하다고 느껴서 예산을 줄인다던지 조직개편으로 섞어버린다던지 하면서 축소된 걸 텐데 ... 왜 그들은 그런 결정을 내리게 되었을까요? 최근 국내에서 Toss나 몇몇 회사에서 다시 DevRel이 준동하려는 걸 보면서 다시 웨이브가 오기 전에 한 번씩 생각해보고 더욱 풍성하고 재미있는 DevRel 생태계가 만들어지면 좋겠습니다.
Subscribe to 'haebom'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'haebom'!
Join Slashpage and subscribe to 'haebom'!