앞 페이지에서 저장 전략, 시크릿, 실행 스크립트까지 정했다면, 이제 구현을 시작하기 전에 마지막으로 고정해야 하는 것이 있습니다. 바로 "어떻게 깨졌는지 빨리 알아차리고, 어떻게 다시 같은 문제를 재현하고, 어떻게 자동으로 기본 품질을 검사할 것인가"입니다.
풀스택 프로젝트는 기능이 늘어날수록 문제가 한 군데에서만 생기지 않습니다. 어떤 날은 프론트가 잘못된 API 응답 형태를 가정하고, 어떤 날은 백엔드가 DB 연결에 실패하고, 어떤 날은 챗봇 플래그가 잘못 들어가서 화면만 깨질 수 있습니다. 이때 CI, 로그, 헬스체크, 장애 재현 기준이 없으면 문제를 발견하는 속도도 느리고, 고친 뒤 다시 확인하는 속도도 느립니다.
이번 페이지의 목적은 거창한 운영 플랫폼을 만드는 것이 아닙니다. 이커머스 MVP를 계속 안전하게 확장할 수 있도록, 구현 시작 전에 반드시 필요한 최소 품질 바닥을 만드는 것입니다.
많은 튜토리얼은 기능을 다 만든 뒤 마지막에 테스트와 운영 이야기를 붙입니다. 하지만 실전에서는 반대입니다. 최소한의 CI와 관측 기준이 먼저 있어야 이후 기능을 붙일 때마다 망가지지 않았는지 바로 확인할 수 있습니다.
이번 교재에서 이 단계를 먼저 넣는 이유는 아래와 같습니다.
즉 이번 페이지는 운영팀을 흉내 내기 위한 장식이 아니라, 이후 장의 구현 속도를 높이기 위한 안전장치입니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
CI는 거대한 클라우드 파이프라인을 뜻하지 않습니다. 지금 단계에서의 CI는 "저장소에 변경이 들어왔을 때 최소한 이것만은 자동으로 확인한다"는 약속입니다.
이번 교재에서 CI의 첫 역할은 아래 정도면 충분합니다.
이 네 가지가 돌아가기 시작하면 이후 장에서 기능을 붙일 때도 기본적인 회귀를 빨리 잡을 수 있습니다.
처음부터 E2E, 보안 스캔, 성능 테스트, 배포 자동화까지 한 번에 넣으면 그 자체가 학습 부담이 됩니다. 이번 교재의 목적은 실전형 흐름을 익히는 것이지, 초반부터 운영 플랫폼 구축에 시간을 다 쓰는 것이 아닙니다.
따라서 이번 장에서는 아래 순서가 자연스럽습니다.
즉 CI는 처음부터 완성형이어야 하는 것이 아니라, 기능 복잡도에 맞춰 단계적으로 커져야 합니다.
이번 이커머스 프로젝트 기준으로는 아래 흐름을 첫 버전으로 잡으면 충분합니다.
storefront 의존성 설치storefront 빌드admin 의존성 설치admin 빌드중요한 것은 "작지만 반드시 도는 파이프라인"을 만드는 것입니다.
이번 프로젝트에서는 프론트와 백엔드가 같은 품질 기준을 가질 수 없습니다.
즉 프론트는 처음에는 "조립과 렌더링 안정성", 백엔드는 "도메인 규칙과 유스케이스 안정성"에 더 무게를 두는 것이 맞습니다.
모든 기능을 같은 비중으로 테스트할 수는 없습니다. 이커머스 MVP에서 먼저 지켜야 할 것은 도메인 규칙과 돈이 관련된 흐름입니다.
우선순위는 아래처럼 두는 것이 자연스럽습니다.
초기 단계에서는 상품 상세 화면 애니메이션보다 주문 상태 전이 테스트가 훨씬 중요합니다.
관측의 시작은 거대한 대시보드가 아니라, 일관된 로그입니다. 로그가 제멋대로면 장애가 생겨도 원인을 찾기 어렵습니다.
이번 교재에서는 최소한 아래를 로그로 남기는 기준을 잡는 것이 좋습니다.
반대로 아래는 로그에 그대로 남기면 안 됩니다.
즉 로그는 많이 찍는 것이 아니라, 문제를 추적할 수 있게 찍되 민감한 값은 숨겨야 합니다.
개발 중에는 서버가 실행만 되면 된다고 생각하기 쉽지만, 실제로는 "프로세스가 떠 있다"와 "서비스가 정상이다"는 다릅니다.
따라서 이번 교재에서는 최소한 아래 수준의 헬스체크를 두는 것이 좋습니다.
이 정도만 있어도 로컬과 배포 환경에서 문제를 훨씬 빨리 좁힐 수 있습니다.
필요합니다. 다만 초반에는 복잡한 APM보다 간단한 관측 포인트가 더 실용적입니다.
예를 들어 프론트에서는 아래 정도를 확인할 수 있어야 합니다.
즉 프론트 관측은 "화면에서 실패가 어떻게 드러나는가"를 기준으로 봐야 합니다.
강의형 프로젝트에서는 오류를 한 번 고치고 끝내는 경우가 많습니다. 하지만 같은 문제가 다시 생기면 그때는 다시 처음부터 찾아야 합니다. 그래서 장애는 "경험담"이 아니라 "재현 가능한 시나리오"로 남겨야 합니다.
이번 교재에서 장애 재현 문서가 필요한 이유는 아래와 같습니다.
즉 좋은 장애 재현 문서는 디버깅 기록이자 테스트 설계의 출발점입니다.
초기 MVP 단계에서 아래 정도는 재현 시나리오로 정리해두는 것이 좋습니다.
API_BASE_URL로 프론트가 실행될 때 어떤 화면이 보이는가이 시나리오가 있으면 이후 장의 구현과 테스트가 훨씬 명확해집니다.
장애 재현은 일부러 시스템을 깨보는 일입니다. 그렇기 때문에 더더욱 절차가 필요합니다.
이번 교재에서는 아래 원칙을 추천합니다.
예를 들어 DB 연결 실패를 재현할 때는 포트 하나만 바꾸고, "주문 생성 시 500이 아니라 명확한 오류 응답이 나와야 한다" 같은 기대 결과를 먼저 적어두는 식입니다.
좋은 흐름은 아래와 같습니다.
즉 장애 재현은 일회성 디버깅으로 끝나면 안 되고, 다음부터는 자동으로 잡히도록 CI와 연결되어야 합니다.
지금 단계에서 아래 정도가 있으면 충분합니다.
이 다섯 가지가 있으면, 기능 구현을 시작해도 프로젝트가 완전히 암흑 상태로 빠지지 않습니다.
이번 장은 최소 바닥을 만드는 장입니다. 따라서 아래까지 지금 당장 넣지 않아도 됩니다.
이것들은 나중에 확장할 수 있지만, 지금 중요한 것은 "문제가 생겼을 때 바로 알 수 있는 최소 기준"입니다.
이 페이지를 코드와 설정으로 옮기면 아래 결과가 있어야 합니다.
.github/workflows/ci.yml 초안이 산출물이 있으면 다음 장에서 백엔드와 프론트 골격을 구현하면서도 최소 품질을 계속 확인할 수 있습니다.
이 여섯 가지 실수는 프로젝트가 커질수록 디버깅 비용을 급격히 높입니다.
이 페이지에서 우리는 이커머스 서비스를 구현하기 전에 필요한 최소 품질 바닥을 정리했습니다. CI는 어디까지 자동화할지, 프론트와 백엔드 테스트는 어떤 역할을 맡아야 하는지, 로그와 헬스체크는 무엇을 확인해야 하는지, 장애는 어떻게 재현 가능한 시나리오로 남겨야 하는지를 확인했습니다. 이제 다음 장에서는 이 바닥 위에서 실제로 백엔드와 프론트의 골격 코드를 만들기 시작할 수 있습니다.
다음 장에서는 이제 실제 코드로 넘어가 백엔드와 프론트의 첫 골격을 만들고, 이 교재의 이커머스 서비스를 동작시키기 시작합니다.