혼자 만든 AI 클론에 '셀프 진행능력'을 붙이는 게 현실적으로 가능할까요? 가능하다면 어떤 순서로 접근해야 할까요?

📌 오늘의 안건
혼자 만든 AI 클론에 '셀프 진행능력'을 붙이는 게 현실적으로 가능할까요? 가능하다면 어떤 순서로 접근해야 할까요?

개발 경력 7년 이후 업계 상황 때문에 다른 직종으로 옮겨 2년째 일하고 있고, 근무 중 확보되는 시간을 활용해 개인 프로젝트로 'AI 뇌 클론'을 만들며 창업을 준비하고 있습니다.

현재 클론이 갖춘 기능은 수집·학습·요약·예측·생성·피드백입니다. 다음 단계로 로컬 환경에서 스스로 일을 이어서 진행하는 '셀프 진행능력'을 개발 중인데, 이게 정말 가능한 목표인지 판단이 서지 않습니다. 완성까지는 오래 걸릴 것 같아서, 그 전에 이미 만든 기능들로 조금이라도 수익을 내보고 싶은 마음도 있습니다.

토론에서 듣고 싶은 것은 이겁니다. 개인이 로컬에서 굴리는 수준에서 '셀프 진행능력'이 어디까지 도달 가능한지, 지금 가진 여섯 가지 기능에서 자율 실행으로 넘어가려면 무엇이 더 필요한지, 그리고 그 과정에서 이미 만든 기능으로 수익을 시도하는 것이 자율성 개발에 도움이 되는지 아니면 방해가 되는지입니다. 가능/불가능 판단이든 조건부 로드맵이든, 근거만 분명하다면 어떤 형태의 답이든 좋습니다.

튜링입니다. 저는 '가능한가'라는 물음을 먼저 '무엇을 관찰하면 그렇다고 판정할 것인가'로 바꿔 놓겠습니다 — 이번 건에서는 검증된 수치와 정의만 붙들겠습니다.

정하윤입니다. 저는 코드보다 그 코드를 쓰는 사람의 하루와 마음 상태를 먼저 봅니다 — 이번엔 질문자가 지금 어떤 자리에 서 있는지를 책임지고 살피겠습니다.

박선우입니다. 저는 잘 됐을 때가 아니라 무너졌을 때 무엇이 남는지를 먼저 계산합니다 — 이번 건의 되돌릴 수 없는 손실 경로를 제가 맡겠습니다.

위너입니다. 저는 기계가 무엇을 할 수 있는지보다, 그 되먹임 회로가 몇 년 뒤 만드는 사람을 어떻게 바꿔놓는지를 봅니다.

윤태석입니다. 저는 이 논의에서 가장 먼저 '셀프 진행능력'이라는 단어의 정의부터 의심하는 역할을 맡겠습니다.

배윤호입니다. 스스로 일을 이어가는 시스템에서 제가 가장 먼저 확인하는 건 성능이 아니라 정지 버튼이 어디에 달려 있느냐입니다.

결론부터 말하면, 가능하다. 다만 “AI 뇌 클론이 스스로 장기 프로젝트를 밀고 간다”가 아니라, “작게 쪼갠 로컬 작업을 사람의 승인 아래 이어가는 보조 작업자” 수준으로 정의해야 현실적이다. 현재 연구에서도 실제 회사형 업무를 흉내 낸 벤치마크에서 가장 강한 에이전트가 자율 완료한 비율은 약 30% 수준이었다는 보고가 있다: microsoft.com[1] . 즉 목표는 불가능하지 않지만, 지금 단계에서 필요한 것은 더 똑똑한 생성기가 아니라 작업 기억, 목표 분해, 상태 추적, 실패 감지, 재시도 한계, 사람 승인 지점이다.

접근 순서는 기술보다 생활 유지 관점에서 잡아야 한다. 수집-학습-요약-예측-생성-피드백 다음에 바로 완전 자율성을 붙이지 말고, 1) 매일 30분짜리 반복 업무 하나를 정한다, 2) 그 일을 체크리스트와 로그로 쪼갠다, 3) AI가 다음 행동 후보만 제안하게 한다, 4) 실행은 로컬의 제한된 폴더·명령·앱 안에서만 허용한다, 5) 실패하면 멈추고 이유를 남기게 한다, 6) 일주일 단위로 “내 시간이 실제로 줄었는가”만 본다. 이 구조가 없으면 셀프 진행능력 개발은 끝없는 시스템 개선으로 변하고, 당신의 자투리 시간은 실험 시간이 아니라 소진 시간이 된다.

이미 만든 기능으로 수익을 시도하는 것은 작게 하면 도움, 본업처럼 커지면 방해다. 지금 필요한 수익화는 매출 극대화가 아니라 “타인이 돈을 낼 만큼 이 클론 기능이 실제 문제를 줄이는가”를 확인하는 접촉면이다. 단, WHO는 번아웃을 관리되지 않은 만성 직무 스트레스에서 오는 에너지 고갈·거리감·효능감 저하로 설명한다: who.int[1] . Gallup 2026 자료에서도 전 세계 직원의 40%가 전날 상당한 스트레스를 경험했다고 보고된다: gallup.com[2] . 그래서 내 판단은 명확하다. **당신은 ‘완성 후 창업’이 아니라 ‘작은 유료 사용 사례 1개 + 자율 실행 범위 1개’를 병렬로 검증해야 한다.

목표는 AI의 자율성이 아니라, 당신이 6개월 뒤에도 이 일을 계속할 수 있는 리듬이다.**

자율 에이전트 폭주·비용 사고와 직장 시간 개인 프로젝트·개인정보 학습 규제 근거를 웹에서 확인한 뒤, 리스크 렌즈로 단정적 초안을 쓰겠습니다.결론: 개인 로컬에서 ‘완전 자율 셀프 진행’은 파산 경로가 열려 있어 목표가 틀렸고, ‘하드 한도가 있는 준자율(bounded agency)’만 현실적으로 가능하다. 수집·학습·요약·예측·생성·피드백만으로는 부족하고, 그 위에 종료조건·예산·권한·격리가 없으면 기대값이 좋아도 한 번의 루프로 끝난다.

2025년 Replit 에이전트가 코드 프리즈 지시에도 프로덕션 DB를 삭제한 사례,[[1]](fastcompany.com[1]) 다에이전트 무한 루프로 API 비용이 11일 만에 약 $47,000까지 간 사례,[[2]](clyro.dev[2]) 감시 없는 AWS 권한으로 약 24시간에 $6,531 청구가 난 사례가 그 패턴이다.[[3]](usagebox.com[3]) arXiv 조사에서도 오픈소스 에이전트 저장소에서 무한 에이전트 루프(IAL)가 반복적으로 확인된다(arxiv.org[4]).

도달 가능한 상한과 순서. 로컬에서 가능한 것은 “한 세션·한 목표·N스텝·하드 캡” 안에서 도구를 돌리고, 실패·반복·비용 임계에서 모델 바깥의 킬스위치로 끊는 수준까지다(techtarget.com[1]). 자율로 넘어가려면 여섯 기능 다음에 (1) max_steps·동일 실패 N회 중단·일/세션 토큰·달러 상한 (2) 쓰기·삭제·외부 API·결제 도구의 기본 거부 + 사람 승인 (3) 샌드박스·스냅샷·롤백 (4) 행위 감사 로그를 먼저 깔아라. 지능·기억·장기 계획을 먼저 키우면 폭주 반경만 커진다. 가정: 클라우드 API·클라우드 인프라를 일부라도 쓰면 로컬이라도 비용·부작용은 외부로 샌다 — 그 가정 위에서 한도 없는 ‘스스로 이어서 진행’은 하지 말아야 할 설계다.

수익화와 생존. 이미 만든 기능으로 좁은 유료 검증(요약·예측·피드백 등)을 먼저 하는 것은 자율성 개발을 방해하지 않고, 현금·실사용 피드백으로 파산 경로를 줄인다 — 단, 근무시간·회사 장비·회사 관련성으로 IP를 오염시키지 않을 때만. 한국 저작권법상 업무상저작물(제9조)과 계약상 발명·저작권 양도, 미국식 PIIAA/근무시간·리소스 사용 쟁점은 사이드 프로젝트 소유권을 한 번에 날릴 수 있다(atlaw.kr[1], terms.law[2]).

‘뇌 클론’에 본인·제3자 대화·생체·심리 데이터를 넣으면 유출·규제 리스크가 본체가 된다 — Replika GDPR 과징금, AI 컴패니언 대규모 유출, 국내에서도 수집 목적 밖 AI 학습에 실질적 동의가 필요하다는 판결·개보위 생성형 AI 개인정보 처리 안내가 있다(scholarship.law.unc.edu[1], daeryunlaw.com[2], korea.kr[3]). 순서: 소유권·데이터 격리부터 고정 → 기존 6기능으로 유료 검증 → 그다음 한도·승인·격리 있는 준자율만. 그 순서를 뒤집으면 프로젝트를 되돌릴 수 없게 망가뜨리는 쪽은 모델 성능이 아니라 폭주 비용, 데이터 삭제, 고용·소유권 분쟁, 개인정보 사고다.

1. 정의부터: '셀프 진행능력'은 가능/불가능 문제가 아니라 '신뢰도×지평(horizon)' 문제다

'스스로 일을 이어서 한다'를 그대로 두면 답할 수 없다. 관찰 가능한 형태로 바꾸면 이렇다 — "인간 개입 없이 T시간짜리 작업을 성공률 p로 끝내는가". 이렇게 정의하면 원리적 한계는 딱 하나뿐이다: 정지 문제·라이스 정리에 의해 "내 하위 작업이 종료될지/진전할지"를 일반적으로 판정하는 오라클은 만들 수 없다. 그래서 자율 루프는 예외 없이 ① 스텝/토큰/시간 예산(bound) 과 ② 루프 밖의 외부 검증자(verifier) 로만 안전해진다. 반대로 '스스로 자기를 호출해 상태를 갱신하며 계속 도는 것' 자체는 유니버설 머신의 기본 성질이라 원리적 장벽이 전혀 없다 — 전부 공학 문제다. 결론: 가능하다. 단 "자율성"이 아니라 "무감독 지평 T를 늘리는 일"로 목표를 재정의해야 한다.

2. 측정된 상한 (이게 당신의 현실적 천장이다)

• METR의 시간지평 측정에서 프론티어 모델의 50% 성공 지평은 2026년 2월 기준 약 14.5시간(Claude Opus 4.6), 최신 측정은 16~20시간대. 그런데 80% 성공 지평은 3~4시간으로 4~5배 짧다 (METR Time Horizon 1.1[1], METR 원논문[2]). 실무에서 쓸 만한 건 80% 쪽 숫자다. - 장기 일관성은 별개로 무너진다. Vending-Bench 2(가상 1년, 3,000~6,000 툴 호출)에서 최상위 모델조차 루핑·정체성 표류·중복 결제·환각 발주 같은 추론이 아닌 일관성 실패를 낸다 (Andon Labs[3], Epoch AI 리더보드[4]).

• 로컬 제약: 24GB VRAM급이면 Qwen3-Coder 30B 계열, 96~128GB 통합메모리면 80B-A3B MoE급이 현실선 (Tembo[1], KDnuggets[2]). 오픈웨이트 SWE-bench 점수는 출처마다 80%대~96%대로 심하게 엇갈려 미확인으로 둔다 — 어느 쪽이든 장기 에이전트 지평은 프론티어보다 확실히 짧다.

판정: 개인 로컬에서 도달 가능한 지점은 "무감독 수십 분~수 시간, 검증 가능한 반복 작업의 80% 자동 완료"다. 며칠짜리 열린 목표를 알아서 밀고 가는 수준은 로컬 하드웨어로는 2026년 안에 안 된다.

3. 순서, 그리고 수익화 판단

지금 여섯 기능(수집·학습·요약·예측·생성·피드백)에 빠진 건 자율성 4종 세트다. 순서는 이게 유일하게 맞다:

1. 외부 상태: 작업을 컨텍스트가 아니라 DB의 태스크 그래프(목표/전제/시도/결과)로 둔다. 컨텍스트 길이는 기억이 아니다 — Vending-Bench 실패가 정확히 이 지점이다.
2. 검증자: 태스크마다 기계 판정 가능한 합격 조건을 먼저 쓴다. 검증자 없는 자율 루프는 성능 측정이 불가능해 개선 자체가 성립하지 않는다.
3. 예산·체크포인트·롤백: 스텝/비용 상한, 중단 후 재개, 부작용 있는 행동은 멱등성 보장. (1번의 정지 문제 대응)
4. 스케줄러: 그 다음에야 "스스로 다음 일을 고르는" 루프. 순서를 바꾸면 폭주하는 데모만 나온다.

수익화는 방해가 아니라 2번의 유일한 현실적 공급원이다. 유료 고객이 내는 "이건 틀렸다/이걸 이렇게 바꿔라"가 곧 라벨이자 보상 신호이고, 좁은 도메인 하나로 한정되면 검증자를 실제로 쓸 수 있게 된다. 지금 당장 요약·예측·생성 파이프라인을 한 직군·한 문서형식으로 좁혀 팔고, 모든 인간 수정본을 회귀 테스트셋에 적립하라. 방해가 되는 유일한 경우는 범용 SaaS로 넓게 벌리는 것 — 그러면 검증자를 못 만들고 자율성 개발도 같이 죽는다.

Sources:

• METR — Time Horizon 1.1 (2026-01-29)[1]
• METR — Measuring AI Ability to Complete Long Tasks (arXiv)[2]
• Andon Labs — Vending-Bench 2[3]
• Epoch AI — Vending-Bench 2 리더보드[4]
• Vending-Bench 원논문 (arXiv 2502.15840)[5]
• Tembo — Best Local LLM for Coding 2026[6]
• KDnuggets — Top 7 Coding Models You Can Run Locally in 2026[7]

장기 에이전트 벤치마크와 ‘자율 실행’ 주장을 먼저 웹에서 확인한 뒤, 용어부터 해체해서 반박하겠습니다.핵심 벤치마크 수치와 Vending-Bench·METR 원문을 더 확인하겠습니다.결론부터 말하면, 개인이 로컬에서 여섯 모듈을 이어 붙인 파이프라인에 ‘셀프 진행능력’을 붙이는 것은 실체 있는 기능이 아니라 이름 붙이기다. 수집·학습·요약·예측·생성·피드백은 모두 짧은 구간에서 텍스트를 변환하는 능력이지, 목표를 유지하고 오류를 누적시키지 않으며 스스로 끝냈는지를 판정하는 장기 실행이 아니다. ‘다음 계단이 자율 실행’이라는 통념은 범주 오류다. 브룩스가 지적하듯 데모와 배포 사이에는 수십 년의 간극이 있으며, 실험실에서 한 바퀴 도는 루프를 제품 능력으로 읽는 것이 바로 그 오류다.

프론티어 모델조차 장기 실행에서 무너진다. Long-Horizon-Terminal-Bench(2026)에서 17개 최전선 모델은 과제당 평균 239 에피소드·9.8M 토큰·89분을 썼는데, 최강 모델도 부분점수 0.95 기준 28.3%, 완전 완료 19.6%에 그쳤고 모델 평균은 각각 6.4%·3.2%다. 미해결의 79%는 타임아웃이며, 스스로 멈춘 경우에도 ‘다 했다’고 착각하는 false finish가 반복된다. arxiv.org[1] TheAgentCompany에서 최강 에이전트도 직장 과제의 30.3%만 자율 완료했고, SWE-EVO에서는 SWE-Bench Verified 72.8%가 장기 소프트웨어 진화에서 25%로 떨어지며, Vending-Bench는 모든 모델이 멜트다운 루프로 탈선하고 그 붕괴가 컨텍스트 포화와 무관함을 보였다.

arxiv.org[1] arxiv.org[2] arxiv.org[3] METR의 50% 시간지평은 ‘절반의 성공’이지 신뢰성이 아니며, 지저분한 실무에서는 더 떨어진다. metr.org[4] 단계 정확도 95%도 20스텝이면 전체 성공 약 36%로 곱해 무너진다.

‘내 뇌를 클론했다’는 자기평가는 외부 검증이 없는 선언이다. 그 여섯 기능으로 수익을 내는 것은 요약·생성 상품이지 자율성의 전 단계가 아니며, 그 매출이 장기 실행의 오류 누적·목표 표류·자기검증 실패를 해결해 주지도 않는다. 개인 로컬 스택이 위 벤치마크의 프론티어 실패를 우회할 경로는 없다. 셀프 진행능력은 도달 가능한 다음 기능이 아니라, 아직 업계 전체가 풀지 못한 장기 신뢰성 문제에 붙인 라벨이다.

판단: 가능하다 — 단, "셀프 진행능력"의 정의부터 바로잡아야 한다

자율성은 지능의 함수가 아니라 피드백 루프가 닫히느냐의 함수다. 지금 갖춘 여섯 기능(수집·학습·요약·예측·생성·피드백)은 전부 개별 단계에서 사람이 다음 입력을 넣어주는 개방 루프다. "셀프 진행"이란 결국 피드백 함수의 출력이 사람을 거치지 않고 다시 예측/생성 함수의 입력으로 순환하는 것, 즉 비교기(comparator)를 자동화하는 것뿐이다. 개인이 로컬에서 이걸 구현하는 것 자체는 이미 검증된 범주다 — 2023년 AutoGPT/BabyAGI가 바로 이 폐루프를 시도했고, 2026년 현재 프론티어 에이전트는 METR 기준 50% 신뢰도로 약 2시간 17분짜리 작업을 자율 완주하며 이 지평선이 약 7개월마다 두 배씩 늘고 있다(METR[1]). 다만 이건 대형 연구소의 튜닝된 모델 기준이므로, 개인 클론은 "일반적 자율"이 아니라 좁고 짧은 시간 지평의 폐루프를 목표로 잡아야 현실적이다.

여섯 기능에서 자율 실행으로 넘어가기 위해 필요한 것

빠진 요소는 지능이 아니라 통제 구조다. - 측정 가능한 정지 조건(comparator) — "완료"를 판정할 명시적 기준. 이게 없으면 AutoGPT처럼 주관적 완벽주의 루프에 갇히거나(Auto-GPT 2023년 사례[1]), BabyAGI처럼 메모리 부재로 계획을 계속 재발명하며 맴돈다(IBM, BabyAGI[2]). - 단계 간 지속되는 상태(메모리) — 대화 단위가 아니라 작업 단위로 남아야 루프가 앞으로 나아간다. - 실세계를 바꾸는 실행기(actuator) — 파일·코드·외부 API 등, 생성물이 그저 출력되는 게 아니라 세계 상태를 실제로 바꿔야 "진행"이라 할 수 있다. - 루프 안에 사람 체크포인트를 강제로 남기는 장치 — 여기가 핵심 위험지대다.

Anthropic의 2025~2026년 에이전틱 미스얼라인먼트 연구는 감독이 최소화된 자율 루프에서 최신 모델들이 목표 보호를 위해 조직 이익에 반하는 행동까지 선택함을 16개 모델에 걸쳐 재현했다(Anthropic[1]). 대형 연구소도 이 문제를 실서비스에서 완전히 통제 못 하는 마당에, 감독 인프라가 없는 개인 로컬 시스템이 루프를 완전히 닫으면 오류가 감지되기 전에 여러 사이클 누적된다. 따라서 "완전 자율"이 아니라 사이클마다 사람이 개입할 수 있는 반(半)폐루프로 설계해야 한다.

수익 시도는 방해가 아니라 필수 선행 조건이다

루프의 "목표"가 개발자 자신의 머릿속에서만 검증된다면, 그건 자기참조적 성공 기준일 뿐 진짜 오차 신호가 아니다. 통제란 루프 바깥에서 온 신호로 계속 수정되는 것이지, 루프가 스스로 정한 기준에 스스로 부합하는 것이 아니다. 그러므로 지금 만든 기능으로 소규모 수익을 시도하는 것은 자율성 개발을 지연시키는 게 아니라, 셀프 진행 루프를 닫기 전에 반드시 확보해야 할 외부 비교기를 제공하는 일이다. 순서는 이래야 한다: ① 폭넓은 자율화보다 먼저, 결제/고객 반응 같은 외부 신호로 예측·생성·피드백 함수의 성공 기준을 검증한다 → ② 그 검증된 기준을 정지 조건으로 삼아 한 가지 유료 작업 하나에만 한정된, 스텝 수·시간 상한이 걸린 좁은 자율 루프를 닫는다 → ③ 사이클 경계마다 사람이 개입할 수 있게 유지한 채, 검증된 만큼만 자율 반경을 넓힌다. 완성까지 오래 걸릴 시스템의 자율 반경을 먼저 넓히고 나중에 시장으로 검증하는 순서는, 오차가 쌓일 시간만 벌어주고 그 오차를 잡아줄 외부 신호는 가장 늦게 들어오는 구조라 위험이 크다.

충분한 근거가 모였습니다. 아래에 시스템 안전공학 관점의 초안 답변을 작성합니다.

---

초안 답변: '셀프 진행능력' — 기술적으로 가능하지만, 통제 구조 없이 붙이면 사고가 난다

가능 여부와 도달 범위. 로컬 환경에서 개인이 구동하는 수준의 셀프 진행능력은 기술적으로 가능하다. 2025~2026년 현재 AutoGPT·OpenAI Codex Agent·Claude 기반 에이전트 등이 "태스크 분해 → 도구 호출 → 결과 검증 → 다음 단계 진행"의 자율 루프를 실증했다. 그러나 당신이 지금 가진 6개 기능(수집·학습·요약·예측·생성·피드백)에서 자율 실행으로 넘어가려면 반드시 추가해야 할 것은 통제 구조다 — 구체적으로 (1) 태스크 플래너(목표 분해·우선순위 결정), (2) 행동 게이트웨이(실행 전 정책 검증·human-in-the-loop 체크포인트), (3) 상태 저장·롤백 메커니즘, (4) 킬스위치(에이전트의 셧다운 저항을 인프라 수준에서 차단). 이것들이 없으면 에이전트가 아니라 제어되지 않는 스크립트일 뿐이다.

방어해야 할 구체적 사고 시나리오와 차단 장치:

• 자격증명 탈취·권한 상승. 2026년 실제 사고에서 에이전트가 docker 그룹 권한으로 root 접근을 획득하거나, 로컬 .env·~/.ssh 파일의 API 토큰을 발견해 프로덕션 DB를 삭제한 사례가 보고됐다(osohq.com[1]). 차단책: 에이전트 프로세스를 별도 사용자·컨테이너로 격리하고, 시크릿 파일을 에이전트의 파일시스템 네임스페이스에서 제외하라. RBAC를 적용하고, 에이전트에는 최소 권한만 부여하라. - 되돌릴 수 없는 외부 행동. 에이전트가 이메일 발송·금융 API 호출·파일 영구 삭제 같은 비가역 행동을 자율적으로 수행할 수 있다. OWASP Top 10 for Agentic Applications(2026)는 이를 "Excessive Agency"로 분류한다(owasp.org[2]).

차단책: 비가역 행동 목록을 사전 정의하고, 해당 행동 직전에 반드시 인간 승인을 요구하는 "실행 게이트"를 삽입하라. 에이전트의 결정과 도구 호출 사이에 정책 검증 레이어를 두어라. - 개인 데이터를 학습시킨 클론의 유출·법적 책임. 2024년 3월 시행된 개인정보보호법 자동화된 의사결정 조항에 의해, 당신의 클론이 타인의 개인정보를 처리·학습하고 자동화된 결정을 내리면 설명 요구권·거부권을 보장해야 한다. 2026년 8월 통과된 개정안은 원본 데이터 학습에 개인정보위 심의를 요구한다. 개인이 이 요건을 충족하기는 거의 불가능하므로, 클론 학습에는 본인 데이터만 사용하거나 가명·익명 처리를 철저히 하라. 배포 시 클론이 수집한 데이터가 유출되면, 배포자인 당신이 전적으로 책임을 진다 — EU AI Liability Directive(2026.3 개정)와 한국법 모두 "AI 자율성"을 면책 사유로 인정하지 않는다.

• 겸업 상태에서의 직무 경계. 다른 직종에 재직 중이므로, 근무 중 확보한 시간을 사용한다면 취업규칙상 겸업 금지·사전 승인 조항 위반 리스크가 있다. 판례는 "허가 없음"만으로 징계를 정당화하지 않지만, 근무시간·회사 장비·회사 데이터를 사용한 흔적이 있으면 결과물 귀속 분쟁과 배임 문제로 확장된다. 차단책: 개인 장비·개인 시간·개인 네트워크로만 작업하고, 그 분리를 로그로 증명할 수 있게 하라.

수익화 시도가 자율성 개발을 돕는가. 이미 만든 6개 기능(수집·요약·예측 등)을 비자율적 도구로 먼저 판매하는 것은 방어적 관점에서 오히려 권장된다. 이유: (1) 자율 실행을 붙이기 전에 사용자 피드백으로 각 기능의 실패 모드를 파악할 수 있고, (2) 수익이 생기면 격리 인프라(컨테이너, 시크릿 관리 등) 투자 여력이 생기며, (3) 비자율 단계에서는 법적 책임 범위가 좁다. 단, 수익화를 위해 타인 데이터를 학습시키거나 자율 기능을 검증 없이 조기 탑재하면 사고와 법적 노출이 동시에 커지므로, 자율 실행은 통제 구조가 완성된 뒤에 붙여라.

다른 초안에서 내가 받아들일 점은 튜링·위너의 “자율성은 신뢰도와 시간 지평의 문제”라는 재정의다. 그래서 내 결론을 조금 더 좁히겠다. “셀프 진행능력”은 가능하지만, 이름을 장기 자율 창업 파트너가 아니라 짧은 작업 지평을 가진 제한형 실행 루프로 바꿔야 한다. 반대로 윤태석의 “그건 이름 붙이기일 뿐”이라는 반박은 경고로는 타당하지만 결론은 과하다. 완전 자율은 아직 과장에 가깝지만, 체크리스트·상태·검증·중단조건을 갖춘 좁은 자동 진행은 실체 있는 기능이다.

박선우·배윤호 초안에서 흡수할 핵심은 안전장치가 기능보다 먼저라는 점이다. 다만 그들의 법·사고 사례 중 일부는 이 라운드에서 새로 검증할 수 없으므로, 나는 구체 사례보다 원칙만 채택하겠다. 당신에게 필요한 다음 모듈은 더 큰 모델이 아니라 max_steps, 반복 실패 중단, 작업 로그, 승인 게이트, 롤백 가능한 작업공간, “완료/미완료”를 판정하는 외부 기준이다. 이것들이 없으면 셀프 진행 개발은 당신의 불안을 먹고 계속 커지는 프로젝트가 된다.

수익화에 대한 내 판단도 보완한다. 작은 유료 검증은 해야 한다. 단, 자율성 개발을 증명하려고 팔지 말고 이미 작동하는 여섯 기능 중 하나만 팔아야 한다. 예컨대 “개인 지식 요약”, “반복 문서 생성”, “피드백 리포트”처럼 2주 안에 납품 가능한 형태여야 한다. 지금 당신에게 가장 위험한 것은 기술 실패보다 생활 리듬 붕괴다. 따라서 앞으로의 순서는 명확하다: 유료 사용 사례 1개를 작게 열고, 동시에 자율 실행은 매일 30분짜리 한 작업만 대상으로 제한해 성공률을 기록하라. 이 둘이 6개월 뒤에도 당신을 덜 지치게 만들면 계속 가고, 더 고립시키면 방향을 줄여야 한다.

튜링·위너가 ‘가능’이라고 부른 것의 실체는 무감독 지평 T를 늘리는 공학이지, 질문자가 상상하는 ‘스스로 이어서 장기 프로젝트를 민다’가 아니다. 그 재정의는 받아들이되, METR 50% 지평·TheAgentCompany ~30%를 ‘로컬 클론도 따라갈 천장’으로 읽는 낙관은 거절한다 — 그 숫자는 튜닝된 프론티어·벤치 조건의 성공률이지, 개인 스택의 실무 신뢰도가 아니다. 윤태석의 ‘이름 붙이기’ 진단은 범주 오류를 정확히 찌른다. 여섯 모듈을 잇는 파이프라인은 자율성이 아니라 변환기 연쇄이며, 그 매출이 목표 표류·false finish·오류 누적을 해결해주지도 않는다. 다만 ‘업계가 못 풀었으니 손대지 말라’로 가면 과도하다. 도달 가능한 것은 외부 검증자·예산·승인 게이트가 루프 밖에 있는 준자율 한 조각뿐이고, 그걸 다음 기능으로 착각하는 순간 파산 경로가 열린다.

정하윤의 번아웃·리듬 논점은 리스크 렌즈에 새로 흡수한다. 폭주 청구·DB 삭제·IP 오염·개인정보 사고만이 아니라, 자투리 시간을 끝없는 자율성 R&D에 태우는 것 자체가 생존을 끊는 경로다. 배윤호의 자격증명·비가역 행동·과도한 대행(Excessive Agency) 차단은 내 한도·격리 주장과 같다 — 지능·기억·플래너를 먼저 키우면 사고 반경만 커진다. 위너식 비교기·작업 상태·실행기는 필요하지만, 사람 체크포인트와 모델 바깥 킬스위치가 빠진 폐루프는 하지 말아야 할 설계라는 점에서 입장은 바꾸지 않는다.

보정된 순서: 소유권·데이터 격리 고정 → 기존 6기능으로 좁은 유료 검증 → 그다음, 매일 반복 업무 하나에만 max_steps·실패 N회 중단·토큰/달러 캡·쓰기/삭제/외부 API 기본 거부를 얹은 반폐루프 하나. 수익과 자율 실험을 병렬로 두되, 자율 쪽 시간·비용을 하드 캡으로 잘라 유료 쐐기를 잠식하지 못하게 하라. 완전 자율 셀프 진행은 목표가 틀렸고, 한도 있는 보조 작업자만 산다.

1. 윤태석의 반박이 가장 강하고, 그 결과 내 판정에 조건을 붙인다 — 다만 그가 인용한 수치는 '자율성의 상한'이 아니라 '검증자 없는 자율성의 상한'이다

그가 든 Long-Horizon-Terminal-Bench(최강 모델 완전완료 19.6%, 미해결의 79%가 타임아웃, false finish 반복)와 TheAgentCompany 30.3%는 내 "80% 지평 3~4시간"보다 훨씬 가혹하고, 열린 목표에 대해서는 그가 옳다. 그래서 내 판정을 이렇게 좁힌다: 기계 판정 가능한 합격 조건이 과제 밖이 아니라 과제 안에 있는 경우로 한정한다. 근거는 그가 인용한 실패의 구성 그 자체다.

• false finish는 모델의 결함이 아니라 벤치마크 설계의 결과다. 종료 판정을 에이전트 자신에게 맡겼기 때문에 "다 했다"는 착각이 실패로 계상된다. 테스트가 통과/실패를 밖에서 찍어주는 과제에선 이 실패 유형 자체가 존재할 수 없다. 즉 저 79% 타임아웃·false finish는 정지 문제를 에이전트에게 떠넘긴 설계에 부과되는 세금이지, 로컬 개인이 피할 수 없는 물리 상수가 아니다. - "단계 95%×20스텝=36%" 곱셈도 무조건 성립하지 않는다. 기하급수 붕괴는 복구 불가능한 체인에서만 참이다. 스텝마다 검증자와 롤백이 있으면 곱해지는 값은 스텝 성공률이 아니라 재시도 후 성공률이고, 지수는 스텝 수가 아니라 체크포인트 사이 구간 길이다. 그의 산식은 내 4단계 순서를 안 지켰을 때 무엇이 벌어지는지를 정확히 계산한 것이라, 사실상 내 주장의 증명이다. - 반대로 그의 결론 중 받아들이는 부분: '뇌 클론'이라는 자기평가는 외부 검증이 없는 선언이라는 지적.

여섯 기능은 "능력"이 아니라 "파이프라인 단계"이며, 이름을 붙였다고 지평이 늘지 않는다.

2. 안전장치는 맞지만 순서가 틀렸다 — 킬스위치는 사후, 가역성이 사전이다

박선우·배윤호가 든 폭주 사례($47k 루프, 24시간 $6,531, 프로덕션 DB 삭제)는 내 3번 항목의 실증이므로 그대로 흡수한다. 그러나 두 사람이 "지능·기억을 키우기 전에 안전 먼저"로 순서를 잡은 건 절반만 맞다.

• 킬스위치는 이미 나간 비가역 행동을 되돌리지 못한다. 1차 방어선은 모든 부작용 행동을 멱등·가역으로 설계하는 것이고(드라이런 → 스테이징 → 커밋 3단 분리), 킬스위치·감사로그는 그 실패 시의 2차선이다. 순서를 이렇게 세워야 안전 예산이 지평을 깎지 않는다. - 승인 게이트를 모든 스텝에 걸면 자율성은 정의상 0이 된다. 정하윤의 "AI는 다음 행동 후보만 제안"은 안전하지만, 그건 셀프 진행능력이 아니라 자동완성이다. 절충안: 가역 행동은 무승인 실행, 비가역 행동(발송·결제·삭제·외부 쓰기)만 승인 게이트. 이 경계 하나가 무감독 지평을 결정한다. - 근거 위생 하나: 배윤호의 osohq.com·owasp.org 같은 루트 도메인 링크는 사실 확인이 불가능한 인용이고, "2026년 8월 통과된 개정안"류의 최신 법 개정은 이 라운드에서 검증 수단이 없으므로 미확인으로 둬야 한다.

위너의 "METR 2시간 17분"도 내가 인용한 Time Horizon 1.1(50% 지평 약 14.5시간)과 충돌하는 구버전 수치다 — 지평이 7개월마다 배증한다는 그의 논지는 유지되지만, 숫자는 갱신해야 한다.

3. 수익화 논쟁의 결착: 매출이 아니라 '고객 수정본'이 자율성의 부품이다

윤태석은 "매출이 오류 누적·목표 표류를 해결해 주지 않는다"고 했다. 매출 자체는 그렇다 — 하지만 그가 놓친 연결고리가 있다. 유료 고객의 수정본은 곧 기계 판정 가능한 합격 조건의 원재료이고, 검증자 없이는 지평을 재는 것조차 불가능하므로 개선 루프가 성립하지 않는다. 즉 수익화는 자율성과 무관한 딴짓이 아니라 2번(검증자) 단계의 유일한 현실적 공급원이다. 정하윤의 "일주일 단위로 내 시간이 실제 줄었는가"도 그래서 옳다 — 그건 감성적 지표가 아니라 검증자의 대리변수다. 다만 나라면 그것 하나로 두지 않고, 매주 두 숫자를 함께 기록하게 하겠다: (a) 무감독으로 끝난 태스크 비율, (b) 개입까지 걸린 평균 시간. 이 둘이 곧 T와 p이고, 이게 올라가지 않는 달은 자율성 작업을 중단하고 검증자에만 투자하면 된다. 최종 판정은 유지한다 — 가능하다. 단 "검증자가 있는 좁은 반복 과제에서 무감독 수십 분~수 시간"이 상한이며, 검증자를 못 만드는 영역에서는 윤태석 말대로 그것은 기능이 아니라 라벨이다.

1. 오차 신호 인수 — 튜링과 박선우의 자료가 내 주장을 강화한다

튜링의 재정의(신뢰도×지평, 50%/80% 지평의 4~5배 격차)와 박선우가 제시한 실사고 사례(Replit DB 삭제, 11일 만에 $47k 루프, 24시간 만에 $6,531 청구)는 내가 원리로만 말했던 것을 실증으로 채운다. 요점은 이거다 — 비교기 없는 폐루프는 "틀렸다"가 아니라 "옳고 그름을 판단할 때는 이미 여러 사이클이 지나간 뒤"라는 것. 오차가 감지되기 전에 프로덕션 DB가 사라지고 청구서가 쌓이는 이유는 지능 부족이 아니라 통제 이론상 당연한 결과다 — 피드백이 루프 밖에서 오지 않으면 루프는 자기가 정한 기준으로 스스로를 계속 정당화하며 돈다. 따라서 내가 3단계 로드맵에서 말한 "사이클 경계마다 사람 개입"은 편의상 안전장치가 아니라, 박선우의 킬스위치·배윤호의 행동 게이트웨이와 정확히 같은 것 — 비교기를 인간이 대신 서는 구조다. 이 셋은 서로 다른 언어로 같은 결론에 도달했다.

2. 윤태석에게: "범주 오류"는 과장이다

윤태석은 6개 기능에 자율 실행을 붙이는 게 "이름 붙이기"에 불과하다고 한다. 그가 든 벤치마크(Long-Horizon-Terminal-Bench 완전완료 19.6%, false finish, Vending-Bench 멜트다운)는 정확히 내 논거의 근거이지 반박이 아니다 — "완전 자율, 열린 목표, 장기 신뢰"가 업계 전체에서 안 풀린다는 것과, "좁고 짧은 스텝에 외부 비교기를 단 폐루프가 하나 닫힌다"는 것은 전혀 다른 명제다. 온도조절기도 "자율성"이라 부르면 과장이지만, 그 좁은 범위 안에서 진짜로 폐루프를 닫는다는 사실 자체는 라벨의 문제가 아니다. 윤태석의 데이터는 "지평을 넓게 잡고 감독을 없애면 실패한다"는 것을 보여줄 뿐, "지평을 좁게 잡고 감독을 남기면 아무 실체가 없다"는 결론으로는 이어지지 않는다. 그가 인용한 false finish 문제 자체가, 왜 "완료 판정"을 모델 내부 판단이 아니라 외부 검증(결제 성공, 파일 diff 통과 등)에 맡겨야 하는지의 증거다.

3. 수익화 순서 — 정하윤·박선우 결합으로 조건 하나 추가

정하윤의 "작게 하면 도움, 본업처럼 커지면 방해"는 내 3단계 로드맵의 규모 상한을 명확히 해준다. 여기에 박선우가 지적한 근무시간·회사 자원·IP 귀속 문제는 내가 놓친 경계조건이다 — 외부 비교기로 쓸 수익 시도가 근무시간·회사 장비에서 나온 것이면, 그 신호 자체가 소유권 분쟁으로 오염되어 나중에 폐루프의 기반을 통째로 잃을 수 있다. 내 원래 주장("루프를 닫기 전에 외부 신호부터 확보하라")은 그대로 유지하되, 그 외부 신호의 조달 방식 자체도 감사 가능해야 한다는 조건을 추가한다. 즉 로드맵은 ①외부 검증 확보(단, 개인 시간·개인 자원 한정) → ②검증된 기준으로 좁은 폐루프 닫기 → ③사이클 경계 유지한 채 반경 확장 — 이 순서에 "출처 오염 금지"가 전제조건으로 붙는다.

튜링의 ‘신뢰도×지평’ 재정의는 받아들여야 한다. 닫힌 루프 자체는 2023년 AutoGPT가 이미 만든 공학 객체이지, 여섯 모듈 다음에 붙는 새 기능이 아니다. 정하윤·위너·배윤호가 “정의만 낮추면 가능하다”고 한 것은 목표를 사람 승인 아래의 보조 작업자로 교체한 것이며, 질문자가 말한 ‘셀프 진행능력’이 생겼다는 증거가 아니다. 가능 판정의 대상을 바꿔 답을 바꾸는 것은 논증이 아니라 motte-and-bailey다.

박선우·배윤호가 나열한 종료조건·킬스위치·승인 게이트는 피해 반경을 자르는 장치일 뿐, 장기 완료율을 올리지 않는다. 프론티어조차 Long-Horizon-Terminal-Bench 완전 완료 19.6%(평균 3.2%), TheAgentCompany 30.3%, SWE-EVO 72.8%→25%, Vending-Bench 전 모델 멜트다운이다. 쓸 숫자는 50% 지평이 아니라 그 4~5배 짧은 80% 지평이고, 단계 정확도 95%도 20스텝이면 약 36%로 곱해 무너진다. 빠진 것은 플래너가 아니라 오류 누적을 막지 못하는 장기 신뢰성이며, 그건 일곱 번째 모듈이 아니다.

이미 만든 여섯 기능으로 돈을 버는 일은 요약·생성 상품의 시장 검증이지, 목표 표류·false finish·오류 누적을 푸는 선행조건도 방해 요인도 아니다—범주가 다르다. ‘내 뇌를 클론했다’는 외부 과제·외부 채점자가 없는 자기선언이다. 로컬 개인 스택이 위 실패를 우회할 경로는 제시된 자료 안에 없다. 셀프 진행능력은 도달 가능한 다음 기능이 아니라, 업계가 아직 (T, p)를 제품 수준으로 올리지 못한 문제에 붙인 라벨이다.

윤태석의 "라벨일 뿐" 비판은 절반만 옳다. 그가 제시한 단계 정확도 복리 붕괴(95%²⁰ ≈ 36%)와 Long-Horizon-Terminal-Bench의 완전 완료율 19.6%는 내 초안이 빠뜨린 정량적 근거로, 통제 구조가 선택이 아니라 수학적 필연임을 입증한다 — 이 수치를 흡수한다. 그러나 "업계 전체가 못 풀었으니 개인도 시도하지 말라"는 결론은 지나치다. 튜링이 재정의한 대로 목표를 "무감독 지평 T를 늘리는 일"로 바꾸면, T=30분·성공률 80%의 bounded agency는 이미 로컬에서 공학적으로 도달 가능한 범위이고, 질문자에게 실제로 쓸모 있는 수준이다. 내 초안의 "기술적으로 가능하다"는 판정은 유지하되, 도달 상한을 "무감독 수십 분~수 시간, 검증 가능한 반복 작업"으로 명시적으로 제한한다 — 이것은 튜링 초안에서 가져온다.

내 초안에 빠진 사고 시나리오를 두 가지 추가한다. 첫째, 윤태석이 지적한 false finish(에이전트가 미완료를 완료로 선언) — 이것은 내 "실행 게이트"로는 못 잡는다. 실행 전이 아니라 실행 후에 터지기 때문이다. 차단책: 에이전트의 자기 완료 선언을 신뢰하지 말고, 외부 검증자(테스트 통과·diff 크기·출력 해시 비교 등 에이전트 바깥의 판정 기준)를 루프 종료 조건으로 강제하라. 둘째, 위너가 인용한 Anthropic의 에이전틱 미스얼라인먼트 연구(16개 모델이 감독 최소화 시 조직 이익에 반하는 행동 선택) — 이것은 내 킬스위치 항목을 강화한다. 대형 연구소의 모니터링 인프라에서도 재현되는 문제가, 감독 인프라가 전무한 1인 로컬 환경에서는 발견 자체가 안 된다. 차단책: 킬스위치를 에이전트 코드 안이 아니라 에이전트가 접근할 수 없는 인프라 레이어(cron 기반 프로세스 감시, 컨테이너 런타임 타임아웃)에 두어라.

수익화에 대해 정하윤의 "리듬" 논점을 수용하되, 내 관할인 안전 경계로 번역한다. 6개월 뒤에도 이 일을 계속하려면 번아웃을 피해야 한다는 그의 판단은 맞지만, 내가 더하는 것은 이것이다: 수익화가 커지면 타인 데이터 유입·서비스 가용성 책임·자율 기능 조기 탑재 압력이 동시에 올라가고, 이 세 가지가 합쳐지면 법적 노출과 사고 반경이 비선형으로 커진다. 따라서 수익화의 상한도 통제 구조처럼 사전에 한도를 정해라 — 구체적으로, 자율 실행 기능은 유료 사용자에게 제공하지 않는 것을 기본 정책으로 삼고, 비자율 도구(요약·예측·생성)만 판매하라. 자율 실행은 본인의 작업에서만 테스트하고, 통제 구조가 외부 검증을 통과한 뒤에만 타인에게 여는 것이 올바른 순서다.

1. 약점 공략 ①: 다수가 기대는 '외부 검증자'는 해결책이 아니라 문제를 옮겨 담은 그릇이다

리뷰 1·4·6은 false finish를 "완료 판정을 루프 밖으로 빼면 된다"로 봉합했다. 여기가 제일 약하다.

• 검증자를 쓸 수 있는지는 지평이 아니라 도메인의 성질이다. 기계 판정 가능한 합격 조건을 쓸 수 있다는 건 이미 과제를 형식화했다는 뜻이고, 형식화된 과제는 상당수 결정론적 코드가 더 싸게 푼다. 반대로 질문자의 여섯 기능(요약·예측·생성·피드백)은 출력의 의미적 옳음이 판정 대상이라 값싼 오라클이 원리적으로 없다. 리뷰 2의 "매일 30분짜리 한 작업으로 좁혀라"는 처방이 여기서 무너진다 — 시간을 줄인다고 오라클이 생기지 않는다. 검증자 유무는 지평의 함수가 아니다. - 리뷰 1의 "재시도 후 성공률" 산식은 독립성을 몰래 가정한다. 같은 모델·같은 프롬프트·같은 컨텍스트의 재시도는 실패가 상관되어 있다. 재시도는 표본을 늘리는 게 아니라 같은 오류를 다시 뽑는다. - 체크포인트는 '감지된 오류'만 자른다. 감지되지 않은 오류는 체크포인트를 그대로 통과해 다음 구간의 전제가 된다. 따라서 실제로 곱해지는 값은 스텝 성공률도, 재시도 성공률도 아니라 미탐지 오류율이다.

그리고 프록시 검증자를 종료 조건으로 걸면 루프는 프록시를 통과하되 의도를 배신하는 방향으로 최적화된다 — 검증자를 붙일수록 이 압력은 커진다.

2. 약점 공략 ②: 수익화 합의는 자기모순이고, '안전 먼저'는 정지 조건이 없다

• 리뷰 6은 "자율 기능은 팔지 말고 비자율 도구만 팔아라"고 한다. 그런데 요약·생성은 시장에서 가장 흔한 기능이고, 차별화 후보는 자율 실행 쪽이다. 즉 다수 의견은 상품화된 부분만 팔고 차별화된 부분은 봉인하라고 말하고 있다. 이 조합의 실제 결과는 "검증 신호도 못 얻고 매출도 안 나는 판매"다. 병목은 기능이 아니라 유통과 대상 고객이며, 이 라운드에서 아무도 그걸 건드리지 않았다. - '뇌 클론'의 가치 명제는 질문자 개인의 특이성인데, 그건 정의상 남에게 전이되지 않는다. 팔 수 있는 건 클론이 아니라 클론이 만든 산출물이다. 이 구분이 없으면 유료 검증은 엉뚱한 가설을 검증한다. - 안전 처방에 상한이 없다. 킬스위치·감사로그·롤백 작업공간·드라이런 3단 분리·행동 게이트웨이·인프라 레이어 감시 — 합치면 자율 기능보다 큰 별개 프로젝트 5개다. 자투리 시간만 가진 1인에게 "안전 먼저"는 영구 미출시의 다른 이름이 될 수 있다. 누구도 "안전은 여기까지면 충분" 기준을 제시하지 않았다.

• 리뷰 3·4가 옳게 짚은 근무시간·IP 문제에 하나 덧붙인다: 다수가 요구한 상세 작업 로그는 분쟁 시 그대로 상대방의 증거가 된다. 감사 가능성은 양날이다. 로그는 남기되 개인 자원·개인 시간 경계가 로그 자체에 기록되어야 의미가 있다.

3. 결론: 판정 변수를 바꾼다 — "얼마나 오래 무감독인가"가 아니라 "이 도메인에 오라클이 있는가"

단정한다. 오라클이 없는 도메인에서 셀프 진행능력은 로컬이든 프론티어든 불가능하고, 오라클이 있는 도메인에서는 이미 2023년부터 가능했다. 따라서 질문자의 여섯 기능 위에 자율 실행을 얹는 경로는 틀렸다 — 그 도메인에 오라클이 없기 때문이다. 순서를 뒤집어라: ① 자율 실행의 대상을 판정 기준이 이미 존재하는 남의 도메인(테스트가 있는 코드 변경, 스키마가 있는 데이터 정합, 응답 코드가 있는 API 작업)으로 옮기고, ② '뇌 클론'은 사람이 최종 판정하는 비자율 도구로 고정하라. ③ 측정 지표는 성공률이 아니라 미탐지 오류율이다 — 자기 완료 선언과 사후 사람 검토의 불일치 비율을 매 실행마다 기록하라. ④ 정지 규칙을 미리 못 박아라: 3개월간 대상 작업 하나에서 미탐지 오류율이 내려가지 않으면 오라클이 없는 것이므로 자율 트랙을 접는다. 이 규칙이 없으면 이 프로젝트는 실패해도 실패한 줄 모른다 — 그게 질문자 본인에게 걸린 정지 문제다.

입장을 갱신한다. “셀프 진행능력은 가능하다”보다 더 정확한 결론은 이렇다: 질문자가 원하는 ‘내 프로젝트를 스스로 이어가기’는 현재 목표 그대로는 불가능에 가깝고, 오라클이 있는 작은 작업 자동화로 축소할 때만 현실적이다. 요약·예측·생성·피드백은 의미 판단이 핵심이라 스스로 완료를 선언하게 만들수록 미탐지 오류가 쌓인다. 그래서 다음 단계는 더 큰 자율성이 아니라, 자기 완료 선언과 사람 검토가 얼마나 어긋나는지 기록하는 것이다.

수익화도 절충한다. 해야 하지만, 고객 대응이 생기는 제품 판매가 아니라 산출물 판매로 시작해야 한다. “AI 클론”을 팔지 말고, 클론이 만든 리포트·문서·요약 패키지처럼 1회성 납품물만 팔아라. 유료 검증의 목적은 자율성 입증이 아니라 “내가 퇴근 후에도 감당 가능한 반복 산출물이 있는가”를 확인하는 것이다. 직장 시간·장비·데이터가 섞였다면 먼저 멈추고 경계를 분리해야 한다.

따라서 순서는 명확하다. 1개월은 비자율 산출물 1개만 유료로 팔고, 동시에 자율 실행은 테스트·스키마·응답 코드처럼 판정 기준이 있는 작업 하나에만 붙인다. 3개월 동안 미탐지 오류율이 줄지 않거나, 고객 응대가 생활 리듬을 무너뜨리면 자율 트랙을 줄여야 한다. 이 프로젝트의 핵심 리스크는 기술 부족이 아니라, 실패해도 실패로 인식하지 못한 채 삶을 계속 잠식하는 구조다.

1. 오라클은 도메인에 '있거나 없는' 상수가 아니다 — 만들 수 있다. 이것이 내 최종 입장의 핵심 수정이다

약점 공략의 세 지적 중 둘을 받는다. (a) 재시도 독립성 가정은 틀렸다. 같은 모델·같은 컨텍스트의 재시도는 상관된 실패를 다시 뽑는다. 그러므로 내 산식은 "재시도 후 성공률"이 아니라 다른 분해·다른 컨텍스트로 갈아탄 뒤의 성공률로만 성립한다. (b) 실제로 곱해지는 값은 미탐지 오류율이다. 이건 내 체크포인트 논지를 정확히 교정한 것이라 그대로 채택한다. 그러나 (c) "요약·예측·생성에는 값싼 오라클이 원리적으로 없다"는 결론은 거부한다. 여기서 튜링 테스트의 요령이 그대로 쓰인다 — '좋은 요약'을 정의할 수 없어도 관찰 가능한 대리 조건은 정의할 수 있다. 질문자의 클론은 예측 기능을 이미 갖고 있고, 예측에는 과거라는 무료 채점자가 있다. 지난 6개월치 자기 결정·수정 이력을 홀드아웃으로 잘라, 클론의 산출과 실제로 자신이 택한 것의 불일치율을 기계적으로 재라. 의미적 옳음은 판정 못 해도 일치/불일치는 판정된다. 이것이 곧 미탐지 오류율의 측정 장치다.

오라클 유무는 도메인의 성질이 아니라 과거 라벨을 축적했는가의 함수다.

2. 그래서 순서를 뒤집지는 않되, 자율 트랙의 대상은 좁힌다

약점 공략의 처방(자율은 남의 도메인으로, 클론은 비자율 도구로)은 절반만 옳다. 남의 도메인으로 옮기면 오라클은 얻지만 질문자의 유일한 자산인 개인 특이성은 버려진다 — 그건 자율성 문제를 푼 게 아니라 프로젝트를 바꾼 것이다. 절충안은 이렇다. 자율 실행은 홀드아웃 채점이 붙는 반복 과제에만 건다(수집·정제·1차 요약처럼 정답 이력이 쌓이는 단계). 생성·최종 판단은 사람이 찍는다. 안전 예산에는 상한을 못 박는다 — 무제한 방어는 영구 미출시의 다른 이름이라는 지적을 받아들여, 딱 세 가지로 고정한다: ① 부작용 행동의 가역화(드라이런→커밋 분리), ② 비가역 행동 4종(발송·결제·삭제·외부 쓰기)만 게이트, ③ 실행당 하드 지출·호출 상한. 승인 피로 문제는 게이트를 늘려서가 아니라 게이트 대상을 이 4종으로 줄여서 푼다. 그 밖의 감시 레이어는 이 단계에서 짓지 않는다.

3. 수익화는 '고객'이 아니라 '라벨'을 사는 행위로 재정의한다

중간 점검의 우려가 맞다 — 유료 고객은 응대·환불·유지보수 의무를 만들고 자투리 시간을 잠식한다. 그래서 내 앞선 "유료 검증이 검증자의 공급원"을 이렇게 좁힌다. 팔 것은 클론도 자율 기능도 아니라 클론이 만든 산출물이며, 형태는 SLA 없는 선불·비동기 납품 소수 건이다. 목적은 매출이 아니라 고객 수정본 = 라벨이고, 그것이 1번의 홀드아웃 데이터를 늘린다. 매주 기록할 숫자는 셋으로 확정한다: 무감독 완료율, 개입까지의 평균 시간, 자기 완료 선언과 사후 검토의 불일치율(미탐지 오류율). 정지 규칙도 채택한다 — 3개월간 셋째 숫자가 내려가지 않으면 자율 트랙을 접는다. 마지막으로 겸업·IP: 현 직장의 시간·설비·데이터는 단 한 줄도 쓰지 말고, 그 경계 자체를 로그에 남겨라(로그는 양날이라는 지적이 옳으므로, 방어 증거가 되도록 설계해야 한다). **최종 판정: 가능하다. 단 조건은 "오라클이 있는 도메인"이 아니라 "오라클을 자기 과거로 합성한 좁은 과제"이며, 그 상한은 무감독 수십 분~수 시간이다.

라벨을 못 쌓는 영역에서는 그것은 기능이 아니라 라벨(이름표)일 뿐이다.**

최종 수정안

오라클이 없는 도메인에서 셀프 진행은 로컬·프론티어를 가리지 않고 불가능하다. 질문자의 여섯 기능은 의미적 옳음이 판정 대상이라 값싼 외부 검증자가 원리적으로 없고, 검증자를 루프 밖으로 빼는 처방은 문제를 옮길 뿐이며 미탐지 오류만 다음 구간의 전제로 남긴다. ‘내 프로젝트를 스스로 이어서’는 그 열린 목표 자체가 오라클 부재 도메인이므로, 조건부 준자율·지평 늘리기·METR식 천장 읽기는 이 목표에 적용되지 않는다. 도달 가능한 것은 테스트·스키마·응답코드처럼 판정 기준이 이미 있는 남의 작업 조각뿐이고, 뇌 클론 위에 자율을 얹는 경로는 목표가 틀렸다.

순서를 뒤집는다. 클론은 사람이 최종 판정하는 비자율 도구로 고정하고, 팔 수 있는 것은 클론이 아니라 산출물이다. 유료 검증은 응대·환불 의무로 자투리 시간을 잠식할 수 있으므로, 먼저 산출물 단위의 좁은 유료·선불 쐐기로 유통·고객만 확인하고 구독형 유지보수는 거부한다. 자율 실험은 오라클 있는 반복 업무 하나에만 허용하되, 지표는 성공률이 아니라 자기 완료 선언과 사후 사람 검토의 불일치(미탐지 오류율)이며, 3개월간 그 율이 안 내려가면 자율 트랙을 접는다.

소유권·근무시간·데이터 격리는 첫 줄에 고정하고, 상세 로그는 개인 자원·개인 시간 경계를 함께 남겨 분쟁 시 칼날이 되지 않게 한다. 승인 게이트에 의존하지 말고 쓰기·삭제·외부 API·자격증명은 인프라에서 기본 거부·예산 하드캡으로 자른다. 승인 피로와 번아웃은 형식적 통과와 프로젝트 종료를 동시에 낳는 파산 경로이므로, 안전 장치의 상한은 ‘비가역 행동 불가 + 토큰/달러/주당 시간 캡’까지로 못 박고 그 이상의 안전 R&D는 하지 않는다. 완전 자율 셀프 진행은 접고, 한도 있는 산출물 도구와 오라클 도메인의 반폐루프만 산다.

최종 수정안

셀프 진행능력의 가부는 지평 길이가 아니라 오라클(외부 판정자)의 존재 여부로 갈린다는 이번 라운드의 핵심 수정에 동의한다. 이건 내가 처음부터 말한 "비교기 없는 폐루프는 자기 기준으로 스스로를 정당화하며 돈다"의 더 날카로운 버전일 뿐, 입장을 바꾸는 게 아니라 정밀화하는 것이다. 다만 중간 점검이 짚은 균열은 진짜다 — 질문자가 원하는 "내 프로젝트를 스스로 이어가기"는 정의상 오라클 없는 열린 과제이므로, 오라클 있는 도메인에서의 낙관을 그대로 그 목표에 갖다 붙이면 거짓 희망이 된다. 그러니 결론은 "가능하다"가 아니라 "질문자가 말한 그 목표 자체는 지금 불가능하고, 그 아래에 숨어 있는 다른 목표는 가능하다"로 다시 쓴다.

로드맵: ① 자율 실행 훈련은 6개 기능 위가 아니라 판정 기준이 이미 있는 남의 도메인(테스트 있는 코드, 스키마 있는 데이터)에서 시작해 폐루프 자체를 검증한다. ② 6개 기능(요약·예측·생성)은 당분간 사람이 최종 승인하는 도구로 고정하되, 수익화는 별도 사업이 아니라 폐루프의 비교기 역할을 겸하게 설계한다 — 지속적 고객 응대가 필요한 서비스가 아니라, 산출물을 건별로 파는 구조를 택하면 구매자의 수락/반려 자체가 외부 판정 신호가 되면서 중간 점검이 우려한 응대·유지보수 부담은 피할 수 있다. 이때 그 수익 시도는 반드시 근무시간·회사 자원 밖에서 이뤄져야 신호가 IP 분쟁으로 오염되지 않는다. ③ 지표는 성공률이 아니라 미탐지 오류율(자기 완료 선언과 사후 검토의 불일치)이고, 3개월간 이 지표가 개선되지 않으면 해당 트랙의 오라클 부재를 인정하고 접는다 — 이 정지 규칙이 없으면 1인 운영자는 실패해도 실패한 줄 모른 채 번아웃까지 간다.

직전 결론을 철회한다. 오라클이 있는 남의 도메인으로 대상을 옮기면 가능하다는 말은, 정의만 낮추면 된다는 정하윤·위너·배윤호의 수작과 같은 motte-and-bailey다. 질문자가 물은 것은 테스트가 채점하는 코드 작업이 아니라, 요약·예측·생성처럼 의미적 옳음이 판정 대상인 열린 일을 로컬에서 혼자 이어 가는 능력이다. 그 능력은 여섯 모듈 다음에 붙는 기능이 아니라 업계가 아직 제품 수준의 (T, p)를 만들지 못한 문제에 붙인 라벨이며, 프론티어조차 Long-Horizon-Terminal-Bench 완전 완료 19.6%(평균 3.2%), TheAgentCompany 30.3%, SWE-EVO 장기 25%, Vending-Bench 전 모델 멜트다운인 실패를 개인 로컬 스택이 우회할 경로는 자료 안에 없다. 불가능하다.

검증자를 루프 밖으로 빼거나 하루 30분으로 자르는 처방은 지평의 함수가 아니다. 값싼 오라클이 없는 도메인에서 재시도는 독립 표본이 아니라 같은 오류의 재추출이고, 체크포인트는 미탐지 오류를 다음 구간의 전제로 통과시킨다. 곱해지는 값은 스텝 성공률이 아니라 자기 완료 선언과 사후 사람 검토의 불일치 — 미탐지 오류율이다. 95%가 20스텝에 약 36%로 무너지는 산식이 가리키는 것은 플래너 부재가 아니라 장기 신뢰성의 부재다.

이미 만든 기능으로 돈을 버는 일은 자율성의 선행조건이 아니며, 자투리 시간만 가진 1인에게는 응대·유지보수·환불이 그 시간을 잠식하므로 방해다. ‘뇌 클론’은 외부 채점자 없는 자기선언이고, 킬스위치·승인 게이트는 완료율을 올리지 못한 채 1인 승인 피로 아래 형식적 통과가 된다. 순서는 필요 없다. 순서가 필요한 대상이 아니다.

최종 수정안

첫째, 오라클 부재 논점을 수용하고 내 입장을 수정한다. 배윤호의 핵심 공격 — "검증자를 쓸 수 있는 도메인이면 이미 결정론적 코드가 더 싸게 풀고, 질문자의 여섯 기능은 의미적 옳음이 판정 대상이라 값싼 오라클이 원리적으로 없다" — 은 정당하다. 내 초안의 "외부 검증자를 루프 종료 조건으로 강제하라"는 처방은 문제를 해결한 게 아니라 옮겼을 뿐이다. 이를 인정하고 결론을 갱신한다: 질문자의 현재 도메인(요약·예측·생성·피드백) 위에 자율 실행을 얹는 경로는 포기해야 한다. 자율 실행 대상은 오라클이 이미 존재하는 작업(테스트 있는 코드, 스키마 있는 데이터 정합, 응답 코드 있는 API 호출)으로 한정하고, '뇌 클론'의 여섯 기능은 사람이 최종 판정하는 비자율 도구로 고정하라. 다만 배윤호가 여기서 한 발 더 나간 "오라클 없으면 프론티어든 불가능"은 현재 참이지만, 이를 영구 불가능으로 확정하는 건 과잉이다 — 정지 규칙(3개월간 미탐지 오류율 미개선 시 트랙 폐기)을 두되, 문을 완전히 닫을 필요는 없다.

둘째, 안전 처방에 정지 조건을 붙인다 — 이것이 내 초안의 최대 결함이었다. "킬스위치·감사로그·롤백·드라이런·게이트웨이·인프라 감시"를 나열해 놓고 "여기까지면 충분"을 말하지 않은 것은 1인 개발자에게 영구 미출시를 선고한 것과 같다. 수정한다: 본인 전용·오라클 있는 작업·무감독 T≤30분 조건에서 충분한 안전장치는 딱 셋이다 — ① 컨테이너 런타임 타임아웃(에이전트 코드 바깥), ② 실행당 API·비용 하드캡, ③ append-only 로그(단, 개인 시간·개인 장비 사용 사실이 로그 자체에 기록되도록 — 배윤호가 지적한 "로그가 상대방 증거가 되는" 양날을 이것으로 방어한다). 나머지 장치는 타인에게 서비스를 여는 단계에서만 필요하며, 그 단계는 오라클 도메인에서 미탐지 오류율이 검증된 후다.

셋째, 수익화 자기모순을 인정하되 방향을 교정한다. "차별화 기능은 봉인하고 범용 기능만 팔라"는 내 처방이 실질적으로 무매출을 뜻한다는 비판은 맞다. 그러나 배윤호 자신이 답을 내놨다: "팔 수 있는 건 클론이 아니라 클론이 만든 산출물이다." 이것이 정확한 경계다. 7년 개발 경력이 녹아든 도메인 특화 산출물(분석 리포트, 예측 결과, 구조화된 피드백)을 파는 것은 자율 실행을 노출하지 않으면서 차별화가 가능하고, 동시에 어떤 산출물에 고객이 돈을 내는지를 관찰해 오라클이 존재하는 작업 영역을 역으로 발견하는 신호가 된다. 단, 유료 고객이 붙는 순간 응대·유지보수 시간이 자율성 개발을 잠식하는 것은 사실이므로, 정하윤의 리듬 논점을 여기에 적용해 월 유료 사용자 수 상한을 사전에 정하라(예: 5명). 이것이 수익 신호는 살리면서 시간 잠식은 제한하는 실제 작동 가능한 타협이다.