멋쟁이

[이방인] 독후감

mutjang2 — Wed, 29 Jul 2026 17:00:44 +0900

"오늘 엄마가 죽었다. 아니, 어쩌면 어제." 유명하고 아주 강렬한 첫문장이다. 처음부터 주인공인 뫼르소의 성격을 옅볼 수 있는 힌트가 주어진다. 가장 가깝고도 사랑하는 존재인 어머니의 죽음을 담담하게, 그리고 언제 돌아가셨는지 조차 애매모호하게 인지하고 있다. 이어서, 뫼르소는 어머니의 시신 앞에서 담배를 태우고 밀크커피를 마시는가 하면, 어머니의 장례 다음날 여자친구 마리와 함께 해변에서 데이트를 즐기기까지 한다. 그의 행동들은 독자들로 하여금 그가 감정이 결여된 비범한 인물로 인식하게한다. 그러나 그의 이러한 점들은 후에 그가 회부될 재판에서 불리하게 작용했다.

소설은 크게 두 장으로 나뉜다. 1부에서 알제리의 소박한 선원인 뫼르소가 어머니의 장례를 치르고 주변인들과 일상을 살아가다가 친구 레몽의 일에 말려들어 해변에서 아랍인을 권총으로 쏴 죽이게된다. 그 이유를 한마디로 표현하면 햇빛이 너무 눈부셨기 때문에.

2부는 뫼르소의 재판 과정을 담는다. 21세기 대한민국을 살아가고 있는 내가 읽기에는 작품에서 묘사된 재판과정에서 다루는 법률 논리와 판단 등의 괴리가 느껴졌지만, 감정과 인과관계, 그리고 종교 등의 가치가 더 무거운 시대인 것으로 이해됐다. 앞서 나열한 뫼르소의 행동들에 대한 주변인들의 증언을 듣고 재판관과 배심원들은 뫼르소를 사회로부터 영구적인 격리가 필요한 악마라고 판단했다. 여기서 주목할 점은 살인을 저질렀다는 사실보다도 그들이 생각하기에 '응당 인간이라면 이렇게 행동해야 한다'라는 기대규격에서 벗어난 그의 행동들에 보다 더 초점을 맞췄다는 것에 있다. 결국 뫼르소는 사람을 죽인 것보다 어머니의 죽음에 슬퍼하지 않는 모습을 보인 이유로 사형이 선고된다.

뫼르소는 감정이 결여된 사람처럼 보인다. 그러나 그는 누구보다도 자신의 감정에 솔직한 인물이다. 어머니가 돌아가셨음에도 담배가 태우고 싶으면 태웠고, 커피가 마시고 싶으면 마셨으며, 욕정을 느끼면 참지 않았다. 그것은 뫼르소가 무질서하고 부도덕한 인물이기 때문에 그런 것이 아니다. 그는 그야말로 감정이 풍부하고 솔직한 사람이기 때문에 그런 것이다.

우리가 살아가는 사회는 어떠한 상황에서는 반드시 슬퍼해야 하고, 죄를 지었다면 회개해야 하며, 법정에서는 정해진 시나리오대로 반성하는 척이라도 해야 한다. 이것은 사회가 정해놓은 틀이자 규칙처럼 이어져 내려오는 관습인 셈이다. 그러나 뫼르소는 거짓말을 거부한다. 비단 없는 사실을 지어내는 것만을 의미하는게 아닌 자신이 느끼는 것 이상을 표현하거나 체면 때문에 감정을 연기하는 것 또한 여기에 포함된다.

오늘날을 살아가는 우리 역시 수많은 관습과 타인의 시선 속에서 살아간다. SNS에서는 행복하지 않아도 적당히 행복한 척을 해야 하고, 직장이나 사회에서는 진실되지 않은 웃음과 연민을 내비쳐야 할 때가 많다. 사회가 기대하는 가식과 연극에 적응하지 못하면 스스로 '외딴섬'처럼 느껴지며 이방인이 된 듯한 고독감을 겪는다.

책을 읽으며 처음에 의문을 가졌던 부분이 있다. 뫼르소가 방아쇠를 당는 과정을 독자로서 읽고 있으면서도 이해가 가지 않았다. 책에서는 뫼르소가 햇빛 때문에 느끼는 열기와 더위, 그로인해 그가 방아쇠를 당기기까지의 심리 상태를 자세히 묘사하는데, 아이러니하게 그 자세함 때문에 나는 이해가 되지 않았었다. 왜냐하면 그의 심리에는 증오나 분노와 같은 일반적인 살해 동기가 포함 되지 않는다. 그러다가 책을 다 읽고 불현듯 '아, 나도 사회가 기대하는 이유를 찾고 있구나' 라는 생각이 들며 카뮈가 말하는 부조리에 익숙해져 있다는 것을 깨달았다.

뫼르소의 살인 자체가 정당화될 수는 없지만, 자신의 감정에 솔직하고자 했던 그의 순수한 진실성은 타인의 시선과 사회적 연극에 맞춰 가면을 쓰고 살아가는 우리들에게 날카로운 질문을 던진다.

우리는 정말 자신의 삶을 살고 있는가, 아니면 남들이 원하는 연기를 하며 살아가고 있는가?

공유 스토리지 기술 정리

mutjang2 — Fri, 24 Jul 2026 16:49:24 +0900

공유 스토리지 기술은 큰 관점에서 데이터에 대한 접근 방식과 구현 아키텍처에 따라 분류할 수 있다.

1. 데이터 접근 방식에 따른 분류 (SAN vs NAS vs Object)

데이터를 어떤 형태로 넘겨주는지(프로토콜)에 따른 분류

SAN(Storage Area Network)

데이터를 블록 단위로 처리하며 호스트에게 스토리지를 물리 디스크로 인식 시킨다

주요 프로토콜: FC, iSCSI

특징: 오버헤드가 없어서 I/O가 매우 빠르고 latency가 낮음. 원하는 파일 시스템을 선택 가능함

단점: 공유 스토리지 활성화를 위해서 물리적인 연결이 필요하며, 데이터 무결성을 위한 클러스터 파일시스템이 필요함

사용처: RDB, 서버 디스크

NAS(Network Attached Storage)

스토리지 장비자체 파일시스템을 가지고 있으며, 네트워크를 이용한 공유 디렉토리 형태로 구현

주요 프로토콜: NFS

특징: 기존 인프라를 그대로 이용하므로 구축 비용 최소화

단점: 네트워크 환경과 오버헤드로 인한 I/O 및 지연율 성능이 상대적으로 떨어짐

사용처: 기업 파일 서버, 웹 서버 공유 업로드 폴더 등

Object Storage

데이터를 메타데이터 + UID + 데이터 형태로 묶어서 하나의 객체 형태로 flat한 구조에 저장

주요 프로토콜: RESTful API(HTTP 기반, AWS S3 API 표준 등)

특징: 서버에 디스크 마운트 형식이 아닌 HTTP web API로 데이터를 주고 받음. Scale-out에 용이

단점: 데이터 수정 시 파일 전체를 다시 써야하므로 Random I/O 성능이 떨어짐

사용처: 미디어 파일 저장, 대규모 정적 파일 배포, 로그 보관 및 대용량 백업 archive

2. 구현 아키텍처에 따른 분류 (하드웨어 SAN/NAS vs 분산/SDS)

최근 기술 동향은 하드웨어 기반 전통 스토리지에서 소프트웨어 정의 스토리지(SDS)로의 전환이 활발하다

전통 하드웨어 기반

Dell, HPE 등 하드웨어 제조사에 의존하는 형태. 컨트롤러 및 파워 서플라이 등이 이중화 되어 있어 신뢰성이 높고 고성능이지만, 비싸고 벤더에 대한 종속성이 높음

분산 SDS(Software Defined Storage)

일반적인 범용 서버에 탑재된 디스크를 소프트웨어와 네트워크적으로 묶어서 하나의 거대한 공유 스토리지로 구현한 형태. Scale-out과 HA가 자유로움. 그러나 관리가 복잡하고 네트워크 비용이 발생

3. SDS의 종류

SDS 안에서도 아키텍처와 용도에 따라 분류할 수 있다.

통합형 분산 스토리지

가장 대세이며, 단일 클러스터에서 블록, 파일, 객체 스토리지를 모두 제공할 수 있는 만능형 스토리지

대표 기술: Ceph

특징: 중앙 메타데이터 서버에 쿼리할 필요 없이 클라이언트가 직접 데이터 위치를 계산하여 병목을 없앰

단점: 초기 구성이 복잡하여 구축 및 관리가 어려움

분산 파일 시스템

파일 공유를 분산 환경으로 확장하는 데에 초점을 맞춤

대표 기술: Glusterfs, Moosefs

특징: 리눅스 디렉토리 구조를 네트워크로 묶어서 거대한 하나의 볼륨으로 만듬. 설치와 구성이 쉽고 직관적임

단점: 대용량 데이터 처리 시에 파일 위치를 추적하는 메타데이터 처리에 심각한 병목 현상이 발생

하이퍼컨퍼지드 인프라 스토리지

컴퓨팅 자원과 스토리지 자원을 분리하지 않고, 하이퍼바이저 커널 레벨에서 스토리지를 묶어버리는 기술

대표 기술: VMWare vSAN

특징: 별도의 스토리지 OS 설치가 필요없이 하이퍼바이저 자체에서 각 노드의 로컬 디스크를 묶어 공유 스토리지를 만듬

단점: 비용이 비싸고 벤더 종속성이 심함

클라우드 네이티브 (컨테이너 전용) 스토리지

최근 쿠버네티스(Kubernetes)나 Docker swarm같은 컨테이너 오케스트레이션 환경에 맞춤 설계된 기술

특징: 스토리지 컨트롤러 자체가 컨테이너 형태로 배포되어 파드가 생성되고 소멸할 때마다 동적으로 볼륨을 할당하고 회수함

단점: Ceph나 vSAN 같은 전통적 SDS에 비해 대규모 I/O 처리 능력이 부족함

AWS - RDS, Aurora & ElastiCache

mutjang2 — Thu, 7 May 2026 00:32:35 +0900

RDS = Relational Database Service

인스턴스에 SSH 접속이 불가하지만, AWS의 프로모션 서비스이니 만큼 AWS 환경에서 많은 기능과 호환이 되는 장점이 있음

Supported DBMS

Postgres
MySQL
MariaDB
Oracle DB
MicroSoft SQL server
IBM DB2
Aurora(AWS Proprietary)

RDS Storage Auto Scaling

Dynamic scaling을 지원함. 모든 RDS 엔진에서 지원

auto scaling의 임계치를 설정할 수 있음

확장조건: 할당된 용량의 10% 이하 && formal condition이 5분 지속 && 최소 6시간의 쿨 다운 타임이 지났을때

RDS Read Replica

읽기 전용 db 복제본을 최대 15개까지 생성가능

AZ, Cross AZ, Cross region 등 전범위 지원

비동기 방식의 이중화를 채택함

읽기 전용 복제본들을 own db로 승격을 시킬 수 있음

AWS는 AZ 간의 통신할때, network cost가 있지만 읽기 전용 복제본 기능은 같은 region에 있다면 cross AZ이더라도 과금되지 않음.

RDS Multi-AZ

DR(Disaster Recovery)을 목적으로 설계

동기화 방식의 이중화를 채택함

RDS들 앞단에 DNS를 두고 로드 밸런싱을 진행하며, app에서 개입할 필요없이 자동으로 진행하는 기능 탑재

RDS - Single AZ to Multi AZ

필요에 의해 이중화 구성을 하게 될 경우, 다운타임이 없이 매끄러운 이중화 장비 setup이 가능함

Amazon Aurora

기존 RDS보다 높은 성능을 자랑하는 AWS의 클라우드 네이티브 RDB.

MySQL과 PostgreSQL를 지원. 동일한 드라이버를 사용하기 때문에 완벽호환.

Aurora HA and Read scaling

데이터를 저장할 때 3 AZ에 걸쳐 총 6개의 데이터 복제본을 생성하여 클러스터 볼륨을 구성함.

볼륨의 4/6 이상의 복제본에게 응답을 받으면 writing task를 승인.

볼륨의 3/6 이상의 복제본에게 응답을 받으면 reading task를 승인.

Aurora를 컴퓨팅할 인스턴스 중 딱 하나의 인스턴스는 writer가 되며(master) 읽기 전용 replica는 최대 15개 까지 생성 가능(RDS=6개)

RDS Backup

Automated backup: 매일 DB 전체를 full backup / 트랜잭션 로그를 5분마다 백업 / 최대 35일 보관(disable 가능)

Manual backup: 직접 삭제전까지 영구 보관

aurora도 비슷하지만 오토 백업 비활성화 불가

온프레미스 db를 migration 하고 싶은 경우에, S3에 업로드하여 RDS나 오로라로 restore 가능

Amazon ElastiCache

AWS가 제공하는 in-memory db 서비스. Redis와 Memcached 엔진을 지원.

Cache hit가 발생하면 그대로 가져오고, miss가 발생하면 RDS로부터 읽어온 후, cache에 저장함

RDS와 cache를 함께 사용할때는 동기화가 필수로 적용되어야하기 때문에 구현방안이 필요됨(TTL 설정, data invalidation 등)

AWS - HA & Scalability

mutjang2 — Sun, 26 Apr 2026 00:11:01 +0900

ELB = Elastic Load Balancer

AWS가 제공하고 게런티하는 로드밸런서 서비스. 다른 AWS의 부가 서비스들과의 호환에도 용이하여 메리트가 있음.

ELB의 종류

CLB(Classic lb): 거의 fade out

ALB(Application lb): L7(HTTP) 기반의 로드밸런서

NLB(Network lb): L4기반의 로드밸런서

GWLB(Gateway lb): 3rd 어플라이언스 전용

Sticky Sessions

클라이언트와 LB 뒤의 동일한 인스턴스에게 리다이렉션 되게하는 기능. 쿠키를 이용함

Cross-Zone Load Balancing

다른 AZ더라도 같은 타겟 그룹인 경우에 고르게 로드 밸런싱을 하는 기능.

ALB는 무료, NLB는 유료

SSL

ACM(AWS Certificate Manager)이 관리함

multiple SSL certi가 필요한 경우 SNI를 이용하며, newer generation LB들만 지원함.

Connection Draining

De-registartion Delay라고도 칭함.(newer generation LB)

1) in-flight request를 보내어 LB가 해당 인스턴스에게 신규 트래픽을 전달하지 않음

2) 처리중인 작업을 마칠때까지 설정 값 동안 LB와의 연결을 유지함

3) 이후 해당 장비에서 오토스케일링, 블루-그린 배포 등의 작업을 진행 후에 서비스 복귀

ASG = Auto Scaling Group

스케일링 그룹을 지정하고 조건을 설정하여 자동으로 스케일링을 지원하는 기능.

CloudWatch 알람을 기반으로 스케일링 가능함. 이 알람들은 메트릭 정보들을 모니터링함.

여러가지 Scaling policy를 지정할 수 있음.

예시) CPU 점유율을 항상 40% 유지, CPU 점유율이 70%가 초과되면 scale out, 트래픽이 몰리는 특정 시간이 되면 scale out

스케일링 작업 이후에 cool down 시간을 가짐(depands on your setting)

AWS - Instance Storage 요약

mutjang2 — Thu, 16 Apr 2026 00:13:07 +0900

EBS = Elastic Block Store

EC2 인스턴스에 attach 되는 스토리지 볼륨.

인스턴스에 귀속되지 않음. 인스턴스에 attach 되어있던 EBS를 별도로 관리할 수 있음(attach / detach)

EBS가 생성된 AZ에 종속됨. AZ나 region 간 migration이 필요한 경우 스냅샷을 활용해야 함

AMI = Amazon Machine Image

EC2 인스턴스 커스텀 이미지. VMWare로 치면 템플릿 기능.

AWS marcket place에서 공유된 이미지 가져다가 사용가능.

EC2 Instance Store

EBS 볼륨의 경우 네트워크 볼륨이기 때문에 성능이 안나올 수 있음.

EC2 Instance store는 하드웨어 디스크이기 때문에, 높은 I/O 성능이 요구되는 서비스에는 해당 옵션을 채택할 수 있음

인스턴스와 물리적으로 직접 연결하기 때문에 EBS와 달리 인스턴스 삭제 시 볼륨 내 데이터도 함께 삭제함

EBS Volume types

SSD 계열과 HDD 계열을 선택할 수 있음. 성능과 비용에 따라 선택가능. 부트 볼륨으로는 SSD 친구들만 채택 가능함

SSD 계열 중 고성능 시리즈인 io1/io2 볼륨은, 여러 대의 인스턴스가 하나의 볼륨에 attach 가능함(최대 16대까지)

EFS = Elastic File System

일종의 EC2 인스턴스들의 NAS.

성능 별 class로 분류한 과금 옵션이 있음. 접근 빈도에 따른 적절한 옵션 채택

AWS - EC2 Associate 요약

mutjang2 — Wed, 15 Apr 2026 23:27:11 +0900

Elastic IP

기본적으로 EC2 인스턴스가 재기동될 때마다 IP가 변동됨. 고정 IP를 할당하려면 Elastic IP를 사용해야 함.

계정 당 최대 5개의 Elastic IP 할당가능(추가 사용이 필요할 경우 문의 필요)

대부분의 경우 Elastic IP 사용보다는 그냥 도메인을 할당받거나 로드밸런서를 사용하는 편이 나음

Placement Group

EC2 인스턴스들을 실제 AWS의 물리서버에 어떻게 호스팅 할 것인지 결정하는 전략.

Cluster PG - 하나의 AZ에 배치하여 물리적인 위치를 가깝게 함으로써 low-latency를 실현
Spread PG - 각각의 인스턴스가 호스팅되는 랙을 분산하여 장애를 회피
Partition PG - 인스턴스들을 여러 개의 파티션으로 나누어 각 파티션이 서로 다른 랙을 사용

ENI = Elastic Network Interfaces

EC2 인스턴스의 Network interface. 인스턴스 생성 시 자동으로 생성됨. 기존의 ENI를 다른 인스턴스에 이식 가능함

EC2 Hibernate

EC2 인스턴스의 절전모드. 기술적으로 아래와 같음

RAM의 데이터를 EBS에 보존 / 따라서 재기동 시 boot 시간 단축 / 모든 유형의 인스턴스가 지원하지는 않음 / 최대 60일

AWS - EC2 Basics 요약

mutjang2 — Sun, 12 Apr 2026 22:15:09 +0900

EC2 = Elastic Compute Cloud

EC2 구성요소

VM(instance)
EBS(Elastic Block Store): 하드 디스크
ELB(Elastic Load Balancer): 로드 밸런서
ASG(Auto-Scaling Group): 오토 스케일링 그룹

bootstrapping이 가능하다. sudo 권한으로 실행되며 cloud-init을 이용함.

AWS가 제공하는 다양한 인스턴스 유형이 있음. 용도에 맞는 하드웨어 스펙을 선택이 가능하며, 커스터마이징은 불가함.

Security Groups

EC2 인스턴스의 방화벽 역할을 함. Inbound와 Outbound 설정을 다르게 가져갈 수 있고, Security group 을 중첩 그루핑하여 관리할 수도 있음.

SSH

EC2 instance 생성 시 '.pem' 파일이 생성됨. 해당 파일을 로컬pc로 가져와서 ssh 접속을 할 수 있다.

Amazon Linux는 'ec2-user' 계정이 디폴트로 존재함

EC2 Instances Purchasing Options

On-Demand: 사용한 만큼 비용을 지불. 장기간 이용에 적합하지 않음
Reversed: 정액제를 끊고 사용. on-demand에 비해 약 72% 저렴함. Marcket place에서 중고거래도 가능함.
Spot Instances: 가장 저렴한 옵션. 다만 데이터 보존성을 보장하지 않음.
Dedicated Hosts: 전용 물리서버를 할당함
Capacity Reservations: 인스턴스의 총량 단위의 계약. 사용여부와 사용량에 관계없이 비용을 지불
Saving plans: 특정 기간동안 모든 서비스를 이용가능

Spot Fleets

capacity, AZ, billing 등 인스턴스의 조건을 설정. 제약조건에 다다르면 해당 인스턴스는 정지

AWS - IAM 요약

mutjang2 — Sun, 12 Apr 2026 21:35:30 +0900

IAM = Identity and Access Management

user는 그루핑 되어 관리할 수 있으며, 다수의 그룹에 소속될 수 있다.

user나 그룹은 json 파일로써 정책을 설정할 수 있다. 이 정책은 권한 부여에 대한 정의를 뜻한다.

IAM policy 예

MFA = Multi Factor Authentication

전통적인 id/pw 조합에 MFA 디바이스를 등록하여 2단계 인증을 통하여 계정 보안을 강화할 수 있다.

IAM role을 설정하여 사용자가 이용할 수 있는 서비스의 권한에 제한을 둘 수 있다.

IAM Sercurity Tools

Credentails Report : 계정 관점의 security management.

Access Advisor: 사용자 권한 관점의 security management. 마지막으로 이용한 서비스를 관제가능한 것이 특징. 이 정보를 토대로 '최소권한 원칙'을 준수하는 데에 용이하다.

2. Terraform - 기본 사용법

mutjang2 — Tue, 7 Apr 2026 17:04:44 +0900

주요 커맨드

기본적인 커맨드를 익히기에 앞서 실습 환경 구성.

$ mkdir '02_command'

$ vi 02_command/main.tf
resource "local_file" "abc" {
content = "abc!"
filename = "${path.module}/abc.txt"
}

init

terraform init 명령은 테라폼 구성 파일이 있는 작업 디렉토리를 초기화하는 명령어다. 테라폼에서는 이 init 명령어를 실행하는 디렉토리를 루트 모듈이라고 칭한다. 테라폼을 사용하기에 앞서 최초이자 필수적으로 실행되는 명령어이다. 테라폼 코드를 기반으로 테라폼 구성에서 필요한 의존성을 읽고, 실행에 필요한 라이브러리 등을 다운로드한다.

$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding latest version of hashicorp/local...
- Installing hashicorp/local v2.7.0...
- Installed hashicorp/local v2.7.0 (signed by HashiCorp)
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

해당 명령어를 실행하면 루트 모듈에 .terraform.lock.hcl 파일이 생성된다.

$ cat .terraform.lock.hcl
# This file is maintained automatically by "terraform init".
# Manual edits may be lost in future updates.

provider "registry.terraform.io/hashicorp/local" {
  version = "2.7.0"
  hashes = [
    "h1:2RYa3j7m/0WmET2fqotY4CHxE1Hpk0fgn47/126l+Og=",
    "zh:261fec71bca13e0a7812dc0d8ae9af2b4326b24d9b2e9beab3d2400fab5c5f9a",
    "zh:308da3b5376a9ede815042deec5af1050ec96a5a5410a2206ae847d82070a23e",
    "zh:3d056924c420464dc8aba10e1915956b2e5c4d55b11ffff79aa8be563fbfe298",
    "zh:643256547b155459c45e0a3e8aab0570db59923c68daf2086be63c444c8c445b",
    "zh:78d5eefdd9e494defcb3c68d282b8f96630502cac21d1ea161f53cfe9bb483b3",
    "zh:7aa4d0b853f84205e8cf79f30c9b2c562afbfa63592f7231b6637e5d7a6b5b27",
    "zh:7dc251bbc487d58a6ab7f5b07ec9edc630edb45d89b761dba28e0e2ba6b1c11f",
    "zh:7ee0ca546cd065030039168d780a15cbbf1765a4c70cd56d394734ab112c93da",
    "zh:b1d5d80abb1906e6c6b3685a52a0192b4ca6525fe090881c64ec6f67794b1300",
    "zh:d81ea9856d61db3148a4fc6c375bf387a721d78fc1fea7a8823a027272a47a78",
    "zh:df0a1f0afc947b8bfc88617c1ad07a689ce3bd1a29fd97318392e6bdd32b230b",
    "zh:dfbcad800240e0c68c43e0866f2a751cff09777375ec701918881acf67a268da",
  ]
}

이 파일에는 작업 당시의 provider와 테라폼 버전 등의 dependancy가 명기되며 작업 시에 이 파일을 참조하게 된다.

validate

테라폼 구성파일의 유효성을 점검하는 명령어. 코드적인 유효성만 점검한다.

-json 옵션을 활용하면 json 형식으로 출력할 수도 있다.

$ terraform validate
Success! The configuration is valid.

$ terraform validate -json
{
  "format_version": "1.0",
  "valid": true,
  "error_count": 0,
  "warning_count": 0,
  "diagnostics": []
}

$ terraform validate -json | jq -r .valid
true

plan & apply

plan 명령은 적용할 인프라 변경 사항의 실행 계획을 생성한다. plan 명령은 적용 전 검토하는데 이용한다.

apply는 계획을 기반으로 작업을 실행한다. plan이 없이 apply를 한다면 우선 새 실행 계획을 자동으로 생성하고,

해당 계획을 적용여부를 묻게된다.

$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.abc will be created
  + resource "local_file" "abc" {
      + content              = "abc!"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./abc.txt"
      + id                   = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

위처럼 plan을 실행했을때, 적용될 사항들이 출력되며 하단에는 최종 결과를 요약하여 표시한다. 현재는 이전에 생성한 리소스가 없으므로 +로만 표시가 된다. 또한 마찬가지로 변경과 삭제되는 사항이 없기 때문에 add만 1이 표시되었다.

-detailed-exitcode 옵션을 이용하면 plan의 결과를 환경변수로 추출할 수 있다.

$ terraform plan -detailed-exitcode
...
$ echo $?
2

0: 변경사항이 없는 성공 / 1: error 있음 / 2: 변경사항이 있는 성공

-out =filename 옵션으로 plan 명령의 결과를 기록할 수 있고, 후에 apply 명령에서 해당 파일(계획)을 가지고 적용할 수 있다.

terraform plan 명령어로 task를 검토하고, 특이 사항이 없으면 apply를 입력하여 작업을 실행한다.

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.abc will be created
  + resource "local_file" "abc" {
      + content              = "abc!"
      + content_base64sha256 = (known after apply)
생략
Plan: 1 to add, 0 to change, 0 to destroy.


local_file.abc: Creating...
local_file.abc: Creation complete after 0s [id=5678fb68a642f3c6c8004c1bdc21e7142087287b]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

-replace: 테라폼은 ansible과 마찬가지로 멱등성을 가지기 때문에, 변화없는 동일한 구성에 대해서 반복 작업을 수행하지 않는다. 하지만 필요에 의해서 해당 리소스를 다시 생성 해야하는 경우에 -replace 옵션을 이용할 수 있다.

destroy

테라폼의 모든 개체를 제거하는 명령이다. destroy 명령도 plan과 apply의 관계와 같이 계획과 실행이 동반되어야 한다.

$ terraform destroy
local_file.abc: Refreshing state... [id=5678fb68a642f3c6c8004c1bdc21e7142087287b]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # local_file.abc will be destroyed
  - resource "local_file" "abc" {
      - content              = "abc!" -> null
      - content_base64sha256 = "U+Dv8yBGJvPiVspjZXLXzN+OtaGQyd76P6VnvGOGa3Y=" -> null
  생략

Plan: 0 to add, 0 to change, 1 to destroy.

local_file.abc: Destroying... [id=5678fb68a642f3c6c8004c1bdc21e7142087287b]
local_file.abc: Destruction complete after 0s

Destroy complete! Resources: 1 destroyed.

fmt

fmt 명령은 테라폼 구성 파일의 내용을 표준 형식과 표준 스타일로 적용하는데 사용한다.

$ cat main.tf 
resource "local_file" "abc" {
content = "abc!"
filename = "${path.module}/abc.txt"
}

$ terraform fmt
main.tf

$ cat main.tf 
resource "local_file" "abc" {
  content  = "abc!"
  filename = "${path.module}/abc.txt"
}

-recursive 옵션을 이용하면 해당 디렉토리 하위의 모든 파일에 적용할 수 있다.

HCL

테라폼은 기본적으로 HCL을 사용한다. json은 공식적으로 호환이 되지만, 가독성이 안좋고 주석 기능을 지원하지 않는 단점이 있다. 직접 작성할 때는 HCL을 이용하고 다른 툴이 json 파일을 생성한 경우에는 .tf.json 확장자를 가진다면 호환이 가능하다. 추가로 테라폼은 yaml 파일은 지원하지 않지만 yamldecode() 함수를 이용하여 테라폼 변수로 변환할 수 있다.

Cloud-init을 이용하여 간단한 VM 생성해보기

mutjang2 — Wed, 25 Mar 2026 18:10:11 +0900

VMWare ESXi 호스트에 cloud-init을 이용하여 VM 생성하기.

1. OS 이미지 다운로드 - 시험대상: Rocky Linux 8.10

- Generic cloud 이미지 다운로드

https://download.rockylinux.org/pub/rocky/8/images/x86_64/

Rocky Linux Repository

download.rockylinux.org

2. Download 한 이미지를 vmdk 파일로 변환

- VMWare와의 호환성을 위해서 vmdk 파일로 변환함

$ qemu-img convert -f qcow2 -O vmdk Rocky-8-GenericCloud.latest.x86_64.qcow2 rocky-8.10-cloud.vmdk

3. Cloud-init 데이터 소스 파일 작성

필수 구성요소: user-data, meta-data

- user-data: 사용자 계정 등의 OS 환경 및 부팅 후 초기 설정 정보를 포함

- meta-data: 인스턴스(VM)의 세부정보를 포함

cloud-init root 디렉토리 생성

$ mkdir cloud-init-pr

meta-data 생성

$ vi meta-data
instance-id: ci-inst-001
local-hostname: ci-host

user-data 생성

- 콘솔 접속할 수 있을정도로만 간단히.

$ vi user-data

#cloud-config
ssh_pwauth: true

users:
  - name: test
    groups: [wheel, sudo]
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    lock_passwd: false
    ssh_authorized_keys:
    -  <ssh-rsa AAAAB3NzaC1yc2.....>

runcmd:
  - id si || useradd -m -G wheel -s /bin/bash si
  - echo "test:test" | chpasswd
  - sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication yes/g' /etc/ssh/sshd_config
  - systemctl restart sshd

4. cloud-init 이미지 생성

$ genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data
$ ll
total 388
-rw-r--r-- 1 root root     54 Mar 25 15:23 meta-data
-rw-r--r-- 1 root root 376832 Mar 25 15:23 seed.iso
-rw-r--r-- 1 root root   1061 Mar 25 15:34 user-data

이렇게 만든 vmdk 와 iso 파일을 ESXi datastore에 업로드 하여 VM을 생성할 수 있다.