예전엔 코드가 일단 작동하면 작업의 80%가 끝난 셈이었습니다. AI로 코드를 짜기 시작한 뒤로는, 작동하는 코드가 나와도 이제 겨우 20%를 지난 느낌이라고 합니다.

개발자 제이콥 오브라이언트가 지난 6개월간 AI로 코드를 짜온 경험을 정리한 글에서 이렇게 말합니다. LLM이 확실히 유용해졌다는 건 인정하지만, 흔히 말하는 “생산성 10배”는 자신의 체감과 다르다는 것이죠. 대신 그는 왜 딱 그 정도, 2배 수준에서 멈추는지에 대한 나름의 가설을 내놓습니다.

출처: 2x, not 10x: coding with LLMs in 2026 – Jacob O’Bryant

계단은 오를 수 있어도, 수영은 못 한다

오브라이언트의 가설은 이렇습니다. LLM이 요즘 폭발적으로 쓰이게 된 이유는 모델이 똑똑해져서라기보다, “자동화된 피드백 루프 안에서 믿고 돌릴 수 있을 만큼” 신뢰도가 어떤 문턱을 넘었기 때문이라는 것이죠. 일단 그 문턱을 넘고 나면, 모델 성능이 더 좋아져도 생산성에 미치는 영향은 예전만큼 크지 않다는 게 그의 설명입니다.

그는 이걸 계단에 비유합니다. 계단을 오르려면 최소한 한 칸씩은 올라갈 수 있는 키가 되어야 하죠. 하지만 그 이상으로 키가 커서 한 번에 두세 칸씩 오를 수 있다고 해도, 별로 중요하지 않습니다. LLM이 코딩에 쓸모 있어진 것도 비슷한 이치입니다. “이런 버튼을 만들어줘, 그다음 눌러서 제대로 작동하는지 확인해줘”처럼 목표가 명확하고 검증 가능하면, LLM은 그 목표를 향해 의미 있는 단위로 반복 개선해 나갑니다. 사람이 “됐다”고 판단할 시점을 꽤 정확히 예측하는 것이죠.

문제는 그 다음입니다. “이 코드를 더 유지보수하기 좋게 구조화하는 방법이 있을까”, “이 문서에 꼭 필요한 내용만 담겼나” 같은 질문에는 LLM이 아직 충분히 정확한 답을 내놓지 못한다고 그는 말합니다. 계단은 오를 수 있어도 수영은 못 하는 것과 비슷한 상황이죠. 그래서 앞으로 모델 성능이 더 올라간다고 해서 이 부분까지 저절로 좋아질 거라 낙관할 수는 없다는 겁니다.

작동하는 코드는 이제 완료의 20%

이런 판단 때문에 오브라이언트의 실제 작업 방식도 바뀌었습니다. AI에게는 코드의 초안만 맡기고, 구조가 마음에 들 때까지는 직접 대대적으로 고쳐 쓰죠. 개별 줄이나 함수 단위의 가독성은 다소 느슨하게 넘어가는 편이라고 인정하면서도, 그 이후 다듬는 과정에 걸리는 시간을 매번 과소평가한다고 털어놓습니다. 예전엔 일단 작동하는 구현이 나오면 작업의 80%가 끝난 셈이었는데, 지금은 오히려 20% 정도 지난 느낌이라는 겁니다.

문서화도 마찬가지입니다. 그는 AI에게 “README나 docstring, 주석은 절대 쓰지 마라, 그건 내가 나중에 직접 쓰겠다”고 아예 못박아 지시하죠. 이 한 문장을 넣은 뒤로 결과물이 눈에 띄게 나아졌다고 합니다. AI가 스스로 판단해서 쓴 문서보다, 사람이 필요한 만큼만 골라 쓰는 쪽이 낫다는 뜻입니다.

10배로 가는 길은 모델이 아니라 도구에 있다

오브라이언트는 앞으로 남은 생산성 개선은 모델 자체의 발전보다, 지금 있는 모델 성능을 중심으로 업계가 도구와 작업 방식을 다시 짜는 데서 나올 거라 내다봅니다. 그는 스스로도 이 변화의 얼리어답터는 아니라고 말하죠. 검색엔진 대용으로 LLM을 쓰던 단계에서, 채팅으로 대화하며 코드를 짜는 단계를 거쳐, 지금은 원하는 결과물을 미리 선언해두는 방식까지 왔다는 겁니다. 30초마다 AI에게 권한을 새로 승인해줄 필요가 없도록 샌드박스 환경을 갖춘 것도 큰 도움이 됐다고 합니다.

업무 외 개인 프로젝트에서는 코드를 읽거나 이해하지 않고 그냥 생성만 하는 이른바 “바이브 코딩”도 시도해봤다고 합니다. 다만 이 방식이 장기적으로 얼마나 안정적일지는 아직 판단하기 이르다는 입장이죠. 어쩌면 특정 테스트 관행이나 도구가 갖춰지면 블랙박스 같은 AI 코드를 핵심 인프라 운영에까지 믿고 맡길 수 있는 날이 올지도 모른다고 여지를 남기면서도, 정작 자신은 당분간 직접 손으로 다듬은 문서와 코드 구조를 고수하겠다고 말합니다.