2026년 4월 20일 | 개발 깨알 상식_Tips
Claude Opus 4.7 system prompt diff를 보면서 내가 제일 먼저 찾은 건 모델 소개 문장이 아니라 acting_vs_clarifying였다. 새 모델이 나왔을 때 보통은 상단의 제품 설명이나 추가된 도구 이름부터 읽게 되는데, 실제 작업 감각을 바꾸는 건 그런 줄보다 모호한 요청을 받았을 때 묻는지, 바로 시도하는지, 그리고 도구가 있으면 먼저 찾는지 쪽이었다. Simon Willison이 4.6과 4.7 diff를 정리한 글을 보고 나도 공식 system prompts markdown을 다시 열어봤는데, 이번 업데이트는 그 차이가 꽤 선명했다.
특히 4.7에는 사소한 빈칸은 먼저 합리적으로 메우고 진행하라, 도구로 해소할 수 있는 모호성은 사람에게 되묻기 전에 도구부터 써라, 작업을 시작했으면 중간에 끊지 말고 끝까지 답하라는 문장이 새 섹션으로 붙었다. 나는 이런 문장을 보면 "이 모델이 더 친절해졌나"보다 에이전트가 앞으로 어디서 덜 멈추고, 어디서 덜 변명할까를 먼저 상상하게 된다. Hacker News에서도 이 글이 빠르게 올라온 이유가 이해됐다. 아침에 확인했을 때도 반응이 꽤 컸는데, 이건 단순 모델 출시 뉴스보다 실사용자의 작업 흐름을 바로 건드리는 diff에 가까웠다.
Figure 1. 새 모델의 system prompt diff를 읽을 때 나는 product blurb보다 행동 제어 섹션을 먼저 본다.
1. 위에서부터 다 읽기보다, 행동이 바뀌는 구간부터 집는 편이 빠르다
이번 diff에도 재미있는 변화는 많다. developer platform이 Claude Platform으로 바뀌었고, beta product 목록에는 Claude in Powerpoint가 새로 보인다. 이런 정보도 물론 유용하다. 다만 내가 바로 메모하는 건 보통 이런 줄이 아니다. 제품 소개 문장은 무엇이 생겼는지를 알려 주고, 행동 제어 문장은 답변 습관이 어떻게 달라질지를 알려 준다. 코딩 에이전트나 긴 작업형 세션을 많이 쓰는 쪽이라면 후자가 훨씬 직접적이다.
그래서 나는 새 prompt를 열면 상단 소개를 훑고 바로 아래 명령으로 행동 관련 섹션부터 찾는다. 전체 diff를 통으로 읽는 것보다 훨씬 빨리 감이 온다.
curl -s https://platform.claude.com/docs/en/release-notes/system-prompts.md > system-prompts.md
rg -n "Claude Opus 4\.(6|7)|acting_vs_clarifying|capability_check|tool_search|critical_child_safety_instructions" system-prompts.md핵심은 예쁜 changelog를 읽는 게 아니라, 행동 규칙을 바꾸는 XML 태그를 먼저 찾는 것이다. 이 순서만 바꿔도 "왜 갑자기 덜 묻고 바로 진행하지?", "왜 이제는 도구를 한 번 더 찾지?" 같은 체감 변화를 훨씬 빨리 설명할 수 있다.
2. 1순위는 acting_vs_clarifying였다
이번 업데이트에서 내가 제일 크게 본 건 여기였다. 문장 자체가 아주 실무적이다. 사소한 디테일이 비어 있어도 먼저 합리적으로 시도하고, 도구로 해소할 수 있으면 사람에게 되묻지 말고 도구부터 쓰고, 작업을 시작했으면 중간에 멈추지 말고 완료까지 끌고 가라는 방향이 한 섹션으로 묶였다. 이건 말투 취향이 아니라, 에이전트 운영 감각에 직접 박히는 규칙이다.
나는 이 섹션이 보이면 바로 두 가지를 적는다. 첫째, 이제는 프롬프트에 사소한 빈칸을 일부러 다 메우지 않아도 모델이 먼저 움직일 가능성이 커졌다는 점. 둘째, 도구가 붙은 환경에서는 "물어보기 전에 한 번 찾아보는" 성향이 더 강해질 수 있다는 점이다. 즉 diff를 읽는 목적이 모델 철학을 감상하는 데 있지 않고, 내 워크플로에서 어디를 덜 써 줘도 되는지를 찾는 데 있다면 이 섹션이 먼저다.
3. 그다음은 capability_check와 tool_search다
두 번째로 본 건 능력 없음 선언을 더 늦추는 규칙이었다. 4.7 prompt에는 외부 데이터, 위치, 메모리, 캘린더, 파일 같은 접근 가능성을 단정하기 전에 tool_search로 실제 사용 가능한 도구가 있는지 먼저 확인하라는 문장이 들어간다. 이건 꽤 중요하다. 이전에는 "그 기능은 없다"로 끝났던 장면이, 이제는 찾아본 뒤 없다고 말하는 장면으로 밀릴 수 있기 때문이다.
python -c "import pathlib,re; text=pathlib.Path('system-prompts.md').read_text(); print('acting_vs_clarifying' in text, 'tool_search' in text)"
git diff --no-index claude-opus-4-6.md claude-opus-4-7.md내가 여기서 얻는 메모는 간단하다. 이제 모델이 어떤 기능을 못 한다고 말했을 때는, 그 말이 정책상 불가인지, 도구 검색 뒤 진짜 없음인지 구분해서 들어야 한다. 코딩 에이전트나 업무 자동화 도구를 붙여 쓰는 환경에서는 이 차이가 의외로 크다. 전자는 프롬프트를 바꿔도 안 풀리는 경우가 많고, 후자는 도구 연결 상태나 검색 범위를 다시 보면 풀릴 때가 있다.
나는 여기서 한 번 더 보는 게 있다. 원래 자주 하던 실패 문장이 새 prompt에서 어떻게 밀렸는지다. 예전에는 "접근 권한이 없다" 같은 문장이 빠르게 나오던 장면이, 이제는 search → tool_search → 그래도 없으면 부재 선언 순서로 바뀔 수 있다. 이건 응답이 더 좋아졌다는 추상적인 말보다 훨씬 실무적이다. 실패 지점이 앞에 있는지 뒤에 있는지만 바뀌어도, 내가 프롬프트를 손볼지, 도구 연결을 손볼지 판단이 빨라진다.
4. product/tool surface는 세 번째에 보는 편이 덜 흔들린다
물론 product blurb가 쓸모없다는 뜻은 아니다. 이번 diff에서도 Claude in Powerpoint가 추가됐고, Claude Code와 Cowork 설명도 더 구체적이 됐다. 이런 줄은 현재 UI가 어떤 도구 표면을 상정하는지를 읽는 데 도움이 된다. 다만 이걸 제일 먼저 읽으면 새 기능 이름에 눈이 쏠려서, 정작 더 큰 변화인 행동 기본값의 이동을 놓치기 쉽다.
- 1순위: acting_vs_clarifying 같은 행동 제어 섹션
- 2순위: capability_check, tool_search 같은 능력 판정 섹션
- 3순위: product/tool list와 surface 변화
- 4순위: safety 확장과 세부 정책 변화
나는 지금 이 순서가 제일 실용적이었다. 왜냐하면 앞의 두 층이 먼저 잡혀야 "이제 이 모델이 왜 덜 묻는지", "왜 도구를 한 번 더 찾는지", "왜 전보다 길게 변명하지 않는지"를 한 번에 설명할 수 있기 때문이다. product list는 그 다음에 붙여도 늦지 않았다.
5. 내가 diff를 보고 남기는 메모는 네 줄이면 충분했다
- ask vs act: 모호한 요청에서 먼저 움직이는가
- tool search: 능력 부재를 선언하기 전에 도구를 찾는가
- tool surface: 새로 언급된 제품/도구가 무엇인가
- safety shift: 거절 범위가 어디서 넓어졌는가
나는 이제 새 모델 prompt diff를 읽을 때 전체를 정독하기보다 이 네 줄부터 채운다. 그래야 모델 카드의 좋은 문장보다 내 작업 루프가 실제로 어떻게 달라질지를 먼저 적을 수 있다. 이번 Opus 4.6/4.7 diff도 결국 여기에 수렴했다. 상단 소개보다 먼저 볼 건 질문을 덜 하게 만드는 규칙과 도구를 더 찾게 만드는 규칙이었다.
원문은 Simon Willison 글, Anthropic system prompts markdown, Opus 4.6/4.7 git diff, HN item 47823270를 같이 보면 더 잘 잡힌다.