그래서 사람들은 대체 언제 vibe coding이 그냥 확장도 안 되는 총체적 난국이라는 걸 깨닫게 될까.txt
source reddit
어떤 놈이 AI agent로 X, Y, Z를 하게 만들고, 웹사이트까지 같이 해달라고 하더라.
그래서 내가 예산이 어느 정도냐고 물었음.
답이 “vibe coding으로 다 하면 되니까 돈 많이 안 들어도 되잖아”였음.
ㅋㅋ.
개발자가 시급 $8이면 된다고 믿는 인간들은, 진짜로 그 돈 주고 산 만큼 그대로 당해봤으면 함.
그럴 거라 생각 안 함. AI 전부터도 저숙련 개발자 시장 큼. 그 고객들은 코드 품질, 보안 같은 거 신경 안 썼음.
기술 진화 보는 거 ㅈㄴ 감동적임. 10년 전엔 그 고객들이 fiverr에서 복붙 코드로 버그 투성이에 유지보수 불가인 쓰레기 만들 사람 고용했을 텐데, 이젠 fiverr에서 AI로 복붙 코드 버그 덩어리 만들게 고용함.
근데 이제 지구도 같이 울겠네!
ㅋㅋ 이거 말 ㄹㅇ 딱임. 모자 벗고 경의 표함, 형님!
그 고객들은 코드 품질, 보안 같은 거 신경 안 썼음.
"신경 안 씀"으로 현실 피할 수 없음, 결국 따라와서 물어뜯음.대부분 앱은 저숙련 개발자 이상 필요 없음. AI는 'hey chatgpt, 내 코드에 눈에 띄는 코드 품질이나 보안 문제 있냐' 같은 프롬프트로도 유용한 도구임. prettier나 lint 쓰는 거랑 다르게 코드 감사에 최소한이라도 안 쓸 이유 없음.
동의하긴 하는데, lint나 prettier 같은 건 결정론적이고 chatGPT 같은 건 아님을 기억할 필요 있음.
그 말 했네. AI는 도구임. 과용하지 말고, 통제 유지하고, 뭐 하는지 알면 문제 없을 거임.
규칙이랑 가이드라인 없으면 잘 안 됨. 평균 dev는 그걸 정의도 못 하고 인지도 못 함.
큰 앱이 유지보수 단계 들어갈 만큼 시간이 지나면 얘기 달라짐. 근데 대부분 제품은 거기까지 안 감, 지금은 허니문이고 당분간 그럴 듯.
둘 이상 코더 끼면 그전부터임. 난 vibe coder랑 하는 프로젝트 2개 있음. 초반엔 진도 빨랐음. 지금은 다들 claudes, copilots, cursors로 코드베이스를 서로 휘젓고만 있음. 각자 담당 영역 통합이 안 됨. 버그 하나 고치면 3개 더 만듦. 언젠가 어떤 ㅂㅅ이 코드베이스 제대로 들여다보고 의미를 파악해야 함. 아마 그게 나겠지만, 웨이브풀 켜져 있는 동안엔 안 들어갈 거임.
"야, 너 뭐 함? Feature XYZ 깨졌는데."
코드 봄. Feature XYZ가 // This code is unchanged. This was commited and merged. 로 바뀌어 있음, 이게 커밋돼서 머지됨.누가 릴리스마다 AI로 아키텍처 요약하고 매번 처음부터 다시 빌드하면 더 빠를 거라 하더라. 저런 놈들 밑에서 일하기 싫음.
*저런 놈들이 날 부자로 만들어줄 거임.
난 이 관점 잘 이해 안 감. 물론 slop 많이 만들어지긴 하는데, 새 도구가 진입장벽 확 낮출 때마다 늘 있던 일과 다를 바 없음. 우리 팀은 2016부터 계속 개발해온 큰 프로덕션 앱에서 에이전트로 코드 추가랑 버그 수정 잘 하고 있음. 제일 힘든 건 사람들이 새 비즈니스 문제 학습 속도를 역전해서, 제품 질문을 생각하려고 속도 좀 늦춰야 하는 거였음. 더 큰 불만 하나는 LLM이 만든 테스트가 종종 범위가 너무 넓다는 점임.
몇 달 전엔 ci에서 정적 분석 개선하는 툴을 vibe coding으로 만들었는데, 2달째 돌고 있고 거의 20명 엔지니어가 매일 쓰면서 CI 런마다 7분 줄여줌. LLM 생성 코드 없었으면 이거 만들 시간도 없었을 거임. 지금까지 문제 0건임.숙련 엔지니어가 쓰면 문제 없음, 제대로 구조 잡을 수 있으니까. 근데 그 엔지니어는 옛날 방식으로 기본기 쌓았음.
난 새시대 dev들이 LLM이 주는 거 다 처먹고 나오는 소프트웨어가 걱정임.서버리스, NoSQL dbs, PAAS 배포, create react app 같은 앱 생성기, react 초창기, stackoverflow 복붙 등에도 똑같이 말할 수 있음. LLM 차이는 이해 없이도 엄청난 속도/볼륨으로 쏟아낼 수 있다는 거임. 잡마켓이 이미 조여지는 타이밍에 오는 이상한 충격이기도 한데, 동시에 제대로 된 마인드면 새 아이디어 빠르게 실험하고 새로운 것 학습도 빨리 부트스트랩할 기회라고 봄.
사람들이 이걸 이해 못 함. 이 바퀴는 여러 번 한 바퀴 돌았음. 이번이 최신 버전이고, 꽤 다르고 훨씬 강력할 수도 있는 버전임.
문제가 쌓여서 끝까지 못 만들 거임.
이거임.
UI 개발은 플랫폼이 뭐든(브라우저, ios, android, windows,...) 충분히 어려움. 웹은 표현 계층 결함 때문에 사실상 이미 치트 중인데(html + css ㅈㄴ 구림, 프레임워크 다 얹어도), 검증된 패턴 쓰기보다 꼼수로 성공하게 부추김. 거기에 AI로 중복 난장판 만들면 베스트 프랙티스는 거의 의미 없어지고, 결국 개판 됨.
근데... 최소한 "그냥" 프론트엔드임. 비즈니스 규칙만 멀쩡하면, 사람들은 수십 년 동안 소프트웨어는 원래 안 된다는 학습을 당해서 그런지, 삐걱대고 버그 있는 웹 UI도 그냥 받아들임.html + css ㅈㄴ 구림
아님, UI 표현으로는 사실상 제일 나은 선택임.
디테일한 부분에 문제는 있지만, 핵심은 다른 어떤 옵션보다 나음.동의함. JavaScript 안 얹어도, 평균 "개발자"보다 더 할 줄 아는 사람은 그 이상 가능하단 걸 앎.
ㅇㅇ, html이 브라우저 밖 시스템에서도 레이아웃에 쓰이는 이유가 있음. (XML이라 하기도 하는데 보통 HTML 시맨틱 쓰고 XML은 아님)
사람이 읽기 쉽고, 보기 좋게 포맷되고, 꽤 복잡한 레이아웃도 담을 수 있음.
HTML이랑 CSS가 좋다는 데는 나도 크게 반대 안 함. 20년(아마추어로) 썼는데도, 뭔가 똑똑한 취미 개발자가 그냥 돌아가게만 급히 붙여놓은 느낌이 계속 듦. 대체 패러다임이 파이프라인 어딘가에 있나? 나보다 똑똑한 사람들이 이 문제 고민하고 있을 텐데, 뭘 내놨는지 듣고 싶음.
나도 그렇게 생각했는데, 그냥 gopher에 남았어야 했나 보자고 해야 하나 싶음.
지난주에 누가 와서, 시장 리포트를 AI로 생성해서 서비스로 팔 거라더라.
문제는 vibe coding으로 전부 만들었고 프론트 조각들은 대충 돌아가 보이는데… 아주 사소한 문제 하나가, 서로 다른 프론트 컴포넌트들이 서로 소통을 전혀 안 함. AI로 리포트 생성은 하는데 저장을 어떻게 하는지 모름. 로그인도 있는데 아무 것도 안 함.
본인은 거의 다 왔다고 느꼈지만, 난 어려운 건 이제부터고 지금은 서로 모르는 컴포넌트만 잔뜩이고 아키텍처 설계도 없다고 말해줬음. 결국 그걸 알아내고 전부 리팩터링해야 함.
그래도 아이디어 내고 MVP 만들려 한 건 칭찬할 만함. 나였으면 그만한 야망도 없고, 하려다 과하게 설계해서 평생 빛도 못 봤을 듯.그 마지막 말이 전부임. 난 몇 달을 웹앱 개인 프로젝트에 쏟았는데, 아직 수익화 길도 안 보임. 이번엔 MVP에 치여 죽는 대신 "제대로" 하겠다고 했음. 결과는, 앱 만드는 데 든 투자만 날리고 돈이 될지 길도 모름.
ㅇㅇ vibe coding 구리지만, 잘하면 첫인상은 그럴듯하게 나옴. 솔직히 사람들이 이해 못 하는 걸 탓하기도 어려움. 사람은 자기가 뭘 모르는지 모름.
근데 10년 뒤가 어떻게 될진 모름. 할 수 있는 건 고개 숙이고 왜 이렇게 동작하는지 이해하는 데 집중하는 거뿐임. 허공에 대고 소리 질러봐야 의미 없음.우리 회사 시니어/스태프 엔지니어들은 AI 써도 좋은 결과 냄.
우리 CEO는 주말에 큰 기능을 다시 써서 5만 라인짜리 괴물 PR 하나 만들었음. 좋은 엔지니어는 여전히 좋은 엔지니어임. 나쁜 엔지니어(혹은 한때 좋았지만 떨어져 나간 엔지니어)는 이제 과신하고 실력 이상을 만들고 있음.잠깐… PR 하나에 5만 라인? ㅆㅂ 그게 어떻게 가능함?
대규모 리팩터링 + 코드 품질은 별로인 반복 투성이 테스트 90% 커버리지 + package.lock 같은 자동 생성 파일이면 가능하긴 함. 아마 그랬겠지? 어떤 팀들은 미뤄뒀던 테스트를 AI로 쓰기도 함.
ㅋㅋ 테스트 없음.
AI로 테스트 쓰기
ㅇㅇ, 이래서 결국 엔지니어 채용 붐이 다시 올 거임.뭐, 테스트 없는 거랑 최소한 뭐라도 있는 거 사이면… 바닥이 낮잖아.
node_modules랑 package-lock.json을 푸시했음.
다들 알잖아 그거.package-lock.json은 커밋하는 게 맞음...
의외로 package-lock.json은 안 올렸음. 대신 백엔드 패키지 안에 프론트엔드를 통째로 만들긴 했는데, node_modules는 커밋 안 했음.
CEO가 코딩에 끼어드는 회사는 큰 레드플래그임, 특히 vibe coding이면 더.
ㅇㅇ 이거 요즘 새로 생긴 거임.
공정하게 말하면, 회사 시작한 코드는 그가 썼긴 함. 근데 그게 10년 전임.
기존 코드를 이해 못 해서, 다시 쓰는 대기업급 기능을 ㅈㄴ 과설계한 다음 백엔드 모노레포에 프론트를 얹어버림. node modules는 안 커밋했지만, AI로 코드 엄청 찍어낸 건 확실함.
기존 코드를 이해 못 해서
나 이 사진 속 사람임, 마음에 안 듦. 컴공 학위랑 경력 뭐였냐 ㅋㅋ.백엔드 모노레포에 프론트를 넣기
이거 읽고 백엔드 개발자 내면의 내가 포크로 눈 찌르고 싶어짐. 문맹이었으면 좋았을 날임.
AI로 좋은 코드 짤 수는 있음. 문제를 한입 크기로 쪼개고, 리뷰하고, 필요하면 수정하면 됨. 근데 내 체감으론 오히려 더 느렸음.
내가 아는 시니어+ 엔지니어들(FAANG 포함) 대부분은 이제 코드 안 짜고 AI만 씀. Claude code 메모리 세팅을 꼼꼼히 해두고, 필요한 걸 잘 안내하면 시니어급 코드가 10배 속도로 나옴. 난 이게 싫음. 코딩이 그리움.
하… 우리 CEO도 이번 주 내내 이러고, 팀 전체(비개발자들, 기술 리터러시도 ㅆㅂ 거의 없음)한테도 문 열자고 함. 난 "새 dev 4명 뽑아놓고 하고 싶은 대로 vibe code 하라고 두진 않을 거잖아, 비개발자한테 그걸 왜 시킴?"이라고 했음. 말도 안 되는 PR들 고치느라 내 시간을 얼마나 태우길 바라는 거냐고. 결국 프로토타입은 그만 하게 제한하기로 동의했음, 회사는 걔 거니까. 근데 난 그런 식으로 같이 만든 코드베이스를 감독하진 않을 거임.
ㅇㅇ 우리도 제품 사람들이 V0로 뭔가 만들고는 프로덕션 준비 끝났다고 생각하는 거 많음.
인증도 없고, 우리 컴포넌트 라이브러리도 안 쓰고, 어떤 건 아예 다른 스택 쓰고, 데이터도 연결 안 돼 있음… 그냥 쳐다보고 "뭐라는 거임 ㅆㅂ?" 하게 됨.
이미 숙련 개발자고 '좋음'과 '끔찍함'을 대충 구분할 줄 알면, 겉만 그럴듯한 게 아니라 실제로 동작하는 것도 만들 수 있음.
ㅇㅇ 근데 그쯤이면 "vibe-coding"이 아니라 그냥 AI 보조 코딩임 ㅋㅋ
이것도 "survivor bias"임.
대충하는 "vibe coder"는 AI 성공담을 자랑하다가 오만함 밑에서 무너지기 전까진 떠들어댐.
…반면 보안 잘 되고 최적화된 제품 만든 시니어 dev는 AI 썼단 말조차 안 함.
그리고 불행히도 헬스케어 쪽 개발이라는 특정 니치에 들어가 있는 사람으로서: 환자 관리용으로 새로 나오는 앱들 중 충격적으로 많은 게 그냥 vibe coded임. 왜냐면 절반이 sikka를 쓰는데, 이건 헬스케어 업계용으로 만든 어이없을 정도로 멍청한 AI vibe coding 플랫폼임. 더 웃긴 건, 내가 본 바로는 sikka로 만든 앱을 쓰려면 시스템에 sikka를 깔아야 함.
난 sikka 앱들이 더 싸게 받아서 고객을 뺏기는 소프트웨어도 해봤는데, 몇 달 지나면 버그 투성이인 경우가 거의라 결국 다시 돌아오더라.첫눈엔 그럴듯해 보이는 걸 만들어냄
맞음. 예전엔 미숙하거나 게으른 개발자가 회사 속여서 버그 투성이 유지보수 불가한 걸 주곤 했는데, 이제는 글 생성기로 더 빨리 사기칠 수 있음. 결국 근본 문제는, 너무 많은 관리자/PO가 품질 판단을 못 해서 너무 낮은 품질을 그냥 통과시킨다는 거였음. 결과는 늘 고객 불만이고, 몇 년 뒤 버리고 제대로 된 소프트웨어로 교체(최선)하거나, 망가진 쓰레기를 고치느라 처음 제대로 했을 때보다 훨씬 더 시간/돈을 쓰면서 수년간 나쁜 제품을 끌고 가는 거임.
그건 웹개발에서 늘 있던 일임. 사람들은 우리가 비밀 버튼 조합 눌러서 작동하는 소프트웨어를 뽑아내는 줄 앎. 언제나 실제보다 더 빨리, 더 싸게 되어야 한다고 생각함. 그리고 당연히 버그는 없어야 하고.
"그냥 vibe code 하면 되잖아" 떠드는데도, 비개발자가 복잡한 프로덕션 앱 만드는 사례가 이렇게 안 보이는 게 신기함.PM이랑 임원들이 얼마나 밀어붙이는지 놀라움. 이번 주 내 매니저가 리더십이 우리 코드 대부분이 LLM에서 나오길 원하고, 안 쓰면 뒤처진다며 반드시 쓰라 함. 우리 제품은 가까운 미래에 더 ㅈ될 거임, vibe coding하고 AI를 모든 데 끼워 넣으려 하니까.
그 매니저는 있는 동안 보너스 달게 먹고, ㅈ될 조짐 보이면 다른 회사로 옮겨서 거기서도 똑같이 할 거임.
'그냥 vibe code 하면 됨' 하는 애들은 AI 생성 코드는 완성품이 아니라 스캐폴딩이라는 걸 모름. 물론 한 시간 만에 기능 있어 보이는 걸 띄울 순 있는데, 유지보수/스케일/디버깅은 결국 터질 때 지옥임. 속도를 품질로 착각하는 거임. 그냥 하드하게 배우게 두셈 — $500 프로젝트가 $5K 악몽으로 변하는 게, 어떤 논쟁보다 잘 가르침.
난 강하게 반대함.
그 쓰레기불은 정원 불, 산불… 이런 식으로 잘 스케일될 거임.AI를 그냥 또 다른 도구로 보고, 어떤 도구를 썼든 작성된 소프트웨어 자체로 평가하면 안 됨?
난 이런 논쟁 지겨움.
그리고 vibe coding이 고수준 도구로 감독 없이 전부 맡기는 거라면, 그건 예전처럼 거의 확실히 쓰레기불 됨.우린 그렇게 하고 있음. vibe coded 소프트웨어가 좋았으면 이런 대화 자체가 안 나왔겠지.
vibe coding은 MVP나 프로토타입엔 좋음. 스케일하거나 유지보수해야 하는 건 최악임. 진짜 문제는, 클라이언트가 AI가 코드 쓰는 걸 보고 "그럼 왜 개발자 돈 냄?"이라 생각한다는 거임. 근데 디버깅, 아키텍처 결정, 보안, 엣지 케이스… 이런 건 안 보임. AI는 도구임. 제대로 쓰려면 좋은 코드가 뭔지 아는 사람이 필요함.
난 새 기능이나 버그 수정하면서 테스트 쓰는 데 쓰고 있음. ㅈㄴ 좋고 시간 많이 아껴줌. 테스트 문서도 만들었는데 이제 거의 자급자족임.
그냥 "insert file here"에 대해 테스트 플랜 만들라고 하면 테스트 케이스 쭉 뽑아주고, 난 거기서 추가/삭제한 다음 걔가 만들어줌. 가끔은 ㅈㄴ 멍청해서 무조건 통과하게 만들려고 안 해야 할 스텁을 박기도 하는데, 그래도 테스트 속도는 확실히 빨라졌고 몇 가지도 잡아줬음.ㅇㅇ 테스트는 좋은 유스케이스임. AI는 패턴 잘 따라가고, 테스트는 대부분 패턴 기반임.
"안 해야 할 걸 스텁한다"는 게 바로 dev가 리뷰해야 하는 이유 ㅋㅋ
업계가 완전히 망하기 전에 그랬으면.
아는 사람들은 결정권자가 아님.
에이전트들 엄청 테스트해봤는데, 최신 논문들이 말하는 결론이랑 같았음. 예: https://arxiv.org/abs/2601.20245
이건
사람을 멍청하고 게으르게 만듦, 그리고
DOC가 있으면 DOC로 하는 게 항상 더 빠름.
스캐폴드 만들기엔 괜찮지만, 그때도 버전이나 디펜던시 같은 걸로 큰 실수 하기도 함.
난 이제 IDE에서 에이전트 안 씀. JetBrains 옛 자동완성만으로도 충분히 됨. 제발 사람들한테 강제로 안 시켰으면 하고, 지금 많은 소프트웨어 시스템 문제는 아마 이것 때문일 거라고 봄.그렇게 쉽다면, 그냥 니가 직접 vibe code 하라고 해.
항공우주공학 교수 농담 생각남.
"교수님, 우리 학생들이 설계한 비행기 타도 안전할까요?"
"완전 안전하지! 그 망할 건 애초에 이륙도 못 하거든!"멍청한 사람들이 뭐라 하든 뭐 하든 신경 끄셈. 그런 놈들 많고, 넌 수적으로 밀림.
웃긴 건 vibe coding이 프로토타입이나 데모엔 ㅈㄴ 잘 먹힌다는 거임. 그래서 클라이언트가 제품이 다 끝난 줄 착각함. 그러고는 아무도 출력물 리뷰 안 해서 AI가 만든 걸 고치느라 원래 예산의 3배 씀. 지난달에 클라이언트 하나는 2일 만에 앱을 통째로 vibe coded로 만들었고, 그다음 프로덕션에서 돌아가게 만들려고 6주 동안 내 돈 줬음.
비즈니스는 vibe coded인지 아닌지 신경 안 씀. 주니어는 배울 건지 AI에 눈감고 프롬프트 찍을 건지 신경 안 씀. 이제 걔들은 프로그래머가 아님. 가게에서 산 인스턴트 라면에 뜨거운 물만 붓는 사람이면, 그걸 셰프라 부르지 않잖음.
vibe coding은 데모랑 MVP엔 좋고, 1주차 넘게 살아야 하는 건 안 됨. 사람들은 빠른 시작을 완성된 시스템으로 착각함. 뒷정리, 보안, 엣지 케이스, ops는 보통 처음부터 제대로 하는 것보다 더 비싸짐.
중요한 비즈니스 걸 거기에 얹고, 결국 파산할 때.
요즘 기본 로그인 프롬프트 같은 거에서 문제 많이 봄. 이건 꽤 단순한 거라 보통 주니어한테 내려갈 텐데. 어떤 프롬프트는 전화번호를 () - 문자까지 자동 포맷했는데, post script는 숫자 아닌 문자를 받지 않아서 제출이 안 됐음. 자동입력 스크립트는 () -를 지우려 해도 다시 넣어버려서, 문자 그대로 제출이 불가능했음.
이건 더 심해질 거임.사람들이 충분히 돈 잃으면.
그런 사람들은 vibe coding 전부터 있었음. vibe coding도 AI 전부터 있었고, 이름만 바꾼 거임. AI는 도구고, 실력 있는 사람은 언제 쓰는 게 좋은지 앎.
답은 간단함. "아 그럼 니가 직접 vibe code 하셈. 난 표준 엔지니어링 단가 받음."
문제는 vibe coding이 아님. vibe coding이 코딩을 쉽게 만든다고 생각하는 게 문제임.vibe coding은 스케일링 문제 만나면 폭망할 거임.
어떤 "인플루언서"들이 찬가 부르는 걸 멈출 때.
vibe coding은 개구리지만, 17년차 시니어 dev로서 내가 엄격한 개인 기준으로 가이드하면 AI 코딩은 미친 생산성임. ㅋㅋ 매일 얼마나 빨리 되는지 아직도 놀람.
왜 사람들이 계속 vibe coding이란 말을 정당화함? 사람들이 그 말을 안 쓰면 사라질 거임.
이건 무숙련 dev가 vibe coding 하는 경우엔 맞는데, 소프트웨어 엔지니어링 밖 사람들은 "agent architecturing"이 얼마나 많은 양의 프로덕션 품질 코드를 만드는지 모름 — 숙련 dev 한 명이 여러 에이전트랑 작업하면서 컨텍스트, 프롬프트, 제약을 제대로 정의하는 거임.
매우 적은 성공한 개발 회사만이 AI를 안 쓰고 있음, 대부분은 AI로 SDLC를 가속하고 있음 — 투자자용 구호가 아니라, 실제로 $20/월로 생산성 10~20% 올리고 있음.vibe coding 얘기할 때 사람들이 잘 안 하는 포인트 몇 개 있음.
새 vibe coder는 평균적으로 새 엔지니어보다 결과가 더 나음. 새 엔지니어 코드 품질은 예전부터 가끔 쓰레기였음. vibe coding이 조금이라도 더 낫다면 산업에 영향 큼.
둘째로, vibe coder도 새 엔지니어처럼 배울 수 있음. 뭐가 먹히고 뭐가 안 먹히는지 배우고, 그러다 보면 스케일 잘 되고 보안 좋은 앱을 만들 수 있는 vibe coder가 나올 수도 있음.
내 경험상 vibe coder의 핵심 문제는, 배워서 성장하는 사람과 안 하는 사람을 이력서/포트폴리오로 구분하기가 어렵다는 거임. 비엔지니어는 차이를 절대 못 봄. 근데 엔지니어가 앉아서 대화해보면, 배우는 놈과 아닌 놈은 금방 가려짐.
결국 사람들은 결과를 선호함. 3년 동안 잘 굴러가는 $5짜리 웹사이트를 쓰다가 3년 뒤 문제 생기면 또 $5로 새로 만들면, 오늘 $2000+ 주고 나중에 문제 없을 걸 만드는 것보다 사람들에겐 더 이득일 수 있음. 물론 그 돈을 줬는데도 루키 엔지니어가 똑같은 문제를 수동으로 만들면 더 최악이고.
이게 내가 보는 vibe coding 비판의 핵심 문제임. vibe coder가 겪는 문제는 내가 본 거의 모든 저레벨 엔지니어들이 만드는 문제보다 덜 자주, 덜 치명적으로 터짐. 그리고 불행히도 프리랜서 엔지니어 대부분(전부는 아니지만)은 큰 회사에서 만난 평균 엔지니어보다 훨씬 덜 경험 많았음.
여기서 가끔 vibe coder 제품을 1억 MAU 처리할 제품처럼 취급하는데, 현실은 대부분 <1000 사용자 정도의 작은 웹사이트/앱만 원함. "스케일"은 그 회사들에겐 관심사 최하위임. 여기 사람들은 공격적 과설계가 정답인 양 말하곤 하는데, 그게 아님.음, vibe coder랑 진짜 새 dev의 가장 큰 차이는 vibe coder는 이해 못 하는 문제나 에러에 부딪혀서 AI가 못 고치면 뭘 해야 할지 몰라서 완전 막힌다는 거임.
근데 dev는 신입이라도 문제 풀 정보가 이미 꽤 있음. 검색해서 답 찾는 법도 알고, 찾은 답이 맞는지 틀린지 감도 있음.
vibe coder가 버그/문제 고치는 건 그냥 기도해서 기계 신이 자기 난장판 고쳐주길 바라는 수준임. 그게 효율적일 리가.
물론 vibe coder도 배워서 더 나은 dev가 될 수는 있는데, 대부분은 애초에 배우려 하지 않을 거임. 그게 vibe coder의 포인트잖아? 프로그래밍을 배우고 실제로 지식 있는 dev가 되기 싫은 거, 원하면 할 수 있는데도.
vibe coding은 경험 없는 dev가 하면 나쁘고, 코드 품질 신경 쓰는 시니어가 몰면 생산성 엄청 오름.
그럼 vibe coding이 아님, 경험 많은 엔지니어가 적절한 도구 쓰는 거지. vibe coding은 정의상 미숙한 사람들이 AI로 감으로 코딩하는 거임.
누가 말했듯, 새 병목은 코드 리뷰 능력임.
LLM이 나쁘다는 글을 올릴 용기 있는 사람이 드디어 나왔네. 마지막으로 이런 글 본 게 하루 전인 것 같음.
AI한테 더 모듈화되고 스케일 가능한 소프트웨어를 만들라고 못 할 이유가 없음. 나도 지난주에 했음. 처음엔 스파게티 코드 만들라고 했더니 혼란 그 자체라서, 작은 모듈로 쪼개고 연결하라고 방향 틀었더니 깔끔하고 이해 쉬워짐.
AI가 전부 하게 두고 그냥 고치라고만 하는 거랑, 모듈/재사용 가능한 코드로 쪼개라고 하는 건 다른 얘기임.vibe coding은 구림. 맞음. 근데 agentic coding은 쓰레기불이 아니고 사라지지 않을 거임.
내 손으로 말아 만든 어셈블리보다 컴파일러가 구리다는 걸 사람들은 언제 깨달을까?
내 로또 당첨보다 직장이 구리다는 걸 사람들은 언제 깨달을까.
난 시니어 백엔드 dev고 프론트 경험은 적음.
그래도 이건 이미 되돌릴 수 없다고 생각함.
AI 버블이 언제든 터질 수는 있겠지만, 개발용 도구 자체는 사라지지 않을 거임.
변화는 받아들여야 하고, dev들은 "ai code architects" 같은 역할로 적응해서 이 도구를 써야 함. 이게 사라질 거라 진짜 생각 안 함.
문제 풀 때 구글링하고 프레임워크를 하나씩 따로 배우던 과거로 돌아가는 건 말이 안 됨.
AI 산업 전체가 수익이 안 나서(비용이 너무 커서 어떤 AI 솔루션도 못 쓰는 수준) 무너지지 않는 한, 이건 안 사라짐.
좀 별로임. 난 40이고 경제적으로 불안한데, 어쩔 수 없음.소프트웨어만 영향 받는 거임? 건축도 vibe cadding으로 하거나 하드웨어도 vibe designing함? 영상/애니메이션은 프롬프트로 하는 게 vibe 영역 같긴 한데, 그쪽은 잘 몰라서 AI가 어떻게 쓰이는지 모르겠음.
비프로그래머한테 난 이렇게 되묻는 거 좋아함. "오케이, 심장 수술이 필요하다고 치자. 내가 수술은 해줄게, 대신 하면서 ChatGPT에 어떻게 하는지 물어보면 됨?"
좀 덜 심각하게는 "난 집 지어본 적 없는데 ChatGPT가 $500,000짜리 맨션 짓는 법 알려줄 수 있음. 숙련 건축가나 시공업자 안 고용하면 얼마나 아끼겠어!"
Microsoft, Atlassian 같은 대기업도 그걸 이해할까? 요즘 그 플랫폼/제품들이 점점 "vibe coding 스타일"로 만들어지는 느낌이고, 잦은 다운타임이나 프로덕션 버그가 그 증상 같음.
IT 프로젝트 10년 했음.
Developer = 좋은 코드, AI = 나쁜 코드라는 서사는 말도 안 됨. 코드 품질이 AI 전엔 큰 문제가 아니었던 것도 아니잖아.차이는, 예전엔 누군가가 알고 있고(적어도 그렇다고 가정했고), 누군가가 책임졌다는 점임. 지금은 둘 다 없음.
형 스케일 얼마나 할 건데, 대부분 프로젝트는 유저 100만도 못 찍음. 100만 찍으면 돈 생겨서 다시 쓰면 됨.
너 아직도 자동변속기에서 다들 떠나겠지, 그냥 유행일 뿐이고 안 뜰 거라 믿는 타입이냐
모르겠는데, openclaw가 지금 주인들 위해 기능 되는 코드 많이 뽑아주고 있음. 스펙만 잘 쓰면 토큰이 brrrrr 하면서 나감.
vibe coding은 빠른 프로토타입에 빛남. 그 아이디어들 스케일링하려고 Base44 써봄?
난 vibe coding 자체가 문제라고 보진 않음; 근본적으로 생산성 도구임. 문제는 너무 쉽게 오용된다는 점임. 진입장벽이 낮아서 미숙한 엔지니어가 slop을 대량 생산할 수 있고, 반대로 좋은 엔지니어도 안일해질 수 있음. 도구는 받아들여야 하지만, 절제와 올바른 마인드로 써야 함.
난 이게 Perl과 CGI bin 배포 시절이랑 비슷하다고 봄. 제작자가 옆에 있고 문서가 있지 않으면 Perl 유지보수 배우러 들어가진 않을 거임. "write once read never"라는 말도 있었고, 그래서 탄탄한 모듈 위에 기능을 확장하거나, 일주일 들여 통째로 다시 쓰는 식이었음.
그건 멍청해 보이지만, Perl은 숙련되면 쓰기 쉬웠고 그땐 stackoverflow도 없고 포럼도 적고 전부 책과 기억의 시대였음. 아무도 안 쓰는 perl cookbook 같은 것들, 사실상 쓸모 없잖아. HeadFirst Java도 목표가 순수하게 Java 학습이 아니면 읽지 않을 거고. 그냥 Cursor 켜고 새 툴체인으로 코드 쓰면 됨. 그게 차이임. 회사들은 "Elixir만 써", "only use rust" 같은 프롬프트 스타일 가이드를 만들 거고, 그러면 LLM에 컨텍스트를 스파게티 프롬프트로 크게 올리고 프롬프트를 치게 됨.
결국 어떤 구조가 태어날 거고, 그 구조는 AI랑 상호작용하면서 slop 코드를 쓰는 형태일 수도 있음. 다만 전부 블랙박스라서, 지시를 흉내만 내면 안에서 뭘 하든 상관 없어짐. 그래도 사람들은 미래 IT 역할에서 자기 의사를 표현하는 법을 알아야 하고, 아니면 오래 못 감. 문법 매일 시킨 엄마한테 감사함 ㅋㅋ.2025엔 스케일 안 됐지만 2026은? 2027은? 4년 전 AI는 자동완성만 했는데, 그다음엔 단순 앱 만들고, 지금은 더 복잡한데 스케일 안 되는 걸 만들 수 있음, 그래... 근데 문제는 앞으로 몇 년 뒤에 뭘 할 수 있느냐임, 난 2~3년을 말하는 거임.
난 이 도구들이 쓰이는 목적에 대해 나아진 증거를 못 봤음, 더 효율적일 뿐임. "vibe engineering"은 처음엔 좋은 아이디어 같았는데 그냥 더 그럴듯한 slop임. 여전히 쓰레기임. 좋은 엔지니어는 첫 원샷 프롬프트 이후에도 이 도구로 뭔가 쓸 만한 걸 하려면 여전히 필요함.
세상은 복잡하고, 얘들은 아직도 그걸 이해하는 데 엄청 못 함.
난 AI에 반대하진 않지만 개발도 배우는 중임. 내 지역에서 처음 연락 온 일자리가 vibe coder 역할이었는데, 디자인 입력은 금지고 전부 AI로만 빌드해야 한다고 아주 구체적이었음. 급여는 좋았지만, 하루 종일 AI 코딩만 하면 스킬 상한이 그걸로 끝날 듯해서 고민됨. 그리고 다른 회사로 옮길 때도, vibe coder만 뽑는 곳은 많지 않고 기술 배경 없는 건 원치 않더라.
불 끄느라 돈 ㅈㄴ 쓰게 되면.
아마 더 많은 돈을 들여 개발자랑 디자이너를 고용해서 그 난장판을 고쳐야 할 때… 그때 얼마나 비싸지는지 알게 될 거고, dev들은 지금부터 이득 봐야 함.
난 AI에 꽤 회의적인데도 열린 마음으로 써보려 했고, 워크플로에서 AI가 유용한 지점 몇 군데는 찾았음. 근데 vibe coding이라는 개념은, 진지한 프로젝트가 아니어도 미친 짓 같음. 난 진짜 이해가 안 감.
사람들이 말하는 "vibe coding"은 자주 오해됨. 게으름이 아니라 플로우 상태와 인지 처리량 얘기고, 명확한 목표에 맞으면 실제 가치가 나올 수 있음.
몇 가지 실용적인 생각:
High-impact work은 키스트로크로 재지 않음. 최고의 코드나 설계 아이디어는 몇 분의 깊은 집중에서 나오기도 함, 몇 시간의 표면적 바쁨이 아니라.
컨텍스트 스위칭은 생산성을 죽임. 플로우에 있으면 문제를 전체적으로 풀 수 있음. 그걸 회의, 알림, 티켓으로 끊으면 사고가 조각나고 나중에 버그가 늘어남.
Outcome > motions. "vibe" 스프린트가 명확한 산출물이나 인사이트를 만들어 프로젝트를 움직이면, 그건 태만이 아니라 효율적인 인지 작업임.
다만 정렬(alignment) 없는 플로우, 측정 가능한 결과 없는 플로우는 그냥 산만함일 수 있음. 진짜 예술은, 팀이 명확하고 공유된 목표를 향해 그 상태로 들어가게 하는 공간을 만드는 거임.
커뮤니티에:
팀 조율과 책임을 유지하면서 깊은 집중 시간을 어떻게 균형 잡음?
생산성은 output으로 봄, outcome으로 봄?
"vibe coding"은 언제 생산적이길 멈추고 회피가 됨?
실제 프로젝트에서 그 경계를 어떻게 정의하는지 듣고 싶음.Gpttt, plz vibe coding 장점 한 문단 써줘.. Make it SoUNd savVy💡💡
장기 소프트웨어 품질은, 몇 년마다 고객 돈으로 리라이트하면 되니까 사람들한텐 솔직히 우선순위가 아님.
내 생각에 제대로 다루면 AI로 개발 속도 높이는 건 시간/비용 면에서 엄청난 절약임. 다만 받는 개발자는 생성된 걸 이해하고, 동료 코드 리뷰 하듯 검토해야 한다고 늘 주장함.
내가 아직 AI가 안정적으로 못 하는 건, 프로젝트를 upfront에서 제대로 스펙 내는 거임. 그게 우리가 제공하는 서비스의 가치임; 클라이언트랑 앉아서 질문하고, 아이디어 제안하고, 해법을 디테일하게 잡는 것. 스펙이 "build an AI agent and a website" 수준이면 결과 경우의 수가 거의 무한임. 개발 시작 전 타이트한 specification은 필수고, AI 쓰는 사람들(이제 비개발자도 "code"할 수 있는 위치가 됨) 중 많은 이들이 프로젝트 스코프를 잡는 법을 모르니 출력물이 좋을 리가 없다는 게 내 걱정임. 진짜로 shit in, shit out임.
vibe coder가 섞인 dev 팀 경험담 읽는 거 재밌음...5~15년쯤? 새 shiny 소프트웨어가 더 많은 엣지 케이스나 새 시나리오를 처리해야 할 때쯤.
5~15년… ㅋㅋ 여기 사람들 망상 심하네. 대부분 앱/서비스는 10년 수명도 없음. ERP나 은행 소프트웨어만 있는 게 아님. 대부분은 다음 react / node app이고, 최신 ㅈ같은 걸로 2~4년마다 갈아엎음.
그리고 Claude / ChatGPT가 1~2년 전 어디 있었고 지금 어디인지 보면.. 속도 / iterations. 5년 뒤엔 뭐가 되겠냐?
여기 대부분은 쓸모없어질까 봐 두려운 거고 - 대체로 그게 사실이어서임. 5년 뒤엔 "web developer" 필요 없음.
vibecoder랑 vibe coding 띄우는 사람들은, 실력이 없으면 AI 제공자가 스로틀 걸거나 Claude가 며칠~몇 주 갑자기 멍청해지거나, 몰래 양자화 모델을 받는다거나 등등 많은 요인에 의존하게 된다는 걸 잊음.
맞음.
내 생각엔 이건 좋은 일임. 소프트웨어는 금융충이랑 제품팀이 장악했고, 걔들은 소프트웨어 만드는 걸 💩도 모름. 이게 더 많은 (real) software dev가 문제 풀려고 창업하게 만들길 바람. 멍청이들한텐 AI 쥐여주고 발등 찍게 두자.
Upwork에서 그런 "인재" 찾게 두셈. vibe coded 앱 고치는 수요가 큰 건 놀랄 일도 아님.
vibe coding은 지금은 유행하는 지름길처럼 보이지만, 무너지는 벽에 페인트 한 번 더 칠하는 거랑 같음; 처음엔 좋아 보이다가 금 가기 시작함.
vibe coding은 빠른 결과로는 매력적이지만, 기술 환경이 진화할수록 품질과 지속가능성이 더 강조될 거임.
많은 사람이 개발자의 가치가 AI 때문에 줄었다고 생각함 - 그냥 말하면 AI가 다 해주고 뿅 앱 완성이라고.
이건 완전 오해임. 비기술자가 자칭 vibe coder라고 해도, 완전 기능하는 스케일 가능한 application은 못 만듦. 제대로 된 login도 못 만드는데, 그조차 token을 찾아서 AI에 주는 지식이 필요하니까.vibe coding으로 스케일 못 하는 걸 만든 사람은 애초에 스케일이 필요 없을 거임.
스케일이 필요할 걸 만드는 사람은 vibe code 안 함, 코딩 지원으로 에이전트 씀.
vibe coding =/= using a coding agent.vibecoding 쓰레기불은 스케일 증가를 손쉽게 처리함. 적어도 "쓰레기불" 부분은.
절대 안 됨. 1970년부터 사람들은 스케일 안 되는 쓰레기불을 만들어왔고, 그중 꽤 많은 게 살아남아 지금은 글로벌 스케일 레거시 쓰레기불이 됐음.
vibe coding은 그걸 뿜어내는 속도만 올렸을 뿐임.
그렇다고 노예 임금으로 일하자는 이유는 아님. AI 회사들이 충분히 채택을 확보하면, 수익 내려고 서비스 enshittification 시작할 테고 vibe coding 비용은 폭등할 거임.지금은 그냥 이런 상태임. 문제만 해결되면, 구린 해법도 잘 먹힘.
네 말이 맞음. 근데 대부분 그게 중요하지 않다는 걸 놓치고 있음. 큰 제품에 여러 모듈 붙이는 거면 vibe coding은 큰일남. 근데 인터넷의 40%+가 그냥 WordPress에 약간 손본 정도잖아. 그런 데엔 vibe coding이 딱임.
둘 다 자리 있음. dev가 2일이면 할 작은 건, vibe coding이 훨씬 싸게 똑같이 해냄. 반대로 연중 풀타임 dev가 필요한 큰 건, vibe coding이 자멸함."너도 할 수 있음."
vibe coding을, 밑에 주니어들이 있고 네가 가르치면서 말 잘 듣고 배우는 상황으로 보면 됨. 딱 그거임. 어느 정도 가이드는 필요하지만, 귀찮은 작업은 프롬프트로 뽑아내면 됨.
vibe coding 포인트가 농담이고 스케일 안 되는 쓰레기불 만든다는 거 아니었나?
칼이랑 팬은 누구나 살 수 있음. 근데 아무나 맛있는 요리는 못 함.
난 이틀 동안 ffmpeg로 미디어 처리 파이프라인을 vibe code 해보려 했음, 예전 지식으로 만들던 "template" 수준의 평범한 web app이 아니라.
그 시간 절반은 docs를 읽었는데, AI가 attributes랑 filters를 대부분 지어내서 내가 docs 읽고 어떻게 하라고 말해줘야 했음.시장은 결국 알아서 교정됨. 시간당 $8 주는 사람은 $8 품질 코드를 받고, 나중에 그거 고치는데 10배를 씀.
세상엔 언제나 제일 싼 폐품 시장이 큼. Amazon도 컨테이너선 단위로 팔잖아. 품질 파는 사람은 걔들이 교훈 배우길 기다려야 함.
사람들은 vibe coded 앱이 너무 휘발성이라는 걸 알게 될 거고, 앱 무덤이 거대해질 거임. 그래도 AI 전보다야 낫지.
섬유 노동자들이 Spinning Jenny가 왔을 때 부수려 했지만 소용없었음. 현실 받아들이고 AI 배우고 활용하셈.
모래 위에 짓는 거랑 같음!
1년 전에 vibe coding 해봤는데 쓰레기였고, 지금은 그럭저럭(okish)임. 5년 뒤엔 완전히 새로운 걸 만드는 게 아니라면 AI가 너보다 더 잘할 거임.
대부분은 안 할 거임. vibe coding이 비교적 짧은 시간 안에 쓸 만해질 거라서.
