회고록

📌 프로젝트 목표

• 선물 증정 서비스 금나와라 뚝딱(이하 금뚝) 개발

😁 Liked

🔥 최영권

• 프론트, 백엔드 다같이 프로젝트를 기획부터 개발까지 경험 할 수 있어서 좋았습니다.

• 초기에 백엔드끼리 도메인, erd 설계와 같은 작업들을 다 같이 하면서 같은 기획을 바라보고 어떻게 설계할 것인지를 경험할 수 있어서 좋았습니다.

• 지라를 도입한 이슈 관리를 경험 할 수 있어서 좋았습니다.

• 이미지와 함께 데이터 처리에 대한 것을 알 수 있게 되어서 좋았습니다.

🔥 신언주

• 프론트와 함께 프로젝트를 경험해 볼 수 있어서 좋았습니다.

• 프론트, 백엔드 모두 의사소통이 잘되어 싸우지 않아서 좋았습니다.

• 지각비 덕분에 마지막에 우리가 만든 서비스를 테스트 할 수 있어서 좋았습니다.

• 이슈를 관리하는 방법을 배울 수 있었고, PR 단위가 작아야하는 것을 깨달을 수 있어 좋았습니다.

• 처음에 다 같이 도메인 작성했던 것은 티켓을 나누는데 있어서 편리했다.

🔥 한맹희

• 첫 프론트 백엔드 협업 프로젝트인 만큼 신선하고 유익했다.

• 백엔드할때는 미처 생각못했던 프론트만의 고충을 알 수 있어서 좋았다.

• 이전 프로젝트 때는 복잡한 로직이 거의 없고 단순 CRUD API만 개발했었는데 이번에는 나름 복잡한 로직이 필요한 API가 있었기 때문에 개발하는데 재미있었다.

🧐 Learned

🔥 최영권

• 스프링 시큐리티를 적용해서 인증과 인가 처리에 대한 부분을 배울 수 있었던 것 같습니다.

• ci/cd에 대한 방법이 여러가지 있다는 것을 경험할 수 있었고 도커의 장점을 느낄 수 있었습니다.

• 제가 작업하지는 않았지만 동시성에 대한 작업을 하는 것을 보고 락에 대해서 조금 알게 되었고 코드리뷰를 통해서 같이 고민해볼 수 있었던 거 같습니다.

• 조인으로 n+1 문제를 해결하고 역정규화를 통해서 쿼리의 수를 줄이는 등 성능을 위한 고민을 하는 것을 배울 수 있었습니다.

• 성능테스트를 해볼 수 있었던 점이 좋았습니다.

🔥 신언주

• FetchJoin과 연관관계에 대해서 배울 수 있었습니다.

• 성능 개선을 위해서 많은 방법이 있다는 것을 알게 되었습니다.

• 이슈를 관리하는 방법을 배울 수 있었고, PR 단위가 작아야하는 것을 깨달을 수 있어 좋았습니다.

🔥 한맹희

• 공통 응답 객체 형식과 에러코드를 어떻게 내려줄지에 대한 고민이 평소에 많았은데 이번 기회로 프론트 분들의 의견을 듣고 좀 더 이해하기 쉬운 형식을 나름대로 정의할 수 있었다.

• 평소 도커에 대한 안좋은 이미지가 있었는데 Ec2 메모리 부족으로 인한 문제를 도커로 해결하면서 도커에 대한 유용성을 많이 배울 수 있었다.

😅 Laked

🔥 최영권

• 로그 처리와 같은 작업을 좀 더 잘 할 수 있었을 것 같은데 못한 점이 아쉽습니다.

• 개인적으로 이미지 처리 하는게 알고 보면 어렵지 않은 작업이었지만 잘 몰랐던 작업이어서 생각보다 시간이 지체 되었고 더 많은 것을 하지 못했던 것이 아쉽습니다.

• jpa 대신 jdbc를 사용해서 batch insert를 하려고 했는데 하지 못했던 것이 아쉽습니다.

• 레디스를 도입하려고 해봤지만 잘 안되어서 아쉽습니다.

🔥 신언주

• 이벤트 조회시 api를 작게 분리해서 네트워크 탭에서 선물이 보이지 않게 하는 것을 못한 것이 아쉽습니다.

• 더 빠르게 api 스펙을 전달하지 못해서 약간 아쉽다.

• 후반에 코드리뷰를 제대로 못한것 같아 아쉽다.

🔥 한맹희

• 로깅 전략을 따로 설정하지 않았기 때문에 에러 발생시 로그를 보기 위해 직접 서버에 접속해야만 했다. 미리 프로젝트 초기에 로깅 전략을 확보했다면 좀 더 효율적으로 디버깅을 할 수 있었을꺼란 아쉬움이 남는다. 다른 팀의 사례를 참고해서 적절한 로깅 전략을 적용해봐야겠다.

• 이번 핵심 목표가 성능 개선 작업의 일환으로 레디스를 도입하는거였는데 결국 제때 도입하지 못했다. 처음 프로젝트 스케쥴을 계획할때 금나와라 뚝딱의 도메인은 크지 않기 때문에 충분히 기능을 2주안에 끝내고 나머지 1주동안 성능 개선에 시간을 쏟을 수 있을것 이라 생각했다. 하지만 하지만 생각보다 기능 구현에 시간이 많이 잡아먹혔다. 후반으로 갈 수 록 프론트분들과 api를 맞춰보는 일이 늘어났는데, 그때마다 누락된 데이터, 추가되어야 하는 api, 잘못된 로직들이 발견되었고 결과적으로 성능개선 작업은 단 2일의 시간이 주어지게 되었다. 프로젝트 초반에 프론트 분들과 API 스펙에 대해서 논의 해봤다면 일어나지 않았을것이라 생각한다.

🥺 Longed for

🔥 최영권

• 프론트와 백엔드 간의 api 스펙을 미리 맞춰놓고 진행했더라면 중간에 시간이 약간 지체되는 것을 방지했었을 것 같았습니다.

• 로그 파일 관리를 좀 더 잘했더라면 프론트와 맞출 때, 성능개선을 할 때, 에러가 날 때 등 로그를 보기 편했을 것 같았습니다.

🔥 신언주

• 에러에 관한 것을 프론트와 맞추고 했으면 더 좋았을 것 같습니다.

• 조금 더 빠르게 개발해서 성능 개선을 했으면 더 좋았을 것 같습니다.

🔥 한맹희

• 프론트와 백엔드가 사전에 API 스펙을 세세하게 맞춰놓고 개발을 진행했다면 추후에 있을 병목이 많이 해결되었을 것 같다.