loop 와 when — 태스크가 아니라 데이터를 늘린다

한 줄 요약

같은 태스크를 복사해 열 개 만드는 대신, 태스크는 하나 두고 데이터를 열 줄로 만든다.

왜 이게 필요했나

사용자 세 명을 만드는 플레이북을 복사·붙여넣기로 쓰면, 네 번째 사용자가 생겼을 때 태스크를 하나 더 붙인다. 그런데 그중 하나만 권한 인자를 빠뜨리면 그 사용자만 설정이 다르다. 이 오류는 코드를 아무리 봐도 눈에 잘 안 띈다 — 네 개가 거의 같아 보이기 때문이다.

loop 는 이 구조적 위험을 없앤다. 태스크가 하나뿐이니 인자를 빠뜨릴 자리도 하나뿐이고, 데이터는 표처럼 보여 빠진 칸이 눈에 띈다.

어떻게 동작하나

loop 는 리스트를 받아 item 에 하나씩 넣어 태스크를 반복한다. 리스트 원소가 딕셔너리면 item.name 처럼 필드로 접근한다.

when 은 조건이다. loop 와 when 을 함께 쓰면 조건은 반복의 각 항목마다 평가된다. 즉 조건에 맞는 항목만 처리된다. 이 조합이 "조건부 반복"을 만든다.

주의할 조합이 몇 가지 있다.

| 도구 | 쓰임 | 함정 |
| --- | --- | --- |
| loop_control.label | 로그에 찍을 축약 이름 지정 | 지정하지 않으면 딕셔너리 전체가 로그에 노출됨 |
| until / retries / delay | 조건이 참이 될 때까지 재시도 | until 은 loop 와 함께 쓰기 까다로움 |
| product 필터 | 두 리스트의 모든 조합 | 조합 수가 곱으로 늘어남 |
| fileglob 조회 | 패턴에 맞는 파일 목록 | 순서가 보장되지 않음 |

loop_control.label 은 보안 문제이기도 하다. 딕셔너리에 비밀번호가 들어 있으면 기본 로그에 그대로 찍힌다. 라벨을 지정하거나 no_log 를 쓰는 것이 안전하다.

until 은 "될 때까지 기다린다"를 표현한다. 서비스가 뜨기를 기다리는 상황에 쓰지만, 재시도는 실패를 늦출 뿐 없애지 않는다. 재시도 횟수와 간격을 정할 때 "이 시간 안에 안 되면 진짜 문제"라는 판단이 함께 들어가야 한다.

현장에서 만나는 모습

첫째, 반복 안의 멱등성. 반복하는 태스크도 각 항목에 대해 멱등해야 한다. 반복이 열 번 돌면 비멱등의 피해도 열 배다.

둘째, 조합 폭발. 환경 3 × 컴포넌트 2 = 6 은 괜찮지만, 여기에 리전 5 를 곱하면 30 이 된다. 조합 반복은 편하지만 실행 시간과 로그 길이가 곱으로 늘어난다는 것을 계산에 넣어야 한다.

셋째, 순서에 의존하지 않기. 파일 패턴 조회의 결과 순서는 보장되지 않는다. 순서가 중요하면 정렬하거나 명시적 리스트를 쓴다.

다음 실습에서 할 것

리스트와 딕셔너리 리스트를 돌며 디렉터리를 만들고, when 으로 조건에 맞는 항목만 처리한다. loop_control.label 로 로그를 정리하고, until 로 대기 로직을 만든다. 두 리스트의 조합으로 6개 설정 파일을 만들고, 패턴으로 그것들을 다시 모은 뒤, 전체를 요약한 보고서로 마무리한다.