SNS 포스팅 자동화, Claude Code로 하루 검토 80분을 10분 목표로

SNS 포스팅 자동화가 왜 필요했나?

문제는 글을 못 쓴다는 점이 아니라, 매일 쓰는 짧은 글 한 편이 하루 50~80분을 가져간다는 점이었습니다. 저희는 만드는 과정을 X와 Threads에 공개하는 일지를 매일 올리고 있었습니다. X에는 영어로 네 개짜리 연결 글(스레드)을, Threads에는 한국어로 긴 글 한 편을 올리는 방식입니다.

공개 일지는 회사를 알리는 채널이라 멈추고 싶지 않았습니다. 다만 대표 한 사람이 운영하는 회사에서 하루 한 시간 남짓은 작은 시간이 아닙니다. 그 시간은 고객 일과 제품 개발에서 그대로 빠져나갑니다.

그래서 저희는 이 일지에 미리 예산을 걸어 두었습니다. 공개 일지에 쓰는 시간은 주 2시간을 넘기지 않는다는 상한입니다. 상한을 정한 이유는 단순합니다. 알리는 일이 만드는 일을 잡아먹기 시작하면, 알릴 거리 자체가 줄어들기 때문입니다.

문제는 이 상한을 정해 놓고도 실제로 얼마를 쓰는지 따로 계산해 보지 않았다는 점입니다. 2026년 4월 28일에 처음 계산을 해 보았고, 결과는 상한을 몇 배 넘긴 상태가 이미 쌓여 있었다는 사실이었습니다.

처음 잰 숫자: 하루 50~80분, 주 6~9시간

계산 방법은 하루 작업 시간에 7일을 곱하는 방식이었습니다. 하루 수작업 시간은 50~80분이었고, 여기에 7일을 곱하면 시간으로 주 6~9시간이 나옵니다. 상한 주 2시간과 비교하면 적게 잡아도 3배, 많이 잡으면 4배를 넘습니다.

이 계산이 중요한 이유는 하루 단위로는 문제가 잘 보이지 않기 때문입니다. 하루 50분은 점심시간 정도로 느껴져 아무도 문제 삼지 않습니다. 같은 시간을 일주일로 모아 상한 옆에 놓아야 비로소 몇 배를 넘었는지가 드러납니다. 매일 반복하는 작은 일일수록 주 단위로 다시 계산해 보는 습관이 필요합니다.

측정 방식의 한계도 같이 적어 둡니다. 설계 문서에는 이 50~80분을 어떤 도구로 쟀는지가 적혀 있지 않습니다. 값이 한 점이 아니라 범위로 적힌 점을 보면, 타이머로 기록한 값보다는 하루 작업 시간을 사람이 어림한 값으로 읽는 편이 정확합니다. 그래서 이 글에서는 이 숫자를 정밀한 측정값이 아니라 출발선을 잡기 위한 어림값으로 다룹니다.

숫자를 이렇게 놓고 보니 판단이 쉬워졌습니다. 일지를 줄이거나 끊는 길도 있었지만, 그러면 알리는 채널이 사라집니다. 남는 길은 같은 결과물을 더 적은 사람 시간으로 만드는 방법뿐이었습니다. 이때 목표로 잡은 값이 하루 5~10분 검토입니다. 7일로 곱하면 주 35~70분이라, 상한 주 2시간 안쪽으로 다시 들어옵니다.

세운 가설 세 가지는 무엇이었나?

설계 문서에는 자동화가 성립하려면 참이어야 하는 가정 세 개가 따로 적혀 있습니다. 셋 중 하나라도 무너지면 다음 버전에서 보정 작업을 시작한다는 조건도 함께 붙어 있습니다. 가정을 미리 써 두는 이유는, 나중에 결과가 나빴을 때 어느 고리가 끊겼는지 추적하기 위해서입니다.

• 가설 1: 사실 대조: 글쓰기 에이전트가 자연어 본문 속 주장에서 근거 자산(실제로 만든 파일·기능)을 찾아 대조하는 규칙이 95% 이상 정확하다.
• 가설 2: 글감 목록 동기화: 어떤 글감을 이미 썼는지 기록하는 목록이, 사람이 실제로 발행하지 않은 글을 따로 표시하는 규칙 없이도 제대로 굴러간다.
• 가설 3: 글감 재고: 미리 정리해 둔 글감 7개와 새로 추가하는 글감만으로 최소 운영 14일째까지 매일 쓸 거리가 떨어지지 않는다.

세 가정은 무게가 다릅니다. 가설 2와 3은 틀려도 사람이 금방 알아챕니다. 같은 글감이 두 번 나오거나 쓸 거리가 떨어지면 눈에 바로 보이기 때문입니다. 가설 1은 다릅니다. 사실 대조가 틀리면 그럴듯한 글이 그대로 나가고, 틀렸다는 사실은 누군가 지적하기 전까지 드러나지 않습니다.

운영 14일째라는 기준도 일부러 짧게 잡았습니다. 글감이 2주 만에 바닥나면 자동화가 아니라 글감을 모으는 방식부터 다시 설계해야 합니다. 반대로 2주를 버티면 그사이 새 작업이 쌓이면서 글감도 함께 늘어난다는 뜻이라, 그다음부터는 재고 걱정을 덜 수 있습니다. 짧은 기한을 걸어 두면 이 갈림길을 빨리 확인할 수 있습니다.

그래서 설계 문서도 이 가설 1을 결정 변수로 지목합니다. 새로 생기는 의존성은 글쓰기 에이전트의 사실 대조 정확도 하나이고, 이 값은 실제로 써 보면서 보정한다고 적었습니다. 자동화의 성패가 속도가 아니라 정확도에 걸려 있다는 판단입니다.

가설이 틀린 지점: 발행 도구를 바꾸면 끝난다는 생각

SNS 포스팅 자동화라고 하면 가장 먼저 떠오르는 답은 예약 발행 도구입니다. Buffer나 Hypefury 같은 외부 SaaS에 글을 넣어 두면 정해진 시간에 올려 줍니다. 설계 단계에서 이 방향도 대안으로 올렸고, 기각했습니다.

기각 사유는 두 가지였습니다. 하나는 한국어 일지를 따로 운영하는 구조와 맞지 않았다는 점입니다. 다른 하나는 보안 등급 제약입니다. 저희는 공개해도 되는 정보와 공개하면 안 되는 정보를 등급(Tier)으로 나눠 두고 글마다 이를 점검하는데, 외부 도구에 이 점검을 맡길 수는 없었습니다.

더 근본적인 이유는 시간이 쓰이는 자리였습니다. 예약 발행 도구가 줄여 주는 시간은 올리는 시간입니다. 그런데 하루 50~80분의 대부분은 올리는 데가 아니라 무엇을 쓸지 고르고, 쓴 내용이 실제로 만든 것과 맞는지 확인하고, 두 채널의 말투를 맞추는 데 들어갔습니다. 발행 도구를 바꾸면 끝난다는 생각은 병목의 위치를 잘못 짚은 가설이었습니다.

X API 직접 연동은 성격이 조금 다릅니다. 글을 올린 뒤 반응 수를 자동으로 모으는 기능이라 쓸모는 분명했습니다. 다만 첫 버전에 넣으면 범위가 감당할 수 없이 커질 위험이 있어서 다음 버전으로 미뤘습니다. 줄이려는 대상은 사람 시간인데, 그 시간을 줄이는 도구를 만드느라 시간을 더 쓰면 앞뒤가 바뀌기 때문입니다.

진짜 원인은 무엇이었나?

진짜 원인은 판단 기준이 문서에는 쌓여 있었는데, 매일 그 기준을 꺼내 적용하는 일을 사람이 손으로 하고 있었다는 점입니다. 일지를 쓰는 동안 저희는 말투, 글감 고르는 법, 사실을 검증하는 순서에 관한 원칙을 내부 학습 기록 문서에 다섯 항목으로 정리해 두었습니다. 기준은 이미 글로 존재했습니다.

그런데 매일 글을 쓸 때마다 사람이 그 원칙을 다시 떠올리고, 이번 글감을 이미 썼는지 기억을 더듬고, 글 속 주장이 실제로 만든 파일과 맞는지 하나씩 열어 확인했습니다. 일지용 글쓰기 에이전트도 이미 있었지만, 그 에이전트는 이 원칙들을 자동으로 읽지 않았습니다. 기준과 실행 사이를 사람이 매일 이어 붙이고 있었던 셈입니다.

하루 50~80분을 일의 종류로 나눠 보면 이 구조가 더 잘 보입니다. 글감 고르기는 기억에 기대는 일이고, 사실 확인은 파일을 하나씩 여는 일이고, 말투 맞추기는 원칙을 다시 읽는 일입니다. 셋 다 판단처럼 보이지만, 기준이 이미 문서에 있으니 사실은 조회에 가깝습니다. 사람이 매일 같은 문서를 다시 읽고 같은 확인을 반복하고 있었습니다.

이렇게 보면 자동화의 대상이 달라집니다. 글을 대신 써 주는 기능보다 먼저 세 가지가 필요했습니다. 원칙을 에이전트가 매번 자동으로 읽게 만드는 일, 이미 쓴 글감과 남은 글감을 파일 하나에 모아 두는 일, 글의 뼈대를 서식 하나로 고정하는 일입니다. 설계 문서가 원칙이 쌓였으니 자동화할 단계라고 적은 이유도 같습니다.

기준이 사람 머릿속에서 문서로 옮겨 온 순간이 자동화를 시작할 수 있는 순간이다. 문서로 옮겨 오기 전에 자동화하면 기계가 무엇을 지켜야 하는지 모른다.

조치: 파일 4개와 에이전트 1개 강화

조치는 두 갈래였습니다. 새 파일 4개를 만들고, 기존 에이전트 1개를 강화했습니다. 새 시스템을 처음부터 짓지 않고, 이미 있던 글쓰기 에이전트를 중심에 두고 앞뒤를 채우는 방식을 택했습니다. 구축에는 한 번에 4~6시간이 든다고 잡았습니다.

• 슬래시 커맨드 2개: /post-x(영어, X용)와 /post-threads(한국어, Threads용). 어느 프로젝트에서 작업하든 같은 명령으로 부를 수 있게 전역에 두었습니다.
• 글쓰기 에이전트 강화: 말투·글감·검증 원칙 다섯 항목을 매번 자동으로 읽고, 사실 대조를 건너뛸 수 없게 강제하고, 채널마다 다른 말투를 적용합니다.
• 글감 목록 파일(CATALOG.md): 이미 쓴 글감 이력, 쓸 수 있는 자산 목록, 다음에 고를 글감의 우선순위를 한곳에 둡니다.
• 서식 파일(TEMPLATE.md): X용 네 개짜리 연결 글과 보충 글, Threads용 단일 글, 그리고 보안 등급 점검·사실 대조·한글 번역 칸을 고정합니다.

슬래시 커맨드를 프로젝트마다 따로 두지 않고 전역에 둔 데에도 이유가 있습니다. 일지의 글감은 특정 저장소 하나가 아니라 그날 작업한 여러 프로젝트에서 나옵니다. 명령이 한 저장소에만 있으면, 다른 프로젝트에서 일하다가 일지를 쓰려면 작업 위치부터 옮겨야 합니다. 명령을 어디서나 같은 이름으로 부를 수 있게 해 두면 그 이동이 사라집니다.

서식 파일에 보안 등급 점검과 사실 대조 칸을 고정한 이유는 빠뜨릴 수 없게 만들기 위해서입니다. 사람이 손으로 쓸 때는 바쁜 날일수록 확인을 건너뛰기 쉽습니다. 서식에 칸이 있으면 그 칸이 비어 있는 초안은 눈에 바로 띕니다. 에이전트 지시서에서도 사실 대조를 선택이 아니라 강제 단계로 적었습니다.

흐름은 이렇습니다. 사람이 슬래시 커맨드 한 줄을 입력하면, 에이전트가 글감 목록에서 다음 글감을 고르고 원칙 문서를 읽은 뒤 서식에 맞춰 초안을 씁니다. 초안 안의 주장은 실제 자산과 대조하고, 보안 등급을 점검하고, 한국어 번역을 붙여서 넘깁니다. 사람에게 남는 일은 마지막 검토와 발행뿐입니다.

투자 대비 효과도 미리 계산했습니다. 구축에 4~6시간을 한 번 쓰고, 그 대가로 주 5~8시간을 아낀다는 계산입니다. 이 계산대로라면 4~7일이면 구축 시간을 회수하고, 1주일 뒤부터는 순이익 구간에 들어갑니다. 이 기간 동안 핵심 제품 개발에서 5시간을 한 번 빼 쓴다는 비용도 함께 적어 두었습니다.

같은 구조로 만든 다른 사례가 궁금하다면 Claude Code 맥락 유지, 세션이 끝나도 남는 문서 구조도 함께 보면 좋습니다. 원칙을 문서로 남기고 AI가 매번 그 문서를 읽게 만든다는 발상이 이 글과 같습니다.

재측정 결과: 합격선은 세웠고, 실측 기록은 비어 있다

이 부분은 솔직하게 적어야 합니다. 설계 문서는 첫 버전이 끝났다고 말하기 위한 합격선을 세 개 정해 두었습니다. 그런데 그 합격선에 견줘 실제로 다시 잰 값은 이 문서에 남아 있지 않습니다. 앞에서 쓴 하루 5~10분은 측정 결과가 아니라 설계 단계의 예상치입니다.

합격선의 구조 자체는 지금 봐도 쓸 만합니다. 시간 하나만 재지 않고 정확도와 안전을 같이 걸었기 때문입니다. 검토 시간이 10분으로 줄어도 사실 대조가 틀린 글이 나가면 실패로 칩니다. 반대로 정확해도 검토에 여전히 50분이 걸리면 역시 실패입니다. 셋을 동시에 만족해야 끝났다고 말할 수 있습니다.

그렇다면 다시 잴 때 무엇을 봐야 할까요? 검토 시간은 초안을 받은 시각부터 발행 버튼을 누른 시각까지를 매일 기록하면 됩니다. 사실 대조는 글 속 주장마다 맞음·틀림을 사람이 표시해 비율을 내고, 보안 등급은 발행 후 위반이 나온 글 수를 셉니다. 셋 다 대단한 장비 없이 기록 한 줄로 잴 수 있는 값입니다. 다만 처음부터 기록 형식을 정해 두지 않으면 나중에 되살릴 수 없습니다.

부족한 점도 분명합니다. 합격선을 정해 두고 그 값을 다시 재지 않으면, 설계 문서의 예상치가 시간이 지나면서 결과처럼 읽히기 시작합니다. 이 글을 쓰면서 원자료를 다시 열어 보고서야 하루 5~10분이 실측이 아니라 목표였다는 점을 분명히 확인했습니다. 그래서 이 글의 제목도 줄였다가 아니라 목표로 썼습니다.

남는 한계: 95% 정확도는 어떻게 검증해야 하나?

가장 큰 한계는 가설 1, 곧 사실 대조가 95% 이상 정확하다는 가정이 아직 증명 전이라는 점입니다. 같은 회사의 내부 학습 기록에는 이 가정이 왜 위험한지 보여 주는 사례가 이후에 세 건 쌓였습니다. 일지 자동화와 직접 관련된 사례는 아니지만, 자동 대조와 자동 검사가 어떻게 조용히 틀리는지를 보여 줍니다.

• 2026년 8월 16일: 웹 검색 요약이 존재하지 않는 정부 보고서를 만들어 냈습니다. 발행기관·연도·보고서명과 함께 “국내 기업 68%”라는 수치까지 붙어 있었고, 원문을 찾으려 하자 보고서도 수치도 없었습니다. 형식이 완벽할수록, 찾던 답과 딱 맞을수록 의심해야 한다는 교훈을 남겼습니다.
• 2026년 8월 31일: 영상 478편을 자동으로 분류한 집계에서, 원가를 분해한 근거를 담았다고 잡힌 문서가 41편이었는데 조건을 좁히자 17편으로 줄었습니다. 표본을 직접 열어 보는 절차가 없었다면 부풀려진 숫자를 그대로 믿었을 것입니다.
• 2026년 9월 18일: 기한 점검 검사기가 점검 대상 15항목 중 12개를 읽지 못하면서도 문제없음(초록불)을 내고 있었습니다. 파일에는 기한 표시가 10개 있었는데 검사기는 0개를 보았습니다.

세 사례가 일지 자동화에 주는 시사점은 하나입니다. 에이전트가 사실 대조를 통과했다고 말해도, 실제로 대조가 맞았다는 보장은 없습니다. 보안 등급 위반 0건이라는 합격선도 같습니다. 검사기가 눈을 감은 채 0건을 내면, 그 0건은 검사가 아예 없을 때보다 나쁩니다. 다음 사람이 확인했다고 믿기 때문입니다.

그래서 95% 정확도를 검증하는 방법은 정답이 알려진 표본으로 직접 재야 합니다. 일부러 틀린 주장을 섞은 초안을 넣고 에이전트가 그 틀린 주장을 몇 개 잡아내는지 세는 방식입니다. 보안 등급 점검도 위반이 들어 있는 초안을 넣었을 때 실제로 걸리는지부터 확인해야 0건이라는 숫자를 믿을 수 있습니다.

나머지 두 가정도 열려 있습니다. 글감 7개와 신규 추가분이 운영 14일째를 넘어서도 버티는지, 발행하지 않은 글을 표시하는 규칙 없이 글감 목록이 어긋나지 않는지는 운영 기간이 길어져야 드러납니다. 설계 문서의 규칙대로라면 셋 중 하나라도 무너지는 순간이 다음 버전의 보정 작업을 시작하는 신호입니다.

첫 버전에서 X API 연동을 뺀 대가도 여기서 드러납니다. 반응 수를 자동으로 모으지 않으니, 자동으로 쓴 글이 손으로 쓴 글보다 반응이 나은지 못한지를 숫자로 비교할 수 없습니다. 검토 시간을 줄이는 데는 성공해도, 그렇게 나간 글이 제 역할을 하는지는 따로 재야 합니다. 범위를 줄인 결정은 옳았다고 보지만, 그 결정이 남긴 빈칸도 함께 적어 둡니다.

직접 따라 하려면 무엇부터 재야 하나?

SNS 포스팅 자동화를 고민하는 회사라면 도구를 고르기 전에 하루 시간이 어디에 쓰이는지부터 나눠 보길 권합니다. 저희 경우에는 올리는 시간이 아니라 고르고 확인하는 시간이 대부분이었고, 그래서 예약 발행 도구가 아니라 판단 기준을 AI에게 넘기는 쪽으로 방향이 갈렸습니다.

• 먼저 주간 상한을 숫자로 정합니다. 저희는 주 2시간이었습니다. 상한이 없으면 넘었는지도 모릅니다.
• 하루 시간을 일주일로 곱해 상한과 비교합니다. 저희는 이 계산 한 번으로 주 6~9시간이라는 사실을 알았습니다.
• 판단 기준이 문서로 존재하는지 확인합니다. 기준이 머릿속에만 있으면 자동화보다 문서화가 먼저입니다.
• 합격선을 시간·정확도·안전 세 축으로 함께 겁니다. 시간만 재면 틀린 글이 빨리 나가는 결과도 성공처럼 보입니다.
• 합격선을 세웠으면 반드시 다시 잽니다. 저희가 아직 못 한 일이 바로 이 마지막 단계입니다.

사내에서 반복되는 글쓰기나 보고 업무를 AI로 줄이고 싶은데 어디서부터 재야 할지 막막하다면, 지금 쓰는 시간과 판단 기준을 정리해서 상담으로 보내 주세요. 같은 순서로 출발선부터 함께 잡아 보겠습니다.