Part 1 정리

AI 답을 확인하는 기준

Part 1은 LLM이 정답을 찾는 기계가 아니라 그럴듯한 다음 단어를 예측하는 확률 시스템이라는 점에서 시작했습니다. 그래서 Claude Code를 잘 쓰는 방법은 AI를 더 믿는 법이 아니라, 근거를 주고 확인 기준을 세우는 법입니다.

• Hallucination·Knowledge Cutoff: 줄일 수는 있지만 없앨 수 없는 구조적 한계입니다. 학습 이후 정보나 근거 없는 세부사항은 그럴듯하게 지어낼 수 있습니다.
• Tool: LLM의 한계를 없애지는 않습니다. 대신 예측의 근거를 기억에서 실제 파일·검색 결과·명령 실행 결과로 옮깁니다.
• Agent = Tool + Loop + 자율적 판단: Tool 호출을 한 번 쓰고 끝내면 한 사이클이고, 결과를 보고 다음 행동과 멈출 시점을 스스로 정하며 반복하면 Agent입니다.
• Agentic 코딩: AI에게 탐색·수정·실행의 중간 단계를 맡기는 방식입니다. 개발자는 목표·제약·검증 기준을 잡고, 결과가 맞는지 확인합니다.
• Claude Code: Terminal-native Agent입니다. 터미널에서 작업 루프를 이어 가고, 동작 방식 자체를 프로젝트 안의 파일과 도구로 설계할 수 있습니다.

Claude Code 입문 흐름

Claude Code 입문은 설치·로그인에서 시작해 첫 개발 흐름, 세션 관리, 권한 모드로 이어졌습니다. 세부 명령을 모두 외우는 것보다, 작업이 어떤 순서로 진행되는지 잡는 것이 먼저입니다.

설치·요금제·모델 선택

설치와 로그인 뒤에는 요금제 한도와 작업 난이도에 맞춰 모델을 고릅니다.

• 첫 실행: Claude Code를 설치하고 로그인하면 터미널에서 바로 첫 세션을 열 수 있습니다.
• 요금제와 한도: Pro·Max·Team의 사용량 한도에 따라 고를 모델이 달라집니다. 자주 오래 쓴다면 한도를 기준으로 기본 모델을 정합니다.
• 모델 선택: Opus는 설계와 큰 판단, Sonnet은 구현과 일상 작업, Haiku는 단순 질문과 빠른 확인에 맞춰 씁니다.

첫 개발 흐름과 실수 복구

첫 개발 흐름은 읽고, 이해하고, 고치고, 되돌리고, 저장하는 순서였습니다.

• 읽기 → 이해 → 수정 → 복구 → 저장: 첫 대화는 개발자가 평소 일하는 순서 그대로 진행했습니다. 자연어 한 줄로 각 단계를 진행할 수 있지만, 무엇을 바꿀지와 결과가 맞는지는 사람이 판단합니다.
• 특수 입력: @ 는 파일을 Context에 올리고, ! 는 빠르게 셸 명령을 확인하며, / 는 Claude Code 명령을 실행합니다.
• 되돌리기: Esc+Esc 와 Checkpoint로 원하는 지점의 파일 변경을 되돌립니다. 셸 명령으로 생긴 변경은 Checkpoint로 되돌릴 수 없습니다. 커밋된 이력은 Git으로 관리합니다.

세션 관리와 권한 모드

세션은 다시 열고, 권한은 필요한 만큼만 자동화합니다.

• 세션 다시 열기: claude --continue 는 마지막 세션을 바로 열고, claude --resume 은 목록에서 골라 엽니다.
• 권한 프롬프트: 쓰기·셸 실행은 승인 흐름을 거칩니다. Yes, don't ask again 은 반복 작업을 줄이지만, 허용 범위를 신중하게 골라야 합니다.
• default: 읽기 작업은 바로 진행하고, 쓰기·셸 실행은 확인을 요청합니다.
• acceptEdits: 파일 편집은 자동으로 허용하고, 셸 실행은 계속 확인합니다.
• plan: 소스 수정 전에 프로젝트를 읽고 계획을 세우는 데 집중합니다.
• auto: 권한 판단을 분류기에 맡겨 안전해 보이는 작업은 자동으로 넘기고, 위험한 작업은 확인을 요청합니다. 긴 작업의 흐름을 덜 끊으면서도 모든 권한을 여는 --dangerously-skip-permissions 보다 안전해서 먼저 고려합니다.

Context를 필요한 만큼만 남기기

Context Window는 한 번의 답변을 만들 때 Claude가 보는 작업 범위입니다. 많이 넣는 것보다 지금 작업과 직접 관련된 정보만 남기는 것이 더 중요합니다.

Context Window와 모듈형 프롬프트

Context 관리는 작업 범위와 정보 배치를 함께 다룹니다.

• Context Rot: 중간 정보를 놓치는 위치 편향과 지침이 많아질수록 떨어지는 준수율 때문에 답이 어긋납니다. 문제는 양만이 아니라 구조입니다.
• 모듈형 프롬프트: 전체 자료를 한 번에 넣기보다 지금 작업에 필요한 Context만 남깁니다. Claude Code에서는 Rules·Skills·Sub-agents·CLAUDE.md가 이 역할을 나눠 맡습니다.

세션 사이에 남길 정보

세션 사이에 남길 정보는 누가 쓰는지, 누구와 나누는지에 따라 어디에 둘지가 달라집니다. 팀과 공유할 규칙은 CLAUDE.md에, 이 프로젝트에서만 반복되는 요청과 작업 방식은 Memory에 둡니다.

• CLAUDE.md: 팀이 합의해 써두는 업무 매뉴얼입니다. 코드에서 찾을 수 없는 아키텍처 결정 이유·팀 워크플로우·제약만 남기고, 200줄을 넘기지 않는 편이 좋습니다.
• Memory: Claude가 이어받는 반복 요청과 작업 방식입니다. 프로젝트별 로컬 파일에 저장되며 팀과 공유되지 않습니다.
• 자리 고르기: 팀과 공유하면 프로젝트 CLAUDE.md, 모든 프로젝트에 적용하면 ~/.claude/CLAUDE.md, 이 프로젝트에서만 반복되면 Memory에 둡니다.

새로 시작과 이어가기

문제는 대화 길이 자체보다 누적된 노이즈입니다. 실패한 가설과 어긋난 흐름이 남으면 다음 답변도 그 방향에 끌려갑니다.

• 새로 시작할 시점: 설명을 덧붙일수록 Claude가 핵심 의도에서 멀어지거나, 다음 작업의 목표·제약·검증 기준이 달라지면 새로 시작합니다.
• 이어가도 되는 흐름: 같은 목표 안의 탐색·계획·구현·테스트는 이어가도 됩니다.
• 방법 고르기: 새로 시작할 때는 /clear 나 새 세션을 쓰고, 같은 긴 작업을 이어갈 때는 /compact 를 씁니다.

요구사항에서 검증까지 이어가기

Part 1 마지막 챕터는 Todo 앱을 요구사항부터 검증까지 한 바퀴 만드는 실습이었습니다. 핵심은 AI가 대신 결정할 자리를 줄이고, 마지막에는 실제 동작 확인으로 마무리하는 것입니다.

세 가지 공백 줄이기

요구사항, 기술 스택, 프로젝트 구조에서 생기는 공백을 줄이면 AI의 추측도 줄어듭니다.

• 요구사항의 공백: 기능 목록은 "사용자가 ~하면, ~한다" 형식으로, 범위 제한은 "무엇을 만들지 않는가"로 적습니다.
• 기술의 공백: 학습 데이터가 충분한 기술과 프로젝트 안에 소스가 있는 라이브러리를 고르면 AI가 추측할 자리가 줄어듭니다.
• 프로젝트 구조의 공백: 요구사항과 기술 스택이 있어도 현재 프로젝트의 파일 구조는 읽어야 압니다. Plan Mode로 먼저 탐색하게 만듭니다.

Plan Mode: 탐색 → 계획 → 실행 사이클

Plan Mode는 먼저 읽고, 계획을 확인한 뒤, 승인 후 실행으로 넘어갑니다.

• 승인 전 탐색: Plan Mode에서는 승인 전 소스 수정이 막힙니다. Claude는 Read·Grep·Glob·LS와 탐색용 명령으로 구조를 먼저 읽습니다.
• 미해결 질문: 탐색 중 나오는 질문은 요구사항의 빈틈을 드러냅니다. 답을 채우면 실행 단계에서 같은 자리에 다시 멈추지 않습니다.
• 맥락 유지: 계획을 승인하면 탐색에서 파악한 코드 위치와 결정 근거가 실행 단계로 이어집니다.

완료를 검증으로 닫기

요구사항·Plan Mode·구현을 거쳐 Todo 앱 한 바퀴를 완주한 뒤, 마지막으로 브라우저 체크리스트를 확인했습니다. AI가 "완료"라고 말해도 실제 동작 확인은 사람의 몫입니다.

• 요구사항 → 검증 사이클: CLAUDE.md와 요구사항을 준비하고, Plan Mode로 계획을 검토하고, 구현 뒤 브라우저에서 확인했습니다.
• 완료 메시지 ≠ 동작 보장: 작성은 AI가 맡아도, 결과가 맞는지는 실행해 봐야 압니다.
• 반복 검증 비용: 기능이 늘수록 체크리스트도 길어지고, 기능 하나를 추가할 때마다 같은 항목을 다시 확인해야 합니다.

이어서 배울 내용

Part 2는 수동 체크리스트를 테스트와 성공 기준으로 바꾸는 데서 시작합니다. 개발자는 단계를 하나하나 지시하는 대신 어떤 상태가 성공인지 정하고, AI는 테스트 결과를 보며 방법을 바꿔 갑니다.

• What vs How: 방법 지시에서 성공 기준으로 옮기기
• 테스트 기반 검증: 수동 체크리스트를 코드로 바꾸기
• Red Green Refactor: 성공 기준 목록에서 하나씩 테스트로 검증하며 구현
• Task 시스템: 대화가 끊겨도 작업 상태 이어가기