1차 MVP 백오피스 기능 리딩 회고

들어가기 전에

2025년 10월부터 스노로즈 운영관리 도구(백오피스) TF를 리딩하며 프론트엔드 개발에 참여하고 있습니다. 그리고 2026년 1월, 1차 MVP 기능 개발까지 마무리할 수 있었어요.

이번 글에서는 백오피스 TF가 어떤 방식으로 협업했고, 어떤 흐름으로 개발을 진행했는지 정리하며 회고를 남겨보려고 합니다.

---

백오피스 기능 개발 계기

스노로즈 운영기획팀은 게시글·댓글 관리, 포인트 지급, 푸시 알림 발송 등 다양한 운영 업무를 맡고 있습니다. 그런데 별도의 백오피이스 기능이 없다 보니, 개발 경험이 거의 없는 운영기획팀원들도 Postman을 직접 사용해 API를 호출해야 하는 구조로 운영되고 있었어요.

이런 방식으로 운영하다 보니 여러 불편한 점들이 있었습니다.

• 비개발자 13명이 Postman 사용법을 익혀야 하는 학습 부담
• 요청 처리 결과를 실시간으로 확인하기 어려운 환경

운영 효율을 높이고 실수를 줄이기 위해, 내부적으로 백오피스 TF팀을 별도로 구성해 운영 환경 자체를 개선하기로 했습니다.

백오피스 기능 TF 진행

TF 팀은 다음과 같은 구성으로 운영되었어요.

• 개발팀: 프론트엔드 3명, 백엔드 3명
• 운영기획팀: 운영관리 파트 1명, 이벤트 파트 2명

총 9명이 함께 참여했고, 저는 프론트엔드 개발자로 참여했습니다.

초기에는 운영기획팀에서 필요 기능을 정리했고, 이를 기반으로 논의를 거쳐 요구사항을 확정했습니다. 이 초기 기획 단계가 약 4개월 정도 소요되어 예상보다 시간이 길어지기도 했어요.

초기 기획이 마무리되고 개발 단계로 넘어가는 시점에 있던 회의에서, 운영기획 업무 경험이 있는 제가 팀원들의 추천을 받아 백오피스 TF 리딩을 맡게 되었습니다.

우선 순위 결정 및 기능 개발

요구된 기능들은 다양했고, 그중에는 이미 API가 개발되어 있는 것도 있었습니다. 그래서 본격적인 개발에 들어가기 전에 먼저 우선순위를 정리하는 과정이 필요했어요.

1. 운영기획팀에서 자주 사용하는 기능, 가장 필요하다고 느끼는 기능을 우선 목록으로 작성
2. 각 기능별 API 존재 여부 확인
3. API가 있다면 → 프론트엔드 개발 먼저 진행
4. API가 없다면 → 백엔드 개발 후 프론트엔드 개발 진행

백오피스는 신규 프로젝트였고, 일부 기능은 완성되는 즉시 운영에 바로 적용할 수 있었기 때문에, 전체 기능을 한 번에 완성하기보다 작은 단위로 나누어 빠르게 개발·반영하는 방식이 더 적합하다고 판단했습니다.

이 방식이 필요했던 이유는 다음과 같아요.

• 완전히 처음 시작하는 신규 프로젝트라는 상황
• 일부 기능은 빠르게 완성해 운영에 바로 적용할 수 있다는 특성
• 운영기획팀의 피드백을 바로 반영하며 작은 단위로 개발·배포하기 좋은 구조

이런 특성을 고려해, 자연스럽게 애자일 방식에 가까운 흐름으로 개발이 진행되었습니다.

1차 MVP 기능에서의 목표

1차 MVP에서 가장 중요하게 둔 목표는 우선순위 기능을 기한 안에 완성하는 것이었습니다.

2025년에 스노로즈 내부에서 목표했던 기능의 약 50% 정도만 완성할 수 있었는데, 이는 학부생 중심 팀의 기술적 난이도, 학업·취업 준비 병행 등 여러 상황 때문에 개발 속도가 일정하게 유지되기 어려웠기 때문이에요.

하지만 백오피스의 1차 MVP 작업 이후에는 기능 개발 범위가 현재의 2~3배 이상 확대될 예정이었기 때문에 초반 일정이 밀리지 않도록 관리가 필요하다고 판단했습니다.

또, 프로젝트 경험을 돌아보면 팀 내에서 특정 인원만 계속 작업하는 분위기가 형성되면 전체 흐름이 금방 무너지는 경우가 많아요. 이번 TF에서는 그런 상황을 최대한 만들지 않기 위해 책임 범위와 일정 관리를 명확하게 유지하는 데 더욱 신경을 썼습니다.

프론트엔드 쪽은 특히 제 몫을 조금 더 가져가면서 개발 흐름이 끊기지 않도록 유지했습니다.

백오피스 TF 리딩 과정에서의 고민

TF를 리딩하면서 가장 신경 쓰였던 부분은 비개발자인 운영기획팀과의 소통이었어요. 회의나 논의에서 의견을 모으는 과정이 쉽지 않았고, 운영기획팀이 적극적으로 의견을 내기 어려워하는 모습도 종종 보였습니다.

프론트엔드와 백엔드는 서로 협업에 익숙하지만, 운영기획팀은 개발 용어나 프로세스 자체가 낯선 환경에서 논의를 이어가야 했기 때문에 어려움이 있을 수밖에 없었다고 생각합니다. 기본적인 개발 용어조차 생소한 상태에서 기능 명세를 이야기하거나 판단을 내려야 했고, 이런 부분이 자연스럽게 부담으로 이어졌던 것 같아요.

저는 최대한 쉽게 설명하려고 노력했지만, 이 과정 역시 쉽지는 않았습니다. 그렇다고 넘어갈 수도 없어서 운영기획팀과 따로 이야기를 나눈 적이 있는데, 그때 들은 솔직한 이야기가 “잘 몰라서 그랬다”는 말이었어요.

그 후 운영기획팀의 다른 팀원과도 이야기를 이어가며, 협업에서 발생하는 간극을 줄이기 위한 방법을 함께 고민했습니다. 그 과정에서, 운영기획팀이 기본적인 개발 용어와 흐름만 조금 더 익히고, 개발팀은 가능한 한 쉽게 설명하는 방향으로 접근한다면 협업이 훨씬 수월해질 거라는 결론을 함께 내렸어요.

그래서 협업 가이드라인 문서를 만들자는 의견이 나왔고, 현재 개발 경험이 있는 운영기획팀원들과 함께 준비 중입니다. 이 문서에는 기능 개발의 전체 흐름, 회의 과정에서 자주 나오는 용어, 소통 방식 등을 정리하려고 합니다. 이런 준비가 향후 협업에서 작은 기반이 되었으면 하는 마음이에요.

---

마치며

1차 MVP 기간 동안에는 기술적인 부분보다 소통과 협업 방식을 고민하는 시간이 더 많았던 시기였어요. 쉽지 않은 과정이었지만, 꼭 필요하다고 느낀 부분이고 앞으로도 계속 다듬어가야 할 영역이라고 생각합니다.

백오피스는 이제 시작 단계이고 앞으로 더 많은 기능과 협업이 이어질 텐데, 이번 경험이 다음 단계를 준비하는 데 작은 발판이 되기를 바라고 있어요. 💪