0. 프로젝트 소개
프로젝트명: Napal - 버려지는 자원의 경매 플랫폼
기간: 2025.08.14 - 2025.08.23 (10일)
팀 구성: 7인 (프론트엔드 2, 백엔드 2, 디자인 2, PM 1)
Napal은 버려지는 자원을 경매 방식으로 거래하는 웹 기반 플랫폼입니다. 본 프로젝트는 사업팀에서 제공한 기획서를 기반으로, 해커톤 기간 동안 실제 동작하는 MVP를 구현하는 것을 목표로 진행되었습니다.
팀은 Discord를 통해 모집된 멤버들로 구성되었으며,
나의 역할
인증: /app/(auth)/login/page.tsx, /app/(auth)/signup/page.tsx 유저 영역: /app/home/mypage/page.tsx, 고객 후기(Napal Story) 운영자 영역(백오피스): /app/admin/...
라우트 단위로 역할 분리를 명확히 하여, 프론트엔드 2인이 서로 겹치지 않는 책임 영역 안에서 병렬 개발을 진행했습니다. 공통 UI 요소(Button, Input 등)는 packages/ui/src/components에서 관리했고, Next.js 앱에서는 @workspace/ui/components/...로 가져다 쓰는 방식으로 구성했습니다.
1. 프로젝트 배경
사업팀 기획에 따르면, 지역 단위로 발생하는 잉여 자원은 거래 구조와 접근성 문제로 인해 실제로는 활용되지 못하는 경우가 많았습니다.
Napal MVP의 목적은 이러한 자원을 경매라는 단순한 거래 방식으로 연결했을 때 사용자 경험이 성립하는지를 짧은 시간 안에 검증하는 것이었습니다.
해커톤이라는 제약 환경에서, 완성도 높은 기능 수보다는 사용자가 처음 접했을 때 이해 가능한 거래 흐름을 구현하는 데 초점을 맞췄습니다.
2. 아키텍처 및 기술 스택
Napal 프론트엔드는 Next.js 기반 웹 애플리케이션으로 구성되었습니다. 빠른 구현과 명확한 책임 분리를 위해 monorepo 구조를 사용했습니다.
/apps ├─ web/ # 사용자용 서비스 (상품 조회, 입찰, 마이페이지) └─ backoffice/ # 운영자용 서비스 (상품 및 경매 관리) /packages └─ ui/ # 공통 UI 컴포넌트
Next.js
App Router 기반으로 페이지를 구성했고, 라우트 단위로 기능을 나누어 짧은 개발 기간에도 구조가 복잡해지지 않도록 했습니다.
React Query
상품 목록, 경매 정보, 입찰 내역 등 대부분의 데이터가 서버 상태에 의존했기 때문에 React Query를 사용해 서버 상태를 관리했습니다.
이를 통해
- 별도의 전역 상태 관리 없이 데이터 동기화
- 운영자 화면 변경 시 사용자 화면 자동 반영
- 로딩·에러 상태의 일관된 처리
를 구현했습니다.
4. 에피소드
(1) 정해진 기획을 MVP로 구현하기
1. 상황
본 프로젝트는 기획팀에서 이미 정의한 요구사항을 바탕으로 짧은 기간 안에 실제 동작하는 웹 서비스를 구현해야 했습니다.
기획을 수정하거나 확장하기보다는, 정해진 요구사항을 어디까지 현실적으로 구현할 수 있는지 판단하는 것이 중요했습니다.
2. 행동
사용자 관점에서 반드시 필요한 화면 위주로 구현 범위 설정
인증 → 상품 조회 → 입찰 → 마이페이지 → 운영자 관리로 이어지는 기본 흐름 구현
실시간 기능, 결제, 채팅 등은 범위에서 제외
3. 결과
핵심 사용자 흐름이 끊기지 않는 MVP를 완성했고, 기획 의도가 웹 서비스로 잘 전달되었다는 평가를 받았습니다.
(2) 사용자용 서비스와 운영자 서비스 분리 구현
1. 상황
운영자 기능은 사용자 서비스와 성격이 완전히 달랐기 때문에 하나의 앱 안에 섞일 경우 구조가 빠르게 복잡해질 수 있었습니다.
2. 행동
사용자용(apps/web)과 운영자용(apps/backoffice)을 명확히 분리
운영자 페이지는 상품·경매 관리에 필요한 최소 화면만 구현
공통 UI는 packages/ui에서 관리해 스타일 일관성 유지
3. 결과
짧은 개발 기간에도 사용자 화면과 운영자 화면이 서로 간섭하지 않는 구조를 유지할 수 있었습니다.
5. 회고 및 향후 개선 방향
이번 해커톤은 정해진 기획을 얼마나 빠르고 정확하게 제품으로 옮길 수 있는가를 집중적으로 경험한 프로젝트였습니다.
기능을 더 만들기보다는, 주어진 시간과 조건 안에서 어디까지 구현하는 것이 적절한지 판단하는 과정이 중요했습니다.
이 경험을 통해 프론트엔드 개발자는 단순히 화면을 만드는 역할이 아니라, 기획과 기술 사이에서 현실적인 구현 범위를 정하는 역할도 수행한다는 점을 체감했습니다.