AI가 만든 프론트엔드 코드를 리뷰할 때 보는 기준

AI 코딩 도구는 프론트엔드 개발에서 꽤 강력합니다. React 컴포넌트를 만들고, TypeScript 타입을 붙이고, CSS를 작성하고, 테스트 초안까지 만들어 줍니다. 특히 반복적인 UI 작업이나 기존 패턴을 따라가는 작업에서는 생산성이 확실히 좋아집니다.

하지만 AI가 만든 코드를 그대로 머지해도 되는지는 다른 문제입니다. 겉으로는 동작하는 것처럼 보여도 요구사항을 일부 놓치거나, 상태 관리를 복잡하게 만들거나, 접근성과 테스트가 빠져 있는 경우가 많습니다.

이번 글에서는 AI가 만든 프론트엔드 코드를 리뷰할 때 확인하면 좋은 기준을 정리해보겠습니다. React와 TypeScript 프로젝트를 기준으로 설명하지만, Vue나 다른 프레임워크에서도 대부분 비슷하게 적용할 수 있습니다.

1. 요구사항을 제대로 만족했는가

가장 먼저 볼 것은 코드 스타일이 아니라 요구사항입니다. AI는 사용자가 말한 내용을 빠르게 구현하지만, 문장 사이에 숨어 있는 조건이나 예외 상황을 잘 놓칩니다.

예를 들어 “상품 목록에서 품절 상품은 비활성화해줘”라는 요구사항이 있었다고 해보겠습니다. 리뷰할 때는 단순히 버튼이 disabled 되었는지만 보면 부족합니다.

확인해야 할 항목은 다음과 같습니다.

• 품절 상품이 클릭되지 않는가?
• 키보드 접근에서도 비활성 상태가 유지되는가?
• 품절 사유나 상태가 사용자에게 표시되는가?
• API 데이터가 늦게 도착해도 상태가 꼬이지 않는가?
• 필터, 검색, 페이지네이션과 함께 동작하는가?

AI 코드는 “대표 케이스”에는 강하지만 “경계 조건”에는 약한 편입니다. 그래서 리뷰에서는 정상 케이스보다 예외 케이스를 먼저 보는 것이 좋습니다.

2. 변경 범위가 필요 이상으로 넓지 않은가

AI에게 작업을 맡기면 가끔 요청하지 않은 리팩터링까지 함께 들어갑니다. 변수명 몇 개를 고치거나 컴포넌트를 하나 추가하면 될 일을, 폴더 구조를 바꾸고 공통 유틸을 새로 만들고 스타일 방식까지 바꿔버리는 식입니다.

리뷰에서는 다음을 확인합니다.

• 요구사항과 직접 관련 없는 파일이 수정되었는가?
• 기존 패턴을 무시하고 새로운 구조를 만들었는가?
• 한 PR 안에 기능 추가와 대규모 리팩터링이 섞였는가?
• 삭제된 코드가 실제로 사용되지 않는 것이 맞는가?
• 패키지 추가가 꼭 필요한가?

AI가 제안한 개선이 나쁘다는 뜻은 아닙니다. 다만 변경 범위가 넓어질수록 리뷰 비용과 회귀 위험이 커집니다. 기능 구현과 구조 개선은 가능하면 분리하는 것이 좋습니다.

3. TypeScript 타입이 안전한가

AI가 만든 TypeScript 코드는 그럴듯해 보이지만, 자세히 보면 any, 과도한 optional 처리, 실제 API와 맞지 않는 타입이 섞여 있는 경우가 있습니다.

특히 아래 패턴은 주의해서 봅니다.

const data: any = await response.json();

user?.profile?.name || ''

type Status = string;

이런 코드는 당장은 에러를 피하게 해주지만, 장기적으로는 타입 시스템의 장점을 약하게 만듭니다. 리뷰에서는 다음 질문을 던져볼 수 있습니다.

• API 응답 타입이 실제 계약과 맞는가?
• 상태 값은 string보다 union type으로 제한할 수 없는가?
• optional chaining으로 에러를 숨기고 있지는 않은가?
• null, undefined, empty array의 의미가 구분되어 있는가?
• 컴포넌트 props가 너무 많은 책임을 갖고 있지는 않은가?

AI에게 “타입 에러 안 나게 해줘”라고만 하면 안전한 타입보다 느슨한 타입을 선택할 가능성이 있습니다. “도메인 상태를 union type으로 표현해줘”, “any 없이 작성해줘”처럼 기준을 명확히 주는 것이 좋습니다.

4. 상태 관리가 단순한가

프론트엔드 코드에서 복잡도는 대부분 상태에서 나옵니다. AI는 빠르게 동작하는 코드를 만들기 위해 useState를 여러 개 추가하거나, 서버 상태와 UI 상태를 한 컴포넌트 안에 섞어두는 경우가 많습니다.

리뷰할 때는 다음을 확인합니다.

• 같은 의미의 상태가 중복으로 존재하지 않는가?
• 서버에서 계산할 수 있는 값을 클라이언트 상태로 따로 들고 있지 않은가?
• loading, error, empty, success 상태가 명확히 구분되는가?
• derived state를 불필요하게 useEffect로 동기화하고 있지 않은가?
• 컴포넌트가 너무 많은 데이터 흐름을 알고 있지는 않은가?

예를 들어 필터링된 목록은 별도 state로 저장하기보다 원본 데이터와 필터 값에서 계산할 수 있습니다.

const filteredItems = useMemo(() => {
  return items.filter((item) => item.name.includes(keyword));
}, [items, keyword]);

반대로 사용자의 입력 중간값, 모달 열림 여부, 선택된 탭처럼 UI 상호작용에 필요한 값은 명시적인 state로 두는 것이 자연스럽습니다.

5. 접근성과 사용성을 놓치지 않았는가

AI가 만든 UI 코드는 시각적으로는 괜찮아 보이지만 접근성 속성이 빠져 있는 경우가 많습니다. 특히 버튼처럼 보이지만 div로 만든 요소, label이 없는 input, 키보드 이동이 안 되는 모달은 자주 나오는 문제입니다.

체크리스트는 간단합니다.

• 클릭 가능한 요소는 실제 button 또는 anchor를 사용하는가?
• input에는 label 또는 aria-label이 있는가?
• 모달, 드롭다운, 탭이 키보드로 조작되는가?
• disabled 상태가 시각적으로만 표현되지 않는가?
• 에러 메시지가 사용자에게 명확한가?
• 색상만으로 상태를 구분하지 않는가?

모던 CSS나 React Server Components처럼 기술적인 주제도 중요하지만, 실제 사용자에게 닿는 마지막 품질은 이런 기본기에서 갈립니다.

6. 테스트가 의미 있는가

AI는 테스트 파일도 잘 만들어 줍니다. 하지만 “렌더링된다” 정도의 테스트만 잔뜩 만드는 경우가 있습니다.

좋은 테스트는 구현 세부사항보다 사용자 행동과 결과를 확인합니다.

it('품절 상품은 장바구니에 담을 수 없다', async () => {
  render(<ProductCard product={soldOutProduct} />);

  const button = screen.getByRole('button', { name: /장바구니/i });
  expect(button).toBeDisabled();
});

리뷰할 때는 다음을 봅니다.

• 핵심 사용자 시나리오가 테스트에 포함되어 있는가?
• 실패/빈 상태/로딩 상태 테스트가 있는가?
• mock 데이터가 실제 도메인과 비슷한가?
• 내부 구현보다 화면에 보이는 결과를 검증하는가?
• 테스트 이름만 그럴듯하고 실제 검증은 약하지 않은가?

테스트는 AI 코드의 안전장치입니다. 특히 AI에게 리팩터링을 맡길수록 테스트의 중요도는 더 올라갑니다.

7. 리뷰 코멘트를 다시 AI에게 잘 전달하기

AI 코드 리뷰의 장점은 피드백을 다시 AI에게 전달해 개선시킬 수 있다는 점입니다. 다만 “고쳐줘”라고만 하면 또 다른 문제가 생길 수 있습니다.

리뷰 코멘트는 구체적으로 작성하는 것이 좋습니다.

• “상태가 복잡해요” → “selectedItem과 selectedItemId가 중복 상태이므로 selectedItemId만 남기고 선택된 객체는 계산하도록 바꿔주세요.”
• “타입이 별로예요” → “Status를 string이 아니라 'idle' | 'loading' | 'success' | 'error' union type으로 제한해주세요.”
• “테스트 추가해주세요” → “품절 상품일 때 버튼이 비활성화되고 클릭 핸들러가 호출되지 않는 테스트를 추가해주세요.”

AI에게 주는 리뷰 코멘트도 결국 스펙입니다. 구체적인 피드백일수록 결과가 좋아집니다.

실무 리뷰 체크리스트

AI가 만든 프론트엔드 코드를 머지하기 전 아래 항목을 확인해보면 좋습니다.

• 요구사항의 정상 케이스와 예외 케이스를 모두 만족하는가?
• 변경 범위가 요청한 작업 안에 머무르는가?
• 새 패키지나 구조 변경이 꼭 필요한가?
• any나 과도한 optional 처리가 없는가?
• loading, error, empty 상태가 분리되어 있는가?
• 상태가 중복으로 관리되지 않는가?
• 접근성 기본 속성이 빠지지 않았는가?
• 테스트가 사용자 행동 중심으로 작성되었는가?
• lint, typecheck, test를 통과하는가?
• AI에게 다시 전달할 피드백이 구체적인가?

마무리

AI 코딩 도구는 프론트엔드 개발의 속도를 올려줍니다. 하지만 속도가 빨라진 만큼 리뷰 기준도 더 중요해졌습니다. AI가 만든 코드는 초안으로는 훌륭하지만, 제품 코드가 되려면 요구사항, 타입, 상태, 접근성, 테스트라는 기본 기준을 통과해야 합니다.

결국 핵심은 AI를 믿지 말자는 것이 아니라, AI가 잘할 수 있는 일과 사람이 반드시 확인해야 하는 일을 나누는 것입니다. 반복 구현은 AI에게 맡기고, 제품의 품질 기준은 개발자가 잡아야 합니다.