Software 3.0 시대, 완전 자율보다 부분 자율이 먼저 설득되는 이유 | DAKER 커뮤니티

AI 제품을 만들 때 가장 먼저 떠오르는 그림은 종종 완전 자율입니다. 사람이 거의 개입하지 않아도 알아서 끝까지 처리하는 흐름이 더 미래적으로 보이기 때문입니다. 하지만 실제로는 결과를 빠르게 확인하고 바로 수정할 수 있는 구조가 더 안전하고, 데모에서도 더 설득력 있게 작동하는 경우가 많습니다.

Andrej Karpathy는 Y Combinator 강연 Software Is Changing (Again)에서 이런 변화를 Software 3.0이라고 설명합니다. 자연어 프롬프트가 프로그램이 되고 LLM이 그 프로그램을 실행하는 시대라면, 제품 설계의 중심도 완전 자동화보다 생성과 검증을 함께 돌리는 방식으로 옮겨갈 수 있습니다.

Software 3.0에서는 프롬프트가 코드처럼 동작하고, 제품은 완전 자율보다 검증이 빠른 부분 자율로 설계하는 편이 더 실용적입니다.

Software 1.0 · 2.0 · 3.0은 무엇이 다른가

Karpathy의 구분을 따르면 소프트웨어는 무엇을 프로그램으로 보느냐에 따라 세 단계로 나뉩니다. Software 1.0에서는 사람이 직접 쓴 코드가 프로그램이고, 개발자는 명시적 로직과 테스트, API를 다룹니다. Software 2.0에서는 데이터로 맞춰진 신경망 가중치가 프로그램이 되며, 개발자는 데이터와 목적함수, 학습 루프를 설계합니다. Software 3.0에서는 자연어 프롬프트가 프로그램 역할을 하고, 개발자는 문맥과 도구 연결, 생성과 검증이 이어지는 UI를 다루게 됩니다.

이미 DAKER에도 Software 2.0, 즉 목적함수 설계에 관한 글이 있습니다. 여기서는 그다음 단계인 Software 3.0 가운데서도 부분 자율 제품에 초점을 맞춥니다.

부분 자율이 중요한 이유

이 관점의 핵심은 AI가 모든 일을 대신 끝내는 구조보다, 사람이 결과를 바로 보고 판단할 수 있는 구조가 현실적이라는 점입니다. Karpathy가 말하는 Iron Man 슈트 비유도 여기에 가깝습니다. 사람 없이 일하는 로봇을 바로 만드는 것보다, 사람이 입고 능력을 확장하는 장비가 더 실용적이라는 뜻입니다.

부분 자율에서는 AI가 초안을 만들고, 사람은 그 자리에서 확인하고 수정합니다. 이때 중요한 것은 생성과 검증이 분리되지 않는다는 점입니다. 결과가 나온 화면에서 곧바로 읽고, 고치고, 다시 생성할 수 있어야 흐름이 끊기지 않습니다.

완전 자율보다 중요한 것은 AI가 만든 결과를 사람이 한 화면에서 빠르게 검수하고 수정할 수 있는 구조입니다.

autonomy slider가 제품 설계를 바꿉니다

부분 자율을 제품에 담을 때 유용한 개념이 autonomy slider입니다. AI의 개입 정도를 낮은 수준의 제안에서부터, 여러 단계를 자동으로 실행하는 수준까지 조절하는 방식입니다. 이렇게 하면 사용자는 지금 어디까지를 AI에 맡기고 있는지 이해하기 쉬워지고, 제품도 신뢰를 얻기 쉬워집니다.

Karpathy는 Cursor, Perplexity 같은 제품을 이런 방향의 예로 듭니다. 코딩이나 검색 결과를 사람이 한 화면에서 읽고, 고치고, 다시 생성하는 흐름이 자연스럽게 이어집니다. 중요한 것은 자동화의 강도가 아니라, 생성과 검증이 얼마나 매끄럽게 연결되어 있느냐입니다.

해커톤·바이브코딩에서 바로 적용하는 방법

해커톤이나 바이브코딩에서는 특히 완전 자율보다 검수 속도가 더 큰 차이를 만듭니다. 심사자나 팀원이 결과를 5초 안에 이해하고 수정할 수 있으면, 제품에 대한 신뢰가 훨씬 빠르게 올라갑니다.

그래서 데모 목표를 전부 자동으로 바꾸기보다 검수 속도로 옮겨 두는 것이 좋습니다. 예를 들어 제품 안에 개입 단계를 드러내는 슬라이더를 넣고, 제안만 하는 수준인지, 한 파일만 수정하는지, 여러 파일과 명령까지 실행하는지를 구분해 보여줄 수 있습니다.

또 생성과 검증은 같은 화면에 두는 편이 좋습니다. 생성 로그와 미리보기, 승인 버튼이 한 흐름 안에 있어야 사용자가 결과를 믿고 다음 단계로 넘어가기 쉽습니다. 에이전트가 읽기 쉬운 자료를 남기는 것도 중요합니다. 마크다운 README, 재현 가능한 API·명령, 체크리스트는 GUI 클릭 안내보다 더 안정적으로 작동합니다.

제출 전에는 사람 확인 1회를 두는 방식도 유효합니다. 스모크 테스트 URL, 샘플 입력, 실패 시 되돌리기 같은 항목을 마지막에 확인하면 데모의 안정성이 높아집니다.

코드와 학습 방식도 달라집니다

프롬프트와 도구 호출이 많아질수록, 한 번에 정답을 만드는 능력보다 틀린 답을 빨리 걸러내는 구조가 더 중요해집니다. Software 3.0에서는 생성 자체보다 검증 설계가 성과를 가르는 경우가 많습니다.

학습할 때도 마찬가지입니다. 모델 이름만 바꾸는 것보다 입력과 출력, 제약 조건, 실패 예시 같은 검증 항목을 먼저 적어 두는 습관이 더 잘 맞습니다. 이 방식은 프롬프트를 코드처럼 다루되, 결과를 항상 확인 가능한 상태로 두는 감각에 가깝습니다.

Software 3.0에서는 한 번에 맞는 답보다 틀린 답을 빨리 걸러내는 구조가 더 중요해집니다.

오늘 바로 점검해볼 순서

현재 프로토타입에서 AI가 혼자 끝내는 구간이 어디인지 먼저 표시해 보면 됩니다. 그다음 그중 한 구간만 골라 사람 승인이나 미리보기 단계를 넣어 보고, 개입 단계를 2~3단 슬라이더나 라디오 버튼으로 드러내면 흐름이 훨씬 선명해집니다. 마지막으로 데모 스크립트를 생성, 화면에서 검수, 수정, 재생성 순서로 다시 써 보면 부분 자율의 장점이 더 잘 보입니다.

참고 자료

Andrej Karpathy, Y Combinator 강연 Software Is Changing (Again)

여러분이 만든 AI 제품에서는 완전 자율보다 부분 자율이 더 설득력 있었던 순간이 있었나요?