"바이브 코딩 청소 서비스"의 등장

(donado.co)

10P by GN⁺ 18시간전 | ★ favorite | 댓글 3개

최근 "바이브 코딩 클린업" 이라는 새로운 서비스 카테고리가 IT 업계에서 등장함 : Vibe Coding Cleanup as a Service
AI 생성 코드의 대부분이 프로덕션에 적합하지 않다는 현실이 드러나면서, 이를 정리·수정하는 새로운 서비스 시장이 등장
Andrej Karpathy가 2025년 초 “Vibe Coding” 을 정의한 이후, 개발자 92%가 AI 도구를 활용하지만 코드 품질 저하와 보안 취약점 문제가 심각하게 드러남
실제로 개발자들은 AI가 만든 불일치·중복·비합리적 로직을 해결하는 데 전문적으로 종사하며, 전용 마켓플레이스와 컨설팅 서비스가 확산 중임
AI는 작은 작업에는 뛰어나지만 시스템 맥락을 고려하지 못해 구조적 부채와 보안 문제를 양산하며, 이는 곧 "정리 경제"라는 새로운 산업 기회를 낳음
기업이 성공적으로 AI 코딩을 활용하려면 프로토타입은 AI에 맡기되, 아키텍처·보안·테스트 정리 과정에 전문 인력을 투자해야 함

바이브 코딩의 등장과 확산

2025년 초 Andrej Karpathy가 “바이브 코딩” 이라는 용어를 사용하며 개념이 정착됨
- 자연어 대화를 통해 함수 전체를 생성하는 방식
- 생산성을 10배 향상시킬 수 있다는 기대와 함께 빠르게 확산
GitHub에 따르면 개발자의 92%가 AI 코딩 도구를 사용하고 있음
- Copilot은 매달 수십억 라인의 코드를 생성
그러나 GitClear 분석에 따르면 AI 코드 사용 시 41% 더 높은 코드 변동률이 나타남
- 2주 이내 되돌리거나 재작성되는 코드가 크게 증가
Stanford 연구에서는 AI 보조를 쓰는 개발자가 보안성이 낮은 코드를 더 많이 작성하면서도 더 안전하다고 믿는 경향을 보임
AI 도구는 입력 검증 부재, 구식 의존성 사용, 애매한 설계 결정 등으로 인해 여러 가지 안티패턴을 증폭시키는 문제를 유발

정리 경제의 현실

최근 IT 업계에서는 바이브 코딩 클린업이라는 새로운 서비스 영역이 조용히 등장
초기에는 "AI가 만든 엉망진창 코드를 고친다"는 농담 수준에서 시작하였으나, 이제는 실제 비즈니스 기회로 자리잡는 모습
404 Media 조사에 따르면, 일부 개발자들은 AI 코드 정리만으로 경력을 쌓고 있음
- “AI 스파게티”라 불리는 불일치·중복·엉뚱한 로직을 해체하는 일
Ulam Labs는 Vibe Coding Cleanup 을 핵심 서비스로 광고
VibeCodeFixers.com 이라는 전용 마켓플레이스도 등장
- 몇 주 만에 300명 이상 전문가가 가입하고 수십 건의 프로젝트 매칭
- 전형적 고객: “수천 달러의 OpenAI 크레딧을 소모하고 반쯤 동작하는 프로토타입을 가진 스타트업”

AI 코드가 실패하는 이유

AI 자체가 나쁜 코드를 쓰는 게 아니라, 시스템 맥락을 이해하지 못하고 국소적으로 최적화된 코드를 쓰는 것이 문제
결과적으로 불일치 패턴·중복 로직·보안 허점이 쌓이며 기술 부채 발생
Georgetown University 연구에 따르면 AI 생성 코드의 최소 48%가 보안 취약점을 포함
- 비밀 정보 노출, 오래된 라이브러리 사용, 부하 상황에서 발생하는 경쟁 조건 등
더 심각한 점은, 개발자 본인이 AI가 생성한 코드를 충분히 이해하지 못해 문제를 제대로 발견하지 못하는 현상
Thoughtworks는 이를 “역량 부채” 라 정의
- 팀이 코드 유지보수 능력을 상실하고 AI 의존에 빠지는 현상

시장 기회

클린업 시장이 급성장 중이지만, 구체적인 수치 파악은 어려움
Gartner는 2028년까지 기업 개발자의 75%가 AI 코드 보조를 사용할 것이라 전망
- 대부분 프로젝트에서 정리 필요성이 발생할 것으로 예상
- 이 중 일부만 클린업이 필요하다고 해도, scale상 상당히 거대한 신시장으로 부상함
경제적 측면에서도 매력적임
- 스타트업은 AI로 빠르게 MVP를 만들지만, 이후 정리에 동일한 시간과 비용을 투입
- 그래도 전통 개발보다는 여전히 빠른 속도
정리 전문가들은 시간당 200~400달러를 청구
- 정액제 패키지·AI 코드 감사·“Vibe-to-Production” 파이프라인 같은 제품화된 서비스도 확산
Thoughtworks에 따르면, AI 활용 프로젝트에서 리팩터링 비율이 감소하고 코드 변동이 더 늘었으며, 실제 프로덕션 투입 전에 대규모 정리 과정이 필수로 요구됨
- 다수의 컨설팅기업이 AI 코드 클린업 또는 리미디에이션 역할 전담 인재를 채용 시작함
- 결론적으로, 클린업 시장은 실재하며, 빠르게 성장하고 있고 아직 미개척 영역이 많음

엔지니어링에 미치는 영향

소프트웨어 개발 방법론의 근본적인 변화가 진행 중
개발 프로세스가 AI가 구현 → 사람이 아키텍처·테스트·정리 담당하는 분업 체제로 재편
Gergely Orosz는 AI 도구를 " 매우 의욕 넘치는 주니어 개발자" 에 비유하며, 빠른 속도로 코드를 작성하지만 늘 감독이 필요함을 강조함
- 하지만 AI는 항상 주니어 개발자 수준에 머무르며 시니어로 성장하지 않으므로, 항상 정리 전문가의 역할이 필요함
새로운 커리어 경로도 열림
- 주니어 개발자가 정리 기술을 익히면 2년 만에 시니어 급 연봉 가능
- AI의 강점과 한계를 이해하는 시니어는 높은 가치 창출
성공하는 기업은 AI를 가장 많이 쓰는 곳이 아니라, 정리 프로세스를 체계적으로 구축하는 곳
- 견고한 클린업 프로세스를 구축한 조직은 시장에서 경쟁 우위를 가질 수 있음

Donado Labs의 입장

Donado Labs는 수많은 바이브 코드 정리 경험을 기반으로, AI는 가속화에 유용하지만 반드시 전문가 정리 과정이 필요하다고 강조
프로토타이핑과 반복 작업에는 AI를, 핵심 아키텍처와 보안·테스트는 사람이 담당
“Vibe to Production” 서비스로 AI 프로토타입을 기업 수준으로 정비
- 테스트, 보안 강화, 문서화까지 포함
AI 코딩을 성공적으로 활용하는 기업은 AI를 가장 많이 쓰는 조직이 아니라, AI를 똑똑하게 활용하고 정리를 투자하는 조직임
- 기술 부채 누적 이전에 클린업을 병행하는 것이 핵심
- AI가 프로그래머를 대체할 것이라는 주장에 대해, "그 코드 정리는 누가 할 것인가?"라는 질문이 진짜 비즈니스 기회임

▲

aer0700 8시간전 [-]

바이브 코딩 등장 이전에도 엉망진창 코드를 정리해주는 서비스가 있으면 좋겠다는 생각을 하긴 했었는데, 이렇게 누군가는 만드네요. 하지만, 우리 회사에서 도입할 일은 없을 것 같습니다 ㅠ

답변달기

▲

t7vonn 16시간전 [-]

AI그림 손가락 고쳐주는 외주가 유행이었는데.. 지금은 그것마저도 안하게 됐거든요

AI 클린업도 그런 전철을 밟을 것 같긴 하네요

답변달기

▲

GN⁺ 18시간전 [-]

Hacker News 의견

나는 꽤 오랫동안 비즈니스를 통해 “구조” 프로젝트를 맡아왔음
예전에는 거의 동작하지 않는 코드를 주로 외주 에이전시에서 받았지만, 요즘은 그 근원이 LLM으로 넘어가는 것 같음
결국 똑같은 문제들이 반복되는 것으로 보임
단지 비용 절감 방법이 달라졌을 뿐임
지름길을 선택할 이유는 분명히 있지만, 이를 통해 비용이 들 수 있다는 점을 깊이 인식하지 않을 때 진짜 문제 발생함
매니저, 직원, 외주 인력 등 출처와 상관 없이 결과는 비슷함
아직 vibe coding 플랫폼 구조 개선 서비스를 별도로 광고해 본 적은 없지만, 어쩌면 이제 시도해볼 때가 된 것 같기도 함
호주 소프트웨어 시장은 작아서 그런 실험의 결과가 잘 들리지 않음
- vibe 코딩과 외주 개발의 차이는 코드 생산량에 있다고 생각함
  한 번 vibe 코딩으로 간단한 헬퍼 스크립트를 만들어봤는데, 내가 직접 썼다면 지금 코드의 1/3 정도에 불과했을 것이고, 대부분의 엣지 케이스는 아예 다루지도 않았을 것임(쓸데없는 예외처리도 있었고, 진짜 도움되는 것도 있었음)
  내가 한 일은 코드 스캔하면서 실수로 홈디렉토리가 지워질 수 있어서 temp 파일 삭제 라인 하나를 제거하는 정도였음
  근데 나중에 더 깊은 데이터 작업을 하다 보니 temp 파일이 일부 사라져 있고, 삭제코드가 두 군데 더 있었음을 알아챘음
  사실 사람이 읽기엔 코드가 너무 많아서 모두 확인하는 게 비현실적임
  그래도 속도 면에서는 확실히 엄청난 효율임
  나는 앞으로 코드를 꼼꼼히 읽기보다 샌드박스에서 AI로 테스트 돌릴 계획임
- 특히 Claude Code와 같이 “플랜 모드”가 있는 도구에서는 큰 차이점이 있음
  나는 요즘 회사에서 Claude Code를 많이 사용하는데, 항상 플랜 모드로 대화 형식으로 “어떻게 구현할지” 먼저 물어보고, 몇 번 대화로 좋은 설계로 세부플랜을 다듬음
  그 다음에 AI가 어떤 코드를 생성할지(코드 diff와 함께) 정확하게 알려주고, 내가 최종 승인한 후에 실제 코드를 생성함
  이와 대조적으로 예전에 외주팀이 만든 코드를 리뷰해봤을 땐, 도저히 내용을 파악할 수 없는 엉망진창의 스파게티 코드였음
- SEO용으로라도 vibe-coding 관련 용어를 사이트에 적어두는 게 괜찮은 아이디어라 생각함
- 나도 비슷한 생각을 했음
  그런데 프로젝트가 vibe-coded라서 버그투성이 코드가 됐을 때, 내가 가서 버그를 고치고 구조를 정리해주면 끝인 건지?
  애초에 설정할 전문 지식이 없던 회사가, 유지보수를 어떻게 이어갈 수 있는지 궁금함
- 외주와 LLM 기반 개발 모두 결국 비슷한 역량이 필요하다고 봄
  즉, 요구사항 정리, 커뮤니케이션, 이해관계자 관리, 명세 정의, 테스트, 문서화처럼 엔지니어링 영역에서의 탄탄한 기본기가 계속 필요함
Karpathy의 "vibe coding"이라는 개념이 이런 식으로 유행한 게 좀 이상하게 느껴짐
아마 실제 개발 경험이 별로 없는 사람들 사이에서만 그런 것 아닐까 생각됨
내가 기억하기로 vibe coding이란, ‘그냥 AI와 대화하면서 코드 생성 결과는 확인도 하지 않으면서 흐름만 믿고 진행하는’ 일종의 플로우 상태로, 코드는 거의 돌아보지도 않는 접근임
진지하게 만드는 소프트웨어의 품질이 조금이라도 중요하다면 정말 끔찍한 방식임
트위터 밈이나 자기만족용 실험, 집에서 쓰는 작은 스크립트쯤에는 쓸 수 있어도, 제대로 된 제품을 개발할 땐 말도 안 된다고 생각함
이렇게 화제가 된 건 Karpathy처럼 유명한 사람의 멋진 네이밍 때문이지, 다른 사람이 얘기했다면 그냥 묻혔을 것임
AI 이전에도 주니어나 경험이 많지 않은 개발자들이 이미 이런 식으로 코딩해왔음
어디서 복붙해서 돌아가는 것만 확인하다가 엉뚱한 버그나 코어 덤프 나오면 소스코드 순서만 바꿔서 겨우 없애는 방식임
이런 스타일은 회사에서 최소한 경고를 듣거나, 성과 개선 플랜에 올려지거나, 더 심하면 퇴출당할 수도 있음
- 비전문가들이 소프트웨어 엔지니어와의 소통에서 제대로 된 결과를 얻지 못하는 경우가 많았음
  vibe coding의 등장은 우리가 그동안 어떤 소프트웨어를 전달해왔는지에 대한 반성이라고 봄
  실제로 내가 알고 있는 vibe coded 스타트업들의 소프트웨어 품질은 엉망이지만, 그들이 원하는 동작만 하면 품질은 지금 단계에선 중요하지 않음
  비즈니스에 소프트웨어 품질이 '실제 타격'을 주기 전까지는 굳이 개발자를 고용해서 자신의 아이디어를 변질시키는 리스크를 감수하려 하지 않을 것임
  결국 쓰레기같아도 자기들이 원하는 걸 당장 쓸 수 있는 게, 자신들이 원하지 않는 완벽한 소프트웨어보다 나은 선택지임
- 마음에 들든 말든 vibe coding은 앞으로 사라지지 않을 것임
  나도 개인적으로 이 개념에 별로 동의하지 않지만, 조직 내에서 동료들에게 ‘이거 vibe coded로 만들었어’라고 종종 말함
  우리에게는 ‘코드의 대부분을 AI로 자동 생성했다’ 정도의 의미임
  그렇지만 이렇게 만든 코드를 리뷰 없이 바로 프로덕션에 올릴 생각은 절대 없음
  그냥 '멋진 앱을 vibe coding으로 뚝딱 만들어봤어’ 정도로, 가볍게 실험용으로만 씀
- Karpathy가 vibe coding은 해볼 만한 “가능한 실험”이고 어디까지 갈 수 있는지 시험해보면 재미있다는 취지로 말한 것 같음
  회사에서 진짜로 vibe coding만으로 제품을 만드는 건 권장 의미가 아니었다고 봄
  사람들이 이 표현의 맥락을 너무 자기 멋대로 해석한 것임
  실제로 Karpathy가 본인이 말한 의미를 유튜브 영상에서 설명하기도 했음
  관련 기사
  Karpathy 유튜브: Software Is Changing (Again)
  사람들이 힘든 일을 이제 쉽게 할 수 있을 거라 믿고 싶어서 오해가 더 커졌다고 봄
- 나는 원래 tweet 자체도 농담이나 ‘YOLO 코딩’의 자유로움을 표현한 것일 뿐, 실제 업무용 프로세스로 권장한 게 아니라고 여전히 생각함
  그냥 그 당시 느낀 해방감을 유쾌하게 적었을 뿐임
- 지금 vibe coding은 사실상 모든 AI 코딩 보조를 폄하하거나 비꼬는 용어로 쓰이는 느낌임
  어떤 도구든 잘 쓸 수도, 못 쓸 수도 있는데 요즘은 “vibe coding이 얼마나 멍청한지”라는 밈이 온라인에서 표를 빠르게 얻음
  이제는 피곤할 정도임
"스타트업이 vibe coding 덕분에 수 주 단축해서 MVP를 만들고, 결국 나중에 비슷한 비용과 시간을 들여 클린업을 하더라도, 전통적 개발보다 여전히 빠르다"라는 주장이 기사 핵심임
정말 그런지 궁금함
내가 본 바로는 개발자가 직접 만들어도 AI 보조를 쓴다면 속도차이가 크지 않을 수 있음
특히 MVP나 프로토타입이 나중에 바로 프로덕션에 들어갈 걸 알고 있으면, 처음에 아키텍처를 제대로 잡는 게 장기적으로 낫다고 느낌
하지만 대부분 제품 쪽과 경영진은 이 시간을 낭비라고 봄
vibe coding의 진짜 장점은, 제품팀이 개발자에게 설명할 필요 없이 자기가 원하는 걸 직접 바로 만들어볼 수 있다는 점임
어쩌면 코드 자체를 만들기보단 사양과 프로토타입을 명확하게 만드는 vibe coding 기반 제품 도구가 시장성 있을지도 모름
이런 도구는 개발자에겐 더 나은 명세를 주고, 비즈니스 쪽에도 더 많은 기여와 주도권을 줄 수 있음
- 스타트업에서는 시장출시가 워낙 중요한 일이기 때문에, 전체적으로 시간과 비용이 더 든다 해도, 출시 속도가 더 빠르다는 이유로 기술적 부채를 감수하는 게 충분히 합리적 판단임
  그렇기 때문에 사람들이 기술 부채를 쌓기도 함
- 트위터도 처음엔 Ruby on Rails 기반의 웹앱으로 시작해서, 저스틴 비버가 트윗할 때마다 서버가 죽고 fail-whale이 뜨곤 했었음
  하지만 성장하면서 결국 전문가를 고용해서 아예 더 견고하고 확장성 좋은 구조로 제대로 다시 만듦
- MVP라기보다는 프로토타입 정도엔 쓸 수 있겠지만,
  프로토타입을 prod에 올리지 않는 조직적, 개인적 규율이 없으면, vibe coding은 피하는 게 맞다고 봄
  회사 경영진에게 “지금 당장 쓰고 있는 멋진 코드가 속은 엉망이라 싹 갈아야 한다”는 설득이 얼마나 어려운지 다들 알 것임
  이런 경우에는 오히려 노코드(no-code) 툴이 훨씬 안전함
- 대부분의 MVP나 프로토타입이 결국 곧 프로덕션에 올라가는 현실임
  여기서 누군가 "MVP 코드가 몸이 아플 정도로 더럽지 않으면 코드 품질에 너무 많은 시간 쓰고 있는 것"이라는 말을 한 게 기억남
  결국 임시방편 코드들이 회사 백본이 되는 셈임
  이렇게 구조 개선만 해주는 서비스를 "C-Suite 클린업 as a Service"라고 불러도 될 것 같지만, 그렇게 광고하면 아무도 고용 안 할 것 같음
글을 읽자마자 em-dash 없이도 Claude가 쓴 글이 명확하게 느껴졌음
확실히 OP가 본인 생각과 자료를 프롬프트로 줬겠지만, 특유의 구절과 문장 뉘앙스가 LLM에서 흔히 나오는 것과 똑같아서 억지로 읽는 느낌이 있었음
이런 스타일의 글이 앞으로 “LLM 문체”로 시대에 뒤떨어지게 되는 게 아닐까 생각됨
- 이제 vibe-writing 클린업 as a service가 대세가 될 것 같음
- 나는 오래전부터 em-dash를 많이 써왔는데, 이제는 억지로라도 그걸 줄여야 하는 시기가 온 것 같음
- Microsoft Word는 자동으로 하이픈을 em-dash로 바꿔줌
vibe coding이 DIY 배관공 작업과 비슷하다고 봄
직접 해보고 욕실에서 물이 터지면, 결국 응급 출동 배관공을 비싼 비용 주고 불러야 함
그 과정에서 다음엔 좀 더 배우게 됨
- 비슷하게 볼 수 있지만, 전문 배관공 역시 DIY를 보조하는 도구를 잘 쓰기도 함
  차이점은 전문가들은 언젠 어디까지 써야 하는지 잘 안다는 것임
- 오히려 더 심각하다고 느낌
  배관공 일은 뭘 하는지 눈으로 보면서 작업하지만, vibe 코드는 어느 날 갑자기 뭔가 작동이 안 되고 이유도 모름
- 유튜브에서 오히려 프로보다 더 꼼꼼하게 작업하는 DIY 배관공도 많이 볼 수 있음
- vibe coder가 이런 경험에서 진짜로 배울지 여부에 따라 다를 것 같음
  시간이 지나야 알 수 있을 듯함
- 이 비유가 진짜로 적절하다고 느낌
  압박받는 부동산중개인이 집을 팔기 위해 허겁지겁 배관공 일을 하듯, 스타트업 창업자도 빨리 뭔가 데모해서 투자자·고객 관심을 끌고 나중에 진짜 전문가를 불러 클린업함
  운이 좋으면 그 전에 대형사고를 막을 수도 있음
Janitor Engineer(청소부 엔지니어)라는 말이 이미 업계에 있었나 싶어서 놀람
추가로, "Why AI code fails at scale" 이후 기사 링크들이 다 깨졌던데, 얼마 안 된 글이라 더 의아함
참고로 누군가 기분 나쁘게 받아들이지 않길 바람
나도 vibe coding이 유행한 뒤로 “all-organic-code” 컨설턴트가 되어 AI가 만들어낸 코드 덩어리를 마구 풀고 정리하는 반은 농담 같은 은퇴 플랜을 계속 갖고 있음
- 사실 오래전부터 시스템 개보수(brownfield) 전문화가 늘 있었음
  진짜 희귀한 건 오히려 새 프로젝트(greenfield)임
vibe coding이 문서화와 아키텍처의 명확성을 빠르게 약화시키고 있음
회사는 코드 토큰 생성량과 프로토타입 속도만을 중요한 지표로 생각하고, 숨겨진 유지보수·클린업 비용을 무시함
이제 진정한 스킬은 생성이 아니라 클린업임
- 진짜 실력은 처음부터 잘 가이드해서 제대로 된 소프트웨어를 뽑아내는 것임
  Claude 코드처럼 “이게 최신 기술”이라고 생각하는 사람들이 있던데, 제대로 하려면 훨씬 더 많은 관여가 필요함
  사실 기존 엔지니어링과 크게 다르지 않음
  비용 최소화하고, 요구 충족시키는 게 핵심임
  유지보수성을 명시적으로 요구하지 않으면, 그대로 원래 의도한 결과(?)가 나옴
- 왜 문서화의 죽음인지 궁금함
  처음부터 문서만 작성하고, 이후 코드가 그 문서와 일치하는지 점검하면서 개발하는 방식도 있음
  아니면 코드에서 문서를 생성하게 하고, 그게 적절한지 직접 검토도 가능함
우리 회사는 수십 년째 고객사의 비상시스템(장애 등으로 심각한 금전 손실 발생 → 자체 해결 불가) 긴급 복구를 계속 해왔음
최근 몇 년간 이런 사례가 상당히 빠르게 증가하는 추세임
vibe code는 여러 면에서 레거시 코드와 유사함
코드에 자신이 없어 변경은 꺼려지고, 내부와 외부 품질 모두 낮음
하지만 차이점도 있음
나이 대비 코드량이 낮고, 일정 압박이 심하고, 기대치가 과장됨
가장 비용 효율적인 건 실행(runtime) 시점이 아니라 설계(design)나 컴파일 타임 전에 오류를 최대한 옮기는 것임
문제는 AI로 인해 모두가 런타임까지 너무 빠르게 달린다는 것임
- 참고로 “Vibe code is legacy code (val.town)”라는 글을 볼 만함
  관련 HN 게시글
- 레거시 코드라 해서 항상 나쁜 건 아님
  보통 복잡하거나 문서화가 부족하고, 오랜 기간 동안 크고 작은 운영상 수정 패치가 쌓인 경우가 많음
  많은 운영이슈(신규 요구사항 등)가 반영되어 실제 실서비스에서 잘 굴러가기도 함
  문제는 코드베이스에 익숙한 사람이 사라지고, 심지어 당시 사용한 언어나 툴을 아는 인력도 없어질 때임
- vibe 코딩이 강타입 언어에도 적용 가능한지 궁금함
  vibe로 만든 코드를 레거시 코드처럼 취급할 수 있다는 점에 동의함
  그런데 사람들은 vibe 코드에 대해서도 정말 변경을 꺼리는 경향이 있는지 궁금함
LLM 코드 생성이 앞으로 사라질 수도 있겠다는 생각이 듦
기사는 항상 LLM 코드가 만들어지고, 항상 클린업이 필요하다고 가정하지만, 어쩌면 LLM 비용+클린업 비용이 개발자 연봉보다 늘 비싸다면 결국 인간이 직접 작성하는 쪽으로 돌아가야 하지 않을까?
- LLM으로 코드 생성 후 체크해서 쓰는 건 vibe coding과는 다름
  vibe coding은 완성된 코드는 체크없이 그냥 사용하는 경우임
  두 방식 모두 결국 사라지지 않을 것으로 보임
- 오늘날 AI 기반 vibe coding은 점점 유행이 사라지고 있음
  왜냐하면 곧 더 뛰어난 AI가 등장할 것이기 때문임
- 하루종일 vibe coding만 해선 결국 비용이 감당 안 되는 구조가 될 수도 있음
  지나치게 지원/보조된 덕분에 모두가 열광했던 게 착각일 수도 있고, 나중엔 현실을 깨닫고 진통을 겪게 됨
  코딩 사례가 모두 들어가 예측완성·자동생성 보조도구가 되는 추세는 절대 사라지지 않을 것임
  마치 예전엔 구문 강조(syntax highlighting) 없이도 코딩했지만, 지금은 아무도 굳이 그렇게 하지 않듯이
  DFS 같은 걸 80번째 새로 타이핑한다고 해서 내 프로그래머로서 자존감이 더 올라가진 않음

답변달기