혼자서 AI로 40개 프로젝트를 만든 방법 — AI Factory라는 작업 방식

이 사이트의 실험실에는 프로젝트 카드가 줄지어 있다. 가끔 “혼자서 이걸 다 만들었냐"는 질문을 받는데, 답은 “혼자서, 그러나 혼자 손으로는 아니다"에 가깝다. 이 글은 그 방식 — 나는 AI Factory라고 부른다 — 를 한 번 정리한 것이다. 잘된 부분만 쓰지 않으려고 숫자부터 그대로 꺼낸다.

숫자부터 정직하게

제목의 “40개"는 어림수다. 지금 실험실 카드를 상태별로 세면 이렇다(AI Factory 자체 카드 포함).

• 전체 44개
• 운영중 14개 — 배포돼서 실제로 돌아가는 것
• 개발중 11개 — 내가 “하자"고 지목해 진행 중인 것
• 준비중 11개 — 설계 문서까지는 있는데 착수하지 않은 것
• 폐기 8개 — 만들다가, 혹은 만들고 나서 접은 것

그러니까 절반 가까이는 “아직” 또는 “이미 아님"이다. 폐기 8개 중에는 끝까지 동작하게 만들고도 접은 것이 있다. 공공데이터로 점포 자리의 개·폐업 이력을 보여주던 상가렌즈는 기술적으로 성립했지만 경쟁 해자가 없다는 결론으로 접었고, 옷 사진만 올리면 AI가 착장샷·상세페이지까지 만들던 무인 쇼핑몰은 착장 품질과 초상권 문제에 동시에 걸려 접었다. 폐기 카드에는 그 회고를 그대로 남겨 둔다. “만들 수 있다"와 “사업이 된다"가 다르다는 걸 매번 새로 배우기 때문이다.

기간으로 보면 이 작업 시스템의 레포 첫 커밋이 2026년 6월 16일이고, 이 글을 쓰는 8월 23일까지 커밋이 1,000건을 넘었다. 프로젝트 중 일부는 그 전부터 있었으니 전부 두 달 만에 생긴 건 아니지만, 속도의 대부분은 이 두 달 안에서 나왔다.

순환: 요구사항 → 설계 → 제작 → 품질개선

AI Factory는 하나의 프로그램이라기보다 작업을 흘려보내는 순서다.

1. 내가 요구사항을 한 줄 적는다.
2. 설계 담당 봇이 그걸 받아 내장된 질문 목록으로 “설계할 수 있을 만큼 정보가 있는가"를 먼저 판정한다. 빠진 게 있으면 진행을 막고 무엇이 빠졌는지 돌려보낸다. 통과하면 구현 단위(Stage)로 쪼개고, 각 단위에 작업 명세·건드려도 되는 파일·테스트 방법을 붙여 넘긴다.
3. 제작 담당 봇은 그 패키지만 보고 코드를 만든다. 허용된 파일 밖은 건드리지 못하게 계약으로 막아 두었다. 한 프로젝트의 수정이 다른 프로젝트로 번지는 사고를 막기 위해서다.
4. 만들자마자 테스트를 돌리고 통과·실패·차단을 기록한다. 실패하면 자기수정 단계로 넘어가서 원인을 요약하고 고쳐서 다시 시도한다. 두 번 연속 실패하면 멈추고 나에게 텔레그램으로 보고한다.
5. 배포된 뒤에도 운영 지표를 채점하고, 기준치 아래로 떨어지면 개선 요구사항을 스스로 써서 2번으로 다시 들어간다.

이 순환에서 자동화가 멈추고 나를 기다리는 지점이 네 군데 있다. 설계 확정, 위험 파일 변경, 배포, 반복 실패. 이 네 곳은 승인 없이는 넘어가지 않는다. 밤에는 이 순환이 사람 없이 돈다. 매일 새벽 3시에 남은 구독 예산만큼 밀린 일을 찾아 개발하되 커밋까지만 하고, 아침에 나는 접수함에서 승인 버튼만 누른다.

사람이 하는 일, AI가 하는 일

두 달을 돌려 보고 나서 나눠진 역할은 이렇다.

내가 하는 일

• 무엇을 만들지 정한다(요구사항 한 줄).
• 준비중인 프로젝트 중 어떤 걸 개발중으로 올릴지 지목한다.
• 네 군데 승인 게이트에서 결정한다.
• “운영중"으로 승격할지, 폐기할지 정한다. 이 두 판단은 사람만 한다.
• 규칙을 문서로 쓴다.

AI가 하는 일

• 설계 분해, 코드 작성, 테스트, 실패 분석과 재시도.
• 야간 개발, 운영 감시, 품질 채점.
• 매일 아침 운영일지 작성.

나는 코드를 거의 안 쓴다. 대신 문서를 쓴다. 처음엔 이게 꼼수 같았는데, 지금은 역할 분담으로 이해한다. 규칙과 결정은 사람 쪽, 반복과 실행은 AI 쪽.

여러 에이전트가 꼬이지 않게 — 문서가 곧 기억

혼자라고 해도 에이전트는 여럿이다. 대화형 세션, CLI 에이전트, 새벽 자동 파이프라인이 같은 레포를 번갈아 만진다. “A가 고친 걸 B가 몰라서 꼬이는” 사고를 한 번 겪고 나서 규칙을 몇 개 고정했다.

• 작업 하나가 끝나면 커밋한다. 세션이 끝날 때가 아니라 작업 단위로.
• 프로젝트마다 인수인계 장부(WORKLOG)를 두고, 만지기 전에 읽고 만진 뒤에 한 줄 남긴다. 장부 갱신 없는 코드 커밋은 훅이 거부한다.
• 상시 서비스 코드를 고쳤으면 재시작까지가 작업 완료다. 디스크의 코드만 바뀌고 옛 프로세스가 돌면 “코드는 맞는데 서비스는 이상한” 유령 장애가 된다.
• 같은 폴더를 두 에이전트가 동시에 고치지 않는다.

그리고 프로젝트마다 착륙 문서를 둔다. 무엇인가, 지금 어디에 어떻게 떠 있나, 어떻게 실행·배포·재시작하나, 다음 할 일은 무엇인가. 8월 초에 개발 도구를 재설치하면서 세션 메모리가 통째로 날아간 적이 있는데, 그 뒤로 “작업에 필요한 지식은 레포 안 문서에 산다"를 원칙으로 박았다. 새 에이전트든 며칠 뒤의 나든, 그 문서 하나로 이어서 일할 수 있어야 한다.

상태 라벨도 같은 맥락이다. 준비중·개발중·운영중·폐기 네 가지는 진열용 색칠이 아니라 계기판이다. 코드가 조금 있어도 내가 지목하지 않았으면 준비중이다. 그래야 “설계까지 해 놓고 멈춘 것"이 숨지 않고 드러난다. 위의 준비중 11개가 바로 그것이다.

운영일지 — 돌아가고 있다는 증거

매일 아침 AI Factory가 어제 하루를 스스로 적는다. 등록 서비스 15개 중 몇 개가 떠 있는지, 자동복구가 발동했는지, 새벽 배치가 몇 건을 처리했는지, 봇들이 어떤 상태인지, 그리고 두 레포에 미커밋 변경이 몇 건 남아 있는지까지. 최근 일지를 보면 15개 중 13개가 가동 중이고 하나는 down으로 찍혀 있다. 숨기지 않는다. 미커밋 변경 수가 일지에 박히니 커밋 규율을 어긴 건 다음 날 아침에 드러난다.

이 방식의 한계

• 준비중 11개는 사실상 “아이디어가 앞서간 빚"이다. 순환이 빨라질수록 설계만 쌓이는 속도도 빨라진다.
• 폐기 8개는 대부분 만들기 전이 아니라 만든 뒤에 알았다. 해자·법·품질 같은 관문은 코드가 아니라 판단의 문제였고, 그건 AI가 대신해 주지 않았다.
• 에이전트가 늘수록 규칙 문서가 늘고, 규칙은 어기는 순간에만 존재가 드러난다. 훅과 일지로 강제하는 이유다.

그래도 이 방식의 핵심 한 줄은 이렇게 남는다. 사람은 결정과 규칙을, AI는 실행과 반복을. 그리고 둘 사이의 기억은 머릿속이 아니라 레포 안 문서에 둔다. 44개 카드와 8개의 폐기 회고는 그 결과물이다.

이 글은 제 여행 기록과 작업 로그를 바탕으로 초안을 AI와 함께 정리하고, 직접 편집했습니다.