[PROJECT] 프로메사(PROMESA) 개발 후기

프로젝트 소개

♥️랜딩페이지

🌱깃허브 링크

📍프로젝트 인원 : 8명, 기획/디자인/프론트/백엔드 각 부서 2명씩

📍프로젝트 기간 :  5월 14일(첫 커밋) ~ 8월 8일(데모데이)

팀 프로메사는 아직 주목받지 못한 신예 작가들을 발굴하고
플랫폼을 통해 작품의 전시와 거래를 돕습니다.

도예 작가의 작품을 큐레이션하여 전시 및 판매하는 플랫폼 - 프로메사(PROMESA)

 

프로메사는 커머스 사이트로서, 개발 관점에서 바라보면 전형적인 쇼핑몰과 거의 동일한 기능 요구사항을 가지고 있었다. 로그인과 회원가입 기능을 비롯해서 상품을 둘러보고 마음에 드는 작품에 하트를 눌러 찜할 수 있는 기능, 그리고 실제 구매까지 이어지는 흐름이 일반적인 커머스 사이트의 요구사항과 크게 다르지 않아 기획을 이해하기에는 전혀 무리가 없었다.

 

사전 경험

본격적으로 프로젝트와 구현 과정을 소개하기에 앞서, 프로메사 개발 이전의 나의 스펙을 간단히 정리해보겠다. 우선 나는 프로젝트 자체에 대한 경험은 꽤 많았다. 게임 개발에서는 프로그래머 또는 기획자로, 또 프론트엔드로 해커톤에 참가해본 경험이 있었다. 덕분에 개발뿐만 아니라 기회, 디자인 등 다양한 분야의 사람들과 협업한 경험은 많은 편이었다.

 

다만 스프링을 이용한 백엔드 경험은 조금 달랐다. 그때 해당 프로젝트에서 내가 맡았던 것은 단순한 CRUD 기능 구현 정도에 불과했다. Spring Security를 다뤄본 적도 없었고, 배포도 내 역할이 아니었다. 그나마 백엔드 경험을 쌓을 수 있었던 건 CEOS 과제였던 지식인 프로젝트였다. 그때 혼자서 24개의 API를 개발하며 조금은 익숙해질 수 있었다. 휴학생 신분이라 시험기간에 동아리도 쉬는 틈을 적극 활용한 덕분이었다. 하루에 개발 7시간 하던 미친(Positive) 시절,,,

 

프로젝트 구현에 대한 걱정도 물론 있었지만 사실 크게 걱정하지는 않았다. 세상이 좋아져서 챗GPT가 충분히 똑똑해졌고, 충분한 인내심과 시간만 있다면 못 할 게 없다고 생각했다. 그리고 무엇보다 나는 누구보다 시간이 많은 휴학생이었다!

 

기능 요구사항

최종 API 명세서는 총 16개의 인덱스로 구분했다.

• home: 서비스 접속 시 홈 화면에 표시되는 정보 조회 및 검색 기능
• image: S3 버킷 내 이미지 등록 및 삭제
• exhibition: 기획전 관련 CRUD
• auth: 인증 및 인가 처리
• member: 회원 정보 관련 CRUD
• address: 회원 배송지 정보 관련 CRUD
• artist: 작가 정보 관련 CRUD
• item: 작가 작품 관련 CRUD
• wish: 작품/작가 위시리스트 추가·삭제·조회
• category: 카테고리별 작품 조회
• cart: 회원 장바구니 관련 CRUD
• order: 장바구니 작품 주문, 주문 내역 조회·취소
• payment : 토스 페이먼츠와 연동하여 작업할 예정이었으나 프로젝트 일정상 폐기
• review: 회원 리뷰 CRUD
• delivery: 배송 관련 CRUD
• inquiry: 회원 문의 CRUD

그리고 관리자 페이지까지 합하면 더 많다... 

이렇게 총 64개(...)의 API를 개발했다. 

이정도면 나름 대규모 프로젝트 아니였을가...?

 

작업 과정

ERD를 설계하고 API 명세서를 작성한 뒤 본격적으로 개발에 들어갔다.

 

우리 팀의 워크플로우는 조금 독특했는데, 백엔드에서 API 명세서를 작성했다고 해서 곧바로 개발을 시작하지는 않았다. 디자인이나 확정된 와이어프레임이 나온 뒤, 해당 페이지 디자인을 보면서 필요한 데이터가 무엇인지 고민하고 나서야 API를 구상하고 구현에 들어갔다. 그동안 프론트는 화면을 제작하고 백엔드에서 API 구현을 끝내면 바로 연결하는 식으로 업무가 착착 이루어졌다. 덕분에 전체 작업 속도가 빨라졌을 뿐만 아니라, 개발 이후에 중간 수정 없이 쭉 이어갈 수 있어서 훨씬 편했다

 

이런 워크플로우를 채택하게 된 건 디자인 확정 전 뇌피셜로 개발을 진행했다가 기획 변경이나 디자인 수정 때문에 같은 작업을 두세 번 반복해야 하는 상황을 여러 번 겪어봤기 때문이다. 초반에 전 부서의 작업 흐름을 명확히 합의해둔 게 정말 다행이었다.

 

그리고 배포를 꽤 이른 시점에 해둬서 덕분에 백엔드에서 API를 개발할 때마다 프론트가 바로 연결 작업을 진행할 수 있었다. 흔히 백엔드-프론트 연결 과정이 가장 까다롭고 실패 확률이 크다고 하는데 우리 팀은 전혀 그런 문제가 없었다. 프론트에서 연결 중 오류가 발생하더라도 이미 이전 API들이 모두 붙어 있는 상태라서 검토하고 수정할 범위가 훨씬 줄어들었다. 그래서 백엔드에서 한 번 구현하면 크게 수정할 일이 거의 없었다.

 

주요 구현 파트

나는 이번 프로젝트에서 주로 인프라를 관리했다. 배포를 맡았고 CI/CD를 구축했다. 토스 페이먼츠 연동을 이용한 결제 기능은 데모데이까지 불가능할 것 같아서 포기했기 때문에 결국 핵심 구현 영역은 인증·인가와 배포였다고 할 수 있다. 특히 배포는 내가 전담했는데, 자연스럽게 AWS를 다룰 일이 많았다. 마침 AWS 자격증을 준비하던 시기였던 덕분에 AWS 관련 기능은 대부분 내가 담당하게 되었다.

 

API는 home, exhibition, address, artist,item, review 등을 구현했고 일부 관리자 페이지 기능도 맡았다. 대부분은 CRUD 중심이라서 큰 어려움이나 특이사항은 없었다. 다만 초반에 S3 Presigned URL을 발급받아 이미지를 업로드·조회하는 부분은 꽤 공을 들였다. 이후 프로젝트 전반에서 이 코드를 재사용했는데 S3Service를 만들어 이미지 조회 메서드를 묶어둔 덕분에 두고두고 활용할 수 있었다. 객체지향적인 구조를 잘 잡았다는 점에서 만족스러웠다.

 

또 조회 성능 최적화를 위해 QueryDSL을 적극적으로 사용했다. 단순히 동작하는 쿼리에서 그치지 않고 조건별로 최적화된 조회를 구현하는 연습이 많이 되었다.

 

리뷰 기능은 특히 시간이 오래 걸린 부분이었다. 단순히 글만 등록하는 게 아니라 이미지도 함께 업로드해야 했기 때문에 프론트와 어떻게 통신할지 고민이 많았다. 실제로 지그재그 같은 쇼핑몰 사이트를 직접 참고하며 플로우를 정리했다. 또한 리뷰 검증 로직에서도 고려할 사항이 많아 여러 번 다듬으며 완성해갔다.

🍒전체 흐름
: S3에 먼저 이미지를 등록하고 이후 리뷰 내용을 등록할 때 이미지는 key값만 넘김

1. 프론트가 이미지를 업로드 할 Presigned URL 요청 → review-images/presigned-url API 호출
2. 서버가 S3 Key 생성 + URL 발급 후 응답
3. 프론트가 S3에 이미지 업로드
4. 사용자가 리뷰 작성 제출 시, 프론트에서 해당 리뷰 내용과 이미지 key 목록도 함께 전송 → reviews API 호출
5. 백에서 리뷰를 저장하고 연결된 이미지 key들을 DB에 저장


🍒검증
1. 실제 주문 내역이 있는가?
2. 주문의 상품 id와 회원 id가 일치하는가?
3. 상품이 배송되고 난 이후의 리뷰인가?
4. 주문 상품에 대해 이미 리뷰를 작성했는가?
5. 내용이 최소 10자, 최대 1000자를 만족하는가?
6. 별점이 최소 1점, 최대 5점을 만족하는가?
7.이미지 최대 3장을 넘지 않았는가?

 

개발 시 중점 사항

하나의 프로젝트라 하더라도 체계적으로, 제대로 해내고 싶다는 마음가짐이 컸다. 단순히 완성만 목표로 두는 것이 아니라 개발 문화 자체를 경험해보고 싶었기 때문이다. 이를 위해 우리 프로젝트에는 몇 가지 큰 규칙을 두었다.

1. 구현해야 할 기능은 이슈로 미리 파두기
2. 깃허브 PR과 이슈는 일대일 대응 될것
3. 깃허브 브랜치는 이슈 일대일 대응 될 것
4. PR시 서로 코드리뷰를 할것
5. 코드 리뷰를 반영한 후 꼭 merge할 것

 

굵직한 기능을 개발할 때는 반드시 코드 리뷰를 하려고 노력했다. 특히 마지막에 진행했던 코드 리뷰가 정말 큰 도움이 되었다. 서로의 코드를 보면서 배울 수 있었을 뿐 아니라, 내가 놓친 부분이나 보완하면 좋을 부분(예: 검증 로직 추가)을 서로 댓글로 남겨주면서 성장 속도를 두 배로 끌어올릴 수 있었다. 가장 댓글이 많이 달린 PR은 무려 23개(ㅇㅁㅇ!!!)까지 달렸다. 무엇보다 서로 코드에 칭찬을 남기면서 동기부여도 되었다. 

 

개발적인 측면에서는 최적화에 많이 신경 썼다. 아무래도 커머스 사이트 특성상 이미지가 많아서 이걸 어떻게 효율적으로 다룰지와 로딩 속도를 개선하는 것이 최대 고민이었다. 이미지는 S3의 PresignedUrl을 이용하여 불러오고 CloudFront를 이용해 최적화했다. 만약 프로젝트 기간이 더 길었다면 Lambda를 이용한 이미지 리사이징 등 좀 더 다양한 최적화를 시도했을 것이다. 

 

또 조회 시 QueryDsl을 적극적으로 쓴 것도 최적화의 일환이었다. 

 

개발 과정에서의 어려움

내가 구현했던 부분 중 가장 어려웠던 건 단연 배포였다. 욕심을 부려 이것저것 좋아 보이는 건 다 넣다 보니 CI/CD 파이프라인이 지나치게 복잡해졌다. 모든 코드를 구현하고 실행을 돌렸을 때, 화면에는 계속 502 에러만 떴다. 그때부터 약 2주 가까이, 새벽 2시까지 매일같이 이 문제만 붙잡고 있었다. 작성한 게 워낙 많다 보니 어디가 문제인지 찾는 과정 자체가 너무... 너무 힘들었다. 그래서  처음 사이트가 제대로 떴을 때는 정말 눈물 날뻔.... 괜히 불필요하게 배포 파이프라인이 복잡해진 느낌인데, 그러나 이미 작동된 이상.,,, 더 이상 손댈 수 없다. 개발판의 명언, 일단 작동하면 건들지 마라

 

이 날이 시작이었지...

배포 이후에 또 하나 골치 아팠던 문제는 OOM(Out Of Memory) 에러였다. 프론트가 작업을 하던 것도 아니고 그냥 새벽에 혼자 서버가 죽어버리는 문제점이 계속해서 발생했다. 힙 덤프도 뜨고 나름대로 덤프 파일을 분석해보려고 여러 시도를 해봤지만 근본적인 원인은 끝내 찾아내지 못했다. 결국 선택한 임시방편은 EC2 인스턴스 스펙 업그레이드였다. 데모데이 당일 서버가 죽는 상황은 절대 막아야 했기 때문이다. 다행히 데모데이 이후에는 다시 다운그레이드를 했는데, 그 뒤로는 서버가 죽지 않았다. 아마 프론트에서 개발 과정 중 너무 많은 요청을 보내서 서버가 과부하로 터진 게 아닐까 싶지만...아직도 모르겠다ㅜㅜ 배포가 문제였을까....

ㅠㅠㅠ

데모데이

우리 팀은 전체적인 mood를 중요시해서 팀원들끼리 드레스코드까지 맞췄다. 차분하고 chill한 느낌의 베이지를 메인 컬러로 정했는데, 다들 철저하게 드레스코드를 지킨 게 귀여웠다ㅋㅋ

부스는 포스터와 미니 배너를 세우고, 무엇보다 사이트에 등록된 작품들을 실제로 가지고 와서 일부 전시했다. 직접 보니 너무 이쁘면서도 신기했다. 특히 우리 팀의 디자인을 보고 다들 감탄했는데 나도 무척 동의하는 바다. 실제 운영 중인 사이트와 비교해도 전혀 손색없는 퀄리티였다. 

 

다른 팀 부스도 구경하며 돌아다녔다. 각자 열심히 준비한 흔적이 보였고 또 우리 프로젝트와 어떻게 다른지, 구현해야 할 요구사항은 어떤 차이가 있는지 비교해보는 재미가 있었다. 다만 아쉬운 점은… 우리 쪽에 사람들이 상대적으로 많이 몰리지 않았다ㅠㅠ 우리 팀이 짱인데!

 

수상은 아쉽게도 하지 못했다. 수상 기준이 개발 완성도보다는 기획적인 측면에 더 많은 점수를 둔 듯했다. 사회적 의미를 지닌 기획들이 모두 상을 받았다. 사회적 가치를 담은 기획이 선호된다는 걸 느낄 수 있었다.

 

비록 팀이 수상은 못했지만, 나는 개인적으로 백엔드 열정맨으로 선정되었다! 해당 후기는 여기로✨

 

결론

정말 잘 만든 프로젝트라고 자부할 수 있다. 비록 수상은 하지 못했지만, 개발적인 측면에서는 결코 뒤처지지 않는 퀄리티였다고 생각한다. 이 프로메사 프로젝트 하나를 통해 정말 많은 것을 경험하고 배웠다. 특히 내가 직접 구현한 부분이 많을수록 얻어가는 게 훨씬 크다는 걸 다시금 느낄 수 있었다.

 

구현뿐만 아니라 깃허브의 다양한 기능(이슈, PR, Discussion)을 적극적으로 활용했고, 코드 리뷰 문화까지 체험했다. 무엇보다 다른 부서와의 소통을 통해 협업하는 프로젝트가 어떤 것인지 제대로 체감할 수 있었다. 그리고 역시 가장 어려운 건 ‘완성’이라는 말처럼, 데모데이 이후 더 이상 손볼 부분이 없을 만큼 명확하게 프로젝트를 끝낼 수 있었던 점이 놀랍고 감사했다. 이게 가능했던 건 무엇보다 좋은 팀원들을 만났기 때문이라고 생각한다. 프로젝트 경험이 적지 않다 보니 팀원과 팀 분위기의 중요성을 뼈저리게 느끼는데, 프로메사 팀은 정말 최고였다. 누구 하나 빠짐없이 맡은 일에 책임을 다하고, 소통까지 원활했던 팀이었다ㅎㅎ

 

이번 프로젝트에서 배운 게 많은 만큼, 앞으로 다가올 프로젝트들에서도 이 경험들을 알차게 활용할 수 있을 것 같다. 이제는 나도 당당하게 프로젝트 하나 제대로 해봤다라고 말할 수 있게 되었다!

 

마지막의 그동안의 노력이 흔적이 보이는 내 깃허브 잔디로 마무리하겠다☘️