방구석컴퍼니
← 이야기 목록
AI 도구2026-08-13

CLAUDE.md 40줄 설계 — 클로드 코드 제작자의 기준을 코드로 옮긴 과정

CLAUDE.md에 어떤 줄이 살아남는가. 클로드 코드 제작자의 공개 기준 4개를 실제 파일 설계로 옮기고, 같은 조건 재실행으로 검증한 기록입니다.

방구석컴퍼니

혼자 일하는 사람 · 작업 기록

설정 파일은 길수록 좋다고 생각했던 시절이 있었습니다. 세 화면 분량까지 갔다가 오히려 규칙이 안 먹히는 걸 보고 방향을 뒤집었는데, 이 글은 그 뒤집힌 설계의 근거를 남기는 기록입니다. AI 도구의 지시 파일을 어떤 기준으로 채울지 결정해야 하는 분을 위한 글입니다.

문제 정의 — 왜 지시가 증발하는가

에이전트는 대화가 시작될 때 컨텍스트 윈도우에 지시 파일을 올립니다. 여기서 두 가지 실패 모드가 갈립니다. 첫째, 파일이 없으면 도구는 사용자의 관례를 추측하거나 질문으로 때웁니다. 둘째, 파일이 비대하면 정작 중요한 지시가 나머지에 희석됩니다. 공식 문서도 파일이 부풀 때 실제 지시를 무시하는 현상을 경고합니다. 그러니까 이 파일의 설계 목표는 정보량 최대화가 아니라 지시 밀도 최대화입니다.

설계 원칙 — 추측 불가능성 테스트

제작자 보리스 셔니가 공개한 운용 팁을 제 상황에 맞게 번역하면, 줄 하나가 파일에 들어올 자격은 하나뿐입니다. 모델이 코드베이스나 상식에서 유추할 수 없는 정보인가. 저장 경로 관례, 명명 규칙, 반복적으로 걸리는 함정이 여기 해당합니다. 반대로 코드만 읽으면 아는 사실, 일반적인 품질 요구는 자격 미달입니다.

심문 루프 — 세 화면이 절반이 되기까지

기존 파일의 각 줄에 같은 질문을 걸었습니다. "이 줄을 삭제하면 실제로 오답이 나오는가." 확신이 없으면 지우고 하루 돌려봤습니다. 오답이 재현되면 복원, 아니면 영구 삭제. 이 루프를 돌리고 나니 분량이 절반 아래로 내려왔고, 남은 줄은 전부 삭제 시 실제 오류가 재현됐던 것들입니다.

흥미로운 건 제작자 본인의 운용입니다. 새 모델이 나올 때마다 프롬프트를 통째로 비우고, 한 줄씩 복원하며 실효를 재확인한다고 합니다. 최근 회차에선 80%가 복귀하지 못했다고 밝혔습니다. 모델이 좋아질수록 지시 파일은 짧아지는 방향이 맞다는 방증입니다.

모호성 제거 — 형용사를 수치로

줄이는 것만으로 해결 안 되는 유형이 하나 남습니다. 존재하는데 안 지켜지는 줄. 진단 기준은 두 갈래입니다. 파일이 길어 묻혔거나, 문구가 모호하거나. 후자의 전형이 형용사 지시입니다.

모호한 지시판정 가능한 지시효과
보기 좋게 작성제목 15자 이내즉시 준수
깔끔하게 정리결과는 지정 폴더, 파일명에 날짜즉시 준수
간결하게섹션당 3문장 상한즉시 준수

모델 입장에서 형용사는 판정 함수가 없는 조건문입니다. 수치와 경로로 바꾸는 순간 준수율이 달라지는 게 재현됩니다.

검증 가능성 — 완료 신호를 파일에 심기

에이전트는 그럴듯해 보이는 지점에서 멈추는 경향이 있습니다. 그래서 각 작업 유형에 완료 판정 방법을 지시로 심었습니다. 예를 들어 글 작성 작업엔 분량 집계 보고를, 파일 조작엔 결과 재확인 절차를 요구합니다. 판정 신호가 파일에 있으면 확인 노동이 사용자에게서 에이전트로 이동합니다.

재실행 검증 — 같은 조건, 파일 유무만 다르게

설계가 실제로 작동하는지 통제 실험으로 확인했습니다. 동일 모델, 동일 프로젝트 폴더, 동일 프롬프트, 유일한 변수는 파일 유무.

관측 항목파일 없음파일 있음
경로 규칙 준수위반 (루트 저장)준수
명명 규칙위반준수
완료 검증생략수행 + 보고
소요 시간36.4초52.2초

시간 증가는 검증 단계의 비용입니다. 설계 의도대로면 이 비용은 사람이 하던 검사의 이전이므로 순손실이 아닙니다.

안전장치 — settings.json의 역할 분리

지시 파일과 별개로 권한 설정을 분리한 이유도 설계 판단입니다. 폴더 삭제류 파괴적 명령은 지시로 금지하는 게 아니라 권한에서 차단해야 합니다. 지시는 확률적으로 지켜지지만 권한은 결정적으로 막히기 때문입니다. 확률적 방어와 결정적 방어를 같은 파일에 섞지 않는 것, 이게 두 파일 체제의 이유입니다.

유지보수 — 파일을 키우는 훅

운영하면서 파일을 직접 편집하는 빈도를 줄이려고 두 개의 트리거 단어를 만들어뒀습니다. 오류를 목격한 순간 채팅에 트리거를 치면 해당 실수의 방지 규칙이 한 줄로 축적되는 방식입니다. 편집 비용이 0에 가까워지니 규칙 축적이 실제로 일어납니다. 다만 축적만 있고 삭제가 없으면 다시 비대해지므로, 심문 루프를 주기적으로 돌리는 걸 전제로 한 설계입니다.

실패담 — 처음 버전이 안 됐던 이유

솔직하게 남기면, 첫 버전은 위 원칙을 하나도 안 지켰습니다. 말투 지침만 열두 줄이었고, 그중 실제로 출력에 영향을 준 건 두 줄이었습니다. 나머지 열 줄은 지면만 차지하며 중요한 지시의 희석재 노릇을 했습니다. 열두 줄을 쓴 시간보다 열 줄을 지울 용기를 내는 데 걸린 시간이 더 길었다는 게 이 작업의 요약입니다.

판단이 필요한 분께

이 설계를 그대로 쓸 필요는 없습니다. 다만 줄 하나를 두고 고민될 때 "삭제하면 오답이 재현되는가"라는 질문 하나는 어디서든 통합니다. 여러분 파일에서 그 질문을 통과 못 할 것 같은 줄, 몇 개나 됩니까?

실측 장면 전체는 영상으로 남겨뒀고, 완성 파일은 방구석모각코 오픈톡에서 배포 중입니다.

새 글 알림

이런 작업 기록, 계속 받아보실래요?

네이버 블로그 이웃추가하면 새 글이 피드로 바로 떠요. 광고 없이 진짜 이야기만.