같은 소재라도 플랫폼의 노출 방식이 다르면, 다른 글이어야 한다.
카드뉴스 스튜디오의 콘텐츠 생성 포맷은 '카드뉴스'와 '브런치/블로그' 두 가지였습니다. format='blog' 하나로 브런치와 티스토리를 모두 처리했고, 시스템 프롬프트도 "브런치나 기술 블로그에 올릴 수 있는 에세이"를 쓰라는 하나의 지시문뿐이었습니다. 결과물은 항상 존댓말 에세이체의 장문 글 하나였고, 그걸 브런치에도 티스토리에도 그대로 쓸 수밖에 없었습니다.
format 값을 'brunch'와 'tistory' 두 개로 분리하고, 각각 독립된 생성 함수(generateBrunchContent / generateTistoryContent)와 시스템 프롬프트를 만들었습니다. 브런치용은 짧은 문단과 여백, 흐름 중심의 에세이 구조를 유지하면서 검색 키워드를 억지로 넣지 않도록 지시했고, 마무리에 구독 유도 문구를 넣도록 했습니다. 티스토리용은 H2/H3 소제목으로 명확히 구조화하고, 제목에 검색 키워드를 자연스럽게 포함하며, 정보성 소재는 "문제 상황 → 원인 → 해결 → 검증" 골격을 따르도록 했습니다. UI 드롭다운도 카드뉴스/브런치/티스토리 3분기로 늘렸고, (post_id, format) unique 제약을 그대로 활용해 같은 게시글로 두 초안을 동시에 보관할 수 있게 됐습니다.
콘텐츠 생성 스튜디오에서 '브런치/블로그'로 뭉쳐 있던 포맷을 브런치용과 티스토리용으로 분리한 과정을 기록합니다. 무작정 나누기 전에 두 플랫폼에서 조회수가 잘 나오는 글의 특징을 웹서치로 먼저 조사했고, 그 차이를 실제 프롬프트 규칙으로 옮겼습니다. "만들 수 있다"와 "만들 가치가 있다"는 다른 문제라는 원칙을, 이번엔 콘텐츠 생성 로직에도 적용해본 사례입니다.
원래는 "하나의 엔진으로 여러 플랫폼용 콘텐츠를 만든다"는 포트폴리오 원칙에 맞춰, 카드뉴스처럼 하나의 생성 로직 안에서 포맷만 다르게 처리하면 된다고 생각했습니다. 하지만 브런치와 티스토리의 조회수 구조를 웹서치로 확인해보니, 둘은 노출 메커니즘 자체가 다릅니다. 브런치는 다음 포털 노출과 에디터 추천이 핵심이라 에세이체와 구독자 관계가 중요하고, 티스토리는 구글 SEO가 핵심이라 제목의 키워드와 문서 구조가 중요합니다. 같은 규칙으로 두 플랫폼용 글을 만드는 건 "하나의 엔진"이 아니라 "둘 다 절반만 최적화된 상태"였다는 걸 깨달았고, 그래서 프롬프트 규칙 자체를 분리하는 쪽으로 재설계했습니다.
format 컬럼에 데이터베이스 레벨의 CHECK 제약이 없었기 때문에, 스키마 변경 없이 애플리케이션 코드(생성 함수 분리 + UI 드롭다운 분기)만으로 완결됐습니다. 이 패턴 — 하나의 카테고리형 컬럼에 새 값을 추가하고, 그 값에 대응하는 생성 함수와 프롬프트를 독립적으로 만드는 방식 — 은 이후 인스타그램, 스레드, 링크드인처럼 또 다른 플랫폼이 추가될 때도 동일하게 반복할 수 있습니다. 핵심은 "플랫폼을 늘릴 때마다 프롬프트를 분기 처리하지 말고, 플랫폼마다 완전히 독립된 생성 함수를 만드는 것"입니다.
관련 프로젝트
프로젝트 개요 기획자(PM)로서 AI를 활용한 업무 자동화(AX) 사례를 문서화하는 개인 포트폴리오 사이트입니다. 국내 기업의 AX 기획자/AI PM 직군으로의 커리어 전환을 목표로, 사이트 자체가 채용 지원용 스토리텔링 자료로 실사용되고 있습니다. 핵심 패턴: 업무 병목 발견 → AI로 워크플로우 재설계 → Before/After·근거·재현 가능성 문서화 전체 서사는 '실행하지 않은 아이디어 나열'이 아니라, 하나의 검증된 자동화 패턴과 도메인별 확장 블루프린트를 갖춘 재사용 가능한 엔진을 보유하는 방향으로 수렴하고 있습니다. 기술 스택 Next.js 16, Tailwind CSS v4, TypeScript Supabase (개발/운영 환경 분리), Vercel, Resend Claude API 기반 기술 자문 및 프롬프트 설계 보안 아키텍처 관리자 CRUD는 세션 기반 인증과 RLS(Row Level Security)로 보호 공개 읽기 전용 경로는 별도의 익명 클라이언트로 분리 서비스 롤 키는 애플리케이션 코드에서 완전히 배제 권한 검증은 마이그레이션 파일 및 대시보드 검토를 통해서만 진행 작업 방식 (에이전틱 IDE 협업 워크플로우) AI 에이전트 기반 IDE가 파일/버전관리 작업을 담당하고, LLM은 기술 자문 및 프롬프트 작성 역할을 수행하는 협업 구조를 운영합니다. AI 자문 → 에이전트용 프롬프트 작성 → 실행자가 붙여넣기 → 계획 확인 → 자문 검토 → 실행 승인 → 로그 검토 → 직접 클릭 테스트 → 명시적 지시 시에만 커밋 통제 규칙 실행 전 계획 검토 필수 요약 보고가 아닌 직접 클릭 테스트로 검증 개발 환경 우선 적용 후 명시적 승인 하에 운영 환경 반영 커밋은 명시적 지시가 있을 때만 수행 DB 자격증명 직접 연결 및 범위 외 삭제 금지 브랜치 전략: 개발 브랜치에서 작업 후 운영 브랜치는 배포 전용으로 직접 커밋 금지, 병합 전 변경 범위 검증 현재 진행 상황 고객사 미팅 브리핑 자동화 사례: 1단계 완료, 개발/운영 환경 배포 및 실데이터 테스트 완료 범위 변경 감지 자동화 사례: 상태 확인 진행 중 리스크 조기 경보 자동화 사례: 운영 환경 배포 완료 보안 사고 관련 포스트: 'AI 리스크 거버넌스 사례'로 재구성 예정 AI 활용 관련 콘텐츠 시리즈 초안 작성 완료, 게시 미확정 핵심 학습 원칙 보고가 아닌 검증: 버그·보안 이슈는 항상 직접 로그/브라우저 검토를 통해서만 발견되며, 에이전트의 자체 결과 요약을 그대로 신뢰하지 않음 보안 사고의 콘텐츠화: 실제 발생한 권한 관련 이슈 사례를 케이스 스터디로 재구성하여 콘텐츠화 커밋 의미 분리: 기능 단위/변경 유형별로 항상 분리 커밋 자동화하지 않는 것도 스토리: 저사용 빈도 기능을 의도적으로 고도화하지 않은 결정 자체를 AX 스토리텔링 소재로 활용