2x, not 10x: 2026년 LLM을 활용한 코딩

지난 6개월 동안 제가 스스로에 대해 깨달은 점이 하나 있다면, 만약 해리 포터가 허구가 아니고 마법이 실제로 존재한다는 사실을 발견하게 된다면 저의 반응은 대략 이럴 것이라는 점입니다. "음, 흥미롭긴 한데, 이 마법이라는 게 유닛 테스트 (unit tests) 작성보다 더 복잡한 작업에도 도움이 될 만한 건가요?"

LLM (Large Language Models)은 확실히 그 유용성의 임계점을 넘었습니다. 비록 2026년 7월 현재, 오로지 저의 직접적인 관찰에 근거했을 때, LLM은 여전히 근본적인 한계를 가지고 있으며, 이로 인해 저는 "소프트웨어 엔지니어 (Software Engineer)"라는 직업이 멸종할 경우를 대비한 차선책으로 목공을 시작하지는 않았습니다. LLM이 왜 유용해졌는지에 대한 저의 정신적 모델 (mental model)에 따르면, 이러한 상황이 조만간 바뀔 것 같지는 않습니다. 저의 가설은 다음과 같습니다:

2026년에 LLM의 채택률이 증가한 주된 이유는 LLM이 자동화된 피드백 루프 (automated feedback loops) 내에서 효과적으로 작동할 만큼 충분히 신뢰할 수 있게 되었기 때문입니다. 이제 LLM이 그 임계점을 넘었기 때문에, 모델 성능의 추가적인 향상은 이전보다 생산성에 미치는 영향이 훨씬 작을 것입니다.

비유를 들자면, 계단을 올라가기 위해서는 한 번에 적어도 한 계단은 오를 수 있을 만큼 키가 커야 하지만, 한 번에 두세 계단을 오를 수 있을 정도로 키가 큰 것은 훨씬 덜 중요합니다.

LLM이 코딩에 유용한 이유는 "X를 수행하는 버튼을 만들고, 그 버튼을 클릭해서 실제로 X를 수행하는지 확인해줘"라고 명령할 수 있기 때문입니다. LLM은 갈팡질팡하는 대신 의미 있는 크기의 단계로 그 목표를 향해 반복 (iterate)할 수 있으며, 사람이 "그래, 이제 버튼이 X를 수행해" 또는 "아니, 버튼이 아직 X를 수행하지 않아"라고 말할 시점을 신뢰성 있게 예측할 수 있습니다. 따라서 LLM은 사용자가 명시적으로 제공하는, 쉽고 객관적으로 검증 가능한 수락 기준 (acceptance criteria)을 충족하는 코드를 생성하는 데 유용합니다.

그리고 그것은 놀라운 일입니다. 엄청나고, 인생을 바꿀 만한 일이죠. 어쩌면 2배 (2x)의 향상일지도 모릅니다. 하지만 이 분야에는 여전히 중요한 질문들이 남아 있으며, 그 답은 제 의견으로는 유용할 만큼 충분한 정확도로 LLM이 예측할 수 없습니다. 예를 들면 다음과 같습니다:

• "이 코드를 구조화하는 더 유지보수하기 쉬운 방법이 있을까요?"
• "이 문서가 적절한 정보를 포함하고 불필요한 정보를 생략하고 있나요?"

따라서 저는 주로 LLM을 사용하여 코드의 초안 (rough draft)을 생성하는 데 사용하며, 적어도 제가 전반적인 구조가 마음에 들 때까지는 이를 바탕으로 대대적인 반복 작업 (iterate)을 수행합니다. 개별 라인이나 함수(function)의 가독성에 대해서는 다소 소홀했을 수도 있습니다. (제 동료들이 이 글을 읽을 경우를 대비해 이 정도의 유보 조항은 두어야겠습니다). 그리고 라인 수준의 소홀함에도 불구하고, 저는 여전히 그 반복 작업에 시간이 얼마나 걸릴지를 지속적으로 과소평가하곤 합니다. 예전에는 작동하는 구현 (working implementation)이 완료된 작업의 80%를 의미했다면, 이제는 20% 정도에 불과합니다.

문서화 (documentation)에 관해서는, LLM의 결과물을 크게 개선할 수 있는 간단한 지침을 발견했습니다:

README, 독스트링 (docstrings), 또는 주석 (comments)을 절대 작성하지 마세요. 그것들은 나중에 제가 직접 작성하겠습니다. 네, 정말로 진심입니다.

이러한 한계에 대해 잠재적으로 합리적인 반응은 "LLM은 지난 1년 동안 엄청나게 발전했으며, 따라서 향후 1년 동안의 개선을 통해 좋은 문서와 유지보수 가능한 코드를 작성하는 능력이 훨씬 더 좋아질 것이다"라고 말하는 것일 수 있습니다. 하지만 만약 여러분이 저의 계단 가설 (staircase hypothesis)을 받아들인다면, 그러한 반응은 훨씬 덜 확실해집니다. 높은 계단을 오를 수 있다고 해서 수영을 할 수 있다는 뜻은 아니기 때문입니다.

그래서 저의 현재 추측은, 모델의 추가적인 개선만으로는 2025년이라는 암흑기 대비 10배의 생산성 향상을 달성하기 어려울 것이라는 점입니다. 대신, 가까운 미래의 대부분의 생산성 이득은 우리가 이미 오늘날 보유하고 있는 모델의 능력에 맞춰 산업계가 재편 (retooling)되는 과정에서 올 것이라고 생각합니다.

저는 이 분야의 얼리어답터(early adopter)는 아닙니다. 지금까지 저는 LLM을 단순한 검색 엔진이나 Stack Overflow의 대체재(고인의 명복을 빕니다)로 사용하는 단계에서, 대화형 채팅을 통해 코드를 작성하게 하는 단계로, 그리고 제가 원하는 최종 상태에 대한 선언적 명세(declarative specifications)를 작성하는 단계로 발전해 왔습니다. 또한 샌드박스 환경(Sandboxed environments)은 제가 30초마다 LLM에 무언가를 수행할 권한을 부여하지 않아도 되도록 하는 MVP(Minimum Viable Product, 최소 기능 제품) 역할을 해왔습니다. 이와 관련된 워크플로우(workflows)와 툴링(tooling)을 개선하기 위해 해야 할 작업이 아주 많이 남아 있습니다.

저는 또한 업무 외적인 용도나 프로덕션(production) 환경이 아닌 것들을 위해 약간의 바이브 코딩(vibe coding, 제가 정의하기로는 "코드를 전부 읽거나 이해하지 않고 생성하는 것")을 해보기도 했습니다. 업무 외적으로 그 영역을 더 탐구해보고 싶으며, 물론 이미 많은 사람이 열정적으로 앞서 나가고 있습니다. 아직 장기적인 관점이 존재하지 않았기에 그 접근 방식이 장기적으로 얼마나 실행 가능한지는 알기 어렵습니다. 하지만 말하자면, 어쩌면 가능성이 있을지도 모릅니다. 특정 테스트 관행(test practices)이나 툴링 등이 갖춰진다면, 핵심 인프라를 운영하는 데 있어서도 블랙박스(black-box) 형태의 LLM 코드를 신뢰하는 것이 안전해질 수도 있습니다. 어쩌면 LLM의 근본적인 약점을 우회함으로써 10배의 개선을 이뤄낼 수도 있을 것입니다.

하지만 그동안 저는 제가 직접 작성한 README 파일들을 고수할 것입니다.

2026년 7월 25일 발행