DevRel(Developer Relations)는 비교적 최근에 생긴 직업이다. 우리나라도 그렇지만 소프트웨어 개발자 관련한 모든 것이 선진적이라고 생각되는 나라들에서도 DevRel이 왜 필요하고, 뭘 해야하고 그들의 역할을 어떻게 평가받아야 하는지 의견이 분분하다. 이 글에서는 DevRel이 하는 일들을 포괄적으로 설명하고자 한다. 꼭 DevRel이란 이름을 달고 있지 않더라도 DevRel 역할 조직은 아래에 있는 일들을 담당한다.

 

우선, 소프트웨어 회사를 포함해서 모든 회사는 중대한 목표가 있다. 돈을 벌어야 한다. 즉, 매출을 높이고, 영업이익을 늘려야 한다. 세상 모든 회사가 소프트웨어 회사인 세상이 되었지만, 표면적으로 우리는 매출을 만들기 위한 제품을 다음과 같이 구분할 수 있다.

 

  1. 제품 안에 소프트웨어가 들어 있는 경우 (가전, 자동차, ... 만질 수 있는 물건)
  2. 제품 자체가 소프트웨어 인 경우 (게임, 앱, SaaS형 솔루션, 패키지 소프트웨어)
  3. 제품이 다른 소프트웨어나 제품의 일부인 경우 (프레임워크, 라이브러리, ...)
  4. 제품이 어떤 서비스인데, 소프트웨어가 없으면 말이 안되는 경우 (거래, 중계, 예약, ...)
  5. 제품이 소프트웨어 개발 노동 시간인 경우 (SI)

한마디로 모든 회사에서 소프트웨어 개발자는 가장 소중한 인력임에는 틀림없다는 것이다. 제품뿐만 아니라 회사의 가치가 그 회사의 소프트웨어 역량에 의해 좌우되기 때문이다. 그 가치는 (잠재적) 매출과 이익에 의해 결정되고, 개발자가 회사에 존재하는 이유도 그 때문이다. DevRel도 마찬가지이다. 매출을 만들어내는 제품에 따라 DevRel 운영 전략, 활동 내용은 다를 수 있다. DevRel은 영업/마케팅, 비지니스 개발, 제품 개발을 직접 담당하지는 않는다. 하지만, 누가 뭐래도 DevRel의 최종 목표는 밖으로는 자기 제품을 더 많이 사게 하는 것이고, 안으로는 더 좋은 제품을 만들기 위한 훌륭한 개발자를 잘 뽑는 회사가 되도록 하는 것이다. 이 목표를 달성하기 위한 DevRel 활동에는 다음과 같은 것들이 있겠다.

 

  • 제품 또는 핵심 기술을 중심으로 하는 커뮤니티의 구성과 운영 : 제품에 따라 다를 수 있겠지만, 넓게 사용자 커뮤니티라고 보고, 회사 내부의 개발자들이 사용자의 요구를 더 잘 이해하도록 하여, 결국 사용자를 더 늘리는 일. 잘 따져보면 위 분류의 1번을 제외하고는 결국 파는 제품의 겉모습이 소프트웨어이며, 사용자가 내 제품을 이용하여 다른 소프트웨어를 만든 개발자일 가능성도 높다. 그래서 DevRel은 우리 개발자와 우리 제품의 고객이거나 고객이 될 사용자, 그들의 큰 일부인 외부 개발자를 연결하는 통로로서 커뮤니티가 존재하도록 운영을 주도하거나 지원해야한다.
  • 개발자인 사용자에 대한 분석과 지원 : 우리 제품을 사용하는 개발자들에게 필요한 것이 무엇인지를 파악하여 제공할 수 있도록 노력함으로써 사용자를 충성 고객으로 만드는 일. 개발자들은 기술 지원, 교육, 적절한 개발 도구나 환경의 추천 및 지원 및 기능 개선을 끊임없이 요구한다. 소프트웨어 업체인 경우, 기술 지원과 교육은 또 다른 상품으로 매출에 기여할 수도 있다. 훌륭한 커뮤니티 관리가 이 일을 수월하게 만든다.
  • 우리 내부에 대한 메시지 제공 : 모든 조직의 구성원은 이미 만들어진 제품에 대한 관성을 가질 수 있기 때문에 이를 깨뜨리고 혁신을 할 동기를 제공하는 일. 개발자인 우리 고객들이 겪는 기술의 변화, 개발 환경의 변화, 그리고 시장 자체의 변화를 읽어 전달함으로써 우리 제품이 좀 더 많이 채택되거나 적어도 시장 share를 잃지 않도록 하는 수준을 유지하도록 회사 내부를 드라이브 하거나 드라이브할 기초 자료를 제공해야 한다.
  • 회사 인지도 및 인식 개선 : 우리 회사가 좋은 회사 그리고 좋은 개발 조직을 가진 회사라는 것을 알리는 일. 훌륭한 개발자를 우리 회사로 오게 하려면, 우리 회사가 일하기 좋은 회사로 알려져야 한다. 금전적 보상과 복지가 우선되어야 하지만, 일하기 좋은 회사는 좋은 동료, 생산성 높고 창의성을 발휘할 수 있고 성장할 수 있는 개발 프로세스, 도전을 두려워하지 않은 혁신 추구 성향, 개발자를 중시하는 조직 문화가 있는 회사이다. DevRel은 그 내용을 밖에 소개해야 한다. 기술적인 혁신과 그 과정을 사례로 들어, 우리 회사가 고객들에게 어떤 가치를 제공하고 그 과정에서 우리 개발자들이 성장하고, 커뮤니티에도 기여를 했다는 사실을 잘 알리면, 우리 회사에 대한 개발자들의 호감도가 높아진다.
  • 리크루팅 활동 :  외부 개발자들과의 접점에서 개발자들을 모셔오는 일. DevRel은 외부의 개발자 특히 우리 기술과 친한 외부 개발자들을 일선에서 많이 만난다. 그들은 우리 제품을 사용하며, 어떤 경우에는 그 속까지 잘 알기 때문에 우리 회사로 이직 후 아주 빠르게 적응하여 높은 퍼포먼스를 낼 수 있다. 그들에게 공을 들이고 조용히 우리 회사로 올 수 있게 도와준다.
  • 우리 기술의 홍보 : 개발자 커뮤니티에 우리 기술을 효과적으로 홍보하는 일. 개발자 출신 DevRel인 경우에는 직접도 가능하지만, 우리 개발자들로 하여금, 더 나아가 우리 고객들로 하여금 우리 기술 자체의 우월성 또는 우리 기술이 다른 기술과 결합되었을 때 생기는 부가가치, 다른 기술을 우리 서비스에 사용한 사례들 기술적인 내용을 블로그에 쓰거나, 컨퍼런스, 작은 밋업 등을 통해 소개하도록 돕는다. DevRel 관점에서 시니어 개발자, 편집자들의 도움을 받아 글이나 발표의 내용을 정하고, 글을 요청하고 정리한다. 

정리 하면, DevRel 활동은 개발 자체는 말고, 개발자 하면 떠오르는 활동들과 어떤 제품 관련 활동이 있는데 결국 개발자와 관련이 있어보이는 일들을 하는 것이다. 우리 회사의 기술이라는 같은 나무에 내부 개발자들과 외부 개발자들이 손을 올려놓게 하는 일이다.

#매출증가, #사용자기반확대, #혁신동력확보, #사용자지원, #기술홍보, #개발자채용

 

https://unsplash.com/photos/DNkoNXQti3c

DevRel 조직

 

DevRel은 누가하는가? 정해진 것은 없다. 개발자 출신의 DevRel도 있고, HR 출신, 마케터 출신, 아마도 처음부터 DevRel 등 다양하다. 회사가 충분히 크면, 한두명의 DevRel이 회사의 모든 기술을 담당할 수 없으므로 적당한 조직 단위로 DevRel을 둘 수 있다. 꼭 DevRel 포지션이 없더라도 위에 언급한 여러 목표를 달성하기 위해 해당 역할을 누군가는 해야할 것이다. 회사에 별도의 DevRel 조직이 있다면 그 조직에서 회사의 기술을 나누어 담당할 수도 있고 외부와의 관계에서 한 채널, 한 목소리를 낼 수 있는 장점이 있겠다.

 

DevRel 활동 가운데 기술을 전파하는 일은 Tech-Evangelist(또는 Tech-Advocate, Developer Advocate 등 다양)라고도 한다. 오픈소스로 개발이 진행되는 기술인 경우 회사 내부의 기술과 그 변화를 바로 외부에서도 볼 수 있기 때문에, 우리 회사 소속의 해당 기술의 개발자 또는 (개발 역량을 갖춘) DevRel 말고, 해당 프로젝트에 기여하고 있거나 고급지게 사용하는 커뮤니티의 역량이 있는 개발자들에게 Tech-Evangelist 역할을 맡길 수도 있다. 이 경우 다양한 지원을 하고 그지원을 자랑할 수 있도록 도와주어야 한다. 지원에는 여행 경비, 컨퍼런스 참가, 밋업 개최 등 소요 경비의 지원, 발표자 초청, 굿즈 제공, 회사 내부와의 소통 채널의 제공, 미공개 정보들에 대한 접근 권한 제공, Reputation 관리 등 다양하다. 

 

DevRel 조직의 고객은 누구인가? 회사 내부의 개발자와 회사 외부의 개발자이다. 둘 사이에 존재하는 요구와 피드백을 전달함으로써 두 개발자 그룹 모두가 DevRel의 활동에 만족하면 "소프트웨어로 회사의 가치를 높이는 것"이 달성된다.

 

어떤 역량을 가진 사람이 DevRel 담당으로 적합한가? 누가 뭐래도 Communication Skill 이 좋은 사람이 최고다. 그리고 기술적 호기심이 큰 사람, Social 한 사람, 긍정적인 사람, 그리고 애매한 것에 대한 판단과 정리가 빠른 사람이다. (쓰고보니 이런 사람들은 모든 일을 잘할 가능성이 높다.) DevRel 이라는 Career가 성공적이려면 (DevRel 업무를 하는 사람에게나, 조직에서의 존재감 관점에서) 매출을 직접적으로 만들어내지도 않고 정량적인 측정이 잘 안되는 DevRel 활동들을 (가능하면 윗분들이 좋아하는) 정량적인 목표 중심적으로 정리할 줄 알아야 한다. 즉 DevRel 활동이 비용이 아닌 회사로서는 아주 가치있는 투자로 보이게 만드는 능력이 필요하다.

 

DevRel의 구체적인 Action Item:

 

DevRel 활동을 성공적으로 하기 위해 DevRel 활동 별로 실질적으로 해야하는 일은 무엇일까를 나열해봤다. 회사의 상황에 따라, 할 수 없거나, 필요 없는 것도 있고, 활동 별로 중복되는 것도 있고, 회사 내 타 조직과 R&R이 겹치는 부분도 있다. 사내의 다른 조직을 설득하여 협업을 끌어내야 할 일이 많다. 또 외주가 처리해야할 일, 기술역량이 있는 기여자나 자원봉사를 모집해서 해야하는 일도 있다.

DevRel 조직은 당연히 개발 부서의 모든 사람과 친하게 지내야 한다. 바쁜 그들이 시간 내줘야 할 일이 많다. 가장 비싼 몸값의 그들이 효율적으로 일 할 수 있도록 DevRel 활동 프로세스를 정리하는 것이 중요하다. 

 

  • (개발자) 커뮤니티의 구성과 운영 : 커뮤니티 운영 목표의 설정, (페이스북 그룹, 게시판, 슬랙과 같은) 가상의 소통 공간 구성, 운영 규칙 마련, 커뮤니티 홍보, 커뮤니티 활동 참여자에 대한 인센티브 설계, 오프라인 밋업의 기획, 진행, 자원봉사 모집, 커뮤니티 운영 결과의 보고, 개발자 감성 배우기, 예산 담당 조직과 친하게 지내기.
  • (개발자인) 사용자 분석과 지원, 홍보 : 사용자 설문, Focus Group 선정, 인터뷰, 사용자 요구 사항의 정리 및 전달, 매뉴얼/API문서/기술블로그 제작 배포, 동영상 튜토리얼의 제작/배포, 새로운 사용처의 발굴, 뉴스레터, 교육 프로그램의 기획, 초기테스트 그룹 운영, 마케팅 조직과 친하게 지내기.
  • 내부 개발자 동기부여 : 외부 커뮤니티 행사 소개 및 참여 독려, 관련 시장 상황 공유, 타사의 새로운 제품 소개, 내부 뉴스레터 발송, 기획 조직과 친하게 지내기.
  • 회사 인지도 및 인식 개선, 리크루팅 : 관련 이벤트 (외부 커뮤니티 행사, 해커톤 등) 주최/후원, 우리 개발자 인터뷰 및 동영상 올리기, 사내외 개발자 간 밋업 주선, 우리 조직/개발 문화의 외부 소개, 자체 기술의 오픈소스화 추진, 교육기관과의 교류, 우리 개발자를 강사/멘토로 파견, 적극적 개발자 커뮤니티 참여 및 후원, 유력 개발자들과 좋은 관계 유지. 내부/외부 세미나 초청, 채용 프로세스 외부에 알리기, 인사 조직과 친하게 지내기.

DevRel 활동의 백미는 고기

 

ps. 개발자 채용을 원하신다면, 우선 매뉴얼을 읽으시라.

     "이노베이션 아카데미의 '개발자 채용 가이드 북 PDF 다운로드"

*

반응형
Posted by hl1itj
,