LLM이 소프트웨어를 제대로 만들 수 없는 이유

TL;DR Highlight

Zed 에디터 CEO가 LLM은 소프트웨어 엔지니어링의 핵심인 멘탈 모델 유지 능력이 없다고 분석하며 AI 코딩 도구의 현실적 한계와 올바른 활용법을 제시했다.

Who Should Read

AI 코딩 도구(Cursor, Claude Code, Copilot 등)를 실무에 쓰고 있거나 도입을 검토 중인 개발자. LLM에 어디까지 맡기고 어디서 직접 개입해야 하는지 판단 기준이 필요한 사람.

Core Mechanics

소프트웨어 엔지니어링의 핵심은 '요구사항의 멘탈 모델'과 '코드가 실제로 하는 일의 멘탈 모델' 두 가지를 동시에 유지하면서 차이를 좁혀가는 반복 루프인데, LLM은 이 두 모델을 동시에 들고 비교하는 능력이 없다.
LLM은 코드 생성 자체는 잘 하지만, 테스트가 실패하면 코드를 고쳐야 하는지 테스트를 고쳐야 하는지 판단하지 못하고, 답답해지면 전부 지우고 처음부터 다시 짜는 패턴을 보인다. 이건 좋은 엔지니어의 정반대 행동이다.
사람은 문제가 생기면 전체 컨텍스트를 잠시 스택에 넣고 세부 이슈에 집중한 뒤 다시 돌아오는 '멘탈 스택' 조작이 가능한데, LLM은 컨텍스트 윈도우에 텍스트를 계속 쌓을 뿐 이런 추상화 수준 전환을 못 한다.
현재 생성형 모델의 구조적 한계로 세 가지를 꼽았다: 빠진 컨텍스트를 잘 못 찾는 문제(context omission), 최근에 본 내용에 편향되는 문제(recency bias), 없는 내용을 지어내는 문제(hallucination).
그렇다고 LLM이 쓸모없다는 건 아니다. 요구사항이 명확하고 문제가 단순한 경우에는 한 번에 결과물을 뽑아내는 데 탁월하고, 문서 합성이나 코드 초안 생성에도 좋다.
다만 비교적 복잡한 작업에서는 LLM이 정확한 컨텍스트를 유지하면서 반복적으로 해결책을 수렴시키는 게 불가능하므로, 요구사항 명확화와 코드 검증은 여전히 사람의 몫이다.
Zed의 입장은 '사람과 에이전트의 협업'이되, 운전대는 사람이 잡아야 한다는 것. LLM은 도구일 뿐이라는 관점이다.

Evidence

한 개발자가 Cline + Sonnet 3.7로 Rails TDD를 하면서 '테스트 먼저 작성하고 작은 단위로 나눠서 리뷰하면 코드 vs 테스트 판단도 꽤 잘 한다'며, 최소한 주니어 엔지니어 수준은 된다고 반박했다. 다만 '완벽하진 않고 가끔 풀지 못하는 버그가 있다'고 인정했다.
GPT5로 WebGPU/wgpu 렌더러를 만들다 런타임 에러에 막혀 LLM에 도움을 요청했더니 2시간 동안 그럴듯한 설명만 늘어놓고 해결 못 했는데, 직접 10분 생각하니 버퍼 포맷 불일치라는 단순한 문제였다는 경험담이 공유됐다. '쉬운 건 혼자 하고, 어려운 건 LLM이 못 하면 대체 뭐에 쓰냐'는 불만.
투자 관점에서 '인터넷도 90년대엔 엉망이었고, 트위터도 fail whale 시절이 있었지만 계속 성장했다. LLM도 2022년 대비 10배 나아졌으니 5년 뒤엔 이런 작업도 가능해질 것'이라는 기술 낙관론이 있었다.
TDD의 Red-Green-Refactor 단계를 LLM에게 명시적으로 알려주면('지금은 RED 단계니까 테스트가 실패해야 정상') 코드 vs 테스트 판단을 훨씬 잘 한다는 실용적 팁이 공유됐다.
Claude Code를 쓰면서 '멘탈 모델 유지 못 하는 문제'에 점점 더 좌절한다는 댓글과, 반대로 'enum 값 추가 같은 반복 작업을 여러 에이전트에 맡기고 자기는 아키텍처에 집중하니 개발 속도가 크게 올랐다'는 긍정적 경험이 공존했다.

How to Apply

LLM에게 복잡한 작업을 맡길 때는 한 번에 큰 덩어리를 주지 말고, 문제를 작은 단위로 쪼개서 하나씩 지시하면 멘탈 모델 유지 실패로 인한 삽질을 크게 줄일 수 있다.
TDD 기반으로 LLM을 쓸 때 Red-Green-Refactor 단계를 프롬프트에 명시하면('지금은 GREEN 단계, 이 테스트를 통과하는 최소한의 코드만 작성해') 코드/테스트 혼동 문제를 완화할 수 있다.
LLM이 생성한 코드가 수백 줄 넘어가면 나중에 문제 발견 시 사실상 처음부터 다시 해야 하므로, 각 단계마다 직접 리뷰하고 검증한 뒤 다음 단계로 넘어가는 워크플로를 유지해야 한다.
enum 추가 후 매칭 포인트 수정, 보일러플레이트 CRUD, 컴파일 에러 수정 같은 '지적 난이도는 낮지만 손이 많이 가는 작업'에 LLM을 집중 투입하고, 아키텍처 설계와 디버깅 판단은 직접 하는 식으로 역할을 분리하면 생산성이 올라간다.

Terminology

Mental Model머릿속에 구축하는 '시스템이 어떻게 동작하는지'에 대한 지도. 코드를 안 봐도 '이 입력이 들어오면 저쪽에서 이렇게 처리될 것'이라고 예측할 수 있게 해주는 내부 시뮬레이션.

Context WindowLLM이 한 번에 읽고 참고할 수 있는 텍스트의 최대 범위. 책상 위 공간처럼, 넓을수록 많은 자료를 동시에 펼쳐볼 수 있지만 무한하지 않다.

Recency BiasLLM이 컨텍스트 윈도우에서 최근에 나온 내용에 과도하게 영향받는 현상. 앞부분에 중요한 정보가 있어도 뒷부분 내용을 더 중시하는 경향.

HallucinationLLM이 실제로 존재하지 않는 함수, API, 사실 등을 마치 있는 것처럼 자신있게 생성하는 현상. 창의성과 메커니즘은 같지만 결과가 틀릴 때 이렇게 부른다.

Red-Green-RefactorTDD의 3단계 사이클. Red: 실패하는 테스트 작성, Green: 테스트 통과하는 최소 코드 작성, Refactor: 동작 유지하면서 코드 정리.