AI는 도구인가 자동화인가, 핵심은 통제의 위치

같은 AI를 두고 서로 다른 정의가 충돌했다

Rich Hickey의 'AI' Is Not a Tool은 LLM 사용을 직접 다루는 도구 사용이 아니라 자동화에 대한 요청으로 구분한다. LinkedIn에 표시된 발행일은 2026년 10월 12일이다. 같은 날 Huahai는 AI Is a Tool. Using It Well Takes Skill.에서 이 구분이 지나치게 단정적이라고 반박했다. 두 글은 실험 결과나 신제품 발표가 아니라 소프트웨어 사용 방식에 관한 논평이다.

Hickey가 강조하는 도구의 핵심은 사용자가 지속적으로 힘과 방향을 가하고 피드백을 받는다는 점이다. 그 과정에서 대상 세계와 작업에 대한 숙련이 생긴다고 본다. 반면 LLM에 요청한 뒤 결과를 받는 방식은 실제 작업을 대신하게 하므로, 도구를 다루는 경험과 같지 않다는 주장이다.

Huahai는 자동화가 도구의 한 속성일 수 있다고 반박한다. 사용자가 소스 코드를 확인하고, 설명에 이의를 제기하고, 변경을 시험하고, 틀린 결과를 거부하는 과정도 목적을 가진 피드백 루프라는 것이다. 불확실성은 중요한 결함이지만 그것만으로 도구라는 범주에서 제외할 이유는 아니라는 입장이다.

양측은 통제의 시간 단위를 다르게 본다

이 논쟁은 단순히 AI에 찬성하느냐 반대하느냐로 정리하기 어렵다. Hickey는 작업이 진행되는 순간의 연속적인 통제와 학습을 강조한다. Huahai는 요청과 결과 검증을 반복하는 더 큰 단위의 통제를 인정한다. 두 사람이 같은 단어를 사용해 서로 다른 상호작용 구조를 말하는 셈이다.

이 표는 두 논평을 실무 질문으로 재구성한 것이다. 어느 방식이 실제로 학습을 더 훼손하는지 입증한 연구 결과를 뜻하지 않는다. 특정 사용자의 생산성과 이해도는 작업 종류와 검증 방식에 따라 따로 측정해야 한다.

또한 컴파일러와 LLM이 모두 자동화 요소를 갖는다고 해서 동일한 신뢰성을 갖는 것은 아니다. 반대로 LLM이 확률적으로 동작한다고 해서 사용자에게 남는 통제가 전혀 없다고 단정할 필요도 없다. 분류 문제와 신뢰 수준의 문제를 분리할 때 토론이 구체적이 된다.

코딩 에이전트에서는 출력과 행동을 나누자

같은 모델도 코드 설명만 하는 경우와 운영 서버를 수정하는 경우의 책임 구조는 다르다. 설명을 읽는 사용자는 원본 코드와 비교해 거부할 수 있다. 반면 에이전트가 외부 시스템을 변경하면 결과를 보기 전에 부작용이 발생할 수 있다. 요청을 사람이 했다는 이유만으로 실행 과정까지 통제했다고 볼 수는 없다.

기업 제품의 경쟁도 이 지점에서 갈린다. 무엇이 바뀔지 미리 보여주는 기능, 변경 근거와 테스트를 제공하는 기능, 실행 범위를 제한하고 취소하는 기능은 모델 점수와 별도의 가치를 만든다. 나델라의 AI 비상 브레이크 분석은 중단 장치를 모델 밖에 두는 문제를 다룬다. 이는 AI를 도구라 부르든 자동화라 부르든 필요한 설계다.

NIST AI 위험관리 프레임워크도 위험을 실제 사용 맥락에서 살피는 참고 자료다. 이름으로 신뢰 수준을 결정하기보다 데이터, 사용자, 권한과 영향을 함께 보아야 한다.

한국 개발팀은 허용 목록보다 작업 계약을 만들자

실무적으로는 AI 사용을 허용 또는 금지하는 한 줄 규칙보다 작업별 계약이 낫다. 예를 들어 코드 설명은 원문 위치를 함께 남기고, 코드 변경은 테스트를 통과해야 하며, 배포는 별도의 권한 경계를 지나도록 설계할 수 있다. 여기서 작업 계약은 법률 용어가 아니라 입력·완료 조건·검증 책임을 명시하는 운영 방식이다.

학습용 작업과 납품용 작업도 구분할 필요가 있다. 입문자가 구현 전체를 맡기는 것과 숙련자가 반복 변환을 맡기는 것은 같은 행동처럼 보여도 잃거나 얻는 경험이 다르다. AI 과제와 구술 평가, HackerRank의 판단 중심 평가가 다루는 설명 능력은 이 구분에 도움이 된다.

성과 측정에서는 AI 사용 횟수보다 완료된 변경과 재작업을 보자. DORA의 전달 성과 지표처럼 속도와 안정성을 함께 살피면, 단지 많이 위임한 사람을 숙련된 사용자로 착각할 가능성을 줄일 수 있다. 이는 논평에서 직접 검증된 결론이 아니라 조직 운영을 위한 제안이다.

두 글을 함께 읽을 이유는 승자를 가리기 위해서가 아니다. 결과를 받아보는 순간에만 개입하는 것인지, 작업의 중요한 경계마다 이해와 통제가 유지되는 것인지 자신의 업무 흐름을 묻게 하기 때문이다.

FAQ

Hickey는 AI가 전혀 유용하지 않다고 주장한 것인가?

핵심 주장은 유용성의 부정이 아니라 직접 다루는 도구와 작업을 대신하는 자동화의 차이다. 유용하다는 이유만으로 둘을 같은 것으로 부르지 말자는 취지다.

Huahai는 LLM을 완전히 통제할 수 있다고 보나?

아니다. 글은 실패와 예측 불가능성을 인정하면서도 검증과 수정이 가능한 활용을 도구 사용으로 볼 수 있다고 주장한다.

이 논쟁으로 생산성 향상 여부를 알 수 있나?

두 글은 논평이다. 생산성이나 학습 효과를 판단하려면 별도의 측정과 비교가 필요하다.

사람 승인이 있으면 통제가 충분한가?

승인할 사람이 변경 내용을 이해할 수 있고, 실행 범위와 결과가 관찰 가능해야 한다. 형식적인 확인 버튼만으로 충분하다고 보기는 어렵다.

개발자는 무엇부터 바꾸면 좋을까?

AI가 만든 결과에 원본 근거와 테스트를 연결하고, 자신이 설명할 수 없는 변경을 구분해 검토하는 것부터 시작할 수 있다.