우리는 이 모든 것을 DevRel이라고 부르기로 했어요

Developer Relations 의 확장

*이 글은 제가 함께하고 있는 DevRel 담당자들의 유튜브 채널 멀티탭 "1년 만에 돌아왔습니다. DevRel 담당자들의 근황!" 영상을 촬영하면서 옆길로 샌 지구,짜구,구구 그리고 파구(=문스카이)의 대화를 아주 개인적인 기준에 따라 일부 요약 및 확장 내용입니다.

DevRel 담당자들이 만나 네트워킹을 하는 자리에서 늘 나왔던 이야기 몇가지가 있는데,

1. DevRel을 잘한다는게 뭐냐 (성과 측정이 가능하긴 하냐) 

2. DevRel담당자 10년하면 뭐가 될까 (전문성이 있긴하냐) 

3. 회사 어려워지면 가장 첫번째로 잘리지 않겠냐

4. 이직이 가능하긴 하겠냐. 퇴사하고 싶을 때 우리끼리 회사 돌려막기 해야하는거 아니냐 (ㅋㅋㅋ)

지난 글에서 3년 반, 함께 자라다로 회고한 시간을 돌이켜보면 제가 한 회사에서 DR 담당자로 여러 경험을 하하는 동안 Developer Relations 또한 여러 방면으로 확장되었습니다. 

최근엔 Developer Relations의 분야가 확장되었다는 걸 현장에서도 느낄 수 있는데, WWCode 공식블로그에서 Olivia 님이 번역하신 글에서 DevRel의 새로운 정의를 찾을 수 있었습니다.

"DevRel은 기술 영역에 한정되며, 개발자 관계 및 기술 커뮤니티와, 우리가 일하는 회사와 제공하는 서비스 간의 관계에 초점을 맞추는 영역입니다."  WWCode 공식블로그, "New Relic의 Pachi Parra가 DevRel을 소개합니다."

이 내용을 저의 경험과 이해를 기반으로 다시 풀어 쓰면, "Developer Relations 담당자들은 개발직군에 속한 사람들이라는 공통 분모를 두고 A와 B를 잇는 사람들이다." 가 되는데요, A와 B라는 변수에 들어갈 수 있는 것들은 내/외부 개발자, 교육자, 수강생, 프로덕트, 기술조직, 시장 등등 처럼 무궁무진합니다. 

예를들면, 

1. 개발자를 고객으로, 상품/시장을 잇다. (프로덕트 마케팅-프로덕트 브랜딩)

2. 외부 개발자를 구성원으로, 개발조직을 잇다. (탤렌트 마케팅-기업/조직 브랜딩)

결과적으로 회사 또는 조직이 가지는 목적에 따라 변수인 A와 B가 다르게 설정되고, DevRel 담당자의 책임과 역할이 "마케팅","브랜딩","채용" 이 3가지 영역이 어느정도의 비율로 섞여져 설정됩니다. 

현업에서 DevRel 담당자로 일하면서 제가 하는 일을 소개할 때, HR, Sales 혹은 Marketing의 직무에 빗대어 설명하곤 했습니다. 퇴사 후 한 발자국 떨어져 Developer Relations을 다시보니 이를 이해하기 위한 (혹은 이해시키기 위한) 접근 방식이 달라져야 할 것 같습니다. 

Developer Relations을 하나의 직무로 볼 것이 아니라 특정한 목적을 가지고 행하는 다양한 활동으로 보는게 맞을 것 같습니다. 따라서 회사별로 목적에 맞게 조직의 책임을 설정하고 담당자는 이를 기반으로 스스로의 역할을 이해하며 정의해가야 한다고 생각합니다.