가까운 미래에 많은 개발자와 기업이 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 코드를 쓰는 게 낫다”고 답했음
이런 대화 자체가 흥미로운 실험임
Hacker News 의견들
가까운 미래에 많은 개발자와 기업이 AI 허세로 인해 큰 충격을 받을 것 같음
지금은 AI로 뭔가를 만들 수 있지만, 진짜 문제는 직접 부딪혀보지 않으면 모르는 부분임
결국 ‘분위기 코딩(vibe code)’만 하는 사람들은 현실적인 한계에 부딪힐 것이고, 시스템의 실제 작동 원리를 이해하는 사람만이 살아남을 것임
2분 만에 버그를 고치고 머지할 수 있었고, “시스템을 이해한다”는 것과 “직접 코드를 쓰지 않는다”는 건 양립 가능함
AWS는 이 방향에 거대한 베팅을 하고 있고, 비결정적 도구들이 점점 더 안정화되면서 인간 수준의 품질을 넘어설 가능성이 큼
이해 없이 맡기면 결과물의 정확성이나 유지보수성, 확장성을 보장할 수 없음
하지만 그런 사람들과 함께 일한다면, 왜 수십만 달러를 주고 그들과 LLM 구독료까지 내야 하는지 의문임
물론 ‘분위기 코딩’으로 만든 앱이 망가지는 사례는 생기겠지만, 테스트와 버전 관리, 문서화를 병행하는 팀은 오히려 더 번성할 것임
결국 균형 잡힌 접근이 중요함
언젠가 ‘de-slopper 봇’이 등장할지도 모름
프레임워크를 쓰는 이유는 그 설계자들이 나보다 더 많은 문제와 스케일 이슈를 겪었기 때문임
프로젝트 초반엔 쉽지만, 규모가 커지면 재설계가 고통스러움
이런 글을 읽다 보면, 글 자체가 LLM이 쓴 것 같을 때가 많음
‘벽돌을 자르고 꿰매는’ 식의 비유는 오히려 그 모순을 보여줌
모든 스택을 직접 만드는 건 여전히 비효율적이고, 유지보수 비용이 큼
다만 이제는 문제에 맞게 맞춤형 컴포넌트를 쉽게 만들 수 있다는 점이 달라졌음
새로운 걸 배울 필요 없이 익숙한 프레임워크로 충분함
내 문제, 플랫폼 문제, 그리고 프레임워크를 우회하는 문제
코드를 쓰는 고통을 말하는 글이 이상하게 느껴짐. 코딩은 오히려 쉬운 부분임
만약 톨킨이 AI를 썼다면, 프롬프트를 다듬느라 시간을 낭비했을 것 같음
특히 어려운 부분일수록 AI 도움은 오히려 독이 됨
AI 글에서는 “AI가 코드를 대신 써줘서 생각에 집중할 수 있다”고 말함
같은 사람들이라면 모순적임
요즘은 Claude Code에게 맡기면 대부분 몇 분 안에 해결됨
하지만 나는 내가 쓴 코드를 더 신뢰함. 결국 속도보다 이해의 깊이가 중요함
워홀처럼 새로운 도구를 잘 활용하면 그것도 예술임
LLM은 창작의 초반 단계를 돕는 도구일 뿐, 천재성은 여전히 인간에게서 나옴
Node.js 보안 패치를 귀찮게 여기는 건 오해임
그건 특권임. 직접 만든 솔루션은 보안 커뮤니티도 없고 취약점도 많음
React 개발자는 쉽게 구할 수 있지만, “AI가 만든 독자 프레임워크” 개발자는 없음
대단한 일은 아님
코딩 에이전트와 프레임워크의 중간 지점이 존재함
나는 여전히 같은 도구를 쓰지만, 반복 작업은 에이전트가 하고
나는 아키텍처와 엣지 케이스에 집중함
에이전트를 무시하는 것도, 맹신하는 것도 극단임
진짜 실력은 언제 운전대를 잡을지 아는 것임
이 글의 문제는 프레임워크와 ‘진짜 엔지니어링’을 대립적으로 본다는 점임
Vercel, Next.js, Firebase 같은 플랫폼은 즉시 배포와 CI/CD를 가능하게 함
과거 Jenkins로 직접 세팅하던 시절을 생각하면 혁명적임
진짜 엔지니어링은 ‘다시 발명’이 아니라 빠르게 고객에게 전달하는 것임
AI가 기존 프레임워크를 전투 검증 없이 재구현하는 건 비효율적임
생태계와 공통 패턴이 없으면 협업이 어려움
경험 없는 개발자가 AI를 잘못 쓰는 건 예전과 다르지 않음
직접 만들면 문서, 미들웨어, 유지보수 모두 잃게 됨
“API를 연결할 수 있다”는 걸 새삼 깨닫는 수준임
하지만 이런 발견이 트레이드오프의 이해를 동반하지는 않음
나는 최근 6개월간 Cursor + Opus 4.x로 임베디드 개발을 해왔음
LLM은 소프트웨어뿐 아니라 회로 설계, CAD, CNC까지 도와줌
예를 들어 ST7789 기반 디스플레이용 래퍼 함수를 세 번의 프롬프트로 완성했음
이제는 LVGL, TinyUSB, 압축, 암호화 외엔 라이브러리를 거의 쓰지 않음
LLM이 만든 목적형 함수는 작고 빠르며, 불필요한 추상화가 없음
많은 라이브러리가 이제 퇴장할 시기라고 생각함
.NET 같은 건 대체 불가지만, 범용 함수 모음은 충분히 교체 가능함
더블 프레임 버퍼까지 포함된 완성 코드를 바로 줬음
코딩의 고된 부분은 타이핑이 아니라 사람과의 협업, 테스트, 설계 사고임
최근 가장 힘들었던 건 락프리 자료구조를 설계하는 일이었음
LLM 시대일수록 프레임워크의 가치가 더 커짐
LLM은 학습 데이터 덕분에 React 같은 익숙한 패턴에 강함
인간이 개입해 디버깅할 수 있다는 점도 중요함
AGI가 오더라도, 효율적인 프레임워크를 다시 배우지 않을 이유가 없음
이런 대화 자체가 흥미로운 실험임