프로젝트 진행 방식
기획부터 유지보수까지 이어서 갑니다
프로젝트가 어긋나는 지점은 대개 실력이 아니라 순서입니다. 무엇을 먼저 정하고, 어느 단계에서 승인하고, 언제 다음으로 넘어가는지가 정해져 있으면 진행이 흔들리지 않습니다.
준비된 순서가 일정을 지킵니다
1단계: 상담과 범위 정리
먼저 목표, 예산 범위, 일정, 기존 시스템 여부를 확인합니다. 이 네 가지가 정해지면 필요한 서비스와 순서가 좁혀집니다. 준비가 덜 되어 있어도 괜찮습니다. 이 단계에서 함께 정리합니다.
범위가 정해지면 무엇이 포함되고 무엇이 빠지는지 문서로 남깁니다. 이 문서가 이후 일정과 견적의 기준이 됩니다. 말로만 정한 범위는 나중에 서로 다르게 기억되기 쉽습니다. 그래서 상담이 끝나는 시점에 범위 문서 초안을 함께 확인하시길 권합니다.
이 단계에서 받는 것
- 범위 정의 문서 — 포함 항목과 제외 항목을 한 문서에 정리합니다.
- 필요한 서비스 조합 — 웹사이트 제작, 모바일 앱 개발, IT 컨설팅 중 무엇이 먼저인지 정합니다.
- 일정 초안 — 주요 승인 지점과 예상 기간을 함께 봅니다.
- 자료 준비 목록 — 텍스트, 이미지, 계정 접근 권한 등 발주처가 준비할 항목입니다.
2단계: 기획과 정보구조
사용자가 무엇을 하러 오는지, 어떤 순서로 화면을 지나는지 정리합니다. 정보구조와 사용자 흐름이 여기서 잡힙니다. 웹과 앱이 함께 있는 프로젝트라면 두 화면이 어떻게 이어지는지도 이 단계에서 그립니다.
산출물은 화면 목록, 흐름도, 기능 정의서입니다. 한국어 서비스라면 카카오톡 알림, 네이버 검색 노출, 접근성 요구를 여기서 함께 확인합니다. 나중에 발견하면 되돌리는 비용이 커지기 때문입니다.
3단계: 디자인과 프로토타입
기획을 바탕으로 화면을 설계합니다. Figma에서 프로토타입으로 먼저 확인하고, 확정된 화면은 컴포넌트로 정리해 개발에 넘깁니다. 이렇게 하면 반응형 웹과 앱 화면을 같은 규칙으로 유지하기 쉽습니다.
디자인 검토는 한 번에 끝내지 않습니다. 주요 화면을 먼저 확인하고, 나머지는 같은 규칙으로 확장합니다. 그래야 뒤로 갈수록 시안을 계속 고치는 상황을 줄일 수 있습니다. 확정된 컴포넌트 목록은 이후 개발 단계에서 그대로 기준이 됩니다.
이 단계에서 받는 것
- Figma 프로토타입 — 주요 화면의 흐름을 실제로 눌러보며 확인합니다.
- 컴포넌트 정의 — 버튼, 입력, 목록 같은 반복 요소를 규칙으로 정리합니다.
- 반응형 화면 기준 — 데스크톱과 모바일에서 같은 규칙이 유지되는지 확인합니다.
4단계: 개발
프론트엔드와 백엔드, 데이터베이스, 관리자 화면을 만듭니다. 기능 단위로 완성되는 대로 공유해서 실제 동작을 확인합니다. 한 번에 다 만들고 마지막에 보여주는 방식은 위험이 큽니다.
AI 기능이 포함되면 모델 선택과 데이터 흐름을 이 단계에서 붙입니다. 사람이 최종 확인하는 지점도 함께 정합니다. 개발 중 발견되는 제약은 범위 문서와 비교해 조정합니다.
개발 중 확인하는 것
- 기능 단위 공유 — 완성된 기능부터 실제 화면으로 확인합니다.
- 데이터 흐름 점검 — 저장, 조회, 알림이 어디서 이어지는지 봅니다.
- 범위 대조 — 새로 발견된 제약을 범위 문서와 비교해 조정합니다.
5단계: 출시
웹은 서버 배포와 도메인 연결, 검색 노출 설정을 확인합니다. 앱은 Google Play 심사와 스토어 등록 정보, 버전 관리를 준비합니다. 심사에서 보완 요청이 오는 경우가 있으므로 일정에 여유를 둡니다.
출시 직후에는 실제 사용에서 나오는 문제를 빠르게 확인합니다. 로그인, 결제, 알림처럼 핵심 동선을 먼저 점검합니다. 이 구간을 안정화 기간으로 두고 대응합니다.
출시 직후에는 핵심 동선을 먼저 봅니다
출시 이후
6단계: 유지보수와 개선
출시 이후가 더 깁니다. 서버 운영, 앱 업데이트, 기능 개선, 보안 패치가 이어집니다. 저희는 이 단계를 범위에 넣을지 상담에서 정합니다. 운영을 맡기지 않더라도 어떤 항목을 누가 담당할지는 출시 전에 정리해 두는 편이 안전합니다.
운영 중 쌓인 데이터를 보면 다음에 무엇을 개선할지 보입니다. 어떤 화면에서 사용자가 멈추는지, 어떤 기능을 안 쓰는지가 드러납니다. 이걸 다음 개선 주기에 반영합니다.
역할 분담
발주처가 맡는 일
- 목표와 우선순위 정하기 — 무엇이 먼저인지 정하면 범위가 좁혀집니다.
- 콘텐츠 준비 — 텍스트, 이미지, 서비스 정보를 준비합니다.
- 최종 승인 — 단계마다 결과물을 확인하고 다음으로 넘길지 결정합니다.
저희가 맡는 일
- 기획과 정보구조 — 사용자 흐름과 화면 목록을 정리합니다.
- 디자인과 개발 — 프로토타입, 프론트엔드, 백엔드, 관리자 화면을 만듭니다.
- 출시와 운영 — 배포, 스토어 등록, 유지보수까지 이어서 처리합니다.
발주처 담당자가 한 명으로 정해지면 진행이 빨라집니다. 의사결정이 여러 곳으로 흩어지면 승인 대기 시간이 길어집니다. 초반에 담당자와 소통 채널을 정합니다. 회의 주기와 보고 방식도 이때 함께 정하면 중간에 확인이 끊기지 않습니다.
일정이 늘어나는 흔한 이유
콘텐츠 준비 지연
가장 흔한 원인은 콘텐츠 준비 지연입니다. 텍스트와 이미지가 늦게 오면 디자인과 개발이 함께 밀립니다. 그래서 기획 단계에서 필요한 자료 목록과 마감을 정합니다.
중간에 커지는 범위
두 번째는 중간에 범위가 커지는 경우입니다. 새 기능을 넣고 싶을 때는 일정과 예산에 어떤 영향이 있는지 함께 확인합니다. 무리하게 끼워 넣기보다 다음 단계로 미루는 편이 결과가 낫습니다.
단계별 확인 방식
저희는 단계마다 결과물을 공유하고 확인받은 뒤 다음으로 넘어갑니다. 중간에 방향이 바뀌어도 되돌릴 지점이 남아 있게 하기 위해서입니다. 승인 없이 다음 단계로 넘어가지 않습니다.
확인 방식은 프로젝트 규모에 따라 다릅니다. 작은 프로젝트는 화면 공유로, 큰 프로젝트는 정기 미팅으로 진행합니다. 어떤 방식이 맞을지는 상담에서 정합니다. 소통 채널과 보고 주기도 같은 자리에서 함께 정합니다.
승인 지점
- 범위 문서 확인 — 무엇이 포함되고 빠지는지 확인합니다.
- 기획 산출물 확인 — 화면 목록과 흐름도를 확인합니다.
- 디자인 확정 — 주요 화면을 확인하고 나머지를 같은 규칙으로 확장합니다.
- 기능 확인 — 완성된 기능을 실제 동작으로 확인합니다.
- 출시 전 점검 — 핵심 동선과 등록 정보를 확인합니다.
무엇을 준비하고 어떤 산출물을 받는지 먼저 확인하세요
범위가 정해지면 일정과 견적도 함께 정리됩니다. 준비가 덜 되어 있어도 상담과 기획 단계에서 같이 정리하니, 지금 필요한 자료가 무엇인지부터 확인하시면 됩니다.
자주 묻는 질문
프로젝트는 보통 얼마나 걸리나요?
소개 사이트와 웹앱, 앱은 필요한 범위가 달라 기간도 달라집니다. 범위가 정해진 뒤 일정을 제안합니다.
기획 자료가 없어도 시작할 수 있나요?
가능합니다. 상담과 기획 단계에서 목표와 기능을 함께 정리합니다.
개발 중 기능을 추가할 수 있나요?
협의해 조정합니다. 일정과 예산에 미치는 영향을 먼저 확인한 뒤 결정합니다.
출시 후 유지보수는 꼭 맡겨야 하나요?
아닙니다. 서버 운영과 업데이트를 범위에 넣을지 상담에서 정합니다.