1부. AI 코딩 에이전트와 첫 결과물 만들기

1장 바이브 코딩이란?

1.1 말로 요청하면 결과물이 나온다
1.2 바이브 코딩, 어디서 온 말인가?
1.3 코드 작성의 주체가 옮겨 간다
1.4 코딩을 몰라도 이미 만들고 있다
1.5 코드를 몰라도 확인할 수 있다

2장 Claude Desktop에서 시작해 CLI로 이어 가기

2.1 Claude Desktop의 [Code] 탭에서 시작하기
2.2 첫 작업 폴더 만들기
2.3 파일 하나 만들어 보기
2.4 같은 일을 터미널에서도 할 수 있다
2.5 Claude Code CLI 설치하기
2.6 같은 작업 폴더에서 CLI 열기
2.7 세션 안에서 쓰는 기본 조작
2.8 권한 모드를 auto로 맞추기
2.9 안될 때 먼저 확인할 것

3장 Claude Code 첫 실습

3.1 오늘의 재료는 회의 메모 한 장
3.2 Claude가 읽을 파일을 알려 주기
3.3 표를 만들기 전에 물어본다
3.4 할 일만 뽑아 todo.md 표로
3.5 할 일 표를 웹 화면으로 바꾸기
3.6 오늘 폴더에 남은 것

4장 첫 결과물 다듬기

4.1 고치기 전에 문제부터 찾기
4.2 문제와 원하는 모습을 함께 말하기
4.3 설명 대신 스크린샷 보여 주기
4.4 디자인은 시안으로 고른다
4.5 입력창을 비우고 Esc 두 번으로 수정 전으로 돌아가기

2부. 작은 도구를 제품처럼 키우기

5장 AI 투자 브리핑 비서 만들기

5.1 매일 아침, 흩어진 종목 뉴스
5.2 완성된 하루 - 미리 보기
5.3 “만들어 줘.”라는 한 줄로는 안 되는 이유
5.4 시스템 큰 그림 그리기
5.5 조립 순서 - 6~13장 로드맵

6장 SDD - 만들기 전에 설계하기

6.1 스케치만으로는 만들 수 없다
6.2 Claude가 나를 인터뷰하게 한다
6.3 만들지 않을 것부터 정한다 - 경계선과 결승선
6.4 인터뷰를 SPEC.md로 - 첫 번째 판
6.5 확정은 사람이 한다

7장 Git으로 작업 이력 남기기

7.1 왜 지금 Git인가?
7.2 저장소 만들기
7.3 커밋 - 되돌릴 수 있는 지점 만들기
7.4 변경 내용 - 무엇이 바뀌었는지 눈으로 본다
7.5 되돌리기
7.6 GitHub에 올리기
7.7 맥락 정리하기

8장 실행 계획 세우기 - 플랜 모드

8.1 왜 계획부터인가?
8.2 플랜 모드 - 실행하기 전에 계획을 세운다
8.3 스펙을 실행 순서로 쪼갠다
8.4 순서 정하기
8.5 계획을 확인하고 기록한다

9장 작업 시작하기

9.1 새 세션에서 시작하기
9.2 CLAUDE.md - AI에게 주는 프로젝트 규칙
9.3 템플릿으로 직접 쓴다
9.4 첫 조각 대시보드 프로토타입
9.5 확인하고 커밋

10장 Skills - 네이버 뉴스 API로 종목 뉴스 가져오기

10.1 Skill이란?
10.2 왜 화면을 긁지 않고 API인가?
10.3 API 키 발급과 시크릿 관리
10.4 수집 Skill 만들기
10.5 분석 - 발췌를 모아 리포트로
10.6 환각 주의 - 사람이 확인하는 지점
10.7 파이프라인에 연결

11장 데이터 파이프라인 확인하기

11.1 파이프라인 한 번 돌리기
11.2 산출물과 화면을 확인한다
11.3 사람이 먼저 검토한다
11.4 스케줄 걸기

12장 대시보드 배포하기

12.1 로컬에서 먼저 띄운다
12.2 환경이 왜 여러 개인가?
12.3 배포 전 보안 검사
12.4 Vercel로 배포
12.5 잘 올라갔는지 확인하기
12.6 끝났는지 확인 - 완료 기준 대조

13장 휴대폰 앱처럼 쓴다 - 설치·오프라인 업데이트 확인

13.1 앱처럼 쓴다는 말부터 작게 정한다
13.2 고치기 전에 프로젝트를 진단한다
13.3 완료 기준을 스펙에 보탠다
13.4 홈 화면에 설치할 이름표를 붙인다
13.5 실제 휴대폰에 설치한다
13.6 마지막 브리핑만 오프라인에 남긴다
13.7 오프라인이라는 사실을 화면에 드러낸다
13.8 지하철을 흉내 내 본다
13.9 새 배포가 설치 앱에도 들어오는지 확인한다
13.10 끝났는지 확인한다

3부. 믿고 쓰게 만들기 - 뒤죽박죽 업무 폴더 정리하고 일잘러 되기

14장 출근 첫날 받은 엉망진창 폴더, 일잘러의 첫 관문

14.1 출근 첫날, 엉망진창 폴더를 받았다
14.2 열어 보니 진짜 엉망이다
14.3 정리를 마치면 이 폴더는 이렇게 된다
14.4 여기까지 가는 길 - 15장부터 20장까지
14.5 2부와 무엇이 다른가?

15장 뭐가 있는지부터 파악한다 - 폴더 현황표(인벤토리)

15.1 문제: 뭐부터 봐야 할지 모르겠다
15.2 해결: /init으로 구조부터 뽑는다
15.3 한 걸음 더 - 정리할 목록을 뽑는다
15.4 막막함이 목록이 됐다

16장 버전 지옥을 정리한다 - 체계적 폴더링

16.1 시작 전에 스냅샷부터
16.2 첫 번째 처리 - 단가표 이름 정리
16.3 두 번째 처리 - CS 응대 매뉴얼은 벽에 부딪힌다
16.4 한 묶음 끝냈으면 커밋
16.5 오늘 하루, 무엇이 달라졌나?
16.6 다음에 이어서 - /resume으로 세션 되살리기

17장 찾을 수 있게 만든다 - LLM Wiki로 구조화

17.1 정리 전, 같은 질문을 던져 본다
17.2 위키라는 발상 - 왜 폴더가 아니라 위키인가?
17.3 원본은 그대로 두고 위키를 얹는다
17.4 대성물산 페이지를 만든다
17.5 이름 없는 스캔 파일의 정체
17.6 여기까지, 그리고 아직 안 담긴 것
17.7 보류했던 워드 파일을 읽는다 - 즉석 스크립트
17.8 아직 못 읽은 문서가 8개 - MCP로 도구를 연결한다
17.9 남은 8개를 한 번에 위키로
17.10 정리 후 같은 질문을 다시 던진다
17.11 무엇이 달라졌나?
17.12 CLAUDE.md를 위키의 스키마로
17.13 위키 입구 - README

18장 서로 안 맞는 문서를 바로잡는다 - 검증·대조

18.1 경고: 이 폴더를 그대로 믿으면 틀린다
18.2 업무를 몰라도 할 수 있는 것과 없는 것
18.3 원본을 대조해 문서상 최신 합의를 찾는다
18.4 다시 갱신할 땐 상태 태그를 붙인다
18.5 확정된 값으로 다른 문서도 훑는다
18.6 원본은 고치지 않는다 - git revert로 되돌리기
18.7 매뉴얼도 같은 원칙으로 확인한다
18.8 검증을 나만의 Skill로 만든다 - /test
18.9 10장의 Skill과 무엇이 다른가?
18.10 작업 중 다른 것이 궁금할 때 - /btw

19장 한눈에 보는 업무 지도 - 대시보드

19.1 오늘 만들 세 위젯
19.2 준비 - 데이터부터
19.3 위젯 1 - 카테고리 분포
19.4 위젯 2 - 문서 관계
19.5 위젯 3 - 타임라인
19.6 위젯이 깨졌을 때
19.7 화면도 검증 대상이다
19.8 세 위젯을 한 번에 확인 - 자동 테스트

20장 위키는 계속 채워진다 - 새 문서 편입과 주간 브리핑

20.1 금요일 오후 새 제안서가 도착했다
20.2 새 문서는 어디로 가야 하는지 이미 정해져 있다
20.3 월요일 아침, 한 줄 질문
20.4 이제 여러분의 폴더 차례
20.5 긴 정리엔 완료 기준을 걸어 둔다 - /goal