Open Design은 파일 공개가 아닙니다: 작은 팀이 디자인을 운영하는 방식

Open Design이라는 말을 들으면 먼저 공개된 Figma 파일이 떠오릅니다. 오픈소스 디자인 시스템도 함께 떠오릅니다. 누구나 보고, 복사하고, 수정할 수 있는 디자인 자료입니다. 그것도 중요한 의미다. 다만 AI 에이전트와 작은 팀의 관점에서 보면 Open Design은 파일 공개보다 더 넓은 문제다.

디자인은 이제 더 이상 한 사람이 도구 안에서 끝내는 결과물이 아닙니다. 토큰은 코드로 내려가고, 컴포넌트는 제품에 붙고, AI 에이전트는 디자인 파일을 읽어 화면을 만들고, 개발자는 다시 구현 결과를 디자인 언어로 되돌립니다. 이 흐름에서 닫힌 파일 하나는 병목이 됩니다. 디자인은 열려 있어야 할 뿐 아니라 읽히고 실행될 수 있어야 합니다.

Penpot은 자신을 오픈소스 디자인 플랫폼이라고 설명합니다. 디자인과 코드와 AI 워크플로우를 연결하는 방향도 강조됩니다. Open Design 프로젝트는 local-first, agent-native 디자인 플랫폼을 내세웁니다. 생성된 산출물이 로컬 프로젝트 파일로 남는 흐름을 말합니다. 두 사례 모두 같은 질문을 던집니다. 디자인을 화면 안의 그림으로 둘 것인가, 팀의 운영체계로 만들 것인가.

핵심 정리

1. 01Open Design의 핵심은 공개 여부만이 아니라 디자인 결정이 기계와 사람이 함께 읽을 수 있는 형태로 남는지입니다.
2. 02작은 팀에게 열린 디자인은 토큰, 컴포넌트, 문서, 예시 화면이 한 방향으로 연결된 운영 방식입니다.
3. 03AI 디자인 도구가 강해질수록 결과 이미지만 남기는 방식보다 디자인 시스템과 메모리를 남기는 방식이 중요해집니다.
4. 04Open Design은 무조건 모두에게 공개하자는 뜻이 아니라, 팀 내부에서도 닫힌 파일을 줄이고 재사용 가능한 언어를 만들자는 실무 원칙으로 쓸 수 있습니다.

용어 정리

Open Design

디자인 자료와 의사결정을 더 공개적이고 재사용 가능한 형태로 만드는 접근입니다. 이 글에서는 AI 시대의 운영 방식까지 포함해 씁니다.

open

Local-first

산출물과 작업 상태가 외부 서비스 안에만 갇히지 않고 사용자의 로컬 파일과 레포에 남는 방식입니다.

local

Agent-native

AI 에이전트가 디자인 자료를 읽고, 수정하고, 검증하는 흐름을 처음부터 고려한 구조입니다.

agent

디자인 시스템

색, 글꼴, 간격, 컴포넌트, 패턴, 사용 원칙을 묶어 반복 가능한 제품 언어로 만든 것입니다.

system

공개된 파일과 열린 작업 방식은 다릅니다

디자인 파일을 공개하는 것은 Open Design의 한 형태입니다. 브랜드 리뉴얼 과정을 공개하거나, UI kit을 배포하거나, 디자인 시스템을 오픈소스로 내놓으면 다른 사람이 배웁니다. Mozilla Open Design 같은 시도도 그런 맥락에 있었습니다. 닫힌 조직 안에서만 돌던 디자인 과정을 바깥으로 꺼낸다는 점에서 의미가 컸습니다.

다만 파일 공개만으로는 팀의 일하는 방식이 열리지 않죠. 공개된 파일이 오래되어 실제 제품과 다르거나, 토큰과 코드가 연결되어 있지 않거나, 컴포넌트 상태가 문서화되어 있지 않으면 재사용하기 어렵습니다. 보는 사람은 영감을 얻을 수 있지만, 제품을 만드는 사람은 다시 해석해야 합니다.

작은 팀에서 더 중요한 것은 내부 Open Design입니다. 모든 것을 세상에 공개하지 않아도 됩니다. 대신 팀 안에서 디자인 결정이 특정 도구와 특정 사람 머릿속에 갇히지 않게 해야 합니다. 색상 역할과 컴포넌트 상태는 레포에 남깁니다. 화면 밀도, 금지 패턴, 예시 코드도 같은 곳에 있어야 합니다.

이 관점에서는 Open Design이 오픈소스와 닮아 있습니다. 코드가 공개되어 있어도 빌드가 안 되면 쓰기 어렵습니다. 디자인도 마찬가지입니다. 파일이 열려 있어도 토큰과 컴포넌트가 없으면 부족합니다. 사용 규칙과 구현 연결이 없으면 실제 협업에서는 닫힌 것과 크게 다르지 않습니다.

AI 디자인 도구는 닫힌 파일의 한계를 더 빨리 드러냅니다

AI 디자인 도구는 빠르게 이미지를 만듭니다. 랜딩 페이지와 대시보드를 몇 분 안에 만들 수 있습니다. 슬라이드와 포스터도 빠르게 나옵니다. 그런데 결과가 빠를수록 다음 질문이 중요해집니다. 그 디자인 결정은 어디에 남았는가. 다음 화면을 만들 때 같은 색과 간격을 쓸 수 있는가. 다른 에이전트나 개발자가 그 결과를 이어받을 수 있는가.

이미지 생성형 디자인은 순간 설득력이 강합니다. 다만 제품에는 상태가 있습니다. hover와 focus가 따라옵니다. disabled와 loading도 따라옵니다. error와 empty state도 빠지지 않습니다. 화면 하나가 예뻐도 상태가 없으면 실제 서비스로 옮길 때 다시 설계해야 합니다. AI가 만든 결과가 파일 하나로 닫히면, 사람은 다시 해석자가 됩니다.

Open Design은 이 해석 비용을 줄이는 방향이어야 합니다. AI가 화면을 만들었다면, 그 화면에서 색상 토큰과 간격 규칙을 추출해야 합니다. 컴포넌트 이름과 변형도 남깁니다. 왜 이 레이아웃을 선택했는지, 어떤 대안을 버렸는지, 다음 생성에 반영할 메모리가 있어야 합니다.

Open Design 프로젝트가 강조하는 local-first와 DESIGN.md 같은 개념은 이 문제의 한 답입니다. 산출물이 특정 벤더의 클라우드 안에만 남지 않고 로컬 파일과 레포에 남으면, 다음 에이전트와 다음 사람이 이어받을 수 있습니다. 디자인이 이미지가 아니라 작업 상태가 됩니다.

Penpot이 보여주는 방향

Penpot은 오픈소스 디자인 플랫폼으로, 디자인과 코드의 거리를 줄이는 기능을 강조합니다. 공식 사이트와 GitHub 설명은 디자인 토큰을 핵심으로 내세웁니다. CSS Grid와 Flex Layout도 중요하게 다룹니다. MCP server와 open API도 같은 방향에 있습니다. 플러그인과 self-hosting도 연결됩니다. 이 조합은 단순히 무료 대체재라는 뜻보다 큽니다.

첫째, 디자인을 코드 친화적으로 만들려는 방향입니다. CSS Grid와 Flex를 디자인 도구 안에서 직접 다루면 구현과 가까운 사고를 하게 됩니다. 개발자는 결과를 inspect하고 CSS, HTML, SVG 같은 형태로 읽을 수 있습니다. 디자인이 픽셀 캔버스에만 머무르지 않습니다.

둘째, 토큰과 컴포넌트를 단일 출처로 다루려는 방향입니다. 작은 팀에서 색과 간격이 흔들리는 이유는 결정이 여러 곳에 흩어지기 때문입니다. 디자인 도구와 코드가 서로 다른 이름을 쓰면 에이전트는 매번 추정합니다. 문서와 AI 프롬프트가 다른 이름을 써도 같은 문제가 생깁니다. 네이티브 토큰과 공유 라이브러리는 이 추정을 줄이는 장치입니다.

셋째, AI와 연결될 수 있는 API 표면입니다. Penpot의 MCP server나 open API 같은 흐름은 디자인 도구를 사람이 클릭하는 화면에서 에이전트가 읽고 조작할 수 있는 작업장으로 바꿉니다. 이것이 바로 Open Design이 AI 시대에 다시 중요해지는 이유입니다. 열려 있다는 것은 사람이 볼 수 있다는 뜻을 넘어, 시스템이 연결할 수 있다는 뜻이 됩니다.

작은 팀에서 시작하는 방법

작은 팀이 Open Design을 시작한다고 해서 거대한 디자인 시스템을 만들어야 하는 것은 아닙니다. 처음에는 세 가지 파일이면 충분합니다. DESIGN.md, 토큰 파일, 대표 화면 몇 개입니다. DESIGN.md에는 시각 원칙과 금지 패턴을 적고, 토큰 파일에는 색과 간격과 타입을 이름으로 남기고, 대표 화면에는 실제 밀도와 상태를 보여줍니다.

중요한 것은 이 파일들이 따로 놀지 않는 것입니다. DESIGN.md에 적힌 브랜드 톤이 CSS 변수로 내려가고, CSS 변수가 컴포넌트에 쓰이고, 컴포넌트가 실제 화면에서 반복되어야 합니다. AI 에이전트에게도 같은 자료를 읽게 해야 합니다. 그러면 디자인 지시는 "이 느낌으로"에서 "이 시스템을 기준으로"로 바뀝니다.

두 번째 단계는 변경 기록입니다. 왜 색을 바꿨는지, 왜 카드 반경을 줄였는지, 왜 특정 레이아웃을 버렸는지 짧게 남겨야 합니다. 디자인은 결과만 보면 이유가 사라집니다. 이유가 사라지면 다음 에이전트가 같은 실수를 반복합니다. 작은 changelog나 ADR만 있어도 반복 비용이 줄어듭니다.

세 번째 단계는 검증입니다. 디자인이 열려 있다는 것은 아무나 마음대로 바꾼다는 뜻이 아닙니다. 오히려 기준이 명확해야 합니다. 버튼 텍스트가 넘치지 않는지, 모바일에서 카드가 겹치지 않는지, 색 대비가 충분한지, 토큰 밖 색이 새로 생기지 않았는지 확인해야 합니다. Open Design은 자유와 검증이 같이 있어야 오래갑니다.

Open Design은 공개보다 이식성에 가깝습니다

Open Design을 모두 공개해야 한다는 주장으로만 받아들이면 실무에서는 부담스럽습니다. 회사 안의 미공개 제품, 고객 데이터, 브랜드 전략까지 열 수는 없습니다. 다만 이식성은 내부에서도 필요합니다. 사람이 바뀌고, 도구가 바뀌고, 에이전트가 바뀌어도 디자인 언어가 살아남아야 합니다.

이 때문에 나는 Open Design을 "공개된 파일"보다 "닫힌 맥락을 줄이는 운영 방식"으로 이해하는 편이 좋다고 봅니다. 파일이 열려 있고, 토큰이 이름을 갖고, 컴포넌트가 상태를 갖고, 에이전트가 읽을 수 있고, 결과가 로컬 레포에 남는 구조입니다. 이 구조에서는 디자인이 한 번의 산출물이 아니라 다음 산출물을 만드는 재료가 됩니다.

AI 시대의 디자인은 더 빨리 많이 만드는 방향으로만 가지 않을 것입니다. 빨리 만든 결과를 어떻게 기억하고, 다시 쓰고, 검증하고, 다른 도구로 옮기는지가 중요해집니다. Open Design의 실무적 의미는 디자인을 보기 좋은 파일에서 반복 가능한 운영체계로 바꾸는 데 있습니다.