AI 코딩 도구를 '잘 쓰는' 사람과 '잘 엮는' 사람의 차이가 점점 선명해지고 있다. 도구 하나하나의 성능은 평준화되고 있지만, 그것을 팀 단위 워크플로우에 어떻게 구조화하느냐는 여전히 설계의 영역이다. 최근 프론트엔드 개발 현장에서 주목할 만한 세 가지 실천 사례가 등장했다. 각각은 독립적인 문제를 다루지만, 모두 같은 질문을 향하고 있다. "AI가 생성한 코드를 팀이 신뢰하고 유지할 수 있는 구조를 어떻게 만들 것인가."
컨벤션을 한 번만 정의하면 팀 전체가 따른다—Cursor Skills
dev.to에 공개된 Brian Treese의 사례는 Angular 개발 워크플로우에서 반복되는 비효율을 정면으로 건드린다. AI가 생성한 Angular 컴포넌트는 '거의 맞지만 정확히는 틀린' 코드를 자주 뱉어낸다. standalone: true는 Angular v20+에서 기본값이라 불필요한데도 붙고, @Input()·@Output() 데코레이터 대신 함수형 input()·output()을 써야 하고, *ngIf는 @if로 바꿔야 하고, OnPush 변경 감지 전략도 직접 추가해야 한다. 이 수정 작업이 개발자마다 매번 반복되면 팀 전체적으로 드리프트가 쌓인다.
Cursor Skills는 이 문제를 프로젝트 레벨의 규칙 파일로 해결한다. .cursor/skills 디렉토리 안에 SKILL.md 파일을 만들면, AI가 코드를 생성할 때 이 파일을 참조해 팀의 컨벤션을 그대로 따른다. 핵심은 "하지 말아야 할 것"을 명시하는 섹션이다. AI의 기본 습관을 직접 반박하는 이 부분이 실무에서 가장 큰 차이를 만든다고 저자는 강조한다. 그리고 이 스킬 파일은 소스코드에 커밋된다. 즉, 팀 컨벤션이 문서가 아니라 실행 가능한 규칙으로 저장소에 박히는 것이다.
컴포넌트 생성 스킬을 만들었다면 다음은 테스트 생성 스킬이다. Cursor Skills는 조합된다. 스킬 하나가 안정되면 그 스킬이 만든 코드를 입력으로 받는 또 다른 스킬을 붙일 수 있다. 팀의 코딩 스타일이 AI 워크플로우 안에 레이어로 쌓여가는 구조다. 이건 단순한 프롬프트 템플릿이 아니라, 팀의 의사결정을 자동화하는 설계에 가깝다.
AI가 쓴 코드, 여섯 달 뒤에 왜 그렇게 짰는지 아무도 모른다—Selvedge
AI 코드의 더 조용한 문제가 있다. Mason Delan이 dev.to에서 지적한 '의도 증발' 현상이다. 인간이 코드를 짤 때는 의도가 사방에 새어 나온다. 커밋 메시지, PR 설명, 슬랙 스레드, 인라인 주석. 몇 달이 지나도 왜 그 결정을 내렸는지 재구성할 수 있다. 하지만 AI 에이전트는 세션이 끝나는 순간 맥락을 잃는다.
git blame을 실행하면 커밋 메시지: "Update schema"만 남는다. 에이전트가 가격 정책 마이그레이션 중 할인 소급 적용을 위해 user_tier_v2 컬럼을 추가했다는 사실, 빌링 히스토리를 건드리지 않기 위해 그 구조를 택했다는 맥락은 완전히 사라진다. Delan은 이걸 "판다스 이전 시대"에 비유한다. 데이터 과학자 모두가 각자의 방식으로 같은 문제를 풀며 비효율을 쌓던 그 시절처럼, 지금 AI 코딩 팀들은 천천히 "이유를 알 수 없는 결정"들을 코드베이스에 쌓아가고 있다.
그의 해법은 Selvedge라는 MCP 서버다. AI 에이전트가 작업하는 동안 변경 이벤트를 구조화해서 기록한다—무엇이 바뀌었고, 언제, 어떤 에이전트가, 어떤 커밋에서, 그리고 왜. 핵심은 Reasoning 필드다. 에이전트가 변경을 실행하는 순간의 맥락을 캡처해 나중에 쿼리할 수 있게 저장한다. selvedge blame payments.amount를 실행하면 "사용자가 Stripe 빌링 추가를 요청함—카드 정보를 로컬에 저장하지 않고 계정과 구독을 연결하기 위해 customer ID가 필요"라는 설명이 돌아온다. diff는 git이, 이유는 Selvedge가 맡는 구조다.
셀렉터 대신 의도를 기술한다—AI 에이전트 기반 통합 테스트
Playwright를 버렸다는 선언도 같은 맥락에서 읽힌다. Arnaldo Delisio가 dev.to에서 공유한 사례에서 핵심 비판은 Playwright가 단일 사용자, 결정론적 UI 플로우를 위해 설계됐다는 점이다. 하지만 실제 서비스는 고객이 요청을 올리면 운영자가 배정하고, 전문가가 처리하고, 고객이 결제하는 다중 역할 플로우로 작동한다. Playwright로 이걸 테스트하려면 역할별 인증 상태 파일, 데이터베이스 시딩 픽스처, UI 변경 때마다 깨지는 셀렉터, 수백 줄의 보일러플레이트가 필요하다.
agent-browser와 Claude 서브에이전트를 활용한 오케스트레이터 패턴은 이 구조를 완전히 뒤집는다. 셀렉터 대신 자연어로 의도를 기술하면 에이전트가 접근성 트리를 탐색해 실행한다. UI가 바뀌어도 버튼에 레이블이 있으면 에이전트는 찾아낸다. 역할 분리는 Chrome 프로필 디렉토리로 처리하고, 상태는 공유 JSON 파일로 다음 에이전트에게 넘긴다. 오케스트레이터가 서브에이전트를 순서대로 소환하면서 고객→운영자→전문가→운영자→고객으로 이어지는 6역할 플로우 전체를 하나의 테스트 런으로 커버한다.
비용 반론은 Claude 구독 기반으로 전환하면 실질적으로 사라진다고 저자는 주장한다. 남는 단점은 속도다. 커밋마다 돌리는 CI 파이프라인에는 맞지 않는다. 하지만 배포 전 QA 런이나 다중 역할 통합 테스트라면 Playwright의 유지 비용이 에이전트의 실행 시간보다 훨씬 비싸다.
시사점: 도구를 사는 게 아니라 워크플로우를 설계하는 것
세 사례는 표면적으로 다른 문제를 다루지만 같은 구조적 통찰을 공유한다. AI 도구의 가치는 개별 기능의 성능이 아니라, 그것이 팀의 워크플로우 안에서 어떻게 작동하도록 설계됐느냐에 달려 있다. Cursor Skills는 컨벤션을 한 번 정의해 팀 전체에 강제하는 구조를 만들고, Selvedge는 AI가 만든 결정의 맥락이 사라지지 않도록 잡아두고, 에이전트 기반 테스트는 역할 복잡도가 높은 플로우를 셀렉터 없이 기술할 수 있게 한다.
이 세 가지가 공통으로 요구하는 것은 '설계하려는 의지'다. SKILL.md를 작성하는 시간, CLAUDE.md에 Selvedge 지침을 추가하는 작업, 오케스트레이터 패턴의 상태 파일을 구조화하는 결정—이것들은 모두 AI에게 시키는 일이 아니라 개발자가 앞서 해야 하는 설계 작업이다. AI 도구가 강력해질수록 그것을 어떻게 엮을지 설계하는 능력이 팀의 실제 경쟁력이 된다.
전망: '프롬프트 작성'에서 '워크플로우 아키텍처'로
앞으로 AI 코딩 도구의 진화 방향은 더 나은 모델보다 더 나은 컨텍스트 관리 쪽으로 무게중심이 이동할 가능성이 높다. Selvedge 같은 MCP 서버가 표준 인프라로 자리잡고, 팀 단위 스킬 파일이 .eslintrc처럼 저장소의 기본 구성 요소가 되고, AI 에이전트가 테스트 역할을 점진적으로 흡수하는 흐름은 이미 시작됐다. 그 흐름에서 경쟁력을 갖추려면 어떤 도구를 쓰느냐보다 그 도구들을 어떤 의도로 엮었느냐가 중요하다. 워크플로우 자체가 팀의 지식이 되는 시대다.