앞 페이지에서 로컬 개발환경과 compose, env 구조를 정했다면, 이제 실제 데이터를 어디에 저장하고 어떤 값을 비밀로 다루며 어떤 명령을 반복 실행할지까지 정해야 합니다. 이 단계가 빠지면 프로젝트는 겉으로는 실행되는 것처럼 보여도 금방 무너집니다.
처음에는 메모리 저장소로 대충 돌아가고, 개발자 로컬 파일에만 값을 넣어도 되는 것처럼 느껴질 수 있습니다. 하지만 주문, 결제, 운영자 조회, 챗봇 상담 기록이 붙기 시작하면 바로 문제가 드러납니다.
이번 페이지의 목적은 이 혼선을 없애는 것입니다. 이커머스 서비스에 필요한 최소 저장 전략, 시크릿 주입 원칙, 실행 스크립트 구성을 먼저 고정하고 나서 다음 장의 실제 구현으로 들어갑니다.
풀스택 강의에서 자주 생기는 착각은 "일단 API부터 만들고 나중에 DB 붙이면 된다"는 생각입니다. 물론 아주 짧은 데모라면 가능하지만, 이번 교재는 DDD 기반 이커머스 서비스를 끝까지 완성하는 흐름입니다. 따라서 아래 세 가지는 구현 전에 먼저 정해두는 편이 맞습니다.
이 셋이 먼저 정리되어야 이후의 백엔드 유스케이스와 프론트 흐름도 안정적으로 이어집니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
이커머스 서비스에서는 모든 데이터를 똑같이 다룰 수 없습니다. 어떤 것은 메모리에 있어도 되지만, 어떤 것은 반드시 DB에 남아야 합니다.
이번 교재에서 최소한 영속 저장해야 하는 것은 아래와 같습니다.
반대로 아래는 초기 단계에서는 반드시 DB에 넣지 않아도 됩니다.
중요한 점은 "서비스 상태를 복원하는 데 필요한 것"은 DB에 남겨야 한다는 것입니다.
강의용 프로젝트라고 해서 무조건 가벼운 DB를 쓰는 것이 정답은 아닙니다. 반대로 실전 같아 보인다고 처음부터 너무 무거운 구성을 넣는 것도 좋지 않습니다.
이번 교재에서는 아래 원칙으로 판단하는 것이 좋습니다.
이 기준을 적용하면 이번 교재는 관계형 DB를 기본으로 두는 것이 자연스럽습니다. 구현 난이도와 실습 안정성을 고려해 초기에는 SQLite 또는 PostgreSQL 중 하나를 선택할 수 있지만, "DDD 기반 이커머스"라는 목표를 생각하면 관계형 모델이 맞습니다.
이번 프로젝트는 아래 관계를 자주 다룹니다.
이 구조는 문서형 DB보다 관계형 DB에서 설명과 검증이 더 쉽습니다. 특히 아래 장점이 큽니다.
즉 이번 교재에서는 관계형 DB가 "실전형 사고를 연습하기 좋은 기본 선택"입니다.
정확한 스키마는 뒤 장에서 더 구체화되지만, 지금 시점에서 최소한 아래 테이블을 예상할 수 있어야 합니다.
usersproductscart_itemsordersorder_itemspaymentsadmin_userssupport_conversations 또는 support_events중요한 것은 지금 완벽한 컬럼을 다 정하는 것이 아니라, 어떤 도메인 정보가 결국 영속 저장 대상인지 인식하는 것입니다.
초기 이커머스 MVP에서도 파일 저장은 생각보다 빨리 필요해집니다. 대표적으로 아래 경우가 있습니다.
하지만 모든 파일 저장을 처음부터 복잡하게 만들 필요는 없습니다. 이번 교재의 초기 기준은 아래처럼 가져가면 충분합니다.
즉 처음에는 로컬 디렉터리 기반 저장으로 시작하되, 코드 구조는 "나중에 S3류 스토리지로 바꿀 수 있게" 분리해두는 것이 맞습니다.
파일 저장에서 가장 흔한 문제는 경로가 암묵적이라는 점입니다.
예를 들어:
uploads//tmp/uploads이렇게 되면 실행과 테스트가 깨집니다. 따라서 이번 교재에서는 파일 저장 경로도 설정으로 관리하는 것이 좋습니다.
예를 들면 아래와 같습니다.
STORAGE_ROOTPRODUCT_IMAGE_DIRCHATBOT_KB_DIR로컬에서는 하나의 명확한 루트 아래 두고, compose에서는 볼륨으로 연결하는 방식이 실용적입니다.
시크릿은 단순히 "남에게 보여주면 안 되는 문자열"이 아닙니다. 유출되면 세션 위조, 결제 오용, 관리자 계정 침해, 외부 API 오남용이 가능한 값입니다.
이번 교재에서 시크릿 후보는 아래와 같습니다.
SECRET_KEY이 값들은 코드에 하드코딩하면 안 됩니다. 문서에도 실제 값을 넣으면 안 됩니다. .env.example에는 이름과 형식만 있고, 실제 값은 각 환경에서 주입되어야 합니다.
모든 env가 시크릿은 아닙니다. 이 구분이 안 되면 보안과 운영이 동시에 지저분해집니다.
즉 APP_PORT와 SECRET_KEY는 같은 env에 있을 수는 있어도, 같은 민감도로 다뤄서는 안 됩니다.
시크릿은 아래 계층에 퍼지면 안 됩니다.
이번 교재에서는 최소한 아래 원칙을 지키는 것이 맞습니다.
이 원칙만 지켜도 초반 보안 실수를 많이 줄일 수 있습니다.
강의형 프로젝트에서 반복 실행 명령이 문서에만 있으면 재현성이 떨어집니다. 사람마다 명령을 다르게 치기 시작하면 곧바로 "누구 환경에서는 되는데 누구 환경에서는 안 되는" 상태가 됩니다.
따라서 자주 반복하는 작업은 scripts/ 아래에 고정하는 편이 좋습니다.
이번 교재에서 스크립트로 분리하기 좋은 작업은 아래와 같습니다.
문서에는 스크립트를 설명하고, 실제 실행은 스크립트를 통해 하게 만드는 것이 좋습니다.
아래 정도면 강의 진행과 실습 재현에 충분합니다.
scripts/dev/up.shscripts/dev/down.shscripts/test/all.shscripts/server/seed.shscripts/server/reset_db.shscripts/server/create_admin.shscripts/client/storefront_dev.shscripts/client/admin_dev.sh스크립트 이름은 팀 규칙에 따라 달라도 되지만, 역할은 명확해야 합니다.
모든 것을 스크립트로 만들 필요는 없습니다. 반복성과 실수 가능성으로 판단하면 됩니다.
즉 문서는 "왜"를 설명하고, 스크립트는 "어떻게 반복 실행할지"를 고정합니다.
실전 교재에서 빠지기 쉬운 부분이 초기 데이터 전략입니다. 하지만 상품도 없고 관리자 계정도 없으면 프론트와 운영 화면을 제대로 확인할 수 없습니다.
따라서 이번 교재에서는 아래를 미리 정해두는 것이 좋습니다.
이 데이터는 사람이 수동으로 매번 넣기보다 스크립트로 재현 가능해야 합니다.
AI 상담 기능도 저장 전략과 무관하지 않습니다. 최소한 아래 질문에 답할 수 있어야 합니다.
초기 MVP에서는 모든 대화를 완전하게 보존하지 않아도 되지만, 최소한 문의 맥락과 FAQ 소스는 추적 가능해야 합니다. 그래야 운영자가 챗봇 품질을 개선할 수 있습니다.
이 페이지를 실제 작업으로 옮기면 아래 산출물이 있어야 합니다.
.env.examplescripts/ 하위 실행 스크립트이 산출물이 있어야 다음 장에서 "이제 백엔드를 구현하자"는 말이 현실적으로 성립합니다.
SECRET_KEY를 코드에 하드코딩한다.env.example에 넣는다이 여섯 가지 실수는 초반에는 티가 안 나지만, 장바구니와 주문 기능이 붙는 순간 바로 개발 속도를 떨어뜨립니다.
이 페이지에서 우리는 이커머스 서비스를 실제로 구현하기 전에 반드시 필요한 저장 전략과 실행 바닥을 정리했습니다. 어떤 데이터가 DB에 들어가야 하는지, 파일은 어디에 저장해야 하는지, 시크릿은 어떻게 분리해야 하는지, 반복 실행 명령은 왜 스크립트로 고정해야 하는지를 확인했습니다. 이제 다음 페이지에서는 이 환경을 팀 단위로 유지하기 위한 CI, 품질 검증, 장애 재현의 최소 기준을 정리할 수 있습니다.
다음 페이지에서는 CI, 린트, 테스트, 관측, 장애 재현 흐름을 어떻게 최소 비용으로 갖출지 설명합니다.