대부분의 자동화 프로젝트는 '무엇을 자동화할까'를 기획 회의에서 결정한다. 화이트보드에 후보를 나열하고, 우선순위를 매기고, 구현을 시작한다. 문제는 이 방식이 놓치는 것이 있다는 점이다. 팀이 매일 반복하고 있지만, 아직 이름도 없고 문서화도 되지 않은 작업들. 그것이 진짜 자동화 대상이다.
distill-workflows는 이 문제를 정면으로 건드린다. dev.to에 공개된 이 Claude Code 스킬은 자동화 대상을 기획하는 대신 '발굴'한다. git 커밋 히스토리, 터미널 세션 트랜스크립트(.jsonl), 그리고 리포지토리 메모리(GPS)를 동시에 스캔해 반복 패턴을 추출한다. 빈도, 결정론적 실행 가능성, 마찰 비용을 기준으로 후보를 점수화하고, 인간의 확인을 거쳐 스킬·서브에이전트·워크플로우로 패키징한다.
이 시스템이 자기 자신의 리포지토리에 적용됐을 때 50회 이상 반복된 패턴 하나가 발견됐다. 단일 책임 Android/Kotlin 수정을 동일한 컨벤션(브랜치 네이밍, 커밋 스코프, PR 크기 제한)으로 배포하는 사이클이었다. 누구도 이것을 '반복 작업'이라고 인식하지 못했다. 그냥 하고 있었을 뿐이다. 스캐너는 이를 android-fix-pr 스킬로 패키징했다. 더 흥미로운 건 QA 스윕 패턴이 감지됐지만 이미 파라미터화된 워크플로우가 존재한다는 이유로 패키징을 거부했다는 점이다. 언제 만들지 않을지를 판단하는 것도 자동화의 절반이다.
이 접근 방식이 의미 있는 이유는 설계 철학에 있다. 시스템은 '읽고 제안한다, 확인 후 실행한다'는 원칙을 지킨다. 디스크에 아무것도 쓰지 않고 먼저 후보 테이블을 보여준다. 기존 스킬과 80% 이상 겹치는 후보는 새로 만들지 않고 기존 스킬 확장을 권고한다. 그리고 세션 간 누적 원장(watchlist.md)을 통해 한 세션에서 한 번 발생한 패턴도 시간이 쌓이면 결국 임계치에 도달한다. 이것은 단순한 자동화 도구가 아니라 팀의 작업 패턴을 장기 관찰하는 시스템이다.
같은 시기에 IBK기업은행은 다른 경로에서 같은 결론에 도달하고 있었다. 'IBK AI 붐업 페스타'의 피날레로 열린 AI Day에서는 253개 팀, 731명의 직원이 참여한 AI 에이전트 경진대회 결선이 열렸다. 외화송금 서류 검증, 여신심사 자동화, 불완전판매 탐지—모두 현장 직원이 직접 기획하고 구현한 결과물이다. 기업은행 측은 이를 "현장 직원들이 업무 과정에서 발견한 문제를 직접 AI 기술로 해결하는 문화"라고 정의했다.
두 사례가 공통으로 가리키는 것이 있다. 자동화의 발견은 외부 컨설턴트나 기획팀이 아니라, 그 작업을 반복하고 있는 사람이 가장 잘 한다는 것이다. distill-workflows는 개발자 자신의 작업 히스토리를 분석해 패턴을 뽑아내고, IBK의 직원 참여형 프로그램은 현업 직원이 자신의 페인 포인트를 에이전트로 직접 해결하도록 설계했다. 방법론은 달라도 전제는 같다. 반복 작업을 가장 잘 아는 사람이 자동화 설계자가 되어야 한다.
VS Code의 Agents view는 이 흐름을 IDE 레벨로 끌어들인다. dev.to의 리뷰에 따르면 Agents view는 단순한 자동완성 확장이 아니라, 프로젝트 전체를 스캔하고 멀티 에이전트를 병렬로 실행하며 터미널 명령까지 직접 수행하는 에이전트 전용 워크스페이스다. Copilot이 줄 단위 보조 도구라면, Agents view는 태스크 단위 실행 도구다. 이 차이는 작지 않다. 개발자가 에이전트에게 '이 폴더의 TypeScript 에러 전부 고쳐'라고 지시하고 결과를 검토하는 방식은, AI를 동료 수준의 실행 주체로 대우하기 시작했다는 신호다.
팀 리빌딩 관점에서 이 흐름이 중요한 이유가 있다. AI-First 워크플로우를 설계할 때 가장 자주 듣는 질문이 '무엇을 자동화해야 하나요?'다. 그런데 이 질문 자체가 잘못된 출발점일 수 있다. distill-workflows가 보여주듯, 팀이 이미 반복하고 있는 작업에서 패턴을 발굴하는 것이 훨씬 높은 ROI를 낸다. 기획 회의에서 나온 자동화 후보는 실제 작업 맥락을 반영하지 못하는 경우가 많다. 현장 히스토리 분석이 먼저다.
전망을 냉정하게 짚자면, distill-workflows 같은 접근은 아직 개인 리포지토리 수준에 머물러 있다. 팀 전체의 작업 히스토리를 분석하고, 조직 단위로 패턴을 발굴하고, 공유 스킬 라이브러리를 구축하는 것은 아직 설계가 필요한 영역이다. IBK기업은행이 경진대회 우수작을 '보안성과 시스템 연계 방안을 고려해 고도화할 예정'이라고 밝힌 것처럼, 발굴과 실용화 사이에는 아직 엔지니어링 비용이 존재한다. 하지만 방향은 분명하다. 팀이 AI로 자동화를 발견하는 가장 빠른 방법은, 이미 하고 있는 반복 작업의 히스토리를 AI에게 먼저 보여주는 것이다.