셸 스크립트에서 MCP 서버까지: SEO가 내 뇌를 (긍정적인 의미로) 망가뜨린 과정
요약
20년 경력의 SEO 전문가가 단순 스크립트 자동화에서 LLM 기반의 행동 사양 설계로 전환하며 겪은 경험담입니다. Claude Code와 Cursor를 활용한 '바이브 코딩'을 통해 프로토타이핑 효율을 높이는 방법과 주의점을 다룹니다.
핵심 포인트
- 단순 자동 완성을 넘어 신뢰할 수 있는 행동 사양 설계가 중요함
- Vibe coding은 빈 페이지 문제를 해결하는 강력한 프로토타이핑 도구임
- 생성된 코드를 반드시 이해해야 기술 부채를 방지할 수 있음
- AI 도구를 활용해 스켈레톤 코드를 빠르게 생성하고 반복 개선함
저는 20년 동안 기술적 SEO (Technical SEO)를 수행해 왔습니다. 저의 첫 번째 "자동화"는 제 사이트가 인덱싱되었는지 확인하기 위해 매시간 Google에 핑을 보내는 셸 스크립트 (shell script)였습니다. 우리는 정말 먼 길을 걸어왔습니다.
지난 20년 중 대부분의 시간 동안 자동화는 한 가지를 의미했습니다: 바로 Python입니다. 스크래퍼 (Scrapers), 크롤러 (crawlers), 로그 분석기 (log analyzers), 대량 콘텐츠 파이프라인 (bulk content pipelines) 등이 그것이었죠. 저는 반복적인 작업이 있다면 스크립트를 작성한다는 생각에 익숙해져 있었습니다. 배포하고, 잊어버리고, 다음 단계로 넘어가는 식이었죠.
그러다 2년 전, 그 모델이 완전히 깨져버렸습니다.
아무도 말해주지 않는 프롬프트 엔지니어링 (Prompt Engineering)의 진실
LLM (Large Language Models)이 실제 업무에 유용할 정도로 성능이 좋아졌을 때, 저의 첫 번째 본능은 그것들을 화려한 자동 완성 (autocomplete) 기능으로 사용하는 것이었습니다. 더 나은 키워드 조사, 더 빠른 콘텐츠 브리프 (content briefs), 더 스마트한 메타 설명 (meta description) 생성 같은 것들 말이죠.
그 단계는 약 3개월 동안 지속되었습니다.
변화는 제가 "AI를 무엇에 사용할 수 있을까"라고 묻는 것을 멈추고, "좋은 AI 지시 시스템 (instruction system)은 어떤 모습일까"라고 묻기 시작했을 때 일어났습니다. 그 질문은 완전히 달랐으며, 저를 소프트웨어 엔지니어링 (software engineering)과 매우 유사한 무언가로 다시 끌어들였습니다.
다만 함수 (functions)를 작성하는 대신, 저는 "행동 사양 (behavior specifications)"을 작성하고 있었습니다.
# 나쁜 프롬프트 (자동 완성 방식의 사고)
"산업용 펌프에 관한 페이지를 위한 타이틀 태그 10개를 작성해줘"
...
차이점은 단순히 스타일의 문제가 아닙니다. 두 번째 방식은 "신뢰할 수 있습니다 (reliable)". 500개의 페이지에 대해 실행해도 일관되고 실행 가능한 결과물을 얻을 수 있습니다. 반면 첫 번째 방식은 매번 다른 결과를 내놓습니다.
바이브 코딩 (Vibe coding)이 나의 프로토타이핑 방식을 바꾸다
여기서부터 이상해집니다. 제가 프롬프트 엔지니어링 (prompt engineering)에 진지해지기 시작했을 무렵, 실제 Python 작업을 위해 Claude Code와 Cursor를 사용하기 시작했습니다.
저는 뛰어난 개발자는 아닙니다. 하지만 적당히 괜찮은 개발자입니다. 코드를 읽고, 무엇을 하는지 이해하며, 명백한 오류를 수정할 수는 있지만, 아직 중요하지 않은 결정에 너무 많은 시간을 소비하지 않고 처음부터 무언가를 설계(architect)하는 데는 어려움을 겪는 그런 종류의 개발자 말이죠.
Vibe coding (바이브 코딩)이 저의 문제를 해결해 주었습니다. AI가 완벽한 코드를 작성하기 때문이 아니라 (실제로 그렇지 않습니다), 빈 페이지 문제 (blank page problem)를 제거해 주기 때문입니다.
현재 저의 워크플로우는 다음과 같습니다:
- 만들고 싶은 것을 일상적인 언어로 설명합니다.
- 몇 분 안에 작동하는 스켈레톤 (skeleton) 코드를 얻습니다.
- 코드를 건드리기 전에 무엇이 만들어졌는지 실제로 이해합니다.
- 아무것도 없는 상태가 아니라, 실체가 있는 무언가로부터 반복 (iterate)합니다.
이해하는 단계는 타협할 수 없는 필수 사항입니다. 저는 사람들이 생성된 내용을 읽기 위해 멈추지 않음으로써, 스스로 유지보수할 수 없는 코드베이스로 빠져드는 바이브 코딩 (vibe-code) 사례를 보았습니다. 그것은 자동화가 아니라, 단계만 더 추가된 기술 부채 (technical debt)일 뿐입니다.
두 가지 요소가 충돌했을 때
6개월 전, 저는 특정한 문제를 해결하려고 노력 중이었습니다. UI/UX 작업(랜딩 페이지, SaaS 앱 레이아웃, 디자인 감사)을 돕기 위해 AI 에이전트 (AI agent)를 사용할 때마다, 항상 똑같이 밋밋한 결과물만 생성된다는 점이었습니다. 중앙 정렬된 히어로 섹션, 보라색에서 인디고로 이어지는 그라데이션, 일반적인 카드 그리드. AI의 "안전한 선택 (safe choices)" 문제였습니다.
저의 SEO 뇌는 이렇게 말했습니다. 이것은 능력의 문제가 아니라 규칙의 문제다.
모델은 좋은 디자인이 무엇인지 알고 있습니다. 다만 제 맥락 (context)에 적용할 일관된 프레임워크 (framework)가 없을 뿐입니다.
그래서 저는 직접 만들었습니다. 모든 디자인 관련 작업에 주입할 일련의 디자인 규칙, 청사진 (blueprints), 그리고 산업별 가이드라인을 구축했습니다. OKLCH 색상, 적절한 모션/반응 패턴, 산업군별 금지 패턴(B2B SaaS, 헬스 플랫폼, 이커머스 사이트 각각 다른 규칙 적용) 등을 포함했습니다.
그 후, 어떤 AI 도구라도 사용할 수 있도록 이를 제대로 된 MCP 서버 (MCP server)로 만들었습니다:
# 이제 어떤 에이전트든 다음을 호출할 수 있습니다:
get_sector_context("b2b-products")
# → 필요한 신뢰 신호(trust signals), 금지 패턴, 전환 요소(conversion elements)를 반환
...
그 결과물이 바로 global-design-skill 입니다.
— Claude Code, Cursor, Copilot, 그리고 Windsurf를 위한 오픈 소스 디자인 OS입니다. 이 도구는 귀하의 비즈니스 섹터를 자동으로 감지하고, 적절한 규칙을 적용하며, 사용하면 사용할수록 귀하의 피드백에 맞춰 더욱 정교하게 조정(calibrate)됩니다. 모든 과정은 로컬 (local)에서 이루어지며, 텔레메트리 (telemetry)는 없습니다.
20년 동안의 SEO가 AI 시스템에 대해 실제로 가르쳐준 것
돌이켜보면, SEO는 언제나 _제약된 최적화 (constrained optimization)_에 관한 것이었습니다. 알고리즘을 제어할 수는 없으므로, 제어할 수 있는 모든 것을 제어하는 것이죠. 구조 (Structure). 신호 (Signals). 맥락 (Context). 일관성 (Consistency).
프롬프트 엔지니어링 (Prompt engineering)은 다른 시스템에 적용된 동일한 규율입니다. 모델이 무엇을 알고 있는지는 제어할 수 없지만, 다음은 제어할 수 있습니다:
- 프레임 (The frame) — 모델이 어떤 역할을 수행하는지, 어떤 규칙이 적용되는지
- 맥락 (The context) — 당신의 구체적인 상황에 대해 모델이 무엇을 알고 있는지
- 출력 형식 (The output format) — 구조적으로 좋은 답변이 어떤 모습인지
- 실패 모드 (The failure mode) — 모델이 모르는 내용에 대해 무엇이라고 말해야 하는지
제 경험상, 이 분야에서 가장 뛰어난 사람들은 반드시 훌륭한 코더나 훌륭한 작가는 아닙니다. 그들은 _시스템적 사고 (thinking in systems)_에 능숙한 사람들입니다. 즉, 입력값 (inputs), 프로세스 (process), 그리고 기대되는 출력값 (expected outputs)을 명시하고 반복 (iterate)할 수 있는 무언가로 바라보는 사람들입니다.
그것은 제가 깨닫지 못하는 사이에 SEO가 제 안에 구축해 준 기술입니다.
다음 단계
저는 현재 다음과 같은 것들에 대해 많이 배우고 있습니다:
- MCP 서버 설계 (MCP server design) — 무엇이 AI 에이전트 (AI agents)를 위한 좋은 도구와 나쁜 도구를 가르는가
- 컨텍스트 윈도우 경제학 (Context window economics) — 최소한의 토큰 (tokens) 안에 어떻게 최대한의 유용한 신호를 채워 넣을 것인가
- 산업별 AI 행동 (Sector-specific AI behavior) — 동일한 작업이라도 산업군에 따라 정답이 완전히 달라지는 현상
만약 당신이 AI 툴링 (AI tooling), 자동화 (automation), 그리고 도메인 전문 지식 (domain expertise)의 교차점에서 일하고 있다면, 꼭 연락하고 싶습니다. 이 분야는 아직 매우 초기 단계여서 대부분의 흥미로운 문제들이 아직 해결되지 않았습니다.
당신의 도메인에 특화된 업무를 위해 AI 도구를 사용할 때, 당신의 워크플로 (workflow)는 어떠한가요? 도메인 맥락을 명시적으로 주입하시나요, 아니면 모델이 스스로 파악하도록 내버려 두시나요?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기