AI 드리븐

지도 위치 : 3일차 · 신뢰와 운영 · 병합에서 운영까지 한 줄로 | 이전: 21차시 배포 ① 서버 공개 | 다음: 23차시 운영과 장애 대응 키워드 : 화면 배포와 연결, 자동 배포 흐름, 끝에서 끝까지 검증

이 차시를 다 읽으면

1. 화면이 빌드되면 무엇이 되는지 말하고, CDN 을 유와 종차로 정의할 수 있다.
2. 화면과 서버가 각각 정상인데도 연결이 실패하는 원인 을 점검 목록으로 댈 수 있고, CORS 가 무엇이고 무엇이 아닌지 말할 수 있다.
3. CD 와 미리보기 배포 를 정의하고, 자동 배포 흐름에서 사람이 손을 대는 자리 와 그 이유를 말할 수 있다.
4. E2E 테스트 를 단위 · 통합 테스트와 가르고, 핵심 흐름 몇 개로 제한하는 이유를 설명할 수 있다.
5. E2E가 진짜로 사용자의 길을 따라갔는지 코드가 아니라 녹화 영상 으로 확인할 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 병합 버튼 하나에서 실제 서비스까지를 어떻게 한 줄로 잇는가 , 그리고 그 줄의 어디에 사람을 남겨 두는가 입니다. 앞에서 배운 화면 · 서버 분리 (9, 11차시)가 연결 지점을 만들었고, 앞 차시(21차시)의 스모크 테스트와 20차시의 "자동 + 사람 승인" 칸이 이 차시에서 하나의 흐름이 됩니다.

---

1. 화면 배포

1.1 정의

정적 파일 — [배포 대상]인데, [ 누가 요청하든 같은 내용을 그대로 내주는 파일(HTML · JS · CSS · 이미지) ]이라는 점에서 요청마다 서버가 계산해 만드는 응답과 구별된다. 화면(프론트엔드)은 빌드하면 대부분 정적 파일이 됩니다.

CDN (Content Delivery Network) — [파일 전달망]인데, [ 같은 파일을 세계 여러 곳의 서버에 복사해 두고 사용자와 가까운 곳에서 내준다 ]는 점에서 한 서버가 모든 요청에 답하는 방식과 구별된다.

1.2 화면을 올리는 곳

(서비스별 기능은 바뀌므로 공식 문서 확인.)

1.3 반례

---

2. ⭐ 연결 점검 — 각각 정상이어도 연결은 깨진다

2.1 왜 연결에서 깨지나

0절 축 2입니다. 화면과 서버를 나눴기 때문에 둘 사이에 약속이 생기고, 그 약속은 배포 환경에서 처음 시험받습니다. 서버의 스모크 테스트(21차시)도 통과, 화면의 빌드도 성공인데 예약 버튼을 누르면 아무 일도 안 일어나는 상황이 이 단계의 전형입니다.

2.2 CORS — 무엇이고 무엇이 아닌가

출처 (origin) — 주소의 앞부분 세 가지(https + classon.example + 포트)를 묶은 것입니다. 화면이 https://classon.example이고 서버가 https://api.classon.example이면 출처가 다릅니다.

CORS (교차 출처 리소스 공유) — [브라우저 보안 규칙]인데, [ 화면이 다른 출처의 서버에 요청할 때, 그 서버가 허락한 출처의 화면만 응답을 읽게 한다 ]는 점에서 서버가 "누가 요청했는가"를 확인하는 인증과 구별된다.

⚠️ 그래서 두 가지 실수가 생깁니다.

• ❌ CORS 에러를 *(모든 출처 허용)로 "해결"한다 → 아무 사이트의 화면이나 우리 서버 응답을 읽을 수 있게 됩니다. 허용 목록에 우리 화면 도메인만 넣습니다.
• ❌ CORS를 걸었으니 서버가 보호된다고 생각한다 → CORS는 브라우저 밖의 요청을 막지 않습니다. 보호는 서버의 인증 · 인가가 합니다.

---

3. ⭐ 자동 배포 흐름 (CD)

3.1 정의

CD (지속적 배포, Continuous Deployment / Delivery) — [자동화 흐름]인데, [ 검사를 통과한 변경을 사람이 손대지 않고 배포 환경까지 내보낸다 ]는 점에서 검사까지만 하는 CI(19차시)와 구별된다.

⚠️ 용어 하나: 운영까지 완전 자동 이면 지속적 배포(Deployment), 운영 직전에 사람 승인 을 두면 지속적 전달(Delivery)이라고 구분해 부르기도 합니다. 이 과정의 흐름은 후자입니다. 둘 다 약자가 CD라 섞여 쓰입니다.

미리보기 배포 (preview deployment) — [배포]인데, [ PR마다 임시 주소로 따로 배포되어, 병합 전에 그 변경이 들어간 실제 화면을 볼 수 있다 ]는 점에서 main이 바뀔 때만 갱신되는 공유 스테이징과 구별된다.

3.2 흐름

19차시의 CI 뒤에 배포 단계를 이어 붙입니다.

PR 생성 ─▶ CI 통과 ─▶ 미리보기 배포 (PR마다 임시 주소)         [자동]
   │
   ▼ 리뷰 · 승인 후 병합                                    [사람 — 20차시]
main ─▶ CI 통과 ─▶ 스테이징 자동 배포 ─▶ 스모크 + E2E 테스트   [자동]
                                         │
                                  통과 ─▶ 운영 배포            [⭐ 사람이 승인 버튼]
                                  실패 ─▶ 중단, 알림           [자동]

🔍 읽는 포인트 : 오른쪽의 [자동] / [사람] 표시만 보면 됩니다. 사람은 두 자리 에만 있습니다 — 병합 승인과 운영 배포 승인.

3.3 사람은 왜 그 두 자리에만 있나

20차시 3절의 표를 그대로 적용한 결과입니다.

⚠️ 운영 배포까지 완전 자동으로 만들면, 결제 관련 변경이 사람 확인 없이 실제 고객에게 나갑니다. 팀이 커지고 테스트가 충분히 믿을 만해지면 이 칸을 자동으로 옮기는 조직도 있지만, 그 판단도 사람의 몫입니다.

💡 미리보기 배포는 코드를 읽지 않는 사람을 위한 기능 입니다. 20차시 체크리스트의 마지막 항목 "미리보기 주소에서 직접 눌러 봤다"가 여기서 가능해집니다. 코드 대신 동작을 보고 승인하는 방식 이 이 기능으로 완성됩니다.

---

4. 끝에서 끝까지(E2E) 검증

4.1 정의와 위치

E2E 테스트 (End-to-End) — [자동 테스트]인데, [ 실제 브라우저를 자동으로 조작해 사용자처럼 처음부터 끝까지 따라간다 ]는 점에서 부품만 확인하는 단위 · 통합 테스트와 구별된다. 앞에서 배운 테스트 층 (17차시)의 꼭대기입니다.

단위 · 통합 테스트는 부품 을 확인합니다. 2절의 연결 문제(API 주소, CORS, 쿠키, 결제 이동 주소)는 부품 테스트로는 원리상 잡을 수 없습니다. 부품을 다 붙이고 실제 주소에서 돌려야만 드러나기 때문입니다. 0절 축 3이 이 경계입니다.

4.2 예시

Playwright가 대표적인 도구입니다.

// e2e/reservation.spec.ts (개념)
test("수강생이 클래스를 찾아 예약하고 결제한다", async ({ page }) => {
  await page.goto(STAGING_URL);
  await page.getByRole("link", { name: /도자기/ }).click();
  await page.getByRole("button", { name: "11월 1일" }).click();
  await page.getByRole("button", { name: "예약하기" }).click();
  // PG 테스트 결제창에서 테스트 카드로 결제
  // ...
  await expect(page.getByText("예약이 확정되었어요")).toBeVisible();
  await page.goto(`${STAGING_URL}/me/reservations`);
  await expect(page.getByText("도자기")).toBeVisible();
});

🔍 읽는 포인트 : test("...") 안의 문장이 지키는 흐름이고, name: "예약하기"처럼 따옴표 안의 글자 가 사용자가 화면에서 누르는 버튼 이름입니다. 마지막 두 줄은 "확정 문구가 보이는가", "내 예약 목록에 나오는가"를 확인합니다.

4.3 몇 개나 두나

E2E는 느리고 깨지기 쉽습니다(화면 문구 하나만 바뀌어도 실패). 그래서 핵심 흐름 몇 개만 둡니다.

4.4 ⭐ E2E는 영상으로 확인한다

Playwright는 테스트 실행을 녹화(비디오) 하고, 단계별 화면을 기록(trace) 할 수 있습니다(설정 이름은 공식 문서 확인). 그러면 테스트가 실제로 어떤 화면을 거쳐 무엇을 눌렀는지 코드 없이 볼 수 있습니다.

⚠️ 테스트는 "통과"했는데 영상을 보니 엉뚱한 버튼을 누르고 있었다면, 앞에서 배운 형식만 갖춘 테스트 (17차시)입니다. E2E에서는 영상이 17차시의 "망가뜨려 보기"에 해당하는 판별 도구입니다.

에이전트에게 브라우저 도구를 연결해 두면(앞에서 배운 외부 연결, 7차시) E2E 시나리오 작성과 실패 원인 분석을 함께 맡길 수 있습니다.

💡 비유는 마지막에 — 단위 · 통합 테스트는 부품 공장의 검수 , E2E는 완성차 시운전 입니다. 엔진도 바퀴도 검수를 통과했는데 조립하고 나니 핸들과 바퀴가 반대로 연결되어 있을 수 있습니다. 시운전 영상을 보면 바로 압니다.

---

5. 클래스온에 적용하면

이 차시가 끝나면 다음이 성립해야 합니다.

---

6. 실습 — 맡기고 검수하기

지시

[1단계 — 화면 배포와 연결]
apps/web을 프론트엔드 호스팅에 스테이징으로 배포할 설정을 만들어줘. PR마다 미리보기 배포가 생기게.
- 서버 주소는 빌드 환경변수로 넣고, 코드에 주소를 직접 쓰지 마.
- 서버의 CORS 허용 목록에는 스테이징 화면 도메인과 미리보기 도메인만. * 는 쓰지 마.
- 2절 연결 점검 표의 여섯 항목을 하나씩 확인하고 [항목 | 확인 방법 | 결과 | 근거(화면·출력)] 표로 보고해.

[2단계 — 자동 배포와 E2E]
main 병합 시 스테이징 자동 배포 → 스모크 → E2E가 도는 흐름을 만들어줘.
운영 배포는 GitHub Environments의 필수 검토자 승인을 거쳐야만 진행되게 하고, 검토자는 나로.
E2E는 "예약 → 결제 → 내 예약 확인" 하나만. 실행 시 영상 녹화와 trace를 켜고, 결과 영상 위치를 알려줘.
운영 배포 승인 버튼은 절대 누르지 말고, 운영 환경에는 아무것도 배포하지 마.

🔍 읽는 포인트 : "*는 쓰지 마"(2.2), "E2E는 하나만"(4.3), "운영 배포 승인 버튼은 절대 누르지 마"(3.3)가 이 차시의 세 원칙을 지시로 옮긴 것입니다.

받을 증거

• 연결 점검 표 (여섯 항목, 근거 칸 채움)
• 미리보기 주소 하나, 스테이징 주소
• 병합 후 자동 배포 Actions 실행 화면 주소와 스모크 · E2E 출력 원문
• E2E 녹화 영상 파일 위치
• 운영 배포가 승인 대기 로 멈춰 있는 화면

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 22차시 노트만 근거로 5문제를 내줘. 비전공자 기준으로.
"CORS가 무엇이고 무엇이 아닌가", "자동 배포 흐름에서 사람이 남는 두 자리", "E2E를 영상으로 확인하는 이유"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.