AI로 개발하는 것의 어려운 부분은 코드가 아니라 허점을 찾아내는 것이다
요약
비개발자인 PM이 Claude Code를 활용해 게임 위키 시스템을 구축하며 얻은 통찰을 다룹니다. AI 개발의 핵심은 코드 작성이 아니라 AI가 생성한 정보의 허점을 찾아내고 검증하는 판단력에 있음을 강조합니다.
핵심 포인트
- AI 개발의 핵심은 코드 작성이 아닌 결과물의 허점(bullshit)을 찾아내는 검증 능력임
- AI 에이전트 활용 시 사실 관계 확인을 위한 출처(source) 기반 검증 프로세스가 필수적임
- AI가 생성한 결과물의 톤(tone)을 조정하고 논쟁하는 과정이 실제 업무의 큰 비중을 차지함
- 효율적인 AI 협업을 위한 시간 배분: 지시 20%, 검토 30%, 검증 30%, 톤 조정 20%
Pathogenic이라는 게임이 7월 16일에 출시되었습니다. 이 게임은 인간 몸속의 기생충 역할을 하는 로그라이크(roguelike) 장르입니다. 출시 당일, 저는 이 게임에 대한 전체 위키를 라이브로 구축했습니다. 가이드, 데이터베이스, 패치 노트 등 모든 것이 포함되어 있습니다.
저는 개발자가 아닙니다. 제품 관리자(product manager)입니다. 코드를 작성하지 않습니다. 저는 AI 코딩 에이전트(Claude Code)를 사용하여 이 전체 시스템을 구축했습니다. Next.js, Cloudflare Workers, SSR, 콘텐츠 파이프라인 등 모든 것을 말이죠.
그리고 그 경험은 'AI가 개발자를 대체할 것'이라는 담론 속에서 간과되는 무언가를 저에게 가르쳐주었습니다.
코드는 쉬운 부분이었습니다. 어려운 부분은 허점(bullshit)을 찾아내는 것이었습니다.
실제 'AI로 구축하는 것(building with AI)'의 모습은 이렇습니다.
저는 에디터를 열지 않습니다. 터미널을 열고 평이한 언어로, 즉 영어 또는 대부분 중국어(저의 모국어)로 AI 에이전트와 대화합니다. 저는
AI는 의학 문헌(병원성 박테리아, 화상 상처)의 파편들과 "Pathogenesis"라는 완전히 다른 보드 게임의 내용을 가져와 권위 있어 보이는 무언가로 엮어냈습니다. 만약 제가 그것을 그대로 게시했다면, 그 위키(wiki)는 시작과 동시에 망했을 것입니다.
그래서 저는 규칙을 하나 만들었습니다. 모든 주장에는 출처(source)를 링크해야 한다는 것입니다. 공식 패치 노트, 개발자의 답변, 또는 커뮤니티의 게임 플레이 영상 같은 것들 말입니다. 출처를 확인할 수 없다면, 게시하지 않습니다. AI가 조사를 수행하고, 저는 그 조사 내용을 검증(verify)합니다.
상황이 실전이 된 순간
지난주, 한 플레이어가 제 Steam 가이드에 댓글을 남겼습니다. 그들은 이렇게 말했습니다: "Brain 구역에 상점이 있습니다."
제 가이드에는 상점이 없다고 적혀 있었습니다. 제가 본 게임 플레이 영상에 상점이 나오지 않았다는 사실에 근거하여, 저는 확신을 가지고 그렇게 작성했습니다. AI가 그 글을 쓰는 것을 도와주었죠.
플레이어의 설명은 구체적이었습니다: 상점은 화폐(currency)를 거의 주지 않지만, 부품들은 항상 전설 등급(legendary tier)이라고 말입니다.
제게는 두 가지 선택지가 있었습니다: 플레이어의 댓글을 믿고 가이드를 수정하거나, 먼저 검증하거나.
저는 즉시 수정할 뻔했습니다. 제 본능은 "실제로 Brain을 플레이해 본 플레이어가 나보다 더 잘 안다"라고 말했습니다. 하지만 곧 스스로를 다잡았습니다. 댓글 하나는 검증이 아닙니다. 저는 독립적인 확인(independent confirmation)을 위해 검색했습니다. 아무것도 찾을 수 없었습니다. 제가 봤던 영상에서도 상점에 대한 언급이 없었지만, 그것이 상점이 없다는 것을 확인하는 것과는 같지 않습니다.
그래서 저는 문구를 중립적인 것으로 바꿨습니다: "Brain에 진입하기 전에 빌드(build)를 완료하세요."라고 말이죠. "상점이 없다"라고도, "상점이 있다"라고도 하지 않았습니다. 그저 어느 쪽이든 유효한 실질적인 조언을 남긴 것입니다.
그것이 바로 업무입니다. 콘텐츠를 쓰는 것이 아닙니다. 코드를 짜는 것도 아닙니다. 무언가 그럴듯하게 들리지만 확인되지 않은 순간을 포착하고, 판단(judgment call)을 내리는 것입니다.
제가 실제로 시간을 쓰는 일
솔직히 말하자면, 시간 배분은 다음과 같습니다:
- 20% AI에게 무엇을 만들지 지시하기
- 30% AI가 생성한 결과물 검토하기
- 30% 출처를 바탕으로 사실 검증하기
- 20% 톤(tone)에 대해 AI와 논쟁하기
마지막 항목은 정말 실재하는 문제입니다. AI는 특유의 기묘한 "도움이 되는 비서 (helpful assistant)" 말투로 글을 씁니다. 모든 것이 "포괄적 (comprehensive)"이고 "매끄러우며 (seamless)", "~라는 점을 주목할 가치가 있습니다 (it's worth noting that)"와 같은 식입니다. 저는 "위키 편집자처럼 말하지 말고, 게임을 잘 아는 플레이어처럼 말해라"라고 말하는 데 많은 시간을 소비합니다.
코드 부분은요? 거의 생각조차 하지 않습니다. 에이전트 (agent)가 빌드 (build), 배포 (deployment), SEO 헤더 (SEO headers), 구조화된 데이터 (structured data)를 처리합니다. 한 번은 회귀 (regression) 오류를 잡아내기도 했습니다. 제가 공유 컴포넌트 (shared component)를 변경했을 때 다른 가이드 페이지가 망가졌는데, 제가 알아채기 전에 에이전트가 먼저 알아차렸습니다.
같은 일을 시작하려는 사람에게 해주고 싶은 말
- AI는 빠르지만 신뢰할 수 없습니다. 가끔 환각 (hallucination)을 일으키는 똑똑한 인턴처럼 대하세요. 모든 사실적 주장은 검증되어야 합니다. AI가 "출처를 확인했습니다"라고 말하는 모든 내용은 당신이 다시 확인해야 합니다.
- 검증 가능한 사실이 있는 니치 (niche) 시장을 선택하세요. 게임 위키가 작동하는 이유는 대조할 수 있는 패치 노트 (patch notes), 개발자 포스트, 게임플레이 영상이 있기 때문입니다. 만약 제가 마케팅 블로그를 만들고 있었다면, 무엇을 어떻게 검증해야 할지 몰랐을 것입니다.
- 품질의 기준은 AI가 아니라 당신의 것입니다. AI는 80%는 맞고 20%는 조작된 2,000단어 분량의 가이드를 기쁘게 발행할 것입니다. 그 20%가 당신의 신뢰도를 무너뜨릴 것입니다. 그것을 잡아내는 사람은 반드시 당신이어야 합니다.
- 커뮤니티와 소통하세요. 제 Steam 가이드를 수정해 준 플레이어는 저에게 도움을 준 것입니다. 덕분에 무언가를 배웠습니다. 그리고 제가 그들에게 감사 인사를 전하며 "이 내용을 검증하겠습니다"라고 말했을 때, 단순히 조용히 텍스트를 수정했을 때보다 더 큰 신뢰를 쌓을 수 있었습니다.
사이트
궁금하시다면: Pathogenic Game Wiki. 여기에는 Brain 루트, Brain 보스전, Overcharge 메커니즘, Burn 빌드, 협동 (Co-op) 설정, 그리고 초보자 가이드가 있습니다. 모든 주장은 출처로 링크되어 있습니다. 확인되지 않은 내용에는 확인되지 않았다고 명시되어 있습니다.
이것이 개발의 미래라고 주장하는 것은 아닙니다. 제가 말하고자 하는 바는, 명확한 콘텐츠 비전과 엄격한 품질 기준을 가진 비개발자(non-coder)에게 이제 도구들이 실제로 결과물을 출시할 수 있을 만큼 충분히 좋아졌다는 것입니다. 병목 현상(bottleneck)은 "이것을 만들 수 있는가?"에서 "이것이 실제로 정확한가?"로 이동했습니다. 그리고 그것은 훨씬 더 흥미로운 문제입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기