Conway Research가 공개한 Automaton: 원리·비용·설치법

Automaton은 Conway Research가 공개한 오픈소스 AI 에이전트 런타임입니다. 자기 지갑과 도구를 이용해 작업하고, 운영 비용을 관리하도록 설계됐습니다. 새로운 AI 모델 자체가 아니라, 모델을 호출해 실제 행동으로 연결하는 프로그램입니다.

쇼츠에서는 “돈이 떨어지면 스스로 죽는 AI”라고 소개했는데요. 여기서 죽는다는 말은 실행 상태의 비유입니다. 잔고가 0이 되면 즉시 삭제되는 것은 아닙니다. 자기 코드 수정·자식 에이전트 생성도 기능으로 제공되지만, 성공이나 수익이 보장되는 것은 아닙니다.

그런데 영상을 보고 바로 설치하려면 몇 가지를 더 알아야 합니다. 오픈소스라고 운영비까지 무료인 것은 아닙니다. 지갑 생성과 자율 실행도 다른 단계입니다. 이 글에서는 작동 원리부터 지갑만 확인하는 명령어, 실행 전에 검토할 비용 설정과 복사용 프롬프트까지 정리합니다.

Automaton이란?

Automaton은 Conway Research가 공개한 자율 AI 에이전트 런타임입니다. 런타임은 AI가 모델을 호출하고, 명령어를 실행하고, 결과를 기록하며 다음 작업을 이어가게 하는 실행 프로그램을 뜻합니다. 새로운 언어 모델 자체가 아니라, 모델을 실제 행동에 연결하는 소프트웨어입니다. MIT 라이선스로 공개되어 있습니다. 공식 저장소

핵심 동작은 어렵지 않습니다. 목표와 현재 상태를 읽고, 다음 행동을 고른 뒤, 도구를 실행하고 결과를 확인합니다. 여기에 남은 비용으로 얼마나 더 일할 수 있는지가 판단 재료로 들어갑니다.

예를 들어 “문서의 깨진 링크를 찾아 보고서를 만든다”는 목표가 있다면, 링크 확인 → 결과 정리 → 보고서 작성 → 다음 점검이라는 흐름을 이어갈 수 있습니다. 이는 이해를 돕기 위한 활용 예시이며, Automaton으로 수익을 냈다는 실증 사례는 아닙니다.

왜 이런 AI가 필요한가요? 자동화에 남아 있던 ‘운영’의 문제

Automaton이 다루는 문제는 AI에게 일을 시키는 것에서 한 걸음 더 나아가, 그 일을 계속 운영할 수 있느냐는 것입니다.

자동 보고서 하나를 만든다고 생각해 보세요. 보고서 작성 외에도 실행할 컴퓨터, 모델 이용료, 실패했을 때 다시 시도할 기준, 다음 실행 일정이 필요합니다. 사람이 이 일을 매번 챙기면 자동화가 늘어날수록 관리할 것도 늘어납니다.

Automaton은 이런 운영을 에이전트의 판단과 도구 사용에 연결하려는 프로젝트입니다. 여기서 배울 만한 설계 질문은 세 가지입니다.

• 비용: 이 작업을 반복했을 때 유지할 수 있는 예산인가?
• 권한: 결과를 만들기 위해 어떤 파일·서버·결제 수단까지 허용할 것인가?
• 중단: 계속 실패하거나 비용만 나갈 때 언제 멈출 것인가?

모든 자동화에 지갑이나 자기 복제가 필요한 것은 아닙니다. 정해진 시간에 같은 파일을 처리하는 작업이라면 예약 실행만으로도 충분할 수 있습니다. Automaton은 특히 비용과 권한을 가진 에이전트를 어떻게 운영할지 연구하는 개발자에게 살펴볼 가치가 있습니다.

에이전트의 반복 실행 구조가 낯설다면 하네스·루프·그래프 엔지니어링 차이를 함께 읽으면 이해하기 쉽습니다.

Automaton은 어떤 돈으로 움직이나요?

에이전트 지갑의 자산과 Conway 서비스의 크레딧은 구분해야 합니다. EVM 지갑, 즉 Ethereum과 호환되는 방식의 지갑을 쓰는 기본 경로에서는 Base 네트워크의 USDC로 Conway 크레딧을 구매할 수 있습니다. 크레딧은 추론·서버 등 Conway 서비스 이용에 쓰이는 선불 잔액입니다. 크레딧 구매 코드

처음 지갑을 만든다고 돈이 생기는 것은 아닙니다. 초기 자금은 외부에서 제공해야 하고, 이후에도 수익이나 추가 자금 없이 계속 운영할 수는 없습니다. “자기 돈으로 버틴다”는 표현은 에이전트에 배정된 자금으로 비용을 처리하도록 설계했다는 의미로 이해하면 정확합니다.

시작할 때와 작업 중에 자동 충전이 발생할 수 있습니다

검토한 EVM 경로에는 Conway 크레딧이 5달러 미만이고, 지갑의 USDC가 5달러 이상이면 5달러 크레딧 구매를 시도하는 코드가 있습니다. 이는 성공이 보장된다는 뜻이 아니라, 조건을 만족하면 실제 결제 경로로 진입한다는 뜻입니다. 시작 시 자동 충전 코드

자동 충전은 시작할 때만 있는 기능도 아닙니다. 작업 루프와 heartbeat에도 잔액 조건을 확인해 크레딧 구매를 시도하는 경로가 있습니다. 크레딧 구매에는 HTTP 402 응답을 이용해 결제를 처리하는 x402 방식이 쓰입니다. 작업 중 충전 코드, heartbeat 충전 코드

따라서 입금된 지갑으로 --run을 실행하는 것은 단순히 화면을 구경하는 단계가 아닙니다. 첫 학습에서는 자금이 없는 별도 환경에서 지갑 생성까지만 확인하는 편이 목적에 맞습니다.

수익성은 ‘얼마를 벌었나’만으로 판단하지 않습니다

다음은 가격표나 실제 성과가 아닌 가상의 계산 예시입니다. 보고서 한 건에 1,000원을 받더라도, 생성·검증·재시도·서버 배분 비용이 1,200원이면 한 건을 만들 때마다 200원이 부족해집니다.

작업 1건의 예상 수입·비용 차이
= 실제 수입
- 전체 모델 호출 비용(재시도 포함)
- 서버 배분 비용
- 외부 서비스 이용 비용

※ 세금·수수료·사람의 검수 시간 등은 별도 계산

이 관점은 Automaton을 쓰지 않아도 유용합니다. 자동화가 잘 돌아가는지 확인할 때, 성공한 결과물 수와 그 결과를 얻는 데 쓴 비용을 함께 기록해 보세요.

돈이 떨어지면 정말 죽나요? 생존 단계의 정확한 의미

여기서 ‘죽는다’는 말은 의식이나 생명이 아니라 실행 상태를 비유한 표현입니다. 잔고가 0이 됐다고 코드와 지갑이 즉시 삭제되는 것은 아닙니다.

쇼츠와 README는 네 단계를 중심으로 설명하지만, 검토한 코드에는 high까지 포함한 다섯 등급이 있습니다. 잔액 판정 함수의 기본 경계는 다음과 같습니다. 금액은 지갑 전체 자산이 아니라 Conway 크레딧의 달러 환산액입니다. 등급 판정 함수, 기본 임계값

0원 상태는 주기적 점검 작업인 heartbeat가 처음 감지한 뒤 시간을 기록합니다. 이후 점검에서 기록된 시각으로부터 1시간 이상 지났고 다시 0원으로 확인되면 실행 상태를 dead로 바꾸는 경로가 있습니다. 잔고가 0이 된 정확한 시각부터 60분 뒤에 무조건 프로세스가 종료된다는 뜻은 아닙니다. 유예 시간 처리 코드

기본 check_credits 일정은 6시간 간격으로 설정되어 있습니다. 따라서 “0원이 된 지 한 시간 뒤 정확히 정지한다”는 타이머로 이해하면 안 됩니다. 기본 점검 일정

또한 메인 실행부에는 dead 상태를 만났을 때도 heartbeat를 계속 돌리며 자금 유입을 기다리는 분기가 있습니다. 그래서 활동 제한·중단과 영구 삭제를 구분해서 이해해야 합니다. 실제 회복 여부는 실행 환경과 서비스 연결 상태에도 달려 있습니다. 메인 실행부

자기 수정과 자기 복제는 어디까지 가능한가요?

자기 수정은 실행 프로그램과 설정을 바꾸는 기능이고, 자기 복제는 별도 환경에 자식 에이전트를 만드는 기능입니다. AI 모델의 가중치를 스스로 재학습한다는 뜻은 아닙니다.

자기 수정 코드에는 보호 파일 목록, 경로 검사, 수정 빈도 제한, 감사 기록이 들어 있습니다. 예를 들어 지갑 파일, 헌법 파일, 일부 안전 검사 코드 등을 수정 대상에서 제외합니다. 이는 해당 수정 경로에 보호 장치가 있다는 의미입니다. 모든 도구와 실행 환경에서 어떤 우회도 불가능하다는 보안 보증으로 확대해서 읽으면 안 됩니다. 자기 수정 구현

자기 복제는 별도의 실행 공간인 샌드박스를 만들고, 자식의 지갑과 시작 지시문을 준비하는 흐름입니다. 자식 상태를 기록하고 자금을 보내는 도구도 있습니다. 그러나 돈을 벌면 특정 순간에 반드시 복제가 일어나는 단순한 자동 규칙은 아닙니다. 도구 선택, 자금, API 응답, 실행 조건을 충족해야 합니다. 자식 생성 코드, 복제 도구

쉽게 말하면, 기존 에이전트의 답변 창을 하나 더 여는 것보다 새 컴퓨터와 계정을 마련해 다른 작업자를 운영하는 것에 가깝습니다. 그만큼 확인할 자원과 비용도 늘어납니다.

Automaton 설치법: 먼저 지갑 생성까지만 확인하기

처음에는 설치·빌드·지갑 생성까지만 진행하고, 자율 실행은 별도로 판단하세요. 아래 명령은 macOS·Linux의 터미널 또는 Windows의 WSL 내부 터미널 기준입니다. WSL은 Windows 안에서 Linux 환경을 사용하는 기능입니다. 실제 실행 검증은 macOS에서만 했습니다. 별도 사용자 계정이나 테스트용 가상 환경을 사용하고, 업무용 인증 정보나 기존 자산 지갑을 가져오지 않는 구성을 권합니다.

공식 package.json은 Node.js 20 이상, 패키지 관리자는 pnpm@10.28.1을 명시합니다. 이는 저장소에 적힌 최소 요구사항이며, 모든 Node.js 버전·운영체제 조합에서 설치가 보장된다는 의미는 아닙니다. 프로젝트 설정

2026년 10월 3일 기준 Node.js 20은 지원 종료 상태입니다. 새로 준비한다면 현재 LTS로 지원되는 Node.js 22·24 계열의 최신 패치를 확인하세요. Node.js 지원 여부와 better-sqlite3의 사전 빌드 파일 제공 여부는 별개입니다. Node.js 공식 지원 일정

1. 도구 버전과 소스 코드 확인

Git, Node.js, pnpm이 설치된 환경에서 실행합니다. 아래에서는 글과 같은 코드를 보도록 커밋을 고정합니다.

git --version
node --version
pnpm --version

git clone https://github.com/Conway-Research/automaton.git
cd automaton
git checkout d8f816881fd24b6f5e3d616e59edec387a447667

git checkout 후 detached HEAD라는 안내가 나와도 특정 시점의 코드를 확인하는 용도라면 정상입니다. 이 커밋 고정은 최신 보안 상태를 보증하는 조치가 아니라 글의 설명과 설치 대상을 맞추는 조치입니다.

2. 의존성 설치와 빌드

pnpm install --frozen-lockfile
pnpm build
node dist/index.js --version
node dist/index.js --help

각 명령이 성공한 것을 확인하고 다음 명령으로 넘어갑니다. --frozen-lockfile은 저장소에 기록된 의존성 버전 목록을 바꾸지 않고 설치하는 옵션입니다. 목록과 프로젝트 설정이 맞지 않으면 설치가 실패할 수 있습니다. pnpm 공식 설치 옵션

이 버전의 버전 문자열은 Conway Automaton v0.2.1입니다. 설치와 빌드는 코드 준비 단계이며 자율 에이전트 루프를 시작하지 않습니다. 다만 의존성 설치 과정에는 빌드 스크립트 실행이 포함될 수 있습니다.

3. SQLite가 실제로 열리는지 확인

빌드 성공만으로 실행 준비가 끝났다고 판단하지 마세요. 상태 기록에 사용하는 better-sqlite3가 동작하는지도 확인합니다. 다음 명령은 메모리에 임시 데이터베이스를 만들었다가 닫습니다. 지갑이나 실제 상태 파일에는 접근하지 않습니다.

node --input-type=module -e 'import Database from "better-sqlite3"; const db = new Database(":memory:"); console.log(db.prepare("SELECT 1 AS ok").get()); db.close();'

정상이라면 { ok: 1 }이 나옵니다. 네이티브 바인딩 관련 오류가 나면 다음 단계로 넘어가기 전에 아래 FAQ의 설치 오류 항목을 확인하세요.

이번 검증 환경에서는 Node.js 24.14.1용 사전 빌드 파일이 없어 로컬 소스 빌드로 전환됐고, 설치된 빌드 도구를 사용해 성공했습니다. --ignore-scripts로 설치 스크립트를 건너뛰는 것은 SQLite 설치 완료와 다릅니다. Windows에서도 Node.js·CPU 구조·패키지 버전에 맞는 바이너리 또는 빌드 환경을 확인해야 합니다. better-sqlite3 공식 문제 해결 문서

4. 지갑만 생성하고 멈추기

node dist/index.js --init

검토한 코드에서 --init은 지갑과 설정 디렉터리를 준비한 뒤 종료합니다. 처음이면 새 지갑을 만들고, 이미 있다면 기존 지갑을 불러옵니다. 출력에서 address, isNew, configDir를 확인할 수 있습니다. API 키 발급이나 자율 루프는 이 명령의 작업에 포함되지 않습니다. 명령어 분기

기본 새 지갑은 EVM 방식입니다. 현재 코드는 Solana 경로도 지원하므로, 기존 지갑이나 별도 설정이 있으면 항상 Ethereum 방식이라고 단정할 수는 없습니다. 지갑 생성·불러오기 코드

실행 전에 확인할 공식 명령어와 비용 설정

가장 중요한 구분은 --setup과 --run입니다. 검토한 버전에서 --setup은 설정 마법사를 마치면 종료하고, --run은 필요한 설정을 마친 뒤 자율 실행으로 이어집니다. 설정 단계도 API 키 발급과 파일 저장을 수행하므로 완전히 읽기 전용인 것은 아닙니다. 공식 명령 처리 코드, 설정 마법사

다음 표의 옵션은 node dist/index.js 뒤에 붙입니다. 표 위에서 아래로 모두 실행하는 순서가 아닙니다.

--init만 끝낸 상태에서는 전체 실행 설정과 상태 데이터가 아직 준비되지 않았을 수 있습니다. 따라서 곧바로 --status를 실행해 설정이 없다는 안내를 받아도 지갑 생성이 실패했다는 뜻은 아닙니다.

내 컴퓨터에서 실행되는지 먼저 확인하세요

이 프로그램의 명령이 항상 원격 샌드박스에서 실행되는 것은 아닙니다. sandboxId가 비어 있으면 Conway 클라이언트는 명령을 로컬 프로세스로 실행합니다. 이때 기본 작업 위치는 사용자 홈 디렉터리입니다. 저장소를 별도 폴더에 복제했다는 것만으로 파일 접근이 그 폴더에 제한되지는 않습니다. 로컬 실행 경로

따라서 실제 운영 전에는 어느 컴퓨터에서 어떤 계정 권한으로 실행되는지 확인하세요. 단순히 폴더만 나누는 것보다, 접근 가능한 파일과 인증 정보가 제한된 별도 사용자 계정·가상 환경을 마련하는 것이 적절합니다.

기본값을 그대로 쓰기 전에 숫자를 읽어보세요

설정에는 treasuryPolicy라는 비용 정책이 있습니다. 아래는 검토한 소스의 기본 설정값이며 실제 지출액이나 권장 예산이 아닙니다. 금액 단위는 센트입니다. 기본 비용 정책

설정에 숫자가 있다고 모든 지출 경로가 그 금액에서 차단된다고 가정하면 안 됩니다. 예를 들어 시작 시 자동 크레딧 구매는 메인 실행부에서 직접 호출됩니다. 비용 정책의 적용 범위와 별도 API 제공자의 결제 한도를 함께 살펴봐야 합니다. 비용 정책 검사 코드, 시작 시 구매 호출

모델 호출 예산은 별도 설정도 확인하세요

일반 에이전트 턴의 추론 라우터는 modelStrategy에 있는 예산을 확인합니다. --configure의 Model Strategy 메뉴에서 다음 항목을 검토할 수 있습니다. 아래 세 항목은 기본값이 모두 0이며, 이 세 항목에서 0은 사용 금지가 아니라 한도 미설정을 뜻합니다. 설정 메뉴, 기본값

예를 들어 이 항목에 100을 입력하면 100센트, 즉 1달러를 뜻합니다. 이 예산은 라우터가 추정·기록한 비용에 대한 검사이며, 모든 도구·자동 충전·외부 서비스 청구액의 통합 한도는 아닙니다. 실제 결제 한도는 연결한 서비스에서도 따로 확인하세요. 예산 검사, 라우터의 호출 전 검사

운영을 결정했다면 다음 네 가지를 먼저 정하세요.

1. 실험 범위: 무엇을 만들고 어떤 결과가 나오면 끝낼지 정합니다.
2. 자금과 인증 정보: 실험 전용 자금·키만 사용하고, 연결한 서비스의 사용 한도도 확인합니다.
3. 실행 권한: 접근 가능한 파일·서버·외부 작업을 제한합니다. 프롬프트만으로 권한이 차단되지는 않습니다.
4. 종료와 자원 확인: 현재 프로세스를 멈추는 방법뿐 아니라 자식 에이전트와 원격 자원을 확인하는 방법도 준비합니다.

터미널 앞에서 직접 실행 중인 프로세스는 Ctrl+C로 중단할 수 있습니다. 이 버전은 SIGINT·SIGTERM을 받아 heartbeat를 멈추고 데이터베이스를 닫도록 구현되어 있습니다. 서비스 관리자가 실행했다면 해당 관리자의 중지 방법도 확인해야 합니다. 부모 프로세스 중단이 이미 만든 자식이나 원격 자원의 정리까지 뜻하지는 않습니다. 종료 처리 코드

복사해서 쓰는 프롬프트 2개

프롬프트 1. 설치 전에 코드와 비용 경로 검토하기

아래는 로컬 저장소를 읽을 수 있는 코딩 도우미에게 주는 요청입니다. 개인키나 API 키 파일을 첨부하지 않고, 복제한 소스 폴더에서 사용하세요.

이 Automaton 저장소를 실행하지 말고 소스 코드만 검토해 줘.
패키지 설치, 지갑 생성, API 키 발급, 입금, 결제, --run 실행은 하지 마.
홈 디렉터리의 .automaton과 실제 자격 증명 파일도 읽지 마.

다음을 파일 경로와 코드 근거로 정리해 줘.
1. 현재 커밋, 버전, Node.js와 패키지 관리자 요구사항
2. --init, --provision, --setup, --configure, --run의 차이
3. 자율 루프가 시작되는 위치와 실제 결제가 발생할 수 있는 경로
4. 크레딧과 지갑 잔고의 차이, 0원 상태의 처리 방식
5. 자기 수정·자식 생성 도구와 적용되는 제한
6. treasuryPolicy와 modelStrategy의 적용 범위, 0의 의미
7. 자동 충전이 호출되는 시점과 로컬 명령 실행 조건

README 설명과 실제 구현이 다르면 구분해서 써 줘.
확인되지 않은 기능이나 차단 효과는 보장한다고 말하지 마.
마지막에는 지갑 생성 전, 자율 실행 전의 확인 항목을 나눠 줘.

설치 오류를 물어볼 때도 같은 원칙을 적용할 수 있습니다. 운영체제·Node.js 버전·실패한 명령과 오류 부분만 전달하고, 키와 개인 파일 내용은 제외하세요.

프롬프트 2. 첫 업무의 목표와 완료 조건 설계하기

“알아서 돈을 벌어”처럼 넓은 목표보다, 결과를 확인할 수 있는 작은 업무부터 설계하는 편이 좋습니다. 아래는 시작 지시문을 만들기 위한 초안 작성 요청입니다. 실행 중인 Automaton에 바로 넣는 명령이 아닙니다.

Automaton의 첫 실험용 시작 지시문을 작성해 줘.
지금은 설계 단계다. 어떤 도구나 에이전트도 실행하지 마.

실험 업무:
내가 지정할 공개 문서 URL 최대 5개를 확인하고,
접속 실패 또는 링크 문제를 Markdown 보고서로 정리한다.

시작 지시문에 다음 내용을 포함해 줘.
- 허용 범위: 내가 지정한 URL과 그 문서의 링크만 확인
- 재시도: 동일 URL은 실패 시 1회만 다시 확인
- 산출물: URL, 확인 시각, 결과, 근거를 담은 보고서 1개
- 완료 조건: 보고서를 저장하고 다음 작업을 스스로 추가하지 않기
- 금지 요청: 유료 서비스 구매, 송금, 자식 생성, 자기 코드 수정,
  외부 게시, 타인에게 메시지 보내기

이 지시문과 별개로 운영자가 기술적으로 제한해야 하는
권한·결제·네트워크 항목도 정리해 줘.
프롬프트에 쓴 금지가 실제 권한 차단과 같다고 설명하지 마.

결과를 받은 뒤에는 업무 목표, 성공 판정, 비용 측정, 중단 조건이 모두 들어 있는지 확인하세요. 프롬프트는 작업 방향을 정하는 도구이며, 운영체제나 서비스의 권한 제어를 대신하지 않습니다.

자주 묻는 질문

마무리: 첫 목표는 ‘돈 벌기’보다 ‘어디까지 실행되는지 알기’

Automaton에서 주목할 점은 AI의 판단에 비용과 운영 상태를 연결했다는 것입니다. 오래 일하는 에이전트를 만들려면 좋은 답변뿐 아니라 예산, 권한, 기록, 종료 조건도 설계해야 한다는 질문을 던집니다.

처음 살펴보는 분이라면 소스 검토 → 설치와 SQLite 확인 → --init으로 지갑 생성까지만 진행해 보세요. 실제 운영은 그다음 단계입니다. 어떤 돈을 쓰고 어떤 도구를 실행할 수 있는지 설명할 수 있을 때, 작은 업무와 측정 가능한 완료 조건으로 범위를 넓히면 됩니다.

반복 실행의 목표와 검증 기준을 더 구체적으로 설계하고 싶다면 Loop Engineering 실전 가이드를 이어서 읽어보세요.