서울에서 접속한 사용자가 미국 버지니아의 서버까지 신호를 보내고 받는 데는 물리적으로 왕복 200밀리초가 넘게 걸린다. 빛의 속도는 협상 대상이 아니기 때문이다. 그 지연을 없애는 가장 확실한 방법은 서버를 사용자 가까이로 옮기는 것이다. 엣지 컴퓨팅은 바로 이 단순한 물리학에서 출발한다.
전통적인 CDN은 이미지나 CSS 같은 정적 파일을 전 세계 수백 개 거점에 복제해 가까운 곳에서 내려줬다. 엣지 함수는 여기서 한 걸음 더 나아간다. 캐시된 파일을 주는 데 그치지 않고, 그 거점에서 코드를 실행한다. 사용자 인증, 지역별 분기, A/B 테스트 같은 로직이 중앙 서버를 거치지 않고 사용자에게서 수십 밀리초 거리에서 처리된다.
규모를 보면 이 변화의 무게가 실감 난다. 클라우드플레어는 전 세계 330여 개 도시에 거점을 두고, 어떤 사용자든 평균 50밀리초 안에 닿을 수 있는 위치에서 코드를 돌린다. 과거라면 한국 사용자의 요청이 미국까지 갔다 돌아오며 200밀리초 이상을 소모했을 처리가, 이제는 서울 거점에서 끝난다. 거리가 짧아진 만큼 응답은 빨라지고, 중앙 서버의 부하도 줄어든다. 같은 코드가 어디서 실행되느냐에 따라 사용자가 체감하는 속도가 네 배 가까이 벌어지는 것이다.
서버리스와 엣지는 무엇이 다른가
둘 다 서버를 직접 관리하지 않는다는 점은 같지만 실행 위치와 환경이 다르다. AWS 람다 같은 전통적 서버리스는 특정 리전의 데이터센터에서 돌아가며, 콜드 스타트 때 수백 밀리초의 지연이 생기기도 한다. 반면 클라우드플레어 워커스나 버셀 엣지 함수는 V8 아이솔레이트라는 가벼운 격리 단위로 동작해 콜드 스타트가 사실상 1밀리초 수준이고, 전 세계 거점에서 동시에 실행된다.
대신 엣지에는 제약이 따른다. 실행 시간과 메모리가 빠듯하고, 무거운 라이브러리나 네이티브 바이너리를 쓰기 어렵다. 무엇보다 데이터베이스가 한 리전에 있다면, 엣지에서 가까워진 만큼 DB까지의 거리가 다시 병목이 된다. 서울 거점에서 1밀리초 만에 코드가 깨어나도, 그 코드가 미국 동부의 데이터베이스를 호출한다면 결국 왕복 200밀리초를 다시 치러야 한다. 그래서 최근에는 데이터마저 엣지 가까이로 분산하는 시도가 늘고 있다. 클라우드플레어의 D1이나 KV, 분산 데이터베이스 서비스들이 그 방향이다. 그래서 엣지는 만능 해법이 아니라, 가벼운 로직과 빠른 응답이 필요한 경계에 어울리는 도구다.
지연시간은 곧 매출이다
구글의 Core Web Vitals는 이 흐름을 비즈니스 언어로 번역한다. 첫 콘텐츠가 그려지는 LCP, 상호작용 반응성을 보는 INP, 화면 흔들림을 재는 CLS. 이 지표들은 검색 순위에 직접 반영된다. 측정값은 냉정하다.
- 아마존은 페이지 로딩이 100밀리초 느려질 때마다 매출이 약 1퍼센트 감소한다고 밝힌 바 있다
- 구글은 모바일 페이지 로딩이 1초에서 3초로 늘면 이탈률이 32퍼센트 증가한다고 보고했다
- 핀터레스트는 체감 대기시간을 40퍼센트 줄이자 검색엔진 트래픽과 가입이 15퍼센트 늘었다
속도는 더 이상 엔지니어링 부서의 내부 지표가 아니다. 그것은 인도네시아의 사용자와 독일의 사용자가 같은 회사를 다른 품질로 경험하게 만드는, 가장 조용한 형태의 차별이다.
물론 트레이드오프는 분명하다. 엣지에 로직을 분산하면 장애가 어디서 났는지 추적하기 어려워지고, 캐시 무효화는 더 까다로워지며, 전 세계에 흩어진 데이터의 일관성을 지키는 일이 복잡해진다. 글로벌하게 분산된 상태를 관리하는 비용은 결코 작지 않고, 잘못 설계하면 오히려 느려지거나 데이터가 어긋날 위험도 있다. 그럼에도 사용자가 어디에 있든 200밀리초 안에 응답하는 웹과 그렇지 못한 웹의 격차는 점점 벌어지고 있다. 현명한 팀은 모든 것을 엣지로 옮기는 대신, 응답 속도가 곧 매출인 길목만 골라 경계로 내보낸다. 속도의 기준선이 중앙에서 경계로 옮겨가는 지금, 어디서 코드를 실행할 것인가는 더는 인프라 담당자만의 질문이 아니다.