← Work

사내 웹 서비스 · 외주 작가·내부 팀용

SNS 콘텐츠 제작 워크플로

외주 작가의 원고 접수부터 내부 검수, 발행 일정, 경영진 보고서까지 한 곳에서 처리하는 콘텐츠 워크플로.

쓰는 사람
외주 작가 · 내부 검수자 · 디자이너 · 관리자
맡은 일
기획 · 설계 · 구현 · 운영
다루는 채널
숏폼 영상 · 이메일 뉴스레터 · 블로그 · 내부 제작
기술
Next.js · Postgres · 사내 통합 로그인 · LLM · 인쇄용 HTML

문제

원고는 흩어지고, 진행 상황은 담당자 머릿속에만 있었다

SNS 채널 세 곳을 채널마다 다른 외주 작가가 맡고 있었습니다. 원고를 받는 창구도 채널마다 달라서 한 곳은 협업 문서, 한 곳은 이메일, 한 곳은 아직 정해지지 않은 상태였습니다. 어떤 원고가 몇 번째 수정 중인지는 담당자만 알았습니다.

원고 한 건이 보고서에 실리기까지
  1. 외주 작가

    채널마다 다른 창구

  2. 담당자 기억

    몇 차 수정인지 추적

  3. 내부 검수

    메신저·메일 왕복

  4. 격주 보고서

    슬라이드를 손으로 작성

범용 협업 도구도 검토했지만 맞지 않았습니다. 발행일은 작가에게 숨겨야 했는데, 외부 참여자에게 칸 단위로 숨기는 기능이 없었습니다. 단계와 수정 차수도 결국 사람이 기억해서 지켜야 했습니다. 규칙을 사람의 습관에 맡기면 오래 지켜지지 않는다고 판단했습니다.

기획

규칙은 사람의 습관이 아니라 시스템이 지킨다

콘텐츠 한 건의 상태를 네 개의 축으로 나눴다

진행 단계

  • 기획안
  • 상세 기획
  • 컷 편집본
  • 제작 자료
  • 내부 제작

검토 상태

  • 작성 중
  • 검토 대기
  • 수정 요청됨
  • 확정

발행 상태

  • 일정 미정
  • 발행 예정
  • 발행 완료

처분

  • 진행
  • 발행 포기
상태를 한 줄로 세우지 않고 네 축으로 나눈다
'촬영본 피드백 중인데 발행은 다음 달로 미룰 예정' 같은 상황을 상태 하나에 담으려면 상태 종류가 끝없이 늘어납니다. 진행 단계, 검토, 발행, 처분을 따로 두면 조합으로 표현됩니다. 발행 여부는 발행 상태 한 곳에만 기록합니다.
제출본은 고칠 수 없고, 의견은 특정 버전에 붙는다
'몇 차 수정안에 대한 의견인지'가 헷갈리지 않게 했습니다. 제출된 원고와 이력은 데이터베이스 단에서 수정·삭제를 막았고, 의견을 적는 자리는 한 번에 한 곳만 열리게 해서 대화가 두 군데로 갈라지지 않게 했습니다.
쓰이지 않는 칸은 지운다
처음에는 월 단위로 카드를 묶고 계약 물량을 세는 칸이 있었습니다. 운영 데이터를 보니 만들어 둔 달이 모두 열린 채였고 마감 설정은 한 번도 쓰이지 않았습니다. 월 구분과 물량 카운터를 없애고, 메인 화면을 '진행 중 / 확정·발행 전 / 최근 발행'이라는 작업 상태 기준으로 바꿨습니다.
경영진 보고서는 도구 안의 데이터로 만든다
발행 예정·발행 완료 카드를 기간으로 모아 인쇄용 지면을 자동으로 조립합니다. 뉴스레터 카드에 확정된 본문이 없으면 조용히 빠뜨리지 않고 생성 자체를 막습니다. 지면에는 '검토 중' 같은 작업 상태를 싣지 않습니다.

결과물

접수부터 검수, 발행, 보고까지 한 도구에서

외주 채널 + 내부 제작
3 + 1
상태 축
4
기획서에서 첫 버전 운영까지
3일
보고서 지면 자동 조립
16:9
상황판. 맨 위에 검토를 기다리는 제출물이 모이고, 그 아래 채널마다 진행 중, 확정·발행 전, 최근 발행 세 구획이 이어집니다. 줄마다 유형, 제목, 단계, 검토 상태, 작가가 보입니다.
카드 상세. 위쪽에 단계 진행이 보이고, 본문에는 회차별 제출본과 그 버전에 붙은 의견이 쌓입니다. 검수자는 수정 요청이나 확정으로 판정합니다. 오른쪽 발행 칸의 일정은 작가에게 보이지 않습니다.
보고서 화면. 기간을 고르면 카드별로 지면에 실릴 본문(확정본, 제출본, 작업본, 본문 없음)을 먼저 보여 주고, 아래 16:9 지면에서 글자를 눌러 바로 고칩니다. 고친 값은 보고서에만 적용되고 카드 원문은 그대로 둡니다.

AI 초안은 초안까지만

내부 제작 트랙에서는 기사 링크를 넣으면 카드뉴스 한 장의 초안(표지 문구, 핵심 세 줄, 캡션, 해시태그)을 LLM이 씁니다. 초안 속 숫자를 원문과 대조한 결과를 함께 보여 주고, 사람이 고쳐서 저장하기 전에는 아무것도 남기지 않습니다. 튜닝하면서 배운 것은 규칙 문장보다 예시 하나가 더 세게 작동한다는 점이었습니다. 핵심 줄 수는 지면이 넘쳐서 다섯에서 셋으로 줄였습니다.

쓰이면서 고친 것

영상에서 장면을 캡처하는 게 느렸다
보고서 지면에 넣을 장면을 공유 드라이브 영상에서 캡처하는데 기다림이 길었습니다. 재 보니 원인은 요청 횟수였습니다. 당시 측정한 영상에서는 요청마다 3초 넘는 고정 시간이 붙었습니다. 영상을 조각조각 받지 않고 통째로 받도록 바꿔, 60MB가 넘는 영상도 요청 두 번으로 끝나게 했습니다.
화면마다 느린 이유가 설정 하나였다
앱 서버와 데이터베이스가 서로 다른 지역에 있어서, 데이터베이스를 한 번 오갈 때마다 약 0.2초가 붙었습니다. 두 곳을 같은 지역으로 맞췄습니다. 5분마다 도는 알림 작업이 데이터베이스의 자동 정지를 막고 있던 것도 한 시간 주기로 바꿨습니다.

회사와 업종, 사람과 브랜드는 밝히지 않았습니다. 화면은 실제 캡처가 아니라 구조를 다시 그린 것이라 문구와 배치가 실제와 조금 다릅니다.