인프라 자동화와 설치 현장 지식¶

11/12(목)

한 줄 요약: Ansible·OpenTofu 같은 자동화 도구는 사람이 정해 준 입력을 반복해서 적용할 뿐이다. Ansible은 할 일을 순서대로 실행하는 절차형이고, OpenTofu는 최종 모습을 선언해 두고 차이만 맞추는 선언형이다. 어느 쪽이든 입력을 현장에 맞게 쓰는 지식이 일의 대부분이다.

📍 만난 상황¶

2026-11-12 — dhub2 저장소에서 현장 설치 업무를 생각하다가 2번 물음(→ 작업 7) → 그날 일지
17:57 새 세션을 열자마자 "dhub 설치는 그냥 앤서블 플레이북 명령(또는 tofu)을 쓰면 되는 거 아니야?"라고 물었다. → 명령은 현장 준비와 인벤토리 작성이 끝난 뒤의 마지막 단계라는 답을 들었다.
18:03 이 업무로 어떤 지식이 늘지 물었고, "다양한 환경을 접하는 폭은 넓다"는 답을 들었다. 이어서 "앤서블과 토푸의 차이가 뭔데?"라고 물었다. → 절차형과 선언형의 차이, state와 plan을 설명받았다.

🧩 쉽게 말하면¶

Ansible은 요리 레시피다. "물 끓이기 → 면 넣기 → 3분 뒤 불 끄기"를 위에서부터 그대로 따라 한다.

OpenTofu는 완성된 요리 사진이다. 지금 접시를 사진과 비교해서 빠진 것만 채우고, 사진에 없는 것은 치운다.

둘 다 같은 일을 사람 손 없이 반복해 준다. 하지만 어떤 요리를 할지, 그 주방에 가스가 들어오는지는 정해 주지 않는다. 그건 현장을 본 사람이 정한다.

도구가 없으면 고객마다 손으로 같은 설치를 하다가 실수가 난다. 현장 지식이 없으면 도구가 있어도 무엇을 넣어 돌릴지 모른다.

📖 제대로 알기¶

IaC¶

IaC(Infrastructure as Code: 서버·설정을 손 대신 코드 파일로 정의하고 적용하는 방식)의 대표 도구가 둘이다. 코드라서 git으로 이력을 남기고 리뷰할 수 있다.

Ansible: 절차형¶

대상 서버에 SSH(원격 접속 규약)로 들어가 작업(task)을 위에서 아래로 실행한다. 대상 서버에 따로 프로그램(에이전트)을 깔지 않는다.
인벤토리(inventory): 어느 서버에, 어떤 값으로 적용할지 적은 파일.
플레이북(playbook): 어떤 작업을 어떤 순서로 할지 적은 YAML 파일.
상태를 기억하지 않는다. 실행할 때마다 작업이 "이미 돼 있나?"를 직접 확인한다.
그래서 멱등성(idempotency: 여러 번 실행해도 결과가 같은 성질)을 갖게 짤 수 있다. 단, 작업을 그렇게 짰을 때만이다.
주 용도: 서버 설정(패키지 설치, 설정 파일 배포).

OpenTofu: 선언형¶

.tf 파일에 HCL(HashiCorp 설정 언어)로 리소스의 최종 모습을 적는다.
state 파일: 자기가 만든 리소스와 그 속성을 적어 둔 장부. "지금 무엇이 있나"의 기준이다.
provider: 클라우드·Kubernetes·Helm 같은 대상과 대화하는 플러그인.
tofu plan: 선언과 state를 비교해 생성·변경·삭제될 것을 미리 보여 준다.
tofu apply: 그 차이만 적용하고 state를 갱신한다.
2023년에 Terraform이 라이선스를 바꾸자 갈라져 나온 오픈소스판이다. 사용법이 거의 같아서 Tofu를 알면 Terraform도 쓸 수 있다.
주 용도: 인프라 생성(클라우드 VM, 네트워크, K8s 클러스터).

현장을 나누는 네 좌표¶

dhub 문서(ADR-0005)는 현장을 네 값으로 분류한다. 온프렘(on-premise: 고객 건물 안 서버) 설치에서 일반적으로 가장 먼저 묻는 항목이다.

좌표	선택지	결정되는 것
Egress(외부 인터넷)	된다 / 안 된다	안 되면 폐쇄망 번들, 클라우드 LLM 불가
DNS	공개 / 내부 / 없음	TLS 인증서 방식, 접속 주소
VIP(가상 대표 IP)	있음 / 없음	고객 인프라팀에서 대역 받기
GPU	없음 / 밖 / 안	LLM 주소, 드라이버 깔린 노드

에어갭(air-gap: 외부 인터넷이 끊긴 폐쇄망): 이미지·차트·실행 파일을 미리 한 묶음(번들)으로 싸 가야 한다.
이 밑에 Linux(방화벽 포트, 호스트 이름), Kubernetes(배포판, CNI: 파드끼리 통신하게 하는 네트워크 플러그인), 스토리지(StorageClass: 디스크를 어떤 방식으로 만들어 줄지 정한 설정) 지식이 깔린다.

⚙️ 어떻게 동작하나¶

두 도구가 한 번 실행될 때¶

Ansible 1. 인벤토리에서 대상 서버 목록과 변수를 읽는다. 2. 플레이북의 작업을 순서대로 실행한다. 이미 돼 있으면 ok, 바꿨으면 changed로 보고한다. 3. 끝난다. 무엇을 만들었는지 따로 기록하지 않는다.

OpenTofu 1. tofu init: provider를 내려받는다. 폐쇄망이면 미리 묶어 간 mirror(내려받기 사본)에서 가져온다. 2. tofu plan: 선언, state, 실제 상태를 비교해 차이를 계산한다. 3. tofu apply: 차이만 적용하고 결과를 state에 적는다.

flowchart LR
    D["선언<br/>.tf 파일"] --> P["tofu plan<br/>차이 계산"]
    S["state 파일<br/>지금 있는 것"] --> P
    P -->|"생성·변경·삭제 목록"| A["tofu apply"]
    A -->|"결과 기록"| S

state가 "지금 있는 것"의 장부다. 그래서 선언에서 뺀 리소스를 알아서 지울 수 있다. Ansible에는 이 장부가 없다.

현장 설치 전체에서 명령의 위치¶

현장 조사: 네 좌표, 서버 사양, 보안 규정을 받는다.
방식 결정: dhub는 지금 인터넷이 되는 현장은 ansible, 폐쇄망은 tofu 번들로 설치한다.
기반 확인: K8s 클러스터가 이미 있어야 한다. dhub 문서도 "ansible-playbook이 알아서 만들어 주지 않는다"고 적었다.
입력 작성: 고객별 인벤토리, 플레이북, 시크릿 파일을 새로 쓴다.
명령 실행: ansible-playbook -i <인벤토리> <플레이북> -e @<시크릿> 한 줄. 자동인 건 여기뿐이다.
검증·문제 해결: 막히는 곳은 대부분 Linux·K8s·스토리지 층이다.

🧪 예시¶

예시 1 · 일상에 빗대어: 상에 밥·국·반찬 3가지를 차린다. 내일부터 반찬 하나를 빼기로 했다.
레시피(Ansible)에서 "반찬 3 올리기" 줄을 지우고 다시 따라 한다. 이미 올라가 있던 반찬 3은 그대로 남는다. "반찬 3 치우기"를 따로 적어야 한다.
사진(Tofu)에서 반찬 3을 지운다. 장부와 비교해 "치울 것 1개"를 미리 보여 주고, 확인하면 치운다.
예시 2 · 실제로는: 같은 일(Helm 차트로 서비스 하나 올리기)을 두 도구로 적은 단순화한 모양이다.
```
# Ansible: 할 일을 순서대로
- name: 포털 차트 설치
  kubernetes.core.helm:
    name: portal
    chart_ref: ./charts/portal
    release_namespace: dhub
```
```
# OpenTofu: 있어야 할 모습을 선언
resource "helm_release" "portal" {
  name      = "portal"
  chart     = "./charts/portal"
  namespace = "dhub"
}
```
① Ansible 쪽은 "이 작업을 실행하라"는 명령문이다. 다음 작업이 아래에 줄줄이 붙는다. ② Tofu 쪽은 "portal 릴리스가 이렇게 있어야 한다"는 선언이다. 실행 순서는 도구가 의존 관계를 보고 정한다. ③ Tofu에서 이 블록을 지우면 다음 plan에 "portal 삭제"가 뜬다. Ansible에서 작업을 지우면 아무 일도 일어나지 않는다.

dhub 저장소도 두 도구로 같은 일을 한다. 이미 있는 K8s 위에 Helm 차트로 구성 요소를 올린다. Ansible은 roles/<서비스>/install/이 차례로 돌고, Tofu는 tofu/base/<서비스>.tf마다 helm_release가 하나씩 있다. 대부분의 현장은 Ansible이고, 일부와 폐쇄망(제주)만 Tofu다.

⚖️ 비교 · 흔한 오해¶

항목	Ansible	OpenTofu
적는 것	할 일의 순서(YAML)	최종 모습(HCL)
상태 기억	없음, 매번 확인	state 파일
미리 보기	`--check` 정도로 제한적	`tofu plan`
삭제	지우는 작업을 따로 적음	선언에서 빼면 지움
실행 환경	Python + 각종 collection	단일 바이너리

내가 생각한 것	실제
명령만 치면 설치 끝	입력 세 개를 현장마다 새로 써야 돈다
클러스터도 만들어 준다	dhub는 K8s가 이미 있다고 전제한다
이름만 다른 같은 도구	절차형 vs 선언형, 장부 유무가 다르다
어느 걸 쓸지는 취향	인터넷 여부 같은 현장 조건이 정한다

왜 그렇게 생각하기 쉬운가: 둘 다 "IaC 도구"로 함께 소개되고, 이 저장소에서도 같은 일(Helm 차트 설치)을 한다. 처음 설치 결과만 보면 차이가 안 보인다. 차이는 바꾸거나 지울 때 드러난다.

또 개발 환경에서는 누군가 미리 준비해 둔 곳에서 명령 한 줄만 본다. 그래서 "자동화"가 "다 알아서"로 들린다. 실제 뜻은 "같은 일을 사람 손 없이 반복"이다.

🛠️ 실무에서는¶

고르는 기준
서버 안을 설정(패키지·파일·서비스)하는 일 → Ansible이 자연스럽다.
리소스를 만들고 지우며 변경을 미리 보고 싶다 → Tofu.
폐쇄망 → tofu·kubectl 바이너리 몇 개와 provider mirror로 반입되는 Tofu가 유리하다. dhub가 Tofu로 옮기려는 이유(ADR-0007, 아직 제안 단계)도 이것과 plan 미리 보기다.
Tofu 주의점: state 파일을 잃거나 두 사람이 동시에 apply하면 꼬인다. state 보관 위치와 잠금을 먼저 정한다. 손으로 바꾼 설정은 다음 plan에 "되돌리기"로 뜬다.
Ansible 주의점: shell·command 작업은 멱등하지 않기 쉽다. 두 번 돌려서 changed가 0인지 본다.
현장 가기 전 체크: 외부 인터넷과 번들, DNS와 인증서, VIP 대역, GPU와 LLM 주소, K8s 배포판과 StorageClass, 방화벽 포트.
막혔을 때 먼저 볼 것: 파드 Pending → 스토리지·자원 부족. ImagePullBackOff → 이미지 저장소 접근·번들 누락. 접속 불가 → DNS·VIP·인증서 순.

❓ 자주 묻는 질문¶

Q. 설정에서 리소스 하나를 지우고 다시 실행하면 어떻게 되나? A. Ansible은 그 작업을 안 할 뿐, 이미 만든 건 남는다. Tofu는 state와 비교해 지운다. plan에 미리 보인다.
Q. Tofu를 배우면 Terraform도 할 줄 아는 건가? A. 거의 그렇다. 문법·명령·provider가 대부분 같다.
Q. 설치가 중간에 실패하면 처음부터 다시 하나? A. 원인만 고치고 같은 명령을 다시 돌린다. Ansible은 멱등하게 짠 작업을 건너뛰고, Tofu는 남은 차이만 적용한다.
Q. 무엇부터 공부하나? A. Linux·네트워크(포트·DNS) → K8s 기본 객체(파드·서비스·PVC) → 저장소의 ansible role 하나와 tofu .tf 하나를 나란히 읽기.

🔭 더 깊이 보기¶

Tofu state는 어디에 두고 어떻게 잠그나(remote backend) — 여러 명이 같은 현장을 만질 때 가장 먼저 사고가 나는 곳이라서.
폐쇄망에서 provider mirror와 이미지 레지스트리를 어떻게 준비하나 — 에어갭 번들의 핵심 부품이라서.
Kubernetes PV·PVC·StorageClass는 어떻게 연결되나 — 설치 실패의 단골 원인이라서.
관련 주제: 쿠버네티스 클러스터 내부 통신, Docker Compose 로컬 개발환경

📚 참고 자료¶

스토리지 클래스 (Kubernetes 한국어 문서) — StorageClass가 무엇이고 어떻게 고르는지 · 링크
Getting started with Ansible (Ansible 공식 문서, 영문) — 인벤토리·플레이북·멱등성의 기본 개념 · 링크
OpenTofu Documentation (OpenTofu 공식 문서, 영문) — state, plan, apply의 흐름 · 링크

🗓️ 이력¶

2026-11-12: ansible·tofu 명령만 쓰면 설치가 끝나는지 묻고, 이어서 두 도구가 어떻게 다른지(절차형 vs 선언형) 물었다. 2번 물음 → 일지

🕸️ 연결된 주제¶

바로 이어진 주제 2개전체 지도에서 보기 →

다른 주제 랜덤으로 보기