"도구 검색"에서 "기술"로: AI 에이전트 아키텍처의 패러다임 전환 클로드(Claude)가 스킬 규칙을 발표했고, 코덱스(Codex) 또한 스킬 지원을 시작하여 AI 에이전트의 표준 기능으로 자리 잡고 있습니다. 모든 도구를 LLM에 나열하고 LLM이 스스로 선택하도록 하는 방식(즉, "도구 검색")은 한계가 있습니다. 미래의 방향은 기능을 독립적이고 신뢰할 수 있는 "스킬"로 캡슐화하고 보다 정밀한 분류 메커니즘을 통해 호출하는 것입니다. 핵심 논점: "도구 검색" 기능이 왜 사라졌는가? 초기 에이전트 개발에서 개발자들은 모델이 마치 사전을 찾아보듯 "검색"하여 사용할 올바른 도구를 선택할 수 있기를 바라며, 수십 개 또는 수백 개의 함수 호출 정의를 대규모 모델의 프롬프트 컨텍스트에 집어넣는 데 익숙했습니다. 저자는 이 모델에 세 가지 치명적인 결함이 있다고 생각합니다. • 신뢰성 부족: 도구의 수가 증가함에 따라 모델의 주의력이 분산되어 잘못된 도구를 선택하거나 착시 현상을 일으키는 경우가 많습니다. • 확장성 부족: 컨텍스트 창은 제한적이며 비용이 많이 듭니다. 모든 도구 정의를 단일 프롬프트에 담으려고 하면 토큰이 낭비될 뿐만 아니라 모델의 추론 품질도 저하됩니다. • "사용법"에 대한 지식 부족: 단순히 모델에 도구의 API 정의(예: get_weather(city))만 제공하는 것은 불충분합니다. 모델은 "언제 사용해야 하는지", "어떻게 사용해야 하는지", "오류 발생 시 어떻게 처리해야 하는지"와 같은 암묵적인 지식을 알아야 하는 경우가 많지만, "도구 검색" 패턴은 이러한 맥락을 무시합니다. 해결책: 스킬이 새로운 표준이 되고 있습니다. "스킬"은 단순히 도구의 이름을 바꾸는 것이 아니라, 더욱 모듈화되고 체계적인 아키텍처 접근 방식을 의미합니다. "기술"이란 무엇일까요? • 맥락을 포괄합니다: "기술"에는 도구 자체뿐만 아니라 도구 사용을 위한 모범 사례, 구체적인 프롬프트 지침, 심지어 미리 구축된 지식 기반까지 포함됩니다. • 온디맨드 로딩: 스킬이 항상 컨텍스트에 연결되어 있는 것은 아닙니다. 시스템은 필요할 때만 특정 스킬을 모델에 "로드"합니다. 어떻게 작동하나요? (분류 vs. 검색) 저자들은 대규모 모델이 긴 목록을 무작정 검색하도록 내버려두는 대신 분류기나 라우팅 계층을 사용할 것을 권장합니다. • 의도 인식: 사용자가 요청을 하면, 먼저 경량 모델 또는 분류기를 통해 의도를 파악합니다. • 스킬 로드: 분류 결과에 따라 시스템은 해당되는 "검색 스킬 팩" 또는 "프로그래밍 스킬 팩"만 컨텍스트에 불러옵니다. • 정확한 실행: 이 단계에서 메인 모델은 현재 작업과 매우 관련성이 높은 몇 가지 도구와 상세 지침만 보게 되므로 성공률이 매우 높습니다. 요약: AI 개발자를 위한 시사점 에이전트 개발은 "프롬프트 단어 엔지니어링"에서 "소프트웨어 엔지니어링"으로 전환되고 있습니다. • 기존 접근 방식: LLM의 일반화 능력에 모든 희망을 걸고, 혼란 속에서 적절한 도구를 찾아낼 수 있기를 바라는 것. • 새로운 모델(기술): 코딩과 같은 복잡한 작업을 분리합니다. AI에게 망치만 주는 것이 아니라 "망치 사용 설명서"도 함께 제공하고, 못을 박아야 할 때만 망치를 건네줍니다. 이러한 변화로 AI 에이전트는 "가끔씩 즐기는 장난감"에서 "안정적이고 신뢰할 수 있는 생산성 도구"로 탈바꿈했습니다. 기업용 애플리케이션의 경우, 단순히 모델 매개변수를 쌓아두는 것보다 잘 정의되고 명확하게 구축된 "스킬" 라이브러리가 훨씬 더 중요한 자산이 될 것입니다. 원문을 읽어보세요
스레드를 불러오는 중
깔끔한 읽기 화면을 위해 X에서 원본 트윗을 가져오고 있어요.
보통 몇 초면 완료되니 잠시만 기다려 주세요.
