Part 1 정리

LLM은 빈칸을 추측으로 메우는 확률 기계

Part 1은 "AI가 왜 자신있게 틀리는가"에서 시작했습니다. LLM은 "맞는 답"이 아니라 그럴듯한 다음 단어를 예측할 뿐이고, 비어 있는 자리는 확률로 메웁니다. 이 원리가 Part 1 전체를 관통합니다.

• Hallucination·Knowledge Cutoff는 구조적 한계: 줄일 수는 있어도 없앨 수 없습니다. 정답과 오답이 똑같은 자신감으로 나옵니다
• Tool은 한계를 지우지 않고 우회: 예측의 근거를 머릿속 기억에서 실제 파일·검색 결과로 바꿔줄 뿐, 확률로 답을 만드는 본질은 그대로입니다
• Agent (Tool + Loop + 자율 판단): 한 번 쓰고 끝나면 LLM + Tool, 결과를 보고 다음 행동을 스스로 정하며 반복하면 Agent입니다. 능력 차이가 아니라 실행 구조의 차이입니다
• Claude Code (Agentic 코딩 + Terminal-native + 프로그래밍 가능): 어디서든 실행되고 동작 방식 자체를 CLAUDE.md·Hooks·Skills·Subagent·MCP 로 설계합니다. 프로그래밍 가능 영역은 Part 2에서 본격적으로 다룹니다

Claude Code의 기본 감각

Agent를 매일 쓰려면 도구의 감각이 먼저 몸에 익어야 합니다. 인터페이스 네 축과 모델 분업이 그 출발점입니다.

• 세션: claude --continue·--resume 으로 이어받고, 길어지면 /clear 로 비웁니다. /compact 는 요약 과정에서 뉘앙스가 사라져 예외 도구로만 씁니다
• 특수 입력 (! @ /): 입력창 첫 문자가 모드 스위치입니다. ! 는 쉘 명령, @ 는 파일 첨부, / 는 슬래시 명령. 긴 입력은 Ctrl+J, 이미지는 Ctrl+V
• 권한 4모드: Shift+Tab 으로 default·acceptEdits·plan·auto 를 순환합니다. auto 는 분류기가 매 행동을 사전 검토하고, --dangerously-skip-permissions 는 그마저 끄는 마지막 수단입니다
• 되돌리기: Esc+Esc (또는 /rewind)로 마지막 AI 행동을, Checkpoint로 여러 단계 전 상태까지 한 번에 이동합니다
• 모델 분업: 설계는 Opus, 구현은 Sonnet, 단순 작업은 Haiku. 같은 세션에서 /model 로 바꿔도 Context는 그대로 이어집니다

Context Window: 작은 책상의 한계

Claude의 작업 책상은 좁습니다. 같은 모델·같은 지시여도 책상이 어떻게 채워져 있느냐에 따라 결과가 갈립니다.

책상의 두 함정

• 위치 편향 (Smart Zone·Dumb Zone): Context 초반·후반부에서 주의력이 가장 높고, 중간 구간 정보를 놓치는 Lost in the Middle 경향이 강합니다
• 지침의 저주: 지침이 많아질수록 개별 지침의 준수율이 떨어집니다. 해법은 더 자세히 쓰는 것이 아니라 지금 작업에 필요한 것만 주는 것입니다

영구 지식: CLAUDE.md와 Memory

• CLAUDE.md (내가 쓰는 팀 매뉴얼): 매 세션 자동 로드. 모델이 코드에서 찾을 수 없는 결정·워크플로우·제약만 300줄 미만으로 남깁니다
• Memory (Claude가 쓰는 관찰 노트): 대화 중 감지한 개인 선호를 자동 저장해 다음 세션에 불러옵니다. 로컬 전용이라 팀과 공유되지 않고, 충돌 시 CLAUDE.md가 이깁니다

Task Sizing: 새 대화를 여는 세 신호

토큰 한계는 자동 압축이 알아서 처리하지만, 긴 대화에 쌓이는 노이즈는 다음 답변의 질을 떨어뜨립니다. 다음 신호가 보이면 /clear 로 끊는 편이 안전합니다.

• 무관 작업 전환: 디버깅 직후 새 기능 구현처럼, 이전 작업의 톤이 다음 작업을 어긋나게 할 때
• 두 번 빗나가는 수정: 빗나간 답변이 다음 답변의 본보기로 작용합니다. 세 번째 시도는 같은 프롬프트를 새 대화에 그대로 붙이는 편이 풀릴 확률이 높습니다
• 작업 완결 (예방 신호): 한 기능을 마무리한 자리에서 미리 끊으면 위 두 신호가 나타나기 전에 차단됩니다

계획이 먼저, 코드는 그 다음

Part 1의 마지막 장은 "빈 폴더에 대고 바로 코드를 시키면 왜 실패하나"에서 시작했습니다. 답은 첫 테마로 돌아옵니다. AI는 빈칸을 추측으로 메우고, 개발자도 자신이 원하는 걸 처음부터 정확히 모릅니다.

• Plan Mode (쓰기 잠금으로 탐색 강제): Shift+Tab 두 번으로 진입하면 Edit·Write·Bash가 차단되고 읽기 도구만 열립니다. AI의 역질문이 가장 큰 가치이고, 탐색에서 쌓인 맥락이 실행 단계까지 그대로 따라갑니다
• 요구사항의 공백: 기능 목록은 "사용자가 ~하면, ~한다" 형식으로, 범위 제한은 "무엇을 만들지 않는가"로 적습니다. AI가 추측으로 채울 자리를 미리 닫는 장치입니다
• AI 친화 스택: 학습 데이터가 두터운 Next.js와 컴포넌트 소스가 프로젝트 안에 있는 Shadcn은 AI의 빈칸을 줄입니다

검증이 남긴 질문

요구사항·계획·구현을 거쳐 Todo 앱 한 바퀴를 완주한 뒤, 마지막은 다섯 시나리오를 브라우저에서 직접 클릭하는 일이었습니다. 작성은 AI가 가져갔지만, 검증은 여전히 사람의 몫입니다. 기능이 늘수록 한 기능을 추가할 때마다 같은 체크리스트를 처음부터 다시 돌려야 합니다.

이 체크리스트를 코드로 바꿀 수 있다면 어떨까요? AI가 스스로 "통과/실패"를 판단하며 자율적으로 루프를 돌 수 있지 않을까요?

이어서 배울 내용

Part 2는 이 질문에서 시작합니다. 체크리스트를 테스트 코드로 변환하면 AI가 스스로 성공 기준을 읽으며 Loop를 돌고, 개발자는 단계를 하나하나 지시하는 대신 성공 기준만 주고 방법은 AI에게 맡기게 됩니다.

• What vs How: AI에게 일을 시키는 두 가지 방법
• 테스트 기반 검증: 수동 체크리스트의 자동화
• Red Green Refactor: 성공 기준을 테스트로 변환하고 한 번에 하나씩 구현
• Task 시스템: 대화가 끊겨도 이어가는 작업 진행