🗄️ 나스와 AI 서버를 한 대에 합쳤습니다 — 부품보다 먼저 정해야 했던 것

집에 나스가 한 대 돌고 있었습니다. 하드 8개에 데이터가 들어 있었고 별문제 없이 쓰던 물건이었어요. 여기에 로컬 AI를 돌려보고 싶어졌는데, 그렇다고 서버를 한 대 더 놓자니 전기도 자리도 아깝더라고요. 그래서 한 대에 합치기로 했습니다. 결과부터 말하면 합치는 일 자체는 어렵지 않았고, 어려운 건 무엇을 어디에 넘길지 먼저 정하는 일이었습니다.

요구사항이 정반대인 둘을 한 상자에 넣는 법

나스와 AI 서버는 성격이 정반대입니다. 나스는 24시간 조용히 안정적으로 돌아야 하고, AI는 쓸 때만 자원을 몰아 쓰다가 나머지 시간엔 놀아도 됩니다. 이 둘을 한 운영체제에 섞으면 한쪽 문제가 다른 쪽을 죽입니다. 모델 하나 잘못 올려서 메모리가 터졌는데 가족 사진이 든 나스까지 같이 멈추는 상황은 피하고 싶었어요.

그래서 가상화를 골랐습니다. 호스트에 Proxmox를 깔고, 나스도 게스트, AI도 게스트로 올리는 구조입니다.

Proxmox (호스트)
├── VM  나스        하드 8개
├── VM  AI          GPU
└── LXC 미디어 서버  내장 그래픽

한 상자 안에 있지만 서로 격리됩니다. AI 쪽에서 뭘 잘못해도 나스는 계속 돕니다. 실제로 AI 게스트를 여러 번 재시작했는데 나스는 한 번도 영향받지 않았어요.

부품을 사기 전에 그려야 했던 그림

여기서 핵심이 하나 있습니다. GPU는 나눠 쓸 수 없지만 내장 그래픽은 나눠 쓸 수 있습니다.

GPU를 게스트에 넘기는 방식(패스스루)은 장치를 통째로 하나에게 주는 겁니다. 반씩 나눠주는 선택지가 없어요. 반면 CPU에 붙어 있는 내장 그래픽은 여러 컨테이너가 동시에 붙어 쓸 수 있습니다.

이 비대칭이 구조 전체를 결정했습니다.

• 무거운 AI 작업 → GPU를 독점하는 가상머신 하나에 몰아넣기
• 가벼운 영상 트랜스코딩 → 내장 그래픽을 공유하는 가벼운 컨테이너로

미디어 서버 트랜스코딩을 GPU에 맡기고 싶은 유혹이 있었는데, 그러면 AI 작업 중엔 영상을 못 봅니다. 내장 그래픽으로 넘기니 둘이 동시에 돌아가요. 영상 트랜스코딩은 내장 그래픽 쪽이 전력 효율도 낫고요.

이걸 나중에 깨달으면 케이블부터 다시 꽂아야 합니다. 부품 목록보다 배치도를 먼저 그리는 게 순서였습니다.

용량이 모자란 게 아니라 위치가 잘못된 것이었습니다

시스템 디스크를 120GB짜리 SSD 두 장으로 묶었습니다. 안정성을 위해 미러 구성으로 잡은 건데, 여기서 고민이 하나 생겼어요. AI 모델을 여러 개 쓸 텐데 120GB로 되겠나 싶었거든요.

답은 디스크를 키우는 게 아니었습니다. 모델을 다른 데 두면 됩니다. 나스 공유 폴더에 모델을 올려두고 AI 게스트에 마운트해서 쓰면, 시스템 디스크는 시스템만 담으면 돼요. 실제로 지금 모델 저장소는 전부 나스에 있습니다.

시스템 디스크는 용량보다 죽지 않는 것이 중요합니다. 여기가 죽으면 게스트 전부가 멈추니까요. 용량이 필요한 건 언제든 다시 받을 수 있는 모델 파일이고, 그건 다른 데 두면 그만입니다. 홈서버에서 부딪히는 용량 문제는 대개 “더 큰 디스크”가 아니라 “다른 위치”로 풀립니다.

가장 무서웠던 단계 — 하드 8개를 데이터째 옮기기

전제 조건이 하나 있었습니다. 하드 8개의 데이터는 반드시 살려야 한다. 이 제약이 자유도를 크게 줄였지만, 초반에 못 박아둔 덕에 설계가 흔들리지 않았습니다.

원리는 생각보다 단순했어요. 나스 운영체제는 볼륨 구성 정보를 부팅 디스크가 아니라 데이터 디스크 안에 저장합니다. 그래서 기존과 같은 조건만 재현하면 디스크를 그대로 읽어냅니다. 맞춰야 할 건 세 가지였습니다.

• 기종과 버전을 동일하게 — 바꾸고 싶은 유혹이 들지만 이 단계에선 바꾸지 않는 게 최선입니다
• 디스크 순서와 최대 디스크 수 — 8개를 쓰려면 인식 가능한 슬롯 수부터 늘려놔야 합니다
• 마이그레이션 화면에서 설정 유지 선택 — 이 화면이 뜨는 게 정상입니다

부팅했더니 “돌아오신 것을 환영합니다”가 떴고, 볼륨 8개가 전부 그대로였습니다. 서버 이름까지요.

두 가지는 꼭 챙기시길 권합니다. 첫째, 초기화 유혹을 참으세요. 중간에 디스크를 초기화하겠느냐는 화면이 나올 수 있는데 한 번 누르면 끝입니다. 조금이라도 이상하면 멈추고 확인하는 게 맞습니다. 둘째, 넘기기 전에 원래 상태를 기록해두세요. 저는 디스크 시리얼과 용량, 사용 시간을 전부 적어뒀습니다.

lsblk -o NAME,SIZE,MODEL,SERIAL
for d in /dev/sd?; do echo "== $d"; smartctl -i -A "$d" | head -30; done

문제가 생겼을 때 무엇이 원래 상태였는지 알 수 있어야 하니까요. 이 단계만큼은 자동화하지 말고 한 단계씩 눈으로 확인하는 편이 낫습니다.

이론적 우려보다 강한 증거

작업하면서 제가 틀린 순간도 있었습니다. 가상머신 안의 나스에서 내장 그래픽을 쓰는 건 어려울 거라고 지레 걱정했는데, 알고 보니 같은 CPU로 예전에 이미 잘 쓰고 있던 환경이었어요.

기존에 돌아가던 걸 재현하는 작업에서는 “원래 되던 것”이 가장 강한 증거입니다. 이론적으로 안 될 것 같다는 판단보다 실제 이력이 우선해요. 홈서버는 남의 구성을 그대로 따라 하기 어려운 영역이라, 자기 환경의 이력을 신뢰하는 편이 대체로 맞았습니다.

정리

서버 두 대를 한 대로 합치는 일은 부품을 고르는 문제가 아니었습니다. 요구사항이 정반대인 둘을 격리해서 얹고, 나눠 쓸 수 있는 자원과 없는 자원을 구분해 배치하고, 절대 잃으면 안 되는 것을 먼저 못 박는 순서였어요.

정리하면 세 문장입니다. 부품 목록보다 배치도를 먼저 그린다. 용량 문제는 위치로 푼다. 데이터 보존이 목표라면 바꾸지 않는 것이 최선이다. 이 셋을 먼저 정하고 나니 나머지는 조립이었습니다.