작년 3월 신입 개발자로 입사한 나는 부푼 꿈을 안고 개발자로서의 커리어를 시작했다. 작은 스타트업이었다. 코드리뷰는 당연히 없었고, 업무를 위해 참고할 수 있는 문서가 단 한 장도 없었다. 나에게 "개발의 왕도"를 제시해줄 수 있는 시니어 개발자도 없었다. 거기다 회사일이 많았기 때문에 CTO님이나 사수가 신입 개발자들을 케어해줄 수 있는 시간이 부족했다. 결국 내가 성장할 수 있는 방법을 스스로 찾아야 하는 상황이 되었다.
회사에 입사하기 전 체대 출신 개발자의 회고라는 글을 읽었다. 정수님의 발자취를 보며 나도 어떤 회사를 가더라도 내 성장 환경을 만들기 위해 행동하면 무엇이든 될 거라는 자신감을 얻었다. 스타트업 회사에 입사하는 것을 지망했기에 회사에 입사하면 어떤 것을 실천해볼지 고민해봤다. 실제로 입사해서 내가 생각했던 것들을 하나씩 실천했고 조금씩 변화해나가는 회사를 지난 9개월 동안 지켜봤다. 그런 과정을 통해 성장해가는 나의 모습을 보면서 느낀 점이 많았다. 이제 그 내용을 정리해보려 한다.
1. 개발문화 변화시키기
개발문화를 좋은 방향으로 변화시키는 것만큼 회사와 개발자에게 좋은 건 없다고 생각한다. 하지만 그만큼 변하기 어려운 것도 사실이다. 개발문화를 만들어가기 위한 과정은 운영진뿐만 아니라 모든 개발자 구성원의 동의를 얻어야하는 일이기 때문에 다른 방법에 비해 시간이 오래 걸렸다.
1-1. 문서화 시작
처음 입사하자마자 든 생각이었다. (지금은 많이 개선됐지만) 사수가 없으면 회사가 아예 멈춰버릴 것 같다는 생각이 들었다. 비즈니스, 기술적인 정보가 모두 사수에게 집중되어 있었다. 사수가 너무 바쁜 탓에 그 내용을 정리할 시간은 없었기에 필요할 때마다 다른 개발자들에게 알려주는 식으로 일이 진행됐다. 문서로 정리되지 않았기 때문에 개발자들은 사수에게 지속적으로 질문을 해야 했고, 사수는 그만큼 시간을 허비할 수 밖에 없었다. 비효율적이라고 생각했고 문서화가 필요하다고 생각했다.
다른 회사의 개발자들과 교류할 때 문서화에 대한 궁금증이 있었기에 대화 주제로 종종 꺼냈었다. 문서가 코드만큼 많다는 얘기, 문서화를 통해 얻는 이점 등 문서화의 중요성에 대해 얘기를 들었기 때문에 문서화에 대한 요구가 더 커졌다.
결국, CTO님에게 문서화를 시작하자고 적극적으로 의견을 개진했다. CTO님도 문서화의 필요성을 느끼고 있었기 때문에 Jira Confluence를 사용해 문서화를 시작하자고 선뜻 답변해주셨다. 문서화는 6월에 처음으로 시작했다. 마침 할 일을 다 끝내놓은 상태였기 때문에 본격적으로 문서화 작업을 시작할 수 있었다.
물론 처음부터 문서화가 잘되진 않았다. 사수가 종종 같이 작성해주긴 했으나 처음엔 거의 나 혼자 작성했다. 현재 187건 중 114건(약 61%)의 문서가 내 손에서 작성된 만큼 다들 문서화에 큰 관심을 가지고 있지 않았던 것이 사실이다.
문서화를 통해 몇몇 작업들에서 효과를 보고 있기 때문인지 몰라도 변화가 생기기 시작했다. CTO님이 문서화를 인사 평가 때 넣을 거라고 말씀하셔 문서화에 힘이 실렸다. 신입 개발자 분들은 누구보다 열정적으로 문서화에 참여하고 있고, 몇몇 동료 분들이 문서를 작성하고 있는 것이 눈에 보이기 시작했다.
1-2. 문서화를 통해 생긴 변화
(1) 불필요한 질문이 줄어들었다.
이전에는 인수인계를 하기 위해 담당자에게 직접 물어봐야만 문맥 파악이 가능했지만 문서로 대체할 수 있게 됐다.
(2) 신입 교육에 문서를 활용
보통 사수가 신입의 개발 환경에 대한 교육을 진행하면 평균적으로 2시간 정도의 시간이 소요됐다. 개발환경 세팅부터 시작해 Gitlab, Jira 등의 툴까지 전부 일일이 설명해줘야 했기 때문이었다.
나는 신입 교육에 필요한 거의 모든 것을 문서로 정리해뒀고, 사수가 이것을 신입 교육에 활용하기 시작했다. 그 이후로 3명의 신입을 교육했는데 30분~1시간 정도의 시간만 들여도 될 정도로 교육을 문서로 대체할 수 있게 되었다.
(3) 인사이트 공유
회사에서 기술공유가 잘 이뤄지지 않고 있었는데 문서화를 통해 해당 문제를 어느정도 해결했다.
회사에서 쿠버네티스와 RabbitMQ를 다루면서 프로덕트의 구조에 대한 이해도가 생겨 아키텍처를 도식화해 문서화했다. 다른 개발자들이 해당 문서를 확인하고 프로덕트의 구조를 이해하는데 도움되었다는 얘기를 들었다. 또, 동료 개발자 분이 Java8의 Functional Interface 기능을 사용해 하드 코딩되어 있던 코드를 리팩토링하고 문서화해 남겨두었는데 덕분에 다들 해당 기능을 확인하고 배울 수 있는 기회가 되었다.
1-3. 코드리뷰 시작
처음 입사했을 때는 코드리뷰는 커녕 Pull Request 조차 사용하지 않고 있었다. 입사 1주차부터 회사에 코드리뷰와 PR 사용을 건의했었다. 신입인 나로서는 내가 코드를 잘 작성하고 있는지 확인받고 싶었다. 하지만 CTO님과 사수는 코드리뷰에 회의적이었다. 할 일도 많은데 언제 PR 등록하고 코드리뷰까지 하겠냐는 답변이 돌아왔다.
코드리뷰에 대한 설득은 6개월이라는 시간이 걸렸다. PR과 코드리뷰에 대한 문서를 만들어 정리해두고 리뷰에 대한 얘기를 기회가 될 때마다 나눴다. 결국, 신입 및 경력 개발자들이 새로 들어오면서 개발팀의 인원이 많아졌고 CTO님도 이제는 코드에 대한 체계적인 관리가 필요하다는 것을 인정하셔 PR을 사용한 코드리뷰를 도입하게 되었다.
나도 신입이지만 신입 개발자들의 온보딩에 쏠쏠하게 사용되었다. 요구사항에 맞게 구현되었는지, 코드 컨벤션, 코드에 일관성이 있는지, 클래스 및 메소드 네이밍, 중복되는 코드를 확인해줬다. 그정도만 확인해줘도 리뷰 이전의 코드와 이후를 코드를 비교해봤을 때 확연히 좋아보였다.
2. 회사와 함께 성장하기
나 혼자만 성장하는 것은 한계가 있다고 생각한다. 사람은 주변 사람들에게 영향을 받는 존재이기 때문에, 주변이 배울 점이 없는 사람들로 가득해지면 결국 나 또한 그렇게 될 것이다. 개발팀 구성원들이 함께 성장해나가야 회사의 기술적인 레벨이 올라가고, 나도 그들에게 내가 부족한 점들을 배울 수 있다. 그래서 개인의 성장보다는 회사와 함께 성장하기 위한 방법을 고민했다.
2-1. 기술 면접에 기여
나와 회사가 성장하려면 좋은 동료들이 주변에 있어야한다. 좋은 동료들은 채용을 통해 들어온다. 다시 말해, 회사의 성장에 채용만큼 큰 영향을 끼칠 수 있는 프로세스는 없다고 생각한다. 개발자들은 좋은 면접 경험을 제공하는 회사를 선호하기 때문에 면접을 잘 준비하는 것이 중요하다고 생각한다.
신입 개발자를 뽑기 위한 면접 일정이 잡혀 CTO님이 사수와 함께 면접에 들어가고 싶은 팀원을 지원받았다. 내가 면접을 준비한다면 지금 회사에서 면접을 보면서 아쉬웠던 점들을 개선하고 채용에 기여할 수 있다고 생각했기 때문에 지원했다. 그렇게 총 20번의 기술 면접에 참여했다.
시간이 날 때마다 이력서와 프로젝트를 살펴봤다. 그리고 내가 판단할 수 있는 부분(기술적인 내용, 기여도, 기록을 얼마나 잘 남겼는지, 컨벤션을 정립했는지 등)들을 추려 CTO님한테 보고를 드렸다. 시간이 부족할 때면 퇴근을 하고 집에서 면접 질문을 준비한 적도 있다.
최근에 입사한 신입 개발자 분께 CTO님이 다른 회사를 붙었음에도 우리 회사를 입사한 이유에 대해서 물어봤다. 처음 나온 답변이 생각지도 못하게 기술 면접에 관한 얘기였다. 면접자의 프로젝트를 꼼꼼히 읽어와 질문해준 것이 느껴졌고 질문 내용도 면접을 봤던 다른 회사에 비해 좋다고 생각해 입사를 결정했다고 하셨다. 내가 기술면접을 위해 했던 노력이 확실히 도움이 되었다는 것을 확인할 수 있었다.
면접을 준비하는 과정이 회사 뿐만 아니라 나에게도 도움이 되었다. 면접 질문 목록을 자주 봤었는데 내가 몰랐던 내용이 굉장히 많았다. 모르는 내용을 면접자에게 질문할 수는 없었기 때문에 그 내용들을 공부했고 나에게 부족한 것들을 채워나갈 수 있었다.
2-2. 기술 공유
기술 공유는 내가 직접 만들자고 제안하진 않았지만 우연한 계기로 시작됐다.
성능 개선을 진행하고 난 후, 다른 개발자들도 해당 방법을 적용하면 좋겠다는 마음에서 CTO님과 사수한테 공유한 적이 있었다. 이 얘기를 들은 CTO님이 기술 공유 시간을 만들어 해당 내용을 발표해보라고 제안하셨고 나는 당연히 하겠다고 답변드렸다. 20분 정도의 짧은 발표를 준비했고 기술적인 내용과 그 성과에 대해 발표했다.
기술 공유 이후 해당 방법을 적용해보는 개발자들이 생겨 프로젝트 전체적으로 성능이 개선 되었다. 그 일을 계기로 프로젝트에 큰 변화가 생기게 되면서 기술 공유 시간이 생기게 되었다. 내가 이해하지 못한 기술에 대해 알아갈 수 있었고, 다른 개발자의 시각에서 코드를 해석해볼 수 있었다.
2-3. 시스템 구축하기
지금 나에게 주어진 버그 이슈가 주어졌을 때 간단하게 고칠 수 있는 문제지만, 이대로 두면 결국 다시 문제가 생길 것을 인지하는 때가 있다. 나는 그럴 때마다 근본적으로 문제를 해결할 수 있는 방법을 고민했다. "어떤 실수가 한 번 발생하면 그 사람의 잘못이지만, 그 실수가 반복되면 시스템의 잘못이다." 라는 말이 있다. 실수가 발생했을 때 그 실수가 다시 발생하지 않도록 시스템을 만들어 놓는 경험이 나와 회사의 성장에 도움이 된다.
실제로 입사 초반 내가 만든 버그로 인해 큰 손해를 본 적이 있었다. 예약자에게 문자를 보내는 배치 잡이 있다. 연관된 코드에 문제가 발생해 배치에서 문자가 발송되지 않는 버그가 발생했다. 그런데 문자가 발송되지 않아도 확인할 방법이 없었다. 기어코 5일 연속된 연휴에 문제가 발생했다. 2천 건 가까이 되는 문자가 발송되지 않았는데 아무도 알아채지 못했다.
여기서 버그를 만들어낸 내 잘못도 있지만 더 STAG 환경에 7일을 테스트하고 프로덕트로 배포된 지 5일이 지났는데도 이 문제를 아무도 알아채지 못했다는 것이 더 큰 문제라고 생각했다. 문제가 있는지 바로 확인할 수 있는 경로만 있다면 STAG 환경에서도 충분히 잡을 수 있는 버그였다. 나는 이 문제를 근본적으로 해결하기 위해 슬랙을 사용해 모니터링 알림을 구축했다.
해당 알림은 최근까지도 유용하게 쓰이고 있다. 슬랙 시스템이 생긴 이후로 다른 개발자들도 이를 활용해 Batch 서버의 버그를 확인하는 등 런타임에 발생하는 여러 문제에 대해 즉각적으로 피드백받을 수 있게 되었다.
3. 회사 밖에서 영감을 얻기
회사에서 개발을 하는 것만으로도 성장할 수 있지만 일은 일이기에 시간이 지나면 반복 작업으로 숙달된다. 그 편암함이 익숙해지면 하던대로 하게 되고 그런 습관은 나를 고이게 만든다. 지속적으로 발전해나가려면 퇴근한 후나 주말에 따로 시간을 내서 자신의 부족한 점을 채워나가야 한다. 새로운 기술이나 방법론에 대해 찾아보거나 다른 회사들은 어떻게 개발하고 있는지 참고해보는 등의 접근이 발상을 전환하는데 큰 도움이 될 수 있다.
3-1. 개인 프로젝트
개인적으로 알고 지내는 지인들과 프로젝트 진행했다. 새로운 기술을 공부해보고자 하는 마음도 있었고, 다른 개발자 친구들의 코드 스타일을 분석해 내 코드를 개선해보고 싶었다. 회사에서는 사용해보지 못한 기술을 연마했고 프로젝트 커뮤니티를 통해 모각코, 스터디 등을 진행해 부족한 부분을 함께 채워나갔다.
최근에 진행했던 프로젝트에서는 특히 REST Docs + Swagger UI와 Spring Security를 집중적으로 공부했었다. 개인 프로젝트에서 구현할 때는 굉장히 오랜 시간을 들여 공부하고 구현했다. 그런데 우연찮게도 신규 프로젝트를 맡아 진행하게 되었다. 기한이 촉박했고 해당 기술을 사용해야만 하는 상황이었기 때문에 그 기술을 알고 있는 나에게 기회가 온 것이었다. 개인 프로젝트에서 공부해둔 덕분에 굉장히 빠르게 Swagger와 인증/인가 기능을 구현할 수 있었다.
언제 어떻게 새로운 프로젝트를 할 수 있는 기회가 찾아올 지 모른다. 준비가 되어 있어야 그 기회를 잡을 수 있다. 지속적으로 개인 프로젝트를 진행하고 새로운 개발 지식을 공부해나가는 것은 필수적이라고 생각한다.
3-2. 기술 블로그
다른 회사나 개발자의 기술 블로그가 프로덕트의 비즈니스 로직의 개선과 나의 성장에 도움이 됐다. 회사에 시니어 개발자가 없는 상황이기 때문에 웬만한 문제해결을 스스로 해야하는 상황이다. 때때로 내가 감당하기 어려울 정도의 복잡한 로직을 구현하라는 요구 사항이 주어지기도 하는데 그럴 때마다 도움이 된 것은 다른 회사들의 기술 블로그에 작성된 Best Practice였다.
회사에서 개발하고 있는 쇼핑몰 프로젝트의 포인트 구조에 불합리한 점이 많았다. 포인트를 만료시키기 위해 모든 로우를 계산하는 방법을 사용해야 했기에 때문에 속도가 확연히 느렸다. 그러다 우아한형제들 기술블로그의 신규 포인트 시스템 전환기라는 글에서 힌트를 얻어 포인트의 테이블 스키마를 변경하고 마이그레이션하여 로직을 새로 만들었다. 해당 로직을 적용하고 나니 만료일이 된 포인트만 체크해 만료처리할 수 있었고 성능을 20배 개선했다.
3-3. 강의와 책
회사에서 업무와 관련된 강의나 책이라면 필요할 때마다 지원해주겠다고 했기 때문에 마음 편히(?) 강의를 구매할 수 있었고, 지금까지 입사 이래로 총 10편의 강의를 수강했다. 회사에서 사용하는 스택인 자바나 스프링에 익숙하지 않았기 때문에 영한님의 강의를 위주로 들었고 그 외 필요한 강의와 책을 곁들였다. 강의를 통해 배운 기술을 신규 프로젝트 적용해 도움이 됐다. 회사에서 사용하는 기술과는 다른 기술을 공부하더라도 강의에서 배운 내용을 응용해 회사 프로젝트에 적용해볼 수 있었다.
영한님의 JPA 로드맵을 들으면서 N+1 문제를 해결하기 위한 방법들을 공부할 때였다. 문제를 해결하기 위해 @BatchSize를 사용할 수 있다는 내용이었다. @BatchSize의 동작 원리에 대한 설명을 들었는데, 거기서 영감을 얻어 다른 DB 접근 기술인 MyBatis 쿼리를 개선했다.
글을 마치며
자기 할 일을 묵묵히 하고 따로 시간내서 꾸준히 공부해도 충분히 성장할 수 있다고 말하는 이도 있을 것이다. 누군가는 지금 다니고 있는 회사를 좋게 만들기 보다는 자신의 실력을 키워서 좋은 회사를 가는 것이 빠르다고 생각할 수 있다.
또, 어떤 회사에서는 의견을 제시해도 완전히 무시당할 가능성도 존재한다. 우리 회사는 서비스 회사이고 운영진들이 신입 직원의 의견에 수용적인 편이었기에 내가 이런저런 의견 제시했을 때 받아들여지기 유리한 점도 있었을 것이다.
나는 주어진 환경에서 더 빨리 성장할 수 있는 방법을 고민했고 회사와 함께 성장하는 것이 최선의 선택이 될 거라고 생각했다. 내게 주어진 환경이 나쁘지 않다고 생각했고 내가 충분히 영향력을 발휘할 수 있게 권한을 줬기에 내가 하고 싶은 것을 할 수 있었다. 회사의 일이 나의 일인 것처럼 했기에 회사에 많은 시간을 쏟았지만 아깝지 않을만큼 완전히 달라진 회사와 나의 모습을 볼 수 있었다. 발전하고자 하는 동료가 곁에 있고 그들이 나의 말에 귀기울여 준다면 회사를 변화시키기 위해 무엇이든 시도를 해볼만 한 가치가 있다고 생각한다.
