주니어 개발자의 마지막, 미드레벨(mid-level) 개발자의 시작

이제 곧 4년 차, 미드 레벨(mid-level) 개발자가 될 예정이다. 생각보다 빠르게 시간이 지난 것 같다. 3년의 개발 생활을 회고하면서 그동안 나는 어떤 일을 했고, 앞으로는 어떤 방향으로 개발하고 싶은지 정리하고자 이 글을 쓰게 되었다.

실무 경험을 배우고 익숙해지는 시기

입사하고 나서 약 1년 6개월 동안은 시니어 개발자와 함께 개발하면서 실무 업무를 익히고, 조금씩 업무량을 늘리는 시간을 보낸 것 같다. 그동안 1명이 운영하던 앱을 2명에서 개발을 하게 되니깐 주니어인 나는 시니어 개발자의 코드를 보고 배우는 시간을 보냈다. 시니어 개발자는 앱 서비스 개발하면서 내가 잘 따라올 수 있는지 확인해보는 시간을 보냈다. 여러 가지 미션들을 수행하면서 앱의 전체적인 구조를 조금 맛볼 수 있었고, 실무에서는 이렇게 사용하는구나 하고 배울 수 있었다. 다행히 나는 빠르게 실무 일할 수 있다고 판단되어 한 달 만에 실무 업무를 하기 시작했다. 아직도 기억나는 나의 첫 업무는 위로 가기 버튼 이미지 변경하고 모양을 바꾸는 작업이었다. 작업 후에 앱 버전 배포되었을 때도 기억나는 게, 내가 작성한 코드가 있는 앱이 세상에 나온 것만으로 너무 좋았다. 비록 수많은 코드 중에 몇 줄이겠지만, 뭔가 하나를 했다는 거에 뿌듯함을 느꼈다.

시간 지날수록 조금씩 업무를 늘려가면서, 나는 욕심이 조금씩 생겼다. 화면의 일부분만 작업하다가 화면 전체도 작업하게 되고, 처음 안 만들어본 기능도 개발하게 되었다. iMessage app이랑 Watch App 등, 여러 가지 새로운 기능들을 개발하면서 도입하고, 어떤 하나의 피쳐(feature)를 담당하는 매니저(Manager) 혹은 wrapper 클래스도 개발해봤다. 그러면서 첫 벽에 부딪히고 어려워하다가 혼자 깨트리고, 하나의 업데이트 버전(거의 개편 수준)을 혼자서 개발해 본 경험도 했다. 중간중간에도 기술 블로그 글도 썼다. 조금씩 할 수 있는 게 많아지다 보니, 자연스레 앱에 대한 이해도가 높아지고 앱 개발 외적인 배포 프로세스나 기타 등등에도 관심 두게 되었다. 앱 배포 경험은 사내 앱용으로 개발해서 배포한 적이 있었는데, 앱 스토어에 앱을 등록해서 배포한 경험은 회사 다니면서 알게 되었다. 배포에 필요한 것들과 준비하는 등 여러 가지 등을 메모해 가면서 언젠가 새로운 앱 서비스를 개발하게 된다면, 잘 할 수 있도록 준비를 했다.

iOS 파트를 이끌다

그리고 생각보다 빠르게, 시니어 개발자의 육아 휴직으로 인해 iOS 파트를 이끌어야 하는 시기가 왔다. ‘혼자서 잘할 수 있지?’ 무심코 던진 시니어 개발자의 말에 왠지 모르게 준비를 한 나 자신이 다행이라고 생각했다. 물론, 두렵긴 했다. 이제 1년이 지났는데, 아직 더 배울 게 많다고 생각하는데, 혼자서 iOS 파트를 이끌어야 하고 잘 할 수 있을지 무서웠다. 일단 부딪혀 보자 하는 심정으로 신입 개발자도 뽑아서 혼자 업무 부담을 많이 받지 않도록 했다. 물론 신입 개발자가 자기의 역량만큼 일하려면 시간이 오래 걸리겠지만, 일단 상황은 이렇게 되었기 때문에 감안하고 하루하루를 보냈다.

약 8개월의 시간은 솔직히 고통스러웠다. 일단 개발뿐만 아니라 관리까지 해야 했기 때문에, 업무량이 기본 2배였다. 개발만 신경 써야 하는 게 아니라, 앞으로 개발해야 하는 것들이 가능한지 검토해야 하고, 개발부터 테스트, 배포까지의 업무 프로세스를 알아야 하고, 앱 스토어와 관련된 내용, 가이드라인 등 개발 외적인 내용을 알고 있어야 했다. 게다가 신입 개발자가 회사에 잘 적응하고 업무 일을 할 수 있도록 옆에서 신경도 써야 했다. 흰머리는 입사했을 때부터 나긴 했는데, 이 기간에는 계속 한쪽에서 많이 나기 시작했다. 잠드는 시간은 보통 새벽 2시에서 4시 사이, 조금 심하면 6시에 자서 1시간 자고 일어나서 출근했다. 늘 퇴근해서도 공부하는 습관이 조금 있었지만, 공부는 기본이고 업무까지 해야 하는 상황이 거의 일상이었다. 그리고 하필 이럴 때, 새로운 앱 서비스를 출시해야 했다. 총 3개의 앱 서비스를 운영해야 했다. 개발 외적인 뭔가가 필요하다는 것을 느꼈다.

도구와 문화 도입

iOS 파트 이끌기 시작했을 때, 어떤 체계가 필요하다고 생각했다. iOS 파트나 팀 안에서 공유하는 문서나 기타 내용은 주로 슬랙 채널이나 노션 문서로 공유하지만, 나는 조금 더 iOS 파트 내에서 관리하는 도구가 필요하다는 것을 느꼈다. 그래서 iOS Workspace 라는 큰 노션 문서를 만들어, iOS 파트 내에 필요한 것들을 조금씩 정리하기 시작했다. 시니어 개발자가 육아 휴직하기 전, 작성한 아키텍처 혹은 iOS 프로젝트 관련 문서들을 이 workspace 문서에 옮겼고, 하나의 스프린트 작업할 때마다 기록하는 문서 등을 만들었다. 그리고 이 워크스페이스 문서는, 지금까지도 쭉 관리하고 사용하고 있다.

신입 개발자와 협업하면서 조금이라도 더 나은 개발자로 성장할 수 있도록 여러 가지 공부 내용 공유도 했지만, 개인적으로 제일 많이 도움 준 거는 코드 리뷰라고 생각한다. 개인적으로 코드 리뷰가 중요하다고 생각했고, 시니어 개발자와 둘이서 작업할 때도 종종 시니어 개발자의 코드 리뷰 받으면서 많이 고치고 배우기도 했었다. 내가 신입 개발자의 코드를 리뷰하면서 더 나은 코드 방향으로 수정할 수 있도록 도와주고, 개발한 내용을 이해하는지도 확인할 수 있었다. 그러면서 반대로 신입 개발자도 내 코드 보면서 어떤 내용인지 확인하고, 왜 이렇게 작성했는지 물어보면 대답할 수 있도록 하는 시간도 가졌다. 나도 내 코드가 완벽하지 않을 수 있기 때문에, 서로 코드를 봐주면서 하면 예상치 못한 버그를 찾거나, 더 나은 코드로 작성할 수 있다.

코드 리뷰하면서 GitFlow 브랜치 방법을 도입했다. 그 전에 사용한 브랜치 방법이 있었지만, 엔터프라이즈 용 앱 개발할 때 자동 빌드와 배포에 사용했던 브랜치 방법이었고, 나는 이 자동화 빌드까지 신경 쓸 여력이 없었다. 그래서 새롭게 GitFlow 브랜치 도입을 했고, iOS 파트랑 맞게끔 조금 수정해서 적용하여 지금까지도 잘 쓰고 있다. 관련하여 문서도 만들어서 안드로이드 파트와 공유하는 시간도 가졌다. 주 단위로 개발하는 작업의 진행 상태를 한눈에 볼 수 있는 Sprint 문서도 만들었다. 내가 개발하면서 신입 개발자의 개발 진행 상황도 보고 싶어서 도입했고, 주 단위로 자신이 해야 하는 일을 볼 수 있어서 서로 긍정적인 효과를 봤다.

협업하기

여러 도구와 문화가 도입했지만, 계속 쌓여가는 피로도는 결국 마지막에 나를 더 힘들게 했다. 중간 휴식을 취할 수 있게 매 차수 끝날 때 연차를 썼지만, 하루 이틀 가지고는 그동안 쌓인 피로도가 한 번에 풀리지 않다. 그리고 쉬고 있어도 이메일 알림 혹은 메신저 알림 들리기만 하면 심장이 쿵 내려앉으면서 무슨 일 있나 조마조마하면서 내용을 확인해야 했다. 업무 부담감을 나눠야 했다.

팀에 시니어 개발자들이 대거 채용되면서 자연스레 iOS 파트를 더 이끌지 않게 되었다. 팀장님과 파트장님께서 자연스레 업무 부담감을 가져간 덕분에 피로도가 조금씩 낮아졌다. 숨 쉴 틈이 벌어지기 시작했다. 물론 중간에 급하게 추가 요청 사항이 생기거나, 갑자기 앞당겨진 완료 날짜가 생겼었다. 그런 문제가 발생하면 히스토리를 알고 빠르게 문제를 해결할 수 있는 내가 빠르게 처리했다.

육아 휴직을 보내신 시니어 개발자까지 복귀하여 드디어 iOS 파트도 많은 개발자가 생겼다. 그동안 1~2명에서 2개의 앱 서비스 혹은 3개의 앱 서비스를 운영했었는데, 이제는 5명 이상으로 늘어났다. 자연스레 협업에 필요한 규칙도 서로 맞춰 가면서 진행했고, 골고루 업무 할당량이 주어지기 시작했다. 협업에 필요한 코드 리뷰는 사용하고 있는 소스 관리 시스템에 따라 한정적으로 사용할 수밖에 없었지만, 코드 리뷰하면서 서로 코드 보면서 수정이 필요한 부분을 찾아내거나 다른 사람의 코드를 보고 배울 수 있게 된다.

코드 리뷰하면서 배우기

그동안 1~2명에서 개발하게 되면 서로의 코드 스타일이 점점 비슷해질 수 있다. 새로운 개발 방법을 배우면 도입해보면서 할 수 있지만, 이것도 결국 오래 가지 못한다. 이번에 많은 개발자랑 협업하면서 코드 리뷰를 진행했는데, 다양한 코드 스타일과 방식을 배울 수 있어서 너무 좋았다. 1년 동안 배움에 대해 목말라 있던 나에게 너무 좋은 시간이었다. iOS 파트를 이끈 기간 동안 과연 내가 코드를 잘 작성했는지, 더 개선할 수 있는 게 없는지 항상 궁금했다. 신입 개발자 눈에는 잘 짜여 있을지 몰라도 시니어 개발자의 눈에는 달라 보일 수 있다. 나는 그런 피드백이 필요했다.

그래서 다양한 개발자들의 PR 보면서 많이 배울 수 있었고, 내가 올린 PR에 대한 피드백도 받아 볼 수 있어서 내 안의 갈증이 해소된 느낌이 들었다. 당연히, 여기서 그치지 않고 나의 코드 스타일과 개선할 수 있는 모든 것들에 대해서 적용했다. 적용하는 시간이 조금 필요했지만, 적용하면서 니 자신도 이런 게 가능하구나 하고 깨달을 수 있었다.

코드를 보면서 개발하기

시니어 개발자 중 한 명이 이런 말을 했었다. ‘코드를 보면서 개발할 수 있게 되었다’. 업무 작업량이 골고루 잘 분배되면서 시간적 여유도 생겼다. 그러면서 자연스레 코드를 보면서 개발할 수 있게 되었다고 말씀하셨다. 나는 이 말에 공감이 되었다. 그동안 빠르게 기능 개발해야 할 때는, 동작이 잘 돌아가는 것을 확인하고 다음에 더 개선해야지 하면서 넘어간 적이 많았다. 솔직히 시간이 없었다. 회사 사정상 빠르게 기능 도입하고 업데이트해야 하는 상황이었다. 거기에 맞춰서 개발하게 되면 어쩔 수 없이 코드에 많은 시간을 투자할 수 없다. 일정을 맞추는 게 우선이기 때문이다.

하지만 지금은 조금 더 여유롭게 기능 구현할 수 있는 일정이 되었다. 자연스레 코드 보는 시간이 많아졌고, 거기에 따라 더 개선할 수 없는 부분이 없나, 더 나은 방법이 없나 고민하는 시간도 늘어났다. 늘어나면서 더 나은 코드로 개발할 수 있게 된 것 같다. 지난번에 작성한 코드를 다시 보게 되면 개선할 수 있는 부분이 없나 확인해보고, 개선할 수 있으면 개선한다. 새로 개발하는 부분에 대해서 더 많은 자료를 찾는 시간도 가질 수 있고, 테스트하면서 개발할 수 있게 되었다. 코드 리뷰하면서 아이디어 얻게 되면, 그 아이디어를 가지고 개발하는 부분에 적용해보기도 한다. 개발하는 코드의 수준이 조금씩 나아지고 있다는 게 눈에 보이기 시작했다.

더 나은 코드, 더 나은 개발자

지난 3년 동안 정말 많은 경험을 했던 것 같다. 갓 신입 개발자로서 할 수 있는 일을 해보고, iOS 파트를 이끄는 경험도 해보고, 많은 개발자와 협업하는 경험도 했다. 틈틈이 개인 프로젝트 앱도 개발하고, 작지만 개인 블로그도 만들었다. 시간적 여유가 생기다 보니 코드를 보는 시간이 늘어났고, 그동안 개발한 코드를 보면서 개선할 수 있던 부분이 없었나 찾으면서 개선하는 시간을 가졌다. 바빠서 못 했던 일들을 조금씩 해보면서 앱 프로젝트의 퀄리티를 높이는 일에 힘을 더 썼다. 기능 개발은 나 말고 다른 개발자들이 할 수 있으니깐, 나는 앱 프로젝트의 퀄리티를 높이는 작업에 더 집중했다.

그러면서 코드에 대한 나의 가치관도 조금씩 달라지는 게 느껴졌다. 멋진 기능들을 개발하고 멋지고 깨끗하고 똑똑한 코드를 개발하는 게 좋다고 생각했었다. 하지만 지금은 똑똑한 코드보다 읽기 좋은 코드가 더 좋다고 생각한다. 너무 똑똑한 코드는, 한 번에 이해하는 데 시간이 걸릴 수 있고, 잘 안 읽힐 수도 있다. 여러 번 봐야 아 이런 일을 하는구나 하고 깨닫거나, 이해 못 하고 사용하지 않게 되어 개발한 사람만 수정할 수 있게 될 수도 있다. 혼자만 똑똑해지는 코드다. 읽기 좋은 코드는 신입 개발자부터 시니어 개발자까지, 모든 사람이 한 번에 이해할 수 있고, 어디든지 사용할 수 있는 간단한 코드로 보인다.

나는 앞으로도 읽기 좋은 코드, 더 나은 코드로 앱 프로젝트의 퀄리티를 높이는 개발자로 일하려고 한다. 기능 개발하면서 앱의 퀄리티를 높이는 코드를 개발해서, 신입 개발자와 시니어 개발자의 중간 다리 역할 하고 싶다. 읽기 좋은 코드로 그 다리를 만들어주고 싶다. 그 다리 만들면서 시니어 개발자로 성장하고 싶다.