주니어 개발자의 2021년 회고

취업 준비

2021년은 2020년의 연장선으로 취업 준비가 이어졌다.

운이 좋게 2020년에 부스트캠프라는 좋은 부트캠프에서 개발자로서 어떻게 스스로 성장해 나가야하는지, 현재 어떤 내용들을 깊게 학습해야하는지 배울 수 있었다.

교육 이후, 부스트캠프 채널에서 열리는 채용 공고와 직접 채용 공고를 찾아가며 서류를 내고, 시험과 면접을 보며 1월과 2월을 보냈다.

수많은 고배를 마신 후, 현재 다니고 있는 회사에 인턴 모집과정에 합격하여 감사하게도 현재 개발자로 일을 하고 있다.

1년여 간의 취업 준비 기간동안 불합격이라는 경험 속에서 많은 것들을 느꼈다.

 

아쉬운 점 

• 깊게 학습했다고 믿었던 내용들, 스스로 트러블 슈팅하면서 정리해둔 개념이나 내가 사용한 기술 스택에 대해 상세히 알고 있다고 생각했었는데, 잘못된 내용으로 기억하고 있던 점
  • 실제로 면접에서 자신있게 대답한 내용들이 있었는데, 면접 이후에 다시 찾아보니 완전히 틀린 내용들이 존재했었다...
• 코딩테스트를 안일하게 준비했던 점
  • 부스트캠프 교육을 듣기 전, 반년 이상 PS에 몰두했었기 때문에 조금은 대충해도 붙을 수 있을거라는 착각을 했었다... 정말 오만한 생각이었다.
  • 시험을 보면서 조금만 더 신경써서 준비했더라면 쉽게 풀었을 텐데, 이전에 풀었던 내용인데 기억이 안나네.. 라고 생각했던 부분이 정말 많았다.
  • 다시 돌아간다 해도 이 부분은 신경쓰지 못할 것 같다.. 면접 준비까지 너무 치열하게 준비를 했던 기억이..
• 긴장을 늦추지 못한 점
  • 사실 면접자들에게 긴장을 하지 않아야한다는 말이 얼마나 힘들 말인지 잘 안다. 본인이 준비하지 못한 질문들이 나왔을 때나, 꼬리를 무는 질문들을 마주했을 때는 정신이 아득해진다는 느낌이 들었었다. 조금만 더 여유를 가지고 이를 컨트롤했다면, 면접에서 더욱 강렬한 인상을 주지 않았을까 싶다.

잘한 점

• 면접이 회사가 '나'라는 사람을 평가하는 자리지만, 나에게 맞는 회사인지도 검증하는 자리라고 생각한 점
  • 당시에 가장 중요하게 생각하던 것이 개발 문화였다. 해당 회사와 팀에서는 어떤 식으로 의사 결정을 하는지 (예를 들면, 스크럼 회의나 애자일한 의사 결정 등이 있겠다.) 가장 먼저 물어봤던 것 같다.
    더불어 테스트 코드를 작성하는지, 중요하게 생각하시는지, 스터디 활동이나 기술 공유 & 코드 리뷰는 어떻게 진행이 되는지 꼬치꼬치 물어봤었다.
    한 회사의 면접에서는 위의 체크 포인트와 반대 방향인 곳이 있었는데, 떨어짐을 직감했지만 합격해도 가지 않고싶다는 느낌이 들기도 했었다. 어떤 것이 맞고 틀리고는 아니지만 나에게 맞는 회사인지 아닌지 검증하는게 현재도 중요하다고 생각하고 있다.
• 포기하지 않은 점
  • 대학을 늦게 졸업하고 교육을 들으며 포기하고 싶었던 순간이 정말 많았다. 취준 기간이 길어질수록 무기력함과 자존감 하락으로 인해 개발자를 그만둘까 고민을 정말 많이했지만, 당시에 나를 믿어주며 힘을 주는 사람들이 있었기에 끝까지 포기하지 않았었다. 스스로도 나태해지지 않으려고 이런 생각이 들 때면 시간에 관계 없이 무작정 나가서 산책이라도 하고 왔었다. 힘이 되어주셨던 많은 분들께 아직도 감사하다.

 

인턴, 그리고 입사

1년여 기간 동안 정말 꿈에도 그리던 회사에 입사를 했다!!! 그런데 인턴..?

정말 그때로 다시 돌아가고싶지 않을 정도로 후회도 없고 열심히 준비했다고 생각하는데, 다시 한번 검증을 받아야했다.

물론 인턴 지원하기 전에는 자신이 넘쳤다.

인턴 합격만하면 당연히 나라는 사람을, 개발자로서 얼마나 성장할 수 있을지 기대되게 해줄 자신이 있었다.

하지만, 당연하게도 해당 기간 동안 떨어지면 정말 다시는 개발자 못할 것 같다는 생각의 많은 스트레스와 합격해야한다는 압박감, 인턴 사원이지만 회사에 존재감이 없는 탈소속감 등 너무 위태위태했다.

그래도 개발자라면 어떻게 해야하는지 잘 알고 있었다. 

나의 인턴 평가는 일정 기간 동안 프로젝트를 요구 사항에 따라 구현하는 것이었는데, 개발자로서 역량을 보여주면 그만이었기 때문에, 프로젝트 완성도를 높이려고 밤낮과 주말없이 달렸다.

변수 하나, 메소드 하나 선언할 때마다 정말 많은 고민을 담았고, 더 좋은 구현 방법은 없을지 고민하는 시간을 늘렸다.

코드 리뷰를 받으면서도 위의 고민 사항들에 대해 질문을 남겼고, 피드백 주신 부분에 대해 궁금하다면 질문을, 다르게 생각하면 나의 생각을 주고받으며 완성도를 높이려고 노력했다.

(사실 내가 떨어진다면 어떤게 가장 이득이될지 고민했을 때, 현직에 계신 분들에게 많은 것들을 배우자는 생각이 가장 먼저여서 위와 같이 행동했던 것 같다... ㅎㅎ)

이 방법이 정답은 아니지만 다행히 좋게 봐주셔서 정직원 전환이되어 개발자로 살아갈 수 있게 되었다.

 

개발자라는 이름으로 일을 하며 배운 것

정직원 전환과 동시에 4월 경 현재 팀에 배치되었다.

당시 팀은 새롭게 꾸려진 팀이어서 많이 어수선했던 기억이 난다.

그럼에도 팀원 분들께서 신경을 많이 써주시며 신입 교육을 위해 신입 프로젝트를 진행하게 되었다.

1주간 기획과 기술 스택 등을 정하고 구현 주에 들어가려는 순간, 다른 팀원분께서 퇴사를 하시게되어 신입 프로젝트는 스탑이되고, 현재 담당하고 있는 서비스의 부사수로 들어가게 되었다.

지금 되돌아보면 내가 가진 연혁이나 능력에 비해 감사하고 과분하지만, 당시에는 많이 혼란스러웠고 두려웠었다.

그렇게 인수인계를 받게되었고, 코드와 서비스 파악, 문서화가 되어있지 않아 문서화 작업, 취약점 보완 등에 두달간 고생한 기억이 있다. 당시 서비스가 불안정하여 퇴근 후나 주말에도 간헐적으로 출근해서 원인 파악을 하는 등 원래 개발자는 이렇게 사는걸까 궁금해했었다.

다행히 과도기를 잘 보내면서 서비스 리빌딩까지 안정적으로 마치고, 지금은 안락한 주말을 보내고 있다.

서론이 매우 길어졌는데, 신입으로 그리고 개발자로 일하면서 신선한 충격이 몇가지 있었다.

• 이론과 실전은 다르다.
  • 너무 당연한 얘기지만, 나에게는 정말 큰 충격이었다. FK 관계 설정이나 정규화 & 무조건 적인 성능 최적화보다는 가독성이 좋은 코드 등은 여태까지 내가 공부하고 경험했던 것들에 반하는 내용이었기에 당황스러웠다.
    FK 관계 매핑이나 정규화 부분은 수많은 연관 테이블이 casecade 될 때, RDBMS에서 안정적이지 못하게 처리되는 경우가 존재한다고 한다. (흔한 경우는 아니지만 제대로 casecade되지 않아 정합성이 어긋나는 경우가 생기는 경우가 더러 있다고 한다.) 로직 작성 시에도 정말 성능 최적화가 필요한 상황이 아니라면 최적화에 대한 고민보다는 가독성에 대한 고민을 하는 것이 sustaining 할 때, 서비스 관점에서 훨씬 이득이라는 것도 새로웠다. 내가 운영했던 프로젝트는 길어야 6개월이 전부였는데, 2년, 3년, 10년 등 어떤 서비스가 운영될 때 그 사이에 담당 개발자도 변경이 되고, 기술 스택이나 자잘한 라이브러리, 프레임워크 등 많은 부분이 변경되는게 실제 서비스라는 것을 배웠다. 물론 성능 최적화는 언제나 옳지만, 성능 최적화 작업 공수가 너무 길거나 영향이 미비하다면 오히려 다른 일을 하지 못하는 기회 비용이기 때문에 급하지 않다면 서비스 운영 측면에서 다른 사항들을 고민하는 것이 더욱 도움이 된다.
• 로직에 대한 정확도는 높을수록 다른 누구도 아닌 나에게 이득이다.
  • 단위 테스트, 통합 테스트, 자체적인 사용성 테스트를 거치며 develop에 merge하는 과정까지 스스로 많은 과정을 거친다. 하지만 저 테스트는 다른 누구도 아닌 내가 짠 코드에 대한 테스트다. 그럼 당연히 내가 생각하는 사고회로 안에서만 테스트를 할 수 밖에 없다. 아무리 많은 케이스를 검증하려고 해도 빈구멍은 항상 생기기 마련이다. 그럼에도 잘해야하는 이유는 develop에 머지되는 순간 시간을 되돌릴 수 없기 때문이다. develop에 올려지면 alpha & beta에서 검증이 진행되는데, 이 기간에 나는 다른 task 처리를 하고 있게된다. 다른 task를 처리하다가 이전에 구현했던 사항이 터진다고 상상해보면, 왜 다 알고 있는 내용인데 적었을지 이해될 것 같다. 멀티태스킹이 정말 힘들다.. 더군다나 관련이 없는 task를 처리하고 있다면 일은 x2가 아니라 ^2가 되어버린다... 정말로.... 그래서 리마인드 차원에서 이 글을 볼 때, 다시 상기하고자 남겨본다...
    (팀원 리뷰에서도 정확성에 대한 아쉬움을 피드백 받기도 했다..)
    이 정도면 될까 생각이 든다면? 그 생각을 접고 다시 여러 상황에 대한 고민을 하는게 더 현명할 것 같다.
• 테스트 코드는 언제나 옳다.
  • 로직이나 기획이 변경되는 상황이라면 테스트 코드도 변경되어야 한다. 이 때문에 많은 개발자들이 테스트 코드 작성을 꺼려한다. 테스트 코드 짤 공수는 안주기 때문에 내가 처리해야할 일이 두배가 되기 때문이다.
    하지만, 역설적이게도 로직이 변경되거나 기획이 변경되는 상황에서 가장 필요하고 중요한 것은 테스트 코드이다. 새롭게 기능 구현할 때야 그나마 영향이 덜하지만, 기존에 운영되고 있는 기능을 수정한다고 생각해보자.
    테스트 코드가 없다면 고려해야할 사항이 두배로 늘어난다. 개인적으로 테스트 코드는 내 코드 품질에 대한 최소한의 보증이라고 생각한다. 어떠한 상황에 대해 고려해서 처리를 했고, 기획에 따라 어떻게 처리하게 했다 라는 보증이 되기도 하고, 이 로직이 어떤 식으로 요청이 들어왔을 때 어떻게 동작할 것이다라는 쉬운 가이드가 되기도 한다. 이는 리팩토링에서 정말 큰 힘이된다. 코드 수정 범위가 넓고 로직이 변하면 정말 복잡하다. class 하나, pacakge 하나 수정은 테스트 코드가 아니더라도 처리가 가능하다. 하지만, 수정 범위가 pacakage 두개에 영향을 미친다 하더라도 수정된 코드에 대한 확신은 사라진다. 이 때, 테스트코드가 있다면 기존에 동작하던 기능이 잘 동작하는지 확인이 가능하다. 추가되는 케이스가 있다면 추가하면 그만이다. 기획 사항이나 로직이 변경되는 이유라면, 위에서 주장한 나의 관점에서는 테스트 코드는 변경되는 것이 당연하다. 처음에만 귀찮지 나중에는 내가 일을 두번하지 않아도 되니까 신나서 작성하게 될 것이다... (적어도 나는 그랬다)
    가끔 많은 분들이 TDD와 테스트 코드 작성이랑 헷갈려 하시는데, TDD 같이 개발 루틴을 바꾸는 것이 아니더라도 테스트 코드는 정말 중요하다. 
• 의견은 명확하게 전달해라.
  • 신입은 위축되어있기 마련이다. 나도 그렇고 동기도 그렇고 선배들도 그랬다. 
    내가 지닌 경험치와 선배들의 경험치는 다를 수 밖에 없다. 절대적인 시간이 부족하기 때문이다.
    그렇기 때문에 모두가 알고있다. 모르는게 당연하다는 것을.
    진짜 모르면 찾아보고 정리해서 궁금한 사항을 물어보면 된다.
    선배들도 그걸 바랄 것이다. (혼자 전전긍긍하는 것 보다 질문하고 성장해서 빠르게 1인분을 하게되는 것을 더욱 바랄 것이다.)
    다행히도 나는 위축되어있기는 했지만, 궁금한 사항은 물어보고, 명확하지 않으면 정리된 내용으로 역질문하며 스스로 명확해지려고 노력했다. 그렇기에 위에서 정확성이 아쉽다는 동료의 피드백이 적지 않았을까싶다..
  • 내가 작성한 코드에 자신감을 가져도 좋다.
    항상 옳다라고 생각하는 것이 아니라, 내가 작성한 코드기 때문에 이유가 있어야 한다는 것이다.
    그래야 내가 어떻게 생각하고 어떤 부분을 고려하여 작성했는지 명확해진다.
    이 방향성이 우리 팀이 지향하는지, 서비스를 유지하는 관점에서 도움이 될지가 명확해진다.
    만약 내가 생각한 방향이 잘못된 방향이라면 지적을 받을 것이고, 수용하고 배우면 된다.
    만약 내가 생각한 방향이 다른 방향이라면, 다른 팀원들에게 공유되어 더 좋은 방향으로 채택하면 된다.
    만약 내가 생각한 방향이 좋은 방향이라면, 다른 팀원들도 성장할 수 있는 계기가 된다.
    즉, 언제나 명확하게 이유와 근거가 있어야한다는 의미다.

 

스스로 아쉬운 점

• 욕심이 너무 많았다.
  • 욕심이 너무 많아서 이것도 하고싶고 저것도 하고싶고 이것저것 신경이 분산되었다.
    결론적으로는 이것저것 건드린 것중에 완성이된 것이 거의 없다.
    번갈아가며 몰두하다보니 성과도 없고 빠르게 지쳤다.
    추석 전후로 지치다보니 아무것도 안하게되었다.
    일이 바쁘기도 했지만, 일이 수월한 날도 분명 있었다.
    그 시간들을 모아보면 하나의 목표를 잡고 완성도를 높일 시간이 충분히 나온다.
    하지만, 생각이 많고 잡다해지다보니 시작도 하지않고 풀어지게 되었다.
    입사 초에는 늦게 시작한만큼 연차보다 좋은 퍼포먼스를 보이기 위해 노력하자고 생각했는데, 이 생각이 독이 된 것 같다.
    첫 술에 배부르려고 했던 과오였다고 생각한다.
• 업무시간에 너무 개발에만 집중했다.
  • 개발자면 개발에 집중하는게 왜 아쉽지? 라는 생각이 들 수도 있는데, 개발자는 개발만 하는 사람이 아니다.
    내가 사용한 기술 스택에 대한 정리도 필요하고, 문서화나 더욱 좋은 커뮤니케이션을 위한 노력 등 외적인 것도 정말 중요하다고 생각한다.
    일이 바쁘다는 핑계로 task 쳐내기 바쁘다는 핑계로 개발에만 몰두했는데, task가 여유롭게 들어오는 시간이 잠깐 생기면 외적인 것을 계발하거나 현재 서비스에 대한 안정성 향상 등에 고민하기보다 쉬엄쉬엄 일한 시간이 있었다.
    이런 시간도 분명 필요하지만, 너무 많으면 독이되는 것 같다는 생각이 들었다.
    다행히 이 생각이 일찍 들어서 정말 바쁜 기간이 끝난 이후부터는 조금씩 서비스 안정성을 올리기 위해 모니터링하며 버그 픽스를 진행하기도 했고, 배우고싶던 기술에 대해 검색하거나 조금 더 개선할 수 있는 기술을 리서치하거나하는 시간을 보냈다. 이런 시간들을 보내고 보니, 조금 더 일찍 이 생각을 가졌다면 좋았을텐데 라는 아쉬움까지 연결되었다.
• 적극적인 피드백이 부족했다.
  • 다른 팀원의 코드리뷰나 기술 공유 시간에 궁금한 점이나 내 생각을 자유롭게 표현하지 못했다.
    나보다 경험이 더 많으니 당현히 이런 부분까지 고려하여 진행하셨겠지? 라거나 내가 알고있는 것이 완벽하지 못하니 잘못된 내용 공유일 수 있겠지? 라는 생각이 앞섰던 것 같다.
    다른 팀원들도 실수할 수 있는 여지가 있고, 내가 알고있는 내용을 모를 수도 있다.
    만약 이게 트러블 슈팅과 관련되어있다면, 해당 팀원이 고민할 수 있는 방향을 줄여주는 좋은 길잡이가 될 수도 있다.
    신입이라는 타이틀에 너무 위축되어 자유롭게 표현하지 못했다는 생각이 든다.
    선배 개발자분들도 실수하는 경우가 당연히 존재하고, 내가 잘못알고 있는 내용이라면 이에 대한 피드백을 받을 수도 있는 좋은 기회라고 느낀다.
    '나'의 성장에 초점을 맞추기 보다, 같이 성장하는데 초점을 두면 서로에게 좋은 시너지효과가 나타난다는 것을 잠시 망각했던 것 같다.
    
    

 

스스로 만족한 점

• '나'를 찾으려는 노력을 했다.
  
  • 취업준비를 하면서 좋아하는 것, 하고싶은 것들을 뒤로하고 앞만보고 달렸었다.
    평일에는 스터디를 하는 날도, 개인적으로 리서치하는 시간도 가지며 산책을 하는 날도 많았다.
    주말에는 여행이나 그간 못했던 취미 혹은 새롭게 무언갈 배우려는 시도를 했었다.
    일과 멀어지면서 정말 내가 좋아하는게 무엇인지 조금 더 깊게 고민해봤고 나에 대해 알아가는 시간을 보내면서 잃었던 자존감을 되찾았다.
    그리고 이 시간들 덕분에 업무 시간에 더욱 몰두할 수 있지 않았을까 싶다.
    올해도 의도적으로 업무나 개발과 거리를 두는 시간을 가지며 나를 조금 더 탐구해보고 싶다.
• 현실과 타협하는 횟수가 적었다.
  • 데드라인에 맞춰 task를 쳐내다 보면 현실과 타협하자는 유혹을 정말 많이 느낀다.
    테스트 코드를 작성하지 않은 채 pr을 올려 그대로 merge를 한다던가, 어떤 원리로 동작하는지 파악하지 않은채 사용하는 코드 등 서비스 안정성이나 추후에 실수를 야기할 수 있는 유혹들이 대표적이다.
    트러블 슈팅 기록 등도 있겠지만 테스트 코드나 작동 원리를 모르는 코드가 조금 더 크리티컬하다고 생각이 들어서, 최대한 공수에 부합하여 위의 사항들을 챙기고자 노력했다.
    hotfix 사항을 제외하고는 위의 사항들이 적었기 때문에 개인적으로는 노력했다라고 칭찬해주고싶다.

 

올해 목표

• 내 서비스에서 1인분 하는 개발자가 되기
  • 어딜가든 1인분을 하는 개발자는 정말 귀하고 개인적으로는 되기 힘들다고 생각한다.
    그러니 현재 내가 투입된 서비스들에서 만큼이라도 1인분을 할 수 있도록 더욱 많은 고민과 몰입을 해보자.
• 새로운 취미 찾기
  • 1년 가까이 일하면서 취미의 중요성을 크게 느낀다.
    개발을 좋아하는 편이라고 생각하지만, 취미가 개발로 이어지는 정도까지는 아니다.
    그래서 정말 공부하고 싶은 것이 없다면, 무리해서 퇴근 후나 주말까지 이어가고 싶지 않다는 생각을 가지고 있다.
    작년에 리프레시하려고 이것저것 해보면서 긍정적인 효과를 봤는데, 뭔가 새롭게 도전하는 취미들을 가지고 싶다는 생각을 가지게 됐다. 새롭게 도전하며 조금 더 나를 알아가고싶은 마음에 새로운 취미를 가지고 싶다.
    
    
• 일에 대해 기록하기
  • '작년에 너는 어떤 일을 했어?'라고 누군가 나에게 물어본다면 이것저것 대답은 할 수 있겠지만, 확실하게 대답하기는 어렵다고 생각한다.
    8개월 동안 분명 한일이 많을텐데, 누군가 앞에서 10분을 얘기하기도 힘들다는 생각이 들어서, 이대로는 안된다는 생각이 앞섰다.
    어떤 일을 했고 어떤 것들을 경험했는지 기록하는 것만으로도 더 큰 성장을 할 수 있다는 것을 이미 부스트캠프 교육을 통해 느꼈기때문에, 올해는 나의 업무 발자취를 남겨보도록 하자.