온보딩 프로그램​

MongoDB의 온보딩 프로그램은 내가 지금까지 경험한 다섯 회사의 신규입사자 교육 중 단연코 최고였다.

몇 주에 걸친 Leadership Commitment 시리즈는 MongoDB 제품의 설계 이념, 핵심 가치, 리더십 원칙, 고객 여정 그리고 포용성 등 여러 주제로 이뤄진 핵심 교육이었는데, 상당히 밀도 있고 전달력 있게 구성되어 있었다. 특히, 많은 내용을 CEO를 포함한 회사 임원진이 직접 설명한다는 점이 인상적이었다.

신규 입사자 기술 트레이닝은 MongoDB의 핵심 기능, 문서형 데이터 모델링, Atlas (MongoDB 클라우드 개발자 데이터 플랫폼), 인덱스, 분산 아키텍처, 관리자 기능 등의 주제로 구성된 총 20여 시간의 교육이었다. 챕터별 영상을 다 보면 내용을 이해했는지 확인할 수 있는 퀴즈를 풀었다. 프로비저닝된 MongoDB 클러스터에서 예제를 직접 실행해 볼 수 있어 실습에 큰 도움이 되었다.

전사 온보딩뿐 아니라, 조직별 온보딩 프로그램도 마련되어 있었는데 나는 마케팅과 Developer Relations 조직 고유의 신규입사자 교육 자료까지 둘러보고 좀 더 실무에 가까운 정보를 익힐 수 있었다.

직무에 대해​

입사 전 작성한 지난 글에서 나는 채용 직무기술서와 면접에서 알게 된 것을 바탕으로 내가 맡을 직무를 간략히 소개했다. 입사 후 6주는 무엇보다 내가 앞으로 수행할 업무들을 더욱 깊고 선명하게 이해하게 된 시간이었다.

MongoDB의 슬로건이 Love Your Developers('함께하는 개발자를 사랑하세요')인 것처럼, 개발자는 MongoDB의 성공을 위한 근간이라 할 수 있다. MongoDB의 Developer Relations는 다양한 Advocacy & Enablement 프로그램을 통해 MongoDB를 사용하는 개발자의 생산성을 제고하고 가속한다.

• 시장 인식 제고와 채택을 촉진하는 콘텐츠 생성
• 워크숍이나 라이브 핸즈온 세션 등을 통한 개발자 교육
• 전략 고객사의 관심 유도 및 데이터 모델링 컨설팅

첫 출장​

입사 2주 차에 첫 출장을 다녀왔다. 마닐라와 호찌민에서 각각 개최된 MongoDB Days였다. 개발자 교육 및 데이터 모델링 컨설팅을 포함한 행사이기 때문에, 온보딩 이후 맡게 될 일들을 미리 경험할 기회였다.

DevRel APAC 팀 동료 Sourabh과 함께	DevRel APAC 팀 동료 Wenjie와 함께

무엇보다 DevRel APAC 팀 소속의 Developer Advocate 동료들을 직접 만날 수 있어 좋았다. 연말에는 계획된 행사가 적은데, 11월 입사라 운 좋게 시기가 딱 맞았다. 팀 동료인 Sourabh과 Wenjie는 적어도 1년 이상 먼저 Developer Advocate 일을 시작한 선배들이다. 이번 출장에서 그들이 다양한 세션을 흡인력 있고 프로페셔널하게 전달하는 것을 보며, 나도 얼른 이들처럼 잘해야겠다는 생각이 들었다.

MongoDB Days 호찌민 행사를 마치고 ASEAN 지역 직원들과

또 ASEAN 지역의 Solutions Architect, Field Marketer, Customer Success Manager 등과 인사를 나누었고, 하나의 행사를 기획하고 진행하는 데 있어 Developer Advocate이 이들과 어떤 식으로 협업하는지를 보고 배울 수 있어서 내게는 많은 도움이 됐다. 행사 중간중간, 또 행사가 끝나고 다 같이 모인 저녁 자리에서는 ASEAN 지역 직원들과 다양한 주제로 이야기를 나눴다.

두 번째 출장은 1월에 타이베이에 가는 것으로 계획되어 있다. 여기서 나는 MongoDB에서의 첫 개발자 세션을 진행할 예정이다. 긴장도 되지만 설렌다.

한국지사 인트로​

한국지사 오피스에서 내려다보이는 잠실 뷰

회사에서 한국에 베이스를 두고 있는 나를 채용한 것은, 당연히 한국의 주요 고객 및 개발자를 대상으로 한 활동을 전개하기 위해서다. 그렇기에 6주 동안 MongoDB 한국지사 직원분들께도 다양한 기회를 통해 인사를 드렸다. APAC 지역에서 Developer Advocate 들이 로컬 담당자들과 함께 일하는 모델을 참고해, 한국에서도 유사한 협업 형태를 단계적으로 만들어 나갈 예정이다.

지난주에는 한국지사의 연말 파티에 다녀오기도 했는데, 외국계 회사의 문화는 그동안 다녔던 한국 IT 기업과는 또 다른 재미와 독특함이 있다는 생각이 들었다.

소통, 소통, 소통​

회사 전반에 걸쳐 거침없이 흐르는 전방위적 소통이 인상적이었다.

나의 매니저인 Nick은 수시로 1:1 세션을 만들어 온보딩 과정을 체크하고, 도와줄 것이 없는지 성심껏 묻고는 했다. 한국의 정치적 상황에 따른 나의 안위를 물어봐 준다거나, 가족을 챙겨야 하는 일이 생기면 이를 우선시하라는 말을 보태준다거나 하는 것을 통해 인간적/심리적으로 잘 보살핌을 받는 느낌을 받았다. 매니저와 IC(Individual Contributor, 실무자)가 분리된 구조는 들어보기만 했는데, MongoDB에 입사하며 처음 경험해 보니 말 그대로 매니지먼트를 담당하는 사람이 있다는 사실이 IC에게 주는 편안함과 편리함 같은 것을 느낄 수 있었다.

또한 다양한 조직에서 앞으로 밀접하게 일하게 될 직원 예닐곱 명과 캐주얼한 소개 시간을 가지며 그들의 R&R에 대한 설명을 들을 수 있었는데, 나는 이 시간을 나의 배경과 관심사에 관하여 이야기를 하는 기회로 삼을 수 있었다. 관심 있는 일에는 좀 더 적극적으로 의사 표현을 하고, 궁금한 점은 지체 없이 물어보는 것이 당연하고 장려되는 환경이라 답답하지 않고 재밌었다.

마지막으로 회사의 C 레벨들이 직접 참여하는 월간 All-Hands에는 두 번 참여했다. 직원들은 사전에 질문을 남기거나 실시간 채팅으로 궁금한 점을 물어볼 수 있었는데, 그 질문의 주제가 광범위하고 깊이가 있었고 C 레벨들의 답변은 솔직하고 막힘이 없었다. 아주 인상 깊었다.

이상이 MongoDB에서 보낸 첫 6주간의 기록이다. 앞으로 MongoDB에서 보낼 날들이 기다려진다. 1~2월이 되면 이제 조금씩 실무를 맡게 된다. 즐겁게 잘 해보자!

내 이름은 불교적인 의미를 담고 있고, 우리 집도 불교를 믿는 가정이다. 하지만 어째서인지 나는 기독교 계통의 유치원을 다녔다. 이젠 너무나도 오래된 일이라 대부분의 기억은 희미하지만, 그중에서도 특별히 기억나는 한 사람이 있다. 유치원 밴의 문을 열어주고 안전한 등하원을 책임지며, 하루를 시작하고 마무리할 때마다 기분을 물어봐 주고, 아이들의 행동을 살피며 친구와의 관계를 개선하기 위한 조언을 해주는 사람. 우리는 그를 '전도사님'이라고 불렀고, 내 기억 속 전도사란 그런 사람이었다.

테크 에반젤리스트: 기술 전도사​

한참의 시간이 지나 어른이 되고 나서 나도 전도사의 일을 하게 됐다. 다만 한국어 표현 대신 '에반젤리스트'라는 영어 이름으로 불리는 역할인데, 특정 기술을 매개로 개발자들과 관계를 형성하고 기술 생태계를 만들어나가는 역할이기에 테크 에반젤리스트라고 한다.

테크 에반젤리스트가 하는 역할은 어릴 적 전도사가 했던 일과 많은 부분 유사하다. 개발자들에게 기술 제품으로의 첫 여정을 안내하고, 그들이 제품을 사용하는 데 어려움이 없는지 살피며, 제품을 어떻게 활용하면 좋을지 전파하는 역할이다.

내가 이쪽으로 커리어 방향을 모색하게 된 것은 블로그에 앞서 소개한 나의 관심사 및 성향과 깊은 관련이 있다. 나는 개발자로 일하는 내내 테크 업계에서 소통과 친절함이 부족한 영역을 항상 주시해왔다. 나에게 지금 일하면서 마음을 들끓게 하는 지점이 있다면 그것은 '개발자 경험'이라 하겠다.

사용자 경험으로 대변되는 일반 사용자 향 제품도 그렇지만, 개발자들이 사용하는 기술 제품 또한 절대로 '만든다고 누군가 저절로 쓰지' 않는다. 그 과정에는 사내외 개발자들과 끊임없는 소통과 챙김이 있어야 하고, 개발자들에게 필요한 적절한 문서와 교육이 제공되어야 한다. 그리고 그런 노력은 아마도 그러한 일에 전념하는 인력의 배치로 나타날 것이다. 테크 에반젤리스트는 그런 역할을 수행한다.

네이버제트에서의 경험​

처음 테크 에반젤리스트 일을 경험했던 곳은 최근까지 다닌 메타버스 서비스 '제페토'를 운영하는 네이버제트였다. 제페토 월드 SDK라는 개발자 도구를 사용하는 생태계를 조성하고, 개발자들에게 기술 콘텐츠를 제공하며, 교육과 기술 지원까지 폭넓게 담당하는 포지션이었다. 아직 B2B SaaS 및 API/SDK 등 기술 제품 비즈니스가 온전히 뿌리내리지 않은 한국에서는 보기 드문 기회였다. 특히 제페토가 이미 어느 정도 글로벌 사용자를 확보한 상태였기에 제페토 월드를 개발하는 세계 여러 나라의 개발자 및 협력사들과 소통할 수 있다는 점이 매력적이었다.

한번은 화상으로 이스라엘에 있는 회사의 기술 지원을 한 적이 있다. 협력사가 출시 일정이 촉박한 상태에서 꼭 필요로 하는 기능이 있어서, SDK 개발팀에 전달해줄 수 있느냐는 부탁이었다. 그들의 요구사항을 듣고 SDK 개발팀에 이슈를 등록했으며, 신규 기능은 비교적 높은 우선순위로 개발됐다. 나는 그 사용법을 정리해 협력사와의 팔로업 세션에서 직접 설명했다.

내게는 이 일련의 과정이 정말 재미있고 보람 있었다. 그뿐만 아니라 개발자들을 위한 문서를 작성하고 샘플 코드를 만드는 일 또한 개발자로서 코드를 만드는 것과는 또 다른 재미와 일로서의 가능성을 가지는 분야라는 것을 알게 됐다. 회사의 운영 방향에 따라 에반젤리스트 일을 생각했던 만큼 길게 하지는 못했는데, 커뮤니케이션을 통해 기술 제품을 사용하는 개발자와 파트너의 성공을 돕는 일을 좀 더 깊고 전문적으로 해보고 싶다는 갈증은 커졌다.

새로운 도전: 몽고DB 디벨로퍼 어드보킷​

그러던 중 약 3개월 전, 몽고DB 리쿠르터에게 링크드인으로 연락을 받았다. 몽고DB에서 시니어 디벨로퍼 어드보킷으로 일하는 것에 대한 의사를 묻는 내용이었다. 가볍게 이야기를 들어보았고 좋은 기회라는 생각이 들어 지원했다. 그렇게 약 한 달 반 동안 총 열 번의 인터뷰를 거쳤고, 제안을 수락해 내일 첫 출근을 앞두고 있다.

디벨로퍼 어드보킷은 테크 에반젤리스트와 큰 틀에서 유사한 역할이지만, 뉘앙스의 차이가 있다. 특히 에반젤리스트(전도사)라는 말이 주는 종교적인 뉘앙스에서 벗어나, 어드보킷(지지자)으로서 개발자의 편에서 제품을 제공하는 회사와의 가교 구실을 함을 의미한다.

나는 시니어 디벨로퍼 어드보킷으로서, 면접에서 이미 수차례 만났던 능력 있는 팀원들과 함께, 한국을 포함한 APAC 지역에서 몽고DB의 개발자 활성화(Enablement) 및 관계 형성을 위한 일을 수행할 예정이다. 여기에는 주로 개발자를 대상으로 한 기술 교육 콘텐츠 작성, 워크숍, 핸즈온 세션이 포함된다. 필드 마케팅팀과 함께 고객사 및 개발자와의 관계 형성을 위한 효율적인 전략을 세우는 일도 직무 요구사항의 일부이다.

새로운 기회에 대해 여러모로 설렘과 기대를 안고 있다. 새롭게 학습할 지식과 나의 경험을 잘 활용해 팀에 빠르게 기여하고 싶다. 조만간 그 과정에서 배우고 느낀 바를 블로그를 통해 또 소개할 수 있기를.

선물의 의미​

어떤 대상을 새로운 시각에서 접근해 이해하고자 할 때면 우리는 종종 비유를 활용한다. 기술을 선물로서 바라보는 시도는 선물의 본질을 이해하는 것에서 시작된다.

아마존에서 상품을 주문할 때 마주치는 'This is a gift (선물입니다)' 체크박스는 단순히 영수증 제외나 메시지 카드 추가 같은 기능적 차이만을 의미하지 않는다. 그것은 더 깊은 '마음 씀'을 상징한다. 우리는 선물을 고르는 순간 거래 그 자체를 넘어 받는 이와의 관계를, 그들의 필요를 더 깊이 생각하게 된다. 시스템이 전면에 내세우는 베스트셀러나 추천 상품을 넘어, 받는 이의 취향과 상황을 고려해 더 세심하게 고른 선택지들 속에서 결정을 내리게 되는 것이다.

친구의 이름을 그저 문자열로 바라보다​

이러한 관점의 전환이 얼마나 중요한지, 나는 프로그램 중 겪은 작은 사건을 통해 깊이 깨닫게 되었다.

프로그램 3일 차, 일본인 참가자 키와코는 프로그램에 참가한 학생과 SFPC 교사, 그리고 YCAM 스텝을 대상으로 하는 '커피챗' 아이디어를 제안했다. 커피챗 참여를 원하는 사람들을 모아 무작위로 1:1 짝을 지어주고, 서로 알아갈 수 있도록 하자는 취지였다. 나는 태국인 참가자인 짐과 함께 이 무작위 1:1 매칭 시스템 구현을 자원했다. 짐은 프론트엔드를 맡았고, 나는 백엔드를 맡아 매칭 로직과 매칭 기록을 저장하는 기능을 작성했다. 구현은 하룻밤이면 충분했다. 커피챗 시스템을 제공한 첫날, 커피챗을 신청한 모든 이가 화면에 표시된 짝을 찾아 시간을 보냈다.

사건은 매칭을 운영한 둘째 날 생겼다. 이날 커피챗을 신청한 인원은 홀수였다. 이 경우 우리가 만든 시스템은 마지막에 홀로 남은 사람을 ("홍길동", "")와 같이 처리하고 있었다. 타카시라는 친구의 이름이 스크린 맨 아래 짝없이 홀로 나타났고, 그는 다소 당황한 눈치였다. 키와코는 재빨리 그를 마지막 그룹에 포함해 3인 커피챗을 만들어줬지만, 나는 깊은 좌절감을 느꼈다. 그때까지 나는 이름 목록을 단순한 텍스트 데이터 배열로만 바라보았을 뿐, 각 이름 뒤에 있는 사람들의 경험과 감정을 생각하지 못했던 것이다.

누군가와 이야기를 나누게 될 그 순간을 기대하는 사람들을 위한 선물로, 이 시스템을 바라봤더라면...

개발자에게도 선물을​

2019년의 이 작은 사건 이후, 나는 개발에 참여하는 제품을 선물로 여기는 마음을 가져왔다. 사실, 제품을 선물로 여기는 관점은 이제 업계에 널리 도입된 사용자 경험(User Experience, UX) 중심의 제품 설계 및 개발과 맥을 같이 한다. 그런데 우리가 보통 이야기하는 UX의 맥락은 대개 B2C 서비스의 최종 사용자에 한정되어 있다.

백엔드 API 개발자로 경력을 시작한 사람으로서 내가 더 깊이 고민하게 된 것은 개발자 경험(Developer Experience)이다. '사내용'이라는 이유만으로 레퍼런스도 없는 API, 개발자 스스로도 읽어보지 않은 듯한 문서, 원칙 없는 엔드포인트 설계를 마주할 때마다 나는 의문을 품었다. 소프트웨어를 모듈로 나누고, MSA를 도입하고, 이에 맞춰 조직을 구성하면서도 정작 이들이 소통할 프로토콜을 정리하는 일에는 왜 이토록 소홀한가? 심지어 API나 SDK를 B2B로 제공하는 회사들의 제품에서 '만들면 누군가 쓸 거야'라는 안일한 마음가짐이 느껴질 때면 더욱 안타까워진다.

그러나 개발자들도 마땅히 좋은 선물을 받아야 하지 않을까? 우리는 개발자들에게 선물을 주는 일에 더 많은 가치를 두어야 한다. 그리고 그 선물은 결국 우리 개발자들이 서로에게 주고받아야 할 것이다.

그동안 나는 이러한 생각들을 실천할 수 있는 직무를 찾아 여러 시도를 해왔고, 11월부터 Developer Advocate로서 새로운 도전을 시작하게 되었다. 기술이 선물이 될 때, 우리는 단순한 기능 구현을 넘어 사용자와 개발자 모두의 경험을 더 깊이 고민하게 된다. 이는 결국 더 나은 개발 문화, 더 나은 제품으로 이어질 것이다. '선물로서의 기술'이라는 관점이 가져올 변화를 이제 본격적으로 탐구하고 실천하고자 한다.

다음 글의 주제: 기술의 선물을 전하는 사람 - Developer Advocate 직무를 시작하며

나는 설명서를 좋아하는 사람이다. 거의 모든 공산품과 서비스에 대해, 설계 의도와 기능 그리고 브랜딩 텍스트를 살펴보기 전에는 손을 대지 않는다. 첫 차를 사고서, 일단 차는 모셔두고 설명서를 1페이지부터 정독하는 모습을 친구들이 신기해했던 게 기억난다. 식당에서 식사가 나오기 전까지 '메밀의 효능' 같은 걸 읽는 게 나다.

그것은 내가 제품을 향유하는 방법이다. 좋은 설명서를 보면 제품을 사용하기 전부터 이미 기분이 좋다. 그만큼 나는 제품 설명을 사용자 경험의 중요한 일부로 생각하고 있다. 다양한 설명을 보다 보니 자연스럽게 취향도 생겼는데, 요즘은 '사용자 임파워먼트(empowerment)'에 충실한 설명을 좋아한다. 이것에 대해서는 따로 쓰겠다.

소통하는 개발자​

이러한 관심과 성향은 내가 개발자로 일을 시작하고 난 이후에도 이어졌다. 지난 10년 동안 나는 개발에 참여하는 제품과 관련한 다양한 종류의 설명을 직접 해볼 기회를 적극적으로 찾아다녔다. 그동안 짧거나 길게 경험해봤던 일들을 나열하자면 다음과 같다.

• B2B, B2C, 인터널 제품에 대한 사용 가이드, API 레퍼런스 문서 및 릴리즈노트 작성
• SDK 활용 예제 코드 작성 및 데모 어플리케이션 제작
• 제휴사 및 개인 크리에이터 기술지원 세션
• 사내 기술과제 발표를 위한 자료 작성
• 회사 기술블로그, 리서치 아카이브 기고 프로세스 운영

또 나는 팀으로 일을 하는 과정에서 항상 설명의 힘을 믿어왔다. 회사가 헛바퀴 돌지 않으려면, 조직의 역할과 일의 목적을 각자가 이해하고 정렬하는 것이 중요하다고 생각한다. 팀의 구성원으로서 나는 설명하는 리더를 지지했다. 또 팀을 맡았을 때는, 내가 설명에 할애하는 시간이 그 설명을 참조하는 팀내외 구성원들의 숫자만큼 배로 시간을 아껴준다는 신념으로 일했다.

예를 들어 나는 팀 내 프로젝트의 Readme를 작성한다든지, API 변경점에 대해 정제된 마이그레이션 가이드를 제공한다든지 하는 일을 가치 있게 여겼다. 또 회의 전에 안건을 사전 공유하고, 회의 후에 회의록을 공유하는 일과 팀의 문서 베이스를 주기적으로 최신화하는 일을 중요시했다.

개발자로서, 무언가 설명하는 일들을 할 때 나는 만족을 느껴왔다. 그 동안 ‘소통 역량’ 항목에서 항상 좋은 평가를 받기도 했기에 나는 그것을 개발 조직 안에서 살아갈 나의 무기로 여겼다.

전문성의 확장 - 개발자를 넘어서​

개발 조직의 멤버로 나같은 사람 하나쯤 두는 건 나쁘지 않은 구색이었을 거다. 하지만 연차가 쌓이면서, 어느 순간부터 커리어 확장에 대한 욕심이 났다. ‘개발 조직에서의 소통’을 내 특기라 할 수 있다면 그 분야에서 전문성을 쌓고 영향력을 넓히고 싶어졌다. 그랬더니 막상 내 커리어 패스에서 개발자로서는 위가 보이지 않는다는 것을 깨달았다.

7년 차 즈음 백엔드 개발자 면접에서 면접관이 물었다. ‘팀에 합류하면 가장 먼저 하고 싶은 일이 무엇인가요?’ 나는 솔직하게 대답했다. ‘우리가 운영하는 API 문서가 제대로 되어있는지 먼저 파악하고 개선하겠습니다. 또 API에 의미 없는 요청 파라미터나 응답 필드가 있다면 정리하겠습니다.’ 면접관은 고개를 갸우뚱 했다.

이런 순간들을 포함해 종합적으로 판단건대 개발자로서는 ‘소통 역량’이 회사에게도 나에게도 본질적으로 더 좋은 밥을 먹여주지 않는 것 같았다. 그 동안 내가 무기로 여겼던 장점이 ‘제가 이래뵈도 사람은 착합니다’를 말하는 수준으로 뭉툭해보이기까지 했다. 내 장점을 살려 전문성을 쌓고 영향력을 넓히기 위해서는, IC 개발자를 넘어 다른 직무로 전직해야 한다고 믿게 되었다.

블로그를 시작하며​

전직을 위한 탐색과 시행 착오는 진행 중이며 쉽지 않다. 급변하는 세상 속에서 어쩌면 일하는 동안 계속 고민해야 할 문제라고도 생각한다. 하루하루를 보내는 마음이 불안하고 초조하기도 하다. 이 블로그를 시작하는 이유에는 이러한 감정들을 조금 달래보고자 하는 것도 있다.

나와 같거나 비슷한 고민을 하는 사람이 나뿐일 리 없기에, 이 블로그를 계기로 커리어에 대한 생각과 정보를 나누고 싶다. 또 어쩌면 이 블로그를 통해, 내가 가진 경험과 역량을 찾는 누군가가 나를 발견해 새로운 기회로 이어질 수도 있지 않을까.