AI가 작동하는 제품까지 만들어주지는 않는다, 그건 여전히 당신의 일이다

• AI는 몇 분 만에 UI와 데이터베이스를 갖춘 프로토타입을 만들지만, 첫 작동 버전에서 프로덕션급 제품까지의 거리를 줄여주지는 못함
• 실제 제품에는 확장성, 오류 처리, 관측 가능성, 보안, 인증, 데이터 구조처럼 문법 작성보다 공학적 판단이 필요한 문제가 남아 있음
• 컴퓨터 과학의 가치는 코드 생산보다 시스템의 동작과 실패 원인을 이해하는 정신 모델에 있으며, 이를 알아야 비효율적인 쿼리나 경쟁 조건을 발견할 수 있음
• 요구사항을 기계적으로 코드로 옮기는 수요는 줄어들지만, 숙련된 엔지니어는 반복 작업을 AI에 맡기고 전문성이 필요한 문제에 집중해 훨씬 빠르게 일할 수 있음
• AI를 이해의 대체재로 사용하면 고장 난 시스템을 수정·확장·인수인계하기 어려우므로, 기초 지식을 먼저 익힌 뒤 AI 도구를 활용해야 함

---

프로토타입과 제품 사이의 간극

• 자연어로 아이디어를 설명하면 몇 분 안에 UI와 데이터베이스를 갖추고 의도한 기능을 수행하는 작동 가능한 프로토타입을 얻을 수 있음
• 하지만 노트북에서 실행되는 프로토타입은 실제 환경에서 여러 문제를 드러낼 수 있음
  • 부하를 견디지 못하고 오류 처리도 갖추지 못함
  • API 토큰이 유출될 수 있음
  • 데모용 데이터 모델이 두 번째 사용자를 추가하는 순간 무너질 수 있음
  • 인증이 검증되지 않은 가정에 의존하며 보안 여부도 불확실함
• 배포 단계에 이르면 ‘작동한다’와 ‘준비됐다’ 사이의 큰 프로덕션 격차가 드러남

어려운 일은 코드 작성 이후에 있었음

• 소프트웨어 엔지니어는 이전에도 무언가를 빠르게 실행할 수 있었고, 실제로 시간이 걸리는 부분은 그 이후였음
  • 규모가 커져도 버티는 시스템 설계
  • 사용자가 예상 밖의 경로로 진입할 때의 예외 처리
  • 장애 발생을 확인할 수 있는 관측 가능성 구축
  • 3년 뒤의 후회를 줄이는 데이터 아키텍처 결정
• AI는 최초 작동 버전까지 걸리는 시간을 크게 단축했지만, 그 버전에서 프로덕션급 시스템까지 가는 거리는 줄이지 못함
• 빠른 요청·응답·결과 확인 과정은 나머지 개발 과정도 압축됐다는 인상을 주지만, 소프트웨어의 어려운 문제는 애초에 문법 작성이 아니었음
• 무엇을 만들고 어떻게 구조화할지, 무엇을 미루고 언제 거절할지를 정하는 판단력이 프로토타입과 프로덕션 시스템을 구분함

컴퓨터 과학이 여전히 필요한 이유

• AI 생성 코드에 쉽게 접근할 수 있게 되면서 알고리듬, 자료구조, 운영체제, 이론을 수년간 공부해야 하는지 의문을 품는 신규 진입자가 늘어남
• 컴퓨터 과학 교육의 가치는 코드 작성 능력에만 있지 않으며, 시스템이 어떻게 동작하고 실패하며 왜 그런 결과가 생기는지 이해하는 정신 모델을 형성함
• 이 기반이 있어야 AI가 생성한 코드의 잠재적 실패를 식별할 수 있음
  • 5천만 행 테이블에서 전체 테이블 스캔을 일으키는 쿼리
  • 동시 부하에서 경쟁 조건을 만드는 캐시 전략
  • 현재 요구사항은 해결하지만 다음 문제를 훨씬 어렵게 만드는 아키텍처
• 기초 지식이 없으면 모델의 판단에 전적으로 의존하게 됨
  • 모델은 판단력이 아니라 패턴 매칭을 바탕으로 의도에 맞는다고 여기는 코드를 적극적으로 생성함
  • 생성된 코드는 올바르고 관례에 맞는 것처럼 보여도 프로덕션에서 실패할 수 있음
  • 문제를 알아볼 지식이 없다면 진단에 며칠이 걸릴 수 있음
• 이해와 결과물 사이의 거리가 줄어든 지금은 컴퓨터 과학을 배우기 좋은 시기이며, 분산 시스템을 제대로 이해한 학생은 10년 전보다 훨씬 짧은 시간에 이를 구축할 수 있음

자동화되는 업무와 확대되는 생산성

• 요구사항을 한 줄씩 구현으로 옮기는 기계적 코딩 업무의 수요는 실제로 감소하고 있으며, 해당 영역은 자동화되고 있음
• 생산성 분포의 하단은 압축되는 반면 상단의 한계는 확장됨
  • 현대적인 AI 도구를 사용하는 숙련된 엔지니어는 5년 전에는 상상하기 어려웠던 속도로 작업할 수 있음
  • 어려운 문제가 사라진 것이 아니라 시간과 주의를 소모하던 기계적 작업이 대부분 처리되기 때문임
  • 이렇게 확보한 시간은 실제 전문성이 필요한 작업에 쓸 수 있음
• 뒤처질 엔지니어는 AI 활용법을 모르는 사람이 아니라, AI를 이해의 대체재로 사용하는 사람임
  • 추론할 수 없는 시스템을 바이브 코딩으로 구축함
  • 장애를 수정하거나 성장한 시스템을 확장하지 못함
  • 유지보수 담당자에게 자신이 만든 것을 설명하지 못함

더 높은 추상화 수준에서 일하기

• 필요한 변화는 새 도구를 채택하는 데 그치지 않고, 기초에 뿌리를 둔 채 더 높은 추상화 수준에서 일하는 것임
• AI를 깊은 지식의 대체재가 아닌 증폭기로 사용하는 엔지니어는 동료보다 빠르게 앞서갈 수 있음
  • 모델에 무엇을 생성하도록 요청하는지 이해함
  • 주니어 엔지니어의 풀 리퀘스트를 검토하듯 생성 코드를 비판적으로 살핌
  • 기능 설명만 전달하지 않고 아키텍처 관점에서 대화함
  • 모델의 제안에 언제 반대해야 하는지 판단함
• 이는 새로운 역량으로 기존 기술을 교체하는 것이 아니라, 기존 기술을 새로운 환경에 적용해 훨씬 높은 레버리지를 얻는 방식임
• 프로토타입 이후에도 실제 공학적 판단은 필요하며, 이 역량이 신뢰할 수 있는 소프트웨어를 출시하는 개발자와 데모만 출시하는 개발자를 가름함
• 학습 순서는 기초 지식이 먼저이고 AI 도구가 다음이어야 함

[GN⁺]

Hacker News 의견들

• 사이드 프로젝트에서 몇 달간 LLM으로 만든 코드를 버리려 함. 설계 명세를 꼼꼼히 작성하고 기존 코드베이스에서 작업했는데도, 개별 변경은 논리적으로 보여도 전체적으로는 여러 부분이 미묘하게 어긋난 복잡한 덩어리가 됐음
  보고서나 논문도 각 절은 그럴듯하지만 전체 문서는 이상하게 느껴짐. 인간은 세부 작업에서 느리더라도 LLM에는 아직 불가능한 상위 수준 추론을 하는 듯함. 결함을 알려주면 “전적으로 맞다”고 하지만 스스로 검토할 때는 찾아내지 못함
  흔한 JS 프레임워크, Tailwind, ORM으로 단순 CRUD 앱을 만드는 일은 충분히 가능하겠지만, 예전에도 SaaS 템플릿을 살 수 있었고 잘 만든 수제 상용구가 바이브 코딩 결과보다 나을 가능성이 큼

  • 완전 자율형 프로그래밍보다 LLM 보조 프로그래밍을 점점 더 많이 사용함. Opus 같은 모델은 좋은 설계를 이해하기보다 목표를 달성할 때까지 변경하며, 사람이 정리해야 할 코드와 과도한 조사 작업을 남기는 경향이 있음
    다른 사람의 PR에서도 프롬프트의 문제는 표면적으로 해결하지만 장기 유지보수가 어려운 구현을 자주 봄. 그래서 구현 절차와 설계는 직접 결정하고, 작은 오픈소스 모델이나 Claude 4.5·4.6과 단계별로 작업함. API 탐색과 상용구 작성이 빨라져 수작업보다 몇 배 빠르면서도 지식이 퇴화하거나 코드베이스가 망가지지 않음
  • 복잡하고 과잉 설계된 해법에 갇혔다가 산책하거나 다른 일을 한 뒤 단순한 해법을 깨달은 적이 많음. LLM은 모든 것을 즉시 처리해 성찰하거나 막다른 길임을 알아차리고 다음 작업과의 충돌을 생각할 시간을 빼앗음
  • 내 사이드 프로젝트도 이제 코드를 완전히 이해하고 안전하게 직접 수정하기 어려워졌지만, 더는 그럴 필요가 없다고 봄. 거의 20년간 아름다운 코드를 작성했으니 이제는 생산성과 결과물에 집중하고 싶고, Codex가 스파게티 코드를 이해하는 한 개인 프로젝트나 소규모 독립 개발사에는 괜찮음
    AI는 기계어 위에 고급 언어가 놓인 것처럼 기술 스택 위에 추가된 새 계층이므로, 놓아줄 필요가 있음
  • 진짜 가치는 코드보다 그곳에 도달하며 얻는 배움에 있었음. 고생하는 과정에서 실제 요구사항과 기술적 난제를 반복적으로 발견하지만, AI는 그 과정을 건너뛰어 목표를 피상적으로 달성한 것처럼 보이게 함
    AI가 쓸모없다는 뜻은 아니며, 요구사항과 최종 검증을 더 깊이 고민하고 과정이 가치 있는 결과를 보장하리라는 신뢰를 줄여야 함
  • 신규 가족용 일정 관리 프로젝트에서 AI의 속도를 활용해 사용자 경험 문제를 다듬고 있음. 기능을 만들고 며칠간 직접 사용한 뒤 마음에 들지 않는 부분을 고치는 과정을 반복해 v1 기능 완성을 목표로 함
    색상이나 장황하고 불필요하게 화려한 비즈니스 로직은 마음에 들지 않지만, 지금 중요한 것은 부부가 실제로 유용하게 쓰는지이며 결과는 긍정적임. 이후 UI를 취향대로 다시 설계하고 백엔드 요구사항을 확정한 다음, 유지보수와 확장이 쉽도록 처음부터 재작성할 예정임
    Claude 계열은 프로토타이핑과 요구사항 발견에 뛰어나며, 이후 제대로 다시 만드는 과정을 수월하게 해줌

• 간단한 검증 기준은 지난 12·24·36개월 동안 훌륭한 신제품이나 기존 제품의 큰 개선을 실제로 봤는지임. 내가 써본 훌륭한 신제품은 선호하는 LLM뿐이고, 그 연구소들은 오히려 더 많은 사람을 채용하고 있음
  12개월 뒤에도 개선이 없다면 “2027년 2월에야 LLM이 충분히 좋아졌으니 아직 평가할 수 없다”는 주장이 반복될 것이라 봄

  • Claude Code 웹판과 VS Code판이 여전히 버그투성이인지도 좋은 기준임. 거의 모든 에이전트 반복 실행이 고장 나 강제 새로고침이 필요하고, 때로는 그것조차 해결하지 못함. Anthropic에는 사실상 무제한의 LLM 예산과 미공개 모델도 있음
  • LLM 만능론자는 아니며 통제된 방식으로 쓰지만, 최근의 자동 취약점 발견은 흥미로운 발전임. Chrome은 6월 한 달에 지난 2년보다 더 많은 버그를 해결했음
    https://news.ycombinator.com/item?id=49120097
    최신 Apple 보안 업데이트와 6월 Android 보안 공지도 엄청난 수의 취약점을 수정함. 상당수는 C/C++ 같은 안전하지 않은 언어에서 생겼지만, 명확히 정의되고 일탈 가능성이 적은 변환 작업에 LLM이 강하므로 Rust 같은 안전한 언어로 이식하는 데도 유용함
  • 프로젝트 출시 속도는 예전과 비슷하지만 AI 도구 덕분에 결과물이 훨씬 완성도 높고 기능도 풍부해짐. 과거에는 정상 경로만 동작하게 출시했지만, 이제는 해지·계정 내보내기·개인정보 처리방침과 모바일·웹 앱 전체까지 큰 노력 없이 제공할 수 있음
  • 개발 커뮤니티 몇 곳만 봐도 이 도구들이 등장한 뒤 신제품 수가 세 배로 늘었음. 모든 출시 소프트웨어와 AI 사용 여부를 추적하는 목록도 없는데, 자신이 직접 개선을 보지 못했다는 이유로 존재하지 않는다고 보는 것은 이상함
    의료 분야에서도 제품 수가 급증했으며 품질은 제각각이지만 아무 결과도 없었다는 말은 객관적으로 틀림
  • 실용화된 것은 작년 말부터라고 보지만, 최근 취미용 소프트웨어가 눈에 띄게 급증한 것은 맞음. 얼마나 잘 유지보수될지는 별개의 문제임

• 제품이 동작하면 “코드베이스가 프로덕션 준비를 마쳤는지, 100만 달러에 판매할 기준을 충족하는지 검토하라”고 요청해 보길 권함. 그러면 AI가 앞서 주장한 수준에 전혀 도달하지 못했음을 드러내며, 얼마나 속고 있었는지 알려주는 ‘백만 달러 프롬프트’가 됨

  • Hacker News 글 두 개를 봤는데 모두 상위 댓글이 “AI는 코드를 못 쓰며 곧 무너질 것”이라고 했음. 수년 동안 매일 이 도구를 성공적으로 쓰는 사람들에게 계속 신기루라고 주장하는 모습은 이해하기 어려움
  • 형편없는 코드베이스도 100만 달러 이상에 팔린 적이 많음
  • 그렇다면 Oracle Database는 몇백만 달러에 팔려야 하는지 궁금함
    https://news.ycombinator.com/item?id=18442941
  • 문제를 고치라고 한 뒤 같은 질문을 다시 던지면, 수정 후에도 비슷한 비판을 또 내놓을 것임
  • OpenClaw가 얼마에 팔렸는지를 생각해 볼 만함

• LLM을 두 방식으로 사용해 봄. 첫째, Opus 4.6과 Node 백엔드로 인원 순번에 따라 Slack 채널에 알림을 보내는 플러그인과 Google Meet 참가자별 발언 타이머를 바이브 코딩했음. 내부 도구라 구현을 잘 이해하지 못해도 GCP에서 문제없이 동작하며, 1인당 월 20달러였던 Slack 도구 비용을 전체 월 0.07달러의 인프라 비용으로 줄였음
  단번에 만든 것은 아니고 상세 계획, 단계별 실행, 테스트 추가를 거쳤음. 둘째, 장기 제품에서는 팀이 아키텍처를 설계·검토하고 상세 JIRA 티켓을 만든 뒤 Opus에 전달함. 모델이 구현 계획을 만들고 엔지니어가 승인한 뒤에만 코딩하게 함
  빠른 MVP나 개념 증명에는 첫 방식이 좋지만 장기 제품이라면 MVP를 버리고 확장성과 깔끔한 아키텍처를 처음부터 계획한 뒤 LLM을 코딩 작업자로 써야 함. LLM은 사람이 오래 유지할 수 있는 아키텍처와 깔끔한 코드 판단에는 아직 약함

  • 일회성 저위험 앱의 바이브 코딩에는 훌륭했지만, 거대한 레거시 코드베이스에서 같은 방식으로 기능을 구현하면 완전히 악몽이 됐음

• 판별 기준은 AI 생성물을 소비하는 일이 즐거운지임. 글, 영상, 음성, 식당 메뉴, 의류 사진, 문서, 공항 관제, 광고 등 어느 것도 즐겁지 않으며, LLM은 개선된 검색 엔진이나 질의응답 도구로는 가치가 있다고 봄

  • 많은 소비자는 최소 기준만 충족해 작동하면 낮은 품질을 개의치 않음. 가전제품, 소프트웨어, 패스트푸드에서도 같은 현상이 있었음
    AI가 결국 그 기준을 충족하면 생성물이 수제품을 지배할 것이며, 사람이 직접 만든 제품과 서비스는 오늘날 수공예품처럼 훨씬 비싼 가격에만 살 수 있게 될 가능성이 큼
  • 좋은 AI 결과물은 이미 알아차리지 못한 채 늘 즐기고 있을 수 있음. 누구도 형편없는 단발성 생성물은 좋아하지 않음
  • 사람들이 매달 합계 수십억 달러를 쓰는 것을 보면 실제로 좋아한다고 볼 수 있음
  • AI 생성물은 원재료로만 취급하며, 대중 고객에게 바로 제공할 완제품으로 보지 않음
  • AI라는 사실보다 낮은 품질이 문제임. AI임이 명백해도 잘 만든 결과물은 좋아함

• 다른 회사의 바이브 코딩 결과를 정리하고 현실적인 시스템으로 만드는 일이 많이 생길 것임. 개별 프로젝트의 가치는 낮아져도 수는 늘고, 도움 없이는 제대로 작동하지 않을 가능성이 큼
  소프트웨어 엔지니어가 없는 회사가 Claude Code로 본업 밖의 일을 하면서도, 직원이 코드를 만지작거리기보다 채용한 목적의 일을 하길 바란다고 했음
  맞춤 제작이 쉬워지면서 천편일률적 제품은 판매가 어려워지지만, 실제 맞춤 결과물을 전달하는 데는 여전히 많은 일이 필요함. 직접 구축한 경력과 해당 업무 영역 지식을 함께 가진 사람에게 두 배로 유리함
  사람들은 대개 자신에게 무엇이 필요한지 모르므로 요구를 찾아내고 제공하는 컨설팅의 본질은 그대로이며, 소프트웨어가 저렴해진 만큼 더 많은 고객을 맡을 수 있음

  • 코드를 만지지 말아야 한다는 그 직원이 누구인지 불분명함

• 글의 기본 논리는 결함이 있음. 프로토타입을 만든 뒤 해야 할 일이 남았다면 그 일도 계속하면 됨. AI 사용을 네 줄짜리 프롬프트로 한 번에 생성하는 일과 동일시하는 듯하며, 근본적 통찰보다는 무비판적인 자기합리화에 가까워 보임

  • 테스트 범위가 부족하고 요구사항이 불확실하며 배포 방식이 비표준인 코드베이스에서 LLM을 사용한 내 체감과는 정확히 일치함. 정상 경로를 벗어나면 프로덕션을 망가뜨리는 나쁜 가정을 하기 시작하며, 가장 똑똑한 모델도 이런 환경에 적합한 아키텍처에는 미치지 못함

• 공학 배경이 없어도 직관적으로 맞다고 느꼈으며, 카드 게임을 만들 때 여러 번 겪었음. 처음에는 잘 만들다가 표준 52장 카드 라이브러리를 가져온 탓에 특수 이벤트 카드를 추가할 수 없었고, 카드 객체 기반의 유연한 데이터 모델이 필요했음
  처음부터 알려주면 해결할 수 있겠지만, 소프트웨어를 일회용으로 여기고 숙련 엔지니어처럼 구현을 깊이 고민하지 않으면 그런 요구를 떠올리지 못함. AI 생성 글과 코드의 문제는 제작 과정에 내재했던 사고를 빼앗는다는 데 있음
  다만 모든 소프트웨어가 확장성, 속도, 유지보수성을 갖출 필요는 없음. 수백만 명이 쓸 인프라와 앱에는 필요하지만 가족용 식단 계획 앱은 Google 직원 수만 명의 알레르기 설정까지 지원할 필요가 없음
  AI는 소프트웨어를 집밥 같은 도구로 만들 수 있게 함. 집밥은 완벽한 요리일 필요 없이 가족을 먹이고 누군가에게 수고라는 선물이 되면 충분함

• 제품이 단 한 번의 요청으로 만들어지는 것이었다면 오래전부터 외주 회사가 제품 회사를 지배했을 것임. 제품 개발의 상당 부분은 초기 프로토타입·MVP 이후 반복 작업에서 이뤄짐
  기술뿐 아니라 문제를 오래 파고들어 고통의 근본 원인을 이해하고 사용자 경험과 기술 양쪽에서 해결해야 함. 예전에도 외주 회사에 제품을 “프롬프트”할 수 있었지만, 고객과 수년간 대화하며 전문성을 쌓은 제품 회사에 비용을 지불한 이유가 여기에 있음

• 글의 제목은 논의를 더 잘 요약하는 The Prototype Isn't the Product가 적절함. AI로 “대체로 동작”하면 충분한 일회용 프로토타입과 개인용 앱은 놀랄 만큼 빠르게 만들 수 있지만, 품질과 유지보수가 중요한 소프트웨어 공학은 여전히 어렵고 느림
  화려한 바이브 코딩 시연은 많지만, 대규모 레거시 코드베이스나 일상적인 비화려한 전문 업무에서 AI가 얼마나 유용했는지에 대한 논의는 적음
  바이브 코딩한 3D 게임 프로토타입이 멈췄다고 일요일 오전 6시에 전화받지는 않지만, 방금 갱신한 24시간 운영 시스템에 버그가 생기면 반드시 전화받게 됨