AI가 코드를 고치는 시대, 프론트엔드 구조는 어떻게 달라져야 할까?

프레임워크만으로는 답이 나오지 않았다#

프론트엔드 프로젝트는 시간이 지나면 흔히 기술 계층별로 정리된다.

1
src/
2
├── components/
3
├── hooks-or-composables/
4
├── services/
5
├── stores/
6
├── utils/
7
└── views/

사람에게는 익숙하다. 컴포넌트를 찾으려면 components, API 호출은 services, 상태는 stores를 보면 된다.

하나의 기능을 수정하는 입장에서 보면 얘기가 달라진다. 문서 업로드 기능을 고치기 위해 다음 파일을 돌아다녀야 할 수 있다.

1
views/DocumentUploadPage
2
components/FileDropZone
3
hooks-or-composables/useDocumentUpload.ts
4
services/document.service.ts
5
stores/document.ts
6
utils/file.ts
7
types/document.ts

기술 계층별로는 정돈되어 있지만 기능은 저장소 전체에 흩어진다. 전역 store나 공통 hook·composable에까지 연결되어 있다면, 변경 영향도를 확인하기 위해 다른 기능도 읽어야 한다.

이 구조를 강제하는 프레임워크는 없다. 여러 프레임워크에서 자주 선택하는 관습일 뿐이다. 문제는 프레임워크 자체보다 기능 하나를 고칠 때 몇 개의 경계를 가로질러야 하느냐에 있다.

프레임워크를 아예 걷어내면 어떨까. 이 방향을 지지하는 것처럼 보이는 결과가 있다.

DesignBench는 React, Vue, Angular와 Vanilla HTML/CSS를 포함한 900개 샘플에서 UI 생성, 편집, 복구를 평가했다. 모델들은 대체로 Vanilla HTML/CSS에서 더 높은 시각적 유사도와 컴파일 성공률을 보였다. 결과가 프레임워크 순서대로 나빠지지는 않았다. 논문은 Vanilla가 가장 좋고 React와 Vue가 비슷하게 뒤따르며 Angular가 유독 어렵다고 정리했다. 생성 과제에서 Vanilla는 컴파일이 사실상 항상 성공했지만, Angular는 성능이 높은 모델들조차 약 69~76%에 머물렀다.

실제로 컴포넌트 기반으로 구현한 비율도 낮았다. 논문이 보고한 비율은 React 0.24%, Vue 5%, Angular 19%다. 화면에 같은 항목이 반복되어도 컴포넌트와 반복 렌더링을 쓰지 않고 마크업을 복사하는 사례가 많았다.

이 숫자를 읽을 때는 실험의 성격을 같이 봐야 한다. 생성 과제는 목업을 코드로 옮기고, 편집과 복구 과제는 기존 코드와 시각 정보, 자연어 지시를 함께 사용한다. 장기 유지보수와 재사용을 평가한 벤치마크는 아니므로 낮은 컴포넌트 사용률을 제품 아키텍처 전반으로 일반화할 수는 없다. 다만 반복 UI가 있는 사례에서도 모델이 재사용 가능한 구조를 거의 선택하지 않았다는 점은 확인됐다.

반대 방향의 결과도 있다. ICLR 2026에 발표된 The Matthew Effect of AI Programming Assistants는 대중적인 언어와 프레임워크일수록 AI가 더 높은 성공률을 보이는 경향을 보고했다. 저자들은 언어별 알고리즘 과제와 같은 17개 요구사항을 여섯 개 풀스택 조합으로 구현하는 과제를 평가했다. 실험 과정에서는 코드를 직접 고치거나 해결 방향을 알려주지 않고, 오류 메시지만 그대로 모델에 다시 전달했다. 그런 다음 완료 여부와 반복 시도 횟수를 비교했다. React + Express + Prisma나 Vue + Spring Boot 조합보다 Svelte + FastAPI, SolidJS + Actix Web처럼 덜 보편적인 조합에서 실패와 재시도가 늘었다.

이 논문은 프론트엔드와 백엔드가 결합된 스택을 비교했으니, 프론트엔드 프레임워크의 효과만 떼어낼 수는 없다. 보편적인 생태계에서 성공률이 높다는 상관관계는 확인했지만, 학습 데이터 노출량과 문서·도구 생태계 중 어느 요인이 원인인지도 분리하지 않았다.

적어도 문법이 단순하거나 코드가 짧다는 이유만으로 AI 친화적이라고 단정할 수는 없다. 해당 생태계가 얼마나 널리 쓰이는지와 AI 성능 사이의 관계도 함께 봐야 한다.

두 결과에서는 프레임워크별 성능 차이가 나타났지만, 유리한 방향은 과제에 따라 달랐다. 두 연구 모두 프레임워크와 소스 아키텍처의 상대적인 영향을 비교하지 않았으므로, 현재 근거로는 React, Vue, Angular, Svelte, Lit 중 하나를 AI 친화적인 프레임워크로 확정하기 어렵다.

그래서 이 글은 프레임워크 선택 자체보다, 그 위에 어떤 구조를 만들 것인지 다룬다.

첫 번째 축: 읽어야 할 문맥#

Web-Bench는 프론트엔드 프로젝트 50개에 각각 20개의 연속된 기능 작업을 수행하게 했다. 뒤의 작업은 앞에서 만든 저장소 상태에 의존한다. 화면 하나를 만드는 것으로 끝나지 않고, 이미 동작하는 기능을 보존하면서 계속 변경해야 한다.

Web-Agent에서 Best-of-5 방식으로 집계했을 때 가장 높은 점수를 기록한 Claude 3.7 Sonnet(thinking)의 Pass@1도 25.11%였다. 네 개 중 하나 정도만 첫 번째 시도에서 통과했다. 화면을 만드는 일과 저장소를 계속 고치는 일은 난이도가 다르다.

2026년 7월 공개된 WebDesignIter는 이 문제를 더 직접적으로 다룬다. 저자들은 프론트엔드 저장소를 연속해서 수정할 때 AI에게 부족한 것이 단순한 코드 검색이 아니라 설계 지식이라고 주장한다.

• 아키텍처 원칙
• 모듈별 책임
• 구조적 제약
• 파일과 컴포넌트 간 의존성
• 이전 작업에서 내려진 설계 결정

저자들은 이 정보를 코드 그래프와 함께 관리해 관련 파일을 찾고 최소 패치를 생성하는 방식을 평가했다. Claude 4 Sonnet으로 진행한 제거 실험에서는 설계 지식을 빼면 Pass@1이 11.4%p 떨어졌고, 코드 그래프를 빼면 8.4%p 떨어졌다.

두 번의 시도 후에도 해결되지 않은 오류를 유형별로 나눴을 때 회귀 오류가 차지하는 비중은 29.17%에서 4.17%로 낮아졌다. 이 수치는 절대 회귀율이 아니라 미해결 오류의 구성비다. 논문은 이 분석의 모델별 집계 방식과 분모를 별도로 공개하지 않았다. 따라서 회귀 자체가 줄었다기보다 남은 실패에서 회귀 오류가 차지하는 비중이 작아졌다고 해석해야 한다.

이 결과는 코드가 어디에 있는지만 찾는 것으로는 부족하다는 해석을 뒷받침한다. 그 코드가 왜 거기에 있고, 무엇과 연결되며, 무엇을 깨뜨리면 안 되는지도 작업에 필요한 문맥으로 제공돼야 한다.

문맥을 고르는 능력 자체도 병목이다. ContextBench는 66개 저장소의 1,136개 작업에서 에이전트가 정밀도보다 재현율을 우선해 관련 있을 것 같은 코드를 넓게 읽는다고 보고했다. 탐색한 문맥과 실제 해결에 사용한 문맥 사이에도 큰 차이가 있었다. 정교한 에이전트 스캐폴딩을 더해도 문맥 검색의 개선 폭은 미미했다는 관찰도 함께 있다. 코드 위치와 의존성을 정확히 짚는 문제는 LocAgent와 DependEval에서도 따로 다뤄졌다.

AI에게 전체 저장소를 읽게 하면 비용이 크고 관련 없는 정보까지 섞인다. 그렇다면 아키텍처가 할 일 중 하나는 읽지 않고도 안전하게 수정할 수 있는 범위를 만드는 것이다.

두 번째 축: 기억해야 할 규칙#

모듈 경계가 중요하다고 해서 AI에게 아키텍처 규칙을 많이 주면 된다는 뜻은 아니다. Constraint Decay에서는 오히려 반대 결과가 나왔다.

Constraint Decay는 여덟 개 백엔드 프레임워크와 열 개 제약 조합으로 80개의 신규 생성 과제를 만들고, 구조 제약을 L0부터 L3까지 바꿔가며 성능을 측정했다. 별도의 기존 저장소 기능 구현 과제 20개는 제약 효과를 분리하는 실험이 아니라, 이미 계층·PostgreSQL·ORM이 들어간 코드베이스에서도 어려움이 이어지는지 확인한 보조 실험이다. 신규 생성 실험에서 기본 성능이 높았던 여덟 개 모델·에이전트 구성은 L0에서 L3로 갈 때 검증 항목 통과율이 평균 30%p 하락했다.

전체 평균만 보지 말고 제약별 결과도 봐야 한다. 논문은 각 제약의 평균 영향을 분리해 계산했다. 표의 ± 값은 표준오차다.

ORM 지정의 감소 폭은 점추정치상 1.5%p 이하로 작았다. 점추정치 기준으로 PostgreSQL 지정의 감소 폭은 Clean Architecture의 약 2.1배였고 SQLite는 약 1.6배였다. 규칙이 몇 개인지만으로 비용을 설명할 수 없고, 어떤 종류의 제약을 어떤 조합으로 만족해야 하는지가 중요하다. 따라서 규칙 수를 무조건 줄이기보다 비용이 큰 제약의 종류와 기능 하나에서 동시에 만족해야 할 제약 조합을 줄여야 한다.

논문은 Clean Architecture의 -9.1%p가 계층 분리의 부담과 일치한다고 해석했지만, 구체적인 원인을 따로 측정하지는 않았다. 가능한 설명 중 하나는 기능 하나가 여러 수평 계층에 나뉜다는 점이다.

1
routes
2
→ services
3
→ entities
4
→ repositories

기능 하나를 구현하려면 여러 디렉터리를 오가며 계층 규칙을 지켜야 한다. 아키텍처적으로 정돈되어 있어도, AI가 한 번에 붙잡고 있어야 할 조건은 늘어난다.

프론트엔드에서 특히 어려운 것#

여기까지의 두 축은 프론트엔드만의 얘기가 아니다. 이전 글에서 백엔드에 적용한 정리와 크게 다르지 않다. 기능별 경계를 만들고, 변경할 때 해석해야 할 제약의 종류와 판단 비용을 낮춘다는 원칙은 어느 쪽에나 적용된다.

프론트엔드가 다른 지점은 하나다. 기능 경계를 넘어 UI를 재사용해야 할 일이 많다.

백엔드에서 결제와 정산은 코드를 공유하지 않아도 된다. 프론트엔드에서 결제 화면과 정산 화면은 같은 버튼, 같은 입력, 같은 모달, 같은 표를 써야 한다. 디자인 일관성은 취향이 아니라 제품 요구사항이다. 기능 경계를 그은 직후부터 그 경계를 뚫으라는 요구가 들어온다.

공통 UI를 쓴다고 기능들이 곧바로 서로 결합하는 것은 아니다. 문제는 shared/ui-primitives가 업무 규칙을 알기 시작하거나 공개 API가 자주 바뀔 때 생긴다. 버튼 하나를 바꿨을 때 여러 기능에 영향이 퍼지면 기능 캡슐을 만들어놓고도 확인해야 할 범위가 다시 넓어진다.

AI가 이 압력을 스스로 관리해줄 것 같지도 않다. 앞에서 본 DesignBench에서는 반복 UI가 있어도 React 컴포넌트를 사용한 비율이 0.24%에 그쳤다. 장기 유지보수를 평가한 결과는 아니지만, 별도 요구가 없을 때 재사용 가능한 구조를 자연스럽게 선택하지 않았다는 점은 확인됐다. 반면 SlopCodeBench에서는 반복 수정 중 구조적 중복이 96% 늘었다. 공통화를 미루면 같은 마크업이 여러 곳에 쌓일 수 있고, 반대로 너무 일찍 공통화하면 기능 사이의 결합이 커질 수 있다.

그래서 공유를 두 종류로 나눈다. 모양의 공유와 행동의 공유다.

1
색, 간격, 타이포그래피, 모서리 반경 → shared/design-tokens
2
버튼·입력·모달의 껍데기   → shared/ui-primitives
3
폼 조합, 검증 표시, 흐름  → feature 내부

판단 질문은 하나다.

이 컴포넌트가 업무 규칙을 알고 있는가.

<Button>은 자기가 무엇을 제출하는지 모르므로 shared에 둔다. <SubmitTaxForm>은 세금 계산 규칙을 알므로 features/tax-calculation 안에 둔다. 같은 버튼을 쓰더라도 조합 로직은 각 기능 안에 둔다.

이렇게 나누는 목적은 읽어야 할 문맥을 작게 유지하는 것이다. shared의 공개 API가 안정적이고 업무 규칙이 없다면 기능을 고칠 때 내부 구현까지 읽을 일이 줄어들 수 있다. 반대로 shared의 컴포넌트에 기능별 조건 분기가 쌓이면 기능 하나를 고칠 때마다 그 분기를 전부 읽어야 한다. shared가 커지는 것 자체보다 shared가 업무를 알기 시작하는 것이 문제다.

그래서 무엇을 할 것인가#

1
features/*/model/**: UI 프레임워크를 import하지 않는다

1
src/
2
├── app/
3
│   ├── router/
4
│   ├── layouts/
5
│   ├── orchestration/
6
│   └── main.ts
7
│
8
├── features/
9
│   ├── document-upload/
10
│   │   ├── index.ts
11
│   │   ├── ui/
12
│   │   ├── model/
13
│   │   ├── api/
14
│   │   └── tests/
15
│   │
16
│   ├── tax-calculation/
17
│   │   └── ...
18
│   │
19
│   └── consultation/
20
│       └── ...
21
│
22
├── platform/
23
│   ├── auth/
24
│   ├── http/
25
│   ├── storage/
26
│   └── telemetry/
27
│
28
└── shared/
29
    ├── design-tokens/
30
    ├── ui-primitives/
31
    └── generated-api/

1
1. feature는 다른 feature를 직접 import하지 않으며, feature 외부에서는 index.ts로 공개한 API만 사용한다.
2
2. shared와 platform은 feature를 import할 수 없다.
3
3. feature 간 연결은 app이 각 feature의 공개 API를 통해 담당한다.
4
4. feature의 model은 UI 프레임워크를 import할 수 없다.

1
export { DocumentUploadPage } from "./ui/DocumentUploadPage";
2
export { uploadDocument } from "./model/upload-document";
3

4
export type {
5
  UploadDocumentInput,
6
  UploadDocumentResult,
7
} from "./model/types";

1
// 금지
2
import { validateFile } from
3
  "@/features/document-upload/model/validate-file";

1
import { uploadDocument } from "@/features/document-upload";
2
import { calculateTax } from "@/features/tax-calculation";
3

4
export async function uploadAndCalculate(file: File) {
5
  const document = await uploadDocument(file);
6
  return calculateTax(document.id);
7
}

1
서버가 원본인 데이터  → 서버 상태
2
검색 조건과 탭       → URL 상태
3
컴포넌트 입력값      → 컴포넌트 로컬 상태
4
기능 내부 공유 상태  → feature 내부 store
5
로그인 사용자        → app 전역 상태

1
features/document-upload/model/upload-store.ts
2
features/consultation/model/consultation-store.ts

1
{
2
  "name": "document-upload",
3
  "responsibility": "세무 문서를 검증하고 업로드한다",
4
  "invariants": [
5
    "파일은 20 MB를 초과할 수 없다"
6
  ]
7
}

1
허용된 의존성   → lint 또는 구조 테스트
2
공개 진입점     → 실제 export와 빌드 설정
3
업무 불변식     → 테스트
4
검증 방법       → 실행 가능한 명령
5
기능의 책임     → 짧은 README

1
1. features/로 기능별 수직 분할, index.ts만 공개
2
2. shared는 모양만 공유하고 업무 규칙은 feature 안에
3
3. model은 UI 프레임워크를 import하지 않는다
4
4. store 소유권을 기능에 두고 전역은 예외로
5
5. 성급한 공통화를 지연하되 중복 추이는 측정
6
6. 위 경계를 lint 또는 구조 테스트로 강제
7
7. 배포는 하나로, 소스 경계만 기능 단위로

처음부터 하지 않을 것#

AI 친화적인 구조를 만든다고 아키텍처를 키울 이유는 없다. 요구가 생기기 전까지 아래 항목은 보류한다.

• Micro Frontend
• 모든 기능의 별도 패키지화
• 기능마다 repository, service, use case를 의무적으로 두는 구조
• 전역 이벤트 버스
• 모든 상태의 중앙 store 관리
• 범용 폼 엔진
• 거대한 공통 hook 또는 composable 모음
• 자연어 아키텍처 규칙 수십 개

Micro Frontend는 독립 배포와 팀 자율성이 정말 필요할 때 의미가 있다. Micro Frontend 문헌 리뷰는 작은 독립 애플리케이션과 팀 확장이라는 장점과 함께 페이로드 증가, 코드 중복, 팀 간 결합, 모니터링 복잡성을 보고했다.

AI가 코드를 읽기 좋게 만들자고 런타임과 배포 단위까지 쪼갤 이유는 없다. 하나의 애플리케이션으로 배포하면서 소스 경계만 기능 단위로 나누는 모듈러 모놀리스가 먼저다.

근거는 어디까지이고, 어떻게 확인할까#

현재까지의 연구에서 직접 확인된 범위는 아래와 같다.

• 저장소를 연속해서 변경하는 과제에서 AI의 성공률은 낮았다.
• 정확한 코드 위치와 의존성을 찾는 능력은 저장소 수준의 작업 성능과 관련이 있었다.
• 설계 지식과 코드 그래프를 포함한 WebDesignIter 시스템은 비교 대상보다 적은 입력 토큰으로 높은 통과율을 기록했다.
• DesignBench에서는 Vanilla보다 프레임워크 구현이 대체로 어려웠고, Constraint Decay의 신규 생성 실험에서는 제약 종류에 따라 비용 차이가 컸다.
• Python으로 평가한 반복 수정 실험에서는 중복과 구조 침식이 누적됐다.

근거의 수준은 세 단계로 나뉜다.

1
내 프로젝트에서 측정됨
2
→ 기능별 진입 문맥의 파일 크기는 전체 TypeScript 소스의 약 53분의 1이었다.
3

4
논문에서 측정됨
5
→ 설계 지식과 코드 그래프 등을 결합한 시스템은 입력 토큰을 줄이면서 통과율을 높였다.
6

7
아직 미검증
8
→ 기능별 소스 아키텍처 자체가 개선의 직접 원인이다.

세 번째 항목이 아직 검증되지 않은 이유가 중요하다. WebDesignIter는 소스 아키텍처만 바꾸지 않았다. 설계 지식, 코드 그래프, 최소 패치, 자동 테스트를 함께 사용한 특화 하네스라서 폴더 구조만의 효과를 분리할 수 없다. 토큰 계산 방식과 에이전트별 도구 차이도 있어 26배라는 숫자를 그대로 적용할 수도 없다. 2026년 7월 처음 공개된 프리프린트이며, 논문이 연결한 GitHub 저장소는 2026년 8월 5일 현재 비어 있어 공개 코드만으로 독립 재현하기도 어렵다.

내가 기능별 아키텍처에 기대하는 흐름은 다섯 단계로 이어진다.

1
기능 경계가 명확해진다
2
→ 탐색해야 할 후보 파일이 줄어든다
3
→ 입력 토큰과 관련 없는 문맥이 줄어든다
4
→ 수정 범위가 작아진다
5
→ 회귀 가능성이 낮아진다

코드 위치 파악, 의존성 이해, 문맥 선택의 중요성은 LocAgent, DependEval, ContextBench에서 각각 관찰됐다. 그러나 기능별 폴더 경계가 후보 파일과 입력 토큰을 줄이는지는 이 연구들이 측정하지 않았다. WebDesignIter도 전체 시스템의 입력 토큰과 통과율, 미해결 오류의 구성을 보고했을 뿐 각 화살표를 따로 검증하지 않았다. 따라서 위 다섯 단계 전체가 이 글에서 검증하려는 인과 가설이다.

동일한 프론트엔드 애플리케이션에서 기능별 수직 구조가 기술 계층별 구조보다 AI의 작업 성공률을 높이는가.

답하려면 같은 요구사항을 두 구조로 구현하고 동일한 모델과 하네스로 연속 작업을 수행해야 한다.

1
A: 기술 계층과 공통화 중심
2
components / hooks-or-composables / services / stores
3

4
B: 기능 캡슐 중심
5
features/document-upload/{ui, model, api, tests}

측정 항목은 작업 통과율과 재시도 후 회귀 발생률, 읽은 파일 수와 입력 토큰이다. 탐색한 파일 가운데 실제로 필요한 파일의 비율과, 실제로 필요한 파일 가운데 탐색한 파일의 비율도 함께 본다. 기능 경계 밖의 수정 파일 수, 테스트 통과율, 중복과 복잡도의 누적, 같은 작업을 반복했을 때의 결과 편차도 기록해야 한다. 요구사항에는 어느 구조의 이름도 쓰지 않고 사용자 관점의 기능만 적는다. 작업마다 이전에 만든 기능의 테스트도 다시 실행한다.

이 실험 전까지 기능 캡슐이 AI에게 더 좋다는 말은 검증되지 않은 가설로 남는다.

그럼에도 나는 이 구조를 출발점으로 택한다. 관련 파일을 좁히고 설계 제약을 작업 문맥에 넣는다는 점에서 선행 실험의 방향과 모순되지 않기 때문이다. AI에 대한 가설을 빼더라도 변경 이유가 같은 코드를 모으고 공개 API를 두는 방식은 사람이 유지보수하기에도 납득할 수 있는 선택이다. 다만 실제 이득과 제약 비용은 앞의 비교 실험으로 확인해야 한다.

결국 남는 기준#

지금 프로젝트를 시작한다면 기술 스택은 팀에 익숙하고 널리 쓰이는 것으로 고른다.

1
대중적이고 팀에 익숙한 UI 프레임워크
2
+ TypeScript strict
3
+ 표준적인 빌드 도구
4
+ 기능 캡슐
5
+ 최소한의 공통 기반
6
+ 실행 가능한 의존성 경계
7
+ 기능별 단위 테스트와 브라우저 검증

React, Vue, Angular, Svelte, Lit은 생성 난이도와 생태계 측면에서 차이가 있을 수 있다. 그래도 어느 것을 고르든 기능 경계라는 별도의 문제는 남는다. 기능 하나를 해당 디렉터리 내부와 소수의 공개 API만으로 수정할 수 있다면, 경계 밖에서 추가로 읽어야 할 문맥도 줄어들 가능성이 있다.

프레임워크를 고르는 질문보다 먼저 물어야 할 것이 있다.

“문서 업로드 기능을 수정해줘”라고 했을 때 AI가 document-upload 디렉터리와 몇 개의 공개 API만 읽고 수정과 검증을 끝낼 수 있는가.

가능하다면 내가 생각하는 AI 친화적인 구조에 가깝다. 전역 스토어와 공통 훅·컴포저블·서비스·컴포넌트를 모두 돌아다녀야 한다면 프레임워크를 바꾸기 전에 소스 구조부터 다시 봐야 한다.

이 글의 결론은 프레임워크가 중요하지 않다는 것도, 아키텍처 규칙을 많이 두자는 것도 아니다.

현재 근거에서 내가 AI 친화적인 프론트엔드의 출발점으로 택한 것은 프레임워크 교체가 아니라, 기능 하나를 바꿀 때 읽어야 할 문맥을 줄이고 그 경계를 검사 가능한 규칙으로 지키는 구조다. 이 구조가 실제 작업 성능을 높이는지는 비교 실험으로 확인해야 한다.

참고 자료

• WebDesignIter: Co-Evolving Design Knowledge for Repository-Level Front-End Code Generation
• Web-Bench: A LLM Code Benchmark Based on Web Standards and Frameworks
• DesignBench: A Comprehensive Benchmark for MLLM-based Front-end Code Generation
• ContextBench: A Benchmark for Context Retrieval in Coding Agents
• DependEval: Benchmarking LLMs for Repository Dependency Understanding
• LocAgent: Graph-Guided LLM Agents for Code Localization
• Constraint Decay: The Fragility of LLM Agents in Backend Code Generation
• SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks
• The Matthew Effect of AI Programming Assistants (ICLR 2026 포스터)
• Motivations, Benefits, and Issues for Adopting Micro-Frontends