집의 본체를 사무실에서 부르는 법
— 집의 본체를 사무실에서 부르는 법
지난 편까지 ATOM 위에서 첫 AI 이미지를 만들어보고, 코드 한 줄의 의미까지 파헤쳐봤습니다. 그런데 며칠 지나니 새로운 문제가 생겼어요. 본체는 집에 있는데, 저는 매일 사무실에서 출근한다는 것.
오늘 글은 그 문제를 해결한 이야기입니다. 단순한 원격 접속 가이드는 아니에요. 그 과정에서 “서버라는 게 도대체 뭔가” 를 손으로 깨달은 기록이기도 합니다.
시작하며: 700만 원짜리를 매일 들고 다닐 수는 없어서
처음에는 진지하게 고민했어요. 본체가 1리터 우유팩만 한 크기라 충분히 들고 다닐 수 있을 정도거든요. 그런데 막상 들고 출근하려니 손이 떨립니다. 700만 원짜리예요. 지하철에서 한 번 떨어뜨리면 그걸로 끝입니다. 어디 부딪히기라도 하면…
그러던 중에 들은 말이 있었어요.
“이런 기계는 원격으로 쓰는 거야.”
저는 처음엔 무슨 말인지 잘 와닿지 않았어요. AnyDesk나 TeamViewer 같은 거 비슷한 거 아닌가? 그러면 사무실에서 ATOM의 우분투 화면이 그대로 뜨겠지? 정도로 생각했죠.
알고 보니 그건 큰 오해였습니다. 그리고 그 오해를 푸는 과정이 이번 편의 진짜 주제예요.
첫 오해: “화면이 그대로 뜨는 거 아니에요?”
NVIDIA가 DGX Spark 시리즈(ATOM도 여기 속합니다)를 위해 공식적으로 추천하는 원격 접속 방식은 두 가지 도구의 조합입니다.
- NVIDIA Sync - NVIDIA가 만든 원격 관리 앱
- Tailscale - 두 기기를 마치 같은 네트워크에 있는 것처럼 묶어주는 도구
이 둘을 깔면 사무실에서 집의 본체에 접속할 수 있다고 해요. 그래서 처음엔 이렇게 상상했어요.
사무실 PC를 켠다 → NVIDIA Sync를 클릭한다 → 집의 ATOM의 검은 우분투 바탕화면이 사무실 모니터에 그대로 뜬다.
그런데 실제로는 그렇지 않습니다. 화면을 통째로 가져오는 게 아니에요.
그럼 뭐냐. 비유로 정리하면 이래요.
| AnyDesk / TeamViewer | NVIDIA Sync 방식 | |
|---|---|---|
| 비유 | TV로 본체 화면을 실시간 중계 | 본체 안의 앱들을 사무실 PC 창으로 따로 띄우기 |
| 데이터 양 | 화면 픽셀 전체 (큼) | 명령어와 텍스트만 (작음) |
| 속도 | 네트워크 따라 끊김 | 안정적, 빠름 |
| 본체 화면 자체 | ✅ 보임 | ❌ 안 보임 |
NVIDIA Sync는 본체 안에서 돌아가는 개별 앱들 (터미널, JupyterLab, DGX Dashboard, VS Code 같은 IDE) 을 사무실 PC 화면에 따로따로 띄워주는 방식이에요.
사무실 PC는 일종의 창구 역할만 하고, 진짜 GPU 연산은 집의 본체가 합니다. 그 결과만 사무실 PC 화면에 텍스트로 나타나요.
이 차이는 단순한 구현 방식의 차이가 아니에요. AI 인프라가 원래 어떻게 굴러가는지를 보여주는 핵심 개념입니다. 글의 마지막에 다시 돌아올 거예요.
비대칭의 미학 - 양쪽 끝을 따로 세팅한다
여기서 또 헷갈렸어요.
“그럼 사무실 PC에 NVIDIA Sync 깔러 출근할 때 ATOM도 같이 들고 가야 하나? 둘이 만나서 처음 인증해야 할 거 아니야?”
결론부터 말하면 아니었습니다. 본체를 어디로 옮길 필요가 없어요.
세팅은 양쪽에서 따로따로 진행됩니다.
- 집에서 - ATOM 본체에 Tailscale을 깔고 본인 계정으로 로그인. 본체는 그 자리에 그대로 두고 전원만 켜놓는다.
- 사무실에서 - 윈도우 PC에 Tailscale + NVIDIA Sync를 깔고, 같은 계정으로 로그인. 그러면 알아서 본체를 찾아 연결한다.
두 기기가 같은 Tailscale 계정으로 로그인하기만 하면, 둘은 마치 같은 와이파이에 붙어있는 것처럼 서로를 찾을 수 있게 됩니다. 꽤 떨어진 집 ↔ 사무실 사이가, 네트워크 관점에서는 같은 방 안에 있는 거나 마찬가지가 되는 거예요.
이게 Tailscale의 정체입니다. 일종의 사설 가상 네트워크. 인터넷 위에 본인만 쓸 수 있는 작은 사설망을 깔아주는 도구예요.
변호사 마인드 한마디: 이게 처음에 안 와닿았던 이유는 “물리적 거리”와 “네트워크 거리”를 동일시했기 때문이에요. 실제로는 다릅니다. 집의 본체와 사무실 PC는 물리적으로는 멀어도지만 Tailscale 위에서는 0km에요.
첫 명령어와 첫 의문 - curl ... | sh 해부하기
집에서 본체에 Tailscale을 까는 첫 명령어가 이거였어요.
curl -fsSL https://tailscale.com/install.sh | sh
3편에서 코드 한 줄을 의심하면서 읽었던 것처럼, 이 한 줄도 그냥 지나치기 아쉬워서 풀어봤어요.
각 부분이 뭔지 정리하면,
curl: URL로 뭔가를 가져오는 도구 (브라우저의 텍스트 버전이라고 생각하시면 돼요)-fsSL: 옵션 4개의 조합-f(fail): 서버가 에러 응답하면 그냥 조용히 실패하라-s(silent): 진행률 표시 끄기-S(show error): 그래도 진짜 에러는 보여줘라-L(location): 서버가 리다이렉트하면 따라가라
https://tailscale.com/install.sh: 받아올 설치 스크립트 주소|(파이프): 왼쪽 명령어의 결과물을 → 오른쪽 명령어에 흘려보내는 연결관sh: 그걸 그대로 실행하는 셸
풀어 말하면 “Tailscale 서버에서 설치 스크립트를 받자마자 곧바로 셸에 흘려보내 실행시켜라” 가 됩니다.
다운 → 확인 → 실행 3단계를 한 방에 처리하는 효율적인 방식이에요. 다만 변호사로서 한 가지 짚고 싶은 점이 있어요. 이 방식은 편리하지만 보안 관점에서 완전히 깔끔하진 않습니다. 뭐가 들었는지 확인 안 한 채 그대로 실행하는 거니까요.
신뢰하는 출처(공식 도메인)일 때만 쓰는 게 좋다는 점, 그리고 더 꼼꼼하게 하려면 이렇게 분리할 수도 있다는 점, 알아두면 좋아요.
curl -fsSL https://tailscale.com/install.sh -o install.sh
cat install.sh # 내용을 직접 읽어본 다음
sh install.sh # 실행
여담으로, 이 과정에서 리눅스가 대소문자를 빡세게 구분한다는 걸 실감했어요. 위 옵션 -fsSL에서 -s와 -S는 완전히 다른 옵션이에요. 윈도우라면 둘 다 같은 거로 쳤을 텐데, 리눅스는 별개로 취급합니다. 파일명, 명령어, 사용자명 모두 마찬가지예요. Documents와 documents는 다른 폴더로 인식됩니다. 작은 디테일이지만, 익숙해지는 데 며칠 걸렸어요.
첫 위기 - “Active: dead”
설치 후 본체의 SSH 서비스가 켜져 있는지 확인하는 단계가 있었어요.
sudo systemctl status ssh
여기서 Active: active (running)이 떠야 정상이라고 했는데, 제 화면에는 Active: inactive (dead) 가 떴습니다.
“어, dead라고? 죽었다고? 내가 뭔가 잘못한 건가?”
조사해보니 이게 DGX Spark 계열에서 꽤 흔한 이슈더라고요. SSH라는 게 설치는 돼있는데 활성화는 안 된 상태로 출고된 거예요. “프로그램은 깔려있지만 자동 실행은 꺼둔” 상황입니다.
왜 그럴까? 보안 철학 때문이에요. SSH는 외부에서 접속을 받는 문이라, 사용자가 인지하지 못한 채 켜져있으면 위험할 수 있어요. 그래서 우분투/DGX OS는 “필요한 사람이 직접 켜라”는 정책으로 깔아두기만 하고 비활성 상태로 놔둡니다.
해결은 명령어 한 줄로 끝났어요.
sudo systemctl enable --now ssh
enable은 “앞으로 부팅할 때마다 자동 시작”이고, --now는 “지금 당장도 켜라”는 뜻입니다. 두 가지를 한 번에 처리하는 거예요.
다시 status를 보니 이번엔 Active: active (running). 초록 점이 떴어요. 첫 서비스를 손으로 켠 순간이었습니다.
작은 일 같지만 저한테는 의미 있었어요. “서비스(service)” 라는 개념을 처음으로 체감한 거예요. 리눅스에는 백그라운드에서 항상 돌면서 외부 요청을 기다리는 프로그램들이 있고, 이게 다 systemctl로 관리됩니다. SSH도 그중 하나일 뿐이에요. 나중에 Open WebUI, Ollama, OpenClaw 같은 걸 띄울 때도 같은 개념이 반복됩니다. 한 번 익혀두면 평생 써요.
그리고 폰에서도 됐다 - SSH가 정말 뭔지 깨달은 순간
세팅이 끝난 다음, 검증 차원에서 폰에 Tailscale 앱을 깔아봤어요. 그리고 Termius 라는 SSH 클라이언트 앱을 추가로 설치했죠.
폰에서 본체 IP를 입력하고 Connect를 누르니, 검정 화면에 익숙한 프롬프트가 떴습니다.
rocklassic@rocklassic:~$
집에 있는 700만 원짜리 슈퍼컴퓨터가, 제 손바닥 안의 폰 화면에 응답한 거예요. 명령어 한 줄을 치면 그쪽 GPU가 움직입니다.
이게 진짜 신기했어요. 그리고 동시에, 그동안 헷갈렸던 모든 개념이 한 번에 정리되는 순간이었습니다.
“아, 서버라는 게 이거구나.”
생각해보면, 그동안 “서버”라는 말을 막연하게 썼어요. 큰 회사들이 데이터센터에 두는 특별한 기계, 정도로 어렴풋이 이해했죠. 그런데 막상 보니까 서버는 특별한 기계가 아니에요.
서버 = 다른 컴퓨터가 접속해서 일을 시키는 컴퓨터.
물리적으로는 그냥 컴퓨터입니다. 우리가 쓰는 노트북이랑 본질적으로 같아요. 다만,
- 24시간 켜져 있고
- 인터넷에 노출되어 있고
- 다른 기기가 접속할 수 있게 SSH 같은 게 열려 있고
- 보통은 화면(GUI) 없이 헤드리스(headless)로 돌아간다
이 조건만 갖추면 어떤 컴퓨터든 서버가 됩니다. 우리 집의 본체도 어제까지는 그냥 “비싼 PC”였는데, Tailscale + SSH를 켠 순간부터 서버가 된 거예요.
그러고 보니 일상에서 우리가 “사용한다”고 생각하는 서비스들도 다 이 구조예요.
- 인스타를 본다 → 인스타 서버에 접속한 거
- 유튜브를 본다 → 유튜브 서버에서 영상을 가져오는 거
- 카톡 메시지를 보낸다 → 카톡 서버를 거쳐서 가는 거
- 폰에서 ATOM에 접속한다 → ATOM이 그 순간 서버가 된 것
그리고 코랩(Google Colab)도 똑같은 원리입니다. 구글이 데이터센터에 GPU 잔뜩 꽂은 서버를 수만 대 돌려놓고, 사용자가 브라우저로 접속하면 그중 한 대를 잠깐 빌려주는 거예요. 제가 집에 만든 건 그 1인용 축소판이었던 거고요.
| 코랩 | 우리집 ATOM 셋업 | |
|---|---|---|
| 서버 위치 | 구글 데이터센터 (미국) | 우리집 |
| 서버 대수 | 수만 대 | 1대 |
| 사용자 수 | 전 세계 수백만 명 | 저 혼자 |
| GPU 공유 | 다른 사람과 나눠 씀 | 100% 제 거 |
| 끊김 | 12시간 후 자동 종료 | 본체 안 끄면 안 끊김 |
| 데이터 보안 | 구글 서버에 올라감 | 집 안에서만 처리 |
| 비용 | 월 구독료 | 전기료만 |
변호사 입장에서 가장 끌리는 항목이 보이시죠. “데이터 보안” 행. 이게 처음부터 제가 로컬을 택한 이유였습니다.
사소한 함정 - NVIDIA Sync 키는 만료된다
세팅이 끝나고 며칠은 평화로웠어요. 사무실에서 NVIDIA Sync 한 번 클릭하면 본체가 손에 잡혔거든요.
그런데 어느 날 갑자기 빨간 에러가 떴어요.
Unexpected Error: not connected
check logs at C:\Users\user\AppData\Local\NVIDIA Corporation\Sync\logs\nvsync.log
처음에는 멘붕이었어요. “어제까지 잘 되던 게 왜?”
로그 파일을 열어보니 이런 메시지가 있더라고요.
ssh: handshake failed: EOF
해석하면 “본체까지 가는 통신은 됐는데, 인증 단계에서 본체가 응답을 끊었다” 라는 뜻이에요. 이상하죠. 같은 시간에 폰 Termius로는 접속이 됐거든요.
조사해보니 원인은 이랬어요.
NVIDIA Sync는 자기 전용 Tailscale 노드를 따로 만들어서 동작합니다. 그런데 이 노드의 인증 키가 주기적으로 만료돼요. 며칠 ~ 몇 주에 한 번씩 재인증을 받아야 합니다. 본체나 폰의 키는 영구 유지인데, NVIDIA Sync 자체 노드만 만료되는 구조예요.
해결책은 두 단계로 정리됐어요.
1) 당장 - NVIDIA Sync에서 본체를 한 번 삭제했다가 다시 추가하기
NVIDIA Sync 안의 SSH 키 캐시를 초기화하는 가장 깔끔한 방법이었어요. 어제 했던 세팅을 5분만에 반복하는 셈입니다.
2) 앞으로 - Tailscale 콘솔에서 “Disable key expiry” 설정하기
Tailscale 웹 콘솔(login.tailscale.com/admin/machines)에서 각 기기 옆 ... 메뉴를 누르면 “Disable key expiry” 옵션이 있어요. 이걸 켜두면 그 기기의 키가 무기한 유지됩니다.
특히 본체에는 꼭 해두시는 걸 추천해요. 본체 키가 풀리면 결국 집에 가서 직접 재인증해야 하니까요.
사고를 통한 진짜 학습 - 로그를 읽는 법
이 사고를 겪으면서 부수적으로 배운 게 있어요. “로그를 읽는다” 는 행위 자체예요.
nvsync.log 파일을 열어보니 처음엔 그냥 영문 글자가 잔뜩 나열돼 있어서 막막했어요. 그런데 시간 순서대로 차근차근 읽어보니 사건의 전말이 보였습니다.
어제 16:38 → 정상 접속
어제 16:42 → "Broken pipe" (PC 종료/슬립으로 연결 끊김)
오늘 08:42 → "keepalive failed" (재접속 시도)
오늘 08:42~ → "handshake failed: EOF" (반복 실패)
서버 다루는 분들이 “로그 봐” 라고 말하는 게 무슨 의미였는지 그제서야 알겠더라고요. 로그는 시스템의 일기장이에요. 무슨 일이 언제 일어났는지 적혀 있고, 거기서 단서를 찾는 게 트러블슈팅의 기본이었습니다.
변호사로서는 익숙한 작업이에요. 사건 일지를 시간순으로 정리하고, 어디서 일이 꼬였는지 찾아내는 거잖아요. 사건 기록의 형식만 다를 뿐, 본질은 같았어요.
마무리: 책상 위 컴퓨터가 진짜 서버가 된 날
오늘 배운 것 정리해보면,
- ✅ NVIDIA Sync는 화면 미러링이 아니라, 본체 안의 앱을 사무실 PC 화면으로 띄워주는 방식입니다
- ✅ Tailscale은 두 기기를 같은 사설망에 묶어주는 도구. 물리적 거리와 무관해집니다
- ✅ SSH는 “다른 컴퓨터를 안전하게 원격 조종하는 표준 방법”. 인프라의 가장 밑바닥에 있습니다
- ✅ 서버는 특별한 기계가 아닙니다. 24시간 켜두고 외부 접속을 받는 컴퓨터 = 서버
- ✅ NVIDIA Sync의 자체 노드 키는 만료되니, “Disable key expiry”를 켜두면 마음 편합니다
- ✅ 트러블슈팅의 시작은 로그를 읽는 것. 변호사가 사건 일지를 보는 것과 같은 작업이에요
오늘 글에서 가장 강조하고 싶은 한 줄을 고른다면 이거예요.
“내 컴퓨터가 서버가 되는 순간은 따로 있다. 24시간 켜두고, 다른 기기가 접속할 수 있게 문을 여는 순간.”
이 한 마디가 머리에 박히고 나니, 그동안 막연했던 것들이 한꺼번에 정리되기 시작했어요. AWS, Azure, GCP, 코랩, 허깅페이스, 다 같은 원리예요. 누군가 자기 서버를 24시간 켜놓고, 우리는 접속해서 빌려 쓰는 거. 저는 집에 그 1인용 미니 버전을 만든 것뿐입니다.
요즘 데이터센터, HBM 메모리, 전력 반도체 같은 키워드가 자주 들리잖아요. 그게 다 “거대한 서버 농장을 짓는 산업”이에요. AWS와 구글과 마이크로소프트가 집의 본체 같은 걸 수십만 대 단위로 짓고 있는 것이고, 거기 들어가는 부품 회사들이 다 수혜주죠.
오늘 직접 서버 한 대를 운영해본 게, 사실 그 거대한 산업의 작동 원리를 손으로 체감한 것이기도 합니다. 변호사가 이런 직관을 얻기는 쉽지 않은데, ATOM 한 대로 책상 위에서 가능해진 거예요.
미리 드리는 팁 - 이걸 따라하시려는 분들께
다음 편으로 넘어가기 전에, 이 시리즈를 보면서 본인도 원격 접속을 세팅하려는 분들을 위해 핵심만 정리해드릴게요.
본체(집)에서 할 일
# 1) Tailscale 설치
curl -fsSL https://tailscale.com/install.sh | sh
# 2) Tailscale 로그인 + SSH 통합 옵션
sudo tailscale up --ssh
# 3) Tailscale IP 확인 (메모해두기)
tailscale ip -4
# 4) SSH 서비스 활성화
sudo systemctl enable --now ssh
# 5) 본체는 끄지 말고 그대로 두기
사무실 PC(또는 노트북)에서 할 일
- Tailscale 윈도우 클라이언트 설치 → 같은 계정으로 로그인
- NVIDIA Sync 윈도우 클라이언트 설치
- NVIDIA Sync에서 본체 추가 (집에서 메모한 Tailscale IP, 본체 사용자명, 비밀번호 입력)
- Connect 클릭
잊지 말 것
- Tailscale 콘솔에서 본체 노드 옆
...→ “Disable key expiry” 켜두기 - 본체에 정전 시 자동 부팅되도록 BIOS 옵션 켜두면 안전합니다
- 폰에도 Tailscale + Termius 같은 SSH 앱 깔아두면 백업 플랜으로 좋아요
마치며
이번 편은 단순히 “원격 접속 세팅하는 법”을 적은 글이 아니었어요. “내 책상 위 컴퓨터가 어느 순간 서버가 되더라” 라는 깨달음의 기록이었습니다.
변호사가 IT 인프라 개념을 손으로 익힐 일이 평생 몇 번이나 있을까요. 저는 이번에 ATOM 덕분에 한 번 한 셈이에요. 그리고 이게 앞으로 다룰 모든 주제(Open WebUI, Ollama, OpenClaw, 모바일에서 LLM 부르기)의 토대가 됩니다. 전부 다 “내 서버를 띄우고 거기에 접속한다” 의 변주일 뿐이거든요.
다음 편에서는 본격적으로 본체 위에 로컬 LLM 서비스를 띄워봅니다. Docker라는 도구로 ChatGPT 비슷한 인터페이스를 ATOM 위에 깔고, 어디서든 폰으로도 그 LLM과 대화할 수 있게 만드는 이야기예요. 그 과정에서 컨테이너라는 또 하나의 큰 개념을 만나게 됩니다.
읽어주셔서 감사합니다. 🙂
다음 편: “내 책상 위의 ChatGPT - Docker로 Open WebUI 띄우기”