당신이 방금 당신의 스타일을 도와줄 초지능적이고 엄청나게 빠른 로봇 조수에게 나무집을 만드는 데 도움을 달라고 초대했다고 상상해 보세요. 이 로봇은 나무, 못, 물리학에 대해 모든 것을 알고 있습니다. 하지만 당신만의 구체적인 스타일은 모릅니다. 당신이 항상 난간을 파란색으로 칠한다는 것도, 못을 2인치보다 짧은 것은 절대 사용하지 않는다는 이상한 규칙이 있다는 것도 모릅니다. 만약 로봇이 당신이 원하는 방식 그대로 나무집을 짓기를 원한다면, 당신은 그것을 알려주어야 합니다. 하지만 매번 도움을 요청할 때마다 아주 사소한 세부 사항까지 설명해야 한다면, 당신은 지쳐버릴 것이고 로봇은 혼란에 빠질 수도 있습니다.

이것이 바로 "AI 에이전트(AI Agents)"의 세계입니다. AI 에이전트는 우리를 위해 과업을 수행하는 똑똑한 컴퓨터 프로그램입니다. 이들을 진정으로 유용하게 만들기 위해, 개발자들은 그들에게 "기술(Skills)"을 부여하고 있습니다. 여기서 기술을 단순한 마법 주문이 아니라, 로봇에게 건네주는 작은 설명서나 도구 상자라고 생각하십시오. 이 파일은 "헤이, 이런 종류의 작업을 보게 되면, 내가 원하는 방식은 정확히 이래"라고 말해줍니다. 큰 질문은 과학자와 엔지니어들이 던지고 있는 것입니다: 우리는 이 매뉴얼을 어떻게 작성해야 로봇이 실제로 그것을 따르게 만들 수 있을까? 우리가 매뉴얼을 잘못 작성하면 로봇은 이를 무시하거나 일을 그르칠 수 있습니다. 반대로 잘 작성한다면, 로봇은 당신만의 방식을 구현하는 진정한 전문가가 될 것입니다.

당신이 읽게 될 이 논문은 주세페 데스테파니스스(Giuseppe Destefanis)가 작성한 것으로, 이러한 "기술"을 작성하는 것을 단순히 일상적인 메모나 시를 쓰는 것처럼 취급해서는 안 된다고 주장합니다. 대신, 이를 소프트웨어 공학처럼 다루어야 합니다. 프로그래머가 명확한 규칙, 깨끗한 코드, 안전 점검 장치를 갖춘 신뢰할 수 있는 앱을 구축하는 것처럼, 우리도 AI 기술을 구축할 때 동일한 주의를 기울여야 합니다. 이 논문은 기술이 사실 가면을 쓴 소프트웨어 조각이라고 제안합니다. 기술은 "인터페이스"(무엇을 하는지 알려주는 라벨)와 "구현"(실제 지침)을 가지고 있습니다. 저자는 우리가 컴퓨터 프로그램을 만들 때 사용하는 것과 같은 엄격한 규칙들—즉, 단순함을 유지하고, '무엇'과 'how'를 분리하며, 철저히 테스트하는 것—을 사용하여 우리의 AI 에이전트가 궤도를 벗어나지 않도록 해야 한다고 제안합니다.

"기술"이란 디지털 맥가이버 칼(Swiss Army Knife)이다

당신에게 무엇이든 담을 수 있는 거대하고 마법 같은 배낭이 있다고 상상해 보세요. 그 안에 "릴리스 노트 작성하기"를 위한 특별한 주머니가 있습니다. 이 주머니는 단순한 종이 한 장이 아닙니다. 하나의 키트입니다. 겉면에는 "새로운 버전의 게임에 대한 변경 사항 요약을 작성해야 할 때 사용하세요"라고 적힌 라벨이 붙어 있습니다. 그 라벨이 바로 인터페이스입니다. 로봇은 라벨을 보고, 일치하는 작업이 있는지 확인한 뒤, 그 주머니를 열기로 결정합니다.

주머니 안에는 단순히 지저한 메모 뭉치를 쏟아붓는 것이 아닙니다. 당신은 명확한 단계별 레시피(본문)를 가지고 있으며, 변경 사항을 자동으로 계산하는 스크립트나 노트가 보여야 할 스타일 가이드와 같은 몇 가지 추가 도구도 가지고 있습니다. 이것이 구현입니다. 논문은 이것을 "기술(Skill)"이라 부르며, 이 전체 키트가 하나의 **소프트웨어 아티팩트(software artifact)**라고 강조합니다. 이는 그것이 비디오 게임이나 웹사이트처럼 구축되고, 테스트되고, 유지 관리되어야 하는 기술 조각이라는 뜻의 어려운 표현입니다.

저자는 만약 당신이 기술을 일상적인 메모처럼 취급한다면 실패할 것이라고 주장합니다. 만약 당신이 기술을 소프트웨어처럼 취급한다면, 그것은 작동할 것입니다. 다음은 이 디지털 키트를 구축하기 위한 규칙들입니다.

1. "단일 책임" 규칙

맥가이버 칼을 생각해 보세요. 만약 당신이 드라이버, 병따개, 톱, 칫솔, 피자 커터를 모두 하나로 합친 도구를 만들려고 한다면, 그것은 모든 면에서 형편없을 것입니다. 논문은 하나의 기술이 한 가지 일을 정말 잘 해내야 한다고 말합니다. 만약 어떤 기술이 "코딩과 관련된 모든 것"을 하려고 한다면, 로봇은 언제 그것을 사용해야 할지 혼란스러워할 수 있습니다. 하지만 기술이 구체적으로 "풀 리퀘스트(pull requests)로부터 릴리스 노트를 초안 작성하기"라면, 로봇은 정확히 언제 그것을 꺼내 써야 할지 알게 됩니다. 논문은 집중된 기술이 AI에 의해 더 신뢰성 있게 선택된다고 제안합니다.

2. "단계별 로딩" 기법

당신에게 백만 권의 책이 있는 도서관이 있다고 상상해 보세요. 필요한 책을 찾기 위해 한꺼번에 모든 책을 읽으려 한다면 당신의 뇌는 폭발할 것입니다. 논문은 AI 기술이 **단계별 로딩(staged loading)**이라는 영리한 트릭을 사용한다고 설명합니다.

• 레벨 1 (라벨): 먼저, 로봇은 주머니의 라벨(이름과 짧은 설명)만 봅니다. 이는 "두뇌 에너지(토큰)"가 거의 들지 않습니다.
• 레벨 2 (레시피): 만약 로봇이 작업이 라벨과 일치한다고 판단하면, 주머니를 열고 메인 레시피를 읽습니다.
• 레벨 3 (도구): 레시피에서 "오, 이제 이 특정 파일을 확인해야 해"라고 명시적으로 말할 때만 추가 도구(스크립트나 참조 파일)를 꺼냅니다.

이는 당신이 기술 내부에 방대한 참조 자료 라이브러리를 가지고 있더라도, 로봇이 실제로 그 자료를 사용할 필요가 없을 때까지는 과부하를 주지 않는다는 것을 의미합니다. 이는 거대한 도구 상자를 가지고 있지만, 필요한 서랍만 여는 것과 같습니다.

3. "설명"이 트리거(Trigger)다

기술에서 가장 중요한 부분은 라벨에 적힌 설명입니다. 논문은 만약 당신이 "릴리스 처리"와 같이 모호한 라벨을 쓴다면 로봇은 언제 그것을 사용해야 할지 모를 것이라고 경고합니다. 설명은 구체적이어야 합니다: "두 버전 태그 사이에 병합된 풀 리퀘스트로부터 릴리스 노트를 초안 작성합니다. 릴리스를 끊을 때 사용하세요." 로봇은 이 설명을 보고 작업을 매칭합니다. 만약 설명이 흐릿하다면, 로봇은 기술을 통째로 놓치거나 잘못된 것을 선택할 수 있습니다. 논문은 이 설명이 당신과 로봇 사이의 "계약"이라고 제안합니다.

4. "행동 평가"를 통한 테스트

일반적인 컴퓨터 프로그래밍에서는 함수를 실행하고 결과가 정확히 "5"인지 확인하여 테스트할 수 있습니다. 하지만 AI는 다릅니다. 로봇은 똑같은 일을 하고 있더라도 매번 약간 다른 답을 줄 수 있습니다. 논문은 단순한 "합격/불합격" 체크로 기술을 테스트할 수 없다고 말합니다. 대신, **행동 평가(behavioral evaluation)**를 사용해야 합니다. 즉, 실제 세계의 작업들을 기술에 주고, 여러 번 실행해 본 뒤, 대부분의 경우에 제대로 수행하는지 확인하는 것입니다. 이것은 재료 목록에 있는지 확인하는 수준을 넘어, 새로운 레시피를 열 번 요리해 보고 맛을 보며 테스트하는 것과 같습니다.

거대한 혼란: 기술 vs 다른 도구들

이 논문의 가장 큰 기여 중 하나는 AI에게 무엇을 할지 알려주는 다양한 방법들 사이의 혼란을 정리하는 것입니다. 저자는 기술을 훅(Hooks), 슬래시 커맨드(Slash Commands), **메모리 파일(Memory Files)**과 같은 다른 도구들과 비교합니다.

당신이 연극을 연출하고 있다고 상상해 보세요.

• 메모리 파일은 배우(AI)들이 공연하는 매 순간 무대 위에 항상 존재하는 대본과 같습니다. 이들은 사라지지 않는 프로젝트 컨텍스트를 제공하여, 로봇이 특정 행동을 강제하지 않더라도 항상 이 정보를 사용할 수 있도록 보장합니다.
• 슬래시 커맨드는 무대 진행 요원이 "헤이, 지금 마술 보여줘!"라고 외치는 것과 같습니다. 당신(사용자)이 명령을 내려야 합니다. 로봇은 당신을 기다립니다.
• **훅(Hooks)**은 엄격하고 자동화된 안전 장치와 같습니다. 만약 배우가 안전 장치 없이 무대 밖으로 뛰어내리려 한다면, 이 안전 장치는 그들을 잡거나 동작을 멈추기 위해 **결정론적으로 실행(deterministically executes)**되는 규칙을 작동시킵니다. 로봇은 이를 무시할 수 없습니다. 특정 이벤트가 발생할 때마다 로봇의 결정과 상관없이 반드시 일어납니다.
• **기술(Skills)**은 요청 시 로드되는 특화된 절차적 도구 상자와 같습니다. 로봇이 어떤 작업을 마주하면, 설명을 매칭하고 해당 도메인을 처리하기 위한 특정 지침을 로드합니다. 이는 로봇이 문제를 해결하기 위해 능동적으로 검색하는 전문 지식의 원천입니다.

논문은 명확한 선을 긋습니다: 만약 어떤 일이 매번 일어나야 한다면(파일을 저장하기 전의 안전 점검처럼), 반드시 **훅(Hook)**을 사용해야 합니다. 만약 로봇이 특정 절차가 필요한지 스스로 판단하게 하고 싶다면, **기술(Skill)**을 사용해야 합니다. 이 둘을 혼동하는 것은 흔한 실수라고 논문은 경고합니다. 만약 당신이 기술 안에 안전 규칙을 작성한다면, 로봇은 그것을 건너뛰기로 결정할 수도 있습니다. 만약 훅 안에 유연한 제안을 작성한다면, 로봇은 하지 않아도 될 일까지 계속하게 되어 갇혀버릴 수 있습니다.

"신뢰"의 문제

마지막으로, 논문은 무섭지만 중요한 아이디어인 신뢰를 다룹니다. 만약 당신이 다른 사람(제3자)으로부터 기술을 다운로드한다면, 당신은 당신의 로봇이 따를 지침을 그들이 쓰도록 허용하는 것입니다. 그 기술은 파일을 삭제하거나 데이터를 인터넷으로 보내는 스크립트를 포함할 수 있습니다. 논문은 기술을 인터넷에서 다운로드하는 소프트웨어와 똑같이 취급해야 한다고 주장합니다. 그냥 "설치"를 누르지 마십시오. 코드를 읽고, 스크립트를 확인하고, 안전한지 확인해야 합니다. 로봇은 기술이 시키는 대로 무엇이든 할 것이므로, 당신이 문지기가 되어야 합니다.

결론

주세페 데스테파니스의 논문은 AI 도구를 만드는 모든 이들을 향한 행동 촉구입니다. 이 논문은 이렇게 말합니다: "AI 지침을 일상적인 메모처럼 취급하는 것을 멈추십시오. 그것을 진지한 소프트웨어처럼 다루기 시작하십시오."

소프트웨어 공학의 원칙을 사용함으로써—단순함을 유지하고, 라벨과 내용을 분리하며, 실제 시나리오로 테스트하고, 기술과 훅을 언제 사용할지 정확히 아는 것—우리는 단순히 똑똑한 것을 넘어 신뢰할 수 있고 안전한 AI 에이전트를 구축할 수 있습니다. 이 논문은 이것이 모든 AI 문제를 해결할 것이라고 약속하지는 않지만, 우리가 앱을 만들 때와 같은 정성을 들여 기술을 만든다면, 우리의 디지털 조수를 훨씬 더 신뢰할 수 있는 파트너로 만들 수 있다고 제안합니다. 이것은 "로봇이 제대로 해주길 바라는 것"에서 "로봇이 제대로 하도록 엔지니어링하는 것"으로 나아가는 과정입니다.