클로드 기본기 7가지를 고른 기준 — 공식 문서가 갈라둔 층을 따라서
모델이 여덟 번 바뀌는 동안에도 자리가 유지된 동작만 남기는 선별 기준과, 그 기준이 어디서 나왔는지 근거를 정리했습니다.
방구석컴퍼니
혼자 일하는 사람 · 작업 기록
공식 변경 기록 40일 치에 버전이 28개 올라오는데, 같은 기간 제 작업 방식은 한 줄도 안 바뀌었습니다. 읽는 시간만 늘고 실력은 제자리인 상태였어요.
결론부터 적습니다. 문제는 소식을 못 따라간 게 아니라, 무엇이 오래 가는 층인지 판별하는 기준이 없던 것이었습니다. 이 글은 그 기준을 어디서 가져왔는지, 왜 일곱 개로 잘렸는지를 근거와 함께 정리한 문서입니다.
따라 하는 순서가 필요하신 분께는 맞지 않습니다. 여긴 선별 근거만 다룹니다.
왜 하필 지금 선별 기준이 필요한가?
지금 필요한 이유는 바뀌는 속도가 사람이 기억을 갱신하는 속도를 넘었기 때문입니다. 다만 이건 체감이 아니라 세어보면 나오는 수치예요.
| 축 | 실측 구간 | 값 |
|---|---|---|
| 공식 변경 기록 | 2026-07-08 ~ 08-17 (40일) | 발행 버전 28개 |
| GitHub 릴리스 | 2026-08-07 ~ 08-17 (11일) | 10건 |
| 모델 세대 | 2026-02-05 ~ 07-24 (6개월) | 8종 |
여기서 흥미로운 건 버전 번호와 실제 발행분이 다르다는 점입니다. 번호로는 205번부터 234번까지 서른 개 구간인데, 두 번호는 발행된 적이 없어요. 세어보지 않고 범위로 계산하면 두 개가 부풀려집니다.
안 바뀌는 층은 누가 정했나?
제가 고른 게 아니라 문서 구조가 먼저 선언했습니다. 다만 그 선언을 알아보려면 목차를 봐야 합니다.
프롬프트 가이드 목차는 세 갈래로 나뉩니다. 모델별 지침, 갈아탈 때 볼 것들, 그리고 지금 나온 모든 모델에 공통으로 통하는 기법. 마지막 칸이 이 글이 말하는 층입니다.
즉 "어떤 게 오래 갈까"는 추측의 영역이 아니었습니다. 만든 쪽이 자기 문서에서 칸을 갈라 두고 관리하고 있었어요.
선별 기준을 한 문장으로 쓰면?
교체 가능한 이름표가 붙어 있으면 버리고, 사람이 정하는 자리면 남깁니다. 다만 이 기준은 명령어를 전부 버리라는 뜻이 아닙니다.
- 이름표가 붙은 것: 슬래시 명령 문자열, 제품명, 플랜 가격, 메뉴 경로
- 사람이 정하는 자리: 작업 범위 설정, 완료 판정 근거, 위임 한계선
이 기준을 적용하면 일곱 개가 남습니다. 순서는 대화창 안에서 하는 다섯 개, 그 바깥 층 두 개로 갈립니다.
실제로 죽은 것은 무엇이었나?
반년 사이 사라진 항목은 전부 이름표가 붙어 있던 쪽이었습니다. 다만 그중 하나는 죽었다가 되살아났습니다.
| 항목 | 상태 | 성격 |
|---|---|---|
| 답변 앞부분 미리 채우기 | 지원 종료 | 입력 방식 |
| 작업 목록을 알아서 세우던 기능 | 최신 모델에서 제거 | 도구 |
| 권한 질의 기본값 | 변경 | 설정 |
| 깊게 생각하라는 키워드 | 폐기됐다가 현행 문서에 복귀 | 명령어 |
| "천천히 생각해" 계열 표현 | 여전히 무효 | 명령어 |
표에서 볼 칸은 네 번째 줄입니다. 같은 문단 안에서 하나는 살아 돌아오고 하나는 계속 죽어 있어요. 명령어 층은 방향조차 예측이 안 된다는 뜻입니다.
원칙 층이 정말 성과를 가르나?
가릅니다. 다만 근거는 제 경험이 아니라 표본이 큰 쪽을 씁니다.
앤트로픽이 약 40만 세션을 분석한 리서치에서, 숙련도를 가른 신호는 세 가지였습니다. 지시가 얼마나 정밀한지, 검증을 요구하는지, 방향을 잡아주는지. 초보 구간 성공률이 15%, 숙련 구간이 28~33%였고, 상위 10개 직업군은 소프트웨어 엔지니어와 성공률 차이가 7%p 안쪽이었습니다.
여기서 중요한 건 마지막 줄입니다. 직군이 갈리지 않았다는 건 코딩 지식이 변수가 아니었다는 뜻이에요.
같은 조건에서 비교하면 어떻게 다른가?
같은 모델에 같은 요청을 넣고 조각 세 개만 붙였다 뺐다 해보면 갈립니다. 반면 모델만 최신으로 올리고 요청을 그대로 두면 차이가 잘 안 납니다.
- 조각을 뺀 요청: 어디서 본 듯한 문장이 나옵니다
- 조각을 붙인 요청: 지목한 원본을 먼저 열어보고 답합니다
조각은 세 개입니다. 어디를 볼지, 무엇을 기준으로 삼을지, 무엇을 뺄지.
검증을 많이 시키면 좋아지나?
아닙니다. 오히려 과잉이 됩니다. 다만 이 판단은 제가 한 번 틀린 다음에 얻었습니다.
확인 지시를 겹겹이 쌓았다가 되돌린 기록
처음엔 "검증 수단을 줘야 한다"는 원칙을 문장 수로 이해했습니다. 확인하라는 지시를 예닐곱 줄씩 박아 넣었어요.
결과가 나아지지 않았습니다. 문서를 열어보니 요즘 세대는 별말 없어도 자기 결과를 되짚는 편이고, 그 위에 감시 문장을 얹으면 과해진다고 적혀 있더군요.
원인은 셋이었습니다. 원칙을 분량으로 번역한 것, 모델 세대 차이를 안 본 것, 확인의 주체를 정하지 않고 횟수만 늘린 것.
방향을 바꿨습니다. 확인하라고 조르는 게 아니라 확인할 수단을 한 번 쥐여주는 쪽으로요. 지시는 한 줄로 줄었고 결과는 나아졌습니다.
원칙을 분량으로 오해하면 어떻게 되나?
지시가 늘어날 뿐 결과는 그대로입니다. 위 기록이 그 사례였어요.
원칙 층은 문장을 더 넣으라는 요구가 아닙니다. 판정할 근거를 한 번 넘기라는 요구입니다. 근거가 넘어가면 지시는 오히려 짧아져요.
여기서 갈리는 지점이 하나 더 있습니다. 판정을 통째로 남에게 넘기면, 이번엔 그 판정을 누가 판정하느냐가 남습니다. 그래서 세 번째 항목의 문장은 "검증을 시켜라"가 아니라 "채점 수단을 쥐여줘라"입니다.
이 기준의 한계는 어디인가?
세 가지가 남습니다. 다만 셋 다 원칙 층을 부정하지는 않습니다.
- 완결이 아닙니다. 곁가지 질문을 기록에 안 남기는 방식은 2026년 3월에 생겼습니다. 여섯 달을 못 채웠으니 일곱 개 목록에 넣지 않았지만, 유용한 건 사실입니다.
- 품질을 보장하지 않습니다. 무엇을 시킬지 정하는 일은 그대로 사람에게 남습니다.
- 접근 조건이 있습니다. 원칙 층은 무료 환경에서도 쓰지만, 본문의 명령어는 클로드 코드가 붙은 유료 플랜을 전제합니다.
오늘 무엇부터 하면 되나
세 가지를 봤으니 액션도 셋으로 맞춥니다.
- 지금 쓰는 요청 문장 하나에 조각 세 개를 붙여봅니다
- 작업 폴더에 규칙 파일 한 장을 만들고 200줄 아래로 자릅니다
- 결과를 판정할 기준 한 줄을 정해 요청에 답니다
새 소식이 뜨면 하나만 물어보면 됩니다. 이건 이름표인가, 사람이 정하는 자리인가.
이 글에서 제가 틀릴 수 있는 문장은 "명령어 층은 방향조차 예측이 안 된다"입니다. 되살아난 사례가 하나뿐이라 표본이 얇아요. 반례를 겪으셨다면 알려주세요.