정적과 동적 — 모델링과 하네스 구조

9. 정적과 동적 — 세 층위에서 반복되는 하나의 축

9.1 3계층 매핑표

이 장 축 4의 완성판입니다. 완전히 달라 보이는 세 쌍이 실은 같은 축입니다.

핵심 요약: 세 쌍 모두 "처음 정해진 규칙·기록을 고수하느냐(정적)" 와 "프로그램이 실행되거나 사용자가 개입하면서 실시간 상태를 반영하느냐(동적)" 의 차이로 완벽하게 관통됩니다.

⚠️ Attribute와 Property는 자주 같은 말로 번역되지만 다릅니다. HTML에 value="홍길동" 이라고 적혀 있어도, 사용자가 입력창에 다른 걸 타이핑하면 Attribute는 그대로고 Property만 바뀝니다. 크롤링할 때 "HTML에는 있는데 화면 값과 다르다"는 상황이 여기서 나옵니다.

9.2 공장으로 보기

[ 정적 영역: 변하지 않는 틀 ]              [ 동적 영역: 살아 움직이는 상태 ]
┌───────────────────────────┐            ┌───────────────────────────┐
│ • HTML 소스 코드           │            │ • 브라우저 렌더링 화면      │
│   (Attribute: value="홍길동")│── 로드 ──▶│   (Property: 사용자 입력값)  │
├───────────────────────────┤            ├───────────────────────────┤
│ • 클래스 설계도            │  인스턴스   │ • 실제 생성된 인스턴스      │
│   (Class 변수: maker="Apple")│── 생성 ──▶│   (Instance 변수: 개별 색상) │
├───────────────────────────┤            ├───────────────────────────┤
│ • 컴파일 / 초기화 단계      │  런타임    │ • 런타임 (실행 중)          │
│   (상수: 변하지 않는 기준값) │── 연산 ──▶│   (변수: 수시로 변하는 결과)  │
└───────────────────────────┘            └───────────────────────────┘

설계도(정적) 와 설계도로 만든 제품의 상태(동적) 의 관계입니다. 3주차의 클래스 ↔ 인스턴스, 디스크 ↔ 메모리와 같은 계열이지만, 이번에는 한 객체 안에서도 이 구분이 반복된다는 점이 새롭습니다.

9.3 집짓기로 다시 보는 객체지향

같은 구조를 건축 비유로 정리한 그림도 함께 붙잡아 둡시다.

3주차의 메모리 3영역과 짝을 지으면 이렇게 됩니다.

9.4 코드(레포지토리) ↔ 데이터(데이터베이스)

정적/동적 축의 가장 큰 스케일 버전입니다. 시스템 전체가 이 축으로 두 덩어리로 갈립니다.

+------------------------------------------------------------------------+
|                          APPLICATION SYSTEM                            |
+------------------------------------------------------------------------+
|    [ 코드 / 레포지토리 ]                      [ 데이터 / 데이터베이스 ]  |
|   +---------------------+                    +--------------------+    |
|   |    Code (로직)       |                    |    Data = State    |    |
|   |  (어떻게 움직이는가)   |                    | (현재 어떤 상태인가) |    |
|   +----------+----------+                    +----------+---------+    |
|              |                                          |              |
|              v                                          v              |
|   +---------------------+                    +--------------------+    |
|   | Repository (저장소)  |                    | Database (기록소)   |    |
|   |    GitHub / Git     |                    |  RDBMS / NoSQL 등   |    |
|   +----------+----------+                    +----------+---------+    |
|              |                                          |              |
|              +---------------------+--------------------+              |
|                                    v                                   |
|                        [ 런타임 (Runtime) 결합 ]                        |
|                    코드가 실행되면서 데이터의 상태를                       |
|                     조회(Read) 및 변경(Write) 수행                       |
+------------------------------------------------------------------------+

두 흐름

① 개발 및 배포 단계 (정적 제어)

1. 개발자가 기능을 구현하려고 코드(Code) 를 작성합니다.
2. 코드는 버전 관리를 위해 레포지토리(Repository) 에 push되어 누적됩니다.
3. 검증된 코드는 CI/CD 파이프라인을 거쳐 운영 서버 환경에 배포됩니다.

② 실행 및 가동 단계 (동적 제어)

1. 사용자가 서비스에 접속해 요청(Request)을 보냅니다.
2. 서버에서 실행 중인 코드(로직) 가 요청을 해석합니다.
3. 코드는 규칙에 따라 데이터베이스에 접근해 현재 상태(State) 를 읽거나(Read) 갱신합니다(Write/Update).
4. 갱신된 최종 상태값(data = state)이 다시 사용자에게 전달됩니다.

아키텍처 관점의 요약 레포지토리는 "데이터를 어떻게 다룰 것인가?" 에 대한 행동 지침(코드)을 보관하는 곳입니다. 데이터베이스는 그 지침에 따라 가동된 시스템의 "현재 결과와 살아있는 상태(State)" 를 보관하는 곳입니다. 소프트웨어 공학은 레포지토리의 깔끔한 소스코드 관리를 통해 데이터베이스의 안전하고 정확한 상태 관리를 달성하는 것을 목표로 합니다.

3주차 9.7절에서 배운 "Base는 기초가 아니라 거점·저장소" 라는 감각이 여기서 다시 쓰입니다. Repository도 Database도 나갔다가 돌아오는 거점입니다. 하나는 코드가, 하나는 데이터가.

---

10. 모델링 — 개체를 객체로

10.1 모델링이란 무엇인가

모델링 — "복잡한 현실 세계의 대상을 컴퓨터가 이해하고 처리할 수 있도록, 핵심만 뽑아내어 구조(틀)를 짜는 과정"

한 줄 더 붙이면: 모델이 인식하기 좋은 형태로 데이터를 편집하는 일입니다.

ERD 작업이 곧 모델링입니다.

ERD 작업 = 모델링 = 개체를 객체로 = 설계도

10.2 왜 개체를 객체화하는가

이유는 하나입니다.

서로 언어가 다르기 때문에, 통일시켜서 AI(머신)가 활용할 수 있도록 하기 위해서입니다.

• 프론트엔드는 자바스크립트 객체로 말합니다.
• 백엔드는 파이썬 객체로 말합니다.
• 데이터베이스는 테이블 행으로 말합니다.

세 언어가 다르니, 하나의 공통 모델을 먼저 정해 두고 각자 그것으로 번역합니다. 그 공통 모델이 ERD입니다. 그래서 ERD를 그리는 일이 "그림 그리기"가 아니라 세 계층이 같은 단어를 쓰게 만드는 작업인 것입니다.

3주차 DDD에서 배운 보편적 언어(Ubiquitous Language) 가 여기서 실제 도구로 내려온 셈입니다.

10.3 ⚠️ 정규화는 두 종류다 — 완전히 다른 것

정규화(Normalization) 는 IT에서 두 도메인(RDB, ML)에 따라 완전히 다른 의미로 쓰입니다. 같은 단어라서 섞이면 대화가 통째로 어긋납니다.

A. 관계형 데이터베이스(RDB)의 정규화

데이터베이스의 중복을 최소화하고 데이터 무결성(정확성·일관성)을 유지하기 위해 테이블 구조를 최적화하는 과정입니다. 주 목적은 삽입·갱신·삭제 시 발생하는 이상 현상(Anomaly) 방지입니다.

💡 실무 팁: 정규화 수준이 높아질수록 무결성은 완벽해지지만, 테이블 파편화로 JOIN 연산이 많아져 조회 성능이 떨어질 수 있습니다. 그래서 실제 서비스에서는 의도적으로 구조를 단순화하는 반정규화(Denormalization) 를 하기도 합니다.

B. 머신러닝(ML)의 정규화 = 피처 스케일링 (Feature Scaling)

DB에 적재된 로우 데이터를 가져와, ML 모델이 학습하기 좋게 데이터의 스케일(범위)을 일정하게 맞추는 전처리입니다. 서로 다른 컬럼(예: 나이 20~60, 연봉 3,000만~1억)의 숫자 크기 차이 때문에 특정 피처가 과도한 영향력을 갖는 것을 막습니다.

한 표로 구분

⚠️ 면접이나 회의에서 "정규화했어요"라고만 말하면 상대가 어느 쪽인지 모릅니다. 반드시 앞에 도메인을 붙이세요.

10.4 식별관계와 비식별관계 — 3주차 실선/점선의 회수

3주차 3.2절에서 이렇게 예고했습니다.

이 실선/점선 구분은 데이터베이스 설계의 식별 관계 / 비식별 관계와 정확히 대응됩니다. 실선은 실선끼리, 점선은 점선끼리 만납니다. 우연이 아닙니다 — 둘 다 "이것 없이 저것이 존재할 수 있는가"라는 같은 질문을 묻고 있기 때문입니다.

이제 그 약속을 지킵니다.

A. 식별 관계 (Identifying Relationship) ─── [실선]

• 개념: 부모 테이블의 기본키(PK)가 자식 테이블의 외래키(FK)가 됨과 동시에 자식의 기본키(PK) 영역의 일부로 편입되는 관계.
• OOP 대응: HAS-A (포함 / 컴포지션)
• 생명주기: 자식이 부모에 강하게 종속됩니다. 부모가 삭제되면 자식도 독립적으로 존재할 수 없습니다. 자식 고유의 ID가 단독으로 존재하지 못하고 부모 ID와 묶여야만 성립합니다.
• 예시: 주문 테이블 (PK: 주문번호) ── 주문상세 테이블 (PK: 주문번호 + 순번)

B. 비식별 관계 (Non-Identifying Relationship) ╌╌╌ [점선]

• 개념: 부모의 PK가 자식의 기본키가 되지 않고, 일반 데이터 컬럼(일반 외래키, FK)으로만 연결되는 관계.
• OOP 대응: USES-A (의존 / 사용) 또는 IS-A (상속 / 카테고리 분류)
• 생명주기: 자식은 자신만의 고유한 독립 ID(PK) 를 명확히 보유합니다. 부모와의 연관성은 비즈니스 로직 연계를 위한 참고용 필드일 뿐이므로, 부모가 삭제·변경되어도 자식은 독립적으로 살아남고 NULL 을 허용할 수도 있습니다.
• 예시: 부서 테이블 (PK: 부서코드) ╌╌ 사원 테이블 (PK: 사원번호 / FK: 부서코드)

매핑 구조도

⭐ 왜 우연이 아닌가 두 세계가 묻는 질문이 같기 때문입니다: "이것 없이 저것이 존재할 수 있는가?" 존재할 수 없으면 실선(강한 결합), 존재할 수 있으면 점선(약한 결합). 3주차에서는 메모리(Heap/Stack) 로, 이번 주에는 테이블(PK/FK) 로 물었을 뿐입니다.

10.5 열쇠 색으로 구분하기 — ERDCloud 실전

ERD 도구에서 관계를 맺으면, 자식 테이블에 생기는 열쇠 아이콘의 색이 달라집니다. 눈으로 바로 확인할 수 있습니다.

• 파란색 열쇠 = 식별 관계 — 부모의 PK가 자식으로 내려가 FK이면서 동시에 PK의 일부가 됩니다. 자식은 노란 열쇠(자기 키) + 파란 열쇠(부모 키)가 묶여 복합 기본키를 구성합니다. 부모 데이터가 없으면 자식도 독립 존재 불가(강한 종속).
• 핑크색 열쇠 = 비식별 관계 — 부모의 id 가 자식의 일반 속성 영역의 FK로만 내려갑니다. 자식은 자신만의 id 를 독립적으로 가집니다. 부모가 없어도 독립 존재 가능(느슨한 관계).

⚠️ 관계선이 갑자기 사라지는 현상을 만나면, 대개 자식 테이블에 복합키 구조가 들어갈 공간·제약 조건이 엉킨 것입니다. 도구 버그로 의심하기 전에 자식의 PK 구성을 먼저 확인하세요.

10.6 ★ 현대적 권장안 — 비식별 관계 + 단일 대리키

Q. 식별 관계에서 부모키를 그대로 쓰는 것 vs 복합키로 묶는 것?

식별 관계 패러다임을 꼭 고수해야 한다면 부모키를 포함한 복합키 형태가 정석입니다. 부모키를 그대로 단일키로 쓰는 구조는 오직 1:1 관계에서만 성립하므로 비즈니스 확장성이 심각하게 저해됩니다.

★ 최종 권장안: 비식별 관계 + 단일 대리키(Surrogate Key)

현대적인 대규모 백엔드 아키텍처와 ORM(JPA, SQLAlchemy) 환경에서는 식별 관계 작성을 최소화하고, 모든 테이블에 인공적인 단일 대리키(id)를 부여한 뒤 비식별 관계(점선)로 연결하는 설계 패턴을 강력히 권장합니다.

[권장되는 테이블 설계 패턴]
- id (PK)      : 시스템이 자동 생성하는 단일 대리키 (Auto-Increment, UUID 등)
- 부모_id (FK) : 상위 테이블과 느슨하게 연결하는 비식별 외래키
- 일반 데이터 컬럼들...

세 가지 이유

1. PK BLOAT 방지 — 식별 관계를 남발하면 자식의 자식(3대, 4대)으로 갈수록 부모들의 PK가 누적되어 복합 기본키가 매우 비대해집니다. SQL 쿼리가 복잡해지고 인덱스 저장 공간이 낭비됩니다.
2. ORM 궁합 — 모든 테이블의 PK를 id 단일 컬럼으로 통일하면 최신 ORM과의 궁합이 극대화되어 코드 생산성이 대폭 향상됩니다.
3. 확장 대응 — MSA나 데이터베이스 샤딩 등 트래픽 확장 상황에서 훨씬 유연합니다.

OLD (COMPOSITE KEY)                     MODERN (SURROGATE KEY)
GrandparentPK → ParentPK → ChildPK      모든 테이블에 id + FK
        ⇒ PK BLOAT                      UUID / AUTO-INC, ORM 친화
                                        ⇒ CLEAN, FLEXIBLE, ORM-FRIENDLY

이 원칙은 실습에서 ENTITY_RULE.md 규칙으로 직접 코드화됩니다(12.5절).

---

11. 하네스 엔지니어링 4대 구조

11.1 하드웨어 구조로 보는 소프트웨어 아키텍처

이 주까지 배운 네 개의 구조를 한 그림에 놓으면 이렇게 됩니다.

  [ 무상태 프론트엔드 ]  ← 화면은 기억 없이 데이터가 주는 대로만 찍어냄
          │
          ▼  (하네스 엔지니어링: 데이터를 규격화된 케이블 묶음으로 안전하게 전송)
          │
  [ 모듈러 모놀리식 백엔드 ]
   └── 📦 하나의 큰 서버 덩어리 내부가 독립된 방(모듈)으로 쪼개져 있음
        ├── 🧩 회원 관리 모듈    (객체지향: 회원 부품, 인증 부품들이 협력)
        ├── 🧩 공장 시뮬레이션 모듈 (객체지향: 기계 부품, 레이아웃 부품들이 협력)
        └── 🧩 알림 모듈

11.2 네 구조와 각각의 틀·알맹이

3.2절에서 배운 "틀(상수) 안에 알맹이(변수)" 라는 렌즈로 네 구조를 전부 읽을 수 있습니다.

요약 가이드: 외부 규격은 상수, 내부는 함수, 괄호가 없으면 속성.

11.3 왜 이 넷이 한 묶음인가

넷은 서로 다른 층에 있지만, 하나의 문장을 각자의 자리에서 실행하고 있습니다.

"틀은 고정하고, 알맹이만 바꾼다."

• 프론트엔드는 렌더링 규칙을 고정하고 데이터만 바꿉니다.
• 하네스는 인터페이스를 고정하고 전송 내용만 바꿉니다.
• 모듈러 모놀리식은 배포 단위를 고정하고 내부 모듈만 바꿉니다.
• 객체지향 백엔드는 클래스 정의를 고정하고 인스턴스 값만 바꿉니다.

이것이 3주차에서 배운 전략 패턴 / DIP / IoC / DI / 포트&어댑터가 말하던 "쓰는 쪽은 인터페이스만 알고, 실제 물건은 밖에서 넣어준다" 와 정확히 같은 문장입니다. 층만 다를 뿐, 소프트웨어 공학 전체가 이 한 문장의 변주입니다.

---

12. 실습 — 이번 주에 손으로 한 것

12.1 회원가입 화면 만들기

가장 먼저 만든 것은 화면입니다. 이 주 전체의 예제가 되는 화면입니다.

프롬프트

회원가입 창에 값을 입력한 후 회원가입 버튼을 클릭하면
입력된 값이 보여지는 알러트창(alert) 이 나오도록 해줘.

이 한 줄짜리 실습이 왜 중요한가:

• alert() 은 괄호가 있으므로 기능입니다(3.1절).
• 입력된 값은 괄호가 없는 속성입니다.
• 버튼 클릭은 이벤트이고, 그것을 받는 함수가 핸들러입니다(7.4절).
• 그리고 이 폼에 e.preventDefault() 가 왜 필요한지가 곧바로 문제가 됩니다(7.5절).

한 줄의 프롬프트로 이 장의 절반이 손에 잡힙니다.

12.2 보안 시스템 DB — 레이어드 구조로 만들기

프롬프트

사용자 그룹을 관리자 / 일반유저 두 그룹으로 테이블을 구성해줘.
속성은 id=a, password=a, nickname=a, email=a@b 이고,
여기에 role 을 추가해서 각각 admin, user 로 등록되도록
controller / service / repository / model 을 작성해줘.

여기서 나온 네 개의 폴더가 백엔드 레이어드 아키텍처입니다.

⚠️ Repository에서 비밀번호 규칙 같은 업무 판단을 하면 안 됩니다. 그건 Service/Domain의 일입니다. Service는 무엇을 저장할지 정하고, Repository는 어떻게 저장할지만 압니다.

12.3 파이프라인 경로 확인 — 레이어 통과 로그

레이어를 나눴으면, 데이터가 실제로 그 길을 지나는지 눈으로 확인해야 합니다.

프롬프트

controllers/user_controller.py, services/user_service.py, repositories/user_repository.py 의
각 레이어 save_user 를 지날 때마다 통과 로그와 내부 값을 출력해줘.

⚠️ 단, print 는 쓰지 않습니다.

불필요한 코드는 삭제하고, 절대 print 하지 말고 logger 로 출력해줘.

import logging

logger = logging.getLogger(__name__)

logger.info("[UserController] save_user 레이어 완료 — userId=%s", user_schema.userId)

왜 print 대신 logger 인가

💡 %s 포맷을 쓰는 이유: logger.info("... %s", value) 는 그 로그 레벨이 켜져 있을 때만 문자열을 조합합니다. f-string으로 미리 만들면 로그를 끄더라도 문자열 조합 비용이 계속 발생합니다.

이 로그 한 줄씩을 붙이면, 1절의 파이프라인 그림이 터미널에서 실제로 흐르는 것을 볼 수 있습니다.

12.4 Alembic — DB 스키마 버전 관리

테이블 구조를 바꿔야 할 때, 운영 DB에 직접 ALTER TABLE 을 치는 것은 위험합니다. 되돌릴 수 없고, 다른 개발자의 로컬 DB와 어긋나기 때문입니다.

Alembic — [DB 스키마 마이그레이션(버전 관리) 도구]인데, [SQLAlchemy 전용]이라는 점에서 다른 마이그레이션 도구와 구별된다.

코드에 Git이 있다면, DB 스키마에는 Alembic이 있습니다. 9.4절의 "코드는 형상 관리, 데이터는 마이그레이션"이 여기서 실물이 됩니다.

# 1. 환경 초기화 — alembic 폴더와 설정 파일이 생성됩니다
alembic init alembic

# 2. 모델 변경을 추적해 버전(리비전) 파일 생성
alembic revision --autogenerate -m "add age column to users table"

# 3. 실제 DB에 적용
alembic upgrade head

⚠️ --autogenerate 는 모델(코드)과 DB의 차이를 자동으로 감지합니다. 따라서 모델 파일이 Alembic 설정에 제대로 import되어 있어야 합니다. 안 그러면 "변경 없음"으로 나옵니다.

🔗 https://wikidocs.net/226764

12.5 ENTITY_RULE.md — 모든 테이블의 PK를 id 로 통일

10.6절의 권장안을 프로젝트 규칙 파일로 못 박는 작업입니다.

프롬프트

모든 테이블에 int 인덱스를 두고 이름을 id 로 통일하는 규칙을 @ENTITY_RULE.md 에 추가해줘.

id: Optional[int] = Field(
    default=None,
    primary_key=True,
    sa_column_kwargs={"name": "id"}   # DB 컬럼명: id
)

⭐ 이 파일이 하네스입니다. 3주차에서 배운 하네스 엔지니어링은 "규격화된 통로를 만들어 두는 일"이었습니다. ENTITY_RULE.md 는 AI와 사람이 같이 읽는 규격서입니다. 이걸 만들어 두면 이후 생성되는 모든 테이블이 같은 모양을 갖습니다. 마크다운으로 쓰는 이유도 3주차 11.2절에서 배운 그대로입니다 — 사람과 AI가 함께 읽을 문서이기 때문입니다.

12.6 프로젝트 구조 정리 — 지침 파일을 루트로

AI 지침 파일들이 하위 폴더에 흩어져 있으면, AI가 프로젝트 전체를 하나의 객체로 인식하지 못합니다.

• backend 내부의 .cursorrules, AGENTS.md, CLAUDE.md, CURSOR.md 를 프로젝트 루트로 이동합니다.
• 💡 커서를 닫고 드래그앤드랍한 뒤 다시 여는 것이 확실합니다. 열려 있는 상태로 옮기면 인덱스가 꼬일 수 있습니다.

멀티 에이전트 구성을 위한 프롬프트

@file:.cursorrules 를 커서가 참조한 후
반드시 @docs 내부를 통해 코딩 규칙을 인지하도록 코드를 작성해줘

3주차 9.5절 "AI가 프로젝트를 읽는 순서"(.cursorrules → README.md → __init__.py → requirements.txt → 코드)를 실제로 성립시키는 작업입니다. 파일이 루트에 있어야 1번이 성립합니다.

12.7 안티그래비티(Antigravity) 2.0 설치

에이전트 우선(agent-first) 개발 플랫폼입니다. 여러 자율 에이전트를 병렬로 오케스트레이션합니다.

설치 절차

1. https://antigravity.google/download 접속 → Antigravity 2.0 섹션에서 OS 선택 (Windows는 x64 / ARM64)
2. Antigravity.exe 실행해 설치
3. 좌측 메뉴 확인: New Conversation, Conversation History, Scheduled Tasks, Projects, 하단 Settings
4. 하단 입력창 위 Select Project → No projects found 상태에서 New Project(기존 폴더로 프로젝트 생성) 선택
5. 폴더 선택 창에서 작업 폴더 선택 → 하단 선택 버튼 → Create Project 창에서 폴더 확인 후 Create

설정 확인

⚠️ Security Preset을 Unrestricted 로 두지 마세요. 에이전트가 기계 전체에 접근합니다. 기본값에서 시작해 필요한 만큼만 엽니다.

첫 프롬프트 예시

안티그래비티, 이제부터 이 프로젝트의 프론트엔드와 백엔드 코딩을 이어받아 진행한다.
코드를 작성하거나 수정할 때 반드시 프로젝트 루트의 ./AGENTS.md 프로토콜을 따르고,
프론트엔드 수정 시에는 ./docs/DevOps/Frontend/REACT_RULES.md 를 먼저 읽고 반영해라.
지시한 두 문서를 읽고 이해했는지 확인한 뒤, 각 문서의 핵심 규칙을 요약해줘.

💡 "읽고 이해했는지 확인한 뒤 요약해줘" 가 이 프롬프트의 핵심입니다. AI가 지침을 실제로 읽었는지 증거를 요구하는 것입니다. 그냥 "지침을 따라줘"라고 하면 따랐는지 알 수 없습니다.

12.8 타이타닉 프로젝트 — 문제 정의와 화면 구성

이 주부터 타이타닉 데이터가 본격적인 프로젝트가 됩니다.

문제 정의

• 사건: 1912년 4월 10일 Southampton 출항, 4월 15일 침몰
• 문제 유형: 생존 여부를 종속변수로 하는 이진 분류(Binary Classification)
• 종속변수: Survived (1 = 생존, 0 = 사망)

⚠️ 3주차 10.1절에서 배운 대로, 공학적으로 설계하고 리버럴 관점으로 해석해야 합니다. Sex 가 강한 예측력을 갖는 이유는 성별 자체가 아니라 "여성과 어린이 먼저" 라는 구명정 배정 규칙 때문입니다.

폴더 구조

secom 폴더의 레이어드 구조를 참조해 titanic 폴더를 구성합니다. 이미 만들어 둔 레이어드 구조(controller / service / repository / model)를 템플릿처럼 복제하는 것입니다. 이것이 3주차 6.4절에서 배운 표준 보일러플레이트의 실제 사용법입니다.

화면 구성 프롬프트

[타이타닉] 메뉴 구성
(1) 메뉴 끝에 "수업용"을 추가하고, 클릭 시 lesson 페이지로 이동하게 해줘.
(2) 사이드 메뉴 맨 위에 "타이타닉"을 추가하고, 클릭 시 모델 분석 화면으로 이동하게 해줘.

[타이타닉] 데이터 수집 화면
사이드 메뉴 우측 끝 > 를 클릭하면 90도 회전하며 하부 메뉴가 노출되고,
"1. 데이터 수집"을 클릭하면 드래그앤드랍 / 파일선택 방식의 업로드 화면이 나오게 해줘.

수집한 캐글 CSV는 Neon에 insert 합니다. 3주차 12.3절에서 만들어 둔 비동기 커넥션이 여기서 처음으로 실제 데이터를 나릅니다.

💡 > 아이콘이 90도 회전한다는 지시가 좋은 프롬프트인 이유: 상태 변화(닫힘 ↔ 열림)를 시각적으로 어떻게 표현할지까지 지정했기 때문입니다. 7.6절의 단방향 흐름 그대로 — 상태가 바뀌고, 화면(회전)이 따라옵니다.

12.9 ERD 수동 작성 — ERDCloud

🔗 https://www.erdcloud.com/

10절에서 배운 식별/비식별 관계를 실제로 그어 보는 도구입니다. 자동 생성에 의존하지 말고 한 번은 손으로 그려 보세요. 열쇠 색이 바뀌는 것을 눈으로 봐야 개념이 붙습니다.

12.10 제미나이 SDK 설치와 환경변수 주의

설치와 확인

npm install @google/generative-ai
npm list @google/generative-ai

npm list 로 설치가 실제로 됐는지 확인하는 습관을 들이세요. 설치 로그가 지나가 버리면 확인할 방법이 없습니다.

⚠️ 환경변수 — 이 주에서 가장 중요한 보안 규칙

GEMINI_API_KEY=your_actual_gemini_api_key_here

⛔ 절대로 NEXT_PUBLIC_ 접두사를 붙이지 마세요.

Next.js는 NEXT_PUBLIC_ 이 붙은 환경변수를 클라이언트 코드에 그대로 심어서 빌드합니다. 개발자 도구를 열면 키가 보입니다. 3주차 13.3절에서 배운 대로, 키 하나가 새면 법적 책임이 따라옵니다.

⭐ 판별 기준: 이 값이 브라우저에 보여도 되는가? 안 되면 NEXT_PUBLIC_ 은 절대 금지입니다.

12.11 Vercel + 가비아 도메인 연결 — 4단계

배포된 프론트엔드에 내 도메인을 붙이는 절차입니다.

사전 준비: v0 프로젝트를 GitHub와 연결

• v0 좌측 Projects → + Project → Import from GitHub → Import from a URL 에 깃허브 HTTPS 주소를 붙여넣고 Import
• 이미 연결된 경우 Connect to Existing Project 화면에서 대상 프로젝트와 Base Branch: main 확인 후 Continue (처음이면 새로 생성됨)
• ⏱ Clone·프리뷰 로딩에 1~5분 걸립니다. 멈춘 게 아니니 기다리세요.

1단계: Vercel에서 도메인 추가 프로젝트 → Settings → Domains → 입력창에 도메인 입력 후 Add → 유형 선택 시 보통 첫 항목 Redirect www.my-domain.com to my-domain.com(권장)을 선택합니다.

2단계: Vercel이 주는 DNS 값 확인

3단계: 가비아에서 DNS 설정 [My가비아] → [도메인 관리] → 체크 후 [DNS 정보 설정] → [레코드 수정]

📌 이미 @ 나 www 호스트로 등록된 기존 레코드가 있으면 삭제·수정해야 충돌이 없습니다. 입력 후 반드시 [저장]을 누르세요.

4단계: 확인 DNS 전파에 최소 5분 ~ 최대 1~2시간 걸립니다. Vercel 화면의 빨간 경고가 사라지고 Valid Configuration(녹색)이 되면 성공입니다.

⚠️ DNS는 즉시 반영되지 않습니다. 5분 만에 안 된다고 설정을 다시 만지면 오히려 더 늦어집니다. 한 번 저장했으면 기다리세요.

12.12 버셀에서 재배포하기

코드를 고쳤는데 배포 화면이 그대로라면, 재배포가 안 된 것입니다. 3주차 12.9절에서 배운 대로, git push 만으로 끝났다고 생각하지 말고 다음을 확인합니다.

1. Vercel 대시보드에서 자동 빌드·배포 로그 확인
2. 배포된 프론트가 localhost:8000 이 아닌 운영 API 주소를 보고 있는지, CORS 가 맞는지 확인
3. 배포 환경의 환경변수 점검 (로컬 .env 는 배포 서버에 따라가지 않습니다)

---

13. 이 주의 읽을거리와 그 맥락

13.1 삼위일체와 《삼체》 — 왜 셋인가

• 서양 삼위일체 세계관과 SF 소설 《삼체》의 "세 개로 이뤄진 일체" 개념
• 서구 유럽이 반도체 팹을 못 만드는 이유

이게 왜 이 주에 나왔는가: 이번 주의 뼈대가 함수 → 객체 → 개체라는 셋이기 때문입니다. 서구 사고는 하나를 셋으로 나누되 그 셋이 하나임을 유지하는 방식을 오래 다뤄 왔습니다. MVC도, D-M-V-C도, 자원·행위·표현(REST 3요소)도, Notation·Modeling·Objectification도 전부 이 감각 위에 서 있습니다.

그래서 이 주의 아키텍처 그림에는 아예 "THE THREE-BODY ARCHITECTURE" 라는 이름이 붙었습니다.

1. FUNCTION (f(x)) : HTML / FRONTEND    →  f(x) = ∫ chaotic_data_input dx
2. OBJECT          : PYTHON / BACKEND   →  class ObjectProcessor: def refine_data(self): ...
3. ENTITY          : SQL / DATABASE     →  INSERT INTO Entity_Records SELECT * FROM ...

세로 단계는 RAW INPUT → PROCESSING → STORED DATA. 1절의 그림과 같은 그림입니다.

반도체 팹 이야기가 붙은 이유는 "설계와 제조는 다른 역량" 이라는 점 때문입니다. 아키텍처를 그릴 줄 아는 것과 실제로 돌아가게 만드는 것은 다른 일입니다. 12절의 실습이 필요한 이유이기도 합니다.

13.2 CS 기초 쇼츠 세 편

• 프로세스가 쓰레드의 집합으로 정의되는 이유 — 프로그래밍을 실(=쓰레드)로 한다는 비유 🔗 https://youtube.com/shorts/pjL0rWzpJ1s
• HTTP 프로토콜 🔗 https://youtube.com/shorts/0UfTQsHHaQs
• 멱등성(Idempotency) 🔗 https://youtube.com/shorts/bAdJC-RpzOE

이게 왜 이 주에 나왔는가: 세 편이 각각 이 장의 세 절을 보충합니다. 쓰레드 편은 3주차 2.8절의 복습이자 8절 메모리 이야기의 예열이고, HTTP 편은 5.1절, 멱등성 편은 5.4절입니다. "프로그래밍을 실로 한다" 는 비유는 특히 좋습니다 — 여러 가닥의 실이 하나의 천(프로세스)을 이룬다는 그림이 스레드의 본질입니다.

13.3 JSON 공식 홈페이지

🔗 https://www.json.org/json-en.html

이게 왜 이 주에 나왔는가: 6.2절에서 배운 대로 JSON은 표기법(Notation) 입니다. 표기법은 원전을 한 번 봐야 합니다. 이 페이지에는 JSON의 전체 문법이 철도 다이어그램 한 장으로 그려져 있습니다. 문법 전체가 한 화면에 들어간다는 사실 자체가, JSON이 얼마나 단순한 규칙인지를 보여 줍니다.

13.4 자바스크립트 클로저

🔗 https://inpa.tistory.com/entry/JS-📚-클로저

이게 왜 이 주에 나왔는가: 8절 전체의 원전입니다. 클로저는 파이썬과 자바스크립트에서 똑같이 동작하는 몇 안 되는 개념 중 하나입니다. 프론트와 백엔드를 오가며 개발할 때, 이 개념 하나로 양쪽 코드를 같은 눈으로 읽을 수 있습니다.

13.5 바이브 코딩이 바꾼 Z세대 놀이 문화

🔗 https://www.careet.net/1909

이게 왜 이 주에 나왔는가: 이 주에 우리는 프롬프트 몇 줄로 회원가입 화면과 레이어드 백엔드를 만들었습니다. 그 방식이 이미 놀이 문화가 되어 있다는 사회 관찰 자료입니다. 기술 문서가 아니라 문화 문서라는 점이 중요합니다. 도구가 대중화되면 판단 기준을 가진 사람과 아닌 사람의 격차가 벌어집니다. 이 교재가 판별 축부터 가르치는 이유가 여기 있습니다.

13.6 구글 I/O '26 — 제미나이 3.5 플래시와 안티그래비티 2.0

구글이 제미나이 3.5 플래시와 안티그래비티(Antigravity) 2.0 을 공개했습니다. 안티그래비티는 여러 자율 에이전트를 병렬로 오케스트레이션하는 '에이전트 우선(agent-first)' 개발 플랫폼입니다.

이게 왜 이 주에 나왔는가: 3주차에서 배운 하네스 엔지니어링의 다음 단계입니다. 하네스가 "AI를 안전하게 붙들어 쓰는 체계"였다면, 안티그래비티는 "여러 AI를 동시에 부리는 체계" 입니다. 그래서 이 도구의 첫 화면에 Scheduled Tasks 와 Security Preset 이 있는 것입니다 — 자율성이 커질수록 통제 장치가 앞으로 나옵니다.

📎 설치 절차는 12.7절에 정리했습니다.

13.7 안드레이 카파시, 앤트로픽으로 이적

이게 왜 이 주에 나왔는가: 3주차 9.5절에서 CLAUDE.md 를 만들 때 "카파시의 의도대로 작성되었는지 체크해줘" 라는 프롬프트를 썼습니다. 그가 만든 AI 코딩 워크플로 감각이 이 수업의 작업 방식에 이미 들어와 있습니다. 사람의 이동은 어떤 방법론이 어디로 옮겨 가는지의 신호입니다. 도구 뉴스보다 사람 뉴스가 더 오래 유효합니다.

13.8 도구 문서 두 편

• Alembic 마이그레이션 🔗 https://wikidocs.net/226764
• ERD 수동 작성 (ERDCloud) 🔗 https://www.erdcloud.com/

이게 왜 이 주에 나왔는가: 10절(모델링)과 12.4절(스키마 버전 관리)은 같은 이야기의 앞뒤입니다. ERDCloud로 설계하고, Alembic으로 그 설계의 변경 이력을 관리합니다. 설계 없이 마이그레이션만 하면 어디로 가는지 모르고, 설계만 하고 마이그레이션이 없으면 첫 배포 이후 손댈 수 없습니다.

---

부록 A. 용어 사전

---

부록 B. 스스로 확인하기

먼저 답해 보고, 막히면 옆의 절을 펼치세요.

---

부록 C. 자주 하는 실수

---

부록 D. 날짜별 색인

이 장의 내용이 실제 수업에서 어느 날 다뤄졌는지입니다.

---

부록 E. Gemini / NotebookLM 프롬프트

복습 문제 받기

이 4주차 교재만 근거로 8문제를 내줘. 비전공자 기준으로.
"Stateless가 무엇에 대한 말인가"와 "식별관계 vs 비식별관계"는 반드시 포함해줘.
답은 바로 주지 말고, 내가 답한 다음에 채점하고
틀린 이유를 교재의 어느 절을 근거로 설명해줘. 교재에 없는 내용은 꺼내지 마.

인포그래픽 ① — 이 장의 중심 흐름

「1. 이 주의 큰 그림」을 가로 흐름도 인포그래픽 1장으로 만들어줘.
- 함수(Frontend/HTML) → 객체(Backend/Python) → 개체(Database/SQL) 3단계
- 두 화살표 위에 연결고리 A(API: GET/POST)와 B(커넥션: ORM)를 크게 표시
- 각 단계 아래에 하는 일 3가지씩 (수집·정형화 / 정제·AI연산 / 영구저장·테이블화)
- 데이터의 형태 변화(Raw Data → JSON → 메모리 객체 → 테이블 행)를 아래 띠로
- 전문용어는 한글(영문) 병기

인포그래픽 ② — Stateless 오해 바로잡기

「4.2 Stateless 오해 바로잡기」를 인포그래픽 1장으로 만들어줘.
- 왼쪽에 프론트엔드(다크모드·장바구니·입력창) = STATEFUL
- 오른쪽에 백엔드·DB(회원정보·게시글) = STATEFUL
- 가운데 통신 구간만 STATELESS 로 색을 다르게
- "서버는 아까 그 사람을 기억하지 않는다. 매번 신분증을 요구한다"를 말풍선으로
- 아래에 무상태의 장점 3가지(확장성·안정성·단순성)

인포그래픽 ③ — 정적 vs 동적 3계층

「9.1 3계층 매핑표」를 좌우 대비 인포그래픽으로 만들어줘.
왼쪽은 정적(Attribute / Class변수 / 상수), 오른쪽은 동적(Property / Instance변수 / 변수).
가운데에 전이 화살표와 그 이름(LOAD / INSTANCE / RUN-TIME)을 넣어줘.
세 줄이 같은 축의 반복임이 한눈에 보이게 색을 통일해줘.

인포그래픽 ④ — 식별관계와 비식별관계

「10.4~10.6」을 인포그래픽 1장으로 만들어줘.
- 위쪽: 식별관계(실선, 파란 열쇠, PK+FK, HAS-A, 부모 없으면 존재 불가)
- 아래쪽: 비식별관계(점선, 핑크 열쇠, FK만, USES-A/IS-A, 독립 존재 가능)
- 오른쪽에 "OLD: 복합키 → PK BLOAT" vs "MODERN: 대리키 id → ORM 친화" 비교
- 3주차의 연관관계/의존관계 실선·점선과 이어진다는 화살표를 옆에 붙여줘

막힐 때

4주차에서 "___" 가 이해가 안 돼.
이 교재의 판별 축 6개(상태 유무 / 선언·정의 / 괄호 / 정적·동적 /
Safe·Unsafe / 식별·비식별)만 써서 다시 설명해줘.
교재에 없는 새 비유는 만들지 마.

미국식 분류로 다시 정리하기

이 교재에 나온 비유(공장, 리모컨, 붕어빵 틀, 집짓기, 자판기)를 전부 걷어내고,
"이것은 무엇의 한 종류인가 / 형제 개념과 무엇으로 갈리는가" 형식으로만
선언·정의·정제·파인튜닝, GET·POST, Notation·Annotation,
DOM·JSON, 식별관계·비식별관계를 다시 정의해줘.

3주차와 이어 보기

3주차 교재와 4주차 교재를 같이 읽고, 3주차에서 "앞으로 다시 만납니다"로
예고된 개념이 4주차 어디에서 어떤 이름으로 회수되었는지 표로 정리해줘.
특히 연관관계/의존관계(실선·점선)가 식별관계/비식별관계로 이어지는 부분을
자세히 설명해줘.

다음 장 연결 확인

이 4주차 교재에서 "앞으로 다시 만납니다"라고 표시된 부분을 모두 찾아서,
이번 장의 어떤 개념이 나중에 어떤 이름으로 다시 나올지 표로 정리해줘.