{3줄 요약}

디자인 조직 운영은 좋은 디자이너를 모으는 일보다 일하는 구조를 만드는 일이에요.
팀이 커질수록 결정과 협업과 성장 방식이 품질에 직접적인 영향을 주게 돼요.
운영 원칙을 알면 사람 관리가 아니라 좋은 디자인이 나올 환경을 설계하게 돼요.

이 방법을 쓰는 맥락

디자인 팀이 생기거나 성장할 때, 협업 방식을 재정비할 때, 또는 "우리 팀이 왜 이렇게 느리지?"를 파악하려 할 때 이 방법이 필요해요.

작은 팀(2~3명)은 대화로 많은 것을 해결해요.
하지만 팀이 커지면 대화만으로는 정보가 빠지고, 결정이 지연되고, 일관성이 무너져요.
팀 규모에 맞는 운영 구조가 필요해요.

주니어 디자이너들이 자주 경험하는 것: "팀이 좋은데 일하기가 어렵다"예요.
좋은 사람들이 모여도 방향 정렬이 안 되면, 같은 화면을 여러 명이 다르게 만들고, 결정이 계속 번복되고, 리뷰가 "원래 방향이 뭐였죠?"로 시작돼요.
이게 운영의 문제예요.

단계별 실행 방법

1단계 — 팀 구조 정의하기

디자인 팀이 조직에서 어떤 위치에 있는가가 어떻게 일하는가를 결정해요.

중앙 집중형(Centralized): 모든 디자이너가 한 팀에 있어요. 일관성이 높고, Design System 운영이 쉬워요. 하지만 각 제품팀의 맥락을 깊이 이해하기 어려워요.

임베드형(Embedded): 디자이너가 각 제품팀에 소속돼요. 팀 맥락을 잘 알고 빠르게 움직여요. 하지만 디자이너 간 방향이 달라지거나, Design System이 분산될 수 있어요.

하이브리드형: 일부는 중앙 팀(Design System, 리서치), 일부는 제품팀에 임베드돼요. 규모가 커지면 가장 흔히 택하는 구조예요.

Peter Merholz는 《Org Design for Design Orgs》에서 "어떤 구조가 맞는지는 조직의 성숙도와 제품 전략에 따라 다르다"고 했어요.
정답은 없어요.
지금 팀이 겪는 문제를 해결하는 구조를 택해야 해요.

2단계 — 의사결정 구조 만들기

결정이 느리거나 자주 번복되면, 결정 방식이 불명확한 거예요.

무엇을 누가 결정하는가를 명확히 해요.

예시:

  • Design System 컴포넌트 추가 → Design System 리드가 결정
  • 특정 화면의 UX 방향 → 담당 디자이너 + PM이 결정
  • 전체 브랜드 방향 → 디자인 리더 + 경영진이 결정

RACI 매트릭스(누가 책임지고, 누가 승인하고, 누가 협의하고, 누가 통보받는가)를 주요 결정 유형별로 만들어두면 "이건 누가 결정해요?"가 줄어요.

3단계 — 디자인 리뷰 문화 만들기

디자인 리뷰는 비판하는 자리가 아니에요. 더 좋은 방향을 찾는 자리예요.

좋은 리뷰 구조:

  • 리뷰 전에 "이 리뷰에서 어떤 피드백을 원하는가"를 발표자가 먼저 말해요 (방향 피드백인지, 세부 디자인 피드백인지)
  • 피드백은 "이상해요" 대신 "이 부분에서 [사용자가] [어떤 상황]에서 어려울 것 같아요"처럼 맥락과 함께
  • 결정된 것과 열린 것을 구분해서 회의를 마쳐요

리뷰 문화가 나쁘면 디자이너들이 리뷰에 방어적이 돼요.
리뷰에서 피드백 대신 방어를 준비하기 시작하면 팀 전체의 학습이 느려져요.

4단계 — Design Ops 기반 만들기

Design Ops(디자인 운영)는 디자인 팀이 더 잘 일할 수 있게 하는 인프라예요.

포함되는 것:

  • 도구 관리: Figma 조직 계정, 라이선스, 플러그인 기준
  • 파일 구조 기준: 팀 전체가 같은 파일 명명 규칙, 레이어 구조를 써요
  • 온보딩 가이드: 새 팀원이 도구, 프로세스, Design System을 빠르게 파악할 수 있는 문서
  • 반복 업무 자동화: → Design 자동화 참고

팀이 3~5명을 넘으면 Design Ops가 없는 비용이 보이기 시작해요.
파일을 찾는데 시간이 걸리고, 컴포넌트 명명이 제각각이고, 새 팀원이 오면 세팅에 1주일이 걸려요.

5단계 — 성장 경로와 피드백 루프 만들기

좋은 디자인 조직은 사람이 성장하는 곳이에요.

디자이너가 "나는 어디로 성장하는가"를 알 수 있어야 해요.
IC(Individual Contributor, 전문성 깊이) 경로와 Management(팀 리드) 경로를 구분해요.
모든 좋은 디자이너가 팀장이 되어야 하는 건 아니에요.

정기 1:1 미팅에서 "지금 어떤 것이 어렵나요?", "무엇을 더 배우고 싶나요?"를 물어요.
이 대화가 없으면 어려움이 쌓여 이직으로 이어져요.

하지 말아야 할 것

팀이 커질 때 아무 구조도 바꾸지 마세요: 5명일 때 작동하던 "그냥 Slack으로 다 해요"가 15명에서도 된다고 생각하면 안 돼요. 팀 크기마다 필요한 프로세스가 달라요.

리뷰를 승인 절차로만 만들지 마세요: "이 디자인을 통과시켜야 한다"는 압박이 있는 리뷰는 진짜 문제를 드러내지 않아요.

Design Ops를 "디자이너가 아닌 사람이 하는 것"으로 분리하지 마세요: 작은 팀에서는 시니어 디자이너 또는 디자인 리더가 직접 챙겨야 해요. 아무도 안 챙기면 팀 전체의 효율이 떨어져요.

실행 후 확인하기

  • 팀 구조가 현재 조직의 필요에 맞나요?
  • 주요 결정 유형별로 누가 결정하는지 명확한가요?
  • 디자인 리뷰가 비판이 아닌 개선을 위한 자리인가요?
  • 신규 팀원이 온보딩하는 데 필요한 문서가 있나요?
  • 각 디자이너가 성장 경로를 알고 있나요?

관련 아티클

참고 문헌

  • Peter Merholz & Kristin Skinner, 《Org Design for Design Orgs》(2016) - 디자인 조직 구조(중앙집중형 vs 임베드형 vs 하이브리드), 의사결정 구조, Design Ops의 실무 적용을 다뤄요.