Kafka App? There’s a Skill for That
Author: Isobel Scott (Etsy) | Source: etsy.com/codeascraft | Published: 2026
한 줄 요약
Kafka 스트리밍 앱 생성을 Agent Skill로 만들었더니 잘 동작했지만 아무도 쓰지 않았다 — 개발자들은 존재를 몰랐고, 에이전트가 그것을 제안하지 않았기 때문이었다.
핵심 주장/내용
- 문제는 Java나 YAML을 쓰는 게 아니었다: 올바른 스키마를 고르고, 정확한 base class를 식별하고, 입력을 검증하고, 엣지 케이스를 예상하고, 로컬 테스트를 돌리는 것이었다. 정적 템플릿이 파일을 생성할 수는 있어도 이 반복적이고 시간 소모적인 과정을 매끄럽게 만들지는 못한다
- Kafka Skills = 개발자와 LLM이 협업하는 대화형 워크플로. 자연어나 슬래시 커맨드(
/new-streaming-feature)로 호출. 각 스트리밍 피처 파이프라인에 대해 에이전트가 공유 인터페이스를 구현하는 Java 클래스를 만들고, YAML 설정은 빈칸 채우기이며, scaffolding 스크립트·템플릿 코드 생성·자체 제작 도구로 결정론적 코드를 출력 - 로컬 실행 오케스트레이션까지: 개발자가 더 이상 테스트 토픽을 만들고, JAR을 빌드하고, 수동 커맨드를 채우고, 테스트 토픽에서 읽을 필요가 없다. 에이전트가 다 하고 findings를 보고하고 관련 출력 링크를 생성한다
- Observability: Skill이 호출되면 hook이 발화해 Python 헬퍼가
started이벤트를 방출하고, PR을 열면 wrapper가 완료 이벤트를 방출. 두 이벤트가 기존 Etsy 서비스를 통해 protobuf 메시지로 Kafka에 발행되고 BigQuery 테이블에 저장 → 어떤 Skill이 얼마나 쓰이고, 어디까지 PR에 도달하고, 어떤 환경·앱 유형이 관여하고, 개발자가 여전히 지원이 필요한 곳이 어디인지 파악 - “Build It and They Won’t Come” — 채택률이 놀랍도록 낮았다. 이유를 물었더니 “그냥 존재를 몰랐다”. 개발자들은 코딩 에이전트를 쓰고 있었지만 에이전트가 Kafka Skills를 제안한 적이 없었다
- 원인은 기존 워크플로의 모양: Skill 이전 표준 흐름은 가장 가까운 기존 피처를 찾아 코드를 복사하고 필드를 고치는 것이었다. LLM을 열고 “새 스트리밍 피처를 만들고 싶어”로 시작하는 대신, 엔지니어는 옛 프로세스의 중간에 에이전트에 개입해 “이 클래스를 복사해서 cart moves를 세도록 바꿔줘”나 이전 PR에서 가져온 경로로 “이 파일을 편집해줘”라고 한다
- 또 하나 — 어휘 문제: 요청이 개발자 팀이 쓰는 어휘로 도착한다. 특정 feature-store 항목, 내부 이벤트 이름, 필요한 부모 Java 클래스 이름, 출력 데이터 타입을 언급하는 식
- 해법: 서로 다른 어휘·라이프사이클 단계·복붙 모양 요청에 대한 진입점을 열거하고, repository-level 라우팅을 추가해 관련 파일을 건드리는 것 자체가 Kafka Skill의 트리거가 되게 했다. 개발자는 자연스럽게 하던 대로 작업을 설명하고 에이전트가 paved path를 제안한다
- Guardrails — 에이전트가 Kafka 애플리케이션을 처음부터 발명하는 것을 막고 싶었다: 에이전트는 모호한 부분을 다룬다(개발자 요청 이해, 소스 스키마·필드 식별, 어떤 검증 단계를 돌릴지 결정). 그다음 구조화된 입력을 버전된 scaffolding 스크립트와 검증 도구에 넘긴다. Anthropic의 tool-use 문서가 기술하는 패턴 — 에이전트가 구조화된 tool call을 반환하고 애플리케이션이 소유한 코드가 그것을 실행하며, strict tool use로 입력을 JSON 스키마에 제약할 수 있다. 에이전트는 오케스트레이션을, 스크립트와 hook은 템플릿 코드 생성을 담당
- 보안 연구가 그 결정을 강화했다: 2023년 Stanford 연구에서 어시스턴트를 쓴 개발자는 덜 안전한 코드를 썼고 동시에 자기 코드가 안전하다고 생각할 가능성이 더 높았다. BaxBench도 “도는 코드”와 “안전한 코드” 사이의 유사한 격차를 발견 — 백엔드 과제 392개, 모델 11개에서 최고 모델이 기능적으로 정확한 비율이 62%였지만 어떤 모델도 정확하면서 동시에 안전한 코드를 37% 초과로 생산하지 못했고, 기능적으로 정확한 프로그램의 약 절반을 연구자들이 익스플로잇할 수 있었다
- 에이전트가 우리 대신 커맨드를 돌리고 코드를 커밋하게 되면서 Kafka ACL·리포지토리 권한·배포 통제를 조여야 했다. 시스템을 least privilege로 설계 — 에이전트는 수행 중인 작업에 필요한 접근만 얻는다. 사람도 에이전트도 중요한 토픽을 지우거나, 예상치 못한 곳에 쓰거나, 무관한 파이프라인을 바꾸거나, 정상적인 프로덕션 리뷰 경로를 우회할 수 없게 하기 위함
주요 수치 / 사실
- Etsy: 560만 활성 판매자의 1억 개 이상 리스팅. 판매 아이템이 고유하고 창의적이라 그것이 무엇인지 알려주는 표준 제품 카탈로그가 없다 — “여름용 가벼운 린넨 원피스”를 검색하면 모델이 쇼퍼의 의도와 리스팅의 내용을 추론해야 하고, 그 재료가 사용자 방문과 리스팅 데이터
- 스트리밍 피처가 테라바이트 규모 토픽에서 이벤트를 필터링하고, 변환 로직을 쓰고, 필터된 토픽을 통해 출력을 feature store에서 쓸 수 있게 만들 것을 요구
- 7개 Kafka 워크플로에 Skill 구축. 근시일 초점은 채택 — 개발자가 작업을 어떻게 표현하든 Skill이 제안되도록 진입점을 계속 추가 중이고, observability 테이블의 초기 인사이트로 discoverability 수정이 실제로 통했는지 확인할 예정
- Kafka가 Etsy에서 ML 피처 생성, 임베딩, 필터링, fan-out, 데이터 저장 등 광범위한 핵심 데이터 워크플로를 지원
관련 위키
- Agent Skills and Paved Paths
- Loop Engineering
- Real-Time Stream Processing
- AI Agent Identity and Security
- Feature Store
- LLM Platform Engineering
Source: 원문 보기