회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
개발자는 무엇을 성장 지표로 삼아야 할까? 나는 개발을 처음 시작한 후부터 지금까지 지표에 대해 많이 고민했다. 그중 개발자 로드맵과 드라이퍼스 모델을 참고하여 현재 나의 위치를 점검해 보았다. 먼저 개발자 로드맵에 따르면 개발 지식을 얼마나 자신의 지식으로 소화하는지에 따라 현재의 수준이 정해지고, 드라이퍼스 모델에서는 코드의 생산성에 따라 달라진다.
이들을 종합적으로 고려하면 결국 개발자가 얼마나 성장했는지는 ‘개발할 수 있는 기능의 범위와 코드 퀄리티’로 측정이 가능하다. 이 두 가지 측면에서 보면 나는 1년 전보다 나아졌다고 자신 있게 말할 수 있다. 과거에는 구현 요구사항이 크거나 복잡하면 해결이 어려웠지만, 지금은 구현할 수 있는 기능의 범위가 넓어졌다. 또한 좋은 코드와 나쁜 코드를 구별할 수 있는 기준도 생겼다. 이전에는 코드 리뷰에서 소통이 막히는 경우가 많았다면 지금은 거의 없는 편이다.
오늘은 내가 개발자로서 성장할 수 있도록 도움을 준 리더들의 특징을 이야기하고자 한다. 물론 한 사람만의 특징은 아니다. 나는 흔히 말하는 ‘사수 없는 팀에서 고군분투하기’와 ‘좋은 리더가 있는 팀에서 코칭을 받으며 일하기’를 모두 경험해 본 결과, 개발자의 성장에서 리더의 역할이 중요함을 깨달았다. 물론 성장 의지가 있는 사람이라면 좋은 리더를 만나지 못해도 스스로 성장할 수 있을 것이다. 다만 좋은 리더를 만나면 성장에 가속도가 붙는다는 점에 적극 동의한다. 내가 직접 경험해 봤기 때문이다. (※이번 글은 필자의 개인적인 경험을 바탕으로 쓴 글로, 이런 사례도 있다는 점을 참고해 주면 좋겠다.)
이제 막 개발자로 업무를 시작했던 때, 처음 받았던 코드 리뷰는 정말 어려웠다. 자바스크립트 문법 지식이 잘 잡히지 않은 상태여서, 동작을 정확히 예상하지 못하고 코드를 작성하는 경우가 종종 있었다. 당시 팀 리더는 감정적인 표현이 많은 성향이었는데, 코드 리뷰에서 코드에 대한 지적과 부정적인 표정, 말투가 그대로 드러났다. 이렇다 보니 리뷰를 받는 입장에서 과도하게 주눅들 때가 많았다.
그러던 얼마 후 만난 또 다른 리더는 이성적이고 감정 표현이 적은 분이었다. 그분 덕분에 코드 리뷰를 주고받는 태도에 대해 배울 수 있었는데, 이때 팀장님의 이성적인 성향이 큰 도움이 되었다. 코드 리뷰는 작업물에 대해 수많은 피드백을 주고받는 과정이다. 따라서 감정 표현은 적게 할수록 지치지 않고 오래 대화를 나눌 수 있다고 생각한다. 이때의 경험을 통해 나는 코드 리뷰에 대한 부담을 덜었고, 코드를 읽고 토론하며 개선하는 과정 자체를 즐기게 되었다. 이 경험이 없었다면 아마 지금까지 코드 리뷰에 대해 큰 부담을 갖고 있었을 지도 모른다.
내가 만난 대부분의 리더들은 질문을 좋아했다. 한번은 팀장님이 슬랙 팀 메신저에 ‘심리적 안전감’에 대한 영상을 공유하며, 개발자에게는 질문하는 태도가 정말 중요하다고 강조했다. 이분은 평소 팀원들이 설계나 디버깅에 대한 고민을 들고 찾아오면 꽤 긴 시간 동안 함께 고민해 주곤 했는데, 사소한 질문도 넘기지 않고 진지하게 들어주었다.
그리고 팀장님 또한 다른 팀원들에게 질문을 많이 했다. 기획자, 디자이너, 다른 팀 개발자에게까지 정말 다양한 질문을 했다. 특히 기획의도나 UX/UI 디자인 의도가 이해되지 않으면, 담당자에게 정중한 태도로 궁금증이 모두 해소될 때까지 열심히 질문하고 필기했다. 특이하게도 그분의 질문 범위는 개발에만 국한되지도 않았다. 내가 퇴근 후 남아서 스터디를 진행하고 있으면 어떤 것을 공부 중인지 물어보기도 했고, 친해진 사람들과는 취미에 대한 얘기도 많이 나눴다. 개발 외에도 다방면에 호기심이 많은 분이었다.
이 분을 통해 질문할 때는 서로가 가진 생각과 이해의 수준을 같게 맞추는 것이 꼭 필요함을 알게 되었다. 나는 수많은 질문 끝에 원래 의도한 대로 기능을 개발할 수 있었다. 질문은 두루뭉술했던 내용을 뾰족하게 깎아내는 수단이 된다. 정확한 의사소통을 위해 계속해서 질문을 주고받는 동안 개발의 방향과 목적이 점차 명확해진다. 또한 팀 내에서 많은 질문이 오고 가다 보면 서로의 업무 스타일도 파악할 수 있고, 팀원들 간에 친밀감도 생겨서 장기적으로는 시너지를 낼 수 있는 팀으로 도약하는 계기가 된다.
한번은 새로운 개발팀에 합류해 온보딩 과제를 하던 중, 욕심이 생겨 늦은 시간까지 회사에 남은 적이 있다. 그날따라 팀장님도 야근이었는데, 어느새 내 옆에 와서 말을 건넸다.
“이번 개발에서 본인이 가장 신경 쓴 부분은 뭔가요?”
당시 검색 기능을 구현중이었는데, 검색할 쿼리 키워드와 페이지, 데이터 개수 등의 검색 패러미터들을 효율적으로 관리하는 데 초점을 맞추고 있었다. 그리고 이 부분을 나름 효율적으로 짰다고 생각해서 이에 대해 설명하기 시작했다. 내 설명을 듣던 중 팀장님이 물었다.
“검색 속도를 더 높일 수 있을까요?”
테스트 환경에서 검색 API가 호출되어 데이터를 받아오는 속도는 이미 충분히 빨랐기 때문에, 속도에 대한 고민은 미처 생각하지 않았다. 하지만 네트워크 환경에 따라 API 호출에는 얼마든지 지연이 발생할 수 있었고, 그 영향을 덜 받게 동작할 수록 사용성이 높아지는 것은 당연했다. 만약 사용자가 검색 버튼을 누르기 몇 초 전에 미리 API를 호출해서 데이터를 받아오고, 버튼을 누르는 순간에는 받아온 데이터를 보여주기만 한다면 충분히 사용성이 더 높아질 수 있었다. 다만 과도하게 많은 호출을 막기 위해 적절한 타이머를 걸고 디바운싱을 적용해야 했다.
이때부터 나는 API를 호출하는 시점과 횟수에 대해 고민하기 시작했다. 이것은 일정 시간마다 API를 호출하는 디바운싱 처리, 직전 네트워크 요청을 취소하는 브라우저의 AbortController API에 대해 공부하는 계기가 되었다. 내가 만났던 좋은 리더들은 이렇게 종종 새로운 화두나 생각할 거리를 던져주어, 스스로 공부할 수 있는 기회를 만들어주었다.
팀원으로서 겪는 난감한 상황 중 하나는 리더의 말을 제대로 이해하지 못했을 때다. 잘 모르는 개념은 검색이나 학습을 통해 이해할 수 있지만, 리더가 제시한 방향이 모호하다고 느껴질 때는 결국 정확한 이해를 위해 다시 질문하게 된다. 개인적인 경험으로는 리더 입장에선 사전에 공유한 컨텍스트만 잘 고려하면 돼서 이에 대한 설명을 생략했는데, 팀원은 컨텍스트를 숙지하지 않았거나 잊어버려서 지시를 모호하게 느끼는 상황도 있었다.
아직 주니어인 내가 리더의 고충을 전부 이해하기는 어렵다. 하지만 팀원으로서의 고충은 분명히 있다. 바로 컨텍스트 숙지가 꽤 어려운 일이라는 점이다. 경험이 많은 개발자는 시야가 넓고 그물망처럼 머릿속에 쌓이는 컨텍스트도 많을 것이다. 하지만 경험이 적은 개발자 눈에는 당장 맡은 작업밖에 보이지 않고, 다음 작업에 집중하다 보면 이전 작업에 대해서는 잊을 때가 많다.
쉽게 말해 주니어 개발자의 경우, (어쩌면 나만의 경험일 수도 있지만) 지금 작성하고 있는 코드 외에 다른 것은 머릿속에 없다. 그래서 현재 코드와 상관없는 이야기가 나오면 컨텍스트 스위칭에 시간이 걸린다. 그래서 처음부터 가이드라인을 명확하게 준다면 매번 컨텍스를 찾기 위한 시간을 들이지 않아도 된다. 서로 여러 번 묻고 답할 필요 없이 한 번의 지시로 해결되니 업무 효율도 극대화할 수 있다.
내가 겪은 좋은 리더들의 경우 대부분 말수가 적었다. 물론 앞서 말한 질문이 많은 팀장님 같은 예외도 있었지만, 팀원들이 믿고 따르는 리더들은 대부분은 과묵한 분이 많았다. 왜 그런지에 대해 생각해 봤는데, 과묵할수록 사람들이 그 사람의 말을 중요하게 생각한다는 것이다. 회의 시간에 말없이 듣기만 하던 사람이 입을 열면 시선이 그에게 집중된다. 또한 말을 하지 않는 동안 충분히 생각을 정리했기 때문에, 말이 대체로 명료하고 말실수가 적은 편이다. 따라서 신뢰할 수 있는 사람으로 느껴질 가능성이 높다고 생각한다.
유저에게 직접 제공되는 서비스를 개발하는 팀에서 버그를 만든다는 것은 꽤 큰 책임감이 따르는 일이다. 사소한 불편이 쌓이면 서비스 이용자 수가 줄고, 이는 매출에 영향을 줄 수 있기 때문이다. 따라서 개발팀은 이런 일을 미연에 방지하기 위해 컨벤션, 코드 리뷰, 리팩토링, 테스트 코드, QA 등 여러 장치를 마련한다.
그러나 버그 없는 완벽한 개발이란 사실상 불가능하다. 버그를 만들지 않는 것도 중요하지만, 발생한 버그를 정확히 파악하고 고치는 것 또한 중요하다. 경우에 따라서는 디버깅을 잘 하는 것이 기능을 잘 만드는 것만큼이나 팀에 기여하는 일이 된다. 나는 처음 개발팀에 소속되면 내가 만드는 툴과 서비스를 열심히 사용해 보는 편이다. 어느 날은 화면을 이리저리 눌러보던 중 눌리지 않는 영역을 발견하게 됐다.
이를 QA팀에 제보했더니 이미 알고 있지만 해결하지 못한 버그였다. 당시 나는 공식적인 업무를 받기 전이여서, 그 버그를 해결해 보기로 마음먹었다. 약 일주일간 디버깅 툴을 활용해 들여다보니, 결과적으로 아주 작은 크기로 화면에 고정되어 있는 opacity 0의 컴포넌트 레이어를 발견했다. 이 결과를 바로 팀장님께 공유했는데, 팀장님은 슬랙 전체 채널에 이 사실을 알리며 박수를 보내주었다. 이후로도 팀장님은 종종 업무 크기와 상관없이 팀원들의 성과를 공개적으로 칭찬했고, 팀원들의 성과를 널리 공유하는 문화는 팀에 활기를 불어넣어 주었다.
일을 잘하는 리더들은 휴가를 갈 때도 쿨하게 떠나는 모습이었다. 물론 휴가 중 긴급대응을 하는 경우도 간혹 있지만 대부분은 충분히 자주 휴가를 즐기며, 에너지를 충전한 모습으로 돌아왔다. 야근은 상황에 따라 불가피한 경우도 많기 때문에 이를 개인의 특징으로 단정 짓기는 어렵다. 그러나 체계적으로 일과를 처리하고, 병목이나 문제가 생겼을 때도 빠르게 해결된다는 느낌을 받았다.
한때 나도 습관적으로 야근을 했는데 이런 리더들의 모습을 지켜보면서, 효율적으로 일하고 쉴 때 쉬는 사람이 일을 잘하는 것이라고 생각하게 됐다. 그때부터 작업의 효율과 리듬을 생각하며 일하게 되었고, 불필요한 야근을 줄이기 위해 노력하고 있다.
지금까지 팀원을 성장시키는 리더의 특징을 살펴보았다. 이번 글은 개발자 입장에서 살펴봤지만, 어떤 팀이든 팀원의 성장은 혼자서 이뤄지지 않는다고 생각한다. 리더와 논의하고 동료들과 협업하면서 결과물을 개선해 나가는 과정이며, 이를 통해 개인과 팀 모두 성장할 수 있다. 만약 현재 속한 팀에 좋은 동료와 리더가 있다면 큰 행운으로 여겨야 한다. 그들의 코드와 일하는 방식을 보고 따라 하는 것만으로도 많은 도움이 되기 때문이다.
본문에서 자세히 다루지는 않았지만 좋은 리더들은 늘 팀원들의 고민에 관심이 많다. 성장에 대한 갈증, 진로에 대한 고민 등을 진지하게 들어주고, 진솔한 조언을 아끼지 않는다. 만약 여러분이 리더의 도움이 필요한 상황이라면 주저하지 말고 먼저 도움을 요청해 보면 좋겠다. 아마 생각지 못한 인사이트를 얻을 수 있을 것이다.
요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
좋아요
댓글
공유
공유
29.0K
