11월 COMMIT은 ‘성장: 개발자들의 평생 과제’를 주제로 당근마켓 SRE 김승호 님이 경험을 나누어 주셨습니다. 성장에 대한 이야기인 만큼 엔지니어뿐만 아니라 디자이너, 기획자, 대학생 등 많은 분이 구름스퀘어를 찾아주셨어요.
승호 님은 남들보다 한발 늦게 개발 커리어를 시작했지만, 꾸준히 성장했습니다. 그 결과 지금은 어엿한 9년 차 시니어 개발자로 자리 잡았죠. 승호 님의 이야기를 11월 COMMIT에서 자세히 들어봤습니다.
🎤 이 아티클은 김승호 님의 11월 COMMIT 강의 내용을 바탕으로 재구성되었습니다.
안녕하세요, 김승호입니다
트위터에서는 ‘raccoonyy’라는 아이디를 사용하고 있고요. 닉네임은 ‘너굴’, 당근마켓에서는 ‘앨런’이라고 불리고 있습니다.
지금은 당근마켓 SRE로 근무하고 있어요. ‘SRE’라는 직군이 생소하신 분들도 계실 것 같은데요, 일반적으로 SRE는 클라우드 인프라를 운영하고 서비스 안정성을 유지하는 일을 합니다. 여기에 더해 개발자들이 직접 인프라를 운영할 수 있도록 플랫폼을 만드는 역할도 하고 있어요. 저는 SRE 팀에 속해 있기는 하지만, 주로 인프라 운영보다는 백엔드 개발을 하고 있습니다.
출판 편집자에서 개발자로
저는 2014년부터 개발을 시작했어요. 유·아동 콘텐츠를 만드는 회사에서 일을 시작했고, 5년 정도 근무하다 미디어 스트리밍 스타트업으로 옮겨 2년 정도 일했습니다. 이후에는 리뷰 플랫폼 스타트업에서 2년 정도 근무했고요. 최근에는 당근마켓에 합류해 이제 막 신규 입사자 타이틀을 뗀 상황입니다.
개발하기 전에도 경력이 좀 있는데요, 출판 편집자로 7년 정도 일했습니다. 중간에 한 번 전직한 거죠.
좋은 원고와 원서를 발굴하기도 하고, 필요하다고 생각하는 책을 기획하기도 했습니다. 책을 기획하면 기획에 걸맞은 역자, 번역자 혹은 저자를 찾아 나섰죠. 원고를 교정하고, 디자이너와 협력해 책을 만들면서 인쇄소에 감리도 다녔습니다. 책이 나오면 서점 MD를 찾아가 좋은 자리에 전시해 달라고 설득하고 온라인 마케팅 활동도 했어요. 저자와의 만남 같은 오프라인 행사를 준비하기도 했고요.
굉장히 다양한 일을 하며 다방면으로 협업했습니다. 책 한 권을 하나의 프로젝트로 본다면, 프로젝트 전체를 매니징하는 PM으로 일했었죠.
7년 정도 출판 편집 일을 했기 때문에 전직을 결심했을 때도 당연히 대기업보다 스타트업에 가야겠다고 생각했어요. 자기 주도적으로 일할 수 있고, 전체적인 업무 사이클을 다 배울 수 있는 곳이라고 들었거든요.
출판 경력까지 합치면 15년 정도 직장 생활을 했습니다. 그중 개발 경력은 9년 정도고요. 그동안 뛰어나고 배울 점이 많은 동료의 공통점을 생각해봤는데 3가지 능력으로 나눌 수 있었습니다. 업무, 개발, 그리고 협업 능력인데요, 하나씩 짚어볼게요.
업무 능력
개발자에게 ‘업무 능력=개발 능력’이라고 생각하실 수 있을 텐데요. 저는 개발 능력과 구분해서 이야기하려고 해요.
1. 우선순위 정하기
업무를 할 때 가장 중요한 단계죠. 우선순위를 정하려면 기준이 필요합니다.
업무 우선순위를 정할 때 자주 사용하는 아이젠하워 매트릭스(Eisenhower Matrix) 기법인데요. 중요성과 시급성을 기준으로 업무를 네 가지 범주로 구분합니다. 똑같은 일도 직무나 직군에 따라 다른 곳에 배치할 수 있어요.
결제 기능을 만들어야 한다고 가정해 볼게요. 결제 기능이라고 하면 덩치가 커서 사분면 중 어디에 넣어야 할지 고민되죠.
이렇게 덩치가 크면 다른 업무들이 중간에 치고 들어올 때 우선순위가 흐트러질 수 있습니다. 업무를 잘게 쪼개야 우선순위를 유연하게 조정할 수 있어요. 결제 기능을 쪼개면 당장 필요한 ‘API 스펙 결정’ 업무만 끝내고 다른 업무를 진행할 수 있죠.
다만 동료와 함께하는 일의 우선순위는 무조건 높여야 합니다. 제가 맡은 부분을 빨리 처리하고 넘겨야 동료가 그 일을 마무리할 수 있으니까요. 업무의 선후를 잘 조절하면 동료를 배려하는 개발자가 될 수 있습니다.
축구를 할 때 공을 받으면 슛하거나 패스해야 하죠. 최악은 공을 가지고만 있는 건데요, 개발도 일종의 팀플레이입니다. 일감을 맡으면 슛을 하던 패스를 하던 둘 중 하나는 빨리 해야 해요. 슛을 하는 건 업무를 처리하는 거고, 패스하는 건 동료에게 위임하거나 내 할 일을 빨리 끝내고 넘겨주는 거겠죠.
2. 우선순위 지키기
동료 중 한 분은 아침에 출근하면 슬랙 개인 창에 꼭 챙겨야 하는 업무를 적으면서 개인 스크럼을 하시더라고요. 저도 4~5년 정도 계속하고 있습니다. 놓치는 업무를 줄이고 싶으시다면 슬랙이나 카카오톡 나와의 채팅을 활용해도 좋을 것 같습니다.
업무 목록을 공개 채널에 기록하는 것도 좋아요. 잘 작동하면 공을 패스하는 역할을 하거든요. 회사 동료의 데일리 스크럼을 보고 제 업무랑 관련 있는 내용이라 조언을 드린 적도 있고, 역으로 제가 도움을 받은 적도 있습니다. 다만 공개 채널에 공유하는 건 회사의 분위기에 따라 업무 보고처럼 느껴질 수 있으니 신중하게 도입하면 좋겠습니다.
3. 우선순위 조정하기
시스템이 잘 갖춰진 회사에 다니신다면 OKR, MBO, KPI, BSC 같은 용어를 자주 들으셨을 텐데요. 이런 용어를 사용하는 이유는 회사의 장기 목표를 팀원들에게 잘 전달하고 상기시키기 위해서입니다. 개인 업무 우선순위도 이 목표에 맞춰 가야 하고요.
회사의 장기 계획 혹은 중·단기 계획을 공유받지 못 한 채로 일하시는 분들도 계실 텐데요. 이런 경우에도 회사의 목표는 분명히 존재합니다. 목표를 계속 확인하는 과정을 거쳐야 해요.
어떤 일을 열심히 하고 있는데 새로운 업무가 주어졌다고 가정해 볼게요. 새 업무의 우선순위를 높여야 할지, 하던 일을 먼저 해야 할지 혼란스러울 수 있습니다. 회사가 알려주지 않았다면요.
대표나 개발 리드, 혹은 동료에게 빨리 물어봐야 합니다. 혹시 ‘나를 귀찮아하지 않을까?’, ‘OO 님의 시간을 방해하는 건 아닐까?’라는 걱정이 앞선다면 반대로 생각해 보세요. 회사가 중요하지 않다고 생각하는 일을 하느라 시간을 쏟는 것만큼 회사가 싫어하는 일은 없습니다. 동료들도 힘들어지고요. 편하게 물어보세요. 대부분 문제는 소통하지 않아서 발생합니다.
개발 능력
개발 직군에만 특화된 이야기는 아닙니다. 모든 직군이 참고하실 수 있어요.
1. 호기심 자극하기
일 잘하는 동료들의 문제 해결 과정을 살펴보면 일단 업무를 잘 처리한 다음 중간중간 발생했던 문제 상황을 깊이 들여다보더라고요. 끝까지 호기심을 잃지 않고요.
계속 호기심을 자극해야 합니다. 가장 쉬운 방법은 뉴스레터를 구독하는 건데요, 다양한 소식을 정해진 주기에 맞춰 메일함에 배달해 주니까요. 각자 사용하시는 언어에 대한 뉴스레터를 검색하면 쉽게 찾을 수 있으니 하나씩 구독하는 걸 추천해 드려요. 산더미처럼 쌓이지 않도록 약간의 책임감을 갖고 열어보셔야 합니다.
블로그나 유튜브도 좋습니다. 자바 생태계에서 굉장히 유명하신 이동욱 CTO님의 개발바닥이나 데이터 관련 분석 코딩이 자주 올라오는 오늘코드도 있고요. 벨로퍼트(velopert)로 유명한 프론트엔드 개발자 김민준 님 유튜브도 추천드립니다. 약간 부끄럽지만 제가 운영진으로 참여하는 44BITS도 있습니다.
조금 더 적극적으로 움직이면 커뮤니티나 개발 행사에 참여해볼 수 있을 거예요. 내가 사용하는 기술 생태계에서 어떤 일이 벌어지고 있는지 다양한 이야기를 들을 수 있는 곳이죠. 다른 분들이 도전적으로 시도한 경험을 그대로 전수받을 수 있는 것도 큰 장점입니다. 행사 소식은 주로 트위터에서 접하는데요, 트위터를 하지 않는 분들은 Festa나 onoffmix에서 찾아보시면 좋을 것 같아요.
2. 호기심 채워가기
호기심만 자극하고 끝내면 아무런 득이 없습니다. 궁금한 걸 찾아서 공부해야죠.
가장 전통적인 방법은 책입니다. 저는 출판 편집을 했던 사람이라 전통 미디어에 애정이 가요. 주로 전자책과 종이책을 활용해서 공부하는 편이지만, 요즘은 온라인 강의도 많으니 충분히 잘 배우실 수 있습니다.
조금 더 활동적인 방법은 스터디랑 커뮤니티인데요. 앞선 커뮤니티는 참석자로 이야기를 듣는 데서 그친다면, 여기서는 운영이나 발표에 가깝다고 보시면 됩니다.
저는 좀 게으른 편이라 공부해야겠다고 결심하면 거기서 끝나더라고요. 다행히 책임감은 있어서 역할을 부여받으면 하게 됩니다. 그래서 택한 방법이 스터디나 커뮤니티였어요. 억지로 공부할 수밖에 없는 환경을 만든 거죠.
커뮤니티 인연이 길게 이어지기도 합니다. 커뮤니티 안에서 새로운 커뮤니티를 만들기도 하고, 새로운 커뮤니티를 알게 되기도 해요. 팟캐스트 44bits도 커뮤니티에서 파생해 시작했습니다.
이직이나 구인으로 이어지는 경우도 많습니다. 스터디나 커뮤니티를 통해 서로 어떤 수준으로 기술을 다루는지 파악한 상태이다 보니 일종의 기술 면접은 마친 거죠. 참여할 때의 태도나 뒤풀이에서의 모습을 통해 자연스럽게 어떤 성향인지도 알게 되니 컬쳐 핏도 맞출 수 있고요. 괜찮은 분이다 싶으면 회사 내부에 추천해서 데려오거나, 역으로 추천받아 다른 회사에 가기도 했습니다.
사이드 프로젝트도 좋은 방법이에요. 혹시 ‘내 트리를 꾸며줘!’ 서비스를 기억하시나요? 작년에 굉장한 화제였죠. 이 서비스도 사이드 프로젝트였다고 해요. 그러다 사용자가 몰리면서 대용량 트래픽을 운영해보는 경험을 하게 됐고요. 시간과 노력이 많이 들어가지만 성장하기 좋은 방법이라고 생각합니다.
다양한 방법을 활용해 보세요. 저도 예전에는 뉴스레터나 책만 봤었는데, 스터디나 커뮤니티 같은 능동적인 방법을 사용하니 장점이 분명하더라고요. 우물에서 탈출하는 기회를 만들어 보시길 권합니다.
협업 능력
1. 요청에 응답하기
일반적으로 API 성능을 가늠하는 중요한 지표 중 하나는 응답 속도입니다. 여러분의 응답 속도는 얼마나 빠른가요?
갑자기 동료가 찾아와 미안한 표정을 지으며 ‘혹시 뭐 하나만 여쭤봐도 될까요?’라고 물었다고 가정해 봅시다. 보통 30분만 기다려 달라고 하거나, 무슨 일이냐며 바로 동료의 고민을 듣겠죠.
동료에게 30분만 기다려 달라고 하면 이런 문제가 생깁니다. 일단 30분 안에 내 작업이 끝나지 않는 경우가 많아요. 작업 시간을 추정하는 건 늘 어려우니까요. 고구마 줄기처럼 다른 일이 엮여 있어 늦어지는 경우도 있을 겁니다. 잠시만 기다려 달라는 걸 반복하다 보면 동료는 제가 바쁘다고 생각해 요청을 꺼리겠죠.
바로 동료의 고민을 듣게 되면 일하던 맥락을 놓치게 됩니다. 1시간 동안 레거시 코드를 파헤쳐서 맥락을 잡았는데, 급한 요청을 받게 되면 당황스럽죠.
동료가 요청하는 업무가 얼마나 중요한지에 따라 응답 속도를 결정하실 텐데요. 일단 바로 일어나지 마시고 “1분만요.”라고 해볼까요? 1분 동안 마음속으로 생각했던 걸 어딘가에 간단하게 적어두세요. 어떤 일을 하고 있었고, 어디까지 맥락을 잡았고, 어떤 고민을 하고 있었는지 등이죠. 그럼 동료의 업무를 처리하고 다녀왔을 때 금방 맥락을 찾을 수 있습니다.
2. 기록으로 전달하기
개발자에게 기록은 주석을 꼼꼼하게 쓰는 것이라고 생각하실 수 있는데요, 제가 이야기하고 싶은 건 다른 기록입니다.
저는 아침마다 제 업무를 기록하는 습관이 있다고 말씀드렸는데요. 이런 습관을 들이니 한두 달쯤 지나서 제가 한 일을 돌아볼 때 정리가 수월하더라고요. 이직하려고 이력서를 정리할 때도 큰 도움이 됐고요.
개발자는 코드로 말하지만, 코드로만 말하지 않습니다. 좋은 코드를 작성해야 하는 건 맞지만, 코드 외 기록도 중요해요.
예를 들어 10원 미만의 금액은 할인해주는 코드를 만든다고 가정해 봅시다. 팀원들이 모여서 논의한 후 결정하겠죠. 다만 코드에 논의 사항을 적지는 않을 거예요. 코드에는 ’10원 미만은 할인한다.’, ’10원 미만은 버린다.’고만 적혀 있을 겁니다. 1년쯤 지나 신규 입사자가 들어왔는데 코드를 보고 이렇게 물을 수 있겠죠. “사용자 한 명당 최대 9원까지 손실이 발생하고 있습니다. 어떻게 된 일인가요?”
회사마다 다르겠지만 노션, 컨플루언스 등 어딘가에 비즈니스 로직을 적어두셔야 해요. 회의록에는 결정 과정과 결정 내용이 모두 담겨야 합니다. 결정 과정에는 왜 이 사항을 논의하기 시작했는지부터 적는 거죠.
당근마켓은 다양한 정책들이 왜 만들어졌는지 문서에 다 적혀있어 좋았습니다. 입사 후 그 문서만 보면 되니까 누군가한테 물어볼 필요가 없었어요. 해당 문화가 왜 생겼는지 바로 이해할 수 있으니 동기화가 쉬웠습니다.
성장을 넘어 성숙으로
제가 만났던 성숙한 개발자는 개발을 잘하는 것과는 조금 달랐습니다. 지금부터 말씀드리는 특징을 가진 분을 만난다면 멘토로 삼아 열심히 배우시길 바라요.
첫 번째 특징은 단언하지 않습니다. 자신이 모르는 영역에 대해서는 상대의 말을 듣고 존중하면서 대화하시더라고요. 언제든 내 이야기가 틀릴 수 있다는 사실을 인정하는 자세를 가진 분들이 많았습니다.
두 번째는 우월감을 드러내지 않아요. 프로그래머들은 가끔 자기 직군을 우월하게 느끼는 경우가 있는 것 같습니다. 멋있긴 하죠. 저도 그래서 이 일을 하고 있고요. 아이디어를 현실로 구현하고 사람들이 내가 만든 서비스를 사용한다는 건 굉장히 흥미진진한 일이에요. 다만 개발 직군이 아닌 분을 만났을 때도 당연하게 그분만의 고유한 영역이 있다는 걸 인정하고 존중해야 합니다. 종종 “프로그래밍 너무 힘들다. 기획자나 할까?”, “데이터 분석가나 돼 볼까?”라는 이야기를 쉽게 뱉는 경우들이 있는데요, 입장을 바꿔 생각해 보면 기분 나쁘겠죠. 쉽게 내뱉는 말속에 은근한 우월감이 있는 건 아닌지 조심해야 합니다.
마지막으로 유행을 따라가지 않습니다. 업계에는 항상 유행어가 있죠. 제가 개발을 막 시작하던 무렵에는 ‘Ajax’와 ‘User Generated Content(UGC)’가 유행이었어요. 요즘은 ‘Domain Driven Design(DDD)’이나 ‘MicroService Architecture(MSA)’가 많이 사용되는 것 같고요.
용어가 중요한 건 아니라고 생각합니다. 내가 MSA 개발자인지 DDD 개발자인지 수식어가 중요한 게 아니라는 뜻이에요. 용어는 그저 공통으로 나타나는 현상에 이름을 붙인 거니까 새로운 용어만 쫓진 마세요.
지금까지 말씀드린 모든 것들을 잘 챙겨야만 뛰어난 개발자가 되는 건 아닙니다. 저도 못 챙기는 영역들이 많아요. 부족한 걸 차근차근 채워나가다 보면 어느 때쯤에 성장해 있는 자신을 발견할 수 있을 거예요.
주변에서 성숙한 개발자를 찾으면 좋지만, 여러분 스스로가 성숙한 개발자가 되는 것도 방법입니다. 누군가 나와 함께 일하는 걸 즐거워하는 건 기분 좋은 일이니까요. 앞서 말씀드린 다양한 능력을 갖추기보다 성숙한 사람이 되기를 권하고 싶습니다. 능력은 좀 부족해도 성숙한 사람과는 같이 일하고 싶더라고요. 어디에선가 개발자로 만나 함께 일할 수 있다면 영광일 것 같습니다.
Edit Sunny Design Lil
