bananackck

이 글은 SEO를 이미 아는 개발자분들이 AI 시대에 어떻게 사용자를 유입할 것인가에 대한 글입니다.

GEO란?

예전에는 궁금한 것이 생기면 대부분 Google이나 네이버에서 검색했다.

예를 들어 “ISR과 SSR 차이”가 궁금하면 검색창에 키워드를 입력하고 여러 블로그를 읽으며 답을 찾았다.

하지만 요즘은 조금 다르다.

많은 사람들이 ChatGPT, Claude, Gemini 같은 AI에게 먼저 질문한다.

“ISR과 SSR의 차이가 뭐야?”

“React에서 Context API 대신 Zustand를 쓰는 이유는?”

“SSR은 언제 사용하는 게 좋아?”

AI는 검색 결과를 나열하지 않는다.

여러 문서를 읽고 하나의 답변으로 정리해서 알려준다.

즉, 앞으로는 검색 엔진뿐 아니라 생성형 AI에게도 선택받는 콘텐츠가 중요해지고 있다.

그래서 등장한 개념이 바로 GEO이다.

SEO와 GEO의 차이

둘 다 좋은 콘텐츠를 만드는 것이 목적이지만, 기준이 조금 다르다.

그렇다고 SEO가 필요 없어졌을까?

그건 아니다.

여전히 많은 사람들은 검색을 사용한다.

그리고 ChatGPT나 Gemini도 웹 검색 기능을 활용해 정보를 가져오는 경우가 많다.

즉,

SEO를 버리고 GEO를 선택하는 것이 아니라, SEO를 기반으로 GEO까지 고려해야 하는 시대가 된 것이다.

GEO 시대에는 글을 어떻게 써야 할까?

1. 결론부터 말하기

AI는 긴 글 전체를 인용하지 않고, 질문에 대한 핵심 정의를 먼저 찾는다.

ex)

❌ ISR은 Next.js에서 등장한 렌더링 전략으로…

✅ ISR은 정적 페이지를 일정 주기마다 다시 생성하는 Next.js의 렌더링 방식이다.

2. 비교표를 적극 활용하기

비교는 AI가 가장 활용하기 좋은 정보 중 하나다.

ex)

3. 질문을 제목으로 사용하기

AI도 결국 사용자의 질문에 답하는 것이 목적이기 때문에 질문 자체를 제목으로 사용하면 매칭률이 높다.

ex)

• ISR이란?
• SSR은 언제 사용할까?
• Context API 대신 Zustand를 사용하는 이유
• index.html이 URL에 노출되는 이유

4. 핵심 내용을 먼저 정리하기

AI는 글의 앞부분에서 핵심 내용을 빠르게 파악하고 넘어간다. 따라서 아래와 같은 정의가 먼저 나오는 것이 유리하다.

ex)

1. 한 줄 정의
2. 언제 사용하는가
3. 장점
4. 단점
5. 예시
6. 실무 경험

앞으로 내 블로그도 조금은 바뀔 것 같다.

지금까지는 검색 엔진을 많이 의식하며 글을 작성했다.

앞으로는 AI가 이 글을 읽는다면 어떤 질문의 답으로 활용할 수 있을까?도 함께 고민해 보려고 한다.

다만 방향 자체가 크게 달라지는 것은 아니다.

오히려 명확한 정의, 비교, 실무 경험을 더 강화하는 방향이 될 것 같다.

SEO가 끝난 것이 아니라, 좋은 글의 기준이 조금 더 명확해진 것일지도 모른다.

마무리

앞으로 개발 블로그는 이제 코드보다 의사결정 과정을 더 많이 기록해야 하지 않을까?

예를 들어 단순히 “ISR을 적용했다”보다 왜 ISR을 선택했고, SSR을 선택하지 않은 이유는 무엇이었는지를 함께 적는 글이 AI를 타겟한다면 더 큰 가치를 가질 것 같다.

출처: https://news.hada.io/topic?id=31476

오랜만입니다!! 그 동안 바쁘다는...(정신적 여유를 가지기 힘들었다는....) 핑계를 대며 염치없이 돌아왔습니다 ㅎㅎ

SQL을 다시 공부하며 일주일 동안 정리한 내용을 공유합니다.

MySQL 8.0을 기준으로 기본 문법부터 코딩테스트에서 자주 쓰이는 개념과 예제를 정리했습니다.

같은 내용을 공부하는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

다들 화이팅!

📚 SQL 정리 노트

https://bananackck.notion.site/SQL-38bcf2b6ab9380c38179ef781866fd94

웹사이트를 탐색하다 보면 어떤 사이트는 URL이 /로 깔끔하게 끝나는 반면, 어떤 사이트는 /index.html이 그대로 노출되는 경우가 있다. 처음에는 단순히 "안 이쁘다"는 느낌을 받을 수 있지만, 이는 디자인 문제가 아니라 서버 설정과 배포 방식의 차이에서 비롯된 현상이다.

기본 개념: index.html은 웹의 시작점이다

웹 서버는 특정 경로로 요청이 들어왔을 때 기본적으로 보여줄 파일을 정해두는데, 일반적으로 index.html이 그 역할을 한다. 따라서 아래 두 요청은 사실상 같은 의미다.

• / → 내부적으로 index.html을 찾아 응답
• /index.html → 명시적으로 해당 파일 요청

다만 대부분의 서버는 URL을 깔끔하게 유지하기 위해 index.html을 숨겨준다.

왜 어떤 사이트는 index.html이 그대로 보일까

1. 정적 파일만 업로드한 경우

S3, Object Storage, 단순 서버 등에 HTML 파일을 그대로 업로드한 경우다. 이때 서버는 디렉터리의 “기본 문서”를 인식하지 못할 수 있다. 결과적으로 다음과 같이 동작한다.

• / → 어떤 파일을 보여줄지 모름 (에러 가능)
• /index.html → 명확한 파일 요청이므로 정상 응답

즉, 파일명을 직접 URL에 포함해야 접근 가능한 구조다.

2. 라우팅이 없는 순수 HTML 구조

프레임워크 없이 HTML 파일로만 구성된 사이트도 같은 특징을 가진다. 예를 들어 다음과 같다.

• /about.html → 접근 가능
• /about → 접근 불가

이 경우 URL은 곧 파일 경로이기 때문에 index.html이 그대로 노출된다.

index.html이 안 보이는 사이트의 차이

1. 서버의 기본 문서 설정

Nginx나 Apache 같은 서버는 “이 경로에는 index.html을 기본으로 보여줘라”라는 설정을 할 수 있다.

예시:

location / {
  try_files $uri $uri/ /index.html;
}

이 설정이 있으면 /로 접근해도 자동으로 index.html이 응답되며, URL에는 노출되지 않는다.

2. SPA 구조 (React, Vue 등)

SPA에서는 모든 요청이 하나의 HTML 파일로 처리된다. 예를 들어 /, /about, /career와 같은 모든 요청이 실제로는 index.html을 반환하고, 이후 화면 전환은 JavaScript가 처리한다. 즉, URL은 다양하지만 서버 입장에서는 단일 진입점 구조다.

핵심 정리

• index.html이 보인다 → 서버 설정이 단순하거나 정적 파일 구조
• index.html이 안 보인다 → 서버가 기본 문서 또는 라우팅을 처리

결국 URL의 형태는 “프론트 코드”가 아니라 서버와 배포 방식이 어떻게 구성되어 있는지의 결과다.

이 글은 SSR과 ISR의 차이와 개발 경험에 대해 다룬 글입니다.

Next.js를 공부하다 SSR(Server Side Rendering)과 ISR(Incremental Static Regeneration)에 대해 알게되었다. 특히 ISR을 처음 알게 되었을 때 “SSR보다 더 발전한 기술 아닌가?”, “그럼 앞으로는 SSR 대신 ISR만 쓰면 되는 것 아닌가?“라는 생각이 들기도 했다. 무거운 SSR보다 트리거에 맞게 업데이트 하고 정적페이지로 SEO도 챙길 수 있으니까.

하지만 실제 프로젝트에서 둘을 적용해보니 생각이 달라졌다. 결론부터 말하면 ISR은 SSR의 상위호환이 아니다. 둘은 서로 경쟁하는 기술이 아니라, 해결하려는 문제가 다른 기술이다.

SSR이란?

SSR은 사용자가 페이지를 요청할 때마다 서버에서 HTML을 생성하여 반환하는 방식이다.

사용자 요청 → 서버에서 데이터 조회 → HTML 생성 → 브라우저 전달

장점

1. 항상 최신 데이터를 보여줄 수 있다.

사용자가 페이지를 요청하는 시점에 데이터를 가져오기 때문에 데이터가 변경되면 즉시 반영된다.

예를 들어 다음과 같은 서비스에 적합하다.

• 실시간 주식 정보
• 관리자 대시보드
• 개인화된 마이페이지
• 주문 현황 페이지

2. 사용자별로 다른 화면을 제공할 수 있다.

쿠키나 세션을 이용해 사용자마다 다른 데이터를 렌더링할 수 있다.

단점

1. 요청마다 서버 연산이 발생한다.

사용자가 많아질수록 서버 부하가 커진다.

2. 응답 속도가 느릴 수 있다.

데이터 조회와 HTML 생성 과정을 매 요청마다 수행하기 때문이다.

3. 캐싱 전략이 복잡해질 수 있다.

항상 최신 데이터를 제공해야 하는 경우 CDN 캐싱을 적극적으로 활용하기 어렵다.

ISR이란?

ISR은 정적 페이지를 생성해 두고, 일정 시간이 지나거나 특정 트리거가 유발(데이터 삽입)되면 백그라운드에서 페이지를 다시 생성하는 방식이다.

빌드 시 페이지 생성
        ↓
사용자에게 정적 페이지 제공
        ↓
revalidate 시간 경과 / 트리거 동작
        ↓
백그라운드에서 페이지 재생성

장점

1. 매우 빠르다.

미리 생성된 HTML 파일을 반환하므로 응답 속도가 빠르다.

2. 서버 부하가 적다.

모든 요청마다 렌더링하지 않기 때문에 대규모 트래픽에도 효율적이다.

3. SEO에 유리하다.

정적 HTML을 제공하므로 검색 엔진이 페이지를 쉽게 수집할 수 있다.

4. 데이터가 주기적으로 갱신된다.

SSG의 단점이었던 “빌드 이후 데이터 변경” 문제를 어느 정도 해결할 수 있다.

단점

1. 데이터가 항상 최신은 아니다.

revalidate 시간이 지나기 전까지는 이전 데이터가 제공된다.

예를 들어 revalidate: 60이라면 최대 60초 동안 오래된 데이터를 보게 될 수 있다.

2. 사용자별 페이지에는 적합하지 않다.

모든 사용자가 같은 정적 페이지를 공유하기 때문에 개인화된 데이터에는 사용하기 어렵다.

3. 데이터 변경 시점을 정확히 예측하기 어렵다.

실시간성이 중요한 서비스에는 적합하지 않다.

그래서 ISR은 SSR의 상위호환일까?

내 생각은 아니다이다.

ISR은 SSR의 단점을 해결하기 위해 등장한 기술이지만, SSR을 완전히 대체할 수는 없다.

두 기술은 트레이드오프가 존재한다.

즉, 최신 데이터가 중요하다면 SSR,
빠른 응답 속도와 트래픽 대응이 중요하다면 ISR을 선택하면 된다.

그럼 나는 어디에 무엇을 사용했을까?

CareerBee - ISR

지도 기반 커리어 플랫폼인 CareerBee에서는 기업 정보와 채용 공고 페이지에 ISR을 적용했다.

채용 정보는 분 단위로 계속 바뀌는 데이터가 아니었고, 많은 사용자가 동일한 페이지를 조회했다.

따라서 매 요청마다 서버에서 데이터를 가져오는 것보다 일정 주기로 페이지를 재생성하는 편이 훨씬 효율적이었다.

덕분에 초기 로딩 속도를 개선할 수 있었고, SEO 측면에서도 좋은 결과를 얻을 수 있었다.

관리자 페이지 - SSR

데모로 관리자 페이지의 대시보드를 만들었을 때 SSR을 사용했다.

통계 데이터와 사용자 현황은 항상 최신 상태를 보여줘야 했고 관리자의 수는 제한되어있기 떄문에 서버 부하가 일어날 가능성도 적다고 판단했다.

따라서 일부 성능 비용이 발생하더라도 최신성을 보장하는 SSR이 더 적합했다.

결국 렌더링 전략의 핵심은 “최신성”과 “성능” 사이에서 어떤 가치를 더 중요하게 생각하느냐에 따라 유동적으로 판단해야한다. 적재적소에 맞는 기술을 선택하는 것이 좋은 아키텍처의 시작이 되지 않을까?