LLM을 둘러싼 모든 것이 여전히 마법 같고 희망적인 생각임

• LLM 도구의 성과담은 프로젝트 조건, 사용자 전문성, 후속 작업량 같은 비교 기준이 빠지는 경우가 많아 실제 효용을 판단하기 어려움
• MCP, 도구 사용, 에이전트 논의에서 비판자를 “깊이 보지 않은 사람”으로 몰아가는 태도는 과거 crypto 논쟁과 닮아 있음
• LLM과 에이전트는 비결정적이라 같은 문제라도 지금 작동한 방식이 1분 뒤에도 그대로 통한다고 보기 어려움
• Claude Code가 “레거시 버그를 처리한다”는 유명 발언도 코드베이스 규모, 버그 종류, 관리 방식이 빠진 채 1.8천 좋아요와 204 리포스트를 받음
• 여러 도구를 실제로 써 온 입장에서도 LLM은 비결정적 통계 기계에 가깝고, 작동할 때 마법처럼 느껴져도 마법이나 공학으로 단정하기 어려움

---

LLM 경험담을 서로 비교하기 어려운 이유

• LLM 도구에 대한 찬반 경험은 대개 분리된 단편으로 공유되어, 서로 같은 조건을 말하는지 확인하기 어려움
• 프로젝트와 코드베이스의 성격이 빠지는 경우가 많음
  • greenfield인지, 성숙한 코드베이스인지, 독점 코드베이스인지 불명확함
• 사용자 전문성도 단순 비교하기 어려움
  • 전문성이 같은 도메인, 같은 코드베이스, 같은 언어에 적용된 것인지 알 수 없음
• 리뷰, 수정, 배포, 마무리 같은 추가 작업량이 얼마나 필요했는지도 판단에 큰 영향을 줌
• 한 사람이 위 정보를 모두 제공하더라도, 다른 사람들의 조건을 모르면 경험 간 비교는 여전히 제한됨
• 여기에 LLM 시스템과 에이전트의 비결정성이 더해짐
  • 같은 문제라도 지금 통하던 방식이 1분 뒤에도 통한다고 볼 수 없음
  • React greenfield 프로젝트의 시니어 엔지니어 경험과 OCaml 독점 코드베이스의 비개발 디자이너 경험은 모델과 에이전트가 달라지면 더 비교하기 어려움
  • 같은 모델과 에이전트여도 실행마다 결과가 달라질 수 있어 단순 비교가 어려움

과열된 담론과 실제 도구 사용 사이의 간극

• LLM 비판자를 “MCP와 도구를 충분히 보지 않은 사람”으로 취급하는 반응은 AI 논쟁의 과열을 보여줌
• “industry leaders”의 사례로 Steve Yegge의 Claude Code 관련 발언이 등장함
  • Claude Code가 오래된 코드베이스의 레거시 버그를 며칠 동안 강하게 처리했다는 내용임
  • 컨텍스트를 직접 선택하지 않아도 Claude Code가 진행한다는 식의 표현이 포함됨
  • 은행 승인만 계속되면 버그 수정이 프로덕션 배포까지 이어지고 사용자 로그를 확인한다는 내용도 포함됨
• 이 사례에서도 판단에 필요한 정보는 빠져 있음
  • 코드베이스 규모가 알려지지 않음
  • 어떤 버그인지 알 수 없음
  • 추가 관리가 있었는지 불명확함
  • 프로그래밍 언어와 프레임워크도 드러나지 않음
• 그럼에도 해당 발언은 1.8천 좋아요와 204 리포스트를 받음
• 회의론자와 비판자도 도구를 쓰지 않는 것은 아님
  • Vercel의 v0로 전적으로 설계한 사이드 프로젝트가 있음
  • Swift를 모르는 상태에서 Claude Code로 SwiftUI 모니터링 앱을 만들었음
  • Midjourney로 이벤트 포스터를 만듦
  • Elixir로 MCP server를 vibe-coding했지만 phoenix.new는 쓰지 않았음
• 실제 사용 경험은 “50%의 시간에 50%만 작동한다”는 식으로 요약됨
• LLM은 비결정적 통계 기계이며, 작동할 때 마법처럼 느껴질 수 있어도 마법이나 공학 자체는 아님
• LLM 담론은 이를 마법 또는 공학 중 하나로만 다루려는 경향이 있음

[GN⁺]

Hacker News 의견들

• 일하는 곳의 경영진이 생산성 10배 향상 같은 얘기를 들어서 답답함. 그런 주장 일부는 사내 얼리어답터에게서도 나옴
  하지만 기대치가 너무 높아짐. 이유 중 하나는 Amdahl의 법칙인데, 실제로는 코딩보다 생각하고, 내 코드의 고객인 다른 사람들과 소통하는 시간이 훨씬 많기 때문임. 코딩이 10배 빨라진다 해도 대부분은 그렇지 않고, 전체 생산성은 10~15% 정도 좋아지는 수준임. 무시할 정도는 아니지만 10배는 아님

  • 지금 일이 연구개발 성격이 강해서일 수도 있지만, 내 경우 LLM은 코딩만큼이나 생각하는 부분에서도 생산성을 올려줌. 소통은 아직 내가 직접 잘 처리하고 있음
    LLM으로 생각하는 작업을 하는 느낌은 20여 년 전 웹 검색을 익혔을 때와 비슷함. 검색엔진은 무엇을 찾는지 알 때 정보 접근을 가능하게 했고, 이제 LLM은 애초에 무엇을 찾아야 하는지 알아내는 데 도움을 주며, 검색까지 해줌. 예전에는 노력과 불확실성 때문에 어렵다고 분류하던 작업들이 사소해짐
    지금은 웹 검색의 약 1/3을 ChatGPT o3로 하고 있고, 이제는 포기하기 어려움
    덜 익은 생각을 정리하고 러버덕처럼 받아주는 심리적 효과도 있어서, 많은 작업이 훨씬 덜 부담스럽게 느껴지고 그 자체만으로도 차이가 큼
  • 우리 회사도 비슷한데, 지금까지 본 내부 얼리어답터의 생산성 주장은 모두 아주 좁은 생산성 측정 방식과, 좋게 말해도 수상한 계산에 기반해 있음
  • 그건 LLM이 주니어 개발자보다 시니어 개발자에게 훨씬 더 큰 가속기가 되기 때문일 수도 있음. 주니어는 무엇이 좋은지 나쁜지 잘 모름
    시니어 1명에게 잘 튜닝된 LLM 작업 흐름을 주면, LLM 이전의 주니어 10명만큼 생산적이어도 놀랍지 않음. 심지어 나쁜 개발자는 시니어의 시간을 빼앗아 생산성을 음수로 만들 수 있으니 그 경우는 무한 배에 가까움
    괜찮은 주니어도 대체로 저수준 반복 작업에 묶이는데, LLM은 이미 그런 일을 더 잘할 수 있음
    그래서 일자리가 실제로 사라질 수 있다는 말은 이해됨
  • LLM 도구 비용 때문에 고용 비용이 10~15% 더 든다면, 10~15% 생산성 향상은 무시할 수 없는 게 아니라 따져봐야 할 문제임. 처리량만이 아니라 전체 생산 비용을 항상 봐야 함
  • 또 하나의 기술 과대광고 물결일 뿐임. 현실은 완전한 파멸과 무한한 유토피아 사이 어딘가겠지만, 아마 둘 다 아닐 것임
    AI 흐름은 2000년대 초 소프트웨어 엔지니어를 대규모로 해외 아웃소싱하려던 움직임을 떠올리게 함. 경영진 사이에서 엄청난 기대가 있었고, 종이 위에서는 그럴듯했지만 대부분은 큰 실패로 끝났고 거의 모든 일자리가 다시 미국으로 돌아옴
    소프트웨어 엔지니어가 전체를 붙여주는 수많은 자잘한 일을 한다는 점을 많이들 무시함. AI에는 그런 부분이 많이 부족함. 외국인에게 그게 없다는 뜻은 아니지만, 언어 장벽, 시간대 차이, 문화 차이 등으로 비슷한 문제가 생겼음. 코드 품질과 유지보수성은 급락했고, 아웃소싱 업체가 만든 많은 결과물은 버려야 했음
    이미 내가 다루는 코드베이스에도 AI 찌꺼기가 쌓이고 있음. 코드 리뷰에서 통과한 이런 것들을 잡아내기가 매우 어려운데, diff로 보면 합리적으로 보이기 때문임. 문제는 보이지 않는 중복 코드와, 높은 수준에서 보면 전혀 말이 안 되는 이상한 추상화들임

• 나는 글쓴이가 불평하는 바로 그 부류에 속함. ChatGPT만 있었고 성능도 별로였던 시절부터, 사소하지 않은 그린필드 제품들을 출시해왔음. 처음에는 Claude를 쓰면서 웹 채팅과 XCode 사이를 복사·붙여넣기했고, 이후 Cursor를 발견함
  Cursor는 성가신 빌드 오류를 많이 남겼지만 생산성은 그래도 최소 3배였음. 이제 에이전트가 더 좋아지고 Claude 4가 나온 뒤로는 거의 직접 코드를 쓰지 않고, 그게 싫지도 않음. 아키텍트/매니저 역할에 더 기울었고, 필요하면 전문 지식으로 에이전트를 지휘함
  까다로운 스타트업에 들어간 지 몇 달이 됐지만 아직 손으로 코드 한 줄도 쓰지 않았음. PR을 만들기 전에 전부 직접 감사하고 철저히 테스트하지만, Cursor + Sonnet은 그 코드베이스에서 정말 말도 안 되게 강력함. 코드 줄 수 같은 무의미한 지표가 아니라, 해당 코드베이스 전문가들이 특이한 버그를 들고 와도 그 도메인에 새로 들어온 내가 5~30분 안에 좁혀낼 수 있다는 점에서 내가 가장 생산적인 직원이라고 확신함
  원래 커리어 내내 피했던 프런트엔드 개발자 일까지 Claude 덕분에 보이는 작은 문제들을 고치다가 발을 빼야 했음. 이건 바이브 코딩이 아니라 조사, 계획, 조심스러운 탐색의 절차가 있고 에이전트가 성공하도록 세팅하는 과정임. 도메인 지식도 필요함. 그런데 어떻게 같은 효용을 뽑아내지 못하는 사람이 있는지 정말 놀랍고, 이런 글이 매주 두 개씩 나오는 느낌임

  • 그런데 방금 블로그 글이 주장한 내용을 전부 확인해준 셈임
    믿기 어려운 얘기를 하면서도 증거는 하나도 공유하지 않았음. 심지어 신원 확인과 주장 검증을 불가능하게 하려고 일회용 계정까지 만들었음
    그래서 농담처럼 느껴짐
  • 나도 비슷한 경험을 했고, 다만 작업 방식은 조금 다를 것 같음. 나는 박사과정 학생임. LLM에 극도로 회의적이었지만 Claude Code가 작업 방식을 완전히 바꿔놨음
    그렇다고 큐레이션 요구가 사라지는 건 아님. 그건 여전히 내 몫이고, 박사과정이 가르쳐야 하는 일부이기도 함. 왜 X를 하는지, Y로 무엇을 보이고 싶은지 정확하고 성찰적으로 다루고, 모든 단계를 쪼개서 다른 사람에게 설명하는 능력은 엄청난 소프트 스킬임. 에이전트들은 지속적인 세계 모델이 없고, 영리한 압축을 써도 상호작용의 목표를 금방 잊기 때문에 지금은 더 중요해짐
    내가 정확히 소통하는 상태라면, 이전에는 불가능했던 방식으로 Claude Code를 써서 계산 작업을 조직할 수 있음
    품질을 신경 쓴다면 프로그래밍보다 쉬운 것은 아니지만, 다르고, 다른 관용구를 요구함
  • LLM이 내놓는 코드 품질은 꽤 나쁘다고 봄. 여러 번 반복해서 고치다 보면 내가 직접 하는 게 더 빠른 경우가 많음
    에이전트가 실제로 유용한 건 대규모의 기계적인 리팩터링임. 완벽한 vim 매크로나 AST 재작성 스크립트를 고민하는 대신 에이전트에게 맡김
  • PR 만들기 전에 전부 직접 감사하고 철저히 테스트한다고 했는데, LLM은 전체 프로젝트를 머릿속에 담고 있지 않고 환각도 잘 하는데, 신뢰할 수 없는 출처의 코드를 어떻게 그렇게 빨리 감사함?
    평균적으로 프롬프트는 얼마나 길고, 단위 테스트도 LLM이 작성함?
  • Claude Code를 하루에 몇 시간씩 쓰는데, 얘는 거짓말쟁이임. 믿고 쓰는 건 각자 위험을 감수해야 함
    개인적으로는 경험을 너무 좋게 포장하고 있다고 봄

• 개인적으로는 이걸 잘 이해 못하겠음
  전 세계 서비스 산업의 엄청난 양의 일이 사실상 사람이 한 Excel 시트에서 다른 Excel 시트로, 또는 CRM/이메일에서 Excel로 수동 데이터 이동을 하는 것에 가까움. 거의 모든 대기업에는 이런 일을 매일 하는 정규직이 수백에서 수천 명 있고, 상당수는 외주임. 소프트웨어 엔지니어 1명당 이런 수동 데이터 파이프라인 일을 하는 사람이 100명은 있을 거라고 봄
  따라서 LLM이 엄청난 가치를 만들기 위해 OCaml을 대단히 잘할 필요는 없음. Excel에서 사람보다 조금만 잘하면 됨. MCP가 정말 도움이 되는 지점은 이런 시스템들을 쉽게 연결할 수 있다는 점임. 이런 작업의 많은 오류는 전체 작업을 한 번에 문맥에 넣으려다 생김. MCP로 이메일을 가져와 데이터를 추출하고, 다시 MCP로 CRM에 한 줄씩 넣을 수 있다면 내 경험상 환각률은 매우 낮음. 최소한 과로한 주니어 직원 수준은 됨
  아마 글의 요지도 이것이었을 수 있지만, 이런 사용 사례에서는 비결정성이 문제가 아님. 관련된 사람들도 결정적이지 않기 때문임. 비결정적인 시스템, 예컨대 인간 시스템의 품질을 강제하는 시스템과 프로세스를 만들 수 있음
  마지막으로 나는 암호화폐도 LLM도 가까이 따라봤는데, 효용과 채택 측면에서 둘은 비슷해 보이지 않음. 가장 가까운 건 스마트폰 채택임. iPhone이 처음 나왔을 때 비기술 친구들 다수가 스마트폰이 필요 없다고 했지만, 몇 년 안에 모두 갖게 됨. LLM도 비슷함. 지금은 거의 모든 비기술 친구들이 매우 다양한 용도로 쓰고 있음

  • 암호화폐와 비교하는 건 게으른 비판임. 검증할 가치도 별로 없음. 암호화폐의 부정적 분위기를 가져와 재활용하려는 것뿐임. 두 기술은 서로 관련이 없고, 따라서 기술적으로 비교 평가할 뚜렷한 이유도 없음
    다만 사회적 반응은 기술 숭배의 흐름이고, 오래 겪어본 많은 엔지니어들이 피곤해할 만함. 비현실적인 주장은 쉽게 찾을 수 있고, 최악은 AI 회사 CEO들에게서 나옴
    동시에 정말 많은 사람이 사실상 컴퓨터 문맹임. 기본적인 자동화조차 거의 접해보지 못한 사람들에게는 얼마나 흥분되는 일처럼 보일지 상상할 수 있음. 우리가 SF에서 익숙하게 봐온 “말하는 컴퓨터”가 거의 현실이 되어가고 있음
    몇 년 전 AI 이전에 기계학습과 자연어 처리를 했는데, 가장 두드러지는 점은 이 분야에서 벌어진 그 어떤 일보다도 훨씬 주류가 됐다는 것임. 그만큼 통계적 추론을 바탕으로 설계하는 경험이 부족한 사람들도 많아짐. 당분간은 의견, 성공적인 구현, 현실적인 프로젝트 아이디어를 배우는 모든 면에서 서부 개척 시대가 될 것임
    이렇게 보면 됨. 이제 소설 같은 앱 아이디어를 들고 오는 친구에게 직접 만들어보라고 말할 수 있음. 그건 적어도 모두에게 이득임
  • 그 수동 데이터 파이프라인 일을 하는 각 정규직은 동시에 그 일을 검증하고 있음. 그리고 제때 정확히 해야 하는 준법적 책임도 있음
    해고되지 않기 위한 생존 본능, 더 잘하려는 야망, 이상한 관리자를 다른 경로로 보고할 윤리와 판단력처럼 회사에 감정적으로 투자된 부분도 있을 수 있음
    LLM은 문맥 밖의 이유로 값이 이상하다고 봤을 때 조직의 다른 노드에 전화해 확인하지 않음. 예를 들어 어제가 일회성 은행 휴일이라 값이 0이어야 한다는 상황 같은 것임. 이 숫자들이 정확한지 보장하는 데 정규직 연봉만큼의 가치가 있을 수 있음. 그리고 정확하지 않을 때 탓하거나 해고하거나 감옥에 보낼 사람이 있는 것도 가치임
  • 소프트웨어 엔지니어 1명당 수동 데이터 파이프라인 인력이 100명이라는 게 어떤 회사에서 사실인지 궁금함. 누군가 화이트칼라 직무 500개를 전수조사해서 분류해줬으면 함
    진짜로 자동화 가능한 것은 이미 자동화됐음. AI가 큰 혼란을 일으킬 거라고는 보지만, 대부분의 화이트칼라 직업이 “이메일 직무”나 데이터 입력이라는 관점에는 매우 회의적임. 내 경험과 맞지 않고, 여기 사람들이 과거에 갇혔다고 할 만한 대형 관료적 회사에서도 일해봤음
  • 이런 종류의 직무 복잡성을 크게 과소평가하고 있음

• 은퇴한 프로그래머임. 확률로 생성된 코드를 임무 중대 시스템에 신뢰한다는 건 상상하기 어려움. 거의 맞고 작은 수정만 필요하다면 이해할 수 있지만, 직접 경험은 없음
  주된 말은 LLM이 코딩이 아닌 영역, 예를 들어 브레인스토밍, 자유로운 발상, 조사 세부사항 채우기, 나를 되돌아보게 하는 질문 던지기에서는 놀랍다는 것임. LLM을 사고 파트너처럼 대함. 실수는 하지만 다른 출처로 확인하거나, 다른 LLM에게 결론을 검토하게 하면 쉽게 잡을 수 있음

  • 특정 경험을 대신 말할 수는 없지만, 나는 모든 것에 지독하게 회의적인 편인데도 가능한 모든 면에서 기대를 뛰어넘고 있음
    24시간도 안 돼 무언가를 만들었는데, 이걸 시작하는 데만 몇 달은 걸렸을 것이고 지금처럼 다듬어진 버전까지 가려면 더 오래 걸렸을 것임. 가장 인상적인 건 내가 할 수 있는 일을 더 빠르게 해낸다는 점임. 더 인상적인 건 내가 도저히 할 수 없어 채용하거나 외주를 줘야 했을 일까지 훨씬 적은 돈과 시간으로, 다른 사람과 소통하는 것보다 더 빠른 반복 속도로 해낸다는 점임
    완벽하지 않고 때로는 엄청나게 답답함. 명시적으로 하지 말라고 했는데 값을 하드코딩하거나, 특정 수정을 했다고 거짓말하면서 실제로는 전혀 관련 없는 다른 것을 바꾸기도 함. 그래도 내 생각엔 게임 체인저임
  • 한동안 “사고 파트너” 접근을 해봤고 잠깐은 잘 되는 줄 알았지만, 어느 순간 균열이 보이기 시작했고 허세를 알아봤음. LLM은 자신이 알고 있고 추론할 수 있는 것처럼 보이게 만드는 데는 극도로 뛰어나지만, 지적 대화를 키워가는 데는 별로임
    특히 새로 접하는 분야에서 지식을 캐내려 할 때 LLM에 오도되기 쉽고 위험함. 일반 검색엔진을 쓰면 출처 사이트를 보고 신뢰성을 판단할 수 있지만, LLM에는 그런 게 없음. 출력은 사실상 아무거나일 수 있고, 실수를 반드시 쉽게 잡을 수 있다는 데 동의하지 않음
  • 40년 동안 프로그래밍했고 몇 달 전부터 LLM을 쓰기 시작했는데, 작업 방식이 정말 바뀌었음. 코드 조각을 쓰게 하고, 로그의 오류 메시지를 붙여넣으면 대체로 1분 안에 수정안을 주며, 아키텍처나 새 해결책 브레인스토밍에도 씀
    물론 작성한 코드는 확인하지만, 지능과 정확도에 거의 매일 놀라고 있음. 암호화폐와는 전혀 다름
  • LLM 회의론자로서 말하자면, 숙련된 개발자가 쓰는 코드를 포함한 모든 코드는 본질적으로 확률적임. 그래서 중요한 프로젝트에는 코드 리뷰, 단위 테스트, 페어 프로그래밍, 가이드라인과 안전장치가 있음
    LLM 출력을 무비판적으로 쓰고 있다면 잘못 쓰는 것이지만, 인간의 출력도 무비판적으로 쓰면 잘못임
    다만 LLM은 마법이 아니고, 사람들이 copilot이나 에이전트 모델 등으로 나쁜 엔지니어링 관행을 숨기고, 장기적으로 중요한 효율성·안전성·재설계 대신 보일러플레이트를 더 많이 쌓을까 봐 걱정됨
  • LLM이 극도로 잘하는 영역이 하나 있는데, 바로 데이터 과학임. 입출력이 잘 정의되어 있으면 결과가 맞는지 쉽게 검증할 수 있음. 데이터의 특정 속성을 알고 있다면 테스트를 작성해달라고 할 수도 있음
    문제는 LLM에 내가 무엇을 하는지 문맥을 줘야 한다는 점인데, ChatGPT식 채팅에서는 그 문맥을 주지 않거나 귀찮아서 못 주게 됨. 여기서 Claude Code가 판을 바꿈
    예를 들어 각 UDP 패킷에 여러 메시지가 들어 있는 PCAP 파일이 있다고 하자. IP, 포트, 프로토콜, 시간을 어떻게 필터링할까? LLM을 쓰고 출력을 확인하면 됨. 패턴 A, AB, AAB, ABB 등을 가진 패킷 수를 어떻게 찾을까? LLM을 쓰고 출력을 확인하면 됨. 테스트용으로 그런 패킷만 들어 있는 PCAP은 어떻게 만들까? LLM을 쓰고 출력을 확인하면 됨
    코드도 읽을 수 있으니, 솔직히 말해 당신의 일이 특별한 건 아니기 때문에 무엇을 하려는지 훨씬 더 잘 추론할 수 있음. 어쨌든 “위 함수 전부에 대한 단위 테스트를 작성해줘”라고 할 수 있다는 사실만으로도 스스로 검증하도록 도울 수 있음

• “대부분의 회의론자와 비판자처럼 나도 이 도구들을 매일 쓴다. 그리고 50%의 경우 50% 정도 작동한다”라는 말이 있는데, 나는 약 1년 전부터 업무에서 거의 매일 LLM을 쓰고 있고 내 문제의 약 90% 를 해결해줌
  이런 AI/LLM 불만을 진지하게 받아들여야 하는지, 아니면 일부 사용자의 비합리적인 사용 패턴으로 봐야 하는지 판단하기가 매우 어려움. 예를 들어 나는 LLM에 코드베이스를 먹이고 마법처럼 작동하길 기대한 적이 없음. 내 이해의 경계 안에서 직접적이고 구체적인 질문을 하고, 해법을 의도적으로 테스트 가능한 방식으로 적용함
  다른 방식으로 접근하면서 LLM에 불평한다면, 잘못 쓰고 있다고 보는 쪽에 가까움. 그리고 작고 유용하며 꽤 일관적인 진짜 마법을 놓치고 있는 것임

  • “60%의 경우 항상 작동한다”는 The Weatherman의 대사를 사실상 인용한 셈임
    나도 Cursor를 통해 gpt와 Claude를 매일 씀. gpt o3는 일반 지식 검색에 꽤 괜찮음. Claude는 자주 무너지지만, 토큰을 낭비하며 자기 과시를 하는 동안 실제 문제와 관련된 지점을 건드리는 경우가 꽤 있다는 것도 봤음
    모델은 멍청하고, 천재 바보라기보다 그냥 바보에 가까움. 그래도 가끔 관련 있는 항목을 맞힘. 자신이 무엇이 일어나야 하는지 대략 알고 있고 LLM을 농장 들판의 쥐잡이 테리어처럼 다루면 제대로 활용할 수 있음
  • 이 말도 글쓴이가 문제 삼은 댓글보다 나을 게 없음
    90% 라는 수치도 좀 수상해 보임

• 이 글은 담론의 부정확성에 화가 난 것처럼 읽히는데, 그 부정확성은 솔직히 지지자보다 반대자 쪽에 더 만연해 있음. 지지자는 대개 결함과 한계를 매일 다뤄야 하기 때문임
  LLM 주변의 모든 것이 마법적 사고라는 결론은 꽤 오만해 보임. 지난 5년 동안 번역, 전사, 일정 규모까지의 코드 생성처럼 이전에는 거의 다루기 어려웠던 문제들이 완전히 또는 거의 해결됐기 때문임

  • 반대자들은 보통 실제 결함을 짚음. 지지자들은 보통 구체적인 세부사항 없이 LLM을 어떤 문제든 한 번에 해결할 수 있는 기적처럼 무비판적으로 떠받듦
  • 번역, 전사, 일정 규모까지의 코드 생성이 거의 다루기 어려운 문제였다고?
    Google Translate, Whisper, 코드 생성기는 LLM 없이도 꽤 오래전부터 존재했음

• “암호화폐가 다시 온 것”이라는 말에 대해, 암호화폐는 내게 생명줄임. 내가 사는 나라에서 내가 통제할 수도 고칠 수도 없는 이유로 은행 계좌를 열 수 없기 때문임
  그래서 암호화폐가 당신에게 쓸모없다면 다행임. 나와 나 같은 수백만 명에게는 생사 문제임
  LLM도 마찬가지로 어떤 사람에게는 마법이고, 다른 사람에게는 신뢰할 수 있는 결정적 도구이며, 동시에 마법이기도 함. 방금 수백 장의 송장을 분류하고 정렬했음. 맞음, 마법임

  • 이건 사실상 암호화폐의 유일한 사용 사례이고, 명시적으로 설계된 목적이기도 한 검열 저항성임
    그래서 합법 경제에서 암호화폐가 할 만한 유용한 일을 찾기 어려운 것임. 정부가 원하지 않거나 촉진할 수 없는 거래를 가능하게 하도록 설계됐기 때문임. 어떤 경우에는 인도주의적 응용이 있고, 불법적 응용도 많음
  • 어떤 상황인지 더 설명해줄 수 있음? 어느 나라에 있고, 거기서 암호화폐를 어떻게 쓰고 있음?
  • “암호화폐의 진짜 의미를 믿지 않으면 바보”라는 식의 말도 안 되는 과대광고 속에서, 이건 유효한 사용 사례임
    “그 자리에 있었어야 믿을 수 있다” https://x.com/0xbags/status/1940774543553146956
    AI 열풍도 지금 비슷한 시기를 지나고 있음. 어떤 비판이든 아무것도 모르는 바보가 하는 말로 치부됨
  • 사실 글쓴이의 농담과 반대되는 말을 하는 건 아닌 것 같음. 당신은 암호화폐를 화폐로 쓰고 싶어 하는 반면, 원글은 아마 투자 대상으로서 암호화폐 주변의 사기를 말했을 가능성이 큼
    화폐로 쓴다면, 코인을 펌프 앤 덤프하고 돈벌이 수단으로 삼으려는 사람들은 당신의 적임. 폭등과 폭락의 롤러코스터가 아니라 안정적일수록 당신에게 좋음
  • 암호화폐가 겪는 것과 같은 문제임. 거의 모두가 기술에 대해 거짓을 퍼뜨리고 있고, 그중 다수는 스스로 거짓말이라는 걸 알 만큼 이해하지 못할 뿐임. 순진함과 악의의 차이임
    암호화폐 쪽에는 의도적 거짓말이 더 많고 얻을 가치가 더 적다고 보지만, 두 경우 모두 실제로 이익을 얻을 수 있는 사람들이 부정직과 왜곡 때문에 문턱에 들어서기도 전에 돌아서고 있음. 그리고 두 경우 모두 오늘 실제 가치를 얻는 예가 존재함

• 약간 관련된 얘기지만, 요즘 AGI라는 용어, 때로는 AI라는 용어까지 쓰이는 방식이 짜증남. 특히 과학 논문에서는 모든 것이 잘 정의되어 있을 거라고 기대하는데, 적어도 그 논문 안에서의 사용 방식이라도 그래야 함
  왜 AGI가 무엇인지 정의를 만들 수 없는 걸까? 그러면 어떤 AI가 그 정의에 들어맞는지 논리적으로 증명할 수도 있음. 실용적으로 크게 쓸모없어 보이더라도, 의미 없이 용어를 쓰는 것보다는 이론적으로 훨씬 유용함
  지금은 일종의 탈출구처럼 느껴짐. Wikipedia에는 “거의 모든 인지 과제에서 인간 능력과 같거나 뛰어넘는 AI 유형”이라고 되어 있음. 이걸 어떻게 측정함? 어떤 시스템이 이 속성을 갖는지 증명할 수 없다면 무슨 소용이 있음?
  조금 푸념이지만 그래도 어느 정도 읽히길 바람

  • 전반적인 합의가 꼭 필요한 건 아님. 나는 무엇이 AGI인지에 대해 더 관대한 나만의 이정표를 갖고 있지만, 다른 사람이 공유할 거라고 기대하지 않음
    내게 “crypto”가 여전히 암호화이지 암호화폐가 아닌 것과 비슷함. 때로는 주류가 그냥 다른 의견을 가질 뿐임
  • 정의는 이미 있음
    “AI는 아직 해내지 못한 것이다”[1]
    1. https://en.wikipedia.org/wiki/AI_effect

• 최근 회사에서 LLM을 쓰기 시작했고, 첫 작업은 고객 통화 2만 건을 전사한 뒤 다음 정보를 추출하는 것이었음

  1. 우리 제품이 보통 어떤 제품들과 비교되는지
  2. 사용자가 우리 소프트웨어에서 어떤 문제를 겪는지
  3. 사용자가 가장 자주 언급하는 사용 사례가 무엇인지
     예전에는 몇 주 걸리던 조사가 몇 시간 만에 끝났음. 새 전략을 세우는 데 도움이 됐고 실제 비즈니스 가치를 만들었음
     LLM을 그냥 자연어 처리 엔진으로 보며, 그 용도에는 훌륭함. 누군가 과장하는 건 맞지만, 우리 사례에서 진짜로 유용했다는 사실은 변하지 않음. “LLM 나쁘다” 글들이 왜 이렇게 많은지 모르겠음. 자신에게 안 맞으면 그냥 넘어가면 됨. 왜 누가 누구에게 뭘 증명해야 함? 그냥 도구임
  • 과대광고가 만드는 부정적 영향을 과소평가하고 있음. 시장을 왜곡하고, 과잉 투자를 부르고, 부서를 선제적으로 줄이며, 결코 충족되지 않을 기대를 만듦
    이런 글들은 기대를 식히는 데 중요함. 사람들이 LLM을 팔 때 보통 고객 지원 통화 요약을 말하는 게 아니라, 고객 지원 직원을 해고할 수 있다는 생각을 팔려고 함
  • 정말 그렇다. LLM이 실제 쓸모가 없다고 하는 사람들은 많은 데이터를 꽤 안정적인 방식으로 처리해야 하는 문제를 마주해본 적이 없음
    수년 동안 웹상의 번역 대부분에는 문맥이 없었음. 이제는 문맥을 가질 수 있음

• 신중한 견해로 알려진 믿을 만하고 합리적인 기술계 인물들이 여러 형태의 생성형 AI를 써서 프로그래밍 작업에서 상당한 개선을 얻었다고 보고했음
  여기서 상당하다는 건 어느 정도일까? 5%에서 100% 사이, 즉 무시할 수 없는 수준임
  최소한 생성형 AI가 상당수 사람에게 상당히 유익한 도구이거나 그럴 수 있다는 말은 안전함
  이 정도 판단이 합리적이려면 CPU 수, 코드 줄 수, 처리한 바이트 수 같은 세부사항을 모두 공개해야 하는 건 아님

  • “사람들이 내가 만든 임의의 숫자와 또 다른 임의의 숫자 사이 어딘가의 생산성 향상을 주장한다. 우리는 이 주장을 무비판적으로 믿어야 한다”라는 말과 다를 바 없음