jaeyoung-dev

운영 중인 UniFi 장비에서 NAT 규칙 확인하기

jaeyoung-dev — Sun, 24 May 2026 17:39:40 +0900

NAT는 네트워크를 공부하다 보면 자주 만나는 개념입니다.

처음에는 NAT를 단순히 “사설 IP를 공인 IP로 변환하는 기술” 정도로 이해했습니다.
그런데 실제 운영 중인 장비에서는 이 개념이 어떤 설정과 규칙으로 나타나는지 궁금해졌습니다.

따라서, 이번 글에서는 UniFi USG-Pro-4에 SSH로 접속해 NAT 관련 설정을 살펴보겠습니다.

운영 중인 장비이기 때문에 설정 변경은 하지 않았고, 조회 명령만 사용했습니다.
공인 IP, 사설 IP 일부, 비표준 포트, 내부 서버 정보는 보안상 마스킹했습니다.

SSH 접속 화면

NAT가 필요한 이유

IPv4 주소는 32비트로 구성되어 있으며, 이론상 약 43억 개의 주소를 표현할 수 있습니다.

하지만 이 주소를 모두 공인 IP로 사용할 수 있는 것은 아니고,
오늘날 인터넷에 연결되는 기기 수를 생각하면 이 정도 주소 공간만으로는 부족합니다.

그래서 내부 네트워크에서는 보통 사설 IP를 사용합니다.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

사설 IP는 회사, 가정, 연구실 같은 내부 네트워크에서는 사용할 수 있지만, 인터넷에서는 직접 라우팅되지 않습니다.

예를 들어 내부 장비가 192.168.xxx.xxx 주소를 가지고 있다고 해서, 이 주소 그대로 인터넷 서버와 통신할 수는 없습니다.

인터넷 입장에서는 해당 사설 IP가 어느 네트워크의 어떤 장비인지 알 수 없기 때문입니다.

이때 필요한 기술이 NAT(Network Address Translation)입니다.

NAT는 내부 사설 IP를 외부 인터넷에서 사용할 수 있는 주소로 변환해주는 기술입니다.

책의 예시로 보는 NAT 구조

책에 나오는 NAT 구조를 기준으로 먼저 개념을 짚고 넘어가겠습니다.

[내부 호스트]
172.18.3.1
...
      ↓
      
[NAT 라우터]
Inside: 172.18.3.30
Outside: 200.24.5.8
      ↓
      
[외부 서버]

예시에서 사설 네트워크가 172.18.3.x 대역을 사용합니다.

172.18.3.1
172.18.3.2
...
172.18.3.20

이 주소들은 내부 네트워크에서는 사용할 수 있지만, 외부 인터넷에서는 직접 사용할 수 없습니다.

중간의 NAT 라우터는 두 개의 주소를 가집니다.

내부 방향 주소: 172.18.3.30
외부 방향 주소: 200.24.5.8

내부 호스트가 인터넷으로 나가면, NAT 라우터는 출발지 주소를 내부 사설 IP에서 자신의 외부 주소로 변환합니다.

예를 들어 172.18.3.1이 외부 서버에 접근한다고 해보겠습니다.

변환 전:
172.18.3.1 → 외부 서버

변환 후:
200.24.5.8 → 외부 서버

외부 네트워크에서는 내부의 172.18.3.1을 직접 볼 수 없습니다.

외부에서 보이는 주소는 NAT 라우터의 외부 주소인 200.24.5.8입니다.

이 구조를 실제 운영 환경에 대입하면, NAT 라우터 역할을 UniFi USG-Pro-4가 수행한다고 볼 수 있습니다.

SNAT, DNAT, PAT 구분

NAT는 어떤 주소를 변환하느냐에 따라 나눌 수 있습니다.

구분	의미	대표 방향
SNAT	Source NAT, 출발지 주소 변환	내부 → 외부
DNAT	Destination NAT, 목적지 주소 변환	외부 → 내부
PAT	Port Address Translation, 포트까지 함께 변환	여러 내부 장비 → 하나의 외부 IP

간단히 정리하면 다음과 같습니다.

SNAT : 내부 장비가 인터넷으로 나갈 때 출발지 IP를 바꾸는 방식
DNAT : 외부에서 들어온 요청의 목적지 IP를 내부 서버로 바꾸는 방식
PAT : 여러 내부 장비의 연결을 포트 번호로 구분하여 하나의 공인 IP를 공유하는 방식

실제 환경에서 확인

이제 운영 중인 UniFi 장비에서 NAT 관련 설정을 직접 확인해보겠습니다.

 
대상 장비는 UniFi USG-Pro-4이고, 사용한 명령어는 다음과 같습니다.

show interfaces
show ip route
show nat rules
show configuration commands | grep -i port-forward
sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
sudo iptables -t nat -S | grep -E "DNAT|SNAT|MASQUERADE"

아래 정보는 보안상 이유로 마스킹했습니다.

공인 IP
사설 IP 일부
비표준 포트
내부 서버 주소
장비 식별 정보
서비스 설명 일부
...

인터페이스 확인

먼저 LAN과 WAN이 각각 어떤 인터페이스에 연결되어 있는지 확인했습니다.

show interfaces

필요한 부분만 가져오면 아래와 같습니다.

Interface    IP Address              S/L  Description
---------    ----------              ---  -----------
eth0         192.168.xxx.1/23        u/u  LAN
eth1         -                       A/D
eth2         203.xxx.xxx.xxx/24      u/u  WAN
eth3         -                       A/D
lo           127.0.0.1/8             u/u

eth0은 내부 네트워크와 연결된 LAN 인터페이스이고, eth2는 외부 인터넷과 연결된 WAN 인터페이스입니다.

구조로 보면 다음과 같습니다.

내부 네트워크
192.168.xxx.0/23
        ↓
eth0 - USG-Pro-4 - eth2
        ↓
외부 네트워크
203.xxx.xxx.xxx/24

NAT는 이 LAN과 WAN 사이에서 발생합니다.

라우팅 경로 확인

다음으로 외부 트래픽이 어떤 경로로 나가는지 확인했습니다.

show ip route

주요 출력은 아래와 같습니다.

S>* 0.0.0.0/0 [1/0] via 203.xxx.xxx.1, eth2
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.xxx.0/23 is directly connected, eth0
C>* 203.xxx.xxx.0/24 is directly connected, eth2

출력 결과에서 핵심은 기본 경로입니다.

0.0.0.0/0 via 203.xxx.xxx.1, eth2

목적지를 알 수 없는 외부 트래픽은 eth2를 통해 WAN 방향으로 나갑니다.

내부 장비는 192.168.xxx.xxx 형태의 사설 IP를 사용하고 있습니다.

즉, 이 주소 그대로 인터넷에 나갈 수 없기 때문에, WAN으로 나가기 전 출발지 주소 변환이 필요하다는 것을 알 수 있습니다.

SNAT / Masquerade 확인

설정된 NAT 규칙을 확인해보겠습니다.

show nat rules

NAT와 관련된 부분만 보면 다음과 같습니다.

rule   type  intf     translation
----   ----  ----     -----------
6001   MASQ  eth2     saddr ANY to 203.xxx.xxx.xxx
    proto-all         sport ANY

6002   MASQ  eth2     saddr ANY to 203.xxx.xxx.xxx
    proto-all         sport ANY

6003   MASQ  eth2     saddr ANY to 203.xxx.xxx.xxx
    proto-all         sport ANY

여기서 MASQ는 Masquerade를 의미합니다.

Masquerade는 SNAT의 한 형태로 볼 수 있습니다.
내부 장비가 외부로 나갈 때 출발지 주소를 WAN 인터페이스의 주소로 바꿔줍니다.

변환 전:
192.168.xxx.xxx → 외부 서버

변환 후:
203.xxx.xxx.xxx → 외부 서버

즉, 내부 장비의 사설 IP가 그대로 인터넷에 노출되는 것이 아니라, USG-Pro-4의 WAN IP로 변환되어 외부와 통신합니다.

iptables에서 SNAT 확인

USG-Pro-4 내부에서는 NAT 규칙이 iptables NAT 테이블에도 반영되어 있었습니다.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers

NAT와 관련된 부분만 보면 다음과 같습니다.

Chain POSTROUTING (policy ACCEPT)
num   pkts   bytes  target      prot  in  out   source       destination
4     ...    ...    MASQUERADE  all   *   eth2  0.0.0.0/0    0.0.0.0/0  match-set corporate_network src  /* NAT-6001 */
5     ...    ...    MASQUERADE  all   *   eth2  0.0.0.0/0    0.0.0.0/0  match-set remote_user_vpn_network src  /* NAT-6002 */
6     ...    ...    MASQUERADE  all   *   eth2  0.0.0.0/0    0.0.0.0/0  match-set guest_network src  /* NAT-6003 */

POSTROUTING은 패킷이 외부 인터페이스로 나가기 직전에 적용되는 단계를 의미합니다.

이 지점에서 MASQUERADE가 적용된다는 것은, 내부 네트워크의 출발지 주소가 WAN 인터페이스의 주소로 변환된다는 의미입니다.

따라서 이 규칙은 SNAT에 해당한다고 볼 수 있습니다.

PAT는 어디에 해당할까?

PAT는 IP 주소뿐 아니라 포트 번호까지 함께 변환하여 연결을 구분하는 방식입니다.

여러 내부 장비가 하나의 WAN IP를 공유하려면, 게이트웨이는 각 연결이 어느 내부 장비에서 시작되었는지 구분해야 합니다.

이때 포트 번호가 함께 사용됩니다.

예를 들어 내부에서는 다음과 같은 연결이 발생할 수 있습니다.

192.168.xxx.10:50001 → 외부 서버:443
192.168.xxx.20:50002 → 외부 서버:443
192.168.xxx.30:50003 → 외부 서버:443

NAT 이후 외부에서 보기에는 다음처럼 보일 수 있습니다.

203.xxx.xxx.xxx:40001 → 외부 서버:443
203.xxx.xxx.xxx:40002 → 외부 서버:443
203.xxx.xxx.xxx:40003 → 외부 서버:443

외부에서 보면 모두 같은 WAN IP를 사용하는 것처럼 보입니다.

USG-Pro-4는 포트 번호와 연결 추적 정보를 기준으로 응답을 원래 내부 장비에 돌려보냅니다.

운영 장비에서 PAT라는 이름의 규칙이 따로 보이지는 않았습니다.

다만 여러 내부 네트워크가 MASQUERADE 규칙을 통해 하나의 WAN IP로 나가고 있으므로,
일반적인 인터넷 접속 과정에서는 포트 번호를 이용해 각 연결을 구분한다고 이해할 수 있습니다.

실제 포트 매핑 상태까지 보려면 NAT 규칙뿐 아니라 연결 추적 정보까지 함께 확인해야 합니다.

DNAT / Port Forwarding 확인

이번에는 외부에서 내부로 들어오는 흐름을 보겠습니다.

UniFi 설정에서 Port Forwarding 규칙을 확인할 수 있었습니다.

show configuration commands | grep -i port-forward

Port Forwarding 관련 설정만 보면 다음과 같습니다.

set port-forward hairpin-nat enable
set port-forward lan-interface eth0
set port-forward wan-interface eth2

set port-forward rule 3003 forward-to address 192.168.xxx.xxx
set port-forward rule 3003 original-port 80
set port-forward rule 3003 protocol tcp_udp

set port-forward rule 3004 forward-to address 192.168.xxx.xxx
set port-forward rule 3004 original-port 443
set port-forward rule 3004 protocol tcp_udp

여기서 hairpin NAT는 내부 사용자가 내부 서버를 공인 IP나 도메인으로 접근할 때도
Port Forwarding 흐름을 사용할 수 있게 해주는 설정입니다.

Port Forwarding은 외부에서 WAN IP의 특정 포트로 들어온 요청을 내부 서버로 전달하는 기능입니다.

외부 사용자
  ↓
USG-Pro-4 WAN IP:80
  ↓
Port Forwarding
  ↓
192.168.xxx.xxx:80

HTTPS도 같은 방식입니다.

외부 사용자
  ↓
USG-Pro-4 WAN IP:443
  ↓
Port Forwarding
  ↓
192.168.xxx.xxx:443

이 동작은 목적지 주소를 변환하므로 DNAT에 해당합니다.

iptables에서 DNAT 확인

iptables NAT 테이블에서도 DNAT 규칙을 확인할 수 있었습니다.

sudo iptables -t nat -S | grep -E "DNAT|SNAT|MASQUERADE"

DNAT 처리 흐름은 아래와 같습니다.

-A PREROUTING -j UBNT_PFOR_DNAT_HOOK
-A UBNT_PFOR_DNAT_HOOK -i eth2 -m set --match-set ADDRv4_eth2 dst -j UBNT_PFOR_DNAT_RULES

-A UBNT_PFOR_DNAT_RULES -p tcp --dport 80  -j DNAT --to-destination 192.168.xxx.xxx
-A UBNT_PFOR_DNAT_RULES -p udp --dport 80  -j DNAT --to-destination 192.168.xxx.xxx
-A UBNT_PFOR_DNAT_RULES -p tcp --dport 443 -j DNAT --to-destination 192.168.xxx.xxx
-A UBNT_PFOR_DNAT_RULES -p udp --dport 443 -j DNAT --to-destination 192.168.xxx.xxx

PREROUTING은 패킷이 라우팅되기 전에 먼저 거치는 단계입니다.

외부에서 WAN IP의 특정 포트로 들어온 요청은 이 단계에서 내부 사설 IP로 목적지가 변경됩니다.

즉, UniFi의 Port Forwarding 설정은 내부적으로 iptables의 DNAT 규칙으로 반영되어 있었습니다.

정리

운영 중인 UniFi USG-Pro-4에서 NAT 관련 설정을 확인한 결과는 다음과 같습니다.

구분	확인한 내용
LAN / WAN 구조	eth0 = LAN, eth2 = WAN
기본 라우팅	외부 트래픽은 eth2를 통해 WAN으로 전달
SNAT	MASQUERADE 규칙으로 내부 주소를 WAN IP로 변환
PAT	여러 내부 장비가 하나의 WAN IP를 공유하며 포트로 연결 구분
DNAT	Port Forwarding 설정이 iptables의 DNAT 규칙으로 반영

방향만 놓고 보면 NAT의 역할은 다음처럼 나눌 수 있습니다.

내부 → 외부:
SNAT / Masquerade / PAT

외부 → 내부:
DNAT / Port Forwarding

책에서 개념으로만 봤던 NAT는 실제 운영 장비에서도 구체적인 규칙으로 확인할 수 있었습니다.

UniFi USG-Pro-4에서는 내부에서 외부로 나가는 트래픽에 MASQUERADE 규칙이 적용되어 SNAT/PAT 성격으로 처리되고 있었고,
외부에서 내부로 들어오는 요청은 Port Forwarding 설정을 통해 DNAT 규칙으로 처리되고 있었습니다.

이처럼 NAT는 단순히 “사설 IP를 공인 IP로 바꿔준다”는 설명으로만 끝나는 기능이 아니라,
트래픽 방향에 따라 서로 다른 규칙으로 처리되는 기능이라고 볼 수 있습니다.

참고자료

Book: Data Communications and Networking / Behrouz A. Forouzan 저

AWS Summit Seoul 2026 회고: AI 시대에 어떤 개발자가 되어야 할까

jaeyoung-dev — Sat, 23 May 2026 19:55:08 +0900

2026년 5월 20일부터 21일까지 이틀간 진행된 AWS Summit Seoul 2026에 참여했다.

AWS Summit Seoul 2026 행사장에 도착했을 때의 모습

AWS !

AWS Summit은 이번이 처음이었다. AWS에 관심은 꾸준히 가지고 있었지만, 이렇게 큰 규모의 오프라인 행사에 직접 참여한 것은

처음이었기 때문에 행사장에 들어가기 전까지는 어떤 분위기일지 쉽게 상상이 되지 않았다.

이번 Summit에 참여한 가장 큰 이유는 AWS가 클라우드 시장의 선두 주자라는 점 때문이었다.

클라우드 시장을 이끌어 온 AWS가 현재 AI 흐름을 어떻게 바라보고 있는지,

그리고 실제 기업들은 AWS 위에서 AI를 어떤 방식으로 활용하고 있는지 직접 확인해보고 싶었다.

이번 Summit은 1일차 Industry Day, 2일차 AI Day로 구성되어 있었다.

하지만 실제로 세션을 들어보니 첫날부터 이미 전체 분위기는 AI를 중심으로 흘러가고 있었다.

금융, 로봇, 고객 경험, 개발 라이프사이클, 서버리스, 에이전틱 AI 등 다루는 도메인은 다양했지만, 결국 많은 발표가

“AI를 어떻게 실제 비즈니스와 서비스에 적용할 것인가”라는 질문으로 연결되고 있었다.

이틀 동안 총 10개의 세션에 참여했다.

기조연설 - Industry Day
KBaaS, 금융이 플랫폼 속으로 : KB국민은행의 임베디드 금융 전략과 API 인프라 현대화
AWS 위에서 만드는 로봇의 미래: 리얼월드의 RFM 학습과 위로보틱스의 휴머노이드 조작기능 구현
복잡함 속의 질서 : Beyond AI Adoption in Agentic Era
혁신가와 리더의 대담 - AI로 이끄는 비즈니스 혁신
Amazon Connect Customer AI Agent가 다시 쓰는 고객 경험 : 불만을 감동으로
AI 기반 개발 라이프사이클(AI-DLC) 소개
AWS AI와 서버리스로 구축하는 완성차 지능형 상품 전략 플랫폼
200개국 삼성 스마트 TV 앱 데이터를 자연어로 묻다: 에이전틱 AI on AWS
에이전트 성능 평가와 개선: 개발부터 운영까지

모든 세션을 하나씩 자세히 정리하기보다는, 이번 글에서는

특히 인상 깊었던 세션들과 그 과정에서 정리하게 된 생각을 중심으로 기록해보려고 한다.

생각보다 훨씬 컸던 AWS 생태계의 존재감

가장 먼저 느낀 것은 행사장의 규모와 열기였다.

기조연설을 듣고 있는 사람들

세션마다 사람이 많았고, 관심 있는 발표를 듣기 위해 많은 사람들이 이동하고 대기하는 모습을 볼 수 있었다.

단순히 AWS 서비스를 소개하는 자리가 아니라, 이미 많은 기업과 개발자들이 AWS 기반으로 서비스를 만들고 운영하고 있으며,

그 위에서 AI를 어떻게 활용할지 고민하고 있다는 점이 현장에서 바로 느껴졌다.

거의 모든 세션에서 많은 참가자들이 발표를 듣고 있었다.

예전에 AWS 온라인 교육 프로그램에 참여한 적이 있었다.

당시에는 AWS에 대한 이해가 충분하지 않았기 때문에, 일부 내용이 AWS 서비스를 홍보하는 강의처럼 느껴지기도 했다.

무엇을 설명하는지는 알겠지만, 왜 중요한지까지는 깊게 와닿지 않았던 기억이 있다.

그런데 이번 Summit에서는 조금 다르게 받아들여졌다.

AWS가 단순히 클라우드 서비스를 제공하는 회사를 넘어,

현재 AI 시장과 소프트웨어 개발 방식의 변화를 이끌어가는 주요 플랫폼 중 하나라는 점이 더 분명하게 느껴졌다.

그래서 이번에는 “AWS가 어떤 서비스를 제공하는가?”보다

“AWS는 AI 시대의 흐름을 어떤 방향으로 이끌고 있는가?”,

그리고

“나는 그 흐름 속에서 어떤 역량을 갖춰야 하는가?”

라는 관점으로 세션을 듣게 되었다.

Why에서 Why Not으로

첫째 날 기조연설에서 가장 기억에 남았던 표현은 “Why”에서 “Why Not”으로의 전환이었다.

첫째 날, Industry Day 기조연설 사진

Jason Bennett - Vice President, Worldwide Startups and VC, AWS 의 발표 중 나온 내용이었는데,

개인적으로 이번 Summit 전체를 관통하는 문장처럼 느껴졌다.

그동안 새로운 아이디어나 서비스를 떠올릴 때는 자연스럽게

“왜 해야 하지?”, “정말 가능한가?”, “구현하려면 너무 복잡하지 않을까?” 같은 질문을 먼저 하게 되는 경우가 많았다.

하지만 AI를 활용하면 아이디어를 직접 만들어보고 실험하는 과정이 이전보다 훨씬 빨라진다.

완성도 높은 결과물을 처음부터 만드는 것은 여전히 어렵지만,

적어도 가능성을 검증하고 초기 형태를 구현해보는 진입 장벽은 분명히 낮아졌다는 생각이 들었다.

이 지점에서 “Why?”보다 “Why Not?”이라는 태도가 가능해졌다는 말이 특히 인상 깊었다.

다만 그렇다고 해서 기본기가 덜 중요해졌다는 뜻은 아니라고 느꼈다. 오히려 반대에 가까웠다.

AI를 통해 무언가를 빠르게 만들어낼 수 있는 시대가 되었기 때문에,

그 결과물이 올바른 방향으로 가고 있는지 판단하는 능력이 더 중요해졌다.

결국 코드를 얼마나 빠르게 작성하느냐보다 더 중요한 것은

문제를 이해하는 능력, 도메인을 해석하는 능력, 그리고 적절한 소프트웨어 구조를 설계하는 능력이라는 생각이 들었다.

고객 경험을 바꾸는 AI Agent

가장 인상 깊었던 세션 중 하나는 “Amazon Connect Customer AI Agent가 다시 쓰는 고객 경험 : 불만을 감동으로”였다.

고객 경험 관점에서 AI Agent를 어떻게 활용할 수 있는지 보여준 세션

이 세션이 좋았던 이유는 AI를 단순히 “대단한 기술”로 설명하기보다,

실제 고객 경험 안에서 어떤 역할을 할 수 있는지를 보여주었다는 점이었다.

특히 고객 문의나 불만 처리처럼 반복적이면서도 감정적인 부담이 큰 업무에서 AI가 어떻게 개입할 수 있는지를 구체적으로 볼 수 있었다.

세션에서는 항공편 지연 상황을 바탕으로 데모가 진행되었다.

고객이 항공편 지연 문제로 문의했을 때, AI Agent가 단순히 정해진 답변을 반복하는 것이 아니라

고객의 상황을 진단하고, 적절한 조치를 위해 여러 MCP 툴을 유연하게 호출하는 흐름이 인상 깊었다.

Amazon Connect 데모

또 흥미로웠던 부분은 외부 API와의 연동이었다. 실제 서비스 환경에서는 고객의 상황을 이해하기 위해

내부 시스템이나 외부 API를 호출해야 하는 경우가 많은데, 이 데모에서는 AI가 상황에 맞는 외부 API를 호출하고,

그 결과를 이해한 뒤 추가 응대까지 이어가는 모습을 보여주었다.

특히 좋았던 것은 대화의 맥락이 끊기지 않도록 설계되어 있다는 점이었다.

AI가 1차적으로 고객 상황에 대응한 뒤 상담사에게 연결되는 경우에도, 상담사는 처음부터 다시 상황을 파악할 필요가 없었다.

AI와 고객이 나눈 대화의 맥락이 정리된 대시보드를 통해 상담사가 자연스럽게 이어서 응대할 수 있도록 지원하는 구조였다.

AI Agent가 고객 상황을 파악하고, 상담사에게 맥락을 이어주는 구조가 특히 인상 깊었다.

실제 고객 응대에서 가장 불편한 경험 중 하나는 상담사가 바뀔 때마다 같은 내용을 다시 설명해야 하는 상황이다.

세션에서 보여준 구조는 바로 그런 문제를 AI로 어떻게 줄일 수 있는지를 잘 보여주었다.

이 세션을 들으며 예전에 진행했던 프로젝트도 떠올랐다. 과거에 키오스크 기반 회의실 관리 서비스를 만든 적이 있었는데, 여기에 AI Agent를 결합하면 어떨까 하는 생각이 들었다.

예를 들어 사용자가 키오스크 화면에서 회의실을 직접 선택하고 예약하는 방식에서 더 나아가,

AI Agent가 사용자의 요청을 이해하고 가능한 시간대나 회의실을 추천해줄 수 있다면

서비스 경험이 훨씬 자연스러워질 수 있겠다는 생각이 들었다.

다만 동시에 한 가지 개인적인 의문도 생겼다.

AI Agent가 사용자와 상호작용할 때 반드시 음성이나 TTS 중심으로 가야 할까?

경우에 따라서는 음성보다 체크박스, 선택지, 자연어 입력, 화면 기반 인터페이스가 더 편안한 경험이 될 수도 있지 않을까?

이 부분은 세션의 직접적인 내용이라기보다, 세션을 들으며 개인적으로 확장하게 된 생각에 가깝다.

하지만 AI를 서비스에 적용할 때 중요한 것은 “AI를 넣었다”는 사실보다,

사용자가 어떤 방식으로 가장 자연스럽게 문제를 해결할 수 있는가라는 점이라고 느꼈다.

SDLC에서 AI-DLC로

두 번째로 인상 깊었던 세션은 “AI 기반 개발 라이프사이클(AI-DLC) 소개”였다.

소프트웨어 개발 전 과정에서 AI와 사람이 어떻게 협업할 수 있는지를 다룬 세션

이 세션은 기존의 SDLC, 즉 Software Development Life Cycle이 AI 시대에 어떻게 변화할 수 있는지를 보여주었다.

단순히 개발자가 AI 도구를 사용해 코드를 더 빠르게 작성한다는 이야기가 아니라,

요구사항 분석, 설계, 구현, 테스트, 운영까지 이어지는 전체 소프트웨어 개발 과정에서

AI가 어떻게 보조 역할을 할 수 있는지를 설명하는 세션이었다.

개인적으로 가장 크게 남은 메시지는 AI와 사람이 각자 잘하는 일에 집중해야 한다는 것이었다.

AI는 빠르게 초안을 만들고, 반복 작업을 줄이고, 다양한 가능성을 제안하는 데 강점이 있다.

반면 사람은 맥락을 이해하고, 최종 결정을 내리고, 책임 있는 판단을 해야 한다.

즉, AI-DLC는 AI가 사람을 대체하는 구조라기보다,

AI와 사람이 하나의 워크플로우 안에서 협업하는 구조에 더 가까워 보였다.

LG에서는 이를 세 가지 관점으로 설명했다.

첫 번째는 업무 분해였다.

계층적 Inception을 통해 작업을 적절한 단위로 나누고,

1인이 1~2일 안에 Construction 가능한 크기로 작업 단위를 분할하는 방식이었다.

특히 500라인 이하의 분량이 사람과 AI 모두에게 안정적이라는 경험적 기준을 제시한 점이 인상 깊었다.

AI를 활용한다고 해서 무조건 큰 작업을 한 번에 맡길 수 있는 것은 아니었다.

오히려 작업을 잘게 나누고, AI가 안정적으로 처리할 수 있는 단위로 구조화하는 능력이 중요하다는 점이 눈에 들어왔다.

두 번째는 정보 보존이었다. 이 부분은 개인적으로 특히 중요하게 느껴졌다.

세션에서는 AI가 본능적으로 요약하려는 경향이 있으며, 소프트웨어 설계에서는 이것이 치명적일 수 있다고 설명했다.

개발 과정에서 중요한 것은 단순한 요약이 아니라, 왜 그런 설계 결정을 내렸는지에 대한 맥락이다.

설계 의사 결정이 코드까지 이어지려면, 중간 과정의 정보가 사라지지 않도록 관리해야 한다.

이를 위해 계획 단계에서 참조해야 하는 문서 목록을 명시적으로 관리하고,

사람이 최종적으로 확인해 누락된 문서를 추가하며,

AI에게 명확한 제약과 기대치를 설정하는 전략을 사용했다고 소개했다.

이 부분을 들으며 AI 시대의 개발에서는 문서화와 설계 기록의 중요성이 오히려 더 커질 수 있겠다는 생각이 들었다.

세 번째는 기존 결정과의 공존이었다.

기업 환경에는 이미 사람이 내린 수많은 결정들이 존재한다.

기존 시스템의 구조, 조직의 정책, 기술 스택, 도메인 규칙, 과거의 설계 판단 등이 모두 현재의 개발에 영향을 준다.

AI가 유용하게 동작하려면 이러한 외부 맥락을 무시해서는 안 된다.

세션에서는 AI의 역할을 “확정된 것은 존중하고, 애매한 것은 질문하며, 빈 곳은 제안하게 만드는 것”으로 설명했다.

이 표현이 특히 기억에 남았다.

AI를 잘 활용한다는 것은 AI에게 모든 것을 맡기는 것이 아니라, AI가 어떤 맥락 안에서 일해야 하는지를 분명히 정해주는 것에 가깝다.

결국 좋은 결과를 얻기 위해서는 사람이 도메인과 기존 의사결정을 이해하고 있어야 한다.

이 세션을 통해 AI 시대의 개발자는 단순히 프롬프트를 잘 쓰는 사람이 아니라,

작업을 분해하고, 정보를 보존하며, 기존 맥락과 공존할 수 있는 개발 프로세스 자체를 설계할 수 있어야 한다는 생각이 들었다.

에이전트는 만들어지는 것보다 평가되고 개선되어야 한다

세 번째로 인상 깊었던 세션은 “에이전트 성능 평가와 개선: 개발부터 운영까지”였다.

AI Agent를 실제 서비스 수준으로 끌어올리기 위해 필요한 평가와 개선 과정을 다룬 세션

요즘 AI Agent에 대한 이야기는 정말 많다.

하지만 실제 서비스를 만든다고 생각하면 Agent를 구현하는 것만으로는 부족하다.

운영 환경에서 안정적으로 동작하는지,

의도한 답변을 일관되게 제공하는지,

잘못된 도구를 호출하지는 않는지,

성능을 어떻게 측정하고 개선할 것인지가 훨씬 중요해진다.

세션에서는 먼저 에이전트 개발자들이 밤잠을 설치게 만드는 네 가지 문제를 소개했다.

설계상 비결정론적이라는 점,

잘못된 도구와 잘못된 파라미터를 선택할 수 있다는 점,

“더 나아졌다”는 것을 측정하기 어렵다는 점,

그리고 자동 회귀 오류가 발생할 수 있다는 점이었다.

이 네 가지는 AI Agent를 실제 서비스로 운영하려면 결국 반드시 마주하게 될 문제처럼 느껴졌다.

특히 “더 나아졌다”를 어떻게 측정할 것인가라는 질문이 인상 깊었다.

단순히 응답이 자연스러워 보인다고 해서 좋은 에이전트라고 말할 수는 없다.

실제로 사용자의 목적을 달성했는지,

올바른 도구를 호출했는지,

적절한 파라미터를 사용했는지,

이전보다 실패율이 줄었는지를 판단할 수 있어야 한다.

에이전트는 한 번 만들고 끝나는 것이 아니라, 평가와 개선이 반복되는 라이프사이클을 가진다.

세션에서는 에이전트가 지속적으로 평가되고 개선되어야 한다고 설명했다.

모델 업데이트, 에이전트의 새 버전, 소스 프롬프트 수정, Tool 추가와 제거가 반복적으로 이루어지고,

그때마다 평가 과정이 필요하다는 것이다.

에이전트 평가 라이프사이클도 구체적으로 소개되었다.

에이전트를 구축하고, 평가 데이터셋을 찾거나 생성하고, Evaluator를 선택하고,

에이전트를 평가할 모델을 선택하고, 평가 수행 인프라를 구축하고, 결과를 기록하고 인사이트를 종합해 조정하며,

프로덕션 환경에서 모니터링하는 과정이 반복되어야 한다는 내용이었다.

이 과정을 들으며 AI Agent 개발은 단순히 프롬프트를 작성하고 도구를 연결하는 작업이 아니라는 점을 다시 느꼈다.

Agent가 실제 서비스로 운영되려면 평가 체계와 개선 루프가 함께 설계되어야 한다는 것이다.

세션에서는 AWS의 AgentCore Evaluations를 활용하면 이러한 과정의 부담을 줄일 수 있다고 소개했다.

또 사용자 시뮬레이터를 활용한 에이전트 평가 Preview도 언급되었다.

Amazon Bedrock FM을 사용해 다양한 표현으로 테스트하고,

자유 대화 평가를 진행하며, 시나리오 커버리지를 확장하고, 다양성 기반 회귀 테스트를 수행할 수 있다는 내용이었다.

평가 기준을 어떻게 세우고, 어떻게 반복적으로 검증할 것인가가 핵심이라는 점이 인상 깊었다.

여기서 중요한 개념으로 Ground Truth도 소개되었다.

세션에서는 이를 어설션, 예상 응답, 예상 궤적과 같은 형태로 표현할 수 있다고 설명했다.

이 부분이 특히 중요하게 느껴졌다. AI Agent는 항상 동일한 문장을 출력하지 않을 수 있기 때문에,

단순히 정답 문자열 하나와 비교하는 방식으로는 평가하기 어렵다.

어떤 조건을 만족해야 하는지, 어떤 응답이 기대되는지, 어떤 경로로 도구를 호출해야 하는지 등

평가 기준 자체를 더 섬세하게 설계해야 한다는 점이 인상 깊었다.

결국 에이전트 성능 평가에서 중요한 것은 “잘 되는 것처럼 보이는가?”가 아니라,

“무엇을 기준으로 잘 되었다고 판단할 것인가?”였다.

이 세션을 통해 나는 에이전트 개발자라면 이러한 평가 라이프사이클을 직접 설계하고 작성해보는 경험이 반드시 필요하다고 느꼈다.

AWS의 도구를 활용할 수는 있지만, 특정 서비스에만 의존하기보다

에이전트가 어떻게 평가되고 개선되어야 하는지에 대한 기본적인 구조를 이해하고 있어야 한다고 생각했다.

나는 최종적으로 아키텍터를 지향하고 있지만, 단순히 큰 구조만 이야기하는 사람이 되고 싶지는 않다.

AI Agent 개발 정도는 직접 다룰 수 있고, 개발의 구체적인 어려움과 평가 과정을 이해한 상태에서

아키텍처를 제시할 수 있는 사람이 되고 싶다는 생각도 더 분명해졌다.

AI 시대에 내가 갖춰야 할 역량

이번 Summit을 통해 가장 많이 생각한 것은 “AI 시대에 어떤 개발자가 되어야 하는가”였다.

졸업을 앞둔 입장에서, 이 질문은 단순한 감상이 아니라 앞으로의 진로와도 바로 연결되는 질문이었다.

AI를 잘 사용하는 것도 물론 중요하다. 하지만 그것만으로는 부족하다고 느꼈다.

기업에서 정말 필요로 하는 사람은 AI 도구에 의존해 결과물을 빠르게 만들어내는 사람만은 아닐 것이다.

오히려 중요한 것은

도메인과 비즈니스를 이해하고, 그 문제를 해결하기 위해 어떤 기술과 구조가 적합한지 판단할 수 있는 사람이라고 생각한다.

금융, 자동차, 로봇, 고객 경험, 개발 라이프사이클 등 서로 다른 세션을 들으며 공통적으로 느낀 점도 이와 같았다.

AI나 클라우드 기술이 단독으로 가치를 만드는 것이 아니라,

특정 도메인의 문제를 얼마나 정확히 이해하고 그에 맞는 아키텍처를 설계할 수 있는지가 중요했다.

특히 앞으로는 소프트웨어 아키텍처 설계 능력이 더욱 중요해질 것이라고 느꼈다.

AI를 통해 초기 구현은 더 빨라질 수 있다.

하지만 실제 서비스로 운영하기 위해서는

안정적인 구조, 확장 가능한 설계, 명확한 책임 분리, 운영과 평가 체계가 필요하다.

이 부분은 AI가 대신해주는 것이 아니라, 개발자가 더 깊게 고민해야 하는 영역이라고 생각한다.

그래서 나는 앞으로 단순히 코드를 작성하는 개발자에 머무르기보다,

도메인 중심으로 문제를 이해하고 비즈니스적인 맥락을 바탕으로

적합한 소프트웨어 아키텍처를 제시할 수 있는 개발자이자 아키텍터로 성장하고 싶다.

마무리

AWS Summit Seoul 2026은 나에게 단순히 AWS 서비스를 소개받는 자리가 아니었다.

클라우드 시장의 선두에 있는 AWS가 AI 시대를 어떤 방향으로 바라보고 있는지 확인할 수 있었고,

여러 기업들이 AI를 실제 비즈니스와 서비스에 어떻게 적용하고 있는지도 볼 수 있었다.

하지만 그보다 더 크게 남은 것은 기술 자체보다도 내가 앞으로 어떤 개발자가 되어야 하는가에 대한 고민이었다.

AI가 더 많은 코드를 작성하고, 더 빠르게 결과물을 만들어내는 시대가 오고 있다.

그렇기 때문에 개발자에게 필요한 역량은 오히려 더 넓어지고 있다고 생각한다.

문제를 이해하는 능력, 도메인을 해석하는 능력, 비즈니스 맥락을 파악하는 능력,

그리고 그에 맞는 소프트웨어 아키텍처를 설계하는 능력이 더욱 중요해지고 있다.

이번 Summit을 통해 나는 AI 시대의 개발자가 단순히 AI를 잘 사용하는 사람이 아니라,

AI를 이해하고 적절한 구조 안에서 활용할 수 있는 사람이어야 한다는 생각을 하게 되었다.

앞으로는 도메인과 비즈니스를 이해하고,

AI 시대에 적합한 소프트웨어 아키텍처를 제시할 수 있는 개발자로 성장하고 싶다.

이틀간의 Summit을 마치고, 앞으로 어떤 개발자로 성장해야 할지 다시 생각하게 되었다.

리눅스는 어떻게 부팅될까? (EC2 로그로 따라가 보기)

jaeyoung-dev — Mon, 18 May 2026 01:21:40 +0900

리눅스 부팅 과정을 공부하다 보면 다음과 같은 흐름을 보게 됩니다.

UEFI → GRUB → Kernel → systemd

처음 이 흐름을 봤을 때는 각각의 단어가 무엇을 의미하는것인지 명확하지 않았습니다.

UEFI는 BIOS와 비슷한 것인가?
GRUB는 왜 필요한가?
Kernel은 언제 실행되는가?
systemd는 서비스 관리 도구 아닌가?
...

그래서
AWS EC2에서 Amazon Linux 2023 인스턴스를 직접 실행하고
실제 로그와 파일을 확인하면서 부팅 과정을 따라가 보기로 결정하였습니다.

실습 환경

Cloud Provider : AWS EC2
OS             : Amazon Linux 2023
Instance Type  : t3.micro
Architecture   : x86_64
AMI            : al2023-ami-2023.11.20260514.0-kernel-6.1-x86_64
접속 방식       : SSH

이 실습 환경에서 UEFI → GRUB → Kernel → systemd 부팅 과정을 따라가 보겠습니다.

UEFI

운영체제가 실행되기 전에 부팅에 필요한 초기화 작업을 수행하고,
다음 단계의 부트로더 또는 운영체제 로더로 제어권을 넘기는 단계가 필요합니다.

이 역할을 하는 펌웨어 인터페이스가 UEFI(Unified Extensible Firmware Interface)로,
UEFI는 컴퓨터 전원이 켜졌을 때 운영체제가 실행되기 전에 가장 먼저 동작합니다.

기존에는 BIOS(Basic Input/Output System)라는 전통적인 방식이 사용되었습니다.
UEFI는 BIOS의 한계를 극복하기 위해 만들어진 후속 표준으로 볼 수 있습니다.

EC2에서는 일반 PC처럼 부팅 화면을 직접 보는 것이 아니기 때문에,
OS 내부에 남아 있는 흔적을 통해 UEFI 여부를 확인해야 합니다.

/sys/firmware/efi 디렉터리의 존재 여부로 UEFI 여부를 확인할 수 있습니다.

ls -lah /sys/firmware/efi

각 구성 항목은 다음과 같은 의미를 가집니다.

config_table     : UEFI configuration table 정보
efivars          : UEFI 변수들이 노출되는 위치
fw_platform_size : UEFI 펌웨어의 플랫폼 비트 수 정보
fw_vendor        : 펌웨어 벤더 정보
runtime          : UEFI runtime service 관련 정보
runtime-map      : UEFI runtime memory map
systab           : UEFI system table 정보

/sys/firmware/efi 디렉터리가 존재한다는 것은
커널이 UEFI 환경에서 부팅되었음을 인식했다는 의미입니다.

따라서 이 인스턴스는
Legacy BIOS 방식이 아니라 UEFI 방식으로 부팅되었다고 볼 수 있습니다.

GRUB

UEFI 다음에는 부트로더가 동작합니다. 리눅스 환경에서 대표적인 부트로더가 GRUB입니다.

Amazon Linux 2023에서는 부팅에 필요한 파일들을 /boot 아래에서 확인할 수 있습니다.

ls -lah /boot

vmlinuz-*    : 리눅스 커널 이미지
initramfs-*  : 초기 RAM 파일시스템 이미지
grub2/       : GRUB 관련 파일
efi/         : EFI System Partition 마운트 위치
loader/      : 부팅 항목 관련 파일

부트로더 : 컴퓨터의 전원이 켜진 뒤, 운영체제의 커널을 메모리에 적재하고 실행하는 프로그램

UEFI 환경에서는 EFI System Partition(ESP)이 중요합니다.

Amazon Linux 2023 이미지에서는
기본적으로 이 파티션이 /boot/efi에 마운트되는 것으로 확인됩니다.
즉, /boot와 /boot/efi는
UEFI 이후 GRUB와 커널로 이어지는 부팅 흐름을 확인할 수 있는 중요한 위치입니다.

EFI System Partition(ESP) : UEFI 기반 시스템에서 부팅에 필요한 파일들을 저장하는 전용 파티션으로, 부팅 과정에서 UEFI 펌웨어가 참조하는 파티션에 해당

ls -lah /boot/efi

GRUB 설정은 /boot/grub2에서 확인할 수 있습니다.

ls -lah /boot/grub2

다음으로 확인할 파일은 /proc/cmdline입니다.

/proc/cmdline은 현재 실행 중인 커널이
부팅 시 전달받은 command line 파라미터를 보여주는 가상 파일입니다.

즉, GRUB가 커널을 실행하면서 넘긴 옵션들이
최종적으로 커널에 어떻게 전달되었는지 확인할 수 있습니다.

cat /proc/cmdline

다음과 같은 옵션을 볼 수 있습니다.

BOOT_IMAGE=(hd0,gpt1)/boot/vmlinuz-6.1.170-213.321.amzn2023.x86_64
root=UUID=afcd3653-4916-4996-a80d-b02b83e8be92
console=tty0
console=ttyS0,115200n8
nvme_core.io_timeout=4294967295
rd.emergency=poweroff
rd.shell=0
selinux=1
security=selinux

이 결과를 통해 GRUB가 커널을 실행하면서 BOOT_IMAGE, root, console, selinux
같은 부팅 옵션을 함께 전달했다는 흐름을 확인할 수 있습니다.

Kernel

GRUB가 커널을 실행하면 이제 Linux Kernel 단계로 넘어갑니다.

커널 버전은 다음 명령어로 확인할 수 있습니다.

uname -r

사실 이 정보는 AMI 이름에서도 미리 확인할 수 있습니다.

AMI : al2023-ami-2023.11.20260514.0-kernel-6.1-x86_64

커널은 부팅 과정에서 CPU, 메모리, 디스크, 네트워크 장치, 파일시스템 등을 초기화합니다.

커널 로그는 dmesg로 확인할 수 있습니다.

sudo dmesg | head -n 80

조금 더 보기 쉽게 필터링하면,

sudo dmesg | grep -Ei "Linux version|Command line|EFI|ACPI|NVMe|ENA|XFS|EXT4|systemd" | head -n 100

일부만 캡처한 결과이며,

밑에서 두 번째 줄의 Command line 에서 앞서 /proc/cmdline에서 확인했던
커널 부팅 파라미터와 동일한 내용을 다시 볼 수 있습니다.

구성요소는 다음과 같습니다.

Linux version : 실제 실행된 커널 버전
Command line  : 커널이 받은 부팅 파라미터
EFI           : UEFI 관련 흔적
NVMe          : EC2 루트 볼륨이 NVMe 장치로 인식된 흔적
ENA           : EC2 네트워크 드라이버 관련 흔적
XFS 또는 EXT4 : 파일시스템 마운트 관련 흔적
systemd       : 커널 이후 사용자 공간으로 넘어가는 흔적

GRUB가 커널을 실행하고 부팅 파라미터를 넘기면,
커널은 해당 정보를 바탕으로 시스템을 초기화합니다.
그리고 이 과정의 흔적은 dmesg 로그에서 확인할 수 있습니다.

systemd

커널이 기본적인 초기화를 마치면 사용자 공간의 첫 번째 프로세스를 실행합니다.
이 역할을 systemd가 담당합니다.

PID 1 프로세스를 확인해보면 다음과 같습니다.

ps -p 1 -o pid,comm,args

결과를 통해 커널 이후 systemd가 사용자 공간 초기화를 담당하고 있음을 확인할 수 있으며,

부팅 로그도 확인할 수 있습니다.

journalctl -b --no-pager | head -n 100

journalctl -b는 이번 부팅에서 systemd-journal에 기록된 로그를 보여줍니다.
여기에는 systemd 서비스 로그뿐만 아니라 커널에서 넘어온 초기 부팅 메시지도 함께 포함될 수 있습니다.

systemd가 부팅에 사용한 시간도 확인할 수 있습니다.

systemd-analyze

마지막으로 SSH 서비스 상태를 확인해보면,

systemctl status sshd --no-pager

systemd가 사용자 공간 초기화를 진행한 뒤 SSH 서비스까지 정상적으로 올렸다는 것을 확인할 수 있습니다.

정리

지금까지 Amazon Linux 2023 EC2 인스턴스에서 리눅스 부팅과정을 따라가 보았습니다.

/sys/firmware/efi를 통해 UEFI 방식으로 부팅되었음을 확인했고,
/boot와 /proc/cmdline을 통해 GRUB가 커널을 실행하면서 전달한 부팅 파라미터를 확인했습니다.
dmesg를 통해 커널이 디스크, 네트워크, 파일시스템 등을 초기화하는 과정을 확인했고,
ps -p 1, journalctl, systemd-analyze, systemctl status sshd를 통해 systemd가 사용자 공간의 첫 번째 프로세스로 실행되었고, SSH 서비스까지 올라간 흐름을 확인했습니다.

앞으로 지속적으로 여러 고민거리와 이를 해결하는 과정을 작성하도록 하겠습니다.

amazon-linux-boot-capture.mov

1.7 MB

참고자료

https://www.ibm.com/kr-ko/think/topics/firmware

https://uefi.org/specifications

https://uefi.org/sites/default/files/resources/UEFI_PI_Spec_Final_Draft_1.9.pdf

https://www.gnu.org/

https://docs.aws.amazon.com/linux/al2023/ug/journald.html