date: 2026-08-13
agent: Boss (작성) · Claude Code (기록)
mark: _Boss
type: whitepaper
status: active
related:
- 80-ai-voice-actor-whitepaper_Boss.md
- 81-helena-rvc-dubbing-standard_Claude.md
- 82-helena-rvc-baseline-lords-prayer_Grok.md
- 84-youtube-two-channel-momentum_Boss.md

AI 코어 활용 백서 (v4 · 최종 완전판)

기록 메타 (Claude Code, 2026-08-14): 이 백서는 작성일 2026-08-13 기준.
08-14에 Grok 2역할 기점(83) 과 YouTube 2채널(84) 이 확정되었으므로, §6 슬롯3(60초 숏폼)·§8 영상편집이 어느 레인(공짜 페이지 공장 vs 구독 다큐)을 말하는지는 83과 대조해 다시 확인할 것.
08-14 추가: §6 두 벡터 명시화 + 돌봄 순환 루프(빌드→배달→로컬구동→피드백) 반영 (Boss 지시, Claude 기록).
본문은 박씨(보스) 원문 그대로, 표제·프론트매터·이 메타와 §6 갱신 주석만 Claude가 붙임.

작성일: 2026-08-13
작성 목적: 개인 AI 코어(성우/가창) 활용 방향 및 폰 기반 인프라 실험 전체를 사고 흐름 포함하여 완전히 구조화 정리 — 헬레나/조카(목사)/에이전트 공유용

1. 배경 — 성우 코어의 출발점

폰 하나(구형 Galaxy S21, 헬레나 실사용 기기)로 PC 없이 지식 생태계·1인 미디어 파이프라인을 만드는 프로젝트를 먼저 진행했다. Termux → proot Ubuntu 가상 환경 위에 에이전트(Claude Code 스킨 + DeepSeek 엔진)를 심어, 음성 입력(STT)만으로 깃허브·블로그·유튜브 숏폼 자동화까지 구축했다.

이 파이프라인의 숏폼 성우 슬롯에는 원래 Edge TTS만 꽂혀 있었는데, 기계음 티가 나서 설득력이 떨어졌다. 그래서 그 자리를 갈아엎어 박씨/헬레나 본인 목소리로 RVC를 구워 넣은 것이 이 성우 코어의 출발점이다.

1-1. “폰 안에서 안 되는 것”의 첫 사례
지금까지 인프라(Termux, proot Ubuntu, 에이전트, STT)는 전부 “폰 하나로 완결”되는 것들이었다. 그런데 목소리 학습(RVC 트레이닝)만은 폰이 못 한다 — GPU 연산이 필요하기 때문이다.

1-2. 해결 구조: 베스트AI = PC방, 그리고 돌봄 데몬
- 돈 없는 사람 입장에서 GPU 클라우드(Vast.ai, “베스트AI”)를 PC방처럼 시간당 빌려 쓰는 개념으로 접근
- 헬레나 집 PC로는 연산이 안 되어, 본인 PC에서 대신 연산을 짊어짐
- 이 과정을 “돌봄 데몬(daemon)”으로 개념화 — 보호자/동생이 GPU 연산을 대신 짊어지고 결과물만 구워서 선물하는 역할

해결 3단계 원칙: ① 폰 안에서 안 되는 것 발생 → ② 돈 있으면 PC방처럼 렌탈 → ③ 돈 없으면 돌봄 데몬(보호자)이 대신 구워서 선물

2. 성우 코어 사양

• 구조: 전 세계 언어 딕션·악센트 정확한 Edge TTS(발음) + 박씨/헬레나 음색 RVC(음색)
• 구동: S21 폰에서 즉시 생산 (모바일 로컬 구동)
• 장점: 즉시성, 이동성, 확장성 / 체감 품질: 약 80%
• 상업용 트랙: 저작권 클린 필요 시 오픈소스 TTS(Piper/VITS)로 발음 소스 대체 + RVC 음색

3. 뇌과학적 근거 검토

결론: 직접 증명한 단일 논문은 없으나 세 근거를 종합하면 탄탄함. 효과가 가장 큰 지점은 “그 순간 직접 발화” — 녹음 반복 청취는 2차 강화.

4. 저작권 구분 정정

• 타인 저작물(책, 경전 번역본, 가사, 시) 낭독 판매 → 품질과 무관하게 저작권 문제로 원천 불가
• 본인 오리지널 콘텐츠(박씨 로그) → 저작권 문제 없음, 상업 활용 가능

5. 상업화 전략 정정

오디오북 판매(저작권 문제로 폐기) → 시스템을 만들고 활용하는 과정을 유튜브 강의로 판매하는 방향으로 전환. 콘텐츠(원본 대화)와 노하우(지식 상품) 모두 저작권 문제 없음.

6. 콘텐츠 레인과 벡터

콘텐츠 레인 (실증됨, 소비 벡터)

• 슬롯 1 암기 매트릭스: 콘텐츠(경전/가사/시, 고정)×언어(확장)×목소리(고정). 콘텐츠 행 고정, 언어 열만 확장.
• 슬롯 2 만담쇼: 박씨 로그(실제 즉흥 대화)에 목소리 매칭. AI가 대화를 지어내는 게 아니라 진짜 즉흥 대화에 목소리만 입히는 역발상 구조. 저작권 문제 없음.
• 슬롯 3 60초 숏폼: 유튜브 소개용 파이프라인이 목소리 결합으로 카톡 음성편지·경조사·프레젠테이션까지 확장되는 개인화 영상 메시지 포맷으로 전용됨.

돌봄 데몬 (케어 벡터)
- 헬레나 계정을 텔레그램/테일스케일 네트워크에 편입 중
- 파이프라인: 트리거 → 텍스트 → 성우 변환(RVC) → 테일스케일 전송/재생(헬레나 폰)
- 직접 개발해야 하는 유일한 부분은 성우 코어 하나뿐, 나머지(트리거 앱 등)는 쇼핑+배선
- 미실증 후보: 리마인더, 접근성, 안부체크인, 교육낭독

레인 vs 벡터

§6 갱신 (Claude 기록 · 2026-08-14 · Boss 지시): 두 벡터를 명시화하고, 돌봄 벡터를 “단방향 전송”에서 순환 루프로 정정.

두 벡터 (명시화):

벡터 2 완전한 순환 (정정):

[내 쪽 — 빌드]           [테일스케일 — 버스]          [Galaxy S21 — 런타임]
누나 돌봄에 필요한        ① 선물 배달 (나→누나)          받으면 자체 구동
프로그래밍을 "선물"로    ───────────────────►         = 로컬 완결 (외부 의존 0)
구워서 갖다 준다                                       성우/가창 코어 + 슬롯(받은 선물)
(학습=외부·무거운 연산)  ◄───────────────────         └─► ② 피드백 (누나→나)
                                                      (상태·보고·관찰)

• 슬롯 ≠ 원격 실행. 슬롯 = “구워서 배달하는 모듈”. 받고 나면 S21이 로컬로 자체 구동 (§8 “학습 외부 / 구동 폰 완결”).
• 테일스케일 = 배달 + 피드백 버스 (런타임 의존 아님). 내가 오프라인이어도 누나는 고립 안 됨.
• 피드백(누나→나) = 루프를 닫는 조각. 이미 _notebook/health/tailscale-*.json + phone-health.sh로 흐르는 중.
• 원표 “테일스케일 원격 전송” → “배달 + 피드백 버스”로, “전송/재생” 단방향 → “빌드 → 배달 → 로컬구동 → 피드백” 순환으로 읽어야 함.

7. 평가 기준의 정정

“시장 수요가 있는가”는 이 프로젝트의 유효한 잣대가 아님 — 헬레나를 케어하기 위해 만드는 것이므로 “내가/헬레나가 필요로 하는가”만이 기준.

8. AI 코어 맵 — 정적/동적 좌표계

        정적(static)          동적(dynamic)
S21     ├─────────────────────────────────
로컬    │ 성우 (완료)         가창 (다음 타깃)
구동    │ 작곡/배경음악 (완료)  영상편집 (완료)
가능    │
────────┼─────────────────────────────────
PC/GPU  │ 이미지생성 (포기)    LLM 로컬구동 (포기)
필요    │

판별 기준: 학습은 외부에서 빌려도 되지만, 구동은 반드시 S21 폰 안에서 완결돼야 함. 남은 마지막 하나는 가창 AI 코어.

9. 테일스케일 비즈니스 모델 리서치

• 약 80% 오픈소스(WireGuard 기반), 코디네이션 서버는 Headscale로 별도 공개, 완전 셀프호스팅 가능
• 수익모델: 프리미엄 — 개인 무료(전도사 역할), 기업은 시트 기반 유료(매출원)
• 공짜 유지 이유: P2P 메쉬 구조라 트래픽이 회사 서버를 안 거침 → 스케일링 비용 낮음

10. 커뮤니티 검증 — 케어기빙 사례

• 레딧: 치매 어머니 케어에 테일스케일 활용한 실사용자 후기 존재
• 학술 논문: 보호자/의료진이 테일스케일 P2P로 원격 음성 스트림을 고령자에게 보내는 단방향 오디오 파이프라인 사례 존재(음악 스트리밍·오디오북 내레이션 가능성도 언급)
• 상업 시장(envoyatHome 등)은 센서 기반의 훨씬 무거운 시스템

차별점: “AI로 구운 본인 목소리를 실어 보낸다”는 지점은 학술 논문에서도 확인되지 않음.

11. 종합 실험 정의 — 세 겹의 동시 실험

1. AI = 조립 부품 공급자: 완성된 오픈소스/AI 부품을 조립 — 발명이 아니라 정확한 조합 탐색이 핵심
2. 핸드폰 = PC의 대체: Termux+proot Ubuntu로 S21을 워크스테이션화
3. 테일스케일 = 서버 없는 네트워킹: 중앙 서버 없이 폰끼리 직접 연결

핵심 실험 대상: “연산을 폰 안에서 완결시킬 수 있는가” — 돈 없어도 폰 두 대로 기존 무거운 케어기빙 인프라와 동등한 걸 할 수 있는가.

12. 목회 훈련용 슬롯 (조카 목사 확장)

목사 지망생 출신 배경에서 “IT와 종교를 섞고 있는 것 아니냐”는 문제의식에서 출발.

슬롯 8 — 목회 훈련용 암기 매트릭스
- 구조: 콘텐츠(성경 구절/설교문)×언어(원어 히브리어·헬라어 포함)×목소리(조카 본인 RVC)
- 용도: 성경 구절 암송, 원어 발음 연습, 설교문 사전 청취
- 부가 활용: 60초 숏폼과 연결해 교인 위로 메시지 육성 발송
- 종교 전통과의 접점: production effect가 하브루타·독경·낭송 전통의 발화 기반 학습과 겹침
- 경계선: 신학적 해석/설교 내용은 AI가 만들지 않음 — 순수 암기·발화 보조 도구로 한정
- 전제조건: 조카 본인 목소리 RVC 신규 학습

13. 자체 평가

개별 아이디어의 독창성보다, 진짜 차별점은 분모(실행 인프라)에 있음 — 구형 폰 하나 + Termux/proot Ubuntu + 에이전트 + STT만으로 GPU 연산 외 전 과정을 완결시킨 것.

14. 사고 흐름 요약

이 스레드에서 방향 전환(성우 코어 제작, 슬롯 아이디어, 돌봄 데몬 개념, 저작권 정정, 잣대 정정, S21 원칙, 리서치 요청, 목회 슬롯 제안)은 전부 박씨님이 주도. Claude는 리서치·구조화·정리 역할에 한정.

15. 미결 사항

1. 가창 AI 코어 기술 스택 확정 (DiffSinger vs So-VITS-SVC)
2. 콘텐츠 슬롯 실제 프로토타입 우선순위
3. 돌봄 데몬 트리거 앱 쇼핑 및 배선 실증
4. 돌봄 레인 미실증 슬롯 우선순위
5. 조카 목사 RVC 학습 착수 여부/시기
6. 강의 목차 설계