LogoSEO Jing
  • All Posts
  • SEO Jing
  • okayJing
  • KD Team
  • CLAB Coreteam
  • Study

Contact Me

© 2026 SEOJing. All rights reserved.

SEOJingVisualAutomationBlogDevLog

본문 이미지를 나중에 넣는 게 아니라 — SEOJing 글쓰기 파이프라인에 시각 판단을 넣기

2026년 6월 22일·8분 읽기

처음엔 대표 이미지 자동화만 있으면 충분할 줄 알았다. 글 목록에서 카드가 비어 보이지 않고, 최신 글들이 어느 정도 분위기를 갖게 되면 된다고 봤다. 그런데 실제로 새 포스트를 작성해보니 다른 문제가 남아 있었다.

글 안쪽은 여전히 텍스트만 길게 이어졌다.

썸네일은 목록에서 글을 고르게 해준다. 하지만 독자가 글에 들어온 뒤에는 중간중간 구조를 잡아주는 이미지나 다이어그램이 필요하다. 특히 SEOJing에는 일반 회고 글만 있는 게 아니라 OkayJing 운영 기록, agent framework 스터디, CLAB 하네스 기록처럼 추상적인 시스템 설명이 많다. 이런 글은 문단만으로 밀어붙이면 읽는 사람이 머릿속에 구조를 계속 다시 그려야 한다.

이번 작업은 그래서 작은 반성에서 시작했다.

“대표 이미지 기능을 만들었는데, 왜 새 글 작성 흐름에서는 안 쓰고 있지?”

먼저 SEOJing 블로그 맵을 다시 봤다

본문 이미지를 나중에 넣는 게 아니라 — SEOJing 글쓰기 파이프라인에 시각 판단을 넣기 글의 먼저 SEOJing 블로그 맵을 다시 봤다 섹션을 설명하는 경계/계약 구조 다이어그램
SEOJing authored diagram · 경계/계약 구조

본문 이미지 자동화를 만들려면, 아무 글에나 사진을 붙이면 안 된다. 글의 성격마다 필요한 시각 자료가 다르기 때문이다. 그래서 지금 SEOJing의 글을 대략 이렇게 나눠봤다.

txt
SEOJing Blog
├─ SEOJing
│  ├─ 블로그 기능 개발기
│  ├─ 글쓰기/이미지/프레젠테이션 같은 publishing UX
│  └─ 실제 구현 후 생긴 판단 기록
├─ Study
│  ├─ Backend study
│  └─ Agent framework study
├─ OkayJing
│  ├─ Architecture
│  ├─ Memory
│  ├─ Workflow
│  ├─ Skills
│  └─ Voice
├─ CLAB
│  ├─ Agent harness
│  └─ Insight analysis
└─ Archive
   ├─ KD/CSHOME
   └─ SPOT

이 맵에서 중요한 건 카테고리 이름 자체가 아니다. 각 카테고리가 요구하는 이미지의 종류가 다르다는 점이다.

글 종류어울리는 시각 자료피해야 할 것

Post Q&A

오케이징에게 물어보기

본문 이미지를 나중에 넣는 게 아니라 — SEOJing 글쓰기 파이프라인에 시각 판단을 넣기 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!

0/500

포스트 목록

/SEOJing
파일 15개, 폴더 1개
Cloudflare Workers에서 fs 모듈이 안 되는 이유와 해결법대표 이미지 자동화 실험 — 검색과 Codex 생성이 같은 경로로 붙었다본문 이미지를 나중에 넣는 게 아니라 — SEOJing 글쓰기 파이프라인에 시각 판단을 넣기모바일 웹에서 가로 모드를 강제하는 5가지 방법 — iOS Safari에서도 동작하는 코드 뷰어 만들기블로그 글을 PPT로 만들기 — DOM 클로닝 기반 프레젠테이션 모드100vh가 100%가 아닌 이유 — 모바일 뷰포트 단위 완전 정리Context로 퀴즈 컴포넌트를 만들다 막혀서 React.Children을 공부하게 된 이야기대표 이미지를 글마다 다시 붙이는 방식 — 사진 검색에서 리소그래프 배경까지글 위에 영상을 붙인다는 것 — SEOJing 요약 쇼츠 파이프라인localStorage 읽기에서 하이드레이션 에러가 터지는 이유 useSyncExternalStore로 해결useEffect cleanup과 의존성 배열 — 실전 버그 사례로 이해하는 생애주기vinext + GitHub Actions로 Cloudflare Workers 배포하기vinext 오픈소스 기여기: 한국어 slug가 RSC에서 이슈를 일으킨 이유RSC 환경에서 WebAssembly가 차단되는 이유 — Shiki에서 rehype-prism-plus로vinext는 왜 빠를까? — SSR, Vite, Edge, 그리고 Web Vitals까지

같은 섹션의 대표 이미지

39 posts · latest first
본문 이미지를 나중에 넣는 게 아니라 — SEOJing 글쓰기 파이프라인에 시각 판단을 넣기 글의 대표 이미지
SEO Jing26. 06. 22.

본문 이미지를 나중에 넣는 게 아니라 — SEOJing 글쓰기.

SEOJing에서 새 글을 쓸 때 대표 이미지와 본문 이미지를 빼먹지 않도록, 블로그 맵과 글쓰기 파이프라인 안에 시각 판단 단계를 넣은 과정을 정리했다.

26. 06. 22.SEOJing
SEOJing 기능 개발기실제 UI 흐름, 파이프라인 다이어그램, 전후 비교기능과 상관없는 예쁜 배경 사진
Study 글개념 관계도, 상태 전이, 계약/경계 그림교과서 캡처처럼 보이는 장식 이미지
OkayJing 운영 기록hub-spoke 구조, memory 흐름, worker 경계내부 경로만 가득한 사적인 스크린샷
CLAB 글팀 작업 흐름, repo-local 구조, 검증 루프사람 역할놀이처럼 보이는 agent 그림
Archive 글당시 프로젝트 스크린샷, 의사결정 비교지금도 활성 프로젝트처럼 보이게 만드는 이미지

여기서 기준이 하나 생겼다. SEOJing의 이미지는 “글을 예쁘게 꾸미는 장식”이 아니라, 글의 카테고리와 사고 구조를 빨리 잡아주는 장치여야 한다.

cover와 inline visual은 역할이 다르다

대표 이미지는 이미 cover:auto로 어느 정도 경로가 잡혔다. 글 frontmatter에 cover.src, cover.alt, cover.caption, cover.kind를 넣고, 카드 렌더러는 그 값을 보고 실제 이미지를 보여준다. 검색 이미지든 생성 이미지든 최종적으로 같은 경로를 탄다.

하지만 cover는 글 바깥에서 작동한다.

txt
목록 / archive / OG image
→ 이 글이 어떤 분위기인지 보여준다
→ 클릭할지 말지 판단하게 한다

본문 이미지는 역할이 다르다.

txt
article body
→ 지금 읽는 섹션의 구조를 잡아준다
→ 긴 설명을 하나의 모델로 압축한다
→ 다음 문단을 읽기 전에 머릿속 좌표를 만든다

그래서 같은 자동화라고 해도 판단 기준이 달라야 했다. cover는 글 전체의 대표성을 본다. inline visual은 특정 섹션의 인지 부하를 본다.

이번에 추가한 visual:auto

이번에 만든 명령은 visual:auto다. 기본은 dry-run이고, 실제 파일과 MDX를 바꾸려면 --write를 붙여야 한다.

bash
pnpm --filter @app/web run visual:auto -- \
  --path apps/web/content/SEOJing/inline-visual-pipeline.mdx

실제 삽입은 이렇게 한다.

bash
pnpm --filter @app/web run visual:auto -- \
  --provider diagram \
  --path apps/web/content/SEOJing/inline-visual-pipeline.mdx \
  --write

이 명령은 글을 섹션 단위로 읽고, 각 섹션이 시각 anchor를 필요로 하는지 점수를 매긴다. 대충 이런 신호를 본다.

  • boundary / contract
  • flow / pipeline
  • lifecycle / state transition
  • comparison
  • stack / runtime / API
  • interface / tooling

후보가 없으면 억지로 넣지 않는다. 이게 중요했다. 새 기능을 만들었다고 모든 글에 이미지를 강제로 박으면, 결국 예전의 decorative image 문제로 돌아간다.

다이어그램이 먼저인 글이 있다

처음에는 이미지라고 하면 외부 사진 검색을 먼저 떠올렸다. 하지만 SEOJing의 많은 글은 추상적인 시스템 판단을 다룬다. 이런 글에 Wikimedia 사진을 붙이면 대개 애매해진다. 서버 랙 사진, 키보드 사진, 책장 사진은 분위기는 만들 수 있지만, 글 안쪽에서 구조를 설명해주지는 못한다.

그래서 본문 이미지 쪽은 authored diagram을 우선했다.

txt
글의 섹션
→ 경계/흐름/비교/상태 신호 탐지
→ 추상 개념이면 diagram 생성
→ 구체적 사물이나 UI면 Wikimedia 후보 검토
→ ArticleImage로 해당 heading 아래 삽입

이 방식이 마음에 드는 이유는, 다이어그램이 글의 일부가 되기 때문이다. 외부 사진은 출처와 라이선스를 신경 써야 하고, 의미가 조금만 빗나가도 장식처럼 보인다. 반면 직접 만든 다이어그램은 글에서 말하려는 구조를 그대로 압축할 수 있다.

물론 이건 만능이 아니다. 실제 도구 화면, 하드웨어, 역사적 자료처럼 “실물”이 중요한 글은 검색 이미지가 더 낫다. 다만 agent framework, memory architecture, workflow boundary 같은 글은 사진보다 다이어그램이 먼저다.

이 글 자체를 테스트 대상으로 삼았다

이번 포스트도 일부러 테스트 대상으로 만들었다. 글 안에 SEOJing 블로그 맵, cover와 inline visual의 역할 구분, visual:auto의 판단 흐름을 넣어뒀다. 그러면 자동화가 어디를 시각 anchor로 잡는지 볼 수 있다.

내가 기대한 후보는 세 곳이었다.

  1. SEOJing 블로그 맵
  2. cover와 inline visual의 역할 분리
  3. visual:auto의 섹션 판단 흐름

실제로 자동화가 고른 곳은 첫 번째였다. 내가 처음에 예상한 후보는 세 번째였는데, 점수화 기준은 블로그 맵 섹션을 더 강하게 봤다. 경계, 흐름, 상태, 비교, 인터페이스 신호가 한꺼번에 들어 있었기 때문이다. 이 결과가 나쁘지는 않았다. 오히려 이 글에서는 독자가 먼저 전체 블로그 지형을 잡아야 뒤의 cover와 inline visual 구분도 따라오기 쉽다.

앞으로의 새 글 작성 기본값

이제 새 글 작성 흐름은 이렇게 잡는 게 맞다.

txt
주제 결정
→ 카테고리와 독자 맥락 확인
→ MDX 초안 작성
→ cover:auto dry-run
→ 적절하면 cover --write
→ visual:auto dry-run
→ 적절하면 inline visual --write
→ asset check / format / lint / build
→ 내용 리뷰

중요한 건 --write보다 dry-run이다. 이미지를 넣는 기능이 있다는 이유만으로 무조건 넣으면 안 된다. 대신 새 글을 만들 때마다 “이 글은 이미지가 없어도 괜찮은가?”를 한 번은 물어봐야 한다.

이번 기능은 그 질문을 자동으로 던지는 장치에 가깝다.

정리

이번 작업으로 SEOJing의 글쓰기 파이프라인이 조금 더 명확해졌다. 예전에는 글을 쓰고, 나중에 필요하면 이미지를 붙이는 흐름이었다. 이제는 글을 쓰는 과정 안에 시각 판단이 들어간다.

대표 이미지는 글 바깥의 진입점을 만든다. 본문 이미지는 글 안쪽의 이해 지점을 만든다. 둘 다 필요하지만, 같은 기준으로 넣으면 안 된다.

돌이켜보면 기능 자체보다 기본값을 바꾼 게 더 중요했다. 새 포스트가 텍스트만으로 끝났다면, 그건 “이미지가 필요 없었다”는 판단이어야 한다. 그냥 잊어버린 결과이면 안 된다.

참고문헌

  • SEOJing cover 자동화 구현: apps/web/scripts/generate-content-covers.mjs
  • SEOJing inline visual 자동화 구현: apps/web/scripts/generate-inline-visuals.mjs
  • SEOJing asset 삽입 보조 스크립트: apps/web/scripts/insert-content-image.mjs
  • SEOJing 콘텐츠 자산 검증: apps/web/scripts/check-content-assets.mjs
  • Wikimedia Commons API — https://www.mediawiki.org/wiki/API:Imageinfo
SEO Jing26. 06. 22.

글 위에 영상을 붙인다는 것 — SEOJing 요약.

SEOJing 글을 소셜용 영상으로 따로 소비시키는 게 아니라, 포스트 상단 요약과 블로그 유입 장치로 연결하기 위해 summaryVideo frontmatter와 Supertonic3 기반 요약 쇼츠 파이프라인을 붙인 과정을 정리했다.

26. 06. 22.SEOJing
대표 이미지 자동화 실험 — 검색과 Codex 생성이 같은 경로로 붙었다 글의 리소그래프 스타일 대표 이미지 배경
SEO Jing26. 06. 21.

대표 이미지 자동화 실험 — 검색과 Codex 생성이 같은.

SEOJing 블로그에 대표 이미지를 자동으로 붙이는 실험을 실제로 돌려봤다. 검색 기반 cover 삽입과 Codex CLI 기반 정적 SVG 생성이 같은 frontmatter 경로로 연결됐다.

26. 06. 21.SEOJing
대표 이미지를 글마다 다시 붙이는 방식 글의 리소그래프 스타일 대표 이미지 배경
SEO Jing26. 06. 21.

대표 이미지를 글마다 다시 붙이는 방식 — 사진 검색에서.

SEOJing 포스트 목록을 파일 탐색기처럼만 두지 않고, 최신 글부터 실제 사진 기반 리소그래프 배경을 붙이는 실험을 정리합니다. 이미지는 배경만 만들고, 제목과 아이콘은 블로그 UI가 맡는 쪽으로 방향을 바꿨습니다.

26. 06. 21.SEOJing
SEO Jing26. 04. 01.

Day 12 - 테스트 커버리지 개선, 모바일 프레젠테이션 버그 2건.

SEO Jing 개발 열두째 날. code-block 테스트 14개 추가로 커버리지 대폭 개선, 모바일 프레젠테이션에서 FullscreenView 방향 전환 문제와 스크롤 멈춤 버그 수정.

26. 04. 01.SEOJing
SEO Jing26. 04. 01.

useEffect cleanup과 의존성 배열 — 실전 버그.

useEffect 의존성 배열에 불필요한 값이 포함되면 cleanup과 재실행이 뒤엉켜 DOM 상태가 꼬일 수 있다. 프레젠테이션 모드에서 발생한 모바일 스크롤 고착 버그를 통해 원인과 해결 패턴을 정리한다.

26. 04. 01.SEOJing
SEO Jing26. 03. 25.

Day 11 - 프레젠테이션 확대 기능,.

SEO Jing 개발 열한째 날. PC 프레젠테이션 확대/축소 컨트롤 추가, 모바일 orientation 판단 로직 개선, FullscreenView를 독립 컴포넌트로 분리 및 PC 대응.

26. 03. 25.SEOJing
SEO Jing26. 03. 25.

vinext 오픈소스 기여기: 한국어 slug가 RSC에서.

한국어 MDX 블로그를 만들다 vinext 프레임워크의 ByteString 버그를 발견하고, 이슈를 작성하고, PR을 올리기까지의 과정

26. 03. 25.SEOJing
SEO Jing26. 03. 25.

vinext는 왜 빠를까? — SSR, Vite, Edge,.

vinext가 빠른 이유를 이해하기 위해, SSR부터 Hydration, 빌드 도구, Edge Runtime, Web Vitals, RSC, CDN 캐싱, ISR, PPR까지 웹 렌더링 성능의 전체 그림을 정리한다

26. 03. 25.SEOJing
SEO Jing26. 03. 24.

100vh가 100%가 아닌 이유 — 모바일 뷰포트 단위 완전 정리.

모바일 Safari에서 100vh가 화면을 넘치는 이유, vh/svh/lvh/dvh의 차이, JavaScript에서 실제 뷰포트를 구하는 방법, 그리고 전체화면 UI를 만들 때 알아야 할 CSS zoom과 모바일 판정 패턴까지 정리한다.

26. 03. 24.SEOJing
SEO Jing26. 03. 23.

Day 10 - 프레젠테이션 모드 안정화.

SEO Jing 개발 열째 날. 프레젠테이션 모드의 모바일 UX 문제들을 전면 수정. 퀴즈·코드블록·이미지·포스트목록 처리 개선, 롱프레스 UX 및 하단 바 레이아웃 안정화. 모바일 뷰포트·리스트 분할 문제 수정, 채움 비율 보수적으로 조정, 포스트 탐색기 자연 정렬 적용.

26. 03. 23.SEOJing
SEO Jing26. 03. 22.

Day 9 - 프레젠테이션 모드, 코드블럭 개선, 테스팅.

SEO Jing 개발 아홉째 날. 프레젠테이션 기능 추가, 퀴즈 구조 변경, 모바일 반응형, 코드블럭 사용성, 테스팅 도입.

26. 03. 22.SEOJing
SEO Jing26. 03. 22.

모바일 웹에서 가로 모드를 강제하는 5가지 방법 — iOS.

모바일 웹에서 코드 블록을 가로로 넓게 보여주고 싶었다. screen.orientation.lock()은 iOS에서 안 되고, PWA manifest는 브라우저에서 무시된다. 결국 CSS transform으로 가짜 회전을 만들었고, 그 과정에서 엄지 접근성까지 고민하게 됐다.

26. 03. 22.SEOJing
SEO Jing26. 03. 22.

블로그 글을 PPT로 만들기 — DOM 클로닝 기반.

MDX 파일을 수정하지 않고, 렌더된 DOM을 h2 기준으로 자르고 화면 높이에 맞춰 자동 페이지네이션하는 프레젠테이션 모드를 만들었다. 리스트 높이 측정이 왜 틀리는지 디버깅한 과정과, ul/ol을 li 단위로 분할하는 해결책을 정리한다.

26. 03. 22.SEOJing
SEO Jing26. 03. 21.

Day 8 - 아티클 퀴즈와 스터디 자료.

SEO Jing 개발 여덟째 날. 아티클 퀴즈 디자인시스템 구현과 스터디 대면 자료 작성.

26. 03. 21.SEOJing
SEO Jing26. 03. 21.

Context로 퀴즈 컴포넌트를 만들다 막혀서.

MDX 블로그에 퀴즈 컴포넌트를 만들면서, Context 기반 Compound Component로 시작했다가 index 문제에 막혀 React.Children API를 채택하게 된 과정을 정리한다.

26. 03. 21.SEOJing
SEO Jing26. 03. 20.

Day 7 - Front Matter CMS와 관련 게시물.

SEO Jing 개발 일곱째 날. Front Matter CMS 설치와 관련 게시물 이동 탐색기 구현.

26. 03. 20.SEOJing
SEO Jing26. 03. 18.

Day 6 - 스터디 자료 작성과 데스크탑 비율 수정.

SEO Jing 개발 여섯째 날. 데스크탑 비율 수정과 씨랩 스터디 사전 진단 자료 작성.

26. 03. 18.SEOJing
SEO Jing26. 03. 17.

Day 5 - shiki 제거, MDX 모듈화, 그리고.

SEO Jing 개발 다섯째 날. shiki를 rehype-prism-plus로 교체하고, gray-matter 직접 구현, MDX 모듈화, 페이지 내 검색, 테이블 디자인시스템까지.

26. 03. 17.SEOJing
SEO Jing26. 03. 16.

Day 4 - 배포와 CI/CD.

SEO Jing 개발 넷째 날. lint, codecov, Cloudflare 배포, fs 런타임 이슈.

26. 03. 16.SEOJing
SEO Jing26. 03. 16.

Cloudflare Workers에서 fs 모듈이 안 되는 이유와.

배포 후 블로그 포스트가 404를 반환하던 문제부터, gray-matter eval 차단, next-mdx-remote eval 차단까지 — 세 겹으로 터진 이슈를 하나씩 해결한 기록

26. 03. 16.SEOJing
SEO Jing26. 03. 16.

localStorage 읽기에서 하이드레이션 에러가 터지는 이유.

localStorage를 읽는 컴포넌트에서 하이드레이션 불일치가 발생하는 원인과, useState+useEffect가 아닌 useSyncExternalStore가 정답인 이유를 정리한다.

26. 03. 16.SEOJing
SEO Jing26. 03. 16.

vinext + GitHub Actions로.

vinext 프로젝트를 GitHub Actions로 Cloudflare Workers에 자동 배포하는 방법과 실제 겪은 트러블슈팅 기록

26. 03. 16.SEOJing
SEO Jing26. 03. 16.

RSC 환경에서 WebAssembly가 차단되는 이유 —.

코드 하이라이팅에 Shiki를 쓰면 왜 RSC에서 WebAssembly.instantiate() 에러가 터지는지, 그리고 빌드 타임 하이라이팅으로 어떻게 해결했는지 정리한다.

26. 03. 16.SEOJing
SEO Jing26. 03. 15.

엄청난 피드백.

CLI 코드 리뷰에서 받은 피드백과 전체 코드 수정 계획을 정리했다.

26. 03. 15.SEOJing
SEO Jing26. 03. 15.

생각보다 어려웠던 댓글, 완독 로컬스토리지.

localStorage만으로 글 읽기 추적, 스크롤 진행률, 댓글 감지를 구현한 과정을 정리했다.

26. 03. 15.SEOJing
SEO Jing26. 03. 15.

MDX 관련 이슈 노트.

블로그 디테일 페이지에서 MDX를 렌더링하기 위해 검토한 라이브러리들과 최종 선택 과정.

26. 03. 15.SEOJing
SEO Jing26. 03. 15.

Day 3 - MDX 이슈, 반응형, 다크모드.

SEO Jing 개발 셋째 날. MDX 라이브러리 이슈, 반응형, 코드블럭, 댓글, 다크모드, 코드 리뷰.

26. 03. 15.SEOJing
SEO Jing26. 03. 14.

디자인 시스템을 구축할 때 주의할 점.

디자인 시스템 구현 시 파일 구조, 디자인 토큰, 유의 사항을 정리했다.

26. 03. 14.SEOJing
SEO Jing26. 03. 14.

폰트는 왜 메인 페이지에서만 적용이 안되고 있었을까?.

Tailwind v4 환경에서 폰트가 메인 페이지에서만 적용되지 않던 원인과 Hydration Mismatch 이슈를 정리했다.

26. 03. 14.SEOJing
SEO Jing26. 03. 14.

MDX DOM 트리 파싱하기.

MDX 파일의 경로 탐색 로직과 콘텐츠 트리 생성 과정을 정리했다.

26. 03. 14.SEOJing
SEO Jing26. 03. 14.

결국 Node.js 까지 와버렸다.

MDX 파일 구조를 JSON으로 변환하기 위해 Node.js의 fs 모듈을 배워봤다.

26. 03. 14.SEOJing
SEO Jing26. 03. 14.

Day 2 - 블로그 스켈레톤과 MDX 파싱.

SEO Jing 개발 둘째 날. 디자인 시스템 확장, 블로그 스켈레톤, 폰트 이슈 해결.

26. 03. 14.SEOJing
SEO Jing26. 03. 13.

전체적인 플로우.

SEO Jing 프로젝트의 기술 스택 선정과 전체적인 개발 플로우 정리.

26. 03. 13.SEOJing
SEO Jing26. 03. 13.

Storybook으로 디자인 시스템 테스팅하기.

Storybook의 사용법과 디자인 시스템 개발에서의 장점을 정리했다.

26. 03. 13.SEOJing
SEO Jing26. 03. 13.

MDX가 뭘까?.

MDX의 개념과 블로그에서 활용하는 이유를 정리했다.

26. 03. 13.SEOJing
SEO Jing26. 03. 13.

Day 1 - 디자인 컨셉과 디자인 시스템.

SEO Jing 개발 첫째 날. 디자인 컨셉 설정과 디자인 시스템 구축을 시작했다.

26. 03. 13.SEOJing
SEO Jing26. 03. 13.

기술 블로그를 직접 제작하게 된 이유.

SEO Jing을 개발하게 된 이유입니다.

26. 03. 13.SEOJing
SEO Jing26. 03. 13.

왜 자꾸 프로젝트가 중단되는지.

프로젝트가 중단되는 이유에 대한 자기 회고입니다.

26. 03. 13.SEOJing