한 개인 개발 저장소의 GitHub 이슈와 풀 리퀘스트 일련번호가 네 자릿수에 가까워졌다고 해 보자.
첫 반응은 대개 이렇다.
“혼자 거의 1000번 개발한 거야?”
비슷하지만 정확하지는 않다. GitHub에서는 풀 리퀘스트를 이슈의 한 형태로 취급하며, 같은 저장소 안에서 이슈 번호와 풀 리퀘스트 번호는 서로 겹치지 않는다. 따라서 번호가 1000에 가깝다는 것은 두 종류를 합친 일련번호가 그만큼 진행됐다는 뜻이지, 풀 리퀘스트 1000개를 완료했다는 뜻은 아니다.[1]
그래도 더 재미있는 질문은 남는다.
이 정도 규모의 수정, 확인, 복구, 배포와 운영을 AI 없이 사람이 대부분 손으로 처리했다면 비용이 얼마나 들까? 그리고 그 사업은 실제로 수지가 맞을까?
이 질문은 AI 시대의 1인 개발을 이해하는 핵심에 가깝다.
1. GitHub 번호는 헬스장의 반복 횟수가 아니다
저장소의 번호는 작업량 측정기가 아니다.
어떤 개발자는 한 풀 리퀘스트에 2000줄의 변경을 넣고, 어떤 개발자는 CSS 한 줄 수정에도 풀 리퀘스트를 연다. 버그 신고, 설계 메모, 기능 요청, 조사 작업 같은 이슈도 같은 번호 공간을 사용한다.
따라서,
번호가 1000에 가깝다 = 사람 1000명분의 노동
도 아니고,
번호가 1000에 가깝다 = 완성 기능 1000개
도 아니다.
숫자는 저울보다 개찰구 통과 카운터에 가깝다.
다만 짧은 기간에 작은 변경이 계속 쌓였다면 다른 의미가 있다.
설계 → 구현 → 검증 → 수정의 순환이 반복해서 돌아갔다는 기록이다.
사람의 비용을 계산할 때 봐야 할 것은 번호 자체가 아니라, 실질적인 한 번의 순환에 평균 몇 분이 들었는가다.
2. 작은 일이 많을수록 사람 비용은 쉽게 과소평가된다
2026년 9월 발표된 일본의 프리랜서 엔지니어 채용 공고 집계에 따르면, 2026년 8월 월평균 프로젝트 단가는 78만9000엔이었다.[2]
이 숫자는 모든 개발자의 월급도 아니고 특정인의 시급도 아니다. 시장에 올라온 프로젝트의 평균값이다.
그래도 같은 역량을 외부에서 조달할 때의 대체 비용을 가늠하는 기준으로는 쓸 수 있다.
월 160시간으로 단순 계산하면 시간당 약 4930엔이다.
이제 실질적인 변경 단위가 1000개 있었다고 가정해 보자. 이것은 GitHub의 #1000과는 별개의 가상 계산이다.
| 변경 1개당 평균 시간 | 총시간 | 월 160시간 기준 인월 | 월 78.9만 엔 기준 비용 |
|---|---|---|---|
| 15분 | 250시간 | 1.56 | 약 123만 엔 |
| 30분 | 500시간 | 3.13 | 약 247만 엔 |
| 45분 | 750시간 | 4.69 | 약 370만 엔 |
| 1시간 | 1000시간 | 6.25 | 약 493만 엔 |
| 2시간 | 2000시간 | 12.5 | 약 986만 엔 |
| 3시간 | 3000시간 | 18.75 | 약 1479만 엔 |
| 4시간 | 4000시간 | 25 | 약 1973만 엔 |
15분짜리 변경만 1000번 해도 250시간이다.
“한 건은 가볍다”와 “전체 비용이 가볍다”는 같은 말이 아니다.
작은 작업일수록 조사, 브랜치 작성, 리뷰, 테스트, 병합, 배포 확인 같은 고정 절차의 비중도 커진다.
전부 사람이 한다면 명함에 작가, 번역가, 프론트엔드, 백엔드, QA, 인프라, 편집장을 다 적어야 해서 접이식 명함이 필요해진다.
3. “내가 했으니 인건비는 0원”은 현금 회계에서는 가능하지만 경제 비교에서는 다르다
개인 사이트가 호스팅비로 월 1000엔을 쓰고 광고로 5000엔을 번다면 현금 기준 이익은 4000엔이다.
그런데 운영자가 매달 50시간을 쓴다면 사업 비교에서는 다른 시각이 필요하다.
최소한 두 가지를 나눠 보자.
현금이익 = 매출 − 실제 현금비용
노동조정이익 = 매출 − 실제 현금비용 − 운영자 작업시간 × 비교할 시급
취미라면 자신의 시간을 0원으로 잡아도 아무 문제가 없다. 게임을 50시간 했다고 “인건비 손실”이라고 하지는 않는다.
문제는 취미 회계를 그대로 사업 수익성의 증거로 사용할 때다.
즐거움, 학습, 작품, 평판도 실제 보상이다. 다만 사업이익과 같은 것은 아니다.
사업끼리 비교할 때는 청구서를 발행하지 않았다고 시간이 사라지지는 않는다.
4. 광고 모델은 생각보다 큰 분모를 요구할 수 있다
광고 수익의 단순식은 다음과 같다.
광고수익 = 페이지뷰 ÷ 1000 × 실효 RPM
실효 RPM은 국가, 기기, 광고 형식, 계절, 주제, 독자층에 따라 크게 달라진다.
따라서 여기서는 시장 평균을 단정하지 않고 계산 규모를 보기 위한 가상의 RPM만 사용한다.
광고만으로 월 78만9000엔을 회수해야 한다면:
| 가정한 실효 RPM | 월 78.9만 엔에 필요한 PV |
|---|---|
| 100엔 | 약 789만 PV |
| 300엔 | 약 263만 PV |
| 500엔 | 약 158만 PV |
| 800엔 | 약 99만 PV |
이 표는 특정 사이트의 광고수익 예측이 아니다.
말하고 싶은 것은 간단하다.
사람 노동을 시장 대체비용으로 평가하면 광고만으로 회수하는 데 필요한 트래픽이 매우 커질 수 있다.
그래서 수작업 사이트도 광고 외에 제휴수익, 상품 판매, 고객 유치, 회원제, 후원, 브랜드 가치, 취미 가치가 함께 작동하는 경우가 많다.
5. AI가 바꾸는 것은 글쓰기 속도만이 아니다
AI의 가치를 “30초 만에 글을 쓴다”로만 보면 경제성의 핵심을 놓친다.
웹 미디어 운영에는 주변 공정이 많다.
- 주제 발견
- 조사
- 집필
- 사실 확인
- 코드 수정
- 테스트
- 다국어화
- 배포
- 실제 서비스 확인
- 장애 복구
- SNS와 뉴스레터 배포
- 성과 측정과 개선
사람이 전부 하면 공정이 늘어날수록 변동 인건비도 늘어난다.
AI와 자동화를 결합하면 초기 시스템 설계비는 커질 수 있지만, 두 번째, 열 번째, 백 번째 결과물의 추가 비용을 낮출 가능성이 생긴다.
이 변화는 “작가가 빨라졌다”보다,
한 사람이 작은 편집부와 개발팀의 운영체제를 소유하게 됐다
에 가깝다.
사람이 없어지는 것이 아니다.
사람의 역할이 입력, 판단, 사양, 품질 기준, 예외 처리와 관리로 이동한다.
6. AI는 꽂기만 하면 빨라지는 마법의 가속 장치가 아니다
연구 결과가 한 방향이 아니라는 점이 오히려 흥미롭다.
2023년에 공개된 GitHub Copilot 통제 실험에서는 지정된 JavaScript HTTP 서버 과제를 수행할 때 AI 사용 가능 집단이 대조군보다 55.8% 빨랐다.[3]
반대로 METR이 2025년에 진행한 무작위 비교시험에서는 자신이 오랫동안 다뤄 온 성숙한 오픈소스 저장소의 과제를 수행한 숙련 개발자 16명이 당시 AI 도구를 사용할 수 있을 때 평균 19% 더 오래 걸렸다.[4]
METR은 2026년 2월 후속 실험의 해석도 어렵다고 설명했다. AI 없이 일하는 조건을 싫어해 참여하지 않는 개발자가 늘었고, 여러 AI 에이전트를 동시에 돌리는 사람의 작업시간을 측정하기도 어려웠기 때문이다. 2025년 초보다 최신 AI가 더 큰 속도 향상을 주고 있을 가능성은 있지만, 선택 편향과 측정 문제 때문에 정확한 효과 크기를 강하게 말할 수는 없다고 했다.[5]
따라서 결론은 “AI는 항상 55% 빠르다”도 “AI는 전문가를 19% 느리게 한다”도 아니다.
과제, 코드베이스 친숙도, 에이전트 사용법, 리뷰 부담, 병렬화, 테스트 환경에 따라 달라진다.
AI는 정답을 빠르게 만들 수 있고, 설계가 나쁘면 버그도 빠르게 대량생산할 수 있다.
그래서 자신의 실제 공정에서 직접 측정해야 한다.
7. 수작업 사이트가 반드시 지는 것은 아니다
자동화가 큰 AI 시스템이 수작업 사이트보다 항상 더 많은 이익을 내는 것은 아니다.
수작업이 합리적인 경우도 많다.
- 한 달에 몇 편만 낸다
- 전문가 개인의 문체 자체가 상품이다
- 글 하나가 고가 상품이나 서비스를 판매한다
- 다국어와 대량 배포가 필요 없다
- 업데이트가 적다
- 제작 자체가 즐거운 취미다
- 자동화 구축비가 절약되는 노동비보다 크다
반대로 자동화가 유리해지는 경우는 다음과 같다.
- 같은 공정을 계속 반복한다
- 여러 언어를 운영한다
- 콘텐츠 수가 계속 늘어난다
- 매번 QA, 배포, 실제 서비스 확인을 한다
- 배포 채널이 늘어난다
- 사람이 같은 확인을 계속 반복한다
결국 고정비와 변동비의 문제다.
AI 공장은 처음이 비싸다. 수작업 공방은 제품 하나하나가 비싸다.
그리고 아무리 최신 자동 공장을 만들어도 독자가 한 명도 오지 않으면 미래형 미디어가 아니라 최첨단 창고다.
8. AI 없이 수작업하는 사이트의 채산성을 보려면 이 숫자를 본다
사람을 평가할 필요는 없다.
운영 구조를 비교하려면 다음 숫자면 상당 부분이 보인다.
- 월 운영자 작업시간
- 월간 PV 또는 순방문자
- 월매출과 현금비용
- 전체 글 수와 월 신규 글 수
- 운영 언어 수
- 운영 기간과 초기 구축시간
여기서 최소한 다음을 계산할 수 있다.
현금이익 = 매출 − 현금비용
운영자 현금수익 시급 = 현금이익 ÷ 작업시간
노동조정이익 = 현금이익 − 작업시간 × 비교 시급
글 1개당 한계비용 = 추가 집필 + 번역 + QA + 배포 + 유통에 필요한 시간과 비용
가장 중요한 것은 마지막 항목이다.
과거에 1000시간을 썼다는 사실보다 지금 다음 한 편을 내는 데 몇 시간이 드는가가 미래 채산성을 더 잘 설명한다.
9. AI 1인 개발의 진짜 강점은 대량생산보다 재현성이다
하룻밤에 파일을 대량 생성하는 것 자체는 이제 아주 어려운 일이 아니다.
어려운 것은 다음 상태를 만드는 것이다.
- 다음번에도 같은 품질 기준을 적용한다
- 실패한 범위만 다시 처리한다
- 중복 게시를 막는다
- 현재 버전을 식별한다
- 실제 배포 결과를 확인한다
- 한 채널이 막혀도 관련 없는 작업은 계속 간다
- 정말 사람이 필요한 인증만 사람에게 돌려준다
- 나중에 무슨 일이 있었는지 추적할 수 있다
이것은 단순한 생성량이 아니다.
운영 자산이다.
수작업 사이트도 절차서, 템플릿, CMS, 백업, 체크리스트를 쌓으면 같은 방향으로 갈 수 있다.
AI 시대의 차이는 한 사람이 이런 운영층을 훨씬 깊게 구축할 수 있다는 점이다.
10. 결론: “1000을 찍었나?”보다 “다음 1개는 얼마인가?”가 더 중요하다
이슈와 풀 리퀘스트 일련번호가 네 자릿수에 가까우면 보기에는 강렬하다.
하지만 그것을 생산성 점수로 쓰면 안 된다.
더 중요한 숫자는 다음이다.
사람 작업시간 변경 1회 비용 글 1개의 한계비용 배포 전 재작업률 운영자 1시간당 산출량 매출 대비 노동조정이익
수작업 사이트도 충분히 돈을 벌 수 있다.
AI 사이트도 충분히 적자를 낼 수 있다.
다만 글쓰기, 번역, 개발, QA, 배포, 감시, 유통을 매번 사람이 반복하는 모델과, 처음에 시스템을 만들어 한계비용을 낮춰 가는 모델은 규모가 커질수록 비용곡선이 전혀 달라진다.
1000에 가까운 번호가 흥미로운 이유는 훈장이라서가 아니다.
그 수많은 시행착오 중 얼마나 많은 부분이 다음번부터 사람이 반복하지 않아도 되는 구조로 바뀌었는가.
바로 그 지점이 AI 1인 개발 경제성의 핵심이다.
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
