AI 시대, 진짜 개발자는 "이 숫자"를 알아야 살아남는다!
코딩, AI 시대에도 숫자로 말해야 하는 이유
요즘은 누구나 코딩을 할 수 있다고 하지만, 진짜 개발은 단순히 코드를 짜는 것 이상이야. AI가 코드를 써주는 시대에도 진짜 개발자라면 꼭 알아야 할 '숫자 감각'이 있어. 바로 코드와 아키텍트를 가르는 중요한 감각이지.
느리다, 빠르다는 숫자로 말해야 해!
회의 중에 주니어 개발자가 데이터베이스 조회가 느려서 캐시 도입을 제안했어. 그런데 시니어 개발자가 "DB 응답이 얼마나 느린데요? 캐시로 얼마나 빨라질까요?"라고 물었지. 이때 "음... 그건..." 하고 말끝을 흐리면 안 돼. '느리다', '빠르다'는 느낌이 아니라 숫자로 객관적으로 말할 수 있어야 해.
코드와 아키텍트의 차이, 숫자로 말하는 능력
코드와 아키텍트의 차이는 코드를 잘 쓰는 게 아니라, 근거 있는 의사결정을 할 수 있느냐에 달려있어. AI가 코드를 잘 만들어 주지만, 진짜 개발자, 아키텍트는 그 결정에 대한 근거와 기준이 있어야 하고, 그걸 바탕으로 의사결정을 할 수 있어야 해.
오늘은 그 의사결정의 기준이 되는 '레이턴시 넘버'에 대해 알아볼 거야. 모든 개발자가 알아야 할 핵심 레이턴시 수치들이지. 이 수치들은 백엔드와 시스템 설계할 때 전 세계적으로 널리 인용되는 레퍼런스야.
모든 개발자가 알아야 할 숫자: 컴퓨터 시스템의 시간 비용
이 표는 컴퓨터 시스템의 주요 연산에 걸리는 시간을 숫자로 정리한 거야. 이걸 보면 컴퓨터 시스템의 '시간 비용'에 대한 기본적인 감각을 기를 수 있어.
- 누가 만들었을까?
- 피터 노빅 (Peter Norvig): 2001년에 시작했어. AI 교과서 저자로 유명하지.
- 제프 딘 (Jeff Dean): 2009년에 확장했어. 구글의 전설적인 엔지니어지.
- 콜린 스콧 (Collin Scott): 2020년에 연도별 시각화를 업데이트했어.
이 수치들은 컴퓨팅 시스템의 시간 비용, 즉 CPU, 메모리, 디스크, 네트워크 같은 것들이 얼마나 시간이 걸리는지를 정량화한 거야.
이 수치, 왜 중요할까? 권위 있는 자료들이 인용하는 이유
이 표는 백엔드의 바이블이라 불리는 DDI, 100만 부 이상 팔린 시스템 디자인 면접 책, ACMQ, 구글 리서치, 코넬 대학교 학술 자료 등 소프트웨어 개발 분야에서 권위 있는 자료들이 공통으로 참조하고 있어.
이 표가 답해주는 질문들
- 캐시를 도입할 가치가 있을까?
- 네트워크 호출을 한 번 줄이면 얼마나 빨라질까?
- 데이터를 메모리에 두는 게 정말 그렇게 큰 차이가 날까?
- 리전을 분리하면 응답이 얼마나 느려질까?
- SSD가 RAM의 대안이 될 수 있을까?
이런 아키텍처 설계에 관한 질문들에 이 수치로 답할 수 있어.
누가, 언제, 왜 만들었을까?
- 피터 노빅 (2001년): 스탠퍼드와 구글에서 활동하며 처음 제안했어. 프로그래밍 독학 책들을 비판하며 진짜 프로그래밍은 10년이 걸린다는 에세이의 부록으로 이 표를 포함시켰지.
- 제프 딘 (2009년): 구글의 경험을 바탕으로 분산 시스템에 맞게 확장했어. "시스템 성능을 만들지 않고도 추정할 수 있는 능력"이 중요하다고 말했지.
- 콜린 스콧 (2012년부터): 시간에 따른 변화까지 반영해서 시각화했어.
이 수치와 표는 한 사람의 천재성이 아니라 업계 전체가 함께 다듬어온 '공룡 자산'이라고 할 수 있어.
피터 노빅의 11가지 레이턴시 (2001년)
- CPU 명령 실행: 1 나노초 (ns)
- L1 캐시 참조: 0.5 ns
- L2 캐시 참조: 7 ns
- 메인 메모리 참조: 100 ns
- 1KB 데이터 네트워크 전송 (1Gbps): 20 마이크로초 (µs)
- 1MB 데이터 메모리 순차 읽기: 250 µs
- 디스크 탐색 (HDD): 8 밀리초 (ms)
- 디스크 탐색 (SSD): 20 ms (이후 추가됨)
- 미국-유럽 패킷 왕복 (네트워크): 150 ms
핵심은 정확한 수치 암기가 아니라 '차수'의 감각이야.
CPU는 1ns, 메모리는 100ns, 디스크는 8ms, 네트워크는 150ms. 나노초, 마이크로초, 밀리초의 차이를 아는 감각이 중요해. 이 감각이 있으면 어떤 새로운 기술이 나와도 비용을 추정할 수 있지.
제프 딘의 확장: 분산 시스템과 SSD의 시대 (2009년)
제프 딘은 피터 노빅의 표에 몇 가지를 추가했어.
- 1KB 데이터 압축 (Gzip): 3 µs (압축 후 전송하면 8µs vs 그냥 전송 10µs. 압축이 이득!)
- SSD 레이턴시: 4KB 랜덤 읽기, 1MB 순차 읽기
- 데이터센터 내부 왕복 (RTT): 500 µs
이 수치들은 분산 시스템과 SSD 시대의 관점을 반영한 거야.
콜린 스콧의 시각화: 시간의 흐름에 따른 변화
콜린 스콧은 하드웨어 발전 속도를 공식화해서 연도별 레이턴시를 시각화했어.
- 핵심 가치: 상대적 격차를 시각화했다는 것. CPU 캐시, 메모리, SSD, 디스크, 네트워크의 순서는 시간이 지나도 변하지 않음을 보여줘.
- 한계: 메모리나 네트워크처럼 개선 속도가 제한적인 영역은 실제 수치와 차이가 날 수 있어. 하지만 중요한 건 정확한 수치보다 레이턴시의 차수, 규모, 관계를 이해하는 것이야.
실무에서 이 숫자를 어떻게 활용할까?
이 수치들은 시스템 설계 시 '감각'을 만들어줘. 직접 만들기 전에 추정할 수 있게 해주는 거지.
- 캐시 도입 의사결정: HDD 디스크 탐색 10ms vs Redis 메모리 조회 나노초. 차수가 다르니 캐시 도입 가치가 있지! (물론 SSD 기반 DB라면 상황이 달라지겠지만)
- 마이크로 서비스 분리의 진짜 비용: 로컬 함수 호출 나노초 vs 데이터센터 내부 통신 마이크로초. 10만 배 이상 차이나! 무조건 분리가 답은 아니야.
- 시스템 디자인 면접: 초당 100만 건 요청 처리 시스템 설계? 메모리 조회 100ns (이론상 1000만 QPS 가능), 디스크 조회 밀리초 (단일 서버 한계), 네트워크 호출 500µs (호출 줄여야 함). 이 감각으로 캐시, 샤딩, 호출 최소화 이유를 설명할 수 있지.
주의할 점
- 정확한 수치 외우지 마세요: 차수 수준의 근사값이야. 중요한 건 나노초, 마이크로초, 밀리초의 '차이' 감각.
- 몇 개만 외워도 좋아요: L1 캐시, 메인 메모리, SSD, 데이터센터 RTT, 디스크, 대륙간 패킷 전송 비용 정도만 알아도 충분해.
- 절대적인 값에 매달리지 마세요: 상대적인 격차, 즉 '몇 배 빠른가'가 중요해.
- 레이턴시만 전부는 아닙니다: 처리량(Throughput)도 함께 고려해야 해.
AI 시대, 아키텍트의 중요성
AI가 코드를 써주는 시대일수록, '기본'을 이해하고 '중요한 것'에 집중하는 능력이 더욱 중요해져. AI는 도구일 뿐, 운전대를 잡는 건 결국 사람이야.
AI 코딩 시대일수록 오히려 아키텍트의 영향력이 진짜 경쟁력이 될 거야. 남들이 쉬운 길만 찾을 때, 우리는 본질을 이해하는 역량을 키우자.