적용 전에 걸러 내는 세 가지

한 줄 요약

fmt 는 서식을, validate 는 구조를 본다. 둘 다 값은 보지 못하고, 그 틈을 console 이 메운다.

왜 이런 검사가 따로 필요했나

적용해 봐야 아는 사고는 비싸다. 계획을 세우려면 프로바이더를 받아야 하고, 상태를 읽어야 하고, 원격이라면 잠금까지 잡아야 한다. 그런데 실제로 일어나는 실수의 상당수는 설정 파일만 읽어도 알 수 있는 것들이다. 선언하지 않은 변수를 참조했다거나, 필수 인자를 빠뜨렸다거나, 문자열 자리에 목록을 넣었다거나 하는 것들이다. 이런 것을 위해 계획까지 가는 것은 낭비다.

서식은 성격이 다르다. 틀린 것이 아니라 제각각인 것이 문제다. 설정 언어를 쓰는 팀이 들여쓰기 규칙을 회의로 정하기 시작하면 그 시간은 돌아오지 않고, 결과물인 리뷰 diff 는 내용이 아니라 공백으로 가득 찬다. 그래서 도구가 정답을 하나로 정해 두었다. 논쟁할 여지를 없앤 것이 이 명령의 설계 의도다.

어떻게 동작하나

tofu fmt 는 기본적으로 파일을 고친다. 판정만 하고 싶으면 확인 모드를 쓰고, 이때 종료 코드가 세 갈래로 갈린다.

tofu fmt -check -diff -recursive   # 고치지 않고 판정만# 0 : 고칠 것이 없다# 3 : 고칠 것이 있다# 2 : 파일을 읽을 수조차 없다(문법 오류)

게이트를 쓸 때 2 와 3 을 구분하면 메시지가 훨씬 친절해진다. 3 은 "서식 명령을 한 번 돌리세요" 이고, 2 는 "이 파일은 아예 파싱이 안 됩니다" 다. 하위 디렉터리까지 보려면 재귀 옵션이 필요하다 — 없으면 루트의 파일만 본다.

tofu validate 는 프로바이더 스키마가 있어야 하므로 init 을 먼저 해야 한다. 초기화하지 않은 디렉터리에서 돌리면 프로바이더가 없다고 말한다. 잡아 주는 것은 세 종류다.

Reference to undeclared input variable   선언 안 한 var.xxx 참조Missing required argument                필수 인자 누락Incorrect attribute value type           스키마와 타입 불일치

기계가 읽을 형식도 있다. -json 을 주면 valid, error_count, warning_count 와 진단 목록이 나와서 CI 가 그대로 판정하거나 리뷰에 붙일 수 있다.

중요한 것은 못 잡는 것이다. validate 는 상태도 실물도 보지 않고 변수 값도 모른다. 그래서 다음 설정은 아무 문제 없이 통과한다.

variable "seed_path" { type = string }resource "local_file" "out" {  filename = "${path.module}/out.txt"  content  = file(var.seed_path)}

구조는 완벽하다. 그런데 계획을 세우려 하면 두 군데서 막힌다. 값을 안 주면 "변수가 설정되지 않았다" 고 하고, 없는 경로를 주면 "그 경로에 파일이 없다" 고 한다. 둘 다 설정 파일 밖의 사실이라 정적 검사가 알 수 없다. validate 통과는 적용해도 된다는 뜻이 아니다.

세 번째 도구인 tofu console 은 현재 디렉터리의 변수와 locals 를 읽어 표현식을 한 줄씩 평가한다. 파일로 흘려 넣으면 비대화형으로도 쓸 수 있고, 첫 오류에서 멈추고 0 이 아닌 코드로 끝난다. 헷갈리는 변환을 확인하기에 좋다.

"5" + 5      ->  10       산술에서는 문자열이 수로 변환된다1 == "1"     ->  false    같다 비교에서는 변환되지 않는다

현장에서 만나는 모습

가장 흔한 것은 게이트 순서를 거꾸로 짠 CI 다. 구조 검사를 먼저 돌리면 문법이 깨진 파일 하나 때문에 알 수 없는 오류가 쏟아지고, 정작 원인인 "괄호를 안 닫았다" 는 파묻힌다. 서식 판정을 먼저 두면 그 파일을 곧바로 지목해 준다.

두 번째는 게이트가 저장소를 고치는 경우다. 고치는 모드를 CI 에 넣어 두면 검사가 통과하는 대신 작업 트리가 조용히 바뀌고, 사람은 자기가 커밋하지 않은 변경을 나중에 발견한다. 게이트에는 판정만 하는 모드를 쓴다.

세 번째는 앞에서 말한 오해다. "검사 다 통과했는데 왜 apply 가 터지죠" 라는 질문의 절반은 값 문제다. 정적 검사는 설정 파일의 문법과 구조를 보증할 뿐, 그 값이 가리키는 세상에 대해서는 아무 말도 하지 않는다. 그래서 검사 통과 다음에도 계획 리뷰가 남는다.

네 번째는 콘솔을 안 쓰는 팀이다. 표현식이 헷갈릴 때마다 설정을 고치고 적용하고 결과를 보는 왕복을 반복하는데, 그 한 바퀴가 몇 분씩 걸리고 실패하면 상태가 어중간해진다. 콘솔에서 한 줄로 확인하면 왕복이 사라진다. 특히 변환이 일어나는 자리 — 산술과 비교, 문자열과 숫자 사이 — 는 기억에 의존하지 말고 그 자리에서 찍어 보는 편이 빠르다.

다음 실습에서 할 것

여덟 단계를 돕니다. 서식이 어긋난 트리를 만들어 판정 종료 코드를 확인하고, 실제로 고친 뒤 다시 판정하고, 문법이 깨진 파일에서 코드가 또 달라지는 것을 봅니다. 이어서 구조 오류 두 개를 한 번에 잡는 기계 판독 출력을 만들고, 반대로 구조는 멀쩡한데 값 때문에 계획이 두 번 막히는 경우를 기록합니다. 마지막 두 단계에서는 콘솔로 표현식 네 개를 확인해 그중 하나를 실제 설정에 옮겨 적용하고, 서식 판정과 구조 검사를 순서대로 묶은 커밋 전 게이트를 직접 만듭니다.