LLM 코딩 도구를 쓰면서 “코드가 빨리 나오는데 왜 일이 줄지 않을까”라는 의문을 가진 적 있으신가요? 1986년에 이미 이 질문에 답한 컴퓨터과학자가 있었습니다. 그리고 2026년의 데이터는 그의 예측이 옳았음을 보여주고 있습니다.
출처: Let’s talk about LLMs – James Bennett (b-list.org)
소프트웨어의 어려움에는 두 종류가 있다
소프트웨어 공학자 Fred Brooks는 1986년 논문 No Silver Bullet에서 소프트웨어 개발의 어려움을 두 가지로 분류했습니다. 하나는 ‘우발적 난이도(accidental difficulty)’, 다른 하나는 ‘본질적 난이도(essential difficulty)’입니다.
우발적 난이도는 제거 가능한 어려움입니다. 메모리를 수동으로 관리해야 했던 C 언어의 불편함, 반복적인 보일러플레이트 코드처럼 더 좋은 도구가 나오면 줄어드는 것들이죠. 실제로 지난 수십 년간 높은 수준의 언어와 프레임워크들이 이런 우발적 어려움을 꾸준히 제거해왔습니다.
본질적 난이도는 다릅니다. “무엇을 만들 것인가를 정확히 정의하는 것”, “서로 맞물리는 개념들의 구조를 설계하는 것”, “만든 것이 실제로 원하는 대로 작동하는지 검증하는 것”—이것들은 어떤 도구를 써도 사라지지 않는 어려움입니다. Brooks는 이것이 소프트웨어의 본질적인 속성이라고 봤습니다.
그리고 결정적인 수학적 주장을 내놓습니다. 만약 우발적 난이도가 전체 작업의 90%를 차지하지 않는다면, 그것을 완전히 제거해도 생산성이 10배 향상되는 것은 불가능하다고요. Brooks는 이미 많은 우발적 어려움이 제거된 성숙한 개발 환경에서 남은 우발적 난이도는 전체의 극히 일부에 불과하다고 판단했습니다.
코드가 더 빨리 나온다고 소프트웨어가 더 빨리 완성될까
James Bennett은 b-list.org에서 이 40년 전 논증이 LLM 코딩 도구에 그대로 적용된다고 주장합니다. LLM의 핵심 가치는 코드를 빠르게 생성하는 것인데, 문제는 코드 생성 속도가 소프트웨어 개발의 병목이 아니라는 점입니다.
The Mythical Man-Month에서 Brooks는 소프트웨어 작업 시간의 약 83%가 코딩 이외의 활동—요구사항 파악, 사양 정의, 설계, 테스트, 리뷰, 반복—에 쓰인다고 추산했습니다. Tailscale CEO도 최근 비슷한 맥락의 글을 썼습니다. Claude가 30분 걸릴 코드를 3분에 만들어준다 해도, 그 코드를 리뷰하는 데 여전히 27분이 걸리거나, 검토 없이 제출하면 코드 리뷰어가 5시간을 써야 한다고요.
코드 생성이 빨라져도 검토 큐의 처리 속도는 그대로라는 점—이게 핵심입니다.
이론이 아니라 데이터가 말한다
Bennett은 여기서 멈추지 않고 실증 데이터를 들여다봅니다. LLM 도입을 긍정적으로 평가하는 쪽으로 알려진 DORA 보고서와 CircleCI의 2026년 보고서를 기준으로 삼았을 때조차, 결과는 복잡합니다.
DORA 보고서는 LLM 도입 후 처리량이 소폭 증가했다고 인정하면서도, 배포 불안정성이 함께 상승했다고 지적합니다. 여기서 ‘배포 불안정성’이란 배포 후 즉각적인 개입이 필요한 사례와 장애로 인한 비계획 재배포의 비율을 말합니다. DORA는 이 불안정성 증가가 처리량 향상으로 상쇄되지 않는다고 결론 내렸습니다. 오히려 제품 성능 저하와 번아웃이라는 더 심각한 결과를 낳는다고요.
CircleCI 보고서는 더 구체적입니다. 메인 브랜치 성공률이 5년 만에 최저치인 70.8%로 떨어졌고, 장애 복구 시간은 전년 대비 13% 늘었습니다. 하루 5번 배포하는 팀이 성공률 90%에서 70%로 떨어지면, 이틀에 한 번 발생하던 심각한 장애가 하루 1.5번으로 세 배 늘어납니다. 복구 시간을 60분으로 잡으면, 연간 250시간이 추가로 디버깅과 차단된 배포에 소비된다는 계산이 나옵니다.
흥미로운 점은 생산성과 코드 품질 향상을 보고한 수치들이 대부분 ‘개발자 자기 응답’ 기반이라는 것입니다. METR의 연구에서는 LLM 사용 후 실제로 속도가 느려진 개발자들이 사용 후에도 여전히 속도가 빨라졌다고 믿었다는 결과가 나왔습니다. 자기 보고 방식의 생산성 측정이 얼마나 신뢰하기 어려운지를 단적으로 보여주는 사례입니다.
“지금 쓰지 않으면 도태된다”는 논리에 대해
Bennett은 또 하나의 논점—”지금 LLM 안 쓰면 뒤처진다”—도 분석합니다.
이 주장이 성립하려면 LLM 코딩이 실제로 혁명적이어야 합니다. 만약 회의론이 맞다면, 늦게 도입해도 별다른 손해가 없습니다. 반대로 LLM이 진짜 혁명적으로 변한다면, 그 변화는 현재의 LLM 워크플로우 자체를 완전히 바꿔놓을 만큼 근본적인 것이어야 합니다. 그 경우에도 기존 LLM 경험이 극복 불가능한 우위를 주기는 어렵습니다.
어느 쪽이든, 지금 당장 LLM 도입을 서두르지 않는다고 치명적인 손해가 생긴다는 논리는 성립하기 어렵습니다.
LLM 코딩이 가져다줄 수 있는 이점은 분명 있습니다. 하지만 그것이 소프트웨어 개발의 본질적 어려움—무엇을 만들지 정의하고, 설계하고, 검증하는 일—을 해결해주지 않는 한, 기대할 수 있는 것은 점진적이고 부분적인 개선입니다. 40년 전 Brooks가 예측한 범위를 벗어나지 않는 수준에서.
참고자료:
답글 남기기