🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

스킬은 새로운 코드입니다: AI 네이티브 개발에서 재사용 가능한 맥락은 모델을 프로그래밍하는 핵심 단위가 되며, 코드처럼 품질·보안·버전·관측 체계로 관리돼야 한다.

📌 핵심 요점

1. 소프트웨어 개발의 중심은 코드 구현에서 의도와 지시로 이동하고 있으며, 모델 위에 도구·맥락·하네스·팩토리 라인을 쌓는 새로운 개발 스택이 형성되고 있다.
2. 도구는 모델이 정보를 찾고 세상과 상호작용하며 실제 변경을 수행하게 만들어 모델을 에이전트로 바꾸고, 특정 작업에서는 비용·속도·정확성 면에서 모델 단독 사용보다 효율적입니다.
3. 맥락은 정책·스펙·워크플로 형태로 모델에 주입되어 에이전트의 시행착오를 줄이고, 스킬은 이 맥락을 재사용 가능한 단위로 만들어 여러 작업과 조직에 확장할 수 있게 한다.
4. 스킬이 빠르게 늘어나면서 보안, 중복, 품질 판별, 환경 차이, 의존성, 유지보수 문제가 커지고 있으며, 단순 공유 저장소만으로는 신뢰 가능한 재사용 체계를 만들기 어렵습니다.
5. 스킬을 문서가 아니라 소프트웨어 조각으로 다루려면 정적 분석, evals, 보안 스캐닝, 패키지 관리, 버전 통제, 런타임 관측성을 포함한 컨텍스트 개발 생명주기가 필요하다.

🧩 배경과 문제 정의

• 소프트웨어 개발의 중심이 코드 작성과 구현 세부사항에서 의도와 지시를 설계하는 방향으로 이동하면서, AI 네이티브 개발에 맞는 새로운 개발 스택이 필요해졌다.
• 모델만으로는 안정적인 작업 수행이 어렵기 때문에, 도구·맥락·하네스·팩토리 라인이 함께 작동해야 에이전트가 실제 행동을 수행하고 반복 가능한 결과를 만들 수 있다.
• 스킬은 재사용 가능한 맥락이자 모델을 프로그래밍하는 단위로 자리 잡고 있지만, 빠른 확산은 품질·보안·거버넌스·유지보수 문제를 함께 키우고 있다.

🕒 시간순 섹션별 상세정리

1. 개발 패러다임 전환과 새 스택의 윤곽

• 콘퍼런스의 핵심 가치는 강연을 듣는 데 그치지 않고, 참석자들이 서로 배우고 협업하는 데 있다 [00:41]
• 강연은 왜 스킬이 새로운 코드가 되는지를 핵심 문제의식으로 제시한다 [00:56]

2. 도구가 모델에 행동 능력과 효율성을 더하는 방식

• 도구는 모델을 에이전트로 전환시키는 소프트웨어 유틸리티다 [02:24]
• 도구는 모델이 외부 세계와 상호작용하고, 정보를 모으며, 실제 변화를 일으키게 한다 [02:39]

3. 맥락의 세 가지 내용 유형과 로딩 방식

• LLM 활용의 핵심은 결국 무엇을 컨텍스트 창에 넣을지에 달려 있다 [03:52]
• 사람이 준비한 맥락은 에이전트가 모르거나 비효율적으로 찾아야 할 정보를 미리 줄여준다 [04:07]

4. 스킬 합성과 워크플로 구성

• 스킬은 도구처럼 서로 합성될 수 있다 [05:45]
• 하나의 스킬이 도구나 다른 스킬을 호출하면서 더 큰 작업 단위를 구성할 수 있다 [06:00]

5. 하네스 통제와 팩토리 라인으로 확장되는 개발 흐름

• 하네스는 에이전트 개발을 확장하기 위한 핵심 구성요소가 된다 [07:49]
• 하네스는 필요한 스킬 로드를 모델의 자율 판단에만 맡기지 않고 제어하는 구조를 만든다 [08:04]

6. 맥락이 새로운 코드가 되고 스킬 생태계가 폭발하는 흐름

• 도구, 하네스, 팩토리 라인, 팩토리는 모두 모델을 감싸는 소프트웨어다 [10:11]
• 새로운 계산 단위는 모델 자체와 그 내부 작동에 직접 주입되는 네이티브 맥락이다 [10:26]

7. 스킬 확산이 보안과 거버넌스 문제로 계속된다

• 많은 기업은 스킬이 계속 늘어나는 상황에서 통제력을 잃고 있다 [12:11]
• 어떤 스킬을 어떻게 관리해야 하는지 명확한 운영 기준도 부족하다 [12:26]
• 스킬은 에이전트가 실제로 실행하는 단위이므로 직접적인 보안 위험이 된다 [12:27]
• 악성 스킬, 안전 경계가 없는 스킬, 정보를 노출하는 스킬이 모두 문제가 될 수 있다 [12:42]

8. 공유 저장소만으로는 재사용과 협업이 안정되지 않는다

• 1,000명 이상의 개발자가 있는 조직에서는 비슷한 목적의 스킬이 반복적으로 만들어진다 [14:03]
• 코드 리뷰, 테스트 생성, 앱 관련 스킬이 중복되면 재사용되지 못하고 협업 효율도 떨어진다 [14:18]

9. 스킬도 소프트웨어처럼 부패하고 유지보수가 필요하다

• 소프트웨어는 유지보수 없이 방치되면 결국 동작하지 않거나 시스템에 해를 끼칠 수 있다 [15:36]
• 스킬 역시 모델, API, 배포 인프라가 바뀌면서 빠르게 낡아간다 [15:51]
• AI 환경에서는 3개월은커녕 2주 만에도 지시가 오래된 것이 될 수 있다 [16:07]
• 효과가 떨어진 스킬은 에이전트를 잘못된 방향으로 이끄는 위험 요소가 된다 [16:22]

10. 스킬 품질 문제는 코드 품질 도구의 적용 대상으로 바뀐다

• 보안, 거버넌스, 재사용, 협업, 라이프사이클 문제는 이미 코드 개발에서 오래 다뤄온 주제다 [17:21]
• 그래서 스킬도 단순한 문서가 아니라 관리 가능한 소프트웨어 조각으로 다뤄야 한다 [17:36]
• 스킬 품질 체계에는 정적 분석, 동적 테스트, 보안 도구, 의존성 관리, 관측성이 포함되어야 한다 [17:50]
• 이러한 도구들이 앞서 언급한 운영상의 문제를 해결하는 기반이 된다 [18:05]

11. 정적 분석은 스킬의 형식, 품질, 보안을 반복 점검한다

• 스킬 린팅은 필드와 형식이 올바르게 작성되었는지 확인한다 [18:54]
• 품질과 보안 측정은 모범 사례를 벗어난 부분을 반복적으로 찾아낸다 [19:09]
• Tessl Review는 스킬이 Anthropic의 모범 사례에 맞는지 점검한다 [19:11]
• progressive disclosure, 간결성, activation 선언의 명확성도 주요 검사 대상이 된다 [19:26]

12. Evals는 스킬 테스트 체계의 중심이 된다

• 테스트 없이 스킬을 빠르게 배포하는 방식은 당장에는 편리해 보일 수 있다 [19:55]
• 그러나 다음 날 수정이 필요해지는 순간, 확장성과 신뢰성의 한계가 드러난다 [20:10]

13. 스킬 품질·보안·공급망 관리가 소비 기준이 된다

• 공유 저장소에서 스킬을 가져다 쓸 때 품질 점수는 중요한 선택 기준이 된다 [24:00]
• 품질 점수는 완벽한 판정은 아니지만, 더 나은 스킬을 고르는 방향을 제시한다 [24:15]

14. 스킬 의존성도 패키지 관리와 버전 통제가 필요하다

• 의존성 관리는 번거롭지만 실제 운영에서는 피할 수 없는 과제다 [25:24]
• 업그레이드는 애플리케이션을 깨뜨리거나 의존성 간 충돌을 일으킬 수 있다 [25:39]

15. 컨텍스트 개발 생명주기와 새로운 에이전트 개발 스택이 완성된다

• 실험실 안에서 테스트, 보안, 최적화를 모두 끝내는 데에는 분명한 한계가 있다 [27:02]
• 따라서 런타임 관측성은 코딩 에이전트의 실제 동작을 확인하고, 컨텍스트 개발 생명주기를 완성하는 마지막 축이 된다 [27:17]

16. 런타임 관측성은 실제 사용 데이터를 다시 컨텍스트 개선으로 되돌린다

• 에이전트를 모니터링하면 현실 세계의 평가 시나리오와 문제를 추출해 스킬을 갱신하고 최적화할 수 있다 [27:20]
• 전체 에이전트 성공 여부를 분석해 새 스킬 기회나 제거해야 할 요소를 찾을 수 있다 [27:34]
• 인간은 컨텍스트 개발 생명주기에 머물고, SDLC는 에이전트가 수행하도록 해야 한다 [27:43]
• 컨텍스트를 만들고 테스트·최적화·패키징·보안 소비·관측한 뒤 반복하는 루프가 핵심이다 [28:05]

17. 에이전틱 개발의 새 스택은 공동으로 구축되는 새 개발 패러다임이다

• 모델은 운영체제, 도구는 유틸리티, 컨텍스트는 새 코드, 하네스는 프레임워크처럼 자리 잡는다 [28:19]
• 하네스들은 반복 입력과 성공 출력이 있는 파이프라인·팩토리로 조합된다 [28:36]
• 스킬을 새 코드로 대하고 그에 맞는 도구와 정신 모델을 갖추는 것이 중요하다 [28:54]
• Tessell은 컨텍스트·하네스·팩토리 라인 개발을 돕는 에이전트를 준비 중이며, 새 개발 패러다임을 함께 만들어가고 있다고 마무리한다 [29:21]

🧾 결론

• 이 강연의 핵심은 “스킬은 새로운 코드”라는 주장입니다. 즉, AI 에이전트를 잘 쓰는 문제는 더 좋은 프롬프트를 쓰는 수준을 넘어, 재사용 가능한 맥락을 설계·검증·배포·관리하는 소프트웨어 공학 문제로 바뀌고 있다.
• 모델 자체만으로는 반복 가능한 품질을 보장하기 어렵기 때문에, 도구는 행동 능력을 제공하고 하네스는 결정적 통제를 제공하며, 팩토리 라인은 여러 하네스와 스킬을 묶어 실제 개발 흐름을 자동화한다.
• 스킬의 확산은 생산성 기회인 동시에 운영 리스크입니다. 악성 스킬, 부주의한 스킬, 오래된 스킬, 중복 스킬은 에이전트의 결과 품질뿐 아니라 보안과 공급망 안정성까지 흔들 수 있다.
• 따라서 조직은 스킬을 “잘 써보는 것”에서 멈추지 않고, 어떤 스킬을 누가 만들고 설치하고 업데이트하며 어떤 결과를 냈는지 추적하는 거버넌스 체계를 갖춰야 한다.
• 강연 내 수치나 사례 중 “GitHub에서 스킬이 약 200만 개까지 늘었다”, “OpenClaw 생태계에서 30%가 넘는 스킬이 악성으로 나타났다”는 내용은 발표자가 제시한 주장으로 정리하되, 외부 의사결정에 활용하려면 원자료 검증이 필요하다.

📈 투자·시사 포인트

• AI 에이전트 시장의 병목은 모델 성능만이 아니라 스킬 품질, 보안, 재사용성, 의존성 관리, 관측성으로 이동하고 있습니다. 따라서 스킬 레지스트리, eval 플랫폼, 보안 스캐닝, 컨텍스트 관리 도구의 중요성이 커질 수 있다.
• 기업 도입 관점에서는 “스킬을 많이 만드는 조직”보다 “스킬을 검증하고 오래 관리할 수 있는 조직”이 더 큰 생산성 우위를 가질 가능성이 있습니다. 공유 저장소만으로는 부족하고, 코드 품질 도구에 준하는 운영 체계가 필요하다.
• 투자 검토 시에는 특정 도구가 단순 프롬프트 저장소인지, 아니면 정적 분석·동적 eval·버전 관리·설치 이력·보안 정책·런타임 관측까지 포함하는지 확인하는 것이 중요한다.
• 비용 측면에서는 eval과 관측성을 통해 어떤 작업에 더 저렴한 모델을 써도 되는지 판단할 수 있으므로, 스킬 관리 체계는 품질 관리뿐 아니라 모델 비용 최적화 수단이 될 수 있다.
• 검증 필요 포인트: 강연에서 제시된 스킬 증가 규모, 악성 스킬 비율, 특정 기업 사례는 방향성 있는 시사점으로는 유용하지만, 실제 투자나 도입 판단에는 별도 데이터와 원문 근거 확인이 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 강연에서 언급된 “GitHub 분석상 스킬이 약 200만 개까지 늘어났다”는 수치는 출처, 분석 범위, ‘스킬’의 정의를 별도로 확인필요가 있다.
• “OpenClaw 생태계에서 30%가 넘는 스킬이 악성으로 나타났다”는 사례는 표본, 측정 기준, 실제 생태계 명칭과 맥락을 검증해야 한다.
• “Intercom은 관련 스킬이 로드되지 않으면 GitHub PR 생성을 막는다”는 사례는 실제 운영 사례인지, 예시적 설명인지 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 조직 내 에이전트가 사용하는 스킬 목록을 수집하고, 각 스킬의 목적·소유자·사용 위치·버전·의존성을 기록한다.
• 스킬을 단순 문서가 아니라 재사용 가능한 코드 단위로 간주하고, 작성·리뷰·배포·폐기 기준을 정의한다.
• 스킬 린팅, 정적 분석, 보안 스캔을 도입해 형식 오류, 과도한 권한, 비밀값 노출 가능성, 모범 사례 위반을 반복 점검한다.
• 핵심 스킬부터 eval 시나리오를 만들고, 실제 작업 성공 여부와 회귀 여부를 검증하는 최소 테스트 체계를 마련한다.

❓ 열린 질문

• 스킬의 품질을 판단할 때 가장 중요한 기준은 간결성, 정확성, 보안성, 재사용성, 실행 성공률 중 무엇으로 우선순위를 둘 것인가?
• 스킬을 조직 내에서 누가 소유하고 유지보수해야 하며, 오래된 스킬을 폐기하는 기준은 어떻게 정할 것인가?
• 모든 스킬에 eval을 요구할 것인지, 아니면 보안·배포·코드 변경처럼 위험도가 높은 스킬에만 우선 적용할 것인가?