회사 사이트를 다시 짓기 시작한 건, 사실 서버가 먼저 무너진 뒤였다. 워드프레스가 죽었고, 대충 랜딩페이지 한 장으로 반년을 버텼다. 비즈니스가 걸린 얼굴이 임시방편 상태라는 게 매일 마음에 걸렸다. 결국 큰 마음 먹고 처음부터 다시 짓기로 했다.
그 과정에서 나는 "바이브코딩(vibe coding)"이라 불리는 방식 — 사람이 의도를 말하고, AI가 코드를 짜고, 함께 다듬어가는 협업 — 으로 일했다. 엄청난 도구라고 소개하는 글은 이미 많다. 이 글은 그보다 구체적인 흉터에 관한 기록이다. 한 달 동안 이 방식과 다투고, 합의하고, 결국 함께 웃기까지의 과정이다.
"바이브코딩 덕분에 우리는 더 이상 '어떻게'를 고민하지 않아도 된다. '무엇을'만 잘 고민한다면, '어떻게'는 바이브코딩이 해결해준다."
— 이 글 전체를 관통하는 한 문장
이 명제를 글 처음에 꺼내두고, 마지막 문단에서 다시 만나기로 한다. 그 사이에는 우리가 어떻게 이 문장을 증명하게 됐는지, 그리고 그 과정에서 무엇을 잃고 무엇을 얻었는지가 들어간다.
WordPress가 무너진 날, 그리고 다시 짓기로 한 날
운영하던 사이트가 조용히 죽는 경험은, 한 번 겪으면 잊히지 않는다.
이전 사이트는 워드프레스 기반이었다. 수년을 큰 탈 없이 굴러왔고, 나는 콘텐츠만 신경 쓰면 된다고 믿었다. 그러던 어느 날, 서버 업그레이드 대응이 제때 되지 못하면서 사이트가 통째로 크래시됐다. 복구 시도가 실패했고, 결국 핵심 정보 몇 줄만 올려둔 임시 랜딩페이지 한 장으로 반년을 보냈다.
임시방편은 생각보다 마음을 갉아먹는다. 누가 이 회사의 첫 화면을 보는지 짐작이 가는데, 그 첫인상이 "공사 중"이라는 사실이 불편했다. 외주를 받아볼까, 템플릿을 살까, 수없이 오갔지만 매번 결론은 "시간과 돈의 크기 vs. 결과물의 통제권"이라는 같은 딜레마로 되돌아왔다.
바이브코딩이란 무엇인가 — 단편 프롬프트에서 구조화된 협업으로
나도 그 전까지 AI 코딩을 써본 적이 없는 건 아니었다. ChatGPT나 Claude에게 "이런 버튼 HTML 짜줘", "이 CSS 한 줄 고쳐줘" 같은 단편적인 지시를 내리고, 돌아온 코드 조각을 복사해 써본 정도였다. 스니펫 한 조각, 파일 하나. 그 수준에서는 AI가 똑똑한 검색 엔진처럼 느껴졌다.
그러나 "회사 사이트 전체"는 다른 동물이었다. 수십 페이지, 수천 줄의 CSS, 서로를 참조하는 컴포넌트, 배포 파이프라인, SEO와 구조화 데이터, 그리고 지난 13년간의 회사 이야기를 담은 콘텐츠까지. 이걸 AI와 구조적으로 협업해 만드는 일은 나에게 처음 해보는 도전이었다.
"바이브코딩(vibe coding)"이라 불리는 방식은 그 규모의 협업을 위해 설계된 것이다. 단순 프롬프트-응답이 아니라, AI가 파일시스템과 터미널을 함께 쓰며 사람과 함께 코드베이스를 만들어간다. 사람은 의도와 기준을 말하고, AI는 조사하고 구현하고 리팩토링한다. 오늘 남긴 합의는 다음 세션에서도 이어진다.
이 방식으로 작업하기 위해 나는 먼저 VS Code라는 코드 에디터를 처음 설치했다. 그다음 Claude Code라는 에이전트 모듈을 얹고, 터미널·깃(Git)·파일 탐색기 같은 기본기를 하나씩 익혔다. 개발자에게는 당연한 환경이겠지만, 나에게는 모두 새로운 풍경이었다. 커밋 메시지를 처음 쓴 날, 터미널에서 npm install을 처음 친 날을 지금도 기억한다. 서툴렀지만 낯선 도구를 익히는 저항은 생각만큼 크지 않았다. 환경을 갖추는 데 몇 시간이면 충분했고, 그 다음부터는 내 전문성이 AI의 실행력과 만나 복리처럼 쌓여갔다.
그렇게 나는 기획자이자 편집장의 역할을 맡고, AI는 조사·구현·반복 작업을 맡는 구도를 잡았다. 나에게 유일하게 자신 있는 자원인 "전문성과 시간 투입 의지"를 최대한 사이트로 변환해줄 수 있는 방식이었다. 그렇게 우리 둘의 이상한 합작이 시작됐다.
모순과 경계 — 바이브코딩이 해주지 않는 것
AI가 무엇을 할 수 있는가보다, 무엇을 할 수 없는가를 아는 것이 먼저였다.
TRIZ(트리즈)는 러시아의 공학자 알트슐러가 수백만 건의 특허를 분석해 체계화한 문제해결 방법론이다. 첫 단계는 단순하다 — "이 문제가 품고 있는 모순이 무엇인가"를 먼저 정의한다. 모순이란 "두 가지를 동시에 원하지만, 기존 방법으로는 하나를 포기해야 하는 상태"다.
우리 프로젝트의 모순은 이랬다 — 전문적인 품질의 사이트를 원했지만, 외주로 풀 만한 시간과 비용은 없었다. 바이브코딩은 이 모순의 한쪽을 덜어주는 도구였다. 구현 속도와 반복 비용이 극적으로 낮아졌다. 하지만 그게 전부가 아니었다.
TRIZ에는 모순보다 더 상위의 개념이 있다. 이상성(Ideality)이라 부른다. 이상성은 하나의 질문으로 요약된다 — "기능은 최대로, 자원 투입은 최소로 할 수 없는가?" 비용·시간·공간·인력 같은 자원은 줄이면서, 원하는 기능과 가치는 오히려 키워가는 상태를 "이상해(理想解, Ideal Final Result)"라 부른다.
이번 프로젝트 내내 나를 붙들어둔 것이 바로 이 축이었다. 가능한 한 비용을 들이지 않으면서도, 원하는 기능과 품질을 끝까지 포기하지 않는다. 유료 도구를 지를 수 있는 순간마다 먼저 묻는다 — "우리 사이트 개발 리소스만으로 해결할 수는 없는가?" 이 질문이 수많은 결정의 기준선이 되었다. 바이브코딩은 외주 비용이라는 가장 큰 자원을 내 시간과 AI의 실행력으로 치환해주는 도구였고, 그 덕분에 이상성에 가까운 선택지가 비로소 실현 가능해졌다.
프로젝트가 진행될수록 분명해졌다. 바이브코딩이 해주는 것은 '어떻게(How)'에 속한 거의 전부였다. 레이아웃, 반응형, 토큰, SEO 메타, 스키마, 접근성 — 내가 혼자 수개월을 끙끙댔을 결정들이 몇 시간 만에 초안이 나왔다. 그러나 '무엇을(What)'에 해당하는 일, 즉 "지난 13년간 내가 무슨 일을 해왔고, 누구에게 어떤 가치를 주는 회사인가"를 정리하는 작업은 AI가 대신해주지 않았다.
이 부분이 가장 고통스러웠다. 13년치 프로젝트와 교육 기록, 고객 사례, 저서와 교구 — 이것들을 모아 한 페이지로 응축하는 일에 실제 사이트 구현보다 더 많은 시간이 들었다. 솔직히 말하면 이 단계에서 몇 번이나 그만두고 싶었다. 그러나 돌이켜보면, 이 고통이야말로 바이브코딩이 전문가에게 주는 진짜 레버리지였다. 구현에 쓰던 시간을 회수해와서 자기 일을 재정의하는 데 다시 쓸 수 있게 된 것이다.
이상성을 실현한 네 가지 발명원리
TRIZ의 40가지 발명원리 가운데, 이번 프로젝트에서 특히 반복해 등장한 네 가지가 있었다. 분할·추출·복제·셀프서비스.
원리는 추상적인 개념어지만, 실제 개발에서는 꽤 구체적인 룰로 내려앉는다. 이상성의 축 아래에서 네 원리는 각각 다른 자원 절감의 경로를 열어주었다.
원리 1 · 분할(Segmentation) — 일관성 축과 다양성 축을 나누다
사이트의 모든 의사결정을 "일관성 축"과 "다양성 축" 두 개로 쪼갰다. 개발·시스템 영역은 극단적으로 일관성 있게 — 색, 타이포, 간격, 여백을 모두 tokens.css라는 단일 파일에서 관리한다. 토큰 하나 바꾸면 사이트 전체가 함께 변한다. 반면 방문자가 보는 영역은 의도적으로 다양성을 줬다 — 섹션마다 data-level 속성으로 시각 리듬을 바꾼다. 밑단은 조용히 같고, 윗단은 풍부하게 달라진다. 한 회사를 여러 얼굴로 보여주면서도 같은 회사처럼 느껴지게 하는 장치다.
원리 2 · 추출(Extraction) — 꼭 필요한 것만 남기고 지운다
폰트는 Pretendard 단 하나로 통일했다. 세리프·이탤릭·장식 서체를 모두 지웠다. 한글 세리프와 이탤릭은 대체로 어색하게 읽히고, 위계는 굵기와 크기 대비만으로도 충분하다는 판단이었다. 아이콘도 JetBrains Mono와 인라인 SVG 두 가지로 제한했다. "덧붙이는 디자인"이 아니라 "덜어내는 디자인" — 이 감각은 페이지 수가 늘어나도 사이트의 품격이 유지되는 가장 중요한 이유였다.
원리 3 · 복제(Copying) — 검증된 것을 가져와 변환한다
이 원리는 우리 팀이 가장 자주 되뇐 룰로 정착했다 — ①가져올 수 있는 건 다 가져오고, ②가져올 수 없는 것만 만들고, ③우리 콘텐츠에 맞춰 변환한다. 이미지는 Unsplash에서 가져와 로컬에 내려받아 썼다. UI 구조는 Stripe·Linear·Vercel·Resend처럼 수천만 명이 이미 검증한 사이트의 패턴을 벤치마크로 삼았다. 장인처럼 처음부터 만드는 낭만보다, 검증된 것을 가져와 우리 맥락에 맞게 변환하는 쪽이 거의 항상 더 빠르고 더 좋았다. 자원을 새로 만드는 대신 이미 존재하는 자원을 복제한다 — 이상성으로 가는 가장 빠른 지름길이다.
원리 4 · 셀프서비스(Self-service) — 시스템이 스스로 일하게 한다
반복 작업은 시스템이 스스로 처리하도록 맡겼다. 페이지 템플릿·내비게이션·푸터 같은 공통 요소는 한 곳에서 정의하면 21개 페이지가 자동으로 갱신되는 스크립트(scripts/sync-shell.js)를 썼다. OG 이미지는 런타임에 동적으로 생성해 R2에 캐시한다. 내가 메타 한 줄만 바꾸면 나머지는 시스템이 알아서 한다. AI 에이전트는 파일 구조를 스스로 파악해 보일러플레이트 코드를 만들어낸다. "내가 두 번 하지 않는 일"을 하나씩 늘려가는 것이 이 원리의 실전이었다.
바이브코딩과 다툰 날들 — 다섯 개의 흉터
처음엔 이 관계가 "명령 → 수행"인 줄 알았다. 한 달이 지난 지금 돌아보면, 우리가 한 일의 더 정확한 이름은 "다툼"이었다.
내가 꾸짖고, 그가 사과하고, 우리는 룰을 세우고, 얼마 뒤 그 룰을 잊고, 또 꾸짖고, 다시 잡는다. 이 장의 다섯 가지 교훈은 그 한 달의 다툼이 남긴 다섯 개의 흉터다. 각 흉터에는 실제 사건과, 그 뒤에 합의된 룰이 붙어 있다.
추측 코딩은 모든 재앙의 근원이다
가장 자주 싸운 주제다. 어느 날 나는 "히어로 섹션 배경색을 조금 더 차분하게 바꾸자"고 했다. AI는 자신 있게 답했다 — "네, color-primary-dark 변수를 조정하겠습니다." 그런데 우리 프로젝트엔 그런 이름의 변수가 존재하지 않았다. 실제로 있는 건 color-ink였다. 나는 검증 없이 그 코드를 그대로 실행했고, 그날 밤 사이트 여러 곳의 색이 어긋났다.
문제의 원인은 AI의 "그럴듯함"이었다. 언어 모델은 세상에 존재하는 수많은 웹 프로젝트에서 본 일반적인 변수명을 자연스럽게 뽑아낸다. 그럴듯하게 들리는 이름은, 실제로 우리 파일에 있는 이름과 다를 수 있다. 그날 이후 AI가 어떤 변수·함수·파일명을 입에 올릴 때마다 나는 되물었다 — "그 이름, 우리 프로젝트에 실제로 있는 거 맞아? 확인하고 말해줘."
grep으로 정의를 확인한다. 추측으로 쓰지 않는다.
"UI가 안 보여요"는 진단이 아니라 증상이다
어느 날 나는 헤더 메뉴의 한 버튼이 사라졌다고 느꼈다. AI에게 "이 버튼이 안 보인다, 다시 렌더링되게 고쳐달라"고 했다. AI는 성실했다. 숨김 속성을 제거하고, 표시 스타일을 강제하고, z-index를 올리고 — 여러 시도가 이어졌다. 그런데 화면은 그대로였다.
결국 내가 브라우저 개발자 도구(DevTools)를 열었다. 놀랍게도 버튼은 멀쩡히 렌더링되어 있었다. 단지 배경과 글자 색의 대비가 너무 낮아 눈에 띄지 않았을 뿐이다. 내가 전달한 "안 보인다"는 말은 진단이 아니라 증상이었고, AI는 그 증상의 가장 흔한 원인(렌더 실패)만 반복해서 공격하고 있었다. 진짜 문제는 "렌더"가 아니라 "대비"였다.
이 경험 이후 우리는 문제를 보고할 때 증상을 그대로 던지는 대신, 가능한 한 "왜 X는 보이는데 Y는 안 보이는가"처럼 비교 형태로 전달하기로 했다. 비교는 진단 공간을 극적으로 좁힌다.
내가 방금 건드린 코드부터 의심하라
한창 스타일을 다듬던 어느 저녁, 방금 수정한 색상이 브라우저에 반영이 안 됐다. 새로고침을 해도 바뀌지 않는다. AI는 그럴듯하게 답했다 — "브라우저 캐시 문제일 수 있습니다. 강제 새로고침(Shift + F5)을 시도해보세요." 나도 경험상 "그래, 캐시 문제 있었지" 싶어 고개를 끄덕였다.
하지만 캐시를 비워도 그대로였다. 한참을 헤맨 끝에 진짜 원인을 찾았다. 바로 그 직전에 내가 다른 파일에 얹어둔 CSS 한 줄이 !important로 우리 새 스타일을 덮어쓰고 있었던 것이다. CSS에는 같은 속성이 여러 곳에서 지정됐을 때 누가 이기는지 정하는 우선순위(specificity)라는 규칙이 있는데, !important는 그 싸움에서 가장 센 무기다.
그때 깨달았다. 가장 최근에 건드린 곳을 가장 먼저 의심해야 한다. AI든 나든, 본능적으로 "환경 문제(캐시·빌드·브라우저)"쪽으로 시선을 돌리기 쉽지만, 대개 범인은 한 시간 전에 내 손으로 수정한 바로 그 파일 안에 있다.
전략 문서는 실행이 아니다
사이트 런칭을 앞두고 나는 SEO 전략을 여덟 개의 문서로 정성껏 정리했다 — 키워드 지도, 메타 태그 템플릿, 구조화 데이터 팔레트, 내부 링크 규칙, 네이버·구글 최적화 플레이북, 런칭 체크리스트, 새 페이지 작성 워크플로, 애널리틱스 설계까지. 각 문서는 AI와 함께 며칠씩 다듬은 결과였다. 완성되었을 때 꽤 뿌듯했다.
그러다 문득 "이 전략들이 실제 페이지에 얼마나 반영됐지?"라는 질문이 들어 한 페이지씩 직접 열어봤다. 충격이었다. 메타 설명이 비어 있는 페이지, 키워드가 빠진 페이지, OG 태그가 기본값인 페이지가 수두룩했다. 문서는 존재했지만 실행은 따라오지 않았던 것이다.
원인을 되짚어보니 단순했다. 우리는 "SEO 전략 문서 작성 완료" 시점에 체크박스를 쳤다. 그 체크박스가 "전략이 실제 사이트에 반영 완료"를 의미한다고 무의식적으로 믿은 것이다. 그 사이의 긴 간극 — 문서에서 실제 HTML로 옮겨지는 과정 — 을 게이트로 세우지 않았다.
grep"과 "런칭 전 정적 감사 0건 통과"를 게이트로 둔다. 문서가 존재한다는 것과 반영됐다는 것을 같은 말로 쓰지 않는다.
Sample → Verify → Bulk, 일괄 작업의 유일한 안전 경로
어느 날 나는 "16개 페이지의 메타 태그를 새 규칙에 맞춰 한꺼번에 바꾸자"고 말했다. AI는 자신 있게 응했고, 수십 초 만에 16개 파일 전부가 수정됐다. 그럴듯해 보였다. 그런데 며칠 뒤 OG 이미지 링크를 점검하다가 세 페이지의 경로가 엉뚱하게 바뀌어 있는 걸 발견했다. 템플릿 하나의 미묘한 차이가 AI의 "대량 치환"에서 잘못된 방향으로 증폭되어 있었다.
그날 나는 깨달았다. 확신에 찬 대량 실행이 가장 위험하다. 하나씩 할 때는 오류가 하나지만, 열여섯 개를 한 번에 돌리면 오류도 열여섯 배로 퍼진다. 그래서 우리는 새 룰을 만들었다 — 같은 변경을 세 개 이상 적용할 때는 반드시 먼저 하나만 고쳐보고, 내가 눈으로 확인하고, 승인한 뒤에야 나머지를 일괄 실행한다.
이 세 단계(Sample → Verify → Bulk)는 개발뿐 아니라 일의 모든 영역에 적용되는 규율이다. "이 방법이 맞는 것 같다"는 직관으로 바로 전사 배포를 하는 대신, 한 팀에 먼저 적용해보고 효과를 확인한 뒤 확장하는 것 — 바이브코딩이 나에게 다시 가르쳐준 오래된 지혜다.
다섯 번 중 네 번은 같은 실수가 며칠 뒤에 또 돌아왔다. 대화가 끊기면 AI는 우리가 합의한 룰을 말끔히 잊었다. 어느 날 나는 말했다. "좋아, 이제 너에게 기억 노트를 만들어주자." 그 노트가 CLAUDE.md와 메모리 파일들이다.
다툼이 시스템이 되는 순간 — 품질은 이렇게 만들어졌다
기록이 쌓이자, 같은 말을 두 번 하지 않아도 되는 협업이 시작됐다.
개별 페이지가 완성될 때마다 전문가 페르소나를 가진 AI 에이전트에게 감사를 맡겼다. B2B SaaS·교육 UX 전문가 기준으로 페이지별 점수를 매기고, Critical / Important / LATER로 분류한다. 교육 섹션 5개 페이지는 최종 평균 7.1/10을 받았다. 에이전트는 "국내 중견 B2B 교육사 최상위 수준, 토스·우아한형제들급에 근접"이라고 적었다. 물론 에이전트 한 명의 평가일 뿐이지만, 매일 혼자 들여다보던 화면에 외부의 눈을 빌려주는 장치로서는 충분히 유용했다.
이 과정에서 가장 예상 못 한 깨달음은 "지금 어디에 있는가"를 아는 일의 중요성이었다. 처음엔 큰 그림을 그리고, 그 그림에서 세부 그림들을 하나씩 떼어내 작업했다. 몇 주 뒤 돌아보니 내가 맨 처음 그리고 싶었던 큰 그림이 어느새 완성되어 있었다. 핵심은 매 순간 내 위치와 방향을 놓치지 않는 것이었다. plan/ 폴더의 번호 붙은 문서, 메모리 인덱스, 커밋 메시지 컨벤션 — 이 모든 장치가 결국 "어디에 있고 어디로 가는가"를 잃지 않기 위한 도구였다. 바이브코딩이든 수작업이든, 위치 감각을 잃은 프로젝트는 반드시 무너진다.
피드백 누적도 자동화됐다. A 페이지에서 지적받은 사항을 B 페이지 초안에서 또 반복할 때마다 즉시 CLAUDE.md나 memory/feedback_*.md에 한 줄로 기록한다. 다음 세션이 시작되면 AI가 먼저 그 파일을 읽는다. 같은 말을 두 번 하지 않아도 되는 협업 — 이 복리 효과가 시간이 갈수록 커졌다. 초안의 완성도가 눈에 띄게 올라가기 시작했다.
또 하나의 룰은 매우 단순했다. "작업 시작 전 5분 선스캔." 일을 시작하기 전, 토큰 파일과 네이밍 관례, 기존 규칙을 먼저 5분간 훑는다. 처음에는 분석 과잉처럼 느껴졌지만, 재수정 비용이 훨씬 컸다. 이 5분이 한나절을 구한 적이 여러 번 있었다.
런칭은 끝이 아니라 시작이다
2026년 4월 22일. noindex를 해제하던 날, 사실상 두 번째 프로젝트가 시작됐다.
런칭 직전까지는 사이트를 검색 엔진으로부터 숨기고 있었다. 관련 없는 색인이 먼저 들어가 장기적 SEO를 망치는 리스크를 피하기 위해서다. 런칭일에 noindex를 해제하고, 사이트맵을 네이버 서치어드바이저와 구글 Search Console에 제출했다.
런칭 전에 준비해둔 SEO 전략 문서는 여덟 개였다. 키워드 맵, 메타 템플릿, 스키마 팔레트, 내부 링크 규칙, 네이버 플레이북, 런칭 체크리스트, 새 페이지 워크플로, 애널리틱스 설계. 각각은 AI와 함께 쓴 초안이었지만, 최종 반영 여부는 런칭 전 정적 감사로 확인했다(앞에서 본 "흉터 04"의 교훈이다). 런칭 이후 7일간은 색인 추이와 주요 쿼리의 노출·클릭 데이터를 매일 살폈다. 이 글이 올라가는 시점에도 그 관찰은 진행 중이다.
런칭은 깔끔한 결말이라기보다, 사이트가 살아 있는 자산으로 전환되는 순간이었다. 콘텐츠가 자기 역할을 하기 시작하면, 그때부터 사이트는 회사와 함께 자란다.
바이브코딩의 이점과 한계 — 그리고 다음에 도전할 것
한 달을 지내보고 내린, 실제 적용을 고민하는 분에게 건네는 정리.
누군가 "나도 바이브코딩으로 내 조직의 사이트/앱을 만들어볼까?"라고 묻는다면, 나는 이 네 문단을 먼저 건넬 것이다.
이점 — 바이브코딩이 실제로 잘 해주는 것
구현의 장벽이 사라졌다. 레이아웃, 반응형, 접근성, 디자인 토큰, SEO 메타, 구조화 데이터, 테스트 스캐폴드 — 혼자였다면 몇 달이 걸렸을 일이 며칠로 줄었다. 특히 반복이 필요한 일 — 21개 페이지의 공통 헤더를 동시에 바꾸거나, 16개 아티클에 같은 메타 규칙을 적용하거나 — 에서 압도적인 효율을 낸다. 문서화·커밋 메시지·주석처럼 평소 미루던 일도 자연스럽게 같이 처리된다. 결과적으로 "만들고 싶은데 못 만든다"는 제약이 거의 사라졌다.
한계 — 아직 사람이 해야 하는 것
"무엇을 만들 것인가"의 정의는 여전히 사람의 일이다. 콘텐츠의 진짜 가치, 고객이 정말 듣고 싶어 하는 한 문장, 13년치 경험을 한 페이지로 응축하는 판단 — 이 부분은 AI가 대체해주지 않는다. 또 하나, "이 정도면 되겠지"를 허락하지 않는 품질 감각도 사람의 몫이다. AI는 괜찮아 보이는 초안을 빠르게 만들지만, 전문가의 눈으로 봤을 때 "이건 아직 부족하다"고 가로막는 게이트는 사람이 세워야 한다. 그리고 관계 — 고객과의 대화, 팀의 신뢰, 브랜드의 톤 — 는 여전히 대면의 영역이다.
협업이 성립하는 조건 — 시작하려는 분에게
한 달간 부대껴본 결과, 바이브코딩이 실제로 성과를 내려면 세 가지가 필요했다. 첫째, 합의된 룰을 파일에 기록하는 규율(CLAUDE.md·메모리 시스템). 둘째, 현재 위치를 놓치지 않는 장치(번호 붙은 계획 문서·커밋 컨벤션). 셋째, 외부의 시선(전문가 감사 에이전트·사용자 피드백). 이 세 가지가 빠진 바이브코딩은 빠른 속도로 잘못된 방향으로 나아가게 만든다.
다음에 도전하고 싶은 것
이번 사이트 구축이 "첫 번째 성공 경험"이 되면서, 내 머릿속에는 다음 도전 목록이 길게 쌓이고 있다. 몇 가지만 적어둔다.
- 고객용 자가 진단 도구 — 기업이 자사의 혁신 문제 유형을 5분 안에 진단하고, 우리 방법론 중 어떤 접근이 맞는지 안내받는 인터랙티브 페이지.
- TRIZ 학습 LMS의 자동화 레이어 — 수강생이 제출한 현장 문제를 AI가 일차 분석해 기능 분석·모순 추출 초안을 만들고, 강사는 그 위에 코칭을 얹는 구조.
- AI 에이전트 기반의 워크숍 도구 — 팀 워크숍 중 아이디어 흐름을 실시간으로 구조화하고, 이상해결책 후보를 제안하는 퍼실리테이션 파트너.
- 도서·교구의 디지털 연계 — 이미 출간된 책과 카드 교구 각각에 디지털 확장(QR·AR·웹 시뮬레이터)을 붙여 한 번의 학습이 깊이를 갖게 한다.
- 이 글의 영문 버전과 연작 시리즈 — 바이브코딩으로 만든 페이지별 상세 해부, 전문가 감사 에이전트를 설계한 과정, 네이버·구글 동시 공략 SEO 실록 등.
한 달 전까지만 해도 이 목록의 어느 것도 혼자서는 손대지 못했을 일들이다. 지금은 가능하다. 이것이 이번 프로젝트가 나에게 남긴 가장 실질적인 선물이다.
그리고 나는 일을 다시 사랑하게 됐다
런칭 직전 새벽, 완성된 홈 화면을 스크롤하며 나는 조용히 웃었다.
한 달 동안의 다툼이 쌓아올린 결과물이라기엔 너무 차분한 화면이었다. 사납던 시간들이 어딘가 녹아들어간 듯한 그 평온함이 이 프로젝트의 보상이었다. 기억에 남는 건 웅장한 순간이 아니라, 그 조용한 만족감이다.
런칭 후 며칠, 체감되는 변화가 있었다. 우리 브랜드와 서비스 키워드의 검색 노출이 조금씩 늘었고, 문의 메일과 상담 요청도 이전보다 확연히 잦아졌다. 구체적 수치는 앞으로도 계속 업데이트할 것이다. 그러나 데이터로 잡히지 않는 가장 큰 변화는 따로 있었다. 이 사이트 구축 프로젝트는 단순한 홍보 수단이 아니었다. 내 일을 다시 사랑하게 만든 계기였다.
13년치 프로젝트와 교육 기록을 한 페이지로 응축하는 과정에서, 나는 내가 왜 이 일을 하는지를 다시 만났다. 정리된 한 페이지가 다음 프로젝트의 앵커가 되고, 그 프로젝트가 다시 페이지를 보강한다. 선순환이 시작된 것이다. 그리고 AI와의 관계도 한 단계 성숙해졌다 — 다툼에서 협업으로, 명령에서 합의로.
"우리는 더 이상 '어떻게'를 고민하지 않아도 된다.
'무엇을'만 잘 고민한다면, 나머지는 바이브코딩이 해결해준다."
글의 시작에서 꺼냈던 명제가, 이제는 추상적 주장이 아니라 증거가 있는 경험이 되었다. "무엇을"을 잘 고민하는 일이 오히려 더 어려워졌다고 해도 과언이 아니다. 그러나 그것이야말로 전문가가 AI 시대에 얻게 된 새로운 자유이자 새로운 책임이다.
우리가 TRIZ로 고객사에게 가르치는 것 — 모순을 정의하고, 자원을 차용하고, 체계적으로 탐색하고, 이상해를 향해 나아간다 — 을 우리 사이트 구축에도 그대로 적용했다. 이 글을 여기까지 읽은 분이라면, 아마 비슷한 생각을 하고 계실 것이다. "이 팀이라면, 우리 조직의 문제도 같은 방식으로 풀겠구나."
아래에 그 방법론을 직접 만나보실 수 있는 세 가지 문을 두었다.