AI를 몇 개 쓰면 혼자서 회사처럼 일할 수 있을까?
AI 5개를 돌린 연구자 사례가 보여준 것은 AI의 숫자가 아니라 확인 장치의 중요성이다
AI 구독을 몇 개 쓰는지가 혼자 할 수 있는 일의 크기를 정하지는 않는다. 중요한 것은 AI가 만든 결과를 사람이 일일이 읽지 않아도 먼저 걸러낼 수 있는 확인 장치다. 연구자 1명이 AI 에이전트 5개를 돌린 사례에서도 핵심은 AI의 숫자가 아니라 검증 방식이었다.
AI를 많이 돌리는 것보다 틀린 결과가 밖으로 나가지 않게 만드는 것이 먼저다.
정말 혼자서 칩까지 만들었나?
2026년 8월 arXiv에 올라온 한 보고서에는 연구자 제이슨 히키가 AI 에이전트 5개를 활용한 작업이 기록돼 있다. 2026년 7월 6일 빈 저장소에서 시작해 37일 동안 수학, 컴파일러, 반도체, 증명 확인 등의 일을 나눠 맡겼다.
에이전트는 총괄, 수학, 컴파일러, 반도체, 증거 담당으로 나뉘었다. 그 결과 수학 저장소에서는 2,087건의 커밋과 32만 줄 이상의 증명 코드가 나왔고, 시스템 쪽에서는 실제 칩 설계 제출까지 이어졌다.
| 항목 | 숫자 | 조건 |
|---|---|---|
| 전체 기간 | 37일 연속(5주), 작업 없는 날 0일 | 2026.7.6~8.11 |
| 수학 저장소 커밋 | 2,087건, 하루 평균 56.4건, 최다 178건 | 37일 |
| 시스템 저장소 커밋 | 1,379건, 하루 최다 343건 | 7일 |
| 수학 증명 코드 | 32만 줄 이상(엄격 집계), 단순 집계 658,103줄 | 표준 라이브러리 크기의 29.3% |
| 에이전트가 쓴 칩 설계 코드 | 22,679줄, 파일 71개 | 도구가 자동 생성한 부분은 제외 |
| 칩 배치 소자 | 43,884개(그중 논리 소자 11,212개) | 제출된 최종본 |
그렇다고 AI가 무엇이든 해냈다는 뜻은 아니다. 목표 가운데 하나였던 쌍둥이 소수 추측은 풀지 못했다. 이 사례에서 확인할 수 있는 것은 정해진 방식으로 확인할 수 있는 일을 대량으로 처리했다는 점이다.
사람은 그동안 무엇을 했나?
사람이 AI 결과를 계속 옆에서 지켜본 것은 아니다. 측정 구간인 116시간 40분 가운데 사람이 붙어 있던 시간은 37시간 21분이었다.
처음에는 사람이 개입한 시간이 44시간 25분으로 계산됐다. 하지만 총괄 에이전트가 다른 에이전트에 보낸 입력 11시간 50분어치가 사람의 입력처럼 잡힌 것을 확인해 이를 빼고 다시 계산했다.
| 측정 | 숫자 | 비고 |
|---|---|---|
| 측정 구간 실제 시간 | 116시간 40분(4.86일) | 밤 시간 포함 |
| 사람이 붙어 있던 시간 | 37시간 21분, 45개 구간 | 처음 계산 44시간 25분 → 기계 입력 11시간 50분 제외 |
| 같은 구간 AI 출력량 | 2,807만 토큰, 요청 36,844건 | 커밋 1,376건, 증명 코드 56,951줄 |
| 코드 한 줄당 출력 | 376토큰 | 설명문 포함, 전체로 넓혀 계산하면 안 됨 |
| 1시간 이상 무지시 커밋 비율 | 수학 43.0%, 시스템 24.4% | 4시간 이상은 14.5%, 4.6% |
| 8시간 이상 무지시 커밋 비율 | 수학 8.8%, 시스템 1건 | 밤 9시~새벽 5시 커밋 18.1% |
사람이 한동안 지시하지 않아도 작업은 이어졌다. 수학 쪽 커밋의 43.0%는 사람이 1시간 넘게 지시하지 않은 사이에 나왔다. 가장 긴 공백은 20시간 56분이었다. 그동안 커밋 26건과 증명 코드 12,310줄이 쌓였다.
다만 모든 일이 이렇게 오래 사람 없이 진행된 것은 아니다. 수학처럼 정답을 기계로 판정할 수 있는 일은 맡겨 두기 쉬웠고, 칩처럼 확인 고리가 약한 일은 사람이 더 자주 개입했다.
AI가 틀리면 누가 잡나?
이 사례에서 가장 중요한 장치는 증명 검사기인 Lean 4 커널이었다. 증명 검사기는 수학 증명이 규칙에 맞는지 기계로 확인하는 프로그램이다.
사람은 증명을 하나씩 직접 읽지 않았다. 검사기가 각각의 증명을 확인했고, 에이전트끼리도 서로 결과를 확인했다. 7월 7일부터 20일까지 검사기와 교차 확인 과정에서 오류에는 256번까지 번호가 붙었다. 79번이 비어 있어 번호가 붙은 오류는 255건이었다.
| 확인 항목 | 결과 | 확인 수단 |
|---|---|---|
| 잡아낸 설계 오류 | 번호 256번까지(79번 결번, 이후 건은 번호 없이 기록) | 검사기 + 에이전트 교차 확인 |
| 최종 기록에 들어간 틀린 증명 | 0건 | 증명 검사기 |
| 등록된 주요 정리 | 73개, 반영 날짜 모두 일치 | 저장소 기록 대조 |
| 사람이 손으로 분류한 오류 | 앞 78건만 | 나머지는 미분류 |
| 칩 검사 단계 | 서로 다른 에이전트가 만든 검사기 3개, 판정 충돌 2번 | 바이트 단위로 맞춰 해결 |
틀린 결과가 나온 것은 이상한 일이 아니었다. 측정 범위를 잘못 잡은 주장도 있었고, 오래된 인용이나 원리를 엉뚱한 곳에 적용한 설명도 있었다. 중요한 것은 이런 결과를 그대로 기록에 넣지 않았다는 점이다.
설계도 실행 전에 다른 에이전트가 반박하도록 했다. 숫자를 뽑을 때는 그 숫자를 만든 명령도 함께 기록했다. 정해진 예산을 다 쓴 에이전트는 계속 작업하지 않고 멈춰서 실패했다고 알렸다.
칩도 전부 기계가 확인했나?
그렇지는 않았다. 이 부분이 이 사례의 중요한 한계다.
처음 제출한 칩 설계의 기억 소자 902개 가운데 증명 검사를 거친 설계에서 바로 만들어진 것은 288개, 31.9%였다. 나머지 614개는 에이전트가 작성한 설계 코드에서 나왔다.
최종본의 논리 소자 11,212개를 보면 에이전트가 쓴 설계 코드가 만든 부분은 6,944개, 61.9%였다. 증명 검사를 거친 설계에서 나온 부분은 1,443개, 12.9%였다.
| 최종 칩 논리 소자 11,212개를 만든 주체 | 개수 | 비율 |
|---|---|---|
| 에이전트가 쓴 설계 코드 | 6,944 | 61.9% |
| 도구가 넣은 타이밍 보정 | 2,611 | 23.3% |
| 증명 검사를 거친 설계에서 생성 | 1,443 | 12.9% |
| 클럭 배선 자동 생성 | 214 | 1.9% |
모든 설계 코드를 증명 검사기로 확인할 수 있었던 것은 아니다. 범용 하드웨어 설계 코드를 증명 검사기로 옮겨 확인하는 공개 도구가 아직 없기 때문이다. 그래서 이 구간은 자동 대조 검사인 SAT 동치 검사로 확인했다.
가게 일도 비슷하다. 확인할 방법이 있는 일은 AI에 더 맡길 수 있다. 확인 방법이 약한 일은 사람이 더 가까이 붙어 있어야 한다.
그럼 사장님은 무엇을 직접 해야 하나?
보고서에서 사람에게 남은 일은 크게 두 가지였다. 먼저 무엇을 원하는지 글로 적는 일이다. 그다음 결과가 정말 기준을 충족했는지 읽고 판정하는 일이다.
합격 기준은 일을 시작하기 전에 정했다. AI가 결과를 내놓은 뒤 기준을 바꾸지 않기 위해서다. 되돌릴 수 없거나 바깥으로 나가는 행동도 사람이 맡았다.
| 사람이 남겨 둔 일 | 기계에 맡긴 일 | 보고서의 규칙 |
|---|---|---|
| 원하는 것을 글로 적기 | 실제 구현 | 합격 기준은 시작 전에 정함 |
| 결과 요약문 읽고 판정하기 | 증명· | 사람은 증명을 읽지 않음 |
| 제출· | 그 직전까지 준비 | '누르기만 하면 되는 상태'에서 멈춤 |
| 하루 1번 정해진 판정 회의 | 밤사이 실행 | 설계는 회의에서 확정 |
| 목표 문장 바꾸기 | 목표 문장 바꾸기 금지 | 증명이 안 된다고 목표를 낮추지 않음 |
사람과 에이전트의 회의는 하루 한 번 정해진 시간에 열렸다. 설계는 회의에서 확정했고, AI는 그 전까지 필요한 작업을 진행했다.
이 규칙은 작은 가게에도 그대로 생각해 볼 수 있다. AI에게 일을 맡기는 것과 고객에게 바로 나가는 것을 같은 단계로 두지 않는 것이다.
가게에서는 어떻게 확인하면 되나?
가게에는 수학 증명 검사기 같은 장치가 없을 수 있다. 그래도 AI가 만든 결과를 사람이 보기 전에 먼저 확인하는 절차는 만들 수 있다.
가격표를 AI가 고쳤다면 원본 메뉴판과 품목 수, 합계를 표 계산으로 대조할 수 있다. 홈페이지 글이라면 영업시간, 주소, 가격 같은 사실을 원본 표 한 곳에서 가져오게 할 수 있다. 링크가 실제로 살아 있는지도 별도로 확인할 수 있다.
글을 만든 AI와 다른 AI에게 같은 결과를 다시 만들게 하는 대신, 틀린 곳만 찾게 하는 방법도 있다. 고객에게 문자를 보내거나 결제하거나 글을 공개하는 마지막 행동은 사람이 직접 하는 식이다.
국내 조사에서도 AI 결과를 바로 쓰기 어렵다는 응답이 많았다. 국민대 플랫폼SME연구센터의 2025년 7월 조사에서는 디지털 상공인의 86.6%가 생성형 AI 결과물을 바로 쓰기 어렵다고 답했다.
| 조사 | 숫자 | 조사 주체· |
|---|---|---|
| 결과물을 바로 쓰기 어려움 | 86.6% | 국민대 플랫폼SME연구센터, 2025.7, 디지털 상공인 |
| 실습 위주 교육이 필요함 | 60% | 같은 조사 |
| 가장 큰 걱정: 잘못된 정보 | 61.3% (보안· | 메가존클라우드· |
| 미국 사업체 정기적 AI 이용 | 48% → 77% | 인투잇 퀵북스, 2024.7→2026, 사업주 3만 4천여 명 |
| 생산성이 나아졌다 | 78% | 같은 조사 |
| 혼자 일하는 자영업자 생성형 AI 이용률 | 12.6% | KISDI, 2026.4 |
이 숫자는 AI를 쓰지 말라는 뜻이 아니다. 오히려 AI가 만든 결과를 그대로 쓰지 않고 한 번 걸러내는 과정이 필요하다는 뜻에 가깝다. 혼자 일하는 자영업자의 생성형 AI 이용률이 12.6%였다는 조사도 있다.
AI 구독 몇 개면 직원 몇 명 몫일까?
이 사례만으로 그런 계산을 할 수는 없다. 저자도 이 구성이 최선이거나 일반적인 방식이라고 주장하지 않는다고 적었다.
돈도 정확히 계산할 수 없다. 구독료가 요청 한 건마다 정해진 것이 아니어서 작업 하나에 얼마가 들었는지, 모델 사용 시간이 얼마였는지를 기록만으로 계산할 수 없다.
측정에도 한계가 있다. 출력량 측정은 마지막 4.86일에만 이뤄졌다. 주요 정리가 이미 나온 뒤였고, 저자도 이를 가장 큰 측정 공백으로 적었다.
무엇보다 수학처럼 정답을 기계로 확인할 수 있는 일과 맛, 친절, 사진의 분위기처럼 기계가 쉽게 판정하기 어려운 일을 같은 방식으로 볼 수는 없다.
그래서 이 사례에서 가져갈 결론은 단순하다. AI를 몇 개 구독할지부터 정하기보다 어떤 결과를 어떻게 확인할지를 먼저 정해야 한다. 확인 장치가 있는 일부터 맡기면 혼자서 처리할 수 있는 일의 범위를 넓힐 수 있다.
요점 ① 연구자 1명이 AI 에이전트 5개를 37일 동안 돌려 커밋 2,087건과 증명 코드 32만 줄 이상을 만들었다. ② 측정 구간 116시간 40분 가운데 사람이 붙어 있던 시간은 37시간 21분이었다. ③ 오류는 256번까지 번호가 붙었고 79번 결번을 제외하면 255건이었으며, 최종 기록에 들어간 틀린 증명은 0건이었다. ④ 국내 디지털 상공인의 86.6%가 AI 결과를 바로 쓰기 어렵다고 답했으며, 핵심은 AI 수보다 확인 장치와 마지막 사람 확인이다.
같이 읽을 글
자료 출처
- AI with Authority, from Application to Silicon(Jason Hickey·arXiv 2608.21356·2026년 8월 제출, 8.25 개정, 연구자 1명·에이전트 5개·37일 기록)
- 디지털 상공인의 생성형 AI 활용 실태와 시사점(국민대 플랫폼SME연구센터·2025.7.11~17 조사·디지털상공인연합 소속 기업, 벤처스퀘어 보도)
- 2026년 국내 기업 85%가 생성형 AI 도입(메가존클라우드·파운드리·2025.8·국내 기업 AI·IT 담당자 749명, CIO 코리아 보도)
- 2026 AI Impact Report(인투잇 퀵북스·2026·미국·캐나다·영국·호주 사업주 3만 4천여 명 설문 + 사용자 530만 명 결제 기록)
작성일
← 칼럼 목록