-
AI 제품 설계 8년 이상 경력을 가진 Barron Webster는 Figma에서 세계 최초의 '모델 디자이너' 역할을 수행 중이며, 이는 디자이너가 LLM과 직접 협업하는 새로운 하이브리드 직군의 등장을 의미
- 모델 디자이너의 핵심 업무는 파운데이션 모델의 한계를 보완하고, AI 기능 설계를 위한 새로운 도구와 사고방식을 디자인 조직에 도입하는 것
- 기존 UI 디자인과 달리 AI 제품 설계는 모델의 동작을 먼저 프로토타이핑한 후 UI를 설계해야 하며, 그렇지 않으면 실제 작동과 맞지 않는 UI를 만들 위험 존재
-
평가(Evals) 시스템 구축이 AI 제품 품질 관리의 핵심이며, 디자이너가 빠른 피드백 루프로 평가 케이스를 조작하고 실행할 수 있는 도구 필요
- AI 시대의 디자이너는 모델의 입출력 구조를 깊이 이해하고 시스템 전체를 파악하는 역량이 필수적이며, 단순 UI 제작자가 아닌 의사결정 참여자가 되어야 함
Barron Webster 소개
-
8년 이상 AI 제품에 깊이 관여해 온 디자이너로, 하이프 사이클을 꿰뚫어 보는 통찰력 보유
- Google Creative Lab에서 2017년 출시된 Teachable Machine 설계에 참여, 이는 소비자가 AI 모델을 학습시킬 수 있는 최초의 도구
- 이후 Replit에서 AI 기능 작업, 스타트업에서 유니콘으로 성장하는 데 기여
- 최근 Figma에 세계 최초의 모델 디자이너로 합류
모델 디자이너의 역할
- Figma AI 리서치 팀 소속으로, 두 가지 주요 임무 수행
-
파운데이션 모델에서 최대한 성능을 뽑아내도 충분하지 않은 상황 해결
- Figma의 데이터가 독점 포맷이라 파운데이션 모델이 잘 처리하지 못하므로 이 격차를 메우는 작업
- 디자인 조직에 새로운 도구와 AI 우선 사고방식 도입
- Figma는 대기업으로 많은 디자이너가 AI 경험 설계 경험이 없음
- AI 기능 설계는 전통적인 제품 설계와 다름
- 디자이너가 엔지니어가 되지 않고도 프로세스 초기에 AI 기능의 핵심을 프로토타이핑할 수 있는 도구 구축이 목표
- 직접 경험하지 않은 기능의 UI를 설계하면 실제 작동과 맞지 않는 완벽한 케이스용 UI를 만들 위험 존재
AI 디자인 도구의 미래
- 가장 기대하는 도구는 디자이너가 빠른 피드백 루프로 평가 케이스를 조작하고 실행할 수 있는 것
- Figma 파일에서 AI 기능이 작동하지 않으면 즉시 테스트 케이스로 추가 가능해야 함
- 시스템 프롬프트 조정, 다른 모델 시도 등이 바로 가능해야 함
- 현재 피드백 루프가 너무 느린 것이 문제
-
모든 좋은 디자인 도구의 핵심은 피드백 루프 제거 또는 축소
- 평가 세트 구축 작업의 상당 부분이 데이터 정리를 위한 수작업
- Figma에서 AI 기능을 차별화하는 방법도 고민 중
- 디자인 플랫폼이므로 Claude Code나 Cursor보다 더 잘 설계된 출력물 기대
- 타겟팅된 평가 전략과 좋은 디자인의 프록시 찾기가 관건
- 이는 아트스쿨 수준의 철학적 질문이기도 함
Barron의 AI 입문 경험
-
2014-2015년 RISD Computer Utopias 수업: LLM 이전 시대, 머신러닝 연구가 분류기 중심이던 때
- 이미지 분류 모델이 가장 흥미로웠으며, Snapchat 얼굴 필터나 Google 이미지 검색을 구동
- 콘텐츠 모더레이션과 추천 시스템이 주요 화두
- Facebook, Twitter, Cambridge Analytica 전성기로, 알고리듬 피드의 발명이 설계할 새로운 소재 창출
-
2016-2018년 Google Creative Lab: Google Lens, Google Assistant, Teachable Machine 작업
- 거의 모든 프로젝트가 모델 혁신 적용
- 텍스트 생성이 아닌 기존 콘텐츠를 정렬하거나 주석 달기에 모델 활용
- 일본 오이 농부가 TensorFlow로 오이를 분류한 사례 프로모션 진행
Replit에서의 경험
-
3년 이상 근무, AI 기능이 전무한 상태에서 시작해 AI 활용 방안 평가 역할 담당
- 모델이 계속 개선되면서 새로운 능력을 활용하면서도 신뢰할 수 있는 AI 기능 추가 방법 모색
- 기본적인 수동 트리거 기능(코드 선택 후 AI 설명, 기존 파일에 코드 생성)에서 시작
- 각 기능 출시 후 사용자 기대치 상승의 사이클 반복
- 코드 스니펫 생성 허용 → 전체 파일/프로젝트 요청
- 전체 생성 가능 → 특정 편집 요청
- 특정 편집 가능 → 처음부터 새로 시작 요청
-
기존 모델로 기능 시도 → 안 되면 대기 → 새 파운데이션 모델 출시 시 재시도 패턴
- 프로그래밍 환경의 제품 제약 사항
- 모델이 코드 작성에 뛰어나도 올바른 위치에 편집하는 방법 필요
- Sonnet 3.5 이전까지 모델이 줄 번호 처리에 취약
- 편집 정확성, 콘텐츠 중복 방지, 함수 교체를 위한 임시방편 개발 필요
- 이런 작업 대부분이 6개월~1년 후 새 모델로 무용지물화
사용자 검증으로의 전환 사례
- Replit 에이전트가 자동으로 파일 생성하고 코드 작성할 때, 에이전트가 빌드한 애플리케이션 테스트가 큰 기술적 문제
- 엔지니어링 측 접근: 샌드박스 가동, 스크린샷 기능 구축, 멀티모달 모델에 스크린샷 피드하여 클릭/입력 위치 결정
- Barron과 다른 엔지니어의 제안: 사용자에게 웹사이트를 보여주고 직접 테스트 요청
- 검증과 테스트를 사용자에게 오프로드하여 복잡한 기술적 문제 전체 우회
- 기술적 문제가 아닌 사용자 문제에 집중하는 사람이 있으면 많은 것을 건너뛰거나 단순화 가능
제품-시장 적합성 발견
- 전통적인 AI 이전 제품 전략: 계획 수립, 기존 사용자 기반, 시장/카테고리 확장 전략 수립
- AI의 급격한 변화로 Replit의 전략은 훨씬 더 반응적
- 교육 시장에서 강한 제품-시장 적합성 보유(특히 코로나 이후 원격 교육)
- AI 기능 개선으로 딜레마 발생
-
인디 개발자와 해커들은 AI 선호
- 교사들은 학생이 기초 학습을 우회할 수 있어 반대
- Replit 에이전트 출시 시 대상 사용자 불명확
- 하향식 프로젝트보다 기능 출시 후 반응 관찰이 더 성공적
- 출시 후 대화를 통해 사용자 발견: 테크 기업의 운영 담당자들로, 영업 데이터 수집이나 대시보드 구축 필요 (Zapier나 Retool 사용자와 유사)
평가(Evals) 시스템
- Replit 첫 2년간 평가를 많이 하지 않았음, 당시 관행이 널리 퍼지지 않음
- 에이전트에서는 평가를 더 적극 활용, 주로 제품 개발 지표로 사용
- 새 모델 출시 시 프로그래밍 평가 성능을 보고 앱 테스트 여부 결정
- Sandbar에서는 모델 성격에 대한 평가 작성에 많은 시간 투자
- 광범위한 업계 벤치마크 평가 외에 제품 고유의 평가 구축이 새로운 디자인 작업
- 워크플로우: 프롬프트 작성 → 프롬프트 조정 → 평가 생성 → 성능 확인 → 수동 테스트 및 주관적 피드백과 결합
- 평가 없이는 AI 작동 검증을 위한 수작업 대폭 증가
- Sandbar 평가 예시
- 답을 모르면 환각 대신 단일하고 구체적인 명확화 질문을 해야 함
- 한 번에 두 개 이상 질문 금지
- 답변 간결하게 유지 (예외 포함)
평가의 어려움
-
아첨(Sycophancy) 이 평가 작성에서 가장 어려운 주제 중 하나
- 모델이 적절한 경우 사용자에게 반박해야 한다는 개념
- 허용 가능한 실패율 결정이 제품 및 디자인 결정이 되며, 제품의 디자인 철학 일부가 됨
- 평가 결과 저조의 원인이 성능 저하가 아닌 잘못 작성된 평가인 경우 많음
- 예: "매우 간결해야 함" 평가에서 사용자가 "엄마가 돌아가셨어요"라고 하면 "그거 안됐네요"가 높은 점수 받지만 실제로 원하는 응답 아님
- 평가는 주로 회귀 방지용, 특성 충족 여부 확인
- 전통적 프로그래밍의 테스트 주도 개발(TDD) 같은 것이 AI 엔지니어링에서는 아직 드묾
- 평가를 먼저 작성하고 평가를 통과할 코드 작성하는 방식
-
평가 디자이너라는 미래 직업 가능성
- AI 성능을 팀이 이해할 수 있는 대시보드를 디자인하는 디자인 시스템 역할과 유사
Figma에서의 AI 기능 구상
-
"서비스로서의 디자인 비평" 아이디어 고려 중
- AI에게 디자인 비평 요청
- 해당 시스템의 성격에 대한 흥미로운 질문 제기
- 선택 가능한 태도(예: "Dieter Rams" 스타일) 제공 vs 기본값 설정
- 접근성이나 대비 문제(더 객관적 피드백) 집중 vs 더 넓은 범위 목표
- 실제 제품 경험에 얼마나 반영될지는 미정
평가 도구의 발전 방향
-
평가 생성 반복 속도를 줄이는 도구 희망
- 현재 평가 작업하는 모든 사람이 기본적으로 해야 하는 작업
- 매핑, 포맷, 파이프라인, 출력을 한 곳에서 볼 수 있는 인터페이스 연결
- 텍스트용 도구는 꽤 좋지만 다른 포맷용은 부족
- Design Arena 같은 유사 평가 플랫폼 존재
- 사람들이 원하는 최고의 출력에 투표하는 블라인드 사이드바이사이드 테스트
-
Figma 파일에서 직접 유사한 작업 수행 희망
- 코멘트 달기, 이슈 지적 포함
- 빠르게 테스트 세트 생성, 한 번에 실행, 100개 응답 받고 30초 내 반복 가능해야 함
- 현재 모든 조각이 작동하지만 시간이 너무 오래 걸림
모델 생성에서 디자이너의 역할
-
처음부터 학습 vs 파인튜닝 두 가지 방식 경험
- 처음부터 학습 시: 사용자 니즈가 가장 크고 불편함이 가장 심한 곳을 조직에 알리는 것이 디자이너의 최대 기여
- Replit에서 Python의 일반적이고 단순한 코드 오류에 대한 커스텀 모델 학습
- 실제 학습보다 문제 정의와 학습된 모델의 제품 적용 방법 파악에 더 관여
- 파인튜닝 시: 기존 모델, 제품, 평가가 있고 성능 향상 원할 때
- 프롬프트 작성, 평가 작성, 사용자 대화를 하는 사람이 기대 충족 여부 명확히 파악
- 프롬프트 엔지니어링이 한계에 도달하면 파인튜닝이 다음 단계
- 디자이너의 핵심 번역 역할: 사용자 가정 기억
- 모델과 긴밀히 작업하는 엔지니어/디자이너는 사용자가 세부사항을 모른다는 것을 잊을 수 있음
- "내면의 바보"를 활용해 AI 모델 특성을 모르는 순진한 사용자가 시도할 것과 막힐 곳 소통 필요
AI 제품 디자이너를 위한 조언
- 가장 지속 가능하고 영향력 있는 것: 모델의 입력과 출력을 진정으로 이해하는 데 상당한 시간 선투자
- 프롬프트는 무엇인가, 어떤 사용자 정보가 입력되는가, 어떤 도구를 호출할 수 있는가, 어떤 평가가 있는가
- 이 다이얼들을 조정할 때 어떤 일이 일어나는지 직관적으로 파악
-
깊이 이해하지 못하는 출력의 UI 제작자가 되어서는 안 됨
- "모델이 이걸 주니까 인터페이스를 디자인해라"라고 하면 할 수는 있지만 사용자 인사이트 기반 개선 제안 불가
- 후속 모델 변경에 매우 반응적으로 작업하게 됨
- 새로운 기능이 원하는 것인지 의사결정의 일부가 되어야 함, 단순 수신자가 아닌
- 코드에 익숙하지 않은 디자이너에게 어려울 수 있음
- Langsmith 같은 인터페이스가 있거나 개발 환경 직접 실행 방법 학습 필요
가장 큰 영향을 미친 사례
-
Replit 에이전트: 생성된 애플리케이션 작동 여부를 사용자에게 직접 검증 요청하도록 팀 설득
- 사용자 검증의 가장 단순한 경로에 집중하여 많은 노력 절감
-
LaMDA 출시(Google의 초기 LLM): 모델을 다양하게 시도하고 무엇이 가장 잘 작동하는지 확인하는 데 많은 시간 투자
- 당시 "프롬프팅"이라고 부르지 않았지만 다른 것인 척하고 신뢰성 있게 수행하도록 시도
- 명왕성이나 그 위성과 대화할 수 있는 데모는 수많은 시도 후 가장 잘 작동하는 것 발견 결과
- 광범위한 실험 없이 전략적으로 선택 불가능했음
디자이너의 프롬프팅
- "디자이너가 프롬프트해야 하는가"는 "디자이너가 코딩해야 하는가"와 성격이 다름
- 코딩의 경우 답이 상당히 반증 가능: ABC 기술로 XYZ 구축 가능한가? 엔지니어에게 묻는 것이 직접 아는 것과 상당히 동등
-
AI 모델 행동은 본질적으로 더 주관적이고 미묘함
- 그 소재를 깊은 수준에서 직접 이해하는 것에 대체물 없음
여전히 디자인인가
-
행동을 디자인하는 것으로, 완벽해지지 않을 수 있으며 그것은 괜찮음
- 모든 픽셀을 완전히 통제하고 완벽함이 보상받는 UI 디자인과 다른 마인드셋
- 여전히 목업 작성, 디자인 도구 사용
- Figma에서 평가 케이스 만들고 출력 검토하고 어색한 부분 수정
- 거의 치료적, 피젯 스피너 같음
- 웹사이트 목업과 30분 주면 타이포그래피 수정하며 행복
- 기능이 제거되지 않는 한 절대 끝나지 않는 종류의 작업, 항상 개선 가능