클라우드를 하나로 합쳤더니, 일하는 환경이 사라졌습니다 — 4.5TB 클라우드 단일화에서 Mac × 클라우드 × Agentic 업무환경 전환까지

Dropbox 1.4TB를 OneDrive로 옮긴 건 시작이었습니다. 스토리지를 하나로 합치자, 정작 ‘일하는 환경’이라는 것이 사라졌습니다 — 어느 디바이스에서 접속하든 같은 환경이 되었기 때문입니다. 개인 컨설팅 인프라가 Mac × 클라우드 × Agentic(Claude Code·Codex) × 하네스 × RAG로 전환을 마친 기록과, 다음 로드맵. (AX 시리즈)

처음 의도는 단순했습니다. Dropbox에 쌓인 약 1.4TB를 OneDrive로 백업해 클라우드를 하나로 줄이자. 비용도, 관리 지점도, “이 파일 어느 드라이브에 있더라”는 매일의 마찰도 줄일 수 있을 것 같았습니다.

그런데 작업을 끝내고 보니, 줄어든 것은 클라우드 개수만이 아니었습니다. ‘내 작업 환경’이라는 개념 자체가 흐려졌습니다. 스토리지를 한 곳으로 모으자 자연스럽게 실행 환경도 클라우드로 올라갔고, 일을 실제로 수행하는 주체는 에이전트(Claude Code·Codex)가 되었습니다. 그러자 제가 Mac 앞에 앉아 있든, 클라우드 PC에 접속해 있든, 결과가 똑같아졌습니다. 디바이스와 OS가 ‘내 환경’이 아니라 ‘접속 창구’로 격하된 것입니다.

이 글은 그 전환의 기록입니다. 클라우드 단일화라는 인프라 정리에서 출발해, Mac × 클라우드 × Agentic × 하네스 × RAG라는 다섯 계층의 곱셈 구조로 업무·컨설팅 환경을 재구성하기까지 — 무엇을 평가했고, 왜 OneDrive로 결정했으며, 어떻게 옮겼고, 그래서 지금 어떤 환경에서 일하고 있는지를 정리했습니다. 마지막에는 다음 단계를 위한 개인 Agentic 로드맵을 붙였습니다.

전환 전 제 자산은 세 개의 클라우드와 두 종류의 디바이스에 흩어져 있었습니다. 10년치 강의·컨설팅 산출물이라는 점이 문제를 키웠습니다 — 같은 프로젝트의 원본이 Dropbox에, 정리본이 OneDrive에, 대용량 원본이 Synology NAS에 따로 있는 식이었습니다.

핵심 통증은 용량이 아니라 맥락 전환 비용이었습니다. 자료가 어디 있느냐에 따라 어느 기기를 켜야 하는지가 달라졌고, 기기가 달라지면 쓸 수 있는 도구가 달라졌습니다. Windows에서만 되는 작업, Mac에서만 되는 작업, NAS가 켜져 있어야 하는 작업이 따로 있었습니다. 한 사람이 다섯 개의 작은 작업 환경을 머릿속에서 스위칭하고 있었던 셈입니다.

통합 대상을 정하기 위해 두 비즈니스 클라우드를 다시 평가했습니다. 결론부터 말하면, Dropbox는 여전히 특정 영역에서 더 우수합니다. 그래서 더 정직하게 비교가 필요했습니다.

표를 정직하게 읽으면 이렇습니다. 대형 바이너리를 매일 협업하는 창작 팀이라면 Dropbox의 블록 단위 동기화가 여전히 강력합니다. 2GB 디자인 파일의 한 레이어만 바꿔도 수 KB만 올라가는 경험은 OneDrive가 따라오기 어렵습니다. 이 점을 부정하면 평가가 아니라 합리화가 됩니다.

그러나 제 업무는 영상 협업이 아니라 문서·발행·컨설팅 산출물 중심이고, 이미 Microsoft 365를 핵심 작업 도구로 쓰고 있었습니다. 그리고 두 가지 결정적 변수가 OneDrive 쪽으로 저울을 기울였습니다.

결정 다음은 실행이었습니다. Dropbox 약 1.4TB를 OneDrive로 비파괴 백업했습니다. 핵심 원칙은 원본을 절대 건드리지 않는 단방향 복사였습니다 — 옮기는 도중 무슨 일이 생겨도 Dropbox 원본은 그대로 남도록.

핵심 기법 — 다운로드 없이 ‘클라우드 → 클라우드’ 직접 전송

1.4TB를 옮기는 가장 순진한 방법은 “Dropbox에서 PC로 1.4TB를 내려받고, 다시 OneDrive로 1.4TB를 올린다”입니다. 이러면 로컬 디스크에 2.8TB 분량의 입출력이 발생하고, 시간도 두 배가 듭니다. 저는 그 대신 오픈소스 동기화 도구 rclone으로 두 클라우드를 직접 연결했습니다 — Dropbox API에서 읽은 바이트를 로컬에 쌓지 않고 곧바로 OneDrive API로 흘려보내는 remote-to-remote(원격→원격) 스트리밍 방식입니다. 로컬 디스크에는 거의 아무것도 남지 않습니다.

플래그 하나하나가 현장 교훈입니다. copy는 sync와 달리 대상에만 더하고 원본은 손대지 않습니다(비파괴). 진짜 병목은 대역폭이 아니라 OneDrive의 초당 API 호출 한도였기에 — 소형 파일이 수십만 개라 — --tpslimit으로 전송 속도를 일부러 묶어 throttle(호출 차단)을 피했습니다. 무작정 빠르게 밀어붙이면 오히려 차단당해 더 느려집니다. 여기에 두 가지 운영 장치를 더했습니다.

• Watchdog(정체 감지 재시작) — 장기 실행이 멈추면(“프로세스는 살아 있는데 복사는 안 되는” 상태) 자동 감지·재기동. 가장 큰 함정은 “프로세스 생존 = 진행”이라는 착각이었습니다.
• 상태 모니터(감사 로그) — 마지막 복사 시각·대조 진척·재시도 패턴 세 신호를 분리 기록. 다일(多日) 전송을 ‘재확인 가능한 기록’으로 만들어 둡니다.

마지막은 검증이었습니다. rclone check --one-way로 원본 대비 누락분을 대조해, 무엇이 정말 안 넘어갔는지를 확인했습니다. 그렇게 남은 것이 아래 표의 예외 6건입니다.

이 작업이 남긴 가장 값진 교훈은 기술이 아니라 ‘끝’의 정의였습니다. 옮기는 동안에도 Dropbox 원본에는 새 파일이 계속 생겼습니다. 그래서 “양쪽이 완벽히 똑같아질 때”를 기다리면, 그건 작업이 아니라 끝나지 않는 운영이 됩니다.

이렇게 Dropbox 1.4TB가 OneDrive로 들어오면서, 기존 코퍼스 + Microsoft 365 문서 + 백업본이 한 곳의 정본으로 모였습니다 — 통합 후 단일 정본은 약 4.5TB 규모입니다. Synology NAS는 폐기가 아니라 ‘콜드 백업’ 역할로 명확히 재배치했습니다 — 모든 저장소가 일상 작업 드라이브일 필요는 없으니까요.

스토리지를 합치자 다음 수가 자연스럽게 보였습니다. 자료가 클라우드 한 곳에 있다면, 그 자료를 다루는 환경도 클라우드에 있는 게 맞습니다. 그래서 작업 환경 자체를 Windows 365 클라우드 PC로 올렸습니다.

Windows 365의 핵심은 가격이 아니라 접속 방식입니다 — 전용 앱과 브라우저로 macOS·iOS·Android·ChromeOS·Windows 어디서나 같은 클라우드 PC에 접속합니다. 즉 제 Mac은 더 이상 ‘작업 기기’가 아니라 클라우드 환경으로 들어가는 창구(thin client)가 됩니다. (참고로 2026년 들어 Windows 365 가격이 약 20% 인하되어 진입 장벽도 낮아졌습니다.)

그리고 그 클라우드 환경 안에서 실제로 일을 수행하는 주체를 에이전트 도구로 바꿨습니다 — 터미널 기반의 Claude Code와 Codex입니다. 제가 단계마다 손으로 하던 작업(자료 검색·문서 작성·조판·발행·검증)을 에이전트가 수행하고, 저는 목표와 기준을 주고 결과를 검수합니다.

전환을 마치고 보니, 제 업무·컨설팅 환경은 다섯 개의 독립 계층이 곱해진 구조가 되어 있었습니다. 각 계층이 분리되어 있다는 것이 핵심입니다 — 한 계층을 바꿔도 나머지가 흔들리지 않습니다.

이것은 더하기가 아니라 곱하기입니다. 어느 한 계층이 0이면 결과도 0입니다 — 최고의 에이전트도 정돈 안 된 지식 위에서는 일반론을 쓰고, 아무리 좋은 지식도 하네스의 품질 게이트가 없으면 산출물에 규율이 빠집니다. 반대로 다섯 계층이 모두 살아 있으면, 한 계층의 개선이 전체에 곱해집니다. 이 곱셈 구조 자체가 이번 전환의 결과물입니다.

그리고 이 구조의 가장 큰 미덕은 계층 독립성입니다. 새 모델이 나오면 ④만 갈아끼우면 되고, 디바이스를 바꾸면 ①만 바뀝니다. 지난 한 달 사이 실제로 모델이 두 번 바뀌었지만, 나머지 계층이 모델 무관으로 쌓여 있어 교체 비용은 0에 가까웠습니다. 환경을 ‘하나의 덩어리’가 아니라 ‘분리된 계층의 곱’으로 지으면, 변화는 위협이 아니라 그냥 한 계층의 업그레이드가 됩니다.

여기서 분명히 해 둘 것이 있습니다 — 이 로드맵은 ‘앞으로 할 일 목록’이 아닙니다. 상당 부분이 이미 매일 가동 중입니다. 기반 단일화(Phase 0)는 끝났고, 하네스 성숙(Phase 1)·지식 자동 환류(Phase 2)·에이전트 플릿(Phase 3)은 실제로 돌아가고 있습니다. 특히 지식 환류는 앞서 소개한 두 지식 시스템(지식 베이스·아카이브) 위에서 작업 종결 때마다 자동으로 일어나고, 야간에는 모니터링 플릿이 외부 인텔리전스를 훑어 큐에 쌓아 둡니다. 남은 진짜 프론티어는 Phase 4, 하네스가 스스로를 개선하는 자기진화입니다.

관통하는 원칙은 하나입니다 — 사람의 역할을 ‘실행’에서 ‘판단’으로 옮긴다. 단계가 올라갈수록 에이전트가 더 많이 수행하지만, 위험한 변경·외부 배포·최종 승인 같은 결정 노드는 끝까지 사람이 쥡니다. 자동화의 목표는 사람을 빼는 것이 아니라, 사람이 가장 잘하는 곳(판단·관계·맥락)에 사람을 집중시키는 것입니다.

역설적이지만, 클라우드를 하나로 ‘합치는’ 작업의 결과는 일하는 환경을 깔끔하게 ‘분리하는’ 것이었습니다. 스토리지·환경·실행·하네스·지식이 각자의 자리에서 독립적으로 존재하게 되자, 그동안 다섯 개의 작은 환경을 머릿속에서 스위칭하던 부하가 사라졌습니다. 그리고 그 자리에 ‘어느 디바이스에서든 같은 환경’이 들어섰습니다.

본 글의 운영 환경 전환은 1인 컨설턴트(n=1)의 기록이며, 가격·정책 수치는 2026년 6월 공개 자료 기준입니다. 조직 규모·산업·규제 환경에 따라 최적 구성은 달라질 수 있습니다.