로그인|회원가입|고객센터
Top
검색버튼 메뉴버튼

SR4. 기업의 개발 문화를 키우려면

개발 문화 육성의 첫발은 ‘기술 블로그’
업무와 일상 보여주며 내•외부 소통을

김철수 | 342호 (2022년 04월 Issue 1)
Article at a Glance

기술 블로그는 기업의 실적과 성과, 체계와 문화, 전략과 가치가 반영된 결과다. 특히 기업의 조직 문화와 개발 문화가 녹아 있다. 기업의 개발 문화가 명확하지 않다면 기술 블로그의 정체성이 모호해지거나 시간이 지나면서 게시물의 형식이나 내용이 제멋대로 바뀔 수 있다. 기술 블로그 도입을 계획 중인 기업이라면 지향하는 개발 문화부터 정의하고 이를 토대로 기술 블로그 운영 원칙을 정해야 한다.



옛날 중국의 한 황제가 유명 화가에게 고양이 그림을 주문했다. 화가는 차일피일 미루더니 7년이 지나도록 그림을 그리지 않았다. 황제는 화가를 불러 화를 냈다. 화가는 그제서야 황제 앞에서 이제껏 본 적 없는 아름다운 고양이를 순식간에 그려냈다. 그림이 마음에 든 황제가 그림값을 묻자 화가가 엄청난 금액을 불렀다. 단숨에 그린 그림이 어찌 그리 비싸냐고 황제가 물었다. 화가가 답했다. “폐하, 저는 지난 7년 동안 고양이만 그려왔습니다.”

개발자에게 블로그란 화가가 그린 고양이와 같다. 모르는 사람이 보기에는 그저 하나의 블로그에 불과하겠지만 기술 블로그는 개발자의 연구와 경험, 성공과 실패, 도전과 좌절의 역사가 점철된 결과물이다. 일상의 감상이나 소감을 기록한 여느 블로그와 다른 이유도 여기에 있다.

061


학술적인 네이버 vs. 자유로운 우아한형제들

기업의 기술 블로그는 해당 기업의 실적과 성과, 체계와 문화, 전략과 가치가 반영된 결과다. 언뜻 보면 기업 홈페이지나 SNS처럼 홍보나 PR 수단으로 인식될 때도 있지만 기술 블로그는 엄연히 기업의 조직문화와 개발 문화를 반영한다. 단적으로 비교할 수 있는 예가 네이버와 우아한형제들의 기술 블로그다.

DBR mini box I

기술 블로그란?

주로 정보기술(IT) 기업이 운영하는 블로그로 사내 개발자들의 실제 개발 사례와 노하우 등을 다룬다. 개발 지식과 노하우를 사내에 공유할 뿐만 아니라 자사가 가진 소프트웨어 기술, 역량, 비전을 외부에 알릴 수 있는 수단이 된다. 최근 개발 인력 유치 경쟁이 치열해지면서 외부 개발 인재들에게 자사 기술력을 홍보하는 수단이 되기도 한다. 네이버, 카카오 등 IT 대기업부터 직방, 야놀자 등 스타트업까지 다양한 업종과 규모의 기술 기반 기업들이 기술 블로그를 운영하고 있다.

네이버는 2011년 자사 개발자들의 지식과 실전 노하우를 담은 블로그 ‘네이버 D2’를 시작했다. 네이버 기술 블로그의 첫 게시글은 ‘Java Garbage Collection’1 이다. 가비지 컬렉션(GC, Garbage Collection)2 이론을 쉽게 소개한 글이다. 이 글의 분량은 그림을 빼고도 A4 용지 7장에 달한다. 글의 말미에는 참고 자료 3개를 덧붙였다. 문장은 담백하다. 불필요한 사례나 의견은 철저히 생략했다. 개인적인 의견은 최소화하고 철저히 과학 논문처럼 서술한다. 다음과 같은 식이다.

“GC를 이해하기 위해서 객체가 제일 먼저 생성되는 Young 영역부터 알아보자. Young 영역은 3개의 영역으로 나뉜다.”

“참고로 HotSpot VM에서는 보다 빠른 메모리 할당을 위해서 두 가지 기술을 사용한다. 하나는 bump-the-pointer라는 기술이며, 다른 하나는 TLABs(Thread-Local Allocation Buffers)라는 기술이다.”

지난해 11월에 올라온 글 ‘지식iN 앱을 Flutter (플러터)3 로 개발하는 이유’4 도 보자. 일반적인 블로그라면 자신이 경험한 속도, 성능, 개발 기간 등 몇 가지 예시를 간단히 들고 글을 마무리한다. 하지만 네이버는 왜 크로스 플랫폼으로 Flutter를 선정했고 지식iN 앱에 어떻게 활용하고 있는지 자세히 설명한다. 샘플 프로젝트를 구현하면서 비교 및 평가도 한다. 그림을 뺀 분량이 A4 용지 13장이다. 내용과 구성 모두 다음과 같이 전형적인 연구 논문 형식을 취했다.

062

“2019년 1월7일부터 1월14일까지 1주일 동안 React Native와 Xamarine, Flutter, SCADE의 4개 크로스 플랫폼에 대해 6명의 개발자가 성능과 생산성을 기준으로 검토를 진행했다.”

“평가 결과 Flutter가 가장 높은 점수를 받았다. 2차 테스트를 위해 기존 방법으로 12명이 개발하고, Flutter로 7명이 개발하였다.”

“지식iN ONE APP 출시 후 2년 동안 서비스를 운영한 결과 Flutter를 실서비스에 적용할 수 있다는 것을 확인했다.”

네이버 기술 블로그는 연구 개발의 특허 또는 특허의 초기 아이디어를 소개하는 창구에 가깝다. 기술적으로 당면한 문제를 해결하는 솔루션이면서 미래 기술을 전망하는 예언서인 것이다. 또 외부 개발자들에게 자사의 지식과 기술력을 홍보하는 ‘공개 구애’이기도 하다. “우리가 이 정도로 지식이 깊으니 함께 개발하자”고 제안하는 것이다. 이처럼 학술적인 기술 블로그는 개발 지식과 노하우를 체계적으로 담고 공유해 개발자가 더 깊은 지식을 탐구하게 한다. 또 개발 지식에 대한 관심이 깊고 능력도 뛰어난 개발자가 합류하도록 유도한다.

반면 우아한형제들은 기술이나 코드뿐만 아니라 개발자들의 일상과 주관적인 감상도 기술 블로그에서 다룬다. 2016년 우아한형제들 기술 블로그 개설 초기에 올라온 게시글 ‘Google Apps Script 사용 이야기(1/3)’5 를 보자. 이 글은 3건으로 나눠서 올렸다. 글 1건당 분량은 A4 2장이 채 되지 않는다. 원고지로 고작 7장이다. 원고지 37장 분량의 네이버 블로그 첫 게시글과 비교했을 때 확연히 적은 분량이다.

063


“업무를 좀 더 편하고 매끄럽게 도와주기 위하여 Google Apps를 도입한 만큼, 사람들이 불편을 느끼지 않도록 잘 운영하고 싶었다.”

“문제는.. 2∼3명의 이메일 등록이나 수정, 삭제 요청이 들어오면 5분이면 처리할 수 있었다. 하지만 20∼30명 정도의 요청이 들어오면 한 명 한 명 작업하는 게 너무 번거롭고, 실수가 없었는지 확인하기도 힘들었다.”

“그래서 찾아보았다. 이 작업을 어떻게 편하게 할 수 있을까 고민하다 발견한 것이 Google Apps Script이다. (중략) Apps Script로 기능을 만들어보기로 하였다.”

“오오! 구글 오오! 너무 간단하게 처리가 되었다. (중략) 그리고 인텔리센스 목록 중, 굉장한 문자열을 보고 본격적으로 사용 실험을 시작하게 되었다….”

몇 문장만 읽어도 우아한형제들의 기술 블로그는 논문 형식이 아니라는 점을 분명히 깨닫는다. 이 글의 마지막 문장은 “[헐… 설마… 내가 생각하는 그것이 가능한가??]”다. 완결성과는 담을 쌓았다. 대괄호 안에 자기 감상을 적나라하게 표현했다.

개발자, 프로덕트 오너(PO) 등 개발 관련 인력 규모만 600여 명이 넘는 유수 개발 조직으로 성장한 지금도 우아한형제들은 기술 블로그에서 개발자의 업무와 일상을 자연스럽게 다루고 있다. 2021년 12월10일에 올라온 게시글 ‘웹툰도 같이 봐요: 만화경 구름톡’을 보자. 웹툰을 보다가 원하는 장면에 바로 댓글을 남길 수 있는 기능인 ‘구름톡’을 만들게 된 계기와 과정을 공유하며 “사실 열심히 만들었으니까 알아 달라고 글 쓰는 거... 맞아요...”라고 말한다. 여전히 학술적인 느낌이 아니다. 우아한형제들의 기술 블로그 검토 기준이 논문 심사 기준인 적합성, 완결성, 정확성이 아님은 분명히 알 수 있다. 그렇다면 우아한형제들은 왜 네이버처럼 기술 블로그를 쓰지 않을까?

그 이유는 2016년 6월에 올라온 게시글 ‘스타워즈 깨어난 포스 리뷰’6 를 보면 알 수 있다. 글의 첫 문장은 이렇게 시작한다. “우아한형제들의 CTO실 사람들이 새로운 기술이나 개발 코드만 얘기하지는 않습니다. 여행담이나 새로 산 전자 기기에 대한 얘기, 영화에 대한 감상도 많이 나눕니다.” 우아한형제들은 기술 블로그를 전문 기술 내용만 다루는 것이 아닌 개발자의 일상도 자유롭게 다루는 ‘개발자 블로그’로 정의한 것이다.

같은 시기에 올라온 게시글 ‘우아한형제들의 Baby Steps’7 에서는 기술 블로그를 ‘우아한형제들 기술 조직의 성장 일기’로 정의했다. 블로그에 적힌 그대로 옮기자면 “이 블로그에는 기술적으로 대단하고 멋진 글이 올라오는 것이 아니라 우아한형제들이 Java로 전환하는 과정에서 새롭게 배우는 것들, AWS로 이전하고 운영하면서 알게 된 것들, 개발자로서 관심을 가지고 살펴보다가 정리가 필요해서 정리한 것들”을 담는다고 설명한다. 당시 우아한형제들의 기술력이 지금처럼 높은 수준은 아니었기 때문에 기술 블로그는 성장하는 과정에서 배운 점을 기록하는 일지였던 셈이다.

기술 블로그로 만드는 개발 문화

네이버에서는 수억 사용자 수준의 대용량 트래픽과 사용자 인터랙션을 경험할 수 있다. 그 경험을 바탕으로 ‘코디네이터가 아닌 깊이가 다른 진짜 개발자로 성장’8 하도록 돕는 것을 개발 문화로 정의하고 있다. 따라서 네이버는 기술 블로그를 과학 블로그로 정의하고 컴퓨터공학을 깊은 수준으로 연구하는 개발 문화를 만들어나가고 있다.

반면 우아한형제들은 개발자가 개발을 잘하는 것보다 더 중요한 것이 있다고 말한다. 김범준 우아한형제들 대표는 “서로 가진 지식을 잘 나누는 것”9 이 개발자의 역량을 가른다고 말한다. 좋은 개발 문화란 자기 지식을 잘 나누는 문화라고 정의한 것이다. 이를 구현하기 위해 김범준 대표는 CTO 시절 우아한형제들 기술 블로그를 개발자의 일상 블로그로 만들었다고 해석할 수 있다.

이처럼 개발 문화가 기술 블로그 성격에 영향을 준다면 기업은 개발 문화부터 정의할 필요가 있다. 이를 바탕으로 기술 블로그 운영 원칙을 정해야 한다. 만약 기업의 개발 문화가 명확하지 않다면 기술 블로그의 정체성이 모호해지거나 시간이 지나면서 게시물의 형식이나 내용이 제멋대로 바뀔 수 있다. 반대로 기술 블로그의 형식과 내용이 유지되거나 발전한다면 이는 곧 그 기업의 개발 문화가 유지되거나 발전한다고 볼 수 있다.

물론 개발 문화는 단순히 정의 내린다고 실현되는 것이 아니다. 다른 개발자가 만든 코드를 검토하는 코드 리뷰, 두 개발자가 같이 코드를 짜는 페어 프로그래밍(Pair programming), 개인보다는 팀이 프로그램을 완성해나가는 스크럼(Scrum), 모든 개발 과정을 기록하고 공유하는 위키 사용 등의 활동이 지향하는 조직 문화에 맞게 잘 진행돼야 개발 문화가 만들어진다.

1. 페어 블로깅(Pair blogging)

한 기업이 개발 문화를 ‘협업 문화’로 정의했다고 가정해보자. 책임자는 협업 문화를 조성하기 위한 프로그램을 만들 것이다. 이때 도움이 되는 프로그램 중 하나가 바로 페어 프로그래밍이다. 개발자 두 명이 짝을 지어 같이 프로그래밍하는 방식이다. 페어 프로그래밍을 하면 코드의 오류가 줄고 코드 자체가 간결하고 분명해진다. 게다가 개발자끼리 지식을 공유하고 새로운 방식을 배우며 문제를 해결할 수 있다. 개발자가 함께 프로그래밍하듯 기술 블로그도 두 명이 짝을 지어 같이 글을 쓰는 페어 블로깅, 즉 짝 글쓰기를 하면 협업 문화를 만드는 데 도움이 된다.

페어 블로깅할 때 반드시 한 주제를 같이 쓸 필요는 없다. 예를 들어 서버와 클라이언트가 통신하는 HTTP 메소드 중에 GET 방식과 POST 방식이 있다. 두 방식의 장단점을 설명하는 블로그 게시물을 두 개발자가 쓴다고 가정해보자. 한 명은 GET 방식의 장점을, 다른 한 명은 POST 방식의 장점을 쓰면 된다. 두 개발자가 같은 결론을 낼 필요는 없다. 글 쓰는 방식을 하나로 고정할 필요도 없다.

065


페어 프로그래밍에는 여러 방식이 있다. ‘Driver & Navigator’ ‘Coder & Adviser’ ‘Verbalizer & Listener’ ‘Ping-Pong’ 등 다양한 방식을 페어 블로깅에 응용해보자.10

Driver & Navigator는 한 명은 글을 쓰고(Driver) 다른 한 명은 검토(Navigator)하는 방식이다. 쉽게 바꿔 말하면 Writer & Reader 방식이다. 짝 프로그래밍은 개발자 두 명이 하지만 짝 글쓰기는 두 명 모두 반드시 개발자일 필요는 없다. 개발자와 기획자, 개발자와 마케터가 같이해도 된다.

Coder & Adviser는 한 명은 글을 쓰고(Coder) 다른 한 명은 조언(Adviser)하는 방식이다. 조언자 역할은 글쓰기 수준이 비교적 높은 사람이 맡는 것이 좋다. 테크니컬 라이터11 나 개발자 글쓰기 전문 강사의 첨삭 지도를 받으면서 글을 써 보는 것도 개발자에게 좋은 경험이다.

Verbalizer & Listener는 글을 쓰고 난 뒤 한 명은 글을 읽고(Verbalizer) 다른 한 명은 귀로 듣는(Listener) 방식이다. 글을 소리 내어 읽어보면 부자연스러운 문장에서 말이 막힌다. 글을 귀로 들을 때도 어색한 문장이나 표현이 거슬리게 마련이다. 기술 블로그에 글을 쓴 뒤 소리 내어 읽고 들어보면 매끄러운 글을 쓰는 데 도움이 된다.

Ping-Pong은 두 명이 번갈아 가면서 글을 쓰는 방식이다. 목차 단위로 나눠서 쓰거나 한 명은 예제 코드를 쓰고 다른 한 명은 예제 코드를 설명하는 식으로 쓸 수도 있다. 한 사람이 글을 쓰다 막힐 때 다른 사람이 이어 쓰는 것도 좋은 방법 중 하나다.

페어 블로깅의 장점은 우선 글의 완성도가 높아진다는 점이다. 두 명이 글 하나를 같이 쓰면 서로가 독자 역할을 맡게 된다. 독자 관점에서 질문하고 답하는 과정을 통해 자연스레 글의 완성도가 높아진다. 심리적 안정감도 준다. 글을 혼자 쓸 때는 글의 수준이나 내용이 적절한지 혼자 판단해야 하므로 중압감이 크다. 둘이 함께 글을 쓰면 이런 부담을 덜어낼 수 있다.

페어 블로깅을 통해 팀 회고도 할 수 있다. 개발 과정이나 결과를 글로 쓰면서 회고하는 것이다. 혼자 쓰면 개인적인 회고이지만 둘이 같이 쓰면 자연스럽게 팀 회고가 된다.

마지막으로 지식을 보편화하는 데 도움이 된다. 혼자 글을 쓰면 자기만의 지식 체계가 만들어진다. 둘이 함께 글을 쓰면 두 사람의 공통된 지식 체계를 만들 수 있다. 이 지식 체계는 혼자 만든 것보다 더 보편적이므로 사내 다른 개발자에게 쉽게 전파할 수 있다.

2. 코드 워크숍

개발자 개개인의 기술 수준보다 모두의 성장을 우선하는 개발 문화를 지향한다면 코드 워크숍을 활용할 수 있다. 코드 워크숍이란 매주 개발 팀이 모여 한 명씩 돌아가며 최근 연구한 사례나 습득한 지식, 우연히 발견한 노하우, 코딩 중 느낀 점, 새로운 코딩 아이디어 등을 공유하는 시간이다. 예를 들어 우아한형제들의 B마트 서비스팀은 금요일마다 ‘자유 주제 워크숍’을 연다. 주제가 정해져 있지 않아 효율적으로 개발하는 테크닉과 아키텍처 등 다양한 주제로 발표한다. 워크숍 내용은 모두 내부 시스템에 기록하고 가끔 기술 블로그에도 공개한다.

067


이처럼 코드 워크숍의 산출물을 정리하고 기술 블로그에 업데이트하는 방법도 있다. 일반적으로 코드 워크숍 발표 내용은 파워포인트(PPT) 1∼2장으로 간단히 정리한다. 이 자료에 다른 개발자들의 의견을 추가하고 토론 내용을 간단히 정리해 덧붙이면 사실상 기술 블로그의 게시글이 된다.

기술 블로그라고 해서 작정하고 글을 써야 한다는 편견은 버리는 것이 좋다. 글의 종류에는 저(著), 술(述), 편(編), 집(輯) 이렇게 4가지가 있다. 기술 블로그 관점에서 ‘저’는 직접 경험하고 실험한 과정이나 결과를 적은 것이다. 개발기, 도입기, 적용기 등이 여기에 해당한다. ‘술’은 어떤 대상을 분석해 의미를 풀이하고 해석한 것이다. 기술 소개나 용어 분석, 장애 해결 방법 등이 대표적이다. ‘편’은 산만하고 복잡한 자료를 편집해 질서를 부여한 것이다. 프로그램 설치 방법이나 튜토리얼(사용 지침), 세미나 후기, 개발 도서 리뷰 등이 있다. ‘집’은 여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것이다. 명령어 모음이나 기술 혹은 기능의 차이점을 설명하는 글이 대표적이다.12

코드 워크숍의 발표 내용 대부분은 저, 술, 편, 집이 섞여 있다. 기술 블로그를 막 시작한 단계라면 ‘편’이나 ‘집’에 해당하는 글을 쓰는 것이 좋다. 만약 시니어와 주니어가 페어 블로깅을 한다면 ‘저’나 ‘술’을 바로 시작해도 나쁘지 않다. 프로그래밍할 때 적절한 도구부터 먼저 찾는 것처럼 페어 블로깅을 시작할 때도 적절한 글의 종류를 정해 가이드라인을 제시해줄 필요가 있다. 특히 초기에 발행되는 글은 이후 개발자들이 글을 쓸 때 참고하는 기준이 될 가능성이 높기 때문에 개발 문화부터 먼저 정의한 뒤 글에 대한 가이드라인을 제시해야 한다.

3. 보상

기술 블로그를 실제로 운영할 때 가장 중요한 것은 의외로 다른 영역에 있다. 바로 보상이다. 기술 블로그에 글을 올리는 개발자뿐 아니라 모든 블로거에게 보상은 조회 수와 추천 수, 댓글이다. 기술 블로그를 오픈했지만 홍보가 미흡해 글을 읽는 독자가 몇 명 없다면 그런 블로그에 글을 게재하고 싶은 개발자는 없을 것이다. 기술 블로그를 운영할 때는 최대한 많은 사람이 조회하고, 추천하고, 댓글을 쓰게 만들어야 한다.

이를 위해 사내 개발자부터 서로의 글을 읽도록 권장해야 한다. 앞서 코드 워크숍의 결과물이 블로그 게시글이 될 수 있다고 했다. 반대 경우도 충분히 가능하다. 코드 워크숍에서 발표할 내용을 먼저 블로그에 게재해 그 내용을 다른 사람이 읽고 추천하며 댓글을 달도록 유도하는 것이다. 이렇게 하면 기술 블로그가 코드 워크숍의 플랫폼으로 기능할 수 있다.

068


또한 보상에는 돈이 빠질 수 없다. 하지만 기술 블로그에 글을 올린 개발자에게 고료를 주는 경우는 거의 없다. 사내에서 정성 평가 또는 핵심성과지표(KPI) 중 하나로 관리하는 수준이다. 이는 개발 문화 조성이라는 명목으로 개발자의 지식과 경험, 노하우를 사실상 착취하는 것과 다름없다고 본다. 외부에 오픈하는 기술 블로그는 기업 영업 활동의 연장선이므로 게시물에 대한 대가를 지불하는 것이 마땅하다. 실제로 대기업의 사보는 사•내외 기고자에게 원고료를 지급한다. 원고료라는 보상 없이 기술 블로그에 좋은 글이 올라오리라는 기대는 환상이다. 좋은 콘텐츠에는 그에 준하는 보상을 줘야 한다. 사내 개발자라고 해서 무상으로 콘텐츠를 착취해서는 안 된다.

원고료라는 보상이 있다면 사외 개발자로 필진을 확장할 수도 있다. 협력 업체나 외부 커뮤니티, 학회 소속 전문가나 교수에게 기술 블로그 작성을 정기적으로 의뢰할 수 있는 것이다. 그렇게 한다면 기술 블로그는 업계의 매체 플랫폼으로, 나아가 유능한 인사가 모이는 기술 플랫폼으로 발전할 수 있다.

개발자의 글쓰기

‘개발자가 글을 잘 쓸까?’ 기술 블로그 책임자의 최대 고민은 이것이다. 개발자는 글쓰기를 업으로 하는 사람이 아니다. 글을 잘 못 쓰는 게 당연하다. 기술 블로그 기고를 요청하기 전에 개발자에게 글쓰기부터 가르쳐야 하는 이유다. 기술 블로그 책임자는 개발자가 글을 잘 쓰게끔 도와주고 지원해야 한다. ‘기술 블로그만 개설하면 개발자들이 알아서 글을 쓰겠지’라는 생각은 착각이다. 마치 회사의 비전이나 핵심 가치 등을 만들어 놓으면 조직 문화가 자연스레 생길 것이라는 착각과 같다. 개발 언어를 처음 배우는 사람에게 ‘Hello World’를 출력하는 방법부터 알려주듯 기술 블로그 작성을 시작하려는 개발자에게 글쓰기 기초부터 알려줄 필요가 있다. 글쓰기를 배우고 실습하면서 분량이 적은 글부터 쓰기 시작하고 또 과제로 계속 쓰다 보면 자연스레 글쓰기 실력이 늘 수 있다.

예산이 충분하다면 기술 블로그 전문 작가의 도움을 받아 검토하고 퇴고하는 것도 좋다. 하지만 이런 테크니컬 라이터는 양날의 검이다. 기술 블로그 글의 수준을 높인다는 장점이 있지만 지나치게 높은 기준이 오히려 역효과를 불러오기도 한다. 검토 과정에서 테크니컬 라이터에게 내용을 제대로 설명하지 못하거나 의도한 대로 글을 쓰지 못한 개발자는 좌절감을 느낄 수 있다.

결국 개발자의 글쓰기에 대한 기대 수준을 낮추는 것이 좋다. 현재 글쓰기 실력을 인정하고 개발 실력과 더불어 글쓰기 실력도 키워나가는 쪽으로 방향을 잡아야 한다. 필자가 네이버, 카카오, 삼성전자, 현대자동차 등에서 글쓰기 강의를 진행하며 만난 개발자들은 공통적인 고민을 갖고 있었다. 신입 개발자부터 개발 팀장까지 연차는 달랐지만 하나같이 “글을 잘 쓰고 싶다”고 했다. 이것이 문제의 핵심이다. 글을 잘 쓰고 싶으니 잘 못 쓰는 것이다. 개발자가 소설 작가처럼 쓸 수는 없다. 기대 수준이 높을수록 글쓰기를 포기할 확률이 높아진다. 수준 높은 기술 블로그를 처음부터 목표하기보다 우아한형제들의 기술 블로그처럼 가벼운 소재를 다룬 개발자들의 일상 블로그로 시작하는 것도 좋은 방법이다.

069


네이버, 카카오 등 이미 높은 기술 수준을 가진 기업이라면 기술 블로그를 투 트랙으로 가져가는 방식도 추천할 만하다. 현재 운영 중인 기술 블로그는 더욱 전문적인 성격으로 포지셔닝하고 새로운 기술 블로그는 개발자의 일상 블로그처럼 가볍고 친근하게 운영하는 것이다. 기술 블로그가 기업의 홈페이지처럼 단 하나일 필요는 없다.

글쓰기가 아닌 다른 방식도 가능하다. 요즘에는 개발 지식을 유튜브 동영상으로 익히는 사람이 많다. 글이 아닌 영상으로 개발 지식이나 경험, 노하우 등을 기록하는 방식도 좋다. 개발자가 화면을 녹화하면서 개발 과정이나 경험을 설명하는 것이다. 이 밖에 웹툰 작가와 협업해 만화로 개발기를 만드는 방법도 있다.

고양이 그림을 주문한 황제는 순식간에 아름다운 고양이를 그려낸 화가를 보며 다른 화가도 그럴 것이라 짐작할지 모른다. 하지만 현실에서 그 정도 실력을 갖춘 화가는 찾기 드물다. 개발자의 글쓰기도, 개발 문화도 마찬가지다. 처음부터 큰 기대를 하기보다 차근차근 성장하고 발전해야 한다. 조직의 개발 문화부터 정의하고 기술 블로그 운영 방식과 원칙을 정한 뒤 개발자에게 글쓰기를 교육하자. 그러다 보면 기술 블로그와 개발 문화가 서로 영향을 주고받으며 만든 선순환 체계가 조직 내에 자리 잡을 것이다.


김철수 디지털역량연구소 소장 vitaminq42@gmail.com
필자는 대학에서 국문학을 전공하고 실무에서 개발 업무를 했다. 프리챌에서 아바타, 스킨 제작을 담당하고 코오롱베니트에서 배출권 거래 시스템 구축과 기후변화 컨설팅을 했다. 지금은 디지털역량연구소를 운영하며 개발자에게 글쓰기와 비즈니스 전략을, 비개발자에게 디지털 트랜스포메이션과 데이터 리터러시, 기획력 등을 주제로 강의한다. 저서로는 『개발자의 글쓰기』 『팀장을 위한 보고서 검토 기술』 『감으로만 일하던 김 팀장은 어떻게 데이터 좀 아는 팀장이 되었나』 『RPA로 만드는 나만의 디지털 로봇 비서』 등이 있다. 자세한 소개는 개인 홈페이지(http://www.HowDigitalHRD.com)에서 확인할 수 있다.


DBR mini box II

개발자를 대상으로 하는 마케팅… SW 기업의 미래 달려

데브렐(DevRel, Developer Relations)이란 개발자를 대상으로 회사의 기술 혹은 개발 문화를 알리고 나아가 개발자를 더 잘 채용할 수 있는 기반을 다지는 역할이다. 사내•외 개발자와의 접점을 늘리는 기술 블로그, 콘퍼런스, 소규모 세미나 및 워크숍 등은 모두 데브렐 활동의 일환이다. 쉽게 말해 데브렐은 PR(Public Relations)의 ‘Public(대중)’을 ‘Developer(개발자)’로 바꾼 개념이다. 개발자를 대상으로 한 PR 활동인 셈이다. 구글, 아마존 등 글로벌 기업뿐만 아니라 국내에서도 라인, 우아한형제들 등 데브렐의 중요성을 인식하고 관련 조직을 운영하는 기업들이 늘어나고 있다.

데브렐 조직이 필요한 이유는 크게 두 가지다. 첫째, 자사 소프트웨어 제품을 판매하거나 홍보하기 위해서는 잠재 고객인 개발자들과 적극적으로 소통해야 한다. 다양한 업종에서 제품과 서비스 개발을 할 때, 소프트웨어에 의존하는 기업이 늘고 있다. 다른 회사가 만든 소프트웨어를 여러 계약 형태로 사용하는 경우도 많다. 개발자들이 소프트웨어를 공급하는 회사들의 핵심 고객인 셈이다. 이런 이유로 소프트웨어를 공급하는 회사들은 잠재 고객인 개발자들과의 접점이 필요하다. 따라서 그 접점을 찾아 활동하는 팀 또는 담당자인 데브렐이 필요한 것이다.

둘째, 더 좋은 제품과 서비스를 만들기 위해 개발 인재 확보와 유지가 중요해졌다. 기업의 디지털 역량이 중요해지면서 소프트웨어 개발자가 기업 운영에 가장 귀한 자원이 된 것이 현실이다. 최근 IT 업계의 잇따른 개발자 연봉 인상만 봐도 알 수 있다. 좋은 소프트웨어 개발자 확보와 유지가 기업의 우선순위가 되면서 큰 개발자 커뮤니티와 지속적으로 소통하는 데브렐 역할이 중요해지고 있다.


주요 업무

데브렐이 하는 일을 요약하면 빠르게 변하는 기술과 사회 환경 속에서 ‘어떻게 개발자들이 자사 제품을 알고 채택하며 효과적으로 이용하게 할 것인가? 이를 위해 어떤 프로그램을 계획하고 운영할 것인가?’에 대한 답을 찾고 실행하는 일이다. 대표적인 역할은 다음과 같다.


1. 개발자 대상의 세미나 및 교류 행사 기획과 운영

데브렐이 하는 가장 중요한 역할이다. 자사 소프트웨어 기술을 소개하거나 다른 기술과의 연동 사례 등을 발표하는 행사를 진행해 외부 개발자와의 접점을 늘리는 역할이다. 대규모 기술 콘퍼런스, 소규모 세미나 혹은 워크숍, 밋업(meet-up) 등을 기획하고 진행한다.

2. 기술과 서비스에 대한 대외 커뮤니케이션

자사가 가진 소프트웨어 기술, 역량, 비전을 외부에 알리고 활용 예시를 보여줌으로써 제품 채택률을 높이는 일이다. 가장 많이 하는 방법은 기술 블로그에 기술 문서를 작성해 대외적으로 배포•홍보하는 것이다. 직접 기술 문서를 작성하거나 기술에 대한 이해를 바탕으로 적절한 내•외부 개발자를 섭외해 글의 방향을 제시해준다. 기술에 대한 이해와 지식이 필요한 일이기 때문에 데브렐 채용 요건에 대체로 개발 경력이 요구된다.

3. 커뮤니티 전략 기획 및 운영

자사 기술을 사용하거나 관련 기술을 개발하는 사람들로 커뮤니티를 조성 및 유지하고 확대하는 일이다. 커뮤니티를 통해 자사 기술을 알리고 실제 사용자들의 피드백을 내부에 전달해 제품 개선을 돕는다. 또한 커뮤니티 내의 정보 교환을 촉진해 자사 제품 또는 서비스에 대한 접근성을 개선하고 구성원 간의 교류를 통한 다양한 성장 경험을 제공한다. 역량 있는 사내 개발자를 커뮤니티에 노출해 자사 기술에 대한 신뢰도를 높이기도 한다. 직접 조성한 커뮤니티뿐만 아니라 자사 제품 및 기술과 관련이 있거나 외부 개발자들이 많이 모여 있는 다른 커뮤니티에 참여하는 것도 데브렐 커뮤니티 전략 중 하나다.

4. 개발자 생태계에 개발 문화를 알리는 마케팅

자사 소프트웨어 개발 문화를 기술 블로그 등을 통해 알려 자사 개발자들이 외부에 멋지게 보이도록 마케팅하는 일이다. 자사 개발 문화가 어떻게 제품과 서비스에 기여하고 개발자의 성장에 도움이 되는지 소개하는 것이다. 이런 마케팅 활동으로 자사 제품에 대한 신뢰를 높이는 동시에 외부 개발 인재에 대한 홍보 효과도 얻을 수 있다.

데브렐에 필요한 역량

데브렐은 3C(Code, Contents, Community)를 통해 자사 제품과 그 제품을 사용하는 개발자를 연결하는 일이다. 데브렐에 필요한 역량은 무엇일까? ‘2020 State of Developer Relations Report’i 에 따르면 데브렐 종사자들은 자신이 가진 역량으로 공감(40%), 소통(33%), 창의성(9%)을 꼽았다. 데브렐에 필요한 대표적인 역량을 정리하면 다음과 같다.

1. 듣기 역량

기술적 또는 비기술적인 문제에 대한 해결 방안을 제시하기 전에 상대를 주의 깊게 관찰해 고객 개발자가 자신의 요구 또는 의도를 잘 표현할 수 있도록 도와야 한다. 경청에는 인내와 관찰력, 맥락 이해력, 공감력이 요구된다. 열심히 듣기만 해서도 안 된다. 개발자의 요구를 명확하게 이해하고 올바른 질문을 던져 고객이 제대로 이해하지 못한 부분을 끌어내 명쾌히 설명해야 한다.

2. 기술 역량

데브렐은 세부 역할에 따라 필요한 기술 역량 수준이 다르다. 기술 이슈에 대해 개발자들과 코드 기반의 논의가 필요한 경우라면 현업 개발자 수준의 개발 역량이 필요하다. 문제 해결 역량과 빠른 학습 능력도 중요하다. 이 밖에 다양한 소프트웨어 기술에 대한 이해도와 새로운 기술에 대한 호기심이 있어야 한다.

3. 조직/기획 역량

데브렐 조직의 업무를 구조화하는 역량이다. 데브렐 조직의 상위 관리자는 명확하지 않다. 데브렐을 대상으로 조사한 ‘2020 State of Developer Relations Report’에 따르면 데브렐팀의 상위 보고 채널이 마케팅 조직이라고 응답한 비율이 가장 많았고 그다음은 CTO, 엔지니어링 조직 순이었다. 사내 데브렐 조직의 위치가 모호한 만큼 업무와 목표를 명확히 정리해 다른 팀과의 관계를 정립해야 한다. 또한 다른 팀과 경쟁하기보다 공동의 목표를 설정하고 협력을 끌어내는 역량이 필요하다.

개발자 커뮤니티 관련 업무를 맡은 데브렐 팀은 커뮤니티가 지향할 목표를 설정하고 커뮤니티 내의 리더십과 권한 분배 등의 거버넌스 구조를 만들어야 한다. 이어 구성원들이 성장하며 커뮤니티에 지속적으로 참여하도록 서로 동기부여하는 문화를 조성해야 한다.

4. 데이터 기반 분석 역량

데브렐이 해야 할 역할 중 하나는 회사가 데브렐 활동을 지속적으로 지원하도록 설득하는 일이다. 미국 등 데브렐 조직이 일반화된 나라에서도 그렇다. 데브렐 활동은 매출로 직결되는 영업이나 제품 개발 업무가 아니기에 정량적인 측정이 어렵기 때문이다. 데이터 기반 분석 역량이 있다면 데브렐 활동의 성과를 정량적으로 측정하고 전략과 목표를 효과적으로 조정할 수 있다. 데브렐 조직의 존재 가치를 증명하는 데 필수적인 역량인 셈이다.

071


데브렐의 미래

비교적 신생 직군인 데브렐의 역할은 앞으로 어떻게 바뀔까? 기술, 경영 전문 작가 케빈 케이시(Kiven Casey)에 따르면 데브렐 조직은 직간접적인 마케팅 활동을 줄이고 제품에 대한 개발자들의 요구에 잘 대응할 수 있도록 대내외적인 협력 중심의 활동으로 발전할 전망이다. 또한 현재 대부분 회사에서 데브렐 조직은 제너럴리스트 위주로 구성된 비교적 작은 규모의 팀이지만 앞으로는 기술 커뮤니티가 세분화되는 트렌드에 맞춰 보다 전문적인 역할과 조직으로 발전할 것이다. 성과 측정 방식 역시 많은 조직에서 데브렐 활동이 일반화되면서 양적 수치보다는 질적 성과를 추구하는 방식으로 변화할 전망이다.


이민석 이노베이션 아카데미 학장 ykhl1itj@gmail.com
필자는 우리나라에 PC가 처음 도입된 1980년대부터 소프트웨어, 하드웨어 개발자로 일했다. 1995년 컴퓨터공학 박사 학위를 취득하고 1990년대 후반 리눅스로 스마트폰을 만드는 회사를 선후배들과 함께 운영했다. 이후 한성대, NHN NEXT, 국민대에서 소프트웨어 인력을 양성했다. 지금은 이노베이션 아카데미에서 인재 양성과 개발자 생태계 활성화를 위해 힘쓰고 있다.
인기기사