AI 도구가 코드를 써주는 시대에 프론트엔드 개발자가 정말 씨름해야 할 문제는 따로 있다. 배포 중에 정적 자산 버전이 섞이는 현상, AI 에이전트가 20년 된 XSS 취약점을 'zero-click'으로 되살리는 구조, 그리고 AI를 갈아탈 때마다 20분씩 낭비되는 컨텍스트 재설명 비용. 기술 스택이 아무리 세련돼도 이 세 가지 균열을 메우지 못하면 속도는 오히려 뒤로 간다.
과제 1. 롤링 배포 중 정적 자산의 버전 충돌
"서버 두 대 번갈아 올리면 로드밸런서가 알아서 처리해주겠지"—이 가설은 절반만 맞다. velog에 공유된 한 Next.js 실전 사례는 이 절반의 빈틈을 정면으로 파고든다. api1이 빌드 2로 전환된 상태에서 api2가 여전히 빌드 1을 서빙하는 롤링 구간, 로드밸런서는 두 서버를 아무 맥락 없이 번갈아 물린다. 브라우저는 api1에서 받은 HTML에 담긴 chunk 경로를 api2에 요청하지만 api2는 그 경로를 모른다. 결과는 404—서버가 죽어서가 아니라 살아 있는 서버들의 버전이 달라서 생기는 404다.
흥미로운 건 문제 해결의 층위가 두 개로 나뉜다는 점이다. generateBuildId를 GITHUB_SHA로 고정하면 같은 배포 안에서 서버마다 다른 빌드 ID가 생성되는 첫 번째 문제는 해소된다. 하지만 롤링 배포 구간에서 old 배포와 new 배포가 공존하는 두 번째 문제는 여전히 남는다. 여기서 등장하는 것이 deploymentId다. 이 값이 클라이언트 쪽에서 mismatch를 감지하면 Next.js는 부드러운 클라이언트 사이드 내비게이션을 포기하고 전체 페이지를 새로 받아오는 hard navigation으로 전환한다. 자산 버전이 꼬인 상태를 억지로 유지하는 대신 새 배포 기준으로 깔끔하게 리셋하는 전략이다.
핵심 시사점은 이렇다. buildId와 deploymentId는 역할이 다르다. 전자는 '같은 빌드 산출물을 식별'하는 문제, 후자는 '클라이언트가 배포 전환을 인식하고 복구'하는 문제를 각각 담당한다. 두 값을 next.config.mjs에 함께 설정하되, DEPLOYMENT_VERSION은 GITHUB_SHA-GITHUB_RUN_ATTEMPT처럼 재시도 횟수까지 포함해야 재배포 시나리오를 커버할 수 있다. 프론트엔드 무중단 배포는 서버 헬스체크만의 문제가 아니라 정적 자산의 버전 일관성 관리라는 레이어를 반드시 포함해야 한다.
과제 2. AI 에이전트가 부활시킨 'UI:R → UI:N' 취약점 재분류
2026년 3월 Patch Tuesday에서 CVE-2026-26144가 공개됐다. 대상은 Microsoft Excel, 유형은 저장형 XSS. 언뜻 2000년대 유물처럼 들린다. 그런데 NIST는 CVSS 4.7 Medium, 마이크로소프트는 7.5 High로 서로 다른 점수를 매겼다. 차이의 원인은 벡터 한 글자—UI:R(사용자 상호작용 필요) 대 UI:N(불필요). 브런치의 분석 글은 이 간극이 단순한 평가 방식의 차이가 아니라 AI 에이전트가 존재하는 세계와 그렇지 않은 세계의 차이라고 정확하게 짚는다.
Microsoft 365 Copilot이 조직 전체에 배포된 환경에서는 사용자가 파일을 열기 전에도 에이전트가 SharePoint, OneDrive, Teams 첨부를 자동 인덱싱한다. "오늘 보고서 요약해줘"라는 일상적 프롬프트 하나가 악성 워크북을 Copilot 파이프라인에 올려놓는다. Simon Willison이 명명한 'lethal trifecta'—민감 데이터 접근, 신뢰할 수 없는 콘텐츠 처리, 외부 네트워크 통신—가 단일 에이전트 세션 안에서 동시에 성립하는 순간, 이전에는 사용자 클릭이 필요했던 공격이 zero-click exfiltration으로 등급이 바뀐다.
프론트엔드 개발자 관점에서 이 이슈는 '백엔드 보안 팀의 문제'로 위임하기 어렵다. Cursor, Claude Code, Copilot처럼 우리가 매일 쓰는 도구들이 lethal trifecta의 세 다리를 얼마나 디디고 있는지 직접 점검해야 한다. Google DeepMind의 CaMeL 논문이 제안하는 방향—"AI 문제를 더 많은 AI로 풀지 말고, 비밀값이 egress 채널에 도달하지 못하도록 데이터 흐름을 구조적으로 분리하라"—은 에이전트를 설계하거나 도입하는 프론트엔드 개발자에게도 동일하게 적용되는 원칙이다. XSS는 죽지 않았다. AI 에이전트라는 증폭기를 달고 돌아왔을 뿐이다.
과제 3. AI 컨텍스트 단절이 만드는 조용한 생산성 손실
Claude Code에서 Cursor로 갈아탈 때마다, 새 세션을 열 때마다 AI는 프로젝트를 처음 만난다. 아키텍처 결정도, 왜 JWT를 선택했는지도, 인증 미들웨어 어디까지 구현했는지도 모른다. dev.to에 공유된 mindswap 제작기는 이 반복되는 20분 재설명 비용에 지쳐 만든 도구의 이야기다. 사소해 보이지만 하루에 두세 번 맥락을 전환하는 실제 워크플로우에서는 이 마찰이 생산성의 상당 부분을 조용히 잠식한다.
mindswap의 접근이 흥미로운 건 수동 문서화를 요구하지 않는다는 점이다. npx mindswap을 실행하면 브랜치 이름에서 현재 태스크를 추론하고(feat/user-auth → "user auth 작업 중"), git diff와 최근 커밋에서 변경 맥락을 캡처하며, 의존성 변화까지 자동으로 기록한다. 생성된 컨텍스트 파일은 CLAUDE.md, .cursor/rules, AGENTS.md 등 15개 AI 도구 포맷으로 동시에 출력된다. MCP 서버 모드에서는 세션 시작 시 mindswap_get_context, 세션 종료 시 mindswap_save_context를 통해 결정 사항이 다음 세션으로 자동 인계된다.
'decision conflict detection' 기능—"Redis 안 쓰기로 했다"고 기록해뒀는데 나중에 "Redis 사용"이 등장하면 경고를 띄우는—은 사소해 보이지만 실제 프로젝트에서 맥락이 쌓일수록 일관성 관리가 얼마나 어려운지를 건드린다. 브랜치별 독립 상태 관리와 시크릿 스캔 기능까지 갖췄다. 아직 초기 도구라 거친 면이 있겠지만, '컨텍스트를 어떻게 이식할 것인가'라는 질문 자체는 AI 워크플로우의 구조적 문제를 정확히 겨냥하고 있다.
세 과제가 가리키는 공통 방향
세 이슈는 표면적으로 다른 도메인처럼 보이지만 같은 방향을 가리킨다. 배포 버전 충돌 문제는 "도구가 알아서 처리해줄 것"이라는 가정을 검증 없이 믿었을 때 터진다. AI 에이전트 보안 문제는 "새 도구를 도입했을 때 공격면이 어떻게 재편되는지"를 적극적으로 추적하지 않으면 뒤늦게 CVE 번호로 확인하게 된다. 컨텍스트 단절 문제는 워크플로우의 마찰을 당연한 것으로 받아들이다 보면 결국 생산성 손실이 구조화된다.
AI가 코드 생성 속도를 끌어올린 만큼, 그 속도가 만들어내는 새로운 취약 지점을 직접 설계하고 관리하는 역량이 프론트엔드 개발자에게 요구되는 시대가 됐다. 빠른 실험과 배포가 가능해질수록 배포 전략의 엄밀함, 에이전트 도입 시의 보안 감사, 그리고 AI 워크플로우 자체의 DX 설계가 오히려 더 중요해진다. 도구를 쓰는 속도보다 도구가 만드는 구조를 이해하는 깊이가 지금 프론트엔드 개발자의 실질적 경쟁력이다.