LLM도 도구다, 잘 쓰는 능력이 결과를 가른다

LLM을 도구로 볼 수 있느냐는 논쟁이 다시 붙었다. Rich Hickey가 2026년 10월 11일 공개한 글에서 LLM은 인간이 휘두를 수 없기 때문에 도구가 아니라 자동화라고 규정하자, yyhh.org에 반론이 올라왔다. 반론의 요지는 단순하다. LLM 역시 인간이 다루는 대상이며, 잘 다루는 데에는 기술이 필요하다는 것이다.

반론 글은 도구의 성질부터 다시 짚는다. 톱을 손에 쥐었다고 반듯한 절단이 나오지 않고, 끌을 들었다고 조각가가 되지 않는다. 도구는 좋은 판단과 나쁜 판단을 똑같이 증폭한다. 쓸모는 그것을 조종하고, 되돌아오는 신호를 해석하고, 실수를 알아채고, 바로잡는 사용자의 능력에 달려 있다. 같은 조건이 LLM에도 적용된다는 것이 반론의 출발점이다.

예측 불가능성은 분명한 한계다. 그러나 예측 가능성, 신뢰성, 단순함, 기능의 범위 제한은 도구를 평가하는 기준이지 도구라는 범주에 들어가기 위한 자격 요건이 아니다. 다루기 어렵거나 오용하기 쉽다는 이유로 도구가기를 그만두지는 않는다.

도구와 자동화를 갈라놓는 구분 자체도 문제로 지적된다. 자동화는 도구의 기능일 수 있다. 컴파일러는 프로그래머가 매 단계를 지시하지 않아도 상당한 작업을 수행하고, 스프레드시트는 누군가 손으로 계산하지 않아도 결과를 다시 뽑아낸다. 그래도 우리는 입력을 정하고 결과를 검토하고 다음에 무엇을 할지 결정하는 방식으로 이 시스템을 다룬다. 코드 번역이나 숫자 계산이 자동이라고 해서 도구가 아니게 되지 않는다면, 텍스트 생성도 마찬가지라는 논리다.

의도와 피드백, 방향, 전문성이 결여된다는 주장도 반박 대상이다. 개발자는 LLM에게 낯선 코드의 설명을 요구하고, 그 설명에 이의를 제기하고, 원본 소스를 확인하고, 제안된 변경을 테스트하고, 거부하고, 요청을 다듬을 수 있다. 이는 목적을 가진 인간이 이끄는 피드백 루프다. 무엇을 물어야 하는지, 어떤 증거가 중요한지, 언제 답이 틀렸는지 아는 능력이 여기에 필요하며, 전문성은 도구를 더 쓸모 있게 만든다.

읽기에 대한 우려는 특정한 사용법에 한해 타당하다. 논문을 읽는 대신 요약을 받아들이면 읽기가 가르쳐 주는 것의 상당 부분을 잃을 수 있다. 하지만 논문을 직접 읽은 뒤 LLM에게 자신의 해석을 검증하거나, 반론을 탐색하거나, 더 자세히 볼 지점을 찾는 데 쓸 수도 있다. 지적 노동을 회피할 가능성이 있다는 사실이 모든 사용이 그렇다는 결론으로 이어지지는 않는다.

글은 의인화된 어휘에도 문제를 제기한다. 'go rogue', 'escape containment', 'conspire' 같은 표현을 반복하면 이 시스템이 독립적인 존재처럼 들리게 만드는 프레임을 받아들이게 된다는 것이다. 소프트웨어가 예상 밖 출력을 내거나 지시를 따르지 않거나, 중대한 권한을 부여받았을 때 피해를 일으키는 것은 실제 엔지니어링 문제다. 이를 음모라고 부르는 것은 인간적인 동기를 암시할 뿐 그런 동기가 있다는 것을 입증하지 않는다.

저자는 LLM이 항상 인간이 시킨 대로만 한다고 주장하지 않는다. 분명히 실패할 수 있다. 그러나 완벽하게 복종하지 못한다는 사실이 도구라는 성질을 없애지는 않으며, 성공적인 사용이 사용자가 판단을 포기했다는 증거가 되지도 않는다. 남는 구분은 하나다. 도구를 능숙하게 다루는 일과, 충분한 이해와 감독 없이 작업을 위임하는 일. 이 구분이 소프트웨어 한 부류 전체를 도구가 아니라고 선언하는 것보다 실용적이라는 것이 반론의 결론이다.