디자이너 한 명과 AI로 수백 개의 결과물 만들기

URL: https://www.youtube.com/watch?v=O1FN4awNEtM
날짜: 2026-09-11
채널: aiDotEngineer
원문 제목: One Designer + AI. Hundreds of Deliverables. — Vincent Wendy, AI Engineer
발표자(자막 표기): Vinson Weng, AI Engineer 시니어 크리에이티브 디자이너

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==작은 팀에서 디자이너 한 명이 수백 개의 컨퍼런스 결과물을 처리하려면, 디자인 시스템을 먼저 만들고 AI를 자동화·검증·예외 처리 파트너로 연결해야 한다.==

• AI Engineer는 약 12~15명의 작은 팀으로 운영되지만, 7,000명 규모의 행사를 준비해야 한다.
• 행사에는 140개 이상의 스폰서, 300명 이상의 연사, 600개 이상의 세션이 있어 스폰서 자산·연사 그래픽·안내물·웹·굿즈까지 모든 항목이 디자인 대상이 된다.
• 기반이 되는 디자인 시스템, 재사용 가능한 패턴, 자동화된 워크플로, 출력 검증, 사용자 관점의 마찰 제거를 함께 적용해야 규모가 커져도 품질을 유지할 수 있다.

발표의 핵심은 AI가 디자이너의 판단을 없애는 것이 아니라, 문제를 작은 단위로 쪼개고 반복 작업·데이터 반영·시각적 검수·예외 수정까지 맡기는 방식으로 한 사람의 처리 능력을 확장한다는 데 있다. 좋은 도구를 찾는 것보다 해결할 가치가 있는 문제를 정확히 찾는 것이 먼저다.

1. 한 사람이 감당해야 하는 행사 디자인의 규모

1.1. 발표의 출발점과 청중

1. 비기술적인 실전 경험 공유

   1. 발표는 기술 구현을 가르치는 자리가 아니라, AI Engineer 컨퍼런스와 이전 컨퍼런스의 디자인을 실제로 어떻게 만들었는지, AI가 그 과정에서 어떻게 도움을 줬는지를 보여주는 실전 경험 공유로 시작한다.
   2. 제목의 ‘디자이너 한 명과 AI’에서 디자이너는 발표자 자신이며, 목표는 수백 개의 결과물(hundreds of deliverables)을 만들어내는 과정이다.

2. 청중 구성 확인

   1. 발표자는 제품 디자이너가 몇 명인지 묻고, 손을 든 사람이 한두 명 정도인 것을 확인한다.
   2. 나머지는 엔지니어라고 추정해도 되겠냐고 묻고, 청중이 대체로 그렇다고 답하자 비기술적인 실제 업무 사례 중심으로 진행한다.

1.2. 작은 팀과 큰 행사의 불균형

1. 발표자와 팀의 조건

   1. 발표자는 AI Engineer의 시니어 크리에이티브 디자이너 Vinson Weng(원문 제목 표기: Vincent Wendy)이다.
   2. AI Engineer는 당시 약 12~15명 규모의 매우 작은 팀이며, 각자가 자기 업무를 맡아 처리한다.
   3. 발표자는 AI가 모든 사람이 여러 일을 해내도록 돕는 매우 유용한 수단이 되었다고 말한다.

2. 규모 문제(scale problem)

   1. 작은 팀이 커다란 행사를 운영하면 자연스럽게 규모 문제가 발생하며, 발표자는 이를 ‘도전 과제’라고도 부른다.
   2. 준비 당시 예상 참석자는 6,000명이었지만 실제로는 7,000명으로 늘었다.
   3. 행사는 140개 이상의 스폰서, 300명 이상의 연사, 600개 이상의 세션을 포함한다.
   4. 이 모든 규모를 사실상 디자이너 한 명이 뒷받침해야 한다는 조합이 문제의 본질이다.

3. 모든 접점이 결과물이다

   1. 스폰서는 각자의 자산을 필요로 하고, 연사는 각자의 그래픽을 필요로 하며, 참석자는 길을 잃지 않도록 표지판을 필요로 한다.
   2. 스티커 같은 스웨그(swags)부터 랜딩 페이지, 연사 발표 공지, 트랙 마스코트까지 행사에서 보이는 거의 모든 것이 결과물이다.
   3. 물리적인 표지판과 디지털 표지판도 모두 설계 대상이며, 화면에 보이는 작은 요소 하나도 결과물 목록에 들어간다.

4. 천 가지 세부 사항과 천 가지 실패 지점

   1. 세부 사항이 1,000개라면 실패할 방법도 1,000가지가 된다.
   2. 스폰서 로고 하나를 빠뜨리면 큰 문제가 되고, 연사 일정 하나를 잘못 표기해도 큰 문제가 된다.
   3. 이렇게 많은 결과물을 처리하는 일은 처음에는 불가능해 보이지만, 발표자는 자신의 디자인 팀을 소개하며 해결 방식으로 넘어간다.

2. 문제를 해결하는 디자인 팀과 AI 활용 관점

2.1. ‘팀’의 재정의

1. 세 구성원으로 된 디자인 팀

   1. 디자인 팀은 발표자 자신, Devin, GPT, Figma로 구성된다.
   2. 발표자는 Devin을 실제 작업을 수행하는 개발·자동화 파트너로 사용하고, GPT와 Figma를 함께 활용한다.
   3. 핵심 변화는 도구가 부족한 것이 더 이상 가장 큰 문제가 아니라는 점이다.

2. 문제가 오히려 강점이 되는 이유

   1. 누군가 ‘AI Engineer 디자인에서 무엇이 영감을 줬느냐’고 물었을 때 발표자는 처음에는 답을 몰랐다.
   2. 나중에 돌아보니 영감은 미적인 영감원이 아니라 해결해야 했던 문제 자체였다고 정리한다.
   3. 해결할 가치가 있는 문제를 갖고 있으면, AI와 연결해 거의 무엇이든 풀 수 있다는 관점이 이후 사례들의 공통 전제가 된다.

2.2. LLM의 한계를 우회하는 디자이너의 사고

1. Simon Wilson의 2025년 실험

   1. 발표자는 청중에게 Simon Wilson의 2025년 발표를 보았는지 묻고, 청중이 그렇다고 답하자 사례를 꺼낸다.
   2. Simon Wilson은 각 LLM에게 펠리컨이 자전거를 타는 장면의 벡터 파일(vector file)을 만들라고 요청했다.
   3. 발표자가 같은 실험을 다시 해보니 기본 모델은 여전히 결과물을 디자이너가 바로 사용할 수 있는 수준으로 만들지 못했다.

2. 작업 형식을 바꾸는 우회법

   1. 디자이너는 LLM의 특정 출력 형식이 안 된다고 해서 전체 작업을 포기할 필요가 없다.
   2. ChatGPT에 펠리컨이 자전거를 타는 정지 이미지(still image)를 PNG로 만들라고 요청하면 된다.
   3. 그 PNG를 Figma에서 벡터화(vectorize)하면 바로 출하할 수 있는 결과가 된다.
   4. 모델의 능력을 그대로 기다리는 대신, 가능한 출력과 디자이너의 후처리를 조합하는 방식으로 ‘박스 밖에서’ 생각해야 한다.

3. 규모 문제를 푸는 다섯 가지 설계 원칙

3.1. 재사용 가능한 기반 만들기

1. 다섯 가지 순서

   1. 첫째는 기반(foundation)이다.
   2. 둘째는 재사용 가능한 디자인(reusable designs)이다.
   3. 셋째는 자동화된 워크플로(automated workflows)다.
   4. 넷째는 출력 검증(validated output)이다.
   5. 다섯째는 마찰 제거(remove frictions)다.

2. 디자인 시스템을 먼저 고정하기

   1. 기반에는 디자인 시스템(design system), 타이포그래피(typography), 색상(colors), 컴포넌트(components)와 그 밖의 공통 규칙이 포함된다.
   2. 웹사이트를 만들 때도 이 기반을 먼저 설정하면 이후 화면이 같은 체계 안에서 만들어진다.
   3. 실제 예시로 기본 색상(primary colors), 강조 색상(accent colors), 타이포그래피, 태그라인(tagline) 등이 정해져 있다.

3. Atomic Design과 LEGO 비유

   1. 발표자는 제품 디자이너 출신이라 사용자 중심 디자인(user-centric design)과 Atomic Design에 익숙하다.
   2. Atomic Design은 가능한 가장 작은 단위를 만들고, 그 단위들을 LEGO 조각처럼 조합해 더 큰 결과물을 만드는 접근이다.
   3. 작은 단위를 미리 규정해 두면 행사처럼 접점이 많은 업무에서도 공통 품질과 브랜드 일관성을 유지할 수 있다.

4. 타이포그래피 규칙으로 LLM의 임의성 제한

   1. 사무실에서는 ‘Defont’라는 도구 또는 표기(자막 표기)를 많이 사용하며, 발표자는 모두가 그것을 많이 사용한다고 농담한다.
   2. 데스크톱용 타이포그래피와 모바일용 타이포그래피를 명시해 둔다.
   3. Claude 또는 다른 LLM은 규칙이 정의되지 않으면 임의의 폰트 크기를 던지는 경향이 있다.
   4. 폰트 크기를 미리 정하지 않으면 이전 슬라이드처럼 조악한(slop) 결과가 나오므로, 기반 문서가 모델의 자유도를 적절히 제한한다.

3.2. 한 번 만든 디자인을 여러 결과물로 확장하기

1. 브랜드 기반의 재사용

   1. 웹사이트에 브랜드 규칙이 이미 정의되어 있으면 AI Engineer의 다른 팀도 이를 활용할 수 있다.
   2. 마케팅 팀은 웹사이트 기반으로 이메일 디자인, 전단지, 문서를 만들 수 있다.
   3. 모든 결과물을 매번 새로 판단하지 않고, 한 번 설정한 규칙을 반복 적용한다.

2. 반복 가능한 마스코트와 패턴

   1. 마스코트는 기본 디자인을 유지하면서 여러 변형으로 계속 만들 수 있다.
   2. 재사용 규칙을 미리 정의하면 하나의 디자인이 다양한 용도에 맞게 작동한다.
   3. ‘만들고, 헹구고, 반복(rinse and repeat)’하는 과정이 브랜드 일관성을 해치지 않으면서 산출량을 늘린다.

4. 자동화된 워크플로: Figma에서 Devin으로

4.1. 행사 일정표를 최신 데이터로 재생성하기

1. 기존 방식의 한계

   1. 행사장 밖에는 각 사람과 각 방의 일정이 표시된 일정표가 있다.
   2. 예전에는 이 일정을 Figma에서 수작업으로 하나씩 만들고 수정했다.
   3. 일정 데이터가 바뀔 때마다 디자이너와 개발자 사이에 전달과 피드백이 반복되어 시간이 많이 들었다.

2. Devin을 이용한 현재 방식

   1. 발표자는 Devin에게 최신 데이터를 가져오라고 한 뒤, 특정 날짜의 특정 방(room)을 원한다고 요청한다.
   2. Devin은 최신 데이터를 반영한 일정표를 만들고, 이를 PNG로 내보낼 수 있게 한다.
   3. 발표자는 정확한 PNG를 다운로드해 플래시 드라이브에 담고, 화면에 꽂아 바로 표시한다.
   4. 데이터가 행사 운영 정보에서 직접 갱신되므로 수작업 복사 과정에서 생기는 오탈자와 오래된 일정 문제가 줄어든다.

4.2. MCP와 명세서로 픽셀 단위 품질 확보하기

1. 디자이너와 개발자 사이의 마찰

   1. 예전에는 디자이너가 ‘이 디자인을 전달해 달라’고 말하고 엔지니어가 구현한 뒤, 픽셀 퍼펙트하지 않은 결과에 대해 다시 피드백을 보내는 루프가 생겼다.
   2. 설계물을 실제 제품으로 옮길 때 전달 형식이 불명확하면 같은 내용을 여러 번 설명해야 한다.
   3. 발표자는 이런 마찰 때문에 과거에는 정확한 구현이 어려웠다고 말한다.

2. MCP와 스펙 시트 연결

   1. Devin을 MCP(Model Context Protocol)에 연결하면 디자인 정보와 작업 맥락을 직접 전달할 수 있다.
   2. 연결이 충분하지 않으면 스펙 시트(spec sheet)에 간격(spacing), 폰트 크기(font size), 색상 등의 규칙을 적어 보완한다.
   3. 이렇게 하면 Devin에게 ‘더 정확하게 만들어 달라’고 요청할 때 추상적인 피드백이 아니라 측정 가능한 기준을 제공할 수 있다.

4.3. 300명 이상의 연사 그래픽 자동화

1. 연사 발표 공지 생성기

   1. 300명 이상의 연사 각각을 수작업으로 처리하는 것은 한 명의 디자이너에게 불가능하므로 연사 발표 공지(speaker announcement) 생성기를 만들었다.
   2. 생성기는 직접 접근해 사용해볼 수 있는 형태이며, 화면에서 템플릿을 선택할 수 있다.
   3. 이름을 바꾸면 해당 이름이 디자인에 반영된다.

2. 다양한 출력과 자동 내보내기

   1. 가로 모드(landscape mode)를 선택할 수도 있다.
   2. 연사의 헤드샷(headshot)과 세부 정보가 있으면 그래픽이 자동으로 구성되고 내보내진다.
   3. 연사 트레이딩 카드(trading cards)도 제공하며, 이 카드는 예상보다 큰 인기를 얻었다.
   4. 다른 팀에서도 이 결과물을 사용하고, 모든 출력은 픽셀 퍼펙트한 상태를 유지한다.
   5. 소개된 한 예시는 TBPN에서 영감을 받은 디자인이다.

5. 디자인 프로세스의 변화와 명세 전달

5.1. 디자인 씽킹에서 Slack 중심 실행으로

1. 제품 디자이너로 시작했을 때의 과정

   1. 발표자가 제품 디자이너로 커리어를 시작했을 때는 조사(research), 제품 구축, 일반적인 디자인 씽킹(design thinking), 피드백 루프가 표준 과정이었다.
   2. 그 과정 자체가 나쁘다는 뜻은 아니지만, AI Engineer의 현재 규모와 속도에는 예전 방식만으로 대응하기 어렵다고 본다.

2. 현재의 짧은 루프

   1. 현재는 Slack으로 가서 Figma와 연결하고, 다시 Slack으로 결과를 보내는 흐름을 사용한다.
   2. Devin이 Slack 안에 살아 있으므로, Slack에서 필요한 일을 지시하고 결과물을 전달한다.
   3. 이 흐름은 별도의 긴 전달 과정과 반복적인 설명을 줄이며, 결과물을 바로 행사 운영에 보낼 수 있게 한다.

5.2. Figma 스펙 시트와 어노테이션

1. 도구 연결 방식

   1. MCP를 연결하거나, Figma에서 만든 스펙 문서를 명세로 전달할 수 있다.
   2. 발표자는 관심 있는 사람을 위해 무료 Figma 플러그인인 스펙 시트를 언급한다.
   3. 이 플러그인은 PDF에 주석(annotation)을 달아 디자인의 측정 정보를 문서화한다.

2. 이름 없는 레이어도 해석하게 만들기

   1. 디자이너들은 레이어 이름을 잘 붙이지 않는다는 농담이 나온다. 실제 파일에는 Frame 3, Frame 4 같은 무작위 이름이 있을 수 있다.
   2. 그럼에도 LLM은 레이어 이름에만 의존하지 않고 명세를 읽을 수 있다.
   3. 스펙 시트는 간격, 폰트 크기, 색상 등을 정의해 개발자가 픽셀 퍼펙트한 제품을 만들도록 돕는다.

6. 이미지 식별과 자산 탐색의 자동화

6.1. 연사 사진을 찾는 새로운 방법

1. 사진 식별 실험

   1. 발표 당일에도 연사 썸네일을 만들어야 하는 사진 작업이 있었다.
   2. 발표자는 Devin에게 사진 속 인물이 누구인지 물었다.
   3. Devin은 사진을 비교하는 ‘Tinder 같은’ 탐지 방식으로 동일 인물인지 판단했고, 발표자는 결과가 상당히 정확하다고 평가했다.
   4. 시연된 인물은 Jason Liu였으며, Devin의 식별이 맞았다.

2. 사진 검색 과정 단축

   1. 예전에는 사진작가가 제공한 코드 목록을 모두 검색하고, 사진을 하나씩 열어 보며 시간이 허락하는지 확인해야 했다.
   2. 이제는 인물이 Jason Liu라는 맥락을 얻은 다음 해당 사진을 다운로드하라고 요청할 수 있다.
   3. 찾은 사진을 곧바로 썸네일에 붙여 넣으면 되므로, 파일 탐색과 확인에 쓰던 마찰이 사라진다.

6.2. 디자이너의 역할이 최고점에 도달했다는 판단

1. 자동화와 빠른 제작의 결합

   1. 발표자는 디자이너가 자동화할 수 있는 것도 갖췄고, 디자인을 빠르게 만들 수 있는 것도 갖춘 현재의 상태가 이미 정점(peak)에 가깝다고 말한다.
   2. ‘무엇을 더 요구할 수 있겠느냐’는 수사적 질문으로, 도구가 디자이너의 실행력을 크게 확장했다는 감탄을 표현한다.

2. 다시 문제로 돌아가기

   1. 발표자는 잠시 사진 사례에 빠져 본래의 논점에서 벗어났다고 농담한 뒤, 다시 규모 문제로 돌아온다.
   2. 결론은 도구 목록을 늘리는 데 있지 않고, 해결할 가치가 있는 구체적인 문제를 정의하는 데 있다.

7. AI를 출력 검증과 QA 팀으로 활용하기

7.1. 스폰서 로고 누락 검수

1. 대규모 로고 검수 문제

   1. 행사에는 140개 이상의 스폰서가 있고, 로비에는 모든 스폰서 로고가 들어간 배너가 있다.
   2. 로고 하나가 빠지면 스폰서와의 관계에 큰 문제가 될 수 있으므로 시각적 검수가 필요하다.
   3. 발표자는 Devin에게 그래픽을 비교해 누락된 로고가 있는지 확인해 달라고 요청했다.

2. 100% 정확도 테스트

   1. 발표자가 직접 진행한 테스트에서 Devin의 누락 로고 탐지 정확도는 100%였다.
   2. 같은 방식을 참석자에게 제공한 티셔츠 스웨그에도 적용했다.
   3. Devin이 시각적으로 요소를 감지하고 비교할 수 있다는 점은 발표자에게도 놀라운 일이었다.

7.2. 인간의 실수와 인간+AI 검수

1. 작은 누락이 만드는 큰 문제

   1. 사람은 검수 중 ‘작은 무언가 하나가 빠졌다’는 사실을 놓칠 수 있다.
   2. 로고·일정·티셔츠 그래픽처럼 항목 수가 많고 반복되는 작업일수록 이런 실수가 누적된다.

2. AI를 QA 파트너로 보기

   1. 인간의 디자인 판단과 AI의 반복적 시각 비교를 결합하면 자체 QA 팀을 갖게 된다.
   2. AI는 디자이너를 대체하는 존재가 아니라, 사람이 놓치기 쉬운 항목을 한 번 더 확인하는 검수 파트너로 기능한다.

8. 사용자 관점과 예외 처리로 마찰 제거하기

8.1. 디자이너가 아니라 사용자처럼 생각하기

1. 사용자 중심의 이동 경로

   1. 마찰을 제거하려면 디자이너처럼이 아니라 사용자처럼 생각해야 한다.
   2. 사용자는 각자 다른 필요를 가지므로, 실제 참석자가 행사장을 어떻게 이동하는지 상상해야 한다.
   3. 발표자는 참석자가 등록 장소로 가고, 표지판과 길찾기(wayfinding)를 확인하고, QR 코드를 사용하고, 필요한 공간으로 이동하는 경로를 따라간다.

2. 모든 안내물의 연결

   1. 지도, 등록 안내, 표지판, QR 코드와 관련 정보가 서로 연결되어야 참석자가 길을 잃지 않는다.
   2. 방을 찾는 과정과 다음 행동을 안내하는 과정이 하나의 사용자 경험으로 이어져야 한다.
   3. 결과물 개수를 늘리는 것만으로는 충분하지 않고, 각각의 결과물이 사용자의 실제 목표를 끊김 없이 지원해야 한다.

8.2. 진짜 업무는 예외를 처리하는 일이다

1. 예상하지 못한 일정 변경

   1. 일정표를 만든 뒤 어느 날 아침 일정 업데이트가 발생했는데, 처음 만든 시스템에는 편집 버튼이 없었다.
   2. 수작업 시스템이라면 이미 배포한 화면을 다시 만들기 위해 상당한 작업이 필요했을 상황이다.

2. Devin에게 예외를 맡기기

   1. 발표자는 Devin에게 편집 버튼을 추가해 달라고 요청했다.
   2. Devin은 편집 기능을 추가했고, 이제 일정 내용을 바꿀 수 있게 되었다.
   3. 수정한 결과를 다시 PNG로 내보내 화면에 꽂으면 되므로, 변경된 일정을 빠르게 배포할 수 있다.
   4. 과거에는 수작업 때문에 어렵거나 사실상 불가능했던 예외 처리가 이제는 자연스러운 수정 작업이 된다.

9. 결론 및 실용적 시사점

1. 규모를 해결하려면 작게 생각하라

   1. 규모가 큰 문제를 한 번에 해결하려 하지 말고, 가능한 가장 작은 단위까지 쪼개서 생각해야 한다.
   2. 디자인 시스템의 원자 단위, 하나의 로고, 하나의 일정 행, 하나의 사용자 이동 단계처럼 작은 요소를 구체적으로 정의해야 한다.

2. 실패를 사전에 모델링하라

   1. 무엇이 잘못될 수 있는지, 무엇이 실제로 잘못될 것인지 모두 상상해야 한다.
   2. 스폰서 로고 누락, 잘못된 일정, 이름 없는 레이어, 없는 편집 버튼 같은 예외를 발생 후에 수습하지 말고 앞서 해결할 구조를 만든다.

3. 자동화와 검증을 함께 설계하라

   1. 자동화만으로는 잘못된 결과가 빠르게 퍼질 수 있으므로, AI의 시각 검수와 명세 기반 검증을 함께 둬야 한다.
   2. 인간은 사용자 경험과 미적·제품적 판단을 담당하고, AI는 반복 생성·데이터 반영·비교 검수·예외 수정에 참여시킨다.

4. 문제를 갖는 것이 기회다

   1. 현재는 거의 모든 것을 자동화할 수 있으므로, 문제를 발견하는 능력 자체가 이점이 된다.
   2. 해결할 가치가 있는 문제가 있으면 더 나은 제품을 만들고, 좋은 결과물을 더 빠르게 출하할 수 있다.

5. 발표의 마무리

   1. 발표자는 자신의 경험이 청중에게 도움이 되기를 바란다고 말하며 발표를 끝낸다.
   2. 청중의 박수와 음악으로 행사가 마무리된다.

주요 발언 모음

“One designer plus AI, and hundreds of deliverables.”

“A thousand details means a thousand ways to fail.”

“Basically all you need is a problem, because once you have a problem that’s worth solving, you can basically solve anything.”

“Human plus AI, combine it, well, you got your own QA team.”

“To solve the scale problem, you have to actually think small.”

“Think everything that can go wrong and will go wrong, and then try to solve it before.”

핵심 데이터 & 수치

• 팀 규모: AI Engineer는 약 12~15명 규모의 작은 팀이다.
• 참석자 수: 준비 당시 예상 6,000명에서 실제 7,000명으로 늘었다.
• 스폰서 수: 140개 이상이다.
• 연사 수: 300명 이상이다.
• 세션 수: 600개 이상이다.
• 디자인 결과물 범위: 스티커·티셔츠·연사 트레이딩 카드·연사 공지·랜딩 페이지·트랙 마스코트·물리/디지털 표지판·일정표·스폰서 배너 등이다.
• 로고 누락 검수: 발표자가 진행한 테스트에서 Devin의 정확도는 100%였다.
• 연사 그래픽 자동화: 이름·헤드샷·세부 정보·가로 모드를 입력해 출력물을 자동 내보낼 수 있다.
• 작업 연결: Slack–Figma–Devin을 MCP 또는 스펙 시트와 연결해 명세·생성·수정·배포를 이어간다.

결론 및 시사점

행사 디자인의 병목은 디자인을 못 만드는 데 있지 않고, 작은 팀이 반복 작업과 예외를 모두 수작업으로 처리해야 하는 데 있다. 디자인 시스템과 Atomic Design으로 기준을 고정하고, Devin·GPT·Figma를 연결하면 일정표·연사 그래픽·이미지 탐색·로고 검수·예외 수정까지 자동화할 수 있다. 사람은 문제를 정의하고 사용자 여정을 판단하며, AI는 반복 생성과 검증을 맡는 구조가 한 사람의 생산성을 수백 개 결과물 수준으로 확장한다.

실무 적용 순서는 다음과 같다.

1. 브랜드 색상·타이포그래피·컴포넌트·태그라인을 먼저 명세한다.
2. 데스크톱·모바일 규칙과 간격·폰트 크기·색상을 스펙 시트에 기록한다.
3. 작은 원자 단위를 LEGO처럼 조합해 재사용 가능한 템플릿을 만든다.
4. 최신 데이터가 필요한 일정·공지·자산 탐색을 AI 워크플로에 연결한다.
5. AI에게 로고 누락·일정 오류·시각적 불일치를 다시 확인하게 한다.
6. 사용자의 실제 이동 경로를 따라가며 표지판·QR·지도·등록 안내의 연결을 검증한다.
7. 편집 버튼이 없는 일정 변경처럼 예외를 예상하고, 문제가 생겼을 때 AI로 기능을 추가할 수 있게 구조를 열어 둔다.

핵심 요약 (20줄)

1. AI Engineer는 약 12~15명의 작은 팀으로 7,000명 규모의 컨퍼런스를 준비했다.

2. 140개 이상의 스폰서, 300명 이상의 연사, 600개 이상의 세션이 한 명의 디자이너에게 수백 개의 결과물을 요구했다.

3. 스티커와 티셔츠부터 랜딩 페이지, 연사 공지, 마스코트, 표지판까지 모두 행사 디자인 결과물에 포함된다.

4. 세부 사항이 1,000개라면 스폰서 로고 누락이나 잘못된 일정처럼 실패할 지점도 1,000개가 된다.

5. Vinson Weng은 자신과 Devin, GPT, Figma를 하나의 디자인 팀처럼 결합했다.

6. LLM이 펠리컨이 자전거를 타는 벡터 파일을 만들지 못해도 PNG를 만든 뒤 Figma에서 벡터화하면 작업을 완료할 수 있다.

7. 규모 문제를 푸는 다섯 요소는 기반, 재사용 디자인, 자동화 워크플로, 출력 검증, 마찰 제거다.

8. 색상, 타이포그래피, 컴포넌트, 태그라인을 먼저 고정하면 여러 팀이 같은 브랜드 규칙을 재사용할 수 있다.

9. Atomic Design은 작은 단위를 LEGO 조각처럼 조합해 일관된 결과물을 만드는 데 유용하다.

10. 데스크톱과 모바일 폰트 규칙을 명시하면 Claude 같은 LLM이 임의의 폰트 크기를 선택하는 문제를 줄일 수 있다.

11. Devin은 최신 일정 데이터를 받아 방별 일정표를 만들고 PNG로 내보내 화면에 표시하게 한다.

12. MCP와 스펙 시트는 간격, 폰트 크기, 색상을 전달해 디자이너와 개발자 사이의 피드백 루프를 줄인다.

13. 300명 이상의 연사도 이름, 헤드샷, 세부 정보와 가로 모드를 입력하면 발표 공지와 트레이딩 카드로 자동 변환할 수 있다.

14. Slack과 Figma를 Devin에 연결하면 지시, 디자인, 수정, 배포가 짧은 루프로 이어진다.

15. 무료 Figma 스펙 시트 플러그인은 이름 없는 레이어에서도 개발에 필요한 측정 정보를 추출하게 한다.

16. Devin은 사진 속 인물을 Jason Liu로 식별해 사진작가의 파일 코드를 일일이 검색하던 작업을 단축했다.

17. 140개 이상의 스폰서 배너와 티셔츠의 로고 누락 검수에서 Devin은 발표자의 테스트 기준 100% 정확도를 보였다.

18. 인간의 판단과 AI의 반복적 시각 비교를 결합하면 별도의 QA 팀에 가까운 검수 체계를 얻는다.

19. 참석자의 등록, 길찾기, QR 코드, 방 이동을 따라가며 모든 안내물이 연결되는지 확인해야 사용자 마찰을 줄일 수 있다.

20. 규모를 해결하려면 가장 작은 단위로 쪼개고 발생할 예외를 미리 설계하며, 해결할 가치가 있는 문제를 AI 자동화의 출발점으로 삼아야 한다.