13년차의 서버실

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

[작성자:] admin

  • [Game] 클라우드 게임 서비스 비교: GeForce NOW vs Xbox Cloud Gaming 장단점 분석

    고사양 PC 없어도 AAA 게임을? 클라우드 게임 서비스 비교 시작합니다

    얼마 전에 조카가 저한테 물어보더라고요. “삼촌, 제 노트북으로 사이버펑크 2077 돌릴 수 있어요?” 사양을 보니까 인텔 내장 그래픽에 램 8GB짜리였습니다. 저도 솔직히 말해줬죠. “그 노트북으로는 힘들어.” 근데 바로 이어서 얘기했어요. “대신 클라우드 게임 서비스 한번 써봐.”

    인프라 엔지니어로 13년 일하다 보니까 클라우드 컴퓨팅 자체는 너무 익숙한데, 이걸 게임에 붙여놓은 서비스들은 처음엔 좀 낯설었거든요. 근데 직접 써보니까 “아, 이거 진짜 되네?” 싶더라고요. 오늘은 현재 가장 많이 쓰이는 두 서비스, GeForce NOW와 Xbox Cloud Gaming(엑스박스 클라우드 게이밍)을 제가 직접 써본 경험 바탕으로 비교해 드릴게요.

    GeForce NOW와 Xbox Cloud Gaming의 서비스 구조와 특징을 한눈에 비교한 개요 다이어그램


    클라우드 게임(Cloud Gaming)이 뭔지 먼저 짚고 갑시다

    쉽게 말해서, 게임을 내 기기에서 돌리는 게 아니라 원격 서버에서 돌리고 그 화면을 스트리밍으로 받아보는 방식이에요. 넷플릭스로 영화 보듯이, 게임도 스트리밍으로 플레이하는 거죠.

    기술적으로 보면 이렇습니다:

    • 렌더링(Rendering, 화면 처리): 서버 측 GPU가 담당
    • 인풋(Input, 조작 입력): 내 기기에서 서버로 전송
    • 출력: 서버가 처리한 화면을 영상 스트림으로 내 화면에 전달

    그래서 내 기기 성능은 크게 중요하지 않아요. 대신 네트워크 지연(Latency, 레이턴시)이 핵심 변수가 됩니다. 이 부분은 나중에 더 얘기할게요.


    GeForce NOW — 내가 산 게임을 클라우드에서 돌린다

    GeForce NOW 기본 개념

    엔비디아(NVIDIA)가 운영하는 클라우드 게임 서비스입니다. 핵심 컨셉이 독특해요. 게임을 새로 사는 게 아니라, 내가 이미 갖고 있는 게임을 클라우드에서 실행하는 방식이거든요. Steam(스팀), Epic Games Store(에픽게임즈 스토어), Ubisoft Connect(유비소프트 커넥트) 같은 플랫폼에서 이미 구매한 게임을 GeForce NOW 서버에서 돌릴 수 있어요.

    처음 이 개념 들었을 때 저도 “어? 그럼 내 게임 라이브러리를 그대로 쓸 수 있다는 거야?” 싶었는데, 맞습니다. 다만 모든 게임이 지원되는 건 아니에요. 게임 퍼블리셔(Publisher, 게임 배급사)가 GeForce NOW 서비스 제공에 동의해야 하거든요. 지원 게임 목록은 계속 업데이트되고 있어요.

    GeForce NOW 요금제 구조

    제가 확인한 요금제 구조는 크게 세 가지 티어(Tier, 등급)입니다:

    • Free(무료) 티어: 세션(Session, 게임 접속 시간) 제한 있음, 대기열 존재, 기본 화질
    • Priority(프라이어리티, 우선순위) 티어: 유료, 대기열 없음, 1080p/60fps 지원
    • Ultimate(얼티밋) 티어: 유료, RTX 4080 수준 GPU 사용, 4K/120fps 지원, DLSS(딥러닝 슈퍼 샘플링) 활용

    💡 팁: 처음 써보시는 분들은 무료 티어로 먼저 테스트해보세요. 세션 시간 제한이 있긴 한데, 내 환경에서 체감 품질이 어떤지 확인하기엔 충분합니다.

    GeForce NOW 장점

    • ✅ 기존 게임 라이브러리 활용 가능 (Steam, Epic 등)
    • ✅ 무료 티어 존재 — 진입 장벽이 낮음
    • ✅ PC 게임 생태계 그대로 이용 (키보드/마우스 지원)
    • ✅ NVIDIA RTX 기술 (레이트레이싱, DLSS) 활용 가능
    • ✅ 다양한 기기 지원 (Windows, Mac, Android, Chromebook 등)

    GeForce NOW 단점

    • ⚠️ 지원하지 않는 게임이 꽤 있음 — 퍼블리셔 동의 필요
    • ⚠️ 무료 티어는 세션 시간 제한 및 대기열 존재
    • ⚠️ 게임 자체는 별도 구매 필요 (서비스 요금 외 추가 비용)
    • ⚠️ 서버 위치에 따라 레이턴시 차이 존재

    Xbox Cloud Gaming — 구독 하나로 수백 개 게임을

    Xbox Cloud Gaming 기본 개념

    마이크로소프트(Microsoft)가 Xbox Game Pass Ultimate(엑스박스 게임 패스 얼티밋) 구독에 포함해서 제공하는 클라우드 게임 서비스예요. 이전 이름이 Project xCloud(프로젝트 엑스클라우드)였는데, 지금은 Xbox Cloud Gaming으로 통합됐죠.

    컨셉이 GeForce NOW랑 완전히 달라요. 게임을 따로 살 필요 없이, Xbox Game Pass 라이브러리에 있는 게임들을 클라우드로 바로 플레이하는 방식입니다. 구독료 하나로 수백 개 타이틀에 접근할 수 있어요. 저도 처음 써봤을 때 “이거 넷플릭스 게임 버전이네” 싶었거든요.

    마이크로소프트 Azure(애저) 클라우드 인프라를 기반으로 하고, 서버는 Xbox Series X 하드웨어를 사용한다고 알려져 있어요. 인프라 엔지니어 입장에서 보면 꽤 흥미로운 아키텍처(Architecture, 시스템 구조)입니다.

    Xbox Cloud Gaming 지원 기기

    브라우저 기반으로 동작하는 게 큰 장점이에요. 별도 앱 설치 없이도 쓸 수 있거든요:

    • Android 기기 (앱 지원)
    • iOS/iPadOS (Safari 브라우저 지원)
    • Windows PC (앱 및 브라우저)
    • Samsung 스마트TV 일부 모델 (앱 지원)
    • Xbox 콘솔 (물론 지원)

    근데 여기서 중요한 포인트! 컨트롤러(Controller, 게임 패드) 사용이 기본으로 권장됩니다. 키보드/마우스 지원이 되긴 하지만, 인터페이스 자체가 컨트롤러 중심으로 설계돼 있어요.

    Xbox Cloud Gaming의 다양한 기기 지원 현황과 실제 플레이 인터페이스 구성

    Xbox Cloud Gaming 장점

    • ✅ Game Pass 구독 하나로 수백 개 게임 이용 가능
    • ✅ 추가 게임 구매 불필요
    • ✅ 브라우저에서 바로 실행 가능
    • ✅ 모바일 플레이에 최적화
    • ✅ Microsoft 퍼스트파티(First-party, 자체 개발) 타이틀 출시 즉시 포함
    • ✅ Azure 글로벌 인프라로 서버 커버리지 넓음

    Xbox Cloud Gaming 단점

    • ⚠️ Game Pass 구독료가 필수 (별도 무료 플랜 없음)
    • ⚠️ 컨트롤러 없으면 조작감이 아쉬운 경우 있음
    • ⚠️ PC 게임 라이브러리(Steam 등) 연동 없음
    • ⚠️ 해상도/프레임레이트(Frame Rate, 초당 프레임 수)가 GeForce NOW 상위 티어 대비 낮을 수 있음

    직접 써보니까 — 실전 체감 비교

    레이턴시(Latency, 입력 지연)가 제일 중요합니다

    클라우드 게임에서 가장 민감한 부분이에요. 제가 홈랩에서 다양한 네트워크 환경을 테스트해봤는데, 유선 인터넷 환경에서 두 서비스 모두 체감 레이턴시가 상당히 양호했어요. 반면 Wi-Fi(와이파이) 환경, 특히 5GHz가 아닌 2.4GHz 대역에서는 좀 더 눈에 띄는 지연이 느껴지더라고요.

    FPS(First Person Shooter, 1인칭 슈팅 게임)나 격투 게임처럼 반응속도가 중요한 장르는 솔직히 클라우드 게임이 로컬 PC보다 불리한 건 사실이에요. 근데 RPG(Role Playing Game, 역할 수행 게임)나 어드벤처, 전략 게임 류는 충분히 즐길 만한 수준이었습니다.

    화질 비교

    GeForce NOW Ultimate 티어를 써보면 확실히 화질이 인상적이에요. DLSS 기술 덕분에 고해상도 출력이 가능하고, RTX 레이트레이싱(Ray Tracing, 광선 추적 기술)도 지원되거든요. 반면 Xbox Cloud Gaming은 현재 최대 1080p/60fps 수준으로, 고사양 게이밍 모니터의 장점을 100% 살리긴 어렵습니다.

    근데 솔직히 말하면, 일반 FHD 모니터나 TV에서 플레이한다면 Xbox Cloud Gaming도 충분히 좋은 화질이에요. “이게 클라우드야?” 싶을 정도로 자연스럽더라고요.

    GeForce NOW와 Xbox Cloud Gaming의 해상도, 프레임레이트, 레이턴시 실측 비교 결과

    게임 라이브러리 접근 방식 차이

    이게 두 서비스의 가장 큰 철학적 차이예요:

    구분 GeForce NOW Xbox Cloud Gaming
    게임 소유 내가 구매한 게임 사용 Game Pass 구독 라이브러리
    추가 구매 게임별 별도 구매 필요 구독 내 게임은 추가 비용 없음
    게임 수 지원 게임 목록에 따라 다름 수백 개 타이틀 (Game Pass 기준)
    플랫폼 연동 Steam, Epic 등 PC 플랫폼 Xbox/Microsoft Store 중심
    신규 AAA 타이틀 퍼블리셔 동의 후 지원 MS 퍼스트파티는 출시 즉시

    ⚠️ 주의사항 — 이런 분들은 실망할 수 있어요

    클라우드 게임 서비스 공통 주의사항

    제가 처음 쓸 때 몰랐다가 나중에 알게 된 것들이에요. 미리 알고 시작하시면 좋겠습니다:

    1. 인터넷 속도보다 안정성이 더 중요: 1Gbps 속도라도 패킷 손실(Packet Loss)이 있으면 화면이 깨져요. 안정적인 유선 연결이 최우선입니다.
    2. 데이터 사용량이 상당합니다: 1080p 스트리밍 기준으로 시간당 수 GB 수준의 데이터를 쓰거든요. 데이터 캡(Data Cap, 사용량 제한)이 있는 요금제라면 주의하세요.
    3. 세이브 데이터(Save Data, 저장 데이터) 관리: GeForce NOW는 세션 종료 후 클라우드 세이브가 지원되는 게임의 경우 해당 플랫폼(Steam 등)의 클라우드 저장을 활용합니다. Xbox Cloud Gaming은 Xbox 계정에 저장되고요. 게임마다 다를 수 있으니 확인이 필요해요.
    4. 서버 점검 및 가용성: 클라우드 서비스다 보니 서버 점검 시간에는 플레이가 안 됩니다. 오프라인 플레이가 필요한 환경이라면 클라우드 게임은 맞지 않아요.

    어떤 서비스가 나한테 맞을까? — 추천 기준 정리

    “그래서 뭘 써야 해요?” 라고 물어보시면, 저는 이렇게 대답해요. 상황에 따라 달라요. 진부하게 들리겠지만 진짜 그렇거든요 ㅎㅎ

    GeForce NOW를 추천하는 경우

    • 이미 Steam이나 Epic에 게임 라이브러리가 있는 분
    • PC 게임을 키보드/마우스로 즐기는 분
    • 무료로 먼저 테스트해보고 싶은 분
    • 고화질(4K, 레이트레이싱)이 중요한 분
    • Mac 사용자 (맥에서 고사양 게임을 즐기고 싶을 때)

    Xbox Cloud Gaming을 추천하는 경우

    • Game Pass 구독을 이미 하고 있거나 할 예정인 분
    • 모바일(스마트폰, 태블릿)에서 주로 게임하는 분
    • 컨트롤러 게임을 선호하는 분
    • Xbox 퍼스트파티 타이틀(헤일로, 포르자, 스타필드 등)을 즐기는 분
    • TV에서 게임하고 싶은데 콘솔 없는 분

    GeForce NOW와 Xbox Cloud Gaming 클라우드 게임 서비스 비교 최종 요약 인포그래픽

    클라우드 게임 서비스 비교 핵심 요약표

    항목 GeForce NOW Xbox Cloud Gaming
    운영사 NVIDIA Microsoft
    무료 플랜 있음 (세션 제한) 없음 (Game Pass 필요)
    게임 제공 방식 내 게임 라이브러리 활용 구독 포함 게임 이용
    최대 화질 4K/120fps (Ultimate) 1080p/60fps
    PC 플랫폼 연동 Steam, Epic, Ubisoft 등 Microsoft Store/Xbox
    모바일 최적화 보통 우수
    브라우저 지원 제한적 우수
    컨트롤러 필수 여부 아님 (KBM 지원) 권장

    마무리 — 클라우드 게임, 이제 진짜 쓸 만합니다

    솔직히 몇 년 전까지만 해도 저도 클라우드 게임에 회의적이었어요. “레이턴시 때문에 게임이 되겠어?” 싶었거든요. 근데 인터넷 인프라가 좋아지고, 서버도 더 가까이 배치되면서 이제는 진짜 쓸 만한 수준이 됐더라고요. 특히 RPG나 어드벤처 장르라면 체감 차이가 거의 없을 정도예요.

    결론적으로 클라우드 게임 서비스 비교를 해보면 이렇습니다:

    • 🎉 기존 PC 게임 유저라면 → GeForce NOW부터 무료로 시작해보세요
    • 🎉 구독형으로 다양한 게임을 즐기고 싶다면 → Xbox Cloud Gaming이 가성비가 좋아요

    저는 개인적으로 둘 다 상황에 따라 쓰고 있어요. 홈랩 서버 모니터링하면서 한 손으로 게임하는 게 이제 일상이 됐습니다 ㅎㅎ 조카한테도 Xbox Cloud Gaming 추천해줬는데 잘 쓰고 있더라고요.

    다음에는 모바일 클라우드 게임 세팅 최적화나 홈 네트워크 레이턴시 줄이는 방법도 다뤄볼 예정이에요. 클라우드 게임 경험을 더 좋게 만드는 네트워크 튜닝 팁도 있거든요. 기대해 주세요!


    자주 묻는 질문 (FAQ)

    Q. GeForce NOW는 정말 무료로 쓸 수 있나요?

    네, 무료 티어가 존재합니다. 다만 세션 시간 제한(1시간 내외)이 있고, 피크 타임에는 대기열이 생길 수 있어요. 체험용으로는 충분하지만 장시간 플레이라면 유료 플랜이 필요합니다.

    Q. Xbox Cloud Gaming은 Xbox 콘솔이 없어도 되나요?

    네, 전혀 없어도 됩니다. Xbox Game Pass Ultimate 구독만 있으면 PC, 모바일, 브라우저에서 바로 플레이할 수 있어요.

    Q. 클라우드 게임에 필요한 최소 인터넷 속도는?

    두 서비스 모두 최소 10Mbps 이상을 권장하고, 1080p 품질로 즐기려면 20~35Mbps 이상이 권장됩니다. 속도보다 안정성(패킷 손실, 지터)이 더 중요해요.

    Q. 두 서비스를 동시에 구독해서 쓰는 게 의미 있나요?

    충분히 의미 있어요. Xbox Game Pass로 다양한 타이틀을 즐기면서, Steam에서 구매한 특정 게임은 GeForce NOW로 고화질 플레이하는 식으로 병행하는 분들도 많습니다.

  • [NAS] Synology NAS 데이터 복구: 실수 삭제부터 RAID 재구성까지 완벽 가이드

    [NAS] Synology NAS 데이터 복구: 실수 삭제부터 RAID 재구성까지 완벽 가이드

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 많은 분들이 한 번쯤은 겪어봤을 법한, 혹은 겪을까 봐 노심초사하는 주제를 들고 왔습니다. 바로 Synology NAS 데이터 복구에 대한 이야기인데요. 소중한 사진, 업무 자료, 영상 파일들이 담긴 NAS에서 갑자기 데이터가 사라지거나, 디스크에 문제가 생기면 정말 심장이 철렁 내려앉는 기분이죠. 저도 홈랩에서 Synology NAS를 운영하면서 크고 작은 데이터 손실 상황을 겪어봤고, 그때마다 ‘아, 이건 정말 미리 알아두면 좋을 텐데!’ 하는 생각이 들더라고요.

    이번 글에서는 제가 직접 겪었던 경험과 삽질을 바탕으로, 실수로 파일을 삭제했을 때부터 RAID 어레이에 문제가 생겼을 때까지, Synology NAS 데이터를 복구하는 완벽 가이드를 알려드리려고 합니다. 혹시 지금 당장 데이터 손실 문제로 머리가 아프시다면, 이 글이 조금이나마 도움이 되기를 바랍니다. 함께 여러분의 소중한 데이터를 지켜봅시다!

    Synology NAS는 다양한 방법으로 데이터를 보호하고 복구할 수 있는 기능을 제공합니다.

    Synology NAS 데이터 복구: 핵심 개념 이해하기

    본격적인 복구 방법에 들어가기 전에, Synology NAS가 데이터를 어떻게 보호하고, 어떤 방식으로 복구할 수 있는지 그 핵심 개념들을 먼저 짚고 넘어갈게요. 이걸 알아야 나중에 어떤 복구 방법을 선택해야 할지 명확해지거든요.

    1. 휴지통 (Recycle Bin)은 만능이 아닙니다!

    Windows나 macOS처럼 Synology NAS에도 ‘휴지통’ 기능이 있습니다. 파일을 삭제해도 바로 영구 삭제되지 않고 휴지통으로 이동해서 일정 기간 보관하죠. 하지만 이 휴지통은 모든 공유 폴더에 기본적으로 활성화되어 있지 않다는 사실! 저도 처음엔 이걸 모르고 ‘당연히 휴지통에 있겠지?’ 했다가 식겁한 적이 있습니다. 💡

    2. 스냅샷 (Snapshot)은 데이터 타임머신입니다.

    스냅샷(Snapshot)은 특정 시점의 데이터 상태를 기록해두는 기능입니다. 쉽게 말해, 잃어버린 데이터를 과거의 특정 시점으로 되돌릴 수 있는 ‘타임머신’ 같은 거죠. 파일이 랜섬웨어에 감염되거나, 실수로 대량의 데이터를 변경했을 때 정말 유용합니다. Synology의 Snapshot Replication (스냅샷 복제) 패키지가 이 기능을 담당합니다.

    3. RAID (Redundant Array of Independent Disks)는 데이터 보호의 기본

    RAID는 여러 개의 하드 디스크를 하나처럼 묶어서 사용하는 기술로, 디스크 하나가 고장 나더라도 데이터를 보호하는 데 목적이 있습니다. Synology NAS는 RAID 1, RAID 5, RAID 6, 그리고 Synology만의 독자적인 SHR (Synology Hybrid RAID) 등 다양한 RAID 구성을 지원해요. RAID가 깨지면 데이터 손실 위험이 커지니, 주기적인 상태 확인이 필수입니다.

    실전! 시나리오별 Synology NAS 데이터 복구 방법

    이제 실제 상황을 가정하고 어떻게 데이터를 복구하는지 단계별로 알아볼게요.

    시나리오 1: 실수로 파일을 삭제했어요! (휴지통 복구)

    가장 흔한 경우죠. 저도 모르게 Shift + Del을 누른 것마냥 파일을 영구 삭제했을 때의 악몽… 하지만 휴지통이 활성화되어 있다면 걱정 마세요!

    1. 휴지통 설정 확인 및 활성화

      먼저, 해당 공유 폴더에 휴지통이 활성화되어 있는지 확인해야 합니다. 제어판 > 공유 폴더로 이동해서 복구하고 싶은 공유 폴더를 선택하고 편집을 누르세요. 휴지통 활성화 옵션이 체크되어 있는지 확인하고, 필요하다면 관리자만 접근 가능 옵션도 설정해두는 게 좋습니다. 저도 처음엔 이 설정을 간과했다가 한 번 크게 데인 적이 있거든요. ⚠️

    2. 휴지통에서 파일 복구

      파일 스테이션(File Station)을 열고, 해당 공유 폴더 안에 있는 #recycle 폴더로 이동합니다. 여기에 삭제된 파일들이 보관되어 있을 거예요. 복구하고 싶은 파일을 선택하고 마우스 오른쪽 버튼을 눌러 복원을 클릭하면 원래 위치로 되돌릴 수 있습니다. 🎉 드디어 됐다!

      # Synology DSM에 SSH로 접속하여 휴지통 내용 확인 (예시)
      # sudo ls -al /volume1/YourSharedFolder/#recycle
      

    시나리오 2: 특정 시점으로 되돌리고 싶어요! (스냅샷 복구)

    랜섬웨어 공격을 받거나, 실수로 중요한 폴더 전체를 날려버렸을 때 스냅샷은 정말 생명의 동아줄입니다. 스냅샷은 백업과는 다르지만, 특정 시점 복원에 특화된 강력한 도구입니다.

    1. Snapshot Replication 패키지 설치 및 설정

      패키지 센터에서 Snapshot Replication을 설치하고, 보호하고 싶은 공유 폴더나 iSCSI LUN에 대한 스냅샷 작업을 생성하면 됩니다. 저의 홈랩에서는 매일 밤 12시에 스냅샷을 찍도록 설정해두었더니 정말 든든하더라고요. 💡

    2. 스냅샷에서 파일/폴더 복원

      Snapshot Replication 앱을 실행하고, 복원 탭으로 이동합니다. 복구하고 싶은 공유 폴더를 선택한 후, 원하는 스냅샷 버전을 선택하세요. 파일 스테이션과 유사한 인터페이스로 과거 시점의 폴더 내용을 탐색할 수 있습니다. 특정 파일이나 폴더만 선택해서 복원하거나, 전체 공유 폴더 복원을 통해 통째로 과거 시점으로 되돌릴 수도 있습니다. ⚠️ 전체 공유 폴더 복원 시에는 현재 데이터가 덮어쓰기 되므로 신중해야 합니다.

    Snapshot Replication 설정 화면에서 스냅샷 주기와 보존 정책을 꼼꼼하게 설정하는 것이 중요합니다.

    시나리오 3: RAID 어레이가 손상되었어요! (디스크 교체 및 재구성)

    RAID는 디스크 하나가 고장 나더라도 데이터를 보호해주지만, 고장 난 디스크를 제때 교체하지 않으면 추가 디스크 고장으로 이어져 데이터 손실로 이어질 수 있습니다. 저도 디스크 불량 경고를 무시했다가 간담이 서늘했던 적이 있네요.

    1. RAID 상태 확인

      저장소 관리자 앱을 실행하여 HDD/SSD 탭과 저장소 풀 탭을 확인합니다. 고장 난 디스크가 있다면 상태가 경고나 손상됨으로 표시될 거예요. 어떤 디스크가 문제인지 정확히 확인해야 합니다.

    2. 고장 난 디스크 교체

      Synology NAS 전원을 끄고(핫스왑이 지원되는 모델은 전원을 켜둔 채로 가능) 고장 난 디스크를 빼냅니다. 그리고 새 디스크를 장착하세요. 반드시 기존 디스크와 동일하거나 더 큰 용량의 디스크를 사용해야 합니다.

    3. RAID 재구성 (Repair)

      새 디스크를 장착한 후 Synology NAS 전원을 켜고, 다시 저장소 관리자 > 저장소 풀로 이동합니다. 손상된 저장소 풀을 선택한 후 동작 > 복구를 클릭합니다. 새로 장착한 디스크를 선택하고 복구 과정을 시작하면 됩니다. RAID 재구성에는 시간이 꽤 오래 걸리니 인내심을 가지고 기다려야 합니다. 저도 이때 ‘이게 맞나?’ 싶어서 조마조마했던 기억이 나네요 ㅎㅎ. 복구가 완료되면 저장소 풀 상태가 정상으로 돌아올 거예요. ✅

    # SSH로 디스크 상태 확인 (예시)
    # sudo smartctl -a /dev/sda  # 각 디스크별 SMART 정보 확인
    # cat /proc/mdstat           # RAID 어레이 상태 확인
    

    ⚠️ 주의사항 및 트러블슈팅: 제가 겪었던 삽질 팁

    데이터 복구 과정에서 몇 가지 주의할 점과 제가 겪었던 문제 해결 팁을 공유해 드릴게요.

    • 백업은 아무리 강조해도 지나치지 않습니다! (Hyper Backup)

      휴지통, 스냅샷, RAID 모두 데이터 보호를 위한 좋은 기능이지만, 진정한 의미의 데이터 손실 방지는 ‘백업’에서 시작됩니다. Synology의 Hyper Backup (하이퍼 백업) 패키지를 이용해서 외부 USB 드라이브, 다른 NAS, 클라우드 스토리지(Google Drive, S3 등)로 주기적으로 백업하는 습관을 들이세요. 저도 중요한 자료는 최소 2군데 이상 백업해둡니다. 이게 진짜 보험이거든요.

    • RAID 재구성 중에는 NAS 성능이 저하됩니다.

      디스크 교체 후 RAID 재구성 중에는 NAS의 CPU와 디스크 I/O 사용량이 급증합니다. 이 시간 동안에는 NAS 성능이 현저히 떨어질 수 있으니, 중요한 작업을 피하는 게 좋습니다.

    • 추가 디스크 고장에 대비하세요.

      RAID 재구성 중 또 다른 디스크가 고장 나는 최악의 시나리오도 발생할 수 있습니다. 특히 오래된 디스크 여러 개를 동시에 사용하고 있다면 이런 위험이 더 커집니다. 이때는 전문가의 도움을 받는 게 현명합니다.

    • 휴지통/스냅샷 보존 기간을 현명하게 설정하세요.

      휴지통이나 스냅샷은 과거 데이터를 보존하지만, 너무 오래 보존하면 저장 공간을 많이 차지합니다. NAS 사용 패턴에 맞춰 적절한 보존 기간을 설정하는 것이 중요합니다.

    • 물리적 손상 (헤드 손상 등)은 전문가에게!

      만약 디스크 자체의 물리적 손상으로 인해 NAS가 아예 부팅되지 않거나 디스크 인식이 안 되는 상황이라면, 자가 복구는 매우 위험합니다. 디스크를 더 손상시켜 영구적인 데이터 손실을 초래할 수 있으니, 전문 데이터 복구 업체에 의뢰하는 게 좋습니다.

    검증 및 결과: 복구된 데이터 확인하기

    데이터 복구 과정을 마쳤다면, 반드시 복구된 데이터가 정상인지 확인해야 합니다. 파일 스테이션에서 복구된 파일을 열어보거나, 복구된 공유 폴더에 접속하여 내용이 온전한지 검증하는 거죠.

    1. 복구된 파일/폴더 확인: 파일 스테이션에서 복구된 파일들이 원래 자리에 잘 있는지, 내용이 손상되지 않았는지 직접 열어서 확인합니다.
    2. 저장소 관리자 상태 확인: RAID 재구성을 했다면, 저장소 관리자 > 저장소 풀에서 모든 디스크와 저장소 풀의 상태가 정상으로 표시되는지 최종 확인합니다. 이것까지 확인되면 비로소 안도의 한숨을 쉴 수 있습니다. 휴~ ✅

    RAID 복구 완료 후, 저장소 관리자에서 모든 디스크와 저장소 풀의 상태가 ‘정상’임을 확인하는 모습입니다.

    마무리: 데이터 보호는 예방이 최고!

    오늘은 Synology NAS 데이터 복구에 대한 저의 경험과 노하우를 공유해 드렸습니다. 실수로 파일을 지웠을 때의 휴지통 복구부터, 과거 시점으로 돌아가는 스냅샷, 그리고 디스크 고장에 대비하는 RAID 재구성까지 다양한 시나리오를 다뤄봤네요.

    사실 데이터 복구는 언제나 긴장되는 일이고, 완벽하게 성공한다는 보장도 없습니다. 그래서 가장 좋은 데이터 보호 전략은 ‘예방’이라는 점을 다시 한번 강조하고 싶습니다.

    • 중요한 공유 폴더에는 꼭 휴지통을 활성화해두세요.
    • 주기적으로 스냅샷을 찍고 보존 정책을 세우세요.
    • 무엇보다 Hyper Backup으로 외부 백업을 생활화하세요.
    • 그리고 저장소 관리자를 통해 NAS의 상태를 주기적으로 모니터링하는 것도 잊지 마세요.

    저도 13년간 인프라 엔지니어로 일하면서 수많은 ‘데이터 손실’ 관련 이슈를 겪어봤지만, 결국 답은 항상 ‘미리 준비하는 것’에 있더라고요. 여러분의 소중한 데이터가 안전하게 보관되기를 바라며, 다음번에는 더 유익한 정보로 찾아오겠습니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!

    Synology NAS의 주요 데이터 복구 방법들을 한눈에 비교할 수 있는 표입니다.

  • [k8s] Flux CD GitOps 파이프라인 구축: 안정적인 쿠버네티스 배포 자동화

    [k8s] Flux CD GitOps 파이프라인 구축: 안정적인 쿠버네티스 배포 자동화

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 많은 인프라 엔지니어분들이 한 번쯤은 고민해봤을 주제, 바로 쿠버네티스(Kubernetes) 배포 자동화에 대해 이야기해보려고 합니다. 특히 GitOps(깃옵스) 방법론과 그 구현체 중 하나인 Flux CD(플럭스 CD)를 활용한 파이프라인 구축 경험을 공유해 드릴게요.

    혹시 이런 경험 있으신가요? 개발팀에서 “배포해주세요!” 요청이 들어오면, kubectl apply -f 명령어를 조심스럽게 입력하면서, “혹시나 다른 설정이 덮어씌워지는 건 아닐까?”, “이전 버전으로 되돌리려면 어떻게 해야 하지?” 같은 걱정을 했던 순간 말이죠. 저는 셀 수 없이 많습니다. 수동 배포는 휴먼 에러의 온상이었고, 배포하다 새벽을 맞이하는 일도 비일비재했거든요. 이런 삽질을 거듭하다가 GitOps를 만나고 나서야 비로소 안정적인 배포의 빛을 보게 되었습니다. 제 홈랩에서도 여러 서비스를 GitOps로 관리하고 있는데, 정말 편하더라고요!

    GitOps 파이프라인은 Git 저장소를 ‘진리의 단일 출처(Single Source of Truth)’로 삼아, 쿠버네티스 클러스터의 상태를 Git에 선언된 대로 유지하는 방식입니다. 간단히 말해, Git에 저장된 설정 파일이 곧 클러스터의 현재 상태여야 한다는 거죠.

    GitOps와 Flux CD, 정말 좋은 이유

    처음 GitOps라는 개념을 들었을 때는 “어차피 Git에 YAML 파일 올리는 건 똑같은데, 뭐가 다르지?” 싶었어요. 근데 실제로 써보니 이 방식이 가진 장점이 정말 많더라고요. 제가 느낀 가장 큰 장점들을 꼽아보면 이렇습니다.

    • 일관성(Consistency): 모든 설정이 Git에 있으니, 개발, 스테이징, 운영 환경 간의 차이를 최소화할 수 있어요. “제 환경에서는 잘 되는데요?” 하는 말이 확 줄어듭니다.
    • 감사 및 추적(Auditability & Traceability): Git 커밋(Commit) 기록 자체가 변경 이력이 되니까요. 누가, 언제, 무엇을 변경했는지 명확하게 알 수 있죠. 문제 발생 시 롤백(Rollback)도 Git으로 너무나 쉽습니다.
    • 안정성(Reliability): Git에 선언된 상태와 클러스터의 실제 상태가 다르면, GitOps 에이전트가 자동으로 클러스터를 Git의 상태로 되돌립니다. 마치 자가 치유(Self-healing) 능력 같달까요?
    • 생산성(Productivity): 수동 작업이 줄어들고 자동화되면서, 엔지니어는 더 중요한 일에 집중할 수 있게 됩니다.

    이런 GitOps의 철학을 구현하는 대표적인 도구가 바로 Flux CD입니다. Flux CD는 쿠버네티스 클러스터 내에서 동작하는 컨트롤러(Controller)들의 집합인데요, 주기적으로 Git 저장소를 감시하다가 변경 사항이 감지되면 자동으로 클러스터에 적용해주는 역할을 합니다. 주요 컴포넌트로는 Source Controller(소스 컨트롤러), Kustomize Controller(커스터마이즈 컨트롤러), Helm Controller(헬름 컨트롤러) 등이 있습니다.

    Flux CD GitOps 파이프라인 구축 실전 가이드

    자, 그럼 이제 제 홈랩에서 Flux CD를 어떻게 구축했는지, 단계별로 자세히 알려드릴게요. 저도 처음엔 공식 문서를 보면서 여러 번 헤맸는데, 이 가이드가 여러분의 삽질 시간을 줄여주길 바랍니다!

    1단계: 사전 준비 및 Flux CLI 설치

    먼저, 쿠버네티스 클러스터에 접근 가능한 환경과 kubectl, git이 설치되어 있어야 합니다. 저는 로컬 PC에 flux CLI(Command Line Interface)를 설치하는 것부터 시작했어요.

    # Flux CLI 설치 (macOS 기준)
    brew install fluxcd/flux/flux
    
    # 설치 확인
    flux --version
    # flux version 2.x.x (최신 버전으로 설치됩니다)
    
    # 클러스터에 Flux CD가 설치될 네임스페이스 생성 (선택 사항)
    kubectl create namespace flux-system
    

    flux-system 네임스페이스는 Flux CD 컨트롤러들이 배포될 기본 공간입니다. 따로 지정하지 않으면 기본으로 이 네임스페이스에 설치되죠.

    2단계: Git 저장소 준비

    Flux CD는 Git 저장소를 바라보며 작동하기 때문에, 쿠버네티스 설정 파일(YAML)들을 저장할 Git 저장소가 필요합니다. 저는 GitHub에 gitops-k8s-homelab이라는 프라이빗(Private) 저장소를 만들었어요. 저장소 안에는 다음과 같은 구조로 파일을 구성할 예정입니다.

    gitops-k8s-homelab/
    ├── clusters/
    │   └── my-cluster/
    │       ├── flux-system/
    │       │   └── gotk-components.yaml
    │       │   └── gotk-sync.yaml
    │       └── apps/
    │           └── my-app/
    │               └── kustomization.yaml
    ├── apps/
    │   └── my-app/
    │       ├── deployment.yaml
    │       ├── service.yaml
    │       └── ingress.yaml
    └── README.md
    

    clusters/my-cluster/flux-system 경로에는 Flux CD 자체의 설정 파일들이, clusters/my-cluster/apps 경로에는 클러스터에 배포할 애플리케이션들을 정의하는 Kustomization 파일들이 들어갈 겁니다. 실제 애플리케이션 YAML 파일들은 apps/my-app 경로에 두고요.

    3단계: Flux CD 부트스트랩 (Bootstrap)

    이제 가장 중요한 단계입니다. flux bootstrap github 명령어를 사용해서 Flux CD를 쿠버네티스 클러스터에 설치하고, Git 저장소와 연결하는 작업을 수행합니다. 이 명령 한 방으로 Flux CD가 클러스터에 필요한 모든 컴포넌트를 배포하고, 지정된 Git 저장소를 바라보도록 설정해줍니다. 저는 GitHub를 사용했으니 github 옵션을 사용했어요.

    # 환경 변수 설정 (개인 GitHub 토큰과 사용자명으로 대체하세요!)
    export GITHUB_TOKEN="YOUR_GITHUB_TOKEN" # Personal Access Token
    export GITHUB_USER="YOUR_GITHUB_USERNAME"
    
    # Flux CD 부트스트랩 실행
    flux bootstrap github \
      --owner=${GITHUB_USER} \
      --repository=gitops-k8s-homelab \
      --branch=main \
      --path=clusters/my-cluster \
      --personal
    

    이 명령을 실행하면 Flux CD가 클러스터에 설치되고, clusters/my-cluster 경로를 기준으로 Git 저장소의 내용을 동기화하기 시작합니다. --personal 옵션은 개인 저장소에 주로 사용하고, 조직(Organization) 저장소의 경우 --owner를 조직명으로 지정하고 SSH 키 방식으로 인증하는 것이 일반적입니다. 저는 홈랩이라 개인 토큰으로 편하게 작업했어요.

    부트스트랩이 완료되면, Git 저장소의 clusters/my-cluster/flux-system 경로에 Flux CD 자체의 Kustomization 파일들이 자동으로 생성되어 커밋되는 것을 볼 수 있습니다. 이게 바로 Flux CD가 스스로를 GitOps 방식으로 관리하는 모습이죠. 신기하더라고요!

    4단계: 애플리케이션 배포를 위한 Kustomization 정의

    이제 클러스터에 배포할 애플리케이션을 정의하고 Flux CD가 이를 인식하도록 설정할 차례입니다. 먼저, apps/my-app 경로에 간단한 NGINX 애플리케이션을 정의하는 YAML 파일들을 만듭니다.

    # apps/my-app/deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx-app
      labels:
        app: my-nginx-app
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: my-nginx-app
      template:
        metadata:
          labels:
            app: my-nginx-app
        spec:
          containers:
          - name: nginx
            image: nginx:latest
            ports:
            - containerPort: 80
    ---
    # apps/my-app/service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: my-nginx-app-service
    spec:
      selector:
        app: my-nginx-app
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      type: ClusterIP
    

    그리고 이 애플리케이션을 클러스터에 배포하도록 지시하는 Kustomization 파일을 clusters/my-cluster/apps/my-app/kustomization.yaml 경로에 생성합니다.

    # clusters/my-cluster/apps/my-app/kustomization.yaml
    apiVersion: kustomize.toolkit.fluxcd.io/v1
    kind: Kustomization
    metadata:
      name: my-nginx-app
      namespace: flux-system
    spec:
      interval: 1m0s
      sourceRef:
        kind: GitRepository
        name: flux-system
      path: ./apps/my-app
      prune: true
      validation: client
    

    이 파일들을 Git 저장소에 커밋(Commit)하고 푸시(Push)합니다.

    git add .
    git commit -m "Add my-nginx-app and kustomization"
    git push origin main
    

    Flux CD는 clusters/my-cluster/flux-system/gotk-sync.yaml 파일에 정의된 Kustomization에 의해 clusters/my-cluster 경로를 1분마다 동기화합니다. 그러면 방금 추가한 clusters/my-cluster/apps/my-app/kustomization.yaml 파일이 클러스터에 적용되고, 이 Kustomization이 다시 apps/my-app 경로의 NGINX 애플리케이션을 클러스터에 배포하게 됩니다. 이 모든 과정이 자동으로 이뤄지는 거죠!

    ⚠️ 삽질 경험 & 트러블슈팅 팁

    제가 Flux CD를 사용하면서 겪었던 몇 가지 삽질과 해결 팁을 공유해 드릴게요. 여러분은 저처럼 헤매지 마시라고요! ㅎㅎ

    • 동기화 지연 문제: Git에 변경사항을 푸시했는데, 클러스터에 바로 적용이 안 되는 경우가 있습니다. Kustomization 리소스의 interval 값이 기본 10분으로 설정되어 있거나, 네트워크 문제 등으로 Git 저장소에 접근이 안 되는 경우가 많았어요. 급할 때는 다음 명령어로 강제 동기화를 시도합니다.
      flux reconcile kustomization my-nginx-app --with-source
      

      이 명령은 해당 Kustomization과 그 소스 GitRepository를 즉시 동기화하도록 Flux CD에 지시합니다.

    • Git Repository 구조 설계: 처음에는 모든 YAML 파일을 한 폴더에 때려 넣었는데, 나중에 애플리케이션이 많아지고 환경이 복잡해지면서 관리가 힘들어지더라고요. clusters/[클러스터이름]/[환경]/apps/[앱이름] 같은 계층적인 구조나, clusters와 apps를 분리하는 구조로 가져가는 것이 훨씬 효율적입니다. 저는 지금 clusters와 apps를 분리해서 관리하고 있어요.
    • 시크릿(Secret) 관리: 데이터베이스 비밀번호 같은 민감한 정보는 Git에 평문으로 올릴 수 없죠. 저는 SOPS(Secrets OPerationS)를 사용해서 Git 저장소에 암호화된 시크릿을 저장하고, Flux CD가 배포 시 자동으로 복호화하도록 설정했습니다. EKS(Elastic Kubernetes Service) 같은 클라우드 환경에서는 KMS(Key Management Service)를 연동해서 SOPS를 사용하는 것이 일반적입니다.
    • CRD(Custom Resource Definition) 적용 순서: 때로는 특정 컨트롤러나 미들웨어의 CRD가 먼저 클러스터에 적용되어야만 해당 리소스를 배포할 수 있습니다. 예를 들어, Istio(이스티오)나 Cert-Manager(서트 매니저) 같은 도구들이 그렇죠. 이런 경우, Kustomization의 dependsOn 필드를 사용하거나, healthChecks를 설정하여 의존성을 명확히 해주는 것이 중요합니다.

    ✅ 배포 결과 확인 및 검증

    이제 모든 설정이 잘 적용되었는지 확인해볼 시간입니다. flux get kustomizations 명령어로 Flux CD가 관리하는 Kustomization 리소스들의 상태를 확인할 수 있습니다.

    flux get kustomizations
    NAME            REVISION        SUSPENDED   READY   MESSAGE                                         LAST ACTIVITY
    flux-system     main/a1b2c3d4   False       True    Kustomization reconciled successfully           2026-05-15T10:00:00Z
    my-nginx-app    main/e5f6g7h8   False       True    Kustomization reconciled successfully           2026-05-15T10:01:00Z
    

    READY 상태가 True이고 MESSAGE에 성공 메시지가 보인다면, Flux CD가 정상적으로 작동하고 있다는 뜻입니다. 이제 쿠버네티스 클러스터에 NGINX 애플리케이션이 잘 배포되었는지 확인해볼까요?

    kubectl get deployment my-nginx-app
    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
    my-nginx-app   2/2     2            2           5m
    
    kubectl get service my-nginx-app-service
    NAME                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    my-nginx-app-service     ClusterIP   10.96.100.123   <none>        80/TCP    5m
    

    🎉 드디어 성공입니다! my-nginx-app 배포가 정상적으로 2개의 레플리카(Replica)로 동작하고 있는 것을 확인할 수 있네요. 이제 Git 저장소의 apps/my-app/deployment.yaml 파일에서 replicas 수를 3으로 변경하고 푸시해보세요. 잠시 후 Flux CD가 이를 감지하고 자동으로 클러스터의 레플리카 수를 3으로 업데이트할 겁니다. 이 경험을 하고 나면 GitOps의 매력에서 헤어 나올 수 없을 거예요!

    GitOps는 이렇게 Git에 대한 변경만으로 클러스터의 상태를 관리할 수 있게 해줍니다. 저는 이 편리함 덕분에 홈랩에서 새로운 서비스를 배포할 때마다 kubectl 명령어를 직접 입력할 일이 거의 없어졌어요. 모든 변경사항은 Git에 기록되니, 누가 어떤 변경을 했는지도 명확하게 알 수 있고요. 정말 안정적이고 편리한 배포 파이프라인이 구축된 거죠.

    마무리하며: GitOps와 Flux CD, 현대 인프라의 필수 도구

    오늘은 13년차 인프라 엔지니어의 경험을 바탕으로 Flux CD GitOps 파이프라인 구축에 대해 상세히 이야기해봤습니다. 쿠버네티스 배포 자동화는 현대 인프라에서 선택이 아닌 필수가 되어가고 있습니다. 특히 GitOps는 그 중심에서 안정성, 일관성, 생산성이라는 세 마리 토끼를 동시에 잡을 수 있게 해주는 강력한 방법론이라고 생각합니다.

    물론 처음에는 GitOps 개념이나 Flux CD 사용법이 낯설고 어렵게 느껴질 수 있습니다. 저도 그랬거든요. 하지만 한 번 제대로 구축하고 나면, 인프라 관리의 패러다임이 확 바뀌는 것을 경험하실 수 있을 겁니다. 마치 수동으로 서버를 한 대 한 대 설치하다가 프로비저닝(Provisioning) 자동화를 접했을 때의 충격과 비슷하다고 할까요?

    다음 글에서는 오늘 다루지 못한 Helm Chart(헬름 차트)를 Flux CD로 관리하는 방법이나, 멀티 클러스터(Multi-cluster) 환경에서의 GitOps 전략, 그리고 SOPS를 이용한 시크릿 관리 등 좀 더 심화된 주제들을 다뤄볼 예정입니다. 이 글이 여러분의 쿠버네티스 여정에 작은 도움이 되었기를 바랍니다!

    궁금한 점이나 저의 삽질 경험에 대한 질문이 있으시면 언제든지 댓글 남겨주세요! 저도 계속 배우고 성장하는 중이거든요. 😊

  • [Cloud] GitHub Actions OIDC로 AWS 인증하기: 보안 강화 및 자격 증명 관리

    [Cloud] GitHub Actions OIDC로 AWS 인증하기: 보안 강화 및 자격 증명 관리

    GitHub Actions에서 AWS 인증, 아직도 IAM Access Key 쓰시나요?

    안녕하세요, 13년차 인프라 엔지니어이자 서버실 주인장입니다. 지난 몇 년간 수많은 CI/CD 파이프라인(Continuous Integration/Continuous Delivery Pipeline)을 구축하고 관리해왔는데, GitHub Actions와 AWS를 연동해서 사용하는 경우가 정말 많았거든요. 처음에는 저도 많은 분들처럼 AWS IAM(Identity and Access Management) 사용자의 Access Key와 Secret Key를 GitHub Secrets에 넣어 사용했습니다. 편리하긴 했죠. 근데 이게 뭔가 찜찜하더라고요.

    Access Key는 말 그대로 영구적인 자격 증명(Long-lived Credentials)이라 탈취 위험이 늘 존재하고, 정기적으로 Key를 교체(Rotation)해야 하는 관리 부담도 만만치 않았습니다. 만약 여러 레포지토리에서 같은 키를 쓴다면 더더욱 골치 아파지고요. 혹시 이런 경험 있으신가요? 저도 처음엔 이 방식밖에 없나 싶었는데, 다행히 더 안전하고 효율적인 방법이 등장했습니다. 바로 GitHub Actions OIDC(OpenID Connect)를 활용한 AWS 인증입니다! 오늘은 이 OIDC를 이용해 GitHub Actions에서 AWS에 안전하게 접근하는 방법을 제 경험을 바탕으로 자세히 알려드릴게요. CI/CD 파이프라인의 보안을 한 단계 끌어올리는 중요한 포인트가 될 겁니다.

    GitHub Actions OIDC를 이용한 AWS 인증의 전체적인 아키텍처 다이어그램입니다. GitHub Actions가 OIDC Provider 역할을 하고, AWS IAM이 이를 신뢰하여 임시 자격 증명을 발급하는 과정을 보여줍니다.

    OIDC(OpenID Connect)와 워크로드 아이덴티티(Workload Identity)가 뭔가요?

    본격적인 설정에 들어가기 전에, OIDC와 워크로드 아이덴티티라는 개념을 잠시 짚고 넘어가면 좋습니다. 복잡하게 들릴 수 있지만, 쉽게 말해볼게요.

    • OIDC (OpenID Connect, 오픈아이디 커넥트): OAuth 2.0 위에 구축된 인증(Authentication) 프로토콜입니다. 사용자(혹은 서비스)가 어떤 Identity Provider(신원 제공자)에게 “나 누구야”라고 인증받으면, Identity Provider는 ID Token이라는 걸 발급해줍니다. 이 토큰 안에는 “이 사람이 누구고, 어떤 방식으로 인증했는지” 같은 정보가 담겨있죠. AWS의 경우, GitHub Actions가 Identity Provider 역할을 하고, AWS IAM이 이 ID Token을 신뢰하는 Relying Party(의존 당사자)가 되는 겁니다.
    • 워크로드 아이덴티티 (Workload Identity): CI/CD 파이프라인의 워크로드(Workload)나 컨테이너처럼 사람이 아닌 시스템에 신원(Identity)을 부여하는 개념입니다. 기존의 Access Key 방식처럼 영구적인 자격 증명을 주지 않고, 필요할 때만 임시 자격 증명(Temporary Credentials)을 발급받아 사용하는 방식이에요. 이렇게 하면 자격 증명 탈취 위험을 최소화하고, 키 관리 부담을 없앨 수 있습니다.

    결론적으로, GitHub Actions OIDC를 사용하면 GitHub Actions 워크플로우가 직접 Access Key 없이 AWS에 “나 GitHub Actions의 이 레포지토리, 이 브랜치에서 실행된 애야!”라고 증명하고, AWS는 이 신원을 확인한 후 특정 권한을 가진 임시 자격 증명을 주는 방식이라고 이해하시면 됩니다. 진짜 편하고 안전하더라고요!

    GitHub Actions OIDC로 AWS 인증 설정 단계별 가이드

    자, 이제 실제로 GitHub Actions OIDC를 이용해 AWS에 인증하는 방법을 단계별로 따라해 볼까요? 제가 직접 해보니 몇 가지 포인트만 잘 기억하면 어렵지 않게 설정할 수 있었습니다.

    1단계: AWS IAM Identity Provider 생성하기

    가장 먼저 AWS IAM에서 GitHub Actions를 신뢰할 수 있는 OIDC Identity Provider로 등록해야 합니다. AWS 콘솔에서 진행하는 것이 가장 직관적입니다.

    1. AWS 콘솔에 로그인 후 IAM 서비스로 이동합니다.
    2. 왼쪽 탐색 메뉴에서 Access management (액세스 관리) > Identity Providers (자격 증명 공급자)를 클릭합니다.
    3. Add provider (공급자 추가) 버튼을 클릭합니다.
    4. Provider type (공급자 유형)으로 OpenID Connect를 선택합니다.
    5. Provider URL (공급자 URL)에 <code>https://token.actions.githubusercontent.com 을 입력합니다.
    6. Get thumbprint (지문 가져오기) 버튼을 클릭하여 서버 인증서 지문을 자동으로 가져옵니다.
    7. Audience (대상)에는 sts.amazonaws.com 을 입력하고 Add provider (공급자 추가)를 클릭하여 완료합니다.

    💡 팁: sts.amazonaws.com은 AWS Security Token Service의 기본 대상입니다. 다른 용도로 특정 서비스에만 OIDC를 사용한다면 해당 서비스의 Audience를 사용할 수도 있습니다.

    AWS IAM 콘솔에서 OIDC Identity Provider를 생성하는 화면입니다. Provider URL과 Audience를 정확히 입력하는 것이 중요합니다.

    2단계: AWS IAM Role 생성하기

    이제 이 OIDC Identity Provider를 통해 GitHub Actions가 임시 자격 증명을 요청할 수 있는 IAM Role을 생성해야 합니다. 이 역할에는 GitHub Actions가 AWS에서 수행할 작업에 대한 권한을 부여하게 됩니다.

    1. IAM 콘솔에서 Access management (액세스 관리) > Roles (역할)로 이동합니다.
    2. Create role (역할 생성) 버튼을 클릭합니다.
    3. Select type of trusted entity (신뢰할 수 있는 개체 유형 선택)에서 Custom trust policy (사용자 지정 신뢰 정책)를 선택합니다.
    4. 다음과 같이 신뢰 정책을 작성합니다. 여기서 StringEquals 조건이 핵심입니다!
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
              "token.actions.githubusercontent.com:sub": "repo:YOUR_GITHUB_ORG/YOUR_GITHUB_REPO:ref:refs/heads/main"
            }
          }
        }
      ]
    }

    ⚠️ 주의사항:

    • YOUR_AWS_ACCOUNT_ID: 여러분의 AWS 계정 ID로 교체해야 합니다.
    • YOUR_GITHUB_ORG/YOUR_GITHUB_REPO: GitHub 조직(Organization) 이름과 레포지토리(Repository) 이름으로 교체해야 합니다.
    • ref:refs/heads/main: 이 부분은 특정 브랜치(Branch)에서만 역할 가정을 허용하겠다는 의미입니다. *를 사용하여 모든 브랜치를 허용할 수도 있지만, 보안을 위해 특정 브랜치를 지정하는 것을 권장합니다. 예를 들어, 특정 태그(tag)에서만 허용하려면 ref:refs/tags/v*와 같이 설정할 수 있습니다.
    1. 정책 검토 후 다음 단계로 넘어갑니다.
    2. 이 역할에 필요한 Permissions (권한)을 부여합니다. 예를 들어 S3 버킷에 파일을 업로드해야 한다면 AmazonS3FullAccess 대신 필요한 최소한의 권한(Least Privilege)을 부여하는 것이 좋습니다. 저는 테스트를 위해 AmazonS3ReadOnlyAccess를 잠시 붙여봤습니다.
    3. 역할 이름을 지정하고(예: GitHubActionsOIDC-S3AccessRole) 역할을 생성합니다.

    3단계: GitHub Actions Workflow 설정하기

    마지막으로 GitHub Actions 워크플로우 YAML 파일에 OIDC를 통한 AWS 인증 로직을 추가합니다. configure-aws-credentials 액션을 사용하면 아주 쉽게 설정할 수 있습니다.

    name: Deploy to AWS S3 via OIDC
    
    on:
      push:
        branches:
          - main
    
    permissions:
      id-token: write # OIDC ID Token을 요청하기 위해 필수
      contents: read # 레포지토리 코드 읽기 권한
    
    jobs:
      deploy:
        runs-on: ubuntu-latest
        steps:
          - name: Checkout code
            uses: actions/checkout@v4
    
          - name: Configure AWS Credentials with OIDC
            uses: aws-actions/configure-aws-credentials@v4
            with:
              role-to-assume: arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/GitHubActionsOIDC-S3AccessRole # 2단계에서 생성한 역할 ARN
              aws-region: ap-northeast-2 # 여러분의 AWS 리전
              # role-session-name: optional-session-name # (선택 사항)
    
          - name: List S3 buckets (for verification)
            run: aws s3 ls

    ⚠️ 여기서 중요한 포인트! permissions: id-token: write 설정은 반드시 필요합니다. 이 권한이 없으면 GitHub Actions가 OIDC ID Token을 생성할 수 없어 AWS 인증이 실패합니다. 처음엔 이걸 몰라서 삽질 좀 했습니다 ㅎㅎ

    삽질 경험: “AccessDenied” 에러의 늪에서 벗어나기 ⚠️

    제가 처음 GitHub Actions OIDC를 설정하면서 가장 많이 겪었던 문제는 다름 아닌 “AccessDenied” 에러였습니다. 워크플로우 로그를 보면 An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentity operation: Not authorized to perform sts:AssumeRoleWithWebIdentity 이런 메시지가 뜨더라고요. 진짜 답답했죠.

    주요 원인은 대부분 IAM Role의 Trust Policy (신뢰 정책) 조건 문제였습니다. 제가 겪었던 실수와 해결 방법은 다음과 같습니다.

    • Audience 불일치: IAM Identity Provider를 생성할 때 Audience를 sts.amazonaws.com으로 설정했는데, IAM Role Trust Policy의 "token.actions.githubusercontent.com:aud" 조건에도 정확히 "sts.amazonaws.com"이 들어가야 합니다. 한 글자라도 다르면 인증이 실패합니다.
    • sub 조건 오류: 가장 흔한 실수입니다. "token.actions.githubusercontent.com:sub" 조건에 지정된 GitHub 레포지토리, 브랜치 정보가 정확해야 합니다. 예를 들어, repo:YOUR_GITHUB_ORG/YOUR_GITHUB_REPO:ref:refs/heads/main 에서 오타가 있거나, 워크플로우가 실행되는 브랜치와 다르면 에러가 발생합니다. 저는 처음에 main 브랜치로 설정해놓고 develop 브랜치에서 테스트하다가 한참을 헤맸습니다.
    • permissions: id-token: write 누락: GitHub Actions 워크플로우 자체에 OIDC 토큰을 생성할 권한이 없어서 생기는 문제입니다. 이 한 줄 때문에 몇 시간을 날린 적도 있어요. 꼭 확인하세요!
    • AWS 계정 ID 또는 역할 ARN 오타: 기본적인 실수지만, 의외로 자주 발생합니다. ARN을 복사 붙여넣기 할 때 다시 한번 확인하는 습관을 들이세요.

    문제가 발생하면 AWS CloudTrail 로그를 확인하는 것이 가장 좋습니다. AssumeRoleWithWebIdentity 호출이 실패한 이유가 자세히 기록되어 있으니 꼭 살펴보세요. 삽질 끝에 드디어 성공했을 때의 그 쾌감이란! 진짜 이 맛에 엔지니어 하는 것 같아요.

    드디어 성공! OIDC로 안전하게 AWS 리소스 접근하기 🎉

    위에 설명드린 대로 모든 설정을 마치고 GitHub Actions 워크플로우를 실행하면, 아래와 같이 성공적으로 AWS 리소스에 접근하는 모습을 볼 수 있습니다.

    GitHub Actions 워크플로우가 성공적으로 AWS CLI 명령어를 실행하여 S3 버킷 목록을 가져오는 로그입니다. OIDC 기반 인증이 정상적으로 작동했음을 보여줍니다.

    워크플로우 로그를 보면 aws s3 ls 명령어가 문제없이 실행되고, S3 버킷 목록이 출력되는 것을 확인할 수 있습니다. 이제 더 이상 GitHub Secrets에 Access Key를 저장할 필요가 없어졌습니다! 🎉

    이 방식의 가장 큰 장점은 바로 단기 자격 증명(Short-lived Credentials)이라는 점입니다. GitHub Actions 워크플로우가 실행될 때만 임시 자격 증명을 발급받아 사용하고, 워크플로우가 끝나면 만료되죠. 덕분에 키 탈취로 인한 보안 위험이 현저히 줄어들고, 키 교체 주기를 관리할 필요도 없어졌습니다. 관리적인 측면에서도 엄청난 이득이라고 생각해요.

    OIDC, CI/CD 보안의 새로운 표준이 되다

    오늘은 GitHub Actions OIDC를 이용해 AWS에 안전하게 인증하는 방법을 자세히 알아봤습니다. 제가 직접 경험하며 얻은 삽질 경험과 해결 과정도 솔직하게 공유해 드렸는데요. 이 방식은 단순히 편리함을 넘어 CI/CD 파이프라인의 보안을 근본적으로 강화하는 핵심 기술이라고 생각합니다.

    기존의 Access Key 방식과 OIDC를 활용한 AWS 인증 방식의 주요 특징을 비교한 표입니다. 보안성, 관리 용이성 등 여러 측면에서 OIDC의 장점을 한눈에 보여줍니다.

    핵심 장점을 다시 정리해볼까요?

    • 보안 강화: 영구적인 Access Key 없이 임시 자격 증명 사용으로 탈취 위험 최소화.
    • 관리 용이성: Access Key 생성, 배포, 교체 등의 관리 부담 해소.
    • 정교한 권한 제어: 특정 레포지토리, 특정 브랜치, 특정 태그에서만 AWS 리소스 접근 허용 가능.
    • 감사 추적 용이: CloudTrail을 통해 어떤 GitHub Actions 워크플로우가 어떤 역할로 AWS에 접근했는지 명확하게 추적 가능.

    저도 홈랩에서 다양한 CI/CD 환경을 구성하면서 OIDC의 강력함을 몸소 체험하고 있습니다. 앞으로는 OIDC 기반의 워크로드 아이덴티티가 CI/CD 보안의 표준으로 자리매김할 것이라고 확신합니다. 혹시 아직 Access Key를 사용하고 계시다면, 이번 기회에 OIDC로 전환해 보시는 것을 강력히 추천합니다! 처음엔 조금 낯설 수 있지만, 한번 설정해두면 정말 든든하거든요.

    다음 글에서는 AWS S3에 정적 웹사이트를 배포하는 과정을 GitHub Actions OIDC와 함께 자동화하는 방법에 대해 다뤄볼까 합니다. 기대해주세요! 그럼 다음 글에서 만나요! 👋

  • [Nas] NAS RAID 구성 비교: Synology SHR vs TrueNAS ZFS RAID

    [Nas] NAS RAID 구성 비교: Synology SHR vs TrueNAS ZFS RAID

    데이터 보호의 시작: NAS RAID 구성, 왜 중요할까요?

    안녕하세요, 13년차 인프라 엔지니어입니다! 오랜만에 NAS 이야기를 좀 해보려고 해요. 저처럼 홈랩을 운영하거나 소중한 개인 데이터를 NAS(Network Attached Storage)에 저장해서 쓰시는 분들이라면, NAS RAID 구성 비교는 늘 뜨거운 감자일 겁니다. RAID(Redundant Array of Independent Disks)는 여러 개의 디스크를 묶어서 하나의 논리적인 저장 공간처럼 사용하고, 동시에 데이터의 안정성을 높이는 기술이거든요. 그런데 단순히 RAID 0, 1, 5, 6 같은 표준 RAID 레벨만 있는 게 아니라, NAS 벤더마다 자체적인 특수 RAID 구성이 있다는 사실, 알고 계셨나요? 오늘은 그중에서도 가장 인기 있는 두 가지, Synology의 SHR(Synology Hybrid RAID)과 TrueNAS의 ZFS RAID에 대해 제가 직접 써보고 겪었던 경험을 바탕으로 낱낱이 파헤쳐 보려고 합니다. 어떤 구성이 여러분의 소중한 데이터를 더 안전하고 효율적으로 지켜줄 수 있을지, 함께 고민해봅시다!

    NAS RAID 구성은 단순히 디스크를 묶는 것을 넘어, 데이터 안정성과 효율성을 동시에 잡는 핵심 기술입니다. 이 그림은 다양한 RAID 구성 방식이 데이터를 어떻게 보호하고 저장하는지 보여줍니다.

    Synology SHR vs TrueNAS ZFS RAID, 핵심 개념부터 알아볼까요?

    Synology SHR (Synology Hybrid RAID)

    Synology NAS를 써보신 분들이라면 아마 SHR(Synology Hybrid RAID)이라는 이름을 많이 보셨을 거예요. 처음엔 이게 뭔가 싶었는데, 쉽게 말해 Synology가 자체적으로 개발한 스마트한 RAID 관리 시스템입니다. 표준 RAID 레벨의 장점을 가져오면서도, 디스크 용량이 서로 다른 경우에도 공간 낭비를 최소화할 수 있도록 설계되었어요. 예를 들어, 4TB, 6TB, 8TB 디스크를 섞어 써도 효율적으로 사용할 수 있다는 거죠. 일반적인 RAID 5나 RAID 6처럼 동일 용량의 디스크가 강제되는 것에 비하면 정말 유연하더라고요.

    SHR은 기본적으로 하나의 디스크 장애를 허용하는 SHR-1과 두 개의 디스크 장애를 허용하는 SHR-2로 나뉩니다. 제가 홈랩에서 처음 Synology NAS를 구성할 때 이 유연성 덕분에 디스크 업그레이드가 정말 편했던 기억이 나네요. 💡 팁: SHR은 표준 RAID 1, 5, 6 등의 기술을 기반으로 작동하지만, Synology OS에서만 관리할 수 있는 독점 기술이라는 점을 꼭 기억해야 합니다.

    TrueNAS ZFS RAID (RAID-Z)

    다음은 TrueNAS에서 사용하는 ZFS RAID, 정확히는 ZFS 파일 시스템의 RAID-Z입니다. ZFS는 Sun Microsystems에서 개발한 고급 파일 시스템으로, 단순히 RAID 기능만 제공하는 게 아니라 볼륨 관리, 스냅샷, 데이터 무결성 검사 등 스토리지 관리에 필요한 모든 기능을 통합한 끝판왕이라고 할 수 있어요. TrueNAS는 이 ZFS를 기반으로 운영되는 오픈소스 NAS 솔루션입니다.

    RAID-Z는 ZFS의 핵심 기능 중 하나로, 표준 RAID 5, 6과 유사하지만 몇 가지 중요한 차이가 있습니다. Copy-on-Write 기술 덕분에 데이터 손실 위험이 적고, Checksum(체크섬)을 통해 데이터 무결성을 상시 검사해서 Bit Rot(비트 로트, 데이터 부패) 같은 현상으로부터 데이터를 강력하게 보호해줍니다. 제가 TrueNAS를 처음 접했을 때, 이 ZFS의 강력한 기능들에 정말 감탄했었죠. 특히 Self-Healing(자가 복구) 기능은 정말 든든하더라고요.

    RAID-Z1은 디스크 1개, RAID-Z2는 2개, RAID-Z3는 3개까지 디스크 장애를 허용합니다. vDev(Virtual Device)라는 개념으로 스토리지 풀을 구성하는데, 이 vDev 단위로 확장하거나 디스크를 교체하는 방식이 처음엔 좀 낯설었지만, 익숙해지니 정말 강력했습니다.

    실전 구성 선택: 나에게 맞는 RAID 레벨은?

    이제 두 시스템의 핵심 개념을 알았으니, 실제 환경에서 어떤 선택을 해야 할지 고민해볼 차례입니다. 제가 13년간 다양한 환경에서 NAS를 써보면서 느낀 점들을 바탕으로 몇 가지 가이드를 드려볼게요.

    Synology SHR 구성 시 고려사항

    Synology NAS는 처음 NAS를 접하는 분들이나, 저처럼 홈랩에서 편의성과 유연한 디스크 확장을 중요하게 생각하는 분들에게 정말 좋은 선택지입니다.

    • 장점:
      • 쉬운 관리: 직관적인 GUI(Graphical User Interface) 덕분에 몇 번의 클릭만으로 RAID 구성 및 볼륨 관리가 가능해요. 저도 처음엔 설명서 없이 그냥 눌러보다가 쉽게 구성했었으니까요.
      • 유연한 디스크 확장: 용량이 다른 디스크를 섞어 쓸 수 있어, 나중에 디스크를 추가하거나 업그레이드할 때 공간 낭비가 적습니다.
      • 높은 접근성: DSM(DiskStation Manager)이라는 운영체제가 워낙 잘 되어 있어서, 다양한 앱과 기능을 쉽게 활용할 수 있어요.
    • 단점:
      • 독점 기술: SHR은 Synology NAS에서만 작동합니다. 만약 Synology NAS가 고장 나서 다른 제조사 NAS로 옮겨야 한다면, 데이터 복구가 복잡해질 수 있어요. 이 부분이 사실 좀 아쉽죠.
      • 성능: ZFS에 비해 고급 데이터 무결성 기능은 부족합니다. 일반적인 사용에는 문제가 없지만, 미션 크리티컬한 환경에서는 고민이 될 수 있어요.

    TrueNAS ZFS RAID (RAID-Z) 구성 시 고려사항

    TrueNAS는 데이터 무결성과 강력한 스토리지 기능에 최우선을 두는 분들에게 적합한 솔루션입니다. 특히 서버 환경이나 엔터프라이즈급 데이터 보호가 필요한 경우에 빛을 발하죠.

    • 장점:
      • 최강의 데이터 무결성: Copy-on-Write, Checksum, Self-Healing 등 ZFS의 강력한 기능 덕분에 Bit Rot으로부터 데이터를 효과적으로 보호해요. 제가 직접 중요한 데이터를 백업할 때 이 부분이 정말 든든하더라고요.
      • 스냅샷/복제: 정교한 스냅샷 기능을 통해 특정 시점의 데이터를 보존하고, 원격으로 복제하여 재해 복구(DR) 솔루션으로도 활용할 수 있습니다.
      • 오픈소스: 커뮤니티 지원이 활발하고, 특정 벤더에 종속되지 않는다는 장점이 있어요.
    • 단점:
      • 높은 러닝 커브: ZFS의 개념(vDev, Pool, Dataset 등)이 처음엔 좀 어려울 수 있습니다. 저도 처음엔 삽질 좀 했습니다 ㅎㅎ.
      • 디스크 확장 제한: 일단 vDev를 구성하면, 해당 vDev에 디스크를 추가하여 용량을 늘리기가 어렵습니다. 기존 vDev의 모든 디스크를 더 큰 용량으로 교체해야 하거나, 새로운 vDev를 추가해야 해요. 이 부분이 SHR에 비해 유연성이 떨어지는 지점이죠.
      • 메모리 요구사항: ZFS는 안정적인 성능을 위해 충분한 RAM(메모리)을 요구합니다. 일반적으로 스토리지 1TB당 1GB의 RAM을 권장하거든요. 저렴하게 구성하려다 이 부분에서 막히는 경우가 꽤 있었어요.

    Synology SHR은 용량이 다른 디스크도 효율적으로 활용하며 유연하게 확장할 수 있는 반면, TrueNAS ZFS RAID는 강력한 데이터 무결성을 제공하지만 디스크 확장에는 제약이 따릅니다. 이 다이어그램은 각 시스템의 디스크 구성 방식을 시각적으로 보여줍니다.

    ⚠️ 제가 겪었던 삽질과 해결 과정: 이것만은 꼭 알아두세요!

    제가 직접 경험했던 몇 가지 삽질과 해결 팁을 공유해 드릴게요. 여러분은 저 같은 실수 하지 마시라고요! ㅎㅎ

    1. ZFS RAID-Z 구성 시 초기 디스크 선택의 중요성

    TrueNAS에서 RAID-Z를 구성할 때, 처음부터 계획을 잘 세우지 않으면 나중에 후회할 수 있습니다. 제가 처음에는 4TB 디스크 3개로 RAID-Z1을 만들었는데, 나중에 용량이 부족해서 8TB 디스크 2개를 추가하려고 했더니 기존 vDev에 바로 추가할 수가 없더라고요. 결국 8TB 디스크로만 새로운 vDev를 만들거나, 기존 4TB 디스크들을 8TB로 전부 교체해야 하는 상황에 직면했습니다.

    결론: ZFS는 vDev 구성 시 디스크 용량과 개수를 신중하게 결정해야 합니다. 나중에 확장성을 고려한다면, 처음부터 동일 용량의 디스크로 여러 개의 vDev를 만들거나, 통 크게 한 번에 큰 용량으로 시작하는 게 좋아요.

    2. Synology SHR에서 디스크 교체 시 주의점

    Synology SHR은 디스크 교체가 유연하다고 했잖아요? 그런데 여기서 한 가지 주의할 점이 있습니다. 예를 들어, 4TB 디스크 4개로 SHR-1을 구성했는데, 4TB 하나가 고장 나서 6TB 디스크로 교체했다고 가정해봅시다. 그럼 남은 3개의 4TB 디스크 때문에 실제 가용 용량은 여전히 4TB 기준으로 계산됩니다. 교체한 6TB 디스크의 추가 용량을 사용하려면, 다른 4TB 디스크들도 6TB 이상으로 교체해야만 해요.

    즉, 가장 작은 용량의 디스크가 전체 볼륨 용량에 영향을 미친다는 거죠. 저는 처음에 6TB 넣으면 바로 용량이 늘어날 줄 알고 신났다가, ‘어라? 왜 안 늘어나지?’ 하고 한참 헤맸던 기억이 있습니다. 결국 모든 디스크를 6TB 이상으로 교체하고 나서야 용량이 늘어나더라고요.

    3. RAM 부족이 ZFS 성능에 미치는 영향

    TrueNAS ZFS를 사용하면서 가장 많이 겪는 문제 중 하나가 바로 RAM 부족입니다. 제가 초기에 저렴한 하드웨어로 TrueNAS를 구성하면서 4GB RAM만 사용했었는데, 스냅샷이 많아지거나 대용량 파일 전송 시 시스템이 버벅거리는 현상을 겪었어요. ZFS는 디스크 캐싱(ARC, L2ARC)과 데이터 무결성 검사 등 다양한 작업을 위해 RAM을 적극적으로 활용하거든요.

    그래서 TrueNAS 공식 문서에서는 최소 8GB, 그리고 스토리지 1TB당 1GB RAM을 권장합니다. 저도 나중에 RAM을 16GB로 업그레이드하고 나서야 훨씬 쾌적하게 사용할 수 있었어요. ZFS는 RAM 넉넉하게! 이게 핵심입니다.

    그래서, 어떤 RAID 구성이 저에게 딱 맞을까요?

    결국, Synology SHR과 TrueNAS ZFS RAID 중 어떤 것을 선택할지는 여러분의 우선순위와 사용 환경에 따라 달라집니다. 제가 경험한 바를 바탕으로 간단히 정리해 드릴게요.

    특징 Synology SHR TrueNAS ZFS RAID
    운영체제 DSM TrueNAS CORE/SCALE (ZFS)
    주요 장점 쉬운 사용성, 유연한 디스크 확장 강력한 데이터 무결성, 스냅샷/복제
    주요 단점 독점 기술, 고급 기능 부족 높은 러닝 커브, 디스크 확장 제약, RAM 요구사항
    추천 사용자 NAS 초보자, 유연한 디스크 확장 원하는 홈랩 사용자 데이터 무결성 최우선 사용자, 고급 스토리지 기능 원하는 전문가/기업
    주요 RAID 레벨 SHR-1 (1개 장애 허용), SHR-2 (2개 장애 허용) RAID-Z1 (1개 장애 허용), RAID-Z2 (2개 장애 허용), RAID-Z3 (3개 장애 허용)

    Synology DSM과 TrueNAS GUI는 각기 다른 방식으로 스토리지 상태와 RAID 구성 정보를 시각적으로 보여줍니다. 이 이미지는 각 시스템의 대시보드를 통해 현재 볼륨 상태와 디스크 건강도를 확인하는 모습을 담고 있어요.

    마무리하며: 여러분의 데이터, 어떻게 지키실 건가요?

    오늘은 Synology SHR과 TrueNAS ZFS RAID라는 두 가지 강력한 NAS RAID 구성 방식에 대해 비교해봤습니다. 저의 13년차 인프라 엔지니어 경험을 바탕으로 솔직한 사용기와 삽질 경험을 공유해 드렸는데, 도움이 되셨으면 좋겠네요.

    • Synology SHR: 편의성과 유연한 확장성을 최우선으로 생각하고, 직관적인 GUI로 쉽게 NAS RAID 구성을 운영하고 싶은 분들에게 강력 추천합니다.
    • TrueNAS ZFS RAID: 최고 수준의 데이터 무결성과 고급 스토리지 기능이 필요하며, 어느 정도 학습 곡선을 감수하더라도 안정적인 데이터 보호를 원하는 분들에게 적합합니다.

    결국 정답은 없습니다. 여러분의 예산, 기술 수준, 그리고 무엇보다 데이터의 중요도에 따라 최적의 선택은 달라질 수 있어요. 어떤 선택을 하시든, 중요한 건 데이터 백업을 생활화하는 것입니다! RAID는 데이터 유실의 위험을 줄여주지만, 절대 백업을 대체할 수는 없다는 점, 잊지 마세요!

    다음번에는 각 시스템에서 스냅샷 기능을 활용하는 방법이나, 외부 클라우드로 백업하는 전략에 대해 더 깊이 다뤄볼까 합니다. 혹시 궁금한 점이나 여러분의 경험담이 있다면 댓글로 남겨주세요! 저도 많이 배우고 싶습니다. 감사합니다!

    이 인포그래픽은 Synology SHR과 TrueNAS ZFS RAID의 핵심적인 장점과 단점을 한눈에 비교하여, 사용자의 NAS RAID 구성 선택에 실질적인 도움을 줄 수 있도록 디자인되었습니다.

  • [3D Printer] 3D 프린터 필라멘트 종류별 완벽 가이드: PLA, PETG, ABS 선택 및 출력 팁

    3D 프린터 필라멘트 종류별 완벽 가이드: PLA, PETG, ABS 선택 및 출력 팁

    3D 프린터를 처음 샀을 때 저도 필라멘트 앞에서 한참 멈췄던 기억이 나요. PLA, PETG, ABS… 마트에서 라면 고르는 것도 아니고, 이게 다 뭔가 싶었거든요. 근데 사실 3D 프린터 필라멘트 선택이 출력 품질의 80%를 결정한다고 해도 과언이 아니에요. 소재를 잘못 고르면 아무리 세팅을 잘 해도 출력물이 들뜨거나, 갈라지거나, 형태가 무너지거든요. 이 글에서는 제가 홈랩에서 직접 써보면서 쌓은 경험을 바탕으로 PLA, PETG, ABS 비교부터 실전 출력 팁까지 한 번에 정리해 드릴게요.

    ▲ PLA, PETG, ABS 세 가지 필라멘트의 특성을 한눈에 비교한 개요 다이어그램

    필라멘트(Filament)가 뭔지 먼저 짚고 가요

    쉽게 말해서 필라멘트는 3D 프린터의 ‘재료’예요. FDM(Fused Deposition Modeling, 열용융 적층 방식) 방식 프린터는 이 실 모양의 플라스틱 소재를 고온으로 녹여서 층층이 쌓아 올려 출력물을 만들어요. 마치 글루건으로 뭔가를 만드는 느낌인데, 훨씬 정밀하고 자동화된 버전이라고 보시면 돼요.

    필라멘트는 보통 직경 1.75mm 또는 2.85mm 두 가지 규격이 있어요. 요즘 대부분의 가정용 프린터는 1.75mm를 써요. 소재별로 녹는 온도, 강도, 유연성, 수분 흡수율이 다 다르기 때문에 용도에 맞는 걸 골라야 해요.

    그리고 중요한 포인트! 필라멘트는 흡습성(수분을 흡수하는 성질)이 있어요. 개봉 후 관리를 잘 못 하면 출력 품질이 뚝 떨어지더라고요. 이 부분은 뒤에서 자세히 다룰게요.

    PLA vs PETG vs ABS: 3D 프린터 필라멘트 핵심 차이점

    먼저 세 소재의 특성을 표로 정리해 봤어요. 저도 처음엔 이게 헷갈렸는데, 이 표 하나만 봐도 어느 정도 감이 잡히실 거예요.

    항목 PLA PETG ABS
    출력 난이도 ⭐ 쉬움 ⭐⭐ 보통 ⭐⭐⭐ 어려움
    노즐 온도 (일반적) 190~220°C 230~250°C 230~250°C
    베드 온도 (일반적) 50~60°C (무가열도 가능) 70~90°C 100~110°C
    내열성 낮음 (60°C 이상 변형) 중간 (80°C 전후) 높음 (100°C 전후)
    강도 / 충격 저항 딱딱하나 취성(brittle) 있음 강하고 유연함 강하고 가공 용이
    수축 / 워핑(warping) 거의 없음 약간 있음 많음 (관리 필수)
    냄새 약함 (달콤한 향) 약간 있음 강함 (환기 필수)
    후가공 (사포, 도색) 보통 어려움 (표면이 끈적) 쉬움 (아세톤 스무딩 가능)
    주요 용도 피규어, 프로토타입, 데코 기구 부품, 투명 출력물 내열 부품, 자동차 용품

    PLA (폴리유산): 3D 프린터 필라멘트 입문자의 친구

    PLA는 제가 처음 3D 프린터를 샀을 때부터 지금까지도 가장 많이 쓰는 소재예요. 옥수수 전분이나 사탕수수에서 추출한 바이오 기반 플라스틱이라서 친환경적이기도 하고요.

    PLA의 장점

    • 출력이 쉬워요: 수축이 거의 없어서 워핑(warping, 출력물이 베드에서 들뜨는 현상) 걱정이 적어요. 가열 베드 없이도 어느 정도 출력이 돼요.
    • 표면 품질이 좋아요: 레이어 라인이 깔끔하게 나오는 편이라 피규어나 전시용 출력물에 딱이에요.
    • 색상이 다양해요: 실크(silk), 메탈릭, 마블 등 특수 효과 PLA도 많아서 선택지가 넓어요.
    • 가격이 저렴해요: 세 소재 중 가장 가성비가 좋아요.

    PLA의 단점 — 이건 진짜 주의하세요

    • 내열성이 낮아요: 여름철 차 안에 PLA 출력물을 두면 변형될 수 있어요. 실제로 제가 차량 내부 부품을 PLA로 만들었다가 여름에 흐물흐물해진 걸 목격했어요 😅
    • 취성(brittleness)이 있어요: 충격에 의해 쉽게 깨질 수 있어요. 기계적으로 하중이 걸리는 부품엔 적합하지 않아요.
    • 흡습성이 있어요: 습기를 먹으면 출력 중 ‘뚝뚝’ 소리가 나고 표면이 거칠어져요.

    PLA 출력 팁

    1. 노즐 온도는 200~215°C 범위에서 시작해서 브랜드별로 조금씩 조정하세요.
    2. 베드에 PEI 시트(스프링 스틸 시트)를 쓰면 접착력이 훨씬 좋아져요.
    3. 출력 속도는 처음엔 50mm/s 이하로 시작하고 세팅이 안정되면 올리세요.
    4. 냉각 팬(part cooling fan)을 충분히 켜야 오버행(overhang, 돌출 부위) 품질이 좋아요.

    ▲ PLA 필라멘트의 슬라이서(slicer) 설정 예시와 완성된 출력물 비교. 노즐 온도와 냉각 팬 설정이 핵심이에요.

    PETG (폴리에틸렌 테레프탈레이트): 실용파의 선택

    PETG는 제가 “아, 이거 진짜 좋다”고 느낀 소재예요. PLA의 출력 편의성과 ABS의 내구성을 적당히 섞어놓은 느낌이거든요. 기구 부품, 홈랩 케이스 브래킷 같은 걸 만들 때 자주 써요. 3D 프린터 필라멘트 중에서 실용성이 가장 뛰어나다고 봐요.

    PETG의 장점

    • 강도와 유연성의 밸런스: PLA보다 충격에 강하고, ABS처럼 딱딱하지만 않아서 적당히 유연해요. 나사 구멍이 있는 부품 만들 때 특히 좋아요.
    • 내화학성: 화학약품에 비교적 강해서 외부 환경에 노출되는 부품에 적합해요.
    • 레이어 접착력이 좋아요: 레이어 간 접착(layer adhesion)이 PLA보다 뛰어나서 구조적 강도가 높아요.
    • 투명 출력 가능: 클리어(clear) PETG로 반투명 출력물을 만들 수 있어요.

    PETG의 단점 — 삽질 경험 공유

    • 스트링(stringing) 현상이 심해요: 노즐이 이동할 때 실처럼 얇은 줄이 생기는 스트링 현상이 PLA보다 심하게 나타나요. 리트렉션(retraction, 필라멘트 역방향 당김) 설정을 잘 잡아야 해요. 저도 처음에 스트링 때문에 출력물이 거미줄처럼 됐었어요 ㅎㅎ
    • 표면이 PLA보다 끈적해요: 레이어가 잘 붙는 게 장점이지만, 서포트(support, 지지대) 제거가 어렵고 후가공이 까다로워요.
    • 흡습성이 강해요: PETG는 특히 습기에 민감해요. 건조 보관이 필수예요.
    • 베드 접착이 너무 강할 수 있어요: PEI 시트에 너무 잘 붙어서 오히려 출력물을 뗄 때 시트가 손상될 수 있어요. 릴리즈 스프레이를 살짝 뿌려주는 게 좋아요.

    PETG 출력 팁

    1. 리트렉션 거리를 짧게 설정하세요. 다이렉트 드라이브(direct drive)면 1~2mm, 보덴(bowden) 방식이면 4~6mm 정도로 시작해서 테스트하세요.
    2. 출력 속도를 40~50mm/s로 낮추면 스트링과 표면 품질이 많이 개선돼요.
    3. 냉각 팬은 PLA보다 약하게 (50% 이하) 설정하세요. 너무 빠르게 식히면 레이어 접착력이 떨어져요.
    4. 첫 레이어(first layer) 속도는 꼭 느리게 해주세요. PETG는 첫 레이어 밀착이 중요해요.

    ABS (아크릴로니트릴 부타디엔 스티렌): 고급 사용자의 영역

    ABS는 솔직히 다루기가 까다로워요. 처음 ABS를 써보다가 워핑 때문에 출력물이 베드에서 통째로 떨어지는 걸 보고 “이게 뭔가” 싶었거든요. 근데 제대로 세팅하면 내열성과 후가공 측면에서 다른 3D 프린터 필라멘트가 따라오기 어려운 장점이 있어요.

    ABS의 장점

    • 내열성이 높아요: 자동차 내부 부품, 전자제품 케이스 등 고온 환경에 적합해요.
    • 아세톤 스무딩(acetone smoothing) 가능: 아세톤 증기에 노출시키면 표면이 매끄럽게 녹아 붙어서 레이어 라인이 사라져요. 마치 사출 성형품처럼 만들 수 있어요. 이 효과 처음 봤을 때 진짜 신기했어요.
    • 기계적 강도가 높아요: 레고 블록이 ABS로 만들어지죠. 그만큼 내구성이 검증된 소재예요.
    • 사포질, 도색이 쉬워요: 후가공 작업이 세 소재 중 가장 용이해요.

    ABS의 단점 — 이건 진짜 각오해야 해요

    • 워핑(warping)이 심해요: 수축률이 높아서 출력 중 베드에서 들뜨는 현상이 자주 발생해요. 인클로저(enclosure, 밀폐 챔버)가 사실상 필수예요.
    • 냄새가 강해요: 출력 중 스티렌 계열 냄새가 심하게 나요. 반드시 환기가 잘 되는 공간에서, 가능하면 공기청정기와 함께 써야 해요.
    • 인클로저가 필요해요: 주변 온도가 낮으면 출력물이 수축하면서 갈라지거나 뒤틀려요. 밀폐된 챔버로 출력 환경 온도를 유지해야 해요.
    • 흡습성도 있어요: 습기를 먹으면 출력 중 기포가 생겨요.

    ABS 출력 팁

    1. 인클로저는 선택이 아닌 필수: 없으면 워핑과의 싸움이에요. 상용 인클로저가 없다면 판지나 아크릴판으로 임시 챔버라도 만드세요.
    2. 베드에 ABS 슬러리(ABS 조각 + 아세톤을 녹인 액체)를 바르면 접착력이 크게 올라가요.
    3. 노즐 온도 240°C 전후, 베드 온도 100~110°C에서 시작하세요.
    4. 냉각 팬은 첫 몇 레이어는 끄고, 이후에도 최소한으로 사용하세요.
    5. 아세톤 스무딩 작업 시 환기와 화재 예방에 각별히 주의하세요. ⚠️ 아세톤은 인화성이 강해요.

    ⚠️ 필라멘트 보관 및 건조: 절대 무시하면 안 돼요

    이게 진짜 중요한데 많이들 지나치는 부분이에요. 필라멘트 종류에 상관없이 모든 소재는 흡습성이 있어요. 습기를 먹은 필라멘트로 출력하면 이런 증상이 나타나요:

    • 출력 중 ‘뚝뚝’, ‘치직’ 소리가 남 (기포 터지는 소리)
    • 표면이 거칠어지고 기포 흔적이 생김
    • 스트링이 심해짐
    • 레이어 접착력이 약해져 출력물이 잘 부러짐

    올바른 필라멘트 보관 방법

    • 밀봉 가방 + 실리카겔(silica gel): 개봉 후 지퍼백이나 진공 백에 실리카겔과 함께 보관하세요.
    • 드라이 박스(dry box): 식품 건조제 넣은 밀폐 용기에 필라멘트를 보관하면 더 좋아요. 저는 플라스틱 밀폐 용기 여러 개 써요.
    • 필라멘트 드라이어(filament dryer): 이미 습기를 먹은 필라멘트는 전용 건조기나 식품 건조기로 건조시킬 수 있어요. PLA는 45~50°C에서 4~6시간, PETG는 65°C에서 4~6시간 정도가 일반적이에요.

    ▲ 올바른 필라멘트 보관법: 밀폐 용기 + 실리카겔 조합과 필라멘트 드라이어 활용 예시

    💡 어떤 3D 프린터 필라멘트를 선택해야 할까? 상황별 추천

    결국 “어떤 게 제일 좋아요?”라는 질문에 정답은 없어요. 용도에 따라 최적의 소재가 달라지거든요. 제가 정리한 상황별 추천이에요:

    • 처음 3D 프린터를 시작했다면 → PLA로 시작하세요. 세팅이 쉽고 실패 확률이 낮아요.
    • 피규어, 미니어처, 장식품 → PLA (표면 품질 우수, 색상 다양)
    • 기계 부품, 클립, 브래킷, 홀더 → PETG (내구성과 출력 편의성 밸런스)
    • 투명 또는 반투명 출력물 → 클리어 PETG
    • 차량 내부, 고온 환경 노출 부품 → ABS
    • 후가공이 중요한 고품질 모형 → ABS (아세톤 스무딩)
    • 실외 장기 노출 부품 → PETG (UV 저항성이 PLA보다 좋음)

    자주 묻는 질문 (FAQ)

    Q. PLA와 PETG를 같은 노즐로 써도 되나요?

    네, 됩니다. 다만 소재 전환 시 노즐을 충분히 고온(250°C 이상)으로 올려서 이전 소재 잔량을 퍼지(purge)해주세요. 색상이나 소재가 섞이면 출력 품질이 떨어질 수 있어요.

    Q. ABS 없이 내열성을 높이려면요?

    ABS 대신 ASA(아크릴로니트릴 스티렌 아크릴레이트)나 PC(폴리카보네이트) 같은 소재를 고려해볼 수 있어요. 특히 ASA는 ABS와 비슷한 특성에 UV 저항성까지 갖추고 있어서 실외용 부품에 좋아요. 다만 이쪽도 출력 난이도가 있어서 ABS에 어느 정도 익숙해진 후 도전하시길 권해요.

    Q. 필라멘트 브랜드는 어떤 걸 써야 하나요?

    처음엔 국내외 메이저 브랜드 제품으로 시작하는 게 좋아요. 품질 편차가 적고 커뮤니티에 설정값 레퍼런스가 많거든요. 저렴한 무명 필라멘트는 직경 편차가 커서 압출 불균형이 생길 수 있어요.

    Q. 필라멘트 1kg이면 얼마나 쓸 수 있어요?

    출력물 크기와 인필(infill, 내부 채움 밀도)에 따라 천차만별이에요. 15% 인필 기준으로 손바닥 크기 출력물 수십 개는 거뜬히 나온다고 보시면 돼요. 슬라이서(slicer) 소프트웨어에서 미리 예상 사용량을 확인할 수 있어요.

    ▲ PLA, PETG, ABS 필라멘트 종류별 선택 가이드 요약 — 용도, 난이도, 보관법을 한눈에 정리한 인포그래픽

    🎉 마무리: 결국 직접 써봐야 알아요

    정리하자면, 3D 프린터 필라멘트 선택의 핵심은 이렇게 요약돼요:

    • ✅ PLA: 입문자, 장식품, 빠른 프로토타입 → 일단 PLA로 시작
    • ✅ PETG: 실용 부품, 내구성 필요, 중급자 → 기능성 부품엔 PETG
    • ✅ ABS: 내열 부품, 후가공 중요, 인클로저 보유자 → 고급 사용자에게 추천

    제가 13년 동안 인프라 엔지니어로 일하면서 느낀 건, 새로운 도구든 새로운 소재든 결국 직접 써보고 삽질해봐야 제대로 안다는 거예요. 이 글이 그 삽질의 양을 조금이라도 줄여드리길 바라는 마음으로 썼어요.

    다음 글에서는 슬라이서(slicer) 소프트웨어 설정 최적화 — 특히 Cura와 OrcaSlicer 기준으로 소재별 프로파일 세팅하는 방법을 다룰 예정이에요. 이 글이 도움이 됐다면 댓글로 어떤 소재 관련 궁금증이 있는지 남겨주세요. 다음 글 주제 선정에 반영할게요! 😊

  • [HomeLabs] UPS와 홈서버 연동: Proxmox/TrueNAS 자동 종료 설정 완벽 가이드

    [HomeLabs] UPS와 홈서버 연동: Proxmox/TrueNAS 자동 종료 설정 완벽 가이드

    UPS와 홈서버 연동: Proxmox/TrueNAS 자동 종료 설정 완벽 가이드

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩을 운영하면서 가장 신경 쓰이는 부분이 뭘까요? 저는 주저 없이 전원 문제라고 말할 수 있어요. 특히 갑작스러운 정전은 애지중지 키워온 홈서버의 하드웨어뿐만 아니라, 그 안에 담긴 소중한 데이터까지 한순간에 날려버릴 수 있는 무서운 재앙이거든요.

    제가 처음 홈랩을 구성하고 몇 달 뒤였을 겁니다. 한창 드라마를 보는데 갑자기 집 전체가 퍽! 하고 암전되더라고요. 순간 ‘아, 망했다!’ 싶었죠. 다행히 서버는 무사했지만, 그날 이후로 UPS(무정전 전원 장치)의 필요성을 뼈저리게 느꼈습니다. 단순히 전원을 공급해주는 것을 넘어, 정전 시 서버를 안전하게 종료시키는 자동화가 정말 중요하다는 걸 깨달았죠.

    오늘은 저처럼 홈랩을 운영하시는 분들을 위해, UPS와 홈서버(특히 Proxmox VE와 TrueNAS)를 연동해서 정전 시 자동으로 시스템이 종료되도록 설정하는 방법을 차근차근 알려드릴게요. 13년 동안 이런저런 삽질을 하면서 터득한 경험을 바탕으로, 여러분은 좀 더 쉽게 성공하시길 바랍니다! 💡

    홈랩 UPS 연동 아키텍처: 정전 시 서버들을 안전하게 지키는 핵심 구성입니다.

    UPS와 NUT(Network UPS Tools)는 뭐 하는 건가요?

    먼저 핵심 개념부터 짚고 넘어갈게요. ‘UPS’는 다들 아실 겁니다. 쉽게 말해 보조 배터리 같은 역할을 하면서, 정전이 되면 일정 시간 동안 서버에 전원을 공급해주는 장치죠. 하지만 UPS의 진짜 가치는 단순히 전원을 유지하는 것을 넘어, 서버에게 “야, 지금 전기가 나갔어! 얼른 마무리하고 꺼져야 해!”라고 알려줄 수 있을 때 빛을 발합니다.

    이때 필요한 게 바로 NUT(Network UPS Tools)예요. NUT는 UPS와 서버 간의 통신을 담당하는 오픈소스 소프트웨어 스위트(Software Suite)입니다. UPS의 상태(배터리 잔량, 전원 상태 등)를 모니터링하고, 특정 조건(예: 배터리 잔량 20% 미만)이 되면 연결된 서버들에게 종료 신호를 보내는 역할을 하죠.

    • UPS 서버 (Server): 물리적인 UPS 장치에 직접 연결되어 UPS 상태를 읽어오는 역할을 해요. 보통 USB 케이블로 연결하죠. 이 서버에 upsd (UPS Daemon)가 실행되면서 다른 클라이언트들에게 UPS 정보를 제공합니다.
    • UPS 클라이언트 (Client): UPS 서버로부터 UPS 상태 정보를 받아, 특정 조건이 되면 스스로 종료하거나 미리 설정된 작업을 수행합니다. Proxmox VE나 TrueNAS 같은 홈서버들이 여기에 해당해요. upsmon (UPS Monitor)이 이 역할을 담당합니다.

    저는 보통 라즈베리 파이 같은 저전력 장치나, 최소한의 리소스를 할당한 가상 머신에 NUT 서버를 구성합니다. 아무래도 UPS가 서버 전체를 위한 장치이니, 그 정보를 관리하는 서버는 가급적 안정적이고 전력을 덜 먹는 게 좋더라고요.

    실전 구현: NUT 서버와 클라이언트 설정

    자, 이제 실전입니다. 저는 제가 직접 구성한 환경을 기준으로 설명해 드릴게요. UPS는 APC BR1500MS 같은 모델을 많이 쓰시는데, USB로 연결되는 대부분의 UPS는 NUT와 호환되니 크게 걱정하지 않으셔도 돼요. 제가 사용했던 UPS도 USB로 연결되는 모델이었거든요.

    1. NUT 서버 설정 (Debian/Ubuntu 기반 VM 또는 Raspberry Pi)

    먼저, UPS에 USB로 직접 연결될 NUT 서버를 설정해봅시다. 저는 Proxmox 위에 데비안(Debian) 가상 머신을 하나 띄워서 사용했어요.

    패키지 설치:

    sudo apt update
    sudo apt install nut

    /etc/nut/ups.conf 설정:
    이 파일은 UPS 장치의 종류와 연결 방식을 NUT에게 알려줍니다. UPS 모델에 따라 드라이버(driver)가 달라질 수 있으니, NUT 공식 문서를 참고해서 맞는 드라이버를 찾아주세요. 저는 usbhid-ups 드라이버를 사용했어요.

    [myups]
      driver = usbhid-ups
      port = auto
      desc = "My HomeLab UPS"
      # mincharge = 80  # 배터리 최소 충전량 (예: 80% 미만이면 경고)
      # override.battery.charge.low = 20 # 배터리 잔량 20% 미만 시 저전압 경고

    /etc/nut/nut.conf 설정:
    NUT의 동작 모드를 설정합니다. 여기서는 STANDALONE 대신 SERVER로 설정해야 다른 서버들이 이 UPS 정보를 가져갈 수 있어요.

    MODE=SERVER

    /etc/nut/upsd.users 설정:
    클라이언트들이 UPS 정보를 모니터링할 때 사용할 사용자 계정을 정의합니다. 보안을 위해 강력한 비밀번호를 사용하는 것이 좋겠죠.

    [upsmon]
      password = YourStrongPasswordHere
      actions = SET
      instcmds = ALL
      upsmon master

    /etc/nut/upsd.conf 설정:
    NUT 데몬이 어떤 IP 주소와 포트(기본 3493)에서 클라이언트의 연결을 받을지 설정합니다. 저는 홈랩 내부에서만 사용할 것이므로 내부 IP를 바인딩했어요.

    LISTEN 0.0.0.0 3493 # 모든 인터페이스에서 수신 (혹은 특정 내부 IP)

    NUT 서비스 재시작 및 확인:

    sudo systemctl restart nut-server nut-client
    sudo systemctl enable nut-server nut-client
    sudo upsc myups@localhost # UPS 정보 확인. 'myups'는 ups.conf에 설정한 이름입니다.

    upsc myups@localhost 명령어를 실행했을 때, UPS의 다양한 정보(배터리 잔량, 전압 등)가 잘 출력된다면 NUT 서버 설정은 성공입니다! 🎉

    NUT 서버 설정의 핵심, ups.conf 파일입니다. UPS 모델에 맞는 드라이버를 찾는 것이 정말 중요해요.

    2. Proxmox VE 클라이언트 설정

    이제 Proxmox VE 서버가 NUT 서버로부터 UPS 정보를 받아 정전 시 자동으로 종료되도록 설정해볼까요? Proxmox는 Debian 기반이라 NUT 클라이언트 설정이 비교적 간단해요.

    패키지 설치:

    apt update
    apt install nut

    /etc/nut/nut.conf 설정:
    Proxmox는 NUT 서버가 아닌 클라이언트 역할을 하므로 MODE=NETCLIENT로 설정합니다.

    MODE=NETCLIENT

    /etc/nut/upsmon.conf 설정:
    이 파일에서 어떤 UPS 서버를 모니터링할지, 그리고 어떤 조건에서 종료할지 정의합니다. MONITOR 라인에 NUT 서버의 IP 주소, UPS 이름, 사용자 이름, 비밀번호를 입력하세요.

    MONITOR [email protected] 1 upsmon YourStrongPasswordHere master
    # (192.168.1.100은 NUT 서버의 IP 주소로 바꿔주세요)
    
    MINWARNTIME 300   # UPS 경고 발생 후 최소 5분 대기
    FINALDELAY 5      # 시스템 종료까지 추가 대기 시간 (초)
    SHUTDOWNCMD "/sbin/shutdown -h now" # 종료 명령
    NOTIFYCMD "/usr/sbin/upssched-cmd" # 알림 스크립트 (선택 사항)
    
    NOTIFYFLAG ONLINE SYSLOG+WALL
    NOTIFYFLAG ONBATT SYSLOG+WALL
    NOTIFYFLAG LOWBATT SYSLOG+WALL
    NOTIFYFLAG FSD SYSLOG+WALL
    
    # Proxmox의 경우, 가상머신 및 컨테이너를 먼저 종료해야 합니다.
    # 저는 아래와 같이 별도 스크립트를 만들어서 사용했어요.
    # /etc/nut/upsmon.conf 에 직접 넣기보다는, SHUTDOWNCMD가 실행할 스크립트 안에 넣는 것이 좋습니다.
    # (예시: /etc/nut/ups_shutdown.sh)
    # SCRIPT: /etc/nut/ups_shutdown.sh
    # (스크립트 예시는 뒤에서 설명합니다)

    Proxmox 특화: 가상 머신/컨테이너(VM/CT) 종료 스크립트
    Proxmox는 단순히 shutdown -h now만 실행하면 호스트만 꺼지고 VM/CT는 강제 종료될 수 있어요. 이를 방지하려면 VM/CT를 먼저 안전하게 종료하는 스크립트를 작성하여 SHUTDOWNCMD에 연결해야 합니다. 저는 다음과 같은 스크립트를 사용했습니다.

    #!/bin/bash
    
    logger -t ups_shutdown "UPS shutting down Proxmox and VMs/CTs..."
    
    # 모든 VM 및 CT 목록 가져오기
    vms=$(qm list | awk 'NR>1 {print $1}')
    cts=$(pct list | awk 'NR>1 {print $1}')
    
    # VM 종료
    for vmid in $vms
    do
      status=$(qm status $vmid | awk '{print $2}')
      if [ "$status" = "running" ]; then
        logger -t ups_shutdown "Shutting down VM $vmid..."
        qm shutdown $vmid --timeout 30
        sleep 5
        if [ "$(qm status $vmid | awk '{print $2}')" = "running" ]; then
          logger -t ups_shutdown "VM $vmid did not shut down gracefully, stopping..."
          qm stop $vmid
        fi
      fi
    done
    
    # CT 종료
    for ctid in $cts
    do
      status=$(pct status $ctid | awk '{print $2}')
      if [ "$status" = "running" ]; then
        logger -t ups_shutdown "Shutting down CT $ctid..."
        pct shutdown $ctid --timeout 30
        sleep 5
        if [ "$(pct status $ctid | awk '{print $2}')" = "running" ]; then
          logger -t ups_shutdown "CT $ctid did not shut down gracefully, stopping..."
          pct stop $ctid
        fi
      fi
    done
    
    logger -t ups_shutdown "All VMs/CTs processed. Shutting down Proxmox host."
    sleep 10 # VM/CT 종료 대기 시간을 충분히 줍니다.
    /sbin/shutdown -h now

    이 스크립트를 /etc/nut/ups_shutdown.sh 로 저장하고 실행 권한을 부여한 뒤,

    sudo chmod +x /etc/nut/ups_shutdown.sh

    /etc/nut/upsmon.conf 파일의 SHUTDOWNCMD를 다음과 같이 수정하세요.

    SHUTDOWNCMD "/etc/nut/ups_shutdown.sh"

    NUT 클라이언트 서비스 재시작 및 확인:

    systemctl restart nut-client
    systemctl enable nut-client
    upsc [email protected] # NUT 서버의 UPS 정보 확인

    3. TrueNAS 클라이언트 설정

    TrueNAS는 NUT 클라이언트 기능이 웹 인터페이스에 통합되어 있어 설정이 훨씬 간편합니다. 제가 써보니 이 부분이 정말 편하더라고요!

    1. TrueNAS 웹 UI에 접속하세요.
    2. 좌측 메뉴에서 Services (서비스)를 클릭합니다.
    3. 서비스 목록에서 UPS를 찾아 Configure (설정) 버튼을 클릭하세요.
    4. 설정 창에서 다음 정보를 입력합니다:
      • UPS Type (UPS 유형): Slave (클라이언트 역할을 하므로)
      • Remote Host (원격 호스트): NUT 서버의 IP 주소 (예: 192.168.1.100)
      • Remote Port (원격 포트): 3493 (기본값)
      • Identifier (식별자): NUT 서버의 ups.conf에 설정한 UPS 이름 (예: myups)
      • Monitor User (모니터 사용자): upsmon (upsd.users에 설정한 사용자)
      • Monitor Password (모니터 비밀번호): YourStrongPasswordHere (upsd.users에 설정한 비밀번호)
      • Shutdown Mode (종료 모드): UPS reaches low battery (UPS 배터리가 부족할 때)
      • Shutdown Timer (종료 타이머): 120 (배터리 부족 감지 후 120초 뒤 종료)
    5. Save (저장) 버튼을 클릭하세요.
    6. 서비스 목록으로 돌아가서 UPS 서비스를 Enabled (활성화)로 설정하고 Start (시작) 버튼을 클릭합니다.

    TrueNAS 로그를 확인하여 UPS 서비스가 정상적으로 시작되었는지, NUT 서버와 통신하는지 확인해 보세요. /var/log/messages나 웹 UI의 시스템 로그에서 관련 메시지를 찾을 수 있어요.

    TrueNAS의 UPS 설정 화면입니다. 웹 UI 덕분에 직관적으로 설정할 수 있어요.

    ⚠️ 주의사항 및 트러블슈팅 (제 삽질 경험 공유)

    제가 이 설정을 하면서 겪었던 몇 가지 삽질 경험과 주의사항을 알려드릴게요. 여러분은 저처럼 고생하지 마시길!

    1. 방화벽 문제: NUT 서버와 클라이언트 간에 3493번 포트 통신이 제대로 되는지 꼭 확인하세요. 특히 NUT 서버로 설정한 VM이나 물리 장치에 ufw나 firewalld 같은 방화벽이 있다면 3493번 포트를 열어줘야 해요. sudo ufw allow 3493/tcp 같은 명령어로 열 수 있습니다. 저는 처음에 이걸 놓쳐서 ‘왜 연결이 안 되지?’ 하고 한참을 헤맸습니다. ㅠㅠ
    2. USB 드라이버 문제: UPS가 USB로 NUT 서버에 제대로 인식되지 않는 경우가 간혹 있어요. lsusb 명령어로 UPS 장치가 목록에 뜨는지 확인하고, dmesg | grep -i usb 명령어로 커널 로그를 확인해서 드라이버 로딩에 문제가 없는지 봐야 합니다. 간혹 특정 UPS 모델은 추가적인 드라이버나 커널 모듈이 필요할 수 있거든요.
    3. ups.conf 드라이버 오설정: 가장 흔한 실수 중 하나예요. UPS 모델에 맞는 정확한 드라이버를 사용해야 합니다. nut-drivers 패키지 설치 후 man ups.conf나 NUT 공식 문서를 참고하는 게 가장 정확합니다.
    4. 종료 스크립트 테스트: 실제 정전 상황을 흉내 내기 어렵다면, 강제로 lowbatt 신호를 보내는 방식으로 테스트할 수 있어요. sudo upsmon -c fsd (Force Shutdown) 같은 명령어를 사용하거나, upsmon.conf에서 SHUTDOWNCMD를 테스트용 스크립트로 바꿔서 실행해 보는 것도 좋은 방법입니다. 절대 운영 중인 서버에서 바로 테스트하지 마세요! 중요한 데이터가 날아갈 수 있습니다. 테스트는 항상 충분히 백업된 환경이나 테스트용 서버에서 진행하시고, 스크립트 실행 권한(chmod +x)도 잊지 마세요!
    5. Proxmox VM/CT 종료 순서: 위에서 설명했듯이 Proxmox는 호스트만 종료하면 VM/CT가 강제 종료돼요. 반드시 qm shutdown, pct shutdown 명령어를 사용하여 순차적으로 종료하는 스크립트를 사용해야 합니다.

    검증 및 결과: 이제 안심하고 홈랩을!

    모든 설정이 끝났다면, 이제 정말 잘 작동하는지 확인해야겠죠? 저는 조심스럽게 UPS의 전원 코드를 뽑아서 실제 정전 상황을 시뮬레이션해봤습니다. (물론 중요한 작업은 모두 백업해두고, 아주 짧게 시도했어요.)

    결과는? 🎉 대성공이었습니다!

    UPS가 배터리 모드로 전환되고, 설정해둔 MINWARNTIME이 지나자 Proxmox와 TrueNAS가 순차적으로 종료되기 시작했어요. Proxmox의 경우, 제가 만들어둔 스크립트 덕분에 VM과 CT들이 먼저 안전하게 꺼진 후 호스트가 종료되는 것을 로그로 확인할 수 있었습니다. TrueNAS도 깔끔하게 종료되었고요.

    로그 확인은 journalctl -u nut-client.service (Proxmox/Debian)나 /var/log/messages (TrueNAS)를 통해 할 수 있습니다. 여기에 UPS 상태 변화와 종료 명령이 정상적으로 기록되어 있다면 안심해도 좋아요.

    시스템 로그에서 확인하는 자동 종료 과정. 이 메시지를 보면 정말 뿌듯하더라고요!

    마무리하며: 홈랩의 든든한 보험, UPS 연동

    오늘은 홈랩의 안정성을 한 단계 끌어올리는 UPS 홈서버 연동, 특히 Proxmox UPS와 TrueNAS UPS 자동 종료 설정에 대해 알아봤습니다. 처음에는 NUT 설정이 조금 복잡하게 느껴질 수도 있지만, 한 번 제대로 설정해두면 갑작스러운 정전에도 소중한 장비와 데이터를 안전하게 지킬 수 있어요. 이건 마치 홈랩을 위한 든든한 보험 같은 존재랄까요?

    저도 처음엔 ‘이거까지 해야 하나?’ 싶었는데, 한번 정전을 겪고 나니 이제는 홈랩의 필수 요소라고 생각합니다. 여러분도 이 가이드를 통해 성공적으로 UPS 연동을 마치시고, 마음 편히 홈랩을 즐기시길 바랍니다. 다음번에는 또 다른 흥미로운 홈랩 이야기로 찾아올게요! 그때까지 즐거운 삽질(?) 되세요! 😉

    UPS 연동의 핵심 가치: 안전한 홈랩, 데이터 보호, 그리고 마음의 평화!

  • [3D Printer] 3D 프린터 필라멘트 선택 가이드: PLA, ABS, PETG 비교

    [3D Printer] 3D 프린터 필라멘트 선택 가이드: PLA, ABS, PETG 비교

    3D 프린터 필라멘트 선택 가이드: PLA, ABS, PETG 비교

    왜 필라멘트 선택이 중요할까요?

    안녕하세요, 13년차의 서버실 운영자입니다. 오늘은 좀 색다른 주제로 찾아왔는데요, 바로 3D 프린터 필라멘트 이야기입니다. 제가 홈랩을 운영하면서 이것저것 만들다 보니 3D 프린터를 정말 유용하게 쓰고 있거든요. 그런데 처음 3D 프린터를 시작하시는 분들이 가장 많이 겪는 고민 중 하나가 바로 어떤 3D 프린터 필라멘트를 써야 할까? 하는 겁니다. 종류도 너무 많고, 각각 특징도 달라서 저도 처음엔 삽질 좀 했습니다. 이 글에서는 가장 흔하게 사용되는 PLA 필라멘트, ABS 필라멘트, 그리고 PETG 필라멘트를 중심으로 각 필라멘트의 특징과 저의 실제 경험을 바탕으로 한 선택 가이드를 알려드릴게요! 💡 여러분의 3D 프린팅 여정에 멘토가 되어 드릴 준비가 되어 있습니다!

    3D 프린터 필라멘트, 이게 다 뭔가요?

    자, 그럼 3D 프린터 필라멘트가 정확히 뭘까요? 쉽게 말해, 3D 프린터가 3차원 물체를 만들 때 쓰는 재료를 말해요. 국수 가닥처럼 생긴 이 플라스틱 줄을 프린터 헤드가 녹여서 한 층씩 쌓아 올리는 방식이죠. 마치 그림을 그릴 때 물감이 필요한 것처럼, 3D 프린팅에서는 이 필라멘트가 바로 ‘물감’ 역할을 하는 셈이에요. 🎨 종류에 따라 강도, 유연성, 내열성, 출력 난이도 등 다양한 특성을 가지고 있어서, 만들고자 하는 결과물의 용도에 맞춰 적절한 필라멘트 종류를 선택하는 것이 정말 중요해요. 제가 처음엔 아무거나 막 썼다가 원하는 결과물이 안 나와서 고생 좀 했거든요.

    다양한 색상과 재질의 3D 프린터 필라멘트들이 롤 형태로 진열되어 있고, 한쪽에서는 3D 프린터가 필라멘트를 이용해 출력물을 만들고 있는 모습을 보여줍니다.

    PLA (PolyLactic Acid) 필라멘트: 초보자의 친구

    가장 먼저 소개해드릴 PLA 필라멘트 (PolyLactic Acid)는 3D 프린팅 입문자분들에게 제가 강력히 추천하는 재료입니다.

    • 장점:
      • 출력 난이도 (Ease of Printing): 가장 쉬운 편입니다. 변형(Warping)이 적고, 냄새도 거의 없어서 집 안에서도 부담 없이 쓸 수 있어요. 저도 처음엔 PLA로 감을 잡았죠.
      • 친환경적 (Eco-friendly): 옥수수 전분 같은 식물성 재료로 만들어져 생분해(Biodegradable)가 가능해요. 환경을 생각한다면 좋은 선택이죠.
      • 색상 다양성 (Color Variety): 시중에 정말 다양한 색상과 특수 효과(ex: 실크, 메탈릭) 필라멘트가 많아서 디자인적인 요소를 중요하게 생각하는 분들께 좋습니다.
    • 단점:
      • 내열성 (Heat Resistance): 열에 약해서 뜨거운 곳에 두면 쉽게 변형돼요. 여름철 차 안에 두면 흐물흐물해지는 경험을 할 수도 있죠 ⚠️.
      • 강도 및 내구성 (Strength & Durability): 다른 필라멘트에 비해 충격에 약하고 잘 부러지는 편입니다.
    • 활용: 피규어, 장난감, 시제품(Prototype), 교육용 모델 등.

    제가 홈랩에서 간단한 브라켓이나 테스트용 부품을 만들 때 주로 PLA를 써요. 출력 성공률이 높아서 마음이 편하거든요.

    ABS (Acrylonitrile Butadiene Styrene) 필라멘트: 견고함의 대명사

    다음은 ABS 필라멘트 (Acrylonitrile Butadiene Styrene)입니다. 레고 블록 아시죠? 바로 그 레고가 ABS로 만들어집니다. 내구성이 필요한 출력물에 주로 사용되죠.

    • 장점:
      • 강도 및 내구성 (Strength & Durability): PLA보다 훨씬 강하고 충격에 잘 견따니다. 기능성 부품이나 오래 사용해야 하는 제품에 적합해요.
      • 내열성 (Heat Resistance): PLA보다 높은 온도에서도 형태를 유지합니다. 뜨거운 환경에서 사용할 부품이라면 ABS가 좋은 선택이에요.
      • 후가공 용이성 (Post-processing): 아세톤 흄 스무딩(Acetone Fume Smoothing) 같은 후가공을 통해 표면을 매끄럽게 만들 수 있습니다.
    • 단점:
      • 출력 난이도 (Difficulty of Printing): PLA에 비해 출력이 까다로워요. 수축(Shrinkage) 현상이 심해서 변형(Warping)이 잘 일어나고, 챔버(Chamber)가 있는 프린터나 베드 히팅(Heated Bed)이 필수예요. 저도 처음 ABS 출력하다가 출력물이 베드에서 떨어져 나가서 여러 번 좌절했습니다 😭.
      • 냄새 및 유해 증기 (Fumes): 출력 시 특유의 플라스틱 냄새가 강하게 나고, 미세 플라스틱 입자나 유해 증기가 발생할 수 있어 환기가 매우 중요합니다.
    • 활용: 자동차 부품, 공구 손잡이, 기능성 프로토타입 등.

    제가 직접 써보니까, ABS는 확실히 튼튼하지만, 출력 환경을 잘 맞춰줘야 한다는 걸 깨달았어요. 환기 시설 없는 곳에서는 절대 사용하지 마세요!

    ABS 필라멘트로 제작된 기능성 부품들이 놓여 있고, 그 옆에서는 챔버가 있는 3D 프린터가 ABS 필라멘트를 사용하여 부품을 출력하고 있는 모습이 보입니다.

    PETG (Polyethylene Terephthalate Glycol) 필라멘트: 두 마리 토끼를 잡다

    마지막으로 소개해드릴 PETG 필라멘트 (Polyethylene Terephthalate Glycol)는 PLA와 ABS의 장점을 적절히 섞어 놓은 하이브리드 같은 존재입니다.

    • 장점:
      • 강도 및 유연성 (Strength & Flexibility): ABS만큼 강하면서도 PLA보다 유연성이 좋아요. 잘 깨지지 않으면서도 어느 정도 휘어지는 특성이 있죠.
      • 내열성 및 내화학성 (Heat & Chemical Resistance): PLA보다 내열성이 좋고, 산이나 알칼리 같은 화학 물질에도 비교적 강합니다.
      • 출력 난이도 (Ease of Printing): ABS보다는 훨씬 쉽고, PLA보다는 약간 까다로운 정도예요. 베드 히팅은 권장되지만, 챔버 없이도 비교적 괜찮은 결과물을 얻을 수 있습니다.
      • 식품 안전성 (Food Safety): 일부 PETG 필라멘트는 식품 용기로도 사용되는 PET 재질과 비슷해서, 식품과 접촉하는 용도로도 고려해볼 수 있어요. (물론 직접적인 식품 용도로는 추가적인 확인이 필요합니다.)
    • 단점:
      • 끈적임 (Stringing): 출력 시 거미줄처럼 실오라기가 생기는 스트링징(Stringing) 현상이 자주 발생할 수 있어요. 리트랙션(Retraction) 설정 조절이 중요해요.
      • 표면 마감 (Surface Finish): ABS나 PLA에 비해 표면이 다소 거칠게 느껴질 수 있습니다.
    • 활용: 물병, 기능성 부품, 야외용 부품, 기계 부품 등.

    제가 실제로 PETG를 써보니까, 확실히 범용성이 높더라고요. 튼튼하면서도 출력 부담이 덜해서, PLA에서 한 단계 업그레이드하고 싶은 분들께 딱입니다.

    PETG 필라멘트로 제작된 유연한 기계 부품이 살짝 휘어져 있는 모습과, 3D 프린터의 노즐에서 녹은 PETG 필라멘트가 정확하게 쌓이는 과정이 클로즈업되어 보입니다.

    필라멘트 종류별 비교: 한눈에 보는 선택 가이드

    자, 그럼 지금까지 살펴본 세 가지 3D 프린터 필라멘트를 한눈에 비교해볼까요? 제가 직접 사용하면서 느꼈던 점들을 바탕으로 표로 정리해봤습니다. 🤓

    특징 PLA (PolyLactic Acid) ABS (Acrylonitrile Butadiene Styrene) PETG (Polyethylene Terephthalate Glycol)
    출력 난이도 쉬움 (초보자 추천) ✅ 어려움 (전문가용) ⚠️ 중간 (베드 히팅 권장)
    강도 / 내구성 낮음 (잘 부러짐) 매우 높음 (견고함) 💪 높음 (유연성 좋음)
    내열성 낮음 (뜨거운 곳에 약함) 높음 (고온에 강함) 중간 (PLA보다 좋음)
    유연성 낮음 (단단함) 낮음 (단단함) 높음 (잘 휘어짐)
    냄새 / 유해 증기 거의 없음 (약간 달콤한 향) 강함 (환기 필수) 💨 약함 (PLA와 유사)
    변형 (Warping) 적음 심함 (수축률 높음) 적음 (ABS보다 적음)
    후가공 사포질, 도색 사포질, 아세톤 흄 스무딩 사포질, 도색
    주요 용도 피규어, 장난감, 시제품 기능성 부품, 공구, 레고 기계 부품, 용기, 야외용품
    가격대 저렴한 편 중간 정도 중간 정도

    PLA, ABS, PETG 필라멘트의 주요 특징(강도, 내열성, 출력 난이도 등)을 아이콘과 그래프로 시각화하여 한눈에 비교할 수 있는 인포그래픽입니다.

    마무리: 나만의 최적 필라멘트를 찾아서

    어떠신가요? 3D 프린터 필라멘트 선택에 대한 감이 좀 잡히셨나요? 결국 어떤 필라멘트가 ‘최고’라고 단정할 수는 없어요. 중요한 건 여러분이 만들고자 하는 출력물의 용도와 3D 프린터의 성능, 그리고 본인의 숙련도에 맞춰 최적의 필라멘트 종류를 선택하는 것입니다.

    • 초보자라면 안전하게 PLA 필라멘트로 시작해서 3D 프린팅의 재미를 느껴보세요.
    • 더 강하고 견고한 출력물이 필요하고 출력 환경이 갖춰져 있다면 ABS 필라멘트에 도전해보는 것도 좋습니다.
    • PLA의 쉬운 출력성과 ABS의 강도를 동시에 원한다면 PETG 필라멘트가 아주 좋은 대안이 될 거예요.

    저도 처음엔 무작정 비싼 필라멘트가 좋겠지 하고 샀다가 낭패를 본 적이 많습니다. 😅 하지만 여러 번의 실패(삽질이라고 하죠!)를 통해 각 재료의 특성을 이해하고 나니, 이제는 어떤 출력물이든 자신 있게 만들 수 있게 됐어요.
    이 글이 여러분의 3D 프린팅 생활에 작은 도움이라도 되었기를 바랍니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요! 다음번에는 각 필라멘트별 최적 출력 설정 팁에 대해 다뤄볼까 합니다. 기대해주세요! 🎉

  • [3D Printer] 3D프린터 필라멘트 보관 및 건조 가이드: 출력 품질 유지 핵심 전략

    필라멘트 한 롤 버린 날의 이야기

    솔직히 말씀드릴게요. 저 처음에 3D프린터 샀을 때 필라멘트 보관 같은 건 전혀 신경 안 썼습니다. 그냥 프린터 옆에 대충 올려두고 쓰면 되는 거 아닌가 싶었거든요. 그러다가 어느 날 PLA 롤 하나를 거의 다 못 쓰고 통째로 날렸어요. 출력 중에 버블이 터지면서 익스트루더(Extruder, 필라멘트를 밀어내는 장치)가 막혀버리고, 표면은 울퉁불퉁하고… 뭐가 문제인지도 몰라서 한참 헤맸습니다. 알고 보니 습기였더라고요. 😅

    3D프린터 필라멘트 보관은 단순히 정리 문제가 아닙니다. 출력 품질 유지의 핵심이에요. 이걸 제대로 안 하면 아무리 좋은 프린터, 아무리 좋은 슬라이서 설정을 써도 결과물이 엉망이 될 수 있어요. 오늘은 그 삽질 경험을 바탕으로 제가 실제로 하고 있는 필라멘트 보관법과 건조 방법을 정리해드릴게요.

    ▲ 필라멘트 보관의 핵심은 습기 차단. 밀폐 용기와 제습제 조합이 기본입니다.

    왜 필라멘트는 습기에 약한가요? — 흡습성(Hygroscopic) 이해하기

    대부분의 3D프린터 필라멘트 소재는 흡습성(Hygroscopic)이 있어요. 흡습성이란 공기 중의 수분을 흡수하는 성질인데, 플라스틱 계열 소재들이 이 특성을 가지고 있습니다. 쉽게 말해, 그냥 공기 중에 놔두면 알아서 습기를 빨아들인다는 거예요.

    습기를 머금은 필라멘트를 고온의 핫엔드(Hot End, 필라멘트를 녹이는 부분)에 통과시키면 수분이 순간적으로 기화(증발)하면서 여러 문제가 생깁니다.

    • 출력 중 퍽퍽 소리(popping/crackling) 발생
    • 표면에 버블(bubble)이나 스트링(stringing, 실처럼 늘어지는 현상) 증가
    • 레이어 간 접착력(layer adhesion) 저하
    • 출력물 강도 약화
    • 심한 경우 익스트루더 막힘(clog)

    소재별로 흡습성 차이가 있어서, 어떤 소재를 쓰느냐에 따라 보관 주의도가 달라집니다.

    소재 흡습성 보관 주의도 비고
    PLA 낮음~중간 ★★☆☆☆ 그래도 장기 보관 시 건조 권장
    PETG 중간 ★★★☆☆ 출력 품질 변화 체감 쉬움
    ABS 중간 ★★★☆☆ 뒤틀림(warping)과 복합 작용
    Nylon (나일론) 매우 높음 ★★★★★ 개봉 후 수 시간 내 영향
    TPU 높음 ★★★★☆ 탄성 저하 및 표면 불량
    PC (폴리카보네이트) 높음 ★★★★☆ 고온 소재라 더욱 주의

    저는 나일론 처음 쓸 때 이걸 몰라서 개봉하고 하루 뒤에 출력했다가 정말 처참한 결과물을 봤었는데… 지금 생각하면 당연한 결과였죠 ㅎㅎ

    3D프린터 필라멘트 보관의 기본 원칙 3가지

    복잡하게 생각할 필요 없어요. 핵심은 딱 세 가지입니다.

    1. 밀폐 보관 — 공기 접촉 차단

    가장 기본이자 가장 중요한 원칙입니다. 필라멘트는 반드시 밀폐 용기(airtight container)에 보관해야 해요. 방법은 여러 가지인데요:

    • 지퍼백(zip-lock bag): 가장 저렴하고 간단한 방법. 롤 크기에 맞는 대형 지퍼백에 제습제와 함께 넣기
    • 밀폐 플라스틱 통: 시중에 파는 밀폐 식품 용기나 공구 수납함 활용. 가격 대비 효율 좋음
    • 전용 드라이 박스(Dry Box): 필라멘트 보관 전용 제품. 습도계가 내장된 제품도 있음
    • 진공 백(vacuum bag): 공기를 완전히 뽑아낼 수 있어서 장기 보관에 적합

    2. 제습제(Desiccant) 함께 보관

    밀폐 용기 안에도 잔류 수분이 있을 수 있어서 실리카겔(Silica Gel) 같은 제습제를 함께 넣어줘야 해요. 포인트는 재사용 가능한 제습제를 쓰는 겁니다. 색이 변하면(보통 파란색→분홍색 또는 오렌지색→초록색) 오븐에 넣고 건조시키면 다시 쓸 수 있거든요. 일회용 쓰면 비용이 은근히 쌓이더라고요.

    💡 팁: 밀폐 용기 안에 소형 습도계(hygrometer)를 함께 넣어두면 내부 습도를 바로 확인할 수 있어요. 목표 습도는 보통 15% 이하를 권장합니다. 저는 이걸 알고 나서 관리가 훨씬 편해졌어요.

    3. 서늘하고 어두운 곳 보관

    습기만큼 중요한 게 온도와 자외선(UV) 차단입니다. 고온 환경이나 직사광선에 노출되면 필라멘트가 취성(brittleness, 부서지기 쉬운 성질)이 생기거나 색이 변할 수 있어요. 특히 PLA는 생각보다 열에 약합니다. 여름에 차 트렁크에 두면 안 되는 이유가 바로 이거예요.

    필라멘트 건조 방법 — 이미 눅눅해진 필라멘트 살리기

    이미 습기를 먹은 필라멘트라도 제대로 건조하면 대부분 살릴 수 있어요. 방법은 몇 가지가 있는데 각각 장단점이 있습니다.

    ▲ 필라멘트 건조 방법 비교. 왼쪽부터 식품 건조기, 오븐 활용, 전용 필라멘트 드라이어.

    방법 1: 식품 건조기(Food Dehydrator) 활용

    제가 가장 추천하는 방법이에요. 온도 조절이 세밀하게 되고, 오랜 시간 돌려도 안전하거든요. 롤을 그대로 넣을 수 있는 크기인지 확인이 필요하지만, 맞는 크기 제품을 구하면 정말 편합니다.

    방법 2: 일반 오븐(Oven) 활용

    집에 있는 오븐을 쓰는 방법인데, 여기서 ⚠️ 주의사항이 있어요. 일반 오븐은 온도 편차가 크고 최저 온도가 생각보다 높은 경우가 많아요. PLA의 경우 너무 고온이면 롤이 변형될 수 있습니다. 반드시 온도계로 실제 온도를 확인하고 쓰세요. 저도 처음에 이걸 확인 안 했다가 PLA 롤 하나를 약간 녹인 적 있습니다… 😅

    방법 3: 전용 필라멘트 드라이어(Filament Dryer)

    필라멘트 건조 전용 제품들이 있어요. 온도 설정이 쉽고 안전하며, 일부 제품은 건조하면서 바로 출력할 수 있는 피드 기능도 있습니다. 자주 건조할 일이 많다면 투자할 만한 가치가 있어요.

    소재별 권장 건조 온도와 시간

    소재 권장 건조 온도 권장 건조 시간 주의사항
    PLA 45~50°C 4~6시간 고온 주의, 변형 가능
    PETG 65~70°C 4~6시간 비교적 여유 있음
    ABS 80°C 4~8시간 환기 주의
    Nylon 80~90°C 8~12시간 충분한 시간 필요
    TPU 50~60°C 4~6시간 고온 주의

    ⚠️ 위 온도와 시간은 일반적인 가이드라인이에요. 소재 제조사마다 권장 사항이 다를 수 있으니 구매한 제품의 데이터시트나 제조사 권장사항을 먼저 확인하는 게 좋습니다.

    실전 필라멘트 보관 시스템 구축 — 제가 실제로 쓰는 방법

    말로만 하면 와닿지 않으니까 제가 실제로 어떻게 하는지 공유할게요.

    단기 보관 (수일~수주 이내 사용 예정)

    1. 사용 후 필라멘트 끝부분을 롤의 구멍에 끼워서 풀리지 않게 고정
    2. 대형 지퍼백에 실리카겔과 함께 넣기
    3. 공기를 최대한 눌러 빼고 밀봉
    4. 서늘한 선반에 세워서 보관 (롤 변형 방지)

    장기 보관 (한 달 이상)

    1. 먼저 건조 과정을 거쳐서 완전히 건조된 상태로 만들기
    2. 진공 백에 넣고 공기 완전 제거
    3. 라벨에 소재, 색상, 건조 날짜 기록 (이거 안 하면 나중에 뭔지 모름 ㅎㅎ)
    4. 서늘하고 빛이 들지 않는 수납함에 보관

    💡 저는 각 롤마다 라벨을 붙이는 습관을 들였는데, 소재명/색상/브랜드/개봉일/마지막 건조일을 적어둬요. 귀찮아 보여도 롤이 쌓이면 이게 없으면 진짜 헷갈립니다.

    ▲ 라벨링과 습도계를 활용한 체계적인 필라멘트 보관 시스템 예시.

    ⚠️ 자주 하는 실수와 트러블슈팅

    문제 1: 건조했는데도 출력 품질이 안 좋아요

    건조 온도가 너무 낮거나 시간이 부족한 경우가 많아요. 특히 나일론은 생각보다 오래 건조해야 합니다. 그리고 건조 후 바로 쓰지 않으면 다시 습기를 먹을 수 있으니, 건조 직후 출력하거나 밀폐 용기에 바로 넣으세요.

    문제 2: 실리카겔이 금방 포화돼요

    용기 크기 대비 실리카겔 양이 부족한 거예요. 일반적으로 1~2kg 롤 하나당 실리카겔 50~100g 정도가 적절하다고 알려져 있어요. 그리고 정기적으로 실리카겔 상태를 확인하고 재생해주는 루틴이 필요합니다.

    문제 3: 필라멘트가 부서져요 (brittle filament)

    이건 습기 문제가 아니라 반대로 과건조(over-drying)나 UV 노출, 또는 오래된 필라멘트 문제일 수 있어요. PLA는 특히 오래되면 취성이 생기는데, 이 경우 건조로는 해결이 안 됩니다. 또한 너무 오래, 너무 높은 온도로 건조해도 필라멘트가 손상될 수 있어요.

    문제 4: 출력 중 퍽퍽 소리가 나요

    습기를 머금은 필라멘트의 전형적인 증상이에요. 출력을 멈추고 필라멘트를 건조한 뒤 다시 시도해보세요. 건조 후에도 소리가 난다면 핫엔드 쪽 문제일 수 있습니다.

    필라멘트 보관 상태 확인 방법

    어떻게 하면 필라멘트 상태가 좋은지 나쁜지 알 수 있을까요? 몇 가지 간단한 체크 방법이 있어요.

    • 소리 테스트: 필라멘트를 구부렸을 때 탁 하고 깔끔하게 부러지면 건조한 상태. 끊어지지 않고 구부러지거나 흐물거리면 습기가 있는 것
    • 출력 소리: 출력 중 퍽퍽/찌직 소리가 나면 습기 신호
    • 표면 상태: 출력물 표면에 작은 기포나 거친 텍스처가 있으면 습기 영향
    • 색상 변화: 일부 소재는 흡습 시 색이 약간 변하기도 함

    ▲ 필라멘트 보관 핵심 원칙 요약: 밀폐, 제습, 온도 관리, 정기 건조.

    자주 묻는 질문 (FAQ)

    Q. PLA는 그냥 놔둬도 되지 않나요?

    PLA가 흡습성이 낮은 편이긴 하지만, 한국처럼 여름 습도가 높은 환경에서는 PLA도 영향을 받아요. 단기간이라면 크게 문제없지만, 몇 달 이상 보관할 거라면 밀폐 보관을 권장합니다.

    Q. 건조기 없어도 건조할 수 있나요?

    네, 오븐이나 에어프라이어로도 가능합니다. 다만 온도 관리가 핵심이에요. 온도계를 꼭 쓰시고, 특히 PLA는 저온에서 건조하세요.

    Q. 진공 포장 없이 지퍼백만으로 충분한가요?

    단기~중기 보관이라면 지퍼백 + 실리카겔 조합으로도 충분합니다. 장기 보관이나 흡습성 높은 소재(나일론 등)라면 진공 포장이 확실히 더 좋아요.

    Q. 제습제는 얼마나 자주 재생해야 하나요?

    색 변화 지시 실리카겔 기준으로, 색이 완전히 변하기 전에 재생하는 게 좋아요. 환경에 따라 다르지만 보통 한 달에 한 번 정도 확인하는 루틴을 추천합니다.

    마무리 — 귀찮아도 해두면 돈이 절약됩니다

    처음엔 이 모든 게 귀찮게 느껴질 수 있어요. 저도 그랬으니까요. 근데 필라멘트 롤 하나 날리고 나서는 생각이 바뀌더라고요. 필라멘트 가격이 소재에 따라 다르지만, 한 롤에 몇 만 원씩 하는 소재들도 많잖아요. 보관 잘 못 해서 날리는 게 훨씬 손해입니다.

    정리하면 이렇습니다:

    • ✅ 사용 후 반드시 밀폐 용기에 실리카겔과 함께 보관
    • ✅ 내부 습도 15% 이하 유지 목표
    • ✅ 서늘하고 빛 없는 곳에 보관
    • ✅ 오래 묵혔거나 품질이 의심되면 건조 후 사용
    • ✅ 소재별 건조 온도/시간 지키기
    • ✅ 라벨링으로 관리 체계화

    다음 글에서는 3D프린터 출력 품질 유지를 위한 슬라이서 설정 최적화 방법도 다뤄볼 예정이에요. 필라멘트 관리와 함께 보면 훨씬 도움이 될 거예요. 혹시 필라멘트 보관이나 건조 관련해서 궁금한 점이나 다른 경험 있으시면 댓글로 남겨주세요! 🎉

  • [AI] LLM 파인튜닝 실전 가이드: LoRA, QLoRA로 커스텀 모델 만들기

    [AI] LLM 파인튜닝 실전 가이드: LoRA, QLoRA로 커스텀 모델 만들기

    LLM 파인튜닝 실전 가이드: LoRA, QLoRA로 커스텀 모델 만들기

    안녕하세요, 13년차 인프라 엔지니어 ‘서버실’입니다. 요즘 LLM(Large Language Model)의 세상이 정말 빠르게 변하고 있죠? ChatGPT 같은 거대 모델들을 보면서, ‘아, 나도 우리 회사 데이터로, 혹은 나만의 특화된 지식으로 LLM을 만들 수 없을까?’ 하는 생각, 혹시 해보셨나요?

    사실 저도 이런 꿈을 꾸다가 거대한 모델을 통째로 학습시키려면 엄청난 GPU 자원이 필요하다는 현실의 벽에 부딪혔어요. 엔비디아(NVIDIA) H100 같은 최신 GPU는 가격도 만만치 않고요. 게다가 학습 시간도 정말 어마어마하더라고요. 홈랩에서 저만의 서버를 돌리는 저 같은 사람에게는 엄두도 못 낼 일이었습니다. 😅

    하지만 희망은 있더라고요! 바로 PEFT(Parameter-Efficient Fine-Tuning, 파라미터 효율적 파인튜닝) 기법 덕분입니다. 특히 LoRA(Low-Rank Adaptation)와 이를 더 발전시킨 QLoRA(Quantized LoRA)는 제한된 자원으로도 LLM 파인튜닝을 가능하게 해주는 정말 혁신적인 방법이거든요.

    오늘은 제가 직접 여러 모델을 파인튜닝하며 겪었던 삽질 경험과 함께, LoRA와 QLoRA를 활용해서 나만의 커스텀 LLM을 만드는 실전 가이드를 여러분께 공유해드릴게요. 자, 그럼 함께 시작해볼까요?

    LLM 파인튜닝의 핵심, LoRA와 QLoRA의 기본 원리를 한눈에 볼 수 있는 다이어그램입니다.

    핵심 개념 설명: PEFT, LoRA, QLoRA 이해하기

    본격적인 실전에 앞서, 핵심 개념들을 짚고 넘어가는 게 중요해요. 제가 처음엔 이 용어들이 좀 헷갈렸거든요.

    • LLM (Large Language Model, 거대 언어 모델): 방대한 텍스트 데이터를 학습하여 사람의 언어를 이해하고 생성하는 능력을 가진 AI 모델입니다. 예를 들면 GPT-3, Llama 2 같은 모델들이죠.
    • Fine-tuning (파인튜닝): 이미 학습된 거대 모델(Pre-trained Model)을 특정 작업이나 데이터셋에 맞게 추가로 학습시키는 과정입니다. 예를 들어, 의료 질문 답변에 특화된 모델을 만들고 싶다면, 의료 데이터로 파인튜닝하는 식이죠.
    • PEFT (Parameter-Efficient Fine-Tuning, 파라미터 효율적 파인튜닝): 이 녀석이 바로 우리의 구세주입니다! 기존의 파인튜닝은 모델 전체의 모든 파라미터를 업데이트해야 해서 엄청난 자원이 필요했어요. 하지만 PEFT는 모델의 아주 작은 부분(소수의 파라미터)만 학습시키거나, 기존 모델에 작은 모듈을 추가해서 학습 효율을 극대화하는 기법들을 총칭합니다. 덕분에 적은 GPU 메모리로도 파인튜닝이 가능해지는 거죠.
    • LoRA (Low-Rank Adaptation, 저랭크 적응): PEFT의 대표적인 방법 중 하나에요. 쉽게 말해, 거대한 LLM의 가중치(weights)를 직접 수정하는 대신, 원본 가중치 옆에 아주 작은 두 개의 행렬(low-rank matrices)을 추가해서 학습시키는 방식입니다. 이 작은 행렬들만 학습시키고, 원본 모델의 가중치는 그대로 두는 거죠. 이렇게 하면 학습해야 할 파라미터 수가 극적으로 줄어들고, 학습된 어댑터(adapter)의 크기도 매우 작아서 저장 및 로드도 훨씬 수월해요.
    • QLoRA (Quantized LoRA, 양자화된 LoRA): LoRA를 한 단계 더 발전시킨 기법이에요. 기존 LoRA는 원본 모델의 가중치를 16비트 부동소수점(FP16)으로 불러와야 했는데, QLoRA는 이를 4비트 정수(4-bit quantization)로 양자화(quantization)해서 불러옵니다. 이렇게 되면 모델을 로드하는 데 필요한 GPU 메모리가 획기적으로 줄어들어요. 제가 홈랩에서 GPU 메모리가 부족해서 겪었던 수많은 삽질 끝에 찾은 빛과 같은 존재였습니다! 덕분에 8GB나 12GB GPU로도 7B(70억 개 파라미터) 이상의 LLM을 파인튜닝할 수 있게 된 거죠.

    LLM 파인튜닝 실전 구현: LoRA, QLoRA 단계별 적용

    자, 이제 이론은 충분해요! 제가 직접 홈랩에서 시도했던 과정을 바탕으로, LoRA와 QLoRA를 활용한 모델 학습 실전 가이드를 단계별로 알려드릴게요.

    1. 환경 준비

    먼저 필요한 라이브러리들을 설치해야 합니다. 파이썬(Python) 환경은 기본이겠죠? 저는 주로 가상 환경(Virtual Environment)을 만들어서 작업하는데, 깔끔하더라고요.

    # 가상 환경 생성 및 활성화
    python -m venv llm_finetune_env
    source llm_finetune_env/bin/activate
    
    # 필요한 라이브러리 설치
    # transformers: Hugging Face 모델 및 트레이너
    # peft: 파라미터 효율적 파인튜닝 (LoRA, QLoRA 등)
    # bitsandbytes: 4비트 양자화 지원
    # accelerate: 분산 학습 가속화
    # datasets: 데이터셋 로드 및 처리
    # trl: 트랜스포머 강화 학습 (SFTTrainer 사용)
    pip install transformers peft bitsandbytes accelerate datasets trl torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121
    

    여기서 <code>torch 설치 시 CUDA 버전에 맞는 URL을 사용해야 해요. 저는 CUDA 12.1 환경이라 cu121을 썼지만, 여러분의 환경에 맞춰 조절해주세요. ⚠️ GPU 드라이버와 CUDA Toolkit 버전이 제대로 맞지 않으면 모델 학습 시 에러가 발생할 수 있으니 꼭 확인하셔야 합니다!

    2. 데이터셋 준비

    파인튜닝에 사용할 데이터셋을 준비해야 합니다. 저는 간단한 질문-답변 형식의 JSON 파일을 사용했어요. 실제 프로젝트에서는 여러분의 목적에 맞는 데이터를 잘 정제하는 것이 무엇보다 중요합니다.

    # example_dataset.json
    [
      {
        "instruction": "다음 질문에 대해 간결하게 답변해 주세요.",
        "input": "LLM 파인튜닝이 무엇인가요?",
        "output": "LLM 파인튜닝은 이미 학습된 거대 언어 모델을 특정 작업이나 데이터셋에 맞게 추가로 학습시키는 과정입니다."
      },
      {
        "instruction": "LoRA의 장점을 설명해 주세요.",
        "input": "",
        "output": "LoRA는 원본 모델의 가중치를 고정하고 작은 행렬만 학습하여, 파라미터 수를 획기적으로 줄이고 학습 효율을 높이는 파인튜닝 기법입니다."
      }
    ]
    

    이 데이터를 파이썬에서 불러와서 datasets 라이브러리로 처리하면 돼요.

    3. 모델 로드 및 양자화 설정 (QLoRA)

    이제 Hugging Face에서 적당한 LLM 모델을 불러옵니다. 저는 Llama 2 7B 모델을 예시로 들어볼게요. QLoRA를 사용하려면 bitsandbytes 설정을 잘 해줘야 합니다.

    import torch
    from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig
    
    # 모델 ID (예시: 메타의 Llama-2 7B 모델)
    model_id = "meta-llama/Llama-2-7b-hf" # 실제 사용 시 접근 권한 필요
    
    # 4비트 양자화 설정
    bnb_config = BitsAndBytesConfig(
        load_in_4bit=True, # 4비트 양자화로 로드
        bnb_4bit_use_double_quant=True, # 이중 양자화 사용
        bnb_4bit_quant_type="nf4", # NormalFloat 4 (NF4) 양자화 타입
        bnb_4bit_compute_dtype=torch.bfloat16 # 계산 시 사용할 데이터 타입
    )
    
    # 토크나이저 및 모델 로드
    tokenizer = AutoTokenizer.from_pretrained(model_id)
    model = AutoModelForCausalLM.from_pretrained(
        model_id,
        quantization_config=bnb_config,
        device_map="auto" # 여러 GPU가 있다면 자동으로 분배
    )
    model.config.use_cache = False # 학습 중 캐시 비활성화
    model.config.pretraining_tp = 1 # 사전 학습 텐서 병렬 처리 설정
    

    여기서 model_id는 실제 접근 가능한 모델 ID로 변경하셔야 해요. Llama 2 같은 모델은 Hugging Face에서 접근 권한을 요청해야 하거든요. 저는 보통 공개된 모델 중 하나를 선택해서 실험합니다.

    4. LoRA 설정 및 모델 학습 준비

    peft 라이브러리를 사용해서 LoRAConfig를 정의합니다. 여기서 r (LoRA 랭크)와 lora_alpha 값이 정말 중요해요.

    from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
    
    # 4비트 학습을 위해 모델 준비
    model = prepare_model_for_kbit_training(model)
    
    # LoRA 설정
    lora_config = LoraConfig(
        r=16, # LoRA 랭크. 값이 클수록 표현력이 좋지만 파라미터도 늘어남.
        lora_alpha=32, # LoRA 스케일링 계수. r의 두 배 정도가 일반적.
        target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], # LoRA를 적용할 모듈
        bias="none", # 편향(bias) 학습 여부. 'none'이 일반적.
        lora_dropout=0.05, # LoRA 레이어에 적용할 드롭아웃
        task_type="CAUSAL_LM", # 작업 유형 (인과 언어 모델)
    )
    
    # PEFT 모델 생성
    model = get_peft_model(model, lora_config)
    model.print_trainable_parameters() # 학습 가능한 파라미터 수 확인
    

    target_modules는 LoRA를 적용할 트랜스포머 블록 내의 레이어들을 지정해요. 주로 쿼리(query), 키(key), 밸류(value), 아웃풋(output) 프로젝션 레이어에 적용하죠.

    LoRA 설정 후 학습 가능한 파라미터 수가 얼마나 줄었는지 확인하는 모습입니다. 정말 극적으로 줄어들죠?

    5. 트레이너 설정 및 모델 학습

    이제 trl 라이브러리의 SFTTrainer를 사용해서 모델 학습을 시작합니다. SFTTrainer는 지도 파인튜닝(Supervised Fine-Tuning)에 특화되어 있어서 데이터셋 처리가 정말 편해요.

    from trl import SFTTrainer
    from transformers import TrainingArguments
    from datasets import load_dataset
    
    # 데이터셋 로드 (위에서 만든 example_dataset.json 사용)
    dataset = load_dataset("json", data_files="example_dataset.json")
    
    # 훈련 인자 설정
    training_args = TrainingArguments(
        output_dir="./results", # 결과 저장 디렉토리
        num_train_epochs=3, # 학습 에포크 수
        per_device_train_batch_size=2, # GPU당 배치 크기 (메모리 제약 시 줄임)
        gradient_accumulation_steps=4, # 기울기 누적 스텝 수 (가상 배치 크기 증가)
        optim="paged_adamw_8bit", # 8비트 AdamW 옵티마이저 (메모리 효율적)
        learning_rate=2e-4, # 학습률
        logging_steps=10, # 로깅 스텝
        save_strategy="epoch", # 에포크마다 모델 저장
        evaluation_strategy="no", # 평가 전략 (간단 예시에서는 평가 생략)
        fp16=False, # QLoRA 사용 시 FP16은 비활성화
        bf16=True, # bfloat16 사용 (A100, RTX 30/40 시리즈 등 지원 GPU)
    )
    
    # SFTTrainer 생성
    trainer = SFTTrainer(
        model=model,
        train_dataset=dataset["train"],
        peft_config=lora_config,
        dataset_text_field="input", # 텍스트 필드 지정 (데이터셋 구조에 따라 다름)
        max_seq_length=512, # 최대 시퀀스 길이
        tokenizer=tokenizer,
        args=training_args,
    )
    
    # 학습 시작!
    trainer.train()
    
    # 학습된 어댑터 저장
    trainer.model.save_pretrained("./my_llm_adapter")
    tokenizer.save_pretrained("./my_llm_adapter")
    

    gradient_accumulation_steps는 메모리가 부족할 때 배치 크기를 효과적으로 늘리는 방법이에요. per_device_train_batch_size * gradient_accumulation_steps가 실제 효과적인 배치 크기가 됩니다. bf16=True는 bfloat16을 지원하는 GPU에서 모델 학습 속도를 높이고 메모리 효율을 좋게 만듭니다.

    ⚠️ 주의사항 및 트러블슈팅 (삽질 경험 공유)

    제가 이 과정에서 정말 많이 겪었던 문제들이 몇 가지 있어요. 독자 여러분은 저처럼 삽질하지 마시라고 공유해드립니다!

    • ⚠️ CUDA Out of Memory (OOM) 에러: 가장 흔하게 만나는 문제일 거예요. 특히 GPU 메모리가 8GB, 12GB 정도라면 QLoRA를 써도 OOM이 발생할 수 있어요.
      • 해결책: per_device_train_batch_size를 1로 줄이고, gradient_accumulation_steps를 늘려보세요. max_seq_length도 줄이는 것이 도움이 될 수 있습니다. bitsandbytes의 bnb_4bit_compute_dtype을 torch.bfloat16 대신 torch.float16으로 바꿔보는 것도 방법입니다. (단, bf16=True 대신 fp16=True로 설정해야 합니다.)
    • ⚠️ 모델 학습 속도 저하: QLoRA는 메모리 효율적이지만, 4비트 양자화된 가중치를 매번 역양자화(dequantize)해서 계산해야 하므로 학습 속도가 약간 느려질 수 있어요.
      • 해결책: bf16=True를 사용하면 (지원 GPU 한정) 속도 개선에 도움이 됩니다. 데이터 로딩 파이프라인 최적화(예: num_workers 설정)도 고려해보세요.
    • ⚠️ 데이터셋 포맷 오류: SFTTrainer의 dataset_text_field나 formatting_func 설정이 데이터셋 구조와 맞지 않으면 에러가 납니다.
      • 해결책: 데이터셋 JSON 파일의 키(key)와 dataset_text_field가 정확히 일치하는지 확인해야 해요. 만약 복잡한 포맷이라면 formatting_func를 직접 구현해서 데이터를 원하는 형태로 만들어줘야 합니다. 저도 여기서 한참 헤맸거든요.
    • ⚠️ 커스텀 모델의 성능 부족: 아무리 파인튜닝을 해도 원하는 결과가 나오지 않을 때가 있어요.
      • 해결책: 가장 큰 원인은 데이터셋의 품질과 양입니다. 충분히 다양하고 고품질의 데이터가 아니라면 모델은 제대로 학습되지 않아요. LoRA 하이퍼파라미터(r, lora_alpha, learning_rate)를 튜닝해보는 것도 중요합니다. 저는 wandb(Weights & Biases) 같은 툴을 써서 실험 결과를 추적하며 모델 학습의 최적 파라미터를 찾곤 합니다.

    파인튜닝 모델 검증 및 결과 확인 🎉

    자, 이제 학습이 끝났으니 우리가 만든 커스텀 LLM이 얼마나 잘 작동하는지 확인해볼 차례예요!

    1. 학습된 모델 로드

    학습된 LoRA 어댑터와 토크나이저를 다시 불러옵니다. 이때 원본 모델도 함께 로드해야 해요.

    from transformers import AutoTokenizer, AutoModelForCausalLM
    from peft import PeftModel, PeftConfig
    import torch
    
    # 원본 모델 로드 (QLoRA 설정과 동일하게)
    model_id = "meta-llama/Llama-2-7b-hf"
    bnb_config = BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_use_double_quant=True,
        bnb_4bit_quant_type="nf4",
        bnb_4bit_compute_dtype=torch.bfloat16
    )
    base_model = AutoModelForCausalLM.from_pretrained(
        model_id,
        quantization_config=bnb_config,
        device_map="auto"
    )
    tokenizer = AutoTokenizer.from_pretrained(model_id)
    
    # 학습된 LoRA 어댑터 로드
    peft_model_id = "./my_llm_adapter"
    model = PeftModel.from_pretrained(base_model, peft_model_id)
    
    # 모델을 평가 모드로 전환 (Dropout 등 비활성화)
    model.eval()
    

    2. 추론 (Inference)

    이제 우리의 커스텀 모델에 질문을 던져봅시다. 학습 데이터셋에 있던 내용과 비슷한 질문을 던져보면, 훨씬 더 정확하고 원하는 형식의 답변을 생성하는 것을 볼 수 있을 거예요.

    # 질문 생성 (데이터셋 형식과 유사하게)
    prompt = "### Instruction:\n다음 질문에 대해 간결하게 답변해 주세요.\n\n### Input:\nLLM 파인튜닝은 무엇인가요?\n\n### Output:"
    
    # 토크나이저로 인코딩
    inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
    
    # 모델로 답변 생성
    with torch.no_grad():
        outputs = model.generate(
            **inputs,
            max_new_tokens=200, # 최대 생성 토큰 수
            do_sample=True, # 샘플링 기반 생성
            top_p=0.9, # 상위 p 확률 내에서 샘플링
            temperature=0.7, # 창의성 조절
        )
    
    # 결과 디코딩 및 출력
    response = tokenizer.decode(outputs[0], skip_special_tokens=True)
    print(response)
    

    출력된 답변을 보면, 우리가 파인튜닝한 의도대로 간결하고 정확한 정보가 나오는 것을 확인할 수 있어요. 처음엔 정말 너무 기특해서 박수까지 쳤다니까요! 🎉

    파인튜닝된 LLM이 질문에 대해 답변하는 모습입니다. 우리가 의도한 대로 잘 대답하고 있죠?

    마무리 💡

    오늘은 13년차 인프라 엔지니어인 제가 직접 경험하며 익힌 LLM 파인튜닝의 세계, 특히 LoRA와 QLoRA 기법을 활용한 커스텀 LLM 구축 방법에 대해 자세히 알아봤습니다.

    이 방법들을 통해 우리는 다음과 같은 장점을 얻을 수 있더라고요.

    • ✅ GPU 메모리 효율성: QLoRA 덕분에 적은 GPU 자원으로도 거대 모델을 파인튜닝할 수 있게 되었습니다. 저처럼 홈랩을 운영하는 분들에게는 정말 큰 축복이에요!
    • ✅ 빠른 모델 학습: 전체 모델을 학습하는 대신 소수의 파라미터만 학습하여 시간을 절약할 수 있습니다.
    • ✅ 저장 및 배포 용이성: 학습된 LoRA 어댑터는 크기가 매우 작아서 관리하고 공유하기가 훨씬 편해요.

    물론, 이 과정에서 수많은 삽질과 시행착오가 있었지만, 결국 원하는 결과를 얻었을 때의 뿌듯함은 정말 대단했습니다. 여러분도 저의 경험이 시행착오를 줄이는 데 도움이 되기를 바라요.

    이제 여러분은 나만의 특화된 LLM을 만들 수 있는 강력한 도구를 손에 넣으신 거예요. 다음 단계로는 더 다양한 데이터셋으로 실험해보거나, Mistral, Gemma 같은 다른 오픈소스 LLM에 적용해보는 것도 정말 좋은 도전이 될 거예요. 궁금한 점이나 추가로 다루었으면 하는 주제가 있다면 언제든지 댓글로 남겨주세요! 다음 글에서는 이렇게 파인튜닝된 모델을 실제 서비스에 배포하는 과정에 대해 다뤄볼까 합니다. 기대해주세요!

    LoRA와 QLoRA의 주요 장점과 고려 사항을 요약한 인포그래픽입니다.