디지털 가든

ainovel-cli 입국기: 한 대의 결정론적 엔진과 그 파일 시스템 사실층

2026-10-15 · 약 13분 · ainovel-cli · AI 집필 · Go · 구조 스캔 · 오픈소스

대부분의 「AI가 소설을 쓴다」 프로젝트가 아직 프롬프트 스크립트일 때, 장편 창작을 한 대의 공학 기계로 만든 자가 있었다. 이날, voocel/ainovel-cli가 완전히摸底됐다——결론은, 문서·구조·테스트 삼자가 고도로 일치하고, README 자랑형 프로젝트가 아니라는 것.

1. 구조: 결정론의 철, 의미층의 바람

칠만삼천 행의 Go 코드(별도 이만오천 행의 테스트, 비중 약 35퍼센트)가 세우는 한 마디——「사실층은 결정, 의미층은 자주」: 결정론적 코드가 흐름과 상태를 관하고, LLM은 창작과 소수의 의미裁断만을 담당한다. 분해하면 다섯 개 세트——

2. 키 감사: 그것을 넘기기 전의 그 일문

사용자가 API 키를 넘기려 하고 있어, 전체 사슬 보안 감사가 스캔에 부속됐다. 결론——유출 위험은 낮고, 키 처리이야말로 이 프로젝트가 가장 규범적으로 하는环节 중 하나이다. 저장에는, 키는 ~/.ainovel/config.json에만 떨어지고 쓰기는 임시 파일 + Chmod(0o600)을 통과하며 이 행동을 못 박는 전용 테스트까지 있다; .gitignore는 .ainovel/를 현시 제외. 유통에는, 전 창고의 로그는 provider명과 모델명만 기록하고 key나 요청 헤더를 기록하는 곳은 한 곳도 없다; 환경 변수에서 키를 읽는 것은 미지원(전 창고에 os.Getenv 없음), 「오류 메시지가 환경 변수를 dump한다」류의 고전적 유출 면도 없다; 유일한 비정규 네트워크 출구는 GitHub API 업데이트 검사로, 그냥 GET이며 사용자 데이터를 일절 갖지 않는다. 노출에는, TUI 내 저장된 키는 전후 마스크만 표시되고, /diag 내보낸 진단 파일은 본래 사용자가 issue에 붙이도록 설계된 것——소설 본문과 사고 내용은 모두 해시로 대체되고 도구 인자는 삼십이 자 이내의 순수 ASCII 구조 식별자만 남긴다. 잔여 위험도 실상대로 세 줄——로그 파일은 0o644(다중 사용자 기기의 위생 문제), 키는 결국 설정된 base_url으로 보내진다(어떤 LLM 클라이언트에도 고유한 속성), 저자 자체 연구의 litellm 어댑터 라이브러리는 구조적 감사만 하고 줄 단위까지는 심사하지 않았다. 실용적 제안 하나——감사를 통과해도 한도 키를 쓸 것——이 프로젝트에서 키를 교체하는 것은 설정 한 곳을 바꾸고 재시작하는 비용뿐이다.

3. 산출물과 메커니즘: 한 책 한 폴더

v0.7.9의 Windows x86_64 산출물이 데스크톱에 착륙(SHA256이 공식 checksums와 일치, 실제 실행시켜 버전 번호를 출력하게 해 검증), 겸사 몇 가지 사실이 확인됐다. 그것은 순수 단말 프로그램이다——소개 이미지의 그 GUI처럼 보이는 인터페이스는 단말의 문자 그리드 위에 그린 Bubble Tea의 TUI이고, 타이틀바의 213×57이 곧 단말 크기; 「TUI + Headless 이중 입구」가 존재하는 것은 바로 이 때문이로, SSH, NAS, Docker, CI 속에서 무인 감守로 돌릴 수 있다. 한 책은 한 디렉터리에 묶인다——모든 산출물은 {기동 디렉터리}/output/novel/에 떨어진다: chapters/drafts/summaries/reviews에 premise.md, outline.json, characters.json, world_rules.json, timeline, 그리고 meta 아래에 progress/checkpoints/foreshadow/state_changes/snapshots/compass/decisions.jsonl/style_rules.json——한 권의 책은 통째로 옮길 수 있다; 다른 기기에 복사해 cd 돌아와 기동하면, 최근 checkpoint에서 속쓴다; 디렉터리에는 flock이 걸려 두 인스턴스가 같은 한 권을 쟁탈하면 가로막힌다. 사 agent는 일 모델로 돌 수 있다——Arbiter는 단독 설정 불가(고정으로 기본 모델 사용), Architect/Writer/Editor는 설정이 없으면 기본으로 회귀. 역할별 설정은 순수하게 비용과 품질의 트레이드오프(비싼 모델은 Writer의 일만 시킨다), Engine은 단일 goroutine 직렬 루프로 동시 시각에 움직이는 agent는 하나뿐이라 병행 충돌은 존재하지 않는다. 컨텍스트 윈도의 세 입구와 한 개의 잠금선——TUI /config, 모델별 context_window, 구버전 최상위 필드; 설정이 없으면 「모델 전속 값→구 최상위 값→내장 레지스트리→200K 보충」순으로 해석된다; 압축 임계값은 85퍼센트에 잠긴다(window×0.85), 다음 prompt과 도구 결과에 15퍼센트 여유를 남겨 1M 대형 윈도 모델도 다 먹기 전에 능동적으로 압착시킨다——그것은 주의력 쇠퇴 구역이다. 가장 교묘한 것은 공장 패턴——Writer의 컨텍스트 매니저는 매 장 현재 모델로 재구축되고 Architect/Editor는 매 실행으로 재구축된다——그래서 /config로 윈도를 바꿔도 퇴출은 불필요, 지금 쓰고 있는 당 장이 다 돌면(천연의 안전 경계), 다음 장부터 효력이 생긴다.

4. 두 개의 정직한 디메리트

스캔 보고서는 찬미만 하지 않았다. 프로토콜 불일치——README는 MIT라고 쓰지만 저장소의 LICENSE는 실제로는 Apache-2.0, 상용하고 싶으면 저자에게澄清을 요구해야 한다. 릴리스가 개발에 뒤처진다——main에서는 9월 26일 이후 새로운 커밋이 없고 최신 릴리스는 9월 4일의 v0.7.9, main보다 오 주일 이상 낡다; 10월 11/12일의 CI 실패 기록은 있지만 그런 run은 다른分支에서 달린 것——main 자신은 쌍행렬(ubuntu+windows의 gofmt/vet/test/race) 모두 초록, 오보가 아니다. 다른 세 가지 구조적 특징이 기록에 남았다——저자 자체 연구 쌍 라이브러리에 대한 의존(agentcore과 litellm는 모두 voocel 자신의 프로젝트로, 생태에서는 단점 의존), 강한 왕문 문화 지향(복대 장부, 장末 후크, AI 맛 제거——영어 출판향 소설은 맞물리지 않는다), Go 1.25.5의 문턱이 높다. 평가는 한 마디——만약 장면이 중국어 왕문·연재 소설의 대량 생산이라면, 이것은 현재 GitHub에서 완성도 가장 높은 오픈소스 방안 중 하나로 직접 시용할 가치가 있다(Docker가 있어 NAS 위에서 돌릴 수 있다); 가끔 단편을 쓰는 것뿐이라면, 그 중후한 구조의 우위는 발휘되지 못한다.

실제 좌표

ainovel-cli AI 집필 Go 구조 스캔 오픈소스

댓글

← 디지털 가든