인프라

서비스를 인터넷에 띄우려면 기계를 직접 사야 하던 시절이 있었습니다. 서버 한 대를 들이는 일은 견적을 받고 구매 승인을 올리고 납품을 기다리는 과정이었고, 물건이 도착하면 전기와 통신 회선이 들어오는 건물에 자리를 빌려 꽂아야 했습니다. 주문한 날부터 그 위에서 서비스가 도는 날까지 한 달이 걸리는 것이 보통이었습니다.

값보다 성가신 쪽은 몇 대를 살지 미리 정해야 한다는 점이었습니다. 앞으로 사람이 얼마나 올지 모르는 상태에서 숫자를 불러야 했고, 어느 쪽으로 틀려도 손해가 났습니다. 적게 사면 광고가 터진 날 접속이 안 됐고, 넉넉히 사면 평소에는 열 대 중 여덟 대가 아무 일도 하지 않으면서 전기만 먹었습니다. 가장 붐비는 하루를 기준으로 사 두고 나머지 364일을 놀리는 것이 그때의 상식이었습니다.

기계가 늘면 다른 문제가 따라왔습니다. 사람 손으로 설치한 서버는 한 대 한 대가 조금씩 달랐습니다. 1번 서버에는 누가 급할 때 손으로 바꿔 둔 설정이 남아 있고 5번에는 그게 없으니, 같은 코드를 올렸는데 1번에서만 제대로 도는 일이 생겼습니다.

그 시절 개발팀의 대화는 이런 모양이었습니다. "서버 한 대만 더 주세요" 라고 하면 "이번 분기 예산은 다 썼고 다음 달에 품의 올릴게요" 가 돌아왔습니다. 기능은 하루면 만드는데 그 기능이 올라갈 자리는 6주 뒤에 생겼습니다.

인프라라는 말은 이 바닥을 따로 떼어 이름 붙인 것입니다. 위에서 어떤 기능을 만들든 그 밑에는 계산을 대신 해 줄 기계와 요청이 오갈 길과 자료를 남길 자리가 있어야 합니다. 기능은 만들어 내보내면 일이 끝나지만 바닥은 서비스가 살아 있는 내내 붙들고 있어야 합니다. 열 명이 쓸 때 충분하던 바닥이 십만 명 앞에서는 무너지고, 늘리고 줄이는 방식을 미리 정해 두지 않으면 하필 가장 잘되는 날에 서비스가 멈춥니다.

인프라 아래 묶인 말은 여섯 갈래입니다. 바닥을 어디서 구해 오느냐가 형태이고, 그 위에서 프로그램을 무엇에 담아 돌리느냐가 실행 환경입니다. 바깥의 요청이 그 프로그램까지 어떤 길로 오느냐가 네트워크이고, 사람이 몰릴 때 바닥을 어떻게 키우느냐가 확장입니다. 나머지 둘은 그렇게 만든 구성을 어디에 적어 두느냐(관리)와 그 구성 때문에 생기는 첫 지연(성능)입니다.

형태는 기계를 어떻게 마련하느냐를 가르는 갈래입니다. 클라우드는 남이 지어 놓은 데이터 센터에서 필요한 만큼만 빌려 쓰고 쓴 만큼 내는 방식입니다. 앞에서 말한 6주가 여기서 몇 분으로 줄어듭니다. 화면에서 사양을 고르고 만들기를 누르면 2분 뒤에 쓸 수 있는 기계가 생기고, 지우면 그 시점부터 요금이 끊깁니다. 대신 한 번 사면 끝이던 값이 매달 나가는 값이 되어서, 쓰지 않는 기계를 켜 둔 채 잊으면 그 비용이 조용히 빠져나갑니다.

실행 환경은 빌려 온 자리 위에서 프로그램을 무엇에 담느냐를 가르는 갈래입니다. 셋이 있고, 담는 그릇이 점점 가벼워지는 순서로 놓여 있습니다.

1. 가상 머신 — 물리 서버 한 대를 쪼개 여러 대인 것처럼 쓰는 방식입니다. 각각이 자기 운영체제를 갖고 있어서 안에서 무엇을 하든 옆방에 영향을 주지 않습니다. 대신 운영체제 한 벌을 통째로 켜야 해서 시작에 1~2분이 걸리고 메모리도 그만큼 먼저 나갑니다.
2. 컨테이너 — 프로그램과 그것이 돌아가는 데 필요한 것만 묶고 운영체제는 아래 것을 나눠 씁니다. 그래서 몇 초 만에 뜨고 한 대에 수십 개를 얹을 수 있습니다. 묶은 내용이 고정되어 있으니 내 노트북에서 돌던 것이 서버에서도 같은 모양으로 돕니다. 앞에서 말한 1번 서버와 5번 서버의 차이가 여기서 사라집니다.
3. 오케스트레이션 — 컨테이너가 수백 개로 늘면 어느 기계에 몇 개를 얹을지, 하나가 죽으면 어디에 다시 띄울지를 사람이 따라갈 수 없습니다. 그 판단을 대신 맡기는 일입니다. "이 프로그램은 항상 세 개가 떠 있어야 한다" 고 원하는 상태를 적어 두면, 하나가 죽는 순간 새것을 띄워 그 상태로 되돌립니다.

네트워크는 바깥의 요청이 프로그램까지 오는 길을 가르는 갈래입니다. 다섯 가지가 도착 순서대로 놓여 있습니다. 주소창에 이름을 치면 DNS 가 그 이름을 실제 서버 주소로 바꿔 줍니다. 전화번호부처럼 이름과 번호를 짝지어 둔 체계라, 서버를 옮겨도 주소만 갈아 끼우면 쓰는 사람은 같은 이름을 계속 씁니다. 주소를 찾아 도착한 요청은 로드 밸런서가 받습니다. 뒤에 서 있는 여러 대 중 지금 여유 있는 쪽으로 요청을 넘기고, 한 대가 대답을 못 하면 그 대를 빼고 나머지로만 보냅니다. 한 대가 죽어도 서비스가 계속 도는 이유가 대개 이것입니다. 리버스 프록시는 요청을 대신 받아 뒤로 넘기면서 압축이나 인증서 처리 같은 공통 작업을 한자리에서 해치우는 중계입니다. 그림 파일처럼 모두에게 똑같이 나가는 자원은 CDN이 맡습니다. 같은 파일을 세계 여러 거점에 미리 복사해 두고 접속한 사람과 가장 가까운 곳에서 내려 주는 배포망입니다. 서울에서 미국 서버를 부르면 왕복에 200밀리초가 걸리지만 서울 거점에서 받으면 10밀리초로 끝납니다. 엣지 컴퓨팅은 여기서 한 걸음 더 가 가까운 거점에서 간단한 계산까지 처리합니다.

확장은 사람이 몰릴 때 바닥을 키우는 방식을 가르는 갈래입니다. 방향이 두 가지이고, 그 위에 자동화가 하나 얹힙니다.

1. 수평 확장 — 같은 사양의 서버 대수를 늘립니다. 2대에서 10대로 가는 식이라 한계가 거의 없고 한 대가 죽어도 나머지가 버팁니다. 대신 어느 대가 받아도 결과가 같도록 프로그램이 만들어져 있어야 합니다.
2. 수직 확장 — 서버 한 대의 성능을 키웁니다. 메모리를 8기가에서 32기가로 올리는 식이고, 코드를 고칠 필요가 없어 급할 때 가장 빠른 수입니다. 다만 한 대가 커지는 데는 한계가 있고 바꾸는 동안 그 한 대가 멈춥니다.
3. 오토스케일링 — 늘리고 줄이는 판단을 규칙에 맡깁니다. "처리 부하가 5분 넘게 70퍼센트를 넘으면 한 대 추가, 30퍼센트 아래로 떨어지면 한 대 제거" 처럼 적어 두면 새벽에는 2대로 줄고 점심시간에는 8대로 늡니다. 사람이 자는 동안에도 돌아가고, 노는 기계에 내는 돈도 같이 줄어듭니다.

관리는 이 모든 구성을 어디에 적어 두느냐의 갈래입니다. 코드형 인프라는 서버 몇 대, 어떤 사양, 어떤 네트워크 설정 같은 것을 화면에서 클릭해 만드는 대신 파일에 적어 두고 그 파일을 실행해 만드는 방식입니다. 적어 두면 같은 파일로 개발용과 운영용을 똑같이 만들 수 있고, 누가 언제 무엇을 바꿨는지 기록이 남고, 통째로 날아가도 파일만 있으면 다시 세울 수 있습니다. 클릭해 만든 구성은 만든 사람의 머릿속에만 남습니다.

성능은 이렇게 만든 바닥에서 생기는 지연을 다루는 갈래입니다. 콜드 스타트는 쉬고 있던 실행 환경이 깨어나면서 첫 요청만 유독 느려지는 현상입니다. 쓰지 않을 때 꺼 두면 돈이 굳지만, 그 상태에서 처음 들어온 사람은 평소 0.1초 걸리던 화면을 3초 기다립니다. 비용을 아끼려는 선택이 사용자 한 명의 첫인상을 깎는 구조라, 아낄 자리와 켜 둘 자리를 나눠 정합니다.

여섯 갈래는 나란히 놓인 목록이 아니라 서로를 부릅니다. 기계를 분 단위로 만들 수 있게 되니 똑같은 것을 여러 개 찍어 내는 방식이 쓸모 있어졌고, 여러 개가 생기니 그 앞에 나눠 보내는 장치를 둘 이유가 생겼고, 나눠 보낼 수 있으니 대수를 자동으로 늘리고 줄이는 일이 가능해졌습니다. 그렇게 늘어난 구성 요소를 사람이 기억으로 관리할 수 없게 되면서 코드로 적어 두는 방식이 따라왔습니다.

"이번 주 금요일에 이벤트 트래픽 몰릴 거라 인프라 미리 늘려 둘게요. 끝나면 다시 줄입니다."

평소 대수로는 못 버틸 것을 알고 있으니 미리 키워 두겠다는 말입니다. 끝나고 줄인다는 단서가 붙는 이유는 늘린 만큼 비용이 계속 나가기 때문입니다.

"그건 코드 문제가 아니라 인프라 문제예요. 뒤에 붙은 세 대 중 한 대가 응답을 안 하고 있었어요."

같은 요청인데 어떤 사람은 되고 어떤 사람은 안 되던 증상의 원인을 짚은 말입니다. 코드를 아무리 들여다봐도 안 나오는 종류의 문제라 찾는 자리를 바꾸자는 뜻입니다.

"인프라 비용이 지난달보다 40퍼센트 늘었는데 사용자 수는 그대로예요. 어디서 새는지 봅시다."

쓴 만큼 내는 구조에서는 쓰는 사람이 늘지 않았는데 비용만 느는 일이 생깁니다. 대개 테스트하려고 만들고 지우지 않은 기계나 잘못 적힌 자동 확장 규칙이 원인입니다.

페이지덱에서 이 말이 가장 자주 오간 때는 기업 고객 한 곳이 도입을 확정한 다음 달입니다. 그때까지 페이지덱은 새벽이든 점심이든 서버 두 대로 돌고 있었습니다. 고객사 쪽에서 300명이 같은 시간에 출근해 문서를 여는 순간 두 대가 버티지 못했고, 문서가 열리는 데 8초가 걸린다는 문의가 오전 내내 들어왔습니다.

태오는 급한 불을 수직 확장으로 껐습니다. 두 대의 사양을 그날 저녁에 두 배로 올렸고, 코드를 한 줄도 고치지 않았으니 다음 날 아침은 넘겼습니다. 그다음이 진짜 대응이었습니다. 시간대별 접속 기록을 보니 오전 9시부터 11시까지만 나머지 시간의 네 배였습니다. 그래서 대수를 자동으로 늘리고 줄이는 규칙을 걸어 평일 오전에는 여섯 대, 새벽에는 두 대로 돌게 바꿨습니다. 규원이 물은 것은 하나였습니다. 한 달 비용이 얼마나 느느냐. 답은 18퍼센트였습니다.

인프라는 따로 있는 담당자가 알아서 챙기는 영역이고 개발자는 코드만 쓰면 된다고 생각하기 쉽습니다. 실제로 큰 회사에는 이 일만 하는 팀이 따로 있고, 작은 팀에서도 서버 권한이 한두 사람에게만 있는 경우가 많으니 그렇게 보입니다. 하지만 코드가 어떻게 생겼느냐가 바닥에서 무엇이 가능한지를 정해 버립니다. 로그인한 사람의 정보를 서버 한 대의 메모리에 들고 있게 짜 두면 대수를 아무리 늘려도 그 사람은 특정 한 대로만 가야 하고, 그러면 수평 확장이 막힙니다. 이 사실을 모른 채 설계하면 트래픽이 늘어난 시점에 "서버를 늘리면 되지 않나요" 라는 요청에 "코드를 고쳐야 늘릴 수 있습니다" 라고 답하게 되고, 하루면 될 줄 알았던 대응이 2주가 됩니다.

클라우드로 옮기면 인프라를 신경 쓸 일이 없어진다는 기대도 자주 봅니다. 기계를 사지도 않고 데이터 센터에 갈 일도 없으니 그 영역이 통째로 사라진 것처럼 느껴집니다. 없어진 것은 기계를 마련하는 수고뿐이고, 정할 것은 오히려 늘었습니다. 어느 지역에 둘지, 대수를 몇 대로 시작할지, 언제 늘리고 언제 줄일지, 백업을 어디에 며칠 치 남길지를 전부 고르게 되어 있고, 고르지 않으면 기본값이 대신 적용됩니다. 그 기본값이 대개 넉넉한 쪽이라 비용이 먼저 티가 납니다. 이 부분을 비워 둔 채 반년을 보내면 청구서를 열고 나서야 쓰지 않는 기계 열두 대를 발견하게 됩니다.