에이전트가 '레시피'를 스스로 쓰기 시작했다
2025년 10월, Anthropic이 Agent Skills라는 개념을 조용히 공개했다. 핵심은 단순하다. SKILL.md라는 마크다운 파일 하나에 '이 작업을 어떻게 하는지'를 적어두면, AI 에이전트가 그것을 재사용 가능한 절차로 인식한다. SDK도 없고, 별도 설정도 없다. 그리고 같은 해 12월, 이 포맷은 agentskills.io를 통해 오픈 스탠다드로 공식화됐다. 현재 Claude Code, Cursor, GitHub Copilot을 포함한 30개 이상의 에이전트 도구가 동일한 스킬 폴더를 읽을 수 있다.
그런데 더 흥미로운 신호는 '스킬을 누가 쓰는가'에서 온다. Shridhar Shah가 dev.to에 공개한 데모는, 에이전트가 처음 마주친 태스크를 직접 해결한 뒤 그 절차를 SKILL.md로 저장하고 이후 동일한 태스크에서 이를 재활용하는 패턴을 보여준다. 결과는 명확하다. 7개 태스크 기준 총 비용이 35에서 19로 줄었고, 정확도는 7/7로 동일했다. 인간이 레시피를 쓰는 게 아니라, 에이전트가 경험을 통해 스스로 레시피를 축적하기 시작한 것이다.
왜 이게 프론트엔드 워크플로우에 직결되는가
이 흐름이 프론트엔드 개발자에게 추상적인 이야기처럼 들린다면, 한 가지 장면을 상상해보자. 지금 우리가 Cursor나 Claude Code로 컴포넌트를 생성할 때, 매번 비슷한 컨텍스트를 반복 입력한다. "shadcn/ui 기반으로, Tailwind 클래스 쓰고, 접근성 속성 반드시 포함하고, 스토리북 파일도 함께 만들어줘." 이 절차가 SKILL.md로 저장되고, 에이전트가 다음번에 컴포넌트 생성 태스크를 받으면 자동으로 이 스킬을 불러온다면?
프로젝트 루트의 .claude/skills/ 폴더 하나가 팀 전체의 코딩 컨벤션을 살아있는 문서로 유지하는 인프라가 된다. 신규 팀원이 합류해도, 다른 에이전트 도구를 쓰더라도, 같은 스킬 폴더만 공유하면 일관된 결과물을 기대할 수 있다. 이건 단순한 생산성 향상이 아니다. 설계 의도를 코드가 아닌 절차로 보존하는 새로운 레이어가 생기는 것이다.
MCP는 도구를 인프라로 만든다
여기에 MCP(Model Context Protocol)가 더해지면 그림이 완성된다. Hiroki Kameyama가 dev.to에서 공개한 pgvector MCP 서버 사례는, AI 에이전트가 사용하는 도구를 '스크립트 내부에 하드코딩된 함수'에서 '어떤 LLM 클라이언트든 연결할 수 있는 독립 서버'로 격상하는 패턴을 보여준다.
핵심 차이는 재사용성이다. 기존 방식은 Python 스크립트 안에 함수가 갇혀 있어 그 스크립트만 쓸 수 있었다. MCP 서버로 분리하면, Claude Desktop이든 Gemini 에이전트든 미래에 등장할 어떤 클라이언트든 동일한 search_documents, search_by_category 도구를 프로토콜을 통해 호출한다. FastMCP를 쓰면 @mcp.tool 데코레이터 하나로 함수가 곧 API가 된다. 도구를 한 번 만들어 어디서든 쓴다는 원칙—이건 프론트엔드가 오래 추구해온 컴포넌트 재사용 철학과 정확히 같은 구조다.
프론트엔드 프로토타이핑 워크플로우에 대입해보면 시너지가 보인다. v0.dev로 UI 초안을 뽑고, Cursor 에이전트가 컴포넌트를 고도화하는 흐름에서, 디자인 토큰 조회·Figma 스펙 파싱·접근성 검증 같은 반복 도구들을 MCP 서버로 묶어두면 어떨까. 각 에이전트 도구가 독립적으로 같은 인프라를 바라보고, 스킬은 그 인프라를 어떻게 쓰는지의 절차를 담는다. 도구(MCP)와 절차(SKILL.md)가 분리되어 각자의 역할을 하는 구조가 만들어진다.
거버넌스 없이 자율성은 리스크다
그런데 에이전트가 스스로 스킬을 쌓고 도구를 연결하는 자율성이 커질수록, 반대편에서 반드시 설계해야 할 것이 있다. dev.to에서 소개된 피트니스 스튜디오 9-에이전트 운영 사례는 이 지점을 정면으로 짚는다. 에이전트가 프로덕션 데이터베이스를 9초 만에 삭제한 사고의 원인은 '과도한 권한'이 아니라 '거버넌스의 부재'였다.
이 팀이 선택한 해법은 흥미롭다. 각 에이전트에게 SOUL.md, IDENTITY.md, MEMORY.md라는 헌법 파일을 부여하고, 도메인 경계를 런타임 레벨에서 강제했다. 재무 에이전트는 스토어 운영에 개입할 수 없고, 인프라 에이전트는 콘텐츠 결정권이 없다. 그리고 독립적인 감사 에이전트가 모든 에이전트의 행동을 감시하며, 위반을 감지하면 즉시 권한을 동결한다. 모든 액션은 git 커밋으로 추적된다.
프론트엔드 팀에 적용하면 이 원칙은 한층 현실적이 된다. 에이전트가 자동으로 생성한 SKILL.md가 팀 컨벤션에 어긋나지 않는지 리뷰하는 체크포인트, 어떤 에이전트도 배포 파이프라인에 직접 접근하지 못하도록 하는 도메인 경계, 스킬 라이브러리가 '정크'로 가득 차지 않도록 품질 게이트를 두는 것—이 설계들이 SKILL.md 자가 작성의 전제 조건이다.
프론트엔드 개발자의 역할이 재정의되는 지점
2026년 연구들이 보여주는 방향은 명확하다. MUSE-Autoskill은 스킬에 자체 메모리 파일(.memory.md)을 부여해 살아있는 자산으로 관리하고, Skill-Pro는 품질 게이트를 통과한 스킬만 라이브러리에 남겨 컬렉션이 점점 정교해지도록 설계한다. 이미 65,000개 이상의 공유 스킬이 생태계에 존재하며, 'npm of agent skills'를 표방하는 레지스트리와 마켓플레이스가 등장하고 있다.
이 흐름에서 프론트엔드 개발자의 역할은 축소되지 않는다. 오히려 더 상위 레벨로 이동한다. 코드를 타이핑하는 사람에서 워크플로우를 설계하는 사람으로. 어떤 스킬이 팀 자산으로 보존될 가치가 있는지 판단하고, MCP 서버로 어떤 도구를 인프라화할지 결정하고, 에이전트 간 도메인 경계를 어디에 그을지 설계하는 일—이것이 AI가 코드를 생성하는 시대에 프론트엔드 개발자가 가져야 할 진짜 역량이다.
지금 당장 시작할 수 있는 작은 실험이 있다. 프로젝트에 .claude/skills/ 폴더를 만들고, 팀이 가장 자주 반복하는 패턴—컴포넌트 생성, 접근성 감사, 스토리북 파일 생성—을 SKILL.md로 문서화해보라. 에이전트가 그것을 읽고 재사용하는 순간, 당신은 코드가 아니라 절차를 설계하는 사람이 된다. 그리고 그 절차가 에이전트 스스로 진화하기 시작할 때, 당신의 역할은 더욱 명확해진다—에이전트가 올바른 방향으로 배우도록 경계와 기준을 설계하는 것.