코딩 에이전트는 획일적 앱 사일로와 프로그래밍 중심 문화라는 두 가지 제약을 넘어설 새로운 길을 열고 있다. 가변적이고 조합 가능한 인터페이스, 특히 전문 사용자를 위한 읽기 환경의 가능성과 함께, 인터페이스 발명 문화가 어떻게 달라질 수 있는지를 탐구한다.
코딩 에이전트는 마침내 우리가 두 개의 감옥에서 벗어나도록 도울지도 모른다. 하나는 컴퓨팅을 획일적인 사일로에 가두는 앱 모델이고, 다른 하나는 상상력과 도메인 통찰의 문화를 밀어내 온 전문화로서의 프로그래밍이다.
에이전트는 일회성 앱을 만들 수 있지만, 대개는 장난감 수준에 그친다. 나는 전문가들이 하루 종일 깊이 의존하는 종류의 인터페이스에 가변성과 조합 가능성을 어떻게 가져올 수 있을지 보여주려 한다. 글쓰기 환경에서 시연하지만, 이는 모든 진지한 소프트웨어에 적용 가능하다. 진지한 읽기 소프트웨어는 거의 존재하지 않기 때문에, 나는 전문가 사용에 초점을 맞춘 새로운 종류의 가변적 디지털 읽기 환경을 제안하고 시연한다.
하지만 가변적 인터페이스만으로는 충분하지 않다. 역사적으로 인터페이스를 발명하려면 상상력 있는 설계 능력, 깊은 도메인 통찰, 그리고 유창한 프로그래밍 능력이 필요했다. 이 세 가지를 모두 갖춘 사람은 드물지만, 프로그래밍만은 그것 자체만으로도 작동하는 소프트웨어를 만들 수 있는 유일한 기술이다. 그래서 인터페이스 발명 문화는 프로그래머가 지배하게 되었다. 나는 코딩 에이전트가 그 상황을 어떻게 바꾸고 있는지, 그리고 오늘날 인터페이스를 발명하는 사람들과 기관들에게 그것이 어떤 의미를 가질 수 있는지에 대한 초기 보고를 공유한다.
불과 몇천 년 전만 해도, 우리 조상들에게는 문자 언어가 없었다. 생물학적으로 우리는 그 인간들과 거의 같지만, 우리 마음속에서 일어나는 일은 그들에게 완전히 낯설었을 것이다. 종이와 펜이 있는 세계에서 자란 것은 우리를 바꾸어 놓았다.
우리는 작업 기억 너머로 사고의 사슬을 따라갈 수 있다. 추상적이고 분석적으로 생각할 수 있다. 한 번도 만난 적 없는 사람들의 생각 위에 우리의 생각을 쌓을 수 있고, 우리 자신의 생각을 후대에 남길 수도 있다. 하지만 그런 능력을 준 것은 자연선택이 아니었다. 다른 사람들이었다. 우리는 우리 자신의 생각을 형성하는 도구를 만들 수 있는 그 놀라운 힘, 즉 우리 자신의 정신 능력을 초월할 수 있는 힘을 물려받았다.
문자 언어는 온 문화권 전체의 작업이었다. 하지만 내 작업에서 가장 나를 흥분시키는 것은, 작은 집단이나 심지어 개인도 생각을 바꾸는 도구를 발명할 수 있다는 점이다.
나는 18세기의 Playfair와 통계 그래픽, 혹은 19세기의 Mendeleev와 원소 주기율표를 떠올린다. 이런 도구들은 발명되는 만큼이나 발견되기도 한다. 그 힘은 주기 법칙 같은 깊은 도메인 통찰을 우리가 생각하고 소통하는 데 사용할 수 있는 외적 형태로 응축하는 데 있다.
개인용 컴퓨팅 혁명의 위대한 꿈 가운데 하나는, 우리 모두가 자기만의 컴퓨터뿐 아니라 자기만의 소프트웨어도 갖게 되리라는 것이었다. 그것도 각자의 목적에 정교하게 맞춰진 형태로 말이다. 하지만 대신 우리는 무심코 두 가지 우연한 폭정 속으로 걸어 들어갔다.
첫 번째는 애플리케이션 모델이다. 소프트웨어를 만드는 데 비용이 많이 들기 때문에, 개발자는 가능한 한 큰 시장을 확보해야 한다. 그 결과 획일적인 패키지가 생겨났다. 당신은 개발자가 제공한 조절 장치만 만질 수 있다. 당신의 도구들은 개발자가 예상한 접점에서만 결합될 수 있다. 우리는 벽으로 둘러싸인 정원의 풍경 속에 살고 있고, 그 결과 우리의 워크플로는 종종 우리가 바라는 방식으로 작동하지 않는다.
두 번째는 프로그래밍 자체다. 새로운 보편 문해를 만드는 대신, 우리는 전문 사제 계급을 만들어 냈다. 이에 대한 익숙한 불만은 최종 사용자가 동적 매체의 수동적 소비자로 전락한다는 것이다. 하지만 나는 기술 산업 내부에서조차 프로그래밍 문화가 우연히 발명을 가로막고 있다는 주장도 하려 한다.
하지만 지금 나는 이 함정들에서 벗어나는 몇 가지 새로운 길을 보고 있다.
먼저 앱에 집중해 보자. 물론 애플리케이션 모델은 우리 분야에서 익숙한 악역이다. 사람들은 수십 년 동안 우리를 그 사일로에서 해방시키려 애써 왔다.
주요한 작업 흐름 가운데 하나인 최종 사용자 프로그래밍은 비전문 프로그래머도 자기만의 소프트웨어를 만들 수 있게 하려 한다. 하지만 실제로는 몹시 어려운 것으로 드러났다. 스프레드시트가 가장 큰 성공 사례지만, 그 외의 사례를 만들어 내기는 어려웠다.
물론 최근까지는 그랬다. 이제 우리는 코딩 에이전트를 갖고 있다. 이제 누구나 자기만의 소프트웨어를 만들 수 있는 것 아닌가?
음… 아마도! 2026년 초를 둘러보면, 나는 비프로그래머들이 개인 대시보드와 자동화 같은 것을 만드는 모습을 본다. 서로 호환되지 않는 여러 시스템의 데이터를 연결하거나 결합하는 스크립트를 사람들이 작성하는 것도 본다. 이미 앱 사일로에 약간의 균열을 내고 있다. 그리고 물론, 재미있는 장난감도 많이 본다. 전반적으로 내가 주로 보는 것은 비프로그래머들이 에이전트를 사용해 접착 코드와 일회성 도구를 만드는 모습이다. 대부분 그들의 진짜 일의 주변부에서 말이다.
물론 그것은 환상적이며, 앞으로도 사람들은 점점 더 야심찬 개인용 도구를 만들게 될 것이다. 하지만 나는 더 많은 것을 원한다. 이 흐름을 좀 더 밀어붙여 보자.
내가 아는 한, 영화 제작자들은 아직 코딩 에이전트를 사용해 자기 편집 워크스테이션을 개인화하고 있지 않다. 음악가들도 코딩 에이전트를 사용해 자기 악보 소프트웨어를 개인화하고 있지 않다. 비프로그래머가 복잡한 인터페이스, 즉 자기 작업의 한가운데 있는 인터페이스에 대해 즉흥적으로 개선을 가할 수 있으려면 무엇이 필요할까? 나는 개인용 동적 매체의 꿈이 그들의 실천에서 가장 중요한 부분에서 실현되는 모습을 보고 싶다.
그 중요한 부분은 종종 극도로 복잡한 "메가 앱" 안에서 일어난다. 영화 제작자는 Adobe Premiere에서 수천 시간을 보낸다. 작곡가는 Sibelius에서 수천 시간을 보낸다. 이런 앱들은 플러그인을 지원하지만, 작은 상자 안에 갇혀 있다. 플러그인은 모달이나, 어쩌면 사이드바에 인터페이스를 렌더링하는 정도만 허용된다. 하지만 사용자가 자신의 개인적 워크플로를 위해 그 앱들의 주요 상호작용 표면을 개선하고 싶다면, 그 모든 복잡성을 다시 만들어야 한다. 오늘날의 코딩 에이전트도, 그것을 쓰는 일반적인 사용자도 새로운 종류의 브러시 도구를 추가하기 위해 즉석에서 Photoshop 전체를 다시 쓸 준비는 되어 있지 않다.
그러므로 우리가 사일로화된 모놀리스를 벗어나고 싶다면, 오늘날의 제로투원 "텍스트에서 앱까지" 코딩 에이전트 워크플로보다 더 가변적인 기반이 필요하다. 이 문제를 연구하는 연구자들은 물론 그 사실을 알고 있고, 우리는 Smalltalk에서 Webstrates, Potluck에 이르기까지 사용자 확장을 위한 원칙적 아키텍처를 제안하는 시스템들을 보아 왔다.
문제는 이 접근들 가운데 어느 것도 "텍스트에서 앱까지" 워크플로만큼 다재다능하고 접근 가능하지 않다는 점이다. 사용자가 복잡한 소프트웨어를 처음부터 다시 쓰지 않고도 적응시킬 수 있을 만큼의 구조, 그리고 비프로그래머도 사용할 수 있을 만큼의 다재다능함과 접근성을 동시에 갖춘 행복한 중간 지점을 찾을 수 있을까?
이제 Photoshop 같은 앱의 플러그인이 작은 상자에 갇혀 있는 것은 이해할 만하다. 그 주요 상호작용 표면은 엄청나게 복잡하다. 플러그인이 거기에 손을 뻗어 이것저것 바꾸기 시작하면, 금세 혼돈이 벌어질 것이다. 안전하고 표현력 있는 확장성을 제공하려면 API 표면이 지나치게 복잡해져서 플러그인을 쓰는 일이 엄청나게 어려워질 것이다. 플러그인에 완전히 제어할 수 있는 패널 하나를 그냥 주는 편이 훨씬 쉽다.
그렇게 말해 두고도, 나는 이 규칙의 흥미로운 예외로부터 배울 수 있다고 생각한다.
Obsidian! 내가 알기로, 이것은 실제 제품으로 출시된 유일한 깊이 있는 확장 가능 GUI 워드 프로세서다. 다른 워드 프로세서들처럼 플러그인은 사용자 정의 테마, 명령, 고립된 패널을 추가할 수 있다. 하지만 다른 워드 프로세서와 달리, Obsidian의 리치 텍스트 에디터는 CodeMirror라는 유난히 조합 가능한 아키텍처를 가진 오픈소스 프레임워크 위에 만들어졌다. 그래서 유일하게도, Obsidian 플러그인은 리치 텍스트 에디터 자체의 동작과 표현을 임의로 확장할 수 있다.
예를 들어, 이 "LaTeX Suite" 플러그인은 내가 소스를 편집하는 동안 렌더링된 LaTeX의 인라인 미리보기를 보여 준다. 또 수식 표현식 안에 있을 때는 키보드 이벤트의 동작도 바꾼다. 예를 들어 탭 키를 누르면 커서가 현재 중괄호 범위 바로 바깥으로 이동한다.
이제 대부분의 Obsidian 플러그인은 에디터 GUI를 확장하지 않는다. 대부분의 Obsidian 플러그인은 그냥 사용자 정의 명령이나 고립된 패널을 추가한다. 내가 생각하기에 그 이유는 에디터 자체를 확장하려면 아주 복잡한 프로그래밍이 필요하기 때문이다. 그 복잡성은 필요해 보인다. 바로 그것이 안전하고 조합 가능한 에디터 플러그인을 가능하게 만들고, 곧 그것이 어떻게 작동하는지 더 이야기할 것이다. 하지만 그것이 큰 억제 요인인 것도 사실이다.
나는 경험 많은 프로그래머인데도, Obsidian용 에디터 확장을 이것저것 만지작거리기 시작할 때마다 그것이 요구하는 섬세한 작업이 너무 많아 금세 의욕을 잃곤 했다. 몇 번이고 내 야심의 범위를 줄이거나, 프로젝트를 아예 포기했다. 하지만 코딩 에이전트가 그 상황을 바꿔 놓았다. 그들은 그 복잡성을 대신 처리해 줄 수 있다.
실제로 지난 몇 달 사이, 그들은 내가 코드를 감독하지 않아도 복잡한 에디터 확장을 만들 수 있을 만큼 좋아졌다. 이건 최종 사용자 프로그래밍의 영역이다. 이제 내 기이한 워드 프로세싱의 꿈도, 대체로 변덕처럼 떠오르면 실현할 수 있다. 보여 주겠다.
나는 밖에서 읽는 데 많은 시간을 보낸다. 나는 능동적으로 읽고 싶은데, 보통이라면 읽으면서 노트에 써야 한다는 뜻이지만, 이런 의자에 앉아 있으면 무릎 위에서 그걸 균형 있게 놓기가 어렵다. 그래서 대신 나는 보통 귀에 마이크를 꽂고 읽으면서 중얼거린다.
문제는 그렇게 말한 코멘트들이 의미를 가지려면 책의 특정 구절을 가리켜야 하는데, 오디오로는 그게 어렵다는 점이다. 그래서 그걸 도와줄 새 도구를 만들었다. 지금 우리는 밖에 있지 않으니 디지털 책을 보여 주겠지만, 그냥 물리적 판본을 읽고 있다고 상상해 보자.
이렇게 페이지를 넘기다가 이런 구절을 만날 수 있고, 어쩌면 나는 바로 이 구절에 대해 코멘트가 있을 수 있다. Canon Cat에서 영감을 받아, 세 단어나 네 단어의 연속이 책 속 거의 어떤 지점이든 유일하게 식별할 수 있다는 걸 깨달았다.
그래서 나는 오디오 녹음을 시작한다. 그리고 읽어나가다가 스스로에게 이렇게 말할 수 있다. "quote, though, only three years older"라고 말한 다음, 그 구절에 대한 관찰을 whatever 말한다. 계속 읽다가 다른 구절을 찾고, "quote, we already feel the effects"라고 말한 다음, 거기에 대해 하고 싶은 말을 이어 간다. 이런 식으로 한 시간 동안 녹음할 수도 있다.
그런 다음 컴퓨터로 돌아와 이 오디오를 복사하고 Obsidian으로 전환한다. 거기에는 특별한 플러그인이 있다. 우리는 마크다운 문서 한가운데 있다. 이미지가 있고, 책의 개요를 적은 블록 인용문이 있다. 나는 녹음을 붙여 넣고 전사한다.
이제 전사문이 생겼다. 오디오 전사는 특별한 일이 아니다. 하지만 흥미로운 일이 벌어지는 것이 보일 것이다. 내가 목소리로 어떤 구절을 가리킨 부분들이 노란색으로 강조되어 있고, 그 옆에 특별한 버튼이 있다.
이건 여전히 그냥 마크다운 문서다. 소스를 보면, 일반 평문과 블록 인용문, 이미지밖에 보이지 않는다. 하지만 스타일링이 라이브 에디터에 적용되고 있고, 버튼도 있다. 내가 그 버튼을 클릭하고 에디터에 내가 읽고 있던 epub을 가리키게 하면, 그것은 그 인용들을 텍스트의 특정 구절에 정박시킬 수 있다.
그 quote 지시문은 epub의 블록 인용문으로 대체되며, 책의 정확한 위치로 이동하는 상당히 정교한 링크도 함께 들어간다. 이 시점부터는 그냥 평문이므로, 나는 코멘트를 더 확장하고, 다른 코멘트를 추가하고, 위치를 옮기고, 복사해서 붙여 넣을 수 있다. 그냥 재료처럼 다루면 된다.
이걸 만든 뒤에는 오디오를 완전히 잃고 싶지 않다는 걸 깨달았다. 그 안에는 흥미로운 정동이 있었고, 여기에는 그냥 평문만 있기 때문이다. 그래서 또 다른 플러그인을 만들었다. 이 오디오 파일로 시연할 수 있다. 방금 본 플러그인의 설계에 대해 차 안에서 스스로에게 이야기하는 내 목소리다.
이걸 전사하면, 여기 흥미로운 것이 있다. 이것은 transcript 지시문이라 부르는 새로운 종류의 Markdown 지시문이다. 나는 재생 버튼을 눌러 오디오 재생을 텍스트 전사문과 동기화할 수 있다. 여러분 가운데 일부는 알아볼 수 있을, Steve Rubin의 오래된 작업에서 영감을 받았다. 명령 키를 누른 채 전사문 아무 곳이나 클릭해서 원하는 위치로 점프할 수 있다.
그리고 이것도 여전히 그냥 Markdown이다. 소스를 보면, 특별한 지시문 세 개의 콜론, 즉 Markdown 확장 지시문으로 감싼 평문뿐이다. 이제 몇 가지 흥미로운 일을 할 수 있다. 이 플러그인이 도입한 편집의 대수가 있다. 나는 여기로 가서 이 전사문 한가운데 새 코멘트를 쓰기 시작할 수 있는데, 그러면 삽입 지점 주변에서 전사 블록이 둘로 나뉘는 것을 볼 수 있다. 이전 블록에는 종료 시간이 붙고, 새 블록에는 시작 시간이 붙는다.
전사문 중간에서 문단 하나를 복사하고 새 파일을 만든 뒤 붙여 넣을 수도 있다. 그러면 여기에는 특정 시간에 시작해서 특정 시간에 끝나는 전사문 구간이 붙여 넣어진다. 명령 클릭은 여전히 작동하며 원본 파일로 연결된다. 전사문 중간을 삭제할 수도 있고, 그 빈틈에서 재생을 시작하면 삭제된 부분을 건너뛴다. 이것은 기존 에디터 한가운데 새로 도입된 꽤 복잡한 Markdown 동작이다.
이제 다음에 할 일은 이 플러그인들을 결합하는 것이다. 둘을 동시에 켜면, 내가 중얼거림 한가운데에 quote 지시문을 포함한 이 지점이 transcript 플러그인의 스타일링 안에서 quote 플러그인의 특유의 노란 강조를 갖는 것을 볼 수 있다.
새 데모 파일을 하나 만들어 보자. 아까 만든 오디오 파일을 붙여 넣고 transcript 플러그인으로 전사할 수 있다. 이제 그 녹음의 전사문이 transcript 지시문으로 감싸져 있으므로, 어디서든 명령 클릭해서 재생을 시작할 수 있다. 그리고 그 새로운 동작은 quote leap 플러그인의 기존 동작과 결합된다. 나는 quote를 클릭해 내장된 인용문들을 해석할 수 있고, 인용문 주변의 전사 재생도 여전히 된다. 사실 재생은 인용문을 건너뛴다. 나는 오디오 전사문을 갖고 있고, 인용문은 책 속에 직접 정박되어 있으므로, 스스로 중얼거리는 것을 들으면서 내가 무엇을 가리키는지 볼 수 있다.
이 두 플러그인은 이 WYSIWYG 텍스트 에디터의 동작을 깊이 있게 함께 수정하고 있다.
이제, 그 데모에서 흥미로운 점은 그 특정 플러그인들의 상호작용 설계 자체가 아니다. 각각의 인터페이스는 어떤 평범한 HCI 논문에서 연구 시스템을 시연하는 일부로 볼 수도 있을 것이다.
아니다. 그 데모에서 흥미로운 점은 이것이 연구 시스템이 아니라는 것 이다. 나는 이 동작들을 실제로 사용하는 상용 워드 프로세서인 Obsidian 안으로 가져왔다. 만약 저 상호작용들이 전형적인 HCI 논문을 위해 프로토타입된 어떤 글쓰기 환경의 일부였다면, 나는 그것들을 평소 쓰는 워드 프로세서에서 사용할 수 없었을 것이다. 나는 어떤 대학원생이 사용자 평가를 돌릴 수 있을 정도로만 다듬은 글쓰기 환경을 써야 했을 것이다.
이런 식으로 앱 사일로는 발명을 가로막는다. 내가 Photoshop이나 Microsoft Word 같은 복잡한 도구에 새로운 인터페이스 아이디어를 기여하고, 전문가 수준의 채택까지 보기를 원한다면, 나는 최고의 기존 앱이 이미 제공하는 모든 기능을 다시 구현해야 한다. 그리고 나서야 비로소 내 아이디어를 맨 위의 체리처럼 얹을 수 있다. 누구나 연구 연옥에서 벗어나기 위해 엄청난 세금을 내야 한다.
그리고 상황은 더 나빠진다. 내가 보여 준 각각의 상호작용이 각기 다른 저자가 쓴 다른 논문에서 구현되었다고 가정해 보자. 내가 데모 마지막에서 했던 것처럼 두 동작을 동시에 사용하고 싶다면, 나는 그냥 방법이 없다. 각각의 새 동작은 자기 시스템 안에 갇혀 있다.
이 데모에서 다른 점은 조합 가능성 이다. 그 복잡한 새 동작들이 Obsidian의 기존의 복잡한 에디터와 조합되고, 서로 간에도 조합된다. 어떤 특별한 지식이나 결합 없이 말이다.
물론 코딩 에이전트가 이 동작들을 나 대신 만들어 주었다는 점도 좋다. 하지만 특히 흥미로운 것은 조합 가능성과 코딩 에이전트의 결합이다. 조합 가능한 아키텍처 없는 코딩 에이전트는 제로투원의 사일로 앱을 줄 뿐이다. 코딩 에이전트 없는 조합 가능한 아키텍처는 새로운 플러그인을 가장 헌신적이고 경험 많은 개발자 외에는 감당하기 어렵게 만든다. 둘이 함께라면, 비프로그래머도 기존의 복잡한 인터페이스 위에서 마음껏 즉흥 변주할 수 있게 될지 모른다.
이제 우리는 Obsidian의 관점에서 이야기해 왔다. 사용자가 경험하는 상위 패키지가 그것이기 때문이다. 하지만 그 에디터의 조합 가능성에 대한 진짜 공은 Marijn Haverbeke가 만든 오픈소스 프레임워크 CodeMirror에 돌아가야 한다.
텍스트 에디터를 먼저 만든 뒤 그 위에 나중에 플러그인 시스템을 설계한 것이 아니라, Marijn은 플러그인으로 이루어진 텍스트 에디터를 설계했다. 설명해 보겠다.
Obsidian은 WYSIWYG Markdown 에디터다. 하지만 CodeMirror는 Markdown도, 이미지도, 글머리 기호 목록도, 링크도, 표도 모른다. Obsidian 에디터에서 평문을 넘어 보이는 모든 것은 CodeMirror 플러그인이다. 그러므로 사용자가 자기만의 CodeMirror 플러그인을 추가할 때, 그들은 Obsidian 개발자들이 자기 제품을 만들 때 쓴 것과 정확히 같은 원시 요소를 사용하는 셈이다.
CodeMirror는 매체의 대략적인 물리학을 정의한다. 텍스트, 상태, 선택에 대한 기본 모델과 트랜잭션적 업데이트 말이다. 그 밖의 거의 모든 것, 즉 텍스트가 어떻게 보이는지, 클릭하거나 타이핑하면 무슨 일이 일어나는지, 어떤 상태가 유지되는지, 텍스트 옆에 무엇이 나타나는지, 이 모든 것은 facet 을 통해 기술된다.
Facet은 독립적인 플러그인들이 같은 관심사에 안전하게 기여할 수 있게 하는 조합 가능한 구조다. 플러그인은 문서에 행동 하지 않는다. 자신이 원하는 것을 선언 한다. 그런 다음 장식, 키 바인딩, 상태 업데이트, 그 밖의 모든 것에 대해 CodeMirror의 물리학이 그 선언들을 결합하고 실행하는 규칙을 정의한다.
우리가 방금 본 데모의 관점에서 이것이 어떻게 작동하는지 보자.
여기 왼쪽에는 오디오 전사문 안의 quote 지시문에 대해 두 플러그인이 동시에 작동하는 모습이 보인다. 그 동작의 한 요소는 시각적 스타일링이다. 오디오 전사문은 작은 고정폭 텍스트를 사용하고, quote 지시문은 노란 빛을 띤다. 둘은 동시에 적용될 수 있다. CodeMirror의 EditorView는 플러그인이 에디터의 동작과 외형을 제어할 수 있도록 많은 facet을 제공한다. 그중 핵심 facet 하나가 "decorations"다. 오디오 transcript 플러그인은 5–18행에 "transcript" CSS 클래스를 적용하고 싶다고 선언한다. 별도로, Quote Leap 플러그인은 어떤 문자 범위에 다른 CSS 클래스를 적용하고 싶다고 선언한다. decorations facet은 그런 선언들을 모두 결합해 DOM에 적용한다. 텍스트 왼쪽의 버튼에도 비슷한 전략을 쓴다.
그렇다면 Markdown transcript 안에서 인용문을 해석하는 것은 어떨까? 우선, 오디오 transcript는 에디터 모델의 일부다. 이것은 Markdown 문법 확장이지만, 데이터는 어떤 별도의 저장소에 격리되어 있지 않고 여전히 Markdown 문서 안에 있다. 즉 다른 플러그인도 그것을 볼 수 있다는 뜻이다. 그래서 quote 지시문 옆 버튼을 누르면, 플러그인은 Markdown을 파싱하고, 그 quote 지시문들을 모두 찾아 책에서 해석된 인용문으로 바꿔 넣는다. 하지만 transcript 블록이 블록 인용문을 중심으로 갈라지는 것을 주목해 보라.
편집 연산도 명시적으로 조합되기 때문에 그렇게 할 수 있다. transactionFilter라는 또 다른 facet이 있다. quote 블록 대체 같은 편집 연산은 트랜잭션 데이터 구조 안에 선언적으로 기술된다. 그 트랜잭션들은 플러그인들이 선언한 transaction filter의 파이프라인을 통과하면서 변형될 수 있다. 오디오 transcript 플러그인은 quote leap 플러그인에 대해 아무것도 모르지만, 플러그인들을 결합하기 전에도 나는 새 줄을 삽입해 오디오 transcript 블록을 둘로 나눌 수 있었다. 그 플러그인은 transcript 블록 안에서 삽입이 일어나는지 감시하는 transaction filter를 선언하고, 삽입 지점을 중심으로 블록을 나누는 반응을 한다.
이 모든 선언적 기계 장치는 구현하기가 꽤 복잡하다. 왜 그것이 과거에 플러그인들에게 그렇게 높은 장벽을 만들었는지 알 수 있다. 하지만 다행히도, 나는 이 코드를 직접 쓸 필요가 없었다. 코딩 에이전트가 대신 썼다.
다른 확장 가능한 텍스트 에디터에서도 이런 일을 할 수는 있다. Emacs에서는 그냥 버퍼를 직접 변경하면 된다. 한 줄이면 끝이다. 하지만 두 플러그인이 같은 영역을 모두 건드리면, org-mode의 수년에 걸친 folding 재작성 같은 악몽 같은 이야기가 생긴다. 여러 다른 패키지를 계속 망가뜨리고 임시방편이 쌓여 갔다. CodeMirror의 선언적 접근은 서로 무관한 확장 메커니즘의 누더기를 일관된 조합 가능 패턴으로 대체한다.
이제 나는 이런 종류의 확장성을 리치 텍스트 에디터뿐 아니라, 내 디자인 작업과 음악, 그리고 읽기에도 원한다. CodeMirror가 리치 텍스트 편집의 물리학을 정의하고, 그 물리학이 플러그인들이 독립적으로 사용자 인터페이스를 확장할 수 있게 만든다면, 우리는 물을 수 있다. Figma나 Sibelius에 해당하는 물리학은 어떤 모습일까?
…하지만 잠깐, Figma나 Sibelius에 대해 답하려 하기 전에, 방금 나는 읽기에도 이런 확장성을 원한다고 말했다. 그걸 위해 나는 대체 어떤 소프트웨어를 확장하고 싶어 하는 걸까? Apple Books?
Preview.app? 어쩌면 PDF Expert? 문제는 단지 확장 가능한 전문가용 도구가 필요하다는 것보다 더 심각하다. 진지한 독자들은 애초에 전문가용 도구 자체를 가지고 있지 않다.
동적 매체의 특별함은 그것이 행동하고 반응한다 는 데 있다. 내가 Figma에서 디자인 시스템을 반복적으로 다듬을 때, 나의 선택이 내가 설계 중인 앱의 모든 화면에서 레이아웃과 무게감에 어떤 영향을 미치는지 실시간으로 볼 수 있다. 트랙을 믹싱할 때는 스펙트럼 시각화 도구가 탁한 구간을 빠르게 찾아 고치게 해 준다. 기후 모델링, 유전체학, 그리고 아주 많은 다른 도메인에서도 비슷한 이야기를 할 수 있다. 매체가 인지 부하의 일부를 떠맡아 주기 때문에, 우리는 생각의 속도에 더 가깝게 아이디어를 탐색하고 다듬을 수 있다.
한편 우리의 읽기 환경은 놀라울 만큼 거의 진화하지 않았다. 그런데도 진화할 여지는 엄청나게 많다. 우리는 읽은 것의 핵심 아이디어를 제대로 흡수하지 못하면서도 그것을 알아차리지 못하곤 한다. 불과 지난주에 매혹되었던 세부사항을 잊어버린다. 여백에 메모를 쓰지만, 여러 텍스트를 가로질러 보려 하면 애를 먹는다. 우리는 이 어느 것에도 동적 매체를 제대로 활용하지 못하고 있다. 대부분은 그냥 화면 속 종이 사진을 다루고 있을 뿐이다.
다른 도메인에서는 매체가 우리와 함께 춤추며 어려운 창조적 작업을 능동적으로 돕는다. 반면 학술에서는 종이가 무기력하게 놓여 있고, 우리는 전 인지 부하를 홀로 짊어진다. Engelbart를 되새기면: 벽돌은 여전히 우리 연필에 묶여 있다.
이렇게 말할 수도 있다. 어쩌면 읽기에는 다른 도메인에서 보았던 변혁적 도구를 가로막는 어떤 특별한 점이 있는지 모른다. 추구할 만한 증강이 없을지도 모른다. 하지만 연구자들은 인간의 인지와 의미 형성에 대해 꽤 많은 것을 밝혀냈다. 분명 우리는 그런 강력한 아이디어를 새로운 매체에 통합할 수 있을 것이다. 실제로 HCI 연구자들은 꽤 흥미로운 증강 읽기 시스템을 여럿 만들어 왔다.
Fok 등은 Scim에서 논문 속 목표, 새로운 기여, 결과를 담은 핵심 문장들을 강조하고 색으로 구분한다. 논문 속 수사적 역할에 따라 분류한 것이다.
Chang 등은 CiteSee에서 인용 링크를 색으로 구분해, 어떤 인용을 저장했고 읽었으며 인용했는지 쉽게 볼 수 있게 한다.
Kim 등은 Papeos에서 독자가 연구 논문과 저자의 관련 학회 발표 영상의 정렬된 구간 사이를 빠르게 오갈 수 있게 한다.
Tashman과 Edwards의 LiquidText는 사용자가 문서의 일부를 접을 수 있게 하여 병렬 읽기를 지원한다.
Romat 등은 SpaceInk에서 그 반대를 한다. 줄 주변의 공백을 늘려 여백 메모를 위한 공간을 만든다.
그리고 내가 Michael Nielsen과 함께 개발한 Quantum Country는 간격 반복 기억 시스템을 읽기 경험에 통합해, 독자가 읽은 것을 훨씬 더 잘 기억할 수 있게 한다.
여기에 많은 것이 있다. 하지만 개별 프로젝트의 아이디어들이 아무리 흥미로워도, 그것들이 잘 축적되지는 않는다. 각각의 상호작용은 자기만의 읽기 환경에 갇혀 있고, 앞서 말한 그 연구 연옥에 묶여 있다. CiteSee의 색 구분된 인용을 쓰고 싶다면, 그 프로토타입을 PDF 리더로 써야 한다. 그런데 내가 언급한 다른 시스템의 기능도 원한다면, 아예 다른 리더로 통째로 갈아타야 한다.
그래서 CodeMirror를 일반화하는 의미에서 묻고 싶다. 이 이질적인 증강 읽기 아이디어들을 동시에 지원하고, 아직 발명되지 않은 더 많은 아이디어까지도 수용할 수 있는 읽기 환경의 물리학 을 정의할 수 있을까?
여기에는 가변적인 읽기 환경의 프로토타입이 있다. 이 읽기 환경은 CodeMirror의 facet과 같은 철학, 즉 선언적 기여와 시스템이 관리하는 결합을 사용하지만, 보게 되겠지만 읽기는 편집에는 없었던 새로운 조합 요구를 드러낸다. 몇 가지 플러그인을 가지고 놀아 보자.
여기 Scim의 한 버전이 있다. 문장들이 색 배경과 함께 빛난다. 목적은 초록색, 방법은 파란색, 결과는 주황색이다. 논문 속 수사적 역할에 따라 분류된 것이다. 이 플러그인은 CodeMirror와 마찬가지로 텍스트 범위에 장식을 선언하는 방식으로 작동한다.
그리고 여기에는 CiteSee의 일부가 있다. 인용 표식이 당신의 읽기 이력에 따라 색을 띤다. 초록색은 당신이 그것을 읽었다는 뜻이고, 위에 마우스를 올리면 논문 상세 정보가 담긴 카드를 볼 수 있다. 이것은 서로 다른 두 저자의 원 논문을 나타내는 두 개의 확장이고, 같은 텍스트 위에 조합되어 있다. 어느 쪽도 서로에 대해 알지 못한다. 시스템이 그들의 선언, 즉 색 배경, 색 입힌 인용 괄호, 입력 이벤트를 CodeMirror에서 보여 준 것과 같은 종류의 facet 메커니즘을 통해 병합한다.
이제 장식은 텍스트 위에 그려지지만, 어떤 읽기 증강은 텍스트 옆에 살아야 한다. 문서 내 위치에 정박하되, 텍스트 흐름 바깥에 렌더링되어야 한다. 그래서 여기 Margin Notes 플러그인이 있다. 나는 텍스트의 어떤 지점이든 가리켜 여백 메모를 만들 수 있다. 이 여백 메모는 대상 문단의 수직 위치와 페이지 오른쪽 가장자리에 정박된다. 이 확장은 그 위치를 계산하지 않는다. 그냥 "나는 이 의미적 위치에 정박된 위젯을 원한다"고 선언할 뿐이고, 시스템이 나머지를 처리한다.
이제 다른 플러그인을 켤 수 있다. 여기 Papeos가 있다. 이 플러그인은 논문의 섹션과 저자의 해당 학회 발표 순간을 연결한다. 이것도 같은 선언적 방식으로 위치가 정해지는 정박 위젯을 선언한다. 하지만 Papeos는 내 Margin Notes 플러그인에 대해 아무것도 모른다. 단지 둘 다 같은 정박 facet에 기여하기 때문에, 시스템이 이 위젯들이 겹치지 않도록 보장할 뿐이다. 같은 정박 원시 요소는 여백 메모를 넘어서도 지원할 수 있다. 떠다니는 툴바, 맥락 패널, 확장이 문서 위치 옆에 두고 싶어 하는 어떤 것이든 가능하다.
지금까지 우리는 문서 자체는 그대로 둔 채 정보를 추가하는 확장, 즉 텍스트 위의 색과 옆의 위젯을 보았다. 가장 흥미로운 읽기 증강 가운데 일부는 콘텐츠가 렌더링되는 방식을 바꾼다. 여기 LiquidText를 변주한 것이 있다. 내가 명령 키를 누른 채 스크롤하면, 논문의 섹션들을 공간적으로 압축해서 콘텐츠를 서로 밀착시킬 수 있다. 접힌 영역 안에서 수사적 색들이 일종의 시각적 지문처럼 압축되는 점에 주목해 보라.
장식은 문서 기하의 변화와 조합되는 프래그먼트 셰이더 같은 것으로 생각할 수 있다. 문서 기하는 그래픽스 파이프라인의 버텍스 셰이더 같은 셈이다. 이것은 공간 변환이다. 화면 위에서 콘텐츠가 나타나는 위치를 바꾼다. 그런데 정박 위젯에서 무슨 일이 일어나는지 보라. 이 정박 위젯들은 LiquidText 플러그인에 대해 아무것도 모른다. 그들은 단지 레이아웃 맵에 "지금 내 정박점은 어디에 있지?"라고 묻는다. 그리고 레이아웃 맵은 그 공간 변환을 반영한다. 위젯들은 문서가 다시 형성되었다는 사실을 모르지만, 기하를 따라 움직인다.
이 아키텍처는 무엇을 보여줄지와 어디에 보여줄지를 깔끔하게 분리하기 때문에, 같은 문서를 여러 방식으로 여러 번 렌더링할 수 있다. 이 미니맵은 메인 뷰와 같은 decoration facet, 즉 수사적 색과 인용 표식을 읽지만, 그것들을 압축된 개요 안에 렌더링한다. 개념적으로는 같은 파이프라인의 두 번째 렌더 패스와 비슷하다.
조합 가능한 아키텍처와 코딩 에이전트의 결합은, 우리가 가장 복잡한 앱들을 둘러싼 사일로를 허무는 데 도움을 줄지 모른다. 하지만 나는 우리가 이미 가진 발칸화된 인터페이스 아이디어들을 그저 결합하는 데 만족하지 않는다. 나는 거칠게 넘실대는 새 아이디어의 흐름을 원한다.
나는 우리가 동적 매체로 할 수 있는 일의 표면만 간신히 긁었을 뿐이라고 생각한다. 기술 산업의 그 모든 광적인 에너지와 권위 있는 HCI 학회들에도 불구하고, 사용자 인터페이스에서 의미 있는 발명의 속도는 놀라울 만큼 느리고, 상상력의 수준도 놀라울 만큼 온순하다. 나는 새로운 답, 새로운 질문, 가능하다면 그 둘을 동시에 원한다.
개인용 컴퓨터 초기에는 변혁적 사용자 인터페이스를 분야를 넘나드는 괴짜들이 발명했다. Engelbart, Sutherland, Kay, Simonyi, Atkinson 같은 사람들이다. 당시에는 무언가를 만드는 일 자체가 너무 어려웠기 때문에 그들은 과학 분야의 박사들이었지만, 동시에 대담한 상상력을 지닌 디자이너이기도 했다.
소프트웨어 산업은 다재다능한 천재들의 공급보다 훨씬 빨리 성장했다. 그래서 1980년대쯤이 되자, 대부분의 프로그래머들은 자기 마음대로 두면 기술 용어로 가득 찬, 사용자를 노골적으로 적대하는 소프트웨어를 만들고 있었다. 그래서 그의 기념비적 저서 The Inmates Are Running the Asylum에서 Alan Cooper는 프로그래머와 함께 일하며 사용자 요구와 능력에 더 잘 맞는 소프트웨어를 만드는 새로운 역할, 즉 인터랙션 디자이너를 제안했다. 전문화는 효과가 있었다. 현대의 대부분 소프트웨어는 실제로 사용자 요구를 이해하려 강하게 노력하며, 이제 인터페이스 디자인 패턴과 관행이 발전했기 때문에 많은 프로그래머도 혼자서 견딜 만한 인터페이스를 만들 수 있다.
하지만 나는 지금도 여전히 수감자들이 정신병원을 운영하고 있다고 말하고 싶다. Cooper는 프로그래머가 사람들에게 우스꽝스러울 만큼 형편없는 사용자 인터페이스를 강요하는 우연한 폭정을 걱정했다. 나는 프로그래머가 사용자 인터페이스에서 상상력을 억누르는 우연한 폭정을 걱정한다.
나는 기이하고, 용감하고, 개성적이고, 낯선 인터페이스를 원한다. 우리는 기계 지능의 놀라운 도래를 지나고 있고, 그것은 충분히 낯설다. 그런데도 우리는 그 모든 힘을 내가 십 대 때 쓰던 IRC 클라이언트 이후 거의 진화하지 않은 채팅 인터페이스에 욱여넣어 왔다. 발명은 어디에 있는가?
나는 핵심 문제가 동적 매체에서의 발명이 지나치게 많은 프로그래밍을 요구한다는 데 있다고 생각한다. 새로운 사용자 인터페이스를 발명하려면 상상력 있는 설계 능력 그리고 능숙한 기술 능력이 둘 다 필요하다. 둘 다 가진 사람은 매우 적다. 더 나쁜 것은, 대개 그 둘만으로도 충분하지 않다는 점이다. 인터페이스 발명에는 깊은 도메인 통찰도 필요하다. 나는 Steinberg가 수년간 음악가이자 프로듀서로 일한 뒤 Cubase의 타임라인 에디터를 발명한 사례, 혹은 Harvard Business School에 있던 Bricklin이 동적 스프레드시트를 발명한 사례를 떠올린다.
당신은 과감한 새 사용자 인터페이스가 주로 상상력 있는 디자인 작업과 깊은 도메인 통찰에 의해 병목된다고 짐작할 수 있다. 그렇다면 문화 속에서 그런 기술이 가장 강조되리라 기대할 수도 있다. 하지만 인터페이스 발명 주변의 커뮤니티 행사들, 즉 개인용 컴퓨터의 미래나 학술 HCI를 방문해 보면, 거의 모두가 훈련 배경상 프로그래머이고 문화적으로도 프로그래머라는 것을 금세 알게 된다. 대부분은 디자인 스쿨의 광기 어린 스튜디오가 아니라 형식적이고 분석적인 과학 프로그램에서 공부했을 것이다. 우연히도, 거기에는 나도 포함된다.
나는 우리가 이런 상황에 있는 이유가 이 기술들 사이의 깊은 비대칭성 때문이라고 생각한다. 디자인이나 도메인 통찰 없이도 프로그래밍은 작동하는 인터페이스를 낳을 수 있다. 종종 지루하거나 결함이 있긴 해도 말이다. 반면 프로그래밍 없는 디자인이나 도메인 통찰은 도면판 위에 멈춰 버린다. 그래서 적어도 개인 발명에서는, 대체로 모든 작동하는 인터페이스는 다른 기술을 가졌을 수도 있고 아닐 수도 있는 프로그래머들에 의해 만들어진다. 새 인터페이스가 주로 상상력 있는 디자인 작업과 깊은 도메인 통찰에 의해 병목된다면, 이 비대칭은 잘못된 기술들에 선택 압력을 가한다.
내가 인터페이스 발명의 느린 속도를 불평하면, 사람들은 종종 이것이 사실 시장의 문제라고 말한다. 소비자는 기이한 인터페이스보다 쉽고 익숙한 인터페이스에 보상을 주고, 그것은 수익성 있고 상업화되고 전문화된 산업이 되었다는 것이다. 하지만 컴퓨팅의 미래를 다루는 모임과 HCI 학회는 그런 것에 관심 없고 자기만의 공중누각을 짓고 싶어 하는 사람들로 가득하다. 다만 사랑을 담아, 그리고 내가 그 장면의 일부로서 말하자면, 결과물은 종종 시원찮다. 나는 그 이유가 이 장면이 프로그래밍 쪽으로 지나치게 무겁고, 도메인 통찰과 디자인 쪽으로는 지나치게 가볍기 때문이라고 생각한다.
이제, 개인 발명이 잘못된 기술을 선별한다면, 팀으로 발명하는 것은 어떨까? Cooper는 전문화를 통해 이 문제에서 벗어날 수 있다고 생각했다. 프로그래머가 디자이너와 함께 일하면, 그들 가운데 하나나 제품 관리자가 도메인 통찰도 갖게 될지 모른다. 이 방식은 대부분의 소프트웨어에서는 꽤 괜찮게 작동했다. 대부분의 소프트웨어는 그저 변주일 뿐이고, 전문가들이 잘 알려진 패턴을 적용하는 일이다. 오히려 새로움은 방해가 될 것이다. 하지만 내가 말하고 싶은 것은 발명이며, 거기에서는 전문화가 훨씬 덜 잘 작동했다고 생각한다.
팀은 기본적으로 비프로그래머를 의존의 위치에 놓는다. 디자이너가 새로운 인터페이스를 발명하고 싶다면, 보통 다른 사람을 설득해 도와달라고 하지 않고는 작동하는 프로토타입을 만들 수 없다. 게다가 그 설득도 어렵다. 디자이너는 가짜 같은 것을 보여 주고, 빈칸은 동료들의 상상력에 기대어 메워야 한다. 프로그래밍 능력이 조금 있는 디자이너의 경우에도, 프로토타이핑은 여전히 너무 느리고 어려워 기회비용을 정당화하기 힘든 경우가 많다. 나는 이런 상태에 수년간 갇힌 디자이너들을 보아 왔다. 그들은 흔히 머릿속의 어떤 개념을 언급하지만, 다른 사람들이 이해할 수 있는 형태로 그것을 실현해 본 적은 없다.
이 문제는 디자이너가 늘 훌륭한 아이디어를 제안하는데 근시안적인 동료들이 그걸 번번이 거절한다는 뜻으로 들릴 수도 있다. 하지만 나는 더 깊은 문제는 이런 역학이 그 아이디어들이 애초에 훌륭해지지 못하게 만든다는 데 있다고 생각한다. 실제로 작동하는 버전을 사용하고 반복적으로 다듬어 보지도 않은 채, 사람들이 새로운 인터페이스에 대한 훌륭한 아이디어를 발전시키고 제안할 수 있으리라고 왜 기대해야 할까?
비프로그래머 디자이너들은 의미 있게 상호작용하는 무언가를 만들 수 없는 상태에서 상호작용적 매체 안의 무언가를 발명하려 한다. 발명의 많은 부분은 재료와의 친밀함, 촘촘한 피드백, 섬세한 관찰, 진정한 사용에 달려 있다. 그래서 이것은 딜레마다. 비프로그래머가 자기 매체와 제대로 대화하려면, 프로그래머의 도움을 받아야 한다. 그런데 그러려면 대개 그 아이디어가 어느 정도는 읽히고 설득력 있어야 한다. 하지만 정말 새로운 것을 하고 있다면, 그들은 자기 매체와 가까이 대화하기 전에는 그 아이디어를 읽히고 설득력 있게 만들 수 없는 경우가 많다.
현대 소프트웨어 디자인 문화는 종종 새로운 동적 표현이나 상호작용보다 시각적 장인정신으로 향한다. 나는 그 이유가 시각이야말로 디자이너가 자신의 아이디어를 발전시키기 위해 다른 사람에게 의존해야 하는 좌절 없이, 직관적으로 만지작거릴 수 있는 영역이기 때문이라고 생각한다. 이것은 어쩌면 소외된 프로그래머가 코드가 정말 깔끔한지에 과도하게 집착하는 것의 디자인판과 비슷하다. 각 실천은 적절한 양에서는 좋고 필요하다. 하지만 쉽게 매체의 진짜 잠재력으로부터 자신을 보호하기 위한 후퇴가 될 수 있다.
이것은 프로그래머에게도 좋지 않은 상황이다. 그들은 의도치 않은 문지기가 된다. 나는 동료들과 함께 이런 위치에 있었던 적이 있다. 그들이 자기 아이디어를 설명하면 나는 질문하고 즉흥적으로 변주를 던지지만, 그래도 그들이 보는 것을 나는 잘 보지 못한다. 여기서 내게는 두 가지 나쁜 선택지가 있다. 사양할 수 있는데, 그러면 종종 사실상 내 팀원의 길을 막게 된다. 아니면 수긍할 수 있는데, 그러면 옳든 그르든 내가 이미 다루고 있는 것들보다 덜 유망해 보이는 아이디어에 내 우선순위를 종속시키게 된다. 이런 상황에서 내가 제너럴리스트라는 사실은 나를 더 폭군적으로 만든다. 왜냐하면 나는 언제나 내가 발전시킬 수 있는 내 디자인 아이디어들을 이미 갖고 있기 때문이다.
하지만 이제 나는 벽에 균열이 생긴 것을 본다. 나는 코딩 에이전트가 인터페이스 발명에서 프로그래머의 우연한 폭정을 끝낼 것이라고 생각한다. 디자이너와 도메인 전문가들은 발명의 초기 단계에서 프로그래머에 대한 의존으로부터 점점 자유로워질 것이라고 생각한다. 마침내 그들은 동적 매체를 직접 손에 쥐게 될 것이다. 개념을 직접 반복하고 프로토타이핑할 수 있게 될 것이다.
나는 그것을 직접 보아 왔다. 나는 2025년 동안 재능 있는 두 디자이너와 협업했다. 지난 한 해 동안 코딩 에이전트와 함께한 그들의 이야기는 정말 엄청났다. 협업자들에게 미친 영향은, 내가 이제 아마 열 배쯤 빠르게 만들고 있다는 사실에도 불구하고, 나에게 미친 영향보다 훨씬 더 큰 것 같다.
나와 달리 이 둘은 디자인 분야에서 커리어를 시작했고, 형성기 시절을 예술 문화 속에서 보냈다. 그들도 조금은 프로그래밍할 수 있지만, 그 과정은 상당한 장벽이 될 만큼 정말 느리고 어려웠다. 2025년 초만 해도 코딩 모델은 작은 일회성 디자인 아이디어를 구현할 수는 있었지만, 몇 번만 반복해도 결과물이 그냥 무너졌다. 연말이 되자 내 협업자들은 새로운 인터페이스 아이디어를 일상적으로 프로토타이핑하고, 그 반복을 몇 주씩 지속하고 있었다.
나는 아침에 메시지를 확인하다가, 한밤의 몰입 속 꿈에서 압축되어 나온 놀라울 만큼 정교한 프로토타입을 발견하곤 했다. 예를 들어, 그해 대부분 동안 우리의 인터페이스 스케치는 이국적인 상호작용 콘텐츠 레이아웃 시스템을 가리키고 있었다. 그것은 크고 무서운 프로젝트처럼 보여서 구체화하기를 망설이고 있었다. 그런데 어느 날 아침 일어나 보니 작동하는 구현이 와 있었다. 디자이너 한 명과 코딩 에이전트 군단이 밤새 함께 그것을 해결해 낸 것이다. 바로 같은 주에, 다른 디자이너가 동적 3D 데이터 시각화의 연필 스케치를 우리 시스템의 실제 데이터를 바탕으로 돌아가는 매혹적인 프로토타입으로 바꾸는 장면을 나는 놀라움 속에 지켜봤다.
이 흐름은 우리의 협업 성격을 완전히 바꾸어 놓았다. 연초에는 협업자들이 자기 아이디어를 진지하게 사용할 수 있을 만큼 충분한 충실도로 프로토타입하려면 대부분 나를 거쳐야 했다. 세 명이 디자인하고 한 명이 프로그래밍하는 상황에서는, 돌아갈 프로그래밍이 충분하지 않았다. 그것은 나를 문지기로 만들고 동료들을 영업사원으로 만든다. 하지만 이제는 점점 그들이 자기 아이디어와 프로토타입을 직접 만지작거릴 수 있게 되었다. 몇 번은 협업자들이 한 아이디어를 프로토타입했는데, 나는 그것을 보며 이렇게 느꼈다. 세상에, 네가 한동안 이걸 가리키고 있었는데, 나는 이해하지 못했구나. 하지만 이제는 내가 이해할 필요가 없다. 나는 그들의 초기 표현과 반복을 막지 않는다.
앞서 설명했듯이, 이 이야기는 단지 내가 아름다운 초기 아이디어를 알아보기에 너무 둔감해서만은 아니다. 종종 디자이너는 자기 손에 쥐고 만져 보기 전에는 자기 자신의 어렴풋한 감각조차 제대로 이해하지 못한다. 코딩 에이전트는 아이디어가 아직 일관되지 않을 때 만지작거릴 수 있는 안전한 공간을 만들었다. 예전의 역학은 처음부터 명료함과 가독성을 요구했다.
나는 Ted Nelson의 이야기가 이 세계에서는 얼마나 달라졌을지 궁금하다. 그는 모든 글 조각이 다른 모든 것과 살아 있는 네트워크 속에 존재하는, 웹의 평행우주 버전을 50년 동안 추구했다. 그에게는 내가 이 장면에서 보고 싶어 하는 그 거친 상상력이 있었다. 하지만 그는 자기 아이디어를 프로토타입할 기술 능력이 없었다. 그래서 그에 대해 통째로 책을 쓰며, 그런 시스템들이 주는 실제 피드백 없이 개념을 점점 더 밀어붙였다. 결국 그는 자기 아이디어를 직접 경험하는 데 필요한 지지를 얻기 위해 평생 싸운 끝에, 그 일부를 구현하게 만들었다. 그런데 그것들은 광고된 것만큼 강력하거나 설득력 있지 않았다. 그건 놀라운 일이 아니다. 우리는 그를 탓해서는 안 된다. 발명은 반복을 필요로 한다. 매체와의 접촉을 필요로 한다. 그런데 그는 वास्तव로 그런 기회를 갖지 못했다. 오늘날의 디자이너들은 점점 그 기회를 갖게 되고 있다.
그것은 분명 그들에게 어린아이 같은 기쁨의 원천이다. 내 협업자 가운데 한 명인 Nio Ono는 자신의 경험에 대해 이렇게 말했다.
Vibe coding unlocked something in my mind or latent personality matrix. I am reminded of descriptions by people who feel they were fundamentally changed by martial arts or some esoteric practice, like something inside of me realigned and connected me to an inner conduit of energy that had lain dormant. … I feel unleashed in a way that changes my sense of self. There is an unambiguous before and after. … I feel free to act! To express myself! … 'I feel the body electric' is as perfect a summation of this feeling as anything.
내가 아는 모든 디자이너는 제대로 시도해 볼 만큼의 지지를 얻지 못한 채 아름다운 아이디어에 오랫동안 사로잡혀 있었다. 이제 그들은 그냥 시도해 볼 수 있다.
기술 세계는 코딩 에이전트에 대한 소음으로 넘쳐난다. 어떤 이들은 말한다. 컴퓨터과학 학부생들은 끝장났고, "아이디어형 인간"들이 혼자서 모든 것을 만들고 출시하게 될 것이라고! 또 다른 이들은 말한다. 그건 과대광고일 뿐이며, vibe-coded 소프트웨어는 보기에는 좋지만 진지하게 쓰려 하면 무너진다고.
어쨌든. 내가 원하는 것은 사용자 인터페이스 안에서 더 많은 상상력과 발명이다. 그리고 그 목적을 위해서는, 비프로그래머가 자기 프로토타입을 끝까지 제품화하지 못하더라도, 코딩 에이전트가 엄청난 차이를 만들어 낼 수 있다. 여기서의 병목은 우리가 늘 놀라운 새 사용자 인터페이스 프로토타입과 연구 시스템을 보고 있는데도 어리석은 시장이 그것들을 실제 제품으로 가져오지 않는 데 있지 않다. 나는 깔때기 맨 위로 흘러 들어오는 상상력의 유량을 늘리고 싶다.
그 초기 단계는 소프트웨어 품질에 대한 압박이 덜하다. 프로토타입은 디자이너가 자신의 아이디어가 진짜 맥락에서 어떻게 펼쳐지는지 느끼고, 다른 사람에게 분명히 전달할 수 있을 정도로만 충분히 실제적이면 된다. 코딩 에이전트는 이미 어떤 아이디어들에 대해서는 그 수준의 프로토타입을 만들어 내기에 충분히 좋다.
그리고 일단 팀이 꾸려지면, 고충실도 프로토타입은 지금 대부분의 디자이너가 사용하는 것보다 동적 매체에 관한 아이디어를 훨씬 더 효과적으로 전달한다. 정적인 아트보드와 클릭형 데모와 달리, 이런 프로토타입은 새로운 동적 동작을 분명하게 명시할 수 있다. Bas Ording은 Macromedia Director 프로토타입과 급조한 스크립트를 사용해 iOS의 관성 스크롤과 고무줄 효과를 발명했다. 그 코드들 가운데 실제 출시된 것은 하나도 없었고, 그게 무슨 상관인가? 그것은 한 세대의 컴퓨팅에 본질적인 감각을 정의했다.
지난해의 흐름이 이어진다면, 이런 기술적 과제들은 오래 걱정하지 않아도 될 것이다. 사실 나는 미학적, 인지적 과제가 훨씬 더 걱정된다. 코딩 에이전트와 하루 종일 일하면 내 주의는 조각나고, 초점이 흐려지고, 충동적으로 변한다. 나는 기다리느라 바쁘다. 워크스페이스 탭 사이를 끊임없이 오가고, 작업 기억을 비웠다가 다시 구성한다. 빠르게 움직이고는 있지만, 결코 몰입 상태에 있지 않다.
내 협업자 Nio는 그 느낌에 대해 앞선 인용과 강렬한 대비를 이루는 또 다른 말을 공유했다.
I live in an eternal present. No memory, no plan. Every minute my attention lunges at something else. It's hard to recount what even happened these last few months. For all this activity, I feel bereft of outcomes or memories. I feel disembodied, so my embodied life is in disrepair. My home is my screen, so my living space is dusty and incomplete. I feel robbed of agency. I can scarcely recognize my own goals, let alone act on them. It's like forgetting a past life. The world feels like a blurry backdrop for my screens. It's all desktop wallpaper.
손으로 무언가를 만드는 데는 깊은 즐거움이 있는데, 여기에서는 그것이 불안하고 산만하며 광적인 에너지 같은 것으로 대체된다. 만드는 일이 너무 쉬워져서 이제는 오히려 묘하게 위험한 유혹이 되었다. 나와 내 협업자들은 모두 신중하게 문제를 생각하는 일을 피하는 방식으로, 무심코 에이전트와 공을 주고받는 자신을 발견하곤 했다.
이 비용들은 वास्तविक하다. 하지만 지금 우리는 그것을 감수한다. 코딩 에이전트가 발명에 엄청나게 좋은 소식이기 때문이다. 경험 많은 프로그래머인 나조차도 속도가 너무 빨라져서, 1년 전에는 시도조차 하지 않았을 온갖 아이디어를 시험해 보고 있다. 하지만 나는 내 자신의 실천에 대해 불편한 질문들과 씨름하고 있다.
나는 인생의 3분의 2가 넘는 시간을 프로그래밍하며 보냈고, 발명적 디자인 작업을 한 시간은 그보다 조금 넘는 3분의 1 정도다. 내가 여전히 발명가보다는 기술자로서 훨씬 더 강한 사람이란 것이 놀라운 일은 아닐 것이다. 후자의 역할에서 내가 거둔 소박한 성공은, 내 상상력의 범위 때문이라기보다 범용적인 기술 조합 덕분이었던 것 같다. 디자이너-프로그래머는 그냥 꽤 드물고, 그게 내게 꽤 독특한 이점을 주었다. 하지만 나는, 아니 오히려 바라건대, 이 이점은 앞으로 몇 년 안에 그냥 사라질 것 같다. 그러면 나와 나 같은 사람들은 어디에 놓이게 될까?
솔직히 말하면, 나는 내가 가장 존경하는 디자이너들만큼 상상력이 풍부하다고 생각하지 않는다. 시각적 표현에 대한 내 표현 범위는 훨씬 좁고, 인터페이스 아이디어를 렌더링하고 반복하는 속도도 훨씬 느리다. 하지만 내가 인터페이스 발명 장면이 프로그래밍 쪽으로 무겁고 디자인 쪽으로 가볍다고 말할 때 뜻하는 것은 그것만이 아니다.
내가 말하는 "디자인"에는 직업적 실천보다 더 넓은 것이 포함된다. 대담한 상상력과 영감을 받은 창조적 에너지다. 그런 에너지를 가진 프로그래머도 많지만, 프로그래밍 문화가 주입하고 보상하는 것의 상당 부분은 더 분석적이고 실용적이다. 프로그래머로 살아온 수십 년은 내게 형식주의적 사고방식을 심어 주었고, 그것은 광기 어린 생성성을 거스르는 방향으로 작용하는 것 같다. 내 마음은 자동으로 추상화와 일반화 쪽으로 움직인다. 체계화할 때는 그것이 초능력이다. 나는 모호하고 덜 정의된 아이디어를 받아서 그것이 실제로 일관되게 작동하게 해 주는 질문을 던질 수 있다. 하지만 그것은 정말 초기의 아이디어들에 너무 많은 압력을 가한다. 나는 디자이너 친구들 가운데 일부가 벽에 스파게티를 던지듯 매력적인 아이디어를 이리저리 만지작거리면서, 그것이 함의하는 형식적 규칙을 걱정하지 않는 방식을 부러워한다.
그래서 이제 무엇을 할 것인가? 우리는 수십 년 동안 주로 디자인 선택 과목이 있는 컴퓨터과학 학과처럼 보이는 HCI 프로그램을 만들어 왔다. 하지만 발명이 기술 전문성보다 상상력에 더 많이 병목되는 세계로 가고 있다면, 우리는 방향을 거꾸로 잡았을 수 있다. 우리는 기술 선택 과목이 있는 미술학교에 조금 더 가까운 프로그램이 필요할지도 모른다. 아이디어를 정확히 표현하기 전에 직관에서 발전시키는 법, 재료를 가지고 놀며 발견하는 법을 배우는 곳 말이다.
그리고 프로그래밍 문화 속에서 자라난 나 자신과 이 장면의 다른 사람들에게는 어떤가? 우리는 어떻게 적응하고 성장해야 할까? 기술적 유창함은 필연적으로 어린아이 같은 상상력의 발목을 잡는가? 나는 역사 속 위대한 과학자들과 컴퓨팅의 창립자들, Feynman이나 Kay 같은 인물들에게서 약간의 위안을 얻는다. 그들의 이야기는 분명 이런 능력들이 공존할 수 있을 뿐 아니라 실제로 서로를 증폭시킬 수도 있음을 시사하는 것처럼 보인다. 그래서 내 질문은 더 절박해진다. 프로그래밍 문화 출신인 우리 자신 안에서 그런 종류의 공명을 더 잘 길러 내려면 어떻게 해야 할까?
