7편을 쓰기 전에 SNS 약관부터 다시 읽었다.
고급편 6편 끝에서 이번 편 주제를 「SNS 운영 자동화와 승인」으로 예고했다. 자동화 이야기를 쓰기 전에 약관부터 확인하는 것은 고급편 4편에서 정한 절차다. 이번에도 그 순서를 따랐고, 읽고 나서 제목을 「SNS는 허용된 길로」로 정했다. 이 글은 SNS 운영을 AI로 덜고 싶은 비개발자를 위해 쓴다. 게시물 올리기, 답글 달기, 답글 정리하기는 반복이 많아서 맡기고 싶어지는 일이다. 다만 SNS는 화면 너머에 사람이 있다. 무엇을 기계에 맡기고 무엇을 내가 쥘지, 약관과 API 문서, 그리고 내 계정에서 실제로 바꾼 운영 방식을 차례로 적는다. 고급편의 일곱 번째 글이다.
7.1 SNS에서 무엇을 자동화하고 무엇을 사람이 쥘까?
자동화는 제공자 API로 열린 게시와 답글 관리에 둔다. 사람은 초안 승인과 대화의 결을 쥔다.
SNS 자동화라고 하면 흔히 로그인한 화면에서 버튼을 대신 눌러 주는 방식을 떠올린다. 사람이 하는 것처럼 보이게 답글을 달고, 반응을 훑고, 누를 것을 누르는 식이다. 이 글에서 권하는 방향은 반대다. 자동화할 일은 SNS 제공자가 개발자용 API로 열어 둔 일로 한정한다. Threads라면 게시, 답글 달기, 답글 숨기기, 누가 답글을 달 수 있는지 정하기, 답글 승인제 같은 것이다. 사람이 쥘 것은 두 가지다. 무엇을 올릴지 초안을 승인하는 일, 그리고 누구에게 어떤 말투로 얼마나 길게 답할지 정하는 대화의 결이다. 반복되는 답글은 사람도 알아본다. 대화의 결까지 기계에 넘기면 약관을 지켜도 독자와의 관계에서 잃는 것이 생긴다.
그림 7-1은 이 구분을 세 칸으로 나눈 지도다. 첫 칸은 제공자 API로 여는 일이다. 게시와 답글 관리가 여기에 들어간다. 둘째 칸은 사람이 승인하는 일이다. 게시물 초안, 답글 초안, 캡처 이미지에 무엇을 담을지가 여기에 있다. 셋째 칸은 하지 않는 일이다. 로그인한 브라우저를 에이전트가 대신 조작해 답글을 읽어 가거나 자동으로 반응하는 방식이 여기에 들어간다. 셋째 칸에 넣은 이유는 다음 절의 약관에 있다.
7.2 약관은 무엇을 막나?
로그인 여부와 관계없이, 허가 없이 자동화된 방식으로 정보에 접근하고 수집하는 일을 막는다.
Threads에는 따로 이용약관이 있다. 그런데 이 문서는 Instagram 이용약관을 보충하고 수정하는 문서다. Threads를 쓰면 Instagram 이용약관과 Meta 커뮤니티 규정이 함께 적용된다. 그래서 금지 항목은 Instagram 이용약관에서 찾았다. 한국어판 금지 항목에는 이런 문장이 있다. “허가받지 않은 방법으로 계정을 만들거나 정보에 접근하거나 정보를 수집하려 해서는 안 됩니다. 여기에는 해당 자동 액세스 및 수집이 Instagram 계정에 로그인한 동안 수행되는지 여부와 관계없이, 저희의 명시적 허가 없이 계정을 만들고 자동화된 방식으로 정보에 액세스하고 정보를 수집하는 행위가 포함됩니다.”
내가 눈여겨본 대목은 ‘로그인한 동안 수행되는지 여부와 관계없이’다. 내 계정으로 로그인한 브라우저라 해도, 내 계정이니 괜찮다는 논리는 이 문장 앞에서 힘을 잃는다고 읽었다. 로그인한 브라우저를 에이전트가 대신 조작해 SNS의 답글을 읽어 가거나 자동으로 반응하는 방식은 이 조항에 걸릴 수 있다. 사람처럼 보이게 누르는 자동화가 바로 이 모양이다. 그래서 SNS에서 무엇을 자동화하려면 제공자가 연 개발자 길, 곧 API로 하기로 했다. 이것은 법률 해석이 아니다. 내가 읽은 문장과, 그에 맞춰 정한 내 기준을 적은 것이다.
같은 약관은 Meta 플랫폼 약관과 개발자 정책을 지키라고 적는다. 개발자용 길인 API에는 그 약관이 적용된다. 4편에서 AI 채팅 서비스의 약관을 읽었을 때와 같은 구조다. 사람이 화면으로 쓰는 길과 프로그램이 쓰는 길이 나뉘어 있고, 프로그램이 쓰는 길에는 따로 규칙이 붙는다. 그러니 SNS에서 자동화할 일을 고를 때 먼저 열어 볼 문서는 그 SNS의 개발자 문서다.
7.3 Threads API가 열어 둔 일
Meta 개발자 문서의 Threads API 개요(2026년 7월 2일 갱신)에 따르면, 이 API로 할 수 있는 일은 크게 넷이다. 게시물 만들기와 게시, 미디어와 프로필 가져오기, 답글 관리, 인사이트 조회다. 게시는 두 단계로 나뉜다. 먼저 올릴 내용을 담은 미디어 컨테이너를 만들고, 그 번호로 게시한다. 문서는 처리 시간을 위해 게시 전에 약 30초 기다리라고 안내한다. 답글 만들기 문서(2025년 12월 22일 갱신)를 보면 답글은 아무 게시물에나 달 수 있는 것이 아니다. 루트 게시물의 주인이거나, 키워드 검색이나 멘션 관리 같은 특정 권한이 있어야 한다. 특정 답글에 답하려면 그 답글을 지정해서 보낸다.
사람 승인과 가장 가까운 것은 답글 관리 문서(2026년 2월 13일 갱신)다. 기능은 세 가지다. 첫째는 답글 숨기기와 다시 보이기다. 둘째는 누가 답글을 달 수 있는지 정하는 기능으로, 모두, 내가 팔로우하는 계정, 언급된 사람만, 원글 작성자만, 팔로워만 가운데서 고른다. 셋째는 답글 승인제다. 켜 두면 내 게시물에 달린 답글은 승인해야 공개되고, 그 전에는 숨겨진다. 대기 중인 답글 목록을 가져와 하나씩 승인하거나 무시할 수 있다. 내 게시물에 달리는 답글에도 사람 승인을 걸 수 있고, 그 승인을 SNS 쪽 기능으로 둘 수 있다는 뜻이다. 그림 7-3이 그 문서다.
표 7-1은 이 기능들을 사람 승인과 나란히 놓은 것이다. 셋째 칸은 내 운영 기준에서 본 관계다.
| 기능 | 무엇을 하나 | 사람 승인과의 관계 |
|---|---|---|
| 게시물 만들기·게시 | 미디어 컨테이너를 만들고 그 번호로 게시한다. 게시 전 약 30초 대기를 안내한다 | 내가 승인한 초안만 이 단계로 넘긴다 |
| 답글 만들기 | 루트 게시물의 주인이거나 특정 권한이 있을 때 답글을 단다. 특정 답글을 지정해 답할 수 있다 | 내가 승인한 답글 초안만 보낸다 |
| 답글 숨기기·보이기 | 달린 답글을 숨기거나 다시 보이게 한다 | 무엇을 숨길지는 사람이 정한다 |
| 답글 권한 정하기 | 모두, 내가 팔로우하는 계정, 언급된 사람만, 원글 작성자만, 팔로워만 가운데서 고른다 | 게시물마다 사람이 고른다 |
| 답글 승인제 | 승인해야 답글이 공개되고, 그 전에는 숨긴다. 대기 목록을 가져와 승인하거나 무시한다 | 내 게시물에 달리는 답글에 사람 승인을 SNS 쪽 기능으로 건다 |
| 미디어·프로필 가져오기, 인사이트 조회 | 내 게시물과 프로필 정보, 반응 지표를 가져온다 | 판단 재료다. 무엇을 할지는 사람이 정한다 |
API를 쓰려면 앱을 등록하고 액세스 토큰을 받아야 한다. 토큰은 내 계정 대신 API를 부를 수 있는 비밀값이다. 그래서 화면이나 대화에 찍지 않고, 권한을 제한한 파일에 둔다. 고급편 1편과 3편에서 정한 원칙을 그대로 따른다.
7.4 내 계정은 왜 자동에서 승인으로 바뀌었나?
개인 글이 반응을 얻었고, 한결같은 답글에 “AI랑?”이라는 질문을 받았다. 그 뒤 승인제로 바꿨다.
내 SNS 계정은 처음에 책 요약 콘텐츠를 자동으로 만들어 올리는 프로젝트의 입구로 설계했다. 그 프로젝트는 내가 직접 만든 파이프라인으로 돌리는 구조였다. Threads API에서 데이터베이스로 이어지는 흐름이다. 서비스는 아직 준비 중이다. 이 파이프라인은 Aside와 별개로 내가 따로 만든 것이다. 처음 설계에서는 콘텐츠가 만들어지면 자동으로 올라가는 쪽을 그렸다. 사람이 끼는 자리를 따로 두지 않은 설계였다. 그런데 계정은 설계대로만 흘러가지 않았다. 계획에 없던 개인적인 글 하나가 반응을 얻으면서, 계정이 개인 이야기 쪽으로 기울었다.
책 계정으로 되돌릴지 개인 계정으로 돌릴지 고를 수도 있었지만, 나는 둘을 섞기로 했다. 개인 글은 남긴다. 개인 글에서 들어온 사람이 책 콘텐츠까지 보기 때문이다. 대신 게시 방식을 바꿨다. 2026년 8월 18일부터 완전 자동 게시를 그만두고, 사람이 검토한 뒤 게시하는 방식으로 옮겼다. 개인 이야기가 섞였다고 모든 것을 드러내지는 않는다. 사적인 사정 일부는 개인 글에도 공개하지 않는다. 무엇을 쓸지와 무엇을 쓰지 않을지 모두 사람이 정하는 영역으로 남긴 셈이다.
직접 계기는 답글이었다. 답글이 한결같은 모양이 되자 한 독자가 “AI랑?”이라고 물었다(1권 11장). 그 뒤로 게시물과 답글은 내가 초안을 승인한 것만 올라간다. 이 일로 알게 된 것은 약관과는 다른 층위의 문제다. 어떤 길로 올리든 답글이 같은 모양으로 반복되면 읽는 사람은 알아본다. 자동화가 허용되는지와, 자동화한 티가 나는지는 따로 따져야 한다. 앞의 것은 약관이 정하고, 뒤의 것은 독자가 정한다. 그래서 초안 승인에 더해 답글을 쓰는 기준을 따로 세웠다.
7.5 답글 문체 기준 네 가지
반복하지 않기, 길이 맞추기, 받아서 이어 가기, 말투 맞추기. 운영하며 정한 기준이다.
첫째, 복사해 붙인 듯한 같은 문장을 돌려 쓰지 않는다. 반복은 봇처럼 읽히고 노출도 줄어든다고 보았다. 둘째, 길이는 대화가 이미 이어지고 있는지에 맞춘다. 처음 댓글을 단 사람에게는 한두 문장만 쓴다. 셋째, 내 질문에 다시 답해 준 사람에게는 그 사람의 구체적인 말을 받아, 내 쪽 이야기를 하나 보태 이어 간다. 넷째, 기본은 존댓말이고 상대가 반말을 쓰면 맞춘다. 이 SNS는 반말 문화가 기본이다. 네 기준은 한 방향을 향한다. 답글 하나하나가 그 사람에게 쓴 말로 읽히게 하는 것이다. 한두 문장짜리 답글이라도 같은 문장을 여러 사람에게 돌리면 금방 드러난다.
이 기준은 내가 직접 쓸 때도, AI에게 초안을 맡길 때도 똑같이 적용한다. 초안을 맡길 때는 오히려 더 또렷하게 적어야 한다. 기준을 적지 않고 답글 여러 개를 한 번에 맡기면 비슷한 인사와 비슷한 맺음말이 반복되기 쉽다. 그래서 요청문에 네 기준을 그대로 옮겨 적고, 초안을 받을 때는 초안끼리 겹치는 표현이 있는지도 따로 적게 한다. 표 7-2는 상황별로 정리한 것이다. 뒤의 요청 예시도 이 표를 바탕으로 썼다.
| 상황 | 길이·말투 | 피할 것 |
|---|---|---|
| 처음 댓글을 단 사람 | 한두 문장. 기본은 존댓말 | 처음 온 사람에게 긴 답 |
| 내 질문에 다시 답해 준 사람 | 그 사람의 구체적인 말을 받고, 내 쪽 이야기를 하나 보탠다 | 상대 말을 받지 않는 인사만으로 끊기 |
| 상대가 반말을 쓴 경우 | 반말로 맞춘다 | 상대 말투와 상관없이 한 가지 말투로만 답하기 |
| 여러 댓글에 한꺼번에 답할 때 | 댓글마다 다른 문장 | 복사해 붙인 듯한 같은 문장 돌려 쓰기 |
7.6 올리고 사라지지 않는다
타이밍에도 내 기준이 있다. 먼저 밝혀 둘 것은, 아래 숫자는 내 운영 판단이고 보장된 수치가 아니라는 점이다. 나는 게시 뒤 첫 30~60분의 반응을 가장 강한 노출 신호로 본다. 그중에서도 좋아요보다 답글, 특히 주고받는 대화를 더 무겁게 본다. 그래서 올리고 사라지지 않는다. 답글은 한 번에 몰아서 달지 않고 여러 번에 나눈다. 올린 직후 바로 한 번, 이후 몇 시간 동안 30~40분 간격으로, 저녁에 한 번, 다음 날 아침에 한 번이다. 몰아서 다는 답글은 앞에서 말한 한결같은 모양이 되기도 쉽다. 나눠 달면 댓글마다 그때의 대화에 맞춰 쓸 여유가 생긴다.
올리는 시간은 밤 10시에서 12시 사이가 나았다. 이 계정은 한국 독자가 많다. 근거는 두 가지다. 아시아권 자료, 그리고 이 계정에서 크게 반응한 글이 자정 무렵이었던 기록이다. 서구 기준으로 만든 ‘좋은 시간표’는 그대로 쓰지 않는다. 독자가 사는 시간대가 다르면 같은 시간표가 맞기 어렵다. 다른 계정이라면 자기 계정의 기록으로 다시 정하는 편이 낫다. 이 시간 기준은 사람이 붙어 있어야 하는 기준이기도 하다. 올리는 시간을 정해도, 그 뒤 첫 한 시간 안팎의 대화를 이어 갈 사람이 자리에 있어야 한다.
7.7 Aside는 어디에 두면 될까?
초안을 쓰는 자리에 둔다. 게시와 답글 관리는 API 쪽 일이고, 승인은 내가 한다.
지금 내 운영에서 Aside의 자리는 초안이다. 게시물과 답글 초안을 Aside가 쓰고, 내가 읽고 승인한다. 답글 초안을 맡길 때는 7.5절의 기준을 지시에 적는다. 같은 문장을 돌려 쓰지 말 것, 대화가 이어진 정도에 길이를 맞출 것, 상대 말투에 맞출 것. 기준을 요청에 적어 두면 초안끼리 비슷해지는 것을 쓰는 단계에서 한 번 걸러 낼 수 있다. 게시물에 캡처 이미지를 붙일 때는 무엇을 찍을지 내가 정하고, 자르기와 가리기는 정해진 절차로 한다. 전체 화면 캡처가 그대로 노출된 사고가 있었기 때문이다(1권 14장).
한 걸음 더 나간 구성도 가능하다. 게시나 답글 승인제 같은 API 작업을 하는 작은 스크립트를 Aside에게 쓰게 하는 것이다. 토큰은 권한을 제한한 파일에 두고, 스크립트는 그 파일에서 읽는다. 실행 결과는 표로 받는다. 무엇을 올렸는지, 어떤 답글을 승인하거나 무시했는지 항목별로 보는 식이다. 이렇게 하면 게시 버튼은 API가 누르고, 무엇을 넘길지는 여전히 내가 정한다. 다만 이 구성은 내가 해 본 일이 아니다. 할 수 있는 구성으로 소개한다. 앞에서 말한 내 파이프라인은 Aside와 따로 만든 것이다.
답글 승인제는 내 게시물에 달리는 답글에 사람 승인을 거는 기능이다. 켜 두면 내가 승인한 답글만 공개된다. 이 기능도 나는 아직 켜 보지 않았다. 이런 기능이 있다는 소개까지만 한다. 어느 쪽이든 원칙은 같다. 기계는 열린 길 안에서 반복을 맡고, 공개되는 말은 사람이 확인한다.
7.8 답글 초안을 맡기는 요청 예시
아래는 설명을 위해 만든 가상의 요청이다. 담을 것은 세 가지다. 초안만 쓰고 게시하지 않기, 답글 기준, 초안을 표로 받기.
[가상 설정] 아래에 붙여 넣은 댓글들에 대한 답글 초안만 써 줘. 게시하지 마. 좋아요, 팔로우 같은 동작도 하지 마. 1. 초안끼리 같은 문장을 돌려 쓰지 마. 겹치는 인사나 맺음말이 있으면 바꿔. 2. 처음 댓글을 단 사람에게는 한두 문장만 써. 3. 내 질문에 다시 답해 준 사람에게는 그 사람의 구체적인 말을 받아서, 내 쪽 이야기를 하나 보태 이어 가. 4. 기본은 존댓말. 상대가 반말이면 반말로 맞춰. 5. 모르는 사실은 지어내지 말고, 사적인 사정은 쓰지 마. 6. 결과는 표로 줘. 번호 / 원 댓글 요약 / 상황(처음·이어지는 대화) / 말투 / 답글 초안 / 내가 확인할 점 7. 표 아래에 초안끼리 겹치는 표현이 있는지 따로 적어 줘. [여기에 댓글을 붙여 넣는다]
맨 앞 두 줄이 이 요청의 중심이다. 초안만 쓰라는 것과 게시하지 말라는 것을 가장 먼저 적었다. 무엇이 공개될지는 내가 표를 보고 정한다. 1번부터 4번은 7.5절의 기준을 그대로 옮긴 것이다. 6번의 ‘상황’ 칸은 처음 온 사람인지, 이어지는 대화인지를 초안마다 밝히게 한다. 이 칸이 있으면 길이가 맞는지 한눈에 보인다. 7번은 반복을 초안 단계에서 잡으려는 줄이다. “AI랑?”이라는 질문을 받게 한 것이 바로 한결같은 답글이었다. 이 요청에서 댓글은 사람이 직접 붙여 넣는다. 에이전트가 SNS 화면에서 답글을 읽어 오게 하지 않은 것은 7.2절의 약관 때문이다.
7.9 다음 편: 영상과 도판 자동화
다음 편에서는 영상과 도판을 만드는 일을 자동화하는 방법을 다룬다.
이 글의 확인 범위
기준일은 2026년 9월 27일이다. 약관과 API 문서, SNS의 동작은 바뀔 수 있다.
- 약관에 관한 문장은 내가 읽은 문장과 그에 맞춰 정한 내 기준이며, 법률 해석이 아니다.
- Threads 이용약관, Instagram 이용약관 한국어판, Meta 개발자 문서의 Threads API 개요·답글 만들기·답장 관리 문서를 2026년 9월 27일 확인했다. 각 문서의 갱신일은 본문에 적었다.
- 7.5절의 답글 기준과 7.6절의 타이밍 기준(첫 30~60분, 30~40분 간격, 밤 10시~12시)은 내 운영 판단이며 보장된 수치가 아니다.
- Aside에게 API 스크립트를 쓰게 하는 구성과 답글 승인제는 해 보지 않았다. 할 수 있는 구성과 있는 기능으로만 소개했다.
- 그림 7-1은 설명용 도식이고, 그림 7-2와 7-3은 공개 페이지 화면이다. 7.8절의 요청은 가상이다.
참고한 자료
2026년 9월 27일 확인. Threads 이용약관 · Instagram 이용약관 · Threads API 문서 · 답장 관리 문서
다음 글: 고급 활용 8 · 영상과 도판을 코드로 만들기
이전 글: 고급 활용 6 · 블로그 자동 발행
1권: 『Aside 브라우저 사용설명서』 연재 목록
『Aside 고급 활용』 연재 목록
저자의 실제 사용 경험과 Aside 도움말을 바탕으로 AI의 도움을 받아 작성·편집했습니다. 초판 선공개 원고 v1.0.