AI 도구를 쓰는 것과 만드는 것 사이
'AI 코딩 도구가 생산성을 높인다'는 말은 이제 새롭지 않다. 그런데 최근 dev.to에 잇따라 등장한 세 편의 글이 흥미로운 이유는, 단순히 AI를 잘 쓰는 방법을 공유하는 게 아니라 개발자가 직접 AI 도구를 설계하고 확장하는 경험을 기록하고 있기 때문이다. 사용자에서 설계자로의 전환—이게 지금 개발자 워크플로우에서 가장 조용하지만 가장 강력하게 일어나고 있는 변화다.
핵심 이슈: 세 가지 직접 설계 사례
첫 번째 사례: Playwright 테스트 실패를 AI가 직접 진단한다
6년 차 QA 자동화 엔지니어가 개발한 커스텀 Playwright AI 리포터(dev.to)는 문제의식이 명확하다. CI에서 테스트가 실패하면 스택 트레이스를 20분씩 읽고, 결국 셀렉터 한 줄 문제를 발견하는 반복. 이 사이클을 끊기 위해 onTestEnd 훅에 LLM 호출을 붙였다. 실패한 테스트의 이름, 에러 메시지, 스택 트레이스를 AI에 전송하면 근본 원인(root cause), TypeScript 수정 코드, 예방 팁까지 한 번에 돌아온다.
설계에서 특히 눈에 띄는 건 AI 프로바이더를 환경변수 하나로 교체할 수 있도록 인터페이스를 추상화한 부분이다. Groq(무료), Claude Haiku, Claude Sonnet, GPT-4o-mini를 코드 변경 없이 .env만 수정해 전환한다. 로컬 개발에선 무료 Groq, 프로덕션 CI에선 진단 품질이 높은 Claude Sonnet을 쓰는 실용적 조합이 가능하다. '도구를 만들 때도 교체 가능성을 먼저 설계한다'는 사고방식—이게 AI 시대 좋은 아키텍처의 기준이 되고 있다.
두 번째 사례: VS Code 에이전트를 통째로 다시 설계하다
Kilo Code는 기존 VS Code 확장을 OpenCode 서버 기반으로 완전히 재구축했다. 병렬 도구 호출(parallel tool calls), 서브에이전트 위임(subagent delegation), 인라인 코드 리뷰, 멀티모델 비교가 핵심 변화다. 주목할 점은 '확장'이 아니라 '재구축'을 선택했다는 것이다. 에이전트 기반 워크플로우에서 기존 아키텍처의 한계가 얼마나 빨리 드러나는지를 보여주는 사례이기도 하다. 포터블 코어(portable core)로의 전환은 에디터 종속성을 낮추겠다는 방향성으로도 읽힌다.
세 번째 사례: AI 대화 자체를 감사(audit) 가능하게 만들다
가장 실험적이면서 가장 근본적인 질문을 던지는 사례다. chron이라는 MCP 서버를 직접 구축해 Claude와의 모든 대화를 로컬 SQLite에 기록한다(dev.to). 컨텍스트 윈도우가 초기화되면 이전 세션의 결정과 맥락이 사라지는 문제—이걸 '내 데이터, 내 머신, 내 포맷'으로 영구 보존하겠다는 의도다. 해시 체이닝으로 로그 무결성을 검증하고, npx 한 줄로 Claude Desktop·Cursor·Windsurf 설정을 자동 감지해 주입하는 설계는 설치 경험(install UX)까지 제품으로 본 결과다.
맥락 해석: 왜 지금 '직접 설계'인가
세 사례의 공통점은 기존 AI 도구의 출력을 소비하는 것에서 멈추지 않는다는 점이다. AI가 개입하는 지점, 프로바이더 선택, 로깅과 감사 체계—이 모든 것을 개발자가 직접 설계하고 있다. MCP(Model Context Protocol)가 플러그인 시스템으로 안착하면서 이 흐름이 가속화되고 있는 것도 눈여겨볼 대목이다. Playwright의 Reporter 인터페이스, MCP의 Tool 스키마—이미 존재하는 확장 포인트에 AI를 연결하는 패턴이 반복된다.
또 하나의 공통 맥락은 DX(개발자 경험)를 제품 수준으로 다룬다는 점이다. chron 개발자가 'MCP 서버를 작동시키는 건 하루, 설치 경험을 매끄럽게 만드는 건 일주일'이라고 술회한 대목은 의미심장하다. AI 기능 자체보다 그 기능에 접근하는 경험을 설계하는 것이 실제 채택의 병목임을 정확히 짚고 있다.
시사점: 개발자의 역할이 확장되는 방식
이 흐름은 두 가지 역량을 동시에 요구한다. 하나는 기존 도구의 확장 포인트를 정확히 이해하는 것—Playwright Reporter API, MCP Tool 스키마, VS Code Extension API. 다른 하나는 AI 프로바이더를 추상화하고 교체 가능하게 설계하는 것. 특정 LLM에 종속되지 않는 아키텍처가 유지보수성과 비용 효율 모두에서 유리하다는 걸 세 사례 모두 방식은 달라도 같은 결론으로 보여준다.
프론트엔드와 QA 영역에서 특히 체감되는 변화는, AI가 '도와주는 도구'에서 '파이프라인의 일부'로 격상되고 있다는 점이다. 테스트 실패 진단, 코드 리뷰, 세션 로깅—이 각각이 더 이상 사람이 수동으로 처리하는 작업이 아니라 자동화된 파이프라인 안에 AI 호출이 내장된 구조로 바뀌고 있다.
전망: 설계 가능한 AI 워크플로우가 경쟁력이 된다
앞으로 주목해야 할 지점은 '어떤 AI 도구를 쓰느냐'보다 '팀이 AI 개입 지점을 얼마나 정밀하게 설계하고 있느냐'가 될 것이다. Playwright AI 리포터가 보여주듯 QA 자동화에 LLM을 붙이는 건 이미 개인 개발자 수준에서 가능하다. Kilo Code가 보여주듯 에이전트 기반 워크플로우는 기존 아키텍처를 빠르게 낡게 만든다. chron이 보여주듯 AI 대화의 감사 가능성(auditability)은 곧 팀 단위 거버넌스의 요구사항이 될 것이다.
결국 AI 도구를 직접 설계한다는 것은, 워크플로우의 주도권을 도구 벤더에게 넘기지 않겠다는 선언이기도 하다. 빠르게 실험하고, 직접 만들고, 팀의 컨텍스트에 맞게 확장하는 개발자—이게 AI 시대 프론트엔드와 QA 엔지니어에게 요구되는 새로운 기본값에 점점 가까워지고 있다.