2026년 10월 11일 릭 히키(Rich Hickey)는 "'AI' is Not a Tool"라는 글에서 대형언어모델(LLM)을 도구가 아니라 자동화로 규정했다. 그의 논거는 분명하다. 도구란 사람이 직접 다루며(wield) 그 과정에서 의도와 피드백, 숙련이 개입하는 것인데, LLM은 그런 식으로 다뤄지지 않고 작업을 통째로 넘겨받는다는 것이다. 작업을 외주화하면 배울 기회를 잃는다는 그의 우려 자체는 타당하다. 이번에 소개하는 글은 이 규정에 대한 반론으로, 자동화와 도구 사용은 양립할 수 있으며 LLM을 잘 다루는 일에도 엄연히 기술이 필요하다고 주장한다.
도구를 든다고 결과가 보장되지는 않는다
반론의 출발점은 단순하다. 톱을 쥔다고 직선으로 잘리지 않고, 끌을 들었다고 조각가가 되지 않는다. 도구는 좋은 판단만큼이나 나쁜 판단도 그대로 증폭한다. 결국 도구의 유용함은 사용자가 그것을 겨냥하고, 돌아오는 신호를 해석하고, 실수를 알아채고 바로잡는 능력에 달려 있다. 저자는 이 조건이 LLM에도 똑같이 적용된다고 본다. 한 동료가 "AI는 거울"이라고 말했다는 대목이 상징적이다. LLM은 사용자가 가진 호기심과 판단, 습관을 반영하며, 어떤 질문을 던지고 그 답에 어떤 기준을 들이대느냐가 결과를 좌우한다는 것이다.
히키가 든 LLM의 예측 불가능성은 실제로 중요한 한계다. 다만 저자는 예측 가능성, 신뢰성, 단순함, 기능의 한정성 같은 속성은 도구를 평가하는 잣대일 뿐 도구의 자격 요건은 아니라고 선을 긋는다. 통제하기 어렵거나 오용하기 쉽다는 이유로 도구가 도구이기를 멈추지는 않는다는 논리다.
자동화는 도구의 '기능'일 수 있다
이 글의 가장 설득력 있는 지점은 도구와 자동화를 가르는 이분법 자체를 겨냥한 부분이다. 컴파일러는 프로그래머가 매 연산을 지시하지 않아도 상당한 작업을 수행하고, 스프레드시트는 사람이 계산을 일일이 하지 않아도 결과를 다시 계산한다. 그럼에도 우리는 입력을 지정하고 결과를 살피며 다음 행동을 결정하는 방식으로 이들을 여전히 '다룬다'. 코드 번역이나 수치 계산을 자동으로 해준다고 도구가 아니게 되지 않는데, 텍스트 생성을 자동으로 한다는 이유만으로 도구에서 제외할 근거는 무엇이냐는 반문이다. 자동화는 도구에서 배제되는 성질이 아니라 도구가 품을 수 있는 기능이라는 관점이다.
LLM 사용에 의도와 피드백, 방향성, 전문성이 없다는 주장도 저자는 받아들이지 않는다. 프로그래머는 낯선 코드를 설명해 달라 요청하고, 그 설명을 의심하고, 원본을 들여다보고, 제안된 변경을 테스트해 거부하고, 다시 질문을 다듬을 수 있다. 이것은 명백히 목적을 가진 사람이 주도하는 피드백 루프다. 무엇을 물어야 하는지, 어떤 근거가 중요한지, 언제 답이 틀렸는지를 아는 숙련이 도구의 쓸모를 키운다. 전문성은 사라지는 게 아니라 작동한다.
읽기의 문제와 '의인화 어휘'의 함정
읽기에 대한 히키의 걱정, 즉 논문을 읽는 대신 요약을 받아들이면 읽기가 주는 많은 것을 포기하게 된다는 지적은 특정 사용 방식에 한해 유효하다. 그러나 누군가는 논문을 직접 읽으면서 자신의 해석을 LLM으로 반문하고, 반론을 탐색하고, 더 들여다볼 지점을 찾아내기도 한다. 지적 노동을 회피할 가능성이 존재한다는 사실이 모든 사용이 그 노동을 회피한다는 뜻은 아니다. 중요한 건 그 사람이 실제로 무엇을 하느냐다.
저자가 가장 아쉬워하는 대목은 'AI 업계의 의인화 어휘'에 기대는 태도다. "반란을 일으킨다", "통제를 벗어난다", "공모한다" 같은 표현을 되풀이하면 이 시스템을 독립된 존재처럼 들리게 만드는 프레임을 무심코 받아들이게 된다. 소프트웨어가 예상치 못한 출력을 내거나 지시를 따르지 않거나 중대한 권한을 쥐었을 때 해를 끼치는 것은 실재하는 엔지니어링 문제다. 그러나 이를 '음모'라 부르는 순간 입증되지 않은 인간적 동기가 덧씌워진다.
정리하면 이 글의 실무적 함의는 명확하다. 쟁점은 LLM이 도구냐 아니냐가 아니라, 기술을 갖고 도구를 다루는 것과 충분한 이해나 감독 없이 일을 떠넘기는 것 사이의 구분이다. 이 구분은 AI에 그대로 적용되며, 특정 소프트웨어 전체를 도구가 아니라고 선언하는 것보다 훨씬 실용적인 기준을 준다. 한국의 개발·기획 실무자에게 이 논쟁은 "AI를 쓸 것인가"보다 "어떤 질문과 검증 기준을 들고 쓸 것인가"라는, 결국 사용자 자신의 숙련으로 되돌아오는 문제를 가리킨다.