'직접 작성한 코드(hand-written code)'에 대한 반발은 핵심을 놓치고 있습니다. 개발자 한 명이 AI를 사용하여 완전한 SaaS를 출시할 때 실제로 어떤 일이 일어나는지, 그리고 비판론자들이 무엇을 잘못 알고 있는지 말씀드리겠습니다.

100일 동안 89개의 도구를 만들었습니다. 코드의 90%는 AI가 작성했습니다. 저는 후회하지 않습니다.

현재 dev.to의 담론은 명확합니다. AI 코딩이 자신의 코드를 디버깅(debug)하지 못하는 "프롬프트 엔지니어(prompt engineers)" 세대를 만들고 있다는 것입니다. 직접 작성한 코드에 대한 반발은 실재합니다. 최근 AI 코딩 어시스턴트(coding assistants)를 버려야 한다고 주장하는 HN 포스트는 737점을 기록했습니다. "바이브 코딩(Vibe coding)"은 조롱의 대상이 되었습니다. 시니어 엔지니어들은 이해력 격차와 기술 퇴화에 관한 선언문을 작성하고 있습니다.

저는 이론이 아닌, 실제 프로덕션(production)의 관점에서 반론을 제기하고자 합니다.

2026년 3월 18일, 저는 개인정보 보호를 우선시하는 온라인 도구 모음인 ToolKnit.com을 출시했습니다. 109일 후, 이 사이트는 89개의 브라우저 기반 도구, 87개의 블로그 포스트, **DR 41 도메인 레이팅(domain rating)**을 보유하게 되었으며, Google과 Bing으로부터 매달 수천 명의 방문자를 유치하고 있습니다. 모든 도구는 100% 클라이언트 사이드(client-side)에서 실행됩니다. 백엔드(backend)도, 데이터베이스(database)도, 회원가입도 없습니다.

AI가 코드의 약 90%를 작성했습니다.

비판론자들이 말해주지 않는 부분은 바로 이것입니다: 그것이 작동했다는 점입니다. 그리고 저는 이러한 반발이 이해는 가지만, 잘못된 싸움을 하고 있다고 생각합니다.

"90% AI 생성"이 실제로 의미하는 것

숫자가 중요하기 때문에 정확하게 말씀드리겠습니다.

ToolKnit에는 89개의 도구가 있습니다. 각 도구는 다음과 같이 구성됩니다:

• HTML 페이지 (~350-600줄의 시맨틱 마크업(semantic markup))
• JavaScript 엔진 (~200-800줄의 로직(logic))
• 영어 및 중국어 i18n 번역
• SEO 메타데이터, JSON-LD 구조화된 데이터, Open Graph 태그
• 서비스 워커(service worker) 엔트리
• 사이트맵(sitemap) 엔트리

프로젝트 전체에 걸쳐 대략 55,000줄의 코드가 있습니다.

저는 그중 단 한 줄도 처음부터 직접 작성하지 않았습니다. 모든 파일은 AI 프롬프트(prompt)로 시작되었습니다. 어떤 것은 3번의 반복(iteration)이 필요했고, 어떤 것은 15번이 필요했습니다. 하지만 초기 스캐폴딩(scaffolding), 반복적인 패턴(도구 카드, 푸터 컴포넌트, 메타 태그), JavaScript 로직 등은 모두 AI가 생성했습니다.

하지만 여기서 중요한 점이 있습니다: 저는 모든 줄을 읽고 이해했습니다.

AI를 실제로 작동하게 만드는 워크플로우 (Workflow)

반(Anti)-AI 진영은 개발자들이 AI의 결과물을 읽지도 않고 그대로 프로덕션(Production)에 붙여넣는 세상을 묘사합니다. 저는 실제로 그런 방식으로 일하는 사람을 본 적이 없습니다. 저의 실제 워크플로우는 다음과 같습니다:

1단계: 아키텍처 (인간)

AI는 시스템을 설계할 수 없습니다. 89개의 도구가 각각 자체적인 언어 전환 기능을 구현하는 대신, 공통된 bilingual.js 엔진을 공유해야 한다고 결정할 수 없습니다. 서비스 워커 (Service Worker) 캐싱 전략을 계획하거나 어떤 CDN을 사용할지 결정할 수도 없습니다.

저는 모든 아키텍처 결정을 직접 내렸습니다. 컴포넌트 패턴, 파일 구조, CSS 커스텀 프로퍼티 (CSS custom property) 시스템, 빌드 파이프라인 (Build pipeline)을 설계했습니다. 이것은 프로젝트가 6개월 동안 생존할지, 아니면 자체 무게를 견디지 못하고 무너질지를 결정하는 작업입니다.

2단계: 스캐폴딩 (AI)

패턴이 확립된 후, AI는 승수 (Multiplier) 역할을 했습니다. "이 템플릿을 따르고, 이러한 기능들을 포함하며, 이 CSS 프레임워크를 사용하는 새로운 도구 페이지를 만들어줘."라고 명령하면, 90초 후에 작동하는 JavaScript가 포함된 완전한 HTML 파일이 만들어졌습니다.

AI가 패턴을 이해할 수 있었던 이유는 제가 이미 패턴을 확립해 두었기 때문입니다. bilingual.js가 프로젝트 컨텍스트 (Context)의 일부였기 때문에 AI는 이 이중 언어 설정을 알고 있었습니다. 푸터 (Footer) 패턴, 도구 카드 (Tool card) 패턴, SEO 패턴도 알고 있었습니다.

3단계: 리뷰 및 수정 (인간)

이 지점이 바로 연구들에서 언급된 70%의 거부율이 발생하는 구간입니다. AI는 틀릴 때가 있습니다. API 이름을 환각 (Hallucinate)하기도 합니다. 보기에는 맞지만 특정 뷰포트 (Viewport)에서 깨지는 CSS를 생성하기도 합니다. 해피 패스 (Happy path)는 처리하지만 엣지 케이스 (Edge case)는 무시하는 JavaScript를 작성하기도 합니다.

하지만 중요한 점은 이것입니다: AI가 생성한 코드를 리뷰하는 것이 처음부터 직접 작성하는 것보다 빠르다는 것입니다. "이것이 정확한가?"라는 인지 부하 (Cognitive load)는 "무엇을 작성해야 하며 그것이 정확한가?"라는 부하보다 낮습니다.

ToolKnit의 경우, 리뷰 단계는 파일당 보통 5~10분 정도 소요되었습니다. 저는 다음과 같은 사항들을 스캔했습니다:

• 논리적 오류 (Logical errors) (일시 정지를 제대로 처리하지 못하는 타이머 카운트다운)
• 엣지 케이스 (Edge cases) (localStorage가 가득 차면 어떻게 되는가?)
• 보안 문제 (Security issues) (클라이언트 측 도구라 할지라도 사용자 입력을 절대 신뢰하지 말 것)
• i18n 완성도 (i18n completeness) (중국어 번역이 실제로 생성되었는가?)

4단계: 반복 (Iterate) (인간 + AI)

주고받는 과정에서 진짜 작업이 이루어집니다. "탭을 전환할 때 진행 상태 링(progress ring)이 업데이트되지 않습니다." "모바일 레이아웃이 320px에서 깨집니다." "'health recovery timeline'에 대한 중국어 번역이 어색합니다."

각 수정 사항은 또 다른 AI 프롬프트(prompt)가 됩니다. 각 프롬프트는 30초가 걸립니다. 각 수정 사항을 검증하는 데는 2분이 걸립니다.

비판론자들이 맞춘 부분

비난에 대해 공정하게 대하고 싶습니다. 그들이 완전히 틀린 것은 아닙니다.

AI 코드는 중앙값(median)으로 수렴합니다. AI에게 아키텍처(architecture) 설계를 맡기면, 모든 곳에 useState와 useEffect가 들어간 평범한 React 앱을 얻게 될 것입니다. 틀리지는 않겠지만, 훌륭하지도 않을 것입니다. 중앙값은 CRUD 작업에는 괜찮습니다. 하지만 새롭고 독창적인 작업에는 치명적입니다.

이해의 격차(comprehension gap)는 실재합니다. 10년 전 제가 직접 코드를 작성했을 때는 모든 서브시스템(subsystem)에 대한 정신적 모델(mental model)을 구축했습니다. AI를 사용할 때는 생성된 결과물을 읽음으로써 그 모델을 능동적으로 구축해야 합니다. 이는 저작(authorship)보다는 코드 리뷰(code review)에 더 가까운, 다른 종류의 이해 방식입니다. 하지만 스스로를 절제하며 임한다면 여전히 이해는 일어납니다.

AI가 생성한 코드를 디버깅하는 것은 더 어렵습니다. 직접 코드를 작성했을 때는 어디에 무엇이 숨겨져 있는지(where the bodies are buried) 알고 있습니다. AI가 작성했을 때는 그것들을 직접 찾아내야 합니다. 이것이 제 워크플로우에서 생산성을 떨어뜨리는 가장 큰 요인입니다. AI가 90초 만에 작성한 200줄짜리 JavaScript 파일을 디버깅하는 데 45분을 소비한 적도 있습니다. 그 비율은 실재하며 고통스럽습니다.

비판론자들이 틀린 부분

그들은 AI가 사고(thinking)를 대체한다고 가정합니다. 그렇지 않습니다. AI는 타이핑(typing)을 대체합니다. 사고 — 즉 아키텍처, 설계 결정, 사용자 경험(UX), SEO 전략 — 이 모든 것은 여전히 인간으로부터 나옵니다. AI는 실행을 위한 승수(force multiplier)이지, 판단(judgment)을 위한 대체재가 아닙니다.

그들은 AI의 결과물을 이상적인 인간의 결과물과 비교합니다. 공정한 비교는 AI의 결과물 대 한 명의 개발자가 주어진 시간 내에 실제로 출시(ship)할 수 있는 결과물 사이의 비교여야 합니다. 저는 AI 없이도 ToolKnit을 만들 수 있었을 것입니다. 다만 100일이 아니라 500일이 걸렸을 것입니다. 그리고 그 추가된 400일 동안, 저는 아마 똑같이 많은 실수를 저질렀을 것입니다. 단지 더 느리게 저질렀을 뿐이죠.

그들은 1인 개발자의 경제학을 무시합니다. 저는 혼자입니다. 팀이 없습니다. QA(품질 보증) 부서도 없습니다. AI는 저의 러버 덕(rubber duck), 코드 리뷰어, 주니어 개발자, 그리고 문서 작성자입니다. 1인 창업자에게 "신중한 검토를 동반한 AI"의 대안은 "결점 없는 수기 코드(hand-written code)"가 아닙니다. 그것은 "89개 대신 15개의 도구만을 출시하는 것"입니다.

논점을 증명하는 도구들

AI가 출시 속도를 진정으로 가속화한 ToolKnit의 몇 가지 사례입니다:

Quit Smoking Tracker — localStorage 지속성(persistence), 10단계 건강 회복 타임라인(CDC/WHO 연구 기반), 업적 배지, 그리고 이중 언어 지원을 갖춘 행동 강화(behavioral reinforcement) 도구입니다. 피한 담배 수, 절약한 금액, 되찾은 삶의 시간 등을 계산하는 핵심 로직을 구현하는 데 약 4번의 프롬프트(prompt)가 소요되었습니다. 건강 타임라인 컴포넌트에는 3번의 프롬프트가 더 필요했습니다. 총 개발 시간은 약 2시간이었습니다.

Pomodoro Timer — SVG 애니메이션이 적용된 원형 진행률 표시 링, 세 가지 작업/휴식 모드, 설정 가능한 지속 시간, 오디오 알림, 그리고 탭 제목 카운트다운 기능을 갖추고 있습니다. SVG 호(arc) 애니메이션 로직만 해도 처음부터 작성했다면 한 시간은 걸렸을 것입니다. AI는 단 한 번의 프롬프트로 이를 생성했습니다. 저는 엣지 케이스(사용자가 탭을 전환할 때 어떤 일이 발생하는가?)를 수정하는 데 15분을 썼습니다.

PDF to Image — pdf.js와 canvas를 사용하여 PDF 페이지를 PNG/JPG/WebP로 변환합니다. 이것은 pdf.js API를 며칠 동안 깊이 파고들어야 하는 작업이었을 것입니다. AI는 API의 표면적(surface area)을 알고 있었고, 렌더링 파이프라인을 생성했으며, 형식 변환 옵션을 처리했습니다. 저는 정확성을 검증하고 브라우저별 렌더링 버그를 수정했습니다.

이 패턴은 89개의 모든 도구에 반복됩니다. AI는 API 통합 (API integration), 보일러플레이트 (boilerplate), 반복적인 패턴을 처리합니다. 저는 아키텍처 (architecture), UX 결정, 예외 케이스 (edge cases), 그리고 품질 게이트 (quality gate)를 담당합니다.

그렇다면 코드를 작성할 때 AI를 사용해야 할까요?

2026년에 "코딩할 때 AI를 사용해야 할까요?"라고 묻는 것은 2016년에 "프레임워크를 사용해야 할까요?"라고 묻는 것과 같습니다. 답은 당신이 무엇을 만들고 있는지, 그리고 당신이 누구인지에 따라 달라집니다.

다음의 경우 AI를 공격적으로 사용하세요:

• 제품을 출시하는 1인 개발자일 때
• 프로젝트에 명확하고 반복 가능한 패턴이 있을 때
• 코드를 검토할 수 있을 정도로 충분히 잘 이해하고 있을 때
• 아키텍처의 우아함보다 시장 출시 속도 (speed-to-market)가 더 중요할 때

다음의 경우 AI를 회의적으로 바라보세요:

• 새롭고 성능이 중요한 시스템을 구축할 때
• AI의 결과물을 아직 평가할 수 없는 주니어 개발자일 때
• 프로젝트에 복잡한 상태 관리 (state management)나 레이스 컨디션 (race conditions)이 있을 때
• 보안에 민감한 인프라를 작업할 때

결정적인 변수는 도구가 아닙니다. 도구가 만들어낸 결과물을 검토할 능력이 당신에게 있느냐입니다. 버그를 찾아낼 수 있다면 AI는 승수 (multiplier)가 됩니다. 찾아낼 수 없다면 AI는 부채 (liability)가 됩니다.

이것이 바로 현재 기술 업계에서 가장 위험한 조언이 "그냥 AI를 쓰세요, 코딩을 배울 필요는 없습니다"인 이유입니다. 당신은 반드시 코딩을 배워야 합니다. 다만, 예전만큼 많이 타이핑할 필요는 없을 뿐입니다.

결론

109일. 89개의 도구. 87개의 블로그 포스트. DR 41. Google과 Bing으로부터 오는 실제 트래픽. 이 모든 것을 AI의 도움을 받은 한 사람이 구축했습니다.

수기로 코드를 작성하는 사람들은 위험성에 대해 틀린 말을 하는 것이 아닙니다. 그들은 결론에 대해 틀렸습니다. 목표는 수기로 작성된 코드가 되어서는 안 됩니다. 목표는 **이해된 코드 (understood code)**여야 합니다. 즉, AI의 도움을 받았든 아니든, 개발자가 모든 줄이 무엇을 하는지, 왜 거기에 있는지 알고 있는 코드 말입니다.

AI가 ToolKnit를 만든 것이 아닙니다. 제가 ToolKnit를 만들었습니다. AI는 제가 할 수 있는 것보다 더 빠르게 타이핑했을 뿐입니다. 그게 전부입니다. 그것이 마법의 전부입니다.

그리고 저는 단 하나의 프롬프트 (prompt)도 후회하지 않습니다.

ToolKnit.com은 89개의 브라우저 기반 유틸리티를 제공하는 무료이며 개인정보를 우선시하는 온라인 도구 모음입니다. 업로드도, 회원가입도, 광고도 없습니다. 모든 도구는 전적으로 사용자의 브라우저 내에서 실행됩니다.

AI 코딩에 대한 여러분의 경험은 어떠신가요? 그것이 여러분의 프로젝트에 승수 효과 (multiplier)를 가져다주었나요, 아니면 부담 (liability)이 되었나요? 저는 진심으로 궁금합니다. 특히