Praxent · 개발 프로세스
아이디어에서 MVP까지의 과정
요구사항 정리, 설계, 개발, 검증, 운영의 다섯 단계로 일하고 각 단계 끝에 확인 지점을 둡니다. 무엇을 만들지보다 무엇을 풀려는지부터 확인합니다.
다섯 단계, 다섯 번의 확인
모든 프로젝트가 같은 기간을 쓰지는 않습니다. 순서는 비슷하고, 각 단계 끝에서 멈춰 확인한 뒤 다음으로 넘어갑니다. 아래 목록은 그 흐름을 순서대로 정리한 것입니다.
- 요구사항 정리 — 범위 정의서와 우선순위 목록
- 설계와 UX/UI — 화면 흐름과 데이터 구조
- 기술 스택 결정 — 조건을 보고 고르는 기준
- 개발과 주 단위 공유 — 매주 문서로 남기는 결정
- 검증 지점과 출시 준비 — 멈춰 확인하는 자리
요구사항 정리
첫 단계는 무엇을 만들지 정하는 게 아니라 무엇을 풀려는지 확인하는 일입니다. 인터뷰로 현재 절차와 불편한 지점을 뽑아냅니다. 문서에 적힌 절차와 실제로 돌아가는 절차가 다른 경우가 많아서, 현업 담당자와 직접 이야기합니다.
이 단계의 산출물은 범위 정의서와 우선순위 목록입니다. 여기서 합의되지 않은 항목은 이후에 다시 논의됩니다. 목록에서 빠진 요구는 나중에 일정과 비용을 다시 흔들기 때문에, 처음부터 전부 적어 두고 순서를 정합니다.
- 인터뷰 대상
- 현업 담당자, 운영 인력, 의사결정자
- 확인하는 것
- 현재 절차, 예외 처리, 손이 많이 가는 구간
- 산출물
- 범위 정의서, 우선순위 목록
- 확인 지점
- 범위 합의, 이후 변경 시 재논의
설계와 UX/UI
범위가 정해지면 화면 흐름과 데이터 구조를 설계합니다. UX/UI 디자인은 보기 좋은 화면을 만드는 일이 아니라 사용자가 어디서 막히는지 줄이는 작업입니다. 이 단계에서 데이터가 어디서 오고 어디로 가는지도 함께 그립니다.
외부 시스템 연동이 있으면 여기서 확인합니다. 결제, 인증, 사내 시스템처럼 프로젝트 밖에 있는 요소가 흐름을 바꾸기 때문입니다. 설계가 흔들리면 개발 중에 변경이 반복되므로, 이 단계의 도면을 기준으로 이후 작업을 맞춥니다.
확인 지점을 일정에 미리 넣어 둡니다. 늦게 발견된 문제일수록 고치는 값이 커지기 때문입니다.
요구사항 단계
범위 합의 — 합의되지 않은 항목은 다시 논의
설계 단계
흐름 검토 — 막히는 지점과 연동 지점 확인
출시 전
테스트 결과 확인 — 이슈 목록과 대응 담당자 확정
기술 스택 결정
스택은 프로젝트 조건을 보고 정합니다. 유행하는 기술을 먼저 정하지 않고, 아래 항목을 확인한 뒤 프레임워크와 호스팅 방식을 고릅니다. 웹 개발, 모바일 앱, 핀테크 소프트웨어, AI 솔루션은 요구 조건이 서로 달라서 같은 조합을 반복하지 않습니다.
| 확인 항목 | 왜 보는가 | 남기는 결정 |
|---|---|---|
| 팀 규모 | 여러 사람이 동시에 손대는 범위가 정해집니다. | 저장소 구조와 배포 흐름 |
| 배포 주기 | 자주 내보낼수록 자동화와 검증 비중이 올라갑니다. | 빌드·배포 파이프라인 방식 |
| 기존 시스템 연결 | 연동 방식이 프레임워크 선택을 제한합니다. | 연동 인터페이스와 데이터 흐름 |
| 운영 인력 숙련도 | 출시 후 누가 고치는지에 따라 난이도가 달라집니다. | 운영 문서와 인수인계 범위 |
| 앱 배포 형태 | 모바일 앱이면 스토어 심사와 업데이트 주기가 변수입니다. | 크로스플랫폼 또는 네이티브 |
크로스플랫폼과 네이티브 중 어느 쪽으로 갈지도 이 단계에서 문서로 남깁니다. 나중에 바꾸면 비용이 커집니다.
개발과 주 단위 공유
개발은 짧은 주기로 나눠 진행하고, 매주 진행 상황과 결정 사항을 공유합니다. 회의록이 아니라 문서로 남깁니다. 시간대가 겹치지 않는 팀과 일할 때 특히 이 방식이 유용합니다.
중간에 범위를 바꾸게 되면 일정과 비용에 미치는 영향을 함께 정리합니다. 조용히 넘어가지 않고, 무엇이 밀리고 무엇이 대체되는지 같은 문서에 적습니다.
사례 살펴보기-
매주 공유되는 것
이번 주에 끝난 작업, 다음 주 계획, 막힌 지점
-
남는 형태
결정 사항과 근거를 적은 문서, 화면 시연 기록
-
범위 변경 시
일정과 비용 영향 정리 후 재합의
-
적합한 상황
시간대가 어긋나 비동기 소통이 필요한 팀
검증 지점
각 단계 끝에 확인 지점을 둡니다. 이 지점에서 멈추고 확인하지 않으면 문제가 다음 단계로 넘어갑니다. 늦게 발견된 문제일수록 수정 비용이 커지므로 일정에 이 시간을 미리 넣어 둡니다.
- 요구사항 단계
- 범위 합의 — 목록에 없는 요구는 다음 회의에서 다시 다룹니다.
- 설계 단계
- 흐름 검토 — 사용자가 막히는 지점과 연동 지점을 함께 확인합니다.
- 개발 중
- 기능 시연 — 매주 동작하는 화면을 보고 판단합니다.
- 출시 전
- 테스트 결과 확인 — 남은 이슈와 대응 담당자를 확정합니다.
프로토타입, MVP, 본개발
세 단어는 목적이 다릅니다. 경계를 흐리면 프로토타입 코드가 운영까지 살아남아 부채가 됩니다.
프로토타입
가설이 성립하는지 확인하는 단계입니다. 버려질 것을 전제로 만들기 때문에 화면과 흐름만 확인하고, 운영에 남기지 않습니다.
목적 — 아이디어 검증
MVP
실제 사용자에게 열어 두고 쓰이는 최소 범위입니다. 운영에 남고, 사용 기록을 보고 다음 순서를 정합니다.
목적 — 실제 사용 검증
본개발
그 위에 확장과 안정화, 운영 체계를 얹는 작업입니다. 기능 추가보다 구조를 정리하는 비중이 커집니다.
목적 — 확장과 안정화
출시 준비
출시 직전에는 배포 방법, 환경 설정, 장애 대응 절차를 정리합니다. 모니터링과 알림 기준도 이때 정합니다. 이 준비를 마치지 않으면 출시 이후 문제가 생겼을 때 대응이 늦어집니다.
- 배포 방법과 환경 설정값 정리
- 장애 대응 절차와 연락 순서 확정
- 모니터링과 알림 기준 설정
- 인수인계 문서 갱신과 담당자 확정
앱이라면 스토어 심사 대응이 추가됩니다. 심사에서 자주 걸리는 항목을 미리 확인하고 제출 순서를 정합니다.
운영과 개선
출시는 끝이 아닙니다. 실제 사용 기록을 보고 개선 우선순위를 다시 정합니다.
성능 문제
응답이 느려진 구간을 찾아 원인부터 확인합니다.
사용 흐름 이탈
어느 화면에서 멈추는지 보고 문구와 순서를 다시 봅니다.
오류 로그
반복되는 오류를 묶어 우선순위를 정합니다.
정기 점검
점검 주기와 담당자를 정해 두면 대응이 빨라집니다.
프로젝트 기간은 어떻게 정하나요?
요구사항 정리 단계에서 범위와 우선순위를 확정한 뒤 일정을 잡습니다. 모든 프로젝트가 같은 기간을 쓰지는 않으며, 확인 지점에 필요한 시간을 일정에 먼저 넣고 개발 기간을 그 뒤에 맞춥니다.
프로토타입을 꼭 만들어야 하나요?
가설을 먼저 확인할 필요가 있을 때 만듭니다. 이미 검증된 흐름이라면 설계 단계에서 바로 MVP 범위로 넘어갈 수 있습니다. 어느 쪽이든 프로토타입 코드를 운영까지 끌고 가지 않는 것을 기준으로 삼습니다.
모바일 앱과 웹을 함께 만들 수 있나요?
가능합니다. 기술 스택 결정 단계에서 크로스플랫폼과 네이티브 중 어느 쪽으로 갈지, 서버와 데이터 구조를 어떻게 공유할지 함께 정합니다. 기존 시스템과 연결해야 한다면 연동 방식을 이 단계에서 확인합니다.
개발 중에 범위를 바꾸면 어떻게 되나요?
일정과 비용에 미치는 영향을 함께 정리해 문서로 공유합니다. 무엇이 밀리고 무엇이 대체되는지 같은 문서에 적고, 확인 지점에서 다시 합의한 뒤 진행합니다.
출시 후에는 무엇을 지원하나요?
운영 단계에서 성능 문제, 사용 흐름 이탈, 오류 로그를 확인하고 개선 우선순위를 다시 정합니다. 신규 기능은 실제 사용 기록을 근거로 순서를 정하며, 정기 점검 주기와 담당자를 함께 정해 둡니다.
다음 단계로
지금 풀려는 문제를 정리해 보내주시면, 인터뷰와 범위 정리부터 함께 시작합니다. 상담은 프로젝트 진행 조건을 확인하는 자리이며, 계약 전 단계에서 비용은 발생하지 않습니다.
문의처
- 주소
- 4330 Gaines Ranch Lp, Ste 230, Austin, TX 78735, USA
- 상담 가능 시간
- 월요일–금요일, 오전 9시 – 오후 6시 (미국 중부 표준시)