⚡ Prompt · parksy-logs · 전문가말투 Prompt Engine Collection

1. 출발점: “말만 해서 시스템까지 가고 싶다”

1-1. 첫 번째 충격: LLM의 코드 생성 능력

처음 시작은 단순했다.

“그냥 물어보니까 코드까지 다 짜준다?”

텍스트 답변을 넘어서:

  • 파이썬 스크립트
  • 웹 코드
  • 아키텍처 설명
  • 자동화 흐름까지 설명 가능

여기서 생긴 기본 욕망:

“내가 말만 하면, 코드·문서·공장·출판까지 한 번에 이어지게 만들 수 있겠는데?”

이게 Parksy OS / EduArt Engineer 프로젝트의 씨앗이다.

생각을 말로 던지면, 그게 곧 설계도와 코드가 되어 돌아오게 만들고 싶었다. / I wanted my spoken thoughts to come back as architecture and code, automatically.

1-2. 두 번째 충격: Claude MCP Desktop = PC 원격 기계 감독

ChatGPT가 “머리”를 대체한다면, Claude MCP는 “손발+근육+공장 로봇”을 장착해버렸다.

  • 로컬 파일 읽기/쓰기
  • ffmpeg 실행
  • 파이썬 코드 실행
  • Node 설치/빌드
  • Git 커밋/푸시 자동화
  • 폴더 구조 생성/리팩토링
  • 심지어 APK 빌드까지 가능

이걸 보고 나온 결론:

“PC는 이제 ‘내가 만지는 컴퓨터’가 아니라,
클로드가 대신 굴리는 자동화 공장이다.”

1-3. 세 번째 발견: GitHub = 출판사 + 코드 공장 본체

GitHub를 단순 저장소로 보지 않고 이렇게 보게 됐다.

  • 콘텐츠 저장소: MDX, HTML, 이미지, 데이터
  • 출판사: GitHub Pages
  • 빌드/배포 시스템: GitHub Actions
  • 템플릿/표준화 센터: 레포 구조
“GitHub = 내 전체 생태계의 ‘본사 & 출판사 & 코드 공장’”

이 인식 전환이 지금 시스템의 핵심이다.

2. 중간에서 부딪힌 벽들 (실패와 혼란)

2-1. “모바일에서 전부 한다” 시도

초기 목표:

  • 인샷 대체도 폰에서
  • PWA도 폰에서
  • GitHub도 폰에서
  • 심지어 거의 모든 편집/출판까지 폰에서

하지만 현실은:

  • ffmpeg 대량 처리 → 모바일에서 비현실적
  • Node/파이썬/Docker 빌드 → 사실상 PC 필수
  • MCP(로컬 제어)는 모바일에서 잘 안 됨
  • APK 빌드/디버깅 → PC 환경이 훨씬 필요
“폰은 중심이지만, 대형 공장 작업은 PC가 필요하다”는 걸 인정하게 됨.

2-2. PWA로 인샷 대체하려다 깨진 지점

당초 플랜:

“인샷 반복 편집 대신,
Vercel + PWA로 클라우드 인샷을 만들자.”

문제:

  • Vercel Serverless Function에는 시간 제한이 있음
  • Hobby / Free: 수 초 수준, Pro: 그래도 60초 정도
  • 영상 인코딩, 긴 ffmpeg 작업 → 타임아웃 리스크
  • 폰 내부 저장소 파일에 직접 접근이 안 됨
  • 업로드해야만 처리 가능

결론:

❌ 긴 영상/대량편집/폰 로컬 파일 직통 처리는
PWA/Vercel 조합만으로는 한계가 있다.

2-3. GitHub / Vercel / 도메인 / PWA 혼선기

한때 상태:

  • GitHub Pages
  • Vercel
  • Tistory / WordPress / 도메인
  • PWA 레포 따로
  • Apps 레포 따로

이 모든 게 직관 없이 섞여서 혼란스러웠던 시기가 있었음.

지금은:

  • 도메인 역할 분리 (parksy.kr / eae.kr / dtslib.com)
  • 레포 슬롯 7개 고정
  • GitOps 기반으로 어느 정도 정리 완료

이 백서는 그 “정리된 상태”를 기준으로 씀.

핵심은 “폰이 중심”이라는 감각을 유지하면서, 공장 일은 PC와 클라우드에 넘기는 역할 분리였다. / The real breakthrough was keeping the phone as the center, while offloading factory work to PC and cloud.

3. 최종 인식: 역할을 명확히 나누자

핵심 키워드: “누가 / 어디서 / 무엇을 / 어떻게 돌리냐”

네 가지 축으로 나눌 수 있다.

  • 1. 장치(디바이스)
    • PC
  • 2. 플랫폼
    • GitHub
    • Vercel
    • YouTube / SNS
  • 3. AI 에이전트
    • ChatGPT
    • Claude MCP
    • Grok
    • GitHub Copilot Agents
  • 4. 아티팩트(결과물)
    • MDX / HTML / 웹페이지
    • PWA / APK
    • 영상 / 음원 / 이미지
    • 백서 / 튜토리얼 / 교재

장치·플랫폼·AI·결과물을 분리해서 보면, 어디에 힘을 써야 할지가 선명해진다. / Once devices, platforms, AIs, and artifacts are separated, it becomes obvious where the real leverage is.

4. 각 요소의 ‘정확한 역할 정의’

4-1. 폰 (Galaxy / Mobile)
메인 콘솔 + 생산·소비 단말

폰에서 하는 일:

  • STT로 말 던지기 (삼성 키보드)
  • ChatGPT에 발화 → 기획/설계/정리
  • GitHub 앱/웹으로:
    • 코드/MDX/HTML 간단 수정
    • Actions 모니터링 및 재시도
    • 브랜치/커밋 관리(간단 수준)
  • Vercel 대시보드 확인
  • PWA 설치/테스트
  • YouTube/인스타/스레드 업로드
  • 아티팩트(완성된 영상/페이지/앱)를 직접 사용
“폰은 왕이다.
명령 내리고, 결과를 보고, 배포하고, 소비한다.”
4-2. PC + Claude MCP Desktop
중공업 공장 + 수술실

PC에서, Claude MCP가 하는 일:

  • 파이썬 / ffmpeg 자동화 스크립트 실행
  • MIDI → AIVA → 음원 → 영상 병합 공장 설계 및 실행
  • GitHub 레포 로컬 클론 → 대규모 리팩토링
  • Node/Next.js 앱 설치/빌드/테스트
  • APK 빌드 (React Native / Flutter 등)
  • GitHub Actions용 yml 템플릿 생성
  • DevOps 수준 자동화:
    • CI/CD 파이프라인
    • 이미지/영상 일괄 변환
    • 대용량 작업(batch) 오케스트레이션
“PC는 공장, Claude는 수술하는 공장장.
사람(박씨)은 그 위에서 구상·명령만 내린다.”
4-3. GitHub
본사 + 출판사 + GitOps 허브

GitHub 역할:

  • 1. 콘텐츠 저장소
    MDX, HTML, JSON, 이미지, 메타데이터
  • 2. 출판사 (GitHub Pages)
    • MDX/HTML 수정 → Actions → 빌드 → 즉시 반영
    • parksy.kr / eae.kr / dtslib.com 의 핵심 뼈대
  • 3. 자동화 허브 (Actions)
    • 커밋 → 빌드 → 테스트 → 배포
    • Pages / Vercel / 기타 워크플로우 모두 여기서 트리거
  • 4. 템플릿/표준 구조
    • 7개 슬롯 레포
    • 공통 보일러플레이트
    • PWA/MDX/튜토리얼 템플릿
GitHub Actions는 모바일에서도 충분히 수정·트리거 가능하다.
다만 대형 빌드/디버깅은 PC+Claude 쪽이 훨씬 편하고 안정적일 뿐.
4-4. Vercel
앱·유틸·경량 백엔드 스튜디오

Vercel에서 하는 일:

  • Next.js 기반 PWA/웹앱 배포
  • 간단한 API Routes
  • 이미지/정적 파일 최적화
  • GitHub 커밋 → 자동 빌드/배포
  • (영상 인코딩처럼 무거운 건 ❌ → 백그라운드 워커나 다른 서비스로 분리)

박씨 기준으로는:

“Vercel은 GitHub 기반 앱을 세상에 내보내는 스튜디오.
폰에서 쓰는 PWA는 여기서 빌드·호스팅한다.”
4-5. PWA
폰에서 돌아가는 클라우드 앱

정리:

  • 설치는 폰
  • 실행은 폰
  • 데이터는 주로 클라우드 (GitHub / DB / S3 등)
  • 브라우저/앱 중간 지점

PWA의 올바른 용도:

  • 업로드형 자동화
    • 폰에서 파일을 선택/업로드
    • 서버가 처리
    • 결과를 내려받음
  • 조회·편집형 인터페이스
    • GitHub 기반 콘텐츠 조회
    • 가벼운 Form/데이터 입력
    • 태깅/분류/메모 등

❌ PWA에게 절대로 억지로 시키지 말 것:

  • 폰 로컬 저장소 전체 스캔
  • 긴 영상 ffmpeg 인코딩
  • 수십 분짜리 배치 작업

그건 PWA가 아니라 PC or APK의 영역이다.

4-6. APK
인샷 진짜 대체용 ‘온디바이스 공장 앱’

APK(안드로이드 앱)의 강점:

  • /storage/emulated/0/... 아래 폴더 접근 가능 (권한 승인 시)
  • 갤러리, Music, Download 폴더 등 로컬 파일 스캔 가능
  • ffmpeg-kit 같은 라이브러리로 폰에서 직접 인코딩
  • 오프라인도 동작 가능
  • “인샷처럼 생겼는데, 내 로직대로 작동하는 나만의 편집기” 가능

역할:

“폰 로컬에 이미 쌓여 있는 영상/음원을
업로드 없이 바로 가공하고 싶은 경우 → APK가 답이다.”

그래서 정리:

  • 인샷 대체 = PWA가 아니라 APK가 본질에 더 가까움
  • PWA는 “업로드 기반 자동화”, APK는 “로컬 기반 자동화”
4-7. AI 팀 구성
각자 역할 확정
ChatGPT · 두뇌/설계 Claude MCP · 공장장 Grok · 밈/캠페인 Copilot Agents · 편집 알바
  • 🧠 ChatGPT = 두뇌 / 설계 / 정리 / 글·구조 담당
    • 박씨 발화 → 개념 정리 → 구조화 → 백서/튜토리얼화
    • GitHub README / MDX / 설계 문서 초안 작성
    • 프롬프트 엔진, 프로젝트 지침서, 아키텍처 설명 문서 생성
    • “생각 → 시스템 설계 도면” 변환
  • 🧬 Claude MCP = 외과 전문의 / 자동화 공장장
    • 파이썬·ffmpeg·Node·Docker·Git을 PC에서 직접 돌리는 집도의
    • 대량 작업, 대규모 리팩토링, 환경설치, 디버깅
    • APK 빌드, 로컬 테스트, GitHub 연동 배치 작업 전담
  • 🎭 Grok = 밈·캠페인·트렌드 담당
    • MZ 감성, 짧은 카피, 쇼츠용 문구, 캠페인 문장
    • 트위터식 짧은 임팩트 있는 문장 뽑기
    • “이걸 어떻게 요즘 애들 언어로 팔아먹을까?” 담당
  • 🧰 GitHub Copilot Agents = 출판물 편집부(알바팀)
    • GitHub 레포 내부에서:
      • MDX 수정
      • CSS/디자인 마이너 변경
      • 카테고리 구조 정리
      • import 경로 정리
      • 죽은 링크 제거
      • 작은 코드 리팩토링
    • → “GitHub Pages라는 출판물을 매일 조금씩 손보는 편집 알바팀”

5. 전체 플로우: “말 → GitOps → 출판 → 유통”

5-1. 기본 루프 (콘텐츠/백서/튜토리얼)

  1. 말한다
    폰에서 STT로 떠듦 → ChatGPT 스레드
  2. ChatGPT가 구조화
    • 개념 정리
    • 섹션 나누기
    • 표/구조화
    • MDX 템플릿에 맞게 가공
  3. GitHub로 간다
    MDX/Markdown/HTML로 저장 → 커밋/푸시
  4. GitHub Actions가 돈다
    • 빌드 시작
    • 에러 있으면 로그 확인 → 수정 → 재빌드
  5. GitHub Pages / Vercel에 출판
    웹페이지/앱 형태로 세상에 노출
  6. 필요시 Copilot Agents가 다듬기
    • 스타일/디자인/카테고리/링크 정리
  7. 폰에서 최종 소비 & 배포
    • 폰 브라우저/PWA로 확인
    • 필요하면 YouTube/인스타/스레드/블로그에 재배포

5-2. 영상/음원/쇼츠 루프 (인샷 대체 라인)

  1. 소스 수집
    • MIDI 다운로드 (PC or 폰)
    • 이미 만들어 둔 이미지/영상 유닛 (폰/클라우드)
  2. PC + Claude 공장
    • 파이썬 + ffmpeg 공장 (120곡 등)
    • 규칙대로:
      • 음원 + 영상 매칭
      • 개별 클립 생성
      • concat으로 긴 버전 생성
  3. 결과물 전달
    • GitHub, Google Drive, S3 등
    • 또는 폰으로 직접 복사
  4. 폰/APK/PWA에서 활용
    • APK: 로컬 클립 재조합, 추가 편집
    • PWA: 업로드 기반 클라우드 편집 (가벼운 용도)
    • YouTube 쇼츠/롱폼 업로드
긴·대량 공정 = PC+클로드 공장
쇼츠 단위 조합/배포 = 폰 & APK & PWA & YouTube

결국 루프는 “말 → GitHub → Actions → 출판 → 재사용”으로 닫힌다. / In the end, the loop closes as “speech → GitHub → Actions → publish → reuse.”

6. 이 전체 시스템이 의미하는 것

6-1. 기술적인 의미

  • GitOps 기반 1인 창작 공장
  • 디바이스 역할 분리: 폰(명령/소비) vs PC(공장)
  • AI 팀 오케스트레이션:
    • ChatGPT(설계)
    • Claude(실행)
    • Copilot(편집)
    • Grok(캠페인)
  • PWA vs APK 역할 정리
    • 업로드 기반 vs 로컬 기반 자동화

6-2. 창작/비즈니스적인 의미

  • 인샷/편집노동 → 시스템으로 치환
  • 백서/튜토리얼/세계관/웹툰/쇼츠 전부
    “말 → 구조화 → 코드/액션 → 출판”으로 묶임
  • 1인 기업이지만, 실제론:
    • CTO (Claude)
    • CCO/플래너 (ChatGPT)
    • 마케팅 팀 (Grok)
    • 편집부 (Copilot)
    를 둔 회사와 비슷한 구조

7. 최종 3원칙 (Parksy Automation OS Core Principles)

  1. 말하면 기록된다.
    STT → LLM → GitHub
    대충 말해도 구조화는 시스템이 한다.
  2. 기록되면 빌드된다.
    GitHub 커밋 → Actions → 빌드 → 출판
    사람은 버튼 누르고, 에러나면 방향만 잡는다.
  3. 빌드되면 퍼블리시된다.
    Pages / PWA / APK / YouTube / SNS
    결과물은 자동으로 여러 채널에 퍼져 나간다.

말하면 기록되고, 기록되면 빌드되고, 빌드되면 퍼진다. / Speak, it gets recorded. Once recorded, it gets built. Once built, it spreads.

← Prompt Engines · parksy-logs · GitHub