주니어 백엔드 1.5년 하고 느낀 것들 - 성과, 느낀 점 1편

2018년 7월에 백엔드 엔지니어로 일을 시작해서 곧 2020년이 된다. 이런저런 느낀 것들이 많아 1년차 정도가 되었을 때 글을 쓰려 했는데, 회고하는 겸 연말에 글을 쓰게 됐다. 궁금하지도 않을 내 얘기만 써서 따분한 글이 될까 싶어, 느낀 점들로 뒤쪽에 내용을 많이 채웠다. 쓰다 보니 내용이 너무 많아져서, 2~3개의 글로 나누어 작성해보려 한다.

성과

글에 대한 인정

올해 2~3월과 6월에는 내가 썼던 '백엔드가 이정도는 해줘야 함' 시리즈와 내게 실용적이었던 프로그래밍 공부 방법들이 꽤 많은 곳에 공유됐었다. 여러 페이스북 페이지, 트위터, 한빛미디어 dev letter, ppss 미디어, 네이버 메인 테크판 등등.. 바이럴에 생각 이상으로 많이 돌아다녀서 꽤 놀랐다.

GitHub 활동에 대한 인정

고등학생 때 만들어서 유지하고 있는 repository 삼대장이 꽤 많은 사람에게 닿았다. 열심히 갈고닦은 결과물이 인기를 얻으니 만족스럽기도 하고, GitHub 프로필 자체가 꽤 풍성해져서 좋다.

내가 만든 라이브러리를 쓴 익명의 누군가가 감사인사를 보내주거나 이슈를 남겨주는 게 이렇게 즐거운 일인지 몰랐다. 6개월 전 쯤에 프로토타입만 만들어서 간단히 배포하고 신경을 안 쓰고 있던 google-play-scraper라는 라이브러리가 있었는데, 몇 주 전에 repository에 들어가 보니 많은 사람들이 이슈를 남겨주었다.

대부분 crash에 대한 제보라 사용자들에게 미안한 마음은 있었지만, 그래도 누가 내 코드를 쓰고 있다는 게 감격스러워서 적극적으로 업데이트 버전을 릴리즈했다. 그리고 또 시간이 흘러 메일을 한 통 받았다.

대충 고맙다는 내용이었다. 나름대로 고생해서 만든 결과물이 바다 건너 누군가에게 도움이 됐다는 게 정말 만족스러웠다.

책 집필

얼마 전에 시간을 조금 들여 썼던 글 Python 3.8의 새로운 기능들을 읽고 출판사 기획자님이 메일로 연락을 주셔서, 파이썬 튜토리얼을 주제로 300페이지 정도 분량의 책을 쓰게 됐다. 몇 개월간 많이 고생하겠지만, 좋은 글로 기초를 널리 알리고자 하는 욕심을 해소할 좋은 기회가 된 것 같아 만족스럽다.

최소 경력이 된 것 같은 느낌

좋은 의사결정을 하려면 지식도 경험도 많아야 한다. 의사결정을 위한 양질의 후보들을 많이 뽑아내야 하기 때문이다. 작년에 비해, 어떤 문제를 해결하던 '오래 갈 수 있는 방법'을 더 잘 찾아낼 수 있게 됐다. 회사에서 도전도 많이 해보고, 그만큼 사고도 많이 치고, 프로젝트도 이것저것 시도해 보고 하니 경험이 좀 쌓였나보다. 동료와 부대껴서 무언가 이뤄낼 수 있을만한 경험적인 준비가 어느 정도 된 것 같은 느낌이 든다.

함께 자라기 - 애자일로 가는 길에서는, 1984년부터 1986년까지 92개 회사에서 600명 이상의 개발자를 대상으로 경력과 업무 수행 능력 간의 상관성을 연구한 자료를 인용했다. 그 자료는 아래와 같은 내용이었다.

경력이 10년인 개발자가 2년인 개발자보다 더 우수하지 않았다. 경력과 생산성은 아무 상관관계가 없었다. 단, 언어를 접한 경험이 6개월 미만인 개발자들은 전반적으로 나머지 개발자들보다 성적이 저조했다.

연구에 어떤 오류가 있을지 모르니 맹신할 수는 없지만, 적어도 공감은 한다. 최소한의 경험치만 넘어가면 경력과 직무 성과의 상관성이 생각보다 낮다는 것이다. 경력의 양보단 질이 중요하며, 도전을 칭찬하는 조직에서 한동안 수준 높은 경험을 하고 나니 꽤 많이 성장했다는 게 느껴진다.

느낀 점들

아래에서 이야기할 것들은 이 글을 보고 있는 여러분이 주니어 시절 느꼈거나, 느낄 것들과 같지 않을 것이다. 일을 시작한 시기, 배경지식, 학업 성과, 속한 조직의 성격에 따라 누군가는 평생 느끼지 않았을 내용도 있다. 그러니 공감되는 것만 같이 공감하면 되겠다.

마음가짐

나이는 핑계가 아니라 무기

어떤 기회로 말하게 됐는지는 기억이 안 나는데, 올해 초에 회사 사람들이 다 모여있는 곳에서 '어린 나이가 핑계가 아니라 무기인 사람이 되겠다'고 이야기했었다. 솔직히 '나 고등학생인데 이만큼 한다'하는 것도 어차피 내 동료들은 내 나이때 나보다 훨씬 더 잘했고, '이만큼밖에 못하지만 어리니까 괜찮은 거 아님?' 하는 회피를 하기 싫었으며, 나이 어린 게 핑계거리가 되는 것만큼 추한게 없다고 생각해서 했던 말이었다.

지금 되돌아 보면, 말했던 만큼 좋은 모습을 보여주지 못했던 것 같다. '회사의 성장에 도움이 되어 줘서 고맙다'고 하는 글을 전사에 공유하신 분은 과연 나를 떠올렸을지 생각해 보면, 별로 그런 것 같지 않아서 그렇다. 10대 생활이 이제 거의 끝나가는데, 더 많은 것을 이뤄낼 수 있었음에도 안일했던 게 마냥 너무 아쉽고, 내년에는 조금 더 완성도 높은 엔지니어로 제품에 더 많이 기여할 수 있었으면 좋겠다.

실수가 반복되지 않게 만들자

실수는 일어날 수 있지만, 반복되면 안 된다. 동일한 실수가 두 번 이상 일어나면 그건 정말 잘못한 게 맞다. 실수가 생기면 단순히 '앞으로는 이러지 말자'고 다짐하고 말 게 아니라, 원인을 근본적으로 해결해야 한다. 그렇지 않으면 내 동료들도 나와 똑같은 실수를 할 수도 있기 때문이다. API에서 버그가 생겼다면, 그냥 고치고 끝내지만 말고 적어도 테스트를 보완하는 작업 정도는 해야 한다. 제목이 그냥 '실수를 반복하지 말자'가 아닌 게 이런 이유다.

지치지 말자

학교 학습처럼 성과가 정량적으로 측정되는 공부가 아니라, 명확한 평가 기준이 없이 미래에 뭔가 도움이 되기 위한 성장 위주의 야생 학습은 학교에서의 학습 전략을 그대로 가져와 사용하기 쉽지 않았다. 학교에선 당장 실력이 빨리 늘어야 하고 취업이 되어야 하니 매일 에너지를 방전시켰는데, 그 습관을 사회에 나와서까지 유지시키려고 하니 어려운 점이 많았다. 야생 학습에 맞도록 전략을 바꿔야 했는데, 내 경우에는 지치지 않도록 완급조절을 하는 게 많은 도움이 됐다.

당장 이뤄야 할 큰 목표가 없다면, 에너지를 과소비하지 않으려고 한다. 열심히 하는 만큼 한 번 힘들기 시작하면 끝도 없었다. 하루에 10시간씩 3개월 공부하고 지쳐서 몇 주 쉬는 것보다, 하루에 2시간씩 학습하는 걸 오랫동안 이어가는 게 졸업 후의 성장에 더 많은 도움이 됐다.

컨디션 관리도 실력이다

프로는 부상을 예방하는 데에 신경쓴다. 올해엔 몸이 좋지 않아서 휴가를 쓴 적이 많았는데, 내년에는 최대한 줄여봐야겠다. 단순히 전공의 실력을 늘리는 것만으로 자기관리가 끝나는 것이 아니니 말이다. 실수하고 났을 때의 멘탈 관리도 정말 중요하다 느꼈다.

이케아 효과 금지

내가 만든 해결책을 과대평가 하지 말자. 이건 겸손을 떨자는 게 아니라 현실이 그랬다. 어쩌다 운이 좋아서 정답에 가까운 의사결정을 했더라도, 누군가는 더 잘 할 수 있었을거라는 생각을 꾸준히 하려고 한다.

학습 습관

블로그에 튜토리얼은 웬만하면 피하자

가장 후회했던 공부 방식을 꼽자면, 블로그에 튜토리얼을 썼던 것이다. 그 경험으로 글 솜씨가 늘고, 기초를 더 잘 설명할 수 있게 된 것은 틀림없지만 성장에 가장 도움이 덜 된 학습 방법이었다. 물론 튜토리얼을 작성하는 게 성장에 도움이 되는 스타일의 사람도 있으니 나의 비추천을 너무 쉽게 받아들이진 않았으면 좋겠다.

공부는 무작정 열심히만 하지 말자

시간이 지날수록 계속해서 올림픽의 신기록이 갱신되는 건, 옛날 사람들보다 지금 사람들이 유전적으로 우수하고, 더 잘 먹고, 더 열심히 했기 때문이라기보단 어떻게 부족한 부분을 채우고 더 잘 해낼 수 있을지 고민하는 과정에서 비롯된 것이라고 생각한다.

코드를 똑같이 1만 줄 작성한다고 쳤을 때, 그 과정에서 얻는 경험치는 사람마다 서로 다를 것이다. 학교에서 닥치는 대로 프로젝트에 들어가서 비슷한 코드 붙여넣어가며 공장처럼 수천 줄을 작성했던 때보다, 더 좋은 결과물을 위해 많은 부분을 고민하며 작성한 2천 줄 남짓의 코드가 훨씬 더 많은 경험치가 됐다. 각 잡고 테스트를 작성해본 것도, CI를 달아본 것도, 코드 퀄리티를 측정해본 것도, 로그 시스템을 구성해본 것도, 모니터링을 시도해본 것도 처음이었으니 말이다. 그 때는 내 자신이 너무 자랑스러워서 페이스북에 자랑 글도 썼었다.

지금 보면 부끄러울 정도의 수준이지만, 그 코드가 보고싶다면 여기로!

대충 붙여넣어 1시간에 100줄의 코드를 작성하는 것보다, 더 나은 방법을 의식적으로 고민하며 1시간에 10줄의 코드를 작성하는 게 성장에 도움이 되는 경우가 많았다. 물론 일정이 빠듯한 경우는 어쩔 수 없지만.

공부법을 몰라서 공부를 못 하는 게 아니다

수능 만점자 공부법이고 서울대 도서관 백색소음이고 공부 동기부여 영상이고 그런 게 학습의 효율을 높이는 데에 기여할 수는 있어도, 애초에 공부를 별로 하질 않으면 딱히 의미가 없다고 생각했다. 차라리 너무 잘하려고만 애쓰다 보니 학습 초기부터 즐기기가 어려웠다.

그냥 부담 없이 힘 빼고 멍청한 방법으로라도 공부를 시작하고 지속하다 보면 훨씬 즐겁기도 하고, 자기만의 공부법이 만들어질 수밖에 없는 것 같다. 이걸 여태껏 많이 경험했음에도, 새로운 언어를 배운다거나 할 때마다 너무 잘하려고만 해서 많은 부분을 실수했던 한 해였다. 이제 너무 각만 잡지 말고 그냥 무작정 도전해봐야겠다.

코딩 습관

Internal Server Error가 나는 케이스를 최대한 방어하자

'예상치 못한 이슈'는 필연적으로 생긴다고 가정하며 개발하곤 했지만, '예상치 못함' 중 '예상'의 범위를 많이 넓히지 못했다. 예를 들어 통계 데이터를 조회하기 위한 날짜 범위를 너무 길게 요청해서 API가 timeout이 난다면, 그렇게 긴 범위를 요청한 사용자를 탓할 게 아니라 범위를 제한하지 못한 최초의 설계를 탓하고 고쳐나가야 한다.

클라이언트는 무엇이든 입력할 수 있다

최근에 아주 교훈적인 사고가 하나 있었다. 서버 개발자는 클라이언트 데이터를 믿지 마라라는 글의 내용인데, 수능평가원에서 폼 데이터를 조작해 수능 성적표를 미리 발급받을 수 있었던 이슈였다.

코드의 로직만큼 중요한 게 검증(validation)이라고 생각한다. 요청의 body 중 URL이 들어오길 기대하는 필드가 있다면, 그걸 그대로 가져다가 사용할 게 아니라 타입은 문자열인지, URL 포맷에는 맞는지 등을 검증해야 한다. Validation을 제대로 하지 않아 status code 400을 내려줘도 될 요청에 500을 내려주는 상황이 꽤 자주 일어나서 아쉬웠다.

DRY한 코드에 신경쓰자

내가 학교에서 작성하던 코드들은 애초에 비즈니스 로직이 복잡하지 않아서 코드의 중복을 매우 쉽게 해결할 수 있었다. 그러면서 코루틴이나 커링같은 트릭들을 공부하는 데에 많이 신경썼는데, 좋은 코드를 위한 최고의 기본기는 DRY라는 생각이 들었다.

라이브러리처럼 코딩하자

YANGI(You Aren't Going to Need It)라는 말이 있다. 소프트웨어적 요구사항의 예측은 빗나감을 가정하며, '나중에 필요하겠지' 하는 예측보단 당장 필요한 코드만 최소한으로 유지하고자 하는 마인드로 프로그래밍에 임해야 한다는 것이다. 섣부른 예측으로 추가된 코드가 복잡도에 나쁜 영향을 줄 가능성이 크다는 것은 인정하지만, 개발하다 보면 확실하게 사용 시나리오가 예상되는 경우가 종종 있다.

그럴 때마다 '그냥 라이브러리처럼 만들어 보자'고 생각하면, 어느 정도의 범용성을 갖춘 결과물이 나오는 경우가 꽤 있었다. 결과적으론 YANGI의 원칙을 위반하는 게 되지만, 확실한 근거를 바탕으로 한 예측은 나쁘지 않다고 느꼈다. 코드 한 줄 한 줄이 빚이 되는 상황에, '오래 갈 수 있는 코드'를 만드는 건 수준 높은 기여라고 생각한다.

2편에서 이어집니다.