Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
개발자가 코딩 에이전트의 기능을 확장하여 원격 Mac 환경을 구축한 사례입니다. 이 시스템은 Linux 기반 개발 머신과 함께 작동하며, MacBook Air를 클라이언트로 사용하여 집의 고성능 중고 MacBook Pro에서 iOS 빌드 및 시뮬레이터 테스트 등 그래픽 인터페이스가 필요한 작업을 수행할 수 있게 했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기내 에이전트는 이미 Linux에서 원격으로 작동했다. iOS 빌드, 시뮬레이터 테스트 및 컴퓨터 사용을 위해 macOS 노드를 추가했다.
Codex에게 웹과 iOS 시뮬레이터에서 내 앱의 변경 사항을 테스트하고 비디오를 보내달라고 요청했다. 나는 MacBook Air를 통해 화면 공유(Screen Sharing)로 작동하는 것을 지켜봤다. 창을 닫았는데도, 작업은 집의 MacBook Pro에서 계속 실행되고 있었다.
나중에 에이전트가 앱의 두 버전을 모두 사용하는 녹화본을 받았다.
원격 Mac은 통합 메모리(unified memory) 48GB를 갖춘 중고 MacBook Pro M4 Pro다. 이 기기는 나의 Linux 타워 옆에 세로 스탠드에 닫힌 채 놓여 있다. 이제 내 에이전트는 집에서 머무는 macOS 데스크톱과 iOS 시뮬레이터를 갖게 되었고, 나의 Air는 여전히 내가 휴대하는 노트북으로 남아있다.
이전 기사에서 나는 오래된 게이밍 PC를 Ubuntu 개발 머신으로 바꾸는 것에 대해 썼다. 리포지토리, 개발 서비스 및 코딩 에이전트가 그곳에서 실행되었다. 나의 MacBook Air는 내가 그것들과 함께 작업하는 클라이언트가 되었다.
그 배치는 처음에는 내가 이미 소유한 하드웨어를 더 편안하게 사용하기 위한 방법으로 시작되었다. 사용해 보니, 나는 계속 이런 방식으로 일하고 싶다는 것을 깨달았다.
나는 에이전트에게 작업을 맡기고 노트북을 닫아도, 집의 환경은 여전히 실행되고 있다는 것을 알 수 있었다. 식당에서 휴대폰만 가지고 돌아와서도 Air가 켜져 있을 필요 없이 안드로이드 변경 사항을 요청하고 같은 휴대폰으로 결과를 확인할 수 있었다.
내가 가장 즐겼던 부분은 작업이 계속 실행되도록 내버려 둘 수 있었다는 점이다. 긴 작업이라도 에이전트를 위해 노트북을 앞에 두고 있어야 할 필요가 없었다.
하지만 나의 개발 중 일부는 여전히 Air에서 이루어졌다.
나는 모바일 작업을 위해 React Native를 사용하며, iOS 빌드와 시뮬레이터 세션에는 macOS가 필요했다. 에이전트가 리포지토리에서 원격으로 작업할 수는 있었지만, 나는 여전히 그 작업을 Air로 가져와 컴파일하고 시뮬레이터에서 검사해야 했다.
이후 저는 Codex 컴퓨터 사용을 더 자주 이용하기 시작했습니다. 여기서 컴퓨터 사용이란 에이전트가 브라우저나 iOS 시뮬레이터 같은 그래픽 인터페이스와 상호작용하도록 하는 것을 의미합니다. 저는 macOS 구현 방식이 마음에 들었습니다. 사이트를 탐색하거나 앱 내에서 플로우를 직접 시도하도록 요청할 수 있었습니다.
이러한 작업들은 또한 Air의 데스크톱과 16GB 메모리를 사용했습니다. 작동은 했지만, 다시 한번 제가 클라이언트로 사용하고 싶은 기기에 에이전트 자원을 할당하는 것이었습니다.
저는 집에서 이런 작업 일부를 처리할 수 있는 Mac을 원했습니다.
Mac mini가 당연한 선택처럼 보였습니다. 저는 집에 두고 원격으로 접근할 수 있는 기기를 원했습니다.
메모리는 저에게 중요했습니다. 컨테이너, iOS 빌드, 시뮬레이터, 그리고 컴퓨터 사용을 위한 여유 공간이 필요했습니다. 또한 로컬 추론(local inference)으로 실험해보고 싶었지만, 당시에는 로컬 모델이 제 워크플로우에서 어떤 역할을 할지 결정하지 못했습니다.
콜롬비아에서 적절한 기기를 찾는 것은 예상보다 어려웠습니다. 제가 찾은 새 Mac mini는 비쌌고, 메모리가 더 많은 중고 옵션은 비교적 희귀했습니다. 저는 Air와 같은 16GB 제약 사항을 가진 다른 기기를 구매하고 싶지 않아 계속 찾아보았습니다.
그러다가 M4 Pro와 48GB 통합 메모리를 갖춘 중고 MacBook Pro를 발견했습니다. 배터리 사이클이 약 70회로 거의 새것 같았습니다. 제시된 가격은 제가 고려하던 16GB Mac mini 신제품의 가격과 비슷했습니다. 또한 동급의 MacBook Pro를 새로 구매하는 것보다 훨씬 저렴했습니다.
그래서 저는 그것을 구매했습니다.
폼팩터(form factor)는 제가 찾던 것은 아니었지만, 일을 할 수는 있었습니다. 집에 두고 macOS 워크로드가 더 많은 메모리를 사용하도록 할 수 있었고, 이동할 때는 Air를 계속 사용할 수 있었습니다.
MacBook Pro는 Ubuntu PC 옆의 세로 스탠드에 닫힌 채 놓여 있습니다. 원격 디스플레이 설정을 위해 더미 HDMI 플러그가 있는 전원 허브에 연결되어 있습니다. 저는 Amphetamine을 사용하여 뚜껑을 닫은 상태에서 작업할 때 깨어있도록 유지하는 데 도움을 받습니다.
나의 Ubuntu 타워와 수직 스탠드에 놓인 MacBook Pro.
Mac 데스크톱을 확인해야 할 때, Air에서 화면 공유(Screen Sharing)를 엽니다. 시뮬레이터, 브라우저, 에이전트 도구는 Pro에서 실행됩니다. Air는 저에게 무슨 일이 일어나고 있는지 보여주고 상호작용할 수 있게 해줍니다.
이제 설정은 다음과 같습니다:
작업 흐름을 보여주기 위해, 제가 만든 개인 AI 동반자 앱인 Synapse의 세션을 녹화했습니다.
저는 최근 Gemini와 함께 OpenRouter를 통해 오픈 소스 모델들을 사용해 볼 수 있는 모델 선택기(model selector)를 추가했습니다. 이 변경 사항은 이미 웹 및 모바일 인터페이스에 구현되었습니다. 저는 Codex가 컴퓨터 사용을 통해 이를 테스트하고, 웹과 iOS 시뮬레이터에서의 상호작용을 보여주는 비디오 하나를 보내주기를 원했습니다.
저는 그것이 사용자 흐름(user flow)을 따르기를 바랐습니다: 선택기를 열고, 채팅을 사용하며, 두 인터페이스에서 발생하는 일을 녹화하는 것입니다.
요청 사항, 원격 데스크톱, 그리고 에이전트가 반환한 비디오 발췌본을 포함하여 편집된 녹화본은 다음과 같습니다:
Codex에게 웹과 iOS에서 Synapse를 테스트하도록 요청하고, 화면 공유를 닫은 다음, 그것이 반환하는 녹화본을 검토합니다.
처음에는 에이전트 대화 옆에 화면 공유가 열려 있었습니다. 저는 Pro의 데스크톱을 볼 수 있었고 그곳에서 작업하는 것을 지켜볼 수 있었습니다. 그러다가 화면 공유 창을 닫았습니다.
작업은 계속되었습니다. 나중에 Codex는 더 많은 진행 상황을 보고하고 녹화본을 반환했습니다.
이것이 제가 이 설정에서 원했던 것입니다. 데스크톱을 검사하고 싶을 때 원격 뷰를 열고, 에이전트가 작업하는 동안에는 닫았다가, 다시 살펴봐야 할 때 재연결할 수 있습니다. 뷰잉 창이 열려 있을 필요는 Pro에서 작업을 실행하는 데 필요하지 않습니다.
반환된 비디오는 에이전트가 웹 앱과 iOS 시뮬레이터와 상호작용하고, 셀렉터를 사용하며, 채팅 응답을 받는 것을 보여줍니다. 저는 이 상호작용들을 작성된 보고서와 함께 직접 검토할 수 있습니다.
저는 이제 에이전트에게 요청할 수 있는 것의 일부로 녹화에 대해 생각하기 시작했습니다. OBS는 화면 캡처를 처리하고, FFmpeg은 비디오를 준비할 수 있습니다. 에이전트는 앱이 실행되는 머신에서 이러한 도구들에 접근할 수 있습니다.
UI 작업에는 이것이 유용합니다. 보고서는 에이전트가 무엇을 했는지 알려줄 수 있습니다. 녹화는 제가 수행한 상호작용을 살펴보고 더 깊이 조사해야 할지 결정하는 데 도움이 됩니다.
이제 저는 웹과 모바일 앱 전반에 걸쳐 작업을 위임하고, 그 결과로 나온 플로우의 가시적인 시연을 요청할 수 있습니다. iOS 시뮬레이터와 녹화는 제 Air의 데스크톱을 빌리지 않고도 Pro에서 작업 내내 유지될 수 있습니다.
저는 여전히 원격 개발에는 Linux를 선호합니다. Ubuntu가 저에게 더 가볍게 느껴지고 비동기적으로 실행되는 작업에 편안합니다. 타워는 레포지토리, 서비스 및 코딩 작업에 계속 유용합니다.
Pro는 작업이 macOS, iOS 시뮬레이터 또는 그래픽 데스크톱 접근을 필요로 할 때 또 다른 옵션을 제공합니다. 저는 에이전트가 무엇을 하기를 원하는지에 따라 환경을 선택할 수 있습니다.
두 개의 호스트를 갖는 것은 프로젝트에서 여러 작업을 수행할 때도 도움이 됩니다. 각 머신은 자체 실행 환경을 가질 수 있고, 저는 그것들을 검사하기 위해 별도의 URL을 열 수 있습니다.
단일 머신에서는 여러 워크트리(worktrees)가 서비스의 여러 복사본, 포트 충돌 및 각 환경을 분리하기 위한 추가 설정으로 이어질 수 있습니다. 두 호스트에 걸쳐 작업을 분산하면 저에게서 이러한 마찰을 일부 줄여줍니다. 저는 여전히 브랜치를 조정하고 변경 사항을 통합해야 합니다.
이는 웹과 모바일 전반에 걸쳐 완전한 기능을 위임할 수 있는 여유 공간을 제공합니다. Air를 사용하여 작업을 지시하고 그 결과를 검토하는 동시에, 개발 작업을 어디서 실행하고 인터페이스를 어디서 검사할지 선택할 수 있습니다.
저는 Pro에서 로컬 Qwen 모델로 실험을 시작했습니다. 48GB의 통합 메모리를 이 용도로 사용한 것은 구매의 재미있는 부분이었습니다.
이것은 원격으로 코딩 에이전트를 실행하는 것과는 별개의 실험입니다. 해당 에이전트들은 여전히 호스팅된(hosted) 모델을 사용할 수 있습니다. 여기서는 제가 Mac 자체에서 모델을 실행하고 있습니다.
저는 이 모델이 더 강력한 모델의 작업자(worker) 옆에서 제한된 작업(bounded tasks)을 처리할 수 있는지, 아니면 대규모 파일 컬렉션을 처리하는 데 더 유용할지 탐구하고 있습니다. 매 요청마다 호스팅 비용이 발생하는 것 없이 제가 소유한 하드웨어에서 추론을 반복할 수 있다는 점이 매력적입니다. 기계와 전기는 여전히 비용이 듭니다.
아직 이 모델의 정기적인 역할을 결정하지 못했습니다. 어떤 작업을 잘 처리하는지, 어디서 더 많은 감독(supervision)이 필요한지 아직 배우는 중입니다. 현재로서는 macOS 개발을 위해 구매한 동일한 기계에서 이러한 아이디어들을 시도할 만큼 충분한 메모리를 가지고 있습니다.
Ubuntu는 계속해서 원격 개발 작업을 수행하며, Air는 여전히 제가 휴대하고 집중적인 작업을 위해 사용하는 노트북입니다. 에이전트가 macOS가 필요하면 집에서 Pro를 사용하여 작업할 수 있습니다.
Synapse 세션은 이 설정이 지원하기를 바랐던 종류의 작업입니다. 저는 에이전트에게 웹 앱과 iOS 시뮬레이터를 테스트하도록 요청한 다음, 검토할 녹화본을 받을 수 있습니다. 화면 공유(Screen Sharing)를 열어 그 작업을 검사하고 뷰를 닫아도 Pro에서 작업이 계속 진행됩니다. 원격 환경에는 이제 이러한 작업들이 필요로 하는 Mac 데스크톱이 포함되었습니다.