내가 생각한 DevRel과 실제 모습 (멘티의 솔직한 의견)
Source: Dev.to
몇 주 전이라면, 누군가가 “DevRel”이 무엇을 의미하는지 물었을 때 저는 눈을 가늘게 뜨고, 미소를 지으며 자신감 있게도 대답하지 못하는 말을 했을 겁니다. 오늘은 제가 DevRel 멘토링 프로그램에 참여하고 있기 때문에, 저에게 그 지식의 격차를 메워준 방식대로 여러분에게도 그 차이를 메워드리겠습니다.
“이전” : 내가 생각했던 DevRel
내가 Developer Relations (DevRel) 라는 용어를 처음 들었을 때, 내 뇌는 대부분의 뇌가 하는 대로—두 단어를 잡아 대충 짐작을 만들었습니다. 하지만 정확히는 아니었죠.
또한 나는 이것이 기본적으로 기술 인플루언서가 되는 것이라고 생각했습니다: 트위터/X에 글을 올리고, 브랜드 후디를 입고 행사에 나타나며, 모두에게 우리 회사 제품이 얼마나 대단한지 알리는 사람. 마케팅과 치어리더 역할을 절반씩 하는 느낌이었습니다.
“During”란? DevRel이 실제로 의미하는 바
DevRel은 개발자를 위한 도구를 만드는 기업과 그 도구를 실제로 사용하는 개발자 사이의 다리 역할을 합니다.
이렇게 생각해 보세요: 한 기업이 정말 강력한 주방 가전을 만들었지만, 그 가전을 어떻게 쓰는지 알 수 있는 사람은 전문 셰프뿐입니다. 그 가전은 가치가 제대로 전달되지 않아 실패하게 됩니다—품질이 나빠서가 아니라, 아무도 어떻게 활용해야 할지 모르기 때문이죠. DevRel은 요리책을 쓰고, 요리 교실을 열며, 셰프들이 버튼에 대해 불평하는 것을 듣고, 엔지니어에게 “이 버튼을 바꿀 수 있을까요?”라고 전달하는 팀입니다.
기술 분야에서 그 “가전”은 보통 API, SDK, 혹은 개발자 도구를 의미합니다. “셰프”는 전 세계의 소프트웨어 개발자들입니다. DevRel은 양쪽이 실제로 연결될 수 있도록 하는 기능입니다.
“두 세계를 동시에 살아보지 않으면 진정한 다리를 놓을 수 없습니다. 코드를 한 번도 써보지 않았다면 제품의 어느 부분이 혼란스럽고, 고장 나며, 마법 같은지 알 수 없습니다. 개발자와 대화는 할 수 있어도, 그들과 함께 말할 수는 없습니다.” — 멘토, 첫 세션
DevRel의 세 가지 C
- Code – DevRel 담당자는 직접 무언가를 만듭니다. 제품을 직접 사용하고, 데모 앱을 배포하며, 샘플 코드를 작성하고, 실제 개발자들이 겪는 마찰을 체험합니다. 이것이 그들이 발언권을 얻는 방법입니다.
- Content – 제품을 학습 가능한 형태로 바꿉니다: 문서, 튜토리얼, 블로그 포스트, 영상, 라이브 스트림, 컨퍼런스 발표 등. “[tool]으로 X 하는 방법”을 구글에 검색했을 때 이해하기 쉬운 가이드를 찾았다면, 그것은 아마 DevRel이 만든 작업일 겁니다.
- Community – 개발자들이 모이는 곳에 나타납니다: 해커톤, 밋업, 컨퍼런스(예: DevFest Lagos), Discord 서버, Twitter/X Spaces 등. 여기서는 판매가 목적이 아니라, 듣고, 가르치며, 진정한 관계를 구축하는 것이 목표입니다.
“After”: 실제로 시작하는 방법
나는 아직 이 문제를 완전히 해결했다고 가장하지 않을 것이다. 멘토십 프로그램에 합격한 상태로, 나는 이제 막 시작 단계에 있다. “시작하기”가 실제로 어떻게 보이는지 아래에 정리했다:
- 먼저 개발자가 되기 – 선택 사항이 아니다. 개발자를 옹호하려면, 초급 수준이라도 내가 먼저 개발자가 되어야 한다. 코드는 모든 것이 서 있는 기반이다.
- 이미 하고 있는 사람들에게 배우기 – 내가 밀접하게 지켜보고 있는 몇몇 사람들(그들의 블로그, 강연, 오픈소스 기여를 팔로우한다).
- 스스로를 드러내기 – 이 블로그 포스트가 바로 그것이다. 공개적으로 글을 쓰는 것은 콘텐츠를 연습하고, 설명하는 법을 배우며, 동시에 피드백을 초대하는 최고의 방법 중 하나다. (이것이 내가 연습하고 있는 것이다.)
경력 경로에 대한 간단한 안내
DevRel은 단일 직무가 아니라 여러 역할이 모인 가족과 같습니다. 다음과 같은 역할 중 하나에 전문성을 가질 수 있습니다:
- Developer Advocate
- Technical Writer
- Community Manager
- Developer Experience (DX) Engineer
- DevRel Engineer
일부 역할은 코드에, 일부는 콘텐츠에, 또 일부는 사람에 더 초점을 맞춥니다. 단일 사다리가 없기 때문에 처음엔 위압감이 들 수 있지만, 이를 받아들이면 자유로워집니다.
그래서… 당신은 이것에서 무엇을 얻었나요?
만약 당신도 개발자이고 DevRel이 자신에게 맞는지 궁금하다면, 가르치는 것을 좋아하고 눈에 띄는 것을 개의치 않는다며 충분히 맞을 수 있습니다.
이 글은 DX 멘토십 프로그램을 통한 저의 여정의 일부입니다. 배우는 대로 더 많은 글을 쓸 예정이니, 함께 따라오시거나 댓글에 읽기 전 DevRel에 대해 어떻게 생각했는지 공유해 주세요. 답변을 모으고 있습니다! 🥑