Claude Code를 만든 Boris Cherny가 최근 X에 짧은 글 하나를 올렸다. 예전부터 일 잘하는 엔지니어들은 vim이나 emacs 매크로를 짜고 lint 규칙을 만들고 테스트 스위트를 쌓는 데 시간을 썼다는 얘기였다. 언뜻 뻔한 회고처럼 들렸다.
반전은 다음 문장이었다. 그는 이 습관이 예전보다 지금, AI 시대에 훨씬 더 중요해졌다고 했다. Claude를 여러 개 동시에 돌리는 사람에게는 그 ‘규칙’ 하나가 에이전트 전부의 속도를 같이 끌어올리기 때문이다.
30초 요약
– AI를 잘 쓰는 차이는 좋은 프롬프트가 아니라 반복 작업을 규칙으로 남기는 습관
– 매번 설명하면 매번 비용이 들지만 한 번 규칙으로 적어두면 그 일은 계속 자동으로 처리된다
– 규칙과 설명서가 있으면 비전공자도 전문가와 비슷한 결과를 낸다
– 지금 할 일은 머릿속 노하우를 AI가 읽을 수 있는 문서로 옮겨두는 것
AI를 잘 쓴다는 건 흔히 좋은 질문(프롬프트)을 잘 짜는 능력이라고 여겨진다. 하지만 Cherny가 말하는 실제 차이는 반복되는 일을 규칙과 문서로 남겨 AI가 스스로 참고하게 만드는 습관에 가깝다.
AI를 잘 쓴다는 건, 질문을 잘하는 걸까
아니다. Cherny가 지목한 차이는 프롬프트의 질이 아니라 반복을 규칙으로 남기는 습관이다.
프롬프트 엔지니어링이라는 말이 한동안 유행했다. 질문을 어떻게 던지느냐에 따라 AI 답변의 질이 갈린다는 논리였고 어느 정도는 맞는 말이다. 그런데 Cherny의 글은 이 통념을 다른 각도에서 본다. 그가 든 예시는 코드가 아니라 습관이었다. “예전부터 최고의 엔지니어들은 자기 일을 자동으로 처리되게 만드는 데 시간을 썼다.” 매크로를 짜고 규칙을 만들고 테스트를 쌓는 일이었다.
이건 완전히 새로운 이야기는 아니다. 다만 AI 시대에는 그 무게가 달라진다. 혼자 일할 때는 습관 하나가 그 사람 한 명의 속도만 바꿨다. 지금은 Claude 여러 개를 동시에 돌리는 사람이 흔하다. 그 상태에서 규칙 하나를 만들면, 돌아가는 에이전트 전부가 동시에 빨라진다. 레버리지의 크기 자체가 달라진 셈이다.
물론 이건 좋은 프롬프트가 쓸모없다는 말이 아니다. 다만 반복되는 일만큼은 시스템으로 옮기는 쪽이 훨씬 남는 장사라는 뜻이다.
왜 매번 똑같이 시키는 건 손해일까
매번 설명하면 매번 비용이 들고 어느 순간 빠뜨린다. 한 번 규칙으로 만들면 그 일은 다음부터 계속 자동으로 처리된다.
패스트푸드 프랜차이즈가 전국 어디서나 같은 맛을 내는 건 요리사가 특별히 뛰어나서가 아니다. 조리법이 매뉴얼로 박혀 있어서다. 매장마다 다른 직원이 있어도 매뉴얼만 있으면 같은 결과가 나온다. AI에게 매번 “이거 해줘, 저건 이렇게 해줘”라고 말로 설명하는 건, 매장을 열 때마다 요리사한테 레시피를 처음부터 다시 불러주는 것과 비슷하다.
반대로 한 번 규칙을 적어두면 상황이 달라진다. 그 규칙은 이번 대화가 끝나도 사라지지 않는다. 다음번에도, 그다음 번에도 똑같이 적용된다.
| 방식 | 매번 설명하기 | 규칙으로 남기기 |
|---|---|---|
| 비용 | 대화할 때마다 다시 지불 | 처음 한 번만 지불 |
| 누락 위험 | 바쁘면 빠뜨리기 쉽다 | 문서에 있어 놓치지 않는다 |
| 효과 범위 | 이번 대화 한 번 | 다음 모든 대화, 모든 에이전트 |
AI에게 ‘나만의 설명서’를 주면 뭐가 달라질까
Cherny는 이 차이를 실제로 실천한다. Claude 활용법을 정리한 howborisusesclaudecode.com에 따르면 그는 이렇게 말한다. “Claude가 실수할 때마다 나는 다르게 하라고 말하지 않는다. 그 대신 CLAUDE.md에 적거나, 스킬로 만든다.” CLAUDE.md(Claude Code가 작업을 시작할 때마다 자동으로 읽는 규칙 파일)는 Claude Code 팀 전체가 공유하는 문서이고 팀원 누구나 한 주에 여러 번 고쳐 쓴다.
(Claude Code 팀이 여러 에이전트를 규칙 기반으로 협업시키는 방식을 보여주는 다이어그램, 출처: howborisusesclaudecode.com)
핵심은 이거다. Claude가 내 규칙을 몰라서 실수했다면, 그건 AI 탓이 아니라 그 규칙을 적어두지 않은 내 탓이다. 그래서 팀도, 개인도 AI가 읽을 ‘나만의 설명서’를 만들어야 한다는 게 그의 결론이다.
이건 코드에만 해당하는 얘기가 아니다. 내 머릿속에만 있는 노하우, 이를테면 어떤 문의는 이렇게 답하고 어떤 보고서는 이 순서로 정리한다는 규칙도 결국 같은 방식으로 남길 수 있다. aboutcorelab도 비슷하게 움직인다. AI 에이전트가 같은 실수를 반복하지 않도록, 작업이 실패한 이유나 글쓰기 규칙 같은 걸 메모리 파일로 남겨둔다. 다음 작업을 시작할 때는 그 메모리부터 먼저 읽고 시작하는 식이다.
이게 왜 비전공자에게 더 좋은 소식일까
규칙이 문서로 남아 있으면, 전문가가 아니어도 전문가와 비슷한 결과를 낼 수 있다.
이케아 가구는 목수가 아니어도 조립 설명서만 있으면 조립할 수 있다. Cherny가 말하는 것도 비슷한 구조다. 걸림돌은 대개 실력이 아니라, 그 실력이 누군가의 머릿속에만 있고 밖으로 안 나와 있다는 점이다. 노하우가 문서로 나오는 순간, 그걸 실행하는 데 필요한 전문성의 문턱이 낮아진다.
실제로 이 효과는 이미 확인됐다. Anthropic이 연 Claude Code 해커톤에서 우승한 건 전문 엔지니어가 아니라 전기공, 의사, 목수였다. Cherny는 이를 두고 “Claude Code에서 가장 많은 가치를 얻어가는 사람들은 내가 예상한 사람들이 아니다”라고 말했다(Platformer). 규칙과 문서가 갖춰지면 진입장벽이 낮아진다는 걸 보여주는 사례다.
그래서 오늘부터 뭘 하면 될까
지금 할 일은 셋으로 나뉜다. 반복되는 일을 찾고 그 일을 규칙으로 한 번 적어두고 다음번엔 새로 설명하는 대신 그 규칙을 다시 꺼내 쓰면 된다.
처음엔 이걸 적어두는 데 품이 든다. 매번 말로 설명하는 게 당장은 더 빨라 보인다. 하지만 한 번 적어두면 그다음부터는 계속 회수된다. 한 번의 좋은 질문보다, 한 번 만든 규칙이 오래간다.
정리
이번 이야기의 핵심은 셋이다. AI를 잘 쓰는 차이는 프롬프트의 질이 아니라 반복을 규칙으로 남기는 습관이다. 매번 설명하면 매번 비용이 들지만 규칙으로 만들면 그 일은 계속 자동으로 처리된다. 그 규칙이 문서로 남으면 비전공자도 전문가와 비슷한 결과를 낼 수 있다.
결국 AI를 잘 쓰는 사람과 그렇지 못한 사람을 가르는 건 재능이 아니라 습관이다. 오늘 반복해서 시킨 일이 있다면, 그걸 다음에도 또 말로 설명할지, 아니면 한 번 적어두고 계속 꺼내 쓸지부터 정해보면 된다.
함께 읽으면 좋은 글
