프롬프트는 소모품이다. 스킬은 자산이다
팀에 AI 코딩 어시스턴트를 도입하고 나서 가장 먼저 드는 질문은 대개 이렇다. "이거 Cursor에서 잘 되던데, Claude Code에서는 왜 결과가 다르지?" 도구마다 프롬프트를 다시 쓰고, 컨텍스트를 다시 세팅하고, 결과를 다시 검증하는 일이 반복된다. 그리고 그 반복은 고스란히 팀의 시간을 갉아먹는다.
dev.to에 공개된 CoreLogic AI Skills 사례는 이 문제를 정면으로 건드린다. 개발자 Lokesh Agarwal이 만든 이 오픈소스 라이브러리의 핵심 아이디어는 단순하다. "같은 프롬프트를 반복해서 쓰는 대신, 워크플로우 자체를 재사용 가능한 스킬로 패키징하자." Build once. Use with any AI coding agent. 말은 쉽지만, 실제로 이 원칙을 지키는 팀은 드물다.
.NET 업그레이드를 해본 사람이라면 공감할 문제
구체적인 예시로 들어가 보자. AI에게 ".NET 애플리케이션을 업그레이드해줘"라고 물으면 돌아오는 답은 대개 비슷하다. "TargetFramework 바꾸고, NuGet 패키지 업데이트하고, 빌드하세요." 실제 프로덕션 업그레이드가 어떤 일인지 아는 개발자라면 이 답이 얼마나 불완전한지 바로 안다.
실제로는 현재 .NET 버전 파악, NuGet 의존성 분석, 취약 패키지 탐지, Deprecated 패키지 처리, Docker 이미지 업데이트, CI/CD 파이프라인 수정, 브레이킹 체인지 대응, 빌드·테스트·리포트 생성까지 이어지는 엔지니어링 워크플로우다. 이걸 프롬프트 하나로 해결하려는 시도 자체가 문제다.
CoreLogic의 dotnet-upgrade 스킬은 이 워크플로우를 4단계로 구조화한다. Phase 1에서 레포지토리를 분석하고 업그레이드 계획을 수립한다. 중요한 건 이 단계에서 코드를 단 한 줄도 수정하지 않는다는 것이다. Phase 2에서 분석 결과를 팀에 제시하고 명시적 승인을 받는다. Phase 3에서 승인된 계획대로 업그레이드를 실행한다. Phase 4에서 빌드·테스트·퍼블리시까지 검증하고 비교 리포트를 생성한다. "빌드 성공이 업그레이드 성공을 의미하지 않는다"는 전제가 설계에 녹아 있다.
이 설계에서 주목해야 할 것: 승인 게이트
사실 이 스킬의 기술적 완성도보다 더 눈에 띄는 건 승인 게이트(Approval Checkpoint) 설계다. AI가 자동으로 코드를 수정하기 전에 반드시 사람의 확인을 받도록 강제한다. 최근 배포 글에서도 에이전트의 위임 설계를 다룬 바 있지만, CoreLogic 사례는 그걸 실제 오픈소스 라이브러리로 구현했다는 점에서 실행 가능성이 다르다.
동일한 설계 원칙이 start-story 스킬에도 적용된다. Azure DevOps 워크 아이템에서 시작해 브랜치 생성, 구현 검증, PR 생성까지 이어지는 워크플로우인데, 여기서도 "잠재적으로 파괴적인 액션" 전에는 반드시 승인 체크포인트가 존재한다. 에이전트가 자율적으로 달리는 구간과 사람이 개입하는 구간을 명확히 나누는 것, 이게 팀 레벨 AI 운용의 핵심 설계 원칙이다.
포터블 스킬이 해결하는 현실 문제
또 하나 짚어야 할 부분은 플랫폼 이식성이다. Cursor는 Rules, Claude Code는 CLAUDE.md와 Commands, ChatGPT는 Custom Instructions, 그리고 일부 도구는 AGENTS.md를 쓴다. 도구마다 워크플로우를 새로 작성하면 팀은 도구에 종속된다. CoreLogic은 이 문제를 플랫폼 어댑터 방식으로 해결한다. 워크플로우 로직 자체는 동일하게 유지하되, 각 도구의 디스커버리 메커니즘만 어댑터로 교환한다. 팀이 Cursor에서 Claude Code로 이동할 때 워크플로우를 다시 작성할 필요가 없다.
기업 레벨에서 확인되는 같은 원칙
한국 마이크로소프트가 공개한 글로벌 프론티어 전환 사례들은 이 원칙이 기업 레벨에서 어떤 숫자를 만드는지 보여준다. EY는 15만 명에게 Microsoft 365 Copilot을 배포해 생산성 15% 향상, 리드타임 95% 단축, 재무 운영 비용 37% 절감을 달성했다. 나비엔은 연간 2만 8000시간을 절감했다. 방코 포퓰라르는 분석 역량을 7배 높이고 수작업을 70% 줄였다.
이 숫자들이 나올 수 있었던 공통 조건이 있다. AI를 단발성 도구로 쓰지 않고, 조직의 지능 자산으로 축적했다는 것. 워크플로우, 지식, 데이터를 하나의 플랫폼으로 연결해 AI의 가치가 모델 자체에 머무르지 않고 조직 내부에 쌓이도록 설계했다. MS가 말하는 "Intelligence Platform"의 실체는 결국 재사용 가능한 워크플로우의 체계적 축적이다.
팀에서 지금 당장 시작할 수 있는 것
거창하게 시작할 필요 없다. 팀에서 반복적으로 AI에게 묻는 질문 3가지를 골라보자. 코드 리뷰 체크리스트, 특정 기술 스택의 마이그레이션 가이드, PR 설명 자동화 같은 것들이다. 이걸 프롬프트 파일로 저장하고, 팀 레포에 버전 관리하고, 어떤 AI 도구에서도 불러올 수 있도록 어댑터를 만드는 것—그게 AI 스킬을 설계 자산으로 만드는 첫 걸음이다.
앞으로 주목할 방향
CoreLogic이 로드맵으로 공개한 스킬 목록을 보면 팀에서 AI 자동화가 어디로 향하는지 가늠할 수 있다. SQL Performance Review, Architecture Review, Security Audit, CI/CD Pipeline Review, Dependency Modernization. 이것들은 지금까지 시니어 엔지니어의 수작업 영역이었다. 이 워크플로우들이 재사용 가능한 스킬로 패키징되면, 시니어의 판단 기준이 팀 전체의 기본값이 된다.
그게 AI-First 팀 리빌딩의 핵심 가치 제안이다. AI가 시니어를 대체하는 게 아니라, 시니어의 워크플로우를 설계 자산으로 만들어 팀 전체의 기준선을 올리는 것. 프롬프트를 반복하는 팀과 스킬을 자산으로 쌓는 팀의 격차는, 도구 도입 초기에는 보이지 않지만 6개월이 지나면 복리로 벌어진다.