Foundations - 01. 인프라 아키텍처란 무엇인가

dongka · 2026. 7. 21. 18:40

인프라는 도시의 도로망과 같다 — 한 번 깔면 바꾸기 어렵다

2017년 2월 28일, 미국 동부 시간 오전 9시 37분. 한 AWS 엔지니어가 S3 청구 시스템 디버깅을 위해 표준 절차에 따라 명령 하나를 실행했다. 문법은 맞았지만 대상이 조금 달랐다. 그 한 번의 명령이 S3 인덱스 서브시스템의 용량을 계산하는 데 필요한 서버를 대거 오프라인으로 만들었다. 이후 약 4시간 동안 Slack, Trello, Quora, 이미지 호스팅 서비스들이 줄줄이 멈췄다. 인터넷의 상당 부분이 한 리전의 한 서브시스템 장애에 종속돼 있었다는 게 그제야 드러났다.

이 사건이 보여주는 핵심은 "AWS가 부실했다"가 아니다. 오히려 AWS는 그 장애를 4시간 안에 복구하며 1차 사고 보고서를 당일에 공개했고, 며칠 뒤 상세 postmortem까지 냈다. 핵심은 다른 데 있다 — 수만 개의 서비스가 자기가 올라간 인프라에 대해 세운 가정이 얼마나 깊은지, 그 인프라가 무너지는 순간 어떻게 연쇄되는지를 이 사건이 보여준다는 것이다. 인프라가 견고하면 위에 올라간 서비스가 복잡해도 단순하게 동작한다. 인프라가 흔들리면 가장 단순한 서비스도 무너진다.

새로운 도시가 생겼다고 상상해 보자. 먼저 뼈대가 깔린다 — 도로, 상수도, 하수도, 전기망, 통신선. 그 위에 건물이 올라가고, 건물 안에 사람이 들어가 살기 시작한다. 어느 날 도시가 10배 커졌는데 출퇴근길이 한 시간이 걸린다고 치자. 이때 "도로를 다시 깔자"고 결정하면 어떻게 될까. 이미 선 도로 위에 세워진 건물을 허물고, 지하에 묻힌 상수도를 옮기고, 전기망을 재배선해야 한다. 기술적으로 가능할지 몰라도 비용은 도시를 처음부터 다시 짓는 수준이다. 그래서 도시 계획자는 건물이 올라가기 전에 도로망을 설계한다. 나중에 바꾸기 너무 비싸기 때문이다.

소프트웨어 인프라도 같은 구조를 갖는다. 서버, 네트워크, 저장소, 전원, 냉각 — 이 "밑에 있는 것들"이 애플리케이션이라는 건물을 받친다. 클라우드 버튼 한 번이 서버 한 대를 만들어 주지만, 그 버튼이 "인프라를 자동으로 설계해 주는" 건 아니다. 누군가 가용 영역(availability zone)을 나누고, 서브넷을 잡고, 보안 그룹을 열고, 로드 밸런서를 앞에 세운 결정이 그 버튼 안에 이미 들어 있다. 그 결정을 안 하면 어쩌다 생긴 구조가 팀을 짓누른다. 이 글이 다루는 질문은 하나다 — 인프라는 왜 "공학"의 대상이 되는가.

인프라의 어원이 알려주는 본질

인프라(infrastructure)라는 단어는 라틴어 infra(아래)와 structura(구조)가 합쳐진 말이다. 직역하면 "밑에 있는 구조"다. 1920년대 프랑스에서 철도·도로·교량 같은 영구적인 공공 시설을 부르던 단어가 1980년대에 들어와 컴퓨터 시스템의 "밑단"을 가리키는 말로 넘어왔다. 어원이 말해주는 핵심은 두 가지다. 하나는 밑에 있다는 것, 다른 하나는 구조라는 것.

밑에 있다는 건, 위에 올라간 것(애플리케이션)이 잘 동작하려면 이 층이 먼저 안정적으로 깔려 있어야 한다는 뜻이다. 구조라는 건, 단순한 부품의 집합이 아니라 부품 사이의 관계가 정해진 형태라는 뜻이다. 스위치 하나, 서버 한 대는 부품이다. 이 스위치와 서버가 어떻게 연결되고, 어디에 중복을 두고, 장애가 났을 때 어디까지 전파되는지를 정한 것이 구조다. 인프라를 논한다는 건 부품 목록을 나열하는 게 아니라 이 관계와 경계를 다루는 일이다.

이 관점을 적용하면 "인프라를 잘 모른다"는 말의 의미가 달라진다. 한 대의 서버에 리눅스를 깔 줄 안다고 인프라를 아는 게 아니다. 그 서버가 연결된 네트워크가 장애 났을 때 어떤 일이 벌어지는지, 디스크가 가득 차면 위에서 도는 데이터베이스가 어떻게 반응하는지, 전원이 한 번 떨어졌을 때 메모리에 있던 데이터가 어떻게 되는지까지가 인프라를 이해한다는 것이다.

추상화 계층 — 왜 그렇게 겹쳐 놓았나

리눅스 서버 한 대에 SSH로 들어가 lscpu를 치면 CPU 종류가 보인다. 거기에 ip addr을 치면 네트워크 인터페이스가 보인다. lsblk를 치면 블록 장치가 보인다. 이 세 명령이 보여주는 것이 같은 컴퓨터라는 게 믿기 어려울 만큼 서로 다른 세계처럼 보인다. CPU는 실리콘 수십억 개의 트랜지스트고, 네트워크 인터페이스는 전기 신호를 받아 숫자로 바꾸는 회로고, 블록 장치는 자성을 이용해 데이터를 저장하는 판이다. 그런데 이 셋이 같은 컴퓨터 안에서 어우러져 돌아간다.

이것이 가능한 이유는 추상화 계층(abstraction layer) 때문이다. 아래 층의 복잡함을 위 층에서 단순한 인터페이스로 가리고, 위 층은 아래 층이 어떻게 구현됐는지 모른 채로 자기 일을 한다. 현대 인프라는 이런 겹이 수십 개 쌓인 형태다.

flowchart TD
    APP["애플리케이션<br/>(nginx, PostgreSQL, 내 서비스)"] --> RT["런타임·컨테이너<br/>(JVM, containerd, OCI)"]
    RT --> OS["운영체제<br/>(Linux 커널, systemd)"]
    OS --> VM["가상화 계층<br/>(KVM, hypervisor) - 클라우드인 경우"]
    VM --> HW["하드웨어<br/>(CPU, 메모리, NIC, 디스크)"]
    HW --> FAC["물리 시설<br/>(전원, 냉각, 랙, 회선)"]

각 층을 한 번씩 내려다보자. 초심자에게 가장 도움이 되는 건 "이 층이 바로 아래 층에 대해 세우는 가정"을 보는 것이다. 어느 층이든, 그 층은 바로 아래 층만 신뢰한다. 그 아래아래는 보지 않는다.

애플리케이션은 "디스크에 쓴 데이터는 전원이 꺼져도 살아 있다"고 가정한다. 데이터베이스 엔진이 fsync()를 부르면 그 아래 누군가가 영속성을 보장해 줄 거라고 믿는다. 그 아래가 진짜 물리 디스크인지, 클라우드의 EBS 같은 네트워크 블록 스토리지인지, 아니면 메모리를 디스크처럼 보이게 하는 RAM 디스크인지는 묻지 않는다. 묻는 순간 성능과 단순함이 같이 무너진다.

런타임·컨테이너는 "내가 받은 CPU·메모리는 전부 내 것"이라 가정한다. JVM이 힙을 잡을 때, containerd가 컨테이너에 2GB를 줬으면 그 2GB가 온전히 자기 것이라 믿는다. 그 아래 cgroup이나 KSM(커널 동일 페이지 병합)이 메모리를 실제로 어떻게 다루는지는 모른다. 이 추상이 깨지는 순간 — 예를 들어 컨테이너가 자기가 가진 줄 알았던 메모리가 실제로는 다른 컨테이너와 공유되고 있었다 — 곧 OOM(Out of Memory)으로 이어진다.

운영체제(커널) 는 "하드웨어가 내가 이해하는 대로 동작한다"고 가정한다. CPU 인터럽트, DMA, 페이지 폴트가 명세대로 일어난다고 믿는다. 그런데 클라우드 환경에서 그 "하드웨어"는 사실 하이퍼바이저가 만들어낸 가상 하드웨어다. CPU는 진짜 Intel이나 AMD이지만, 네트워크 카드·디스크 컨트롤러는 KVM·Xen이 흉내 낸 것이다. 커널은 이 차이를 대부분 모른다 — 가상화가 잘 됐다는 건 곧 "거짓말을 잘 했다"는 뜻이다.

하드웨어는 "전원이 안정적이고 냉각이 된다"고 가정한다. CPU가 95도까지 올라가면 스로틀링을 하고, 전압이 떨어지면 오작동을 한다. 그 아래 물리 시설(PDU·UPS·HVAC)은 이 가정을 지탱하는 마지막 층이다. 데이터센터 냉각이 멈추면 서버가 5분 안에 꺼진다. 클라우드를 쓴다고 이 층이 사라지는 게 아니라 — 누군가 다른 팀(AWS·GCP 인프라 팀)이 그 층을 관리해 줄 뿐이다.

이 계층을 왜 이렇게 겹쳐 놓았을까. 한 번에 모든 걸 다루면 너무 복잡해서다. CPU 설계자는 전기 신호의 타이밍을 나노초 단위로 맞추는 데 집중하고, 커널 개발자는 그 CPU를 "프로세스 스케줄러"라는 추상으로 가공하고, 클라우드 엔지니어는 그 커널 위에 "가상 머신"이라는 추상을 올린다. 각 층은 바로 아래 층만 알면 된다. 이 "관심사의 분리"가 없으면 현대 인프라의 복잡함은 감당이 안 된다.

다만 추상화는 무료가 아니다. 각 층은 위에 비용을 부과한다 — 지연(latency), 자원 오버헤드, 디버깅 난이도. 컨테이너는 VM보다 가볍지만 커널을 공유해서 격리가 약하다. VM은 완전한 격리를 주지만 하이퍼바이저 오버헤드가 있다. 베어메탈은 가장 빠르지만 한 대를 띄우는 데 수십 분이 걸린다. 어느 추상화 계층에서 멈출 것인가가 인프라 설계의 근본 질문 중 하나다. 답은 항상 "그때그때 다르다"이며, 트레이드오프의 형태로 나타난다.

역사 박스 — 하드웨어 가상화는 1960년대 IBM 메인프레임(CP-40·CP-67)에서 처음 등장했다. 한 비싼 메인프레임을 여러 부서가 나눠 쓰기 위해 만들어진 기술이었다. 2000년대 x86 서버에 다시 등장해(VMware·Xen·KVM) 클라우드의 기반이 됐고, 2010년대엔 컨테이너라는 더 얇은 추상화가 인기를 끌었다. 같은 문제(한 하드웨어를 여러 워크로드가 나눠 쓰기)를 푸는 서로 다른 무게의 해법이다.

되돌리기 비용이 인프라 결정을 무겁게 만든다

소프트웨어 아키텍처의 한 줄 요약은 "되돌리기 어려운 결정을 다루는 일"이다. 인프라 아키텍처는 여기에 한 가지가 더 붙는다 — 물리적 제약. 코드는 git revert 한 번이면 되지만, 랙에 꽂힌 서버 100대의 배치를 바꾸려면 물리적으로 서버를 옮겨야 하고, 데이터센터에 깔린 광케이블을 바꾸려면 바닥을 뜯어야 한다. 클라우드 시대에도 이 제약은 사라지지 않았다 — 리전(region)을 바꾸는 건 데이터를 수 테라바이트 옮기는 일이고, 한 번 깐 VPC의 CIDR 블록을 바꾸면 그 안의 모든 리소스 IP가 바뀌어야 한다.

되돌리기 비용이 비싸면, 그 결정은 더 일찍, 더 신중하게 내려야 한다. Richards와 Ford가 (2020)에서 "중요하면서도 변경이 어려운 결정들의 모음"이라 부른 것을 인프라에 적용하면 이런 것들이 해당된다.

베어메탈로 갈까, 가상화로 갈까, 컨테이너로 갈까
단일 데이터센터로 시작할까, 처음부터 멀티 AZ로 갈까
온프레미스에 투자할까, 퍼블릭 클라우드에 올릴까
IPv4만 쓸까, IPv6까지 열어둘까
전용 회선을 계약할까, 인터넷 VPN으로 갈까

결정	되돌림 비용	왜 비싼가
컨테이너 이미지 베이스 변경(ubuntu → alpine)	낮음	재빌드 후 재배포, 자동화 가능
단일 AZ → 멀티 AZ 전환	중간	리소스 복제 + 데이터 동기화 설계
IPv4 전용 → IPv6 듀얼스택	높음	모든 서비스·방화벽·LB·모니터링 재검증
온프레미스 → 클라우드 마이그레이션	매우 높음	데이터 이동 + 네트워크 재설계 + 비용 모델 재구성
단일 리전 → 멀티 리전 active-active	매우 높음	데이터 일관성·지연·비용 구조 전면 재설계
데이터센터 물리 이전	사실상 불가능	계약·이관·검증에 수개월~수년, 도중에 운영 유지

이 표에서 아래로 갈수록 "나중에 바꾸자"로 미뤘을 때의 부채가 기하급수적으로 커진다. 데이터센터 물리 이전은 아예 되돌림이라는 개념이 성립하지 않는다 — 한 번 옮기면 원래 건물로 돌아갈 수 없다. 그래서 인프라 결정은 다른 어떤 결정보다 "지금 안 하면 나중에 훨씬 비싸진다"는 압박을 받는다.

이게 추상적인 경고가 아니라는 건 실제 사례들에서 확인된다. 2022년 소프트웨어 회사 37signals(Basecamp·HEY 개발사)가 클라우드에서 온프레미스로 돌아가겠다고 발표했을 때, 그들은 단순한 환경 선호를 말한 게 아니었다. 5년간 클라우드 비용이 수백만 달러로 쌓인 뒤, 베어메탈을 사고 전용 회선을 계약하고 두 명의 SRE를 고용하는 게 클라우드 비용의 절반 수준이라는 계산이 섰다. 다만 그 결정은 1년이 넘는 마이그레이션 기간과 데이터 이동, 일시적 서비스 중단을 감수해야만 성립했다. "처음부터 베어메탈로 갈 걸"이 사후 평가가 될 수밖에 없는 이유다. 반대로 클라우드가 정답인 경우도 많다 — 트래픽이 불규칙하거나, 초기 자본이 부족하거나, 글로벌 확장이 핵심인 경우. 정답이 하나가 아니라 어느 시점에 어느 결정이 되돌리기 비싼가를 묻는 게 진짜 질문이다.

한 가지 주의할 게 있다. 비용이 비싸다고 모든 결정을 처음부터 완벽하게 하려 들면 안 된다. 완벽주의는 보통 과잉 설계(over-engineering)로 끝난다 — 트래픽이 하루 1만 건인데 초당 100만 건을 감당하도록 인프라를 짜면 비용만 쓸데없이 커진다. 좋은 인프라 아키텍트는 "바꾸기 비싼 결정"과 "바꾸기 싼 결정"을 구분해서, 전자에만 시간을 쏟고 후자는 미루거나 자동화한다.

품질 속성 — 기능이 아니라 "~성"이 구조를 갈라놓는다

두 인프라가 똑같이 "웹 서비스를 호스팅한다"는 기능을 수행해도 구조는 전혀 다를 수 있다. 차이를 만드는 건 품질 속성(quality attributes)이다. Bass·Clements·Kazman은 (4th ed, 2021)에서 아키텍처를 이끄는 요소(architectural drivers)로 이 "~성"들을 분류했다. 인프라가 특별히 다뤄야 하는 주요 품질 속성은 이렇게 모아볼 수 있다.

가용성(availability) — 정해진 시간 동안 서비스가 정상 동작하는 비율. "99.9%"는 1년에 약 8.76시간 다운을 허용한다.
내구성(durability) — 데이터가 손실되지 않을 확률. 디스크 고장, 데이터센터 침수, 소프트웨어 버그 모두 내구성 위협이다.
지연(latency) — 요청에서 응답까지 걸리는 시간. p50(중간값)과 p99(99번째 백분위수)는 다른 이야기를 한다.
처리량(throughput) — 단위 시간당 처리하는 작업량. 초당 요청 수(RPS), 초당 패킷 수(pps), 초당 I/O 작업 수(IOPS).
확장성(scalability) — 부하가 늘어날 때 처리 능력을 어떻게 키우는가. 수직(더 큰 서버)과 수평(서버 추가)으로 나뉜다.
보안(security) — 인가되지 않은 접근·변조·파괴로부터 시스템을 지키는 능력.
비용(cost) — 위 모든 것을 달성하는 데 드는 돈. 인프라에선 절대 무시할 수 없는 0번 품질 속성이다.

가용성 수치의 함정을 하나 짚고 가자. "9의 법칙(nines rule)"이라 불리는 경험칙이다. 99%는 한 해에 약 3.65일 다운을 허용하고, 99.9%는 8.76시간, 99.99%는 52.5분, 99.999%("다섯 개의 9")는 5.25분이다. 9가 하나 추가될 때마다 허용 다운타임이 1/10으로 줄어드는 대신, 필요한 엔지니어링 비용은 대략 10배로 늘어난다. 99.9%에서 99.99%로 가려면 중복의 수준이 한 단계 올라가야 하고, 99.999%에 도달하려면 모든 컴포넌트가 이중·삼중화돼야 한다. 그래서 "무조건 다섯 개의 9"을 목표로 하면 안 된다 — 그 9를 달성하는 데 쓰는 돈이 비즈니스 가치를 넘어설 수 있다. 목표 가용성은 비즈니스가 감당할 수 있는 다운타임 비용에서 역산해 정해진다.

이 "~성"들은 서로 충돌한다. 가용성을 높이려면 중복(redundancy)이 필요하고, 중복은 비용을 키운다. 지연을 낮추려면 더 가까이에 서버를 두어야 하고, 그건 더 많은 리전에 배포해 비용이 또 오른다. 확장성을 높이려면 수평 확장 구조로 가야 하고, 그건 데이터 일관성 문제를 만든다. "다 잘하자"는 말은 품질 속성끼리 충돌한다는 걸 모르는 발언이다.

그래서 인프라 결정은 항상 트레이드오프의 형태를 띤다. "가용성 99.99%를 1년 예산 1억 원 안에서 달성하자"는 의미 있는 목표지만, "가용성을 최대로 높이자"는 의미 없는 목표다. Bass 등이 강조한 대로 품질 속성은 측정 가능한 시나리오로 구체화해야 설계를 이끈다 — "결제 노드 한 대가 장애를 일으키면(자극) 정상 영업 시간에(환경) 다른 노드로 요청을 우회시키고(응답) 30초 이내 복구·연간 가동률 99.95%(측정)를 유지한다"는 식으로. 추상적인 "~성"이 아니라 측정 가능한 수치가 되어야 팀이 같은 목표를 본다.

소프트웨어 아키텍처와 만나는 지점 — 인프라 가정이 깨질 때

인프라 아키텍처는 소프트웨어 아키텍처와 같은 학문이 아니다. 축이 다르다. 소프트웨어 아키텍처는 코드를 어떤 구조로 나눌지, 모듈 간 의존성을 어떻게 흘릴지를 다룬다. 인프라 아키텍처는 그 코드가 돌아갈 물리·논리적 환경을 다룬다. 둘은 분명 다른 층이지만, 현대 시스템에서는 만나는 지점이 점점 많아지고 있다.

마이크로서비스가 데이터베이스마다 서비스마다 독립된 저장소를 쓰기로 하면(소프트웨어 결정), 그 위에 컨테이너 오케스트레이션·서비스 디스커버리·동적 라우팅 인프라가 필요해진다(인프라 결정). 데이터 일관성을 "최종 일관성(eventual consistency)"으로 선택하면(소프트웨어), 그 위에 메시지 브로커와 재시도·멱등성 인프라가 깔려야 한다(인프라). 반대로 인프라 팀이 "서비스 메시를 전사 도입"하겠다고 결정하면(인프라), 각 서비스 팀은 사이드카 프록시의 지연·실패 모드까지 고려해 코드를 짜야 한다(소프트웨어).

그래서 두 축을 완전히 떼어놓고 생각하면 위험하다. 가장 자주 발생하는 문제는 소프트웨어가 인프라에 대해 세우는 가정이 현실에서 깨지는 것이다. Deutsch와 Gosling이 1994~1997년에 정리한 "분산 컴퓨팅의 8가지 오해(Fallacies of Distributed Computing)"는 이 가정들의 함정을 8개로 압축한 명단이다 — 네트워크는 신뢰할 수 있다, 지연은 0이다, 대역폭은 무한하다, 네트워크는 안전하다, 토폴로지는 변하지 않는다, 관리자는 한 명이다, 전송 비용은 0이다, 네트워크는 균일하다. 이 여덟 가지는 모두 거짓인데도 소프트웨어가 습관적으로 가정하는 것들이다.

이 가정이 깨지는 순간이 바로 장애다. "네트워크는 신뢰할 수 있다"를 믿고 서비스 A가 서비스 B를 동기 호출하면, B가 느려지는 순간 A의 스레드 풀이 고갈된다. "지연은 0이다"를 믿고 데이터베이스를 다른 리전에 두면, 매 쿼리마다 50ms가 더 붙어서 p99가 폭발한다. "네트워크는 안전하다"를 믿고 내부 트래픽을 암호화하지 않으면, 한 컨테이너가 뚫렸을 때 같은 네트워크 안의 모든 서비스가 노출된다. 인프라 아키텍트가 이 가정들을 코드까지 들여다보지는 않더라도, "우리 팀의 서비스가 인프라에 대해 세우는 가정이 무엇인가"를 알아야 하는 이유다.

왜 이것이 "공학"인가 — 직감에서 측정으로

전통적인 시스템 관리자(sysadmin) 모델에서는 인프라가 직감과 경험으로 다뤄졌다. "이 서버는 좀 오래됐으니 교체하자", "디스크가 80% 찼으니 비우자", "장애가 났으니 가서 재시작하자". 잘 동작하는 시스템이었고 여전히 많은 곳에서 돌아간다. 그런데 Google은 2003년 무렵 이 모델의 한계에 부딪혔다. 서버가 수만 대가 넘어가니 직감으로는 감당이 안 됐다 — 한 사람이 일일이 서버를 손으로 만질 수 있는 수를 넘어선 것이다.

Google의 대답이 사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)이다. Beyer·Jones·Petoff·Murphy가 엮은 (2016)에서 그들은 운영을 "소프트웨어 공학의 문제"로 재정의한다. 서버 한 대를 재시작하는 건 직감적 작업이지만, 1만 대의 서버 중 임의의 5%가 언제 장애가 날지 예측하고 대비하는 건 통계·측정·자동화의 문제라는 것이다. 이 관점이 업계에 퍼지면서 "운영"은 "신뢰성 공학"으로 바뀌었고, 인프라 아키텍처는 직감이 아니라 측정 가능한 품질 속성(SLI/SLO)과 재현 가능한 절차(IaC·자동화)를 다루는 분야로 자리 잡았다.

이 관점을 극단까지 밀어붙인 게 넷플릭스의 혼돈 공학(chaos engineering)이다. 넷플릭스는 2010년대 초반 AWS로 전면 이전하면서 "우리 인프라가 장애를 견딜 수 있는가"를 일상적으로 테스트하기 시작했다. Chaos Monkey라는 도구는 매일 영업 시간에 무작위 프로덕션 인스턴스를 죽였다. 죽었을 때 시스템이 자동 복구되지 않으면 그건 버그이고, 출시 전에 고쳐야 한다고 본 것이다. 처음엔 미친 짓처럼 보였지만, 이 접근은 "장애는 피하는 게 아니라 견디는 것"이라는 발상의 전환을 업계에 가져왔다. 인프라의 신뢰성은 "절대 안 죽게 만들기"가 아니라 "언젠가 죽을 것이므로 죽어도 서비스가 사는 구조로 만들기"로 정의가 바뀌었다.

이것이 인프라를 "공학"이라 부르는 이유다. 공학은 직감에 의존하지 않고 측정·추론·재현 가능한 절차에 의존하는 문제 해결 방식이다. 다리 설계가 "이 정도면 버티겠지"가 아니라 하중 계산과 안전율로 이뤄지듯, 인프라 설계도 "이 정도면 안 죽겠지"가 아니라 가용성 수학적 모델과 장애 주입 실험으로 이뤄진다. 직감을 배척하는 건 아니다 — 숙련된 엔지니어의 직감은 여전히 귀중한 입력이다. 다만 직감만으로는 1만 대 규모의 시스템을 운영할 수 없고, 측정·추론의 언어로 번역되지 않은 직감은 팀에 전달되지 않는다.

실습 — 추상화 계층이 드러나는 모습

추상화 계층이라는 개념이 허구가 아니라는 걸 직접 확인한다. 리눅스 서버(또는 WSL2) 한 대에서 아래 명령을 차례로 치면, 같은 컴퓨터가 층마다 완전히 다른 모습으로 드러나는 걸 볼 수 있다.

1. 하드웨어 계층 — 실리콘의 진짜 모습

# CPU의 진짜 정체를 본다. 클라우드 VM이라면 가상화 흔적이 보인다.
lscpu | grep -E 'Model name|Hypervisor|Virtualization|CPU\(s\)'

확인할 것: CPU 종류·코어 수·가상화 지원 여부. 클라우드 VM이라면 Hypervisor vendor: KVM이 보인다 — 이 자체가 가상화 계층의 흔적이다. 베어메탈이라면 이 줄이 아예 없다.

# 베어메탈 예상 출력 (Ubuntu 24.04, Intel i7-12700)
Model name:                      Intel(R) Core(TM) i7-12700 CPU @ 2.10GHz
CPU(s):                          20
Virtualization:                  VT-x

# AWS EC2 예상 출력 (m6i.large, KVM 기반)
Model name:                      Intel(R) Xeon(R) Platinum 8375C CPU @ 3.50GHz
Hypervisor vendor:               KVM
Virtualization type:             full

2. 블록 장치 — 물리적 저장소의 추상화

# 디스크를 "블록 장치"라는 추상으로 본다.
lsblk

확인할 것: 디스크가 /dev/sda, /dev/nvme0n1 같은 블록 장치로 보임. 실제로는 SSD의 셀·플레인·채널 같은 구조가 있지만 커널은 "블록 장치"라는 추상으로 가린다.

# 예상 출력 (단일 NVMe SSD)
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0 953.9G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
└─nvme0n1p2 259:2    0 953.4G  0 part /

3. 네트워크 인터페이스 — 전기 신호의 추상화

# NIC을 "인터페이스"라는 추상으로 본다. -br은 brief(요약) 출력.
ip -br link

확인할 것: lo(루프백), eth0 또는 ens5(이더넷)이 이름으로 보임. 실제로는 NIC의 펌웨어·드라이버·DMA가 동작하지만, 커널은 "인터페이스"라는 추상으로 가린다.

# 예상 출력
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             0a:1b:2c:3d:4e:5f <BROADCAST,MULTICAST,UP,LOWER_UP>

4. 커널 — 모든 추상화를 조율하는 층

# 커널 버전과 아키텍처. 가상 파일 시스템을 통해 커널 정보를 읽는다.
uname -a
cat /proc/cpuinfo | head -3

확인할 것: uname이 커널 버전·아키텍처(x86_64, aarch64)를 알려준다. /proc/cpuinfo는 "가상 파일 시스템(procfs)"의 일종 — 실제 파일이 아니라 커널이 만들어내는 정보의 창이다. 커널이 모든 하드웨어를 "파일처럼" 보이게 하는 Unix 철학의 결과다.

# uname 예상 출력
Linux myhost 6.8.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 14 07:50:21 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

# /proc/cpuinfo 예상 출력 (처음 3줄)
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6

5. 프로세스 — 실행 중인 프로그램의 추상화

# 시스템에 떠 있는 모든 프로세스를 본다.
ps aux | head -10

확인할 것: 시스템에 수십~수백 개의 프로세스가 동시에 떠 있는데 CPU는 한 개뿔일 수 있다. 어떻게 가능한가 — 커널이 "시분할(time-sharing)"이라는 추상화로 CPU를 프로세스들 사이에 밀리초 단위로 빠르게 번갈가며 할당하기 때문. 우리는 프로세스가 "동시에" 도는 것처럼 보는 추상을 받아들일 뿐이다.

# 예상 출력 (처음 몇 줄)
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0 168144 11456 ?        Ss   09:30   0:02 /sbin/init splash
root           2  0.0  0.0      0     0 ?        S    09:30   0:00 [kthreadd]
root           3  0.0  0.0      0     0 ?        I<   09:30   0:00 [rcu_gp]
systemd+     521  0.0  0.0  23360  9728 ?        Ss   09:30   0:00 /lib/systemd/systemd-resolved

PID 1이 /sbin/init인 게 보인다 — 이게 systemd(뒤에서 다룬다)의 진입점이다.

이 다섯 명령은 모두 같은 컴퓨터를 보여준다. 하지만 각각 다른 층을 들여다본다. 인프라를 이해한다는 건 이런 층들이 어떻게 겹쳐 있고, 각 층에서 문제가 생기면 위아래로 어떻게 전파되는지를 아는 것이다.

미검증 항목: 위 명령의 정확한 출력 형식은 배포판·버전·하드웨어에 따라 다르다. Rocky 10, Ubuntu 24.04, WSL2 환경에서 직접 실행해 확인하길 권한다. man 페이지(man lscpu, man ip)가 각 필드의 공식 의미를 제공한다.

같은 서비스, 두 인프라 — 장애 앞에서 벌어지는 차이

품질 속성이 왜 구조를 갈라놓는지, 장애 시나리오로 확인한다. 같은 "웹 서비스"를 두 인프라 구조로 세우고, 트래픽이 갑자기 10배가 됐을 때 벌어지는 일을 비교한다.

인프라 A — 단일 서버, 올인원.

flowchart LR
    USER[사용자] --> SVR["서버 1대<br/>nginx + app + DB"]

# 서버 한 대에 전부 띄움
web: nginx (port 80) → app (port 8080) → postgres (port 5432)

처음엔 잘 돌아간다. 그런데 트래픽이 10배가 되면 세 가지가 동시에 터진다 — CPU 100%, 디스크 I/O 병목, 메모리 부족. 이 상태에서 서버가 죽으면 서비스가 완전히 사라진다. 단일 장애점(single point of failure, SPOF)이다.

인프라 B — 분산, 다중 AZ.

flowchart LR
    USER[사용자] --> LB[로드 밸런서]
    LB --> AZ1["AZ-A<br/>app × 3"]
    LB --> AZ2["AZ-B<br/>app × 3"]
    AZ1 --> DB[(DB primary)]
    AZ2 --> DB
    DB -. 복제 .-> RDB[(DB replica, AZ-B)]

같은 10배 트래픽이 와도, 로드 밸런서가 여러 app 인스턴스로 분산시키고, AZ 하나가 통째로 날아가도 다른 AZ가 서비스를 유지한다. 비용은 더 들지만 가용성은 비교할 수 없이 높다. 중요한 건 — 이 구조는 "장애가 난 뒤에" 만들 수 있는 게 아니라는 것이다. 처음 설계할 때 "언젠가 AZ 하나가 날아갈 수 있다"는 시나리오를 가정하고 멀티 AZ를 깔았기 때문에, 막상 장애가 왔을 때 아무것도 안 해도 된다. 장애 대응의 90%는 사전 설계에서 끝난다. 남은 10%는 모니터링·알림·장애 대응 절차가 다룬다.

여기서 한 번 더 들여다볼 게 장애 도메인(fault domain)의 차이다. 장애 도메인이란 "같은 원인으로 동시에 장애가 나는 리소스들의 묶음"이다. 인프라 A에서는 서버 한 대 전체가 하나의 장애 도메인이다. 전원·디스크·네트워크 카드 중 어느 하나가 죽으면 서비스 전체가 죽는다. 인프라 B에서는 장애 도메인이 더 잘게 쪼개진다 — app 인스턴스 하나, AZ 하나. 어느 하나가 죽어도 전체 서비스는 산다. 장애 도메인을 잘게 쪼갤수록 장애의 충격이 분산되지만, 운영 복잡도는 올라간다. 인프라 아키텍처의 많은 결정이 결국 "장애 도메인을 어디까지 쪼갤 것인가"라는 질문으로 귀결된다. 이 개념은 01-foundations/03-fault-domains.md에서 깊이 다룬다.

시나리오	인프라 A (단일 서버)	인프라 B (다중 AZ 분산)
트래픽 10배 증가	CPU·I/O 포화, 응답 지연 폭발	자동 확장(autoscaling)으로 흡수
서버 1대 장애	서비스 완전 중단	LB가 건강한 인스턴스로 우회, 무중단
AZ 전체 장애	서비스 중단	반대 AZ가 서비스 유지 (가용성 손실 최소)
DB 장애	서비스 중단, 최근 데이터 손실 가능	replica로 승격(failover), RPO 수 초 이내
초기 비용	낮음	상대적으로 높음
운영 복잡도	낮음	높음 (모니터링·배포·IaC 필요)

인프라 A가 "틀렸다"는 게 아니다. 트래픽이 적고 잠깐 다운돼도 되는 서비스라면 A가 정답이다. 트레이드오프의 문제다. 다만 "나중에 필요하면 B로 바꾸면 되지"라고 생각하면 안 된다 — A에서 B로 가는 건 코드 수정보다 훨씬 큰 공사이고, 장애가 한 번 터진 뒤에는 그 공사를 할 여유가 없다.

비용·복잡도·안정성 — 인프라 결정의 삼각형

인프라 결정은 대부분 비용-복잡도-안정성의 삼각형 안에서 내려진다. 세 가지를 동시에 다 잘할 수는 없다.

flowchart TD
    COST((비용 절감)) --- QUAL((품질 향상))
    QUAL --- COMP((복잡도 증가))
    COMP --- COST

품질(가용성·지연·내구성)을 높이면 비용이 오르거나 복잡도가 늘거나 둘 다다.
비용을 줄이면 품질이 떨어지거나, 복잡한 최적화 작업이 필요하다.
복잡도를 줄이면 (예: 관리형 서비스 쓰기) 비용이 오르거나, 제공되는 기능에 제약이 생긴다.

이 삼각형에서 "다 잡자"는 말은 품질 속성이 서로 충돌한다는 걸 모르는 발언이다. 진짜 질문은 "이 서비스에선 어느 한 꼭지를 타협할 건가"다. 결제 시스템은 비용이 비싸도 품질(가용성·내구성)을 끌어올리고, 개발 환경은 품질을 타협하고 비용을 줄인다. 로깅 파이프라인은 복잡도를 좀 감당하더라도 비용·품질을 잡는다. 정답이 하나인 게 아니라 서비스마다 다른 타협점이 있는 것이고, 그 타협점을 명시적으로 결정하는 일이 인프라 아키텍트의 일이다.

이 서브프로젝트의 지도 — 6영역이 푸는 질문들

이제 이 서브프로젝트가 앞으로 파고들 영역을 한눈에 봐야 할 때다. 인프라 아키텍처를 한 권으로 담긴 어렵기에 여섯 영역으로 나눴다. 각 영역은 다른 질문을 풀고 있다.

flowchart TD
    F["01 foundations<br/>왜 공학으로 다루나"] --> CP["02 compute-platforms<br/>어떻게 컴퓨팅을 추상화했나"]
    F --> NF["03 network-fundamentals<br/>패킷이 어떻게 흐르나"]
    CP --> DC["04 datacenter-and-cloud<br/>물리에서 클라우드 네이티브까지"]
    NF --> DC
    DC --> RS["05 reliability-sre<br/>신뢰성을 어떻게 공학으로"]
    RS -. 교차 .-> SC["06 infra-security<br/>어떻게 방어하나"]

01 foundations (이 글이 속한 영역): 인프라를 왜 공학으로 다루는가. 품질 속성·장애 도메인·redundancy·IaC 철학의 어휘를 잡는다. 다른 모든 영역의 기반이다.
02 compute-platforms: 컴퓨팅 자원을 어떻게 추상화했나. 서버 하드웨어부터 베어메탈·VM·HCI·컨테이너 런타임까지. "한 대의 서버"에서 시작해 "실행 환경의 선택지"로 확장한다.
03 network-fundamentals: 패킷이 어떻게 흐르는가. OSI 7계층·이더넷·IP·라우팅·TCP·혼잡 제어·DNS·HTTP/TLS·로드 밸런싱. 인터넷이 굴러가는 원리를 위에서부터 아래로.
04 datacenter-and-cloud: 물리 시설에서 클라우드 네이티브까지. IDC의 전력·냉각·랙부터 spine-leaf 토폴로지·VXLAN·VPC·SDN·Terraform·CNCF·GitOps. 베어메탈이 어떻게 클라우드가 되는가.
05 reliability-sre: 신뢰성을 어떻게 공학으로 다루나. SLI/SLO/SLA·error budget·observability·incident·chaos engineering·DR. Google SRE의 방법론이 왜 업계 표준이 됐나.
06 infra-security: 어떻게 방어하나. defense in depth·zero trust·방화벽·호스트 강화·IAM·PKI. 다른 모든 영역의 교차 적용.

어디서 시작하든 좋다. 다만 foundations는 웬만하면 먼저 읽는 게 좋다 — 품질 속성·장애 도메인·redundancy 어휘가 뒤 영역 전체에서 재사용되기 때문이다. 그다음은 관심사에 따라 — HW가 궁금하면 compute-platforms, 네트워크가 궁금하면 network-fundamentals, 장애와 운영이 궁금하면 reliability-sre. datacenter-and-cloud는 02와 03이 끝난 뒤가 자연스럽고, infra-security는 어느 시점에 읽어도 좋다. 다만 이 여섯 영역이 결국 같은 질문의 다른 층면을 본다는 걸 잊지 말자 — "이 추상화 계층에서, 이 품질 속성을 위해, 이 비용을 치를 가치가 있는가."

인프라는 "밑에 있는 것"을 다룬다는 뜻

도시 기반 시설 비유로 돌아오자. 도시의 도로망이 건물보다 먼저 깔리고 나중에 바꾸기 어려운 것처럼, 인프라도 애플리케이션보다 먼저 설계되고 나중에 바꾸기 어렵다. 클라우드가 이 물리적 제약을 일부 완화해 주었지만, 근본적으로 지워주진 않았다 — 리전을 바꾸는 건 여전히 도시를 옮기는 일이다.

그래서 인프라를 공학으로 다룬다는 건, "나중에 바꾸기 비싼 결정을 미리, 측정 가능한 품질 속성에 근거해, 트레이드오프를 명시적으로 드러내며 내리는 일"이다. 2017년 AWS S3 사건은 이 명제의 부정형을 보여줬다 — 인프라 가정을 깊이 검토하지 않은 수만 개의 서비스가 한 서브시스템 장애에 연쇄적으로 무너졌다. 이 서브프로젝트가 앞으로 파고들 주제는 이 명제의 긍정형을 쌓는 일이다 — 베어메탈에서 컨테이너까지, 이더넷에서 BGP까지, 단일 서버에서 멀티 리전까지. 각 주제는 결국 같은 질문의 다른 층면을 본다. 그 질문에 답할 수 있을 때 인프라는 더 이상 어둠 속의 마법이 아니라 설계 가능한 구조가 된다.

참고

AWS SRE 팀, "Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region", AWS News Blog, 2017-02-28 — S3 us-east-1 장애의 공식 사고 보고서. 접근 2026-07-21. URL: https://aws.amazon.com/message/41926/
Bass, L., Clements, P., Kazman, R. 4th ed, Addison-Wesley, 2021, Ch.2·Ch.4 — 품질 속성·architectural drivers 정의. 접근 2026-07-21
Richards, M., Ford, N. , O'Reilly, 2020, Ch.1 — "변경이 어려운 결정" 정의. 접근 2026-07-21
Deutsch, P. "The Fallacies of Distributed Computing" — 1994년 Sun 내부 발표, 1997년 James Gosling이 정리해 널리 퍼뜨림. 분산 시스템의 8가지 흔한 오해. 접근 2026-07-21
Beyer, B., Jones, C., Petoff, J., Murphy, N. R. (eds.) , O'Reilly, 2016 — Google의 SRE 모델, 운영을 공학으로 재정의. 무료 공개(sre.google/sre-book/table-of-contents/). 접근 2026-07-21
Kleppmann, M. , O'Reilly, 2017, Ch.1 — 신뢰성·확장성·유지보수성의 공학적 정의. 접근 2026-07-21
37signals 발표 "Why we're leaving the cloud", 2022-10 — 클라우드에서 온프레미스(베어메탈)로 회귀한 사례와 비용 분석. 접근 2026-07-21
RFC 1918 (Rekhter, Y. et al., 1996) — 사설 IP 주소 공간 할당. 인프라 기본 빌딩 블록 예시. 접근 2026-07-21
Linux kernel documentation, kernel.org — /proc, lscpu, 블록 장치 계층 문서. 접근 2026-07-21
systemd freedesktop.org 문서 — 유닛·저널·서비스 관리. 접근 2026-07-21

'Infra Architecture > Foundations' 카테고리의 다른 글

Foundations - 03. fault domain과 blast radius (1)	2026.07.21
Foundations - 02. 인프라 품질 속성 (0)	2026.07.21