좋은 스킬의 해부학: 시스템이 신뢰할 수 있는 기능 설계하기

스킬은 단순한 지침 그 이상입니다. 신뢰할 수 있는 스킬이 에이전트 시스템(agent systems) 내부에서 입력(inputs), 출력(outputs), 계약(contracts), 실패(failures), 그리고 유연성(flexibility)을 어떻게 정의하는지 알아보세요.

이전 글에서 우리는 에이전트 시스템 내부에서 스킬이 실제로 무엇을 나타내는지 살펴보았습니다. 스킬은 단순히 지침의 집합이나 재사용 가능한 프롬프트(prompt)가 아닙니다. 그것은 에이전트가 매번 동일한 추론(reasoning)을 다시 구축할 필요 없이 특정 작업을 수행할 수 있도록 하는 정의된 기능(capability)입니다.

이러한 정의는 다음 질문을 불러옵니다.

만약 스킬이 에이전트 워크플로(workflow) 내부에서 재사용 가능한 기능이 된다면, 무엇이 한 스킬을 다른 스킬보다 더 낫게 만들까요?

기술적으로 작동할 수는 있지만, 여전히 형편없는 빌딩 블록(building block)일 수 있는 스킬이 있습니다.

한 번은 작업을 완료할 수 있지만, 다른 에이전트가 이를 사용하려고 할 때 실패할 수 있습니다. 유용한 정보를 생성할 수는 있지만, 워크플로의 다음 단계에서 소비할 수 없는 형식으로 생성할 수도 있습니다. 이상적인 시나리오에서는 처리할 수 있지만, 입력이 불완전하거나 예상치 못한 경우 무너질 수도 있습니다.

기초적인 스킬과 신뢰할 수 있는 스킬의 차이는 설계(design)에 달려 있습니다.

신뢰할 수 있는 스킬은 고립된 지침처럼 행동하기보다 잘 정의된 시스템 구성 요소(system component)처럼 행동합니다. 스킬은 경계(boundaries), 기대치(expectations), 그리고 예측 가능한 동작(predictable behavior)을 가집니다. 시스템의 다른 부분은 스킬의 내부 추론을 조사할 필요 없이 스킬과 상호작용하는 방법을 이해해야 합니다.

이 지점이 바로 스킬 설계가 중요해지는 부분입니다.

스킬에는 계약이 필요합니다

소프트웨어 시스템에서 구성 요소들은 명확한 계약(contracts)을 가질 때 유지보수가 더 쉬워집니다.

함수(function)는 어떤 인자(arguments)를 수락하고 무엇을 반환(returns)하는지 정의합니다. API는 다른 시스템이 어떻게 통신하는지를 정의합니다. 서비스(service)는 요청이 성공하거나 실패할 때 어떤 일이 발생하는지를 정의합니다.

스킬에도 동일한 규율이 필요합니다.

스킬 계약(skill contract)은 기능(capability)과 이를 사용하는 시스템 사이의 관계를 정의합니다.

이는 몇 가지 중요한 질문에 답합니다:

이 스킬은 어떤 정보를 필요로 하는가?

어떤 종류의 결과를 생성할 것인가?

어떤 가정을 전제로 하는가?

필요한 정보가 누락되었을 때 어떤 일이 일어나야 하는가?

이러한 경계(boundaries)가 없다면, 스킬은 조합(compose)하기 어려워집니다.

**Generate Project Summary (프로젝트 요약 생성)**라는 간단한 스킬을 예로 들어보겠습니다.

취약한 구현 방식은 다음과 같이 설명할 수 있습니다:

프로젝트를 분석하고 요약을 생성하십시오.

사람에게는 의도가 명확하지만, 시스템 입장에서는 여전히 해결되지 않은 질문이 많습니다.

이 스킬은 소스 파일, 문서, 최근 커밋, 사용자 노트, 또는 이전의 결정 사항이 필요한가요? 출력물은 하나의 단락이어야 하나요, 구조화된 보고서여야 하나요, 아니면 중요한 발견 사항의 목록이어야 하나요?

문제는 스킬이 작업을 수행할 수 없다는 것이 아닙니다.

문제는 인터페이스(interface)가 정의되지 않았다는 것입니다.

더 잘 설계된 스킬은 이러한 기대 사항을 명시적으로 만듭니다. 어떤 컨텍스트 (context)가 필요한지, 그리고 최종 출력물이 어떤 형태를 따라야 하는지를 정의합니다. 일단 그것이 존재하면, 스킬은 다른 에이전트 (agents), 도구 (tools), 그리고 워크플로 (workflows)와 연결하기가 더 쉬워집니다.

계약 (contract)은 능력 (capability)과 조정 (coordination) 사이의 가교가 됩니다.

입력(Inputs)이 스킬의 경계를 정의한다

스킬의 품질은 종종 입력 (inputs)이 얼마나 신중하게 설계되었는지에 따라 달라집니다.

많은 초기 스킬들은 모든 것을 수용하려고 시도하기 때문에 신뢰할 수 없게 됩니다. 이들은 코딩과 관련된 무엇이든 처리하기 또는 프로젝트 작업 돕기와 같이 광범위한 지침과 함께 만들어집니다.

이러한 설명은 유연해 보이지만, 불확실성을 초래합니다.

스킬이 불분명한 입력을 수용할 때, 에이전트 (agent)는 어떤 정보가 중요한지 결정하는 데 추가적인 추론 (reasoning) 노력을 기울여야 합니다. 그 결정은 실행할 때마다 달라질 수 있으며, 이는 일관성 없는 동작을 만들어냅니다.

잘 설계된 스킬은 정의된 운영 영역 (operating area)을 가집니다.

예를 들어, 코드 리뷰 (code review) 스킬은 저장소 (repository)를 리뷰하기 전에 무엇이 필요한지 이해해야 합니다. 변경된 파일, 프로젝트 컨벤션 (project conventions), 보안 기대 사항, 또는 특정 리뷰 목표가 필요할 수 있습니다. 만약 이러한 세부 정보가 누락되었다면, 스킬은 묵묵히 가정을 하는 대신 그 공백을 식별해야 합니다.

좋은 입력 설계는 불필요한 추측을 줄여줍니다.

이것이 모든 스킬에 엄격한 스키마 (schema)와 수십 개의 필수 필드가 필요하다는 의미는 아닙니다. 어떤 스킬들은 자연스럽게 불완전한 정보로도 작동합니다. 연구 및 탐색 (research and exploration) 스킬은 그 목적이 불확실성을 조사하는 것이기 때문에 유연성이 필요할 수 있습니다.

중요한 부분은 불확실성이 어디에 속해야 하는지를 아는 것입니다.

스킬은 탐색이 필요한 곳에서는 유연해야 하고, 정확성이 중요한 곳에서는 엄격해야 합니다.

출력은 다음 시스템을 위해 설계되어야 합니다

스킬을 만들 때 흔히 하는 실수는 스킬이 자신의 작업만을 완료하는지에만 집중하는 것입니다.

하지만 에이전트 생태계 (agent ecosystem)에서 완료는 워크플로 (workflow)의 일부일 뿐입니다.

다음 질문은 다른 시스템이 그 결과를 사용할 수 있는지 여부입니다.

긴 설명을 반환하는 스킬은 그것을 읽는 사람에게는 유용할 수 있지만, 다른 에이전트가 처리하기에는 어려울 수 있습니다. 단순히 **배포 실패 (deployment failed)**라고 말하는 배포 스킬은 실패한 단계, 오류 세부 정보, 그리고 가능한 복구 조치를 반환하는 스킬보다 가치가 떨어집니다.

출력은 스킬 인터페이스 (interface)의 일부입니다.

좋은 출력 형식은 스킬이 종료된 후에 어떤 일이 일어날지를 고려합니다.

다른 스킬가 이 정보를 소비할 것인가?

오케스트레이터 (orchestrator)가 다음 행동을 결정할 것인가?

사람이 이를 검토해야 하는가?

이 답변에 따라 출력이 어떻게 구조화되어야 하는지가 달라집니다.

이것이 바로 신뢰할 수 있는 스킬(skill)이 단순히 설명(description)만을 제공하기보다, 결정(decision)을 중심으로 구조화된 정보를 반환하는 경우가 많은 이유입니다. 목표는 출력을 더 길게 만드는 것이 아닙니다. 목표는 출력을 유용하게 만드는 것입니다.

스킬은 시스템의 다른 부분이 실행에 옮길 수 있는 무언가를 남겨두어야 합니다.

에러 핸들링(Error Handling)은 설계의 일부입니다

많은 스킬이 성공적인 경로(successful path)를 중심으로 설계됩니다.

지침(instructions)은 모든 것이 가용하고 모든 것이 올바르게 작동할 때 무엇을 해야 하는지를 설명합니다.

실제 시스템은 그렇게 작동하는 경우가 드뭅니다.

입력(input)이 불완전할 수 있습니다. 외부 도구(external tools)가 실패할 수 있습니다. 컨텍스트(context)가 오래되었을 수 있습니다. 요청된 작업이 가용 정보로는 불가능할 수도 있습니다.

이러한 상황을 정의하지 않는 스킬은 전체 워크플로(workflow)에 불확실성을 초래합니다.

좋은 스킬은 실패 동작(failure behavior)을 설계의 일부로 포함합니다.

필요한 정보가 누락된 경우, 스킬이 명확한 설명을 요청해야 하는가?

외부 작업이 실패한 경우, 재시도해야 하는가 아니면 실패를 보고해야 하는가?

부분적인 결과만 사용 가능한 경우, 이를 반환해야 하는가?

이러한 결정이 중요한 이유는 실패가 전파(propagate)되기 때문입니다.

여러 스킬이 연결된 체인(chain)에서, 제대로 처리되지 않은 실패는 이후의 모든 단계를 혼란에 빠뜨릴 수 있습니다. 명확하게 보고된 실패는 시스템이 회복할 기회를 제공합니다.

신뢰할 수 있는 시스템은 실패를 피함으로써 구축되는 것이 아닙니다.

실패를 이해 가능하게 만듦으로써 구축됩니다.

결정론(Determinism) vs 유연성(Flexibility)

스킬 생성 시 가장 큰 설계 선택 중 하나는 스킬이 어느 정도의 자유도를 가져야 하는지를 결정하는 것입니다.

지나친 결정론(determinism)은 경직된 스킬을 만듭니다.

이들은 오직 하나의 정확한 상황에서만 작동하며 적응하기 어려워집니다.

지나친 유연성(flexibility)은 예측 불가능한 동작을 만듭니다.

스킬이 컨텍스트의 미세한 변화에 따라 서로 다른 결과를 생성할 수 있으며, 이는 신뢰를 어렵게 만듭니다.

적절한 균형은 스킬의 책임(responsibility)에 따라 달라집니다.

포맷팅 스킬(formatting skill), 검증 스킬(validation skill), 또는 배포 체크(deployment check)는 일반적으로 전통적인 함수(function)에 더 가깝게 동작해야 합니다. 다른 시스템들이 정확성에 의존하기 때문에 기대되는 동작은 일관되게 유지되어야 합니다.

연구(research) 또는 계획(planning) 스킬은 목표에 탐색(exploration)과 해석(interpretation)이 포함되기 때문에 더 많은 유연성(flexibility)이 필요할 수 있습니다.

목표는 유연성을 제거하는 것이 아닙니다.

목표는 통제된 유연성(controlled flexibility)입니다.

강력한 스킬은 변동성(variation)이 유용한 지점과 일관성(consistency)이 필요한 지점을 이해합니다.

확장 가능한 스킬 구축하기

단일 스킬은 느슨한 지침(loose instructions)만으로도 생존할 수 있습니다.

하지만 스킬 라이브러리(skill library)는 그렇지 못합니다.

에이전트(agents)가 여러 스킬에 의존하기 시작하면, 모든 기능(capability)은 더 큰 운영 체제(operating system)의 일부가 됩니다. 작은 불일치들이 더 큰 문제들을 만들기 시작합니다. 모호한 입력(ambiguous inputs), 불분명한 출력(unclear outputs), 그리고 정의되지 않은 실패(undefined failures)는 전체 워크플로우(workflow)를 점진적으로 유지 관리하기 어렵게 만듭니다.

이것이 바로 스킬 설계(skill design)가 중요한 이유입니다.

좋은 스킬은 단순히 답을 내놓는 스킬이 아닙니다.

주변 시스템과 명확하게 소통하는 스킬입니다.

스킬은 무엇이 필요한지, 무엇을 제공하는지, 그리고 다양한 조건 하에서 어떻게 동작하는지를 정의합니다. 그러한 명확성이 스킬을 일회성 솔루션이 아닌 재사용 가능한 빌딩 블록(building blocks)으로 만들어 줍니다.

에이전트 시스템(agent systems)을 구축하는 첫 번째 단계는 기능(capabilities)을 만드는 것입니다.

다음 단계는 신뢰할 수 있는 기능(capabilities)을 만드는 것입니다.