LLM의 L은 Lying(거짓말)의 L — AI 코딩 도구에 대한 근본적 회의

Who Should Read

AI 코딩 도구(Copilot, Cursor 등)를 일상적으로 쓰고 있지만, 코드 품질과 장기적 기술 역량에 대한 고민이 있는 개발자. AI 도입 여부를 결정해야 하는 팀 리드나 오픈소스 메인테이너에게도 유용하다.

Core Mechanics

• LLM이 하는 일의 본질은 '위조(forgery)'다. 사용자가 직접 만들었을 법한 결과물, 혹은 다른 사람의 결과물을 모방해서 빠르게 찍어내는 것이고, 이 모방물을 진짜 대신 쓰려 할 때 문제가 생긴다.
• 프랑스의 AOC(원산지 통제 명칭) 치즈처럼, 소프트웨어에도 '정품'과 '모조품'의 구분이 필요하다는 비유를 든다. 싸구려 모조품이 범람하면 진짜 제품의 브랜드와 그걸 만드는 전문성 자체가 사라진다는 논리.
• 오픈소스 메인테이너들이 이미 피해를 보고 있다. AI로 대충 만든 PR(슬롭 코드)이 쏟아지면서, 이미 부족했던 기여자 관리 부담이 더 커졌다.
• AI가 아무리 발전해도 소프트웨어 개발의 결과물은 '거의 돌아가는' 수준에 머물고 있다. 몇 년째 LLM 도구가 나오고 있지만 근본적으로 달라진 건 없다는 관찰.
• 새 모델이 계속 나오는 이유 자체가, 이전 모델이 약속한 걸 못 지켰기 때문이다. 하이프가 투자를 부르고, 투자가 더 큰 하이프를 요구하는 순환 구조.
• Copilot이라는 이름 자체가 마케팅 거짓말이라는 지적. 실제로는 co-pilot(부조종사)이 아니라 auto-pilot(자동조종)이고, 사용자가 통제하고 있다는 착각을 심어준다.
• AI를 안 쓰는 것도 완전히 괜찮다는 입장. AI를 안 쓴다고 뒤처지는 게 아니며, 오히려 스트레스가 적고 만족도가 높을 수 있다.
• 게임 업계의 프로시저럴 생성(procedural generation)을 전례로 들며, 자동 생성이 대체로 기대에 못 미쳤다고 주장한다. (단, 이 부분은 댓글에서 강하게 반박됨)

Evidence

• 프로시저럴 생성이 실패했다는 원문 주장에 대해 강한 반론이 나왔다. Minecraft(역대 최다 판매 게임), Valheim, Diablo, No Man's Sky(결국 대성공) 등 수많은 성공 사례가 있으며, 도구 자체가 나쁜 게 아니라 쓰는 사람에 달렸다는 의견.
• 미술사를 전공했다는 한 댓글러가 러다이트(Luddites)의 사례를 들며, 자동화가 품질을 떨어뜨린다는 주장이 역사적으로 맞았다고 지적했다. 중세 유럽의 수제 양모 스카프는 반지를 통과할 정도로 얇고 섬세했는데, 그 기술은 구전으로만 전수되다 영원히 사라졌다. 다만 '옳았어도 그것만으론 충분하지 않았다'고 덧붙였다.
• 실제로 비기술자가 바이브코딩으로 만든 내부 도구가 월 수백 시간을 절약하고 있다는 경험담이 있었다. 코드는 스파게티였지만 이미 임팩트를 내고 있어서 컨설턴트로서 성능만 일부 개선하고 나머지는 그냥 뒀다는 이야기.
• 개발자들이 받아들이기 어려운 현실은, 우리 코드 대부분이 소량의 독창성 + 대량의 반복 보일러플레이트라는 것이라는 의견. 가치는 코드 한 줄 한 줄이 아니라 상위 레벨의 설계와 혁신에 있다는 지적.
• LLM은 '거짓말'이 아니라 '오류(falsehood)'라는 반론도 있었다. 거짓말은 속이려는 의도가 필요한데 LLM에겐 의도가 없고, 그걸 진실로 둔갑시키는 건 사용자의 책임이라는 관점.

How to Apply

• 오픈소스 프로젝트를 운영 중이라면, PR 가이드라인에 AI 생성 코드 관련 정책을 명시하고, AI 슬롭 코드를 걸러내는 리뷰 체크리스트를 만들어라. 예: '이 PR의 코드를 직접 설명할 수 있는가' 확인 항목 추가.
• AI 코딩 도구를 쓸 때 Copilot 모드(자동 수락)가 아니라, 생성된 코드를 반드시 읽고 이해한 후에 반영하는 습관을 들여라. 특히 보안 관련 코드, 에러 핸들링, 엣지 케이스는 AI 출력을 그대로 쓰지 말 것.
• 팀에서 AI 도구 도입을 논의할 때, '보일러플레이트 자동화'와 '핵심 로직 설계'를 명확히 구분하라. AI는 전자에 효과적이지만 후자에서는 오히려 검증 비용이 늘어날 수 있다.
• 내부 도구처럼 수명이 짧고 사용자가 한정된 소프트웨어에는 AI 코딩을 적극 활용하되, 장기 유지보수가 필요한 프로덕션 코드에는 코드 리뷰 기준을 더 높게 잡아라.

Terminology

관련 논문

• Mindwalk – 코딩 에이전트 세션을 코드베이스 3D 맵 위에서 재생하는 시각화 도구

  Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.

• Ghost Font: 사람은 읽을 수 있지만 AI는 읽기 어려운 안티-AI 폰트 실험

  움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.

• GPT-5.6, Grok 4.5, Claude, Muse Spark 등 12개 모델이 동일한 앱 4개를 빌드한 결과 비교

  12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.

• Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과

  Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.

• Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구

  LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.

• LLM-as-a-Verifier: 범용 Verification 프레임워크

  LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.

Related Resources

• https://acko.net/blog/the-l-in-llm-stands-for-lying/
• https://acko.net/about