AI 에이전트와 skills가 가져올 실행 가능한 집단 지성의 가능성

AI 에이전트와 skills의 활용에 대해 생각하던 중, 한 가지 가설에 도달했습니다.

그것은 인류의 지식 축적 단위가 지금까지의 '문장'에서, 앞으로는 실행 가능한 작업 단위로 전환되어 가는 것이 아닌가 하는 가설입니다.

조금 더 정중하게 표현하자면, 그것은 단순한 실행 가능한 절차가 아니라, 실패 이력을 가지고 있으며, 이를 통해 개선되고, 어떤 조건에서 파탄 나는지가 명시된 작업 단위이며, 이것이 앞으로 지식 계승의 중요한 '형태'가 되지 않을까 하는 가설입니다.

조금 과장되게 들릴지도 모릅니다.

하지만 인류 지성의 발전을 되돌아보면, 지식은 항상 어떠한 '단위'로 압축되고, 공유되며, 재사용됨으로써 축적되어 왔습니다.

• 언어
• 개념
• 서적
• 논문
• 업무 절차
• 매뉴얼
• 설계 사상
• 소스 코드

이것들은 개인의 경험이나 사고를 타자가 재사용할 수 있는 형태로 변환한 매체였습니다.

그리고 근대 이후, 그 중심에 있었던 것은 넓은 의미에서의 '문장'이었다고 생각합니다.

• 책을 읽는다.
• 논문을 읽는다.
• 매뉴얼을 읽는다.
• 사양서(Specification)를 읽는다.
• 사례를 읽는다.

인간은 그러한 문장을 읽고, 이해하고, 자신의 상황에 맞춰 해석하여 행동으로 연결해 왔습니다.

이런 의미에서, 문장은 인류의 집단 지성을 지탱하는 중요한 형식이었습니다.

하지만 AI 에이전트가 자연어로 작성된 절차를 읽고, 그것을 바탕으로 실제 작업을 수행하게 되면, 이 구조에 약간의 변화가 생깁니다.

지식은 단순히 읽히는 것이 아니게 되기 시작합니다.

그것은 선택되고, 실행되며, 때로는 실패하고, 수정되며, 재사용되는 것이 되어갈지도 모릅니다.

문장으로서 축적되어 온 집단 지성

인간 사회에서의 지식 발전을 되돌아보면, 문장은 압도적으로 중요한 역할을 수행해 왔습니다.

서적, 논문, 매뉴얼, 법률, 설계서 등등.

이것들은 모두 개인이나 조직의 경험을 타자가 참조하고, 이해하고, 재사용할 수 있는 형태로 변환하기 위한 메커니즘입니다.

예를 들어, 어떤 숙련자가 오랜 경험을 통해 "이런 경우에는 이렇게 판단해야 한다"라는 지견을 얻었다고 가정해 봅시다.

그 지견이 본인의 머릿속에만 있다면 그것은 개인의 지혜에 머뭅니다.

하지만 그것이 문장화되어 공유되고, 타인에게 읽히고, 비판받고, 개선되며, 다른 문맥에서 재사용되게 되면 그것은 집단 지성의 일부가 됩니다.

이런 의미에서 문장은 인류의 지적 진화에 있어 중요한 압축 형식이었습니다.

• 복잡한 경험을 압축한다
• 언어로 고정한다
• 타인에게 공유한다
• 다른 문맥에서 재사용한다
• 더욱 개선한다

이 사이클을 통해 인간 사회는 지식을 축적해 왔습니다.

다만, 문장에는 지금까지 한 가지 커다란 전제가 있었습니다.

그것은 문장을 읽고 실행하는 주체가 기본적으로 인간이라는 점입니다.

매뉴얼은 인간이 읽고 작업하기 위한 것이었습니다.

논문은 인간이 읽고 이해하여 연구나 설계에 활용하기 위한 것이었습니다.

설계서는 인간이 읽고 논의하여 구현(Implementation)으로 변환하기 위한 것이었습니다.

즉, 문장은 지식의 저장 매체이기는 하지만, 그 자체가 직접 작업을 수행하는 것은 아니었습니다.

지식과 행동 사이에는 인간의 이해와 판단이 끼어 있었던 것입니다.

그렇다면 인류의 지식 공유는 모두 "지식과 그 수행 사이에 인간의 이해와 판단이 끼어 있었던" 것이었을까요? 최근에는 그렇지 않다고 할 수 있는 형태가 출현하기 시작했습니다.

소프트웨어는 이미 "실행 가능한 지식"이었다

어떤 관점에서 보면, 인류는 이미 "문장으로서의 지식"에서 "실행 가능한 지식"으로의 커다란 이행을 경험하고 있다고도 할 수 있습니다.

그것이 바로 소프트웨어입니다.

소프트웨어는 단순한 설명이 아닙니다.

실제로 동작합니다.

어떤 처리 절차, 판단 조건, 예외 처리, 데이터 구조, 인터페이스, 테스트, 운용상의 전제가 코드(Code)라는 형태로 기술되어 계산기에 의해 실행됩니다.

그런 의미에서, **소프트웨어는 매우 강력한 "실행 가능한 지식"**이었습니다.

특히 오픈 소스 소프트웨어(Open Source Software)는 단순한 프로그램의 공유가 아니었습니다.

그곳에는 코드, issue, pull request, 리뷰, 테스트, 버그 보고, 릴리스 이력, 문서, 설계 판단이 결합되어 있었습니다.

그 프로세스를 통해 소프트웨어는 실패하며 개선되고 성숙해 갑니다.

그런 의미에서 GitHub와 같은 메커니즘은, 실행 가능한 지식을 전 세계 사람들이 공동으로 육성하기 위한 사회적 인프라라고도 할 수 있습니다.

• 코드가 동작한다
• 버그는 기록된다
• 수정 사항은 이력(history)에 남는다
• 논의는 issue나 pull request에 남는다
• 개선 사항은 버전(version)으로서 축적된다

이것은 상당히 고도화된 "실행 가능한 집단지성"의 형태였다고 생각합니다.

하지만 소프트웨어에는 큰 제약이 있었습니다.

그것은 읽고 쓰는 과정에 참여할 수 있는 사람이 기본적으로 프로그래머로 한정되어 있었다는 점입니다.

소프트웨어는 실행 가능하지만, 컴퓨터를 위해 작성되었습니다.

특정 프로그래밍 언어를 이해하고, 의존 라이브러리(dependency library)와 실행 환경을 갖추고, 빌드(build)하고, 테스트(test)하고, 디버깅(debug)해야 합니다.

경우에 따라서는 프로그래머라 할지라도 거대한 코드베이스(codebase)를 정확히 읽고 개선하는 것이 쉽지 않습니다.

즉, 오픈 소스 소프트웨어(Open Source Software)는 강력한 실행 가능한 집단지성이었지만, 그 입구는 여전히 상당히 좁았습니다.

실행 가능한 지식은 맞았습니다.

하지만 그 지식을 읽고, 쓰고, 개선하기 위해서는 높은 전문성이 필요했습니다.

skills는 "실행 가능한 작업 단위"를 민주화할지도 모른다

AI 에이전트에서의 skills는 이 구조를 더욱 변화시킬 가능성이 있습니다.

여기서 말하는 skill이란, AI 에이전트에게 "이 종류의 작업을 할 때는 이렇게 생각하고, 이렇게 진행하며, 이렇게 확인하라"고 전달하기 위한, 재사용 가능한 작업 절차와 같은 것입니다.

단순한 일회성 프롬프트(prompt)가 아닙니다.

어떤 작업을 수행하기 위한 절차, 적용 조건, 판단 기준, 제약 사항, 참조 자료, 경우에 따라서는 스크립트(scripts)나 도구(tools)까지 포함된 응집력 있는 지식 단위입니다.

예를 들어, 다음과 같은 skill이 있을 수 있습니다.

• 기술 조사를 수행하는 skill
• 장애 대응의 초기 분류(切り分け, triage)를 수행하는 skill
• 문장 구성을 리뷰하는 skill
• 계약서의 리스크 항목을 확인하는 skill
• 고객 대응 방침을 정리하는 skill

이것들은 인간이 읽는 매뉴얼과도 닮아 있습니다.

하지만 결정적으로 다른 점은, AI 에이전트가 그것을 직접 읽고 작업에 사용할 수 있다는 점입니다.

즉, skill은 지식인 동시에 행동을 위한 단위이기도 합니다.

그리고 소프트웨어와 달리, skills는 자연어(natural language)를 중심으로 기술할 수 있습니다.

물론 좋은 skill을 작성하려면 리터러시(literacy)가 필요합니다.

AI 에이전트의 동작, 도구(tool)의 사용법, 권한, 실행 환경, 실패 패턴을 이해해야 합니다.

그럼에도 불구하고 프로그래밍 언어로 소프트웨어를 작성하는 것보다는 훨씬 더 많은 사람에게 열려 있을 가능성이 있습니다.

• 업무 숙련자
• 편집자
• 연구자
• 디자이너
• 법무 담당자
• 고객 지원(Customer Support) 담당자
• 의료 및 교육 전문가

현장에서 수없이 많은 실패와 개선을 반복해 온 사람들

그러한 사람들이 자신들의 판단 절차나 확인 관점, 실패 패턴을 자연어를 중심으로 한 skill로 기술하여 AI 에이전트에게 사용하게 할 수 있게 될지도 모릅니다.

만약 그렇다면, skills는 "실행 가능한 작업 단위의 민주화"를 한 단계 더 진전시킬 가능성이 있습니다.

소프트웨어는 실행 가능한 지식을 만들었습니다.

하지만 그 읽고 쓰는 작업은 주로 프로그래머의 영역이었습니다.

skills는 자연어를 통해 실행 가능한 작업 단위의 읽고 쓰는 과정을 더 넓은 사람들에게 개방할지도 모릅니다.

이것은 단순한 노코드(no-code)나 자동화 도구의 연장이 아니라고 직감합니다.

오히려 인간의 경험과 판단, 그리고 실패로부터 얻은 실무 지식을 AI 에이전트가 이용 가능한 형태로 축적해 나가기 위한 새로운 지식 매체가 아닐까 하는 생각이 듭니다.

하지만 공유되는 것만으로는 집단지성이 아니다

다만, 여기서 한 가지 중요한 문제가 있습니다.

skill은 공유되는 순간 바로 집단지성이 되는 것이 아닙니다.

하물며 신뢰할 수 있는 실행 가능한 집단지성이 되는 것도 아닙니다.

단순히 "괜찮아 보이는 절차"가 작성되어 GitHub나 마켓플레이스(marketplace)에 놓여 있는 것만으로는, 그것이 아직 진정한 의미에서 성숙한 지식이라고 볼 수 없다고 생각합니다.

이는 소프트웨어에서도 마찬가지였습니다.

코드가 공개되어 있다고 해서 반드시 신뢰할 수 있는 소프트웨어인 것은 아닙니다.

실제로 사용되고, 버그가 발견되고, issue가 제기되고, pull request가 만들어지고, 리뷰되고, 테스트가 추가되며, 릴리스(release)를 거듭함으로써 조금씩 신뢰할 수 있는 것이 되어 갑니다.

skill도 마찬가지가 아닐까요?

신뢰할 수 있는 실행 가능한 집단지성의 단위가 되기 위해서는, skill은 충분한 실패 이력을 가지고 있어야 하며, 그 이력을 통해 개선되고, 나아가 스스로가 어떤 조건에서 파탄 나는지를 명시하고 있어야 합니다.

여기서 말하는 실패 이력이란 단순한 에러 로그(error log)가 아닙니다. 그것은,

• 해당 skill이 어떤 상황에서 오용되었는지
• 어떤 전제를 오해했는지
• 어떤 장면에서 인간에게 확인해야 했는지
• 어떤 tool의 결과를 과신했는지
• 어떤 환경에서는 제대로 작동하지 않았는지
• 어떤 수정을 통해 재발을 방지했는지

그러한 경험의 축적입니다.

이러한 실패 이력과 개선 이력을 가져야 비로소, skill은 단순한 '공유된 절차'에서 '신뢰할 수 있는 실행 가능한 지식'으로 다가갈 수 있는 것이 아닐까 생각합니다.

실패의 지식은 어디에 축적되어 왔는가

여기서 중요한 것은, 숙련자의 지식 중 상당수는 성공 절차만으로 이루어져 있지 않다는 점입니다.

오히려 실무에서의 판단 중 상당 부분은 과거의 실패 기억에 의해 지탱되고 있다고 생각합니다.

예를 들어, 프로그래머로서 어떤 아키텍처(architecture)상의 판단을 하려고 할 때, 갑자기 과거의 아픈 기억이 되살아날 때가 있습니다.

"그때 이것과 비슷한 DB 스키마(DB schema)로 만들었다가, 나중에 확장성이 없어서 고생했었지"

"그 설계는 처음에는 깔끔해 보였지만, 운영이 시작되자 예외 케이스(exception case)를 견디지 못했어"

"그 추상화(abstraction)는 편리해 보였지만, 반년 뒤에는 아무도 이해할 수 없게 되었지"

이러한 기억은 반드시 명시적인 규칙으로서 언어화되어 있는 것은 아닙니다.

하지만 판단의 순간에는 확실히 작동하고 있습니다.

어떤 선택지에 대해 이유를 완전히 설명하지 못한 채 "이것은 위험하다"라고 느끼는 것.

어떤 설계에 대해 과거의 실패와 닮은 냄새를 느끼는 것.

어떤 절차에 대해 "이대로 진행하면 나중에 막히겠다"라고 직감하는 것.

이러한 지식은 성공 사례의 지식이라기보다, 실패를 통해 몸에 새겨진 지식입니다.

숙련공이나 장인의 세계에서도 마찬가지일 것입니다.

도구를 다루는 법, 힘을 주는 법, 소재의 특성, 위험한 징후, 해서는 안 될 절차.

그것들 중 상당수는 교과서에 완전한 형태로 적혀 있다기보다, 현장에서의 경험, 실패, 질책, 관찰, 모방을 통해 전해져 온 것들입니다.

즉, 인간 사회에서는 실패로부터 얻은 지식의 상당 부분이 사제 제도, 직장에서의 실습, 리뷰(review) 문화, 현장의 대화, 암묵지(tacit knowledge)로서 전승되어 왔습니다.

반면, 그러한 실패의 지식은 공공의 지식으로서 축적되기 어려운 경향이 있습니다.

성공 사례는 공개되기 쉽습니다.

잘 풀린 설계, 깔끔한 아키텍처, 성공한 프로젝트, 세련된 베스트 프랙티스(best practice)는 기사나 책, 컨퍼런스(conference)를 통해 공유되기 쉽습니다.

하지만 실패 사례는 공개되기 어렵습니다.

그곳에는 일종의 편향(bias)이 작용하기 때문입니다.

• 실패는 부끄럽다
• 회사의 신용과 관련이 있다
• 고객 정보나 사내 사정과 결부되어 있다
• 특정 환경에 의존하고 있어 일반화하기 어렵다
• 책임 소재가 문제가 된다

그렇기 때문에 실제로는 조직 내부에서 많은 실패가 공유되고 개선에 활용되고 있다 하더라도, 그것이 공공의 지식으로서 외부로 나오는 일은 제한적입니다.

이 지점이 현재 AI 에이전트(AI agent)의 약함의 일부 근원과 관련이 있을지도 모릅니다.

AI는 대량의 공개 텍스트로부터 학습할 수 있습니다.

하지만 공개되어 있는 지식은 아무래도 성공 사례나 잘 정리된 설명에 치우치기 마련입니다.

실무 속에서 축적되어 온 '아픈 실패의 기억'이나 '이 조건에서는 망가진다'라는 부정적인 지식은 충분히 언어화되지 않았고, 공개되지도 않았습니다.

그렇다면, AI 에이전트가 실세계의 복잡한 작업에서 약점을 보이는 이유 중 하나는 단순히 추론 능력이 부족해서가 아니라, 실패의 경험이 부족하기 때문일지도 모릅니다.

다단계 작업에서는 실패가 연쇄한다

이 문제는 AI 에이전트가 다단계 작업을 수행할 때 특히 커집니다.

단발적인 질문에 답하는 정도라면, 다소의 불확실성이 있더라도 어느 정도 잘하는 것처럼 보일 수 있습니다.

하지만 실세계의 작업은 대부분의 경우 단발로 끝나지 않습니다.

• 조사하기
• 판단하기
• 변경하기
• 확인하기
• 예외 대응하기
• 재판단하기
• 필요하다면 인간에게 되돌리기

이러한 다단계 처리가 연속됩니다.

여기서 만약 하나의 단계의 성공 확률이 95%라고 하더라도, 그것을 10단계로 쌓으면 전체 성공 확률은 약 60%까지 떨어집니다.

즉, 각 단계가 언뜻 높은 정밀도로 작동하고 있더라도, 긴 작업 전체로 보면 실패할 가능성은 급격히 커집니다.

실제 세계의 작업에서는 단순히 "각 단계의 성공 확률이 높다"는 것만으로는 불충분합니다.

중요한 것은 어디에서 실패하기 쉬운지를 알고 있는 것입니다.

• 실패의 징후를 감지할 수 있을 것
• 위험할 때 멈출 수 있을 것
• 인간에게 확인해야 할 조건을 가지고 있을 것
• 복구 계획 (Recovery plan)을 가지고 있을 것
• 그리고 그 실패가 다음 개선에 반영될 것

이런 의미에서, 신뢰할 수 있는 기술 (skill)에 필요한 것은 성공 절차만이 아닙니다.

오히려 실패의 이력, 파탄 조건, 회복 절차, 인간에게 에스컬레이션 (escalation)해야 할 조건이야말로 기술 (skill)을 실용적인 지식 단위로 성숙시키는 것이라고 생각합니다.

그리고 여기서 다음 문제가 발생합니다.

애초에 AI 에이전트가 어떤 기술 (skill)을 언제 읽고, 언제 사용하며, 어떤 절차를 적용하고, 어디에서 실패했는지를 우리는 알 수 있을까요?

실패로부터 배우기 위해서는 우선 실패를 관측할 수 있어야 합니다.

여기에 AI 에이전트 시대의 새로운 관측 가능성 (observability)의 문제가 있는 것이 아닐까 생각했습니다.

기술 (skill)의 관측 가능성 (observability)이란 무엇인가

실패로부터 배우기 위해서는 우선 실패를 관측할 수 있어야 합니다.

이는 소프트웨어에서는 어느 정도 당연한 일로 취급되고 있습니다.

• 로그 (log)가 있다
• 테스트 (test)가 있다
• 스택 트레이스 (stack trace)가 있다
• CI 결과가 있다
• 이슈 (issue)가 있다
• 풀 리퀘스트 (pull request)가 있다
• 디프 (diff)가 있다
• 릴리스 이력 (release history)이 있다

물론 그렇다 하더라도 원인 분석은 쉽지 않습니다.

하지만 적어도 "무엇이 실행되었는지", "어디에서 실패했는지", "어떤 변경이 영향을 주었는지"를 추적하기 위한 메커니즘은 어느 정도 정비되어 있습니다.

반면, AI 에이전트에서의 기술 (skills)은 조금 까다롭습니다.

예를 들어, MCP 등의 도구 호출 (tool call)은 비교적 관측하기 쉽습니다.

왜냐하면 도구 호출 (tool call)은 LLM의 외부로 나가기 때문입니다.

어떤 도구 (tool)가 호출되었는지, 어떤 인자 (argument)가 전달되었는지, 어떤 결과가 반환되었는지, 에러가 발생했는지, 얼마나 시간이 걸렸는지.

이러한 것들은 로그 (log)로 남기기 쉽습니다.

하지만 기술 (skill)의 실행은 LLM의 실행 문맥 (context) 속에 녹아들기 쉽습니다.

• AI 에이전트가 SKILL.md를 읽는다
• 그 내용을 컨텍스트 (context)에 포함시킨다
• 절차나 판단 기준을 자연어적으로 해석한다
• 그리고 그 영향이 출력이나 도구 호출 (tool call) 또는 판단에 반영된다

이때 외부에서 보고 있는 것만으로는 어떤 기술 (skill)이 실제로 효과가 있었는지 알기 어렵습니다.

최종 출력이 기술 (skill)에 따라 나타났다 하더라도, 그것이 정말로 그 기술 (skill)에 의한 것인지는 알 수 없습니다.

여기에 AI 에이전트 시대의 새로운 관측 가능성 (observability)의 문제가 있습니다.

알고 싶은 것은 단순히 "어떤 도구 (tool)가 호출되었는가"만이 아닙니다.

• 어떤 기술 (skill)이 읽혔는가
• 어떤 기술 (skill)을 사용하겠다고 선언했는가
• 어떤 참조 파일 (reference file)을 참조했는가
• 어떤 절차를 따르려고 의도했는가
• 어디를 생략했는가
• 어디에 불확실성이 남아 있는가
• 최종적으로 어떤 기술 (skill)이나 파일 (file)이 작업에 영향을 미쳤다고 에이전트 스스로 생각하고 있는가

이러한 정보가 없다면 기술 (skill)의 실패를 나중에 분석하는 것은 어렵습니다.

그리고 분석할 수 없다면 개선도 할 수 없습니다.

즉, 신뢰할 수 있는 실행 가능한 집단 지성을 만들기 위해서는 기술 (skill) 그 자체뿐만 아니라, 기술 (skill)이 사용되었을 때의 흔적이 필요합니다.

실행 가능한 지식에는 실행의 증거가 필요합니다.

SkillTrace라는 작은 실험

이러한 문제 의식으로부터, 저는 SkillTrace라는 작은 도구를 만들기 시작했습니다.

SkillTrace는 AI 에이전트의 기술 사용 (skill usage)을 관측하기 위한 실험적인 도구입니다.

처음부터 큰 것을 하려는 것이 아닙니다.

기술 레지스트리 (skill registry)를 만드는 것도 아닙니다.

자동으로 사후 분석 (postmortem)을 생성하는 것도 아닙니다.

실패로부터 기술 (skill)을 자동으로 개선하는 것도 아닙니다.

그보다 앞선, 작은 질문에 집중하고 있습니다.

그것은 AI 에이전트가 하나의 실행 (run) 과정 중에서,

• 어떤 기술 파일 (skill file)을 읽었는가
• 어떤 기술 (skill)을 사용하겠다고 선언했는가
• 최종적으로 어떤 기술 (skill)이나 참조 파일 (reference file)이 작업에 영향을 미쳤다고 회고했는가

이것들을 가시화하는 것입니다.

SkillTrace에서는 크게 세 가지 종류의 증거를 비교합니다.

첫 번째는 file access (파일 액세스)입니다.

skill file (스킬 파일)이나 reference file (참조 파일)이 실제로 액세스되었는지를 OS의 기능을 사용하여 관찰합니다.

두 번째는 MCP를 통한 선언입니다.

에이전트에게 "이 skill (스킬)을 사용하기 시작했다", "이 reference (참조)를 읽었다"와 같은 정보를 명시적으로 기록하기 위한 MCP tool (MCP 도구)을 호출하도록 하는 지시를, 원래의 skill file (AGENTS.md / CLAUDE.md) 서두에 일시적으로 삽입합니다.

세 번째는 run (실행)의 마지막 reflection (회고)입니다.

에이전트 스스로 어떤 skill (스킬)이나 reference (참조)가 작업에 영향을 미쳤다고 생각하는지 회고하도록 하는 지시도 일시적으로 삽입합니다.

물론, file access (파일 액세스)는 읽혔다는 것을 보여줄 뿐, 사용되었다는 것을 증명하지는 않습니다.

MCP를 통한 사용 보고는 에이전트의 자기 신고입니다.

reflection (회고) 또한 사후적인 자기 신고입니다.

하지만 이 세 가지 정보 소스를 대조함으로써 이해의 정확도를 높일 수 있습니다. 또한 정보 소스 간의 불일치는 실패 분석의 입구가 됩니다.

SkillTrace는 skill (스킬) 이용의 진실을 증명하는 도구가 아닙니다.

오히려 여러 흔적을 나열하고 그 차이를 관찰하기 위한 작은 실험입니다.

자세한 사용법이나 기술적인 메커니즘에 대해서는 별도의 기사에서 소개하려고 합니다.

여기서 전달하고 싶었던 것은, 이러한 관측 메커니즘이 향후 skill ecosystem (스킬 생태계)의 기초가 될지도 모른다는 깨달음입니다.

실행 로그는 설명 책임만을 위한 것이 아니다

AI 에이전트의 실행 로그라고 하면 흔히 설명 책임(accountability)이나 감사(audit)의 맥락에서 이야기됩니다.

• 왜 그런 판단을 했는가
• 누가 책임을 지는가
• 나중에 검증할 수 있는가
• 부정이나 일탈은 없었는가

물론 그것들도 중요합니다.

하지만 제가 여기서 더 강하게 관심을 두고 있는 것은 조금 다른 측면입니다.

실행 로그는 책임을 묻기 위한 것만이 아닙니다.

실패를 학습 가능한 경험으로 변환하기 위한 소재이기도 합니다.

어떤 skill (스킬)이 실패했을 때,

• 그 실패를 나중에 재구성할 수 있다
• 어떤 전제가 틀렸었는지 생각할 수 있다
• 어떤 절차가 부족했는지 찾아낼 수 있다
• 어떤 조건에서 인간에게 넘겨야 했는지 추가할 수 있다
• 동일한 실패를 방지하기 위한 regression case (회귀 케이스)를 만들 수 있다
• skill (스킬)의 설명이나 적용 조건, reference (참조)를 개선할 수 있다

그렇게 해서 비로소 실패는 단순한 일회성 실패가 아니게 됩니다.

그것은 skill (스킬)을 성숙시키기 위한 재료가 됩니다.

인간의 조직에서도 실패로부터 배우는 문화를 가진 조직과 실패를 숨기는 조직은 장기적인 학습 능력이 크게 달라집니다.

사고 조사, postmortem (사후 분석), 아차 사고(near miss) 보고, 품질 관리, SRE의 incident review (장애 검토).

이것들은 모두 실패를 책임 추궁으로 끝내지 않고, 재발 방지와 조직 학습으로 연결하기 위한 메커니즘입니다.

AI 에이전트의 skills (스킬들)에도 이와 유사한 메커니즘이 필요하지 않을까요?

단, 그러기 위해서는 우선 실패가 관측 가능해야 합니다.

• 어떤 skill (스킬)이 읽혔는가
• 어떤 skill (스킬)이 사용되었다고 선언되었는가
• 어떤 reference (참조)가 영향을 미쳤는가
• 어떤 절차가 실행되었는가
• 어디에서 불확실성이 남았는가
• 어떤 조건에서 파탄 났는가

이것들이 보이지 않는다면 postmortem (사후 분석)을 작성할 수 없습니다.

postmortem (사후 분석)을 작성할 수 없다면, skill (스킬)은 실패로부터 성숙할 수 없습니다.

그리고 실패로부터 성숙할 수 없다면, 그것은 신뢰할 수 있는 실행 가능한 집단 지성이 되기 어렵습니다.

이런 의미에서 skill observability (스킬 관측 가능성)는 skill ecosystem (스킬 생태계)의 상당히 기초적인 레이어가 될 것이라고 생각합니다.

실패 이력을 가진 skill ecosystem (스킬 생태계)를 향해

만약 skills (스킬들)가 정말로 "실행 가능한 작업 단위의 민주화"를 추진하는 것이라면, 다음에 필요해지는 것은 단순히 skill (스킬)을 공유하는 장소가 아니라고 생각합니다.

필요한 것은 skill (스킬)이 실패하고, 수정되고, 평가되고, 재사용되고, 다시 실패하고, 더욱 개선되어 가는 ecosystem (생태계)입니다.

그곳에서 skill (스킬)은 단순한 Markdown 파일 본체만이 아닐 것입니다.

• skill (스킬) 본체
• 적용 조건
• 사용해서는 안 되는 조건
• 필요한 tool (툴) 및 권한
• reference file (참조 파일)
• known failure modes (알려진 실패 모드)
• incident reports (장애 보고서)
• postmortems (사후 분석)
• regression cases (회귀 사례)
• version history (버전 이력)
• trust information (신뢰 정보)

이러한 것들이 결합된, 이력을 가진 지식 단위가 되어갈 것입니다.

성숙한 skill (스킬)이란, 단순히 아름답게 작성된 skill (스킬)이 아니라고 생각합니다.

오히려, 충분히 사용되고, 충분히 실패하며, 그 실패가 기록되고, 개선에 반영되며, 어떤 조건에서 망가지는지가 명시되어 있는 skill (스킬)입니다.

인간 숙련자가 성공의 지식뿐만 아니라, 뼈아픈 실패의 기억을 통해 판단하는 것처럼 말입니다.

신뢰할 수 있는 skill (스킬) 또한, 성공 절차뿐만 아니라 실패 이력을 통해 성숙해가는 것이 아닐까요.

이때, AI 에이전트의 지식 기반은 단순한 prompt sharing (프롬프트 공유)이나 skill marketplace (스킬 마켓플레이스)와는 다른 것이 됩니다.

그것은 실행 가능한 지식에 실행 증거와 실패 이력, 그리고 개선 이력을 결합하는 메커니즘입니다.

서적이 문장으로서의 집합 지식을 축적해 왔다면,

소프트웨어가 실행 가능한 지식을 전 세계적으로 공동 개발하는 길을 열었습니다.

그리고 skills (스킬)는 자연어를 통해 더 넓은 사람들이 실행 가능한 작업 단위를 기술하고, 공유하고, 개선하는 길을 열지도 모릅니다.

하지만 그러기 위해서는 실패로부터 배울 수 있는 메커니즘이 필요합니다.

그리고 실패로부터 배우기 위해서는, 우선 관측할 수 있어야 합니다.

SkillTrace는 그를 위한 작은 첫걸음입니다.

이제 막 시작된 변화

물론, 이것은 아직 시작된 지 얼마 되지 않은 이야기입니다.

현재의 AI 에이전트는 아직 불안정합니다.

skills (스킬)도 성숙했다고 말하기 어렵습니다.

skill (스킬)을 쓰는 법도, 평가하는 방법도, 공유하는 방법도, 실패 이력을 다루는 법도 아직은 거의 맨땅에 헤딩하는 수준입니다.

게다가 실패 이력을 어떻게 공유할 것인가에는 어려운 문제가 있습니다.

실패에는 기밀 정보가 포함될 수 있습니다.

회사나 고객의 신용과 직결될 수 있습니다.

특정 환경이나 문맥에 강하게 의존할 수도 있습니다.

그대로 공개할 수 없는 경우도 많습니다.

따라서 모든 실패를 그대로 공공의 지식으로 만들 수는 없습니다.

하지만 추상화할 수 있는 실패도 있습니다.

익명화할 수 있는 패턴도 있습니다.

일반화할 수 있는 파탄 조건도 있습니다.

공유할 수 있는 recovery pattern (복구 패턴)도 있습니다.

앞으로 중요해지는 것은 실패 그 자체를 단순히 노출하는 것이 아니라, 실패로부터 얻은 배움을 재사용 가능한 형태로 변환하는 것이라고 생각합니다.

인류의 지식 축적은 지금까지 문장을 중심으로 발전해 왔습니다.

문장은 경험을 압축하고, 공유하고, 재사용하기 위한 강력한 형식이었습니다.

그 일부는 소프트웨어가 되어 실행 가능해졌습니다.

소프트웨어는 지식을 컴퓨터 위에서 구동하며, issue (이슈)나 pull request (풀 리퀘스트), 테스트를 통해 실패하며 개선되는 지식 단위를 만들어냈습니다.

그리고 지금, AI 에이전트와 skills (스킬)를 통해 자연어로 쓰인 지식이 더욱 직접적으로 실행으로 연결되려 하고 있습니다.

만약 이 흐름이 계속된다면, 앞으로 중요해지는 것은 단순히 "좋은 문장을 쓰는 것"이나 "좋은 skill (스킬)을 공유하는 것"만이 아닐지도 모릅니다.

오히려,

• 어떻게 사용되었는가
• 어디서 실패했는가
• 어떻게 개선되었는가
• 어떤 조건에서 신뢰할 수 있는가
• 어떤 조건에서는 인간에게 되돌려줘야 하는가

그러한 이력을 가진, 실행 가능한 작업 단위를 축적해 나가는 것.

그것이 인류 지식 축적의 다음 단위가 될 가능성이 있습니다.

물론 문장이 없어지는 것은 아닙니다.

오히려 문장은 앞으로도 계속 중요할 것입니다.

특히 새로운 개념을 사회적으로 고착화한다는 역할은 더욱 고도화된 skill (스킬)을 실현하기 위해 필수적입니다.

다만, 문장은 단독으로 읽히는 것에 그치지 않고, skill (스킬)의 일부가 되어 실행 문맥에 매몰되며, 실패 이력 및 개선 이력과 결합되어 갈지도 모릅니다.

다음 시대의 지식은 그저 쓰이기만 하는 것이 아니라, 실행된다.

실행되기만 하는 것이 아니라, 실패한다.

실패하기만 하는 것이 아니라, 그 실패를 통해 개선된다.

그리고 그 이력째로 재사용된다.

만약 그렇다면, 우리는 지금 인류의 지식 축적 형식이 조금씩 변하기 시작하는, 꽤 흥미로운 변혁기에 와 있는 것일지도 모릅니다.

그렇게 생각하니 조금 설레지 않나요?

토론 (Discussion)