블로그 자동 포스팅 파이프라인 다시 들여다보기 (연재 3/3)

학습 주제

• 블로그 백엔드의 태그 자동 삽입 로직 정리
• 자동 생성되는 글의 문체(prompt) 조정
• SVG viewBox 클리핑 버그 수정
• 프로젝트별 개발 기록을 트리 형태로 보여주는 기능 구현
• 학습 날짜: 2026년 7월 24일

탐구 과정

블로그 글에 붙은 "본인", "학습", "커밋" 같은 태그를 지우려고 시작했다. 확인해보니 "학습" 태그가 46개, "커밋" 태그가 47개 글에 붙어 있었다. DB에서 이 세 태그를 걷어내는 건 어렵지 않았는데, 문제는 그 다음이었다. 앞으로도 이런 태그가 계속 자동으로 붙는다면 근본적인 해결이 아니라는 생각이 들었다.

그러다 글 내용을 다시 읽어보니 뭔가 이상했다. 내가 직접 쓴 것 치고는 지나치게 정형화되어 있었다. ## 요약 / ## 배경 및 목적 / ## 구현 내용 / ## 기술적 의사결정 / ## 배운 점 같은 틀에 맞춰서, 마치 내 활동을 관찰한 누군가가 보고서 쓰듯 3인칭으로 서술한 느낌이었다. 이 형식이 어디서 나오는지 추적해봤더니, github_collector.py라는 스크립트가 있고 LearningCollector 프로젝트가 GitHub 커밋/PR을 수집해서 초안을 만들어 자동으로 올리는 구조라는 걸 알게 됐다. 즉 글쓰기 스타일을 바꾸려면 태그 삭제가 아니라 이 파이프라인의 프롬프트 자체를 고쳐야 했다.

한 가지 애매했던 부분도 있었다. 글 중 하나에 "리뷰 피드백(찬욱)을 받아 방식을 바꿨다"는 문장이 있었는데, 이걸 1인칭으로 그대로 바꿔 쓰면 마치 리뷰어 이름을 내가 언급한 것처럼 보일 수 있어서, 자연스러운 서술로 흡수하는 방식을 택했다.

핵심 학습 내용

태그 필터링을 서버 단에서 걸기

프론트엔드에서 태그를 숨기는 게 아니라, 애초에 저장 시점에 걸러내는 게 맞다고 판단했다. 모듈 레벨에 금지 태그 상수를 두고, 글이 저장되는 두 지점(개발/PR 워커, 학습 워커) 모두에서 이 필터를 거치도록 했다.

BANNED_TAGS = {"본인", "학습", "커밋"}

def _strip_banned_tags(tags: list[str]) -> list[str]:
    return [t for t in tags if t not in BANNED_TAGS]

태그 목록 자체가 DB에서 동적으로 계산되는 구조라 프론트엔드 재시작 없이도 바로 반영됐다.

글 톤을 두 번 조정한 이유

처음엔 "1인칭 개발 일지처럼, 감정을 담아서" 쓰도록 프롬프트를 바꿨다. 그런데 실제로 적용해보니 이번엔 반대로 너무 주관적이고 감정이 과했다. "보다가 좀 허탈했다" 같은 표현이 오히려 부자연스러웠다. 그래서 다시 "1인칭 개발일지/감정" 지시는 빼고 "감정 표현 없이 담백한 사실 위주 서술"로 조정했다. 대신 ## 요약 같은 고정 보고서 틀은 계속 없앤 채로 유지했다. 결국 적당한 지점은 완전히 딱딱한 보고서도, 완전히 감성적인 일기도 아닌 중간 어딘가였다.

SVG 클리핑 버그

메인 페이지 서버 아이콘 아래쪽이 살짝 잘려 보이는 문제가 있었다. 원인은 SVG 내부 사각형 요소의 stroke가 viewBox(24×24) 범위를 0.25만큼 벗어나 있었기 때문이었다.

<rect y="1.75" ... />
<rect y="9.25" ... />
<rect y="16.75" ... />

좌표를 다시 계산해서 중앙에 오도록 살짝 위로 옮기니 클리핑이 사라졌다. 눈에 잘 안 띄는 버그였는데, viewBox와 stroke 두께의 관계를 다시 생각해보는 계기가 됐다.

프로젝트별 개발 기록 트리

프로젝트 하나를 진행하며 쓴 글들이 시간순으로 흩어져 있어서, 한눈에 흐름을 보기 어려웠다. 그래서 프로젝트 상세 페이지에 월별로 접고 펼치는 트리 뷰를 추가했다. 프로젝트의 github_url에서 레포 이름을 뽑아, 그 이름이 태그로 붙은 글들을 모아 시간순으로 보여주는 방식이다.

구현하면서 걸린 부분은 API가 limit을 서버 단에서 100으로 캡핑하고 있다는 점이었다. 한 프로젝트에 관련 글이 110개나 있어서 한 번의 요청으로는 다 가져올 수 없었다. 프론트엔드에서 페이지를 나눠 여러 번 요청하도록 고쳐서 해결했다. 이후 실제 브라우저 렌더링으로 확인해보니 110개 글이 모두 정상적으로 뜨는 걸 볼 수 있었고, 관련 글이 없는 프로젝트에서는 트리 섹션 자체가 안 보이는 것도 확인했다.

이해한 내용

• 태그나 텍스트 필터링은 프론트엔드가 아니라 저장 시점(백엔드)에서 걸러야 재발하지 않는다는 걸 다시 확인했다.
• 자동 생성 텍스트의 "톤"은 한 번에 맞춰지지 않는다. 너무 딱딱해도, 너무 감정적이어도 어색하고, 실제로 몇 번 적용해보고 비교해야 적정선을 찾을 수 있었다.
• SVG는 viewBox 안에서 stroke 두께까지 고려해서 좌표를 잡아야 요소가 잘리지 않는다.
• 페이지네이션이 있는 API를 쓸 때는 응답 개수 상한을 반드시 확인해야 한다. 처음엔 데이터가 누락된 걸 눈치채지 못할 뻔했다.

실전 적용

이번에 정리한 태그 필터링 로직과 트리 뷰 구조는 다른 콘텐츠 자동화 프로젝트에도 그대로 응용할 수 있을 것 같다. 특히 "저장 시점에 걸러내기" 패턴은 태그뿐 아니라 다른 메타데이터 정제에도 쓸 수 있다. 트리 뷰는 프로젝트가 늘어나고 개월 수가 쌓이면 접기/펼치기 효과가 더 뚜렷해질 텐데, 지금은 전부 7월에 몰려 있어서 실감이 잘 안 난다. 다음 달부터는 실제로 접힌 상태에서 펼쳐보는 흐름이 더 자연스러워질 것 같다.

추가 학습 계획

• 나머지 글들 중 여전히 "보고서 같은" 톤으로 남아있는 것들을 찾아서 순차적으로 정리
• Playwright를 이용한 프론트엔드 검증을 다른 페이지에도 확대 적용해보기
• API 페이지네이션 상한 문제를 다른 엔드포인트에도 점검해볼 필요가 있음