1부와 2부로 나누어서 리뷰를 남깁니다. 책을 읽자 카테고리에 글을 올리는 건 오랜만이네요. 그동안 책을 못 읽기도 했고(타도 넷플릭스!!)...
리뷰라고 했지만 줄 긋고 살짝 메모를 남긴 수준이며 데브렐 중심이 아닌 개인적으로 관심이 있는 부분 위주로 체크한 것이라 책의 전반적인 요약도 아닙니다.
조노 베이컨(기술 리뷰어) 서문
원서 표지에는 'with a foreword by'라고만 표시되어 있는데 어떤 식으로 기술 리뷰를 하셨는지는 알 수 없습니다. 서문 중 인상적인 내용이 있는데요. 이 책이 교과서는 아니라는 거죠. DR은 기술처럼 스펙이 정해져 있는 것도 아니고 '미묘하고 복잡'한 분야라는 것을 알려줍니다.
디벨로퍼 릴레이션, 그리고 우리가 커뮤니티에 광범위하게 참여하고 문화를 만들어내는 것은 아주 미묘하고 복잡하며 상황에 따라 변화하는 분야입니다. 모두를 만족시키는, 한 번에 모든 것을 해결하는 방법 같은 것은 없습니다.
지은이의 말
독특하게 하나의 책 안에서 1부는 의사결정자를 위해 2부는 실무자를 위해 쓴 내용이라고 합니다. 이 책의 원제 'The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success'에서는 그런 의도를 명확하게 드러내고 있습니다. 실제로 데브렐 팀을 운영하고 있는 조직이 아니라면 데브렐 팀이 기업의 비즈니스에 어떤 영향을 줄 것인지를 아는 것이 먼저겠지요(다른 팀도 마찬가지겠지만요). 그런 의미에서 저자의 이런 시도는 흥미롭습니다.
하지만 1부 각 장을 보면 이해관계자보다는 이해관계자를 설득하고자 하는 데브렐 팀을 만들고자 하는 이들을 위한 이야기에 가깝습니다. 실제 오디언스가 다른 것이 아니라 상태가 다른 것이 아닌가 싶네요. 이미 데브렐 팀을 만든 경우에는 우리가 제대로 가고 있는지를 검토하는데 1부를 참조할 수 있을 듯합니다.
타 분야 전문가와 데브렐 전문가 모두에게 유용할 내용이지만, 1부와 2부는 각각 서로 다른 오디언스Audience를 대상으로 하고 있습니다.
1장 커뮤니티란
테크니컬 오디언스와 관련된 커뮤니티의 정의(저자가 만든)입니다. 책 전반적으로 이 정의에 기반해서 설명을 할 것이라고 합니다.
공통의 원칙을 공유할 뿐만 아니라 경험과 노하우를 발전시키고 공유함으로써 그룹 구성원들이 성장할 수 있도록 돕는 집단
커뮤니티가 필요한 이유를 생각할 때 저자가 이야기한 것처럼 당연히 결과를 먼저 생각했습니다. 어떤 성과를 낼 것인지만 생각했지 결과와 이유가 달라야 된다는 것은 생각해보지 못했네요. 개발 회사에서 커뮤니티의 독특한 위치 때문이기도 하겠지만 회사에서 주도적으로 만든 커뮤니티가 성공하지 못하는 이유에 대해서도 결과를 먼저 생각했던 것이 아닌지 따져봐야겠네요.
여러분의 ‘왜’는 결과가 아닌 이유로 움직여야 합니다. 예를 들어, ‘수익 창출’은 고객과의 관계를 발전시키고 리드Lead를 육성하고 멋진 프로덕트를 만든 ‘결과’이지 여러분이 커뮤니티를 원하는 ‘이유’가 아닙니다.
2장 커뮤니티를 회사에 어필하기
개발자 오디언스를 가진 기술 회사(API 기반 제품)의 경우 개발자 경험(DevEx, DX)이 제품을 사용할지 여부를 결정하는 중요한 요소라고 합니다. 개발자 경험은 데브렐의 부분 집합이라고 할 수 있는데 아마도 이후에 이어지는 장에서 자세하게 설명할 듯합니다.
개발자 경험과 데브렐에는 특정 개발자 오디언스의 요구를 이해하고 이를 명확하게 문서화된 기술 콘텐츠로 만들 수 있는 능력을 가진 사람이 필요합니다. 여기서 콘텐츠라 하면, 마케팅이나 세일즈 메시지부터 문서화를 위한 블로그 포스팅과 샘플 앱에 이르기까지 모든 것이 해당합니다.
3장 커뮤니티를 활발하게 유지하기
개발 회사의 소셜 미디어 담당자가 이 정도 수준까지 올라오기는 쉽지 않습니다. 예시처럼 자바와 자바스크립트의 차이만 알면 된다고 할 수 없는 상황들이 많이 나타납니다. 특히 새로운 기능을 소개하는 경우가 그렇죠. 성의 있는 담당자라면 개발 부서를 찾아가 물어볼 수도 있지만 누적된 기술에 대한 이해가 없다면 그 마저 쉽지 않습니다.
주요 오디언스가 개발자인 경우, 소셜 미디어 운영자가 기술 관련 오디언스들과 소통할 수 있는지 확인해야 합니다. 소셜 미디어 운영자가 개발자가 되어야 한다는 말은 아니지만 자바와 자바 스크립트의 차이를 알 정도는 되어야 합니다. 그 차이가 무엇인지 정확하게 알지는 못하더라도 말이죠.
콘텐츠의 핵심 내용을 뽑아낸다는 건 쉽지 않습니다. 엔지니어가 직접 작성한 콘텐츠는 핵심 내용을 잘 드러내지 못하고 있을 수도 있습니다. 그런 경우 먼저 콘텐츠를 정리하고 그 과정에서 소셜 미디어 운영자가 사용할 키워드를 뽑아내야 하죠.
소셜 미디어 운영자는 인기 있는 기술 주제들을 엮을 줄 알고, 사내 개발자들이 쓴 기술 블로그 콘텐츠로부터 핵심 내용을 뽑아 트윗으로 쓸 줄 알아야 합니다. 이를 위해서는 데브렐 팀이나 사내 개발자들의 도움과 지도를 받아야 합니다.
우아한형제들 기술 블로그에 최근 올라온 글만 보더라도(물론 우형은 기술 자체를 제품으로 판매하지 않기 때문에 좀 사정이 다르긴 하지만) '도전기', '공부법' 같은 제목을 달고 있으며 개발자들 역시 이런 콘텐츠에 많이 반응하고 있습니다.
많은 기업에서 자사 블로그를 회사와 관련된 ‘멋진’ 뉴스를 홍보하기 위한 수단으로만 사용합니다. 프로덕트를 만들면서 마주했던 문제들과 어떻게 이 문제를 해결했는지에 대해 블로그에서 이야기한다면 개발자들에게서 훨씬 더 많은 트래픽을 유도할 수 있습니다.
4장 성공을 측정하기
측정은 데브렐 팀이 아니더라도 어려운 일입니다. 물론 제품 자체를 만드는 팀을 제외하고 나머지 팀은 항상 그런 고민을 가지고 있죠. 다만 다른 팀은 인건비 외에 비용을 크게 지출하지는 않지만 데브렐 팀은 큰 비용을 지출할 수 있기 때문에 좀 더 어려운 일이 되어버린 듯합니다.
데브렐 업무를 할 때 가장 어려운 일은 이 팀이 투자 가치가 있다는 것을 증명하는 것입니다. 만약 쉬웠다면 이 책을 쓸 필요도 없었겠지요!
마케팅과는 다르다는 것을 설명합니다. 예를 들어 친구 관계의 ROI를 분석할 수 있냐는 거죠.
커뮤니티 구축은 기본적으로 관계에 대한 것입니다. 어떻게 관계에 대해 손익 분석을 할 수 있을까요?
데브렐 팀 관점에서 기술 문서를 매우 기본적인 요소로 보고 있습니다. 그렇지 않으면 고객에게 가치를 심어줄 수 없다는 것이죠.
여러분은 제한된 시간 내에 프로덕트의 가치를 보여줘야 합니다. 그 누구도 된다고 했던 기능조차 제대로 동작하지 않는 프로덕트를 설치하고 배우려고 많은 시간과 노력을 들이고 싶지 않을 테니까요.
그렇기 때문에 새로운 고객을 위한 문서와 사용자 경험은 최고 수준으로 준비되어 있어야 합니다. 그리고 처음부터 고객에게 가치를 확실하게 심어주어야 합니다.
5장 데브렐 팀 구성하기
저자가 생각하는 데브렐 팀에 꼭 필요한 3가지 역할과 추가적으로 있으면 좋은 역할을 설명합니다. 매니저의 역할은 어떻게 보면 팀을 구축하는 과정부터 시작할 듯합니다. 1인 팀인 경우에는 매니저이자 애드보케이트, 커뮤니티 빌더가 될 수 있겠죠. 역자가 지금 일하고 있는 우형같은 경우에도 1인으로 시작해서 어느 정도 규모를 가진 팀으로 성장한 케이스라 뒤에 설명하는 국내 사례와 비교해보면 이해가 좀 더 쉬울 듯합니다.
이 부분 내용은 나중에라도 체크하고 싶어서 좀 길게 줄을 그어보았습니다.
(필수)
- 데브렐 매니저
데브렐 매니저는 외부 요청으로부터 팀을 보호하고, 관련 없는 일은 원래 부서로 되돌려 보냅니다. 또한 팀이 정기적으로 받고 있는 피드백을 적절한 부서와 사람들에게 전달합니다. 매일 팀이 필요로 하는 것과 니즈를 다룰 뿐만 아니라, 팀이 나아갈 방향에 대한 전략을 세우기도 합니다.
- 디벨로퍼 애드보케이트(기술적 기여자)
디벨로퍼 애드보케이트라는 직함을 가진 사람들은 개발자이며, 이들의 주 목표는 회사에서 커뮤니티를 대변해 목소리를 내는 것입니다. 이들은 커뮤니티에 대한 전문가이자 대변인입니다. 디벨로퍼 애드보케이트 업무는 매월 기술 콘텐츠를 만들고, 정기적으로 콘퍼런스에서 발표하고, 새로운 좋은 코드들을 계속해서 공부하고, 프로덕트를 코드단까지 내려가 깊게 파헤치고, 샘플 애플리케이션과 SDK를 만들어내는 매력적인 일입니다. 그렇지만 이 JDJob Description에는 사실 3개의 직무가 합쳐져 있다는 것을 꼭 알아두세요.
- 테크니컬 커뮤니티 빌더(네트워킹 디렉터)
일반적으로 ‘커뮤니티 매니저’라고 불리지만, 저는 특별히 ‘커뮤니티 빌더’로 정의해보았습니다. 여기엔 두 가지 목적이 있습니다. 앞서 언급했듯이 직함으로 인해 오해가 생기지 않게 하고, 이 포지션이 무엇을 하는 자리인지 명확하게 나타내기 위해서입니다. 이들의 직무는 프로덕트를 중심으로 기술 커뮤니티를 구축하는 것입니다.
(옵션)
- 개발자 경험 관리자
개발자 경험 관리자는 UX 및 사이트 설계부터 문서와 SDK에 이르기까지, 관련된 일을 담당하는 회사 내 모든 팀을 감독합니다. 필요할 때마다 그때 그때 이 역할을 맡아 수행할 사람을 찾을 수도 있습니다. 이 경우, 개발자 경험 관리자에게 개발자 경력이 꼭 필요한 것은 아니지만 개발 백그라운드가 없다면 적어도 테크니컬 라이팅 역량은 가지고 있어야 합니다.
- 테크니컬 앰배서더
‘에반젤리스트evangelist(전도사)’라고 부르지 않고 ‘앰배서더ambassador(홍보 대사)’라고 부릅니다. 에반젤리스트는 종교적인 의미를 담고 있어 많은 나라에서 부정적으로 여겨지기도 하고 신뢰를 쌓기는커녕 마음의 문을 여는 것조차도 어렵게 만들 수 있기 때문입니다. 에반젤리스트는 종종 영업 팀의 연장선에 있는 직업군으로 간주되고 있어 개발자 커뮤니티에서 활동하기가 점점 어려워지고 있습니다.
디벨로퍼 애드보케이트는 개발 커뮤니티와 쉽게 연결될 수 있는 사람들로, 여러분 회사의 프로덕트가 무엇이며 왜 만들어졌는지, 프로덕트의 편의성이 삶을 어떻게 변화시킬지에 대해 이야기합니다. 반면 테크니컬 앰베서더는 부사장이나 C레벨 등의 임원급을 대상으로 비즈니스를 오랫동안 지속하는데 여러분의 프로덕트가 얼마나 중요한 역할을 할지 설득합니다.
- 테크니컬 인게이지먼트 매니저
이 사람은 개발자 오디언스를 위한 콘텐츠를 검수하는 ‘눈’입니다. 모든 콘텐츠를 직접 ‘만들’ 책임은 없지만, 콘텐츠가 회사의 방향성과 목소리를 잘 반영하는지 체크하고, 너무 마케팅과 영업에 초점을 맞추지 않도록 하여 개발자 오디언스를 만족시키는 것이 이 사람의 책임입니다.
- 데브렐 프로젝트 매니저
프로젝트 매니저는 팀원들이 제각각의 방향으로 끌려가 남의 일을 대신 해주는 일이 생기지 않게 보호할 수 있습니다.
- 풀타임 엔지니어
다른 엔지니어나 개발자와 다른 점이 있다면, 오직 데브렐에만 전념한다는 것입니다. 어느 경우든, 팀에 풀타임 엔지니어가 있으면 일회성 버그나 쉽게 해결할 수 있는 지원 요청 등 커뮤니티 멤버들이 요청했지만 엔지니어링 팀이나 프로덕트 팀에 보내기엔 크게 급하지 않은 것들을 놓치지 않고 도울 수 있습니다.
조직에 대한 이야기인데 많은 기업에서 마케팅 조직 아래에 에반젤리스트 팀을 두는 경우가 많았습니다. 아마 에반젤리스트와 영업을 같은 선에서 보게 된 것도 그런 이유가 있었나 봅니다.
데브렐 팀에 이런 지표를 부여하는 순간 팀은 실패를 향해 가게 되며, 기존의 전통적인 마케팅 퍼널로 활동을 한정할 위험이 있습니다. 그러면 커뮤니티 니즈를 해결할 때 필요한 자발성과 창의성이 대폭 제한됩니다. 이는 커뮤니티와의 관계가 무너지는 결과로 이어지고, 팀의 가치를 증명하느라 지쳐 팀이 회사에 가져올 수 있었던 기본적인 가치마저 놓치게 될 것입니다.
