▲

AI는 기존 기술 역량에 곱셈 효과를 준다

 (joshwcomeau.com)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • AI 모델은 많은 프로그래밍 작업에서 충분히 쓸 만하지만, 개발자를 대체하기보다 기존 기술 역량을 증폭하는 도구에 가까움
  • LLM이 모든 규모의 프로젝트를 완전히 설계·구축해 인간 개발자가 곧 필요 없어질 것이라는 증거는 보이지 않음
  • Matt Perry는 Motion 작업에서 Q1 목표 60개 이슈를 넘어 160개를 닫고, Q2용 대규모 리팩터링도 1월 어느 오후에 끝냄
  • 개발 경험이 적은 사용자의 vibe-coding은 MVP 이후 막히기 쉬우며, 아키텍처 판단과 도메인 지식이 결과 차이를 만듦
  • AI는 Iron Man의 슈트처럼 강력하지만 스스로 같은 성과를 내지는 않으며, 구조화된 학습과 숙련도가 활용 효과를 좌우함

Matt Perry의 생산성 사례

  • Matt Perry는 Popmotion, Motion One, Motion(구 Framer Motion) 등 여러 애니메이션 라이브러리를 만든 개발자임
  • Motion의 레이아웃 프로젝션 엔진은 정교한 엔지니어링 결과물임
  • Matt Perry는 2026년에 AI 활용을 강화했고, Q1 목표였던 이슈 60개 종료를 넘어 160개를 종료함
  • Q2에 하려던 Motion의 대규모 리팩터링도 1월 어느 오후 한 번에 끝냄
  • LLM 자체가 최고의 인간 개발자보다 뛰어나다기보다, 숙련된 개발자가 AI를 사용할 때 생산성이 크게 증폭될 수 있음을 보여줌

도메인 지식이 부족한 vibe-coding의 한계

  • /r/vibecoding에는 개발 경험이 거의 없거나 적은 사람들이 vibe-coding 경험을 공유하며, MVP 이후 단계에서 막히는 경우가 많음
  • 안내 없이 사용되는 LLM은 개별 프롬프트를 해결하는 코드 생성에 집중하고, 애플리케이션 아키텍처를 전체적으로 보지 못해 막다른 길로 들어가기 쉬움
  • 숙련된 개발자는 AI로 할 수 있는 일을 증폭하지만, 도메인 지식이 부족한 사용자는 “MVP” 단계를 넘어서기 어려워짐
  • 같은 AI 도구를 쓰더라도 결과는 같지 않으며, 사용자의 판단력과 구조적 이해가 핵심 차이를 만듦

AI를 도구로 보는 사고방식

  • AI는 도구이며, 도구는 능숙하게 다뤄야 효과가 남
  • Jimi Hendrix의 기타, Gordon Ramsey의 주방, Serena Williams의 테니스 라켓을 갖는다고 같은 결과를 낼 수는 없음
  • 사람들은 도구의 중요성을 과대평가하는 경향이 있으며, 마케팅은 Michael Jordan의 “air technology” 운동화가 덩크 능력을 줄 것처럼 이런 편향을 활용함
  • AI 에이전트는 의인화되어 도구로 보기 더 어렵고, 자율 로봇처럼 대하면 실제보다 더 큰 공로를 부여하게 됨
  • 더 적절한 비유는 Iron Man의 슈트임: 놀라운 일을 가능하게 하지만, 스스로 작동해 같은 성과를 내는 존재는 아님
  • Matt Perry가 Motion 저장소 접근권과 LLM 도구를 넘겨줘도, 같은 속도로 움직이려 하면 같은 결과가 아니라 큰 혼란을 만들 가능성이 큼
  • 숙련된 개발자가 LLM으로 해낸 일을 볼 때 핵심 요인은 LLM 자체보다 숙련된 개발자의 역량임

Whimsical Animations와 구조화된 학습

  • Whimsical Animations는 새로 출시된 웹 애니메이션 강좌임
  • 약 20년 동안 웹사이트와 웹 애플리케이션을 만들며 기억에 남고 영향력 있는 애니메이션과 인터랙션을 만드는 방법을 축적함
  • 웹 개발자를 대상으로 한 애니메이션 자료는 많지 않아, 게임 개발 분야의 개념을 웹에 맞게 적용해 왔음
  • 선형 보간, simplex noise, delta time 같은 개념은 일반적인 웹 개발자 기술 범위에 잘 포함되지 않지만, 프로젝트를 돋보이게 만들 수 있음
  • ChatGPT 같은 도구로 새 주제를 배우기는 쉬워졌지만, 효과적으로 배우려면 무엇을 질문해야 하는지 알아야 함
  • 강좌는 다양한 기법을 소개하는 큐레이션된 커리큘럼을 제공함
  • 커스텀 강좌 플랫폼이 업데이트되어 모든 연습문제와 코드 스니펫을 로컬에서 실행할 수 있게 됨
  • 로컬 실행 지원으로 평소 사용하는 코딩 환경과 워크플로에서 챌린지를 완료할 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 지난주에 UI 디자인을 바이브 코딩하면서 옆 화면에는 컴포넌트 테스트를 띄워둔 채 Iron Man 같은 순간을 겪었음
    요소를 옮기고, 강조를 줄이고, 레이아웃 선택지를 탐색하라고 지시하면서 반복했는데, 거의 실시간 루프처럼 돌아가서 굉장했음
    생성된 코드는 끔찍했지만, 혼자서는 못 했을 디자인에 쉽게 수렴했고, 이후 그 참조 디자인을 보고 더 나은 코드로 직접 구현할 수 있었음

    • 내가 전문가인 영역은 쓰레기처럼 보이고, 전문가가 아닌 영역은 괜찮아 보였던 게 우연이 아닐 수도 있음
      디자이너들은 반대로 “Claude Design Studio가 쓰레기 UI를 만들었지만, 내가 직접 고쳤고 대신 내가 못 짰을 훌륭한 코드를 만들어줬다”고 말할 수 있음
    • 며칠 전 Tailwind 스레드에서는 많은 프레임워크의 의도된 경험이 쓰기 전용 코드라고 들었으니, 이게 받아들여야 할 미래일지도 모름
      어떻게 연결됐는지 걱정하지 말고, 작동하면 된 거고 멈추면 AI에게 고치라고 하면 된다는 식임
      해방감이 있긴 한데, 아직 이걸 받아들이는 AI 열반에 도달했는지는 모르겠고 그 순간이 가까운 것 같기는 함
    • 이게 얼마나 지식의 관성에 기대는 건지 궁금함
      지금은 기본 기술을 이해하고 직접 만들 수도 있지만, 어딘가에 정리 가능한 엉망 코드가 있다는 걸 알면서도 빠른 반복을 선택하는 단계임
      “어떻게 되어야 하는지”의 대략적인 형태를 알고 자동화 프레임워크를 그쪽으로 유도할 수 있기 때문에 가능한 일이고, 특히 직접 만든 프로젝트에서는 더 그렇다 봄
      기업들이 충분히 오래 버티면 그 지식이 완전히 사라지고 도구만 남게 되며, 그때는 Iron Man이 아니라 iron lung에 가까워짐
    • 이제 어떤 작업이 비싸고 어떤 작업이 싼지 다시 배워야 함
      프로토타입은 사실상 공짜에 가까워졌고, AI에게 아키텍처나 스타일 선택지를 각각 시도하게 한 뒤 어떤 코드가 더 마음에 드는지 보면 됨
      재작성과 재설계도 꽤 잘 먹히는 편이라, 여러 해법을 바이브 코딩으로 만든 뒤 접근법을 고르고 테스트를 보강하고 큰 리팩터링으로 유지보수 가능하게 만드는 패턴을 좋아함
      여기서 필요한 능력은 좋은 아키텍처가 무엇인지 알고, 어떤 테스트 수준이 피드백 주기를 빠르게 하거나 LLM 변경을 읽기 쉽게 만드는지 프롬프트와 검증을 설계하는 능력임
    • 내가 도달한 모델도 비슷함: 먼저 시스템 아키텍처가 어떻게 보여야 하는지에 대한 스킬 템플릿을 만들고, LLM에게 그 지침을 따르라고 시킴
      100% 따르지는 않지만 충분히 괜찮은 결과가 나오고, 이후 생성물을 검토해 템플릿에 맞추며 마음에 드는 아이디어는 다시 스킬 템플릿에 추가함
      이건 시스템 아키텍처뿐 아니라 백엔드, 프론트엔드, 종단 간 테스트, 문서 작성에도 적용됨
      원하는 목표와 코드 조직 방식, 테스트 작성 방식을 알고 있기 때문에 LLM은 매번 같은 템플릿을 따르는 지루함을 줄여주는 역할을 함
      다만 지속적인 감독이 필요하고, 건드리지 말라고 한 부분을 건드리거나 지시를 따르지 않을 때도 있으며, 출력량이 압도적일 수 있어 동료 검토는 여전히 필요함

  • AI 도구로 작업을 가속할수록, 유용한 소프트웨어를 출시하는 일이 실제로 얼마나 어려운 장인 기술인지 더 실감함
    Claude Code와 Codex가 대부분의 코드를 써줄 수는 있지만, 무엇을 어떻게 만들지 결정하는 데 필요한 기술 지식은 여전히 막대함
    지금 Claude Artifacts처럼 사용자 정의 HTML+JS 앱을 더 큰 애플리케이션 안의 iframe 샌드박스에서 안전하게 실행하는 시스템을 만들고 있는데, 이게 왜 유용하고 가능한지 이해하려면 샌드박싱, 보안 위협, 브라우저 보안 모델, 수십 년간 진화한 여러 플랫폼 기능에 대한 깊은 지식이 필요함
    그런 이해 없이 바이브 코딩만 하는 사람은 LLM이 아무리 안내해도 이런 것을 존재하게 만들 가능성이 거의 없음
    AI 때문에 경력을 그만두겠다고 말하는 개발자들을 보면 슬픈데, 기존의 깊은 기술 경험이 어느 때보다 가치 있어진 시점이기 때문임

    • AI와 상호작용하는 경험 자체가 끔찍함
      코드를 쓰는 건 좋아하지만, 기계가 올바른 코드를 쓰게 하는 마법 주문을 찾거나, 틀렸을 때 고치는 일은 좋아하지 않음
      이런 미래가 올 거라고 들었다면 이 분야에 들어오지 않았을 것 같음
      또 이 도구들이 만들어진 방식은 내 기준으로는 도둑질이고, 비윤리적으로 만들어진 도구를 쓰는 것 자체도 비윤리적이라고 봄
      게다가 더 가치 있는 기술에 대해 돈을 더 받을 수 있을지도 불확실하고, 엔지니어 임금은 전반적으로 내려가는 중임
      고용주가 모든 가치를 가져간다면 내가 더 많은 가치를 만든다는 사실에 관심 가질 이유가 없음
    • 이 관점은 신선하고 내 경험과도 맞음
      주변의 많은 소프트웨어 엔지니어들이 AI가 일자리를 가져갈 거라고 결론 내리고 이미 전직을 생각하지만, 아직 판단하기엔 이르다고 느낌
      내가 쓰는 프롬프트는 전부 매우 기술적이고, 내 전문성 없이 에이전트와 대화만으로 처리하기는 어려움
      전문 영역 밖의 일을 할 때마다 사람들이 상상하는 만큼 빠르지 않고, 전문성은 질서를 유지하는 데 큰 도움이 됨
    • 하지만 고위 임원들은 그렇게 생각하지 않음
      그들이 AI가 엔지니어를 대체할 수 있다고 믿으면 그렇게 흘러갈 가능성이 크고, 품질이 무엇인지 임원들이 제대로 아는 경우도 드묾
      그들은 매출과 이익만 보니, 깊은 기술 경험이 더 가치 있다는 말은 맞아도 현실은 슬프게도 그렇게 안 될 수 있음
    • 몇 년을 들여 쌓아온 “경력”을 그냥 그만둘 수는 없음
      아마 점진적으로 실업 상태로 밀려나게 될 것 같음
    • 훌륭한 아이디어와 훌륭한 제품 사이에는 엄청난 장인정신이 필요하다고 예전에 썼다가 많은 비추천을 받았음
      LLM은 현실에서 이 사실을 바꾸지 못함
      그래서 고부가가치 제품이 폭발적으로 늘지 않은 것이고, 애초에 가치를 만드는 제품을 만드는 일은 매우, 매우 어려움
      LLM이 있다는 이유로 이걸 가볍게 보는 태도는 우습게 느껴짐

  • “AI 도구가 Iron Man 슈트에 가깝다”는 말에 대해, GitHub 별 63,600개짜리 흥미로운 저장소가 있음
    개발자는 GitHub 주간 인기 기여자 1위지만, 애플리케이션은 설명된 것과 달라 보이고, 개발자들도 이게 진짜인지 명확히 답하지 못하는 듯함
    결국 지저분한 LLM 출력일 뿐이라는 점에서, 슈트만으로는 Iron Man이 될 수 없음을 보여줌
    https://github.com/ruvnet/RuView
    https://github.com/trending/developers?since=weekly
    https://github.com/deletexiumu/wifi-densepose

    • 세 AI 시스템인 Claude, Codex/GPT-5.2, Gemini의 교차 검증을 포함한 독립 코드 감사를 통해 이 프로젝트가 동작하지 않는 껍데기라고 확인했다는 문구가 있음
      AI가 만든 비동작 프로젝트를 AI가 비동작이라고 증명하는 셈이라, 참 멋진 신세계임
    • ruvnet 전체가 좀 섬뜩함
      여러 프로젝트가 있는데 그냥 AI 출력이 아주 많고, GitHub 인프라를 범람시키는 느낌이라 GitHub가 왜 힘들어하는지 이해하기 쉬움

  • 수학자로서 지난주에 나도 Iron Man 순간을 겪었음
    몇 년간 교수인 친구 둘과 공동 수학 연구를 하고 있었고, 연구 일부를 ChatGPT로 탐색해봤음
    생각이 떠오르면 GPT에 제시하고, 증명하기 쉬운 정리를 쓰게 한 뒤 증명을 LaTeX로 만들게 했고, 증명은 항상 조심스럽게 확인했음
    이어 Mathematica 코드를 생성하게 하고, 실행 결과로 증명을 검증하거나 더 많은 아이디어를 얻어 다시 반복했음
    중간에 특정 식의 상계를 잡지 못해 이해가 부족했던 부분은 종이와 연필로 직접 다시 유도하니 큰 도움이 됨
    전체 과정은 GPT 없이 할 때보다 약 10배 빨랐고, 몇 시간 뒤에는 올바른 증명 20쪽 정도와 관련 수치 시뮬레이션에 필요한 코드가 모두 생겼음

  • AI는 능력의 배수가 아니라 시간을 줄이는 도구라고 봄
    경험이 적은 개발자에게는 프로젝트 초반부터 즉시 시간을 줄여주지만, 초기 결정이 나중에 발목을 잡을 가능성이 큼
    시니어 개발자에게는 설명만 충분히 해주면 즉시 능력 범위 안의 일을 처리하는 주니어 또는 중급 개발자처럼 작동함
    다만 중요한 결정을 맡기면 완전히 틀리거나 미묘하게 틀릴 수 있고, 특히 미묘한 오류는 발견하기 어려워 가장 위험함
    시니어가 지침을 잘 세우고 문제를 알아차릴 수 있다면 개발 속도는 정말 말도 안 되게 빨라짐

    • 꼭 그렇지만은 않음
      배우고자 하는 마음이 있다면 AI는 기술을 다듬고 익히는 데 걸리는 시간을 줄여주고, 그 결과 실제 능력 배수가 될 수도 있음
      AWS도 몇 년 써본 뒤보다 지금 훨씬 잘 쓰게 됐고, 명령줄도 더 효과적으로 쓰게 됨
      원래도 찾을 수 있던 정보지만 시간이 너무 오래 걸렸는데, 원하는 답에 도달하는 시간 규모가 크게 줄어 실제 산출물과 능력이 달라졌음
    • 작은 Bash나 Python 유틸리티 스크립트를 번개처럼 뽑아주는 건 진짜 게임 체인저임
      Raspberry Pi에서 작은 웹 서버를 돌리고 싶어서 Gemini에게 코드와 systemd 서비스로 실행하기 위한 설정용 Bash 스크립트를 써달라고 했음
      잠자면서도 할 수 있는 일이지만 시간과 집중이 필요한데, 이 댓글을 쓰는 시간 동안 정확히 필요한 걸 만들어줬음
      단독으로 보면 대단하지 않아도, 다른 책임들 때문에 에너지가 없어서 미뤄둔 홈 자동화 작업들을 이제 처리하게 됨

  • 맞음. AI는 순수한 능력이나 재능을 구식으로 만드는 게 아니라 오히려 더 가치 있게 만듦
    깊은 기술 지식은 AI를 적용할 수 있는 접점이 많아지기 때문에 현실에서 더 큰 지렛대 효과를 갖게 됨
    이 깨달음 때문에 AWS 같은 클라우드 서비스 대신 내 기술 SaaS를 호스팅할 홈랩 데이터센터를 직접 만들게 됨
    기본 네트워킹, DevOps, 서버 하드웨어를 배우는 가치가 AI 덕분에 더 빠르고 넓게 적용될 수 있음
    예전 같으면 RouterOS를 익혀 데이터센터급 Mikrotik 라우터를 설정하는 데 몇 시간이나 며칠이 걸렸겠지만, Claude 덕분에 20분짜리 작업이 됐고 라우팅 설정도 많이 배움
    클라우드만 썼다면 갖지 못했을 고유한 제어권이 생겼고, AI 이전에는 감히 생각하지 못했을 자체 운영체제까지 만들어보고 싶어짐

    • 그렇게 확신하진 못하겠음
      전동 공구와 못총이 나왔을 때도 비슷하게 생각했을 것 같지만, 집은 훨씬 빨리 지을 수 있게 된 대신 임금은 내려가고 작업 품질은 떨어졌으며 숙련과 경험의 가치는 크게 줄었음
      벽 미장은 예전엔 고임금 숙련직이었고, 석고보드가 나오면 지루한 평면 벽에 시간을 덜 쓰고 모서리와 장식 미장에 더 시간을 쓸 거라고 생각했지만, 그런 장식은 사라짐
      장식은 벽면 나머지에 비해 시간이 너무 오래 걸렸고, 그 기술을 유지하거나 배우는 사람들은 여전히 decent한 보수를 원했기 때문임
      평범한 석고보드 작업도 생산 요구는 올라가고 임금은 정체됐으며, 요즘은 이음매도 엉망인 경우가 많고 돈이 되는 건 생산 속도와 불평하지 않는 태도뿐임

  • “방 안의 코끼리”는 모두가 말하지 않는 큰 주제를 뜻하는데, AI는 모두가 말하고 있음
    더 나은 제목은 “AI가 개발자 기술을 대체하는 대신 증폭하는 이유”에 가까움

    • 맥락상 이 글은 내 최신 강의를 위한 마케팅 캠페인의 뉴스레터 이슈였음
      그 시점까지 해당 마케팅 캠페인에서 AI를 다루지 않았다는 의미에서 “방 안의 코끼리”였음
      이 링크는 이메일 클라이언트에서 제대로 표시되지 않을 때 읽으라고 만든 웹 보기 링크라, 더 넓은 독자를 의도한 글은 아님
    • 결과는 결국 같음
      같은 일을 해내는 데 필요한 개발자 수가 줄면 많은 사람이 실직하게 됨
      남는 사람들의 급여도 낮아질 가능성이 큼
      주니어 급여와 AI 구독료로 “같은 결과”를 얻을 수 있다고 생각한다면 왜 시니어 급여를 주겠음
      소프트웨어 개발자들은 힘든 시기를 맞을 것 같고, 15년 해왔지만 기대되지 않음
      솔직히 다른 업계로 재교육을 고민 중이고, 돈을 덜 벌더라도 이 난장판을 피하는 게 나을 수 있음

  • Josh의 견해에 대체로 동의하지만, AI와 일할 때 시니어와 주니어 경험을 이야기하는 글 상당수는 좀 헛소리 같음
    시니어가 AI 도구로 더 좋은 결과를 얻고 주니어가 더 고생한다는 건 맞지만, 달라진 건 그 차이가 증폭됐다는 점뿐임
    사람들이 피하는 부분은 주니어가 어떤 분야에서든 AI 연구 보조와 함께 훨씬 빨리 배울 수 있고, 깊게 파고들 체력이 있는 사람에게는 전문가가 되는 속도도 빨라졌다는 점임
    AI 도구에게 “만들어줘”나 “고쳐줘”를 시키는 만큼이나 “이건 어떻게 작동하나?”, “다른 도구를 제안해줄 수 있나?” 같은 질문을 많이 함
    AI를 단순한 입력/출력 관계로만 보는 경우가 많은데, AI가 있든 없든 중간에서 만지작거리는 과정이 항상 중요했음
    초보자는 처음엔 못하겠지만 원래도 그랬고, 좋은 사람들은 내가 겪은 것보다 훨씬 짧게 못하는 시기를 지나갈 거라 봄
    다만 AI가 주는 즉각적인 만족감이 마찰을 겪는 과정을 약화시킬 수 있고, AI 네이티브는 마찰을 이해하지 못하고 의문시할 가능성이 있음

    • 주니어가 AI 연구 보조로 훨씬 빨리 배운다는 건 잘 보이지 않음
      대학 수준에서 보이는 상황을 보면 그렇게 기대하기도 어려움
    • 핵심은 AI의 즉각적인 만족감이 마찰을 겪는 과정을 약화시킬 수 있다는 부분이라고 봄
      형편없는 바이브 코딩이나 10배 속도 같은 주장에 사람들이 불쾌해하면서 이 부분이 가려짐
      가장 중요한 배움은 질문하고 즉시 답을 받을 때가 아니라, 답을 찾으려고 애쓰고 몇 번 실패하고 깊이 생각하다가 잠깐 쉬고 나서 문제를 풀 때 생김
      그런 지식은 답뿐 아니라 앞으로 피할 수 있는 잘못된 경로와 자기 사고에 대한 신뢰까지 주기 때문에 값어치가 큼
      다음 세대가 이 단계를 건너뛰면 답은 쉽게 찾아져야 한다고 생각하고, 점점 AI에 의존하며 자기 머리에 대한 확신은 줄어들 것임
    • 읽는 것만으로 배우는 게 아니라 직접 해보면서 배움
      이 경우 LLM 출력만 읽는다고 해서 실질적으로 교육되지는 않음
    • 오히려 가능한 한 게을러지게 해줌
      AI 도구로 더 깊게 파고드는 사람은 본 적이 없음
    • 실제로 AI는 주니어 개발자를 더 멍청하게 만든다고 봄
      시니어 개발자는 자신이 만든 수많은 실패한 프로젝트라는 산을 넘으며 배웠음
      플랫 파일 데이터베이스를 만들자거나, 50개 넘는 Lambda로 마이크로서비스 아키텍처를 만들자고 해도, 나는 이미 해봤고 왜 기술적으로 가능해도 하지 말아야 하는지 앎
      내게 AI는 올바른 방향으로 시속 100마일로 가게 해주지만, 주니어들은 바다나 벽을 향해 시속 100마일로 달리는 모습을 봄
      AWS가 우리를 더 멍청하게 만들어 역방향 프록시를 모르는 주니어가 생겼고, 고수준 언어가 메모리 관리를 이해하지 못하게 만들었듯 AI도 그 사슬의 다음 고리임
      10년 뒤에는 대부분의 개발자가 코드를 읽지 못할 것 같음

  • 많은, 어쩌면 대부분의 소프트웨어 엔지니어는 자기 코드베이스의 전문가이기 때문에 상당수 엔지니어가 AI에서 높은 가치를 얻고 있음
    불분명한 건 엔지니어당 더 많은 코드를 쓸 수 있게 되면 개발자가 줄어드는지, 아니면 UX, 테스트, 개발자 경험, 문서처럼 전통적으로 밀리던 영역에 더 많은 소프트웨어가 생기는지임
    어쩌면 기준선이 올라갈 뿐일 수도 있음

  • Claude와 이야기하다가 이런 점을 봤음
    내가 “X가 Y보다 낫다는 게 놀랍지 않냐”고 말했더니 Claude는 “통찰력 있는 비판”이라며 Y가 X보다 낫다는 이유를 잘 정리해 답했음
    답 자체는 좋고 사려 깊고 논리적이었지만, 내가 말하려던 것과 반대라서 “아니, 내가 말한 건 X가 Y보다 낫다는 반직관적 주장이다”라고 정정했음
    그러자 Claude는 다시 “맞다, X가 Y보다 낫다”며 역시 잘 정리된 이유를 내놓았음
    이게 일종의 멍청한 똑똑이 천재 밈 같음
    “그냥 자동완성이다”와 “아니다, 마음속에 모델이 있다” 사이를 오가지만, 결국 바벨의 도서관처럼 세상의 모든 천재성이 있어도 올바른 색인 키가 있어야만 쓸 수 있음

    • LLM이 예측 엔진이라는 건 잘 알려져 있지만, 제대로 쓰려면 그 말이 작은 단위에서 무엇을 뜻하는지 생각해야 함
      1차 근사로 LLM은 사용자가 원하거나 기대하는 답을 예측함
      첫 프롬프트에 대한 답은 LLM이 사용자를 완전히 오해하고, 사용자가 썼다고 생각한 내용을 기반으로 예측했기 때문에 우스운 결과가 됐음
      두 번째 프롬프트에 대한 답은 LLM의 목표가 사용자가 원하거나 기대하는 내용을 예측하는 것임을 더 분명히 보여줌
      환각의 큰 유발 요인 중 하나는 LLM이 해석한 사용자 기대가 현실과 맞지 않을 때이며, LLM은 현실을 자신이 파악한 기대에 맞추려 함
      환각을 줄이는 좋은 방법 중 하나는 프롬프트에서 단정문을 최대한 제거하는 것임
      “X가 Y보다 낫다는 게 놀랍지 않냐”에는 명시적 단정이 있고, LLM은 방향은 오해했지만 단정이 있다는 점은 이해해서 그 단정에 현실이 맞는 이유를 제시했음
      변호사들이 가짜 판례 인용으로 곤란해지는 것도 비슷해서, “X를 보여주는 판례를 찾아줘”는 위험하고 “X에 관한 판례는 무엇인가”가 더 나은 출발점임
답변달기