avatar
$
AI가 코드를 짜는 시대, 프론트엔드 엔지니어링은 어디로 가는가
avatar

yceffort

·22분
frontendaiweb

Table of Contents

개요

얼마 전 AI에게 컴포넌트 하나를 시켰다. 30초 만에 코드가 나왔다. 동작도 했다. 그런데 프로덕션에 올리기엔 찝찝했다. 리렌더링이 불필요하게 많았고, 상태를 엉뚱한 곳에서 관리하고 있었고, API 호출 패턴이 워터폴을 만들고 있었다. 명세 없이 "대충 만들어줘"라고 시킨 결과였다. AI가 만든 코드를 고치는 데 결국 직접 짜는 것보다 더 오래 걸렸다.

"개발자가 필요 없어지는 것 아니냐"는 이야기가 나온다. 틀렸다. 없어지는 건 개발자가 아니라, 개발자가 하던 일의 형태다. 코드를 타이핑하는 시간은 줄었지만, "이 코드가 프로덕션에 나가도 되는가"를 판단하는 일은 오히려 더 많아졌다. AI가 코드를 짜는 속도가 빨라질수록, 그 코드를 검증하고 방향을 잡아주는 사람의 역할이 더 중요해진다.

AI 코딩 도구를 적극적으로 쓰면서 느끼는 변화들을 프론트엔드 엔지니어 입장에서 정리해본다.

AI에게 코드를 시키기 전에, 명세를 먼저 정의해라

AI 코딩 도구를 쓸 때 가장 흔한 실수는 코드와 테스트를 동시에 만들어달라고 하는 것이다. AI가 자기가 만든 잘못된 코드를 "정상"이라고 확인해주는 테스트를 같이 만든다. 틀린 답안지에 맞는 채점 기준표를 스스로 만드는 셈이다.

그래서 "테스트를 먼저 쓰고 AI에게 코드를 시켜라"는 원칙이 나온다. TDD가 AI 시대에 가장 강력한 품질 관리 도구라는 이야기인데, 프론트엔드에서는 이걸 그대로 적용하기 어렵다. 솔직히 말하면, 프론트엔드와 TDD는 궁합이 좋지 않다.

프론트엔드에서 TDD가 어려운 데는 근본적인 이유가 있다.

첫째, 프론트엔드의 결과물은 시각적 출력이다. "버튼을 클릭하면 모달이 열린다"는 테스트로 쓸 수 있지만, "이 모달이 디자인 시안과 맞는가"는 테스트로 표현할 수 없다. CSS 한 줄 바꿨는데 레이아웃이 깨지는 걸 단위 테스트가 잡아주지 않는다.

둘째, UI 테스트는 유지 비용이 높다. Testing Library처럼 role이나 label 기반으로 테스트하면 DOM 구조 변경에 대한 취약성은 줄일 수 있다. 하지만 컴포넌트를 분리하거나 상태 관리 방식을 바꾸면 테스트도 같이 바꿔야 하는 건 여전하다. UI가 자주 바뀌는 프로젝트에서 테스트 유지 비용이 높아 "작성 → 유지 포기 → 삭제"의 사이클을 반복하는 팀이 많다.

셋째, 프론트엔드의 "올바른 동작"은 맥락에 따라 달라진다. 같은 컴포넌트라도 모바일과 데스크톱에서 다르게 동작해야 하고, 네트워크 상태에 따라 다른 UI를 보여줘야 한다. 이런 조합을 전부 테스트로 커버하는 건 비현실적이다.

그래서 프론트엔드에서는 "테스트를 먼저 쓴다"를 "명세를 먼저 정의한다"로 확장해서 생각해야 한다. 영역에 따라 명세의 형태가 다르다.

비즈니스 로직은 TDD가 잘 맞는다. 카드 한도 계산, 할부 이자 산출, 입력값 유효성 검증 같은 건 순수 함수로 분리할 수 있고, 입력과 출력이 명확하다. 테스트를 먼저 쓰고 "이 테스트를 통과하는 함수를 만들어줘"라고 AI에게 시키면 꽤 정확한 결과가 나온다.

UI 컴포넌트는 스토리북이 명세 역할을 한다. 컴포넌트의 각 상태(기본, 로딩, 에러, 빈 상태 등)를 스토리로 먼저 정의하고, AI에게 그에 맞는 컴포넌트를 만들게 한다. 시각적 회귀 테스트 도구(Chromatic 등)가 "이전과 달라졌는가"를 자동으로 잡아준다. TDD와 형태는 다르지만, "검증 기준을 먼저 정의하고 AI에게 구현을 맡긴다"는 원칙은 같다.

상태 관리와 데이터 흐름은 타입 시스템이 명세가 된다. TypeScript의 타입 정의를 정밀하게 해두면, AI가 타입에 맞지 않는 코드를 생성했을 때 컴파일 단계에서 잡힌다. 잘못된 코드가 애초에 존재할 수 없게 만드는 것이다. any 타입을 남발하는 코드베이스에서는 이 효과를 기대할 수 없다. 타입을 엄격하게 쓸수록 AI가 만든 코드의 신뢰도가 올라간다.

정리하면, 프론트엔드에서 AI에게 코드를 시키기 전에 먼저 정의해야 하는 것은 비즈니스 로직의 테스트, UI의 스토리, 데이터 흐름의 타입이다. 세 가지 모두 "AI가 만든 결과물을 자동으로 검증할 수 있는 기준"이라는 점에서 본질은 같다.

코드 리뷰가 하던 네 가지 역할이 흩어진다

코드 리뷰는 사실 네 가지 일을 동시에 하고 있었다.

  1. 후배 교육. 시니어가 주니어의 코드를 보면서 더 나은 방법을 알려주는 것.
  2. 코딩 스타일 통일. 팀 전체가 일관된 방식으로 코드를 작성하게 만드는 것.
  3. 버그 잡기. 논리적 오류나 엣지 케이스를 찾아내는 것.
  4. 신뢰 확보. "이 코드를 프로덕션에 올려도 괜찮은가"라는 확신을 얻는 것.

AI가 코드를 대량 생산하면 사람이 한 줄씩 리뷰하는 게 현실적으로 불가능해진다. 하루에 올라오는 PR 양이 이전과는 비교가 안 된다. 그렇다고 리뷰를 없애면 이 네 가지가 전부 사라진다.

코딩 스타일 통일 → 린터와 포매터, 그리고 커스텀 규칙. ESLint, Prettier가 기본적인 코드 스타일은 이미 잡아주고 있다. 하지만 리뷰에서 반복적으로 지적하게 되는 건 포맷팅이 아니라 팀 컨벤션이다. 이걸 커스텀 ESLint 규칙으로 만들면 된다. "이벤트 핸들러 네이밍은 handle- 접두사를 쓴다", "API 호출은 반드시 이 래퍼 함수를 쓴다" 같은 것들이다. 예전에는 커스텀 규칙을 만드는 비용이 커서 엄두를 못 냈지만, AI에게 "이런 패턴을 잡아내는 ESLint 규칙을 만들어줘"라고 시키면 금방 나온다. 사람이 리뷰에서 반복적으로 하던 지적을 도구로 옮기는 것이다.

버그 잡기 → 자동화된 테스트와 정적 분석. AI가 만든 코드든 사람이 만든 코드든, 테스트를 통과하지 못하면 머지되지 않는다. TypeScript의 타입 체크, ESLint의 규칙, CI의 테스트 파이프라인이 사람 대신 버그를 잡는다.

신뢰 확보 → 위험도에 비례하는 검증 수준. 모든 코드를 동일한 깊이로 리뷰하는 것을 포기해야 한다. "이 코드가 틀리면 얼마나 큰 문제가 되는가"를 기준으로 리뷰의 깊이를 조절한다. 결제 플로우나 개인정보 처리 관련 코드는 반드시 사람이 꼼꼼히 본다. 내부 어드민 도구의 UI 수정은 자동 테스트 통과와 시각적 회귀 테스트만으로 충분하다. 엔지니어링이 장인 모델(모든 줄을 사람이 검수)에서 위험 관리 모델(검증 투자는 위험도에 비례)로 전환되는 것이다.

후배 교육 → 함께 코딩하는 시간. 이게 가장 어렵다. 코드 리뷰는 비동기적이라 시간 부담이 적었다. 페어 프로그래밍은 동기적이고, 양쪽 모두의 시간을 직접 소비한다. 하지만 AI가 코드를 생성하는 속도로 리뷰가 쌓이는 환경에서, 비동기 리뷰로 교육 효과를 기대하기는 점점 어려워진다. 주니어가 AI 도구로 만든 코드를 올렸는데, 시니어가 "이거 왜 이렇게 했어?"라고 물으면 "AI가 이렇게 만들었어요"라고 답하는 상황. 코드 리뷰가 학습 채널로 작동하지 않는다.

현실적인 대안은 형태를 바꾸는 것이다. 주니어가 AI에게 프롬프트를 쓰고 결과물을 판단하는 과정을 시니어가 옆에서 코칭하는 식의 페어 프로그래밍, 주 1회 짧은 라이브 코딩 세션에서 "이번 주에 AI로 만든 코드 중 가장 고민됐던 것"을 함께 리뷰하는 식이다. 시간 투자가 필요하지만, AI가 코드를 만들어주는 세상에서 교육의 초점은 "코드를 짜는 법"이 아니라 "AI가 만든 코드를 판단하는 법"이 되어야 한다.

기술 부채가 아니라 "인지 부채"를 걱정해야 한다

기술 부채는 익숙한 개념이다. 코드에 쌓이고, 리팩토링으로 갚는다.

더 걱정해야 할 건 "인지 부채"다. 시스템의 복잡도와 팀이 그 시스템을 이해하는 정도 사이의 격차를 말한다.

프론트엔드는 특히 인지 부채가 쌓이기 쉬운 환경이다. 컴포넌트 수가 수백 개에 달하고, 각 컴포넌트가 어떤 상태를 관리하고, 어떤 API와 연결되어 있고, 어떤 조건에서 어떤 화면을 보여주는지를 전부 파악하는 건 쉽지 않다. 여기에 AI가 코드 변경 속도를 높이면, 코드는 빠르게 변하는데 사람이 시스템을 이해하는 속도는 그대로다. 코드 리뷰가 줄어들면 시스템의 변화를 자연스럽게 학습하는 채널도 사라진다.

5명짜리 팀에서 한 사람만 시스템을 다 이해하고 있다면, 그 자체가 팀의 인지 부채다. 아무리 그 사람이 뛰어나도, 그 사람이 빠지면 팀이 멈춘다. AI가 코드 생산 속도를 높일수록 이 문제는 더 빠르게 악화된다.

프론트엔드 팀에서 현실적으로 할 수 있는 건 몇 가지가 있다.

  • 주간 아키텍처 회고. 이번 주에 컴포넌트 구조나 상태 관리가 어떻게 바뀌었는지를 팀 전체가 15분이라도 함께 확인한다. 코드를 한 줄씩 보는 게 아니라, 변경의 방향과 의도를 공유하는 것이다.
  • 스토리북을 컴포넌트 문서로 활용. 코드를 읽지 않아도 각 컴포넌트가 어떤 상태를 가지는지 파악할 수 있게 한다. 새 팀원이 왔을 때 스토리북만 훑어봐도 시스템의 UI 구조가 머릿속에 그려지는 수준이면 된다.
  • AI를 코드 이해에도 활용. "이 디렉토리의 컴포넌트 의존 관계를 설명해줘"라고 AI에게 물어보는 것만으로도 시스템 파악이 빨라진다. AI가 코드를 만드는 속도로 인지 부채가 쌓인다면, AI로 인지 부채를 갚는 것도 가능하다.

요구사항의 품질이 코드 품질보다 중요해진다

앞에서는 테스트, 스토리, 타입 같은 기술적 검증 기준을 이야기했다. 여기서는 그보다 앞단의 문제, 요구사항 자체의 품질을 이야기한다. AI에게 코드를 시키려면, "뭘 만들어야 하는지"를 정확하게 써줘야 한다. "사용자로서 ~를 원한다" 같은 모호한 유저 스토리는 AI가 해석하기에 너무 애매하다. AI는 모호한 입력에 대해 그럴듯하지만 틀린 결과를 자신 있게 만들어낸다.

프론트엔드에서 이 문제가 특히 두드러지는 영역이 폼 유효성 검증과 조건부 UI다. "이메일 형식이 잘못되면 에러를 보여준다" 정도의 스펙으로는 AI가 제대로 된 구현을 만들기 어렵다. "이메일 입력 중에는 에러를 보여주지 않고, 포커스를 벗어난 뒤에 검증하며, 서버 검증과 클라이언트 검증의 에러 메시지가 다르고, 에러 상태에서 다시 입력하면 에러가 사라진다" 같은 수준의 명세가 필요하다.

금융 서비스 프론트엔드에서는 더하다. "카드 한도 초과 시 어떻게 동작해야 하는가"를 자연어로 모호하게 쓰면, AI는 그럴듯하지만 틀린 구현을 만든다. 상태 머신으로 각 화면 상태와 전이 조건을 정확히 정의하면, AI가 그에 맞는 코드를 훨씬 정확하게 생성한다.

이건 역설적으로 프론트엔드 엔지니어의 가치가 높아지는 부분이다. 좋은 UI 명세를 쓰려면 사용자 행동 패턴을 이해해야 하고, 엣지 케이스(네트워크 에러, 동시 입력, 느린 응답 등)를 예측할 수 있어야 하며, 브라우저와 디바이스의 제약을 알고 있어야 한다. 코딩 능력은 AI가 대체할 수 있지만, 이 능력은 대체하기 훨씬 어렵다.

병목이 "만드는 속도"에서 "결정하는 속도"로 옮겨간다

AI 도구를 도입하면 코드 생산 속도는 확실히 빨라진다. 컴포넌트 하나 만드는 데 반나절 걸리던 게 30분이면 끝난다. 그런데 조직의 의사결정 속도는 그대로다.

디자인 리뷰 기다리는 시간, API 스펙 확정 기다리는 시간, 다른 팀과의 의존성 해결 기다리는 시간. 이건 AI 도구로 줄일 수 없다. 팀이 백로그를 며칠 만에 처리해도, 바로 이런 벽에 부딪힌다. 결과적으로 전체 속도는 변하지 않고, 좌절감만 커진다.

이 문제는 모든 엔지니어링 팀에 해당하지만, 프론트엔드에서 특히 심하다. 프론트엔드는 디자인, 백엔드 API, 기획 세 방향의 의존성을 동시에 받는 위치에 있기 때문이다. 흔히 겪는 시나리오가 있다. AI로 컴포넌트를 빠르게 만들었는데, 디자이너의 피드백이 일주일 뒤에 온다. 수정은 30분이면 되지만 피드백 대기가 5일이다. API가 아직 안 나와서 목업 데이터로 작업했는데, 실제 API 응답 구조가 달라서 다시 만들어야 한다. 기획이 A/B 테스트를 결정 못 해서 두 버전을 다 만들어놨는데, 결국 둘 다 안 쓴다. 코드 생산 속도가 아무리 빨라져도, 이런 구조적 병목 앞에서는 무력하다.

이걸 인지하고 있으면, 생산성 향상을 추구할 때 방향이 달라진다. "AI 도구를 더 잘 쓰자"가 아니라 "결정이 빨리 내려지는 구조를 만들자"가 되어야 한다. 디자인과 개발의 동기화 주기를 줄이거나, API 스펙을 먼저 합의하고 병렬로 작업하거나, 위험도가 낮은 UI 결정은 프론트엔드 팀에서 자율적으로 내릴 수 있게 권한을 위임하는 식이다.

AI가 대량 생산을 쉽게 만들어도, 작게 나눠 배포해야 한다

AI 도구로 큰 규모의 코드 변경을 쉽게 만들 수 있게 되면서, "한 번에 크게 배포"하는 방식으로 돌아가는 팀들이 보인다.

10년간의 DORA 리서치가 반복적으로 증명한 결론은 "작게 자주 배포할수록 안정적"이라는 것이다. 직관과 다르다. 큰 변경을 한 번에 하면 효율적일 것 같지만, 실제로는 문제가 생겼을 때 원인을 찾기가 훨씬 어렵고 롤백도 복잡해진다.

프론트엔드에서 이 함정에 특히 빠지기 쉽다. AI가 컴포넌트 10개를 한꺼번에 리팩토링해줄 수 있다. 공통 스타일 변경, 상태 관리 마이그레이션, API 연동 방식 변경 같은 것들을 AI가 일괄로 처리해주면, 하나의 거대한 PR이 만들어진다. 이걸 리뷰하는 건 사실상 불가능하고, 배포 후 장애가 나면 열 군데 중 어디가 원인인지 알 수 없다.

AI가 만들어준 변경이라고 해서 배포 원칙까지 바뀌는 건 아니다. AI에게 "한 번에 다 바꿔줘"라고 시키지 말고, "이 컴포넌트만 바꿔줘"를 열 번 시키는 게 맞다. PR 크기 제한과 배포 빈도는 의식적으로 관리해야 한다.

시니어 프론트엔드 엔지니어의 역할 전환

경험 많은 엔지니어가 AI 도구를 쓸 때 더 효과적인 결과를 내는 건 어찌 보면 당연하다. 시스템 아키텍처에 대한 이해가 깊으니까, AI에게 더 정확한 맥락을 줄 수 있고, 만들어진 결과물의 품질을 빠르게 판단할 수 있다.

프론트엔드에서 이 차이가 드러나는 전형적인 장면이 있다. AI가 컴포넌트를 만들어줬는데, 주니어는 "동작하니까 됐다"고 생각한다. 시니어는 "이 컴포넌트가 번들에서 차지하는 비중이 너무 크다", "이 의존성은 트리쉐이킹이 안 된다", "이 데이터 페칭 패턴은 레이아웃 시프트를 만든다"를 바로 잡아낸다. AI가 코드를 짜는 세상에서, 이런 판단력의 가치는 오히려 올라간다.

시니어 엔지니어의 역할은 "컴포넌트를 직접 많이 만드는 사람"에서 "팀과 시스템의 병목을 찾아 제거하는 사람"으로 바뀌고 있다. 번들 사이즈가 왜 커졌는지, 어떤 의존성이 빌드를 느리게 만드는지, 컴포넌트 구조의 어디에서 복잡도가 폭발하는지. 이런 걸 아는 건 경험 있는 사람만 할 수 있다.

다만 이 전환이 쉽지 않다. 코딩을 좋아해서 이 업계에 들어온 사람에게 "이제 직접 코딩은 줄여라"라고 하는 것이다. 컴퓨터 그래픽 분야의 역사가 좋은 비유다. 1990년대 초반에 폴리곤 렌더링 알고리즘을 손으로 짜던 엔지니어들은, 3dfx Voodoo 같은 3D 가속 카드가 보급되면서 그 작업이 하드웨어로 내려갔다. 하지만 그 위에서 애니메이션, 조명, 물리 엔진이라는 새로운 전문 영역이 열렸다. 추상화 계층이 올라갈 때마다 "나는 폴리곤을 렌더링하려고 고용된 사람인데"라며 멈춘 사람들은 뒤처졌다.

같은 일이 프론트엔드에서 벌어지고 있다. 컴포넌트를 직접 짜는 작업이 AI로 내려가면, 그 위에서 성능 최적화, 아키텍처 설계, 팀의 인지 부채 관리라는 전문 영역이 더 중요해진다.

마치며

에이전트 운영체제니 자기 치유 시스템이니 하는 이야기들은 아직 먼 미래다. 프론트엔드 팀에서 지금 당장 할 수 있는 건 이것들이다.

  • 비즈니스 로직은 테스트를, UI는 스토리북을, 데이터 흐름은 타입을 먼저 정의하고 AI에게 구현을 시킨다.
  • 코드 리뷰의 목적을 분리하고, 결제나 개인정보 같은 고위험 영역은 사람이 꼼꼼히 보되 나머지는 자동 검증에 맡긴다.
  • AI 도구를 쓰더라도 PR 크기와 배포 빈도를 의식적으로 관리한다.
  • "우리 팀이 시스템을 얼마나 이해하고 있는가"를 주기적으로 점검한다.

AI가 프론트엔드 개발을 바꾸고 있는 건 사실이다. 하지만 바뀌는 건 "컴포넌트를 만드는 방법"이지, "좋은 사용자 경험을 만드는 데 필요한 것"이 아니다. 사용자 행동을 이해하는 능력, 복잡한 상태를 설계하는 능력, 성능 병목을 진단하는 능력, 팀이 함께 시스템을 이해하는 문화를 만드는 능력. 이런 것들은 AI가 코드를 아무리 잘 짜도 여전히 사람의 몫이다.

도구가 바뀌었다고 원칙까지 바뀌는 건 아니다.