지난 1년간 회사생활을 하며 제가 겪었던 (거의) 모든 일들을 요약하여 회고합니다.
처음 입사를 하고 회사에서 개발중인 에이전트와 백엔드 시스템에 대한 큰 그림을 전달받았습니다. 특히 백엔드 시스템은 크게 어떤 방식으로 관리되며, 필요한 지시사항과 향후 발전과정에 대한 이야기를 들었습니다. 이 때부터 였을까요, 저의 단점이 드러나기 시작했습니다.
회사에 처음 왔으니 회사에서 사용하는 기술과 처음보는 소스코드 등 모르는 것들이 많았고, 백엔드 시스템이 어떻게 구성되는지를 먼저 파악하기 위해 기술문서들을 계속 읽었습니다. 그러면 자연스럽게 모르는 것이 많이 생기고, 질문하지 않으면 오랜 시간이 걸릴 작업일게 뻔한 것들이 많이 생깁니다. 하지만 질문 없이 스스로 풀려고 했던 실수를 했었지요.
이를 위해 저는 아래의 것들을 생각하게 되었습니다:
위의 것이 “생산성을 내는 기본기” 로 마음가짐을 두게 되었습니다.
모르는 것을 정제하지 않고 물어보면 팀원 및 팀장의 귀중한 시간을 뺏는 셈이 됩니다. 하지만, 그것을 두려워하여 필요한 질문을 하지 않는 것 또한 분명 나중의 귀중한 시간을 뺏는 행동입니다. 아울러 질문에 대해 원하는 대답을 주지 않는 것도 마찬가지입니다. 답변을 줄 때도 심사숙고할 필요가 있지요.
1년이면 많은 일이 일어날 수 있지요. 제겐 프로그래머라는 직업을 달고 처음 일하는 때였기 때문에 누구보다 많이 긴장했었던 기억이 다시 떠오릅니다.
그 때는 자사 백엔드가 어떻게 구성되어있고, 앞으로 어떻게 구상해야 할 지를 구상하던 시기였습니다. 기존에 있던 기능을 Django로 이전하거나, KSQL(현재는 ksqlDB이죠) 이나 Schema Registry 에 대해 공부하고 세미나를 했던 기억이 납니다. 객관화할 수 있는 데이터나 근거가 있다면 신기술 도입에 망설임이 없었던 덕분이었습니다. 그렇기 때문에, 기술의 선택폭에 대해선 괜찮다 싶으면 바로 도입할 수 있었습니다.
아래에서, 크게 떠오르는 몇몇 케이스를 작성해보고자 합니다.
- “좋아보인다”로 짐작하지 말고, 좋은 코드를 먼저 이해하자 (ft. 테스트코드)
1년차 기간동안에는, Flask로 된 API 서비스를 Django 로 고치는 작업을 진행했습니다. 기존에 있던 기능을 하나씩 캐치하고, 이를 고치기는 작업을 진행했었고, 그 때 처음 TDD 를 알게되었습니다. 이건 좋아보인다! 하는 마음에 테스트코드를 비즈니스 로직에 끼워맞추는(!) 짓을 했었고, 그 시기 코드리뷰 시절에 크게 혼났던 기억이 나네요. 내가 검증해야할 로직이 뭔지 파악하고, 이를 테스트케이스를 짜서 로직을 방어하는 코드를 만들었어야 했는데 말이죠. 이 링크 를 봤음에도 전혀 엉뚱한 코드가 나왔던 기억이 납니다.
- 디테일에 신경을 쓰자.
단순 CRUD 는 누구나 만들 수 있습니다. 그러나 이런 아티클을 보며, 하나하나 살펴보며 좀 더 좋게 만들어야 하지 않나 하고 생각하게 되었습니다. 누구나 할 수 있는 것에선, 디테일을 더 따져야죠.
- 어떤 원칙이 맞는거야?
때로는 API를 오픈하며, GET을 쓸지, POST를 쓸지 하는 고민을 할 때도 있었습니다. 때에 따라 다른 법이지요. 이 글을 읽고 그 생각을 잡고, Elasticsearch의 API 호출을 보고 생각을 굳혔습니다. 회사에서 제공할 서비스의 설계방향에 맞게 바꾸는게 중요하겠죠.
- 여긴 어디고 나는 누구지?
핵심을 파악하는 것은 중요합니다. 하고자 하는 일에 대한 원인 파악과 근거를 알면 실수가 크게 줄어들기 때문이지요. 이를 이해하지 않고서 일에 뛰어들면 잘못 이해하거나 하지 않아도 될 고려를 할 수도 있습니다. 제게도 그런 생각을 할 수 있게 많이 도와주셨습니다. 어떤 비즈니스 로직을 작성하기 위한 방향성을 인지하고, 이를 위해 어떤 일을 해야할지를 파악하고 그를 위한 배경지식 쌓기 및 관련 내용을 찾아보기 시작했던 기억이 납니다.
감사하게도, 아래 책들을 추천받아서 읽게 되었습니다.
프로그래머의 삶을 살기 위해 어떤 식의 삶의 태도를 가지는게 좋을까? 하는 마음가짐을 잡게 해준 책이었습니다. 처음 봤을 때는 이해 안되고 넘어간 것들도 많았는데, 되돌아보니 이해되는 부분들도 있더라구요.
정말 좋은책인데, 아직은 많이 어려운 것 같습니다. 주로 기억나는 부분은 이정도네요.
이 책은 다시 읽어봐야겠습니다.
일을 어떻게 처리할 것인가? 에 대한 주요 방향성을 알 수 있었습니다. 정신없이 치고오는 일에 대해, 빠르게 쳐낼지/플랜을 세울지/타인에게 부탁할지/미룰지 를 판단하게 두어서, 빠르게 쳐내도록 하는 방법론이지요. 제게는 개인적으로 상당히 도움이 되어서, 제 습관으로 체득화하기 위해 노력중입니다.
이 책입니다. 온라인으로 나온 책이고, Java였어서, 개념을 잡는데 보다 더 큰 주안점을 두고 읽었던 기억이 납니다. 제가 먼저 읽고, 나중에 동료분들이나 혹은 아는 동생들에게 가르쳐주고 싶네요.
적어도, 어제보다 나아지기 위해 생각은 하고있습니다. 한 발짝 걸었다 하고 생각되던 날은 좀 드물었던 것 같아 아쉽습니다.
참 많은 용어들을 접하고, 메모하고, 다시 읽으며 역량을 키우려고 부던히 애썼습니다. 지식을 일단 쌓아야 지혜가 생길테니까요.
그런 의미로, 야생학습 이란 말에 상당부분 동의합니다. 몸이 배워서, 효율적인 행동으로 체화되고 이를 써먹는다고나 할까요.
한마디로, 지난 1년은 엄청(!) 깨졌습니다. 같이 일할 준비가 안되었다 라고 하면 좋을까요. 저는 실수와 실패로부터 배웠습니다. 그 때의 저는 두려워하고 소통하지 않았습니다. 하지만 나아지기 위해 좌절하지 않고 나아갔습니다. 그땐 그랬습니다.
사실 개발자로써 이렇게 하면 좋을 것이다 하는 글은 정말 많습니다. 누구나 성공을 뽐내고 싶어하며 실패를 말하기를 두려워합니다. 저의 1년간의 경험이 여러분들에게 좋은 반면교사가 되었으면 하는 바람입니다.
이건 뭐 회고가 아니라 고해성사가 되어버렸군요. 재밌는 인생입니다.
읽어주셔서 감사합니다.