2023년 백엔드 개발자 회고

경험에 의한 주관적인 내용입니다.

 

비전공자로 부트캠프를 수료하고 백엔드 개발자로 스타트업을 다닌 지 1년 반이 지났습니다. 백엔드에 모든 것을 혼자 담당했었는데, 그동안 무엇을 했고 아쉬운 점이 무엇이었는지 생각하려면 생각나지 않습니다. 그래서 그러한 점을 상기시키고, 발전을 위해 쓰게 되었습니다. 부트캠프를 수료하고 적은 글이 생각보다 많은 사람들이 보고 공감도 많이 눌러 주셨는데, 많은 도움이 되었다 생각되어 용기를 얻은 부분도 있습니다. 저 또한 다른 사람들의 회고나 경험을 적은 글들을 보면 짧은 시간에 간접적인 경험을 하게 되어 도움도 되었고 재미있었습니다. 제가 적은 글도 그렇게 되었으면 좋겠습니다.

 

 

부족했던 점

 

먼저, 아쉬워서 개선하고 싶은 내용이 가장 중요하다고 생각되어 먼저 나열해 보겠습니다.

 

 

1. 블로그를 계속해서 쓰지 않은 점

  블로그를 회사 다니면서 한동안 쓰지 않았습니다. 너무 블로그 글을 잘 쓴사람들이 제 눈에 점점 많이 보이기 시작했고, 잘못된 정보를 전달하는 불안감, 그리고 chatGPT의 존재 때문에 무의미하다고 생각했습니다. 하지만 지금 시점에서는 잘못된 생각이라는 것을 느꼈습니다. 개발을 하면서 얻은 경험을 생각하고 정리해보는 경험, 잘하시는 분들이 먄약에 보게 된다면 피드백을 받을 수 있는 기회를 버렸다고 생각이 들었습니다. 또 제가 어떻게 개발을 했는지, 어떤 사람인지를 알릴 수 있는 좋은 수단 중 하나라고 생각하는데 활용하지 못하여 많은 아쉬움이 남았습니다. 그래서 앞으로는 미뤘던 내용이나 글을 계속해서 쓰려고 합니다. 

 

 

덧붙여서, 할 일을 미루는 사람의 심리 영상을 우연히 보았습니다. 지금 내가 미루어 왔던 것에 생각을 해 볼 수 있는 영상이었습니다. 영상을 보면서 중요하다고 생각된 것은, 마감이 없는 일은 쉽게 미룰 수 있다는 점이고 미루지 않는 사람은 잘 관리 한다는 점이라 생각 되었습니다.

 

 

2.  프로젝트(토이, 사이드)를 하지 않고 회사 코드에 매몰 된 점

  최근에는 적용해보고 싶은 기술이 있어 작게 시작한 개인 토이 프로젝트와, 멘토겸 친구와 하게 된 프로젝트가 있습니다. 아직 많이 진행이 미비하지만, 개인적으로 프로젝트를 시작해보지 않았던 것에 후회가 되었습니다. 이유는 프로젝트를 통해 다른 기능을 처음 구현해보면서 생각만 해보는 것과 직접 구현해보는 것이 많은 차이가 있고, 내가 잘못 알고있는 것을 새롭게 다시 알 수 있는 기회 였습니다.

  회사코드에 제가 해보고 싶은 것을 시도하고, 적용하기는 어렵습니다. 그리고 내가 하고 싶은것 보다 회사 상황과 방향에 맞게 개발해야 하는 부분도 있기 때문입니다.(물론 기회가 된다면 회사 서비스에서 새로운 시도를 했습니다.)  그 예시로 제가 도메인 패턴에 대해 관심이 있고 경험해 보고 싶은데, 회사 코드에 무작정 적용해버린다면 아주 힘들 것이라 생각합니다. 그래서 토이 프로젝트에 적용해보았고 궁금증을 많이 해소 할 수 있었습니다. 그렇기에 아주 화려하고 멋지게 하지 않더라도 조금씩 제가 해보고 싶은 것들을 적용하고 궁금증을 해소하는 좋은 기회라고 생각합니다. 그래서 꼭 배포를 하고 상용화 하지 않더라도 개발에 흥미를 잃지 않는 원동력이 될 것 같습니다.

 

 

혼자 판단하고 결정하여 진행해 보았던 것들

 

  입사 전에 서비스되고 있는 코드를 보게 되었습니다. 당시 회사에서는 2년차 경력직을 구했었고, 백엔드를 혼자서 개선 및 확장 해야했습니다. 그렇기에 성장하고 해 볼 수 있는 것이 많다고 생각했습니다. 그리고 앞으로 해야할 것이 무궁무진해 보였던 것이 기대가 되었고 재밌어 보였습니다.

  그래서 회사에서 사수 없이 백엔드 개발을 시작 하였습니다. 어려운 점도 많았고, 좋은 점도 있었다고 생각합니다. 지금도 사수 없는것에 대한 불안감은 지울 수 없지만, '절대적으로 사수가 있다고해서 나를 잘 가르쳐주거나 실력이 있는 것이 아니다' 라는 생각으로 불안감을 많이 지웠습니다.
  블로그, 커뮤니티 글을 보면 사수가 무조건 있는곳으로 가는게 좋다고 합니다. 저도 동의하는 내용이지만, 사수가 없음으로서 혼자 스스로 생각하는 시간이 많고 결정하는 것이 정말 많았고 개발에 흥미를 잃지 않았다고 생각합니다. 처음에는 괴롭고 누가 정해주었으면 좋겠다는 마음이 있었지만, 작은 결정이거나 틀린 결정이라도 혼자 결정을 하고 판단 했기 때문에 문제를 고민해보고 생각하는 시간이 정말 많아서 좋았습니다. 

 

1. nestjs

 코드를 처음 보았을때 node, express에 자바스크립트로 되어 있었습니다. 그 당시 타입스크립트의 중요성을 알게 되었기 때문에, 개선하고자 하는 마음이 들떠있었습니다. 하지만 코드를 인수인계 받고 처음 느낀것은 사람 스타일 마다 코드가 너무 다르구나 라는 것을 느꼈습니다. 자유로운 것이 장점이자, 단점이라는 말을 이해하였습니다. 그렇기에 문제점을 인지하고 nestjs를 선택하여 서버를 바꾸겠다고 마음을 먹었고, 적용하게 된 이유는 크게 4가지 입니다.

1. 아키텍쳐가 일정 부분 정해져 있어 자유로운 node.js 보다 이해하기 쉽다.

2. java와 비슷하기에 java를 하시는 분이 오시더라도 nest를 접하고 이해하는데 쉽다고 판단.
(우리나라에 자바개발자가 많기 때문에 node를 모르시는 분이 오시더라도 빨리 적응 할 수 있다고 생각했습니다.)

3. 점점 회사에서 많이 쓰는 추세를 확인.

4. TypeScript 적용의 필요성

 

  4가지 이유로 nest로 바꿔나가기 시작했습니다. 물론 nest를 공부하고 적용한 것이 아니라 nest를 공부하면서 적용하게 되었습니다. 그러다 보니 완료하는 데까지 (데이터베이스 포함) 약 3개월이라는 시간이 걸렸습니다. 그 과정에서는 제가 선택하고 해보고 싶었기에 원동력이 가장 컸었고 그렇기에 오전 6~7시에 출근해서 오후 10~11시 퇴근하고 주말에도 나오는 등 즐겁게 하였습니다.

3개월 동안의 삶..

 

  변경하고 나서 제일 좋았던 점은, 하나의 로직 때문에 다른 로직에 영향을 주는 레거시를 개선하였고, 현재 특정 문제가 생기더라도 규칙적인 디렉토리(아키텍쳐) 덕분에 쉽게 문제점을 파악하고 개선할 수 있었습니다. 그래서 일의 작업도가 2배는 빨라졌다고 확신 할 수 있습니다. 이러한 경험을 하고 나니 아키텍쳐의 중요성을 많이 느끼게 되었습니다. 또한 nest에서 많은 기능을 지원하기에 개발도 효율적으로 할 수 있었습니다.
먄약 node.js를 계속 쓰고 유지 보수만 생각하였다면, 레거시에 고통받고 개발에 흥미를 잃어 우물 안 개구리가 되었을 것이라 생각합니다.

 

 

2.  데이터베이스 변경 (스키마 변경)

  nest로 변경하는 과정에서 기존에 사용하고 있는 데이터베이스가 이상하다고 느꼈습니다. 두 가지의 예시를 들자면,
첫 번째로 하나의 결과 데이터를 조회한다고 가정했을 때. A라는 테이블에서 5개의 데이터를 합쳐야 하고, A의 관계형인 자식 테이블인 B에서도 A에서 5개를 합친 데이터에 관계되는 데이터를 찾아야 했습니다.
두 번째는 결과가 도출된 데이터에 대한 원본 값을 저장하는 것이 아닌 원본에서 변화된 값을 저장하고 있었습니다. 예를 들어 지금은 A를 10으로 보여주자라고 약속을 해서 10으로 저장을 하였지만, 11로 바꿔 보여주어야 한다면 무수한 10의 값들은 11로 바꿔야 하는 문제점이었습니다.

  첫 번째는 하나의 결과에 대해서 하나의 테이블과 행에 데이터를 저장할 수 있게 변경하고, 두 번째는 원본을 저장할 수 있게 데이터베이스 구조를 변경하였습니다. 데이터를 계속 쌓아가면서 효율적으로 성능적으로 정말 잘 바꾸었다는 것을 체감하였고, 그 외에도 모든 것에 의심과 의문을 가졌고 문제점이라 생각되는 것을 파악하여 개선을 하였습니다. 이러한 과정과 맞물려 nest로 적용하는데 3개월의 시간이 걸렸습니다. 만약 기존 데이터베이스를 사용했다면 기획이나 요구사항에 대처하기 어려운 상황을 분명 맞이했을 것이라 생각합니다.

  지금은 이 변경한 과정이 크지 않아 짧게 서술하였지만, 오랜시간동안 며칠을 고민하고 생각하였고 시간도 굉장히 많이 들었습니다. 그리고 서비스하고자 하는 방향에 대해서도 정말 많이 질문하였고, 기획에 관하여 참여하고 의견을 냈습니다. 그러면서 방향에 맞춰 데이터베이스 스키마 변경을 하며 많은 경험을 하게 되었습니다.

 

 

3.  변화를 시도한 점

  제가 놓인 상황에서, 누가 피드백 해주거나 개발에 대해 지적해주는 사람은 없습니다. 위에서 이야기한 1번, 2번을 하지 않았어도 그 누구도 저에게 문제라고 이야기 할 사람은 없습니다. 스스로 문제점을 파악하고 개선해 나가는 것은 생각보다 어렵고, 혼자하다보면 서비스 되고 있는것에 당장 문제 될 것이 없으면 쉽게 게을러질 수 밖에 없습니다. 거창하게 무엇을 바꾸고 개선한 것은 아니지만 기획에도 참여하고, 문제점을 계속 찾아서 변경하고 변화하려 했습니다.  갖추어지지 않은 문서화, 테스트 코드, 모니터링, 인프라, 서버 요금관리, 자동화 배포, 더 나아가서 기획 참여 등등. 필요한 것은 갖추고, 개선점을 생각하며 더 나은 방향으로 나아가려고 했던 것 같습니다.

 

아직까지 부족한 것이 많지만 변화를 시도하였기 때문에, 직접 문제를 부딪히고 해결하려고 할 때, 재미있고 많은 것을 얻을 수 있는 사람이라는 것도 알게 되었습니다. 제가 결정하고 시도하였던 것들이 정말 사소하거나 별일 아닐 수 있습니다. 하지만 바탕이 되어 자연스럽게 많은 것을 경험하고 개발을 계속하는 원동력이 되었다고 생각이 듭니다.

 

 

마무리 하며  

wonny님의 이력서 일부

 

https://wonny.oopy.io/ 이력서 가이드로 많이 알려지신 Wonny님의 이력서입니다. 개발자를 하기 전 처음 보았을때 위 이미지 부분에서 어떻게 이걸 다 할 수 있지? 나도 저렇게 해야지라는 막연한 생각을 했었는데, 어느 정도 모든 백엔드 분야에선 실현되었기 때문에 정말 시간을 많이 느꼈음을 깨닳았습니다.

 

 

   

 

 

글을 작성하면서, 다른 목표를 정하게 되었습니다. 좋은 문화가 있는 팀에서 다른 동료와 일해보고 싶은 목표를 잡게 만든 영상이 있습니다. 저는 슈카 유튜브를 즐겨보는데 이 영상이 계기가 되었습니다.

 

 

 

  저도 롤이라는 게임을 하면서 느끼는 바가 참 많았습니다. 서로 모르는 사람들끼리 팀을 이룹니다. 보통 상대팀이 아무리 못하더라도 팀에서 내분이 일어나거나, 의견이 맞지 않거나, 욕하고 헐뜯게 되는 경기가 생깁니다. 그러면 이기는 경기도, 승리에 한 걸음 남은 경기도 지게 되어있습니다. 반면에 힘든 상황에 놓여있어도 피드백을 수용하고, 상대방의 기분을 생각하며, 즐겁게 게임을 하는 팀워크가 있다면 대부분 게임을 이겼던 기억이 있습니다. 설령 지더라도 기분이 오히려 좋은 경험을 가졌습니다.

 

  흔히 스포츠에서 팀워크라는 것이 굉장히 중요합니다. 약팀이 강팀을 잡을 때, 크게 발휘 되는 항목이고, 반대로 강팀이 무너질때 흔히 팀워크가 부족해서 무너지는 것을 종종 볼 수 있습니다.

  개발자도 마찬가지라 생각합니다. 실력도 어느정도 중요하다고 생각하지만, 조직에서의 팀워크에 녹아드는지가 더 중요하다고 생각합니다. 팀워크? 그냥 잘 맞추면 되는거 아니야 라고 쉽게 생각 할 수도 있습니다. 하지만 아주 어려운 부분중 하나라고 생각합니다. 인성을 떠나서 각자 아주 쉽게 이해관계가 다르게 되기도 하고, 목표하는바가 다르게 된다고 생각합니다. 그 순간이 갈등의 도화선에 불을 붙였다고 생각합니다.

 

  팀워크가 있는 팀이 결국 승리를 할 줄 아는 팀일 확률이 높고, 승리하는 방법을 알기 때문에 능동적으로 일을 하게 되고, 승리하는 팀에는 좋은 동료가 옆에 있기 때문에 그만큼 배우고 성장할 것이 많다고 생각합니다. 결국 개발자는 팀 단위로 움직일 수 밖에 없고 팀워크가 중요하다고 생각합니다. 그래서 이러한 팀에 가도록 노력하려고 합니다.