Terraform 도입기 (1): 콘솔로 만든 인프라를 코드로 옮기기로 했다

빈 저장소를 하나 만들고 first commit을 올렸다. VPC를 만드는 일부터 누가 어느 서버에 접속할 수 있는지까지, 인프라에 손을 대는 일은 전부 이 저장소를 거친다.

리소스를 어떻게 만드는지 설명하는 글은 아니다. 그런 건 공식 문서가 훨씬 잘 알려 준다. 여기에는 그때그때 어떤 선택지가 있었고 왜 그쪽을 골랐는지를 적는다.

예제에 나오는 mh, app 같은 이름은 가명이다.

시작할 때의 모습

리소스는 전부 누군가 콘솔에서 손으로 만든 것이었다. 보안 그룹에는 설명 없는 규칙이 많았고, 설명이 있어도 그게 누구 IP인지, 아직 필요한지는 알 수 없었다. 스테이징과 운영이 어디가 다른지 보려면 콘솔 탭을 두 개 띄워 놓고 눈으로 비교해야 했다.

돌아가는 데는 문제가 없었다. 불편한 건 다른 쪽이었다. “이 포트 왜 열려 있어요?“라는 질문을 받으면 답할 방법이 없었다. 이력이 사람 머릿속이나 메신저 어딘가에만 있었기 때문이다.

원했던 것

그래서 Terraform에 기대한 건 자동화보다는 기록이었다.

보안 그룹 규칙 하나를 추가해도 커밋이 남고 PR이 남는다. 반년 뒤에 누가 물어보면 git blame 한 번으로 누가 언제 왜 열었는지 나온다. 적용하기 전에 뭐가 바뀌는지 다른 사람이 볼 수 있다. 콘솔에서는 저장 버튼을 누르는 순간이 곧 배포였는데, 그 사이에 한 단계가 생긴다. 지금 인프라가 어떻게 생겼는지 궁금하면 코드를 읽으면 된다.

반대로 인프라를 빠르게 찍어 내는 능력은 별로 필요하지 않았다. 서버가 수백 대씩 있는 조직이 아니다. 같은 걸 열 번 만드는 일보다 하나뿐인 걸 조심해서 고치는 일이 훨씬 많다. 이 사실이 뒤에 나오는 결정들에 꽤 큰 영향을 줬다. 세련된 추상화를 여러 번 포기했는데, 대부분 이 이유였다.

붙들고 있던 생각들

처음부터 원칙을 세워 놓고 시작한 건 아니다. 지금 저장소를 다시 훑어보면서, 계속 같은 방향으로 결정해 왔구나 싶은 것들을 추렸다.

State는 작게 쪼갠다. 보안 그룹 규칙 하나 고치려고 plan을 돌렸는데 변경 목록에 RDS가 보이는 상황 자체를 만들지 않는다. 한 번의 apply가 건드릴 수 있는 범위가 곧 사고가 날 수 있는 최대 크기라고 생각했다.

똑똑한 코드보다 읽히는 코드. 모듈은 얇게, 서버 하나에 파일 하나. 반복은 생기지만 PR에서 파일 하나만 봐도 무슨 일이 일어나는지 안다.

있는 걸 먼저 옮긴다. 마음에 안 드는 구조라도 일단 그대로 코드로 가져온다. 고치는 건 그다음이다.

변경은 PR로. 리뷰하는 사람은 코드가 아니라 plan 결과, 그러니까 실제로 바뀔 내용을 보고 승인한다.

AWS 밖도 같은 방식으로. 누가 어느 서버에 들어갈 수 있는지도 인프라다. 같은 저장소, 같은 PR 흐름에 넣는다.

어떻게 흘러왔나

첫 한 달은 거의 구조를 잡고, 마이그레이션만 했다. IAM, 보안 그룹, VPC, RDS, EC2, 로드 밸런서 순서로 기존 리소스를 코드로 가져왔다. PR을 올리면 plan 결과가 댓글로 달리는 파이프라인을 붙였다.

그 뒤로는 저장소가 그냥 일상 업무 창구가 됐다. 커밋 로그를 보면 대부분 “보안 그룹에 IP 추가”, “디스크 증설”, “권한 부여” 같은 것들이다. 그 사이사이에 굵직한 작업이 끼어 있다. 신규 서비스 인프라를 처음부터 코드로 만든 것, IAM 구조를 뜯어고친 것, 서버 접근 제어를 Terraform 안으로 들인 것.

개인적으로는 사소한 커밋이 더 의미 있다고 생각한다. IP 하나 추가하는 일까지 콘솔 대신 저장소로 온다는 건, 이게 실제로 일하는 방식이 됐다는 뜻이니까.

이어지는 글

• 2편: 구조를 어떻게 잡았나
• 3편: 기존 인프라 옮기기
• 4편: PR과 Plan으로 일하기
• 5편: 15개월 회고