프로젝트 진행 방식
PoC부터 운영까지 진행 방식
프로젝트가 어디서 지연되는지 대개 예측할 수 있습니다. 요구사항이 확정되지 않은 채 개발이 시작될 때, 또는 연동 심사 일정이 반영되지 않았을 때입니다.
단계 한눈에 보기
다섯 단계, 두 번의 검토 지점
이 페이지는 저희가 어떤 단계와 검토 지점을 거치는지 설명합니다. 일정 감각을 가늠할 수 있게 단계별로 정리했습니다.
각 단계는 앞 단계의 산출물 위에서 시작합니다. 범위 문서 없이 PoC를 시작하거나, 검토 지점을 건너뛰고 출시를 준비하면 뒤에서 되돌아오는 비용이 커집니다.
- 1 상황 확인과 범위 설정 — 산출물: 범위 문서
- 2 PoC로 가설 검증 — 산출물: 성공 기준과 검증 결과
- 3 MVP와 검토 지점 — 첫 화면 완성 시점, 주요 연동 시점
- 4 출시 준비 — 규제 대응 문서와 운영 환경
- 5 운영과 개선 — 지표 확인과 주기 점검
1단계
상황 확인과 범위 설정
첫 미팅에서 확인하는 것은 기능 목록이 아닙니다. 현재 시스템이 어디에 있고, 데이터가 어떤 상태이며, 누가 운영할 것인지입니다. 이 세 가지가 정해지지 않으면 어떤 기능을 만들지도 정할 수 없습니다.
이 단계에서 나오는 산출물은 범위 문서입니다. 무엇을 하고 무엇을 하지 않는지 명시합니다. 이게 없으면 프로젝트 중간에 범위가 계속 늘어납니다. 늘어난 범위는 일정과 비용 양쪽에 남습니다.
기존 시스템과의 통합 범위도 여기서 함께 그립니다. 어디까지 붙이고 어디부터 새로 만들지에 따라 이후 단계의 난이도가 달라집니다.
2단계
PoC로 가설 검증
PoC는 작은 범위로 기술적 가설을 확인하는 단계입니다. 전체 기능을 만드는 것이 목표가 아닙니다. 화면은 거칠어도 되고, 확인하려는 항목만 동작하면 충분합니다.
이 판단이 뒤로 갈수록 비싸지기 때문에 PoC를 먼저 합니다. MVP 단계에서 방향이 바뀌면 이미 만든 화면과 데이터 구조를 다시 손봐야 합니다.
성공 기준을 숫자로 정합니다
- 검색 정확도
- 테스트 질의 집합에서 원하는 결과가 상위에 오는지 확인합니다.
- 응답 시간
- 사용자가 기다릴 수 있는 범위 안에 들어오는지 봅니다.
- 처리량
- 예상 사용량을 감당할 수 있는지 부하를 걸어 확인합니다.
기준을 통과하지 못하면 원인을 고치거나 방향을 바꿉니다. 어느 쪽이든 PoC 단계에서 결정하는 편이 훨씬 저렴합니다.
3단계
MVP와 검토 지점
PoC가 통과하면 MVP로 확장합니다. 이 단계에서는 실제 사용자가 쓸 수 있는 최소 기능을 만듭니다. 기능을 더 얹는 것보다 흐름이 끊기지 않는지 확인하는 일이 먼저입니다.
첫 번째 검토 지점
첫 화면이 완성될 때
실제 사용 흐름을 확인합니다. 진입부터 목표 행동까지 몇 번의 클릭이 필요한지, 어디서 멈추는지 봅니다.
두 번째 검토 지점
주요 연동이 붙을 때
실제 환경에서 동작하는지 확인합니다. 한국 서비스는 카카오·네이버 연동 심사가 일정에 영향을 주므로 이 시점에 반드시 반영합니다.
4단계
출시 준비
출시 전에 확인하는 항목은 기능이 아닙니다. 개인정보 처리방침, 위치정보 고지, 결제 관련 안내처럼 규제 대응 문서입니다. 심사에서 걸리는 항목은 대부분 이쪽입니다.
운영 환경도 함께 준비합니다. 로그 수집, 알림, 장애 대응 절차, 자동 확장 설정이 포함됩니다. 이 준비가 없으면 출시 직후 대응이 늦어집니다.
5단계
운영과 개선
출시 후에는 지표를 봅니다. 어떤 기능이 쓰이고 어디서 이탈하는지 확인하고 조정합니다. 출시는 끝이 아니라 운영 주기의 시작입니다.
AI 기능이 포함된 경우 인덱스 갱신, 프롬프트 점검, 모델 재검토 주기를 함께 정합니다. 운영 부담을 미리 계산하지 않으면 초기 성공이 오래가지 않습니다.
로그 수집, 알림, 장애 대응 절차는 출시 전에 정해 둡니다. 출시 이후에 만들면 첫 장애에서 시간을 잃습니다.
일정에 영향을 주는 변수
이 네 가지가 일정을 좌우합니다. 기능 수보다 영향이 큰 경우가 많습니다. 상담 단계에서 이 항목들을 먼저 확인하는 이유입니다.
외부 연동 심사 소요 시간
심사는 저희가 단축할 수 없는 대기 시간입니다. 제출 자료를 미리 준비해 두는 것만으로도 일정이 앞당겨집니다.
데이터 정리 상태
정리되지 않은 데이터는 개발보다 이관 작업에 시간을 씁니다. 시작 전에 상태를 확인하면 규모를 가늠할 수 있습니다.
기존 시스템과의 통합 범위
붙이는 대상이 많을수록 검증할 조합이 늘어납니다. 범위 문서에서 이 경계를 명확히 남깁니다.
의사결정이 필요한 시점의 피드백 속도
검토 지점에서 결정이 늦어지면 다음 단계 전체가 밀립니다. 결정이 필요한 시점을 미리 공유합니다.
협업 방식
저희는 주 단위로 진행 상황을 공유합니다. 문서와 코드를 함께 관리하고, 결정 사항은 기록으로 남깁니다. 회의에서 정한 내용이 다음 주에 다시 논의되지 않도록 하는 것이 목적입니다.
고객사 담당자가 바뀌어도 이어받을 수 있는 상태를 목표로 합니다. 이게 인수인계를 가능하게 하는 조건입니다. 담당자 개인의 기억에 기대는 구조는 오래가지 않습니다.
프로젝트가 끝난 뒤
인수인계 문서, 배포 절차서, 운영 매뉴얼을 남깁니다. 사내 개발팀이 이어받거나, 이후 유지보수를 다른 곳에 맡길 수 있는 상태를 만듭니다.
외주 의존 구조를 만들지 않는 것이 원칙입니다.
기술 스택 가이드 보기주간 공유는 문서로 남기 때문에, 진행 상황을 확인하려고 별도로 연락을 주고받을 필요가 줄어듭니다.
PoC 없이 바로 개발을 시작할 수 있나요?
요구사항이 명확하고 기술적 불확실성이 낮으면 가능합니다. 반대로 AI 기능이나 새 연동이 포함되면 PoC를 먼저 권합니다. 검증 없이 진행하면 나중에 재작업 비용이 커집니다.
MVP는 얼마나 걸리나요?
범위에 따라 다릅니다. 연동 심사가 필요한 경우 그 시간이 일정에 포함됩니다. 시작 전에 범위 문서로 기준을 맞추는 것이 지연을 줄이는 방법입니다.
유지보수도 맡길 수 있나요?
가능합니다. 다만 사내에서 운영할 계획이라면 인수인계 문서와 운영 매뉴얼을 함께 제공합니다. 어느 쪽이든 이어받을 수 있는 상태를 만드는 것이 목표입니다.
