플랫폼 엔지니어링으로 확장하기

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

원제 : バックエンドエンジニアのためのインフラ・クラウド大全
저자 : 馬場俊彰 바바 도시아키
출간 : SHOEISHA, 2025 / 한빛미디어, 2026

거의 대부분의 IT 개발 직렬이 소프트웨어와 코드로 제어가 가능한시대가 되었더라도 그 이면에는 변하지 않는 것들이 있다. 실제 세계의 운영 전략과 소프트웨어가 해줄 수 없는 테크니컬 엔지니어링은 좀처럼 학교나 학원에서는 알려주지 않는다. 시스템을 설계 할때. 소프트웨어 아키텍처 뿐만 아니라 소프트웨어가 돌아갈 인프라에 대해서도 분명히 설계가 필요하다. 인프라 아키텍처는 어떤식으로 이뤄질까? 그 안에서는 소프트웨어 제품과 서비스를 지탱하기 위해 어떤 전략과 기술이 필요할까? 오늘 소개할 책은 IT에서 잘 변하지 않지만, 알고 나면 매우 넓은 시야를 가질 수 있게 도와준다.

가용성은 대수를 세는 문제가 아니었다

인프라 설계라고 하면 서버 몇 대와 구성도 한 장을 떠올렸는데, 저자는 그보다 앞에서 무엇을 얼마나 튼튼하게 만들지부터 정한다. 기능 요건과 비기능 요건이라는 개발 공정의 구분은 사용자 가치를 기준으로 다시 나뉘고, 가치는 유용성과 안정성으로 갈라지는데 어느 하나만으로는 성립하지 않는다.

안정성은 여섯 갈래로 뻗고 갈래마다 묻는 질문이 다르다. 기대한 대로 계속 도는지, 지금 쓸 수 있는지, 몰려드는 사용자를 다 받는지, 쓰는 동안 답답하지 않은지, 맡긴 정보가 안전한지가 다 다른 질문이고, 마지막 갈래는 이 수준을 몇 년 뒤에도 감당할 수 있느냐를 묻는다. 거기서 비용이 안정성의 항목으로 들어온다는 점이 눈에 걸렸다. 비용을 빼놓으면 지금 버티는 구성이 내년에도 버틴다고 말할 수가 없다.

갈래마다 부딪히는 한계도 따로 있다. 서버 한 대의 가용성, 디스크 하나의 지속성, CPU 하나의 성능에는 각각 상한이 있고, 높은 안정성은 여러 개로 나눠 그 한계를 넘는 설계로만 얻어진다. 그 상한을 어디에 둘지 정하는 것이 인프라다.

개인적으로 가용성 몇 나인이라는 숫자가 어디서 나오는지 궁금했는데 여기서 풀렸다. 가동률은 평균 고장 간격을, 거기에 평균 복구 시간을 더한 값으로 나눈 수다. 분모에 무엇이 들어가는지만 봐도 투자 방향이 갈린다. 하드웨어는 고장 간격을 늘리는 쪽에 돈을 쓰고, 소프트웨어는 고장 간격을 예측할 도리가 없으니 복구 시간을 줄이는 쪽에 손을 댄다. 그리고 이 값들은 이어 붙는 만큼 곱해진다. 0.99가 셋이면 97%로 내려가니 한 곳을 크게 올리기보다 전반을 끌어올리는 편이 낫고, 전체가 이중화돼 있어도 한 군데가 안 돼 있으면 거기가 전부를 결정한다.

여분을 몇 대 둘지보다 그 여분을 다시 채우는 데 몇 주가 걸리는지가 실제 변수라는 문장에서 한참 멈췄다. 이중화를 대수 세는 문제로만 알고 있었기 때문이다. 예비기 한 대를 쓰면 다음 장비가 들어오기까지는 여분 없이 버티는 셈이고, 그 구간의 길이는 대수가 아니라 조달과 반입에 걸리는 시간이 정한다. 대수는 구성도에 적히는데 회복 속도는 어디에도 안 적힌다.

역할 단위로 쪼개면 구성 요소가 늘고, 곱해야 할 값이 늘어난 만큼 이론상 가용성은 내려간다. 그런데도 결과는 나아진다는 게 이 대목의 핵심이다. 한 덩어리로 두면 가장 까다로운 역할의 요구에 전체를 맞추게 되고, 쪼개 두면 역할마다 특성에 맞는 구성을 따로 얹을 수 있다. 이론값을 조금 내주고 실제 값을 올리는 트레이드오프라, 소프트웨어 아키텍처 The Hard Parts에서 본 이야기와 같다. db-primary라는 이름이 ‘지금 db-primary가 세컨더리로 동작 중’이라는 문장을 만들어낸다는 대목도 그렇다. 장비와 역할은 독립적인 개념이어야 한다는 조언을 여기서 처음 납득했다.

결국 안정성은 튼튼한 장비를 고르는 문제가 아니라 어디가 가장 약한지를 아는 문제였다. 이어 붙는 만큼 깎이는 값도, 여분을 다시 채우기까지 걸리는 시간도 약한 데가 어디인지 알 때 계산에 들어온다.

‘느리다’는 아직 데이터가 아니다

가장 약한 데를 봐야 한다는 건 알겠는데, 그게 어디인지 찾는 방법은 따로 배워야 했다. 느리다는 말을 들으면 나는 서버를 늘리는 그림을 먼저 떠올렸다. 그런데 처리량을 결정하는 것은 시스템 전체가 아니라 병목 하나다. 첫 대응은 증설이 아니라 병목 특정이고, 병목이 아닌 곳을 개선하면 효과가 0이 아니라 마이너스가 될 수도 있다.

수평 확장은 양을, 수직 확장은 질을, 성능 튜닝은 효율을 다루고 병용하지 않으면 비용 대비 성능이 오르지 않는다. 뜻밖이었던 건 수평 확장의 비용이 애플리케이션에 청구된다는 대목이다. 스케일 아웃은 인프라 쪽 작업이라 여겨왔는데, 결과적 일관성을 허용할 수 있어야 효과가 나고 어느 노드가 무슨 작업을 받아도 처리되는 상태가 부하 분산 알고리즘보다 먼저다. 스테이트리스 프로세스와 빠른 실행, 그레이스풀 셧다운이 확장의 전제이고, 그것을 열두 항목으로 묶어 놓은 것이 The Twelve-Factor App 이다. 그동안 배포 설정 모범 사례쯤으로 읽었는데 확장의 전제를 적어둔 문서로 다시 읽혔다.

성능 튜닝의 시작점도 기술이 아니라 서비스 이해다. 인터넷에 도는 튜닝 레시피는 특정 병목을 전제한 해법이라 그 전제가 성립하는지는 데이터만 답하고, 데이터가 없으면 계측 지점 추가가 첫 작업이다. 검색해서 가져다 붙였던 설정들도 실은 남의 병목에 맞춰진 값이었던 셈이다.

판정의 순서도 뒤집혔다. 예전에는 감시 시스템이 먼저 이상 여부를 판정했고, 지금은 가리지 않고 모은 텔레메트리로 사실을 확보한 다음 판단한다. 럼즈펠드의 분류는 문제를 아는지와 해법이 있는지에 따라 네 가지 경우를 나눈다. 관찰 가능성이 맡는 쪽은 무엇을 감시해야 할지조차 미리 정할 수 없는 경우다.

감시를 늘리면 안정성이 올라간다고 막연히 여겨왔던 터라 감시가 가용성을 높이지는 않는다는 대목에서 걸렸다. 감시는 발생한 장애를 장기화시키지 않을 뿐이고, 이론값 자체를 올리는 건 이중화와 자기 복구이며 발생 횟수를 줄이는 건 용량 계획이다. 측정은 어디를 고칠지 알려주지만 고치는 것은 여전히 따로 해야 하는 일이었다.

인프라라는 말은 대개 내 담당 아래를 가리킨다

측정이 판단의 출발점이라면, 그 측정을 누가 맡느냐는 담당 범위 문제로 넘어간다. 엔지니어는 대개 자기 담당보다 아래를 인프라라고 여긴다는 관찰에 그대로 걸렸다. 그 선이 몇 번 움직이는 것도 봤다. 랙과 전원이 일이던 시절에는 그 위가 남의 영역이었고, 지금은 그때 만지던 것들이 남이 관리해 주는 자원이 되어 아래에 깔려 있다. 담당을 가른 건 기술이 아니라 어디까지 책임지느냐였다.

계층을 가르는 인터페이스는 두 가지를 한꺼번에 만든다. 위와 아래가 서로의 속을 몰라도 맞물리게 하는 호환성, 그리고 누가 무엇까지 맡을지의 분담이다. 그래서 팀 경계는 대개 기술 경계의 부산물로 생긴다. 조직도를 놓고 나눈 게 아니라 인터페이스가 있는 자리에 사람이 갈라져 붙는 것에 가깝다.

계층이 나뉘어 있다는 건 커리어를 옳겨 다니며 몸으로 익혔다. 다만 현장에 있는 동안은 정해진 범위 안에서 만들고 돌리는 일이 먼저였고, 그 범위를 누가 어떤 기준으로 정했는지는 알 방법이 없었다. 이번에 처음 본 것은 계층의 존재가 아니라 어디까지가 내 일인지를 정하는 기준이었다. 계층화는 벽을 세워 효율을 얻는 기술인데, 변화가 빠른 환경은 그 벽을 허물라고 요구한다. ‘You build it, you run it’은 만든 사람이 운영까지 따라 내려오라는 말이고, 인프라라고 부르며 밀어두었던 일이 내 담당으로 들어온다는 뜻이기도 하다.

담당을 아래로 넓히면 무엇이 따라오는지는 테넌시에서 가장 또렷하게 보인다. 테넌트마다 인스턴스를 따로 두는 것부터 같은 테이블 안에서 행으로만 구분하는 것까지, 어느 계층에서 가를지가 선택지다. 아래로 내릴수록 자원을 함께 쓰니 비용 효율은 올라가고 격리 강도는 내려간다. 격리를 지키는 책임도 인프라에서 코드로 넘어온다. 인스턴스로 갈라 두었다면 조건 하나를 빠뜨려도 다른 테넌트에 닿을 길이 없다. 행으로 갈라 두었다면 남은 안전장치는 리뷰와 테스트, 그리고 쿼리를 쓰는 코드 뿐이다.

그러니 이 결정은 기술 취향으로 끝나지 않고 결론이 사업 쪽에서 나온다. 고객이 요구하는 격리 수준과 감당할 수 있는 단가가 계층을 정하고, 그렇게 정해진 계층이 코드가 짊어질 위험의 크기를 정한다. ‘우리는 멀티 테넌트다’라는 말이 어느 계층에서 갈랐는지를 빼면 정보량이 거의 없는 이유도 여기에 있다. 벽을 허문다는 말이 구호처럼 들렸다면, 실제로 손에 남는 건 where 절 하나다.

혼자 감당할 수 없는 것은 제품이 된다

벽을 허물라는 요구만으로는 그 where 절이 안전해지지 않는다. 저자의 답은 개발자를 고객으로 두는 쪽이다. 개발자 경험이라는 말을 복지나 사기 문제로만 들어왔는데, 가용성과 용량, 성능, 보안과 나란히 사용자 가치 그림 위에 같은 층으로 올라와 있는 걸 보고 다시 생각하게 됐다.

SLI는 측정값이고 SLO는 목표치이며, 100%에서 SLO를 뺀 값이 허용 오류 한계다. 이만큼은 틀려도 된다고 미리 떼어 둔 몫이라, 다 쓰고 나면 안정성이 사용자의 인내 한계를 밑돈다는 뜻이 되고 투자를 유용성에서 안정성으로 옮기라는 신호가 된다. 다만 SLO를 팀 목표나 인사 평가에 올리면 사람들은 시스템을 개선하는 대신 숫자를 개선한다.

플랫폼 엔지니어링이 줄이려는 것은 개발자의 인지 부하다. 배포 방법과 개발 규칙, 툴체인처럼 문제 밖에서 오는 부하를 걷어내 도메인과 학습에 인지 자원을 쓰게 만드는 일이다. 과거의 공통 플랫폼이 투자 효율과 생산성을 봤다면, 이쪽은 개발자 한 사람의 인지 부하를 먼저 본다. 그래서 제공 항목을 읽다 보면 앞에서 흩어져 나왔던 것들이 한 묶음으로 돌아온다. 확장의 전제를 개발자가 매번 외워 지키는 대신 배포 템플릿에 미리 심어 두고, 복구 시간을 줄이는 장치를 팀마다 만드는 대신 기본으로 깔아 둔다. 가동률 식에서 손대야 한다고 했던 것들이 개발자가 고르지 않아도 딸려 오는 기본값이 되는 셈이다.

플랫폼은 개발자를 고객으로 하는 제품이라 쓸지 말지는 개발팀이 정하고 경영진이나 플랫폼 팀이 강요해서는 안 된다고 한다. 강요된 도구는 우회로를 만들고 그 우회로가 다시 팀별 편차가 되니, 골라 쓰게 만드는 편이 결국 빠르다는 이야기로 읽었다.

운영 중인 서비스에 기능 하나를 새로 얹을 때 내가 확인하던 것은 코드가 제대로 도는지까지였다. 정작 걸리는 건 그게 아니다. 이게 감시에 잡히나, 새벽에 터지면 누가 받나, 데이터는 언제 어디로 백업되나, 예상보다 두 배가 들어와도 버티나. 올리기 전에 한자리에서 이것들을 짚고 넘어가는 절차가 프로덕션 레디니스 리뷰이고, 무엇을 물을지 적어둔 것이 체크리스트다. 다만 항목을 늘리는 방식은 빠르고 잦은 릴리스와 부딪혀 쉽게 한계에 닿는다. 그래서 반복되는 패턴은 묻는 항목으로 남기지 말고 플랫폼에 심어 별도의 노력 없이 충족되게 만들라고 한다. 체크리스트가 짧아지는 방향이 플랫폼이 자라는 방향이었다.

막연하게 알고만 있던 자리가 무엇을 보고 정하면 되는지까지 정리됐다. 이중화나 확장, 관찰 가능성은 이름도 알고 손으로도 겪은 것들인데, 언제 택하고 무엇을 내주는지는 그때그때의 감으로 정해왔다. 새벽에 호출을 받아 장애를 붙잡아본 적은 있어도, 그 장애가 어디까지 허용되는지를 숫자로 합의하고 예산처럼 쓰는 자리에는 서본 적이 없다. 이 책의 절반은 아직 겪어보지 못한 이야기지만, 그 자리에 서게 되는 날 무엇부터 볼지는 얻어간다.

아쉬운 점도 있다. 사전 형식이라 서술이 압축적이고 어떤 항목은 판단 근거보다 목록에 가깝다. 개념서라 코드나 설정 실물이 거의 없어 손으로 확인하려면 다른 자료가 필요하다. 두께가 상당해 통독할 물건도 아니어서, 기초를 먼저 읽고 나머지는 필요할 때 찾아 쓰라는 안내가 붙어 있다. 그래도 성능 튜닝과 장애 대응에서 판단 근거를 갖고 싶은 중급 이상 백엔드 엔지니어에게는 권한다. 반대로 특정 클라우드 자격증이나 당장의 구축 실습이 목적이라면 맞지 않는다. 정답집이 아니라 옆자리 시니어와 대화를 트는 계기로 쓰는 편이 이 두께를 가장 잘 쓰는 방법이라고 생각한다.