도구가 인간의 태도, 행동, 이데올로기를 어떻게 형성하는지, 그리고 기술 업계가 그 책임을 왜 외면해서는 안 되는지 살펴봅니다.
최근 글 발행을 쉬게 된 점 사과드립니다. 가정에는 또다시 온갖 심각한 건강 문제가 닥쳤고, Arca 출시 전이 아니라 출시 후에 이런 일을 겪었다는 데에는 분명 큰 이점이 있다고 인정하겠지만, 그래도 불쾌한 일입니다. 곧 더 규칙적으로 글을 쓸 수 있기를 바랍니다.
기술에 대한 사회 비평 분야에서 일하거나 글을 쓴다면, 기술에 관한 아주 다양한 관점과 의견을 듣게 됩니다. 그중 일부는 당신이 하는 일을 한다는 발상 자체에 놀랄 만큼 적대적입니다. 따라서 당신은 자신의 작업, 아이디어, 관점에 대한 여러 종류의 비판을 매우 자주 마주하게 됩니다. 그중 일부는 대단히 타당하고, 다른 일부는… 그렇지 않습니다.
이런 방식으로 특정 기술을 비판할 때 흔히 나오는 말은 엔지니어들이 어떤 기술은 “그저 도구일 뿐”이라고 말하는 것입니다. 셸, 컨테이너화, 반응형 프레임워크 등 온갖 것에 관해 이런 말을 듣고, 최근에는 LLM 기술을 논할 때 특히 자주 등장합니다. 이 응답이 뜻하는 바는 다음과 같습니다.
이 명제들이 참이라면, 도구나 기술에 대해 유효한 비판은 그것이 설계된 작업을 얼마나 잘 수행하는가뿐입니다. 예컨대 어떤 도구가 나쁜 습관을 가르친다고 말할 수 없습니다. 명시적으로 교육 도구가 아니라면, 그것이 사람들에게 무엇을 가르치는지는 논의 범위를 벗어나기 때문입니다. 마찬가지로 SUV를 운전하면 도로에서 형편없는 운전 행동을 하게 되는 경향이 있다는 사실도 논의할 수 없습니다. 결국 SUV는 “그저 도구”일 뿐이고, 그에 대한 정당한 사용 사례도 있기 때문입니다. 그렇기에 SUV가 이데올로기적·행동적 결과를 낳는다는 사실은 우리가 사실상 논의할 수 없는 것이 됩니다. 도구에 대한 이런 민간적 이해는 매우 흔하지만, 안타깝게도 거의 전부 틀렸습니다.
무언가가 “그저 도구”라고 말하는 것이 왜 정당하지 않은지를 설명하려면, 저명한 나치이자 유감스럽게도 매우 중요한 20세기 철학자이기도 한 Martin Heidegger의 작업에 의존해야 합니다. Heidegger의 주요 저작인 _Being and Time_은 주로 존재론과 죽음을 향한 존재로서의 인간 존재를 다루지만, 그 책과 다른 저작에서 그의 작업 중 상당 부분은 도구의 본성과 존재에 관한 것입니다.
Heidegger는 도구를 다음과 같이 생각합니다. 도구란 어떤 방식으로 인간의 능력을 확장하는 어떤 것, 즉 Heidegger적 의미에서 존재를 지닌 것(반드시 객체일 필요는 없음)입니다. 따라서 도구란 그것이 없었다면 할 수 없었을 일을 하게 해 주는 모든 종류의 것입니다. 여기서 우리에게 중요한 개념적 도약은, 도구가 잘 작동하거나 고장 나지 않았을 때 Heidegger가 “손안에 있음”이라고 묘사한 성질을 갖게 된다는 점입니다. 도구가 제공하는 추가 능력을 지닌 인간과 도구의 인간-도구 게슈탈트가 형성되면서, 도구는 배경으로 사라집니다. 간단한 예로 포크로 식사하는 일을 생각해 봅시다. 포크가 잘 설계되어 있고 고장 나지 않았다면, 저녁을 먹는 동안 의식 속에 명시적으로 “나는 포크를 사용하고 있다”라는 생각이 있지 않습니다. 당신은 그저 먹습니다. 포크로 어떻게 먹는지, 포크로 무엇을 먹을 수 있는지에 담긴 가정은 배경으로 사라져 당연한 것으로 받아들여집니다. 포크가 작동하지 않을 때에만 그것을 명시적으로 알아차립니다. 포크 살 하나가 휘었을 수도 있고, 수프를 먹으려 하는 것일 수도 있습니다. 어느 경우든 도구는, Heidegger의 표현으로는, 거슬리거나 원하는 일을 하는 데 장애물이 될 때에만 눈앞에 있는 것이 됩니다.
하지만 손안에 있는 도구와 함께 형성되는 인간-도구 게슈탈트는 중립적이지 않습니다. 오히려 손안에 있는 각각의 도구는 서로 다른 게슈탈트를 만들며, 허용되고 잠재적인 “할 수 있는 일”의 범위와 그에 수반되는 사고 패턴, 아이디어, 이데올로기도 서로 다릅니다. 예를 들어 포크를 봅시다. 관념적으로는 “그저 도구”이므로 중립적이어야 합니다. 하지만 실제로는 전혀, 정말 전혀 그렇지 않습니다. 사례가 필요하다면, 앵글로색슨 배경을 지닌 나이 든 사람이나 문화적으로 더 보호받으며 살아온 사람을 찾아보세요. 사는 곳에서 그런 사람을 찾기 어렵다면, 다른 음식 문화를 가진 사람으로 바꾸면 됩니다. 그리고 그들을 사천 음식점에 데려가 보세요.
이렇게 말하면 요점은 꽤 분명합니다. 나이프와 포크로 먹을 때 가능한 행위는 젓가락으로 먹을 때 가능한 행위와 상당히 근본적으로 다릅니다. 우선 음식이 어떻게 준비되는지에 대한 가정부터 완전히 다릅니다. 젓가락으로 먹는 손님에게 유럽식 스테이크를 내놓을 수는 없으며, 일반적으로 음식은 젓가락으로 쉽게 집을 수 있도록 조심스럽게 잘라야 합니다. 이는 어떤 종류의 요리가 만들어지는가에도 이어집니다. 많은 사천 음식이 부당하게도 지나치게… 음, 맛있어 보이는 충칭 라쯔지 사진을 보세요.
.jpg)
인간-포크 게슈탈트에게 이것은 감당할 수 없을 정도의 고추입니다. 저 모든 매운맛을 즐길 수 있을 만큼 내성이 있더라도, 이런 차림새의 고추는 여전히 건조하고 먹기에 다소 불쾌합니다. 요컨대 인간-포크 게슈탈트가 만들 음식은 아닙니다. 그러나 인간-젓가락 게슈탈트는 젓가락으로 고추 더미를 헤치고, 은은하게 양념되어 향긋한 닭고기 조각을 집어 들며, 그저… 대부분의 고추를 피할 수 있습니다. 그렇다면 충칭 라쯔지는 실제로는 정말 훌륭한 요리를 정당하고 다소 인상적으로 내놓는 방식이 됩니다. 극단적으로는 이러한 상이한 행위 가능성이 게슈탈트들로 하여금 무엇을 음식으로 여기는지 자체에 대해 서로 다른 생각을 갖게 할 수도 있습니다.
음식의 경우 이는 대체로 흥미로운 요리 문화의 차이로 이어집니다. 물론 인종차별과 그 밖의 불쾌한 일들이 자라나기 좋은 토양이기도 합니다. 하지만 다른 도구의 경우에는… 문제가 생깁니다. 예를 들어 인간-자동차 게슈탈트는 인간-자전거 게슈탈트, 인간-기차 게슈탈트, 심지어 이동 수단이 전혀 없는 순수한 인간과도 상당히 다른 방식으로 삶을 경험하고 의견을 갖습니다. 운전자에게 가능한 것과 바람직한 것은 자동차 밖의 같은 인간에게 가능한 것 또는 바람직한 것과도 꽤 근본적으로 다릅니다. 이런 일이 개별적으로 일어나는 경우를 우리는 난폭 운전이라 부르고, 정책 규모에서는 자전거 도로가 차 안에 있지 않은 모든 때에 자신에게 이득이 될 경우에도 사람들이 자전거 도로에 극도로 분노하는 일로 이어집니다. 인간-자동차 게슈탈트는 게슈탈트 속 인간과 분리된 이해관계와 의견을 가지며, 흔히 인간의 이해관계와 의견에 반대되고 게슈탈트의 인간 부분을 넘어 자신을 관철할 수 있습니다.
그리고 물론 인간-총 게슈탈트, 즉 “총-인간”도 있습니다. 사람의 손에 총을 쥐여 주는 일은 그가 세상을 보는 방식과 자신에게 उपलब्ध하다고 느끼고 좋다고 여길 수 있는 잠재적 행동의 범위를 근본적으로 바꿉니다. 가장 극적으로는 미국의 경찰 활동에서 이를 볼 수 있습니다. 총을 가지면 인간-총 게슈탈트의 일부로서 쏠 이유를 찾도록 성향이 기울게 됩니다. 총이 제공하는 행위 가능성 때문에, 보통이라면 폭력 없이 해결될 수 있는 상황이 총격으로 악화됩니다. 협상과 타협보다 위협과 뜻을 관철하려는 요구가 우선시되고, 잠재적 위협은 세상에서 전경으로 떠오르며, 다른 사람들은 눈에 띄지 않게 조금씩 동료 인간이기를 멈추고 당신이 폭력을 행사할 잠재적 대상이 됩니다.
그러므로 분명히, 무언가가 고장 났거나 방해가 되는 경우가 아니라면 결코 “그저 도구”인 것은 없습니다. 이것만으로도 이 모든 것에 대해 기술 업계가 말하는 방식은 의문에 부쳐집니다. 하지만 그것만으로는 아주 흥미롭지 않으니, 다음 절에서는 외견상 매우 비슷한 두 도구가 어떻게 대단히 다른 게슈탈트와 대단히 다른 행동 가능성을 만들어 내는지 논하겠습니다.
새 글이 올라올 때 가장 먼저 알아보세요! 제 사고에 관한 독점 업데이트와 deadSimpleTech 및 우리 프로젝트 소식을 받으려면 뉴스레터도 구독하세요.
새 글을 받은편지함으로 받아보기 →
이메일을 입력하세요
월간 뉴스레터도 보내 주세요
이런 기술 분석을 마주하면, 기술 업계 사람들은 어떤 이유에서인지 기술 세계의 나머지 전부에 적용되는 고려 사항이 자신들에게만은 적용되지 않는다고 흔히 생각합니다. 이런 터무니없는 오만 때문에 우리가 지금 이토록 많은 곤경에 빠져 있는 것이지만, 그래도 요점을 제대로 전달하려면 이러한 역학이 특히 기술 세계에서 어떻게 작동하는지 분명히 설명하는 편이 좋겠습니다.
이 글에서는 웹 인터페이스를 구축하는 데 흔히 사용되는 두 반응형 프레임워크인 Vue와 React를 살펴보겠습니다. 이들은 우리 목적에 이상적입니다. 대략 같은 작업을 쉽게 하도록 목표하지만, 설계 선택과 철학에는 충분한 차이가 있어 도구의 차이가 인간 영역에서 서로 다른 게슈탈트를 어떻게 만드는지 볼 수 있습니다.
이를 보이기 위해 React와 Vue에서 각각 동일한 구성 요소를 어떻게 만드는지 살펴봅시다(제가 여기에서 찾은 기본 양식을 골랐습니다).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import React, { useState } from "react"; function NameForm() { const [value, setValue] = useState(""); return ( <form> <input value={value} onChange={(e) => setValue(e.target.value)} placeholder="Enter name" /> <p>You entered: {value}</p> </form> );}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<template> <form> <input v-model="value" placeholder="Enter name" /> <p>You entered: {{ value }}</p> </form></template><script>export default { data() { return { value: "", }; },};</script>
이 두 구성 요소는 정확히 같은 일을 합니다. 입력란과 그 아래에 입력한 값을 표시하는 문단 태그가 있는 양식을 만듭니다. 하지만 두 프레임워크가 만드는 게슈탈트는 매우 다릅니다.
우선 각 구성 요소가 어떤 종류의 객체로 제시되는지부터 볼 수 있습니다. React는 즉시 JSX로 작성된 함수를 제시합니다. 우리가 상호작용하는 구성 요소는 함수입니다. HTML, CSS 등은 함수가 반환하며, React를 작성할 때는 우선 JavaScript로 사고하고 HTML은 사실상 결과물로만 내보낼 것이 기대됩니다. 이는 React에서 바인딩이 작동하는 방식에도 이어집니다. 바인딩은 값이 바뀔 때마다 템플릿 변수의 값을 양식 입력값으로 설정하라는 명령형 명령으로 명시적으로 제시됩니다. 이는 매우 JavaScript다운 사고방식입니다.
반대로 Vue는 먼저 HTML 문서를 제시합니다. 제시되는 구성 요소는 필요한 JavaScript가 <script> 태그에 유기적으로 포함된 HTML입니다. 이 구성 요소의 바인딩은 선언적이고 양방향입니다. 문단 텍스트에 변경 시 _무엇을 할지_가 아니라 그것이 _무엇인지_를 말합니다. 일반적으로는 주로 HTML 관점에서 사고하고, 작성하는 JavaScript의 양은 대체로 최소한으로 유지할 것이 기대됩니다.
믿기 어렵겠지만, 사물을 바라보는 이 두 방식은 정확히 같은 엔지니어가 사용해도 매우 다른 도구 게슈탈트를 낳습니다. 이는 “이 프로젝트에서 누가 당신과 함께 일해야 하는가?”라는 기본 질문에서 시작됩니다. React는 React 구성 요소를 편집하려면 거의 모든 것에 JavaScript를 알아야 하므로, 답이 “다른 JavaScript 소프트웨어 개발자”여야 한다고 거의 요구합니다. 즉 React 팀을 꾸릴 때는 개발 기술을 가진 사람에게 집중하게 됩니다. HTML과 CSS에는 전문가지만 코드 작성에는 능하지 않은 사람은 게슈탈트에 의해 배제됩니다. 실제로 React는 디자인 작업이나 일반적인 CSS 작성 작업을 덜 강조하는 경향이 있으며, 개발자를 Tailwind 같은 해결책으로 밀어 넣습니다.
반대로 Vue는 서로 다른 기술을 가진 사람을 위한 공간을 더 엽니다. HTML은 알지만 JavaScript는 모르거나 CSS에 뛰어난 사람은 자신이 아는 Vue 구성 요소의 3분의 2를 편집하고 <script> 태그는 건드리지 않을 수 있으므로, JavaScript를 알아야 한다는 요구에 막히지 않고 효과적으로 기여할 수 있습니다. 이는 팀에 두고 싶은 사람의 범위를 넓힙니다. 디자이너, 접근성 전문가, 시맨틱 HTML 전문가 등 Vue를 쓰는 팀이 활용할 수 있지만 React를 쓰는 팀에는 아예 없을 수 있는 기술의 폭이 넓습니다. 그리고 중요한 점은, 이 중 어느 것도 도구 자체가 직접 요구하는 것은 아니라는 것입니다. 누군가 조심한다면 가령 React 구성 요소에 포함된 HTML 블록을 편집할 수 있습니다. 하지만 게슈탈트가 내놓는 제약은 도구 자체가 내놓는 제약보다 훨씬 강하며, 웹 개발 작업에 누가 참여해야 하고 누가 참여해서는 안 되는지에 대한 이데올로기적 믿음까지 만들어 냅니다. 그리고 실제 피해를 만드는 것은 바로 그것입니다.
그 요소를 넘어 보면 React와 Vue는 구성 요소 개발에서 무엇을 _중요한 것_으로 우선시하는지가 다릅니다. Vue에서는 HTML과 CSS가 일급 요소이므로, Vue 게슈탈트는 구조, 레이아웃, 표현을 생각하도록 장려합니다. 앱은 문서적인 일을 수행하고 JavaScript로 상호작용성을 관리할 수 있는 대화형 문서로 생각됩니다. React는 반대 패턴으로 향하는 경향이 있습니다. 즉 앱은 계산을 수행하는 것이며, HTML과 CSS는 계산 결과를 사용자에게 제시하는 데 사용됩니다. 그러므로 이 게슈탈트들은 그러한 입장을 뒷받침하는 태도와 이데올로기를 발달시킬 것이고, 중요하게도 그 이데올로기는 좋든 나쁘든 더 일반적인 기술 이데올로기의 일부가 됩니다.
이 접근법들 중 어느 것도 본질적으로 틀리거나 본질적으로 더 낫지는 않습니다. 하지만 분명히 태도와 세계관을 매우 크게, 그리고 결코 중립적이지 않은 방식으로 형성합니다. JavaScript를 만들 수 없는 사람의 전문성이 존중받지 못한다면, 그 결과 앱의 사용성과 접근성에는 심각한 부정적 결과가 생깁니다. 어떤 사람은 포함되고 다른 사람은 배제될 것입니다. 그리고 누가 포함되고 누가 배제되는지는 이 도구가 작동하는 사회적 영역에서 이미 권력을 가진 사람들을 포함하고, 그들이 어떤 방식으로든 “열등하다”고 여기는 사람들을 배제하는 방향으로 흐르기 쉽습니다. 이 모든 것이 도구 선택 하나에서 나옵니다.
기술 업계의 상당 부분, 업계가 하는 일, 그리고 업계가 제시하는 태도와 이데올로기는 바로 이런 종류의 게슈탈트 역학으로 형성된다고 생각합니다. 이미 존재하는 이데올로기에 의해 형성된 우리가 만드는 도구는, 그것이 만드는 게슈탈트 안에서 그 이데올로기와 태도를 재생산합니다. 특히 React/Vue의 분기는 많은 기술 도구에서 재현되는 것으로, 개발자 우월주의의 이데올로기입니다. React, Kubernetes, Docker, 대단히 많은 Linux 배포판 전반, 그리고 대부분의 클라우드 제공자처럼 서로 매우 동떨어진 도구들에 반복되는 생각은 소프트웨어 개발자가 일을 하는 방식이 _마땅히 일을 해야 하는 방식_이며, 과업에 대한 다른 접근법은 필연적으로 열등하다는 것입니다. 즉 한편으로 HTML을 더 쓰고 다른 한편으로 JavaScript를 더 쓰는 선택지가 생기면, 하려는 일에 실제로 좋은 관용구인지와 무관하게 선택은 언제나 JavaScript 쪽으로 기울 것입니다(Tailwind CSS는 React와 JSX가 표준 CSS와 잘 어울리지 않아서 주로 생긴 문제를 해결하려는 시도에 아주 가깝습니다). 이는 개발자가 대충 해도 쉬운 도구를 만들기 쉽지만, 가령 디자이너나 UX 전문가에게는 다루기 어려울 수 있습니다. 여기서 불길한 점은 이것이 스스로를 재생산하는 경향이 있다는 것입니다. 개발자가 다루기 쉬운 도구는 예를 들어 HTML이나 CSS를 작성하는 일이 _낮은 위상의 개발 작업_이라는 생각을 미묘하게 강화하는 경향이 있습니다. 어떤 상황에서는 그럴 수 있지만, 이는 개발 도구인 만큼이나 디자인 도구입니다. 그러면 디자이너, UX 전문가, 접근성 및 SEO 전문가와 그런 종류의 모든 사람은 미묘하게 종속적 위치로 밀려납니다. 도구가 개발자가 일을 잘못하도록 설계되어 있어서, 그들이 도구에 부딪혀 튕겨 나가기 때문입니다. 이 사람들을 위한 도구는 더 유용한 게슈탈트를 만들고, 그들에게 더 나은 위상과 전반적으로 더 좋은 결과를 가져올 것이라고 상상할 수 있습니다. 하지만 기존 관행은 도구가 만들어 낸 것이며, 너무 강하게 이를 거스르기 때문에 상황을 바꾸려면 실제 노력이 필요하고, 그래서 대부분의 사람은 그러지 않습니다. 그렇게 순환은 스스로를 재생산합니다.
명백히 제 생각에는, 도구가 기술에 존재하는 엄청난 수의 사회적·문화적 문제를 직접 만들어 내지 않았더라도, 그 손안에 있음이 바로 그 문제들을 재생산하도록 향해 있다는 사실만으로도 문제를 재생산하고 정당화하는 데 크게 관여하는 상황에서는, 무언가가 “그저” 도구라고 말하는 것이 최선의 생각은 아닐 수 있습니다.
여기까지 했으니 처음 질문으로 돌아갈 수 있습니다. 무언가가 “그저 도구”라고 말하는 것이 왜 그토록 잘못되었을까요? 도구가 자신이 일부가 되는 게슈탈트, 그리고 그 게슈탈트의 인간 부분이 지니는 이데올로기에 미칠 수 있는 영향을 생각하면, 무언가는 도구일 수 있습니다. 하지만 실제로 도구는 정말, 정말 중요합니다. 기술 업계의 우리는 대체로 우리 자신과 다른 사람들이 무언가를 하도록 도구를 만드는 일을 합니다. 그러므로 우리는 어떤 종류의 도구를 만드는지에 매우, 매우 신중해야 합니다. 개인의 번영과 사회적 조화를 뒷받침하는 게슈탈트를 만드는 경향이 있는 도구를 만들거나, 둘의 균형을 맞출 수 없다면 서로에 대한 필요와 다른 고려 사항을 신중히 저울질하는 도구를 만들어야 합니다.
우리 업계는 그 생각과 상당히 반대로, 이 두 가지 모두에 파괴적인 도구를 만드는 경향이 있었습니다. 사람들을 서로 고립시키고 대규모 허위 정보 확산의 매개체가 된 소셜 미디어 네트워크를 만들었습니다. 막대한 규모의 사기와 기만을 가능하게 한 암호화폐를 만들었습니다. 최악의 종류의 편견을 강화하는 분류 알고리즘을 만들었습니다. 그리고 물론 이 모든 일을 하고 그 밖에도 온갖 사악한 짓을 하는 망할 LLM도 있습니다.
LLM은 특히 중요한 사례입니다. 도구 사용이 아주 이상한 게슈탈트를 형성하는 것을 꽤 직접적으로 볼 수 있기 때문입니다. 가장 극단적인 경우 이를 인공지능 정신병이라 부릅니다. 게슈탈트의 태도, 이데올로기, 심지어 _세계 인식_이 우리가 합리적이라고 여기는 것에서 너무 크게 벗어나기에, 우리는 이를 질병이라고 부릅니다. 이와 같은 일을 관찰하면서 도구가 사용하는 사람의 태도, 경험, 세상 속 존재 방식을 실제로는 근본적으로 형성하지 않았다고 말하기는 분명 어렵습니다. 그러므로 이 글에서 설명한 현상은 아주 분명하게 일어나며, 이 하나의 도구에서 그토록 극적이고 명백하게 일어날 수 있다면, 훨씬 더 넓은 범위의 기술에서 더 미묘하고 광범위한 결과를 기대하는 편이 현명할 것입니다.
이 시점에서 사람들은 어떤 방식으로 “나쁜” 도구가 선하고 유익한 일에 쓰인 수많은 사례를 지적할 것입니다. 제가 해롭다고 여기는 프레임워크와 언어가 많은 선을 행한 도구를 만드는 데 사용된 적도 있습니다. LLM도 이 시점에서는 꽤 많은 유용한 도구를 만드는 데 쓰였습니다. 젠장, 저조차 사용해 보았을 때 어느 정도 성공을 거두었습니다. 이는 모두 타당한 주장입니다. 하지만 게슈탈트 틀에서는 실제로 요점을 반박하지 못합니다. 도구가 좋은 일에 사용될 수 있고 실제로 필요할 수도 있지만, 그럼에도 그것이 조성하는 관점은 장려해서는 안 되는 것일 수 있습니다. 결국 온갖 놀라운 무기 체계가 우크라이나에서 자유와 민주주의를 지키는 데 쓰이고 있으며, 이는 선하고 필요한 일입니다. 하지만 그렇다고 해서 지도자가 폭탄과 포병에 접근할 수 있게 되었을 때의 영향이나 개인이 화기에 접근할 수 있게 되었을 때의 영향이 ceteris paribus 해롭지 않게 되는 것은 아닙니다. 총을 들거나 SUV를 운전하면 일반적으로 인간 생명에는 별 관심이 없는 비사회적 인간쓰레기가 될 성향이 더 강해집니다. 이 경향에 맞서 싸우는 것은 충분히 가능하고 실제로 많은 사람이 그렇게 하지만, 이러한 도구의 게슈탈트 논리는 여전히 나쁜 쪽을 향합니다.
이는 예를 들어 비영리 단체가 잘되도록 돕는 유용한 소프트웨어를 만들기 위해 LLM을 사용하고, 생성된 코드 중 실제로 배포될 것을 매우 신중히 검토하며, 글자 그대로 코드의 모든 줄을 읽는다 해도, 모든 단계에서 당신의 게슈탈트와 그에 따른 태도와 이데올로기를 부주의와 조잡함 쪽으로 밀어붙이는 도구의 손안에 있는 본성과 여전히 싸우고 있다는 뜻입니다. 그렇다고 이것이 절대로 올바른 선택이 아니라거나 이 도구를 절대로 사용해서는 안 된다는 말은 아닙니다. 앞서 말했듯, 총이 일반적으로 태도에 나쁜 영향을 준다고 생각하더라도 침략군에 맞서 싸우는 일은 대체로 지지합니다. 하지만… 그런 도구를 쓸 것이라면, 자신이 무엇을 하는지 알고 매우 조심해야 할 책임은 당신에게 있습니다. 장기간 사용하면 반드시 세상을 보는 방식이 바뀐다는 사실을 알고 이를 완화할 보호 장치를 마련해야 합니다. 곁다리로 흥미로운 관찰이 하나 있는데, 정규 군대는 화기에 관해서는 이런 완화에 상당한 노력을 기울이는 경향이 있는 반면 경찰 조직은 종종 그렇지 않습니다. 일반적으로 그런 타협은 가능한 한 드물게 해야 하며, 마주한 문제가 그런 방식의 타협이 타당할 만큼 심각할 때에만 해야 합니다.
우리가 이 도구들을 그저 사용하기만 했다면, 이를테면 React와 Vue가 인간의 손을 거치지 않은 채 자연에서 발견한 것이라면, 이는 경계해야 할 도구와 기술 전반에 관한 불행한 사실일 수 있습니다. 하지만 우리가 이 도구들을 만듭니다. 기술에서 어떤 도구를 개발할 때든 우리는 그것이 어떤 형태를 취할지, 어떤 행위 가능성을 제공할지, 어떤 게슈탈트를 형성할지 결정합니다. 우리는 어떤 타협을 할지 선택해야 할 뿐만 아니라, 업계로서 다른 사람과 우리 자신에게 어떤 타협이 가능한지 대체로 결정합니다. 그리고 전체적으로 우리는 꽤 나쁜 선택을 했습니다. 세상에 깊이 해롭고, 그 결과 오늘날 우리가 대체로 그 결과 속에서 살아가고 있는 선택들입니다.
그러므로 기술 업계 사람이 무언가를 “그저 도구”라고 말하는 것을 들으면, 업계로서 우리가 세상에 내놓는 것과 스스로에게 하는 일에 책임지기를 꺼리는 태도로 읽지 않을 수 없습니다. 안타깝게도 도구는 기술 세계의 많은 이들이 바라는 중립적이고 분리된 존재일 수 없습니다. 그렇지 않은 척하는 것, 더 나아가 도구의 영향을 받은 사람들에게 그들이 단지 _잘못 사용하고 있다_고 말하는 것은, 가능한 한 해를 끼치지 말아야 한다는 우리의 도덕적 의무를 저버리는 일입니다. 우리는 정말 더 잘해야 합니다.
이 글 아래에 작은 광고가 하나 있는 것을 보게 될 것입니다. Arca는 어떤 면에서 도구와 도구가 우리에게 하는 일에 유의하는 방식으로 기술을 가르치려는 제 시도입니다. 아직 성공했을까요? 모르겠습니다. 하지만 그 방향으로 상당한 진전을 이루었다고는 확신합니다. 가입해서 확인해 보세요!
