AI 도구로 프로토타입을 빠르게 뽑아낼 때, 가장 먼저 무너지는 곳은 눈에 잘 보이지 않는 경계다. 화면이 그럴싸하게 동작하고 기능 흐름도 맞아 떨어지는데, 정작 인증 토큰이 XSS에 노출되거나 오프라인 환경에서 앱이 통째로 죽어버리는 사례가 반복된다. Velog에 올라온 쿠키 경계 분석과 dev.to의 스누커 스코어링 PWA 사례는 서로 다른 문제를 다루는 것 같지만, 결국 같은 질문을 가리킨다. 프로덕션 수준의 신뢰성은 어디에 먼저 설계되어야 하는가?
첫 번째 경계: 쿠키는 '그냥 문자열'이 아니다
document.cookie는 오래됐고 쉬워 보인다. 그래서 AI가 생성한 코드에도 아무 경고 없이 등장한다. 문제는 쿠키가 실제로는 세 가지 다른 레이어—브라우저 JavaScript, 서버 요청 생명주기, 그리고 Next.js App Router의 컴포넌트 경계—에 걸쳐 동작한다는 점이다. 이 레이어를 구분하지 않으면 'AI가 짜준 인증 코드'가 프로덕션에서 조용히 보안 구멍이 된다.
Velog의 쿠키 경계 분석이 핵심적으로 짚는 건 화면 편의 상태와 보안 상태의 분리다. theme=dark나 필터 값 같은 UI 편의 데이터는 클라이언트에서 Cookie Store API로 다뤄도 무방하다. 반면 access_token, refresh_token, session_id는 JavaScript가 직접 만지지 않아야 한다. HttpOnly 속성 하나로 XSS 공격이 토큰을 가져가는 경로 자체를 차단할 수 있기 때문이다.
Cookie Store API는 이 맥락에서 document.cookie의 문자열 파싱 번거로움을 해소하는 실용적 대안이다. cookieStore.get("name")처럼 비동기로 읽고 쓸 수 있고, Service Worker에서도 일부 쿠키 흐름을 다룰 수 있다. 다만 브라우저 지원이 완전하지 않으므로, "cookieStore" in window 분기로 fallback을 반드시 열어둬야 한다.
Next.js App Router에서는 이 경계가 컴포넌트 단위로 명확해진다. Server Component는 await cookies()로 요청 시점의 쿠키를 읽는 데 적합하고, Route Handler와 Server Action은 Set-Cookie 응답 헤더를 통해 쿠키를 쓰는 역할을 맡는다. AI가 생성한 코드가 이 두 역할을 뒤섞어 Client Component에서 인증 쿠키를 직접 다루도록 만들었다면, 그 코드는 기능은 되지만 안전하지 않다.
실무에서 자주 나타나는 증상은 '로그인 후 간헐적으로 인증이 풀리는 문제'다. 이 케이스의 원인 후보는 여러 개지만—Secure 속성 누락, 프록시의 x-forwarded-proto 오인, SameSite 설정 충돌—공통 디버깅 출발점은 하나다. 로그인 응답의 Set-Cookie 헤더와 다음 요청의 Cookie 헤더를 Network 탭에서 나란히 비교하는 것. 이 두 줄이 연결되지 않으면 React 라우팅이나 서버 컴포넌트 캐시를 아무리 뒤져도 원인을 찾기 어렵다.
두 번째 경계: PWA의 오프라인 설계는 나중이 아니다
dev.to에 공개된 SnookerBee 프로젝트는 흥미로운 출발점을 가지고 있다. 당구장 스코어보드가 두 명만 지원해서 직접 만들었다는 것. React 19, TypeScript, Vite, Supabase, Google OAuth를 엮은 이 PWA는 단순한 사이드 프로젝트가 아니라, 실제 사용 환경의 제약—슬롯 수 제한, 불안정한 Wi-Fi, 앱스토어 설치 없이 바로 쓰고 싶은 욕구—을 정확히 분석한 뒤 설계된 결과물이다.
이 프로젝트에서 가장 주목할 선택은 오프라인 우선 설계를 처음부터 핵심 기능으로 놓은 것이다. vite-plugin-pwa와 Workbox를 조합해 최초 로드 이후 인터넷 없이도 앱이 완전히 작동하게 만들었다. 당구 게임 중 Wi-Fi가 끊기는 순간 스코어 앱이 죽으면 그 앱은 존재할 이유가 없다. 오프라인 대응은 '나중에 추가할 기능'이 아니라 이 앱의 존재 이유 자체였다.
사운드 처리 방식도 같은 원칙의 연장이다. 외부 사운드 라이브러리 대신 Web Audio API를 직접 써서 오실레이터와 엔벨로프로 효과음을 합성했다. 100줄 이하의 코드로 팟 확인음, 파울 경고음, 브레이크 마일스톤 알림, 승리 팡파르를 모두 구현했고, 번들에 아무것도 추가하지 않았다. 오프라인에서도 완벽히 동작한다. 의존성을 줄이는 것이 곧 신뢰성을 높이는 선택이었다.
게임 로직의 상태 관리도 인상적이다. useState를 흩뿌리는 대신 순수 state-machine reducer로 설계했다. 레드-컬러 시퀀스 강제, 프리볼 지명, 타이 스코어 시 블랙볼 재설치, 10단계 딥클론 undo 스택—스누커의 복잡한 규칙 엣지케이스를 이 구조 덕분에 일관되게 다룰 수 있었다고 저자는 밝힌다. AI가 생성한 useState 스파게티로는 undo 하나만 넣어도 버그가 쏟아졌을 영역이다.
두 경계가 가리키는 하나의 교훈
두 사례는 표면적으로 다른 문제를 다룬다. 하나는 인증 쿠키 보안이고, 다른 하나는 오프라인 스코어링 앱이다. 하지만 둘이 공통으로 강조하는 것은 명확하다. AI가 빠르게 뽑아준 코드가 작동하는 것처럼 보일 때, 가장 먼저 무너지는 건 '경계'다. 쿠키 레이어 간의 경계, 온라인과 오프라인의 경계, 상태 변이의 경계.
프로토타이핑 속도를 높이는 것과 프로덕션 신뢰성을 확보하는 것은 모순처럼 보이지만 실제로는 순서의 문제다. 쿠키는 HttpOnly/SameSite 정책과 Next.js 컴포넌트 경계를 설계 초기에 잡아야 한다. PWA는 오프라인 전략과 상태 머신 기반 로직을 처음부터 구조에 심어야 한다. 이 두 경계를 먼저 잠가두면, AI 도구가 빠르게 채워넣는 나머지 코드가 프로덕션에서도 버텨낼 기반이 생긴다.
전망은 분명하다. AI 코드 생성 속도가 빨라질수록, 설계자가 먼저 '어디를 잠글지'를 결정하는 역할은 더 중요해진다. 코드를 짜는 속도가 문제가 아니라, 무엇을 먼저 구조화할지 판단하는 능력이 프론트엔드 개발자의 핵심 역량으로 올라서고 있다.