AI 에이전트, 디자인 프로세스에 들어오다
팀스파르타 디자인팀의 AI 에이전트 구조 완전 분석
출처: 팀스파르타 디자인팀 브런치 아티클 (2026.04.02)
저자: 곽진 & 고우정, 프로덕트 디자이너
원문: https://brunch.co.kr/@8a0100de7ca0488/14
목차
- 배경: 왜 지금 AI 에이전트인가
- 산업 맥락: 디자인 직군의 변화 신호들
- 설계 철학: 구조를 어떻게 결정했는가
- 좋은 에이전트의 4가지 기준
- 전체 에이전트 구조 개요
- Product Design AI Agent — 5대 핵심 기능 상세 분석
- 6-1. Research (리서치)
- 6-2. UX Writing (UX 라이팅)
- 6-3. UI Design (UI 디자인)
- 6-4. Critique (크리틱)
- 6-5. Handoff (핸드오프)
- User AI Agent — 가상 사용자 에이전트
- 각 스킬의 세부 기능 매핑표
- 중앙 정책(Central Policy)의 역할
- Claude Code와의 연결: 기술 구현 방식
- 이 구조가 가져오는 조직 변화
- 한계와 남은 과제들
- 결론: 대체가 아닌 확장
1. 배경: 왜 지금 AI 에이전트인가
2026년 현재, 프로덕트 디자인 업계는 조용하지만 근본적인 전환점에 서 있다. Anthropic에서 Claude의 디자인을 총괄하고 있는 Jenny Wen이 공개적으로 “디자인 프로세스는 끝났다”고 선언한 것은 단순한 도발이 아니었다. 그것은 이미 실무 현장에서 벌어지고 있는 일에 대한 솔직한 진단이었다.
불과 몇 년 전까지만 해도 디자이너의 업무 시간 중 60 ~ 70% 가 목업 제작과 프로토타이핑에 쓰였다. 반복적으로 컴포넌트를 배치하고, 팀 리뷰를 거치고, 수정하고, 다시 전달하는 그 사이클이 디자인 업무의 본체라 여겨졌다. 그런데 지금 그 비중은 30 ~ 40% 수준으로 내려왔고, 그 빈자리는 엔지니어와의 구현 설계 논의, 직접 코드를 작성하는 시간으로 채워지고 있다.
이 변화는 단순히 “도구가 빨라졌다”는 이야기가 아니다. 역할의 무게중심 자체가 이동하고 있다는 신호다. 만드는 사람(maker) 에서 방향을 잡아주는 사람(director) 으로. 그리고 직군 간의 경계, 기획과 디자인과 개발 사이의 그 단단했던 칸막이가 빠르게 허물어지고 있다.
팀스파르타 디자인팀은 이 흐름을 수동적으로 받아들이는 대신, 능동적으로 선점하기로 결정했다. 디자이너의 전문 지식을 외부 AI 도구에 의탁하는 것이 아니라, 팀 자신의 원칙과 제품 맥락이 깊이 배어든 고유한 AI 에이전트를 직접 설계하고 구축하는 방향을 택한 것이다.
2. 산업 맥락: 디자인 직군의 변화 신호들
팀스파르타 디자인팀의 이 결정은 고립된 실험이 아니다. 업계 전반에서 비슷한 움직임이 동시다발적으로 일어나고 있다.
AI가 바꾸고 있는 디자이너의 일상
시장에는 이미 디자이너의 작업을 보조하는 수많은 도구들이 존재한다. Figma AI, Galileo AI, Uizard 같은 도구들이 와이어프레임 생성과 UI 초안 작업을 자동화하고 있고, 글로벌 테크 기업들은 내부적으로 디자인 시스템 기반의 AI 생성 파이프라인을 구축하는 중이다.
그러나 이러한 범용 도구들의 공통적인 한계가 있다. 그것들은 어떤 팀의 제품 철학도 모르고, 고객 세그먼트도 모르며, 팀이 쌓아온 UX 패턴의 맥락도 담지 못한다. 결과물이 그럴듯해 보여도 실무에 그대로 쓰기에는 항상 어딘가 어긋난 무언가가 있다.
직군 경계의 해체
더 큰 그림으로 보면, AI는 전통적으로 고도의 전문성을 요구하던 영역들을 ‘접근 가능한’ 영역으로 바꾸고 있다. 기획자가 디자인 시스템의 가이드 안에서 직접 고도화된 결과물을 뽑아낼 수 있게 되고, 디자이너가 코드의 논리를 직접 다루며 개발자와 동등하게 구현을 논의할 수 있게 된다. 이것은 각 직군의 전문성이 사라진다는 이야기가 아니라, 그 전문성이 시스템화되어 조직 전체의 역량으로 확산된다는 이야기다.
팀스파르타 디자인팀이 목표로 하는 것이 바로 이것이다. 디자인을 해본 적 없는 동료들조차 디자인팀의 원칙이 투영된 수준 높은 결과물을 만들어낼 수 있는 시스템. 누구나 주저 없이, 그리고 빠르게 높은 품질의 실험을 시도할 수 있는 환경.
3. 설계 철학: 구조를 어떻게 결정했는가
에이전트 구축을 시작할 때 가장 먼저 부딪힌 것은 “구조를 어떻게 잡을 것인가” 라는 질문이었다.
첫 번째 시도: 기존 프로세스를 그대로 따르기
자연스러운 첫 번째 생각은 기존의 디자인 프로세스를 그대로 에이전트 구조에 이식하는 것이었다. 발견 → 정의 → 디자인 → 테스트 → 전달이라는 그 익숙한 순서대로 에이전트 기능을 나열하는 방식. 그런데 Claude Code를 통한 실험을 거듭하면서 이 접근이 AI의 본질적 특성과 맞지 않는다는 것을 깨달았다.
AI가 바꾸는 업무 문법
AI가 개입하는 순간, 선형적 프로세스의 전제가 흔들린다. 예컨대 이런 시나리오가 가능해진다:
- 최소한의 기획만 한 뒤 곧바로 프로토타입을 배포하고, 그 결과물을 보며 역순으로 기획서를 다듬는다.
- Figma에서 디자인을 완성하기 전에, 먼저 AI로 개발한 페이지로 사용성 테스트(UT)를 진행하거나 설문을 한다.
- 크리틱에서 받은 피드백을 UI 디자인에 즉시 반영하고, 그 결과를 다시 리서치 인사이트와 교차 검증한다.
이 유연함을 수용하려면 ‘순서(sequence)’ 중심의 구조가 아니라, ‘기능과 목적 단위(function & purpose)’ 중심의 구조가 필요하다. 팀스파르타 디자인팀이 선택한 것이 바로 이것이다. 어떤 순서로 사용하든, 어떤 스킬에서 어떤 스킬로 건너뛰든 자유롭게 작동하는 모듈형 구조.
4. 좋은 에이전트의 4가지 기준
단순히 편리한 도구를 만드는 수준을 넘어, 팀스파르타 전체의 생산성을 끌어올리기 위해 네 가지 설계 기준을 수립했다. 이 기준들은 에이전트의 기능 하나하나를 평가하고 정제하는 척도로 사용되었다.
① 직관적인 접근성 (Intuitive Accessibility)
디자인 전문가가 아닌 기획자, 개발자, 마케터 등 타 직무의 동료도 필요한 스킬을 직관적으로 찾아 쓸 수 있어야 한다. 진입 장벽이 낮아야 한다는 말이다. 스킬의 명칭, 설명, 진입 흐름이 디자인 용어에 익숙하지 않은 사람도 바로 이해할 수 있는 수준으로 설계되어야 한다.
이 기준은 단순한 UX 요구사항이 아니라, 에이전트의 존재 이유와 직결된다. 디자이너만 쓰는 도구라면 굳이 AI 에이전트를 구축할 이유가 없다. 이것은 조직 전체의 디자인 역량을 민주화하기 위한 도구이기 때문에, 접근성은 본질적 조건이다.
② 유연한 연결성 (Flexible Connectivity)
스킬들이 독립적인 섬이 아니라 서로 자유롭게 연결되고 이어질 수 있어야 한다. 리서치를 하다가 즉시 크리틱을 받고, 크리틱의 피드백을 UI 디자인에 바로 반영하는 흐름이 자연스럽게 이어져야 한다는 것이다.
기존 도구들의 문제 중 하나는 각 단계가 단절되어 있다는 점이다. 리서치 도구에서 얻은 인사이트를 복사해서 디자인 도구에 붙여넣고, 다시 피드백 도구로 옮기는 반복적인 컨텍스트 스위칭. 이 에이전트는 그 흐름을 하나의 연속적인 경험으로 엮는 것을 목표로 한다.
③ 일관된 맥락 유지 (Consistent Context)
이 기준이 아마도 가장 독특하고 핵심적인 차별점이다. 제품 원칙, 고객 정의, 디자인 시스템 등 팀스파르타만의 ‘중앙 정책’을 모든 스킬이 공유하며 일관된 결과물을 만들어야 한다.
범용 AI 도구가 아무리 강력해도 해결하지 못하는 것이 바로 이 맥락의 일관성이다. 팀스파르타의 타겟 고객이 누구인지, 제품의 보이스 앤 톤이 어떠한지, 어떤 UI 패턴을 금기시하는지, 어떤 접근성 원칙을 지향하는지 — 이 모든 것이 모든 스킬에 통일되게 반영되어야 한다. 그렇지 않으면 리서치 에이전트와 UI 디자인 에이전트가 제각각 다른 방향을 향하게 된다.
④ 즉시 활용 가능한 완성도 (Production-Ready Quality)
마지막 기준은 실용성이다. 실무에서 실제 사용자 경험에 문제없는 수준의 결과물을 제공해야 한다. “AI가 초안을 잡아주면 사람이 갈아엎는다”는 구조가 아니라, AI의 결과물이 곧 실무 투입 가능한 수준이어야 한다는 것이다.
이를 위해 스킬은 검증된 기준과 맥락을 바탕으로 동작하며, 임의 추측 없이 일관된 품질을 유지한다. 이 기준은 에이전트 설계 과정에서 가장 많은 반복 실험이 필요한 부분이기도 하다. 어떤 프롬프트 구조와 어떤 컨텍스트 주입 방식이 실무 수준의 결과물을 안정적으로 보장하는가를 찾아내는 것은 결국 수많은 시도와 검증의 과정이다.
5. 전체 에이전트 구조 개요
팀스파르타 디자인팀이 설계한 AI 에이전트는 크게 두 가지 범주로 나뉜다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌──────────────────────────────────────────────────────────────┐
│ 중앙 정책 (Central Policy) │
│ 제품 원칙 · 고객 정의 · 디자인 시스템 · 브랜드 가이드라인 │
└────────────────────────────┬─────────────────────────────────┘
│ 실시간 참조
┌───────────────────┴────────────────────┐
▼ ▼
┌─────────────────────────────────┐ ┌────────────────────┐
│ Product Design AI Agent │ │ User AI Agent │
│ │ │ │
│ • Research (리서치) │ │ • AI-persona │
│ • UX Writing (UX 라이팅) │ │ • Clone-AI │
│ • UI Design (UI 디자인) │ │ │
│ • Critique (크리틱) │ └────────────────────┘
│ • Handoff (핸드오프) │
└─────────────────────────────────┘
Product Design AI Agent는 디자인 실무의 5개 핵심 영역을 커버하는 에이전트로, 각 스킬이 독립적으로도, 연계해서도 동작한다.
User AI Agent는 디자인팀을 넘어 전사 모든 구성원이 활용할 수 있는 가상 사용자 시뮬레이터로, 비즈니스 의사결정의 검증 도구 역할을 한다.
6. Product Design AI Agent — 5대 핵심 기능 상세 분석
6-1. Research (리서치)
리서치 영역은 세 가지 하위 스킬로 구성되어 있다.
Plan-research (리서치 계획)
“사용자와 대화하며 리서치 종류를 파악하고 계획 문서 작성”
이 스킬은 리서치 설계의 출발점이다. 현재 팀이 직면한 문제 상황을 입력하면, 그에 적합한 리서치 유형(정성 인터뷰, 설문, 행동 데이터 분석, 경쟁사 벤치마킹 등)을 제안하고 구체적인 실행 계획 문서를 생성해준다.
중요한 것은 이 스킬이 단순히 리서치 방법론을 나열하는 것이 아니라는 점이다. 팀스파르타의 제품 맥락과 고객 정의를 중앙 정책에서 실시간으로 참조하여, 지금 이 제품의 이 문제를 해결하기에 가장 적합한 리서치 방식을 제안한다. 예컨대 타겟 고객이 학습자 집단이라면, 그들의 동기와 장벽을 탐색하기에 적합한 특정 인터뷰 프레임을 자동으로 채택하는 방식이다.
Synthesize-research → Organize-survey / Analyze-survey → Organize-interview / Analyze-interview
리서치 실행 이후의 데이터 처리 단계도 세분화되어 있다. 설문과 인터뷰 각각에 대해 데이터를 정리하는 Organize 스킬과, 그 데이터에서 패턴과 인사이트를 도출하는 Analyze 스킬이 쌍으로 존재한다.
- Organize-survey: 정량과 정성 응답 데이터를 구조화한다.
- Analyze-survey: 분포 분석, 세그먼트별 차이, 주관식 텍스트의 패턴을 추출한다.
- Organize-interview: 녹취록, 노트를 발화 단위로 구조화하고 원문을 보존한다.
- Analyze-interview: 테마코딩, 패턴 추출, 참여자 간 공통점과 차이점을 분석한다.
Organize-UT / Analyze-UT (사용성 테스트 처리)
- Organize-UT: 테스트 로그, 관찰 노트를 테스크플로우 단위로 구조화한다.
- Analyze-UT: 태스크 성공률, 오류 패턴, 행동 관찰 패턴을 테마코딩하여 실행 가능한 인사이트로 변환한다.
Archive-research / Archive-user (리서치 자산화)
- Archive-research: 개별 리서치 결과를 리서치 DB에 저장·관리한다.
- Archive-user: 참여자 정보를 유지 DB로 관리하여 반복 활용 가능한 패널 풀을 구축한다.
이 아카이빙 기능이 중요한 이유는 단기적 결과물 생성을 넘어, 지속 가능한 지식 자산으로서의 리서치를 구현하기 때문이다. 리서치 결과가 한 번의 프로젝트로 소비되고 사라지는 것이 아니라, 다음 리서치를 설계할 때의 참조 자원이 되고, 유저 에이전트의 페르소나 구성 재료가 된다.
6-2. UX Writing (UX 라이팅)
UX 라이팅 영역은 세 가지 핵심 스킬로 이루어져 있다.
UX-writing (맥락별 카피 생성)
“와이어프레임을 바탕으로 브랜드 가이드에 맞는 카피 작성”
이 스킬은 팀의 보이스&톤 가이드와 제품 맥락을 바탕으로 최적화된 UX 카피를 제안한다. 단순한 문구 생성이 아니라, 특정 화면의 목적(전환 유도, 오류 안내, 빈 상태 메시지 등)과 사용자의 감정 상태를 고려한 카피 제안이다.
와이어프레임 자동 반영 기능도 포함된다. 기획 단계의 와이어프레임을 입력하면 각 UI 요소에 최적의 카피를 즉시 배치해준다. 이는 기획자가 와이어프레임 작업 단계에서 더미 텍스트 대신 실제 수준의 카피를 확인하며 기획을 정교화할 수 있게 해준다.
Writing-Workflow (라이팅 품질 관리 파이프라인)
“라이팅 대백과 기반으로 문장의 순차적 검토 및 라이팅 품질 향상”
이 스킬은 작성된 카피의 품질 관리 파이프라인이다. 팀스파르타가 정의한 라이팅 가이드라인(이른바 ‘대백과’)을 기반으로, 작성된 카피가 팀의 원칙에 부합하는지 순차적으로 검토하고 개선 방향을 제시한다.
Term-check / Spell-check (용어 및 맞춤법 검수)
- Term-check: 팀스파르타의 서비스 내 공식 용어와 표현의 적합성을 검사한다. 예컨대 제품 내에서 일관되게 사용해야 하는 특정 용어가 있다면, 카피 전체에서 그 일관성을 검증한다.
- Spell-check: 맞춤법과 띄어쓰기 기능을 검사하는 기본 검수 스킬이다.
이 두 스킬의 조합은 UX Writing의 마지막 품질 게이트 역할을 한다. 아무리 좋은 카피도 용어 불일치나 맞춤법 오류가 있으면 제품의 신뢰도를 훼손하기 때문이다.
6-3. UI Design (UI 디자인)
UI 디자인 영역은 화면 생성과 변환에 관한 네 가지 스킬로 구성된다.
UI pattern Analyzer (UI 패턴 분석기)
“팀스파르타 주요 화면을 학습하고 UI/디자인 패턴을 분석”
이 스킬은 다른 UI 생성 스킬들의 기반이 되는 분석 엔진이다. 팀스파르타의 기존 서비스 화면들을 학습하여 반복되는 UI 패턴, 컴포넌트 조합 방식, 레이아웃 원칙을 인식하고 구조화한다. 이를 통해 새로운 화면을 생성할 때 팀의 디자인 언어와 일관된 결과물을 만들어낼 수 있다.
UI generator (UI 자동 생성기)
“STACK 컴포넌트와 디자인 패턴을 기반으로 Figma에 UI 자동 생성”
팀스파르타의 디자인 시스템인 STACK의 컴포넌트 라이브러리와 앞서 분석된 디자인 패턴을 기반으로, Figma 파일에 UI를 자동으로 생성한다. 단순한 레이아웃 배치가 아니라, 팀이 사용하는 실제 컴포넌트를 활용한 생산 수준의 UI를 생성하는 것이다.
이 스킬이 의미 있는 이유는 두 가지다. 첫째, 디자이너가 반복적인 컴포넌트 배치 작업에서 해방되어 더 본질적인 디자인 판단에 집중할 수 있다. 둘째, 디자인 경험이 없는 동료도 요구사항을 텍스트로 입력하면 팀의 디자인 시스템에 맞는 화면을 생성받을 수 있다.
Responsive converter (반응형 자동 변환기)
“생성된 UI의 PC/모바일/태블릿 반응형 레이아웃 자동 변환”
생성된 UI를 PC, 태블릿, 모바일 각각의 디바이스 규격에 맞게 자동으로 변환한다. 반응형 디자인 작업은 동일한 화면을 세 가지 뷰포트에 맞게 반복 조정해야 하는 노동집약적 작업이었는데, 이를 자동화함으로써 디자인 실행 속도를 대폭 높일 수 있다.
Design-to-stack-figma (레퍼런스 → Figma 자동 변환)
“URL, 이미지 등 소스를 STACK 기반으로 Figma에 UI 자동 생성”
외부 레퍼런스(다른 서비스의 화면 URL 또는 이미지)를 분석하여, 팀스파르타의 디자인 시스템(STACK) 기반으로 재해석한 Figma 파일을 생성한다. “이 서비스의 이 기능을 우리 스타일로 구현한다면 어떤 모습일까?”를 즉각적으로 시각화할 수 있게 해주는 스킬이다.
Interaction (인터랙션 설계)
“인터랙션 설계”
화면의 동적 요소, 즉 버튼 클릭 반응, 화면 전환, 로딩 상태, 애니메이션 등 인터랙션을 설계하는 스킬이다. 구조적 레이아웃 생성에서 한 걸음 더 나아가, 사용자가 실제로 경험할 인터랙션 흐름까지 정의한다.
6-4. Critique (크리틱)
크리틱 영역은 디자인의 품질을 다각도에서 검증하는 세 가지 스킬로 구성된다.
Design-critique (통합 디자인 검수)
“비즈니스 목표 정렬, 사용자 중심성, 시각적 위계, 접근성, Stack DS 적용 여부까지 분석”
이것은 디자인 결과물에 대한 종합 진단 스킬이다. 단순히 “예쁜가, 안 예쁜가”를 넘어서, 다섯 가지 차원에서 입체적으로 평가한다.
- 비즈니스 목표 정렬: 이 디자인이 팀스파르타의 비즈니스 목표와 제품 전략에 부합하는가
- 사용자 중심성: 타겟 사용자의 멘탈모델과 니즈를 반영하고 있는가
- 시각적 위계: 정보의 중요도가 시각적으로 적절하게 표현되고 있는가
- 접근성: WCAG 기준 등 접근성 요구사항을 충족하는가
- 디자인 시스템 적용: STACK의 컴포넌트와 패턴을 올바르게 활용하고 있는가
이 다섯 가지를 동시에 검토함으로써, 어느 하나에 치중된 단편적 피드백이 아닌 균형 잡힌 통합 분석을 제공한다.
UX-critique / UI-critique (전문 영역별 상세 검수)
- UX-critique: 사용자 흐름, 정보 구조, 인터랙션의 사용성을 집중 분석한다. “이 흐름이 사용자 입장에서 자연스러운가”, “이 인터랙션이 직관적으로 이해되는가” 같은 질문에 답한다.
- UI-critique: 시각적 위계, 컴포넌트, 타이포그래피, 컬러의 일관성을 집중 분석한다. 더 구체적인 시각 언어 레벨에서의 피드백을 제공한다.
두 스킬의 분리는 피드백의 목적과 레벨을 명확히 하기 위함이다. UX 레벨의 구조적 문제와 UI 레벨의 표현적 문제는 서로 다른 판단 기준과 수정 방향을 요구하기 때문이다.
Design-QA (최종 배포 전 품질 검증)
“STACK 적용 여부 확인 및 디자인 QA”
이 스킬은 크리틱 영역의 마지막 단계이자, 핸드오프로 넘어가기 전의 최종 게이트다. 디자인 시스템(STACK)의 적용이 올바른지를 체계적으로 확인하고, 배포 전 예상되는 사용자 경험 및 정책적 오류를 사전에 발견한다.
특히 주목할 점은 잠재 리스크 진단 기능이다. 단순한 스펙 준수 여부 확인을 넘어서, 접근성 위반, 다크 패턴 여부, 인터페이스 공정성, 제품 신뢰도에 영향을 미칠 수 있는 요소들을 선제적으로 점검한다. 이는 출시 후 사후 대응이 아닌, 출시 전 사전 예방의 관점에서 제품 안정성을 확보하는 접근이다.
6-5. Handoff (핸드오프)
핸드오프 영역은 디자인에서 개발로의 전달을 체계화하는 하나의 핵심 스킬로 구성된다.
Design-handoff (개발 핸드오프 문서 자동화)
“개발 핸드오프 스펙 전달 (상태별 동작, 예외 명세)”
디자인-개발 협업의 마찰이 가장 크게 발생하는 지점은 바로 핸드오프 단계다. 디자이너가 정적 화면을 넘기고 나서 “이 버튼의 비활성화 상태는 어떻게 되나요?”, “에러 케이스는 어떻게 처리하나요?” 같은 질문들이 쏟아지는 상황이 반복된다.
이 스킬은 그 간극을 메운다. 구체적으로 세 가지 기능을 제공한다.
- 핸드오프 정책 정의: 개발 구현에 필요한 핵심 정책과 가이드라인을 수립한다. “이 컴포넌트의 동작 원칙은 무엇인가”를 명문화한다.
- 동작 스펙 자동화: 상태별(State) 동작 방식과 예외 조건(Edge Case)을 명세화한다. 기본 상태, 호버, 클릭, 비활성화, 로딩, 에러 등 모든 상태를 체계적으로 정의한다.
- 커뮤니케이션 효율화: 구현에 필요한 모든 상세 정보를 스펙 문서 형태로 즉시 정리하여, 개발자가 별도의 문의 없이 구현에 착수할 수 있는 수준의 문서를 제공한다.
이 스킬은 디자이너의 시간 효율을 높일 뿐 아니라, 개발자 입장에서도 모호성이 제거된 명확한 스펙을 받게 되어 구현 품질과 속도 모두를 향상시킨다.
7. User AI Agent — 가상 사용자 에이전트
User AI Agent는 Product Design AI Agent와는 별개의 독립적인 에이전트로, 디자인팀을 넘어 전사 모든 구성원이 활용할 수 있도록 설계되어 있다.
개념
“우리의 타겟 고객이라면 이 버튼의 문구를 어떻게 받아들일까?” — 이 질문은 제품 팀이 하루에도 수십 번 스스로에게 던지는 질문이다. 그런데 실제로 이 질문에 답하려면 사용자 인터뷰를 설계하고, 참여자를 모집하고, 진행하고, 분석하는 과정이 필요하다. 빠른 검증이 필요한 순간마다 그 과정 전체를 거칠 수는 없다.
User AI Agent는 이 간극을 채운다. 팀스파르타의 페르소나 정의와 세그먼트 분류를 학습한 가상의 AI 유저가, 실시간으로 질문에 응답하고 피드백을 제공하는 것이다.
두 가지 핵심 스킬
AI-persona (가상 유저 대화)
“유저 데이터 기반 대표 가상 고객과 대화하며 새로운 집단적 경향과 감정을 탐색”
이 스킬은 팀스파르타의 실제 고객 데이터를 바탕으로 구성된 대표 페르소나와 대화하는 기능이다. 단순한 가상 캐릭터가 아니라, 실제 리서치 데이터에서 추출된 행동 패턴, 니즈, 감정적 특성을 반영한 AI 페르소나다.
기획자가 새로운 기능의 아이디어를 던지면 “이 타입의 고객은 이렇게 반응할 것 같다”는 즉각적인 피드백을 받을 수 있고, 마케터가 광고 카피를 테스트하고 싶을 때 “이 세그먼트의 고객은 이 표현을 이렇게 읽을 것 같다”는 반응을 시뮬레이션할 수 있다.
Clone-AI (리서치 데이터 기반 검증)
“실제 유저 1명의 인터뷰·리서치 데이터를 복제해 새로운 집단적 경향과 감정 문제를 탐색”
AI-persona가 여러 고객 데이터를 종합한 ‘대표 페르소나’와의 대화라면, Clone-AI는 특정 실제 사용자 한 명의 인터뷰 데이터를 복제하여 그 사람의 관점에서 검증하는 기능이다. “지난 달에 인터뷰한 30대 직장인 학습자라면 이 UI에서 어떤 어려움을 느낄까?”를 그 실제 인터뷰 데이터 기반으로 시뮬레이션하는 것이다.
활용 범위의 확장
User AI Agent의 가장 큰 의미는 디자인팀 내부를 넘어 사업 전체로 활용 범위가 확장된다는 점이다. 영업, 마케팅, 고객 성공, 사업 개발 등 어떤 부서에서든 “우리 고객이라면 이것을 어떻게 받아들일까?”라는 질문을 즉시 던지고 검증할 수 있는 도구가 되는 것이다.
8. 각 스킬의 세부 기능 매핑표
| 대분류 | 스킬명 | 핵심 기능 | 주요 입력 | 주요 출력 |
|---|---|---|---|---|
| Research | Plan-research | 리서치 유형 제안 및 계획 | 문제 상황 설명 | 리서치 실행 계획 문서 |
| Synthesize-research | 결과 통합 분석 | 수집된 리서치 데이터 | 통합 인사이트 보고서 | |
| Organize-survey | 설문 데이터 구조화 | 정량·정성 응답 데이터 | 구조화된 데이터셋 | |
| Analyze-survey | 설문 패턴 분석 | 구조화 데이터 | 분포, 차이, 패턴 보고서 | |
| Organize-interview | 인터뷰 데이터 정리 | 녹취록·노트 | 발화 단위 구조화 문서 | |
| Analyze-interview | 인터뷰 패턴 추출 | 구조화 인터뷰 데이터 | 테마코딩, 인사이트 | |
| Organize-UT | UT 로그 구조화 | 테스트 로그·관찰 | 태스크플로우 단위 문서 | |
| Analyze-UT | UT 패턴 분석 | 구조화 UT 데이터 | 태스크 성공률, 오류 패턴 | |
| Archive-research | 리서치 DB 아카이빙 | 완료된 리서치 | 리서치 DB 레코드 | |
| Archive-user | 참여자 정보 관리 | 참여자 데이터 | 유저 패널 DB | |
| UX Writing | UX-writing | 맥락별 카피 생성 | 화면 목적·보이스톤 | 최적화된 UX 카피 |
| Writing-Workflow | 라이팅 순차 검토 | 작성된 카피 | 가이드 준수 피드백 | |
| Term-check | 용어 적합성 검사 | 카피 텍스트 | 용어 일관성 검증 결과 | |
| Spell-check | 맞춤법·띄어쓰기 검사 | 텍스트 | 교정 결과 | |
| UI Design | UI pattern Analyzer | UI 패턴 학습·분석 | 기존 서비스 화면 | 패턴 분류 및 구조 |
| UI generator | Figma UI 자동 생성 | 요구사항·패턴 | Figma 화면 파일 | |
| Responsive converter | 반응형 자동 변환 | PC 기준 UI | PC/태블릿/모바일 UI | |
| Design-to-stack-figma | 레퍼런스 → Figma 변환 | URL·이미지 | STACK 기반 Figma 파일 | |
| Interaction | 인터랙션 설계 | 화면 구조 | 동작 정의 문서·프로토타입 | |
| Critique | Design-critique | 통합 디자인 검수 | 디자인 결과물 | 다차원 분석 피드백 |
| UX-critique | UX 사용성 검수 | 화면·흐름 | UX 개선 피드백 | |
| UI-critique | UI 시각 일관성 검수 | 화면 디자인 | UI 개선 피드백 | |
| Design-QA | 최종 배포 전 품질 검증 | 완성 디자인 | QA 체크리스트 결과 | |
| Handoff | Design-handoff | 개발 스펙 자동화 | 완성 디자인 | 상태별 스펙 문서 |
| User Agent | AI-persona | 가상 유저 대화 | 질문·시나리오 | 페르소나 기반 피드백 |
| Clone-AI | 실제 유저 데이터 복제 시뮬레이션 | 특정 인터뷰 데이터 | 개인 관점 기반 반응 |
9. 중앙 정책(Central Policy)의 역할
에이전트 구조에서 종종 간과되지만 사실 가장 중요한 것이 중앙 정책(Central Policy) 의 존재다. 이미지 상단의 검은 헤더 영역에 위치한 “Product Design AI Agent”라는 제목 아래에 내포된 이 개념은 모든 스킬이 공유하는 공통 컨텍스트다.
중앙 정책이 담는 것들
- 제품 원칙: 팀스파르타가 제품을 만들 때 지향하는 원칙들. “우리는 어떤 종류의 UX를 지향하는가”, “어떤 디자인 패턴을 금기시하는가”
- 고객 정의: 타겟 고객의 세그먼트, 특성, 니즈, 행동 패턴. 이것이 있어야 모든 스킬이 “우리 고객에게 맞는” 결과물을 생성할 수 있다.
- 디자인 시스템: STACK 컴포넌트 라이브러리, 컬러 팔레트, 타이포그래피 스케일, 스페이싱 시스템 등 시각 언어의 전체 체계
- 브랜드 가이드라인: 보이스 앤 톤, 커뮤니케이션 원칙, 브랜드 아이덴티티
실시간 참조의 의미
각 스킬이 이 정책을 ‘실시간으로 참조’한다는 것은, 중앙 정책이 업데이트되면 모든 스킬의 동작이 자동으로 업데이트된다는 의미다. 예컨대 타겟 고객 정의가 변경되면, 리서치 스킬의 인사이트 분석 방향, UX 라이팅 스킬의 카피 톤, UI 디자인 스킬의 패턴 선택 등이 모두 새로운 고객 정의를 반영하여 동작하게 된다.
이것이 팀스파르타 에이전트가 범용 AI 도구와 가장 크게 차별화되는 지점이다. 모든 스킬이 하나의 일관된 정체성 위에서 작동한다.
10. Claude Code와의 연결: 기술 구현 방식
아티클에서는 이 에이전트 시스템이 Claude Code를 기반으로 구축되고 있음을 명시하고 있다.
왜 Claude Code인가
Claude Code는 Anthropic이 제공하는 코드 에이전트 도구로, 터미널 환경에서 코드 작성, 파일 조작, 외부 도구 호출 등을 자율적으로 수행할 수 있다. 디자인팀이 Claude Code를 선택한 이유는 몇 가지로 추론할 수 있다.
첫째, Figma API 연동이 가능하다. UI generator, Responsive converter, Design-to-stack-figma 등의 스킬들은 Figma 파일을 직접 생성하거나 수정해야 하는데, Claude Code를 통해 Figma API를 호출하고 파일을 자율적으로 조작하는 것이 가능하다.
둘째, 데이터베이스 연동이 가능하다. Archive-research, Archive-user 스킬들은 리서치 데이터를 실제 DB에 저장하고 관리해야 한다. Claude Code는 DB 쿼리 실행과 파일 시스템 접근이 가능하다.
셋째, 프롬프트 엔지니어링의 코드화다. 각 스킬의 동작 방식을 자연어 지시가 아닌 코드로 정밀하게 정의하고, 버전 관리하고, 팀 내 공유할 수 있다. 이것은 에이전트의 품질을 안정적으로 유지하는 데 핵심적이다.
비선형 프로세스를 지원하는 기술적 설계
아티클에서 강조하는 “순서가 아닌 기능과 목적 단위의 분류”는 기술적으로도 중요한 함의를 갖는다. 각 스킬이 독립적인 모듈로 구현되어 있어, 사용자가 어떤 순서로 어떤 스킬을 호출하든 일관되게 작동해야 한다. 이를 위해 중앙 정책이 모든 스킬에 공통 컨텍스트로 주입되고, 스킬 간 결과물 전달이 표준화된 포맷으로 이루어지는 구조가 필요하다.
11. 이 구조가 가져오는 조직 변화
팀스파르타 디자인팀이 구축하려는 것은 단순한 내부 도구가 아니다. 이 에이전트 시스템은 조직이 일하는 방식 자체를 재구성한다.
디자이너 역할의 재정의
디자이너는 반복적인 실행 작업에서 벗어나 더 고차원적인 판단과 방향 설정에 집중할 수 있게 된다. UI 컴포넌트를 하나하나 배치하는 대신, AI가 생성한 결과물의 품질을 판단하고 방향을 조정하는 역할. 이것이 Jenny Wen이 말한 “만드는 사람에서 방향을 잡아주는 사람”으로의 전환이다.
직군 간 협업의 새로운 가능성
기획자가 직접 UI 초안을 생성하고 디자인 팀에 리뷰를 요청하는 것이 가능해진다. 마케터가 고객 페르소나와 직접 대화하며 캠페인 카피를 검증할 수 있다. 개발자가 핸드오프 스펙 문서를 보며 디자이너에게 별도 문의 없이 구현을 시작할 수 있다.
이것은 각 직군이 자신의 전문 영역을 침범하는 것이 아니라, 서로의 전문성이 시스템을 통해 공유되면서 협업의 비용이 낮아지는 변화다.
실험 문화의 가속
“누구나 높은 품질의 실험을 주저 없이, 그리고 빠르게 시도할 수 있는 환경”이라는 목표는 곧 실험 비용의 민주화를 의미한다. 지금까지 “이걸 실험해보려면 디자인 리소스가 필요한데…“라는 병목이 있었다면, 이제 그 병목이 사라진다. 누구든 가설을 세우고 즉시 시각화하고 검증하는 사이클이 가능해진다.
12. 한계와 남은 과제들
이 시스템이 아무리 잘 설계되어 있어도, 몇 가지 본질적인 한계와 과제는 존재한다.
중앙 정책의 유지 비용
중앙 정책이 모든 스킬의 품질을 좌우하기 때문에, 이 정책을 최신 상태로 유지하는 비용이 상시 발생한다. 제품 전략이 바뀌거나, 타겟 고객이 확장되거나, 디자인 시스템이 업데이트될 때마다 중앙 정책도 갱신되어야 한다. 이것을 누가, 얼마나 자주, 어떤 프로세스로 관리할 것인가는 운영 차원에서 중요한 과제다.
AI 출력의 품질 편차
스킬의 완성도 기준인 “임의 추측 없이 일관된 품질”은 이상적인 목표이지만, 현실적으로 AI 출력은 입력의 품질과 맥락의 완전성에 따라 편차가 발생한다. 특히 복잡하고 새로운 유형의 문제에 대해 AI가 얼마나 정확하게 팀의 판단을 대리할 수 있는가는 지속적인 검증과 개선이 필요한 영역이다.
인간 전문성의 경계
이 시스템이 강조하는 것은 “대체가 아닌 확장”이지만, 어떤 판단이 AI에게 맡겨질 수 있고 어떤 판단은 반드시 인간 전문가가 해야 하는지의 경계를 지속적으로 재정의하는 작업이 필요하다. AI 비평(Critique)이 인간 디자이너의 심미적·윤리적 판단을 완전히 대신할 수는 없다.
13. 결론: 대체가 아닌 확장
팀스파르타 디자인팀이 구축하고 있는 것은 결국 “생각의 파이프라인” 이다. 프로덕트 디자이너를 대체하는 로봇이 아니라, 디자이너의 전문성을 시스템화하여 조직 전체의 역량으로 확산시키는 구조다.
이 아티클이 던지는 핵심 메시지는 세 가지다.
첫째, AI 시대의 디자인 전문성은 “무엇을 만드는 능력”에서 “어떻게 만들어야 하는지 아는 능력”으로 이동한다. 손으로 직접 그리는 스킬보다, 어떤 결과물이 좋은 결과물인지 판단하는 기준과 안목이 더 중요해진다.
둘째, 범용 AI 도구의 한계는 맥락의 부재다. 팀 고유의 제품 철학, 고객 이해, 디자인 원칙이 깊이 투영된 에이전트만이 실무에 즉시 투입 가능한 수준의 가치를 만들어낼 수 있다.
셋째, AI 에이전트는 개인의 도구가 아니라 조직의 인프라다. 디자이너만 쓰는 도구가 아니라, 디자이너의 전문성이 조직 전체로 흐르게 하는 파이프라인으로 설계될 때 비로소 진정한 비즈니스 임팩트를 만들 수 있다.
앞으로 팀스파르타 디자인팀이 각 스킬을 어떻게 구현하고 실제 제품에 어떻게 녹여냈는지에 대한 기록이 이어질 예정이다. 이 시도는 단순한 도구 도입기가 아니라, AI 시대에 디자인 조직이 어떻게 진화해야 하는지에 대한 하나의 실험이자 답안이다.
작성: 곽진 & 고우정, 프로덕트 디자이너 @ 팀스파르타
원문 발행일: 2026년 4월 2일
분석 정리: Claude (Anthropic)