컴포넌트 스프린트의 (새 탭에서 열림)

워싱턴 포스트는 디자인과 개발이 분리된 채 진행되던 컴포넌트 제작의 문제를 해결하기 위해 약 10일간의 ‘컴포넌트 스프린트’를 도입했다. 디자이너와 개발자가 처음부터 한 쌍으로 참여하고, 관련 팀의 의견을 단계별로 반영해 기술적 제약과 실제 사용 맥락을 함께 고려한다. 이 방식은 디자인 시스템 컴포넌트를 더 빠르고 일관되게 제작하면서도, 팀 전체의 공동 소유 의식을 높이는 것이 핵심이다.

디자인 주도·개발 주도 방식의 한계

• 초기 WPDS(The Washington Post Design System)는 컴포넌트 성격에 따라 제작 주체가 달랐다.
  • select, radio, checkbox처럼 시각적 설계가 중심인 요소는 디자인 주도로 제작했다.
  • carousel, input search처럼 기술적 복잡성이 큰 요소는 개발 주도로 제작했다.
• 한쪽 팀이 주도하면 다른 팀의 전문 지식이 늦게 반영되어 일정 지연과 타협이 발생했다.
• 개발자는 디자인 단계에서 기술적 한계를 뒤늦게 지적하거나, 구현보다 세부적인 시각 요소에 집중하도록 압박받을 수 있었다.
• 디자이너는 자신의 사용 사례가 충분히 고려되지 않거나, 이미 존재하는 컴포넌트를 알지 못해 별도 솔루션을 만들기도 했다.
• 그 결과 디자인 시스템에는 잦은 오버라이드와 즉석에서 판단해야 하는 기능·변형 요청이 누적됐다.

컴포넌트 스프린트의 운영 원칙

• 모든 컴포넌트마다 스프린트를 시작하며, 일반적으로 약 10일 동안 진행한다.
• 디자이너와 개발자가 처음부터 끝까지 프로세스를 이끄는 담당자로 짝을 이룬다.
• 핵심 담당자 외에도 관련 팀의 의견을 수집해 폐쇄적인 순차 작업을 개방적이고 협력적인 과정으로 바꾼다.
• 프로세스는 대체로 다음 단계로 구성된다.
  • 킥오프
  • 콘셉트 정의
  • 디자인과 구현
  • 개선 및 다듬기
  • 문서화
• 모든 참여자가 초기에 요구사항과 기술적 제약을 공유하므로, 후반부의 재작업과 오해를 줄일 수 있다.

킥오프: 영향도와 노력으로 우선순위 정하기

• 매주 30분 회의에서 Jira의 후보 컴포넌트 티켓을 검토한다.
• 각 아이디어를 예상 영향도와 필요한 노력의 관점에서 비교해 우선순위를 정한다.
• 아이디어 보드는 단순한 목록이 아니라 다음 정보를 축적하는 협업 공간으로 활용한다.
  • 이해관계자의 비동기 피드백
  • Slack에서 논의된 관련 정보
  • 비슷한 아이디어의 묶음
  • 사업 목표와의 연관성
• 시각화된 영향도-노력 매트릭스에서는 원의 크기로 투표 수나 인기도를 표현하고, 색상으로 연관된 사업 목표를 구분한다.
• 우선순위가 결정되면 디자인 시스템 팀에서 디자이너와 개발자를 각각 배정한다.
• 두 담당자를 초기 단계부터 정함으로써 프로세스 전반의 지속적인 커뮤니케이션을 보장한다.

콘셉트 정의: 범위와 목표 합의하기

• 스프린트 시작 시 전체 팀과 함께 약 2시간의 회의를 진행한다.
• FigJam에서 다음 내용을 공동으로 정리한다.
  • 컴포넌트의 목표
  • 필수 요구사항
  • 작업 범위
  • 기술적 요구사항
  • 검토가 필요한 가정과 쟁점
• 회의 마지막 15분은 결과 검토에 사용한다.
• 기술 담당자와 비기술 담당자가 같은 공간에서 의견을 남기므로, 서로 다른 관점의 기대치를 조기에 맞출 수 있다.
• 이 단계에서는 구체적인 디자인 세부사항보다 문제의 범위, 사용 목적, 구현 조건을 먼저 합의한다.
• FigJam을 활용하면 특정 직군이 논의를 독점하지 않고, 참여자 모두가 요구사항을 명확히 할 수 있다.

실용적인 적용 방향

컴포넌트 제작을 한 팀에 일괄 위임하기보다, 디자이너와 개발자를 초기부터 공동 책임자로 배치하는 것이 효과적이다. 또한 영향도·노력 기반 우선순위 보드와 공개적인 요구사항 문서를 운영하면 불필요한 컴포넌트 중복과 후반 재작업을 줄일 수 있다.