[네이버 부스트캠프] 웹 풀스택 멤버십 #1:: 검색엔진 최적화와 PRG 패턴의 발견

챌린지 1주차가 끝났다.

한 주 동안 가장 많이 붙잡고 있던 키워드는

다름 아닌 SEO 최적화였다.

 

처음엔 웹을 만든다는 게

단순히 페이지를 구현하는 일이라고 생각했지만,

금세 깨달았다.

 

결국 웹의 가치는

얼마나 많은 사람이 찾아오는가에 달려있고

그 첫 관문이 검색엔진 노출이라는 것을.

이런 느낌이다😱

 

목차
1. #Week1 목표: 시맨틱 태그와 SEO
2. 학습과 구현, 단일 책임은 잠시 미뤄두다.
3. PRG 패턴을 접하다.
4. #Week1 평가
5. 다음 주 전략
6. 한 주를 마치며

엄밀한 의미에서 이번 주 학습한
Lighthouse, PageSpeed, Search Console은
코드 실행 병목을 추적하는 프로파일링 도구는 아닙니다.

다만 이번 글에서는 편의상,
웹 성능/SEO를 측정하는 모든 도구를 통칭해
프로파일링 도구라고 언급하고 있습니다.

1. #Week1 목표: 시맨틱 태그와 SEO

이번 주는 HTML 시맨틱 태그를 적극적으로 사용하고,

그 결과를 실제 프로파일링 도구로 측정하는 데 집중했다.

 

사실 시맨틱 태그라는 단어는 오래 전부터 들어왔지만,

정작 HTML을 배우기 시작할 때

제일 먼저 다루는 건 div와 span이다.

 

웹 개발을 처음 접했을 당시,

그 둘을 간신히 익히고,

flex와 grid로 레이아웃을 잡는 데 익숙해질 즈음에야

이제는 시맨틱 태그를 써야 한다는 사실을 깨달았다.

<header>
  <h1>개발새발 민다니</h1>
</header>
<main>
  <article>
    <h2>첫 번째 글</h2>
    <time datetime="2025-08-20">2025년 8월 20일</time>
    <p>내용…</p>
  </article>
</main>
<footer>© 2025 minda</footer>

 

이처럼 단순히 구조를 나누는 것 이상으로,

검색엔진에게 문서의 의미를 알려주는 역할이 있다는 걸 알게 되니

매일이 새롭게 배우는 것들로 이루어져 있었다.

 

특히 time 태그 하나만 추가해도

검색엔진이 문서의 작성일을 인식할 수 있고,

이는 곧 신뢰도 평가에 반영된다는 사실은

정말 전공 수업에서 단 한 번도 들어보지 못한 지식이었다.

 

이번 주는 그래서,

SEO 최적화를 위한 태그 설계 → 구글 크롬 기준 프로파일링 → 점수 확인

 

을 주요 루틴으로 삼았다.

 

백엔드 요구사항은 과감히 미뤄둔 채,

프론트만이라도 제대로 해보자는 각오였다.

---

2. 학습과 구현, 단일 책임은 잠시 미뤄두다.

다만, 단일 책임 원칙은 과감히 지키지 않았다.

두 가지 이유에서 비롯된 문제 때문이다.

 

첫 째, SEO 측정에서 JavaScript가

오히려 방해 요소가 될 수 있다고 생각했기 때문이다.

스크립트가 언제 실행되느냐(defer, async 여부)에 따라

검색엔진 크롤러가 페이지를 제대로 읽지 못할 수도 있다는 우려가 있었다.

<script src="main.js" defer></script>

 

이 한 줄의 defer가 크롤러에게는

페이지 렌더링 지연으로 작용할 수 있다.

그렇다면 차라리 JS 의존성을 최소화하고,

정적인 시맨틱 구조를 우선 다지는 편이 낫다고 판단했다.

 

둘 째, 요구사항이 SSR에 가깝게 읽혔는데

2주차에 CSR 구조로 전환될까봐 약간의 잔머리를 썼다.

 

아키텍처를 지금 당장 세분화하다

유지보수에 많은 시간을 들이게 될 것 같아서...🤯

최소한의 디렉토리,

단순한 라우터로만 페이지 이동을 처리했다.

// 단일 책임을 고려하지 않은 임시 라우터
app.get('/about', (req, res) => {
  res.render('about');
});

 

규모가 작기 때문에 읽기는 편한데,

확실히 단일 책임은 엿 바꿔먹은 디렉토리 구조긴 하다.

 

그래도 이번 주의 핵심은 어디까지나 SEO였으니,

방향성은 맞았다고 위안 삼았다😂

---

3. PRG 패턴을 접하다.

 

이번 주 눈에 띈 학습은

PRG(Post-Redirect-Get) 패턴이었다.

 

다양한 분야를 학습했지만,

처음 접한 개념이라 유독 기억에 남는다.

 

로그인이나 회원가입처럼,

폼 전송 후 새로고침이 일어나면

POST 요청이 반복되는 문제가 있다.

// 잘못된 처리 (forward)
app.post('/login', (req, res) => {
  res.render('home'); 
  // 새로고침 시, POST가 그대로 반복되어 중복 로그인 시도 발생
});

 

이게 문제가 되는 이유는 간단하다.

GET, PUT, DELETE 같은 메서드는

멱등성을 가진다.

 

즉, 동일한 요청을 여러 번 보내도 서버의 상태가 변하지 않는다.

 

예를 들어, 

GET /user/123   # 같은 사용자 조회 → 항상 같은 결과
DELETE /user/123   # 같은 자원 삭제 요청 → 결과는 "삭제됨"으로 동일

 

하지만 POST는 멱등성이 없다.

같은 요청을 두 번 보내면

회원가입이 두 번 처리되거나 결제가 중복 발생할 수 있다.

POST /order
Body: { "item": "book", "count": 1 }

# 두 번 전송 시 → 책 두 권 결제 처리

 

이 문제를 해결하는 고전적인 방법이 바로 PRG 패턴이다.

// PRG 패턴 적용
app.post('/login', (req, res) => {
  // 로그인 로직 처리
  res.redirect('/home'); // POST → Redirect → GET
});

 

POST 요청은 한 번만 처리하고,

그 결과 페이지를 GET으로 다시 불러오게끔 하는 방식이다.

사용자가 새로고침을 누르더라도

다시 실행되는 건 GET 뿐이므로 서버 상태가 중복 변경되지 않는다.

• 회원가입 후 → 회원가입 완료 페이지로 리다이렉트
• 결제 후 → 주문 내역 페이지로 리다이렉트

현업에서 자주 보는 UX 흐름이

사실은 멱등성을 보장하기 위한 안전장치였다는 사실을 알게 되니

상당히 인상 깊어 머릿 속에 오래 남은 것 같다.

---

4. #Week1 평가

 

뿌듯한 점은 분명했다.

첫 주차임에도 배포까지 진행했고,

프로파일링 도구를 직접 돌려 성능 점수를 확인했다.

정량적인 지표로 내 코드를 설명할 수 있겠다는 작은 자신감이 생겼다.

 

 

다만 아쉬운 점은 개념 정리의 부족이다.

 

백엔드 도메인이 특히 생소하다 보니,

설계에 시간이 오래 걸리고 정리는 늘 뒷전으로 밀렸다.

결국 학습 성과 대비 기록이 부족했고,

발표 자료도 잘 준비하지 못했다.

 

그냥 앞으로는 공유 목적으로 학습 파일들을 정리해나간다고 생각하면서

기록에 조금 더 신경 쓰는 게 어떨까 싶다.

---

5. 다음 주 전략

 

다음 주는 SEO를 더 실행해볼 생각이다.

세 가지 측정 도구 중에, 가장 많은 영역을 측정해주는

Google Search Console의 색인이 제때 잡히지 않더라도,

최적화 기법을 발표용으로 정리할 예정이다.

사실 발표 주제가 Google Seach Console인데 측정에 며칠씩 걸리는 건에 관하여...

 

또, 백엔드에는 레이어드 아키텍처를 시도해볼 예정이다.

controllers/ -> 요청 핸들링
services/ -> 비즈니스 로직
repositories/ -> 데이터 접근

 

더 멋있는 아키텍처도 많지만,

규모가 작은 프로젝트라 과하게 느껴질 경우가 많아

레이어드 아키텍처를 선택하게 됐다.

 

이것도 좀 계층이 많긴 하지만,

라우터와 컨트롤러를 구분하는 감을 잡기 위해 시도해보려 한다.

---

6. 한 주를 마치며

 

불과 1주가 지났을 뿐인데 전과 후의 밀도가 달라졌다.

 

챌린지에서 그저 문제를 풀던 날들과 달리,

멤버십은 과제 하나를 붙잡고 깊게 들어가니

올해 가장 치열한 학습이 된 듯하다.

 

아직은 모르는 게 더 많고,

단순한 구현조차 버거울 때가 많다.

 

하지만 프로파일링 점수를 보며,

내가 개선할 수 있는 여지가

눈앞에 보인다는 사실만으로도 즐겁다.

앞으로의 21주,

코드를 더 섹시하게 짜는가보다는,

문제 해결력과 공유할 수 있는 인사이트를 남기는 데 집중하고 싶다.

 

결국 중요한 건 완벽한 설계가 아니라,

계속 배우고 나누며 앞으로 나아가는 태도이지 않나 싶다.