2019년 개발자 회고 (2)

개요

2019년 회고 글에서 이어지는 글이다. 이번 편에서는 내가 했던 활동들과 새롭게 가졌던 마음가짐에 대해서 정리하고, 내년 목표를 글로 남겨놓음으로써 더 많은 성장을 이루기 위한 의지를 다지려고 한다.

개발자로서의 활동

첫 컨퍼런스 발표

개발자 행사는 아니었지만, 인생에서 처음으로 “연사”라는 자격으로 강단에 서서 발표했다. <스타트업 뽀시래기 컨퍼런스>, 일명 스뽀콘이라는 컨퍼런스였다. 스뽀콘은 올해 처음으로 열린 컨퍼런스로, 1~3년 차 주니어 스타트업 종사자들을 위한 이야기를 나누는 자리였다. 나는 올해 5월에 시작해서 지금도 하고 있는 사내 인프라 관련 프로젝트를 진행한 경험을 공유했다. 혹시나 궁금하신 분을 위해 발표자료를 첨부한다.

나는 이번 기회를 통해 발표의 여러 가지 장점을 느낄 수 있었다. 우선 내 이름이 알려진다는 장점이 있다. 개발자로서 실력을 쌓는 것과 명성을 올리는 것은 거의 관계가 없지만, 이왕이면 실력만 있는 것보다 둘 다 있는 것이 여러모로 좋은 것은 당연한 이야기이다. GDG Devfest에서 회사 부스에 찾아오신 분 중에서 발표를 잘 들었다고 인사해주신 분이 계셨는데, 정말 기분 좋은 경험이었다. 지금은 작은 컨퍼런스에서 한 번 발표한 정도니 큰 영향은 없었겠지만, 앞으로 꾸준히 좋은 발표를 계속한다면 인지도 있는 개발자가 될 것이다.

그리고 의외의 장점은, 발표를 듣는 청중보다 오히려 내가 배워가는 게 많다는 것이다. 발표 준비를 하기 위해서는 내가 한 일, 내가 느낀 점을 체계적으로 이야기할 수 있도록 내 경험을 되돌아보고 정리해야만 한다. 또한 발표를 할 때는 반드시 확실한 사실만 전달해야 하므로 발표 내용에 문제가 있는지 이중, 삼중으로 검토하게 된다. 이 과정에서 자연스럽게 내 경험에 대해 몇 번이고 더 곱씹어보게 되고, 그때 배운 것을 더 깊이 체득하게 된다. 이렇게 경험을 온전히 내 것으로 흡수할 수 있게 되는 점이 발표의 진정한 장점이 아닐까 싶다.

한편, 발표 역시 연습이 많이 필요한 일이라는 것을 느꼈다. 이번 발표 구성은 25분 발표 + 5분 Q&A 였는데, 발표가 익숙하지 않다 보니 말이 점점 빨라져서 25분 발표를 준비했는데 18분 만에 끝나버렸다. 어찌어찌 발표 시간을 맞추려고 잘라낸 내용을 즉석에서 발표하면서 시간을 때우긴 했는데, 정말 아찔한 경험이었다. 여유로운 마음가짐으로 좋은 발표를 하기 위해서 더 많은 발표 경험을 쌓아야겠다고 생각했다.

내년에도 발표할 기회를 가져서 내가 한 좋은 경험을 다른 사람들과 공유할 수 있었으면 좋겠다. 이왕이면 이번에는 개발자 행사가 되면 좋겠다.

블로그 글

올해는 총 7개의 개발 관련 글을 작성했다. 아래는 그 목록이다.

나는 스스로 아주 중요한 내용이라고 생각하거나, 다른 사람에게 정말 도움이 될 것 같은 글만 블로그에 공개하는 스타일이다. 나름의 퀄리티 컨트롤을 하는 것이다. 올해 블로그에 올린 글도 전부 나 스스로 만족한 글만 올린 것이다. 그중에서 베스트 글을 뽑자면 역시 3개월 차 주니어가 느끼는 나와 시니어의 차이가 아닐까 싶다. 내용도 마음에 들고, 바이럴도 많이 됐기 때문이다.

올해 4월부터 회사 동료분의 이야기를 듣고 블로그에 GA를 달았다. 특별히 조회수를 올리기 위해 무언가를 하는 건 아니고, 내 글이 다른 사람에게 얼마나 영향을 주고 있는지 궁금해서 종종 조회수를 확인해보는 용도로 사용하고 있다. 다행히 블로그 방문자 수는 꾸준히 늘고 있었다. 5월에는 1주일에 100명 정도 방문했는데, 지난주에는 300명 정도로 늘었다. 앞으로 계속 좋은 글을 많이 올려서 이름 있는 블로거가 되면 좋겠다.

한 가지 의외였던 점은, 내가 정말 좋은 내용이라고 생각했던 글은 생각보다 인기가 없고, 그저 그렇다고 생각했던 글이 인기가 많은 경우가 있었다. 나는 Lock으로 이해하는 Transaction의 Isolation Level의 내용이 그 중요성에 비해 많이 알려지지 않는 내용이라 정말 좋은 글이라고 생각했는데, 생각보다 인기가 별로 없었다. 반면 조금만 구글링하면 비슷한 내용이 나오는 JPA, Hibernate, 그리고 Spring Data JPA의 차이점은 다른 글보다 훨씬 높은 조회수를 기록하고 있었다.

블로그 글을 하나의 컨텐츠라고 생각하는 내게, 이 조회수 차이는 더 좋은 블로그를 만들기 위한 인사이트를 제공해주었다. 많은 사람이 기술을 깊이 다룬 글보다는, 가볍게 읽을 수 있으면서도 어느 정도 인사이트를 줄 수 있는 글을 선호하는 것 같다. 내년에는 이런 부분에 좀 더 신경 써서 글을 작성해봐야겠다.

개발자로서의 태도

올 한 해 동안 나는 개발자로서 성장하기 위해 정말 많은 고민을 거듭했다. 그 과정에서 여러 가지 습관과 태도, 마음가짐을 갖추기 위해 노력했는데, 여기에 정리해보았다.

오롯이 나 혼자서 가장 좋은 해결책을 생각해보기

나는 0에서 1을 만들기보다 1에서 10을 만드는 걸 더 잘하는 사람이다. 시작점을 찍는 것보다 이미 시작점이 주어졌을 때 시작점에서 목적지까지 선을 긋는 것을 훨씬 더 잘한다. 좀 더 직접적으로 이야기하자면, 나는 다른 사람의 PR을 보고 코드의 문제점을 찾는 것이나, 버그가 발생했을 때 원인을 찾아내는 것, 혹은 어떤 문제가 주어졌을 때 다른 사람의 아이디어를 보완하여 더 탄탄하고 구체적인 솔루션을 내놓는 것에는 자신이 있다. 하지만 나 혼자서 처음부터 문제에 대한 해결책을 쌓아올리는 일에는 상대적으로 능숙하지 못하다.

물론 전자 역시 개발자가 필요로 하는 역량임에는 의심의 여지가 없지만, 개발을 하면 할수록 그것만으로는 부족하다는 사실을 깨닫는다. 내가 되고자 하는 개발자는 평범한 개발자가 아니라 아주 특별하고 뛰어난 개발자다. 어떤 문제에 투입되더라도 문제를 어떻게든 해결해내는 해결사가 되고 싶은 것이다. 그러기 위해서는 지금 내가 갖춘 능력만으로는 부족하고, 반드시 어떤 문제를 마주쳤을 때 나 홀로 문제에 대한 솔루션을 내놓을 수 있는 역량이 필요하다는 사실을 깨달았다.

이 역량을 기르기 위해 내가 한 노력은 간단했다. 어떤 문제가 주어졌을 때 다른 사람의 생각을 듣지 않고 오롯이 나 혼자서 해결 방법을 생각해보는 것이다. PR이 올라오면, 다른 사람의 코드를 보기 전에 PR 설명에 적혀있는 문제를 보고 “내가 이 문제를 풀어야 했다면 어떻게 코드를 짰을까”를 머릿속에서 생각해보는 연습을 했다. 또한, 제법 큰 스펙의 기능이 들어와서 어느 정도 설계가 필요할 때 우리는 팀 전체가 같이 설계 회의를 하는데, 설계 회의를 들어가기 전에 기획서를 보고 나 혼자서 설계를 해보았다. 이렇게 나 홀로 생각해낸 솔루션과 다른 사람의 솔루션을 비교해보면서, 내가 어떤 선택을 잘했고(주로 시니어 다수와 얼마나 의견이 일치하는가로 판단한다) 어떤 선택을 왜 못했는지에 대한 피드백을 스스로 해보는 습관을 들였다.

이는 예전에 페이스북에 관련해서 글을 올렸던 “파헤치기“와 비슷하다. 덕분에 나는 다양한 문제에 대해서 깊게 고민해보고, 간접적으로 많은 경험을 쌓을 수 있었다. 물론 나 혼자서 해결책을 내놓는 데에 이전보다 훨씬 익숙해진 것은 당연한 이야기다.

한 번 더 생각하고 말하기

나는 다른 사람과 토의를 하거나 코드 리뷰를 할 때, 머릿속에서 떠오르는 생각을 바로 뱉어버리는 경향이 있다. 하지만 적지 않은 경우 내 생각에 논리적으로 오류가 있었고, 그 오류는 한 번만 더 스스로 검토해보았으면 발견할 수 있을 만큼 아주 찾기 쉬운 오류일 경우가 많았다.

그래서 내 의견을 이야기하거나 리뷰를 남길 때, 내 의견에 대해 한 번 더 검토하고, 한 번 더 관련한 코드를 읽어보는 습관을 들이려고 노력하고 있다. 지금까지의 습관이 있다 보니 아직 완벽하게 개선되지는 않았지만, 실제로 이 부분에 의도적으로 신경 쓰기 시작한 이후로 논리적으로 오류가 있는 리뷰를 하는 횟수가 많이 줄었다. 내년에는 더 많이 노력해야 하는 포인트 중 하나이다.

여담으로, 논리적으로 옳다고 생각되는 내 주장을 다시 한번 검토하려고 노력하게 된 가장 큰 이유는 뛰어난 팀원들 덕분이다. 리뷰를 하다가 “왜 이렇게 짜셨지?”라는 의문이 드는 포인트가 나오는 경우, 팀원이 뛰어나다는 인지가 있었기 때문에 “아마 내 생각이 잘못된 게 아닐까?”, “내가 놓친 포인트가 있는 건 아닐까?”라는 생각을 하게 되었고, 대부분의 상황에서 그 생각이 맞았다. 이런 식으로, 뛰어난 팀원과 함께 일하면 의도치 않은 상황에서 성장의 기회를 잡는 경우가 종종 있다. 팀원들께 감사한 순간이다.

꾸준한 스터디

분명 내 지식과 실력은 착실히 쌓이고 있지만, 한편으로 성장을 거듭할수록 시야가 넓어지기 때문에 내가 모르고 있는 부분이 점차 드러난다. 문제는, 시야가 넓어져서 모르는 부분을 인지하게 되는 속도가 내가 지식을 쌓는 속도보다 훨씬, 훨씬 더 빠르다는 것이다.

이럴 때일수록 초조한 감정을 버리고 꾸준하게 스터디를 해야 한다. 우리가 한두 시간 내에 습득할 수 있는 지식의 양은 얼마 되지 않는다. 그래서 우리는 마치 저축을 하듯 먼 미래를 바라보고 조금씩, 우직하게 계속 스터디를 해야 한다. 하루 동안 습득하는 양은 얼마 되지 않겠지만, 이 한두 시간이 쌓이다 보면 결국 거시적인 스케일에서 많은 발전을 이루게 된다.

그렇기 때문에 스터디를 지속할 수 있는 동기를 찾는 것이 그 무엇보다 중요하다. 개인적으로 같이 공부하는 사람이 있으면 큰 도움이 되었다. 나는 회사 동료들과 종종 주말에 보여 각자 공부하고 싶은 것을 공부하는데, 열심히 공부하는 모습에 서로 자극을 받아 더 열심히 하게 된다. 또한, 내가 모든 지식을 습득해야 한다는 생각을 버리고, 지금 좋아하고 공부하고 싶은 분야에만 집중하는 것도 큰 도움이 되었다. 이를테면, 나는 클라우드 기술에는 흥미가 별로 없는 한편, 어떻게 하면 더 좋은 코드를 작성할 수 있을지, 어떻게 하면 더 유연한 어플리케이션을 만들 수 있는지에 대해서는 많은 관심이 있다. 그래서 소프트웨어 엔지니어링과 아키텍처와 관련된 공부를 할 때는 무척 집중이 잘 됐다.

자신이 좋아하는 분야를 깊게 파는 것이 좋은 이유에는 크게 두 가지가 있다고 생각한다. 첫 번째는 특정 분야를 깊게 파고들기 위해서는 다른 분야가 필요한 경우가 많기 때문에, 깊이 파고드는 과정에서 다른 분야에 흥미가 생기기 쉽다는 점이다. 나는 아키텍처와 관련한 공부를 하다 보니 자연스럽게 운영 쪽에도 관심이 생기고, 클라우드 기술 쪽에도 흥미가 생겼다. 두 번째는 어차피 내가 세상의 모든 지식을 습득할 수 없기 때문이다. 서버, 웹, 모바일 네이티브, 운영에 이르는 모든 작업을 혼자 할 수는 없다. 지식이 있더라도 시간이 부족할 것이다. 그렇기 때문에 내가 못하는 부분을 커버해서 모든 것을 평범하게 할 수 있는 것보다 내가 잘하고 좋아하는 것을 더욱 잘하는 것이 자신의 가치를 더 많이 끌어올리는 방법이라고 생각한다.

프로 의식에 대하여

로버트 마틴의 <클린 코더>를 읽으면서 나는 개발자로서 가져야 하는 프로 의식에 대해 생각해보게 되었다. 책에서 이야기하는 핵심은 자신의 발언과 행위에 대한 책임을 지는 것이다. 자신이 말한 일정이 지켜지지 않았을 때, 혹은 자신이 짜고 배포한 코드 때문에 제품에 문제가 발생했을 때 내가 손해배상을 할 각오로 임하는 책임감이 필요하다. 이렇게 책임감을 갖추면 일을 허투루 할 수 없게 되고, 커뮤니케이션을 할 때도 자신이 정확히 알거나 확신하는 정보만 전달하게 된다. 일정 산출을 할 때는 결코 무리한 일정을 뱉을 수 없게 된다. 코드를 짤 때는 혹여나 배포했을 때 문제가 되는 포인트가 없는지 몇 번이고 다시 검토하게 된다. 이런 태도는 쌓이고 쌓여 개발자 본인에 대한 팀원들의 신뢰로 돌아온다.

이 책을 읽은 후, 나는 내가 지금까지 프로 의식을 갖추지 않고 있었다는 것을 깨달았고, 이 사실이 부끄러워졌다. 기획이 추가되었을 때 개발 일정이 밀릴 것 같다는 사실에 대해 이야기하지 않아서 출시가 밀려도 “기획이 바뀌었는데 어쩔 수 없지”라는 생각을 가졌다. 코드를 짤 때도 내가 배포하지 않고, 문제가 터져도 내가 직접적으로 책임을 지지는 않으니 무의식중에 “뭐 배포해도 괜찮겠지”라는 마인드를 갖고 있었던 것 같다. 엉클 밥의 문장 하나하나는 이런 내 가벼운 책임감을 후벼파는 것이었다.

이런 책임감, 혹은 프로 의식을 키우는 데 큰 도움을 주었던 것은 내가 담당하고 있는 프로젝트가 있었다는 사실이었다. 이 프로젝트는 99% 나 혼자 개발 및 배포를 담당하고 있는데, 내가 개발하고 배포한 서비스에서 장애가 발생해서 팀원들이 꼴딱 밤을 새우는 광경을 보며 내 책임감이 부족했다는 사실을 여러 번 통감했다. 내가 정말로 돈을 받고 일하는 프로 개발자라면 이런 식으로 일을 하면 안 되는 것이었다.

몇 번이고 장애를 내고 나서, 나는 책임감을 가져야겠다고 생각했다. 내가 정말 문제가 없다고 확신한 코드만 머지한다. 배포하기 전에는 반드시 QA를 거친다. 기능과 관련하여 의사소통을 할 때는 확신 없이 이야기하지 않는다. 일정을 논의할 때는 다른 팀의 요구에 맞춰서 대답하는 것이 아니라, 내 능력으로 할 수 있는 최선과 최악이 어느 정도이고, 요구되는 일정에 맞춰 개발을 완료할 수 있는 확률이 어느 정도인지 함께 이야기한다. 내가 못 하는 일이면 못한다고 확실히 말하고, 그 일 대신 내가 해줄 수 있는 방법에 어떤 옵션이 있는지 이야기한다. 자신의 능력을 정확히 파악하고 확신을 가진 채 의사소통하며, 잘못에는 책임을 지고 같은 잘못이 반복되지 않도록 하는 습관을 들이고 있다.

앞으로 어떤 개발자가 될 것인가

2018년 회고 글에서 나는 아직 내가 어떤 개발자가 되고 싶은지 정하지 못했다고 이야기했다.

VCNC의 개발팀은 그리 크지 않지만(약 25명 규모이다), 다들 훌륭하고 배울 점이 많은 분이고, 무엇보다 다양한 성향의 개발자가 모여있다. 에반젤리스트처럼 많은 기술에 관심을 가지고 적극적으로 도입하시는 분, 문제를 가볍고 빠르게 잘 해결하시는 분, 어떠한 문제가 주어져도 어떻게든 해결해내시는 분, 다른 분들이 일을 더 잘 할 수 있도록 도움을 잘 주시는 분, 개발을 넘어서서 프로덕트에 꾸준한 관심을 두며 프로덕트가 잘 되기 위한 고민을 하시는 분 등, 좋은 개발자의 모습으로 상상할 수 있는 타입은 한 분씩 다 계시는 것 같다. VCNC에서 1년 동안 훌륭하고 다양한 성향의 동료들과 함께 일하면서, 나는 자연스럽게 내가 되고 싶은 개발자가 어떤 것인지 그릴 수 있게 되었다.

나는 하나의 백엔드 어플리케이션을 온전히 혼자서 개발 / 운영할 수 있는 능력을 갖추고, 한 프로젝트를 리딩할 수 있는 CTO가 되고 싶다. 여기에는 크게 두 가지 역량이 포함된다. 첫 번째는 어플리케이션을 개발할 때 필요한 요소가 무엇인지 정확하게 알고, 개발하며 마주치는 기술적인 문제를 해결할 수 있어야 한다. 두 번째는 서비스를 개발하고 운영하면서 마주치는, 기술과 관련된 수많은 비즈니스적 문제에 현명하게 대처할 수 있어야 한다. 덤으로, 팀원들을 매니징할 수 있는 능력과 여유가 되면 좋겠다. 3년 내로 이러한 역량을 빠르게 쌓고, “내 회사”라고 말할 수 있는 회사를 만들고, 스타트업계에서 열정적인 사람들과 교류하며 계속 즐겁게 일하고 싶다.

이를 위해 “All about building an application”이라는 거창한 이름을 붙인 문서를 하나 만들었다. 말 그대로 백엔드 어플리케이션을 만들기 위해 알아야만 하는 모든 것을 담은 문서다. 아쉽게도 이 문서를 만든 지는 꽤 오래됐으나, 올해는 단 한 줄도 적지 못했다. 내년부터는 꾸준히 작성해서 아무리 늦어도 2년 뒤에는 공개적으로 오픈할 수 있는 수준까지 만들고 싶다.

올해 아쉬웠던 점들

운영을 못 해보았다

서비스 운영에 참여하기 위해 운영에 필요한 지식, 주로 k8s를 많이 공부했었는데, 결국 운영과 관련된 업무는 한 차례도 해보지 못했다. 올해 너무 바빴던 탓이다. 내년에는 운영에 관여할 기회를 잡기 위해 더욱 노력할 것이다. 사이드 프로젝트를 해서라도 운영을 해봐야겠다.

더 좋은 VCNC 서버팀을 위해

나는 우리 팀이 인력이 부족한 것 빼고는 아주 완벽에 가까운 팀이라고 생각했다. 하지만 한두 달 전에 처음으로 팀 회고 회의를 했는데, 생각보다 불만과 문제점이 꽤 있었다. 되돌아보면 나도 불만을 조금씩 가지고 있었지만, 별로 신경을 쓰지 않은 탓에 불편한 점을 정확히 집어내지 못하고 그냥 방치하고 있었던 것 같다.

우리 서버팀이 더 좋은 팀이 될 여지가 남아있다는 사실이 즐겁다. 내년에는 팀적으로 긍정적인 영향을 어떻게 미칠 수 있을지에 대해서도 열심히 고민할 것이다.

멀티태스킹 능력

중간에 시니어 두 분이 AWS re:invent를 보러 일주일 정도 자리를 비우는 일이 있었다. 덕분에 그분들이 하셨던 리뷰, 배포, 다른 팀분들의 질문 대응 등을 남은 서버팀 인원끼리 분담했는데, 평소 하던 일에 몇 가지가 더 추가되니까 너무 정신이 없어서 도저히 업무 효율이 안 나왔다.

태생적으로 멀티태스킹 능력이 뛰어난 사람도 물론 있겠지만, 기본적으로 멀티태스킹은 얼마나 익숙해지냐의 문제라고 생각한다. 내년에는 업무 범위를 서서히 늘려가면서 멀티태스킹 능력을 키워나가야겠다는 생각이 들었다.

내가 직접 쌓아간 나쁜 코드

내가 올해 회사에서 담당한 업무는 주로 사내 인프라 개발이었다. 여러 가지 이슈와 맞물려 정말 무시무시한 속도로 정책이 바뀌었다. 심지어 이런 경우도 있었다. 운영 정책이 바뀐 게 오늘 오전이고, 그걸 내가 오늘 12시쯤 들었고, 당장 내일부터 적용해야 한다는 것이다.

이런 상황이 종종 발생하다 보니, 듀를 맞추기 위해 코드 퀄리티를 포기하면서 개발하는 적이 꽤 있었다. 여기서 가장 좋은 선택지는 듀를 미루는 것일 텐데, 당장 내일부터 적용해야 한다니 듀를 미룰 수는 없다. 결국 그나마 최선은 일단 배포하고 지속적인 리팩토링을 하는 것인데, 이마저도 시간이 부족하다는 핑계로 내팽개치고 있었다. 내년에는 주말에 코딩을 하거나 다른 업무를 줄여서라도 코드 퀄리티를 유지해야겠다.

내년을 다짐하며

2020년에 들어서면서, 한 해 동안 이루고 싶은 목표는 다음과 같다.

All about building an application 목차 완성하기 & 반 채우기
개발자 컨퍼런스에서 발표 1회 이상
블로그 방문자 수 1주일 평균 500명 이상 달성
회사 엔지니어링 블로그 글 하나 이상 작성하기
서버팀에 온콜 제도 도입 및 운영에 참여하기

올해는 0에서 1이 되는 시기였기 때문에 아주 빠르게 성장할 수 있었다. 그렇기 때문에 내년은 아마 올해와 같은 성장의 속도감은 느낄 수 없을지도 모른다. 그렇다고 내가 정체될 것이라는 말은 아니다. 나는 내가 매년 새로운 것을 깨닫고 성장해나가리라 믿어 의심치 않는다. 재미있게 읽은 책인 <팩트풀니스>의 문구를 하나 빌리면서 글을 마친다. “나쁘지만 나아진다.”

← 2019년 개발자 회고 (1) 2019.12.27. →