1인 연구소 개발 환경 — GPU 두 대와 맥미니, 그리고 사흘간 검은 사각형만 나온 이야기
1인 연구소인데 컴퓨터가 세 대가 됐습니다
혼자 하는 연구소입니다. 사람은 한 명인데 컴퓨터는 계속 늘어요. 지금 한 대로 돌리고 있고, 두 번째를 준비 중이고, 세 번째까지 계획에 들어와 있습니다.
허영으로 늘리는 게 아닙니다. 하나씩, 아주 구체적인 이유가 있어서 늘어났어요. 오늘은 그 이유들을 순서대로 풀어보려고 합니다. 스펙 자랑이 아니라 왜 이렇게 됐는지에 대한 이야기예요.
지금 돌고 있는 한 대
작업 PC 겸 서버, 이름은 SAW1입니다. 라이젠 7800X3D에 DDR5 32GB, 그래픽카드는 RTX 5060 Ti 16GB.
게임용으로 보면 과하지 않은 구성이에요. 그런데 이 한 대가 지금 블로그 글을 읽고, 대본을 만들고, 이미지를 그리고, 음성을 합성하고, 영상을 조립하고, 유튜브에 올리는 일을 전부 합니다.
이 컴퓨터가 하루에 하는 일
고스트 블로그에 글이 올라오면 그걸 영상으로 만듭니다. 원문을 가져와 인터뷰 형식 대본으로 바꾸고, 장면마다 이미지를 생성하고, 두 명의 목소리로 나레이션을 만들고, 자막과 챕터를 붙여 조립한 뒤 유튜브에 롱폼과 쇼츠 세트로 올려요.
말로 하면 한 문단인데, 실제로는 한 편에 스무 개 넘는 단계가 있습니다. 그리고 그중 대부분이 그래픽카드를 씁니다.

시간이 어디로 가는지 재봤습니다
감으로 짐작하지 말고 실제로 재보기로 했어요. 영상 한 편당 소요 시간입니다.
음성 합성 30~40분 / 이미지 생성 13분 / 영상 조립 10분.
숫자를 보고 나서야 알았습니다. 제가 그동안 신경 쓰던 건 이미지 쪽이었는데, 정작 시간을 먹고 있던 건 음성이었어요.
병목은 늘 생각한 곳에 있지 않습니다
이미지 생성은 화려합니다. 진행 상황이 눈에 보이고, 결과물이 예쁘고, 잘못되면 바로 티가 나요. 그래서 자꾸 그쪽을 들여다보게 됩니다.
음성 합성은 조용합니다. 로그 몇 줄이 지나갈 뿐이에요. 그런데 시간의 절반 이상을 거기서 씁니다.
재보기 전까지는 몰랐습니다. 측정하지 않으면 눈에 띄는 것을 병목이라고 착각합니다.

16GB라는 벽
그래픽카드 메모리가 16GB입니다. 넉넉해 보이지만, 이미지 생성 모델과 음성 합성 모델을 동시에 올리면 금세 빠듯해져요.
여기서 재미있는 선택이 하나 생깁니다. 같은 모델을 정밀도를 낮춰 쓰면 메모리를 절반으로 줄일 수 있거든요.
절반짜리 정밀도를 쓰는 이유
이미지 모델을 기본 정밀도로 올리면 11.5GB를 씁니다. 낮춘 정밀도로 올리면 5.8GB예요.
품질 차이는 거의 없습니다. 대신 텍스트 인코더까지 같이 올려둘 수 있게 됩니다. 이게 결정적이에요. 둘이 함께 상주하면 장면마다 모델을 밀어내고 다시 불러오는 일이 사라지거든요.
장면 하나 그리는 데 8초인데, 모델을 다시 올리는 데는 1~2분이 걸립니다. 밀어내기가 한 번 생기면 그 장면만 열 배 넘게 느려져요. 정밀도를 낮춘 건 화질을 포기한 게 아니라 밀어내기를 없앤 선택이었습니다.

그래서 맥미니는 후보에서 빠졌습니다
세 번째 머신으로 맥미니를 잠깐 고민했어요. 조용하고, 전기를 적게 먹고, 통합 메모리 16GB면 될 것 같았거든요.
그런데 방금 말한 낮은 정밀도 형식이 엔비디아 전용입니다. 맥에서는 기본 정밀도로 가야 하고, 그러면 모델만 11.5GB예요. 통합 메모리는 운영체제와도 나눠 쓰니 텍스트 인코더가 들어갈 자리가 없습니다.
즉 맥미니로 이미지를 뽑으면 매 장면마다 모델을 다시 올리게 됩니다. 계산해보고 바로 접었어요.
대신 맥미니가 잘하는 일이 있었습니다
그런데 용도를 바꿔 생각해보니 답이 나왔습니다. 그림 그리는 모델은 안 맞지만 언어 모델을 돌리는 데는 잘 맞아요.
12B 크기 모델을 압축해 올리면 7~8GB입니다. 16GB 통합 메모리에 여유 있게 들어가고, 애플 쪽 가속도 이 분야는 훨씬 성숙합니다.
같은 기계를 두고 안 된다와 좋다가 갈렸습니다. 기계가 문제가 아니라 무엇을 시킬지가 문제였어요.

사흘 동안 검은 사각형만 나온 이야기
여기서 이번 주에 겪은 사건을 하나 풀어놓을게요.
어느 날부터 이미지가 전부 새까맣게 나왔습니다. 완전한 검정. 오류는 하나도 없었어요. 로그에는 성공이라고 찍히고 파일도 정상적으로 생깁니다. 열어봐야 검은 사각형인 걸 압니다.
로그가 정상이라 더 어려웠습니다
실패했다고 말해주면 차라리 쉽습니다. 성공했다고 말하면서 잘못된 결과를 주는 게 제일 곤란해요.
그래서 이후로는 이미지를 뽑을 때마다 픽셀 평균값을 찍어봅니다. 0이면 검정이에요. 눈으로 훑는 것보다 확실합니다.

범인이 버전 업그레이드인 줄 알았습니다
기록을 보니 며칠 전에 이미지 프로그램이 새 버전으로 올라가 있었습니다. 답이 나온 줄 알았어요.
그런데 정작 제 기억으로는 버전을 건드린 적이 없었습니다. 기록과 기억이 정면으로 충돌했어요.
파일 시각을 나란히 놓고 보니
업그레이드 시각은 오전 6시 11분이었습니다. 그런데 정상 이미지가 마지막으로 나온 건 오후 12시 33분이었어요. 여섯 시간 넘게 멀쩡했던 겁니다.
첫 검정 이미지는 12시 36분. 그 3분 사이에 무슨 일이 있었을까요.
재기동한 순간에 바뀝니다
12시 6분에 실행 스크립트가 수정돼 있었습니다. 출력 폴더를 다른 드라이브로 옮기는 작업이었어요. 그걸 반영하려면 프로그램을 다시 켜야 합니다.
그 재기동이 바로, 여섯 시간 전에 올라간 새 버전을 처음으로 불러온 순간이었습니다.
파일은 6시에 바뀌었지만 프로그램은 12시 35분에 바뀐 거예요. 돌고 있던 프로세스는 옛 코드를 메모리에 붙들고 태연히 잘 돌아가고 있었습니다.

두 기억이 모두 맞았습니다
버전이 바뀌었다도 맞고, 나는 안 건드렸다도 맞았어요. 폴더를 옮긴 것도 무죄였습니다. 그건 방아쇠였을 뿐 총알이 아니었거든요.
여기서 하나 배웠습니다. 서비스는 파일을 바꾼 시점이 아니라 재기동한 시점에 바뀝니다. 업그레이드하고 아무 일 없다고 안심하면 안 돼요. 다음 재기동이 진짜 첫 검증입니다.
고장 시각은 산출물로 특정하세요
이 사건을 푼 결정적 방법은 단순했습니다. 결과물 파일을 시간순으로 늘어놓고 픽셀값을 찍은 것이에요. 마지막 정상과 첫 이상 사이가 3분으로 좁혀지니, 그 사이에 뭘 건드렸는지 찾는 건 쉬웠습니다.
로그를 뒤지는 것보다 정확했어요. 로그는 계속 정상이라고 말하고 있었으니까요.

조용히 사라지는 서비스
다른 문제도 있었습니다. 음성 합성 서버가 작업 도중에 사라집니다. 91번째 문장에서 한 번, 다음 날 50번째 문장에서 또 한 번.
크래시 로그가 없어요. 이벤트 기록에도 아무것도 안 남습니다. 프로세스만 없어져 있어요. 이틀 동안 원인을 못 찾았습니다.
두 개가 함께 죽으면서 정체가 드러났습니다
그러다 세 번째에는 음성 서버와 이미지 서버, 그리고 작업 관리자까지 동시에 죽었습니다. 하나가 아니라 셋이 같이 죽으니 공통 원인이 있다는 뜻이었어요.
이벤트 기록을 그 시각으로 좁혀 보니 있었습니다. LiveKernelEvent 141.

그래픽 드라이버가 리셋되고 있었습니다
141은 화면 드라이버 타임아웃 복구를 뜻합니다. 드라이버가 응답을 못 하면 운영체제가 강제로 재설정하는 기능이에요.
그런데 드라이버가 리셋되면 그 위에서 돌던 계산이 전부 무효화됩니다. 그래서 그래픽카드를 쓰던 프로세스가 하나씩이 아니라 한꺼번에 죽어요. 앞의 두 번은 이미지 서버가 놀고 있어서 음성만 죽은 것처럼 보였을 뿐이었습니다.
하루에 55번
혹시나 해서 그날 발생 횟수를 세봤습니다. 55건이었어요. 어쩌다 한 번이 아니라 상시로 일어나고 있었던 겁니다.
재미있는 건 그래픽카드 자체는 멀쩡하다는 점이에요. 온도 34도에 정상 응답. 아프다고 말하지 않으면서 계속 넘어지고 있었습니다.
고치지 못하면 견디게 만듭니다
원인은 아직 못 잡았습니다. 드라이버일 수도, 전원일 수도 있어요. 그래서 일단 넘어져도 일어나게 만들었습니다.
작업 관리자가 연결 끊김을 감지하면 서버를 다시 띄우고 이어서 재시도합니다. 이미 만든 음성 파일은 건너뛰기 때문에 재시도 비용이 거의 없어요. 죽어도 3분 정도 손해로 끝납니다.
근본 해결은 아니지만, 고장을 못 없앨 때는 고장을 싸게 만드는 것도 방법입니다.

그래서 두 번째 머신을 들입니다
SAW2를 준비 중입니다. 7500F에 DDR5 32GB, 그래픽카드는 똑같은 5060 Ti 16GB예요.
일부러 같은 카드를 골랐습니다. 이유가 두 가지 있어요.
처음 계획은 서비스를 나누는 것이었습니다
자연스러운 발상이죠. 한 대는 이미지 전담, 한 대는 음성 전담. 각자 하나씩 맡으면 서로 안 부딪히니까요.
그런데 앞에서 잰 숫자를 다시 봤습니다.

실측이 계획을 뒤집었습니다
음성이 30~40분, 이미지가 13분입니다. 서비스별로 나누면 음성은 여전히 한 대에서만 돕니다. 전체 처리량이 거의 그대로예요.
이미 병목이 아닌 쪽만 두 배로 빨라지는 셈입니다. 그림은 그럴듯한데 효과가 없어요.
편 단위로 나누기로 했습니다
그래서 바꿨습니다. 두 대 모두 이미지와 음성을 다 올리고, 영상 한 편을 통째로 한 대에 맡깁니다.
처리량이 정직하게 두 배가 됩니다. 음성이 두 대에서 동시에 도니까요. 게다가 한 편의 모든 파일이 한 머신 안에서 완결되니 네트워크로 파일을 주고받을 일도 없어요.
덤으로, 한쪽이 드라이버 리셋으로 넘어져도 다른 편은 멀쩡합니다.

NAS에 둘 것과 로컬에 둘 것
저장소는 NAS로 모읍니다. 다만 전부 옮기면 안 돼요. 기가비트 네트워크의 실효 속도가 초당 110MB 정도라는 걸 기준으로 나눴습니다.
NAS로 갈 것 — 완성 영상, 원본 자료, 재사용하는 이미지와 영상 클립 라이브러리. 20분짜리 영상이 1GB 남짓이니 옮기는 데 10초면 됩니다.
로컬에 남길 것 — 모델 파일과 작업 폴더.
모델을 NAS에 두면 안 되는 이유
이미지 모델이 5~12GB입니다. 이걸 매번 네트워크로 읽으면 불러오는 데만 1~2분이 걸려요. 로컬 SSD면 몇 초입니다.
장면 하나 8초 뽑자고 불러오기에 2분을 쓰는 셈이 됩니다. 앞에서 밀어내기를 없애려고 정밀도까지 낮췄는데, 모델을 NAS에 두면 그 노력이 통째로 무의미해져요.

외부 접근은 한 곳으로만
맥미니가 유일한 외부 창구 역할을 합니다. 작업 머신들과 NAS는 내부망 전용으로 막아두고요.
드러난 면이 하나뿐이라는 게 이 구조의 가장 큰 장점입니다. 관리할 곳이 하나면 실수할 곳도 하나예요.
그리고 이런 원칙은 예외를 만드는 순간 무너집니다. 이것만 잠깐이 쌓이면 그냥 열려 있는 것과 같아져요.
그래픽카드를 늘려도 늘어나지 않는 것
여기서 김이 좀 새는 이야기를 해야 합니다. 기계를 두 배로 늘려도 유튜브 업로드 한도는 그대로입니다.
업로드 할당량은 채널이 아니라 클라우드 프로젝트 단위로 걸립니다. 머신을 몇 대를 쓰든 같은 주머니를 나눠 써요.
그래서 그래픽카드가 두 배가 되면 병목이 연산 시간에서 업로드 한도로 옮겨갈 가능성이 있습니다. 하나를 풀면 다음 것이 드러나는 거죠. 병목은 없어지는 게 아니라 이사를 다닙니다.

두 번째 머신은 대조군이기도 합니다
같은 그래픽카드를 고른 두 번째 이유가 이겁니다. 드라이버 리셋 문제요.
SAW2에 같은 구성을 올렸을 때 거기서도 리셋이 나면 드라이버나 이 카드 모델 공통의 문제입니다. 안 나면 지금 쓰는 카드 개체의 문제고, 전원 쪽부터 봐야 해요.
혼자 일하면 비교 대상이 없어서 원래 그런 건가 하고 넘어가기 쉽습니다. 같은 구성을 두 벌 갖는 건 성능만이 아니라 판단의 기준을 갖는 일이기도 합니다.
1인 연구소에서 배운 세 가지
장비 이야기를 길게 했지만, 정작 남는 건 장비가 아니었습니다.
하나, 재보기 전에는 모릅니다. 병목이 이미지인 줄 알았는데 음성이었어요. 눈에 띄는 것과 시간을 먹는 것은 다릅니다.
둘, 조용한 실패가 제일 비쌉니다. 검은 이미지도, 사라지는 서버도 오류를 내지 않았어요. 그래서 며칠씩 걸렸습니다. 이후로는 결과물을 직접 확인하는 관문을 넣습니다.
셋, 못 고치면 싸게 만듭니다. 드라이버 리셋은 아직 못 잡았지만, 넘어져도 3분 손해로 끝나게 만들 수는 있었어요.

핵심 정리
1인 연구소의 장비 구성은 이렇게 정리됐습니다. 작업 머신 두 대에 같은 그래픽카드를 올려 영상을 편 단위로 나눠 만들고, 맥미니는 언어 모델과 외부 창구를 맡고, NAS는 완성본과 라이브러리를 모읍니다. 모델과 작업 폴더는 각 머신 로컬에 둡니다.
그런데 이 구성보다 중요한 건 왜 그렇게 됐는가였어요. 대부분의 결정이 계획이 아니라 실측과 사고에서 나왔습니다. 서비스별로 나누려던 계획을 숫자가 뒤집었고, 사흘짜리 사고가 검증 관문을 만들었고, 원인 모를 죽음이 재시도 구조를 만들었습니다.
혼자 하는 일이라 물어볼 사람이 없습니다. 대신 기록과 측정이 동료 역할을 해줍니다. 오늘 남긴 로그가 다음 달의 저에게 답을 줄 거예요.
여러분의 작업 환경은 어떤 사고를 거쳐 지금 모양이 됐나요? 비슷한 삽질을 하고 계신다면 댓글로 들려주세요. 반갑게 읽겠습니다.
이 포스트는 Claude Cowork + SVIL Ghost MCP를 통해 AI가 직접 작성하고 발행했습니다.