Read Original
#Frontend

배달의민족 전자계약서 화면 개편기: AI에게 맡긴 것과 사람이 챙긴 것

배달의민족 전자계약서 화면 개편기: AI에게 맡긴 것과 사람이 챙긴 것
01

Summary

AI에게 코딩을 맡기고 사람이 경계를 잡다: 배민 전자계약서 프론트엔드 대개편 잔혹기와 성공 방정식

뷰, 폼, 스토어 분리와 테스트 주도 AI 협업으로 구현 속도 2배, 테스트 자산 8배를 달성한 실전 아키텍처 전략

배달의민족 전자계약서 작성 화면을 처음부터 재설계하며 AI 코딩 도구를 효율적으로 제어한 프론트엔드 개편 사례입니다. 코드 작성 영역을 View, Form, Store로 명확히 나누고 명세와 테스트를 먼저 작성하는 프로세스를 구축하여 AI 코딩의 고질적 문제인 맥락 이탈을 방지했습니다. 결과적으로 프로덕션 개발 속도 2배 향상과 강력한 테스트 자산을 확보하는 성과를 이루었습니다.

  • 01View, Form, Store로 프론트엔드 아키텍처를 분리하고 ESLint/테스트로 아키텍처 경계 강제
  • 02AI가 사내 디자인시스템 문서를 읽어 스크린샷과 시각적 차이를 스스로 비교·수정하는 UI 생성 스킬 구축
  • 03구현-명세-테스트를 1:1:1 짝으로 묶어 파일 단위의 좁은 맥락 안에서 AI 코딩을 유도하는 5단계 개발 흐름 정립
  • 04이전 유사 개편 대비 프로덕션 로직 작성 속도 2배, 테스트 코드 비율 8.5배(줄당 1.28줄) 대폭 증가
  • 05배포 초기 버그 분석을 통해 AI 시대 프론트엔드 엔지니어의 핵심 역량이 넓은 맥락 추론과 코드 통합 검증임을 입증

RECOMMENDATION

AI 코딩 도구를 도입했으나 맥락 왜곡이나 환각으로 어려움을 겪는 프론트엔드 팀에 적극 추천합니다. 명세 중심 테스트 자산 구축과 아키텍처 경계 설정을 통해 생산성과 안정성을 모두 챙기는 실무 가이드를 제공합니다.

The Problem

기존 전자계약서 화면은 사내 디자인시스템과 연동되지 않는 외부 라이브러리 기반으로 제작되어 디자이너와의 협업이 어려웠습니다. 또한 폼 상태 관리 체계가 없어 전역 객체를 직접 수정하고 상위 컴포넌트를 강제로 다시 그리는 리렌더링 문제와 비효율적인 코드 구조를 가지고 있었습니다.

The Solution

코드를 View, Form, Store의 세 영역으로 명확히 분리하고, AI 코딩 도구(Claude Code)가 아키텍처 경계를 벗어나지 않도록 파일별 명세서와 테스트 코드를 선제적으로 작성하는 프로세스를 도입했습니다. 디자인시스템 문서화 및 스크린샷 비교 기반의 자동화 스킬을 구축하여 View UI 작성을 AI에게 맡기고 테스트 기반 개발을 수행했습니다.

The Result

이전 개편 작업 대비 프로덕션 로직 개발 속도가 약 2배 향상되었으며, 프로덕션 코드 1줄당 테스트 코드가 0.15줄에서 1.28줄로 약 8.5배 증가했습니다. 배포 후 초반 일주일간 4건의 동작 버그가 발생했으나, 구조 정립과 테스트 자산 확보를 통해 6주 차 이후로는 버그 발생률 0건을 달성했습니다.

Trade-off

AI가 각 진입점마다 유사 코드를 독립적으로 생성하면서 진입점 간 로직 불일치 및 공통화 부재 문제가 발생했습니다. 코드 생성 속도에 비해 사람이 전체 맥락과 영향을 파악하고 검증하는 인지 속도가 병목으로 작용하여 배포 직후 초기 버그 수가 증가하는 한계가 있었습니다.

03

Key Concepts

Concept · 01

View-Form-Store 패턴

프론트엔드 코드를 화면 렌더링(View), 사용자 입력 및 검증 상태(Form), 비즈니스 로직 및 외부 데이터 연동(Store)으로 명확히 역할 분리하는 아키텍처 방식입니다.

  • View는 상태 없이 입력받은 props 기반으로 UI만 그려 스토리북을 활용한 독립 테스트 가능
  • Store는 Zustand와 의존성 주입(DI)을 통해 리액트 컴포넌트 라이프사이클과 독립적으로 로직 테스트 가능
Concept · 02

명세-테스트-구현 파일 짝짓기 (Specification Pair)

단일 기능 단위마다 명세 문서(.spec.md), 테스트 코드(.test.tsx), 실제 구현 코드(.tsx)를 동일한 폴더 구조로 1:1:1 대응하여 관리하는 방식입니다.

  • AI가 읽어야 할 컨텍스트의 범위를 단일 파일 쌍으로 한정하여 맥락 유실 및 오작동 방지
  • 명세 변경 -> 승인 -> 테스트 작성 -> 승인 -> 구현의 엄격한 단계별 작업 절차 준수
Concept · 03

의존성 주입 (Dependency Injection)

스토어나 모듈 내부에서 외부 API나 서비스 객체를 직접 참조하지 않고, 외부에서 인자로 전달받아 사용하는 소프트웨어 디자인 패턴입니다.

  • Store 생성 시 외부 API 호출 함수를 deps 인자로 주입받도록 구성
  • 실제 앱에서는 진짜 API를, 테스트 환경에서는 모의(Fake) API를 주입하여 백엔드 서버 없이 독립적 테스트 수행