UMC Product Web: 운영 백오피스를 단단한 프론트엔드 구조로 만드는 방법

1. 왜 이 서비스가 필요했나

UMC 리크루팅은 기존에 학교별 Google Form 중심으로 분산 운영되는 구조였습니다.
이 방식은 각 학교가 자체적으로 리크루팅을 진행하기에는 빠르지만, 전체 지원자 수나 학교별 진행 현황을 중앙에서 파악하기 어렵다는 문제가 있었습니다.

또 지원 단계에서 끝나는 서비스가 아니라, 합격 이후에는 챌린저 활동과 UMC 앱 사용까지 이어지는 흐름을 가진다는 점도 중요했습니다.
즉, 지원과 운영이 분리된 도구가 아니라 하나의 흐름으로 관리되는 서비스가 필요했습니다.

UMC Product Web은 이 문제를 해결하기 위해 시작한 프로젝트입니다.

2. 단독 프론트엔드 개발에서는 기준을 먼저 세워야 했다

이 프로젝트는 사실상 단독 프론트엔드 개발에 가까웠습니다.
그래서 단순히 화면을 많이 만드는 것보다, 앞으로 화면이 계속 늘어나도 흔들리지 않을 기준을 만드는 일이 더 중요했습니다.

제가 먼저 정한 것은 다음과 같습니다.

• 라우팅과 서버 상태 책임을 분리할 것
• 폼 검증 방식은 공통 패턴으로 고정할 것
• QA 환경과 운영 환경을 분리할 것
• 혼자 개발하더라도 문서화와 검증 도구를 반드시 둘 것

이 기준을 바탕으로 TanStack Router, TanStack Query, React Hook Form, Zod, Emotion 조합을 기본 구조로 잡았습니다.

3. 어려웠던 것은 화면 수보다 흐름 간 의존성이었다

운영 서비스는 대체로 "화면이 많다"는 인상이 강하지만, 실제로 더 어려운 부분은 화면 사이의 의존성입니다.

UMC Product Web에서는 특히 다음 같은 문제가 중요했습니다.

• 지원 생성 후 어떤 조건에서 수정이 허용되는가
• 재지원 시 기존 응답을 어떻게 처리할 것인가
• 지원 파트를 바꾸면 하위 답변은 어떻게 무효화할 것인가
• 자동저장은 어떤 시점에 보장할 것인가
• 질문을 생성한 뒤 POST와 GET 결과 정렬 기준을 어떻게 맞출 것인가
• 실제 지원 페이지의 SEO는 어떻게 반영할 것인가

이 서비스에서 제가 가장 많이 고민한 것은 바로 이런 예외 케이스였습니다.
보이는 화면보다 뒤의 상태 관계를 먼저 정리하지 않으면, 나중에 기능 하나를 수정할 때 다른 흐름이 쉽게 깨질 수 있기 때문입니다.

실제로 파트 변경 시 확인 모달을 띄우고, 기존 응답을 초기화하는 흐름도 별도 훅으로 분리해 관리했습니다.

4. 혼자 개발해도 리뷰와 품질 기준은 필요했다

단독 개발의 어려움은 코드 작성 자체보다, 스스로를 어떻게 검증할 것인가에 있습니다.
그래서 이 프로젝트에서는 리뷰와 품질 검증 구조를 일부러 더 많이 넣었습니다.

Storybook을 도입한 이유

디자이너가 컴포넌트 단위 산출물 없이 작업하는 상황이었기 때문에,
화면을 구현한 뒤에도 PM과 디자이너가 어디를 기준으로 피드백해야 하는지 애매한 경우가 있었습니다.

Storybook을 도입한 이유는 단순히 "UI 예쁘게 보기"가 아니었습니다.

• 컴포넌트 단위 문서화
• PM/디자이너 피드백 기준 정리
• 후임 개발자 인수인계 대비

즉, 협업 구조를 위해 넣은 도구에 더 가까웠습니다.

AI 리뷰어와 테스트 도구

혼자 개발해도 검증은 필요했습니다.
그래서 AI 리뷰어를 적극적으로 활용했고, Storybook, Playwright, Vitest 같은 도구를 함께 두어 기본 품질을 사람 기억에만 의존하지 않도록 만들었습니다.

5. 왜 develop과 main을 나눴는가

이 프로젝트는 실제 운영 서비스이기 때문에, QA를 운영 데이터와 섞어서 진행하는 것이 위험했습니다.
특히 리크루팅 서비스는 실제 지원 데이터와 운영 정보가 얽혀 있기 때문에, 잘못된 테스트가 바로 데이터 훼손으로 이어질 수 있습니다.

그래서 develop과 main을 분리했습니다.

• develop: 서버 테스트, 프론트 테스트, QA
• main: 운영 반영

또 AWS Amplify를 사용하면서 배포 상태를 GitHub 기준으로 더 명확히 확인하고 싶어 GitHub Actions도 함께 구성했습니다.

이 경험을 통해 QA 환경 분리와 데이터 보호 전략도 제품 품질의 일부라는 점을 명확히 배웠습니다.

6. 이 프로젝트가 남긴 것

UMC Product Web을 하며 가장 크게 배운 것은, 규모가 커질수록 화면 구현보다 예외 케이스와 운영 기준 설계가 더 중요해진다는 점이었습니다.

• 큰 서비스일수록 흐름 간 의존성을 먼저 봐야 한다.
• 단독 개발일수록 리뷰 체계와 문서화를 더 의식적으로 만들어야 한다.
• 운영 서비스는 QA 구조와 데이터 보호 전략까지 포함해서 설계해야 한다.
• 인수인계와 협업 피드백 구조를 초기에 만들면 유지보수가 훨씬 쉬워진다.

이 프로젝트는 "백오피스를 만들었다"보다,
"실제 운영 서비스가 버틸 수 있는 프론트엔드 구조를 어떻게 세워야 하는가"를 실전으로 배운 경험이었습니다.