Terraform 도입기 (5): 15개월 회고
잘했다고 생각하는 결정과 아쉬운 결정, 아직 남아 있는 숙제. 그리고 다시 시작한다면 다르게 할 것들.
시리즈 · Terraform 도입기5 / 5
시리즈의 마지막 글이다. 그동안 한 결정들을 잘한 것과 아쉬운 것으로 나눠 본다.
잘했다고 생각하는 것
State를 잘게 쪼갠 것. 가장 덕을 많이 본 결정이다. 어느 스택에서 실수를 하든 그게 다른 스택으로 번질 길이 없다. plan이 짧아서 실제로 읽게 된다는 것도 컸다.
재미없는 코드를 고른 것. 서버 하나에 파일 하나, 얇은 모듈. 비슷한 코드가 반복되는 걸 볼 때마다 정리하고 싶은 마음이 들긴 한다. 그래도 코드가 보이는 대로 동작한다는 건 포기하기 어려운 장점이다. 인프라 코드는 작성하는 횟수보다 급할 때 읽는 횟수가 훨씬 많다.
고치기 전에 먼저 옮긴 것. 처음 한 달 동안 아무것도 개선하지 않고 옮기기만 했다. 그 덕에 이후의 개선을 전부 리뷰를 받으면서, 하나씩, 되돌릴 수 있는 상태로 할 수 있었다.
처음 설계를 일찍 버린 것. 2주 만에 구조를 바꿨는데, 리소스가 몇 개 없을 때 바꾼 게 제일 싸게 먹혔다.
권한 구조와 도구를 같이 준 것. MFA 강제를 도입하면서 한 줄짜리 로그인 명령을 같이 넣었다. 규칙만 만들고 불편은 각자 알아서 하라고 했으면 예외 요청이 쏟아졌을 것이다.
아쉬운 것
복사해서 붙인 파일이 너무 많다. 스택마다 백엔드 설정, 프로바이더 설정, 변수 선언이 거의 똑같이 들어 있다. 스택을 잘게 쪼갠 대가다. 한 번은 모든 스택의 백엔드 설정에 같은 네 줄을 추가해야 했는데, 파일 열다섯 개를 똑같이 고친 PR이 됐다. 지금은 스택이 더 늘었다. 이 중복을 줄여 주는 도구가 있다는 건 알지만, 도구를 하나 더 들이는 비용과 저울질하다가 아직 결정을 못 했다.
비밀 값을 넣는 방식. 변수 파일의 자리 표시를 CI가 문자열 치환으로 바꿔 넣는다. 돌아가긴 하는데, 비밀이 하나 늘 때마다 파이프라인 코드를 고쳐야 하고 로컬에서 실행하는 사람은 따로 챙겨야 한다. 처음 CI를 만들 때 “나중에 고치자”고 적어 둔 게 아직 그대로다. 임시방편은 돌아가는 한 안 고쳐진다는 걸 다시 배웠다.
머지와 적용 사이의 틈. Apply를 사람이 하기로 한 건 지금도 맞다고 생각한다. 하지만 머지만 되고 적용이 안 된 상태를 알려 주는 장치가 없다. 사람의 기억에 기대고 있고, 가끔 어긋난다. 적용까지 자동으로 하지는 않더라도 main과 실제 인프라가 다르면 알려 주는 정기 점검 정도는 있어야 한다.
이름에 남은 흔적들. 처음 구조를 잡을 때 참고한 코드에서 따라온 변수 이름이 있다. 우리가 쓴 적도 없는 도구의 이름이 들어간 변수가 모든 스택에 선언돼 있다. old, new 디렉토리가 그렇다. new가 만들어진 지 한참 지났으니 더는 새것이 아니다. 동작에는 아무 문제가 없어서 계속 밀린다. 이런 건 아마 끝까지 남을 것 같다.
다시 시작한다면
구조는 그대로 갈 것이다. 리소스 종류와 환경으로 쪼개고, 모듈은 얇게, 서버 하나에 파일 하나.
바꿀 건 주변부다. 비밀 값은 처음부터 환경 변수로 넘긴다. 스택 공통 설정은 스택이 다섯 개를 넘기 전에 한곳으로 모을 방법을 정한다. 그리고 IAM 구조 개편을 반년씩 미루지 않는다. 파이프라인보다 권한을 먼저 잡았어야 했다.
돌아보면 아쉬운 것들은 전부 “나중에 하자”고 한 것들이다. 구조에 관한 결정은 대체로 버텼고, 미뤄 둔 것들이 빚으로 남았다.
마치며
Terraform을 도입한다고 인프라가 저절로 좋아지지는 않았다. 달라진 건 인프라를 고치는 일이 다른 사람이 볼 수 있는 일이 됐다는 것이다. 혼자 콘솔에서 하던 일이 PR이 되고, PR에 리뷰가 달리고, 리뷰가 기록으로 남는다. 보안 그룹을 좁히거나 권한 구조를 바꾸는 식의 개선은 전부 그 위에서 가능했다.
처음에 원했던 건 “이 포트 왜 열려 있어요?“에 답할 수 있게 되는 것이었다. 지금은 답할 수 있다.