AI에게 반복되는 일을 맡기려고 작업 설명서를 파일로 만들어 두는 분이 많아졌습니다. 이런 파일을 스킬이라고 부릅니다. 덱을 만드는 순서, 보고서를 쓰는 틀 같은 것을 적어 두면 AI가 필요할 때 알아서 꺼내 쓰는 방식입니다. AI는 각 스킬에 붙은 짧은 설명을 보고, 지금 요청에 맞는 스킬이 있으면 꺼냅니다. 저도 그렇게 25개를 만들었습니다.
기록이 온전히 남아 있는 열흘을 골라 주로 쓰는 AI 도구에서 세어 보니, 꺼내 쓴 스킬은 3개였습니다. 가장 공들인 덱 스킬은 덱 얘기가 수십 번 나오는 동안 한 번 쓰였습니다. 저는 AI가 스킬을 못 찾는 줄 알았습니다. 그래서 설명을 고쳤는데, 고친 뒤 한 달 동안 덱 스킬은 제가 쓰는 AI 도구 두 곳 어디에서도 한 번도 쓰이지 않았습니다.
원인은 다른 데 있었습니다. 덱 요청을 하나씩 읽어 보니, 제가 그 일을 시킨 적이 거의 없었습니다.
강연은 코드 대신 파일을 주면 AI가 알아서 고른다고 말합니다
이 문제를 다시 꺼내게 된 계기는 2026년 AI Engineer World's Fair에서 Google DeepMind의 Philipp Schmid가 한 18분짜리 발표였습니다. 제목은 “Agents Without Code”입니다.
발표는 GitHub의 코드 변경 요청을 검토하는 에이전트를 세 번 만듭니다. 첫 번째는 파이썬으로 직접 짠 반복문이고, 두 번째는 에이전트 프레임워크를 씁니다. 세 번째에서는 코드 폴더가 아예 사라지고 지시문 파일 한 장만 남습니다. 발표자는 에이전트에게 GitHub 명령줄 도구와 파일 시스템이 있으니 알아서 쓰라고만 적어 둡니다(09:43).
기능을 늘리는 방법도 같습니다. 코드를 고치지 않고 스킬 파일을 하나 더 주면, 무엇을 할지는 에이전트가 정한다는 설명입니다(14:57). 사례로 Cursor 팀이 TypeScript 1만 2천 줄을 200줄짜리 스킬 파일로 바꾼 일을 듭니다.
방향에는 저도 동의합니다. 다만 제 경험에서는 그다음 단계가 막혔습니다. 스킬을 주는 것까지는 쉬웠는데, AI가 그걸 꺼내 쓰는 일은 잘 일어나지 않았습니다.
처음에는 스킬 설명에 제 말투가 없어서라고 생각했습니다
두 달 동안 제가 AI에게 보낸 요청 5,218건을 모았습니다. 다만 AI가 무엇을 했는지까지 온전히 남은 기록은 그중 마지막 열흘(8월 14일부터 23일까지)뿐이었습니다. 그 열흘 동안 AI는 파일을 읽거나 명령을 실행하는 식으로 도구를 1만 700번 썼고, 그 가운데 스킬을 꺼낸 것은 43번이었습니다. 꺼낸 스킬은 25개 중 3개였습니다. 아래 숫자는 모두 이 열흘 기준입니다.
쓰인 스킬에는 공통점이 있어 보였습니다. 설명 안에 “덱 만들어줘”처럼 제가 실제로 하는 말이 적혀 있었습니다. 강의 몰입 장치를 설계하는 스킬은 그런 예시가 12개 있었고 8번 쓰였습니다. 반대로 덱을 만드는 스킬은 설계를 가장 공들였는데도 기능 설명만 있었습니다. 같은 열흘 동안 제 요청에 덱 관련 단어가 49번 나왔는데, 이 스킬은 한 번 쓰였습니다.
그래서 덱 스킬 설명에 제가 실제로 쓰는 말 11개를 넣었습니다. “덱 만들어줘”, “ppt로 만들어줘”, “장표 추가해줘” 같은 문장입니다.
막힌 곳: 설명을 고친 뒤에도 덱 스킬은 한 번도 쓰이지 않았습니다
설명을 고치고 30일이 지난 뒤 다시 셌습니다. 이번에는 단어가 나온 횟수가 아니라 요청 건수로 셌습니다. 그 사이 대화 513개에서 덱 관련 단어가 한 번이라도 들어간 요청은 29건이었습니다. 앞의 49는 단어가 나온 횟수라 한 요청에서 여러 번 셀 수 있었고, 29는 요청 하나를 한 번만 센 숫자입니다. 그 29건 뒤에 AI가 덱 스킬을 꺼낸 횟수는 0이었습니다. 대신 대부분 곧바로 명령어를 실행하거나, 이미 만들어 둔 덱 생성 스크립트를 직접 돌렸습니다.
함께 쓰는 다른 AI 코딩 도구인 Codex의 같은 30일 기록도 봤습니다. Codex는 스킬을 꺼내는 별도 동작이 없고, 스킬 파일을 직접 열어 읽는 것이 곧 쓰는 것입니다. 두 도구가 같은 스킬 파일을 읽으니 고친 설명도 똑같이 보입니다. 대화 36개 가운데 24개가 어떤 스킬이든 스킬 파일을 열어 읽었는데, 덱 스킬 파일을 연 대화는 없었습니다. 설명이 문제라면 이번에는 어느 한쪽에서라도 쓰였어야 합니다. 그래서 숫자를 믿는 대신 29건을 하나씩 읽었습니다.
절반 넘게는 이미 있는 PPT를 자료로 삼거나 검토하는 요청이었습니다. “ppt 수정은 안 할 거고 실습에서 커버해 줘”, “ppt 내용이 스토리보드에 안 들어갔어” 같은 말입니다. 다섯 건은 이미 있는 덱의 한 장을 고치거나 다른 양식으로 옮기는 일이었습니다. 새 덱을 처음부터 만들어 달라는 요청은 한 건뿐이었고, 그마저 결과물이 덱인지 웹 페이지인지 분명하지 않았습니다.
덱 스킬은 여러 단계를 거쳐 새 덱을 처음부터 만드는 순서로 짜여 있습니다. 고치는 요청 다섯 건은 이미 있는 덱의 한 장이나 양식만 건드리는 일이라, 처음부터 다시 짜는 순서가 맞지 않았습니다. 제가 실제로 한 일은 그게 아니었습니다. AI가 스킬을 못 찾았다기보다, 쓸 자리가 거의 없었던 겁니다.
되돌린 결정: 단어로 센 기회를 버리고 요청을 읽어서 세기로 했습니다
돌아보면 처음 숫자부터 부풀려져 있었습니다. 덱 관련 단어가 49번 나왔다는 건 기회가 49번 있었다는 뜻이 아니었습니다. 이번 29건에서도 한 건은 OpenAI의 코딩 도구 이름인 ‘코덱스’의 ‘덱’에 걸린 것이었으니까요.
같은 착시가 반대쪽에도 있었습니다. 한 번도 안 쓰였다고 분류한 스킬 가운데 7개는 제가 함께 쓰는 다른 AI 코딩 도구에서 실제로 쓰이고 있었습니다. 앞에서 말한 ‘25개 중 3개’도 한쪽 도구의 기록만 센 숫자였던 셈입니다. 그 7개에 덱 스킬은 없었고, 덱 스킬은 앞서 본 대로 두 도구 모두에서 쓰이지 않았습니다. 더 눈에 띄는 것은 그 7개의 설명에 제 말투 예시가 하나도 없었다는 점입니다. 예시 없이도 할 일이 있으면 쓰였던 겁니다. 세는 방법이 틀리면, 안 쓰인 이유도 틀리게 찾게 됩니다.
세는 방법이 틀리면, 안 쓰인 이유도 틀리게 찾게 됩니다.
인간 중심 설계 표준은 과업을 먼저 이해하라고 합니다
사람을 위한 도구를 만들 때 이 문제는 오래전에 정리돼 있습니다. 인간 중심 설계 표준인 ISO 9241-210은 원칙 가운데 하나로, 설계가 사용자와 과업과 환경에 대한 명시적인 이해에 기반해야 한다고 적어 둡니다.
사람을 위한 도구라면 이 원칙은 비교적 자연스럽게 지켜집니다. 만들기 전에 그 일을 하는 사람을 보고, 만든 뒤에는 쓰는지 안 쓰는지가 눈에 보이니까요. 안 쓰는 도구는 동료가 먼저 말해 줍니다.
AI에게 주는 스킬은 이 둘이 모두 흐려집니다. 저는 제가 할 법한 일을 상상해서 스킬을 썼습니다. 새 덱을 처음부터 만드는 일은 머릿속에서는 자주 있었지만, 실제 요청에는 없었습니다. 그리고 AI는 안 쓰는 스킬에 대해 아무 말도 하지 않습니다. 쓰이지 않은 스킬들은 두 달 동안 조용히 있었습니다.
발표도 마지막 장에서 비슷한 말을 합니다. 가운데 카드 “Own What is Yours”에는 지시문과 작업 흐름을 담은 스킬 파일, 그리고 평가 세트에 집중하고 결과를 엄격하게 확인하라고 적혀 있습니다. 제 경우 그 평가는 AI의 실력을 재는 일이 아니었습니다. 제가 실제로 무슨 일을 시키는지를 세는 일이었습니다.
아직 남은 문제: 설명문 예시의 효과는 아직 모릅니다
이번 분석은 덱 스킬 하나, 30일 한 구간이고, 29건을 나눈 것은 제 판단입니다. 다른 AI 도구에서는 스킬 파일을 열었는지만 봤고, 그쪽 요청은 읽지 않았습니다. 나머지 안 쓰인 스킬들도 같은 이유인지는 아직 하나씩 읽어 보지 않았습니다.
더 중요한 빈칸도 있습니다. 처음에 저는 예시가 있는 스킬이 더 쓰였다고 봤습니다. 그런데 그 스킬들은 제가 실제로 자주 시키는 일이기도 했습니다. 예시 덕분에 쓰인 건지, 그냥 수요가 있어서 쓰인 건지 지금 자료로는 가를 수 없습니다.
덱 스킬을 어떻게 할지도 정하지 못했습니다. 실제로 반복된 일은 이미 있는 덱을 고치는 일이었으니, 그 일에 맞게 다시 쓸지, 그냥 둘지 고민하고 있습니다.
마치며: ‘AI가 꺼내 쓰나’가 아니라 ‘내가 그 일을 시켰나’
스킬이 안 쓰일 때 저는 AI를 먼저 의심했습니다. 설명을 고치고, 예시를 더 넣었습니다. 정작 먼저 봐야 할 것은 제 요청이었습니다.
안 쓰이는 스킬이 있다면 그 스킬과 관련된 최근 요청 스무 개를 골라 하나씩 읽어 보시길 권합니다. Claude Code는 홈 폴더의 .claude/projects 아래에, Codex는 .codex/sessions 아래에 대화마다 기록 파일을 남깁니다. 그 파일에서 스킬 이름을 찾으면 쓰였는지가 보이고, 관련 단어로 찾으면 요청 후보가 모입니다. 단어 검색은 후보를 모으는 데까지만 쓰고, 판정은 한 건씩 읽어서 하시길 권합니다. 그 스킬이 할 일이 실제로 몇 번이나 있었는지 세어 보면, 고칠 곳이 설명인지 스킬 자체인지가 보일 겁니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- Philipp Schmid, “Agents Without Code: Skills, YAML, and Filesystems Replaced Python”, AI Engineer, 2026: https://www.youtube.com/watch?v=fjF8EKnxKCU
- ISO 9241-210:2019 Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems: https://www.iso.org/standard/77520.html