[인터파크 클론코딩] 최종 회고 (23.01.12 ~ 23.02.05)

프로젝트 선정 이유

• A-Z 에서 경험해봤던 예매를 더 깊게 해보고 싶은 마음에서 아이디어를 제시하였다.
• 인터파크는 다양한 도메인을 가지고 있어 프로젝트 진행이 빠르게 되었을 경우 티켓 외에도 도서 등으로 확장이 가능할 듯 하여서
  • 일단 시작은 티켓 도메인, 그 중에서도 뮤지컬을 기반으로 시작하기로 했다.
• 팀원들 모두가 적어도 한 번쯤은 이용해보았을 서비스이기에 도메인 이해가 더 쉬울 것이라 예상하였다.

 

개발 기간 및 인원

• 개발 기간
  • 23/01/12 ~ 23/02/05 (약 3주)
• 맡은 역할: Project Owner

 

내가 기여한 부분

• 뮤지컬 등록 API
  • multipart/form-data 를 받아서 뮤지컬 정보와 저장한 이미지 링크 저장
• 이미지 S3 에 업로드
  • findify S3Mock 이용하여 테스트 시에는 환경 분리
• 뮤지컬 삭제(Soft) API
  • 연관된 정보들도 함께 삭제(Soft)
• 스케줄 조회, 좌석 조회 API
• 티켓 환불 API
• 공통 예외 처리 응답 DTO
• 담당한 API 에 필요한 TEST

 

깃허브 주소

https://github.com/prgrms-be-devcourse/BE-03-InterMark

 

좋았던 것

• 프로젝트 기간동안 매일 꾸준하게 개발을 지속했다.
• 개발하는 것이 더 재밌어졌다. 특히, 인프라 관련해서는 전부 새롭게 배우는 것들이어서 모두 신선했다.
• 좋은 코드를 작성하고자 노력했다. → 자세한 내용은 추가적인 글로 작성할 예정
  • 재사용하기 좋은 코드를 작성하고자 노력했다. 뮤지컬에 종속되어 있는 엔티티들이 굉장히 많았다. 내가 뮤지컬 등록과 삭제를 담당하였기에, 뮤지컬 도메인의 근간이 되는 코드들을 다 작성했어야 했다. 뮤지컬 조회, 수정을 작성하는 다른 팀원들이 재사용하기 좋은 코드를 작성하고자 노력했다.
  • 테스트하기 쉬운 코드를 작성하려고 노력했다. 앞서 말했듯이 뮤지컬에 종속되어 있는 코드들이 많았기에 테스트하기가 어려웠다. 최대한 책임을 분리하여서 단위 테스트하기 쉬운 코드를 만들려고 노력했다.
  • 이미지를 업로드하는 서비스도 뮤지컬에 종속적이기보다는 추상화를 통해 다양한 도메인에서 사용할 수 있도록 하였다.
• 다른 팀원들은 어떨지 모르겠지만 나는 개인적으로 예매라는 도메인에 흥미를 느끼고 있었기에 이번 프로젝트가 정말 재미있었다.
• 좋은 팀원들이 함께 해주었다.
  • 운이 참 좋은 것인지 좋은 팀원들을 만났다. 내 스스로 기준치가 높아서 괴로워할 때가 있는데 팀원들의 따뜻한 한마디가 위로가 될 때가 있다.

 

배운 것

프로젝트를 하기 전 내 모습과 지금의 모습을 비교해보면 3주간이지만 나름 많은 것을 배웠다.

• 프로젝트 시작부터 배포까지의 한 과정을 전체로 겪어보는 소중한 경험을 얻었다.
  • 특히 인프라 관련 지식을 많이 알게 되었다. 막연하게만 알고 있고 자세하게는 알지 못했던 것들인데 사용하는 이유를 실제로 필요성을 느끼면서 자연스럽게 알게 되었다.
  • 다시 한 번 백문이불여일견이라는 것을 느낀다.
• 가장 중요한 것은 소통이다.
  • 팀원들 전체가 생각하는 프로젝트의 그림, 방향성이 일치해야 효율이 나온다. 그리고 그 그림, 방향성을 일치시키기 위해 꾸준히 소통을 해야한다.
    • 내 생각의 핵심을 명확하게 논리적으로 전달하려고 노력하자!
  • 서로 동등한 관계에서 팀을 이끌어간다는 것이 쉽지 않다는 것을 느꼈다.
    • 다른 사람들에게 동기부여를 주고 생산성을 높힐 수 있는 좋은 방법이 있을까?
• 시작할 때 공통적으로 해놓아야할 것은 확실하게 해놓아야 두 번 일을 안한다.
  • 프로젝트의 근간, 건축으로 치면 기둥과도 같은 것이라고 느꼈다.
  • 명확한 기획 -> 화면 흐름 구성 -> 엔티티, db, api 설계 -> 컨벤션(깃, 코드) -> 프로젝트 환경 -> 공통 사용 코드 작성
• 문서화는 바로 하자.
  • 이것은 항상 느끼지만 실천하기가 너무 어렵다. 하지만, 최종 프로젝트때는 진짜 바로 바로 해야한다. 하루만 지나도 그 감정과 기억이 휘발된다.
• git 으로 협업하는 경험
  • 정말 많은 충돌을 해결하면서 이제 어디가서 적어도 문제를 일으키지는 않을 것 같다고 느낀다.
  • git 은 정말 잘만든 프로그램인 것 같다. 어떻게 이런 생각을 했을까?

 

아쉬웠던 것

• PO 로서 역할을 제대로 하지 못했다.
  • 개인적으로 느끼기에는 프로젝트의 완성도가 좀 아쉽다. 원인을 생각해보자.
    • 기획과 설계가 제대로 이루어지지 않아서 1차 스프린트에서 했던 것을 다 엎고 다시 했다는 점
    • 2, 3, 4차 스프린트를 진행하면서도 계속 초기 세팅 같은 것들에 대해 논의가 되어 있지 않은 부분이 있어 잦은 코드 수정이 생긴 점
    • 프로젝트 후반부부터 나를 포함한 팀원들 전체적으로 생산성이 떨어졌다.
      • 팀원들 각자 바쁜 일도 있었고, 또 조금은 지쳤을 수도 있다는 생각이 든다.
      • 지금 생각해봤을 때, 우리 팀의 유일한 단점이라면 모두가 너무 착하다. 팀의 생산성이 떨어졌을 때 쓴소리, 악역이 필요할 경우가 있다. 그 역할을 PO 인 내가 했어야 했는데 하지 않았다.
• 멘토님들을 적극적으로 활용하지 않았다.
  • 데브코스 시작 전에는 옆에서 알려줄 수 있는 존재를 간절히 원했으면서, 왜 정작 지금은 멘토님들에게 적극적으로 질문하지 않을까? 문제가 생기면 해결하려고 노력해보고 답이 보이지 않으면 꼭 질문해보자.
• 목표했던 것까지 다하지 못한 점
  • 유저 입장에서의 API 를 시간이 없어서 하지 못했다.
    • 시간이 없긴 했지만 조금은 일찍 포기를 한 건가 하는 생각도 지금 와서 생각하니 든다.
  • API 중 일부분만 동시성을 고려한 점
  • 나 개인적으로는 후반부부터는 최선을 다하지 않은 것 같은 느낌이 들어서 찝찝한 마음이 든다.

• 다른 팀원들의 로직이나 미션들에 대해 잘 알지 못하는 점
  • 소셜 회원가입 / 로그인 관련, CI/CD 관련은 꼭 한번 공부해보고 싶다.

 

맺으며

여러모로 좋았던 것도 배운 것도 아쉬운 것도 많았던 첫 협업 프로젝트였다. 이번 프로젝트를 통해서 협업이라는 것이 어떤 것인지 감을 확실히 잡았고, 다음 최종 프로젝트 때는 정말 잘할 수 있을 것 같다는 자신감도 얻었다.

그래도 가장 중요한 것은 프로젝트 기간동안 정말 즐겁게 했다는 점이다. 그거면 된 거 아닐까?