진행 프로세스 · 판교 242
디스커버리부터 유지보수까지 협업 절차
프로젝트는 여섯 단계로 진행됩니다. 범위가 작으면 몇 단계를 합쳐서 진행하기도 합니다. 각 단계에서 누가 무엇을 하는지, 어떤 문서가 남는지 정리했습니다.
단계별 산출물 먼저 보기여섯 단계
한 번의 인쇄처럼, 같은 흐름을 단계마다 다시 확인합니다
모든 프로젝트가 같은 무게로 진행되지는 않습니다. 신규 출시는 기획과 프로토타이핑에 시간을 더 쓰고, 기존 시스템 개편은 디스커버리에서 현재 구조를 먼저 읽는 데 시간을 씁니다. 아래 여섯 단계는 순서를 지키되, 범위에 따라 겹치거나 합쳐질 수 있습니다.
프로젝트 상담 신청하기디스커버리
지금 무엇이 막혀 있는지 확인하는 단계입니다. 기능 목록보다 문제를 먼저 봅니다. 신규 출시인지, 기존 시스템 개선인지, 사내 업무 자동화인지에 따라 이후 방향이 달라집니다. 이 단계의 결과물은 요구사항 정리 문서입니다.
제품 기획
누가 어떤 빈도로 이 기능을 쓰는지 정의합니다. 화면 단위가 아니라 사용자 흐름 단위로 정리합니다. 실제로 안 쓰일 기능을 걸러내는 작업도 여기서 합니다. 결과물은 기능 정의서와 우선순위 목록입니다.
프로토타이핑
핵심 흐름을 클릭 가능한 수준으로 만들어 확인합니다. 사용자가 어디서 헤매는지 몇 번의 테스트로 드러납니다. 이 단계에서 방향을 고치면 개발 단계에서 고치는 것보다 손실이 적습니다. 프로토타입은 이후 개발의 기준점으로 남습니다.
개발
설계를 실제 코드로 옮기는 단계입니다. 프론트엔드와 백엔드 작업이 병행되고, 기존 시스템 연동이 있으면 API 명세를 기준으로 맞춥니다. 주 단위로 진행 상황을 공유하고, 범위 변경이 생기면 일정에 미치는 영향을 함께 정리합니다. 결과물은 소스 코드와 배포 환경입니다.
출시
배포와 안정화 단계입니다. 앱은 스토어 심사 대응이, 웹은 배포 환경 점검이 포함됩니다. 출시 직후에는 오류 모니터링과 사용 흐름 확인을 집중적으로 봅니다. 초기 반응을 보고 다음 릴리스 범위를 정합니다.
유지보수
서버 모니터링, 보안 패치, 라이브러리 업데이트, 장애 대응이 기본입니다. 신규 기능 개발을 포함할 수도 있습니다. 범위는 프로젝트마다 다르게 정합니다. 담당자와 연락 채널을 명확히 두고 시작합니다.
설계 리뷰는 같은 자리에서 끝냅니다
주 단위 진행 공유를 기본으로 하되, 여러 결정을 한 번에 맞춰야 하는 단계에서는 판교 사무실에서 대면 미팅을 병행합니다. 이슈는 문서로 남겨 이력이 추적되게 합니다. 회의가 끝나면 남는 것은 결정 사항과 다음 주에 확인할 목록입니다.
단계별 산출물
각 단계에서 남는 문서
디스커버리
요구사항 정리 문서. 지금 막혀 있는 지점과 이번 프로젝트가 건드릴 범위를 한 문서에 모읍니다.
제품 기획
기능 정의서와 우선순위 목록. 누가 어떤 빈도로 쓰는지, 이번 릴리스에서 무엇을 미룰지 함께 적습니다.
프로토타이핑 · 개발
클릭 가능한 프로토타입, 소스 코드, 배포 환경, 운영 문서. 출시 이후 담당자가 혼자서도 확인할 수 있게 정리합니다.
일정과 범위
촉박할 때는 기능을 줄이는 대신 1차 출시 범위를 좁힙니다
품질을 낮추는 방식은 나중에 더 큰 비용으로 돌아옵니다. 우선순위를 나눠 1차와 2차 릴리스로 쪼개면 시장 반응을 보고 다음 투자를 결정할 수 있습니다. 무엇을 1차에 넣을지는 제품 기획 단계에서 정한 우선순위 목록을 기준으로 다시 확인합니다.
신규 서비스
제품 기획과 프로토타이핑 비중이 큽니다. 시장에 처음 나가는 제품은 무엇을 먼저 보여줄지 정하는 일이 개발보다 앞섭니다.
기존 개편
디스커버리와 정보 설계 비중이 큽니다. 지금 쓰이는 화면과 데이터 구조를 먼저 읽고, 옮길 것과 버릴 것을 나눕니다.
사내 자동화
업무 흐름 정리와 데이터 점검이 먼저입니다. 어떤 입력이 어디로 흘러가는지 확인한 뒤에 도구를 고릅니다.
출시 직후가 가장 바쁩니다
앱은 스토어 심사 대응이, 웹은 배포 환경 점검이 함께 갑니다. 배포가 끝나면 오류 모니터링과 사용 흐름 확인을 집중적으로 봅니다. 초기 반응을 보고 다음 릴리스 범위를 정합니다.
자주 나오는 질문
프로젝트 기간은 어떻게 정해지나요? +
범위와 기간에 따라 결정됩니다. 1차 출시 범위를 좁히면 초기 투입을 줄일 수 있어, 우선순위를 나눠 릴리스를 쪼개는 방식을 자주 씁니다.
기획 없이 개발만 맡길 수 있나요? +
가능합니다. 다만 요구사항이 정리되어 있지 않으면 개발 중 범위 변경이 잦아질 수 있어, 짧은 디스커버리 단계를 먼저 두는 편을 권합니다.
유지보수 범위는 어떻게 정하나요? +
서버 모니터링, 보안 패치, 라이브러리 업데이트, 장애 대응이 기본이고 신규 기능 개발을 포함할 수도 있습니다. 담당자와 연락 채널을 명확히 두고 시작하며, 범위는 프로젝트마다 다르게 정합니다.
다음 단계로 넘어가는 방법
지금 막혀 있는 지점을 알려주시면 어느 단계부터 시작할지 함께 정리합니다. 서비스 범위와 지금까지 진행한 프로젝트를 먼저 살펴보시면 상담이 더 빠릅니다.