부록. 블로그 메이킹 on Physical AI 드림팀

대본만 쓰면 강의 영상이 나온다 — 버튜버 자동 제작 파이프라인 구축기

Thu, 02 Jul 2026 00:00:00 +0900

무엇을 만들었나

블로그 1장 “AI가 화면 밖으로 나왔다 — 피지컬 AI 입문 가이드"를 10분짜리 유튜브 강의 영상으로 만들었다. 목표는 분명했다. 사람이 카메라 앞에서 연기하지도, 녹화 버튼을 누르지도 않는 것. 대본을 쓰면 AI 음성 합성 → 아바타 자동 립싱크 → 자동 녹화까지 한 번에 이어지도록 배선했고, 사용한 도구가 전부 무료라 총비용은 0원이었다.

전체 흐름은 다음과 같다.

1
2
3
4
5


블로그 글 → 구어체 대본 (Claude 작성)
 → Edge TTS로 mp3 생성 (tts.py)
 → 음성 내장 HTML 슬라이드, 타임스탬프 자동 전환 (slides.html)
 → OBS 재생 음성을 가상 오디오 케이블로 VMagicMirror에 전달 → 아바타 립싱크
 → OBS WebSocket API로 녹화 시작/종료 자동화 (record.py)

무료 도구로 짠 파이프라인

파이프라인을 구성하는 도구는 모두 무료이거나 오픈소스다.

VRoid Studio (Pixiv): 슬라이더 조작만으로 3D 아바타를 만들어 VRM 파일로 내보낸다. 샘플 모델로 시작해도 충분하며, 내보낼 때는 호환성이 가장 좋은 VRM 0.0 형식을 쓴다.
VMagicMirror (MIT 라이선스): VRM 아바타를 띄우고 마이크 입력만으로 립싱크한다. 웹캠 없이 쓰는 것을 전제로 만들어져 숨쉬기·눈 깜빡임 같은 대기 모션이 자연스럽고, 그래서 “AITuber” 용도에 잘 맞는다.
VB-Audio Cable (도네이션웨어): 가상 오디오 케이블. 재생 소리를 가상 마이크(CABLE Output)로 흘려보내, mp3를 마이크 입력인 것처럼 넣어 준다.
edge-tts (파이썬 패키지): 마이크로소프트 Edge의 한국어 TTS를 무료로 쓴다. ko-KR-SunHiNeural 음성으로, 10분 분량 대본이 몇십 초 만에 mp3가 된다.
OBS Studio: 배경·슬라이드·아바타를 합성하고 녹화한다. WebSocket 서버를 켜면 파이썬으로 원격 제어할 수 있다.

이 구조에서 가장 중요한 건 소리 배선이다. mp3 재생음을 아바타의 “마이크 입력"으로 착각하게 만들어야 립싱크가 걸리기 때문이다.

OBS 설정 → 오디오 → 고급 → 모니터링 장치를 CABLE Input으로.
음성 소스(슬라이드 브라우저 소스)의 고급 오디오 속성 → 모니터링을 **“모니터링과 출력”**으로.
VMagicMirror 스트리밍 탭 → 립싱크 마이크를 CABLE Output으로.

정리하면 소리는 이렇게 흐른다. OBS가 mp3를 재생 → CABLE Input → CABLE Output → VMagicMirror가 마이크 입력으로 인식 → 립싱크. 같은 소리가 녹화 트랙에도 그대로 들어간다.

슬라이드 자동 전환과 자동 녹화

슬라이드는 PPT가 아니라 HTML 한 파일로 만들었다. 1920×1080 고정, 12장짜리이고 OBS 브라우저 소스로 바로 로드한다. HTML 안에 <audio>로 강의 mp3를 내장하고, JS가 audio.currentTime을 지켜보다가 미리 계산해 둔 타임스탬프에 슬라이드를 자동으로 넘긴다. 사람이 큐시트를 보며 넘길 필요가 없다.

전환 시각은 섹션별 mp3 실측 길이에 대본 글자 수 비율을 얹어 계산했다. TTS 발화 속도가 균일해서 글자 비율만으로도 추정이 꽤 정확했다. 아바타가 우측 하단에 들어가므로 슬라이드 레이아웃에서는 그 자리를 비워 뒀다(padding-right 460px).

녹화는 record.py가 맡는다. OBS 28버전 이상은 WebSocket 서버가 내장돼 있어(도구 → WebSocket 서버 설정 → 활성화), 파이썬 obsws-python 패키지로 붙어 녹화 시작 → 브라우저 소스 새로고침(refreshnocache로 페이지를 리로드해 음성을 처음부터 재생) → 재생 길이만큼 대기 → 녹화 종료를 순서대로 실행한다. 결과적으로 명령 한 줄이면 10분 45초짜리 1080p60 영상이 나온다.

막혔던 지점들

자동화 과정에서 걸렸던 문제와 해결책을 남겨 둔다.

아바타 배경이 검게 찍힘: VMagicMirror 배경 투명화를 켰을 때 OBS 게임 캡처의 “투명도 허용"을 체크하지 않으면 투명 영역이 검정으로 나온다. 게임 캡처 속성에서 체크 하나로 해결.
얼굴이 잘림: VMM 카메라를 “프리 카메라 모드"로 두고 아바타 창에서 휠(줌)·휠 드래그(이동)·우클릭 드래그(회전)로 구도를 잡는다. 잡은 구도는 퀵 세이브 슬롯에 저장할 수 있다.
10분 맞추기: 첫 대본이 11분 10초로 나와, 중복 문장을 덜어 10분 39초로 맞췄다. 한국어 TTS 기본 속도 기준 10분은 공백 포함 4,000자 안팎이다.
TTS 오독: “유니트리 G1"을 “지원"으로 읽는 식의 오독이 있어, 외래어·기호는 대본 단계에서 미리 한글로 풀어썼다(챗지피티, 러로봇, 아이작 랩 등).
조작용 UI가 화면에 찍힘: 슬라이드 카운터(HUD)가 녹화에 들어가서, 자동 재생 중에는 숨기도록 고쳤다. 녹화 화면에 들어가는 소스에 “조작용 표시"가 없는지 확인할 것.
창을 가려도 되나: OBS 게임 캡처는 GPU 렌더링을 직접 후킹하므로 다른 창에 가려져도 캡처된다. 다만 최소화는 금지(렌더링이 멈춘다). OBS 자체는 최소화해도 녹화가 계속된다.

한 가지 한계도 분명하다. 립싱크·표정·대기 모션까지는 자동이지만, 손짓이나 판서 같은 큰 제스처는 안 된다. 다만 강의 영상은 슬라이드 하이라이트로 대체할 수 있어 실용상 문제는 없었다. 이제 다음 장부터는 “대본 작성 → TTS → 슬라이드 생성 → 자동 녹화"가 명령 몇 번으로 끝난다. 유튜브 강의 채널을 글 쓰는 속도로 운영할 수 있는 구조가 된 셈이다.

한 줄 정리

대본만 쓰면 TTS·아바타 립싱크·슬라이드 전환·녹화까지 이어지는 무료 파이프라인을 짜서, 유튜브 강의 영상을 글 쓰는 속도로 찍어낼 수 있게 됐다.

블로그 글을 숏폼 영상으로 자동 변환해서 유튜브에 올리기까지

Thu, 02 Jul 2026 00:00:00 +0900

블로그에 정리해 둔 글을 그냥 두기 아까워서, 글 하나를 60초짜리 세로형 교육용 숏폼 영상으로 만들고 유튜브에 자동으로 올리는 파이프라인을 만들었다. 목표는 세 가지였다. (1) 글을 어떻게 영상 구성으로 바꿀 것인가, (2) 그걸 자동으로 할 수 있는가, (3) 실제 영상 파일로 인코딩해 저장·업로드까지 되는가. 결론부터 말하면 셋 다 된다. 비전공자도 따라올 수 있게, 개념과 내가 헤맨 지점 위주로 정리한다.

전체 그림 먼저

파이프라인은 이렇게 흐른다. 각 단계는 뒤에서 하나씩 풀어 쓴다.

1
2
3
4
5
6
7
8
9


블로그 글(.md)
 ↓ ① 글을 "장면 대본"으로 압축 (AI가 요약)
장면 JSON
 ↓ ② 나레이션 음성 만들기 (TTS, 무료 한국어)
 ↓ ③ 장면 화면(이미지) 만들기 (HTML 또는 Pillow)
 ↓ ④ 이미지 + 음성 → 영상으로 합치기 (ffmpeg)
숏폼 mp4
 ↓ ⑤ 유튜브 업로드 (YouTube API)
유튜브 Shorts

이 전체를 매일 일정 시간에 자동으로 도는 스케줄로 걸어두는 게 마지막 단계다.

준비물: 무료 도구 네 가지

돈 드는 건 없다. 전부 무료다.

Python — 파이프라인을 묶는 접착제 역할.
ffmpeg — 이미지와 음성을 합쳐 mp4로 인코딩(영상 파일로 만드는 것)하는 도구. 영상 자동화의 핵심.
edge-tts — 글자를 사람 목소리로 읽어주는 TTS(Text To Speech). Microsoft의 무료 한국어 음성을 API 키 없이 쓸 수 있다. ko-KR-SunHiNeural(여성) 같은 목소리가 꽤 자연스럽다.
화면 만드는 도구 — 두 가지를 다 만들어 비교했다. 뒤에서 설명한다.

Windows라면 ffmpeg는 winget install Gyan.FFmpeg, 나머지는 pip install로 끝난다.

① 글을 “장면 대본"으로 쪼개기

블로그 글은 길다. 60초 숏폼에는 한국어로 대략 320~380자밖에 못 담는다. 그래서 글을 통째로 넣을 수 없고 핵심만 압축해야 하는데, 이 요약·재구성이야말로 AI(LLM)가 제일 잘하는 일이다.

글을 다음처럼 5개 장면으로 나눈 대본(JSON 형식)으로 바꾼다.

후킹 (0~~3초): 강한 한 줄로 시선 잡기 (“최신 AI 모델, 외우지 마세요”) 2~~4. 핵심 카드: 한 장에 한 개념. 짧은 문장 3개 + 나레이션
마무리: 결론 한 줄 + “전체 글은 블로그에서”

각 장면에는 화면에 띄울 글자와, 성우가 읽을 나레이션이 따로 들어간다. 블로그 글의 제목·소제목·표가 자연스럽게 후킹·핵심 카드·계보 도표로 대응된다는 점이 좋았다.

한 가지 팁: 나레이션에서 영어 약어는 한글 발음으로 적어야 TTS가 제대로 읽는다. VLA는 “브이엘에이”, AI는 “에이아이"처럼. 숫자도 “96%“보다 “구십육 퍼센트"로 적으면 자연스럽다.

② 나레이션 음성 만들기

장면별 나레이션 문장을 edge-tts에 넣으면 mp3가 나온다. 명령 한 줄이면 된다. 이 음성의 길이를 재서, 나중에 그 장면 화면을 그 시간만큼 보여주면 화면과 목소리가 자동으로 맞는다.

③ 화면 만들기: 두 가지 방법

세로형(9:16, 유튜브 Shorts 규격)의 카드 이미지를 장면마다 만든다. 두 방식을 다 만들어 비교했다.

A안 — HTML/CSS로 만들고 캡처: 웹페이지처럼 예쁘게 꾸민 뒤 브라우저로 스크린샷을 찍는다. 한글 타이포와 표·도표가 훨씬 깔끔하다. 교육용에 유리해서 이걸 채택했다.
B안 — Pillow(파이썬 그림 라이브러리)로 직접 그리기: 브라우저가 필요 없고 가볍다. 담백한 스타일.

여기서 초보가 꼭 만나는 문제 하나. 자막이 화면 폭을 넘어 줄이 깨진다. 글자 길이가 글마다 다르니 고정 폰트 크기로는 안 된다. 그래서 “한 줄에 들어갈 때까지 폰트 크기를 자동으로 줄이는” 로직을 넣었다. 이러면 어떤 글이 와도 자막이 깔끔하게 한 줄로 맞는다.

④ 영상으로 합치기 (ffmpeg)

장면마다 이미지 + 그 장면 음성을 붙여 짧은 클립을 만들고, 클립들을 순서대로 이어 붙이면 하나의 mp4가 된다. 페이드 인 같은 효과도 ffmpeg 옵션으로 넣을 수 있다. 60초 영상이 1~2MB로 가볍게 나온다.

⑤ 유튜브 자동 업로드: 여기가 진짜 삽질 구간

영상 만드는 것보다 유튜브에 자동으로 올리는 인증 과정이 훨씬 까다로웠다. 공식 방법은 YouTube Data API + OAuth 인증이다. 초보가 순서대로 만나는 함정을 그대로 적어둔다.

Google Cloud에서 API 사용 설정 + OAuth 클라이언트(데스크톱 앱) 만들기. 다운로드한 인증 파일(client_secret.json)이 "installed"로 시작하면 데스크톱 앱(정상), "web"이면 잘못 만든 것.
앱 이름에 “Google”·“YouTube” 같은 상표명을 넣으면 안 된다. 정책상 거부된다.
“프로덕션"으로 올리면 오히려 막힌다. 유튜브 업로드는 민감한 권한이라 프로덕션 상태에선 구글 정식 심사를 통과해야 한다. 개인용이면 “테스트” 상태로 두고 내 계정을 테스트 사용자로 추가하는 게 답이다.
“확인하지 않은 앱” 경고는 차단이 아니다. 테스트 모드에선 이 경고가 정상이다. 고급 → (앱이름)(으)로 이동을 눌러 통과하면 된다.
youtubeSignupRequired 오류 = 유튜브 채널이 없다는 뜻. 인증은 됐는데 그 구글 계정에 채널이 없으면 올릴 곳이 없다. youtube.com에서 채널을 먼저 만들면 해결된다.
테스트 모드는 토큰이 약 7일마다 만료된다. 자동화가 일주일에 한 번쯤 끊기므로, 주 1회 인증 명령을 한 번 다시 실행해 토큰을 갱신해 줘야 한다.

참고로 무료 사용량은 하루 10,000 유닛이고 업로드 1건이 1,600 유닛이라, 하루 약 6개까지 올릴 수 있다. 매일 몇 개면 충분하다.

매일 자동 실행: 규칙을 정하다

마지막으로 위 전체를 Windows 작업 스케줄러에 매일 오후 3시로 걸었다. 규칙은 이렇게 정했다.

게시된 글만 대상 (초안 제외).
“블로그 메이킹” 카테고리는 제외 (지금 이 글처럼 블로그 만들기 자체를 다룬 글은 영상으로 안 만든다).
오래된 글부터 순서대로 하루 2개씩 처리. 이미 처리한 글은 기록해 두고 다시 만들지 않는다.
밀린 글이 다 소진되면, 그다음부터는 새로 올라온 글을 자동으로 집어 처리한다.

한 줄 정리

블로그 글을 숏폼으로 바꾸는 핵심은 “긴 글을 5개 장면으로 압축하는 AI 단계” 와 “이미지+음성을 ffmpeg로 합치는 인코딩” 이고, 진짜 난관은 영상 제작이 아니라 유튜브 OAuth 인증(테스트 모드·채널 생성·토큰 만료) 이다. 이 셋만 넘으면 매일 자동으로 도는 숏폼 공장이 완성된다.

실제 결과물 — 이 글이 이렇게 숏폼이 됐다

아래 원본 글 하나가, 위에서 설명한 파이프라인을 거쳐 60초짜리 세로 영상으로 자동 변환됐다. 긴 글이 어떻게 5개 장면으로 압축됐는지 원본과 나란히 보면 감이 온다.

원본 글: 피지컬 AI, 최신 모델을 외우지 말고 ‘흐름’을 읽어라
결과 숏폼: 이 파이프라인으로 처음 업로드한 영상 (아래)

GitHub Pages 블로그를 구글 검색에 노출시키기

Wed, 01 Jul 2026 00:00:00 +0900

블로그를 만들어 배포하는 것으로 끝이 아니다. 사이트가 존재해도 구글이 그 존재를 모르면 검색으로는 아무도 찾아올 수 없다. GitHub Pages에 Hugo 사이트를 올린 상태에서 실제로 검색 노출까지 진행하며 한 일과, 그 과정에서 만난 함정을 정리한다.

검색에 뜨려면 무엇이 필요한가

블로그가 구글 검색 결과에 나타나려면 네 가지가 모두 갖춰져야 한다.

구글이 사이트의 존재를 알아야 한다 → Google Search Console에 등록
구글이 사이트를 크롤링할 수 있어야 한다 → robots.txt에 sitemap 링크
구글이 안에 무엇이 있는지 알아야 한다 → sitemap.xml 제출
구글이 페이지를 색인에 넣어야 한다 → 크롤링 대기 (3일~2주)

다행히 Hugo는 sitemap.xml을 기본으로 자동 생성하고, enableRobotsTXT = true만 켜 두면 robots.txt도 만들어 준다. 결국 실제로 손봐야 할 것은 몇 가지 SEO 보완과 Search Console 등록 정도다.

현재 상태 진단과 SEO 보완

먼저 배포된 사이트에서 세 가지가 정상인지 curl로 확인한다.

1
2
3
4
5
6
7
8


curl -sI "https://<도메인>/sitemap.xml"
# → HTTP 200, content-type: application/xml 이면 정상

curl -s "https://<도메인>/robots.txt"
# → User-agent: * 는 기본. Sitemap: 링크가 있는지 확인

curl -s "https://<도메인>/" | grep -oE '<meta [^>]*(description|og:|canonical)[^>]*>'
# → og:title, og:description, canonical 있는지 확인

Hugo + Stack 기본 구성이면 sitemap과 meta 태그는 이미 있지만, 두 가지가 빠져 있었다. robots.txt에 sitemap 링크가 없어서 구글이 사이트맵을 자동으로 발견하지 못하고, og:image가 없어서 검색 결과나 메신저 공유에서 썸네일이 뜨지 않는 문제다.

첫 번째는 layouts/robots.txt 파일을 만들어 해결한다. Hugo는 이 파일이 있으면 우선 사용한다.

1
2
3
4


User-agent: *
Allow: /

Sitemap: {{ "sitemap.xml" | absURL }}

absURL이 baseURL을 붙여 절대 경로로 렌더하므로 다중 도메인이나 리버스 프록시 환경에서도 안전하다.

두 번째는 hugo.toml의 defaultImage 블록을 활성화한다.

1
2
3
4
5


[params.defaultImage]
 [params.defaultImage.opengraph]
 enabled = true
 local = true
 src = "img/avatar.png"

local = true면 static/ 아래 경로를 그대로 쓴다. 개별 글에 cover 이미지가 있으면 그쪽이 우선하고, 없으면 이 기본값이 쓰인다.

Search Console 등록과 Sitemap 제출

Google Search Console에 로그인한 뒤 진행한다.

속성 추가 → URL 접두어를 선택하고 사이트 URL(예: https://<user>.github.io/)을 입력한다.
소유권 확인에서 HTML 파일 방식을 고르면 구글이 googleXXXX...html 파일을 준다.
이 파일을 블로그 프로젝트의 static/ 폴더에 그대로 두고 commit + push 한다.
GitHub Pages 배포가 끝나면 https://<도메인>/googleXXXX...html로 접근되는지 curl로 확인한다.
Search Console로 돌아와 확인 버튼을 누르면 “소유권이 확인됨"이 뜬다.

파일 내용은 google-site-verification: ... 한 줄뿐이다. 이 토큰 자체가 인증 역할을 하지만 저장소에 push해도 위험하지 않다. 다만 구글이 준 파일명과 내용은 이 사이트·이 계정 조합에서만 유효하다는 점만 기억하면 된다.

인증이 끝나면 왼쪽 메뉴 Sitemaps에서 입력란에 sitemap.xml만 넣고 제출한다. 처음에는 “가져올 수 없음"이 자주 뜨는데, 대부분 구글이 방금 등록된 속성을 캐시하는 중이거나 첫 fetch가 일시적으로 실패한 것이다. 12~48시간 기다리면 자동으로 재시도되어 “성공"으로 바뀐다. 급하면 사이트맵을 삭제 후 재제출해 강제로 다시 트리거할 수 있다.

우선 노출을 원하는 페이지가 있다면 상단 URL 검사 도구로 특정 URL을 넣고 색인 생성 요청을 할 수 있다. 홈(/), 대표·최신 글 몇 개, 핵심 카테고리 페이지 순으로 요청하면 몇 시간~~하루 안에 처리된다. 하루 요청 수 제한(10~~15개)이 있으니 중요한 URL부터, 한 URL당 한 번만 누른다.

노출까지의 시간차, 그리고 함정

세팅은 하루면 끝나지만, 실제 노출까지는 시간이 걸린다.

시점	상태
지금	`site:<도메인>` 검색 결과 0 (정상)
3~7일	홈과 대표 글 색인 시작 → 결과 1~5개
1~2주	대부분 페이지 색인 완료
이후	고유 이름(블로그 제목 등)부터 상위 노출 시작

진행 상황은 두 곳에서 볼 수 있다. 구글에서 site:<도메인>을 검색하면 색인된 페이지 수를 대략 파악할 수 있고, Search Console의 색인생성 → 페이지에서 “색인 생성됨/미생성” 개수를 정확히 확인할 수 있다.

겪은 함정은 모두 시간차에서 비롯된 것이었다.

인증 직후 URL 검사 색인 요청 실패: 시스템 반영에 시간이 필요하다. 30분~1시간 뒤 재시도하면 대부분 성공한다.
Sitemap 제출 직후 “가져올 수 없음”: 흔한 초기 현상. 기다리면 자동 재시도되어 “성공"으로 바뀐다.
site:<도메인> 결과 0: 세팅 문제가 아니라 아직 색인되지 않은 것뿐이다.

이 시간차를 미리 알고 있으면 조급해할 일이 없다. 파일 배치와 제출은 하루 안에 끝나고, 나머지는 구글의 스케줄대로 진행된다. 한 번 해 두면 이후로는 계속 자동으로 크롤링·색인되므로, 여유가 될 때 각 글에 개별 cover 이미지를 붙여 썸네일을 다양화하거나 Article 구조화 데이터(Structured Data)를 추가해 검색 스니펫을 더 다듬을 수 있다.

한 줄 정리

검색 노출 세팅 자체는 robots.txt·og:image 보완과 Search Console 등록·sitemap 제출로 하루면 끝나고, 나머지는 구글이 3일~2주에 걸쳐 크롤링·색인하기를 기다리는 시간차의 문제다.

PaperMod에서 Stack 테마로 갈아타며 배운 것들

Tue, 30 Jun 2026 00:00:00 +0900

블로그 테마를 PaperMod에서 Stack(CaiJimmy/hugo-theme-stack)으로 교체했다. 색은 무채색(zinc) 톤으로, 폰트는 Pretendard로 커스텀했다. 단순히 “옷 갈아입기"로 끝나는 작업이 아니라 글 메타데이터와 자동화 prompt까지 한 사이클로 묶어야 일이 닫힌다는 걸 새삼 느꼈다. 헤맸던 지점 위주로 정리한다.

테마 붙이고 config에서 처음에 헤매는 것들

Stack은 submodule로 붙인다.

1

git submodule add https://github.com/CaiJimmy/hugo-theme-stack themes/hugo-theme-stack

GitHub Actions로 빌드한다면 checkout 단계에 submodules: recursive 옵션이 있어야 테마가 같이 받아진다. 이게 없으면 로컬에선 멀쩡한데 배포 빌드만 깨진다.

hugo.toml은 길지만, 처음에 발목 잡히는 건 세 가지뿐이다.

mainSections = ["posts"] — Stack 기본값은 단수형 "post"다. 우리 폴더가 posts/라면 이걸 명시하지 않으면 홈에 글이 한 개도 안 뜬다.
sidebar.avatar는 문자열 한 줄로. {enabled=..., src=...} 같은 중첩 테이블을 쓰면 빌드 에러가 난다.
메뉴 아이콘은 실재하는 파일명으로. themes/.../assets/icons/에 실제로 있는 이름이어야 한다. list, category처럼 없는 이름을 쓰면 빌드가 fail한다. archives, categories, tag, hash, home 정도가 안전하다.

커스텀의 90%는 custom.scss 한 파일에서 끝난다

Stack은 자기 style.scss 마지막에 @import "custom.scss";를 박아둔다. 그래서 우리 사이트의 assets/scss/custom.scss만 만들면 별도 설정 없이 자동으로 끼워져 컴파일된다. 이게 Stack 커스텀의 핵심이다.

이 파일에서 한 일은 다음과 같다.

색 변수(--body-background, --accent-color, --card-background 등)를 라이트/다크 모두 zinc 톤으로 override. 다크 모드는 :root[data-scheme="dark"] 블록에서 따로 잡는다.
Pretendard를 @import url(...) CDN으로 불러오고 --base-font-family를 교체. Stack 기본 폰트인 Lato는 한글 글리프가 없어서 시스템 fallback으로 떨어지면 글자가 둔탁해진다.
카드 타이틀을 2.2rem → 1.9rem으로 줄이고 letter-spacing: -0.01em. 한글은 영문보다 자간을 살짝 좁히는 쪽이 균형이 맞는다.
본문에 word-break: keep-all; overflow-wrap: anywhere; — 한국어가 어절 단위로 줄바꿈되어 훨씬 깔끔해진다.

가장 큰 함정: 카테고리 배지의 inline style

제일 오래 잡아먹은 건 카테고리/태그 배지였다. Stack은 카테고리·태그마다 hash로 색을 자동 생성해서 <a> 태그에 inline style로 직접 박는다. inline style은 외부 CSS를 이기기 때문에, SCSS로 그냥 덮어쓰면 먹지 않는다.

해결은 !important로 강제하는 것이다.

1
2
3
4


.article-category a, .article-tags a {
 background-color: var(--card-background-selected) !important;
 color: var(--card-text-color-secondary) !important;
}

이걸 안 하면 사이트 전체는 무채색인데 카테고리 배지만 알록달록하게 튄다.

글 메타데이터와 자동화 prompt까지 함께 손보기

Stack 사이드바의 카테고리 위젯이 살아나려면 각 글의 frontmatter에 categories:가 있어야 한다. 기존 글들은 PaperMod 시절이라 tags:만 있어서 위젯이 비어 있었다. 그래서 모든 글에 카테고리를 VLA / 피지컬 AI / 메타 3개 분류로 채워 넣었다.

여기서 멈추면 다음 날 새로 생기는 글에서 같은 문제가 반복된다. 그래서 매일 밤 자동 초안을 만드는 prompt-instructions.txt에도 categories 지시를 추가했다. 이제 다음 날부터 새 글은 자동으로 올바른 분류에 들어간다. 테마 교체를 글 메타데이터·자동화 prompt까지 한 사이클로 묶어야 일이 닫힌다는 게 이 작업의 교훈이다.

작업 흐름에서 챙긴 팁도 적어둔다.

별도 브랜치에서 작업. main은 머지 시점까지 건드리지 않는다.
로컬에서 hugo server를 띄워두고 SCSS를 고치면 hot reload된다. 확인할 때마다 GitHub Pages에 push하지 말 것.
배포 후 옛 모양으로 보이면 십중팔구 브라우저 캐시다. Ctrl+Shift+R이나 시크릿 창으로 먼저 확인하자. 빌드 자체를 의심하기 전에 curl로 라이브 CSS에 새 규칙이 들어갔는지 보는 게 더 빠르다.

한 줄 정리

Stack 테마 교체의 핵심은 custom.scss 한 파일과 inline style을 이기는 !important이며, 테마 변경은 글 메타데이터와 자동화 prompt까지 한 사이클로 묶어야 비로소 끝난다.

블로그를 열며 — Physical AI 드림팀

Fri, 26 Jun 2026 00:00:00 +0900

안녕하세요. Physical AI 드림팀의 첫 글입니다.

이곳은 Physical AI를 비롯해 돈 되는 모든 걸 다 하는 팀의 기록을 남기는 공간입니다. 연구 노트, 실험 결과, 그리고 떠오르는 아이디어를 차곡차곡 쌓아가려 합니다.

앞으로 다룰 것

Physical AI / 로보틱스 연구 노트
실험과 삽질의 기록
돈 되는 아이디어와 그 검증

차근차근 채워가겠습니다. 잘 부탁드립니다. 🚀

코드 한 줄 없이, 0원으로 내 블로그 만들기 (GitHub Pages + Hugo)

Fri, 26 Jun 2026 00:00:00 +0900

“블로그 하나 갖고 싶은데, 서버비도 부담되고 코드는 무섭고…”

저도 그랬어요. 그런데 오늘 직접 해보니, 코드를 거의 짜지 않고도 단돈 0원으로 인터넷에 내 블로그를 띄울 수 있더라고요. 신기했던 마음 그대로, 누구나 따라 할 수 있게 차근차근 정리해 봤습니다. 천천히 같이 가봐요. 🙂

1. GitHub에 가입하고 ‘내 땅’ 만들기

먼저 GitHub에 가입했어요. 그리고 블로그 파일이 들어갈 저장소(폴더 같은 것)를 하나 만들었습니다.

여기서 딱 하나만 틀리지 않으면 돼요. 저장소 이름을 반드시 이렇게 지어야 합니다.

내사용자이름.github.io

이 형식을 지켜야만 무료 주소가 자동으로 켜지거든요. 점 하나, 철자 하나라도 다르면 안 돼요. 이게 가장 중요한 약속입니다.

2. 무료 발행 스위치 켜기 (GitHub Pages)

GitHub에는 Pages라는 고마운 기능이 있어요. 내 저장소에 올린 파일을 무료 웹사이트로 띄워 주는 서비스죠. 서버를 따로 빌릴 필요가 없으니, 그 유명한 “서버비 0원"이 여기서 나옵니다.

켜는 법도 간단했어요.

저장소 상단의 Settings(설정) 로 들어가서
왼쪽 메뉴에서 Pages 를 누르고
Source 를 GitHub Actions 로 바꿔 주기

마지막의 ‘GitHub Actions’가 핵심이에요. 이걸로 바꿔야 다음 단계의 Hugo가 자동으로 블로그를 지어 줍니다.

3. 진짜 블로그 엔진 얹기 (Hugo + 테마)

이제 글을 쓰면 예쁜 페이지로 만들어 줄 엔진을 올릴 차례예요. 저는 Hugo를 골랐습니다.

Hugo는 쉽게 말해, 글만 쓰면 블로그 페이지를 알아서 만들어 주는 도구예요. 저는 그냥 글을 적기만 하고, 보기 좋은 HTML 페이지로 바꾸는 건 Hugo가 다 해줍니다.

디자인은 직접 만들 필요도 없었어요. 이미 잘 만들어진 PaperMod라는 테마를 가져다 붙이니, 단숨에 깔끔한 블로그 모양이 갖춰지더라고요.

4. 깃허브에 올리기 — 그리고 만난 작은 함정

작업한 내용을 깃허브에 올리는 흐름은 두 단어로 정리돼요.

commit(커밋) — 변경한 내용을 저장하기
push(푸시) — 그 내용을 깃허브로 올려보내기

다만 여기서 한 번 막혔어요. 올리려는데 403 에러가 뜨더라고요. 알고 보니 컴퓨터에 다른 계정 정보가 저장돼 있어서 생긴 일이었어요. 저장된 정보를 제 계정으로 정리해 주니 깔끔하게 해결됐습니다. 혹시 같은 에러를 만나도 당황하지 마세요. 실력 문제가 아니라 그냥 계정 설정이 엇갈린 것뿐이에요.

5. 한 줄 정리

코드를 거의 짜지 않고도, GitHub Pages + Hugo + PaperMod 조합이면 0원으로 진짜 내 블로그를 띄울 수 있어요. 막히는 순간이 와도 그건 끝이 아니라 그냥 “다음에 물어볼 차례"일 뿐이고요. 오늘 첫 발을 뗀 당신, 이미 절반은 온 거예요. 👏