기술 스택은 처음에 고를 일이 아니다
『바이브 코딩 에센셜』의 예전 판에는 첫 실습부터 이런 조건이 들어 있었습니다. 기술 스택은 HTML, CSS, JavaScript로 하고 모든 코드는 하나의 HTML 파일에 넣으라는 조건입니다. 그때는 이렇게 정해 주지 않으면 AI가 엉뚱한 쪽으로 가는 일이 많았습니다. 지금 판에서는 이 줄을 지웠습니다. 누구에게, 무엇을, 어떤 느낌으로 보여 주고 싶은지만 말하면 기술은 AI가 고릅니다.
기술 스택은 무엇을 어떤 재료로 만들지 정한 목록입니다. 오랫동안 개발 입문서는 이 선택을 앞쪽에 두었습니다. 저는 이것을 처음에 할 일이 아니라고 봅니다. AI가 저보다 잘 고르고, 사람이 그 이름을 알 필요도 없는 시대로 들어섰습니다.
고르지 않는 것으로 끝나지 않습니다. 고르면 해로울 때가 있습니다. 부트캠프에서 여러 번 본 장면이 있습니다. 개발을 잘 모르는 분이 명세서의 기술 칸을 비워 두기가 불안해서 검색을 하고, 검색에서 나온 단어를 적습니다. 그 단어가 자기 프로젝트에 맞는지는 모릅니다. AI는 적힌 대로 따릅니다. 간단한 소개 페이지 하나에 파일이 수십 개 생기고, 그 뒤로 본인이 손을 대지 못합니다. 모르는 것은 적지 않는 편이 결과가 좋습니다.
1. 말할 것은 기술 이름보다 사정입니다
한칸에는 문서가 따로 있습니다. 기획 문서에는 친구끼리 싸우지 않는다는 말이 있고, 구조 문서에는 층마다 쓰는 기술과 그 이유가 표로 적혀 있습니다. 화면에 블록을 그리는 기술, 서버, 데이터베이스가 차례로 나오고, 동시 접속을 몇 명까지 받을지도 정해져 있습니다. 코드를 모르는 분이 이 표를 읽을 일은 없습니다.
표에서 서버 칸의 이유는 눈여겨볼 만합니다. 기존에 쓰던 기술과 배포 절차를 그대로 쓴다고 적혀 있습니다. 이미 돌아가는 서버가 있고 저희가 그쪽을 잘 안다는 사정이 기술을 정했습니다. 사람에게서 나가야 할 말은 이런 쪽입니다. 회사 서버에 올릴 것이다, 아이들이 휴대폰으로도 들어온다, 친구들이 같이 논다. 그 말을 듣고 재료를 고르는 일은 AI가 합니다.
고른 것이 틀려도 큰일이 아닙니다. 노트북은 서버에서 돌리기로 했던 실행을 10월 29일에 회원의 브라우저에서 돌리는 쪽으로 바꿨습니다. 구현의 값이 낮아지면서 기술 선택은 나중에 바꿀 수 있는 결정이 됐습니다. 처음에 잘 고르려고 쓰는 시간이 그만큼 아깝습니다.
2. 제가 지운 것들
저는 제가 가르치던 것을 지운 사람입니다. 교재 옛 판에는 URL 설계가 백엔드 개발의 첫 단계이자 핵심이라고 적혀 있었습니다. 주소에는 동사 대신 명사를 쓰고, 이름은 복수형으로 짓고, 특정 언어의 주소 문법까지 설명했습니다. 지난달에 그 절의 제목을 'URL 설계는 AI에게 맡기기'로 바꿨습니다. 원칙이 이미 세상에 공개되어 있고, AI는 그 원칙을 사람보다 잘 지킵니다.
데이터베이스 절은 일대다, 다대다 관계를 설명하고 표와 표의 관계를 도표로 그린 다음 칸 종류를 고르는 법까지 갔습니다. 이 절의 제목은 이제 'DB 설계는 무엇을 저장할지만 말하기'입니다. 동네 독서 모임 게시판을 만든다면 회원은 이름과 이메일로 가입하고, 책 제목과 별점과 감상을 남기고, 감상은 회원만 보고, 쓴 사람만 고칠 수 있다고 말하면 됩니다. 표 이름도 칸 종류도 말하지 않습니다.
여기서 지워지지 않은 것을 보면 경계가 보입니다. 표를 어떻게 나눌지는 지웠지만 무엇을 저장할지, 누가 보고 고칠지, 얼마나 남길지는 남겼습니다. 주민등록번호를 받을 것인가, 탈퇴한 사람의 기록을 언제 지울 것인가는 설계 기법이 아니고 내 서비스의 약속입니다.
저희 부트캠프에서도 예전처럼 URL 설계와 DB 설계를 강의하지 않습니다. 이유는 둘입니다. AI가 설계하는 것이 충분히 믿을 만합니다. 그리고 비전공자가 잘못 설계하는 위험이 너무 큽니다. 어설프게 정해 준 설계는 AI가 그대로 따르고, 그 위에 쌓인 것은 나중에 고치기 어렵습니다. 차라리 AI가 설계하게 두는 쪽이 훨씬 멋진 결과물이 나옵니다. 이것은 개발자도 마찬가지입니다.
옛 판에서 적어도 한 번은 코드를 따라 타이핑해 보라고 권하던 자리에는 적어도 한 번은 처음부터 배포까지 끝까지 가 보라는 말을 넣었습니다.
프롬프트 요령은 가장 빨리 낡았습니다. 2026년 5월에 쓴 실습은 무성의한 한 줄과 역할·맥락·작업·형식을 갖춘 프롬프트를 비교했습니다. 다섯 달 뒤에 고친 판은 한 줄로 시키기와 맥락을 담아 한 문단으로 시키기를 비교합니다. 당신은 10년 경력의 전문가라고 역할을 주는 문장은 지금 모델에게 거의 차이를 만들지 않습니다. 업계는 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링이라는 말을 차례로 만들었고 저희도 그 이름으로 강의를 하고 교재를 냈습니다. 지난달 그 교재를 고치며 짚어 보니 네 가지 모두 손으로 하던 부분을 모델과 제품이 가져가 있었습니다. 지금 익힌 요령은 다음 모델이 나오는 날 값이 떨어집니다.
단어까지 버리라는 말은 아닙니다. 프론트엔드, 백엔드, 서버 같은 말은 AI의 보고를 읽으려면 뜻을 알아야 합니다. 설계하는 법을 배우는 것과 말을 알아듣는 것은 다른 일입니다.
마지막 수정