장애없이, 매일 놀아 봅시다.

certificate has expired — 인증서 만료, 장애 하루 전 신호

와우패널 — Wed, 9 Sep 2026 08:00:05 +0900

앞선 네 편은 전부 "서서히 소진되는" 자원이었습니다 — inode·fd·포트·재시작 횟수 전부 오늘 얼마나 찼는지가 계속 바뀌었습니다. 인증서 만료는 다릅니다. 만료일은 인증서를 발급하는 순간 이미 정해져 있고, 그날 그 시각까지는 아무 경고 없이 멀쩡하다가 그 순간을 넘기면 즉시, 예외 없이 끊깁니다. 이 글은 그 날짜를 오늘 어떻게 확인하는지, 리프 인증서만 보고 안심하면 안 되는 이유를 실측으로 확인하고, 실제로 만료된 인증서로 접속이 끊기는 걸 재현합니다.

월요일 오전, 파트너사 연동 API — 외부 파트너가 우리 API를 호출하는 게 자정 넘어서부터 전부 실패한다고 연락이 왔다. 우리 쪽 API 서버는 재시작한 적도 없고 로그도 조용했다. 원인은 리프 인증서가 아니라 체인 중간에 있는 중간(intermediate) 인증서가 그 시각에 만료된 것이었다. 리프 인증서의 유효기간만 확인하고 있었기 때문에, 아무도 이 만료를 미리 보지 못했다.

인증서 만료는 이 시리즈에서 가장 확정적인 신호입니다 — 날짜가 이미 정해져 있으니 "재현마다 값이 흔들린다"는 걱정이 없습니다. 그런데도 매년 반복되는 장애 유형이라는 게, 이 신호를 어떻게 놓치는지 살펴볼 이유입니다.

측정 환경: Rocky Linux 9.7(커널 5.14.0-611.47.1.el9_7) · OpenSSL 3.5.1 · curl 7.76.1. 이 글의 모든 명령 출력은 이 환경에서 실제로 인증서를 만들고 접속을 시도해 얻은 것입니다.

신호 관찰 — -enddate가 아니라 -checkend로 봅니다
왜 위험한가 — 리프만 보고 안심하면 안 되는 이유
재현 — 만료된 인증서로 실제로 끊어 봅니다
임계값과 오탐 — 언제부터, 그리고 아닌 경우
지금 조치 — 갱신 자체보다 갱신 자동화를 먼저 봅니다
치트시트 — 정기 점검 명령

1. 신호 관찰 — `-enddate`가 아니라 `-checkend`로 봅니다

$ openssl x509 -in cert.pem -noout -enddate
notAfter=Aug 26 10:54:22 2026 GMT

-enddate는 날짜를 보여줄 뿐, "며칠 남았다"는 계산은 직접 해야 합니다. 스크립트로 점검한다면 -checkend가 더 낫습니다 — 주어진 초(seconds) 안에 만료되는지를 종료 코드로 바로 알려줍니다.

$ openssl x509 -in cert.pem -checkend 2592000 # 30일(2,592,000초) 이내 만료 예정?
Certificate will expire
$ echo "rc=$?"
rc=1
$ openssl x509 -in cert.pem -checkend 0 # 지금 이 순간 기준
Certificate will not expire
$ echo "rc=$?"
rc=0

이 인증서는 지금 당장은 유효(checkend 0 → rc=0)하지만 30일 안에는 만료(checkend 2592000 → rc=1)됩니다. rc만 보면 되니 모니터링 스크립트에 그대로 넣기 좋습니다.

파일이 로컬에 없는 경우(리버스 프록시·로드밸런서 뒤라 실제 서빙되는 인증서를 모를 때)는 접속 중인 엔드포인트에서 직접 뽑습니다.

$ echo | openssl s_client -connect <호스트>:<포트> -servername <SNI호스트명> 2>/dev/null \
| openssl x509 -noout -enddate

이 방식이 파일을 직접 보는 것보다 낫습니다. 서버가 실제로 내보내는 인증서를 그대로 확인하기 때문에, 갱신된 인증서 파일이 디스크에는 있는데 웹서버가 아직 리로드되지 않아 옛 인증서를 계속 서빙 중인 상태도 이 방식으로만 잡힙니다.

2. 왜 위험한가 — 리프만 보고 안심하면 안 되는 이유

TLS 클라이언트는 인증서 하나만 보지 않습니다 — 리프(내 도메인 인증서)부터 루트까지 체인 전체를 검증하고, 체인 안의 인증서 중 어느 하나라도 만료되면 전체가 거부됩니다. 리프 인증서의 유효기간이 1년 남았어도, 그 리프에 서명한 중간 인증서가 먼저 만료되면 똑같이 끊깁니다.

실제로 만들어서 확인했습니다. 루트 CA(2027년까지 유효) → 중간 CA(이미 만료) → 리프(2027년까지 유효) 3단 체인을 만들고, 리프 인증서 자체만 확인하면 이렇게 보입니다.

$ openssl x509 -in leaf.pem -noout -enddate
notAfter=Jun  1 00:00:00 2027 GMT

멀쩡해 보입니다. 그런데 중간 인증서는 이미 만료됐습니다.

$ openssl x509 -in inter.pem -noout -enddate
notAfter=Aug 24 00:00:00 2026 GMT

체인 전체를 검증하면 바로 드러납니다.

$ openssl verify -CAfile root.pem -untrusted inter.pem leaf.pem
CN=test-intermediate
error 10 at 1 depth lookup: certificate has expired
error leaf.pem: verification failed

error 10 at 1 depth lookup — 체인에서 1단계 위(중간 인증서)에서 만료 오류가 났다는 뜻입니다. 리프의 -enddate만 정기 점검에 넣어 뒀다면 이 상태를 영영 못 봅니다.

2021년 Let's Encrypt의 옛 루트 인증서(DST Root CA X3)가 실제로 만료되면서, 리프는 전부 멀쩡한데 구형 클라이언트들이 체인 검증에서 무더기로 실패한 사례가 있었습니다. 이 글의 3단 재현은 그 상황을 압축한 것입니다 — 리프가 아니라 체인 어딘가가 원인일 수 있다는 걸 늘 염두에 둡니다.

3. 재현 — 만료된 인증서로 실제로 끊어 봅니다

openssl req의 -not_after로 만료일을 과거로 직접 지정하면, 기다리지 않고도 진짜 만료된 인증서를 만들 수 있습니다. 로컬 루프백에서만 도는 테스트 서버라 운영 서비스와는 무관합니다.

$ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out expired.pem -nodes \
-subj "/CN=test.local" -not_before 20260101000000Z -not_after 20260823000000Z
$ openssl x509 -in expired.pem -noout -enddate
notAfter=Aug 23 00:00:00 2026 GMT
$ openssl s_server -cert expired.pem -key key.pem -accept 18444 -naccept 1 -quiet &
$ echo | openssl s_client -connect 127.0.0.1:18444 -CAfile expired.pem -verify_return_error
verify error:num=10:certificate has expired
...
Verification error: certificate has expired
Verify return code: 10 (certificate has expired)

curl로 접속하면 실무에서 훨씬 자주 보는 형태의 메시지가 뜹니다.

$ curl --cacert expired.pem https://127.0.0.1:18444/ -sv 2>&1 | grep -i expire
* TLSv1.3 (OUT), TLS alert, certificate expired (557):
* SSL certificate problem: certificate has expired

두 도구 다 만료 정확히 그 순간부터 실패합니다. 그 전까지는 -enddate나 -checkend로 미리 찾아보지 않는 한, 접속은 끝까지 정상입니다.

4. 임계값과 오탐 — 언제부터, 그리고 아닌 경우

며칠 전부터 경고할지는 인증서 발급 주기에 따라 다릅니다. Let's Encrypt처럼 90일짜리라면 30일 전(전체 유효기간의 3분의 1)에 갱신을 시작하는 게 흔한 관례입니다 — 갱신이 한 번 실패해도 재시도할 여유를 남기기 위해서입니다. 1~2년짜리 상용 인증서라면 만료 30~60일 전에 발급사에서 갱신 안내 메일이 오는 관행 자체가 이 여유를 반영합니다.

오탐 주의 — 이 신호인데 장애로 안 이어지는 경우

상황	왜 괜찮은가
만료 임박이지만 자동 갱신(certbot 타이머 등)이 스케줄돼 있고 최근에 정상 동작한 이력이 있음	5장에서 볼 것처럼, 진짜 봐야 할 건 인증서 날짜가 아니라 갱신 자동화가 살아 있는지다
더는 안 쓰는 도메인·서비스의 인증서가 만료 임박	실제 트래픽이 없다면 만료돼도 장애가 아니다 — 다만 "안 쓰는지" 확인 없이 방치하면 다음 담당자가 오탐으로 놀란다
내부망 전용, mTLS로 상호 검증하는 사설 CA 인증서가 만료 임박	사설 CA 정책에 따라 유효기간이 의도적으로 짧을 수 있음(예: 90일 회전) — 그 자체가 설계라면 정상
SAN에 여러 도메인이 걸린 인증서에서 그중 하나만 확인해 "괜찮다"고 판단	같은 인증서를 쓰는 다른 도메인들도 정확히 같은 날 같이 만료된다 — 하나만 보고 판단하면 나머지에서 놓친다

5. 지금 조치 — 갱신 자체보다 갱신 자동화를 먼저 봅니다

당장 할 수 있는 것 — 만료가 임박했다면 즉시 갱신하고, 리프뿐 아니라 체인 전체를 재배포합니다(2장의 함정). 갱신 후에는 반드시 라이브 엔드포인트에서 다시 확인합니다(1장의 s_client 방식) — 파일만 바꾸고 서버 리로드를 빠뜨리면 옛 인증서가 계속 나갑니다.

지금 못 고치면 남겨 둘 것 — 이번 건을 수동으로 해결했다면, 왜 자동 갱신이 이 인증서를 놓쳤는지를 남겨 둡니다. 진짜 장애 하루 전 신호는 인증서 날짜 자체가 아니라, 자동 갱신 작업(cron·systemd timer·certbot renew)이 며칠 전부터 조용히 실패하고 있었다는 것인 경우가 많습니다. 인증서 만료를 감시하는 것보다, 갱신 자동화가 마지막으로 성공한 시각을 감시하는 게 더 이른 신호입니다.

systemctl list-timers | grep -i certbot # 갱신 타이머가 살아 있는지
certbot renew --dry-run # 실제 발급 없이 갱신 경로만 검증
journalctl -u certbot.timer --since -30d # 최근 갱신 시도 이력

6. 치트시트 — 정기 점검 명령

openssl x509 -in <파일> -noout -checkend 2592000 # 30일 이내 만료? rc로 판단
echo | openssl s_client -connect <호스트>:<포트> -servername <SNI> 2>/dev/null \
| openssl x509 -noout -enddate # 실제 서빙 중인 인증서 확인
openssl verify -CAfile <루트> -untrusted <중간체인> <리프> # 체인 전체 검증
systemctl list-timers | grep -i certbot # 갱신 자동화가 살아 있는지

이 글이 보탠 것 — 리프 인증서만 확인하면 놓치는 "중간 인증서 만료"를 3단 체인을 직접 만들어 재현했고, curl·openssl s_client 양쪽에서 만료 순간의 정확한 실패 메시지를 확보했습니다. 그리고 이 시리즈의 다른 신호들과 달리, 인증서는 날짜가 이미 정해져 있다는 것 자체가 무기입니다 — 며칠 남았는지 세는 게 아니라, 그 갱신을 맡은 자동화가 지금도 살아 있는지를 봐야 합니다.

1~4편이 전부 "값이 한도에 다가가는지"를 봤다면, 이번 건 "예정된 사건을 처리할 자동화가 조용히 죽어 있지 않은지"를 보는 글이었습니다.

Start request repeated too quickly — 서비스 flapping, 장애 하루 전 신호

와우패널 — Tue, 8 Sep 2026 07:58:32 +0900

Restart=always를 걸어 둔 서비스는 죽어도 알아서 다시 뜬다고 믿기 쉽습니다. 맞는 말이지만 조건이 하나 있습니다 — 짧은 시간에 너무 자주 죽으면 systemd가 재시작 자체를 포기합니다. 그 뒤로는 다음에 진짜 장애가 나도 자동 복구가 동작하지 않습니다. 이 글은 이 한도에 다가가는 신호를 어떻게 보는지, 실제로 그 한도까지 몰아붙여 재현하고, 오늘 뭘 확인해야 하는지를 다룹니다.

수요일 새벽, 배치 워커 서비스 — 새로 배포한 워커가 설정 파일 하나를 잘못 읽어 기동 직후 매번 죽었다. Restart=always가 걸려 있어 당연히 다시 뜰 거라 생각했는데, 아침에 보니 서비스는 죽은 채였고 그날 새벽 배치가 통째로 안 돌았다. 로그를 훑어보니 새벽 3시 12분 이후로는 재시작 시도 자체가 없었다 — systemd가 그 시각에 "너무 자주 재시작한다"며 스스로 멈춘 것이었다.

systemd는 서비스가 일정 시간 안에 일정 횟수 이상 재시작되면 더 이상 재시작을 시도하지 않습니다. 이건 무한 재시작 루프로 시스템 자원을 잡아먹는 걸 막기 위한 설계지만, 이 한도에 이미 근접해 있었다는 신호를 놓치면 다음 장애 때 자동 복구가 조용히 사라져 있습니다.

측정 환경: Rocky Linux 9.7(커널 5.14.0-611.47.1.el9_7) · systemd 252(252-55.el9_7.8.rocky.0.1). 이 글의 모든 명령 출력은 이 환경에서 systemd-run --user(사용자 세션, sudo 불필요)로 직접 재현해 얻은 것입니다.

신호 관찰 — 재시작 카운터와 한도 대비 비율
왜 위험한가 — 자동 재시작도, 수동 재시작도 같은 카운터를 씁니다
재현 — 기본값 그대로 한도까지 밀어붙여 봅니다
임계값과 오탐 — 몇 번부터, 그리고 아닌 경우
지금 조치 — 카운터를 지울지, 원인을 고칠지
치트시트 — 정기 점검 명령

1. 신호 관찰 — 재시작 카운터와 한도 대비 비율

systemctl show의 NRestarts가 그 서비스의 지금까지 재시작 횟수, StartLimitBurst가 한도입니다. 이 둘이 같아지기 직전(예: 4/5)이면 한 번만 더 실패해도 자동 복구가 완전히 멈춥니다. 1초마다 죽는 서비스 하나를 실제로 띄워 이 숫자가 올라가는 걸 그대로 지켜봤습니다.

$ systemd-run --user --unit=flapslow -p Restart=always bash -c 'sleep 1; exit 1'
$ for i in $(seq 1 8); do
    sleep 1
    N=$(systemctl --user show flapslow.service -p NRestarts --value)
    ST=$(systemctl --user show flapslow.service -p ActiveState --value)
    echo "t=${i}s NRestarts=$N ActiveState=$ST"
  done
t=1s NRestarts=0 ActiveState=activating
t=2s NRestarts=1 ActiveState=active
t=3s NRestarts=2 ActiveState=active
t=4s NRestarts=3 ActiveState=active
t=5s NRestarts=4 ActiveState=active
t=6s NRestarts=5 ActiveState=failed
t=7s NRestarts=5 ActiveState=failed
t=8s NRestarts=5 ActiveState=failed

t=5s에서 NRestarts=4(한도 5 중 4) — 아직 ActiveState=active라 겉으로는 멀쩡해 보입니다. 바로 다음 초(t=6s)에 5번째 재시작이 한도에 닿으면서 ActiveState=failed로 바뀌고, 그 뒤로는 NRestarts가 더 이상 안 오릅니다. active인 동안에도 NRestarts가 한도에 근접해 있으면, 다음 실패 한 번이 곧바로 복구 중단으로 이어진다는 뜻입니다.

systemctl status 맨 아래 줄들이 최근 로그 몇 줄을 같이 보여줍니다. 이 서버는 사용자(--user) 세션의 저널이 별도로 안 쌓이는 구성이라 journalctl --user -u <서비스>로는 안 잡히고, systemctl status에 딸려 나오는 로그 스니펫이 사실상 유일한 창이었습니다. 이 구성 차이가 있는지 먼저 확인하십시오.

2. 왜 위험한가 — 자동 재시작도, 수동 재시작도 같은 카운터를 씁니다

man systemd.unit의 StartLimitIntervalSec=, StartLimitBurst= 항목입니다.

Units which are started more than burst times within an interval time span are not permitted to start any more. Use StartLimitIntervalSec= to configure the checking interval and StartLimitBurst= to configure how many starts per interval are allowed. ... interval ... Defaults to DefaultStartLimitIntervalSec= in manager configuration file ... burst ... defaults to DefaultStartLimitBurst= in manager configuration file.

기본값은 man systemd-system.conf에 있습니다.

DefaultStartLimitIntervalSec= defaults to 10s.
DefaultStartLimitBurst= defaults to 5.

10초 안에 5번이 기본값입니다 — 기동 즉시 죽는 서비스라면 순식간에 소진되는 아주 빡빡한 한도입니다.

여기서 흔한 오해가 있습니다 — 이 카운터가 Restart=로 인한 자동 재시작만 센다고 생각하기 쉬운데, 같은 항목이 이렇게 덧붙입니다.

These configuration options are particularly useful in conjunction with the service setting Restart= ...; however, they apply to all kinds of starts (including manual), not just those triggered by the Restart= logic.

즉 담당자가 장애 대응 중에 systemctl restart를 손으로 반복 실행하는 것도 똑같이 카운터에 들어갑니다. 디버깅한다고 급한 마음에 몇 번 연달아 수동으로 재시작을 시도하면, 정작 원인을 못 찾고 물러난 사이 자동 복구까지 같이 멈춰 있을 수 있습니다.

man systemd.unit은 회복 경로도 명시합니다 — "units which are configured for Restart=, and which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted manually or from a timer or socket at a later point, after the interval has passed. ... systemctl reset-failed will cause the restart rate counter for a service to be flushed." 즉 ① 창 시간이 지나거나 ② reset-failed로 수동 초기화하면 다시 재시작을 받아 줍니다. 5장에서 이걸 실제로 확인합니다.

3. 재현 — 기본값 그대로 한도까지 밀어붙여 봅니다

systemd-run --user로 즉시 실패하는 트랜지언트 서비스를 띄우면 sudo 없이, 실제 배포된 서비스를 안 건드리고 같은 상황을 재현할 수 있습니다. 이 글의 모든 값은 StartLimitIntervalSec·StartLimitBurst를 건드리지 않은 기본값(10초/5회) 그대로입니다.

$ systemd-run --user --unit=flaptest2 -p Restart=always /bin/false
Running as unit: flaptest2.service
$ sleep 2
$ systemctl --user status flaptest2.service --no-pager -l
× flaptest2.service - /bin/false
     Loaded: loaded (/run/user/1000/systemd/transient/flaptest2.service; transient)
  Transient: yes
     Active: failed (Result: exit-code) since Tue 2026-08-25 18:46:07 KST; 833ms ago
   Duration: 4ms
    Process: 3661066 ExecStart=/bin/false (code=exited, status=1/FAILURE)
   Main PID: 3661066 (code=exited, status=1/FAILURE)
        CPU: 4ms

 8월 25 18:46:07 wowpanel.tistory.com systemd[3603804]: flaptest2.service: Scheduled restart job, restart counter is at 5.
 8월 25 18:46:07 wowpanel.tistory.com systemd[3603804]: Stopped /bin/false.
 8월 25 18:46:07 wowpanel.tistory.com systemd[3603804]: flaptest2.service: Start request repeated too quickly.
 8월 25 18:46:07 wowpanel.tistory.com systemd[3603804]: flaptest2.service: Failed with result 'exit-code'.
 8월 25 18:46:07 wowpanel.tistory.com systemd[3603804]: Failed to start /bin/false.
$ systemctl --user show flaptest2.service -p StartLimitIntervalUSec -p StartLimitBurst -p NRestarts
StartLimitIntervalUSec=10s
StartLimitBurst=5
NRestarts=5

/bin/false는 기동하자마자 죽으므로 Duration: 4ms, 전체 재현이 833ms 안에 끝났습니다. 로그의 restart counter is at 5가 한도(StartLimitBurst=5)에 정확히 닿은 순간이고, 바로 다음 줄 Start request repeated too quickly.가 그 이후로는 재시작을 안 하겠다는 선언입니다. NRestarts=5로 멈춘 채 더 안 올라가는 게 그 증거입니다.

실제 서비스는 /bin/false처럼 순식간에 안 죽습니다 — 기동 준비(설정 로드, 커넥션 시도)에 몇 초가 걸리는 서비스라면 이 5번 소진까지 수십 초에서 몇 분이 걸릴 수 있습니다. "아직 몇 번 안 죽었으니 여유 있다"고 안심하지 말고, StartLimitIntervalUSec 창(기본 10초) 안에서 몇 번 죽었는지를 봐야 합니다. 10초 창을 벗어나 죽은 재시작은 이전 실패와 별개로 새로 카운트가 시작됩니다.

4. 임계값과 오탐 — 몇 번부터, 그리고 아닌 경우

NRestarts 절대값이 아니라 StartLimitBurst 대비 비율, 그리고 그 재시작들이 StartLimitIntervalUSec 창 안에 몰려 있는지를 봅니다. 기본값(10초/5회) 기준이면 사실상 "여유"라고 부를 구간이 거의 없습니다 — 3~4회째부터는 바로 다음 장에서 다룰 조치를 준비해야 합니다.

오탐 주의 — 이 신호인데 장애로 안 이어지는 경우

상황	왜 괜찮은가
배포 직후 재시작 1~2회 후 안정화	새 버전이 뜨는 과정의 흔한 정상 패턴 — `NRestarts`가 그 뒤로 안 늘면 급한 신호가 아니다
재시작 창을 넉넉히(예: 300s) 늘려 둔 서비스	창이 넓으면 같은 5회라도 훨씬 오래 버틴다 — `StartLimitIntervalUSec` 값을 같이 확인한다
담당자가 방금 수동으로 몇 차례 재시작함	수동 재시작도 카운터에 들어간다(2장) — 서비스 실패가 아니라 사람 조작이 원인일 수 있다
서비스가 정상 종료(exit 0)로 자주 재시작됨	`Restart=on-failure`는 실패 종료에만 재시작한다 — 원인이 반복 실패가 아니면 이 글과 무관

5. 지금 조치 — 카운터를 지울지, 원인을 고칠지

systemctl reset-failed를 원인도 안 고치고 먼저 누르지 마십시오. 카운터만 지우면 서비스는 다시 죽고-재시작을 반복하다가 10초 안에 또 5번을 채우고 그대로 멈춥니다. 원인을 못 고쳤다면 지운 의미가 없습니다.

당장 할 수 있는 것 — 원인(설정 오류, 의존 서비스 미기동, 리소스 부족)을 먼저 고치고, 그다음 systemctl reset-failed <서비스>로 카운터를 초기화합니다. man systemd.unit이 명시한 그대로 — 초기화하면 재시작 로직이 다시 활성화됩니다. 아무것도 안 해도 StartLimitIntervalUSec 창(기본 10초)이 지나면 다음 재시작 시도부터는 새 카운트로 취급됩니다만, 서비스가 여전히 죽는 상태라면 창이 지나도 다시 5번 만에 멈추는 게 반복될 뿐입니다.

systemctl reset-failed <서비스>   # 원인 조치 후에만
systemctl restart <서비스>

지금 못 고치면 남겨 둘 것 — 원인을 바로 못 고치는 상황이면, StartLimitBurst를 무작정 올리기보다 NRestarts를 알림 임계값으로 걸어 둡니다. 값을 올려서 더 오래 재시도하게 만드는 건 "더 오래 죽어 있다가 결국 멈춘다"로 시간만 벌 뿐 — 근본적으로는 원인 해결이 우선입니다.

StartLimitIntervalSec=0으로 두면 한도 자체를 끌 수 있다고 man systemd.unit에 나와 있지만("may be set to 0 to disable any kind of rate limiting"), 권장하지 않습니다 — 이 한도가 막아 주는 게 바로 "무한 재시작 루프가 CPU·로그를 잡아먹는" 상황이라, 끄면 원인 미해결 상태에서 그 상황을 그대로 허용하게 됩니다.

6. 치트시트 — 정기 점검 명령

systemctl show <서비스> -p NRestarts -p StartLimitBurst -p StartLimitIntervalUSec
                                                    # 한도 대비 현재 재시작 횟수
systemctl status <서비스> --no-pager -l            # 최근 로그와 함께 현재 상태
systemctl reset-failed <서비스>                    # 원인 해결 후 카운터 초기화

이 글이 보탠 것 — Restart=always가 무조건 살려낸다는 가정이 왜 틀렸는지를 기본값(10초/5회) 그대로 실제로 소진시켜 확인했고, 이 카운터가 자동 재시작뿐 아니라 사람이 손으로 재시작하는 것도 똑같이 센다는 것을 man 원전으로 확인했습니다.

1~3편(inode·fd·ephemeral 포트)이 모두 "자원이 조용히 소진되는" 신호였다면, 이번 건 성격이 다릅니다 — 소진되는 건 자원이 아니라 "다시 시도할 기회"입니다.

문의 페이지

와우패널 — Mon, 7 Sep 2026 23:11:46 +0900

문의

블로그와 관련된 모든 연락은 이메일-댓글로 받습니다.

이런 연락을 환영합니다

내용 오류 제보 — 글에 적힌 명령어나 설명이 실제 환경과 다른 경우 좀 더 고민하겠습니다.
오탈자 제보
주제 제안 — 다뤄줬으면 하는 장애나 명령어
질문 — 글 내용에 대한 추가 질문. 다만 개별 환경의 장애 진단을 대신 해드리기는 어렵습니다.

답변에 대하여

1인이 운영하는 블로그이며 본업이 따로 있어, 답변까지 며칠이 걸릴 수 있습니다. 내용 오류 제보는 확인되는 대로 글을 수정하고 하단에 수정 이력을 남깁니다.

저작권

이 블로그의 글은 직접 작성하고 실제 환경에서 검증한 것입니다. 인용 시 출처와 원문 링크를 남겨주세요. 전문 복제는 삼가 주시기 바랍니다.

이 블로그는 무엇을 쓰는 곳인가

와우패널 — Mon, 7 Sep 2026 23:09:59 +0900

리눅스 서버와 AWS, 스프링부트를 운영하면서 실제로 마주친 장애와 그 원인을 기록하는 블로그입니다.

"재부팅했더니 됐습니다"로 끝나는 기록은 쓰지 않습니다. 어떤 신호가 먼저 있었는지, 그 신호를 어떤 명령으로 볼 수 있었는지, 같은 일이 다시 생기면 무엇을 먼저 확인해야 하는지를 씁니다.

왜 이렇게 쓰는가

장애가 났을 때 검색하면 대부분 두 종류의 글이 나옵니다. 하나는 명령어만 나열된 글이고, 다른 하나는 원인 설명 없이 해결책만 있는 글입니다. 둘 다 지금 내 서버에서 벌어지는 일이 그 상황과 같은 것인지를 알려주지 않습니다.

그래서 이 블로그는 순서를 뒤집었습니다. 증상에서 시작해, 그 증상이 나올 수 있는 원인을 갈라내고, 각 갈래를 어떤 명령으로 확인하는지까지 씁니다. 명령어는 결론이 아니라 판단의 근거를 얻는 도구로 다룹니다.

어떻게 검증하는가

모든 명령어와 출력은 실제 서버에서 실행한 결과를 그대로 붙입니다. 주로 Rocky Linux 9.x 환경이며, 버전이 중요한 경우 글 안에 명시합니다.
직접 확인하지 못한 내용은 "확인 필요"라고 명시하고, 추측을 사실처럼 쓰지 않습니다.
잘못된 내용을 발견하면 글을 수정하고, 하단에 수정 이력을 남깁니다.

다루는 주제

리눅스 — 프로세스와 부하, 메모리, 디스크와 파일, 네트워크, 로그 추적, 서비스·권한·쉘
장애 D-1일 전 — inode 고갈, 파일 디스크립터 고갈, ephemeral 포트 고갈처럼 터지기 전에 먼저 보이는 신호를 다루는 시리즈
AWS — VPC, EC2, S3, RDS, IAM, Route 53, ELB 등을 온프레미스에서 쓰던 장비 감각으로 읽는 시리즈
MariaDB — 커넥션, 락, 슬로우 쿼리, 복제 중단 등 운영 중 실제로 만나는 오류
스프링부트 — 기동 실패, 빈 주입, 트랜잭션, 커넥션 풀 등 애플리케이션 레이어의 장애

하나의 장애를 애플리케이션 · 데이터베이스 · 운영체제 세 층에서 각각 다루는 것을 목표로 하고 있습니다. 같은 "커넥션 고갈"도 앱에서 보는 모습과 DB에서 보는 모습, OS에서 보는 모습이 다르기 때문입니다.

누가 쓰는가

온프레미스 인프라와 클라우드를 다루고 있고, 자바 개발자입니다. 물리 서버와 사내망을 직접 다루던 감각으로 AWS를 읽는 관점을 주로 씁니다. 그 감각이 클라우드를 이해하는 데 오히려 지름길이 되는 경우가 많았기 때문입니다.

업데이트

평일 기준 매일 한 편씩 발행합니다. 새 글은 오전에 올라갑니다.

문의

오탈자 제보, 내용 오류 지적, 다뤄줬으면 하는 주제 제안 모두 환영합니다.

이메일: wowpanel.seo@gmail.com

Cannot assign requested address — ephemeral 포트 고갈, 장애 하루 전 신호

와우패널 — Mon, 7 Sep 2026 09:57:39 +0900

바깥으로 나가는 연결을 만드는 모든 프로그램은 로컬 포트를 하나씩 씁니다. 이 포트는 무한하지 않고, 연결을 끊어도 한동안 회수되지 않습니다. 이 상태가 쌓이면 새 연결 자체를 못 만듭니다 — 원격 서버는 멀쩡하고, 방화벽도 안 막았는데 Cannot assign requested address가 뜹니다. 이 글은 이 신호를 어떻게 미리 보는지, 흔히 오해하는 설정 하나를 실측으로 바로잡고, 실제로 포트를 고갈시켜 같은 에러를 재현합니다.

화요일 오전, 결제 게이트웨이 연동 서버 — 외부 API를 호출하는 배치가 트래픽이 몰리는 시간대에 실패하기 시작했다. 로그엔 connect: Cannot assign requested address. 담당자는 방화벽·DNS·상대 서버 상태를 다 확인했지만 전부 정상이었다. 원인은 그 배치가 API 호출마다 새 TCP 연결을 열고 바로 닫는 구조였다는 것 — 끊은 연결은 즉시 없어지지 않고 TIME_WAIT으로 남아 로컬 포트를 붙잡는다. 트래픽이 몰리자 열어 둘 수 있는 포트 자체가 바닥났다.

ss -s의 timewait 카운트는 이 상태가 얼마나 진행됐는지 보여주는 계기판입니다. 이 글에서는 그 계기판을 읽는 법, TIME_WAIT의 지속 시간을 좌우한다고 흔히 오해하는 설정을 실측으로 확인하고, 실제로 포트를 고갈시켜 봅니다.

측정 환경: Rocky Linux 9.7(커널 5.14.0-611.47.1.el9_7) · util-linux 2.37.4(unshare) · iproute2(ss·ip) · Ncat 7.92(nmap). 이 글의 모든 명령 출력은 이 환경에서 직접 실행해 얻은 것입니다.

신호 관찰 — ss -s의 timewait과 포트 범위
왜 위험한가 — 그리고 흔한 오해 하나를 실측으로 바로잡기
재현 — 포트 11개로 좁혀서 실제로 고갈시켜 봅니다
임계값과 오탐 — 몇 %부터, 그리고 아닌 경우
지금 조치 — 포트를 늘릴지, 연결을 줄일지
치트시트 — 정기 점검 명령

1. 신호 관찰 — `ss -s`의 timewait과 포트 범위

$ ss -s
Total: 961
TCP:   373 (estab 60, closed 292, orphaned 0, timewait 142)

Transport Total     IP        IPv6
RAW       1         0         1
UDP       7         4         3
TCP       81        49        32
INET      89        53        36
FRAG      0         0         0

$ cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999

timewait 142는 절대 개수만으로는 별 의미가 없습니다. 봐야 할 건 이 서버가 쓸 수 있는 로컬 포트 범위(ip_local_port_range) 대비 얼마나 차 있는가입니다. 이 서버는 32768~60999, 즉 28,232개 중 142개(0.5%)라 전혀 위험하지 않습니다. 이 비율이 문제가 되는 건 아웃바운드 연결을 짧은 주기로 열고 닫는 프로세스가, 대상 목적지가 소수로 좁을 때입니다.

$ ss -tan state time-wait | wc -l
143

(헤더 줄 하나가 포함되므로 ss -s의 142보다 1 많습니다.)

ss -tan state time-wait은 로컬에서 만든 아웃바운드 연결도, 남이 나에게 연결했다가 끊은 인바운드 연결도 둘 다 보여줍니다. 특정 목적지가 원인인지 좁히려면 ss -tan state time-wait "( dport = :목적지포트 )"처럼 필터를 겁니다.

2. 왜 위험한가 — 그리고 흔한 오해 하나를 실측으로 바로잡기

TCP 연결을 만들 때 로컬 쪽은 (로컬 IP, 로컬 포트, 원격 IP, 원격 포트) 조합 하나를 씁니다. 같은 목적지로 계속 연결한다면 사실상 로컬 포트 하나가 그 목적지 하나를 위해 소비되는 셈입니다. 연결을 닫아도 그 포트는 즉시 재사용되지 않습니다 — TIME_WAIT 상태로 남아 지연 도착한 패킷과 이전 연결을 혼동하지 않도록 커널이 붙잡아 둡니다.

여기서 흔한 오해가 있습니다 — net.ipv4.tcp_fin_timeout을 낮추면 TIME_WAIT이 빨리 풀린다고 알려져 있는데, man tcp는 이렇게 못 박습니다.

tcp_fin_timeout This specifies how many seconds to wait for a final FIN packet before the socket is forcibly closed.

이건 FIN_WAIT 계열(상대가 안 끊어서 붕 뜬 소켓)의 이야기지, TIME_WAIT과는 다른 상태입니다. 실제로 확인해 봤습니다 — tcp_fin_timeout을 기본값(60)의 12분의 1인 5로 낮추고, 연결 하나를 열었다 바로 닫은 뒤 TIME_WAIT이 몇 초 만에 사라지는지 5초 간격으로 쟀습니다.

$ unshare -rn bash -c '
    ip link set lo up
    echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout
    cat /proc/sys/net/ipv4/tcp_fin_timeout
    ncat -lk 127.0.0.1 9999 &
    sleep 0.3
    ncat -w1 127.0.0.1 9999 </dev/null       # 연결 1회 생성 후 즉시 close
    START=$(date +%s)
    for k in $(seq 1 20); do
      N=$(ss -tan state time-wait "( dport = :9999 )" | tail -n +2 | wc -l)
      NOW=$(date +%s)
      echo "t=$((NOW-START))s timewait_count=$N"
      [ "$N" -eq 0 ] && break
      sleep 5
    done
  '
5
t=0s timewait_count=1
t=5s timewait_count=1
t=10s timewait_count=1
t=15s timewait_count=1
t=20s timewait_count=1
t=25s timewait_count=1
t=30s timewait_count=1
t=35s timewait_count=1
t=40s timewait_count=1
t=45s timewait_count=1
t=50s timewait_count=1
t=55s timewait_count=1
t=60s timewait_count=1
t=65s timewait_count=0

tcp_fin_timeout=5인데도 TIME_WAIT은 60~65초 사이에 사라졌습니다. tcp_fin_timeout을 아무리 낮춰도 TIME_WAIT 지속 시간은 그대로입니다 — 이 값은 리눅스 커널에 고정돼 있고 일반적인 sysctl로 바꿀 수 없습니다. "이 서버는 tcp_fin_timeout을 낮춰 놨으니 TIME_WAIT이 금방 빠진다"는 가정은 틀렸습니다.

TIME_WAIT을 실제로 줄이는 sysctl은 tcp_tw_reuse입니다. man tcp: "Allow to reuse TIME_WAIT sockets for new connections when it is safe from protocol viewpoint." 이 서버의 기본값은 2입니다 — man은 아직 Boolean으로만 설명하는데, 최신 커널은 0/1/2 세 단계를 씁니다. 정확한 2의 의미는 이 서버에 커널 문서 패키지가 없어 원전으로 확인하지 못했습니다 — 이 값을 근거로 판단을 내려야 한다면 커널 소스나 배포판 문서로 한 번 더 확인하시길 권합니다.

3. 재현 — 포트 11개로 좁혀서 실제로 고갈시켜 봅니다

운영 서버의 실제 포트 범위를 건드릴 수는 없으니, unshare -rn으로 새 네트워크 네임스페이스를 열어 그 안에서만 유효한 루프백을 만들고 포트 범위를 극단적으로 좁힙니다. 호스트에는 영향이 없고, 셸이 끝나면 사라집니다.

$ unshare -rn bash -c '
    ip link set lo up
    echo 32768 32778 > /proc/sys/net/ipv4/ip_local_port_range   # 11개 포트만
    cat /proc/sys/net/ipv4/ip_local_port_range
    ncat -lk 127.0.0.1 9999 &
    sleep 0.3
    echo ---BASELINE---
    ss -s
    echo ---연결 시도 30회---
    ok=0; fail=0
    for i in $(seq 1 30); do
      if ncat -w1 127.0.0.1 9999 </dev/null 2>/tmp/ncat_err.txt; then
        ok=$((ok+1))
      else
        fail=$((fail+1))
      fi
    done
    echo "성공 $ok · 실패 $fail"
    echo ---마지막 실패 메시지---
    cat /tmp/ncat_err.txt
    echo ---AFTER---
    ss -s
    ss -tan state time-wait | head -5
  '
32768   32778
---BASELINE---
Total: 1
TCP:   229 (estab 0, closed 228, orphaned 0, timewait 0)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       0         0         0
TCP       1         1         0
INET      1         1         0
FRAG      0         0         0

---연결 시도 30회---
성공 13 · 실패 17
---마지막 실패 메시지---
Ncat: Cannot assign requested address.
---AFTER---
Total: 1
TCP:   241 (estab 0, closed 240, orphaned 0, timewait 11)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       0         0         0
TCP       1         1         0
INET      1         1         0
FRAG      0         0         0

Recv-Q Send-Q Local Address:Port  Peer Address:Port
0      0          127.0.0.1:32773    127.0.0.1:9999
0      0          127.0.0.1:32778    127.0.0.1:9999
0      0          127.0.0.1:32775    127.0.0.1:9999
0      0          127.0.0.1:32776    127.0.0.1:9999

11개짜리 포트 범위에서 연결을 30번 반복하니 13번째까지만 성공하고 나머지 17번은 전부 실패했습니다. 실패 메시지는 정확히 도입부 상황의 그 메시지 — Cannot assign requested address(errno EADDRNOTAVAIL)입니다. 성공했던 연결 13개 중 남은 것들이 전부 TIME_WAIT으로 쌓여 timewait 11(포트 범위 11개와 정확히 일치)을 만든 뒤로는, 그 포트들이 60초 동안 풀리기 전까지 어떤 새 연결도 이 목적지로는 못 나갑니다.

이 실패는 연결을 시도하는 쪽에서만 일어납니다. 서버(리스닝 소켓) 쪽은 SO_REUSEADDR을 쓰면 자기 포트를 바로 재사용해서 다시 뜰 수 있어 이 문제와 무관합니다. 아웃바운드 연결을 만드는 클라이언트·배치·연동 서버가 이 증상의 당사자입니다.

4. 임계값과 오탐 — 몇 %부터, 그리고 아닌 경우

ip_local_port_range의 크기 대비 timewait 개수 비율로 봅니다. 1·2편과 같은 관례(경고 80% · 위험 90%)를 적용할 수 있지만, 이 자원은 목적지별로 쪼개집니다 — 전체 포트 범위가 넉넉해도 특정 목적지 하나로 몰리는 연결이 그 목적지에 배정 가능한 포트를 다 쓰면 그 목적지로만 못 나갑니다. 전체 비율과 함께 목적지별 TIME_WAIT 개수도 같이 봐야 합니다.

ss -tan state time-wait "( dport = :목적지포트 )" | wc -l

오탐 주의 — 이 신호인데 장애로 안 이어지는 경우

상황	왜 괜찮은가
`timewait` 절대 개수는 크지만 목적지가 다양하게 분산됨	목적지마다 별도의 포트 풀을 쓰는 게 아니라 전체 범위를 나눠 쓰는 것 — 특정 목적지 하나가 포트를 독점하지 않으면 그 목적지로의 새 연결은 계속 됩니다
`tcp_tw_reuse`가 활성화(이 서버 기본값 `2`)돼 있고 클라이언트 쪽 연결	"안전할 때" 재사용되므로 순수 개수만큼 위험하지 않을 수 있음 — 다만 정확한 재사용 조건은 원전 확인이 안 됐으니 개수 자체가 계속 우상향하는지는 여전히 지켜봐야 함
서버(리스닝) 소켓이 재시작 후 잠깐 `TIME_WAIT`을 남김	`SO_REUSEADDR`을 쓰는 서버 소켓은 재바인딩에 지장이 없음 — 이 글의 위험은 아웃바운드(클라이언트) 쪽 이야기
배치가 끝난 직후 `timewait`이 일시적으로 튀었다가 다음 배치 전에 원래 수준으로 돌아옴	60초짜리 창이 지나면 자연히 풀림 — 다음 배치가 시작되기 전에 여유 있게 풀린다면 급한 신호가 아님

5. 지금 조치 — 포트를 늘릴지, 연결을 줄일지

당장 할 수 있는 것 — ip_local_port_range를 넓힙니다(예: 32768 60999 → 1024 65000, 다른 서비스가 쓰는 낮은 포트와 안 겹치는지 확인 후). 포트 풀이 커지면 같은 목적지로도 더 많은 연결을 동시에 감당합니다. 임시 완화일 뿐, 연결 패턴 자체는 그대로입니다.

sysctl -w net.ipv4.ip_local_port_range="1024 65000" # 즉시 적용, 재부팅 시 소실
# 영구 적용은 /etc/sysctl.d/*.conf 에 net.ipv4.ip_local_port_range = 1024 65000 추가

근본 조치 — 이 신호의 진짜 원인은 대부분 "연결을 재사용하지 않는 코드"입니다. HTTP 클라이언트라면 keep-alive·커넥션 풀을 켜서 같은 목적지로의 연결을 재사용하고, DB 클라이언트라면 매 요청마다 새로 접속하지 않고 커넥션 풀을 씁니다. 연결 자체가 줄면 포트 소비도 같이 줍니다 — 포트 범위를 넓히는 건 증상 완화지, 원인 제거가 아닙니다.

지금 못 고치면 남겨 둘 것 — 코드를 당장 못 고치는 상황이면, 목적지별 timewait 개수를 알림 임계값으로 걸어 둡니다. 트래픽이 몰리는 시간대 직전에 미리 확인하는 루틴이 없다면 하나 만들어 둡니다.

6. 치트시트 — 정기 점검 명령

ss -s # timewait 전체 개수
cat /proc/sys/net/ipv4/ip_local_port_range # 전체 포트 풀 크기
ss -tan state time-wait "( dport = :포트 )" | wc -l # 특정 목적지로 쏠렸는지
cat /proc/sys/net/ipv4/tcp_tw_reuse # 재사용 설정 확인 (기본값이 뭔지 먼저 확인)

이 글이 보탠 것 — tcp_fin_timeout이 TIME_WAIT 지속 시간과 무관하다는 것을 5초로 낮춰도 60~65초를 그대로 기다리는 실측으로 확인했고, 포트 범위를 11개로 좁혀 실제로 Cannot assign requested address를 재현해 도입부 상황과 같은 실패를 만들어 봤습니다.

1·2편과 마찬가지로, 이 신호도 익숙한 설정 하나(tcp_fin_timeout)가 실제로는 다른 걸 조절하고 있었다는 함정이 핵심입니다 — inode의 df -h, fd의 lsof에 이어 세 번째입니다.

이어서 보면 좋은 글

S3 — "NAS 마운트" 감각으로 열면 바로 걸리는 AWS의 오브젝트 스토리지

와우패널 — Sun, 6 Sep 2026 15:22:03 +0900

온프레미스에서 여러 서버가 같은 파일을 함께 봐야 할 때는 NAS(Network Attached Storage — 네트워크로 파일을 공유하는 전용 저장장치)를 세우고 NFS(Network File System)나 SMB(Server Message Block)로 마운트해 디렉터리 트리를 공유합니다. AWS에서 이에 가장 가까운 서비스는 Amazon S3(Simple Storage Service)이지만, 저장 방식 자체가 근본적으로 다릅니다. 이 글은 그 차이가 실무에서 정확히 어디서 걸리는지, "마운트해서 쓰면 되겠지"라는 첫 시도가 왜 막히는지부터 다룹니다.

온프레미스에서 NAS를 세워 애플리케이션 업로드 파일을 여러 웹 서버가 함께 보도록 운영해 온 인프라팀이, 신규 서비스의 파일 저장소를 S3로 옮기라는 지시를 받았다. "그냥 네트워크 드라이브 마운트하듯 버킷을 마운트해서 쓰면 되겠지"라는 생각으로 콘솔에 들어갔는데, 마운트 메뉴 자체가 안 보인다는 데서 시작한다.

이 글은 실제 AWS 콘솔 화면이나 CLI(Command Line Interface — 명령줄로 AWS를 조작하는 도구) 실행 결과를 캡처하지 않습니다 — 이 프로젝트로 쓸 수 있는 AWS 계정이 없기 때문입니다. S3의 저장 모델, 버킷 이름 규칙, 스토리지 클래스별 특성, 접근 제어 기본값, 라이프사이클 규칙처럼 이 글이 다루는 사실 하나하나는 전부 AWS 공식 문서를 직접 열어 원문을 대조한 것입니다.

1. S3가 정확히 뭔가

AWS 공식 문서는 S3를 이렇게 정의합니다.

"Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance."

"오브젝트 스토리지"라는 말이 핵심입니다. NAS는 파일 시스템을 네트워크로 공유하는 장치라 그 안에 실제 디렉터리 트리가 있지만, S3는 구조 자체가 다릅니다.

"Amazon S3 is an object storage service that stores data as objects, hierarchical data, or tabular data within buckets. An object is a file and any metadata that describes the file. A bucket is a container for objects."

버킷은 컨테이너, 객체는 파일과 그 메타데이터, 그리고 객체마다 버킷 안에서 유일한 키(key)가 붙습니다.

"An object key (or key name) is the unique identifier for an object within a bucket. Every object in a bucket has exactly one key."

버킷을 만들 때 리전을 지정하고, 그 안의 객체는 명시적으로 옮기지 않는 한 그 리전을 벗어나지 않습니다.

"Objects stored in an AWS Region never leave the Region unless you explicitly transfer or replicate them to another Region."

여기까지는 NAS와 크게 다르지 않아 보일 수 있습니다. "네트워크 너머 어딘가에 있는 저장 공간에, 이름 붙여서 파일을 넣어 둔다"는 감각 자체는 비슷합니다. 하지만 접근 방식과 내부 구조에서 갈립니다.

접근 방식 — NAS는 마운트해서 로컬 디렉터리처럼 다룹니다. S3에는 마운트라는 개념이 없습니다. 콘솔, CLI, REST API(Application Programming Interface — 프로그램끼리 정해진 규칙으로 주고받는 호출 인터페이스) 호출로 객체를 올리고 내립니다. 객체 하나는 버킷 이름·리전·키를 조합한 HTTPS 엔드포인트 URL로 주소가 매겨집니다 — 파일 경로가 아니라 HTTP 엔드포인트입니다. 이 오해는 4장에서 도입부 상황과 함께 자세히 다룹니다.

내부 구조 — NAS의 디렉터리는 실제 계층 구조지만, S3는 버킷 안에 객체가 평평하게(flat) 늘어선 구조입니다.

"The Amazon S3 data model is a flat structure: You create a bucket, and the bucket stores objects. There is no hierarchy of subbuckets or subfolders."

콘솔에서 보이는 "폴더"는 진짜 디렉터리가 아니라 키 이름의 접두사(prefix)와 구분자(/)로 흉내 낸 것입니다. Development/Projects.xlsx라는 객체는 실제로는 그 전체 문자열이 하나의 키일 뿐이고, 콘솔이 / 앞부분을 "Development"라는 폴더로 묶어 보여주는 것뿐입니다. 콘솔에서 폴더를 만들면 그 뒤에서는 이런 일이 일어납니다.

"The Amazon S3 console implements folder object creation by creating a zero-byte object with the folder prefix and delimiter value as the key. These folder objects don't appear in the console."

즉 "폴더"는 콘솔이 편의상 만든 0바이트짜리 객체거나, 순전히 화면에만 존재하는 시각적 묶음입니다. 이 차이는 4장의 두 번째 오해로 이어집니다.

2. 온프레미스 대응표

같은 목적(여러 서버가 같은 데이터를 공유)을 이루는 방식이 근본적으로 다릅니다. 이름과 쓰임새가 비슷해 보여도 "같은 물건"으로 여기고 접근하면 3장·4장에서 다루는 실무 문제로 바로 이어집니다.

온프레미스 NAS	AWS S3	같은 점	다른 점
NFS·SMB로 마운트해 접근	REST API·콘솔·CLI로 접근	여러 서버가 같은 데이터를 공유	마운트가 아니라 API 호출(1장, 4장)
실제 디렉터리 트리	버킷 안 평평한 키 네임스페이스	콘솔에서 폴더처럼 보임	진짜 계층 구조가 없다(1장, 4장)
RAID 컨트롤러 + 정기 백업	스토리지 클래스별로 설계된 내구성	데이터 유실 방지	여러 데이터센터에 자동 복제, 직접 구성 안 함(3장)
디스크 증설·컨트롤러 교체로 용량 계획	프로비저닝 없는 무제한 저장	—	용량을 미리 계획할 필요 자체가 없다(5장)
파일 시스템 접근 권한	버킷 정책·계정 권한 정책 + 기본 차단 설정	접근 통제	기본값부터 강하게 잠겨 있다(3장)
스냅샷을 별도로 구성	S3 버저닝(옵션, 버킷 단위)	이전 버전 복구	기본은 꺼짐, 켜면 지운 것도 그대로 남는다(3장)

3. 실무에서 반드시 알아야 하는 것

버킷 이름은 전역에서 유일해야 하고, 만든 뒤엔 이름도 리전도 못 바꾼다

버킷 이름은 계정 하나만의 문제가 아닙니다.

"General purpose buckets exist in a global namespace, which means that each bucket name must be unique across all AWS accounts in all the AWS Regions within a partition."

이름 규칙도 정해져 있습니다 — 3자에서 63자 사이, 소문자·숫자·마침표·하이픈만 가능, 시작과 끝은 문자나 숫자여야 하고, IP 주소 형식(192.168.5.4 같은)은 쓸 수 없습니다. 그리고 한 번 만들면 되돌릴 수 없는 결정입니다.

"After you create a general purpose bucket, you can't change its name or Region."

버킷을 지워도 그 이름이 곧바로 내 것으로 다시 확보되는 건 아닙니다.

"After you delete a bucket in the shared global namespace, be aware that another AWS account in the same partition can use the same bucket name for a new bucket and can therefore potentially receive requests intended for the deleted bucket."

스토리지 클래스는 접근 빈도로 고른다

S3는 객체마다 스토리지 클래스를 지정할 수 있고, 기본값은 S3 Standard입니다.

"By default, objects in S3 are stored in the S3 Standard storage class, however Amazon S3 offers a range of other storage classes for the objects that you store."

AWS 공식 문서가 정리한 주요 클래스 비교표는 다음과 같습니다. 클래스 이름에 붙은 IA는 Infrequent Access, 즉 "자주 접근하지 않는다"는 뜻입니다.

스토리지 클래스	접근 빈도	내구성	가용성	데이터센터 수	최소 저장 기간
S3 Standard	월 1회 이상	99.999999999%	99.99%	3곳 이상	없음
S3 Standard-IA	월 1회	99.999999999%	99.9%	3곳 이상	30일
S3 Intelligent-Tiering	변동·불명	99.999999999%	99.9%	3곳 이상	없음
S3 One Zone-IA	월 1회, 재생성 가능	99.999999999%	99.5%	1곳	30일
S3 Glacier Instant Retrieval	분기 1회	99.999999999%	99.9%	3곳 이상	90일
S3 Glacier Flexible Retrieval	연 1회	99.999999999%	99.99%(복원 후)	3곳 이상	90일
S3 Glacier Deep Archive	연 1회 미만	99.999999999%	99.99%(복원 후)	3곳 이상	180일

눈여겨볼 건 내구성과 가용성이 별개 숫자라는 점입니다 — 내구성은 "데이터를 잃어버리지 않을 확률", 가용성은 "필요할 때 바로 접근할 수 있을 확률"입니다. 표의 모든 클래스가 내구성은 동일하게 11개의 9로 설계되어 있지만, 가용성과 AZ(Availability Zone — 같은 리전 안에서 전력·냉각·네트워크가 서로 독립된 데이터센터 그룹) 수는 클래스마다 다릅니다. One Zone-IA만 유일하게 단일 AZ에 저장되고, 나머지는 3곳 이상의 AZ에 걸쳐 저장됩니다. 이 차이는 4장에서 다시 다룹니다.

객체 하나의 크기 제한과 업로드 방식

객체 키 이름은 최대 1,024바이트까지 쓸 수 있습니다. 업로드 방식은 크기에 따라 갈립니다.

"The maximum size of a file that you can upload by using the Amazon S3 console is 160 GB."

콘솔이 아니라 API·CLI로 단일 요청을 보낼 때는 이보다 작습니다.

"With a single PUT operation, you can upload a single object up to 5 GB in size."

더 큰 객체는 여러 조각으로 나눠 병렬로 올리는 멀티파트 업로드를 씁니다.

"You can use a multipart upload for objects from 5 MB to 50 TB in size."

온프레미스 NAS에서는 파일 크기가 디스크 여유 공간의 문제였다면, S3에서는 "어떤 업로드 방식을 쓸 것인가"의 문제로 바뀝니다.

쓰자마자 읽어도 최신 값이 보장된다 — 강한 일관성

과거 S3는 새로 쓴 객체를 곧바로 읽으면 이전 값이 보일 수 있는 최종 일관성(eventual consistency) 모델이었지만, 지금은 다릅니다.

"Amazon S3 provides strong read-after-write consistency for PUT and DELETE requests of objects in your Amazon S3 bucket in all AWS Regions. This behavior applies to both writes of new objects as well as PUT requests that overwrite existing objects and DELETE requests."

객체를 쓰고 바로 읽거나 목록을 조회해도 그 결과에 곧바로 반영된다는 뜻입니다. 다만 버킷 자체의 설정(버저닝 활성화 등)은 여전히 최종 일관성입니다.

"If you enable versioning on a bucket for the first time, it might take a short amount of time for the change to be fully propagated. We recommend that you wait for 15 minutes after enabling versioning before issuing write operations (PUT or DELETE requests) on objects in the bucket."

기본은 비공개, 접근 차단 설정이 기본으로 켜져 있다

버킷도 객체도 만들자마자 공개되는 일은 없습니다.

"By default, all general purpose buckets are private."

여기에 더해 Block Public Access(공개 접근 차단)라는 계정·버킷 단위 설정이 기본으로 켜져 있습니다.

"By default, new buckets, access points, and objects don't allow public access."

접근 통제는 버킷 정책과 계정 권한 관리 서비스인 IAM(Identity and Access Management)이 중심입니다. 예전에는 개별 객체·버킷 단위로 접근 권한을 붙이는 ACL(Access Control List — 접근 통제 목록)도 쓰였지만, 지금은 새 버킷에서 기본으로 꺼져 있습니다.

"By default, Object Ownership is set to the Bucket owner enforced setting, and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to them exclusively by using access-management policies."

시나리오 — 버킷 이름을 만들 때마다 이미 있다고 거부당한다

신규 프로젝트의 파일 저장용 버킷을 만들려는데, 계속 "이미 사용 중"이라는 오류만 돌아오는 상황을 가정합니다.

순진한 시도는 회사명이나 서비스명을 붙인 짧고 예쁜 이름(mycompany-uploads 같은)을 여러 방식으로 바꿔 가며 계속 시도하는 것입니다. 계정 안에서는 처음 쓰는 이름인데도 계속 실패합니다.

문제는 위에서 확인했듯 버킷 이름이 계정 단위가 아니라 파티션 전체에서 유일해야 하는 전역 네임스페이스라는 데 있습니다. 다른 계정이 이미 그 이름을 선점하고 있으면, 내 계정에서 한 번도 안 써 본 이름이라도 실패합니다.

정답은 두 갈래입니다. 하나는 이름 뒤에 계정 ID와 리전 코드를 붙인 계정 리전 네임스페이스를 쓰는 것입니다.

"New general purpose buckets created in your account regional namespace are unique to your account and can never be re-created by another account."

이 방식은 {{이름 접두사}}-계정ID-리전-an 형태를 강제로 따라야 합니다. 다른 하나는 무작위 문자열을 뒤에 덧붙여 이름 자체를 예측 불가능하게 만드는 방법입니다. 온프레미스에서는 파일 서버 이름이 사내에서만 겹치지 않으면 됐지만, S3 버킷 이름은 전 세계 다른 회사의 계정과도 겹치지 않아야 한다는 걸 이 시나리오가 보여줍니다.

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "네트워크 드라이브처럼 버킷을 마운트해서 쓰면 되겠지"

도입부 상황이 정확히 이 오해에서 시작합니다. S3에는 마운트 개념이 없습니다 — 접근은 REST API 호출입니다. 다만 파일 인터페이스가 꼭 필요한 상황을 위한 별도 계층이 있습니다. 하나는 AWS Storage Gateway의 S3 File Gateway로, NFS나 SMB 파일 공유처럼 온프레미스에 노출해 줍니다.

"By using this combination, you can store and retrieve objects in Amazon S3 using industry-standard file protocols such as Network File System (NFS) and Server Message Block (SMB)."

다른 하나는 리눅스 전용 오픈소스 클라이언트인 Mountpoint for S3로, 버킷을 로컬 파일 시스템처럼 마운트할 수 있게 해 줍니다. 다만 이름과 달리 완전한 파일 시스템은 아닙니다.

"Mountpoint supports basic file system operations, and can read files up to 50 TB in size. It can list and read existing files, and it can create new ones. It cannot modify existing files or delete directories, and it does not support symbolic links or file locking."

NAS는 POSIX(Portable Operating System Interface — 유닉스 계열 운영체제의 파일 접근 표준) 방식의 완전한 파일 시스템 의미론을 제공하지만, S3와 그 위에 얹는 파일 인터페이스 계층들은 처음부터 그 의미론 전체를 흉내 내도록 설계되지 않았습니다. "일단 마운트해서 기존 애플리케이션을 그대로 얹는다"는 접근은 되는 것 같다가도 파일 잠금이나 기존 파일 수정이 필요한 지점에서 막힙니다.

오해 2. "폴더를 지우면 그 폴더 전체가 지워진다"

1장에서 확인했듯 S3에는 진짜 폴더가 없습니다. 콘솔에서 "폴더를 삭제"하는 동작은 실제로는 그 접두사로 시작하는 객체들을 하나씩(또는 배치로) 삭제하는 것입니다. 반대로 "빈 폴더"를 만들었다고 생각했는데 나중에 API로 그 버킷을 조회하면, 콘솔에는 안 보이던 0바이트짜리 객체가 하나 있는 걸 발견하게 되는 경우도 있습니다. 온프레미스에서 rmdir로 디렉터리 자체를 지우는 감각과 달리, S3에서 지우는 대상은 처음부터 끝까지 "키를 가진 객체들"입니다.

오해 3. "저장만 해두면 어느 클래스든 여러 데이터센터에 복제돼 있다"

3장 표에서 봤듯 모든 스토리지 클래스가 같은 조건은 아닙니다. S3 One Zone-IA는 이름 그대로 단일 AZ에만 저장됩니다.

"S3 One Zone-IA – Amazon S3 stores the object data in only one Availability Zone, which makes it less expensive than S3 Standard-IA. However, the data is not resilient to the physical loss of the Availability Zone resulting from disasters, such as earthquakes and floods."

내구성 숫자(11개의 9)는 One Zone-IA도 다른 클래스와 똑같습니다 — 그 데이터센터 안에서는 여러 장치에 중복 저장되기 때문입니다. 하지만 그 데이터센터 자체가 재해로 사라지면 복구할 수 없다는 게 가용성 숫자(99.5%)가 다른 이유입니다. 공식 문서도 이 클래스의 권장 용도를 명확히 못박습니다.

"S3 One Zone-IA (ONEZONE_IA) – Use if you can re-create the data if the Availability Zone fails, for object replicas when configuring S3 Cross-Region Replication (CRR)."

여기서 말하는 CRR(Cross-Region Replication — 다른 리전으로 객체를 복제하는 기능)처럼, 원본 데이터, 다시 만들 수 없는 유일한 사본을 One Zone-IA에 두면 안 됩니다. 다시 만들 수 있는 데이터(다른 곳에 원본이 있는 복제본, 캐시 등)에만 어울리는 클래스입니다.

오해 4. "라이프사이클로 아무 때나 Glacier로 내리면 무조건 저렴해진다"

Standard-IA·One Zone-IA는 30일, Glacier Instant Retrieval은 90일, Glacier Flexible Retrieval과 Deep Archive는 90일과 180일이라는 최소 저장 기간이 있습니다. 이 기간을 못 채우고 삭제하거나 다른 클래스로 다시 옮기면 어떻게 될까요.

"The S3 Standard-IA and S3 One Zone-IA storage classes are suitable for objects larger than 128 KB that you plan to store for at least 30 days. If an object is less than 128 KB, Amazon S3 charges you for 128 KB. If you delete an object before the end of the 30-day minimum storage duration period, you are charged for 30 days."

용량이 작은 객체(128KB 미만)는 실제 크기와 무관하게 128KB로 청구되고, 최소 저장 기간을 못 채우고 지우면 그 남은 기간만큼 요금이 붙습니다. 클래스를 옮기는 전환(transition) 자체에도 별도 요청 비용이 듭니다.

"There are costs associated with lifecycle transition requests."

그리고 전환은 공짜로 되는 게 아니라 데이터를 다시 쓰는(ingest) 동작이라, 꺼낼 때 내는 검색 수수료와는 별개로 넣을 때 내는 비용이 붙습니다.

"There are no data retrieval charges for lifecycle transitions. However, there are per-request ingestion charges when using PUT, COPY, or lifecycle rules to move data into any S3 storage class."

온프레미스에서 "오래된 파일은 그냥 저렴한 디스크로 옮기면 이득"이었던 감각을 그대로 옮기면, 수명이 짧은 파일(로그처럼 금방 지워지는)에까지 라이프사이클을 걸었다가 최소 저장 기간 위약금성 청구와 전환 요청 비용이 겹쳐 오히려 손해를 볼 수 있습니다.

시나리오 — 로그를 Glacier로 자동 전환했더니 스토리지 비용이 오히려 늘었다

애플리케이션 로그를 매일 새 객체로 쌓아 두고, 오래된 로그는 저렴하게 보관하려는 상황을 가정합니다.

순진한 시도는 로그가 쌓이는 즉시(1일 뒤) Glacier Flexible Retrieval로 전환하는 라이프사이클 규칙을 겁니다. "어차피 오래된 로그니까 최대한 빨리 싼 곳으로 옮기는 게 이득"이라는 판단입니다.

문제는 이 서비스의 로그 보관 정책이 실제로는 60일 뒤 삭제라는 데 있습니다. Glacier Flexible Retrieval의 최소 저장 기간은 90일인데, 삭제는 그보다 30일 이른 60일째에 일어납니다. 위에서 확인했듯 최소 저장 기간을 못 채우고 삭제하면 그 남은 기간만큼 요금이 붙습니다. 게다가 로그 파일 다수가 128KB보다 작아, Standard에 있었다면 실제 크기대로 청구됐을 것이 Glacier로 전환되자마자 더 큰 최소 청구 용량 기준으로 다시 계산되고, 여기에 전환 자체의 요청 비용까지 매일 쌓입니다. "빨리 옮길수록 이득"이라는 가정과 반대로, 저장 단가는 낮아졌는데 총비용은 늘어난 상태로 나타납니다.

정답은 라이프사이클 규칙을 세우기 전에 그 데이터의 실제 보관 기간이 목표 클래스의 최소 저장 기간을 넘는지부터 확인하는 것입니다. 60일 만에 지워지는 로그라면 Glacier로 내리지 말고 Standard에 그대로 두고 60일째 만료(expiration)만 걸거나, 정말 장기 보관이 필요한 로그(예: 감사용 1년 보관분)만 따로 골라 90일 이상 지난 뒤에 전환하도록 조건을 나눠야 합니다. 접근 패턴이 불확실하다면 최소 저장 기간이 없는 S3 Intelligent-Tiering으로 옮겨 자동 최적화를 맡기는 것도 대안입니다.

5. 비용·운영 감각

온프레미스에서 NAS 한 대를 들이면 디스크·컨트롤러·전력·공간 비용이 도입 시점에 크게 몰려 나가고, 그 뒤로는 감가상각으로 흡수됩니다. S3는 반대로 처음부터 끝까지 실제로 쓴 만큼만 청구되는 종량제입니다.

"Amazon S3 charges you only for what you actually use, with no hidden fees and no overage charges."

과금은 크게 몇 갈래로 나뉩니다 — 저장한 용량, 요청 처리(PUT·GET·LIST 등 API 호출 횟수), 인터넷으로 나가는 데이터 전송량, 스토리지 클래스별 검색·복원 수수료, 그리고 라이프사이클 전환이나 Intelligent-Tiering 모니터링 같은 관리 기능 수수료입니다. 정확한 단가는 리전마다 다르고 시점에 따라 계속 바뀌므로, 이 글은 구체적인 숫자를 못박지 않습니다. Amazon S3 요금 페이지에서 리전을 선택해 직접 확인하는 것이 가장 정확한 방법입니다.

숫자를 찾아보기 전에 먼저 봐야 하는 건 "어떤 항목이 애초에 청구 대상인가"입니다. 4장에서 다뤘듯 스토리지 클래스를 낮은 등급으로 옮기는 전환 자체에도 요청 비용이 붙고, Standard-IA·Glacier 계열은 저장 단가가 싼 대신 꺼낼 때(GET) 검색 수수료가 따로 붙습니다. 온프레미스에서 "일단 디스크에 넣어 두면 다시 꺼내 쓰는 건 공짜"였던 감각을 그대로 옮기면, 자주 내려받는 데이터를 무작정 Glacier로 옮겼다가 검색 수수료 때문에 오히려 손해를 볼 수 있습니다. Storage Class Analysis 같은 도구로 실제 접근 패턴을 먼저 확인한 뒤 클래스를 고르는 편이, 요금표의 단가를 외우는 것보다 실무에서 더 유용합니다.

진짜 비용은 스토리지 클래스 선택과 라이프사이클 설계에 들이는 시간입니다. 저장 단가 몇 원 차이보다, 4장의 조기 전환 시나리오처럼 최소 저장 기간과 최소 청구 용량을 무시하고 라이프사이클을 설계하는 쪽이 훨씬 비싼 대가를 치르게 합니다.

6. 관련 개념

Amazon CloudFront — S3에 저장한 정적 콘텐츠를 전 세계 엣지 위치로 캐싱해 배포하는 CDN(Content Delivery Network — 콘텐츠를 사용자와 가까운 위치에서 캐싱해 전달하는 네트워크). S3가 원본(origin) 저장소, CloudFront가 배포 계층을 맡는 조합으로 자주 쓰인다.
AWS Storage Gateway(S3 File Gateway) — NFS·SMB로 S3를 파일 공유처럼 온프레미스에 노출해 주는 가상 어플라이언스(4장 오해 1).
Mountpoint for S3 — 리눅스 전용 오픈소스 파일 클라이언트. 완전한 POSIX 파일 시스템이 아니라 기본 연산만 지원한다(4장 오해 1).
EBS(Elastic Block Store)·EFS(Elastic File System) — 각각 블록·파일 스토리지로, 오브젝트 스토리지인 S3와는 계층이 다른 서비스다.
IAM·버킷 정책 — S3 접근 통제의 기반이 되는 계정 권한 체계(3장·4장).

7. 한눈에 정리

항목	확인할 것
접근 방식	마운트 아님 — REST API·콘솔·CLI, 또는 File Gateway·Mountpoint 같은 별도 계층이 필요
저장 구조	버킷 안 평평한 키 네임스페이스, 콘솔의 "폴더"는 접두사 흉내
버킷 이름	파티션 전체에서 유일해야 하고, 생성 후 이름·리전 변경 불가
스토리지 클래스	접근 빈도로 고른다 — 내구성은 대부분 동일, 가용성·AZ 수는 클래스마다 다름
객체 크기	콘솔 업로드 160GB, 단일 PUT 5GB, 멀티파트 업로드 5MB~50TB
일관성	PUT·DELETE는 전 리전에서 강한 읽기-후-쓰기 일관성
기본 접근 권한	비공개, Block Public Access 기본 켜짐, ACL은 기본 비활성화
라이프사이클	최소 저장 기간 전에 삭제·전환하면 잔여 기간만큼 비례 청구
비용 확인	숫자는 요금 페이지에서, 먼저 어떤 항목(저장·요청·전송·검색)이 청구 대상인지부터 파악

이어서 보면 좋은 글

개인정보처리방침

와우패널 — Sun, 6 Sep 2026 09:19:01 +0900

개인정보처리방침

wowpanel.tistory.com(이하 '블로그')을 운영하는 개인 운영자(이하 '운영자')는 이용자의 개인정보를 소중히 다루며 관련 법령을 준수합니다. 본 방침은 시행일자 기준으로 적용됩니다.

1. 수집하는 개인정보 항목 및 수집 방법

운영자는 별도의 회원가입 절차를 운영하지 않으며, 이용자가 자발적으로 입력하는 정보(방명록·댓글 작성 시 닉네임, 이메일, 비밀번호 등) 외에는 개인정보를 직접 수집하지 않습니다. 다만 블로그 이용 과정에서 아래 정보가 쿠키 등을 통해 자동으로 생성·수집될 수 있습니다.

방문 일시, 서비스 이용 기록, 접속 로그, 쿠키, 접속 IP, 기기 정보(OS·브라우저 종류)

2. 개인정보의 수집 및 이용 목적

방문자 통계 분석 및 블로그 서비스 개선 (Google Analytics 등)
이용자 맞춤형 광고 제공 (Google AdSense)
댓글·방명록 관리 및 스팸 방지

3. 쿠키(Cookie) 운영 및 광고 서비스 안내

본 블로그는 Google이 제공하는 애드센스(Google AdSense) 광고를 게재하고 있으며, Google을 비롯한 제3자 광고 네트워크 공급자는 쿠키를 사용해 이용자가 본 블로그 및 다른 사이트를 방문한 기록을 바탕으로 광고를 게재합니다.

이용자는 Google 광고 설정에서 맞춤 광고를 비활성화할 수 있습니다.
www.aboutads.info에서 제3자 공급업체의 맞춤 광고 쿠키 사용을 거부할 수 있습니다.
웹 브라우저 설정(예: 크롬 설정 > 개인정보 및 보안 > 쿠키)에서 쿠키 저장을 거부할 수 있으며, 이 경우 일부 서비스 이용에 제한이 있을 수 있습니다.

4. 개인정보의 제3자 제공 및 처리 위탁

운영자는 이용자의 개인정보를 원칙적으로 외부에 제공하지 않으며, 서비스 제공을 위해 아래와 같이 위탁하고 있습니다.

수탁업체	위탁업무 내용
Google LLC (Google AdSense)	맞춤형 광고 게재
Google LLC (Google Analytics)	방문자 통계 분석
카카오(티스토리)	블로그 플랫폼 운영, 방명록·댓글 기능 제공

5. 개인정보의 보유 및 이용 기간

이용자가 남긴 댓글·방명록은 해당 게시물이 삭제되거나 이용자가 삭제를 요청할 때까지 보관되며, 쿠키를 통해 수집된 정보는 관련 서비스(Google)의 정책에 따라 처리됩니다.

6. 이용자의 권리와 행사 방법

이용자는 언제든지 본인이 작성한 댓글·방명록의 열람, 정정, 삭제를 요청할 수 있으며, 아래 연락처로 문의 시 지체 없이 조치합니다.

7. 개인정보 보호책임자

담당자: 블로그 운영자
이메일: wowpanel.seo@gmail.com

문의사항은 위 이메일로 연락 주시면 신속히 답변드리겠습니다.

8. 고지의 의무

본 개인정보처리방침은 법령·정책 변경에 따라 내용이 추가·삭제 및 수정될 수 있으며, 변경 시 본 페이지를 통해 공지합니다.

부칙

본 방침은 2026년 9월 6일부터 시행됩니다.

lsof로 세면 안 보입니다 — 파일 디스크립터 고갈, 장애 하루 전 신호

와우패널 — Sun, 6 Sep 2026 08:56:30 +0900

프로세스가 파일을 못 열기 시작하면 증상이 사방으로 튑니다. 로그를 못 쓰고, 새 커넥션을 못 받고, 심하면 새 프로세스조차 못 띄웁니다. 원인은 하나 — 그 프로세스가 열 수 있는 파일 디스크립터 개수 한도(ulimit -n)에 이미 닿아 있었다는 것입니다. 이 글은 그 한도에 다가가는 신호를 어떻게 확인하는지(그리고 흔히 쓰는 방법이 왜 부정확한지), 실제로 한도까지 밀어붙였을 때 무슨 일이 벌어지는지, 오늘 무엇을 조치해야 하는지를 다룹니다.

금요일 저녁, 결제 API 서버 — 신규 커넥션이 간헐적으로 실패하기 시작했다. 애플리케이션 로그엔 Too many open files. 담당자는 lsof -p <PID> | wc -l로 열린 파일 수를 세어 봤다 — 결과는 800. ulimit -n은 1024. "아직 여유 있는데?" 하고 다른 곳을 팠다. 30분 뒤에야 알았다 — lsof 출력에는 실제 파일 디스크립터가 아닌 줄(현재 작업 디렉터리, 실행 파일 자체, 메모리 매핑)이 섞여 있어서, 진짜 사용량은 이미 1000을 넘어 있었다.

ulimit -n은 프로세스 하나가 동시에 열 수 있는 파일 디스크립터 개수의 상한입니다. 소켓, 열린 파일, 파이프 전부 이 한도 안에서 셉니다. 이 글에서는 이 한도를 정확히 세는 법, man 원전으로 확인한 위험 메커니즘, 실제로 한도까지 밀어붙인 재현 결과, 그리고 오늘 조치할 것을 정리합니다.

측정 환경: Rocky Linux 9.7(커널 5.14.0-611.47.1.el9_7) · GNU bash 5.1.8 · util-linux 2.37.4(prlimit) · lsof 4.94.0 · systemd 252 · GNU coreutils 8.32(df·ls). 이 글의 모든 명령 출력은 이 환경에서 직접 실행해 얻은 것입니다.

신호 관찰 — lsof로 세면 안 되는 이유
왜 위험한가 — 프로세스 한도와 시스템 한도는 다르다
재현 — 한도까지 밀어붙여 봅니다
임계값과 오탐 — 몇 %부터, 그리고 아닌 경우
지금 조치 — 지금 늘릴 수 있는 것과 재시작이 필요한 것
치트시트 — 정기 점검 명령

1. 신호 관찰 — `lsof`로 세면 안 되는 이유

lsof -p <PID>는 그 프로세스와 관련된 모든 항목을 보여줍니다 — 실제로 열린 파일 디스크립터뿐 아니라, 현재 작업 디렉터리(cwd)·루트(rtd)·실행 파일 자체(txt)·메모리 매핑(mem)까지 전부 한 줄씩 나옵니다. 이 중 ulimit -n이 세는 건 진짜 파일 디스크립터뿐입니다.

$ sleep 300 &
$ PID=$!
$ ls /proc/$PID/fd | wc -l
3
$ lsof -p $PID | wc -l
10
$ lsof -p $PID | head -5
COMMAND     PID     USER   FD   TYPE DEVICE  SIZE/OFF      NODE NAME
sleep   3631002 wowpanel  cwd    DIR  9,124      4096       131 /home/wowpanel
sleep   3631002 wowpanel  rtd    DIR  9,125       250       128 /
sleep   3631002 wowpanel  txt    REG  9,125     36312    357644 /usr/bin/sleep
sleep   3631002 wowpanel  mem    REG  9,125 223542144  33686081 /usr/lib/locale/locale-archive

방금 띄운 sleep은 실제로 열어 둔 파일 디스크립터가 표준입출력 3개뿐인데(/proc/$PID/fd 안 항목 수), lsof는 헤더 줄 포함 10줄을 보여줍니다. cwd·rtd·txt·mem은 FD 컬럼에 숫자가 아니라 저 문자열이 찍혀서 ulimit -n과 무관하다는 걸 알 수 있지만, lsof -p <PID> | wc -l로 통째로 세면 이 차이가 사라집니다. 정확히 세려면 /proc/<PID>/fd 디렉터리 안의 항목 수를 직접 셉니다.

ls /proc/<PID>/fd | wc -l은 헤더 줄이 없고 cwd·txt·mem 같은 비-fd 항목도 안 섞입니다. 이 디렉터리 안의 각 항목이 정확히 열린 파일 디스크립터 하나입니다.

2. 왜 위험한가 — 프로세스 한도와 시스템 한도는 다르다

파일 디스크립터 한도는 사실 두 개입니다. 이 둘을 헷갈리면 엉뚱한 곳을 고칩니다.

프로세스 한도 — `RLIMIT_NOFILE`, 넘으면 `EMFILE`

man getrlimit:

RLIMIT_NOFILE This specifies a value one greater than the maximum file descriptor number that can be opened by this process. Attempts (open(2), pipe(2), dup(2), etc.) to exceed this limit yield the error EMFILE.

시스템 전체 한도 — `/proc/sys/fs/file-max`, 넘으면 `ENFILE`

man proc:

/proc/sys/fs/file-max This file defines a system-wide limit on the number of open files for all processes. System calls that fail when encountering this limit fail with the error ENFILE. (See also setrlimit(2), which can be used by a process to set the per-process limit, RLIMIT_NOFILE, on the number of files it may open.)

두 한도는 에러 메시지 문구부터 다릅니다 — errno 24(EMFILE)는 Too many open files, errno 23(ENFILE)는 Too many open files **in system**입니다. 1편(inode 고갈)의 No space left on device는 원인이 둘(블록·inode)이어도 메시지가 완전히 같아서 df -i를 따로 찍어야 구분됐는데, 이번엔 메시지 자체가 어느 쪽인지 알려줍니다.

이 서버의 실제 값입니다.

$ ulimit -n
1024
$ ulimit -Hn
524288
$ cat /proc/sys/fs/file-max
9223372036854775807

소프트 1024·하드 524288은 흔히 "리눅스 전통 값"으로 오해하는데, 실제로는 systemd가 로그인 세션에 주는 기본값입니다.

DefaultLimitNOFILE= defaults to 1024:524288.
— man systemd-system.conf

file-max는 사실상 무제한(64비트 정수의 최댓값)입니다 — 이 서버에서 ENFILE은 현실적으로 거의 안 일어납니다. 운영 중에 실제로 만나는 건 거의 항상 EMFILE(프로세스 한도)입니다.

소켓을 대량으로 여는 프록시·DB·웹서버는 systemd가 주는 1024로 부족해서 서비스 유닛에 별도로 LimitNOFILE=을 올려 둡니다. 반대로 이 값을 아예 안 건드린 서비스가 갑자기 커넥션이 몰리면(트래픽 급증, 커넥션 정리 실패로 인한 누적) 프로세스 한도부터 부딪힙니다.

3. 재현 — 한도까지 밀어붙여 봅니다

bash -c로 자식 셸을 열어 ulimit -n을 낮게 잡고, 파일 디스크립터를 순서대로 열어 한도까지 채웁니다. 현재 로그인 셸의 ulimit은 건드리지 않습니다.

$ bash -c '
    ulimit -S -n 20
    i=3
    while :; do
      if eval "exec $i<>/dev/null" 2>/dev/null; then
        n=$i; i=$((i+1))
      else
        echo "마지막 성공: fd $n, 실패 지점: fd $i"
        break
      fi
    done
  '
마지막 성공: fd 18, 실패 지점: fd 19
bash: redirection error: cannot duplicate fd: Too many open files
bash: line 5: /dev/null: Too many open files

(뒤 두 줄은 2>/dev/null이 적용되기 전에 셸이 리다이렉션 실패 자체를 이미 찍은 것입니다 — 1편의 unshare 재현에서 본 것과 같은 현상입니다.)

한도 20 중 표준입출력 3개(0·1·2)를 빼면 17개를 더 열 수 있어야 할 것 같지만, 셸 자체가 내부적으로 몇 개를 더 쓰기 때문에 18에서 멈춥니다. 그리고 그다음 시도(fd 19)에서 정확히 EMFILE 메시지가 뜹니다.

여유를 더 안 남기고 한도까지 꽉 채우면 훨씬 이상한 증상이 나옵니다. 새 프로세스를 하나 더 띄우려고 하면(예: sleep), 이렇게 실패합니다 — 3회 반복해도 같은 결과입니다.

$ bash -c '
    ulimit -S -n 20
    for i in $(seq 3 20); do eval "exec $i<>/dev/null"; done
    sleep 5
  '
bash: line 3: /dev/null: Too many open files
sleep: error while loading shared libraries: libc.so.6: cannot open shared object file: Error 24

파일 디스크립터가 한도에 완전히 걸려 있으면 동적 링크된 실행 파일은 자기 공유 라이브러리(libc.so.6)조차 열지 못해 뜨지도 못합니다. Error 24가 EMFILE인 걸 모르면 "이게 왜 라이브러리 에러야?"로 완전히 엉뚱한 곳(라이브러리 경로, 패키지 손상)을 의심하게 됩니다. fd 고갈 상태에서 실행되는 헬스체크 스크립트·크론 잡이 하나같이 이 메시지로 죽는다면, 원인은 그 스크립트가 아니라 이미 fd가 꽉 찬 부모/형제 프로세스 쪽입니다.

4. 임계값과 오탐 — 몇 %부터, 그리고 아닌 경우

절대 개수(예: "800개 열림")는 의미가 없습니다. 그 프로세스의 ulimit -n(소프트) 대비 비율로 봐야 합니다. 1편과 같은 관례(경고 80% · 위험 90%)를 그대로 적용할 수 있지만, fd는 원인이 명확히 갈립니다 — 누수(연결을 정상적으로 닫지 않아 꾸준히 우상향)와 폭주(트래픽 급증으로 짧은 시간에 치솟음)는 대응이 다릅니다. 어제 대비 오늘 값을 비교해서 완만한 우상향인지 급등인지부터 구분합니다.

오탐 주의 — 이 신호인데 장애로 안 이어지는 경우

상황	왜 괜찮은가
`lsof -p <PID>`로 센 값이 `ulimit -n`에 근접	1장에서 본 것처럼 `cwd`·`rtd`·`txt`·`mem` 행이 섞여 과대 계산된 것 — `/proc/<PID>/fd` 개수로 다시 확인한다
커넥션 풀을 쓰는 서비스가 항상 `ulimit -n`의 60~70%를 유지	풀 크기만큼 미리 열어 두는 설계라면 그 자체가 정상 동작 — 어제 오늘 값이 그대로면(추세가 없으면) 급한 신호가 아니다
시스템 전체 `/proc/sys/fs/file-nr`의 첫 번째 값이 큼	`file-max`(두·세 번째 값)와 비교해서 판단 — 이 서버처럼 `file-max`가 사실상 무제한이면 이 수치 자체가 위험 신호가 아니다
프로세스 재시작 직후 fd 수가 낮았다가 서서히 정상 범위까지 오름	커넥션 풀·워커가 워밍업하며 채워지는 정상 과정 — 정상 범위(운영 중 관찰한 평상시 %)를 넘어서는지가 기준이지, 0에서 오르는 것 자체는 신호가 아니다

5. 지금 조치 — 지금 늘릴 수 있는 것과 재시작이 필요한 것

원인 프로세스와 fd 목록 확인

ls /proc/<PID>/fd | wc -l # 정확한 현재 사용량
grep "Max open files" /proc/<PID>/limits # 이 프로세스의 소프트·하드 한도
for f in /proc/<PID>/fd/*; do readlink "$f"; done | sed 's/:\[[0-9]*\]//' | sort | uniq -c | sort -rn | head
# 어떤 대상(소켓/파일/파이프)이 몰려 있는지

세 번째 명령은 /proc/<PID>/fd의 각 항목이 가리키는 대상(심볼릭 링크)을 readlink로 풀어서 종류별로 셉니다. (ls -l을 대신 쓰면 맨 위 "합계" 줄까지 집계에 섞여 값이 틀어집니다 — readlink는 그 문제가 없습니다.) 같은 호스트로 가는 소켓이 압도적으로 많다면 커넥션을 안 닫고 쌓는 누수, 특정 파일 하나가 반복해서 열려 있다면 그 파일을 닫지 않는 코드 경로를 의심합니다.

당장 할 수 있는 것 — 이미 떠 있는 프로세스라면 prlimit으로 하드 한도 범위 안에서 소프트 한도를 즉시 올릴 수 있습니다(재시작 불필요). man prlimit이 이걸 명시합니다 — "prlimit tries to retrieve and/or modify the limits", 대상은 --pid로 지정한 실행 중인 프로세스입니다. (이 글에서는 fd가 이미 소진된 프로세스를 상대로 실제 조정을 재현하려 했으나, 검증 환경에서 타이밍을 안정적으로 맞추지 못해 직접 재현 결과는 못 실었습니다 — 원전 인용으로 대신합니다. 운영 환경에서 쓰기 전에 낮은 위험도의 대상으로 먼저 검증해 보시길 권합니다.)

prlimit --pid <PID> --nofile=4096: # 소프트 한도만 4096으로 올림 (콜론 뒤 생략 시 하드는 유지)

지금 못 고치면 남겨 둘 것 — 프로세스를 재시작할 수 있다면 근본 해결은 시작 시점의 한도를 올리는 것입니다. systemd 유닛이면 LimitNOFILE=을 드롭인으로 추가(systemctl edit <유닛>), 로그인 세션에서 띄우는 프로세스면 /etc/security/limits.conf(PAM 세션 한정, systemd가 관리하는 서비스에는 적용 안 됨)를 확인합니다. 어느 쪽이든 재시작이 있어야 새 한도가 적용됩니다 — prlimit으로 당장 급한 불을 껐어도, 재발을 막으려면 시작 설정 자체를 고쳐야 합니다.

6. 치트시트 — 정기 점검 명령

ulimit -n # 현재 셸의 소프트 한도
cat /proc/<PID>/limits | grep "Max open files" # 특정 프로세스의 소프트·하드 한도
ls /proc/<PID>/fd | wc -l # 정확한 현재 사용량 (lsof 아님)
cat /proc/sys/fs/file-nr # 시스템 전체: 사용중/여유/상한
prlimit --pid <PID> --nofile=<새값>: # 재시작 없이 소프트 한도만 즉시 상향

이 글이 보탠 것 — lsof -p <PID> | wc -l이 실제 fd 사용량을 과대 계산한다는 것을 실측으로 확인하고, EMFILE(프로세스 한도)과 ENFILE(시스템 한도)이 서로 다른 메시지로 구분된다는 것을 man 원전과 실제 errno로 검증했습니다. 그리고 fd 한도에 걸린 프로세스는 새 파일뿐 아니라 새 프로세스의 공유 라이브러리 로딩까지 실패한다는, 겉보기엔 fd와 전혀 무관해 보이는 증상을 재현으로 확인했습니다.

1편(inode 고갈)과 이 글을 같이 보면, df -h·lsof 같이 익숙한 명령이 각각 왜 이 두 자원에 대해 오해를 부르는지가 드러납니다 — 둘 다 "직관적으로 보이는 명령이 사실은 다른 걸 재고 있었다"는 같은 함정입니다.

이어서 보면 좋은 글

RDS — "DB 서버 직접 구축" 감각으로 읽는 AWS의 관리형 데이터베이스

와우패널 — Sat, 5 Sep 2026 15:19:55 +0900

온프레미스에서 DB 서버를 하나 세우려면 물리 서버나 VM을 준비하고, OS를 깔고, MariaDB·MySQL·PostgreSQL 같은 엔진을 설치하고, 패치·백업 스크립트·장애조치 구성까지 전부 관리자가 직접 챙겨야 합니다. AWS RDS(Relational Database Service)는 이 중 상당 부분을 대신 맡아 주는 관리형 서비스입니다. 이 글은 RDS가 정확히 무엇을 대신해 주고 무엇은 여전히 내 몫으로 남는지, DB 서버를 직접 구축·운영해 본 사람이 RDS를 처음 만졌을 때 헷갈리는 지점을 다룹니다.

온프레미스에서 MariaDB 서버를 직접 구축해 운영하던 인프라팀이 신규 서비스의 DB를 RDS로 올리는 프로젝트를 맡았다. "관리형이니까 백업도 알아서 넉넉하게 챙겨 주겠지"라는 생각으로 기본값 그대로 인스턴스를 하나 띄우고 서비스를 연결했다. 두 달 뒤 배포 스크립트 오류로 실수로 테이블 하나를 통째로 지우는 사고가 났는데, 열흘 전 데이터로 복구하려다 보니 자동 백업이 하루치밖에 안 남아 있었다. "온프레미스에서는 cron으로 매일 자정 풀 백업을 받아 일주일치를 쌓아 뒀었는데"라는 질문에서 시작한다.

이 글은 실제 AWS 콘솔 화면이나 CLI(Command Line Interface — 명령줄로 AWS를 조작하는 도구) 실행 결과를 캡처하지 않습니다 — 이 프로젝트로 쓸 수 있는 AWS 계정이 없기 때문입니다. RDS의 정의와 관리 책임 분담, 이중화 배포·읽기 전용 복제본의 동작 방식, 자동 백업 보존 기간 기본값, 유지 관리 윈도우처럼 이 글이 다루는 사실 하나하나는 전부 AWS 공식 문서(Amazon RDS User Guide 등)를 직접 열어 원문을 대조한 것입니다.

1. RDS가 정확히 뭔가

AWS 공식 문서는 RDS를 이렇게 정의합니다.

"Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up, operate, and scale a relational database in the AWS Cloud. It provides cost-efficient, resizable capacity for an industry-standard relational database and manages common database administration tasks."

온프레미스에서 서버 한 대를 사면 CPU·메모리·스토리지·IOPS(Input/Output Operations Per Second — 초당 처리 가능한 입출력 작업 수)가 전부 하나로 묶여 있고, 그 서버와 그 위의 OS·DB 엔진까지 전부 관리자 책임입니다. RDS는 이 책임 중 상당 부분을 AWS와 나눠 갖습니다.

"Amazon RDS manages backups, software patching, automatic failure detection, and recovery."

RDS DB 인스턴스는 특정 리전의 특정 AZ(Availability Zone — 같은 리전 안에서 전력·냉각·네트워크가 서로 독립된 데이터센터 그룹)에 생성됩니다. 흔히 EC2(Elastic Compute Cloud — AWS의 가상 서버 서비스)로 띄운 애플리케이션 서버가 VPC(Virtual Private Cloud — 계정 전용으로 격리된 가상 네트워크) 안의 프라이빗 서브넷에 있는 이 DB 인스턴스에 접속하는 구성이 일반적입니다.

RDS가 지원하는 DB 엔진은 여섯 가지입니다.

"Amazon RDS supports the following database engines:"

IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL입니다.

MariaDB를 직접 구축해 운영해 봤다면, RDS for MariaDB는 그 엔진 자체(쿼리 문법·복제 방식 등)는 그대로 두고 그 아래 인프라 계층만 관리형으로 바꾼 것이라고 보면 됩니다. Amazon Aurora는 이 목록에 없는데, RDS와 나란히 붙어 다니는 이름이지만 별도 서비스이자 별도 문서로 다뤄집니다 — 자세한 내용은 6장에서 다룹니다.

그렇다고 모든 걸 다 대신해 주는 건 아닙니다. AWS 공식 문서는 온프레미스·EC2·RDS 세 가지 배포 방식의 관리 책임을 표로 비교합니다. 원문 표를 그대로 옮기면 다음과 같습니다.

기능	온프레미스 관리	EC2 관리	RDS 관리
애플리케이션 최적화	고객	고객	고객
스케일링	고객	고객	AWS
고가용성	고객	고객	AWS
데이터베이스 백업	고객	고객	AWS
데이터베이스 소프트웨어 패치	고객	고객	AWS
데이터베이스 소프트웨어 설치	고객	고객	AWS
OS 패치	고객	고객	AWS
OS 설치	고객	고객	AWS
서버 유지보수	고객	AWS	AWS
하드웨어 수명주기	고객	AWS	AWS
전력·네트워크·냉각	고객	AWS	AWS

표에서 빠진 항목이 하나 있습니다. 쿼리 성능입니다.

"Amazon RDS is responsible for hosting the software components and infrastructure of DB instances and DB clusters. You are responsible for query tuning, which is the process of adjusting SQL queries to improve performance."

즉 하드웨어·OS·DB 엔진 설치까지는 AWS가 책임지지만, 그 위에서 도는 쿼리가 느린 건 여전히 내 몫입니다. 온프레미스에서 DB 서버를 직접 구축할 때 하던 일 중 인프라 계층은 RDS로 넘어가지만, 스키마 설계와 쿼리 튜닝은 그대로 남는다는 뜻입니다.

2. 온프레미스 대응표

같은 물건이 아니라 "가장 가까운 것"입니다. 특히 Multi-AZ 배포와 읽기 전용 복제본은 둘 다 "인스턴스를 하나 더 두는 것"처럼 보이지만 목적이 다릅니다 — 대응시켜 놓고 다른 점을 무시하면 3장·4장에서 다루는 시나리오·오해로 바로 이어집니다.

온프레미스	AWS RDS	같은 점	다른 점
물리 서버/VM + OS + DB 엔진 설치	DB 인스턴스	격리된 DB 실행 환경	하드웨어·OS·엔진 설치는 AWS가 대신(1장)
my.cnf / postgresql.conf	DB 파라미터 그룹	엔진 동작 값 설정	그룹 하나를 여러 인스턴스에 같이 물린다(3장)
cron + mysqldump/xtrabackup	자동 백업	정기적으로 쌓이는 백업	기본 보존 기간 1일, 명시적으로 늘려야(4장)
고가용성 클러스터(Pacemaker 등) + 대기 서버	Multi-AZ 배포	장애조치용 대기 인스턴스	동기 복제, 형태에 따라 읽기를 못 받을 수도(3장)
읽기 전용 슬레이브(비동기 복제)	읽기 전용 복제본(Read Replica)	읽기 부하 분산	오토스케일링 없음, 수동 생성(3장)
새벽 시간대 정기 패치 창	유지 관리 윈도우	정기 패치 시간대	필수 업데이트는 마감일 지나면 강제 적용(4장)

3. 실무에서 반드시 알아야 하는 것

DB 인스턴스 클래스는 하드웨어 스펙이 아니라 계열로 고른다

RDS도 EC2처럼 자유롭게 CPU·메모리를 조합하는 게 아니라, 정해진 클래스 계열 중에서 고르는 방식입니다. AWS 공식 문서가 정리한 계열은 네 가지입니다.

계열	접두어
범용	`db.m*`
메모리 최적화	`db.z`, `db.x`, `db.r*`
컴퓨팅 최적화	`db.c*`
버스터블 성능	`db.t*`

계열 뒤에 세대·크기가 붙습니다. 예를 들어 db.m7g.2xlarge는 7세대 범용 계열에 AWS 그래비톤3 프로세서를 쓰는 크기 2xlarge 클래스입니다.

"db.m7g is a 7th-generation, general-purpose DB instance class type powered by AWS Graviton3 processors."

스토리지는 세 갈래로 나뉘고, 매그네틱은 이미 끝난 선택지다

DB 인스턴스 스토리지는 성능·용도가 다른 세 종류입니다. General Purpose(SSD)는 이렇게 설명됩니다.

"This cost-effective storage type is ideal for a broad range of workloads running on medium-sized DB instances. General Purpose storage is best suited for development and testing environments."

프로비저닝 IOPS(PIOPS)는 이렇게 설명됩니다.

"This storage type is designed to meet the needs of I/O-intensive workloads, particularly database workloads, that require low I/O latency and consistent I/O throughput. Provisioned IOPS storage is best suited for production environments."

매그네틱은 이미 끝난 선택지입니다.

"Magnetic storage is deprecated and is no longer offered for new DB instances. Starting July 1, 2026, you can no longer restore a snapshot to magnetic storage. Use General Purpose SSD or Provisioned IOPS SSD for any new storage needs."

2026년 7월 1일부터는 매그네틱 스토리지로 스냅샷을 복원하는 것 자체가 막혔습니다 — 새로 스토리지를 고를 일이 있다면 General Purpose SSD와 Provisioned IOPS 중에서 고르면 됩니다. 온프레미스에서 개발/운영 환경에 서로 다른 등급의 디스크(SATA vs SAS/NVMe)를 쓰던 감각과 비슷하게, 개발·테스트는 General Purpose SSD로, I/O가 몰리는 운영 환경은 Provisioned IOPS로 갈라 쓰면 됩니다.

Multi-AZ는 두 가지 형태가 있고, 읽기를 받는지가 갈린다

Multi-AZ 배포는 한 가지가 아니라 두 가지 형태로 나뉩니다.

"When the deployment has one standby DB instance, it's called a Multi-AZ DB instance deployment. A Multi-AZ DB instance deployment has one standby DB instance that provides failover support, but doesn't serve read traffic. When the deployment has two standby DB instances, it's called a Multi-AZ DB cluster deployment. A Multi-AZ DB cluster deployment has standby DB instances that provide failover support and can also serve read traffic."

DB 인스턴스 배포는 대기 인스턴스가 하나이고 동기 복제로 유지되지만, 그 대기 인스턴스는 읽기 트래픽을 아예 받지 않습니다.

"The following diagram depicts a Multi-AZ DB instance deployment, where Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. The replica database doesn't serve read traffic."

DB 클러스터 배포는 대기 인스턴스가 둘이고, 이 둘은 읽기 트래픽도 받을 수 있습니다. 온프레미스 고가용성 클러스터에서 흔히 쓰던 "액티브-스탠바이" 구성과 비슷한 건 앞의 DB 인스턴스 배포 쪽이고, 뒤의 DB 클러스터 배포는 그보다 한 단계 더 나아간 구성입니다.

읽기 전용 복제본은 비동기라 최신 값이 아닐 수 있다

읽기 전용 복제본은 Multi-AZ의 대기 인스턴스와 달리 비동기 복제로 동작합니다.

"Amazon RDS then uses the asynchronous replication method for the DB engine to update the read replica whenever there is a change to the primary DB instance."

원본 DB 인스턴스가 백업·유지보수로 잠시 I/O를 못 받는 상황에 읽기 트래픽을 복제본으로 돌리는 용도로도 쓸 수 있지만, 공식 문서는 이 경우 값이 최신이 아닐 수 있다고 명시합니다.

"In these cases, you can direct read traffic to your read replicas. For this use case, keep in mind that the data on the read replica might be 'stale' because the source DB instance is unavailable."

그리고 복제본은 늘었다 줄었다 자동으로 조절되지 않습니다.

"You must manually create read replicas. RDS doesn't support autoscaling of read replicas, which is the automatic add or removing of read replicas as read demand changes."

파라미터 그룹으로 엔진 설정을 관리한다

my.cnf나 postgresql.conf에 직접 값을 써넣던 감각은 파라미터 그룹으로 옮겨 갑니다.

"Database parameters specify how the database is configured. For example, database parameters can specify the amount of resources, such as memory, to allocate to a database."

설정값 자체를 직접 관리하는 방식은 이렇습니다.

"You manage your database configuration by associating your DB instances and Multi-AZ DB clusters with parameter groups."

설정 파일을 서버마다 따로 관리하는 대신, 그룹 하나를 만들어 여러 DB 인스턴스에 같이 물릴 수 있습니다.

자동 백업은 증분 스냅샷이고 기본 보존 기간은 하루뿐이다

첫 스냅샷은 전체 백업이지만, 그다음부터는 변경분만 저장됩니다.

"The first snapshot of a DB instance contains the data for the full database. Subsequent snapshots of the same database are incremental, which means that only the data that has changed after your most recent snapshot is saved."

보존 기간은 인스턴스를 만들 때 지정하는 값인데, API(Application Programming Interface — 프로그램끼리 주고받는 호출 인터페이스) 기본값이 생각보다 짧습니다.

"The number of days for which automated backups are retained. Setting this parameter to a positive number enables backups. Setting this parameter to 0 disables automated backups."

이 값의 공식 기본값은 1(하루)이고, 0부터 35 사이의 값만 허용됩니다. 그리고 이 DB 인스턴스가 읽기 전용 복제본의 원본이라면 0으로 설정할 수 없습니다 — 복제본이 참조하는 원본의 백업을 아예 꺼 버릴 수는 없다는 뜻입니다. 이 값은 자세히 4장에서 다시 다룹니다.

시나리오 — 읽기 부하를 어떻게 분산할까

애플리케이션 서버가 늘면서 DB 인스턴스 하나가 읽기 쿼리로 버거워지는 상황을 가정합니다.

순진한 시도는 이미 켜 둔 Multi-AZ 배포의 대기 인스턴스가 평소에 놀고 있으니, 애플리케이션의 읽기 커넥션 절반을 그쪽으로 돌리면 되겠다고 판단하는 것입니다. 장애조치용으로 대기 중인 인스턴스가 있으니 활용하지 않을 이유가 없어 보입니다.

문제는 이 DB 인스턴스가 (DB 클러스터 배포가 아니라) DB 인스턴스 배포로 구성돼 있었다는 데 있습니다. 앞서 확인했듯 이 형태의 대기 인스턴스는 읽기 트래픽을 아예 받지 않으므로, 그쪽으로 읽기 커넥션을 돌리려는 시도 자체가 성립하지 않습니다.

정답은 대기 인스턴스를 읽기용으로 쓰려 하는 대신, 읽기 전용 복제본을 별도로 만들어 읽기 트래픽만 그쪽으로 보내는 것입니다. 공식 문서도 이 두 기능을 동시에 쓸 수 있다고 밝힙니다.

"You can configure a read replica for a DB instance that also has a standby replica configured for high availability in a Multi-AZ deployment."

즉 장애조치는 Multi-AZ 대기 인스턴스가, 읽기 분산은 읽기 전용 복제본이 맡는 서로 다른 역할입니다. 대기 인스턴스를 읽기용으로 억지로 끌어다 쓰려 하지 말고, 필요하면 읽기 전용 복제본을 새로 붙이면 됩니다.

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "관리형이니까 백업 보존 기간도 기본으로 넉넉하게 잡혀 있겠지"

도입부 시나리오가 정확히 이 오해에서 시작합니다. 3장에서 확인했듯 자동 백업 보존 기간의 API 기본값은 1일입니다. 온프레미스에서 cron으로 일주일치 이상을 쌓아 두던 감각으로 별생각 없이 기본값을 그대로 두면, 사고가 나고 며칠이 지난 뒤에는 되돌릴 지점 자체가 사라져 있습니다. 인스턴스를 만들 때(또는 나중에 수정할 때) 보존 기간 값을 업무에 맞게 최대 35일까지 직접 늘려야 합니다.

오해 2. "마이너 버전 자동 업그레이드를 꺼두면 패치가 아예 안 온다"

운영체제·엔진 업데이트는 선택형과 필수형으로 나뉩니다.

"An optional update can be applied at any time. While these updates are optional, we recommend that you apply them periodically to keep your RDS fleet up to date. RDS does not apply these updates automatically."

"A mandatory update is required and has an apply date. Plan to schedule your update before this apply date. After the specified apply date, Amazon RDS automatically upgrades the operating system for your DB instance to the latest version during one of your assigned maintenance windows."

자동 마이너 버전 업그레이드 옵션을 꺼 둬도, 필수(mandatory) 업데이트는 지정된 적용 기한이 지나면 결국 강제로 적용됩니다.

"If you repeatedly modify your DB instance maintenance window to avoid a pending mandatory upgrade, Amazon RDS can still apply the upgrade outside of your preferred maintenance window after the mandatory apply date has passed."

유지 관리 윈도우를 계속 미루면 패치를 무기한 피할 수 있다고 여기기 쉽지만, 필수 업데이트에는 통하지 않습니다. 온프레미스에서 커널 보안 패치를 무한정 미루다가 감사에서 걸리는 것과 비슷한 구조이되, RDS 쪽은 사람이 안 움직이면 AWS가 대신 강제로 움직입니다.

오해 3. "Read Replica끼리 서로 복제를 걸어 이중화(순환 복제)할 수 있다"

온프레미스에서 마스터-마스터 구성을 해 봤다면 자연스럽게 떠오르는 발상이지만, RDS는 이걸 막아 둡니다.

"Amazon RDS doesn't support circular replication. You can't configure a DB instance to serve as a replication source for an existing DB instance."

다만 복제본에서 또 다른 복제본을 만드는 일렬 체인은 일부 엔진에서 허용됩니다.

"For RDS for MariaDB and RDS for MySQL, and for certain versions of RDS for PostgreSQL, you can create a read replica from an existing read replica."

즉 A → B → C처럼 한 방향으로 이어지는 체인은 되지만, C가 다시 A로 복제를 걸어 원을 만드는 구성은 안 됩니다.

오해 4. "읽기 전용 복제본은 원본과 스토리지 설정이 항상 똑같아야 한다"

기본값은 원본과 같은 스토리지 타입이지만, 다르게 지정할 수도 있습니다.

"By default, a read replica is created with the same storage type as the source DB instance. However, you can create a read replica that has a different storage type from the source DB instance based on the options listed in the following table."

다만 나중에 복제본 스토리지 용량을 늘리려면 최소 증가 폭 제한이 있습니다.

"When you increase the allocated storage of a read replica, it must be by at least 10 percent. If you try to increase the value by less than 10 percent, you get an error."

원본과 복제본을 무조건 똑같이 맞춰야 한다는 생각으로 접근하면 스토리지 타입을 못 바꾸는 줄 알고 지나치기 쉽지만, 실제로는 용도(예: 복제본을 리포팅 전용으로 쓰며 더 저렴한 타입으로)에 맞춰 다르게 가져갈 수 있습니다.

시나리오 — 무중단인 줄 알았던 유지보수 창에 서비스가 잠깐 끊겼다

Multi-AZ로 구성해 뒀으니 유지보수는 항상 무중단일 거라 믿고, 엔진 마이너 버전 업그레이드를 아무 유지보수 창에나 걸어 둔 상황을 가정합니다.

순진한 시도는 OS 패치 때와 똑같이, 대기 인스턴스를 먼저 패치하고 승격시키는 방식으로 짧게 끊기고 끝날 거라 예상하고 그대로 두는 것입니다.

문제는 엔진 버전 업그레이드가 OS 패치와 다른 절차를 탄다는 데 있습니다.

"If you upgrade the database engine for your DB instance in a Multi-AZ deployment, Amazon RDS modifies both primary and secondary DB instances at the same time. In this case, both the primary and secondary DB instances in the Multi-AZ deployment are unavailable during the upgrade. This operation causes downtime until the upgrade is complete."

OS 패치는 대기 인스턴스를 먼저 손보고 승격하는 방식이라 페일오버 수준(1분 미만)으로 끝나지만, 엔진 버전 업그레이드는 기본·대기 인스턴스를 동시에 손대기 때문에 그 시간만큼 온전히 다운타임이 발생합니다.

"If there are underlying operating system patches that need to be applied, a short Multi-AZ failover is required to apply the patches to the primary DB instance. This failover typically lasts less than a minute."

정답은 유지보수 계획을 세울 때 "OS·하드웨어 패치냐, 엔진 버전 업그레이드냐"를 구분하는 것입니다. 엔진 버전 업그레이드처럼 다운타임이 나는 작업은 트래픽이 가장 적은 시간대를 직접 골라 공지하고 진행해야 합니다. MySQL·PostgreSQL·MariaDB라면 다운타임을 줄이는 방법도 있습니다.

"If your DB instance runs RDS for MySQL, RDS for PostgreSQL, or RDS for MariaDB, you can minimize the downtime required for an upgrade by using a blue/green deployment."

당장 다운타임을 감수할 수 없다면 블루/그린 배포로 새 버전 환경을 미리 만들어 전환하는 쪽을 검토하고, 여유가 있다면 트래픽이 가장 적은 시간대에 짧은 다운타임을 감수하는 쪽으로 정리하면 됩니다.

5. 비용·운영 감각

온프레미스에서는 서버 감가상각·전력·냉각·공간 비용이 눈에 잘 안 보이는 방식으로 나갑니다. RDS는 이 비용을 아래 여섯 항목으로 명시적으로 청구합니다.

요금 항목	내용
DB 인스턴스 시간	사용한 인스턴스 클래스 기준
스토리지	DB 인스턴스에 프로비저닝한 용량(GB당 월 단위)
I/O 요청	Aurora·매그네틱 스토리지의 스토리지 I/O 요청 총량
프로비저닝 IOPS	실제 소비량과 무관하게 프로비저닝한 IOPS 기준
백업 스토리지	자동 백업·수동 스냅샷에 쓰인 스토리지
데이터 전송	DB 인스턴스로 들어오고 나가는 인터넷 데이터 전송량

인스턴스 시간은 온디맨드와 예약 두 가지 방식으로 지불합니다.

"You pay for compute capacity per hour your DB instance runs. With on-demand, there are no long-term commitments."
"You can reserve a DB instance for a one- or three-year term. Reserved Instances receive a significant discount compared to On-Demand Instances."

절감 폭은 최대 69%까지입니다.

"You can save up to 69% when you use Reserved Instances over on-demand rates when used in steady state."

"steady state", 즉 약정 기간 내내 그 인스턴스를 안정적으로 계속 쓴다는 전제가 붙습니다. 온프레미스에서 장비를 미리 구매해 두는 것과 비슷한 감각이지만, 중간에 껐다 켰다 하거나 클래스를 자주 바꾸면 이 절감률은 그대로 적용되지 않습니다.

프리 티어도 있습니다. db.t3.micro, db.t4g.micro 클래스로 MariaDB·MySQL·PostgreSQL·SQL Server Express Edition을 월 750시간까지 무료로 쓸 수 있습니다. 다만 이중화까지 무료로 연습해 볼 수는 없습니다.

"You can't use the following features, resources, and actions with AWS Free Tier on Amazon RDS:"

이 목록에 포함된 항목 중 하나가 다음입니다.

"Deployment options other than Single-AZ"

Multi-AZ는 프리 티어 대상이 아닙니다 — Single-AZ로만 무료 사용이 가능합니다.

유지 관리 윈도우는 리전마다 정해진 8시간 블록 안에서 30분이 무작위로 배정됩니다. 서울 리전(ap-northeast-2)의 기본 시간 블록은 13:00–21:00 UTC(Coordinated Universal Time — 세계 표준시)로, 한국 시간(UTC+9)으로 환산하면 22:00~06:00 사이입니다 — 별도로 지정하지 않아도 국내 새벽 시간대에 걸리도록 되어 있는 셈입니다.

진짜 비용은 인스턴스 요금표가 아니라 설계에 들이는 시간입니다. 백업 보존 기간을 기본값(1일)으로 방치하거나, Multi-AZ와 읽기 전용 복제본의 역할을 헷갈려 잘못된 구성으로 몇 달을 운영하는 쪽이 인스턴스 클래스를 한두 단계 잘못 고르는 것보다 훨씬 비싼 대가를 치르게 합니다.

6. 관련 개념

Amazon Aurora — MySQL·PostgreSQL과 호환되는 AWS 자체 스토리지 엔진. RDS와 이름이 나란히 다니지만 별도 User Guide로 다뤄지는 별도 서비스다(1장).
블루/그린 배포(Blue/Green Deployments) — 엔진 버전 업그레이드의 다운타임을 줄이기 위해 새 버전 환경을 미리 만들어 전환하는 배포 방식(4장 시나리오).
Amazon CloudWatch — RDS가 활성 데이터베이스마다 매 분 자동으로 지표를 보내는 모니터링 서비스. 이 지표 전송 자체는 추가 과금이 없다.
RDS Performance Insights·Enhanced Monitoring — 부하가 큰 쿼리를 찾아내는 도구. 쿼리 튜닝 자체는 여전히 고객 책임이라는 것(1장)과 맞물린다.
보안 그룹 — VPC 안에서 DB 인스턴스로의 접근을 IP 대역이나 다른 리소스 단위로 통제하는 방화벽 규칙. RDS DB 인스턴스도 이 규칙 아래 있다.

7. 한눈에 정리

항목	확인할 것
관리 책임	하드웨어·OS·엔진 설치·패치·백업·장애조치는 AWS, 쿼리 튜닝은 여전히 내 몫
Multi-AZ DB 인스턴스 배포	동기 대기 인스턴스 1개, 읽기 트래픽을 받지 않는다
Multi-AZ DB 클러스터 배포	대기 인스턴스 2개, 읽기 트래픽을 받을 수 있다
읽기 전용 복제본	비동기, 수동 생성·오토스케일링 없음, 승격 가능, 순환 복제 불가
자동 백업	증분 스냅샷, 기본 보존 기간 1일(최대 35일) — 명시적으로 늘려야 한다
유지 관리 윈도우	30분, 리전별 8시간 블록에서 무작위 배정
필수 업데이트	유예해도 적용 기한이 지나면 강제 적용된다
엔진 버전 업그레이드(Multi-AZ)	OS 패치와 달리 기본·대기 인스턴스가 동시에 다운타임을 겪는다
프리 티어	Single-AZ만 대상, Multi-AZ는 프리 티어로 못 쓴다
예약 인스턴스	1·3년 약정, 최대 69% 절감

이어서 보면 좋은 글

df -h는 여유 있는데 파일이 안 만들어집니다 — inode 고갈, 장애 하루 전 신호

와우패널 — Sat, 5 Sep 2026 07:54:48 +0900

df -h를 찍어 보면 디스크는 절반도 안 찼습니다. 그런데 애플리케이션은 로그를 못 쓰고, 세션 파일을 못 만들고, 업로드가 계속 실패합니다. 에러 메시지는 하필 디스크가 꽉 찼을 때와 똑같은 문구입니다. 이 글은 이 상태가 장애 당일 갑자기 생기는 게 아니라, 하루 전부터 df -i 한 줄이면 보였던 신호라는 것과, 그 신호를 오늘 어떻게 확인하고 조치하는지를 다룹니다.

목요일 오후, 배치 서버 — 파일 업로드 API가 간헐적으로 500을 뱉기 시작했다. 담당자가 제일 먼저 한 일은 df -h / — 결과는 62%. "디스크는 남아 있는데 왜 안 되지?" 하고 애플리케이션 로그를 보니 write(): No space left on device. 디스크 용량과 에러 메시지가 서로 모순되는 것처럼 보여서 30분을 애플리케이션 코드에서 헤맸다. 원인은 그 파티션의 inode가 이미 하루 전부터 소진되고 있었다는 것 — df -h는 이 상태를 절대 보여주지 않는다.

df -h와 df -i는 같은 파티션을 서로 다른 자원 기준으로 봅니다. 하나가 여유 있다고 다른 하나도 여유 있는 건 아닙니다. 이 글에서는 그 구분이 왜 생기는지를 파일시스템 문서로 확인하고, 실제로 inode를 소진시켜 같은 에러 메시지를 재현해 보고, 오늘 무엇을 확인해야 하는지를 정리합니다.

측정 환경: Rocky Linux 9.7(커널 5.14.0-611.47.1.el9_7) · util-linux 2.37.4(unshare) · e2fsprogs 1.46.5(mke2fs·resize2fs·dumpe2fs) · xfsprogs 6.4.0(mkfs.xfs·xfs_info) · GNU coreutils 8.32(df). 이 글의 모든 명령 출력은 이 환경에서 직접 실행해 얻은 것입니다.

신호 관찰 — 지금 뭘 보면 보이는가
왜 위험한가 — 파일시스템마다 다른 메커니즘
재현 — 실제로 소진시켜 봅니다
임계값과 오탐 — 몇 %부터, 그리고 아닌 경우
지금 조치 — 원인을 찾고, 줄이고, 재발을 막습니다
치트시트 — 정기 점검 명령

1. 신호 관찰 — 지금 뭘 보면 보이는가

df -h는 블록(용량) 기준입니다. df -i는 inode(파일 개수 한도) 기준입니다. 파일 하나를 만들려면 내용을 담을 블록도 있어야 하지만, 그 파일을 가리킬 inode도 하나 있어야 합니다. 블록은 남아도 inode가 없으면 파일을 못 만듭니다 — 그 반대(inode는 남는데 블록이 없는 경우)가 훨씬 흔해서, 대부분의 운영자는 df -h만 보는 데 익숙합니다.

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/md125       25G  5.9G   20G   24% /

$ df -i /
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/md125    13101568 144192 12957376    2% /

이 서버는 둘 다 여유롭습니다. 문제는 이 두 수치가 서로 독립적으로 움직인다는 것 — df -h의 Use%가 낮다고 df -i의 IUse%도 낮다는 보장은 없습니다. 작은 파일(세션 파일, 락 파일, 캐시 파일, 빈 마커 파일)을 대량으로 만드는 워크로드에서는 블록은 거의 안 쓰는데 inode만 빠르게 소진됩니다. 3장에서 이 상태를 실제로 만들어 봅니다.

-h는 df -i에도 그대로 적용됩니다 — 위 예시를 df -ih /로 다시 찍으면 13101568이 13M으로, 144192가 141K로 축약됩니다. 다만 파일 개수는 애초에 백만·천만 단위라 축약하면 임계값(예: 90%)과 비교하기 오히려 불편해서, 이 글의 나머지 예시는 -h 없이 원래 개수로 씁니다.

2. 왜 위험한가 — 파일시스템마다 다른 메커니즘

"inode가 부족하다"는 말이 모든 파일시스템에서 같은 뜻은 아닙니다. 흔히 쓰는 세 가지를 man 원전으로 확인합니다.

ext4 · tmpfs — 만들 때 개수가 고정된다

mke2fs(ext2/3/4)는 파일시스템을 만드는 시점에 inode 개수를 정해서 굽습니다. man mkfs.ext4:

-i bytes-per-inode
Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer inodes will be created.
-N number-of-inodes
Overrides the default calculation of the number of inodes that should be reserved for the file system (which is based on the number of blocks and the bytes-per-inode ratio).

tmpfs(메모리 기반, /tmp·컨테이너 레이어에 흔함)도 같은 방식입니다. man tmpfs:

nr_inodes=inodes
The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is smaller.

두 경우 다 파일 크기와 무관하게 개수 자체에 상한이 있습니다. 0바이트짜리 파일 100만 개도 각자 inode 하나씩을 씁니다.

XFS — 동적이지만 상한이 있다

Rocky/RHEL 계열 기본 파일시스템인 XFS는 필요할 때 inode를 동적으로 더 할당합니다 — ext4처럼 미리 정해두지 않습니다. 대신 전체 용량 대비 inode에 쓸 수 있는 비율 상한(imaxpct)이 있습니다. man mkfs.xfs:

maxpct=value
This specifies the maximum percentage of space in the filesystem that can be allocated to inodes. The default value is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% for filesystems over 50TB.

실제 검증 서버 루트 파티션 값입니다.

$ xfs_info / | head -6
meta-data=/dev/md125             isize=512    agcount=4, agsize=1637696 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=6550784, imaxpct=25

imaxpct=25 — 이 파티션 용량의 25%를 넘겨서까지 inode를 늘리지는 않는다는 뜻입니다. 메커니즘은 다르지만 결론은 같습니다 — ext4·tmpfs는 처음부터 막혀 있고, XFS는 늦게 막히지만 결국 막힙니다.

XFS에서 inode가 소진되는 상황은 ext4보다 흔치 않습니다. 아주 작은 파일(수 바이트) 수백만 개가 쌓이는 워크로드(세션 스토리지, 메일 큐, 캐시)가 아니면 25% 상한에 먼저 닿기 전에 데이터 용량이 먼저 찹니다. 반대로 ext4·tmpfs는 파일 크기와 무관하게 개수만으로 먼저 막힐 수 있어 더 자주 봅니다.

3. 재현 — 실제로 소진시켜 봅니다

운영 파티션에서 재현할 수는 없으니, unshare -rm으로 새 마운트 네임스페이스를 열고 그 안에서만 존재하는 작은 tmpfs를 inode 100개짜리로 만듭니다. sudo 없이, 호스트에는 아무 흔적도 안 남고, 셸이 끝나면 사라집니다.

$ LANG=C unshare -rm bash -c '
    mount -t tmpfs -o size=16m,nr_inodes=100 tmpfs /tmp/inode-lab
    cd /tmp/inode-lab
    for i in $(seq 1 200); do : > file$i 2>/dev/null || { echo "마지막 성공: file$((i-1))"; break; }; done
    df -h .
    df -i .
    touch onemore
  '
마지막 성공: file90
bash: line 4: file91: No space left on device
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            16M     0   16M   0% /tmp/inode-lab
Filesystem     Inodes IUsed IFree IUse% Mounted on
tmpfs             100   100     0  100% /tmp/inode-lab
touch: cannot touch 'onemore': No space left on device

(file91 실패 메시지가 한 번 노출되는 것은 정상입니다 — 그 리다이렉션이 열리는 시점의 오류라 2>/dev/null이 적용되기 전에 셸이 먼저 찍습니다. 루프는 그 즉시 멈춥니다.)

df -h는 여전히 0% Use(16M 전부 여유)입니다. 0바이트 파일들이라 블록을 거의 안 썼기 때문입니다. 그런데 df -i는 100% IUse고, 91번째 파일부터는 전부 실패했습니다. 그리고 이 에러 메시지 — No space left on device — 는 진짜로 디스크가 꽉 찼을 때 나오는 메시지와 완전히 동일합니다. 커널이 반환하는 errno가 둘 다 ENOSPC라서 그렇습니다. 메시지만 봐서는 절대 구분이 안 되고, df -i를 직접 찍어야만 구분됩니다.

장애 중에 No space left on device를 보면 반사적으로 df -h부터 찍습니다. 그게 여유 있다고 "디스크 문제는 아니네" 하고 넘어가면, 진짜 원인(inode)을 놓칩니다. 이 메시지를 보면 df -h와 df -i를 항상 같이 찍습니다.

4. 임계값과 오탐 — 몇 %부터, 그리고 아닌 경우

정해진 표준값은 없지만, 디스크 용량 점검에 쓰는 관례(경고 80% · 위험 90%)를 inode에도 그대로 적용하는 운영팀이 많습니다. 근거는 단순합니다 — inode도 df -i의 IUse%가 100%에 닿는 순간 그 이후 동작(둘 다 "새 파일을 못 만든다")이 똑같기 때문입니다.

그런데 inode는 절대값보다 증가율이 더 중요합니다. 디스크 용량은 보통 로그처럼 완만하게 늡니다. inode는 세션 폭주·재시도 루프처럼 짧은 시간에 수만 개가 만들어지는 워크로드에서 소진되는 경우가 많아서, 어제 2%였던 게 오늘 갑자기 90%일 수 있습니다. 하루 한 번 df -i를 찍는 것보다, 전날 값과 비교하는 것이 실질적인 조기 경보입니다.

오탐 주의 — 이 신호인데 장애로 안 이어지는 경우

상황	왜 괜찮은가
XFS에서 `IUse%`가 서서히 오르지만 `imaxpct`(기본 25%)에 한참 못 미침	동적 할당이라 필요한 만큼만 늘어난 것 — ext4의 "고정 상한 근접"과 성격이 다르다. `xfs_info`의 `imaxpct`와 비교해서 판단한다
대량의 하드링크·심볼릭 링크로 `IUsed`가 높아 보임	링크는 새 inode를 만드는 경우와 안 만드는 경우가 갈린다(하드링크는 기존 inode 재사용, 심볼릭 링크는 새 inode 소비) — `IUsed` 증가가 실제 파일 증가와 항상 비례하진 않는다
컨테이너 이미지 레이어가 많아 `IUsed`가 큼	레이어 자체는 정적 — 지속적으로 새 파일을 만드는 워크로드와 달리 더 늘지 않는다면 급한 신호가 아니다
tmpfs `nr_inodes`를 마운트 옵션으로 넉넉히 잡아둔 경우	기본값(RAM 페이지의 절반)보다 낮춰 잡은 게 아니라면 일반적인 사용량으로는 잘 안 닿는다

5. 지금 조치 — 원인을 찾고, 줄이고, 재발을 막습니다

어디에 몰려 있는지 찾기

du는 용량 기준이라 inode 개수를 안 보여줍니다. 디렉터리별로 파일 개수를 직접 세야 합니다.

$ for d in /tmp/inode-lab/*/; do
    echo "$(find "$d" | wc -l) $d"
  done | sort -rn
201 /tmp/inode-lab/appA/
6 /tmp/inode-lab/appB/

숫자가 압도적으로 큰 디렉터리가 원인입니다. 실무에서는 세션 저장 디렉터리(/var/lib/php/session 류), 메일 큐, 애플리케이션이 정리를 안 하는 임시 디렉터리, 로그 회전이 실패해 잘게 쌓인 조각 파일이 흔한 범인입니다.

당장 할 수 있는 것 — 원인 디렉터리를 찾았으면 오래된 파일부터 지웁니다(find 디렉터리 -type f -mtime +N -delete, 지우기 전에 -mtime +N 조건까지만 걸어서 몇 개가 걸리는지 먼저 세어 봅니다). 지우는 순간 df -i의 IFree가 그만큼 바로 돌아옵니다 — 블록과 달리 반영이 즉시입니다.

지금 못 고치면 남겨 둘 것 — 원인 프로세스를 당장 못 건드리는 상황(운영 중인 세션 스토어 등)이면, 최소한 알림 임계값을 IUse% 기준으로 하나 걸어 두고 넘깁니다. "블록 용량은 감시하고 있었다"는 다음 장애의 변명이 안 됩니다.

growfs로 해결되지 않는 경우

디스크(파티션) 자체를 키우면서 resize2fs로 확장하면 inode도 늘어납니다. man mkfs.ext4의 -i 항목이 이미 못 박아 두고 있습니다.

Be warned that it is not possible to change this ratio on a file system after it is created, so be careful deciding the correct value for this parameter. Note that resizing a file system changes the number of inodes to maintain this ratio.

실제로 검증 서버에서 64M→256M(4배)로 키웠더니 inode도 16384개→65536개(정확히 4배)로 늘었습니다.

$ dumpe2fs -h fstest.img | grep -E "^Inode count|^Block count" # 64M, 확장 전
Inode count:              16384
Block count:              65536
$ resize2fs fstest.img # 256M로 truncate 후
$ dumpe2fs -h fstest.img | grep -E "^Inode count|^Block count" # 확장 후
Inode count:              65536
Block count:              262144

(grep -i "inode count\|block count"처럼 느슨하게 잡으면 Reserved block count 줄까지 같이 걸립니다 — 줄 시작(^)을 고정해야 정확히 두 줄만 남습니다.)

문제는 디스크 용량 자체를 늘릴 수 없을 때입니다. resize2fs에는 inode 개수만 별도로 늘리는 옵션이 없습니다(-N은 mke2fs에만 있습니다) — 같은 크기에서 inode만 더 확보하려면 백업 → 재mkfs(다른 -i/-N 값으로) → 복원뿐입니다. 원인 파일 정리로 당장 급한 불을 끄고, 재발이 예상되면 이 재구성을 계획에 넣어야 합니다.

XFS는 이 지점에서 ext4·tmpfs보다 옵션이 하나 더 있습니다. man xfs_growfs:

-m Specify a new value for the maximum percentage of space in the filesystem that can be allocated as inodes. In mkfs.xfs(8) this is specified with -i maxpct=nn.

즉 용량을 안 늘려도 imaxpct 상한 자체를 마운트된 상태에서 올릴 수 있습니다(이 글에서 직접 재현하지는 않았습니다 — 운영 서버에서 루프 마운트에 필요한 권한이 없어 man 원전 확인으로 대신합니다). ext4·tmpfs는 이 여지가 아예 없다는 점이 2장에서 본 "처음부터 막힘 vs 늦게 막힘" 차이가 조치 단계까지 그대로 이어지는 지점입니다.

6. 치트시트 — 정기 점검 명령

df -hT # 파티션별 용량
df -iT # 파티션별 inode — 위와 반드시 같이 본다
xfs_info <마운트포인트> | grep imaxpct # XFS라면 상한을 확인
for d in <상위디렉터리>/*/; do echo "$(find "$d" | wc -l) $d"; done | sort -rn | head
# 어느 디렉터리가 파일 개수를 잡아먹는지

이 글이 보탠 것 — df -h가 여유로워도 안심할 수 없는 이유를 파일시스템 문서(ext4·tmpfs·XFS)로 확인하고, 실제로 inode를 소진시켜 No space left on device가 디스크 풀과 똑같이 뜬다는 것, 그리고 resize2fs가 확장 시에는 inode도 비례해서 늘리지만 용량을 안 늘리면 inode만 따로는 못 늘린다는 것을 실측으로 확인했습니다.

다음 글은 같은 관점으로 파일 디스크립터를 봅니다 — lsof 카운트가 ulimit -n에 조용히 다가가는 신호입니다.

이어서 보면 좋은 글

IAM — 온프레미스 AD/LDAP 감각으로 읽는 AWS의 계정·권한 관리

와우패널 — Fri, 4 Sep 2026 15:18:21 +0900

온프레미스에서는 AD(Active Directory)나 LDAP(Lightweight Directory Access Protocol — 디렉터리 서버에 계정 정보를 조회·인증하는 표준 프로토콜) 서버 하나가 "누가 로그인했는지"와 "그 계정이 뭘 할 수 있는지"를 동시에 관리합니다. AWS에서는 이 역할을 IAM(Identity and Access Management) 이 맡습니다. 다만 AD처럼 서버 한 대를 구축·운영하는 게 아니라, 계정을 만드는 순간부터 이미 존재하는 관리형 서비스라는 점이 다릅니다. 이 글은 IAM이 정확히 무엇이고, AD·LDAP를 다뤄 본 사람이 이걸 처음 만졌을 때 어디서 헷갈리는지를 다룹니다.

온프레미스에서 AD 관리자로 일하던 사람이 새 AWS 계정의 권한 관리를 맡았다. 팀원이 늘 때마다 기존 개발자 계정을 복사해서 새 IAM 사용자를 만들었고, 매일 도는 배치 스크립트에는 "일단 되게 하려고" 액세스 키를 코드에 그대로 박아 넣었다. 몇 달 뒤 그 코드가 실수로 깃허브 공개 저장소에 올라갔고, 그 액세스 키로 낯선 리전에 인스턴스가 대량으로 뜨는 사고가 났다. "AD에서는 계정 하나 새로 파는 게 이렇게 위험하지 않았는데"라는 질문에서 시작한다.

이 글은 실제 AWS 콘솔 화면이나 CLI(Command Line Interface — 명령줄로 AWS를 조작하는 도구) 실행 결과를 캡처하지 않습니다 — 이 프로젝트로 쓸 수 있는 AWS 계정이 없기 때문입니다. IAM 사용자·그룹·역할의 정의, 정책 평가 로직, 루트 사용자 권장 사항, 계정 할당량처럼 이 글이 다루는 사실 하나하나는 전부 AWS 공식 문서(IAM User Guide 등)를 직접 열어 원문을 대조한 것입니다.

1. IAM이 정확히 뭔가

AWS 공식 문서는 IAM을 이렇게 정의합니다.

"AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. With IAM, you can manage permissions that control which AWS resources users can access. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources."

핵심은 인증(authentication — 누구인지 확인) 과 인가(authorization — 그 신원이 뭘 할 수 있는지 결정) 를 나눠서 본다는 점입니다. AD에서 로그온(인증)과 GPO(Group Policy Object — 그룹 단위로 정책을 배포하는 AD 기능)·ACL(Access Control List, 접근 제어 목록) (인가)이 별개 메커니즘이던 것과 같은 구조입니다. 다만 IAM은 이 둘을 하나의 서비스 안에서 함께 다룹니다.

AWS 계정을 처음 만들면, 이미 계정 전체에 대한 전권을 가진 단일 신원이 하나 존재합니다.

"When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user."

이게 루트 사용자입니다. AD의 최상위 도메인 관리자 계정과 비슷해 보이지만, 다루는 방식은 다릅니다 — 자세한 내용은 4장에서 다룹니다. 루트 사용자 외의 나머지 신원(관리자·개발자·애플리케이션)은 전부 IAM으로 직접 만들어야 합니다. AD처럼 이미 도메인 컨트롤러가 계정 저장소 역할을 하고 있는 게 아니라, 계정 자체를 IAM 위에 새로 쌓아 올리는 셈입니다.

2. 온프레미스 대응표

같은 물건이 아니라 "가장 가까운 것"입니다. 특히 IAM 사용자·그룹은 AD 계정·그룹과 이름은 비슷해도 권장되는 쓰임새가 다릅니다 — 대응시켜 놓고 다른 점을 무시하면 4장에서 다루는 오해로 바로 이어집니다. 표의 마지막 두 행에 나오는 ADFS(Active Directory Federation Services — AD 계정으로 외부 서비스에 로그인하게 해주는 페더레이션 서버) 와 AWS SSO(Single Sign-On, 2022년 IAM Identity Center로 이름이 바뀐 서비스) 를 여기서 먼저 풀어 둡니다. IAM Identity Center가 연동하는 IdP(Identity Provider — 사용자 인증을 대신 처리해 주는 외부 신원 공급자) 라는 용어도 표에 함께 나오고, IAM 정책은 JSON(JavaScript Object Notation — 키·값 구조로 데이터를 표현하는 텍스트 형식) 문서로 작성됩니다.

온프레미스 AD/LDAP	AWS IAM	같은 점	다른 점
도메인 계정	IAM 사용자	개별 자격증명	사람 계정엔 페더레이션 권장(4장)
보안 그룹(AD 그룹)	IAM 그룹	계정을 묶어 관리	리소스 접근 주체 아님, 중첩 불가(4장)
서비스 계정·위임 토큰	IAM 역할	서비스가 대신 쓰는 자격증명	항상 임시, 장기 암호·키 없음(3장)
GPO·ACL	IAM 정책(JSON)	권한 규칙 정의	명시적 거부가 항상 우선(3장)
도메인 관리자 계정	루트 사용자	계정 최고 권한	일상 사용 금지, 특정 작업 전용(4장)
ADFS	IAM Identity Center	외부 IdP 연동 통합 인증	여러 AWS 계정 접근을 한 곳에서(6장)
AD 서버 자체 이전	AWS Directory Service	실제 AD를 관리형으로 운영	IAM과 별개 서비스(6장)

3. 실무에서 반드시 알아야 하는 것

새로 만든 사용자·역할은 기본적으로 아무 권한이 없다

AWS 공식 문서는 이렇게 명시합니다.

"By default, a new IAM user has no permissions to do anything. They are not authorized to perform any AWS operations or to access any AWS resources."

AD 계정을 만들면 최소한 도메인에 로그인은 되는 것과 달리, 갓 만든 IAM 사용자·역할은 정책을 붙여 주기 전까지 콘솔에 로그인해도 아무것도 할 수 없습니다. 권한을 시작할 때는 AWS가 미리 만들어 둔 관리형 정책(AWS managed policy)을 붙이는 게 빠르지만, 공식 문서는 이렇게 경고합니다.

"Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they are available for use by all AWS customers. As a result, we recommend that you reduce permissions further by defining customer managed policies that are specific to your use cases."

여러 고객이 공통으로 쓰는 정책이라 필요 이상으로 넓은 경우가 흔합니다 — 시작은 관리형 정책으로 하되, 실제 사용 패턴이 파악되면 그 계정 전용 정책(customer managed policy)으로 좁혀 가는 것이 최소 권한 원칙(least privilege) 입니다.

정책 평가는 기본적으로 전부 거부, 명시적 거부가 항상 이긴다

정책을 여러 개(identity-based, resource-based 등) 동시에 걸었을 때 AWS가 판단하는 순서는 이렇습니다.

"AWS first checks all policies for a Deny. If one exists, then the request is denied. Then AWS checks for each Allow. If at least one policy statement allows the action in the request, the request is allowed."

즉 기본값은 거부(default deny) 이고, 어딘가에 허용(Allow) 문이 있어야 통과합니다. 그리고 어느 정책에든 명시적 거부(explicit Deny)가 하나라도 있으면, 다른 곳의 허용을 전부 무시하고 거부가 이깁니다. GPO에서 "거부"가 "허용"보다 우선하는 것과 같은 방향의 규칙이지만, IAM에서는 이게 모든 정책 종류(identity-based·resource-based·권한 경계 등)에 걸쳐 예외 없이 적용된다는 점이 다릅니다.

identity-based 정책과 resource-based 정책은 같은 계정 안에서 합집합으로 평가된다

IAM 정책은 붙는 위치에 따라 두 종류로 나뉩니다.

"Identity-based policies are attached to an IAM user, group, or role... Resource-based policies are attached to a resource. For example, you can attach resource-based policies to Amazon S3 buckets..."

같은 계정 안에서는 이 둘이 합집합으로 평가됩니다 — 사용자 쪽 정책이 허용하지 않아도 리소스 쪽 정책이 허용하면 접근됩니다.

"If an action is allowed by an identity-based policy, a resource-based policy, or both, then AWS allows the action. An explicit deny in either of these policies overrides the allow."

다만 이 규칙은 같은 계정 안에서 요청할 때만 성립합니다. 다른 계정에서 오는 요청은 요청자 쪽 identity-based 정책과 리소스 쪽 resource-based 정책 양쪽 모두가 허용해야 통과합니다 — 한쪽만 허용하면 실패합니다.

역할은 항상 임시 자격증명이다

IAM 역할은 사용자와 겉모습은 비슷하지만 근본적으로 다릅니다.

"Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session."

역할을 assume(맡는다)할 때마다 AWS STS(Security Token Service — 임시 보안 자격증명을 발급하는 서비스)가 새 임시 자격증명을 발급하고, 이 자격증명은 세션이 끝나면 자동으로 만료됩니다. 별도로 값을 지정하지 않으면 세션은 1시간 동안 유효하고, 역할 설정에 따라 최대 12시간까지 늘릴 수 있습니다. 다만 역할로 다른 역할을 다시 assume하는 역할 체이닝(role chaining) 은 예외입니다.

"Role chaining limits your AWS Management Console, AWS CLI or AWS API role session to a maximum of one hour. It applies regardless of the maximum session duration configured for individual roles."

AD의 서비스 계정이 보통 고정 암호를 갖고 그 암호가 유출되기 전까지 계속 유효한 것과 달리, 역할은 애초에 훔칠 만한 장기 자격증명 자체가 없습니다 — 있는 건 곧 만료되는 세션 토큰뿐입니다.

변경 사항이 즉시 반영되지 않는다

IAM은 전 세계 여러 서버에 데이터를 복제하는 방식으로 동작합니다.

"IAM, like many other AWS services, is eventually consistent... If a request to change some data is successful, the change is committed and safely stored. However, the change must be replicated across IAM, which can take some time... We recommend that you do not include such IAM changes in the critical, high-availability code paths of your application."

사용자·그룹·역할·정책을 만들거나 바꾼 직후 바로 다른 API(Application Programming Interface — 프로그램끼리 주고받는 호출 인터페이스) 호출에서 그 변경이 반영 안 된 것처럼 보일 수 있습니다. AD 복제 지연과 비슷한 현상이지만, IAM 쪽은 배포 자동화 스크립트에서 "역할 만들기 → 곧바로 그 역할로 assume"처럼 실행하면 실패할 수 있다는 뜻이라, 자동화 스크립트에는 재시도나 약간의 대기를 넣어 두는 게 안전합니다.

시나리오 — 배치 스크립트에 액세스 키를 박아 넣으려는 시도

매일 새벽 도는 배치 스크립트가 S3 버킷에서 파일을 읽어야 하는 상황을 가정합니다.

순진한 시도 는 "일단 되게 하자"는 생각으로 IAM 사용자를 하나 만들고 액세스 키를 발급해서, 그 배치 스크립트가 도는 EC2 인스턴스 안 설정 파일에 키 값을 그대로 적어 두는 것입니다. 당장은 동작합니다.

문제 는 이 액세스 키가 장기 자격증명이라 만료되지 않고, 인스턴스 이미지·설정 파일·백업 어딘가에 남아 유출될 경로가 여러 갈래로 늘어난다는 데 있습니다. 도입부 시나리오의 사고가 정확히 이 경로로 났습니다 — 코드 저장소에 실수로 올라간 액세스 키가 그대로 살아 있었던 것입니다. 키를 순환(rotate)하려면 수동으로 새 키를 만들고 옛 키를 지우는 절차가 필요하고, 그 사이 어딘가에서 빠뜨리기 쉽습니다.

정답 은 액세스 키를 아예 만들지 않고, EC2 인스턴스에 그 S3 버킷만 읽을 수 있는 IAM 역할을 연결하는 것입니다. 공식 문서가 권장하는 방식이 정확히 이것입니다.

"When you're building on an AWS compute service, such as Amazon EC2 or Lambda, AWS delivers the temporary credentials of an IAM role to that compute resource. Applications written using an AWS SDK will discover and use these temporary credentials to access AWS resources, and there is no need to distribute long lived credentials for an IAM user to your workloads running on AWS."

스크립트 코드는 한 줄도 안 바뀝니다 — AWS SDK(Software Development Kit — AWS 서비스를 코드에서 호출하도록 언어별로 제공되는 라이브러리 묶음)가 인스턴스에 연결된 역할의 임시 자격증명을 자동으로 찾아 씁니다. 코드 저장소에 올라갈 만한 값 자체가 애초에 없습니다.

액세스 키가 필요한 경우가 아예 없는 건 아닙니다 — AWS 밖에서 도는 워크로드, IAM Identity Center를 지원하지 않는 서드파티 도구처럼 역할을 못 쓰는 특정 상황에는 여전히 장기 액세스 키를 씁니다. 다만 "AWS 안에서 도는 워크로드라면 역할이 먼저" 라는 순서를 뒤집으면 안 됩니다.

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "사람 계정도 전부 IAM 사용자로 만들면 되지"

IAM User Guide는 이 페이지 맨 앞에 경고 문구를 따로 두고 있습니다.

"IAM best practices recommend that you require human users to use federation with an identity provider to access AWS using temporary credentials instead of using IAM users with long-term credentials. We recommend that you only use IAM users for specific use cases not supported by federated users."

AD에서 사람 계정을 도메인 계정으로 만드는 건 기본값이지만, IAM에서는 사람 계정에 장기 자격증명(암호·액세스 키)을 발급하는 것 자체가 예외적인 상황을 위한 것입니다. 사람은 IAM Identity Center 같은 페더레이션으로 접근하고, IAM 사용자는 역할을 지원하지 않는 워드프레스 플러그인, IAM Identity Center를 지원하지 않는 서드파티 도구, 비상 접근용 계정처럼 정말 대안이 없는 몇몇 상황에만 남겨 두는 게 권장 방향입니다.

오해 2. "그룹에 역할·정책을 걸어두면 그룹 자체가 리소스에 접근할 수 있다"

AD 그룹을 ACL의 주체(Principal)로 직접 넣던 감각을 그대로 옮기면 걸리는 지점입니다. IAM 그룹은 정책을 묶어 사용자에게 나눠 주는 편의 기능일 뿐, 그 자체가 인증되는 신원이 아닙니다.

"You cannot identify a user group as a Principal in a policy (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities."

그리고 AD의 중첩 그룹(그룹 안에 그룹)도 IAM에는 없습니다.

"User groups can't be nested; they can contain only users, not other IAM groups."

그룹은 정책을 묶어서 여러 사용자에게 한 번에 적용하는 용도로만 씁니다 — 그룹 계층을 여러 단으로 설계하는 AD의 관행을 그대로 옮기려 하면 첫 단계에서 막힙니다.

오해 3. "정책에 거부(Deny) 문이 없으면 기본적으로 다 허용된다"

거꾸로입니다. IAM은 기본값이 거부입니다(3장) — 사용자·역할을 새로 만들면 아무 권한이 없고, 어딘가에 명시적 허용이 있어야만 접근이 됩니다. AD의 일부 ACL 편집 화면처럼 "특별히 막지 않으면 통과"라는 감각으로 접근하면, 오히려 "왜 아무것도 안 되지"라는 반대 방향의 문제로 먼저 부딪히게 됩니다.

오해 4. "루트 계정 = 도메인 관리자니까 평소 업무에도 쓰면 편하다"

공식 문서가 가장 강하게 권고하는 부분입니다.

"We strongly recommend that you don't use the root user for your everyday tasks and that you follow the root user best practices for your AWS account."

루트 사용자가 필요한 작업은 계정 설정 변경, 계정 종료, 그리고 이런 경우처럼 정말 그것만 루트여야 하는 작업으로 한정됩니다.

"Restore IAM user permissions. If the only IAM administrator accidentally revokes their own permissions, you can sign in as the root user to edit policies and restore those permissions."

즉 루트 계정은 "제일 센 계정이라 평소에 쓰기 편한 계정"이 아니라, 다른 모든 권한이 꼬였을 때 되돌리는 최후의 안전망에 가깝습니다. 평소 업무는 IAM Identity Center로 만든 관리자 계정으로 하고, 루트 자격증명은 MFA(Multi-factor authentication — 암호 외에 별도 기기·앱이 생성하는 일회성 코드를 추가로 요구하는 인증 방식)를 걸어 안전하게 보관해 두는 것이 정석입니다.

시나리오 — 신규 팀원 계정을 기존 관리자 계정 복제로 만든다

팀에 새 개발자가 들어올 때마다, 기존 시니어 개발자의 IAM 사용자에 붙은 정책 목록을 그대로 복사해서 새 사용자에게 붙이는 방식으로 계정을 만들어 왔다고 가정합니다. AD에서 "이 사람과 같은 부서니까 같은 그룹에 넣으면 되지"라고 하던 것과 비슷한 감각입니다.

문제는 시니어 개발자의 정책이 그 사람이 몇 년간 맡았던 여러 프로젝트의 권한이 누적된 결과라는 데 있습니다. 신규 팀원은 당장 프로젝트 하나만 맡는데도, 복제된 정책 때문에 손댈 필요조차 없는 다른 프로젝트의 리소스까지 접근할 수 있게 됩니다. 최소 권한 원칙(3장)과 정반대 방향으로 계정이 늘어나는 셈입니다.

당장 취할 조치는 새 계정을 만들 때 기존 계정을 복제하지 않고, 그 사람이 맡은 업무에 필요한 권한만 골라 customer managed policy로 새로 구성하는 것입니다. 이미 복제로 만들어진 기존 계정들은 한 번에 다 고치려 하지 말고, IAM이 제공하는 마지막 접근 정보(last accessed information — 어떤 정책·자격증명이 최근에 실제로 쓰였는지 보여주는 기능)로 안 쓰는 권한부터 순서대로 줄여 가는 편이 현실적입니다.

5. 비용·운영 감각

온프레미스에서는 AD 서버 자체가 라이선스·하드웨어 비용이 드는 인프라입니다. IAM은 이 감각과 다릅니다.

IAM·IAM Identity Center·STS는 그 자체로 무료입니다.

"AWS Identity and Access Management (IAM), AWS IAM Identity Center and AWS Security Token Service (AWS STS) are features of your AWS account offered at no additional charge. You are charged only when you access other AWS services using your IAM users or AWS STS temporary security credentials."

사용자·그룹·역할·정책을 몇 개를 만들든, 역할을 얼마나 자주 assume하든 그 자체로는 과금되지 않습니다. 과금은 그 신원으로 실제로 건드리는 다른 AWS 서비스(EC2·S3 등) 쪽에서 발생합니다. 다만 예외가 하나 있습니다.

"IAM Access Analyzer external access analysis is offered at no additional charge. However, you will incur charges for unused access analysis and customer policy checks."

접근 권한을 점검해 주는 IAM Access Analyzer의 기본 외부 접근 분석은 무료지만, 안 쓰는 권한을 찾아 주는 분석과 정책 검사 일부 기능은 별도 과금 대상입니다.

진짜 비용은 IAM 사용료가 아니라 설계에 들이는 시간과, 잘못 설계했을 때의 사고 비용입니다. 온프레미스에서 장비 구매 비용을 아끼려는 감각을 IAM에 그대로 옮기면, "일단 넓게 권한을 주고 나중에 정리하자"는 쪽으로 흐르기 쉽습니다. 하지만 IAM 자체가 무료이기 때문에, 처음부터 최소 권한으로 세밀하게 나눠 관리해도 추가 비용이 들지 않습니다 — 아낄 이유가 없는데 아끼다가, 3장 시나리오·4장 오해처럼 권한이 새 나가는 사고로 이어지는 쪽이 훨씬 비쌉니다.

6. 관련 개념

IAM Identity Center(구 AWS SSO) — 여러 AWS 계정에 대한 사람 사용자의 접근을 한곳에서 관리하는 서비스. 외부 신원 공급자와 연동하거나 자체적으로 사용자를 만들 수 있다. 사람 계정은 IAM 사용자보다 이쪽이 우선 권장된다(4장).
AWS Organizations의 SCP(Service Control Policy) — 여러 AWS 계정을 조직으로 묶어 계정 전체에 적용되는 권한 상한을 거는 기능. 개별 계정의 IAM 정책과는 별개 층위에서 작동한다.
AWS Directory Service(Managed Microsoft AD) — 실제 Active Directory 서버 자체를 AWS 위에서 관리형으로 운영하는 서비스. IAM과 헷갈리기 쉽지만 완전히 다른 서비스다(2장).
AWS KMS(Key Management Service) — 암호화 키를 만들고 관리하는 서비스. 그 키를 누가 쓸 수 있는지는 IAM 정책으로 통제한다.
AWS CloudTrail — 어느 신원이 언제 무엇을 했는지 기록하는 감사 로그 서비스. IAM으로 권한을 걸어 두는 것과, 그 권한이 실제로 어떻게 쓰였는지 사후에 추적하는 것은 별개 문제다.

7. 한눈에 정리

항목	확인할 것
새 사용자·역할	기본적으로 아무 권한이 없다 — 정책을 붙여야 뭔가 할 수 있다
정책 평가	기본값은 거부, 명시적 거부가 명시적 허용을 항상 이긴다
identity-based / resource-based	같은 계정 안에서는 합집합, 계정을 넘으면 양쪽 모두 허용해야 한다
IAM 역할	항상 임시 자격증명, 기본 세션 1시간 · 역할 체이닝은 1시간 상한
사람 계정	IAM 사용자보다 IAM Identity Center(페더레이션) 권장
워크로드(EC2·Lambda 등)	장기 액세스 키 대신 역할의 임시 자격증명을 쓴다
그룹	정책만 묶어서 부여, Principal로 지정 불가, 중첩 불가
루트 사용자	일상 업무 금지, 계정 설정·복구처럼 특정 작업 전용, MFA 필수
변경 반영	즉시 전파되지 않는다(eventually consistent) — 자동화 스크립트에 재시도를 둔다
과금	IAM·STS·Identity Center 자체는 무료, Access Analyzer 일부 기능만 유료

이어서 보면 좋은 글

리눅스 프로세스·서비스 관리 Top 10 — systemctl·kill, 변수만 바꿔 그대로 쓰는 명령

와우패널 — Fri, 4 Sep 2026 08:13:38 +0900

"서비스가 응답이 없다"는 보고를 받으면 손이 먼저 systemctl restart로 가기 쉽습니다. 그런데 재시작은 지금 상태를 지워버리는 명령입니다 — 왜 멈췄는지 볼 기회도 같이 사라집니다. 이 글은 재시작하기 전에 먼저 확인하는 명령 10개를 모았습니다 — 서비스가 systemd 레벨에서 살아있는지, 그 서비스의 진짜 프로세스는 뭘 하고 있는지, 그리고 신호를 보낼 때 어떤 순서로 보내야 하는지. 변수 하나만 바꿔 그대로 복붙하면 됩니다.

"nginx가 응답이 없다"는 보고가 들어왔습니다. 바로 재시작 버튼을 누르고 싶지만, 그러면 지금 멈춰 있는 이유(설정 오류인지, 메모리 부족으로 죽어가는 중인지, 자식 프로세스가 좀비로 쌓인 건지)를 확인할 기회가 같이 날아갑니다. 재시작 전에 지금 상태를 읽는 순서가 필요합니다.

이 글 쓰는 법 — 변수 한 줄만 바꾸세요

변수가 있는 명령은 아래 형태입니다.

SVC=crond # ← 이 줄의 값만 여러분이 볼 서비스(유닛)로 바꾸세요
systemctl status "$SVC" --no-pager -l # ← 상태 한눈에

첫 줄의 오른쪽 값만 바꾸고 그대로 붙여넣으면 됩니다. 출력은 전부 실제 서버(Rocky Linux 9, systemd 252)에서 실행해 그대로 옮겼습니다 — 여러분 서버의 PID·가동 시간·유닛 목록은 다르게 나오는 게 정상입니다. 호스트명은 이 블로그의 도메인으로 바꿔 표기했습니다.

측정 환경: Rocky Linux 9.7(커널 5.14.0-611.47.1.el9_7) · systemd 252(252-55.el9_7.8.rocky.0.1, systemctl) · procps-ng 3.3.17(ps·kill) · psmisc 23.4(pstree). 앞 7개는 전부 sudo 없이 됩니다. 뒤 3개(kill 계열)는 자신이 소유한 프로세스에만 root 없이 동작합니다 — 다른 사용자 소유 프로세스에 신호를 보내려면 root가 필요합니다(이유는 8번에서 다룹니다). 서비스를 재시작하는 명령은 이 글의 범위 밖입니다 — 맨 끝 경고 박스를 보세요.

1. 서비스가 살아있나 — systemd 레벨

1) 상태 한눈에

언제 쓰나 — 보고를 받으면 가장 먼저 치는 명령입니다. 살아있는지, 언제부터인지, 최근에 뭘 남겼는지가 한 화면에 나옵니다.

SVC=crond # ← 볼 서비스(유닛) 이름
systemctl status "$SVC" --no-pager -l # ← --no-pager: 페이저 없이 한 번에 출력, -l(--full): 긴 줄 안 자름

$ SVC=crond
$ systemctl status "$SVC" --no-pager -l
● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-07-13 19:41:35 KST; 1 month 11 days ago
   Main PID: 1474 (crond)
      Tasks: 1 (limit: 98164)
     Memory: 2.1M (peak: 11.7M)
        CPU: 1min 13.213s

 8월 25 00:01:02 wowpanel.tistory.com CROND[3244130]: (root) CMD (run-parts /etc/cron.hourly)
 8월 25 00:01:02 wowpanel.tistory.com anacron[3244141]: Anacron started on 2026-08-25
 8월 25 00:01:02 wowpanel.tistory.com anacron[3244141]: Normal exit (0 jobs run)
 8월 25 00:01:02 wowpanel.tistory.com run-parts[3244143]: (/etc/cron.hourly) finished 0anacron
 8월 25 00:01:02 wowpanel.tistory.com CROND[3244129]: (root) CMDEND (run-parts /etc/cron.hourly)

주의 — 읽기 전용. Active: 줄이 판단의 시작점입니다 — active (running) 말고도 activating(뜨는 중)·deactivating(내려가는 중)·failed(비정상 종료)가 있습니다. -l(--full)을 안 붙이면 긴 줄이 ...로 잘려 맨 아래 로그 메시지 끝이 안 보일 수 있습니다. 그 로그 몇 줄은 journalctl -u를 요약해 보여주는 것일 뿐이라, 더 앞뒤로 보려면 별도로 journalctl -u "$SVC"가 필요합니다. 원래 출력에는 이 아래 CGroup: 항목으로 실제 하위 프로세스 트리도 붙지만, 트리 연결선에 이 블로그 스킨에서 깨질 수 있는 상자 문자가 쓰여 여기서는 뺐습니다 — 그 트리는 5)번 pstree로 대신 봅니다.

2) 스크립트에서 바로 쓰는 짧은 답

언제 쓰나 — 사람이 읽는 게 아니라, 배포 스크립트나 헬스체크에서 "떠 있나/자동시작인가"만 참·거짓으로 필요할 때.

SVC=crond # ← 볼 서비스
systemctl is-active "$SVC"; echo "rc=$?" # ← 떠 있는지만 참·거짓으로, 종료 코드로 판단
systemctl is-enabled "$SVC"; echo "rc=$?" # ← 재부팅해도 자동 시작인지, 역시 종료 코드로 판단

$ SVC=crond
$ systemctl is-active "$SVC"; echo "rc=$?"
active
rc=0
$ systemctl is-enabled "$SVC"; echo "rc=$?"
enabled
rc=0

없는 서비스 이름으로 시도하면 어떻게 되는지도 같이 확인해 둡니다.

$ systemctl is-active nonexist-svc-xyz; echo "rc=$?"
inactive
rc=3

주의 — 읽기 전용. man systemctl의 is-active 설명:

"Check whether any of the specified units are active (i.e. running). Returns an exit code 0 if at least one is active, or non-zero otherwise. Unless --quiet is specified, this will also print the current unit state to standard output."

출력 문자열이 아니라 종료 코드($?)로 분기하세요 — 사람이 읽는 상태 이름은 systemd 버전마다 늘어날 수 있지만(예: activating), 스크립트가 기대하는 건 "떠 있다/아니다" 둘뿐입니다. 없는 유닛 이름을 주면 active가 아니라 inactive로 나온다는 점도 유의하세요 — 오타로 유닛 이름을 잘못 줘도 "죽어있다"처럼 보이는 결과가 나옵니다.

3) 이 서버에서 지금 실패 중인 서비스 전체 훑기

언제 쓰나 — 특정 서비스 하나가 아니라 "이 서버 전체에서 지금 뭐가 고장 나 있나"를 한 번에 볼 때. 장애 조사를 시작할 때 가장 먼저 던져볼 만한 질문입니다.

systemctl list-units --type=service --state=failed --no-pager # ← 실패 상태 서비스만 걸러서

$ systemctl list-units --type=service --state=failed --no-pager
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

주의 — 읽기 전용. --type=service로 서비스 유닛만, --state=failed로 그중 실패한 것만 걸러서 --no-pager로 한 번에 봅니다. 이 서버는 지금 실패한 서비스가 0개입니다 — 이게 정상 상태입니다. 뭔가 있다면 UNIT·LOAD·ACTIVE·SUB·DESCRIPTION 다섯 열로 한 줄씩 나오고, ACTIVE 열에 failed가 찍힙니다. 재현하려고 일부러 서비스를 죽이지는 않았습니다 — 이 명령의 값어치는 지금 이 서버처럼 평소에 정기적으로 0개인지 확인해 두는 것에 있습니다. 그래야 나중에 한 줄이라도 뜨는 순간 바로 눈에 띕니다.

4) 실제 적용 중인 설정 확인

언제 쓰나 — "이 서비스가 재시작할 때 자동으로 다시 뜨게 설정돼 있나", "누가 override 파일로 옵션을 덮어썼나"를 확인할 때. 파일 경로를 직접 찾아 cat하지 않아도 됩니다.

SVC=crond # ← 볼 서비스
systemctl cat "$SVC" --no-pager # ← 원본 유닛 파일 + override(있다면)를 이어붙여 --no-pager로 한 번에

$ SVC=crond
$ systemctl cat "$SVC" --no-pager
# /usr/lib/systemd/system/crond.service
[Unit]
Description=Command Scheduler
After=auditd.service nss-user-lookup.target systemd-user-sessions.service time-sync.target ypbind.service autofs.service

[Service]
EnvironmentFile=/etc/sysconfig/crond
ExecStart=/usr/sbin/crond -n $CRONDARGS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=30s

[Install]
WantedBy=multi-user.target

주의 — 읽기 전용. 맨 위 주석 줄(# /usr/lib/systemd/system/crond.service)이 실제로 읽은 파일 경로입니다. /etc/systemd/system/에 override(systemctl edit로 만든 .d/override.conf)가 있으면 이 명령이 그것까지 순서대로 이어 붙여서 보여줍니다 — 그래서 "설정 파일을 봤는데 내가 기대한 옵션이 없다"는 혼란은 대부분 override 파일을 못 찾아서 생깁니다. Restart=on-failure·RestartSec=30s처럼 이 서비스가 죽으면 자동으로 재시작하는지, 몇 초 뒤인지도 여기서 바로 보입니다 — 뒤 8~10번에서 신호를 보낼 때 이 값을 미리 알고 있어야 "내가 죽였는데 왜 다시 떠 있지"에 안 놀랍니다.

2. PID 레벨로 내려가기

systemd가 "이 서비스는 살아있다"고 말해도, 그 서비스가 실제로 어떤 프로세스들로 이뤄져 있는지는 다른 질문입니다. 여기서부터는 systemd 단위가 아니라 PID를 기준으로 확인합니다 — 그 PID는 1)의 systemctl status 출력에 있는 Main PID 줄에서 그대로 읽거나, 아래 5)처럼 따로 조회할 수 있습니다.

5) 이 서비스가 실제로 거느린 자식 프로세스들

언제 쓰나 — 서비스 하나가 자식 프로세스를 여러 개 거느리는 구조(워커, 커넥션 핸들러)일 때, "지금 몇 개나 떠 있고 어떻게 연결돼 있나"를 트리로 봅니다. 1)에서 본 것처럼 systemctl status의 Main PID 줄을 그대로 써도 되고, 서비스명만 알고 있어 그 값만 스크립트로 뽑고 싶으면 아래처럼 따로 조회할 수도 있습니다 — 여기서는 자식 프로세스가 여럿 딸린 모습을 보여주려고 (자식이 없는) 크론 대신 sshd로 바꿔 시연합니다.

SVC=sshd # ← 이번엔 sshd로 확인합니다
systemctl show "$SVC" -p MainPID # ← -p MainPID: 수십 개 속성 중 Main PID 값 하나만 뽑아서

$ SVC=sshd
$ systemctl show "$SVC" -p MainPID
MainPID=1459

PID=1459 # ← 방금 확인한 sshd의 Main PID
pstree -p "$PID" # ← -p: 트리에 PID 숫자까지 같이 표시

$ PID=1459
$ pstree -p "$PID"
sshd(1459)-+-sshd(2734881)---sshd(2734885)---bash(2734886)
           `-sshd(3266055)---sshd(3266058)---bash(3266059)---pstree(3266088)

주의 — 읽기 전용. sshd(1459)가 리스너 본체, 그 아래로 뻗은 두 줄이 지금 연결된 세션 두 개입니다 — 세션마다 인증 전용 자식(sshd)이 한 번 더 갈라지고, 그 아래 로그인 셸(bash)이 붙습니다. 이 서버에 지금 몇 명이 접속해 있는지, 방금 실행한 pstree 자신도 그 트리 끝에 잡힌 걸 볼 수 있습니다. 서비스가 워커 프로세스를 여러 개 fork하는 구조(예: nginx)라면, Main PID 하나 아래 워커 수만큼 가지가 뻗은 모습으로 나타나 "지금 워커가 몇 개 떠 있나"를 바로 셀 수 있습니다.

6) PID 하나의 상태 코드 읽기

언제 쓰나 — 특정 PID가 살아는 있는데 응답이 없을 때. "실행 중"과 "멈춰 있음"은 같은 게 아닙니다 — STAT 열이 그 차이를 말해줍니다.

PID=1474 # ← 확인할 PID (여기선 crond)
ps -o pid,ppid,stat,etime,cmd -p "$PID" # ← -o로 볼 열을 pid·ppid·상태·경과시간·명령줄로 지정, -p로 이 PID만

$ PID=1474
$ ps -o pid,ppid,stat,etime,cmd -p "$PID"
    PID    PPID STAT     ELAPSED CMD
   1474       1 Ss   42-05:31:02 /usr/sbin/crond -n

주의 — 읽기 전용. ELAPSED는 man ps의 etime 설명대로 [[DD-]hh:]mm:ss 형식입니다 — 이 서버의 42-05:31:02는 42일 5시간 31분입니다. STAT의 Ss는 man ps의 PROCESS STATE CODES에서:

"S interruptible sleep (waiting for an event to complete)"

"s is a session leader"

즉 "지금 할 일이 없어 이벤트를 기다리는 중이고, 이 세션의 우두머리"라는 뜻입니다 — crond는 원래 대부분의 시간을 이 상태로 보냅니다. 여기서 진짜 문제 신호는 D(uninterruptible sleep, 보통 디스크 I/O 대기 — Ctrl+C도 안 먹고 kill도 안 먹는 상태)와 Z(defunct/zombie, 종료됐는데 부모가 아직 수거를 안 한 상태)입니다. 이 서버 전체 프로세스의 STAT 분포를 한 번 세어 보면:

$ ps -eo stat --no-headers | sort | uniq -c | sort -rn | head
     90 I<
     86 S
     84 Sl
     69 Ss
     49 Ssl
     35 I
      2 SN
      1 Ss+
      1 SNsl
      1 SNs

D도 Z도 없는 게 정상입니다 — 있다면 그 줄의 PID로 바로 6)을 다시 돌려 어떤 프로세스인지 확인하세요.

7) 열어 둔 파일·소켓 개수로 누수 의심하기

언제 쓰나 — 메모리는 안정적인데 시간이 지날수록 서비스가 느려지거나 "Too many open files"가 뜰 때. 파일 디스크립터(FD) 누수를 의심하는 첫 확인입니다.

PID=3602303 # ← 확인할 PID (자신이 소유한 프로세스여야 root 없이 됩니다)
ls /proc/"$PID"/fd | wc -l # ← fd 디렉터리 안 항목(열린 파일 하나당 하나)을 세어 개수만

$ PID=3602303
$ ls /proc/"$PID"/fd | wc -l
14
$ ps -o pid,ppid,stat,etime,cmd -p "$PID"
    PID    PPID STAT     ELAPSED CMD
3602303 3602278 Ssl   8-08:29:11 java -XX:+UseG1GC -XX:MaxRAMPercentage=60.0 -Djava.security.egd=file:/dev/./urandom -jar /app/app.jar

주의 — 읽기 전용. man proc의 /proc/pid/fd/ 설명대로:

"This is a subdirectory containing one entry for each file which the process has open, named by its file descriptor, and which is a symbolic link to the actual file. Thus, 0 is standard input, 1 standard output, 2 standard error, and so on."

숫자 하나가 열린 파일 하나(또는 소켓·파이프 하나)입니다. 한 번 본 숫자는 기준값일 뿐 그 자체로는 의미가 없습니다 — 몇 시간 간격으로 다시 재서 계속 늘어나기만 하는지가 누수의 신호입니다(연결마다 여닫는 게 정상이라면 오르내려야 합니다). 남의 프로세스는 권한 오류로 막힙니다 — 이 서버의 sshd(root 소유, PID 1459)로 시도하면:

$ ls /proc/1459/fd
ls: cannot open directory '/proc/1459/fd': 허가 거부

정확한 한도 대비 사용량을 보려면 cat /proc/"$PID"/limits에서 Max open files 줄과 비교하세요 — 이 글은 개수를 세는 것까지만 다룹니다.

3. 신호 보내기 — 안전한 순서

여기서부터는 프로세스에 실제로 무언가를 하는 명령입니다. 순서가 중요합니다 — 존재 확인(8) → 정상 종료 요청(9) → 그래도 안 죽을 때만 강제 종료(10). 8)은 신호를 안 보내는 조회라 아무 PID로나 시도해도 안전하지만, 실제로 신호를 보내는 9)·10)의 데모는 이 계정(wowpanel)이 직접 띄운 프로세스로만 했습니다 — 운영 서비스를 대상으로 재현하지 않았습니다.

8) 신호 없이 존재만 확인

언제 쓰나 — 실제로 신호를 보내기 전에, 그 PID가 지금도 그 프로세스가 맞는지 먼저 확인합니다. PID는 재사용되므로, 한참 전에 적어둔 PID로 바로 kill부터 날리면 그사이 종료되고 새로 뜬 다른 프로세스를 잘못 건드릴 수 있습니다.

PID=3267299 # ← 확인할 PID
kill -0 "$PID"; echo "rc=$?" # ← -0: 신호는 안 보내고 존재·권한만 확인, 결과는 종료 코드로

$ PID=3267299
$ kill -0 "$PID"; echo "rc=$?"
rc=0

주의 — man 2 kill의 설명대로:

"If sig is 0, then no signal is sent, but existence and permission checks are still performed; this can be used to check for the existence of a process ID or process group ID that the caller is permitted to signal."

신호 0은 실제로 아무것도 보내지 않습니다 — 종료 코드만으로 존재 여부를 판단합니다(0이면 있음, 1이면 없거나 권한 없음). 신호를 보낼 권한 자체는 같은 man 페이지가 이어서 정의합니다:

"For a process to have permission to send a signal, it must either be privileged (under Linux: have the CAP_KILL capability in the user namespace of the target process), or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the target process. In the case of SIGCONT, it suffices when the sending and receiving processes belong to the same session. (Historically, the rules were different; see NOTES.)"

소유자가 같아야 root 없이 신호가 통합니다(마지막 문장의 SIGCONT 예외는 이 글이 다루는 TERM·KILL·신호 0에는 해당하지 않습니다). — 그래서 앞서 이 글 쓰는 법에서 "뒤 3개는 자신이 소유한 프로세스에만" 된다고 한 것입니다. root 소유 프로세스(crond, PID 1474)로 시도하면:

$ kill -0 1474; echo "rc=$?"
bash: kill: (1474) - 명령을 허용하지 않음
rc=1

종료 코드는 존재하지 않을 때와 똑같이 1입니다 — 코드만으로는 "없다"와 "권한이 없다"를 구분하지 못하고, 메시지 문구(그런 프로세스가 없음 vs 명령을 허용하지 않음)로만 구분됩니다. 프로세스가 아예 없으면 이렇게 나옵니다.

$ kill -0 999999999; echo "rc=$?"
bash: kill: (999999999) - 그런 프로세스가 없음
rc=1

9) 정상 종료 요청 — TERM, 기본값

언제 쓰나 — 실제로 멈추게 해야 할 때 항상 이걸 먼저 시도합니다. kill $PID라고만 쳐도 이 신호가 나갑니다.

PID=3267299 # ← 위 8)에서 존재를 확인한 그 PID
kill -15 "$PID" # ← -15(TERM): 정상 종료를 요청, 신호 번호를 안 주면 이게 기본값
sleep 1 # ← 프로세스가 스스로 정리하고 종료할 시간을 잠깐 줌
kill -0 "$PID"; echo "rc=$?" # ← 신호 0으로 다시 존재 확인

$ PID=3267299
$ kill -15 "$PID"
$ sleep 1
$ kill -0 "$PID"; echo "rc=$?"
bash: kill: (3267299) - 그런 프로세스가 없음
rc=1

주의 — TERM은 프로세스가 직접 처리할 기회를 주는 신호입니다. 정상적으로 짜인 서비스는 이 신호를 받으면 열린 연결을 정리하고, 진행 중인 트랜잭션을 마무리한 뒤 스스로 종료합니다 — 위 결과처럼 신호를 보내자마자 사라진 게 정상입니다. kill에 번호를 안 주면 기본값이 바로 이 15번(TERM)입니다.

10) 그래도 안 죽으면 — KILL, 최후 수단

언제 쓰나 — TERM을 보냈는데도 프로세스가 계속 살아있을 때. 응답이 없는 프로세스, 또는 의도적으로(혹은 버그로) TERM을 무시하도록 짜인 프로세스에 마지막으로 씁니다.

TERM을 일부러 무시하도록 만든 프로세스로 차이를 보입니다.

kill -15 3267503 # ← TERM을 무시하도록 만든 프로세스에 정상 종료 요청
sleep 1 # ← 종료 처리 시간을 잠깐 줌
kill -0 3267503; echo "still-alive-rc=$?" # ← 신호 0으로 살아있는지 재확인

$ kill -15 3267503
$ sleep 1
$ kill -0 3267503; echo "still-alive-rc=$?"
still-alive-rc=0

TERM이 무시됐습니다(rc=0, 아직 살아있음). 이제 KILL을 보냅니다.

PID=3267503 # ← 위에서 TERM이 안 먹힌 그 PID
kill -9 "$PID" # ← -9(KILL): 커널이 즉시 강제 종료, 프로세스가 막을 수 없음
sleep 1 # ← 종료 확인 전 잠깐 대기
kill -0 "$PID" 2>&1; echo "gone-rc=$?" # ← 신호 0으로 최종 확인, 2>&1로 에러 메시지도 같이 받음

$ PID=3267503
$ kill -9 "$PID"
$ sleep 1
$ kill -0 "$PID" 2>&1; echo "gone-rc=$?"
bash: kill: (3267503) - 그런 프로세스가 없음
gone-rc=1

주의 — man 7 signal이 이 차이를 명시합니다:

"The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored."

TERM(15)은 프로세스가 무시하거나 자체 처리 루틴으로 가로챌 수 있지만, KILL(9)은 커널이 프로세스에게 물어보지 않고 직접 정리합니다 — 그래서 항상 통합니다. 대신 프로세스가 자기 정리(임시 파일 삭제, 버퍼 flush, 연결 정상 종료)를 할 기회 자체가 없습니다 — 그래서 9)의 TERM을 먼저 시도하고, 정말 안 될 때만 여기로 옵니다. 그리고 한 가지 더 — 부모 프로세스를 KILL해도 그 자식까지 같이 사라지는 게 아닙니다. 위 데모의 부모(3267503)가 거느리던 자식(sleep 3600, PID 3267525)은 부모가 죽은 뒤에도 그대로 남아 있었고, PPID만 1(init)로 바뀌어 있었습니다 — 고아가 되어 다른 프로세스가 됩니다. 서비스 전체를 확실히 내리려면 개별 PID가 아니라 systemd 단위로 제어해야 하는 이유가 여기 있습니다(맨 끝 경고 박스 참고).

4. 전체 치트시트

한 번에 모아 둡니다. 변수(SVC·PID)만 바꿔서 그대로 쓰세요.

# ── 서비스가 살아있나 (systemd 레벨, root 불필요)
SVC=crond; systemctl status "$SVC" --no-pager -l # ← 상태 한눈에
SVC=crond; systemctl is-active "$SVC"; systemctl is-enabled "$SVC" # ← 스크립트용 짧은 답
systemctl list-units --type=service --state=failed --no-pager # ← 실패 서비스 전체 훑기
SVC=crond; systemctl cat "$SVC" --no-pager # ← 실제 적용 중인 설정(override 포함)

# ── PID 레벨로 내려가기 (root 불필요)
PID=1459; pstree -p "$PID" # ← 자식 프로세스 트리
PID=1474; ps -o pid,ppid,stat,etime,cmd -p "$PID" # ← STAT 코드 확인
PID=1234; ls /proc/"$PID"/fd | wc -l # ← 열어 둔 파일 개수 (자신 소유만)

# ── 신호 보내기 (자신이 소유한 프로세스만 root 없이 됨, 순서대로)
PID=1234; kill -0 "$PID"; echo "rc=$?" # ← ① 존재만 확인, 신호는 안 감
PID=1234; kill -15 "$PID" # ← ② 정상 종료 요청 (기본값, 항상 먼저)
PID=1234; kill -9 "$PID" # ← ③ 그래도 안 죽을 때만 최후 수단

마무리

"응답이 없다"는 보고 하나로 바로 재시작하지 않는 게 이 10개의 요점입니다. 1~4는 systemd가 보는 상태(살아있나, 왜 그렇게 설정됐나), 5~7은 그 서비스가 실제로 어떤 프로세스로 이뤄져 있는지, 8~10은 멈추게 해야 할 때 어떤 신호를 어떤 순서로 보내는지입니다. TERM으로 안 죽는 프로세스를 만났다면 그 자체가 정보입니다 — 정상 종료 루틴이 없거나, 어딘가에 멈춰 있다는 뜻이니 KILL로 넘어가기 전에 왜 그런지 한 번은 의심해 보세요.

참고

man systemctl · man ps · man proc · man 2 kill · man 7 signal · man pstree

서비스를 실제로 재시작하려면 — 위 10개로 "언제부터, 왜 멈춰 보이는지"까지 확인했다면, 다음은 이 세 줄입니다.

SVC=서비스이름 # ← 재시작할 유닛
systemctl list-dependencies --reverse "$SVC" # ← ① 먼저: 나에게 의존하는 서비스 확인 (root 불필요)
sudo systemctl restart "$SVC" # ← ② 정지 후 재시작 (start+stop이 한 번에)
sudo systemctl status "$SVC" --no-pager -l # ← ③ 다시 뜬 뒤 상태 확인
sudo journalctl -u "$SVC" -n 20 --no-pager # ← ④ 재시작 전후 로그

②~④는 root 권한이 필요해서 이 글에서는 실행·검증하지 않았습니다 — 이 프로젝트는 검증 안 된 출력을 싣지 않는 걸 원칙으로 하고, 운영 서버에서 sudo도 쓰지 않습니다. ①은 이 글의 다른 명령과 마찬가지로 읽기 전용이라 sudo가 필요 없습니다. 실행하기 전에 반드시:

①에서 나온 목록이 비어 있지 않다면, 재시작이 그 서비스들에도 순간적인 단절을 일으킬 수 있다는 뜻입니다.
restart는 stop 다음 start를 순서대로 하는 것뿐이라, 그사이 짧게라도 다운타임이 생깁니다. 무중단이 필요하면 reload(설정만 다시 읽는, 서비스가 지원할 때만 되는 명령)가 되는지 먼저 확인하세요.
4)번(systemctl cat)에서 본 Restart=·RestartSec= 값을 미리 알아두세요 — 재시작 정책에 따라 여러분이 아무것도 안 해도 이미 자동으로 재시작이 걸려 있었을 수 있습니다.
재시작 후에는 반드시 1)번(systemctl status)으로 다시 active (running)이 됐는지, 3)번(실패 서비스 훑기)으로 다른 서비스까지 덩달아 실패하지 않았는지 확인하세요.

이어서 보면 좋은 글

Route 53 — DNS 서버 하나가 하던 일을 세 갈래로 나눈 이유

와우패널 — Thu, 3 Sep 2026 16:16:27 +0900

온프레미스에서는 로드밸런서 어플라이언스(F5 BIG-IP·Citrix ADC 같은 장비) 한 대에 VIP(Virtual IP — 클라이언트에게 노출하는 대표 IP 주소, 실제 서버들은 이 뒤에 숨어 있다) 하나를 만들고, 그 안에서 4계층 포트 기반 분산과 7계층 URL·호스트 기반 라우팅을 같은 화면에서 같이 설정했습니다. 헬스 모니터도, 퍼시스턴스(persistence — 같은 클라이언트를 같은 서버로 계속 보내는 세션 고정)도 한 장비 설정 안에 다 있었습니다. AWS는 이 하나의 어플라이언스를 세 갈래로 쪼갭니다 — 7계층에서 동작하는 ALB(Application Load Balancer), 4계층에서 동작하는 NLB(Network Load Balancer), 그리고 두 계층에 걸쳐 있었지만 지금은 구세대로 분류된 CLB(Classic Load Balancer)입니다. 이름은 전부 "로드밸런서"지만 계층이 다르면 그 계층에서만 볼 수 있는 정보와 그 계층에만 있는 기능이 갈리고, 이 구분을 놓치면 온프레미스에서 당연했던 기능(고정 IP, 순수 TCP 릴레이)이 선택한 타입에는 아예 없다는 걸 나중에야 알게 됩니다.

새벽 배포 창. 무중단 배포라고 확신하고 오토 스케일링 그룹의 인스턴스를 하나씩 순서대로 내리고 새 버전으로 교체하는 롤링 배포를 돌린다. 배포가 끝난 뒤 모니터링을 보니 배포가 진행되던 구간마다 일부 요청이 500 에러로 실패한 흔적이 남아 있다. 애플리케이션 로그에는 에러가 없고, 헬스체크도 배포 내내 정상이었다. 재현을 시도해도 매번 같은 요청에서 나는 게 아니라 간헐적이라 원인을 좁히기 어렵다.

이 글은 실제 AWS 콘솔 화면이나 CLI 실행 결과를 캡처하지 않습니다. ALB·NLB·CLB가 지원하는 프로토콜, 기본 라우팅 알고리즘, 헬스체크·등록 해제 동작, 교차 영역 분산 기본값, 과금 구조처럼 이 글이 다루는 사실 하나하나는 전부 AWS 공식 문서(Elastic Load Balancing 사용 설명서·기능 비교·가격 페이지)를 직접 열어 원문을 대조한 것입니다. 정확한 가격은 리전과 시점에 따라 바뀌므로, 구체적인 숫자를 쓸 때는 "이 글 작성 시점(2026-08-27) 기준"이라고 밝힙니다.

1. ALB·NLB·CLB가 정확히 뭔가

ALB는 요청의 내용(URL 경로, 호스트 헤더 등)을 보고 어디로 보낼지 판단합니다.

"An Application Load Balancer functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model."

OSI(Open Systems Interconnection — 네트워크 통신을 7개 계층으로 나눠 설명하는 참조 모델) 7계층, 즉 애플리케이션 계층에서 동작한다는 뜻입니다. HTTP 요청 자체를 열어 보고 판단하므로, 경로별·도메인별로 다른 서버 그룹에 보내는 것 같은 콘텐츠 기반 라우팅이 ALB의 핵심입니다.

NLB는 요청 내용을 보지 않고 IP·포트 단위로만 분산합니다.

"A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second."

4계층, 즉 전송 계층에서 동작합니다. 애플리케이션 내용을 들여다보지 않는 대신 초저지연·고처리량에 특화돼 있고, 순수 TCP·UDP 트래픽을 그대로 중계하는 데 적합합니다.

CLB는 AWS가 가장 먼저 내놓은 로드밸런서로, 지금은 새 워크로드에 쓰라고 권장하지 않는 구세대입니다.

"Classic Load Balancers are the previous generation of load balancers from Elastic Load Balancing. We recommend that you migrate to a current generation load balancer."

CLB 소개 문서 자체에는 계층을 명시한 문장이 없지만, AWS의 공식 기능 비교표는 CLB를 "Layer 4/7"로 분류합니다 — 4계층 포트 기반 분산과 기본적인 7계층 프로토콜(HTTP/HTTPS) 지원을 한 컴포넌트 안에서 같이 제공했던 구조입니다.

세 타입 모두 공통으로 갖는 성격이 하나 있습니다 — 클라이언트 입장에서는 뒤에 서버가 몇 대든 상관없이 하나의 접점으로 보인다는 것입니다.

"A load balancer serves as the single point of contact for clients."

온프레미스에서 VIP 하나 뒤에 여러 대의 리얼 서버를 숨겼던 것과 같은 감각입니다. AWS의 공식 기능 비교표도 ALB·NLB의 접근 방식을 "Reachable via: VIP"로 표기합니다.

2. 온프레미스 대응표

같은 물건이 아니라 "가장 가까운 것"입니다. 온프레미스 어플라이언스 한 대가 하던 일이 AWS에서는 계층별로 나뉘어 있다는 것부터 잡아야 3장·4장이 자연스럽게 이어집니다.

온프레미스	AWS	같은 점	다른 점
L7 스위치의 콘텐츠 기반 라우팅(URL·호스트별 분기)	ALB	경로·호스트 헤더로 다른 서버 그룹에 분배	고정 IP를 직접 지원하지 않음(4장)
L4 스위치의 순수 IP·포트 기반 분산	NLB	요청 내용을 안 보고 초저지연 처리	UDP까지 처리(3장), 정적·탄력적 IP 지원(4장)
VIP + 헬스 모니터	헬스체크(공통)	비정상 대상을 자동으로 제외	대상이 전부 비정상이면 오히려 전체에 흘려보냄(3장, fail-open)
퍼시스턴스(세션 고정)	스티키 세션(공통 개념, ALB·CLB만 지원)	같은 클라이언트를 같은 서버로 유지	쿠키 기반, 소스 IP 기반이 아님(3장)
통합형 구형 어플라이언스	CLB	4·7계층 기능을 한 컴포넌트가 같이 제공	신규 워크로드 비권장, 순수 TCP/SSL 리스너는 ALB엔 아예 없음(4장)

3. 실무에서 반드시 알아야 하는 것

타입마다 지원하는 프로토콜 자체가 다르다

AWS 공식 기능 비교표에서 이 글이 다루는 세 타입(ALB·NLB·CLB)만 추리면 다음과 같습니다(원문 표에는 게이트웨이 로드밸런서 열도 있지만 이 글의 범위 밖이라 뺐습니다. 원문이 "-"로 비워 둔 칸은 그 항목 자체가 해당 타입에 없다는 뜻이라 괄호로 풀어 썼습니다).

항목	ALB	NLB	CLB
계층	Layer 7	Layer 4	Layer 4/7
타겟 타입	IP, Instance, Lambda	IP, Instance, Application Load Balancer	(원문 "-", 개별 타겟 타입 구분 없음)
프로토콜 리스너	HTTP, HTTPS, gRPC	TCP, UDP, TLS	TCP, SSL/TLS, HTTP, HTTPS
접근 방식	VIP	VIP	(원문 "-", VIP 개념 표기 없음)

ALB에는 순수 TCP·SSL 리스너 자체가 없습니다. HTTP/HTTPS/gRPC만 받습니다. 반대로 NLB·CLB는 TCP·TLS(SSL) 리스너를 지원합니다 — 이 차이가 4장 오해로 이어집니다.

스티키 세션은 쿠키 기반이다 — 소스 IP 퍼시스턴스와는 다르다

온프레미스 L4/L7 스위치의 퍼시스턴스는 대부분 클라이언트의 소스 IP를 기준으로 같은 서버에 고정합니다. ALB의 스티키 세션은 다른 방식으로 동작합니다.

"To use sticky sessions, the client must support cookies."

ALB는 자체 쿠키(AWSALB)를 만들어 클라이언트에게 내려주고, 이후 요청에 그 쿠키가 실려 오는지로 같은 대상을 판단합니다 — 소스 IP는 보지 않습니다. 이 쿠키의 유효 기간은 7일로 고정돼 있고 바꿀 수 없습니다. 쿠키를 저장하지 않는 클라이언트(일부 API 클라이언트, 헬스체크 스크립트 등)라면 스티키 세션을 켜 놔도 매번 다른 대상으로 흩어집니다 — 온프레미스에서 소스 IP 기반으로 문제없이 되던 구성이 AWS로 오면서 그대로 안 되는 지점입니다.

ALB의 라우팅은 규칙(rule) 우선순위로 결정된다

"The rules that you define for a listener determine how the load balancer routes requests to its registered targets. Each rule consists of a priority, one or more actions, and one or more conditions. When the conditions for a rule are met, then its actions are performed."

경로·호스트 헤더 조건을 우선순위 순서로 평가해 맞는 규칙의 액션(어느 타겟 그룹으로 보낼지)을 실행하는 구조입니다. 타겟 그룹 안에서 실제로 어떤 대상에게 요청을 줄지는 별도의 라우팅 알고리즘이 결정합니다.

"The default routing algorithm is round robin; alternatively, you can specify the least outstanding requests routing algorithm."

기본값은 라운드 로빈이고, 요청마다 처리 부하가 들쭉날쭉하면 least outstanding requests(처리 중인 요청이 가장 적은 대상 우선)나 weighted random으로 바꿀 수 있습니다.

시나리오 — L7 스위치로 하던 경로 기반 라우팅을 그대로 옮기려는 시도

온프레미스에서 /api로 오는 요청은 API 서버군으로, /static으로 오는 요청은 정적 파일 서버군으로 나누는 규칙을 L7 스위치 하나에 걸어 뒀다고 합시다. AWS로 옮기면서 "로드밸런서니까 아무거나 하나 만들어서 리스너만 두 개 걸면 되겠지" 하고 CLB를 골라 HTTP 리스너 하나 아래 API 서버와 정적 파일 서버를 전부 등록하면, 요청은 경로와 무관하게 등록된 인스턴스 전체에 그냥 순서대로 분산됩니다. CLB에는 애초에 "규칙"이라는 개념 자체가 없어서, 경로를 보고 갈라 보내는 동작을 설정할 방법이 없기 때문입니다.

정답은 ALB를 쓰고, API 서버용 타겟 그룹과 정적 파일 서버용 타겟 그룹을 각각 만든 뒤, 리스너에 /api/* 경로 조건은 API 타겟 그룹으로, 나머지는 기본 규칙으로 정적 파일 타겟 그룹으로 보내는 규칙을 우선순위대로 추가하는 것입니다. 온프레미스에서 L7 스위치 화면 하나에 있던 설정이 AWS에서는 "타입 선택(ALB)"과 "리스너 규칙"이라는 두 단계로 나뉘었을 뿐, 할 수 있는 일 자체는 그대로 옮겨집니다.

헬스체크가 전부 실패해도 로드밸런서는 트래픽을 끊지 않는다

"However, if the load balancer doesn't have enough healthy targets, it automatically sends traffic to all registered targets (fail open)."

정상 대상이 하나도 없으면 오히려 등록된 대상 전체에 트래픽을 흘려보냅니다(fail-open). 온프레미스 헬스 모니터가 "전부 비정상이면 서비스 자체를 내린다"는 감각으로 설정돼 있었다면 반대 방향의 동작이라 헷갈리기 쉽습니다 — 이건 아무것도 못 받는 것보다 에러라도 낫다는 설계 판단입니다.

인스턴스를 등록 해제해도 곧바로 끊기지 않는다

"Elastic Load Balancing stops sending requests to targets that are deregistering. By default, Elastic Load Balancing waits 300 seconds before completing the deregistration process, which can help in-flight requests to the target to complete."

등록 해제를 시작해도 기본 300초 동안은 진행 중이던 요청(in-flight request)이 끝날 시간을 줍니다. 다만 이 유예 시간이 끝나기 전에 대상 쪽에서 먼저 연결을 끊으면 얘기가 달라집니다.

"If a deregistering target terminates the connection before the deregistration delay elapses, the client receives a 500-level error response."

이 동작은 4장에서 도입부 시나리오를 그대로 풀어 줍니다.

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "로드밸런서니까 당연히 고정 IP 하나로 붙일 수 있겠지"

온프레미스에서는 로드밸런서에 할당한 VIP가 곧 고정 IP였으니, AWS 로드밸런서도 당연히 고정 IP를 준다고 생각하기 쉽습니다. 하지만 ALB 소개 문서 어디에도 고정 IP 관련 언급이 없는 반면, NLB는 명시적으로 지원합니다.

"Elastic Load Balancing creates a network interface for each Availability Zone you enable. Each load balancer node in the Availability Zone uses this network interface to get a static IP address. When you create an Internet-facing load balancer, you can optionally associate one Elastic IP address per subnet."

파트너사가 방화벽 화이트리스트에 등록할 로드밸런서의 고정 IP를 요구하는데 이미 ALB로 서비스를 구성해 놨다면, ALB 자체를 고정 IP로 바꿀 방법은 없습니다. 이럴 때 흔히 쓰는 구성은 앞단에 NLB를 하나 더 두고 그 뒤에 기존 ALB를 타겟으로 등록하는 것입니다 — 공식 기능 비교표가 NLB의 타겟 타입에 "Application Load Balancer"를 포함시켜 놓은 것도 이 구성을 염두에 둔 것입니다. 경로 기반 라우팅은 ALB가 그대로 처리하고, 파트너사에 알려 줄 고정 IP는 NLB가 제공하는 식입니다.

오해 2. "헬스체크만 정상이면 아무 때나 인스턴스를 내려도 안전하다"

도입부 시나리오가 바로 이 오해에서 시작합니다. 오토 스케일링 그룹이 롤링 배포 중 인스턴스를 종료할 때, 헬스체크가 정상이었다는 것과 그 인스턴스가 지금 처리 중인 요청이 없다는 것은 별개입니다. 등록 해제를 시작하면 기본 300초의 유예 시간(3장)이 있지만, 이 시간이 지나기 전에 인스턴스 자체가 연결을 끊어 버리면(운영체제 종료, 프로세스 강제 종료 등) 그 순간 처리 중이던 요청은 500 에러로 클라이언트에 돌아갑니다. 배포 스크립트가 등록 해제 신호를 보내자마자 바로 인스턴스를 종료하도록 짜여 있었다면, 헬스체크 로그는 배포 내내 정상으로 보이면서도 간헐적인 500 에러가 나는 정확히 이 패턴이 재현됩니다.

조치는 배포 절차에 등록 해제 유예 시간만큼(또는 그보다 조금 더) 기다리는 단계를 넣는 것입니다. 오토 스케일링의 인스턴스 새로 고침(instance refresh) 기능을 쓴다면 종료 대기(termination wait) 시간을 등록 해제 지연과 맞추고, 직접 스크립트로 내린다면 타겟을 등록 해제한 뒤 그 유예 시간만큼 대기했다가 인스턴스를 종료하도록 순서를 바꿉니다. 당장 급하게 배포를 멈출 수 없는 상황이라면 유예 시간을 늘려 여유를 벌 수도 있지만, 근본적으로는 "등록 해제 신호"와 "인스턴스 종료" 사이에 시간차를 두는 게 맞는 방향입니다.

오해 3. "교차 영역 분산 기본값은 셋 다 똑같겠지"

가용 영역(AZ, Availability Zone — 물리적으로 분리된 데이터센터 단위)을 여러 개 걸쳐 두면 로드밸런서가 알아서 전체 대상에 고르게 나눠 줄 거라 생각하기 쉽지만, 교차 영역 로드밸런싱(cross-zone load balancing) 기본값은 타입마다 다릅니다. ALB는 끌 수조차 없이 항상 켜져 있습니다.

"With Application Load Balancers, cross-zone load balancing is always turned on at the load balancer level, and cannot be turned off."

반면 NLB는 기본값이 꺼짐입니다.

"By default, each load balancer node distributes traffic across the registered targets in its Availability Zone only. If you enable cross-zone load balancing, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones."

NLB를 쓰면서 한쪽 가용 영역에만 인스턴스를 몰아 뒀다면, 다른 가용 영역의 로드밸런서 노드로 들어온 요청은 그 영역 안의 대상만 찾다가 아예 처리할 곳을 못 찾을 수 있습니다. 가용 영역마다 대상 수를 고르게 맞추거나, 필요하다면 교차 영역 로드밸런싱을 직접 켜야 합니다.

오해 4. "CLB에서 ALB로 옮기면 기능이 다 그대로 되겠지"

ALB가 더 최신이니 CLB의 상위 호환일 거라 생각하기 쉽지만, 3장 비교표대로 ALB에는 순수 TCP·SSL 리스너 자체가 없습니다. MQTT 브로커나 커스텀 바이너리 프로토콜을 쓰는 서버, 또는 HTTP가 아닌 TCP 기반 서비스를 CLB 뒤에 두고 있었다면, 그 워크로드는 ALB로 옮길 수 없습니다 — 이런 경우는 NLB가 맞는 대상입니다. "로드밸런서 교체"를 계획할 때는 지금 CLB가 실제로 어떤 프로토콜의 리스너를 쓰고 있는지부터 확인해야, HTTP/HTTPS 워크로드는 ALB로, 순수 TCP/UDP 워크로드는 NLB로 나눠서 옮길 수 있습니다.

5. 비용·운영 감각

온프레미스에서는 로드밸런서 어플라이언스를 한 번 사서 설치하면 그 뒤로는 감가상각만 신경 쓰면 되는 자산(CAPEX, Capital Expenditure — 처음에 사들여 감가상각하는 자본 지출)이었습니다. ELB(Elastic Load Balancing)는 다릅니다 — 만들어 둔 시간과 처리한 트래픽 양에 따라 계속 청구됩니다.

ALB의 과금은 시간당 기본 요금에 LCU(Load Balancer Capacity Unit)라는 처리량 단위 요금을 더하는 구조입니다. 이 글 작성 시점(2026-08-27) us-east-1(버지니아 북부) 리전 기준으로, 시간당 기본 요금은 $0.0225, LCU당 요금은 $0.008입니다. LCU는 한 가지 지표가 아니라 네 가지 차원 중 가장 높은 사용량을 기준으로 계산됩니다.

"An LCU measures the dimensions on which the Application Load Balancer processes your traffic (averaged over an hour)."

"You are charged only on the dimension with the highest usage."

네 차원은 새 연결 수(초당), 활성 연결 수(분당), 처리 바이트(GB), 그리고 규칙 평가 수(rule evaluations)입니다. 온프레미스 감각으로는 낯선 항목이 마지막 것입니다 — 리스너 규칙을 얼마나 복잡하게 짜 두느냐(조건 개수, 트래픽당 평가되는 규칙 수)도 비용에 영향을 줍니다.

NLB도 같은 구조로 과금됩니다.

"An NLCU measures the dimensions on which the Network Load Balancer processes your traffic (averaged over an hour)."

다만 NLCU당 요금은 $0.006이고, 규칙 평가 차원이 없는 대신 새 연결·활성 연결·처리 바이트 세 차원만 봅니다 — NLB는 콘텐츠를 보고 규칙을 평가하지 않으니 애초에 이 차원이 존재하지 않는 것입니다.

트래픽이 없어도 시간당 요금은 그대로 쌓입니다. 온프레미스 어플라이언스처럼 "안 쓰는 시간엔 그냥 놀고 있는 것"이 아니라, 로드밸런서를 만들어 둔 시간만큼 최소 요금이 계속 붙습니다. 개발·테스트 환경에 만들어 둔 로드밸런서를 쓰지 않는 기간에도 지우지 않으면, 실제 사용량과 무관하게 요금이 쌓입니다. 정확한 숫자는 리전과 시점에 따라 바뀌므로, 실제 도입 전에는 반드시 공식 가격 페이지에서 해당 리전 기준 최신 값을 확인해야 합니다.

6. 관련 개념

타겟 그룹 — 로드밸런서가 실제로 트래픽을 보내는 대상(인스턴스·IP·Lambda) 묶음. 헬스체크·라우팅 알고리즘·등록 해제 지연 같은 설정이 로드밸런서가 아니라 이 단위에 붙는다.
Auto Scaling — 인스턴스를 자동으로 늘리고 줄이는 서비스. 늘어난 인스턴스는 타겟 그룹에 자동 등록되고, 줄어들 때는 등록 해제 절차(4장)를 거친다.
Route 53 — 도메인 이름을 로드밸런서로 연결하는 DNS 서비스.
AWS Certificate Manager — HTTPS 리스너에 붙일 SSL/TLS 인증서를 발급·관리하는 서비스.
AWS WAF — ALB 앞단에서 요청 내용을 검사해 악성 트래픽을 걸러내는 서비스.
VPC·보안 그룹 — 로드밸런서가 어느 서브넷에 놓이고 어떤 트래픽을 받을 수 있는지를 결정하는 네트워크 경계.

7. 한눈에 정리

항목	확인할 것
계층	ALB=7계층(내용 기반 라우팅), NLB=4계층(IP·포트만), CLB=4/7계층(구세대, 신규 비권장)
프로토콜	ALB는 HTTP/HTTPS/gRPC만, NLB는 TCP/UDP/TLS, CLB는 TCP/SSL/HTTP/HTTPS
고정 IP	NLB만 정적·탄력적 IP 지원, ALB엔 없음 — 필요하면 앞단에 NLB를 둔다
라우팅	ALB는 리스너 규칙(우선순위·조건)으로 분기, CLB엔 이 개념 자체가 없음
기본 알고리즘	라운드 로빈(least outstanding requests·weighted random으로 변경 가능)
헬스체크 실패	대상 전부 비정상이면 오히려 전체에 흘려보냄(fail-open)
등록 해제	기본 300초 유예, 그 전에 연결이 끊기면 클라이언트에 500 에러
교차 영역 분산	ALB는 항상 켜짐(끌 수 없음), NLB는 기본 꺼짐
비용	시간당 기본 요금 + LCU/NLCU(차원 중 최댓값 기준), 트래픽 없어도 시간당 요금은 그대로
CLB→ALB 이전	순수 TCP/SSL 워크로드는 ALB로 못 옮김 — NLB가 맞는 대상

이어서 보면 좋은 글

리눅스 압축·백업 Top 10 — tar·rsync·scp, 변수만 바꿔 그대로 쓰는 명령

와우패널 — Thu, 3 Sep 2026 08:12:43 +0900

배포 전에, 장애 조치 전에, "혹시 몰라서" 백업 하나는 남겨 두고 시작합니다. 그런데 막상 치려면 tar 옵션이 czf였는지 xzf였는지 헷갈리고, rsync는 옵션 하나 잘못 쓰면 있던 파일을 지워 버릴 수도 있다는 얘기를 들어서 손이 안 갑니다. 이 글은 압축을 만들고, 옮기기 전에 확인하고, 옮긴 뒤 검증까지 이어지는 명령 10개를 모았습니다. 변수 하나만 바꿔 그대로 복붙하면 됩니다.

배포 스크립트를 돌리기 직전입니다. 실패하면 되돌릴 수 있어야 하니 지금 상태를 먼저 압축해 남기고, 다른 서버로도 하나 복사해 두려 합니다. tar로 뭘 묶어야 하는지, rsync와 scp 중 뭘 써야 하는지, 그리고 무엇보다 — 백업이라고 만들어 놓은 게 실제로 쓸 수 있는 파일인지 어떻게 확인하는지가 필요합니다.

이 글 쓰는 법 — 변수 한 줄만 바꾸세요

변수가 있는 명령은 아래 형태입니다.

SRC=app # ← 이 줄의 값만 여러분이 압축할 디렉터리로 바꾸세요
tar -czf app-backup.tar.gz "$SRC" # ← 압축 아카이브 생성

첫 줄의 오른쪽 값만 바꾸고 그대로 붙여넣으면 됩니다. 출력은 전부 실제 서버(Rocky Linux 9)에서 실행해 그대로 옮겼습니다 — 여러분 서버의 파일 크기·경로·타임스탬프는 다르게 나오는 게 정상입니다. 데모는 홈 디렉터리 밑에 app/이라는 예제 디렉터리(로그 파일 2개 + 설정 파일 1개, 약 400K)를 직접 만들어 놓고 그 안에서 진행했습니다 — 여러분은 SRC=에 실제 백업 대상 경로를 넣으면 됩니다. scp·rsync 예시는 같은 서버 안 두 디렉터리 사이 복사로 검증했습니다 — 진짜 원격 서버로 보낼 때 목적지를 어떻게 바꾸는지는 각 항목 주의에 적었습니다. 아래 10개는 전부 sudo 없이, 이 계정이 쓰기 권한을 가진 경로 안에서만 동작합니다.

측정 환경: Rocky Linux 9.7(커널 5.14.0-611.47.1.el9_7) · GNU tar 1.34 · rsync 3.2.5(프로토콜 31) · OpenSSH 8.7p1(scp) · gzip 1.12 · GNU coreutils 8.32(du·find·ls).

1. 아카이브 만들기·확인 — tar

1) 디렉터리를 압축 아카이브로 묶기

언제 쓰나 — 배포·설정 변경 전에 지금 상태를 통째로 하나의 파일로 남길 때. 가장 먼저 쓰게 되는 명령입니다.

SRC=app # ← 압축할 디렉터리
tar -czf app-backup.tar.gz "$SRC" # ← c=생성, z=gzip 압축, f=파일명 지정
ls -lh app-backup.tar.gz

$ SRC=app
$ tar -czf app-backup.tar.gz "$SRC"
$ ls -lh app-backup.tar.gz
-rw-r--r--. 1 wowpanel wowpanel 6.0K  8월 25 16:07 app-backup.tar.gz

주의 — 원본은 그대로 남습니다(압축이지 이동이 아닙니다). -czf의 순서는 관례일 뿐 실제로는 옵션 나열이라 -zcf도 되지만, f 다음에는 항상 파일명이 와야 합니다 — app과 아카이브 이름의 순서를 바꿔 쓰면 app이라는 이름의 아카이브가 생기고 진짜 대상이 뒤로 밀립니다. 상대 경로로 압축했으므로("$SRC"가 app) 압축을 풀면 항상 app/ 아래에 풀립니다 — 절대경로(/home/사용자/app)로 압축하면 풀 때도 그 절대경로 그대로 생성되어 다른 계정에서 되돌리기 번거로워집니다.

2) 압축 풀지 않고 내용만 미리 보기

언제 쓰나 — 남이 만들어 둔 백업이거나, 오래전에 만든 걸 열기 전에 "이 안에 뭐가 들었는지"부터 확인할 때.

ARCHIVE=app-backup.tar.gz # ← 확인할 아카이브
tar -tzf "$ARCHIVE" # ← t=목록만, 실제로 풀지 않음

$ ARCHIVE=app-backup.tar.gz
$ tar -tzf "$ARCHIVE"
app/
app/logs/
app/logs/app.log
app/logs/access.log
app/config/
app/config/app.yml

주의 — 읽기 전용, 디스크에 아무것도 쓰지 않습니다. 대상 서버에 이 아카이브를 풀 자리가 있는지 확인하기 전에, 먼저 이걸로 "무엇이 얼마나 들었는지"부터 보는 게 순서입니다. 아카이브가 손상됐으면 이 명령에서 먼저 걸립니다 — 3)번 넘어가기 전에 습관적으로 한 번 돌려 보세요(10번에서 손상 사례를 직접 보여 드립니다).

3) 아카이브에서 파일 하나만 꺼내기

언제 쓰나 — 전체를 되돌릴 필요는 없고, 그때 그 설정 파일 하나만 다시 보고 싶을 때. 전체를 풀었다가 필요한 것만 골라내는 것보다 빠릅니다.

ARCHIVE=app-backup.tar.gz # ← 대상 아카이브
FILE=app/config/app.yml # ← 2)번 목록에서 확인한, 꺼낼 파일의 전체 경로
mkdir -p restore-test
tar -xzf "$ARCHIVE" -C restore-test "$FILE" # ← restore-test/ 밑에 그 파일 하나만 풀림
find restore-test -type f
cat restore-test/app/config/app.yml

$ ARCHIVE=app-backup.tar.gz
$ FILE=app/config/app.yml
$ mkdir -p restore-test
$ tar -xzf "$ARCHIVE" -C restore-test "$FILE"
$ find restore-test -type f
restore-test/app/config/app.yml
$ cat restore-test/app/config/app.yml
name: demo-app
port: 8080
env: production

주의 — FILE=은 2)번 tar -tzf 출력에 찍힌 경로를 글자 그대로 써야 합니다. app/config/app.yml을 config/app.yml처럼 앞부분을 빼고 쓰면 tar: config/app.yml: 아카이브에 없음이 납니다. -C restore-test는 "여기로 옮겨서 풀어라"는 뜻이라 원래 있던 자리를 건드리지 않습니다 — -C 없이 그냥 풀면 지금 디렉터리에 바로 풀리므로, 같은 이름의 파일이 이미 있으면 확인 없이 덮어씁니다.

4) 압축이 실제로 얼마나 줄었는지 확인

언제 쓰나 — 백업 용량 계획을 세울 때, "이 정도 압축이면 디스크가 며칠 버티나"를 가늠할 때.

SRC=app # ← 원본 디렉터리
ARCHIVE=app-backup.tar.gz # ← 압축 결과물
du -sh "$SRC" "$ARCHIVE"

$ SRC=app
$ ARCHIVE=app-backup.tar.gz
$ du -sh "$SRC" "$ARCHIVE"
400K app
8.0K app-backup.tar.gz

주의 — 읽기 전용. 1)번 ls -lh에서 본 아카이브 크기(6.0K)와 여기 du -sh 값(8.0K)이 다른 게 정상입니다 — ls는 파일의 실제 바이트 수를, du는 파일시스템 블록 단위로 올림한 디스크 사용량을 보여주기 때문입니다. 이 예제는 반복되는 텍스트 로그라 50배 가까이 줄었지만, 이미 압축된 파일(jpg·mp4·이미 gzip된 로그)은 다시 압축해도 거의 안 줄고 시간만 씁니다. 원본 디렉터리에 그런 파일이 섞여 있다면 du -sh 전후 차이가 기대만큼 안 나온다고 놀라지 마세요 — 텍스트 위주(로그·설정·소스)일 때 이 비율이 의미가 있습니다.

2. 옮기기 전에, 옮긴 뒤에 확인하기 — rsync·scp

5) rsync로 무엇이 바뀔지 먼저 보기

언제 쓰나 — 실제로 옮기기 전에, 뭐가 새로 추가되고 뭐가 덮어써질지 미리 확인할 때. 대상 디렉터리에 이미 파일이 있다면 건너뛰지 마세요.

SRC=app/ # ← 끝에 슬래시: app "안의 내용"을 보냄
DEST=backup-stage/app/ # ← 목적지
rsync -avn "$SRC" "$DEST" # ← n=dry-run, 실제로는 아무것도 안 씀

$ SRC=app/
$ DEST=backup-stage/app/
$ rsync -avn "$SRC" "$DEST"
sending incremental file list
created directory backup-stage/app
./
config/
config/app.yml
logs/
logs/access.log
logs/app.log

sent 196 bytes  received 75 bytes  542.00 bytes/sec
total size is 399,545  speedup is 1,474.34 (DRY RUN)

주의 — -n(--dry-run)이 걸려 있으면 실제로는 디렉터리조차 만들지 않습니다. 이 실행 직후 ls backup-stage를 해 보면 여전히 없습니다 — 출력에 찍힌 "created directory"는 "만들었다"가 아니라 "만들 것이다"라는 뜻이라, 처음 보면 착각하기 쉽습니다. SRC 끝의 슬래시(app/)는 "app 디렉터리 자체가 아니라 그 안의 내용을 보낸다"는 뜻입니다 — 슬래시를 빼고 app이라고만 쓰면 목적지 밑에 app이 한 겹 더 들어가 app/app/ 구조가 됩니다. 처음 옮기는 대상이라면 이 명령으로 목록부터 확인하고 6)으로 넘어가세요.

6) rsync로 실제 동기화하기

언제 쓰나 — 5)에서 확인한 내용이 맞으면 실제로 옮깁니다. 두 번째부터는 전체를 다시 보내지 않고 바뀐 것만 보냅니다(7번에서 확인).

SRC=app/ # ← 보낼 디렉터리(끝 슬래시 유지)
DEST=backup-stage/app/ # ← 목적지
rsync -av "$SRC" "$DEST" # ← a=권한·시각 등 보존, v=상세 출력

먼저 목적지 상위 디렉터리 없이 그대로 돌리면 이렇게 실패합니다 — rsync는 목적지의 마지막 한 단계만 새로 만들고, 그 위 경로까지 통째로 만들어 주지는 않습니다.

$ rsync -av app/ backup-stage/app/
sending incremental file list

rsync: [Receiver] mkdir "/home/wowpanel/blogdemo/backup-stage/app" failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(780) [Receiver=3.2.5]

상위 디렉터리를 먼저 만들어 주면 됩니다.

mkdir -p backup-stage # ← 목적지의 상위 디렉터리를 먼저 확보
SRC=app/
DEST=backup-stage/app/
rsync -av "$SRC" "$DEST"

$ mkdir -p backup-stage
$ SRC=app/
$ DEST=backup-stage/app/
$ rsync -av "$SRC" "$DEST"
sending incremental file list
created directory backup-stage/app
./
config/
config/app.yml
logs/
logs/access.log
logs/app.log

sent 399,957 bytes  received 131 bytes  800,176.00 bytes/sec
total size is 399,545  speedup is 1.00

주의 — mkdir -p backup-stage처럼 목적지의 상위 경로까지는 미리 만들어 둬야 합니다(마지막 한 단계인 app만 rsync가 알아서 만듭니다). 원격 서버로 보낼 때는 DEST 자리를 user@호스트:경로 형태로 바꾸면 됩니다.

DEST=wowpanel@백업서버:/home/wowpanel/backup-stage/app/ # ← 목적지를 원격 표기로

이 글의 예시는 검증 서버 안에서 로컬 경로끼리 확인했습니다. --delete 옵션은 이 명령에 없습니다 — 넣으면 목적지에는 있는데 원본에는 없는 파일을 지웁니다. 백업 스테이징처럼 "쌓아 두는" 용도라면 빼는 쪽이 안전하고, 목적지를 원본과 완전히 똑같이 맞추고 싶을 때만(그리고 그 위험을 알고) 붙이세요.

7) 다시 돌리면 바뀐 파일만 보낸다는 것 확인

언제 쓰나 — 같은 목적지에 반복해서 백업을 돌릴 때, rsync가 정말 전체를 다시 보내지 않는지 눈으로 확인합니다. scp로 매번 통째로 복사하는 것과 가장 크게 갈리는 지점입니다.

echo "app restarted at $(date +%H:%M:%S)" >> app/logs/app.log # ← 파일 하나만 변경
SRC=app/
DEST=backup-stage/app/
rsync -av "$SRC" "$DEST"

$ echo "app restarted at $(date +%H:%M:%S)" >> app/logs/app.log
$ SRC=app/
$ DEST=backup-stage/app/
$ rsync -av "$SRC" "$DEST"
sending incremental file list
logs/app.log

sent 1,958 bytes  received 37 bytes  3,990.00 bytes/sec
total size is 399,571  speedup is 200.29

주의 — 읽기 전용에 가깝습니다(목적지만 갱신, 원본은 그대로). 목록에 logs/app.log 딱 하나만 뜬 걸 보세요 — access.log·config/app.yml은 안 바뀌었으니 건드리지 않았습니다. 이게 rsync를 반복 백업에 쓰는 이유입니다: 매번 전체를 보내는 scp -r와 달리, 바뀐 부분만(그것도 파일 안에서 바뀐 블록만) 전송합니다. 다만 이 판단은 파일 크기와 수정 시각(mtime) 을 기준으로 하므로, 내용은 같은데 touch로 시각만 건드려도 "바뀐 파일"로 잡혀 다시 전송됩니다.

8) 파일 하나만 빠르게 복사 — scp

언제 쓰나 — 디렉터리 전체 동기화가 아니라, 파일 딱 하나를 지금 바로 다른 곳에 보낼 때. rsync보다 명령이 짧고 옵션을 고민할 게 적습니다.

FILE=app/config/app.yml # ← 보낼 파일
DEST=backup-stage/app.yml.bak # ← 목적지 경로(원격이면 user@호스트:경로)
scp "$FILE" "$DEST"
ls -la backup-stage/app.yml.bak

$ FILE=app/config/app.yml
$ DEST=backup-stage/app.yml.bak
$ scp "$FILE" "$DEST"
$ ls -la backup-stage/app.yml.bak
-rw-r--r--. 1 wowpanel wowpanel 42  8월 25 16:08 backup-stage/app.yml.bak

주의 — 성공하면 scp는 아무 말도 안 합니다(진행률 표시가 꺼진 비대화형 실행이라 조용합니다) — 위처럼 ls로 결과를 직접 확인하는 습관을 들이세요. 진짜 원격 서버로 보낼 때는 DEST를 user@호스트:경로 형태로 바꿉니다(포트가 22가 아니면 -P로 지정).

scp -P 2222 "$FILE" wowpanel@백업서버:~/backup/ # ← 원격으로 보낼 때 형태

디렉터리째 보내려면 -r을 붙여야 합니다 — 안 붙이면 cp: -r not specified; omitting directory 'app' 한 줄만 남기고 아무것도 안 보냅니다. 여러 파일을 반복해서 보낼 거라면 6)의 rsync가 낫습니다 — scp는 매번 전체를 새로 복사해서, 7)에서 본 것 같은 "바뀐 것만" 절약이 없습니다.

3. 백업이 맞는지 검증하기

9) 백업이 방금 실제로 만들어졌는지 확인

언제 쓰나 — 백업 스크립트가 크론으로 도는데, "어젯밤에 진짜 돌긴 했나"를 확인할 때. 스크립트가 에러 없이 끝났다는 것과 파일이 실제로 갱신됐다는 것은 다른 얘기입니다.

DIR=backup-stage # ← 백업이 쌓이는 디렉터리
find "$DIR" -type f -newermt "10 minutes ago" # ← 최근 10분 안에 바뀐 파일만

$ DIR=backup-stage
$ find "$DIR" -type f -newermt "10 minutes ago"
backup-stage/app/config/app.yml
backup-stage/app/logs/access.log
backup-stage/app/logs/app.log
backup-stage/app.yml.bak

주의 — 읽기 전용. -newermt(modification time 기준)는 "10 minutes ago"·"yesterday"·"2026-08-25 09:00:00"처럼 자연어와 정확한 시각을 둘 다 받습니다. 이 명령이 빈 결과를 내면 — 크론 로그에는 "성공"이라고 찍혀 있어도 — 실제로는 최근에 아무 파일도 안 바뀐 것이니 스크립트가 조용히 아무 일도 안 하고 끝났다는 신호입니다. 반대로 파일이 있다고 해서 내용까지 맞다는 보장은 없습니다 — 그건 10)에서 봅니다.

10) 압축 파일이 안 깨졌는지 무결성 확인

언제 쓰나 — 백업을 실제로 써야 하는 순간(복구할 때)이 오기 전에 미리 확인해 둘 때. 복구 시점에 처음 알면 이미 늦습니다.

ARCHIVE=app-backup.tar.gz
tar -tzf "$ARCHIVE" > /dev/null; echo "rc=$?" # ← 목록을 끝까지 읽어 보되 화면엔 안 찍음
gzip -t "$ARCHIVE"; echo "rc=$?" # ← gzip 계층만 별도로 검사

$ ARCHIVE=app-backup.tar.gz
$ tar -tzf "$ARCHIVE" > /dev/null; echo "rc=$?"
rc=0
$ gzip -t "$ARCHIVE"; echo "rc=$?"
rc=0

두 rc가 모두 0이면 정상입니다. 손상된 아카이브라면 이렇게 됩니다 — 앞부분만 잘려 나간 파일로 재현했습니다.

$ head -c 4000 app-backup.tar.gz > broken.tar.gz
$ tar -tzf broken.tar.gz > /dev/null; echo "rc=$?"
gzip: stdin: unexpected end of file
tar: 아카이브에 예기치 않은 파일 끝 문자
tar: Error is not recoverable: exiting now
rc=2

주의 — -tzf > /dev/null은 화면에 목록을 안 찍을 뿐, tar가 아카이브를 끝까지 실제로 읽습니다 — 그래서 중간이 잘린 파일도 걸러냅니다. ls -lh로 크기가 그럴듯해 보여도 전송 도중 끊긴 파일은 크기만 크고 내용이 없을 수 있습니다 — 크기 확인(4번)과 이 무결성 확인은 서로 다른 걸 봅니다, 크기가 맞아도 이 검사는 따로 돌리세요. rc=$?는 반드시 명령 바로 뒤에 세미콜론으로 붙여야 합니다 — 줄을 나눠 따로 echo "rc=$?"를 치면 그사이 프롬프트가 $?를 갈아치워 늘 0으로 보일 수 있습니다.

4. 전체 치트시트

한 번에 모아 둡니다. 변수(SRC·DEST·ARCHIVE·FILE·DIR)만 바꿔서 그대로 쓰세요.

# ── 아카이브 만들기·확인
SRC=app; tar -czf app-backup.tar.gz "$SRC" # ← 압축 만들기
ARCHIVE=app-backup.tar.gz; tar -tzf "$ARCHIVE" # ← 내용만 미리 보기
ARCHIVE=app-backup.tar.gz; FILE=app/config/app.yml; mkdir -p restore-test; tar -xzf "$ARCHIVE" -C restore-test "$FILE" # ← 파일 하나만 꺼내기
SRC=app; ARCHIVE=app-backup.tar.gz; du -sh "$SRC" "$ARCHIVE" # ← 압축률 확인

# ── 옮기기 전에, 옮긴 뒤에 확인하기
SRC=app/; DEST=backup-stage/app/; rsync -avn "$SRC" "$DEST" # ← 무엇이 바뀔지 미리 보기(dry-run)
mkdir -p backup-stage; SRC=app/; DEST=backup-stage/app/; rsync -av "$SRC" "$DEST" # ← 실제 동기화
SRC=app/; DEST=backup-stage/app/; rsync -av "$SRC" "$DEST" # ← 재실행 시 바뀐 것만 전송 확인
FILE=app/config/app.yml; DEST=backup-stage/app.yml.bak; scp "$FILE" "$DEST" # ← 파일 하나만 빠르게

# ── 백업이 맞는지 검증하기
DIR=backup-stage; find "$DIR" -type f -newermt "10 minutes ago" # ← 방금 만들어졌는지
ARCHIVE=app-backup.tar.gz; tar -tzf "$ARCHIVE" > /dev/null; echo "rc=$?" # ← 안 깨졌는지(tar 계층)
ARCHIVE=app-backup.tar.gz; gzip -t "$ARCHIVE"; echo "rc=$?" # ← 안 깨졌는지(gzip 계층)

소유권까지 그대로 보존해서 백업·복원하려면 — 위 10개는 전부 이 계정 권한만으로 됩니다. 그런데 여러 계정이 쓰던 파일을 백업했다가 그대로 복원하려면(소유자·그룹까지 원본과 똑같이) root 권한이 필요합니다.

# 백업할 때 소유권 정보까지 아카이브에 남기는 것 자체는 이미 기본 동작입니다.
# 문제는 "복원할 때 그 소유권을 실제로 적용"하는 단계입니다 — 아래는 root로 실행해야 하는 형태입니다.
ARCHIVE=app-backup.tar.gz
tar -xzpf "$ARCHIVE" --same-owner -C /restore/target # ← p=권한 보존, --same-owner=소유자·그룹까지 원본대로

man tar는 --same-owner를 이렇게 설명합니다.

"Try extracting files with the same ownership as exists in the archive (default for superuser)."

일반 계정으로 복원하면 파일들은 전부 실행한 계정 소유로 바뀝니다(권한 부족을 알아서 조용히 우회). rsync도 마찬가지입니다 — man rsync의 --owner 설명입니다.

"This option causes rsync to set the owner of the destination file to be the same as the source file, but only if the receiving rsync is being run as the super-user (see also the --super and --fake-super options)."

이 명령은 root 권한이 필요해서 이 글에서는 실행·검증하지 않았습니다 — 이 프로젝트는 검증 안 된 출력을 싣지 않는 걸 원칙으로 하고, 운영 서버에서 sudo도 쓰지 않습니다. 실행하기 전에 반드시:

복원 대상 경로(/restore/target)에 같은 이름의 파일이 이미 있는지 먼저 확인하세요 — --same-owner는 소유권만 바꿀 뿐 덮어쓰기 확인은 별도입니다.
되돌릴 방법(스냅샷, 혹은 복원 전 상태의 별도 백업)을 먼저 확보하세요.

마무리

순서대로 쓰면 됩니다 — 압축부터 만들고(1), 옮기기 전에 뭐가 들었는지 확인하고(2), 필요하면 파일 하나만 골라 꺼내고(3), 용량을 가늠하고(4). 다른 곳으로 옮길 땐 먼저 --dry-run으로 무엇이 바뀔지 보고(5), 실제로 옮기고(6), 반복 백업이라면 바뀐 것만 가는지 확인하고(7), 파일 하나뿐이면 scp로 짧게(8). 옮긴 뒤에는 방금 실제로 만들어졌는지(9)와 안 깨졌는지(10)를 확인해야 "백업했다"고 말할 수 있습니다 — 압축 파일이 존재한다는 것과 복원 가능하다는 것은 다른 얘기입니다.

이어서 보면 좋은 글

ALB·NLB·CLB — L4/L7 스위치 한 대가 세 갈래로 나뉜 이유

와우패널 — Wed, 2 Sep 2026 20:01:31 +0900

1. ALB·NLB·CLB가 정확히 뭔가

ALB는 요청의 내용(URL 경로, 호스트 헤더 등)을 보고 어디로 보낼지 판단합니다.

"An Application Load Balancer functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model."

NLB는 요청 내용을 보지 않고 IP·포트 단위로만 분산합니다.

"A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second."

CLB는 AWS가 가장 먼저 내놓은 로드밸런서로, 지금은 새 워크로드에 쓰라고 권장하지 않는 구세대입니다.

"Classic Load Balancers are the previous generation of load balancers from Elastic Load Balancing. We recommend that you migrate to a current generation load balancer."

세 타입 모두 공통으로 갖는 성격이 하나 있습니다 — 클라이언트 입장에서는 뒤에 서버가 몇 대든 상관없이 하나의 접점으로 보인다는 것입니다.

"A load balancer serves as the single point of contact for clients."

2. 온프레미스 대응표

온프레미스	AWS	같은 점	다른 점
L7 스위치의 콘텐츠 기반 라우팅(URL·호스트별 분기)	ALB	경로·호스트 헤더로 다른 서버 그룹에 분배	고정 IP를 직접 지원하지 않음(4장)
L4 스위치의 순수 IP·포트 기반 분산	NLB	요청 내용을 안 보고 초저지연 처리	UDP까지 처리(3장), 정적·탄력적 IP 지원(4장)
VIP + 헬스 모니터	헬스체크(공통)	비정상 대상을 자동으로 제외	대상이 전부 비정상이면 오히려 전체에 흘려보냄(3장, fail-open)
퍼시스턴스(세션 고정)	스티키 세션(공통 개념, ALB·CLB만 지원)	같은 클라이언트를 같은 서버로 유지	쿠키 기반, 소스 IP 기반이 아님(3장)
통합형 구형 어플라이언스	CLB	4·7계층 기능을 한 컴포넌트가 같이 제공	신규 워크로드 비권장, 순수 TCP/SSL 리스너는 ALB엔 아예 없음(4장)

3. 실무에서 반드시 알아야 하는 것

타입마다 지원하는 프로토콜 자체가 다르다

항목	ALB	NLB	CLB
계층	Layer 7	Layer 4	Layer 4/7
타겟 타입	IP, Instance, Lambda	IP, Instance, Application Load Balancer	(원문 "-", 개별 타겟 타입 구분 없음)
프로토콜 리스너	HTTP, HTTPS, gRPC	TCP, UDP, TLS	TCP, SSL/TLS, HTTP, HTTPS
접근 방식	VIP	VIP	(원문 "-", VIP 개념 표기 없음)

스티키 세션은 쿠키 기반이다 — 소스 IP 퍼시스턴스와는 다르다

"To use sticky sessions, the client must support cookies."

ALB의 라우팅은 규칙(rule) 우선순위로 결정된다

"The rules that you define for a listener determine how the load balancer routes requests to its registered targets. Each rule consists of a priority, one or more actions, and one or more conditions. When the conditions for a rule are met, then its actions are performed."

"The default routing algorithm is round robin; alternatively, you can specify the least outstanding requests routing algorithm."

시나리오 — L7 스위치로 하던 경로 기반 라우팅을 그대로 옮기려는 시도

헬스체크가 전부 실패해도 로드밸런서는 트래픽을 끊지 않는다

"However, if the load balancer doesn't have enough healthy targets, it automatically sends traffic to all registered targets (fail open)."

인스턴스를 등록 해제해도 곧바로 끊기지 않는다

"Elastic Load Balancing stops sending requests to targets that are deregistering. By default, Elastic Load Balancing waits 300 seconds before completing the deregistration process, which can help in-flight requests to the target to complete."

"If a deregistering target terminates the connection before the deregistration delay elapses, the client receives a 500-level error response."

이 동작은 4장에서 도입부 시나리오를 그대로 풀어 줍니다.

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "로드밸런서니까 당연히 고정 IP 하나로 붙일 수 있겠지"

"Elastic Load Balancing creates a network interface for each Availability Zone you enable. Each load balancer node in the Availability Zone uses this network interface to get a static IP address. When you create an Internet-facing load balancer, you can optionally associate one Elastic IP address per subnet."

오해 2. "헬스체크만 정상이면 아무 때나 인스턴스를 내려도 안전하다"

오해 3. "교차 영역 분산 기본값은 셋 다 똑같겠지"

"With Application Load Balancers, cross-zone load balancing is always turned on at the load balancer level, and cannot be turned off."

반면 NLB는 기본값이 꺼짐입니다.

"By default, each load balancer node distributes traffic across the registered targets in its Availability Zone only. If you enable cross-zone load balancing, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones."

오해 4. "CLB에서 ALB로 옮기면 기능이 다 그대로 되겠지"

5. 비용·운영 감각

"An LCU measures the dimensions on which the Application Load Balancer processes your traffic (averaged over an hour)."

"You are charged only on the dimension with the highest usage."

NLB도 같은 구조로 과금됩니다.

"An NLCU measures the dimensions on which the Network Load Balancer processes your traffic (averaged over an hour)."

6. 관련 개념

타겟 그룹 — 로드밸런서가 실제로 트래픽을 보내는 대상(인스턴스·IP·Lambda) 묶음. 헬스체크·라우팅 알고리즘·등록 해제 지연 같은 설정이 로드밸런서가 아니라 이 단위에 붙는다.
Auto Scaling — 인스턴스를 자동으로 늘리고 줄이는 서비스. 늘어난 인스턴스는 타겟 그룹에 자동 등록되고, 줄어들 때는 등록 해제 절차(4장)를 거친다.
Route 53 — 도메인 이름을 로드밸런서로 연결하는 DNS 서비스.
AWS Certificate Manager — HTTPS 리스너에 붙일 SSL/TLS 인증서를 발급·관리하는 서비스.
AWS WAF — ALB 앞단에서 요청 내용을 검사해 악성 트래픽을 걸러내는 서비스.
VPC·보안 그룹 — 로드밸런서가 어느 서브넷에 놓이고 어떤 트래픽을 받을 수 있는지를 결정하는 네트워크 경계.

7. 한눈에 정리

항목	확인할 것
계층	ALB=7계층(내용 기반 라우팅), NLB=4계층(IP·포트만), CLB=4/7계층(구세대, 신규 비권장)
프로토콜	ALB는 HTTP/HTTPS/gRPC만, NLB는 TCP/UDP/TLS, CLB는 TCP/SSL/HTTP/HTTPS
고정 IP	NLB만 정적·탄력적 IP 지원, ALB엔 없음 — 필요하면 앞단에 NLB를 둔다
라우팅	ALB는 리스너 규칙(우선순위·조건)으로 분기, CLB엔 이 개념 자체가 없음
기본 알고리즘	라운드 로빈(least outstanding requests·weighted random으로 변경 가능)
헬스체크 실패	대상 전부 비정상이면 오히려 전체에 흘려보냄(fail-open)
등록 해제	기본 300초 유예, 그 전에 연결이 끊기면 클라이언트에 500 에러
교차 영역 분산	ALB는 항상 켜짐(끌 수 없음), NLB는 기본 꺼짐
비용	시간당 기본 요금 + LCU/NLCU(차원 중 최댓값 기준), 트래픽 없어도 시간당 요금은 그대로
CLB→ALB 이전	순수 TCP/SSL 워크로드는 ALB로 못 옮김 — NLB가 맞는 대상

이어서 보면 좋은 글

리눅스 로그 빠르게 훑기 Top 10 — journalctl, 변수만 바꿔 그대로 쓰는 명령

와우패널 — Wed, 2 Sep 2026 09:11:19 +0900

"뭔가 이상하다"는 보고를 받으면 결국 로그를 봐야 합니다. 그런데 journalctl을 옵션 없이 치면 부팅 이후 전체 로그가 쏟아지고, 정작 찾는 줄은 그 안 어딘가에 파묻힙니다. 이 글은 범위를 좁혀서 보는 명령 10개를 모았습니다 — 심각도로, 서비스로, PID로, 시간대로. 변수 하나만 바꿔 그대로 복붙하면 됩니다.

로그가 너무 많다는 게 문제 — "새벽에 뭔가 있었던 것 같다"는 보고만 있고, 어느 서비스인지 몇 시쯤인지는 아직 모릅니다. journalctl을 그냥 치면 화면이 순식간에 넘어가 버립니다. 지금 필요한 건 전체를 읽는 게 아니라, 범위를 좁혀서 그 줄만 보는 명령입니다.

이 글 쓰는 법 — 변수 한 줄만 바꾸세요

변수가 있는 명령은 아래 형태입니다.

SVC=crond # ← 이 줄의 값만 여러분이 볼 서비스로 바꾸세요
journalctl -u "$SVC" -n 10 --no-pager # ← 최근 10줄만

첫 줄의 오른쪽 값만 바꾸고 그대로 붙여넣으면 됩니다. 출력은 전부 실제 서버(Rocky Linux 9)에서 실행해 그대로 옮겼습니다 — 여러분 서버의 서비스 이름·PID·시각은 다르게 나오는 게 정상입니다. 호스트명은 이 블로그의 도메인으로 바꿔 표기했습니다.

측정 환경: Rocky Linux 9.7(커널 5.14.0-611.47.1.el9_7) · systemd 252(252-55.el9_7.8.rocky.0.1, journalctl).

아래 10개는 전부 sudo 없이 됩니다 — 단 그 계정이 systemd-journal·adm·wheel 그룹 중 하나에는 속해 있어야 합니다(groups 명령으로 확인). 셋 다 아니면 저널 파일 자체를 못 읽어 전부 -- No entries --거나 권한 오류가 납니다.

1. 무엇부터 좁히나

1) 심각도로 — 에러만

언제 쓰나 — 범위를 가장 빠르게 좁히는 방법입니다. 서비스도 시간대도 모를 때, 일단 "에러"로 찍힌 것만 봅니다.

journalctl -p err -n 20 --no-pager # ← 심각도 err 이상만, 최근 20줄

$ journalctl -p err -n 20 --no-pager
 8월 24 19:05:54 wowpanel.tistory.com sshd[3161083]: error: kex_exchange_identification: Connection closed by remote host

주의 — 읽기 전용. 결과가 한 줄뿐이어도 정상입니다 — 최근에 err 이상으로 찍힌 게 이것뿐이었다는 뜻입니다. 다만 이 서버처럼 도커·k3s 컨테이너가 표준출력에 직접 level=error라고 적어 내보내는 로그는 얘기가 다릅니다 — man systemd.exec의 SyslogLevel= 설명대로, 특별히 설정하지 않으면 journald는 그런 줄도 유닛의 기본 우선순위(기본값 info)로 기록할 뿐, 메시지 안의 "error"라는 글자까지 읽어서 우선순위를 올려주지는 않습니다 — -p err로 걸러도 애플리케이션이 스스로 "에러"라고 적은 줄이 그대로 빠질 수 있습니다.

2) 특정 서비스 로그만

언제 쓰나 — "이 서비스가 뭘 했는지"가 궁금할 때. 가장 많이 쓰게 되는 형태입니다.

SVC=crond # ← 볼 서비스(유닛) 이름
journalctl -u "$SVC" -n 10 --no-pager # ← 최근 10줄만

$ SVC=crond
$ journalctl -u "$SVC" -n 10 --no-pager
 8월 24 23:01:01 wowpanel.tistory.com CROND[3227149]: (root) CMD (run-parts /etc/cron.hourly)
 8월 24 23:01:01 wowpanel.tistory.com run-parts[3227158]: (/etc/cron.hourly) finished 0anacron
 8월 24 23:01:01 wowpanel.tistory.com CROND[3227148]: (root) CMDEND (run-parts /etc/cron.hourly)
 8월 25 00:01:02 wowpanel.tistory.com CROND[3244130]: (root) CMD (run-parts /etc/cron.hourly)
 8월 25 00:01:02 wowpanel.tistory.com anacron[3244141]: Anacron started on 2026-08-25
 8월 25 00:01:02 wowpanel.tistory.com anacron[3244141]: Normal exit (0 jobs run)
 8월 25 00:01:02 wowpanel.tistory.com run-parts[3244143]: (/etc/cron.hourly) finished 0anacron
 8월 25 00:01:02 wowpanel.tistory.com CROND[3244129]: (root) CMDEND (run-parts /etc/cron.hourly)

주의 — 읽기 전용. 서비스 이름은 유닛 이름입니다(systemctl list-units --type=service로 확인). -- No entries --가 나오면 그 유닛이 systemd로 관리되지 않거나, 아직 한 번도 로그를 안 남겼다는 뜻입니다 — 서비스 이름 오타부터 의심하세요.

3) 특정 PID만

언제 쓰나 — ps나 ss로 이미 PID를 찾아 놓은 상태입니다. 그 프로세스가 방금 뭘 로그로 남겼는지, 유닛 이름을 몰라도(또는 systemd 관리 밖이어도) 바로 봅니다.

PID=2036 # ← ps/pgrep으로 찾은 PID
journalctl _PID="$PID" -n 8 --no-pager # ← 그 PID가 남긴 로그만

$ PID=2036
$ journalctl _PID="$PID" -n 8 --no-pager
 8월 24 04:23:03 wowpanel.tistory.com dockerd[2036]: time="2026-08-24T04:23:03.269712336+09:00" level=info msg="received task-delete event from containerd" container=87f091d850190f56ccac255d45ed9ad940ddee54af062b26ca01eb077e158e4e module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
 8월 24 04:23:04 wowpanel.tistory.com dockerd[2036]: time="2026-08-24T04:23:04.628755667+09:00" level=info msg="received task-delete event from containerd" container=abe2a2f645cd0d3a8a483a4b90ae8069350cc3f6874f22b2b6822d751f38c4c4 module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
 8월 24 06:41:39 wowpanel.tistory.com dockerd[2036]: time="2026-08-24T06:41:39.284438921+09:00" level=error msg="failed to validate image signature" error="resolving signature chain for image sha256:74c4244427b7312c5b901fe0f67cbc53683d06f4f24c6faee65d4182bf0fa893: expected image index descriptor, got application/vnd.docker.distribution.manifest.list.v2+json"

주의 — 읽기 전용. _PID=는 옵션이 아니라 systemd 저널의 필드 매치라 앞에 -가 붙지 않습니다. -u(유닛)와 달리 그 프로세스가 systemd 서비스로 등록돼 있지 않아도 됩니다 — 다만 PID는 재사용되므로, 한참 지난 뒤에 같은 PID로 조회하면 그사이 종료되고 새로 뜬 다른 프로세스의 로그가 섞여 나올 수 있습니다.

4) 시간대로 좁히기

언제 쓰나 — "그 시각쯤에 그 서비스가 뭘 했는지"를 볼 때. 보고받은 시각이 있으면 여기서 시작합니다.

SVC=crond # ← 볼 서비스
journalctl -u "$SVC" --since "1 hour ago" --no-pager # ← 최근 1시간만

$ SVC=crond
$ journalctl -u "$SVC" --since "1 hour ago" --no-pager
 8월 25 00:01:02 wowpanel.tistory.com CROND[3244130]: (root) CMD (run-parts /etc/cron.hourly)
 8월 25 00:01:02 wowpanel.tistory.com anacron[3244141]: Anacron started on 2026-08-25
 8월 25 00:01:02 wowpanel.tistory.com anacron[3244141]: Normal exit (0 jobs run)
 8월 25 00:01:02 wowpanel.tistory.com run-parts[3244143]: (/etc/cron.hourly) finished 0anacron
 8월 25 00:01:02 wowpanel.tistory.com CROND[3244129]: (root) CMDEND (run-parts /etc/cron.hourly)

주의 — 읽기 전용. "1 hour ago"·"10 min ago"·"2026-08-25 09:00:00"처럼 자연어와 정확한 시각 둘 다 받습니다. -u 없이 이 옵션만 쓰면 시스템 전체 로그를 그 시간대로 좁힙니다 — 서비스를 특정 못 했을 때는 그렇게 먼저 던져 보고, 거기서 서비스 이름을 건진 다음 2)로 좁혀 가는 순서가 보통 더 빠릅니다.

5) 언제 재부팅됐는지

언제 쓰나 — "혹시 그사이 재부팅됐나"부터 확인할 때. 재부팅 여부 자체가 원인 후보를 절반으로 줄여 줍니다.

journalctl --list-boots # ← 이 저널이 아는 부팅 목록

$ journalctl --list-boots
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 916cbf82bb8846b39b7b44b5131170cd Sun 2026-08-23 22:54:13 KST Tue 2026-08-25 00:29:23 KST

주의 — 읽기 전용. IDX 0이 지금 부팅입니다. 이 서버는 목록에 0 하나뿐입니다 — 재부팅을 한 번도 안 했다는 뜻이 아니라, 예전 부팅의 저널이 용량 제한(뒤 9번 참고)에 밀려 이미 지워졌다는 뜻입니다. 이전 부팅이 있다면 IDX -1처럼 음수로 나오고, journalctl -b -1로 그 부팅만 따로 볼 수 있습니다.

2. 그래도 안 잡히면

6) 커널 로그만

언제 쓰나 — 서비스 로그에는 안 잡히는데 뭔가 이상할 때. OOM(메모리 부족으로 프로세스 강제 종료)·디스크 I/O 에러·네트워크 인터페이스 문제는 서비스가 아니라 커널이 남깁니다. dmesg의 systemd 버전입니다.

journalctl -k -n 12 --no-pager # ← 커널이 남긴 최근 12줄

$ journalctl -k -n 12 --no-pager
 8월 24 04:00:04 wowpanel.tistory.com kernel: veth04ef7d6d (unregistering): left promiscuous mode
 8월 24 04:00:04 wowpanel.tistory.com kernel: cni0: port 36(veth04ef7d6d) entered disabled state
 8월 24 04:23:01 wowpanel.tistory.com kernel: cni0: port 35(veth265b4d4a) entered blocking state
 8월 24 04:23:01 wowpanel.tistory.com kernel: cni0: port 35(veth265b4d4a) entered disabled state
 8월 24 04:23:01 wowpanel.tistory.com kernel: veth265b4d4a: entered allmulticast mode
 8월 24 04:23:01 wowpanel.tistory.com kernel: veth265b4d4a: entered promiscuous mode
 8월 24 04:23:01 wowpanel.tistory.com kernel: cni0: port 35(veth265b4d4a) entered blocking state
 8월 24 04:23:01 wowpanel.tistory.com kernel: cni0: port 35(veth265b4d4a) entered forwarding state
 8월 24 04:23:04 wowpanel.tistory.com kernel: cni0: port 35(veth265b4d4a) entered disabled state
 8월 24 04:23:04 wowpanel.tistory.com kernel: veth265b4d4a (unregistering): left allmulticast mode
 8월 24 04:23:04 wowpanel.tistory.com kernel: veth265b4d4a (unregistering): left promiscuous mode
 8월 24 04:23:04 wowpanel.tistory.com kernel: cni0: port 35(veth265b4d4a) entered disabled state

주의 — 읽기 전용, root 불필요. 이 서버는 컨테이너가 뜨고 내려갈 때마다 가상 네트워크 인터페이스(veth...)가 생겼다 사라지는 게 커널 로그의 대부분을 차지합니다 — 컨테이너를 안 쓰는 서버라면 훨씬 조용합니다. OOM을 의심할 때는 여기서 Killed process·Out of memory를 찾는 게 첫 순서입니다(재현하지 않고는 예시를 만들 수 없어 이 글에는 못 실었습니다).

7) 실시간으로 지켜보기

언제 쓰나 — 문제를 지금 재현시키면서 로그가 실시간으로 찍히는 걸 보고 싶을 때.

SVC=sshd # ← 지켜볼 서비스
journalctl -u "$SVC" -f # ← 실시간으로, Ctrl+C로 멈춤

$ SVC=sshd
$ journalctl -u "$SVC" -f
 8월 25 00:34:16 wowpanel.tistory.com sshd[3254326]: Failed password for invalid user dkq from 80.94.92.163 port 58422 ssh2
 8월 25 00:34:17 wowpanel.tistory.com sshd[3254324]: Connection closed by invalid user wsupgrade 2.57.122.137 port 54428 [preauth]
 8월 25 00:34:17 wowpanel.tistory.com sshd[3254326]: Connection closed by invalid user dkq 80.94.92.163 port 58422 [preauth]
 8월 25 00:34:21 wowpanel.tistory.com sshd[3254366]: Invalid user wjyou from 80.94.92.30 port 60528
 8월 25 00:34:22 wowpanel.tistory.com sshd[3254366]: pam_unix(sshd:auth): check pass; user unknown

주의 — 위 출력은 실행 뒤 5초간 실제로 찍힌 줄이고, 그 뒤로도 화면은 계속 흐릅니다. -f는 끝나지 않는 명령이라 Ctrl+C로 직접 멈춰야 프롬프트로 돌아옵니다. -u 없이 journalctl -f만 쓰면 시스템 전체가 흘러서, 이 서버처럼 여러 서비스가 동시에 도는 환경에서는 원하는 줄이 순식간에 밀려 나갑니다 — 될 수 있으면 서비스를 좁힌 다음 켜세요.

8) 서비스 + 시간대 + 심각도, 한 번에

언제 쓰나 — 앞의 좁히기를 다 합친 실전형입니다. "그 서비스가, 그 시간대에, 에러를 냈는지"를 한 줄로.

SVC=sshd # ← 볼 서비스
journalctl -u "$SVC" --since "6 hours ago" -p err --no-pager # ← 최근 6시간의 에러만

$ SVC=sshd
$ journalctl -u "$SVC" --since "6 hours ago" -p err --no-pager
 8월 24 19:05:54 wowpanel.tistory.com sshd[3161083]: error: kex_exchange_identification: Connection closed by remote host

주의 — 읽기 전용. 옵션 순서는 안 가립니다 — -u·--since·-p는 전부 AND로 겹칩니다. 결과가 없으면(-- No entries --) 그 조건 셋을 동시에 만족하는 로그가 없다는 뜻이지, 명령이 잘못됐다는 뜻이 아닙니다 — 조건 하나씩 빼면서 어느 조건이 결과를 0으로 만들었는지 확인하세요.

3. 로그 자체가 말썽일 때

9) 로그가 디스크를 얼마나 쓰나

언제 쓰나 — /var가 꽉 찼는데 원인이 안 보일 때, 저널 자체가 범인일 수 있습니다.

journalctl --disk-usage # ← 저널이 디스크를 얼마나 쓰는지

$ journalctl --disk-usage
Archived and active journals take up 298.1M in the file system.

주의 — 읽기 전용. 이 값이 예상보다 크면 /etc/systemd/journald.conf의 SystemMaxUse를 확인하세요 — 기본값은 디스크의 일정 비율까지 자동으로 불어납니다. 5)번에서 본 것처럼 오래된 부팅의 로그부터 밀려나며 지워지므로, 용량을 줄이는 것과 "예전 로그가 사라지는 것"은 같은 동작의 양면입니다.

10) 키워드로 걸러 보기

언제 쓰나 — 서비스와 대략의 시간대는 좁혔는데, 그 안에서도 특정 단어가 있는 줄만 보고 싶을 때.

SVC=sshd # ← 볼 서비스
KEYWORD="invalid user" # ← 찾을 단어
journalctl -u "$SVC" --no-pager | grep -i "$KEYWORD" | tail -6 # ← 그 줄만, 최근 6개

$ SVC=sshd
$ KEYWORD="invalid user"
$ journalctl -u "$SVC" --no-pager | grep -i "$KEYWORD" | tail -6
 8월 25 00:31:27 wowpanel.tistory.com sshd[3253436]: Failed password for invalid user orp from 80.94.92.27 port 47336 ssh2
 8월 25 00:31:27 wowpanel.tistory.com sshd[3253434]: Connection closed by invalid user kcw 80.94.92.28 port 50928 [preauth]
 8월 25 00:31:28 wowpanel.tistory.com sshd[3253436]: Connection closed by invalid user orp 80.94.92.27 port 47336 [preauth]
 8월 25 00:31:43 wowpanel.tistory.com sshd[3253507]: Invalid user syd from 92.118.39.81 port 60922
 8월 25 00:31:45 wowpanel.tistory.com sshd[3253507]: Failed password for invalid user syd from 92.118.39.81 port 60922 ssh2
 8월 25 00:31:46 wowpanel.tistory.com sshd[3253507]: Connection closed by invalid user syd 92.118.39.81 port 60922 [preauth]

주의 — 읽기 전용. grep -i는 대소문자를 가리지 않습니다. journalctl 자체에도 -g(패턴 검색) 옵션이 있지만, 이렇게 파이프로 넘기면 grep에 이미 익숙한 -v(제외)·-c(개수)·-A/-B(앞뒤 줄)를 그대로 얹을 수 있어 더 유연합니다.

4. 전체 치트시트

한 번에 모아 둡니다. 변수(SVC·PID·KEYWORD)만 바꿔서 그대로 쓰세요.

# ── 무엇부터 좁히나
journalctl -p err -n 20 --no-pager # ← 심각도로
SVC=crond; journalctl -u "$SVC" -n 10 --no-pager # ← 서비스로
PID=2036; journalctl _PID="$PID" -n 8 --no-pager # ← PID로
SVC=crond; journalctl -u "$SVC" --since "1 hour ago" --no-pager # ← 시간대로
journalctl --list-boots # ← 재부팅 이력

# ── 그래도 안 잡히면
journalctl -k -n 12 --no-pager # ← 커널 로그만
SVC=sshd; journalctl -u "$SVC" -f # ← 실시간(Ctrl+C로 멈춤)
SVC=sshd; journalctl -u "$SVC" --since "6 hours ago" -p err --no-pager # ← 서비스+시간대+심각도

# ── 로그 자체가 말썽일 때
journalctl --disk-usage # ← 저널 용량
SVC=sshd; KEYWORD="invalid user"; journalctl -u "$SVC" --no-pager | grep -i "$KEYWORD" | tail -6 # ← 키워드로

마무리

이 10개는 순서대로 쓰면 됩니다 — 서비스도 시간도 모르면 1)로 시작하고, 서비스를 알면 2)나 4), PID만 있으면 3), 재부팅 여부부터 확인하려면 5). 여기서도 안 잡히면 커널(6)이나 실시간(7)으로 넘어가고, 8)은 그 전부를 합친 실전형입니다. 로그 자체가 디스크를 잡아먹는 게 문제라면 9), 걸러 읽고 싶으면 10). journalctl을 옵션 없이 치기 전에, 이 10개 중 하나로 먼저 좁혀 보세요.

이어서 보면 좋은 글

NAT 게이트웨이·인터넷 게이트웨이 — 온프레미스 경계 라우터 하나가 둘로 갈라진 이유

와우패널 — Tue, 1 Sep 2026 22:25:25 +0900

온프레미스에서는 경계 라우터(또는 방화벽) 한 대가 인터넷과 맞닿는 일을 전부 처리했습니다. 공인 IP를 받은 웹 서버로 외부 요청을 포트포워딩해 주는 것도, 사설 IP만 가진 내부 서버가 OS 패치나 외부 API를 받으러 나갈 때 주소를 변환(NAT, Network Address Translation — 사설 IP를 공인 IP로 바꿔 인터넷과 통신할 수 있게 하는 주소 변환 기술)해 주는 것도 같은 장비 안에서 일어났습니다. AWS는 이 두 역할을 아예 다른 컴포넌트로 쪼갭니다 — 외부에서 먼저 연결을 걸어올 수 있는 인터넷 게이트웨이와, 내부에서 나가는 연결만 허용하는 NAT 게이트웨이입니다. 이름이 비슷해 보이지만 "누가 먼저 연결을 트는가"가 완전히 갈리는 지점이고, 이 구분을 놓치면 프라이빗 서브넷의 서버가 인터넷에 나가지 못해 막히거나, 반대로 나가는 길을 열어 준다는 게 무엇을 의미하는지 모른 채 구성하게 됩니다.

새벽에 모니터링 알람이 울린다. 두 가용 영역(AZ, Availability Zone — 물리적으로 분리된 데이터센터 단위)에 나눠 오토 스케일링으로 띄워 둔 웹 서버 중 한쪽 그룹만 외부 결제 API 호출이 전부 타임아웃으로 실패하고 있다. 애플리케이션 로그도, 보안 그룹 규칙도, 결제사 쪽 상태 페이지도 멀쩡하다. 문제는 그 가용 영역이 아니라 다른 가용 영역에서 나던 장애였는데, 왜 이쪽 서버들까지 같이 영향을 받는지 알 수 없는 상황에서 시작한다.

이 글은 실제 AWS 콘솔 화면이나 CLI 실행 결과를 캡처하지 않습니다. 인터넷 게이트웨이·NAT 게이트웨이의 동작 방식, 가용 영역 종속성, 대역폭·연결 수 제한, 비용 구조처럼 이 글이 다루는 사실 하나하나는 전부 AWS 공식 문서(Amazon VPC User Guide)를 직접 열어 원문을 대조한 것입니다. 정확한 가격은 리전과 시점에 따라 바뀌므로, 구체적인 숫자보다 "무엇이 과금 대상이고 무엇이 아닌가"에 초점을 둡니다.

1. 인터넷 게이트웨이·NAT 게이트웨이가 정확히 뭔가

인터넷 게이트웨이는 VPC(Virtual Private Cloud — 계정 안에 논리적으로 분리해 만드는 가상 네트워크)와 인터넷 사이를 양방향으로 연결하는 컴포넌트입니다.

"An internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet."

퍼블릭 IP를 가진 인스턴스는 이 게이트웨이를 통해 인터넷으로 나갈 수도, 인터넷에서 먼저 걸려온 연결을 받을 수도 있습니다. 문제는 인스턴스가 실제로 아는 주소는 VPC 안의 사설 IP뿐이라는 점입니다. 이 변환을 대신 처리하는 것도 인터넷 게이트웨이입니다.

"The internet gateway logically provides the one-to-one NAT on behalf of your instance, so that when traffic leaves your VPC subnet and goes to the internet, the reply address field is set to the public IPv4 address or Elastic IP address of your instance, and not its private IP address. Conversely, traffic that's destined for the public IPv4 address or Elastic IP address of your instance has its destination address translated into the instance's private IPv4 address before the traffic is delivered to the VPC."

즉 인터넷 게이트웨이 자체가 이미 NAT(사설 IP 하나에 공인 IP 하나를 그대로 대응시키는 1:1 방식)를 수행하고 있습니다. 다만 이 NAT는 양방향입니다 — 인스턴스가 먼저 나갈 때도, 인터넷 쪽에서 먼저 걸어올 때도 똑같이 동작합니다.

NAT 게이트웨이는 이름은 비슷하지만 방향이 다릅니다.

"A NAT gateway is a Network Address Translation (NAT) service. You can use a NAT gateway so that instances in a private subnet can connect to services outside your VPC but external services can't initiate a connection with those instances."

프라이빗 서브넷의 인스턴스가 밖으로 나가는 연결은 통과시키지만, 밖에서 먼저 그 인스턴스로 연결을 거는 것은 애초에 받지 않습니다. 내부 서버가 자기 사설 IP를 밖에 노출하지 않고 나갈 수 있게 해 주는 편도 통로인 셈입니다. 실제로 프라이빗 서브넷의 인스턴스가 NAT 게이트웨이를 거쳐 인터넷까지 나가는 경로는 한 번 더 주소 변환을 거칩니다.

"Both private and public NAT gateways map the source private IPv4 address of the instances to the private IPv4 address of the NAT gateway. For a public NAT gateway, the internet gateway then maps the private IPv4 address of the public NAT gateway to the Elastic IP address associated with the NAT gateway."

인스턴스의 사설 IP → NAT 게이트웨이의 사설 IP → 인터넷 게이트웨이가 다시 탄력적 IP(Elastic IP, EIP — 계정에 할당해 원하는 리소스에 붙였다 뗄 수 있는 고정 공인 IP)로 변환. 이 두 단계를 거쳐야 프라이빗 서브넷의 인스턴스가 인터넷에 닿습니다.

2. 온프레미스 대응표

같은 물건이 아니라 "가장 가까운 것"입니다. 대응시켜 놓고 다른 점을 무시하면 3장 시나리오와 4장 오해로 바로 이어집니다.

온프레미스	AWS	같은 점	다른 점
경계 라우터의 정적 1:1 NAT	인터넷 게이트웨이	사설 IP ↔ 공인 IP 양방향 변환	무료, VPC당 1개 제한(3장)
사내 프록시·NAT 라우터(내부 서버 전용 아웃바운드)	NAT 게이트웨이	아웃바운드 전용, 내부 IP를 밖에 안 드러냄	가용 영역에 종속, 유료(3·5장)
방화벽 이중화 페어(HA, High Availability 클러스터)	하나의 NAT 게이트웨이 안의 이중화	자동 이중화로 가용성 확보	그 가용 영역 자체가 죽으면 같이 죽는다(4장)
직접 구축한 리눅스 NAT 서버	NAT 인스턴스(대안, 비권장)	사설 IP를 하나의 인터페이스로 내보냄	관리형이 아니라 패치·이중화를 직접 해야 함(4장)

3. 실무에서 반드시 알아야 하는 것

인터넷 게이트웨이는 VPC당 하나, 무료

"There is no charge for an internet gateway, but there are data transfer charges for EC2 instances that use internet gateways."

인터넷 게이트웨이 자체는 요금이 없습니다. 다만 만들 수 있는 개수에는 제약이 있습니다 — VPC 하나에는 동시에 하나만 연결할 수 있고, 리전당 기본 5개(상향 가능)까지만 만들 수 있습니다. 여러 VPC를 운영한다면 이 리전 단위 할당량을 계정 전체에서 나눠 쓰게 됩니다.

인터넷 게이트웨이만 만든다고 되는 게 아니다 — 라우팅 테이블이 결정한다

인터넷 게이트웨이를 VPC에 연결해도, 그 자체로는 아무 서브넷도 인터넷에 열리지 않습니다.

"If a subnet is associated with a route table that has a route to an internet gateway, it's known as a public subnet. If a subnet is associated with a route table that does not have a route to an internet gateway, it's known as a private subnet."

퍼블릭·프라이빗을 가르는 건 오직 그 서브넷의 라우팅 테이블에 인터넷 게이트웨이로 가는 경로(보통 0.0.0.0/0, IPv4 전체 대상을 뜻하는 표기)가 있는지 여부입니다. 이 기준은 뒤에서 NAT 게이트웨이 경로를 추가한다고 서브넷 성격이 바뀌지 않는 이유(4장 오해 3)로 다시 나옵니다.

NAT 게이트웨이는 퍼블릭 타입과 프라이빗 타입이 따로 있다

퍼블릭 NAT 게이트웨이가 기본값이고, 프라이빗 서브넷을 인터넷으로 연결하는 흔한 용도입니다.

"Public – (Default) Instances in private subnets can connect to the internet through a public NAT gateway, but the instances can't receive unsolicited inbound connections from the internet. You create a public NAT gateway in a public subnet and must associate an Elastic IP address with the NAT gateway at creation."

프라이빗 NAT 게이트웨이는 인터넷이 아니라 다른 VPC나 온프레미스 네트워크로만 나가는 용도입니다.

"Private – Instances in private subnets can connect to other VPCs or your on-premises network through a private NAT gateway, but the instances can't receive unsolicited inbound connections from the other VPCs or the on-premises network... You can't associate an Elastic IP address with a private NAT gateway."

퍼블릭 타입은 반드시 퍼블릭 서브넷에 만들고 탄력적 IP를 붙여야 하는 반면, 프라이빗 타입은 애초에 탄력적 IP를 붙일 수조차 없습니다 — 인터넷으로 나갈 일이 없기 때문입니다. 인터넷 접속은 필요 없고 사내망(Direct Connect·Site-to-Site VPN)으로만 나가면 되는 프라이빗 서브넷이라면 프라이빗 NAT 게이트웨이가 맞는 선택입니다.

NAT 게이트웨이는 가용 영역 하나에 묶여 있다

"Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone."

가용 영역 안에서는 자동으로 이중화되지만, 그 가용 영역 자체가 통째로 장애가 나면 그 NAT 게이트웨이도 같이 못 씁니다. 여러 가용 영역의 리소스가 NAT 게이트웨이 하나를 공유하도록 구성했다면, 공식 문서가 이 위험을 그대로 경고합니다.

"If you have resources in multiple Availability Zones and they share one NAT gateway, and if the NAT gateway's Availability Zone is down, resources in the other Availability Zones lose internet access. To improve resiliency, create a NAT gateway in each Availability Zone, and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone."

여러 가용 영역에 걸쳐 서버를 띄우는 이유가 애초에 한쪽이 죽어도 다른 쪽이 버티게 하려는 것인데, NAT 게이트웨이를 하나만 두면 그 목적이 무너집니다. 도입부 시나리오가 정확히 이 패턴이고, 4장에서 조치까지 이어 다룹니다.

대역폭과 동시 연결 수에는 자동 확장되는 한도가 있다

"A NAT gateway supports 5 Gbps of bandwidth and automatically scales up to 100 Gbps. If you require more bandwidth, you can split your resources into multiple subnets and create a NAT gateway in each subnet."

"A NAT gateway can process one million packets per second and automatically scales up to 10 million packets per second. Beyond this limit, a NAT gateway will drop packets."

트래픽이 늘면 5Gbps에서 시작해 100Gbps까지, 초당 백만 패킷에서 천만 패킷까지 자동으로 늘어납니다 — 온프레미스처럼 장비를 미리 사이징할 필요가 없습니다. 다만 이 한도를 넘으면 그냥 패킷을 버립니다. 연결 수는 조금 다른 기준으로 제한됩니다.

"Each IPv4 address can support up to 55,000 simultaneous connections to each unique destination. A unique destination is identified by a unique combination of destination IP address, the destination port, and protocol (TCP/UDP/ICMP)."

목적지 전체를 합쳐 55,000개가 아니라, 목적지 하나당 55,000개입니다. 서로 다른 외부 API 열 곳에 나눠서 나가는 트래픽이라면 사실상 이 한도에 걸릴 일이 거의 없지만, 특정 목적지 하나에 커넥션이 몰리는 배치 작업이라면 이 숫자를 기억해 둘 가치가 있습니다. 부족하면 NAT 게이트웨이에 IPv4 주소를 최대 8개(기본 IP 1개 + 보조 IP 7개)까지 붙여 늘릴 수 있습니다 — 다만 퍼블릭 NAT 게이트웨이에 붙일 수 있는 탄력적 IP는 기본 2개뿐이라, 8개까지 쓰려면 할당량 상향을 따로 신청해야 합니다(5장).

NAT 게이트웨이에는 보안 그룹을 붙일 수 없다

"You can't associate a security group with a NAT gateway. You can associate security groups with your instances to control inbound and outbound traffic."

트래픽 통제는 NAT 게이트웨이가 아니라 그 뒤에 있는 인스턴스 쪽 보안 그룹의 몫입니다. NAT 게이트웨이는 순수하게 주소를 변환해 중계하는 역할만 하고, 허용·차단 판단에는 관여하지 않습니다.

시나리오 — 프라이빗 서브넷의 서버가 패치를 받으려는데 인터넷이 안 된다

DB 서버를 프라이빗 서브넷에 올려놓고 며칠이 지나면, 보안 패치를 받거나 외부 API를 호출해야 하는 순간이 옵니다. 지금 상태로는 라우팅 테이블에 인터넷으로 나가는 경로 자체가 없어서 요청이 그냥 멈춥니다.

가장 먼저 떠오르는 방법은 "프라이빗 서브넷의 라우팅 테이블에 인터넷 게이트웨이로 가는 0.0.0.0/0 경로를 그냥 추가하면 되지 않을까"입니다. 실제로 경로를 추가하면 요청은 나갑니다. 하지만 이 순간 그 서브넷은 더 이상 "프라이빗"이 아닙니다 — 앞서 확인한 대로 퍼블릭·프라이빗을 가르는 유일한 기준은 라우팅 테이블에 인터넷 게이트웨이 경로가 있는지이므로, 이 경로를 추가한 순간 그 서브넷은 정의상 퍼블릭 서브넷이 됩니다. DB 서버에 공인 IP가 없어 당장 인터넷에서 직접 접근은 못 하더라도, 서브넷 전체의 보안 경계가 흐트러지고 이후 이 서브넷에 올라오는 다른 인스턴스가 실수로 공인 IP를 받으면 그대로 인터넷에 노출됩니다.

정답은 인터넷 게이트웨이 경로를 프라이빗 서브넷에 직접 끌어오는 게 아니라, 퍼블릭 서브넷에 NAT 게이트웨이를 만들고 프라이빗 서브넷의 라우팅 테이블에는 그 NAT 게이트웨이로 가는 0.0.0.0/0 경로만 추가하는 것입니다. 이렇게 구성하면 서브넷은 여전히 프라이빗으로 남고(인터넷 게이트웨이 직행 경로가 없으므로), DB 서버가 보내는 요청은 NAT 게이트웨이 → 인터넷 게이트웨이를 거쳐 나가지만 밖에서 먼저 그 서버로 연결을 거는 것은 처음부터 불가능합니다.

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "NAT 게이트웨이 하나 만들어서 여러 가용 영역이 같이 쓰면 되겠지"

가장 조용히 사고로 이어지는 오해입니다. 온프레미스에서 이중화 방화벽 페어 하나를 여러 랙이 공유하던 감각으로 접근하면, NAT 게이트웨이도 하나만 두고 여러 가용 영역의 프라이빗 서브넷이 전부 그걸 가리키게 구성하기 쉽습니다. 도입부 시나리오가 정확히 이 상태입니다 — 웹 서버는 두 가용 영역에 나눠 오토 스케일링으로 띄워 놨는데, 두 서브넷의 라우팅 테이블이 전부 한쪽 가용 영역에 있는 NAT 게이트웨이 하나를 가리키고 있었습니다. 그 NAT 게이트웨이가 속한 가용 영역에 장애가 나자, 정작 장애가 안 난 다른 가용 영역의 서버들까지 외부 결제 API 호출이 전부 막혔습니다 — 여러 가용 영역에 걸쳐 서버를 띄운 이유 자체가 무색해지는 상황입니다.

조치는 가용 영역마다 NAT 게이트웨이를 따로 만들고, 각 가용 영역의 프라이빗 서브넷 라우팅 테이블이 같은 가용 영역에 있는 NAT 게이트웨이를 가리키도록 나누는 것입니다. 당장 장애가 난 상황이라면 살아 있는 가용 영역에 새 NAT 게이트웨이를 급하게 하나 더 만들고 그쪽 라우팅 테이블만 옮겨도 되지만, 이건 임시 조치입니다. 근본적으로는 처음 설계할 때부터 "가용 영역 개수만큼 NAT 게이트웨이도 만든다"를 기본값으로 삼아야 합니다 — 비용은 가용 영역 수만큼 늘지만(5장), 그게 애초에 멀티 AZ로 구성한 목적입니다.

오해 2. "인터넷 게이트웨이가 있으면 방화벽 역할도 해 주겠지"

인터넷 게이트웨이는 라우팅과 주소 변환만 합니다. 어떤 트래픽을 들여보내고 막을지는 전혀 판단하지 않습니다. 온프레미스에서 경계 라우터에 NAT와 방화벽 규칙을 같이 걸어 두던 감각으로 접근하면, 인터넷 게이트웨이만 붙여 놓으면 트래픽 통제도 알아서 될 거라 생각하기 쉽습니다. 실제로 어떤 포트·프로토콜을 허용할지는 인스턴스에 붙은 보안 그룹과 서브넷에 붙은 네트워크 ACL(Access Control List — 서브넷 단위로 허용·차단을 판단하는 접근 제어 목록)이 결정합니다 — 인터넷 게이트웨이는 그 트래픽이 오갈 수 있는 통로만 열어 둘 뿐입니다.

오해 3. "프라이빗 서브넷 라우팅 테이블에 NAT 게이트웨이 경로를 추가하면 그 서브넷도 퍼블릭이 되는 거 아닌가"

아닙니다. 서브넷의 퍼블릭·프라이빗을 가르는 기준은 오직 인터넷 게이트웨이로 가는 직접 경로가 있는지입니다(3장). NAT 게이트웨이로 가는 경로는 이 기준에 해당하지 않습니다 — NAT 게이트웨이 자체가 퍼블릭 서브넷에 놓여 있고(퍼블릭 타입 기준), 그 NAT 게이트웨이가 다시 인터넷 게이트웨이로 나가는 구조이지, 프라이빗 서브넷이 인터넷 게이트웨이를 직접 가리키는 게 아니기 때문입니다. 이 오해가 실제로 문제가 되는 지점은 3장 시나리오처럼 "그냥 인터넷 게이트웨이 경로를 프라이빗 서브넷에 직접 추가"하는 반대 방향의 실수로 이어질 때입니다.

오해 4. "저렴하게 EC2(Elastic Compute Cloud — AWS의 가상 서버) 인스턴스 하나로 NAT 서버를 직접 만들면 되지"

가능하긴 합니다 — AWS는 이를 NAT 인스턴스라고 부르고 여전히 지원합니다. 다만 권장하지는 않습니다.

"We recommend that you use NAT gateways because they provide better availability and bandwidth and require less effort on your part to administer."

공식 비교표에서 핵심만 추리면, 온프레미스에서 소프트웨어 라우터를 직접 굴리는 것과 상용 어플라이언스를 쓰는 것의 차이와 비슷합니다(공식 비교표는 이 외에도 네트워크 ACL·플로우 로그·타임아웃 동작 등 항목이 더 있습니다).

항목	NAT 게이트웨이	NAT 인스턴스
가용성	가용 영역 안에서 자동 이중화	장애 조치(failover)를 직접 스크립트로 관리
대역폭	최대 100Gbps까지 자동 확장	선택한 인스턴스 타입의 대역폭에 종속
유지보수	AWS가 관리, 직접 할 일 없음	소프트웨어 업데이트·OS 패치를 직접 관리
비용	NAT 게이트웨이 개수·사용 시간·처리 데이터량 기준	NAT 인스턴스 개수·사용 시간·인스턴스 타입·크기 기준
보안 그룹	리소스에 붙일 수 있지만 NAT 게이트웨이 자체에는 불가	NAT 인스턴스 자체에도 붙일 수 있음

NAT 인스턴스가 유리한 지점도 있습니다 — 보안 그룹을 직접 붙일 수 있고, 포트 포워딩이나 베스천 서버(내부망 접속용 중계 서버) 용도로 함께 쓸 수 있습니다. 하지만 이중화·확장·패치를 전부 직접 관리해야 한다는 부담은 그대로 남고, AWS도 기존 NAT 인스턴스를 쓰고 있다면 NAT 게이트웨이로 옮기라고 명시적으로 권장합니다. 온프레미스에서 이미 방화벽 어플라이언스로 옮겨 온 조직이라면 이 권장 방향이 낯설지 않을 것입니다.

5. 비용·운영 감각

온프레미스에서 경계 라우터·NAT 장비는 한 번 사서 설치하면 그 뒤로는 감가상각만 신경 쓰면 되는 자산(CAPEX, Capital Expenditure — 처음에 사들여 감가상각하는 자본 지출)이었습니다. 인터넷 게이트웨이와 NAT 게이트웨이는 이 감각이 완전히 갈립니다.

인터넷 게이트웨이는 그 자체로 무료입니다 — 데이터 전송 요금만 인스턴스 쪽에 별도로 붙습니다. NAT 게이트웨이는 다릅니다.

"When you provision a NAT gateway, you are charged for each hour that your NAT gateway is available and each gigabyte of data that it processes."

만들어 두기만 해도 시간당 요금이 쌓이고, 그 위에 처리한 데이터량(GB)만큼 추가로 붙습니다. 온프레미스 감각으로는 "안 쓰는 시간엔 그냥 놀고 있는 것"이지만, NAT 게이트웨이는 트래픽이 없어도 떠 있는 것만으로 계속 과금됩니다. 개발·테스트 환경에 NAT 게이트웨이를 만들어 두고 밤새, 주말 내내 지우지 않으면 실제로 쓴 시간보다 훨씬 오래 요금이 쌓입니다.

데이터 처리 비용을 줄이는 방법도 공식 문서가 짚어 줍니다.

"If your AWS resources send or receive a significant volume of traffic across Availability Zones, ensure that the resources are in the same Availability Zone as the NAT gateway. Alternatively, create a NAT gateway in each Availability Zone with resources. If most traffic through your NAT gateway is to AWS services that support interface endpoints or gateway endpoints, consider creating an interface endpoint or gateway endpoint for these services."

리소스와 NAT 게이트웨이를 같은 가용 영역에 두거나(가용 영역마다 NAT 게이트웨이를 따로 두는 4장의 구성이 여기서도 그대로 도움이 됩니다), S3 같은 AWS 서비스로만 나가는 트래픽이라면 NAT 게이트웨이 대신 VPC 엔드포인트(6장)를 쓰는 편이 데이터 처리 비용을 줄이는 방법입니다.

할당량도 함께 확인해야 합니다. 가용 영역당 NAT 게이트웨이는 기본 5개(상향 가능), 퍼블릭 NAT 게이트웨이 하나에 붙일 수 있는 탄력적 IP는 기본 2개(최대 8개까지 상향 가능)입니다. 가용 영역마다 NAT 게이트웨이를 나눠 만드는 구성(4장)을 계획할 때 이 숫자를 미리 알아 두면 나중에 할당량 초과로 막히는 일을 줄일 수 있습니다.

6. 관련 개념

VPC·서브넷·라우팅 테이블 — 인터넷 게이트웨이·NAT 게이트웨이가 실제로 트래픽을 흘려보내려면 라우팅 테이블에 경로가 있어야 한다. 퍼블릭·프라이빗 서브넷을 가르는 기준도 이 라우팅 테이블에 있다.
보안 그룹·네트워크 ACL — 인터넷 게이트웨이·NAT 게이트웨이가 통로를 열어 줘도, 실제로 어떤 트래픽을 허용할지는 이 둘이 결정한다.
VPC 엔드포인트 — 프라이빗 서브넷에서 S3·DynamoDB 같은 AWS 서비스에 접근할 때, NAT 게이트웨이를 거치지 않고 AWS 네트워크 안에서 바로 연결하는 방법. 데이터 처리 비용을 줄이는 대안이 된다.
전송 게이트웨이·Site-to-Site VPN — 프라이빗 NAT 게이트웨이가 온프레미스 네트워크나 다른 VPC로 나갈 때 실제로 경유하는 하이브리드 연결 컴포넌트.
탄력적 IP(Elastic IP) — 퍼블릭 NAT 게이트웨이와 퍼블릭 서브넷의 인스턴스가 인터넷과 통신할 때 쓰는 고정 공인 IP.

7. 한눈에 정리

항목	확인할 것
방향	인터넷 게이트웨이는 양방향(인바운드 가능), NAT 게이트웨이는 아웃바운드 전용
위치	인터넷 게이트웨이는 VPC에 연결, NAT 게이트웨이는 퍼블릭 서브넷 안에 생성(퍼블릭 타입 기준)
개수 제한	인터넷 게이트웨이는 VPC당 1개, NAT 게이트웨이는 가용 영역당 기본 5개
가용 영역	인터넷 게이트웨이는 특정 가용 영역에 종속되지 않음, NAT 게이트웨이는 특정 가용 영역에 종속 — 이중화하려면 가용 영역마다 따로 만들어야 함
퍼블릭/프라이빗 서브넷 결정	라우팅 테이블에 인터넷 게이트웨이로 가는 직접 경로가 있는지만으로 결정, NAT 게이트웨이 경로는 무관
보안 그룹	NAT 게이트웨이는 자체적으로 보안 그룹을 붙일 수 없음(리소스 쪽에 붙임, NAT 인스턴스는 예외), 인터넷 게이트웨이는 애초에 트래픽 허용 여부를 판단하지 않음
비용	인터넷 게이트웨이는 무료(데이터 전송료만), NAT 게이트웨이는 시간당+처리 GB당 유료
대역폭	NAT 게이트웨이는 5Gbps에서 100Gbps까지 자동 확장, 초당 백만~천만 패킷
연결 수	NAT 게이트웨이 IP 하나당 목적지 하나에 55,000 동시 연결
대안	NAT 인스턴스도 가능하지만 AWS는 관리 부담 때문에 NAT 게이트웨이를 권장

이어서 보면 좋은 글

보안 그룹 vs 네트워크 ACL — 온프레미스 방화벽 감각으로 읽는 AWS의 이중 방어선

와우패널 — Tue, 1 Sep 2026 00:17:03 +0900

온프레미스에서 서버로 들어오는 트래픽을 막을 때는 보통 두 계층을 씁니다. 코어 스위치나 경계 라우터에 걸어 둔 ACL(Access Control List, 접근 제어 목록 — 순서대로 평가되는 허용·차단 규칙의 목록)이 서브넷 단위로 큰 그물을 치고, 그 안쪽에서는 서버마다 개별 방화벽(iptables, Windows 방화벽)이 세부 규칙을 다시 겁니다. AWS도 구조는 똑같이 두 계층입니다 — 인스턴스에 붙는 보안 그룹과 서브넷에 붙는 네트워크 ACL입니다. 문제는 이름이 비슷해서 "결국 같은 방화벽 규칙 아닌가"라고 생각하기 쉽다는 겁니다. 실제로는 트래픽을 판단하는 방식 자체가 다르고, 이 차이를 모르고 넘어가면 규칙을 분명히 추가했는데도 연결이 안 되는 상황을 만납니다.

온프레미스에서 경계 방화벽과 서버 방화벽을 함께 운영해 온 네트워크 관리자가 로드밸런서 뒤 웹 서버 서브넷에 네트워크 ACL을 새로 만든다. 인바운드 규칙에 HTTPS(443) 허용을 추가하고 "이제 됐다"며 넘어갔는데, 로드밸런서의 헬스체크가 계속 비정상(unhealthy)으로 뜬다. 보안 그룹도, 웹 서버 애플리케이션도 멀쩡한데 왜 응답이 안 돌아오는지 알 수 없는 상황에서 시작한다.

이 글은 실제 AWS 콘솔 화면이나 CLI 실행 결과를 캡처하지 않습니다. 보안 그룹과 네트워크 ACL의 동작 방식, 기본 규칙, 규칙 평가 순서, 할당량(quota)처럼 이 글이 다루는 사실 하나하나는 전부 AWS 공식 문서(Amazon VPC User Guide)를 직접 열어 원문을 대조한 것입니다.

1. 보안 그룹과 네트워크 ACL이 정확히 뭔가

보안 그룹은 인스턴스(정확히는 인스턴스에 붙은 네트워크 인터페이스) 단위로 붙는 방화벽입니다. AWS 공식 문서는 이렇게 정의합니다.

"A security group controls the traffic that is allowed to reach and leave the resources that it is associated with. For example, after you associate a security group with an EC2 instance, it controls the inbound and outbound traffic for the instance."

네트워크 ACL은 서브넷 단위로 붙는 방화벽입니다.

"A network access control list (ACL) allows or denies specific inbound or outbound traffic at the subnet level."

여기까지는 "트래픽을 제어하는 규칙"이라는 점에서 같아 보입니다. 하지만 AWS 공식 문서가 둘을 나란히 비교한 표를 보면 완전히 다른 원칙으로 동작한다는 것이 드러납니다. 원문 표(Compare security groups and network ACLs)를 그대로 옮기면 이렇습니다.

특성	보안 그룹	네트워크 ACL
Level of operation	Instance level	Subnet level
Scope	Applies to all instances associated with the security group	Applies to all instances in the associated subnets
Rule type	Allow rules only	Allow and deny rules
Rule evaluation	Evaluates all rules before deciding whether to allow traffic	Evaluates rules in ascending order until a match for the traffic is found
Return traffic	Automatically allowed (stateful)	Must be explicitly allowed (stateless)

레벨(인스턴스 대 서브넷)만 다른 게 아니라, 규칙을 판단하는 방식 자체가 다릅니다. 이 다섯 줄이 이 글 전체를 관통하는 축입니다.

2. 온프레미스 대응표

같은 물건이 아니라 "가장 가까운 것"입니다. 대응시켜 놓고 다른 점을 무시하면 3·4장에서 다루는 오해로 바로 이어집니다.

온프레미스	AWS	같은 점	다른 점
서버별 개별 방화벽(iptables·Windows 방화벽)	보안 그룹	리소스 단위로 트래픽 제어	상태 유지·allow만 가능(3장)
경계 라우터·코어 스위치의 ACL	네트워크 ACL	서브넷 단위로 트래픽 제어	무상태·allow·deny 둘 다(3장)
규칙을 위에서 아래로, 첫 매치 적용	네트워크 ACL의 규칙 번호 순 평가	순서가 판단에 영향을 준다	보안 그룹은 순서 개념이 없다(3장)
방화벽 그룹·객체 이름으로 소스 지정	보안 그룹을 소스로 참조	재사용 가능한 단위로 규칙 묶기	IP 대신 보안 그룹 ID로 지정(3장)
경계 방화벽을 2차 방어선으로 두는 구성	네트워크 ACL	서브넷 전체를 감싸는 굵은 그물	보안 그룹이 주 방어선이다(4장)

3. 실무에서 반드시 알아야 하는 것

상태 유지(보안 그룹)와 무상태(네트워크 ACL)의 실제 차이

보안 그룹은 요청을 보낸 트래픽의 응답을 자동으로 통과시킵니다.

"Security groups are stateful. For example, if you send a request from an instance, the response traffic for that request is allowed to reach the instance regardless of the inbound security group rules. Responses to allowed inbound traffic are allowed to leave the instance, regardless of the outbound rules."

네트워크 ACL은 이 자동 허용이 없습니다.

"NACLs are stateless, which means that information about previously sent or received traffic is not saved. If, for example, you create a NACL rule to allow specific inbound traffic to a subnet, responses to that traffic are not automatically allowed."

즉 보안 그룹에서는 인바운드 443을 허용하면 그 요청에 대한 응답은 아웃바운드 규칙과 무관하게 자동으로 나갑니다. 네트워크 ACL에서는 인바운드 443을 허용해도, 그 응답이 나가는 아웃바운드 트래픽을 별도 규칙으로 또 허용해야 합니다. 이때 응답은 443이 아니라 클라이언트가 연결을 시작할 때 임의로 고른 임시 포트(ephemeral port)로 돌아오므로, 이 포트 범위를 아웃바운드에 열어 둬야 합니다. AWS 공식 문서는 실무 대응을 이렇게 안내합니다.

"In practice, to cover the different types of clients that might initiate traffic to public-facing instances in your VPC, you can open ephemeral ports 1024-65535."

도입부 시나리오의 원인이 바로 이것입니다 — 네트워크 ACL에 인바운드 443만 열고 이 아웃바운드 임시 포트 범위를 안 열면, 요청은 서버까지 도달하지만 응답이 나가지 못해 로드밸런서 입장에서는 타임아웃으로 보입니다.

네트워크 ACL은 번호 순서대로 평가하고, 첫 매치에서 멈춘다

"Each rule has a number from 1 to 32766. We evaluate the rules in order, starting with the lowest numbered rule, when deciding whether allow or deny traffic. If the traffic matches a rule, the rule is applied and we do not evaluate any additional rules. We recommend that you start by creating rules in increments (for example, increments of 10 or 100) so that you can insert new rules later on, if needed."

온프레미스 방화벽에서 규칙을 위에서 아래로 읽어 내려가다 첫 매치에서 적용하던 것과 같은 방식입니다. 뒤쪽에 더 엄격한 deny 규칙을 넣어도 앞쪽 규칙에 먼저 걸리면 그 규칙으로 끝입니다. 그래서 AWS도 처음부터 규칙 번호를 10이나 100 단위로 띄워 두라고 권장합니다 — 나중에 규칙 하나를 끼워 넣을 여유를 남겨 두라는 뜻입니다. 보안 그룹에는 이 순서 개념 자체가 없습니다 — allow 규칙만 있고, 전체 규칙을 다 평가한 뒤 하나라도 매치되면 허용하는 방식이라 규칙을 적는 순서가 결과에 영향을 주지 않습니다.

보안 그룹은 소스를 다른 보안 그룹으로 지정할 수 있다

온프레미스 방화벽 규칙은 대개 IP 대역이나 서브넷을 소스로 씁니다. 보안 그룹은 IP 대신 다른 보안 그룹의 ID를 소스로 지정할 수 있습니다.

"When you specify a security group as the source or destination for a rule, the rule affects all instances that are associated with the security groups. The instances can communicate in the specified direction, using the private IP addresses of the instances, over the specified protocol and port."

AWS 공식 문서가 드는 예시가 실무에서 그대로 반복되는 3계층 구성입니다.

"Add rules to the load balancer security group to allow HTTP and HTTPS traffic from the internet... Add rules to the security group for the web servers to allow HTTP and HTTPS traffic only from the load balancer. The source is the security group for the load balancer. Add rules to the security group for the database servers to allow database requests from the web servers. The source is the security group for the web servers."

로드밸런서용, 웹 서버용, DB 서버용 보안 그룹을 각각 만들고, 뒤 계층의 인바운드 규칙 소스로 앞 계층의 보안 그룹 ID를 지정하는 방식입니다. 인스턴스가 늘어나거나 교체돼 IP가 바뀌어도 규칙을 다시 고칠 필요가 없습니다 — 그 보안 그룹에 속한 인스턴스라는 사실만으로 규칙이 적용됩니다.

서브넷과 네트워크 ACL은 1대1, 네트워크 ACL과 서브넷은 1대다

"Each subnet in your VPC must be associated with a network ACL. If you don't explicitly associate a subnet with a network ACL, the subnet is automatically associated with the default network ACL."
"You can associate a network ACL with multiple subnets. However, a subnet can be associated with only one network ACL at a time. When you associate a network ACL with a subnet, the previous association is removed."

서브넷 하나는 항상 네트워크 ACL 하나에만 연결됩니다(따로 지정하지 않으면 기본 네트워크 ACL이 자동으로 연결됩니다) — 두 개를 동시에 걸어 놓을 수 없습니다. 반대로 네트워크 ACL 하나는 여러 서브넷에 동시에 연결할 수 있습니다. 보안 그룹은 이 제약이 없습니다 — 인스턴스 하나에 보안 그룹을 여러 개 붙일 수 있고, 그 규칙들은 합쳐져서 하나의 허용 목록처럼 동작합니다.

시나리오 — 온프레미스 방화벽 규칙표를 그대로 옮긴다면

방화벽 규칙표에 "로드밸런서 → 웹 서버(80·443)", "웹 서버 → DB 서버(3306)"처럼 계층별 소스·목적지가 IP 대역으로 적혀 있는 조직이 AWS로 전환한다고 가정합니다.

계층마다 보안 그룹을 하나씩 만드는 것이 첫 단계입니다. 로드밸런서용 보안 그룹, 웹 서버용 보안 그룹, DB 서버용 보안 그룹을 따로 만들고, 각 인스턴스는 자기 계층의 보안 그룹만 붙입니다. 그다음 규칙표의 소스를 IP 대역이 아니라 앞 계층의 보안 그룹 ID로 바꿔 씁니다 — 웹 서버 보안 그룹의 인바운드 소스는 "로드밸런서가 있는 서브넷 대역"이 아니라 "로드밸런서 보안 그룹" 자체입니다. DB 서버 보안 그룹도 마찬가지로 "웹 서버가 있는 서브넷 대역"이 아니라 "웹 서버 보안 그룹"을 소스로 씁니다.

이렇게 옮기면 웹 서버 대수가 늘어나거나 오토 스케일링으로 인스턴스가 계속 교체돼도 규칙표를 다시 손댈 필요가 없습니다. IP 대역으로 규칙을 짜 두면 서브넷을 나중에 넓히거나 인스턴스를 다른 서브넷으로 옮길 때마다 방화벽 규칙까지 같이 손봐야 하지만, 보안 그룹 참조는 "그 그룹에 속해 있는가"만 보므로 이런 변경에 영향을 받지 않습니다. 네트워크 ACL은 이 참조 방식을 지원하지 않습니다 — 서브넷 단위로만 걸리므로, 규칙표의 서브넷 경계에 해당하는 부분(예: 웹 서버 서브넷과 DB 서버 서브넷 사이의 큰 틀)만 네트워크 ACL로 옮기고, 계층별 세부 규칙은 보안 그룹으로 옮기는 것이 실무에서 맞는 역할 분담입니다.

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "네트워크 ACL에서 인바운드만 열면 그 트래픽은 다 처리된 것이다"

가장 흔하고 가장 조용히 사고로 이어지는 오해입니다. 네트워크 ACL은 무상태라 인바운드를 허용해도 그 응답이 나가는 아웃바운드는 별도로 열어야 합니다(3장). 인바운드 443만 열고 넘어가면, 요청은 서버까지 도달해도 응답이 못 나가 클라이언트는 그냥 연결이 걸린 것처럼 보입니다. 도입부 시나리오의 로드밸런서 헬스체크 실패가 정확히 이 패턴이고, AWS 공식 문서도 이 경우를 별도로 경고합니다.

"With Elastic Load Balancing, if the subnet for your backend instances has a network ACL in which you've added a deny rule for all traffic with a source of either 0.0.0.0/0 or the subnet's CIDR, your load balancer can't carry out health checks on the instances."

여기서 CIDR(Classless Inter-Domain Routing — 10.0.0.0/24처럼 IP 대역의 범위를 표기하는 방식)은 서브넷 전체의 IP 대역을 가리킵니다. 원인이 애플리케이션이나 보안 그룹이 아니라 네트워크 ACL의 아웃바운드 규칙 누락이라는 것을 모르면, 정작 문제 없는 곳들을 계속 확인하게 됩니다.

오해 2. "규칙을 다 확인해서 제일 엄격한 쪽으로 결정되겠지"

네트워크 ACL은 번호가 낮은 규칙부터 순서대로 보다가 첫 매치에서 즉시 멈춥니다(3장). 뒤쪽에 더 엄격한 deny 규칙을 추가해도 앞쪽에 이미 걸리는 allow 규칙이 있으면 그 deny는 평가조차 되지 않습니다. 반대로 보안 그룹은 규칙 순서라는 개념 자체가 없습니다 — allow 규칙만 있고 전체를 다 본 뒤 하나라도 매치되면 허용하는 방식이라, "순서를 신경 써야 하는가"라는 질문 자체가 네트워크 ACL에만 해당합니다.

오해 3. "보안 그룹으로 특정 IP를 차단할 수 있다"

불가능합니다. 보안 그룹 규칙 기본 원칙은 이렇게 명시돼 있습니다.

"You can specify allow rules, but not deny rules."

특정 IP를 명시적으로 막고 싶다면 보안 그룹이 아니라 네트워크 ACL의 deny 규칙을 써야 합니다. 보안 그룹만으로 "이 IP만 빼고 전부 허용"하는 규칙은 만들 수 없습니다 — allow 목록에 없으면 자동으로 막히는 방식이지, 명시적으로 차단하는 방식이 아닙니다.

오해 4. "기본 보안 그룹이 마음에 안 들면 지우고 새로 만들면 된다"

기본 보안 그룹은 삭제할 수 없습니다.

"You can't delete a default security group. If you try to delete a default security group, we return the following error code: Client.CannotDelete."

규칙은 자유롭게 고칠 수 있지만, 그룹 자체는 항상 남아 있습니다. 그리고 새로 만든 인스턴스에 보안 그룹을 따로 지정하지 않으면 이 기본 보안 그룹이 자동으로 붙습니다 — 기본 보안 그룹의 인바운드 기본 규칙은 "자기 자신을 소스로 하는 전체 허용"(같은 기본 보안 그룹에 속한 인스턴스끼리는 서로 통신 가능)이라, 인터넷이나 다른 보안 그룹으로부터의 트래픽은 별도로 열어 주기 전까지는 들어오지 않습니다.

오해 5. "네트워크 ACL만 촘촘하게 잠그면 보안 그룹은 대충 열어도 된다"

AWS의 권장 방향은 반대입니다.

"Use security groups as the primary mechanism for controlling network access to your VPCs. When necessary, use network ACLs to provide stateless, coarse-grain network control. Security groups are more versatile than network ACLs, due to their ability to perform stateful packet filtering and create rules that reference other security groups. Network ACLs can be effective as a secondary control (for example, to deny a specific subset of traffic) or as high-level subnet guard rails."

보안 그룹을 주 방어선으로 세밀하게 관리하고, 네트워크 ACL은 서브넷 전체를 감싸는 굵은 보조 그물(2차 방어선)로 쓰는 것이 AWS가 명시하는 역할 분담입니다. 온프레미스에서 경계 방화벽 하나만 촘촘히 관리하고 서버 방화벽은 느슨하게 두던 구성을 그대로 옮기면, AWS가 권장하는 방향과 정반대로 가게 됩니다.

5. 비용·운영 감각

온프레미스에서는 방화벽 장비를 늘리거나 정책을 세분화할 때마다 라이선스·성능 비용을 신경 써야 합니다. 보안 그룹과 네트워크 ACL은 이 감각과 다릅니다.

둘 다 그 자체로는 무료입니다.

"There is no additional charge for using security groups."
"There is no additional charge for using network ACLs."

몇 개를 만들든, 규칙을 얼마나 세분화하든 추가 요금이 붙지 않습니다. 다만 무제한은 아닙니다 — 할당량(quota)이 있습니다. 보안 그룹 하나에는 인바운드·아웃바운드 각각 최대 60개 규칙(계정 신청으로 상향 가능), 네트워크 인터페이스 하나에는 최대 5개(최대 16개까지 상향 가능)의 보안 그룹만 붙일 수 있습니다. 네트워크 ACL 하나에는 인바운드·아웃바운드 각각 최대 20개 규칙(상향 시 최대 40개)이 기본값입니다. 규칙이 갑자기 안 먹히거나 인스턴스에 보안 그룹을 더 못 붙이는 상황을 만나면, 애플리케이션이나 설정 실수를 의심하기 전에 이 할당량부터 확인하는 것이 순서입니다.

운영 방식도 온프레미스와 다릅니다. 서버 방화벽은 보통 서버 하나하나에 규칙을 다시 적용해야 하지만, 보안 그룹은 규칙을 한 번 고치면 그 보안 그룹이 붙은 모든 리소스에 즉시 반영됩니다 — 인스턴스가 수십, 수백 대여도 규칙 변경은 한 곳에서 끝납니다. 네트워크 ACL도 마찬가지로 서브넷에 연결해 두면 그 서브넷의 모든 인스턴스에 일괄 적용됩니다. 방화벽 정책을 서버마다 따로 배포·확인하던 온프레미스 운영 절차가, AWS에서는 "보안 그룹·네트워크 ACL 규칙 하나를 고치는 것"으로 단순해집니다.

6. 관련 개념

VPC·서브넷·라우팅 테이블 — 보안 그룹과 네트워크 ACL이 동작하는 무대. 서브넷의 퍼블릭·프라이빗 구분, CIDR 블록 규칙은 별도로 다룬다.
NAT 게이트웨이·인터넷 게이트웨이 — 보안 그룹·네트워크 ACL이 트래픽을 허용해도, 그 트래픽이 인터넷과 오가려면 이 게이트웨이를 통한 경로가 라우팅 테이블에 있어야 한다.
ALB·NLB — 로드밸런서도 자체 보안 그룹을 갖는 리소스다. 헬스체크 트래픽이 백엔드 인스턴스의 보안 그룹·네트워크 ACL을 통과해야 정상 동작한다.
AWS Network Firewall — 보안 그룹·네트워크 ACL보다 더 정교한 트래픽 검사(침입 탐지·방지 등)가 필요할 때 쓰는 별도 서비스.
Reachability Analyzer — 두 리소스 사이의 연결이 왜 막히는지(라우팅·보안 그룹·네트워크 ACL 중 어디서 막히는지) 정적으로 분석해 주는 진단 도구.
IAM — 누가 보안 그룹·네트워크 ACL 규칙을 만들고 고칠 수 있는지를 통제하는 권한 체계.

7. 한눈에 정리

항목	확인할 것
적용 레벨	보안 그룹은 인스턴스, 네트워크 ACL은 서브넷
규칙 종류	보안 그룹은 allow만, 네트워크 ACL은 allow·deny 둘 다
평가 방식	보안 그룹은 전체 규칙 평가, 네트워크 ACL은 번호 순 평가 후 첫 매치에서 중단
리턴 트래픽	보안 그룹은 자동 허용(상태 유지), 네트워크 ACL은 별도로 허용해야 함(무상태)
소스 지정	보안 그룹은 다른 보안 그룹 ID를 소스로 참조 가능
서브넷 연결	서브넷 하나는 네트워크 ACL 하나에만 연결(미지정 시 기본 네트워크 ACL 자동 연결)
기본값	새 보안 그룹은 인바운드 없음·아웃바운드 전체 허용, 새 커스텀 네트워크 ACL은 인바운드·아웃바운드 전체 거부
기본 보안 그룹	삭제 불가, 규칙 수정만 가능
비용	둘 다 무료, 다만 규칙 개수·연결 개수에 할당량 있음
AWS 권장	보안 그룹을 주 방어선, 네트워크 ACL을 보조(2차) 방어선으로

이어서 보면 좋은 글

nohup / tmux 완벽 정리 — SSH가 끊기면 왜 백그라우느 작업까지 같이 죽는가

와우패널 — Mon, 31 Aug 2026 06:34:56 +0900

장시간 배포 스크립트를 백그라운드(&)로 돌려놓고 노트북을 덮었는데, 다시 접속해 보니 절반만 끝나 있습니다. 이 글은 그 이유를 man bash의 신호 처리 규칙으로 정확히 확인하고, nohup과 tmux가 그 문제를 서로 다른 방식으로 푸는 이유를 봅니다. 모든 출력은 Rocky Linux 9.7 · GNU bash 5.1.8 · coreutils 8.32 · tmux 3.2a에서 실행해서 그대로 붙였습니다.

금요일 저녁, 배포 서버. 새 버전 배포 스크립트가 실행에 시간이 좀 걸립니다.

① 터미널에 deploy.sh &로 띄워 놓고 자리를 비웠습니다. 노트북이 잠들었다가 VPN이 끊겼습니다. 다시 접속해 로그를 보니 중간까지만 있습니다.

② nohup을 걸었다고 알고 있던 동료의 스크립트도 어느 파이프라인에서는 중간에 끊깁니다. "분명 nohup을 붙였는데요"라는 말과 실제 로그가 안 맞습니다.

③ 급한 대로 Ctrl+Z로 멈췄다가 bg로 백그라운드에 보내고 disown까지 걸었는데도, 자동화 스크립트 안에서 실행한 것은 여전히 접속이 끊기면 죽습니다.

④ "그냥 tmux 쓰세요"라는 조언을 들었는데, 정작 tmux 서버 프로세스 자체가 죽었던 날엔 그 세션도 통째로 사라져 있습니다.

32편(ssh)은 접속이 안 되는 문제를 다뤘습니다 — Connection refused(즉시)와 timed out(대기)이 뜨는 순간을 -vv로 구분했습니다. 이 글은 그 바로 다음 문제입니다: 어렵게 접속해서 띄운 작업이, 그 접속이 끊기는 순간 같이 죽는 문제입니다. 위 네 가지가 겉으로는 전부 "백그라운드로 돌렸는데 죽었다"는 같은 증상이지만, 원인은 신호 하나(SIGHUP)가 누구에게 어떻게 전달되는가로 갈립니다 — ①②는 2~3장에서, ③은 시나리오 3에서, ④는 함정 5에서 각각 갈라 봅니다. 이 글은 그 신호를 직접 재현해서 보여주는 데서 시작합니다.

"백그라운드로 돌렸다"만으로는 안 끊깁니다. nohup은 신호 자체를 무시하게 만들고, tmux는 애초에 그 신호가 갈 세션 자체를 분리합니다 — 같은 증상, 다른 처방입니다

1. nohup·tmux가 하는 일 — 30초 요약

nohup = 프로세스가 SIGHUP을 무시하게 만드는 래퍼. tmux = 세션 자체를 터미널 접속과 분리된 별도 서버 프로세스로 옮기는 다중화 도구.

이름부터 이미 답을 담고 있습니다.

nohup  = no + hangup            "끊김을 무시한다"
tmux   = terminal multiplexer   "터미널을 여러 개로 나눈다"

man nohup NAME 절 그대로입니다.

"nohup - run a command immune to hangups, with output to a non-tty"
— man nohup

man tmux NAME·DESCRIPTION 절입니다.

"tmux — terminal multiplexer... tmux may be detached from a screen and continue running in the background, then later reattached."
— man tmux

두 줄의 차이가 그대로 두 도구의 성격을 가릅니다. nohup은 신호 하나를 막는 아주 작은 래퍼이고, tmux는 그 자체로 서버·클라이언트 구조를 가진 별도의 프로그램입니다.

tmux의 시작 — 2007년, "터미널을 여러 개로 나누는" 문제를 다시 씀

tmux가 패키징하는 문서(/usr/share/doc/tmux/CHANGES, EL9 baseos rpm)의 가장 오래된 항목입니다.

"09 July 2007" (날짜 다음 줄, 불릿 항목) "Initial import to CVS. Basic functions are working... Detaching, reattaching, creating new sessions, listing sessions work acceptably for using with shells."
— tmux 패키지 CHANGES

지은이는 man tmux AUTHORS 절에 그대로 남아 있습니다.

"Nicholas Marriott <nicholas.marriott@gmail.com>"
— man tmux, AUTHORS

터미널을 detach·reattach하는 문제 자체는 tmux가 처음 푼 게 아닙니다 — CHANGES 곳곳에 등장하는 비교 대상인 GNU screen이 먼저 이 자리를 차지하고 있던 도구입니다. 이 글은 screen을 다루지 않지만, 지금 서버에 screen이 이미 깔려 있어 익숙하다면 개념(세션·detach·reattach)은 그대로 옮겨 옵니다.

왜 이 도구인가

상황	이 도구 아닌 방법	왜 안 되나
배포 스크립트를 켜 놓고 접속을 끊어야 한다	`command &`만 사용	2장에서 보듯 `&`는 같은 세션 안에 남는 것일 뿐, 세션이 끊기는 순간 함께 죽습니다
이미 돌기 시작한 대화형 작업(vim, top, REPL)을 유지한 채 다른 창을 오가고 싶다	`nohup`	`nohup`은 신호만 막을 뿐 화면을 다시 보여주지 못합니다 — 표준입력이 필요한 대화형 작업엔 못 씁니다
여러 사람이 같은 작업 화면을 같이 보면서 인수인계해야 한다	각자 별도로 `ssh` 접속	각자 접속하면 화면이 따로입니다 — 한쪽이 명령을 쳐도 다른 쪽엔 안 보입니다. `tmux`는 같은 세션에 여러 클라이언트가 동시에 `attach`할 수 있어 화면을 그대로 공유하지만, 이 글은 단일 사용자 관점만 다룹니다

가장 단순한 형태

nohup 명령 [인자...] &
tmux new -s 세션이름

2. 기본기 — SIGHUP은 누구에게, 언제 가는가

2.1 SIGHUP 정의

man 7 signal이 번호와 정의를 함께 줍니다.

"SIGHUP ... Hangup detected on controlling terminal or death of controlling process"
— man 7 signal

11편(kill/시그널)이 이미 확인했듯 SIGHUP은 번호 1로, 어떤 아키텍처에서도 값이 안 바뀌는 세 신호(HUP 1 · KILL 9 · TERM 15) 중 하나입니다. 이 글은 그 신호가 실제로 언제, 누구에게 가는지를 봅니다.

이 글의 재현은 아래 준비만 마치면 전부 그대로 됩니다. 이후 나오는 모든 명령은 이 디렉터리 안에서 실행합니다.

mkdir -p ~/nohuplab && cd ~/nohuplab
[ -x ~/tmuxdoc/usr/bin/tmux ] || command -v tmux || { mkdir -p ~/tmuxdoc && cd ~/tmuxdoc && dnf download tmux --destdir=. -q --disablerepo='*' --enablerepo=baseos < /dev/null && rpm2cpio tmux-*.rpm | cpio -idm --quiet; cd ~/nohuplab; }
export PATH="$HOME/tmuxdoc/usr/bin:$PATH"
cat > ticker.sh <<'EOF'
#!/bin/bash
for i in $(seq 1 8); do echo "tick-$i"; sleep 1; done
EOF
chmod +x ticker.sh

이 검증 서버에는 tmux가 패키지로 설치돼 있지 않았습니다. dnf install은 sudo가 필요해서 쓰지 않았고, 대신 dnf download로 설치하지 않고 rpm 파일만 받아 rpm2cpio로 홈 안에 풀어 그 실행 파일을 직접 씁니다 — sudo 없이, 시스템 어디에도 손대지 않고 끝납니다. tmux가 이미 설치돼 있다면 command -v tmux가 성공해서 이 블록은 아무것도 안 하고 넘어갑니다. 접속이 중간에 끊겨 새 세션에서 이어 하는 경우엔 export PATH="$HOME/tmuxdoc/usr/bin:$PATH" 한 줄만 다시 치면 됩니다(다운로드는 이미 끝나 있어 다시 안 받습니다).

$ tmux -V
tmux 3.2a

2.2 `&`만으로는 왜 안 되나 — 커널이 직접 보내는 경로부터 봅니다

SIGHUP이 배경 job까지 가는 경로는 사실 둘입니다. ① 커널이 프로세스 그룹 전체에 직접 보내는 경로, ② 로그인 셸이 자기 job들에게 대신 재전송하는 경로(대화형 세션에만 해당 — 시나리오 3에서 자세히 봅니다). 여기서는 더 간단하고 항상 통하는 ①번부터 결정적으로 재현합니다.

운영 서버에서 실제로 SSH 연결을 반복해서 끊는 대신(그러려면 접속을 여러 번 다시 해야 해서 재현이 무거워집니다), 터미널이 끊길 때 커널이 보내는 것과 같은 신호를 setsid로 만든 별도 세션에 직접 보내서 재현합니다. setsid는 새 세션을 만들면서 그 프로세스를 자기 자신만의 새 프로세스 그룹 리더로 둡니다. 그 그룹 전체(-가 붙은 숫자는 프로세스 그룹 전체를 뜻합니다)에 SIGHUP을 보내면, 실제 접속이 끊길 때 터미널 드라이버가 그 세션에 하는 일과 같습니다.

$!가 아니라 echo $$ > outer.pgid로 그룹 번호를 직접 적어 둡니다 — 대화형 셸에서는 setsid가 "이미 그룹 리더인 프로세스"를 받으면 새 자식을 하나 더 fork하고 원래 프로세스(그 PID가 $!입니다)는 곧바로 끝나 버립니다. $!를 그대로 쓰면 이미 사라진 PID를 잡는 것이라, 신호를 보내도 아무 일도 안 일어납니다 — 세션 안에서 직접 자기 PID($$)를 적어야 정확한 번호를 잡습니다.

$ rm -f plain.pid plain.log
$ rm -f outer.pgid
$ setsid bash -c 'echo $$ > outer.pgid; sleep 60 > plain.log 2>&1 & echo $! > plain.pid; sleep 3' < /dev/null > /dev/null 2>&1 &
$ disown
$ sleep 1; kill -HUP -"$(cat outer.pgid)"; sleep 2
$ ps -p "$(cat plain.pid)" -o pid=,stat=,cmd= 2>&1 || echo "찾을 수 없음 — 죽었습니다"
찾을 수 없음 — 죽었습니다

&로 백그라운드에 둔 것만으로는 살아남지 못합니다. 이 재현은 bash -c(비대화형)라서 작업 제어(job control)가 켜지지 않고, 그래서 sleep이 setsid가 만든 셸과 같은 프로세스 그룹에 그대로 남습니다. 그 그룹 전체에 보낸 SIGHUP을 커널이 구성원 전부에게 직접 전달하므로, 셸이 뭘 하든 상관없이 죽습니다. ssh 서버 '명령 &'처럼 자동화 스크립트가 원격에서 비대화형으로 배경 작업을 걸 때 정확히 이 경로를 탑니다 — 함정 3에서 이 경로가 부르는 함정을 봅니다.

작업 제어가 꺼진 셸에서는 백그라운드 job이 셸과 같은 프로세스 그룹에 남습니다. 그 그룹 전체에 보낸 SIGHUP을 커널이 구성원 모두에게 직접 전달합니다 — nohup은 이 직접 전달 자체를 프로세스 스스로 무시하게 만듭니다

2.3 `nohup`이 다른 이유 — 신호 자체를 무시하게 만듭니다

$ rm -f nh.pid nh.log
$ rm -f outer.pgid
$ setsid bash -c 'echo $$ > outer.pgid; nohup sleep 60 > nh.log 2>&1 & echo $! > nh.pid; sleep 3' < /dev/null > /dev/null 2>&1 &
$ disown
$ sleep 1; kill -HUP -"$(cat outer.pgid)"; sleep 2
$ ps -p "$(cat nh.pid)" -o pid=,stat=,cmd=
2673271 S    sleep 60
$ kill -9 "$(cat nh.pid)"

같은 신호, 같은 프로세스 그룹인데 이번엔 살아남습니다. man nohup이 이유를 말해 줍니다 — nohup은 셸의 재전송을 피하는 게 아니라, 그 프로세스 자신이 SIGHUP을 아예 무시하도록 만듭니다.

"Run COMMAND, ignoring hangup signals."
— man nohup

이 차이가 이 글의 핵심입니다. disown(시나리오 3)은 "셸이 이 job에게 재전송하지 않도록" 셸의 장부만 바꾸는 것이고, nohup은 "이 프로세스는 애초에 그 신호를 받아도 반응하지 않는다"로 프로세스 자신을 바꾸는 것입니다. 셸이 없어져도, 재전송 경로가 뭐든 상관없이 살아남는 쪽은 후자입니다.

2.4 실제 터미널 접속에는 경로가 하나 더 있습니다 — 셸의 재전송

지금까지 재현한 것은 작업 제어가 꺼진 셸(비대화형 스크립트)의 경우입니다. 독자가 실제로 ssh 서버로 접속해 명령을 하나씩 치는 대화형 세션은 다릅니다 — 그 경우엔 작업 제어가 자동으로 켜져 있어 &로 보낸 job이 별도의 프로세스 그룹으로 옮겨지고, 그 덕분에 커널이 보내는 그룹 단위 SIGHUP(위 경로 ①)에서는 벗어납니다. 그런데도 접속이 끊기면 여전히 죽습니다 — man bash SIGNALS 절이 그 이유를 적어 둡니다.

"The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped."
— man bash, SIGNALS

로그인 셸 자신이 먼저 SIGHUP을 받고(터미널의 세션 리더이기 때문입니다), 죽기 전에 그 신호를 자기가 띄운 job들에게 그대로 다시 보냅니다. 커널의 직접 전달을 피해도 셸의 재전송까지는 못 피하는 것입니다 — 실제 접속 종료 실측으로 확인한 값입니다(이 재전송 여부는 접속을 실제로 강제 종료해야 드러나 결정적 재현 블록으로 신지 않았습니다). disown이 진짜로 의미를 가지는 곳이 정확히 여기입니다 — 시나리오 3에서 이 경로를 자세히 봅니다.

2.5 `tmux`는 아예 다른 층위입니다 — 세션을 서버로 옮깁니다

man tmux DESCRIPTION의 서버·클라이언트 구조를 설명하는 문단입니다.

"In tmux, a session is displayed on screen by a client and all sessions are managed by a single server. The server and each client are separate processes which communicate through a socket in /tmp."
— man tmux

nohup이 신호 하나를 막는 대응이라면, tmux는 애초에 그 신호가 갈 대상 자체를 분리합니다. SSH 세션(클라이언트)이 끊겨도 작업이 실제로 돌고 있는 곳은 별도로 계속 살아 있는 tmux 서버 프로세스이기 때문에, 클라이언트 쪽 SIGHUP은 서버에 있는 작업까지 갈 방법 자체가 없습니다. 이 차이는 시나리오 5에서 프로세스 트리로 직접 확인합니다.

3. 실전 시나리오 5가지

시나리오 1 — 배포 스크립트를 `&`로 띄우고 나왔는데 절반만 끝나 있다

앞서 2장에서 이미 원인을 확인했으니, 여기서는 정답과 그 근거를 정리합니다.

$ rm -f fix1.pid fix1.log
$ rm -f outer.pgid
$ setsid bash -c 'echo $$ > outer.pgid; nohup sleep 6 > fix1.log 2>&1 & echo $! > fix1.pid; sleep 2' < /dev/null > /dev/null 2>&1 &
$ disown
$ sleep 1; kill -HUP -"$(cat outer.pgid)"; sleep 1
$ ps -p "$(cat fix1.pid)" -o pid=,etimes=,cmd=
2673322       2 sleep 6
$ sleep 6; ps -p "$(cat fix1.pid)" 2>&1 || echo "정상 종료(끝까지 다 돌았습니다)"
    PID TTY          TIME CMD
정상 종료(끝까지 다 돌았습니다)

SIGHUP을 보낸 시점(경과 2초)에도 sleep 6이 멀쩡히 살아 있고, 남은 시간을 다 채운 뒤(6초 뒤) 정상 종료했습니다.

교훈: &는 "지금 화면을 막지 않겠다"는 뜻이지 "이 세션과 무관해지겠다"는 뜻이 아닙니다. 접속이 끊기는 순간까지 살아남아야 하는 작업이면 시작할 때부터 nohup을 붙입니다 — 이미 띄운 다음에 되돌리려면 함정 3의 제약을 먼저 확인해야 합니다.

시나리오 2 — 분명 `nohup`을 붙였는데도 로그가 중간에서 끊긴다

순진한 시도 — 파이프라인의 첫 명령에만 nohup을 붙입니다. ticker.sh는 앞서 준비한, 1초마다 한 줄씩 8초 동안 찍는 스크립트입니다.

$ rm -f pipe.log
$ rm -f outer.pgid
$ setsid bash -c 'echo $$ > outer.pgid; nohup ./ticker.sh | tee pipe.log & sleep 3' < /dev/null > /dev/null 2>&1 &
$ disown
$ sleep 3; kill -HUP -"$(cat outer.pgid)"; sleep 1
$ cat pipe.log
tick-1
tick-2
tick-3

8줄이 나와야 하는데 3줄에서 끊깁니다. nohup은 자기 뒤에 바로 오는 명령 하나에만 걸립니다. 파이프의 뒤쪽 명령(tee)은 nohup이 보호하지 않는 별도의 프로세스라서, 세션이 끊기면 tee가 먼저 SIGHUP으로 죽고, tee가 사라지면 앞쪽 명령도 SIGPIPE로 따라 죽습니다.

정답 — 파이프라인 전체를 하나의 명령으로 감싸서 그 전체에 nohup을 겁니다.

$ rm -f pipe2.log wrap.out
$ rm -f outer.pgid
$ setsid bash -c 'echo $$ > outer.pgid; nohup bash -c "./ticker.sh | tee pipe2.log" > wrap.out 2>&1 & sleep 1' < /dev/null > /dev/null 2>&1 &
$ disown
$ sleep 1; kill -HUP -"$(cat outer.pgid)"
$ sleep 9; cat pipe2.log
tick-1
tick-2
tick-3
tick-4
tick-5
tick-6
tick-7
tick-8

nohup bash -c "생성 | tee 로그"   ← tee까지 같은 bash -c 자식이라 통째로 보호됩니다
nohup 생성 | tee 로그             ← tee는 nohup 밖의 별도 job이라 못 지킵니다

교훈: nohup은 명령 하나를 감쌉니다. 파이프·&&로 이어진 다음 단계는 각자 별도의 프로세스이므로, 여러 단계를 전부 지키려면 그 전체를 bash -c "..."로 한 덩어리로 만든 다음 그 바깥에 nohup을 겁니다.

시나리오 3 — 이미 돌고 있는 걸 백그라운드로 보내고 `disown`까지 걸었다

Ctrl+Z로 멈췄던 작업을 bg로 이어 돌리고 disown까지 걸어 뒀는데, 어떤 환경에서는 되고 어떤 환경에서는 안 됩니다. 갈리는 기준을 봅니다.

$ rm -f d1.pid d1.log
$ rm -f outer.pgid
$ setsid bash -c 'echo $$ > outer.pgid; sleep 30 > d1.log 2>&1 & echo $! > d1.pid; disown -h %1; sleep 3' < /dev/null > /dev/null 2>&1 &
$ disown
$ sleep 1; kill -HUP -"$(cat outer.pgid)"; sleep 2
$ ps -p "$(cat d1.pid)" -o pid=,stat=,cmd= 2>&1 || echo "찾을 수 없음 — 죽었습니다"
찾을 수 없음 — 죽었습니다

man bash가 disown -h를 이렇게 정의합니다.

"If the -h option is given, each jobspec is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP."
— man bash, SHELL BUILTIN COMMANDS

"셸이 그 job에게 재전송하지 않는다"는 것이지, "그 job이 신호 자체를 안 받는다"는 게 아닙니다. 위 재현처럼 작업 제어(job control)가 켜지지 않은 셸(스크립트로 자동화된 세션이 대표적입니다)에서는 백그라운드로 보낸 job이 셸과 같은 프로세스 그룹에 그대로 남아, 커널이 그룹 전체에 보내는 SIGHUP을 셸의 장부와 무관하게 직접 맞습니다. disown이 지켜 주는 건 "셸이 다시 보내는 것"뿐이라, 애초에 셸을 거치지 않고 오는 이 경로는 못 막습니다.

실제로 터미널을 열어 명령을 하나씩 치는 대화형 세션은 다릅니다 — 그 경우엔 작업 제어가 자동으로 켜져 있어 &로 보낸 job이 별도의 프로세스 그룹으로 옮겨지고, 커널의 직접 신호에서 벗어납니다. 이때는 disown -h가 실제로 보호막이 됩니다(셸이 재전송만 안 하면 되니까요) — 실제 SSH 접속을 강제로 끊어(로컬 클라이언트를 죽여) 확인한 것으로, disown -h 없이는 죽고 걸어 두면 살아남는 것을 양쪽 다 재현했습니다. 다만 이 재현은 별도 네트워크 접속이 필요해 이 글의 결정적 재현 블록으로는 신지 않았습니다.

상황	작업 제어(job control)	`disown -h`가 막아 주는가
터미널에서 직접 타이핑하는 대화형 세션	켜짐(백그라운드 job이 별도 그룹)	막아 줍니다 — 셸의 재전송이 유일한 위협이기 때문입니다
`ssh 서버 '명령 &'`처럼 스크립트로 보내는 비대화형 세션	꺼짐(job이 셸과 같은 그룹)	못 막습니다 — 커널이 그룹 전체에 직접 보내기 때문입니다

교훈: 자동화 스크립트에서 원격으로 백그라운드 작업을 거는 경우라면 disown을 믿지 않습니다. nohup은 이 표의 두 상황 모두에서 통합니다 — 신호를 받는 셸이 몇 개를 거치든, 프로세스 자신이 무시하기 때문입니다.

시나리오 4 — `tmux`로 아예 세션을 분리한다

아래부터는 -L lab34로 이 글 전용 소켓을 씁니다. tmux kill-server는 그 소켓의 서버 전체를 끕니다 — 지금 이미 다른 작업으로 tmux를 쓰고 있다면, -L 없이 그냥 tmux kill-server를 치는 순간 그 세션들까지 전부 죽습니다. 이 글의 재현이 독자의 진짜 작업에 영향을 주지 않도록 소켓 이름부터 분리합니다.

$ tmux -L lab34 kill-server 2>/dev/null; rm -f tmux_work.log
$ tmux -L lab34 new-session -d -s deploy
$ tmux -L lab34 send-keys -t deploy './ticker.sh >> tmux_work.log' Enter
$ tmux -L lab34 list-sessions
deploy: 1 windows (created Sun Aug 23 16:15:00 2026)

이 시점부터 접속이 끊겨도 상관없습니다. tmux 세션 자체는 SSH 접속과 별개의 프로세스이므로, 실제로 노트북을 덮든 네트워크가 끊기든 영향이 없습니다. 8초 뒤(ticker.sh가 끝날 시간)에 다시 확인합니다.

$ sleep 9
$ tmux -L lab34 list-sessions
deploy: 1 windows (created Sun Aug 23 16:15:00 2026)
$ cat tmux_work.log
tick-1
tick-2
tick-3
tick-4
tick-5
tick-6
tick-7
tick-8

man tmux EXAMPLES 절이 이 흐름을 그대로 요약합니다.

"A session may be detached using 'C-b d' (or by an external event such as ssh(1) disconnection) and reattached with: $ tmux attach-session"
— man tmux, EXAMPLES

Ctrl+b d(의도적 detach)와 "SSH 연결이 끊김"(사고성 hangup)을 매뉴얼이 같은 문장에서 나란히 다룹니다. tmux 입장에서는 둘이 사실상 같은 이벤트이기 때문입니다 — 클라이언트가 사라졌을 뿐, 서버(그리고 그 안의 작업)는 계속 돕니다. 화면으로 돌아가려면 이렇게 씁니다.

tmux -L lab34 attach -t deploy

이렇게 붙었다면, 다음 절로 넘어가기 전에 Ctrl+b d로 다시 빠져나옵니다. 붙은 채로 다음 명령(세션을 끄는 명령이 곧 나옵니다)을 그 안에서 치면 자기 자신의 화면을 끄는 셈이 됩니다.

시나리오 5 — 교차검증: 두 도구가 정말 다른 메커니즘인지 부모 프로세스로 확인한다

nohup으로 살아남은 프로세스는 원래 부모(로그인 셸)가 죽었으니 새 부모가 필요합니다. 리눅스는 고아 프로세스를 PID 1(이 서버는 systemd)에게 입양시킵니다.

$ rm -f orphan.pid orphan.log
$ rm -f outer.pgid
$ setsid bash -c 'echo $$ > outer.pgid; nohup sleep 30 > orphan.log 2>&1 & echo $! > orphan.pid; sleep 2' < /dev/null > /dev/null 2>&1 &
$ disown
$ sleep 1; kill -HUP -"$(cat outer.pgid)"; sleep 2
$ ps -o pid=,ppid=,cmd= -p "$(cat orphan.pid)"
2673697       1 sleep 30
$ kill -9 "$(cat orphan.pid)"

PPID가 1입니다 — 원래 부모였던 로그인 셸이 사라지자 커널이 즉시 이 프로세스를 PID 1에게 입양시켰습니다. 부모가 먼저 죽은 자식은 init(PID 1)이 다시 부모가 되어 나중에 좀비를 거둡니다.

tmux 세션 안의 프로세스는 다릅니다.

$ tmux -L lab34 kill-server 2>/dev/null
$ tmux -L lab34 new-session -d -s probe 'sleep 30'
$ sleep 1
$ PANE_PID=$(tmux -L lab34 list-panes -t probe -F '#{pane_pid}'); ps -o pid=,ppid=,cmd= -p "$PANE_PID"
2709472 2709471 sleep 30
$ ps -o pid=,cmd= -p "$(ps -o ppid= -p "$PANE_PID" | tr -d ' ')"
2709471 tmux -L lab34 new-session -d -s probe sleep 30
$ tmux -L lab34 kill-server

부모가 1이 아니라 여전히 tmux 서버 프로세스입니다. nohup은 "고아가 되고도 살아남는" 방식이고, tmux는 "애초에 로그인 셸의 자식이 아니라 서버의 자식으로 태어나는" 방식입니다 — 두 도구가 같은 증상(접속이 끊겨도 산다)을 완전히 다른 층위에서 풉니다.

같은 결과(접속이 끊겨도 산다)를 만드는 두 가지 다른 부모-자식 경로입니다. nohup은 고아가 됐다가 입양되고, tmux는 처음부터 서버의 자식입니다

4. 함정 코너 — "분명히 살려놨는데" 여섯 가지

함정 1. `nohup.out`이 어디 생겼는지 못 찾는다

출력 리다이렉션 없이 nohup만 쓰면, 그 출력이 어디로 가는지는 현재 디렉터리가 쓰기 가능한가에 달렸습니다. (script -qc "..." /dev/null은 표준출력을 진짜 터미널처럼 보이게 만드는 용도로만 씁니다 — nohup의 아래 분기가 "표준출력이 터미널일 때"에만 적용되기 때문입니다.)

⚠️ 아래 블록은 ~/nohup.out을 지웠다가 다시 만듭니다 — 그 자리에 이미 진짜 nohup 작업의 로그가 있다면 먼저 다른 이름으로 옮겨 둡니다(mv ~/nohup.out ~/nohup.out.bak).

$ mkdir -p readonly && chmod 555 readonly && cd readonly
$ rm -f ~/nohup.out
$ script -qc "nohup sleep 1" /dev/null < /dev/null
nohup: ignoring input and appending output to '/home/wowpanel/nohup.out'
$ ls -la ~/nohup.out
-rw-------. 1 wowpanel wowpanel 0  8월 23 16:15 /home/wowpanel/nohup.out
$ cd .. && chmod 755 readonly && rm -rf readonly ~/nohup.out

man nohup이 정확히 이 순서를 적어 둡니다.

"If standard output is a terminal, append output to 'nohup.out' if possible, '$HOME/nohup.out' otherwise."
— man nohup

현재 디렉터리에 쓰기 권한이 없으면 조용히 $HOME으로 넘어갑니다 — 에러가 아니라 안내 메시지 한 줄로만 알려 줍니다. 로그가 안 보이면 실행하던 디렉터리가 아니라 홈부터 확인합니다.

디스크 어디에 쌓이는지 모르는 로그를 만들지 않으려면, 애초에 nohup 명령 > 원하는경로.log 2>&1 &로 목적지를 직접 지정합니다.

함정 2. `nohup.out`은 언제나 600 — 다른 계정과 공유가 안 된다

$ umask
0022

$ mkdir -p ro2 && chmod 555 ro2
$ for u in 0022 0077 0400; do (cd ro2; umask $u; script -qc "nohup sleep 1" /dev/null < /dev/null >/dev/null; stat -c '%a' ~/nohup.out; rm -f ~/nohup.out); done
600
600
600
$ chmod 755 ro2 && rm -rf ro2

umask를 0022·0077·심지어 더 좁게 깎는 0400으로 바꿔도 nohup.out은 항상 600입니다. 일반적인 umask 산수(요청한 모드에서 umask 비트를 빼는 것)라면 0400일 때 200이 나와야 하는데 그렇지 않습니다 — nohup이 이 파일을 열 때 umask 자체를 일시적으로 자신이 원하는 값으로 바꿔치기했다가 되돌리기 때문입니다. 배포 로그를 다른 계정(모니터링 봇 등)이 읽어야 한다면 nohup.out에 의존하지 말고 리다이렉션 경로를 직접 지정한 뒤 별도로 권한을 맞춥니다.

함정 3. `disown`을 걸었는데도 원격 자동화에서는 죽는다

시나리오 3에서 이미 확인했습니다. "직접 접속해서 손으로 확인했을 때는 됐는데, CI/배치 스크립트에 넣었더니 죽는다"는 보고가 오면 이 함정입니다. 자동화 스크립트가 ssh 서버 '명령 & disown' 형태로 원격 백그라운드 작업을 거는 순간, 그 셸은 작업 제어가 꺼진 비대화형 셸이라 disown의 보호가 안 먹습니다. 이런 경로에는 처음부터 nohup을 씁니다.

함정 4. `huponexit`이 켜진 서버에서는 그냥 `exit`만 쳐도 죽는다

지금까지의 재현은 전부 "연결이 예기치 않게 끊기는" 경우(로그인 셸이 SIGHUP을 받는 경우)였습니다. bash에는 이것과 별개로, 정상적으로 exit를 쳐서 로그아웃할 때도 job을 정리하는 옵션이 있습니다.

$ shopt huponexit
huponexit       off

"huponexit — If set, bash will send SIGHUP to all jobs when an interactive login shell exits."
— man bash, SHELL BUILTIN COMMANDS(shopt)

이 서버는 기본값(꺼짐)이라 exit로 정상 로그아웃하는 것만으로는 job이 안 죽습니다 — 접속이 끊길 때 죽는 건 이 옵션 때문이 아니라 2장에서 본 "셸이 SIGHUP을 받으면 재전송한다"는 규칙 때문입니다. 하지만 shopt -s huponexit로 이 옵션을 켠 로그인 셸(원격 배포용 계정에 이렇게 설정해 둔 곳이 있습니다)에서는 일부러 얌전히 exit를 쳐도 백그라운드 job이 함께 죽습니다. 서버를 옮겨 다니는 운영자라면 새 서버에서 이 값부터 한 번 확인해 두는 편이 안전합니다.

함정 5. `tmux` 세션은 로그 파일이 안 남고 통째로 사라진다

nohup은 죽어도 최소한 그때까지의 출력이 로그 파일로 남습니다. tmux는 다릅니다 — 세션은 메모리에만 있는 서버 프로세스의 상태이므로, 서버가 재부팅되거나 tmux 서버 프로세스 자체가 죽으면(OOM Killer에 잡히는 경우도 포함, 15편 참고) 그 세션 안에서 실행 중이던 작업의 화면 내용까지 전부 사라집니다.

아래는 tmux 서버 프로세스 자체를 죽이는 재현입니다. -L lab34(이 글 전용 소켓)로 격리했는데도 굳이 다시 적어 두는 이유는, 이 조작을 기본 소켓에 그대로 했다가는 지금 그 계정의 다른 tmux 세션까지 전부 같이 죽기 때문입니다. 절대 -L 없이 시도하지 않습니다.

$ tmux -L lab34 new-session -d -s willvanish 'sleep 30'; sleep 1
$ VPID=$(tmux -L lab34 list-panes -t willvanish -F '#{pane_pid}'); SPID=$(ps -o ppid= -p "$VPID" | tr -d ' '); kill -9 "$SPID"
$ sleep 1; tmux -L lab34 list-sessions 2>&1
no server running on /tmp/tmux-1000/lab34

tmux 서버 프로세스 하나를 죽이자 세션 자체가 통째로 사라졌습니다. 정말 중요한 장시간 작업이면 화면을 유지해 주는 tmux에만 기대지 말고, nohup처럼 파일로도 로그를 남깁니다(tmux 안에서 명령 | tee 로그를 쓰면 둘 다 챙길 수 있습니다).

함정 6. 다른 계정으로 붙었더니 방금 만든 `tmux` 세션이 안 보인다

$ tmux -L testsock new-session -d -s hidden 'sleep 5'
$ tmux -L testsock list-sessions
hidden: 1 windows (created Sun Aug 23 16:15:16 2026)
$ tmux -L lab34 list-sessions 2>&1
no server running on /tmp/tmux-1000/lab34
$ tmux -L testsock kill-server 2>/dev/null

같은 계정, 같은 서버인데도 소켓 이름(-L)이 다르면 서로 안 보입니다 — lab34 소켓에서 보면 방금 testsock에 만든 hidden 세션이 아예 없는 것처럼 나옵니다. man tmux가 소켓 위치를 명시합니다.

"the sockets are all created in a directory tmux-UID under the directory given by TMUX_TMPDIR or in /tmp."
— man tmux, DESCRIPTION(-L)

기본 소켓 디렉터리 이름에 UID가 그대로 들어갑니다(/tmp/tmux-1000). su나 sudo -u로 다른 계정이 되어 tmux attach를 치면 그 계정의 UID로 된 다른 디렉터리를 보게 되어, 방금 만든 세션이 "없다"고 나옵니다 — 지워진 게 아니라 다른 서랍을 열어 본 것입니다.

5. 심화 — systemd 서비스라면 이 글은 안 통합니다

이 글의 모든 재현은 로그인 셸의 SSH 세션 관점입니다. 29편(systemctl)이 이미 확정해 둔 것이 있습니다.

setsid · nohup · disown은 systemd가 관리하는 유닛에서 프로세스를 cgroup 밖으로 못 뺀다 — systemd가 추적·종료 대상으로 삼는 건 이름이나 부모 관계가 아니라 cgroup이기 때문이다.

이 글의 nohup/tmux는 "로그인 셸이 사라져도 프로세스가 산다"는 문제를 풉니다. 반면 systemctl stop이 보내는 신호는 SSH 연결 여부와 무관하게 그 유닛의 cgroup 전체로 갑니다 — nohup으로 신호를 무시하게 만들어 놔도, tmux 세션 안에서 띄워 놔도 KillMode 기본값(control-group)인 systemd 서비스는 여전히 그 안에서 죽습니다. "터미널이 끊겨도 산다"와 "서비스 관리자가 내려도 산다"는 완전히 다른 질문이고, 후자는 이 글이 아니라 29편의 영역입니다. 배포 스크립트가 systemd 유닛으로 관리되고 있다면, 지금 필요한 건 nohup이 아니라 systemd-run이나 별도 유닛 파일입니다.

6. 치트시트 · 장애 대응 5분 루틴

접속을 끊어야 하는데 작업이 안 끝났을 때

① 아직 시작 전이면 → nohup 명령 > 로그 2>&1 &로 처음부터 띄웁니다. 파이프가 있으면 nohup bash -c "명령 | tee 로그" &처럼 전체를 감쌉니다.

② 이미 대화형으로 돌고 있으면 → Ctrl+Z → bg → disown -h. 단, 이 경로가 지금 대화형 세션인지 먼저 확인합니다(자동화 스크립트 안이면 안 통합니다 — 함정 3).

③ 화면도 계속 봐야 하거나 여러 창이 필요하면 → tmux new -s 이름으로 처음부터 그 안에서 작업합니다. 로그 파일은 별도로 챙깁니다(함정 5).

여기까지 해서도 접속이 끊기면 작업이 죽는다면, 그건 이 글의 영역이 아니라 systemd 유닛의 KillMode 문제입니다.

복사해서 붙여 두고 쓰는 명령

# ── 지금 바로 백그라운드로 안전하게 ──────────────
nohup 명령 > ~/작업.log 2>&1 &
echo "PID: $!"

# ── 파이프 전체를 지키기 ──────────────
nohup bash -c "명령1 | 명령2 > ~/작업.log" &

# ── tmux 세션 관리 ──────────────
tmux new -s 이름 # 새 세션
tmux ls # 세션 목록
tmux attach -t 이름 # 재접속
tmux kill-session -t 이름 # 세션 종료

# ── 지금 이 셸의 huponexit 확인 ──────────────
shopt huponexit

옵션 한 장 요약

명령	무엇을 하나
`nohup 명령 &`	이 명령 하나가 `SIGHUP`을 무시하게 만듭니다
`disown -h %1`	대화형 세션에서만, 셸이 그 job에 재전송하지 않게 합니다
`tmux new -s 이름`	새 세션을 만들고 그 안에서 작업을 시작합니다
`tmux new -d -s 이름 '명령'`	화면에 붙지 않고 바로 백그라운드로 세션을 만듭니다
`tmux attach -t 이름`	접속이 끊겼던 세션 화면으로 돌아갑니다
`tmux ls`	지금 서버에 떠 있는 세션 목록
`shopt huponexit`	정상 `exit`만으로도 job을 죽일지 여부

실습 정리

$ tmux -L lab34 kill-server 2>/dev/null; tmux kill-server 2>/dev/null
$ cd ~ && rm -rf ~/nohuplab ~/tmuxdoc

마무리

nohup과 tmux는 증상은 같지만(접속이 끊겨도 작업이 산다) 해법의 층위가 다릅니다. nohup은 신호 하나를 프로세스 스스로 무시하게 만드는 가장 가벼운 방법이고, tmux는 세션 자체를 별도 서버로 옮겨 화면까지 통째로 보존하는 더 무거운(그리고 그만큼 더 강력한) 방법입니다.

오늘 다룬 것 중 딱 세 가지만 가져가신다면 이겁니다.

&만으로는 접속이 끊기는 순간 함께 죽습니다 — 작업 제어가 꺼진 셸에서는 커널이 프로세스 그룹 전체에 SIGHUP을 직접 보내고, 대화형 셸에서도 자신이 받은 SIGHUP을 job 전체에 재전송합니다(man bash SIGNALS) — 경로는 둘이지만 결과는 같습니다.
nohup은 파이프의 첫 명령에만 걸리고, disown은 작업 제어가 켜진 대화형 세션에서만 통합니다 — 자동화 스크립트라면 전체를 감싼 nohup이 가장 안전합니다.
tmux는 세션을 별도 서버로 옮기는 것이라 화면째 보존되지만, 그 서버가 죽으면(재부팅 포함) 로그 없이 통째로 사라집니다 — 중요한 작업은 파일 로그도 같이 남깁니다.

"접속이 끊겨도 산다"는 같은 목표를 세 가지 다른 층위에서 풉니다. 어느 것도 다른 것의 상위 호환이 아니라, 문제가 어느 층위에 있는지에 따라 골라야 합니다

이 글로 리눅스/인프라 운영 연재를 마칩니다. grep으로 시작해 awk, sed, ps, top, strace, systemctl, ssh를 거쳐 여기까지, 명령 하나당 글 하나로 32편을 썼습니다(번호는 34까지 갔지만, 검증 서버가 raw socket을 막아 재현이 안 됐던 tcpdump와 아래 두 가지가 로드맵에서 빠져 32편입니다). 처음 계획에는 리다이렉션(>, 2>&1, tee)과 uptime/last/w도 있었지만, 연재가 길어져 이 글을 마지막으로 매듭짓기로 했습니다. 다루지 못한 것들은 이미 다룬 32편 안에서도 조각조각 만나셨을 겁니다 — 2>&1은 이 글의 시나리오 2에서, w가 보여주는 정보의 절반은 ps·top편에서 이미 지나왔습니다.

읽어 주셔서 감사합니다.

참고

man nohup
man bash — SIGNALS · JOB CONTROL · SHELL BUILTIN COMMANDS(disown·shopt)
tmux 패키지 CHANGES(/usr/share/doc/tmux/CHANGES)
man tmux
man 7 signal
tmux 공식 저장소

이어서 보면 좋은 글

VPC — 온프레미스 사내망 설계 감각으로 읽는 AWS의 가상 네트워크

와우패널 — Mon, 31 Aug 2026 00:28:32 +0900

온프레미스에서 사내망을 설계할 때는 코어 스위치에서 VLAN을 나누고, 서브넷마다 게이트웨이를 두고, 인터넷으로 나가는 구간에는 방화벽을 세웁니다. AWS에서 EC2 인스턴스를 띄우기 전에도 똑같은 결정이 필요합니다 — 다만 물리 장비 대신 VPC라는 논리적인 네트워크를 먼저 설계해야 합니다. 이름 그대로 "가상 사설 클라우드"이지만, CIDR(Classless Inter-Domain Routing — 10.0.0.0/16처럼 IP 대역의 범위를 표기하는 방식, 사내망의 서브넷 마스크 표기와 같은 역할) 로 지정한 IP 대역을 나중에 넓힐 수 없다거나 서브넷이 특정 위치에 고정된다거나 하는, 물리 네트워크에서는 신경 쓰지 않던 제약이 있습니다. 이 글은 VPC가 정확히 무엇이고, 사내망을 설계해 본 사람이 이걸 처음 만졌을 때 어디서 헷갈리는지를 다룹니다.

사내망에서 코어 스위치로 VLAN을 나누고 서브넷마다 방화벽 정책을 걸어 온 네트워크 관리자가 이번 프로젝트에서 VPC를 처음부터 설계하게 됐다. CIDR을 10.0.0.0/24로 작게 잡았는데, 몇 달 뒤 서브넷이 모자라 대역을 넓히려 하니 콘솔에서 막힌다. 그리고 "일단 되나 보자"며 기본 제공되는 VPC에 테스트 서버를 하나 올렸는데, 나중에 보니 인터넷에서 그대로 접근되는 상태였다. "사내망에서는 안 이랬는데"라는 질문에서 시작한다.

이 글은 실제 AWS 콘솔 화면이나 CLI 실행 결과를 캡처하지 않습니다. CIDR 블록 크기 규칙, 서브넷과 가용 영역의 관계, 퍼블릭·프라이빗 서브넷을 가르는 기준, 기본 VPC의 구성, 보안 그룹의 동작 방식처럼 이 글이 다루는 사실 하나하나는 전부 AWS 공식 문서(Amazon VPC User Guide)를 직접 열어 원문을 대조한 것입니다. 정확한 가격은 리전과 시점에 따라 바뀌므로, 구체적인 숫자보다 "무엇이 과금 대상이고 무엇이 아닌가"에 초점을 둡니다.

1. VPC가 정확히 뭔가

AWS 공식 문서는 VPC를 이렇게 정의합니다.

"With Amazon Virtual Private Cloud (Amazon VPC), you can launch AWS resources in a logically isolated virtual network that you've defined. This virtual network closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of AWS."

온프레미스에서 직접 설계·운영하던 사내망을 논리적으로 그대로 옮겨 놓은 것에 가깝습니다. 다만 AWS 문서가 나열하는 핵심 구성 요소를 보면 사내망과 매핑되는 지점이 분명해집니다.

"Subnets: A subnet is a range of IP addresses in your VPC... Routing: Use route tables to determine where network traffic from your subnet or gateway is directed... Gateways and endpoints: A gateway connects your VPC to another network. For example, use an internet gateway to connect your VPC to the internet... Peering connections: Use a VPC peering connection to route traffic between the resources in two VPCs."

서브넷(IP 대역을 나눈 것)·라우팅 테이블(트래픽을 어디로 보낼지)·게이트웨이(다른 네트워크와의 연결점)·피어링(VPC끼리의 연결) — 사내망을 설계할 때 다루던 개념과 이름만 다를 뿐 역할은 같습니다. 그리고 VPC는 리전 하나에 종속됩니다 — 계정을 만들면 리전마다 기본 VPC가 하나씩 자동으로 생깁니다.

"Your AWS account includes a default VPC in each AWS Region."

2. 온프레미스 대응표

같은 물건이 아니라 "가장 가까운 것"입니다. 대응시켜 놓고 다른 점을 무시하면 3·4장에서 다루는 오해로 바로 이어집니다.

온프레미스	AWS	같은 점	다른 점
사내망 전체 설계	VPC	논리적으로 격리된 네트워크	리전 하나에 종속(1장)
VLAN	서브넷	IP 대역을 나눈 구획	가용 영역 하나에 고정(3장)
코어 스위치의 라우팅 테이블	(VPC) 라우팅 테이블	트래픽 목적지 결정	서브넷마다 자동으로 하나씩 연결(3장)
인터넷 경계 라우터	인터넷 게이트웨이(IGW)	인터넷으로 나가는 관문	라우팅 테이블에 경로가 있어야 실제로 열림(3장)
DMZ / 내부망 구분	퍼블릭 서브넷 / 프라이빗 서브넷	인터넷 노출 여부로 구획	물리 분리가 아니라 라우팅 설정 차이(3장)
사내망 IP 대역 설계(고정)	VPC CIDR 블록	처음에 크게 잡아야 함	기존 블록 크기 변경 자체가 불가능(3장)
사이트 간 전용선·VPN	Direct Connect·Site-to-Site VPN	원격 네트워크 연결	이 글에서는 존재만 언급(6장)
방화벽 규칙	보안 그룹·네트워크 ACL	트래픽 허용/차단	이 글에서는 깊이 다루지 않음(6장)

3. 실무에서 반드시 알아야 하는 것

CIDR 블록은 처음 크기가 사실상 최종 크기다

AWS 공식 문서는 VPC의 IPv4 CIDR 블록 규칙을 이렇게 명시합니다.

"When you create a VPC, you must specify an IPv4 CIDR block for the VPC. The allowed block size is between a /16 netmask (65,536 IP addresses) and /28 netmask (16 IP addresses)."

그리고 크기 변경에 대해서는 이렇게 못 박습니다.

"You cannot increase or decrease the size of an existing CIDR block."

온프레미스에서 사내망 대역이 부족해지면 스위치 설정을 바꿔 서브넷 마스크를 조정하는 것도 가능했지만, VPC는 한번 만든 CIDR 블록의 크기 자체를 바꿀 수 없습니다. 대신 추가 CIDR 블록을 붙이는 것(/28~/16 범위 안에서, 기존과 겹치지 않게)은 가능합니다. 도입부 시나리오에서 /24(256개 주소)로 작게 잡았다가 막힌 것이 바로 이 제약입니다 — 부족하면 새 대역을 추가하는 것이지, 기존 /24를 /20으로 넓히는 것 자체가 불가능합니다. 그래서 실무에서는 처음부터 여유 있게(/16 쪽으로) 잡아 두는 것이 정석입니다.

서브넷은 가용 영역 하나에 고정된다

AWS 공식 문서는 서브넷의 기본 제약을 이렇게 설명합니다.

"A subnet is a range of IP addresses in your VPC... Each subnet must reside entirely within one Availability Zone and cannot span zones."

VLAN을 스위치 설정만 바꾸면 다른 랙, 다른 층으로 유연하게 옮길 수 있던 것과 달리, 서브넷은 만들 때 지정한 가용 영역(AZ, Availability Zone — 물리적으로 분리된 데이터센터 단위)에 그대로 고정됩니다. 다른 AZ로 옮기려면 그 AZ에 새 서브넷을 만들고 리소스를 재배치해야 합니다. VPC 전체가 여러 AZ에 걸쳐 있더라도, 그 안의 서브넷 하나하나는 각각 AZ 하나씩만 담당합니다.

퍼블릭 서브넷과 프라이빗 서브넷은 물리적 차이가 아니라 라우팅 설정 차이다

AWS 공식 문서는 서브넷 유형을 라우팅 기준으로 정의합니다.

"The subnet type is determined by how you configure routing for your subnets... Public subnet – The subnet has a direct route to an internet gateway. Resources in a public subnet can access the public internet. Private subnet – The subnet does not have a direct route to an internet gateway."

온프레미스의 DMZ는 보통 물리적으로 별도 스위치·별도 방화벽 인터페이스로 분리하지만, VPC의 퍼블릭·프라이빗 구분은 순전히 그 서브넷에 연결된 라우팅 테이블에 인터넷 게이트웨이로 가는 경로가 있는지로 갈립니다. 서브넷 자체에는 "이건 퍼블릭, 이건 프라이빗"이라는 물리적 표식이 없습니다 — 라우팅 테이블의 경로 하나가 그 서브넷의 성격을 결정합니다. 그리고 서브넷 라우팅은 이렇게 동작합니다.

"Each subnet must be associated with a route table, which specifies the allowed routes for outbound traffic leaving the subnet. Every subnet that you create is automatically associated with the main route table for the VPC."

서브넷을 새로 만들면 별도로 지정하지 않는 한 자동으로 VPC의 메인 라우팅 테이블에 연결됩니다. 이 메인 라우팅 테이블에 인터넷 게이트웨이 경로가 있는지 없는지가, 그 서브넷이 프라이빗인지 퍼블릭인지를 가르는 실질적인 기준입니다.

시나리오 — 온프레미스 IP 대역 설계를 그대로 옮긴다면

사내망에서 본사 10.0.0.0/16, 부서별 VLAN을 /24로 쪼개 쓰던 조직이 AWS로 전환하면서 같은 감각으로 VPC를 설계한다고 가정합니다.

VPC CIDR부터 여유 있게 잡는다. 나중에 크기를 못 바꾸므로(위 사실), 당장 필요한 서버 수만 보고 작게 잡지 않고 /16(65,536개 주소) 근처로 시작합니다. 온프레미스에서 본사 대역을 /16으로 잡던 것과 같은 이유입니다 — 조직이 커질 걸 감안한 여유입니다.
AZ 개수만큼 서브넷을 쪼갠다. 서브넷이 AZ 하나에 고정되므로(위 사실), 최소한 사용할 AZ 개수만큼 서브넷이 필요합니다. 흔한 패턴은 AZ마다 퍼블릭 서브넷 하나, 프라이빗 서브넷 하나를 두는 것입니다 — 부서별 VLAN을 나누던 감각을 "AZ별 + 용도별"로 확장한 것에 가깝습니다.
부서 대신 용도로 나눈다. 온프레미스에서는 부서(영업팀·개발팀)로 VLAN을 나누는 경우가 많지만, VPC 서브넷은 보통 역할(웹 서버용 퍼블릭 서브넷, DB용 프라이빗 서브넷)로 나눕니다. 인터넷 노출 여부가 곧 서브넷 구분 기준이라는 3장의 원칙과 맞닿아 있습니다.
라우팅 테이블로 성격을 확정한다. 퍼블릭으로 쓸 서브넷의 라우팅 테이블에만 인터넷 게이트웨이 경로를 추가합니다. 이 경로 하나가 그 서브넷을 "퍼블릭"으로 만드는 전부입니다 — 별도 물리 배선이 필요한 게 아닙니다.

CIDR 크기와 AZ 배치는 나중에 되돌리기 어려운 결정이라는 점에서, 온프레미스의 사내망 설계만큼(혹은 그 이상으로) 처음에 신중해야 하는 단계입니다.

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "VPC CIDR이 좁으면 나중에 넓히면 되지"

거꾸로입니다. 이미 만든 CIDR 블록은 크기를 늘리거나 줄일 수 없습니다(3장) — 부족하면 새 CIDR 블록을 추가하는 방식으로만 대응할 수 있고, 그마저도 기존 블록과 겹치지 않아야 합니다. 온프레미스에서 스위치 설정으로 서브넷 마스크를 넓히던 유연함이 VPC에는 없습니다. 처음 설계 단계에서 여유 있게 잡는 것이 사실상 유일한 대응책입니다.

오해 2. "서브넷도 나중에 다른 위치로 옮기면 되지"

서브넷은 만들 때 지정한 가용 영역에 고정됩니다(3장). VLAN을 스위치 설정 변경만으로 다른 랙에 옮기던 감각과 다릅니다 — 다른 AZ로 옮기려면 그 AZ에 새 서브넷을 만들고 리소스를 재배치해야 합니다.

오해 3. "프라이빗 서브넷은 물리적으로 격리돼 있으니 더 안전하겠지"

방향은 맞지만 근거를 잘못 짚은 오해입니다. 프라이빗 서브넷이 안전한 이유는 물리적 격리가 아니라, 그 서브넷의 라우팅 테이블에 인터넷 게이트웨이로 가는 경로가 없기 때문입니다(3장). 만약 실수로 그 라우팅 테이블에 인터넷 게이트웨이 경로를 추가하면, 서브넷 이름이 "프라이빗"이어도 그 순간부터 퍼블릭처럼 동작합니다. 이름표가 아니라 라우팅 테이블의 실제 내용을 확인해야 합니다.

오해 4. "기본 제공되는 VPC를 그냥 쓰면 무난하겠지"

AWS 공식 문서는 기본 VPC의 구성을 이렇게 설명합니다.

"A default VPC comes with a public subnet in each Availability Zone, an internet gateway, and settings to enable DNS resolution."

기본 VPC의 서브넷은 전부 퍼블릭입니다 — 빠르게 시작할 수 있도록 처음부터 인터넷 게이트웨이 경로가 걸려 있는 구성입니다. 온프레미스에서 "기본값이니까 무난하게 안전할 것"이라는 감각으로 접근하면 안 됩니다. 도입부 시나리오에서 테스트 서버가 인터넷에 그대로 노출된 이유가 이것입니다 — 프로덕션 워크로드는 보통 프라이빗 서브넷을 포함해 VPC를 직접 설계하는 쪽을 권장합니다.

오해 5. "VPC도 유료 서비스니까 안 쓰면 비용이 나가겠지"

거꾸로입니다. AWS 공식 문서는 이렇게 명시합니다.

"There's no additional charge for using a VPC."

VPC 자체, 서브넷, 라우팅 테이블, 보안 그룹은 만들어 두는 것만으로는 비용이 발생하지 않습니다. 비용은 그 안에 얹는 컴포넌트(NAT 게이트웨이, 퍼블릭 IPv4 주소 등)에서 발생합니다. 자세한 내용은 5장에서 다룹니다.

시나리오 — 서로 다른 리전의 VPC를 하나로 묶으려 한다

두 리전(예: 서울·도쿄)에 각각 VPC를 만들어 애플리케이션을 이중화한 뒤, 두 VPC 안의 서버가 서로 사설 IP로 직접 통신하게 만들려는 요청이 들어옵니다. 담당자는 "VPC 하나에 리전 두 개를 걸치도록 서브넷만 추가하면 되겠지"라고 생각하고 콘솔에서 리전을 바꿔 서브넷을 추가하려 하지만, 애초에 다른 리전에서는 그 VPC 자체가 보이지 않습니다.

원인은 1장에서 확인한 그대로입니다 — VPC는 리전 하나에 종속되는 자원이라, 서울 리전에서 만든 VPC는 도쿄 리전에 존재하지 않습니다. 사내망에서 본사와 지사를 전용선으로 묶어 하나의 IP 대역처럼 쓰던 것과 달리, VPC는 애초에 리전을 넘어 확장되는 개념이 아닙니다.

당장 취할 조치는 VPC 피어링을 검토하는 것입니다. 두 리전 각각에 VPC를 그대로 두고, VPC 피어링 연결로 두 VPC의 라우팅 테이블에 서로를 향하는 경로를 추가합니다. AWS 공식 문서는 이 방식을 이렇게 안내합니다.

"Use a VPC peering connection to route traffic between the resources in two VPCs."

VPC 자체를 합치는 것이 아니라, 별개인 두 VPC를 네트워크 수준에서 연결하는 방식입니다.

연결할 VPC나 VPN이 여러 개로 늘어날 것 같다면 전송 게이트웨이(Transit Gateway)를 검토합니다. 피어링은 VPC 쌍마다 개별로 맺어야 해서, 리전이나 VPC 수가 늘어나면 관리가 급격히 복잡해집니다. AWS 공식 문서는 이런 경우를 위한 중앙 허브 방식을 안내합니다.

"Use a transit gateway, which acts as a central hub, to route traffic between your VPCs, VPN connections, and Direct Connect connections."

사내망에서 지사가 늘어날수록 개별 전용선 대신 허브 앤 스포크 구조로 전환하던 것과 같은 방향의 해법입니다.

어느 방식을 택하든 CIDR이 겹치지 않는지부터 먼저 확인해야 합니다. 피어링이든 전송 게이트웨이든, 두 VPC의 CIDR 블록이 겹치면 연결 자체가 불가능합니다. 처음 설계 단계에서 리전별 VPC의 대역을 서로 겹치지 않게 나눠 둬야 합니다(3장의 "여유 있게 잡는다"에 "리전별로 겹치지 않게"도 추가해야 하는 이유입니다).

"VPC는 리전 경계를 넘지 않는다"는 것을 인프라 설계 초기에 반영해 두지 않으면, 멀티 리전 이중화 계획 자체를 다시 짜야 하는 상황을 만날 수 있습니다.

5. 비용·운영 감각

온프레미스에서는 스위치·라우터·방화벽 장비를 구매하는 순간 네트워크 인프라 비용 대부분이 확정됩니다. VPC는 이 감각과 크게 다릅니다.

VPC·서브넷·라우팅 테이블·보안 그룹 자체는 무료입니다. 몇 개를 만들든, 얼마나 정교하게 나누든 그 자체로는 과금되지 않습니다. 온프레미스에서 "물리 장비를 늘릴 때마다 비용이 든다"는 감각을 VPC 설계에 그대로 옮기면, 필요 이상으로 서브넷을 아끼거나 단순하게 설계하는 방향으로 흘러갈 수 있습니다 — 비용 부담 없이 용도별로 세분화해도 됩니다.

비용은 VPC 안에 얹는 컴포넌트에서 발생합니다. 대표적으로 NAT 게이트웨이(프라이빗 서브넷이 인터넷에 나갈 때 거치는 컴포넌트, 5번 글에서 다룰 주제)가 있고, 트래픽 미러링·Reachability Analyzer 같은 부가 기능도 별도 과금됩니다.

퍼블릭 IPv4 주소는 이제 과금 대상입니다. AWS 공식 문서는 이렇게 설명합니다.

"A public IPv4 address is an IPv4 address that is routable from the internet. A public IPv4 address is necessary for a resource to be directly reachable from the internet over IPv4."
"Private IPv4 addresses (RFC 1918) are not charged."

온프레미스에서 공인 IP가 회선 계약에 딸려 오는 경우가 많아 IP 자체 비용을 잘 의식하지 않는 것과 달리, VPC에서는 사설 IP(RFC 1918 대역 — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16처럼 인터넷에 직접 노출되지 않는 사설 IP 대역을 정의한 IETF 표준 문서)는 무료지만 퍼블릭 IP는 유료입니다(EC2 글 5장에서 다룬 탄력적 IP 과금과 같은 원칙의 연장선입니다). 프라이빗 서브넷 위주로 설계하는 것이 단순히 보안뿐 아니라 비용 측면에서도 유리한 이유입니다.

6. 관련 개념

보안 그룹·네트워크 ACL — 서브넷·인스턴스 단위의 트래픽 제어. 이 글에서는 존재만 언급하고 깊이 다루지 않았다.
NAT 게이트웨이·인터넷 게이트웨이 — 프라이빗 서브넷이 인터넷으로 나가는 경로, 퍼블릭 서브넷이 인터넷과 만나는 관문.
ALB·NLB — VPC 안 여러 서브넷에 걸쳐 트래픽을 분산하는 로드밸런서.
Direct Connect·Site-to-Site VPN — 온프레미스 네트워크와 VPC를 연결하는 전용선·VPN.
IAM — 누가 VPC·서브넷·라우팅 테이블을 만들고 고칠 수 있는지를 통제하는 권한 체계.

7. 한눈에 정리

항목	확인할 것
VPC	리전 하나에 종속, 다른 리전으로 자동 확장되지 않는다
CIDR 블록	`/16`~`/28` 범위, 생성 후 기존 블록 크기 변경 불가 — 추가만 가능하다
서브넷	가용 영역 하나에 고정, VPC의 CIDR을 나눠 쓴다
퍼블릭·프라이빗 구분	물리적 분리가 아니라 라우팅 테이블에 인터넷 게이트웨이 경로가 있는지로 결정된다
라우팅 테이블	서브넷마다 하나씩 연결, 지정 안 하면 메인 라우팅 테이블이 자동 적용된다
기본 VPC	서브넷이 전부 퍼블릭으로 구성되어 있다
VPC·서브넷·라우팅 테이블	그 자체로는 무료
퍼블릭 IPv4	유료, 사설 IP(RFC 1918)는 무료
여러 리전 연결	VPC 피어링(개별 연결) 또는 전송 게이트웨이(중앙 허브)가 필요하다

장애없이, 매일 놀아 봅시다.

certificate has expired — 인증서 만료, 장애 하루 전 신호

목차

1. 신호 관찰 — -enddate가 아니라 -checkend로 봅니다

2. 왜 위험한가 — 리프만 보고 안심하면 안 되는 이유

3. 재현 — 만료된 인증서로 실제로 끊어 봅니다

4. 임계값과 오탐 — 언제부터, 그리고 아닌 경우

5. 지금 조치 — 갱신 자체보다 갱신 자동화를 먼저 봅니다

6. 치트시트 — 정기 점검 명령

Start request repeated too quickly — 서비스 flapping, 장애 하루 전 신호

목차

1. 신호 관찰 — 재시작 카운터와 한도 대비 비율

2. 왜 위험한가 — 자동 재시작도, 수동 재시작도 같은 카운터를 씁니다

3. 재현 — 기본값 그대로 한도까지 밀어붙여 봅니다

4. 임계값과 오탐 — 몇 번부터, 그리고 아닌 경우

5. 지금 조치 — 카운터를 지울지, 원인을 고칠지

6. 치트시트 — 정기 점검 명령

문의 페이지

문의

답변에 대하여

저작권

이 블로그는 무엇을 쓰는 곳인가

왜 이렇게 쓰는가

어떻게 검증하는가

다루는 주제

누가 쓰는가

업데이트

문의

Cannot assign requested address — ephemeral 포트 고갈, 장애 하루 전 신호

목차

1. 신호 관찰 — ss -s의 timewait과 포트 범위

2. 왜 위험한가 — 그리고 흔한 오해 하나를 실측으로 바로잡기

3. 재현 — 포트 11개로 좁혀서 실제로 고갈시켜 봅니다

4. 임계값과 오탐 — 몇 %부터, 그리고 아닌 경우

5. 지금 조치 — 포트를 늘릴지, 연결을 줄일지

6. 치트시트 — 정기 점검 명령

이어서 보면 좋은 글

S3 — "NAS 마운트" 감각으로 열면 바로 걸리는 AWS의 오브젝트 스토리지

목차

1. S3가 정확히 뭔가

2. 온프레미스 대응표

3. 실무에서 반드시 알아야 하는 것

버킷 이름은 전역에서 유일해야 하고, 만든 뒤엔 이름도 리전도 못 바꾼다

스토리지 클래스는 접근 빈도로 고른다

객체 하나의 크기 제한과 업로드 방식

쓰자마자 읽어도 최신 값이 보장된다 — 강한 일관성

기본은 비공개, 접근 차단 설정이 기본으로 켜져 있다

시나리오 — 버킷 이름을 만들 때마다 이미 있다고 거부당한다

4. 온프레미스 관리자가 자주 하는 오해

오해 1. "네트워크 드라이브처럼 버킷을 마운트해서 쓰면 되겠지"

오해 2. "폴더를 지우면 그 폴더 전체가 지워진다"

오해 3. "저장만 해두면 어느 클래스든 여러 데이터센터에 복제돼 있다"

오해 4. "라이프사이클로 아무 때나 Glacier로 내리면 무조건 저렴해진다"

시나리오 — 로그를 Glacier로 자동 전환했더니 스토리지 비용이 오히려 늘었다

5. 비용·운영 감각

6. 관련 개념

7. 한눈에 정리

이어서 보면 좋은 글

개인정보처리방침

개인정보처리방침

1. 수집하는 개인정보 항목 및 수집 방법

2. 개인정보의 수집 및 이용 목적

3. 쿠키(Cookie) 운영 및 광고 서비스 안내

4. 개인정보의 제3자 제공 및 처리 위탁

5. 개인정보의 보유 및 이용 기간

6. 이용자의 권리와 행사 방법

7. 개인정보 보호책임자

8. 고지의 의무

부칙

lsof로 세면 안 보입니다 — 파일 디스크립터 고갈, 장애 하루 전 신호

목차

1. 신호 관찰 — lsof로 세면 안 되는 이유

2. 왜 위험한가 — 프로세스 한도와 시스템 한도는 다르다

프로세스 한도 — RLIMIT_NOFILE, 넘으면 EMFILE

시스템 전체 한도 — /proc/sys/fs/file-max, 넘으면 ENFILE

3. 재현 — 한도까지 밀어붙여 봅니다

4. 임계값과 오탐 — 몇 %부터, 그리고 아닌 경우

5. 지금 조치 — 지금 늘릴 수 있는 것과 재시작이 필요한 것

원인 프로세스와 fd 목록 확인

6. 치트시트 — 정기 점검 명령

1. 신호 관찰 — `-enddate`가 아니라 `-checkend`로 봅니다

1. 신호 관찰 — `ss -s`의 timewait과 포트 범위

1. 신호 관찰 — `lsof`로 세면 안 되는 이유

프로세스 한도 — `RLIMIT_NOFILE`, 넘으면 `EMFILE`

시스템 전체 한도 — `/proc/sys/fs/file-max`, 넘으면 `ENFILE`