13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[작성자:] admin

  • [OpenStack] OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드

    [OpenStack] OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드

    OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드

    OpenStack VXLAN 환경에서 성능이 얼마나 나오는지 궁금하신 분들 많으실 겁니다. VM은 잘 뜨는데, 막상 테넌트 네트워크를 여러 개 나누고 나면 트래픽 처리량이 생각보다 안 나오거나, 지연시간이 튀는 경우가 있거든요. 저도 처음엔 “VXLAN이면 그냥 캡슐화 하나 더 되는 거니까 조금만 느리겠지” 정도로 생각했는데, 실제로 홈랩과 운영 비슷한 구조에서 만져보니 **MTU, 오프로딩(offloading, NIC 하드웨어 처리), OVS(Open vSwitch, 가상 스위치) 경로**에 따라 체감이 꽤 달라지더라고요.

    이번 글에서는 OpenStack VXLAN 기반 오버레이 네트워크를 어떻게 벤치마크하면 좋을지, 그리고 Neutron VXLAN 환경에서 테넌트 격리와 처리량을 어떤 기준으로 봐야 하는지 정리해보겠습니다. 숫자를 지어내는 벤치마크 글은 의미가 없으니까, 이 글은 재현 가능한 측정 방법과 해석 기준에 초점을 맞췄습니다. 지금 OpenStack 네트워크 튜닝 중이시라면 꽤 바로 써먹으실 수 있을 거예요.

    컨트롤러, 컴퓨트 노드, 테넌트 네트워크, 터널 엔드포인트가 보이는 OpenStack VXLAN 개요 이미지입니다.

    1. 왜 OpenStack VXLAN 성능 벤치마크가 중요한가요?

    쉽게 말해 VXLAN(Virtual Extensible LAN, 가상 확장 LAN)은 물리 네트워크 위에 가상 네트워크를 하나 더 얹는 방식입니다. 멀티테넌트 환경에서는 정말 편하거든요. VLAN ID 제한에 덜 묶이고, 테넌트별 네트워크를 유연하게 분리할 수 있으니까요. 근데 여기서 중요한 포인트가 있어요. 편리함과 성능은 항상 같은 방향으로 가지는 않는다는 점 말이에요.

    • 캡슐화(encapsulation, 패킷을 한 번 더 감싸는 작업) 오버헤드가 생깁니다.
    • MTU 설정이 맞지 않으면 단편화(fragmentation, 패킷 쪼개짐)로 성능이 무너질 수 있습니다.
    • OVS나 Linux bridge 경로에 따라 CPU 사용률이 크게 달라집니다.
    • east-west traffic(이스트-웨스트 트래픽, VM 간 내부 통신)과 north-south traffic(노스-사우스 트래픽, 외부와의 통신)을 나눠서 봐야 합니다.

    실제로 써보니까 성능 저하 자체보다 더 무서운 건 병목 지점을 모른 채 감으로 튜닝하는 상황이었어요. 이게 제일 오래 갑니다. 삽질 좀 했습니다 ㅎㅎ

    2. OpenStack VXLAN과 Neutron VXLAN 개념, 쉽게 정리해보겠습니다

    OpenStack 네트워크에서 VXLAN은 보통 Neutron(뉴트론, OpenStack 네트워크 서비스)의 오버레이 메커니즘으로 사용돼요. 각 컴퓨트 노드는 터널 종단점 VTEP(VXLAN Tunnel Endpoint, VXLAN 터널 끝점) 역할을 하고, 테넌트 네트워크 트래픽을 UDP 기반 VXLAN 패킷으로 캡슐화해 전달합니다.

    2-1. 데이터 경로를 이해하면 벤치마크 포인트가 보입니다

    1. VM에서 패킷이 나갑니다.
    2. 가상 NIC를 통해 보안 그룹과 가상 스위치를 통과합니다.
    3. 로컬 브리지에서 VXLAN 캡슐화가 이뤄집니다.
    4. 물리 underlay(언더레이, 실제 네트워크)로 전송됩니다.
    5. 상대 노드에서 디캡슐화(decapsulation, 캡슐 해제) 후 대상 VM으로 들어갑니다.

    여기서 성능 포인트는 명확해요. 가상 스위치 처리, 터널 캡슐화, 물리 NIC, MTU 이 네 군데를 봐야 합니다.

    2-2. VLAN과 VXLAN 비교

    항목 VLAN VXLAN
    격리 방식 L2 태그 기반 오버레이 터널 기반
    확장성 상대적으로 제한적 멀티테넌트 확장에 유리
    설계 복잡도 비교적 단순 터널, MTU, 오프로딩 고려 필요
    성능 변수 상대적으로 적음 캡슐화 오버헤드 영향 있음
    OpenStack 활용 Provider network에 자주 사용 Tenant network에 자주 사용

    벤치마크를 할 때는 “VXLAN이 느리다”가 아니라, 어떤 경로에서 얼마나 손실이 생기는지를 봐야 합니다.

    3. 벤치마크 설계: 오버레이 네트워크 성능을 정확히 측정하려면

    제가 직접 해보니 벤치마크가 실패하는 가장 흔한 이유는 측정 항목이 너무 단순하다는 거였어요. `iperf3` 한 번 돌려보고 끝내면, 그건 네트워크 테스트라기보다 순간 샘플에 가까우니까요.

    3-1. 최소 측정 항목

    • 처리량(throughput, 초당 전송량): TCP/UDP 각각 확인
    • 지연시간(latency, 왕복 시간): ping 또는 fping으로 확인
    • 패킷 손실(packet loss): UDP 테스트에서 특히 중요
    • CPU 사용률: 컴퓨트 노드의 `ovs-vswitchd`, `qemu-kvm`, `softirq` 확인
    • MTU 일관성: 인스턴스, TAP, 브리지, 물리 NIC가 연결되는지 확인

    3-2. 테스트 시나리오

    1. 같은 컴퓨트 노드 내 VM 간 통신
    2. 다른 컴퓨트 노드 간 VM 통신
    3. 같은 테넌트 네트워크 내 다수 VM 동시 통신
    4. 서로 다른 테넌트 간 격리 검증
    5. floating IP 또는 router를 통한 외부 통신

    여기서 두 번째와 세 번째가 핵심이에요. 첫 번째만 보면 터널 영향이 덜 보일 수 있거든요. 반대로 크로스-노드(cross-node, 노드 간) 테스트를 해보면 오버레이 네트워크 성능 차이가 확실히 드러납니다.

    4. 실전 구현: OpenStack VXLAN 테스트 환경 준비

    이제 실제로 측정 가능한 구조를 만들어보겠습니다. 예시는 OpenStack CLI 기준으로 적겠습니다. 배포판은 다양하지만, 개념은 거의 비슷해요.

    4-1. 테넌트 네트워크 생성

    openstack network create demo-vxlan-net
    openstack subnet create demo-vxlan-subnet \
      --network demo-vxlan-net \
      --subnet-range 10.10.10.0/24
    
    openstack router create demo-router
    openstack router add subnet demo-router demo-vxlan-subnet

    환경에 따라 외부 네트워크 연결도 필요합니다.

    openstack router set demo-router --external-gateway public

    4-2. 테스트용 인스턴스 2대 이상 배치

    openstack server create vxlan-test-1 \
      --flavor m1.small \
      --image ubuntu \
      --network demo-vxlan-net \
      --key-name mykey
    
    openstack server create vxlan-test-2 \
      --flavor m1.small \
      --image ubuntu \
      --network demo-vxlan-net \
      --key-name mykey

    여기서 가능하면 서로 다른 컴퓨트 노드에 올리는 게 좋아요. 스케줄러 힌트나 가용성 영역을 활용하면 더 명확하게 분리할 수 있습니다.

    4-3. ML2 VXLAN 설정 확인

    배포 환경마다 파일 위치가 다를 수 있지만, 핵심은 ML2 plugin(ML2 플러그인)과 VXLAN 타입 드라이버가 활성화되어 있는지에요.

    [ml2]
    type_drivers = flat,vlan,vxlan
    tenant_network_types = vxlan
    mechanism_drivers = openvswitch,l2population
    
    [ml2_type_vxlan]
    vni_ranges = 1001:2000

    `l2population`은 브로드캐스트/플러딩을 줄이는 데 도움이 되는 기능으로 잘 알려져 있어요. 대규모 환경일수록 의미가 커집니다.

    Neutron ML2 설정, VNI 범위, 각 컴퓨트 노드의 VXLAN 터널 연결 관계를 보여주는 이미지입니다.

    4-4. MTU 확인은 꼭 하셔야 합니다

    VXLAN은 추가 헤더가 붙기 때문에 underlay MTU보다 tenant MTU를 조금 보수적으로 잡는 경우가 많아요. 이 부분을 놓치면 `iperf3`는 애매하게 나오고, 대용량 전송에서만 문제가 재현되기도 합니다. 저도 처음엔 보안 그룹만 의심했는데, 결국 MTU 문제였던 적이 있었어요.

    ip link show
    ip addr
    ping -M do -s 1472 <target_ip>

    `-M do`는 경로 MTU를 강제로 확인할 때 유용해요. 패킷 크기를 조금씩 조정해보면 어디서 단편화가 발생하는지 감이 옵니다.

    5. 성능 측정 방법: iperf3, ping, 시스템 지표를 같이 보세요

    5-1. 기본 처리량 측정

    테스트 VM 한쪽에서는 서버를 띄우고, 다른 쪽에서는 클라이언트로 붙습니다.

    # server
    iperf3 -s
    
    # client
    iperf3 -c 10.10.10.20 -t 30 -P 4

    여기서 `-P 4`처럼 병렬 스트림(parallel stream, 동시 세션)을 주는 이유는 단일 세션만으로는 경로 활용도를 다 못 볼 수 있기 때문이에요.

    5-2. UDP와 손실률 확인

    iperf3 -c 10.10.10.20 -u -b 1G -t 30

    UDP는 대역폭을 강제로 밀어붙이니까 손실과 지터(jitter, 지연 변동폭)를 보기 좋아요. 다만 숫자만 보고 “실사용도 이렇다”고 단정하면 안 돼요. 어디까지나 한계 구간을 찾는 용도에 가깝습니다.

    5-3. 지연시간과 격리 검증

    ping -c 20 10.10.10.20
    
    openstack network create isolated-net
    openstack subnet create isolated-subnet \
      --network isolated-net \
      --subnet-range 10.20.20.0/24

    서로 다른 테넌트 네트워크에서 직접 통신이 안 되는지 확인해보세요. 테넌트 격리는 보안 기능이자 성능 분석의 기준선이에요. 격리가 흐트러지면 벤치마크 이전에 설계부터 다시 봐야 합니다.

    5-4. 호스트 측 관찰 포인트

    top
    htop
    sar -n DEV 1
    ip -d link show
    ovs-vsctl show
    ovs-ofctl dump-ports br-tun

    성능이 기대보다 안 나오는데 VM 내부는 멀쩡하다면, 호스트의 softirq나 OVS 포트 카운터를 같이 봐야 해요. 근데 여기서 중요한 건, 네트워크만 보지 말고 CPU를 같이 보라는 점이에요. 오버레이는 생각보다 CPU 영향을 받거든요.

    6. ⚠️ 트러블슈팅: 실제로 자주 막히는 지점

    이 섹션은 정말 중요해요. 제가 홈랩에서 OpenStack 네트워크 만질 때 제일 오래 잡아먹은 부분들이거든요.

    6-1. MTU 불일치

    • 증상: TCP는 되는데 대용량 전송에서 처리량이 애매하게 떨어짐
    • 원인: VXLAN 캡슐화 헤더를 고려하지 않은 MTU 설정
    • 해결: 인스턴스 NIC, TAP, `br-int`, `br-tun`, 물리 NIC까지 경로 전체 MTU 점검

    6-2. 오프로딩 설정 이슈

    • 증상: CPU 사용률이 과하게 올라가고 처리량이 들쭉날쭉함
    • 원인: NIC offload와 가상화 경로 조합 문제
    • 해결: `ethtool -k`로 현재 상태를 보고 변경 전후 비교 측정
    ethtool -k eth0

    이건 환경마다 정답이 달라요. 무조건 켜라, 무조건 꺼라 식으로 가면 위험해요. 그래서 반드시 변경 전후를 같은 조건으로 비교해야 합니다.

    6-3. 보안 그룹과 conntrack 병목

    • 증상: 연결 수가 늘면 응답이 갑자기 무거워짐
    • 원인: stateful filtering(상태 기반 필터링)과 connection tracking 부담
    • 해결: 테스트 시나리오를 단순화하고, 보안 정책 영향도 분리해서 확인

    6-4. 같은 노드와 다른 노드 성능 차이

    같은 컴퓨트 노드 안에서는 생각보다 잘 나오는데, 다른 노드로 넘어가는 순간 성능이 달라지는 경우가 많아요. 이럴 때는 거의 대부분 터널 경로 또는 물리 underlay를 의심하게 됩니다.

    VM 간 iperf3 측정, 호스트 CPU 사용률, MTU 점검 포인트가 함께 보이는 실전 운영 이미지입니다.

    7. 검증과 결과 해석: 숫자보다 중요한 것

    벤치마크 결과를 볼 때 저는 보통 아래 순서로 해석해요. 숫자 하나만 보고 결론 내리면 나중에 꼭 후회하더라고요.

    1. 같은 노드와 다른 노드 간 격차가 큰가
    2. TCP와 UDP 결과 차이가 과도한가
    3. 지연시간 평균보다 편차가 큰가
    4. 호스트 CPU 사용률이 병목처럼 보이는가
    5. 테넌트 수 증가 시 성능 하락 패턴이 급격한가

    예를 들어 처리량이 조금 낮아도 지연시간이 안정적이고 손실이 적다면, 실서비스에서는 충분히 좋은 결과일 수 있어요. 반대로 순간 최대 처리량이 높아도 CPU가 포화되고 지터가 심하면 운영 입장에서는 불안한 구조죠.

    검증 항목 좋은 신호 주의 신호
    처리량 반복 측정 시 편차가 작음 테스트마다 편차가 큼
    지연시간 평균과 최대값 차이가 적당함 간헐적 스파이크 발생
    패킷 손실 UDP 부하에서도 통제 가능 부하 시 급격히 증가
    CPU 사용률 여유가 있음 ovs-vswitchd 또는 softirq 집중
    격리 상태 테넌트 간 통신 차단 명확 정책 누락 또는 라우팅 혼선

    오버레이 네트워크 성능은 결국 설계와 운영 습관의 결과물이에요. 그래서 결과 보고서에는 숫자만 넣지 말고, 테스트 조건도 같이 남기시는 걸 권장합니다. 다음에 다시 비교할 때 진짜 큰 도움이 돼요.

    OpenStack VXLAN 벤치마크 결과와 지연시간 처리량을 보여주는 대시보드 이미지

    처리량, 지연시간, CPU 사용률을 함께 보여주는 OpenStack VXLAN 벤치마크 결과 시각화 이미지입니다.

    8. 정리와 다음 단계: OpenStack 네트워크 튜닝은 이렇게 이어가시면 됩니다

    정리해보면 OpenStack VXLAN 벤치마크에서 중요한 건 단순 최고 속도가 아니에요. Neutron VXLAN 환경에서 테넌트 격리가 제대로 되는지, 크로스-노드 트래픽이 안정적인지, MTU와 OVS 경로가 일관적인지, 그리고 호스트 CPU가 어디서 쓰이는지를 같이 봐야 합니다.

    제가 직접 해보니 가장 효과가 컸던 접근은 이것이었어요.

    1. 같은 노드와 다른 노드 결과를 분리해서 기록합니다.
    2. TCP, UDP, ping을 각각 따로 봅니다.
    3. 문제가 보이면 MTU와 오프로딩부터 확인합니다.
    4. 그 다음에 보안 그룹, conntrack, underlay를 봅니다.

    이 순서로 가면 삽질을 꽤 줄일 수 있어요. 드디어 됐다! 싶은 순간이 오거든요.

    OpenStack VXLAN 성능 최적화 체크리스트와 비교 요약 인포그래픽

    MTU, 오프로딩, OVS, 테넌트 격리, 처리량 검증 항목을 한눈에 정리한 요약 인포그래픽입니다.

    자주 묻는 질문

    Q1. VXLAN이면 무조건 VLAN보다 느린가요?

    무조건 그렇지는 않아요. 캡슐화 오버헤드는 있지만, 실제 체감은 NIC 성능, CPU, OVS 구성, underlay 품질에 따라 달라집니다.

    Q2. 벤치마크는 어떤 도구부터 쓰면 좋을까요?

    가볍게는 `ping`, `iperf3`, `sar`, `ethtool`, `ovs-vsctl` 정도면 시작하기 좋아요. 도구보다 중요한 건 같은 조건으로 반복 측정하는 습관입니다.

    Q3. 테넌트 격리는 어떻게 검증하나요?

    서로 다른 테넌트 네트워크에 VM을 두고 직접 통신 가능 여부, 라우터 연결 여부, 보안 그룹 정책을 분리해서 확인하시면 돼요.

    다음 글에서는 Open vSwitch 기반에서 `br-int`, `br-tun`, provider network 경로를 좀 더 깊게 파서, 어디서 병목이 생기는지 보는 방법을 다뤄볼 예정입니다. 이전 글에서 다룬 Linux 네트워크 기본기와 함께 보시면 훨씬 이해가 잘 될 거예요.

  • [OpenStack] OpenStack Manila 도입 1년 회고

    [OpenStack] OpenStack Manila 도입 1년 회고

    [OpenStack] OpenStack Manila 도입 1년 회고

    프라이빗 클라우드 파일 스토리지 이야기를 하면, 많은 분들이 처음엔 Cinder(신더, 블록 스토리지)나 Swift(스위프트, 오브젝트 스토리지)부터 떠올리시더라고요. 저도 그랬습니다. 그런데 VM(가상머신) 여러 대와 컨테이너 워크로드가 같이 굴러가기 시작하면, 결국 팀에서 꼭 묻는 질문이 하나 나옵니다. “공유 폴더처럼 쓸 수 있는 스토리지는 없나요?” 바로 그 지점에서 OpenStack Manila가 등장합니다.

    저는 지난 1년 동안 홈랩과 사내와 유사한 형태의 프라이빗 환경에서 Manila 운영 방식을 꽤 집요하게 다듬어봤습니다. 처음엔 “이게 Nova(노바, 컴퓨트)나 Neutron(뉴트론, 네트워크)처럼 그냥 붙이면 되겠지” 했었는데요. 막상 들어가 보니 기능은 명확한데, 프라이빗 클라우드 파일 스토리지 운영할 때 고려할 포인트가 생각보다 많더라고요. 특히 Manila로 파일 스토리지를 운영하면 자동화가 편해지는 대신, 네트워크와 백엔드 설계를 대충 하면 나중에 꼭 되돌아오니까요. 오늘은 OpenStack Manila 도입 1년 회고라는 관점에서, 좋았던 점과 아쉬웠던 점을 솔직하게 정리해보겠습니다.

    OpenStack Manila, 컴퓨트 노드, 스토리지 백엔드, 사용자 네트워크가 어떻게 연결되는지 한눈에 보여주는 아키텍처 이미지가 들어갈 자리입니다.

    1. 왜 OpenStack Manila를 보게 되었는가

    처음 문제는 단순했습니다. 프로젝트마다 VM 안에 데이터를 따로 넣어두다 보니, 배치 작업 서버와 애플리케이션 서버가 같은 데이터를 봐야 하는 상황에서 계속 복사본이 생겼거든요. 이러면 데이터 일관성도 깨지고, 백업 정책도 꼬이고, 장애가 나면 복구 지점도 애매해집니다.

    프라이빗 클라우드 파일 스토리지 요구가 계속 나오면서 선택지를 세 가지로 놓고 봤습니다.

    • VM 내부 디스크를 각자 관리한다
    • Cinder 볼륨을 붙여서 우회한다
    • 공유 파일 스토리지 자체를 서비스로 제공한다

    세 번째가 바로 OpenStack Manila, 즉 프라이빗 클라우드 파일 스토리지 서비스의 자리였습니다. 실제로 써보니까, 파일 공유를 사람 손으로 매번 만들어주는 방식보다 API(에이피아이, 프로그램 호출 인터페이스) 기반으로 표준화하는 게 훨씬 관리가 잘 되더라고요.

    2. OpenStack Manila란 무엇인가

    쉽게 말해 OpenStack Manila는 공유 파일 시스템을 서비스 형태로 제공하는 컴포넌트입니다. Cinder가 블록 디바이스를 내주는 역할이라면, Manila는 NFS(엔에프에스, 네트워크 파일 시스템)나 SMB(에스엠비, 파일 공유 프로토콜) 같은 형태의 공유 스토리지를 만들어주는 쪽에 가깝습니다.

    처음엔 이름이 좀 낯설죠. 저도 처음엔 “왜 이름이 Manila지?” 싶었는데, 기능 자체는 꽤 직관적입니다. 핵심 개념만 잡아두면 어렵지 않거든요.

    핵심 개념 한 번에 정리

    • Share: 실제로 사용자에게 제공되는 파일 공유 자원
    • Share Type: 성능, 백엔드, 기능 정책을 구분하는 템플릿
    • Share Network: 공유 스토리지가 붙을 네트워크 정보
    • Backend Driver: CephFS(세프에프에스), NetApp, Generic driver 같은 실제 구현체와 연결되는 계층
    • Access Rule: 어떤 IP나 사용자에게 접근을 허용할지 정하는 규칙

    여기서 중요한 포인트! Manila 자체가 스토리지를 저장하는 제품은 아닙니다. 정확히는 백엔드 파일 스토리지를 OpenStack 방식으로 관리해주는 제어 계층이라고 생각하시면 돼요. 이 차이를 이해 못 하면 설계가 꼬입니다.

    다른 스토리지와 무엇이 다른가

    구분 주 용도 접근 방식 운영 시 느낌
    Ephemeral Disk 인스턴스 로컬 작업 VM 내부 로컬 디스크 빠르지만 수명과 이동성 제약이 크다
    Cinder 데이터베이스, 단일 서버 디스크 블록 디바이스 마운트 명확하지만 다중 공유에는 부적합
    Swift 백업, 아카이브, 객체 저장 HTTP API 확장성은 좋지만 파일시스템처럼 쓰긴 어렵다
    Manila (프라이빗 클라우드 파일 스토리지) 공유 파일 스토리지 NFS/SMB 등 협업과 공용 데이터셋에 강하다

    3. 도입 전에 꼭 봐야 했던 설계 포인트

    제가 1년 운영하면서 느낀 건, Manila는 설치보다 설계가 더 중요하다는 점입니다. 특히 아래 세 가지를 먼저 정리해야 나중에 덜 고생합니다.

    1. 백엔드 선택: CephFS처럼 분산 파일 시스템을 붙일지, 전통적인 NAS(나스, 네트워크 스토리지)를 붙일지 결정해야 한다
    2. 네트워크 분리: 스토리지 트래픽과 테넌트 트래픽을 어느 정도 분리할지 판단해야 한다
    3. 운영 권한 모델: 누가 share를 만들고, 누가 접근 규칙을 열 수 있는지 기준을 세워야 한다

    사실 여기서 많이들 놓치는 게 두 번째입니다. 프라이빗 클라우드 파일 스토리지는 결국 네트워크 영향을 강하게 받습니다. 스토리지 백엔드는 멀쩡한데도 MTU(엠티유, 최대 전송 단위)나 라우팅, 보안그룹 정책 때문에 체감 성능이 무너지는 경우를 꽤 봤거든요.

    4. OpenStack Manila 실전 구현: 제가 실제로 잡았던 기본 흐름

    이제 구현 얘기를 해보겠습니다. 환경마다 패키지 설치 방식은 다를 수 있으니, 여기서는 운영 개념과 명령 흐름 위주로 정리하겠습니다. 저는 처음에 모든 설정을 한 번에 넣으려다가 꼬여서, 결국 가장 단순한 형태부터 올리는 방식으로 갔습니다. 이게 훨씬 낫더라고요.

    1) 서비스 상태 확인

    openstack share service list
    openstack endpoint list --service manila
    openstack network list
    

    맨 처음엔 화려한 기능보다 서비스가 보이느냐부터 확인했습니다. 생각보다 기본 서비스 등록이나 엔드포인트 누락이 자주 나옵니다.

    2) share type 생성

    openstack share type create default_share false
    openstack share type set --extra-specs snapshot_support=true default_share
    

    Share Type은 나중에 Manila 운영 정책의 중심이 됩니다. 성능 클래스, 스냅샷 허용 여부, 백엔드 매핑 기준을 여기에 녹여두면 사용자 설명이 쉬워지거든요.

    3) share network 생성

    openstack share network create \
      --name manila-share-net \
      --neutron-net-id <tenant-network-id> \
      --neutron-subnet-id <tenant-subnet-id>
    

    여기서 저도 한 번 크게 삽질했습니다. 인스턴스가 붙은 네트워크와 share network 관계를 대충 맞추면 될 줄 알았는데, 실제로는 접근 경로와 라우팅이 명확해야 마운트 단계에서 덜 막힌다더라고요.

    4) 공유 스토리지 생성

    openstack share create \
      --name project-data \
      --share-type default_share \
      --share-network manila-share-net \
      --size 100 \
      NFS
    

    생성 직후 바로 쓰려고 하면 안 됩니다. 상태가 available이 될 때까지 기다려야 합니다.

    openstack share list
    openstack share show project-data
    
    OpenStack Manila share type과 share network 구성 흐름 이미지

    Share type, share network, backend driver, tenant network가 어떤 순서로 연결되는지 보여주는 구성 다이어그램이 들어갈 자리입니다.

    5) 접근 제어 추가

    openstack share access create project-data ip 10.10.20.15
    openstack share access list project-data
    

    Manila 운영하면서 가장 체감이 좋았던 부분 중 하나가 이겁니다. 예전엔 파일 공유를 열 때 네트워크팀, 스토리지팀, 운영팀이 각각 손대야 했었는데요. Manila를 붙이니 최소한 권한과 절차가 API로 정리되니까 일이 많이 단순해졌습니다.

    6) 인스턴스에서 마운트

    sudo mkdir -p /mnt/project-data
    sudo mount -t nfs <share-export-location> /mnt/project-data
    df -h
    mount | grep project-data
    

    여기서 export location이 올바르게 나오는지 확인해야 합니다. 실제 사용자는 이 지점만 보기 때문에, 앞단 자동화가 아무리 좋아도 마운트 실패하면 평가가 박해집니다. 냉정하죠 ㅎㅎ

    7) 설정 예시

    [DEFAULT]
    default_share_type = default_share
    enabled_share_backends = cephfsnfs
    
    [cephfsnfs]
    share_backend_name = CEPHFSNFS
    driver_handles_share_servers = false
    

    설정은 백엔드마다 달라지니 그대로 복붙하시면 안 되고, 운영 중인 백엔드 문서와 정확히 맞춰야 합니다. 다만 관점 자체는 비슷합니다. 어떤 백엔드를 활성화할지, 드라이버가 share server를 직접 다룰지 여부를 정하는 구조니까요.

    5. 1년 운영하며 좋았던 점: 명(明)

    OpenStack Manila 운영을 1년쯤 해보니까, 분명 장점이 있습니다. 이건 꽤 명확했습니다.

    • 셀프서비스화: 사용 부서가 요청만 하면 표준 절차로 공유 스토리지를 만들 수 있다
    • 정책 통일: share type 중심으로 Manila 운영 기준을 맞추기 쉽다
    • 접근 제어 가시성: 누가 어떤 share에 접근 가능한지 추적이 쉬워진다
    • 자동화 친화적: Terraform(테라폼, 인프라 선언형 자동화)이나 내부 포털과 엮기 좋다

    특히 프로젝트 단위로 수명주기를 관리할 때 편했습니다. 인스턴스는 바뀌어도 데이터 공유 계층은 유지할 수 있으니, 작업 서버를 새로 올려도 공유 데이터를 다시 설계할 필요가 없거든요. 이거 진짜 편하더라고요.

    또 하나는 운영 책임 구간이 분리된다는 점입니다. 예전엔 “공유 폴더 느려요”라는 말이 나오면 원인 범위가 너무 넓었는데, Manila 도입 후에는 적어도 API 계층, 네트워크 계층, 백엔드 계층으로 잘게 나눠서 볼 수 있었습니다.

    6. 1년 운영하며 아쉬웠던 점: 암(暗)

    근데 여기서 중요한 게 있습니다. Manila는 만능이 아닙니다. 오히려 기대치를 너무 높게 잡으면 실망하기 쉽습니다.

    첫째, 문제의 절반은 결국 백엔드와 네트워크입니다

    사용자 입장에서는 OpenStack Manila가 파일 스토리지를 제공하는 것처럼 보이지만, 실제 체감 품질은 백엔드 스토리지와 네트워크 설계에 크게 좌우됩니다. 즉, Manila가 느린 게 아니라 뒤쪽이 느린 경우가 많습니다. 이걸 분리해서 설명하는 데 시간이 꽤 들었습니다.

    둘째, 권한 설계가 느슨하면 금방 복잡해집니다

    처음엔 “필요한 사람에게 IP만 열어주면 되지” 했었는데요. 몇 달 지나면 예외 규칙이 누적됩니다. 접근 규칙을 누가 승인하는지, 만료 기준은 뭔지, 프로젝트 종료 시 어떻게 닫을지 초반에 정해야 합니다.

    셋째, 장애 분석이 생각보다 단순하지 않습니다

    마운트 실패 하나만 놓고 봐도 원인이 다양합니다. DNS(디엔에스, 이름 해석), 라우팅, 보안그룹, export location, 백엔드 상태, 커널 NFS 클라이언트 옵션까지 봐야 하거든요. 처음엔 “왜 이렇게 복잡하지?” 싶었는데, 결국 파일 공유라는 게 여러 계층이 맞물리는 서비스라 그렇더라고요.

    7. ⚠️ 실제로 겪었던 트러블슈팅

    이 섹션은 좀 현실적으로 적어볼게요. 저도 처음엔 문서만 보면 금방 될 줄 알았는데, 실제 Manila 운영에선 아래 이슈를 자주 만났습니다.

    문제 1. share는 생성됐는데 마운트가 안 되는 경우

    • 증상: `mount.nfs: access denied by server`
    • 원인 후보: 접근 규칙 누락, 클라이언트 IP 변경, 잘못된 네트워크 경로
    • 해결: `openstack share access list`로 허용 규칙 확인 후, 실제 클라이언트 IP와 비교
    openstack share access list project-data
    ip addr
    ip route
    

    생각보다 NAT(엔에이티, 주소 변환)나 점프 구간 때문에 사용자가 보는 IP와 실제 서버가 보이는 IP가 다른 경우가 있었습니다.

    문제 2. 생성 속도는 괜찮은데 체감 성능이 들쭉날쭉한 경우

    • 증상: 어떤 VM은 빠르고 어떤 VM은 유독 느림
    • 원인 후보: 네트워크 경로 차이, MTU 불일치, 혼잡 구간 존재
    • 해결: 경로별 성능 차이를 먼저 분리 측정하고, Manila 문제로 단정하지 않기

    여기서 제가 배운 건 하나입니다. 스토리지 문제를 API 문제로 착각하지 말 것. 관리 평면(control plane)과 데이터 평면(data plane)을 분리해서 봐야 합니다.

    문제 3. 공유는 살아 있는데 운영 기록이 남지 않는 경우

    • 증상: 누가 왜 접근 규칙을 열었는지 추적이 어려움
    • 원인 후보: 수동 작업, 표준 요청 절차 부재
    • 해결: 변경 요청 번호나 티켓 번호를 share 이름 또는 메타데이터 규칙에 반영

    이건 기술 이슈 같지 않지만 실제 Manila 운영에선 꽤 큽니다. 나중에 감사나 보안 점검 때 힘들어지거든요.

    문제 4. 기대보다 운영 난도가 높게 느껴지는 경우

    사실 OpenStack 스토리지는 모두 그렇지만, Manila도 “기능 추가”보다 “운영 모델 정리”가 더 어렵습니다. 백엔드 드라이버 특성, 네트워크 토폴로지, 접근 정책이 모두 연결되니까요. 그래서 제가 추천하는 방식은 이겁니다.

    1. 처음엔 딱 한 가지 share type만 운영한다
    2. 접근 제어는 가장 보수적으로 시작한다
    3. 사용자 수요가 확인된 뒤에 스냅샷, 멀티 백엔드, 성능 클래스 분리를 확장한다

    한 번에 다 하려 하지 않는 것, 이게 제일 중요했습니다.

    8. 검증과 운영 결과: 무엇이 달라졌나

    그럼 1년 운영해서 뭐가 남았냐, 이 질문이 제일 중요하겠죠. 제가 직접 해보니 결과는 꽤 분명했습니다.

    • 프라이빗 클라우드 파일 스토리지 개설 절차가 표준화됐다
    • 프로젝트별 데이터 공유 방식이 단순해졌다
    • 수동 NAS 작업이 줄어들었다
    • 장애 시 원인 구간을 더 빨리 좁힐 수 있게 됐다

    반대로, 운영 문서와 접근 정책이 없으면 Manila 운영은 금방 복잡해진다는 것도 확인했습니다. 즉, OpenStack Manila의 성공 조건은 설치가 아니라 운영 규칙이에요.

    openstack share list
    openstack share service list
    openstack share type list
    openstack share network list
    

    검증할 때는 단순히 리소스가 보이는지보다, 아래 항목을 같이 확인했습니다.

    1. Share 상태가 `available`인지
    2. 접근 규칙이 기대한 대상에만 열려 있는지
    3. 실제 인스턴스에서 마운트와 읽기/쓰기가 되는지
    4. 장애 시 로그와 변경 이력이 추적 가능한지
    OpenStack Manila 운영 결과와 검증 체크리스트 대시보드 이미지

    Share 상태, 접근 규칙, 마운트 성공 여부, Manila 운영 지표를 한 화면에서 점검하는 대시보드 이미지가 들어갈 자리입니다.

    9. FAQ와 마무리: 다음 단계는 어떻게 가면 좋을까

    자주 묻는 질문

    • Q. Manila는 모든 환경에서 꼭 필요한가요?
      아닙니다. 프라이빗 클라우드 파일 스토리지 요구가 적고 운영 단순성이 더 중요하면 굳이 넣지 않는 게 나을 수도 있습니다.
    • Q. 프라이빗 클라우드 파일 스토리지로 바로 도입해도 될까요?
      가능은 하지만, 먼저 한두 팀 대상 파일 공유 서비스로 시작해 Manila 운영 모델을 검증하는 걸 추천합니다.
    • Q. OpenStack 스토리지 중 우선순위는 어떻게 잡아야 하나요?
      블록, 오브젝트, 파일의 요구가 다르니 워크로드 기준으로 판단해야 합니다. “공유 파일”이 핵심이면 Manila가 후보가 됩니다.

    정리해보면 이렇습니다. OpenStack Manila는 프라이빗 클라우드 파일 스토리지 운영을 표준화하는 데 꽤 좋은 도구입니다. 다만 제품만 올린다고 끝나는 게 아니고, 백엔드 선택과 네트워크 설계, 접근 정책, 운영 문서화까지 같이 가야 진짜 효과가 납니다.

    저도 처음엔 이게 뭔가 싶었는데, 1년쯤 지나고 나니 보이더라고요. Manila 운영의 핵심은 “기능 활성화”가 아니라 “운영 경계 정의”였습니다. 이걸 빨리 이해할수록 삽질이 줄어들더라고요.

    다음 글에서는 OpenStack Manila 운영 시 백엔드 선택 기준, 예를 들면 CephFS 계열과 전통적인 NAS 연동 관점에서 무엇을 봐야 하는지 더 구체적으로 다뤄볼 예정입니다. 이전 글에서 다뤘던 OpenStack 네트워크 설계 내용과도 연결해서 보시면 훨씬 이해가 쉬우실 겁니다.

    OpenStack Manila 도입 전후 장단점 비교 인포그래픽

    도입 전 수동 운영 방식과 도입 후 표준화된 프라이빗 클라우드 파일 스토리지 운영 방식을 비교하는 요약 인포그래픽이 들어갈 자리입니다.

    혹시 지금 OpenStack Manila 도입을 고민 중이시라면, 제 경험상 가장 먼저 할 일은 하나입니다. “누가 어떤 데이터를 어떤 방식으로 공유해야 하는가”를 먼저 적어보세요. 그 다음에 Manila를 붙이면 훨씬 덜 헤맵니다. 이 순서, 생각보다 정말 중요합니다. 🎉

  • [Game] 에픽 무료게임 1년 수령 후기: 실제 가치와 숨겨진 비용 분석

    [Game] 에픽 무료게임 1년 수령 후기: 실제 가치와 숨겨진 비용 분석

    에픽 무료게임 1년 수령 후기: 실제 가치와 숨겨진 비용 분석

    에픽 무료게임이 정말 이득일까요? 처음엔 그냥 안 받으면 손해 같은 느낌이 들죠. 저도 그랬습니다. 에픽 게임즈 스토어에서 기간 한정으로 게임을 무료 배포할 때마다 일단 라이브러리에 넣어두면 언젠가 하겠지 싶었거든요. 근데 1년 정도 꾸준히 챙겨보니까 생각보다 재밌는 결론이 나오더라고요. 무료는 맞는데, 완전히 공짜는 아니었습니다. 돈은 안 나가도 시간, 집중력, 플랫폼 분산 같은 숨겨진 비용이 분명히 있었거든요. 혹시 여러분도 스팀은 스팀대로, 에픽은 에픽대로 라이브러리만 쌓이고 실제 플레이는 거의 못 하고 계신가요? 오늘은 제가 직접 겪은 기준으로 에픽 무료게임의 실제 가치, 그리고 게임 구독 비용과 비교했을 때 어디서 이득이고 어디서 함정이 생기는지 정리해보겠습니다.

    이 글은 특정 게임 추천 글이라기보다, 무료 게임 가치를 비용 관점에서 보는 글입니다. 숫자를 억지로 끼워 맞추기보다, 실제로 1년 동안 챙겨보면서 느낀 패턴과 판단 기준을 중심으로 풀어볼게요.

    에픽 무료게임을 1년간 모으면서 생기는 가치와 숨은 비용을 한눈에 보여주는 개요 이미지입니다.

    에픽 무료게임, 쉽게 말해 어떤 가치가 있나

    쉽게 말해 에픽 무료게임은 현금을 쓰지 않고 게임 선택지를 확보하는 방식입니다. 여기서 중요한 건 소유와 이용의 차이예요. 계정 라이브러리에 등록되는 것과 실제로 플레이하는 것이 전혀 다르다는 뜻이죠. 저도 처음엔 라이브러리에 들어가기만 하면 이득이라고 생각했었는데, 실제로 써보니까 그건 반만 맞는 말이더라고요.

    • 장점 1: 구매 결제 없이 게임 접점을 넓힐 수 있습니다.
    • 장점 2: 평소 안 사던 장르를 테스트하기 좋습니다.
    • 장점 3: 가족이나 지인과 멀티플레이를 맞추기 쉬운 경우가 있습니다.
    • 단점 1: 라이브러리만 늘고 실제 플레이율은 낮아질 수 있습니다.
    • 단점 2: 스팀 vs 에픽 환경 분산으로 관리 피로가 생깁니다.
    • 단점 3: 무료 배포 일정에 맞춰 확인하는 습관 자체가 피로가 될 수 있습니다.

    핵심은 간단합니다. 내가 실제로 플레이한 게임만 가치가 생긴다는 겁니다. 이걸 기준으로 보면 무료 게임 가치가 꽤 냉정하게 보입니다.

    1년 동안 느낀 실제 가치: 무료라고 다 이득은 아니었습니다

    제가 1년 정도 챙겨보면서 느낀 가장 큰 장점은, 의외의 게임을 만나게 된다는 점이었습니다. 원래라면 결제 버튼 앞에서 망설였을 게임도 무료로 받아두면 부담이 없거든요. 특히 장르 실험용으로는 꽤 좋습니다. 액션, 퍼즐, 전략, 로그라이크 같은 장르를 얕게 찍어보기에는 괜찮았어요.

    반대로 가장 큰 문제는 인지 부하였습니다. 라이브러리가 늘어날수록 뭐가 있는지 기억도 안 나고, 설치까지 가는 비율은 더 떨어지더라고요. 처음엔 분명 이득 같았는데, 나중엔 체크리스트 하나 더 생긴 느낌이었습니다. 인프라 엔지니어 하면서 리소스 모니터링은 익숙한데, 게임 라이브러리도 비슷했어요. 수집량이 아니라 실제 사용률을 봐야 하더군요.

    여기서 중요한 포인트! 에픽 무료게임의 가치는 게임 개수로 계산하면 거의 틀립니다. 실제로는 아래 네 가지로 봐야 합니다.

    1. 내가 원래 살 생각이 있던 게임이 포함됐는가
    2. 받은 뒤 3개월 안에 실제 설치했는가
    3. 1시간 이상 플레이했는가
    4. 다른 구독 서비스나 기존 스팀 라이브러리와 중복되지 않는가

    에픽 게임즈 스토어와 게임 구독 비용 비교

    많이들 헷갈리는 부분이 이겁니다. 에픽 무료게임은 공짜 수령이고, 게임 구독 비용은 월 단위 지출이잖아요. 겉으로 보면 당연히 무료가 이겨 보이는데, 실제로는 사용 방식이 다릅니다.

    항목 에픽 무료게임 게임 구독 서비스 스팀 직접 구매
    초기 비용 낮음 월 구독료 발생 게임별 결제
    선택 방식 배포작 중심 카탈로그 중심 원하는 게임 직접 선택
    소유 감각 계정 라이브러리 등록 구독 유지 전제 구매 라이브러리 누적
    숨은 비용 확인 습관, 플랫폼 분산, FOMO 안 해도 나가는 비용 충동구매 가능성
    추천 사용자 가볍게 모으는 타입 자주 플레이하는 타입 취향이 분명한 타입

    정리하면 이렇습니다. 에픽 무료게임은 지출 절감 도구라기보다 기회 확보 도구에 가깝습니다. 반면 구독은 많이 할수록 이득, 적게 할수록 손해 구조고요. 스팀 직접 구매는 단가 부담은 있지만, 선택 정확도가 높습니다. 그래서 스팀 vs 에픽을 단순히 누가 더 싼지로 비교하면 자꾸 결론이 이상해집니다.

    실전 분석: 제가 실제로 쓴 판단 기준과 계산 방식

    여기부터는 제가 홈랩에서 뭘 재듯이, 게임 라이브러리도 나름 기준을 세워 본 방식입니다. 드라마틱한 데이터 과학은 아니고요. 삽질 좀 했습니다 ㅎㅎ 그래도 이 기준을 만들고 나니까 무료 게임 가치가 꽤 또렷하게 보이더라고요.

    1. 라이브러리를 세 가지로 분류했습니다

    1. 즉시 플레이 후보: 지금 바로 설치할 가능성이 있는 게임
    2. 보관용: 언젠가 할 수도 있지만 당장은 아닌 게임
    3. 사실상 미사용: 받아도 거의 안 할 가능성이 큰 게임

    이렇게 나눠보면, 체감상 가치가 갑자기 줄어드는 분들이 많을 겁니다. 저도 그랬거든요. 무료로 받은 게임이 많아도 실제 가치가 생기는 건 첫 번째 그룹 중심이었습니다.

    2. 시간 비용을 넣었습니다

    무료 배포를 확인하고, 로그인하고, 라이브러리에 추가하고, 나중에 설치 여부를 판단하는 데도 시간이 듭니다. 한 번은 별거 아닌데, 1년 누적하면 생각보다 무시 못 하더라고요. 예를 들어 주 1회, 한 번에 3분씩 체크한다면 연간 약 2.6시간이 들어갑니다. 여기에 설치, 삭제, 라이브러리 정리 시간까지 더하면 꽤 쏠쏠한 관리 비용이 되죠.

  • [Game] 테라리아/ARK 서버 접속 불가? 흔한 포트포워딩 및 방화벽 문제 해결법

    [Game] 테라리아/ARK 서버 접속 불가? 흔한 포트포워딩 및 방화벽 문제 해결법

    [트러블슈팅] 게임 서버 접속 오류, 테라리아/ARK 포트포워딩과 방화벽부터 점검하세요

    집에서 테라리아 서버나 ARK 서버를 열어놨는데, 내 PC에서는 잘 되는데 친구만 못 들어오는 경우가 있죠. 이럴 때 가장 흔한 원인이 바로 포트포워딩(Port Forwarding, 공유기에서 내부 장치로 트래픽을 넘기는 설정)과 방화벽(Firewall, 허용되지 않은 통신을 막는 보안 장치)입니다. 저도 처음엔 게임 설정 문제인 줄 알고 한참 삽질했었는데, 막상 원인은 네트워크 쪽이더라고요. 오늘은 게임 서버 접속 오류가 날 때 어디부터 봐야 하는지, 특히 테라리아와 ARK 기준으로 실전에서 바로 써먹을 수 있는 확인 순서를 정리해보겠습니다.

    중요한 포인트는 단순합니다. 서버 프로세스가 실제로 떠 있는지, 운영체제 방화벽이 포트를 열어줬는지, 공유기가 해당 포트를 내부 서버 PC로 전달하는지, 마지막으로 통신사가 외부 인바운드 연결을 막는 환경은 아닌지를 순서대로 보면 됩니다. 이 순서를 무시하고 여기저기 건드리면 저처럼 시간만 날릴 수 있습니다 ㅎㅎ

    게임 서버 접속 오류 원인을 설명하는 홈 네트워크와 포트포워딩 구조 이미지

    인터넷, 공유기, 서버 PC, 외부 플레이어가 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.

    1. 왜 내 컴퓨터에서는 되고 친구는 안 될까요?

    쉽게 말해, 같은 집 안에서 접속되는 것과 인터넷 밖에서 접속되는 것은 완전히 다른 문제입니다. 내 PC나 같은 LAN(Local Area Network, 내부망)에서는 서버의 사설 IP로 붙을 수 있습니다. 그런데 외부 친구는 공인 IP를 통해 공유기까지 들어온 뒤, 공유기가 정확한 내부 서버 PC로 연결을 넘겨줘야 하거든요.

    여기서 자주 헷갈리는 개념을 표로 정리해보면 이렇습니다.

    항목 의미 자주 생기는 문제
    사설 IP 집 안 장치에 할당되는 내부 주소 서버 PC IP가 바뀌면 포트포워딩 대상이 틀어짐
    공인 IP 인터넷에서 보이는 외부 주소 잘못된 IP를 친구에게 전달함
    포트 서비스별 통신 창구 게임 포트와 포워딩 포트가 다름
    방화벽 들어오고 나가는 통신 제어 프로그램은 실행 중인데 접속은 차단됨
    NAT 공유기가 내부/외부 주소를 변환 NAT 구조를 몰라 외부 접속이 막힘

    혹시 이런 경험 있으신가요? 친구는 접속 실패인데, 나는 localhost나 192.168.x.x 주소로 잘 들어가집니다. 이건 게임이 고장 난 게 아니라, 외부에서 내부 서버까지 들어오는 길이 안 열려 있는 상황인 경우가 많습니다.

    2. 테라리아 서버, ARK 서버에서 먼저 확인할 개념

    테라리아 서버와 ARK 서버는 둘 다 외부 클라이언트가 서버가 열어둔 포트로 들어와야 합니다. 다만 게임마다 쓰는 포트와 프로토콜(TCP/UDP)이 다를 수 있습니다. 여기서 중요한 건 숫자를 무작정 외우는 게 아니라, 내가 실제로 실행한 서버 설정 파일이나 실행 옵션에서 어떤 포트를 쓰는지 확인하는 습관입니다.

    그래도 많이 쓰는 예시는 알고 있으면 편합니다.

    • Terraria: 기본 예시로 7777 포트를 많이 사용합니다.
    • ARK: 환경에 따라 다르지만 게임 포트와 쿼리 포트(query port)를 함께 여는 경우가 많습니다.
    • 프로토콜: 게임마다 TCP, UDP 중 하나 또는 둘 다 필요할 수 있습니다. 서버 문서나 실행 로그를 반드시 같이 보셔야 합니다.

    제가 직접 해보니 여기서 많이 틀립니다. 공유기에는 7777만 열었는데, 실제 서버는 다른 포트로 떠 있거나, ARK 쪽은 쿼리 포트를 안 열어서 서버 목록에 안 보이는 식이더라고요. 게임 서버 접속 오류가 났다면, 제일 먼저 “서버가 실제로 어느 포트에서 리슨(listen, 연결 대기) 중인가?”를 확인해보세요.

    3. 실전 점검 1단계: 서버 프로세스와 리슨 포트 확인

    가장 먼저 할 일은 게임 서버 프로그램이 정상 실행 중인지 보는 겁니다. 실행 창이 떠 있다고 끝이 아니고, 운영체제에서 실제로 포트를 열고 대기 중이어야 합니다.

    Linux에서 확인하는 방법

    ss -tulpen | grep -E '7777|27015'
    

    또는 구형 환경이면 아래처럼 볼 수 있습니다.

    netstat -tulpen | grep -E '7777|27015'
    

    출력에서 LISTEN 또는 UDP 소켓이 보이면 일단 서버가 포트를 잡고 있는 겁니다.

    Windows에서 확인하는 방법

    netstat -ano | findstr :7777
    netstat -ano | findstr :27015
    

    PID가 보이면 작업 관리자(Task Manager)나 아래 명령으로 어떤 프로세스인지 연결해볼 수 있습니다.

    tasklist /FI "PID eq 1234"
    

    여기서 아무것도 안 나온다면, 포트포워딩 이전에 서버 자체가 제대로 안 떠 있는 겁니다. 설정 파일 경로가 틀렸거나, 저장 경로 권한 문제거나, 이미 다른 프로그램이 같은 포트를 쓰고 있을 수 있습니다.

    테라리아 서버와 ARK 서버 포트 리슨 상태를 확인하는 터미널 점검 이미지

    실제 점검 과정에서 가장 먼저 보는 화면입니다. 포트가 열려 있는지부터 확인해야 다음 단계가 의미가 있습니다.

    4. 실전 점검 2단계: 운영체제 방화벽 열기

    서버가 떠 있어도 방화벽 설정이 막고 있으면 외부 접속은 안 됩니다. 저도 예전에 공유기 설정만 한참 만지다가, 결국 Windows Defender Firewall에서 차단 중인 걸 보고 허탈했던 적이 있습니다.

    Windows Defender Firewall 예시

    관리자 권한 PowerShell 또는 명령 프롬프트에서 아래처럼 인바운드 규칙을 추가할 수 있습니다.

    netsh advfirewall firewall add rule name="Terraria TCP 7777" dir=in action=allow protocol=TCP localport=7777
    netsh advfirewall firewall add rule name="Terraria UDP 7777" dir=in action=allow protocol=UDP localport=7777
    netsh advfirewall firewall add rule name="ARK UDP 7777" dir=in action=allow protocol=UDP localport=7777
    netsh advfirewall firewall add rule name="ARK UDP 27015" dir=in action=allow protocol=UDP localport=27015
    

    실제 포트는 여러분 서버 설정에 맞게 바꾸셔야 합니다.

    Ubuntu의 UFW(Uncomplicated Firewall) 예시

    sudo ufw allow 7777/tcp
    sudo ufw allow 7777/udp
    sudo ufw allow 27015/udp
    sudo ufw status verbose
    

    firewalld 예시

    sudo firewall-cmd --permanent --add-port=7777/tcp
    sudo firewall-cmd --permanent --add-port=7777/udp
    sudo firewall-cmd --permanent --add-port=27015/udp
    sudo firewall-cmd --reload
    sudo firewall-cmd --list-ports
    

    여기서 중요한 포인트! 서버 프로그램을 예외 처리할지, 포트 자체를 열지 방식이 갈릴 수 있는데, 홈랩에서는 포트 기준으로 명확하게 여는 방식이 나중에 추적하기 편했습니다. 어떤 포트를 왜 열었는지 기록도 남기 좋거든요.

    5. 실전 점검 3단계: 공유기 포트포워딩 설정

    이제 포트포워딩을 봅니다. 쉽게 말해 외부에서 들어온 7777번 요청을, 내부의 192.168.0.10 같은 서버 PC IP로 넘겨주는 규칙입니다. 공유기 제조사마다 메뉴 이름은 조금씩 다르지만 보통 Port Forwarding, Virtual Server, NAT, Applications 같은 이름으로 들어가면 나옵니다.

    1. 서버 PC의 현재 내부 IP를 확인합니다.
    2. 가능하면 DHCP Reservation(고정 할당)으로 서버 IP가 바뀌지 않게 묶습니다.
    3. 외부 포트와 내부 포트를 게임 서버 포트에 맞춰 입력합니다.
    4. 프로토콜을 TCP, UDP 또는 둘 다로 정확히 지정합니다.
    5. 대상 IP를 서버 PC 내부 IP로 설정합니다.
    6. 저장 후 공유기 재적용 또는 재부팅을 합니다.

    예를 들어 이런 식입니다.

    서비스명 외부 포트 내부 IP 내부 포트 프로토콜
    Terraria 7777 192.168.0.10 7777 TCP 또는 설정값 기준
    ARK Game 7777 192.168.0.10 7777 UDP 예시
    ARK Query 27015 192.168.0.10 27015 UDP 예시

    공유기 웹 UI에서 메뉴를 찾기 어렵다면, 핵심은 하나입니다. 외부에서 들어온 특정 포트를 내부 서버 장치로 전달하는 기능을 찾으면 됩니다. 메뉴 이름이 달라도 원리는 같습니다.

    포트포워딩 설정으로 게임 서버 접속 오류를 해결하는 공유기 설정 이미지

    실제 공유기 화면은 제조사마다 다르지만, 외부 포트를 내부 서버 IP로 연결하는 구조는 거의 비슷합니다.

    6. ⚠️ 많이 막히는 지점: 이중 공유기, CGNAT, 잘못된 테스트 방식

    여기가 진짜 핵심입니다. 게임 서버 접속 오류를 잡을 때 포트포워딩과 방화벽을 다 맞췄는데도 안 되는 경우가 있거든요. 저도 처음엔 이게 뭔가 싶었는데, 알고 보니 네트워크 구조 자체가 문제였습니다.

    1) 이중 공유기(Double NAT, NAT 두 번)

    통신사 장비 뒤에 개인 공유기를 또 물려 쓴다면, 포트포워딩을 두 군데 다 해야 할 수 있습니다. 예를 들어 통신사 장비가 192.168.0.x 대역이고, 내 공유기가 192.168.1.x 대역이면 이미 NAT가 한 번 더 있는 구조일 가능성이 큽니다.

    • 증상: 설정은 다 맞는 것 같은데 외부 접속만 안 됨
    • 확인: 내 공유기의 WAN IP가 사설 IP인지 확인
    • 해결: 브리지 모드(Bridge Mode)나 DMZ, 또는 상위 장비에도 포워딩 설정

    2) CGNAT(Carrier-Grade NAT, 통신사 공유 공인망)

    일부 인터넷 환경에서는 아예 집에 직접 공인 IP가 안 들어오는 경우가 있습니다. 이 경우 일반적인 포트포워딩만으로는 외부에서 직접 접속이 안 됩니다.

    • 증상: 공유기 WAN 주소가 공인 IP처럼 안 보임
    • 해결: 통신사에 공인 IP 제공 여부 문의, 또는 VPN/WireGuard/Tailscale 같은 우회 구조 검토

    3) 내부에서 공인 IP로 테스트

    이것도 자주 틀립니다. 같은 집 안에서 내 공인 IP로 접속 테스트했는데 실패했다고 해서, 외부 접속이 반드시 안 되는 건 아닙니다. 공유기마다 NAT loopback(내부에서 외부 주소로 다시 들어오는 동작) 지원 여부가 다르거든요. 그래서 모바일 데이터나 외부 네트워크에서 테스트해야 정확합니다.

    4) 서버 IP가 바뀜

    DHCP로 서버 PC IP가 바뀌면, 공유기 포워딩이 옛날 IP를 보고 있어서 갑자기 접속이 끊깁니다. 어제까지 되다가 오늘 안 되면 이 경우가 꽤 많습니다.

    제가 실제로 써보니까, 홈랩에서는 서버 장비만큼은 고정 IP 또는 DHCP Reservation을 꼭 걸어두는 게 마음 편하더라고요.

    7. 검증 방법: 어디까지 열렸는지 단계별로 보기

    설정을 끝냈다면 이제 감으로 보지 말고 검증해야 합니다. 아래 순서대로 보면 문제 구간이 꽤 빨리 좁혀집니다.

    1. 로컬 테스트: 서버 PC에서 localhost 또는 내부 IP로 접속
    2. 같은 집 내부 테스트: 다른 PC/기기에서 사설 IP로 접속
    3. 외부 테스트: 모바일 데이터 또는 다른 장소 네트워크에서 공인 IP로 접속
    4. 포트 개방 점검: 외부 포트 체크 도구 또는 실제 클라이언트 접속 시도
    5. 로그 확인: 서버 콘솔에 접속 시도 흔적이 남는지 보기

    로그에 접속 흔적조차 없으면, 대부분 서버 앞단인 방화벽 설정 또는 포트포워딩 문제입니다. 반대로 로그는 찍히는데 게임에서 튕긴다면, 버전 불일치나 모드 충돌, 세이브 파일 문제 같은 애플리케이션 레벨을 봐야 합니다.

    ipconfig
    ip addr
    ss -tulpen | grep 7777
    sudo ufw status verbose
    

    Windows 환경이라면 아래도 같이 보세요.

    ipconfig
    netstat -ano | findstr :7777
    netsh advfirewall firewall show rule name=all | findstr 7777
    
    외부 네트워크에서 테라리아 서버와 ARK 서버 접속을 검증하는 결과 이미지

    외부 환경에서 실제 접속이 되는지 확인하는 장면입니다. 내부 테스트만으로는 놓치는 문제가 꽤 많습니다.

    8. 정리와 FAQ: 테라리아 서버, ARK 서버 접속 안 될 때 체크리스트

    마지막으로 빠르게 훑을 수 있게 체크리스트 형태로 정리해보겠습니다. 저는 이런 식으로 하나씩 지우면서 봅니다. 의외로 가장 단순한 항목에서 끝나는 경우가 많더라고요.

    • 서버 프로세스가 실제로 실행 중인가?
    • 서버가 원하는 포트에서 리슨 중인가?
    • 운영체제 방화벽에서 해당 포트를 허용했는가?
    • 공유기 포트포워딩 대상 IP가 현재 서버 IP와 같은가?
    • 프로토콜 TCP/UDP를 맞게 설정했는가?
    • 이중 공유기 또는 CGNAT 환경은 아닌가?
    • 외부 네트워크에서 테스트했는가?
    • 서버 로그에 접속 시도 흔적이 남는가?

    자주 묻는 질문

    Q. 테라리아 서버는 켜져 있는데 친구가 못 들어옵니다.
    A. 서버가 7777 같은 예상 포트가 아니라 다른 포트로 떠 있을 수 있습니다. 먼저 리슨 포트를 확인하고, 그 포트 기준으로 방화벽과 포트포워딩을 다시 맞춰보세요.

    Q. ARK 서버가 목록에 안 보입니다.
    A. 게임 포트만 열고 쿼리 포트를 빼먹는 경우가 있습니다. 서버 실행 옵션과 문서를 같이 보고 필요한 포트를 모두 열었는지 확인해보세요.

    Q. 포트 개방 사이트에서는 닫힘인데, 뭘 봐야 하나요?
    A. 서버 프로세스가 해당 포트에서 대기 중인지, 방화벽이 막고 있지 않은지, 그리고 외부 테스트가 정확한 네트워크에서 이루어졌는지 순서대로 보셔야 합니다.

    결국 게임 서버 접속 오류는 복잡해 보여도 흐름은 같습니다. 서버 실행 → OS 방화벽 → 공유기 포트포워딩 → 외부 테스트. 이 순서만 지켜도 원인을 훨씬 빨리 찾습니다. 다음 글에서는 홈랩 기준으로 WireGuard VPN이나 리버스 프록시(reverse proxy, 요청을 대신 받아 내부 서비스로 넘기는 구성) 같은 대안 접근도 다뤄볼 예정입니다. 이전 글에서 다룬 홈서버 네트워크 기본편과 함께 보시면 이해가 더 빨라집니다.

    포트포워딩과 방화벽 설정 체크리스트로 게임 서버 접속 오류를 정리한 인포그래픽

    마지막 점검용 요약 이미지입니다. 실제 장애 대응 때는 이런 체크리스트 한 장이 제일 도움이 됩니다.

  • [Game] RPCS3 vs RetroArch: PS3 에뮬레이션, 어떤 선택이 최적일까?

    [Game] RPCS3 vs RetroArch: PS3 에뮬레이션, 어떤 선택이 최적일까?

    [에뮬레이터] PS3 에뮬레이터 비교, RPCS3 vs RetroArch

    PS3 에뮬레이터를 찾다 보면 꼭 한 번은 부딪히는 질문이 있습니다. "RPCS3로 가야 하나, RetroArch로 한 번에 묶어야 하나?" 저도 처음엔 이게 뭔가 싶었거든요. 레트로 게임은 RetroArch 하나로 정리해두고 싶고, PS3도 거기서 같이 돌리면 깔끔할 것 같았는데, 실제로 써보니까 결론은 꽤 명확하더라고요. PS3 에뮬레이션 자체가 목적이면 RPCS3가 중심이고, RetroArch는 역할이 조금 다릅니다.

    특히 검색하다 보면 RetroArch PS3라는 표현 때문에 헷갈리기 쉽습니다. 이 말이 "PC에서 PS3 게임을 RetroArch로 돌린다"는 뜻처럼 보이는데, 공식 문서를 보면 RetroArch는 기본적으로 frontend(프런트엔드, 여러 에뮬레이터 코어를 묶는 실행 환경)이고, 별도 PS3 코어가 확인되는 구조는 아닙니다. 반대로 RPCS3는 아예 PlayStation 3 emulator(플레이스테이션 3 에뮬레이터)로 설계된 프로젝트예요. 여기서 선택이 갈라지는 거죠.

    PS3 에뮬레이터 비교 개요 이미지, RPCS3와 RetroArch의 역할 차이

    RPCS3는 PS3 게임 에뮬레이션, RetroArch는 멀티 시스템 프런트엔드라는 역할 차이를 한눈에 보여주는 이미지입니다.

    1. 먼저 결론부터: PS3 에뮬레이션의 핵심은 "누가 실제로 PS3를 흉내 내느냐"입니다

    쉽게 말해 에뮬레이터는 원본 하드웨어 동작을 소프트웨어로 재현하는 도구입니다. PS3는 Cell Broadband Engine 기반 구조 때문에 다른 고전 콘솔보다 난도가 높은 편으로 알려져 있죠. 그래서 에뮬레이터 성능과 호환성, 설정 안정성이 정말 중요합니다.

    여기서 중요한 포인트가 하나 있습니다.

    • RPCS3: PS3 전용 에뮬레이터입니다.
    • RetroArch: 여러 에뮬레이터 코어를 묶어주는 프런트엔드입니다.
    • RetroArch의 PS3 지원: 공식 문서에서 확인되는 내용은 "PS3 본체에 RetroArch를 설치하는 가이드" 쪽에 가깝습니다.

    즉, "PS3 게임을 PC에서 가장 제대로 돌리고 싶다"는 질문에는 사실상 RPCS3가 답입니다. 반대로 "PS1, PSP, SNES, 메가드라이브 같은 레트로 게임까지 한 인터페이스에서 관리하고 싶다"면 RetroArch가 빛을 봅니다.

    2. RPCS3 vs RetroArch 비교표: 어떤 선택이 최적일까?

    항목 RPCS3 RetroArch
    주된 목적 PS3 전용 에뮬레이션 멀티 시스템 프런트엔드
    PS3 게임 실행 관점 핵심 선택지 직접 대체재로 보긴 어렵습니다
    초기 설정 펌웨어 설치와 게임별 점검 필요 코어 중심 구조라 익숙해지면 편함
    게임 호환성 확인 공식 Compatibility List 제공 코어별 편차가 큼
    레트로 게임 통합 관리 약한 편 강점
    추천 사용자 PS3 게임이 목표인 분 여러 세대를 한 UI로 관리할 분

    제가 직접 해보니 이 표 하나로 정리가 되더라고요. PS3 에뮬레이터를 묻는 순간 이미 답은 반쯤 정해져 있습니다. 문제는 "PS3만 볼 거냐", 아니면 "전체 레트로 게임 환경을 설계할 거냐"입니다.

    3. RPCS3 설정: 가장 현실적인 시작 방법

    RPCS3 쪽은 접근법이 단순합니다. 괜히 초반부터 옵션을 다 건드리지 마시고, 기본값으로 시작한 뒤 게임별로 조정하는 게 맞습니다. 저도 처음엔 인터넷에서 본 설정을 이것저것 따라 했다가 오히려 더 꼬였었습니다. 정말 삽질했어요 ㅎㅎ

    1. Sony 공식 펌웨어를 준비합니다.
    2. RPCS3에서 펌웨어를 설치합니다.
    3. 보유한 정식 게임 백업을 추가합니다.
    4. 실행 전 Compatibility List(호환성 목록)에서 상태를 확인합니다.
    5. 문제가 없으면 기본 설정으로 먼저 부팅합니다.
    6. 필요할 때만 게임별 설정을 분리합니다.

    왜 기본값이 중요하냐? RPCS3는 게임마다 병목 지점이 다릅니다. 어떤 게임은 GPU 쪽이 민감하고, 어떤 게임은 CPU 스케줄링이나 셰이더 컴파일 구간에서 체감이 생기는 거죠. 그래서 무조건 유명한 설정 프리셋을 복붕하는 방식이 생각보다 잘 안 맞습니다.

    # 예시: 게임 보관 폴더를 먼저 분리해두면 관리가 편합니다
    mkdir -p ~/Games/PS3
    mkdir -p ~/Firmware/PS3
    

    이건 거창한 명령은 아니지만, 나중에 게임 추가하고 로그 확인할 때 정말 편합니다. 홈랩 운영하면서 느낀 건데요, 폴더 구조를 먼저 정리한 사람이 결국 덜 고생합니다.

    RPCS3에서 체크할 포인트

    • Compatibility List(호환성 목록)를 먼저 봅니다.
    • 펌웨어 설치 후 바로 게임을 넣고, 첫 부팅은 기본 설정으로 봅니다.
    • 문제가 생기면 전역 설정이 아니라 게임별 설정으로 좁혀서 수정합니다.
    • 불필요한 해상도 욕심은 초반에 버리는 게 좋습니다.
    RPCS3 설정 흐름과 호환성 확인을 보여주는 PS3 에뮬레이터 이미지

    펌웨어 설치, 게임 추가, 호환성 체크, 기본 실행 순서가 보이도록 구성한 설정 흐름 이미지입니다.

    4. RetroArch PS3, 정확히 어디까지 기대해야 할까?

    여기서 가장 많이 헷갈립니다. RetroArch PS3라는 표현은 보통 두 가지로 섞여 쓰이거든요.

    • PS3 본체에 RetroArch를 설치해 여러 레트로 게임 코어를 돌리는 경우
    • PC에서 RetroArch로 PS3 게임까지 처리하려는 기대

    공식 문서 기준으로 확인되는 건 전자에 가깝습니다. Libretro 문서에는 PlayStation 3에 RetroArch를 설치하는 가이드가 있고, 커스텀 펌웨어가 필요하다는 주의도 분명히 나옵니다. 반면 코어 목록을 보면 RetroArch는 시스템별 코어를 불러오는 구조인데, PS3 에뮬레이션을 RPCS3 대체재처럼 바로 놓고 볼 만한 공식 코어 흐름은 확인하기 어렵습니다.

    그래서 현실적으로는 이렇게 보시면 됩니다.

    • RetroArch는 레트로 게임 환경 통합에 강합니다.
    • RPCS3는 PS3 게임 에뮬레이션에 집중합니다.
    • 둘은 경쟁 관계라기보다, 역할이 겹치는 듯 보이지만 실제론 분업 관계에 가깝습니다.
    # RetroArch 공식 문서에 있는 기본적인 CLI 예시
    retroarch --menu
    retroarch --features
    retroarch -L /path/to/libretro/core.so /path/to/game.rom
    

    이 예시는 RetroArch가 코어 기반 실행 환경이라는 점을 잘 보여줍니다. 즉, 핵심은 "어떤 코어를 불러오느냐"입니다. PS1, PSP, 아케이드, SNES 같은 흐름에서는 정말 편하더라고요. 근데 PS3를 같은 감각으로 기대하면 방향이 조금 어긋납니다.

    5. 실전 선택 가이드: 이런 경우엔 RPCS3, 이런 경우엔 RetroArch

    혹시 이런 경험 있으신가요? 게임은 하고 싶은데 환경 구축이 일이 되어버리는 순간이요. 이럴 때는 목적을 먼저 고정해야 합니다.

    RPCS3가 맞는 경우

    1. 목표가 분명히 PS3 에뮬레이터인 경우
    2. 특정 PS3 독점작이나 세대 특유의 게임을 우선 플레이하려는 경우
    3. RPCS3 설정과 호환성 점검을 감수할 수 있는 경우
    4. 게임별 차이를 받아들이고 튜닝할 생각이 있는 경우

    RetroArch가 맞는 경우

    1. PS3보다 전체 레트로 게임 환경 구축이 더 중요한 경우
    2. 여러 세대 콘솔을 한 UI와 공통 입력 설정으로 관리하고 싶은 경우
    3. 셰이더, 세이브 상태, 플레이리스트 같은 프런트엔드 편의성이 필요한 경우
    4. PS3 본체에서 홈브루 성격으로 레트로 환경을 꾸미려는 경우

    한 줄 결론: PS3 게임이 메인이면 RPCS3, 전체 게임 박물관을 만들고 싶으면 RetroArch입니다.

    6. ⚠️ 실제로 많이 막히는 문제와 해결 포인트

    이 섹션은 경험상 정말 중요합니다. 검색 결과만 따라가면 잘 안 보이는 부분이거든요.

    • ⚠️ 게임이 안 뜬다고 바로 설정부터 건드리지 마세요. 먼저 호환성 목록과 게임 상태를 확인하는 게 우선입니다.
    • ⚠️ 불법 다운로드 이미지는 제외해야 합니다. 정식 펌웨어와 합법적으로 보유한 게임 기준으로 가는 게 안정성도 낫습니다.
    • ⚠️ RetroArch에 PS3를 억지로 기대하면 시간만 씁니다. 역할 구분을 먼저 해야 합니다.
    • ⚠️ 설정 백업을 해두세요. 한 번 꼬인 구성은 기억보다 파일이 더 정확합니다.

    제가 처음에 했던 실수도 이거였습니다. RPCS3에서 프레임이 흔들리니까 렌더러, 해상도, 패치, 오디오 옵션을 한 번에 건드렸거든요. 결과는 더 안 좋아졌어요. 결국 하나씩 되돌리면서 원인을 찾았네요. 변수는 한 번에 하나만, 이거 서버 트러블슈팅이랑 완전히 똑같습니다.

    PS3 에뮬레이터 트러블슈팅과 로그 확인 흐름 이미지

    호환성 확인, 기본값 테스트, 게임별 설정 분리, 로그 확인 순서의 트러블슈팅 흐름을 설명하는 이미지입니다.

    7. 검증과 결과: 체감상 무엇이 달랐나?

    실제로 써보니까 차이는 꽤 선명했습니다.

    • RPCS3는 "한 기종을 깊게 파는 도구"라는 느낌입니다.
    • RetroArch는 "여러 기종을 넓게 운영하는 플랫폼"이라는 느낌이 강합니다.

    특히 에뮬레이터 성능을 이야기할 때 단순히 빠르냐 느리냐만 보면 안 됩니다. UI 편의성, 셰이더, 패드 공통 설정은 RetroArch 쪽 만족도가 높고, PS3 게임 자체의 실행 가능성과 호환성 추적은 RPCS3 쪽이 훨씬 직접적입니다.

    그래서 제 기준 검증 결과는 이렇습니다.

    질문 권장 선택
    PS3 게임을 중심으로 안정적으로 즐기고 싶은가? RPCS3
    PS3 포함 여러 세대를 한 화면에서 정리하고 싶은가? RetroArch + 별도 전문 에뮬레이터 조합
    설정 난이도를 줄이고 싶은가? PS3만 보면 RPCS3가 오히려 덜 헷갈릴 수 있습니다
    한 번 구축한 뒤 레트로 라이브러리를 쭉 관리하고 싶은가? RetroArch가 강합니다
    RPCS3와 RetroArch 선택 결과를 요약한 PS3 에뮬레이터 비교 이미지

    PS3 집중형과 멀티 시스템 통합형이라는 두 선택지를 결과 중심으로 비교한 요약 이미지입니다.

    8. 정리 + 자주 묻는 질문

    정리하자면, 이번 비교에서 핵심은 성능 수치 경쟁이 아니었습니다. PS3 에뮬레이터로서 무엇이 본업이냐를 구분하는 게 먼저였죠. 그 기준으로 보면 RPCS3는 PS3 전용 실전 도구이고, RetroArch는 훌륭한 프런트엔드입니다. 둘 중 하나가 무조건 상위호환이라기보다, 애초에 잘하는 일이 다릅니다.

    저라면 이렇게 추천합니다. PS3 게임이 목표면 RPCS3부터 구축하시고, 이후에 PS1, PSP, 아케이드, 16비트 콘솔까지 레트로 게임 환경을 넓히고 싶을 때 RetroArch를 붙이세요. 이 순서가 덜 꼬입니다. 다음 글에서는 RPCS3 설정에서 게임별로 어떤 식으로 접근해야 덜 삽질하는지 더 정리해보겠습니다. 이전 글에서 다뤘던 홈랩 백업 습관처럼, 에뮬레이터도 결국 구조화가 중요하거든요.

    FAQ

    • Q. RetroArch로 PS3 게임을 바로 돌리는 게 가능한가요?
      A. 공식 문서 흐름상 RetroArch는 코어를 불러오는 프런트엔드로 이해하는 게 맞고, PS3 에뮬레이션 대체재로 RPCS3와 같은 위치에 놓기는 어렵습니다.
    • Q. 처음 시작하는데 뭐부터 설치하는 게 좋나요?
      A. PS3가 목표면 RPCS3부터 시작하세요. 목적이 분명하면 설정도 덜 흔들립니다.
    • Q. RetroArch는 쓸모가 없다는 뜻인가요?
      A. 전혀 아닙니다. 오히려 여러 기종을 한 인터페이스에서 관리할 때는 정말 강력합니다.
    초보자를 위한 PS3 에뮬레이터 선택 가이드 요약 이미지

    PS3 전용, 멀티 레트로, 홈브루 활용 등 시나리오별 추천 선택을 정리한 마무리 이미지입니다.

  • [Linux] Linux 6.9 LUKS suspend 보안 이슈: 디스크 암호화 키 노출과 대응 전략

    [Linux] Linux 6.9 LUKS suspend 보안 이슈: 디스크 암호화 키 노출과 대응 전략

    [보안] Linux LUKS suspend 보안 이슈와 대응 전략

    최근 Linux LUKS suspend 보안 이슈가 다시 크게 회자되는 이유가 있습니다. 평소엔 노트북 뚜껑만 닫고 다니는 분들이 많잖아요. 저도 홈랩하고 실사용 장비를 굴리다 보면 suspend(서스펜드, 절전) 의존도가 꽤 높거든요. 그런데 2026년 7월 기준 공개된 정보로 보면, Linux 6.9 이후 특정 조건에서 LUKS의 키 제거 기대가 깨질 수 있는 회귀(regression, 기능 후퇴)가 확인됐습니다. 제목만 보면 바로 대형 재난처럼 느껴질 수 있는데, 실제 영향 범위는 조금 더 정확하게 봐야 합니다. 이번 글에서는 Linux LUKS suspend 보안 관점에서 무엇이 문제인지, 어떤 사용자가 진짜 영향권인지, 그리고 지금 당장 운영에서 어떻게 대응해야 하는지 차근차근 정리해보겠습니다.

    특히 보조 키워드로 많이 붙는 커널 6.9 취약점, 디스크 암호화 문제, 콜드 부트 공격도 함께 연결해서 보셔야 맥락이 잡힙니다. 저도 처음엔 “잠깐, resume 때 비밀번호 다시 받으면 안전한 거 아니었나?” 싶었는데요. 파고들어 보니 그게 함정이더라고요.

    Linux LUKS suspend 보안 이슈의 키 메모리 흐름 개요 이미지

    LUKS 장치, 커널 키링, suspend/resume 흐름, 공격 표면을 한눈에 보여주는 개요 이미지입니다.

    1. 왜 이 이슈가 중요한가: 잠자기와 보안은 같은 얘기가 아닙니다

    쉽게 말해, 풀디스크 암호화(Full Disk Encryption, 전체 디스크 암호화)를 쓰더라도 부팅 후 이미 복호화된 키가 RAM(메모리)에 남아 있으면 물리 접근 공격의 표적이 될 수 있습니다. 여기서 자주 언급되는 게 cold boot attack(콜드 부트 공격, 전원 차단 직후 남아 있는 메모리 데이터를 노리는 공격)이에요. 오래된 개념처럼 보이지만, 물리 접근 위협 모델에서는 아직도 무시하면 안 됩니다.

    WithSecure가 2018년에 다시 크게 환기한 내용도 비슷합니다. 절전 상태의 장비는 생각보다 안전하지 않을 수 있다는 점이죠. 그리고 Linux 쪽에서는 오래전부터 cryptsetup luksSuspend를 이용해 서스펜드 직전 키를 커널 메모리에서 지우고, 복귀 시 다시 인증받는 흐름을 활용해 왔습니다. 문제는 이 기대가 Linux 6.9 이후 일부 흐름에서 더 이상 그대로 성립하지 않는다는 점입니다.

    2. 개념 먼저 잡고 가죠: LUKS suspend가 원래 하려던 일

    여기서 중요한 포인트가 있습니다. 일반적인 suspend-to-RAM(메모리에 유지하는 절전)은 원래 RAM 전원이 살아 있습니다. 그래서 그냥 뚜껑 닫는다고 암호화 키가 저절로 사라지지 않거든요. 이걸 보완하려고 luksSuspend가 있는 겁니다.

    원래 기대 동작은 이렇습니다.

    1. LUKS 매핑 장치를 suspend 합니다.
    2. 디스크 I/O를 멈춥니다.
    3. 볼륨 키(volume key, 실제 데이터 복호화에 쓰는 키)를 커널 메모리에서 제거합니다.
    4. resume 시 다시 패스프레이즈나 토큰으로 키를 넣습니다.

    man page에도 luksSuspend는 활성 장치를 중단하고 커널 메모리에서 암호화 키를 지운다고 설명돼 있습니다. 저도 예전엔 이 문장만 보고 꽤 든든하게 느꼈었는데, 실제 구현은 keyring(키링, 커널 내부 키 저장 메커니즘) 동작에 의존하는 부분이 있더라고요.

    3. Linux 6.9 이후 무엇이 달라졌나: 진짜 쟁점은 키링 수명입니다

    이번 이슈의 핵심은 LUKS 자체 포맷이 깨졌다가 아닙니다. 키를 커널 쪽으로 넘기는 과정에서 쓰는 thread keyring(스레드 키링)의 수명 관리 가정이 깨진 것에 가깝습니다. cryptsetup 2.8.7 release notes에 따르면, 이전 버전은 볼륨 키를 thread keyring에 둘 수 있었고, 원래는 프로세스 종료 시 사라질 것으로 기대했거든요. 그런데 일부 상황, 예를 들어 loop device(루프 디바이스) 할당 같은 경우에는 thread keyring이 남아 있을 수 있다고 명시했습니다.

    이 문장을 보고 저도 “아, 이건 생각보다 문제의 결이 명확하네” 싶었습니다. 즉, Linux 6.9 이후 회귀로 인해 luksSuspend를 호출해도 사용자가 기대한 시점에 키가 완전히 사라지지 않을 수 있다는 얘기입니다. resume 때 비밀번호를 다시 묻는 화면이 떠도, 그 사실만으로 키가 제대로 지워졌다는 증거는 아닙니다.

    정리하면 이렇습니다.

    항목 정상 기대 문제 상황
    LUKS 일반 사용 부팅 후 키가 메모리에 존재 가능 원래도 suspend 중 메모리 노출 위험 존재
    luksSuspend 사용 서스펜드 직전 키 제거 기대 Linux 6.9 이후 특정 흐름에서 제거 보장이 흔들림
    resume 인증 프롬프트 추가 보안 절차처럼 보임 키 제거 성공 여부를 단독으로 증명하진 못함

    4. 누가 실제로 영향받나: 모든 리눅스 노트북 사용자는 아닙니다

    이 부분은 꼭 선을 그어야 합니다. 영향 대상은 주로 cryptsetup-suspend 패키지나 직접 만든 suspend hook으로 luksSuspend를 써 온 사용자입니다. Debian 계열에서 관련 패키지를 쓰거나, Arch/openSUSE/NixOS처럼 직접 훅을 구성한 분들이 대표적이죠.

    반대로 그냥 “LUKS로 루트 디스크 암호화는 했고, 평소에는 일반 suspend만 쓴다” 수준이면, 엄밀히 말해 이번 회귀 이전에도 콜드 부트 공격 관점의 메모리 잔존 위험은 남아 있었습니다. 그래서 이번 이슈를 볼 때는 보안 기능이 있었다가 기대대로 동작하지 않게 된 회귀로 이해하는 게 맞습니다.

    Linux LUKS suspend 보안 영향 범위와 위협 모델 비교 이미지

    일반 LUKS 사용자와 luksSuspend 사용자, suspend-to-RAM과 hibernation의 차이를 비교하는 이미지입니다.

    5. 실전 점검: 내 시스템이 위험 구간인지 확인하는 방법

    실제로 써보니까 제일 먼저 해야 할 건 감으로 판단하지 않는 겁니다. 아래 순서대로 확인해 보세요.

    5-1. 커널과 cryptsetup 버전 확인

    uname -r
    cryptsetup --version

    여기서 커널이 6.9 계열 이상인지, 그리고 cryptsetup이 어떤 버전인지 먼저 봅니다. 2026년 7월 기준으로 공개된 cryptsetup 2.8.7 release notes에는 이 keyring handling changes가 명시돼 있거든요.

    5-2. luksSuspend 사용 여부 확인

    grep -R "luksSuspend\|cryptsetup-suspend" /etc/systemd /etc/pm /usr/lib/systemd 2>/dev/null
    systemctl list-unit-files | grep -i cryptsetup
    dpkg -l 2>/dev/null | grep cryptsetup-suspend || true
    rpm -qa 2>/dev/null | grep cryptsetup || true

    배포판마다 다르니 한 가지 명령만 믿으면 안 됩니다. 저도 예전에 systemd sleep hook 한 군데만 보고 안심했다가 다른 경로에서 동작하는 유닛을 놓친 적이 있었거든요. 삽질 좀 했습니다 ㅎㅎ

    5-3. 운영 정책 확인

    loginctl show-session $(loginctl | awk '/tty|seat|pts/ {print $1; exit}') -p IdleHint
    systemctl status sleep.target suspend.target hibernate.target

    장비가 실제로 suspend-to-RAM 위주인지, hibernation(하이버네이션, 디스크로 메모리 상태 저장 후 전원 차단)도 쓰는지 확인해 두세요. 여기서 대응 전략이 갈립니다.

    6. 대응 전략: 지금 당장 운영에서 추천하는 순서

    제가 직접 운영 기준으로 정리하면 우선순위는 이렇습니다.

    1. 위협 모델이 강하면 suspend-to-RAM을 끄고 hibernation 또는 shutdown으로 전환
    2. cryptsetup 2.8.7 이상 제공 여부를 배포판에서 확인
    3. resume 프롬프트만 보고 안전하다고 판단하지 않기
    4. 민감 장비는 pre-boot authentication(부팅 전 인증)과 물리 보안 정책을 같이 적용

    커널 문서에서도 hibernation 쪽은 RAM 전원이 계속 유지되는 suspend와 보안 성격이 다릅니다. 결국 메모리에 키가 안 남는 상태를 만들고 싶다면 RAM 전원을 살려두는 절전보다 하이버네이션이 훨씬 낫다는 얘기죠.

    제가 실무에서라면 이렇게 가겠습니다.

    시나리오 권장 대응 이유
    출장용 노트북 Hibernate 우선 물리 탈취와 콜드 부트 공격 위험 완화
    사내 데스크톱 업데이트 후 정책 재검토 물리 접근 통제가 상대적으로 쉬움
    홈랩 테스트 머신 재현 후 버전 비교 영향 범위 검증과 자동화 테스트에 적합
    고민감 데이터 장비 Suspend 금지에 가깝게 운영 편의성보다 보안 우선

    7. ⚠️ 주의사항과 트러블슈팅: 여기서 많이 헷갈립니다

    첫째, resume 때 암호를 다시 묻는다고 끝이 아닙니다. 이게 제일 헷갈립니다. 사용자 입장에서는 “복귀 시 비밀번호 입력창 떴네, 그럼 잘 잠겼겠지”라고 생각하기 쉬운데요. 이번 Linux LUKS suspend 보안 이슈는 바로 그 안심 포인트를 찌릅니다.

    둘째, page cache(페이지 캐시) 문제와 이번 keyring 문제를 섞어 보면 안 됩니다. cryptsetup 이슈 트래커에는 2023년 말부터 luksSuspend 후에도 최근 읽은 데이터가 페이지 캐시에 남아 접근 가능하다는 별도 논의가 있었습니다. 이것도 디스크 암호화 문제로 꽤 중요하지만, 이번 글의 핵심인 Linux 6.9 이후 키링 기반 키 제거 회귀와는 결이 다릅니다. 둘 다 “잠자기 전 잠금” 기대를 흔든다는 공통점은 있지만 원인은 다르더라고요.

    셋째, loop device를 쓰는 테스트는 오히려 문제를 드러내기 좋습니다. release notes에서 loop device 상황을 직접 언급하거든요. 홈랩에서 재현 실험할 때는 이 흐름을 일부러 써 보는 게 이해에 도움이 됩니다.

    Linux LUKS suspend 보안 점검을 위한 커널 버전과 cryptsetup 확인 이미지

    커널 버전, cryptsetup 버전, suspend hook을 실제로 점검하는 터미널 중심 이미지입니다.

    8. 검증과 결과: 무엇을 확인하면 되나

    완성된 결과 확인은 “업데이트했다”에서 끝나면 안 됩니다. 운영에서는 아래 체크리스트까지 봐야 합니다. 이거 진짜 중요하더라고요.

    1. 커널 버전과 cryptsetup 버전을 문서화했는가
    2. luksSuspend 사용 경로가 실제로 존재하는가
    3. 민감 장비의 절전 정책이 suspend인지 hibernate인지 분리됐는가
    4. 보안 가이드에 “resume 비밀번호 프롬프트는 충분조건이 아님”이 반영됐는가

    제가 이런 류 이슈를 볼 때 늘 하는 방식은 간단합니다. 기능 설명 문구가 아니라 실제 위협 모델 기준으로 재평가하는 겁니다. 특히 출장 장비, 연구 장비, 고객 데이터가 실린 노트북은 더 그렇습니다. “암호화했으니 괜찮다”가 아니라 “절전 중에도 괜찮은가?”를 따로 봐야 하거든요.

    Linux LUKS suspend 보안 관점의 suspend와 hibernate 비교 인포그래픽

    절전 방식별 메모리 키 잔존 위험과 운영 편의성을 비교한 요약 이미지입니다.

    9. 마무리: 이번 이슈가 남긴 교훈

    이번 Linux LUKS suspend 보안 이슈를 보면서 다시 느낀 건, 보안은 결국 기능 존재 여부가 아니라 실제 동작 검증이라는 점입니다. 저도 처음엔 “luksSuspend까지 붙여 놨으면 꽤 단단하겠네”라고 생각했었는데, 이런 회귀가 나오면 운영 가정 자체를 다시 써야 하더라고요.

    정리하면 이렇습니다.

    • Linux 6.9 이후 luksSuspend 기반 보호 기대가 흔들린 공개 이슈가 있다.
    • 영향 범위는 모든 LUKS 사용자가 아니라 해당 suspend 잠금 흐름을 구성한 사용자 쪽에 더 직접적이다.
    • 콜드 부트 공격 같은 물리 접근 위협을 진지하게 보는 환경이라면 suspend-to-RAM보다 hibernation이 낫다.
    • cryptsetup 2.8.7의 keyring handling 변경 사항을 배포판에서 꼭 확인해야 한다.

    다음 글에서는 실제 배포판별로 cryptsetup-suspend, systemd sleep hook, hibernate 정책을 어떻게 점검하고 바꾸는지 더 실전적으로 다뤄볼 예정입니다. 이전 글에서 다룬 디스크 암호화 운영 체크리스트와도 이어서 보시면 훨씬 이해가 쉬우실 겁니다.

    참고 링크

  • [리눅스] Asahi Linux 1년 사용 후기: 2026년 10월 M1/M2/M3 업데이트

    [리눅스] Asahi Linux 1년 사용 후기: 2026년 10월 M1/M2/M3 업데이트

    [리눅스] Asahi Linux 1년 사용 후기: M1/M2/M3 맥북 회고

    Asahi Linux 사용 후기를 찾는 분들은 대체로 비슷한 고민을 하시더라고요. M1 맥북 리눅스가 이제 메인으로 쓸 만한지, 애플 실리콘 리눅스가 실험 단계를 넘었는지, 그리고 Fedora Asahi Remix가 실제 데스크톱으로 얼마나 버텨주는지 말입니다. 저도 처음엔 반신반의했어요. 맥북 하드웨어는 정말 맘에 드는데, 업무 습관은 리눅스 쪽에 더 붙어 있었거든요. 그래서 아예 1년 가까이 서브 머신이 아니라 거의 생활 머신처럼 굴려봤습니다.

    2026년 10월 기준으로 다시 보니, 핵심 흐름은 더 분명해졌습니다. M1/M2 맥북 리눅스는 안정적인 실사용 후보로 말할 수 있는 구간이 넓어졌고, Fedora Asahi Remix 44가 여전히 안정판 기준입니다. 다만 Fedora Asahi Remix 45 Beta가 공개되면서 GNOME 51, KDE Plasma 6.7 계열, 최신 개발 도구 흐름을 미리 확인할 수 있게 됐고, M3 Asahi Linux 지원도 8월에 비해 꽤 큰 폭으로 전진했습니다.

    Asahi Linux 사용 후기와 애플 실리콘 리눅스 개요를 보여주는 M1 맥북 다이어그램

    Asahi Linux 사용 후기의 전체 맥락을 한눈에 보여주는 개요 이미지입니다.

    1. 왜 Asahi Linux가 M1/M2 맥북에서 의미가 있었나

    쉽게 말해, 애플 실리콘(Apple Silicon, 애플의 ARM 기반 칩) 맥북은 하드웨어 완성도가 정말 높습니다. 배터리 효율, 발열, 키보드, 트랙패드, 화면 품질까지 기본 체급이 좋아요. 문제는 여기에 리눅스를 얹는 순간이었죠. x86 중심으로 익숙했던 리눅스 환경이 ARM64(AArch64, 64비트 ARM 아키텍처)로 옮겨오면서 생기는 미묘한 차이, 드라이버 문제, 부트 체계 차이 같은 것들이 생각보다 발목을 잡았거든요.

    제가 직접 써보니 Asahi Linux의 가치는 딱 두 가지였습니다. 첫째, 맥북 하드웨어를 포기하지 않고도 리눅스 워크플로를 가져갈 수 있다는 점. 둘째, 단순 부팅 성공이 아니라 데스크톱 사용성까지 신경 썼다는 점입니다. 특히 Fedora Asahi Remix 쪽은 설치 이후 일상적인 데스크톱 사용 흐름이 꽤 정돈돼 있어서, 예전처럼 “부팅은 되는데 그 다음이 문제” 같은 느낌이 많이 줄었어요.

    2. Asahi Linux 핵심 개념 정리

    저도 처음엔 헷갈렸는데, 이걸 이해하면 글이 훨씬 잘 읽힙니다.

    2-1. Asahi Linux는 배포판 이름이라기보다 프로젝트에 가깝습니다

    Asahi Linux는 애플 실리콘 맥에서 리눅스를 제대로 돌리기 위한 커널(Kernel, 운영체제 핵심), 부트로더(Bootloader, 부팅 로직), 드라이버(Driver, 하드웨어 제어 소프트웨어) 작업을 포함한 큰 프로젝트라고 보시면 됩니다. 그래서 실제 사용자는 프로젝트 자체보다, 그 결과물을 잘 묶어 제공하는 배포판 경험을 체감하게 됩니다.

    2-2. Fedora Asahi Remix는 실사용 관점의 진입점입니다

    여기서 많이들 접하는 게 Fedora Asahi Remix입니다. 2026년 10월 현재 안정판 기준은 Fedora Asahi Remix 44입니다. 공식 소개 기준으로 Fedora Linux 44 기반이며, KDE Plasma 데스크톱을 대표 경험으로 제공하고 GNOME 이미지도 함께 제공합니다. 그래픽 쪽은 OpenGL 4.6, OpenGL ES 3.2, OpenCL 3.0, Vulkan 1.4 지원을 이야기할 수 있는 단계까지 왔습니다.

    다만 글을 처음 썼던 7월 말과 달라진 점도 있습니다. 2026년 9월에는 Fedora Asahi Remix 45 Beta가 공개됐습니다. 아직 안정판으로 갈아탈 기준이라기보다는 테스트용에 가깝지만, Fedora 45 흐름과 Apple Silicon Linux 2026의 다음 단계를 미리 보는 의미가 있습니다.

    2-3. “맥북에 리눅스를 깐다”와 “메인으로 쓴다”는 다릅니다

    이 부분이 제일 중요합니다. 부팅이 되고 와이파이가 되고 브라우저가 뜨는 것과, 업무용으로 하루 종일 써도 스트레스가 적은 건 완전히 다른 문제거든요. 저는 1년 동안 이 차이를 계속 체크했습니다. Suspend(절전), 오디오, 외부 모니터, 패키지 호환성, 컨테이너 워크플로, 특정 상용 앱 대체 가능성까지요. 초반엔 “오 신기하다”였다가, 중반부터는 “이걸 계속 쓸 수 있나?”로 기준이 바뀌더라고요.

    구분 장점 아쉬운 점
    하드웨어 조용하고 효율이 좋음 세대별 지원 범위는 계속 확인 필요
    데스크톱 일상 작업 흐름이 꽤 자연스러움 macOS 전용 앱 대체는 별도 고민 필요
    개발 환경 터미널, SSH, Git, 컨테이너 워크플로가 편함 ARM64 패키지 차이로 삽질 가능
    운영 안정성 M1/M2 기준으로 꽤 안정적 Beta 버전과 최신 칩은 기대치 조절 필요

    3. 제가 1년 동안 어떻게 굴렸는지

    환경 이야기를 조금 해야 후기의 온도가 맞습니다. 저는 홈랩 장비에 SSH로 붙고, 브라우저에서 문서 작업하고, 로컬에서 Git(깃, 분산 버전 관리)과 컨테이너를 쓰고, 가끔은 원격 서버 디버깅도 했습니다. 딱 화려한 워크스테이션 용도라기보다, 인프라 엔지니어가 평일에 계속 만지는 생활형 환경이었죠.

    • 터미널 중심 작업: 이건 정말 잘 맞았습니다. 쉘 위주의 습관이 있다면 금방 적응합니다.
    • 브라우저 기반 업무: 문서, 대시보드, 클라우드 콘솔, 사내 웹툴 위주라면 크게 무리 없었습니다.
    • SSH와 개발 툴: 원격 서버 접속, 편집기, Git 흐름은 제 기준에선 충분히 실용적이었습니다.
    • 가벼운 데스크톱 몰입감: 팬 소음과 발열 부담이 적으니 장시간 작업할 때 확실히 편하더라고요.

    반대로, 제가 초반에 꽤 신경 썼던 건 “내가 지금 리눅스를 쓰는 건지, 리눅스 위에서 계속 호환성 체크를 하는 건지”였습니다. 이 느낌이 사라져야 메인으로 쓸 수 있거든요. 다행히 시간이 지나면서 기본 사용성은 점점 자연스러워졌어요.

    4. 설치와 초기 세팅에서 해둔 것들

    설치 자체는 공식 안내 흐름을 따르는 게 가장 안전합니다. 2026년 10월 현재도 macOS에서 시작하는 공식 설치 흐름은 유지되고 있고, 사용자 입장에서는 여전히 공식 설치 스크립트와 문서를 그대로 따르는 게 제일 덜 꼬입니다. 특히 안정적인 실사용 목적이라면 Fedora Asahi Remix 44를 기준으로 보고, 45 Beta는 테스트 머신이나 명확한 목적이 있을 때만 접근하는 쪽이 좋습니다.

    1. 설치 전 백업: 파티션 작업 전 백업은 습관처럼 하셔야 합니다.
    2. 업데이트 직후 재부팅: 초기 설치 후 패키지 업데이트를 먼저 반영하고, 장치 상태를 다시 확인합니다.
    3. 업무 툴 우선 설치: 브라우저, SSH 키, Git 설정, 에디터부터 잡아야 체감 품질을 빨리 볼 수 있습니다.
    4. ARM64 패키지 확인: 평소 쓰는 툴이 ARM64에서 바로 되는지 먼저 체크합니다.
    sudo dnf upgrade --refresh
    sudo dnf install git vim htop tmux fastfetch
    
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    ssh-keygen -t ed25519 -C "asahi-linux"
    
    git config --global user.name "Your Name"
    git config --global user.email "[email protected]"

    이건 화려한 세팅은 아닙니다. 근데 이런 기본기가 빨리 잡혀야 “오, 이거 메인 후보인데?”라는 감각이 옵니다. 참고로 예전에 많이 쓰던 neofetch는 유지보수 관점에서 fastfetch로 넘어가는 분들이 많아져서, 지금은 저도 fastfetch 쪽이 더 자연스럽습니다.

    4-1. 컨테이너 워크플로는 먼저 검증해보세요

    인프라 쪽 분들이면 여기 많이 궁금하실 겁니다. 컨테이너 엔진, 이미지 아키텍처, 개발용 데이터베이스 같은 것들요. 저는 여기서 가장 먼저 한 일이 “내 프로젝트가 ARM64에서도 문제없이 도는가” 확인하는 거였습니다.

    uname -m
    podman info
    podman pull docker.io/library/nginx:latest
    podman run --rm -p 8080:80 nginx:latest

    혹은 Docker를 쓰는 분들은 동일하게 이미지 아키텍처를 꼭 봐야 합니다. 예전 x86 이미지에만 익숙하면 여기서 한 번 멈칫하게 됩니다. 그래도 2026년 기준으로는 멀티 아키텍처 이미지가 훨씬 많아져서, 컨테이너 실사용 난이도는 예전보다 분명 낮아졌어요.

    Fedora Asahi Remix 설정과 M1 맥북 리눅스 초기 세팅 장면

    초기 설치와 패키지 세팅, ARM64 환경 점검 흐름을 설명하는 이미지입니다.

    5. 1년 써보며 좋았던 점: 생각보다 데스크톱이 자연스럽습니다

    Asahi Linux 사용 후기에서 제가 가장 높게 평가하는 건 “어느 순간 의식하지 않게 된다”는 점입니다. 좋은 도구는 존재감이 약해지거든요. 브라우저 열고, 터미널 띄우고, 원격 서버 들어가고, 문서 정리하고, 다시 로그 보고. 이런 일상이 특별한 이벤트 없이 이어지는 날이 많아질수록 신뢰가 생겼어요.

    • 조용한 작업 환경: 발열과 소음 스트레스가 적으니 집중이 잘 됩니다.
    • 기본기 위주의 사용성: 터미널, 브라우저, 에디터 중심 업무는 꽤 잘 맞습니다.
    • Fedora 기반 운영 편의: 업데이트와 패키지 흐름이 익숙해서 관리 부담이 덜합니다.
    • Wayland 중심 데스크톱 경험: HiDPI와 다중 디스플레이 감각이 꽤 자연스럽습니다.

    특히 원격 인프라 작업이 많은 분이라면 이 장점이 크게 다가옵니다. KVM, Kubernetes, VPN, SSH 포워딩 같은 단어가 일상에 섞여 있는 분들 말이죠. 물론 모든 시나리오가 완벽하다는 뜻은 아닙니다. 다만 적어도 “리눅스 데스크톱으로 업무가 끊기지 않는 구간”은 분명히 있습니다.

    6. ⚠️ 아쉬웠던 점과 실제 트러블슈팅

    이제 현실 이야기 해보겠습니다. 좋은 점만 쓰면 그건 후기보다 홍보에 가깝죠. 저도 삽질 좀 했습니다 ㅎㅎ 그리고 이 파트가 사실 제일 도움 되실 거예요.

    6-1. x86 감각으로 패키지를 고르면 꼭 한 번 막힙니다

    가장 흔한 문제는 아키텍처 차이입니다. 어떤 툴은 바로 되는데, 어떤 바이너리는 ARM64 빌드가 없거나 실험적일 수 있거든요. 해결은 단순합니다. 설치 전에 공식 지원 아키텍처를 먼저 봅니다. 무턱대고 curl로 설치 스크립트부터 때리는 습관은 여기선 위험합니다.

    uname -m
    rpm -qa | grep -i kernel
    cat /etc/os-release

    이 세 가지 출력만 봐도 지금 내 환경을 꽤 명확하게 설명할 수 있습니다. 문제 생겼을 때 포럼이나 이슈 트래커에 질문할 때도 훨씬 수월하고요.

    6-2. “업데이트하면 끝”이 아니라 “업데이트 후 확인”이 중요합니다

    이건 Asahi Linux만의 문제라기보다, 하드웨어 지원이 빠르게 발전하는 프로젝트 전반에 해당하는 이야기입니다. 커널, Mesa, 부트 관련 패키지가 얽혀 있으면 업데이트 후 체감이 달라질 수 있거든요. 그래서 저는 업데이트 직후 아래 정도는 꼭 확인했습니다.

    1. 재부팅이 정상적으로 되는지
    2. 와이파이와 블루투스가 평소처럼 동작하는지
    3. 오디오와 절전 복귀가 이상 없는지
    4. 외부 모니터나 자주 쓰는 주변기기가 그대로 붙는지

    별거 아닌 체크리스트 같죠? 근데 이런 기본 점검이 삽질 시간을 많이 줄여줍니다. 인프라 운영도 그렇지만, 데스크톱도 결국 체크리스트가 사람을 살립니다.

    6-3. macOS 대체 여부는 앱 의존성에서 갈립니다

    이건 기술보다 습관 문제에 가깝습니다. 특정 상용 앱, 특정 회사 VPN 클라이언트, 특정 회의 도구, 특정 주변기기 설정 앱이 꼭 필요하다면 애플 실리콘 리눅스가 불편해질 수 있습니다. 저도 순수 웹 기반과 SSH 중심일 땐 정말 편했는데, 한두 개 전용 앱이 끼는 순간 “아, 이건 분리해서 써야겠네” 싶더라고요.

    Asahi Linux 사용 후기의 트러블슈팅과 업데이트 점검 장면

    업데이트 후 문제를 점검하고 로그를 확인하는 실제 트러블슈팅 흐름을 표현한 이미지입니다.

    7. 검증: 메인 데스크톱으로 쓸 수 있었나

    제 기준의 검증 포인트는 단순했습니다. “하루 종일 써도 신경이 덜 쓰이느냐”였어요. 벤치마크 숫자보다 더 중요한 건, 업무 중간에 운영체제가 존재감을 과하게 드러내지 않는가였습니다.

    • 브라우저, 터미널, SSH, Git 중심이라면 꽤 만족스러웠습니다.
    • 로컬 개발과 경량 컨테이너 작업도 흐름이 괜찮았습니다.
    • 특정 앱 의존성이 낮을수록 만족도가 올라갔습니다.
    • 완전한 만능 메인 머신이라기보다, 조건이 맞으면 아주 강한 메인 후보였습니다.

    제가 1년 동안 써보며 느낀 핵심은, Asahi Linux 사용 후기를 검색하는 분들이 기대하는 “이제 진짜 써도 되나요?”에 대한 답은 “용도 따라 yes”라는 겁니다. 예전처럼 무조건 실험용이라고 말하기엔 너무 많이 좋아졌고, 반대로 아무 설명 없이 모두에게 추천하기엔 아직 변수도 있습니다.

    fastfetch || true
    uptime
    free -h
    df -h
    journalctl -b -p warning
    Asahi Linux 사용 후기 결과 검증을 보여주는 애플 실리콘 리눅스 데스크톱 화면

    실사용 검증 결과를 보여주는 시스템 상태 확인 이미지입니다.

    8. 2026년 10월 기준 달라진 점

    원래 글을 썼을 때보다 지금은 분명 바뀐 부분이 있습니다. 특히 Fedora Asahi Remix 45 Beta, M3 MacBook Linux 지원, Vulkan 1.4, Apple Video Decoder, 그리고 M4/M5 지원 현황은 따로 짚고 넘어가는 게 맞겠더라고요.

    8-1. 안정판 기준은 Fedora Asahi Remix 44, 45는 Beta입니다

    2026년 10월 4일 기준으로 안정적인 실사용 글을 쓴다면 기준점은 여전히 Fedora Asahi Remix 44입니다. Fedora Linux 44 기반이고, Apple Silicon용 그래픽 스택은 OpenGL 4.6, OpenGL ES 3.2, OpenCL 3.0, Vulkan 1.4 지원까지 올라와 있습니다.

    새로운 점은 Fedora Asahi Remix 45 Beta입니다. Fedora Linux 45 Beta가 2026년 9월 15일 공개됐고, Asahi Remix 45 Beta도 테스트용으로 공개됐습니다. 이쪽은 최신 GNOME 51, KDE Plasma 6.7 계열, 최신 Podman과 개발 도구 흐름을 확인할 수 있다는 장점이 있지만, 이름 그대로 Beta입니다. 업무 메인 장비라면 안정판과 베타를 구분해서 접근하는 게 맞습니다.

    8-2. M3 지원은 눈에 띄게 전진했습니다

    8월에 비해 가장 크게 바뀐 건 M3 Asahi Linux 지원입니다. 최근 진행 상황을 보면 M3 계열에서 웹캠, 내장 마이크, USB, 하드웨어 비디오 디코딩, Wi-Fi, Bluetooth 같은 기본 장치 지원이 많이 올라왔습니다. 예전처럼 “아직은 거의 WIP로만 봐야 한다”고만 말하기엔 상황이 꽤 달라졌습니다.

    다만 제 표현은 여전히 조심스럽습니다. M1/M2처럼 오래 굴려본 안정감과 M3의 최신 지원 상태는 결이 다릅니다. M3 맥북에 바로 설치하려는 분이라면 공식 feature support 문서와 Fedora Asahi Remix 45 Beta 안내를 같이 확인하는 게 좋습니다. 특히 메인 장비 하나만 들고 작업하는 분이라면 “된다”보다 “내 장비의 어떤 장치가 어느 단계인가”를 먼저 보셔야 합니다.

    8-3. 비디오 디코딩, Vulkan, 전력 관리도 계속 좋아지고 있습니다

    그래픽과 미디어 쪽도 계속 전진하고 있습니다. Fedora Asahi Remix는 Apple Silicon에서 Vulkan 1.4까지 이야기할 수 있는 단계가 됐고, Apple Video Decoder와 Vulkan Video 관련 작업도 이어지고 있습니다. M3 쪽에서는 AV1을 포함한 하드웨어 가속 비디오 디코딩 지원이 언급될 정도로 진행이 빨라졌습니다.

    다만 이 부분도 과장하면 안 됩니다. 하드웨어 디코딩은 커널과 드라이버만의 문제가 아니라 브라우저, 미디어 플레이어, VA-API/V4L2 경로, 앱별 기본값까지 얽힙니다. 그래서 “지원된다”와 “내가 쓰는 앱에서 자동으로 잘 된다” 사이에는 아직 확인할 거리가 있습니다. 그래도 Apple Silicon Linux 2026 흐름에서 이 변화는 꽤 중요합니다.

    9. 새로 볼 변화: Fedora Asahi Remix 45 Beta와 M4/M5 초기 작업

    이번 업데이트에서 새로 추가할 만한 변화는 두 가지입니다.

    첫째, Fedora Asahi Remix 45 Beta입니다. 안정판을 대체하는 결론은 아니지만, Fedora 45 기반 Asahi 환경을 공식 흐름 안에서 테스트할 수 있게 됐다는 점은 의미가 큽니다. 새 커널, 새 데스크톱, 새 개발 도구를 빨리 확인해야 하는 분에게는 테스트 가치가 있습니다.

    둘째, M4/M5 지원 작업입니다. 아직 일반 사용자에게 추천할 단계는 아니지만, 최근 진행 보고에서는 M4와 M5 쪽 NVMe 작업 같은 저수준 기반 작업이 언급됐습니다. 즉 M4/M5 MacBook Linux를 당장 메인으로 쓰라는 뜻은 아니고, 프로젝트가 M1/M2에서 멈춘 것이 아니라 최신 Apple Silicon 세대까지 계속 전진하고 있다는 신호로 보는 게 맞습니다.

    10. 누구에게 추천하고, 누구에게는 아직 이르냐

    대상 판단
    M1/M2 맥북 사용자 터미널·브라우저·개발 중심이면 진지하게 검토 가능
    M3 맥북 사용자 지원이 크게 좋아졌지만 장치별 상태 확인 후 접근 추천
    M4/M5 최신 기기 사용자 아직은 개발 진행 상황을 지켜보는 쪽이 안전
    터미널 중심 개발자/엔지니어 리눅스 워크플로 이점이 바로 체감됨
    브라우저 기반 업무 비중이 높은 분 앱 의존성이 낮아 전환 장벽이 낮음
    특정 macOS 전용 앱 필수 사용자 아직은 이중 운영이 더 현실적일 수 있음

    혹시 이런 경험 있으신가요? 하드웨어는 너무 마음에 드는데 운영체제가 습관에 안 맞아서 계속 겉도는 느낌요. 그런 분이라면 Asahi Linux는 분명 매력적인 선택지입니다. 반대로 회의 앱, 보안 프로그램, 기업 전용 앱이 필수라면 아직은 기대치를 조금 조절하시는 게 좋습니다.

    11. 마무리: 1년 써본 결론과 다음 단계

    정리해보면, Asahi Linux 사용 후기를 한 문장으로 줄이면 이렇습니다. “M1/M2 맥북에서 리눅스 데스크톱은 이제 진지하게 검토할 만한 단계까지 왔다.” 제가 실제로 써보니까 감탄 포인트는 화려한 기능보다도 일상의 자연스러움에 있었습니다. 터미널 열고, 서버 붙고, 패키지 관리하고, 문서 보고, 다시 로그 보는 그 흐름이 꽤 편했거든요.

    2026년 10월 업데이트 기준으로는 여기에 한 문장을 더 붙이고 싶습니다. “M3 지원은 빠르게 실사용권으로 들어오고 있지만, 안정판 기준과 Beta 기준은 분리해서 봐야 한다.” 특히 Fedora Asahi Remix 44와 45 Beta를 혼동하지 않는 것이 중요합니다. 안정적인 생활 머신을 원하면 Fedora Asahi Remix 44, 최신 지원 상태를 테스트하고 싶으면 Fedora Asahi Remix 45 Beta라는 식으로 접근하면 훨씬 덜 헷갈립니다.

    정리 FAQ

    Q1. Asahi Linux는 지금 메인으로 써도 되나요?

    M1/M2 맥북에서 브라우저, 터미널, SSH, Git, 컨테이너 중심이면 충분히 메인 후보입니다. 다만 회사 보안 프로그램, macOS 전용 앱, 특정 회의 도구가 필수라면 먼저 대체 가능성을 확인하세요.

    Q2. M3 맥북에도 Asahi Linux를 추천하나요?

    2026년 10월 기준으로 M3 지원은 크게 좋아졌습니다. 그래도 M1/M2보다 검증 기간이 짧기 때문에 공식 feature support 문서를 보고 내 모델의 웹캠, 오디오, USB, 외부 디스플레이, 절전 상태를 확인한 뒤 접근하는 게 좋습니다.

    Q3. Fedora Asahi Remix 44와 45 Beta 중 무엇을 설치해야 하나요?

    실사용 안정성을 우선하면 Fedora Asahi Remix 44가 기준입니다. Fedora Asahi Remix 45 Beta는 최신 Fedora 45 흐름과 M3 관련 변화를 빠르게 확인하고 싶은 테스트용 선택지에 가깝습니다.

    Q4. M4/M5 맥북 리눅스는 지금 어떤가요?

    개발은 진행 중이지만 일반 사용자에게 바로 추천할 단계는 아닙니다. M4/M5 Asahi Linux 지원은 아직 초기 기반 작업과 세대별 하드웨어 대응을 지켜보는 쪽이 안전합니다.

    Q5. 참고한 공식 정보는 어디인가요?

    업데이트 기준은 Fedora Asahi Remix 공식 페이지, Fedora Asahi Remix 44 발표, Fedora Asahi Remix 45 Beta 안내, Asahi Linux M3 진행 보고, Asahi Linux feature support 문서를 확인했습니다.

    🔄 마지막 업데이트: 2026년 10월

  • [Linux] 리눅스 성능 모니터링 툴 벤치마크: htop, glances, atop 실측 비교

    [Linux] 리눅스 성능 모니터링 툴 벤치마크: htop, glances, atop 실측 비교

    리눅스 성능 모니터링 툴 벤치마크: htop, glances, atop 실측 비교

    리눅스 성능 모니터링 툴을 고를 때 은근히 많이 고민하게 됩니다. CPU만 빨리 훑어보면 되는지, 메모리 누수까지 봐야 하는지, 아니면 장애가 지나간 뒤에 기록을 다시 뒤져야 하는지에 따라 답이 완전히 달라지거든요. 저도 홈랩 서버랑 작은 서비스 노드를 굴리면서 htop, glances, atop을 번갈아 써봤는데요. 처음엔 “다 비슷한 거 아닌가?” 싶었는데, 실제로 써보니까 보는 관점도 다르고 시스템 자원 사용량도 꽤 차이가 나더라고요.

    이번 글은 리눅스 성능 모니터링 툴을 고를 때 감으로 선택하지 않도록, 제가 실무와 홈랩에서 자주 쓰는 세 가지 도구를 같은 조건에서 비교하는 방식으로 정리한 내용입니다. 제목은 벤치마크라고 적었지만, 확실하지 않은 수치를 억지로 붙이기보다는 측정 방법, 관찰 포인트, 그리고 반복 사용에서 드러난 경향에 초점을 맞췄습니다. htop glances atop 비교가 필요하셨다면 아마 이 포인트가 더 실전적일 겁니다.

    리눅스 성능 모니터링 툴 비교 개요 이미지

    htop, glances, atop이 CPU, 메모리, 프로세스, 기록 보존 관점에서 어떻게 다른지 한눈에 보여주는 개요 이미지입니다.

    왜 이 비교가 중요한가: 보이는 정보와 남는 기록은 다릅니다

    쉽게 말해, 성능 모니터링은 “지금 무슨 일이 벌어지는지” 보는 작업과 “아까 무슨 일이 있었는지” 추적하는 작업으로 나뉩니다. 여기서 많은 분들이 처음 삽질합니다. 저도 예전에 CPU 스파이크가 한 번 튀고 끝나는 장애를 겪었는데, htop만 켜 두고는 원인을 못 잡았거든요. 그때 느꼈습니다. 실시간 뷰(real-time view)와 히스토리컬 로깅(historical logging, 과거 기록 보존)은 완전히 다른 문제라는 걸요.

    세 도구를 아주 단순하게 요약하면 이렇습니다.

    • htop: 빠르게 현재 상태를 읽기 좋습니다.
    • glances: 한 화면에서 많은 지표를 보고 싶을 때 편합니다.
    • atop: 나중에 되짚어보는 기록형 분석에 강합니다.

    여기서 중요한 포인트! “무조건 가벼운 툴”이 정답은 아닙니다. 장애 대응에서는 몇 퍼센트의 오버헤드보다, 어떤 정보를 놓치지 않느냐가 더 중요할 때가 많습니다.

    핵심 개념 정리: 리눅스 성능 모니터링 벤치마크를 볼 때 무엇을 비교해야 하나

    리눅스 성능 모니터링 도구 벤치마크를 이야기할 때 흔히 CPU 점유율만 보는 경우가 있는데요. 실제로는 그것만 보면 절반만 본 겁니다. 제가 직접 비교할 때는 아래 네 가지를 먼저 봅니다.

    1. CPU overhead: 도구 자신이 CPU를 얼마나 쓰는지
    2. Memory footprint: 상주 메모리(RSS, Resident Set Size)가 얼마나 되는지
    3. Refresh model: 화면 갱신 주기와 수집 방식이 어떤지
    4. Retention: 데이터가 휘발되는지, 기록으로 남는지

    특히 glances는 Python 기반이라 플러그인, 센서, 네트워크, 디스크 통계를 폭넓게 엮어 보여주는 장점이 있지만, 환경에 따라 체감 무게가 달라질 수 있습니다. 반대로 htop은 C 기반의 가벼운 인터랙티브 뷰라는 인상이 강하고요. atop은 화면만 보면 투박한데, 기록을 남기고 재생(replay)하듯 보는 흐름이 진짜 강점입니다.

    리눅스 모니터링 툴 비교 기준 표

    항목 htop glances atop
    주요 용도 실시간 프로세스 확인 다지표 통합 관찰 기록 기반 사후 분석
    초기 학습 난이도 낮음 낮음~중간 중간
    화면 정보량 중간 높음 높음
    과거 기록 추적 사실상 없음 기본 화면 중심 강함
    시스템 자원 사용량 경향 대체로 가벼움 환경 따라 상대적으로 무거움 기록 기능 포함 시 중간

    실전 구현: 같은 조건에서 htop, glances, atop 비교하는 방법

    제가 실측 비교할 때는 “툴이 보이는 내용”이 아니라 “툴이 시스템에 추가로 주는 부담”을 분리해서 봅니다. 이때 제일 흔한 실수가 SSH 세션 상태, 터미널 크기, 갱신 주기를 다르게 둔 채 비교하는 겁니다. 저도 처음엔 그렇게 했다가 결과가 들쭉날쭉해서 다시 했었습니다 ㅎㅎ

    아래 예시는 Debian/Ubuntu 계열 기준이지만, RHEL 계열도 패키지 이름만 조금 다를 뿐 흐름은 같습니다.

    1. 도구 설치

    sudo apt update
    sudo apt install -y htop glances atop sysstat procps

    sysstat는 pidstat(프로세스별 통계), sar(시스템 활동 리포트) 같은 도구를 포함하므로 벤치마크 보조 도구로 매우 유용합니다.

    2. 테스트 전 환경 고정

    1. 가능하면 같은 서버, 같은 커널, 같은 부하 상태에서 비교합니다.
    2. 다른 모니터링 에이전트(node exporter, telegraf 등)가 과도하게 돌아가면 변수로 작용할 수 있습니다.
    3. 비교 대상 툴의 갱신 주기를 맞춥니다.
    4. 최소 3회 이상 반복합니다.
    uname -a
    cat /etc/os-release
    uptime
    free -h
    nproc

    이 정보는 나중에 결과를 다시 볼 때 꽤 중요합니다. 특히 코어 수가 다르면 체감 오버헤드 해석도 달라지거든요.

    3. 기준 부하 없이 idle 상태에서 측정

    먼저 아무 부하를 주지 않은 상태에서 각 툴을 1초 갱신 기준으로 실행해 봅니다. 그리고 다른 터미널에서 pidstat로 해당 프로세스의 CPU와 메모리를 관찰합니다.

    htop -d 100
    glances
    atop

    참고로 htop의 <code>-d 옵션은 갱신 주기를 1/100초 단위로 설정합니다. 1초 갱신은 -d 100이고, 0.5초는 -d 50이라고 생각하면 됩니다. glances와 atop은 기본 동작이 배포판과 설정에 따라 다를 수 있으니, 실제 환경에서는 도움말을 꼭 확인하세요.

    pidstat -rud -p ALL 1

    또는 특정 프로세스만 보고 싶다면 이렇게 좁혀도 됩니다.

    pgrep -x htop
    pgrep -x glances
    pgrep -x atop
    pidstat -rud -p <PID> 1
    리눅스 성능 모니터링 툴 실측 비교 터미널 구성 이미지

    한쪽 터미널에서 모니터링 툴을 실행하고, 다른 쪽에서 pidstat로 해당 프로세스를 추적하는 실전 구성 예시입니다.

    4. 가벼운 CPU 부하를 준 상태에서 측정

    idle 상태만 보면 재미가 없습니다. 실제 문제는 부하가 걸릴 때 드러나니까요. 저는 간단한 CPU 부하를 줄 때 yes나 openssl 같은 익숙한 도구를 씁니다. 너무 공격적인 벤치 툴을 먼저 쓰면 오히려 모니터링 툴 차이가 묻히더라고요.

    yes > /dev/null &
    yes > /dev/null &
    yes > /dev/null &
    yes > /dev/null &
    
    uptime
    pidstat -rud -p ALL 1

    테스트가 끝나면 부하 프로세스를 정리합니다.

    pkill -f '^yes$'

    이 상태에서 제가 반복해서 본 경향은 대체로 이렇습니다.

    • htop은 현재 CPU 바, 코어별 사용량, 프로세스 정렬을 빠르게 읽기에 좋았습니다.
    • glances는 한 화면에 CPU, 메모리, load average(로드 애버리지, 평균 부하), 네트워크, 디스크 I/O를 다 보니 진짜 편했는데, 화면 정보량이 많은 만큼 환경에 따라 좀 더 무겁게 느껴질 수 있었습니다.
    • atop은 즉시성보다는 기록성과 해석력이 강했습니다. 순간 피크보다, 일정 시간 동안 어떤 프로세스가 문제였는지 뒤늦게 찾을 때 진가가 나옵니다.

    5. 메모리와 기록 기능까지 포함해 비교

    단순 화면 도구처럼 보여도, 내부적으로 무엇을 수집하느냐에 따라 차이가 있습니다. 특히 atop은 로그 파일을 남기는 구성을 함께 보셔야 합니다.

    ps -o pid,ppid,cmd,%mem,rss,vsz -C htop -C glances -C atop
    sudo systemctl status atop

    배포판에 따라 atop 로그 서비스가 활성화되어 있을 수 있습니다. 이 기록 덕분에 나중에 재생하듯 분석할 수 있는데, 반대로 디스크 기록을 싫어하는 환경에서는 정책을 확인해야 합니다.

    sudo atop -r /var/log/atop

    이 기능 때문에 저는 “장애 재현이 어려운 서버”에서는 atop을 꽤 높게 평가합니다. 실시간 화면만 보면 htop이 더 편할 때가 많아도, 사건이 지나간 뒤에는 기록이 있는 쪽이 훨씬 유리하거든요.

    주의사항과 트러블슈팅: 제가 실제로 부딪힌 포인트들

    여기서부터가 진짜 중요합니다. 벤치마크는 명령어 몇 줄보다 변수 통제가 핵심이거든요.

    ⚠️ glances가 유독 무겁게 느껴질 때

    처음 glances를 띄웠는데 “어? 생각보다 무거운데?” 싶었던 적이 있었습니다. 실제로 써보니까 센서 수집, 네트워크 정보, 파일시스템 정보 등 표시 범위가 넓을수록 체감 부담이 커질 수 있더라고요. 특히 오래된 VM이나 저사양 홈서버에서는 더 민감했습니다.

    • 불필요한 플러그인 성격의 표시를 줄입니다.
    • 갱신 주기를 너무 짧게 잡지 않습니다.
    • 비교할 때는 htop과 동일한 관찰 시간, 동일한 세션 조건을 맞춥니다.

    ⚠️ htop은 편하지만 과거 장애 증거가 안 남습니다

    이건 정말 많이 겪습니다. htop은 그 순간 보기엔 최고인데, 나중에 “그때 누가 CPU를 먹었죠?”라고 물으면 답이 없습니다. 스크린샷을 남겨둔 게 아니면요. 그래서 저는 운영 서버에서는 htop만 믿지 않고, 최소한 sar나 atop 같은 기록형 도구를 같이 둡니다.

    ⚠️ atop은 처음 보면 화면이 낯설 수 있습니다

    저도 처음엔 솔직히 htop보다 훨씬 덜 친절하게 느꼈습니다. 근데 며칠 써보니까 생각이 바뀌더라고요. 프로세스, 디스크, 메모리, 스케줄링 흔적을 시간축과 같이 보는 흐름이 익숙해지면 오히려 분석이 빨라집니다.

    리눅스 성능 모니터링 툴 atop 기록 추적 이미지

    atop 로그를 저장하고 특정 시점으로 되돌아가며 CPU 스파이크 원인을 추적하는 흐름을 설명하는 이미지입니다.

    검증 결과: 어떤 상황에서 무엇이 더 맞았나

    이제 결과를 정리해보겠습니다. 수치를 단정적으로 적지 않는 이유는, 배포판과 커널, Python 런타임, 플러그인 활성화 상태에 따라 차이가 꽤 날 수 있어서입니다. 대신 반복 관찰에서 흔들리지 않던 결론은 분명했습니다.

    리눅스 성능 분석 실전 관찰 요약

    사용 시나리오 가장 잘 맞는 도구 이유
    SSH로 급하게 현재 상태 확인 htop 정렬, 필터, 프로세스 탐색이 직관적임
    한 화면에서 전체 상태 훑기 glances CPU, 메모리, 디스크, 네트워크를 통합해서 보기 좋음
    장애 후 원인 추적 atop 기록 기반 재확인이 가능함
    저사양 환경에서 최소 부담 선호 htop 대체로 가볍고 즉응성이 좋음
    운영 서버의 장기 관찰 atop + 다른 경량 지표 도구 실시간보다 사후 분석 가치가 큼

    제가 직접 해보니 시스템 자원 사용량만 놓고 보면 htop이 가장 부담이 적다고 느껴지는 경우가 많았습니다. 반대로 glances는 가장 많은 정보를 짧은 시간에 보여줘서, 장애 초기 탐색에는 이거 진짜 편하더라고요. atop은 처음 적응이 필요하지만, 서버 성능 분석을 나중에 다시 해야 하는 팀 운영 환경에서는 가장 실무적이었습니다.

    즉, “무엇이 최고냐”보다는 “어떤 장애 패턴을 잡고 싶은가”가 먼저입니다. 이 기준이 없으면 도구 비교는 항상 애매해집니다.

    리눅스 성능 모니터링 툴 결과 비교 이미지

    htop, glances, atop 화면에서 어떤 지점을 보면 되는지 CPU, 메모리, I/O 관점으로 비교한 결과 요약 이미지입니다.

    추천 조합: 하나만 고르지 말고 역할을 나누세요

    개인적으로는 하나만 고집하는 것보다 역할 분담이 훨씬 낫다고 봅니다. 저도 예전엔 “주력 도구 하나면 되지”라고 생각했었는데, 결국 운영에서는 조합이 답이더라고요.

    1. 평소 SSH 점검: htop
    2. 문제 초기 탐색: glances
    3. 사후 분석과 기록: atop

    만약 단 하나만 먼저 익혀야 한다면, 입문자에게는 htop을 권합니다. 반대로 장애 분석 책임이 있는 운영자라면 atop을 꼭 한 번 익혀보세요. glances는 “한눈에 많이 보고 싶다”는 분들에게 잘 맞습니다.

    자주 묻는 질문

    Q1. 리눅스 성능 모니터링 툴로 초보자에게 가장 쉬운 건 뭔가요?

    htop입니다. 프로세스 정렬과 색상 구분이 직관적이라 접근 장벽이 낮습니다.

    Q2. htop glances atop 비교에서 가장 큰 차이는 뭔가요?

    정보의 성격입니다. htop은 현재 상태, glances는 통합 관찰, atop은 기록 기반 분석에 강합니다.

    Q3. 운영 서버에 하나만 둬야 한다면요?

    장애 원인 추적이 중요하다면 atop 쪽이 더 실용적입니다. 다만 즉시성은 htop이 더 편할 수 있습니다.

    마무리: 벤치마크의 핵심은 숫자보다 맥락입니다

    이번 비교를 하면서 다시 느낀 건, 리눅스 성능 모니터링 툴 벤치마크는 단순히 누가 더 가볍냐를 가리는 싸움이 아니라는 점입니다. 실제로 써보니까 htop, glances, atop은 경쟁자라기보다 역할이 다른 도구에 가깝습니다. 처음엔 저도 숫자 하나로 결론 내리고 싶었는데, 운영 경험이 쌓일수록 그런 비교가 별 의미 없더라고요.

    정리하면 이렇습니다. 지금 당장 빠르게 본다? htop. 여러 자원을 한 화면에서 본다? glances. 장애가 지나간 뒤 원인을 캔다? atop. 이 기준만 잡혀도 선택이 훨씬 쉬워집니다.

    다음 글에서는 pidstat, sar, vmstat까지 포함해서 CLI 기반 서버 성능 분석 루틴을 묶는 방법을 다뤄볼 예정입니다. 이전 글에서 다룬 로그 확인 루틴과 함께 보시면 운영 대응 속도가 훨씬 빨라질 겁니다.

    상황별로 htop, glances, atop 중 어떤 도구를 고르면 되는지 한눈에 정리한 요약 인포그래픽입니다.

  • [리눅스] NetworkManager vs systemd-networkd 비교: 최적의 선택은?

    [리눅스] NetworkManager vs systemd-networkd 비교: 최적의 선택은?

    [리눅스] NetworkManager vs systemd-networkd 비교: 최적의 선택은?

    리눅스에서 네트워크가 한 번 꼬이기 시작하면, 진짜 별거 아닌 설정 하나 때문에 한참 붙잡고 있게 되더라고요. 특히 NetworkManager systemd-networkd 비교를 제대로 안 하고 그냥 배포판 기본값만 따라가면, 데스크톱에서는 편한데 서버에서는 과한 경우가 있고, 반대로 서버에서는 깔끔한데 노트북에서는 불편한 경우가 생깁니다. 저도 홈랩에서 Ubuntu, Debian, Fedora 계열을 섞어 쓰면서 리눅스 네트워크 관리 방식 때문에 삽질 좀 했습니다 ㅎㅎ

    이번 글에서는 제가 실제로 운영하면서 느낀 기준으로, NetworkManager와 systemd-networkd를 비교해보겠습니다. 쉽게 말해 둘 다 네트워크 인터페이스를 올리고 IP, 게이트웨이, DNS를 관리하는 도구인데, 철학과 쓰임새가 꽤 다릅니다. 데스크톱, 노트북, 서버, 홈랩 환경에서 뭐가 더 잘 맞는지 감 잡으실 수 있게 정리해볼게요.

    NetworkManager systemd-networkd 비교를 보여주는 리눅스 네트워크 아키텍처 이미지

    데스크톱, 노트북, 서버 환경에서 두 도구가 어디에 잘 맞는지 한눈에 보여주는 개요 이미지입니다.

    1. 왜 이 비교가 중요한가: 서버 네트워크 설정은 한번 정하면 오래 갑니다

    네트워크 설정 도구는 단순히 IP만 넣는 수준이 아닙니다. DNS Resolver(리졸버, 이름 해석기), Bridge(브리지, 가상 스위치), Bonding(본딩, 다중 NIC 묶기), VLAN(가상 LAN), Wi-Fi(무선 네트워크), VPN(가상사설망)까지 이어지거든요. 처음 선택이 애매하면 운영 중간에 갈아타면서 서비스 다운타임까지 생길 수 있습니다.

    제가 직접 해보니 데스크톱 네트워크는 사용자가 자주 바뀌는 연결 상태를 다뤄야 해서 자동화와 UI가 중요했고, 반대로 서버 네트워크 설정은 단순하고 예측 가능한 구성이 더 중요했습니다. 여기서 중요한 포인트! 편의성이 곧 정답은 아니고, 단순함이 곧 만능도 아닙니다.

    2. 개념부터 쉽게: NetworkManager와 systemd-networkd는 뭐가 다른가

    쉽게 말해 NetworkManager는 사용자 환경 친화적인 네트워크 관리자거든요. 유선뿐 아니라 Wi-Fi, VPN, 여러 프로파일 전환, GUI 연동까지 잘 해주죠. 반면 systemd-networkd는 더 작고 단순한 서비스 지향 도구에 가까워요. 설정 파일 기반으로 네트워크를 선언하고, 부팅 시 안정적으로 올리는 데 강점이 있습니다.

    항목 NetworkManager systemd-networkd
    주 사용 환경 데스크톱, 노트북, 혼합 환경 서버, VM, 컨테이너 호스트, 홈랩
    설정 방식 nmcli, nmtui, GUI, 프로파일 기반 .network, .netdev 파일 기반
    Wi-Fi/VPN 강함 제한적, 별도 도구 조합 필요
    구성 단순성 기능이 많아 다소 복잡할 수 있음 단순하고 예측 가능함
    서버 자동화 가능하지만 환경 따라 다름 설정 파일 관리에 잘 맞음
    학습 난이도 입문은 쉬움 개념 이해가 필요함

    처음엔 이게 뭔가 싶었는데, 결국 차이는 이겁니다. NetworkManager는 변화가 많은 사용자 환경에 강하고, systemd-networkd는 고정된 인프라 환경에 강합니다. 이 한 줄이 핵심이에요.

    3. 어떤 환경에서 뭘 고르면 좋나: 선택 기준 정리

    데스크톱 네트워크라면 NetworkManager가 편합니다

    • Wi-Fi SSID를 자주 바꿔야 할 때
    • VPN 연결을 자주 올리고 내릴 때
    • GUI 환경에서 빠르게 상태를 보고 싶을 때
    • 노트북처럼 이동성이 중요한 환경

    실제로 써보니까 노트북에서는 NetworkManager가 진짜 편하더라고요. 유선 꽂았다가 빼고, 집 Wi-Fi와 회사 Wi-Fi를 넘나들고, 잠깐 핫스팟 붙는 일까지 생각하면 이쪽이 훨씬 자연스럽습니다.

    서버 네트워크 설정이라면 systemd-networkd가 깔끔한 경우가 많습니다

    • 고정 IP 위주로 운영할 때
    • 브리지, VLAN, Bonding 같은 선언형 구성이 필요할 때
    • GUI 없이 최소 구성으로 운영할 때
    • 재부팅 후에도 예측 가능한 상태가 중요할 때

    저는 홈랩 KVM 호스트와 몇몇 작은 서비스 VM에서는 networkd 쪽을 더 선호합니다. 설정 파일이 명확해서 Git으로 추적하기도 좋고, 나중에 다시 봐도 덜 헷갈리거든요.

    4. 실전 구현 1: NetworkManager로 고정 IP 구성하기

    먼저 NetworkManager 예제를 보겠습니다. 인터페이스 이름은 예시로 <code>enp1s0를 쓰겠습니다. 배포판마다 이름이 다를 수 있으니 먼저 인터페이스를 확인하세요.

    1. 현재 인터페이스와 연결 상태를 확인합니다.
    2. 새 프로파일을 만들고 고정 IP를 넣습니다.
    3. 연결을 활성화한 뒤 상태를 확인합니다.
    ip link show
    nmcli device status
    nmcli connection show

    고정 IP 프로파일 생성 예제입니다.

    sudo nmcli connection add \
      type ethernet \
      ifname enp1s0 \
      con-name static-enp1s0 \
      ipv4.addresses 192.168.10.20/24 \
      ipv4.gateway 192.168.10.1 \
      ipv4.dns "1.1.1.1 8.8.8.8" \
      ipv4.method manual \
      autoconnect yes

    적용은 이렇게 합니다.

    sudo nmcli connection up static-enp1s0
    nmcli connection show static-enp1s0

    기존 DHCP 프로파일이 남아 있으면 우선순위 때문에 헷갈릴 수 있습니다. 저도 예전에 유선 프로파일이 두 개 살아 있어서, 분명 고정 IP 넣었는데 DHCP 주소가 다시 붙는 바람에 한참 봤었거든요. 이럴 때는 안 쓰는 프로파일을 정리하는 게 좋습니다.

    nmcli connection show
    sudo nmcli connection delete "Wired connection 1"
    NetworkManager systemd-networkd 비교 중 NetworkManager nmcli 고정 IP 설정 이미지

    NetworkManager에서 nmcli로 프로파일을 만들고 활성화하는 흐름을 보여주는 이미지입니다.

    5. 실전 구현 2: systemd-networkd로 고정 IP 구성하기

    이번에는 systemd-networkd입니다. 이쪽은 선언형 설정 파일이 핵심입니다. 파일 이름은 보통 숫자 접두어를 붙여 정렬되게 관리합니다.

    1. /etc/systemd/network/ 아래에 인터페이스 설정 파일을 만듭니다.
    2. networkd와 필요하면 resolved를 활성화합니다.
    3. 상태를 확인하고, 기존 관리자와 충돌이 없는지 점검합니다.

    예시 파일입니다.

    # /etc/systemd/network/10-enp1s0.network
    [Match]
    Name=enp1s0
    
    [Network]
    Address=192.168.10.20/24
    Gateway=192.168.10.1
    DNS=1.1.1.1
    DNS=8.8.8.8

    서비스 활성화는 아래처럼 진행합니다.

    sudo systemctl enable --now systemd-networkd
    sudo systemctl enable --now systemd-resolved
    networkctl status enp1s0

    DNS 쪽은 배포판마다 차이가 있어서 /etc/resolv.conf 연결 상태도 같이 보는 게 좋습니다.

    ls -l /etc/resolv.conf
    resolvectl status

    Bridge가 필요한 서버라면 networkd가 꽤 직관적입니다. 예를 들어 가상화 호스트에서 브리지 인터페이스를 만들 때, 파일 두세 개로 구조가 눈에 보이게 정리됩니다. GUI가 필요 없는 환경에서는 이게 정말 편하더라고요.

    # /etc/systemd/network/20-br0.netdev
    [NetDev]
    Name=br0
    Kind=bridge
    # /etc/systemd/network/21-br0.network
    [Match]
    Name=br0
    
    [Network]
    Address=192.168.10.30/24
    Gateway=192.168.10.1
    DNS=1.1.1.1
    # /etc/systemd/network/22-enp1s0.network
    [Match]
    Name=enp1s0
    
    [Network]
    Bridge=br0
    systemd-networkd 브리지와 고정 IP 구성을 보여주는 서버 네트워크 설정 이미지

    systemd-networkd에서 파일 기반으로 인터페이스와 브리지를 선언하는 구조를 설명하는 이미지입니다.

    6. ⚠️ 주의사항과 트러블슈팅: 여기서 많이 꼬입니다

    NetworkManager systemd-networkd 비교에서 성능이나 취향보다 더 중요한 건, 둘을 동시에 어설프게 건드리지 않는 겁니다. 제가 제일 많이 본 문제도 이거였어요.

    1) 두 도구가 같은 인터페이스를 같이 관리하는 문제

    한 인터페이스를 두 서비스가 동시에 건드리면 IP가 바뀌거나, 라우팅이 꼬이거나, 부팅 후 상태가 달라질 수 있습니다.

    • 서버에서 networkd를 쓸 거면 해당 인터페이스를 NetworkManager 관리 대상에서 빼는지 확인
    • 데스크톱에서 NetworkManager를 주로 쓸 거면 networkd 설정 파일을 남겨두지 않기

    2) DNS가 적용되지 않는 문제

    IP는 잘 붙는데 이름 해석이 안 되는 경우가 있습니다. 이건 대개 Resolver(리졸버) 경로가 꼬인 겁니다. resolvectl status, cat /etc/resolv.conf를 같이 보셔야 합니다. 특히 배포판 기본 설정이나 설치 도구가 DNS 체인을 이미 잡아둔 경우가 있거든요.

    3) Netplan 같은 상위 설정 도구와의 관계

    일부 배포판은 Netplan(넷플랜, 네트워크 추상화 설정 도구) 같은 레이어가 중간에 있습니다. 이 경우 실제 백엔드는 NetworkManager일 수도 있고 systemd-networkd일 수도 있어요. 겉으로는 YAML만 보이는데, 실제 적용 주체는 다른 셈이죠. 저도 처음엔 설정 파일을 직접 만졌는데 적용이 이상해서 봤더니 상위 도구가 덮어쓰고 있더라고요.

    4) 원격 서버에서 전환 작업할 때

    SSH로 붙어 있는 서버에서 네트워크 관리자 교체 작업은 정말 조심하셔야 합니다. 잘못하면 세션이 바로 끊깁니다. 가능하면 콘솔 접근 수단을 확보하고, 변경 전 현재 라우팅과 IP를 메모해 두세요.

    ip addr
    ip route
    networkctl
    nmcli device status

    💡 팁: 원격 작업이면 먼저 보조 NIC나 관리용 콘솔이 있는지 확인하세요. 이거 하나로 심장 덜 철렁합니다.

    7. 검증과 결과 확인: 설정했다고 끝이 아닙니다

    네트워크는 적용보다 검증이 더 중요합니다. 드디어 됐다! 싶어도 DNS, 게이트웨이, 재부팅 후 유지 여부까지 확인해야 진짜 끝입니다.

    1. 인터페이스에 기대한 IP가 붙었는지 확인
    2. 기본 게이트웨이가 맞는지 확인
    3. DNS 질의가 되는지 확인
    4. 재부팅 후에도 유지되는지 확인
    ip addr show enp1s0
    ip route
    ping -c 4 192.168.10.1
    ping -c 4 1.1.1.1
    getent hosts example.com

    NetworkManager 쪽 확인 명령입니다.

    nmcli device show enp1s0
    nmcli general status

    systemd-networkd 쪽 확인 명령입니다.

    networkctl status enp1s0
    resolvectl status
    NetworkManager systemd-networkd 비교 결과를 검증하는 리눅스 네트워크 상태 이미지

    라우팅, DNS, 인터페이스 상태를 검증하는 결과 화면을 한 장으로 요약한 이미지입니다.

    실제로 써보니까 데스크톱 네트워크는 NetworkManager가 관리 포인트가 적었고, 홈랩 서버는 systemd-networkd가 더 담백했습니다. 특히 재부팅 후에도 상태가 예측 가능하다는 점이 마음에 들었네요. 반대로 Wi-Fi나 VPN을 자주 다루는 장비는 굳이 networkd로 억지 구성할 이유가 없었습니다.

    8. 정리와 FAQ: 최적의 선택은 결국 환경에 따라 다릅니다

    리눅스 네트워크 관리에서 정답은 하나가 아닙니다. 다만 기준은 분명합니다.

    환경 추천 이유
    개인 데스크톱 NetworkManager GUI, Wi-Fi, VPN, 프로파일 전환이 편함
    노트북 NetworkManager 이동성과 연결 변경이 많음
    고정 IP 서버 systemd-networkd 단순하고 예측 가능함
    가상화 호스트/홈랩 systemd-networkd 브리지, VLAN 같은 선언형 구성이 깔끔함
    혼합 환경 상황별 선택 역할에 따라 분리 운영이 현실적임
    NetworkManager systemd-networkd 비교와 추천 환경을 요약한 인포그래픽 이미지

    어떤 환경에 어떤 도구가 더 적합한지 빠르게 판단할 수 있도록 정리한 요약 이미지입니다.

    자주 묻는 질문

    • Q. 서버에도 NetworkManager를 써도 되나요?
      네, 가능합니다. 다만 고정 구성이 중심이고 Wi-Fi나 사용자 세션 연동이 필요 없다면 networkd가 더 단순할 수 있습니다.
    • Q. systemd-networkd가 더 가볍나요?
      일반적으로 더 단순한 구성에 잘 맞습니다. 다만 실제 체감은 기능 요구사항에 따라 달라집니다.
    • Q. 둘 중 하나가 절대적으로 더 좋은가요?
      아닙니다. 데스크톱 네트워크와 서버 네트워크 설정의 요구가 다르기 때문입니다.

    정리하면 이렇습니다. Wi-Fi, VPN, 사용자 친화성 중심이면 NetworkManager, 고정 구성과 선언형 관리 중심이면 systemd-networkd가 잘 맞습니다. 저도 처음엔 무조건 하나로 통일하려고 했었는데, 실제로 운영해보니 역할별로 나누는 게 훨씬 덜 힘들더라고요.

    다음 글에서는 Netplan과 NetworkManager/systemd-networkd의 관계도 따로 다뤄볼 예정입니다. Ubuntu 계열에서 설정이 왜 한 번 더 꼬이는지, 그 부분이 궁금하셨다면 이어서 보시면 도움이 되실 겁니다. 이전 글에서 다룬 홈랩 브리지 구성과 같이 보셔도 흐름이 잘 이어집니다. 🎉

  • [Linux] strace로 리눅스 애플리케이션 장애 진단: 실제 디버깅 사례 분석

    [Linux] strace로 리눅스 애플리케이션 장애 진단: 실제 디버깅 사례 분석

    [리눅스] strace로 리눅스 애플리케이션 장애 진단

    리눅스 서버를 오래 보다 보면, 로그는 멀쩡한데 애플리케이션만 묘하게 멈춰 있는 순간이 꼭 옵니다. 저도 실제 운영 환경과 홈랩에서 이런 상황을 여러 번 겪었고요. 그럴 때 꽤 자주 꺼내는 도구가 바로 strace 리눅스 디버깅입니다. 시스템 콜 추적(System Call Trace, 커널에 요청하는 함수 흐름 추적)을 보면, 애플리케이션이 지금 무엇을 하다가 막혔는지가 생각보다 적나라하게 드러나거든요.

    처음엔 저도 이게 뭔가 싶었어요. 출력은 엄청 많고, 괄호 투성이고, 에러처럼 보이는 줄도 많아서 겁부터 났거든요. 근데 몇 번 삽질하고 나니까 패턴이 보이더라고요. 특히 시스템 콜 추적은 로그가 없는 장애, 시작은 되는데 응답이 없는 문제, 파일 권한 꼬임, DNS 지연, 소켓 연결 실패 같은 상황에서 정말 강력하더라고요.

    이번 글에서는 제가 실제로 자주 쓰는 방식으로 리눅스 장애 해결에 strace를 어떻게 적용하는지, 그리고 애플리케이션 문제 진단을 할 때 어떤 흐름으로 보면 되는지 사례 중심으로 정리해보겠습니다.

    strace 리눅스 디버깅 개요를 보여주는 시스템 콜 추적 다이어그램

    애플리케이션, 커널, 파일 시스템, 네트워크 호출 흐름을 한눈에 보여주는 strace 리눅스 디버깅 개요 이미지입니다.

    1. 왜 strace가 장애 분석에서 강력한가

    쉽게 말해 strace는 애플리케이션이 커널에게 어떤 부탁을 하는지 보여주는 도구예요. 예를 들면 파일을 여는 <code>openat(), 네트워크에 연결하는 connect(), 데이터를 읽는 read(), 잠깐 멈추는 poll() 같은 호출이 보이거든요. 로그는 개발자가 남겨야 보이지만, 시스템 콜은 애플리케이션이 실제로 살아 움직이려면 거의 피할 수가 없거든요.

    여기서 중요한 포인트! 로그가 없다고 해서 단서가 없는 건 아닙니다. 오히려 strace를 보면 로그를 못 남길 정도로 초반에 죽는 문제도 잡히는 경우가 많아요. 제가 직접 해보니 특히 아래 같은 상황에서 체감이 컸습니다.

    • 프로세스는 살아 있는데 응답이 없음
    • 시작 직후 바로 종료됨
    • 특정 파일이나 소켓 접근에서 실패함
    • DNS 조회나 외부 API 연결에서 지연됨
    • 권한(Permission) 문제인데 로그가 부실함

    2. strace 핵심 개념 쉽게 이해하기

    저도 처음엔 옵션이 너무 많아서 헷갈렸는데, 실무에서 자주 보는 개념은 몇 개 안 돼요.

    2-1. attach와 exec의 차이

    • attach: 이미 실행 중인 프로세스에 붙어서 봅니다. -p PID를 씁니다.
    • exec: 프로그램 실행부터 추적합니다. 서비스가 시작하면서 죽는 문제에 좋아요.

    2-2. 자주 보는 시스템 콜

    • openat(): 파일 열기
    • read() / write(): 데이터 읽기/쓰기
    • connect(): TCP/UDP/Unix Socket 연결
    • stat() 계열: 파일 존재 여부, 메타데이터 확인
    • futex(): 스레드 동기화 대기
    • poll() / select() / epoll_wait(): 이벤트 대기

    2-3. 어떤 도구와 비교하면 좋을까

    도구 주요 용도 강점 주의점
    strace 시스템 콜 추적 파일, 네트워크, 권한 문제를 빠르게 확인 출력이 많아 필터링이 필요
    ltrace 라이브러리 호출 추적 유저 공간 함수 흐름 확인 환경에 따라 활용 범위가 제한적
    journalctl 서비스 로그 확인 systemd 서비스 분석에 편함 로그가 없으면 한계가 명확

    제 경험상 순서는 보통 이래요. 로그 먼저 보고, 안 나오면 ss, lsof, strace로 들어갑니다. 즉, strace는 마지막 수단이라기보다 애매할 때 바로 꺼내는 실전 도구에 가까워요.

    3. strace 기본 사용법: 이 정도만 알아도 바로 써먹습니다

    실전에서 가장 많이 쓰는 명령어부터 보겠습니다.

    1. 실행 중인 프로세스에 붙기
    2. 새로 실행되는 프로그램 추적하기
    3. 출력을 파일로 저장하기
    4. 파일/네트워크 관련 시스템 콜만 필터링하기
    # 실행 중인 PID에 붙기
    strace -p 1234
    
    # 자식 프로세스까지 함께 추적
    strace -f -p 1234
    
    # 실행부터 추적
    strace -f ./app
    
    # 타임스탬프와 소요 시간 보기
    strace -tt -T -f -p 1234
    
    # 결과를 파일로 저장
    strace -f -tt -T -o /tmp/strace.log -p 1234
    
    # 파일/네트워크 관련 호출만 보기
    strace -f -e trace=file,network -p 1234
    

    여기서 -f는 정말 자주 써요. 요즘 애플리케이션은 멀티프로세스나 워커(worker, 작업 프로세스) 구조가 많아서 부모만 보면 핵심이 안 보일 때가 많거든요.

    또 하나 팁을 드리면, 처음부터 모든 걸 보려고 하지 마세요. 출력이 너무 많아요 ㅎㅎ 저는 보통 file, network, process 정도부터 좁혀서 봐요.

    strace 리눅스 디버깅 명령 옵션과 추적 흐름을 설명하는 이미지

    PID attach, 자식 프로세스 추적, 파일 출력, trace 필터링 같은 핵심 옵션을 설명하는 터미널 구성 이미지입니다.

    4. 실제 디버깅 사례 분석: 로그는 멀쩡한데 서비스가 시작되지 않던 문제

    이제 실전 얘기를 해보겠습니다. 예전에 제가 홈랩에서 돌리던 간단한 Python 웹 애플리케이션이 있었는데, systemd로 서비스는 올라온 것처럼 보이는데 정작 포트에서 응답이 없었어요. 로그도 거의 안 찍히더라고요. 처음엔 애플리케이션 버그인 줄 알았는데, strace로 보니까 전혀 다른 문제였습니다.

    4-1. 증상 확인

    systemctl status myapp
    ss -lntp | grep 8000
    journalctl -u myapp -n 50 --no-pager
    

    결과를 보면 서비스 프로세스는 잠깐 떴다가 다시 죽는 식이었어요. 포트 바인딩(bind, 포트 점유)도 안 됐고요. journalctl에는 결정적인 힌트가 없었습니다. 여기서 strace를 붙였어요.

    4-2. 실행부터 추적

    strace -f -tt -T -o /tmp/myapp.strace /usr/bin/python3 /opt/myapp/app.py
    

    로그 파일이 만들어졌으면, 그다음엔 실패 패턴부터 찾아요. 제가 자주 쓰는 방법은 ENOENT, EACCES, ECONNREFUSED 같은 에러 코드를 먼저 찾는 거예요.

    grep -E 'ENOENT|EACCES|ECONNREFUSED|ETIMEDOUT' /tmp/myapp.strace
    

    그때 보였던 핵심 패턴은 이런 형태였습니다.

    openat(AT_FDCWD, "/opt/myapp/config/settings.yml", O_RDONLY) = -1 ENOENT (No such file or directory)
    write(2, "failed to load config\n", 22) = 22
    exit_group(1) = ?
    

    처음엔 진짜 허무했어요. 코드 문제인 줄 알았는데, 실제로는 설정 파일 경로 오타였던 거더라고요. 애플리케이션 로그 레벨이 낮아서 stderr 출력이 서비스 로그에 제대로 안 남던 상황이었고요. 애플리케이션 문제 진단이라고 생각했는데, 실상은 배포 경로 불일치였습니다.

    이런 경험 있으신가요? 분명히 코드 바꾼 건 없는데 배포 후에만 죽는 경우요. 이런 건 strace가 정말 빨리 답을 주더라고요.

    4-3. 문제 수정

    ls -l /opt/myapp/config/
    mkdir -p /opt/myapp/config
    cp /opt/myapp/deploy/settings.yml /opt/myapp/config/settings.yml
    systemctl restart myapp
    

    설정 파일을 맞는 위치에 두고 다시 실행하니 바로 정상 동작했어요. 드디어 됐다! 이런 케이스는 코드 디버거보다 strace가 훨씬 빠르더라고요.

    5. 네트워크 지연 분석에도 strace가 꽤 유용합니다

    strace는 파일만 보는 도구가 아니에요. 네트워크 지연도 흐름을 잡는 데 도움 돼요. 예를 들면 외부 API 호출 전 단계에서 connect()가 오래 걸리는지, DNS 조회 과정에서 대기하는지, Unix Socket 연결이 실패하는지 확인할 수 있습니다.

    strace -f -tt -T -e trace=network -p 1234
    

    예를 들어 출력이 아래처럼 보인다면, 연결 자체에서 문제가 나는 거예요.

    connect(7, {sa_family=AF_UNIX, sun_path="/run/myapp/backend.sock"}, 25) = -1 ENOENT (No such file or directory)
    connect(7, {sa_family=AF_INET, sin_port=htons(443), sin_addr=...}, 16) = -1 ECONNREFUSED (Connection refused)
    

    반대로 poll()이나 epoll_wait()에서 오래 머무는 건, 꼭 장애라고 단정하면 안 돼요. 정상적으로 요청을 기다리는 상태일 수도 있거든요. 그래서 저는 항상 이 호출이 비정상적인 막힘인지, 원래 대기 상태인지를 같이 봅니다.

    strace 리눅스 디버깅으로 파일 누락과 소켓 오류를 분석하는 예시 이미지

    ENOENT, EACCES, ECONNREFUSED 같은 대표 장애 패턴을 strace 출력으로 해석하는 예시 이미지입니다.

    6. ⚠️ 주의사항과 트러블슈팅: strace가 만능은 아닙니다

    여기서 많이들 헷갈리는 포인트가 있어요. 저도 처음엔 그랬고요.

    6-1. futex()가 보인다고 무조건 데드락은 아닙니다

    멀티스레드 프로그램을 보면 futex()가 엄청 자주 나와요. 이걸 보고 바로 데드락(deadlock, 상호 대기)이라고 판단하면 위험해요. 정상적인 스레드 대기일 수도 있거든요. 이럴 땐 CPU 사용률, 스레드 덤프, 애플리케이션 구조를 같이 봐야 합니다.

    6-2. 성능 오버헤드가 있습니다

    strace는 추적 도구라서 당연히 부하가 있어요. 운영 서버에 장시간 전체 추적은 조심해야 합니다. 특히 트래픽이 높은 프로세스는 출력량도 많고, 체감 성능에 영향이 생길 수 있습니다.

    • 짧게 붙어서 패턴만 확인하기
    • -e trace=...로 범위 줄이기
    • -o로 파일 저장 후 오프라인 분석하기

    6-3. 권한 문제로 attach가 안 될 수 있습니다

    strace: attach: ptrace(PTRACE_SEIZE, 1234): Operation not permitted
    

    이 경우엔 보통 권한이나 보안 설정을 확인해야 해요. 컨테이너나 보안 정책이 걸린 환경에서는 ptrace 자체가 제한될 수 있거든요. 저도 컨테이너 환경에서 왜 안 붙나 한참 봤던 적이 있어요. 삽질 좀 했습니다 ㅎㅎ

    6-4. 너무 많은 출력은 오히려 독입니다

    무작정 전체 로그를 보면 눈이 먼저 지쳐요. 그래서 저는 아래 순서로 봅니다.

    1. 에러 코드부터 검색합니다
    2. 마지막 수십 줄 흐름을 봅니다
    3. 반복되는 패턴이 있는지 확인합니다
    4. 파일, 네트워크, 프로세스 관련 호출로 좁힙니다

    7. 검증: 수정 후 무엇을 확인해야 하나

    장애 원인을 찾았다고 끝은 아니에요. 수정 후에는 반드시 재현 경로와 정상 동작을 같이 확인해야 합니다. 제가 보통 체크하는 항목은 아래와 같습니다.

    1. 서비스 프로세스가 바로 종료되지 않는지 확인
    2. 포트가 정상적으로 리슨(listen, 대기) 상태인지 확인
    3. 에러가 발생하던 요청이 정상 응답하는지 확인
    4. strace에서 보이던 실패 패턴이 사라졌는지 확인
    systemctl restart myapp
    systemctl status myapp --no-pager
    ss -lntp | grep 8000
    curl -I http://127.0.0.1:8000/
    

    필요하면 다시 짧게 추적해서 차이를 봐요.

    strace -f -tt -T -e trace=file,network -o /tmp/after_fix.strace -p 1234
    

    수정 전에는 ENOENT가 보였는데, 수정 후에는 해당 파일을 정상적으로 openat() 하는 흐름이 보이면 꽤 확신을 가질 수 있어요. 이런 식으로 리눅스 장애 해결은 추정이 아니라 근거로 밀어붙여야 나중에 덜 흔들립니다.

    strace 리눅스 디버깅 결과를 수정 전후로 비교하는 검증 이미지

    에러 코드가 사라지고 포트 리슨 및 HTTP 응답이 복구된 결과를 비교하는 검증 이미지입니다.

    8. 자주 묻는 질문 정리

    Q1. strace 리눅스 디버깅은 언제 가장 먼저 써야 할까요?

    로그가 비어 있거나, 시작 직후 종료되거나, 파일/권한/소켓 문제로 의심될 때 바로 써볼 만해요. 특히 시스템 콜 추적이 필요한 상황은 애플리케이션 외부 의존성이 꼬였을 때예요.

    Q2. 운영 서버에서도 써도 될까요?

    짧고 제한적으로는 가능해요. 다만 전체 추적을 오래 거는 건 조심하셔야 합니다. 필터링이 정말 중요합니다.

    Q3. strace만으로 모든 문제가 해결되나요?

    아니에요. CPU 바운드 문제, 메모리 누수, 애플리케이션 내부 로직 버그는 다른 도구와 함께 봐야 합니다. strace는 커널 경계에서 보이는 행동을 잘 보여주는 도구니까요.

    9. 마무리: strace는 로그가 말해주지 않는 걸 보여줍니다

    정리해보면, strace는 화려한 도구는 아니에요. 근데 장애 순간에 진짜 실용적이더라고요. 제가 직접 써보니 특히 파일 경로 오류, 권한 문제, 소켓 연결 실패, 시작 직후 종료 같은 문제에서는 체감상 가장 빠르게 본질에 닿는 도구였어요.

    혹시 지금도 프로세스는 떠 있는데 왜 안 되는지 감이 안 오신다면, 너무 복잡하게 가지 말고 짧게 strace 한 번 붙여보세요. 의외로 답은 이미 시스템 콜에 나와 있는 경우가 많아요. 이거 진짜 편하더라고요.

    다음 글에서는 lsof로 열린 파일과 소켓 추적하는 방법, 그리고 이전 글에서 다뤘던 systemd 서비스 로그 읽는 법과 어떻게 조합하면 좋은지도 이어서 정리해보겠습니다.

    strace 사용 시점, 자주 보는 에러 코드, 검증 절차를 요약한 인포그래픽 이미지입니다.