# ‘모델 디자이너’의 부상: AI 제품에서 디자인의 역할이 바뀌고 있다 > Clean Markdown view of GeekNews topic #25831. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25831](https://news.hada.io/topic?id=25831) - GeekNews Markdown: [https://news.hada.io/topic/25831.md](https://news.hada.io/topic/25831.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-15T10:51:01+09:00 - Updated: 2026-01-15T10:51:01+09:00 - Original source: [aidesignfieldguide.com](https://www.aidesignfieldguide.com/articles/barron-webster) - Points: 12 - Comments: 0 ## Summary **‘모델 디자이너’** 는 AI 제품 설계의 새로운 직군으로, 디자이너가 **파운데이션 모델의 한계를 보완**하며 **모델의 동작을 직접 프로토타이핑**하는 역할을 맡습니다. Figma의 Barron Webster는 이 과정을 통해 디자인 조직에 **AI 우선 사고방식과 평가(Evals) 시스템**을 도입하고, 디자이너가 코드 없이도 모델의 품질을 빠르게 검증할 수 있는 도구를 구축하고 있습니다. 이는 UI 중심의 전통적 디자인을 넘어, **디자이너가 모델의 입출력 구조와 시스템 전체를 이해**하는 **의사결정 참여자**로 진화하고 있음을 보여줍니다. ## Topic Body - **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분 주면 타이포그래피 수정하며 행복 - 기능이 제거되지 않는 한 **절대 끝나지 않는 종류의 작업**, 항상 개선 가능 ## Comments _No public comments on this page._