코딩은 아직 해결되지 않았습니다

AI 요약

Alex Ewerlöf는 AI에 반대하는 것이 아니라, “코딩은 해결됐다”는 주장에 반론을 제기합니다. LLM 코딩 도구와 AI 제품을 직접 만들어 온 경험을 바탕으로, 코드 생성 비용이 낮아진 사실과 소프트웨어 엔지니어링 전체가 자동화된다는 주장은 구분해야 한다고 말합니다.

코드 생성과 소프트웨어 엔지니어링

글은 개인용 자동화나 개념 증명(POC)처럼 실패 비용을 감수할 수 있는 작업과, 의료·금융·항공·제조처럼 오류가 금전적 손실이나 인명 피해로 이어질 수 있는 제품을 나눕니다. 후자에서는 기능 요구사항뿐 아니라 신뢰성, 보안, 확장성, 유지보수성 같은 비기능 요구사항(NFR)을 지켜야 합니다. 저자는 AI가 생성한 코드도 결국 출시한 사람이 이해하고 책임져야 한다고 강조합니다. AI 자체에는 벌금이나 형사 처벌 같은 책임을 물을 수 없기 때문입니다.

LLM은 확률적으로 출력을 만듭니다. 코딩 도구는 컴파일 오류와 테스트 결과를 모델에 돌려주는 피드백 루프, 하네스(harness), 도구 호출 등을 붙여 오류를 줄입니다. 하지만 저자는 자연어 지시의 모호함과 상충, 긴 입력에서의 정확도 저하, 실행 중 예측하기 어려운 결과가 남는다고 봅니다. 테스트 통과만으로 코드의 설계가 적절한지, 제품 요구를 제대로 담았는지까지 확인했다고 볼 수는 없다는 주장입니다.

이해와 책임이 엔지니어의 일입니다

저자는 명세를 처음부터 완벽하게 작성하기 어렵고, 자연어가 프로그래밍 언어를 대체하기에도 모호하다고 지적합니다. 좋은 엔지니어는 문제의 이유와 사용자의 필요를 먼저 파악한 뒤 해결책을 탐색하며, 코드는 그 과정에서 나온 결과물이라는 설명입니다. 따라서 코드 작성 속도만으로 생산성을 재거나, PR 수와 코드 줄 수를 성과 지표로 삼으면 안 된다고 말합니다. 토큰 비용과 사업 가치 사이에 실제 이익이 있는지, 서비스 수준과 사용자 만족도가 나아졌는지를 봐야 한다고 제안합니다.

글은 소프트웨어 소유권에 지식, 권한, 책임이라는 세 요소가 필요하다고 정리합니다. 무엇을 만들고 어떻게 작동하는지 알아야 하며, 판단할 권한이 있어야 하고, 문제가 생기면 대응할 책임도 져야 합니다. AI에 코드를 맡겨도 이 책임은 사라지지 않습니다. AI가 만든 대량의 변경 사항을 검토하지 않은 채 병합하면, 검토 비용과 장애 대응 비용이 생성 속도의 이점을 상쇄할 수 있다고 경고합니다.

비용과 품질의 균형

저자는 AI가 사람보다 훨씬 빠르고 저렴하게 코드를 만드는 경우도 인정합니다. 위험이 낮고 요구가 특수한 작업이라면 직접 만드는 편이 경제적일 수 있습니다. 반대로 안정적인 서비스와 서비스 수준 협약(SLA)이 필요한 기업은 SaaS를 구매하는 편이 총소유비용(TCO) 면에서 나을 수 있다고 설명합니다. AI가 소프트웨어 제작 비용을 낮추면 기존 업체도 사람 개발자의 비용을 기준으로 가격을 매기기 어려워집니다. 업체는 가격을 낮추거나, 경험 있는 엔지니어의 검증과 운영 품질을 차별점으로 삼아야 한다는 주장입니다.

AI 사용에 따른 데이터 위험도 다룹니다. 클라우드 AI에 업무 지식과 데이터를 제공할 때는 학습이나 저장에 쓰일 가능성과 업체의 유인을 고려해야 한다고 말합니다. 로컬 모델은 하드웨어와 설정 비용이 들고 성능이 낮을 수 있지만, 데이터가 기기 밖으로 나가지 않는 장점이 있습니다. 저자는 앞으로 엔지니어의 역할이 기술 제품 관리자, AI 관리자, AI 배포 엔지니어, AI 품질 엔지니어 등으로 나뉠 수 있다고 제안합니다.

Hacker News 반응

• @hanifbbz — 글쓴이입니다. 이곳에 공유해 주셔서 감사합니다. 이 커뮤니티의 거센 비판과 비판적 사고가 좋습니다. 이런 글이 감정을 자극한다는 점도 알고 있습니다. 누구의 작업 방식도 바꾸려는 게 아닙니다. 서비스 품질이 떨어지는데도 정가를 내는 상황에 지쳤습니다. 지난주에는 GitHub가 어리석은 재시도 오류로 중단됐습니다. AI 에이전트가 통제를 벗어나 기업과 정부를 해킹한 사례도 있습니다. AI에 반대하는 게 아니라, 엉성한 결과물을 진보라고 내세우는 데 지쳤습니다. 반론이 있거나 제가 더 배울 수 있도록 돕고 싶다면 듣겠습니다.
  • @boxed — GitHub는 LLM이 나오기 전에도 여러 번 중단됐고, 그때는 지금처럼 기하급수적으로 성장하지도 않았습니다. 상황이 어려워졌다는 점은 빼고 문제가 있었다는 사실만 따지면 나쁘게 보일 수 있지만, 제 생각에는 공정한 비교가 아닙니다.
• @N_Lens — 투자자들이 계속 돈을 쏟아붓는 한, “코딩은 해결됐다”는 말은 언제나 6개월 뒤의 일이 될 겁니다.
  • @xnorswap — 코딩의 의미를 계속 바꾸는 한 그렇겠죠.
• @federicobrancas — 코딩은 해결됐지만 소프트웨어 엔지니어링은 해결되지 않았습니다.
  • @flohofwoe — 두 단어는 같은 것을 가리킵니다. “코딩”을 명세를 소스 코드로 바꾸는 일로만 보고 엔지니어링 판단은 필요 없다고 보는 생각은 우스웠습니다. 그렇게 하려면 명세가 소스 코드만큼 자세해야 합니다.
  • @ben_w — LLM은 제 지난 20년간 유급으로 작성한 코드를 전부 쓸 수 있습니다. 하지만 프로젝트 계획과 자기 검증은 아직 맡기기 어렵습니다. 코딩과 소프트웨어 엔지니어링은 같은 일이 아닙니다.
• @vatsachak — 코딩은 해결되지 않았지만, 이 글은 Opus 5.5를 고려하지 않았습니다. LLM의 장기 계획 능력은 아직 해결되지 않았습니다.
  • @hanifbbz — Opus 5.5가 똑똑하고 다음 버전은 더 똑똑해질 거라고 생각합니다. 글의 핵심은 책임이며, 그 책임을 AI에 넘길 수 없다는 점입니다.
• @askonomm — AI는 게으르고 실력 없는 개발자를 더 게으르고 실력 없게 만듭니다. 코드가 쏟아지면서 사람이 현실적으로 검토하기 어려워지고 코드 리뷰도 사실상 무력해집니다. AI가 코드를 만들고 AI가 리뷰하는 방식으로는 결정론적 결과를 기대하기 어렵습니다. 저도 매일 AI를 쓰며, 게으르거나 무능하지 않다면 고품질 소프트웨어를 만들 수 있다고 봅니다.
  • @whatever1 — 당신이 유능하더라도 LLM 이전에 하루 100줄을 쓰다가 지금 하루 5,000줄을 쓴다면, 그 코드를 제가 검토할 수는 없습니다.
  • @hanifbbz — 다시 말해 AI는 증폭기입니다.
  • @huijzer — 다른 사람에게 AI를 가르칠 때 이렇게 말합니다. 좋은 도구가 될 수 있지만 결과를 확인해야 합니다. 특히 엔지니어링에서는 확인하고 또 확인해야 합니다.
• @hibikir — “통제하지 못하는 일에는 책임질 수 없다”는 전제는 적절하지 않습니다. 법에서는 자신이 직접 통제하지 못하는 대상에도 책임을 지는 경우가 많습니다. 개가 아이를 다치게 하거나 안전하지 않은 장난감을 판매한 사례처럼, AI가 저지른 일이나 AI가 쓴 코드를 배포한 책임도 물을 수 있습니다.
  • @hanifbbz — 법적으로 통제하는 사람이 책임을 집니다. 개나 안전하지 않은 장난감의 사례가 그 점을 보여줍니다. 차이는 일부 기업이 법 위에 있는 듯 보인다는 겁니다.
• @gradus_ad — 코드를 쓰는 과정은 자기 생각을 명확히 하고, 미처 몰랐던 질문에 답하는 과정입니다. AI가 가정을 하면 버그와 잘못된 코드를 만들 수 있습니다. 반대로 질문을 한다면 무엇을 가정해도 되는지 AI가 안다는 전제가 필요하지만, 항상 그렇지는 않습니다.
  • @hanifbbz — “AI는 설명할 수 있지만, 대신 이해해 줄 수는 없습니다.” 코드는 생각을 명확히 한 결과입니다. LLM은 컴파일러의 제약을 받지 않고 코드를 내놓다가, 오류를 돌려받고 반복하는 피드백 루프를 거치며 문법 오류와 테스트를 통과합니다. 그 뒤에도 개발자가 결과를 확인하고 명세에서 빠진 부분을 다듬어야 합니다.
• @vmg12 — AI는 CRUD API나 퀵소트, 힙 같은 코드를 빠르게 작성합니다. 하지만 타입과 API를 설계하고 시스템이 앞으로 어떻게 진화할지 계획하는 일에는 약합니다. 대규모 소프트웨어를 체계적으로 만들고 확장하는 능력을 학습시키려면 훈련 환경부터 만들어야 하므로 시간이 걸릴 것 같습니다.
• @efficax — 코드를 읽는다고 코드를 이해하는 것은 아닙니다. LLM으로 가능한 실행 경로를 찾고 퍼저와 속성 기반 테스트를 만들고, 모든 시나리오를 실행해 추적과 출력을 분석할 수 있습니다. 이런 작업에 자원을 투입하면 AI가 만든 소프트웨어의 신뢰성을 높일 수 있습니다. 저는 어렵고 큰 코드도 많이 작성해 봤으며, 품질을 중요하게 생각하기 때문에 LLM 코딩을 적극적으로 사용합니다.
  • @grumple — 저도 많이 사용하고 코드 작성과 검토 시간을 크게 줄입니다. 제가 놓치는 점도 찾아냅니다. 다만 LLM은 문제를 해결했다고 자신 있게 말하거나 기능을 설명하면서 틀리는 경우가 있습니다. 사람과 달리 확신이 줄지 않은 채 틀릴 때가 있습니다.
• @lordnacho — 작은 범위의 코딩은 해결됐다고 볼 수 있습니다. 현재 상태와 원하는 변경이 분명하면 LLM이 대신 수정할 수 있습니다. 하지만 더 큰 의미의 코딩은 해결되지 않았습니다. 무엇을 만들지 판단해야 하고 그 판단은 시간에 따라 바뀝니다. LLM은 기본값을 선택해 POC를 만들 수 있지만, 그 선택을 모른 채 지나칠 수도 있습니다. LLM은 특히 사람이 이미 정한 일을 구현하는 데 강합니다. 유지보수성, 비용, 변경 시간 같은 대가를 알아야 합니다.
• @gnfargbl — 중간 지점은 있습니다. LLM을 유용한 도구로 쓰되, 망치가 생겼다고 모든 문제가 못처럼 보인다고 착각하지 않는 겁니다. LLM 결과도 열정적인 개발자의 결과처럼 검토와 추론이 필요합니다. 검토 시간을 확보하고 신중하게 다른 LLM을 활용한다면, 순수하게 AI만 쓰는 방식만큼 빠르지는 않아도 기존 개발 방식보다 나아질 수 있습니다.

원문: Alex Ewerlöf Notes / 번역·요약: Trawling