매기 애플턴과 함께 살펴보는 디자인 엔지니어링

디자인 엔지니어링은 시각적 완성도와 제품의 기술 아키텍처를 연결하고, 에이전트 시대의 협업·프로토타이핑·문화적 맥락까지 함께 설계하는 문제 해결 활동이다.

URL: https://www.youtube.com/watch?v=KZSzF0KEFRg
날짜: 2026-09-25
채널: pragmaticengineer (Pragmatic Engineer)
원문 제목: Design Engineering with Maggie Appleton
출연: Maggie Appleton, Gergely Orosz

📌 핵심 질문 / 디자인 엔지니어링은 무엇을 연결하는가

==디자인 엔지니어링은 시각적 완성도를 높이는 기술이 아니라, 문제를 정의하고 제품의 명사·동사·데이터·구현을 하나의 시스템으로 묶는 일이다.==

디자이너는 색·간격·움직임만 다루지 않고 제품이 다루는 데이터와 기술적 제약을 이해해야 한다.
에이전트는 구현과 프로토타이핑을 빠르게 만들지만, 공간·문화·맥락·사용자 이해를 자동으로 보장하지 않는다.
종이와 펜, 화이트보드, 라이브 변수, 공유 의사결정 카드가 인간과 에이전트 사이의 사고를 연결하는 매개체가 된다.
에이전트 시대에는 개인의 코딩 속도보다 팀이 같은 결정을 공유하고 책임지는 협업 인터페이스가 더 큰 병목이 된다.

디자인과 엔지니어링은 모두 문제를 확인하고, 가능한 해법을 넓게 조사하고, 절충안을 선택하고, 프로토타입을 만들고, 사용자에게 검증하는 문제 해결 과정이다. 차이는 주로 재료에 있다. 엔지니어가 코드·데이터 흐름·아키텍처를 재료로 삼는다면 디자이너는 공간·크기·무게·색·문구·움직임·가시성을 재료로 삼는다. 좋은 디자인 엔지니어는 두 재료를 동시에 다루며, 에이전트가 만드는 결과를 감독할 만큼 깊이 이해한다.

1. 종이에서 시작하는 시각적 사고

1.1. 아이디어를 언어화하기 전 외부화하기

손으로 그린 스케치는 사고의 임시 저장소다
1. 아이디어가 떠오르면 Claude의 코드에 바로 들어가거나 긴 프롬프트를 쓰기보다 옆 테이블의 펜과 종이에 카드와 아코디언처럼 보이는 구조를 빠르게 그린다.
2. 종이 위의 스케치는 화면에서 사라지지 않고 테이블에 남아 다음 날 다시 볼 수 있으며, 전날 무엇을 고민했는지 기억하게 한다.
3. 데이터 흐름, 공간 관계, 인터페이스 배치처럼 아직 단어로 정확히 표현할 수 없는 생각을 먼저 2차원으로 꺼내 놓을 수 있다.
언어 이전의 사고가 에이전트 입력의 한계를 보완한다
1. 현재 에이전트는 텍스트를 가장 잘 받아들이고 이미지를 읽을 수 있어도 공간적 관계·간격·크기·겹침을 안정적으로 이해하지 못한다.
2. 이미지나 스크린샷을 넣으면 에이전트가 요소 사이의 간격을 틀리게 배치하거나 크기를 잘못 잡고 텍스트를 겹치게 하는 일이 반복된다.
3. 시각적 아이디어를 문장으로만 설명하면 의도와 결과 사이에 큰 간극이 생기므로, 원하는 형태를 먼저 스케치한 뒤 에이전트에게 구현을 맡기는 편이 빠르다.

1.2. 화이트보드와 노트북이 만드는 공통 공간

화이트보드는 엔지니어의 물리적 사고 도구다
1. 데이터베이스, 네트워크 연결, 반복되는 로직은 말이나 코드로 설명할 수 있지만, 화이트보드의 사각형과 화살표는 여러 사람이 동시에 같은 2차원 공간을 볼 수 있게 한다.
2. 한 사람이 컴포넌트를 그리면 다른 사람이 원을 치거나 새 컴포넌트를 추가하면서 생각을 이어 간다.
3. 온라인 화이트보드는 같은 방에 없어도 물리적 보드의 공통 공간과 비슷한 협업 효과를 만든다.
물리적 매체는 생각의 형태를 강제한다
1. 노트북, 화이트보드, 디지털 캔버스는 아이디어를 추상적인 말에서 구체적인 모양으로 옮기는 공통 장치다.
2. 엔지니어가 데이터 구조와 시스템 경계를 사각형으로 그리듯, 디자이너는 화면의 구성과 물리적 감각을 노트북에 배치한다.
3. 인간과 에이전트가 함께 일하려면 에이전트가 공간·빛·재료·선·형태를 이해할 수 있는 중간 표현이 필요하다.
ESP32 캐릭터는 진지한 문제와 장난스러운 실험의 결합이다
1. 작은 화면과 Wi-Fi·Bluetooth를 갖춘 ESP32로 날씨를 알려 주는 캐릭터를 만들고, 에이전트와 연결해 한정된 전력과 리셋 조건을 다루는 실험을 했다.
2. 이런 낙서와 하드웨어 실험은 제품 전략만큼 무겁지 않지만, 새로운 상호작용의 형태를 손으로 확인하게 해 준다.
3. 진지한 시스템 구상과 어린아이가 노트에 그린 캐릭터가 같은 스케치 공간에 공존한다.

2. 매기 애플턴의 경로와 디자인의 재료

2.1. 인류학에서 일러스트레이션과 프론트엔드로

문화인류학은 사람과 시스템을 관찰하는 훈련이 됐다
1. 대학에서 문화인류학을 공부하며 참여관찰을 접했고, 인류학자가 다른 문화권 사람들과 함께 살면서 음식·집·시간·색의 이해가 얼마나 다를 수 있는지 관찰한다는 점에 매료됐다.
2. 어린 시절 여러 나라를 옮겨 다닌 엑스패트로 자라 런던에서의 생활 방식이 유일한 정상적인 사회 구성 방식이 아니라는 사실을 일찍 배웠다.
3. 사람은 환경에 맞춰 매우 유연하게 변하고 사회를 구성하는 방법에도 고정된 정답이 없다는 감각이 이후 제품과 인터페이스를 바라보는 기반이 됐다.
4. 인류학 전공자의 진로로 박사학위 후 교수가 되거나 군을 위해 다른 나라 사람을 고문하는 방법을 개발하는 선택지가 있다는 농담이 나왔고, 매기는 어느 쪽도 택하지 않았다.
1990년대 인터넷은 취미에서 직업으로 이어졌다
1. Neopets에서 놀며 12~13세 무렵 HTML과 CSS를 배웠고, MySpace 페이지에 복잡한 애니메이션과 반짝이는 커서를 붙였다.
2. 당시 인터넷을 직업으로 생각하는 사람은 많지 않았고, 대학 졸업 후 전공만으로 수입을 만들기 어려워 프리랜서 디자이너가 됐다.
3. 대학에서 IT 지원 업무를 하며 월세를 마련했고, 그림을 좋아해 처음에는 일러스트레이션에 집중했다.
프라하의 UI/UX 스튜디오가 제품 인터페이스를 소개했다
1. 샌프란시스코 스타트업을 위한 UI/UX를 만들던 프라하의 디자인 스튜디오에서 초기 Tinder와 Uber 프로젝트를 접했다.
2. 애플리케이션의 일러스트레이션·로고·브랜딩을 맡다가 버튼과 사이드 패널을 만드는 사람이 따로 있다는 사실을 알게 됐고, 제품 디자인에 관심을 갖게 됐다.
3. Egghead에서 4년 동안 일러스트레이터로 시작해 아트 디렉터가 됐고, 다른 일러스트레이터의 작업을 감독하면서 JavaScript와 React를 공부했다.
4. React 컴포넌트, useEffect, JavaScript 함수처럼 그림으로 설명하려는 재료를 실제로 이해해야 했던 경험이 프론트엔드 엔지니어링으로 자연스럽게 이어졌다.
Elicit은 처음부터 끝까지 제품 디자인을 익힌 장소였다
1. 2021년 말 또는 2022년 초에 초기 AI 스타트업 Elicit에 합류했고, 언어 모델을 10년 동안 연구한 창업자가 과학적 문헌 검토를 가속할 가능성을 일찍 본 상태였다.
2. Elicit은 과학자들이 수천 편의 논문을 읽고 스프레드시트로 데이터를 추출하는 느린 문헌 검토 작업을 언어 모델로 빠르게 만들려 했다.
3. 합류 당시 팀원은 6~7명 정도였고 매기는 유일한 디자이너였으며, 프로젝트 매니저가 떠난 뒤 새 PM을 두지 않아 오랫동안 제품 관리 역할도 팀이 나눠 맡았다.
4. 창업자들과 소규모 팀은 리트릿에서 몇 주씩 함께 지내며 비전에 대한 신뢰를 쌓았고, 가족처럼 일하는 초기 스타트업의 밀도를 경험했다.
5. 제품이 많은 사용자를 확보하면서 검색어·클릭·작동 여부·A/B 테스트 데이터를 수집할 수 있었고, 2년이 넘는 기간 동안 매주 기능을 설계하고 출시하고 측정하고 다시 설계했다.
6. 사용자 필요를 출발점으로 전체 프론트엔드 구현까지 연결하는 제품 디자인의 기본 역학을 반복적으로 배웠다.

2.2. 디자이너가 다루는 명사와 동사

디자인은 엔지니어링과 같은 문제 해결 과정이다
1. 먼저 무엇이 진짜 문제인지, 올바른 문제를 골랐는지, 조사 범위를 충분히 덮었는지 확인한다.
2. 가능한 해결책을 넓게 조사하고 각 방법의 절충안을 비교한 뒤, 프로토타입과 검증으로 사용자에게 실제로 의미가 있는지 확인한다.
3. 코드 대신 공간·크기·무게·색·가시성·움직임·문구가 디자인의 재료가 되지만, 문제를 정의하고 검증하는 절차는 엔지니어링과 가깝다.
제품은 명사와 동사로 이해해야 한다
1. 운동화 가게에는 운동화·유모차·돈처럼 사용자가 쉽게 이해하는 명사가 있지만, AWS나 개발자 도구에는 데이터 세트·컨테이너·연결된 데이터·변환 함수처럼 추상적인 명사가 있다.
2. 에이전트 도구에는 채팅 세션, 계획, MCP, 스킬, 개인 기록(PR) 같은 새로운 명사가 생기며, 여러 세션을 하나의 기록으로 묶는 새 프리미티브가 필요할 수 있다.
3. 각 명사에 대해 편집·이름 변경·삭제가 가능한지, 에이전트 세션을 분리했을 때 어떤 결과가 생기는지 같은 동사를 정의해야 한다.
4. 제품 디자인의 어려운 부분은 복잡한 시스템을 사용자가 가리키고 결과를 예측할 수 있는 단순한 명사와 동사의 체계로 줄이는 일이다.
제품 디자인은 전체 스택과 사용자 흐름을 함께 본다
1. 기술 제품을 만드는 디자이너는 색·그림자·형태·애니메이션뿐 아니라 데이터베이스의 형태, API, 데이터의 위치, 컴포넌트 사이의 전송 방식도 이해해야 한다.
2. 모든 디자이너가 데이터베이스를 알 필요는 없으며 정부 양식처럼 기술적 구조보다 사용자를 보호하고 흐름을 명확히 하는 일이 핵심인 영역도 있다.
3. AI처럼 새로운 산업에서는 서버와 데이터가 제품의 가능성을 결정하므로, 디자이너가 기술적 작동 방식을 깊이 다루지 않으면 새로운 명사와 동사를 설계하기 어렵다.
Ward Cunningham과 Kent Beck의 패턴 언어가 던지는 힌트
1. 올바른 문제 영역을 찾아 적절한 단어와 구조를 붙이는 작업은 도메인 중심 설계와 디자인 패턴을 만들 때의 고민과 닮았다.
2. 패턴과 템플릿은 반복되는 구조에 이름을 붙여 사람들이 같은 개념을 공유하게 하며, 에이전트 제품도 새로운 개념에 정확한 이름을 부여해야 한다.
3. 소프트웨어 디자인은 시각적 장식이 아니라 사람이 이해할 수 있는 구조를 찾고 그 구조를 작동하는 시스템으로 구현하는 일이다.

3. 디자인 엔지니어의 정의와 협업

3.1. 마이크로인터랙션과 진짜 디자인 엔지니어링

인터넷에서 통용되는 명칭에는 범위가 섞여 있다
1. X에서 엔지니어-디자이너라고 소개하는 사람 중에는 버튼의 호버 효과나 다운로드 상태의 멋진 전환을 만드는 마이크로인터랙션 전문가가 많다.
2. 이런 시각적 효과는 훌륭하지만 에이전트에게 지시하고 코드 한 줄도 검토하지 않아도 만들 수 있으므로, 매기는 이를 디자인 엔지니어링 전체와 동일시하지 않는다.
3. 디자인 엔지니어링은 일시적인 효과 제작이 아니라 공학과 디자인을 함께 수행하는 지속적인 업무 영역이다.
디자인 엔지니어는 구현과 아키텍처에 깊이 들어간다
1. 좋은 디자인 엔지니어는 제품의 명사·동사·시각적 품질을 다루면서 엔지니어와 긴밀히 협력하거나 직접 코드를 작성한다.
2. 완전한 풀스택 엔지니어일 필요는 없지만 자신이 만드는 제품의 기술 아키텍처를 깊이 이해하고, 서버 데이터의 형태와 모델의 능력, 제품에 내장된 커스텀 스킬이 인터페이스에 미치는 영향을 판단한다.
3. 프론트엔드 구현을 직접 맡으면 CSS를 싫어하는 엔지니어의 부담을 줄이고, 엔지니어는 더 논리적이고 복잡한 데이터 흐름에 집중할 수 있다.
4. 엔지니어가 “이 둥근 모서리 값이 정말 중요한가?”라고 생각할 때 디자인 엔지니어가 그 세부 구현을 맡아 전체 긴장을 줄인다.
Figma 픽셀과 실제 재료 사이에는 간극이 있다
1. Sketch와 Figma는 iOS·데스크톱·웹의 실제 제약과 연결되지 않은 픽셀 기반 레이아웃을 제공한다.
2. 모바일에서 복잡한 그라디언트를 사용하면 스크롤 성능을 해칠 수 있고, 저사양 Android나 iOS 기기에서는 같은 디자인이 다르게 작동한다.
3. 웹에서는 폰트 렌더링·반응형 중단점·데이터 로딩 시간·레이스 컨디션을 고려해야 하며, 이를 모르면 보기 좋은 화면이 나쁜 제품으로 변한다.
4. 목재 디자이너가 참나무와 소나무의 물성을 무시할 수 없듯, 웹 디자이너는 자신이 작업하는 플랫폼의 물성을 배워야 한다.
에이전트는 디자이너의 기술 학습 코치가 될 수 있다
1. 엔지니어가 “이 상황에서는 오류가 난다”고 말하면 디자이너는 에이전트에게 해당 조건이 왜 생기는지 설명하고 최종 구현을 함께 만들도록 요청할 수 있다.
2. 디자이너가 과거의 픽셀 레이아웃에 머무르지 않고 데이터 흐름·성능·동시성까지 배울 수 있는 진입점이 생긴다.
3. 에이전트는 오래된 디자이너-엔지니어 마찰을 없애는 만능 해결책은 아니지만, 디자인 재료의 범위를 넓히는 학습 도구가 된다.

3.2. Figma를 거쳐 라이브 프로토타입으로

Figma는 정답이 아니라 중간 해상도의 스케치다
1. 매기는 종이에서 정한 대략적인 형태를 Figma로 옮겨 색 대비, 텍스트 크기, 화면의 시각적 흐름을 조정한다.
2. Figma 결과를 최종 고정 사양으로 보지 않는 이유는 브라우저의 폰트, 반응형 동작, 중단점이 화면을 다르게 만들기 때문이다.
3. 평균적인 모양을 Figma에서 얻은 뒤 가능한 한 일찍 브라우저에서 구현하고 실제 환경에서 개선한다.
목공의 지그(jig)가 라이브 디자인 도구가 된다
1. 목공에서 지그는 특정 작업을 반복해서 정확히 수행하도록 돕는 작은 장치다.
2. 라이브 프로토타입에서는 확신이 없는 헤더 크기, 색상 팔레트, 애니메이션 곡선 같은 값에 슬라이더를 붙여 직접 조정한다.
3. 변수의 범위를 에이전트에게 지정하고 여러 값을 실시간으로 움직이면 정적 목업보다 훨씬 빠르게 올바른 값을 찾을 수 있다.
4. 불확실성을 숨기지 않고 조작 가능한 변수로 노출하는 방식은 “나만의 Figma”를 만드는 것과 같다.
GitHub Next의 조직적 위치가 작업 방식을 결정한다
1. GitHub Next는 본체 조직과 좋은 관계를 유지하면서도 낯선 아이디어를 연구하고 나중에 본체를 설득하는 작은 연구·개발 팀으로 다소 고립돼 있다.
2. GitHub.com의 디자이너는 수백만 또는 수천만 사용자의 기존 업무 흐름과 Rails 기반 디자인 시스템을 지켜야 하므로 버튼 하나를 옮기는 일도 정치적 결정이 된다.
3. 매기가 속한 팀에는 엔지니어-디자이너 두 명이 있고, 모두 같은 PR·도구·재료를 사용하되 한쪽은 인터페이스를, 다른 쪽은 서버와 데이터 흐름을 더 걱정한다.

4. 에이전트 시대의 프로토타이핑

4.1. 가짜 클릭 프로토타입에서 작동하는 시제품으로

기존 Figma 프로토타입은 사용자에게 가짜라는 신호를 줬다
1. Figma의 클릭 연결이 다음 화면으로 이어지지 않으면 사용자가 엉뚱한 영역을 눌렀을 때 화면이 멈추거나, 연결되지 않은 새 화면이 나타난다.
2. 사용자는 며칠 만에 만든 프로토타입이 조악해서 어색해하고, 디자이너는 짧은 테스트 일정 때문에 시각적 완성도를 높일 시간도 부족했다.
3. 실제로 작동하는 에이전트 기반 프로토타입은 사용자의 행동을 더 자연스럽게 관찰하고, 짧은 실험에 더 높은 품질을 부여한다.
파일과 스크린샷이 에이전트의 반복 루프를 만든다
1. Figma 파일이나 완성도 높은 목업을 에이전트에게 주고 구현하게 한 뒤, 결과가 원본과 다르면 스크린샷을 비교해 계속 수정하도록 지시한다.
2. 이 작업은 밤새 실행해 아침에 결과를 확인할 수 있을 만큼 빨라졌고, 매기는 에이전트가 설명한 레이아웃을 실제 인터페이스로 얻을 수 있었다.
3. 프로토타입용 React 컴포넌트의 클래스 품질이나 장기 유지보수성은 버릴 코드라면 중요하지 않으며, 핵심은 가설을 검증할 수 있게 작동하는가이다.
더 큰 아이디어를 더 빨리 시험할 수 있다
1. 에이전트가 구현을 담당하면서 Figma가 제공하는 정적 도구에 제한되지 않고 애니메이션·물리 효과·상태 변화를 프로토타입에 넣을 수 있다.
2. 매기는 GitHub Next의 새 웹사이트를 위해 회전하는 별자리(constellation)와 프로젝트 카드를 실험했다.
3. 별의 회전 속도, 중력에 해당하는 강도, 별의 크기와 변형, 스크롤에 따른 확대·축소, 배경 그라디언트와 거친 질감, 유리 효과와 로고 크기, 호버 시 크기, 스크롤 전환을 슬라이더와 변수로 조정했다.
4. 별의 실제 물리학을 따로 공부하거나 코드를 직접 작성하지 않고도 원하는 분위기와 상호작용을 선택하며 여러 형태를 비교했다.

4.2. 브렛 빅터의 생생한 프로그래밍

“죽은 물고기를 그만 그려라”는 피드백의 직접성을 요구한다
1. Brett Victor는 엔지니어이면서 디자이너로 활동했고 2010~2013년 무렵 “Stop Drawing Dead Fish”를 포함한 발표와 실험을 선보였다.
2. 전통적인 프로그래밍은 에디터에서 코드를 조립한 뒤 브라우저나 다른 화면으로 이동해 결과를 확인하므로 변수와 결과 사이가 끊어진다.
3. 생생한 프로그래밍은 어떤 변수를 바꾸는 순간 결과물에서 직접 그 효과를 보고, 결과물 위에서 바로 수정할 수 있어야 한다.
라이브 변수는 예전에는 구현 비용이 컸다
1. 과거에는 가능한 모든 값을 미리 노출하거나 실시간 미리보기를 만들 시스템이 부족해, 매번 코드를 고치고 브라우저를 새로고침해야 했다.
2. 에이전트와 브라우저 프로토타입을 결합하면 색·속도·강도·공간·질감을 즉시 조정할 수 있다.
3. 프로토타입은 더 이상 최종 코드의 축소판이 아니라, 설계 공간을 탐색하는 살아 있는 장치가 된다.

5. AI가 디자이너를 대체할 수 있는가

5.1. 스무 개의 대안과 한 명의 디자이너

간단한 가설 검증에는 대량의 대안이 유용하다
1. 엔지니어 Amir는 Claude에게 고품질 디자인 대안 20개를 만들게 하고 가장 좋은 것을 고르는 방식이 디자이너와 상호작용하는 것보다 빠르다고 말했다.
2. 디자이너가 곁에 없고 버튼·사이드 패널처럼 익숙한 요소가 필요하거나, 제품 가설을 확인할 임시 화면이 필요하다면 20개의 대안을 생성하는 방법이 합리적이다.
3. 결과를 빠르게 비교하면 취향과 명백한 실패를 걸러낼 수 있고, 개발자가 디자인 실험을 시작할 진입장벽도 낮아진다.
새로운 제품의 형태를 정하는 일은 자동 생성과 다르다
1. 완전히 새로운 제품의 명사와 동사를 정하거나 사람들이 실제로 무엇을 이해하는지 알아내는 작업은 단순히 예쁜 시안을 고르는 일이 아니다.
2. 디자이너는 문제를 어떻게 구성할지 결정하고, 여러 실험을 설계하고, 사용자를 만나 무엇이 이해되고 무엇이 이해되지 않는지 확인한다.
3. AI가 만든 시안은 취향에 맞을 수 있어도 문화적 맥락과 제품의 목적을 이해했다는 보장은 없으며, 생성된 티가 나는 품질과 미묘한 맥락의 차이가 남는다.
AI가 만든 ‘좋은 디자인’은 보편 규칙을 과잉 적용한다
1. 에이전트는 사이드 패널을 닫는 익숙한 아이콘 대신 “Close sidebar”라는 문구를 넣거나, 모달 오른쪽 위에 “Close modal window”를 쓰고 버튼 위에 네 줄의 설명을 붙인다.
2. 사람은 특정 위치의 작은 아이콘이 패널을 닫는다는 관습을 이미 학습했지만, 에이전트는 모든 것을 명시하면 명확해진다고 판단한다.
3. 접근성·명확성 같은 원칙도 맥락 없이 적용하면 화면을 장황하고 둔하게 만든다.

5.2. 좋은 AI 인터페이스는 익숙한 프리미티브에서 확장된다

Elicit은 새로움보다 익숙함을 선택했다
1. 과학 논문의 데이터를 추출하는 Elicit 초기 버전은 연구자들이 쓰던 Excel 표가 낡은 방식이라고 생각해 무한 캔버스에 카드들을 흩어 놓거나 접힌 카드 더미처럼 보여 주는 실험을 했다.
2. 사용자 인터뷰마다 “혼란스럽다”, “그냥 표를 달라”는 반응이 나왔고, 몇 달간의 실험 뒤 표가 가장 인지 부하가 낮다는 사실을 받아들였다.
3. 익숙한 표를 출발점으로 삼고 주변에 AI의 검색·추출·정리 기능을 확장하는 편이 사용자가 배우지 않아도 되는 강력한 인터페이스였다.
AI의 최종 UI가 반드시 챗봇일 필요는 없다
1. 챗봇은 초기 프리미티브일 뿐이고, Codex 같은 도구는 채팅 창에 더해 Git worktree, 주석, 디버깅, 실행 환경을 함께 보여 준다.
2. Elicit도 표를 유지하면서 표 안팎에 새로운 기능을 추가해 익숙한 구조를 확장했다.
3. 문서·사이드 패널·카드·표는 사람들이 운영체제, Google Sheets, Excel, Office 문서에서 이미 습득한 구조이므로 AI 제품도 이 기반 위에서 더 강력해질 가능성이 크다.
문화적 맥락이 인터페이스의 수명을 결정한다
1. 지금 유행하는 Linear·Vercel식 미니멀 디자인은 흰색 또는 크림색 배경, 약간 둥근 모서리, 깨끗한 여백을 특징으로 한다.
2. 모든 에이전트가 이 형태를 구현할 수 있게 되면 같은 화면이 AI 생성물임을 드러내고, 10년 뒤에는 낡은 소프트웨어의 신호가 될 수 있다.
3. 읽을 수 있을 만큼 큰 글자와 충분한 주변 공간은 오래가는 기본 원칙이지만, 무엇이 세련됐는지 알려 주는 미학과 문화적 신호는 계속 변한다.
4. 인간 디자이너는 새롭고 이상한 형태를 제안해 차별화할 수 있으며, 에이전트가 기존 인터넷의 평균을 복제할수록 인간의 취향과 실험이 더 중요해진다.

6. 모델의 불일치와 에이전트의 가스라이팅 기회

6.1. 잘하는 일과 못하는 일을 예측하기 어렵다

“가스라이팅 기회”는 모델의 들쭉날쭉함을 가리킨다
1. Maggie는 모델이 어떤 작업에는 놀랄 만큼 뛰어나고 다른 작업에는 형편없이 실패하는 현상을 모델이 사용자를 가스라이팅하는 것처럼 느껴지는 “gaslighting opportunities”라고 불렀다.
2. 처음에는 훌륭한 결과를 보고 모델의 능력을 믿게 되지만, 같은 모델이 다음 작업에서는 기본적인 실수를 하고도 자신 있게 답하면 실패의 크기를 놓치기 쉽다.
3. 전문가는 갑자기 어제의 전문 지식을 잊지 않지만 모델은 맥락·프롬프트·사용 가능한 모델·확률적 출력에 따라 매일 다르게 행동한다.
프런티어 모델의 향상이 회의주의를 없애지는 않는다
1. 최신 모델은 일정 수준 아래로 떨어지지 않는 기본 성능을 보여 주지만, 모델이 바뀔 때 잘하는 일과 기대에 맞지 않는 일이 함께 바뀐다.
2. “모델이 계속 좋아지고 있다”는 인상만으로 개별 결과를 신뢰하면 디자인·코드·기획의 결함을 늦게 발견한다.
3. 사용자는 작업마다 에이전트의 결과를 확인하고, 라이브 변수와 테스트를 통해 실제 품질을 검증해야 한다.

7. 공동 엔지니어링과 팀 의사결정

7.1. 한 명의 개발자, 두 다스의 에이전트, 제로 정렬

개인의 속도와 팀의 합의 사이에 새로운 틈이 생겼다
1. 한 사람이 에이전트와 로컬에서 빠르게 작업할 수 있어도 소프트웨어는 여전히 제품 관리자·디자이너·다른 엔지니어와 합의해 팀으로 만든다.
2. Slack·Linear·GitHub에는 문제와 작업을 기록할 수 있지만, 기능을 만들 가치가 있는지, 어떤 형태가 맞는지, 데이터베이스 마이그레이션이 필요한지 합의하는 사전 설계 공간은 부족하다.
3. 현재 에이전트 코딩 세션은 대부분 개인 컴퓨터에 로컬로 존재하고 다른 사람이 실시간으로 참여하기 어렵다.
에이전트에게 넘기는 순간이 새로운 하드 포인트가 된다
1. 과거에는 구현이 오래 걸려 진행 중에 팀이 설계를 조정할 여지가 있었다.
2. 에이전트에게 명확한 지시를 넘기면 구현이 너무 빨라져, 팀이 시작 전에 문제·사양·인터페이스·아키텍처를 거의 완전히 합의해야 한다.
3. 에이전트가 낸 해법은 충분히 큰 화면의 결정 카드로 보여 주고, 다른 팀원의 기여와 최종 승인자를 기록해야 한다.
4. 6개월 뒤 누가 어떤 정보를 보고 서버 관련 결정을 승인했는지 확인할 수 있도록 결정의 맥락과 책임자를 감사 로그에 남겨야 한다.
공동 엔지니어링은 일급 프리미티브가 되어야 한다
1. 단순히 Slack 채널에 에이전트를 넣는 것만으로는 결정 조정과 책임 소재 문제가 해결되지 않는다.
2. 한 결정에 여러 선택지·시각 자료·데이터 흐름도·상태 머신·HTML 프로토타입을 붙이고, 각 팀원이 자신이 이해한 내용을 확인한 뒤 승인하는 구조가 필요하다.
3. 에이전트가 실행하는 계획 자체가 팀의 공유 문서이자 실행 기록이 되어야 한다.

7.2. ACE와 멀티플레이어 작업공간

ACE는 Slack과 클라우드 개발 환경을 합친 프로토타입이다
1. GitHub Next의 ACE는 Slack 같은 대화 공간, 마이크로 가상 머신 샌드박스, 코드 실행, PR 생성과 리뷰를 하나로 묶은 범용 멀티플레이어 작업공간이었다.
2. 약 3~4명이 동시에 작업했지만 범위가 너무 커서 작은 팀만으로 실제 제품으로 전환하기 어려웠다.
3. 샌드박스의 일부는 GitHub 데스크톱 애플리케이션으로 옮겨졌고, 프로토타입은 GitHub 경영진이 멀티플레이어 작업의 중요성을 더 진지하게 보게 했다.
RAMP와 내부 시스템 통합은 협업의 질을 바꾼다
1. 대화에서 언급된 RAMP 계열 사례는 Slack 채널, Chrome 플러그인, 웹 인터페이스를 통해 에이전트가 내부 시스템과 클라우드 머신에 접근하게 했다.
2. 제품 디자이너와 PM이 있는 Slack 채널에서 에이전트가 맥락을 얻고, 누구나 세션에 참여해 방향을 바꾸거나 제안할 수 있었다.
3. 처음에는 기밀성과 세션 공개가 걱정됐지만, 참여자들은 공유가 오히려 업무를 문명화하고 피드백 루프를 넓힌다고 판단했다.
4. 이 경험을 범용 제품으로 만드는 일은 한 회사의 내부 시스템에 맞추는 것보다 훨씬 어렵지만, Slack과 Jack Dorsey의 Buzz 같은 제품도 같은 방향으로 움직이고 있다.
다음 연구 질문은 방해하지 않는 선제적 에이전트다
1. ACE의 범위를 줄이면서 GitHub의 향후 6개월~1년과 더 먼 미래를 탐색할 수 있는 작은 프로토타입을 만드는 방향으로 전환했다.
2. 지능이 매우 싸거나 사실상 무료가 되어 배경 에이전트 100개를 둘 수 있다고 가정하면, 결과를 가장 덜 방해받는 방식으로 소비하는 방법이 새로운 문제다.
3. 여러 에이전트가 문서를 함께 조사하고 유용한 백그라운드 작업을 수행하되, 사람에게 끊임없이 변경을 강요하거나 알림을 쏟아내지 않는 인터페이스가 필요하다.

8. 자동화되는 세부와 인간의 장인정신

8.1. 사라지는 코드 편집기와 남는 디자인 세부

Jorge Manrubia의 “Oh, my craft”가 변화를 포착한다
1. 모델이 세부 구현을 독립적으로 처리할 만큼 좋아지면서 작은 부분에 개입하는 일이 인간의 관심을 낭비하는 것처럼 느껴진다는 글이 소개됐다.
2. Jorge는 몇 달 동안 코드 에디터를 열지 않았고 한 줄도 직접 작성하지 않았다고 썼다.
3. 코드 내부에 머물며 모든 세부를 보던 숙련이 약해질 수 있다는 불안과, 모델이 처리할 수 있는 일에 시간을 쓰지 않는 편이 낫다는 효율성 사이에 긴장이 생긴다.
매기의 기준에서는 디자인 세부가 아직 자동화되지 않았다
1. 에이전트는 매기가 원하는 품질의 전환·간격·프레임 그림자·테두리 불투명도를 일관되게 구현하지 못하므로, 매기는 여전히 결과를 세밀하게 보고 수정한다.
2. 개인의 프레임 사이 간격 같은 선호를 스킬 문서에 적어도 모든 제품과 맥락에 보편적으로 적용되지 않는다.
3. 에이전트가 내일 모든 디자인 규칙을 정확히 구현한다면 멋진 인터페이스가 눈앞에 생기는 기쁨은 남겠지만, 직접 만드는 즐거움이 사라질지는 확신할 수 없다.
자동화가 장인정신을 없앨지 모른다는 질문이 남는다
1. 원하는 디자인을 에이전트가 완벽히 구현하면 결과물을 보는 만족감과 결과물을 만드는 만족감이 달라진다.
2. 사람이 세부를 조정하는 시간은 비효율일 수도 있지만, 그 조정 자체가 취향을 형성하고 새로운 형태를 발견하는 과정일 수도 있다.
3. 자동화의 목표는 인간의 관심을 전부 제거하는 것이 아니라, 인간이 더 높은 수준의 문제와 의도에 집중할 수 있게 세부의 성격을 바꾸는 데 있어야 한다.

8.2. AI 방 인테리어와 인터페이스의 진정성

AI가 만든 방은 그럴듯해도 실제 공간이 아니다
1. Pinterest에서 본 AI 인테리어 이미지는 아름답지만, 빛의 방향이 틀렸거나 실제로 존재하지 않는 방일 수 있다.
2. 누군가 실제로 만든 공간이 아니라면 그 방의 물리적 제약과 생활의 흔적을 생각할 이유가 줄어든다.
3. 인터페이스도 인터넷의 평균을 학습해 보기 좋은 화면을 만들 수 있지만, 실제 사용 맥락과 만든 사람의 의도가 없으면 비슷한 공허함이 생긴다.
미학은 제품에 대한 신뢰 신호다
1. 크림색 배경, 붉은 텍스트, 특정한 타이포그래피처럼 Claude 계열 생성물에서 반복되는 언어적·시각적 흔적은 사람이 거의 개입하지 않았다는 신호가 된다.
2. 사용자는 제품이 자신의 문제를 이해하고 세심하게 만든 것인지, 새로 생성된 기본 템플릿인지 미학을 통해 추측한다.
3. 공통된 기본 규칙을 지키면서도 문화적 맥락과 의외의 선택을 더하는 인간의 판단이 차별화를 만든다.
글에서도 인간의 흔적은 감지된다
1. 매기는 많이 읽고 쓰기 때문에 과도한 형용사와 반복적인 문장 빈도, “이것이 아니라 저것이다” 같은 틀을 빠르게 알아챈다.
2. 오래전에 쓰인 책의 자연스럽고 낯선 문장을 읽으면 에이전트가 만든 글과 다른 신선함을 느낀다.
3. 전문가가 인공적인 문체를 모두 알아보는 것은 아니지만, 특정 분야를 깊이 읽는 사람은 텍스트의 작은 이상을 감지할 가능성이 높다.

9. 디지털 가든과 맨발 개발자

9.1. 미완성 상태를 공개하는 디지털 가든

디지털 가든은 완성된 글만 올리는 블로그가 아니다
1. 글을 씨앗(seedling), 자라는 글, 상록수(evergreen) 같은 단계로 표시하고, 반쯤 완성된 생각도 독자에게 미완성임을 알린 채 공개한다.
2. 2020년 무렵부터 이 방식을 시작했고, 완벽주의 때문에 아무것도 공개하지 못하는 문제를 줄였다.
3. 어떤 글은 몇 문단에 그치지만 어떤 글은 긴 에세이이며, 3년 동안 시간이 날 때마다 한 문단씩 덧붙이는 글도 있다.
공개 작업은 독자와의 합의에 기반한다
1. 글 중간에 “draft in progress”라고 표시하고 아래의 거친 메모와 목록을 완성본으로 가장하지 않으면 독자는 그 상태를 알고 읽는다.
2. 작가가 무엇이 초안인지 숨기지 않고, 독자가 초안의 정신으로 읽는다는 합의를 만들면 공개 작업이 가능해진다.
3. 완성도를 기다리기보다 생각이 자라는 과정을 공개하면 더 많이 쓰고 더 오래 수정할 수 있다.

9.2. 홈 소프트웨어와 맨발 개발자

홈 소프트웨어는 가족을 위한 수제 도구다
1. 2024년 베를린의 지역 콘퍼런스에서 Robin Sloan의 표현을 빌려, 집에서 만든 음식처럼 자신과 가족을 위해 만드는 소프트웨어를 소개했다.
2. Robin Sloan의 사례에는 가족이 짧은 동영상을 서로 보내는 작은 애플리케이션이 있었고, 대기업 서버나 광고·결제 모델에 의존하지 않았다.
3. 모든 소프트웨어가 앱스토어에서 2.99달러를 받거나 사용자의 데이터를 팔아야 하는 것은 아니며, 작은 도구가 가족의 삶을 직접 개선할 수 있다.
4. 에이전트가 확산된 뒤 사람들은 레시피 관리자, 집안용 앱, 운동용 앱처럼 자신에게 맞는 소프트웨어를 직접 만들 수 있게 됐다.
맨발 의사는 맨발 개발자의 비유가 된다
1. 중국의 맨발 의사 프로그램은 농촌 주민을 데려와 예방접종과 항생제 투여 같은 기본 의료 지식을 가르친 뒤 마을에 배치했다.
2. 병원에 갈 수 없는 사람들의 건강을 개선한 성공적인 분산 모델은 고도로 훈련된 전문가만 모든 일을 해야 한다는 전제를 흔들었다.
3. 현재 개발자는 매우 비싸고 높은 자격을 요구하는 직업이지만, 많은 사람에게는 정원이나 거리의 작은 문제를 해결할 간단한 소프트웨어가 필요하다.
4. 에이전트는 모든 사람을 전문 개발자로 만들기보다, 평범한 사람이 자신의 문제에 맞는 작은 도구를 만들도록 돕는 맨발 개발자의 기반이 될 수 있다.

주요 발언 모음

“디자인의 재료가 코드와 다를 뿐, 문제를 정의하고 조사하고 프로토타이핑하고 검증하는 과정은 엔지니어링과 같다.”

“손으로 그린 것은 화면에서 사라지지 않는다. 다음 날 테이블 위에서 다시 보고 무엇을 만들려 했는지 기억할 수 있다.”

“디자인 엔지니어는 시각적 디자인만 하는 사람이 아니라 제품의 기술 아키텍처를 깊이 이해하고 구현에 참여하는 디자이너다.”

“에이전트는 사람에게 필요한 정보를 소화하기 쉽게 만들지 않고 엄청난 양의 텍스트를 출력하는 데 익숙하다.”

“모델은 어떤 일에는 놀라울 정도로 좋고 다른 일에는 놀라울 정도로 나쁘다. 그래서 무엇을 얻게 될지 항상 알 수 없다.”

“팀이 에이전트에게 넘기는 순간이 너무 빨라졌기 때문에, 그 전에 모두가 같은 결정을 공유해야 한다.”

“디지털 가든은 미완성인 것을 미완성이라고 말하는 한 공개적으로 생각할 수 있게 해 준다.”

핵심 데이터 & 수치

12~13세: 매기가 HTML과 CSS를 배우기 시작한 시기다.
약 4년: Egghead에서 일러스트레이터와 아트 디렉터로 일한 기간이다.
2021년 말~2022년 초: Elicit에 합류한 시점이다.
6~7명: Elicit 합류 당시의 작은 팀 규모다.
2년 이상: Elicit에서 매주 기능을 설계·출시·측정하는 반복을 이어 간 기간이다.
36개 질문: 에이전트의 기획 스킬이 한 번에 던진 질문 수의 사례다.
20~25번째 질문: 사용자가 피로를 느끼기 시작한 지점이다.
GPT-3.5, 2022년 11월: 대화형 에이전트 인터페이스가 대중화된 기준점으로 언급됐다.
약 60년: 소프트웨어 개발의 역사가 아직 인간-기계 인터페이스를 완전히 이해하기에는 짧다는 맥락에서 제시됐다.
2010~2013년: Brett Victor의 생생한 프로그래밍 관련 발표들이 언급된 시기다.
20개 대안: 디자이너가 없는 상황에서 모델에게 생성하게 할 수 있는 고품질 디자인 후보의 예다.
약 3~4명: GitHub Next의 ACE 프로토타입을 동시에 작업한 인원이다.
100개 배경 에이전트: 지능이 매우 싸다고 가정했을 때 상정한 미래의 규모다.
2020년 무렵: 매기가 디지털 가든을 시작한 시점이다.
2024년 베를린: 홈 소프트웨어와 맨발 개발자를 발표한 콘퍼런스 시기다.
2.99달러: 홈 소프트웨어가 반드시 앱스토어에서 이 가격을 받고 데이터를 판매해야 하는 것은 아니라는 예시다.
418회/초, 89배: 후원 구간에서 Entire가 제시한 저장소 푸시 처리량과 경쟁 서비스 대비 속도다.

후원 구간에서 언급된 제품

Antithesis
1. 전체 시스템을 적대적인 조건에서 모델링하고 오류를 찾는 검증 도구로 소개됐다.
2. 오류 확률을 가상 시간축으로 시각화하고, 특정 시점으로 되돌아가 Bash 명령을 실행하며 재현 환경을 조사할 수 있다.
3. 선형화 오류 같은 특정 오류가 시간에 따라 얼마나 드물거나 널리 발생했는지 브라우저에서 필터링하고 시각화하는 기능이 강조됐다.
Turbopuffer
1. 오브젝트 스토리지 위에서 동작하는 빠르고 저렴하며 확장 가능한 벡터·全文 검색 인프라로 소개됐다.
2. Anthropic, Notion, Bridgewater, Cognition 같은 AI 기업과 빠르게 성장하는 회사의 검색 부하를 지원하며 신뢰성·성능·확장성을 중시한다.
3. 평범한 엔터프라이즈 인프라 회사의 무균적인 브랜딩을 거부하고, 직접 만든 ASCII 차트와 단순하지만 재미있는 웹사이트로 하드코어한 팀의 성격을 드러낸다.
Entire
1. 에이전트가 병렬로 더 많은 코드를 생성하면서 GitHub와 Git이 병목이 되는 문제를 해결하려는 Git 호스팅 서비스로 소개됐다.
2. 저장소를 지역적으로 가까운 곳에 배치해 지연을 줄이고, 초당 418회의 푸시와 경쟁 서비스보다 최대 89배 빠른 처리량을 제시했다.
3. GitHub가 중단돼도 작업을 계속하고 기존 GitHub 저장소를 한 번의 CLI 명령으로 미러링할 수 있으며, 에이전트의 프롬프트와 대화 기록을 저장소에 함께 보존한다.

결론 및 시사점

디자인 엔지니어링은 색과 애니메이션을 코드로 옮기는 직무가 아니라, 사용자의 문제·제품의 개념·데이터 구조·기술 제약·구현 결과를 하나의 판단 체계로 연결하는 직무다.
디자이너는 플랫폼의 물성을 배워야 하며, 엔지니어는 사용자의 흐름과 의미가 전달되는 시각적 재료를 존중해야 한다.
종이 스케치와 화이트보드는 에이전트가 아직 이해하지 못하는 공간적 사고를 보존하고 팀의 공통 맥락을 만든다.
Figma는 최종 사양이 아니라 중간 해상도의 스케치로 사용하고, 가능한 한 빨리 브라우저의 라이브 변수와 실제 데이터로 검증해야 한다.
에이전트는 프로토타입의 품질과 야심을 높이지만, 모델의 불일치와 시각적·문화적 맥락 결핍을 감안해 결과를 계속 검증해야 한다.
익숙한 표·문서·카드·사이드 패널을 출발점으로 AI 기능을 확장하면 인지 부하를 낮추면서 새로운 능력을 제공할 수 있다.
에이전트가 생성하는 평균적인 Linear·Vercel 스타일을 넘어서는 인간의 문화적 감각과 의외의 선택이 제품을 구별한다.
에이전트 시대의 큰 병목은 코드 생성 속도가 아니라 팀이 같은 문제와 결정을 공유하고 승인자를 기록하는 공동 엔지니어링이다.
ACE 같은 멀티플레이어 작업공간은 대화·샌드박스·PR·감사 로그를 한곳에 모으는 방향을 보여 주며, 결정 카드는 에이전트 협업의 핵심 프리미티브가 될 수 있다.
홈 소프트웨어와 맨발 개발자는 전문 개발자의 희소성을 인정하면서도 더 많은 사람이 자신의 삶에 맞는 작은 도구를 만들게 하는 분산형 미래를 가리킨다.

핵심 요약 (20줄)

디자인 엔지니어링은 시각적 완성도와 제품의 기술 아키텍처를 동시에 다루는 문제 해결 활동이다.
디자이너와 엔지니어는 문제 정의·조사·프로토타이핑·검증이라는 같은 과정을 서로 다른 재료로 수행한다.
매기 애플턴은 문화인류학과 일러스트레이션을 거쳐 프론트엔드와 AI 제품 디자인으로 이동했다.
Neopets와 MySpace에서 익힌 HTML·CSS는 어린 시절의 인터넷 취미를 제품 제작의 기반으로 바꿨다.
Elicit에서 유일한 디자이너로 일하며 주간 출시와 측정을 반복한 경험이 제품 디자인의 전체 흐름을 가르쳤다.
복잡한 AI 도구는 세션·계획·MCP·스킬 같은 명사와 편집·삭제 같은 동사를 명확히 정의해야 한다.
디자인 엔지니어는 데이터·API·성능·레이스 컨디션을 이해하고 구현에 직접 참여한다.
종이와 펜은 언어로 표현하기 전의 공간적 사고를 보존하며 에이전트의 시각 이해 한계를 보완한다.
Figma는 최종 사양이 아니라 브라우저 검증으로 넘어가기 위한 중간 해상도의 스케치다.
슬라이더와 라이브 변수는 목공의 지그처럼 불확실한 디자인 값을 빠르게 실험하게 한다.
에이전트는 가짜 클릭 프로토타입을 실제로 작동하는 고품질 시제품으로 바꾸고 실험 범위를 넓힌다.
Brett Victor의 생생한 프로그래밍 개념은 변수와 결과 사이의 직접적인 피드백을 요구한다.
단순한 가설에는 AI가 만든 20개 대안이 유용하지만 새로운 제품의 형태와 사용자 의미는 디자이너가 정해야 한다.
Elicit의 표 실험은 익숙한 인터페이스가 새로운 AI 기능보다 낮은 인지 부하를 제공할 수 있음을 보여 줬다.
모델은 같은 작업에서도 성능이 흔들리므로 높은 성능에 감탄한 뒤에도 결과를 회의적으로 검증해야 한다.
에이전트가 빨라질수록 팀은 구현 전에 문제·사양·인터페이스·아키텍처를 더 엄격하게 합의해야 한다.
ACE는 Slack·샌드박스·PR을 공유하는 멀티플레이어 작업공간으로 공동 엔지니어링의 방향을 제시했다.
AI가 만든 평균적인 미학이 확산될수록 문화적 맥락과 인간의 의외성이 제품의 신뢰와 차별화를 결정한다.
디지털 가든은 초안임을 공개하는 합의를 통해 완벽주의를 낮추고 생각의 성장을 기록하게 한다.
홈 소프트웨어와 맨발 개발자는 에이전트를 이용해 평범한 사람도 자신과 가족을 위한 작은 도구를 만드는 미래를 가리킨다.