개발자 관계 정의하기

점점 더 많은 개발자 서비스 회사가 막대한 자금을 투자하여 자사 제품, 서비스, API 등을 중심으로 자사의 DevRel 팀을 구성하고 있습니다.

그러나 다른 회사들은 DevRel에 대해 다른 이해를 가지고 있습니다. 일부는 전담 “기술 홍보 엔지니어(Developer Advocate)”를 고용하고, 일부는 “기술 전도사(Developer Evangelists)”를 고용합니다. 일부는 DevRel이 “개발자를 대상으로 하는 마케팅 행위”라고 생각하고, 일부는 DevRel을 제품 피드백을 얻고 제품 성공을 홍보하는 핵심으로 간주합니다. 어떤 직무 역할과 활동 형태가 귀사에 가장 적합한지 어떻게 판단할까요? 다른 직함들은 도대체 무슨 차이가 있을까요?

“개발자 관계”가 회사에 무엇을 의미할까요? 이것은 회사의 목표가 무엇인지에 달려 있습니다. 상황을 설명하기 위해 Google과 Twilio의 DevRel 부서의 미션을 인용해 보겠습니다. 하지만 짧은 문장 하나가 DevRel 팀이 실제로 하는 모든 일을 보여줄 수 없다는 점에 주의하세요.

Google

개발자 관계의 역할은 개발자와 회사의 플랫폼 제품, 엔지니어링, 디자인 간의 양방향 소통을 통해 활기찬 제3자 개발자 생태계를 만드는 것입니다.

Twilio

우리의 업무는 개발자가 차세대 놀라운 애플리케이션을 구축하도록 영감을 주고 돕는 것입니다. 이것은 그들이 무엇을 하려고 노력하고 있는지 이해하고, 도구를 안내하고 교육하며, 그들이 성공하도록 돕는 것을 의미합니다.

Google은 “the interface between”이라는 표현을 사용했습니다. 이는 DevRel이 제품 의사결정자와 개발자(즉, 제품 사용자) 간의 양방향 소통 다리를 구축하기를 기대한다는 것을 나타냅니다. Twilio의 태도는 DevRel이 개발자가 Twilio 제품을 사용하도록 돕는 일방적인 “교육적 역할”과 더 유사하다는 것을 나타냅니다.

Michael Mahemoff는 최근 Developer Relations: A Five-Level Maturity Model을 썼습니다. 이 글에서 그는 회사 DevRel 부서 발전의 다른 단계를 설명했습니다. DevRel 부서가 없는 것에서 전략의 가치를 완전히 정량화할 수 있는 것까지.

“본사의 DevRel 전략을 수립하는 방법”의 맥락에서 Michael의 정의를 조정해야 합니다:

없음(None), 회사 내부에 개발자를 지원하거나 개발자 피드백을 수집하는 메커니즘이 없음;
비공식(Informal), 회사 다른 부서가 DevRel의 일부 역할을 담당, PR은 회사 브랜드 향상을 담당, BD는 일부 개발자 지원 작업을 담당, 제품의 전담 개발자도 일부 커뮤니티 연설을 담당;
파트너십(Partnerships), 소중한 파트너와의 관계, 보통 은밀함 (보통 대기업, 새로운 제품 기능을 구축할 충분한 자원 보유);
전도사(Evangelism), 회의, 파트너, 온라인 미디어를 통해 대규모로 회사 제품을 홍보하고 지원;
기술 홍보 엔지니어(Advocacy), 양방향 관계, 제품 개발에 참여할 뿐만 아니라 외부 개발자가 본사 제품을 사용하도록 장려하고 버그 피드백 및 새로운 기능 요청을 수집. 동시에 개발자의 사용 경험을 향상시키는 지원 도구 개발;

위의 분석에 따르면 요약: Twilio는 “기술 전도사” 방식으로 DevRel을 운영하고, Google은 “기술 홍보 엔지니어” 방식입니다.

Michael은 DevRel의 올바른 운영 방법이 회사의 DevRel 프로젝트 목표에 달려 있다고 지적했습니다. 예를 들어, 회사가 단지 브랜드 인지도 향상이나 비용 절감을 위해 소수의 활동에 참여하기를 기대한다면, 해당 회사는 “기술 전도” 방식으로 DevRel을 운영해야 합니다. 제3자 개발자로부터 제품 사용 피드백을 수집하는 것을 우선시한다면, “기술 홍보” 방식을 채택하는 것이 가장 효과적일 수 있습니다.

요컨대, DevRel에 투자하는 것은 회사의 각 비즈니스에 촉진 작용을 합니다. 따라서 전략의 목표가 무엇인지가 특히 중요합니다. Dave McClure의 AARRR 모델은 DevRel 전략의 기초로 사용할 수 있습니다.

그러나 저는 두 가지 수정을 제안합니다:

DevRel이 개발자들의 제품 인지도를 높일 수 있기 때문에, 전통적인 마케팅 관행에 따라 AARRR 약어 앞에 ‘A’를 추가;

DevRel 팀의 일상 활동에서 개발자들의 제품 피드백이 관련될 수 있음을 나타내기 위해 AARRR 약어 뒤에 ‘P’를 추가;

이렇게 하면 새로운 모델이 생성됩니다: AAARRRP 모델. 이것을 단지 DevRel 지표로 간주하는 것보다 DevRel 프로젝트의 잠재적 목표로 간주하는 것이 낫습니다 (‘이러한 지표를 어떻게 측정할지’도 고려해야 하지만, 자세한 내용은 What’s the ROI of Developer Relations 참조):

인지도(Awareness) 제품 플랫폼의 인지도
획득(Acquisition) 등록 수, 다운로드 수, 설치 수
활성화(Activation) 플랫폼 사용 활동도
유지(Retention) 플랫폼 지속 사용, 새로운 기능 사용
수익(Revenue) 플랫폼에 대한 유료
자체 전파(Referral) 플랫폼을 다른 사람에게 알림
제품(Product) 구축 및 제품 피드백 수집 관련

DevRel 일상 운영에는 다양한 활동 형태가 있습니다. 각 유형의 활동은 하나 이상의 DevRel 지표에 해당하며, 하나 이상의 AAARRRP 목표를 실현합니다. 예를 들어:

	문서 작성(참고 사례, 시작 가이드 등)		획득, 활성화, 제품
	라이브러리 개발		활성화, 제품
	빠른 시작 애플리케이션		활성화, 제품
	블로그 게시물(튜토리얼, 팁, 사상 리더십 등)		인지도, 획득, 활성화, 유지
	웨비나		인지도, 획득, 활성화, 유지
	행사 후원(Meetup 후원사, 컨퍼런스 부스 등)		인지도, 획득
	연설(Meetup, 컨퍼런스, 커뮤니티 등)		인지도, 획득
	제품 지원(Zendesk, StackOverflow, 기타 포럼 등)		활성화, 유지, 제품
	사전 기술 논의(전화, 이메일, 지원 등)		획득, 활성화
	전용 포럼(Google Groups, Discourse 등)		활성화, 유지
	Alpha/Beta 프로그램		유지, 제품
	오피스 아워		활성화, 유지
	개발자 피드백 수집		유지, 제품
	회사 채용 돕기		인지도

이러한 행동의 결과를 성공적으로 보장하면 개발자에게 긍정적인 의미를 갖게 되고, 회사의 평판이 향상될 것입니다. 이렇게 하면 “자체 전파”의 가능성이 높아집니다. 하지만 개발자와 회사 간의 이러한 관계는 구축하는 데 시간이 걸립니다.

수익: 분명히 위의 행동에서 생략되었습니다. 수익은 개발자가 제품을 사용하는 정도에 달려 있습니다. 따라서 제품 가격 구조에 매우 의존합니다. 따라서 수익은 위의 목록에 단순히 추가할 수 없지만, 확실한 것은: 일시적으로 수익을 고려하지 않으면 많은 ROI를 가져올 가능성이 있는 활동과 목표 개발자에 더 집중할 수 있습니다.

개인적으로 직함으로 사람을 정의하는 것을 인정하지 않지만, 직함은 회사나 다른 개발자가 DevRel 팀에서 그들의 역할 정의를 반영합니다.

따라서 일반적인 직함을 기반으로 다른 역할이 어떤 활동에 참여하는지 살펴보겠습니다.

기술 홍보 엔지니어(Developer Advocates): 위의 대부분의 책임을 DevRel 업무의 일부로 담당, 특히 제품 또는 유지와 관련된 책임;

기술 전도사(Developer Evangelists): 아마도 사용자 획득 관련 활동에 더 집중, 예: 문서 작성, 블로그 게시, 행사 후원, 연설. “인지도”와 획득 관련 활동 더보기.

| 요약

DevRel을 어떻게 정의할까요? 그리고 어떤 방식이 귀사에 가장 적합할까요? 다음은 제 제안입니다:

AAARRRP 모델에 따라 DevRel 팀에 기대하는 목표를 수립;
이러한 목표와 가장 일치하는 활동 형태 선택;
이러한 활동 형태에 따라 기술 홍보 엔지니어(Developer Advocates) 또는 기술 전도사(Developer Evangelists)를 모집할지 결정;

또 다른 방법으로, 적어도 제안으로서. 직함에 대한 지속적인 논쟁에 대해 DevRelOMeter 프로젝트를 만들었습니다 - DevRel 팀이 수행할 활동 유형에 따라 기술 전도 또는 기술 홍보를 할지 제안합니다.