1강부터 3강까지에서 우리는 왜 이 서비스를 만드는지, 누가 어떤 시나리오를 수행하는지, 이번 교재의 MVP가 어디까지인지를 정했습니다. 이제 남은 것은 실행 기준을 고정하는 일입니다. 실제 프로젝트는 좋은 아이디어만으로 굴러가지 않습니다. 어떤 문서가 먼저 필요하고, 어떤 코드가 뒤따라야 하며, 어느 시점에 무엇을 검증해야 하는지가 정리되어 있어야 합니다.
이 페이지의 목적은 팀이 같은 그림을 보게 만드는 것입니다. 기획 문서, 도메인 모델, 화면 설계, 구현, 검증, 배포까지 어떤 순서로 남아야 하는지 고정해 두면, 뒤 장에서 프론트와 백엔드가 따로 놀지 않고 한 줄로 연결됩니다.
개발 강의에서 흔히 생기는 문제는 방향은 맞는데 실행 규칙이 없어서 중간부터 흐트러지는 것입니다.
예를 들어:
이런 문제를 막으려면 "무엇을 만들 것인가"뿐 아니라 "어떤 산출물을 어떤 순서로 만들 것인가"를 정해야 합니다. 그래서 이번 페이지는 일종의 프로젝트 운영 계약서 역할을 합니다.
이 페이지를 읽고 나면 아래 항목이 분명해야 합니다.
이 기준이 있어야 뒤 장의 실습이 단순 코딩이 아니라 재현 가능한 프로젝트 진행 방식이 됩니다.
이 교재는 코드만 작성하는 강의가 아닙니다. 설계와 검증까지 남는 프로젝트를 만드는 강의입니다. 따라서 아래 산출물은 반드시 남겨야 합니다.
이 산출물은 "왜 이 기능이 필요한가"를 설명하는 기준입니다.
이 산출물은 뒤에서 API와 DB 구조를 설계할 때 기준이 됩니다.
이 산출물은 프론트 구현 순서를 정하는 기준입니다.
이 산출물은 실제 실행 가능한 결과물입니다.
이 산출물이 있어야 "동작한다"는 말을 근거 있게 할 수 있습니다.
이번 교재에서는 아무 순서로나 만들지 않습니다. 산출물은 아래 순서를 따릅니다.
이 순서를 따르는 이유는 간단합니다.
즉 문서와 코드는 대립 관계가 아니라, 앞 산출물이 뒤 산출물의 입력값이 되는 관계입니다.
이번 교재는 아래 마일스톤 순서로 진행하는 것이 가장 자연스럽습니다.
이 교재는 실제 팀 프로젝트처럼 진행할 수 있도록 설계되어 있습니다. 정확한 날짜보다 중요한 것은 단계별 시간 배분입니다.
권장 비율은 아래와 같습니다.
| 단계 | 권장 비율 | 이유 |
|---|---|---|
| 기획 | 15% | 뒤 수정 비용을 크게 줄여 준다 |
| 도메인 설계 | 15% | API와 코드 경계의 질을 결정한다 |
| 화면 설계 | 10% | 프론트 구현 속도와 일관성을 높인다 |
| 인프라/셋업 | 10% | 재현 가능한 개발 환경을 만든다 |
| 구현 | 35% | 실제 기능을 완성하는 중심 단계 |
| 검증/배포 | 15% | 완성도와 신뢰도를 결정한다 |
중요한 점은 구현 시간이 가장 길더라도, 기획과 설계를 너무 줄이면 전체 품질이 떨어진다는 것입니다.
이번 교재는 개인 학습에도 쓸 수 있지만, 팀 실습에도 바로 적용할 수 있도록 협업 규칙을 명시합니다.
요구사항이나 경계가 바뀌면 먼저 관련 문서를 수정합니다. 문서와 코드가 충돌할 때는 "최근 코드"가 아니라 "합의된 기획과 설계"를 기준으로 정리해야 합니다.
작업 분할은 파일 기준보다 시나리오 기준이 좋습니다.
예를 들어:
이렇게 나누면 프론트와 백엔드가 같은 목표를 보고 움직일 수 있습니다.
아래 네 가지가 모두 있어야 완료라고 부를 수 있습니다.
인증, 주문, 결제, 외부 연동, 챗봇 응답 범위처럼 경계를 건드리는 변경은 바로 구현하지 말고 먼저 도메인 규칙과 시나리오를 다시 확인해야 합니다.
이런 항목은 암묵적으로 공유하지 말고 문서로 남기는 것이 좋습니다.
이번 교재는 "나중에 테스트" 방식으로 진행하지 않습니다. 시나리오 완성과 검증은 같이 갑니다.
이 원칙이 중요합니다. 이커머스는 상태가 바뀌는 서비스이므로, 읽기 API만 확인해서는 완료를 말할 수 없습니다.
이 교재에서는 배포도 구현의 마지막 단계가 아니라 검증의 일부로 봅니다.
즉 배포 성공 메시지가 완료가 아니라, 배포 후 사용자 흐름 재확인이 완료 기준입니다.
이 장을 따라 하는 학습자는 아래 체크리스트를 프로젝트 초반에 만들어 두는 것이 좋습니다.
이 다섯 가지 실수는 후반부에 일정 지연과 품질 저하로 바로 이어집니다.
이 페이지에서 우리는 이 프로젝트를 어떤 순서와 어떤 기준으로 굴릴지 정했습니다. 이제 이 강의는 단순한 기능 구현 목록이 아니라, 기획 -> 설계 -> 구현 -> 검증 -> 배포의 선후 관계가 분명한 실전 교재가 됩니다. 다음 장부터는 이 기준을 바탕으로 기획을 DDD 도메인 언어로 번역하기 시작합니다.
다음 단계에서는 이제 기획 내용을 바운디드 컨텍스트와 도메인 언어로 번역하면서, DDD 모델링을 본격적으로 시작합니다.