백엔드 데브코스 12기 36일차

이 날은 프로젝트 발표를 진행한 날이었다. 내가 발표를 맡게 되어 주말부터 발표 준비를 계속해서 진행했다.

1. 발표 자료 수정

주말 동안 PPT를 계속 읽어보면서 우리 팀이 실제로 구현한 기능과 구현하지 않은 기능을 하나씩 확인하고 수정했다. 처음에는 만들어둔 발표 자료를 그대로 사용하면 될 것 같았지만, 내용을 다시 살펴보니 실제 구현 내용과 조금 다르게 작성된 부분도 있었고, 발표에서 추가로 설명하면 좋을 기능들도 있었다.

그래서 어떤 기능을 발표에 포함하면 좋을지 계속 고민하면서 팀원들에게 자료 수정을 요청했다. 발표 자료는 한 사람이 만드는 것이 아니라 팀에서 실제로 개발한 내용을 정확하게 담아야 하기 때문에, 각 기능을 담당한 팀원들에게 구현 내용을 확인하면서 수정하는 과정이 필요했다.

디자인도 여러 번 수정했다. 단순히 깔끔한 PPT를 만드는 것보다 우리 사이트의 분위기와 서비스를 잘 보여줄 수 있는 디자인을 만드는 것이 중요하다고 생각했다. 그래서 사이트에서 사용한 색감과 분위기를 PPT에도 반영하고, 핵심 내용이 눈에 잘 들어오도록 화면과 내용을 배치했다.

발표 당일 아침에는 PPT를 마지막으로 정리하고, 발표 대본도 계속 수정했다. 실제 발표 시간에 맞춰 읽어보면서 너무 길거나 설명이 부족한 부분을 줄이고 보완했다.

2. 다른 팀의 배울 점

우리 팀의 발표 순서가 마지막이라 발표를 기다리는 동안 긴장도 많이 됐다.

다른 팀들의 발표를 먼저 듣다 보니 오히려 우리 팀 발표에서 부족한 부분이나 다른 팀과 차이점이 더 잘 보이기도 했다.

특히 다른 팀들이 구현한 기능을 보면서 우리 팀과 어떤 점이 다른지 비교해볼 수 있었다.

삭제 대신 Flag를 사용한 방식

다른 팀에서는 주문 내역이나 상품을 삭제할 때 데이터를 바로 삭제하지 않고 Flag를 사용해 삭제 여부를 관리하고 있었다.

주문을 실제로 삭제해버리면 관리자가 주문 취소 내역을 확인하기 어려워지고, 상품을 삭제할 경우 기존 주문 내역에서 해당 상품을 참조하고 있다면 문제가 발생할 수 있었다. 데이터를 바로 삭제하지 않고 상태를 관리하는 방식이 실무적으로 어떤 장점이 있는지 생각해볼 수 있었다.

배송 상태 구현

우리 팀에서는 구현하지 않았던 배송 상태 관리 기능도 다른 팀에서는 구현되어 있었다.

주문의 상태를 단순히 주문 완료로 관리하는 것이 아니라 배송 과정을 함께 관리하는 것을 보면서, 서비스의 요구사항에 따라 주문 도메인에서 관리해야 하는 정보가 달라질 수 있다는 점을 알게 되었다.

주문과 배송을 분리한 방식

주문이 여러 개 존재하는 경우 주문 내역 자체를 하나로 묶는 것이 아니라 배송 단위로 묶어서 관리하는 방식도 있었다.

우리 팀에서 생각했던 주문 구조와 다른 방식이어서 흥미로웠고, 실제 서비스에서는 주문과 배송의 책임을 분리해서 설계할 수도 있다는 것을 알게 되었다.

주문 당시 결제 금액 저장

다른 팀에서는 Order에 결제 금액을 별도로 저장해두고 있었다.

상품 가격이 변경되더라도 이미 주문한 상품의 결제 금액은 변하지 않아야 하기 때문에, 주문 당시의 금액을 별도로 보관하는 방식이었다.

이 부분을 보면서 우리 팀의 구조에서는 상품 가격이 변경되었을 때 기존 주문 내역의 가격이나 통계에도 영향을 줄 수 있다는 문제를 다시 생각해보게 되었다.

이미지 파일 업로드

상품 이미지를 단순한 URL로 관리하는 것이 아니라 실제 이미지 파일을 업로드하는 기능을 구현한 팀도 있었다.

같은 상품 관리 서비스라도 이미지 저장 방식까지 구현하는 등 팀마다 기능을 확장한 방향이 달라서, 다른 팀의 발표를 들으며 다양한 구현 방법을 접할 수 있었다.

3. 피드백

발표 이후 강사님과 FT님께서 우리 팀에 대한 피드백을 주셨다.

먼저 핵심 기능 중 하나였던 오후 2시 주문 합배송 테스트를 잘 진행했다는 점을 좋게 봐주셨다. 실제 요구사항을 단순히 코드로 구현하는 것에서 끝내지 않고, 핵심 기능이 제대로 동작하는지 테스트한 부분이 긍정적인 평가를 받은 것 같았다.

또한 H2와 MySQL의 차이를 고려하여 Testcontainers를 도입한 부분도 칭찬을 받았다. 개발 환경과 실제 환경에서 사용하는 DB가 달라질 수 있다는 점을 고려해 테스트 환경을 구성한 것이 의미 있는 작업이었다.

트러블슈팅 내용을 발표 자료에 원인 → 해결 과정 → 결과의 흐름으로 잘 담았다는 피드백도 받았다. 단순히 "이런 오류가 있었고 해결했다"라고 작성하는 것이 아니라, 문제가 발생한 이유와 해결 과정, 최종 결과까지 보여주는 것이 중요하다는 것을 다시 한번 느낄 수 있었다.

반면 상품 가격 변경과 관련된 스냅샷 문제는 개선할 부분으로 피드백을 받았다. 현재 구조에서는 상품 가격이 변경되었을 때 기존 주문 내역의 가격에도 영향을 줄 수 있고, 이에 따라 과거 주문을 기반으로 하는 통계까지 변경될 수 있는 문제가 있었다.

다른 팀의 발표에서 주문 당시 결제 금액을 별도로 저장하는 방식을 본 뒤 받은 피드백이라 더욱 이해하기 쉬웠다.

이번 피드백을 통해 현재의 데이터만 관리하는 것이 아니라 과거의 주문 데이터가 변경되지 않아야 하는 경우까지 고려해서 도메인을 설계해야 한다는 점을 배울 수 있었다.

4. 발표를 마치고

발표를 준비하면서 개발한 기능을 잘 만드는 것만큼 내가 만든 결과물을 다른 사람에게 어떻게 전달할 것인지도 중요하다는 것을 느꼈다.

특히 발표를 준비하면서 우리가 무엇을 구현했고, 어떤 부분에서 고민했으며, 어떤 문제를 해결했는지를 다시 정리할 수 있었다. 다른 팀의 발표를 보면서는 내가 생각하지 못했던 구현 방식이나 설계 방법도 배울 수 있었다.

이번 발표를 통해 단순히 프로젝트를 완성하는 것에서 끝나는 것이 아니라, 다른 사람의 구현을 보고 비교하면서 내 코드와 설계를 돌아보는 과정도 좋은 공부가 될 수 있다는 것을 느꼈다.

이제 프로젝트가 거의 마무리된 만큼, 이번에 받은 피드백을 바탕으로 부족했던 부분을 다시 한번 정리하고 앞으로 프로젝트를 진행할 때는 처음 설계할 때부터 데이터의 변경 가능성과 과거 데이터의 보존까지 고려하는 개발자가 되어야겠다고 생각했다.