SEO 주도 개발 실천기: 구글이 인정한 ‘좋은 URL’ 99% 달성 여정

원티드 엔지니어분들은 원티드 플랫폼을 개발하고 운영하며, 더 나은 사용자 경험을 제공하기 위해 끊임없이 노력하고 있습니다.

그 노력의 일환으로, 저희는 ‘SEO 주도 개발’을 실천하고 있습니다.

‘SEO 주도 개발’이란, Google Search Console (이하 GSC )과 도구를 통해 SEO 관련 지표를 주기적으로 관찰하고, 이를 개선하는 것을 개발의 주요 목표 중 하나로 삼는 방식을 의미합니다.

모든 URL이 ‘좋은 URL’이 되기까지

10월 30일부로 원티드의 99% URL은 좋은 URL로 전환.

10월 30일, 저희는 Google Search Console의 코어 웹 바이탈(Core Web Vitals) 지표에서 모든 URL이 ‘좋은 URL(빠른 URL)’로 전환되는 값진 성과를 달성했습니다.

제가 처음 입사했을 때만 해도, GSC 지표는 ‘느린 URL’과 ‘개선이 필요한 URL’이 대부분이었습니다. 이 지표들을 모두 ‘좋은 URL’로 바꾸겠다는 목표를 세웠고, 그 개선 여정을 시작하게 되었습니다.

이 글은 그 목표를 달성하기까지의 과정을 공유합니다. 이 성과는 원티드의 모든 프론트엔드. 서버, Devops 엔지니어분들의 협업이 있었기에 가능했습니다.

1부: 기본기 다지기, 서버 사이드 로직 최적화

아무리 프론트엔드에서 렌더링 최적화를 진행해도, Next.js 서버에서 HTML 응답 자체를 늦게 내려준다면 사용자가 느끼는 속도는 느릴 수밖에 없습니다. 저희는 병목의 원인을 서버 사이드에서부터 찾아 해결하기로 했습니다.

1–1. 병목의 핵심, 번역키 데이터 제거

가장 큰 병목은 URL 첫 요청 시 받아오는 HTML의 용량이었습니다.

문제:

• 당시 원티드는 글로벌 서비스를 지향하며 방대한 양의 번역키 데이터를 HTML에 포함 하고 있었습니다. 이 데이터가 전체 HTML 용량의 90%를 차지했습니다. 이는 경쟁사 대비 월등히 큰 용량이었고, 이 데이터를 가져오는 레이턴시까지 더해져 심각한 성능 저하를 유발했습니다.

과정:

• 하지만 이 번역키는 조직의 일하는 방식과 깊이 결합되어 있어 단순히 제거하기 어려웠습니다. 저는 현재 상황을 최대한 수치화(경쟁사 비교, 로딩 속도 영향)하여 자료를 만들었고, 조직장, 경영진, 그리고 동료 개발자분들께 공유하며 설득하는 과정을 거쳤습니다.

결과:

• 최종적으로 번역키 데이터를 제거해도 좋다는 공감대를 형성했고, 해당 로직을 과감히 삭제할 수 있었습니다.
• HTML 용량 66% 감소 (경쟁사보다 가벼운 페이지 달성)
• 프론트엔드 서버 Latency 16% 개선
• FCP (First Contentful Paint) 10% 개선
• LCP (Largest Contentful Paint) 21% 개선

번역키 데이터 제거 배포 후, 서버 Latency 지표

1–2. 로그인 사용자 TTFB 개선 (DB 인덱스 추가)

원티드 서비스는 유독 로그인한 사용자가 접속할 때 첫 요청이 느린 현상이 있었습니다.

원인분석과 해결은 프론트엔드 챕터 조윤환님과 서버 챕터 이지수님이 작업을 진행 하셨습니다.

• 문제: Datadog으로 메트릭을 분석한 결과, 로그인한 사용자의 세션 정보를 가져오는 DB 테이블에 인덱스(Index)가 누락된 것을 확인했습니다.
• 과정: 해당 테이블에 즉시 인덱스를 추가했습니다.
• 결과: TTFB (Time to First Byte) 지표 70% 개선 🚀🚀🚀🚀

1–3. 서버 사이드 API 호출 병렬 처리

Next.js 서버 사이드(SSR)에서 페이지 렌더링에 필요한 API들을 기본적으로 호출하고 있었습니다.

원인 분석과 해결은 프론트엔드 챕터 조윤환님이 진행하셨습니다.

• 문제: 이 API들이 순차적으로 호출되어 불필요한 대기 시간이 발생하고 있었습니다.
• 과정: API 간의 의존 관계를 분석하여, 서로 상관관계가 없는 API들은 Promise.all 등을 활용해 병렬로 처리하도록 로직을 수정했습니다.
• 결과: TTFB 20% 개선

1–4. Internal API 호출로 레이턴시 단축

서버 사이드에서 API를 호출할 때, 외부로 나갔다가 다시 들어오는 Public API를 사용하고 있었습니다.

• 문제: 불필요한 네트워크 홉(hop)으로 인한 레이턴시가 발생했습니다.
• 과정: 서버 챕터 홍진우님 이 먼저 Internal API(내부 통신용 API)로 전환을 제안해주셔서 빠르게 적용할 수 있었습니다.
• 결과: API 호출 레이턴시 32% 감소

1–5. 인프라 아키텍처 개선 (CloudFront 도입)

인프라 최전선에 Amazon CloudFront를 도입하여 아키텍처 변화를 주었습니다.

과정: 인프라 맨 앞단, 즉 사용자의 요청이 가장 먼저 도달하는 지점에 CloudFront (CDN)를 도입했습니다.

결과:

• CloudFront의 엣지 로케이션을 통해 사용자에게 더 가까운 곳에서 콘텐츠를 제공하고 연결을 최적화했습니다.
• 유저와 서버 간의 TCP 커넥션 최적화
• 최신 프로토콜인 HTTP/3 적용으로 연결 속도 및 효율성 향상
• LCP (Largest Contentful Paint) 10% 개선
• FCP (First Contentful Paint) 7% 개선

📈 중간 점검: 2025년 2월, 모바일 99% 달성

2025년 2월 GSC 지표

1부에서 소개한 여러 서버 사이드 최적화 작업을 완료하니, ‘빠른 URL’ 지표가 상승하기 시작하였습니다. 하지만 대부분 여전히 ‘개선이 필요한 URL’ 비율이 높았습니다.

이후 2025년 1월 말, 저희는 또 한 번의 큰 개선 작업을 진행했습니다.

기존에 Client Side에서 호출되던 특정 페이지 로직을 Server Side Rendering(SSR)으로 전환 한 것입니다. 이 작업은 즉각적인 성과로 나타났습니다. 모바일 환경에서만 10만 개에 달하는 URL이 ‘좋은 URL’로 전환 되었고, 그 결과 2025년 2월 기준, 모바일 URL의 99%가 ‘좋은 URL’이 되는 성과를 거두었습니다.

게재 순위도 점점 상승되는 시기

당시 GSC 지표는 다음과 같았습니다.

[📱 모바일]

• 좋은 URL: 140,148
• 개선이 필요한 URL: 388
• 느린 URL: 138

[💻 데스크톱]

• 좋은 URL: 97,370
• 개선이 필요한 URL: 43,122
• 느린 URL: 182

보시다시피 모바일 지표는 거의 해결되었지만, 데스크톱은 ‘개선이 필요한 URL’이 4만 개 이상 남아있는 상태였습니다. 이로써 저희의 다음 목표는 명확해졌습니다. 바로 아직 남아있는 클라이언트 사이드 문제를 해결하여 데스크톱 지표를 개선하는 것이었습니다.

2부: 사용자 경험의 완성, 클라이언트 사이드 최적화

서버의 응답 속도를 확보한 뒤, 사용자의 브라우저에서 실제로 그려지는 속도를 개선하는 작업에 집중했습니다.

2–1. 3rd-Party 라이브러리 번들 사이즈 최적화

모든 페이지들의 근간이 되는 _app.js의 사이즈가 커서 모든 페이지들이 무거워지고 있었습니다.

이작업의 원인 분석과 해결은 프론트엔드 챕터 임성현님이 진행 하셨습니다.

문제:

• 사용자가 처음 접속할 때 다운로드해야 하는 JavaScript(JS) 용량이 컸습니다.

과정:

• 번들 분석 도구를 사용하여 불필요하게 큰 라이브러리를 식별했습니다.
• Tree-shaking이 효율적으로 동작하는 라이브러리로 교체
• 당장 필요하지 않은 무거운 라이브러리는dynamic import()를 사용해 사용자가 필요로 하는 시점에 불러오도록 지연 로딩(Lazy Loading)을 적극 활용

결과:

• _app.js 파일의 크기를 759KB에서 489KB로 35%사이즈를 줄였습니다.
• FCP: 60% 개선
• LCP: 31% 개선
• TTFB: 13% 개선

2–2. 마지막 관문, 데스크톱 CLS 개선

위의 모든 과정을 마쳤을 때, 대부분의 페이지가 ‘좋은 URL’로 전환되었습니다. 하지만 단 하나, 데스크톱 ‘포지션 상세 페이지’가 CLS (Cumulative Layout Shift, 누적 레이아웃 이동) 지표 0.1 이상으로 ‘개선이 필요한 URL’로 남아있었습니다.

문제:

포지선 상세 페이지 페이지 로딩중에 Image 슬라이드 영역이 유동적으로 변경되어, 레이아웃이 밀리는 현상이 발생 했습니다.

과정:

• Chrome > 개발자도구 > Performentce 에서 문제가 발생하는 컴포넌트 판별하고, 불필요한 layout shift되는 코드를 개선.

결과:

• 데스크톱 상세 페이지의 CLS 지표를 0.1 미만으로 개선 완료
• 원티드 플랫폼의 99% 이상 페이지가 ‘좋은 URL’로 전환

맺음말

SEO 주도 개발을 통해 지표를 개선하는 과정은 단순히 숫자를 바꾸는 작업이 아니었습니다. 느린 원인을 데이터로 분석하고, 동료들을 설득하며, 기술적인 해결책을 함께 찾아 나가는 전 과정이었습니다.

그 결과, 10월 30일부로 Google Search Console의 99%지표가 ‘좋은 URL’ 로 빛나게 되었습니다. 이는 곧 사용자 경험의 향상을 의미하며, SEO 지표에도 긍정적인 효과로 나타나고 있습니다.

원티드의 더 나은 사용자 경험을 위한 원티드의 엔지니어들의 여정은 앞으로도 계속될 것입니다.