▲

속도를 늦춰야 하는 이유

 (mariozechner.at)
12P by GN⁺ 20시간전 | ★ favorite | 댓글 2개
  • 최근 AI 코딩 에이전트의 확산으로 개발 속도는 빨라졌지만, 소프트웨어 품질 저하와 불안정성이 심화되고 있음
  • 에이전트가 반복 학습 능력 없이 동일한 오류를 누적하며, 대규모 코드베이스에서는 검색 재현율 저하와 복잡성 폭증이 발생함
  • 인간의 통제 없이 시스템 전체를 맡기면 중복 코드, 잘못된 설계 패턴, 유지 불가능한 코드베이스로 이어짐
  • 현재로서는 에이전트를 비핵심 작업이나 실험적 영역에 제한적으로 활용하고, 인간이 최종 품질 게이트로 남아야 함
  • 속도를 늦추고 인간의 주체성을 회복하는 것이 학습, 성장, 그리고 지속 가능한 소프트웨어 생태계를 위한 핵심임

모든 것이 망가진 상태

  • 최근 1년간 코딩 에이전트가 실제 프로젝트를 완성할 수준으로 발전했지만, 그 결과 소프트웨어 품질 저하가 두드러지고 있음
    • 대형 서비스에서도 98% 가동률이 일반화되고, UI 버그가 빈번히 발생
    • AWS의 AI 관련 장애 사례나 Microsoft의 AI 코드 비중 증가 발언 등이 언급됨
  • 일부 기업은 제품 코드의 100%를 AI가 작성한다고 주장하지만, 결과물은 메모리 누수, UI 오류, 기능 불안정 등으로 품질이 낮음
  • 여러 개발자들이 에이전트 중심 개발로 인해 코드 리뷰 부재, 설계 결여, 불필요한 기능 과잉 등으로 유지 불가능한 코드베이스에 빠졌다고 보고함

에이전트와 함께 일하지 말아야 하는 방식

  • 개발자들이 속도와 코드량에 중독되어 품질과 통제권을 포기한 상태
    • “분산·자율·자동화”를 내세워 대규모 에이전트 오케스트레이션을 시도하지만, 실제로는 불안정한 결과물을 양산
    • 일부 프로젝트는 작동조차 어렵고, 인간의 개입 없이는 유지되지 않음
  • 개인 프로젝트 수준에서는 가능할 수 있으나, 실제 사용자 기반 제품에서는 실패 사례가 대부분임

  • 오류 누적과 학습 부재, 병목 없음, 지연된 고통

    • 에이전트는 반복 학습 능력이 없어 동일한 오류를 계속 발생시킴
    • 인간은 오류를 통해 학습하지만, 에이전트는 같은 실수를 무한히 반복
    • 인간은 코드 작성 속도가 제한되어 오류 누적이 느리지만, 에이전트 군단은 병목이 없어 오류가 폭발적으로 누적
    • 결과적으로 코드베이스가 신뢰 불가능해지고, 자동화된 테스트조차 믿을 수 없게 됨
    • 결국 수동 테스트만이 유일한 검증 수단이 되어, 개발팀이 스스로를 함정에 빠뜨림

  • 복잡성을 학습한 상인들

    • 에이전트는 전체 시스템 맥락을 보지 못한 채 로컬한 결정만 내림
    • 그 결과 중복 코드, 불필요한 추상화, 구조적 혼란이 급속히 누적
    • 인간 조직에서는 이런 복잡성이 수년에 걸쳐 서서히 축적되지만, 에이전트 기반 팀은 몇 주 만에 동일한 수준의 혼란에 도달
    • 에이전트는 훈련 데이터에서 배운 잘못된 설계 패턴을 그대로 재현하며, 인간의 통제가 없으면 복구 불가능한 복잡성을 만들어냄

  • 에이전트 검색의 낮은 재현율

    • 에이전트가 코드 수정이나 리팩터링을 시도할 때, 필요한 코드 전체를 찾지 못함
    • 코드베이스가 커질수록 검색 재현율(recall) 이 급격히 낮아져, 중복과 불일치가 발생
    • Bash, LSP, 벡터 DB 등 다양한 도구를 사용해도 대규모 코드베이스에서는 한계가 존재
    • 이로 인해 코드 냄새와 불필요한 복잡성이 더욱 심화됨

에이전트와 함께 일해야 하는 방식 (현재로서는)

  • 에이전트는 빠른 코드 생성과 높은 초기 품질로 매력적이지만, 전체 시스템을 맡기면 붕괴
    • 적절한 사용 사례는 작은 범위의 비핵심 작업, 자체 평가 루프가 가능한 작업, 실패해도 치명적이지 않은 작업
    • 예를 들어, 내부 도구 제작, 아이디어 실험, 성능 측정 기반 자동화 연구(auto-research) 등이 적합
  • 인간은 반드시 최종 품질 게이트로 남아야 하며, 에이전트의 결과를 검토·수정·통합해야 함
    • 평가 함수가 좁은 지표만 반영할 경우, 에이전트는 코드 품질·복잡성·정확성을 무시할 수 있음
  • 속도를 늦추는 것이 핵심
    • 무엇을, 왜 만드는지 생각할 시간을 확보하고, 불필요한 기능을 과감히 거절해야 함
    • 하루에 에이전트가 생성할 수 있는 코드량을 검토 가능한 수준으로 제한
    • 아키텍처·API 등 시스템의 본질적 형태는 반드시 사람이 직접 작성
    • 에이전트와 페어 프로그래밍을 하며, 코드 작성 과정에서 마찰과 이해의 기회를 확보
  • 이러한 접근은 유지 가능한 코드베이스를 만들고, 사용자 만족도를 높이며, 불필요한 기능 대신 핵심 기능에 집중하게 함
    • 인간의 이해가 남아 있으면 에이전트 검색의 재현율 문제도 완화되고, 문제가 생겨도 직접 수정 가능
    • 초기 설계가 잘못되었더라도 이유를 이해하고 개선할 수 있는 능력이 유지됨
  • 결국 필요한 것은 규율과 인간의 주체성
    • 시스템의 품질과 지속 가능성은 인간의 개입과 판단에 달려 있음
    • “천천히 가는 것”이야말로 학습과 성장, 그리고 건강한 소프트웨어 생태계를 유지하는 유일한 길임
▲
GN⁺ 20시간전  [-]
Hacker News 의견들

  • 요즘 이런 사색적인 글들을 읽을 때마다, 나도 어느 순간 지쳐버린 느낌임
    결국 중요한 건 “무엇을 만들고 있는가”와 “그 도구가 실제로 도움이 되는가”임
    루비, PHP, Lotus Notes, Visual BASIC 시대에도 같은 실수를 반복했음
    도구를 현명하게 쓰고, 팀이 실제로 만들고 있는 복잡한 현실을 이해할 만큼의 속도로 일해야 함
    애자일이냐 워터폴이냐, Docker냐 Podman이냐 같은 건 본질이 아님
    요즘은 LLM이 프로덕션 DB를 지우고, 그걸 포스트모템 블로그에 그림까지 그려주는 시대지만, 그게 진짜 엔지니어링인지 모르겠음
    어쩌면 소프트웨어 개발은 애초에 공학적 학문이 아니었을지도 모름

    • “무엇을 만들고 있는가”라는 질문에 1000% 공감함
      지난 10년간 소프트웨어 업계는 메타 작업으로 가득했음 — 새로운 프레임워크, 툴, 가상화 계층, 조직 구조 등
      하지만 정작 “무엇을 위해” 이걸 만드는지 불분명함
      마치 피라미드식 구조처럼, 산업을 유지하기 위해 새 일자리를 만들어내는 느낌임
      그래도 진짜 엔지니어링은 존재함 — 과학적으로 질문을 세우고, 그 답으로 의사결정을 내릴 때
      반대로 ‘감’으로 일하고 CEO 말만 따르는 건 엔지니어링이 아님
    • 예전보다 소프트웨어 엔지니어링의 품질은 훨씬 나아졌음
      예전엔 버전 관리조차 없는 팀이 많았고, 있었다 해도 형편없었음
      Joel Spolsky의 Joel Test를 보면 그 시절 대부분의 회사가 “아니오”였음
    • 다리 설계처럼 소프트웨어를 만들 수 있을까 생각함
      다리는 하중, 재료, 수명 등을 정확히 계산하지만, 웹사이트는 트래픽조차 예측하기 어려움
      서버나 프레임워크의 한계치를 정량적으로 다루는 기준이 없음
      언젠가 소프트웨어도 진짜 엔지니어링이 될 수 있겠지만 아직 갈 길이 멂
    • 사실 소프트웨어는 공학이라기보다 창의적 실험에 가까움
      “엔지니어”라는 단어를 붙인 건 단지 더 많은 돈을 벌기 위해서였던 것 같음
      진짜 엔지니어들은 증명과 검증을 중시하지만, 우리는 새로운 패턴과 시도를 즐김
      그래서 ‘엔지니어’라는 말이 오히려 불편함
    • Edsger Dijkstra가 1988년에 이미 “소프트웨어 공학은 불가능한 학문”이라 했음
      “프로그래밍을 모르는 사람들이 프로그래밍하려는 방법론”이라며 비판했는데, 지금도 여전히 맞는 말 같음

  • 요즘 AI 기반 개발 프로세스가 대기업 중심으로 굳어지며 벤더 종속이 심해지고 있음
    코드베이스가 에이전트 중심으로 변하면, 결국 그 에이전트만이 코드를 이해하게 됨
    그때가 되면 가격은 오를 것이고, 인간 개발자가 다시 돌아오기도 어려운 일방향 전환이 될 수 있음
    낙관론자들은 “기술은 항상 더 싸지고 좋아진다”고 말하지만, 석유 시장처럼 될 수도 있음

    • 나도 같은 우려를 가짐
      예전 DVD에서 스트리밍으로 넘어갈 때처럼, 우리는 같은 영화를 두 번 사는 셈임
      Claude Opus 4.6 같은 모델은 이제 분당 1달러 수준으로 비싸졌고, 프롬프트 엔지니어링으로는 더 이상 보정이 안 됨
      결국 AI 서비스도 저가–중간–프리미엄 계층 구조로 나뉘는 중임
      프롬프트 엔지니어링은 이제 거의 교묘한 탈옥(jailbreaking) 수준으로 취급됨
    • 이런 이유로, 숙련된 전문가들은 자기 기술을 직접 유지해야 함
      AI 기업에 지식 노동 능력을 ‘임대’하는 건 위험함
      “비용은 더 이상 오르지 않을 것”이라는 말은 대화의 끝임 — 이미 그들은 주사위를 던진 상태임
    • Facebook이나 Uber가 요청당 비용을 공개하지 않는 이유는 단순함 — 독점적 가격 책정을 하기 때문임
      AI 대기업들도 같은 길을 갈 것임
      결국 우리는 토큰 중독자 시장에 갇히게 될지도 모름
    • 반대로, 코드는 낮은 엔트로피를 가지므로 더 작고 효율적인 모델로도 충분히 가능하다고 봄
      오픈소스의 보이지 않는 손이 결국 모든 걸 무료로 만들 것임
    • 나는 오히려 LLM 비용이 계속 내려갈 것이라 확신함
      하드웨어와 소프트웨어가 발전하면서 계산 단가는 꾸준히 떨어짐
      블록체인 붐처럼 실사용이 없는 기술은 사라지지만, AI는 실제 유저가 있음
      Uber처럼 초기에 비판받던 서비스도 결국 지속 가능한 비즈니스로 자리 잡았음
      석유와 달리, 컴퓨팅은 매년 더 싸지고 빨라짐

  • 이 글의 저자는 Pi라는 오픈소스 코딩 에이전트 프레임워크를 만든 사람임
    OpenClaw에서도 쓰이고 있음

    • Goodreads 인용문을 통해, 저자의 글이 약간 자기 풍자적임을 보여줌
    • 나는 Mario Zechner를 libGDX와 RoboVM 시절부터 팔로우했음
      그의 Pi 관련 블로그 글도 참고할 만함
    • 반대로, OpenClaw 창작자는 완전히 다른 철학을 가짐
    • 그래서 이 글이 단순한 반(反) 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”에서도 같은 문제를 다룸

  • 어제 동료와 비슷한 이야기를 나눴음
    AI가 로그를 읽고 버그를 고치고 포스트모템까지 작성하는 데모를 봤는데,
    문제는 인간이 그 과정을 내면화할 시간이 없다는 것임
    “자동차에 브레이크가 있어야 빨리 달릴 수 있다”는 말처럼,
    인간이 이해할 수 있는 속도로 학습의 마찰을 유지해야 함

    • 하지만 그 예시의 진짜 공백은, 시스템이 고장났음을 인간이 먼저 알아차려야 한다는 점임
      만약 에이전트가 스스로 인식하고 복구한다면, 인간이 배울 필요가 있을까?
      물론 근본 원인을 놓칠 수 있지만, 자율 복구 시스템이 충분히 견고하다면 그게 문제일까?

  • 제품 디자인 관점에서도 비슷한 문제를 느낌
    개발 속도가 너무 빨라서 직접 써보며 검증할 시간이 없음
    잘못된 디자인 위에 기능을 쌓다 보면 되돌리기 어려움
    결국 중요한 건 속도가 아니라 품질과 학습의 균형임

    • 핵심은 코드 라인을 늘리는 게 아니라, 고객 피드백을 반영해 반복 개선하는 것임
      이런 과정에는 반드시 시간이 필요함
답변달기