맥북 개발서버와 윈도 노트북 사이의 장비 고민

28일 오후 두 시를 넘긴 더배러 대화방에 한 참가자가 갑자기 생각이 났다는 듯 장비 이야기를 꺼냈다. 가지고 있는 맥북 M1 max 64gb를 개발서버로 두고, 평소에는 윈트북 위주로 쓰고 싶다는 것이다. 윈트북은 윈도 운영체제가 깔린 노트북을 줄여 부르는 말이다. 이어서 맥미니가 아니라 맥북인 이유는 키보드와 트랙패드를 쓰려는 것이라고 덧붙였다.

갑자기 맥북 M1 max 64gb를 개발서버로 두고 윈트북 위주로 쓰고 싶네유

맥북이 아니라 윈트북 한 대가 목적이었다

다른 참가자는 이 글에 RTX spark가 사고 싶었다고 받았다. RTX spark가 어떤 제품인지는 대화에서 따로 설명되지 않았고, 이 참가자는 말끝에 윈트북이라는 말만 붙였다. 처음 글을 쓴 참가자는 약 20분 뒤 GPT와 길게 대화하고 답을 찾았다며 방향을 바로잡았다. 맥북을 개발서버로 쓰고 싶었던 것이 아니라 윈트북 하나만 들고 다니고 싶었다는 것이었다.

저는 맥북을 개발서버로 쓰고싶은 게 아니라, 윈트북 하나만 들고 다니고 싶었던 거였네유

이유는 오후 세 시 무렵 이어진 글에 있다. 만드는 서비스가 윈도 사용자를 대상으로 하기 때문에 윈트북에서의 QA, 곧 품질 점검이 필수이고, exe 설치 파일을 만들려면 어차피 윈트북에서 빌드해야 한다는 설명이다. 개발은 상시 켜 둔 맥에 맡기고 점검과 엑셀 같은 문서 작업은 윈트북에서 하면 편하겠다는 구상이었다. 지금은 맥북과 윈트북을 둘 다 들고 다니는데 힘들다고 했다.

무조건 윈트북 qa가 필요하고, exe 파일 빌드하려면 윈트북으로 어차피 해야되고요

다른 방법과 새 장비를 둘러싼 의견

같은 시각 다른 참가자가 해법을 하나 건넸다. tailscale을 쓰면 ssh로 맥북 터미널을 열어 두고 윈도우에서도 작업할 수 있다는 것이다. tailscale은 떨어진 기기끼리 사설망으로 이어 주는 서비스고, ssh는 원격에서 터미널에 접속하는 방식이다.

tailscale 사용해서 ssh로 맥북 터미널 열어놓고 윈도우에서도 작업이 가능합니다

글을 쓴 참가자는 터미널은 herdr로 쓰고 /rc로 크롬에서 작업하고 있다고 답했다. 이 방법을 쓰겠다는 말은 따로 없었다. 한편 장비 값이 화제가 되어, 같은 참가자가 당근을 보니 윈트북이 엄청 비싸다고 했고 또 다른 참가자가 계속 오르고 있다고 받았다.

RTX spark를 두고는 서로 다른 참가자들의 평이 오후 내내 이어졌다. 한 참가자는 ARM 기반 윈도라서 테스트용 윈트북으로는 적절하지 않을 것 같다고 했고, 오후 네 시 무렵 같은 참가자가 리눅스를 깔아 쓰는 편이 제대로일 것 같다고 덧붙였다.

RTX spark는 ARM 기반 윈도 라서 , 테스트용 윈트북으로 사용하기에는 적절하지 않을텐데요..

또 다른 참가자는 이 장비를 계륵 같은 존재라고 했고, x64가 아니라 되는 게 없을 것이라고 짐작했다. 그와 별개로 다른 참가자는 윈도 프로그램이 제대로 안 돌아가는 것 같아 맥북 2중대로 생각해야겠다고 했다. 이들 모두 직접 써 본 후기가 아니라 짐작이나 인상이었고, 계륵이라고 했던 바로 그 참가자는 후기를 못 봤다고 스스로 밝혔다. 대화 속 사양 판단은 확인되지 않은 채 남았다.

오후 네 시 반, 맥북이 멈췄다

오후 네 시 반을 넘기자 분위기가 바뀌었다. 한 참가자가 갑자기 맥북이 아무것도 안 된다며 같은 경험을 하는 사람이 있느냐고 물었고, 맥북이 집에 있어서 재부팅해야 하는데 쉽지 않다고 했다. 이어서 모든 agent가 안 된다며 codex, claude, minimax를 꼽았다.

모든 agent가 안되네요 codex, claude minimax

같은 참가자는 ssh는 붙는데, 맥북이 GUI로 하지 않으면 안 되는 부분이 많은 것 같다고 했다. GUI는 마우스로 조작하는 화면 방식이다. 원격 프로그램도 갑자기 안 된다고 한 뒤에는 몇 개 더 깔아 놔야겠다고 정리했다. 오류 메시지도 한 줄 올렸는데, 로그인 시작에 실패했다는 내용이었고 원인은 대화에서 확인되지 않았다.

ssh는 붙는데

다른 참가자는 강제 재부팅 뒤에 연결을 유지해 주는 스크립트를 만들어 두어야 할 것 같다고 했고, 원격 프로그램으로 보험을 들어야겠다고 조언했다. 윈도의 taskkill 같은 명령으로 프로세스를 정리한 뒤 자동 재실행되면 붙을 것 같은데 맥은 어렵다는 말도 했다. 이는 어디까지나 추측이며, 먹통이 실제로 어떻게 풀렸는지는 이 창의 대화에 나오지 않는다.

장비 고민이 보여 준 것

오후 세 시의 장비 고민과 네 시 반의 먹통은 서로 다른 참가자의 이야기다. 인과로 이어 붙일 근거는 없다. 다만 개발서버 한 대를 켜 두고 다른 기기로 접속해 일하는 구도는 같은 날 한 번 흔들렸고, 그 자리에서 제안된 것은 새 장비가 아니라 원격 수단을 여러 개 갖춰 두는 쪽이었다. 윈도 사용자용 서비스라서 윈트북이 반드시 필요하다는 사유와, 맥북을 개발서버로 두는 편의 사이에서 무엇이 정답인지 대화는 결론을 내리지 않았다.