입사 2주차 스타트업 신입 백엔드 개발자의 업무에 관한 고민과 성장 목표

분명 나는 신입으로 들어왔는데 회사의 코드들을 보고 매일 놀라고 있다. 도대체 이 상태로 어떻게 서비스를 배포할 수가 있지? 너무 양심없는거 아닌가...? 나도 신입이고 내 코드도 별볼일 없겠지만서도 적어도 이렇게는 하면 안될 것 같은데 하는 불길함이 있었다. 

 

  내가 기존 서비스 오류 수정, 리팩토링하면서 느낀 것은... 지금 있는 곳은 백엔드는 나 혼자고 프론트가 6명 가량 있는데, 애초에 신입을 뽑는 것 부터 급한 불 끄자는 거겠지만, 이사님께서 그닥 서버개발에 대해서 중요하다고 생각하지 않으시는 것 같다고 느꼈다. 그저 굴러가기만 하면 된다고 생각하시는 것 같다..... 나름 시키지도 않았는데 조회하는 로직 개선할 수 있을 것 같다고 말씀드렸더니 그러라고 하셨지만.... ㅋㅋㅋㅋ 그냥 알아서 하라는듯....ㅋㅋ sql문 로직 수정해서 최소 3초는 걸리던거 아예 딜레이 없게 수정했는데 차이를 잘 모르시는 것 같다. 

 

  그래서 이후에 더 성장한 내가 보기엔 아쉽겠지만 그래도 막연하게나마 어떻게 코드를 작성해야 할지 고민해보려 한다. 그리고 내가 갈 회사를 내가 고른다고 가는 것은 아니지만 어떤 회사에 가고 싶은지도.. 

 

 

  아마 쓰면서 가장 고민하는 부분은 당연한 것 아닌가? 라는 부분일 것이지만, 그럼에도 내가 이 진절머리나는 코드들을 계속 보고 있자니 당연한게 당연한게 아닌 것 같다. 

먼저 떠오르는 것은, 아무리 나 혼자 서버 코드를 개발한다고 한들, 협업하는 것처럼 여기고, 정리를 잘 해야한다.  

아니...무엇보다 책임감이 강해야 한다. 

그러기 위해서 정리해보면 내가 새롭게 서비스를 구축할 때 무엇을 중요시해야 할까?

1. 문서화 / 시각화

  현재 이 회사에서는 노션 / 잔디 에서 개발자들이 소통하고 있다. 잔디는 토스에서 개발한 협업툴인데, 잔렉이 있어서 아직은 그렇게 좋은지는 모르겠다. 일단 문서화 / 시각화를 먼저 언급한 이유는, 노션에 API명세서가 있는데 내가 수정하면서 보니까 API명세서와 다른 부분들이 많았고, 설명이 없었다. 아무래도 서버개발을 전임자가 혼자 해서 그런지, 소스코드를 봐야만 이해할 수 있었다. 

 

<문서화>

*API명세서

  지금 상태에서는 프론트는 메서드, url, 입력값 방식, 형태만 확인하고 있다. 뭐 더 할게 있나? 싶긴 하지만,

적어도 예시와 클라이언트에서 발생할 수 있는 에러처리한 부분에 대해서는 같이 명시해주면 좋을 것 같다. 

 

  처음 입사하고 로그인 빼고는 뭐든 다 에러처리없이 db에 저장을 해버리니.. 내가 들어와서 에러처리를 하기 시작한 이후로 프론트측에서 수많은 '안돼요.' 를 들었다. 아마 기존에는 입력하면 다 됐는데, 지금은 뭔가 제약이 많으니까 나한테 속으로 불만을 제기할 수도 있겠지만... 그렇다고 DB에 무분별하게 넣으면 어떤 기준으로 찾고,,, 그만 알아보도록 하자...ㅋㅋㅋ 

 

  뭐가 어떻게 안되는지 전혀 말 안해주고 그저 안돼요 해버리니까 솔직히 답답한 마음도 있었지만, 이건 일류의 자세가 아니다. 어쩌면 왜 안되는지 모르는건 서로의 아쉬움이다. 내가 아무리 신입이라지만 이건 알겠다.

정말 소통을 잘해야 한다. 그러려면, 클라이언트단 에러 자체에 예외처리나 DB관련된 에러 제외하고는 에러메세지를 잘 전달해주는게 우선이겠지만,

 

>>>>>> 적어도 어떻게 입력해야 하고 어떻게 입력하면 오류가 날지 어느정도 써주면 서로 작업시간이 단축될 것 같다. 

(스웨거 쓰면 조금 더 간단하게 문제를 해결할 수 있겠지만... 좀 더 일해보고 건의해봐야겠다. )

 

<시각화>

*Entity Relationship Diagram

  ERD라고 하는 이 것을 꼭 꼭 잘 작성하고(이 부분은 아래에서 다루겠지만, DB설계가 애초에 중요한 부분..), 개발 초기단계에서 ERD에 대해서 같이 이야기를 잘 나눠야겠다. 솔직히 지금 프론트들 입장에서는 ERD뭔지도 잘 모르고 귀찮아 할 수 있을 것 같은데, 사수중에 연차가 많이 쌓인 시니어가 없다보니 내가 짜여진 코드 보고 욕하는 것처럼 내 코드도 완벽한 코드는 아니니까 코드리뷰느낌으로.. 엔티티를 이렇게 정의했고, 이렇게 저장될텐데 괜찮은지 논의가 필요하다고 생각한다. 

 

  지금은 RDBMS (Mysql)을 사용하고 있는데도 불구하고 예를 들어 질문에 대한 대답을 저장하는데.. choose라는 컬럼에 어떻게 입력했는지를 객체로 다 넣어주고 있다... 어차피 객관식에 기타 정도만 문자열로 저장될텐데, 질문과 대답들을 전부 choose 컬럼에 넣고 있다. 아마 질문마다 문항수도 다르고 어떻게 저장해야할지 애매했을 것 같다. 

  이럴거면 그냥 NoSQL 쓰면 안됐나..? 

 

  나도 신입이고 나도 엄청 부족한 개발자라 당장 어떤 방식이 최대로 효율을 내는 방식일지 떠오르지는 않는다. 그렇다고 문자열을 다 넣는건.... 당장 떠오르는 것은 문제를 별도로 저장을 하든, 프론트에서 하드코딩을 하든 하고 유저의 대답에는 question_id를 매핑해서 대답을 저장하고, 기타일 때만 detail이라는 컬럼을 nullable하게 두면 어떨까 하긴 한다. 

 

  아무튼, 모를 수 있다. 그러니까 어떻게 DB에 저장하는 것이 효율적일지 같이 고민해보자는 것이다. 이건 그냥 가치관적인 부분이겠지만, 내가 정답이라고 여기기보다 정말 협업을 해야한다고 생각한다. 왜냐하면 어떻게 저장할지는 서버 비용 대는 회사측이면 모를까 프론트 입장에서 알 빠 아닐 수 있지만, DTO쪽은 서로 편하고 적은 리소스를 소모하게끔 소통하는 부분은 중요하니까 말이다. 

 

2. 통일성

  특별히 소스코드로 봐야만 알 수 있는 ... 이 기능에 대한 정의 없는 코드들은 변수명마저 다 제멋대로였다. 아니 그 전에 네이밍컨벤션부터 카멜케이스와 스네이크케이스가 혼용되어 있었다. 내가 국비지원받을 때 첫 프로젝트에서도 이렇게는 안했는데.. 물론 DB에서 스네이크케이스를 쓰고 그 DB의 값에 대한 변수를 그대로 스네이크케이스로 쓰는 것 같긴 한데, 또 아닌 부분도 있어서 혼란스럽다.. 사실 ORM을 잘 쓰고 있으면 애초에 엔티티를 제외하고 스네이크케이스가 보일 수가 없는데, 다른 문제긴 하다. 아무튼 네이밍컨벤션 통일이 필요하다. 

 

  그리고 api명세서나 별도의 기능정의가 안되어있더라도, 어떤 기능을 하는지라도 명확하면 바로 디버깅할텐데,,,,

어디는 진단이 diagnosis고 어디는 dx고,, 라우팅은 인덱스에 다 모아놓은 줄 알았는데 또 어떤건 진입단에서 바로 라우팅하고.. 

 

정리하자면, 누구든 이해할 수 있는 코드를 작성해야겠다. 

 

3. 전달하는 값

  이 부분은 나도 어떻게 하면 좋을지 명확치 않다. 기존 코드에서 검색결과가 없는데 어떤 api는 빈 배열, 또 어떤 api는 null을 주고 통일되어있지 않았다. 통일이고 뭐고를 떠나서 그 의도가 명확치가 않았다. 내가 고민하던 부분을 너무나도 명확하게 정리되어있는 포스트가 있어서... 두고두고 참고하려 한다.  역시 토스...! 

https://toss.tech/article/engineering-note-2

null 리턴은 왜 나쁠까?

 

 

  이 외에도 Node.js의 자유분방함때문이겠지만, 도무지 이해할 수 없는 구조와 레거시들이 날 미치게하지만, 아마 다른 곳에 가도 부지기수일 것이라 생각하며 여기서 단단해지려 한다. 그래서 내가 앞으로 어떤 회사에 가야 성장할 수 있을지를 고민하고 있다. 지금 고민하는 옵션들이 그 회사의 장점이라거나 내가 갈 수 있는 것은 아니지만, 적어도 내 상황에서 가장 내가 성장할 수 있는 곳이 아닐까..?

 

코드리뷰 문화가 원활한 회사

  코드리뷰를 하는 것이 무조건 강제적으로 필요한 것이라고 생각하지는 않는다. 하지만 나에겐 절실하게 필요하다. 여기서는 나에게 아무도 코드에 대해 지적해주지 않기 때문에 과연 잘하고 있는게 맞나 의심도 하고 있지만.. 다른 곳을 가게 된다면 사수에게 혼도 나면서 배우지 않을까 싶다. 하지만 그저 수직적으로 이렇게 해야 한다. 이거보다는 어떻게 효율적으로 코드를 짤 수 있을지 팀 안에서 고민하는 문화가 있는 회사가 있다면.. 페이와 상관없이 가고싶다. 

 

기능구현에 급급하지 않은 회사

  어쩌면 코드리뷰 얘기와도 비슷하겠지만, 애초에 코드를 리뷰한다는 것 자체가 기한 내에 빨리 api 쳐내기 급급하지 않은 곳이라는 것이다. 물론 여기는 급하지도 않지만.....ㅋㅋㅋㅋ 분명 내가 빠른게 아닌거같은데.. 프론트 5명에 나 혼자 백인데도 뭔가 여유가 있어서 돈받는게 미안해서.. 응답속도 개선에 최선을 다하고 있다.

  내가 기능구현에 급급하지 않은 회사라고 언급한 것은, 여유로운 분위기를 원하는 것은 아닌데..ㅋㅋ 모순일 수 있지만 서비스의 구축시간이 아니라 서비스의 완성도에 초점을 두고 조금은 더디더라도 확실하게 하는 곳으로 가고싶다. 

 

 

코멘트

  어쨌든 회사가 나를 서류 검토든 면접이든 보고 고르기 전에, 내가 먼저 회사를 고르지 않나. 채용공고를 보면 어느정도는 회사의 지향점이 보이니 말이다. 또 JD를 맞춰 내가 준비하는 것도 크겠지만, 내가 이 회사에 적합한 사람인지를 잘 어필하는 것이 중요한 것 같다.

 

  신입에 비전공자인데 얼마나 하는지 판가름 나는 것은 이력서와 포트폴리오인 것은 맞지만, 거창하고 화려하게 해도 문제인 것 같다. 우연치 않게 전임자의 깃헙 프로필을 봤는데, 정말 뭔가 화려한데 막상 지금 이 코드들을 보면 한숨만 나오듯.. 내실이 중요한데 제대로 된 인원을 뽑으려는 회사에서는 그 내실을 확실하게 확인해야 하기 때문에 내가 함께 일할만한 사람이라는 것을 어필해야 한다고 생각한다. 

 

  그래서 구구절절 이렇게 자주 포스팅하는 것은..ㅋㅋ 진짜 한 사람 뽑는 것에 진심이라면 이런 자잘한 글도 보겠지 싶어서 끄적인다. 함께 일할만한 사람이라는 것을 어필하려면 포트폴리오에 넣는 내용들이 부풀리기 식이 아닌 진짜 진또배기가 되어야 하기에 여러 프로젝트도 해보고 내 것으로 만들어야겠지만, 그 프로젝트가 괜찮은 프로젝트여야 좋은 물을 경험해야 한다고 생각해서, 오픈소스에 기여한다던지 하는 그런 노력들을 해보려 한다.