클로드가 하루 만에 라이브러리를 갈아엎었다

자바스크립트 BDD 라이브러리 야다(Yadda)의 3.0.0 버전이 8월 15일 npm에 올라왔다. 오래된 라이브러리의 통상적인 현대화 작업처럼 보이지만, 제작자 스티븐 크레스웰(Stephen Cresswell)이 발행 후 남긴 기록의 무게중심은 다른 데 있다. 코드 대부분을 클로드가 썼고, 정작 그가 부딪힌 한계는 모델이 아니라 자기 자신이었다는 것이다.

무슨 일인가

야다는 큐컴버(Cucumber)처럼 일상 언어로 쓴 명세를 실행 코드에 연결해주는 도구다. 다만 명세를 어떤 형식으로 써야 하는지에 대해 훨씬 덜 규범적이라는 점이 차별점이다. 3.0의 변경은 대부분 정리 작업이다. 노드 전용으로 축소하면서 브라우저 번들링과 캐스퍼JS·팬텀JS·바우어·컴포넌트 같은 지금은 역사적 유물이 된 통합을 걷어냈고, 테스트를 노드 내장 테스트 러너로 옮겼으며, 바이옴(Biome)과 레프트훅(lefthook)을 도입하고 소스를 ES6 문법으로 현대화했다. 플레이라이트(Playwright)와 퍼피티어(Puppeteer) 예제가 추가됐고 타입스크립트 정의도 함께 제공된다.

작업은 클로드 코드(Claude Code)와 오푸스 4.8로 진행됐다. 작업을 쪼갠 기획 문서 자체도 클로드가 작성했고, 시작부터 npm 발행까지 걸린 시간은 대략 하루였다. 그동안 저자는 다른 일을 병행했다.

핵심 짚어보기

결과보다 중요한 건 방법이다. 저자는 작업을 의도적으로 분리된 단계들로 나눴다. 폐기 기능 제거, 툴체인 업데이트, 기계적인 서식 변경, 소스 현대화, API 변경 검토, 예제와 CI 갱신, 마지막으로 메타데이터와 문서와 타입 정의 순이다. 각 단계는 구현 전에 계획을 먼저 세웠고, 그다음은 대체로 맡겼다. 저자는 실수가 놀랄 만큼 적었으며, 단순 작업으로 보이던 구간에서 놓치기 쉬운 미묘한 경계 사례를 오히려 에이전트가 짚어냈다고 평가했다.

성공 조건으로 그가 꼽은 건 두 가지다. 하나는 야다에 이미 촘촘한 테스트 스위트가 있었다는 점이다. 다른 하나는 규칙이었다. 그는 프로덕션 코드와 그에 대응하는 테스트를 같은 단계에서 고치지 못하게 막았다. 둘을 동시에 바꾸면 테스트 통과는 약한 증거가 된다. 에이전트가 구현과 '무엇이 옳은가'의 정의를 동시에 바꿀 수 있기 때문이다. 둘을 떼어놓아야 테스트가 외부 제약으로 작동한다.

저자는 올해 초 바이브 코딩 경험담이 극과 극으로 갈리는 이유를 실험한 적이 있다. 당시 결론은 결과가 사용 방식에 달렸다는 것이었다. 촘촘히 제약하고 감독하면 매우 좋은 결과가 빠르게 나오지만, 방치하면 아키텍처가 표류하고 불필요한 코드와 운영 부채가 쌓였다. 7개월이 지난 지금은 그 전제 자체가 흔들릴 만큼 역량이 올라갔다는 게 그의 진단이다.

1인기업 실전 적용 포인트

• 테스트 스위트가 없으면 자동화를 늘리지 마라. 이 사례가 하루 만에 끝난 결정적 이유는 되돌아볼 기준이 이미 있었기 때문이다. 검증 장치 없이 에이전트에게 코드를 맡기면 속도는 빨라져도 무엇이 망가졌는지 알 방법이 없다.
• '코드와 테스트를 같은 단계에서 고치지 않는다'를 규칙 파일에 박아라. 프로젝트 지침 문서에 한 줄 넣어두는 것만으로 통과한 테스트의 신뢰도가 달라진다.
• 동시에 굴리는 작업은 3~5개로 제한하라. 저자가 실측한 인간의 상한선이다. 그 이상은 진행 상황을 놓친다. 작업 수를 늘리는 대신 각 작업의 완료 기준을 명확히 쓰는 편이 실제 산출량을 늘린다.
• 계획 단계와 실행 단계를 파일로 분리하라. 단계별 기획 문서를 먼저 만들고 승인한 뒤 실행에 들어가는 흐름은, 에이전트를 여러 개 굴릴 때 각각이 무엇을 하는지 되짚는 유일한 기록이 된다.

전망 / 주의점

저자의 결론이 이 기사의 핵심이다. 그는 클로드 코드 세션을 여러 개 띄우고 깃 워크트리로 작업 공간을 분리하는 병렬 실행을 시도했지만, 곧 다른 벽에 부딪혔다. 세 개는 편하게, 많으면 네다섯 개까지 굴릴 수 있었고 그 이상은 각 에이전트가 무엇을 하는지, 어떤 결정이 내려졌는지, 무엇이 자기 검토를 기다리는지 맥락을 잃었다. 모델도 기계도 과부하가 아니었다. 병목은 일을 조율하는 사람이었다. 그는 좋은 오케스트레이션이 다음 중요한 층위가 될 것이라고 봤고, 같은 결론에 도달한 동료가 클로드 코드와 워크트리를 감싸는 조율 도구를 만든 뒤 구현·리뷰·피드백·문서를 잇는 에이전트 파이프라인으로 넘어갔다는 사례도 함께 소개했다. 혼자 일하는 사람에게 이 신호는 분명하다. 다음에 투자할 곳은 더 좋은 모델이 아니라, 여러 작업을 놓치지 않고 붙잡아 두는 자기만의 조율 체계다.

출처: Signal Over Noise (http://www.stephen-cresswell.com/2026/08/15/Yadda-3.0.0-BDD-in-the-Age-of-AI-Agents.html)