3D 뷰어 텍스처 처리 성능 최적화 — 2단계 캐싱

3D 뷰어에서 소재를 바꿀 때마다 텍스처 이미지를 서버에서 받아오는 흐름이 있었어요. 화면에 동일한 패턴의 소재가 여러 슬롯에 동시에 들어가는 경우가 흔했는데, 그 때 같은 텍스처 URL이 거의 동시에 4~5번씩 요청되는 일이 자주 일어났습니다. 네트워크 패널을 보면 같은 url이 동시에 떠 있고, 서버 응답을 기다리는 동안 사용자에게 보이는 첫 프레임이 의도보다 늦게 그려졌어요.

처음엔 "결과 캐시(Map)만 있으면 두 번째부터는 캐시가 잡혀서 괜찮겠지"라고 생각했는데, 실제로는 동시에 첫 요청이 진행 중일 때 두 번째·세 번째가 들어오면 모두 캐시 미스로 분류되어 똑같은 fetch가 4번 떠버렸어요. 결과 캐시는 "이미 끝난 작업"만 막을 뿐, "지금 진행 중인 작업"은 못 막는다는 게 문제의 본질이었습니다.

loadTexture 함수가 들어왔을 때 세 갈래로 분기합니다.

const resultCache = new Map<string, Texture>();
const inflightCache = new Map<string, Promise<Texture>>();

async function loadTexture(url: string): Promise<Texture> {
  // 1. 결과 캐시: 이미 끝난 작업
  const cached = resultCache.get(url);
  if (cached) return cached;

  // 2. 인플라이트 캐시: 진행 중인 작업의 Promise 공유
  const inflight = inflightCache.get(url);
  if (inflight) return inflight;

  // 3. 둘 다 miss: 새로 시작하고 인플라이트에 등록
  const promise = fetchAndDecode(url)
    .then((tex) => {
      resultCache.set(url, tex);
      inflightCache.delete(url); // 완료된 인플라이트는 정리
      return tex;
    })
    .catch((err) => {
      inflightCache.delete(url); // 실패해도 정리해야 다음 시도 가능
      throw err;
    });

  inflightCache.set(url, promise);
  return promise;
}

핵심은 단계 3에서 fetch를 시작하기 전에 Promise 객체를 인플라이트 Map에 먼저 등록한다는 점이에요. 그러면 같은 url을 동시에 요청한 다른 호출자가 단계 2에서 그 Promise를 발견하고 같이 await 합니다. fetch는 한 번만 나가고, N명의 호출자가 결과 한 개를 공유하는 구조가 만들어져요.

이 패턴 도입 후 같은 텍스처가 4~5번 동시에 요청되던 시나리오에서 네트워크 호출이 1번으로 줄었고, 체감 첫 프레임 시간이 눈에 띄게 빨라졌습니다.

"Promise를 공유한다"가 처음엔 추상적으로 들릴 수 있는데, 자바스크립트 모델에서는 매우 구체적인 동작이에요. Promise는 그냥 자바스크립트 객체고, Map에 저장하는 건 그 객체의 참조 자체입니다.

호출자 A가 단계 3에서 Promise를 만들고 인플라이트 Map에 넣어요. 호출자 B가 직후에 들어와서 단계 2에서 같은 Promise 객체를 꺼내 갑니다. 이제 A와 B는 같은 Promise 객체에 각자 await을 걸고 있는 상태가 돼요. fetch 호출은 그 Promise 안에서 단 한 번만 일어났고, fetch가 끝나면 Promise는 한 번만 resolve 되는데, await 걸어 둔 모든 callback이 마이크로태스크 큐에 들어가서 차례로 같은 결과를 받습니다.

핵심 통찰은 **"Promise는 결과의 채널이지 작업의 트리거가 아니다"**라는 거예요. 새 호출자가 같은 Promise를 await한다고 해서 fetch가 다시 트리거되지 않아요. fetch는 Promise 생성 시점에 이미 한 번 시작됐고, await은 단지 "끝나면 알려달라"는 구독 신호일 뿐입니다.

원래 컬러라이즈 모드 판별이 isColorize && !isPattern && hasTexture 같은 boolean prop 여러 개의 조합으로 표현되어 있었어요. 가능한 조합이 많아지니까 자연스럽게 if/else가 깊어지고, 한 모드의 동작을 바꾸려면 분기 여러 군데를 동시에 손대야 하는 상태였어요. 약 400줄짜리 함수가 됐고, 동료들이 손대길 꺼리는 코드였습니다.

리팩토링 핵심은 상태 자체를 enum 한 개로 표현한 것이었어요. 가능한 모드를 나열한 enum DisplayMode { Colorize, Pattern, Plain, Mixed, ... }를 만들고, 입력 boolean들을 단 한 번 enum 값으로 변환하는 normalize 단계를 둡니다. 그 이후의 모든 분기는 switch (mode) 한 단계 평탄화. 400줄이 200줄로 줄었어요.

더 큰 효과는 TypeScript의 exhaustive check였어요. switch 문에 default 자리에 _exhaustive: never = mode 같은 패턴을 두면, enum에 새 값이 추가됐는데 분기가 빠진 곳이 있으면 컴파일 에러가 납니다. 새 모드를 추가했을 때 컴파일러가 손봐야 할 모든 곳을 정확히 알려주니까, 누락 버그가 원천적으로 차단됐어요. 이게 enum 기반 설계의 진짜 가치라고 봅니다.

캐시는 도입할 때부터 회수 정책을 함께 설계해야 한다는 게 제 원칙이에요. 세 가지 측면에서 통제했습니다.

첫째, 결과 캐시 evict 정책. 단순 Map은 GC 후보가 될 수 없으니 무한히 자라요. 텍스처 개수 상한을 두고 LRU 정책으로 가장 오래 안 쓴 항목을 제거했습니다. 둘째, GPU 자원 정리. 텍스처는 단순 자바스크립트 객체가 아니라 GPU 메모리도 점유하니까, evict될 때 엔진의 dispose 메서드를 명시적으로 호출해서 GPU 메모리도 회수했어요. 셋째, 캐시 키 정규화. ?a=1&b=2와 ?b=2&a=1이 다른 키로 들어가면 같은 리소스가 두 번 캐시되는 비효율이 생기니까, URL을 정규화한 뒤 키로 사용했습니다.

인플라이트 캐시는 자체 정리예요. fetch가 resolve나 reject로 끝나는 순간 delete 하는 게 패턴이라 별도 회수 정책이 필요 없습니다. 다만 fetch가 영원히 끝나지 않는 좀비 케이스를 막기 위해 timeout을 걸어 fail로 처리하는 안전장치를 같이 뒀어요.