1차 MVP 백오피스 기능 프론트엔드 개발 회고

들어가기 전에

백오피스 기능 TF 팀의 프론트엔드로 참여하며, 초기 프로젝트 세팅을 담당하게 되었습니다. 이 과정에서 고민했던 기술 스택 선택, 프로젝트 구조 설계, 그리고 담당 페이지 구현하는 과정에서 고민했던 내용들을 정리해 보았습니다.

기술 스택 선정

백오피스 서비스 특성상 디자인 팀의 별도 지원 없이 개발을 진행해야 했습니다. 디자인 일관성을 유지하면서 빠르게 화면을 만들기 위해 Tailwind CSS를 선택했고, 완성도 있는 컴포넌트 구성을 위해 Shadcn/ui를 함께 활용했어요.

배포는 기존 서비스인 ‘스노로즈’와 동일하게 Cloudflare를 선택했습니다. 기존 도메인을 그대로 활용할 수 있고, 인프라 운영 측면에서도 관리 포인트를 하나로 합치는 것이 효율적이라고 판단했기 때문이예요.

• 코어: React, TypeScript
• 상태 관리: TanStack Query
• UI/스타일링: Tailwind CSS, Shadcn/ui
• 빌드 도구: Vite
• 패키지 매니저: npm
• 배포: Cloudflare Pages

프로젝트 구조 설계

이번 프로젝트는 공통 요소와 비즈니스 도메인을 명확히 분리하는 데 중점을 두었습니다. 특히 토스의 'Frontend Fundamental' 문서에서 제시하는 구조를 참고해, 새로운 기능을 추가하거나 기존 기능을 수정·삭제할 때 다른 영역에 영향이 최소화되도록 구조를 설계하고자 했어요.

• src: 전역에서 공통으로 사용하는 로직과 설정을 관리
• src/domains: 비즈니스 도메인별로 기능을 분리해 관리하고, 각 도메인의 응집도를 높이는 데 집중

가장 큰 차이점은 기존 스노로즈 프로젝트에서는 공통 컴포넌트, 상수, 커스텀 훅 등을 shared 디렉터리에 모아 관리했지만, 이번 백오피스에서는 이들을 src 바로 아래에 배치하는 방식을 선택했다는 점입니다.

이렇게 구성하면 디렉터리 뎁스가 줄어들어 더 빠르게 접근할 수 있고, 동시에 도메인별 구조는 훨씬 깔끔하게 유지될 것으로 기대돼요. 앞으로 MVP 이후 기능이 더 확장되면, 이 구조가 실제 유지보수에도 효과적인지 계속 확인해볼 예정입니다.

src/
├── apis/                    # API 호출 함수
├── assets/                  # 정적 자산 (이미지, 로고 등)
├── axios/                   # Axios 인스턴스 설정
├── components/              # 공통 컴포넌트
├── constants/               # 상수 정의
├── hooks/                   # 커스텀 훅
├── pages/                   # 페이지 컴포넌트
├── types/                   # TypeScript 타입 정의
├── utils/                   # 유틸리티 함수
├── ...
└── domains/                 # 도메인별 기능
    ├── Users/
    │   ├── components/
    │   ├── hooks/
    │   └── ...
    └── Points/
        ├── components/
        ├── hooks/
        └── ..

프론트엔드 개발 과정

1차 MVP 기능 개발에서는 아래와 같은 기능들을 담당했습니다.

• 로그인 (관리자 등급만 가능)
• 푸시알림
• 포인트 지급 (1건 지급, 정회원 전체 지급, 포인트 미지급 기간 설정/조회/수정/삭제)
• 프로젝트 세팅 및 Cloudflare 배포
• 사이드바 등 주요 컴포넌트 작업

제가 맡았던 기능들은 운영기획팀에서 이미 Postman으로 사용하고 있던 API 기반 기능들이라, API 연동 자체에서 큰 이슈는 없었습니다.

다만 실제 운영기획팀이 매일 사용하는 기능이기 때문에, 운영 정책에 따른 사용성에 대한 고민을 많이 했습니다.

예를 들어, 포인트 지급 기능은 기존에는 아래와 같은 흐름을 거쳐야 했습니다.

1. 학번/아이디를 통해 회원의 userId 조회(운영기획팀 → 백엔드에 조회 요청) 후 userId에 직접 입력
2. 지급을 수행한 관리자 userId를 조회해 sourceId에 직접 입력
3. 포인트 카테고리별 포인트 증감량 정책을 노션 문서에서 확인
4. category, difference(포인트 증감량), source, memo를 모두 수동 입력

이 과정이 반복되다 보니, 실수 가능성도 있었고 사용성도 좋지 않았습니다.

그래서 백오피스에서는 아래와 같이 개선했습니다.

• 학번/아이디만 입력하면 바로 회원 정보 자동 조회
• 포인트 유형 선택 시 자동으로 증감 포인트량 입력
• 노션 문서를 열어 확인하는 절차 제거
• 관리자 userId를 프론트에서 자동 처리해 화면에서는 입력하거나 노출하지 않도록 변경
• 포인트 지급 전 마지막으로 한 번 더 확인할 수 있는 검증 단계 추가

기존에 여러 단계를 거쳐야 했던 작업들이 이제는 직관적인 화면 조작만으로 처리할 수 있도록 흐름을 정리하였습니다.

마치며

이번 백오피스 프로젝트는 단순히 기능을 구현하는 데서 그치지 않고, 실제로 운영기획팀이 매일 사용하는 도구를 만든다는 관점에서 많은 고민을 하게 된 경험이었습니다.

기술적인 완성도뿐 아니라 운영 정책과 실제 업무 흐름을 이해하고, 이를 어떻게 화면과 인터랙션으로 자연스럽게 풀어낼지 생각하는 과정이 중요하다는 것도 다시 느꼈어요.

앞으로도 운영기획팀의 피드백을 바탕으로, 더 사용하기 쉬운 백오피스로 계속 발전시켜 나가보려고 합니다. 🙌