물리적 공간은 얼마든지 손볼 수 있다. 기타 제작자는 작업대에 톱과 끌을 자기 손에 맞게 배치하고, 필요하면 나무토막을 받침으로 깎아 새 도구를 만든다. 가정 요리사는 여러 해에 걸쳐 자기에게 맞는 칼과 도마, 냄비를 모으고 천장에 고리를 달거나 선반을 옮겨 동선을 다듬는다. 포스트잇 한 장을 벽에 붙이는 작은 조정부터 주방을 통째로 개조하는 큰 변화까지, 누구의 허락도 없이 즉시 시도하거나 지역의 장인에게 도움을 청할 수 있다. 스튜어트 브랜드가 '건물은 어떻게 배우는가'에서 적었듯, 세월과 적응성이 결합할 때 공간은 사랑받는 대상이 된다.
문제는 우리가 점점 더 많은 시간을 원자가 아니라 코드로 지어진 환경에서 보낸다는 데 있다. 대륙을 넘어 즉시 협업하고 수천 개의 파일을 순식간에 검색하는 능력을 얻은 대신, 환경을 내 것으로 바꾸는 능력은 잃어버렸다. 개인용 컴퓨팅이 약속했던 것은 새로운 종류의 점토였지만, 실제로 우리가 받은 것은 멀리서 만들어져 밀봉된 채 바뀌지 않는 '가전제품' 같은 앱이었다는 것이 이 에세이의 출발점이다.
경직된 소프트웨어가 일을 가로막을 때
원문에는 인덱스카드로 작업을 관리하던 한 소프트웨어 팀의 사례가 나온다. 벽에 붙인 카드와 테이프 선을 수시로 옮기며 도구가 유연했기에 프로세스도 유연했다. 그러나 원격 협업을 위해 웹 기반 이슈 트래커로 옮기자, 특별한 카드 구역을 표현할 방법이 없어져 그 프로세스를 아예 포기했고 이후의 개선도 멈췄다. 예전에는 몇 분이면 시도하던 아이디어가 이제는 설정 씨름에 몇 시간이 들거나 아예 불가능해졌다. 업무를 전산화하면서 오히려 주도권을 잃은 셈이다.
이는 사소한 불편이 아니다. 의사이자 작가인 아툴 가완디는 의료 현장의 전산화가 기록적인 번아웃을 부른다고 지적했다. 종이 양식에서는 관련 없는 항목을 건너뛰던 의사들이, 이제는 소프트웨어가 강제하는 필드를 모두 채워야 하고 그 규칙을 고칠 권한은 없다. 가완디가 전한 한 의사의 말처럼, 사람들을 분노하게 만드는 것은 추가로 드는 시간이 아니라 그 무의미함이다.
소프트웨어가 내 필요를 충족하지 못할 때 개발자에게 피드백을 보낼 수는 있지만 즉각적인 조치로 이어지는 경우는 드물다. 사용자마다 요구가 다른데 중앙 개발팀이 이를 모두 감당할 수는 없고, 무리하게 모든 요구를 한 제품에 욱여넣으면 비대해진 엉망이 된다. 그래서 좋은 제품팀은 대부분의 요청을 거절하는 법을 배우고, 그 결과 소수의 틈새 요구는 긴 꼬리로 남는다. 반면 가완디가 소개한 신경외과 의사는 IT 분석가와 협업해 자기 부서에 특화된 더 빠르고 직관적인 인터페이스를 만들었고, 생산성뿐 아니라 도구를 통제한다는 감각 자체가 번아웃의 해독제가 되었다.
설정, 플러그인, 모드로는 부족한 이유
에세이가 제안하는 대안은 '주무를 수 있는 소프트웨어(malleable software)', 즉 누구나 최소한의 마찰로 도구를 자기 필요에 맞게 고칠 수 있는 생태계다. 물론 기존에도 커스터마이징 수단은 있다. 설정은 체크박스 하나로 동작을 바꾸지만 개발자가 미리 노출하기로 한 것만 건드릴 수 있고, 서로 무관한 옵션 목록으로 비대해지기 쉽다. 서드파티 플러그인은 중앙 개발자의 대역폭을 넘어서게 해주고 확장과 앱 사이의 계약을 안정화하는 이점이 있지만, 인가된 확장 지점이 없으면 무력하며 애초에 플러그인 API가 없는 앱이 대부분이다. 설치와 제작 사이의 간극도 크고, 앱마다 플러그인 체계가 달라 공유도 어렵다.
브라우저 확장 같은 '무허가 모딩'은 개발자가 훅을 열어두지 않아도, 심지어 개발자가 반대하는 상황(광고 차단기)에서도 개입할 수 있어 적용 범위가 넓다. 그러나 리버스 엔지니어링이 필요하고 원본 앱이 바뀌면 유지가 어려우며, 서버 측 동작은 손대지 못하는 등 플랫폼의 한계에 묶인다. 오픈소스는 소유와 기여, 자체 포크를 가능하게 하는 중요한 재료지만, 버튼 색 하나 바꾸는 사소한 변경에도 개발 환경 설정과 코드 이해라는 문턱이 있어 '최소한의 마찰'과는 거리가 있다.
AI가 답이 될 수 있을까
자연스레 떠오르는 질문은 AI가 이 모든 것을 자동으로 해결해주느냐다. 대규모 언어 모델은 모호한 자연어 아이디어를 코드로 바꿔주며, 채팅만으로 웹 앱을 만드는 흐름을 만들고 있다. 원문 저자들도 특화된 일본어 번역 앱이나 맞춤 운동 계획을 담은 미니멀 타이머를 직접 만들어 유용함을 확인했다고 밝힌다. 그러나 모든 사람이 코드를 완벽히 쓸 수 있다고 가정해도 남는 질문이 있다. 이미 설치한 도구를 새 사일로 앱을 만들지 않고 어떻게 손볼 것인가, AI가 만든 도구들이 공유 데이터 위에서 어떻게 조합되어 더 큰 워크플로를 이룰 것인가, 그리고 아주 작은 변경마저 매번 AI 코딩에 기대지 않고 어떻게 직접 정밀하게 통제할 것인가. 프롬프트로 클라우드 앱을 생성하는 제품들은 이 질문들에 답하지 않는다.
실무자 입장에서 이 글의 함의는 분명하다. AI 코딩 도구를 오늘날의 폐쇄적 생태계에 들여오는 것은 '푸드코트에 뛰어난 부주방장을 데려오는 격'이라는 비유가 핵심이다. 메뉴에서 완성된 음식을 고르는 구조에서는 아무리 실력 있는 요리사도 손쓸 여지가 없듯, 앱스토어의 폐쇄 소스 소프트웨어를 쓰는 한 AI 어시스턴트가 해줄 수 있는 일도 제한적이다. 평균에서 멀어질수록, 다시 말해 고유한 요구가 강할수록 완성도 높은 대량생산의 이점보다 직접 고칠 수 있는 주도권의 가치가 커진다. 도구 도입을 검토할 때 기능 목록만큼이나 '우리 조직이 이것을 어디까지 다시 빚을 수 있는가'를 따져 물을 이유가 여기에 있다.