설정 언어를 바꾼다고 드리프트가 고쳐지지는 않는다

납득이 안 된다. 드리프트가 언어 탓이 아니라는 건, 거기까지는 동의한다. 그런데 HCL 파일은 어차피 프로그래밍 언어로 자란다. for 표현식, 조건식, 함수, 모듈을 부르는 모듈. 결국 진짜 로직을 쓰게 되는데, 한 단계씩 따라가거나 한 조각만 떼어 시험할 도구는 훨씬 빈약하다.

그 지경이면 차라리 진짜 언어를 쓰고, 프로그램은 멍청하게 유지한다는 규칙을 두겠다. 평평한 데이터가 들어가고 리소스 목록이 나오고, 그 사이엔 영리함이 없다.

plan 검사가 크게 실패하려면, 그 plan을 읽는 정책이 실패할 수 있어야 합니다. 본문에서 input.resource.encrypted == false를 검사하는 규칙은 필드가 없으면 undefined가 되고, 규칙은 아무것도 내지 않으며 리소스는 통과합니다. 그 필드를 빼 보십시오. 쿼리는 무엇을 돌려줍니까? 빠진 속성과 명시적인 false를 둘 다 입력으로 시험해 보십시오. 거부되는 것은 그중 하나뿐입니다.

진짜 언어를 쓰면 에디터에서 타입을 얻는 건 맞고, 실행 전에 속성 이름 오타를 잡는 건 분명 가치가 있어요. 그래도 그건 프로그램이 보내려던 것을 설명할 뿐이에요. 제공자 쪽에서 우리 타입에 없는 필드를 돌려주면 어느 분기로 가나요? 실제 상태가 처음 드러나는 곳은 plan이고, 우리 쪽 어떤 것도 그걸 들여다본 적이 없어요.

에디터까지만 보면 맞아요. 생성하는 설정에 Python의 TypedDict로 타입을 붙이면 체커가 실행 전에 호출 지점에서 키 오타를 잡아 줘요. 그건 정말 쓸모 있어요. 그런데 TypedDict는 실행 시점엔 그냥 dict라서, 제공자에게서 다시 읽어 온 값은 직접 검증하지 않는 한 네트워크로 온 그대로예요.

저는 이 둘을 다른 일로 봐요. 타입이 붙은 생성, 그리고 검사된 입력. 어노테이션으로 공짜로 얻는 건 앞쪽뿐이고, 뒤쪽이 싸지는 날이 올지는 잘 모르겠어요.