# 코딩 에이전트가 내가 사용하던 모든 프레임워크를 대체했다 > Clean Markdown view of GeekNews topic #26502. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26502](https://news.hada.io/topic?id=26502) - GeekNews Markdown: [https://news.hada.io/topic/26502.md](https://news.hada.io/topic/26502.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-08T13:33:19+09:00 - Updated: 2026-02-08T13:33:19+09:00 - Original source: [blog.alaindichiappari.dev](https://blog.alaindichiappari.dev/p/software-engineering-is-back) - Points: 17 - Comments: 5 ## Summary **자동화 프로그래밍**이 부상하면서, 개발자는 더 이상 코드를 한 줄씩 타이핑하는 대신 아키텍처와 제품 설계에 집중할 수 있게 됩니다. 프론티어 모델과 코딩 에이전트의 성숙으로 보일러플레이트 제거 비용이 사실상 0에 수렴하며, 복잡한 프레임워크 대신 **Bash 같은 기본 도구**로 충분한 환경이 현실화되고 있습니다. 수많은 추상화 계층이 낳은 불필요한 복잡성을 걷어내고, 진짜 문제 해결과 설계 사고로 돌아가는 흐름이 조용히 확산되고 있습니다. ## Topic Body > "소프트웨어 엔지니어링이 돌아왔다" - 프론티어 AI 모델과 코딩 에이전트의 발전으로 **자동화 프로그래밍** 시대가 열리면서, 코드를 한 줄씩 직접 타이핑하는 수작업이 사라지고 소프트웨어 엔지니어가 다시 본질적인 설계와 사고에 집중할 수 있게 됨 - 작년말부터 도구와 모델의 성숙도가 극적으로 향상되어, 잘 구성된 환경에서 **아키텍트 역할에 전념**하면서도 직접 개입해 수정할 수 있는 작업 방식이 가능해짐 - 웹·모바일·데스크톱 개발에 축적된 **불필요한 프레임워크와 추상화 계층**이 진정한 복잡성을 해결하지 못한 채 오히려 문제를 증가시켜 왔음 - 프레임워크가 해결한다고 주장하는 세 가지 문제—**단순화, 자동화, 인건비 절감**—중 자동화만 정당한 가치가 있었으나, **AI 자동화**가 이마저 대체 가능 - Google, Meta, Vercel 등 하이퍼스케일러가 설계한 시스템의 **운영자(operator)로 전락**하지 말고, 자신만의 설계와 제품을 직접 만드는 진정한 엔지니어링으로 돌아가야 함 --- ### 자동화 프로그래밍의 부상 - Antirez가 명명한 **"[automated programming](https://news.hada.io/topic?id=26334)"** 이라는 프레이밍이 "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 등 **대형 기업의 설계 철학에 종속**되는 구조를 경계할 것 - 개발자가 스스로의 사고와 미적 감각을 신뢰하고, **자신만의 도구와 제품을 구축해야 함** > “부러진 다리를 비단으로 감싸지 말고, **진짜 자신만의 것을 만드세요**” ## Comments ### Comment 50878 - Author: click - Created: 2026-02-09T13:08:06+09:00 - Points: 3 이거야말로 진정한 유지보수 어렵게 개발하는 방법론이네요 AI시대에 맞춰서 새 시대의 평생 내 자리를 지키는 법을 실천하시는 분입니다 ### Comment 50905 - Author: centell - Created: 2026-02-09T18:07:27+09:00 - Points: 1 “대부분의 유즈 케이스에서 기능의 10%만 사용하는 비싸고 결함 있는 프레임워크와 부수 라이브러리”라는 말이 정말 공감이 안되네요.. 프로젝트에 맞는 사이즈의 환경을 잘 선택하는것이 미덕 아니었던가요. 별 기능 안 만들거같으면 express 같은 가벼운거 쓰면되죠. 굳이 express를 대체할것을 처음부터 만들어야할지.. 굳이 기능많은데 별거 안쓰는 것이라하면 오히려 아파치나 nginx같은 웹서버가 더 그럴텐데 그게 무겁다고 웹서버를 처음부터 만드나요 그냥 설정해서 쓰지 ### Comment 50868 - Author: bini59 - Created: 2026-02-09T11:16:42+09:00 - Points: 1 프레임워크라는 잘 정리되고, AI가 많이 학습한 자료가 있는데, 굳이 나만의 새로운 걸 만들어야할 필요가 있을까, 오히려 생산성을 떨어뜨리는 일 같네요. 아키텍쳐를 짜는 비용을 줄이고 본질(서비스)에 집중할 수 있게 만들어준걸 다시 버릴 필요는 없다고 생각합니다. ### Comment 50866 - Author: khris - Created: 2026-02-09T11:03:20+09:00 - Points: 1 음... 이런 프랙티스는 Cursor가 사용량 무제한 제공할때의 것이 아닌지... 오히려 어떻게 토큰을 아끼고 AI를 잘 보조해야할까?가 적어도 당분간은 앞으로의 방향같은데요. 비싼 토큰가격 없이도 중복을 제거할 수 있는데 프레임워크를 쓰지 않을 이유가 뭘까요? ### Comment 50819 - Author: neo - Created: 2026-02-08T13:33:19+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46923543) - 가까운 미래에 많은 개발자와 기업이 **AI 허세**로 인해 큰 충격을 받을 것 같음 지금은 AI로 뭔가를 만들 수 있지만, 진짜 문제는 직접 부딪혀보지 않으면 모르는 부분임 결국 ‘분위기 코딩(vibe code)’만 하는 사람들은 현실적인 한계에 부딪힐 것이고, 시스템의 실제 작동 원리를 이해하는 사람만이 살아남을 것임 - 오히려 반대라고 생각함. [AWS re:Invent](https://reinvent.awsevents.com/)에서 본 세션에서는 세 개의 **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 코드**를 쓰는 게 낫다”고 답했음 이런 대화 자체가 흥미로운 실험임