개발 도구의 역할과 첫 실습

7. 첫날 설치한 네 도구 — 각각 다른 범주

7.1 무작위로 고른 네 개가 아닙니다

개강 첫날 설치 목록은 Cursor · 옵시디언 · Git · GitHub였습니다. 역할이 하나도 겹치지 않는 네 개입니다. 각각 다른 범주에 속합니다.

설치 링크:

7.2 핵심 경계 — 실행되는가, 읽히는가

Cursor와 옵시디언은 둘 다 글자를 편집합니다. 그래서 "같은 종류 아닌가" 싶습니다. 아닙니다. 다루는 대상이 다릅니다.

⭐ "실행되는가 / 읽히는가" 가 이 둘을 가르는 축입니다.

7.3 CLAUDE.md 가 왜 .md 인가

개강 첫날 워크숍 영상에서 CLAUDE.md 라는 파일 이야기가 나왔습니다. AI에게 프로젝트의 규칙을 알려주는 파일입니다. "이 프로젝트는 이런 규칙으로 작업해라" 를 적어둡니다.

왜 .py 가 아니라 .md 인가 — 방금 그은 경계가 그대로 답입니다. 그건 AI가 읽을 문서이지 실행할 코드가 아니기 때문입니다.

마크다운을 쓰는 이유는 셋입니다.

⭐ 세 번째가 결정적입니다. .docx 나 .pdf 로 규칙을 적으면 Git이 "파일이 바뀌었다"까지만 알려줍니다. .md 는 어느 문장이 어떻게 바뀌었는지 보여줍니다. 규칙 문서야말로 이력이 중요합니다.

앞으로 다시 만납니다 마크다운(Markdown)과 마크업(Markup)의 차이 — 누구를 위한 이름표인가 — 는 3주차 에서 제대로 다룹니다. 그리고 AI에게 규칙 파일을 주는 이 방식은 나중에 하네스(Harness) 엔지니어링이라는 이름으로 다시 나옵니다. 요지는 에이전트 = 모델 + 하네스. LLM을 날것으로 쓰지 말고, 규칙 문서(가이드)와 검증 장치(센서)로 감싸라는 것입니다.

7.4 에디터 · IDE · 터미널

같이 헷갈리는 세 단어를 정리해 둡니다.

Cursor 안에서 터미널을 열면, 에디터와 터미널이 같은 폴더를 보고 있게 됩니다. 이게 중요한 이유는 뒤에서 나옵니다 — 명령은 현재 폴더 기준으로 동작하기 때문입니다.

터미널 생존 명령어 8개만 먼저 익혀둡니다.

💡 Tab 키 = 자동완성 / --help = 도움말 / ⚠️ rm -r 은 되돌릴 수 없습니다.

---

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

이 절은 순서대로 따라 하면 재현되도록 썼습니다. 막히는 지점에는 ⚠️ 로 표시해 두었습니다.

8.1 Cursor 설치

1. 공식 홈페이지 접속 — 🔗 https://cursor.com/
2. Download 클릭 (윈도우는 .exe, 맥은 .dmg)
3. 받은 파일 실행
4. 설치 완료

설치 후 두 가지 설정

💡 아이콘 테마는 취향 문제로 보이지만, 파일 종류가 한눈에 구분되면 폴더 구조를 읽는 속도가 달라집니다. 앞으로 폴더가 수십 개로 늘어납니다.

8.2 크롬을 실습 환경으로 맞추기

브라우저를 그냥 쓰는 것과 작업 환경으로 세팅하는 것은 다릅니다.

1. 크롬 설치 — 🔗 https://www.google.com/chrome/
2. 북마크 바 표시: Ctrl + Shift + B
3. AI 서비스(Claude / Gemini / ChatGPT)를 각각 열고 주소창의 별표(☆) 를 눌러 북마크
4. 북마크할 때 이름을 지워서 아이콘만 남기기
5. 북마크 바 빈 곳에서 우클릭 → [앱 단축키 표시]
6. 드래그로 순서 변경

이름을 지우는 이유: 북마크 바의 가로 폭은 한정돼 있습니다. 이름을 지우면 아이콘만 남아 훨씬 많은 항목이 한 줄에 들어갑니다. 그리고 매일 쓰는 도구는 어차피 아이콘만으로 구분됩니다.

⭐ 세 개의 AI를 나란히 놓는 이유는 비교하며 쓰기 위해서입니다. 같은 질문을 셋에 던져보면 각 모델의 성격이 금방 드러납니다. 1.7절의 "직접 써봤는가"가 이것입니다.

8.3 Git 설치와 GitHub 가입

⚠️ 설치 직후 터미널에서 git 이 안 먹으면 열려 있던 터미널을 껐다 켭니다. 5.5절에서 본 것과 똑같은 원리입니다. 설치 프로그램이 PATH 를 고쳤지만, 이미 떠 있는 터미널은 모릅니다.

8.4 아나콘다 설치

가장 많이 막히는 단계입니다. 특히 경로와 환경변수입니다.

설치

1. 🔗 anaconda.com/download 접속 → 설치 파일 다운로드
2. Select Installation Type 에서 Just Me (recommended) 선택 → Next >
3. Choose Install Location 의 Destination Folder를 C:\ProgramData\Anaconda3 로 지정

⚠️ 가장 흔한 함정: 설치 경로가 랜덤으로 다르게 잡히는 경우가 아주 많습니다. 화면에 뜬 경로를 반드시 눈으로 확인하고, 다르면 그 경로를 기억해 두세요. 아래 환경변수를 그 경로 기준으로 넣어야 합니다. 이 한 가지가 대부분의 conda 에러의 원인입니다.

설치 확인 — 해당 폴더에 아래 폴더들이 생겼는지 봅니다.

condabin  conda-meta  DLLs  envs  etc  include
Lib  Library  libs  Menu  pkgs  Scripts

환경변수 설정 — 시스템 변수(S) 에 4개를 새로 만듭니다.

이어서 Path 를 선택 → 편집(I)... → 아래 4줄을 추가하고 확인.

%ANACONDA_HOME1%
%ANACONDA_HOME2%
%ANACONDA_HOME3%
%ANACONDA_HOME4%

💡 왜 변수를 4개 만들고 다시 Path에 넣는가 경로를 Path 에 직접 4줄 박아 넣어도 동작은 합니다. 하지만 나중에 아나콘다를 다른 곳으로 옮기면 4줄을 전부 고쳐야 합니다. 변수로 한 번 감싸두면 ANACONDA_HOME1 하나만 고치면 나머지가 따라옵니다. 이게 프로그래밍에서 말하는 한 곳에서만 정의하기의 첫 사례입니다.

PATH 가 하는 일 터미널에 conda 라고 치면, 컴퓨터는 PATH 에 적힌 폴더들을 위에서부터 차례로 뒤져서 conda 라는 실행 파일을 찾습니다. 어디에도 없으면 command not found 입니다. 즉 PATH 는 "명령어를 어느 폴더에서 찾을지 적어둔 목록" 입니다.

검증 — 터미널을 새로 열고 세 가지를 확인합니다.

conda --version
# → conda 24.1.2

conda env list
# → base    C:\ProgramData\Anaconda3

python --version
# → Python 3.11.7

⚠️ conda env list 결과에 base 만 있는 것이 정상입니다. 아직 가상환경을 안 만들었기 때문입니다.

8.5 가상환경 만들기

conda create -n venv python=3.13 -y
conda init

여기서 Cursor를 완전히 종료했다가 다시 실행합니다. (창만 닫는 게 아니라 프로그램 종료)

conda activate venv

성공 신호: 프롬프트 앞이 (base) 에서 (venv) 로 바뀝니다.

(base) C:\project>   →   (venv) C:\project>

⚠️ 에러가 나면 그 자리에서 바로 물어보세요. 환경 문제는 뒤로 미룰수록 원인이 겹쳐서 찾기 어려워집니다.

8.6 판다스가 이 환경에서 동작하는지 확인

가상환경을 만들었으면 거기서 실제로 라이브러리가 import 되는지 확인해야 합니다. 이 확인을 건너뛰면, 나중에 코드가 안 돌 때 코드 문제인지 환경 문제인지 구분이 안 됩니다.

준비

1. 프로젝트 안 apps 폴더에 titanic_starter.py 를 만듭니다.
2. 같은 폴더에 Titanic-Dataset.csv 를 둡니다.

코드

from pathlib import Path
import pandas as pd

csv_path = Path(__file__).parent / "Titanic-Dataset.csv"
df = pd.read_csv(csv_path)
print(df.head())
print(df.shape)

⭐ Path(__file__).parent 를 쓰는 이유가 중요합니다. 그냥 "Titanic-Dataset.csv" 라고만 쓰면, 파일을 어느 폴더에서 실행했느냐에 따라 찾기도 하고 못 찾기도 합니다. __file__ 기준으로 쓰면 어디서 실행하든 같은 파일을 가리킵니다. ("실행하는 위치 기준"과 "파일이 있는 위치 기준"의 차이 — 이건 나중에 .env 파일에서 다시 문제가 됩니다.)

실행 — (venv) 가 붙은 터미널에서:

python apps\titanic_starter.py

정상 출력

   PassengerId  Survived  Pclass  ...     Fare Cabin  Embarked
0            1         0       3  ...   7.2500   NaN         S
1            2         1       1  ...  71.2833   C85         C
...
[5 rows x 12 columns]
(891, 12)

출력 읽는 법

검증 — CSV를 에디터로 열어 첫 데이터 행을 봅니다.

1 / 0 / 3 / Braund, Mr. Owen Harris / male / 22 ...

터미널 출력의 첫 줄(0 1 0 3 ...)과 일치하면 성공입니다. PassengerId=1, Survived=0, Pclass=3 이 그대로 보입니다.

⭐ 이 확인이 뜻하는 것: 파이썬이 설치됐고, 가상환경이 활성화됐고, 그 환경에 판다스가 있고, 파일 경로가 맞다 — 네 가지가 한 번에 검증된 것입니다.

8.7 깃허브에 코드 올리기

저장소 만들기

1. github.com/[내아이디] 접속 → Repositories 탭 → 초록색 New 버튼
2. 입력값:

1. Create repository 클릭

⚠️ README·gitignore·license를 전부 끄는 이유: 이것들을 켜면 GitHub가 원격에 커밋을 하나 먼저 만듭니다. 그러면 아직 커밋이 없는 내 로컬과 이력이 어긋나서, 첫 push 가 거부됩니다. 빈 저장소로 만들어야 아래 6줄이 그대로 통합니다.

올리기

저장소를 만들면 나오는 …or create a new repository on the command line 코드 블록을 복사한 뒤, README.md 부분을 지우고 . 으로 바꿔 실행합니다.

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

성공 신호

* [new branch]      main -> main
branch 'main' set up to track 'origin/main'

• 첫 줄: 원격에 main 이라는 가지가 새로 생겼다
• 둘째 줄: 앞으로 로컬 main 은 원격 origin/main 을 따라간다 (이게 -u 의 효과)

에러가 나면 — 대부분 신원 정보가 없어서입니다.

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

설정한 뒤 git commit 부터 다시 실행합니다.

8.8 도메인 구입

배포는 아직 멀었지만, 내 이름의 주소를 하나 확보합니다. (4.6절의 이유)

1. 도메인 등록 서비스(가비아)의 도메인 검색창(www. 뒤 입력란)에 원하는 이름을 입력하고 검색
2. 검색 결과에서 원하는 도메인(예: example.cloud) 행의 선택 클릭 → 우측 "도메인 장바구니"에 담김 → 하단 신청하기
3. 1 신청 정보 입력 단계

   ⚠️ "도메인 1" 카드의 기간 드롭다운이 기본 3년 입니다. 반드시 1년 으로 바꾸세요. 이걸 놓치면 3년치가 결제됩니다. 가장 많이 놓치는 지점입니다.

4. ⑤ 결제 금액 계산 확인 — 프로모션 도메인의 경우 예를 들면 이런 구성입니다.

확인 후 다음 단계 5. (선택) "새로운 기기에서 로그인 되었습니다" 확인 메일이 오면 예, 맞습니다. 클릭. 메일이 없으면 그대로 진행 6. 소유자 정보 인증

• 이메일 에 회원가입 시 쓴 주소 입력 → 인증 메일 발송
• 메일함에서 [가비아] 인증번호를 안내해 드립니다. 를 열어 인증번호 확인
• 입력란에 넣고 확인 (⚠️ 제한시간 약 3분)
• 소유자명(영문) 은 Hong.Gil-dong 형식 (성.이름)

1. 2 서비스 비용 결제 → 완료 화면에 결제가 성공적으로 완료되었습니다. 표시

💡 첫 해 프로모션 가격과 갱신 가격은 다릅니다. 1년 뒤에는 정가로 갱신됩니다. 그래서 기간을 1년으로 줄여 두고, 실제로 쓸지 1년 뒤에 다시 판단하는 편이 낫습니다.

8.9 막힐 때 — 에러를 전달하는 법

이번 주부터 계속 쓰게 될 기술입니다. 명령어를 외우는 것보다 상황을 설명하는 능력이 중요합니다.

전달할 4요소

⭐ 3번은 요약하지 말고 그대로 복사해서 붙여넣으세요. 에러 메시지의 정확한 문구가 원인을 특정하는 가장 강한 단서입니다. "에러가 났다"는 정보가 거의 없지만, CommandNotFoundError 라는 단어 하나면 원인이 좁혀집니다.

---

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

이 주에 함께 본 자료들입니다. 각각 왜 개강 주에 나왔는지가 중요합니다.

9.1 Claude Code 창시자 Boris의 30분 워크숍

한국어 자막이 있는 30분짜리 워크숍 영상입니다. 다룬 내용은 넷입니다.

왜 개강 첫날에 이게 나왔는가 — 이 수업이 무엇을 목표로 하는지를 첫날 보여주기 위해서입니다. 목표는 "AI에게 코드를 받아 쓰는 것"이 아니라 "AI를 도구로 쓰는 개발 환경 자체를 구성하는 것" 입니다.

네 주제 중 뒤의 둘(claude -p, SSH+tmux)은 지금 당장은 이해되지 않아도 됩니다. 다만 "AI는 채팅창 안에만 있는 게 아니다" 는 감각만 가져가면 됩니다.

이 영상에 나온 CLAUDE.md 방식은 나중에 하네스 엔지니어링이라는 이름으로 이 수업의 큰 줄기가 됩니다.

9.2 IBM의 AI 정의 정리

AI / 머신러닝 / 딥러닝 / 생성형 AI / AI 에이전트, 약한 AI vs 강한 AI, 그리고 윤리·거버넌스까지 이어지는 개념 계층 자료입니다.

왜 이 자료인가: 1장 전체가 이 자료의 구조를 따라갑니다. 중요한 것은 개별 정의가 아니라 정의들이 계층으로 배열되어 있다는 사실 자체입니다. IBM 같은 회사가 개념 계층 문서를 공들여 만드는 이유는, 경계가 흐려지면 계약과 규제가 성립하지 않기 때문입니다. "우리 제품은 AI입니다"와 "우리 제품은 생성형 AI입니다"는 법적으로 다른 문장이 되어 가고 있습니다.

9.3 Red Hat AI

🔗 https://www.redhat.com/ko/products/ai

오픈소스 기반의 AI 솔루션 플랫폼입니다.

왜 이 주에 나왔는가: 1.6절의 "API로 부르기 ↔ 로컬에서 돌리기" 축의 기업판입니다. 기업이 자기 데이터를 외부 AI 서비스에 보내지 않고 자기 인프라 안에서 AI를 돌리려 할 때 쓰는 종류의 제품입니다. 축 2(로컬 ↔ 원격)가 개인의 편의 문제가 아니라 기업의 보안·규제 문제가 되는 지점입니다.

9.4 「바퀴를 재발명하지 않기」

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

왜 이 주에 나왔는가: 6.4절에서 다뤘습니다. 같은 날 import pandas 를 처음 실행했기 때문입니다. import 한 줄을 치는 순간이 "남이 만든 것을 내 것에 들여놓는" 첫 경험입니다. 그 순간에 이 글이 배치된 것입니다.

9.5 EBS 《위대한 수업》 AI 시즌

제프리 힌튼, 얀 르쿤, 스튜어트 러셀 등의 라인업을 소개하는 쇼츠 영상입니다.

왜 이 주에 나왔는가: 개강 주는 동기를 만드는 주이기도 합니다. 그리고 이 세 사람의 이름은 1장의 계층과 직접 이어집니다. 힌튼과 르쿤은 딥러닝을 지금의 모습으로 만든 사람들이고, 러셀은 AI 안전·거버넌스를 대표하는 사람입니다. IBM 자료의 마지막 계층(윤리·거버넌스)이 왜 계층의 일부인지가 여기서 설명됩니다.

9.6 네이버 국가대표 AI 탈락 — 표절 논란

국가대표 AI 사업에서 한 기업이 탈락했고, 핵심 장치에 외부(중국산) 기술을 사용한 것이 드러나 표절 논란이 일었다는 보도입니다.

왜 이 주에 나왔는가 — 뉴스 자체가 아니라 질문 때문입니다.

"무엇을 가져다 쓰고, 무엇을 직접 만드는가?"

같은 주에 배운 "라이브러리를 import 해라(바퀴를 재발명하지 마라)"와 정면으로 부딪히는 사례입니다. 그래서 이 뉴스가 6.5절의 경계표를 만드는 계기가 됩니다.

⭐ 개강 첫 주에 이 질문을 받아두는 것이 중요합니다. 앞으로 라이브러리를 수십 개 설치하게 됩니다. 그때마다 "이건 가져다 쓰는 쪽인가, 직접 만드는 쪽인가"를 자동으로 묻게 되면, 4개월 뒤 클린 아키텍처를 배울 때 그 원 그림이 이미 머릿속에 있게 됩니다.

---

부록 A. 용어 사전

---

부록 B. 스스로 확인하기

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

---

부록 C. 자주 하는 실수

---

부록 D. 날짜별 색인

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

---

부록 E. Gemini / NotebookLM 프롬프트

복습 문제 받기

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

인포그래픽 ① — AI 계열의 포함 관계

「1.1 다섯 단어는 대등하지 않습니다」와 「1.3 AI 에이전트는 이 계열이 아닙니다」를 합쳐
인포그래픽 1장으로 만들어줘.
- AI ⊃ 머신러닝 ⊃ 딥러닝 ⊃ 생성형 AI 를 동심원(또는 중첩 상자)으로
- 각 층 옆에 "종차" 한 줄씩 (무엇이 새로 추가되는가)
- AI 에이전트는 그 동심원 밖에 따로 두고 "축이 다름"을 화살표로 표시
- 약한 AI / 강한 AI 는 아래쪽에 별도 축으로
- 전문용어는 한글(영문) 병기

인포그래픽 ② — 다섯 개의 판별 축

「0. 이 장의 판별 축」 표를 인포그래픽 1장으로 만들어줘.
- 축 5개를 가로 막대 5줄로, 왼쪽 끝이 0 오른쪽 끝이 1
- 각 막대 아래에 이번 주 사례를 하나씩 (AI⊃ML / Git↔GitHub / base↔venv / 0↔1 / 자연어↔기계어)
- 오른쪽 여백에 "이 축이 다시 나오는 곳"을 작은 글씨로
- 축 5(추상↔구상)를 가장 굵게 강조 — 교재 전체에서 가장 많이 쓰이는 축

인포그래픽 ③ — 첫 push 6줄과 로컬/원격 경계

「4.2 첫 push 6줄의 의미」를 세로 흐름도로 만들어줘.
- 왼쪽에 "내 컴퓨터(로컬)" 영역, 오른쪽에 "GitHub(원격)" 영역을 세로 띠로 나누고
- git init / add / commit / branch -M / remote add / push 를 순서대로 배치
- 6줄 중 5줄이 로컬 안에서 끝나고 마지막 push만 경계를 넘는다는 것을 굵은 화살표로
- 각 명령 옆에 "몇 번 하나(1번/매번)"를 배지로 표시

막힐 때

1주차에서 "___" 가 이해가 안 돼.
이 교재의 판별 축 5개(포함관계 / 로컬↔원격 / 전역↔격리 / 0↔1 / 추상↔구상)만
써서 다시 설명해줘. 교재에 없는 새 비유는 만들지 마.

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

이 교재에 나온 비유(작업 일지와 온라인 사무실, 도구상자와 작업장, 레시피)를 전부 걷어내고,
"이것은 무엇의 한 종류인가 / 형제 개념과 무엇으로 갈리는가" 형식으로만
머신러닝·딥러닝·생성형 AI·이진 분류·가상환경·라이브러리·프레임워크를 다시 정의해줘.

환경 문제 진단 받기

나는 1주차 교재의 8.4~8.6 절차를 따라 하는 중이야.
지금 상황은 [상황], 실행한 명령은 [명령], 오류 메시지 원문은 [원문],
내가 원하는 결과는 [결과] 야.
교재 부록 C의 "자주 하는 실수" 표에 해당하는 항목이 있는지 먼저 확인하고,
없으면 그 다음에 다른 원인을 추정해줘.

다음 장 연결 확인

이 교재에서 "앞으로 다시 만납니다"라고 표시된 부분을 전부 찾아서,
이번 장의 어떤 개념이 몇 주차에 어떤 이름으로 다시 나오는지 표로 정리해줘.
컬럼은 "1주차의 개념 / 다시 나오는 주차 / 그때의 이름" 으로.