코딩이 해결되지 않은 이유: 프로덕션 소프트웨어에서 LLM의 한계

요약 – 코딩은 해결되지 않았다

LLM이 생성한 코드는 개발 속도를 높일 수 있지만, 소프트웨어 비용의 대부분은 신뢰성, 보안, 확장성과 같은 비기능적 요구사항(NFR)에서 발생합니다. 프로덕션 수준의 시스템은 여전히 코드를 이해하고 검증하며 책임을 질 수 있는 인간 엔지니어를 필요로 합니다. AI는 책임을 질 수 없기 때문입니다.

1. 핵심 주장: 코드 생성 ≠ 해결된 엔지니어링

생성은 저렴하지만 유지보수는 비싸다. 저자는 LLM이 코드 작성 비용을 낮추지만, 운영 비용의 대부분은 소프트웨어를 대규모로 유지하고 운영하는 데서 발생한다고 지적합니다.
비기능적 요구사항이 지배적이다. 보안, 신뢰성, 성능, 규정 준수와 같은 NFR은 단순한 LLM 출력물로는 거의 해결되지 않으며 깊은 도메인 전문 지식이 필요합니다.
논리 및 용량의 한계. LLM은 긴 문맥, 논리적 일관성, 결정론적 동작을 처리하는 데 어려움을 겪습니다. 확률적 특성 때문에 문법적으로는 올바르지만 미묘한 버그가 포함된 코드를 생성할 수 있습니다.
책임의 공백. AI는 처벌받거나 벌금을 물거나 법적 책임을 질 수 없습니다. 법적 및 조직적 책임은 소프트웨어를 배포하는 인간에게 남아 있습니다.

"통제할 수 없는 것에 대해 책임을 질 수는 없습니다. 시스템 동작을 추론하고 AI가 필연적으로 실패할 때 이를 수정하려면 이러한 이해가 핵심입니다." – @alex_ewerlof

2. 저자가 강조한 실제 위험

위험 영역	LLM이 부족한 이유
의료, 금융, 항공, 국방	오류가 생명을 앗아가거나 법적 처벌을 초래할 수 있음; AI는 필요한 엄격한 검증 파이프라인이 부족함.
보안	LLM은 숨겨진 취약점을 도입할 수 있음; 인간이 작성한 코드처럼 감사하기 어려움.
확장성	성능 회귀는 부하가 걸릴 때만 나타나는 경우가 많음; LLM은 모든 엣지 케이스 상호작용을 예측할 수 없음.
법적 책임	LLM에 책임을 물을 메커니즘이 없음; 조직이 모든 비난을 감수해야 함.

3. 현재 코딩에서 LLM이 작동하는 방식

프롬프트 → 모델 – 개발자가 자연어 사양을 제공합니다.
생성 → 하네스 – 모델이 코드를 생성하고, 이를 컴파일러, 린터, 테스트 스위트를 실행하는 하네스에 입력합니다.
피드백 루프 – 코드가 기본 검사를 통과할 때까지 오류가 모델로 다시 전송됩니다(종종 사고의 연쇄(chain-of-thought)나 도구 호출을 통해).
인간 검토 – 이상적으로는 개발자가 diff를 검사하고 NFR을 검증한 후 승인합니다.

저자는 고위험 도메인에서는 4단계가 필수적이라고 강조합니다.

4. Hacker News 커뮤니티 반응

4.1 동의하는 의견

@efficax는 LLM이 철저한 테스트와 퍼징을 자동화하여 신뢰성을 향상시킬 수 있다고 주장하지만, 저자의 견해가 제한적인 실무 경험에 기반한 것 같다고 지적합니다.
@lordnacho는 "소규모 코딩"(해결됨)과 "대규모 코딩"(해결되지 않음)을 구분하며, 아키텍처와 트레이드오프에 대한 인간의 판단이 필요하다는 점에 동의합니다.
@mstaoru는 엔지니어가 이제 코드를 입력하는 대신 AI를 지도하는 데 대부분의 시간을 보낸다는 점을 언급하며, 이는 역할이 사라지는 것이 아니라 변화하고 있다는 저자의 주장과 일치한다고 봅니다.

4.2 반대하는 의견

@brainless는 프로그래밍의 근본적인 재창조를 예견하며, LLM이 결국 현재의 언어와 프레임워크를 대체할 것이라고 제안합니다.
@manny_rat은 일상 업무에서 LLM이 생성한 코드는 최소한의 검토만 필요하며 10배의 생산성 향상을 가져온다고 보고하며, "고위험" 소프트웨어가 얼마나 흔한지 의문을 제기합니다.
@jpadkins는 많은 내부 도구의 경우 에이전트의 출력이 모든 정확성 표준을 충족하므로 코드 검토가 선택 사항이라고 주장합니다.
@bluegatty는 LLM이 컴파일러 피드백을 통해 학습되므로 컴파일러 수준의 완벽한 코드를 생성하는 데 능숙하다며 "논리" 비판에 반박합니다.

4.3 미묘한 관찰

AI 과다 복용 – 여러 댓글 작성자(@askonomm, @mywittyname 등)는 AI에 대한 과도한 의존이 개발자의 기술을 저하시키고 검토하기 어려운 거대한 PR을 초래할 수 있다고 경고합니다.
법적 책임 – @hibikir는 법적 시스템이 이미 AI로 인한 피해에 대해 조직에 책임을 묻고 있으므로, AI가 책임을 질 수 없다는 저자의 주장은 틀렸다고 지적합니다.
경제적 관점 – @__MatrixMan__은 AI가 생성한 맞춤형 소프트웨어의 비용 절감 효과가 많은 소규모 팀에게는 품질 문제보다 더 중요할 수 있다고 언급합니다.

5. 엔지니어와 리더를 위한 실질적인 조언

*LLM을 대체자가 아닌 보조자로 대우하십시오.* 코드를 스캐폴딩하거나 보일러플레이트를 생성하거나 대안을 탐색하는 데 사용하되, 항상 NFR을 검증하십시오.
하네스와 자동화된 테스트에 투자하십시오. 강력한 피드백 루프(컴파일러 → 테스트 스위트 → 모델)만이 결정론적 실패를 잡아낼 수 있는 유일한 방법입니다.
명확한 소유권을 유지하십시오. 지식, 권한, 책임이라는 세 가지 기둥은 규제 대상 도메인일수록 인간 엔지니어가 유지해야 합니다.
AI 과다 복용을 경계하십시오. 토큰 예산이 정해진 생성을 제한하고, 거대한 PR을 피하며, 기술 퇴보를 막기 위해 개인적인 코딩 연습을 계속하십시오.
인센티브를 조정하십시오. 기업은 AI가 생성한 서비스를 현실적으로 책정해야 합니다. 저렴한 AI를 사용하면서 "인간 수준"의 품질을 요구하며 비용을 청구하는 것은 신뢰를 떨어뜨릴 것입니다.

6. 향후 전망

모델 개선(더 큰 컨텍스트 윈도우, 더 나은 추론)은 논리적 격차를 줄이겠지만 완전히 제거하지는 못할 것입니다.
도메인별 에이전트(예: 보안 중심 LLM)가 일부 NFR 격차를 메울 수 있지만, 여전히 인간의 감독이 필요할 것입니다.
규제 압력이 증가하여 고위험 분야에서 AI 생성 코드에 대한 감사 추적과 책임을 의무화할 가능성이 높습니다.
기술 진화 – 엔지니어는 단순한 코더가 아니라 프롬프트 엔지니어, AI 오케스트레이터, 품질 관리자가 될 것입니다.

7. 결론

LLM이 코드 생성의 장벽을 크게 낮췄지만, 소프트웨어 엔지니어링의 본질적인 과제인 신뢰성 유지, 보안 보장, 책임 이행은 여전히 해결되지 않았습니다. HN 토론은 개발자 역할의 단기적 변화를 보는 시각과 저자가 현재 모델의 능력을 과소평가하고 있다는 시각으로 나뉩니다. 입장이 무엇이든, 프로덕션 수준의 소프트웨어에는 여전히 인간의 전문 지식이 필수적이라는 점은 분명합니다.