AI는 코딩을 해결하지 못했다: 유지보수, 보안, 확장성은 여전히 인간의 몫
Coding Is Not Solved – Alex Ewerlöf Notes
Alex Ewerlöf는 '코딩은 해결됐다'는 주장에 반박한다. LLM이 코드를 생성할 수는 있지만, 프로덕션 환경에서 중요한 유지보수, 신뢰성, 보안, 확장성 같은 비기능 요구사항(NFR)은 여전히 해결되지 않았다. 그는 AI가 책임질 수 없기 때문에 의료, 금융, 항공 등 높은 위험을 감수하는 분야에서는 AI에 의존할 수 없다고 지적한다. 또한 LLM은 논리와 대량의 컨텍스트 처리에 약점을 보이며, '코딩은 해결됐다'는 주장은 AI를 과대평가하는 데서 비롯된다고 비판한다.
AI는 책임을 질 수 없다. 어떤 결과도 감수할 수 없다. AI에게 할 수 있는 최악은 전원을 뽑는 것뿐이다. AI는 인간의 감정을 흉내 내지만 전혀 신경 쓰지 않는다. AI는 죽지도 않는다. 징역형이나 벌금을 받을 수도 없다. AI를 처벌할 수 없기에 결코 책임을 물을 수 없다.
HN 토론
531- efficax
코드를 읽는다고 해서 그 코드를 이해하는 건 아니다. 소프트웨어 경험에서 얻은 교훈 하나: 나는 코드를 결코 이해한 적이 없다. 어떤 방식으로 동작한다고 생각하다가, 그게 아니라는 걸 알게 된다.
LLM이 가능하게 해주는 것은 내가 이렇게 말하는 것이다: 이게 동작하는 모든 방식을 찾아내라. 이 소프트웨어를 실행할 수 있는 다양한 방법을 분석하고, 퍼저를 만들고, 속성 테스트를 만들고, 가능한 모든 시나리오에서 이 소프트웨어를 실행하라. 전체 트레이스를 로깅하라. 모든 출력을 로깅하라. 이제 각 시나리오의 버그를 분석하라. 손으로는 할 수 없다.
우리가 마음을 먹고, 자원을 투입하고, 시간을 할애한다면 (그리고 그냥 이렇게 말하는 것만으로도 가능하다: 예전 걸리는 시간의 절반이면 된다!), LLM이 만든 소프트웨어는 의료, 금융, 자동차, 국방, 발전소, 항공, 제조 분야에서 LLM과 함께 더 신뢰할 수 있고 더 나아질 수 있다... 단 한 줄의 코드도 읽지 않고서도. 그런데 LLM은 논리에는 정말 뛰어나다.
어쨌든 이 모든 글은 실제로 LLM을 사용해 소프트웨어를 만들지 않거나 한동안 시도해보지 않은 사람이 쓴 것처럼 읽힌다. 나도 2025년에는 같은 생각이었다. 나는 어려운 코드를 수십만 줄 작성했다. 이 글을 읽는 당신도 아마 내가 작성한 소프트웨어를 접해봤을 것이다. 예를 들어 한동안은 미국에서 직불카드 거래를 할 때마다 당신이 그것을 접했을 것이다. 나는 코드를 이해하고 품질을 중요하게 여기며, 그래서 코드에 LLM을 전적으로 지지한다.
- askonomm
내가 발견한 것은 AI가 게으르고 무능한 개발자들을 더 게으르고 더 무능하게 만든다는 점이다. 그 결과 제품 품질이 더 빠르게 더 나빠진다. 이제 쏟아져 나오는 코드의 양이 엄청나서, 예전에는 게으르고 무능한 개발자들이 끔찍한 코드를 내보내는 것을 어느 정도 막아주던 코드 리뷰가 사실상 사망했다. 현실적으로 그런 양의 코드를 사람이 리뷰할 수 없기 때문이다. 일부 회사는 코드 리뷰에 AI를 도입했는데, 뭐랄까... AI가 코드를 만들고, AI가 코드를 리뷰하고... 여기서 결정론적 결과를 기대한다면 이 얼마나 어리석은지 아시겠지.
소비자가 더 낮은 품질의 제품에 적응해서 회사가 게으르고 무능한 개발자의 존재를 정당화하게 될지, 아니면 소비자가 반발해서 회사가 개발자의 품질을 높이도록 강제할지는 시간이 말해줄 것이다.
참고: 나는 매일 AI를 사용하며, 게으르고 무능하지 않다면 AI로 고품질 소프트웨어를 만드는 것은 충분히 가능하다.
- temp00345
나는 이런 글을 거의 매일 읽는다.
이 글은 1년 전에 나왔다면 100% 맞았을 것이고, 9개월 전이면 75% 맞았을 것이고, 3개월 전이면 50% 맞았을 것이고, 지금은 아마 25%도 안 맞을 것이다.
이 글이 어디서 나오는지 충분히 이해한다. 나도 내 30년 넘은 프로그래밍 경력이 빠르게 무용지물이 되어가는 걸 받아들이기 힘들어하고 있다. 이 때문에 잠을 못 이루고, 힘들다.
하지만 최신 모델들(오늘 기준 Opus 5.5 / Astra 6)을 한번 다시 써봐라.
그들이 무엇을 할 수 있는지 보고, 그들이 생성한 코드를 읽어봐라.
어떤 문제 영역이든, 저수준 C++이든 고수준 TypeScript나 Clojure든, 아니면 이것들의 이상한 조합이든..
주저하지 말고 큰 작업을 맡겨라, UI까지 포함한 앱 전체를 만들게 해봐라..
그리고 그 결과를 1년 전 Opus 4나 gpt-5와 비교해봐라 - 그때는 이상하고 버그투성이가 아니면 함수 하나도 제대로 못 만들었다.
이게 바로 내 문제다. 모델들이 이미 아주 좋다는 게 아니라, 얼마나 빨리 이렇게 좋아졌는지가 문제다.
그래서 코딩이 아직 해결되지 않았다면, 곧 해결될 것이다.
- thesumofall
나는 글쓴이가 기업용 소프트웨어의 90%가 얼마나 지루하고 단순한지 과소평가한다고 생각한다. 항공기나 발전소를 돌리는 부분이 아닌 나머지 말이다. 그 중 상당수는 하룻밤 작업, 형편없이 관리된 하청업체, 그리고 애초에 품질이 낮은 요구사항(전혀 다른 본업을 가진 사람들이 작성하기 때문에)에서 비롯된다. 그리고 아시는가? 그 대부분은 24시간 내내 문제없이 돌아간다. LLM은 그런 걸 더 많이 만들어줄 뿐이다. 어쩌면 더 나을 수도 있다
- brainless
나는 약 30년간 프로그래밍을 해왔다(학창 시절 포함). 전문적으로는 18년이다.
누가 내게 왜 프로그래밍 언어가 40개 이상 있고 그중 인기 있는 게 10개쯤 되는지 말해줄 수 있나? 그리고 각 언어마다 프레임워크가 20개쯤 있다. 그리고 각 언어마다 인기 라이브러리가 200개씩 더 있다? 이 행렬은 깨닫기 전까지는 말이 안 된다 - 결국 전부 취향이라는 걸.
우리 엔지니어 대부분은 프로그래밍에 대한 자신만의 정신 모델을 구축했다. 우리 모두 옳다. 하지만 사용자는 신경 쓰지 않는다. LLM은 필요에 따라 점점 더 하드웨어에 가까운 코드를 생성하기 위해 존재한다. 필요하다면 모든 스펙에서 그래프를 만들고, 스스로 개발한 AST를 사용해 CPU에서 실행할 수도 있다. 그들은 해낼 것이다. 우리가 아무리 논의해도 그것을 막을 수 없다.
프로그래밍은 재발명될 것이다. 소프트웨어를 작성하는 현재의 방식은 중요하지도 않게 될 것 같다.
- hibikir
> 통제할 수 없는 것에 대해서는 책임질 수도 없다. 그 이해가 시스템 동작을 추론하고 AI가 필연적으로 실패할 때 고치는 데 핵심이다.
이건 좋은 전제가 아니다. 법 전반에서, 사람들은 자신이 통제하지 못하지만 소유하는 것에 대해 책임을 지게 된다. 개를 풀어 아이에게 해를 입히게 하거나, 개가 탈출할 수 있는 환경에 두기만 해도 어떤 일이 벌어지는지 보라.
합리적인 가이드라인을 한참 벗어난 시점에 문제가 발생할 수 있는 예측 불가능한 상황에서는 책임을 지지 않을 수도 있다.
그러니 당연히 당신이 통제할 수 없다고 여기는 AI가 한 일, 또는 당신이 납품한 AI 작성 코드에 대해 책임을 물을 수 있다. 늑대 무리를 풀어놓거나, 아이를 불구로 만들 수 있는 안전하지 않은 장난감을 파는 것처럼 취급하라. 모든 곳에 선례가 있다.
- thefilmore
"코딩은 해결됐다"를 주장한 사람들로부터: 오늘 한 동료가 Claude Code를 실행하려다 Bun 도움말 메뉴가 뜨는 문제를 겪었다 [1]. 이전에는 내가 Claude Code를 사용할 때 그것이 여러 번 스스로를 삭제했다. [2]
- hakunin
LLM이 생성한 소프트웨어가 충분히 좋다고 주장하는 사람들:
오랫동안 코드를 작성하지 않았다
그들의 코드에 비유적으로 손가락이 6개 있어도 알아채지 못한다!
좋은 것이 무엇인지에 대한 기준이 낮다
품질이나 NFR에 신경 쓰지 않는다
S-커브를 이해하기 어려워한다
antirez 같은 예외도 있지만, 많은 시끄러운 낙관론자들에게는 이게 맞다고 본다.
- lordnacho
이것에 대한 내 생각:
- 작은 규모의 코딩은 해결됐다. 현재 상태가 있고, 그것을 바꾸고 싶고, 어떻게 바꿀지 안다. 예를 들어, 어떤 이유로 블로킹 TCP 핸들러가 있는데 비동기로 만들고 싶다. 직접 만지작거리거나 LLM이 대신 변경하게 할 수 있다.
- 더 큰 의미의 코딩은 결코 해결되지 않는다. 무엇을 만들고 싶은지 결정하려면 판단이 필요하다. 무엇을 만들든 결정할 것들이 있고(누구/무엇을 위한 것인가?) 그 결정은 시간이 지나며 바뀐다. LLM이 기본 결정을 대신 내려줄 수 있고, 그게 괜찮다면 기본값을 얻는다(POC에 좋다). 그러나 그것이 당신을 위해 무엇을 결정했는지조차 깨닫지 못할 수도 있다. 어느 규모가 되면 그 결정들을 검토하는 데 많은 시간을 쓰게 된다. 하지만 지금은 결정을 바꾸는 마찰이 훨씬 낮아졌다. 예전에는 매우 시간이 많이 걸렸던 많은 것들을 이제 테스트할 수 있다.
- LLM이 확률적이라는 점은 사람들이 말하는 것만큼 중요하지 않다. 주니어 개발자에게 뭔가 코딩해달라고 하면, 나도 그가 무엇을 만들지 모른다. 심지어 당신이 뭔가를 해결할 수 있다고 확신해도, 당신 자신도 해결책이 어떤 모습일지 모른다. 어쩌면 사용하려던 라이브러리가 결국 적합하지 않다는 걸 알게 될 수도 있다. 최종적으로 무엇을 쓸지 모르지만, 뭔가가 문제를 해결해줄 거라는 건 안다. 문제에는 하나 이상의 해결책이 있을 수 있고, 어떤 것을 찾든 항상 중요한 건 아니다.
- 나는 여전히 t […]
- josephmtummon
글을 읽으면서 글쓴이에게 확실히 동의했지만, 댓글의 반론에도 동의하는 나를 발견했다.
AI 코딩 관행에 대해 개인적으로 갈등하는 점은, AI가 복잡한 작업까지 완수하는 게 믿을 수 없을 만큼 인상적이라는 데 전적으로 동의하고, 적어도 코드 작성에 있어서는 나보다 훨씬 훨씬 낫다고 말할 수 있다는 것이다.
내 문제는, AI가 매번 같은 수준의 사고를 요구하지 않는 "게으른" 선택지를 준다는 것이다. 이건 전적으로 개발자인 내 책임이고, 간단한 해결책은 LLM이 정확히 무엇을 만들어내는지 배우고 이해하는 데 시간을 들이는 것이다. 나는 이걸 시도하고 있고, 진행하면서 이해를 쌓아가도록 별도의 스킬을 설정했다.
그럼에도 불구하고, 오늘 LLM 없이 앉아서 뭔가를 구현하면 훨씬 오래 걸리지만, 일단 몰입하면 LLM 출력을 앞뒤로 읽는 것에서는 결코 얻을 수 없는 몰입 상태를 찾는다. 그리고 끝냈을 때 내 해결책이 완벽하지 않더라도 훨씬 더 많이 배웠고 문제에 대한 내 맥락이 훨씬 나아져서, 보통 그때 LLM과 함께 리뷰할 수 있다. 이렇게 하면 보통 더 나은 구현, 더 중요하게는 내가 책임질 수 있는 구현을 얻는다.
나 같은 신입 개발자(경력 약 2년)의 경우, 수년간의 문제 해결 경험을 쌓지 않았기 때문에, 매일 AI 도구를 내려놓고 문제 해결 능력을 향상시킬 시간을 확보하지 않으면 나는 […]