같은 앱, 네 프레임워크
8라운드 감사

여덟 번 지은 같은 앱

API Analyzer — 브라우저에서 HTTP 요청을 만들어 보내고 응답을 뜯어보는 도구다. 백엔드가 없다. 모든 상태가 브라우저 안에 있고, 저장은 IndexedDB가 맡는다. 라운드마다 같은 네 에이전트가 이 앱을 고쳐 나갔고, 1차에 지은 것이 8차까지 이어졌다.

1차 측정 결과

소요 시간과 토큰은 각 에이전트의 자체 start→end 기준이다. spawn이 13초씩 엇갈려 출발했으므로 공통 시점이 아닌 개별 소요로 비교했다.

기획서 준수도

네 에이전트 모두 완료 기준 15/15 충족을 주장했다. 자체 보고를 그대로 받지 않고 실제 소스를 직접 대조한 결과다.

기획서가 놓은 함정 하나

기획서는 입력 필드 토큰에 text-slate-100을 넣어두고, 동시에 Method별 글자색을 text-emerald-400 같은 값으로 지정했다. 같은 CSS 속성을 두고 두 유틸리티가 충돌한다. 기획서를 쓸 때 의도한 함정이 아니라, 쓰고 나서야 드러난 구멍이다.

고친 방법

두 구현 모두 공용 입력 토큰을 select 말고도 URL 입력·헤더 Key/Value 등 네다섯 곳에서 쓰고 있었다. 거기서는 text-slate-100이 있어야 하므로 통째로 지울 수 없다. React가 쓴 방식대로 토큰을 글자색 기준으로 분해했다.

각자의 판단

점수로 환산되지 않지만 실력 차이가 가장 잘 드러난 지점들.

줄 수는 밀도지 설계가 아니다

네 구현을 전부 읽고 나서 판단 하나를 뒤집었다. Svelte가 439줄인 건 조밀해서가 아니라 아무것도 분리하지 않았기 때문이다. React의 673줄은 낭비가 아니라 분리의 대가다.

통신 결과를 타입으로 모델링한 건 Angular뿐이다

나머지 지표

번들 크기 — 참고용, 에이전트 평가 대상 아님

프레임워크와 스캐폴딩 선택이 지배하는 값이다. 에이전트가 잘해서 작아진 게 아니다.

공식 스킬은 결과를 좋게 만들었나

Angular와 Svelte에는 벤더가 배포하는 공식 에이전트 스킬이 있었다. React와 Vue는 커뮤니티 스킬뿐이었다. 결과는 기대와 반대로 나왔다. 아래 동등성 판정은 수정 전, 각 에이전트가 자력으로 만들어낸 결과 기준이다.

1차 순위

결함이 해소된 뒤 남은 축은 넷이다 — 함정을 자력으로 넘었는가, 설계가 계층을 갖췄는가, 유지보수가 가능한가, 얼마나 들었는가. 코드를 읽기 전 순위와 읽은 뒤 순위가 달랐다.

2차 측정 결과

네 테스트 스위트를 직접 실행해 확인했다. 보고된 숫자와 전부 일치한다. 회귀 실격은 없다 — 1차 15개 항목이 네 구현 모두에서 살아 있다.

경합 조건 — 셋은 만들었고 하나는 이미 갖고 있었다

A 요청이 진행 중일 때 B를 보내면, A의 늦은 응답이 B의 결과를 덮어써서는 안 된다. 이 문제에서 프레임워크의 성격이 가장 선명하게 갈렸다.

양방향 동기화 — 넷 다 순환을 구조로 막았다

Params 탭과 URL 입력이 서로를 갱신해야 한다. 재진입 플래그를 쓴 구현은 하나도 없었다. 넷 다 "순환이 코드에 존재하지 않게" 만들었고, 접근만 달랐다.

도구가 가려주지 못하게 만들기

경합 조건 테스트에는 함정이 있다. AbortController가 요청을 실제로 끊어버리면 가드가 없어도 테스트가 통과한다. 검증하려는 것이 가려진다.

채점

기획서에 미리 공개한 가중치로 채점했다. 네 구현 8,186줄을 직접 읽고 매겼다. 시간과 토큰은 기록만 하고 점수에 넣지 않았다.

3차 측정 결과

단위 테스트와 E2E까지 직접 실행해 확인했다. 보고된 숫자와 전부 일치한다. 회귀 실격은 없다.

Vue만 zod 3으로 내려갔다

난제를 떠안은 쪽이 이겼다

Zod를 네 폼 라이브러리에 붙이는 과제에서, 셋은 공식 어댑터가 한 줄로 해결해 줬고 Angular만 그런 어댑터가 없었다. 그런데 폼 점수는 Angular가 만점이다.

넷 다 Send에 mutation을 쓰지 않았다

TanStack Query를 필수로 넣었지만, 요청 전송을 useMutation으로 감싼 구현은 하나도 없었다. 근거까지 네 곳이 독립적으로 같았다.

2차 설계가 라이브러리 도입을 견뎠는가

이번 라운드에 15%를 배정한 항목이다. 자체 보고가 아니라 2차 스냅샷과의 파일 단위 diff로 측정했다 (테스트 제외, 순수 도메인 계층만).

채점

기획서에 미리 공개한 가중치로, 코드를 직접 읽고 매겼다.

E2E 43개를 계약으로 동결했다

행동이 안 변했다는 것을 증명할 방법이 필요했다. 3차에서 쌓인 E2E 스펙을 읽기 전용으로 선언하고, 시작 전에 해시를 떠뒀다. 고쳐야만 통과한다면 그것은 행동을 바꾼 것이므로 실패로 규정했다.

무엇이 실제로 나아졌나

행동이 동결됐으므로 개선은 숫자로만 증명된다. 3차 코드가 round3-snapshot/에 보존돼 있어 같은 잣대로 전후를 잴 수 있었다. 아래는 자체 보고가 아니라 직접 측정한 값이다.

프레임워크를 모르는 코드의 비율

세 라운드 동안 못 옮긴 규칙이 옮겨졌다

I7 — "가장 최근 요청만 결과를 확정할 수 있다." 명백한 도메인 규칙인데, 1~3차 내내 AbortController + 티켓이나 switchMap이라는 프레임워크 인접 코드로만 표현됐다. 도메인에 담기지 않는 규칙인가, 아니면 담아본 적이 없는 것인가?

네 구현이 독립적으로 같은 3차 버그를 찾았다

불변식을 도메인으로 끌어모으는 과정에서, 넷 다 같은 사실을 발견했다 — 규칙이 폼 스키마에만 있었고 저장 경로는 무방비였다.

가변 애그리거트 vs 네 개의 반응성 모델

DDD의 애그리거트는 보통 불변식을 지키는 가변 객체다. 그런데 네 프레임워크는 상태 변경을 저마다 다르게 다룬다. 넷의 답이 갈렸다.

DDD가 손해였던 지점

“손해를 3가지 이상 쓰라, 전부 좋았다고 하면 그 보고서는 신뢰하지 않는다”를 평가 항목 10%로 걸었다. 네 구현이 6~7가지씩 냈고, 자기 비판이 가장 날카로웠다.

채점

네 라운드 중 점수 폭이 가장 좁다 — 3점.

말이 아니라 실제 변경으로 쟀다

“응집도가 좋아졌다”는 말로는 검증되지 않는다. 그래서 라운드를 둘로 쪼갰다.

FSD가 자기 핵심 주장에서 3:1로 졌다

FSD의 약속은 “변경이 한 슬라이스 안에 머문다”다. 네 구현 중 셋이 그 지표에서 악화됐다.

그래서 어느 구조가 가장 좋은가

자체 보고만으로는 보이지 않는 것이 있다. 네 구조를 직접 열어 슬라이스 내부 세그먼트와 shared 비대화를 쟀다.

공식 린터가 절반만 본다

“규칙을 일부러 어겨 도구가 잡는지 확인하라”를 3차부터 라운드 규칙으로 넣어뒀다. 이번엔 그 절차가 FSD 공식 린터의 사각지대를 네 개 찾아냈다.

채점

자체 보고로 매긴 뒤 코드를 직접 읽고 두 축을 고쳤다 — 1차에서 “밀도”와 “설계”를 혼동했던 전례가 있어서다.

모양이 다른 기능 세 개

5차에서 Svelte가 정확히 지적했다 — “secret은 횡단 관심사라 FSD에 불리했다.” 기능 하나로 잰 것이 한계였다. 그래서 모양을 셋으로 나눴다.

예측이 4/4 빗나갔다 — 그리고 축이 틀렸다

4차에 묻어둔 투자가 여기서 회수됐다

F1은 4차에 도메인으로 끌어올린 불변식 I4를 개정하는 과제였다. “히스토리 길이는 상한을 넘지 않는다”가 “고정되지 않은 항목에만 적용된다”로 바뀐다. 넷 다 도메인 한 곳에서 흡수했다.

측정 장치가 결과를 오염시켰다

이 문서가 저지른 가장 큰 방법론 실패다. 무엇을 잴지 미리 알려줬더니 네 구현 중 셋이 그 지표에 맞춰 설계를 바꿨다.

한 줄짜리 규칙이 세 라운드 동안 피해를 냈다

채점

이번엔 네 구현의 과제가 완전히 동일해서 시간·토큰을 점수에 반영했다. 기존 E2E·의존성·경계 설정은 전부 직접 대조했다.

네 구현 모두 공식 린터를 지웠다

투표 결과는 만장일치였다. 설정 파일과 의존성에서 steiger가 완전히 제거됐다 — 직접 확인했다. 그런데 근거는 넷 다 달랐다.

서로를 무력화한 두 규칙이 다섯 라운드 동안 초록이었다

Svelte가 찾았고, 이 문서가 코드로 확인했다. 4차부터 “순수하다”고 주장해 온 계층이 실제로는 IndexedDB에 쓰고 있었다.

넷 다 자기 6차 보고를 뒤집었다 — 이 문서도 포함해서

여섯 라운드에 대한 네 개의 독립 평가

7차 보고서에서 가장 읽고 싶었던 항목이다 — 어떤 처방이 값을 했고 어떤 것이 부채였나. 값을 한 처방 1위는 만장일치로 4차 도메인 계층이었다. 그런데 넷 다 이유가 “DDD라서”가 아니었다.

검증과 평가

이 라운드는 지표를 공개하지 않았고 변경량을 평가하지 않겠다고 했으므로, 발견의 질 · 판단의 정직함 · 자기 규칙에 대한 회의로 봤다. 점수표는 쓰지 않는다.

네 구현이 만장일치로 5차 처방을 유죄 판결했다

아무도 서로의 결과를 보지 못한 채, 넷이 각자 독립적으로 같은 결함에 도달했다 — 이 문서가 5차에 강제한 “슬라이스는 공개 API로만 접근한다”는 규칙이 네 생태계 전부에서 트리 셰이킹을 막고 무거운 의존성을 엔트리 청크에 용접하고 있었다.

가장 비싼 작업이 가장 작은 diff를 냈다 — 그게 정답이다

Angular는 이 라운드에 76분 34초와 토큰 416,520개, 도구 호출 190회를 썼다. 여덟 라운드를 통틀어 한 에이전트가 한 라운드에 쓴 최대치다. 그렇게 해서 src/에 남긴 변경은 파일 하나, 한 줄, +5 바이트였다.

측정 장치가 결과를 오염시킨다 — 이번엔 둘이 그걸 잡아냈다

6차에서 이 문서가 지표를 공개해 설계를 오염시켰다. 8차에서는 오염이 기계에서 왔고, Angular와 Vue가 서로를 모른 채 같은 현상을 탐지해 각자 측정 설계를 다시 짰다.

가설 43개 중 33개가 기각됐다

기획서 §3은 “최적화한 것만 나열한 보고서는 낮게 평가한다”고 못박았다. 네 구현이 세운 가설과 기각률은 이렇다 — 그리고 기각된 것들 쪽이 더 흥미롭다.

가장 큰 숫자를 찾고도 고치지 않았다

기획서 §5는 “고치지 않기로 한 것도 정답이다”라고 했다. 넷 다 그 칸을 채웠는데, Vue의 항목이 이 라운드에서 가장 큰 숫자였다.

검증과 평가

기획서 §7이 미리 밝힌 것은 하나뿐이었다 — 개선 폭의 크기는 순위를 정하지 않는다. 그래서 측정의 엄격함 · 가설 규율 · 정직한 자제로 봤다. 점수표는 쓰지 않는다.

여덟 라운드가 서로 다른 것을 측정했다

같은 네 에이전트, 같은 앱, 여덟 개의 다른 질문. 순위가 라운드마다 재배열됐다는 사실 자체가 “어느 프레임워크가 낫다”는 질문이 잘못 놓였음을 보여준다.

원래 질문으로 — AI로 개발할 때 무엇이 다른가

이 연구는 “어느 프레임워크가 낫냐”를 물으려고 시작한 것이 아니다. AI에게 맡겨 개발할 때 네 프레임워크가 어떻게 다른가를 보려고 시작했다. 여덟 라운드를 그 축으로 다시 자르면, 각 라운드는 AI 개발의 한 국면을 모형화한 것이 된다.

AI 사용은 반대 방향 두 모드로 갈린다

위 표에서 1위 칸이 Svelte와 Angular로 깨끗하게 둘로 나뉜다. 그리고 그 둘은 서로의 정확한 거울상이다 — 한쪽이 이긴 라운드에서 다른 쪽이 꼴찌였다. 어느 프레임워크도 두 모드를 동시에 잘하지 못했다.

프레임워크별 AI 적합성 판정

여덟 라운드의 성적과 8차에 확정된 측정 사실을 합쳐, AI에게 맡길 때를 기준으로 정리한 것이다.

공식 AI 도구에 투자한 둘이 8라운드 중 7승

이 연구가 원래 목적에 가장 직접적으로 답하는 관측이다. 다만 상관이지 인과가 아니다 — 아래 반례와 교란을 함께 읽어야 한다.

AI가 무엇을 부쉈는지 알 수 있는가

혼자 AI로 개발할 때 가장 중요한 축은 속도도 비용도 아니다. AI가 낸 변경이 무엇을 깨뜨렸는지 30초 안에 아는가이다.

완성된 네 코드베이스를 같은 잣대로

여기까지는 여덟 라운드의 행동을 봤다. 이 절은 남은 결과물을 본다 — 물려받아 AI와 계속 작업한다면 어느 쪽이 덜 저항하는가. 전체 소스 29,153줄 + 테스트 13,368줄 중 약 2,500줄(6%)을 정독하고, 나머지는 전수 지표로 쟀다. 정독한 것은 네 앱의 같은 지점이다 — 전송·취소·경합 순수 로직, 경계 검사기, 저장소 어댑터, 환경 편집 화면.

변경 하나가 몇 줄을 움직이는가

5차에 실제로 추가했던 secret 필드를 기준으로, 그 개념이 닿아 있는 범위를 전수 측정했다. AI 작업에서 가장 직접적인 비용이고, 여기서 앞 절의 평가가 한 번 뒤집힌다.

라운드마다 건드린 파일 수

스냅샷 간 diff로 전수 측정했다. R5→R6은 네 구현의 과제가 기능 3개로 완전히 같았던 라운드라 이것만 직접 비교할 수 있다.

AI가 이 코드로 작업할 때의 지표 여덟 개

전수 측정이다. 굵게 표시한 것이 그 축의 1위, 붉은 것이 꼴찌다.

지표로는 안 보이고 읽어야 보였던 것 넷

물려받아 AI와 계속 작업한다면

“어느 쪽이 더 나쁘냐”가 아니라 “어느 쪽이 덜 저항하느냐”다. 4위인 React도 any 0에 이 연구 최고의 핵심 파일을 갖고 있다.

목적에 대한 답

여덟 라운드가 실제로 든 값

비용은 6차 한 번만 점수에 들어갔다 — 네 구현의 과제가 기능 3개로 완전히 같았던 유일한 라운드였기 때문이다. 나머지 일곱 라운드에서는 재기만 하고 순위에 쓰지 않았다. 막대 하나가 한 라운드의 토큰 소모량이고, 높이는 네 줄 전체에서 같은 축을 쓴다.

어떻게 검증했나