재사용 가능한 AI 스킬을 생성 코드 및 출력 검사에 연결하는 방법

실패는 생성에 도달하는 가이드에서 발생했다

Launcherry의 채널들을 검토했을 때, 저는 생성 워크플로우와 초안의 일부 부분에서 플랫폼 가이드가 누락되어 있다는 것을 발견했습니다. 또한 독자에게 유용한 다음 단계를 제시하기보다는 내부 목표 레이블을 반복하는 내용도 있었습니다. 저는 전문 지식이 어떻게 생성 단계에 도달해야 하는지 고치는 것이 필요했습니다. 단순히 카피의 유창성만 개선해서는 두 가지 문제 모두 해결할 수 없었습니다.

저는 연구된 전문 지식을 제품이 결과물을 생성하는 순간까지 전달할 방법이 필요했습니다. 그래서 저는 재사용 가능한 AI 스킬 라이브러리를 구축했습니다: 공유 코어와 계획, 작성 및 에셋 디렉션을 위한 16개의 채널별 파일로 구성되어 있습니다. 이 라이브러리는 로컬 개발 환경에 구현되었으며, 공개 사용 가능 여부는 출시 및 채널 상황에 따라 달라집니다.

모델이 가이던스를 받는지에 대한 증거가 필요합니다. 문서만으로는 그것을 확립할 수 없습니다. 모델이 이를 받는다고 해서 결과 캠페인이 유용하다는 것을 의미하지도 않습니다. 저는 작성(authoring), 통합(integration) 및 평가(evaluation)를 별개의 책임으로 다루었으며, 각각 고유한 증거가 필요했습니다.

사람이 필요한 결과물부터 시작하기

저의 출발점은 플랫폼과 전달 유형이었습니다. 오가닉 게시물, 유료 광고, 짧은 비디오 스크립트는 작업에 서로 다른 요구 사항을 제시합니다. 작가는 청중이 무엇을 접하게 될지, 형식이 무엇을 담을 수 있는지, 그리고 어떤 다음 행동이 커뮤니케이션에 적합한지를 이해해야 합니다. 일반적인 지침에 플랫폼 이름만 붙이는 것으로는 이 모든 것을 표현할 수 없습니다.

저는 개별 채널의 요구 사항을 조사하여 출력과 연결된 가이드로 만들었습니다. Launcherry 라이브러리에서, 채널별 자료는 앵글(angle), 작성 및 에셋을 지원합니다. 공유 표준은 이러한 단계 전반에 걸쳐 일관성을 제공합니다. 이를 통해 각 파일이 전체 제품 철학을 반복할 필요 없이 생성 워크플로우에 관련성 있는 가이던스를 부여할 수 있습니다.

다른 팀의 경우, 가장 피할 수 있는 재작업을 유발하는 반복적인 결과물부터 시작할 것입니다. 그 청중(audience), 목적(purpose), 제약 조건(constraints)을 정의한 다음, 실제 실패 사례를 검사합니다. 스킬은 이러한 반복되는 작업을 해결할 때 자리를 얻습니다. 증거는 단순히 파일이 존재한다는 것을 보여주기보다는 왜 가이드가 필요한지를 설명해야 합니다.

공통 표준과 채널별 판단 분리하기

공유 코어(shared core)는 일관성을 유지해야 하는 표준을 위한 장소를 제공합니다. 채널 파일(channel files)은 결과물을 목적지에 적합하게 만드는 차이점들을 담고 있습니다. 이러한 분리는 작성 방식의 선택일 뿐만 아니라 유지보수(maintenance)상의 선택이기도 합니다. 공통 요구사항은 하나의 거처를 가지는 반면, 채널별 수정 사항은 해당 채널에 국한되어 남아 있을 수 있습니다.

또한 저는 이 분리를 사용하여 의견 불일치(disagreements)를 진단할 수도 있습니다. 만약 모든 채널이 동일한 종류의 미흡한 다음 단계(weak next step)를 생성한다면, 공유 가이드와 주변 생성 워크플로우(generation workflow)를 검토해야 합니다. 문제가 특정 전달 형식(delivery format)에 속하는 경우, 해당 전문 가이드가 더 관련성 높은 시작점이 됩니다. 규칙의 위치는 그 범위(scope)를 반영해야 합니다.

저는 이러한 자산들을 재사용 가능한 도메인 스킬(reusable domain skills)이라고 설명합니다. Launcherry는 자체 생성 코드에 가이드를 로드합니다. 이는 모든 파일이 모든 코딩 에이전트(coding agent)를 위한 드롭인 패키지라고 주장하는 것과는 다릅니다. 더 광범위한 Agent Skills 사양은 이식 가능한 패키징 접근 방식(portable packaging approach)을 설명하며, 특정 호스트와의 호환성(compatibility)은 여전히 확립되어야 합니다.

스킬과 변경하고자 하는 작업 연결하기

Launcherry에서는 생성 코드가 공유 코어와 채널 가이드를 로드합니다. 레이블링된 가이드 블록(labelled guidance blocks)은 모델을 위한 자료를 식별하며, 이 블록 외의 문서는 라이브러리를 유지보수하는 사람들을 위해 남아 있습니다. 파일과 생성 단계 사이의 연결은 시스템이 어떻게 작동하는지에 대한 가정이라기보다는 구현(implementation)의 일부입니다.

저는 그 경계를 사용하여 편집 목적을 명확하게 유지합니다. 관리자들은 스킬에 대한 맥락, 의도된 사용처, 그리고 이를 어떻게 평가해야 하는지에 대한 정보가 필요합니다. 모델은 현재 작업과 관련된 지침이 필요합니다. 이러한 목적들을 부주의하게 결합하면 생성된 결과물에 유지보수 메모나 평가 언어가 포함될 수 있습니다.

저는 이 문제를 이전의 목표 레이블 누출(goal-label leakage)에서 목격했습니다. 계획 레이블은 내부적으로는 유용할 수 있지만, 캠페인 문구를 작성할 때는 좋지 않을 수 있습니다. 저는 스킬이 의도를 독자에게 보이는 언어로 번역하는 데 도움을 주기를 바랍니다. 창립자는 생성 시스템의 전문 용어를 해석할 필요 없이 청중을 위한 사용 가능한 다음 단계를 받아야 합니다.

스킬을 확인하고 출력물을 별도로 평가하기

해당 라이브러리에는 기계적인 검사를 포함하는 작성 표준이 있습니다. 이러한 검사들은 예상되는 가이드 블록이 존재하는지, 그리고 파일들이 요구되는 구조를 충족하는지를 확립할 수 있게 해줍니다. 이 검사들은 잘못된 가이드가 발생하여 글쓰기 품질에 대한 논의가 일어나기도 전에 실패하게 만들 수 있기 때문에 유용합니다.

출력 평가(Output evaluation)는 다른 질문을 던집니다. 즉, 워크플로우가 이 제품과 채널에 적절한 결과를 생성했는지 여부입니다. 저는 평가 기준을 생성 가이드와 분리하여 유지합니다. 이렇게 함으로써 준수하는 것이 글쓰기 지침의 성공 증거로 취급되는 대신, 검토 자체에 고유한 역할을 부여할 수 있습니다.

실용적인 평가는 관련 예시들을 비교하고, 조사 중인 실패 사례를 기록하며, 주변 워크플로우를 염두에 두어야 합니다. 결과물은 스킬, 모델, 제공된 비즈니스 맥락 또는 나중의 검증 단계 중 어느 것의 영향을 받았을 수 있습니다. 저의 AI 출력 평가 관련 기사에서는 어떤 분야가 검증을 통과하더라도 여전히 사용 불가능할 수 있을 때 이러한 구분이 왜 중요한지 설명합니다.

모델에 독립적인 가이드도 모델별 증거를 필요로 한다

저는 특정 모델 공급업체에 의존하지 않도록 가이던스를 작성했습니다. 이는 재사용성을 지원하고 도메인 지식이 제공업체 변경에도 살아남게 합니다. 하지만 모든 모델에서 동일한 동작을 보장하는 것은 아닙니다. 새로운 모델은 요구사항을 다르게 해석하거나 이전 모델이 처리했던 제약 조건을 실패할 수 있습니다.

따라서 저의 승인 결정은 평가되는 조합, 즉 가이던스, 컨텍스트, 모델, 그리고 생성 워크플로우에 속합니다. 성공적인 실행은 그 조합에 대한 증거를 제공할 뿐입니다. 이 스킬이 모든 곳에서 좋은 출력을 보장한다는 주장으로 변해서는 안 됩니다.

저는 연구, 통합, 평가 및 유지보수를 스킬 엔지니어링의 일부로 취급합니다. 지침을 작성하는 것은 그 작업 중 한 부분일 뿐입니다. 저는 전문 지식을 제품 내부에서 사용 가능하게 만드는 연결고리를 구축한 다음, 제품이 실제로 무엇을 반환하는지 검토합니다. Launcherry 사례는 이 라이브러리가 제품 환경에서 어떻게 작동하는지를 보여주며, 개발 하니스 아티클은 그 주변의 전달 관행을 설명합니다.

원래 ivanped.ai에 게시됨: 재사용 가능한 AI 에이전트 스킬 구축: 도메인 전문 지식부터 시작까지. 더 많은 작업 보기: [ivanped.ai]