TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 30 READS

'10배'가 아니라 '2배': LLM 코딩의 현실적 천장에 관한 한 개발자의 가설

'10배'가 아니라 '2배': LLM 코딩의 현실적 천장에 관한 한 개발자의 가설
SOURCE IMAGE · HACKER NEWS

인공지능이 소프트웨어 개발을 뒤바꾼다는 이야기는 이제 새롭지 않다. 다만 그 변화의 크기를 어떻게 가늠할지에 대해서는 여전히 과장과 냉소가 뒤섞여 있다. 한 현업 엔지니어가 블로그(obryant.dev)에 올린 글은 이 논쟁에 흥미로운 각도를 제시한다. 그는 2026년 7월 시점에서 자신의 직접 경험만을 근거로, 대규모 언어모델(LLM)이 코딩 생산성을 분명히 끌어올렸지만 그 폭은 대략 '2배'이며 흔히 회자되는 '10배'와는 거리가 있다고 주장한다. 그리고 앞으로 모델 성능이 더 좋아진다고 해서 그 격차가 쉽게 메워지지는 않을 것이라는 가설을 덧붙인다.

계단 비유가 말하는 것

글쓴이의 핵심 논지는 '계단 비유'로 요약된다. 계단을 오르려면 최소한 한 칸을 딛을 만큼의 키는 있어야 하지만, 두세 칸을 한 번에 밟을 만큼 크다고 해서 얻는 이득은 훨씬 작다는 것이다. 그가 보기에 2026년 들어 LLM 도입이 급증한 진짜 이유는 모델이 갑자기 천재가 되어서가 아니라, 자동화된 피드백 루프 안에서 안정적으로 돌아갈 만큼 신뢰도가 올라섰기 때문이다. 즉 '한 칸을 딛을 키'라는 문턱을 넘어선 것이 결정적이었고, 그 문턱을 넘은 이후의 추가 성능 향상은 생산성에 미치는 영향이 상대적으로 작아진다는 논리다.

LLM이 코딩에 쓸모 있는 이유도 같은 맥락에서 설명된다. "X를 하는 버튼을 만들고, 그 버튼을 눌러 실제로 X가 되는지 확인하라"고 지시하면, 모델은 방향을 잃고 헤매는 대신 의미 있는 단위로 목표를 향해 반복 수정해 나간다. 더 중요한 것은 인간이 "그래, 버튼이 이제 X를 한다"고 판단할 시점을 꽤 정확히 예측한다는 점이다. 결국 LLM은 명시적으로 주어진, 쉽게 그리고 객관적으로 검증 가능한 수용 기준을 충족하는 코드를 만들어내는 데 강하다.

'작동하는 코드'는 이제 시작점일 뿐

그러나 이 강점은 곧 한계의 경계선이기도 하다. 정답을 충분한 정확도로 예측할 수 없는 질문, 즉 구조를 어떻게 잡을지나 무엇이 유지보수하기 좋은 코드인지 같은 판단에서는 여전히 사람의 손이 필요하다. 글쓴이는 그래서 LLM을 주로 초안 생성기로 쓰고, 전체 구조가 마음에 들 때까지 그 위에서 무겁게 반복 작업을 한다고 밝힌다. 특히 그가 강조하는 체감의 변화가 인상적이다. 예전에는 동작하는 구현이 나오면 작업이 80% 끝난 것으로 느껴졌지만, 지금은 오히려 20% 지점에 가깝다는 것이다. 초안 이후의 다듬는 시간을 매번 과소평가하게 된다는 고백은 많은 실무자에게 익숙할 법하다.

문서화에 대한 그의 처방도 실용적이다. 그는 모델에 "README, 독스트링, 주석을 절대 쓰지 말라. 그것들은 내가 나중에 직접 쓰겠다. 진심이다"라고 지시하는 것만으로 출력 품질이 크게 좋아졌다고 말한다. 모델이 채워 넣는 설명성 텍스트가 오히려 방해가 되는 경우가 많다는 뜻이다. 이는 도구를 무조건 신뢰하기보다, 잘하는 영역과 못하는 영역을 구분해 역할을 좁혀 주는 편이 낫다는 실무 감각을 보여준다.

다음 도약은 모델이 아니라 도구에서

여기서 자연스러운 반론이 나온다. 지난 1년간 이만큼 좋아졌으니 내년이면 문서화나 유지보수성 있는 코드까지 잘하게 되지 않겠느냐는 낙관이다. 하지만 계단 가설을 받아들인다면 그 기대는 훨씬 불확실해진다. 글쓴이의 표현을 빌리면, 높은 계단을 오를 수 있다고 해서 헤엄을 칠 수 있는 것은 아니다. 그는 앞으로의 생산성 향상 대부분이 모델 자체의 발전이 아니라, 이미 손에 쥔 현재 수준의 능력에 맞춰 업계가 도구와 작업 흐름을 재정비하는 과정에서 나올 것이라고 본다.

실제로 그 자신의 사용 방식도 진화해 왔다. 검색엔진이나 스택오버플로 대체품처럼 쓰던 단계에서, 대화형 채팅으로 코드를 짜게 하는 단계를 거쳐, 원하는 최종 상태를 선언적 명세로 기술하는 방식으로 옮겨갔다. 30초마다 권한을 승인해 줄 필요가 없도록 샌드박스 환경을 마련한 것도 최소한의 필수 요소였다고 말한다. 이는 워크플로와 툴링을 다듬을 여지가 아직 많다는 방증이다.

한편 그는 코드를 다 읽고 이해하지 않은 채 생성하는 이른바 '바이브 코딩'을 업무 외 영역에서 시도해 봤다고 덧붙인다. 아직 장기간의 검증 사례가 없으니 이 접근이 얼마나 지속 가능한지는 알 수 없지만, 특정 테스트 관행이나 도구가 뒷받침된다면 중요한 인프라에서도 블랙박스 코드를 안전하게 신뢰할 길이 열릴지 모른다고 열어 둔다. 어쩌면 LLM의 근본적 약점을 우회하는 방식으로 10배에 도달할 가능성도 배제하지 않는 셈이다. 다만 그때가 오기 전까지 자신은 직접 손으로 쓴 README를 고수하겠다는 문장으로 글을 맺는다. 도구의 한계를 냉정하게 인정하면서도 그 위에서 무엇을 재설계할지를 고민하는 태도가, 지금 이 기술을 다루는 현업의 온도에 가장 가깝다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://obryant.dev/p/2x-not-10x/
SHARE
처리 중...