---
title: "2026년 LLM 코딩은 10배가 아니라 2배 생산성에 가깝다"
published: 2026-07-25T14:27:05.000Z
canonical: https://jeff.news/article/5281
---
# 2026년 LLM 코딩은 10배가 아니라 2배 생산성에 가깝다

저자는 2026년 LLM 코딩의 핵심 생산성 향상이 모델 자체의 마법이 아니라 자동 피드백 루프를 안정적으로 돌릴 수 있게 된 데서 왔다고 본다. 하지만 유지보수성, 문서 품질, 구조 판단 같은 문제는 여전히 인간 몫이라서 10배 생산성보다는 2배에 가깝다고 주장한다.

- 저자의 핵심 주장은 제목 그대로임. 2026년 LLM 코딩은 10배가 아니라 대략 2배 생산성에 가깝다는 것
  - LLM은 이미 “단위 테스트 작성보다 복잡한 일”에도 충분히 쓸모 있음
  - 그래도 소프트웨어 엔지니어가 곧 멸종할 정도는 아니라고 봄
  - 이유는 LLM이 잘하는 문제와 아직 못 미치는 문제가 꽤 선명하게 갈리기 때문임

- 저자는 LLM 채택이 늘어난 이유를 ‘자동 피드백 루프를 안정적으로 돌릴 수 있게 됐기 때문’이라고 설명함
  - 예전보다 모델이 좋아져서, “버튼을 만들고 클릭해서 X가 되는지 확인해” 같은 작업을 반복적으로 수행할 수 있음
  - 모델이 완전히 헤매지 않고 의미 있는 크기의 단계로 목표에 가까워지는 수준까지 왔다는 얘기임
  - 계단 비유도 나옴. 한 계단씩 오를 키가 되면 엄청난 변화지만, 두세 계단씩 오를 정도로 더 커지는 건 생산성에 같은 비율로 반영되지 않는다는 것

- 그래서 LLM은 명확하고 객관적인 수용 기준이 있는 코드에 강함
  - “이 버튼이 X를 해야 한다”, “테스트가 통과해야 한다”, “명시한 상태가 화면에 보여야 한다” 같은 조건이 있으면 좋음
  - 모델은 인간이 “이제 됐다” 또는 “아직 안 됐다”고 말할 상황을 꽤 잘 예측함
  - 이건 진짜 대단하지만, 모든 개발 업무가 이런 형태는 아니라는 게 포인트임

> [!IMPORTANT]
> 저자는 “작동하는 구현”의 의미가 바뀌었다고 말함. 예전에는 작업의 80%가 끝났다는 신호였지만, LLM이 만든 초안에서는 20% 정도 끝난 상태에 더 가깝다고 봄.

- LLM이 아직 약한 질문도 분명함
  - “이 코드를 더 유지보수하기 쉬운 구조로 만들 수 있나?”
  - “이 문서에 필요한 정보는 있고, 쓸데없는 정보는 빠졌나?”
  - 이런 판단은 자동 테스트처럼 명확히 참거짓으로 검증하기 어렵고, 모델이 충분히 믿을 만한 답을 주지 못한다고 봄

- 저자의 실제 사용 방식은 LLM에게 초안을 만들게 한 뒤, 구조가 마음에 들 때까지 사람이 크게 손보는 쪽임
  - 코드 줄 단위의 가독성은 조금 느슨해졌다고 농담하지만, 전체 구조 판단은 여전히 사람이 맡음
  - 특히 반복 수정 시간이 생각보다 오래 걸린다고 함
  - 이 지점이 10배 생산성 환상과 실제 체감 사이의 간극임

- 문서에 대해서는 꽤 강한 규칙을 제시함
  - “README, docstring, comment를 절대 쓰지 마. 나중에 내가 직접 쓸 거야. 진짜로.”
  - LLM 문서가 그럴듯하지만 필요한 정보와 불필요한 정보를 잘 가르지 못한다는 경험에서 나온 규칙임

- 앞으로의 생산성 향상은 모델 성능보다 도구와 워크플로에서 나올 거라고 봄
  - 저자는 LLM을 검색 대체재처럼 쓰다가, 채팅으로 코딩시키고, 이제는 원하는 최종 상태를 선언적으로 적는 방식으로 옮겨왔다고 함
  - 샌드박스 환경은 MVP급으로 중요하다고 말함. 30초마다 권한 승인하느라 멈추면 자동 루프가 깨지기 때문임
  - 산업 전체가 지금 모델이 잘하는 방식에 맞춰 도구를 다시 짜는 데서 더 큰 이득이 나올 수 있다는 주장임

- vibe coding에 대해서는 가능성을 열어두지만 조심스러움
  - 여기서 vibe coding은 코드를 전부 읽거나 이해하지 않고 생성된 코드를 쓰는 방식으로 정의함
  - 개인 프로젝트나 비프로덕션 작업에는 이미 해봤고 더 탐색해볼 생각이라고 함
  - 다만 장기적으로 중요한 인프라까지 블랙박스 LLM 코드에 맡길 수 있을지는 아직 모른다고 선을 그음

---

## 기술 맥락

- 이 글의 핵심 선택은 LLM을 ‘똑똑한 개발자’가 아니라 ‘검증 루프 안에서 움직이는 코드 생성기’로 보는 거예요. 그래서 테스트, 브라우저 클릭, 명확한 완료 조건이 있을 때 생산성이 크게 올라가요.

- 유지보수성 판단을 사람이 가져가는 이유도 여기 있어요. 테스트는 통과해도 구조가 나쁘면 다음 변경이 비싸지는데, 그 비용은 지금 당장 빨간불로 드러나지 않거든요.

- 샌드박스가 중요하다는 말은 단순 편의 얘기가 아니에요. 에이전트가 코드를 수정하고 실행하고 다시 고치는 루프를 계속 돌려야 하는데, 권한 확인이 자주 끼면 그 루프 자체가 제품성이 떨어져요.

- 문서를 LLM에게 맡기지 말라는 규칙은 꽤 실무적이에요. 문서는 코드처럼 테스트로 쉽게 검증되지 않아서, 그럴듯하지만 빠진 정보가 있는 상태로 머지되기 쉽거든요.

## 핵심 포인트

- LLM은 명확한 수용 기준과 자동 검증이 있는 작업에서 강함
- 작동하는 구현이 예전에는 80% 완료였지만, LLM 시대에는 20% 완료에 가깝다고 봄
- README, 주석, 문서 작성은 LLM에게 맡기지 말라는 개인 규칙을 제시
- 앞으로의 생산성 향상은 모델 성능보다 툴링과 워크플로 재설계에서 나올 가능성이 크다고 주장

## 인사이트

요지는 ‘모델이 더 똑똑해지면 다 해결’이 아니라, 지금 가능한 능력에 맞춰 개발 프로세스를 다시 짜야 한다는 쪽이다. 실무 개발자에게는 꽤 현실적인 체감담이다.