Claude Code와 Claude Design을 잇는 /design-sync, 무엇이고 무엇이 아닌가

2026년 6월 17일, Claude Code와 Claude Design을 잇는 /design-sync가 발표되었습니다(글을 쓰는 지금은 베타로 순차 롤아웃되는 중입니다). 처음 소식을 접했을 때는 "MCP 서버를 하나 더 붙이는 이야기인가" 하고 가볍게 넘겼습니다. 그런데 자료를 조금 더 읽어보니 제가 짐작했던 그림과 실제 동작이 꽤 다르다는 생각이 들었습니다. 그래서 직접 돌려보기 전에, 우선 사실관계부터 차분히 정리해두기로 했습니다.

미리 밝혀두자면 이 글은 직접 써본 후기가 아닙니다. 아직 제 손으로 /design-sync를 실행해보지는 못했고, 발표된 내용을 읽고 정리한 사실 위주의 글입니다. 다만 정리하는 과정에서 헷갈리기 쉬운 지점이 두 가지 보였고, 그 부분을 분명히 짚는 것이 이 글의 목적입니다.

Claude Design부터 — 어디서 돌아가는 제품인가

Claude Design은 Anthropic이 2026년 4월에 출시한 디자인 생성 제품입니다. 웹(claude.ai/design)과 데스크톱 앱에서 동작하며, 모바일은 지원하지 않습니다. 디자인을 만드는 일과 그것을 코드로 옮기는 일은 원래 서로 다른 자리에서 이루어지던 작업입니다.

그동안 저를 포함한 많은 개발자들은 Claude Design에서 만든 결과물을 export해 파일로 로컬에 내려받은 뒤, 그 파일을 가지고 작업해왔습니다. 다만 이렇게 내려받은 파일은 그 시점을 한 번 떠낸 스냅샷이라, 디자인이 바뀌면 다시 받아와야 하는 일회성 흐름이었습니다. 결국 이 두 자리 사이에는 늘 간극이 있었고, /design-sync가 메우려는 지점이 바로 그 간극이라는 생각이 들었습니다.

/design-sync가 연결하는 것 — 양방향이라는 의미

발표의 핵심은 Claude Code와 Claude Design이 양방향으로 연결된다는 점입니다. 한쪽 방향만 트인 것이 아니라, 가져오고 다시 올리는 흐름이 모두 가능합니다. 방향을 둘로 나누어 보면 이해가 쉽습니다.

• pull: Claude Design에 있는 디자인 시스템을 레포로 가져와, 프로젝트의 실제 컴포넌트에 맞춰 구현합니다. export로 파일을 한 번 내려받아 두던 일회성 방식에서, 필요할 때 실제 컴포넌트를 그대로 끌어오는 방식으로 바뀌는 셈입니다.
• push: Claude Code에서 만든 것을 다시 Claude Design 캔버스로 올려, 시각적으로 마저 편집합니다.

이 둘이 맞물리면 하나의 반복 루프가 됩니다. 디자인 시스템에서 출발해 코드로 내려갔다가, 다시 캔버스로 올라와 다듬고, 또다시 내려오는 순환입니다.

[Claude Design: 디자인 시스템 보유]
        │  pull
        ▼
[Claude Code: 코드 구현]
        │  push (승인 게이트)
        ▼
[Claude Design 캔버스: 시각적으로 마저 편집]
        │
        └─ 다시 pull … 반복

실제로 노출되는 동작 — 읽기, 쓰기, 그리고 승인 게이트

연결의 형태만으로는 손에 잡히지 않으니, 실제로 어떤 동작이 노출되는지 살펴보았습니다. 크게 읽기, 쓰기, 그리고 안전장치 세 갈래로 나뉩니다.

구분	동작	설명
읽기	list_projects, get_project, list_files, get_file	쓰기 가능한 디자인 시스템 프로젝트 목록을 확인하고(여러 개일 수 있습니다), 파일을 읽어옵니다. get_file은 파일당 256KB 상한이 있습니다.
쓰기	write_files, delete_files, create_project	파일을 쓰거나 지우고, 새 프로젝트를 만듭니다.
안전장치	finalize_plan	쓰기 전에 어떤 경로를 쓰고 지울지 목록을 잠그고, 사용자 승인을 거쳐 planId를 발급합니다.

여기서 제 눈에 가장 들어온 것은 finalize_plan이라는 안전장치였습니다. 쓰기 작업을 바로 실행하는 것이 아니라, 무엇을 어디에 쓸지 먼저 잠그고 사용자의 승인을 받은 다음에야 진행하는 구조입니다. 계획에 없던 경로에 쓰는 일은 거부되며, 설계상 전체를 한꺼번에 갈아엎는 대신 컴포넌트 단위로 조금씩 동기화하도록 되어 있습니다.

자동화 도구가 내 레포에 직접 파일을 쓴다고 하면 아무래도 마음이 놓이지 않는 법입니다. 그런데 승인 게이트가 앞단에 한 겹 있다는 점은, 적어도 의도하지 않은 변경이 조용히 들어오지는 않겠다는 안심을 주었습니다.

헷갈리기 쉬운 두 가지 — 이 글을 쓴 이유

사실 이 글을 쓰게 된 진짜 이유는 여기에 있습니다. 정리하면서 제가 처음에 잘못 짐작했던 지점이 두 군데 있었고, 비슷하게 오해하기 쉬운 부분이라는 생각이 들었습니다.

첫째, MCP 수동 등록이 아니라 인증입니다

저는 처음에 이것이 claude mcp add로 서버를 직접 등록하는 종류의 일이라고 생각했습니다. 그런데 그렇지 않았습니다. claude.ai 계정으로 로그인해 디자인 권한을 갖거나, /design-login으로 인증만 하면 되는 내장 기능입니다. 첫 호출 시 권한을 묻는 프롬프트가 한 번 뜨는 정도이고, 별도의 서버 등록 절차를 손으로 거치는 방식이 아니었습니다.

둘째, 파일 동기화이지 에이전트 위임이 아닙니다

두 번째 오해가 더 본질적이었습니다. 저는 막연히 "Claude Code에서 Claude Design에게 명령을 내리면, 그쪽이 알아서 디자인을 해주는" 그림을 떠올렸습니다. 그러나 이 도구가 제공하는 것은 그런 에이전트-대-에이전트 위임이 아닙니다. /design-sync의 본질은 파일을 읽고 쓰는 동기화입니다.

캔버스 위에서 이루어지는 AI 디자인 작업은 여전히 Claude Design 앱 안에서 사용자가 직접 하는 것입니다. /design-sync는 그 두 도구를 잇는 다리일 뿐, 한쪽이 다른 쪽에게 일을 떠넘기는 통로가 아니라는 점을 분명히 해둘 필요가 있겠다는 생각이 들었습니다.

참고로 이 연결을 담당하는 내장 서버의 정확한 명칭이 무엇인지는 공식 자료에서 확정적으로 확인하지 못했습니다. 그래서 이 글에서는 특정 명칭을 단정해 부르지 않으려 합니다. 명칭보다 중요한 것은, 결국 무엇을 연결하고 무엇은 연결하지 않는가라고 생각합니다.

정리하다 보니 이 '파일 동기화'라는 성질에서 실용적인 함의가 하나 더 보였습니다. 브라우저에서 Claude Design과 길게 대화하다 보면 한 대화의 컨텍스트가 차서 더는 손대기 어려운 순간이 오는데, 이는 특정 제품의 결함이라기보다 대화형 AI라면 피하기 어려운 한계입니다. 다만 /design-sync는 작업의 정본을 대화가 아니라 파일에 두기 때문에, 한 대화가 꽉 차더라도 작업물이 그 대화에 갇히지 않습니다. 별개의 컨텍스트를 가진 Claude Code 쪽으로 pull해 이어서 작업할 길이 열려 있는 셈입니다. 그래서 컨텍스트 한계 자체가 사라지는 것은 아니지만, 적어도 대화 하나가 차서 프로젝트가 통째로 잠겨버리는 상황은 한결 비껴갈 수 있겠다는 생각이 들었습니다. 물론 이 역시 아직 직접 확인한 것은 아니어서, 다음에 일부러 대화를 채워 두고 Claude Code에서 이어 편집해보며 검증해볼 생각입니다.

정리 — 다음엔 직접 돌려볼 차례

이번에 사실관계를 정리하며 얻은 교훈은 단순합니다. 새로운 기능을 마주할 때 이름이나 겉모습에 휘둘리기보다, 그것이 무엇을 잇고 어디까지 책임지는지를 먼저 따져보는 편이 낫다는 것입니다. /design-sync는 디자인 시스템과 실제 코드 사이를 양방향으로 이어주는 다리이고, 그 이상도 그 이하도 아니었습니다.

다만 여기까지는 어디까지나 읽어서 정리한 내용일 뿐입니다. 솔직히 말하면 아직 제 손으로 pull과 push를 실행해보지는 못했습니다. 사실관계는 이렇게 확인했으니, 다음에는 직접 /design-sync를 돌려보고 그 경험을 따로 정리해보려 합니다. 도구를 제대로 이해하는 길은 결국 한 번 써보는 데 있다는 생각이 들기 때문입니다.