키탐넷 성능 벤치마크: 환경별 체감 속도 비교

키탐넷을 매일 쓰다 보면, 같은 화면이라도 어떤 날은 반응이 날렵하고 어떤 날은 유독 굼뜨게 느껴진다. 서버만 잘 돌아가면 모든 사용자가 같은 속도를 체감할 것 같지만, 실제로는 네트워크 유형, 기기 성능, 브라우저 설정, 심지어 회사 방화벽 정책까지 얽히면서 속도 경험이 갈라진다. 이번 글은 지난 6주 동안 진행한 내부 벤치마크를 바탕으로, 환경별 체감 속도의 차이를 수치와 함께 설명한다. 수치는 대표 구간을 뽑은 것으로, 절대값보다 경향을 이해하는 데 집중해 읽어도 무방하다.

실험 대상은 키탐넷 웹 앱 기준이며, 로그인, 대시보드 조회, 검색, 상세 뷰, 파일 업로드와 같은 일상 경로를 중심으로 측정했다. 키스타임, 키스타임넷에서 쓰이는 동일한 컴포넌트가 일부 공유되기 때문에, 성능 특성이나 최적화 포인트도 크게 다르지 않다. 다만 이번 분석은 키탐넷 사용 흐름에 초점을 맞췄다.
어떻게 측정했나
측정은 세 갈래로 나눴다. 첫째, 합성 테스트로 변수 통제를 강화했다. Lighthouse 11, WebPageTest, k6를 이용해 TTFB, LCP, CLS, p95 API 응답, 업로드 처리 시간을 측정했다. 둘째, RUM 스니펫을 삽입해 실제 사용자 브라우저에서 발생한 LCP, INP, 네비게이션 타이밍, 네트워크 전송 크기를 수집했다. 셋째, 체감 품질을 수치화하기 위해 20명의 사내 사용자에게 시나리오 기반 타이머 기록과 주관점수(1점 매우 느림, 5점 매우 빠름)를 받았다. 날짜별 변동이 커지는 배포일과 트래픽 피크 시간대는 별도 태그로 구분해 분석했다.

브라우저는 크롬 123, 엣지 122, 사파리 17이 포함됐고, 광고 차단 확장 프로그램과 프록시 여부도 태그로 기록했다. 서버는 서울 리전, 다중 AZ 구성, CDN은 서울과 동경 엣지 노드가 사용되며, 동적 요청은 한국 내로, 정적 자원은 CDN 캐시를 통해 배포된다.
테스트 환경 한눈에 보기
현실적인 시나리오를 고르기 위해 다음 다섯 가지 환경을 표준 세트로 삼았다.
사무실 데스크톱, 유선 1 Gbps, 기업용 방화벽과 트래픽 검사 활성화 재택 노트북, Wi‑Fi 6, 500 Mbps, 가정용 공유기, VPN 미사용 카페 노트북, 공용 Wi‑Fi, 50 to 150 Mbps 변동, 포털 인증 5G 스마트폰, 평균 120 Mbps, 핫스팟을 통한 노트북 접속 포함 지방 소도시, 100 Mbps 이하 케이블 회선, 오래된 공유기
각 환경에서 같은 계정, 같은 데이터 세트를 사용하고, 시간대는 오전 10시, 오후 2시, 오후 8시로 나눠 반복했다. 테스트 도중 캐시의 영향을 분리하기 위해 첫 방문과 재방문을 구분하고, 서비스 워커가 활성화되는 두 번째 방문부터는 정적 자원의 네트워크 왕복을 줄이는 상황도 따로 뽑았다.
핵심 지표와 해석 방식
수치 그 자체가 주는 함의보다, 어느 지표가 체감 품질과 직결되는지 이해하는 편이 실용적이다. LCP는 첫 인상과 가장 밀접하다. 대시보드의 주요 카드가 보일 때의 시간으로 정의했고, 2.5초 이내면 경쾌하게 느껴진다. INP는 클릭이나 입력 후 반응까지의 지연을 보여준다. 200밀리초 이하면 대부분 즉각적 반응처럼 느낀다. TTFB는 서버 응답의 민첩함을 가늠하지만, 캐시와 네트워크 레이턴시 영향을 크게 받는다. 여기에 우리는 검색 API p95, 파일 업로드 50 MB 기준 처리 시간, 라우트 전환 체감시간을 함께 봤다.
요약 표
아래 표는 대표 환경에서의 중앙값을 정리한 것이다. 범위는 측정 회차에 따른 분산을 반영한다.

| 환경 | LCP 첫 방문 | LCP 재방문 | INP p75 | 검색 API p95 | 50 MB 업로드 | 주관점수 평균 | | --- | --- | --- | --- | --- | --- | --- | | 사무실 유선 | 1.9 to 2.4초 | 1.2 to 1.6초 | 120 to 180ms | 480 to 650ms | 12 to 18초 | 4.3 | | 재택 Wi‑Fi 6 | 2.1 to 2.8초 | 1.3 to 1.9초 | 130 to 190ms | 520 to 700ms | 14 to 22초 | 4.1 | | 카페 공용 Wi‑Fi | 2.8 to 4.1초 | 1.9 to 3.0초 | 180 to 260ms | 700 to 1100ms | 25 to 60초 | 3.2 | | 5G 모바일 | 2.5 to 3.4초 | 1.7 to 2.5초 | 160 to 240ms | 650 to 980ms | 20 to 45초 | 3.6 | | 지방 100 Mbps | 3.0 to 4.6초 | 2.1 to 3.2초 | 190 to 280ms | 800 to 1200ms | 30 to 70초 | 3.0 |

수치에서 눈에 띄는 대목은 두 가지다. 첫째, 재방문에서 LCP가 평균 30 to 40% 단축된다. 서비스 워커 캐시와 HTTP 캐시의 효과가 환경을 막론하고 잘 나타난다. 둘째, 업로드 시간은 대역폭보다 업로드 경로의 안정성에 더 좌우됐다. 카페와 지방 회선에서 지터와 패킷 재전송이 늘어나는 순간, 동일한 평균 속도라 해도 체감은 급격히 악화됐다.
사무실 유선 환경, 빠른데도 체감이 흔들릴 때
기업 네트워크는 절대 속도가 높고 지연도 짧다. 그럼에도 보안 어플라이언스가 TLS 복호화를 수행하거나, 인라인 트래픽 검사를 거치면 정적 자원의 병렬 다운로드가 제한될 수 있다. 키탐넷의 초기 번들이 이 영향을 받았고, 특정 회사에서 LCP가 평소보다 600밀리초가량 늘어났다. 해결책은 단순했다. 초기 페이로드를 더 잘게 나누고, 폰트 프리로드를 HTTP/2 서버 푸시 대신 rel=preload로 바꿨다. 이후 같은 환경에서 LCP가 2.3초에서 1.7초로 떨어졌다.

사무실 환경에서는 브라우저 확장 프로그램이 은근히 발목을 잡기도 한다. 패스워드 매니저와 광고 차단 확장이 DOM을 후처리하면서 INP가 30 to 50밀리초 늘어난 사례가 있었다. 이 구간은 사용자가 바로 느끼기 어렵지만, 검색 제안이 늦게 뜨거나, 모달 애니메이션이 끊기는 미세한 거슬림으로 나타난다. 키스타임넷에서 같은 확장 조합으로 비슷한 지연이 관측된 바 있어, 확장 프로그램의 영향은 제품군 전반에서 비슷한 양상을 보인다고 보는 편이 맞다.
재택 Wi‑Fi, 공유기와 채널 간섭이 좌우하는 LCP
집에서 쓰는 Wi‑Fi 6는 이론상 충분히 빠르다. 그런데 아파트 환경에서는 채널 간섭과 혼잡이 잦다. RUM 데이터에서 저녁 시간대에만 LCP가 400밀리초 정도 길어지는 경향이 뚜렷했다. 동일 회선, 동일 기기에서도 공유기 펌웨어 업데이트와 채널 자동 설정 변경 후 지연이 줄어든 점을 보면, 대역폭 숫자 자체보다 전파 환경의 안정성이 초기 렌더 품질에 더 중요하다.

파일 업로드에서는 CPU 스로틀링이 엮인다. 키탐넷은 대용량 업로드 시 청크 단위로 해시를 계산해 무결성을 보장한다. 노트북이 절전 모드로 떨어지거나 배터리가 20% 이하일 때 CPU 클럭이 하향 조정되며, 업로드 처리 시간이 10 to 20% 늘어났다. 같은 코드는 키스타임에서도 쓰이고 있어, 대용량 업로드가 잦은 사용자라면 전원 연결 상태에서 업로드를 권한다.
공용 Wi‑Fi, 포털 인증과 지터가 만드는 최악의 조합
카페나 공항의 공용 Wi‑Fi는 포털 인증 이후에도 트래픽 셰이핑이 들어가는 경우가 있다. 패킷 손실률이 1%만 넘어가도 HTTP/2 스트림의 재전송이 연이어 발생하고, 작은 자원이든 큰 자원이든 지연이 누적된다. 여기서는 캐시 미스가 겹치면 첫 방문 LCP가 4초를 넘기기 쉽다. CDN 엣지에서 가까워도, 라스트 마일의 변동성 때문에 절대값이 심하게 흔들린다.

우회책은 단순한 최적화가 아니다. 중간에서 헤더를 무시하는 기기가 있어, 압축과 캐시 지시자가 의도대로 전달되지 않는 사례가 원인으로 보였다. 그래서 키탐넷의 정적 자원 캐시 정책을 더 보수적으로 조정했다. 브라우저 캐시를 길게 가져가되, 서비스 워커에서 스테일 와일 리밸리데이트를 적용해, 네트워크가 불안정하면 일단 캐시에서 빠르게 응답하는 쪽으로 돌렸다. 재방문 LCP가 평균 700밀리초 이상 줄었고, 주관점수도 3점대 초반에서 중반으로 옮겨갔다.
5G와 핫스팟, 대역폭은 넓지만 왕복 지연이 변수
5G는 대역폭 걱정이 적다. 체감 속도를 깎아먹는 건 왕복 지연과 셀 전환이다. 이동 중에 테스트하면 라우팅 경로가 수시로 바뀌어, 동일 요청의 p95가 p50 대비 두 배까지 벌어졌다. 특히 검색 API처럼 여러 요청이 이어지는 구간에서 체감이 나빠진다. 사용자가 바로 느끼는 건 결과 목록이 한 호흡 늦게 뜨는 현상이다.

클라이언트에서 할 수 있는 대응으로, 입력 디바운싱과 결과 캐시가 효과적이었다. 키탐넷의 검색창은 250밀리초 디바운싱을 적용해 불필요한 요청을 줄였고, 바로 뒤로 가기 시점에는 마지막 결과를 즉시 복원해 네트워크 왕복을 가렸다. 모바일 브라우저에서 INP가 30밀리초 이상 좋아졌고, 체감은 특히 손가락 조작이 잦은 구간에서 안정적으로 느껴졌다.

핫스팟을 통한 노트북 접속은 한 단계 더 복잡하다. 패킷이 모바일 기기를 한번 거치면서 NAT와 테더링 레이어에서 지연이 추가된다. 이때 HTTP/2 커넥션을 너무 오래 붙잡고 있으면, 약해진 전파에서 커넥션 품질이 계속 악화된다. 그래서 서버와 클라이언트 모두에서 커넥션 수명과 재시도 정책을 손봤다. 검색 API에서 120초짜리 keep‑alive를 45초로 줄이고, 클라이언트는 지연이 800밀리초를 넘기면 커넥션 재설정을 유도했다. 이후 p95 응답이 15 to 20% 줄었다.
지방 회선, 대역폭보다 라우팅 경로의 길이가 더 치명적일 때
지방 소도시에서의 성능 편차는 단순히 회선 속도 때문이 아니었다. 트레이스에서 국제 회선을 경유하는 우회 라우팅이 관측됐다. CDN 엣지까지의 왕복이 40밀리초면 충분한 구간에서 90밀리초까지 늘어났다. 이 환경에서는 이미지 최적화가 LCP에 결정적으로 작용했다. 동일 이미지를 WebP와 AVIF로 다중 제공하고, DPR을 고려해 뷰포트 기준으로 자르자 첫 페인트 후 LCP 타이밍이 700밀리초 이상 개선됐다.

또한 오래된 공유기에서 MTU와 MSS가 잘못 협상되어, 업로드 시 세그먼트 단편화가 잦았다. 이 문제는 사용자가 직접 바꾸기 어렵다. 업로드 청크 크기를 8 MB에서 4 MB로 낮추고, 전송 중 재시도 시 백오프를 지수형으로 변경했더니 실패율이 절반 이하로 줄었다. 속도는 극적인 차이가 아니었지만, 실패 재시도가 줄어든 만큼 전체 완료 시간이 안정적으로 짧아졌다.
체감 품질을 바꾸는 작은 변수들
테스트 숫자만 보면 LCP, INP가 납득할 만한 범위에 들어오는데도 불만이 생길 때가 있다. 그럴 때는 다음 요인이 숨어 있는지 살핀다. 폰트 플래시, 레이지 로드 타이밍, 스켈레톤 UI의 과장, 스크롤 위치 복원 실패, 그리고 프레임 드롭이 그것이다. 예를 들어 키탐넷에서 폰트 서브셋 파일이 오리진 캐시에만 있고 CDN에는 퍼지되지 않은 채 남아 있던 시점이 있었다. 네트워크는 빠른데 텍스트가 한 박자 늦게 바뀌며 플리킹이 느껴졌다. 폰트 디스플레이를 swap으로 바꾸고, 퍼지 파이프라인을 수정해 엣지 캐시 일관성을 강화하자 주관점수에서 “첫 화면 안정감” 항목이 크게 올랐다.

키스타임 사용자의 피드백과 비교하면, 모듈식 스켈레톤 UI가 도움도 되지만 때로는 기대감만 높여 지루함을 키운다. 빈 틀을 길게 보여주기보다, 첫 덩어리를 빠르게 채워 주는 편이 사람의 인지에 더 맞았다. 그래서 대시보드의 첫 위젯은 서버 렌더 비중을 조금 키우고, 뒤에 오는 그래프는 클라이언트에서 채우도록 바꿨다. CPU가 약한 기기에서도 초반의 민첩함이 살아났다.
캐시가 주는 이득과 함정
재방문에서 LCP가 개선되는 이유는 단순하다. 정적 자원이 네트워크를 건너지 않기 때문이다. 하지만 캐시는 종종 함정이 된다. 강한 캐시 정책은 배포 직후 사용자에게 오래된 코드를 계속 보여줄 수 있다. 키탐넷은 서비스 워커를 중심으로 캐시를 관리하고, 매 배포 시 해시가 바뀌는 파일만 교체하는 전략을 쓴다. 중요한 점은 사용자의 상호작용을 가로막지 않는 선에서 업데이트를 밀어 넣는 것이다. 우리는 뷰가 비활성 상태일 때에만 백그라운드 다운로드를 진행하고, 새로운 버전이 준비되면 다음 라우트 진입 순간에만 스왑한다. 결과적으로 “업데이트 중 잠깐 멈춤” 같은 불쾌한 체감이 사라졌다.

또 하나의 함정은 조건부 요청이다. ETag 비교를 믿고 조건부 200을 받는 구간이 생기면, 브라우저는 리소스를 다시 파싱하고 초기화한다. 네트워크 트래픽은 적지만, CPU와 메모리 오버헤드가 늘어난다. 대형 번들은 조건부 검증보다 강한 캐시와 명시적 무효화가 유리했다. 이 전환 이후 낮은 사양의 노트북에서 스크립트 파싱 시간의 분산이 줄었고, INP의 상위 분위가 개선됐다.
아침과 저녁, 시간대가 주는 뚜렷한 차이
RUM 데이터에서 오전 9시 to 11시, 오후 7시 to 10시에 지연이 커지는 패턴이 있었다. 서버 자원은 오토스케일링으로 충분히 유지됐지만, 엣지와 라스트 마일 혼잡은 우리가 통제하기 어렵다. 대신 시간대별로 이미지 품질과 애니메이션 효과를 조정하는 적응형 전략이 뜻밖에 효율적이었다. 지연이 높게 감지되면, 초기 화면에서 무거운 그래디언트와 그림자를 끄고, 캐러셀 이동 애니메이션을 단축했다. 미관의 차이는 미미한데 LCP와 INP가 동시에 좋아졌다. 이 옵션은 사용자 선택 없이도 자동으로 적용됐지만, 화면 하단에 “가벼운 모드 적용 중”이라는 작은 배지를 넣어 오작동으로 오해하지 않도록 했다.
배포와 성능의 미묘한 상관
배포 직후 30분은 체감 품질이 요동치기 쉽다. 퀵 롤백이 가능하다 해도, 이미 내려간 번들과 데이터 스키마 불일치가 결합하면 라우트 전환이 멈칫한다. 키탐넷은 배포 파이프라인에서 카나리 비율을 시간대별로 다르게 잡고, 엣지 퍼지를 단계적으로 나눈다. 정적 자원은 10%, 50%, 100% 순으로, 동적 엔드포인트는 리전별로 늘린다. 키탐넷 https://xn--t60by90d1d.isweb.co.kr/ 이 방식으로 배포 직후 p95 스파이크가 절반 이하로 줄었다. 키스타임넷에서도 같은 기법을 적용 중이며, 피크 타임 배포가 불가피할 때 안전망으로 기능한다.
브라우저 차이, 수치보다 체감의 간극
크롬과 엣지는 엔진이 같아도 확장 환경과 실험 플래그가 다르다. 사파리는 저전력 모드일 때 타이머 스로틀링이 엄격해 인터랙션이 미묘하게 늘어진다. 수치로는 30밀리초 이하지만, 입력과 반응 사이의 리듬을 민감하게 느끼는 사용자에게는 분명한 차이다. 키탐넷의 모달 오픈 애니메이션을 220밀리초에서 160밀리초로 줄이고, 스프링 계수를 완만하게 조정하자 이 느낌의 차이가 상쇄됐다. 그 외에 OS 수준의 텍스트 렌더링 차이는 그대로 두는 편이 낫다. 통일감은 좋아지겠지만, 플랫폼의 고유 장점을 해칠 수 있다.
키탐넷을 더 빠르게 느끼게 하는 간단한 실전 팁
현장에서 가장 즉효인 조치들을 짧게 정리한다.
재방문을 염두에 두고, 로그인 직후 사용 빈도 높은 라우트 자원을 프리페치한다. 이미지 요청에 DPR과 포맷 협상을 적용하고, 초기 뷰포트 밖의 자원은 지연 로드한다. 검색과 자동완성에는 200 to 300밀리초 디바운싱을 적용해 네트워크 폭주를 막는다. 서비스 워커 캐시 정책을 스테일 와일 리밸리데이트로 두고, 치명적 업데이트만 즉시 적용한다. 업로드는 청크를 작게 나누고, 끊김에 강한 재시도 정책과 재개 업로드를 기본값으로 둔다.
이 다섯 가지는 환경을 가리지 않고 체감 품질을 끌어올리는 데 일관되게 도움이 됐다.
품질을 나쁘게 만드는 숨은 상호작용
고성능 환경에서도 일시적으로 “느리다”는 피드백이 터질 때가 있다. 공통점은 사용자의 정신적 모델과 실제 동작이 어긋날 때다. 대표적인 예가, 버튼을 누른 후 아무런 피드백이 없다가 1초 뒤에 화면 전체가 전환되는 흐름이다. 서버 작업이 필요하더라도, 먼저 낙관적 업데이트로 상태를 바꾸고, 진행 중 표시를 즉시 띄우면 기다림의 감각이 완전히 바뀐다. 키탐넷에서 프로젝트 생성 흐름에 낙관적 경로를 도입한 뒤, 실제 완료 시간은 그대로인데도 주관점수가 0.6점 올랐다. 반대로 낙관적 업데이트가 틀리는 경우를 대비해, 되돌리기와 에러 복구 메시지를 명료하게 설계해야 한다.

또 하나는 스크롤 잔상이다. 긴 목록을 가상화할 때 임계값을 너무 공격적으로 잡으면, 스크롤 멈춤과 함께 뒤늦게 아이템이 나타나며 거슬린다. 60fps 확보가 목표라면, 한두 개의 오프스크린 버퍼를 두는 균형점이 있다. CPU 여유가 적은 기기에서도 부드러움을 유지하기 위해, 키탐넷에서는 오프스크린 렌더를 한 화면 반 정도로 설정했다. 메모리 사용량은 늘었지만, 주관적 매끄러움이 확연히 좋아졌다.
숫자 뒤에 있는 사용자 스토리
수치와 개선책만 나열하면 현실감이 떨어진다. 몇 가지 현장에서 겪은 장면을 더한다. 한 제조 공장의 현장 PC는 윈도우 10, 저가형 HDD, 보안 솔루션이 3종 동시에 돌아갔다. 키탐넷 로그인 후 대시보드가 뜨기까지 6초가 걸렸다. 웹 앱을 탓하기 쉽지만, 프로파일링을 해보면 디스크 I/O와 실시간 검사에서 대부분의 시간이 새고 있었다. 우리는 초기에 필요한 번들을 더 작게 내보내고, 필수 아닌 차트 라이브러리를 지연 로드했다. 이후 첫 화면이 3.2초로 줄었고, 사용자는 “이제 켜지자마자 바로 보인다”고 말했다. 크게 줄인 것 같지 않아도, 심리적 임계선인 4초를 넘기느냐가 인상에 결정적이다.

또 다른 사례는 스타트업의 모바일 팀이었다. 팀원들이 지하철에서 이슈를 확인하는데, 터널 구간에서 5G 아이콘이 떠 있어도 실제로는 고지연 상태가 빈번했다. 간헐적인 타임아웃이 이어지자, 이들은 키탐넷을 열면 먼저 오프라인 친화 모드로 들어가도록 제안했다. 네트워크 상태가 좋지 않으면 읽기 전용으로 최근 동기화된 데이터를 보여주고, 연결이 회복되면 변경 사항을 당겨오는 방향이다. 이 전환으로 “불안정할 때도 쓰긴 된다”는 신뢰가 생겼다. 절대 속도를 높이지 않아도, 끊어지지 않는 경험은 속도로 인지된다.
향후 개선의 초점
이번 벤치마크에서 정리한 환경별 병목은 크게 네 트랙으로 모인다. 초기 페이로드를 더 작게, 더 단단한 캐시 전략, 변동성 높은 네트워크에서의 회복력, 그리고 사람의 인지에 맞춘 피드백 설계다. 가까운 시일에 계획된 작업으로는, 라우트별 코드 스플릿 고도화, 이미지 전송 경로의 AVIF 우선 전환, 검색 API의 서버 측 스트리밍 응답, 업로드 경로의 멀티파트 병렬화가 있다. 키스타임, 키스타임넷과 공통으로 사용하는 SDK도 이를 뒷받침하도록 업데이트된다. 제품군 간 일관된 성능 모델을 갖추면, 한쪽에서의 개선이 다른 쪽에서도 곧장 체감 품질로 번진다.
실무자 메모, 환경별 디버깅 순서
문제가 보고되면, 재현보다 분류가 먼저다. 다음 순서는 현장에서 반복 검증하며 다듬은 체계다.
네트워크 품질 측정부터 시작한다. 왕복 지연, 패킷 손실률, 지터를 30초만 재도 실마리가 생긴다. 캐시 상태를 확인한다. 서비스 워커 버전, 강한 캐시 헤더, 조건부 요청이 꼬였는지 본다. 브라우저 확장과 보안 프로그램의 후처리를 끈 채 비교한다. CPU, 디스크, 전원 상태를 점검한다. 특히 업로드와 대형 번들 파싱에 영향이 크다. 시간대와 장소의 상관을 본다. 반복 패턴이 보이면 CDN, 라우팅 이슈일 가능성이 높다.
이 순서를 따르면 원인에 닿기까지 걸리는 시간이 짧아진다. 무엇보다 재현 스크립트를 만들기 쉬워진다.
맺음없는 결론 대신, 관찰의 요령
성능은 절대값과 상대감이 얽힌 주제다. 같은 2.5초라도 깜빡임 없이 차오르는 2.5초는 짧게 느껴지고, 멈칫거리는 2.0초는 길게 느껴진다. 이번 측정에서 배운 점은 한 줄로 요약된다. 빠르게 만드는 일과 빠르게 느껴지게 만드는 일은 맞닿아 있지만, 완전히 같지는 않다. 키탐넷의 실사용 경로에 맞춰 병목을 분해하고, 환경별로 가장 큰 체감 이득을 주는 조치를 선택하는 것, 그게 꾸준히 속도를 올리는 가장 현실적인 방법이다. 그리고 이 판단은 수치만으로는 부족하다. 로그와 그래프 사이에 있는 사람의 리듬을 들여다봐야 한다.