[Nailed IT #1] 테크 조직 문화를 가꾸는 커뮤니티와 기업 사이의 커넥터, DevRel을 만나다.
💡 Nailed IT(a.k.a 대신 해주는 커피챗)는 다양한 직군에서 일하고 있는 여성 IT인들을 만나 커피챗을 하며 인터뷰를 진행하는 프로젝트입니다.
Q. 안녕하세요. Olivia님! 만나 뵙게 되어 반갑습니다. 먼저 이 Nailed IT 프로젝트가 위민후코드 서울 상반기 결산 행사에서 Olivia님과 가인님께서 발표해 주신 세션인 [Tech 세계의 빙산의 일각만 아는 당신에게: Tech 업계의 다양한 직군 소개]를 통해 파생되었는데요. 행사에 참여해 주신 많은 분들이 해당 세션이 너무 유익했다고 코멘트를 남겨주셨어요. 그래서 가장 처음으로 진행하는 인터뷰는 Olivia님이 해주셔야겠다고 제가 강력하게 주장했답니다!(웃음) 흔쾌히 인터뷰에 응해주셔서 너무 감사해요. 그럼 이 인터뷰를 보실 모든 독자님들께 소개 부탁드립니다.
안녕하세요. 저는 현재 무신사에서 Developer Relations으로 일하고 있는 Olivia Ha입니다. 최근 무신사에 CTO님이 새롭게 합류하면서 무신사 테크 부문에 굉장히 많은 변화가 일어나고 있고, 저는 그런 흐름에 맞춰 테크 부문의 조직 문화 개선 및 테크 부문을 널리 알리는 일을 하기 위해 입사하게 되었어요. 아직 입사한지 한 달 차라 좀 어리버리한 상태입니다.(웃음)
Q. 무신사에 DevRel로 합류하게 된 계기가 있을까요? 요새 무신사가 테크팀 채용을 엄청나게 하고 있던데, 저희 독자님들의 상당 부분이 개발자시기 때문에 혹시라도 이 글을 보고 계실 개발자분들께 무신사의 매력을 어필할 수 있는 시간을 드리겠습니다!
먼저 이 인터뷰는 직무 인터뷰이기에, DevRel 커리어 관점에서의 매력과 무신사 테크 부문의 구성원으로서 느낄 수 있는 매력 두 가지로 나누어서 생각해 봤어요.
일단 둘 다 공통적으로 해당되는 건 많은 분들이 아시다시피 무신사는 독보적인 성장력을 가진 회사로서 단기간에 고속 성장을 했고, 그 속도가 계속 지속되는 회사 중 하나예요. 회사가 매출을 내면서 크게 성장하고 있을 뿐만 아니라 지금까지 적자가 한 번도 나지 않았다는 게 어마어마한 매력이라고 생각해요. 구성원으로서 안정감과 자신감을 느끼게 하고요.
그런 회사가 이제 CTO와 Developer Relations을 갖추고 테크 부문을 제대로 다지기 위한 활동을 본격적으로 시작했으니 이제 더 좋아질 일만 남은 회사라고 생각합니다. 계속 성장하며 흥미로운 과제들이 쏟아지는 상황이라, 어떤 액션이든 구성원이 만들어낼 수 있는 영향력이 굉장히 크다는 것 또한 매력이라고 생각합니다. 같은 일이 계속 반복되거나 풀고 있는 문제가 충분히 매력적이지 않아 고민이신 분이 계시다면, 무신사로 오시는 것이 해답일 수 있습니다!(웃음)
DevRel로 일하는 커리어 관점에서는, 개인적으로 내부 브랜딩과 문화를 만드는 일을 해본 적이 없어서 굉장히 도전적인 기회라고 생각이 되어 기대가 되고요. 무신사의 테크 조직은 목적 조직과 기능 조직 하이브리드 구조로 일하고 있는 PM과 개발자, 디자이너가 함께 있는 조직이라 단순히 개발자만을 위한 관계 활동이 아닌 더 확장된 개념으로 조직을 위한 활동들을 만들어나갈 수 있어 새로운 것을 시도해 볼 여지가 많은 것 같아요.
Q. 듣다 보니 저도 당장 무신사에 지원하고 싶어질 정도예요. 그럼 현재 일하고 계신 DevRel이란 직군에 대해서도 소개해주세요.
최근에 여기저기서 많이 언급된 덕분에 예전보다는 많이 알려진 직군이 된 거 같아요. DevRel은 ‘Developer Relations’의 줄임말로 한국어로 직역하면 ‘개발자 관계 활동’인데, 보통 개발자들을 고객으로 보는 DevRel과 개발자를 내부 구성원으로 보는 DevRel, 이렇게 두 가지로 나눠져요.
첫 번째로 개발자를 고객으로 하는 제품이나 서비스를 만드는 회사의 DevRel은 보통 영업, 세일즈 마케팅에 가까워요. 근데 이게 우리가 ‘영업’이라고 했을 때 느껴지는 노골적인 느낌이 아니고 정말 진정한 관계를 만드는 걸 말해요. 우리의 제품으로 업무를 보다 더 효율적으로 할 수 있게 하려면 어떻게 해야 할까를 고민하면서 개발자 친화적으로 접근하는 활동들을 많이 하죠. 그래서 개발자분들이 우리 서비스와 제품을 제대로 활용할 수 있게 하기 위해 필요한 콘텐츠를 만들고 소통을 하는 등 회사와 개발자 사이에 모든 커뮤니케이션을 담당하는 일을 합니다. 이 경우를 ‘Developer Advocate’라고도 말해요.
두 번째로 개발자가 없으면 안 되는 회사의 DevRel이 있는데, 보통 한국의 DevRel은 여기에 속해요. 한국은 SaaS나 SDK, API를 만드는 회사가 많이 없기 때문에 개발자가 고객이라기보단 핵심 인재거든요. 그래서 사내 테크 문화와 테크 브랜딩을 잘 만들어서 외부 개발자들한테 어필해서 채용으로 이어지게 한다든지, 테크 컨퍼런스 후원을 한다든지 개발자에 대한 모든 이해를 바탕으로 하는 활동들을 해요.
저는 후자에 가까운 DevRel이에요.
Q. DevRel이 테크 조직 브랜딩과 마케팅, 커뮤니케이션, 채용 등에 긴밀하게 연결되어 있는 것 같은데요. 정말 한 사람이 이 모든 것을 다 하는 건가요?
놀랍게도 그렇습니다.(웃음) 근데 소위 말하는 우아한 형제들이나 라인 등 DevRel이 조금 무르익은 회사들은 2~3명 정도 있는 거로 알고 있어요. 마이크로소프트같이 글로벌 회사들은 몇십 명씩 되기도 하고, 지역 별로 전 세계를 커버해야 하는 경우엔 훨씬 많아요.
우선 저의 경우엔 혼자서 다 하고 있어요. 그렇게 때문에 더욱이 우선순위를 나눠 업무를 진행해야 하고, 에너지 조절을 잘 해야 하죠. 회사 안팎으로 커뮤니케이션이 동시다발적으로 일어나는 업무의 특성 때문에 멀티태스킹 능력도 굉장히 중요한 것 같아요.
기본적으로 사람과의 커뮤니케이션이 남들보다 조금 더 힘들거나 많이 지친다고 생각되는 타입이시면 에너지 소모가 상당할 거예요. 반면 그런 특성 때문에 지루하지 않게 일할 수 있고, 다양한 장점들을 발휘하면서 일을 해볼 수 있죠.
Q. 앞서 말씀하셨던 DevRel의 업무 중에 개발자 채용도 있는 것 같은데, 그렇다면 테크 리크루터와는 또 어떻게 다른지 설명해 주실 수 있으신가요?
채용 공고를 보면 개발자 채용 전략이나 채용 프로세스 등을 관리하는 게 테크 리크루터의 일이에요. 이렇게 엄연히 HR의 업무로 분류되는 것들이 있어요. 근데 저희가 보통 개발자 채용에 관여한다고 하면 ‘채용 브랜딩’이라고 말하거든요. 목적이 되게 다른 것 같아요.
쉽게 말하면, 채용은 결국 모든 프로세스를 거쳐 최종적으로 살아남은 사람을 뽑는 게 목표잖아요. 저희는 그 퍼널의 제일 넓은 쪽에서 접점을 늘리는 데 필요한 활동들을 돕는다고 생각하면 될 거 같아요. 아까도 말씀드렸지만 내부 구성원들이 행복한 조직을 만들면 당연히 밖으로 자랑할 거리가 많아지고, 그런 것들이 HR 측면에서 더 많은 지원자를 불러 모을 수 있는 하나의 콘텐츠 리소스가 될 수 있으니까 그렇게 상호보완적으로 일하는 거라고 생각해 주시면 될 거 같습니다. 하지만 저희도 지금 같이 일하는 프로세스를 조율하며 만들어가는 과정에 있고, 이건 회사의 상황마다 다 다를 거라고 생각해요.
Q. 이 질문은 Nailed IT의 공통 질문이에요. 출근해서 퇴근하기까지의 하루 업무 과정을 말씀해 주세요!
저의 경우에는 정해진 루틴 없이 매일매일이 달라요. 그때그때 상황에 맞춰 가장 우선적으로 처리해야 할 일들에 따라서 하루 업무 과정이 달라지는 편이에요. 대략적으로 예를 들면, 테크 컨퍼런스 행사 후원을 앞두고 있거나 부스 운영을 앞두고 있는 경우엔 그와 관련된 부서들과의 협업 미팅을 진행하고 아이데이션해요. 그다음에 테크 타운홀같이 내부 구성원들과 CTO가 함께 하는 전사적인 행사가 계획되어 있으면 베뉴부터 케이터링 준비, 프로그램 등을 기획하고 안배하는 거 같아요. 그리고 만약 개발자분들의 스터디를 지원한다 하면 어떤 스터디를 어떻게 진행할 건지 같이 기획하는 등 하루 업무 과정이 딱 정해져 있지 않고 매번 다양한 것 같아요.
또 사내 메신저에서 말랑말랑하고 재밌게 읽을 수 있을 법한 아티클을 공유하거나 같이 의견을 나눠볼 수 있는 아젠다를 계속 던지는 일도 하고요. 대화에서 사용할 수 있는 커스텀 이모지를 추가한다든지 정말 소소하지만 즐거운 일들이 많아요.
추가로 제가 최근에 위민후코드 서울 운영진분들과 같이 진행하는 나랏말싸미 프로젝트로 GitHub에서 Developer Advocate으로 일하고 계신 Pachi Parra의 인터뷰를 번역했었는데, 그분도 하루 업무 과정을 소개해 주셨거든요. 그뿐만 아니라 DevRel 이야기도 재밌으니 전문을 같이 읽어주시면 더 좋을 거 같아요. (👉 보러 가기)
Q. 보통 개발자나 디자이너는 기능이나 페이지 단위로 성과를 측정하는데, DevRel 직군의 경우 성과 측정을 어떻게 하는지 궁금합니다!
저희 회사의 경우엔 이제 막 DevRel이 합류했기 때문에 당장 어떤 평가 지표를 두고 성과를 측정하고 있지는 않고, 정성적인 목표를 세워 진행하고 있습니다. 그렇기 때문에 일반적으로 어떻게 성과 측정을 하는지 말씀드릴게요.
우선 앞서 DevRel이 하는 업무에 대해 말씀드려 아시겠지만, 정말 하는 일이 다양해요. 물론 모든 직군이 그렇지만 회사 니즈에 맞게 업무가 조율되고 변형되는 직군 중 하나이기 때문에 성과 측정 방법도 회사마다 그리고 업무마다 달라요.
예를 들어 개발자 경험을 좋게 만드는 게 중요한 경우, 개발자들의 긍정적인 피드백 혹은 GitHub 레포지토리에 스타가 많이 붙었다든지 그런 것들로 평가하기도 해요. 만약 제품 혹은 콘텐츠와 관련된 경우, 얼마나 자주 방문했는지, 페이지 조회수가 얼마인지 트래픽을 보기도 하고 그래요.
Q. Developer Advocate의 경우엔 제품을 세일즈 마케팅하는 데에 주안점을 좀 더 둔다 하셨는데 이런 경우에는 그럼 어떻게 측정하나요?
이 경우에는 앞서 소개했었던 번역 글에도 쓰여있는데, 절대 직접 파는 게 아니라 영업 부서와 연결을 해줘요. 연결 횟수까지 세세하게 측정하는지는 알 수 없지만, 제가 경험했던 회사들에 따르면 튜토리얼 문서에서 사람들이 얼마나 체류했는지, 혹은 제품을 소개하는 웨비나에 몇 명이 참석했고, 데모로 몇 번이나 이어졌는지, 그리고 데모를 보고 나서 미팅으로 이어지는 게 얼마인지 등의 수치들을 측정해서 평가하기도 했습니다.
Q. 그럼 업무를 수행하면서 가장 기억에 남는 에피소드가 있으실까요? 있으시다면 한 가지 이야기해 주세요.
가장 기억에 남는 에피소드는 마이크로소프트에 있던 시절 제가 처음 맡았던 일인, 싱가포르에서 열리는 MS MVP 개더링을 오거나이즈했던 일이에요. 마이크로소프트는 MVP(Microsoft Most Valuable Professional)라는 어워드가 있어서 MS 기술을 사랑하는 사람들 중에 자신의 지식을 커뮤니티와 열정적으로 공유하는 기술 전문가에게 주는 상이 있는데 저는 그런 MVP를 서포트하는 일을 했었거든요.
APAC 지역의 MVP들이 일 년에 한 번 싱가포르에서 다 같이 모이는 행사였어요. 근데 저는 싱가포르에 가본 적도 없고, 13개의 국가에서 오는 MVP들을 직접 만나본 적도 없었거든요. 그들을 대상으로 소속감도 느낄 수 있고, 재미도 있고, 모든 문화를 다 수용할 수 있는 기획을 해야 한다는 생각에 엄청 압도됐었죠.
그때 진짜 ‘다양성’에 대해 되게 많이 배울 수 있었어요. 다양한 종교를 가진 MVP들이 참석하기 때문에 음식 선호도 조사도 해야 했고, 우리나라에서는 경험할 수 없었던 다양한 문화에서 커뮤니티 활동을 하는 커뮤니티 리더들과의 대화 속에서 많은 가치들을 배울 수 있었어요. 그 과정을 통해 내 업무가 다양한 사람들의 니즈를 맞출 수 있어야 한다는 걸 깨달았던 거 같아요. 그때부터 항상 사람들을 진정으로 이해하고, 업무 뒤에 한 사람 한 사람이 있다는 거를 잊지 말자는 생각으로 업무를 해왔어요.
Q. 그렇다면, 이 직무를 수행하는 데에 가장 필요한 역량은 무엇이라고 생각하시나요?
제가 업계의 DevRel 친구들과 우스갯소리로 맨날 하는 말이 세미나 끝나고 남아서 쓰레기 같은 거 남아서 주울 줄 아는 사람이면 된다고 하거든요.(웃음) 이 일이 잡일이 많기 때문에 막 ‘나는 그런 일 못해’ 이런 마인드라면 좀 힘들 거 같아요.
그리고 뭐든지 오너십을 갖고 임하는 적극성이 되게 중요해요. 왜냐하면 이 직군은 사실 많이 알려진 멘토나 같은 길을 가는 사람들을 찾기가 쉽지 않거든요. 그렇기 때문에 도전정신을 가지고 ‘내가 길을 만든다’ 이런 개척해 나가는 마인드로 임하는 게 중요한 거 같아요.
또한 기본적으로 커뮤니티 생태계에 대한 자연적인 관심이 많아야 되는 것 같아요. 예를 들어서 MLOps 생태계의 제품이나 서비스를 시장에 런칭하면서 관심을 가질 타겟 그룹을 찾는 것이 DevRel의 미션이라면, 타겟이 누구일지, 그 타겟이 모여있는 곳이 어디인지, 없다면 어떻게 모이게 할지 등에 대해 바로 알 수 있어야 해요. 근데 이런 것들은 사실 하루아침에 되는 게 아니라 본인이 커뮤니티에서 꾸준히 활동을 해야 자연스럽게 알 수 있는 거거든요. 혹은 모르면 설령 한 번도 대화를 나눠본 적 없는 개발자일지라도 먼저 다가가서 혹시 주변에 ML 엔지니어 연결해 줄 수 있냐 부탁하고 그렇게 스스로 찾아갈 수 있어야 해요. 그래서 주어진 업무만 하는 게 좋거나 본인이 주력으로 하는 분야 이외의 사람들하고 만나서 네트워킹하는 걸 별로 좋아하지 않는다면 힘들 수도 있죠.
Q. 그렇다면 말씀하신 역량이 없는 경우에는 어떻게 해야 하나요?
일단 커뮤니티에 가입해서 봉사활동이나 활동에 참여해 보면서 커뮤니티가 어떻게 돌아가는지부터 먼저 이해를 해보라고 얘기를 항상 드려요. 작은 스터디라도 스스로 아이디어를 내서 모임을 리딩해 본다든지 그런 경험들이 엄청 도움이 되거든요. 그거 이외에도 비전공자를 위한 개발 지식을 가르쳐 주는 강연이나 책을 본다든지 개발자분들이 하는 세션 등을 꾸준히 소비를 해서 IT 업계 자체에 전반적인 이해를 높이는 게 되게 중요한 것 같아요.
Q. 이제 주제를 좀 돌려볼게요. Olivia님은 학부 시절 무슨 전공을 하셨나요?
저는 영어학을 전공했어요. 커리어는 마케터로 시작했는데 지금은 완전 쌩뚱맞은 곳에 있죠.(웃음)
Q. 마케터로 커리어를 시작하셨다고 방금 말씀해 주셨는데 그럼 어떻게 DevRel이라는 직업을 알게 되셨고, 그 방향으로 커리어를 진행해 나가겠다는 결심을 하신 건지 궁금합니다. 그동안의 커리어 패스에 대해서도 같이 설명해 주세요.
마케터로 일을 할 때 아무래도 개발 지식이 없다 보니 개발자분들이랑 소통하는 게 되게 어려웠어요. 그래서 개발자분들을 좀 이해할 수 있어야 업무가 좀 수월하겠다 싶어서 개발 언어를 공부해야겠다 결심했고, 비개발자를 위한 워크샵을 찾았어요. 그렇게 Django Girls라는 커뮤니티에서 진행하는 무료 워크샵에 참여하게 되었는데, Django를 사용해서 블로그 만드는 튜토리얼을 듣게 되었어요. 작은 것 하나를 완성해도 함께 박수 쳐주고, 함께 기뻐해 주는 커뮤니티에서의 소속감을 그때 처음 맛본 것 같아요. 모든 사람이 저를 환영해 주고 저를 수용해 주는 분위기가 저한테는 너무 감격스럽고 어디서도 경험하지 못한 신선함이었어요.
또 말 그대로 ‘Django Girls’였기 때문에 여성 개발자분들도 되게 많았어요. 그동안 생각해왔던 전형적인 개발자의 이미지가 그때 많이 바뀐 거 같아요. 그렇게 열심히 참여하다가 자연스럽게 운영진이 되었고 2년 정도 활동을 했는데, 그러다 보니 어느 순간 제 주변에 개발자 친구들이 많아졌죠.
사실 커뮤니티 활동을 하신 분들은 공감하실 텐데 리더가 있어서 역할을 분장해 주는 게 아니라 본인이 자발적으로 참여를 해야 하는 분위기예요. 근데 그때 저는 개발자가 아니었기 때문에 제가 기여할 수 있는 업무는 마케팅이나 홍보 쪽일이었어요. 그때 당시에 마케터들도 개발 지식을 배워야 한다는 이야기가 조금씩 나오던 때였고, 그럼 내가 개발자와 마케터 사이를 이어줄 수 있는 브릿지 역할을 해봐도 좋을 거 같다는 생각도 하게 되었고요.
그러다가 무료 워크샵에서 코치였던 개발자분이 MS MVP가 되셨는데 MVP 프로그램을 관리하는 포지션에 추천을 해주셨어요. 그렇게 우연히 DevRel의 길에 접어들게 되었죠.
Q. 커뮤니티를 통해 DevRel까지 흘러오게 되신 거군요. 그렇다면 개발 지식이 전무한 사람도 DevRel에 도전해 볼 수 있을까요? 그리고 IT 회사에 다녀보지 않은 사람도 가능할까요?
우선 IT 회사에 다녀보지 않은 사람이라면 되게 쉽지 않겠다는 생각이 들어요. 예전에 마케터로 일할 때 IT 업계가 아닌 다른 업계 사람들과 네트워킹을 할 기회가 있었는데, 쓰는 제품이나 관심사가 너무 다른 거예요. 예를 들면 그때가 막 토스가 사업을 시작한 때였는데 토스가 뭔지도 모르고, 공유 차량 이런 것도 써본 적 없고 뭐 이런 식으로 아예 이 시장 동향을 모르는 사람들이 많았어요.
그런 환경이라면, 커뮤니티가 IT 환경과 접점을 만들어 줄 수 있는 좋은 매개체가 된다고 생각해요. DevRel은 이름 그대로처럼 개발자분들을 고객으로 하거나, 조직의 핵심 인재로 여기는 곳에서만 채용되는 실정이기에, 이런 생태계에 대한 이해는 핵심일 수밖에 없죠. 얼마 전에 어떤 대학생분이 합격한 회사 몇 군데를 후보에 두고 질문을 하셨는데, 하고 있던 직무를 지속하면서, DevRel과의 접점을 만들기에 어떤 선택이 좋을지 여쭈어보셨어요. 한 회사는 소위 말하는 혁신을 다루는 최신 기술을 중심으로 하는 작은 스타트업이었고, 다른 한 회사는 규모는 좀 더 컸지만, 기술 집약적 회사가 아니었기에 매우 소수의 개발자만 존재하는 회사였어요. 여러분의 목표가 DevRel로의 브릿지를 만드는 것이라면 개발자가 있는 것만으로는 충분하지 않아요.
그리고 개발 지식 유무에 대해서 질문을 진짜 많이 하시는데 이거는 두려움에서 오는 질문 같아요. 이 질문에 저는 기본적으로 DevRel이 누구와 일을 하고 누구를 위해 존재할까를 먼저 생각해 보셨으면 좋겠다고 대답해 드리고 싶어요. DevRel은 Relations을 만드는 일이라는 것을 잊지 마세요. 개발 지식의 유무로 내가 이 일을 잘할 수 있을까 없을까의 자격을 논하기보다는, 내가 정말 같이 일할 사람들에 대해서 궁금증과 호기심을 가지고 있는지 그렇다면 그 사람들을 더 이해하기 위해 무엇이든 배우고 알아볼 의지가 있는지 생각해 보자고 이야기 드리고 싶어요.
그리고 직무 이름 자체는 Developer Relations지만 사실 개발자만을 위한 직무가 아니라 테크 조직을 위해서 존재한다고 생각해요. 그래서 테크 조직의 인력들과 공감을 할 수 있어야 해요. 또, DevRel은 Community Manager, DevRel Advocate, Program Manager 등 다양한 직무로 나눠질 수 있어요. 물론 팀이 어느 정도 구축이 되어야 이렇게 여러 갈래로 나눠지지만 그래도 꼭 개발 지식을 알아야지만 할 수 있는 게 아니라는 거죠.
Q. 반대로 개발자에서 DevRel이 되고 싶은 경우에는 어떻게 하나요?
DevRel 직무 중에서도 Developer Advocate과 같이 개발 지식을 활용하는 분야가 있기도 하고, 확실히 개발 지식이 있으면 커버할 수 있는 범위가 넓어지고 남들보다 더 잘할 수 있는 영역이 있게 돼요. 지금 개발자 커리어를 지속하고 계신다면, 최소 3년에서 5년 정도는 개발자로 일하면서 현직 개발자를 이해할 수 있는 역량들을 충분히 경험하시고 DevRel을 시작하시면 더 좋을 거라고 조언 드리곤 해요.
Q. 역시 커뮤니티 활동이 중요한 거 같은데 혹시 DevRel 커뮤니티가 국내에도 있나요? 있다면 DevRel을 준비하는 사람들을 위해 대표적으로 몇 가지만 소개해 주실 수 있으세요?
국내에서 대표적인 DevRel 커뮤니티는 아직 본 적 없는 거 같아요. 최근에 트위터에서 devrel.kr이라는 계정을 발견했는데, 페이스북 그룹도 있더라고요. 아직 멤버 수가 많지는 않은데, 그래도 정보가 꽤 올라오는 편이라 관심 있으신 분들은 참고해 주시면 될 거 같아요.
Q. Olivia님이 생각하시는 좋은 사내 개발 문화는 무엇이며, 문화를 바꿔보신 경험이 있으신지 궁금합니다.
저는 구성원들이 자율적 의지를 가지고 스스로 만들어가는 문화가 제일 좋은 문화라고 생각해요. 막상 어디서 좋다고 해서 도입해 봤자 만약 그걸 주도했던 사람이 퇴사하면 흐지부지되면서 없어지는 경우가 종종 있거든요. 사실 그런 건 문화가 아니라고 생각해요. 필요에 의해서 구성원들이 자발적으로 만들어 나가는 관습들이 반복되면 그게 문화가 되는 거라고 생각합니다. 저도 이번 회사에서 그런 경험을 해보고 싶어요.(웃음)
Q. 이 질문은 사전 설문을 통해 받았던 질문 중 하나예요. 시니어 없이 주니어들로만 이루어진 스타트업에서 일하고 있습니다. 개발팀 내의 체계를 잡아가는 게 힘든데 이런 상황에는 어떻게 하면 좋을지 DevRel로서 조언 한 마디 부탁드려요.
모든 전후 상황을 알 수는 없어서 조심스러운 답변이긴 한데, 저는 그냥 같이 힘을 합쳐서 만들어 보는 경험을 해보시라고 말씀드리고 싶어요. 처음부터 완벽한 체계는 없고, 시니어가 만든 체계가 항상 조직에게 다 옳다고 말할 수 없거든요. 주니어라고 생각하기 보다, 함께 일하는 동료로서 우리가 어떻게 일하는 것이 조직의 미션을 달성하는 데 가장 적합하고 맞을까를 고민하면서 만들어가는 경험을 해보시길 응원 드려요!
Q. 이제 거의 막바지를 향해 가고 있는데, 커리어 측면에서 앞으로 이루고 싶으신 게 있다면 무엇인가요?
단기적으로는 이번에 합류하게 된 무신사가 큰 규모이기 때문에 단순히 사람들을 이해하는 일보다 협업을 하는 방식, 그리고 조직이 행복할 수 있는 요소들이 무엇인지 보다 더 큰 시각으로 찾아가는 게 현재 가장 집중해야 할 미션인 거 같아요.
어떤 조직에서 잘 맞는 방식이 또 다른 조직에서는 안 맞을 수도 있고, 또 구성원 모두가 만족할 수 있는 문화를 만든다는 게 쉽진 않잖아요. 그런 것들을 같이 고민하면서 만들어가고 싶어요. 그리고 무신사 테크 조직의 구성원분들이 회사에 더 만족하고, ‘우리는 이렇게 일하고 이런 문화를 가지고 있어’라고 명확하고 자랑스럽게 말할 수 있는 순간까지 최선을 다하고 싶어요.
장기적으로는 조직과 사람을 더 깊게 이해하고 방향을 설정할 수 있는 그런 역량을 좀 더 키워가는 커리어 패스를 밟아가고 싶어요.
Q. 이 인터뷰를 읽고 계신 독자님들 중에는 DevRel 직군에 취업을 꿈꾸는 취업 준비생들도 계실 거 같은데, 후배들을 위한 조언 한마디 부탁드려요.
협업을 즐기고, IT업계의 사람과의 관계 속에서 영향력을 펼치는 데 관심이 많은 분들이라면 잘 해내실 수 있을 거예요. 많은 사람들을 혼자 상대해야 하는 일이 많은 만큼, 다양한 사람들에 대한 이해와 호기심, 그리고 배려를 갖추는 것의 중요성을 강조하고 싶고요. 커뮤니티에서 다양한 역할을 자처하면서 DevRel의 밑거름을 쌓는 동시에 즐겁고 뭉클한 추억도 많이 만들다 보면 언젠가 DevRel 실무자로 만날 날이 있을 거라고 생각해요. 파이팅입니다 :)
Q. 마지막으로 DevRel을 한 문장으로 표현해주세요!
Developer Relations === Versatile Player!
조직 혹은 커뮤니티 생태계에 대한 깊은 이해로 다양한 사람들과의 협업 속에서 성격이 제각기 다른 프로젝트를 해내야 하는 DevRel을 Versatile Player(다재다능한 사람)라고 말하고 싶어요.
—
이 인터뷰를 만든 사람들☕️:
여기까지 위민후코드 서울이 대신 해주는 Olivia님과의 첫 번째 커피챗이었습니다. 독자분들께 유익한 콘텐츠가 되었길 바라며, Nailed IT 다음 시리즈는 서비스 기획자와의 인터뷰로 돌아오겠습니다!
서비스 기획자, PM, PO에 대해 궁금한 점이 있다면 아래의 설문에 자유롭게 질문을 남겨주세요! (👉 설문하러 가기)
