자체 칼럼 시스템으로 콘텐츠 운영 자동화

자체 칼럼(articles) 플랫폼을 구축하고, 디스코그래피 콘텐츠를 자동으로 생성하는 봇을 만들었다. 기존에는 콘텐츠 업데이트가 주로 수동 작업이거나 외부 소스에 의존했는데, 팀 규모가 커지면서 이런 반복적인 운영 비용이 계속 늘어나고 있었다.

이번 작업의 핵심은 "자동화 가능한 부분을 명확히 구분하고, 그 과정 자체를 스케일 가능하게 설계하는 것"이었다. 단순히 일회성 봇을 짜는 것을 넘어서, 나중에 다른 도메인의 칼럼도 같은 방식으로 추가할 수 있도록 기초를 다져야 했기 때문이다.

콘텐츠 운영, 왜 자동화가 필요했나

서비스가 커질수록 "정기적으로 업데이트되어야 하는 콘텐츠"의 수가 기하급수적으로 늘어난다. 특히 디스코그래피 같은 구조화된 데이터는 이미 내부 DB에 있는데도, 그걸 칼럼 형태로 다시 가공해서 배포하는 작업이 반복됐다. 팀원이 이걸 매번 수동으로 처리해야 한다면:

• 일관성 문제: 사람이 하면 매번 다른 방식으로 작성될 가능성
• 운영 비용: 자동화할 수 있는 작업에 인력이 낭비됨
• 확장성 저하: 새 도메인의 칼럼을 추가하려 할 때마다 새로운 수동 프로세스가 필요

이런 상황을 보면서, "콘텐츠 자동 생성 → DB 저장 → 웹 페이지 노출"까지의 전체 파이프라인을 한 번에 설계하는 게 낫겠다고 판단했다.

시스템 설계: 봇부터 UI까지

구현 흐름을 단순하게 정리하면 다음과 같다:

초기 설계 단계에서 가장 중요했던 결정은 DB 스키마를 먼저 정의하는 것이었다. 봇이 어떤 형태의 데이터를 생성할 건지, 프론트엔드가 어떤 필드를 필요로 할 건지를 명확히 한 후에야 양쪽 코드를 일관되게 작성할 수 있기 때문이다.

-- 예시: 칼럼 스키마의 핵심 구조
CREATE TABLE articles (
    id INTEGER PRIMARY KEY,
    title TEXT NOT NULL,
    slug TEXT UNIQUE NOT NULL,
    content TEXT,
    source TEXT,           -- 원본 데이터 출처 추적
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

봇(seed_articles.py)은 이 스키마에 맞춰 데이터를 생성하고, 프론트엔드는 이 필드들을 기반으로 페이지를 렌더링한다. 중간에 변경이 생기면 양쪽을 동시에 고려해야 하므로, 초기 설계가 정말 중요하다.

구현 과정에서의 선택과 배운 점

팀원들과 논의했던 주요 트레이드오프:

• 배포 타이밍: 봇을 매번 수동으로 실행할 건가, 정기적 스케줄로 실행할 건가?

• 초기엔 수동 실행으로 시작했지만, 나중에 자동 스케줄로 전환할 수 있게 구조를 열어뒀다.

• 다국어 지원: UI 문자열만 다국어화할 건가, 콘텐츠까지?

• 현재는 UI(src/i18n/ui.ts)만 다국어화했는데, 콘텐츠 자동 번역이 필요하면 나중에 봇에 추가할 수 있게 했다.

• 레이아웃 통합: 기존 Base.astro에 칼럼 섹션을 어디까지 깊숙이 넣을까?

• 코드리뷰 때 팀원들과 "칼럼이 얼마나 메인 네비게이션처럼 중요한가"를 논의했고, 그에 맞춰 레이아웃 계층을 정했다.

특히 배웠던 점은, 초기에 "이건 나중에 확장할 거야"라고 막연하게 생각하는 것과 실제로 확장 포인트를 코드에 남겨두는 건 완전히 다르다는 것이다. 예를 들어, 봇이 단순히 "디스코그래피 칼럼만 생성"하도록 짰다면, 나중에 다른 도메인을 추가할 때 봇 구조 자체를 뜯어고쳐야 했을 것이다. 대신 봇을 "소스별 칼럼 생성 엔진"으로 추상화했으니, 나중에 새 소스를 추가하는 건 설정만 바꾸면 된다.

이것도 결국 팀 리딩의 영역이었다. 초기 설계 논의에서 "3개월 뒤 우리가 이 코드를 어떻게 확장하고 싶을 것 같나"를 팀원들과 함께 예상하고, 그에 맞춰 아키텍처를 잡는 것이 중요했다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.