코딩 에이전트가 내가 사용하던 모든 프레임워크를 대체했다

"소프트웨어 엔지니어링이 돌아왔다"

• 프론티어 AI 모델과 코딩 에이전트의 발전으로 자동화 프로그래밍 시대가 열리면서, 코드를 한 줄씩 직접 타이핑하는 수작업이 사라지고 소프트웨어 엔지니어가 다시 본질적인 설계와 사고에 집중할 수 있게 됨
• 작년말부터 도구와 모델의 성숙도가 극적으로 향상되어, 잘 구성된 환경에서 아키텍트 역할에 전념하면서도 직접 개입해 수정할 수 있는 작업 방식이 가능해짐
• 웹·모바일·데스크톱 개발에 축적된 불필요한 프레임워크와 추상화 계층이 진정한 복잡성을 해결하지 못한 채 오히려 문제를 증가시켜 왔음
• 프레임워크가 해결한다고 주장하는 세 가지 문제—단순화, 자동화, 인건비 절감—중 자동화만 정당한 가치가 있었으나, AI 자동화가 이마저 대체 가능
• Google, Meta, Vercel 등 하이퍼스케일러가 설계한 시스템의 운영자(operator)로 전락하지 말고, 자신만의 설계와 제품을 직접 만드는 진정한 엔지니어링으로 돌아가야 함

---

자동화 프로그래밍의 부상

• Antirez가 명명한 "automated programming" 이라는 프레이밍이 "vibe coding"보다 본질을 훨씬 잘 포착
  • 인쇄기, 방직기, 조립라인처럼 자동화는 역사적 혁신의 핵심이었으며, 이번 변화도 그 연장선상에 있음
• 2025년 12월 이후 프론티어 모델과 코딩 에이전트의 역량이 극적으로 변화하여, 주의 깊게 관찰하는 사람에게는 이미 명백한 수준

엔지니어의 역할 변화

• 아키텍처, 트레이드오프, 제품 결정, 엣지 케이스 등 깊은 사고가 필요한 작업은 여전히 남아 있음
• 사라진 것은 모든 코드 라인을 직접 타이핑하는 지치고 소모적인 수작업
• 깨끗하고 철저하게 구성된 환경에서 모델과 도구를 사용하면, 벽돌을 직접 쌓지 않고도 건축가 역할 수행 가능
• 20년간 직접 코드를 작성해 온 경험이 뒷받침되어야 하며, 마음에 들지 않으면 직접 들어가서 이해하고 수정한 뒤 설정을 갱신할 수 있음
• 필요한 도구를 즉시 만들어낼 수 있어, 구상한 기술을 실현하는 데 더 많은 시간을 할애 가능

프레임워크와 불필요한 복잡성

• 웹, 모바일, 데스크톱 개발에서 수년간 프레임워크·라이브러리·툴링의 거대한 오염이 축적됨
• 의미 있는 것을 추상화하지 않는 추상화 계층들이 겹겹이 쌓여, 하나의 문제를 해결한다고 주장하면서 열 개의 새로운 문제를 생성
• 업계 전체가 소프트웨어 구축의 진짜 복잡성 앞에서 사고를 날카롭게 하는 대신, 기성품 사고를 구매하는 방식을 택함
• 부러진 다리를 실크로 감싸는 것 처럼, 겉은 좋아 보이지만 다리는 여전히 부러진 상태

프레임워크가 해결한다고 주장하는 세 가지 문제

• "단순화(Simplification)": 엔지니어가 직접 설계하기를 두려워하여 타인의 구조를 맹목적으로 수용하는 현상
  • 목표에서 역방향으로 설계하는 대신, 원사이즈핏올(one-size-fits-all) 설계를 어디에나 적용
  • 이는 단순화가 아니라 지적 항복(intellectual surrender)
• 자동화(Automation): 보일러플레이트 코드 제거라는 유일하게 납득 가능한 가치
  • ORM, CRUD 관리, 코드 생성, API 문서화 등 반복적이지만 필수적인 작업의 자동화
  • 그러나 바로 이 지점에서 AI가 모든 것을 바꾸고 있음
• 인건비 절감(Labour cost): 컨퍼런스 슬라이드에는 등장하지 않는 조용한 이유
  • Google, Meta, Vercel이 제품 구축과 코드 배포 방식을 결정하게 하면, 소프트웨어 엔지니어 대신 "React 개발자"를 고용할 수 있음
  • 교육 불필요, 플러그 앤 플레이, 쉽게 교체 가능한 부품(cog) 같은 인력
  • 이는 엔지니어링이 아니라 운영(operating)

새로운 작업 방식의 실제

• 2년 이상 이 방식으로 거의 결함 없이 개발해 왔으며, 진정한 혁명은 작년 12월부터 발생
  • 불필요한 복잡성을 제거하고 아이디어 중심의 복잡성에 집중할 수 있는 기회가 열림
• 보일러플레이트 제거 비용이 거의 0에 수렴, 동일 코드를 두 번 작성할 필요가 없음
• 문제에 정확히 맞춘 목적 특화 소규모 도구를 즉시 구축
• 화려한 모노레포 매니저 없이 단순한 Makefile이 99%의 유즈 케이스를 충족
• 문제가 매우 복잡해지면 그때 생각하되, 그 전에는 절대 미리 해결하지 않는 것이 엔지니어링
  • 컨퍼런스 무대에서 누군가 언젠가 겪을 것이라고 말한 문제가 아니라, 지금 가진 문제를 해결해야 함

Bash와 기본 도구의 재발견

• 에이전트는 수십 년간 존재해 온 기본 도구(basic tools) 에 매우 능숙
• Bash는 1989년에 탄생했으며, 현재 가장 평범한 모델도 세계 어떤 사람보다 Bash를 잘 앎
• 코딩 에이전트들이 복잡하고 비용이 높은 MCP 구성에서 Bash 기반의 단순한 에이전트 루프로 전환하는 추세
• 가장 오래된 도구가 가장 미래에 적합한 도구(most future proof)

프레임워크 의존의 비용

• 대부분의 유즈 케이스에서 기능의 10%만 사용하는 비싸고 결함 있는 프레임워크와 부수 라이브러리는 필요 없음
  • 유지보수, 보안 업데이트, 설계 제약 등 보이지 않는 비용이 크며, 이는 개발자의 자유를 제한함
• 이 트레이드오프를 계속 수용하면, 수십 년 만의 가장 큰 기회를 놓치는 것
• Google, Meta, Vercel 등 대형 기업의 설계 철학에 종속되는 구조를 경계할 것
  • 개발자가 스스로의 사고와 미적 감각을 신뢰하고, 자신만의 도구와 제품을 구축해야 함

“부러진 다리를 비단으로 감싸지 말고, 진짜 자신만의 것을 만드세요”

[centell]

“대부분의 유즈 케이스에서 기능의 10%만 사용하는 비싸고 결함 있는 프레임워크와 부수 라이브러리”라는 말이 정말 공감이 안되네요.. 프로젝트에 맞는 사이즈의 환경을 잘 선택하는것이 미덕 아니었던가요. 별 기능 안 만들거같으면 express 같은 가벼운거 쓰면되죠. 굳이 express를 대체할것을 처음부터 만들어야할지..

굳이 기능많은데 별거 안쓰는 것이라하면 오히려 아파치나 nginx같은 웹서버가 더 그럴텐데 그게 무겁다고 웹서버를 처음부터 만드나요 그냥 설정해서 쓰지

[bini59]

프레임워크라는 잘 정리되고, AI가 많이 학습한 자료가 있는데, 굳이 나만의 새로운 걸 만들어야할 필요가 있을까, 오히려 생산성을 떨어뜨리는 일 같네요.
아키텍쳐를 짜는 비용을 줄이고 본질(서비스)에 집중할 수 있게 만들어준걸 다시 버릴 필요는 없다고 생각합니다.

[khris]

음... 이런 프랙티스는 Cursor가 사용량 무제한 제공할때의 것이 아닌지... 오히려 어떻게 토큰을 아끼고 AI를 잘 보조해야할까?가 적어도 당분간은 앞으로의 방향같은데요.

비싼 토큰가격 없이도 중복을 제거할 수 있는데 프레임워크를 쓰지 않을 이유가 뭘까요?

[GN⁺]

Hacker News 의견들

• 가까운 미래에 많은 개발자와 기업이 AI 허세로 인해 큰 충격을 받을 것 같음
  지금은 AI로 뭔가를 만들 수 있지만, 진짜 문제는 직접 부딪혀보지 않으면 모르는 부분임
  결국 ‘분위기 코딩(vibe code)’만 하는 사람들은 현실적인 한계에 부딪힐 것이고, 시스템의 실제 작동 원리를 이해하는 사람만이 살아남을 것임

  • 오히려 반대라고 생각함. AWS re:Invent에서 본 세션에서는 세 개의 SRE 에이전트가 로그 분석부터 버그 수정, PR 제출까지 자동으로 처리했음
    2분 만에 버그를 고치고 머지할 수 있었고, “시스템을 이해한다”는 것과 “직접 코드를 쓰지 않는다”는 건 양립 가능함
    AWS는 이 방향에 거대한 베팅을 하고 있고, 비결정적 도구들이 점점 더 안정화되면서 인간 수준의 품질을 넘어설 가능성이 큼
  • AI나 외주 모두 마찬가지로, 작업 전체를 깊이 이해한 사람만이 제대로 활용할 수 있음
    이해 없이 맡기면 결과물의 정확성이나 유지보수성, 확장성을 보장할 수 없음
  • 복잡한 시스템을 AI에게 “예쁘게 부탁”해서 만들 수 있다고 믿는 사람들도 있음
    하지만 그런 사람들과 함께 일한다면, 왜 수십만 달러를 주고 그들과 LLM 구독료까지 내야 하는지 의문임
  • 너무 비관적(doomer) 으로 들림
    물론 ‘분위기 코딩’으로 만든 앱이 망가지는 사례는 생기겠지만, 테스트와 버전 관리, 문서화를 병행하는 팀은 오히려 더 번성할 것임
    결국 균형 잡힌 접근이 중요함
  • 대규모 붕괴는 없겠지만, AI가 만든 코드의 찌꺼기(de-slopping) 를 정리하는 시간이 점점 늘어날 것 같음
    언젠가 ‘de-slopper 봇’이 등장할지도 모름

• 프레임워크를 쓰는 이유는 그 설계자들이 나보다 더 많은 문제와 스케일 이슈를 겪었기 때문임
  프로젝트 초반엔 쉽지만, 규모가 커지면 재설계가 고통스러움

  • 인간이 쓴 코드를 거부하고 LLM 코드만 신뢰하는 건 일종의 광기라고 생각함
    이런 글을 읽다 보면, 글 자체가 LLM이 쓴 것 같을 때가 많음
    ‘벽돌을 자르고 꿰매는’ 식의 비유는 오히려 그 모순을 보여줌
  • ‘Not Invented Here’ 증후군은 예전부터 안티 패턴이었음
    모든 스택을 직접 만드는 건 여전히 비효율적이고, 유지보수 비용이 큼
    다만 이제는 문제에 맞게 맞춤형 컴포넌트를 쉽게 만들 수 있다는 점이 달라졌음
  • 나는 LLM을 많이 쓰지만, 가장 큰 장점은 LLM이 이미 프레임워크를 알고 있다는 점임
    새로운 걸 배울 필요 없이 익숙한 프레임워크로 충분함
  • API를 한두 시간만 봐도 그 프레임워크의 품질은 대체로 판단 가능함
  • 프레임워크의 한계는, 내가 하고 싶은 걸 지원하지 않을 때 세 가지 문제가 생긴다는 것임
    내 문제, 플랫폼 문제, 그리고 프레임워크를 우회하는 문제

• 코드를 쓰는 고통을 말하는 글이 이상하게 느껴짐. 코딩은 오히려 쉬운 부분임
  만약 톨킨이 AI를 썼다면, 프롬프트를 다듬느라 시간을 낭비했을 것 같음

  • 나도 Claude를 써봤지만, 결과적으로 이해도가 떨어짐
    특히 어려운 부분일수록 AI 도움은 오히려 독이 됨
  • 흥미로운 점은, vim/emacs 논의에서는 “타이핑은 중요하지 않다”고 하면서
    AI 글에서는 “AI가 코드를 대신 써줘서 생각에 집중할 수 있다”고 말함
    같은 사람들이라면 모순적임
  • 코딩이 고통스럽지 않냐고? CI 실패가 진짜 고통임
    요즘은 Claude Code에게 맡기면 대부분 몇 분 안에 해결됨
  • 어떤 사람은 남의 코드 읽기를 더 편하게 느끼기도 함
    하지만 나는 내가 쓴 코드를 더 신뢰함. 결국 속도보다 이해의 깊이가 중요함
  • 예술에서도 과정보다 결과물의 품질이 중요하다고 생각함
    워홀처럼 새로운 도구를 잘 활용하면 그것도 예술임
    LLM은 창작의 초반 단계를 돕는 도구일 뿐, 천재성은 여전히 인간에게서 나옴

• Node.js 보안 패치를 귀찮게 여기는 건 오해임
  그건 특권임. 직접 만든 솔루션은 보안 커뮤니티도 없고 취약점도 많음
  React 개발자는 쉽게 구할 수 있지만, “AI가 만든 독자 프레임워크” 개발자는 없음

  • 결국 AI가 기존 오픈소스 프레임워크를 덜 정교하게 복제하는 셈임
    대단한 일은 아님
  • React를 피하기 쉽지 않음. 이미 업계 표준이 되어버렸음

• 코딩 에이전트와 프레임워크의 중간 지점이 존재함
  나는 여전히 같은 도구를 쓰지만, 반복 작업은 에이전트가 하고
  나는 아키텍처와 엣지 케이스에 집중함
  에이전트를 무시하는 것도, 맹신하는 것도 극단임
  진짜 실력은 언제 운전대를 잡을지 아는 것임

• 이 글의 문제는 프레임워크와 ‘진짜 엔지니어링’을 대립적으로 본다는 점임
  Vercel, Next.js, Firebase 같은 플랫폼은 즉시 배포와 CI/CD를 가능하게 함
  과거 Jenkins로 직접 세팅하던 시절을 생각하면 혁명적임
  진짜 엔지니어링은 ‘다시 발명’이 아니라 빠르게 고객에게 전달하는 것임

  • 모바일 개발에서도 프레임워크와 라이브러리는 삶을 훨씬 편하게 만들어줌

• AI가 기존 프레임워크를 전투 검증 없이 재구현하는 건 비효율적임
  생태계와 공통 패턴이 없으면 협업이 어려움

  • 결국 StackOverflow 복붙의 AI 버전일 뿐임
    경험 없는 개발자가 AI를 잘못 쓰는 건 예전과 다르지 않음
  • 프레임워크의 에코시스템과 관용적 패턴이 핵심 가치임
    직접 만들면 문서, 미들웨어, 유지보수 모두 잃게 됨
  • 지금의 AI 리더들은 기존 지식을 새로 발견하는 중임
    “API를 연결할 수 있다”는 걸 새삼 깨닫는 수준임
    하지만 이런 발견이 트레이드오프의 이해를 동반하지는 않음

• 나는 최근 6개월간 Cursor + Opus 4.x로 임베디드 개발을 해왔음
  LLM은 소프트웨어뿐 아니라 회로 설계, CAD, CNC까지 도와줌
  예를 들어 ST7789 기반 디스플레이용 래퍼 함수를 세 번의 프롬프트로 완성했음
  이제는 LVGL, TinyUSB, 압축, 암호화 외엔 라이브러리를 거의 쓰지 않음
  LLM이 만든 목적형 함수는 작고 빠르며, 불필요한 추상화가 없음
  많은 라이브러리가 이제 퇴장할 시기라고 생각함

  • 프레임워크보다 라이브러리가 더 적절한 용어일 듯함
    .NET 같은 건 대체 불가지만, 범용 함수 모음은 충분히 교체 가능함
  • 나는 Claude(Opus 4.1)에게 단순히 “ESP32 + ST7789용 Rust 드라이버 만들어줘”라고 했더니
    더블 프레임 버퍼까지 포함된 완성 코드를 바로 줬음
  • 제조사 라이브러리가 얇은 래퍼라면 그냥 쓰는 게 낫지 않겠냐는 의견도 있음

• 코딩의 고된 부분은 타이핑이 아니라 사람과의 협업, 테스트, 설계 사고임
  최근 가장 힘들었던 건 락프리 자료구조를 설계하는 일이었음

  • 하지만 AI가 이런 복잡한 사고 과정도 도와줄 수 있음

• LLM 시대일수록 프레임워크의 가치가 더 커짐
  LLM은 학습 데이터 덕분에 React 같은 익숙한 패턴에 강함
  인간이 개입해 디버깅할 수 있다는 점도 중요함
  AGI가 오더라도, 효율적인 프레임워크를 다시 배우지 않을 이유가 없음

  • 실제로 Claude에게 물어보니, “프레임워크보다 직접 SVG 코드를 쓰는 게 낫다”고 답했음
    이런 대화 자체가 흥미로운 실험임

[click]

이거야말로 진정한 유지보수 어렵게 개발하는 방법론이네요 AI시대에 맞춰서 새 시대의 평생 내 자리를 지키는 법을 실천하시는 분입니다