초보 개발자

CLAUDE.md 정리하다 발견한 중복 지침
CLAUDE.md 정리를 한 번도 안 했다면 점검해볼 만하다. Claude Code(AI 코딩 도우미)를 쓰다 보면 어느 순간 CLAUDE.md 파일이 여러 개가 된다. 내 환경에는 세 개가 있었다. 그냥 두면 되는 줄 알았는데 점검해보니 아니었다.

CLAUDE.md가 뭐고 왜 여러 개일까?

CLAUDE.md는 Claude Code가 세션(session, 작업을 시작하고 끝내는 한 번의 대화 구간)을 시작할 때 자동으로 읽는 설정 파일이다. “나는 이렇게 일하는 사람이야, 이 규칙을 따라줘”라고 클로드에게 미리 알려두는 메모다.

문제는 이 파일이 한 군데만 있는 게 아니라는 점이다. Claude Code는 공식 문서에 나온 것처럼 여러 위치에서 CLAUDE.md를 찾는다. 홈 폴더(~/CLAUDE.md), 전역 설정 폴더(~/.claude/CLAUDE.md), 그리고 각 프로젝트 폴더 안의 CLAUDE.md까지.

내 세 파일은 ~/CLAUDE.md, ~/.claude/CLAUDE.md, 자동화 프로젝트 폴더의 CLAUDE.md였다. 그래서 클로드에게 직접 점검을 시켰다. 파일 내용을 실제 폴더와 대조해서 읽고, 수정하거나 지워도 되는 부분이 있으면 알려달라고 했다.

CLAUDE.md 정리 전 점검: 세 파일에서 나온 문제

세 파일 모두 문제가 있었다. 종류는 달랐다.

~/CLAUDE.md는 131줄짜리 파일이었다. 클로드가 읽고 나서 이상한 걸 발견했다. 1번 줄과 67번 줄에 똑같이 # CLAUDE.md라는 제목이 있었다. 1~65줄과 67~131줄을 비교했더니 완전히 같은 내용이었다. 같은 지침 블록이 두 번 들어가 있었다는 뜻이다.

위는 정리 전 131줄, 정리 후 65줄과 두 블록 비교 결과를 찍은 화면이다. 왜 두 번 들어갔는지 원인은 지금도 모른다.

자동화 프로젝트 CLAUDE.md에는 다른 문제가 있었다. workflows/ 폴더를 전제로 한 규칙이 세 곳에 흩어져 있었다. “Workflow는 내 허락 없이 새로 만들거나 삭제하지 마”, 에러 처리 절차의 ‘Workflow 업데이트’, 보안 절의 ‘Workflow’ 표현. 그런데 workflows/ 폴더가 실제로 없었다. 폴더는 사라졌는데 규칙은 그대로 남아 있었다.

CLAUDE.md 정리 중 만난 NotebookLM 지시 문제

~/.claude/CLAUDE.md는 또 다른 문제였다. 세션 시작 때 NotebookLM(구글의 AI 노트 정리 도구) 노트북을 먼저 검색하라고 되어 있었다. 그런데 NotebookLM 연결은 로그인 감지 버그와 구글 장애로 2026-09-01부터 막혀 있었다. 매 세션마다 실패할 게 뻔한 명령이 설정에 그냥 살아 있었던 거다.

위는 전역 CLAUDE.md의 NotebookLM 지시를 고친 변경 부분이다.

그 외에 자동화 프로젝트 CLAUDE.md에 ‘실제 사용 중인 블로그는 tistory 1개뿐’이라고 적혀 있었다. 지금 이 블로그, ujinify.com이 훨씬 더 활발히 쓰는 프로젝트인데도 설정에는 반영이 안 되어 있었다.

CLAUDE.md 정리 첫 단계: 중복 찾는 쉘 명령어

쉘(shell, 명령어를 입력해서 컴퓨터에게 일을 시키는 창)에서 두 가지 명령어로 확인할 수 있다.

먼저 파일이 몇 줄인지 센다.
- wc -l ~/CLAUDE.md , 줄 수를 보여준다. wc는 ‘word count’의 줄임말이다.
- grep -n '^# ' ~/CLAUDE.md , 파일 안에서 #으로 시작하는 제목 줄을 찾아서 몇 번째 줄인지 함께 보여준다. grep은 파일 안에서 특정 단어나 패턴을 찾는 명령어다.
내 경우에는 grep 결과에 # CLAUDE.md가 1번 줄과 67번 줄, 두 군데 나왔다. 같은 제목이 두 번 뜨면 중복을 의심해야 한다. 그다음엔 두 블록의 내용이 실제로 같은지 확인해야 한다.

앞 블록과 뒤 블록을 비교하는 짧은 스크립트(script, 명령어를 순서대로 묶어둔 파일)를 돌렸다. 완전히 같다는 결과가 나왔고, 그래서 뒤 블록을 지웠다.

자기 파일에서 확인하려면 이 순서로 해보면 된다. wc -l로 줄 수 확인 → grep -n '^# '로 제목 위치 확인 → 같은 제목이 두 군데 이상 있으면 두 블록 내용 비교. 간단하다.

CLAUDE.md 정리에서 없는 폴더 규칙 지우기

workflows/ 폴더가 실제로 없다는 걸 어떻게 확인했냐고 하면, ls 명령어로 봤다. ls는 폴더 안에 뭐가 있는지 목록으로 보여주는 명령어다. 없으면 없다고 나온다.

있어야 할 폴더가 없으면 그 폴더를 전제로 한 규칙은 전부 의미가 없다. 클로드가 “Workflow 삭제 전 허락을 받아야 한다”는 규칙을 읽어도, 지킬 대상이 없다. 그냥 노이즈다.

위는 workflows 폴더가 없다는 결과와 정리 전후 ‘Workflow’ 문구 검색 결과다.

수정 전에 파일을 /tmp에 백업했다. /tmp는 임시 파일을 저장하는 폴더다. 백업 없이 수정하지 마라. 잘못 지우면 돌아올 방법이 없다.

백업 뒤에 workflows/ 관련 문구를 세 곳 모두 지웠다. 113줄이던 파일이 106줄이 됐다.

파일 구조를 설명하는 절도 실제와 달랐다. tools/ 폴더에 파이썬(.py)과 타입스크립트(.ts) 파일이 섞여 있고, 새 코드는 타입스크립트로 작성된다는 실제 구조로 고쳤다. ujinify를 활성 블로그 목록에 올리고, 폐기된 프로젝트 목록은 4줄로 줄였다. 보관 방침은 그대로 뒀다.

실제 안 쓰는 도구 지시는 지우기로 했다

NotebookLM 지시는 지울지 남길지 갈렸다. 연결이 복구되면 다시 켜야 해서, 재개 규칙까지 통째로 지우면 나중에 처음부터 다시 써야 한다.

그래서 지우지 않고 ‘보류 중’으로 바꿨다. 지시 자체는 남겨두고, 현재 상태를 주석처럼 표시한 거다. 연결이 복구되면 ‘보류 중’ 표시만 지우면 된다. 재개 규칙은 그대로 살아 있다.

이건 판단의 문제다. 완전히 폐기된 도구라면 지우는 게 맞다. 일시 중단 상태라면 보류 표시를 남겨두는 쪽이 낫다. 어느 쪽이든 원칙은 하나다. 지금 작동하지 않는 도구에 대한 지시가 설정에 살아 있으면 클로드는 매 세션마다 실패할 명령을 실행하려 한다. 그 부분만큼은 반드시 정리해야 한다.

ujinify 전용 CLAUDE.md를 새로 만든 이유

점검하면서 ujinify 블로그 파이프라인 폴더에 전용 CLAUDE.md를 새로 만들기도 했다. 여기저기 흩어져 있던 규칙들, 글 내용 규칙, 이미지 캡처 규칙, 랭크매스 점수 규칙, 릴스·링크 처리 순서를 한 파일에 모았다.

알려진 문제도 적었다. 이미지 캡션과 사실을 지어내는 문제, 랭크매스 포커스 키워드가 REST로 저장되지 않는 문제. 고친 게 아니라 기록한 거다. 기록해두지 않으면 클로드도 나도 같은 실수를 반복한다.

정리 후 나한테 달라진 점, 너도 확인해보는 방법

솔직하게 말하겠다. CLAUDE.md 정리 후 확인한 건 줄 수뿐이다. ~/CLAUDE.md가 131줄에서 65줄이 됐다. 프로젝트 CLAUDE.md가 113줄에서 106줄이 됐다. 그게 다다.

응답이 빨라졌는지, 컨텍스트가 몇 토큰 줄었는지는 측정하지 않았다. 그래서 효과는 “읽는 분량이 줄었다”까지만 말할 수 있다. 더 좋아졌다고 단정하지 않겠다.

내 환경의 CLAUDE.md 정리 상태 확인하는 법

자기 환경에서 확인하고 싶다면 세 가지만 해보면 된다.
- wc -l로 CLAUDE.md 줄 수를 세고, grep -n '^# '로 같은 제목이 반복되는지 확인한다.
- CLAUDE.md 안에 언급된 폴더 이름을 찾아서 ls로 실제로 있는지 확인한다.
- 세션 시작 때 실행하라고 적어둔 도구가 지금도 작동하는지 직접 돌려본다.
나는 이 세 가지에서 각각 문제가 나왔다. 처음 점검해보는 사람이라면 하나쯤은 걸릴 거라고 본다. 오래된 설정일수록 더 그렇다.

스킬과 메모리 폴더를 정리한 이야기는 Claude Code 스킬 정리 후기에 적어뒀다.

다음엔 새로 만든 ujinify 전용 CLAUDE.md가 실제로 잘 작동하는지 확인할 차례다. 규칙을 모아두는 것과 클로드가 그 규칙을 제대로 따르는 것은 다른 얘기다. 그 부분은 좀 더 써봐야 안다.
2026년 10월 01일
GitHub AI 에이전트 7개 다 봤는데 하나도 안 깐 이유

소셜 미디어에서 뭔가를 보면 일단 저장부터 한다. 나중에 쓸 것 같아서. 근데 나중이 오는 경우는 드물다.

이번엔 달랐다. 인스타그램 어딘가에서 AI 에이전트 도구 소개 카드를 봤고, 그냥 넘기지 않았다. 스크린샷을 찍어서 Claude Code한테 바로 물어봤다.

AI 에이전트 도구 7개, 먼저 검증했던 이유

처음엔 3개였다. claude-mem, find-skills, VibeSec. 캡처한 카드를 Claude Code에 던지면서 물었다.

“지금 설치돼 있어? 설치하면 나한테 좋아? 아니면 없어도 돼?”

그냥 좋아 보인다고 깔면 안 된다는 걸 안다. 도구는 내 상황에 맞아야 쓸 수 있다. 맞지 않는 도구는 설치하는 순간부터 짐이 된다. 그래서 먼저 확인했다.

확인 과정에서 ponytail, graphify, Ruflo, OmniRoute까지 추가로 검토하게 됐다. 결국 7개를 다 들여다봤다.

이미 깔려있던 도구들 (claude-mem, find-skills, ponytail, graphify)

결과부터 말하면, 4개는 이미 있었다.

claude-mem은 8월 28일부터 설치돼 있었다. find-skills도 이미 스킬로 등록된 상태였다. 몰랐다. 쓰고 있었는데 쓰고 있는 줄 몰랐던 거다.

ponytail은 좀 달랐다. 설치돼 있는 수준이 아니었다. 그 대화를 하는 내내 실제로 켜져서 작동하고 있었다. 이걸 확인하면서 뭔가 이해됐다. Claude Code가 항상 최소한의 코드로 답하던 게 이상하다고 생각한 적 있었는데, 그게 ponytail 때문이었다. 도구가 조용히 일하고 있었던 거다.

graphify도 전역 설정(어떤 프로젝트에서도 공통으로 적용되는 설정)에 등록돼 있어서 언제든 쓸 수 있는 상태였다. fire-your-seo-agency 스킬을 블로그 4개에 자동 적용했을 때도 비슷한 걸 느꼈다 — 이미 깔린 걸 제대로 아는 게, 새로 까는 것보다 먼저다.

이 네 개는 새로 깔 필요가 없었다. 이미 있으니까.

VibeSec을 안 깐 이유: 내 프로젝트 구조와 안 맞았다

VibeSec은 웹 취약점(XSS, SQL 인젝션 같은 것)을 잡아주는 보안 도구다.

XSS(Cross-Site Scripting)는 악성 스크립트를 웹페이지에 심는 공격이고, SQL 인젝션은 데이터베이스 쿼리를 조작하는 공격이다. 로그인 폼, 검색창, 결제 입력칸 같은 데서 주로 생긴다.

내 프로젝트엔 그런 게 없다. 지금 만드는 건 블로그 자동 생성 스크립트들이다. 사용자 입력을 받는 곳이 없다. 로그인도 없고 결제도 없다. 워드프레스 인증은 앱 비밀번호를 .env.local 파일(환경 변수를 저장하는 파일, 코드에 직접 비밀번호를 적지 않기 위해 사용)에 넣어서 쓰는 정도다.

VibeSec이 잡아줄 취약점 자체가 생길 구조가 아니었다. 좋은 도구지만 내 상황엔 맞지 않는다. 그래서 안 깔았다.

Ruflo, OmniRoute가 과했던 이유

Ruflo는 스웜 오케스트레이션(swarm orchestration, 여러 AI 에이전트를 동시에 무리 지어 운영하는 방식) 프레임워크다.

근데 확인해보니 사실 claude-flow라는 기존 프로젝트를 이름만 바꾼 거였다. 버전이 385개나 찍혀 있었다. 60개 넘는 에이전트를 동시에 굴리는 구조인데, 내 작업은 프로젝트마다 4~5개 역할이 정해진 순서대로 도는 방식이다. Ruflo가 필요한 상황이 아니었다. 이름을 바꿨다고 다른 도구가 되는 건 아니다.

OmniRoute는 다른 방향에서 과했다. 여러 AI 제공사(OpenAI, 앤트로픽 같은 곳)를 하나로 묶어서 무료 할당량을 다 쓰면 자동으로 다른 모델로 넘어가는 게이트웨이(gateway, 여러 서비스를 하나로 연결하는 중간 통로)다.

아이디어는 나쁘지 않다. 하지만 내 파이프라인 전체가 Claude 하나 기준으로 맞춰져 있다. 말투 스킬도, AI 패턴 차단 규칙도 전부 Claude 기준이다. 여기에 다른 모델을 섞으면 그동안 다듬어온 것들이 다 어긋날 수 있다. 거기다 요청이 게이트웨이를 하나 더 거치게 된다는 것도 마음에 걸렸다. 중간에 거치는 단계가 하나 늘어날 때마다 뭔가 꼬일 가능성도 하나씩 늘어난다.

13만 개 별을 의심하고 다시 확인한 검증 과정

ponytail 별(star, GitHub에서 사용자들이 좋은 프로젝트에 누르는 즐겨찾기 같은 것)이 13만 개, graphify가 11만 개라고 나왔다.

이 숫자가 이상했다. 13만 개면 엄청난 숫자다. 유명한 오픈소스 프로젝트 수준이다. AI가 그냥 그럴듯하게 숫자를 지어냈을 수 있다고 생각했다. AI가 할루시네이션을 일으키는 건 알려진 사실이다.

그래서 GitHub API(Application Programming Interface, 프로그램끼리 데이터를 주고받는 통로)로 직접 다시 확인해달라고 했다. 결과는 같은 숫자였다. 진짜였다.

의심했다. 확인했다. 믿었다. 이 순서가 맞다. 실제로 ponytail 저장소에 들어가면 지금도 그 별점을 직접 확인할 수 있다.

AI가 말하는 숫자나 사실은 한 번쯤 다시 확인해야 한다. 귀찮더라도 그렇게 해야 한다. 이번엔 맞았지만, 다음에도 맞다는 보장은 없다.

하나도 안 깐 게 오히려 정답인 이유

7개를 다 봤다. 하나도 안 깔았다.

처음엔 뭔가 하나쯤은 새로 깔아야 할 것 같았다. 7개를 다 확인해봤는데 결과물이 없으면 시간 낭비처럼 느껴질 것 같았다. 근데 하나씩 따져보면서 생각이 바뀌었다.

이미 있는 건 이미 있는 거다. 없는 건 지금 내 상황에 안 맞았다. 새로 깐 게 없다는 게 실패가 아니라, 지금 쓰는 구조가 이미 내 상황에 맞게 다듬어져 있다는 확인이었다.

뭔가를 안 하기로 결정하는 것도 결정이다. 그리고 그 결정을 내리려면 일단 확인은 해봐야 한다. 소개 카드만 보고 “좋아 보이네” 하고 깔았으면 지금 내 환경에 안 맞는 도구들이 3~4개쯤 더 쌓여 있었을 거다.

다음엔 지금 이미 깔려 있는 도구들을 제대로 들여다볼 생각이다. ponytail이 그 대화 내내 켜져 있었다는 걸 이번에 처음 알았다. 모르고 쓰고 있는 게 또 있을 거다.

버전이 안 맞아서 CLI가 아예 안 됐던 사례는 데몬 버전 불일치로 CLI가 안 됐던 이야기 (v1.8.7→1.8.8)에 정리했다.

2026년 09월 30일
예약 발행 기능을 직접 만들고 4개 글을 한 번에 올린 후기
예약 발행 기능이 없어서 매번 이렇게 됐다. 월요일 아침마다 똑같은 일을 반복하고 있었다. 글 하나 급하게 다듬고, 올리고, 끝. 그게 매주였다.

왜 그때그때 올리는 방식에 불만을 느꼈을까?

문제는 비효율이었다. 월요일이 될 때마다 그날 올릴 글 하나를 챙기는 방식은 솔직히 별로였다. 한 번 집중해서 여러 편을 미리 써뒀는데, 그걸 굳이 하나씩 날짜 맞춰 손으로 올려야 한다는 게 이상했다.

그래서 방향을 바꿨다. 한 주치 분량을 미리 정해두고, 날짜에 맞춰 자동으로 나가게 하는 구조가 낫다고 판단했다. 어느 월요일 아침, Claude Code에 바로 요청했다. “이번 주 수요일, 토요일, 다음 주 수요일, 토요일. 4개 예약 발행 하고 싶은데 가능해?”

가능하지 않았다.

예약 발행 기능이 없다면 직접 만들어야 한다

업로드 스크립트(script, 자동으로 실행되는 명령어 묶음)에는 예약 발행 기능 자체가 없었다. 초안(draft, 공개 전 임시 저장 상태)으로 올리는 것만 됐다. 특정 날짜에 자동으로 글이 나가도록 하는 옵션은 아예 존재하지 않았다.

당연히 있을 거라고 생각했다. 없어서 좀 당황스럽긴 했지만! 근데 어쩔 수 없다. 이것 역시 내가 지금까지 겪었던 것처럼 없으면 만들면 된다.

그 자리에서 바로 Claude Code에 추가 구현을 요청했다. 기존 스크립트를 고쳐서 날짜를 지정하면 그 시각에 발행되도록 하는 옵션을 넣는 작업이었다.

–schedule 옵션을 추가한 과정

Claude Code에게 요청한 방향은 단순했다. 기존 업로드 스크립트에 --schedule 옵션(option, 명령어를 실행할 때 추가로 붙이는 설정값)을 새로 추가해 달라는 것이었다. 날짜를 함께 넘기면 해당 시각에 발행되는 구조다.

예를 들어 이런 식이다.
- 기존 방식: 스크립트를 실행하면 바로 발행되거나 초안으로 저장
- 추가된 방식: --schedule 2025-07-09처럼 날짜를 붙이면 그 날짜에 자동 발행
Claude Code가 기존 코드 구조를 파악하고 옵션을 붙이는 로직(logic, 기능이 작동하는 규칙과 흐름)을 추가했다. 내가 직접 코드를 짠 게 아니다. 요청했고, 결과를 확인했다. 그게 전부였다.

기능 자체는 복잡하지 않았다. 처음부터 있었어야 했다고 생각한다.

4개 글을 한 번에 처리하려면 기준을 낮춰야 현실적이다

SEO(Search Engine Optimization, 검색엔진 최적화) 점수 기준 얘기를 해야 한다. 평소에는 랭크매스 기준 80점을 맞추고 올렸다.

이번엔 달랐다. 한 번에 4개를 처리해야 했다. 4개 전부 80점을 맞추려고 시간을 쓰다 보면 예약 발행의 의미가 없어진다. 그래서 기준을 낮췄다. 70점 이상이면 올린다고 정했다.

Claude Code에 요청할 때도 명확하게 전달했다. “랭크매스는 70점 이상만 맞춰줘.” 완벽하게 다듬는 것보다 4개를 제때 내보내는 게 이번의 목표였다.

기준을 낮추는 게 맞냐 틀리냐의 문제가 아니다. 현실적인 선택이었다. 한 번에 처리하는 분량이 늘어나면 기준도 거기에 맞게 조정해야 한다. 그렇지 않으면 결국 아무것도 못 올린다.

실제로 예약 발행을 돌려본 결과

4개 글을 한 번에 예약 걸었다. 이번 주 수요일, 토요일, 다음 주 수요일, 토요일. 각각 날짜를 지정해서 스크립트를 돌렸다.

작동했다. 상태가 “future”로 바뀌면서 예약이 정상적으로 걸린 걸 확인했다. 이제 지정한 날짜가 되면 자동으로 발행된다. 월요일 아침에 급하게 뭔가를 챙기는 일은 없어졌다.

다만 솔직히 말하면, 70점 기준으로 올린 글들이 80점짜리보다 성과가 어떻게 다를지는 아직 모른다. 데이터가 쌓여야 안다. 지금은 그냥 지켜보는 중이다.

예약 발행 자체는 앞으로도 유지할 생각이다. 그때그때 올리는 방식으로는 안 돌아간다. 미리 묶어서 처리하는 게 훨씬 낫다. 다음엔 4개가 아니라 더 늘릴 수 있을지 한번 봐야겠다.
2026년 09월 19일
fire-your-seo-agency 스킬로 4개 블로그 자동 SEO 최적화한 후기
이번에 Claude Code로 fire-your-seo-agency라는 스킬을 설치하고 블로그 4개에 SEO를 한꺼번에 적용했다. 중간에 파일이 세 번 중복으로 받아지는 해프닝도 있었고, 생각보다 빠르게 끝났다. 경험한 것 그대로 적는다.

fire-your-seo-agency 스킬이 뭔데? 5가지를 한 번에 본다는 게 무슨 뜻일까?

이 스킬의 이름을 처음 봤을 때 “SEO 대행사를 해고해라”라는 뜻이라는 걸 바로 알아챘다. 이름부터 꽤 직설적이다.

설치하고 싶었던 이유는 단순했다. 이 스킬 하나가 아래 다섯 가지를 한꺼번에 진단하고 고쳐준다고 했기 때문이다.
- SEO(Search Engine Optimization, 검색엔진 최적화) — 구글 같은 검색엔진에 잘 노출되도록 글과 구조를 다듬는 작업
- AEO(Answer Engine Optimization, 답변엔진 최적화) , 검색 결과에서 바로 답변으로 뜨도록 최적화하는 방식
- GEO(Generative Engine Optimization, 생성형 엔진 최적화) , ChatGPT 같은 AI가 답변할 때 내 콘텐츠를 인용하도록 최적화하는 방식
- LLMO(Large Language Model Optimization, 대형 언어모델 최적화) , AI 언어모델이 내 글을 더 잘 이해하고 활용하도록 다듬는 것
- 네이버 노출 , 네이버 검색에서 잘 걸리도록 최적화하는 작업
다섯 가지를 따로 따로 챙기려면 도구도 각각 써야 하고, 시간도 각각 든다. 그걸 스킬 하나로 묶어준다는 게 핵심이다. 궁금해서 바로 설치해달라고 했다.

‘말 안 해도 알아서 해줘’라고 한 이유, 반복 작업의 부담감

블로그를 운영하다 보면 신경 써야 할 게 한두 가지가 아니다. 글 쓰는 것 자체도 일인데, 그 글이 검색에 잘 뜨는지 확인하고, 제목 태그는 맞는지, 메타 설명(meta description, 검색 결과에서 제목 아래 뜨는 짧은 요약 글)은 채워져 있는지까지 매번 챙기는 건 솔직히 귀찮다.

“SEO 해줘”라고 매번 말하는 것도 결국 반복이다. 한 번 설치해뒀으면 글을 올릴 때마다 자동으로 챙겨주는 게 맞다고 생각했다. 그래서 처음부터 “말 안 해도 알아서 적용해줘”라고 정리해서 요청했다.

이게 게으른 건지 효율적인 건지는 모르겠다. 다만 반복 작업에 쓰는 시간을 줄이고 싶었던 건 사실이다.

1개 블로그가 아닌 4개 블로그 전부에 적용한 이유

블로그가 4개다. 주제가 각각 다르고, 독립적으로 운영하고 있다.

처음엔 테스트 삼아 하나만 적용할까도 생각했다. 근데 금방 판단을 바꿨다. 하나만 적용하면 나머지 세 개는 결국 나중에 또 따로 손을 봐야 한다. 그건 지금 귀찮음을 미루는 것뿐이다.

이왕 하는 거 다 적용하는 게 나중에 편하다. “다 적용해줘”라고 한 줄로 정리했다. 결과적으로 이 판단은 맞았다.

파일이 3번 중복으로 받아진 문제

스킬을 설치하는 과정에서 이상한 일이 있었다. 다운로드 폴더(컴퓨터에서 파일이 저장되는 기본 폴더)를 열어보니 같은 파일이 세 개 들어 있었다.

이건 좀 웃겼다.

위 화면처럼 동일한 파일명으로 세 개가 나란히 쌓여 있었다. 왜 세 번이나 받아진 건지 정확한 원인은 파악하지 못했다. 버튼을 여러 번 눌렀을 수도 있고, Claude Code 쪽에서 재시도(retry, 실패했을 때 다시 시도하는 것)가 반복됐을 수도 있다.

실제로 문제가 생긴 건 아니었다. 중복 파일 두 개를 지우고 하나만 남겨서 진행하면 된다. 다만 초보자라면 “세 개 중 어느 게 제대로 된 파일이지?”라고 헷갈릴 수 있다.

이 상황에서 원칙은 하나다. 파일 내용이 동일하다면 어느 것을 써도 상관없다. 파일명이 똑같고 용량도 같다면 중복이다. 두 개는 지워라.

초보 개발자도 따라 할 수 있는 자동 적용 순서

실제로 내가 진행한 순서를 기준으로 정리한다. 인터뷰에서 확인된 내용만 적는다.
1. Claude Code에서 fire-your-seo-agency 스킬을 설치 요청한다.
2. 다운로드 폴더를 열어 파일이 정상적으로 받아졌는지 확인한다.
3. 중복 파일이 있다면 하나만 남기고 나머지는 삭제한다.
4. 적용할 블로그가 여러 개라면 처음부터 “전부 다 적용해줘”라고 명시한다.
5. “매번 말 안 해도 자동으로 적용해줘”라고 한 번에 요청한다.
주의할 점이 있다.
- 블로그가 여러 개라면 각각의 이름이나 URL(인터넷 주소)을 미리 정리해서 한 번에 넘겨야 한다. 하나씩 따로 말하면 결국 반복이다.
- 중복 파일은 반드시 정리하고 넘어가야 한다. 그냥 두면 나중에 어느 파일이 실제로 적용된 건지 추적하기 어려워진다.
- “알아서 해줘”라고 했다고 해서 완전히 손을 놓으면 안 된다. 처음 한 번은 결과를 직접 확인해야 한다.
지금까지 실제로 바뀐 것들

지금 시점에서 바뀐 건 이거다. 스킬이 설치됐고, “말 안 해도 알아서 적용해줘”라는 규칙이 4개 블로그 전부에 걸렸다. 매번 “SEO 해줘”라고 말할 필요가 없어진 것 자체가 편하다.

다섯 가지를 따로 챙기지 않아도 된다는 것도 실질적인 변화다. 특히 GEO나 LLMO는 따로 도구를 찾아서 적용하기가 까다로운 영역인데, 스킬 하나로 묶여서 처리되는 건 낫다.

다만 한 가지는 분명히 짚고 넘어간다. 규칙을 걸어놨다고 해서 검색 순위가 바로 오르는 건 아니다. 이제부터 블로그 작업을 할 때마다 배경에서 진단·수정이 돌아가는 거고, 실제로 검색에 노출되는 결과는 시간이 걸린다. 이걸 착각하면 나중에 실망한다.

지금은 규칙을 걸어놓은 상태로 각 블로그에 글을 계속 올리면서 변화를 지켜보는 중이다. 수치로 확인할 수 있는 변화가 생기면 그때 다시 정리할 생각이다.

이 문제는 워드프레스 SEO 버그 5개 총정리 글에도 다른 4개 사례와 함께 정리해뒀다.
2026년 09월 16일

랭크매스 SEO 16점→76점, API 함정 피하고 올린 과정

처음 랭크매스 점수를 확인했을 때 16점이 떴다. 대표 이미지도 넣었고, 카테고리도 설정했다. 뭘 더 해야 하는지 몰랐다.

다 설정했는데도 랭크매스 점수가 16점에서 안 움직인 이유

이상했다. 분명히 다 채웠는데 점수가 꼼짝을 안 했다. 처음엔 랭크매스 플러그인(워드프레스에 설치해서 SEO를 관리하는 도구) 자체 문제인가 싶었다.

원인은 다른 데 있었다. API(Application Programming Interface, 프로그램끼리 데이터를 주고받는 통로)로 포커스 키워드(검색엔진에 “이 글은 이 단어에 집중합니다”라고 알려주는 핵심 단어)를 설정했는데, 그게 실제 랭크매스 에디터(글을 작성하고 편집하는 화면) 화면에는 반영이 안 되고 있었다. 코드로는 값을 넣었다. 근데 랭크매스는 그걸 모르는 상태였다.

겉으로는 다 설정된 것처럼 보였다. 실제 점수는 그대로였다. 이 두 가지가 동시에 사실이었다.

API로 설정한 SEO 정보, 실제로는 먹히지 않는다?

먹히지 않는다. 적어도 랭크매스 점수 계산에는.

Claude Code 같은 AI 도구로 워드프레스 API를 통해 글을 발행할 때, SEO 관련 메타(meta, 글의 제목·설명·키워드 같은 부가 정보) 값을 함께 넣을 수 있다. 기술적으로는 데이터가 전달된다. 문제는 랭크매스가 점수를 다시 계산하지 않는다는 거다.

wp-admin(워드프레스 관리자 페이지) 에디터를 직접 열어보지 않으면 이걸 알 방법이 없다. 포커스 키워드 입력란이 비어 있다. 점수는 16점. API로 아무리 잘 넣어도 랭크매스 입장에선 설정 안 된 상태다.

이거 모르고 그냥 발행했으면 SEO 점수가 낮은 채로 글이 올라갈 뻔했다. 실제로 그럴 뻔했다.

위 화면이 그 상태다. API로 다 넣었다고 생각했는데, 에디터에서 확인하면 포커스 키워드 칸이 비어 있고 점수는 16점 그대로다.

에디터에서 포커스 키워드를 직접 입력했을 때 점수가 폭발한 이유

wp-admin에서 해당 글을 열었다. 랭크매스 패널(화면 한쪽에 붙어 있는 설정 영역)을 찾아서 포커스 키워드를 직접 손으로 입력했다. 저장했다.

16점에서 57점이 됐다.

한 단어 입력이 41점을 올렸다. 이게 왜 가능하냐면, 랭크매스는 포커스 키워드를 기준으로 점수를 계산하기 때문이다. 키워드가 없으면 제목에 키워드가 있는지, 본문에 키워드가 있는지 아무것도 판단을 못 한다. 기준이 생기자마자 이미 작성된 글의 내용들이 한꺼번에 점수에 반영된 거다.

API 설정이 쓸모없다는 게 아니다. 랭크매스 점수 계산만큼은 에디터 직접 입력이 기준이라는 거다. 이 차이를 모르면 계속 헤맨다.

57점에서 76점까지, 하나씩 고쳐가며 올린 체크리스트

57점에서 멈추지 않았다. 뭘 더 고쳐야 하는지 랭크매스가 항목별로 알려준다. 하나씩 고쳤다. 찔끔찔끔 올랐다. 이 과정이 은근히 나쁘지 않았다. 뭘 고쳤을 때 점수가 오르는지 직접 눈으로 보니까.

SEO 제목(검색 결과에 표시되는 글 제목)에 포커스 키워드 포함 — 제목 앞쪽에 키워드가 있어야 한다.
메타 설명(검색 결과에서 제목 아래 뜨는 짧은 소개글)에 키워드 포함 , 키워드가 자연스럽게 들어가야 한다. 억지로 끼워 넣는 느낌이면 별로다.
본문 시작 부분에 키워드 포함 , 글 앞쪽 한두 문단 안에 키워드가 나와야 한다.
소제목(h2, h3 태그로 표시되는 중간 제목)에 키워드 포함 , 모든 소제목에 다 넣을 필요는 없다. 한두 군데면 된다.
내부 링크(같은 사이트 안의 다른 글로 연결하는 링크) 1개 추가
외부 링크(다른 사이트로 연결하는 링크) 1개 추가

이 여섯 가지를 순서대로 적용했다. 76점까지 올랐다. 한 번에 다 한 게 아니라, 하나 고치고 저장하고 점수 확인하고, 다시 고치는 식으로 진행했다.

완벽한 100점을 목표로 하지 않아도 된다. 랭크매스 기준으로 70점 이상이면 초록색으로 바뀐다. 76점이면 충분하다.

API vs 에디터 직접 설정의 차이와 확인 방법

정리하면 이렇다.

구분	API 설정	에디터 직접 설정
데이터 저장	된다	된다
랭크매스 점수 반영	안 된다	된다
포커스 키워드 인식	안 된다	된다
확인 방법	wp-admin 에디터 열어봐야 앎	저장하면 바로 점수 업데이트

확인 방법은 하나다. wp-admin에서 해당 글의 편집 화면을 직접 열어라. 랭크매스 패널이 보이면 포커스 키워드 칸이 채워져 있는지 확인해라. 비어 있으면 API 설정은 점수에 아무 영향이 없는 상태다.

API로 글을 자동 발행하는 워크플로(작업 흐름)를 쓰고 있다면, 발행 후에 반드시 wp-admin에서 한 번 더 열어서 SEO 설정을 수동으로 확인해야 한다. 귀찮다. 근데 안 하면 낮은 점수로 그냥 올라간다.

자동화가 전부를 해결해주지는 않는다. 이번에 그걸 배웠다. 다음엔 발행 체크리스트에 “wp-admin SEO 확인” 항목을 아예 넣어둘 생각이다. 결국 랭크매스 점수 하나 때문에 발행 프로세스 자체를 다시 점검하게 됐다.

이 문제는 워드프레스 SEO 버그 5개 총정리 글에도 다른 4개 사례와 함께 정리해뒀다.

같은 랭크매스 주제로 이어서 읽으면 좋은 글: 랭크매스 포커스 키워드, wp.data로 직접 넣는 법, 랭크매스 무료 기능으로 고아 포스트 2개 찾아낸 이야기, 메타 설명 오류 , 색인됐는데 검색 안 되던 이유.

2026년 09월 12일

이미지가 삐져나가는 버그, 원인 찾고 자동화까지 한 후기
이미지가 삐져나가는 버그, 처음엔 그냥 넘어갈 뻔했다. 블로그 글을 올리고 나서 멀쩡히 보이는지 확인하는 건 습관이다. 그날도 그냥 훑어보고 있었다.

이미지가 삐져나가는 버그, 눈에 띄는 이상함: 스크린샷 하나가 삐져나가 보였던 이유

본문을 읽다가 뭔가 이상했다. 스크린샷 하나가 오른쪽으로 쏠려 있었다. 다른 이미지들은 멀쩡한데 그것만.

이유는 몰랐다. 그냥 딱 봐도 어색했다. 바로 Claude Code(AI 기반 코딩 보조 도구)에 말했다. “지금 본문에서 이 이미지만 오른쪽으로 쏠려있어. 사이즈 조절해서 중앙으로 보기 좋게 다시 작성해줘.” 원인 분석보다 고치는 게 먼저였다.

아래가 당시 상태다. 텍스트 컬럼(column, 본문이 들어가는 세로 영역) 오른쪽으로 이미지가 넘쳐 있다.

이렇게 이미지가 본문 영역 밖으로 삐져나오면 레이아웃(layout, 화면 배치 구조) 전체가 깨진 것처럼 보인다. 작은 것 같지만 실제로 읽는 사람 입장에서는 바로 티가 난다.

원인은 간단했다: 업로드 스크립트가 이미지를 줄이지 않고 있었네

원인은 허무했다. 업로드 스크립트(script, 특정 작업을 자동으로 처리하는 코드 파일)가 이미지를 그대로 박아넣고 있었다. 리사이즈(resize, 이미지 크기를 줄이거나 늘리는 작업) 없이. 원본 그대로.

원본 이미지의 가로 크기가 본문 컬럼 폭보다 훨씬 넓었다. 그러니 오른쪽으로 넘칠 수밖에 없다. 알고 나니 별거 아니었다. 근데 이게 지금까지 계속 이렇게 올라가고 있었다는 게 더 문제였다.

이 버그(bug, 코드나 프로그램에서 발생하는 오류) 자체는 금방 고칠 수 있다. 문제는 따로 있다.

버그 수정만으로는 부족한 이유: 같은 실수가 반복되면?

지금 이 이미지만 고치고 끝내면 어떻게 될까. 다음에 글 올릴 때 또 같은 일이 생긴다. 스크립트가 그대로니까.

버그를 발견했을 때 그 버그만 패치하고 넘어가는 건 임시방편이다. 원인이 코드 안에 남아 있으면 같은 실수는 반드시 다시 나온다. 타이밍만 다를 뿐이다.

그래서 바로 한 마디 더 붙였다. “처음부터 작성할 때 이런 것 체크해서 최종 마무리해줘.” 재발 방지까지 해야 진짜 끝난 거라고 생각했다.

자동화로 근본 해결하기: 스크립트에 리사이즈 기능 추가하기

수정 방향은 하나였다. 업로드 스크립트 자체를 고치는 것.

이미지를 올릴 때마다 수동으로 크기를 확인하는 건 지속 가능하지 않다. 귀찮으면 빠뜨리게 돼 있다. 그러니 스크립트가 알아서 처리하게 만드는 게 맞다.

Claude Code에 요청해서 업로드 스크립트를 수정했다. 핵심은 두 가지다.
- 새 글을 올릴 때 이미지가 자동으로 본문 폭에 맞게 리사이즈된다.
- 리사이즈된 이미지는 중앙 정렬로 삽입된다.
이제 이미지 크기를 신경 쓰지 않아도 된다. 스크립트가 처리한다. 이게 자동화(automation, 사람이 직접 하던 작업을 코드가 대신 처리하도록 만드는 것)의 의미다. 한 번 제대로 만들어두면 그 다음부터는 신경 끄면 된다.

재발 방지까지: 업로드 후 최종 확인 프로세스 정하기

스크립트를 고치는 것만으로는 완전하지 않다고 봤다. 코드가 제대로 동작하는지 눈으로 확인하는 단계가 없으면 또 다른 문제가 조용히 지나갈 수 있다.

그래서 규칙을 명확히 정했다. Claude Code에 이렇게 못 박았다.
- 이미지는 본문 폭 안에 딱 맞게, 중앙 정렬로 들어가야 한다.
- 업로드 후에는 Claude Code가 직접 최종 확인을 하고, 그 결과를 나한테 컨펌받아야 한다.
- 스크린샷으로 실제 화면을 직접 확인하는 것을 기본으로 한다.
코드만 고치고 “됐겠지” 하고 넘어가지 않는다. 반드시 눈으로 확인한다. 이게 기준이다.

이 사례에서 배울 점: 코드만 고치지 말고 프로세스도 함께

이번 건 작은 버그였다. 이미지 하나가 삐져나간 것. 근데 거기서 멈추지 않은 게 핵심이다.

버그를 고치는 건 시작이다. 왜 생겼는지 파악하고, 같은 일이 반복되지 않도록 구조를 바꾸고, 확인 단계까지 만드는 것이 진짜 마무리다.

AI 도구를 쓸 때 “고쳐줘”만 하고 끝내는 사람이 많다. 그러면 똑같은 질문을 다음 달에 또 하게 된다. “왜 또 이러지?” 하면서.

물어봐야 할 건 두 가지다.
- 지금 이걸 어떻게 고치냐.
- 앞으로 이게 안 생기려면 뭘 바꿔야 하냐.
두 번째 질문을 안 하면 첫 번째 질문을 계속 반복한다.

다음에는 업로드 스크립트 전체를 한 번 훑어볼 생각이다. 이미지 말고 다른 곳에서도 비슷한 게 조용히 지나가고 있을 수 있다. 결국 이미지가 삐져나가는 버그 하나가 전체 업로드 파이프라인을 점검하게 만든 셈이다.

비슷한 패턴은 다른 데서도 반복됐다. WPCode로 보안 헤더 추가하다 코드가 깨진 사례도 결국 같은 교훈이었다 , 자동화 도구를 만들 땐 “일단 되는 것”과 “제대로 확인된 것”은 다르다.

같은 워드프레스 주제로 이어서 읽으면 좋은 글: 대표 이미지가 잘리는 이유 , 템플릿 비율 3:2→16:9 차이, 워드프레스 SEO 버그 5개, curl로 찾은 공통 원인.

좌표 값 하나를 잘못 잡아서 생긴 다른 버그는 자막이 카드 텍스트와 겹쳤다, y=h*0.8로 좌표 하나 바꿔 고친 이야기에도 정리했다.
2026년 09월 09일
Claude Code로 UI 재설계하면서 배운 AI 협업 꿀팁과 함정
Claude Code 사용법을 실전에서 익혔다. Claude Code로 블로그 UI를 처음 손봤다. 홈 화면 재설계, 스크롤 목차, 로봇 로고 브랜딩까지 한꺼번에 작업했다. 빠르지 않았다. 하지만 혼자 했으면 못 끝냈을 작업을 끝냈다.

Claude Code 사용법, UI를 직접 만들어보니 어땠나?

Claude Code는 AI(인공지능) 기반 코딩 도구다. 터미널(terminal, 텍스트로 컴퓨터에 명령을 내리는 창)에서 명령어를 치면, AI가 코드를 직접 읽고 수정하고 실행까지 해준다. 에디터(editor, 코드를 작성하는 프로그램)를 오가며 복사 붙여넣기 할 필요가 없다.

이번에 작업한 항목은 세 가지였다. 홈 화면 레이아웃(layout, 화면 구성 방식) 재설계, 글 목록을 따라다니는 스크롤 목차, 그리고 블로그 로고 교체. 규모가 작지 않았다.

재설계를 마친 지금 홈 화면이다. 글 목록이 카드 그리드로 정리됐다.

처음엔 속도가 붙는 느낌이었다. “홈 화면 카드 간격 늘려줘”, “목차 위치 고정해줘” 같은 말만 해도 AI가 코드를 찾아서 고쳐줬다. 근데 작업이 길어질수록 문제가 생기기 시작했다.

텍스트 안 보임, 위치 계산 오류… 실제로 마주친 버그들

제일 시간을 잡아먹은 버그는 두 가지였다. 텍스트가 안 보이는 문제, 그리고 요소(element, 화면을 구성하는 개별 블록) 위치 계산 오류.

텍스트가 안 보이는 건 CSS(Cascading Style Sheets, 화면의 색상·크기·위치를 정하는 코드) 문제였다. 배경색이랑 글자색이 같아져버리는 식이다. 눈에 안 보이니까 버그인지도 한참 몰랐다. 위치 계산 오류는 더 번거로웠다. 스크롤 목차가 엉뚱한 곳에 붙거나, 화면 밖으로 튀어나갔다.

새로 만든 헤더다. 로봇 로고와 카테고리 메뉴가 나란히 붙었다.

이런 버그들은 Claude Code한테 증상을 설명하면 고쳐줬다. 완전히 못 고친 건 아니다. 다만 시간이 걸렸다. “텍스트가 안 보여”라고 말하면 원인을 찾고, 수정하고, 다시 확인하는 과정을 반복해야 했다. 빠른 척하지만 한 번에 되는 경우는 드물었다.

모르는 버그가 더 있을 수 있다는 것도 문제다. 눈에 보이는 버그는 고칠 수 있다. 눈에 안 보이는 버그는 존재 자체를 모른다.

AI가 기억을 못 하는 문제에 대처한 방법

이게 진짜 스트레스였다.

Claude Code는 대화 맥락이 길어지면 앞에서 한 말을 잊는다. 정확히는 잊는다기보다 우선순위가 밀린다. 내가 “이 스타일은 건드리지 마”라고 했어도, 나중에 다른 수정을 요청하면 그 스타일을 다시 바꿔놓는 경우가 생겼다.

더 황당한 경우도 있었다. 내가 특정 레퍼런스를 요청했는데, AI가 그걸 무시하고 자기가 찾은 걸 벤치마킹해버렸다. 내 요구사항이 아니라 AI가 판단한 방향으로 가버린 거다. 이건 버그인지 특성인지도 모르겠다.

글을 스크롤하면 옆에 목차가 따라다니고, 지금 읽고 있는 항목이 강조 표시된다.

그래서 이렇게 대처했다.
- 작업 단위를 작게 쪼개야 한다. 한 번에 많은 걸 요청하면 맥락이 흔들린다.
- 중요한 조건은 매 요청마다 반복해서 명시해야 한다. 한 번 말했다고 AI가 기억한다고 믿지 마라.
- AI가 자의적으로 바꾼 부분이 없는지 결과물을 꼭 직접 확인해야 한다. 확인 없이 넘어가면 나중에 더 꼬인다.
- 레퍼런스를 요청할 때는 URL(인터넷 주소)이나 구체적인 예시를 함께 줘야 한다. 막연하게 “이런 느낌으로”는 AI 마음대로 해석된다.
궁극적으로는 버그를 스스로 찾아서 고치는 AI를 원하는데, 지금 Claude Code는 거기까지는 못 간다. 내가 발견한 것만 고친다. 이 한계는 명확히 알고 써야 한다.

로봇 로고를 선택한 이유: AI 시대를 표현하다

로고를 바꿨다. 이전 로고 얘기는 길게 안 한다. 중요한 건 왜 로봇으로 바꿨냐는 거다.

지금이 AI 시대다. 이 블로그도 AI 도구를 활용하는 내용을 다룬다. 그걸 가장 직관적으로 보여주는 이미지가 로봇이라고 판단했다. 복잡한 이유는 없다.

최종적으로 정한 로봇 로고 아트웍이다.

스타일 방향은 Claude Code가 몇 가지 후보를 제안했고, 그중에서 로봇 아이콘을 직접 골랐다. AI 시대를 표현하는 데 제일 직관적인 이미지라고 판단했다. 지금 보니 잘 고른 것 같다.

로고 작업 자체는 다른 버그들에 비해 순탄했다. 방향이 명확하면 AI도 잘 따라온다. 방향이 흐릿할 때 문제가 생긴다.

완성 후 느낀 점: 완벽함보다는 계속된 개선이 정답

버그 때문에 시간은 오래 걸렸다. 하지만 완성은 했다.

완성된 걸 보고 “완벽하다”는 생각은 안 들었다. 완성인지 미완성인지도 솔직히 아직 모른다. 지금은 만족스럽다. 근데 계속 쓰다 보면 만족스럽지 못한 부분이 또 나올 거다. 그게 당연한 과정이다.

워드프레스에 등록된 로봇 파비콘이다. 브라우저 탭에 이렇게 뜬다.

지금은 계속 사용하면서 버그를 잡고 있다. 더 유용한 기능이나 플러그인이 있는지도 알아보는 중이다. Claude Code도 계속 쓰면서 어떻게 하면 더 잘 쓸 수 있는지 파악하고 있다.

AI 도구는 만능이 아니다. 기억을 못 하고, 자의적으로 판단하고, 눈에 안 보이는 버그는 그냥 둔다. 그걸 알고 쓰는 것과 모르고 쓰는 건 결과가 다르다. 다음 작업은 이번에 파악한 한계를 기준으로 접근할 생각이다.

워드프레스 템플릿을 직접 고친 다른 사례는 관련 글 카드로 바꾸다 만난 버그 3개, 워드프레스 템플릿 직접 수정기에도 있다.
2026년 09월 06일

초보 개발자

CLAUDE.md가 뭐고 왜 여러 개일까?

CLAUDE.md 정리 전 점검: 세 파일에서 나온 문제

CLAUDE.md 정리 중 만난 NotebookLM 지시 문제

CLAUDE.md 정리 첫 단계: 중복 찾는 쉘 명령어

CLAUDE.md 정리에서 없는 폴더 규칙 지우기

실제 안 쓰는 도구 지시는 지우기로 했다

ujinify 전용 CLAUDE.md를 새로 만든 이유

정리 후 나한테 달라진 점, 너도 확인해보는 방법

내 환경의 CLAUDE.md 정리 상태 확인하는 법

AI 에이전트 도구 7개, 먼저 검증했던 이유

이미 깔려있던 도구들 (claude-mem, find-skills, ponytail, graphify)

VibeSec을 안 깐 이유: 내 프로젝트 구조와 안 맞았다

Ruflo, OmniRoute가 과했던 이유

13만 개 별을 의심하고 다시 확인한 검증 과정

하나도 안 깐 게 오히려 정답인 이유

왜 그때그때 올리는 방식에 불만을 느꼈을까?

예약 발행 기능이 없다면 직접 만들어야 한다

–schedule 옵션을 추가한 과정

4개 글을 한 번에 처리하려면 기준을 낮춰야 현실적이다

실제로 예약 발행을 돌려본 결과

fire-your-seo-agency 스킬이 뭔데? 5가지를 한 번에 본다는 게 무슨 뜻일까?

‘말 안 해도 알아서 해줘’라고 한 이유, 반복 작업의 부담감

1개 블로그가 아닌 4개 블로그 전부에 적용한 이유

파일이 3번 중복으로 받아진 문제