같은 일을 AI에게 매번 처음부터 설명하는 사람은 시간을 두 번 쓴다. 설명하는 데 한 번 쓴다. 빠뜨린 설명 때문에 틀어진 결과를 고치는 데 한 번 더 쓴다. Claude Code(클로드 코드) 사용자라면 이 반복이 낯설지 않을 것이다.
Claude Code를 만든 Boris Cherny가 최근 X에 짧은 글을 올렸다. 일 잘하는 엔지니어들은 예전부터 자기 일이 저절로 처리되게 만드는 데 시간을 썼다는 얘기였다. vim이나 emacs의 매크로(반복 입력을 한 번에 실행하는 기능)를 짜는 식이다. lint 규칙(코드 실수를 자동으로 잡는 검사)을 만드는 일도 같다. 테스트 스위트(동작을 한꺼번에 확인하는 검사 모음)를 쌓는 일도 같다. 언뜻 뻔한 회고처럼 들렸지만 그는 이 습관이 지금 AI 시대에 훨씬 더 중요해졌다고 덧붙였다.
30초 요약
- 뺀 일: 같은 일을 AI에게 매번 처음부터 설명하는 일.
- 남긴 일: 반복되는 일을 찾아 규칙으로 한 번 적는 일. 실수가 나오면 그 규칙을 고치는 일.
- 되찾은 시간: 미측정. 참고로 2월의 리팩토링 한 건은 3시간짜리가 40분에 끝났다.
- 든 비용: 미측정. 규칙을 처음 적는 데 품이 든다. 그 뒤로는 같은 설명을 다시 하지 않는다.
Claude Code 개발자는 프롬프트보다 어떤 습관을 꼽았을까?
Cherny가 꼽은 습관은 반복되는 일을 규칙과 문서로 남겨 AI가 스스로 참고하게 만드는 것이다. 보통 AI를 잘 쓴다는 말은 좋은 질문을 잘 짠다는 뜻으로 쓰인다. 그 질문이 프롬프트, 곧 AI에게 보내는 지시문이다. 하지만 Cherny가 말하는 실제 차이는 질문을 짜는 솜씨에 있지 않다.
프롬프트 엔지니어링이라는 말이 한동안 유행했다. 질문을 어떻게 던지느냐에 따라 답변의 질이 갈린다는 논리였다. 어느 정도는 맞는 말이다. 그런데 Cherny의 글은 이 통념을 다른 각도에서 본다. 그가 든 예시는 습관이었다. “예전부터 최고의 엔지니어들은 자기 일을 자동으로 처리되게 만드는 데 시간을 썼다.”
혼자 일할 때는 습관 하나가 그 사람 한 명의 속도만 바꿨다. 지금은 Claude를 여러 개 동시에 돌리는 사람이 흔하다. 그래서 규칙 하나를 만들면 돌아가는 에이전트 전부가 같이 빨라진다. 에이전트는 스스로 파일을 읽고 고치며 일하는 AI다. 적은 노력으로 큰 결과를 내는 레버리지가 그만큼 커진 셈이다.
물론 좋은 프롬프트가 쓸모없다는 말은 아니다. 다만 반복되는 일은 시스템으로 옮기는 쪽이 훨씬 남는 장사다.
같은 일을 매번 설명하면 왜 손해일까?
매번 설명하면 매번 비용이 들고 어느 순간 빠뜨린다. 그래서 한 번 규칙으로 만들어 두면 그 일은 다음부터 계속 자동으로 처리된다.
패스트푸드 프랜차이즈가 전국 어디서나 같은 맛을 내는 건 요리사가 특별히 뛰어나서가 아니다. 조리법이 매뉴얼로 박혀 있기 때문이다. 매장마다 직원이 달라도 매뉴얼이 있으면 같은 결과가 나온다. AI에게 매번 “이거 해줘, 저건 이렇게 해줘”라고 설명하는 일은 매뉴얼 없는 매장과 같다. 매장을 열 때마다 요리사에게 레시피를 처음부터 불러 주는 셈이다.
반대로 규칙을 한 번 적어 두면 그 규칙은 이번 대화가 끝나도 사라지지 않는다. 다음에도, 그다음에도 똑같이 적용된다. 아래 표가 두 방식의 차이다.
| 방식 | 매번 설명하기 | 규칙으로 남기기 |
|---|---|---|
| 비용 | 대화할 때마다 다시 지불 | 처음 한 번만 지불 |
| 누락 위험 | 바쁘면 빠뜨리기 쉽다 | 문서에 있어 놓치지 않는다 |
| 효과 범위 | 이번 대화 한 번 | 다음 모든 대화, 모든 에이전트 |
Claude Code 팀은 실수가 나올 때마다 규칙 문서를 고친다
Cherny는 이 차이를 직접 실천한다. Claude 활용법을 정리한 howborisusesclaudecode.com에 따르면 그는 이렇게 말한다. “Claude가 실수할 때마다 나는 다르게 하라고 말하지 않는다. 그 대신 CLAUDE.md에 적거나, 스킬로 만든다.”
스킬은 자주 하는 작업 절차를 이름 붙여 저장해 두는 기능이다. CLAUDE.md는 Claude Code가 작업을 시작할 때마다 자동으로 읽는 규칙 문서다. Claude Code 팀 전체가 이 문서를 공유한다. 팀원 누구나 한 주에 여러 번 고쳐 쓴다.
Cherny의 결론은 이렇다. Claude가 내 규칙을 몰라서 실수했다면 그건 AI 탓이 아니라 규칙을 적어 두지 않은 내 탓이다. 그래서 팀이든 개인이든 AI가 읽을 ‘나만의 설명서’가 있어야 한다.
이 얘기는 코드에만 해당하지 않는다. 어떤 문의는 이렇게 답하고 어떤 보고서는 이 순서로 정리한다는 머릿속 노하우도 같은 방식으로 남길 수 있다. aboutcorelab도 비슷하게 움직인다. AI 에이전트가 같은 실수를 반복하지 않도록 작업이 실패한 이유와 글쓰기 규칙을 메모리 파일로 남긴다. 다음 작업을 시작할 때는 그 메모리부터 읽고 시작한다.
규칙이 문서로 남으면 비전공자도 전문가에 가까운 결과를 낸다
이케아 가구는 목수가 아니어도 조립 설명서만 있으면 조립할 수 있다. Cherny가 말하는 구조도 비슷하다. 걸림돌은 대개 그 실력이 누군가의 머릿속에만 있고 밖으로 나와 있지 않다는 점이다. 그래서 노하우가 문서로 나오면 그걸 실행하는 데 필요한 전문성의 문턱이 낮아진다.
이 효과를 보여 주는 사례가 있다. Anthropic이 연 Claude Code 해커톤의 우승자는 전기공, 의사, 목수였다. 전문 엔지니어는 아니었다. Cherny는 이를 두고 “Claude Code에서 가장 많은 가치를 얻어가는 사람들은 내가 예상한 사람들이 아니다”라고 말했다(Platformer). 규칙과 문서가 갖춰지면 진입장벽이 낮아진다는 뜻이다.
Claude Code 에이전트가 엉뚱한 파일을 고치던 일을 세 가지 규칙으로 막았다
2월에 3시간짜리 리팩토링을 40분 만에 끝낸 적이 있다. 리팩토링은 동작은 그대로 두고 코드 구조를 고치는 일이다. Claude Code에 “이 레거시 코드 타입스크립트로 마이그레이션해줘”라고 했더니 실제로 해냈다. 레거시 코드는 오래된 코드다. 마이그레이션은 이를 다른 방식으로 옮기는 일이다.
100% 완벽하지는 않았다. 타입 추론이 틀린 부분은 직접 고쳐야 했다.
그 한 달 전까지만 해도 Claude Code는 엉뚱한 파일을 고치곤 했다. 같은 버그를 세 번이나 다르게 잘못 고치는 일도 잦았다. 도구보다 쓰는 습관이 문제였다. 그래서 막히는 지점마다 규칙을 하나씩 붙였다. 아래 표가 그 대응이다. 이 세 습관을 명령어와 함께 더 자세히 풀어 쓴 글은 3시간 작업을 40분에 끝낸 세 가지 습관에 있다.
| 막힌 지점 | 그래서 붙인 규칙 |
|---|---|
| 규칙 문서를 자동으로 만든 뒤 방치했더니, 프로젝트에 맞지 않는 방식으로 코드를 쓰고 테스트를 잘못 실행했다 | 반복되는 실수가 보이면 한 줄 추가하고, 필요 없어진 줄은 지운다. 50~100줄 정도로 둔다 |
| 대화가 길어질수록 앞서 한 지시를 잊고 실수가 늘었다 | 작업이 바뀔 때마다 대화를 비우고 새로 시작한다 |
| 기능만 설명하면 그럴듯해 보이지만 동작하지 않는 코드가 나올 수 있었다 | 확인 방법을 먼저 주고, 큰 기능은 먼저 질문하게 한다 |
Claude Code 규칙 문서는 짧게 두고 실수가 나올 때마다 고친다
처음에는 규칙 문서(CLAUDE.md)를 자동으로 만든 뒤 방치했다. 그랬더니 프로젝트에 맞지 않는 방식으로 코드를 쓰고 테스트를 잘못 실행하는 일이 반복됐다.
그래서 지금은 반복되는 실수가 보이면 규칙을 한 줄 추가한다. 필요 없어진 줄은 지운다. 줄마다 “이걸 빼면 실수할까?”를 묻는다. 아니면 지운다. 개인적으로는 50~100줄이 적당했다.
작업이 바뀌면 대화를 새로 시작한다
대화가 길어질수록 앞서 한 지시를 잊고 실수가 늘어난다. 그래서 작업이 바뀔 때마다 대화를 비우고 새로 시작한다. 파일은 통째로 읽히지 않고 필요한 부분만 보게 한다. 에러 로그도 핵심 몇 줄만 붙인다. 여러 파일을 뒤지는 조사는 따로 떼어 서브에이전트에게 맡긴다. 서브에이전트는 본 작업과 별개로 조사를 대신하는 보조 AI다.
확인 방법을 먼저 주고 먼저 질문하게 한다
기능을 설명하기 전에 이게 제대로 동작하는지 어떻게 확인할지부터 정한다. “이메일 검증 함수 구현해줘”라고만 하면 그럴듯하지만 동작하지 않는 코드가 나올 수 있다. 테스트 케이스를 함께 주고 “구현 후 테스트까지 돌려줘”라고 하면 Claude Code가 스스로 확인하며 고친다. 큰 기능은 “먼저 인터뷰해줘. 기술 구현, 엣지 케이스, 트레이드오프를 물어봐”라고 해서 내가 놓친 부분을 먼저 잡는다. 엣지 케이스는 드물게 터지는 경계 상황이다.
오늘부터 Claude Code 반복 작업을 규칙으로 바꾸는 세 단계
지금 할 일은 셋이다. 매번 비슷하게 설명하고 있는 일을 찾는다. 그 일을 규칙과 설명서로 한 번 적어 둔다. 다음번에는 새로 설명하는 대신 그 문서를 다시 꺼내 쓴다.
코드나 명령어는 필요 없다. 말로 이렇게 시키면 된다.
오늘 내가 두 번 이상 같은 설명을 한 일을 골라줘.
그 일을 다음부터 바로 쓸 수 있게 규칙 문서에 한 줄씩 적어줘.
처음에는 적어 두는 데 품이 든다. 매번 말로 설명하는 쪽이 당장은 더 빨라 보인다. 하지만 한 번 적어 두면 그다음부터는 계속 회수된다. 한 번의 좋은 질문보다, 한 번 만든 규칙이 오래간다.
마무리하며
이번 이야기는 세 가지로 모인다.
- AI를 잘 쓰는 차이는 프롬프트의 질이 아니라 반복을 규칙으로 남기는 습관이다.
- 매번 설명하면 매번 비용이 들지만 규칙으로 만들면 그 일은 계속 자동으로 처리된다.
- 그 규칙이 문서로 남으면 비전공자도 전문가와 비슷한 결과를 낼 수 있다.
그래서 오늘 반복해서 시킨 일이 하나라도 있으면 그 일이 규칙으로 바꿀 첫 후보다.
함께 읽으면 좋은 글
