클로드 새 소식, 붙잡을 것과 흘릴 것 — 안 바뀌는 7칸

새 기능 소식이 뜰 때마다 저장은 하는데, 정작 쓰는 방식은 그대로인 상태가 있습니다. 읽는 시간은 늘었는데 손에 남는 게 없죠. 저처럼 여기서 막히신 분들께 쓰는 글입니다.

이 주제로 나온 글들은 대부분 "이번 업데이트에 뭐가 추가됐나"를 정리합니다. 이 글은 반대 방향입니다. 추가된 걸 세지 않고, 붙잡을 것과 흘릴 것을 가르는 축을 드립니다.

축은 하나입니다. 부를 이름이 있는 것인가, 사람이 정해야 하는 것인가. 이 축으로 재면 일곱 칸이 남습니다.

이름이 바뀔 수 있는가 — 소식 하나를 어느 칸에 넣나

새 소식을 만나면 질문 하나만 던집니다. "이걸 부르는 이름이 바뀔 수 있나?"

슬래시 문구, 제품명, 구독 가격, 버튼이 놓인 위치는 전부 불리는 이름이 있습니다. 반면 어디까지 맡길지, 무엇을 근거로 끝났다고 볼지는 부를 이름이 없어요. 이름이 없으니 갈아치울 것도 없습니다.

오해 교정 — "기본기를 배우라"는 말은 보통 쉬운 것부터 하라는 뜻으로 읽힙니다. 여기서는 다릅니다. 수명이 긴 것부터 하라는 뜻입니다. 난이도 순서가 아니라 유효기간 순서예요.

축은 하나, 이름이 바뀔 수 있는가.

왜 이 축이 필요한가 — 속도를 숫자로

바뀜 기록을 40일만 끊어 세도 발행분이 28개입니다. 8월 7일에서 17일 사이 열하루엔 10건이 나왔고, 반년 동안 모델은 여덟 번 갈렸습니다.

머릿속을 고쳐 쓰는 속도가 이걸 못 따라갑니다. 전부 쫓겠다는 계획 자체가 처음부터 어긋난 셈이에요.

지도 한 장 — 두 축으로 나눈 네 칸

	수명 짧음	수명 김
손이 많이 감	도구 세팅·요금제 갈아타기	규칙 파일 한 장 만들기
손이 덜 감	새 명령어 외우기	시키는 문장에 조건 붙이기

표에서 볼 칸은 왼쪽 아래입니다. 가장 쉬워 보여서 가장 많이 하는데, 수명이 제일 짧습니다. 새 명령어를 외우는 데 쓴 시간이 반년마다 사라지는 구조예요.

가장 쉬워 보이는 칸이 가장 빨리 사라진다.

이름표 층에서 실제로 벌어진 일

항목	반년 전	지금
답변 앞부분 미리 채우기	표준 기법	❌ 지원 종료
할 일을 대신 적어주던 보조 기능	기본 제공	❌ 최신 모델에서 빠짐
권한 질의 기본값	매번 확인	⚠️ 기본값 변경
깊게 생각하라는 키워드	"없어졌다"고 정리됨	✅ 현행 문서에 복귀

마지막 줄이 이 표의 핵심입니다. 죽었다고 배운 항목이 되살아났어요. 이름표 층은 사라지는 방향조차 예측이 안 됩니다.

사라지는 방향조차 예측이 안 된다.

반면 이 일곱 칸은 자리가 그대로였다

같은 기간 문서에서 위치가 유지된 항목들입니다. 앞쪽 다섯은 창 하나를 다루는 일이고, 뒤쪽 둘은 창 바깥에 놓입니다.

1. 시키는 문장에 조건 세 개 붙이기
2. 손대기 전에 계획 받기
3. 채점 수단 쥐여주기
4. 대화창 용량 관리하기
5. 두 번 고쳐도 안 되면 판 새로 깔기
6. 규칙 파일 한 장 두기
7. 전 모델 공통 원칙 여섯 개

일곱 개를 다 할 필요는 없습니다. 여섯 번째 칸 하나가 오늘 들인 시간을 가장 빨리 돌려줍니다. 나머지는 필요해질 때 하나씩 늘리면 됩니다.

일곱 칸 어디에도 프로그램을 작성하는 단계는 없습니다. 슬래시로 시작하는 짧은 문구가 몇 번 등장할 뿐입니다.

판단 축 자체는 요금과 무관합니다. 다만 슬래시 문구가 등장하는 칸들은 클로드 코드를 전제하고, 그쪽은 구독이 있어야 열립니다.

일곱 개 중에서도 하나는 목록에서 뺐다

네 번째 칸에 딸린 수단 중 하나는 옆길 질문을 대화에 안 쌓고 묻는 방식입니다. 쓸모는 확실합니다. 그런데 올해 3월에 나왔어요.

반년을 못 버텼으니 이 목록에서는 뺐습니다. 쓰지 말라는 뜻이 아니라 같은 칸에 두지 말자는 뜻입니다. 축을 세웠으면 내 목록부터 그 축으로 잘라야 하니까요.

공정성 — 반대 사례도 적어둡니다. 이 축이 항상 맞지는 않습니다. 되살아난 사례가 아직 하나뿐이라 "명령어 층은 예측 불가"라는 판정의 표본이 얇아요. 반례가 쌓이면 축을 다시 깎아야 합니다.

그럼 새 소식은 아예 안 봐도 되나

그건 과합니다. 저도 알림은 그대로 열어둡니다.

다만 손에 든 방식을 갈아엎게 만드는 소식은 해에 두어 번 정도입니다. 나머지는 몰라도 지장이 없었어요. 문제는 그 두어 번을 나머지와 구분하지 못하면 전부를 같은 무게로 읽게 된다는 점입니다.

탈락 조건 — 이 축을 안 쓰는 게 나은 세 경우

세 경우엔 이 글의 축을 안 쓰는 게 낫습니다.

• 도구를 오늘 처음 켰다면 과합니다. 수명을 따지기 전에 화면이 익숙해지는 게 먼저예요.
• 특정 기능 하나만 쓰러 왔다면 약합니다. 그 기능의 사용법 문서가 더 빠릅니다.
• 팀 표준을 정하는 자리라면 얕습니다. 여기엔 권한·보안 축이 빠져 있습니다.

검증을 맡기면 끝나는가

안 끝납니다. 같은 작업에서 교차 검증을 붙였더니 열세 건을 잡아줬는데, 그중 한 건은 검증하는 쪽이 틀렸습니다.

"버전 28개가 아니라 30개"라고 지적했는데, 원자료를 다시 세어보니 두 번호는 발행된 적이 없었어요. 검증자는 앞선 문서에 적힌 30을 그대로 근거로 삼은 것이었습니다.

그래서 세 번째 칸은 판정을 넘기라는 말이 아닙니다. 채점표를 쥐여주라는 쪽이에요. 판정을 통째로 넘기면 판정한 쪽을 다시 판정해야 하니까요.

"40일에 버전 30개"가 아니라 실제 발행분 28개

이 주제 글에서 "40일에 버전 30개"라는 수치를 보실 수 있습니다. 번호 구간을 그대로 센 값이에요. 실제 발행분은 28개입니다. 두 번호는 발행된 적이 없습니다.

사소해 보이지만 이런 게 이름표 층의 성질입니다. 범위로 계산하면 맞아 보이는데 세어보면 다릅니다.

이 축을 다른 글에도 대보면

같은 판정 방식을 다른 주제에 적용한 글도 있습니다. 축만 갈아 끼우면 그대로 돌아갑니다.

📌 클로드 코드 스킬, 뭘 깔고 뭘 넘길까 — 같은 "붙잡을 것 고르기" 축을 스킬 목록에 적용한 글입니다.

📌 복붙한 프롬프트, 그대로 써도 되는지 점검하는 법 — 첫 번째 칸(조건 붙이기)의 실전 점검판입니다.

📌 클로드·GPT·클로드 코드·코덱스를 2×2로 — 도구 자체를 지도에 올린 글이라 이 글보다 한 칸 위입니다.

정리 — 목록을 하나로 접으면

일곱 칸을 다 외우실 필요는 없습니다. 도입에서 드린 질문 하나면 됩니다.

"이걸 부르는 이름이 바뀔 수 있나?" 바뀔 수 있으면 흘려보내고, 부를 이름이 없으면 붙잡습니다. 일곱 칸은 그 질문을 통과한 결과물일 뿐이에요.

그리고 이 축도 언젠가 깎여야 합니다.