‘개발문화를 혼자서 바꿀 수 없다’며 포기하기엔 이릅니다

   이 이야기는 평사원인 개발자가 사내 개발문화를 만들기 위해 힘쓴 지난 6개월을 기록한 산문입니다. 반 년이 흐른 지금 소기 목표를 달성하였습니다. 이 방식을 유지해나간다면 느리더라도 점차 나은 모습으로 바뀌리라 확신합니다. 좋은 개발문화를 가진 기업들이 늘어나기를 바라며, 더 많은 개발자들이 만족할만한 개발문화 속에서 일하길 희망합니다. 자, 그럼 시작해봅시다!

기술블로그는 훌륭한 마케팅 수단입니다

   개발 커뮤니티 활동을 하면서 여러 개발자들을 만나 이야기하면 빠지지 않고 등장하는 단골 소재가 있습니다. 바로 개발 문화죠. 소위 개발자들의 워너비라 불리는 회사들은 연봉 뿐만 아니라 좋은 개발 문화를 갖고 있다며 어필합니다. 기술에 욕심 있는 개발자라면 그보다 혹할 조건이 또 있을까요?

   개발 문화에 대한 중요성은 날이 지날수록 증가하는 양상을 보입니다. 한 번쯤 이름 들어본 IT기업들이 기술블로그를 차립니다. 네이버 D2, NHN Meetup, 우아한형제들의 우아한Tech, LINE Enginreering, 카카오 Tech 뿐만 아니라 특이하게 개발 리더의 강연을 신호탄으로 쓰려던 11번가 TechTalk도 있습니다. 제가 다니는 사람인에이치알도 마찬가지고 무신사, 당근마켓, 컬리 등 많은 기업들이 기술블로그를 키우고자 합니다.

   기술블로그를 만드는 이유는 너무나도 명확합니다. 기술과 경험을 공유하는 그 밑바탕에는 개발자를 향한 마케팅이 담겨습니다. ‘우리 회사 좋아! 어때? 같이 일하고 싶지?’라는 마음을 갖게 만들기 위한 수단이죠. 기업이 별도로 DevRel까지 고용하면서 기술블로그를 유지한다는 건 장기적인 관점에서 그 이상 아웃풋이 발생한다는 의미일 겁니다. 개발자들은 업무를 하면서 기술블로그를 찾아보니 자연스레 그 회사에 대해 긍정적으로 받아드리죠. 개발자를 타켓으로 장기적인 관점에서 투자하는 마케팅 수단이 바로 기술블로그입니다.

시작하자 개발 큐레이션

   기술블로그는 대외비가 아닌 내용만 꺼냅니다. 마케팅 수단이기에 회사의 치부를 드러낼 수 없습니다. 따라서 기술블로그를 운용한다고 해도 사내 개발자 간 격차는 줄어들지 않을 겁니다. 기술블로그는 외부 개발자를 끌어드리기 위한 도구입니다. 물론 이를 통해 개발자 스스로도 브랜딩하지만, 이러한 행위가 동료들과 직접적인 연관을 갖기 힘듭니다.

   저는 동료 간 편차를 줄이고, 서로 거리낌 없이 개발에 대해 이야기할 수 있는 문화를 만들고 싶었습니다. 다만 한 명 한 명에게 개별적으로 다가가기엔 개발자도 많고 그들과 접점을 갖기도 힘듭니다. 시간도 많이 필요하죠. 단순히 100명이라고 계산해도 한 명 당 한 시간이면 무려 이주일이 넘게 필요합니다. '어떻게 하면 사내 개발자들을 위한 소통 창구를 만들지?'라는 고민에 빠져 살다가 기술블로그에서 쓰는 전략을 활용해보자는 아이디어가 떠올랐습니다. 누구를 향해? 사내 개발자를 향해!

   방법은 기술블로그와 별반 다르지 않습니다. 동료들을 향한 혼자만의 구애랄까요? 「개발 큐레이션」이라는 이름으로 포장하여 동료를 위해 펜을 들었습니다. 저에게 글은 그리 어려운 게 아니거든요. 사내 개발자를 대상으로 정기메일링 보낸지 벌써 반 년이 흘렀습니다.

사실 말로만 큐레이션이고, 절반은 동료를 위해 스스로 글로 옮긴 토픽입니다.

   CTO에게 「개발 큐레이션」을 제안하기 전까지 고민이 많았습니다. 과연 동료들이 호응해줄까? 괜히 밉보이지는 않을까?라는 막연한 두려움이 있었습니다. 그럼에도 불구하고 시작했던 건 글로 정리하는 행위가 저만의 공부 수단이기 때문입니다. 직접 손으로 정리하면서 되세기다보면 희미했던 지식이 어느새 뚜렷히 보입니다. 스스로 이해하지 못 하는 내용은 글로 옮겨지지 않거든요. 어차피 평소에도 쓰는 글이니 동료 개발자를 독자로 선정하여 적어보기로 했습니다. 미리 적어둔 10월 첫 번째 간행물을 포함하면 벌써 17개 작성했네요.

어설프게 다가가 겪은 시행착오

   「개발 큐레이션」을 시작할 때 구체적인 계획을 세우지 않아 시행착오를 겪었습니다. 의욕만 앞서고 준비한 건 없었죠. 개발 커뮤니티에서 제 사수였던 분이 꾸준히 써오던 건 보았지만, 그 분은 정기간행물에 대한 번역이라 소재가 명확합니다. 그렇다고 한 번 입 밖으로 꺼낸 이야기를 물릴 수 없죠. 혹여나 관심있는 분들은 저와 같은 시행착오를 겪지 않길 바랍니다.

   첫 번째는 연재 주기입니다. 회사에서 주업무는 어디까지나 빌링 서비스 개발이고, 「개발 큐레이션」은 혼자서 개인 시간을 할애하는 사이드 프로젝트입니다. 사내에서 제 역할은 어디까지나 벡엔드 개발자이기에 담당 도메인 프로젝트가 최우선 순위입니다.

   무릇 글이라는게 스스로 파악하고 머릿속에 정리하는 과정을 거쳐야 만들어잖아요? 처음에는 주간 연재도 가능하지 않을까 싶었지만 말도 안 되는 오만이었습니다. 주업무가 아닌 이상에야 터무니 없는 일이었어요. 꾸준함이 중요하다 판단하여 격주 발행으로 최종 결정하였습니다. 서비스 개발과 병행하기엔 리소스 제한이 너무나도 커요. 「오브젝트」처럼 많은 지면이 필요할 때만 일시적으로 주간 연재로 바꿔서 운영했습니다.

   두 번째는 주제 선정입니다. 단순히 기술 뉴스를 그 때 그 때 퍼나르는 건 크게 의미가 없습니다. 또 하나의 스팸으로 여길지 몰라요. 개발자 모두를 아우를 수 있는 주제도 한정적입니다. 또한 갑작스레 업무가 바빠 최신 동향을 살펴볼 겨를이 없다면 글로 옮길 소재가 마땅찮습니다. 해당 주간에 흥미로운 소재가 발견되지 않을 수도 있죠.

   정기 연재를 하려면 사전에 자료가 충분히 준비되어야 합니다. 처음에는 스스로 정한 마감 기한이 다가올 때마다 부랴부랴 준비했어요. 여분 자료를 따로 모아두지 않았거든요. 그러다보니 버거운 날도 있었습니다. 이대로는 제풀에 쓰러질 게 분명합니다. 그럴 수는 없죠! 평소 지하철로 오고 갈 때 틈틈이 자료를 모우고 미리 주제 별로 분류하기 시작했습니다. 지금은 소재 창고에 10회 분 넘게 여분이 쌓였죠. 든든하다 든든해! 사전에 미리 자료를 준비해두니 상황에 걸맞는 주제를 꺼내기 쉬워졌습니다. 예전부터 혼자 써오던 글들도 많은 도움이 되었습니다.

개발 큐레이션이 가져온 변화

   「개발 큐레이션」은 사내 개발자들이 공부하는 내용을 보태거나, 사내 교육으로 관심도가 올라간 영역을 소재로 삼습니다. 때로는 제가 참여했던 TF에 대한 AS를 다뤘습니다. 신입 개발자 공채 직후에는 그들에게 도움되는 내용을 담았죠. 그 덕분인지 잘 보고 있다며 직접적으로 응원해주시는 분들이 생겨났습니다. 덕분에 반 년동안 지속할 수 있었네요. 따로 인사드리지 못 했는데 이 글을 통해서 감사의 인사를 드립니다.

   물론 이보다 더 중요한 변화가 있습니다. 무엇일까요? 드디어 「개발 큐레이션」 컨텐츠를 생산할 사내 개발자가 생겼습니다! 아무리 좋은 취지라도 혼자서로는 문화로 가꿀 수 없잖아요? 함께 할 동료가 생겼다는 건 고무적인 일입니다.

「개발 큐레이션」 초기에는 서론으로 참여자를 모집했습니다.

   이러한 컨텐츠 기획은 혼자서 하려면 업무 중 많은 시간을 할애해야 합니다. 심지어 업무 외적인 개인 시간에도 틈틈이 뉴스를 파악하고 지금 현재 동료들의 관심을 끌 주제는 무엇인지 살펴봐야죠. 어디까지나 지금은 사이드 프로젝트에 지나지 않아 실무 비중이 훨씬 높은 만큼 혼자서 소모해야 하는 에너지가 큽니다. 하나의 글은 수십 번 퇴고를 거쳐야 완성됩니다.

   다행스럽게도 꾸준히 주위 개발자 분들께 넛지를 가하니 스스로 글을 쓰겠다는 분이 나타났습니다. 실제로 이미 글을 쓰셔서 교열을 마친 상태입니다. 「개발 큐레이션」 열여섯 번째 주제로 사내 개발자들에게 공유될 예정입니다. 하나에서 둘은 어렵습니다. 하지만 둘에서 셋은 훨씬 수월할 거에요. 개발자들이 스스로의 성과를 어필하는 장으로 만들 겁니다.

드디어 사내 개발자가 「개발 큐레이션」에 참여했습니다.

One for all, all for one, 글로 시작하는 개발 문화

   알렉산드르 뒤마의 소설, 『삼총사』하면 떠오르는 대사가 있습니다.

All for one, One for all!

   스위스의 비공식 모토이기도 한 이 문장의 순서를 뒤바꾸어 볼까요?

한 명의 개발자가 동료를 위해, 모든 개발자가 개발 문화를 위해.

   개발 문화는 분명 혼자서 바꿀 수 없습니다. 문화란 집단 속에서 피어나는 꽃이거든요. 하루아침에 피어나지도 않습니다. 그렇다고 움직이지 않는다면 당신은 그저 불평불만만 하는 여타 다른 개발자에 지나지 않습니다. 그러니 자신이 아닌 동료를 위해 접근합시다. 나 좋자고 타인에게 강요할 수 없습니다. 심지어 저는 직책자가 아니라 평사원입니다. 그러니 전략을 세워 다가갑시다.

   익숙한 행동경제학 이론을 하나 가져왔습니다. 넛지, 공개적인 장을 만들어 넛지를 가하면 의지 있는 사람들은 자신의 속도에 맞추어 변합니다. 처음에는 느릴지라도 하나 둘 제 속도를 찾아갑니다. 이와 함께 동료가 해결한 이슈를 찾아 경험담을 공유하고, 다른 개발자들에게 도움이 될 내용을 공부하는 분들께 적극적으로 권유합시다. 글을 쓰기 두려워 한다면 직접 작문을 알려주고 교열해준다는 말을 덧붙입니다. 단, 강요는 하지마세요. 어디까지나 동료를 위해 접근해야 합니다. 혼자서 형성할 수 없기에 문화라 부르는 겁니다.

맺음말

   개인은 독립된 주체이기에 스스로에게 이득이 되지 않는다면 움직이지 않습니다. 경직된 사람들을 움직이게 하는 건 합당한 보상입니다. 그리고 그에 대한 가장 큰 어드벤티지는 가장 앞에 서서 진두지휘한 당신이 가져가겠죠. 설사 회사에서 인정해주지 않아도 괜찮습니다. 이렇게 시작한 자료 하나하나가 모여 지식이 되고, 포트폴리오로 만들어집니다. 꾸준히 개발 문화를 바꿔보려고 했던 개발자가 몇이나 되겠나요? 특수성을 가졌으니 이를 원하는 기업을 상대로 좋은 무기가 될 겁니다. 지금 다니는 회사가 바뀌지 않더라도 개발문화를 가진 기업으로 갈 발판이 되어줍니다.

   아무런 행동을 취하지 않은 채 움직이지 않으면서 불평불만만 하면 아무 것도 바뀌지 않습니다. 스스로 움직이며 잔 다르크가 되어 보는 건 어떨까요? 저도 여러분과 다르지 않은 6년차 백엔드 개발자입니다. 궁금한 내용은 언제든지 devellany@gmail.com으로 메일 주세요.

   아래 첨부한 링크는 인사팀과 협업하여 사내 개발자 인터뷰어로 참여한 프로젝트입니다. 이곳이 아니더라도 언젠가 당신과 함께 마주하길 바라겠습니다.

라민이가 말한다 #1 : 개발자 in 사람인HR

사람인HR은 어떤 회사인가요? 사람인HR의 개발자로 근무하는 건 어떤가요?

www.saraminhr.team