「코딩은 해결됐다」는 문장의 주어는 누구인가
「코딩은 해결됐다」는 문장의 주어는 누구인가
코딩이 해결되었는가는 모델의 성질인가, 아니면 그 코드에 대해 책임을 지는 사람과 그가 감당할 수 있는 위험의 성질인가?
도입
2026년 9월 28일 해커뉴스 1면에 「Coding is not solved」라는 글이 올라와 585점을 받았다. 필자는 신뢰성 공학과 AI 시스템을 주제로 글을 써 온 Alex Ewerlöf로, 그의 Substack 메타데이터상 게시일은 9월 26일이다. 해커뉴스 스레드에는 필자 본인이 hanifbbz라는 계정으로 나타나, 이 글이 반(反)AI 선언이 아니라 「가격은 그대로인데 서비스는 나빠지는 것」에 대한 피로의 표현이라고 설명했다(직접 인용은 아니고, 코멘트의 요지를 요약).
제목만 보면 익숙한 논쟁이다. 이 블로그도 9월 11일에는 코딩 모델의 벤치마크 경쟁을, 8월 26일에는 코드 리뷰의 버그 검출률을 다뤘다. 그런데 Ewerlöf의 글을 끝까지 읽으면 벤치마크도, 리뷰 정확도도 중심 논점이 아니다. 그가 실제로 세우는 축은 두 개다. 하나는 위험 허용도(risk tolerance), 다른 하나는 **책임(accountability)**이다. 그는 코드를 읽고 다듬는 데 쓰는 시간이 위험 허용도의 함수이고, 위험 허용도는 업종뿐 아니라 규모·결합도·격리·관측 가능성의 함수라고 쓴다.
이 틀을 받아들이면 「코딩은 해결됐는가」라는 질문은 모델을 향하지 않는다. 그 코드가 깨졌을 때 누가 호출되는가, 그 사람은 무엇을 이해하고 있어야 하는가를 향한다. 이 글은 그 전환이 얼마나 유효한지, 그리고 해커뉴스 독자들이 어디서 반박했는지를 살펴본다.
「해결됐다」의 정의가 갈라지는 지점
Ewerlöf는 먼저 코드를 읽지 않아도 되는 제품 유형 네 가지를 꼽는다. 개인용 소프트웨어(가려운 곳을 긁는 자동화나 DIY 패치), POC(기술적 실현 가능성과 제품 가능성의 증명), 결과만 검증할 예산밖에 없는 일회성 자동화, 그리고 위험을 의도적으로 겨누는 「무기화된 AI」다. 앞의 세 가지는 위험 허용도가 높고, 마지막은 위험을 무기로 쓴다는 것이 그의 정리다.
반대편에는 엔지니어를 고용해 돈을 지불하는 소프트웨어가 있다. 그는 의료, 금융, 자동차, 국방, 발전소, 항공, 제조를 나열하고, 실수가 돈이나 생명이나 법적 결과로 이어지는 곳에서는 책임 소재가 필요하다고 쓴다. 다만 이것이 이분법은 아니라고 덧붙인다. 같은 업종 안에서도 소비자가 많으면 작은 결함이 큰 피해가 되고, 강한 결합은 연쇄 장애로 번지며, 샌드박스나 벌크헤드 같은 격리는 피해를 가두고, 관측 가능성이 높으면 오류 비용이 줄어든다.
이 분류가 흥미로운 이유는 「코딩은 해결됐다」고 말하는 사람과 「해결되지 않았다」고 말하는 사람이 서로 다른 칸에 서 있을 가능성을 드러내기 때문이다. 해커뉴스에서도 정의 논쟁이 바로 시작됐다. 가장 짧은 반응은 「코딩은 해결됐고, 소프트웨어 공학은 아니다」였다(@federicobrancas, 직접 인용은 아니고, 코멘트의 요지를 요약). @lordnacho는 더 세밀하게 나눴다. 현재 상태와 원하는 변경을 이미 알고 있는 「작은 코딩」, 예컨대 블로킹 TCP 핸들러를 비동기로 바꾸는 일은 해결됐지만, 무엇을 누구를 위해 만들지 판단해야 하는 「큰 의미의 코딩」은 결코 해결되지 않는다는 것이다. 그는 LLM이 기본값 결정을 대신 내려 주는데, 그 기본값이 무엇이었는지조차 모를 수 있다는 점을 위험으로 짚었다(직접 인용은 아니고, 코멘트의 요지를 요약).
Ewerlöf 자신도 이 구분을 예상하고 있었다. 그는 「코딩은 해결됐지만 공학은 아니다」라는 주장을 「반쯤 수건을 던진 것」이라 부르며, 좋은 소식과 나쁜 소식을 함께 전한다. 좋은 소식은 피드백 루프 덕분에 단순 작업의 상당 부분이 이미 해결됐다는 것이다. 나쁜 소식은 코드가 여전히 진실의 원천이라는 점이다. 코드는 무엇이 일어나는지와 어떻게 동작하는지를 말해 주고, 우리가 책임지는 대상이 바로 그것이다. LLM의 설명보다 코드를 읽는 쪽이 통제력이 크다는 것이 그의 결론이다.
여기서 두 진영의 차이가 선명해진다. 「작은 코딩은 해결됐다」는 쪽은 코드를 생산물로 본다. Ewerlöf는 코드를 증거로 본다. 생산물이라면 그럴듯하게 동작하면 충분하지만, 증거라면 누군가 그것을 읽고 법정이든 장애 회고든 어딘가에서 설명할 수 있어야 한다.
책임은 이해를 요구하는가 — 반박이 가장 날카로웠던 곳
글의 핵심 명제는 「이해하지 못하는 것에 대해 책임질 수 없다」이다. Ewerlöf는 AI가 처벌받을 수 없으므로 책임(accountability)을 질 수 없고, 도구로서 역할상의 담당(responsibility)만 가질 수 있다고 구분한다. 그는 소유권(ownership)을 세 기둥으로 설명한다. 무엇을 왜 풀고 있는지 아는 지식, 허락을 구하지 않고 결정할 수 있는 권한, 그리고 일이 터졌을 때 호출되는 책임이다. 셋 중 하나라도 빠지면 「깨진 소유권」이라는 것이다. 그래서 AI가 코드를 설명해 줄 수는 있어도 대신 이해해 줄 수는 없다고 그는 쓴다.
해커뉴스에서 가장 설득력 있는 반박은 바로 이 명제를 겨눴다. @hibikir는 법 체계 곳곳에 자신이 통제하지 못하는 것에 대해 책임지는 사례가 있다고 지적했다. 개를 풀어 놓았다가 아이가 다치면, 개의 행동을 완전히 통제할 수 없었다는 것이 면책 사유가 되지 않는다. 따라서 통제하기 어려운 AI가 만든 코드에 대해서도 사람은 당연히 책임을 질 수 있고, 위험한 장난감을 판 사람처럼 다뤄질 것이라는 주장이다(직접 인용은 아니고, 코멘트의 요지를 요약).
이 반박은 Ewerlöf의 결론을 뒤집는다기보다 오히려 무겁게 만든다. 책임이 이해 없이도 성립한다면, 사람은 이해하지 못한 코드에 대해서도 책임을 지게 된다. 그것은 「AI를 써도 괜찮다」는 허가가 아니라 「AI가 만든 것을 내보낸 순간 위험이 당신에게 이전된다」는 경고다. 개 주인의 비유가 성립하는 이유는 개 주인이 개를 묶어 둘 의무를 진다는 데 있다. 소프트웨어에서 그 끈에 해당하는 것이 테스트, 격리, 관측, 그리고 리뷰다.
두 번째 축의 반박은 「읽기」 자체를 문제 삼았다. 가장 많은 답글을 모은 @efficax의 코멘트는, 코드를 읽는다고 이해하는 것이 아니며 오랜 경험이 준 교훈은 자신이 코드를 결코 이해한 적이 없다는 것이었다고 말한다. 그 대신 LLM에게 이 소프트웨어가 동작하는 모든 방식을 찾아내게 하고, 퍼저와 속성 기반 테스트를 만들게 하고, 전체 트레이스를 남겨 시나리오별로 버그를 분석하게 할 수 있다고 주장한다. 그는 미국 직불카드 거래를 처리하던 소프트웨어를 작성한 경험을 근거로 들며, 그렇게 하면 코드 한 줄 읽지 않고도 고위험 업종의 소프트웨어를 더 신뢰할 수 있게 만들 수 있다고 봤다(직접 인용은 아니고, 코멘트의 요지를 요약).
답글은 갈렸다. 한 이용자는 LLM이 문제를 해결했다고 자신 있게 선언하거나 기능을 틀리게 설명하는 일이 잦다며, 사람과 다른 점은 그 근거 없는 확신이라고 경계했다(@grumple, 직접 인용은 아니고, 코멘트의 요지를 요약). 다른 이용자는 고위험 업종은 원래 광범위한 테스트에 의존해 왔고 사람의 리뷰는 그 위에 얹힌 한 층일 뿐 가장 중요한 층은 아니었다며 @efficax 편에 섰다(@pu_pe, 직접 인용은 아니고, 코멘트의 요지를 요약).
이 교환이 보여 주는 것은, 「코드를 읽어야 하는가」라는 질문이 사실은 「이해를 무엇으로 대리할 수 있는가」라는 질문이라는 점이다. Ewerlöf는 코드 읽기를, @efficax는 체계적 검증을 이해의 대리물로 제시한다. 두 사람 모두 이해를 포기하자고 말하지 않는다. 다른 점은 이해의 증거를 어디에 두느냐다. 그리고 여기서 Ewerlöf가 다른 곳에서 든 지적이 다시 의미를 갖는다. 그는 리뷰 불가능할 만큼 거대한 PR이 「신뢰」로 병합되는 오래된 수법을 비꼬았다. 검증을 LLM에게 맡기는 길도, 그 검증 결과를 사람이 읽을 수 있는 크기로 유지할 때만 이해의 대리물이 된다.
위험 허용도, SLA, 그리고 데이터가 없는 논쟁
이 글에서 가장 덜 주목받았지만 실무적으로 가장 쓸모 있는 부분은 경제학을 다룬 절이다. Ewerlöf는 가정을 하나 세운다. AI가 만든 코드가 품질 면에서 두 배 나쁘더라도, 사람보다 1000배 빠르고 100배 싸다면 많은 작업에서 느리고 비싼 사람을 투입할 경제적 근거가 없다. 「느린 것이 빠른 것」이라는 원칙은 위험 허용도가 낮은 핵심 소프트웨어에서만 정당화된다는 것이다. 이 숫자들은 측정값이 아니라 사고 실험의 가정이라는 점은 분명히 해 두자.
여기서 그는 SaaS 회사가 점점 「SLA를 파는 사업」이 되어 간다고 진단한다. 이제 AI에게 SaaS 제품을 복제하게 할 수는 있다. 그러나 그 복제품이 깨졌을 때 많은 기업은 직접 원인을 찾느라 자원을 쓰기보다 공급자에게 전화하기를 원하고, AI가 일으킨 장애는 다른 모델을 써도 AI가 고치기 어려운 경우가 많다는 것이다. 규모의 경제 덕분에 SaaS 회사는 높은 품질과 보증의 비용을 많은 고객에게 나눠 질 수 있다. 그의 처방은 단순하다. 원하는 것이 너무 독특해 합리적인 가격에 파는 곳이 없다면 프롬프트로 만들되 총소유비용과 보증의 부재를 알고 하라. 그것이 본업이 아니라면 SLA를 사라.
이 논리는 처음의 위험 허용도 틀과 정확히 맞물린다. 「코딩이 해결되었다」고 느끼는 경험은 대부분 위험 허용도가 높은 칸, 즉 개인 도구나 POC에서 나온다. 그 칸에서는 생성 비용의 하락이 곧 가치다. 반면 위험 허용도가 낮은 칸에서는 가치가 생성이 아니라 보증에 있고, 보증은 누군가 장애 시 호출될 수 있어야 성립한다. 같은 모델, 같은 출력이라도 어느 칸에 놓이느냐에 따라 「해결됐다」의 진리값이 바뀐다.
해커뉴스에서는 이 칸 나누기 자체에 대한 반론도 있었다. @Sevii는 엔지니어를 고용하는 소프트웨어 대부분이 위험 허용도가 낮다는 전제가 틀렸으며, 대부분의 엔지니어는 위험 허용도가 낮은 코드를 다루지 않는다고 반박했다. @giovannibonetti는 헬스테크에서 일한 경험을 들어, 의료 분야는 느리고 버그투성이인 UI로 사용자가 매달 몇 시간을 낭비해도 용인할 만큼 기술 품질에 관대했다고 썼다. @thesumofall은 엔터프라이즈 소프트웨어의 90퍼센트가 지루하고 단순하며, 하룻밤 작업과 관리 부실한 하청과 질 낮은 요구사항에서 태어났는데도 대부분 24시간 문제없이 돈다고 지적했다(세 코멘트 모두 직접 인용은 아니고, 코멘트의 요지를 요약).
이 반론들은 Ewerlöf의 틀을 무너뜨리지 않는다. 오히려 그 틀이 정확히 어디서 경쟁하는지를 보여 준다. 업계 대다수가 위험 허용도가 높은 칸에 있다면, 「코딩은 해결됐다」는 말은 그 대다수에게 사실에 가깝다. 그렇다면 논쟁은 「해결됐는가」가 아니라 「당신의 소프트웨어는 어느 칸에 있는가」로 옮겨 가야 한다. 그리고 그 질문에 대한 답은 종종 정직하지 않다. 헬스테크의 사례처럼 조직이 실제로 용인하는 위험과 명목상의 위험 수준이 다를 수 있기 때문이다.
공정하게 말하면 이 글의 약점도 분명하다. @Marha01은 이렇게 확신에 찬 주장을 하려면 사람이 쓴 코드와 AI가 쓴 코드의 버그 밀도를 비교하고 그 추이를 보이는 식의 단단한 데이터가 있어야 하는데, 이 글은 분위기뿐이라고 비판했다. 「코딩과 소프트웨어 공학을 혼동하지 말라」는 지적은 타당하지만 나머지는 넋두리에 가깝다는 평이다(직접 인용은 아니고, 코멘트의 요지를 요약). @armchairhacker는 결론에는 동의하면서도, LLM의 확률적 성질이 곧 어리석음을 뜻하지는 않으며 글이 든 특이한 실패 사례 일부는 이미 몇 달 전에 고쳐졌다고 지적했다(직접 인용은 아니고, 코멘트의 요지를 요약).
글 안에서 숫자로 된 증거는 드물다. 그나마 구체적인 것은 필자 자신의 실험이다. 그는 에이전트에게 패치 릴리스뿐인 npm 의존성 5개를 업데이트하게 했더니 12분과 72단계가 걸렸고, 자신은 1분 안에 할 수 있었다고 쓴다. 일화 하나지만 방향은 의미가 있다. 작업의 위험이 낮고 범위가 명확할 때조차 에이전트의 「과정 비용」이 사람보다 클 수 있다는 것이다. 다만 이것을 일반화하려면 훨씬 더 많은 측정이 필요하다.
시간 축의 반론도 있었다. @temp00345는 이 글이 1년 전이라면 100퍼센트, 9개월 전이라면 75퍼센트, 3개월 전이라면 50퍼센트 옳았겠지만 지금은 25퍼센트 이하라고 평가했다. 30년 넘은 프로그래밍 경험이 빠르게 낡아 간다는 사실을 받아들이기 어려워 잠을 설친다고 고백하면서, 최신 모델에게 큰 작업을 맡기고 결과 코드를 직접 읽어 보라고 권했다(직접 인용은 아니고, 코멘트의 요지를 요약). Ewerlöf는 S자 곡선을 들어 이런 외삽을 경계한다. 능력은 오르지만 체감 수확이 있고, 더 비싼 모델이 가격 상승만큼 생산적이지 않은 지점이 온다는 것이다. 어느 쪽이 맞는지는 지금 시점에서 이 블로그가 판정할 수 있는 문제가 아니다.
그럼에도 위험 허용도와 책임이라는 틀은 모델 성능의 추이와 무관하게 유지된다는 점이 중요하다. 모델이 1년 뒤 두 배 좋아져도, 장애 시 호출될 사람이 그 시스템을 설명할 수 있어야 한다는 요구는 남는다. @vmg12의 지적이 이 지점을 보강한다. AI는 CRUD 엔드포인트나 자료구조 구현에는 거의 완벽하지만, 시스템이 어떻게 진화할지 내다보는 타입과 API 설계에는 약하다. 그런 능력을 기르는 강화학습 환경을 만들려면 대규모 소프트웨어를 먼저 만들고 그것을 진화 가능한 방식으로 분해해야 하므로, 시간이 걸릴 것이라는 관측이다(직접 인용은 아니고, 코멘트의 요지를 요약). 다시 말해 현재 모델이 잘하는 영역은 정답을 기계적으로 확인하기 쉬운 영역이고, 그렇지 않은 영역일수록 사람의 이해가 증거로 요구된다.
결론
「코딩은 해결됐다」는 문장에는 생략된 주어가 있다. 누구에게, 어떤 위험 수준에서, 장애가 났을 때 누가 호출되는 조건에서 해결됐는가. Ewerlöf의 글이 이전의 수많은 「AI는 아직 멀었다」류 글과 다른 점은 이 생략된 주어를 위험 허용도와 책임이라는 두 변수로 복원하려 했다는 데 있다. 개인 도구와 POC의 칸에서는 이미 해결됐을 수 있다. 의료나 항공의 칸에서는 해결이라는 말 자체가 「누가 책임지는가」와 분리되지 않는다.
해커뉴스의 가장 좋은 반박들은 이 틀을 부수지 않고 정밀하게 만들었다. 책임은 이해 없이도 성립하므로 위험은 오히려 사람에게 더 무겁게 이전된다. 이해는 코드 읽기만이 아니라 체계적 검증으로도 대리할 수 있지만, 그 검증 결과가 사람이 읽을 수 있는 크기일 때만 그렇다. 그리고 업계 대다수는 생각보다 위험 허용도가 높은 칸에 있다.
당신 팀의 소프트웨어는 어느 칸에 있는가. 명목상의 칸이 아니라, 지난 장애에서 실제로 용인된 피해의 크기가 말해 주는 칸 말이다. 그리고 그 칸에서 AI가 쓴 코드가 깨졌을 때 호출될 사람은, 지금 그 코드를 무엇으로 이해하고 있는가.
출처: