leedc0101/01-a11y-dialog-ko.md

Created March 9, 2026 01:30

Star (0) You must be signed in to star a gist
Fork (0) You must be signed in to fork a gist

Select an option

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/leedc0101/b2e8d9fc183d0ab00875128f353fa6a4.js"></script>
Save leedc0101/b2e8d9fc183d0ab00875128f353fa6a4 to your computer and use it in GitHub Desktop.

frontend-briefing-2026-03-09-KST

Raw

원문 제목: React: Singletons aren't as evil as you think 원문 링크: https://dev.to/link2twenty/react-singletons-arent-as-evil-as-you-think-44m8 번역일: 2026-03-09 KST

React에서 싱글턴은 생각보다 그렇게 나쁘지 않다

React 세계에서 싱글턴은 종종 “추적하기 어렵고 테스트하기 힘든 전역 상태의 지름길”로 취급된다. 하지만 작성자의 요지는 단순하다. 싱글턴 자체가 문제라기보다, React와 연결하는 방식이 낡았던 것이 문제였다는 것이다.

과거의 안 좋은 패턴

예전에는 싱글턴 값이 바뀌어도 React 컴포넌트가 그 사실을 몰랐다. 그래서 수동 새로고침 버튼을 두거나, setInterval로 폴링하며 싱글턴의 현재 값을 state로 복사하는 식으로 동기화했다.

이 방식은 반응형도 아니고, 지연이 생기며, 코드도 지저분해진다.

이벤트 기반으로 바꾸면 훨씬 낫다

싱글턴이 값 변경 시 이벤트를 발행하도록 만들면 React 컴포넌트는 그 이벤트를 구독해 바로 state를 갱신할 수 있다. 예를 들어 싱글턴 내부에서 EventTarget 또는 유사한 이벤트 시스템을 사용해 change 이벤트를 내보내고, 컴포넌트는 useEffect에서 구독한 뒤 해제하면 된다.

이렇게 하면 폴링도, 수동 동기화 버튼도 필요 없다. React state처럼 꽤 자연스럽게 동작한다.

클래스 기반 싱글턴의 장점

작성자는 싱글턴을 구현할 때 JavaScript 클래스의 단순함을 강조한다. 외부 상태 관리 라이브러리를 추가하지 않아도 되고, 앱 전역에서 하나의 인스턴스를 공유하기 쉽다. 작은 규모의 cross-cutting concern을 처리할 때는 오히려 더 가볍고 명시적일 수 있다.

대표적인 예시는 다음과 같다.

네트워크 연결 상태
전역 토스트/알림 허브
feature flag 캐시
사용자 세션 메타데이터
앱 전체에서 하나만 존재해야 하는 서비스 객체

이런 경우 “상태 저장소”보다 “공유 서비스”로 보는 편이 더 자연스럽다.

`useSyncExternalStore`가 판을 바꿨다

이 글의 핵심은 최신 React가 외부 저장소를 더 공식적으로 다룰 수 있게 해 준다는 점이다. useSyncExternalStore를 사용하면 싱글턴을 React의 렌더링 모델에 안전하게 연결할 수 있다.

싱글턴은 최소한 다음 두 가지를 제공하면 된다.

현재 스냅샷을 읽는 함수
변경 사항을 구독하는 함수

그러면 컴포넌트는 React가 보장하는 방식으로 최신 스냅샷을 읽고, 변경 시 일관되게 리렌더링할 수 있다. 즉, 싱글턴을 “대충 전역 변수처럼 쓰는 것”과 “React 친화적인 외부 스토어로 쓰는 것”은 전혀 다른 이야기다.

간단한 구조 예시

작성자가 제안하는 형태는 대략 이런 흐름이다.

싱글턴 클래스가 내부 데이터를 가진다.
setData() 같은 메서드가 값을 변경한다.
값이 바뀌면 등록된 리스너들에게 알린다.
React 훅이 useSyncExternalStore로 구독한다.
컴포넌트는 평범한 state처럼 값을 읽는다.

이 패턴을 쓰면 전역 상태 라이브러리 수준의 과한 추상화 없이도 충분히 실용적인 결과를 얻을 수 있다.

테스트는 정말 어려운가?

싱글턴에 대한 가장 흔한 반론은 테스트다. 상태가 전역으로 살아남기 때문에 테스트 간 오염이 생길 수 있다는 것이다. 이 문제는 실제로 존재한다. 하지만 작성자는 이것이 “싱글턴이라서 본질적으로 테스트 불가능하다”는 뜻은 아니라고 말한다.

해결책은 꽤 현실적이다.

테스트마다 싱글턴 초기화 메서드를 제공한다.
테스트 setup에서 상태를 리셋한다.
필요한 경우 의존성 주입 지점을 둔다.
순수 계산 로직은 싱글턴 밖으로 분리한다.

즉, 테스트 난이도는 관리 이슈이지, 금지 사유는 아니다.

언제 쓰면 좋은가

작성자는 싱글턴이 다음과 같은 상황에 적합하다고 본다.

앱 전체에서 진짜로 인스턴스가 하나여야 할 때
상태보다 서비스 성격이 강할 때
도입 비용을 최소화하고 싶을 때
Redux/Zustand/Jotai 같은 큰 도구가 과하다고 느껴질 때

반대로 복잡한 도메인 상태, 시점별 이력 관리, 서버 캐시, 많은 파생 상태가 얽힌 문제라면 전용 상태 관리 도구가 더 적합할 수 있다.

결론

싱글턴은 React에서 무조건 피해야 할 금기 패턴이 아니다. 중요한 것은 “전역 하나를 그냥 가져다 쓰는가”가 아니라, 변경 구독과 스냅샷 읽기를 포함한 React 친화적 인터페이스로 감쌌는가다. 작고 명확한 전역 서비스에는 여전히 꽤 실용적인 선택지다.

Raw

03-server-side-mocking-gap-ko.md

원문 제목: The Server-Side Mocking Gap Nobody Talks About 원문 링크: https://dev.to/rrafatpanah/the-server-side-mocking-gap-nobody-talks-about-36jb 번역일: 2026-03-09 KST

아무도 잘 말하지 않는 서버 사이드 모킹 공백

SPA가 중심이던 시절에는 E2E 테스트가 지금보다 단순했다. 앱이 브라우저 안에 있었고, API 요청도 대부분 브라우저에서 시작했기 때문에 Cypress 같은 도구가 네트워크를 가로채고 모킹할 수 있었다.

하지만 Next.js, Remix, TanStack Start 같은 최신 풀스택 프레임워크에서는 상황이 달라졌다. loader, action, server component, server function이 서버에서 실행되기 때문이다. 이 요청들은 브라우저 밖에서 발생하므로, 기존 E2E 도구의 네트워크 인터셉트만으로는 커버되지 않는다. 이 지점이 작성자가 말하는 “서버 사이드 모킹 갭”이다.

작성자는 Anedot에서 9개월 동안 실무에 적용한 접근을 소개한다.

좋은 해결책의 조건

이 문제를 푸는 방법은 단순히 “응답을 가짜로 만든다” 수준이 아니어야 한다. 글에서 제시한 목표는 다음과 같다.

앱의 경계만 모킹한다. 브라우저와 서버는 실제로 동작시키고, 외부 서드파티 API만 모킹한다.
각 테스트가 자기 모킹을 직접 소유한다. 테스트마다 필요한 엔드포인트와 응답을 명시하고, 테스트 간 공유 상태가 없어야 한다.
모킹 데이터는 타입 체크되어야 한다. 실제 API 스키마와 어긋나는 가짜 응답이 테스트를 통과시키면 안 된다.
실제 외부 요청이 새면 안 된다. 스테이징을 포함해 어떤 환경에서도 진짜 서드파티 호출이 나가면 안 된다.
요청 자체를 검증할 수 있어야 한다. 바디와 헤더가 올바르게 나갔는지 assert 가능해야 한다.
병렬 실행이 안전해야 한다. 여러 테스트가 동시에 돌아도 서로의 모킹이 섞이면 안 된다.

데모 앱 구성

작성자는 TanStack Start + Playwright + MSW 조합으로 데모 앱을 만들었다. 앱은 두 가지 서버 함수만 가진 단순한 예시다.

서버 함수 fetchPosts: 외부 API에서 게시글 목록 로드
서버 함수 createPost: 폼 제출로 외부 API에 POST 요청

핵심은 이 요청들이 브라우저가 아니라 앱 서버에서 실행된다는 점이다.

브라우저 모킹만으로는 왜 부족한가

Playwright나 Cypress의 route interception은 주로 브라우저에서 발생한 요청을 대상으로 한다. 하지만 loader나 server function이 Node 런타임에서 fetch()를 호출하면 E2E 도구의 인터셉트 범위 밖으로 나간다. 결과적으로 테스트는 다음 둘 중 하나가 되기 쉽다.

실제 외부 API에 의존하는 느리고 불안정한 테스트
브라우저 계층만 가짜로 만들고 서버 계층은 사실상 무방비인 테스트

작성자는 이 상태를 피하려고 앱 서버 자체에서 네트워크를 모킹한다.

접근 방식: 서버 안에 MSW를 심는다

핵심 아이디어는 테스트가 시작될 때 앱 서버 내부에 MSW 기반 mock server를 띄우고, 서버에서 외부로 나가는 요청을 그곳에서 가로채는 것이다. 이렇게 하면 브라우저와 앱 서버는 실제로 동작하고, 외부 서비스 경계만 통제할 수 있다.

여기에 더해 각 테스트 케이스는 자신만의 mock 핸들러를 서버에 등록한다. 즉, “이 테스트에서는 /posts가 이런 응답을 반환한다”를 테스트가 직접 선언한다.

테스트별 모킹을 어떻게 분리하나

가장 중요한 실무 포인트는 병렬성이다. 여러 테스트가 동시에 실행될 때 공용 전역 mock 상태를 쓰면 서로 꼬인다.

작성자는 테스트마다 고유 식별자를 발급하고, 브라우저 요청 헤더나 컨텍스트를 통해 이 식별자를 앱 서버로 전달한다. 앱 서버는 그 식별자를 기준으로 해당 테스트에만 적용되는 mock 집합을 조회한다. 그러면 test A가 등록한 응답은 test A의 서버 요청에만 적용되고, test B와 섞이지 않는다.

이 구조는 병렬 실행에서 특히 강력하다.

요청 검증까지 포함한다

글의 포인트는 “응답을 돌려준다”에서 끝나지 않는다. 외부 API로 나가려던 요청의 헤더, 메서드, 바디가 기대한 대로였는지도 검증한다. 예를 들어 createPost 테스트에서는 실제로 POST가 나갔는지, JSON 본문 구조가 맞는지, 필요한 인증 헤더가 포함됐는지 확인할 수 있다.

이런 검증이 없으면 UI만 얼핏 통과하고 실제 통합 계약은 깨져 있을 수 있다.

타입 안전한 모킹

작성자는 OpenAPI 같은 스키마 기반 타입 생성과 함께 모킹 데이터를 타입 체크하는 방식을 권장한다. 이유는 단순하다. 테스트가 사용하는 가짜 응답이 실제 운영 응답과 구조가 다르면, 테스트는 안정감을 주는 대신 거짓 확신만 준다.

즉, 모킹은 빠르기만 하면 되는 것이 아니라 계약을 보존해야 한다.

실무적 장점

이 방식의 장점은 다음과 같다.

브라우저부터 서버까지 앱 내부를 진짜처럼 실행한다.
외부 의존성만 안정적으로 차단한다.
테스트 간 독립성이 높다.
병렬 실행에 강하다.
요청/응답 계약을 모두 검증할 수 있다.

특히 Next.js App Router나 TanStack Start처럼 서버 함수를 적극적으로 쓰는 팀에게 매우 실용적이다.

결론

최신 풀스택 프레임워크 시대의 E2E 테스트는 브라우저 인터셉트만으로 충분하지 않다. 진짜 공백은 서버에서 시작되는 외부 호출에 있고, 이를 메우려면 앱 서버 내부에서 테스트별로 격리된 네트워크 모킹 계층을 가져가야 한다. 이 글은 FE 팀이 서버 경계를 포함한 “실제에 가까운 E2E”로 옮겨갈 때 참고할 만한 좋은 청사진이다.

Raw

04-playwright-nextjs-llm-tests-ko.md

원문 제목: How to End-to-end (E2E) Test AI Agents: Mocking API Responses with Playwright in Next.js 원문 링크: https://dev.to/dumebii/how-to-e2e-test-ai-agents-mocking-api-responses-with-playwright-in-nextjs-nic 번역일: 2026-03-09 KST

Next.js에서 Playwright로 AI 에이전트 E2E 테스트하기

AI 에이전트 제품을 만드는 것은 재미있지만, CI/CD 파이프라인에서 테스트하는 일은 전혀 다르다. 작성자는 Ozigi라는 콘텐츠 관리형 AI 에이전트를 만들며 다음 세 가지 문제에 부딪혔다고 말한다.

비용: 테스트를 돌릴 때마다 OpenAI, Anthropic, Vertex AI 같은 API 크레딧이 소모된다.
속도: LLM 호출은 느리다. 테스트 하나당 10~15초씩 걸리면 배포 파이프라인이 크게 늘어진다.
비결정성: LLM 응답은 완전히 동일한 문자열을 보장하지 않는다. 따라서 정확한 문구 일치를 기대하는 assertion은 쉽게 flaky해진다.

작성자는 그래서 “LLM 백엔드에 실제로 붙지 않고도 프런트엔드의 상태 전환을 E2E로 검증하는 방법”을 택했다.

기본 아이디어: 네트워크 인터셉트로 LLM 응답을 고정한다

Ozigi에서 사용자는 페르소나를 고르고, URL이나 텍스트 컨텍스트를 넣고, “Generate Campaign”을 누른다. 그러면 UI는 로더 상태로 전환되고, 이후 생성된 카드/그리드 결과를 보여 준다.

이 흐름에서 검증하고 싶은 것은 모델 품질이 아니라 UI 상태 변화다. 즉,

버튼 클릭 후 로더가 나타나는가
요청 중 스피너/동적 로더가 보이는가
응답 후 결과 카드가 렌더링되는가
실패 시 에러 상태가 보이는가

이런 부분은 실제 LLM을 호출하지 않아도 충분히 테스트할 수 있다.

Playwright `page.route()` 활용

작성자는 Playwright의 네트워크 인터셉트를 이용해 특정 API 엔드포인트 요청을 가로채고, 미리 준비한 JSON 응답을 반환한다. 예를 들어 /api/generate 같은 내부 엔드포인트에 대해 고정된 campaign payload를 반환하도록 설정하면, 테스트는 빠르고 결정적으로 동작한다.

핵심 패턴은 다음과 같다.

테스트 시작 전에 page.route()로 엔드포인트를 등록한다.
요청이 오면 route.fulfill()로 상태 코드와 JSON 응답을 돌려준다.
페이지에서 실제 사용자 흐름을 수행한다.
로딩 UI와 결과 UI를 assert한다.

왜 이 방식이 좋은가

이 방식의 장점은 분명하다.

돈을 아낀다. 테스트가 실제 LLM API를 치지 않는다.
빨라진다. 응답이 즉시 돌아오므로 테스트 시간이 짧아진다.
안정적이다. 매번 같은 payload를 받으므로 assertion이 흔들리지 않는다.
UI에 집중할 수 있다. 모델 자체가 아니라 프런트 상태 기계를 검증할 수 있다.

어떤 것을 검증해야 하나

LLM 앱 테스트에서 중요한 것은 “문장이 똑같은가”보다 “사용자 경험이 기대대로 흘러가는가”다. 예를 들어 다음을 검증하는 편이 현실적이다.

생성 버튼 클릭 시 요청이 시작되는가
로딩 컴포넌트가 나타나는가
결과 섹션이 렌더링되는가
카드 개수나 섹션 제목처럼 구조적 결과가 맞는가
에러 응답에서 fallback UI가 정상 동작하는가

이런 구조적 검증은 비결정성 문제를 크게 줄여 준다.

실패 시나리오도 같이 테스트하라

실무에서는 성공 케이스만큼 실패 케이스가 중요하다. 네트워크 에러, 500 응답, 빈 결과, validation 실패 같은 응답을 각각 모킹해 두면, 실제 운영에서 자주 깨지는 사용자 경험을 미리 방어할 수 있다.

이 글이 주는 실무 교훈

AI 앱을 테스트할 때 “모델을 테스트한다”와 “제품 경험을 테스트한다”를 분리해야 한다. 전자는 별도의 평가 파이프라인이나 offline eval이 더 어울리고, 후자는 Playwright 같은 E2E 도구에서 고정 응답 기반으로 빠르게 검증하는 편이 맞다.

결론

Next.js 기반 AI 제품의 E2E 테스트는 실제 LLM 호출을 제거하고, Playwright 인터셉트로 응답을 통제하는 쪽이 훨씬 실용적이다. 비용, 속도, 비결정성이라는 세 문제를 한 번에 줄이면서도 FE 팀이 가장 중요하게 보는 사용자 흐름을 안정적으로 검증할 수 있다.

Raw

05-shadcn-live-editor-ko.md

원문 제목: Building UI Blocks on Top of shadcn/ui with a Live Editor 원문 링크: https://dev.to/felipe_menezes/building-ui-blocks-on-top-of-shadcnui-with-a-live-editor-g3 번역일: 2026-03-09 KST

shadcn/ui 위에 라이브 에디터를 얹은 UI 블록 만들기

작성자는 오픈소스 프로젝트 UI Flx를 소개한다. 이 프로젝트는 shadcn/ui를 기반으로 만든 UI 블록 모음으로, 현대적인 프런트엔드 스택에 쉽게 통합하고 커스터마이즈할 수 있도록 설계되었다.

핵심 목표는 단순하다.

재사용 가능한 UI 섹션을 더 쉽게 만든다.
코드에 대한 통제권은 유지한다.
복사해서 붙여 넣기 전에 시각적으로 수정할 수 있게 한다.

라이브 에디터가 핵심 기능

작성자는 UI Flx를 만들면서 “코드를 복사하기 전에 블록을 시각적으로 수정할 수 있으면 좋겠다”는 요구를 가졌고, 그래서 각 블록마다 라이브 에디터를 붙였다.

즉, 사용자는 블록을 미리 편집하고 결과를 즉시 확인한 다음, 자신에게 맞는 형태의 코드를 가져갈 수 있다. 단순한 컴포넌트 갤러리보다 한 단계 더 실용적인 방향이다.

CMS 기반 사이트를 고려한 설계

또 하나의 목표는 CMS 기반 웹사이트와 잘 맞도록 만드는 것이었다. 예시로 Sanity 같은 CMS와 쉽게 붙일 수 있도록 고려했다고 설명한다. 이는 마케팅 사이트, 콘텐츠 사이트, 랜딩 페이지처럼 반복 섹션 조합이 많은 팀에게 특히 유용한 접근이다.

오픈소스 프로젝트

프로젝트는 오픈소스로 공개되어 있으며, 관심이 있으면 사이트에서 직접 확인할 수 있다고 안내한다.

프로젝트: https://ui.flexnative.com

짧은 실무 해석

이 글 자체는 기술 구현 디테일보다는 프로젝트 소개에 가깝지만, FE 실무 관점에서 중요한 시사점은 있다.

shadcn/ui 생태계가 이제 단순 컴포넌트 복제 수준을 넘어 “블록 + 에디터 + 코드 내보내기” 방향으로 확장되고 있다.
팀들이 디자인 시스템보다 빠른 생산성 도구를 원할 때, 이런 블록 기반 접근이 충분히 매력적일 수 있다.
CMS 친화성은 앞으로 마케팅/콘텐츠 프런트엔드에서 더 중요한 선택 기준이 될 가능성이 크다.

결론

아주 긴 기술 글은 아니지만, 최근 FE 툴링 흐름을 잘 보여 준다. shadcn/ui 기반 조립형 UI 자산을 만들고, 이를 라이브 편집 경험과 연결하는 방향은 작은 팀과 스타트업이 빠르게 화면을 생산하는 데 꽤 잘 맞는다.

Raw

06-zip-code-first-ko.md

원문 제목: Put the ZIP code first. 원문 링크: https://zipcodefirst.com/ 번역일: 2026-03-09 KST

ZIP 코드를 먼저 넣게 하라

이 글은 미국 주소 입력 폼 UX를 매우 직설적으로 비판한다. 핵심 주장도 명확하다. 미국에서는 ZIP 코드 5자리만 있으면 도시, 주, 국가를 상당 부분 자동으로 채울 수 있는데, 왜 아직도 주소 폼 맨 아래에 ZIP 코드를 두고 사용자가 도시/주/국가를 일일이 입력하게 하느냐는 것이다.

5글자면 3개 필드를 채울 수 있다

사용자가 90210만 입력해도 Beverly Hills, California, United States를 미리 알 수 있다. 그런데 많은 서비스는 여전히 다음 순서를 강요한다.

Street address
City
State dropdown
ZIP
Country dropdown

작성자는 이걸 2026년에도 반복하는 건 비효율의 전형이라고 꼬집는다.

왜 ZIP 우선이 더 좋은가

ZIP 코드를 먼저 받으면 도시, 주, 국가를 자동 채움할 수 있다. 그 결과:

사용자가 타이핑해야 할 양이 줄고
dropdown 스크롤 지옥이 사라지며
주소 자동완성 검색 범위도 좁아져 더 빠르고 정확해진다
수집되는 데이터 품질도 높아진다

글에서는 Zippopotam.us 같은 무료 API 예시를 보여 주며, 실제 구현이 몇 줄이면 된다고 설명한다.

const res = await fetch(`https://api.zippopotam.us/us/${zip}`)
const data = await res.json()
city.value = data.places[0]["place name"]
state.value = data.places[0]["state"]
country.value = "United States"

주소 폼의 “수치의 전당”

작성자는 형편없는 주소 폼 패턴을 몇 단계로 조롱 섞어 분류한다.

1단계: ZIP이 맨 아래에 있다

이미 자동 채움에 필요한 데이터를 받을 수 있는데도 마지막에 두는 패턴이다.

2단계: ZIP을 받아 놓고 아무 것도 안 한다

사용자는 ZIP을 입력했지만, 폼은 도시/주를 자동 채우지 않는다.

3단계: 스크롤형 국가 드롭다운

국가 200개 이상을 검색 없이 스크롤하게 만드는 패턴이다. 심지어 미국이 “The United States…” 아래에 정렬되어 찾기 더 어려운 경우도 있다.

4단계: 뒤로 가면 폼이 초기화된다

결제 실패 후 뒤로 갔을 때 14개 필드를 전부 다시 입력하게 만드는 최악의 UX다.

추가 제안

작성자는 몇 가지 기본기까지 같이 짚는다.

ZIP 코드에는 inputmode="numeric"를 써서 모바일에서 숫자 키패드가 뜨게 하라.
autocomplete="postal-code", address-line1, country 등 올바른 자동완성 속성을 써라.
국가를 먼저 받는 편이 더 정확할 수는 있다. 다만 핵심은 “이미 아는 정보를 다시 타이핑시키지 말라”는 것이다.

FE 실무 관점의 의미

이 글은 농담 섞인 톤이지만, 실제로는 폼 UX의 매우 중요한 원칙을 말한다.

사용자가 입력해야 하는 정보를 최소화하라.
이미 유추 가능한 값은 시스템이 채워라.
모바일 키보드, 브라우저 autofill, 주소 검색 범위를 모두 함께 최적화하라.

한국 주소 폼에는 그대로 적용되지 않더라도, “입력 순서를 데이터 활용 순서에 맞게 다시 설계하라”는 교훈은 충분히 일반화할 수 있다.

결론

이 글은 거칠지만 맞는 말을 한다. 주소 폼은 여전히 너무 자주 2009년 패턴에 머물러 있다. FE 팀이 폼 UX를 개선하고 싶다면, 먼저 “사용자가 왜 이걸 직접 입력해야 하지?”부터 다시 물어볼 필요가 있다.

Raw

07-typescript-6-rc-ko.md

원문 제목: Announcing TypeScript 6.0 RC 원문 링크: https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-rc/ 번역일: 2026-03-09 KST

TypeScript 6.0 RC 발표

Microsoft는 TypeScript 6.0 RC를 공개하며 다음 명령으로 바로 사용해 볼 수 있다고 안내했다.

npm install -D typescript@rc

이번 6.0은 단순한 기능 릴리스가 아니라 큰 전환점에 가깝다. 팀은 이미 예고했던 것처럼 TypeScript 컴파일러와 언어 서비스를 Go로 재작성한 네이티브 코드베이스로 옮기고 있으며, 그것이 TypeScript 7.0의 기반이 된다. 따라서 6.0은 현재 JavaScript 코드베이스 기반의 사실상 마지막 주요 릴리스이자, 5.9와 7.0 사이를 잇는 브리지 역할을 맡는다.

베타 이후 달라진 점

RC에서는 특히 7.0 동작과의 정렬을 위한 조정이 들어갔다.

1. 제네릭 호출 내 함수 표현식 타입 검사 조정

특히 generic JSX 표현식 안의 함수 표현식 타입 검사에서 더 많은 버그를 잡아내도록 바뀌었다. 기존 코드 중 일부는 이제 명시적 타입 인자를 추가해야 할 수 있다.

2. import assertion 폐기 범위 확대

import ... assert { ... } 문법에 대한 폐기를 import() 호출까지 확장했다. 예를 들어 import(..., { assert: {...} }) 형태도 영향권에 들어간다.

3. 최신 웹 표준에 맞춘 DOM 타입 업데이트

DOM 타입 정의가 최신 웹 표준에 맞게 갱신됐고, Temporal API 관련 조정도 일부 포함됐다.

`this` 없는 함수의 문맥 민감도 감소

글에서 가장 눈에 띄는 기술적 설명은 함수 인자 타입 추론 방식의 변화다.

TypeScript는 보통 예상 타입이나 같은 호출 안의 다른 인자를 통해 타입을 추론할 수 있다. 예를 들어 한 객체 리터럴 안에서 produce가 T를 만들어 내고 consume이 그 T를 받는 구조에서는, 순서가 달라도 잘 추론되는 경우가 많다.

하지만 메서드 문법을 쓸 때는 이야기가 달라질 수 있었다. 매개변수 타입이 명시되지 않은 함수는 “contextually sensitive function”으로 취급되는데, 이 함수는 추론 과정에서 잠시 건너뛰어지는 경우가 있었다. 그 결과 속성 순서에 따라 어떤 메서드는 unknown으로 떨어지는 어색한 상황이 생겼다.

TypeScript 6.0은 이런 부분을 다듬어, this를 사용하지 않는 함수에 대해서는 문맥 민감도를 낮추고 더 일관되게 타입을 추론하려고 한다. 실무적으로는 “객체 리터럴 안 함수/메서드의 선언 순서 때문에 추론 결과가 흔들리는 문제”를 줄이려는 방향으로 이해하면 된다.

7.0 대비 릴리스라는 의미

이번 릴리스의 중요한 메시지는 “새 기능 몇 개 추가”보다 “다가오는 TS 7 전환을 준비하라”에 가깝다. TypeScript 팀은 Go 기반 네이티브 구현을 통해 더 빠른 성능과 shared-memory multi-threading의 이점을 가져오려 한다. 6.0에서의 정렬 작업은 이후 7.0 채택 비용을 줄이기 위한 준비 단계다.

FE/TS 실무 관점의 체크포인트

프런트엔드 팀이 주목할 부분은 다음과 같다.

generic 함수/JSX 사용이 많은 코드베이스는 RC에서 타입 오류가 늘어날 수 있다.
import assertion 관련 코드를 쓰는 프로젝트는 폐기 경고와 향후 마이그레이션 방향을 확인해야 한다.
DOM 타입 업데이트로 웹 표준 관련 타입 변화가 생길 수 있으니 CI를 돌려 보는 것이 좋다.
6.0은 곧 7.0으로 이어지는 징검다리이므로, 대형 모노레포나 TS-heavy 프로젝트라면 지금부터 적응 비용을 살피는 게 좋다.

결론

TypeScript 6.0 RC는 겉으로는 비교적 차분한 릴리스처럼 보이지만, 실제로는 TypeScript 7 네이티브 시대를 준비하는 전략적 릴리스다. FE 팀 입장에서는 당장 체감할 변화보다도, 타입 추론/표준 타입/폐기 문법을 미리 점검하고 다음 메이저 전환에 대비하는 계기로 보는 편이 맞다.