# 속도를 늦춰야 하는 이유 > Clean Markdown view of GeekNews topic #27861. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27861](https://news.hada.io/topic?id=27861) - GeekNews Markdown: [https://news.hada.io/topic/27861.md](https://news.hada.io/topic/27861.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-26T09:37:09+09:00 - Updated: 2026-03-26T09:37:09+09:00 - Original source: [mariozechner.at](https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/) - Points: 27 - Comments: 2 ## Summary AI 에이전트가 코드 생산성을 높이는 동시에 **품질 관리와 설계 통제권**을 잃는 트레이드오프를 정면으로 다룬 글입니다. 자동화된 속도가 테스트 신뢰도와 코드베이스 해석 가능성을 무너뜨리는 방향으로 작동할 수 있고, 지금의 에이전트는 CI 파이프라인의 도구로는 유용하지만 시스템 아키텍트를 대체하기엔 **학습 루프가 결여**되어 있다고 지적합니다. 이번 주 gstack·Harness·Impeccable 같은 에이전트 도구가 쏟아지는 맥락에서, "에이전트를 자동 커밋 봇이 아니라 **리뷰 가능한 코드 초안 생성기로 다뤄야 한다**"는 메시지가 좋은 것 같습니다. ## Topic Body - 최근 **AI 코딩 에이전트**의 확산으로 개발 속도는 빨라졌지만, **소프트웨어 품질 저하와 불안정성**이 심화되고 있음 - 에이전트가 **반복 학습 능력 없이 동일한 오류를 누적**하며, 대규모 코드베이스에서는 **검색 재현율 저하와 복잡성 폭증**이 발생함 - 인간의 통제 없이 시스템 전체를 맡기면 **중복 코드, 잘못된 설계 패턴, 유지 불가능한 코드베이스**로 이어짐 - 현재로서는 에이전트를 **비핵심 작업이나 실험적 영역**에 제한적으로 활용하고, **인간이 최종 품질 게이트**로 남아야 함 - **속도를 늦추고 인간의 주체성을 회복**하는 것이 학습, 성장, 그리고 **지속 가능한 소프트웨어 생태계**를 위한 핵심임 --- ### 모든 것이 망가진 상태 - 최근 1년간 **코딩 에이전트**가 실제 프로젝트를 완성할 수준으로 발전했지만, 그 결과 **소프트웨어 품질 저하**가 두드러지고 있음 - 대형 서비스에서도 **98% 가동률**이 일반화되고, **UI 버그**가 빈번히 발생 - AWS의 **AI 관련 장애 사례**나 Microsoft의 **AI 코드 비중 증가** 발언 등이 언급됨 - 일부 기업은 제품 코드의 **100%를 AI가 작성**한다고 주장하지만, 결과물은 **메모리 누수, UI 오류, 기능 불안정** 등으로 품질이 낮음 - 여러 개발자들이 **에이전트 중심 개발**로 인해 코드 리뷰 부재, 설계 결여, 불필요한 기능 과잉 등으로 **유지 불가능한 코드베이스**에 빠졌다고 보고함 ### 에이전트와 함께 일하지 말아야 하는 방식 - 개발자들이 **속도와 코드량**에 중독되어 **품질과 통제권을 포기**한 상태 - “분산·자율·자동화”를 내세워 **대규모 에이전트 오케스트레이션**을 시도하지만, 실제로는 **불안정한 결과물**을 양산 - 일부 프로젝트는 작동조차 어렵고, 인간의 개입 없이는 유지되지 않음 - 개인 프로젝트 수준에서는 가능할 수 있으나, **실제 사용자 기반 제품**에서는 실패 사례가 대부분임 - ## 오류 누적과 학습 부재, 병목 없음, 지연된 고통 - 에이전트는 **반복 학습 능력**이 없어 동일한 오류를 계속 발생시킴 - 인간은 오류를 통해 학습하지만, 에이전트는 **같은 실수를 무한히 반복** - 인간은 코드 작성 속도가 제한되어 오류 누적이 느리지만, **에이전트 군단은 병목이 없어 오류가 폭발적으로 누적** - 결과적으로 **코드베이스가 신뢰 불가능**해지고, 자동화된 테스트조차 믿을 수 없게 됨 - 결국 **수동 테스트만이 유일한 검증 수단**이 되어, 개발팀이 스스로를 함정에 빠뜨림 - ## 복잡성을 학습한 상인들 - 에이전트는 **전체 시스템 맥락을 보지 못한 채 로컬한 결정**만 내림 - 그 결과 **중복 코드, 불필요한 추상화, 구조적 혼란**이 급속히 누적 - 인간 조직에서는 이런 복잡성이 **수년에 걸쳐 서서히 축적**되지만, 에이전트 기반 팀은 **몇 주 만에 동일한 수준의 혼란**에 도달 - 에이전트는 훈련 데이터에서 배운 **잘못된 설계 패턴**을 그대로 재현하며, 인간의 통제가 없으면 **복구 불가능한 복잡성**을 만들어냄 - ## 에이전트 검색의 낮은 재현율 - 에이전트가 코드 수정이나 리팩터링을 시도할 때, **필요한 코드 전체를 찾지 못함** - 코드베이스가 커질수록 **검색 재현율(recall)** 이 급격히 낮아져, **중복과 불일치**가 발생 - Bash, LSP, 벡터 DB 등 다양한 도구를 사용해도 **대규모 코드베이스에서는 한계**가 존재 - 이로 인해 **코드 냄새와 불필요한 복잡성**이 더욱 심화됨 ### 에이전트와 함께 일해야 하는 방식 (현재로서는) - 에이전트는 **빠른 코드 생성과 높은 초기 품질**로 매력적이지만, **전체 시스템을 맡기면 붕괴** - 적절한 사용 사례는 **작은 범위의 비핵심 작업**, **자체 평가 루프가 가능한 작업**, **실패해도 치명적이지 않은 작업** - 예를 들어, **내부 도구 제작**, **아이디어 실험**, **성능 측정 기반 자동화 연구(auto-research)** 등이 적합 - 인간은 반드시 **최종 품질 게이트**로 남아야 하며, 에이전트의 결과를 **검토·수정·통합**해야 함 - 평가 함수가 좁은 지표만 반영할 경우, 에이전트는 **코드 품질·복잡성·정확성**을 무시할 수 있음 - **속도를 늦추는 것**이 핵심 - 무엇을, 왜 만드는지 **생각할 시간을 확보**하고, 불필요한 기능을 **과감히 거절**해야 함 - 하루에 에이전트가 생성할 수 있는 코드량을 **검토 가능한 수준으로 제한** - **아키텍처·API 등 시스템의 본질적 형태**는 반드시 사람이 직접 작성 - 에이전트와 **페어 프로그래밍**을 하며, 코드 작성 과정에서 **마찰과 이해의 기회**를 확보 - 이러한 접근은 **유지 가능한 코드베이스**를 만들고, **사용자 만족도**를 높이며, **불필요한 기능 대신 핵심 기능**에 집중하게 함 - 인간의 이해가 남아 있으면 **에이전트 검색의 재현율 문제**도 완화되고, 문제가 생겨도 **직접 수정 가능** - 초기 설계가 잘못되었더라도 **이유를 이해하고 개선할 수 있는 능력**이 유지됨 - 결국 필요한 것은 **규율과 인간의 주체성** - 시스템의 품질과 지속 가능성은 **인간의 개입과 판단**에 달려 있음 - “천천히 가는 것”이야말로 **학습과 성장**, 그리고 **건강한 소프트웨어 생태계**를 유지하는 유일한 길임 ## Comments ### Comment 53911 - Author: tested - Created: 2026-03-26T22:57:34+09:00 - Points: 1 [Pi – 간결한 터미널 코딩 하니스](https://news.hada.io/topic?id=26999) 이거 만든 사람이군요 ### Comment 53863 - Author: neo - Created: 2026-03-26T09:37:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47517539) - 요즘 이런 **사색적인 글**들을 읽을 때마다, 나도 어느 순간 지쳐버린 느낌임 결국 중요한 건 “무엇을 만들고 있는가”와 “그 도구가 실제로 도움이 되는가”임 루비, PHP, Lotus Notes, Visual BASIC 시대에도 같은 실수를 반복했음 도구를 현명하게 쓰고, 팀이 실제로 만들고 있는 **복잡한 현실**을 이해할 만큼의 속도로 일해야 함 애자일이냐 워터폴이냐, Docker냐 Podman이냐 같은 건 본질이 아님 요즘은 LLM이 프로덕션 DB를 지우고, 그걸 포스트모템 블로그에 그림까지 그려주는 시대지만, 그게 진짜 엔지니어링인지 모르겠음 어쩌면 소프트웨어 개발은 애초에 **공학적 학문**이 아니었을지도 모름 - “무엇을 만들고 있는가”라는 질문에 1000% 공감함 지난 10년간 소프트웨어 업계는 **메타 작업**으로 가득했음 — 새로운 프레임워크, 툴, 가상화 계층, 조직 구조 등 하지만 정작 “무엇을 위해” 이걸 만드는지 불분명함 마치 **피라미드식 구조**처럼, 산업을 유지하기 위해 새 일자리를 만들어내는 느낌임 그래도 진짜 엔지니어링은 존재함 — 과학적으로 질문을 세우고, 그 답으로 의사결정을 내릴 때 반대로 ‘감’으로 일하고 CEO 말만 따르는 건 엔지니어링이 아님 - 예전보다 **소프트웨어 엔지니어링의 품질**은 훨씬 나아졌음 예전엔 버전 관리조차 없는 팀이 많았고, 있었다 해도 형편없었음 Joel Spolsky의 [Joel Test](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...)를 보면 그 시절 대부분의 회사가 “아니오”였음 - 다리 설계처럼 소프트웨어를 만들 수 있을까 생각함 다리는 하중, 재료, 수명 등을 정확히 계산하지만, 웹사이트는 트래픽조차 예측하기 어려움 서버나 프레임워크의 **한계치**를 정량적으로 다루는 기준이 없음 언젠가 소프트웨어도 진짜 엔지니어링이 될 수 있겠지만 아직 갈 길이 멂 - 사실 소프트웨어는 공학이라기보다 **창의적 실험**에 가까움 “엔지니어”라는 단어를 붙인 건 단지 더 많은 돈을 벌기 위해서였던 것 같음 진짜 엔지니어들은 증명과 검증을 중시하지만, 우리는 새로운 패턴과 시도를 즐김 그래서 ‘엔지니어’라는 말이 오히려 불편함 - Edsger Dijkstra가 1988년에 이미 “소프트웨어 공학은 **불가능한 학문**”이라 했음 “프로그래밍을 모르는 사람들이 프로그래밍하려는 방법론”이라며 비판했는데, 지금도 여전히 맞는 말 같음 - 요즘 **AI 기반 개발 프로세스**가 대기업 중심으로 굳어지며 **벤더 종속**이 심해지고 있음 코드베이스가 에이전트 중심으로 변하면, 결국 그 에이전트만이 코드를 이해하게 됨 그때가 되면 가격은 오를 것이고, 인간 개발자가 다시 돌아오기도 어려운 **일방향 전환**이 될 수 있음 낙관론자들은 “기술은 항상 더 싸지고 좋아진다”고 말하지만, 석유 시장처럼 될 수도 있음 - 나도 같은 우려를 가짐 예전 DVD에서 스트리밍으로 넘어갈 때처럼, 우리는 같은 영화를 두 번 사는 셈임 Claude Opus 4.6 같은 모델은 이제 **분당 1달러** 수준으로 비싸졌고, 프롬프트 엔지니어링으로는 더 이상 보정이 안 됨 결국 AI 서비스도 **저가–중간–프리미엄** 계층 구조로 나뉘는 중임 프롬프트 엔지니어링은 이제 거의 **교묘한 탈옥(jailbreaking)** 수준으로 취급됨 - 이런 이유로, 숙련된 전문가들은 **자기 기술을 직접 유지**해야 함 AI 기업에 지식 노동 능력을 ‘임대’하는 건 위험함 “비용은 더 이상 오르지 않을 것”이라는 말은 대화의 끝임 — 이미 그들은 **주사위를 던진 상태**임 - Facebook이나 Uber가 요청당 비용을 공개하지 않는 이유는 단순함 — **독점적 가격 책정**을 하기 때문임 AI 대기업들도 같은 길을 갈 것임 결국 우리는 **토큰 중독자 시장**에 갇히게 될지도 모름 - 반대로, 코드는 **낮은 엔트로피**를 가지므로 더 작고 효율적인 모델로도 충분히 가능하다고 봄 오픈소스의 **보이지 않는 손**이 결국 모든 걸 무료로 만들 것임 - 나는 오히려 LLM 비용이 **계속 내려갈 것**이라 확신함 하드웨어와 소프트웨어가 발전하면서 계산 단가는 꾸준히 떨어짐 블록체인 붐처럼 실사용이 없는 기술은 사라지지만, AI는 실제 유저가 있음 Uber처럼 초기에 비판받던 서비스도 결국 **지속 가능한 비즈니스**로 자리 잡았음 석유와 달리, 컴퓨팅은 매년 더 싸지고 빨라짐 - 이 글의 저자는 **Pi**라는 오픈소스 코딩 에이전트 프레임워크를 만든 사람임 OpenClaw에서도 쓰이고 있음 - [Goodreads 인용문](https://www.goodreads.com/quotes/141645-heard-joke-once-man-...)을 통해, 저자의 글이 약간 **자기 풍자적**임을 보여줌 - 나는 Mario Zechner를 **libGDX**와 **RoboVM** 시절부터 팔로우했음 그의 [Pi 관련 블로그 글](https://mariozechner.at/posts/2025-11-30-pi-coding-agent/)도 참고할 만함 - 반대로, [OpenClaw 창작자](https://steipete.me/posts/2025/shipping-at-inference-speed)는 완전히 다른 철학을 가짐 - 그래서 이 글이 단순한 **반(反) AI 비판**으로 치부되지 않음 그는 LLM과 에이전트를 누구보다 깊이 다뤄본 사람임 - 하지만 어떤 사람들은 이런 글이 **아무 말도 안 하는 듯한 글쓰기**라고 느끼기도 함 - “AI가 100% 코드를 작성한다”고 주장하는 회사일수록 **엉망인 제품**을 내놓는 경우가 많음 예전 DOS나 MacOS 시절엔 그런 코드가 시스템 전체를 다운시켰기 때문에, 품질이 더 중요했음 지금은 OS가 관대해져서 **엉성한 코드**가 살아남음 - 문제는 컴퓨팅 자원이 아니라, “**항상 온라인**”이라는 전제와 “지금 배포하고 나중에 고치자”는 문화임 OTA 업데이트 덕분에 미완성 제품을 쉽게 내보내고 경쟁사보다 빨리 출시하려 함 - 하지만 예전에도 **형편없는 소프트웨어**는 많았음 단지 우리가 기억하는 건 잘 만든 소수의 제품뿐임 - 인터넷 이전에는 패치가 어려워서 출시 전에 **철저한 테스트**를 했음 지금은 네트워크 연결만 있으면 OS조차 게임처럼 쉽게 업데이트함 - 코딩 에이전트는 **‘유혹하는 세이렌’** 같음 처음엔 빠르고 똑똑하게 보이지만, “컴퓨터야, 내 일을 대신해줘”라고 생각하는 순간 무너짐 하지만 이건 일시적임 — AI는 **측정 가능한 영역**에서 이미 인간을 능가하고 있음 진짜 문제는 **HCI(인간–컴퓨터 상호작용)** 임 인간의 가치와 맞는 인터페이스를 설계하는 게 앞으로의 핵심 과제임 - 지금은 **AI 과열기**의 정점임 예전 MongoDB나 NoSQL이 “SQL은 죽었다”고 외쳤던 시절처럼, 결국 사람들은 다시 **현실적인 균형점**으로 돌아올 것임 NoSQL은 사라지지 않았지만, 이제는 필요한 곳에서만 쓰임 - “요즘 소프트웨어는 부서지기 쉬운 엉망”이라는 말에 공감하지만, 사실 **소프트웨어 자체는 변하지 않았음** 과거엔 신뢰가 없어서 사람이 직접 확인했고, 그 느린 속도가 문제를 줄였을 뿐임 DevOps의 핵심은 **신뢰를 기반으로 빠르게 움직이되, 품질을 유지하는 것**임 Toyota의 **Andon 코드**처럼, 문제를 발견하면 즉시 멈추고 근본 원인을 해결해야 함 이건 기술 문제가 아니라 **문화와 프로세스의 문제**임 - 시스템 엔지니어링 관점에서 보면, 각 단계마다 **허용 가능한 실패 모드**를 정의하고 검증해야 함 잘못된 인터페이스나 비즈니스 맥락 불일치를 조기에 찾아야 함 - **대규모 통합**도 문제임 모두가 GitHub, AWS, Cloudflare를 쓰다 보니, 한 곳이 멈추면 전 세계가 멈춤 - Andon 코드 같은 문화는 모든 곳에 필요함 - 반도체 업계는 이미 이런 문화가 있음 테이프아웃 직전에 버그가 발견되면, **메신저를 탓하지 않고** 신중히 판단함 - 프로그래밍의 산출물은 코드뿐 아니라 **프로그래머 자신**임 코드를 작성하며 쌓이는 **정신적 모델과 근육 기억**이 진짜 자산임 AI가 이 과정을 대체하면, 결국 **프로그래머의 성장**이 사라짐 Jonathan Blow의 [“Preventing the Collapse of Civilization”](https://www.youtube.com/watch?v=ZSRHeXYDLko)에서도 같은 문제를 다룸 - Peter Naur가 1985년에 이미 같은 통찰을 남겼음 [“Programming as Theory Building”](https://pages.cs.wisc.edu/~remzi/Naur.pdf) 참고 - 어제 동료와 비슷한 이야기를 나눴음 AI가 로그를 읽고 버그를 고치고 포스트모템까지 작성하는 데모를 봤는데, 문제는 **인간이 그 과정을 내면화할 시간이 없다는 것**임 “자동차에 브레이크가 있어야 빨리 달릴 수 있다”는 말처럼, 인간이 이해할 수 있는 속도로 **학습의 마찰**을 유지해야 함 - 하지만 그 예시의 진짜 공백은, **시스템이 고장났음을 인간이 먼저 알아차려야 한다는 점**임 만약 에이전트가 스스로 인식하고 복구한다면, 인간이 배울 필요가 있을까? 물론 근본 원인을 놓칠 수 있지만, **자율 복구 시스템**이 충분히 견고하다면 그게 문제일까? - 제품 디자인 관점에서도 비슷한 문제를 느낌 개발 속도가 너무 빨라서 **직접 써보며 검증할 시간**이 없음 잘못된 디자인 위에 기능을 쌓다 보면 되돌리기 어려움 결국 중요한 건 **속도가 아니라 품질과 학습의 균형**임 - 핵심은 코드 라인을 늘리는 게 아니라, **고객 피드백을 반영해 반복 개선**하는 것임 이런 과정에는 반드시 **시간이 필요함**