삐- 삐리리리- 치이이익, 그 소리 기억하시나요?
56k.rip은 이름 그대로 1996년 무렵의 다이얼업 인터넷을 다시 겪어 보게 해주는 사이트예요. 다이얼업은 전화선으로 인터넷에 접속하던 방식을 말해요. 30대 후반 이상이라면 모뎀이 전화를 걸면서 '삐- 삐리리리- 치이이익' 하는 소리를 내고 PC통신에 접속하던 기억이 있을 거예요. 그보다 어린 분들한테는 거의 옛날이야기처럼 들릴 텐데요. 그냥 추억을 떠올리는 사이트처럼 보이지만, 웹 성능을 고민하는 개발자라면 꽤 진지하게 생각해 볼 거리가 있거든요. 오늘은 '56k'가 정확히 무슨 뜻이었는지부터, 그 시절의 제약이 지금 웹 개발에 어떤 흔적을 남겼는지까지 하나씩 풀어볼게요.
56k는 왜 하필 56k였을까
56k는 초당 56킬로비트, 즉 56kbps를 뜻해요. 바이트로 바꾸면 이론상 초당 7KB 정도인데요. 실제로는 초당 4~5KB만 나와도 잘 나오는 편이었어요.
그럼 왜 하필 56이라는 애매한 숫자였을까요? 이게 뭐냐면, 전화망 구조 때문이에요. 집까지 들어오는 전화선은 아날로그였지만, 전화국끼리 연결하는 간선망은 그때 이미 디지털이었거든요. 전화 음성을 디지털로 바꿀 때는 1초에 8,000번 소리를 측정하고(이걸 샘플링이라고 해요), 한 번 측정할 때마다 8비트로 기록해요. 그래서 8,000 × 8 = 64kbps가 나오죠. 그런데 미국식 디지털 회선(T1)은 이 8비트 중 1비트를 가끔 회선 제어 신호용으로 빌려 썼어요. 그래서 믿고 쓸 수 있는 건 7비트뿐이었어요. 8,000 × 7 = 56,000, 여기서 56k가 나온 거예요.
재밌는 건 업로드 속도는 33.6kbps 정도에 머물렀다는 점이에요. 다운로드는 인터넷 업체 쪽 장비가 디지털 회선에 바로 붙어 있어서 변환 손실 없이 보낼 수 있었어요. 반면 업로드는 우리 집의 아날로그 신호를 전화국이 디지털로 바꾸는 과정에서 잡음(양자화 잡음)이 생겨서 속도를 더 올리기 어려웠거든요. 게다가 미국에서는 전화선 출력 제한 규정 때문에 다운로드도 실제로는 53kbps 근처가 한계였어요. '최대 56k'는 말 그대로 이론상의 최대치였던 거죠.
그 유명한 접속음도 사실 의미가 있는 대화였어요. 두 모뎀이 '너는 어떤 규격을 지원해?', '이 전화선 상태는 어때?' 하고 협상하는 소리를 우리가 스피커로 듣고 있었던 거예요. 회선 품질을 확인하고, 에코 제거 기능을 조정하고, 서로 맞출 수 있는 가장 빠른 속도를 정하는 과정이었죠.
숫자로 느껴 보는 1996년의 속도
실제 속도를 초당 5KB로 잡아볼게요. 요즘 웹페이지 하나는 이미지, 자바스크립트, 폰트까지 합치면 중간값이 2MB를 훌쩍 넘어요. 2.5MB짜리 페이지를 초당 5KB로 받으면 약 500초, 그러니까 8분이 넘게 걸려요. 뉴스 기사 하나 열려고 컵라면 두 개 끓일 시간을 기다려야 하는 셈이죠. 요즘 프론트엔드 앱은 자바스크립트 번들 하나만 수백 KB인 경우가 많아서, 화면에 첫 글자가 뜨기도 전에 1분이 훌쩍 지나가요.
다이얼업은 대역폭만 좁았던 게 아니에요. 지연 시간(latency, 요청을 보내고 첫 응답이 올 때까지 걸리는 시간)도 길었어요. 서버와 요청을 여러 번 주고받아야 하는 요즘 웹 구조였다면 그 지연이 계속 쌓였겠죠. 그리고 무엇보다, 인터넷을 쓰는 동안 집 전화가 불통이었어요. 엄마가 '전화 좀 쓰자!' 하고 외치면 접속을 끊어야 하던 시절이었죠. 국내에서는 01410 같은 접속 번호로 PC통신에 들어가던 때라, 전화 요금이 무서워서 밤에만 접속하는 분들도 많았고요.
그 시절 제약이 지금 웹에 남긴 흔적
흥미로운 건, 느린 회선을 버티려고 만든 기술들이 지금도 웹 곳곳에 남아 있다는 거예요.
대표적인 게 프로그레시브 JPEG과 인터레이스 GIF예요. 이미지를 위에서부터 한 줄씩 그리는 대신, 흐릿한 전체 모습을 먼저 보여주고 점점 선명하게 만드는 방식이죠. 요즘 많이 쓰는 blur placeholder(이미지가 로딩되기 전에 흐릿한 미리보기를 보여주는 기법)의 원조라고 할 수 있어요.
img 태그의 width, height 속성도 마찬가지예요. 이미지를 다 받기 전에 브라우저가 미리 자리를 잡아둘 수 있게 해주는 속성인데요. 그 시절에는 이미지가 오는 동안 텍스트라도 먼저 읽게 하려고 썼어요. 지금은 구글 Core Web Vitals 지표 중 하나인 CLS(페이지 레이아웃이 갑자기 밀려나는 정도)를 줄이는 기본기로 다시 강조되고 있죠.
HTML을 받는 대로 바로 그려 주는 점진적 렌더링도 원래는 느린 회선에서 사용자가 빈 화면만 보고 있지 않게 하려고 만든 설계였어요. 요즘 서버 컴포넌트나 스트리밍 SSR이 '먼저 보여줄 수 있는 것부터 보낸다'는 원칙을 다시 내세우는 걸 보면, 기술은 정말 돌고 돈다는 생각이 들어요.
업계 맥락: 웹은 정말 빨라졌을까
회선 속도는 수천 배 빨라졌지만, 웹페이지도 그만큼 무거워졌어요. 그래서 체감 속도는 생각만큼 빨라지지 않았다는 얘기가 꾸준히 나와요. 구글이 Core Web Vitals를 검색 순위에 반영하고, 프레임워크들이 번들 크기 줄이기와 부분 하이드레이션(페이지 전체가 아니라 필요한 부분만 자바스크립트로 동작하게 만드는 방식)에 힘을 쏟는 것도 결국 같은 고민에서 나온 거예요. 56k.rip 같은 사이트는 이 문제를 극단적인 방식으로 직접 느끼게 해준다고 볼 수 있어요.
한국 개발자에게 주는 시사점
한국은 세계에서 손꼽힐 만큼 인터넷이 빠른 나라예요. 그런데 바로 그 점 때문에 개발자가 느린 환경을 떠올리기 어렵다는 함정이 있어요. 사무실 기가 인터넷과 최신 노트북에서는 멀쩡한 서비스도 지하철 터널이나 엘리베이터 안에서는 한참 버벅일 수 있거든요. 데이터 속도 제한이 걸린 요금제를 쓰는 사용자나 해외 사용자도 마찬가지고요.
당장 해볼 수 있는 방법은 간단해요. 크롬 개발자 도구의 Network 탭에서 throttling 설정을 열면 느린 네트워크를 흉내 낼 수 있어요. 커스텀 프로필을 만들어서 다운로드 56kbps, 업로드 33kbps를 직접 넣어볼 수도 있고요. 이 속도에서 내 서비스의 첫 화면이 몇 초 만에 뜨는지 한 번만 확인해 보세요. 생각보다 충격적일 수 있어요. Lighthouse 점수를 보는 것보다 훨씬 강하게 최적화할 마음이 생길 거예요.
마무리
한 줄 정리: 56k 시절의 제약은 사라졌지만, 사용자가 기다리는 시간을 줄여야 한다는 숙제는 그대로예요.
여러분 서비스의 메인 페이지는 56k 모뎀으로 열면 몇 분이 걸릴까요? 느린 환경의 사용자를 위해 지금 팀에서 실제로 챙기고 있는 최적화가 있다면 댓글로 나눠주세요.
🔗 출처: Hacker News