나는 AI 생산성의 다음 도약이 더 나은 프롬프트를 작성하는 것에서 올 것이라고 생각하곤 했다.

더 긴 프롬프트. 더 정밀한 프롬프트. 역할 정의(role definitions), 어조 규칙(tone rules), 예시(examples), 제약 사항(constraints), 그리고 출력 형식(output formats)이 포함된 프롬프트 말이다.

Agent Skills에 관한 책을 읽은 후, 나는 이러한 프레임워크(framing)가 너무 작다는 것을 깨달았다.

진정한 병목 현상(bottleneck)은 내가 작업을 한 번 설명하는 데 실패하는 것이 아니다. 진정한 병목 현상은 동일한 범주의 작업을 계속해서 반복적으로 설명해야 한다는 점이다. 즉, 기사를 어떻게 구성하고 싶은지, 코드를 어떻게 리뷰하는지, App Store 출시 노트(release notes)를 어떻게 준비하는지, 시각 자료를 어떻게 생성하는지, 발행 전 초안을 어떻게 확인하는지 등을 말이다.

어느 시점에 이르면, "AI를 사용하는 것"은 조용히 "AI를 수동으로 관리하는 것"으로 변질된다.

그 책에서 가장 유용한 아이디어는 간단하다:

AI 생산성은 모든 프롬프트를 더 길게 만드는 데서 오는 것이 아니다. 반복되는 작업을 실행 가능하고(executable), 유지 관리 가능하며(maintainable), 테스트 가능한(testable) 기술(skills)로 전환하는 데서 온다.

그것이 AI 작업에 대한 나의 생각을 바꾸어 놓았다.

기술(Skill)은 프롬프트가 아니다
프롬프트는 하나의 대화 내에서 이루어지는 일시적인 지침이다.

기술(Skill)은 에이전트(agent)를 위한 재사용 가능한 운영 매뉴얼이다.

매일 AI를 사용하기 전까지는 그 차이가 작게 느껴질 수 있다. 프롬프트는 모델에게 지금 당장 원하는 것이 무엇인지 알려준다. 기술(Skill)은 에이전트에게 특정 범주의 작업이 매번 어떻게 수행되어야 하는지를 알려준다:

언제 활성화할 것인지
어떤 입력을 읽을 것인지
어떤 단계를 따를 것인지
어떤 도구(tools)나 스크립트(scripts)를 호출할 것인지
어떤 출력을 생성할 것인지
무엇이 절대 일어나서는 안 되는지
에이전트가 어디에서 멈추고 인간의 판단을 요청해야 하는지
마지막 부분이 중요하다.

목표는 작업에서 인간을 제거하는 것이 아니다. 목표는 동일한 저수준 지침(low-level instructions)에 인간의 주의력을 소비하는 것을 멈추는 것이다.

나에게 있어 가장 명확한 후보들은 특별한 것이 아니다:

• 글쓰기 스타일 기술 (writing style skill)
• 코드 리뷰 기술 (code review skill)
• iOS 출시 체크리스트 기술 (iOS release checklist skill)
• App Store 출시 노트 기술 (App Store release notes skill)
• 도서 노트 기술 (book notes skill)
• 주간 리뷰 기술 (weekly review skill)

이것들은 내가 할 수 없는 작업들이 아니다. 이것들은 내가 동일한 기준, 선호도, 주의 사항, 그리고 확인 사항들을 계속해서 반복하고 있는 작업들이다.

그 반복이 바로 진정한 비용이다.

유용한 분리: 판단(Judgment), 기계적 작업(Mechanics), 그리고 워크플로우(Workflow)

이 책에서 가장 명확한 구분 중 하나는 다음과 같습니다:

• 프롬프트는 의미론적 판단을 처리하고,
• 스크립트는 결정론적 기계적 작업을 처리하며,
• 스킬은 전체 워크플로우를 오케스트레이션합니다.

이것은 당연하게 들리지만, 많은 AI 워크플로우가 모델에게 잘못된 임무를 부여하기 때문에 실패합니다.

예를 들어, 기사에 어느 부분에 삽화가 필요한지 결정하도록 모델에게 요청하는 것은 합리적입니다. 하지만 파일 이름을 신뢰성 있게 변경하거나, 이미지 크기를 검증하거나, 긴 문서를 분할하거나, 표의 값을 계산하도록 요청하는 것은 보통 실수입니다.

이것들은 결정론적인 작업(deterministic jobs)입니다. 스크립트나 엄격한 도구로 처리되어야 합니다.

모델은 판단에 더 잘 사용됩니다:

• 에세이의 관점 선택하기
• 초안의 약한 부분 식별하기
• 두 가지 아키텍처 옵션 비교하기
• 트레이드오프 설명하기
• 거친 자료를 명확한 언어로 바꾸기

스킬은 이 둘 위에 존재합니다. 스킬은 다음과 같이 말합니다: 이러한 종류의 작업이 나타나면, 모델에게는 판단 부분을 사용하고, 기계적 부분에는 스크립트를 사용하며, 인간의 결정이 필요한 체크포인트를 보존해야 합니다.

이는 모든 것을 하나의 거대한 프롬프트에 넣으려고 시도하는 것보다 훨씬 더 지속 가능한 패턴입니다.

맥락은 창고가 아니라 작업대(Workbench)이다

큰 컨텍스트 윈도우는 모든 것을 대화창에 쏟아붓고 싶은 유혹을 만듭니다.

스타일 가이드. 이전 채팅 기록. 예시. 템플릿. API 문서. 초안. 개인적인 선호 사항. 이 모든 것이요.

이 책은 정반대의 규율, 즉 적절한 시점에 올바른 자료를 로드할 것을 주장합니다.

스킬은 이렇게 설계되어야 합니다. 메인 SKILL.md는 창고가 되어서는 안 됩니다. 핵심 워크플로우를 포함해야 합니다:

• 트리거 조건(trigger conditions)
• 입력 및 출력(inputs and outputs)
• 주요 단계(main steps)
• 하드 제약 조건(hard constraints)
• 실패 모드(failure modes)
• 필요할 때만 로드하는 참조(references to load only when needed)

긴 템플릿, 예시, API 노트, 스타일 샘플은 별도의 참조 파일에 속해야 합니다.

이것은 단순히 토큰 절약에 관한 것이 아닙니다. 주의력(attention)에 관한 것입니다. 컨텍스트에 관련 없는 자료를 많이 밀어 넣을수록, 모델이 실제로 중요한 단 하나의 규칙을 놓치기 쉬워집니다.

컨텍스트 (Context)는 작업대처럼 느껴져야 합니다. 현재 작업에 필요한 도구들만 그 위에 놓여 있어야 합니다.

좋은 워크플로 (Workflows)는 완전히 자동화된 것이 아니다
AI 자동화의 위험한 버전은 모든 일시 정지(pause)를 제거함으로써 효율적으로 보이는 것입니다.

Medium 멤버가 되어주세요
에이전트 (Agent)에게 소스 자료를 제공하십시오. 에이전트가 관점 (angle)을 선택하게 하십시오. 에이전트가 초안을 작성하게 하십시오. 에이전트가 초안을 다듬게 하십시오. 에이전트가 이미지를 생성하게 하십시오. 에이전트가 게시하게 하십시오.

이것은 생산성 향상처럼 보입니다. 하지만 종종 이는 가장 중요한 결정들을 외주 주는 방식일 뿐입니다.

더 나은 워크플로는 더 선택적입니다.

글쓰기의 경우, 저는 AI가 다음과 같이 하기를 원합니다:

소스 자료 분석
여러 가지 관점 제안
정지
내가 관점을 선택하도록 함
해당 관점으로 초안 작성
내 기준에 맞춰 수정
플랫폼별 버전 준비

일시 정지는 마찰이 아닙니다. 그것이 핵심입니다.

개발에도 동일하게 적용됩니다. AI는 구현 계획을 제안하고, 테스트를 작성하며, 회귀 (regressions)를 스캔하고, 릴리스 노트 (release notes)를 생성할 수 있습니다. 하지만 아키텍처 결정, 제품의 트레이드오프 (tradeoffs), 그리고 게시 결정은 여전히 인간의 소유권 (ownership)이 필요합니다.

AI는 준비 작업을 할 수 있습니다. 하지만 판단력을 조용히 가로채서는 안 됩니다.

기술에는 장식이 아닌 엔지니어링이 필요하다
유용한 기술은 영리한 메모라기보다 작은 소프트웨어 제품처럼 취급되어야 합니다.

이는 기술에 생명 주기 (lifecycle)가 있음을 의미합니다:

실제 문제 정의
가장 작은 사용 가능한 버전 구축
실제 작업에 실행
실패 모드 (failure modes) 기록
테스트 또는 예시 추가
파일이 너무 커지면 리팩터링 (refactor)
작업이 변함에 따라 지속적으로 개선

기술의 가장 유용한 부분은 종종 우아한 워크플로가 아닙니다. 바로 "주의 사항 (gotchas)" 섹션입니다.

그곳은 계속해서 발생하는 실패들을 기록하는 곳입니다:

에이전트가 참조 템플릿을 읽는 것을 잊음
출력이 너무 일반적임
스크립트가 잘못된 파일 경로를 처리함
모델이 보존해야 했던 섹션들을 다시 작성함
게시 전 인간의 체크포인트 (checkpoint)가 필요함

이것이 개인의 경험이 운영 메모리 (operational memory)가 되는 지점입니다.

만약 같은 실수가 두 번 반복된다면, 그것은 아마도 기술 (skill)의 영역에 속할 것입니다. 만약 같은 작업이 세 번 반복된다면, 그것은 아마도 기술 (skill)의 후보가 될 것입니다.

보안 경계 (Security Boundary)는 설계의 일부입니다
기술 (skill)이 파일을 읽거나, 파일을 쓰거나, 스크립트를 호출하거나, 네트워크에 접속하거나, 콘텐츠를 게시할 수 있게 되면 더욱 심각해집니다.

그 시점에서 그것들은 단순한 프롬프트 (prompt)가 아닙니다. 그것들은 운영 도구 (operational tools)입니다.

따라서 안전 규칙은 처음부터 설계에 포함되어야 합니다:

• 기술 (skill)이 읽고 쓸 수 있는 위치를 제한할 것
• 확인 없이 파괴적인 동작을 수행하는 것을 피할 것
• 중요한 파일을 덮어쓰기 전에 백업할 것
• 게시 워크플로 (publishing workflows)를 먼저 가짜 데이터로 테스트할 것
• 기술 (skill)을 공개적으로 공유하기 전에 로컬 경로, 비밀 정보 (secrets), 그리고 개인적인 가정을 제거할 것
• 타사 기술 (third-party skills)의 스크립트를 실행하기 전에 검사할 것

이것은 편집증이 아닙니다. 기본적인 엔지니어링 위생 (engineering hygiene)입니다.

에이전트 (agent)가 더 유능해질수록, 경계 (boundaries)는 더 명시적이어야 합니다.

내가 가장 먼저 시도해 볼 것
이 책은 이 아이디어를 매주 습관으로 만들 수 있을 만큼 충분히 구체적으로 느끼게 해주었습니다.

이번 주에 나는 세 가지 작은 기술 (skills)로 시작할 것입니다.

첫째: 글쓰기 스타일 기술 (writing style skill).

거대한 선언문이 아닙니다. 단지 역할 (role), 세 가지 스타일 원칙, 짧은 금지어 목록, 그리고 무엇이 "좋은" 것인지에 대한 몇 가지 예시일 뿐입니다.

둘째: iOS 또는 앱 출시 체크리스트 기술 (app release checklist skill).

첫 번째 버전은 버전 번호, 출시 노트 (release notes), 스크린샷, 개인정보 보호 텍스트, 그리고 제출 전 최종 수동 확인만을 다루면 됩니다.

셋째: 기존 기술 (skills)을 위한 주의사항 (gotchas) 섹션.

실망스러웠던 최근 세 개의 AI 출력물을 가져옵니다. 각 실패를 구체적인 규칙으로 변환하십시오. 단 하나의 사례를 위해 임시방편으로 수정하지 마십시오. 패턴을 포착하십시오.

또한 즉시 실행해 볼 가치가 있는 실험이 하나 있습니다:

기사로 만들고 싶은 자료를 하나 가져오십시오. AI에게 기사를 써달라고 요청하지 마십시오. 오직 두 가지만 요청하십시오: 자료를 분석하고 세 가지 관점 (angles)을 제안하는 것입니다. 그런 다음 멈추고 관점은 직접 선택하십시오.

만약 최종 기사가 개선된다면, 인간의 체크포인트 (human checkpoint)는 그 가치를 스스로 증명한 것입니다.

변화
이 책은 제가 AI를 더 많이 사용하고 싶게 만들지는 않았습니다.

대신 AI를 수동으로 관리하는 일을 줄이고 싶게 만들었습니다.

그것이 진정한 변화입니다: 일시적인 지시 (temporary instruction)에서 재사용 가능한 워크플로 (reusable workflow)로; 프롬프트 축적 (prompt accumulation)에서 경험 엔지니어링 (experience engineering)으로; AI에게 내 선호도를 기억해 달라고 요청하는 것에서 그 선호도를 유지 관리 가능한 시스템에 기록하는 것으로의 변화 말입니다.

더 나은 프롬프트는 여전히 중요합니다.

하지만 진정한 복리 수익 (compounding return)은 프롬프트가 일회성 지시가 아닌 하나의 기술 (skill)의 일부가 될 때 발생합니다.

공개 사항: 이 에세이는 저의 중국어 독서 노트를 바탕으로 AI의 도움을 받아 작성되었습니다.