'내가 만든 것'의 경계가 흐릿해지고 있다. Python 한 줄 안 쓰고 35년 된 게임을 한글화했고, 프롬프트 하나로 실시간 소셜 플랫폼 전체가 생성됐으며, Notion 페이지에 설명을 적고 버튼을 누르자 배포된 React 앱이 돌아왔다. 이 세 사례는 서로 다른 맥락에서 나왔지만, 하나의 질문을 공유한다. AI와 함께 만들었다면, 그건 누가 만든 건가?
프로젝트 리더가 된 개발자
긱뉴스에 공유된 한글화 사례가 특히 인상적인 건 기술적 난이도 때문이다. Westwood의 독점 바이너리 포맷 PAK·EMC·DLG를 리버스 엔지니어링하고, 1바이트 기준으로 구현된 폰트 렌더러를 2바이트 한글 처리에 맞게 수정하고, ScummVM 오픈소스 코드베이스에 PR까지 올리는 작업이다. 과거라면 C++와 Python에 깊은 이해가 필요한 수주짜리 사이드 프로젝트였을 것이다. 그런데 작성자는 이렇게 회고한다. "실제로 대부분은 Claude Opus/Sonnet이 했고, 나는 프로젝트 리더처럼 독려하고 테스트하고 디버깅했다."
여기서 핵심은 AI가 '대신' 한 게 아니라는 점이다. 어떤 포맷을 분석해야 하는지, 중국어 팬 번역 시스템을 어떻게 재활용할지, 버그의 원인이 getFontOffset의 0 반환 때문이라는 걸 파악하는 것—이 판단들은 여전히 인간의 몫이었다. AI는 그 판단을 코드로 빠르게 구현했을 뿐이다. 지식은 여전히 인간이 갖고 있어야 하지만, 그 지식이 코드로 구현되는 속도가 달라진 것이다.
프롬프트 하나가 풀스택 앱이 되는 구조
Dev.to에 소개된 InsForge + MiniMax M2.7 + Next.js 튜토리얼은 AI 에이전트 기반 개발의 다음 단계를 보여준다. 핵심은 에이전트가 코드를 쓰기 전에 .agents/skills/insforge/ 폴더를 먼저 읽는다는 것이다. SDK 문서, API 패턴, 인증 설정이 에이전트가 읽을 수 있는 형식으로 프로젝트 안에 내장되어 있다. 덕분에 프롬프트는 짧아도 되고, 에이전트는 처음부터 InsForge가 어떻게 동작하는지 알고 있다.
이 구조는 단순한 자동화가 아니다. 에이전트는 프롬프트를 받은 뒤 스스로 전체 DB 스키마(profiles, ripples, waves, follows, notifications, ai_chat_history 등)를 설계하고, 빌드 플랜을 세운 다음 코드를 작성했다. 인증 컨텍스트 연결, 실시간 pub/sub 연결, AI 게이트웨이 라우팅까지 한 번의 패스로 처리됐다. PostgREST 레이어가 모든 테이블을 자동으로 REST 엔드포인트로 만들어주기 때문에 데이터 접근 레이어를 따로 설계할 필요조차 없었다. 배포도 에디터 안에서 끝났다.
아이디어가 앱이 되는 가장 짧은 경로
Vizion 프로젝트는 이 흐름의 극단적 버전이다. Notion 페이지에 원하는 것을 글로 쓰고 버튼을 누르면, 에이전트가 Notion MCP를 통해 페이지 전체 블록 트리를 읽고—텍스트뿐 아니라 DB 스키마와 블록 간 관계까지—React 앱을 생성해 배포한 뒤 임베드로 돌려준다. 폼으로 수집된 데이터는 Notion 데이터베이스에 바로 기록되고, Notion 행을 수정하면 앱이 몇 초 안에 업데이트된다.
흥미로운 건 'Refine' 플로우다. 결과물이 마음에 들지 않으면 Notion 댓글로 피드백을 남기고 Refine 버튼을 누른다. 에이전트가 MCP로 현재 상태, 원본 스펙, 새 댓글을 함께 읽고 전체를 다시 짜는 게 아니라 타깃 diff를 생성한다. 이건 단순 재생성이 아니라 맥락을 이해한 수정이다. 아이디어에서 배포까지의 루프가 Notion 안에서 닫힌다.
시사점: 이제 '어디서 시작할지'가 진짜 실력이다
세 사례를 관통하는 공통점이 있다. AI가 잘 동작하려면 컨텍스트 설계가 선행되어야 한다는 것이다. 한글화 프로젝트에서 AI는 재료—리버스 엔지니어링된 포맷 구조, 기존 ScummVM 코드 레퍼런스, 디버깅 단서—를 갖춰줬을 때 움직였다. InsForge의 에이전트는 .agents 폴더라는 사전 지식 베이스가 있었기에 짧은 프롬프트로 전체 앱을 만들 수 있었다. Vizion은 MCP를 통한 구조화된 페이지 읽기가 있었기에 단순 텍스트 덤프가 아닌 아키텍처 결정을 내릴 수 있었다.
AI에게 '무엇을 만들어줘'라고 말하는 것과, '이 맥락에서 이 문제를 이렇게 접근해줘'라고 설계해서 건네는 것은 결과물의 품질이 다르다. 도구 사용 능력이 아니라 문제를 분해하고, 컨텍스트를 구조화하고, 판단 포인트를 놓치지 않는 역량이 AI 시대 개발자의 핵심 레버리지로 부상하고 있다.
전망: '제작'의 정의가 확장된다
앞으로 '만들었다'는 말은 더 넓은 의미를 갖게 될 것이다. 코드를 직접 타이핑했는지보다, 어떤 문제를 정의하고 어떤 판단을 내렸는지가 제작의 본질로 이동한다. 35년 된 게임의 한글화를 기획하고 버그를 추적한 것, 소셜 플랫폼의 데이터 모델을 설계한 것, Notion 페이지에 제품 스펙을 정확하게 서술한 것—이것들이 이미 '만드는 행위'의 핵심이 됐다.
동시에 리스크도 분명하다. 컨텍스트를 제대로 설계하지 못하면 AI는 방향을 잃고, 판단 포인트에서 인간이 개입하지 못하면 오류가 쌓인다. AI가 설계·구현·배포 전 사이클에 깊이 들어올수록, 루프를 닫는 사람의 판단력이 결과물의 품질을 결정하는 진짜 변수가 된다. 도구는 강력해졌지만, 도구를 다루는 사람의 사고 구조가 더 중요해진 역설적인 시대다.