본문 바로가기

책을읽자

기업의 성공을 이끄는 Developer Relations (2/2)

반응형

2022.07.12 - [책을읽자] - 기업의 성공을 이끄는 Developer Relations (1/2) 에 이어지는 글입니다.

 

6장 커뮤니티 찾기

 

어느 정도 규모가 있는 회사인 경우에는 사내 커뮤니티가 활성화된 경우가 많습니다. 사내에 공유되는 콘텐츠를 만들고 사내에서만 공유되기도 합니다. 그런 사례들은 예외로 하고 일반적인 기술 분야에서의 이야기겠죠.

 

타기팅이 맞는 표현이라는 것도 글을 읽으면서 알게 됐습니다. 

 

 

한 가지 중요한 사실은 여러분이 타기팅하려는 회사 유형(스타트업, 중소기업, 대기업)에 상관없이 개발자들은 다른 개발자들과 어울리며 같은 장소에서 정보를 얻는다는 점입니다.

 

'커뮤니티의 기술' 저자 조노 베이컨은 읽기 커뮤니티의 예로 스타트렉 팬 커뮤니티를 이야기합니다. 물론 그들도 팬픽을 만드는 문화가 있긴 하지만 그건 예외로 하고. 쓰기 커뮤니티는 사람들이 모여 협업을 하고 뭔가 만들어내는 것이라고 정의합니다.

다른 사람을 돕는 성향의 커뮤니티를 ‘쓰기 커뮤니티Write Community’라고 합니다.
읽기 커뮤니티는 프로덕트를 좋아하지만 오픈소스 프로덕트에 적극적으로 기여하지는 않는 활성 유저 기반을 가지고 있습니다.

 

이건 무슨 뜬금없는 이야기지 싶었는데 일단 2015년에 'Chop Wood Carry Water: How to Fall in Love with the Process of Becoming Great'이라는 책이 나왔습니다. 그 책에서는 일본에 간 John이라는 소년의 에피소드가 담겨 있는데요. 이 이야기가 DevOps 진영에서 사용되면서 일상적인 작업을 중요하게 여기는 이야기가 만들어졌습니다.

http://radar.oreilly.com/2015/01/chop-wood-carry-water.html

 

해당 글의 원문(추정되는 글)은 중국 선종의 거장 중 한 명인 방거사(龐居士)가 전등록(傳燈錄)이라는 책에 남긴 글이라고 합니다.

 

신통과 묘용은 다만 물 긷고 나무하는 것(神通并妙用 運水及搬柴)

선종 불교에 “나무를 베고 물을 길어라”라는 속담이 있습니다. 깨달음을 얻기 위해서도, 깨달음을 얻은 후에도 기본적인 것을 꾸준히 해나가야 한다는 뜻입니다. 이 문구는 데브옵스 커뮤니티에서 자주 인용되다가 나중에는 쿠버네티스(컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈소스 시스템)의 행동 요령 중 하나를 일컫는 말이 되었습니다.

 

많은 기업에서 오픈소스 프로젝트를 하면서 오해하는 부분입니다. 오픈소스라서 우리는 유지보수 책임을 지지 않는다 뭐 이런 스토리로 오픈소스 프로젝트를 운영한다고 이야기하기도 합니다.

프로젝트를 오픈소스로 만들려면 깃허브 기반 저장소에서 ‘공개make public’ 버튼을 클릭하는 것 이상이 필요합니다. 오디언스와 고객을 이해하는 게 가장 중요하다는 것은 누구나 알고 있는 사실일 텐데, 프로젝트를 오픈소스 소프트웨어로 사용할 수 있도록 결정할 때도 마찬가지입니다.
“‘진짜 일’은 프로젝트에 사람들이 기여하기 시작할 때 시작됩니다. 프로젝트에 대한 활동은 더 많은 활동으로 이어집니다. 그래서 새로운 기여를 인정하고, 새로운 기여자가 환영받는다고 느끼는 것이 중요합니다. 하지만 모든 기여가 좋은 변화를 가져오는 것은 아니기 때문에, 이러한 기여들을 초기에 다루는 방법을 생각해야 합니다.”
여러분이 오픈소스 소프트웨어를 만든 진짜 이유가 단지 새로운 커뮤니티로 사람들을 끌어들이기 위해서이고 이 커뮤니티에 그다지 열정을 쏟지 않을 것임을 개발자들이 알게 된다면 여러분은 아무것도 얻을 수 없을 것입니다.

 

7장 건강한 커뮤니티 만들기

Ritual은 애자일 쪽에서 데일리 스크럼 같은 행사를 지칭하기도 합니다. 본문에서는 약간 다른 의미지만 의식적인 절차가 중요하다는 의미로 사용한 듯합니다.

반복을 통해 의미를 부여하는 ‘리츄얼Ritual’과 전통은 커뮤니티의 ‘끈끈함’에 좋은 원천이 되어줍니다.

 

책에 소개된 링크가 변경됐습니다. 링크 변경은 어쩔 수 없죠 ~~ 슬랙의 경우 릴리스 노트도 한국어로 깔끔하게 번역을 해주고 있습니다. 간혹 번역되지 않는 항목이 있긴 합니다만 한국어 서비스를 정식으로 하기 때문에 잘 대응해주고 있습니다.
https://slack.com/intl/ko-kr/release-notes/windows
https://slack.com/release-notes/windows

앱의 릴리스 노트를 잘 쓰는 회사가 바로 슬랙(Slack)입니다. 저는 체인지 로그나 릴리스 노트를 잘 읽지 않는데, 슬랙의 앱 업데이트 내용만은 꼭 챙겨봅니다.

 

'디스코스'가 '디스코드' 오타인줄 알았는데 전혀 다른 서비스네요. 하여간 뭐.
최근에는 기업에서 디스코드를 사용하는 사례도 보이긴 합니다. 디스코드 채팅이라고 표현하기도 하는데 포럼이라고 해도 무리가 없겠네요. 슬랙과 비슷해 보이긴 하지만 디스코드만의 장점이 있는지는 살펴봐야겠습니다. 토스 페이먼츠에서 디스코드 채팅으로 고객지원을 하고 있는데 일단 무료이기도 하고 젊은 세대들에게 익숙한 플랫폼이라는 점 때문이라 선택한 것이 아닌가 싶네요.

커뮤니티에 질문할 수 있는 포럼 기능을 넣어서 고객 지원 팀의 부담을 덜고 싶나요? 몇 가지 좋은 포럼들이 있습니다. 디스코스Discourse나 바닐라Vanilla는 토론을 하거나 이야기하기에 좋은 포럼입니다.

 

8장 오프라인 모임: 어떻게, 왜, 어디서 해야 할까?

문제를 명확하게 해결하지 못하더라도 전달하는 메시지를 수정할 수 있는 기회라는 점이 인상적입니다.

만약 여러분이 새로운 오디언스 세그먼트에 접근하려고 한다면, 그 오디언스들이 자주 하는 질문들과 해결하고 싶어 하는 문제를 메모하세요. 여러분의 프로덕트가 오디언스들의 문제를 해결해줄 수도 있겠지만, 이에 앞서 그 커뮤니티의 특징을 잘 반영해 메시지를 업데이트할 필요가 있습니다.

 

자신의 경험을 풀어내는 것이 어쩌면 가장 자연스러운 스토리라인입니다. 뭔가 위기의 순간을 어떻게 해결했는지 공유하는 세션이 아마도 인기가 있지 않을까 싶네요.

블릿 포인트와 그림으로 가득한 슬라이드를 만들기보다 기승전결이 있는 스토리를 만드세요. 잘 만들어진 스토리라인은 참석자들의 마음 속에 더 오래 남습니다. 기억하세요, 우리는 좋은 이야기꾼이 되어야 합니다.

 

9장 자주 생기는 커뮤니티 이슈 다루기

제목은 커뮤니티 이슈지만 실제 다루는 내용은 데브렐 팀에 대한 이슈가 많이 담겨 있습니다.

한국에 한정하면 상대적으로 이런 이슈가 적겠지만 글로벌로 넘어가거나 북미만 하더라도 이런 이슈가 영향을 미칠 수 있습니다. 예전에 어도비 MAX 행사에 참여하면서 에반젤리스트들이 묵는 숙소에 가본 적이 있는데 술과 게임 콘솔 등 즐길 수 있는 도구들이 잔뜩 있더군요. 스트레스가 많은 만큼 집에서처럼 여행 중에도 이를 해소할 수 있는 장치들을 많이 준비하는 것 같았습니다.

그러나 데브렐에서 번아웃은 훨씬 더 깊고 장기적인 문제가 될 수 있습니다. 만성적인 스트레스와 좌절로 인한 정서적 피로는 과도한 출장으로 인한 육체적 피로와 꼭 참석해야 하는 콘퍼런스에서 보내는 시간이 누적된 결과입니다.

 

저녁이 있는 삶이라는 건 딱 정해진 시간 내에 과업에만 집중할 수 있는 환경에만 해당할 뿐 그 외의 경우에는 완벽하게 분리하기가 어렵습니다. 특히 애드보게이트 팀처럼 작업의 공간이나 시간 자체가 한정되어 있지 않은 경우에는 더욱 그렇겠죠.

여러 어려움과 한정된 리소스라는 문제가 한데 뭉쳐 우리의 에너지를 빼앗아가기 시작합니다. 그런데도 사람들은 도망치기보다 일을 계속하는 경향이 있습니다. 이러한 문제들의 첫 번째 신호가 나타나더라도 사람들은 피하지 못합니다. 왜냐하면 우리는 일을 단순히 직업이 아닌 우리 자신으로 여기고, 일과 자신의 삶을 구별하지 않기 때문입니다.

 

반대가 아닌가 싶기도 한데 그 앞부분의 맥락을 보면 맞는 것 같기도 하구요.
원문은 "There's no end to the work that we could do, but there is an end of the work that we need to do at that moment."

번역문에서 'at that moment'라는 표현이 빠지면서 살짝 의미가 애매해진 것 같긴 하네요.

우리가 ‘할 수 있는 일’에는 끝이 없지만, 우리가 ‘해야 할 일’에는 끝이 있습니다.

 

* 원서에서는 특정 인물의 인터뷰가 나올 때 캐리커쳐 비슷하게 일러스트를 사용합니다. 예를 들어 9장에 트위터의 Andy Piper가 나올 때 이미지는 아래와 같은데요.

 

 

번역서에서는 트위터라는 부분만 강조해서 캐릭터를 사용했습니다. 원서 일러스트는 자세히 보니 좀 무섭네요.

 

 

10장 퍼스널 브랜드 만들기

 

음. 저런 문구가 법적인 효력은 없나 봅니다. 뭐 사실 저렇게 이야기해도 딱히 파격적인 내용을 작성하는 경우는 별로 없습니다. 진짜 뭔가 보이지 않게 이야기하고 싶다면 블라인드 같은 곳에 글을 올리겠죠. 다만 자신의 회사에 몇 명 안 되는 데브렐 팀원이라면 조심해야겠죠.

SNS 프로필에 ‘포스팅 내용은 제 개인적인 견해이며 회사를 대표하지 않습니다’라고 써두는 경우를 볼 수 있습니다. 그렇게 쓴 의도가 이해는 갑니다. 하지만 여러분이 회사를 공식적으로 대표하는 경우, 이 문구를 써둔다고 해서 나중에 SNS에 올린 내용으로 부적절한 일이 생겼을 때 면책 사유가 되거나 고용주가 여러분을 해고할 수 없다는 건 아닙니다. 여러분의 의견, 생각, 포스팅은 실제로 여러분의 회사를 반영할 수밖에 없습니다. 왜냐하면 2~3장에서 이야기했듯이 여러분은 회사와 커뮤니티를 잇는 다리 역할을 하기 때문입니다. 개인 SNS도 마음대로 못 하냐고 생각할지도 모르겠지만, 이것이 데브렐 전문가로서 우리가 살아가는 현실이며 받아들여야 할 부분입니다.

 

* 부록 A. 출장 보고서
꼭 출장이 아니더라도 컨퍼런스 등에 참석하고 나서 스스로 정리해보는 것도 좋을 듯합니다.

* 부록 원문은 'Back Matter'라는 이름으로 PDF 파일로 내려받을 수 있습니다.
부록 E. 행사 프로세스와 플레이북 예시(Sample Event Process and Playbook)는 원문으로 나중에 참고해도 좋을 듯하네요.
https://link.springer.com/book/10.1007/978-1-4842-3748-9

* 부록 F. 국내 데브렐은 어떨까요? 

이건 당연히 원서에는 없는 내용입니다. 역자가 직접 작성한 글입니다.

 

* 역자가 정리한 관련 자료 모음입니다.

https://github.com/silverjade/DevRel-Book

728x90