[AJECT 개발 일지] 홈페이지는 공개가 끝이 아니다 — 검색엔진 등록·SEO·WordPress 연동·콘텐츠 품질 검증까지

AJECT ENGINEERING JOURNAL · 2026.10.11

기업 홈페이지를 오픈한 순간부터 진짜 운영이 시작됩니다. 고객이 회사 이름을 검색해도 사이트가 나타나지 않는다면, 잘 만든 디자인과 기능이 잠재 고객에게 닿지 못합니다. 반대로 검색 결과에 노출되더라도 콘텐츠가 오래되거나 이미지가 깨져 있다면 전문성과 신뢰를 전달하기 어렵습니다. AJECT는 홈페이지 구축을 ‘화면 제작’이 아닌 검색 발견 → 콘텐츠 이해 → 방문 → 신뢰 → 문의 → 운영 개선으로 이어지는 전체 시스템의 문제로 접근했습니다.

2026년 10월 11일, 실제 운영 중인 AJECT와 PLUTUS WordPress를 연결하고 검색엔진 등록과 콘텐츠 품질 검증까지 단계적으로 진행했습니다. 이 글은 적용된 구조와 확인된 결과, 남아 있는 운영 과제를 구분한 기술 기록입니다.

1. 검색엔진 등록이 왜 중요한가: ‘웹에 존재’와 ‘검색에서 발견’은 다릅니다

웹사이트가 HTTPS로 열리는 것은 출발점입니다. 검색엔진이 해당 URL을 발견하고 크롤링할 수 있는지, 내용을 해석할 수 있는지, 색인할 가치가 있다고 판단하는지는 별개의 과정입니다. 검색엔진 최적화(SEO)는 특정 검색 순위를 보장하는 기술이 아니라, 검색 시스템이 사이트의 구조와 의미를 올바르게 이해하도록 만드는 기초 작업입니다.

중요: 사이트맵 제출과 URL 색인 요청은 검색엔진에 정보를 전달하는 수단이지, 색인·상위 노출을 보장하지 않습니다. AJECT는 등록과 크롤링 요청을 수행했으며 실제 색인 여부는 각 검색엔진 도구에서 지속 확인해야 합니다.

2. 운영 아키텍처: WordPress를 콘텐츠 원본으로, AJECT를 사용자 경험의 중심으로

기술 콘텐츠를 운영하기 위해 별도 편집 시스템을 중복 구축할 필요는 없습니다. 기존 PLUTUS WordPress를 콘텐츠 관리 시스템(CMS)으로 활용하고, AJECT의 Next.js 앱이 WordPress REST API에서 승인된 개발 콘텐츠를 읽어 자체 도메인에 표시하도록 설계했습니다.

이 구조는 외부 사이트로 단순히 이동시키는 링크 모음과 다릅니다. 기술 블로그의 목록과 본문이 AJECT 도메인 아래에서 제공되어 기업 사이트의 탐색 경험과 콘텐츠 브랜드를 일관되게 유지합니다. AJECT에는 WordPress의 ‘AI 개발 일지’ 카테고리(ID 340)만 연동해 금융 콘텐츠와 기술 콘텐츠의 성격도 분리했습니다.

실제 적용 기술 스택

3. 패치 기록: 실제 사용 경험과 검색엔진 친화성을 함께 개선하다

STEP 1 — 기술 블로그와 홈페이지 최신 글 연동

기술 블로그 목록과 개별 본문 페이지를 구축하고, 홈페이지 MEDIA 영역에 최신 게시글을 연결했습니다. WordPress에 기술 글을 발행하면 AJECT에서도 같은 콘텐츠를 확인할 수 있는 운영 흐름이 마련됐습니다.

STEP 2 — 제목·요약 검색과 정렬

방문자가 게시글을 쉽게 찾도록 실시간 검색과 최신순·오래된순 정렬을 추가했습니다. 기업 블로그는 글의 개수가 늘수록 ‘읽을거리의 양’보다 ‘필요한 정보를 발견하는 경험’이 중요해집니다.

STEP 3 — 검색엔진 기술 기반 구성

Next.js의 사이트맵과 robots.txt, 게시글별 SEO 메타데이터와 Article 구조화 데이터를 구성했습니다. 특히 기존 레이아웃에 있던 robots: { index: false, follow: false } 설정을 발견하고 공개 페이지가 색인 가능하도록 index: true, follow: true로 수정했습니다. 사이트맵이 존재하더라도 HTML에 noindex가 남아 있다면 색인 목표와 충돌할 수 있기 때문에 반드시 확인해야 하는 항목입니다.

STEP 4 — 기술 문서의 가독성 개선

글 상세 화면에서 제목 계층, 문단 간격, 표, 코드 블록, 이미지와 캡션의 표시 방식을 개선하고 관련 개발 스토리 영역을 추가했습니다. 긴 기술 문서를 읽는 사용자가 구조를 빠르게 파악하도록 하기 위한 작업입니다.

STEP 5 — 콘텐츠 품질 점검과 실제 장애 수정

공개된 기술 게시글 5개를 검사해 3개에서 검토 신호를 발견했습니다. 그중 AJECT 기술 사례 게시글(ID 1674)의 대표 이미지가 1×1픽셀이라는 실제 오류를 확인했습니다. WordPress 업로드 과정에서는 Nginx의 413 Request Entity Too Large 응답이 발생했고, 해당 HTTPS 서버 블록에 client_max_body_size 12m;를 설정해 요청 크기 제한을 조정했습니다. 이후 정상 크기의 인포그래픽을 업로드하고 대표 이미지를 미디어 ID 1675에서 1684로 교체했습니다. WordPress 재조회에서도 신규 대표 이미지 ID를 확인했습니다.

다른 두 게시글의 ‘본문 이미지 없음’은 자동으로 결함으로 판정하지 않았습니다. 본문 이미지가 필요 없는 글도 있기 때문입니다. 기계적 검사 결과를 사람의 맥락 판단과 결합하는 것이 품질 관리의 기본입니다.

4. Google Search Console 등록 절차: 도메인 확인부터 색인 검증까지

1. 사이트 속성 등록: Google Search Console에서 도메인 속성 또는 URL 접두어 속성을 등록합니다. 도메인 속성은 하위 도메인과 프로토콜을 폭넓게 포함하므로 관리 범위를 고려해 선택합니다.
2. 소유권 검증: 도메인 속성의 경우 안내된 DNS TXT 레코드를 DNS 관리 화면에 등록하고 검증합니다. DNS 전파로 반영에 시간이 걸릴 수 있습니다.
3. 크롤링 허용 확인: 공개 URL의 HTTP 200, HTML의 robots 메타데이터, robots.txt 규칙을 확인합니다. 비공개 관리자/API 경로는 별도로 보호해야 하며 robots.txt만으로 접근 통제가 되지는 않습니다.
4. 사이트맵 제출: https://aject.co.kr/sitemap.xml을 등록합니다. XML이 열리는지뿐 아니라 Search Console의 최종 처리 상태도 확인합니다.
5. URL 검사: 홈페이지와 주요 기술 글 URL을 검사하고 필요한 경우 색인 생성 요청을 제출합니다.
6. 운영 모니터링: 페이지 색인 보고서에서 발견·크롤링·색인 상태를 확인하고, 오류 또는 제외 사유를 검토합니다.

AJECT에서는 Google의 DNS 소유권 검증을 완료하고 홈페이지 URL의 실시간 검사에서 색인 가능 응답을 확인했습니다. 다만 이는 실제 검색 색인 완료나 검색 순위 확보를 의미하지 않습니다. 사이트맵 처리 상태와 최종 색인 여부는 후속 확인 대상입니다.

5. 네이버 서치어드바이저: 국내 고객을 위한 별도 등록 과정

국내 시장을 대상으로 하는 기업이라면 Google뿐 아니라 네이버 검색 수집 경로도 챙길 필요가 있습니다. 네이버 서치어드바이저에서 AJECT 사이트를 등록하고, 사이트맵을 제출했으며, 홈페이지·블로그 목록·주요 기술 글의 수집 요청을 진행했습니다.

1. 네이버 서치어드바이저에서 정확한 사이트 주소 https://aject.co.kr을 등록하고 소유권을 확인합니다.
2. https://aject.co.kr/robots.txt와 사이트맵 접근 상태를 점검합니다.
3. 사이트맵 메뉴에 sitemap.xml을 제출합니다.
4. 웹페이지 수집 요청 메뉴에서 홈페이지, 블로그 목록, 대표 게시글 URL을 제출합니다.
5. 요청 이력과 수집·색인 관련 진단을 추적합니다. 요청 접수는 검색 결과 노출 확정이 아닙니다.

특히 사이트 주소의 철자와 프로토콜을 정확히 확인해야 합니다. 등록 속성이 잘못되면 수집 상태를 엉뚱한 대상에서 점검하는 운영 실수가 발생할 수 있습니다.

6. SEO를 코드로 구현할 때 빠뜨리기 쉬운 체크포인트

향후 중요 과제 — 중복 콘텐츠 정책: AJECT가 WordPress의 글 전문을 자체 URL로 제공하므로 동일한 본문이 두 도메인에 존재할 수 있습니다. 검색엔진별 정규 URL 정책과 두 사이트의 콘텐츠 운영 목적을 검토해 canonical을 일관되게 관리해야 합니다. 이번 작업에서 이 정책이 최종 확정됐다고 주장하지 않습니다.

7. AJECT가 중요하게 생각하는 것은 ‘작동한다’ 다음 단계입니다

개발 중 오류는 언제든 발생합니다. 중요한 것은 오류를 숨기지 않고, 재현 가능한 기준으로 확인하며, 수정 후 실제 결과를 다시 검증하는 과정입니다. 이번 작업에서는 1×1픽셀 대표 이미지를 품질 검사로 찾아냈고, 서버 업로드 제한이라는 원인을 분리해 해결했습니다. 또한 다른 서비스가 의존하는 Node.js 환경을 변경하지 않고 AJECT 전용 런타임을 유지했으며, 빌드가 성공한 뒤에만 서비스 재시작을 진행했습니다.

AJECT가 지향하는 개발 원칙은 분명합니다. 사용자가 보는 화면, 검색엔진이 읽는 구조, 관리자가 운영하는 콘텐츠, 장애를 진단하는 도구까지 하나의 제품으로 책임지는 것. 기능 추가만큼이나 측정·검증·복구 가능성을 중요하게 다룹니다. 이것이 작은 기업 홈페이지에도 전문적인 엔지니어링이 필요한 이유입니다.

8. 다음 개선 로드맵

이번에 확인한 검색엔진 등록과 기술 블로그 운영 기반 위에 세 가지를 더 강화할 예정입니다. 첫째, Search Console과 네이버의 실제 수집·색인 상태를 주기적으로 점검합니다. 둘째, WordPress 발행 파이프라인에 대표 이미지 해상도와 본문 품질의 사전 검증을 추가합니다. 셋째, AJECT와 원본 WordPress 사이의 정규 URL 및 메타데이터 정책을 정리해 검색엔진이 콘텐츠 출처를 일관되게 해석하도록 개선합니다. 이는 계획 단계이며 적용 완료 항목과 구분합니다.

공식 참고 문서

• Google Search Central — SEO Starter Guide
• Google Search Central — Sitemaps
• Google Search Central — Canonicalization
• 네이버 서치어드바이저
• Next.js — sitemap.xml
• WordPress REST API

작성 기준: 2026년 10월 11일. 운영 기록과 검증 결과를 기준으로 작성했으며 검색엔진 색인·순위는 보장되지 않습니다.