이승준Seungjun Lee

아래 사례는 전부 같은 네 단계로 적었습니다. 해결 방법의 기술 이름보다 문제가 드러난 현상을 어떻게 분석했는가에 무게를 뒀습니다.

1. 01

   문제

   Problem

   사용자가 무엇을 겪었는지를 사용자의 말로 적는다. 화면이 안 넘어간다, 눌렀는데 딴 게 열린다.

   개발자의 언어(TPS, 커넥션)로 시작하면 원인을 가정한 채 출발하게 된다. 증상은 사용자 쪽에 있다.

   →
2. 02

   분석

   Analysis

   그 현상이 왜 그렇게 보이는지를 이벤트 루프, 프록시 버퍼, 메모리 영역, 좌표계 같은 실제 동작으로 설명한다.

   원인을 CS로 설명할 수 있으면 해결책은 따라온다. 설명할 수 없으면 고쳐도 왜 고쳐졌는지 모른다.

   →
3. 03

   해결 방안

   Options

   선택지를 여럿 놓고, 이 서비스의 규모에 맞는지·지금 가진 도구로 되는지를 기준으로 비교한다.

   인프라를 늘리는 답은 대개 원인을 고치지 않은 채 환경을 키운다. 설정 한 줄로 되는지 먼저 본다.

   →
4. 04

   결론

   Decision

   하나를 고르고, 그 선택이 무엇을 내주는지 적는다. 그리고 고친 뒤에 무엇을 지켜볼지 정한다.

   만들고 끝이 아니다. 부작용은 운영 중에 나타나고, 규모가 바뀌면 옳았던 선택이 틀린 선택이 된다.

인턴으로 참여한 서비스에서 만난 문제 6건. 각 글의 머리에는 사용자가 겪은 것을, 분석에는 브라우저와 네트워크와 메모리가 실제로 한 일을, 결론에는 고른 뒤에 무엇을 지켜보는지를 적었습니다.

1. 012026.08
   사용자 웹 A·severity medium

   뒤로가기를 하면 보던 자리가 아니다

   스크롤 위치가 왕복마다 밀리는 문제

   문제포스트를 보고 뒤로가기를 누르면 보던 자리보다 아래에 떨어진다. 왕복할수록 더 밀리고, 펼쳐 둔 글은 접혀 있다

   분석스크롤 위치는 좌표계에 종속된 숫자다추정 높이와 실측 높이의 좌표계 불일치브라우저 scroll anchoring의 개입상태의 수명 불일치갱신 중 스냅샷이 바뀌는 문제

   결론좌표를 보정하는 대신 좌표계가 바뀌지 않게 만들었다. 상태는 데이터와 수명을 맞추고, 자동 갱신은 끄고 새 글은 사용자가 적용하게 했다

   • 왕복 반복 시 착지 오차 0px
   • 좌표 보정 코드 0줄
   • 뒤로가기 시 전 페이지 일괄 마운트 스파이크 제거

   SvelteKitTanStack QueryCSS Scroll Anchoring읽기
2. 022026.08
   사용자 웹 A·severity high

   피드를 오래 내리면 폰이 느려지고 탭이 죽는다

   무한스크롤에 메모리 상한 만들기

   문제피드를 오래 내리면 점점 버벅이고, 폰에서는 이미지가 늦게 뜨거나 탭이 통째로 새로고침된다

   분석렌더러 프로세스의 메모리 구성(DOM·디코드 이미지·JS 힙)선형 증가와 상한의 부재content-visibility가 막는 것과 못 막는 것가상화와 추정 높이의 레이아웃 시프트

   결론라이브러리 세 개를 검토한 뒤, 이 피드에만 있는 조건(로드된 것은 전부 한 번 그려졌다)을 이용해 추정 없는 페이지 단위 가상 스크롤을 직접 만들었다

   • 200장 기준 DOM 노드 21,248 → 4,400(−79%)
   • 이미지 캐시 498MB → 189MB(−62%)
   • JS 힙 30.3MB → 10.5MB(−65%)
   • 로드량에 비례하던 사용량을 상한 고정으로

   Svelte 5IntersectionObserverResizeObserverChrome DevTools읽기
3. 032026.07 – 2026.08
   사용자 웹 A·severity high

   모달에서 좋아요를 눌렀는데 뒤 피드는 그대로

   한 데이터가 여러 곳에 사는 문제

   문제모달에서 좋아요를 눌렀는데 닫고 나면 뒤 피드의 숫자는 그대로다. 같은 글이 화면마다 다른 상태로 보인다

   분석서버 상태의 복제와 캐시 일관성무효화(invalidate) 전략의 전제 조건정규화와 갱신 이상갱신 비용 O(캐시)와 O(1)참조 동일성과 렌더링

   결론라이브러리(Apollo)를 들이는 대신 정규화 캐시라는 설계만 가져와 직접 만들었다. 전수 순회로 먼저 문제를 닫고, 비용 모양이 문제가 되자 엔티티 스토어로 옮겼다

   • 응답 처리 17.7ms → 0.66ms
   • 클릭 → 화면 반영 ~26ms → ~11ms(네트워크와 무관한 상수)
   • 갱신 비용 O(캐시 크기) → O(1)

   Svelte 5TanStack QueryGraphQL읽기
4. 042026.07
   어드민 B·severity medium

   같은 코드량인데 배포는 3배 느리다

   번들러를 바꿔도 안 줄던 5초의 정체

   문제운영팀이 요청한 수정이 반영되기까지 유독 오래 걸리고, 배포가 도는 동안 어드민 자체도 잠깐 느려진다

   분석번들러의 모듈 그래프와 플러그인 훅 비용배럴 파일과 정적 링킹트리셰이킹이 숨기는 비용단일 코어 서버의 CPU 경쟁

   결론번들러 업그레이드와 import 경로 교체로 빌드 시간을 54% 줄였다. CI 서버 분리는 조건을 적어 보류했다

   • 빌드 7.87s → 3.61s(−54%)
   • 변환 모듈 4,315 → 724개(−83%)
   • 산출물 크기 동일

   Vite 8SvelteKitESLintpm2읽기
5. 052026.06
   사용자 웹 A·severity medium

   모달을 닫았는데 뒤에 있던 카드가 눌린다

   모바일 실기기에서만 생기는 유령 클릭

   문제모바일에서 모달 바깥을 탭해 닫으면, 그 자리에 있던 뒤 카드까지 눌려 다른 화면으로 넘어간다

   분석터치 입력의 이벤트 시퀀스와 합성 clickclick 타겟 결정 규칙과 hit-test 시점이벤트 전파와 별개 이벤트의 구분

   결론DOM을 바꾸는 시점을 click으로 옮겨 뒤따라올 이벤트 자체를 없앴다. 우회 플래그는 채택하지 않았다

   • 실기기 유령 클릭 재현 0건
   • 실기기 테스트를 QA 체크리스트에 추가

   Svelte 5Pointer Events읽기
6. 062026.05
   어드민 B·severity high

   로딩 중에 다른 메뉴를 눌러도 화면이 넘어가지 않는다

   배포 환경에서만 생긴 대기 현상

   문제오래 걸리는 화면을 열어 둔 채 다른 메뉴를 누르면, 앞 화면의 로딩이 끝날 때까지 아무것도 바뀌지 않는다

   분석HTTP/1.1 커넥션 상한리버스 프록시 응답 버퍼링단일 워커의 직렬 처리와 Convoy Effect

   결론설정 두 줄(proxy_buffering off, HTTP/2)과 데이터 정책 하나로 해결하고, 백엔드 워커 증설은 제안으로 넘겼다

   • 메뉴 이동이 앞 요청과 무관하게 즉시 반응
   • 핵심 정보는 먼저·무거운 표는 나중에 도착하는 스트리밍이 배포 환경에서도 동작

   SvelteKitNode.jsNginx읽기