제작 과정
기획부터 유지보수까지 진행 단계
프로젝트가 어떤 순서로 진행되는지 미리 알면 협업이 수월해집니다. 각 단계에서 무엇을 만들고 무엇을 확인하는지 정리했습니다.
협업은 순서를 공유하는 데서 시작합니다
제작 과정이 보이지 않으면 진행 상황을 확인할 때마다 같은 질문을 반복하게 됩니다. 반대로 각 단계의 목적과 산출물을 미리 알고 있으면, 어느 시점에 무엇을 검토하고 어떤 결정을 내려야 하는지 판단하기 쉬워집니다.
이 페이지는 킥오프부터 유지보수까지 실제로 진행되는 순서를 따라갑니다. 단계마다 확인하는 항목, 담당자가 바뀌어도 이어질 수 있도록 남기는 기록, 그리고 다음 단계로 넘어가기 전에 합의해야 하는 지점을 함께 설명합니다. 서비스 범위와 프로젝트 사례를 같이 보면 각 단계가 결과물에서 어떻게 드러나는지 비교할 수 있습니다.
단계별로 무엇을 확인하는가
일곱 단계가 이어집니다. 각 단계는 앞 단계의 결과물을 입력으로 받고, 다음 단계가 의존할 결정을 남깁니다.
준비 단계
킥오프와 요구사항 정리
킥오프에서 정하는 것은 목표, 범위, 일정, 의사결정 구조입니다. 누가 최종 승인을 하는지, 변경 요청은 어떤 경로로 들어오는지를 함께 정합니다. 이 구조가 없으면 진행 중 혼선이 생깁니다. 회의에 참여하는 사람이 곧 결정권자인지, 아니면 별도의 승인 절차가 있는지를 먼저 확인하는 편이 좋습니다.
요구사항은 문서로 정리합니다. 기능 목록, 우선순위, 제외 범위를 함께 적습니다. 무엇을 하지 않을지 명시하는 것이 나중에 분쟁을 줄입니다. 우선순위는 "이번 버전에 반드시 들어가는 항목"과 "여유가 있을 때 검토하는 항목" 두 단계로 나누면 일정 조정이 쉬워집니다.
이 단계에서 남기는 것
- 목표와 성공 기준을 한 문장으로 정리한 합의문
- 기능 목록과 우선순위, 제외 범위가 적힌 요구사항 문서
- 최종 승인자와 변경 요청 경로를 정한 의사결정 구조
구조 설계
정보구조 설계와 와이어프레임
정보구조 설계는 메뉴와 페이지 구조를 정하는 작업입니다. 사용자가 어떤 순서로 정보를 찾는지, 검색 유입 키워드가 무엇인지를 함께 봅니다. 사이트맵이 확정되면 화면 단위 작업이 시작됩니다.
와이어프레임은 화면 배치와 흐름을 확인하는 단계입니다. 이 단계에서는 시각 디자인보다 동선과 우선순위를 봅니다. 여기서 잡은 구조가 이후 디자인과 개발의 기준이 됩니다. 검색으로 들어오는 방문자와 앱에서 넘어오는 방문자의 첫 화면이 다르다면, 그 차이도 이 단계에서 정리해 둡니다.
화면 설계
디자인과 디자인 시스템
반복 요소를 규칙으로 만듭니다
주요 화면 시안과 함께 버튼, 폼, 알림, 카드 같은 컴포넌트를 정리합니다. 규칙으로 만들어두면 페이지가 늘어나도 일관성이 유지되고, 나중에 문구만 바꾸는 작업도 빠르게 끝납니다.
국내 서비스 관행을 초기에 반영합니다
본인인증, 주소 검색, 고객센터 연결 같은 요소를 이 단계에서 잡아두면 개발 단계 재작업이 줄어듭니다. 나중에 붙이면 화면 흐름과 폼 구조를 다시 손봐야 하는 경우가 생깁니다.
상태를 함께 정의합니다
비어 있는 화면, 로딩 중, 오류, 권한 없음 같은 상태도 시안에 포함합니다. 정상 흐름만 그려두면 개발 단계에서 임의로 채우게 되고, 그때마다 톤이 달라집니다.
모바일과 웹을 같이 봅니다
같은 서비스라도 모바일과 웹의 우선순위가 다릅니다. 화면 폭이 좁을 때 무엇을 먼저 보여줄지 미리 정하면, 퍼블리싱 단계에서 배치를 다시 고민하지 않아도 됩니다.
구현 단계
퍼블리싱과 반응형 웹
디자인을 실제 브라우저에서 동작하는 마크업으로 만드는 단계입니다. 화면 크기별 대응과 접근성 점검이 여기서 함께 진행됩니다.
화면 크기별 대응과 인앱 브라우저
반응형 웹은 화면 크기별 대응과 함께 인앱 브라우저 환경도 확인합니다. 메신저 안에서 열리는 경우 레이아웃이 달라질 수 있어, 실제로 링크가 공유되는 경로를 기준으로 점검합니다.
접근성은 이 단계에서 잡습니다
키보드 탐색, 대체 텍스트, 명도 대비 같은 항목을 확인합니다. 나중에 고치면 관련 화면을 다시 손봐야 하므로 퍼블리싱 단계에서 잡는 편이 낫습니다.
개발
프론트엔드와 백엔드 개발
두 영역은 API 계약을 기준으로 나뉩니다. 어떤 요청에 어떤 응답이 오는지를 먼저 정하면 병렬 작업이 가능해집니다.
프론트엔드
사용자가 보는 화면과 상호작용을 만듭니다. 상태 관리, 폼 검증, 오류 표시 같은 부분이 여기에 포함됩니다. 서버 응답이 늦을 때 화면이 어떻게 보일지도 함께 정합니다.
백엔드
데이터 저장, 인증, 권한, 외부 연동을 담당합니다. 누가 어떤 데이터를 볼 수 있는지 규칙을 코드 이전에 정리해두면 권한 관련 수정이 줄어듭니다.
API 계약
계약이 바뀌면 양쪽 일정에 영향을 주므로 변경 절차를 정해둡니다. 누가 변경을 제안하고 누가 승인하는지, 변경된 계약이 언제 적용되는지 기록합니다.
병렬 작업
화면과 데이터 규칙이 먼저 합의되면 프론트엔드와 백엔드가 동시에 진행될 수 있습니다. 이때 임시 응답을 사용해 화면을 먼저 완성해두면 통합 시점의 수정이 줄어듭니다.
연동
API 연동과 외부 시스템 연결
결제, 지도, 알림, 사내 시스템과 연결할 때 인증 방식과 오류 처리 규칙을 합의합니다. 실패했을 때 재시도할지, 사용자에게 어떤 메시지를 보여줄지를 정합니다. 이 규칙이 없으면 오픈 후 대응이 어려워집니다.
연동 대상이 많아질수록 문서화가 중요해집니다. 어떤 시스템이 어떤 데이터를 주고받는지 기록해두면 담당자가 바뀌어도 대응이 가능합니다. 외부 시스템의 점검 시간이나 응답 지연처럼 통제할 수 없는 조건도 문서에 함께 남깁니다.
오픈
검수와 오픈
검수 항목
기능 동작, 화면 표시, 성능, 보안 항목을 확인합니다. 실제 사용 환경과 유사한 조건에서 테스트하고, 발견된 문제는 우선순위를 정해 처리합니다.
롤백 계획
오픈 전에 이전 상태로 되돌릴 수 있는 계획을 준비합니다. 되돌리는 절차와 그 절차를 실행할 사람을 함께 정해 둡니다.
오픈 당일
모니터링 담당과 연락 체계를 정합니다. 문제가 감지됐을 때 누구에게 어떤 순서로 알리는지 미리 합의해 두면 대응이 빨라집니다.
운영
유지보수와 운영
오픈 후에는 오류 수정, 보안 패치, 브라우저·OS 업데이트 대응, 콘텐츠 변경이 이어집니다. 월 단위 점검 범위와 긴급 대응 기준을 문서로 정합니다. 기능 추가와 단순 수정의 경계도 함께 정해두면, 어느 요청이 다음 버전 계획으로 넘어가는지 분명해집니다.
운영 데이터를 보면 다음 개선 우선순위가 보입니다. 사용 패턴, 오류 발생 지점, 문의 유형을 주기적으로 확인합니다. 이 기록이 다음 버전 계획의 근거가 됩니다.
운영 점검에서 확인하는 것
- 사용 패턴 변화와 이탈이 잦은 화면
- 오류가 반복되는 지점과 발생 조건
- 문의 유형과 자주 반복되는 요청
- 브라우저·OS 업데이트로 영향받는 기능
자주 나오는 질문
진행 순서에 대해 문의할 때 자주 나오는 질문을 정리했습니다.
일정은 언제 확정되나요?
킥오프와 요구사항 정리가 끝난 뒤에 전체 일정을 확정합니다. 범위가 바뀌면 일정도 함께 조정되므로, 확정된 일정은 문서로 남겨 두고 변경이 생길 때마다 갱신합니다.
디자인과 개발을 동시에 진행할 수 있나요?
주요 화면 시안과 API 계약이 정해지면 가능합니다. 다만 공통 컴포넌트 규칙이 먼저 확정되어야 병렬 작업이 서로 어긋나지 않습니다.
외부 시스템 연동은 언제 시작하나요?
인증 방식과 오류 처리 규칙이 합의된 뒤에 시작합니다. 연동 대상이 많으면 백엔드 개발과 겹쳐 진행하고, 문서를 같은 위치에 계속 갱신합니다.
오픈 후 수정은 어떻게 요청하나요?
긴급 대응 기준에 해당하면 즉시 처리하고, 그 외 요청은 정해진 점검 주기에 맞춰 반영합니다. 기능 추가로 분류되는 요청은 다음 버전 계획에서 우선순위를 함께 봅니다.
다음 단계로 이어가기
진행 순서를 확인했다면, 서비스 범위에서 각 단계가 어떤 작업으로 구성되는지 살펴보거나 프로젝트 사례에서 단계별 결과물을 비교해 볼 수 있습니다. 진행 중 궁금한 점은 문의로 남겨 주시면 담당자가 확인합니다.
상담 가능 시간: 월요일–금요일 09:00–18:00 · 전화 +82-31-701-5678
진행 순서가 정해지면 프로젝트는 훨씬 빠르게 움직입니다
범위와 일정, 확인 지점을 함께 정리한 뒤에 시작합니다. 문의를 남겨 주시면 담당자가 순서대로 확인합니다.