Data Eng Wiki

Agent Skills and Paved Paths

10 min read

Agent Skills and Paved Paths

Build it and they won’t come — 개발자들은 Skill이 존재하는 줄 몰랐고, 에이전트가 제안하지 않았다

핵심 개념

Agent Skill은 언어 모델에게 특정 작업을 어떻게 수행할지 가르치는 재사용 가능한 playbook이다. 플랫폼 팀이 사내 워크플로(스트리밍 앱 생성, 파이프라인 배포, 서비스 scaffold)를 Skill로 패키징하면 에이전트가 코드 생성·설정 검증·로컬 실행·PR 생성을 대신한다.

핵심 통찰은 문제가 코드를 쓰는 것이 아니었다는 점이다. Etsy의 Kafka 사례에서 어려웠던 것은 Java나 YAML 작성이 아니라 올바른 스키마 고르기, 정확한 base class 식별, 입력 검증, 엣지 케이스 예상, 로컬 테스트 실행이었다. 정적 템플릿이 파일을 생성할 수는 있어도 이 반복적이고 시간 소모적인 과정을 매끄럽게 만들지는 못한다.

무엇을 에이전트에게, 무엇을 스크립트에게

가장 중요한 설계 결정은 경계다.

에이전트가 다루는 것 (모호한 부분)
  · 개발자 요청 이해
  · 소스 스키마와 필드 식별
  · 어떤 검증 단계를 돌릴지 결정
        ↓ 구조화된 tool call
스크립트·hook이 다루는 것 (결정론적 부분)
  · 버전된 scaffolding
  · 템플릿 코드 생성
  · 검증 도구 실행

에이전트는 오케스트레이션을 담당하고, 애플리케이션이 소유한 코드가 실제 생성을 수행한다. strict tool use로 입력을 JSON 스키마에 제약할 수 있다.

목표는 에이전트가 애플리케이션을 처음부터 발명하는 것을 막는 것이다.

보안 연구가 이 경계를 지지한다

  • 2023년 Stanford 연구: 어시스턴트를 쓴 개발자는 덜 안전한 코드를 썼고, 동시에 자기 코드가 안전하다고 생각할 가능성이 더 높았다
  • BaxBench: 백엔드 과제 392개, 모델 11개에서 최고 모델의 기능적 정확도는 62%였지만 어떤 모델도 정확하면서 동시에 안전한 코드를 37% 초과로 생산하지 못했고, 기능적으로 정확한 프로그램의 약 절반을 익스플로잇할 수 있었다

“도는 코드”와 “안전한 코드” 사이의 격차가 실증적으로 크다는 것이, 생성을 결정론적 스크립트에 맡기는 근거다.

채택이 진짜 문제다

Skill을 만들고 데모하고 만족했는데 아무도 쓰지 않았다. 이유를 물었더니 답은 단순했다 — “그냥 존재를 몰랐다.” 개발자들은 코딩 에이전트를 쓰고 있었지만 에이전트가 Skill을 제안한 적이 없었다.

왜 제안되지 않았나

기존 워크플로의 모양이 원인이다. Skill 이전 표준 흐름은 “가장 가까운 기존 코드를 찾아 복사하고 필드를 고치기”였다. 그래서 개발자는 LLM을 열고 “새 스트리밍 피처를 만들고 싶어”로 시작하지 않는다. 대신 옛 프로세스의 중간에 에이전트에 개입한다.

“이 클래스를 복사해서 cart moves를 세도록 바꿔줘” “이 파일을 편집해줘” (경로는 이전 PR에서 복사)

두 번째 원인은 어휘다. 요청이 개발자 팀이 쓰는 말로 도착한다 — 특정 feature-store 항목 이름, 내부 이벤트 이름, 필요한 부모 클래스 이름, 출력 데이터 타입.

해법 — 진입점을 열거하라

  • 서로 다른 어휘에 대한 진입점
  • 라이프사이클 단계별 진입점 (처음부터 시작하는 요청뿐 아니라 중간 개입도)
  • 복붙 모양 요청에 대한 진입점
  • repository-level 라우팅 — 관련 파일을 건드리는 것 자체가 Skill의 트리거

개발자는 자연스럽게 하던 대로 작업을 설명하고, 에이전트가 paved path를 제안한다.

이것이 “paved path”의 진짜 의미다. 좋은 경로를 만드는 것만으로는 부족하고, 사람들이 실제로 걷는 자리에 그 경로 입구를 놓아야 한다.

Observability — 무엇이 쓰이는지 모르면 개선할 수 없다

Skill이 호출되면 hook이 발화해 started 이벤트를 방출하고, 에이전트가 PR을 열면 wrapper가 완료 이벤트를 방출한다. 두 이벤트를 기존 이벤트 파이프라인으로 흘려 분석 테이블에 저장한다.

이것이 답하는 질문:

  • 어떤 Skill이 얼마나 쓰이나
  • 어디까지 PR에 도달하나 (invoke → PR 전환율)
  • 어떤 환경·앱 유형이 관여하나
  • 개발자가 여전히 지원을 필요로 하는 곳은 어디인가

그리고 결정적으로 discoverability 수정이 실제로 통했는지를 측정할 수 있게 한다.

에이전트가 커밋하기 시작하면 권한을 조여야 한다

에이전트가 우리 대신 커맨드를 돌리고 코드를 커밋하게 되면 least privilege가 필수가 된다. 에이전트는 수행 중인 작업에 필요한 접근만 얻어야 한다.

막아야 할 것 (사람이든 에이전트든):

  • 중요한 토픽·리소스 삭제
  • 예상치 못한 대상에 쓰기
  • 무관한 파이프라인 변경
  • 정상적인 프로덕션 리뷰 경로 우회

→ AI Agent Identity and Security

경계 — skill과 loop은 다른 축이다

계층으로는 agent harness < loop < factory model 이고 Skill은 harness의 구성 요소지만, loop과 나란히 놓고 보면 둘은 직교한다.

Agent SkillsLoop Engineering
다루는 축지식 — 이 작업 하나를 어떻게 올바르게 하는가시간 — 언제 발화하고, 다음에 뭘 하고, 언제 멈추는가
전제사람이 부르든 루프가 부르든 동일내가 안 보는 동안 돈다
핵심 설계 결정에이전트(모호) ↔ 스크립트(결정론) 경계maker/checker 분리, 정지 조건, 상태를 디스크에
대표 실패아무도 안 씀 (discoverability)comprehension debt, cognitive surrender
없으면루프가 매 사이클 프로젝트를 처음부터 재유도매번 사람이 다음 프롬프트를 타이핑

Skill은 루프를 필요로 하지 않는다. Etsy 사례에서 Skill이 로컬 실행 전체를 오케스트레이션한다 — 테스트 토픽 생성, JAR 빌드, 커맨드 실행, 결과 읽기, findings 보고, 출력 링크 생성. 개발자는 그 중 아무것도 하지 않고, 루프도 없다.

둘이 합쳐질 때: Skill이 loop의 진입점이 되면 이 페이지의 discoverability 문제가 루프의 커버리지 문제로 바뀐다 — 루프가 집어 갈 수 있는 일의 범위가 곧 진입점의 범위다. 진입점을 열거하는 작업(어휘·라이프사이클·복붙 모양·repo 라우팅)이 그대로 루프의 작업 발견 범위를 정한다.

연관 개념

Source: Kafka App - Theres a Skill for That, Agent Harness vs Loop vs Graph Engineering

그래프 뷰

백링크