문제: 두 세계의 불화
한 무역회사의 자동화팀은 오랫동안 고민해왔다. 윈도우 디바이스는 메인 업무용 데스크톱이고, 맥미니는 개별 프로젝트용이었는데, 이 둘이 제대로 대화하지 못했다. 구글 시트의 데이터는 윈도우에서만 처리되고, 이미지나 파일 변환은 맥에서만 가능한 식이었다.
「매일 수동으로 파일을 옮기고, 수작업으로 데이터를 입력하고, 중복 확인했다. 자동화 에이전트들도 디바이스가 나뉘자 일처리 효율이 떨어졌다.」
전환점: Claude Code의 중계 역할
3주 전, 이 팀은 Claude Code에 새로운 지시를 내렸다. 윈도우에서 생성된 원본 데이터를 맥미니가 '감지'하고, 자동으로 포맷을 변환한 후, 다시 윈도우로 피드백을 보내는 흐름을 만드는 것이었다.
처음엔 API 연동이 막혔다. 네트워크 대역폭 문제도 있었고, 두 OS의 파일 시스템이 다른 것도 문제였다. 하지만 Claude Code는 중간 저장소로 클라우드 스토리지를 활용하도록 제안했다.
윈도우 디바이스
↓ (파일 생성)
클라우드 스토리지 (공유 지점)
↓ (감지 및 처리)
맥미니
↓ (포맷 변환)
클라우드 스토리지 (결과 저장)
↓ (갱신 알림)
윈도우 디바이스 (최종 처리)
작은 기적들
이 구조로 바뀐 후, 예상 밖의 일들이 일어났다.
첫째, 자동화 에이전트들의 작업 충돌이 완전히 사라졌다. 이전엔 같은 데이터를 두 디바이스에서 동시에 수정하려다 파일이 손상되곤 했다.
둘째, 작업 속도가 40% 빨라졌다. 맥미니의 이미지 처리 능력과 윈도우의 대량 데이터 처리 능력이 진정으로 협력하기 시작했다.
셋째, 예상 밖의 자동화 신청이 늘었다. 다른 팀들도 「자기 디바이스도 네트워크에 포함시켜달라」고 요청했다. 비개발자가 만든 이 시스템이 확장 가능한 구조였던 것이다.
배운 것
이 과정에서 중요했던 것은 기술이 아니었다. 두 시스템이 「직접 연결」되어야 한다고 생각하던 발상을 바꾼 것이었다. 중간 지점(클라우드 스토리지)을 두니까 갑자기 모든 게 부드러워졌다.
또한 Claude Code의 역할이 프로그래머와 달랐다. 에러를 고쳐주는 게 아니라, 「아, 이런 건 이렇게 풀면 되네」라고 아이디어를 제시해주는 방식이었다. 비개발자도 그 로직을 이해할 수 있었다.
「맥미니와 윈도우가 마침내 손을 잡은 날, 우리는 비로소 '팀'이라고 느껴졌다.」
교차 플랫폼 자동화는 아직 소수의 전문가 영역으로 여겨지지만, 작은 비즈니스에서는 이미 일상이 되었다. 도구가 많을수록, 시스템도 복잡해 보이지만, 올바른 '중계점'을 찾으면 비개발자도 충분히 운영할 수 있다.