[WWCode공식 블로그 번역 #13] New Relic의 Pachi Parra가 DevRel을 소개합니다.

oliviha
wwcodeseoul
Published in
15 min readJul 31, 2022

--

본 글은 Women Who Code 공식 블로그에 게재된 글을 Women Who Code Seoul 운영진이 커뮤니티를 위해 한글로 번역 및 발행하였습니다. 원본 글은 여기에서 읽으실 수 있습니다.

안녕하세요. 저는 Pachi라고 합니다. 오늘 저는 Developer Relations(줄여서 DevRel로 통일해 언급할 예정입니다)이 무엇인지 말씀드리려고 합니다. DevRel에 대해 들어보셨을 수 있지만 그것이 무엇인지 확실히 이해하지 못하셨을 수도 있고, 알고 있으셨다고 해도 뭔가 개발과 관련된 것이다 정도여서 프로그래머로서는 DevRel에 대해 궁금증을 가지고 계셨을 수도 있을 것 같아요.

그래서 오늘 저는 DevRel이 무엇인지와 DevRel이 어떻게 개발자 커뮤니티를 풍성하게 하는지에 대해 말씀드리고, 여러분이 직업으로서 DevRel을 해볼까 하는 결정을 내리는 데 있어 도움이 되는 내용을 말씀드리려고 합니다.

저는 Pachi라고 하고 인터넷 상에서는 Pachi Codes라는 이름으로 알려져 있어요. 전에는 New Relic에서 DevRel 엔지니어로 일했으며, 현재는 실시간 스트리밍 방송을 하는 스트리머(streamer)이자 기술 콘텐츠를 만드는 브라질 여성과 논바이너리(non-binary: 젠더이분법에 의해 규정받기를 거부하는 사람들)의 커뮤니티인 페미니스트 테크(Feminist tech)의 공동 설립자이기도 합니다. 저는 또한 엄마이기도 하고, 커뮤니티를 사랑하는 사람이죠. 커뮤니티는 제가 프로그래밍을 시작하게 했던 계기고 매일 아침 제가 기분 좋게 일어나는 이유이기도 합니다.

오늘 저는 DevRel을 담당하는 사람들의 다양한 업무 뿐만 아니라, 제가 어떤 커리어 여정을 지나왔고, 어떻게 DevRel을 알게 되어 시작하게 되었는지에 대해 알려드리고자 합니다. 그리고 만약 이 직무에 관심있는 분들에게 도움이 될 몇 가지 조언도 드릴게요.

What is DevRel?

먼저, DevRel을 어떻게 정의내릴 수 있을까요?

간단히 말해, DevRel은 기술 영역에 한정되며, 개발자 관계 및 기술 커뮤니티와, 우리가 일하는 회사와 제공하는 서비스 간의 관계에 초점을 맞추는 영역입니다. 외부향으로 일하는 DevRel 업무의 몇 가지 유형이 있습니다. 예를 들어, 저는 New Relic에서 일하고 있고, 제 일의 일부는 사람들에게 제가 존재한다는 것을 알리는 것입니다. 하지만 DevRel의 초점은 그것뿐만이 아닙니다. 우리의 진짜 임무는 회사 내부의 개발자들과 협력하여 그들이 행복할 수 있도록 만드는 것입니다.

DevRel은 커뮤니티와 여러분이 일하는 회사 사이 일종의 다리입니다. 커뮤니티에 가서는 저는 회사를 대표하고, 회사에서는 커뮤니티를 대표합니다. 그래서, DevRel 담당자는 항상 그 둘 사이에 있지만, 종국에 여러분은 한쪽으로 약간 치우쳐야 하고, 그 한 쪽을 선택해야 한다면 바로, 개발자의 편이 되는 것이죠.

DevRel은 여러분이 들어봄직한 다양한 직군들 — 가령 커뮤니티매니저, DX(개발자 경험 관리), 디벨로퍼 애드보캇(developer advocate), 테크니컬 에반젤리스트(technical evangelist), 테크니컬 라이터(technical writer), 데브렐 엔지니어(developer relations engineer) — 을 아우를 수 있는 큰 개념입니다. DevRel이라는 타이틀이 그 역할을 구체적으로 무엇인지를 분명하게 보여주지 않는 경우가 있어 DevRel이라는 이름만으로 어떤 영역인지를 묶기는 다소 어려울 수 있습니다. 하지만, 여러분은 그들이 DevRel의 산하에 있다는 것을 통해 그들의 업무에 대한 이해도를 높일 수 있을 것입니다.

사람들은 종종 DevRel을 뭔가 새로운 것으로 생각하지만, 그렇지는 않습니다. DevRel이라는 이름 자체가 생겨난 건 약 5~6년 정도 밖에 안됐지만 DevRel이라는 업무 자체는 웹만큼 역사가 오래되었습니다. 저는 첫 번째 DevRel 팀이 90년대에 Apple에 있었다는 것을 알게 되었습니다. 웹이 탄생한 것과 동시에 말이죠.

DevRel 2020 현황 서베이

2020년에 조사했던 DevRel의 현황을 조사했던 서베이를 함께 보시죠. 이 설문 조사를 통해 대부분의 사람들이 4–7년 정도의 경력을 가지고 있는 반면, 5%이상은 15년 이상의 경력을 가지고 있다는 것을 알 수 있습니다. 일반적으로 생각해보면 그리 길지 않은 시간일 수 있지만, 기술 분야임을 감안하면, 보면 길고 긴 시간입니다. 이 서베이는 대개 미국에 기반을 둔 사람들을 대상으로 한 서베이로, 남미, 아프리카, 그리고 그 외 다른 많은 곳들은 포함되지 않았습니다.

DevRel은 어디서나 볼 수 있습니다. 특히 COVID 이후, 이동을 자연스럽게 생각하게 되었고, 원격과 비동기적인 방식에 더 익숙해졌습니다. 아마 그래서 최근에 더 이 직업군에 대해 더 많이 듣게 되었을거라 생각합니다. 더 이상 사무실에 갈 수 없기 때문에, 관계에 대한 관리가 필요하다는 것이 명확해졌기 때문입니다.

왜 회사는 DevRel 팀을 시작할까요? DevRel 팀은 비용이 많이 드는데다, ‘관계’를 맺는 것에 기반하여 일을 하기 때문에 명확한 측정 기준을 정하기가 어렵습니다. 상사에게 가서 “오늘 저는 개발자 다섯 명의 삶을 바꿨습니다”라고 말할 수 없죠. 그래서 우리는 왜 회사가 DevRel 팀을 시작하는지에 대해 잘 살펴봐야 합니다. 원 그래프를 함께 보시죠.

이 원그래프는 2020년에 조사된 자료인데, 여러분이 가장 먼저 볼 수 있는 것은 ‘인지도와 기술의 도입의 유도(Drive awareness & Adoption) 인데요 . 이것은 여러 가지 방법으로 발생할 수 있습니다. New Relic은 소프트웨어 옵저버빌리티 플랫폼(역자 첨가 : 시스템상에서 언제 오류 또는 문제가 발생했는지 뿐만 아니라, 그보다 중요한 왜 발생했는지 그 이유를 제공해주는 실행 가능한 데이터를 수집하여 더 나은 소프트웨어를 빌드할 수 있도록 돕는 제품)입니다. 여러분이 5초 전에 New Relic이 무엇인지 몰랐다면, 이제는 알게 되었고 이게 제가 하는 일인거죠.

저희는 큰 시장의 일부입니다. 지금으로부터 1년 후에 여러분의 회사에서 New Relic과 옵션 B 중 도입을 고려한다면 그리고 만약 둘 다 같은 가격에 동일한 서비스를 제공한다면 그 때 여러분에게 이 강연이 기억에 스칠 수 있겠죠. 그리고 ‘아, New Relic에서 일한다고 했던 Pachi가 정말 멋진 분이었지,’ 라고 떠올리며, New Relic을 선택하는 것이죠. 인간은 경험과 감정에 의해 판단을 내리니까요.

두번째로 높은 비율을 보인 부분은 (22%) ‘개발자에 대한 교육과 지원’(Educate & Support developers) 이며 이는 여러 가지 형태로 진행될 수 있습니다. 하나의 예로, 튜토리얼과 비디오를 통한 제품 교육이 있습니다. 지금 이 발표에서 (역자 해설: 해당 글은 원문에 첨부된 유투브 발표를 기반으로 합니다) 제가 DevRel의 커리어 여정에 대해 알려드리는 것처럼요. 저는 초보자들을 돕는 일을 좋아합니다. New Relic은 사람들에게 코딩하는 법을 가르치는 회사는 아니기 때문에, 제가 사람들에게 코딩하는 법을 가르치고 있다면, 저는 회사 밖의 일을 하는 것이 됩니다. 하지만 저는 이를, 사람들에게 저희 제품을 배우는 데 장애물이 되는 부분들을 인지하고 그것을 제거하도록 돕는 일의 관점으로 보고 있습니다. DevRel 업무에 궁극적으로 도움이 되기도 하고요. 다른 디벨로퍼 애드보캇(Developer advocate)들은 직접 가르치기 보다, 적절한 튜토리얼을 선택 및 제공하는 것을 선호할 수 있으며, 그것도 괜찮습니다. 교육과 인지도는 DevRel 업무에서 가장 큰 부분입니다.

인게이지먼트(Engagement) 또한 또 하나의 영역인데, DevRel 담당자는 여러분이 브랜드에 알게되고 또 같이 소통하고 참여하기를 바랍니다. 당신이 적극적으로 소셜미디어에 글을 올리지 않더라도, 우리는 항상 사람들을 모아 제품에 대한 피드백을 받고 싶습니다. 그러나 DevRel로서 피드백을 받는 것은 일반적인 피드백을 받는 것과 다릅니다.

일반적인 방식의 경우, 소프트웨어를 사용하면 설문조사를 작성하라고 묻지만, 아마도 그냥 귀찮아서 꺼버리죠. 그래서 스티커를 줄테니 서베이를 해달라고 부탁하겠죠. 다들 스티커를 좋아하기 때문에, 서베이에 응하게 될 것입니다. 하지만 여러분이 정말 그 소프트웨어를 좋아하는 것이 아니라면, 여러분이 적는 대답은 기껏해야 예, 아니오, 예, 아니오 에 그치죠.

하지만 DevRel은 여러분을 이해하기를 원하고 여러분과 진정한 대화를 하려고 할 것입니다. 그래서 여러분은 저희에게 정말 유용할, 정직하고 편견 없는 피드백을 줄 가능성이 더 높죠.

이 다이어그램은 사실 좀 틀린 것 같아요. 1%의 Sales도 아니에요. DevRel은 영업이 아닙니다. 당신이 DevRel 담당자인데 무언가를 팔라는 이야기를 했다면, 그건 당신 일이 아닙니다. 누군가가 제게 와서 “Pachi, 나 프리미엄 버전으로 결제하고 싶어요”라고 말하면 “좋습니다. 제가 영업 담당자와 연결해 드릴게요” 라고 할거예요.

7%를 차지한 부분을 보면, 오픈 소스와 같은 코드 기여(Get code contributions)도 있습니다. 많은 회사들은 문서화나 새로운 제품 라인을 개발하기 위한 훌륭한 프로젝트를 가지고 있습니다.

3가지 요소로 설명하는 DevRel 담당자가 하는 일

DevRel 담당자는 그럼 구체적으로 무슨 일을 할까요?

우리는 주로 커뮤니티에서 활동하며, 피드백을 주고, 사람들에게 우리가 커뮤니티에 존재한다는 것을 알립니다. 하지만 어떻게 그렇게 할 수 있을까요? 위의 그림처럼 세 개의 영역으로 나누어 설명해보겠습니다. 첫 번째는 도움이 될 수 있는 콘텐츠를 만드는 것인데, 그 형태는 다양합니다. 예를 들면, 발표. 지금 저는 콘텐츠를 만들고 있는 거겠죠! ( 발표중이니까요 ) YAY! 너무나 중요한, 블로그도 있겠고요. 그리고 유튜브 영상도 있죠.

커뮤니티 관계 또한 중요합니다. 당신이 내성적인 사람일지라도 사람들과 관계를 맺고 두려워해서는 안 됩니다. 저는 굉장히 내성적입니다. 하지만 DevRel일을 하면서 맺게 되는 관계는 네트워킹에서 맺는 관계의 성격과는 다릅니다. DevRel 담당자로서는, ‘진정한’ 관계를 만드는 것이 중요합니다.

마지막은 코드입니다. 어떤 사람들은 DevRel이 프로그래머 마케팅과 같다고 말하는데, 그것은 우리를 차별화하는 부분입니다. 예를 들어, 제가 DevRel으로서 처음 한 일은 트윗을 날리고 사람들과 소통하는 활동이었는데, 그것을 통해 사람들의 어려움과 농담에 공감할 수 있게 해주었기 때문에 마케팅 활동에 도움이 되었습니다.

이것이 세 가지 주 요소입니다. 어떤 성격의 DevRel을 하느냐에 따라, 코드보다는 콘텐츠 생산의 일이 더 많을 수 있습니다. 2020년에 저는 콘텐츠 제작을 많이 했고 코딩 작업은 상대적으로 적었습니다. 하지만 이제 새로운 회사로 옮겼고, 여기서는 콘텐츠 제작 보다는 코딩이 더 많은 업무를 하게 됩니다.

코드를 많이 작성하면 콘텐츠를 많이 만들 수 있지만 커뮤니티에 들어갈 시간이 많지 않습니다. 만약 여러분이 더 많은 대중 연설을 하는 디벨로퍼 애드보캇이라면, 커뮤니티 비중이 높을 것이고, 다양한 업무 각각의 비중은 상이할 수 있어요.

프로그래머가 아니더라도 코드를 볼 수 있어야 합니다. 적어도 자바와 자바스크립트의 차이점을 알 수 있어야 하죠.

제 여정에 대해 조금 말씀드리겠습니다. 저는 2018년 10월부터 독학으로 코딩을 배우기 시작했는데 저를 커뮤니티형 프로그래머라고 이야기하는 걸 좋아해요. 온라인베이스였죠. 2019년 여름, 저는 뉴욕에서 열린 Kotland라는 컨퍼런스에 참석했습니다. 거기서 저는 ‘블로그를 시작해야만 하는 이유’ 에 대한 강연을 들었고 그 이후로 블로그를 시작했습니다. 제가 첫번재로 쓴 건 “이봐, 코드는 어려워.” 라는 내용의 20줄 짜리 글이었고요. 2년 전 1월에 저는 주로 Dev.to과 Twitter 에 참여하기 시작했습니다. 트위터는 누구를 팔로우 하느냐에 따라 굉장히 다른 공간이 될 수 있어요.

그리고 트위치에서 라이브 코딩을 시작했습니다. 제가 좋아하는 일이었고, 많은 사람들을 알게 되었기 때문에 그 일은 제 삶에 변화를 안겨 주었어요. 그리고 2020년 말, 저는 2–3개월 후에 첫 직장을 구했습니다. 제가 이 이야기를 하는 이유는 아무도 DevRel이 되기 위해 일관적인 커리어 여정을 택하지 않기 때문입니다. 제 여정을 보면 알 수 있듯, 저는 이미 콘텐츠를 만들고 커뮤니티에 참여하고 있었습니다.

제가 무엇을 했냐고요? 저는 개인적으로 공개 발표와 라이브 코딩을 하고 있고, New Relic에서 팟캐스트도 했습니다. 컨퍼런스도 다시 시작될 예정이고요. 제 역할은 대중과 마주하는 많은 것들이지만, 몇몇 다른 사람들은 다르게 할 수도 있습니다. 변하지 않는 것은 제가 아까 말씀드렸던 세 가지 요소입니다. 코드를 작성하고, 커뮤니티와 상호 작용하며, 콘텐츠를 만드는 것이요.

저의 하루는 이렇게 흘러갑니다. 프로그래머로서, 여러분은 아마 여러분이 책임져야 할 테스트와 이슈 티켓, 그리고 에러가 생긴 것들이 있을거예요. 하지만 DevRel로서, 저는 그런 것들을 가지고 있지 않고, 대신 일어나서 아침 일을 하고, 앉아서 하루 일과를 계획합니다. 그리고 오전 10시에, 저는 2시간 동안 라이브 스트리밍을 하고, 몇 개의 팀 미팅에 참여하고, 점심을 먹습니다. 약간의 일을 하고, 블로그 포스팅에 몇 시간을 할애하고, 발표 준비도 합니다. 어떤 날은 8시간 일하고, 어떤 날은 4시간 일하고, 컨퍼런스 날에는 하루 종일 18시간씩 일할 수 있습니다.

저희는 재미있는 것들을 많이 합니다. DevRel은 재미있어요. 하지만 유념해야해요. 번아웃은 정말 쉽게 찾아오거든요. 때때로 여러분이 재미있고 즐거운 일을 하고 있을 때; 여러분의 뇌는 “좋아, 즐거웠지만, 우리의 몸은 불평하고 있어.”라고 할지도 모릅니다. 바운더리를 갖고 임하는 것이 항상 중요합니다.

이제 여러분은 스스로에게 묻어볼 수 있을지 몰라요. “내가 DevRel 이 될 수 있을까?” 음, 당신은 개발자인가요? 그러면 몇 년의 경력이 없어도 가능합니다. 대부분의 역할들이 그 정도의 경력을 요구하지만, 제 역할은 단지 5년 정도의 경력을 요구했습니다. 하지만 매니저가 저를 좋아해서 그 역할을 맡겨주셨죠.

수 년의 경력이 없더라도 적어도 코딩에 대한 경험은 있어야 개발자들과 공감할 수 있습니다. 그리고 여러분은 기꺼이 새로운 것을 시도할 수 있어야 합니다. 프로그래머가 파이썬으로 작업하면서 스크립트 작성 방법에 대한 블로그 게시물이 필요하다고 말할 수도 있지만, 다음 달에는 파이썬이 아닌 새로운 기술이 될 수도 있습니다. 따라서 여러분은 하나의 스택에 집착하기 보다는 다른 것들을 배우는 데 기꺼이 시간을 보내야 합니다. 저 같은 경우는 10명으로 구성된 큰 팀이 있어서 어느 정도 전문화 할 수 있지만, 이건 흔한 경우는 아닙니다. 그래서 DevRel로 일할 때는, 정말 융통성이 있어야 합니다.

가장 중요한 것은 우리는 공유하고, 가르치는 사람이라는 것입니다. 코딩 조언을 공유할 수도 있고, DevRel이 무엇인지 설명할 수도 있습니다. 저는 이것을 항상 유념하고 있는데 왜냐하면 여러분이 DevRel일을 하는 동안, 사람들이 여러분을 지켜보고, 여러분을 본보기로 삼을 수 있기 때문입니다. 그래서 여러분은 가르치고 공유해야 합니다. 하지만 여러분이 정말로 훌륭한 DevRel이 되고 싶다면 이 외에도, 사람들을 배려할 줄 알아야 합니다.

저는 항상 배려하며 마음을 쓸 줄 아는 것이 여러분을 차별화하는 부분이라고 말합니다. 적절한 기술을 가진 사람이라면 누구나 DevRel이 될 수 있지만, 당신이 진정으로 마음을 쓰며 사람들을 케어할 줄 안다면, 당신은 훌륭한 DevRel이 될 수 있습니다. 커뮤니티를 배려하는 것은 차이를 만듭니다.

여러분이 시작하는 방법은 여러분의 콘텐츠 유형을 찾는 것입니다. 여러분은 유투버가 되고 싶어할 수도 있고, 틱토커가 되고 싶을 수도 있습니다. 그러니 당신은 당신이 좋아하는 콘텐츠의 종류를 찾아야 합니다.

제가 작년에 유투브, 트위터, 링크드인, 인스타그램 등을 사용했고, 저는 번아웃이 금방 와버렸습니다. 그러니 한가지만 하세요. 블로그를 먼저 시작하는 것이 좋을 거예요. 블로그는 가장 쉽게 시작할 수 있는 활동이에요. 여러분이 글을 통해 문제를 제시한다면, 아이디어를 교환하는 방식으로 작동될 수 있죠. 저는 Dev.to라는 사이트를 적극 추천합니다. 왜냐하면 그곳엔 훌륭한 도움 커뮤니티가 있기 때문입니다.

마지막으로, 여러분의 사람들을 찾고, 여러분의 커뮤니티를 찾으세요. 저의 경우에 처음에는 트위터의 개발자들이었고, Dev.to 라는 커뮤니티였는데, 만약에 여러분이 파이썬에 관심이 많다면, Python Ladies 가 좋을 거예요. 당신과 맞는 사람들을 찾았다면 거기가 맞는 커뮤니티입니다. 당신이 받은 것을 돌려주고 싶은 사람들을 얻게 되고, 저는 그것을 계기로 DevRel일이 하고 싶어졌어요.

여러분이 정말 마음에 맞는 곳에 있다면 지식을 단지 흡수하고 마는게 아니라, 공유하고 어떻게든 돌려주고 싶어할 것입니다.

제가 모아온 DevRel 레파지토리를 공개합니다. 콘텐츠가 많을 거예요. 주소는 github.com/pachicodes/devrel입니다. 책, 편지, 블로그 게시물 등이 있고 그리고 여러분과 더 많은 리소스를 공유할 수 있는 DevRel 사람들의 트위터 목록을 추가했으니, 그것들을 통해 배우고 또 즐기길 바랍니다. 저는 Pachi Parra 였고요. 트위터와 트위치에서 저를 찾을 수 있습니다. 제 DM이 열려있으니 자유롭게 메시지 주시고요.

감사합니다.

번역 : 위민후코드 서울 하현주
검수 : 위민후코드서울 강연정

--

--

oliviha
wwcodeseoul

궁지에 몰린 마음을 밥처럼 씹어라. 어차피 삶은 너가 소화해야 할 것이니까.