핵심 요약 (Summary)
AI는 코드를 빠르게 만들어줍니다. 하지만 "서버 컴포넌트로 분리해줘", "번들 사이즈 줄여줘", "캐시 전략 세워줘"처럼 정확하게 지시하려면, 개발자가 먼저 그 개념을 이해하고 있어야 합니다. 아키텍처 설계, 서버/클라이언트 컴포넌트 경계, 캐시와 클라이언트 상태 동기화, SEO, 프록시, 번들링, 초기 진입 성능 최적화까지 — 이것들은 AI가 스스로 결정해주는 영역이 아니라, FE 개발자가 판단하고 AI에게 지시해야 하는 영역입니다.
왜 이런 문제가 발생하나요? (Why)
팀에 AI 개발 도구가 도입된 직후의 상황입니다.
여러 개발자가 같은 서비스의 아티클 목록 페이지를 맡았습니다.
한 명은 "이 페이지 Next.js로 만들어줘"라고 요청했습니다. AI는 그럴듯한 코드를 만들어냈고, 로컬에서는 잘 동작했습니다. 하지만 배포 후 SEO 점수는 바닥이었고, 첫 진입 번들 용량은 380KB가 넘었으며, 글을 새로 작성한 뒤 목록 페이지로 돌아오면 방금 쓴 글이 보이지 않는 상황이 반복됐습니다. 어디서부터 손을 대야 할지 몰랐습니다.
다른 한 명은 이렇게 요청했습니다. "콘텐츠 렌더링은 서버 컴포넌트로 처리하고, 필터 UI만 클라이언트 컴포넌트로 분리해줘. 데이터 fetching에는 fetch 캐시를 쓰고, 글 작성 후엔 revalidateTag로 캐시를 갱신해줘. 초기 번들은 100KB 이하가 목표야." AI는 즉시 정확한 코드를 만들었고, 배포 후 문제가 없었습니다.
차이는 AI를 얼마나 잘 쓰느냐가 아니었습니다. 무엇을 알고 있느냐의 차이였습니다.
아키텍처는 AI가 대신 결정해주지 않습니다
AI에게 컴포넌트 하나를 만들어달라고 하는 것은 쉽습니다. 하지만 "이 서비스 전체를 어떤 구조로 만들어야 하는가"는 AI가 스스로 판단해주지 않습니다. AI는 당신의 서비스 규모, 팀 구성, 배포 환경, 트래픽 패턴을 모릅니다.
아키텍처 설계란 결국 다음 질문에 스스로 답을 갖는 것입니다.
어떤 페이지가 정적으로 생성돼야 하고, 어떤 페이지가 요청마다 새로 렌더링돼야 하는가. 데이터는 어디서 가져오고, 그 흐름이 컴포넌트 트리에서 어떻게 이동하는가. 공통 레이아웃은 어디에 두고, 어떤 기준으로 모듈을 분리하는가.
이 판단을 내리지 못한 채 AI에게 위임하면, AI는 가장 일반적인 구조를 선택합니다. 그 구조가 여러분의 서비스에 맞는지는 아무도 보장하지 않습니다.
서버 컴포넌트와 클라이언트 컴포넌트, 경계를 그어야 합니다
Next.js App Router 이후 가장 자주 잘못 설계되는 영역이 서버/클라이언트 컴포넌트 경계입니다.
AI에게 "댓글 목록 컴포넌트 만들어줘"라고 하면, 별다른 지시가 없을 때 AI는 "use client"를 붙여 클라이언트 컴포넌트로 만들 때가 많습니다. 동작은 합니다. 하지만 데이터 fetching이 클라이언트로 내려오면서, 그 컴포넌트가 서버에서 사전 렌더링될 기회를 잃습니다. SEO에도 영향을 주고, 초기 로딩 속도에도 영향을 줍니다.
올바른 경계를 잡으려면 판단 기준이 있어야 합니다. 이 컴포넌트가 브라우저 API를 사용하는가, 사용자 이벤트를 처리해야 하는가, 아니면 데이터를 받아 렌더링만 하는가. 이 기준을 AI에게 전달해야만, AI가 올바른 방향으로 코드를 만들어냅니다.
서버 캐시와 클라이언트 상태가 충돌하는 순간
서버에서 캐시된 데이터와 클라이언트에서 변경한 상태가 어긋나는 문제는, 실무에서 가장 자주 마주치는 버그 유형 중 하나입니다.
서버에서 60초 캐시로 가져온 게시글 목록이 있습니다. 사용자가 새 글을 작성하고 목록 페이지로 돌아왔을 때, 방금 쓴 글이 보이지 않습니다. 서버 캐시가 아직 갱신되지 않았기 때문입니다.
이 문제를 해결하려면 두 가지 전략 중 하나를 선택해야 합니다. 글 작성 후 특정 캐시 태그를 revalidate하거나, 클라이언트에서 Optimistic Update를 적용해 서버 응답 이전에 먼저 UI를 갱신하는 방식입니다.
어떤 전략이 이 서비스에 맞는지는 AI가 판단해주지 않습니다. 서버 캐시 전략과 클라이언트 상태 관리의 역할 분담을 이해하고 있어야, 비로소 정확한 지시를 내릴 수 있습니다.
SEO는 크롤러가 보는 HTML이 기준입니다
AI에게 "SEO 최적화해줘"라고 요청하면, 대부분 <title> 태그와 <meta> 태그를 추가하는 수준에서 끝납니다. 하지만 실무에서의 SEO는 훨씬 구체적인 판단을 요구합니다.
검색 엔진 크롤러는 JavaScript를 완전히 실행하지 않는 경우가 많습니다. 클라이언트 컴포넌트에서만 렌더링되는 콘텐츠는 크롤러에게 보이지 않을 수 있습니다. 중요한 콘텐츠일수록 서버에서 미리 렌더링되어 HTML에 포함되어 있어야 한다는 의미입니다.
Open Graph 태그, 캐노니컬 URL, 구조화 데이터(JSON-LD), 사이트맵 자동 생성까지 각각 어느 단계에서 어떻게 처리되어야 하는지 알아야 합니다. "SEO 잘 되게 만들어줘"라는 요청과, "이 페이지는 서버 컴포넌트에서 generateMetadata로 동적으로 메타 태그를 생성하고, 상품 데이터는 JSON-LD 형식으로 구조화해줘"라는 요청은 AI로부터 전혀 다른 결과물을 만들어냅니다.
프록시는 왜 필요하고, 어디에 두어야 하나요
"API 요청 시 CORS 에러가 나는데 고쳐줘"라고 AI에게 물으면, 보통 두 가지 답변 중 하나가 돌아옵니다. 서버에 CORS 헤더를 추가하거나, 프론트엔드에 프록시를 설정하라는 것입니다.
어떤 방법이 이 상황에 맞는지 판단하려면, 프록시가 왜 필요한지를 먼저 알아야 합니다. 프록시는 단순히 CORS 에러를 우회하는 수단이 아닙니다. API 키를 클라이언트에 노출하지 않기 위해, 여러 마이크로서비스의 엔드포인트를 하나로 통합하기 위해, 요청과 응답에 공통 로직을 추가하기 위해 사용하는 구조입니다.
Next.js의 Route Handler, next.config.js의 rewrites, 별도 BFF(Backend for Frontend) 레이어 — 각각이 어떤 상황에 적합한지 알지 못하면, AI가 제안하는 해결책이 올바른지 판단할 수 없습니다.
번들링, 무엇이 얼마나 포함되는지 알아야 합니다
"이 라이브러리 추가해줘"라는 요청을 반복하다 보면, 어느 순간 번들 사이즈가 조용히 커져 있습니다. AI는 기능을 구현하는 데 집중하지, 번들 용량을 알아서 관리해주지 않습니다.
번들링을 이해한다는 것은 다음을 판단할 수 있다는 뜻입니다. 이 라이브러리는 Tree Shaking이 지원되는가. 이 코드는 모든 페이지에 포함되어야 하는가, 아니면 해당 페이지에서만 동적으로 불러와야 하는가. 이미지와 폰트는 어떤 방식으로 최적화되어야 하는가.
번들 분석 도구로 현재 상태를 파악하고, "이 컴포넌트는 dynamic import로 코드 스플리팅해줘", "lodash 전체가 아니라 필요한 함수만 named import로 가져오게 바꿔줘"처럼 지시할 수 있어야 합니다. 이 지시를 내리려면 번들이 어떻게 구성되는지를 먼저 알아야 합니다.
초기 진입 100KB, 왜 이 기준이 중요한가요
퍼포먼스 예산(Performance Budget)이라는 개념이 있습니다. 사용자가 페이지에 처음 진입할 때 다운로드해야 하는 리소스의 총 크기를 미리 정해두는 것입니다. 많은 팀이 초기 진입 JavaScript 번들 기준으로 100KB 이하를 목표로 잡습니다.
이 기준이 중요한 이유는 LCP, FID, TTI 같은 Core Web Vitals 지표와 직결되기 때문입니다. 그리고 이 지표들은 검색 엔진 순위에도 영향을 줍니다.
AI에게 "성능 최적화해줘"라고 하면 일반적인 패턴만 제안해줄 뿐입니다. 하지만 "현재 First Load JS가 340KB인데, 초기 진입 경로에서 불필요한 컴포넌트를 lazy load로 분리하고, 폰트를 preload로 처리해줘. 목표는 100KB 이하야"라고 하면, AI는 구체적인 실행 계획을 즉시 제시합니다. 개발자가 지표의 의미를 알고, 현재 수치를 파악하고, 목표를 설정할 수 있을 때 비로소 AI가 제 역할을 합니다.
정리 (Conclusion)
AI는 FE 개발의 실행 속도를 극적으로 높여줍니다. 하지만 "무엇을 만들어야 하는가", "어떤 구조가 이 서비스에 맞는가", "이 결정의 트레이드오프는 무엇인가"는 여전히 개발자가 판단해야 하는 영역입니다.
AI에게 아키텍처를 물을 수는 있습니다. 하지만 그 답변이 맞는지 틀렸는지를 판단하는 것은, 개발자가 먼저 이 개념들을 이해하고 있을 때만 가능합니다.
AI를 잘 다루는 개발자는 덜 아는 사람이 아닙니다. 오히려 핵심 개념을 명확히 알기 때문에, AI에게 정확하게 지시하고 결과물을 올바르게 검토할 수 있는 사람입니다.
AI 시대에도 공부해야 할 이유는 AI 때문이 아니라, AI를 제대로 쓰기 위해서입니다.