DoStudyPlz.log

[트러블슈팅] 한글 입력 시 Enter 이벤트가 두 번 호출되는 문제

Sun, 26 Oct 2025 06:38:44 GMT

React에서 텍스트 입력 핸들러를 구현하다가 한글 입력 중 Enter를 누르면 이벤트가 두 번 호출되는 현상이 있었다. 영문 입력 시에는 문제가 없었지만, 한글 입력에서만 중복 호출이 발생했다.

현상

다음은 기존 코드이다.

const handleKeyDown = async (e: React.KeyboardEvent) => {
  if (e.isPropagationStopped()) return;
  if (e.key === 'Enter' && !e.shiftKey && text.trim().length > 0) {
    e.preventDefault();
    e.stopPropagation();
    console.log('enter');
    console.log(text);
    onSubmit?.(text);
    setText('');
  }
};

영문 입력에서는 정상 동작했다. 하지만 한글 입력 중 Enter를 누르면 console.log가 두 번 찍히거나, 마지막 글자가 한 번 더 붙는 현상이 발생했다.

원인

한글 입력은 단일 키 입력이 아니다. ‘ㅎ’, ‘ㅏ’, ‘ㄴ’을 순서대로 입력하면 조합 과정을 거쳐 ‘한’이라는 글자가 만들어진다. 이 과정을 조합 입력(Composition) 이라고 한다.

브라우저는 이 조합 과정을 다음 이벤트로 관리한다.

compositionstart
compositionupdate
compositionend

문제는 이 조합 과정 중에도 keydown 이벤트가 발생한다는 점이다. 한글 조합이 완료되기 전, 즉 compositionend 이전에 Enter를 누르면 이벤트가 두 번 호출된다. 조합 중 한 번, 조합 완료 후 한 번이다.

해결

KeyboardEvent 객체에는 조합 중인지 여부를 알 수 있는 속성이 있다. isComposing 이다.

React에서는 e.nativeEvent.isComposing 으로 접근할 수 있다. 이 값이 true일 때는 아직 조합이 끝나지 않은 상태이다. 따라서 이 시점의 Enter 이벤트는 무시해야 한다.

수정한 코드

const handleKeyDown = async (e: React.KeyboardEvent) => {
  // 조합 중에는 Enter 이벤트 무시
  if (e.nativeEvent.isComposing) return;

  if (e.key === 'Enter' && !e.shiftKey && text.trim().length > 0) {
    e.preventDefault();
    e.stopPropagation();

    console.log('enter');
    console.log(text);

    const currentText = text;
    setText('');
    onSubmit?.(currentText);
  }
};

if (e.nativeEvent.isComposing) return; 한 줄로 해결했다. 조합 중 Enter 이벤트를 무시했기 때문에 이제 이벤트는 한 번만 호출된다.

또한 setText('') 이후 onSubmit을 호출하면 상태가 비동기로 초기화될 수 있기 때문에 현재 값을 별도의 변수에 담은 후 호출하는 순서로 변경했다.

정리

한글 입력은 조합 입력 방식이기 때문에 Enter가 두 번 발생할 수 있다.
e.nativeEvent.isComposing 값으로 조합 중인지 확인할 수 있다.
조합 중일 때는 Enter 이벤트를 무시하면 된다.
이 방식은 일본어, 중국어 등 IME 기반 입력에서도 동일하게 적용된다.

참고

[트러블 슈팅] HTTP 캐싱

Sun, 18 May 2025 09:35:52 GMT

바야흐로 목요일, 평소와 같이 배포를 했는데 갑자기 사용자들에게 앱이 흰 화면으로 보인다는 이슈가 인입이 되었다😱 S3 + CloudFront + Next.js 웹뷰 환경에서 캐싱 문제 트러블슈팅한 이야기!! 두두등장

최근 프론트엔드 배포 시스템을 AWS S3와 CloudFront 조합으로 이전한 뒤, 캐싱 문제로 사용자들에게 흰 화면이 발생하는 심각한 이슈를 겪었다. 웹뷰 환경에서는 작은 캐시 이슈도 치명적으로 작용한다는 것을 이번 경험을 통해 절실히 느꼈다.

이 글에서는 문제를 어떻게 분석하고 해결해갔는지 과정을 정리해보았다.

문제 상황: 평소처럼 배포했는데 흰 화면?

어느 날, 앱 고객센터로부터 "앱을 열었더니 흰 화면만 보여요"라는 제보가 들어왔다.

우리는 이전에도 배포를 여러 번 해왔고, 별다른 문제가 없었기 때문에 처음엔 뭔가 일시적인 문제겠거니 했다.

하지만 직접 웹에서 열어보니 콘솔에 아래와 같은 에러가 있었다.

_app.js?ts=1747359952985:498 Uncaught SyntaxError: Invalid or unexpected token

이후 새로고침을 하면 정상적으로 화면이 로딩되었다.

이 증상은 일부 사용자에게만 발생했고, 새로고침을 하지 않은 상태에서 내부 팝업 등을 통해 라우팅할 때 주로 발생했다.

원인 분석: 캐시된 오래된 JS 파일과 최신 HTML의 충돌

콘솔 에러를 본 뒤, 네트워크 탭을 확인해봤다.

에러가 나는 시점에는 main-7b9a라는 오래된 JS 파일이 로딩되고 있었고, 정상일 때는 main-f1ef이라는 최신 JS 파일이 로딩되었다.

즉,

사용자의 브라우저에는 이전 배포 시점의 JS 파일이 캐시되어 있었고
HTML은 새로운 버전으로 불러오면서 버전이 불일치하게 되었다.
이 때문에 구버전 JS로 최신 HTML을 해석하려다 에러가 발생한 것이다.

환경 변화: 왜 갑자기 이런 문제가 생겼을까?

기존에는 프론트엔드를 다른 방식으로 배포하고 있었지만, 최근 S3 + CloudFront로 전환한 이후부터 이런 문제가 생기기 시작했다.

이 환경에서는 브라우저 캐싱이 더욱 강력하게 동작하기 때문에, 의도하지 않으면 캐시가 쉽게 무효화되지 않는다.

처음 시도한 해결 방법: 캐싱 정책 변경

우리는 HTTP 캐싱을 문제의 원인으로 보고, 배포 워크플로우의 aws s3 sync 명령에 캐시 무효화 정책을 추가했다.

적용한 캐시 정책은 다음과 같다:


# _next/static/* → 캐시 X
aws s3 sync out/_next/static s3://.../_next/static \
  --cache-control "no-cache, no-store, must-revalidate"

# *.html → 캐시 X
aws s3 sync out/ s3://... \
  --include "*.html" \
  --cache-control "no-cache, no-store, must-revalidate"

# 나머지 정적 자산 → immutable 캐시 (1년)
aws s3 sync out/ s3://... \
  --exclude "_next/static/*" \
  --exclude "*.html" \
  --cache-control "max-age=31536000, public, immutable

CloudFront invalidation도 함께 설정하여, 모든 경로에 대해 캐시를 무효화하도록 했다.

aws cloudfront create-invalidation --paths "/*"

그런데 문제는 해결되지 않았다

우리는 완벽하게 캐시 정책을 적용했다고 생각했지만, 여전히 사용자에게 흰 화면이 간헐적으로 나타났다.

원인은 생각보다 단순한 곳에 있었다.

원인 재발견: `-include` / `-exclude` 옵션의 맹점

S3에 파일을 업로드할 때 aws s3 sync는 한 번의 명령에 대해 하나의 --cache-control만 적용할 수 있다.

그런데 우리는 아래처럼 --include "*.html" 같은 옵션을 쓰고 있었다.

aws s3 sync out/ s3://... \
  --include "*.html" \
  --cache-control "no-cache, no-store, must-revalidate"

문제는, --include 옵션이 있다고 해서 해당 파일만 cache-control이 설정되는 게 아니라는 점이다.

정확히는:

-include는 대상 파일을 필터링하는 역할만 하고
그 외 모든 파일도 함께 업로드되지만, 동일한 cache-control이 적용된다

그래서 의도치 않게 .js나 이미지 파일에도 no-cache가 적용되었거나, 반대로 .html에 immutable이 적용되어 있었을 수도 있다.

📌 참고 레퍼런스:

aws s3 sync 공식 문서

두 번째 접근: 서비스 워커를 직접 구현

캐시 문제를 사용자 단에서 최대한 자동으로 해결하기 위해, 서비스워커를 직접 구현해보기로 했다. 기존에는 서비스워커가 존재하지 않았기 때문에, 이슈가 발생했을 때 사용자가 강제 새로고침을 하지 않으면 캐싱된 오래된 리소스를 계속 불러오는 문제가 있었다.

서비스워커의 역할

이번 이슈를 해결하기 위한 서비스워커는 다음과 같은 목적을 갖는다:

정적 리소스의 최신화 감지 및 캐시 삭제
오프라인 환경 대응
에러 발생 시 자동으로 캐시 정리 시도
명시적인 캐시 삭제 API 제공

주요 구현 내용

설치 시 사전 캐싱 (install)
```
 self.addEventListener('install', (event) => {
   event.waitUntil(
     caches.open(CACHE_NAME).then((cache) => cache.addAll(PRECACHE_ASSETS))
   );
   self.skipWaiting();
 });
```
배포 시 정의된 정적 파일들을 미리 캐싱하여, 앱 로딩 시 일부 파일들이 빠르게 불러올 수 있도록 하고 skipWaiting()을 통해 새 버전이 즉시 활성화될 수 있도록 했다.

이전 버전 캐시 삭제 (activate)

 self.addEventListener('activate', (event) => {
   event.waitUntil(
     caches.keys().then((cacheNames) =>
       Promise.all(
         cacheNames.map((cacheName) => {
           if (cacheName !== CACHE_NAME) return caches.delete(cacheName);
         })
       )
     )
   );
   self.clients.claim();
 });

새로운 캐시 이름이 등록되면, 이전 버전의 캐시를 자동으로 제거함으로써 충돌을 방지했다.

네트워크-우선 or 캐시-우선 전략 (fetch)
- _next/static, .js 등은 네트워크 우선
- 나머지 리소스는 캐시 우선
  
  이는 최신 JavaScript 코드가 반드시 반영되도록 하기 위해서다.
스크립트 로딩 실패 시 자동 캐시 삭제

HTML 내에