내 손으로 바꿀 수 있는 소프트웨어

게시일: 2026년 10월 12일 | 원문 작성일: 2025년 6월 | 저자: Geoffrey Litt, Josh Horowitz, Peter van Hardenberg, Todd Matthews | 출처: Ink & Switch | 원문 보기

닫힌 앱의 세계에서 사용자의 주도권을 되찾기

개인용 컴퓨터가 처음 약속했던 것은 새로운 종류의 점토였어요. 사용자가 마음대로 모양을 바꿀 수 있는 재료였죠. 하지만 우리 손에 들어온 것은 가전제품이었어요. 먼 곳에서 만들어져 밀봉된 채로 도착하고, 바꿀 수 없는 물건이요. 도구가 필요한 방식으로 작동하지 않으면 의견을 보내고 잘되기를 바랄 수밖에 없어요. 소프트웨어가 우리의 작업 방식에 맞춰야 하는데, 오히려 우리가 소프트웨어에 맞춰 작업 방식을 바꾸도록 강요받고 있어요.

이 글에서 우리는 내 손으로 바꿀 수 있는 소프트웨어 (malleable software)를 그려 보려고 해요. 사용자가 각자의 필요에 맞게 큰 어려움 없이 고쳐 쓸 수 있는 도구예요. 수정은 예외적인 일이 아니라 일상이 돼요. 멀리 있는 기업의 개발팀을 거치는 대신, 사용하는 바로 그 자리에서 도구를 바꾸는 거죠.

이 비전을 실현하려면 많은 장벽을 넘어야 해요. 프로그래밍 언어부터 운영체제와 앱스토어까지, 오늘날 컴퓨팅의 모든 층은 사용자가 함께 만들어 갈 것이라고 기대하기보다, 주어진 것을 받아 쓰기만 할 것이라고 가정하고 만들어졌어요. 우리에게 필요한 것은 모든 사용자가 조금씩 만드는 사람이 되도록 이끄는 컴퓨팅 시스템이에요. 서로 떨어진 거대한 앱 대신, 조합해서 나만의 작업 흐름을 만들 수 있는 도구요. 가까운 사람들과 함께 만드는 일을 뒷받침하는 시스템이요.

다행히 지난 수십 년 동안의 리서치와 상용 제품에서 영감을 얻을 수 있어요. 이 글에서는 그 성과에서 나온 아이디어와, 우리가 여러 해 동안 직접 만든 프로토타입을 시험하며 배운 것들을 함께 정리해요. 소프트웨어 개발자든, 리서처든, 어떤 방식으로든 컴퓨터를 사용하는 사람이든, 사용자가 소프트웨어를 바꿀 수 있는 세상을 향한 노력에 함께해 주세요.

왜 필요한가

우리는 환경을 우리에게 맞게 바꾸고 싶어요

환경은 중요해요. 일을 잘하고 삶을 잘 꾸려 가려면, 저마다 가진 가능성을 발휘할 수 있는 공간이 필요해요.

기타 제작자는 톱, 망치, 끌, 줄을 꼭 맞는 자리에 놓고 작업장을 꾸며요. 가장 좋은 결과를 얻기 위해 필요에 따라 새 도구를 만들기도 해요. 받침대로 쓸 나무토막을 만들거나, 펜치를 갈아서 알맞은 모양으로 다듬는 식이죠.

집에서 요리하는 사람은 여러 해에 걸쳐 칼과 도마, 냄비와 팬을 조금씩 모으며 자신에게 가장 잘 맞는 조합을 찾아요. 천장에 고리를 달고 선반을 옮겨서 자기 작업 방식에 맞출 수도 있어요. 평일 저녁밥을 만들든, 주말에 손님을 초대해 본격적인 야외 요리를 하든 말이에요.

모두 일상적인 모습이에요. 물리적인 세계에서는 환경을 직접 빚어 나가는 일이 자연스러워요. 물리적 현실은 우리가 바꿀 수 있으니까요.

벽에 포스트잇을 붙이거나, 서랍을 재배치하거나, 가구를 옮기는 작은 변화는 누구의 허락도 없이 즉시 할 수 있어요. 작업장을 만들거나 주방을 개조하는 것처럼 더 많은 노력과 기술이 필요한 큰 변화에도 도전할 수 있죠. 직접 할 기술이 없다면 지역의 기술자에게 도움을 청할 수도 있어요.

대량 생산 소프트웨어는 너무 경직돼 있어요

요즘 우리는 원자가 아니라 코드로 만들어진 환경에서 점점 더 많은 시간을 보내요. 이 변화 덕분에 대륙을 넘어 곧바로 협업하고, 수천 개의 파일을 순식간에 검색하는 등 많은 일을 할 수 있게 됐어요. 하지만 중요한 것을 잃고 있기도 해요. 환경을 바꿔서 우리의 것으로 만드는 능력이에요.

예를 하나 들어 볼게요. 이 글의 저자 중 한 사람은 벽에 카드를 붙여 업무를 추적하는 소프트웨어 팀에서 일했어요. 팀은 업무판을 계속 바꿔 나갔어요. 테이프로 그은 선을 옮기고, 체크리스트를 추가하고, 기본 격자 주변에 별도의 카드 구역을 만들었죠. 도구를 유연하게 바꿀 수 있으니 일하는 방식도 유연하게 바꿀 수 있었어요.

나중에 팀은 원격으로 일하는 동료를 지원하기 위해 웹 기반 이슈 추적 도구로 옮겼어요. 이제 특별한 카드 구역을 표현하거나 보여 줄 방법이 없어서, 그 절차를 포기했어요. 이후의 업무 절차 개선도 멈췄고요. 전에는 새로운 아이디어를 몇 분이면 시험해 볼 수 있었는데, 이제는 설정과 씨름하느라 몇 시간이 걸릴 수도 있었어요. 그나마 시험해 볼 수 있다면 말이에요. 업무를 전산화하면서 주도권을 잃은 거예요.

소프트웨어의 경직성은 사소한 불편으로 끝나지 않아요. 중요한 일을 하는 사람들에게 심각한 방해가 될 수 있어요. 의사이자 작가인 Atul Gawande는 의료계의 전산화가 전례 없이 심한 번아웃으로 이어지고 있다고 썼어요. 예전에는 의사들이 종이 서식을 작성할 때 관련 없는 항목을 건너뛰었어요. 이제 소프트웨어는 그 항목까지 채우도록 강요하지만, 의사들에게는 그 규칙을 수정할 권한이 없어요. Gawande는 한 의사를 두고 이렇게 말해요. “그녀가 화가 난 건 추가로 시간을 들여야 해서가 아니었다. 그 일이 아무 의미도 없어서였다.”

원문 보기

소프트웨어가 필요를 충족하지 못할 때 개발자에게 의견을 보낼 수는 있어요. 하지만 보통 곧바로 조치가 이루어지지는 않아요. 사용자마다 필요가 다르면, 중앙의 개발팀이 모든 사람의 문제를 해결할 수는 없어요. 게다가 개발자가 너무 많은 해결책을 한 제품에 밀어 넣으면, 제품은 비대하고 뒤죽박죽이 돼요. 좋은 제품팀은 이 함정에 빠지지 않으려고 사용자 요청 대부분을 거절하는 법을 배워요. 그러면 수많은 소수 사용자의 필요는 해결되지 않은 채 남아요.

소프트웨어가 우리의 구체적인 요구를 충족하지 못하는 것이 당연해 보일 수도 있어요. 하지만 그건 중앙 개발팀이 소프트웨어를 통제하는 것이 당연하다고 여겼기 때문이에요. 자기 필요를 잘 아는 사용자에게 더 많은 통제권을 넘기면 어떨까요?

Gawande는 한 신경외과 의사가 IT 분석가와 함께 자기 부서의 의무기록 시스템을 바꾼 이야기를 들려줘요. “얼마 지나지 않아 그들은 신경외과 외래 진료에 맞춰 설계된, 더 빠르고 직관적인 인터페이스를 만들었다.” 요구 사항은 전국의 모든 의사가 아니라 그 부서만의 필요에서 나왔어요. 생산성이 직접 향상된 것에 더해, 의사들은 자기 도구를 더 잘 통제한다고 느꼈어요. 번아웃의 해독제였죠.

이 이야기는 희망을 주지만, 일반적인 모습이라기보다 예외에 가까워요. 소프트웨어를 배포하는 데 쓰는 도구와 인프라가 사용자를 함께 만드는 사람이 아니라 수동적으로 받아 쓰는 사람으로 대하기 때문이에요. 소프트웨어는 유연하게 다시 조합할 수 있는 도구 모음 대신, 하나로 묶인 거대한 애플리케이션으로 구성돼요. 사용자에 맞게 바꾸려면 대부분의 사람에게 없는 프로그래밍 기술이 필요하고, 게다가 대부분의 소프트웨어는 소스가 공개되지 않아요. 소프트웨어를 수정할 도구도 함께 제공되지 않고요. 앱스토어는 기업이 소비자에게 소프트웨어를 배포하도록 설계돼 있어요. 아마추어가 친구에게 도구를 나눠 주도록 설계된 것이 아니에요. 작은 규모의 수공업이 아니라 산업적 대량 생산 시스템인 거죠.

물론 대량 생산 소프트웨어는 많은 이점을 가져다줬어요. 우리는 잘 다듬어진 다양한 애플리케이션을 합리적인 가격으로 사용할 수 있어요. 소프트웨어의 신뢰성, 접근성, 보안도 발전했어요. 개발자들은 팀에 지속적으로 보수를 지급하며 소프트웨어를 계속 개선할 수 있는 사업 모델을 만들었고요.

하지만 이 이야기와 셀 수 없이 많은 다른 사례가 보여 주듯, 유연하지 못한 대량 생산 소프트웨어는 걸림돌이 되기도 해요. 평균적인 사용자와 다를수록, 전문가가 매끈하게 다듬은 제품의 장점보다 자기에게 맞게 바꾸는 편이 더 유리해져요. 누구나 어떤 면에서는 고유해요. 글쓰기, 음악 만들기, 토론, 프로젝트 계획에 쓰는 도구에 나름의 강한 선호가 있을 수도 있죠. 구체적인 필요가 있을 때는 주도권이 중요해요.

우리의 목표: 내 손으로 바꿀 수 있는 소프트웨어

우리는 사용자가 함께 만드는 사람으로서 주도권을 갖는 새로운 컴퓨팅 생태계를 그려요. 이 아이디어를 ‘내 손으로 바꿀 수 있는 소프트웨어’라고 불러요. 누구나 큰 어려움 없이 자기 필요에 맞게 도구를 바꿀 수 있는 소프트웨어 생태계예요.

• ‘소프트웨어 생태계’는 소프트웨어와 사용자를 둘러싼 폭넓은 기술적·문화적 환경을 뜻해요. 사용자가 소프트웨어를 바꿀 수 있게 하는 일은 좁은 기술적 문제에 그치지 않아요.
• ‘누구나’라는 말은 폭넓은 접근성을 목표로 삼는다는 뜻이에요. 개인이 자립할 능력을 기르는 것도 유용하지만, 가까운 공동체와 협력하는 일도 가치가 있어요.
• ‘도구를 바꾼다’는 말에는 기존 소프트웨어를 조금 손보는 일부터, 크게 개조하는 일, 기존 도구와 잘 어울리는 새 도구를 만드는 일까지 다양한 맞춤 작업이 포함돼요. 필요에 맞게 바꾼다고 해서 처음부터 다시 만들어야 하는 것은 아니에요.
• 마지막으로 ‘큰 어려움 없이’가 핵심이에요. 도구를 수정하는 일은 빨라야 해요. 가볍게 느껴져야 하고요. 가장 좋은 경우에는 필요가 생긴 그 순간에 수정하고, 하던 일로 돌아갈 수 있어야 해요.

기존의 접근법

설정이나 플러그인은 어떻냐고 생각할 수도 있어요. 소프트웨어를 맞춤화하는 훌륭한 방법은 실제로 많아요. 하지만 위에서 제시한 목표를 온전히 이루지 못하게 하는 한계도 있어요.

설정

설정은 애플리케이션의 동작을 바꾸는 흔한 방법이에요. 알맞은 설정이 있다면 체크박스 하나를 켜고 하던 일을 계속하면 돼요.

하지만 설정으로 바꿀 수 있는 것은 애플리케이션 개발자가 열어 두기로 한 기능뿐이에요. 원하는 일을 하는 설정이 없으면 막히게 되죠. 또 설정에는 각 항목이 어떻게 연결되는지 이해할 만한 일관된 틀이 없어, 서로 무관한 체크박스만 길게 늘어서기 쉬워요.

원문 보기

플러그인

중앙 개발팀이 할 수 있는 일을 넘어 기능을 늘리는 한 가지 방법은 외부 개발자가 애플리케이션 동작을 확장하는 플러그인을 만들도록 허용하는 거예요. 좋은 플러그인 시스템에서는 다른 사람이 만든 플러그인을 설치할 수 있으니, 사용자가 적은 노력으로 맞춤화를 시작할 수 있어요. 플러그인 API는 기반 애플리케이션과 여러 확장 기능이 어떻게 맞물려 작동할지 안정적인 규칙을 제공해요. 덕분에 계속 유지보수하기 쉽다는 중요한 장점도 있어요.

하지만 플러그인 시스템으로도 앱 동작을 바꿀 수 있는 범위는 허용된 방식으로 한정돼요. 원하는 수정을 위한 플러그인 접점이 없으면 사용자는 어쩔 수 없어요. (사실 대부분의 애플리케이션에는 플러그인 API 자체가 없어요. 좋은 API를 설계하는 일이 어렵거든요!)

다른 문제도 있어요. 플러그인을 설치하는 일과 만드는 일 사이에는 건너기 어려운 큰 틈이 있어요. 앱마다 플러그인 시스템도 달라서, 서로 다른 앱 사이에서 플러그인을 공유하는 일은 대개 불가능해요.

원문 보기

모딩

설정과 공식 확장 API로 충분하지 않을 때, 또는 처음부터 제공되지 않을 때, 사용자가 허락 없이 모딩(modding)T1을 해서 통제권을 얻을 수 있는 경우도 있어요. 예를 들어 브라우저 확장 프로그램은 원래 애플리케이션 개발자가 확장 지점을 마련해 주지 않아도 웹사이트의 사용자 인터페이스에 개입하고, 사용자의 브라우저에서 실행되는 새로운 동작을 추가할 수 있어요.

허락이 필요 없는 모드는 공식적으로 지원되는 플러그인 API보다 훨씬 다양한 상황에서 사용할 수 있어요. 원래 개발자가 어떤 종류의 확장에 적극적으로 반대해도 사용할 수 있죠. 광고 차단기는 웹사이트의 이익보다 사용자의 이익을 우선해요.

모드에도 한계는 있어요. 만들려면 지루한 역공학 작업이 필요할 수 있어요. 기반 애플리케이션이 바뀌면 유지보수가 어려워지기도 해요. 같은 앱의 서로 다른 모드가 잘 어울려 작동하지 않는 경우도 많고요.

기반 플랫폼의 한계도 가능한 일을 제한해요. 예를 들어 브라우저 확장 프로그램은 서버 측 동작을 수정할 수 없어요. 그 때문에 제공할 수 있는 기능이 크게 제한돼요. 또한 다른 플러그인과 마찬가지로, 공식 지원이 없는 모드도 설치와 제작 사이에 큰 틈이 있어요. 브라우저 확장 프로그램을 만들려면 브라우저를 벗어나 코드를 쓰고, 코드를 패키지로 묶어서 배포해야 해요. (뒤에서 이 단계를 피하는 몇 가지 방법을 이야기할 거예요.)

원문 보기

오픈 소스

오픈 소스 소프트웨어 운동은 소스 코드를 배포해 사용자가 자기 소프트웨어를 소유하고, 개선에 기여하고, 필요하면 자기 필요에 더 잘 맞는 별도 버전을 만들 수 있어야 한다는 생각을 널리 알려요. 세상에 긍정적인 힘이 돼 왔고, 사용자가 소프트웨어를 바꿀 수 있게 하는 중요한 요소예요.

하지만 코드를 수정할 수 있다고 해서 그 과정이 수월한 것은 아니에요. 규모가 있는 오픈 소스 코드베이스를 수정하려면 대개 상당한 전문성과 노력이 필요해요. 버튼 색을 바꾸는 아주 작은 수정도 마찬가지예요. 숙련된 프로그래머에게도 개발 환경을 설정하고 코드베이스를 파악하는 일은 부담이 커요. 필요가 생긴 순간에 가볍게 시도할 일이 되기는 어렵죠.

원문 보기

AI의 도움을 받는 코딩

마지막으로 요즘 뜨거운 주제도 짚어 볼게요. AI 도구가 사용자가 소프트웨어를 손쉽게 바꾸는 세상을 저절로 실현해 줄까요?

소프트웨어 제작을 누구나 할 수 있게 만드는 데는 오랫동안 큰 숙제가 있었어요. 보통 사람들이 컴퓨터 프로그램을 작성할 수 있게 하려면 어떻게 해야 할까요? 더 친숙한 문법이나 더 단순한 의미 체계를 갖춘 프로그래밍 언어, 시범을 보여 프로그램을 만드는 매크로 기록 시스템, 시각적인 라이브 프로그래밍 환경 등 여러 접근법이 시도됐어요.

이런 발전에는 흥미로운 가능성이 있고, 지금 내 손으로 바꿀 수 있는 소프트웨어를 추구할 좋은 이유가 된다고 생각해요. 하지만 동시에 AI 코드 생성만으로는 사용자가 소프트웨어를 바꾸는 데 놓인 모든 장벽을 해결할 수 없어요. 모든 컴퓨터 사용자가 코드를 완벽하게 작성하고 수정할 수 있다고 가정해도, 큰 질문들이 여전히 남아요.

사용자가 서로 분리된 새 애플리케이션만 만드는 대신, 이미 설치한 기존 도구를 손볼 수 있게 하려면 어떻게 해야 할까요? AI가 생성한 도구들이 공유 데이터 위에서 서로 조합돼 더 큰 작업 흐름을 만들려면 어떻게 해야 할까요? 아주 작은 변경까지 AI 코딩에 맡기지 않고도, 사용자가 자기 소프트웨어의 수정을 더 직접적이고 정확하게 통제하도록 하려면 어떻게 해야 할까요? 프롬프트로 클라우드에 호스팅되는 애플리케이션을 생성하는 제품은 이 질문들에 답하지 않아요.

오늘날의 소프트웨어 생태계에 AI 코딩 도구를 들여오는 일은 푸드코트에 유능한 보조 요리사를 데려오는 것과 같아요. 메뉴에서 음식을 골라 사 먹는 데 익숙하다면, 솜씨 좋은 요리사도 도와줄 일이 많지 않아요. 마찬가지로 앱스토어에서 받은 비공개 소스 소프트웨어를 쓴다면, AI 코딩 도우미가 사용자를 위해 해 줄 수 있는 일도 많지 않아요. AI의 능력을 온전히 활용하려면 푸드코트를 벗어나, 제약 없이 무언가를 만들 수 있는 주방 같은 곳으로 가야 해요.

---

사용자의 주도권을 중심으로 컴퓨팅의 토대를 다시 만드는 것은 야심 찬 목표예요. 다행히 개인용 컴퓨터가 등장한 초기부터 많은 사람이 이를 실현할 강력한 아이디어를 제안해 왔어요.

다음 몇 절에서는 내 손으로 바꿀 수 있는 소프트웨어를 실현하는 데 꼭 필요하다고 보는 세 가지 설계 패턴을 정리할 거예요. 문제를 푸는 정확한 조리법은 아니에요. 하지만 오늘날 소프트웨어 세계에서 충분히 다뤄지지 않는 중요한 사고방식이고, 사용자가 소프트웨어를 바꿀 수 있게 만드는 해법의 일부가 될 거라고 믿어요.

• • •

사용자에서 창작자로 이어지는 완만한 경사

내 손으로 바꿀 수 있는 소프트웨어라고 해서 모든 사람이 자기 도구를 전부 처음부터 만들어야 하는 건 아니에요. 이미 나와 있는 도구 가운데는 조금만 손보면 우리 필요에 충분히 맞는 것도 많으니, 그렇게 하면 시간을 낭비하게 되겠죠.

다른 사람이나 회사가 만든 기존 소프트웨어 도구를 먼저 쓰다가, 내 필요에 맞지 않는 부분을 발견했을 때 도구를 고칠 수 있는 선택권을 갖는 편이 더 합리적이에요. 처음에는 주어진 것을 쓰는 사용자였다가, 차츰 편집자이자 창작자가 될 수 있는 거예요.

Allan MacLean과 EuroPARC 동료들은 1990년 논문 「User-Tailorable Systems: Pressing the Issues with Buttons」에서 사용자가 점차 창작자가 되도록 이끄는 소프트웨어 시스템을 설계할 때 유용한 사고의 틀을 제안했어요.

연구진은 Buttons라는 자동화 시스템으로 이 원칙을 보여 줬어요. 사용자는 처음에 버튼을 옮기거나 글자와 색을 바꿀 수 있었어요. 경사를 조금 더 올라가면 변수 값을 고치거나 도구 모음으로 간단한 사용자 인터페이스를 만들 수 있었죠. 마지막으로 경사 맨 위에서는 Lisp 프로그래밍으로 새로운 동작을 만들 수 있었어요. 핵심은 각각의 변경을 가능한 한 가장 간단한 기법으로 하고, 본격적인 프로그래밍은 꼭 필요할 때만 쓰는 마지막 수단으로 남겨 두는 것이었어요.

스프레드시트는 완만한 경사를 만드는 데 유용한 몇 가지 특성을 보여 줘요. 첫째, 스프레드시트에는 사용하던 자리에서 바로 쓸 수 있는 개발 도구가 있어요. 스프레드시트를 쓰는 모든 사람이 완전한 편집기를 실행하고 있는 거예요. 더 깊이 수정하고 싶어져도 별도의 개발 환경을 설치하거나 열 필요가 없어요.

또 스프레드시트는 대개 투박한 모습을 하고 있어요. 전문가가 픽셀 하나까지 정교하게 다듬은 애플리케이션보다 스프레드시트를 고치는 쪽이 덜 부담스럽게 느껴질 수 있어요.

경사를 완만하게 만드는 방법은 두 가지예요. 하나는 그래프 오른쪽, 즉 본격적인 프로그래밍에서 출발해 필요한 숙련도를 낮추는 거예요. 프로그래밍의 온전한 표현력에서 출발해 더 쉽게 접근하도록 만드는 수많은 연구가 이 전략에 해당해요. 더 친숙한 문법, 라이브 프로그래밍 환경, 예시에서 프로그램을 추론하는 방법, 단계적으로 제공하는 학습 발판 등이 여기에 들어가요.

그런데 그만큼 중요하면서도 때로 간과되는 또 다른 전략이 있어요. 그래프 왼쪽, 즉 단순한 사용에서 출발해 할 수 있는 일을 차츰 늘리는 거예요. 스프레드시트, HyperCard, Flash, Notion, Airtable처럼 사용자가 바꿀 수 있도록 만들어 성공한 많은 시스템은 비슷한 패턴을 따라요. 필요하면 프로그래밍도 할 수 있는 미디어 편집기라는 패턴이에요. 익숙한 직접 조작 방식으로 문서를 편집할 수 있는 환경이라면, 사용자는 코드를 한 줄도 쓰지 않고 많은 일을 할 수 있어요.

마지막으로 덧붙이고 싶은 점이 있어요. 모든 사람이 경사 맨 위까지 올라갈 필요는 없어요. 많은 비전문가는 어느 시점에 다른 사람의 도움을 구해요. 시간과 에너지를 아끼거나, 필요한 기술을 새로 배우는 부담을 피하려는 거죠. 핵심은 배움과 숙련에 조금씩 감당할 만한 노력을 들이면 비전문가도 여러 가지 변경을 할 수 있어야 한다는 거예요. 완만한 경사는 숙련도가 다른 사람들 사이의 협업도 더 매끄럽게 해 줘요. 함께 만드는 일의 중요성을 이야기할 때 이 점을 더 살펴볼게요.

• • •

앱 대신 도구

지금까지는 개별 애플리케이션이 얼마나 경직되어 있는지에 집중했어요. 하지만 소프트웨어를 내 필요에 맞추기 어려운 데는 또 다른 이유가 있어요. 바로 ‘애플리케이션’이라는 개념 자체예요. 우리에게 너무 익숙한 개념이라 문제의 성격을 알아보기 어려울 수 있으니, 주방에 빗대어 생각해 볼게요.

앱은 아보카도 슬라이서와 같아요

이 비유를 소프트웨어에 적용하면 어떻게 될까요? 많은 애플리케이션은 아보카도 슬라이서와 같아요. 여행 계획, 운동 기록, 레시피 정리처럼 특정 용도를 겨냥해 기능들을 묶어 놓은 거예요. 앱은 한 용도와 관련된 여러 작업을 처리해야 하다 보니, 어느 작업도 특별히 잘하지 못하는 경우가 있어요. 내게 중요한 기능은 없으면서 필요 없는 기능은 잔뜩 들어 있는 앱을 만난 적이 있을 거예요.

애플리케이션 모델에 장점이 없다는 말은 아니에요. 개발자가 다른 도구와의 상호 운용을 걱정하지 않고 경험을 세밀하게 다듬을 수 있으니, 사용자는 애플리케이션의 경계 안에서 일관된 경험을 얻어요. 데이터를 애플리케이션마다 분리하는 방식은 일부 보안과 개인정보 문제를 해결하는 편리한 방법이에요. 애플리케이션과 지원에 비용을 지불하는 것도 합리적인 과금 방식이고요. 무시할 수 없는 중요한 장점들이에요.

하지만 복잡한 문제를 해결하거나 여러 애플리케이션에 걸친 창의적인 작업 흐름을 만들려고 할 때는, 애플리케이션 사이의 단절이 심각한 문제를 일으킬 수 있어요. 아보카도 슬라이서보다는 칼에 가까운, 더 범용적이고 서로 조합할 수 있는 도구를 중심으로 소프트웨어를 다시 구성하려면 어떻게 해야 할까요? 여기에는 해결해야 할 두 가지 문제가 있어요. 도구 사이에 데이터를 공유하는 것과, 사용자 인터페이스 안에서 도구들을 결합하는 것이에요.

도구 사이에 데이터 공유하기

여러 소프트웨어 도구를 함께 조율해 일을 해내려면, 그 도구들이 같은 정보와 작업 대상을 공유할 수 있어야 해요.

오늘날의 클라우드와 모바일 플랫폼에서는 각 애플리케이션이 자기 데이터를 전용 저장 공간에 따로 관리해요. 여행 계획은 메모 앱, Google Maps 목록, 달력에 흩어져 있어요. 이런 분산은 사용자가 소프트웨어를 바꾸기 어렵게 해요. 애플리케이션마다 자기 데이터를 관리하면 기존 작업 흐름에 새 도구를 추가하기가 더 어려워져요. 작업의 일부를 더 잘 처리하는 다른 도구가 있어도, 기존 애플리케이션 안에서 모든 일을 마치는 편이 더 쉬워요.

반대로 데이터를 애플리케이션들이 공유하면 최종 사용자는 도구를 더 유연하게 조합할 수 있어요. 잘 알려진 예가 데스크톱 파일 시스템이에요. 정보를 파일로 저장하면 각기 다른 세부 작업에 집중하는 여러 도구로 같은 파일을 편집할 수 있어요. Lightroom에서 사진의 밝기를 조정한 뒤, Apple의 미리보기에서 사진에 메모를 적을 수 있죠. 협업하는 사람들도 각자 선호하는 도구를 쓸 수 있어요. 한 사람은 VSCode로 코드 저장소를 편집하고, 함께 일하는 동료는 emacs로 편집할 수 있어요.

원문 보기

데이터 공유라는 생각은 동작을 가진 객체를 공유하는 데까지 이어져요. Smalltalk에서 사용자는 이미지(image)T2를 다뤄요. 이미지는 저장된 상태뿐 아니라 그 상태와 연결된 코드까지 나타내는 객체들의 저장소예요. 시스템의 모든 것이 객체로 표현되므로, 기존 객체를 다루는 새 도구를 추가할 수 있어요. 메서드를 호출해 동작을 실행하는 도구도 포함해서요.

사용자 인터페이스 조합하기

도구들은 기반 데이터뿐 아니라, 함께 사용할 수 있는 작업 공간도 공유해야 해요.

앱이라는 패러다임은 이런 방식에 맞춰져 있지 않아요. 애플리케이션은 창이나 탭 하나를 차지하고 그 안에 자기만의 세계를 만들어요. 여기에는 장점도 있어요. 애플리케이션 제작자가 그 세계 안에서 사용자의 경험을 세심하게 다듬고 모든 것이 정확히 맞물려 작동하도록 만들 수 있죠. 하지만 그 결과 여러 애플리케이션을 함께 쓰려면 서로 단절된 사용자 경험 사이를 계속 오가야 해요. 새 도구를 쓸 때마다 재료를 한 주방에서 다른 주방으로 들고 가야 하는 셈이에요. 데이터가 서로 호환되더라도 사용 경험은 조각나 있어요.

애플리케이션이 데이터를 독점하는 것뿐 아니라 상호작용 환경을 통제하는 것까지 어떻게 풀어낼 수 있을까요? 앞에서는 플러그인이나 허락 없이 하는 모딩처럼, 애플리케이션 내부에서 기능을 확장할 틈을 여는 방법을 살펴봤어요. 훌륭한 방법들이지만 ‘앱 대신 도구’를 쓰는 세상을 원한다면 조금 다른 것이 필요해요. 여러 도구를 한데 모아 공유 공간에서 함께 쓸 수 있는 환경이에요.

사용자 인터페이스를 작은 조각들로 나누면 새로운 설계 과제가 생겨요. 사용자는 문서의 각 부분에 어떤 편집기를 쓸지 어떻게 선택할까요? 문서를 공유할 때 상대방에게 필요한 모든 부분 편집기가 준비되어 있다고 어떻게 보장할까요? 선택이나 포커스처럼 전체에 걸친 상호작용은 여러 편집기 사이에서 어떻게 작동할까요? OpenDoc 같은 시스템이 마련한 답은 연구해 볼 가치가 있어요. 다만 오늘날의 협업 애플리케이션과 웹 기반 애플리케이션은 주변 맥락을 바꿔 놓았다는 점도 고려해야 해요.

이를 해결하기 위해 Tchernavskij는 *엔탱글러(entangler)*를 제안해요. 관련된 사용자 인터페이스 요소를 동적으로 감지하고 연결하는 전용 계층을 인터페이스 시스템에 두는 거예요. 또 다른 연구 프로젝트인 Varv는 항목을 계속 덧붙일 수 있는 이벤트 트리거 목록으로 동작을 정의해 이 문제를 해결해요. 두 접근법의 세부 내용은 다르지만, 인터페이스 각 부분 사이의 연결을 나중에도 확장할 수 있는 형태로 표현한다는 공통점이 있어요.

Dynamicland에서 도구를 쉽게 조합할 수 있는 것은 상당 부분 프로그램을 서로 협력하는 작은 객체들로 나누기 때문이기도 해요. 이 객체들은 전역 데이터베이스를 통해 통신해요. 따라서 기존 객체 사이의 메시지를 가로채는 새 도구를 시스템에 추가해, 기존 도구의 동작을 바꿀 수 있어요. 정보를 보내는 쪽과 받는 쪽 사이에 특정 연결이 있다고 시스템이 처음부터 가정하지 않으면, 그 정보를 새롭게 활용하는 기능을 덧붙여 시스템을 확장하기가 더 쉬워요.

• • •

함께 만드는 소프트웨어

모든 사람이 자기만의 컴퓨터 사용 경험을 만들어 간다고 상상하면 설레요. 하지만 내 손으로 바꿀 수 있는 소프트웨어를 개인의 문제로만 바라보면 한계가 있어요.

물론 개인은 필요할 때 소프트웨어를 조금씩 자기 필요에 맞춰 바꿀 수 있어야 해요. ‘사용에서 창작으로 이어지는 완만한 경사’를 올라가는 거죠. 하지만 원하는 변화가 커질수록 소프트웨어를 만드는 데 더 많은 시간과 능력이 필요해요. 모두가 자신만을 위해 이런 변화를 매번 따로 만들어야 한다면, 아마 비용에 비해 이득이 크지 않을 거예요. 누구나 소프트웨어 제작 전문가가 되고 싶은 건 아니니까요.

소프트웨어를 바꾸는 일을 공동체의 관점에서 봐야 하는 더 근본적인 이유도 있어요. 우리는 컴퓨터를 함께 사용하잖아요! 제품 팀에는 프로젝트를 추적하는 하나의 시스템이 필요해요. 병원의 한 부서에는 환자 접수 양식을 위한 하나의 시스템이 필요하죠. 이런 공동체에 아무런 통제권도 없는 획일적인 앱이 잘 맞을 리는 없어요. 그렇다고 사용자마다 각자 알아서 해결하라는 것도 답이 될 수 없어요. 공동체가 자기 문제를 해결하는 공통의 해법을 만들고 유지하도록 도와야 해요.

적절한 기반이 있으면 소프트웨어를 함께 만들어 갈 수 있어요. 자유 소프트웨어 공동체에서 이미 보았듯이, 세계 곳곳에서 비슷한 필요를 가진 사람들이 작업물을 교환하고 함께 개발할 수 있어요. 회사부터 가족, 시민 단체까지 다양한 작은 공동체도 자기 상황에 맞는 소프트웨어를 만들고 유지할 수 있죠. 공동체의 요구가 ‘경사’의 더 높은 곳에 이르러 특별한 능력과 열정을 필요로 한다고 해서 모두가 그 수준에 도달해야 하는 건 아니에요. 그 역할을 맡아 일을 해낼 사람이 충분히 있으면 돼요.

‘현장’의 상황에 맞는 소프트웨어를 만드는 일이 전 세계에서 쓸 소프트웨어를 만드는 것보다 때로는 더 쉬워요. 사용자와 직접 소통하고 사용자가 겪는 상황에 대응할 수 있다면, 빈틈없이 견고한 산업용 수준의 소프트웨어를 만들 필요가 없어요. 설계할 때 모든 사람의 요구를 예상할 필요도 없죠. 자기 공동체의 요구만 고려하면 돼요. Clay Shirky는 이런 양상을 ‘상황에 맞춘 소프트웨어(situated software)’라고 불렀어요. 학생들이 ‘사회적 기반이나 맥락에 따른 정보를 활용’해서 자기 공동체를 위한 소프트웨어를 빠르게 만들었다고 설명했죠. 더 가까운 관계의 사례로는 Robin Sloan이 가족을 위해 만든 앱을 ‘집에서 해 먹는 요리’라고 표현한 것이 기억에 남아요.

이 모든 이유를 생각하면, 내 손으로 바꿀 수 있는 소프트웨어의 기술적 기반은 여러 수준에서 사람들이 함께 협력하는 사회기술적 체계를 지원해야 해요. 사람들이 자기 자신과 공동체를 위해 소프트웨어를 활용할 수 있도록요.

자유 소프트웨어의 역사는 이런 사회기술적 체계를 만드는 방법을 가르쳐 줘요. 특히 세계에 중앙에서 통제하는 단 하나의 앱 버전만 있어야 한다고 가정하지 않는 자유 소프트웨어 공동체에서 많은 영감을 받아요. 예를 들어 작은 공동체가 운영하는 Mastodon 인스턴스는 공동체만의 기능과 정책을 구현하려고 Mastodon 코드를 수정하는 경우가 많아요. 물론 이런 경우에도 상당한 엔지니어링 작업이 필요하고, 여전히 앱을 대상으로 작업하고 있어요. 소프트웨어 수정으로 이어지는 경사가 더 완만해지고 앱보다 도구가 많아지는 세상으로 나아가면서, 더 작은 코드 조각을 공유하고 함께 개발하는 방법을 찾아야 해요. 다양한 소프트웨어가 공존하는 세상에서 상호운용성을 유지하는 방법도 알아내야 하죠.

• • •

Ink & Switch의 프로토타입

Ink & Switch에서는 지난 몇 년 동안 내 손으로 바꿀 수 있는 소프트웨어의 여러 측면을 탐구하는 리서치 프로토타입을 만들었어요. 이 프로젝트들은 상용 제품이 아니에요. 각 프로토타입의 목표는 사용자가 소프트웨어를 바꿀 수 있게 하는 기법을 더 잘 이해하고, 그 프로토타입을 깊이 사용하면서 배우는 것이었어요. (사실 이 글도 우리가 직접 만든, 내 손으로 바꿀 수 있는 소프트웨어 환경에서 썼어요. 그 과정에서 경험한 성공과 실패도 몇 가지 공유할게요.)

우리 작업은 컴퓨팅 스택 전체에 걸쳐 있고, 크게 두 갈래로 나눌 수 있어요. 한 갈래는 기초 기반 기술을 탐구했어요. 그 위에 사용자가 바꿀 수 있는 경험을 만들 수 있도록 데이터를 저장하고, 코드를 불러오고, 사용자 인터페이스를 정의하는 기법이죠. 스택의 더 높은 곳에 있는 다른 갈래는 특정한 사용자 경험에 집중했어요. 정적인 미디어에 상호작용하는 동작을 조금씩 더할 수 있는 동적 문서예요. 차례로 살펴볼게요.

사용자가 바꿀 수 있는 소프트웨어를 위한 기반

앞서 오늘날 소프트웨어를 실행하고 개발하는 데 쓰이는 기반 기술 대부분이 사용자가 수정하기 쉽게 만드는 일을 우선순위에 두지 않고 설계됐다고 이야기했어요. 사용자가 수정하기 쉽게 만드는 쪽으로 방향을 바꿀 때 참고할 사례도 살펴봤죠. 데스크톱 파일 시스템은 도구 사이의 데이터 공유를 가능하게 해요. Smalltalk, HyperCard, 스프레드시트는 실행 중에 코드를 편집하도록 해서 실시간 수정을 가능하게 하죠. DOM으로 UI를 표현하는 브라우저 기반 앱에서는 확장 기능으로 허락을 받지 않고 개조할 수 있어요.

이런 선례에 영감을 받아, 우리는 사용자가 쉽게 수정할 수 있는 소프트웨어를 만들고, 실행하고, 공유할 기술 기반의 프로토타입을 만들어 왔어요. 우리 접근법은 또 다른 리서치 분야인 로컬 우선 소프트웨어를 토대로 해요. 다른 사람과 협업할 수 있으면서도 사용자에게 데이터의 소유권과 통제권을 주는 일을 우선하는 철학이죠. 그 작업의 일부로 Automerge라는 협업 라이브러리를 개발했어요. 사용자 사이에서 JSON 문서를 영구 저장하고 동기화해요.

PushPin: 확장 가능한 미디어 캔버스

로컬 우선 기반이 어떻게 사용자의 수정을 가능하게 할지 알아보기 위해, 웹 기반 협업 미디어 캔버스인 PushPin의 프로토타입을 만들었어요. 이 프로젝트에서 발전시킨 핵심 아이디어는 ‘문서 기반 함수형 반응형 프로그래밍(document functional reactive programming, DFRP)’이었어요. 도구를 React로 작성한 UI 컴포넌트로 표현하고, 그 뒤에 Automerge를 통해 자동으로 영구 저장되고 동기화되는 JSON 문서를 두는 방식이에요.

PushPin은 여러 어려움도 보여 주었어요. 첫째, 특정 맥락에서 문서를 표시할 UI를 어떻게 선택할까요? 우리는 맥락을 코드에 고정한 단순한 모델을 시도했어요. ‘문서를 보드의 카드로 렌더링할 때는 간결한 뷰를 표시하고, 주 콘텐츠로 렌더링할 때는 확장된 뷰를 표시한다’는 식이었죠. 하지만 이 접근법으로는 모든 요구를 충족할 수 없었어요. 우선 사용자가 수행하는 작업에 따라 뷰를 고를 수 없었어요.

삽입 모델은 격리와 조율 사이의 균형도 잡아야 한다는 사실을 알게 됐어요. 우리는 컴포넌트가 서로를 삽입할 수는 있지만 그 밖의 통신은 허용하지 않는 제한적인 모델을 사용했어요. 이렇게 강하게 격리하면 특정 컴포넌트 안의 동작을 이해하기는 쉬웠지만, UI 컴포넌트끼리 마우스를 올린 상태 같은 맥락을 쉽게 공유할 수 없어 풍부한 사용자 경험을 일부 구현하지 못했어요. 기존 컴포넌트 내부에 접근할 수단이 없어서 허락 없는 개조도 잘 지원되지 않았죠. 어떤 뷰를 선택해 표시할지, 컴포넌트 사이를 어떻게 조율할지는 아직 탐구할 여지가 남아 있어요.

Cambria: 도구 사이의 스키마 호환성 조율

PushPin을 사용하면서 스키마 호환성 때문에 답답한 일이 있었어요. 도구를 업그레이드하면 기존 데이터와의 호환성이 자주 깨졌죠. 기반 JSON 데이터의 형식에 정확히 합의하지 못하면 서로 다른 도구를 함께 작동하게 만들기도 어려웠어요. 이는 더 넓은 범주의 문제를 보여 주는 사례예요. 데이터의 형태에 합의할 수 없는 도구들은 어떻게 협력해야 할까요? 사용자가 바꿀 수 있는 환경에서는 중앙 권한자가 스키마를 지정해 주리라 기대할 수 없어요.

우리는 쓰기 스키마와 읽기 스키마를 분리해 이 문제를 해결하는 Cambria라는 시스템의 프로토타입을 만들었어요. 각 도구는 자신이 선호하는 스키마로 변경 내용을 기록하고, 필요할 때 다른 스키마로 해석해요. 같은 스키마의 최신 버전이나 이전 버전일 수도 있고, 다른 도구가 사용하는 완전히 다른 스키마일 수도 있죠. 일회성 데이터 마이그레이션이 아니에요. 어느 스키마에서든 동시에 쓰고 읽을 수 있도록 계속 실시간으로 변환해요.

Farm: 코드도 데이터예요

PushPin은 환경에 새 도구를 추가하는 문턱을 낮췄지만, 실행 중에 시스템을 편집할 수는 없었어요. 코드는 GitHub 저장소에 저장하고 일반적인 웹 앱 파이프라인으로 배포했거든요. 그래서 다음 프로젝트에서는 로컬 우선 데이터 계층에 사용자 데이터뿐 아니라 시스템 자체의 코드도 담아 자유로운 수정을 가능하게 하는 실험을 했어요. Farm이라는 시스템을 만들어 사용자가 Elm 언어로 도구를 작성하고, 소스 코드를 Automerge 문서에 저장하고 동기화하게 했죠.

기본적으로 코드를 데이터로 다루면 도구 공유가 간단해졌어요. 하지만 협업의 여러 측면은 어려웠어요. 편집하는 동안 다른 사람이 사용하는 도구를 망가뜨리지 않으면서 작업하려면 어떻게 해야 할까요? 여러 협업자가 같은 도구의 서로 다른 부분을 동시에 작업하려면요? 이런 문제들을 계기로 다음 프로젝트를 시작했어요.

Patchwork: 버전 관리와 직접 써 가며 개발하기

사용자가 소프트웨어를 바꿀 수 있으려면, 여러 가능성을 탐색하고 저마다 다른 방향으로 나아갈 수 있어야 해요. 이것이 핵심이에요. 사용자들은 작업을 잃거나 협업자의 작업을 망칠까 걱정하지 않고 소프트웨어를 바꿔 보거나 여러 변형을 만들 자유가 필요해요. 전통적인 소프트웨어 엔지니어링 프로젝트에서는 Git 브랜치 같은 버전 관리 개념으로 이런 문제를 해결하죠.

버전 관리 시스템은 소프트웨어 엔지니어에게 유용한 도구지만, 내 손으로 바꿀 수 있는 소프트웨어를 지원하도록 설계되지는 않았어요. 배우기 어렵고, 정형화된 협업 작업 흐름을 대상으로 해요. 우리는 폭넓은 사용자가 쉽게 접근할 수 있고 가볍고 비공식적인 탐색을 더 잘 지원하는 새로운 해법이 필요하다고 생각해요. 이 비전을 보편적 버전 관리(universal version control)라고 불러요.

이런 버전 관리 아이디어를 더 탐구하기 위해, 내 손으로 바꿀 수 있는 소프트웨어를 위한 웹 기반 협업 환경인 Patchwork를 만들었어요. Patchwork는 PushPin과 Farm의 핵심 아이디어를 이어받아 사용자 데이터와 소프트웨어 코드를 모두 Automerge 문서에 저장해요. 그 위에 변경 이력 보기와 간단한 브랜치 기능 같은 버전 관리 유틸리티를 더했죠. 이 도구들은 글이든 소프트웨어 도구의 코드든 시스템 안의 모든 문서에 적용돼요.

원문 보기

Patchwork로 작업하면서 관찰한 것 중 하나는 사용자가 바꿀 수 있는 시스템 안에서는 소프트웨어를 개선할 기회가 자연스럽게 생길 수 있다는 점이에요. 이 글을 쓰는 과정에서 나온 사례를 볼게요. 우리가 주로 사용하는 도구는 협업용 Markdown 편집기예요.

원문 보기

새 도구가 별로 유용하지 않은 경우도 있었어요. 공동 저자에게 피드백 요청을 배정하는 일을 관리할 ‘Request Tracker’를 만들었지만, 결국 많이 사용하지는 않았어요. 그래도 큰 손해는 아니었어요. 만드는 데 큰 노력이 들지 않았고, 무시하거나 삭제하기도 쉬웠으니까요.

Patchwork를 맞춤화하면서 알게 된 또 다른 점은 AI가 사용자가 바꿀 수 있는 환경을 유용하게 보완한다는 거예요. 앞서 AI 지원 코딩만으로는 사용자가 소프트웨어를 바꿀 수 있다는 보장이 없다고 주장했어요. 하지만 사용자가 바꿀 수 있는 환경과 결합하면, AI 지원 개발은 도구 편집을 훨씬 빠르게 만들어 줄 수 있어요.

우리는 AI의 도움으로 Patchwork 안에서 여러 도구를 빠르게 만들었어요. 앞서 언급한 Section Word Counter도 AI의 도움을 받아 몇 분 만에 코딩했죠. 따로 시간을 내지 않고 글을 쓰던 도중에 만들었어요.

Patchwork에서 이미 사용자가 바꿀 수 있다는 가능성을 조금씩 경험했지만, 큰 과제도 남아 있어요.

남은 과제 중 하나는 가벼운 보편적 버전 관리의 아이디어를 코드에 온전히 적용하는 거예요. 소프트웨어 도구의 브랜치를 만드는 기본 수단은 있지만, 브랜치를 둘러싼 기능 전체를 아직 구체화하지는 못했어요. 예를 들어 도구의 서로 다른 브랜치를 동시에 보고 실행하는 기능이요. 더 넓게 보면, 중앙의 통제를 줄이고 소프트웨어를 함께 개발할 때 까다로운 사회적 문제가 생긴다는 걸 알게 됐어요. 같은 버전의 도구를 공유할지, 각자 별도의 포크를 만들어 갈지 어떻게 합의할까요? 특정 도구의 제품 결정은 누가 내릴까요? 처음 만든 사람이 계속 책임질까요, 아니면 누구나 자유롭게 기여하도록 할까요? 이런 질문이 마법처럼 해결될 수는 없지만, 버전 관리 도구가 도움이 될 거라고 생각해요.

이와 관련된 과제는 품질에 대한 기대를 조율하는 일이에요. 우리가 만든 도구 대부분은 상용 제품의 완성도에 한참 못 미쳐요. 필요에 맞춰 소박하게 만든 개인용 도구들이죠. 도구를 공유할 때 그 품질 수준은 어떻게 전달할 수 있을까요? 도구를 ‘있는 그대로’ 공유하는 것과 지속적인 유지보수를 약속하는 것은 달라요.

Patchwork는 지금도 진행 중인 프로젝트예요. 버전 관리 작업에서 얻은 초기 결과를 랩 노트에 공개했고, 작업이 진전되면 전체 시스템도 더 자세히 소개할 계획이에요. 궁극적으로는 Patchwork를 오픈 소스 도구로 공개할 계획도 있어요.

동적 문서

기반 기술을 연구하면서 소프트웨어를 담아 실행하는 방식에는 새로운 시도를 했지만, 동작 자체는 전통적인 코드로 지정했어요. 그런데 AI의 도움을 받더라도 코드를 쓰는 일은 여전히 사용과 수정 사이의 가파른 ‘절벽’이 된다는 걸 알고 있어요.

그래서 우리 작업의 또 다른 갈래는 프로그래밍 없이 맞춤형 도구를 만들 수 있게 하는 데 집중했어요. 앞서 스프레드시트와 HyperCard 같은 선례를 보여 드렸죠. 직접 조작할 수 있는 정보에서 출발해 선택적으로 프로그래밍을 덧붙이는 접근법을 구현한 사례들이에요.

우리도 동적 문서 연구에서 이 전통을 이어 왔어요. 목표는 사용자가 기존 미디어 문서 위에 동작을 덧붙일 수 있는 새로운 기법을 탐구하는 거예요. 사용자들은 정보를 어떻게 표현해야 상호작용을 더할 수 있을까요? 그리고 도구들은 문서를 공통 바탕으로 삼아 어떻게 협력하고 공존할 수 있을까요? 이런 질문에 답을 찾고자 했어요.

Potluck: 레시피 계획을 위한 동적 일반 텍스트

Potluck에서는 사용자가 텍스트 메모에 동적인 동작을 더하는 방법을 탐구했어요. 레시피의 재료 양을 조절하거나 타이머를 설정하는 식이죠. 사용자는 자연스럽다고 느끼는 어떤 텍스트 문법으로든 정보를 표현한 다음, 텍스트에서 의미 있는 구조를 파싱하는 탐지기를 작성할 수 있었어요.

하지만 Potluck에는 문제가 하나 있었어요. 임의의 일반 텍스트에서 구조를 파싱하는 일이 번거로웠어요. 복잡한 탐지 규칙에 의존하지 않고 관련 정보 사이의 관계, 이를테면 포함 관계나 순서를 표현하기가 어려웠죠.

Embark: 여행 계획을 위한 동적 개요

다음 프로젝트에서는 더 구조화된 접근법을 시도하기로 했어요. 계층형 개요를 기본 형식으로 사용하는 여행 계획 문서 편집기 Embark를 만들었죠. 개요가 제공하는 기초적인 구조 덕분에 Potluck에서 복잡한 패턴을 탐지할 때 겪었던 문제를 일부 해결할 수 있었어요.

구조화된 정보도 핵심 개념으로 추가했어요. Google Maps 장소 같은 객체를 개요 안에서 ‘언급’하고 저장할 수 있었죠. 그러면 경로 계산이나 일기예보 같은 계산의 입력값으로 이런 객체를 사용할 수 있었어요.

Potluck과 Embark에서 공통으로 겪은 큰 과제는 정보를 자유롭게 표현하는 것과 일정한 형식에 맞춰 표현하는 것 사이에서 균형을 찾는 일이었어요. 생각을 형식에 얽매이지 않고 표현할 수 있다는 건 소중해요. 하지만 계산 도구는 대체로 일정한 구조를 갖춘 정보를 다루는 편이 유리하죠. 게다가 데이터 스키마는 사용자 입력에만 국한되지 않아요. Google Maps 장소에는 자체적인 구조화 형식이 있고, 이 형식을 여러 도구에서 사용할 수 있어야 해요.

마지막으로, Potluck과 Embark의 아이디어를 더 일반화해서 더 다양한 작업을 다룰 수 있을지는 아직 확인해야 해요. 각 프로젝트는 범위를 제한하고 실제 사용을 유도하려고 레시피와 여행이라는 구체적인 용도에 기반을 뒀어요. 하지만 앞으로 이 아이디어를 더 일반화하고 Patchwork 같은, 사용자가 바꿀 수 있는 기반 위에 통합해 볼 계획이에요.

• • •

더 나은 미래를 향해

원문 보기

이 글에서 우리는 다른 종류의 컴퓨팅에 대한 비전을 제시했어요. 사람들이 자기 도구를 만들도록 힘을 주고, 작은 공동체에 더 많은 권한을 주며, 사람들이 자기 역량을 최대한 발휘하도록 돕는 컴퓨팅이에요. 그런 컴퓨팅을 구체적으로 어떻게 실현할 수 있을지, 선행 사례와 우리 작업에서 얻은 여러 아이디어도 공유했어요.

동시에 앞으로 닥칠 어려움을 가볍게 볼 생각은 없어요. 앱 중심 컴퓨팅을 다듬는 데 수십 년간 엄청난 노력이 들어갔어요. 새로운 길을 열려면 어려운 질문들을 많이 다뤄야 해요. 우리가 근본적이라고 생각하는 질문 중 몇 가지를 살펴봤죠. 수동적인 사용에서 능동적인 창작으로 이어지는 완만한 경사를 어떻게 만들까요? 앱을 조합 가능한 도구로 어떻게 나눌까요? 협업하는 집단의 요구에 계속 초점을 맞추려면 어떻게 해야 할까요?

이것도 질문의 일부일 뿐이에요. 이 글의 범위에서 대체로 제외한 큰 과제들도 있어요.

개인정보 보호와 보안: 확장 가능한 소프트웨어와 상호운용성을 바라는 마음을, 악의적인 행위자가 존재한다는 현실과 어떻게 조화시킬까요? 기존 소프트웨어가 민감한 데이터에 접근할 수 있는데, 신뢰할 수 없는 낯선 사람들이 그 수정본을 공유한다면 위험한 일이 일어날 수 있어요.

비즈니스 모델: 개발자가 거대한 단일 앱 대신 조합 가능한 도구를 제공한다면, 소프트웨어로 어떻게 돈을 벌 수 있을까요? 지원과 유지보수의 비용은 어떻게 마련할까요?

문화: 디지털 환경이든 그 밖의 환경이든 사람들이 자기 환경을 바꾸고 싶어 하는, 자신의 주도권을 되찾으려는 움직임을 어떻게 키워 갈까요?

만만치 않은 과제들이에요. 기술적 능력만으로 모든 문제를 해결할 수는 없어요. 경제와 문화의 변화도 필요하죠. 하지만 변화는 가능해요. 컴퓨팅의 역사는 아직 짧고, 지난 수십 년 동안 이미 많이 바뀌었어요. 앞으로도 구조적인 변화가 많이 있을 거예요.

여러 종류의 사람이 역할을 할 수 있어요. 컴퓨팅 연구자라면 사용자에게 더 많은 힘을 주도록 컴퓨팅의 근본적인 은유를 다시 상상하기 좋은 때예요. 플랫폼 개발자라면 최종 사용자를 무슨 수를 써서라도 보호해야 할 수동적인 사용자로 보기보다 능력 있는 참여자로 보는 쪽으로 균형을 옮겨 보세요. 보안과 처음 사용할 때의 편리함은 장점이지만, 확장성과 강력한 기능도 장점이에요. 소프트웨어 제품을 만든다면 모든 결정을 정해 주기보다 사용자가 더 많은 일을 직접 결정할 수 있게 하는 방법을 생각해 보세요. 내 손으로 바꿀 수 있는 소프트웨어를 온전히 실현하려면 급진적인 변화가 필요하다고 생각하지만, 점진적인 개선도 도움이 돼요.

어떤 공간에 살거나 일하는 사람들이 자기 필요에 맞춰 도구를 조금씩 발전시키면 특별한 품질이 생겨요. 내 손으로 바꿀 수 있는 소프트웨어는 Palo Alto의 기업들이 외부와 차단된 공간에서 만든 제품처럼 일관된 디자인을 갖추지 못할 수도 있어요. 하지만 시간이 지나면서 오래된 집과 같은 매력이 생긴다고 느껴요. 오늘의 필요에 맞춰 진화하면서도 과거의 쓰임을 보여 주고 지난 결정의 흔적을 간직하죠.

누구에게나 자기 디지털 환경을 발전시킬 권리가 있어야 해요. 점점 더 많은 것이 코드로 정해지는 세상에서, 창의적 잠재력을 실현하고 주도권을 유지하는 중요한 방법이에요. 내 손으로 바꿀 수 있는 소프트웨어를 현실로 만드는 일에 여러분도 함께해 주시길 바라요.

---

진행 중인 리서치 소식을 받아 보려면 이메일 뉴스레터를 구독하세요.