AI 시대의 제품 디자이너는 화면보다 먼저 세계의 모델을 설계해야 한다
조직도나 기존 화면이 아니라 제품이 끝내 답해야 할 가장 작은 질문에서 모델을 시작함Teamtopia의 원자는 ‘한 사람이 특정 날짜에 자리를 비울 수 있는가’였음Office·Skill Group·Department를 달력 규칙·역량·승인 책임으로 분리함소프트웨어는 공급만 알므로 위험을 계산하되 승인 판단은 사람에게 남김대시보드와 달력은 하나의 모델을 작업 맥락에 맞게 보여주는 여러 뷰임
원문 보기 — Flat Studio — Andrei Zolotukhin ↗
목차 7개
Flat Studio의 UX Design Lead Andrei Zolotukhin은 인터페이스를 가장 나중에 결정한다. 먼저 정하는 것은 제품 안의 개념이 무엇을 뜻하고 어떻게 연결되는지다. 이 개념 모델이 맞지 않으면 제품은 기능이 추가될수록 하나의 시스템이 아니라 기능 더미가 됨.
이 원칙은 교과서에서 가져와 Teamtopia에 적용한 것이 아니다. 휴가 관리 시스템을 만들며 얻었고, 나중에야 도메인 주도 설계(Domain-Driven Design)와 겹친다는 점을 알아봤다. Teamtopia는 Flat Studio와 엔지니어링 파트너 Push가 스프레드시트·이메일·공유 달력을 하나로 합치려 만든 도구다. 직원은 휴가를 신청하고, 누군가는 승인하며, 회사는 가용 인력을 확인한다. 단순해 보이는 흐름 아래에서 개념의 의미와 책임, 소프트웨어가 판단할 범위를 다시 정해야 했다.
01. 조직도가 아니라 제품의 가장 작은 질문에서 시작한다
조직 도구라면 조직도, 상점이라면 부서, 문서 도구라면 폴더와 파일부터 모델링하기 쉽다. 익숙한 구조가 이미 이름을 갖고 있기 때문이다. 하지만 구조는 대상을 어떻게 배열했는지 설명할 뿐, 제품이 해야 할 행동과 정확히 일치하지는 않음.
Teamtopia의 첫 모델도 Company, Office, Department, Project, Employee라는 회사의 언어를 그대로 따랐다. 실제 시나리오를 검토하자 더 중요한 질문이 드러났다. ‘회사가 어떻게 조직됐는가’가 아니라 ‘무엇이 한 사람의 하루 휴가 가능 여부를 바꾸는가’였다.
제품이 끝내 답해야 하는 질문은 더 작았다.
이 사람이 이 특정 날짜에 자리를 비울 수 있는가?
한 사람, 하루, 하나의 상태. 이것이 제품의 원자(atom)가 됐다. 월과 달력은 날짜의 집계이고, Office·Skill Group·Project는 제품의 중심 대상이 아니라 하루의 상태에 각자의 규칙을 더하는 층으로 바뀌었다. 출발점이던 조직 구조도 토대가 아니라 여러 입력 중 하나가 됨.
02. 익숙한 명사는 하나의 일을 할 때만 엔티티가 된다
첫 질문은 직원의 기본 달력이 어디에서 오는가였다. 같은 회사에서도 현지 계약자는 국가 공휴일과 노동 규칙을 따르지만 원격 근무자는 그렇지 않았고, 대신 더 많은 휴가 일수를 받았다. 그래서 Office를 장소가 아니라 근무일·공휴일·휴가 정책을 묶은 달력 규칙으로 다시 정의했다. 국가도 공휴일도 없는 Remote Office가 성립한다는 점이 이 정의를 보여줌.

다음에는 하루 자체와 부재의 결과를 분리했다. Office는 그날이 근무일·주말·공휴일·회사 휴무일 중 무엇인지 답한다. 반면 Skill Group은 해당 역량을 가진 사람이 충분히 남는지, Project는 고객 약속을 지킬 인력이 남는지를 본다. 둘은 하루의 종류를 바꾸지 않고 부재에 따른 위험과 남은 업무 여력을 더함.
Department는 처음에 핵심 모델에서 빠졌다. 하루의 상태도, 누가 누구를 대체할 수 있는지도 바꾸지 못했기 때문이다. 그러나 ‘누가 휴가를 승인하는가’라는 다른 질문이 등장하자 돌아왔다.
승인을 Office에 묶으면 분산 팀에서 문제가 생긴다. 같은 Office에 디자이너가 남아 있지 않아도 다른 원격 그룹의 디자이너가 일을 이어갈 수 있다. 위치가 아니라 업무 기능을 따라 책임을 둬야 했고, Department가 그 역할을 맡았다.
결과적으로 세 개념은 겹쳐 보이지만 서로 다른 질문을 소유한다.
- Office — 달력 규칙
- Skill Group — 역량과 부재 위험
- Department — 승인 책임
현실에서는 같은 디자이너들이 Skill Group이면서 Department일 수 있다. 모델에서는 capability와 responsibility를 분리해야 이후의 규칙이 서로 같은 의미를 차지하려 다투지 않음.
03. 공급만 아는 소프트웨어는 승인자가 될 수 없다
시스템이 필요한 역량을 가진 사람이 몇 명 남는지 계산할 수 있게 되면 휴가 신청을 자동 차단하고 싶어진다. 그러나 한 사람이 여러 Skill Group과 Project에 속하므로 엄격한 차단 규칙은 거의 모든 근무일을 ‘불가’로 표시할 수 있다. 계산은 맞지만 신호는 쓸모없어진다.
더 근본적인 한계가 있다. 소프트웨어는 사람이 있는지, 즉 공급은 안다. 하지만 그 기간에 해당 역량이 필요한 일이 있는지, 즉 수요는 모른다. 가용 인원이 0명이어도 예정된 일이 없다면 실제 비용은 없으며, 이 맥락은 관리자에게 있음.
그래서 Teamtopia는 위험 수준과 그 구성만 보여준다. 시스템은 신청을 차단하지도 승인하지도 않는다. 사람은 대체자를 정하거나, 위험을 감수하거나, 이유와 함께 거절한다. 자동화의 경계는 더 많이 결정하는 데 있지 않고 시스템이 정직하게 알 수 있는 범위에 놓임.
04. 역할을 권한 사다리에서 독립된 책임으로 바꾼다
Employee 위에 Approver, 그 위에 모든 것을 바꾸는 Admin을 두는 단일 권한 사다리도 버렸다. 시스템 설정과 타인의 휴가를 책임지는 일은 상하 관계가 아니라 독립된 직무다. 큰 회사에서는 설정 담당자가 승인하지 않을 수 있고, 승인 관리자가 설정을 편집할 이유도 없다.
모든 사람은 창업자를 포함해 휴가가 필요한 Employee를 기본으로 갖는다. 그 위에 설정을 바꿀 수 있는 Admin 권한과, 특정 Office나 Department의 신청을 책임지는 Approver 의무를 따로 붙였다. Approver는 접근 수준이 아니라 책임 구역과 맺은 관계임.
이 분리는 화면에도 이어졌다. 직원은 자신의 달력과 남은 휴가를, 승인자는 담당 구성원의 신청을, 관리자는 전체 상태를 보러 온다. 한 화면에 세 목적을 섞는 대신 같은 사람이 현재 맡은 일에 따라 모드를 전환하도록 했다. 인터페이스 구조가 도메인 모델의 기본층과 독립된 책임 축을 그대로 따름.
05. 화면은 새 엔티티가 아니라 하나의 모델을 보는 각도다
각 Office의 달력은 데이터로 존재하지만 Company 달력은 별도 객체가 아니다. 모든 Office 달력을 한꺼번에 보는 집계 뷰다. 대시보드·프로젝트 화면·승인 화면도 정보를 복제한 작은 시스템이 아니라, 직원의 하루와 그 위에 쌓인 규칙을 서로 다른 각도에서 보여줌.
뷰는 수동적인 창에 그치지 않는다. 날짜를 이미 아는 하루 병가는 빠르게 처리할 수 있어야 한다. 2주 휴가를 계획할 때는 연간 공휴일, 다른 사람의 부재, 위험한 날짜를 함께 보는 달력이 낫다. Teamtopia에서는 직원과 승인자가 대시보드와 달력 어느 쪽에서도 신청을 처리할 수 있다. 데이터는 같고 작업 맥락만 다름.
06. 넓게 만든 프로토타입은 모델의 구현 비용까지 드러낸다
일반적인 프로토타입이 아이디어나 흐름을 검증한다면, 시스템 전체 범위를 클릭할 수 있게 만든 프로토타입은 추상적인 규칙을 가시적인 구현 규모로 바꾼다. 규칙으로 적을 때는 싸 보이던 복잡성이 실제 화면과 상태로 펼쳐지며 비용이 드러남.
Teamtopia의 첫 버전은 2023년부터 운영 중이다. Flat Studio에 따르면 현재 10곳이 넘는 회사, 약 250명의 휴가 업무에 쓰인다. 당시에는 저자가 말하는 AI 프로토타이핑 도구가 없어 와이어프레임에서 곧바로 실제 제품을 만들었다.
이 글이 설명하는 두 번째 모델은 다르다. Figma Make로 광범위한 인터랙티브 프로토타입을 만들었고, 프로덕션 코드 한 줄을 쓰기 전에 구현이 엔터프라이즈 규모의 엔지니어링 작업이라는 판단을 얻었다. 첫 버전은 계속 운영되지만 두 번째 모델은 출시된 제품이 아니다. 방향과 범위를 파악한 프로토타입이며, 실제 구현에는 이를 맡을 인력과 시간이 필요함.
복잡한 제품을 개선하는 방법은 잘못된 모델의 빈틈을 기능으로 덮는 것이 아니다. 각 개념을 두고 ‘현실을 나타내는가, 아니면 익숙해서 가져온 말인가’를 반복해 묻는 일이다. 모델이 진실에 가까워질수록 화면은 그 모델을 꾸며내는 장소가 아니라 정확히 보여주는 표면이 됨.
crit의 관점
AI 시대에는 잘못된 개념 모델도 이전보다 훨씬 빨리 작동하는 화면이 된다. 그래서 제품 디자이너의 선행 과업은 화면을 만드는 속도가 아니라, 제품이 답해야 할 최소 질문을 찾고 엔티티·책임·판단 경계를 세계의 모델로 고정하는 일로 이동한다.
- 크레딧
- 대표 및 본문 이미지 — Flat Studio / Teamtopia 원문
도움이 됐다면 업보트해주세요
댓글
- 불러오는 중…