개발 프로세스
기획부터 운영까지 어떻게 진행되나
프로젝트를 맡기기 전에 가장 궁금한 것은 일정과 역할입니다. 이 페이지는 우마미돔 디지털이 기획, 디자인, 개발, 배포, 운영을 어떤 순서로 진행하고 각 단계에서 무엇을 확인하는지 정리한 것입니다.
착수 전 정리
바로 개발에 들어가지 않습니다. 먼저 목표와 현재 상황을 정리합니다. 기존 시스템이 있다면 무엇이 불편한지, 새로 만든다면 어떤 사용자가 어떤 일을 하게 되는지를 확인합니다.
이 단계에서 확정되지 않은 항목은 별도로 표시해 둡니다. 나중에 일정이 흔들리는 원인이 대부분 여기서 나옵니다. 기존 운영 방식과 인력 구성까지 함께 보는 이유도 같은 맥락입니다. 새 시스템을 누가 매일 쓰게 되는지 모르는 채로 화면부터 그리면, 출시 후에 다시 손대는 일이 생깁니다.
- 확인하는 것
- 현재 불편한 지점, 사용자와 역할, 기존 시스템 제약
- 남기는 것
- 확정된 항목과 아직 정해지지 않은 항목의 구분
기획과 범위 확정
정리한 내용을 기능 단위로 나눕니다. 각 기능이 누구를 위한 것인지, 언제 필요한지를 함께 봅니다. 첫 버전에 넣을 것과 나중으로 미룰 것을 구분합니다. 이 구분이 명확해야 이후 단계에서 방향이 바뀌지 않습니다.
- 기능 목록 무엇을 만들지, 누가 쓰는지를 한 줄씩 적어 확인합니다.
- 우선순위 첫 버전에 넣을 것과 다음으로 미룰 것을 나눕니다.
- 단계 구분 어느 시점에 무엇이 완료되어야 하는지 대략의 순서를 잡습니다.
- 외부 연동 여부 결제, 인증, 알림처럼 바깥 시스템과 붙는 항목을 미리 표시합니다.
- 결과물 정리 기능 목록, 우선순위, 단계 구분을 문서 한 벌로 남깁니다.
이 단계의 결과물은 화려하지 않습니다. 대신 이후 디자인과 개발에서 무엇을 다시 물어봐야 하는지를 줄여 줍니다. 범위가 흔들리면 일정도 같이 흔들리기 때문에, 여기서 합의한 목록을 기준으로 다음 단계를 진행합니다.
UI/UX 설계
사용자가 목적을 빨리 달성하도록 화면 흐름을 잡습니다. 예쁜 화면보다 어디서 막히는지가 먼저입니다. 주요 흐름을 화면 단위로 정리하고, 반복해서 쓰이는 요소는 컴포넌트 기준을 정합니다. 반응형 대응 범위도 이 단계에서 확정합니다.
화면 흐름 설계
가입, 주문, 조회처럼 자주 쓰는 경로를 화면 단위로 나눠 확인합니다. 어느 화면에서 이탈이 생기는지 먼저 짚습니다.
컴포넌트 기준
버튼, 입력 필드, 목록처럼 반복되는 요소의 상태와 간격을 정해 두면 개발 단계에서 화면마다 달라지는 일이 줄어듭니다.
반응형 범위
데스크톱, 태블릿, 모바일 중 어디까지 맞출지 이 단계에서 정합니다. 범위가 늦게 정해지면 개발 막바지에 일정이 몰립니다.
운영자 화면
고객이 보는 화면과 관리자가 쓰는 화면은 요구가 다릅니다. 목록, 검색, 권한처럼 실제 운영에서 자주 쓰는 동선을 함께 그립니다.
결과물은 화면 설계와 컴포넌트 기준입니다. 디자인이 확정되지 않은 채 개발을 시작하면 같은 화면을 두 번 만드는 일이 생기므로, 이 단계에서 확인할 시점을 미리 잡아 둡니다.
개발
프론트엔드와 백엔드를 나눠 진행하되, API 구조를 먼저 정하고 시작합니다. 웹과 앱을 함께 만드는 경우에도 같은 API를 씁니다. 운영자용 백오피스는 고객 화면과 별도로 설계합니다.
진행 상황은 주 단위로 공유하고, 확인 가능한 상태로 보여드립니다. 화면만 보여주는 대신 실제로 동작하는 환경에서 확인하실 수 있게 준비합니다. 웹 개발과 모바일 앱 개발을 병행하는 프로젝트라면 어느 쪽을 먼저 오픈할지도 이 시점에 정합니다.
- 공유 주기
- 주 단위 진행 공유, 확인 가능한 상태로 시연
- 먼저 정하는 것
- API 구조, 백오피스 범위, 오픈 순서
배포와 CI/CD
배포를 수동으로 반복하면 실수가 생깁니다. CI/CD 파이프라인을 세팅하면 배포가 정해진 절차가 되고, 문제가 생겼을 때 이전 상태로 되돌리기 쉬워집니다.
국내 기업용 프로젝트에서도 배포, 유지보수, 장애 대응을 함께 묶어 다루는 흐름이 일반적입니다. 배포 환경과 운영 환경을 분리하는 것도 이 단계에서 정합니다. 테스트 서버에서 확인한 뒤에 운영에 반영하는 순서를 정해 두면, 급하게 고칠 때도 무엇이 바뀌었는지 추적할 수 있습니다.
운영과 유지보수
출시 후에 오류가 나고 기능이 추가됩니다. 이때 코드 구조와 배포 절차가 정리되어 있으면 대응이 빠릅니다. 장애가 발생했을 때 누가 어떻게 확인하고 어떤 기준으로 알릴지를 미리 정합니다.
운영 기간과 범위는 프로젝트마다 다르게 정합니다. 기능 추가만 이어가는 경우도 있고, 배포와 장애 대응까지 함께 맡는 경우도 있습니다. 내부 팀에 인계하는 경우에는 문서와 함께 이전합니다. 담당자가 바뀌어도 같은 절차로 이어갈 수 있게 정리해 두는 것이 목적입니다.
협업 방식
요구사항을 문서로만 주고받으면 놓치는 맥락이 생깁니다. 부산 센텀중앙로 사무실에서 대면 미팅이 가능하고, 기획 초반에는 직접 만나 이야기하는 편을 선호합니다. 이후 진행은 원격으로도 가능합니다.
확인이 필요한 시점을 미리 정해두면 양쪽 모두 일정을 잡기 쉬워집니다. 매주 같은 요일에 짧게라도 상태를 맞추는 방식이 오래 갑니다.
일정이 밀리는 이유
기간을 늘리는 요인은 개발 난이도보다 의사결정 속도인 경우가 많습니다. 기능 우선순위, 디자인 확정, 외부 연동(결제, 인증, 알림) 여부가 정해지지 않으면 착수 후에도 일정이 흔들립니다.
그래서 착수 전 체크리스트를 함께 정리합니다. 확정되지 않은 부분은 별도 단계로 분리해 전체 일정에 영향을 덜 주도록 합니다. 결정이 늦어질 항목을 미리 표시해 두면, 나머지 개발을 멈추지 않고 진행할 수 있습니다.
프로젝트 기간은 보통 어떻게 정하나요?
기능 범위와 외부 연동 여부에 따라 달라집니다. 착수 전에 우선순위를 정리하면 예측 가능한 일정이 나옵니다. 결제나 인증처럼 바깥 시스템과 붙는 항목이 있으면 그 부분의 확인 시간을 따로 잡아 둡니다.
진행 상황은 어떻게 확인하나요?
주 단위로 공유하고, 확인 가능한 상태로 보여드립니다. 필요한 시점을 미리 정해두면 일정 조율이 쉬워집니다. 화면 설계가 확정되는 시점, 첫 버전을 확인하는 시점처럼 미리 날짜를 잡아 두는 편입니다.
완료 후 운영도 맡길 수 있나요?
가능합니다. 배포와 장애 대응, 기능 추가를 이어서 진행할 수 있고, 내부 팀에 인계하는 방식도 선택할 수 있습니다. 인계를 원하시면 코드 구조와 배포 절차를 문서로 정리해 함께 넘깁니다.
일정과 역할부터 함께 정리해 보시죠
지금 만들려는 것이 정리되지 않은 상태여도 괜찮습니다. 무엇이 불편한지, 누가 쓰게 되는지부터 확인하면 다음 단계가 보입니다. 부산 사무실에서 대면으로, 또는 원격으로 상담이 가능합니다.