프론트엔드 개발자에게 2025~2026년은 '경계'를 다시 그리는 시기다. 어디까지가 프론트엔드의 책임인지, 빌드 도구와 언어 런타임이 어떻게 바뀌는지, 백엔드 없이 얼마나 멀리 갈 수 있는지—이 세 가지 질문이 동시에 실무 현장에서 터지고 있다. 최근 dev.to에 올라온 세 편의 실전 사례를 함께 읽으면, 각각의 기술 팁을 넘어 하나의 큰 흐름이 보인다.
국제화: '쿠키 기반 언어 전환'이라는 조용한 SEO 함정
Next.js App Router로 영어·아랍어 이중 언어 사이트를 구축한 사례(dev.to)는 단순한 i18n 튜토리얼이 아니다. 핵심은 언어 전환을 쿠키가 아닌 URL로 설계해야 한다는 것—그리고 그 이유가 SEO와 직결된다는 점이다.
Googlebot은 쿠키를 저장하지 않는다. 미국 IP에서 Accept-Language 헤더도 거의 고정된 채로 크롤링한다. 쿠키 기반 언어 전환기를 쓰면 크롤러는 항상 기본 언어(영어)만 인덱싱하고, 아랍어 페이지는 검색 엔진에 존재하지 않는 것이나 마찬가지가 된다. hreflang 설정 역시 URL이 없으면 무의미하다.
해법은 app/[locale]/ 동적 세그먼트로 /en/...과 /ar/... 두 URL 트리를 명확히 분리하는 것이다. <html lang={locale} dir={locale === 'ar' ? 'rtl' : 'ltr'}> 한 줄로 RTL 레이아웃 전환이 시작되고, 여기에 CSS 논리 속성(ms-4, pe-6, text-start)을 쓰면 물리적 좌우 방향을 전혀 건드리지 않아도 레이아웃이 자동으로 뒤집힌다. Tailwind의 논리 유틸리티 클래스 치환은 기계적이고 검증 가능하다. next/font로 영문 폰트와 아랍어 폰트를 로케일별로 분리 로딩하면, 영어 사용자에게 아랍어 폰트가 내려가는 낭비도 사라진다.
이 설계가 주는 진짜 교훈은 '사용자 경험처럼 보이는 구현'과 '크롤러가 실제로 보는 것' 사이의 간극이다. 쿠키 전환기는 브라우저에서는 멀쩡해 보이지만, 검색 엔진과 링크 공유 맥락에서는 절반짜리 사이트로 작동한다. 프론트엔드 개발자가 SEO를 자신의 책임 범위로 명확히 인식해야 하는 이유다.
TypeScript 7: 10배 빠른 컴파일러가 가져온 마이그레이션 리스크
TypeScript 7.0이 7월 8일 GA를 선언했다. Go로 재작성된 네이티브 컴파일러 tsgo는 기존 대비 약 10배 빠르다—빌드 속도가 드라마틱하게 개선된다는 건 DX 측면에서 분명히 매력적이다. 그런데 ^7로 버전을 올리는 순간, 두 가지 지뢰가 기다리고 있다.
첫째, Compiler API가 7.0에서 제거됐다(7.1에서 복원 예정). import * as ts from "typescript"를 사용하는 도구들—vue-tsc, typescript-eslint, ts-jest, ts-morph, typedoc 등—이 즉시 깨진다. 로컬에서는 초록불이었다가 CI에서 createProgram is not a function 에러로 죽는 최악의 패턴이다. 둘째, baseUrl, target: "es5", esModuleInterop: false 같은 레거시 tsconfig 옵션들이 하드 에러로 처리된다. strict도 이제 기본값이 true다.
dev.to에 소개된 ts7-compat-guard는 이 상황을 위한 실용적인 해법이다. 소스 코드를 파싱하지 않고 package.json과 tsconfig.json만 읽어서 충돌 항목과 어드바이저리(동작 변경이지만 확정 파손은 아닌 것)를 분리해 보고한다. npx ts7-compat-guard --recursive로 모노레포 전체를 스캔하거나, GitHub Actions에 게이트로 걸어 CI 단계에서 미리 잡을 수 있다.
이 도구의 설계 철학이 흥미롭다. '확실히 깨지는 것'과 '깨질 수도 있는 것'을 명확히 분리하고, 후자는 빌드를 실패시키지 않는다. 빠른 도구가 주는 속도의 유혹과, 생태계 호환성이 따라잡기까지의 현실적 시차—이 간극을 관리하는 것이 지금 TypeScript 7 전환의 핵심이다. 7.1이 나오고 주요 도구들이 peer range를 넓히는 시점까지는, 섣불리 올리기보다 이런 사전 점검 도구로 리스크를 가시화하는 것이 합리적이다.
백엔드 없는 Chrome 확장: 제약이 설계를 단순하게 만드는 방식
세 번째 사례는 가장 실험적이면서도 설계 사고 측면에서 가장 많은 걸 보여준다. MindStack은 chrome.storage.sync 하나로 캡처, 간격 반복 학습(Spaced Repetition), 대시보드, 크로스 디바이스 동기화를 모두 구현한 Chrome 확장이다. 백엔드 없음, 번들러 없음, npm install 없음—unpacked 상태로 바로 로드할 수 있다.
핵심 설계 결정들이 흥미롭다. SM-2 알고리즘의 교과서적 구현 대신, 그 핵심 두 가지—응답 품질에 따라 인터벌이 곱셈으로 성장한다, ease factor는 1.3 하한으로 클램핑된다—만 추출한 압축 버전을 썼다. 이전 인터벌을 저장하는 대신 reviewCount를 프록시로 활용해 저장해야 할 필드 수를 줄였다. 어휘 암기 도구가 아니라 '내가 이 아티클을 실제로 기억하고 있나'를 체크하는 도구라면, 이 근사치로 충분하다는 판단이다.
chrome.storage.sync의 100KB 총 쿼터, 항목당 8KB 제한이라는 물리적 제약은 단일 JSON 블롭 + 매 읽기마다 DEFAULT_DATA를 스프레드하는 패턴을 낳았다. 스키마 마이그레이션 코드가 필요 없고, 새 설정 필드가 기존 사용자에게 자동으로 적용된다. 쓰기 효율은 떨어지지만, 수백 개 카드 규모의 개인 도구에서 그 트레이드오프는 올바른 방향이다.
chrome.identity.getProfileUserInfo로 Google 계정을 확인하는 것도 보안 게이트가 아니라 UX 가드레일로 솔직하게 설계했다—백엔드가 없으니 진짜 인증은 있을 수 없고, chrome.storage.sync가 이미 Chrome 프로필에 키잉되어 있으니 그걸 UI 레벨에서 명시적으로 보여주는 것이다. 토스트 알림이 페이지 로드 1800ms 후에 뜨도록 딜레이를 준 것도—레이아웃 시프트와 경쟁하지 않고, 탭을 빠르게 훑는 사람을 귀찮게 하지 않으려는—작지만 사려 깊은 UX 판단이다.
세 사례가 그리는 하나의 방향
이 세 사례를 나란히 놓으면 공통 패턴이 보인다. 필요한 만큼만 정확하게, 그 이상은 복잡도만 늘린다. URL 기반 국제화는 쿠키보다 단순하게 동작하면서 SEO까지 챙긴다. ts7-compat-guard는 소스를 파싱하지 않음으로써 오탐을 없앤다. MindStack은 SM-2의 수학을 90% 버리고 핵심 두 가지만 살렸다.
프론트엔드의 경계가 넓어지고 있다—국제화 SEO, 빌드 도구 호환성 관리, 서버리스 아키텍처 설계까지. 이 경계 확장이 부담이 아니라 가능성으로 느껴지려면, 각 영역에서 '충분한 단순함'을 찾아내는 판단력이 먼저다. 도구가 아무리 발전해도 그 판단은 여전히 개발자의 몫이다.