Developer Relation은 무엇인가?

최근 들어 IT 회사와 제품에 대해 개발자와 커뮤니티가 상호 소통을 통해 지속적으로 좋은 관계를 구축하는 일은 Developer Relation (DevRel), 소위 “개발자 관계 활동”에 대해 관심을 가지는 곳이 늘어나는 것 같습니다. 얼마 전 김범준 CTO님이 올리신 우아한형제들의 Developer Relations을 읽어보면, “개발자들을 대상으로 기업을 설명하고 홍보하여 좋은 개발자 분들이 같이 할 수 있는 기회”를 얻기 위한 활동으로 정의하고 있는데요. 실제로 우리 나라에서는 개발자용 제품을 만드는 곳이 많지 않기 때문에 회사에 “개발자 채용”을 목적으로 하고 있는 곳이 많습니다.

하지만, 해외에서는 개발자들이 사용하는 제품 및 서비스에 대한 전도 활동 (Evangelism)에 더 집중해 왔고, 기업 내에서 중요성과 활동 범위, 일하는 직군도 상당히 세분화 되고 있습니다. 오는 7월에 도쿄에서 열리는 DevRel Tokyo 2018 행사에 발표 요청을 받은 김에, 국내에서는 아직 생소한 DevRel에 대해 좀 더 알아보겠습니다.

DevRel의 기원, 테크 에반젤리즘
DevRel은 최근에 만들진 용어지만, 그 기원은 꽤 오래되었습니다. 글로벌 IT 기업들은 전통적으로 “테크 에반젤리스트 (Tech Evangelist)” 조직을 가지고 있습니다. 기술적인 호기심이 많고, 직접 써보고 믿음이 들지 않으면 사용하지 않는 소프트웨어 개발자의 특성을 고려하여, 개발 배경을 가지고 있는 분들이 강연이나 블로그, 소셜 미디어를 통해 기술을 전도하는 직업입니다.

예를 들어, AWS에는 애플리케이션 개발 및 구축을 위한 다양한 서비스(API)를 가지고 있는데, 아무리 회사가 커서 직원이 많아도 수십 혹은 수백만 개발자를 모두 지원하기는 곤란합니다. 따라서, 각 개발자들이 직접 해보면서 배우는 핸즈온 (Hands-on) 혹은 셀프 서비스 (Self-service)를 하게 해야 합니다. 이를 위해서는 소수의 에반젤리스트들이 일당백으로 개발자를 도와야 합니다. 우리가 만드는 서비스들도 확장성(Scaling)이 중요한데, IT 제품의 서비스 확장을 맡고 있는 역할이라고 보시면 됩니다.

제가 처음 테크 에반젤리즘을 접하게 된 것은 2006년에 열린 Web 2.0 기술 컨퍼런스에서 당시 아마존웹서비스(AWS) 에반젤리스트인 제프 바(Jeff Barr)를 만나서 부터입니다. 벌써 12년 전 일이네요. 주로 닷넷이나 자바 같은 SW 플랫폼에서 웹 기반 API 에반젤리즘으로 변화하는 시점이었구요. 덕분에 테크 에반젤리즘 자체가 소수 SW 플랫폼 제공자에서 다수의 IT 회사로 확산된 계기가 되었습니다.

이에 영감을 받아 국내 기업으로서는 사실상 처음으로 Daum에서 테크 에반젤리즘 부서를 만들기도 하였습니다. 개인적으로 해왔던 Mozilla 같은 오픈소스 및 웹 표준 커뮤니티 활동이 영향을 미쳤던 것 같습니다.

테크 에반젤리스트라는 직업에 대한 좀 더 자세한 것은 아래 글을 참고해 보시기 바랍니다.

DevRel 부서에서 일하는 업무 직군은 ?
과거 테크 에반젤리즘이 개발자 관계 활동으로 변화하게 된 것은 아무래도 이에 종사하는 분들이 많이 늘어나고 있다는 반증입니다. 테크 에반젤리즘은 필연적으로 개발자들이 보는 기술 문서를 만들고, 기술 행사를 통해 전달하고, 개발자 커뮤니티와 연계하거나, 외부 행사를 스폰서쉽으로 확장할 수 밖에 없습니다. 그러다 보니 테크 라이팅, 마케팅 등이 접목될 수 밖에 없게 되어 다양한 직군이 모여들게 되면서 범위가 확대되고 있습니다.

아래는 현재 DevRel에 해당하는 일하는 대표적인 직군입니다. Grassdore나 Indeed 같은 곳에서 직군을 검색해 보시면, 다양한 기업의 직무 소개서 (Job Description)을 볼 수 있구요. 어떤 분들을 찾고 있는지 자세하게 살펴 보실 수 있습니다.

  • Developer Advocate – 기존 테크 에반젤리스트와 같은 업무로 제일 많습니다. 전통적인 에반젤리즘이라는 용어 자체가 종교적 전도라는 개념을 포함하고 있는데다, 특정 국가에서는 반감을 가지기도 합니다. 또한, 용어 자체가 개발자의 피드백을 제품팀에 제공하는 양방향 업무임에도 불구하고, 일방향 홍보처럼 느껴지기 때문에 개발자 관점의 지지자(Advocate)라는 관점에서 직군명이 확산되기 시작했습니다. 요즘은 테크에반젤리스트 보다 이 용어를 많이 사용하는데 업무는 비슷합니다. (직무 소개서 참고)
  • Developer Marketing Manager – 회사 제품을 개발자 대상으로 홍보하는 마케팅 업무를 하는 분들 입니다. 주로 개발자 행사를 기획하고, 진행하고 결과를 측정하는 분들입니다. 일반적인 이벤트 마케팅 출신 분들이 많고, 개발자층이 두터운 미국, 영국, 호주, 인도 등에 주로 많이 뽑고 있습니다. (직무 소개서 참고)
  • Developer Community Manager – DevRel 활동은 필연적으로 개발자 커뮤니티와의 관계를 잘 정립하는 것이 중요합니다. 커뮤니티의 리더들과 소통하면서 어떤 부분이 필요하고, 어떤 도움을 줄지 이야기하고 지원 프로그램을 만드는 분들입니다. 커뮤니티 활동을 왕성하게 하는 분들을 선정하는 MVP (MS Valuable Professional), Google Developer Expert (GDE), AWS Hero 같은 제도를 만들고 지원하기도 합니다. 대개 전 세계적인 프로그램으로 운영하기도 하지만, 간혹 개발자층이 두터운 곳에서는 지역 전문가 프로그램을 만들기도 합니다. (직무 소개서 참고)

DevRel은 어떤 일을 하고 어떻게 성과를 측정하는가?
DevRel 업무 자체가 각 회사에서 일당백 혹은 워낙 소수 인원들이 일하다 보니, 다른 회사들이 어떻게 하고 있는지, 이 업무에 대해서 어떻게 확장할 수 있는지 어려움임 많습니다. 특정 기술의 초기 단계에는 항상 커뮤니티가 형성되는데, DevRel도 예외가 아닙니다. DevRel에 종사하는 분들이 정보를 서로 공유하는 DevRel.net이라는 곳이 만들어져 있고, 매년 DevRelCon이라는 행사도 개최합니다. (샌프란시스코, 도쿄, 런던 등에서 진행하고 있습니다.)

DevRel.net에서 매년 DevRel 업무 종사자들에게 설문 조사를 통해 현재 상태를 정리해서 DevRel Survey를 매년 하고 있습니다. 이 문서를 보면 어떤 분들이 어떤 일을 하는지 어느 정도 파악할 수 있습니다. (Update. 2019년2020년)

출처: DevRel Survey 2018

이미 알다시피, 개발자 행사 및 소셜 미디어, 커뮤니티 밋업, 블로그 및 동영상 같은 콘텐츠 채널을 활용해서 개발자와 소통하고 피드백을 듣는 일을 하고 있습니다. 의외로 1:1 미팅, 파트너사 지원 같은 확장성이 낮은 방법이나, 확장성은 높으나 광고나 언론 홍보 같은 개발자 타겟을 하기 어려운 부분은 우선 순위가 낮거나 효과적이지 않은 것을 볼 수 있습니다.

그렇다면, DevRel 업무의 성과를 측정하는 방법은 어떤 게 있을까요? 이게 바로 DevRel Tokyo 2018 행사에서 제가 요청 받은 발표 주제입니다. 앞으로 발표 내용을 공유해 드릴 기회가 있겠지만, 제가 과거에 해왔던 Daum API 측면에서 봤을 때 KPIs for APIs라는 부분을 많이 참고하고 싶습니다.

출처: KPIs for APIs 및 DevRel Survey 2018

왼쪽은 프로그래머블웹에서 다양한 API 제품을 개발자에게 확산하고 이에 대한 사용량을 어떻게 매출로 연결 시킬 수 있는지, 단계별로 어떤 성과 측정을 하는지를 보여주고 있구요. Google API팀에서는 이에 대한 자세한 측정치를 가지고 있기도 합니다. 제가 Daum에서 일할 때도, 비슷하게 결과를 측정했습니다. 오른쪽에서 보시다시피, 실제로 DevRel 보고서에서도 서비스 사용량을 가장 많이 측정한다고 응답하고 있습니다.

출처: 다음 오픈 API 사용량, 월 3억건 넘다!

다만, 매출로 연결되는 것은 직접적인 영업 활동, 고객 기술 지원 등 다양한 요소가 결합되어 있기 때문에 DevRel 부서에서 우선 순위는 낮은 편입니다. 기존의 프리세일즈나 마케팅 활동은 유사하지만 직접적인 매출을 이끌어 내는데까지 가는 반면에, DevRel은 대상이 개발자 수요층 확대라는 측면에서 타겟이 다르다고 볼 수 있네요.

DevRel을 처음 시작하려면 어떻게 해야 하나요?
저의 경험을 기초로 보면, 우선 DevRel이 회사에 어떤 도움을 줄 수 있는지 경영진을 설득하는게 관건입니다. 회사 개발 문화나 홍보를 통해 개발자 채용에 도움을 죽거나, 현재 제품 이나 서비스 사용량을 늘이거나… 어떻게든 경영진이 이러한 필요성을 인식해야 합니다. 다만, 본 업무의 필요성을 증명하는 많은 사례가 있기 때문에 이 글만 보여줘도 될듯 합니다.

거의 대부분 회사들이 이들 업무가 일당백 혹은 소수의 팀으로 구성되기 때문에 우선 사내의 개발자들의 이야기를 먼저 듣고, 도움을 받아야 합니다. 작게는 내부 API를 외부로 공개하거나, 샘플 코드 및 문서를 만드는 일, 블로그를 쓰는 일도 사내 개발자들의 인식 전환이 필요하죠. 작은 규모의 개발자 밋업이나 외부 행사 발표에도 사내에 실력있는 개발자들의 참여는 필수적입니다. 이들을 설득하는데는 아무래도 같은 개발자 출신이면 좋기 때문에 초기 멤버들은 가급적 소통 능력이 좋은 개발 경력이 있는 분이면 좋을 것 같습니다.

대형 글로벌 IT 기업은 개발 배경을 가진 테크 에반젤리스트나 디벨로퍼 애드보케이트를 직접 채용을 하기도 하구요. 규모가 커지면 위에서 살펴본 다양한 직군이 추가됩니다. 따라서, 경영진에게 DevRel 필요성을 인식시키는 것 부터, 사내에 DevRel의 중요성을 인식 시키고 사내 개발자의 참여를 유도하고, 궁극적으로 외부 개발자를 우한 부서를 만드는 것 까지 순차적으로 하는 것이 필요할 듯 하네요.

혹시 DevRel에 관심 있는 분들을 위해서 페이스북에 그룹을 하나 만들었습니다. 관심있는 분들은 한번 들어와 보시면, 국내에 계신 분들과 다양한 이야기를 나눌 수 있을 듯 합니다. 더 관심 있는 분들은 저의 에반젤리즘 활동 블로그 목록을 보셔도 좋겠고, AWS 클라우드 에반젤리즘 글 목록을 참고하셔도 됩니다.

국내에서도 더 많은 분들이 DevRel에 관심을 가지면 좋을 듯 하네요.

Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)

- ;

여러분의 생각 (2개)

  1. 진우 댓글:

    오호 간만에 차니님이 하고 있는 일에 대해 들을 수 있는 기회여서 좋네요. 앞으로도 데브렐에 대한 다양한 이야기 나눠 주시면 좋겠어요. 개발자들에게 필요하면서도 어떤 점에서는 기술 홍보라는 반감을 가지고 있는데… 이 두 가지 인식차를 어떻게 균형을 맞출 수 있는지도 궁금하네요.

  2. 구독자올림 댓글:

    에반젤리스트와 devrel에 대해 자세히 이해하게 됐네요. 글 속에 좋은 링크가 많아서 읽는 시간이 계속 늘어나는 단점이 ㅎㅎ