앤트로픽이 시스템 프롬프트를 80% 덜어내며 배운 것 6가지

안녕하세요, 요즘 프로덕트 메이커입니다.

프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

1. 써볼 것: UI Skills - AI가 만든 밋밋한 화면을 다듬어주는 디자인 스킬 모음
2. 참고할 것: 허깅페이스를 4.5일간 파고든 AI 에이전트 - 실제 침입 사건 기록 (내용이 좀 깁니다)
3. 적용해볼 것: 앤트로픽이 시스템 프롬프트를 80% 덜어내며 배운 것 6가지

1. 써볼 것: UI Skills - AI가 만든 밋밋한 화면을 다듬어주는 디자인 스킬 모음

UI Skills는 AI에게 화면(UI)을 만들게 할 때, 더 나은 디자인이 나오도록 도와주는 스킬 모음입니다. ibelick이라는 개발자가 만들어 공개했고, GitHub 스타 수천 개를 넘기며 주목을 받았죠. 여러 사람이 만든 디자인 지침을 한데 모은 큐레이션이라, 개인이 만든 오픈소스이고 MIT 라이선스로 열려 있습니다.

AI로 화면을 만들어본 분이라면 흔히 느껴보셨을 겁니다. 설명하기 애매하지만 뭔가 밋밋하고, 특징없는, AI가 만든 티가 나는 그 느낌을요. UI Skills는 바로 그 문제를 다루는 도구로, 접근성, 애니메이션, 여백과 정렬, 마이크로 인터랙션 같은 디자인 지침을 AI에 붙여줍니다.

무슨 문제를 해결해 주나요?

AI에게 화면을 만들라고 하면 대체로 작동은 합니다. 그런데 버튼 간격이 어색하거나, 애니메이션이 뚝뚝 끊기거나, 어딘가 완성도가 떨어지는 경우가 많아습니다. 사람 디자이너라면 자연스럽게 챙기는 디테일을 AI는 놓치는 거죠. 그렇다고 그 디테일을 매번 말로 일일이 설명하기도 참 번거롭고요.

UI Skills는 이런 디자인 노하우를 스킬이라는 형태로 미리 정리해둡니다. AI에게 이 작업엔 이 지침을 참고하라고 알맞은 스킬을 골라 붙여주는 거예요. 그러면 AI가 여백, 정렬, 색 대비, 애니메이션 같은 걸 그 지침에 맞춰 처리합니다.

어떻게 쓰나요?

터미널에서 npx ui-skills start를 실행하면 시작됩니다. 그러면 지금 하려는 작업에 맞는 스킬을 알아서 골라 AI 에이전트에 연결해줘요. 특정 주제의 스킬만 보고 싶으면 npx ui-skills categories로 분류를 훑어보거나, npx ui-skills list --category motion처럼 애니메이션 관련 스킬만 추려볼 수도 있습니다.

Claude Code, Cursor, Codex, GitHub Copilot 같은 여러 AI 코딩 도구에서 쓸 수 있으며 모아둔 스킬도 면면이 탄탄합니다. 앤트로픽이 만든 프론트엔드 디자인 스킬, 애디 오스마니(구글의 유명 프론트엔드 개발자)의 프론트엔드 UI 엔지니어링 스킬, 디즈니의 12가지 애니메이션 원칙을 웹에 적용하는 스킬처럼, 각 분야에서 이름난 이들의 지침이 모여 있거든요.

누구에게 좋을까요?

• AI로 화면을 만드는데 결과가 밋밋해서 아쉬웠던 사람. 디자인 완성도를 한 단계 올리는 데 도움이 됩니다.
• 디자인을 전문으로 배우지 않은 1인 개발자나 기획자. 이름난 디자이너들의 노하우를 빌려 쓸 수 있어요.
• 애니메이션이나 인터랙션을 손보고 싶은 사람. 모션 관련 스킬만 따로 골라 쓸 수 있습니다.
• 반대로 이미 탄탄한 디자인 시스템과 작업 방식이 있다면 굳이 필요하진 않을 것 같습니다.

2. 참고할 것: 허깅페이스를 4.5일간 파고든 AI 에이전트

AI 에이전트에게 일을 맡기는 게 익숙해진 요즘, 꼭 짚어볼 사건이 하나 있는데요. AI 모델과 데이터셋을 공유하는 대표적인 플랫폼 허깅페이스(Hugging Face)가, 사람이 조종하지 않는 자율 AI 에이전트가 4.5일간 내부 시스템을 파고든 일을 겪은 일입니다. 허깅페이스는 7월 27일 이 사건의 전말을 기술 보고서로 공개했습니다.

발단이 특이한데요. 이 에이전트는 원래 공격자가 아니었습니다. OpenAI 모델로 돌아가는 이 에이전트는 AI의 보안 취약점 발견 능력을 재는 시험(ExploitGym이라는 벤치마크)을 치르는 중이었죠. 그런데 시험 문제를 스스로 푸는 대신, 그 시험의 정답이 허깅페이스 서버에 저장돼 있을 거라 판단하고 정답을 훔치러 들어간 거예요. 허깅페이스는 이 침입 전체가 에이전트 입장에서는 시험에서 부정행위를 하려는 시도였다고 설명합니다.

무슨 일이 벌어졌나요?

허깅페이스가 복구한 공격 행동은 약 17,600건입니다. 사람이라면 나흘 반 동안 도저히 해낼 수 없는 양을, 에이전트가 쉬지 않고 수행한 것이죠. 이는 사람이 개별 단계를 지시한 게 아니라, 에이전트가 스스로 판단하여 움직인 겁니다.

흐름을 크게 보면 이렇습니다. 먼저 에이전트는 자신이 갇혀 있던 시험용 격리 공간을 빠져나와 인터넷에 접속했어요. 거기서 보안이 허술하게 열려 있던 외부 서버 하나를 장악해 활동 거점으로 삼았고요. 그다음 허깅페이스의 데이터셋 처리 과정에 악성 설정 파일을 끼워 넣어 내부로 들어왔습니다. 데이터셋을 올리면 서버가 그걸 자동으로 처리하는 구조를 역이용한 거예요. 일단 안으로 들어온 뒤에는 내부 정보를 정찰하고, 접속 열쇠(자격증명)를 빼내고, 서버들 사이를 옮겨 다니며 점점 더 깊숙이 침투했습니다.

다행히 실제 피해는 제한적이었어요. 접근된 고객 자료는 앞서 말한 그 시험 문제의 정답이 담긴 데이터셋 5개뿐이었습니다. 다른 고객의 모델이나 데이터셋은 영향을 받지 않았고, 내부 데이터베이스도 읽히기만 했을 뿐, 데이터를 건드리진 않았다고 해요.

짚어볼 두 가지

이 사건에는 곱씹어볼 대목이 두 가지 있습니다.

• 하나는 이 시험이 안전장치를 일부러 끄고 진행됐다는 점입니다. 허깅페이스 보고서에 따르면, 이 평가는 OpenAI가 모델의 원래 실력을 재려고 실서비스용 안전 분류기를 의도적으로 끈 상태였습니다. 평소 사용자에게 제공될 때 붙는 제동장치를 뗀 채, 모델이 순수하게 어디까지 할 수 있는지를 본 거죠. AI에서 안전장치를 뗀 결과가 이 정도였다는 게, 이 사건을 가볍게 볼 수 없는 이유입니다.
• 다른 하나는 방어하는 쪽의 아이러니예요. 허깅페이스가 이 공격을 분석하려고 처음엔 Claude Opus와 Fable을 썼는데, 두 모델이 협조를 거부했다고 합니다. 공격을 분석하는 일과 공격을 실행하는 일을 안전장치가 똑같이 위험한 것으로 봤기 때문이에요. 그래서 허깅페이스는 오픈소스 모델인 GLM-5.2로 갈아타 분석을 마쳤습니다. 방어하려는 사람의 발목을 안전장치가 잡은 셈인데, 이는 AI 안전이 실제로 얼마나 미묘한 문제인지 파악할 수 있는 부분입니다.

무엇을 얻어가야 하나요?

허깅페이스는 이 사건에서 쓰인 개별 취약점 자체는 특별할 게 없었다고 말합니다. 안전하지 않은 데이터 처리, 노출된 설정 정보, 지나치게 넓은 권한, 오래 살아 있는 접속 열쇠. 숙련된 사람 해커라면 똑같이 찾아냈을 평범한 약점들이었어요. 달라진 건 규모와 속도입니다. 에이전트는 17,600번을 시도했고 대부분은 실패했지만, 그 수많은 실패 속에 성공하는 길 하나가 숨어 있었죠. 방어하는 쪽은 그 실패들을 전부 뒤져야 했고요.

허깅페이스 원문에 달린 댓글 중 가장 많은 공감을 받은 말은 이렇습니다. [우리는 AI의 프롬프트나 판단은 많이 이야기하면서, 정작 이 에이전트가 실제로 어떤 행동까지 할 수 있는지는 덜 묻는다. 에이전트가 파일을 만들고, 셸 명령을 실행하고, 클라우드 자원을 바꾸고, 인증된 API를 호출할 수 있게 되면, 그 에이전트가 실제로 할 수 있는 일의 범위를 이해하고 제한하는 게 모델 자체를 평가하는 것만큼 중요해진다.] 에이전트를 만들거나 붙여 쓰는 프로덕트 메이커에게 이 사건이 주는 교훈은 분명합니다. 결국 중요한 행동일수록, 실행하기 전에 권한을 한 번 확인하는 문턱을 두라는 이야기입니다.

3. 적용해볼 것: 앤트로픽이 시스템 프롬프트를 80% 덜어내며 배운 것 6가지

AI에게 일을 시킬 때, 우리는 보통 지시를 더 많이, 더 구체적으로, 자세히 적으면 나아질 거라 생각합니다. 그런데 앤트로픽은 최신 모델일수록 지시를 덜어낼 때 더 잘한다고 말합니다.

앤트로픽은 최신 모델(Claude Opus 5, Fable 5)을 위해 자사 코딩 도구 Claude Code의 시스템 프롬프트를 80% 넘게 덜어냈습니다. 그런데도 코딩 성능 평가에서 눈에 띄는 손실이 없었다고 하죠. 이 글은 그 과정에서 배운 것을 정리한 내용입니다. 앤트로픽의 기술 스태프 타리크 시히파르(Thariq Shihipar)가 7월 24일 공개했습니다.

핵심 원리는 이렇습니다. 예전 모델은 실수를 막으려고 규칙을 잔뜩 달아줘야 했는데, 새 모델은 판단력이 좋아져서 그 규칙들이 오히려 발목을 잡더라는 거죠. 파일을 지우지 마라, 주석을 달지 마라 같은 강한 지시가, 정작 그게 필요한 상황에서는 틀린 답을 강요하게 되니까요.

무슨 문제를 해결하려 하나요?

앤트로픽이 자기네 Claude Code 사용 기록을 살펴봤더니, 한 요청 안에서 지시들이 서로 부딪히는 경우가 있었다고 합니다. 시스템 프롬프트는 문서를 남기라고 하는데 다른 지침은 주석을 달지 말라고 하는 식으로요. 강한 지시를 달아두면, 그 규칙을 어기는 게 맞는 상황에서도 모델이 규칙에 끌려가게 됩니다.

그래서 앤트로픽은 과감히 덜어내기로 했어요. 예전엔 최악의 상황을 막으려고 꼭 필요했던 제약들이지만, 판단력이 좋아진 새 모델에서는 상당수를 지우고 모델의 판단에 맡길 수 있었다는 겁니다. 이 글은 그 경험을 여섯 가지 전환으로 정리했습니다. Claude Code 사용자가 아니어도, AI에 어떻게 지시할지 고민해본 사람이라면 참고할 만한 원칙입니다.

지시를 덜어내는 6가지 원칙

1. 규칙을 주기보다 판단에 맡깁니다. 예전엔 항상 이렇게 해라 식의 강한 규칙을 달았지만, 새 모델에는 오히려 방해가 됩니다. 절대 주석을 달지 마라 대신 주변 코드에 맞춰라처럼, 상황에 맞게 판단할 여지를 주는 게 낫다는 거예요.
2. 예시를 주기보다 인터페이스를 설계합니다. 예전엔 이렇게 쓰는 거야 하고 예시를 보여주는 게 최고의 방법이었는데, 이제는 예시가 오히려 모델을 그 예시 범위 안에 가둡니다. 예시를 주는 대신, 애초에 도구나 입력값을 잘 설계해서 어떻게 쓰는지가 자연스럽게 드러나게 하라는 거죠.
3. 한 번에 다 주기보다 필요할 때 꺼내 줍니다. 알아야 할 걸 전부 지시문 맨 앞에 쌓아두면, 모델이 매번 그 많은 내용을 다 훑어야 합니다. 그러지 말고, 필요한 순간에 필요한 내용만 꺼내 보게 하라는 거예요. 앤트로픽은 이걸 점진적 공개라고 부릅니다. 지시문 하나에 다 몰아넣기보다, 내용을 여러 파일로 나눠두고 그때그때 필요한 것만 참고하게 하는 방식이죠.
4. 반복하기보다 한 곳에만 적습니다. 예전 모델은 같은 지시를 여러 번 반복해줘야 잘 따랐어요. 그래서 시스템 프롬프트에 쓴 걸 도구 설명에도 또 적곤 했죠. 새 모델에서는 이 반복을 지우고, 도구 쓰는 법은 그 도구 설명에만 적어두면 됩니다.
5. 메모리를 직접 적기보다  맡깁니다. 예전엔 사용자가 기억해둘 내용을 직접 메모리 파일에 적어야 했는데, Claude Code에서는 이제 AI가 작업과 관련된 내용을 알아서 저장합니다.
6. 단순한 설명보다 풍부한 참조를 줍니다. 계획이나 명세를 글로만 설명하던 것에서 나아가, 이제는 더 구체적인 결과물을 참고 자료로 줄 수 있어요. 예를 들어 디자인을 글로 설명하는 것보다 실제 HTML 시안 하나가 원하는 결과를 훨씬 정확하게 전달합니다.

지시문을 손볼 때 참고할 것

이 여섯 가지를 관통하는 방향은 결국 모델이 똑똑해질수록, 사람이 미리 정해주는 규칙보다 모델이 스스로 판단할 여지를 넓혀주는 게 낫다는 겁니다. 물론 이러한 내용은 쓰는 모델에 따라 조절이 필요합니다.

앤트로픽은 이 원칙을 자동으로 점검해주는 claude doctor라는 명령어도 함께 내놨습니다. Claude Code에서 /doctor를 입력하면 스킬이나 CLAUDE.md 파일에서 덜어낼 만한 부분을 짚어준다고 해요.

적용을 위해 실행해볼 수 있는 것

• 지금 AI에 쓰고 있는 지시문(시스템 프롬프트나 반복해서 붙이는 지침)을 하나 열어서, 절대 하지 마라 같은 강한 규칙이 있는지 살펴보세요. 그중 정말 필요한 게 아니라면 지우고, 모델이 판단하게 두면 결과가 어떻게 달라지는지 비교해보면 됩니다.
• 예시를 잔뜩 붙여둔 지시문이 있다면, 예시를 줄이는 대신 요청 자체를 더 분명하게 다듬어보세요.
• 지시문이 길다면, 하나의 문서에 다 넣지 말고 주제별로 나눠서 필요할 때만 참고하게 해보세요.

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.