1단계: 상담과 범위 정리
첫 대화에서는 만들고 싶은 것보다 해결하려는 문제를 먼저 듣습니다. 지금 쓰는 시스템, 불편한 지점, 참고 사례, 예산과 일정 범위를 함께 확인합니다. 이 내용을 짧은 문서로 정리해서 다시 보내드리고, 양쪽이 같은 그림을 보고 있는지 확인합니다. 이 단계에서 범위가 흐리면 이후 모든 단계가 흔들립니다. 상담은 원격과 방문 모두 가능합니다.
고객 확인
정리된 범위 문서를 읽고 빠진 항목이 없는지 확인합니다.
프로젝트 접근 방식
기획부터 운영까지 프로젝트 진행 방식
프로젝트가 어긋나는 지점은 대부분 중간에 있습니다. 범위가 말로만 정해지고, 확인 없이 다음 단계로 넘어가고, 검수 기준이 없을 때입니다.
이 문서를 먼저 읽는 이유
견적과 일정은 결과물만 보고 정할 수 없습니다. 어떤 문제를 해결하려는지, 누가 승인하고 누가 사용하는지, 기존 시스템과 어디서 만나는지가 정해져야 숫자가 나옵니다. 그래서 뉴에라버드 디지털은 상담, 기획, 설계, 개발, 검수, 운영의 여섯 단계를 같은 순서로 진행하고, 각 단계마다 남는 문서를 기준으로 다음 단계로 넘어갑니다.
모든 단계를 고객이 직접 따라오실 필요는 없습니다. 다만 설계 승인과 검수 두 지점은 담당자가 직접 확인하시는 편이 좋습니다. 이 두 곳에서 잡히지 않은 문제는 오픈 이후에 더 큰 비용과 일정으로 돌아옵니다.
- 남는 산출물
- 범위 문서, 요구사항 정의서, 화면 목록, 시안, 중간 빌드
- 진행 공유 주기
- 개발 단계는 주 단위, 그 외 단계는 요청 시 수시 공유
- 상담 방식
- 원격 화상과 방문 상담 모두 가능, 평일 09:00–18:00
단계마다 남는 문서가 다음 단계의 기준이 됩니다. 구두로 합의한 내용은 기준이 되지 않습니다.
여섯 단계로 보는 진행 순서
아래 순서는 실제 프로젝트에서 진행되는 기본 흐름입니다. 프로젝트 규모에 따라 기획과 설계를 한 번에 묶어 진행하기도 하지만, 순서를 건너뛰지는 않습니다.
2단계: 기획과 요구사항 정의
정리된 범위를 기능 단위로 쪼갭니다. 사용자 유형, 주요 흐름, 필요한 화면, 외부 연동 대상이 여기서 나옵니다. 웹 포털이라면 고객 포털인지 내부 업무 포털인지에 따라 권한 구조가 완전히 달라지므로 이 시점에 확정합니다. 결과물은 요구사항 정의서와 화면 목록입니다. 이 문서에 없는 기능은 개발 범위에 들어가지 않는다는 원칙을 처음부터 정합니다.
고객 확인
화면 목록과 권한 구조가 실제 업무와 맞는지 확인합니다.
3단계: 설계와 프로토타입
화면 구조와 데이터 흐름을 설계합니다. 디자인 시안과 함께 실제로 눌러볼 수 있는 프로토타입을 만들어 확인합니다. 문서만 보고 판단하기 어려운 부분은 이 단계에서 드러납니다. 반응형 웹 디자인 기준, 접근성 요건, 터치 영역 같은 세부 규격도 여기서 정합니다. 시안 승인 이후에 구조를 바꾸면 작업이 두 배가 되므로, 이 단계에서 충분히 검토하는 편이 좋습니다.
고객 확인
시안과 프로토타입을 직접 눌러보고 승인 여부를 정합니다.
4단계: 개발과 중간 확인
프론트엔드와 백엔드를 나눠 진행하되, 일정한 주기로 확인 가능한 빌드를 공유합니다. 마지막에 한 번에 보여주는 방식은 위험합니다. 중간에 방향이 어긋나면 되돌리는 비용이 크기 때문입니다. AI 기능이 포함되면 데이터 준비 상태와 규제 검토 결과를 이 단계에서 함께 확인합니다. 진행 상황은 주 단위로 공유하는 것을 기본으로 합니다.
고객 확인
주 단위 중간 빌드에서 화면 동작과 연동 상태를 확인합니다.
5단계: 검수와 오픈
검수 기준은 기획 단계에서 정한 요구사항 정의서입니다. 여기에 없는 항목은 별도 협의 대상이 됩니다. 화면별 동작 확인, 권한별 접근 테스트, 오류 대응, 성능 확인을 거칩니다. 오픈 직전에는 백업과 롤백 계획을 준비합니다. 오픈 일정은 검수 결과에 따라 조정될 수 있고, 이 점은 계약 전에 미리 안내드립니다.
고객 확인
요구사항 대비 동작을 화면별로 확인하고 오픈을 승인합니다.
6단계: 운영과 개선
오픈 후에는 보안 업데이트, 백업 확인, 오류 대응, 기능 개선 요청을 처리합니다. 운영 방식은 프로젝트마다 다르게 정합니다. 월 단위 유지보수 계약을 맺는 경우도 있고, 필요할 때 요청하는 방식도 있습니다. 장애 발생 시 연락 체계와 수정 요청 경로는 오픈 전에 문서로 정리합니다. 이 부분을 미리 정해두면 급한 상황에서 시간을 아낍니다.
고객 확인
운영 방식과 연락 체계를 문서로 확정합니다.
고객이 각 단계에서 확인할 것
상담에서는 범위 문서, 기획에서는 화면 목록, 설계에서는 시안과 프로토타입, 개발에서는 중간 빌드, 검수에서는 요구사항 대비 동작을 확인하시면 됩니다. 모든 단계를 다 보실 필요는 없지만, 설계 승인과 검수 두 지점은 직접 확인하시는 편이 좋습니다.
반드시 직접 보셔야 하는 두 지점
- 설계 승인 — 시안과 프로토타입을 직접 눌러보고 화면 흐름이 실제 업무 순서와 맞는지 확인합니다. 이 승인 이후의 구조 변경은 일정과 견적에 함께 영향을 줍니다.
- 검수 — 요구사항 정의서에 적힌 항목이 실제로 동작하는지 화면별로 확인합니다. 여기서 잡히지 않은 문제는 오픈 이후에 더 큰 비용으로 돌아옵니다.
나머지 단계에서 보실 것
- 상담 — 정리된 범위 문서의 누락 여부
- 기획 — 사용자 유형과 권한 구조
- 개발 — 주 단위 중간 빌드의 동작
- 운영 — 장애 연락 체계와 요청 경로
일정이 늘어나는 흔한 이유
가장 흔한 원인은 중간에 범위가 바뀌는 것입니다. "이것도 넣어주세요"가 반복되면 일정과 견적이 같이 늘어납니다. 두 번째는 외부 시스템 연동입니다. 상대 시스템의 응답 속도와 문서 품질에 따라 작업 기간이 크게 달라집니다. 세 번째는 의사결정 지연입니다. 승인권자가 정해져 있지 않으면 검토가 멈춥니다.
- 줄이는 방법 — 범위 변경
- 변경 요청은 문서로 남기고, 일정과 견적에 미치는 영향을 함께 안내드립니다.
- 줄이는 방법 — 외부 연동
- 연동 대상과 담당 창구를 기획 단계에서 확정하고, 테스트 환경 확보 시점을 미리 잡습니다.
- 줄이는 방법 — 의사결정
- 승인권자와 검토자를 프로젝트 시작 시점에 지정합니다.
협업 도구와 소통 방식
이슈 관리는 문서 기반으로 하고, 급한 사항은 메신저로 처리합니다. 회의는 정기 회의와 필요 시 추가 회의로 나눕니다. 외국계 개발사와 협업하는 경우처럼 시차가 있으면 비동기 소통 비중을 높입니다. SAVVYCOM Seoul office가 서울에 거점을 두고 현지에서 소통하는 방식도 같은 맥락입니다. 소통 채널을 처음에 정해두면 진행 중 혼선이 줄어듭니다.
- 이슈와 결정 사항은 문서에 남기고, 채팅은 확인 요청에 씁니다.
- 정기 회의에서 진행 상황과 다음 주 작업을 함께 확인합니다.
- 시차가 있는 협업은 문서와 영상 기록을 중심으로 돌아갑니다.
- 문의 창구는 프로젝트별로 한 곳을 정해 담당자를 지정합니다.
자주 묻는 질문
상담 전에 자주 나오는 질문을 정리했습니다. 여기에 없는 내용은 문의 페이지에서 남겨주시면 확인 후 답변드립니다.
기획 단계 없이 바로 개발을 시작할 수 있나요?
화면 목록과 권한 구조가 정해지지 않은 상태에서 개발을 시작하면, 중간에 구조를 바꾸는 일이 생기고 그 비용이 일정에 그대로 반영됩니다. 규모가 작은 프로젝트라면 기획과 설계를 한 번에 묶어 진행할 수 있지만, 요구사항 정의서와 화면 목록은 남기는 편을 권합니다.
중간에 기능을 추가하면 어떻게 되나요?
요청 자체를 막지는 않습니다. 다만 추가 요청은 문서로 남기고, 일정과 견적에 어떤 영향을 주는지 먼저 안내드린 뒤 진행 여부를 결정합니다. 작은 수정은 기존 일정 안에서 처리되는 경우도 있고, 구조에 영향을 주는 변경은 별도 단계로 분리됩니다.
AI 기능이 들어가면 일정이 어떻게 달라지나요?
학습이나 연동에 쓸 데이터가 어느 정도 준비되어 있는지에 따라 달라집니다. 데이터 준비 상태와 검토가 필요한 규제 항목을 개발 단계에서 함께 확인하고, 그 결과에 따라 범위를 조정합니다. 데이터가 정리되지 않은 상태라면 정리 작업을 별도 단계로 두는 편이 안전합니다.
운영은 꼭 계약해야 하나요?
아닙니다. 월 단위 유지보수 계약을 맺는 방식과, 필요할 때 요청하는 방식 중에서 프로젝트에 맞는 쪽을 정합니다. 어느 쪽이든 장애 발생 시 연락 체계와 수정 요청 경로는 오픈 전에 문서로 정리해 둡니다.
검수는 누가 어떤 기준으로 하나요?
기준은 기획 단계에서 확정한 요구사항 정의서입니다. 고객 담당자가 화면별 동작을 확인하고, 권한별 접근 테스트와 오류 대응 결과를 함께 봅니다. 정의서에 없는 항목이 필요하면 별도 협의 대상이 되며, 그 판단 기준은 처음부터 문서에 적어 둡니다.
다음 단계는 상담에서 범위를 정리하는 것입니다
지금 쓰는 시스템과 불편한 지점, 예산과 일정 범위를 알려주시면 상담 후 정리된 범위 문서를 보내드립니다. 서비스 범위가 궁금하시면 서비스 페이지에서 항목별로 확인하실 수 있습니다.