코드형 인프라

서버를 빌려 쓰는 일이 쉬워지면서 기계 수가 빠르게 늘었습니다. 화면에서 사양을 고르고 만들기를 누르면 2분 뒤에 쓸 수 있으니, 필요할 때마다 한 대씩 만들었습니다. 문제는 그렇게 만든 구성이 어디에도 적혀 있지 않다는 점이었습니다. 어떤 설정을 눌렀는지는 누른 사람의 기억에만 남았습니다.

여섯 달쯤 지나면 같은 일이 벌어집니다. 개발용 서버에서는 잘 돌던 것이 운영 서버에 올리면 죽습니다. 두 서버가 똑같다고 믿었는데 실제로는 한쪽에만 설정이 하나 더 걸려 있었던 식입니다. 원인을 찾는 데 하루를 쓰고, 찾아도 "누가 언제 왜 이걸 켰는지" 는 끝내 모릅니다. 목적이 다른 실행 공간을 환경이라 부르는데, 환경끼리 이렇게 조금씩 어긋나면 개발 단계에서 하는 확인이 의미를 잃습니다.

만든 사람이 회사를 떠나면 더 곤란해집니다. 남은 사람은 돌아가는 서버를 보며 왜 이렇게 되어 있는지를 역으로 추측해야 하고, 겁이 나서 아무것도 건드리지 못합니다. 코드형 인프라는 이 기억을 파일로 꺼내 온 방식입니다. 구성을 문장으로 적어 두면 사람이 바뀌어도 그 파일이 남습니다.

원하는 구성을 파일에 적고, 그 파일을 도구에 넘겨 실제 자원을 만들게 합니다. 실제로는 다섯 단계로 돕니다.

1. 원하는 상태를 파일에 적습니다. "이 사양의 서버 세 대, 앞에 요청을 나눠 보내는 장치 하나, 이 대역만 접속 허용" 같은 것을 정해진 문법으로 씁니다. 순서를 적는 게 아니라 결과를 적는다는 점이 중요한 차이입니다. 무엇을 어떻게 만들지는 도구가 정합니다.
2. 그 파일을 버전 관리에 올립니다. 코드 변경 이력을 남기고 합쳐 가는 체계인데, 여기에 올리는 순간 누가 언제 무엇을 바꿨는지가 저절로 기록됩니다. 앞 절에서 끝내 알 수 없던 것이 이 단계에서 해결됩니다.
3. 바꾼 내용을 코드 리뷰에 올립니다. 합치기 전에 동료가 살펴보는 절차입니다. 방화벽 규칙 한 줄을 잘못 지우면 서비스가 멈추기 때문에, 인프라 변경은 기능 코드보다 리뷰를 더 깐깐하게 보는 팀이 많습니다.
4. 적용하기 전에 미리보기를 돌립니다. 도구가 지금 상태와 파일을 대조해 "서버 2대 추가, 보안 규칙 1개 수정, 데이터베이스 1개 삭제" 처럼 할 일 목록을 보여 줍니다. 여기서 삭제 항목이 보이면 대개 파일을 잘못 쓴 것입니다.
5. 적용합니다. 이후 어떤 변경도 화면에서 하지 않습니다. 급해서 한 번 손으로 고치면 파일과 실제가 어긋나고, 다음 적용 때 도구가 그 변경을 원래대로 되돌려 버립니다.

같은 구성을 여러 벌 만들어야 할 때 값이 가장 큽니다. 개발·스테이징·운영을 같은 파일로 찍어 내면 세 환경이 어긋날 여지가 없습니다. 고객사마다 환경을 따로 띄워 주는 제품이라면 100벌을 같은 파일로 세울 수 있습니다. 통째로 날아간 상황에서도 파일만 있으면 다시 세우므로, 복구 계획이 문서가 아니라 실행 가능한 형태로 남습니다.

구성이 자주 바뀌는 팀에도 맞습니다. 변경이 파일로 오가면 어제 상태로 되돌리는 일이 파일 한 번 되돌리기로 끝나서, 잘못 올린 설정을 롤백하는 데 몇 분이면 됩니다. 기억에 의존하는 구성에서는 같은 일이 몇 시간짜리 복구 작업이 됩니다.

반대로 서버 한두 대로 몇 년 버틸 서비스라면 굳이 들일 이유가 적습니다. 도구 문법을 익히고 첫 구성을 옮기는 데만 23주가 걸리는데, 그 사이 얻는 것은 클릭 몇 번을 아끼는 정도입니다. 구성이 반년에 한 번 바뀌는 상황이라면 그 23주를 회수하지 못합니다.

한계는 셋입니다. 첫째, 도구가 지금 무엇이 있는지를 따로 저장해 두는데 이 기록이 깨지면 도구가 멀쩡한 서버를 없는 것으로 보고 새로 만듭니다. 둘째, 손으로 고친 변경과 파일이 어긋나는 일이 계속 생깁니다. 새벽 장애 때 누군가 급히 설정을 바꿔 두면 다음 적용에서 소리 없이 되돌아갑니다. 셋째, 파일 한 줄을 잘못 쓰고 적용하면 사람보다 빠르고 정확하게 망가집니다. 클릭은 한 번에 하나씩 지우지만 코드는 한 번에 서른 개를 지웁니다. 그래서 4단계 미리보기를 건너뛰지 않는 것이 실무에서는 가장 중요한 습관입니다.

"이거 콘솔에서 바꾸지 마시고 코드로 올려 주세요. 다음 배포 때 날아갑니다."

화면에서 직접 고친 설정은 파일과 어긋나 곧 되돌아간다는 경고입니다.

"미리보기에 삭제 두 건이 떠요. 적용하기 전에 같이 봐 주세요."

지우려던 게 아닌 자원이 목록에 올라왔으니 파일이 잘못됐을 가능성이 크다는 뜻입니다.

"스테이징은 코드로 세워 놨는데 운영만 아직 손으로 만든 상태예요."

정작 중요한 환경이 기록 없이 남아 있어 먼저 옮겨야 한다는 말입니다.

페이지덱에서는 태오가 인프라 파일을 관리합니다. 서버 사양을 바꾸거나 접속 허용 대역을 더할 때도 코드 파일을 고쳐 풀 리퀘스트로 올리고, 다른 개발자가 미리보기 결과를 함께 본 뒤에 적용합니다. 기능 코드와 같은 절차를 그대로 씁니다.

한 번은 접속이 몰려 급히 서버 대수를 화면에서 늘린 적이 있습니다. 그날은 넘겼지만 이틀 뒤 다른 변경을 적용하면서 대수가 원래 값으로 돌아가 다시 느려졌습니다. 그 뒤로는 급한 변경도 파일을 먼저 고치고 적용하는 쪽으로 정리했습니다.

인프라를 자동으로 만들어 주는 도구라고 읽는 경우가 많습니다. 실행 한 번에 서버가 생기니 그렇게 보입니다. 하지만 이 방식이 진짜로 하는 일은 구성을 기록으로 남기는 것입니다. 만드는 속도는 부수 효과이고, 값은 여섯 달 뒤에 "이 설정 왜 이래요" 라는 질문에 파일을 열어 답할 수 있다는 데서 나옵니다. 속도만 보고 들인 팀은 급할 때마다 화면에서 고치고, 반년 뒤에는 파일과 실제가 달라 아무도 그 파일을 믿지 않게 됩니다.

한 번 적어 두면 끝난다고 여기는 것도 흔합니다. 인프라 파일은 제품 코드와 같은 속도로 낡습니다. 도구와 사업자 쪽 문법이 바뀌고, 쓰던 서버 종류가 단종되고, 규칙 하나가 더는 통하지 않게 됩니다. 1년쯤 손대지 않은 파일은 적용을 눌렀을 때 그대로 돌지 않는 경우가 많아서, 정기적으로 돌려 보며 손봐 두어야 정작 필요한 날 쓸 수 있습니다.