원티드 프리온보딩 인턴십 회고

지난 8월 중순부터 한 달간 원티드 프리온보딩 백엔드 인턴십 과정을 수료했다. 5월 부트캠프 수료 후 진로 고민과 여러 일들로 2개월 간 코딩을 잠시 하지 않고 있다가, 다시 해보려는 참에 동기를 통해 알게되어 지원했고, 운 좋게 붙었다.
모든 과정이 갈무리되고 카페에 모여 회고를 진행했는데, 그때 작성한 걸 조금 수정하여 포스팅한다!

프로젝트 회고

사전 과제

2024.08.04 ~ 2024.08.07
🔗 GitHub

• Swagger를 직접 적용하는 건 처음이었는데, 네스트에선 플러그인 설정을 통해 쉽게 문서화 할 수 있어 편하고 좋았다. nest-cli.json 파일에 이런 식으로 플러그인을 적용해주면 DTO 파일에 붙은 class-validator 데코레이터를 통해 자동으로 스웨거가 적용된다. @ApiBearerAuth로 인증이 필요한 작업도 스웨거 UI를 통해 테스트 할 수 있다.
• TypeORM에서 where 조건에 undefined 값이 들어가면 해당 필드의 조건이 쿼리에서 생략되는 이슈를 알게 되었다. [해당 이슈] 22년에 발행된 이슈인데 Open 상태이고 최근 댓글에선 다른 ORM을 추천하고 있는 걸 보아하니 아직도 똑같이 동작하는 듯…
• 구직자와 회사가 각 도메인으로 나뉘어져 있고, 회원가입/로그인 로직이 유사할 수밖에 없는데, 각각 파일에 그대로 복붙 했었던 게 아쉽다. 지금은 간단한 로직이라 빼서 쓰기에도 애매하다 싶지만…

social-feed-hub

2024.08.21 ~ 2024.08.29
🔗 GitHub
프로젝트 기간에 작성한 글들

• 활발한 코드리뷰를 통해 어떻게 재사용성이 높고 가독성이 좋은 코드를 짤 수 있는지 코드 스타일에 대해 고민해볼 수 있었던 프로젝트였다. 예를 들면, 목록 조회 API에서 쿼리 빌더로 데이터를 가져오는 부분을 private 함수로 빼 책임 분리를 하거나, ORM API로 가능한 부분은 최대한 그렇게 쓰도록 팀 룰을 정하기도 했다.
• Lint 규칙이나 용어, Issue 템플릿 등 그동안 생각해보지 못한 컨벤션들을 구체적으로 정해두고 체계적으로 작업할 수 있어 좋았다. @typescript-eslint/* 패키지를 통해 Lint에 타입 규칙을 지정해두어서, 타입스크립트를 더 공부하게 되는 계기이기도 했다.
• 게시물 목록 조회 API를 구현하며 잘 모르고 그냥 사용했던 JOIN 개념(inner, left…)을 제대로 공부하고 적용해볼 수 있어서 좋았다.
• @IsPublic 데코레이터와 가드 커스텀을 통해 Public API를 보다 용이하게 지정할 수 있다는 걸 알게 되었다. [관련 커밋]

matjum

2024.08.28 ~ 2024.09.06
🔗 GitHub
프로젝트 기간에 작성한 글들

• 아무것도 모르고 docker-compose up 만 했던 과거를 청산하고 도커와 컨테이너 개념에 대해 조금이나마 알게 되어서 좋았다. 직접 도커 환경을 구성하진 않았지만 스크럼에서의 팀원분의 지식 공유를 통해 컨테이너와 볼륨 개념을 이해할 수 있었다.
• PostGIS 또한 이전에 진행한 프로젝트에서 사용했던 스택인데, 이번엔 그때보다 더 코드 리뷰를 활발히 진행해서 어떻게 동작하는지 알 수 있었다.
• 테스트 코드 중요하다 얘기만 듣다가 직접 작성해본건 거의 처음이었는데 테스트를 작성하며 버그를 발견하는등 정말 중요성을 직접 실감하게 되었다. [관련 PR] 처음엔 어떻게 써야할 지 정말 막막했는데, 팀원 분이 일단 GPT를 사용해보고 학습하라는 팁을 주셔서 잘 활용했다.
• 배포를 맡았었는데 EC2, RDS는 평소와 비슷하게 사용했지만 IAM에 대해 생각해본건 처음이라서 좋았다. 원래 루트 계정은 잘 사용하지 않는다는 사실과 권한 관리에 대해 학습해볼 수 있었다.
• 디스코드 웹훅에 대해서 알게 되어서 좋았다.

기업과제 1

2024.09.04 ~ 2024.09.11

• MSA 얘기만 듣다가 NestJS에서 모노레포 구조를 구성해보며 쁘띠 MSA같이 약하게나마 도메인 분리를 경험해볼 수 있어 좋았다.
• 공통 모듈(libs/)에 대해서는 이해가 잘 안되어서 import 하는 것이나 각각의 도메인 코드가 어느 선까지 공유 되어야 하는건지, 의존성을 어떻게 정리할지 생각하는게 힘들었다.
• RPC라는 통신 기술을 새롭게 알게 되어서 좋았다.
• 다만 개인 일정 때문에 제대로 진행하지 못해 정말 아쉬웠다.

기업과제 2

2024.09.15 ~ 2024.09.29
🔗 GitHub

• 개인 프로젝트에 도커를 적용해 볼 생각은 해보지 못했는데 matjum때 인상깊기도 했고 자신감이 생겨서 도커를 직접 설정했다. 확실히 직접 써봐야지 좀 알게 되는 것 같다… 도커 설정과 관련된 글도 하나 썼었다.
• 이때도 테스트 코드를 작성하며 버그를 발견했었다. 부동소수점과 관련된 버그였어서 간단히 toFixed()를 통해 해결하긴 했다. [관련 커밋]
• 이때는 나태함 이슈로 중요 API 하나를 제출 기간이 지난 후 구현했다…

전체 회고 (KPT)

Keep

• 매일 스크럼에서 고민사항이나 상황 공유 등을 하면서 내 업무가 아니어도 어떻게 기능하는지, 다른 팀원은 어떤 에러를 어떻게 해결하는지 지식 도둑질을 할 수 있어서 좋았다. 개인으로 기업 과제를 하는 기간 동안에도 매일 데일리 스크럼을 진행했는데, 러닝 메이트 느낌으로 계획 공유하고, 시시콜콜한 이야기도 하고, 일찍 일어나는 강제성을 부여할 수 있고… 현재까지도 하고 있다.
• 팀 노션에 같이 TIL을 작성했는데, 이게 정말 좋았다. 이전까지 팀 활동 할 땐 각자 TIL을 작성하고 발표하는 식으로 진행했었는데, 이 방식도 물론 장점이 많지만 개인적으론 각자 읽고 피드백 하는 방식이 마음에 든다. 또 팀원만 볼 수 있는 공간에 작성하다보니 편하게 쓸 수 있었고, 노션으로 특정 부분을 태그해 댓글을 달 수 있는 것도 좋았다.
• 커밋, Issue, PR, lint, prettier, 용어 정리, 코드 스타일, 리뷰 룰 등 컨벤션을 세세하게 정할 수록 작업할 때엔 수월해진다는 점을 체감하게 되어서 좋았고 앞으로도 열심히 적용할 것 같다.

Problem

• 주에 2번, 3시간씩 백엔드 기술과 관련된 정규 수업이 있었는데, 이 시간에 집중을 잘 못해서 개인적으로 아쉬웠다. 집중이 안 되는 내용이더라도 좀 더 노력할 걸 싶다.
• 개인 프로젝트를 진행하는 기간 동안엔 거의 한량처럼 놀아서 지나고보니 후회스럽다. 이건 내 고질적인 문제인듯…
• 기록하지 않으면 내 머릿속엔 아무것도 남지 않는다…

Try

• 이번 기회에 알게 된 것들(Keep에 작성한 것들) 앞으로 잘 적용해 유지하기.
• 코드 리뷰는 너무 좋은 문화지만 시간이 많이 필요한 것도 사실이다. 코드 래빗과 같은 AI 코드 리뷰 도구 도입을 통해 작업을 조금이나마 줄일 수 있을 것 같다.
• 스크럼 참여 전 내용 정리를 확실하게 하고 가면 효율적으로 시간을 운용할 수 있을 것 같다.

느낀점

부트캠프만을 수료했던 때의 나는 정말 우물 안 개구리 였다는 걸 깨달았다. 이 프로그램을 하지 못했다면 나는 지금 개발을 안 하고 있었을지도 모른다. 과정 자체도 나쁘진 않았지만, 팀원분들 덕분에 정말 많이 배웠고 개발에 계속 재미를 붙이게 됐다.
모두의 행운을 빕니다…🍀

부록: 나의 장점

서로의 장점을 이야기하는 시간이 있었다. 단점은 진행하지 않았다. 탁월한 선택!

팀원분들이 적어주신 나의 장점 헤헤

서로 이렇게 피드백을 주는 시간을 갖는 것 정말 좋은 것 같다. 어느정도 객관적으로 날 바라볼 수 있게 되고, 기분이 참 좋고😏.