[카테고리:] 1인 자동화

  • 워드프레스 자동 포스팅, 1인 빌더의 3단계 루틴

    워드프레스 자동 포스팅, 1인 빌더의 3단계 루틴

    워드프레스 자동 포스팅, 왜 사람의 개입을 줄여야 하는가?

    AI 초안을 일일이 검토하는 1인 빌더의 딜레마

    혼자서 여러 SaaS를 굴리다 보면 콘텐츠 발행이 발목을 잡는다. 워드프레스 자동 포스팅을 도입해도 결국 사람이 초안을 검수해야 하는 한계에 부딪히기 때문이다. AI가 만든 글을 일일이 읽고 사실 관계를 확인하고 어색한 문구를 고치는 데 시간이 턱없이 부족하다. SaaS를 혼자 운영하는 입장에서 콘텐츠 검수에 하루 종일 시간을 쓸 수는 없다.

    유인 자동화가 오히려 효율을 갉아먹는 이유

    기계가 초안을 만들고 사람이 최종 승인을 누르는 방식은 안전해 보이지만 비효율적이다. 검수 대기열에 글이 쌓이면 발행 주기가 흐트러지고, 결국 블로그는 방치된다. 사람의 개입을 줄이지 않으면 자동화의 의미가 없다. 지난 한 달 반 동안 43편을 발행하면서 이 병목 현상을 뼈저리게 느꼈다.

    무인 발행 시스템의 필요성과 구글 SEO의 현실

    구글이 AI 콘텐츠 자체를 패널티 주는 것은 아니다. 다만 아무런 가치도 없이 기계로 찍어낸 글은 결국 색인에서 밀려난다. 무인 발행 시스템이란 사람의 수동 검수 없이 기계가 자체 품질 기준을 통과한 콘텐츠만 공개하는 자동화 파이프라인이다. 이 기준을 어떻게 세우느냐가 1인 빌더의 생존을 가른다.

    1단계: REST API vs 플러그인, 발행 자동화 세팅의 선택

    워드프레스 REST API로 자동 발행 환경 구축하기

    발행 자동화를 세팅할 때 플러그인을 쓸지 REST API를 쓸지 고민하게 된다. 처음에는 편의를 위해 자동 포스팅 플러그인을 여러 개 깔았다. 설정이 간단해서 당장은 편했지만, 사이트가 무거워지고 충돌이 잦아졌다. 결국 확장성과 제어력을 위해 REST API 방식으로 갈아탔다. 지금은 작업 폴더 183개, git 저장소 90개를 관리하는 파이프라인에서 API로 직접 쏴서 발행한다.

    자동 포스팅 플러그인의 한계와 보안상 위험

    플러그인 방식은 의존성이 높다. 업데이트가 멈추거나 취약점이 발견되면 사이트 전체가 노출된다. 1인 빌더가 모든 플러그인의 보안 패치를 쫓기는 현실적으로 불가능하다. 발행 로직을 내 코드베이스로 가져오면 이런 외부 의존성을 끊어낼 수 있다.

    가장 적합한 방법은 무엇인가: 1인 빌더의 운영 기준

    REST API로 직접 통신하는 편이 유지보수에서 압도적으로 유리하다. 워드프레스 설치 경로나 환경이 바뀌어도 헤더와 엔드포인트만 수정하면 그만이다. 기초적인 통신 코드는 의외로 단순하다.

    import requests
    import base64
    
    wp_url = "https://your-domain.com/wp-json/wp/v2/posts"
    user = "your_username"
    password = "your_app_password"
    credentials = base64.b64encode(f"{user}:{password}".encode()).decode()
    headers = {"Authorization": f"Basic {credentials}", "Content-Type": "application/json"}
    
    payload = {
        "title": "자동 발행 테스트",
        "content": "본문 내용",
        "status": "publish"
    }
    
    response = requests.post(wp_url, headers=headers, json=payload)
    

    애플리케이션 비밀번호를 발급받아 헤더에 넣고 JSON 페이로드를 쏘면 끝이다. 플러그인 UI에 얽매이지 않고 내가 원하는 형태로 발행 로직을 구성할 수 있다.

    2단계: 메타 태그와 슬러그, SEO 요소 자동화 처리

    발행 전 메타 태그 자동 매핑 로직 설계

    발행 자체는 API로 해결되지만, SEO 요소를 비워두면 검색 유입은 기대할 수 없다. 타이틀, 설명, 슬러그를 사람이 넣어주는 건 자동화가 아니다. AI가 초안을 만들 때 메타 데이터도 함께 뽑아서 페이로드에 매핑해야 한다.

    URL 슬러그 자동 최적화 방법

    슬러그 자동 최적화란 검색 엔진과 사용자 모두에게 유리한 URL 구조를 AI가 생성 시점에 분석하여 적용하는 과정이다. 한글 제목을 그대로 인코딩하면 URL이 지저분해지므로, 핵심 키워드를 영문으로 번역하고 불필요한 불용어를 제거하는 로직을 앞단에 둔다.

    카테고리와 태그 자동 분류의 기준

    메타 태그 매핑은 AI 프롬프트에서 JSON 형태로 값을 받아 처리한다. 프롬프트에서 구조화된 데이터를 강제하면 코드에서 파싱하기 편하다.

    {“title”: “제목”, “description”: “80자 이내 요약”, “slug”: “english-slug-only”, “category”: [“SaaS”], “tags”: [“자동화”, “워드프레스”]}

    이 결과값을 REST API 페이로드의 필드에 맞게 꽂아 넣으면 메타 데이터 입력 과정이 완전히 자동화된다.

    3단계: 구글 패널티를 피하는 기계의 품질 검사 기준

    구글 SEO 패널티를 유발하는 AI 문체의 특징

    무인 발행에서 가장 까다로운 부분은 품질 검사다. 기계가 쓴 글은 특유의 정형화된 패턴을 보인다. AI 문체 지문이란 특정 LLM이 반복적으로 사용하는 구문 패턴과 어휘 분포를 수치화한 데이터로, 구글의 패널티 대상이 되는 기계적 텍스트의 징후다. 자동 생성한 글의 AI 문체 지문을 재보니 1,000자당 10.1건이었다. 이대로 발행하면 패널티를 피하기 어렵다.

    사실성 및 중복 콘텐츠 자동 검증 로직

    지문을 낮추기 위해 문체 변환기를 거치고 다시 검사를 돌린다. 손으로 고친 뒤에는 1.4건으로 떨어지는 걸 확인했다. 이 기준을 통과해야 발행 대기열로 넘어간다. 사실성 검증과 중복 검사도 병행한다. 직접 만든 중복 검사 가드를 검증해 보니, 이미 발행된 글 35편끼리 비교했을 때 595쌍 중 73쌍(12.3%)을 중복이라고 잘못 판정했다. 민감도 조절이 필요한 숙제다.

    사람이 개입하지 않는 안전한 자동화 기준선

    통과하지 못한 초안은 발행되지 않는다. 기계가 기준을 통제하기 때문에 품질이 떨어지는 글이 노출될 일이 없다. 다만 중복 검사의 오탐지율을 그대로 두면 발행량이 급감하므로, 예외 처리 로직을 보완하는 중이다.

    자동 포스팅 품질 검사 일러스트

    자동화 파이프라인의 비용과 스케줄 관리

    헤드리스 LLM 호출 비용 최적화

    무인으로 시스템을 돌리면 비용이 걱정된다. 헤드리스로 LLM을 부를 때 기본 설정은 1회 호출당 $0.78이었다. 매일 글을 쓰고 검사하면 비용이 감당이 안 된다. 모델과 작업 디렉터리를 지정하고 불필요한 도구를 떼어내니 $0.028로 27배 줄었다. 기본 설정 그대로 쓰면 큰일 난다.

    크론 스케줄링과 병렬 처리

    지금은 cron 63개를 무인으로 돌리고 있다. 글 생성, 검사, 발행, 모니터링이 각각의 크론으로 분리되어 있다. 시간대를 잘 분산시키지 않으면 서버 리소스가 튀고 API 호출이 실패한다.

    1인 빌더의 리소스 한계 관리

    자동화가 늘어난다고 해서 사람의 피로도가 없어지는 건 아니다. 파이프라인이 꼬일 때마다 어디서 문제가 났는지 추적하는 게 일이다. 로그를 꼼꼼히 남기지 않으면 디버깅 자체가 불가능해진다.

    발행 이후: 무인 크론 루틴과 예외 처리 전략

    크론(Cron)으로 이어지는 1인 빌더의 발행 루틴

    글은 자동 파이프라인이 주 1~5편으로 불규칙하게 초안을 만든다. 불규칙적인 주기가 오히려 자연스러운 발행 패턴으로 보인다. 문체와 사실성 자동 검사를 통과한 글만 워드프레스에 공개된다. 이 루틴은 사람이 개입하지 않는다.

    검사에서 걸린 초안, 사람은 어떻게 후속 처리하는가

    검사에서 불합격한 초안은 사람이 검토한다. 자동화가 완벽할 수 없기 때문에, 기계가 판단하기 애매했던 글은 결국 내가 열어보게 된다. 주로 팩트 오류나 심하게 뒤틀린 문맥이 원인이다. 이때는 초안을 폐기하거나 프롬프트를 수정하여 처음부터 다시 돌린다.

    자동화 시스템의 한계와 모니터링 세팅

    시스템이 멈췄을 때 알 수 있어야 한다. 에러 로그를 슬랙으로 쏘게 세팅해 두지 않으면, 발행이 멈춘 지 일주일이 지나서야 알게 된다. 모니터링은 선택이 아니라 필수다.

    요약 및 1인 빌더를 위한 다음 액션

    워드프레스 자동 발행 시스템 3단계 루틴 요약

    REST API로 발행 파이프라인을 잡고, 메타 태그와 슬러그를 자동 매핑하며, 기계의 자체 품질 검사로 패널티를 방어하는 것이 핵심이다. 플러그인에 의존하지 않고 비용을 통제하는 것도 빠질 수 없는 과정이다.

    지금 바로 세팅해야 할 자동화 체크리스트

    1인 빌더라면 다음 항목을 점검해 보자.

    • REST API 애플리케이션 비밀번호 발급 및 테스트 발행
    • AI 초안 생성 시 메타 데이터 JSON 매핑 로직 추가
    • 발행 전 AI 문체 지문 및 중복 검사 스크립트 구현
    • 불합격 초안의 후속 처리 및 에러 모니터링 세팅

    SaaS 규모를 키우기 위한 콘텐츠 전략

    콘텐츠 발행이 기계화되면 1인 빌더는 제품 개발에 집중할 수 있다. 완벽한 자동화는 없지만, 한계를 인정하고 기계가 통제할 수 있는 영역을 넓히는 게 결국 SaaS를 키우는 길이다.

    참고한 공식 문서


    글쓴이 정보

    이 글의 초안도 운영자가 만든 AI 파이프라인이 씁니다. 문체·사실성 자동 검사를 통과한 글만 공개되고, 걸린 초안은 사람이 고쳐서 내보냅니다. 전체 구조는 포트폴리오에 적어 두었습니다.

  • 텍스트 한 줄로 카드뉴스 영상 만드는 법

    텍스트 한 줄로 카드뉴스 영상 만드는 법

    이젠 Canva에서 이미지 10장 직접 넣는 게 의미 없다

    1인 사업자가 카드뉴스에 집착해야 하는 진짜 이유

    매일 블로그 글을 쓰고 나서 릴스로 옮기려니 영상 편집이 발목을 잡는다. 카드뉴스 영상 만드는 법을 검색해봐야 Canva에서 이미지 10장 넣고 텍스트 박고 음악 입히는 반복 작업이 전부다. 1인 사업자에게 편집 프로그램 켜는 시간은 곧 비용이다. 포토샵이나 프리미어프로를 배우는 것보다 텍스트 한 줄을 API에 던져서 완성본을 받아내는 방식으로 시스템을 바꿨다.

    인스타 한 계정의 최근 30편을 재보니 릴스 18편은 조회수 중앙값이 50이었고, 피드 12편은 0이었다. 숫자가 보여주듯 사진 카드뉴스는 피드에서 묻힌다. 세로형 영상 포맷이 아니면 노출 자체가 안 된다. 내가 카드뉴스에 매달리는 건 단순한 유행이 아니라 트래픽을 남기기 위한 가장 현실적인 출구라서다.

    편집 프로그램 없이 텍스트만으로 영상이 만들어지는 원리

    카드뉴스 자동화란 블로그 HTML이나 마크다운 텍스트를 파싱하여 이미지 생성 API와 비디오 렌더링 API로 전달해 완성본을 반환하는 무인 파이프라인을 뜻한다. 사람이 끼어들 지 않는다. 이 블로그는 한 달 반 동안 43편을 발행했다(2026-07-07~08-23, 47일). 이 작업이 가능한 이유는 편집을 기계에 떠넘겼기 때문이다. 주 1~5편으로 불규칙하게 초안을 만들고 문체와 사실성 검사를 통과한 글만 공개되는 구조다.

    블로그 텍스트 한 줄, 카드뉴스 영상으로 변환하는 워크플로우

    텍스트 입력부터 9:16 비율 변환까지 자동화 파이프라인

    아일리고(AILEEGO)가 실제 운영 중인 크론 기반 텍스트-영상 자동화 워크플로우는 4단계로 짜여 있다. 블로그 글이 발행되면 텍스트가 파싱되어 이미지로 변환되고, 9:16 캔버스에 합성된 뒤 렌더링 검증을 거쳐 영상으로 나온다.

    1. 블로그 텍스트를 문단 단위로 분할한다
    2. 각 문단의 핵심 키워드를 추출해 이미지를 매칭하거나 API로 생성한다
    3. 9:16 캔버스에 텍스트와 이미지를 합성해 렌더링한다
    4. 폰트 렌더링 깨짐 여부를 시각적 안전 마진 안에서 검증한다

    헤드리스로 LLM을 부를 때 기본 설정은 1회 $0.78 이었다. 모델과 작업 디렉터리를 지정하고 불필요한 도구를 떼자 $0.028 로 27배 줄었다. 텍스트와 이미지 매칭을 한 번에 처리하면 비용이 터지기 때문에 파싱 단계부터 극단적으로 쪼개서 던지는 게 낫다.

    node render_video.js --input post.md --aspect 9:16 --safeZone true

    API를 활용한 이미지-텍스트 매칭 및 자동 자막 생성

    이미지 매칭은 키워드 추출 API와 이미지 생성 API를 순차적으로 묶어서 처리한다. 텍스트가 입력되면 핵심 명사를 뽑아내고, 그 단어에 맞는 프롬프트를 조립해 비주얼을 만들어낸다.

    주어진 텍스트에서 한 문장씩 추출해 9:16 비율에 맞는 카드뉴스 장면을 JSON 형태로 설명하라. 각 장면은 배경 이미지 생성 프롬프트와 화면에 띄울 텍스트로 구성한다.

    9:16 세로형 카드뉴스 영상의 가장 이상적인 길이는?

    시청 지속률을 높이는 최적의 초 단위

    9:16 세로형 영상 최적화란 시청자의 첫 1초 이탈을 막기 위해 텍스트 노출 시간과 장면 전환 속도를 플랫폼 데이터 기반으로 조절하는 과정을 의미한다. 무작정 짧게 만들면 조회수가 나오는 게 아니다. 텍스트가 너무 길어 읽기 부담스러운 구간에서 시청자가 이탈하기 시작한다.

    영상 길이를 최소 단위로 쪼개고 첫 장면에서 시선을 끄집어오는 구조로 수정했다. 인스타 데이터를 보면 릴스 18편의 조회수 중앙값이 50이었고 피드 12편은 0이었다. 텍스트를 읽어주는 시간을 장면 전환 속도에 맞추다 보니 자연스럽게 짧아졌다.

    플랫폼(인스타/쇼츠)별 체류 시간 분석 데이터

    쇼츠와 릴스는 체류 시간 잣대가 다르다. 인스타는 첫 3초가 관건이고 쇼츠는 끝까지 보는 비율이 더 중요하다. 텍스트를 9:16 화면에 꽉 채우기보단 상단 3분의 1에만 배치하고 나머지는 여백으로 두니 이탈률이 낮아졌다.

    텍스트를 영상으로 자동 변환

    영상 제작 시 텍스트가 화면 밖으로 나가거나 깨지는 것 방지법

    모바일 노치(UI)를 고려한 9:16 안전 영역(Safe Zone) 설정

    안전 영역(Safe Zone)이란 스마트폰의 노치나 하단 UI 가림 현상을 피하기 위해 9:16 캔버스 중앙에 확보해야 하는 텍스트 렌더링 경계선이다. 자동화 과정에서 텍스트 오버플로우로 영상을 폐기한 적이 있다. AI가 만든 텍스트가 9:16 화면 밖으로 나가거나 폰트 렌더링이 깨지는 현상이 잦았다.

    직접 만든 중복 검사 가드를 검증해 보니 이미 발행된 글 35편끼리 비교했을 때 595쌍 중 73쌍(12.3%)을 중복이라고 잘못 판정했다. 텍스트 매칭 검증 로직도 비슷한 함정이 있다. 지나치게 엄격하게 걸러내면 정상 텍스트까지 잘려 나간다. 그래서 수동 검토 단계를 아예 없애지는 못했다.

    AI 자동 줄바꿈 및 폰트 렌더링 깨짐 방지 로직

    CSS 수준의 박스 모델을 캔버스에 그대로 적용했다. 자간과 행간을 고정하고, 텍스트가 상자를 벗어나면 글자 크기를 줄이거나 줄바꿈하는 스크립트를 넣었다.

    {
      "canvas": {
        "width": 1080,
        "height": 1920,
        "safe_zone": { "top": 200, "bottom": 200, "padding": 80 }
      },
      "text_box": "wrap_text_hard",
      "font": "Pretendard-Bold"
    }

    설정을 바꿔 렌더링을 다시 돌리니 폐기율이 줄었다. 텍스트가 가장자리로 나가는 문제는 safe_zone 여백을 넓히는 것으로 해결됐다. 폰트가 깨지는 건 시스템 기본 폰트를 쓰지 않고 웹폰트를 캔버스에 임베딩하면서 잡혔다.

    텍스트 1줄이면 콘텐츠 매트릭스가 완성된다

    1인 빌더를 위한 콘텐츠 자동화 다음 단계

    혼자서 여러 SaaS를 굴리려면 콘텐츠 발행이 기계화되어야 한다. 현재 작업 폴더가 183개, git 저장소가 90개 쌓여 있다. cron 63개를 무인으로 돌리고 있다. 1인 빌더의 생산성은 여기서 나온다.

    자동 생성한 글의 AI 문체 지문을 재보니 1,000자당 10.1건이었고, 손으로 고친 뒤 1.4건으로 떨어졌다. 영상 변환 전 텍스트 품질부터 잡아야 한다. 문체가 기계 티를 내면 시청자가 스와이프를 멈추지 않는다.

    지금 바로 실험해 볼 텍스트-영상 프롬프트

    텍스트만으로 영상을 찍어내는 시스템 구축이 끝났다면 다음은 자동화 시스템 고도화와 훅 설계로 넘어가면 된다. 아래 프롬프트를 복사해 바로 실험해 볼 수 있다.

    블로그 본문 500자를 입력할 테니, 9:16 카드뉴스 3장 분량의 콘티를 짜라. 각 장면은 상단에 들어갈 10자 이내의 헤드라인, 중앙의 본문 텍스트, 하단의 이미지 생성 키워드를 포함한다.

    이 흐름이 익숙해지면 텍스트 1줄로 영상 1편을 찍어내는 1인 공장 라인이 완성된다.

    근거로 삼은 문서


    글쓴이 정보

    여기 올라오는 글의 초안은 운영자가 만든 AI 파이프라인이 자동으로 만듭니다. 다만 문체·사실성 검사를 통과하지 못한 초안은 공개되지 않고 사람이 손봅니다. 그 과정은 포트폴리오에서 볼 수 있습니다.

    자주 나오는 질문

    카드뉴스 영상을 만들 때 텍스트가 화면 밖으로 나가는 건 어떻게 방지하나요?

    9:16 캔버스 중앙에 스마트폰 노치나 하단 UI를 피하는 안전 영역(Safe Zone)을 설정해야 합니다. CSS 박스 모델처럼 자간과 행간을 고정하고, 텍스트가 상자를 벗어나면 글자 크기를 줄이거나 줄바꿈하는 스크립트를 적용하면 렌더링 깨짐을 막을 수 있습니다.

    9:16 세로형 카드뉴스 영상의 가장 이상적인 길이는 얼마인가요?

    시청자의 첫 1초 이탈을 막기 위해 텍스트 노출 시간과 장면 전환 속도를 조절하는 것이 핵심입니다. 무작정 짧게 만들기보다 텍스트를 읽어주는 시간에 맞춰 전환 속도를 세팅하고, 텍스트는 화면 상단 3분의 1에만 배치해 이탈률을 낮추는 게 좋습니다.

    텍스트 한 줄로 카드뉴스 영상을 자동화하는 원리는 무엇인가요?

    블로그 HTML이나 마크다운 텍스트를 파싱해 이미지 생성 API와 비디오 렌더링 API로 전달하는 무인 파이프라인을 구축하는 방식입니다. 텍스트에서 핵심 명사를 추출해 이미지를 매칭하고 9:16 캔버스에 합성한 뒤 렌더링 검증을 거쳐 완성본을 받아냅니다.

    카드뉴스 자동화 작업 시 API 비용을 줄이려면 어떻게 해야 하나요?

    LLM을 호출할 때 모델과 작업 디렉터리를 지정하고 불필요한 도구를 제외하면 비용을 크게 낮출 수 있습니다. 텍스트와 이미지 매칭을 한 번에 처리하면 비용이 터지므로, 파싱 단계부터 극단적으로 잘게 쪼개서 API에 던지는 것이 유리합니다.

    쇼츠와 릴스는 카드뉴스 시청 지속률 기준이 어떻게 다른가요?

    인스타 릴스는 첫 3초가 관건이고, 쇼츠는 끝까지 보는 비율이 더 중요하게 작용합니다. 그래서 텍스트를 9:16 화면에 꽉 채우기보단 상단 3분의 1에만 배치하고 나머지는 여백으로 두는 방식으로 플랫폼별 이탈률을 낮출 수 있습니다.

    자동화된 카드뉴스에서 텍스트 중복이나 잘못된 매칭은 어떻게 검사하나요?

    자동화 과정에서 텍스트 오버플로우나 중복 판정이 발생할 수 있어 수동 검토 단계를 완전히 없애기는 어렵습니다. 지나치게 엄격하게 필터링하면 정상 텍스트까지 잘려 나가기 때문에, 검증 로직과 함께 최종적으로 수동 검토를 거치는 하이브리드 방식이 안전합니다.

  • GPT와 Make로 0원으로 뉴스레터 자동화하는 법

    GPT와 Make로 0원으로 뉴스레터 자동화하는 법

    매일 글 쓰다가 쓰러질 뻔한 당신을 위한 자동화 진단

    뉴스레터 자동화는 파이프라인을 하루 만에 세우는 일이 아니라, 실패했을 때 누가 알려주느냐를 확보하는 일이다. 무료 도구 조합으로 파이프라인은 하루면 서지만, 오래 사는 쪽은 결국 감시가 붙은 쪽이다.

    아침마다 뉴스를 스크랩하고, 요약하고, 메일링 서비스에 업로드하다 보면 하루가 시작되기도 전에 에너지가 바닥난다. 처음엔 의욕적으로 시작한 뉴스레터도 일주일이 지나면 숙제가 되곤 한다. 매일 반복되는 이 짓을 언제까지나 사람의 손으로 할 순 없다. 혼자 여러 서비스의 콘텐츠를 만들어 봐서 그 고통을 안다. 언젠가는 꼭 멈출 수밖에 없는 노동이 지속 가능할 리 없으니까.

    그래서 AI 자동화가 필요하다. 단순히 귀찮아서가 아니다. 내 핵심 역량인 기술 개발이나 마케팅 전략에 집중하기 위해서다. AI 뉴스레터 콘텐츠 자동화는 선택이 아닌 생존 문제다. 내가 직접 쓰지 않아도 괜찮은 퀄리티의 글이 매일 쌓이게 만드는 것이 1인 크리에이터가 살아남는 길이다.

    뉴스레터, 지키다가 지치는 이유

    사람이 글을 쓸 때는 필연적으로 ‘쓰기의 압박’이 생긴다. 오늘의 핫한 이슈가 뭔지 찾아보고, 내 생각을 덧붙이고, 문장을 다듬는 과정에서 최소 2~3시간은 증발한다. 스케줄을 어기면 독자에게 미안하고, 그러다 보니 결국엔 아예 발행을 포기하게 된다. 내가 운영하는 서비스들도 초기엔 수기로 글을 썼다. 다만 서비스가 하나둘 늘어날수록 손도 근력도 한계가 명확했고, 무언가 바꿔야만 했다.

    AI 자동화가 대체 왜 필요한가?

    필요한 건 흠 없는 글이 아니라, 꾸준히 가는 뉴스레터다. AI는 내 대신 ‘반복’을 질색하지 않고 수행해준다. 내 경험상 자동화 시스템이 갖춰지고 나서 뉴스레터 구독자 수는 꾸준히 올랐다. 내가 신경 써야 할 건 오직 ‘시스템이 망가졌나?’ 정도뿐이다.

    가장 먼저 준비해야 할 소스(뉴스/피드)는 어디서 구하나요?

    좋은 글은 좋은 재료에서 시작한다. 아무리 GPT가 똑똑해도 쓰레기 정보를 넣으면 쓰레기 요약만 나온다. 소스 선정이 자동화의 50% 이상을 좌우한다고 보면 된다.

    RSS 피드, 구글 뉴스, 그리고 커뮤니티 활용법

    가장 확실한 건 RSS 피드다. 네이버 뉴스, 다음 뉴스 같은 주요 매체는 대부분 RSS를 제공한다. 트위터(현재 X)의 리스트 기능도 꽤 유용하다. 관심 있는 분야의 전문가들을 리스트로 묶어두면 그들의 게시글이 곧 훌륭한 소스가 된다. 구글 뉴스는 키워드를 설정해 알림을 받거나, 특정 섹션의 URL을 긁어오는 방식을 쓴다. 요즘은 미디엄(Medium)이나 서브스택(Substack) 같은 플랫폼에서도 RSS를 제공하니 이들을 적극 활용한다.

    정보의 질을 결정하는 소스 선정 기준

    봐야 할 건 ‘필터링’이다. 모든 기사를 긁어올 필요는 없다. 내가 만드는 SaaS나 관심 키워드와 정확히 일치하는 것만 쏙 뽑아야 한다. 예를 들어 ‘No-Code’ 관련 뉴스레터를 만든다면, 굳이 연예란 뉴스를 다루는 IT 포털의 전체 피드를 가져올 필요가 없다. 해당 키워드를 포함하는 전문 블로그나 구글 뉴스의 ‘Top Stories’ 중 키워드가 포함된 URL만 추출하는 식으로 접근해야 소음이 줄어든다.

    AI가 가져온 뉴스를 내 톤앤매너에 맞게 수정하는 프롬프트

    뉴스 원문을 긁어왔다고 바로 발행하면 안 된다. GPT가 뱉어내는 기본 요약은 번역투이거나, 딱딱하기 그지없다. 여기서 프롬프트 엔지니어링이 필요하다. 파인튜닝 같은 복잡한 과정 없이 프롬프트만으로 퀄리티를 끌어올릴 수 있다.

    기계적인 번역투를 없애는 프롬프트 전략

    AI 글쓰기는 결국 ‘지시’의 싸움이다. “요약해줘”라고만 하면 GPT는 그냥 문장을 줄여버린다. 대신 “대화하듯이”, “비유를 섞어서”라고 지시해야 한다. 특히 문장 끝이 “~했습니다”, “~입니다”로 도배되는 걸 막아야 한다. 내가 유튜브 쇼츠 스크립트를 자동화할 때도 처음엔 AI가 너무 진지하고 딱딱한 설명조로 써내려갔다. 시청자가 3초도 안 되고 나가버리는 참사를 겪고 나서 프롬프트를 뜯어고쳤다.

    지금부터 너는 내 뉴스레터의 편집자야. 아래 뉴스 원문을 바탕으로 구독자들이 1분 안에 핵심을 이해할 수 있게 요약해 줘. 절대 기계적인 번역투를 쓰지 말고, 친구에게 카톡 보내듯 가볍게 말해줘. 어려운 전문 용어는 쉽게 풀어서 설명하고, 적절한 비유를 한 번 넣어줘. 이모지는 과하게 쓰지 말고 문장의 흐름을 끊지 않는 선에서 2개만 넣어. 줄바꿈은 가독성을 위해 자주 해줘.

    아일리고가 쓰는 ‘편집자 페르소나’ 부여법

    AI에게 역할을 부여하면 응답 퀄리티가 확 달라진다. 그냥 AI가 아니라 ’10년 차 기자’, ‘유머러스한 개발자’처럼 구체적인 페르소나를 입히는 것이다. 나는 “누구보다 기술을 빨리 흡수하는 1인 개발자”라는 페르소나를 준다. 그러면 글에서 내가 쓰고 싶어 했던 톤앤매너가 살아난다. 내 경우 페르소나를 준 뒤 톤이 일정해져서 발송 전에 문장을 손보는 시간이 줄었다.

    실제로 코드 없이 자동화 파이프라인을 구축하는 전체 과정

    이제 원본도 있고, 프롬프트도 준비됐다. Make(구 인티그로매트) 같은 노코드 자동화 툴로 이들을 엮는다. 코딩 한 줄 필요 없다.

    Make(인티그로매트) 기본 연결: 웹훅부터 GPT까지

    시나리오는 이렇게 짠다. 먼저 ‘Webhooks’ 모듈로 트리거를 만든다. 다음으로 ‘RSS – Watch Feed Items’를 연결해 실시간으로 새 글이 올라오는지 감시한다. 새 글이 잡히면 그 내용을 ‘OpenAI – Create a Completion’으로 보낸다. 여기서 아까 만든 프롬프트를 시스템 메시지에 넣고, 유저 메시지에는 뉴스 원문을 넣는다. 이 과정만으로 AI가 쓴 초안이 떨어진다.

    발행 플랫폼(뉴스레터 서비스·메일)과의 연동 및 테스트

    AI가 정제한 텍스트는 이제 발행처로 보내진다. 스티비(Stibee)·메일침프(Mailchimp) 같은 뉴스레터 플랫폼이나 Gmail 의 초안 작성 기능을 연동하면 된다. Make에서 ‘Gmail – Create a Draft’를 선택하고, 제목과 본문에 AI가 만든 텍스트를 매핑한다. 테스트를 꼭 수동으로 돌려보자. 내용이 너무 길지는 않은지, 형식이 깨지지는 않는지 확인해야 한다.

    자동화의 안전장치: 에러 발생 시 알림 설정

    자동화에도 ‘에어백’은 필수다. API가 터지거나 RSS 소스가 변경되면 파이프라인이 멈춘다. 나는 한동안 이걸 몰라 며칠간 뉴스레터 발행이 멈춘 사태를 겪었다. Make의 ‘Error Router’ 기능을 써서, 에러가 발생하면 슬랙(Slack)이나 텔레그램으로 알림이 오도록 설정했다. 비상시 대처 시스템이 없는 자동화는 폭탄이다.

    자동화 파이프라인 구축

    자동화로 만든 글이 너무 기계적으로 보이지 않게 하는 팁

    자동화의 적은 ‘중복’과 ‘맥락 부재’다. 똑같은 뉴스를 다루는 경쟁 뉴스레터와 차별화하려면 미세한 조정이 필요하다.

    소제목과 도입부에 ‘후킹’ 요소 넣기

    소제목은 단순히 내용을 요약해서 쓰지 마라. 호기심을 자극해야 한다. 예를 들어 “GPT-5 출시 예정” 보다는 “GPT-5, 당신의 직업을 바꿀까?” 처럼 질문 형태를 던지는 식이다. 도입부 첫 문장은 꼭 독자의 공감이나 궁금증을 건드려야 이탈을 막을 수 있다.

    적절한 문장 길이와 줄바꿈 설정

    AI는 한 번에 길게 쓰려는 성질이 있다. 프롬프트에 “문장은 3줄을 넘지 않게 써”라고 제약을 걸어야 모바일에서 읽기 편한 글이 나온다. 이모지도 전략적으로 써야 한다. 문단마다 이모지를 하나씩 박아두면 가독성은 올라가지만, 너무 많으면 장난스러워 보인다. 나는 문단 소제목 옆에만 이모지를 넣도록 설정해 뒀다.

    이 자동화 시스템을 돌리기 위해 월 비용은 얼마나 들까?

    무료 한도 안에서는 0원으로 돌릴 수 있다. Make 무료 플랜(월 1,000 operations)과 무료 RSS 피드가 기본이고, 언어 모델 호출은 무료 티어가 있는 API(예: Gemini 무료 등급)를 쓰면 소량 발송에는 비용이 붙지 않는다.

    0원으로 구축 가능한 플랜 조합

    하루에 뉴스레터 한두 개를 보낸다면 Make의 무료 플랜이 거의 넉넉하다. 언어 모델은 무료 티어가 있는 API를 고르면 하루 한두 통 규모에서는 과금이 거의 생기지 않는다. 각 서비스의 무료 한도를 꼼꼼히 챙기면 월 비용을 거의 들이지 않고 돌린다.

    확장 시 발생하는 비용과 트래픽 관리법

    발행 횟수가 늘어나면 Make의 유료 플랜(약 10달러)을 생각해볼 만하다. 다만 그전에 불필요한 모듈을 줄여서 operations를 아껴야 한다. OpenAI 요금은 사용량에 비례하니, 프롬프트를 너무 길게 쓰지 않는 것도 비용 절감의 한 방법이다.

    뉴스레터 자동화, 그다음은 무엇일까?

    텍스트 뉴스레터로 정보를 전달하는 것만으로는 부족할 때가 온다. 요즘은 텍스트보다 영상의 소비 속도가 빠르다. 이미 정제된 뉴스레터 텍스트는 영상 제작을 위한 흠 없는 대본이다. 여기서 이 대본을 텍스트 기반 숏폼 영상 생성 도구에 그대로 넣으면 1분 남짓한 영상 초안까지 이어진다.

    자동화를 몇 개나 돌리면 무엇이 문제가 되는가 (2026년 8월 28일 기준)

    도구 설명은 어디에나 있으니 내가 실제로 돌리는 규모부터 적는다. 오늘 기준 이 컴퓨터의 크론탭에는 주석을 뺀 활성 작업이 99줄 있다. 그중 48줄이 무언가를 만들어 내보내는 발행·게시 계열이다. 경로별로 세면 스크립트 모음 41, 작업 폴더 36, 쇼츠 엔진 8, 소셜 대시보드 6줄이고 나머지는 감시·백업 잡이다.

    이 숫자가 말해주는 건 자동화의 난이도가 개수에 비례하지 않는다는 것이다. 만드는 건 한 번 짜면 끝이다. 문제는 안 돌았을 때 알아채는 일이고, 이건 개수만큼 늘어난다.

    실제로 이 집에서 블로그 발행 봇이 9일 동안 0편을 내놓은 적이 있다. 코드가 죽은 게 아니라 예외 하나가 알림 코드보다 먼저 터져서, 실패 알림 자체가 실행되지 않았다. 로그에는 앞부분이 정상으로 찍혀 있어서 더 안 보였다. 그 뒤로는 감시를 그 작업 안이 아니라 바깥의 별도 작업으로 옮겼다. 프로세스가 통째로 죽으면 그 안의 알림도 같이 죽기 때문이다.

    지금은 사이트 가용성도 바깥에서 본다. 외부 감시는 최근 20회 실행 중 2회 실패를 기록했다. 실패율 10%라는 숫자 자체보다, 그 2회를 내가 화면을 보지 않고도 알았다는 점이 자동화의 본체다.

    그래서 뉴스레터 자동화를 처음 짠다면 순서를 이렇게 잡길 권한다. 발송을 만들기 전에 발송 실패가 어디로 통보되는지부터 정한다. 메일이든 메신저든, 내가 하루에 한 번은 반드시 보는 곳이어야 한다.

    참고한 공식 문서


    글쓴이 정보

    이 블로그의 초안은 운영자가 만든 AI 파이프라인이 자동 생성하고, 문체·사실성 자동 검사를 통과한 글만 공개합니다. 검사에서 걸린 초안은 사람이 손을 봅니다. 만드는 과정은 포트폴리오에 정리해 두었습니다.

    자주 묻는 질문

    뉴스레터 자동화에 가장 중요한 건 뭔가요?

    AI 툴보다 소스 선정이 더 중요합니다. 쓰레기 정보를 넣으면 아무리 GPT가 똑똑해도 훌륭한 요약이 나오지 않으니, 내 키워드와 정확히 일치하는 양질의 RSS 피드를 확보하는 게 50% 이상을 좌우합니다.

    AI가 쓴 뉴스레터가 기계투처럼 보이는데 어떻게 해결하나요?

    프롬프트 엔지니어링으로 ‘편집자 페르소나’를 부여하세요. ‘친구에게 카톡 보내듯 말해줘’나 ’10년 차 기자가 쓴 것처럼’처럼 구체적인 역할과 톤을 지시하면 번역투가 사라지고 글의 맛이 살아납니다.

    Make(인티그로매트)로 자동화할 때 비용이 많이 드나요?

    핵심 기능은 0원으로 구축할 수 있습니다. 웹훅, RSS 감시, OpenAI 연결 등 기본 파이프라인은 무료 플랜 범위 내에서 충분히 구성 가능하므로 초기 비용 부담 없이 시작해보는 게 좋습니다.

    자동화하다가 실수로 저작권 위반이나 허위 사실을 전파할 위험은 없나요?

    AI가 요약 과정에서 정보를 왜곡할 가능성은 있으므로, 초안은 자동으로 만들더라도 최종 발행 전에는 핵심 팩트만 훑어보는 ‘감수’ 과정을 거치는 것을 권장합니다.

    뉴스 소스를 찾을 때 구체적인 추천처가 있나요?

    네이버나 다음 같은 주요 매체의 RSS를 활용하고, 구글 뉴스에서 특정 키워드를 설정해 알림을 받거나 관련 분야 전문가들의 X(트위터) 리스트를 활용하면 신뢰도 높은 최신 소스를 확보하기 쉽습니다.

  • 세금 폭탄 맞기 전 1인 개발자 점검 3곳

    세금 폭탄 맞기 전 1인 개발자 점검 3곳

    첫 수익이 발생했는데, 지금 당장 무엇을 신고해야 할까요

    카카오톡 알림 소리에 울렁증이 온다. SaaS 첫 결제가 들어온 날, 기쁨보다 당황이 앞섰던 경험이 있다. 돈이 들어왔는데 뭘 해야 할지 모르겠는 게 당연하다. 1인 개발자 세금 신고 필수 항목을 하나하나 챙기다 보면 금방 익숙해진다. 가장 먼저 구분해야 할 건 부가세와 종합소득세다. 헷갈리게 하지만 신고 시기와 대상이 다르다. 아예 다른 세금이다.

    부가세는 반기로 끊는다. 개인 일반과세자는 1~6월치를 7월 25일까지, 7~12월치를 다음 해 1월 25일까지 확정신고한다. 4월과 10월에 오는 예정고지서는 직전 반기에 낸 세액의 절반을 미리 내는 것이라 보통 납부만 하면 되고, 매출이 크게 줄었으면 그때는 직접 예정신고를 할 수 있다(1기 예정신고 기한은 4월 25일). 종합소득세는 1년 전체를 합쳐서 다음 해 5월에 신고한다. 지금 당장 급한 건 부가 신고다. 사업자 등록을 하지 않았더라도 일정 규모 이상의 수익이 발생하면 사업자로 간주되어 신고 대상이 된다. 신규 1인 개발자가 범하기 쉬운 실수가 있다. 사업자번호 개설 전 테스트로 벌어들인 수익을 그냥 넘기는 경우다. 이건 누락되면 나중에 가산세를 낼 수 있다. 테스트 수익이라도 사업 관련성이 있다면 신고 대상이다.

    업무 비용인지 아닌지, 그 기준을 코드로 치면 어떡하죠

    세무사들은 “업무와 관련성”이라고 말한다. 개발자 입장에서 이 말은 너무 추상적이다. 코드로 치면 런타임 에러가 나지 않게 하는 의존성과 비슷하다. AWS 비용 청구서, GCP 세금 계산서, Cloudflare 도메인 결제 내역은 가장 명확한 필수 비용이다. 이건 서비스가 돌아가는 데 없어서는 안 될 리소스다.

    헷갈리는 건 장비다. 맥북을 샀는데 회사 일로 100% 쓴다. 그럼 경비인가? 기준은 업무 전용 여부다. 개인 용도(게임, 넷플릭스)로 섞어 쓰면 경비 인정이 까다롭다. 노트북과 모니터처럼 고가 장비는 업무용 쓰임새를 입증하는 자료를 남겨둬야 나중에 심사 때 걸리지 않는다. 일반 관리비와 업무 무관 지출의 경계를 명확히 하는 게 핵심이다. 카페비는 업무 미팅 증빙이 되어야 하고, 식대는 접대 비용으로 처리할 때 한도가 있다.

    홈택스 마스터하기: 원천징수 조회와 세금 계산서 발행

    홈택스 UI는 개발자 친화적이지 않다. 그래도 메뉴 위치 정도는 외워둬야 한다. 내가 받은 원천징수 내역은 홈택스에 로그인해 My홈택스의 지급명세서 제출내역에서 확인한다. 여기서 3.3%의 원천징수 세금이 제대로 잡혔는지 본다. 이름이 비슷한 ‘원천징수이행상황신고’는 돈을 **주는** 쪽이 신고하는 메뉴라 받는 사람이 볼 곳이 아니다. 홈택스 메뉴 이름은 개편 때마다 바뀌므로 최종 위치는 화면에서 검색해 확인하는 게 빠르다. B2B 거래를 할 때 상대방이 세금을 떼어갔다면 이 내역이 있어야 한다.

    계산서를 발행해야 할 때도 있다. 사업자끼리 거래하면 금액과 관계없이 세금계산서를 발행하는 게 원칙이다(부가가치세법 제32조). 흔히 말하는 3만 원은 발행 기준이 아니라 받는 쪽의 증빙 기준이다 — 건당 3만 원을 넘는 지출에 세금계산서·신용카드 매출전표·현금영수증 같은 적격증빙이 없으면 증빙불비 가산세 2%를 문다. ‘계산서 발행 및 수취 내역’ 메뉴에서 입력하면 된다. 스크립트로 돌리는 자동화와는 다르게 수동 입력이라 실수가 잦다. 현금영수증과 세금계산서 중 뭘 써야 할까? 사업자 간 거래는 세금계산서다. 개인 고객에게 서비스를 파는 SaaS라면 신용카드 매출전표나 현금영수증이 증빙이 된다. 고객이 계산서를 달라고 하면 그때 발행 메뉴를 찾아가면 된다.

    업무 비용 분석하는 돋보기

    간편장부 vs 복식부기, 어떤 선택이 개발자에게 유리한가

    단순 비용 절감만 생각하면 간편장부가 편해 보인다. 하지만 SaaS 운영 구조를 보면 복식부기가 더 효율적일 때가 많다. 장부 세액 공제를 받을 수 있기 때문이다. 서버 비용과 API 사용료처럼 매입이 명확하게 발생하는 SaaS 사업은 복식부기의 장점을 극대화하기 좋다. 간편장부는 단순수익금액에 비례해 추계 경비를 인정해주지만, 실제 쓴 비용이 그보다 많으면 손해다.

    복식부기는 장부를 쓰는 노력이 필요하다. 다행히 전자세금계산서와 연동되는 회계 툴을 쓰면 자동으로 장부가 만들어진다. 매입이 많은 1인 개발자라면 초기 세팅 비용을 들이더라도 복식부기를 선택하는 게 낫다. 장부 세액 공제 덕분에 환급받는 부가세가 간편장부보다 클 가능성이 높다. 단순히 기록의 편의성을 따지기보다 세금 절감 효과를 계산기로 두들겨보고 결정해야 한다.

    세금 신고를 위한 필수 서류와 관리 엑셀 양식

    복잡한 회계 소프트웨어 없어도 된다. 나는 엑셀 하나로 관리한다. 매출/매입 내역을 기록하는 최소한의 구조만 있으면 충분하다. 날짜, 품명, 공급가액, 부가세, 적요. 이 5개 컬럼만 있어도 세무사는 일을 처리할 수 있다. CSV 파일로 크론 작업을 돌려서 매달 내려받는 식으로 자동화를 구축해두면 두 번 손 쓸 일이 없다.

    증빙 서류 보관도 중요하다. 영수증이나 계약서는 종이로 뭉쳐두지 말고 PDF로 스캔해서 클라우드에 올려두자. 세무사에게 장부를 넘길 때 폴더 구조만 깔끔해도 작업 속도가 달라진다. 월별 단위로 폴더를 만들고 그달에 발생한 비용 영수증을 다 넣어둔다. 이거 하나만 지켜도 세무사가 “정리 잘해오셨네”라고 한다.

    세금 폭탄을 피하는 마지막 점검: 3가지 핵심

    가계 지출을 사업 경비로 넣지 마라. 편의점에서 산 커피나 점심값을 경비 처리하다가 걸리면 가산세가 만만치 않다. 업무와 명확히 관련된 비용만 올린다. 신고 기한을 놓치지 않는 것도 중요하다. 내 자동화 시스템에도 세금 신고 알림 크론이 돌고 있다. 깜빡하고 지나가면 납부 유예 승인을 받더라도 불이익이 따른다.

    투자 수익은 사업 수익이 아니다. 주식으로 번 돈을 SaaS 매출 항목에 넣으면 안 된다. 이건 분리해야 한다. 나는 직접 만든 도구를 써서 투자 내역을 사업 장부와 분리해서 관리한다. 섞으면 나중에 못 푼다. 투자 손익과 사업 손익이 섞이면 장부가 꼬이고 세금 신고 때 골치 아파진다. 코드로 돈을 버는 사람이라면 장부도 코드처럼 깔끔하게 유지하는 습관이 필수다.

    참고한 공식 문서

    고지 — 이 글은 세금에 관한 일반 정보이며 세무사의 자문을 대신하지 않습니다. 세법과 신고 기한은 바뀌므로 실제 신고 전에는 국세청 안내나 세무 전문가에게 확인하시기 바랍니다.


    글쓴이 정보

    여기 올라오는 글의 초안은 운영자가 만든 AI 파이프라인이 자동으로 만듭니다. 다만 문체·사실성 검사를 통과하지 못한 초안은 공개되지 않고 사람이 손봅니다. 그 과정은 포트폴리오에서 볼 수 있습니다.

    자주 묻는 질문

    사업자 등록 전 테스트 수익도 세금 신고를 해야 하나요?

    네, 사업 관련성이 있는 테스트 수익도 신고 대상입니다. 나중에 가산세를 피하려면 사업자번호 개설 전 수익도 누락 없이 합산해야 합니다.

    부가세와 종합소득세의 신고 시기는 어떻게 다른가요?

    개인 일반과세자는 1~6월치를 7월 25일까지, 7~12월치를 다음 해 1월 25일까지 확정신고합니다. 4월·10월 예정고지는 직전 반기 세액의 절반을 미리 내는 것이라 보통 납부만 하면 됩니다. 종합소득세는 1년치를 합산해 다음 해 5월에 신고합니다.

    고가 장비인 맥북을 업무 경비로 인정받으려면 어떻게 해야 하나요?

    업무 전용으로 사용된다는 것을 입증할 수 있는 자료를 남겨야 합니다. 개인 용도와 섞여 쓰면 인정이 까다로우므로 사용 내역을 명확히 관리하세요.

    B2B 거래 시 세금계산서와 현금영수증 중 뭘 써야 하나요?

    사업자 간 거래는 세금계산서를 발행합니다. 개인 고객에게 파는 경우에는 신용카드 매출전표나 현금영수증으로 증빙하면 됩니다.

    1인 개발자는 간편장부와 복식부기 중 무엇을 선택해야 하나요?

    서버 비용 등 매입이 많은 SaaS 구조라면 복식부기가 세액 공제 측면에서 유리합니다. 비용이 적다면 간편장부가 편하지만, 실제 지출보다 추계 경비가 적으면 손해를 볼 수 있습니다.

    세무사에게 장부를 넘길 때 가장 중요한 정리 포인트는?

    월별로 폴더를 만들어 비용 영수증을 PDF로 스캔해서 보관하세요. 엑셀에는 날짜, 품명, 공급가액, 부가세, 적요 5개 컬럼만 있어도 세무사가 처리하기에 충분합니다.


  • 블로그 속도 느릴 때 점검할 3곳

    블로그 속도 느릴 때 점검할 3곳

    트래픽이 갑자기 줄었다면, 먼저 속도부터 의심하라

    갑자기 구글 서치 콘솔에서 노출 수가 곤두박질칠 때가 있다. 글을 몇 편 더 썼는데도 조회수가 시들해진다면, 콘텐츠 문제가 아니라 속도 문제일 확률이 높다. 블로그 속도가 느려지면 사용자는 채 페이지를 다 보지 않고 뒤로 가기를 누른다. 이 이탈 신호를 구글이 포착하는 순간, 검색 순위 하락은 시간문제다.

    나도 자동화로 글을 쏟아내다가 서버 부하를 놓친 적이 있다. 20일 동안 35편을 발행하는 동안 크론 잡이 겹치는 시점에 방문자가 몰리자, 로딩 속도가 3초를 훌쩍 넘겼다. 그 결과 트래픽이 급감했고, 며칠 동안이나 회복하지 못했다. 운영 체계가 복잡해질수록 방치하면 터지는 게 속도다. 내 블로그가 느려졌다는 걸 깨닫는 건 방문자가 먼저 알게 되고 나서다.

    웹 페이지 속도 최적화는 단순한 기술적 점수 향상이 아니라, 사용자의 이탈을 막고 검색 엔진의 신뢰를 유지하는 비즈니스 필수 활동이다. 방치된 속도 저하는 곧 매출 감소로 직결된다.

    1단계: 이미지 외에 숨겨진 주범, ‘플러그인’과 ‘코드’

    속도가 느려질 때 대부분 이미지 압축부터 먼저 건드리지만, 이미지는 그다음 문제다. 워드프레스를 쓴다면 플러그인과 외부 스크립트가 훨씬 큰 병목 구간이다. 사용하지 않는 플러그인만 삭제한다고 끝나지 않는다. 활성화된 플러그인 하나가 로드할 때마다 PHP 코드를 실행하고 CSS, JS 파일을 추가로 불러온다.

    특히 주의해야 할 건 외부 스크립트다. 제3자 스크립트는 로딩 방식에 따라 네트워크와 메인 스레드를 점유해 렌더링을 늦출 수 있으므로, 실제 워터폴과 실행 시간을 측정해야 한다. 메인 콘텐츠 표시 지연은 DOMContentLoaded가 아니라 PerformanceObserver나 PageSpeed Insights에서 LCP와 그 하위 구간을 측정해 확인해야 한다. 렌더링 차단 리소스는 LCP에 영향을 줄 수 있지만, 실제 병목이 TTFB·LCP 리소스 발견·다운로드·렌더 지연 중 어디인지 먼저 측정해야 한다.

    불필요한 기능의 플러그인은 과감히 비활성화하고, 스크립트는 꼭 필요한 페이지에만 로드되도록 분리해야 한다. 외부 스크립트 최적화는 페이지 로딩 속도를 직접 결정짓는 가장 강력한 변수 중 하나다.

    2단계: 서버 응답 시간(TTFB)을 줄이는 당장 실천법

    페이지 속도 점수와 실제 체감이 다르면 TTFB뿐 아니라 실제 사용자 데이터, 네트워크, 캐시, 자바스크립트 실행 시간을 함께 점검해야 한다. 브라우저가 요청을 보내고 서버가 첫 바이트를 응답할 때까지의 시간이 길다는 뜻이다. 캐싱 플러그인만 켜두고 방치하면 이게 걸린다.

    1. 데이터베이스 쿼리 모니터링으로 느린 쿼리 찾기
    2. 이미지 용량과 개수 줄이기
    3. PHP 버전 업그레이드

    SaaS를 운영할 때 복잡한 쿼리가 응답을 늦추는 경험이 많다. 워드프레스도 예외가 아니다. 쿼리 모니터(Query Monitor) 같은 도구를 깔아보면, 의외의 플러그인이 무거운 쿼리를 수십 번 날리는 걸 볼 수 있다. 맹목적으로 캐싱 플러그인 힘만 믿다가는, 관리자 페이지에서는 캐시가 걸리지 않아 DB 부하를 그대로 맞고 작업 속도가 느려지는 역설을 겪게 된다. 데이터베이스 최적화는 쿼리를 줄이고 인덱스를 튜닝해서 서버가 일을 덜 하게 만드는 과정이다.

    플러그인과 서버 최적화

    3단계: 점검 순서를 헛되이 하지 않는 효율적인 수정 로드맵

    문제를 찾았다고 해서 한꺼번에 고치면 안 된다. 변수가 섞이면 뭐가 효과가 있었는지 알 수 없기 때문이다. 시간 대비 효과가 가장 큰 순서대로 해결책을 적용해야 한다.

    우선 LCP 줄이기에 집중한다. 주로 메인 배너 이미지나 텍스트 폰트 로딩 문제다. 이미지를 다음 포맷으로 바꾸거나 사이즈를 조절한다. Core Web Vitals 개선은 구글이 직접 평가하는 지표이므로 우선순위가 높다.

    그다음이 자바스크립트 실행 시간 줄이기다. 테마나 플러그인에서 불러오는 JS 파일을 지연 로드하거나 불필요한 것을 제거한다. 마지막으로 서버 사이드 렌더링 최적화를 진행한다. 이 과정에서 속도 측정 도구(PageSpeed Insights, GTmetrix)를 계속 돌려가며 수치 변화를 확인한다. 수정 후에는 반드시 캐시를 비우고 모바일/데스크톱 환경 모두에서 재점검해야 한다. PC에서는 빠른데 모바일에서만 느린 경우가 꽤 많다.

    자동화 운영자가 알려주는 속도 유지 꿀팁

    서버가 터지는 건 대개 예측 가능한 시점에 일어난다. 바로 자동화 배치 작업이 돌아갈 때다. 나는 현재 크론 63개를 무인으로 돌리고 있는데, 이들이 한꺼번에 실행되면 순간적으로 CPU 점유율이 치솟는다. 숨겨진 크론 문제다. 원격 플러그인 업데이트나 글 발행 배치가 돌 때 서버 자원을 갉아먹어 일시적으로 속도가 터질 수 있다.

    이를 막으려면 캐시 플러그인의 갱신 타이밍을 조절해야 한다. 크론 작업이 돌고 난 직후에 캐시를 비우거나, 사용자 접속이 적은 새벽 시간대에 무거운 작업을 몰아넣는 식이다. 캐시 설정이 너무 강력하면 오히려 글이 발행되어도 사용자에게 예전 글이 보이거나, 관리자 페이지에서 충돌이 일어나 수정이 안 되는 경우도 생긴다. 사이트 속도 모니터링 알림을 설정해두고, 알림이 울릴 때마다 어떤 작업이 겹쳤는지 로그를 확인하는 습관이 필요하다.

    마무리: 속도는 단순한 기술 점수가 아니라 비즈니스 문제다

    속도를 높이는 건 귀찮은 작업이다. 코드를 고치고 플러그인을 쑤시고 서버를 들여다봐야 하니까. 하지만 방치하면 트래픽은 고사하고 기존 사용자마저 잃는다. 사용자 경험(UX)을 해치는 느린 사이트는 아무리 좋은 글을 실어도 읽히지 않는다. 지금 당장 측정 도구를 하나 켜고, 내 블로그가 실제로 얼마나 느린지부터 확인해 보자. 개선한 만큼 트래픽이 돌아온다.


    글쓴이 정보

    초안은 AI 파이프라인이 쓰고, 검사를 통과한 글만 공개됩니다. 걸린 초안은 제가 직접 고칩니다. — 아일리고

    자주 나오는 질문

    블로그 속도가 느릴 때 가장 먼저 점검해야 할 곳은?

    이미지보다는 활성화된 플러그인과 외부 스크립트가 주범인 경우가 많습니다. 구글 애드센스나 유튜브 임베드 같은 3자 스크립트가 렌더링을 막고 있는지 먼저 확인하세요.

    페이지 속도 점수는 좋은데 실제 로딩은 느린 이유는?

    서버 응답 시간인 TTFB가 길어서일 가능성이 높습니다. 캐싱만 믿다가 데이터베이스 쿼리가 병목을 일으키고 있는지, 서버 자원을 모니터링해봐야 합니다.

    구글 서치 콘솔 노출이 갑자기 줄어든 이유가 속도인가?

    사용자가 페이지 로딩이 느려져 뒤로 가기를 누르는 이탈 신호를 구글이 포착했기 때문일 수 있습니다. 콘텐츠가 문제가 없다면 속도 저하로 인한 순위 하락을 의심해보세요.

    LCP 점수를 빠르게 올리는 가장 효과적인 방법은?

    메인 배너나 히어로 섹션의 이미지를 최신 포맷으로 변환하고 사이즈를 최적화하는 것이 가장 효과적입니다. 렌더링 차단 리소스를 제거하는 것도 필수적입니다.

    자동화 배치 작업 중 서버가 터지는 걸 막으려면?

    무거운 크론 작업이 사용자 접속이 적은 새벽 시간대에 돌도록 예약하세요. 캐시 갱신 타이밍을 조절해 작업 부하가 겹치지 않게 분산하는 것이 중요합니다.

    속도 최적화는 어떤 순서로 진행해야 효율적인가?

    LCP를 줄여 Core Web Vitals를 먼저 개선하고, 그다음 자바스크립트 실행 시간을 줄이세요. 마지막으로 서버 사이드 렌더링을 최적화하며 수치 변화를 모니터링하는 순서가 좋습니다.


  • wp-config.php 건드리기 전 백업 안 하면 낭패

    wp-config.php 건드리기 전 백업 안 하면 낭패

    wp-config.php 건드리면 사이트 날아갈까요?

    워드프레스 블로그 보안 유지를 위해 wp-config.php 수정 실수를 두려워하는 분이 많다. 파일 하나 잘못 건드리면 화면이 하얗게 변하거나 접속조차 안 되는 경험, 한 번쯤은 겪어봤을 테다. 나도 자동화 SaaS를 운영할 때 코드 한 줄 오타로 cron 63개가 전부 멈춰버린 사례가 있다. 서비스가 마비되니까 당황스럽기 그지없다. 이유는 단순했다. 문법 오류가 발생했는데, 모니터링 시스템이 이를 잡아내지 못한 것이다.

    중요한 건 ‘두려움’이 아니라 ‘복구 전략’이다. 단순히 FTP에 접속해서 파일을 다운로드받는 것만으로는 부족하다. 자동화 운영 환경에서는 백업 파일이 구버전으로 덮어씌워지는 ‘백업 파괴’ 현상이 종종 발생하기 때문이다. 수정 직전의 순수 상태 파일을 로컬이나 별도 원격 스토리지에 분리해서 보관하는 습관이 생명줄이 된다.

    수정 전 백업, 어디서부터 해야 할까요?

    백업이라고 플러그인 백업 기능만 믿으면 안 된다. 플러그인이 돌아가지 않는 상황(WSOD)이 오면 플러그인 백업 자체가 실패했을 수도 있다. 호스팅 관리자 페이지에 들어가서 파일 관리자를 켠다. wp-config.php 백업은 웹 문서 루트 밖이나 접근이 차단된 별도 저장소에 보관하고, 웹에서 요청 가능한 위치에 .bak 파일을 두지 않는다. 이 과정이 수정 사항을 적용하기 전에 필수적으로 거쳐야 할 관문이다. 워드프레스 보안 핵심은 인증 정보를 노출하지 않고, 불필요한 경로를 차단하는 흐름을 만드는 데 있다.

    실수했을 때 대처법: FTP 접속 없이 복구하기

    혹시라도 잘못 수정했다 싶으면 당황하지 말고 브라우저 호스팅 패널의 '파일 관리자'로 바로 들어간다. FTP 클라이언트를 설치할 시간조차 아까울 수 있다. wp-config.php 파일의 마지막 수정 시간을 확인하고, 방금 만든 .bak 파일 내용을 복사해서 붙여넣은 뒤 저장한다. 이 과정을 1분 안에 해결하면 방문자는 사이트 중단을 눈치채지 못한다. SSL 강제 등 보안 코드를 잘못 넣어서 '무한 리다이렉트 루프'에 빠졌을 때도, 파일 관리자로 접속해서 해당 코드 라인만 주석 처리(//) 하면 즉시 해결된다.

    보안 강화를 위해 반드시 수정해야 할 4곳

    복잡한 플러그인 설치 없이 텍스트 편집기로 몇 줄만 바꾸면 보안 효과는 확실해진다. 자동화 파이프라인이 주 1~5편으로 불규칙하게 글을 쓰고, 문체 검사를 통과한 글만 공개되듯, 보안 설정도 일회성이 아니라 주기적인 점검이 필요하다.

    보안 키(Salts) 갱신으로 쿠키 해킹 막기

    WordPress 보안 키와 salt는 인증 쿠키와 nonce의 해시·HMAC을 생성하고 검증하는 데 사용하는 비밀값이다. 이 값이 쉽게 유추되면 해커가 쿠키를 위조하여 관리자 세션을 탈취할 위험이 크다. 기본값으로 둔 채로 쓰는 것은 자물쇠에 '1234'를 다는 것과 같다. 워드프레스 공식 API 키 생성 페이지에 접속해서 뜨는 코드를 그대로 복사해 wp-config.php의 해당 칸에 붙여넣는다.

    
    // 설치 직후 wp-config.php 에는 이렇게 자리표시자만 들어 있다.
    define( 'AUTH_KEY',         'put your unique phrase here' );
    define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );
    define( 'LOGGED_IN_KEY',    'put your unique phrase here' );
    define( 'NONCE_KEY',        'put your unique phrase here' );
    define( 'AUTH_SALT',        'put your unique phrase here' );
    define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
    define( 'LOGGED_IN_SALT',   'put your unique phrase here' );
    define( 'NONCE_SALT',       'put your unique phrase here' );
    

    이 8줄을 통째로 지우고, 공식 생성기
    뱉어낸 8줄을 그대로 붙여넣는다. 값은 매번 새로 만들어지므로 남이 블로그에 적어둔 문자열을 복사해 쓰면 안 된다
    — 공개된 키는 없는 키와 같다. 새로고침할 때마다 다른 값이 나오는 것이 정상이다.

    이 코드를 적용하면 기존에 로그인된 사용자는 다시 로그인해야 한다. 쿠키가 무효화되기 때문이다. 보안 키를 교체하면 기존 로그인 쿠키가 무효화되므로 쿠키 유출이 의심될 때 세션을 강제로 종료하는 데 유용하지만, 다른 공격 경로까지 막지는 않는다.

    디버그 모드 끄고 에러 로그 숨기기

    운영 환경에서는 절대 에러 메시지가 화면에 출력되면 안 된다. PHP 경로나 데이터베이스 구조가 화면에 그대로 노출되면 공격자에게 침투 경로를 알려주는 꼴이 된다. wp-config.php 하단에 있는 디버그 상수를 모두 false로 설정한다.

    
    모든 PHP 코드 예시에서는 곡선 따옴표가 아닌 ASCII 따옴표를 사용한다: `define( 'WP_DEBUG', false );
    define( 'WP_DEBUG_LOG', false );
    define( 'WP_DEBUG_DISPLAY', false );
    

    에러를 확인해야 한다면 서버의 error.log 파일을 직접 까보는 습관을 들이는 게 좋다. 화면에 안 보인다고 해결된 게 아니다. 내부적으로 로그를 쌓으면서 조용히 문제를 해결하는 편이 낫다.

    테이블 접두사 변경 — 효과와 한계

    워드프레스를 설치할 때 기본 테이블 접두사는 wp_다. 새로 설치할 때는 myblog_처럼 예측하기 힘든 접두사를 쓰는 편이 낫다. 자동화된 스캐너가 테이블 이름을 찍어놓고 던지는 공격을 한 겹 걷어내 주기 때문이다.

    다만 이것을 SQL 인젝션 대책으로 이해하면 안 된다. 접두사 변경은 이름을 가리는 것(security through obscurity)일 뿐이고, 인젝션을 실제로 막는 것은 워드프레스가 쿼리를 준비된 문장으로 만들어 주는 $wpdb->prepare()다. 취약한 플러그인이 사용자 입력을 그대로 쿼리에 이어 붙이면 접두사를 뭘로 바꿔놨든 뚫린다. 접두사 변경은 보조 장치이지 방어선이 아니다. 그리고 이미 운영 중인 사이트에서 테이블 이름을 일괄 변경하는 작업은 잘못하면 사이트가 통째로 날아가므로 초보자에게는 추천하지 않는다.

    플러그인 없이 코드로 차단하는 공격 기법

    플러그인은 편하지만, 플러그인 자체의 취약점이 새로운 해킹 루트가 되는 경우도 허다하다. 나는 가능한 코드 레벨에서 직접 차단하는 것을 선호한다. wp-config.phpfunctions.php, 그리고 .htaccess 파일을 조합하면 플러그인 없이도 탄탄한 방벽을 구축할 수 있다. 자동화 LLM을 헤드리스로 부를 때 기본 설정이 1회 $0.67이었는데, 불필요한 도구를 떼어내고 모델을 가벼운 쪽으로 바꿔 $0.0285까지, 약 24배 줄인 경험처럼, 불필요한 요청을 원천 차단하면 리소스 효율도 비약적으로 올라간다.

    XML-RPC 및 REST API 무차별 대공격 막기

    xmlrpc.php는 원격에서 블로그를 관리하기 위한 기능이지만, DDoS 공격이나 무차별 대공격(Brute Force)에 악용되는 주요 타겟이다. xmlrpc_enabled` 필터는 인증이 필요한 XML-RPC 메서드만 끄며, XML-RPC 요청 전체를 차단하려면 웹 서버나 WAF 설정 또는 메서드별 필터가 추가로 필요하다. functions.php에 아래 코드를 추가한다.

    
    add_filter('xmlrpc_enabled', '__return_false');
    

    REST API 역시 불필요한 외부 호출을 막아야 한다. 다만, 내가 만든 SaaS처럼 외부 서비스와 연동이 필요한 경우 API를 완전히 막으면 서비스가 멈춘다. 이럴 땐 특정 IP나 인증된 사용자에게만 접근을 허용하는 예외 처리를 필수적으로 넣어야 한다. 허용 IP를 설정하는 경험을 통해, 보안 설정과 기능 동작의 균형을 맞추는 법을 터득했다.

    파일 직접 접근 차단 (Disable File Editing)

    워드프레스 관리자 화면에서 테마나 플러그인의 코드를 직접 수정할 수 있는 기능이 있다. 편하지만 해커가 관리자 권한을 탈취했을 때 악성 코드를 심는 가장 쉬운 방법이기도 하다. wp-config.php에 이 코드를 한 줄 추가하면 관리자 화면에서 더 이상 파일 편집이 불가능해진다.

    
    define( 'DISALLOW_FILE_EDIT', true );
    

    이 설정은 코드 수정은 무조건 FTP나 파일 관리자로 하게 만든다는 뜻이다. 귀찮아진다고 생각할 수 있지만, DISALLOW_FILE_EDIT`는 관리자 화면의 파일 편집 경로 하나를 제거하지만, 관리자 계정 탈취 후의 모든 코드 변경을 막는 설정은 아니다.

    외부 API 호출과 보안 설정의 충돌 해결법

    보안 코드를 넣다 보면 의도치 않게 정상적인 기능이 막히는 수가 있다. 예를 들어, SSL 강제 리다이렉트를 걸었는데 특정 결제 모듈이 비보안 콜백을 요구하면 결제가 실패한다. 이럴 때는 .htaccess 파일에서 특정 경로만 SSL 예외로 두는 세심한 설정이 필요하다. 보안이 중요하지만, 사이트가 기능을 못 하면 존재 의의가 사라진다. 문제가 생겼을 때는 즉시 방금 수정한 설정을 주석 처리하고, 접속 로그를 확인해서 어떤 요청이 막혔는지 파악해야 한다.

    코드로 공격 차단하기

    잘못 수정했을 때 사이트가 멈추면 복구하는 절차

    아무리 조심해도 실수는 하기 마련이다. 내가 운영하는 시스템도 문법 오류가 나면 알림을 보내는 모니터링을 돌리고 있다. 문제는 화면이 하얗게 나오는 WSOD(White Screen of Death) 상황이 언제 터질지 모른다는 점이다.

    화면이 하얗게 나올 때(WSOD) 원인 파악

    WSOD는 대부분 PHP 메모리 부족이나 문법 오류 때문에 발생한다. wp-config.php를 수정한 직후에 이 화면이 떴다면 문법 오류부터 의심하는 게 순서다. 누락된 세미콜론(;)이나 따옴표 짝이 안 맞는지 의심해야 한다. 에러 로그를 볼 수 없다면, 해당 파일 수정 내용을 하나씩 지워가면서(혹은 주석 처리하면서) 어디서 문제가 터지는지 확인한다.

    문법 오류(Syntax Error) 발생 시 수정법

    브라우저 화면에 "Parse error: syntax error" 같은 메시지가 뜬다면 다행이다. 몇 번째 줄에서 무엇이 잘못됐는지 알려주기 때문이다. FTP 대신 파일 관리자로 접속해서 해당 라인으로 이동해 수정한다. 만약 수정 사항이 기억나지 않는다면, 처음에 백업해 둔 .bak 파일로 덮어씌우는 것이 정신 건강에 이롭다. 자존심 세울 때가 아니다.

    백업 파일로 원복하는 마지막 단계

    사이트가 죽었을 때 급하게 복구하다 보면, 오류가 난 파일을 또 백업해버리는 실수를 저지르기 쉽다. 그러면 깨끗한 원본이 사라진다. 반드시 수정 전 상태로 돌아갈 때는 덮어쓰기 말고, 기존 파일을 이름을 바꿔서(wp-config.php.error) 보관해 두고 백업 파일을 가져온다. 그래야 다시 원인을 분석할 여지가 남는다.

    마무리: 안전한 보안 설정을 위한 체크리스트

    지금까지 wp-config.php 수정 실수 없이 보안을 강화하는 방법을 정리했다. 코드 한 줄이 사이트의 운명을 가르기도 한다. 나는 모든 수정 후에 사람이 직접 검토하는 '수동 검수 게이트'를 두고 있다. 자동화가 아무리 편해도, 결국 최종 책임은 사람이 져야 한다. SEO 플러그인으로 변경 사항을 함께 검증하는 것도 좋지만, 기본적으로 파일을 건드리기 전 백업을 확인하는 습관이 그 어떤 도구보다 강력하다.

    • 파일 수정 전 .bak 파일 생성 여부 확인
    • 수정 코드의 문법(Syntax) 체크
    • 사이트 접속 및 관리자 페이지 로그인 테스트
    • 외부 API 연동 서비스 정상 작동 여부 확인

    이 과정을 하나씩 거치면 해킹도 두렵지 않다. 너무 조급하게 하지 마라. 천천히, 그리고 확실하게 적용하는 게 빠른 길이다.

    참고한 공식 문서


    글쓴이 정보

    제가 만든 AI 파이프라인이 초안을 쓰고, 저는 검사에 걸린 것만 손봅니다. 통과하지 못한 초안은 그냥 버립니다. 파이프라인은 여기에 정리해 두었습니다.

  • 방치하면 트래픽 잃는 속도 저하 원인

    방치하면 트래픽 잃는 속도 저하 원인

    트래픽이 줄어드는 진짜 신호, 워드프레스 속도 저하

    방치했던 워드프레스 사이트가 어느 날 갑자기 트래픽이 끊기듯 줄어들 때가 있다. 대책 없이 내버려 두면 서버 응답 시간(TTFB)이 길어지고 구글 검색 결과에서도 순식간에 밀려난다. 내가 직접 자동화 SaaS를 운영하며 겪었던 일인데, 급격한 일일 방문자수 하락을 확인하고 서버 로그를 뒤져보니 원인은 단순했다. 복구하느라 반나절을 꼬박 쓴 적이 있다. 워드프레스 속도 저하는 단순히 사용자가 불편을 느끼는 문제를 넘어, 검색 엔진이 사이트를 신뢰하는지를 판단하는 잣대가 된다.

    속도 문제를 감지하려면 감에 의존하지 말고 지표를 봐야 한다. 구글 페이지 스피드 인사이트 점수가 좋지 않거나, LCP(최대 콘텐츠 페인트) 수치가 2.5초를 넘어간다면 이미 경고 신호다. 모바일 환경에서의 트래픽 감소 원인을 찾을 때는 특히 더 이 수치들을 믿고 수술에 들어가는 게 맞다.

    방치했던 사이트, 어느 날 갑자기 트래픽이 끊긴 이유

    자동화로 운영되는 사이트는 관리자가 매일 들르지 않기 때문에 문제가 터지고 나서야 알게 되는 경우가 많다. 내 블로그를 포함해 여러 사이트를 모니터링하던 중, 한동안 꾸준히 들어오던 검색 유입이 바닥을 치는 날이 있었다. 확인해 보니 워드프레스 코어와 플러그인 업데이트가 쌓이면서 리소스 사용량이 폭발해 쿼리가 멈춰 있었다. 방치가 얼마나 치명적인지 실감했다.

    내 사이트 속도가 느린지 확인하는 필수 지표 3가지

    워드프레스 속도 측정은 도구 하나만 믿으면 안 된다. PageSpeed Insights와 웹마스터 도구의 실제 사용자 데이터(CrUX)를 같이 봐야 한다. 특히 TTFB, LCP, CLS 이 세 가지는 기본으로 체크해야 한다. 도구 점수만 믿으면 안 된다. 수치가 좋아 보여도 실제 사용자가 느끼는 체감 속도와 다를 수 있기 때문에, 직접 모바일로 접속해 로딩 바가 얼마나 걸리는지 세는 것도 중요하다.

    속도를 죽이는 3대 주범: 이미지, 플러그인, 그리고 호스팅

    솔직히 워드프레스가 느려지는 이유는 뻔하다. 이미지, 플러그인, 호스팅 환경 이 3가지가 압도적으로 크다. 그럼 어디부터 손대야 하나. 하지만 단순히 “이미지가 무겁다”라고 말하는 건 의미가 없다. 기술적으로 어떤 메커니즘으로 속도를 잡아먹는지 이해해야 해결책이 보인다. 1인 빌더로서 여러 플러그인을 섞어 쓰다가 서버가 다운되었던 실패 사례는 이 원인들을 명확히 보여준다.

    용량은 줄었는데 여전히 느린 ‘플러그인 과부하’의 함정

    플러그인은 개수만 문제가 아니다. 활성화된 플러그인 하나하나가 훅(Hook)을 걸어 매 페이지 로딩마다 코드를 실행하기 때문이다. 예전에 기능이 겹치는 SEO 플러그인 두 개를 동시에 켜두었다가 사이트가 먹통이 된 적이 있다. 불필요한 기능이 쌓이면 캐싱을 해도 소용이 없다. 웹 호스팅 속도가 아무리 좋아도 플러그인이 내는 쿼리를 감당하지 못한다면 느릴 수밖에 없다.

    저렴한 호스팅이 불러오는 ‘데이터베이스 병목’ 현상

    저렴한 공유 호스팅을 쓸 때 발생하는 가장 큰 문제는 데이터베이스 병목이다. CPU나 메모리 제한에 걸리면 쿼리가 대기열에 쌓이고, 이는 곧 바로 로딩 속도 저하로 이어진다. 나는 크론 잡을 이용해 콘텐츠를 발행할 때, 데이터베이스 트랜잭션이 몰리는 시간대에 서버 응답 시간이 눈에 띄게 늘어나는 것을 목격했다. 찰나의 순간에 쌓이는 요청을 처리하지 못하면 502 에러를 뱉기도 한다.

    압축되지 않은 이미지가 렌더링을 막는 순간

    이미지 최적화 방법을 모르는 사이트는 로딩의 절반을 이미지 렌더링에 잡아먹는다. 단순히 용량을 줄이는 것(WebP 변환)만으로는 부족하고, 레이아웃 이동(CLS)을 막기 위해 width와 height 속성을 명시해야 한다. 압축되지 않은 고해상도 이미지가 브라우저가 그려지는 순간을 막고 있으면, 아무리 HTML이 가볍게 짜여 있어도 사용자는 느린 사이트라고 느낀다.

    1인 사업자가 지켜야 할 플러그인 개수와 관리법

    그렇다면 도대체 플러그인은 몇 개까지 써야 안전한가. 인터넷에 떠도는 “무조건 10개 이하” 같은 말은 믿지 않는다. 사이트의 트래픽과 호스팅 사양에 따라 달라지기 때문이다. 내가 운영하는 SaaS 사이트들을 기준으로 삼으면, 실제로는 활성 플러그인 수가 중요한 게 아니라 ‘양질의 플러그인’인지가 핵심이다.

    성능에 지장 없는 적정 플러그인 개수는 몇 개인가?

    경험상 워드프레스 필수 플러그인이라 불리는 것들 외에 추가 기능은 최소한으로 줄이는 게 맞다. 나는 현재 운영 중인 메인 사이트에서 보안, 백업, SEO 기본 기능을 포함해 10개 내외로 유지한다. 이 숫자를 넘어가면 플러그인 충돌 해결하느라 소모되는 시간이 늘어난다. 가볍고 잘 만들어진 플러그인 하나가 무거운 것 세 개보다 낫다.

    기능이 겹치는 플러그인 찾아내고 제거하는 법

    설치된 플러그인 리스트를 보고 기능이 겹치는 부분이 없는지 점검해야 한다. 예를 들어, 페이지 빌더 테마 안에 SEO 설정 기능이 있는데 별도의 SEO 플러그인을 또 켜두는 경우다. Query Monitor 같은 도구를 쓰면 어떤 플러그인이 쿼리를 많이 날리는지 확인할 수 있다. 무료 최적화 도구로도 충분히 찾아낼 수 있으니 방치하지 말고 주기적으로 청소해야 한다.

    무료 플러그인만으로 최적화할 수 있는 한계점

    무료 플러그인만으로 모든 것을 해결하려다 보면 한계에 부딪힌다. 개수만 늘리는 방식은 안 통한다. 특히 이미지 서빙이나 고급 캐싱 기능은 유료 버전에서만 제대로 작동하는 경우가 많다. 그렇다고 무조건 돈을 쓰자는 건 아니다. 무료 티어로 가능한 범위를 최대한 끌어올린 뒤, 그래도 부족할 때 코드 레벨의 개입으로 해결하는 게 1인 개발자의 현실적인 접근법이다.

    불필요한 플러그인 정리 작업

    플러그인 없이 무료로 적용하는 핵심 최적화 전략

    플러그인을 계속 추가하는 건 방법이 아니다. 결국 코드 레벨로 건드리는 게 가장 확실하다. 나는 플러그인 충돌 없이 순수 코드나 테마 함수(functions.php)를 수정해 비용 0원으로 스크립트 최적화를 진행한다. 방법이 딱히 어렵지 않다. Core Web Vitals 점수를 올리기 위해 직접 손을 대보자.

    Core Web Vitals 점수를 빠르게 올리는 렌더링 차단 해제

    LCP 줄이기 방법 중 가장 효과적인 건 렌더링을 차단하는 자바스크립트와 CSS를 제거하는 것이다. 스크립트를 푸터로 옮기려면 wp_enqueue_script()in_footer를 쓰고, 지연 실행이 필요하면 의존성을 고려해 strategy => 'defer'를 별도로 지정한다. 다만 이 방법은 내가 등록한 스크립트에만 통한다. 테마나 플러그인이 넣은 스크립트는 등록 인자를 내가 못 건드리므로, 출력되는 태그를 가로채 defer를 붙이는 아래 방식을 쓴다. 이 코드는 푸터로 옮기는 것이 아니라 실행을 뒤로 미루는 것이다.

    
    // 테마의 functions.php에 추가하는 예시 코드
    function defer_parsing_of_js( $url ) {
      if ( is_user_logged_in() ) return $url; // 관리자는 적용 제외
      if ( FALSE === strpos( $url, '.js' ) ) return $url;
      if ( strpos( $url, 'jquery.js' ) ) return $url;
      return str_replace( ' src', ' defer src', $url );
    }
    add_filter( 'script_loader_tag', 'defer_parsing_of_js', 10 );
    

    이미지 캐싱과 로딩 우선순위 설정 방법(Lazy Load)

    캐싱 설정 방법을 모른다면 이미지를 아무리 압축해도 어차피 느리다. 브라우저 캐싱 만료 기간을 설정하고, 화면에 보이지 않는 이미지는 로딩하지 않는 Lazy Load를 적용해야 한다. 요즘은 워드프레스 코어에 네이티브 Lazy Load가 포함되어 있지만, 세밀한 제어를 위해서는 속성을 추가해 주는 게 좋다. ‘loading=”lazy”‘ 속성을 자동으로 주입하는 코드는 이미지 로딩 순서를 조절해 체감 속도를 크게 개선한다.

    필수 코드만 남기고 CSS/JS를 최소화하는 팁

    크론 발행 자체는 스크립트 로딩 순서를 바꾸지 않으며, 순서 문제가 있다면 테마·플러그인의 enqueue 의존성과 발행 훅에서 실행되는 코드를 점검해야 한다. 나는 사용하는 페이지에서만 호출되도록 스크립트를 조건부 로드(Conditional Loading) 한다. 모든 페이지에 구글 폰트나 외부 라이브러리를 싹 다 로드하는 습관을 버리고, 특정 페이지 ID에서만 작동하게 코드를 좁히는 것이다. 플러그인 충돌을 걱정할 필요 없이 서버 응답 시간을 단축하는 가장 강력한 무료 방법이다.

    자동화된 워드프레스 관리를 위한 순환 고리

    1인 개발자가 매일 사이트를 들여다보며 확인할 수는 없다. 그렇기 때문에 시스템을 믿고 운영할 수밖에 없다. 내가 현재 cron 63개를 돌리며 자동화 SaaS를 운영하는 방식은 워드프레스 관리도 예외가 아니다. 정기적인 데이터베이스 정리와 로그 모니터링은 손으로 하는 게 아니라 스크립트가 대신한다.

    정기적인 데이터베이스 정리와 로그 모니터링 습관

    시간이 지나면 워드프레스 데이터베이스에 쓰레기 데이터(Revision, 스팸 댓글 등)가 쌓인다. 이걸 주기적으로 비워주지 않으면 쿼리가 느려진다. 나는 매주 자동으로 DB 최적화 명령을 실행하도록 세팅해 뒀다. 사람이 매일 확인할 수 없기 때문에 시스템(Cron)을 활용해 정리하는 아일리고만의 운영 방식이라고 할 수 있다. 로그를 보다가 이상치가 잡히면 알림이 오게 만들어두면 된다.

    테마와 플러그인 업데이트 전 점검 리스트

    자동화가 편하지만, 업데이트는 조심해야 한다. 업데이트가 충돌을 일으켜 사이트를 죽이는 경우도 있으니까. 나는 테마와 플러그인 업데이트 전 항상 백업이 완료되었는지 확인한다. 그리고 메인 사이트가 아니면 테스트 환경에서 먼저 돌려본다. 이 순서를 지키지 않아 몇 번이나 긴급 복구를 했었는지 모른다.

    SEO와 속도 모두 잡는 메타데이터 자동화의 필요성

    속도만 빠르다고 끝이 아니다. SEO와 속도 모두 잡아야 트래픽이 유지된다. 글을 발행할 때마다 메타 데이터를 수동으로 입력하는 건 비효율적이다. 자동화된 파이프라인이 초안을 만들 때 메타 태그도 함께 세팅하도록 구성해야 한다. 속도 최적화는 기본이고, 그 위에 SEO 요소가 자동으로 씌워져야 1인 사업자가 버틸 수 있다.

    요약: 지금 당장 점검해야 할 속도 체크리스트

    마지막으로 지금 당장 서버에 접속해서 확인해 봐야 할 항목들을 정리한다. 그냥 오늘 해도 늦지 않다.

    • LCP는 75백분위에서 2.5초 이하를 목표로 하고, TTFB는 별도 진단 지표로서 대략 0.8초 이하를 목표로 점검한다.
    • 사용하지 않는 플러그인 비활성화 및 삭제 (비활성만으로도 리소스는 먹는다)
    • 이미지 파일 포맷 WebP로 변환 및 width/height 속성 값 확인
    • 데이터베이스 쓰레기 데이터(수정 이력 등) 수동 삭제 또는 플러그인 최적화 실행
    • 테마의 functions.php 파일에서 불필요한 스크립트 로드 제거 코드 추가

    이 정도만 점검해도 사이트 속도는 눈에 띄게 빨라진다. 방치는 곧 비용이다. 오늘 확인하지 않으면 내일 트래픽은 그대로 사라진다.

    참고한 공식 문서


    글쓴이 정보

    여기 올라오는 글의 초안은 운영자가 만든 AI 파이프라인이 자동으로 만듭니다. 다만 문체·사실성 검사를 통과하지 못한 초안은 공개되지 않고 사람이 손봅니다. 그 과정은 포트폴리오에서 볼 수 있습니다.

  • 블로그 수익 없다면 이것부터 점검하세요

    블로그 수익 없다면 이것부터 점검하세요

    올해 8월 초, 9일 동안 블로그 발행이 멈춰 있었음에도 알림이 단 한 건도 오지 않은 적이 있다. 파이프라인 코드 한 줄에 결함이 있었는데, 실패 알림 코드가 크래시 지점보다 뒤에 위치해 있어 시스템이 조용히 죽어버렸기 때문이다. 이때 깨달았지만 방문자가 꾸준히 들어오는데 수익 그래프만 바닥을 기는 상황도 비슷하다. 수익이 안 나는 걸 운이나 시장 탓으로 돌리기 전에, 데이터가 눈에 보이지 않게 샜거나 기술적으로 막힌 지점을 먼저 찾아야 한다.

    이 블로그의 구글 서치콘솔 28일 노출·클릭 실측 비교
    운영 중인 이 블로그의 서치콘솔 실측치다. 개설 5주차 기준 직전 측정 대비 노출 169→382, 클릭 9→12 — 신생 블로그의 수익은 이 구간에서는 트래픽 절대량이 아니라 추세로 판단해야 한다.

    방문자가 있는데 수익이 0원인 기술적 원인 3가지

    방문자 수는 오르는데 수익 그래프만 바닥을 기는 걸 보면 참 답답하다. 구글 애널리틱스에 유입은 찍히는데 지갑은 열리지 않는 상황, 여기엔 뻔한 이유 말고 기술적인 함정이 숨어 있을 확률이 높다. 가장 먼저 의심해 봐야 할 건 키워드의 성격이다.

    자동화는 감시를 밖에 두면 조용히 죽는다는 사실을 뼈저리게 느꼈다. 예외 처리 코드 결함으로 9일간 발행이 멈췄는데도 실패 알림이 한 건도 오지 않았던 사례처럼, 블로그 운영에서도 수익 파이프라인이 끊겨도 시각화된 지표가 없으면 모르고 지나가기 십상이다. 방문자는 들어오는데 수익이 쌓이지 않는다면, 알림이 울리지 않는 채 죽어가는 내 코드처럼 어딘가에서 기술적인 연결이 끊어져 있을 가능성을 의심해야 한다.

    사람들이 글을 보러 오는 이유가 ‘정보 확인’인지 ‘구매’인지 파악하지 못하면 RPM(방문자당 수익)은 바닥을 친다. 단순히 무언가를 검색해서 뜻을 알아보려는 ‘조회성 키워드’로만 채워진 블로그는 방문자가 아무리 많아도 광고 단가가 낮을 수밖에 없다. 반대로 ‘가격 비교’, ‘후기’, ‘추천’ 같은 구매 전환 의도가 섞인 키워드가 섞여 있어야 수익성이 개선된다.

    기술적인 측면에서 모바일 환경을 점검해 보자. 내가 만든 SaaS 랜딩 페이지를 분석할 때, 모바일 유입 대비 광고 노출이 의도치 않게 막혀 있던 사례가 있다. 뷰포트 설정이 잘못되어 광고 스크립트가 화면 밖으로 밀려나면서 아예 로딩조차 안 되는 경우가 있었다. 테마나 플러그인 업데이트 후 레이아웃이 깨지면 광고 영역이 텍스트에 덮이거나 사라지는데, 이건 PC 화면에서는 절대 못 잡는다. 모바일 기기로 직접 글을 읽어보면서 광고가 정상 자리에 있는지 확인해야 한다.

    애드센스 자체의 정책 위반도 원인이다. 일명 ‘애드센스 광고 제한(Ad Limiting)’이 걸리면 구글이 광고 노출을 인위적으로 줄여버린다. AdSense의 계정 수준 광고 게재 제한은 주로 트래픽 평가나 무효 트래픽 우려와 관련되며, 콘텐츠 정책 위반에 따른 제한·중지와는 구분해야 한다. 광고 게재 제한이나 정책 문제는 AdSense의 ‘정책 센터’에서 확인한다.

    애드센스 승인 거절과 해지의 흔한 실수들

    블로그를 처음 개설하거나 재개설할 때 애드센스 승인 메일을 보고 좌절하는 경우가 많다. 대부분은 ‘콘텐츠 부족’이라고 적혀 있지만, 실제로는 더 구체적인 실수 때문일 때가 많다. 가장 흔한 게 저작권 무단 배제다. 이미지는 라이선스가 허용하는 범위에서 사용하고, 해당 라이선스가 요구할 때 출처·저작자·라이선스를 표시해야 한다.

    또 하나, 광고를 클릭하게 만들려는 시도는 의외로 쉽게 걸린다. 광고 위에 “클릭해주세요”라는 문구를 넣거나, 광고와 콘텐츠의 구분이 모호하게 배치하면 정책 위반이다. 구글의 알고리즘은 사용자가 실수로 클릭했는지, 의도했는지를 꽤 정교하게 판단한다.

    최근 큰 이슈는 AI 콘텐츠다. AI로 글을 쓰는 건 나쁘지 않지만, 검수 과정 없이 대량으로 발행하면 계정 정지 위험이 급격히 높아진다. 자동화 파이프라인을 구축할 때, AI가 생성한 글의 출처 표기를 누락하여 경고를 받았던 러닝커브가 있다. 구글은 원본 출처가 없는 AI 글을 스팸으로 간주할 가능성이 크다. AI가 쓴 글이라도 사람이 팩트를 체크하고 출처를 덧붙이는 과정은 빼면 안 된다.

    AI 글로 수익을 못 내는 결정적인 품질 차이

    AI 글은 효율적이지만, 방치하면 수익을 못 내는 가장 큰 적이 된다. 문제는 ‘정확성’과 ‘신뢰’다. AI는 가끔 터무니없는 정보를 사실인 것처럼 섞어놓는데, 이른바 환각(Hallucination) 현상이다. 독자가 이걸 알아채고 뒤도 돌아보지 않으면 체류 시간은 뚝 떨어지고 수익은 0원이다.

    E-E-A-T는 경험, 전문성, 권위성, 신뢰성을 뜻하며, Google은 이 가운데 신뢰성을 특히 중요하게 본다. AI가 쓴 글은 정보가 나열되어 있을 뿐, 글쓴이의 목소리가 없다. “나는 이걸 써봤는데 이랬다” 같은 개인적인 경험과 인사이트가 빠지면 그 글은 인터넷에 널린 수만 개의 복사본과 다를 바 없다. 검색 사용자는 누군가의 실제 경험을 담은 글에서 더 머무르고 클릭한다.

    실제로 크론으로 돌아가는 자동화 시스템을 통해 비교해 봤다. 사람이 검토 단계를 거치지 않은 AI 원문과, 제 앞에서 한 번씩 훑고 수정한 글의 체류 시간 차이는 확연했다. 검수 없는 글은 읽다 말고 이탈하는 패턴이 뚜렷했다. AI를 보조 도구로 쓰되, 서문과 결론과 예시는 사람 손이 닿아야 수익 낼 품질이 나온다. 이 단계를 건너뛰면 글자 수만 늘어난다. 물량으로 밀어붙이는 방식은 안 통한다.

    SEO 구조 점검하는 모습

    노출이 전혀 안 되는 글의 SEO 구조 문제점

    아무리 좋은 글을 써도 검색 엔진이 읽지 못하면 소용없다. SEO 구조가 기술적으로 망가진 경우다. 대표적인 게 메타 태그와 스키마 마크업의 부재다. Google은 본문과 페이지 구조로도 주제를 파악하며, 메타 설명은 검색 스니펫을 보조하고 구조화 데이터는 특정 리치 결과 자격을 얻는 데 사용된다.

    SaaS 개발 당시, 다수의 블로그에서 발견한 가장 흔한 실수가 메타 디스크립션 미설정이었다. 이걸 제대로 채우기만 해도 노출 효과가 개선되는 걸 여러 번 확인했다. 제목(H1)에는 검색 키워드가 들어가 있어야 하고, 본문의 소제목(H2, H3)이 그 주제를 뒷받침하는 구조여야 한다. 헤드라인과 내용이 따로 노는 글은 검색 의도를 만족시켰다고 판단받지 못한다.

    가독성 문제도 심각하다. 깨알 같은 글씨로 줄글이 빽빽하게 들어찬 문단은 모바일에서 읽기가 고통스럽다. 높은 이탈률만으로 검색 만족도나 순위 하락을 단정할 수 없으므로, 체류·전환·검색 성과와 함께 해석해야 한다.이를 “콘텐츠가 도움이 안 되었다”고 해석한다. 적절한 단락 나눔과 불렛 포인트 사용은 선택이 아니다.

    수익 발생까지 필요한 글의 개수와 속도

    그럼 과연 글을 얼마나 써야 수익이 나올까. 솔직히 정해진 개수는 없다. 대신 전략이 있다. 그냥 아무 키워드나 막 쓰는 게 아니라, 특정 주제를 파고드는 ‘클러스터 콘텐츠’ 전략이 필요하다. 키워드 그룹을 묶어서 밀어주었을 때 검색 상승폭이 확실히 컸다. 서로 연관된 글들이 링크로 엮이면서 주제 권위를 인정받기 때문이다.

    초기 수익 발생까지는 꽤 긴 시간이 걸린다. 기대하기 시작하고 3~6개월은 묵묵히 써야 하는 구간이다. 단, 아무렇게나 쓰는 게 아니라 일관성 있는 발행 주기(Cadence)를 지키는 게 중요하다. 이 블로그처럼 자동화 시스템의 도움을 받아 주 3편씩 꾸준히 채워 넣는다면, 어느 순간 시스템이 굴러가기 시작하는 지점을 마주하게 된다.

    요약: 오늘 당장 블로그에서 수정할 것

    방문자가 꾸준히 유입되고 있음에도 수익이 0원이라면, 지금 당장 애드센스 센터의 ‘수익 최적화’ 탭에 들어가 광고 제한(Ad Limiting)이 걸려 있는지부터 확인하라.

    근거로 삼은 문서


    글쓴이 정보

    여기 올라오는 글의 초안은 운영자가 만든 AI 파이프라인이 자동으로 만듭니다. 다만 문체·사실성 검사를 통과하지 못한 초안은 공개되지 않고 사람이 손봅니다. 그 과정은 포트폴리오에서 볼 수 있습니다.

    자주 나오는 질문

    방문자가 있는데 블로그 수익이 0원인 이유는 뭔가요?

    조회성 키워드는 구매 의도가 높은 키워드보다 RPM이 낮을 수 있지만, 광고 노출과 유효 클릭이 있다면 수익은 발생할 수 있다. 또는 모바일 화면에서 광고가 레이아웃 깨짐 때문에 아예 보이지 않거나, 애드센스 정책 위반으로 광고 노출이 제한된 상태일 수 있습니다.

    애드센스 승인이 거절되는 가장 흔한 실수는 무엇인가요?

    이미지 출처를 명확히 기재하지 않은 저작권 위반이 가장 흔합니다. 구글은 광고와 콘텐츠를 구분하지 못하게 배치하거나, 검수 없는 AI 콘텐츠를 대량으로 발행하는 경우에도 승인을 거절합니다.

    수익을 내려면 글을 얼마나 많이 써야 하나요?

    정해진 개수보다는 특정 주제를 파고드는 클러스터 전략이 중요합니다. 수익 발생까지는 보통 3~6개월이 걸리며, 이 기간 동안 일관된 발행 주기를 유지하며 글을 채워 넣어야 합니다.

  • 쇼핑몰 자동화 프로그램, 수수료 대비 효율 따져보기

    쇼핑몰 자동화 프로그램, 수수료 대비 효율 따져보기

    스마트스토어 판매자 대시보드를 확인하는 것이 하루 일과의 시작이라면, 이미 당신은 자동화 툴을 찾고 있는 상태다. 주문 들어온 건 송장 번호를 따서 입력하고 엑셀로 정리한 뒤 고객에게 문자를 보내는 일이 반복되면 어느 순간 셀러온 같은 툴이 유혹처럼 다가온다. 문제는 이런 툴들이 월 5만 원에서 10만 원대의 고정 비용을 가져간다는 점이다. 하루 5건을 팔아 순익이 3만 원인데 월 5만 원을 낸다면 장사가 아니라 기부나 다름없다.

    하루 주문 5건인데 셀러온 월 5만 원? 비효율의 시작입니다

    스마트스토어 판매자 대시보드 들어가는 게 하루 일과의 시작이라면, 이미 당신은 자동화 툴을 찾고 있는 상태다. 주문 들어온 건 송장 번호 따서 입력하고, 엑셀로 정리하고, 고객에게 문자 보내는 이 과무하(?)한 업무가 쌓이면 어느 순간 셀러온 같은 툴이 유혹처럼 다가온다. 문제는 이런 툴들이 월 5만 원에서 10만 원대의 고정 비용을 가져간다는 것이다. 하루 5건 팔아서 순익이 3만 원인데 월 5만 원을 내면, 장사는 아니고 기부나 다름없다.

    나도 1인 빌더로 여러 서비스를 돌리면서 비슷한 함정에 빠진 적 있다. 초기에는 팀즈, 슬랙, 프로젝트 관리 툴에 월 100만 원 가까이 쓰는데 관리 비용이 그득했다. 서비스 하나하나가 수익을 내기도 전에 고정 지출이 먼저 발생하니 버티기 힘들더라. 결국은 필요 없는 구독을 과감하게 끊고 엑셀과 구글 스프레드시트로 돌아왔다. 이게 자영업자와 1인 창업가의 맨 처음 생존 전략이다.

    숫자로 계산해보자. 현재 시간당 최저임금을 10,000원으로 잡는다. 주문 건당 배송 입력과 문자 발송에 3분이 걸린다. 하루 10건이면 30분, 월 20일 일하면 10시간이다. 시간으로 환산하면 월 10만 원어치의 노동이다. 셀러온 같은 툴 월 비용이 5만 원이라면 아직 근소하게 이득일 수 있다. 다만 주문이 월 30건 미만이라면? 수수료보다 내 노동 시간 값이 더 싼 셈이다. 이때는 유료 툴이 득이 아니라 ‘비용’이 된다.

    자영업자가 스마트스토어 자동화 툴을 검색하는 순간

    구글에 “스마트스토어 자동화”를 치는 순간부터 심리가 변한다. 이것만 쓰면 내가 쇼핑몰 사장님이 될 것 같은 착각이 든다. 다만 도구는 업무량이 일정 수준 이상일 때만 툴로서 기능한다. 그 아래에서는 그저 ‘복잡한 장난감’일 뿐이다.

    수수료 vs 시간: 지금 내 상황에서 손해인지 계산하는 법

    내 노동 시간 1시간의 가치를 1만 원으로 잡을지, 5만 원으로 잡을지는 본인 몫이다. 다만 초기 자영업자라면 대부분 시간이 돈보다 널널한 경우가 많다. 이때는 돈을 아껴서 내 손으로 움직이는 게 맞다. 월 주문 30건이 넘어가고, 하루 2시간 이상을 배송 입력에 쏟는다면 그때 비로소 툴을 도입할 타이밍이다.

    셀러온을 써야 할까, 아니면 엑셀이나 기본 기능으로 충분할까?

    경계를 명확히 해야 한다. 모든 자동화가 좋은 것은 아니다. 내가 운영하던 블로그 자동화 공장도 처음부터 완벽하지 않았다. 크론 잡으로 유튜브 쇼츠를 돌릴 때, API 연동이 꼬여서 퀄리티 낮은 영상이 계속 올라가서 한동안 구독자들한테 욕 먹었다. 그때 깨달았다. 자동화는 ‘통제 가능한 상황’에서만 효율이다. 통제 불가능한 상황, 즉 주문량이 적고 변동폭이 클 때는 수동이 빠르고 안전하다.

    자동화 파이프라인을 직접 다수 운영하면서 겪은 장애가 시사하는 바가 크다. 2026년 8월 초, 발행 파이프라인이 예외 처리 코드 한 줄 결함으로 9일간 멈췄는데 실패 알림 코드가 크래시 지점 뒤에 있어 알림이 한 건도 오지 않았던 사례가 있다. 자동화는 감시를 밖에 두지 않으면 조용히 죽기 때문에, 주문량이 적을 때는 오류를 즉시 확인하고 수정할 수 있는 수동 관리가 훨씬 안전하다.

    엑셀과 셀러온의 차이는 단순히 편리함의 문제가 아니다. ‘관리 사이즈’의 문제다. 상품이 10개 정도고 주문도 툭툭 들어온다면 굳이 ERP를 연동할 필요가 없다. 반대로 상품 100개가 넘고 재고 연동이 실시간으로 필요하다면 이제 엑셀로는 버거워진다. 사람이 직접 송장을 찍어 넣다 보면 누락이 생기고, 그게 바로 “배송 늦어짐”이라는 평점으로 돌아온다.

    구분 엑셀/수기 (월 주문 30건 미만) 셀러온/유료 툴 (월 주문 100건 이상)
    비용 0원 (엑셀 구독료 제외) 월 5만 원 ~ 10만 원
    배송 입력 건당 1~2분 (복사/붙여넣기) 자동 연동 (초 단위)
    오류 관리 즉시 사람이 확인 및 수정 API 오류 시 미처리 건 발생 가능
    학습 곡선 낮음 (엑셀 기본 기능) 높음 (툴 세팅 및 연동 학습 필요)

    엑셀 자동화로 해결되는 영역: 배송 입력, 주문 확인

    엑셀의 파워(Query, Power Query)를 믿어보자. 스마트스토어 엑셀 다운로드 기능을 쓰면 주문 내역을 긁어올 수 있다. 여기에 vlookup 함수 하나만 잘 써도 송장 번호 매칭은 끝난다. 코드를 짤 필요도 없다. 그냥 엑셀 기능만 써도 반복 업무의 80%는 줄어든다.

    셀러온은 주문·송장 통합관리 도구가 아니라 경쟁 상품의 가격을 추적해 판매가를 자동 조정하는 최저가 경쟁 솔루션이므로, 주문 처리 효율을 분석하려면 별도의 통합 주문관리 서비스와 비교해야 합니다.

    주문량이 일일 50건을 넘어가면 엑셀 파일을 열고 닫는 것 자체가 짐이 된다. 여기에 더해 판매처가 쿠팡, 11번가 등으로 늘어나면 통합 관리가 필수다. 이때가 셀러온 같은 통솔 툴이 빛을 발하는 시점이다. 임계점을 명확히 알고 넘어가야 실패가 없다.

    월 수수료를 내지 않고 무료로 자동화할 수 있는 방법

    개발자 지식을 조금만 빌리면 돈 안 내고도 꽤 쓸만한 자동화를 만들 수 있다. 나는 SaaS 운영할 때 외부 API 요금이 아까워서 직접 스크립트를 짜서 돌리는 경우가 많다. 구글 스프레드시트에는 ‘Apps Script’라는 보물이 숨어 있다.

    예를 들어, 구글 스프레드시트의 IMPORTXML이나 IMPORTDATA 함수는 외부 데이터를 긁어올 때 유용하다. 다만 스마트스토어는 인증이 필요해서 이 함수만으로는 안 되고, 간단한 구글 스크립트(GAS)를 써야 한다. 복잡하게 생각하지 말고, 단순히 “엑셀 파일을 구글 드라이브에 올리면 시트가 업데이트되는 로직”만 만들어도 반복 작업은 확 줄어든다. 아래는 그 뼈대다. 실행하면 A2 셀에 마지막 갱신 시각만 기록하고 끝나며, 실제 주문을 가져오려면 주석 자리에 스마트스토어 API 호출이나 드라이브 파일 읽기를 직접 채워야 한다.

    
    function autoImportOrders() {
      var sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
      // 여기에 스마트스토어 API를 호출하거나,
      // 특정 폴더의 엑셀 파일을 읽어오는 코드를 넣습니다.
      // (초보자는 '파일 업로드 폼'과 연동하는 스크립트부터 추천)
      sheet.getRange("A2").setValue("마지막 업데이트: " + new Date());
    }
    

    위 코드는 그냥 예시다. 아래 코드는 마지막 업데이트 시각만 기록하는 뼈대 예시이며, 실제 주문 가져오기를 구현하려면 일반 따옴표를 사용하고 스마트스토어 API 호출 또는 Drive 파일 읽기·변환 로직을 추가해야 합니다. 코딩이 무섭다면 ‘오토핫키’ 같은 매크로 프로그램을 써보자. 마우스 클릭 위치와 키보드 입력을 녹화해서 반복 재생하는 방식이다. 이거 하나만으로도 송장 입력 자동 클릭은 충분히 구현 가능하다.

    구글 스프레드시트 임포트 함수로 주문 자동 불러오기

    직접 API를 붙이기 무섭다면, 중간 단계를 하나 둔다. 스마트스토어 관리자 페이지에서 엑셀을 다운로드하는 건 사람 손으로 하되, 그 파일을 구글 드라이브 특정 폴더에 넣기만 하면 자동으로 시트에 정리되는 구조다. 이것만으로도 ‘복사+붙여넣기’ 수고를 절반은 줄인다.

    반복 업무 줄이는 크롬 확장 프로그램 활용법 (송장 발급 자동 클릭)

    크롬 웹 스토어에는 ‘Auto Clicker’ 같은 확장 프로그램이 널렸다. 배대지 사이트나 택배사 사이트에서 매번 똑같은 버튼을 누르는 짓은 이제 그만하자. 확장 프로그램을 켜두고 해당 버튼의 셀렉터를 지정해주면, 새로고침만 해도 자동으로 클릭해준다. 이걸 ‘가짜 오류’ 방지용으로도 쓴다. 페이지가 멈췄을 때 자동으로 새로고침을 눌러주게 설정하면 두뇌를 쓸 필요가 없다.

    기본 도구로 주문 관리

    구체적으로 어떤 업무를 얼마나 줄일 수 있을까? (실전 데이터)

    숫자가 거짓말을 하지 않는다. 내가 운영하는 자동화 블로그 공장에서 측정한 데이터를 공개한다. 수동으로 글을 쓰고 썸네일을 만들고 올릴 때, 포스팅 하나당 평균 40분이 걸렸다. 이걸 파이썬 스크립트와 크론 잡으로 자동화한 뒤로 내가 하는 일은 검수뿐이다. 약 92%의 시간 절감 효과다. 쇼핑몰 업무도 다르지 않다.

    일일 주문량 20건 기준으로 수동 작업과 엑셀 자동화를 비교해봤다.

    • 수동 작업: 주문 확인 5분 + 송장 입력 20분 + 문자 발송 5분 = 총 30분
    • 엑셀 자동화 (매크로 활용): 파일 다운로드 3분 + 송장 대입 5분 + 대량 문자 발송 2분 = 총 10분

    하루에 20분을 번다. 한 달이면 600분, 10시간이다. 이 10시간 동안 상권 분석을 하거나 신상품을 발로 뛰어 찾는 것이 가치가 높다.

    배송 입력: 주문 건수에 따른 시간 절약 그래프

    주문 건수가 100건으로 늘어나면 수동 작업은 2시간 이상 소요된다. 다만 엑셀이나 간단한 스크립트를 쓰면 그래프의 기울기가 완만해진다. 건수가 늘어나도 고정된 로직이 처리하기 때문에 내 시간은 거의 들지 않는다. 이게 ‘스케일’의 시작이다.

    주문 확인 및 고객 알림: 자동 메시지 설정으로 CS 감소 효과

    스마트스토어의 ‘자동 알림톡’ 설정을 최대한 활용하라. “상품 준비 중”, “배송 시작” 같은 단계는 시스템에게 맡겨라. 사람이 직접 문자 보내다 보면 실수로 타인 번호로 보내거나, 내용을 잘못 적어 CS가 들어오는 경우가 생긴다. 시스템은 쉬지 않고 정확하다. 내가 실수할 여지를 없애는 게 곧 업무 감축이다.

    초보자도 쉽게 설정할 수 있는 실전 단계와 한계점

    무료 자동화에도 함정은 있다. 가장 치명적인 건 ‘API 연동 불량’과 ‘중복 발송’이다. 내가 예전에 만든 인스타 릴스 자동화 봇이, 인스타그램 정책 변경 단 하나 때문에 며칠째 게시물을 올리지 못하는 사태가 벌어졌다. 그동안 쌓인 데이터가 꼬여서 다시 수동으로 풀어야 했는데, 그게 자동화로 벌어들인 시간보다 더 오래 걸렸다.

    당장 오늘 적용하는 3단계 자동화 체크리스트

    1. 엑셀 템플릿 만들기: 주문서 다운로드 파일 양식에 맞춰 송장 번호만 붙여 넣으면 되는 양식을 하나 만든다.
    2. 자동 문자 세팅: 상품 발송 안내, 배송 시작 메시지를 스마트스토어 기본 기능으로 미리 예약해둔다.
    3. 매크로 녹화: 오토핫키나 엑셀 매크로로 ‘송장 입력 – 확인 버튼 클릭’ 과정 하나만 녹화해둔다.

    자동화 툴 사용 시 주의할 점 (연동 오류, 중복 발송)

    엑셀이든 크론 잡이든, 꼭 ‘로그’를 남겨야 한다. 오늘 어떤 주문을 처리했고, 어떤 게 실패했는지 기록이 없으면 나중에 누락이 생겨도 알 수가 없다. 특히 무료 스크립트를 돌릴 때는 스크립트가 죽었을 때 알림이 오게 구성해야 한다. 안 그러면 모르는 사이에 주문이 밀리게 된다.

    결론: 시간을 사되, 월세 내듯 현명하게 지출하세요

    도구를 쓰는 목적은 분명해야 한다. 내가 더 잘 먹고 잘 자기 위해서 시간을 사는 것이지, 멋진 툴을 쓴다고 사장님이 되는 게 아니다. 셀러온으로 아낀 시간은 쉬는 데 쓸 게 아니라 매출을 올리는 데 써야 한다. 지금 당장 엑셀을 꺼내서 주문 관리 시트를 만들어보자. 내월 매출이 셀러온 연체료를 낼 정도로 올라갔을 때 그때 유료 툴을 결제해도 늦지 않다.

    수수료를 지불하고 툴을 도입할 타이밍은 단 하나, 일일 주문 50건을 넘어서 엑셀 파일 관리가 짐이 되는 순간이다.

    출처와 근거 자료


    글쓴이 정보

    제가 만든 AI 파이프라인이 초안을 쓰고, 저는 검사에 걸린 것만 손봅니다. 통과하지 못한 초안은 그냥 버립니다. 파이프라인은 여기에 정리해 두었습니다.

    궁금해할 만한 것들

    하루 주문 5건인데 셀러온 써도 될까요?

    월 수수료가 노동 시간의 가치보다 비싸기 때문에 추천하지 않습니다. 하루 5건 팔아 순익이 3만 원인데 월 5만 원을 내면, 사실상 장사가 아니라 기부나 다름없습니다.

    스마트스토어 자동화 툴을 도입해야 할 타이밍은?

    월 주문 100건 이상이거나 하루 2시간 이상을 배송 입력에 쏟을 때가 적기입니다. 그 전에는 엑셀이나 구글 스프레드시트 활용이 훨씬 효율적입니다.

    셀러온 없이 엑셀로만 배송 입력을 자동화할 수 있나요?

    엑셀의 Power Query나 VLOOKUP 함수를 활용하면 반복 업무의 80%를 줄일 수 있습니다. 코드를 짤 필요 없이 기본 기능만으로도 송장 번호 매칭이 충분히 가능합니다.

    구글 스프레드시트로 스마트스토어 주문을 가져오려면 어떻게 하나요?

    단순 함수로는 안 되고 ‘Apps Script’를 활용해야 합니다. 엑셀 파일을 구글 드라이브에 올리면 시트가 자동 업데이트되는 간단한 로직만으로도 관리 부하를 확 줄일 수 있습니다.

    자동화 툴 쓰다가 오류 나면 어떻게 하나요?

    주문량이 적을 때는 수동 관리가 오류 방지에 더 유리합니다. 통제 불가능한 상황에서는 API 연동 오류로 미처리 건이 생길 수 있어, 관리 사이즈가 커진 후에 툴을 도입하는 게 안전합니다.

  • 카카오톡 링크 미리보기 안 나올 때, OG 태그로 고치기

    카카오톡 링크 미리보기 안 나올 때, OG 태그로 고치기

    SNS 공유가 안 될 때, 겪는 그 답답함 정확히 압니다

    블로그에 정성스럽게 글을 썼는데 링크를 카카오톡에 붙여넣으려니 썸네일이 안 뜨는 경험, 다들 한 번쯤 있을 겁니다. 텍스트만 덩그러니 뜨거나, 아예 잘못된 로고 이미지가 나와서 당황했죠. 워드프레스 블로그를 운영하면서 가장 자주 겪는 이 ‘워드프레스 OG 태그 오류’는 단순히 보기 싫은 문제를 넘어서 방문자 30%를 그냥 날려버리는 결과로 이어집니다. 링크를 클릭할지 말지는 0.5초 안에 결정되는데, 그때 보여주는 ‘얼굴’이 없다면 아무리 좋은 글도 무용지물이니까요. 저도 처음 자동화 블로그를 만들었을 때 이 문제 때문에 며칠을 밤새 디버깅했던 기억이 납니다. 설정이 꼬여서 카카오톡 링크 미리보기가 안 뜨면 트래픽이 반토막 나는 건 당연한 일이죠.

    왜 내 글만 썸네일이 안 뜰까요?

    대부분은 워드프레스 기본 설정에는 메타 태그가 비어 있기 때문입니다. 페이스북이나 카카오 같은 플랫폼은 ‘og:image’나 ‘og:title’ 같은 정보를 페이지 소스에서 찾는데, 이것이 없으면 그냥 아무 이미지나 가져오거나 아예 비워버립니다. 글을 쓸 때마다 수동으로 입력할 수도 있지만, 그건 1인 빌더가 할 수 있는 노동이 아닙니다. 매일 수십 개의 글이 발행되는 제 블로그 시스템에서 일일이 썸네일을 등록하는 건 불가능했고, 결국 이 과정을 자동화하지 못하면 블로그 방문자 유입 감소는 피할 수 없는 구조적인 문제였습니다.

    방문자 30%를 날리는 잘못된 메타 태그의 대가

    제가 운영하는 사이트들의 로그를 분석해보면, SNS 유입 비중은 생각보다 큽니다. 다만 메타 데이터가 없으면 클릭률(CTR)이 급격히 떨어지는데, 이는 사람들의 시선이 이미지로 먼저 가기 때문입니다. 소셜 미디어에서 글이 떠도 클릭을 안 시키면 그건 죽은 길거나 다름없습니다. ‘블로그 방문자 유입 감소 원인’을 찾다가 제일 먼저 점검해봐야 할 게 바로 이 부분입니다. 썸네일 하나 때문에 트래픽을 반으로 줄이는 건 너무나 억울한 손해니까요.

    OG 태그가 단순 정보가 아닌 ‘클릭 유도’ 장치인 이유

    OG(Open Graph) 태그는 단순히 페이지 정보를 적어두는 기술 명세가 아닙니다. SNS에서 내 글을 보여주는 ‘간판’ 역할을 합니다. 제가 만드는 콘텐츠 자동화 파이프라인에서는 AI가 글을 쓰고, 또 다른 AI가 이 OG 태그를 세팅합니다. 제목을 잘 써도 썸네일이 없으면 클릭이 안 됩니다. 반대로, 제목이 평범해도 썸네일이 매력적이면 클릭이 됩니다. 말하자면 OG 태그는 정보 전달을 넘어 쓸 만한 클릭 유도 장치(Copywriting)가 되어줘야 합니다. 그래서 저는 이걸 단순한 세팅이 아니라 ‘제품의 퍼블리싱’ 과정의 핵심으로 봅니다.

    OG 태그가 왜 중요하고 구체적으로 어떤 역할을 하나요?

    페이스북, 트위터, 링크드인 같은 해외 플랫폼은 대체로 Open Graph Protocol을 표준으로 따릅니다. 다만 문제는 국내입니다. 네이버 블로그나 카카오톡은 조금 다른 방식을 쓰기도 하고, 스크래핑 타이밍이 다릅니다. ‘SNS 클릭률 높이는 법’의 가장 기초는 이 태그를 제대로 심는 것입니다. 예를 들어, 제가 매일 크론으로 돌리는 유튜브 쇼츠 링크를 카카오톡에 공유할 때도 이 태그가 없으면 그냥 검은 화면만 뜹니다. 이건 자동화 시스템의 신뢰도와도 직결됩니다. 태그 하나가 시스템의 완성도를 결정하니까요.

    네이버와 카카오톡이 읽어들이는 메타 데이터의 차이

    해외 플랫폼과 달리 한국형 메신저는 캐시가 더 강력하게 작동합니다. 네이버는 ‘twitter:card’나 ‘og:title’을 우선순위로 읽지만, 카카오톡은 가끔 맨 처음 이미지를 무작위로 가져오기도 합니다. 이게 가장 골치 아픈 부분입니다. ‘메타 태그 중요성’을 아무리 강조해도, 각 플랫폼마다 읽는 스펙이 다르니까요. 그래서 저는 모든 스펙을 커버하는 ‘호환성 높은 코드’를 짤 수밖에 없었습니다. 어디에 링크를 걸든 제 의도한 썸네일이 뜨게 만드는 게 진짜 자동화니까요.

    가장 쉬운 방법 vs 가장 가벼운 방법: 선택의 기준

    워드프레스에서 이걸 해결하려는 ‘가장 쉬운 방법’은 유명한 SEO 플러그인을 깔는 겁니다. Rank Math나 Yoast SEO 같은 플러그인은 잘 만들어졌습니다. 다만 저는 이걸 쓰지 않습니다. SaaS를 10개가량 운영하면서 겪었지만, 플러그인이 하나씩 늘어날 때마다 사이트 속도는 기하급수적으로 느려지거든요. DB 쿼리도 늘고, 충돌도 납니다. ‘플러그인 없이 워드프레스 속도 높이기’를 원하는 1인 창업자 입장에서, 이건 무거운 대가를 치르는 선택입니다.

    워드프레스에서 이걸 자동으로 설정해주는 가장 쉬운 방법은 무엇인가요?

    물론 플러그인이 편합니다. 설정 화면에서 토글 하나만 켜면 알아서 다 해주니까요. 다만 그 ‘편리함’ 뒤에는 숨겨진 비용이 따릅니다. 제가 처음에는 ‘워드프레스 og 태그 플러그인 추천’을 검색해서 유명한 걸 다 깔았습니다. 다만 나중에 서버 모니터링을 해보니, 페이지 로드할 때 플러그인이 불러오는 CSS랑 JS 파일이 수백 줄이었습니다. 글 하나 읽는데 그 무거운 짐을 짊어지고 오는 격입니다.

    무거운 플러그인 없이 가볍게 적용하는 방법이 있나요?

    저는 코드를 직접 수정합니다. `functions.php`에 후킹(Hooking)해서 `wp_head`에 코드를 심는 방식입니다. 다만 `functions.php` 자체가 테마 파일이라 테마를 바꾸면 그대로 사라집니다. 그래서 부모 테마를 직접 건드리지 말고 자식 테마에 넣거나, 디자인과 무관하게 유지돼야 하는 기능이면 커스텀 플러그인으로 빼는 쪽이 맞습니다. 이게 ‘wp_head 후킹 사용법’의 핵심입니다. 테마 업데이트를 해도 코드가 날아가지 않도록 자식 테마(Child Theme)나 간단한 커스텀 플러그인을 하나 만들어서 관리하면 됩니다. 제 경험상, 플러그인을 지우고 이 방식으로 바꾸니 페이지 로딩 속도가 1초 이상 빨라지는 걸 확인했습니다. 속도는 곧 돈이니까요.

    자동화 핵심: 썸네일 없어도 지정 이미지가 뜨게 만들기

    AI가 글을 쓰는 환경에서 가장 큰 문제는 ‘대표 이미지(Featured Image)’가 없는 경우입니다. AI가 텍스트는 써줘도 이미지는 만들어주지 않거나, 가끔 실수를 할 때가 있거든요. 그때마다 관리자가 들어가서 이미지를 일일이 등록하라면 그건 자동화가 아닙니다. 제 ‘무인 크론’ 시스템이 멈추지 않으려면, 글에 이미지가 없을 때 자동으로 기본 이미지를 띄워주는 ‘폴백(Fallback) 로직’이 필수적입니다.

    글마다 일일이 썸네일을 만들지 않고도 공유 이미지를 자동으로 뽑을 수 있나요?

    가능합니다. 코드를 짤 때 “이 글에 대표 이미지가 설정되어 있나?” 확인하고, 없다면 “기본 로고 이미지를 가져와”라고 조건문을 걸면 됩니다. 이게 ‘워드프레스 썸네일 자동 생성’의 꽃입니다. 저는 제 브랜드 로고를 기본 이미지로 설정해뒤습니다. 그러면 글에 썸네일을 깜빡한 글이라도 SNS에 공유했을 때 제 브랜드가 찍힌 이미지가 나옵니다. 아무것도 안 뜨는 것보다는 낫죠.

    대표 이미지(Featured Image)가 없을 때의 자동 대체 로직

    ‘없는 이미지 대체 태그’ 로직은 생각보다 단순합니다. `get_the_post_thumbnail_url()` 함수가 비어있으면, 미리 지정해둔 블로그 대표 이미지 URL을 넣어주는 식입니다. 이렇게 하면 이미지가 없는 글이라도 링크 공유 시 정돈된 모습을 유지할 수 있습니다. ‘블로그 대표 이미지 설정’만 제대로 해두면, 나머지는 코드가 알아서 처리해줍니다. 덕분에 저는 주말에 컴퓨터를 켜지 않아도 매일 아침 SNS에 예쁜 썸네일 달린 글이 자동으로 포스팅됩니다.

    코드로 이미지 미리보기

    카카오톡과 슬랙, 미리보기가 깨질 때 점검 리스트

    코드를 다 짜고 나서 막상 카카오톡이나 슬랙에 링크를 걸어보면, 여전히 이전의 썸네일이 뜨거나 아예 아무것도 안 뜰 때가 있습니다. 이전 미리보기가 계속 보이면 캐시를 먼저 의심하되, 미리보기가 생성되지 않으면 OG 태그, HTTP 응답, 외부 접근 가능 여부, 방화벽, 이미지 용량과 중복 태그도 함께 확인해야 합니다. 각 플랫폼의 서버가 우리 사이트를 한 번 긁어간(Crawl) 다음, 그 정보를 메모리에 저장해두기 때문입니다. 이건 자동화를 할 때 가장 많이 실수하는 부분이기도 합니다.

    카카오톡이나 슬랙 공유 미리보기가 제대로 뜨게 하려면 어떤 설정을 더 확인해야 하나요?

    우선 내 코드가 맞는지 확인해야 합니다. 그 다음은 플랫폼의 개발자 도구를 써야 합니다. ‘카카오톡 디버거 사용법’을 검색해서 공식 개발자 사이트에 들어가면, 스크래핑 캐시를 삭제하는 버튼이 있습니다. 여기서 내 URL을 다시 긁어오라고 명령을 내리면 새로운 메타 태그를 읽어옵니다. 슬랙이나 기타 메신저도 비슷합니다. ‘스택 오버플로우 공유 미리보기’가 이상하다면, 그쪽 스크래퍼가 뭔가 긁어가지 못한 게니까 HTML 구조를 다시 점검해야 합니다.

    디버깅 툴 사용법과 캐시 문제 해결

    ‘SNS 캐시 삭제 방법’은 중요합니다. 내가 수정을 했는데 안 바뀐다고 코드를 뜯어고치면 삽질만 늘어납니다. 카카오톡 디버거와 페이스북 Sharing Debugger를 북마크해두고, 수정 후에는 한 번씩 들어가서 ‘Scrape Again’을 누르는 습관을 들이세요. 그래야 실제 사용자들에게 바뀐 모습이 보입니다. 저도 자동화 시스템 배포 후에는 꼭 이 과정을 거쳐서 제대로 뜨는지 눈으로 확인합니다.

    지금 바로 적용하는 최소한의 자동화 코드

    이론은 이제 충분하니, 바로 복사해서 쓸 수 있는 코드를 드리겠습니다. 이 코드는 제가 만든 SaaS 중 하나의 핵심 기능을 아주 가볍게 뜯어낸 버전입니다. 복잡한 기능은 다 뺐고, 오직 카카오톡과 페이스북 등에서 제대로 뜨게 만드는 ‘자동 메타 태그 생성기’ 역할만 합니다. 자식 테마의 `functions.php` 맨 아래, 또는 테마를 바꿔도 유지하고 싶다면 간단한 커스텀 플러그인 파일에 붙여넣으시면 됩니다. 붙여넣기 전에 따옴표가 일반 ASCII 따옴표인지 확인하세요.

    
    function custom_og_tags() {
        if (is_singular()) {
            global $post;
            // 기본 설정값
            $title = get_the_title();
            $url = get_permalink();
            $desc = wp_trim_words(get_the_excerpt(), 30, '...');
            $img = get_the_post_thumbnail_url($post->ID, 'large');
            // 대체 이미지 (썸네일이 없을 경우 사용할 블로그 로고 URL)
            $default_img = 'https://your-site.com/default-image.jpg';
            if (!$img) {
                $img = $default_img;
            }
            echo '' . "\n";
            echo '' . "\n";
            echo '' . "\n";
            echo '' . "\n";
            echo '' . "\n";
            // 트위터 카드 설정
            echo '' . "\n";
        }
    }
    add_action('wp_head', 'custom_og_tags', 5);
    

    functions.php에 붙여넣고 끝나는 핵심 코드

    이 코드의 요는 `get_the_post_thumbnail_url`로 썸네일을 확인하고, 없으면 `$default_img` 변수에 넣은 주소를 사용한다는 점입니다. `your-site.com/default-image.jpg` 부분만 본인의 블로그 로고나 대표 이미지 주소로 바꾸면 됩니다. ‘워드프레스 OG 태그 코드’를 검색해서 다른 걸 가져와도 되지만, 너무 복잡한 건 오히려 에러를 유발합니다. 최소한의 게 가장 빠릅니다.

    설정 후 꼭 확인해야 할 3가지

    코드를 넣고 난 뒤에는 3가지만 체크하세요. 하나는 소스 보기(`Ctrl+U`)에서 `og:image` 태그가 제대로 생겼는지 확인. 다른 하나는 썸네일이 없는 글에서도 대체 이미지가 나오는지 테스트. 나머지는 카카오톡 디버거로 캐시를 지워서 실제로 잘 뜨는지 확인입니다. 이 3단계만 통과하면 ‘functions.php 코드 추가’ 작업은 끝입니다. 이제 링크 공유할 때 맨날 걱정했던 썸네일 문제는 사라집니다.

    마무리: 진짜 자동화를 원한다면

    OG 태그 자동화는 1인 블로그 운영자가 무인 자동화로 가기 위한 첫 관문입니다. 이거 하나 해결했다고 끝이 아닙니다. 끝내 콘텐츠의 퀄리티와 검색 노출이 따라줘야 방문자가 계속 늡니다. ‘워드프레스 SEO 자동화’는 메타 태그만으로는 부족하고, 구조화된 데이터와 키워드 최적화가 더 필요합니다. 제가 운영하는 아일리고(AILEEGO)는 이런 반복적인 SEO 작업조차 자동화해서 관리하는 철학을 가지고 있습니다.

    물론 지금 드린 코드로도 일반적인 블로그 운영은 충분합니다. 다만 SaaS 레벨의 관리를 원하거나, 아예 키워드 분석부터 메타 데이터 세팅까지 자동으로 처리하고 싶다면 좀 더 체계적인 도구를 볼 필요가 있습니다. 다만 비싼 플러그인을 깔라는 뜻은 아닙니다. 무겁게 이것저것 붙은 것보다, 필요한 기능만 있는 가볍고 특화된 도구를 고르는 편이 낫습니다. 봐야 할 건 내가 콘텐츠에 집중할 수 있도록, 기술적인 잡일은 코드가 처리하게 만드는 겁니다. 그게 진짜 1인 빌더가 가야 할 길 아닐까요?

    사례: 이 블로그도 42개 페이지에서 og:title이 통째로 빠져 있었다

    남 얘기가 아니다. 이 블로그를 점검하다 모든 페이지에서 og:title·og:description·meta description이 통째로 빠져 있는 것을 발견했다. 42개 페이지 전부였다.

    몇 주 동안 아무도 못 알아챈 이유가 있다. OG 태그가 전부 없었던 게 아니라 일부만 없었다. og:url, og:type, og:locale, og:image는 정상적으로 나가고 있었다. 그래서 소스를 대충 훑으면 “OG 있네”로 보인다. 카카오톡 미리보기에 이미지는 뜨는데 제목만 이상하게 나오는 상태였던 것이다.

    확인할 때 걸린 함정 두 가지

    첫째, 페이지 소스 전체에서 og:title을 검색하면 안 된다. 이 글처럼 OG 태그를 설명하는 글은 본문 코드 예시에 그 문자열이 들어 있어서, 검색에는 걸리는데 정작 <head> 안에는 없는 상황이 생긴다. 반드시 </head> 앞 구간만 잘라내서 <meta> 태그를 전부 나열해 봐야 한다.

    둘째, 검사 스크립트에 길이 제한을 걸면 안 된다. content="([^"]{0,70})"처럼 70자 제한을 두면 og:image의 긴 URL이 안 잡혀서 “og:image도 없다”고 잘못 판단하게 된다.

    원인은 태그가 아니라 그 앞의 게이트였다

    플러그인 설정에서 메타 자동 생성은 켜져 있었다. 그런데 그 설정을 읽기 전에 라이선스 확인 단계가 있었고, 그게 만료돼서 메타를 만드는 함수가 즉시 종료되고 있었다. og:url 같은 항목은 그 확인 단계 바깥에 있어서 계속 출력됐다 — 이게 “일부만 나오는” 증상의 정체다.

    더 허탈한 건 그다음이다. 설명 문구 데이터는 이미 다 있었다. 글마다 요약문이 워드프레스 excerpt 필드에 저장돼 있었는데, 플러그인은 자기 전용 필드를 읽고 있었다. 두 시스템이 같은 데이터를 서로 다른 서랍에서 찾고 있었던 것이다. 그래서 복구는 새로 만들 필요 없이 excerpt를 그 필드로 옮겨 담는 것으로 끝났다.

    정리하면 점검 순서는 이렇다. ① </head> 앞 구간의 meta 태그 전량 확인 → ② 없는 항목과 있는 항목을 갈라서 “왜 일부만 나오는가”를 묻기 → ③ 플러그인 설정값이 아니라 그 설정을 읽기 전에 걸리는 조건(라이선스·권한·다른 SEO 플러그인 감지)을 확인 → ④ 넣을 데이터가 이미 사이트 어딘가에 있는지 먼저 찾기.

    참고한 공식 문서


    글쓴이 정보

    초안은 AI 파이프라인이 쓰고, 검사를 통과한 글만 공개됩니다. 걸린 초안은 제가 직접 고칩니다. — 아일리고