AI 코딩
셀프스터디 핸드북

세 가지 규칙

1. 한 장씩, 터미널을 켜 놓고. 장마다 마지막에 「직접 해보기」가 하나씩 있습니다. 그걸 하지 않으면 그 장은 안 읽은 것으로 칩니다.
2. 모르는 단어가 나오면 즉시 부록 B(용어집). 모르는 채로 다음 문단으로 넘어가지 마세요. 이 분야는 단어 하나 막히면 그 뒤가 전부 안 보입니다.
3. 막히면 AI에게 물어보세요. 이 책의 어떤 문단이든 그대로 복사해서 Claude Code에 붙여넣고 "이거 내 상황에 맞게 다시 설명해줘"라고 하면 됩니다. 그게 이 도구를 쓰는 방식 그 자체입니다.

읽는 순서

01~06은 개념, 07~09는 실전 절차, 10~11은 다음 단계입니다. 급하면 06→07→08만 먼저 해도 서비스는 배포됩니다. 다만 04(토큰·컨텍스트)를 건너뛰면 어느 날 요금이나 성능에서 반드시 대가를 치릅니다.

GUI와 CLI

GUI(Graphical User Interface)는 우리가 평소 쓰는 방식입니다. CLI(Command Line Interface)는 개발자들이 쓰는 방식이고요. 둘은 같은 컴퓨터를 다루는 두 개의 문입니다.

핵심 문장 하나

오늘 CLI를 쓰는 이유는 셋입니다. ① 클릭 10번 할 걸 명령어 1줄로 끝냅니다. ② 명령어는 AI가 자동으로 만들어주므로 외울 필요가 없습니다. ③ Vercel·Supabase 같은 배포 도구는 CLI로 할 때 가장 간편합니다.

무엇이 바뀌나

마인드셋 세 가지 전환

1. "어떻게 하지?" → "누구에게 시키지?" — 방법을 몰라도, 잘 시키기만 하면 됩니다.
2. "내가 다 알아야 해" → "AI가 알고, 나는 검증한다" — 전문가가 아니어도 방향만 잡으면 됩니다.
3. "완벽하게 한 번에" → "빠르게 시키고 고쳐가며" — 대화하듯 반복해서 다듬는 게 정답입니다.

이제 경쟁력은 "내가 얼마나 잘 만드느냐"가 아니라 "AI에게 얼마나 잘 시키느냐"입니다.

Harness Engineering

• AI가 코드를 작성하고, 사람은 방향을 제시하고 검증합니다.
• 전통적인 코딩 지식보다 문제 정의와 AI와의 대화 능력이 중요해집니다.
• 명확한 지시 → 결과 검토 → 반복 개선. 이 루프가 Harness Engineering입니다.

오늘 만들 것의 크기 정하기 (MVP)

혼자 공부할 때도 똑같습니다. 하루 안에 만들고 배포까지 끝낼 수 있는 크기로 범위를 자르세요. 여기서 그날의 결과가 결정됩니다. "무엇을 뺄 것인가"를 먼저 정하는 게 MVP입니다.

무엇까지 만들 수 있나 — 여덟 단계

"AI 코딩"이라고 하면 웹사이트부터 떠올리지만, 실제로 만들어지는 것의 대부분은 아래쪽 단계입니다. 위로 갈수록 필요한 도구가 하나씩 늘어날 뿐, 전부 알아야 시작할 수 있는 게 아닙니다.

겉모습은 달라도 흐름은 같습니다 — 무언가를 입력받고, 규칙대로 처리하고, 결과를 저장하거나 보여준다.

처음엔 잘 되다가 무너지는 이유

말하면 화면이 나오고, 고쳐달라면 고쳐집니다. 그런데 기능이 하나씩 붙기 시작하면 어느 순간 한 번에 해내지 못하는 지점이 옵니다. 그때 코드를 한 번도 안 본 채 “다시 해줘”만 반복하면, 내 의도와 결과물이 조금씩 멀어집니다.

• 여기를 손보면 멀쩡하던 저기가 멈춥니다.
• 내 화면에서는 멀쩡한데 남에게 보낸 주소에서는 안 열립니다.
• 빨간 글씨가 떠도 어디부터 봐야 할지 몰라 같은 요청만 다시 넣게 됩니다.

원인은 결국 둘입니다.

터미널이란

• Windows — PowerShell. 시작 메뉴에서 "PowerShell" 검색 → Enter
• Mac — 터미널(Terminal). ⌘ + Space → "터미널" 입력 → Enter

명령어 실행법: 회색 박스의 텍스트를 복사(⌘C / Ctrl+C) → 터미널에 붙여넣기(⌘V / 마우스 우클릭) → Enter.

왜 이름이 '터미널'인가

라틴어 terminus(끝·경계·종착점)에서 왔습니다. 옛날에는 방 하나를 채우는 거대한 메인프레임 한 대뿐이었고, 사람들은 본체에서 멀리 떨어진 책상에서 선의 맨 끝에 매달린 입출력 장치로 명령을 넣고 결과를 받았습니다. 한국어 단말기(端末機) — '끝 단, 끝 말'의 기계 — 도 같은 뜻입니다.

60년 전 종이에 글자를 찍던 텔레타이프(Teletype, tty의 어원)가, 지금은 AI에게 일을 시키는 통로로 부활한 셈입니다.

알아야 할 명령어 4개 (+1)

거의 다 양쪽이 같습니다. 실제로는 cd 뒤에 폴더 경로를 복사해서 붙여넣는 것이 대부분이라, 외울 것도 사실상 없습니다.

파일과 폴더 — GUI의 위치를 CLI로 번역하기

같은 위치를 GUI는 내 Mac > 사용자 > 내이름 > Downloads로, CLI는 경로(path)라는 한 줄 문자열로 씁니다 — /Users/내이름/Downloads (Mac) 또는 C:\Users\내이름\Downloads (Windows).

• . 은 현재 폴더, .. 는 부모(한 단계 위) 폴더를 뜻합니다.
• 공백이 있는 폴더명은 따옴표로 감싸세요 — cd "My Folder"

Local과 Global — 어디서 Claude를 켜느냐의 문제

그래서 홈(바탕화면보다 위) 아래에 상위 폴더 하나를 먼저 만들고 그 안에 프로젝트를 넣습니다. 이 폴더가 AI를 하위 어디로든 파견하는 본부가 됩니다.

ai/                  ← 여기서 claude 켜기 (Global 본부)
├── gimbab/          ← 프로젝트 1
├── my-portfolio/    ← 프로젝트 2
└── todo-app/        ← 프로젝트 3

나는 지금 어디에 있을까

• 터미널이면 프롬프트에 현재 폴더 경로가 보입니다.
• Claude Code 안이면 입력줄이 > 로 시작합니다. 이게 보이면 클로드 코드 안입니다.
• 추천 뷰 세팅: 왼쪽에 작업 폴더의 터미널, 오른쪽에 같은 폴더의 Claude Code.

왜 데스크탑 앱이 아니라 터미널인가

데스크탑 앱(Claude·ChatGPT)의 다섯 가지 한계:

1. 내 파일·폴더에 직접 손을 못 댄다. 코드를 받으려면 복사 → 붙여넣기 → 저장을 내가 반복해야 합니다.
2. 명령을 실행할 수 없다. npm install, 서버 켜기, git push, 배포를 대신 실행해주지 못합니다.
3. 에이전트 루프가 없다. 한 번 답하고 끝. CLI는 "읽기 → 수정 → 실행 → 에러 확인 → 재수정"을 스스로 반복합니다.
4. Harness(확장 도구)가 안 붙는다. MCP·Subagents·Hooks·슬래시 명령이 거의 안 돌아갑니다.
5. 컨텍스트 관리가 어렵다. /compact나 프로젝트 규칙 파일 같은 정교한 관리가 안 됩니다.

그럼 앱은 언제? 질문·브레인스토밍, 글쓰기·요약, 이미지 보고 물어보기. 즉 생각과 대화는 앱, 실제로 컴퓨터에서 일 시키기는 터미널입니다.

VSCode 플러그인을 쓰지 않는 이유

플러그인은 에디터 안에 갇힌 조수, 터미널 Claude Code는 컴퓨터 전체를 쓸 수 있는 AI 엔지니어입니다.

다만 코드 한 블록만 고칠 때나 자동완성 용도로는 플러그인도 괜찮습니다. "프로젝트 전체를 AI에게 맡기고 싶다"면 터미널입니다.

/model — 어떤 두뇌를 쓸지 고르기

바꾸는 법: /model 입력 → Enter → 화살표(↑↓)로 선택 → Enter. 이후 대화부터 적용됩니다.

모델 옆에는 추론 강도(effort) 설정도 있습니다. 깊게 생각할수록 시간과 토큰을 더 씁니다. 하루 종일 쓰는 학습·실습에는 medium 정도가 균형이 좋습니다.

권한 모드 — 얼마나 물어보게 할지

Shift + Tab 을 누를 때마다 다음 순서로 돌아갑니다.

계정 조건이 맞으면 auto 가 plan 뒤에 하나 더 붙습니다. 안전하다고 판단한 작업은 묻지 않고 진행하는 모드입니다. 화면에 안 보인다면 그 계정에서는 아직 안 열린 것이니 신경 쓰지 않아도 됩니다.

plan 으로 시작해서 auto 로 넘기기

이게 실전에서 가장 많이 쓰는 흐름입니다. 계획을 먼저 보고, 납득한 다음에 자동으로 돌립니다.

1. Shift + Tab 으로 plan 진입 → 시킬 일을 말합니다.
2. Claude가 계획을 써서 보여주고 승인을 묻습니다.
3. 선택지가 세 개 뜹니다.

Claude has written up a plan and is ready to execute. Would you like to proceed?

❯ 1. Yes, and use auto mode
  2. Yes, manually approve edits
  3. Tell Claude what to change
     shift+tab to approve with this feedback

• 1번을 권합니다. 계획을 이미 읽었으니 단계마다 다시 물어볼 이유가 없습니다.
• 2번은 하나하나 확인하고 싶을 때. 느리지만 가장 안전합니다.
• 3번은 계획이 마음에 안 들 때. 고칠 점을 말하면 계획을 다시 씁니다.

더 깊게 생각시키기 — think

이건 모드가 아니라 프롬프트에 넣는 말입니다. 답을 내기 전에 더 오래 따져보게 만듭니다.

• think → think hard → think harder → ultrathink 순으로 깊어집니다.
• 예: “ultrathink 해서 왜 이 에러가 나는지 분석해줘.”
• 생각도 출력 토큰을 씁니다. 어려운 문제에만 쓰세요.

되돌리기 — /rewind

/rewind 는 대화와 파일 변경을 이전 지점으로 되돌립니다. 입력창이 비어 있을 때 Esc 를 두 번 눌러도 같은 메뉴가 열립니다.

자주 쓰는 슬래시 명령

대화를 정리하는 두 가지 — /clear 와 /compact

비슷해 보이지만 판단 기준이 다릅니다.

한 줄로: 새 기능을 시작하면 /clear, 같은 버그를 계속 쫓는 중이면 /compact.

입력창 기본기

이걸 모르면 긴 지시를 쓰다가 엔터를 눌러 중간에 날아갑니다.

볼 대상을 좁혀주기 — @ 멘션

“알아서 찾아봐”보다 어디를 보라고 짚어주는 쪽이 훨씬 정확하고 훨씬 쌉니다.

• @파일이름 또는 @폴더이름 — 그것만 보게 합니다.
• 파일을 터미널 창으로 끌어다 놓아도 같은 효과입니다.
• 화면이 이상할 때는 스크린샷을 붙여넣으세요. 말로 열 줄 설명하는 것보다 빠릅니다.

@견적서 폴더에 있는 PDF 세 개만 비교해줘.
항목별 단가가 어떻게 다른지 표로 만들고,
가장 싼 곳과 가장 비싼 곳의 차이가 어디서 나는지
한 문단으로 설명해줘.

딴 얘기 하고 돌아오기 — /btw

작업 도중에 “근데 이건 뭐야?”가 떠오릅니다. 그냥 물어보면 본 대화가 옆길로 샙니다.

• /btw 뒤에 물어보면 곁가지 대화로 처리되고 본 작업 맥락은 그대로 남습니다.
• 다 물어봤으면 Esc 를 눌러 원래 세션으로 돌아오세요. 이걸 안 하면 계속 곁가지에 머무릅니다.

/resume — 하던 작업 이어서 하기

이전에 나눴던 대화를 그대로 불러와 끊긴 지점부터 이어갑니다. 어제 멈춘 프로젝트를 오늘 다시 열 때, 실수로 터미널을 껐을 때 씁니다.

1. 작업하던 프로젝트 폴더로 이동 (cd 폴더명)
2. claude 입력
3. /resume 입력 → 최근 대화 목록에서 화살표로 선택 → Enter

/resume은 같은 폴더에서 했던 대화만 보여줍니다. 다른 프로젝트를 찾는다면 먼저 그 폴더로 cd 하세요. 너무 오래된 대화는 /compact로 한 번 정리하고 이어가면 쾌적합니다.

HUD — AI가 일하는 걸 보는 계기판

터미널 하단에 항상 떠 있는 상태 표시줄입니다. 조종사가 고개를 숙이지 않고 전방 유리에서 계기판을 보듯, 시선을 떼지 않고 핵심 정보를 확인합니다.

• 컨텍스트 사용량 — 기억 공간을 얼마나 썼는지 게이지로
• 비용 추정 — 현재 세션에서 쓴 비용
• 활성 도구 — 지금 파일 읽기/쓰기/명령 실행 중 무엇을 하는지
• Todo 진행률 — 시킨 작업 목록의 완료 상태
• Git 브랜치 — 현재 작업 중인 코드 브랜치

계기판 직접 설정하기 — statusline

화면 아래에 늘 보이는 줄을 원하는 항목으로 바꿀 수 있습니다. 매번 /status 를 칠 필요가 없어집니다.

처음에는 이 세 가지면 충분합니다 — 지금 폴더, 쓰고 있는 모델, 컨텍스트 사용률. 사용률이 보이면 /compact 할 시점을 감으로 알 수 있습니다.

/statusline 지금 폴더 이름이랑 쓰고 있는 모델, 컨텍스트 남은 양을 한 줄로 띄워줘

토큰이란

• 영어 단어 1개 ≈ 1.3토큰 (hello = 1토큰, unbelievable = 3토큰)
• 한글 1글자 ≈ 1~2토큰 — 한글은 영어보다 토큰을 더 먹습니다
• 공백, 줄바꿈, 이모지도 전부 토큰으로 계산됩니다

택시 미터기처럼, 글자 하나하나가 요금으로 찍힙니다.

Input과 Output

Input Token — AI에게 읽으라고 주는 모든 것: 내 질문, 첨부한 파일·이미지·코드, 시스템 프롬프트, 프로젝트 메모 파일, 이전 도구 실행 결과, 그리고 지금까지의 대화 전체.

핵심은 여기입니다. 100번째 메시지를 보낼 때 AI는 1~99번 메시지를 다시 다 읽고 답합니다. 대화가 길어질수록 입력 토큰이 누적됩니다.

Output Token — AI가 만들어 돌려주는 것: 답변 텍스트, 작성한 코드, 리스트·표·요약, 도구 호출 인자.

그래서 입력 5페이지 ≈ 출력 1페이지 값입니다. 긴 답변을 요구하면 비용이 급격히 오릅니다.

Context와 Context Window

컨텍스트에 들어가는 것: ① 지금까지의 대화 ② 첨부한 파일·이미지 ③ 시스템 프롬프트 ④ 프로젝트 메모 파일 ⑤ 도구 실행 결과 ⑥ MCP에서 가져온 데이터.

Context Window = Input + Output 합산 한도입니다. Input이 한도의 대부분을 먹으면 Output이 잘립니다. /compact로 입력을 줄여 출력할 공간을 확보하는 이유가 이것입니다.

꽉 차면 생기는 일: 속도 저하(매번 전체를 다시 읽음), 비용 증가, 성능 저하(중요한 정보가 오래된 대화에 묻힘), 기억 상실(초반 규칙을 잊음).

책상이 크다고 좋은 게 아니다 — Lost in the middle

그래서 “파일 200개 다 줄 테니 알아서 해”는 오히려 결과가 나빠집니다. 컨텍스트 윈도우가 커졌다는 말은 담을 수 있다는 뜻이지 다 똑같이 잘 본다는 뜻이 아닙니다.

대응 세 가지

1. 필요한 것만 준다. @ 멘션으로 볼 파일을 짚어주세요(03장).
2. 중요한 지시는 맨 끝에 한 번 더. 긴 자료를 붙인 뒤 마지막 줄에 핵심 요구를 다시 씁니다.
3. 길어지면 정리한다. /compact 로 가운데를 요약해 없앱니다.

토큰을 많이 먹는 일곱 가지 상황

1. 긴 대화가 계속 이어질 때 (가장 흔함) — 매번 대화 전체를 다시 읽습니다. → /compact 또는 /clear
2. 큰 파일을 통째로 첨부할 때 — PDF 50페이지 ≈ 3만 토큰. → 관련 부분만 잘라서
3. 이미지·스크린샷이 많을 때 — 1장 ≈ 800~1,600토큰, 고해상도는 3,000토큰까지. → 꼭 필요한 것만, 리사이즈해서
4. 웹 검색·URL 읽기 — 페이지 전체를 가져옵니다. → "핵심 3줄로 요약"처럼 출력 범위 제한
5. 코딩 작업 — 전체 폴더 탐색 1만+, 긴 에러 로그 5,000~2만. → .gitignore 설정을 잘 해두기
6. MCP를 많이 붙였을 때 — 연결된 MCP 설명서가 매 요청마다 자동 포함. 5개 = 항상 5,000~1만 토큰 고정 비용. → 필요한 것만 켜두기
7. 출력을 길게 시킬 때 (가장 비쌈) — "전체 코드 다 다시 써줘" 같은 요청. → "수정된 부분만", "간결하게", "표로만"

비용 감각

Compacting — 요약해서 공간 만들기

/compact를 치면 지금까지의 대화를 AI가 스스로 요약하고, 중요한 맥락(프로젝트 목표, 파일 구조, 진행 상황, 결정 사항)만 추린 뒤 세부 대화는 버립니다.

언제 쓰나: HUD에서 컨텍스트가 70~80%를 넘었을 때 / 큰 작업 단계가 끝났을 때 / AI가 초반에 말한 걸 잊기 시작할 때 / 응답이 눈에 띄게 느려졌을 때.

Context Engineering

프롬프트 엔지니어링이 "질문을 잘 하는 기술"이라면, 컨텍스트 엔지니어링은 "작업실 전체를 세팅하는 기술"입니다.

실전 기법 네 가지:

• 스코핑 — 한 대화에서 너무 많은 것을 시키지 않기. 작업을 영역별로 나눠 새 세션으로
• 기록 — 프로젝트 규칙·코딩 스타일·자주 쓰는 명령어를 프로젝트 메모 파일에 미리 적어두기
• 압축 — /compact로 길어진 대화를 요약
• 선별적 첨부 — 관련 파일만 골라 보여주기. "전체 코드를 다 읽어"는 오히려 독

절약 팁 다섯

1. 긴 파일은 통째로 첨부하지 말고 관련 부분만 (Input 절약)
2. "간결하게 답해"라고 명시 (Output 절약)
3. /compact 자주 사용
4. 새 작업은 새 세션(/clear)에서 — 이전 대화가 입력에 안 끼어듭니다
5. 반복 규칙은 프로젝트 메모 파일에 — 매번 설명하는 토큰 낭비 방지

왜 이 장이 필요한가

AI가 코드를 다 써줘도, 결과를 읽고 판단하는 건 나입니다. “404가 떴어요”와 “서버는 살아 있는데 그 주소에 아무것도 없대요”는 같은 말인데, 앞의 문장만 알면 다음에 뭘 해야 할지 모릅니다.

이 장은 문법을 배우는 장이 아닙니다. 단어를 아는 장입니다.

요청과 응답 — 웹에서 벌어지는 일 전부

브라우저에 주소를 치면 이 일이 일어납니다.

1. 내 브라우저가 “이 주소의 화면을 주세요” 하고 요청을 보냅니다.
2. 그 주소의 컴퓨터(서버)가 받아서 처리합니다.
3. 결과를 돌려줍니다. 화면일 수도 있고, 데이터일 수도 있고, 에러일 수도 있습니다.

내 컴퓨터에서 열리는 localhost 도 똑같습니다. 다만 주방이 내 집 안에 있을 뿐입니다(08장).

상태 코드 — 응답에 붙는 세 자리 숫자

응답에는 항상 어떻게 됐는지 알려주는 숫자가 붙습니다. 이 셋만 알면 대부분의 상황이 구분됩니다.

프론트엔드와 백엔드

“화면은 나왔는데 저장이 안 돼요”는 프론트는 되고 백엔드가 안 되는 상황입니다. 어느 쪽 문제인지 말할 수 있으면 AI가 훨씬 빨리 고칩니다.

데이터베이스와 CRUD

거기서 하는 일은 결국 네 가지뿐이고, 앞글자를 따서 CRUD 라고 부릅니다.

Claude Code 가 내 폴더에서 하는 일도 정확히 이 네 가지입니다 — 파일을 만들고, 읽고, 고치고, 지웁니다. 그래서 어느 폴더에서 켜느냐가 곧 권한 설정입니다(02장).

라이브러리와 프레임워크

왜 알아야 하냐면, AI가 “Next.js 로 만들까요?” 라고 물을 때 그게 골조를 하나 고르는 결정이라는 걸 알아야 하기 때문입니다. 골조는 도중에 바꾸기 어렵습니다. 공구는 아무 때나 바꿔도 됩니다.

초보자에게 권하는 판단: AI가 추천하는 기본값을 그대로 쓰세요. 대신 “왜 이걸 골랐어?” 는 한 번 물어보세요. 그 답이 나중에 바꿀지 말지를 정할 때 근거가 됩니다.

에러와 로그 — 겁내지 않고 읽는 법

빨간 글자가 쏟아지면 대부분 창을 닫아버립니다. 그럴 필요 없습니다.

1. 맨 아래부터 보세요. 보통 마지막 줄에 진짜 원인이 있습니다.
2. 파일 이름과 줄 번호가 적혀 있습니다. 거기가 사고 지점입니다.
3. 그대로 복사해서 AI에게 주세요. 요약하지 마세요 — 요약하면서 원인이 날아갑니다.

여섯 겹

1. Core — Claude 모델
   실제로 사고하고 코드를 생성하는 LLM. 모든 것의 중심이지만, 혼자서는 파일을 읽거나 명령을 실행할 수 없습니다.
2. Runtime — Claude Code (CLI)
   모델에게 손과 발을 달아주는 실행 환경. 터미널에서 claude를 치면 열리는 그것. 파일 읽기·쓰기, 명령 실행, Git 조작을 담당합니다.
3. Context Layer — 프로젝트 메모 파일 & 설정
   "우리 프로젝트는 이렇게 생겼어"를 알려주는 메모리. 규칙, 코딩 스타일, 자주 쓰는 명령어를 적어두면 매번 설명할 필요가 없습니다.
4. Extension Layer — 확장 도구
   MCP(외부 서비스 연결), Subagents(특정 작업 전담 에이전트), Hooks(이벤트 발생 시 자동 실행), Slash Commands(자주 쓰는 동작의 단축어).
5. Harness Preset
   위 확장들을 한 번에 셋업해주는 플러그인 팩. 검증된 프롬프트·명령어·훅이 한꺼번에 설치됩니다.
6. Interface — HUD & 터미널
   사용자가 실제로 보는 계기판.

API란 무엇인가

일상 속 예시 — 날씨 앱이 기상청 API에 "서울 날씨 알려줘", 쇼핑몰이 결제 API로 결제 요청, 배달앱이 지도 API로 위치 불러오기.

최소한만 알면 되는 구성 요소

오늘 API를 직접 다룰 일은 거의 없습니다. Claude Code가 코드를 알아서 작성해주니까요. 다만 "이 서비스에 API가 있나?"를 확인하는 습관만 있으면, "이 API 붙여줘" 한마디로 기능이 생깁니다.

MCP란 무엇인가

같은 셰프인데 닿을 수 있는 재료의 범위가 완전히 달라집니다.

대표적인 MCP — Notion(페이지·DB 읽고 쓰기), GitHub(코드·이슈·PR), Figma(디자인 파일), Linear·Jira(티켓), Stripe(결제·금융), HubSpot·Salesforce(CRM), Sentry(에러 모니터링), Intercom(고객 대화).

단, MCP를 많이 연결할수록 매 요청마다 고정 토큰 비용이 붙습니다(04장). 필요한 것만 켜두세요.

API와 MCP의 차이

같은 일을 시킬 때 — API 방식은 문서 읽기 → 키 발급 → 코드 작성 → 응답 파싱 → 에러 처리(수 시간). MCP 방식은 설치 한 번(5분) → AI에게 그냥 말하기.

그럼 API는 쓸모없어졌나? 아닙니다. MCP는 내부적으로 API를 호출합니다.

[사용자] → [Claude] → [MCP 서버] → [실제 API] → [상대 서버]

언제 뭘 쓰나 — MCP가 있으면 무조건 MCP. 없으면 "이 API 문서 보고 코드 써줘"라고 AI에게 부탁. 내 앱에 기능을 넣을 때는 API 직접 호출(보통 AI가 코드를 씁니다).

CLAUDE.md — 같은 말을 두 번 하지 않기

두 군데에 둘 수 있고, 성격이 다릅니다.

둘 다 읽히고, 겹치면 프로젝트용이 이깁니다. 내 취향은 전체용에, 이 프로젝트만의 규칙은 프로젝트용에 두면 됩니다.

무엇을 적을까 — 오늘 AI가 틀렸던 것, 내가 내린 결정과 그 이유, 쓰지 말라고 한 것. 즉 “아까 말했잖아”가 나온 순간이 곧 여기 적을 거리입니다.

여기에 하나씩 쌓이는 게 복리입니다. 같은 피드백을 딱 한 번만 하게 만드는 것 — 이게 1주차에 오래 걸리던 일이 4주차에 한마디로 끝나는 이유입니다.

Git이란

왜 필요한가

• "어제는 됐는데 오늘 안 돼요" → 어제 잘 되던 버전으로 즉시 복귀
• "이것저것 고치다 다 꼬였어요" → 마지막 저장 지점으로 되돌리기
• 여러 명이 같은 코드를 동시에 고쳐도 충돌 없이 합칠 수 있음
• 파일 이름을 최종_진짜최종_v2_real.zip으로 안 만들어도 됨

Git과 GitHub는 다릅니다

즉 Git으로 저장(기록)하고 → GitHub에 올려서(백업·공유) 합니다.

핵심 세 단어

명령어를 외울 필요는 없습니다. Claude Code에게 그냥 말하면 됩니다 — "방금 작업한 거 commit하고 GitHub에 push해줘", "아까 잘 되던 버전으로 되돌려줘". AI가 알아서 git 명령어를 실행하니 우리는 개념만 이해하면 충분합니다.

localhost — 내 컴퓨터 안의 미리보기

• 뒤에 붙는 숫자는 포트(port) — 내 컴퓨터 안에서 어떤 서버인지 구분하는 번호입니다.
• 장점: 수정하면 즉시 반영(새로고침만) → 만들면서 확인하기 좋음
• 단점: 내 컴퓨터를 끄면 사라지고, 다른 사람은 접속할 수 없음

AI에게 "네가 만드는 거 보고 싶으니까 localhost로 띄워서 보여줘"라고 하면 실시간으로 확인할 수 있습니다.

HTML 파일 — 파일 하나짜리 웹페이지

index.html 같은 파일 하나를 더블클릭하면 브라우저에 화면이 뜹니다. 서버 없이 열리고 전달·보관이 쉽지만, 버튼 클릭·로그인·DB 저장 같은 앱 기능에는 한계가 있어 한 장짜리 소개·랜딩 페이지에 적합합니다.

세 가지 도구 — GitHub · Vercel · Supabase

결과물을 ① 안전하게 보관하고(GitHub) → ② 공유할 URL로 띄우고(Vercel) → ③ 회원가입·글 저장 같은 기능을 붙이려면(Supabase) 이 셋이 필요합니다. 대부분은 AI가 알아서 해주니 가입만 해두면 됩니다.

GitHub — 코드의 클라우드

• 내가 만든 코드를 인터넷에 백업. 노트북이 망가져도 코드는 안전합니다.
• 버전 기록이 남아 잘못 고쳐도 예전 상태로 되돌릴 수 있습니다.
• 다른 컴퓨터에서 이어서 작업할 때 여기서 내려받습니다(09장).

Vercel — 내 사이트를 세상에 띄워주는 곳

• localhost에서만 돌던 화면을 누구나 접속 가능한 URL로 만들어 줍니다.
• GitHub에 올린 코드를 자동으로 가져와 몇 초 만에 배포합니다.
• 글로벌 CDN, 수정할 때마다 프리뷰 URL 자동 생성, 커스텀 도메인 연결도 간단합니다.

Supabase — 데이터 창고 + 로그인 담당

• 회원가입, 글·사진 저장, 좋아요 수 같은 기억해야 하는 정보를 보관하는 데이터베이스(PostgreSQL 기반)
• 인증(Auth) — Google, GitHub 등 소셜 로그인을 간단히 구현
• 스토리지 — 이미지·파일 업로드/다운로드
• Realtime — 데이터 변경을 실시간 구독 (채팅, 알림 등)

흐름은 GitHub(보관) → Vercel(배포) → Supabase(데이터)입니다.

배포하기

프론트엔드만 필요하면 Vercel만. 데이터베이스·백엔드도 필요하면 Supabase까지. 이것들을 전부 CLI로 진행해서 AI가 나 대신 하게 시킵니다.

supabase.com/docs, vercel.com/docs 의 CLI를 설치해서 CLI를 활용해서
배포를 진행하자. github, supabase와 vercel은 다 가입했고
비개발자임을 고려해서 진행해줘.

이 두 번째 문장이 이 부트캠프에서 가장 많이 쓰게 되는 프롬프트입니다. AI가 못 하는 일이 있을 때 "그럼 내가 뭘 해주면 되냐"로 되묻는 습관을 들이세요.

환경변수 .env — 열쇠를 코드 밖에 숨기기

프로젝트 폴더 최상단(루트)에 .env(또는 .env.local) 파일을 만들고 KEY=VALUE 형태로 한 줄에 하나씩, 따옴표 없이 씁니다. 키 이름은 보통 대문자와 언더스코어입니다.

OPENAI_API_KEY=sk-proj-...
SUPABASE_URL=https://xxxx.supabase.co
SUPABASE_ANON_KEY=eyJhbGci...
DATABASE_URL=postgresql://user:pass@host:5432/db

.env
.env.local
.env.*.local

비개발자가 가장 헤매는 네 가지

1. 파일 이름이 점(.)으로 시작해 Mac/Windows에서 숨김 파일로 취급됩니다.
2. 반드시 프로젝트 루트 폴더에 있어야 합니다. 하위 폴더는 안 됩니다.
3. .env를 수정하면 개발 서버를 껐다 켜야 반영됩니다.
4. 배포할 때는 파일이 아니라 Vercel 대시보드에서 환경변수를 따로 입력해야 합니다.

OpenAI API 키를 받았는데 .env에 추가하고, .gitignore에도 넣어줘.
그리고 이 키를 src/api.js에서 사용하도록 수정해줘.

한줄 요약

1 — 지금 노트북에서 GitHub에 올리기 (push)

가장 쉬운 방법은 Claude Code에게 시키는 것입니다.

내 프로젝트를 GitHub에 새 repo로 올리고 싶어. 비개발자니까
git 초기화 → commit → GitHub repo 생성 → push 까지 전부 CLI로 진행해줘.
GitHub은 가입돼 있어. 로그인이 필요하면 내가 할 수 있게 알려줘.

cd 내프로젝트폴더
git init
git add .
git commit -m "first commit"
gh repo create my-project --private --source=. --push

git remote add origin https://github.com/내아이디/my-project.git
git branch -M main
git push -u origin main

2 — 집 컴퓨터에서 내려받기 (clone)

먼저 집 컴퓨터에도 Claude Code · git · Node.js를 설치하세요(부록 C의 설치 가이드). 그다음 터미널에 복사 → 붙여넣기 → Enter:

cd ~
git clone https://github.com/내아이디/my-project.git
cd my-project
npm install
claude

3 — 두 컴퓨터를 계속 동기화하는 습관

git pull

git add .
git commit -m "오늘 작업한 내용 메모"
git push

헷갈리면 Claude Code에게 "방금 작업한 거 commit하고 push해줘" / "GitHub에서 최신으로 pull해줘"라고 말하면 알아서 해줍니다.

디자인을 이쁘게 하고 싶다면

아래 사이트에서 마음에 드는 디자인을 찾아 "이렇게 만들고 싶어"라고 AI에게 보여주세요. 참고 대상이 있을 때와 없을 때의 결과 차이가 큽니다. (주소는 부록 C)

작업 속도를 올리는 것들

• 터미널 앱 — Mac은 Ghostty, Windows는 Wave Terminal을 권합니다(기본 터미널보다 쾌적합니다).
• Windows에서 스크린샷 붙여넣기 — Ctrl+V가 아니라 Alt+V입니다. Mac은 ⌘C → ⌘V 또는 드래그 앤 드롭이 그대로 됩니다.
• 타자가 느리다면 — 음성 입력 도구(Wispr Flow 등)를 쓰면 AI에게 시키는 속도 자체가 달라집니다.
• 세션 복습 — /insights 한국어로 작성해줘 로 그날 세션을 분석·정리받을 수 있습니다.

다음 단계 — 상시 가동 에이전트

Claude Code 같은 세션 단위 도구 다음에 오는 것이 상시 가동 에이전트입니다. 지금 당장 필요하진 않지만, 방향을 알고 있으면 좋습니다.

언제 무엇을 — 코드를 직접 짜는 작업, 내 옆에서 같이 일하는 페어 프로그래머가 필요할 때는 세션형. 자리를 비워도 일이 돌아가야 할 때(밤새 리서치, 24시간 모니터링), 여러 채널로 알림이 필요한 자동화, 매일 반복되는 업무에는 상시형.

업계는 "세션 단위 도구"에서 "상시 가동 페르소나"로 무게중심이 옮겨가는 중입니다. 에이전트가 충분히 똑똑해졌고, 컴퓨트 단가가 내려갔고, 사람이 노트북 앞에 24시간 있을 수 없기 때문입니다. "Claude Code로 만들고, 상시 에이전트로 운영한다"가 점점 표준이 되고 있습니다.

Harness — 에이전트에게 붙이는 장비

같은 모델이라도 뭘 붙이느냐에 따라 결과가 달라집니다. 네 가지만 구분하면 됩니다.

그리고 이 전부를 Claude Code 하나가 부립니다. 이미지가 필요하면 이미지 모델을 부르고, 일이 크면 자기 분신을 여러 개 띄웁니다. 내가 배울 건 창구 하나 다루는 법이지 도구 목록이 아닙니다.

오늘 배운 걸 스스로 정리해주는 학습 스킬도 있습니다. 구체적인 저장소 주소는 부록 C에 모아두었습니다.

다섯 가지

1. 건강관리. 아직 마라톤 초입부입니다. 잘 돼서 아프면 안 되고, 오래 해야 하니까요.
2. Unlearn, then learn. 배우는 것보다 지금까지의 방식을 내려놓는 것이 먼저입니다.
3. 앞으로가 중요합니다. 결국 자동화를 해내는 사람은 의지·집념·분노가 있는 사람입니다. 똑똑하게 게으르게 일하세요.
4. 왜 이걸 하는가. 잠재력을 여는 것. Unlock your full potential.
5. 제일 무서운 건 가속도입니다. 지금 속도가 아니라, 속도가 붙는 속도를 보세요.

결국 남는 문장 하나