▲

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

 (dmitriid.com)
1P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • LLM에 대한 현재 논의는 명확한 정량적 근거 없이 이루어지고 있음
  • 각 사용자의 경험은 매우 단편적이며, 실제 활용 환경이나 배경 지식 등 핵심 요소가 거의 공유되지 않음
  • 비결정론적 특성으로 인해 같은 작업도 시간마다 다른 결과를 보여 신뢰성에 제한이 존재함
  • 업계 리더들의 과장된 주장이 비평 없는 수용과 과도한 기대를 부추기는 상황임
  • 실제로도 필자는 다양한 AI 툴을 일상적으로 사용하며, 절반 정도의 확률로만 원하는 결과를 얻는 현실 경험을 공유함

LLM을 둘러싼 논쟁과 기술에 대한 시각

LLM에 대한 비판과 분위기

  • 최근 AI, 특히 LLM(대규모 언어 모델)에 대한 논쟁에서, 비판적인 시각은 흔히 "기술을 제대로 이해하지 못한 사람들의 의견"으로 폄하하는 분위기 형성임
  • Hacker News 등에서 "AI에 질문을 던지면 본질을 모르는 무지함"이라는 반응이 반복됨

사용자 간 경험의 간극

  • LLM의 실제 효용성에 대해 "어느 정도는 도움이 된다"는 사용자와, "모든 시도를 해봤지만 별로 쓸모없다"는 사용자 간의 의견 차이 존재
  • 이 차이가 생기는 이유는 경험에 대한 구체적 기준과 정보가 공유되지 않기 때문임
    • 어떤 프로젝트에서 사용했는지
    • 코드베이스의 상태(새 프로젝트, 성숙한 코드, 비공개 소스 등)
    • 사용자의 전문성, 그 전문성이 실제 문제와 얼마나 연결되는지
    • LLM이 작성한 결과물을 실제로 제대로 정제·배포하기까지 추가로 들어간 노력 등 구체 정보 부재

경험 비교의 어려움과 비결정론성

  • 어떤 사용자가 모든 정보를 상세히 공유한다고 해도, 다른 사용자와의 경험 비교가 거의 불가능한 상황임
  • LLM과 오토메이션 에이전트들은 본질적으로 비결정론적임
    • 똑같은 문제에 같은 방식으로 요청을 해도, 매번 다른 결과를 얻게 됨
    • 프로젝트 종류, 사용하는 모델, 도구, 언어 등 변화 요인이 많아 일관된 검증 어려움

업계 리더와 과장된 기대

  • 업계 리더들이 LLM의 성과를 과도하게 강조하는 사례 다수 존재
    • 예: 한 업계 리더가 "Claude Code"를 사용해 오래된 버그가 놀라울 정도로 쉽게 수정된다는 경험, 세부 정보 공유 없이 대중적 호응을 얻음
    • 구체적인 코드 크기, 버그의 난이도, 추가 노동 여부, 사용한 프로그래밍 언어·프레임워크 등 핵심 정보가 생략된 채로 매우 긍정적인 메시지만 확산됨
    • 이러한 사례는 1.8천개 이상의 호응과 204개의 재포스팅을 기록하며, 과장 마케팅이 쉬이 확산됨

사용 경험과 현실 인식

  • 필자도 Vercel의 v0, Claude Code, Midjourney 등 다양한 AI 툴을 매일 활용함
    • Swift에 대한 지식 없이 SwiftUI로 모니터링 앱 제작
    • Midjourney로 이벤트용 포스터 자동 생성
    • Elixir 기반 MCP 서버 함수 코딩 등 경험 있음
  • 하지만 성공 확률은 대략 50% 에 불과하며, 결과물은 언제나 일관되지 않음
  • LLM이 마치 마법처럼 느껴질 때도 있지만, 실제로는 비결정적인 통계적 모델일 뿐임
  • 이러한 현실에서, 업계 논의는 이분법(마법 vs. 엔지니어링) 에만 머무르고 있다고 지적함

결론

  • LLM과 AI를 둘러싼 현장은 확실하고 명확한 검증 체계 없이 과장된 상상, 기대, 믿음이 선호되는 경향임
  • 비판적 사고를 멈추지 않고, 실제로 기능과 효과를 세부적으로 검증하려는 노력이 중요함
  • 논의에서 중요한 것은 구체적이고 정량적인 정보 공유임
  • LLM의 한계와 가능성을 균형 있게 바라보는 시각이 필요함
▲
GN⁺ 18시간전  [-]
Hacker News 의견

  • 내가 일하는 곳의 경영진이 10배 생산성 향상 얘기를 들어서 답답함을 느낌. 일부는 우리 회사의 초기 도입자들이 직접 그런 얘기를 하기도 함. 하지만 그런 기대치는 너무 높음. Amdahl의 법칙도 한몫하는데, 내 시간 대부분은 코딩이 아니라 생각과 커뮤니케이션에 씀. 코딩이 진짜 10배 빨라진다 쳐도(대부분의 경우 그렇지 않음) 전체 생산성은 10~15% 향상에 불과함. 그래도 꽤 괜찮은 결과이긴 하지만, 10배는 아님

    • 내 현재 업무가 좀 더 R&D 느낌이라서 그런지, LLM은 "생각" 부분에서도 "코딩" 만큼이나 큰 이득을 줌(커뮤니케이션은 내가 직접 잘 해결함). LLM으로 생각 작업을 하는 건 20년 전 웹 검색을 마스터하던 감각과 비슷함. 예전 검색 엔진은 내가 뭘 찾는지 알아야 했는데, 이제는 LLM이 뭘 찾아야 하는지부터 찾아줌(그리고 대신 검색해주기도 함). 예전엔 어렵다고 분류했던 일들도 이제는 LLM 덕분에 쉽게 해결 가능. 지금은 웹 검색의 1/3 정도를 ChatGPT o3로 하고 있음. 이제 이걸 포기하는 건 상상도 못 함. 게다가 LLM이 내 미완성 생각을 정리하고 토론 상대가 되어주는 심리적 요소도 큼. 이 덕분에 많은 일이 한결 덜 두렵게 느껴지고, 그 차이도 큼

    • 내 회사에서도 상황이 비슷함. 내부 초기 도입자들이 주장하는 생산성 향상은 매우 좁은 방식으로 측정하거나, 산수 자체가 좀 허술한 경우가 많음

    • LLM이 주니어보다 시니어 개발자에게 더 큰 가속 효과를 줄 수도 있음(주니어는 좋은/나쁜 코드를 잘 구분 못하니까). 시니어 한 명이 향상된 LLM 워크플로우를 쓰면 예전 주니어 열 명 분 생산성도 가능할 듯함. 심지어 못하는 개발자라면 실질적으로 생산성을 마이너스로 만들 수도 있음(시니어의 시간을 뺏어서). 괜찮은 주니어도 LLM이 이미 더 잘하는 반복 일에 머무름. 그래서 직업이 실제로 없어질 수도 있겠다고 보는 입장임

    • LLM 툴 쓴다고 10~15% 생산성만 늘어난 경우 LLM 툴 비용 때문에 고용 비용이 10~15% 더 비싸지면 특별한 장점이 없다고 생각함. 생산의 총 비용을 고려해야 한다는 입장임

    • 개인 프로젝트에서는 쉽게 10배 가까이 빨라짐. 하지만 회사에서는 여러 팀과 논의, 요구사항 변경, PR 리뷰 등으로 이 환경이 안 맞음. 이런 최적화된 설계와 표준 패턴이 가능한 건 작은 스타트업이나 혼자 하는 프로젝트에 한정됨. 여러 명이 모이면 그 자체로 합의도 어려움. AI가 최고의 성과를 내려면 모든 게 표준화되어야 하는데, 현실은 모든 게 조금씩 어긋나기 때문에 실제 조직에선 그만한 효과를 보기 힘듦. 소수의 의지가 맞는 개발자끼리 협업하면 10배도 가능하겠지만, 기업 환경에서는 거의 불가능함. AI가 중간관리와 프로젝트 플래닝 쪽에 더 어울린다고 봄

  • 글쓴이가 불평하는 쪽이 나임. ChatGPT가 한창 부족하던 시절에 녹색필드 제품을 출시함. 이후 Claude와 웹챗~XCode 간 복붙, 그 다음에는 Cursor를 씀. 빌드 오류는 종종 생겼지만, 그래도 생산성은 최소 3배는 되었음. 이제는 에이전트 성능이 좋아지고 Claude 4도 나와서, 코딩은 거의 안 함. Architect/Manager 역할로 내 전문 지식으로 에이전트만 잘 디렉팅함. 스타트업에서 몇달 째 한 줄도 직접 코드를 안 썼음. 내가 직접 PR 올리기 전 전부 검수하고, 테스트도 철저히 하지만 Cursor+Sonnet 조합이 미쳤음. 라인 수 같은 건 중요하지 않고, 오히려 오래 일한 기존 코드베이스 전문가들이 나한테 자잘한 버그 질문함. Claude 덕분에 프론트엔드 개발자 일까지 손댔어서 조심하고 있음. 단순히 쿼리만 던지는 게 아니라 치밀한 리서치, 계획, 단계별 탐색 과정을 거치게 함. 도메인 지식은 필수임. 그래도 이만큼 유용하게 쓰지 못하는 사람이 있다는 게 신기함. 이런 기사 매주 두 개는 보는 느낌임

    • 나도 비슷한 경험이지만 약간 다른 환경(PhD 학생)임. LLM 회의적이었는데 Claude Code 이후 일의 방식이 완전히 바뀜. 그래도 큐레이션은 전적으로 내 몫임(PhD 과정에서 배우는 중요한 소프트스킬이자, LLM이 목표나 컨텍스트를 금방 잃거나 기억하지 못하기 때문). 정확한 소통이 가능하다면, CC로 예전엔 불가능했던 방식으로 연산을 조직할 수 있음. 프로그래밍이 더 쉬워지는 건 아니지만, 완전히 다른 양식이 생김

    • LLM이 신뢰받지 못할 코드를 빨리 검사하는 방법이나, LLM이 유닛 테스트도 작성하는지 평균 프롬프트 길이 등 실제 검증/검사 과정이 궁금함

    • LLM 출력을 바로 신뢰하냐는 지적. 전체 프로젝트 맥락을 LLM이 파악하지 못하고, 헛소리(환각)가 많기 때문에 검증이 필요함

    • LLM 코드 품질이 전체적으로 많이 부족하다고 느낌. 여러 번 반복 수정해야 해서 그냥 직접 짠 게 더 빠를 때가 많음. 하지만 대규모 메카니컬 리팩터링에는 에이전트가 아주 유용함. 복잡한 vim macro나 AST 스크립트 짜는 대신 에이전트 활용함

    • 몇 달 동안 한 줄도 직접 코드를 안 쓴다니 개인적으로 너무 지루할 것 같다는 생각

    • 블로그 글에서 주장한 내용(검증 불가, 엄청난 성과 주장 등)을 그대로 재확인해줌. 계정도 새로 만든 걸로 보임

  • 내 생각엔 실제 서비스 산업 노동의 대부분이 엑셀 시트 옮기기나 CRM/이메일~엑셀로 데이터 옮기는 것 같은 수작업임. 대기업엔 이런 반복 업무를 하는 상근 직원이 소프트웨어 엔지니어 대비 백 배쯤 있을 거라 봄. 그러니 LLM이 OCaml을 못 해도 상관없고, 엑셀에서 인간보다 조금만 잘하면 엄청난 가치가 창출됨. MCP 같은 걸로 이메일-CRM-엑셀을 엮어 자동화하면 오류율이나 환각도 확 줄어듦. 인간도 비결정적이니 이런 프로세스엔 결정론이 중요하지 않음. LLM과 암호화폐(crypto)는 유틸리티나 도입 면에서 완전히 다름. 스마트폰 보급을 떠올리게 됨. 내 비기술 친구들도 이제 LLM을 매우 다양한 용도로 씀

    • 암호화폐와의 비교는 건설적이지 못하다고 생각함. 기술적으론 전혀 관계 없음. 다만 기술 과신 현상은 있음. 이제 기본적인 자동화조차 접하지 못한 사람에겐 LLM이 SF처럼 보일 수도 있음. 이 분야가 이만큼 메인스트림이 된 적이 이전엔 없음. 앞으로는 성공과 실패, 다양한 의견, 실전 경험들이 혼재하는 와일드웨스트가 될 것이라 봄. 좋은 점은, 친구의 앱 아이디어도 이제 직접 실험해 볼 수 있는 세상이 마련됐다는 것임

    • 수작업 데이터 정제하는 FTE(Full-time Employee)들도 결과 검증과 기한 지키기, 법적 책임까지 있음. LLM은 일시적 예외 상황(예, 휴일이라 값이 0이어야 함)들을 맥락 밖에서 파악해 체크하진 못함. 이런 검증에 FTE 한 명 쓸 만한 가치가 충분히 있음

    • 소프트웨어 엔지니어 1명 당 100명 데이터 파이프라이닝 수작업 FTE라는 건 어떤 회사에만 해당하는지 궁금. 실제 백오피스/데이터 엔트리 업무가 대부분이라고 보지 않음. AI의 파급력엔 동의하지만 백색 칼라 전체가 거의 이메일+데이터 엔트리 인력이라는 주장엔 회의적임

    • 이런 유형의 직무 복잡성을 과소평가하고 있다고 생각함

  • 은퇴한 프로그래머 입장인데, 확률로 생성된 코드에 미션 크리티컬 책임을 맡길 상상을 못 함. 조금만 수정하면 쓸 수 있을 듯하면 이해 가능. 코딩 외 분야(브레인스토밍, 창의적 사고, 리서치 서포트)엔 LLM이 놀라움. LLM을 사고 파트너처럼 취급함. 실수도 있지만, 다른 출처로 검증하거나 다른 LLM으로 검토시키면 쉽게 잡을 수 있음

    • 나 역시 무조건 회의적인 성격인데, 실제로 써보니 모든 면에서 기대치를 뛰어넘음. 몇 시간 만에 몇 달 걸릴 프로젝트를 프로토타입~출시까지 진도 냄. 내가 할 수 있는 일들은 더 빠르게, 못하는 일(외주나 채용해야 하는 것)까지도 사소한 비용, 빠른 속도로 해냄. 물론 완벽하진 않고 짜증나는 점(명시적 지시 무시, 거짓말 등)도 많지만, 나에겐 게임 체인저임

    • LLM을 사고 파트너로 활용하는 게 잠깐은 잘 되는 것 같았지만, 어느 순간 망상이 드러난다고 느낌. LLM은 지식이나 추론을 하는 것처럼 보이게 잘 착각시킴. 특히 내가 모르는 분야에선 더 위험함. 검색엔진은 신뢰도를 소스로 비교할 수 있지만 LLM은 그게 안 됨. 실수 잡기도 항상 쉽지 않음

    • 40년 차 개발자로 몇 달 전부터 LLM을 쓰기 시작했는데, 일하는 방식이 크게 변함. 로그 에러 메시지 붙여넣으면 1분 안에 수정, 설계 브레인스토밍, 새로운 솔루션 제안 등. 코드 검증은 하지만, 정확성과 지능에 매일 놀람. (암호화폐와는 전혀 다름)

    • LLM 회의론자 입장이지만, 사실 인간이 작성한 모든 코드도 본질적으로 확률적임. 그래서 코드 리뷰, 유닛 테스트, 페어 프로그래밍, 가이드 같은 게 존재함. LLM이나 사람 출력 결과 모두 무비판적으로 쓰면 안 됨. 다만 LLM은 마법이 아니고, 도움이 되는 부분 외에 효율이나 안전성, 리팩터링 같은 장기적 가치를 무시한 채 보일러플레이트만 늘리는 데 악용될까 우려함

    • 내가 생각하기에 LLM이 가장 잘하는 건 데이터 사이언스임. IO가 명확해서 결과 검증이 쉬움. 특정 데이터의 특성을 알고 있으면 테스트 코드 생성도 쉽게 시킴. 컨텍스트가 필요하면 Claude Code가 큰 변화를 가져옴. 예시로 PCAP 파일에서 각 UDP 패킷 내 다중 메시지 추출, 필터링, 패턴 매칭, 테스트용 분리 등. "이 모든 함수에 대한 유닛 테스트를 작성해줘"라고 하면 LLM이 자가 검증까지 가능함

  • 나는 1년 전부터 거의 매일 LLM을 쓰고, 90%는 내 문제를 해결해줌. AI/LLM에 대한 부정적 의견이 언제 심각하게 받아들여야 할지 모르겠음. 내 경험상 코드베이스 전체를 입력하고 마법을 기대하는 일은 없었고, 내가 아는/이해하는 정확하고 구체적인 질문만 던지고, 솔루션을 검증 가능한 방식으로 적용함. 이런 방식이 아니라면 LLM을 잘못 쓰는 것임. 실제로 마법을 체험하려면, 작고 일상적이며 일관된 활용이 핵심임

    • Weatherman 패러디처럼 "60% 확률로 항상 동작한다"는 식으로 비꼼. 나도 GPT, Claude를 Cursor로 매일 씀. GPT o3는 일반 지식 검색에 좋고, Claude는 종종 실패함. 모델 자체가 바보 같지만 가끔은 핵심도 집어냄. 뭘 원하는지 스스로 알고, LLM을 잘 길들일 때 생산적으로 쓸 수 있다고 봄

    • "내 경험에서 90% 잘된다" 주장도 믿음이 잘 안 간다는 의견

  • 글쓴이가 논객들의 부정확한 논평에 화난 듯함. 실제론 LLM의 문제점과 한계는 매일 부딪히는 사용자=프로모터가 잘 알고 있다고 생각함. 번역, 전사, 코드 생성(일정 규모까지) 등 본래 불가능하거나 거의 불가능했던 문제가 완전히 혹은 거의 해결됨

    • 번역, 전사, 코드 생성이 진짜로 불가능에 가까웠나? Google Translate, Whisper, 오래전부터 존재했다는 지적

    • 실제 결함을 드러내는 건 detractor(비판자)이고, 오히려 promoter(찬양자)는 LLM을 만능인 것처럼 비판 없이 추켜세움

  • 최근 AGI, AI 용어 사용이 특히 과학 논문에서 너무 모호하게 느껴짐. 최소한 논문마다 자신만의 정의라도 명확히 했으면 좋겠다고 생각함. AGI가 뭔지 정의를 명확히 하면, 특정 AI가 그 정의를 충족한다고 논리적으로 증명도 할 수 있음. 실질적인 쓸모가 없어 보일지라도, 의미 없는 용어보단 훨씬 나음. 현재는 AGI 정의 없이 도망치듯 쓰는 느낌임. "인간과 동등/넘어서는 거의 모든 인지 과제"라고 위키에 나오는데, 측정은 불가능함. 이런 속 빈 용어를 왜 쓸까 하는 고민

    • 모두가 같은 의미로 쓸 필요도 없음. AGI라는 단어에 자신만의 기준을 갖고 있으면 됨(다수가 동의하지 않아도 됨). crypto도 원래 내겐 cryptography임. 주류와 내 개인 기준이 다를 수 있음

    • AI에 정의가 있다면 "아직 실현되지 않은 걸 AI라 부른다"는 AI effect 설명 링크

  • 최근 회사에서 LLM 활용 시작. 첫 업무는 2만 통 고객 상담 콜 전사 및 데이터 추출(비교 제품, 문제점, 대표적 사용 사례 등). 예전엔 몇 주 걸릴 리서치가 몇 시간 만에 끝남. 새로운 비즈니스 전략까지 세웠고, 실제로 큰 가치를 얻음. LLM은 자연어 처리 엔진으로 매우 뛰어남. 과장된 홍보도 많지만 실제 우리에겐 실질적으로 도움이 됨. 단순 도구일 뿐, 누군가에게 증명할 필요를 못 느끼겠음

    • 과대 홍보가 마냥 무해하지 않다고 생각함. 시장 왜곡, 과도 투자, 조직 축소, 현실불가능한 기대 등 부정적 파장도 초래함. 이런 기사들이 시장/기대 식히는 데 필요함. LLM을 파는 사람들은 보통 상담 콜 요약이 아니라 인원을 대체할 온갖 과장된 시나리오를 말함

    • 데이터 대량 처리, 신뢰도 있는 방식으로 해결하는 경험 없는 사람만이 LLM에 쓸모가 없다고 말하는 듯. 이제 번역도 훨씬 컨텍스트 있게 처리 가능

  • 신뢰할 만한 테크 업계 인사들도 GenAI가 개발 생산성에 큰 도움을 준다고 직접 얘기함. 의미가 5%~100%라는 식으로 넓음. 최소한 상당히 유용한 도구로 받아들여야 한다고 생각함. 이런 주장을 위해 구체적인 숫자(코드 라인, 바이트, CPU 등)는 필요 없다고 봄

    • "사람들이 임의로 정한 숫자로 생산성 향상을 주장하는 걸 무비판적으로 믿으라는 얘기"라며 비꼬는 의견

  • LLM 기술도 결국 올바르게 쓰일 곳이 있겠지만, 이미 너무 많은 사람들이 오용하기 때문에 이제 되돌릴 수 없음. 수많은 초급 개발자가 위험을 감수하다 실패하고, 수많은 투자가 낭비될 듯함. 기업들도 포기하지 못하고 전부 올인한 상황임

답변달기