처음에는 진짜 일이 줄어든 줄 알았다

솔직히 말하면, 나도 처음에는 AI가 일을 대신해주는 줄 알았다.

자료를 던지면 요약이 나온다. 긴 글을 붙여 넣으면 핵심만 뽑아준다. "이번 주 사업 상태를 판단할 수 있게 정리해줘"라고 말하면 꽤 그럴듯한 문장이 나온다. 빈 화면 앞에서 혼자 끙끙대던 시간에 비하면 거의 반칙처럼 느껴진다.

처음 며칠은 정말 편하다. "이번 주 매출 정리해줘." "문의 내용에서 반복되는 주제 뽑아줘." "이 내용을 내가 바로 판단할 수 있게 정리해줘." 이 정도는 AI가 금방 해낸다. 결과도 나쁘지 않다. 표도 만들고, 제목도 붙이고, 요약도 제법 깔끔하다.

이쯤 되면 속으로 이런 생각이 든다.

"이제 이런 일은 AI한테 맡기면 되겠네."

딱 거기까지가 좋았다.

그 "맡기면 되겠네"가 모든 피로의 시작이었다.

문제는 프로젝트가 반복되기 시작한 뒤에 생긴다

비즈니스 대시보드를 하나 운영한다고 해보자.

대단한 개발 프로젝트가 아니다. 매주 매출, 신규 고객, 문의 내용을 확인하고 내 비즈니스 상태를 판단할 수 있게 정리하는 일이다. 작은 회사든, 1인 사업이든, 콘텐츠 비즈니스든 이런 일은 계속 생긴다.

처음에는 쉽다. "이번 주 매출 요약해줘." AI가 요약한다. "신규 고객 변화도 같이 봐줘." AI가 표를 만든다. "내가 이번 주 판단을 바로 할 수 있게 세 줄로 줄여줘." AI가 문장을 다듬는다.

문제는 그 다음 주부터다.

지난주에는 신규 고객을 "첫 결제한 사람"으로 봤는데, 이번 주 요약에서는 무료 자료를 다운로드한 사람까지 신규 고객에 섞여 있다. 매출 요약에는 환불된 주문이 빠져 있는데, 아래 표에는 환불 전 금액이 그대로 남아 있다.

문의 수를 세어달라고 했더니 어떤 주에는 광고 제휴 제안까지 포함하고, 어떤 주에는 고객 문의만 센다.

숫자가 크게 틀린 것도 아니다. 그래서 더 까다롭다. 완전히 엉망이면 바로 알아차린다. 하지만 그럴듯하게 조금씩 어긋난 결과는 한참 읽고 나서야 보인다. 문장은 매끄럽고 표도 깔끔한데, 기준이 흔들려 있다.

그때부터 일이 바뀐다.

AI가 만든 결과를 읽는 게 아니라, AI가 어디서 추측했는지 찾아야 한다. 신규 고객 기준을 다시 확인한다. 매출에서 환불을 뺐는지 다시 본다.

문의 수에 어떤 항목이 들어갔는지 다시 세어본다. 사업 판단용 요약이라고 했는데 정말 지금 결정에 도움이 되는 문장인지 다시 고친다.

처음에는 AI가 일을 줄여준다고 생각했다. 그런데 어느 순간부터 AI가 만든 결과를 내가 검수하고, 고치고, 다시 설명하고 있다.

이때 머릿속에 한 가지 질문이 자리 잡는다.

"AI에게 맡겼는데, 왜 내가 더 바빠졌지?"

AI 피로는 AI가 느려서 생기지 않는다

AI 피로는 AI가 느려서 생기지 않는다.

오히려 AI는 빠르다. 너무 빠르게 초안을 만들고, 너무 빠르게 표를 만들고, 너무 빠르게 결론을 낸다. 피로는 그 다음에 생긴다. AI가 어떤 기준으로 결과를 만들었는지 사람이 다시 확인해야 할 때 생긴다.

지난번에 말한 기준을 다시 설명해야 할 때도 피로가 생긴다. 좋아 보이는 결과를 받았지만 맞는지 믿을 수 없을 때도 생긴다. 같은 요청을 매주 반복하면서도 매번 조금씩 다른 결과를 받을 때도 생긴다.

AI 피로는 일을 맡겨서 생기는 것이 아니다.
기준 없이 맡긴 일을 사람이 매번 수습할 때 생긴다.

많은 사람이 이 지점에서 프롬프트를 고친다. 더 자세히 말한다. 예시를 붙인다. 금지사항을 적는다. 물론 프롬프트는 중요하다. 모호하게 말하면 결과도 흔들린다. 하지만 같은 설명을 세 번째 반복하는 순간, 문제는 프롬프트 길이가 아니다.

문제는 기준이 대화 속에만 있다는 것이다.

대화 속 기준은 쉽게 사라진다. 새 세션을 열면 다시 설명해야 한다. 다른 자료를 붙이면 우선순위가 흔들린다. AI가 이전에 무엇을 기준으로 삼았는지 사람도 추적하기 어렵다.

반대로 프로젝트 안에 남은 기준은 다시 불러올 수 있다. 프로젝트 안에 "신규 고객은 첫 결제한 사람만 뜻한다"는 기준이 남아 있다면 AI는 다음에도 그 기준을 볼 수 있다.

어떤 매출 파일을 공식 자료로 볼지 남아 있다면 AI는 아무 CSV나 믿지 않아도 된다. 이 프로젝트에서 먼저 확인할 기준과 행동 원칙이 남아 있다면 새 세션에서도 출발점이 생긴다.

중요한 차이는 여기에 있다.

AI에게 한 번 잘 말하는 것과, AI가 다음에도 다시 볼 수 있게 남기는 것은 다르다.

이 책은 Claude Code를 이렇게 쓴다

Claude Code라는 이름 때문에 이 도구가 개발자만의 도구처럼 느껴질 수 있다. 물론 Claude Code는 코드를 다룰 수 있다. 하지만 이 책에서 중요한 것은 코드 작성 능력이 아니다.

중요한 것은 Claude Code가 프로젝트 폴더를 읽고, 필요한 파일을 확인하고, 작업 결과를 다시 파일로 남길 수 있다는 점이다.

비개발자에게도 프로젝트는 있다. 강의 기획 프로젝트가 있다. 리서치 프로젝트가 있다. 마케팅 캠페인 프로젝트가 있다. 채용 공고를 만들고 지원자를 검토하는 프로젝트가 있다. 비즈니스 대시보드와 주간 리포트를 운영하는 프로젝트도 있다.

이런 일들은 대부분 기준과 반복으로 이루어져 있다. 어떤 자료를 공식으로 볼지 정해야 한다. 어떤 톤으로 써야 하는지 정해야 한다.

어떤 순서로 검토해야 하는지 정해야 한다. 결과가 맞는지 확인해야 한다. 다음 작업에서도 이어볼 수 있게 남겨야 한다.

Claude Code는 이런 기준과 반복을 파일과 폴더로 다루게 해준다.

폴더는 개발자의 장식이 아니다. AI에게 "이건 근거 자료", "이건 작업 기준", "이건 검증 기준", "이건 다음 작업의 출발점"이라고 알려주는 경계다.

경계가 없으면 AI는 모든 자료를 같은 무게로 본다. 경계가 있으면 AI는 어디서 근거를 찾고, 어디에 결과를 남기고, 무엇을 기준으로 확인해야 하는지 배울 수 있다.

물론 이 책에서 다루는 원리가 Claude Code에만 갇히는 것은 아니다. 프로젝트 안에 기준을 남기고, 반복 작업을 분리하고, 결과를 검증하고, 다음 작업으로 이어지게 만드는 사고방식은 Codex든 Gemini든 다른 AI 도구에서도 그대로 필요하다.

다만 이 책에서는 설명과 예제를 Claude Code로 통일한다.

도구를 여러 개 섞으면 독자는 원리보다 버튼 위치를 따라가게 되기 때문이다.

이 책에서 만들 것은 자동화가 아니다

이 책은 처음부터 거창한 자동화를 만들지 않는다. 복잡한 에이전트 시스템을 만들지도 않는다. Claude Code의 기능 목록을 순서대로 설명하지도 않는다.

대신 하나의 질문을 끝까지 붙잡는다.

AI가 다음에도 같은 기준으로 일하려면
무엇이 프로젝트 안에 남아 있어야 할까?

이 질문에 답하기 위해 이 책은 하네스를 다룬다. 여기서 하네스란 AI가 안정적으로 일할 수 있게 만드는 작업 환경이다. 하지만 이 책은 하네스를 개념으로만 설명하지 않는다. 구성 요소의 이름을 외우게 하고 끝내지 않는다.

이 책은 하네스를 레이어로 쌓아간다.

Layer 0. 피로
→ Layer 1. 진실의 원천
→ Layer 2. 작업 능력
→ Layer 3. 실행 전 합의
→ Layer 4. 검증
→ Layer 5. 강제와 보호
→ Layer 6. 누적과 이전

처음부터 모든 층을 만들 필요는 없다. 지금 내 프로젝트에서 가장 자주 흔들리는 층부터 만들면 된다.

기준이 없어서 매번 설명한다면 Layer 1부터 시작한다. 같은 요청을 계속 붙여넣고 있다면 Layer 2가 필요하다. 시키고 나서 "아닌데"를 반복한다면 Layer 3을 봐야 한다.

결과를 믿지 못해 사람이 전부 다시 확인한다면 Layer 4가 비어 있는 것이다. 중요한 규칙을 AI가 자꾸 어긴다면 Layer 5가 필요하다. 새 세션을 열 때마다 처음부터 설명한다면 Layer 6이 필요하다.

하나의 프로젝트로 끝까지 따라간다

이 책은 설명만으로 밀어붙이지 않는다. 책 전체에서 하나의 예제를 계속 따라간다.

비즈니스 대시보드 프로젝트다.

매주 내 비즈니스 상태를 확인하기 위한 대시보드와 주간 요약을 만든다고 가정한다. 처음부터 완성된 구조를 보여주지는 않을 것이다. 그렇게 하면 또 다른 정답 폴더 예시처럼 보이기 쉽다.

대신 장이 진행될수록 이 프로젝트가 조금씩 자란다. 처음에는 AI가 왜 같은 숫자를 다르게 해석하는지 본다. 그다음에는 어떤 자료를 공식 기준으로 볼지 정한다.

반복되는 주간 검토는 나중에 하나의 작업 능력으로 분리한다. 결과를 믿기 어려운 지점에서는 검증 기준을 만든다. 새 세션을 열 때마다 다시 설명하는 일이 반복되면, 다음 작업에서 이어볼 기록을 남긴다.

중요한 것은 완성된 폴더 구조가 아니다.

어떤 피로가 생겼을 때, 무엇을 프로젝트 안에 남겨야 하는지 배우는 것이다.

AI 네이티브로 가는 길

이 책은 대단한 프롬프트 모음을 제공하지 않는다. 대신 독자가 자기 프로젝트에 남길 수 있는 것들을 다룬다.

기준 파일. 프로젝트 지도. 작업 skill. 검증 체크리스트. 자동 보호 장치. 다음 세션을 위한 handoff.

이것들은 화려하지 않다. 하지만 반복되는 일을 줄인다. AI에게 다시 설명하는 시간을 줄인다. 결과를 처음부터 다시 검수하는 피로를 줄인다. 무엇보다 AI와 일한 흔적이 다음 작업의 출발점으로 남게 한다.

이 책의 목표는 독자를 "프롬프트를 잘 쓰는 사람"으로 만드는 것이 아니다.

AI가 보고, 실행하고, 확인하고, 다음 작업으로 이어갈 수 있는 층을 쌓는 사람으로 만드는 것이다.

그것이 이 책에서 말하는 AI 네이티브다.

먼저 하나만 바꾸면 된다.

지금 AI에게 가장 자주 다시 설명하는 기준 하나를 고르면 된다.

예를 들어 비즈니스 대시보드 프로젝트라면 이렇게 시작할 수 있다.

내가 매주 보는 비즈니스 대시보드 프로젝트를 기준으로,
AI가 다시 확인해야 할 지표 정의를 정리하려고 합니다.

먼저 내가 자주 쓰는 지표 이름을 물어보고,
각 지표마다 정의가 필요한 이유를 설명한 뒤,
지표 정의를 담을 기준 파일 초안을 만들어주세요.

이 요청은 거창하지 않다. 하지만 이 요청으로 대화 속에 흩어져 있던 기준 하나가 프로젝트 파일로 이동한다.

이 책은 그 작은 이동을 반복한다.

대화에서 파일로.
감각에서 기준으로.
요청에서 skill로.
검수에서 검증으로.

마지막에는 한 번의 대화가 아니라, 계속 이어지는 작업 환경이 남아야 한다.

여기서 두 사람이 갈린다.

매번 AI가 만든 결과를 다시 확인하는 사람으로 남을 것인가. 아니면 AI가 다시 볼 기준과 작업 환경을 남기는 사람으로 넘어갈 것인가.

준비됐다면, Layer 0부터 시작하자.