시니어가 되기 위한 준비, 「개발 큐레이션」과 함께한 2021
Miscellany주니어와 시니어, 애매한 경계선 어딘가
개발자를 표현하는 단어가 참 많습니다. 그 중에서도 코더와 프로그래머, 잡부와 풀스택, 주니어와 시니어처럼 급을 나누는 용어도 존재합니다. 여러분은 자신을 소개할 때 어떤 수식어를 쓰시나요? 2021년 12월을 기준으로 7년차에 접어든 저는 시니어라 불리기를 꿈꾸는 개발자입니다.
시니어, 그 기준은 무엇일까요? 단순히 연차가 쌓인다고 시니어가 되는 건 아닐 겁니다. 연차와 기술역량은 정비례하지 않거든요. 주어진 과업을 동일한 방식으로 해결해온 사람이라면 5년, 10년이 흐르더라도 제자리 걸음입니다. 시간이 해결해주는 문제가 아니죠. 개발 역량은 더 나은 방안을 모색하기 위한 고민 속에서 피어납니다. 사용자와 동료를 위한 고민을 그만 두는 순간 실력은 그대로 정체되거나 퇴보합니다.
그렇다고 실력이 전부일까요? 설사 빼어난 실력을 갖추었어도 주변 개발자들에게 부정적인 영향을 끼친다면 시니어 개발자라 부를 수 없습니다. 한 사람으로 인하여 조직이 와해되기도 하니 그런 사람을 시니어라 부를 수 없습니다. 작은 프로젝트가 아니라면 혼자서 개발하지 않거든요. 혼자는 한계가 분명합니다. 프로에게 협업은 당연하기에 함께 걸을 줄 알아야죠. 독단적인 개발자에게 처음에는 혹할지 모르지만, 결국 맞이하는 건 배드엔딩입니다.
동의하시나요? 아닌 분도 계실 겁니다. 이는 개인, 한 사람의 기준일 뿐입니다. 저마다 시니어에 대한 요건은 다릅니다. 그러니 조금 더 구체적인 단어로 표현해보려고 합니다. 저는 테크니컬 리더를 꿈꾸는 개발자입니다. 올 한 해는 그 깜냥을 갖고 있는지 알아보기 위해 스스로 시험대에 올랐습니다.
멘토를 필요로 하던 주니어가 성장해도
최근에 우연찮은 계기로 개발자 한 분이 작성한 이력서를 첨삭하였습니다. 사내 동료도, 지인도 아닌 모르는 분께서 공개적인 피드백을 받기 위해 공유하셔서 눈길을 사로잡았거든요. 그런 용기와 결단은 아무나 가질 수 없다보니 이끌렸습니다. 이력서를 살펴보니 머릿속이 하얬던 시절이 떠올랐습니다. 스스로 방향을 못 잡고 막막하게 방황한 심정을 누구보다 잘 알기에 아는 한도 내에서 도와드렸습니다.
돕기로 마음을 정했으면 제대로 해야겠죠? 무작정 피드백하는 건 도움 되지 않겠다 싶어서 계속해서 질문을 드렸습니다. 어떤 사람인지, 그동안 개발을 어떻게 해왔는지 알아야 어울리는 전략을 세우거든요. 표면에 드러난 상투적인 조언은 누구나 하는 말이니 자신의 이야기를 꺼내도록 도왔습니다. 계속해서 되묻다보니 이력서에 자신을 드러내지 못 한게 보였습니다. 무엇이 본인의 강점인지 모르는 느낌이었죠. 아무래도 ‘이게 이력서에 쓸 내용이야?’라며 대수롭지 않게 넘겼을 겁니다. 유명 그룹사 최종 면접에 갈 정도였지만, 수차례 입사 서류가 걸러진 이유였습니다.
굳이 일화를 통하지 않더라도 많은 분들이 동의해주십니다. 개발에 발을 들인지 얼마 안 된 주니어에게 멘토가 필요하다는 사실을 말이죠. 똑같은 개발자일지라도 추구하는 방향에 따라 알아야 하는 지식도 다르고, 그 중에서 우선순위를 정하는 일도 쉽지 않습니다. 괜히 매 년 마다 개발자 로드맵이라는 소재가 인기글로 올라오는게 아니죠. 언제나 성장이 고픈 신입은 자신을 이끌어줄 사수 혹은 멘토가 존재하기를 희망합니다.
시간이 흐르다 보면 어느새 멘토를 원하던 신입 시절이 지나갑니다. 드디어 스스로 바라던 멘토가 될 정도로 성장하지만, 주니어를 위해 움직이시는 분들은 많지 않습니다. 개발 커뮤니티 활동을 하면 확연하게 드러나죠. 매번 보이시는 분들만 보이고 가장 열심히 질문에 답변해주십니다. 회사라고 다를 바 없습니다. 실무에 치여 바쁠 수도, 더 많은 책임에 짖눌릴 수도 있지만 그건 누구나 마찬가지입니다. 핑계일 뿐이죠. 그들은 도움을 필요로 하던 올챙이 시절 기억을 잊어버린 걸까요?
많은 개발자들의 장벽, 사일로 효과
곡식이나 사료를 저장하는 굴뚝 모양 창고를 사일로라 부릅니다. 사일로는 독립적으로 존재하며 품목이 뒤섞이지 않는 역할을 수행하죠. 그 모습이 마치 서로 장벽을 쌓은 채 협조하지 않는 부서이기주의와 같다고 하여 생긴 용어가 사일로 효과입니다.
조직을 운영할수록 사일로 효과가 발생하는 건 어쩌면 당연한 결과입니다. 부서 별 성과 측정 후 차등 보상하라는 이야기 들어보셨죠? 경영과 관련된 흔한 조언입니다. 실제로 대다수 회사가 이를 따릅니다. 부서, 팀, 개인에 대한 등급을 나누고 그에 따라 연봉과 인센티브를 지급합니다. 상대평가든 절대평가든 상관없이 보다 나은 보상을 얻으려면 주변 동료보다 높은 평가를 받아야 합니다. 당연한 이야기죠.
성과에 따른 보상이 뒤따르면 구성원의 책임과 성취가 높아져 기업 이윤이 증대한다고 주장합니다. 일정 부분 동의합니다. 분명 개인은 본능적으로 기회비용을 계산하여 더 나은 보상을 선택을 할 겁니다. 그저 주변 동료나 조직 전체의 이익과는 상관없는 방향으로 나아갈 가능성이 높죠. 지분이 없는 이상 중요한 건 회사의 비전보다 연봉입니다. 심지어 그들에겐 기업이 나아가는 방향성과 비전을 파악할 정보가 존재치 않죠. 결국 개인은 남들보다 좋은 보상을 얻는다면 전체 이익은 고려하지 않게 됩니다. 중요한 건 오로지 ‘내 성과’거든요. 전체의 이익은 아무래도 좋다는 행동이 모여 부서이기주의로 발전합니다. 부서이기주의는 협업의 걸림돌로 작용하며 결국 비용 증가를 초래하고 맙니다. 아이러니한 이야기죠.
모두가 ‘성과’라는 최적점을 향해 나아가는데 어째서 비효율이 발생하는 걸까요? 그건 바로 죄수의 딜레마로 입증 가능합니다. 구성원 각자가 스스로 선택할 수 있는 최적점을 추구할 때 비효율이 발생할 수 있다는 건 게임이론 단골 소재입니다. 그만큼 파훼법도 명확합니다. 죄수의 딜레마를 일으키는 전제 조건을 깨트리면 됩니다. 죄수의 딜레마 핵심 요건은 바로 정보 차단과 참여자 간 소통 단절입니다. 즉, 사일로 효과는 바텀업 피드백을 받아드리는 문화로 타파됩니다.
게임이론은 상호의존적인 의사결정을 다루는 미시경제학입니다.
평사원인 제가 감히 말하건데, 개발문화를 위해 시작한 「개발 큐레이션」의 목표 또한 사일로 파괴입니다. 물론 이조차 불가능한 조직이라면 이직을 권유드립니다만, 다행스럽게도 사람인에이치알 IT연구소는 개방적인 조직입니다.
동료와 함께 나아가기 위한 「개발 큐레이션」
개발 분야는 방대하기에 누구보다 개발을 잘 한다고 여기지 않습니다. 사회에 진입한지 오래되지 않은 분들도 각자 뛰어난 역량을 드러내죠. 누구에게나 배울 점이 존재합니다. 하지만 이를 드러내지 않으면 우리는 알 방도가 없습니다. 함께 일하는 동료라도 마찬가지입니다. 개발 조직이 열 명 내외라면 또 모르겠지만, 규모가 커질 수록 요원한 일입니다.
한 가지 가볍게 계산해볼까요? 일대일로 만나 한 시간 이야기하려면 2명일 때 서로 1시간씩 사용하므로 2시간, 3명일 때는 6시간, 4명일 때는 12시간, 5명일 때는 20시간이 필요합니다. 수식으로 풀면 ManHour = (N - 1) * N * T입니다. 즉, 개발자가 100명이라고 가정할 때 서로 만나 한 시간씩 이야기하려면 9900시간이 필요합니다. 이를 법정근로시간인 8시간으로 나누면 1237.5일입니다. 1년의 20퍼센트가 주말을 포함한 휴일로 가정하면 업무 기간은 대략 290일이니 4년이 넘는 시간을 할애해야 서로 한 시간씩 이야기할 수 있습니다. 물론 멀티쓰레드를 활용하여 동시에 운영하면 전체 기간은 줄어들겠지만, 총량이 9900 Man/Hour인 건 변함 없죠. 만약 천 명이라면 99.9만 시간이 필요합니다. 조직이 크면 클수록 소통을 위한 비용은 기하급수적으로 늘어납니다. 이게 바로 사내에서 「개발 큐레이션」을 시작한 또다른 이유입니다. 동료를 찾아가 한 명 한 명 이야기하기에는 비용이 너무나도 큽니다. 이를 허락해줄 회사도 없을 겁니다. 우리는 전략을 세워 다가가야 합니다.
「개발 큐레이션」을 모아보니 가슴이 웅장해지네요.
「개발 큐레이션」은 다양한 기술 뉴스와 개발 이론 뿐만 아니라 동료가 잘 해낸 프로젝트, 사내 시스템에서 개선해야 할 문제 등 여러 주제를 함께 나누는 장입니다. 모두가 아무런 거리낌 없이 개발에 대해 이야기하려면 앞장서서 소리 낼 사람이 필요하기에 스스로 무대를 세워 올라섰습니다. 평소에도 출퇴근길에 혼자서도 개발 뉴스 중 괜찮은 걸 선별해서 읽으니 생활 변화는 크지 않았습니다. 어차피 개인 시간은 예전부터 할애했습니다. 그저 동료를 위하여 한 번 더 선별하고 읽기 좋게 정리할 뿐이죠. 무분별하게 웹 상에 놓여진 자료를 주제 별로 묶어 정기메일링으로 공유하기 시작했습니다. 동료들이 관심을 보이는 주제도 다루고, 평소 관심 깊게 공부하던 내용을 소재로도 삼았습니다. 상황에 걸맞는 주제를 선정했습니다.
22회차를 기준으로 232일 째 발행 중입니다. 대략 11일에 하나 발행했으니 격주 발행 정기 메일링 타이틀을 지켜냈습니다. 발행 간격을 줄이면 줄였지, 단 한 번도 격주 발행을 깨트린 적 없으므로 당연한 결과죠. 회차 당 평균 6.27개 자료를 사용했습니다. 그보다 놀라운 건 거의 모든 회차에서 직접 작성한 토픽이 포함되었다는 겁니다. 그 열정이 새삼스러울 정도로 놀라울 따름이네요. 덕분에 이제는 그 누구에게 보여줘도 자랑할만한 보물창고가 되었습니다. 다만 수명업무와는 별개로 개인 시간을 할애하여 진행하는 사이드 프로젝트라 격주보다 짧은 발행 기간은 유지하기 힘들었습니다. 매니저도 아니기에 의욕만으로 실무와 함께 병행하기란 쉽지 않았습니다.
동료들이 움직이기를 기다린지 반 년이 지나갈 시기에 사내 개발자가 직접 「개발 큐레이션」에 투고하기 시작했습니다. 작지만 큰 변화가 일렁였습니다. 동료 뿐만 아니라 외부 개발자들에게 공유해도 무리 없을 내용이라 추가적인 교열을 거쳐 사람인에이치알 기술블로그에 개제하였죠. 글을 쓰는 일도 즐겁지만, 다른 사람이 적은 글을 교열하는 작업도 재밌는 경험입니다. 변화의 물결을 스스로 만들어냈기에 뿌듯한 한 해로 기억되겠죠. 앞으로 더 많은 개발자들이 자신의 이야기를 꺼내길 기대합니다.
개발자는 개발문화를 목말라한다
서비스 개발은 언제나 좋은 사용자 경험을 제공하기 위하여 고객의 시선에서 고민합니다. 개발문화도 마찬가지입니다. 동료와 함께 성장하기 위해 시작한 만큼 자기 만족보다 타인이 이야기해줄 피드백이 중요합니다.
처음 시작할 때 '거부 반응을 보이는 건 아닐까?'라는 기우와 달리 얼마 지나지 않아서 동료 개발자들에게 응원 메세지를 받았습니다. 직접 이야기해주시기도 하고, 메신저나 메일을 통해 잘 보고 있다며 회신도 주셨습니다. 직책자 분들께서도 관심을 가져주셔서 놀랐습니다. 「개발 큐레이션」을 직접 받지 않는 상무님 귀에도 들어 갈 줄은 몰랐습니다. 예상 범위 밖이었습니다. 마케팅을 위한 기술블로그와 달리 「개발 큐레이션」 중 일부는 쓴소리도 담았거든요. 많은 관심 덕분에 1년이 지나도록 답보하던 문제를 「개발 큐레이션」으로 공감대를 형성하여 해결하는 성과도 이루어 냈습니다.
외부 개발자 반응도 굉장히 호의적이었습니다. 고작 개발 커뮤니티 두 군데에 회고록을 공유했을 뿐인데, 열흘만에 조회수 1만을 돌파했습니다. '개발문화'로 구글링하면 회고록인 「'개발문화를 혼자서 바꿀 수 없다'며 포기하기엔 이릅니다.」가 첫 페이지에 나타났습니다. 지인 중 두 분은 재직 중인 회사 슬랙에서 회고록이 공유되고 있다며 알려주셨죠. 이 외에도 자주 참조하는 그룹과 유명한 개발자 분의 블로그에서도 제 글이 등장했습니다.
많은 개발자들은 개발문화에 환상을 품고 꿈을 꿉니다. 개발자가 아닐지라도 사람이라면 누구나 더 나은 환경에서 재밌게 일하기를 바랍니다. 굳이 다른 사람의 예를 들 필요도 없겠죠. 갈이천정渴而穿井, 저 또한 개발문화에 목말라 시작한 게 「개발 큐레이션」입니다. 단지 여타 개발자와 달리 스스로 행동으로 옮기는 적극성을 가졌을 뿐입니다.
테크니컬 리더가 갖출 요건
사실 시니어처럼 테크니컬 리더도 사람마다 다른 의미로 쓰입니다. 테크Tech라는 단어가 붙었다는 단순한 이유만으로 개발 리더 혹은 CTO를 테크니컬 리더라 부르는 경우도 봤습니다. 그러니 여기서 짚고 넘어가도록 해요. 책 한 권을 준비했습니다. 인사이트에서 2013년에 발간한 번역서, 『테크니컬 리더』입니다. 원서는 1986년에 초판 인쇄 되었습니다. 30년도 지난 원서라는 말을 들으니 어떠신가요? 낡은 이야기라 여길지도 모르지만, 소프트 스킬은 시간이 흐르더라도 그 가치가 변치 않습니다.
커뮤니케이션, 협상, 팀워크, 리더십 등 조직을 움직이는 능력
제목에 속지 마세요. 개발과 큰 상관없는 도서입니다.
테크니컬 리더는 사람들이 자신의 능력을 펼치도록 환경을 조성해주는 사람을 총칭합니다. 리더라는 단어가 마치 직책자를 뜻하는 말처럼 보이지만, 리더십은 직책자에 국한되어 발휘되지 않습니다. 직책과 상관없이 상황에 따라 드러납니다. 진행 중인 프로젝트에서 이슈가 생기면 문제를 해결하기 위한 리더십이 드러나 듯 입니다. 리더십은 다양한 성향으로 나타납니다. 그 중에서도 『테크니컬 리더』는 문제해결형 리더에 초점을 맞추었습니다.
리더십이란 사람들이 능력을 발휘할 수 있는 환경을 만들어나가는 과정이다.
전통적인 스트롱맨과는 사뭇 대비되는 모습입니다. 문제해결형 리더는 구성원을 통제하지 않고 사람들이 제 역량을 발휘하도록 돕습니다. 동기부여, 조직화, 아이디어/혁신이라는 MOI모델을 기반으로 풀어나가는 이 책은 결국 상호작용이라는 큰 틀을 유지합니다. 도와주려는 대상조차 스스로 도움을 바라야 조언을 받아드린다고 기술합니다. 도움을 필요로 할 때까지 기다리는 인내가 필요합니다.
「개발 큐레이션」을 시작하고나서 뒤늦게 『테크니컬 리더』를 읽었지만, 사뭇 닮은 모양새였습니다. 덕분에 무엇을 유의해야 하는지 깨달았습니다. 경력이 쌓일수록 하드 스킬 만큼 소프트 스킬도 중요합니다. 분명 쉽지 않은 일입니다. 어려운 일입니다. 아무도 알아주지 않을 수도 있습니다. 고달픈 길이지만, 그만큼 가치가 높기에 테크니컬 리더를 추구합니다.
누군가가 걸어갈 길을 밝힐 횃불이 되기를
졸업한 대학교에서 정교사 2급 자격증을 발급 받을 수 있기에 개발자를 선택하지 않았어도 살 길은 많았습니다. 그럼에도 불구하고 시간가는 줄 모른 채 밤새서 코딩할 정도로 개발이 재밌었죠. 결과물이 바로 드러나는 게 너무나도 마음에 들었습니다. 정석대로 이론을 기반하여 차근차근 익혔던 남들과 달리 운영하던 사이트를 물려받아 실제 서비스 로직을 리펙토링하면서 독학했기에 다른 사람이 갖는 두려움도 적습니다. 이제와서 되돌아보면 무지했기에 가능한 일이였지만, 리펙토링에 대한 부담을 느끼지 않으니 천직이라 느꼈습니다. 일선에서 물러난 작은 사이트지만, 이제 곧 20주년이 다 되어가네요.
스스로 개발자가 되기를 원했고, 개발자가 되었습니다. 부모형제친구의 의사와는 상관 없이 본인 의지로 개발자가 된 만큼 한계를 시험해보고 싶었습니다. 스스로 지닌 깜냥이 어디까지인지 궁금했고, 이 길을 시작하는 분들께 조금이나마 도움이 되는 사람이 되면 좋겠다는 마음도 존재했습니다. 그에 대한 첫 단추가 사내에서 진행한 「개발 큐레이션」입니다. 또다른 누군가가 이 이야기로 영감을 얻어 다른 개발자들을 위한다면 더이상 바랄 게 없겠네요. 불평불만만 하면 그 무엇도 바뀌지 않습니다. 한 번쯤 용기를 얻어 동료와 소통해보시는 건 어떨까요?
2022년에는 한층 더 시니어에 한 걸음 다가가길 바라며 글을 마칩니다. God bless you.
p.s. 링크드인 뉴스레터로 공개용 「개발 큐레이션」을 시작했습니다. 관심있다면 구독해주세요!
참고자료
Devellany
back-end Developer
PHP, Java, JavaScript, MySQL, Redis, Ubuntu, Nginx
Codeigniter, Laravel, Zend, Phalcon, Spring Boot, JPA
PHPStorm, IntelliJ, Upsource, SVN, Git, Telegram Bot