AI SNS 자동화로 4개 채널과 블로그를 하나로 묶기

기존 production tkim.co

ALT

남자와 여자의 사진이 있는 한국 웹사이트

새 staging.tkim.co

ALT

10x 레슨 - 한국어 워드프레스 테마

소개

채용을 위해 글을 꾸준히 써야겠다고 생각했습니다. 우리 회사가 운영하는 커뮤니티형 교육과 AI 네이티브한 시도를 외부에 보여주면, 이런 방식에 관심이 많은 사람이 자연스럽게 회사를 발견하고 지원할 수 있을 것 같았어요.

문제는 글 한 편을 쓰는 것으로 일이 끝나지 않는다는 점이었습니다. 블로그에 올리고 Threads와 Instagram, LinkedIn, X에 맞게 다시 쓰고 영상이 있으면 숏폼도 만들고 뉴스레터로도 보내야 했습니다. SNS 네 곳에 같은 내용을 옮겨 적는 데만 약 한 시간이 걸립니다. 카드뉴스나 숏폼처럼 포맷까지 바꾸려면 훨씬 오래 걸리고요.

그래서 블로그 디자인만 고친 것이 아니라, 제 의견과 취향을 여러 콘텐츠 형식으로 바꿔 배포하는 시스템을 Codex와 함께 만들었습니다. 아직 새 블로그를 production으로 전환하기 전이지만 이 과정에서 어떤 결정이 중요했고 무엇을 잘못 만들었다가 다시 바꿨는지는 충분히 기록할 만하다고 느꼈습니다.

1단계 — 블로그와 뉴스레터를 계속 운영할 방법부터 다시 정했습니다

기존 tkim.co는 WordPress와 AWS Lightsail로 운영하고 있었습니다. 뉴스레터는 MailerLite Classic을 썼어요. 사이트와 이메일 서비스에 매달 비용이 나갔고 대부분이 한국 독자인데도 해외 뉴스레터 서비스를 계속 쓰는 게 맞는지 의문이 들었습니다. AWS의 WordPress 운영 환경도 앞으로 그대로 유지하기 어려울 수 있다는 소식이 있었고요.

처음 Codex에 한 요청은 꽤 넓었습니다.

지금 현재는 tkim.co 블로그를 WordPress + Lightsail + MailerLite Classic으로 쓰고 있어.
구독자는 [비공개]이고 한 달에 많아야 두 번 정도 뉴스레터를 보내.
회사에서 쓰는 스티비에 별도 그룹을 만들거나, Substack을 쓰거나,
사이트를 새로 만들고 SES 같은 저렴한 이메일 서비스를 쓰는 방법도 있을 것 같아.
어떤 옵션이 있는지 조사해서 알려줘.

Codex는 WordPress를 유지하는 방법, 정적 사이트로 옮기는 방법, Substack, 스티비, 이메일 발송 기능을 직접 만드는 방법을 비교했습니다. 비용만 보면 다른 답이 나올 수 있었지만 제가 더 중요하게 본 조건은 따로 있었어요.

• 한국 독자의 메일함에 안정적으로 도착할 것

• 글을 쓰고 보내는 과정이 어렵지 않을 것

• 반복되는 운영은 AI 에이전트에게 맡길 수 있을 것

• 기존 글의 주소와 검색 자산을 잃지 않을 것

결국 WordPress와 Lightsail은 유지하고 MailerLite만 회사에서 이미 사용 중인 스티비로 옮기기로 했습니다. 회사 워크스페이스 안에서도 다른 뉴스레터와 섞이지 않도록 tkim.co 전용 주소록을 만들었어요.

여기서 중요한 판단은 가장 새로운 도구를 고르는 것이 아니었습니다. 기존에 쌓인 글과 댓글, 검색 유입은 보존하면서 불편한 부분만 바꾸는 쪽을 택했습니다. 한 번에 모든 것을 갈아엎으면 보기에는 시원하지만 이전 과정에서 잃을 것도 많기 때문입니다.

2단계 — AI에게 계획서가 아니라 실제 staging 사이트를 만들게 했습니다

처음에는 다른 AI가 이어받아도 이해할 수 있는 블로그 개편 기획안을 요청했습니다.

WordPress + Lightsail + 회사 스티비 스탠다드 안으로 갈래.
지금 tkim.co에는 나에 대한 소개가 없고 SNS 글을 모아 보는 기능도 없어.
같은 내용을 여러 SNS에 올린다는 점도 고려해서,
개인 블로그와 오디언스 운영의 베스트 프랙티스를 검토하고 개선 계획을 작성해줘.
맥락이 없는 AI도 읽고 수행할 수 있게 해줘.

기획안을 받은 뒤에는 한 단계 더 나갔습니다. Codex가 Lightsail을 직접 다뤄 새 서버를 만들고 기존 글과 댓글, 이미지를 복제하고 테마와 운영 기능을 구현하도록 했어요. 기존 production은 그대로 둔 채 staging.tkim.co라는 별도 환경에서만 작업하게 했습니다.

새 블로그에는 장문의 블로그 글과 짧은 SNS 글을 나눠 담는 구조를 만들었습니다. 같은 생각을 Threads, LinkedIn, Instagram, X에 올려도 블로그에는 SNS 글 하나만 남고 각 플랫폼의 원문 링크가 그 아래 연결되는 방식이었습니다. 소개 페이지와 뉴스레터 구독, 북클럽도 같은 사이트 안에 넣었습니다.

AI가 인프라와 코드를 직접 다룬 점은 예상보다 잘됐습니다. 새 WordPress 설치, HTTPS, 복구용 snapshot, 기존 콘텐츠 복제, 별도 권한을 가진 콘텐츠 에이전트까지 한 흐름에서 만들 수 있었어요. 제가 혼자 했다면 자료를 찾아가며 몇 주나 몇 달에 걸쳐 진행했을 일입니다. 그만큼 시간을 내기 어려워 중간에 멈췄을 가능성도 큽니다.

그렇다고 첫 결과가 바로 마음에 들었던 것은 아닙니다.

3단계 — 첫 디자인을 버리고 제 취향을 고르는 방식부터 바꿨습니다

첫 staging 사이트는 기능적으로는 동작했지만 제 취향과 달랐습니다. 저는 여백이 많고 미니멀하면서도 글의 이미지를 크게 활용하는 구성을 좋아합니다. 그런데 말로만 “미니멀하게 만들어줘”라고 하니 AI와 제가 떠올리는 화면이 달랐어요.

그래서 완성된 화면을 계속 말로 고치는 대신, 먼저 참고할 만한 블로그를 찾아오게 했습니다.

나는 미니멀한 것을 추구하고 블로그 글에 일부러 이미지를 넣어서
이미지 중심으로 글 목록을 나열해왔어.
미니멀하면서도 이미지를 시각 요소로 잘 챙긴 블로그 외관을 조사해서
따라 만들 후보 10개를 찾아줘. 내가 직접 보고 고를게.

후보를 직접 보고 하나를 선택하니 대화가 훨씬 쉬워졌습니다. AI는 선택한 레퍼런스의 큰 구성 원리를 가져오되 tkim.co에 필요한 블로그 글, SNS 글, 소개, 뉴스레터, 북클럽 기능을 맞춰 넣었습니다. 첫 화면에는 10x Lessons라는 이름을 크게 드러내고 글의 첫 이미지를 목록의 시각 요소로 사용했습니다.

이 과정에서 얻은 가장 실용적인 팁은 디자인을 잘 설명하려고 애쓰기보다 비교할 대상을 먼저 모으는 것이었습니다. AI에게 대략적인 취향과 필요한 기능을 알려주고 레퍼런스를 찾게 한 뒤 사람이 고르면 됩니다. 선택 이후의 수정은 훨씬 구체적이고 빨라졌어요.

제 취향이 반영된 콘텐츠 시스템을 만드는 일이 중요하다는 것도 알게 됐습니다. 자동화가 아무리 잘돼도 결과물이 마음에 들지 않으면 결국 쓰지 않게 됩니다. 꾸준함은 의지만의 문제가 아니었습니다. 내가 계속 쓰고 싶은 화면과 흐름을 만드는 일에 가까웠어요.

4단계 — MailerLite 이전은 ‘전부 복사’가 아니라 ‘옮겨도 되는 사람만 옮기기’였습니다

MailerLite에서 스티비로 구독자를 옮기는 작업도 Codex와 함께 진행했습니다. 여기서는 전체 목록을 그대로 복사하지 않았습니다. 현재 구독 중인 사람, 수신거부한 사람, 반송된 주소, 스팸 신고, 아직 확인되지 않은 구독자를 나눠야 했습니다.

실제 구독자 수는 이 글에서 공개하지 않지만 이전 대상은 활성 구독자로 한정했습니다. 수신거부와 반송, 스팸 신고 주소는 억제 목록으로 분리하고 미확인 구독자는 제외했습니다. 활성 목록과 억제 목록이 겹치지 않는지도 확인했습니다.

발신 주소는 새 계정을 만들지 않고 기존 [email protected]를 사용했습니다. 스티비에서 이메일 인증과 SPF, DKIM, DMARC를 확인하고 전체 발송 전에 제 주소 한 곳으로 시험 메일을 보내 받은편지함 도착까지 확인했어요. 원래 MailerLite 목록은 문제가 생겼을 때 되돌릴 수 있도록 그대로 남겨두었습니다.

초기 설계에서는 구독자를 ‘긴 글만’, ‘주간 요약만’, ‘모두 받기’로 나누려 했습니다. 실제로 운영하려고 보니 가입 설명도 복잡해지고 주소록 관리도 번거로웠습니다.

긴 글, 주간 요약, 광고성 정보 동의처럼 여러 가지로 나눠서
복잡하게 관리하고 싶지 않아. 각각 따로 구독자를 모으는 것도 힘들어.
그냥 하나로 통일할 수는 없을까?

결국 주소록도 하나, 뉴스레터도 하나로 줄였습니다. 월요일에는 지난주 블로그 글과 SNS 글을 묶고 새 블로그 글이 있으면 수요일에 한 번 더 소개하는 단순한 원칙만 남겼습니다.

AI를 활용하면 복잡한 기능을 많이 넣기 쉬워집니다. 그래서 오히려 운영자가 감당할 수 없는 기능을 덜어내는 판단이 필요했습니다.

5단계 — 처음에는 SNS 글을 다시 가져오는 자동화를 만들었습니다

블로그에 SNS 글을 모으려면 각 SNS에 이미 올린 게시물을 하루에 한 번 읽어오는 방법이 자연스러워 보였습니다. 처음에는 실제로 이 구조를 만들었습니다.

내 SNS를 하루에 한 번 확인해서 내가 올린 글을 가져오고
블로그의 SNS 글에 추가했으면 좋겠어.
매주 월요일 오전 7시에는 SNS 글과 블로그 글을 모아 뉴스레터로 보내고
새 블로그 글이 있으면 수요일 오전 7시에 소개해줘.

서버는 매일 SNS를 확인하고 뉴스레터 초안을 준비하고 Codex의 예약 작업은 스티비에서 내용을 검토하고 예약하는 방식이었습니다. 당시 요청에는 잘 맞는 설계였어요.

그런데 실제로 콘텐츠를 만들어보면서 출발점이 잘못됐다는 걸 알게 됐습니다.

저는 영상을 보거나 글을 읽다가 떠오른 생각을 먼저 글로 정리합니다. 한번은 영상을 보고 느낀 점을 글로 쓴 뒤, 그 문장을 인용할 수 있는 숏폼을 만들어봤습니다. 글을 원본으로 잡으니 어떤 부분을 영상으로 강조할지 정하기 쉬웠어요.

여기서 콘텐츠 운영의 방향이 달라졌습니다. SNS에 가서 먼저 글을 쓰고 나중에 블로그로 가져오는 것이 아니라, AI 에이전트에게 생각을 주고 원문을 만든 다음 필요한 포맷으로 바꾸는 편이 맞았습니다.

텍스트는 카드뉴스의 문장이 될 수 있고 원본 영상과 결합하면 숏폼의 대본이나 인용구가 될 수 있습니다. 같은 원문을 플랫폼별 글로도 바꿀 수 있고요. 콘텐츠의 시작점이 SNS가 아니라 제 생각과 AI 에이전트 사이의 작업 공간으로 이동한 셈입니다.

6단계 — SNS 역수집을 없애고 전용 에이전트 스킬을 만들었습니다

새 흐름을 구현하기 위해 publish-social-posts라는 에이전트 스킬을 만들었습니다.

여러 SNS에 한 방에 글을 올리기 위해
각 플랫폼에서 인증받고 API로 글을 쓰는 스킬을 만들어보자.

현재 스킬의 흐름은 이렇습니다.

1단계 — 제가 영상이나 글을 보고 느낀 점을 Codex에 줍니다.

2단계 — AI가 한국어 원문을 정리합니다. 제 어조와 문장은 가능한 한 그대로 둡니다.

3단계 — Threads, Instagram, LinkedIn, X에 맞춘 전체 미리보기를 만듭니다. X에는 전체 의미를 살린 영문판을 만들고 긴 글은 플랫폼 제한에 맞춰 여러 게시물로 나눕니다.

4단계 — 관점이 지나치게 좁거나 오해를 부를 만한 대목만 따로 표시합니다. AI가 마음대로 고치지 않고 제가 원문 유지나 수정을 선택합니다.

5단계 — 미리보기 승인과 실제 게시 승인을 따로 받습니다. 마지막 승인이 있어야 각 SNS의 공식 API를 호출합니다.

6단계 — 게시 결과로 받은 URL과 ID를 WordPress의 SNS 글 하나에 합칩니다. X의 영문판이나 Threads의 여러 조각이 별도 글로 생기지 않습니다.

7단계 — 이 SNS 글은 다음 주 뉴스레터의 재료가 됩니다.

처음에는 AI가 플랫폼에 맞게 글을 짧고 매끈하게 바꾸는 것이 좋다고 생각했습니다. 실제 미리보기를 보니 제 생각의 논지와 말투가 많이 사라졌습니다.

원문의 톤과 문장은 최대한 유지해줘.
관점이 편협하거나 오해와 논란을 부를 부분만 따로 표시하고
그런 수정은 자동으로 하지 말고 내가 확인한 뒤 반영해줘.

이 원칙을 스킬 안에 넣었습니다. AI가 대신 쓴 티가 덜 나는 것보다 더 중요한 것은 제 의견이 다른 의견으로 변하지 않는 것이었어요. 콘텐츠가 많이 만들어져도 제 것이 아니면 채용을 위한 신호로 작동하기 어렵습니다.

현재 스킬은 텍스트와 준비된 이미지·영상을 여러 채널에 배포하고 결과를 기록하는 단계까지 구현돼 있습니다. 텍스트를 카드뉴스로 만들거나 원본 영상에서 새로운 숏폼을 완성하는 기능은 별도의 제작 과정으로 더 연결할 수 있습니다. 이미 숏폼에 쓸 문장과 구성을 잡는 시간이 크게 줄어드는 것은 확인했지만 이 부분을 완전 자동화했다고 말할 단계는 아닙니다.

7단계 — API 코딩보다 OAuth 연결이 더 오래 걸렸습니다

개인 계정도 Threads, Instagram, LinkedIn, X의 공식 API를 쓸 수 있었습니다. 다만 스크립트 하나를 만들면 바로 연결될 것이라고 생각했던 것은 틀렸습니다.

플랫폼마다 개발자 앱, 계정 유형, 권한, callback 주소와 token 만료 방식이 달랐습니다. Instagram은 Creator 계정 전환이 필요했고 LinkedIn은 앱 생성 화면에서 입력한 이름을 인식하지 못하는 오류가 반복됐습니다. 결국 고객지원과 메일을 주고받고 오류 화면과 HAR 파일까지 준비해야 했어요.

또 한 번은 인증 과정에서 비밀값이 노출될 가능성을 발견해 기존 값을 폐기하고 다시 발급했습니다. 현재 비밀값은 코드나 문서가 아니라 macOS Keychain에 보관합니다.

이 과정은 콘텐츠 자동화 사례에서 잘 보이지 않는 부분입니다. AI가 게시글을 잘 쓰는 것과 각 플랫폼에 안전하게 게시할 수 있는 것은 다른 문제였습니다. OAuth 구현과 계정 설정은 예상보다 시간이 오래 걸렸고 사람이 로그인하거나 약관에 동의해야 하는 구간도 남았습니다.

그럼에도 공식 API 방식을 고른 이유는 분명했습니다. 게시 결과의 주소와 ID를 받을 수 있고 일부 채널만 실패했을 때 성공한 게시물은 그대로 두고 실패한 곳만 다시 시도할 수 있기 때문입니다. 브라우저 화면을 흉내 내 클릭하는 방식보다 기록과 복구가 쉬웠습니다.

8단계 — 보기 좋은 staging이 완성돼도 production은 멈췄습니다

새 사이트가 거의 완성돼 보였을 때 Codex에 production 전환 전 점검을 요청했습니다.

staging.tkim.co에 만들어진 새로운 블로그를 완전히 production으로 올리기 전에
내가 체크해야 할 것을 이 코드 베이스를 꼼꼼히 보고 알려줘.

화면 품질 점수는 높았지만 판정은 NO-GO였습니다. 새 기능 중 아직 커밋되지 않은 파일이 있었고 기존 production에서 staging으로 마지막 데이터를 합치는 연습도 필요했습니다. DNS, IPv6, 인증서, 검색 노출, 뉴스레터 구독과 해지, 복구 절차까지 함께 맞아야 했습니다.

저는 WordPress 사이트를 바꾸는 일이라고 생각했지만 production 이전에는 예상보다 많은 기술 지식이 필요했습니다. 화면이 잘 열리는지 확인하는 것만으로는 부족했습니다. 기존 글의 주소가 유지되는지, 검색엔진이 staging을 색인하지 않는지, 구독자가 중복되거나 빠지지 않는지, 장애가 나면 예전 서버로 돌아갈 수 있는지를 모두 확인해야 했어요.

그래서 지금도 기존 tkim.co는 production으로 유지되고 새 시스템은 staging에 있습니다. MailerLite에서 추린 활성 구독자는 스티비에 안전하게 옮겼고 시험 메일도 확인했지만 전체 운영 전환과 새 흐름의 장기 성과는 아직 측정 전입니다.

이 상태를 숨기지 않는 것이 중요하다고 생각합니다. AI가 짧은 시간에 많은 일을 해낼 수 있어도 production의 책임까지 사라지는 것은 아닙니다. 오히려 만들 수 있는 범위가 넓어진 만큼 검증할 범위도 함께 넓어졌습니다.

결과 — 시간을 줄이는 자동화에서 취향을 확장하는 시스템으로

아직 모든 결과를 수치로 말할 단계는 아닙니다. 네 SNS에 각각 글을 올리는 데 들던 약 한 시간은 줄일 수 있게 됐지만 더 큰 변화는 같은 생각을 여러 콘텐츠 포맷의 원본으로 쓸 수 있게 된 점입니다.

이전에는 AI가 글을 대신 써주는 기능을 먼저 떠올렸습니다. 지금은 조금 다르게 봅니다. 제가 가진 의견과 취향이 원본이고 AI는 그것을 잃지 않은 채 여러 형태로 확장하는 역할을 맡아야 합니다.

우리 회사가 하는 커뮤니티형 교육과 AI 네이티브한 시도에 관심 있는 사람을 채용하고 싶다면, 결과만 홍보하는 것보다 실제로 어떤 방식으로 실험하고 실패하고 바꾸는지를 보여주는 편이 맞습니다. 이 콘텐츠 시스템도 그 사례 중 하나가 될 수 있습니다.

AI 활용 팁 — 자동화 전에 내 콘텐츠의 원본부터 정하세요

비슷한 시스템을 만들려는 사람에게 가장 먼저 권하고 싶은 것은 도구 비교가 아닙니다. 내가 가진 의견과 취향이 어느 단계에서 원본으로 확정되는지부터 정해야 합니다.

SNS를 원본으로 삼으면 나중에 다시 수집하고 중복을 합쳐야 합니다. AI가 만든 요약문을 원본으로 삼으면 본인의 말투와 관점이 사라질 수 있습니다. 저는 Codex에서 검토한 한국어 원문을 기준으로 삼고 SNS 글·영문판·블로그 기록·뉴스레터가 그 원문에서 갈라지게 했습니다.

처음부터 모든 포맷을 자동화하지 않아도 됩니다. 아래처럼 가장 작은 흐름부터 실제로 써보는 편이 좋습니다.

• 의견이나 소감을 원문으로 정리합니다.

• 플랫폼 두 곳의 미리보기를 만들어봅니다.

• 말투와 논지가 보존되는지 확인합니다.

• 실제 게시 결과의 주소를 한곳에 기록합니다.

• 이 흐름이 반복될 때만 카드뉴스·숏폼·뉴스레터를 붙입니다.

디자인은 AI에게 바로 완성하라고 하기보다 취향에 맞는 레퍼런스를 먼저 찾게 해보세요. 후보를 사람이 직접 고르면 결과를 설명하고 수정하는 시간이 줄어듭니다.

외부 게시와 production 변경에는 별도 승인 단계를 두는 것도 중요합니다. 미리보기가 마음에 든다는 말과 실제로 게시하라는 말은 다릅니다. 자동화가 강해질수록 이 둘을 시스템 안에서 구분해야 합니다.

바로 쓸 수 있는 프롬프트

나는 [회사/개인]의 전문성과 일하는 방식을 외부에 보여주기 위해 콘텐츠 발행 시스템을 만들고 싶어.
먼저 내가 실제로 글을 쓰는 과정을 질문해서 파악해줘.
내 의견과 말투가 담긴 원문을 기준으로 삼고 AI가 임의로 주장이나 관점을 바꾸지 않게 해줘.
이 원문을 [사용할 SNS 채널]에 맞게 바꾸되 전체 미리보기를 먼저 보여줘.
글, 이미지, 카드뉴스, 숏폼 중 어떤 포맷이 적합한지도 제안해줘.
실제 외부 게시와 production 변경은 내가 직전에 승인할 때만 실행해줘.
게시 결과는 [WordPress/Notion/데이터베이스] 한곳에 중복 없이 기록하고 일부 실패 시 성공한 채널은 유지한 채 실패한 곳만 재시도할 수 있게 설계해줘.
구현 전에 현재 방식, 불편한 점, 콘텐츠 원본, 계정 소유권, 복구 방법을 포함한 계획부터 작성해줘.