'AI가 코드를 짤 수 있는가'라는 질문은 이미 끝났다. 지금 개발자들이 실제로 묻는 건 다른 것이다. AI가 만든 코드, 프로덕션에서 얼마나 버티는가. 2026년 7월, 두 가지 흐름이 동시에 이 질문을 정면으로 건드리고 있다. 하나는 GitHub에서 하루 만에 1,486개의 스타를 끌어모은 Hallmark의 폭발적 성장이고, 다른 하나는 Next.js 15.5~16.3 사이에서 문서화된 세 개의 메모리 누수다. 두 사건은 서로 다른 레이어에서 발생했지만, 가리키는 방향은 하나다.
AI 생성 UI의 문제: 작동은 하는데 왜 이상하게 보이는가
Hallmark는 Claude Code, Cursor, Codex 같은 코딩 에이전트가 만들어내는 프론트엔드 결과물의 품질을 통제하는 도구다. Together AI의 Hassan El Mghari가 만들었고, 한 줄 명령어(npx skills add nutlope/hallmark)로 설치된다. 컴포넌트 라이브러리가 아니라 에이전트의 행동 자체를 제약하는 명세 파일—SKILL.md—이라는 점이 핵심이다.
이 도구가 8주 만에 12,200개의 스타를 받은 이유는 새로운 기능 때문이 아니다. AI가 만든 UI에서 반복적으로 나타나는 패턴, 즉 '슬롭(slop)'을 개발자들이 18개월째 수작업으로 고쳐왔기 때문이다. Hallmark는 그 패턴을 57개의 결정론적 게이트로 명문화했다. 모든 게이트는 이진 판정이다—통과 아니면 재생성.
어떤 것들이 걸리는가. 모든 heading이 동일한 weight를 쓰면 탈락이다. blue-500을 무차별적으로 쓰면 색상 앵커 드리프트 게이트에서 막힌다. 카드 높이, border-radius, 패딩이 모두 동일하면 variety 게이트가 재생성을 요구한다. ease-in-out을 모든 모션에 걸면 슬롭 판정이 난다. 심지어 "10,000+ 행복한 고객" 같은 근거 없는 지표도 게이트 하나를 전담으로 잡아낸다. 이것들은 AI가 만든 UI를 AI처럼 보이게 만드는 '신호'들이며, Hallmark는 그 신호를 배포 전에 차단한다.
프레임워크 레이어의 문제: 코드가 잘 보여도 서버는 죽는다
UI 품질이 통제되더라도 프로덕션 안정성은 다른 레이어에서 무너질 수 있다. xabierlameiro.com에서 공개된 Next.js 메모리 누수 진단 포스트는 그 레이어를 정면으로 다룬다. 핵심은 불편한 사실 하나다—2026년 7월 현재, Next.js 프레임워크 자체에 세 개의 미해결 메모리 누수가 존재한다.
첫 번째는 라우터 LRU 캐시 문제다(이슈 #94890). 캐시의 size 함수가 URL 키는 계산하지 않고 값 문자열만 더해, ~1M개의 키를 보유하면서도 자신이 작다고 믿는 구조적 결함이다. 트래픽이 아니라 유니크 URL 수와 힙이 비례해서 증가한다면 이 누수를 의심해야 한다. 두 번째는 RSC 렌더 트리 보존 문제다(이슈 #94919). 모바일 클라이언트, 크롤러, 페이지를 빠르게 이탈하는 사용자처럼 스트림이 정상적으로 완료되지 않으면, Flight 요청의 AbortController가 전체 엘리먼트 트리를 붙잡아 둔다. 무거운 페이지에서 요청당 ~2MB씩 누적된다. Node 22/24 환경에서 특히 심각하다. 세 번째는 미들웨어의 setTimeout 이슈다(이슈 #95094). 샌드박스의 TimeoutsManager가 명시적 clearTimeout 호출이 없으면 ID를 해제하지 않는다. 한 줄짜리 워크어라운드가 이미 알려져 있다—타임아웃 콜백 내에서 자기 자신을 clearTimeout으로 해제하는 방식이다.
서버리스 환경은 OOM 대신 504로 증상이 바뀌기 때문에 더 까다롭다. 같은 포스트에서 소개된 사례는 태그 페이지의 O(N²) 포스트 로더가 ~32초짜리 렌더를 만들어냈고, 인스턴스 재활용이 문제를 계속 숨겨왔다는 것이다. 메모리 누수가 아니라 렌더 비용 문제였지만, 증상은 동일하게 타임아웃이었다. NODE_OPTIONS='--inspect' next start로 힙 스냅샷을 두 번 찍고, Chrome DevTools의 Memory 탭에서 retainer를 비교하는 것이 진단의 시작점이다.
두 흐름이 가리키는 하나의 설계 원칙
Hallmark와 Next.js 메모리 누수는 스택의 다른 레이어에 있지만 같은 문제를 드러낸다. AI가 빠르게 생성한 코드는 프로덕션에서 자동으로 안전하지 않다. UI 레이어에서는 에이전트가 슬롭 패턴을 무의식적으로 복제하고, 인프라 레이어에서는 프레임워크 자체의 미해결 버그가 조용히 힙을 채운다. 속도는 AI가 가져왔지만, 신뢰는 구조가 가져와야 한다.
Hallmark의 57개 게이트가 흥미로운 이유는 '검증'을 사후 단계가 아니라 생성 루프 안에 내장했다는 점이다. 슬롭 테스트를 통과하지 못한 출력은 사용자에게 도달하기 전에 재생성된다. 배포 전 감사(hallmark audit src/)는 기존 코드베이스에도 소급 적용할 수 있다. 이것은 QA를 린트처럼 다루는 접근이고, 그 접근이 12K 스타로 표현된 것이다.
반면 Next.js의 메모리 누수는 반대 교훈을 준다. 프레임워크를 신뢰하더라도 프로덕션 환경에서는 힙 모니터링과 주기적 스냅샷 비교를 운영 루틴으로 가져가야 한다. RSC 페이로드 크기를 줄이고, 미들웨어의 비동기 작업을 명시적으로 정리하는 습관은 AI 생성 여부와 무관하게 필요한 방어 설계다.
앞으로의 방향: 스킬 레이어가 품질 레이어가 된다
Hallmark의 성장 곡선이 obra/superpowers(252K 스타), mattpocock/skills(165K 스타)와 같은 에이전트 스킬 생태계의 폭발과 맞닿아 있다는 사실은 의미심장하다. AI 코딩의 가치는 모델 성능에서 그 위에 얹히는 스킬·툴링 레이어로 이동하고 있다. 모델은 계속 좋아지겠지만, 그 출력을 프로덕션 기준으로 제어하는 레이어를 누가 어떻게 설계하느냐가 실질적 품질을 결정하게 된다.
AI가 빠르게 쌓은 코드가 프로덕션에서 버티려면, 생성 속도만큼 검증 구조에 투자해야 한다. 게이트는 57개여도 좋고, 힙 스냅샷 루틴 하나여도 좋다. 중요한 건 그 구조가 에이전트 워크플로우 안에 미리 설계되어 있는지 여부다. 배포 후에 발견하는 비용은, 언제나 설계 단계에서 막는 비용보다 크다.