많은 기업들이 개발자 관계(DevRel) 직군을 채용하지만, 명확한 목적 없이 단순히 필요하다는 이유로 고용하는 경우가 많습니다. 이는 종종 실패로 이어집니다. 실제로 한 2018~23년까지 국내에서도 DevRel 직군 채용이 활발했었고 의지를 보이는 기업들이 많았는데 최근 보면 눈에 띄게 줄었습니다. (검색량 추이, 각 회사 블로그글 업로드 추이 등을 보면) 사실 DevRel이라는 직군 자체의 첫 등장은 무척 인상 깊었습니다. 구글 및 아마존 등에서 이를 적극적으로 활용했고 각종 기술행사와 콘텐츠로 개발자들에게 매력적인 회사가 되게 만들어 우수한 인력을 유치하고 그 인력이 다시 또 인력을 유치하는 이런 선순환이 어찌보면 많은 이들이 생각하는 DevRel 이였습니다. 마케팅, 인사채용, 브랜딩, 개발 등 다양한 분야에 발을 걸치고 있는 직군이였습니다. 역으로 말하면 모두 전문은 아닌게 문제이긴 했습니다. 문제는 타이밍이야! 최근 페이스북, 트위터, 슬랙에서 DevRel 팀을 이끌고 최근에 DevRel 외주(?) 회사를 차린 Bear Douglas가 트위터에 DevRel을 언제 채용해야하고, 어떤 일을 수행해야하는지에 대해 글을 썼습니다. 간단하게 요약하면, DevRel의 비즈니스 영향력은 측정 가능하지만, 측정 시스템 구축에는 비용이 들 수 있음 기존 업무(기술 문서 작성, 개발자 지원 등)의 규모가 감당하기 어려워질 때 DevRel을 채용해야 함 DevRel은 조직 내에서 그 목적을 이해하는 리더 아래에 속해야 함 → 회사의 핵심 제품이 개발자 도구일 때는 마케팅 부서에, 생태계 API나 비핵심 제품을 다룰 때는 제품 또는 엔지니어링 부서에 속하는 경우가 많음 DevRel은 회사가 필요로 하는 바에 따라 다양한 역할을 수행합니다. 엔지니어가 문서화에 한계를 느끼면 기술 작가를, 창업자가 해커톤과 밋업 참석이 버거워지면 개발자 지원 담당자를 채용하는 식입니다. DevRel 채용 시 흔한 실수로는 DevRel이 하나의 직무라고 생각하거나, 전략 변화 대신 사람을 문제 삼는 것 등이 있습니다.