무엇이 무엇에 속하는가

개강 주입니다. 겉으로 보면 도구를 깔고 계정을 만든 주입니다. Cursor를 깔고, Git을 깔고, 아나콘다를 깔고, 깃허브에 가입하고, 도메인을 하나 샀습니다.

하지만 이 주에 실제로 배운 것은 설치법이 아닙니다. "이것은 무엇에 속하는가" 를 묻는 습관입니다.

앞으로 4개월 동안 수백 개의 새 용어가 쏟아집니다. 그때마다 비유를 찾으면 금방 무너집니다. 비유는 서로 겹치고, 겹치면 경계가 사라지기 때문입니다. 대신 축(軸) 을 잡으면 아직 배우지 않은 것까지 추론됩니다. 이 장은 그 축 다섯 개를 세우는 장입니다.

---

이 장을 다 읽으면

1. AI·머신러닝·딥러닝·생성형 AI가 대등한 네 개가 아니라 포함 관계임을 그림으로 그릴 수 있다.
2. AI 에이전트가 왜 그 포함 관계에 들어가지 않는지, 어느 축에 속하는지 말할 수 있다.
3. 이진 분류가 "가장 기초"인 이유를 쉬워서가 아니라 분해되지 않아서라고 설명할 수 있다.
4. Git과 GitHub 중 인터넷이 없어도 되는 쪽을 고르고, 그 이유를 위치의 축으로 설명할 수 있다.
5. 가상환경을 만드는 이유를 의존성 충돌로 설명하고, venv·컨테이너·VM의 격리 강도를 순서대로 놓을 수 있다.
6. 라이브러리와 프레임워크를 "누가 누구를 부르는가" 한 문장으로 구분할 수 있다.
7. 추상 ↔ 구상 축이 무엇인지 알고, 프로그래밍 언어가 왜 그 축의 가운데에 있는지 설명할 수 있다.
8. 아나콘다 설치 → 가상환경 생성 → 판다스 확인 → 깃허브 업로드까지를 막히지 않고 재현할 수 있다.
9. conda activate 가 안 먹을 때, conda: command not found 가 뜰 때 어디부터 봐야 하는지 안다.

---

0. 이 장의 판별 축

새 용어를 만나면 비유를 찾기 전에 아래 축 중 어디에 꽂히는지부터 정하세요. 비유부터 잡으면 경계가 흐려집니다. 축을 먼저 잡으면 아직 안 배운 것도 추론됩니다.

이 다섯 축은 이 교재 전체의 출발점입니다. 여기가 첫 등장이므로 이어받을 앞 장이 없습니다. 대신 뒤로 이어지는 곳을 지금 미리 적어 둡니다.

앞으로 다시 만납니다

축	어디서 다시 나오는가
축 1 (포함 관계)	상속(IS-A) 관계, DB 분류(RDBMS ↔ NoSQL), 소·중·대전략의 층위 — 3주차
축 2 (로컬 ↔ 원격)	SAVE/LOAD ↔ 업로드/다운로드 (3주차), Docker ↔ Docker Hub, Model ↔ Hugging Face (11주차)
축 3 (전역 ↔ 격리)	지역 변수 ↔ 전역 변수, 인스턴스 변수(Heap) ↔ 클래스 변수(Method Area) — 3주차
축 4 (0 ↔ 1)	모델 검증 지표(정확도·정밀도·재현율), 결정트리의 분기 — 3주차
축 5 (추상 ↔ 구상)	패턴(추상) ↔ 아키텍처(구상), 포트(추상) ↔ 어댑터(구상) — 3주차 · 6주차

이 중 축 5가 교재 전체에서 가장 많이 쓰이는 축입니다. 이번 주에는 다이어그램 하나로만 등장하지만, 6주차 헥사고날 아키텍처에 가면 이 축이 설계 원칙 그 자체가 됩니다.

---

1. AI라는 말이 가리키는 것들

1.1 다섯 단어는 대등하지 않습니다

AI, 머신러닝, 딥러닝, 생성형 AI, AI 에이전트. 이 다섯 단어는 뉴스에서 나란히 나옵니다. 그래서 다섯 개의 서로 다른 기술처럼 보입니다.

아닙니다. 넷은 겹겹이 포개져 있고, 하나는 아예 다른 축에 있습니다.

인공지능 (Artificial Intelligence)
└── 머신러닝 (Machine Learning)
    └── 딥러닝 (Deep Learning)
        └── 생성형 AI (Generative AI)

동심원으로 그리면 이렇게 됩니다.

┌─────────────────────────────────────────┐
│  인공지능 (AI)                            │
│  ┌───────────────────────────────────┐  │
│  │  머신러닝 (ML)                      │  │
│  │  ┌─────────────────────────────┐  │  │
│  │  │  딥러닝 (DL)                  │  │  │
│  │  │  ┌───────────────────────┐  │  │  │
│  │  │  │  생성형 AI (GenAI)     │  │  │  │
│  │  │  └───────────────────────┘  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

⚠️ 가장 흔한 오해: "머신러닝과 딥러닝은 다른 두 기술이다." 딥러닝은 머신러닝의 부분집합입니다. 모든 딥러닝은 머신러닝이지만, 모든 머신러닝이 딥러닝은 아닙니다.

1.2 각 층의 종차

정의를 유(類, 상위 범주) + 종차(種差, 그 안에서의 차이) 형식으로 씁니다. 이 형식은 이 교재 전체에서 반복해서 쓰는 정의법입니다.

• 인공지능(AI) — [사람의 지적 작업을 기계가 수행하게 하는 것 전부]. 최상위 범주이므로 종차가 없습니다. 규칙을 사람이 손으로 다 적어 넣은 옛날 방식(전문가 시스템)도 여기 포함됩니다.
• 머신러닝(Machine Learning) — [AI]인데, [규칙을 사람이 적지 않고 데이터에서 스스로 찾아낸다]는 점에서 다른 AI와 구별된다.
• 딥러닝(Deep Learning) — [머신러닝]인데, [인공신경망을 여러 층 쌓아 특징(feature)까지 스스로 찾아낸다]는 점에서 다른 머신러닝과 구별된다.
• 생성형 AI(Generative AI) — [딥러닝]인데, [출력이 라벨이나 숫자가 아니라 새로 만들어낸 콘텐츠다]는 점에서 다른 딥러닝과 구별된다.

표로 다시 보면 각 층에서 무엇이 새로 추가되었는지가 보입니다.

반례로 확인하기 — "이건 아니다"를 하나씩 짚어야 경계가 굳습니다.

1.3 AI 에이전트는 이 계열이 아닙니다

여기가 이 절의 핵심입니다.

위의 넷은 기술의 종류입니다. AI 에이전트는 시스템의 형태입니다. 축이 다릅니다. 그래서 "딥러닝 다음 단계가 AI 에이전트"라는 말은 성립하지 않습니다. "자동차 다음 단계가 물류회사"라는 말이 이상한 것과 같습니다.

챗봇과 에이전트의 경계도 같은 자리에 있습니다.

에이전트가 일하는 순서는 정해져 있습니다. 지시 받기 → 필요한 정보 찾기 → 도구 사용 → 중간 확인·승인 → 결과 전달. 이 반복을 에이전트 루프(Agent Loop) 라고 부릅니다. 생각 → 계획 → 실행 → 확인 → 수정의 순환입니다.

🔒 삭제·결제·배포·메일 발송처럼 되돌릴 수 없는 작업은 루프 중간에 사람 확인을 넣는 것이 안전합니다. 이 원칙은 나중에 자동화 워크플로를 만들 때 그대로 다시 적용됩니다.

앞으로 다시 만납니다 딥러닝과 AI 에이전트의 이 구분은 15주차 에서 「무엇이 두뇌이고 무엇이 몸인가」로 정면으로 다시 다룹니다. 그리고 이 장 3.1의 Soul / Body 축과도 곧바로 연결됩니다. 딥러닝은 Soul(지능) 쪽, 에이전트는 Body(행동) 쪽입니다.

1.4 약한 AI와 강한 AI — 또 다른 축

이건 세 번째 축입니다. 포함 관계도 아니고 시스템 형태도 아닌, 범용성의 축입니다.

⚠️ ChatGPT가 아무 주제나 답하니까 강한 AI 아닌가요? 아닙니다. "다양한 주제의 텍스트를 생성하는 한 가지 일" 을 하고 있습니다. 스스로 목표를 세우고, 새 능력을 획득하고, 자신의 존재를 유지하려 하지 않습니다. "할 수 있는 일이 많다"와 "범용이다"는 다른 말입니다.

1.5 왜 포함 관계부터 잡는가

여기서 이 교재의 사고방식을 한 번 명시해 둡니다.

같은 세 장의 카드(원숭이 · 바나나 · 사자)를 주고 둘을 묶으라고 하면 문화권에 따라 답이 갈립니다.

소프트웨어 개념은 거의 전부 서구에서 나왔고, 유(類)와 종차(種差) 라는 고전 정의법을 코드로 옮긴 것입니다. 그래서 이 교재는 설명 순서를 이렇게 씁니다.

1. 소속 범주부터 — "이것은 ~의 한 종류다"
2. 형제 개념과의 경계선 — 0/1로 갈리는 축
3. 반례 — "이건 아니다"
4. 그 다음에야 비유 — 기억 보조용으로만

방금 1.1~1.4에서 한 것이 정확히 이 순서였습니다. AI 계열을 포함 관계로 먼저 세우고(1단계), 에이전트를 다른 축으로 떼어내고(2단계), 반례 표를 붙이고(3단계), "두뇌와 몸"이라는 비유를 맨 마지막에 얹었습니다.

1.6 지금 쓰는 도구들은 어디에 속하는가

개강 첫 주에 이미 여러 AI 도구 이름이 나왔습니다. 이것들도 범주부터 정리해 두면 앞으로 새 도구가 나올 때마다 자리를 찾아 넣을 수 있습니다.

• Cursor — 이번 주에 설치한 것. 에디터 안에 AI가 들어와 있는 형태입니다.
• Claude Code — 개강 첫날 워크숍 영상에 나온 것. 코드베이스 전체를 읽고 여러 파일을 한꺼번에 다루는 데 강합니다.
• Antigravity — 여러 에이전트가 계획·실행·검증을 나눠 맡는 형태.

모델을 어디서 돌리는가도 하나의 축입니다. 이건 축 2(로컬 ↔ 원격)의 AI판입니다.

오픈소스 모델은 또 다른 축입니다. "가중치가 공개되어 있는가"를 묻습니다. 공개된 모델을 모아둔 곳이 Hugging Face 이고, 여기서 받아 내 컴퓨터에서 돌리는 도구가 Ollama 입니다.

앞으로 다시 만납니다 모델을 Hugging Face에서 내려받아 내 컴퓨터에서 돌리는 일은 11주차 에서 본격적으로 합니다. 그때 Model ↔ Hugging Face 관계가 이번 주의 Git ↔ GitHub 와 완전히 같은 모양임을 보게 됩니다. 축 2는 이름만 바꿔 계속 돌아옵니다.

1.7 모델을 고를 때 실제로 보는 것 — 토큰과 컨텍스트

브라우저 북마크에 Claude·Gemini·ChatGPT를 나란히 놓았다면, 곧 "어느 걸 쓰지"라는 질문이 옵니다. 그 판단에 필요한 최소 어휘가 둘입니다.

토큰(Token) — AI가 글을 읽고 쓰기 위해 잘게 나눈 글자 조각. 컨텍스트 윈도(Context Window) — AI가 한 번에 펼쳐놓고 볼 수 있는 책상의 크기.

• 입력 토큰 = 내 질문 + 업로드한 문서 + 이전 대화 기록 전부 + 시스템 지시문
• 출력 토큰 = AI가 만들어내는 모든 텍스트
• 비용 = (입력 토큰 × 단가) + (출력 토큰 × 단가)

한국어 기준 감각:

"AI가 앞 내용을 잊어버린다"의 정확한 원인은 기억력이 아니라 책상 크기입니다. 대화가 길어져 컨텍스트를 넘으면 오래된 내용이 앞에서부터 밀려납니다.

밀려나지 않게 하는 방법은 셋입니다.

같은 질문도 어떻게 쓰느냐에 따라 토큰이 5배 차이 납니다.

• 길게: "제가 오늘 서울에 있는 회사에 다녀왔고, 회의도 길었고…" → 152 토큰
• 짧게: "오늘 서울 회사 회의 내용을 요약해줘." → 28 토큰

💡 벤치마크 점수 읽는 법 — ① 어떤 시험인가 → ② 내 작업과 비슷한가 → ③ 직접 써봤는가. 1등 모델이 내 작업의 1등은 아닙니다. 벤치마크는 "AI들의 시험지"일 뿐입니다.

---

2. 이진 분류 — 왜 여기가 바닥인가

2.1 정의

이진 분류(Binary Classification) — [지도학습의 분류 문제]인데, [답의 가짓수가 정확히 2개]라는 점에서 다중 분류·회귀와 구별된다.

• 상위 범주: 분류(Classification) 문제
• 종차: 답이 두 개의 배타적 범주 중 하나
• 형제 개념: 다중 분류(Multi-class, 3개 이상), 회귀(Regression, 연속된 숫자를 맞힘)

두 그룹의 이름은 문제마다 다르지만 형태는 같습니다. 예/아니오 · 참/거짓 · 성공/실패 · 생존/사망 · 스팸/정상 · 0/1.

2.2 형제 개념과 나란히 놓기

⚠️ 분류와 회귀를 가르는 것은 "어려움"이 아니라 "답의 종류"입니다. 답이 끊어져 있으면(범주) 분류, 이어져 있으면(숫자) 회귀입니다.

2.3 왜 "가장 기초"인가 — 쉬워서가 아닙니다

이 문장에 이유가 있습니다. 감각적인 표현이 아닙니다.

다중 분류는 이진 분류 여러 개로 분해됩니다. "개인가 아닌가" + "고양이인가 아닌가" + "새인가 아닌가" — 이 세 개의 이진 분류를 붙이면 3-클래스 분류가 됩니다. 이 기법에는 이름도 있습니다. One-vs-Rest (OvR, 하나 대 나머지).

다중 분류 (개 / 고양이 / 새)
   │
   ├── 이진 분류 ①: 개인가?      → 0 / 1
   ├── 이진 분류 ②: 고양이인가?   → 0 / 1
   └── 이진 분류 ③: 새인가?      → 0 / 1

반대 방향은 성립하지 않습니다. 이진 분류를 더 작은 무엇으로 쪼갤 수는 없습니다. 답이 2개인데 이걸 1개로 줄이면 그건 이미 판단이 아닙니다.

결론: 이진 분류가 기초인 이유는 분해되지 않는 최소 단위이기 때문입니다. 난이도가 낮아서가 아닙니다. 실제로 어려운 이진 분류(암 진단, 사기 탐지)는 얼마든지 있습니다.

2.4 0과 1 — 같은 뿌리

컴퓨터가 근본적으로 0과 1로 동작한다는 사실과, 판단의 최소 단위가 0/1이라는 사실은 우연히 겹친 게 아닙니다.

서구 논리학은 오랫동안 모든 명제를 참/거짓으로 환원하려 해 왔습니다. 그 전통이 불 대수(Boolean Algebra)가 되었고, 불 대수가 전기 회로가 되었고, 그 회로가 컴퓨터가 되었습니다.

명제 논리 (참/거짓)  →  불 대수 (1/0)  →  논리 게이트 (전압 있음/없음)  →  컴퓨터

축 4는 그래서 기술의 축이 아니라 사고방식의 축입니다. "이 판단을 예/아니오로 쪼갤 수 있는가"를 묻는 습관이 곧 프로그래밍의 습관입니다.

if 문 하나가 정확히 이진 분류 하나입니다. 조건이 참이면 이쪽, 거짓이면 저쪽.

앞으로 다시 만납니다 3주차의 결정트리(Decision Tree)는 이 if 를 나무 모양으로 반복해서 쌓은 모델입니다. "이진 분류를 계속 이어 붙이면 복잡한 판단이 된다"는 이 절의 이야기가 알고리즘으로 구현된 것입니다.

2.5 왜 첫 데이터가 타이타닉인가

이 주에 캐글에서 타이타닉 데이터셋을 내려받았습니다. 두 개의 링크가 있었고 용도가 다릅니다.

이 데이터가 입문 과제의 표준이 된 이유는 축 4에 정확히 맞기 때문입니다.

맞혀야 하는 답이 딱 0 아니면 1입니다. 교과서적인 이진 분류입니다. 게다가 나이·성별·객실 등급 같은 사람이 직관적으로 이해할 수 있는 특징이 들어 있어, 모델이 왜 그렇게 판단했는지 검증하기 좋습니다.

주요 컬럼은 이렇습니다.

앞으로 다시 만납니다 이 데이터셋은 이 교재에서 계속 따라다닙니다. 3주차 에서 결정트리로 실제 예측을 하고 정확도·정밀도·재현율을 재며, 그 뒤로는 이 타이타닉 앱이 FastAPI 웹 서비스로, 다시 클린 아키텍처 구조로 계속 자랍니다. 지금 내려받은 CSV 한 장이 4개월치 실습의 출발점입니다.

---

3. 사람과 기계 사이 — 추상과 구상

3.1 Human / Machine, Soul / Body

이 주에 나온 다이어그램 하나가 이 교재에서 가장 오래 쓰이는 도구가 됩니다.

            Soul (추상 · 의미 · 무엇을)
                       ▲
                       │
                       │
   Human ◄─────────────┼─────────────► Machine
   (자연어)             │              (기계어)
                       │
                       │
                       ▼
            Body (구상 · 물질 · 어떻게)

축이 둘입니다.

프로그래밍 언어는 정확히 가운데에 있습니다. 사람이 읽을 수 있으면서, 동시에 기계도 실행할 수 있습니다. 사람 쪽으로도 기계 쪽으로도 완전히 넘어가지 않은 중간 지대 — 그게 코드입니다.

그리고 AI도 이 교차점에 있습니다. 자연어로 말하면 기계가 실행하는 것. 지금 Cursor로 하고 있는 일이 정확히 그것입니다. 이 다이어그램의 요지는 "AI가 등장하면서 이 교차점이 넓어졌다"는 것입니다.

3.2 "고급 언어"의 고급은 어렵다는 뜻이 아닙니다

한국어 번역어가 원 개념을 왜곡한 대표적인 자리입니다.

level 은 난이도가 아니라 추상화의 높이입니다. 축 5의 세로축 좌표입니다. 실제로는 저급(low-level) 쪽이 훨씬 쓰기 어렵습니다. 사람의 사고와 멀기 때문입니다.

언어를 이 축 위에 늘어놓으면 이렇습니다.

Soul (추상 ↑)

  자연어 (한국어·영어)          ← 사람만 읽음
  ─────────────────────────
  파이썬 · 자바스크립트          ← 고급 언어. 사람이 읽고, 번역되면 기계도 실행
  C
  어셈블리어                    ← 저급 언어. 기계 명령과 거의 1:1
  ─────────────────────────
  기계어 (0과 1)                ← 기계만 읽음

Body (구상 ↓)

3.3 코드와 실행

코드(Code) — 컴퓨터에게 주는 레시피입니다. 명령어가 모여 코드가 되고, 코드가 모여 프로그램이 됩니다. 실행(Run) 은 레시피를 읽는 것이 아니라 실제로 요리를 시작하는 것입니다.

이 주에 설치한 언어와 도구들이 각각 어느 일을 맡는지도 정리해 둡니다.

⚠️ HTML과 CSS는 엄밀히는 프로그래밍 언어가 아닙니다. HTML은 마크업 언어(구조를 표시), CSS는 스타일 시트 언어(모양을 지정)입니다. 판단·반복·분기가 없기 때문입니다. 축 5로 보면 둘 다 구상(Body) 쪽에 치우쳐 있습니다.

파일 확장자도 같은 감각으로 읽습니다.

⚠️ 확장자는 힌트일 뿐입니다. 이름만 바꾼다고 파일의 내용 형식이 바뀌지는 않습니다.

3.4 이 축이 앞으로 어디서 다시 나오는가

축 5는 이 교재에서 가장 자주 재등장하는 축입니다. 지금 미리 지도를 그려 둡니다.

앞으로 다시 만납니다 6주차에서 "포트는 추상, 어댑터는 구상"이라는 문장을 만나면, 그건 새 개념이 아니라 지금 이 다이어그램의 세로축을 소프트웨어 설계에 그대로 적용한 것입니다. Soul이 "무엇을", Body가 "어떻게"입니다.

---

4. 내 컴퓨터와 남의 컴퓨터

4.1 Git과 GitHub — 이름이 비슷해서 생기는 오해

이 둘은 이름이 비슷해서 같은 것의 두 이름처럼 느껴집니다. 완전히 다른 범주입니다.

핵심: Git이 먼저 있고, GitHub는 나중에 그 위에 지어진 것입니다. 반대가 아닙니다. Git 없이 GitHub는 성립하지 않지만, GitHub 없이 Git은 완벽하게 동작합니다.

• Git — [프로그램]인데, [파일의 변경 이력을 스냅샷으로 기록한다]는 점에서 다른 프로그램과 구별된다.
• GitHub — [웹 서비스]인데, [Git 저장소를 인터넷에 호스팅한다]는 점에서 다른 웹 서비스와 구별된다.

비유 하나만 붙이자면: Git은 내 책상 위의 작업 일지, GitHub는 그 일지를 올려두는 온라인 사무실입니다. 일지는 인터넷이 끊겨도 계속 씁니다. 사무실에 올리는 것만 인터넷이 필요합니다.

4.2 첫 push 6줄의 의미

깃허브에 코드를 처음 올릴 때 화면이 알려주는 명령이 6줄입니다. 이 6줄에는 한 번만 하는 것과 매번 하는 것이 섞여 있습니다. 그걸 구분하는 게 핵심입니다.

git init
git add .
git commit -m "첫번째 커밋"
git branch -M main
git remote add origin https://github.com/[내아이디]/example-cloud.git
git push -u origin main

⭐ 여섯 줄 중 다섯 줄이 로컬에서 끝납니다. 인터넷이 필요한 건 마지막 한 줄뿐입니다. 이게 축 2를 몸으로 이해하는 첫 순간입니다.

세 단계를 다시 정리하면 — 이 흐름이 앞으로 매일 반복됩니다.

작업 폴더  ──git add──▶  스테이징  ──git commit──▶  로컬 저장소  ──git push──▶  원격(GitHub)
 (수정 중)                (올릴 목록)                (확정된 기록)              (남의 컴퓨터)

⚠️ git add 는 인터넷에 올리는 명령이 아닙니다. commit에 포함할 파일을 고르는 단계입니다. ⚠️ commit 만 하면 GitHub에는 아무것도 없습니다. push 를 해야 올라갑니다.

4.3 예시의 README.md 를 . 으로 바꾸는 이유

깃허브가 보여주는 예시 코드에는 git add README.md 라고 적혀 있습니다. 그건 "README 파일 하나만 올리기" 예시입니다.

우리는 만들어 둔 폴더 안 전부를 올려야 하므로 . 으로 바꿉니다.

. 은 유닉스 계열에서 "현재 디렉터리"를 뜻하는 표준 표기입니다. .. 은 상위 디렉터리입니다.

4.4 커밋이 거부될 때 — 이름과 이메일

첫 커밋에서 가장 흔하게 막히는 지점입니다.

git config --global user.name "사용자이름"
git config --global user.email "이메일주소"

왜 이게 필요한가: Git은 모든 커밋에 누가 언제 무엇을 바꿨는지를 함께 기록합니다. 그 "누가"에 해당하는 값이 비어 있으면 커밋 자체를 거부합니다. 익명 기록을 남기지 않겠다는 설계입니다.

⭐ --global 이라는 단어를 눈여겨보세요. 이건 축 3(전역 ↔ 격리) 입니다.

회사 계정과 개인 계정을 나눠 쓸 때는 프로젝트별로 옵션 없이 설정합니다. "전역이냐 이 프로젝트만이냐"는 질문이 Git 설정에도, 파이썬 환경에도, 나중엔 변수에도 똑같이 나옵니다.

4.5 Git 어휘 최소 세트

지금 다 외울 필요는 없지만, 단어가 나올 때 자리를 알 수 있을 정도로 정리해 둡니다.

💡 origin 은 예약어가 아닙니다. 그냥 관습적으로 첫 번째 원격에 붙이는 별명입니다. 다른 이름을 써도 동작하지만, 모두가 origin 을 쓰기 때문에 따르는 것이 좋습니다.

앞으로 다시 만납니다 3주차 에서 git remote -v 로 원격 주소를 확인하고, 여러 저장소를 하나로 합치는 작업을 합니다. 또한 Copy와 Clone의 차이(파일만 복사 ↔ 이력까지 통째로 복제)도 거기서 다룹니다. 그때 "왜 다운로드가 아니라 clone인가"를 이해하려면 지금의 commit = 기록 감각이 필요합니다.

4.6 왜 개강 이틀 만에 도메인을 사는가

개강 둘째 날에 도메인을 하나 구입했습니다. 배포는 아직 한참 뒤인데도 그렇습니다.

이건 "나중에 필요하니 미리 사두자"가 아닙니다. 축 2(로컬 ↔ 원격)를 몸으로 겪게 하려는 것입니다.

내 컴퓨터에서 만든 것은 나만 볼 수 있습니다. 남이 보게 하려면 주소가 있어야 합니다. 도메인은 그 주소입니다.

개강 이틀 만에 내 이름의 주소를 하나 갖고 나면, 그 뒤로 배우는 모든 것을 "이건 내 컴퓨터 안의 일인가, 밖으로 나가는 일인가" 로 구분하며 듣게 됩니다. 그 구분이 되기 시작하면 절반은 이해된 것입니다.

앞으로 다시 만납니다 도메인 → IP 연결, 네임서버 변경, A 레코드 / CNAME 레코드는 배포 주차에서 다시 나옵니다. 3주차 에서는 백엔드용 서브도메인 이름을 정하는 이야기가 나오는데, 그때 이 도메인을 씁니다.

---

5. 컴퓨터 전체와 이 프로젝트만 — 격리

5.1 가상환경의 정의

가상환경(Virtual Environment) — [격리(isolation) 기법]인데, [격리하는 대상이 파이썬 패키지]라는 점에서 컨테이너·가상 머신과 구별된다.

프로젝트마다 독립된 라이브러리 집합을 갖게 하는 장치입니다.

• 상위 범주: 격리 기법
• 종차: 격리 대상이 파이썬 패키지(와 파이썬 버전)
• 형제 개념: Docker 컨테이너(운영체제 라이브러리까지 격리), 가상 머신(OS 통째로 격리)

5.2 격리에는 강도가 있습니다

세 가지를 나란히 놓으면 무엇까지 격리하는가가 다릅니다. 이게 종차입니다.

격리의 강도 (약함 → 강함)

가상환경 (venv/conda)   →   컨테이너 (Docker)   →   가상 머신 (VM)
  파이썬 패키지만              앱 + OS 라이브러리         OS 통째로

⚠️ "가상환경은 Docker랑 같은 거 아닌가요?" 아닙니다. 격리 수준이 다릅니다. 가상환경은 파이썬 패키지만 나눕니다. 그래서 OS 수준 라이브러리가 필요한 것(예: 특정 이미지 처리 도구)은 가상환경으로 해결되지 않습니다. 그때 Docker로 올라갑니다.

앞으로 다시 만납니다 Docker는 11주차에서 본격적으로 다룹니다. 그때 "Docker 이미지를 Docker Hub에 올린다"는 문장을 만나면, 이번 주의 Git → GitHub 와 같은 축 2임을 알아보실 수 있어야 합니다.

5.3 안 만들면 무슨 일이 생기나 — 의존성 지옥

구체적인 상황으로 봐야 합니다.

• 프로젝트 A는 pandas 1.5 가 필요합니다.
• 프로젝트 B는 pandas 2.1 이 필요합니다.
• 컴퓨터 전체에 pandas를 하나만 깔면? 둘 중 하나는 반드시 깨집니다.

이 상황을 의존성 지옥(Dependency Hell) 이라고 부릅니다. 프로젝트가 셋, 넷으로 늘어나면 조합이 폭발합니다.

⭐ 마지막 줄이 실무에서 가장 큰 이점입니다. 가상환경은 언제든 지우고 다시 만들 수 있습니다. 전역 환경은 그렇지 않습니다.

패키지와 의존성이라는 단어도 여기서 정리해 둡니다.

패키지(Package) — 가져다 쓰는 코드 부품. 의존성(Dependency) — 내 프로젝트가 꼭 기대고 있는 부품 목록.

⚠️ AI가 코드를 아무리 잘 만들어도, 필요한 부품이 내 컴퓨터에 없으면 실행되지 않습니다. "AI가 준 코드가 안 돌아간다"의 상당수가 이 문제입니다. 코드가 틀린 게 아니라 환경이 비어 있는 것입니다.

5.4 아나콘다는 무엇인가

아나콘다(Anaconda) — [파이썬 배포판]인데, [데이터 분석용 패키지와 conda 라는 환경·패키지 관리자를 함께 묶어 배포한다]는 점에서 순정 파이썬과 구별된다.

파이썬 공식 사이트에서 받는 파이썬은 인터프리터만 들어 있습니다. 아나콘다는 거기에 pandas·numpy·matplotlib 같은 데이터 도구와 conda 를 얹어 놓은 꾸러미입니다.

⭐ conda의 결정적 차이: 환경마다 파이썬 버전 자체를 다르게 지정할 수 있습니다. conda create -n venv python=3.13 이 가능한 이유입니다. venv 모듈만으로는 이게 안 됩니다.

5.5 명령어 네 줄의 의미

가상환경을 만드는 과정은 네 단계입니다. 각 줄이 무엇을 하는지 알아야 막혔을 때 어디를 볼지 압니다.

conda create -n venv python=3.13 -y
conda init
# ── Cursor를 완전히 종료했다가 다시 실행 ──
conda activate venv

⚠️ 3단계를 건너뛰면 4단계가 실패합니다. 이건 conda의 버그가 아닙니다.

왜 재시작이 필수인가 — 셸의 동작 원리 때문입니다.

셸이 시작될 때  ──▶  설정 파일을 한 번 읽음  ──▶  그 상태로 계속 동작
                          ▲
                          │
              conda init 이 이 파일을 고침
              (하지만 이미 떠 있는 셸은 다시 읽지 않음)

이미 열려 있는 터미널은 설정 파일을 시작할 때 한 번만 읽었습니다. 그래서 파일이 바뀐 것을 모릅니다. 껐다 켜야 다시 읽습니다.

⭐ 이 원리는 conda만의 이야기가 아닙니다. 환경변수를 바꾼 뒤, .env 를 고친 뒤, 설정 파일을 수정한 뒤 — "바꿨는데 왜 안 바뀌지?" 의 절반은 "다시 읽히지 않았다"가 답입니다.

활성화가 되었는지 확인하는 법: 터미널 프롬프트 앞에 환경 이름이 붙습니다.

(base) C:\project>          ← 아직 전역 환경
(venv) C:\project>          ← 격리 환경 안으로 들어옴

5.6 축 3의 다른 이름들

전역 ↔ 격리 축은 이번 주에만 세 번 나옵니다. 다 같은 축입니다.

앞으로 다시 만납니다 3주차 에서 이 축이 메모리 안으로 들어옵니다. 지역 변수(Stack, 메서드가 끝나면 사라짐) ↔ 전역·클래스 변수(Method Area, 모두가 공유). "이 값은 어디까지 보이는가"를 묻는 것은, 지금 "이 패키지는 어디까지 적용되는가"를 묻는 것과 같은 질문입니다.

---

6. 남이 만든 코드를 쓴다는 것

6.1 라이브러리의 정의

라이브러리(Library) — [코드 묶음]인데, [내가 호출할 때만 동작한다]는 점에서 프레임워크와 구별된다.

• 상위 범주: 코드 (실행되는 것)
• 종차: 내가 짠 게 아니고, 내가 부를 때 응답함
• 형제 개념: 프레임워크 — 내가 부르는 게 아니라 그쪽이 나를 부름

6.2 라이브러리 vs 프레임워크 — 누가 누구를 부르는가

이 구분은 비유로 외우면 반드시 헷갈립니다. 화살표 방향 하나로 외우세요.

라이브러리:   내 코드  ──호출──▶  라이브러리
프레임워크:   프레임워크  ──호출──▶  내 코드

⚠️ React는 라이브러리, Next.js는 프레임워크입니다. React 자체는 UI를 그리는 라이브러리이고, Next.js는 React를 기반으로 라우팅·빌드·서버 렌더링까지 정해 놓은 프레임워크입니다.

앞으로 다시 만납니다 "프레임워크가 내 코드를 부른다"는 이 현상에는 이름이 있습니다. 제어의 역전(IoC, Inversion of Control) 입니다. 3주차 에서 이 이름으로 다시 나옵니다. 그리고 3주차는 한 걸음 더 나아가, IoC가 전략 패턴 · DIP · DI · 포트&어댑터와 전부 같은 이야기임을 보여줍니다. 지금은 누가 누구를 부르는가만 확실히 잡아두면 됩니다.

6.3 import 한 줄을 분해하기

import pandas as pd

⭐ 가운데 줄이 이번 주의 두 축을 한 번에 씁니다. pandas 는 어디에 설치돼 있어야 하나요? 컴퓨터 전체(전역)가 아니라 지금 활성화된 가상환경 안입니다(축 3). 그리고 그건 내 컴퓨터 안에 있어야 합니다(축 2). 인터넷에서 그때그때 가져오는 게 아닙니다.

⚠️ ModuleNotFoundError: No module named 'pandas' 는 대부분 문법 오류가 아니라 환경 문제입니다. "가상환경이 활성화되어 있나" → "그 환경에 설치했나" 순으로 확인합니다.

판다스와 데이터프레임도 같이 정리해 둡니다.

6.4 "바퀴를 재발명하지 마라"의 진짜 이유

이 주의 읽을거리 중 하나가 「바퀴를 재발명하지 않기」 였습니다. 흔히 "시간 절약"으로 요약되지만, 진짜 이유는 셋이고 시간은 그중 가장 약한 이유입니다.

1. 검증 횟수가 다릅니다. pandas는 전 세계에서 매일 수백만 번 실행됩니다. 내가 짠 CSV 파서는 나 혼자 씁니다. 버그가 발견될 확률이 애초에 다릅니다. 이건 실력의 문제가 아니라 노출량의 문제입니다.
2. 공용 언어가 됩니다. 남이 내 코드를 볼 때 pd.read_csv(path) 는 설명이 필요 없습니다. 내가 만든 MyCsvLoader.load() 는 설명이 필요합니다. 협업 비용의 차이입니다.
3. 내 시간을 어디에 쓸 것인가. CSV 파싱은 우리 서비스의 가치가 아닙니다. 아무도 그것 때문에 우리를 쓰지 않습니다.

🔗 https://blex.me/@baealex/바퀴를-재발명하지-않기

6.5 그럼 무엇을 직접 만드나

여기서 반대 질문이 나옵니다. "전부 가져다 쓰면 우리 것은 뭐가 남나?"

이 질문은 5월 1일의 뉴스와 정면으로 붙습니다. 국가대표 AI 사업에서 한 기업이 탈락했는데, 핵심 장치에 외부(중국산) 기술을 그대로 쓴 것이 드러났기 때문이라는 보도였습니다.

같은 주에 "라이브러리를 가져다 써라"를 배웠는데, 같은 주에 "가져다 쓴 게 문제가 됐다"는 뉴스를 본 셈입니다. 모순처럼 보이지만 아닙니다. 경계가 있습니다.

⭐ 판별법 한 줄: "이걸 다른 것으로 바꿔도 우리 서비스가 여전히 우리 서비스인가?" 그렇다면 가져다 쓰는 영역입니다. 아니라면 직접 만들어야 하는 영역입니다.

앞으로 다시 만납니다 이 구분은 6주차 클린 아키텍처의 「안쪽 원 / 바깥쪽 원」 과 정확히 같은 구분입니다. 바깥쪽 원(프레임워크·DB·외부 API)은 갈아끼우는 것, 안쪽 원(도메인 규칙)은 우리가 지키는 것. 4개월 뒤에 배울 설계 원칙이, 개강 첫 주의 뉴스 한 줄에 이미 들어 있었습니다.

---