AVM 등장 후 내 Bicep 모듈을 버려야 하는지 판단하는 5단계 방법
- AVM 성숙으로 기존 Bicep 모듈 재평가 필요해짐
- 작업은 유지·적응·폐기 3갈래로 나뉨
- 판단법은 5단계, 순서 준수가 핵심
신뢰할 수 있는 표준이 등장하면 그동안 직접 관리해온 코드는 계속 유지할 가치가 있는지 다시 따져봐야 하는 시점을 맞습니다. 한 개발자가 자신이 유지해온 Bicep 모듈과 Azure Verified Modules가 겹치기 시작하면서 겪은 이 판단 과정을 도메인에 상관없이 쓸 수 있는 5단계 방법론으로 정리했습니다.
Azure Verified Modules 등장, 내 Bicep 모듈은 유지·적응·폐기 중 무엇일까
핵심: 신뢰할 수 있는 표준이 등장하면 기존 작업은 유지·적응·폐기 세 갈래로 갈립니다.
Bicep은 Azure 리소스를 코드로 정의할 때 쓰는 도메인 전용 언어이고, Azure Verified Modules(AVM)는 이런 Bicep 모듈을 마이크로소프트가 공식적으로 관리하며 검증해 제공하는 표준 모듈 모음입니다. 저자는 그동안 자신이 직접 만들어 유지해온 Bicep 모듈이 있었는데, AVM이 실질적인 기준선(baseline)으로 성숙하면서 이 둘을 어떻게 비교해야 할지 고민하게 되었다고 설명합니다. 이 글은 저자가 실제로 사용한 판단 방법을 domain-agnostic(도메인에 무관하게 적용 가능한) 절차로 정리해 공유한 것입니다. 예시로 든 것은 Azure 마이그레이션이지만, 벤더 모듈 라이브러리, 관리형 서비스, 공식 레퍼런스 아키텍처 등 신뢰할 수 있는 표준이 기존 작업 옆에 나타나는 모든 상황에 같은 방법을 적용할 수 있다고 밝힙니다.
- 더 잘하는 것: 표준이 이제는 자신보다 더 잘 처리하는 영역
- 의견이 필요한 것: 표준이 다루긴 하지만 여전히 자신의 판단을 더해야 하는 영역
- 표준이 못하는 것: 표준이 전혀 다루지 않는 영역
저자는 이 판단을 잘못하면 양쪽 방향 모두에서 비용이 든다고 지적합니다. 너무 많이 유지하면 이제는 남이 대신 관리해주는 것의 열등한 복제본을 계속 떠안는 셈이 되고, 이는 바퀴를 다시 발명하고 있다는 신호로 읽힙니다. 반대로 너무 많이 버리면 애초에 그 작업이 존재했던 이유였던 진짜 차별점까지 함께 잃게 됩니다. 이 딜레마를 감으로 풀지 않기 위해 저자는 순서가 고정된 5단계 절차를 제시합니다.
| 단계 | 하는 일 | 이 순서가 필요한 이유 |
|---|---|---|
| 1. 인벤토리 | 보유한 것을 라벨이 아니라 실물로 확인 | 무엇을 판단할지 알아야 판단할 수 있음 |
| 2. 베이스라인 확인 | 표준을 1차 자료로 실제 검증 | 검증 안 된 표준과는 비교(중복 판정) 불가능 |
| 3. 판정 | 항목별로 유지·적응·폐기 결정 | 인벤토리와 베이스라인이 확정된 뒤에만 가능 |
| 4. 압박 테스트 | '유지' 판정에 다시 도전 | 판정(결론)이 틀릴 가능성과 대가가 가장 큼 |
| 5. 근거 기록 | 판정 이유를 기록 | 판정 자체보다 이유가 더 오래 유효함 |
저자는 이 순서를 어기면 "자신 있지만 틀린 답"에 도달하게 된다고 경고합니다. 특히 4단계 압박 테스트는 원자료(raw material)가 아니라 이미 내린 결론, 즉 3단계에서 나온 판정에 다시 도전하는 단계입니다. '유지'로 판정한 항목이 가장 틀리기 쉽고 틀렸을 때 대가도 가장 크기 때문에, 판정이 확정된 뒤에야 이 항목들을 재검증하는 것이라고 설명합니다. 1단계 인벤토리 단계에서도 저자는 세 가지 원칙을 강조하는데, 폴더 이름이 modules/여도 실제로는 버려진 실험이 들어있을 수 있고 README가 더 이상 존재하지 않는 구조를 설명할 수도 있으므로 라벨이 아니라 실제 아티팩트를 확인해야 하며, 자기 설명은 확인해야 할 가설일 뿐 사실이 아니라는 점, 그리고 각 항목에 대해 실제로 자신이 만든 것인지 소유권(provenance)을 먼저 확인해야 한다는 점입니다.
이게 나에게 의미하는 것
Bicep 모듈이나 이와 비슷한 인프라 코드를 자체적으로 관리해온 개발자라면, AVM처럼 새로 성숙한 표준이 자신의 모듈과 겹치는 영역이 있는지부터 실물 기준으로 다시 점검해볼 만합니다. 라이브러리나 프레임워크 영역에서 신뢰할 수 있는 공식 표준이 새로 등장했다면, 감으로 유지 여부를 정하는 대신 인벤토리부터 근거 기록까지 순서를 지키는 5단계를 적용하면 판단 착오를 줄일 수 있습니다. 특히 '유지'로 결론 낸 항목이 있다면, 그 결론 자체를 다시 의심해보는 압박 테스트 단계를 건너뛰지 않는 것이 핵심입니다.
정리: 오늘의 시사점
이 판단법의 핵심은 순서입니다. 인벤토리(실물 확인)와 베이스라인(1차 자료 검증)이 끝나기 전에는 판정을 내릴 수 없고, 판정이 끝나기 전에는 압박 테스트를 할 수 없습니다. 압박 테스트는 원자료를 다시 훑는 단계가 아니라, '유지'라는 결론이 틀렸을 가능성을 정면으로 의심하는 단계라는 점이 이 방법론의 가장 실용적인 포인트입니다. 마지막 단계인 근거 기록은 판정 자체보다 그 판정을 내린 이유가 더 오래 쓰인다는 저자의 관찰에서 나온 것으로, 나중에 표준이 다시 바뀌었을 때도 왜 그렇게 결정했는지 되짚을 수 있게 해줍니다.