누군가 당신의 제품에 "소셜 공유" 기능을 추가해 달라고 요청합니다. 당신은 그것을 보고 이렇게 생각합니다: 7~8개의 REST 호출, 일주일 정도의 작업량.

저는 현재 수치를 바탕으로, 네트워크별로 그 추정치 뒤에 실제로 무엇이 있는지 설명하고자 합니다. 여러분이 그것을 만들지 못하게 하려는 것이 아닙니다. 어떤 분들은 그래야 할지도 모릅니다. 하지만 비용은 추정치에 나타나지 않는 곳에 집중되어 있으며, 그중 HTTP 호출은 거의 대부분을 차지하지 않습니다.

아래의 모든 내용은 2026년 7월에 검증되었습니다. 그중 절반은 1년 안에 틀릴 것이며, 그 자체가 이 글의 핵심 중 하나입니다.

네트워크별 관문 (The gates)

HTTP 요청은 정말 쉽습니다. 하지만 그것을 수행할 권한을 얻는 것은 쉽지 않습니다.

Meta (Facebook Pages 및 Instagram)

Instagram 게시(publishing)를 위해서는 Professional 계정(Business 또는 Creator)이 필요합니다. 개인 계정은 API 접근 권한이 전혀 없습니다. 해당 계정은 Facebook Page와 연결되어 있어야 하는데, 권한 흐름이 Page를 통해 이루어지기 때문입니다.

그 다음 instagram_business_basic 및 instagram_business_content_publish라는 두 가지 권한에 대해 앱 검토(App Review)를 받아야 합니다. 앱 검토란 비즈니스 인증(Business Verification), 작동하는 데모, 그리고 각 사용 사례를 수행하는 앱의 화면 녹화가 필요함을 의미합니다. 제출당 2~4주를 예산으로 잡고, 한 번 이상의 제출을 예상하십시오.

게시 자체는 두 번의 호출로 이루어집니다: /{ig-user-id}/media로 미디어 컨테이너를 POST한 다음, /{ig-user-id}/media_publish로 게시합니다. 그 부분은 오후 한나절이면 끝납니다.

LinkedIn

여기에는 매우 다른 두 가지 문이 있습니다.

w_member_social은 쉬운 쪽입니다. 이는 Consumer 티어에 속하며 무료이고, 인증된 멤버가 자신을 대신하여 게시물을 올릴 수 있게 해줍니다. 만약 당신의 기능이 "사용자가 자신의 LinkedIn에 공유할 수 있게 하는 것"이라면, 대부분 문제없을 것입니다.

Company Pages(회사 페이지)에 게시물을 올리는 것은 Community Management API를 통해 이루어지며, 이는 개인 개발자에게는 개방되어 있지 않습니다. 등록된 회사, 인증된 LinkedIn Page, 그리고 2단계 심사 과정이 필요합니다. 먼저 호출량이 제한된 Development Tier(개발 단계)를 거친 후, 액세스 요청 시 모든 사용 사례를 보여주는 스크린캐스트(screencast)를 제출해야 하는 Standard Tier(표준 단계)로 넘어가야 합니다. 또한, 심사가 시작된 후 21일 이내에 완료해야 하는 검증 설문조사(vetting survey)가 있습니다.

승인 주기가 3개월에서 6개월 정도 걸릴 것을 대비하십시오. 이는 엔지니어링 작업 시간이 아닙니다. 당신의 기능이 출시되지 못한 채 흘러가는 실제 달력상의 시간입니다.

TikTok

TikTok의 Content Posting API에는 사람들을 놀라게 하는 관문(gate)이 하나 있는데, 이는 당신을 차단하는 것이 아니라 조용히 성능을 저하시키는(degrades) 방식이기 때문입니다.

감사를 받지 않은 클라이언트(unaudited client)가 게시한 콘텐츠는 강제로 비공개(private) 상태가 됩니다. 사용자가 OAuth 과정에서 선택한 개인정보 설정과는 무관합니다. 어떤 상황에서도 항상 비공개입니다. 당신의 통합(integration) 작업은 모든 테스트에서 정상적으로 작동하는 것처럼 보이겠지만, 실제로는 사용자들의 게시물이 보이지 않게 될 것입니다.

감사를 받기 전에는 앱당 최대 5개의 샌드박스(sandbox)를 생성할 수 있으며, 각 샌드박스는 최대 10개의 TikTok 계정과 공유할 수 있습니다. 샌드박스에서 게시되는 모든 콘텐츠 역시 강제로 비공개 처리됩니다. 이것이 설계된 대로 작동하는 관문의 모습입니다. 즉, 자유롭게 빌드하고 테스트하되, 리뷰를 거친 후에만 공개적으로 출시하라는 것입니다.

알아둘 만한 탈출구(escape hatch)가 하나 있습니다. Inbox upload mode(수신함 업로드 모드)는 완성된 비디오를 크리에이터의 TikTok 초안(drafts)으로 넣어 사람이 직접 게시하게 만드는 방식입니다. 이 방식은 감사가 필요 없으며, 솔직히 말해서 많은 콘텐츠 파이프라인(pipelines)에 있어 올바른 설계이기도 합니다.

YouTube

칭찬할 점은, 이 부분은 개선되었다는 것입니다. videos.insert는 과거에 하루 기본 할당량인 10,000 유닛 중 호출당 약 1,600 쿼터 유닛(quota units)을 소모했기에, 하루에 6번의 업로드로 제한되었습니다. 2025년 12월, Google은 이를 조용히 약 100 유닛으로 낮추었으며, 따라서 이제 기본 프로젝트로 하루에 약 100번의 업로드를 처리할 수 있습니다.

문제는 돈을 더 낸다고 해서 이 한도를 넘길 수 없다는 점입니다. YouTube Data API에는 유료 상업용 티어 (paid commercial tier)가 존재하지 않습니다. 더 많은 할당량이 필요하다면 Cloud Console을 통해 할당량 확장 요청 (quota extension request)을 제출하고 기다려야 합니다. 돈이 해결책이 될 수 없다는 점은 이례적이며, 이를 바탕으로 설계를 하기 전에 반드시 알아두어야 할 사실입니다.

X (Twitter)

현재 요율: 게시물 생성 시 $0.015, 해당 게시물에 URL이 포함된 경우 $0.20입니다.

링크 프리미엄 (link premium)을 다시 확인해 보세요. 이는 기본 요율보다 13배 이상 높으며, "링크 게시"는 소셜 스케줄링 기능이 하루 종일 수행하는 작업 그 자체입니다. 한 달에 링크 게시물을 1,000개 올린다면 URL이 없는 동일한 양의 게시물 비용인 $15와 달리, API 비용으로만 $200가 발생합니다.

Threads

무료이며, 운영 환경 접근 권한을 얻기 위한 마찰 요인은 다시 한번 Meta App Review입니다.

게시 제한 (publishing caps)은 24시간 이동 창 (rolling 24 hour window) 기준 프로필당 다음과 같습니다: 게시물 250개, 답글 1,000개, 삭제 100개. 답글은 게시물 제한 수치에 포함되지 않습니다. 캐러셀 (Carousels), 텍스트 및 이미지 게시물은 모두 동일하게 계산됩니다. 한계에 부딪히기 전에 사용량을 확인할 수 있는 GET /{threads-user-id}/threads_publishing_limit 엔드포인트가 있으며, 이를 호출하여 확인하는 것이 좋습니다.

Google Business Profile

모든 새로운 Google Cloud 프로젝트는 Business Profile API에 대해 0의 할당량으로 시작합니다. 적은 할당량이 아니라, 아예 0입니다. API는 무료이며 호출당 과금은 없지만, 승인을 받기 전까지는 단 한 번의 호출도 할 수 없습니다.

승인을 받으려면 공식적인 액세스 요청, 정당한 사용 사례 (본인의 위치 정보 또는 고객의 위치 정보), 60일 이상 활성화된 인증된 프로필, 그리고 실제 비즈니스 웹사이트가 필요합니다. 검토에는 약 14일이 소요됩니다. 할당량이 300 QPM으로 표시되면 승인된 것입니다.

할당량 증설은 별도의 문의 양식을 통해 이루어지며, 평균 사용량이 현재 제한의 50% 미만이면 거절됩니다. 따라서 미리 규모를 확장(pre-scale)할 수 없습니다. 사용량을 늘려가며 자연스럽게 규모를 키워야 합니다.

아무도 예산에 책정하지 않는 부분

모든 관문을 통과했다고 가정해 봅시다. 이제 실제적인 어려운 문제에 직면하게 되는데, 그것은 인증 (authentication) 문제가 아닙니다.

각 네트워크는 유효한 게시물이 어떤 모습이어야 하는지에 대해 저마다의 규칙을 가지고 있습니다. 캡션 길이, 해시태그 제한, 이미지 개수, 이미지와 비디오의 혼합 가능 여부, 종횡비 (aspect ratios), 해상도 범위 (resolution bounds), 프레임 레이트 (frame rate), 재생 시간 (duration), 파일 크기 등입니다. 이 모든 것들은 서로 다르며, 별다른 예고 없이 변경되기도 합니다.

동일한 콘텐츠를 여러 네트워크에 동시에 게시할 때, 실제로 전송할 수 있는 것은 모든 규칙의 **교집합 (intersection)**입니다. 그 교집합은 단일 네트워크의 규칙보다 훨씬 좁으며, 직접 계산해 보기 전까지는 명확히 알 수 없습니다.

여기 실제 사례가 있습니다. 다음은 위에서 언급한 8개 네트워크 모두에 하나의 미디어 게시물을 동시에 보낼 때 병합된 제약 조건 세트입니다:

{
  "caption": { "maxLength": 280, "maxHashTags": 30 },
  "media": {
...

이 내용을 주의 깊게 읽어보십시오. 보기보다 훨씬 가혹하기 때문입니다. 8개 네트워크 모두에 한 번에 게시하려면 이미지는 전혀 없이 오직 하나의 비디오만, 최대 30초, 그리고 280자의 캡션만 사용할 수 있습니다.

캡션은 X(구 Twitter)의 상한선입니다. 30초는 세트 내에서 가장 타이트한 비디오 시간 범위입니다. 그리고 이미지는 완전히 사라집니다. YouTube가 비디오만 허용하기 때문에, YouTube의 존재가 나머지 7개 네트워크의 모든 이미지 기반 옵션을 삭제해 버린 것입니다.

YouTube를 제외하면 그림은 완전히 달라집니다:

{
  "caption": { "maxLength": 280 },
  "media": { "maxOverall": 4, "maxImages": 4, "maxVideos": 1, "canMixOverall": false }
...

4개의 이미지를 다시 사용할 수 있게 됩니다. 네트워크 하나가 추가되거나 제거되는 것만으로, 다른 모든 네트워크가 수용할 수 있는 내용이 조용히 재정의됩니다. 이것이 플랫폼 문서들을 나란히 읽어서는 볼 수 없는 부분입니다.

Reels는 훨씬 더 엄격합니다. Instagram, TikTok, YouTube, Facebook 전체를 통틀어 정확히 하나의 비디오, 이미지 없음, 390초, 2460fps, 그리고 전혀 허용 오차가 없는 엄격한 9:16 비율을 유지해야 합니다:

{
  "media": {
    "maxVideos": 1,
...

이것을 한 번 인코딩(encoding)하는 것도 상당한 작업량입니다. 하지만 진짜 비용은 이를 올바르게 유지하는 데 발생합니다. 이러한 값들은 계속 변동되는데, 아무도 변경 로그 (changelog)를 보내주지 않기 때문입니다. 당신은 고객의 게시물이 실패했을 때야 비로소 그 사실을 알게 됩니다.

지속적인 세금 (The ongoing tax)

관문과 제약 사항을 넘어, 당신이 감수해야 할 영구적인 유지보수 라인이 존재합니다:

• 토큰 생명주기 (Token lifecycle). 모든 네트워크는 토큰을 만료시키는 방식이 다릅니다. 당신은 리프레시 흐름 (refresh flows), 재인증 프롬프트 (re-auth prompts), 그리고 사용자의 Instagram 연결이 3일 전에 조용히 끊겼음을 사용자에게 알릴 방법을 갖춰야 합니다.
• 중대한 변경 사항 (Breaking changes). Meta는 Graph API의 버전을 관리하며 정해진 일정에 따라 이전 버전을 폐기 (deprecate) 합니다. LinkedIn은 매달 버전을 관리합니다. 당신은 새로운 가치를 전혀 제공하지 못하는 마이그레이션 (migration) 작업에 시간을 소비하게 될 것입니다.
• 지원 부담 (Support burden). "왜 제 게시물이 올라가지 않았나요?"라는 질문이 문의 티켓의 한 카테고리가 됩니다. 답변은 대개 토큰, 할당량 (quota), 또는 미디어 제약 사항이며, 무엇이 문제인지 진단하는 것은 당신의 몫입니다.
• 재검토 (Re-review). 사용 사례 (use case)를 변경하면 다시 앱 검토 (App Review) 과정을 거쳐야 할 수도 있습니다.

이 중 어려운 것은 하나도 없습니다. 하지만 이 모든 것은 영원히 지속됩니다.

다른 선택지

우리는 소셜 미디어 관리 플랫폼인 Swonkie이며, 저희 제품이 제대로 작동하도록 위 사항들을 모두 유지보수하고 있습니다. 우리는 이를 swonkie.dev를 통해 개발자들에게 게시 및 측정 API (publishing and measurement API)로 제공하고 있으며, 최근에는 원격 MCP 서버 (remote MCP server)로도 제공하고 있습니다.

단 한 번의 호출로 연결된 모든 네트워크에 전달됩니다. 위에 언급된 제약 사항들은 단순한 예시가 아니라, 우리의 posts_rules_get 엔드포인트 (endpoint)에서 도출된 것입니다. 페이로드 (payload)를 구축하기 전에 이 엔드포인트를 호출하여 무엇이 통과될지 미리 알 수 있습니다. 실제 게시 규칙을 실행하고, 무언가가 나가기 전에 무엇이 왜 실패할지를 알려주는 검증 (validate) 단계가 있습니다.

에이전트 (agent) 형태의 무엇인가를 구축하고 있다면 MCP 서버가 중요합니다. 이는 원격이며 상태가 없는 (stateless) 방식이므로 설치할 것이 아무것도 없습니다:

{
  "mcpServers": {
    "swonkie": {
...

Claude나 Cursor를 해당 서버로 지정하면, 연결된 프로필을 나열하고, 게시물 유형에 대한 규칙을 확인하며, 초안을 작성하고, 검증하고, 승인 절차를 거쳐 게시하고, 분석 데이터를 다시 가져올 수 있습니다. 27개의 도구, 11개의 리소스, 8개의 프롬프트가 준비되어 있습니다.

또한 우리의 이미지 생성 도구인 Andie도 있습니다. Andie는 텍스트 프롬프트를 입력받아 이미 미디어 라이브러리에 업로드되어 게시물 미디어로 즉시 사용할 수 있는, 제작 준비가 된 소셜 이미지를 반환합니다.

이 서비스가 진정으로 필요한 대상: 본인의 브랜드, 또는 많은 클라이언트 계정을 관리하는 에이전시입니다. 하나의 워크스페이스(Workspace)에 여러 연결된 프로필을 담을 수 있으므로, 한 곳에서 50개의 브랜드를 관리하는 것도 문제없습니다. 다만, 현재 제공하지 않는 기능은 각 최종 고객이 자신의 계정을 가져오고 각자의 결제 방식을 사용하는 멀티 테넌트 (Multi-tenant) SaaS 모델입니다. 그것은 셀프 서비스 API 모델이 아니라 리셀러 (Reseller) 계약 방식이며, 여러분이 3주 차에 이를 발견하게 하기보다는 차라리 여기서 미리 말씀드리는 편이 낫겠다고 판단했습니다.

API 및 MCP 문서: swonkie.dev 및 docs.swonkie.dev/mcp-server.

직접 구축할 경우

진정으로 괜찮은 방법이며, 때로는 그것이 정답일 수도 있습니다. 두 가지 제안을 드립니다:

코드를 작성하기 전에 승인 절차를 먼저 시작하세요. LinkedIn 커뮤니티 관리 (Community Management)와 Google 비즈니스 프로필 (Google Business Profile)은 스프린트 (Sprint) 단위가 아니라 개월 단위로 측정되며, 순수하게 달력상의 시간이 소요됩니다. 신청을 미루는 매 주가 전체 일정의 끝에 한 주씩 추가되는 것과 같습니다.

게시 로직 (Publishing logic)을 만들기 전에 제약 조건 테이블 (Constraint table)을 먼저 구축하세요. 하나의 네트워크에 게시하는 것을 먼저 구현한 다음 나머지를 추가하고 싶은 유혹이 들 것입니다. 하지만 그런 순서는 가장 어려운 문제를 뒤로 미루게 만듭니다. 가장 어려운 문제는 게시하는 것 자체가 아니라, 전송하기 전에 무엇이 거부될지 미리 아는 것입니다.

출처 확인 완료: 2026년 7월. 플랫폼 약관은 자주 변경되므로, 계획을 세우기 전에 이곳의 모든 내용을 공식 문서와 대조하여 확인하십시오: Meta, LinkedIn, TikTok, YouTube, X, Google Business Profile.