유틸리티 함수 하나를 고쳤는데 CI가 2,000개의 Playwright 테스트를 돌리기 시작한다. 45분 뒤 초록불. 개발자라면 누구나 겪어본 풍경이다. 이건 도구 문제가 아니다. 정보 문제다. CI는 어떤 테스트가 내 변경에 의존하는지 모르기 때문에, 그냥 전부 돌린다.
최근 dev.to에 소개된 ast-impact-mapper-mcp는 이 문제를 AST(추상 구문 트리) 기반으로 정면 돌파한다. TypeScript 프로젝트의 임포트 그래프를 ts-morph로 파싱해 순방향·역방향 의존성 그래프를 구축하고, 변경된 파일로부터 BFS 탐색을 통해 실제로 영향받는 테스트만 추려낸다. 파일명이나 폴더 구조에 의존하는 휴리스틱이 아니라, 실제 의존성 경로를 정밀하게 추적하는 방식이다.
더 흥미로운 건 이 도구가 MCP(Model Context Protocol) 서버로 구현되어 Claude와 Cursor에 직접 연결된다는 점이다. get_affected_tests, explain_impact, get_coverage_gaps 등 8개 툴이 AI 어시스턴트에 노출되면서, 개발자는 자연어로 이렇게 물을 수 있다. "DateHelper.ts를 바꾸려는데, 어떤 테스트를 돌려야 해?" AI는 의존성 그래프를 탐색해 "4개 테스트만 실행하면 됩니다" 라고 답한다. 45분짜리 피드백 루프가 2분으로 압축되는 건 테스트를 빠르게 돌려서가 아니라, 돌릴 테스트를 정확히 골라냈기 때문이다.
이 사례가 보여주는 건 단순한 CI 최적화 이상이다. AI가 코드베이스의 구조적 맥락을 실시간으로 이해하고, 개발자의 의사결정을 정보로 뒷받침하는 '맥락 인식 동반자' 로서의 역할이다. explain_impact가 "checkout.spec.ts는 CartPage → PriceCalc를 거쳐 변경 파일에 연결됩니다" 라고 인과 경로를 설명할 때, AI는 단순 도구가 아니라 코드 변경의 파급 효과를 함께 추론하는 파트너가 된다.
워크플로우 설계 관점에서 더 근본적인 통찰은 같은 날 dev.to에 올라온 또 다른 글에서 나온다. 저자는 Kibana, Datadog, JIRA, GitHub를 넘나들며 장애 조사 리포트를 수동으로 엮던 경험을 이렇게 회고한다. "조사와 추론은 재밌는데, 다섯 번 같은 시간 구간을 입력하고 로그를 붙여넣는 건 재미없다." 핵심은 여기서부터다. 그는 복잡한 스킬을 처음부터 설계하지 않았다. 대신 AI와 함께 실제 업무를 한 번 수행하고, 그 대화 자체를 스킬의 명세로 삼았다.
"스킬을 설계하려 하지 말고, 발견하라." 이 원칙은 프로토타이핑 방법론 전체를 뒤집는다. 일반적인 접근은 요구사항 → 설계 → 구현 순서지만, AI와 함께라면 실행 → 관찰 → 추출 순서가 더 효과적이다. AI와 실제 장애 조사를 한 번 돌리고, 끝에 "이 대화를 스킬로 만들어줘" 라고 말하면 issue-investigator 스킬이 탄생한다. 그 스킬은 다음 조사에서 5분 안에 리포트를 내놓는다. 처음부터 완벽한 설계를 목표로 한 게 아니라, v1을 실전에서 찾아낸 것이다.
두 사례를 나란히 놓으면 AI 워크플로우 설계의 공통 원형이 드러난다. 문제를 정보 문제로 재정의하고 → AI에게 맥락을 연결하고 → 반복 속에서 점진적으로 고도화하는 흐름이다. AST Impact Mapper는 의존성 맥락을 AI에 연결함으로써 테스트 선택이라는 판단을 AI와 분담한다. Claude Skills 접근법은 업무 흐름의 맥락을 대화 속에 녹여 자동화 가능한 패턴을 추출한다. 두 경우 모두 AI를 완성된 솔루션 실행기로 쓰는 게 아니라, 탐색과 정제의 과정에 함께 끌어들이는 방식이다.
프론트엔드 개발자 입장에서 실무 시사점은 명확하다. 첫째, 반복적으로 느리거나 귀찮은 작업이 있다면, 그것이 AI 워크플로우 설계의 출발점이다. 설계를 먼저 고민하기 전에, AI와 함께 그 작업을 한 번 실제로 수행해보는 것이 훨씬 빠른 경로다. 둘째, MCP처럼 AI 어시스턴트에 직접 연결되는 도구들이 늘어나면서, 코드베이스의 구조적 맥락을 AI가 얼마나 이해할 수 있느냐가 워크플로우 품질을 결정하는 핵심 변수가 되고 있다. get_coverage_gaps가 커버리지 실행 없이도 정적으로 미테스트 코드를 찾아내듯, 맥락이 풍부할수록 AI의 제안은 더 정밀해진다.
전망은 이렇다. 빠른 프로토타이핑 → 사용자 검증 → 고도화라는 흐름은 프로덕트 개발의 오래된 원칙이지만, AI 워크플로우 설계에서도 동일하게 적용된다. 한 번의 완벽한 설계보다 실전에서 발견하고, 쓸수록 날카로워지며, 팀 전체로 퍼지는 스킬이 결국 더 강력하다. AI가 동반자가 된다는 건 단순히 코드를 빠르게 생성한다는 의미가 아니다. 어디서 멈춰야 하는지, 무엇을 더 깊이 파야 하는지, 어떤 패턴이 반복되는지를 함께 인식하는 협업 구조를 만드는 일이다. 그 구조를 설계하는 역량이, 앞으로 개발자의 가장 중요한 차별점이 될 것이다.