사용자가 직접 바꾸는 소프트웨어: 잠긴 앱에서 주도권 되찾기

AI 요약

Ink & Switch는 디지털 환경도 물리적 작업 공간처럼 사용자가 필요에 맞게 바꿀 수 있어야 한다고 주장합니다. 종이 카드로 업무를 관리하던 팀은 벽에 테이프를 붙이고 카드 구역을 바꾸며 업무 절차를 빠르게 실험했습니다. 웹 기반 이슈 트래커로 옮긴 뒤에는 같은 변경에 설정을 손보거나 개발팀을 기다려야 했고, 일부 업무 방식은 사라졌습니다. 저자들은 사용자가 도구를 필요에 맞게 직접 고치고 서로 나눠 쓰는 소프트웨어 생태계를 ‘malleable software’라고 부릅니다. 여기서 말하는 수정은 설정을 조금 바꾸는 일부터 새 도구를 만들고 기존 도구와 연결하는 일까지 포함합니다.

기존 확장 방식의 한계

설정은 개발자가 미리 준비한 선택지만 제공합니다. 플러그인은 앱이 허용한 확장 지점 밖으로 나가기 어렵고, 설치와 제작 사이에도 큰 기술 장벽이 있습니다. 비공식 모드는 더 넓은 변경을 허용하지만, 역공학과 유지보수가 필요하고 다른 모드와 충돌하기도 합니다. 오픈소스 역시 코드를 공개한다고 해서 누구나 쉽게 고칠 수 있는 것은 아닙니다. 작은 수정에도 개발 환경을 꾸리고 코드 구조를 파악해야 합니다.

AI 코딩 도구도 이 문제를 혼자 해결하지는 못합니다. 자연어로 새 앱을 만드는 기능만으로는 이미 설치한 도구를 수정하거나, 생성한 도구를 기존 데이터와 작업 흐름에 연결하기 어렵습니다. 저자들은 AI가 만든 코드를 활용하려면 사용자가 도구를 직접 다루고 조합하는 환경이 먼저 필요하다고 봅니다.

사용에서 제작까지 완만한 경사

사용자가 도구를 쓰다가 필요에 따라 조금씩 더 깊게 수정하도록 학습 장벽을 낮춰야 합니다. 연구자 MacLean 등이 제안한 ‘gentle slope’는 수정 능력이 한 단계 커질 때 필요한 기술도 조금씩 늘어나는 설계 원칙입니다. 스프레드시트는 셀을 입력하는 데서 시작해 서식과 수식을 바꾸고 새 기능을 더하는 단계로 이어지는 사례입니다. HyperCard는 읽기 전용부터 텍스트·그래픽 편집, 버튼 제작, HyperTalk 프로그래밍까지 단계별 모드를 제공했습니다. 모든 사용자가 프로그래밍까지 배울 필요는 없으며, 큰 수정은 숙련자와 협력하는 방법도 포함해야 합니다.

앱 대신 조합 가능한 도구

저자들은 특정 작업만 하는 앱을 아보카도 슬라이서에 비유합니다. 하나의 좁은 용도에 맞춘 앱을 계속 늘리면 기능은 중복되고, 여러 앱을 오가며 데이터를 복사해야 합니다. 칼처럼 여러 작업에 쓸 수 있는 도구를 만들려면 도구끼리 데이터를 공유하고, 같은 작업 공간에서 함께 동작해야 합니다. 파일 시스템은 여러 프로그램이 같은 파일을 편집하는 사례입니다. Airtable이나 Notion 같은 도구는 한 데이터베이스를 표, 카드 보드, 달력 등으로 다르게 보여줍니다. 데이터 형식이 도구마다 달라지면 연결이 어려워지고, 앱이 각자 화면을 독점하면 여러 도구를 함께 쓰기 불편합니다. 따라서 공유 데이터뿐 아니라 도구를 한 화면 안에서 조합하는 방식도 필요합니다.

개인의 수정에서 공동 제작으로

맞춤 도구를 사용자마다 따로 만들면 비용과 유지보수 부담이 커집니다. 병원 부서나 제품팀처럼 같은 문제를 겪는 공동체가 함께 도구를 만들고 관리할 수 있어야 합니다. 저자들은 지역 사용자와 가까운 개발자가 대응하는 소규모 소프트웨어는 전 세계 모든 요구를 한꺼번에 해결하는 제품과 다른 방식으로 발전할 수 있다고 설명합니다. 기술만으로는 충분하지 않으며, 보안과 프라이버시, 개발자 수익 모델, 수정과 공유를 장려하는 문화도 과제로 남습니다.

Ink & Switch의 프로토타입

PushPin은 React UI 컴포넌트와 JSON 문서를 연결하고, Automerge로 데이터를 저장·동기화하는 협업 미디어 캔버스입니다. UI와 데이터를 분리해 같은 문서에 다른 편집기를 붙이는 실험을 했지만, 문맥에 따라 어떤 화면을 보여줄지 정하거나 컴포넌트 사이의 상태를 공유하는 문제는 남았습니다. Cambria는 도구마다 다른 데이터 구조를 실시간으로 변환하는 방법을 탐구했습니다. Farm은 사용자 데이터뿐 아니라 소프트웨어 코드도 데이터처럼 저장했고, Patchwork는 Automerge 문서에 코드와 데이터를 함께 두며 기록 보기와 간단한 분기 기능을 더했습니다.

Patchwork에서 저자들은 글의 분량을 확인할 Section Word Counter를 몇 분 만에 만들고, 문서에 연결해 함께 사용했습니다. 도구는 링크로 공유할 수 있어 협업자가 필요한 것만 설치할 수 있었습니다. AI는 이런 수정 환경과 결합했을 때 작은 도구를 빠르게 만드는 데 도움이 됐습니다. 다만 코드 분기와 협업 규칙, 도구 품질을 사용자에게 알리는 방법, 여러 도구를 한 화면에 배치하는 방식은 계속 연구해야 합니다.

Potluck은 자유 형식 텍스트에서 레시피 정보를 찾아 재료 양을 조절하거나 타이머를 설정하는 실험이었고, 구조를 파악하는 규칙이 복잡해지는 문제가 있었습니다. Embark는 여행 계획을 계층형 개요로 표현하고 지도와 달력을 문서에 삽입했습니다. 지도에서 장소를 가리키면 개요에서도 해당 항목이 강조되는 등 주변 문맥을 공유하는 상호작용을 구현했습니다. 저자들은 자유로운 표현과 도구가 처리하기 좋은 구조화된 데이터 사이의 균형을 과제로 꼽습니다.

Hacker News 반응

• @dmdiefjeidnn — 컴퓨터를 수십 년간 써 왔지만 소프트웨어를 ‘유연하게 바꿀 수 있다’고 느낀 적은 없습니다. 예전에는 프로그램을 직접 입력해야 했지만, 그건 유연성을 추구해서가 아니라 소프트웨어를 배포할 방법이 그랬기 때문입니다. 컴퓨터 환경이 나아질 수는 있어도, 예전이 더 좋았다는 식으로 사용자 주도권을 말하는 건 미화라고 봅니다.
  • @mickael-kerjean — 기능을 계속 추가하다 소프트웨어가 비대해지는 일을 막는 데 유연성이 도움이 됩니다. 회사 하나가 요청한 기능을 넣느라 대다수 사용자가 원하지 않는 기능까지 추가할 필요가 없습니다. 저는 Filestash 오픈소스 프로젝트에서 플러그인을 WebAssembly 런타임으로 실행해 권한을 제한했습니다. 플러그인 코드 양은 핵심 기능의 열 배가 넘습니다.
• @myaccountonhn — 저는 Emacs를 원하는 대로 고쳐 쓰고 주도권을 갖고 있습니다. 이 글의 설명대로라면 저는 존재하지 않는 셈입니다.
  • @ididjsjdjwj — 그건 타당한 반박이 아닙니다. Emacs는 유연하게 바꾸는 것을 목적으로 만든 프로그램입니다. 모든 소프트웨어가 그래야 하는 것은 아니며, 과거 소프트웨어가 기본적으로 그런 방식도 아니었습니다.
• @josephg — 소프트웨어는 API, 연동 기능, 확장, 플러그인, 호환 형식 등 여러 방식으로 이미 바꿀 수 있지만 모두 각자 예외적인 구현입니다. 프로그램마다 PSD 파서를 따로 만들어야 하고, 두 앱의 데이터를 양방향으로 동기화하려면 여러 상황에서 깨지는 스크립트를 짜야 합니다. 이런 문제를 해결한다는 생각이 마음에 듭니다.
• @apatheticonion — 대기업과 소프트웨어 업체가 제3자 클라이언트를 허용하도록 규제해야 한다고 봅니다. 유튜브나 여러 메신저를 더 잘 이용할 클라이언트를 직접 만들고 싶습니다. 하드웨어 업체도 문서화된 드라이버를 지원해야 합니다. 그래야 맥북에 Linux를 설치하거나 TV의 기본 펌웨어를 바꾸고, 서비스 데이터를 다른 기기로 옮길 수 있습니다.
  • @chii — 이런 자유를 위해 오픈소스 배포에는 Copyleft와 GPLv3가 우선되어야 합니다.
  • @Terr_ — 그 주장을 과장하지 말아야 합니다. GPL과 Copyleft는 바이너리를 배포할 때 소스도 공개하게 할 뿐입니다. 기업이 서버에서 중요한 기능을 돌리고 클라이언트에 단순한 암호화와 저작권 콘텐츠를 더하면 소스 공개를 피할 수 있습니다. 사용자 제작 클라이언트를 만들거나 제작 방법을 문서화해도 법적 처벌을 받을 수 있습니다.
• @jongjong — 어머니와 Google Meet 화면 공유를 하는 데 20분 넘게 걸렸습니다. 아이패드에서 링크를 눌렀더니 Safari가 열렸고, Safari에서는 화면 공유가 안 됐습니다. Chrome을 설치한 뒤 주소를 복사하려 했지만 Safari 주소창에서 복사할 수 없었습니다. 결국 제가 URL과 회의 ID를 읽어 주고 어머니가 직접 입력했습니다. 운영체제와 앱이 파일 경로나 웹 주소를 확인하고 복사하는 일을 어렵게 만드는 점이 답답합니다. 요즘은 이런 웹 앱을 쓰게 되면 Chrome 개발자 도구를 열어 HTML을 직접 확인합니다.
• @rsavage — 많은 회사가 스프레드시트를 대체하려고 소프트웨어를 만들지만, 스프레드시트가 좋은 이유는 원하는 대로 쓸 수 있기 때문입니다. 고객마다 필요한 기능을 계속 추가하면 제품이 엉망이 됩니다. 고객이 직접 기능을 고치게 하면 공통 데이터와 기반 기능은 유지하면서 각자 필요한 기능을 쓸 수 있을지 궁금합니다.
  • @mickael-kerjean — Filestash에서 비슷한 방식을 적용하고 있습니다. 수백만 명의 사용자 가운데 대부분은 유연성에 큰 관심이 없어 보입니다. 하지만 유럽의 특정 규정을 위해 로그에 인증 서명을 붙여야 하는 등, 극소수 고객만 필요한 요구가 생길 때 유용합니다.
  • @Ouman — 스프레드시트에서 얻을 교훈은 사용자화가 부가 기능이 아니라 제품 자체일 수 있다는 점입니다.
• @sim04ful — 저는 화면에 정보를 보여주는 방식은 일시적인 층이라고 생각합니다. 데이터 표현과 저장 방식이 그보다 중요합니다.
• @Ouman — 컴퓨터가 제품이라기보다 환경처럼 느껴지던 시절이 그립습니다.
• @finn888 — 무엇이든 스크립트로 바꾸고 손볼 수 있던 때가 그립습니다. 요즘 앱은 빠져나갈 구멍 없는 블랙박스처럼 느껴집니다.
• @piterrro — 글의 말은 맞지만 현실에서는 대부분의 사람이 자기 환경을 직접 만들지 않습니다. 업무와 집에서 불편한 소프트웨어를 그대로 쓰거나 기성품을 택합니다. 필요한 인터페이스를 직접 만들려고 시간과 노력을 들일 사람은 일부일 것 같습니다.

원문: Ink & Switch / 번역·요약: Trawling