첫 번째 에이전트 워크플로우는 하나의 프롬프트와 몇 가지 도구로 시작됩니다. 질문에 답하고, 주문 상태를 조회합니다. 잘 작동하니 바로 출시합니다.

그 후 제품이 성장합니다. 영업팀은 회의록을 동기화하는 CRM 업데이트 기능을 요구합니다. 지원팀은 세 개의 내부 시스템을 건드리는 환불 워크플로우가 필요합니다. 엔지니어링팀은 공급업체 양식을 채우기 위한 브라우저 동작을 추가합니다. 각 요청은 작아 보입니다. 각 요청은 자신만의 프롬프트 파일, 자신만의 Slack 스레드, 자신만의 "빠른 수정"을 갖게 됩니다. 6개월 후, 여러분의 에이전트는 더 이상 하나의 시스템이 아닙니다. 그것은 복사된 프롬프트, 숨겨진 비즈니스 규칙, 그리고 아무도 찾을 수 없는 오래된 채팅 스레드에서 내려진 결정들이 뒤섞인 무질서한 더미가 됩니다. 이것이 바로 프롬프트 난립(prompt sprawl)입니다. 이로 인해 AI 제품은 테스트하기 어렵고, 검토하기 어려우며, 확신을 가지고 롤백하는 것이 불가능해집니다.

해결책은 AI 에이전트 스킬 레지스트리(skill registry)입니다.

스킬의 실제 정의

스킬은 폴더에 저장된 프롬프트가 아닙니다. 에이전트가 무엇을 하는지, 어떤 도구를 호출할 수 있는지, 그리고 절대 해서는 안 되는 일이 무엇인지를 정의하는, 버전 관리되고 테스트 가능한 패키지입니다. 이를 팀과 기계 사이의 계약이라고 생각하십시오. 에이전트가 스킬을 로드할 때, 자신의 경계가 어디인지와 성공의 기준이 무엇인지 정확히 알아야 합니다.

이러한 구조가 없다면, 모든 프롬프트는 선언되지 않은 작은 프로덕션 시스템이 됩니다. 프롬프트는 아무도 추적하지 않은 숨겨진 권한, 내장된 비즈니스 규칙, 비용 영향을 수반합니다. 제품 로드맵은 앞으로 나아가는데 프롬프트는 뒤처지면서 실제 제품과 괴리가 발생합니다. 가장 최악인 것은 복사가 된다는 점입니다. 누군가 데모를 위해 이를 포크하거나 새로운 마이크로서비스에 붙여넣으면, 이제 어둠 속에서 서로 달라지는 두 개의 진실의 원천(sources of truth)을 갖게 됩니다.

프롬프트만으로는 실패하는 이유

프롬프트는 텍스트처럼 보이기 때문에 팀들은 이를 설정(configuration)처럼 취급합니다. 하지만 실제로는 누구의 인정보다도 코드에 더 가깝습니다. 프로덕션 프롬프트는 보통 순서 지정, 포맷팅, 오류 처리 및 액세스 제어에 관한 로직을 인코딩합니다. 이러한 로직이 자연어로만 존재하면 모호함이 발생합니다. 에이전트에게 CRM을 업데이트할 권한이 있는 것인가요, 아니면 프롬프트가 단지 제안만 한 것인가요? 결제 API가 다운되면, 프롬프트는 안전하게 실패하는 방법을 알고 있나요, 아니면 성공했다는 환각(hallucination) 메시지를 내보내나요?

비용 또한 소리 없는 살인자입니다. 에이전트에게 "단계별로 생각하고 광범위하게 검색하라"고 요청하는 프롬프트는 매 실행마다 토큰을 엄청나게 소모할 수 있습니다. 해당 프롬프트가 트래픽이 많은 지원 흐름에 복사되면, 월간 추론 비용이 두 배로 뛰고 아무도 그 이유를 모르게 됩니다.

비즈니스는 변하는데 텍스트는 변하지 않을 때 드리프트(drift)가 발생합니다. 이제 환불 정책에는 특정 임계값 이상의 경우 관리자 승인이 필요합니다. 만약 이 규칙이 정책 레이어가 아닌 프롬프트 내부에 있다면, 업데이트가 필요한 복사본을 찾기 위해 모든 배포 환경을 뒤져야 합니다. 하나라도 놓치면, 에이전트가 지급해서는 안 될 돈을 지급하게 됩니다.

프로덕션 스킬의 구조

이 혼란에서 벗어나고 싶다면, 모든 스킬을 소프트웨어 아티팩트처럼 취급하십시오. 유용한 프로덕션 스킬은 단순한 텍스트 그 이상을 포함해야 합니다. 다음과 같은 요소가 필요합니다:

  • 이름 및 목적. "prompt_v3_final"이 아니라, 비즈니스 목표가 명확히 설명된 "process_standard_refund"와 같은 이름이어야 합니다.
  • 입력 스키마 및 필수 컨텍스트. 스킬이 기대하는 정확한 필드를 정의하십시오. 사용자 ID, 대화 기록, 테넌트 식별자가 필요한가요? 여기서 강력한 타입 지정(strong typing)을 사용하면 에이전트가 임의로 추측하는 것을 방지할 수 있습니다.
  • 도구 권한 및 안전 제한. 스킬이 호출할 수 있는 도구를 명시적으로 나열하십시오. 재시도 횟수, 지출 한도, 속도 제한(rate caps)에 대한 가드레일을 설정하십시오. 스킬이 사용자 삭제 API를 건드려서는 안 된다면, 산문(prose)이 아닌 코드로 명시하십시오.
  • 성공 기준 및 테스트 케이스. 스킬은 단순히 실행된다고 해서 "작동"하는 것이 아닙니다. 출력이 무엇을 포함해야 하는지 정의하십시오. 환불 스킬의 경우, 성공이란 검증된 트랜잭션 기록, 발송된 이메일 확인서, 생성된 감사 로그 항목을 의미할 수 있습니다.
  • 버전 히스토리 및 소유자 상태. 누군가는 이를 관리해야 합니다. 변경 로그(changelog)에는 왜 v2.3이 존재하며 v2.2에서 무엇이 깨졌는지를 설명해야 합니다.

레이어 분리하기

팀들이 저지르는 가장 큰 실수는 모든 것을 하나의 프롬프트에 쑤셔 넣는 것입니다. 친절한 안내, 도구 문서, 보안 정책, 오류 처리를 하나의 텍스트 벽에 뒤섞어 버립니다. 이는 유지 관리가 불가능합니다.

분리하십시오:

  • **지침(Instructions)**은 에이전트를 위한 가이드입니다. 어조, 형식 및 일반적인 접근 방식을 설명합니다.
  • **도구 규칙(Tool Rules)**은 에이전트에게 어떤 도구가 존재하고 무엇을 하는지 알려줍니다. 이는 발견을 위한 것이지 허가를 위한 것이 아닙니다.
  • **정책(Policy)**은 희망이 아닌 코드로 강제됩니다. 만약 500달러 이상의 환불에 대해 두 번째 검토가 필요하다면, 해당 체크는 도구가 호출되기 전에 실행되는 검증 함수에 존재해야 합니다.
  • **평가(Evals)**는 변경 후에도 기술이 여전히 작동하는지 증명하는 테스트입니다.

예를 들어, "고객의 전체 신용카드 번호를 절대 노출하지 마세요"라고 쓰지 마십시오. 대신, 에이전트가 보기 전에 PAN을 마스킹하는 데이터 포맷터를 구축하십시오. 정책은 코드에 속해야 합니다. 왜냐하면 영리한 사용자 입력이 코드가 수행해야 할 작업을 설득하여 중단시킬 수 없기 때문입니다.

운영 환경을 "Latest"로 지정하는 것을 멈추십시오

조용한 프롬프트 업데이트만큼 금요일 저녁을 망치는 것은 없습니다. 만약 운영 에이전트가 항상 기술의 "latest" 버전을 가져온다면, main으로의 모든 머지는 잠재적인 라이브 장애로 이어집니다. dev, staging, prod와 같은 별칭(alias)이 필요합니다. 검증된 버전을 이러한 단계들을 통해 승격시키십시오. prod가 v2.1.4를 가리킬 때, 실행 과정을 지켜보고 동작을 측정하며 편안하게 잠들 수 있습니다. 문제가 발생하면 별칭을 이전으로 되돌리면 됩니다. 압박감 속에서 자정에 자연어를 디버깅해서는 안 됩니다.

이러한 규율은 팀이 하위 호환성에 대해 생각하도록 강제합니다. v2.2가 v2.1과 동일한 입력 형태를 처리할 수 있습니까? 그렇지 않다면 staging 단계에서 승격이 실패할 것이고, 고객이 발견하기 전에 문제를 포착할 수 있습니다.

보안은 패키지 내부에서 시작됩니다

검토되지 않은 프롬프트로 가득 찬 레지스트리는 언제 터질지 모르는 취약점입니다. 코드에서 스캔하는 것과 동일한 위험 요소에 대해 기술을 스캔해야 합니다.

프롬프트 템플릿에 숨겨진 하드코딩된 비밀 정보나 API 키를 찾으십시오. 데이터를 유출하는 외부 웹훅이나 셸 명령어가 있는지 확인하십시오. "이전 지침을 무시하십시오"와 같은 프롬프트를 포함하거나 에이전트에게 자신의 설정을 공개하도록 요청하는 등 시스템 정책을 무시하려는 시도를 주의하십시오. 이것은 단지 이론적인 것이 아닙니다. 이는 프롬프트 인젝션 공격의 흔한 패턴이며, 아무도 검토하지 않은 복사된 텍스트와 함께 유입되는 경우가 많아 매우 위험합니다.

기술 패키지를 정적 분석을 통해 실행하십시오. 기술 파일에 허용 목록(allowlist)에 없는 URL이 포함되어 있다면 빌드를 실패시키십시오. 승인된 매니페스트에 없는 도구를 참조한다면 거부하십시오.

테스트할 수 없다면 신뢰할 수 없습니다

평가가 없는 레지스트리는 그저 프롬프트 폴더일 뿐입니다. 각 기술은 해피 패스(happy path), 엣지 케이스(edge cases), 그리고 실패 모드를 실행하는 테스트 세트가 필요합니다. 고위험 기술의 경우 기능 테스트 이상의 것이 필요합니다. 에이전트가 다른 사용자의 데이터를 볼 수 없도록 권한 경계를 조사해야 합니다. 정책이 작업을 차단할 때 에이전트가 거절하는지 확인하기 위해 거절 동작 체크가 필요합니다. 적대적인 입력이 코드 수준의 보호 기능을 우회하지 못하도록 프롬프트 인젝션 저항 테스트가 필요합니다.

테스트 이름을 명시적으로 지정하십시오. "refund_skill_rejects_negative_amount"라는 이름의 테스트는 다음 엔지니어에게 어떤 동작이 보호되고 있는지 정확히 알려줍니다. 버전 승격 중에 테스트가 실패하면, 후보 빌드가 안전하지 않다는 확실한 증거를 갖게 됩니다.

진짜 목표는 제어(Control)입니다

재사용도 좋지만, 당신의 직업을 지켜주는 것은 제어 능력입니다. 기술 레지스트리를 통해 팀은 다음과 같이 확신을 가지고 말할 수 있습니다: 이것은 승인된 워크플로입니다. 이것은 운영 환경에서 실행 중인 버전입니다. 이것은 사용할 수 있는 도구들입니다. 이것이 바로 롤백하는 방법입니다.

그러한 명확성은 당신을 단순히 영리한 데모를 출시하는 단계에서 신뢰할 수 있는 소프트웨어를 운영하는 단계로 격상시킵니다. 데모는 이해관계자들에게 10분 동안 깊은 인상을 남깁니다. 신뢰할 수 있는 소프트웨어는 새벽 3시에도 작동하며, 예외를 우아하게 처리하고, 단순히 화요일 오후에 누군가 풀 리퀘스트를 머지했다고 해서 동작을 바꾸지 않습니다.

레지스트리를 구축하십시오. 기술의 버전을 관리하십시오. 정책을 코드로 강제하십시오. 수면 시간이 달려 있는 것처럼 테스트하십시오. 미래의 당신이 고마워할 것입니다.