AI 에이전트에게 프레임워크 테스트를 요청했습니다. 놓쳤던 버그들을 찾아내고 디버거까지 만들어줬습니다.

이 글은 3부작 중 세 번째 부분입니다. Part 1에서는 '느낌으로 코딩한 MVP(Minimum Viable Product)'를 변환하는 과정에 대한 내용이고, Part 2는 이 프레임워크가 탄생하게 된 배경 이야기입니다.

저의 첫 TypeScript 프로젝트는 엉망이었습니다

UECA-React는 제가 처음으로 제대로 다뤄본 TypeScript 작업물이었습니다. 첫 버전 출시 후 약 1년 정도가 지났을 때, 저는 이 코드를 비판적으로 살펴보았습니다. 작동은 했지만, 기능들이 무더기로 쌓여 있는 느낌이었습니다. 바인딩(Bindings), 낮은 수준의 MobX 플러그먼트(plumbing) 등 비즈니스 애플리케이션에 절대 노출되어서는 안 되는 것들이 잔뜩 있었습니다. 팀원들은 이 코드를 따라오지 못했고, 저 역시 구조를 재설계하지 않고서는 고칠 수 없는 버그들에 부딪히기 시작했습니다. 그래서 저는 이를 제대로 된 클래스(classes) 형태로 다시 작성했습니다. 이것이 버전 2였습니다.

더 나아졌지만, 여전히 문제가 있었습니다. 이 실패 모드(failure modes)를 진정으로 이해하는 사람은 저밖에 없다는 것이었습니다.

"테스트로 이걸 커버할 수 있나요?"

그때쯤 저는 Claude Code와 Opus 5를 사용하고 있었습니다. 손으로 작성한 통합 테스트(integration tests)는 몇 개 있었지만, 더 많은 시간을 할애하기는 어려웠습니다. 그래서 제가 에이전트에게 프레임워크 전체를 테스트로 커버해달라고 요청했습니다.

에이전트는 코드를 읽고 작동 방식을 설명하는 문서를 작성했으며, 저의 테스트 스타일을 파악한 후 같은 방식으로 테스트 작성을 시작했습니다: 루트(root)에 애플리케이션 컴포넌트가 있고 테스트 컴포넌트들이 연결되는 작은 UECA 애플리케이션 형태였습니다.

그리고 에이전트는 버그들을 찾아내기 시작했습니다. 엄청나게 많이요. 프레임워크는 정상적인 상황에서는 잘 작동했습니다. 하지만 비정상적인 상황에서는 바인딩이 발동되지 않거나(didn't fire), 이벤트가 건너뛰어졌습니다(were skipped). 이처럼 복잡한 상태 기계(state machine) 같은 프레임워크는 하나의 인간 두뇌만으로는 모든 전이(transitions)를 커버할 수 없습니다. 에이전트는 발견한 것을 수정했고, 그 수정 과정에서 새로운 아이디어들이 탄생했습니다.

현재 커버리지는 90%가 넘습니다. 이것이 바로 버전 3.0이 된 것입니다: 이전에 로그로 기록만 되고 무시되던(dropped) 실수들은 이제 예외를 발생시키고(throw), 단일 에러 핸들러에 도달하며, React.StrictMode까지 지원하게 되었습니다.

저는 오랫동안 시각적 트레이스 뷰어(visual trace viewer)를 만들 수 있다는 것을 알고 있었지만, 시간을 내지 못했습니다. 에이전트가 제가 사용하던 트레이싱 시스템을 보고, 더 유용한 정보를 담도록 개선했으며, 컴포넌트 트리, 메시지 버스 트래픽, 바인딩 등을 포함하고 중지 및 재생 기능까지 갖춘 뷰어를 만들어 주었습니다.

저는 이 코드의 한 줄도 작성하지 않았습니다. 이것은 아키텍처 자체에서 나온 결과물입니다. UECA 앱의 모든 것이 같은 종류의 컴포넌트이기 때문에, 모든 것을 동일한 방식으로 추적할 수 있기 때문입니다.

설령 AI가 전체 애플리케이션을 작성하더라도, 뷰어를 열어 아키텍처가 올바른지 확인할 수 있습니다. 예상치 못한 곳으로 메시지가 날아가거나, 필요하지 않은 시점에 컴포넌트가 생성되는지 등을 말이죠.

반전 (A plot twist)

저는 처음에 에이전트에게 의도적으로 순수한 React로 뷰어를 작성해 달라고 요청했습니다. 그러고 나서 그 뷰어를 검사하는 프레임워크인 UECA-React를 사용해 다시 작성하도록 했습니다. 저는 두 버전을 측정해 보았는데, UECA 버전이 더 빨랐습니다.

아키텍처가 여전히 중요할까요?

솔직히 잘 모르겠습니다. 미래의 모델들은 낮은 수준의 React 코드를 처음부터 작성할 수도 있고, 아무도 그것을 눈으로 확인하거나 신경 쓰지 않을 것입니다. 우리는 이미 생성된 모든 코드를 읽는 것이 현실적이지 않은 지점에 와 있습니다.

하지만 더 나은 아키텍처를 향해 한 걸음이라도 나아갈 기회가 있다면, 그럴 가치가 있다고 생각합니다. 어디서든 동일한 형태, 예측 가능한 동작, 그리고 패턴이 여지를 남기지 않아 에이전트가 표류할 수 없는 구조 말입니다. 이것이 바로 UECA-React가 내거는 베팅입니다.

직접 사용해 보세요

• npm: https://www.npmjs.com/package/ueca-react
• UECA-React로 자체 구축된 앱에서 아키텍처와 아이디어를 설명합니다: https://nekutuzov.github.io/ueca-react-website-public/

여러분은 에이전트가 코드의 대부분을 작성하도록 허용하십니까? 가장 먼저 무너지는 부분은 무엇입니까?