세상에 '그냥 도구'란 없다

TMT

https://deadsimpletech.com/blog/no-such-thing-as-just-a-tool

기술에 대한 사회 비평을 업으로 삼거나 그런 글을 쓰다 보면 기술에 관한 온갖 견해와 의견을 듣게 되는데, 그중에는 이런 일을 한다는 발상 자체에 놀랄 만큼 적대적인 반응도 있습니다. 그러다 보니 자신의 작업과 생각과 관점에 대한 갖가지 비판을 자주 접하게 되는데, 어떤 비판은 매우 타당하지만 어떤 비판은... 글쎄요.

이런 식으로 특정 기술을 비판할 때 엔지니어들이 으레 내놓는 대답이 있습니다. 그 기술은 "그냥 도구일 뿐"이라는 말입니다. 셸, 컨테이너화, 반응형 프레임워크 등 온갖 주제에서 이 말을 듣게 되고, 최근에는 LLM 기술을 논할 때 특히 자주 나옵니다. 이 대답이 뜻하는 바는 대략 다음과 같아 보입니다.

  • 논의되는 기술은 그것을 쥔 사람의 태도나 이데올로기와 무관하다. 쓰든 안 쓰든 이데올로기적으로 중립이다.
  • 논의되는 기술은 그것을 쓰는 사람과 사실상 분리할 수 있다. 어떤 기술을 쓰는지를 보고 그 사람에 대해 무언가를 추론할 수는 없다.
  • 기술은 온전히 의식적으로 사용된다. 자신이 기술을 쓰고 있다는 사실을 언제나 또렷이 인식하고 있으며, 언제든 다른 기술로 갈아탈 완전한 의지의 자유가 있다.
  • 기술은 그것으로 하게 될 일의 종류에 영향을 주지 않는다. 기술을 쓴다고 해서 특정 행동이 다른 행동보다 더 부추겨지지는 않는다. "총이 사람을 죽이는 게 아니라 사람이 사람을 죽인다"는 식이다.

이 말들이 참이라면, 도구나 기술에 대해 할 수 있는 타당한 비판은 설계된 과업을 얼마나 잘 수행하느냐 하나만 남게 됩니다. 예를 들어 어떤 도구가 나쁜 습관을 가르친다는 말은 할 수 없게 됩니다. 명시적인 교육용 도구가 아닌 이상, 그 도구가 사람들에게 무엇을 가르치는지는 논의 범위 밖으로 밀려나기 때문입니다. 마찬가지로 SUV 운전이 도로에서 몹쓸 운전 행태를 부추기는 경향이 있다는 사실도 논할 수 없습니다. 어쨌든 SUV는 "그냥 도구일 뿐"이고 정당한 사용처도 있으니까요. 사정이 이렇다 보니 SUV가 이데올로기와 행동 양쪽에 결과를 남긴다는 사실은 사실상 입에 올리면 안 되는 이야기가 됩니다. 도구를 이렇게 이해하는 통념은 아주 흔하지만, 안타깝게도 거의 전부 틀렸습니다.

무언가를 "그냥 도구일 뿐"이라고 말하는 것이 왜 부당한 수인지 설명하려면, 이름난 나치이자 안타깝게도 20세기의 매우 중요한 철학자이기도 한 마르틴 하이데거의 작업에 기대야 합니다. 하이데거의 대표작 『존재와 시간』은 주로 존재론과, 죽음을 향한 존재로서의 인간 존재를 다루지만, 이 책을 비롯한 여러 저작에서 하이데거가 다룬 내용의 상당 부분은 도구의 본성과 존재에 관한 것입니다.

하이데거는 도구를 이렇게 생각합니다. 도구란 어떤 식으로든 인간 능력의 확장에 해당하는 무언가입니다(하이데거적 의미에서 존재를 지닌 것이면 되고, 꼭 물체일 필요는 없습니다). 따라서 도구는 그것이 없었다면 못 했을 일을 할 수 있게 해 주는 모든 종류의 것입니다. 우리에게 중요한 개념적 도약은 여기서 나옵니다. 도구가 잘 작동하거나 고장 나지 않았을 때, 도구는 하이데거가 "손안에 있음(ready-to-hand)"이라고 부른 성질을 띠게 됩니다. 도구가 배경으로 사라지면서, 도구가 부여한 추가 능력을 갖춘 인간이라는 일종의 인간-도구 게슈탈트가 형성되는 것입니다. 간단한 예로 포크로 식사하는 경우를 생각해 봅시다. 포크가 잘 설계되어 있고 고장 나지 않았다면, 저녁을 먹는 동안 "나는 포크를 쓰고 있다"는 생각이 의식에 뚜렷이 떠오르지 않습니다. 그냥 먹을 뿐이고, 포크로 어떻게 먹는지, 포크로 무엇을 먹을 만한지에 새겨진 전제들은 배경으로 물러나 당연한 것으로 받아들여집니다. 포크를 뚜렷이 의식하는 것은 포크가 제 역할을 못 할 때뿐입니다. 갈퀴 하나가 휘었거나, 포크로 수프를 먹으려 할 때 말입니다. 어느 쪽이든 도구는 거슬리는 것이 될 때, 즉 하려는 일에 방해물이 될 때에야 비로소, 하이데거의 표현으로 "눈앞에 있음(present-at-hand)"의 상태가 됩니다.

그런데 손안에 있는 도구와 함께 형성되는 인간-도구 게슈탈트는 중립적이지 않습니다. 오히려 손안에 있는 도구는 저마다 다른 게슈탈트를 만들어 내고, 그에 따라 허용되고 가능한 "할 수 있는 일"의 범위도 달라지며, 거기에 딸려 오는 사고 패턴과 관념과 이데올로기도 달라집니다. 포크를 예로 들어 봅시다. 포크는 명목상 "그냥 도구일 뿐"이니 중립이어야 마땅합니다. 그런데 정말이지 전혀 그렇지 않습니다. 예시가 필요하다면, 앵글로색슨 문화권 출신 중에 나이가 지긋하거나 문화적으로 바깥 경험이 적은 사람을 찾아서(사는 곳에서 그런 사람을 찾기 어렵다면 그 지역 기준으로 다른 음식 문화권 사람으로 대신해도 됩니다) 쓰촨 음식점에 데려가 보십시오.

이렇게 놓고 보면 요점은 꽤 분명해집니다. 나이프와 포크로 먹을 때 열리는 어포던스(affordance)는 젓가락으로 먹을 때의 어포던스와 상당히 근본적으로 다릅니다. 우선 음식을 어떻게 준비하는지에 대한 전제부터 완전히 다릅니다. 젓가락으로 식사하는 손님에게 유럽식 스테이크를 낼 수는 없고, 음식은 대체로 젓가락으로 집기 쉽도록 미리 정성껏 잘라 두어야 합니다. 이는 어떤 요리가 만들어지는지로 이어지는데, 예컨대 많은 쓰촨 음식이 터무니없이... 뭐랄까, 말로 하는 대신 이 맛있는 충칭 라쯔지 사진을 한번 보시죠.

Image

인간-포크 게슈탈트에게 이 고추 양은 감당이 안 되는 수준입니다. 저것을 다 즐길 만큼 매운맛에 강하다 해도, 이런 형태로 올라온 고추는 퍼석해서 먹기에 다소 불쾌합니다. 요컨대 인간-포크 게슈탈트라면 만들지 않았을 요리입니다. 반면 인간-젓가락 게슈탈트는 젓가락으로 고추 더미를 뒤져 가며, 은은하게 매콤하고 향이 밴 닭고기 조각만 골라내고 고추 대부분은 그냥... 피해 가면 됩니다. 그렇게 보면 이 충칭 라쯔지는 실은 아주 훌륭한 요리를 정당하고 꽤 인상적으로 담아낸 한 접시가 됩니다. 극단적으로는 이런 어포던스 차이가 두 게슈탈트로 하여금 아예 무엇을 음식으로 칠지에 대한 생각까지 다르게 만들 수 있습니다.

음식에 한정하면 이런 차이는 대체로 요리 문화의 흥미로운 차이로 이어질 뿐입니다(물론 인종주의를 비롯한 온갖 불쾌한 일이 자라나기 좋은 토양이기도 합니다만). 하지만 다른 도구들로 가면... 문제가 생깁니다. 예를 들어 인간-자동차 게슈탈트는 인간-자전거 게슈탈트나 인간-기차 게슈탈트, 심지어 아무 이동 수단도 없는 맨몸의 인간과도 삶을 사뭇 다르게 경험하고 다른 의견을 갖습니다. 운전자에게 가능하고 바람직한 것은, 같은 사람이 차 밖에 있을 때 가능하고 바람직한 것과 비교해도 상당히 근본적으로 다릅니다. 이것이 개별 사건으로 터지면 로드 레이지(road rage)라고 부르고, 정책 차원으로 가면 자전거 도로가 차에 타고 있지 않은 모든 순간에는 자신에게도 이득인데도 자전거 도로에 극도로 분노하는 사람들 같은 현상으로 이어집니다. 인간-자동차 게슈탈트는 게슈탈트 안의 인간과는 별개인 이해관계와 의견을 가지며, 그것은 종종 인간과 대립하고, 게슈탈트의 인간 부분을 눌러 가며 관철되기도 합니다.

그리고 물론 인간-총 게슈탈트, 이른바 "총 든 인간(gun-man)"이 있습니다. 사람 손에 총을 쥐여 주면 세상을 보는 눈이, 그리고 자신이 취할 수 있고 좋아 보이는 잠재적 행동의 범위가 근본적으로 달라집니다. 이를 가장 극적으로 보여 주는 것이 미국의 치안 활동입니다. 총을 갖고 있으면 인간-총 게슈탈트의 일부로서 쏠 이유를 찾는 쪽으로 기울게 됩니다. 평소라면 폭력 없이 풀릴 수 있었을 상황이 총이 제공하는 어포던스 때문에 총격으로 번집니다. 협상과 타협보다 위협과 밀어붙이기가 우선하게 되고, 잠재적 위협이 세상 속에서 도드라져 보이게 되며, 다른 사람들은 알아차리지 못할 만큼 조금씩 같은 인간이기를 멈추고 내가 폭력을 행사할 수도 있는 잠재적 대상이 되어 갑니다.

그러니 분명, 고장 났거나 거치적거리는 도구라면 모를까, 그 무엇도 "그냥 도구일 뿐"인 적은 없습니다. 이것만으로도 기술 업계가 이 문제를 이야기하는 방식 전체에 의문을 던지기에 충분하지만, 그것으로 끝내면 별로 재미가 없으니, 다음 절에서는 겉보기에 아주 비슷한 두 도구가 어떻게 매우 다른 게슈탈트와 매우 다른 행동 가능성을 만들어 내는지 살펴보겠습니다.

React와 Vue: 도구는 게슈탈트의 행동 자유를 어떻게 빚어내는가

안타까운 사실이지만, 이런 식의 기술 분석을 마주하면 기술계 사람들은 무슨 이유에서인지 기술 세계의 말 그대로 나머지 전부에 적용되는 고려 사항이 자기들에게만은 적용되지 않는다고 생각하곤 합니다. 이런 오만방자함이야말로 우리가 지금 이 수렁에 이토록 깊이 빠져 있는 이유이기도 합니다만, 그래도 요점을 제대로 전달하려면 이 역학이 기술 세계에서 구체적으로 어떻게 작동하는지 짚어 두는 편이 좋겠습니다.

이 글에서는 웹 인터페이스 구축에 널리 쓰이는 두 반응형 프레임워크, Vue와 React를 살펴보겠습니다. 이 둘은 우리 목적에 안성맞춤입니다. 대략 같은 과업을 돕는 것을 목표로 하면서도 설계 선택과 철학의 차이가 충분히 커서, 도구의 차이가 인간 쪽에 어떻게 다른 게슈탈트를 만들어 내는지 확인할 수 있기 때문입니다.

이를 보여 주기 위해 똑같은 컴포넌트를 React와 Vue에서 각각 어떻게 만드는지 살펴봅시다(여기에서 찾은 기본 폼을 골랐습니다).

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>
  );
}
<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 문서를 먼저 내밉니다. 제시된 컴포넌트는 HTML이고, 필요한 JavaScript는 <script> 태그 안에 자연스럽게 담겨 있습니다. 이 컴포넌트의 바인딩은 선언적이고 양방향입니다. 문단 텍스트의 값에게 바뀔 때 무엇을 하라가 아니라 네 값은 이것이다라고 말해 주는 방식입니다. 전반적으로 HTML 위주로 사고하고, 작성하는 JavaScript의 양은 최소한으로 유지하리라는 기대가 깔려 있습니다.

믿기지 않으실지 몰라도, 이 두 가지 사고방식은 완전히 같은 엔지니어가 다루더라도 매우 다른 두 도구 게슈탈트로 귀결됩니다. 출발점은 "이 프로젝트에서 누구와 함께 일해야 하는가?"라는 기본적인 질문입니다. React는 그 답이 "다른 JavaScript 소프트웨어 개발자들"이기를 거의 강요합니다. React 컴포넌트를 수정하려면 거의 모든 일에 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의 갈림은 수많은 기술 도구에서 반복되는 구도인데, 그 정체는 개발자 우월주의(developer supremacy) 이데올로기입니다. React, Kubernetes, Docker, 상당수의 Linux 배포판 전반, 그리고 대부분의 클라우드 사업자처럼 서로 한참 동떨어진 도구들에 걸쳐 반복되는 이 관념은, 소프트웨어 개발자가 일하는 방식이 곧 일이 마땅히 이루어져야 하는 방식이며 다른 접근은 필연적으로 열등하다는 것입니다. 그래서 HTML을 더 쓸지 JavaScript를 더 쓸지 선택의 기로에 서면, 그것이 지금 하려는 일에 실제로 잘 맞는 방식인지와 무관하게 선택은 언제나 JavaScript 쪽으로 기웁니다(Tailwind CSS는 React와 JSX가 표준 CSS와 매끄럽게 어울리지 못한 데서 비롯된 문제를 해결하려는 시도 그 자체라고 해도 과언이 아닙니다). 그 결과 개발자가 대충 해치우기는 쉽지만 디자이너나 UX 전문가가 다루기는 어려운 도구들이 만들어지곤 합니다. 여기서 음험한 지점은 이것이 자기 재생산된다는 것입니다. 개발자가 다루기 쉬운 도구는, 예컨대 HTML이나 CSS 작성이 지위 낮은 개발 잡무라는 인식을 은근히 강화합니다(상황에 따라 그럴 수도 있지만, 둘은 개발 도구인 만큼이나 디자인 도구입니다). 그러면 디자이너, UX 전문가, 접근성 전문가와 SEO 전문가 같은 사람들이 슬그머니 종속적인 위치로 밀려납니다. 도구가 개발자들이 그 일을 대충 하도록 설계되어 있어서, 이들은 도구에 튕겨 나가다시피 하기 때문입니다. 이런 사람들을 위해 만들어진 도구라면 더 쓸모 있는 게슈탈트를 만들고, 이들의 지위도 높이고, 전반적인 결과도 좋게 만들리라 상상해 볼 수 있지만, 도구가 만들어 낸 기존 관행이 그 방향을 워낙 세게 밀어내는 탓에 상황을 바꾸려면 상당한 노력이 들고, 그래서 대부분은 하지 않습니다. 그렇게 악순환은 다시 반복됩니다.

사정이 이렇습니다. 설령 기술계에 존재하는 무수한 사회적, 문화적 문제를 도구가 직접 만들어 낸 것은 아니라 해도, 도구는 자신의 손안에 있음이 그 문제들의 재생산을 정면으로 겨냥하고 있다는 점에서 문제의 재생산과 정당화에 깊이 관여하고 있습니다. 이런 상황에서 무언가를 "그냥" 도구라고 말하는 것은 아무래도 좋은 생각이 아니라고 저는 봅니다.

그래서, 무언가를 "그냥 도구일 뿐"이라고 말하는 것이 왜 문제인가?

여기까지 왔으니 이제 처음 질문으로 돌아갈 수 있습니다. 무언가를 "그냥 도구일 뿐"이라고 말하는 것이 대체 왜 그렇게 문제일까요? 도구가 자신이 속하게 되는 게슈탈트에, 나아가 그 게슈탈트의 인간 부분이 갖게 되는 이데올로기에 얼마나 큰 영향을 미칠 수 있는지 생각하면, 무언가가 도구인 것은 맞을지 몰라도 실은 도구야말로 정말, 정말 중요합니다. 기술계에 있는 우리가 하는 일이 대체로 우리 자신과 다른 사람들이 무언가를 하는 데 쓸 도구를 만드는 일이라면, 어떤 종류의 도구를 만들지에 대해 매우, 매우 신중해야 마땅합니다. 개인의 번영과 사회적 화합을 뒷받침하는 게슈탈트를 만들어 내는 도구를 만들어야 하고, 둘의 균형을 맞출 수 없다면 양쪽의 필요와 그 밖의 고려 사항들을 신중하게 저울질하는 도구를 만들어야 합니다.

그런데 우리 업계는 그런 생각과는 정반대로, 이 두 가지 모두를 파괴하는 도구를 만들어 온 편입니다. 사람들을 서로에게서 고립시키고 허위 정보를 대규모로 퍼뜨리는 매개체가 된 소셜 미디어 네트워크를 만들었습니다. 어마어마한 규모의 사기와 기만을 가능하게 한 암호화폐를 만들었습니다. 최악의 편견을 강화하는 분류 알고리즘을 만들었습니다. 그리고 물론 그 망할 LLM이 있습니다. 방금 말한 짓을 전부 하는 데다, 그 밖에도 온갖 사악한 짓을 하는 물건입니다.

LLM은 특히 중요한 사례입니다. 도구 사용이 아주 기묘한 게슈탈트를 형성하는 모습을 꽤 직접적으로 목격할 수 있기 때문입니다. 가장 극단적인 경우를 우리는 AI 정신증(AI psychosis)이라고 부릅니다. 게슈탈트가 갖는 태도와 이데올로기, 심지어 세계에 대한 지각까지가 우리가 합리적이라고 여기는 것에서 너무 멀리 벗어난 나머지 질병이라는 이름이 붙는 지경입니다. 이런 것을 목격하고서도 도구가 사용자의 태도와 경험과 세계 속에서 존재하는 방식을 극적으로 빚어놓은 것이 아니라고 말하기는 당연히 어렵습니다. 그렇다면 이 글에서 설명한 현상은 분명히 실제로 일어나는 일이고, 이 도구 하나에서 이렇게 극적이고 뚜렷하게 일어날 수 있다면, 훨씬 넓은 범위의 기술에서 더 미묘하고 광범위한 결과가 나타나리라 예상하는 편이 온당합니다.

이쯤 되면 사람들은 어떤 의미에서 "나쁜" 도구가 좋고 유익한 일에 쓰인 사례를 잔뜩 들이댈 것입니다. 제가 해롭다고 여기는 프레임워크와 언어들이 많은 선을 행한 도구를 만드는 데 쓰였습니다. LLM도 지금까지 꽤 여러 유용한 도구를 만드는 데 쓰였습니다. 뭐, 저조차 써 봤을 때 어느 정도 재미를 본 적이 있으니까요. 모두 타당한 논거지만, 게슈탈트의 관점에서 보면 이런 사례가 요점을 반박하지는 못합니다. 도구가 좋은 일에 쓰일 수 있다는 것, 심지어 꼭 필요할 수 있다는 것과, 그럼에도 그 도구가 길러 내는 관점은 부추기지 말아야 한다는 것은 얼마든지 양립할 수 있습니다. 우크라이나에서는 온갖 놀라운 무기 체계가 자유와 민주주의를 지키는 데 쓰이고 있고 이는 좋고도 필요한 일이지만, 그렇다고 해서 폭탄과 포를 손에 쥔 것이 지도자에게 미치는 영향이나 총기를 손에 쥔 것이 개인에게 미치는 영향이, 다른 조건이 같다면(ceteris paribus) 해롭다는 사실이 사라지지는 않습니다. 총을 들고 다니거나 SUV를 몰면 대체로 사람 목숨에 별 관심 없는 반사회적 인간이 되는 쪽으로 기울기 쉬워지고, 이 경향에 맞서 싸우는 것도 얼마든지 가능하며 실제로 많은 사람이 그렇게 하고 있지만, 이 도구들의 게슈탈트 논리는 여전히 나쁜 쪽으로 밀어붙입니다.

그러니 예를 들어 LLM으로 비영리 단체 운영에 보탬이 되는 유용한 소프트웨어를 만들 때, 생성된 코드 중 무엇을 실제로 배포할지 아주 신중하게 가려낼 때조차(말 그대로 코드를 한 줄 한 줄 다 읽는다 해도), 게슈탈트를, 그리고 그에 따라 태도와 이데올로기를 부주의와 조잡한 결과물(slop) 쪽으로 걸음걸음 밀어붙이는 도구의 손안에 있음이라는 본성과 내내 싸우고 있는 셈입니다. 그렇다고 이것이 결코 옳은 판단일 수 없다거나 그 도구를 절대 쓰면 안 된다는 말은 아닙니다. 앞서 말했듯 저는 총이 대체로 사람의 태도에 나쁜 영향을 준다고 생각하면서도 침략군에 맞서 싸우는 일은 대체로 지지합니다. 다만... 그런 도구를 쓸 것이라면, 자신이 무엇을 하고 있는지 알고 매우 조심해야 할 책임이 따릅니다. 오래 쓰면 세상을 보는 눈이 반드시 바뀐다는 사실을 인식하고, 이를 누그러뜨릴 보호 장치를 마련해 두어야 합니다(여담이지만 정규군은 총기에 관해서는 그런 완화 조치에 꽤 공을 들이는 반면 경찰 조직은 그러지 않는 경우가 많다는 점이 흥미로운 관찰거리입니다). 이런 타협은 대체로 가능한 한 드물게 해야 하고, 직면한 문제가 그런 식의 타협이 말이 될 만큼 심각하게 나쁠 때에만 해야 합니다.

우리가 이 도구들을 그저 사용하기만 하는 처지라면, 가령 React와 Vue가 사람 손을 타지 않은 채 자연에서 발견된 것이라면, 이는 도구와 기술 전반에 관한, 우리가 경계해야 할 안타까운 사실 정도로 그쳤을지 모릅니다. 하지만 이 도구들은 우리가 만듭니다. 기술계에서 어떤 도구를 개발할 때 우리는 그것이 어떤 모양을 가질지, 어떤 어포던스를 제공할지, 어떤 게슈탈트를 형성할지 결정합니다. 우리는 우리가 어떤 타협을 할지 선택해야 할 뿐 아니라, 업계로서 다른 사람들과 우리 자신에게 어떤 타협이 선택지로 주어질지까지 대부분 좌우합니다. 그리고 우리는 전반적으로 꽤 나쁜 선택을 해 왔습니다. 세상에 깊이 해로운 선택들이었고, 그 결과 오늘날 우리는 대체로 그 대가를 치르며 살아가고 있습니다.

그래서 저는 기술계 사람이 무언가를 "그냥 도구일 뿐"이라고 말하는 것을 들으면, 우리가 세상에 내놓은 것과 우리가 우리 자신에게 하는 일에 대해 업계 차원의 책임을 지지 않으려는 태도로 읽을 수밖에 없습니다. 안타깝게도 도구는 기술 세계의 많은 이들이 바라는 것처럼 중립적이고 분리된 무언가일 수가 없습니다. 그렇지 않은 척하는 것은, 하물며 도구에 영향받는 사람들에게 그저 잘못 쓰고 있을 뿐이라고 말하는 것은, 가능한 한 해를 끼치지 않아야 한다는 우리의 도덕적 의무를 내팽개치는 일입니다. 우리는 정말 더 잘해야 합니다.

이 글 아래에 작은 광고가 보일 텐데요. Arca는 어떤 의미에서, 도구와 도구가 우리에게 하는 일을 의식하면서 기술을 가르쳐 보려는 저의 시도입니다. 성공했느냐고요? 모르겠습니다. 다만 그 방향으로 의미 있게 나아갔다고는 확실히 믿습니다. 가입해서 직접 확인해 보세요!

Edit this page