AI는 도구이며, 잘 쓰려면 기술이 필요합니다

AI 요약

Rich Hickey는 LLM을 사람이 직접 다루는 도구가 아니라 자동화로 봐야 한다고 주장합니다. 이 글의 저자는 일을 맡기면 배울 기회를 잃을 수 있다는 우려에는 동의하지만, 그 결론이 LLM을 도구의 범주에서 제외하지는 않는다고 반박합니다. 톱을 든다고 반듯하게 자를 수 있는 것은 아니듯 도구는 사용자의 판단을 대신하지 않습니다. 도구를 잘 쓰려면 방향을 정하고, 결과를 해석하고, 실수를 알아차려 수정해야 합니다. 저자는 이 조건이 LLM에도 적용된다고 봅니다.

도구와 자동화

예측 가능성, 신뢰성, 단순성, 기능의 한정성은 도구를 평가하는 기준이지 도구가 되기 위한 조건은 아니라고 설명합니다. 제어하기 어렵거나 오용하기 쉽다고 도구가 아닌 것은 아닙니다. 자동화와 도구도 양자택일 관계가 아닙니다. 컴파일러는 프로그래머가 매 동작을 지시하지 않아도 작업을 수행하고, 스프레드시트는 계산을 자동으로 다시 합니다. 그렇더라도 사람은 입력을 지정하고 결과를 살핀 뒤 다음 행동을 결정합니다. 텍스트 생성을 자동으로 한다는 이유만으로 LLM을 도구에서 제외할 근거가 없다는 논리입니다.

LLM을 다루는 과정

프로그래머는 LLM에 낯선 코드를 설명해 달라고 요청한 뒤 설명에 이의를 제기하고, 소스 코드를 확인하며, 제안된 변경을 시험하거나 거절하고, 요청을 다듬을 수 있습니다. 이 과정에는 사람이 세운 목적과 피드백이 있습니다. 무엇을 물을지, 어떤 근거를 확인할지, 어느 지점에서 답이 틀렸는지 알려면 전문성이 필요합니다. 논문을 읽지 않고 요약만 받아들이면 읽기를 통해 배우는 기회를 잃을 수 있지만, 논문을 읽은 뒤 해석을 점검하거나 반론을 탐색하는 데 LLM을 쓸 수도 있습니다. 지적 노력을 피하는 사용이 가능하다는 사실만으로 모든 사용이 그런 것은 아니며, 실제로 사용자가 무엇을 하는지가 관건이라고 설명합니다.

예상치 못한 출력과 의인화

LLM이 예측하기 어렵다는 점은 분명한 한계입니다. 저자는 명령을 완벽하게 따르지 못하는 실패도 인정합니다. 다만 그 실패가 도구라는 지위를 없애지는 않는다고 주장합니다. 한편 AI 업계가 쓰는 "통제에서 벗어나다", "탈출하다", "공모하다" 같은 표현은 소프트웨어에 사람과 같은 동기가 있는 듯한 인상을 줄 수 있다고 지적합니다. 예상하지 못한 출력, 지시 불이행, 중요한 행동 권한을 줬을 때 생기는 피해는 실제 엔지니어링 문제입니다. 저자는 이를 사람의 의도를 암시하는 표현으로 부르려면 근거가 필요하다고 봅니다. 글의 마지막 구분은 능숙하게 도구를 다루는 것과 이해나 감독이 부족한 채 일을 위임하는 것입니다.

Hacker News 반응

• @troupo — "잘 쓰는 기술"이 무엇인가요? 반복해 검증하거나 다른 사람도 적용할 수 있는 구체적인 사례가 있나요? 컴파일러는 같은 입력에 같은 결과를 내지만 LLM은 그렇지 않습니다. 톱이나 끌도 실제 기법을 익히면 반듯하게 자르거나 조각할 수 있습니다. 이 짧은 글은 제목의 전제를 제대로 다루지 않습니다.
  • @shahbaby — 이번 주말에 LLM 하나가 전체 맥락을 가진 채 작업하는 편이 일을 나눠 여러 LLM에 병렬로 맡기는 것보다 대체로 낫다는 점을 배웠습니다. 전에 읽은 원칙이었지만 제가 하던 작업에서 확인하고 나서야 체감했습니다. 에이전트 사이에 맥락을 어떻게 넘길지, 언제 나눌지를 아는 데도 기술이 필요합니다.
  • @troupo — 모델 업데이트는 내일도 있을 수 있습니다. 그때마다 달라지는 판단은 검증할 수 없는 직감에 불과합니다.
• @extr — 한동안은 원하는 방향의 결과를 얻으려면 작업 흐름을 조정하고 섬세하게 지시해야 했습니다. 지금은 맥락 관리나 특별한 지시문을 크게 신경 쓰지 않아도 됩니다. 현재 남은 기술은 대체로 무엇을 물어야 하는지 아는 일입니다. 디자인 용어를 몰라 구체적으로 수정 요청을 못 하고 시행착오를 겪기도 합니다. 모델이 더 나아지면 이런 우위도 사라질 수 있습니다.
  • @ModernMech — 성공이 무엇인지, 어떤 모습이어야 하는지 구체적이지 않다면 거의 어떤 결과든 맞다고 할 수 있겠네요.
• @shoebilyas_hanz — 제 경험상 주말 개인 프로젝트에는 AI가 좋습니다. 애플리케이션을 확장하는 시점에는 엔지니어링을 이해하는 사람이 필요합니다. 엔지니어의 기술과 전문성에 AI의 속도를 더하는 방식이 가장 잘 맞습니다.
• @smy20011 — 복잡한 코드베이스를 배우고 여러 해결책을 시험하며 복잡한 시스템의 한계를 이해하려 할 때 AI는 훌륭한 도구입니다. 하지만 많은 사람은 AI를 소원을 들어주는 기계처럼 쓰고 생각을 맡깁니다.
  • @FreePalestine1 — 그런데 그 방식도 통합니다. 그게 문제입니다. LLM이 이제는 충분히 잘합니다. 사람은 가장 수고가 적은 길을 좋아하니 지루한 일에서 생각을 외주 주지 않으리라고 기대할 수 없습니다.
• @modo_ — Codex와 Claude Code에는 UI에서 잘 드러나지 않는 기능이 많습니다. 작업에 맞는 노력 수준을 고르고, 하위 에이전트를 쓸지 판단하고, 여러 대화를 병렬로 진행하는 법을 알아야 합니다. 몇 달 전과 같은 방식으로 작동하는지도 계속 확인해야 합니다. 익힌 세부 기술이 낡을 수는 있지만, 지금 도구가 할 수 있는 일과 대부분 사용자가 끌어내는 일 사이에는 여전히 차이가 있습니다.
  • @ForHackernews — 그래서 특정 AI 작업 흐름을 배우는 데 시간과 노력을 많이 들일 가치가 없다고 봅니다. "프롬프트 엔지니어링"과 "Ralph loops"를 기억하나요? 몇 년 뒤 상황이 안정될 때까지 여러 도구를 시험하되 Claude Code를 SQL처럼 깊이 배우지는 않겠습니다.
• @senderista — 원칙적으로 AI를 대리인 대신 도구로 쓰는 일은 가능합니다. 하지만 널리 쓰이는 AI 인터페이스는 사용자의 생각을 돕기보다 대신 결정하도록 계속 유도합니다. Claude가 선택지나 근거를 제시하고 제가 결정하도록 하려면, 제가 직접 일을 처리하지 말라고 계속 막아야 합니다.
• @im_down_w_otp — 제게 AI는 도구보다 슬롯머신에 가깝습니다. 도구에는 명확하고 반복 가능한 원인과 결과가 있어, 원하는 상태에 어떻게 도달할지 조금씩 조정할 수 있습니다. 슬롯머신은 운이 좋으면 결과를 얻습니다. 계속 손잡이를 당기면 원하는 결과를 얻을지도 모르고 아닐지도 모릅니다.
  • @tomrod — 처음 회전 샌더를 쓸 때도 비슷했습니다. 한동안은 무서웠지만 경험을 쌓으면 더 안정적으로 쓸 수 있습니다. LLM에도 적용된다고 생각합니다.

원문: yyhh.org / 번역·요약: Trawling