콘텐츠 자동화를 끝까지 무인으로 돌리면 편하지만 위험합니다. 특히 의료처럼 규제가 있는 분야에서는 사람이 마지막에 한 번은 봐야 합니다. 문제는 그 사람 개입을 얼마나 가볍게 만드느냐입니다. 이 글은 슬랙 승인 자동화로 발행 승인을 무인 흐름에 녹이되, 위험한 콘텐츠는 원클릭 승인을 막은 승인 게이트 설계를 정리한 것입니다.
슬랙 승인 자동화란 무엇인가
슬랙 승인 자동화란, 콘텐츠가 검수를 통과하면 슬랙으로 요약과 리뷰 링크가 오고, 담당자가 버튼 하나로 승인·반려하면 나머지가 자동으로 이어지는 구조입니다. 사람은 콘텐츠를 직접 만들거나 복잡한 관리 화면에 들어가지 않고, 이미 익숙한 슬랙에서 결정만 내립니다. 이것이 사람을 흐름 안에 두는(human-in-the-loop) 설계입니다.
원장에게 가는 슬랙 카드는 무겁지 않습니다. 주제·카테고리·요청 ID와 리뷰 페이지 링크만 담고, 네 채널 결과 전문은 링크 너머의 한 화면에서 봅니다. 승인하면 발행·적재가 이어지고, 반려하면 사유가 다음 생성에 반영됩니다.
위험한 콘텐츠는 원클릭 승인을 막는다
여기서 핵심 설계가 나옵니다. 모든 콘텐츠에 승인 버튼을 똑같이 주지 않습니다. 검수 결과가 위험(BLOCK/HIGH)인 콘텐츠는 슬랙 카드에서 [승인] 버튼 자체가 제거됩니다. 대신 "높은 위험, 수동 검토 필요" 안내와 반려 버튼만 남습니다.
이것이 중요한 이유는, 사람은 버튼이 있으면 습관적으로 누르기 때문입니다. 바쁜 원장이 카드를 훑고 반사적으로 [승인]을 누르는 순간, 의료광고법 위반 콘텐츠가 나갈 수 있습니다. 버튼을 아예 없애면 그 실수 경로가 구조적으로 막힙니다. 위험한 콘텐츠는 서버 측에서 승인 버튼을 렌더링하지 않으므로, 클라이언트를 조작해도 원클릭 승인이 불가능합니다.
3초 안에 응답하고 일은 뒤로 넘긴다
슬랙 버튼에는 기술적 제약이 있습니다. 버튼을 누르면 3초 안에 응답해야 하고, 안 그러면 슬랙이 실패로 표시합니다. 하지만 승인 뒤에 이어지는 실제 작업(상태 갱신, 서빙링크 적재, 카드 업데이트)은 3초보다 오래 걸립니다.
그래서 두 단계로 나눕니다.
- 버튼을 받으면 즉시 응답만 먼저 보냅니다.
- 실제 작업은 백그라운드 작업으로 넘겨 따로 처리합니다.
한 가지 함정이 있습니다. 백그라운드 작업을 그냥 띄우면, 참조가 약해 작업이 끝나기도 전에 사라질 수 있습니다. 그래서 실행 중인 작업을 강하게 붙들어 두고, 끝나면 정리하도록 했습니다. 이렇게 해야 상태 갱신 같은 중요한 후속 처리가 조용히 유실되지 않습니다.
반려는 사유와 함께 재실행으로
반려도 그냥 거절이 아닙니다. 담당자가 반려하면 사유를 입력하는 창이 뜨고, 그 사유가 다음 생성에 반영되어 콘텐츠가 재실행됩니다. 반려 사유는 앞부분만 잘라 프롬프트에 넣어 주입 위험을 줄이고, 전체 내용은 로그에 남기지 않습니다. 숏폼 대본이 후킹 구조 규칙을 반복해서 못 맞추면, 자동 승인을 막고 수동 검토로 넘깁니다.
데이터와 UI를 나눠 이중 경로로 처리한다
승인 처리에는 두 가지 일이 섞여 있습니다. 하나는 상태와 서빙링크 같은 데이터를 바꾸는 일, 다른 하나는 슬랙 카드를 갱신하는 화면을 바꾸는 일입니다. 이 둘을 한 덩어리로 묶으면, 슬랙 화면 갱신이 실패했을 때 데이터까지 어정쩡한 상태로 남을 수 있습니다.
그래서 데이터 변경은 공용 서비스가 단일 진실로 처리하고, 슬랙 카드 갱신은 그 위에 얹는 별도 계층으로 두었습니다. 발행 여부를 결정하는 상태는 한 곳에서만 바뀌고, 화면은 그 결과를 비추기만 합니다. 이렇게 나누면 슬랙 쪽에 문제가 생겨도 발행 상태 자체는 일관되게 유지되고, 웹 리뷰 페이지에서 들어온 승인·반려도 같은 서비스를 거쳐 동일하게 처리됩니다. 사람이 어느 경로로 결정하든 결과가 갈라지지 않는 것이 핵심입니다.
이 승인 게이트는 무인 파이프라인의 마지막 사람 관문입니다. 이 관문 앞의 검수·기획·카피가 어떻게 엮이는지는 멀티에이전트 마케팅 자동화 아키텍처에서, 전체 사례는 의료 마케팅 자동화 OS 사례에서 볼 수 있습니다.
자주 묻는 질문
발행 승인을 슬랙으로 무인화하면 어떤 점이 좋나요?
담당자가 콘텐츠를 직접 만들거나 복잡한 관리 화면에 들어가지 않고, 익숙한 슬랙에서 요약과 링크만 보고 버튼으로 결정합니다. 사람 개입을 최소한으로 줄이면서도 최종 발행 전 확인이라는 안전장치를 유지할 수 있습니다.
위험한 콘텐츠의 원클릭 승인은 어떻게 막나요?
검수 결과가 위험으로 나오면 슬랙 카드에서 승인 버튼 자체를 제거합니다. 버튼이 서버 측에서 렌더링되지 않으므로, 반사적으로 누르거나 클라이언트를 조작해도 원클릭 승인이 불가능하고 수동 검토 경로로만 처리됩니다.
슬랙 버튼이 3초 제한이 있다는데 긴 작업은 어떻게 하나요?
버튼을 받으면 즉시 응답만 먼저 보내고, 상태 갱신·적재 같은 실제 작업은 백그라운드로 넘깁니다. 이때 작업이 끝나기 전에 사라지지 않도록 강하게 붙들어 두어야 후속 처리가 유실되지 않습니다.
반려하면 콘텐츠는 어떻게 되나요?
반려 시 사유를 입력받고, 그 사유가 다음 생성에 반영되어 콘텐츠가 재실행됩니다. 사유는 앞부분만 프롬프트에 넣어 주입 위험을 줄이고 전체 내용은 로그에 남기지 않습니다. 숏폼 대본이 후킹 구조 규칙을 반복해서 못 맞추면 자동 승인을 막고 수동 검토로 넘겨, 재실행이 무한히 도는 것을 방지합니다.
웹 리뷰 페이지에서 승인한 것과 슬랙에서 승인한 것이 다르게 처리되나요?
같게 처리됩니다. 상태를 바꾸는 로직은 한 곳의 공용 서비스가 단일 진실로 담당하고, 슬랙 카드나 웹 페이지는 그 결과를 비추는 화면일 뿐입니다. 사람이 어느 경로로 결정하든 발행 상태가 갈라지지 않도록 데이터 계층을 하나로 모았습니다.