들어가며
오랜만에 개발 컨퍼런스에 다녀왔다. 바로 프론트엔드 개발자들을 위한 FEConf.
작년에는 티켓팅 광탈로 아예 발도 못 들였는데, 올해는 수량이 넉넉했는지 무난하게 성공했다.
사실 가장 듣고싶었던 건 골드티켓 전용 세션 Frontend Leader Talk였지만,
거기에 10만 원을 더 쓰기에는 내 지갑이 요즘 급격하게 다이어트를 해버려서...
그리고 결과적으로는 다행이었다. 오전에 일이 생겨서 행사장에 도착한 게 3시쯤이었으니까.
결국 세션은 세 개밖에 듣지 못했지만, 오히려 딱 필요한 만큼만 건지고 나왔다는 생각이 들었다.
이 글은 그 짧은 경험을 정리해두려는 기록이다.
SEO, 그래서 왜 하는건데?
첫 번째로 들은 건 <1년에 10억 원을 절약한, 강남언니의 SEO 웹 전략 공개> 세션이었다.
나는 지금까지 SEO라고 하면 “메타 태그 잘 넣고, 시멘틱 태그 쓰고, SSR 정도 적용하면 되겠지” 정도로 생각했었다.
그런데 발표를 듣고 나니, 이건 단순히 태그 몇 개 바꾸는 문제가 아니라 검색 퍼널 관점에서 봐야 한다는 생각이 들었다.
검색 노출: 구글 검색 결과에 우리 페이지가 얼마나 보이는가검색 유입: 노출된 페이지 중에서 사람들이 얼마나 클릭하는가전환(액션): 사이트에 들어온 사람들이 실제로 앱 다운로드, 예약 등 원하는 행동까지 이어지는가
발표는 SEO를 이 퍼널 흐름에 맞춰 풀어냈고, 기술 요소들이 각 단계에서 어떤 역할을 하는지 정리해주었다.
Crawling Budget — 구글봇의 체력 관리
구글봇이 하루에 우리 사이트를 탐색할 수 있는 자원은 한정돼 있다. 발표에서는 이걸 크롤링 버짓이라고 불렀다.
- 페이지 크기를 줄이고(
LCP단축, 이미지 최적화,critical CSS적용), sitemap으로 중요한 페이지만 우선순위를 높이고,- 가치 없는 페이지는 과감하게
noindex처리해서 낭비를 막아야 한다.
결국 같은 사이트라도 크롤링 버짓을 어디에 쓰느냐에 따라 인덱스되는 페이지의 수와 질이 달라진다.
단순히 페이지를 많이 만든다고 끝나는 게 아니라, 구글이 꼭 가져갔으면 하는 페이지부터 효율적으로 먹이게 하는 것이 전략이라는 거다.
검색 유입 — 클릭하고 싶게 만들기
사람들이 검색 결과에서 해당 페이지를 누르도록 만드는 건 메타 태그, 시멘틱 태그, 구조화 데이터였다.
메타 태그: 타이틀과 디스크립션을 어떻게 써놓느냐에 따라CTR(클릭률)이 크게 달라진다.시멘틱 태그:<article>,<section>같은 태그로 문맥을 잘 잡아주면 크롤러가 페이지 의도를 더 정확히 파악한다.구조화 데이터:schema.org기반 JSON을 심어두면, 구글이 페이지 정보를 더 풍부하게 이해할 수 있다. 이게 검색 결과에서 별점, 가격, FAQ 같은Rich Result로 노출되면서 차별화를 만든다.
전환 — 신뢰도와 내부 구조
검색해서 들어온 사용자가 실제 전환까지 가려면 페이지 내부 구조도 중요하다.
Page Silo: 관련 주제끼리 내부 링크를 촘촘하게 묶어주면 구글이 “이 사이트는 이 주제에서 권위가 있다”고 판단한다.Core Web Vitals:LCP,CLS같은 지표가 안정적이면 사용자 경험이 좋아지고, 이게 장기적으로 SEO에 긍정적 영향을 준다.External Link Management: 외부 권위 있는 사이트에서 링크를 많이 받는 것도 신뢰도와 랭킹에 영향을 미친다.
눈에 들어온 숫자들
강남언니 웹은 하루 2.7만 명이 방문하는데, 그중 60%가 일본 유저라고 했다. 이 트래픽을 앱 다운로드와 예약 전환으로 연결하면서 연간 10억 원 절감이라는 결과를 만들었다고 한다.
단순히 페이지 노출에서 끝나는 게 아니라, CAC를 줄이고 LTV를 올리는 지점까지 연결된 사례라 흥미로웠다.
내 상황에 비춰보면
내 상황에 대입해보면, 나는 이제서야 학원 홈페이지를 배포하고 SEO를 직접 챙기기 시작한 단계다.
그전까지는 그냥 “메타 태그 몇 개 넣고 sitemap 만들면 되겠지” 수준에서 멈춰 있었는데, 이번 발표를 들으며 그게 얼마나 얕은 접근이었는지 인정할 수밖에 없었다.
그래서 이번에는 목표를 확실히 세웠다.
Lighthouse 점수나 Core Web Vitals 같은 단순 기술 지표가 아니라, 트래픽 자체를 끌어올리고 전환으로 이어지게 하는 것.
어찌 보면 개발자라기보다 마케터에 가까운 방식이지만, 이런 과정을 기술적으로 풀어내면서 가야 진짜 Problem Solver가 될 수 있지 않을까 싶다.
TanStack Query × React Server Component
두 번째로 들은 세션은 TanStack Query와 RSC 얘기였다.
사실 RSC 자체는 이제 꽤 알려진 주제라서 새롭다기보단, “이걸 TanStack Query랑 어떻게 엮어낼 수 있을까?”에 초점이 맞춰져 있었다.
발표자 분은 먼저 RSC의 기본을 짚고 갔다.
- 서버 전용 컴포넌트라 클라이언트 번들에 포함되지 않고,
- 내부에서
async연산을 쓸 수 있으며, - 자식으로는 클라이언트 컴포넌트를 둘 수 있다.
덕분에 DB 계정이나 API 키 같은 보안 자원은 서버에서 처리하고, 클라이언트에는 순수한 뷰만 내려보낼 수 있다는 점이 다시 강조됐다.
여기까지는 익숙한 얘기였는데, 흥미로웠던 건 RSC에서 쿼리를 다루는 방식이었다.
무한 스크롤을 예로 들어 설명했는데,
- 서버에서 데이터를 전부 내려주면 서버 부하가 심해지고,
- 필요한 부분만 클라이언트에서 처리하면 클라이언트 측 로직이 복잡해진다.
결국 어느 한쪽만으로는 답이 나오지 않는다는 얘기였다.
그래서 제시된 전략이 RSC와 TanStack Query를 병행하는 방식이었다.
서버에서 초기 데이터를 prefetch해주고, 이후 pagination이나 필터링 같은 상호작용은 클라이언트의 useQuery로 이어받는 흐름이다.
장점은 기존 코드를 버리지 않고 점진적으로 이주할 수 있다는 거고,
단점은 서버와 클라이언트 사이의 경계가 늘어나면서 복잡성이 커진다는 점이었다.
재밌었던 부분은, 발표자가 이 과정을 아예 자기만의 쿼리 라이브러리인 Dataready로 풀어내고 있다는 점이었다.
기존 useQuery는 반환값이 너무 많다는 문제의식에서 출발했는데,
- 에러는
ErrorBoundary에서 처리하고, refetch같은 동작은mutation레이어로 넘기며,- 최종적으로는
data만 남긴 단순한 쿼리 객체를 정의했다.
이렇게 단순화된 구조라면 RSC와 잘 맞물리고, 타입 안전성까지 챙길 수 있다는 주장이었다.
듣는 내내 느낀 건, 이건 결국 RSC 원리를 제대로 이해한 사람이 자기 상황에 맞게 툴을 엮어낸 사례라는 거였다.
보면서 “결국 중요한 건 문제를 어떻게 정의하느냐, 그리고 그걸 풀기 위해 어떤 툴을 어떻게 조합하느냐구나” 하는 생각이 들었다.
앞으로는 새로운 기술을 그냥 따라 써보는 데서 그치지 않고, 문제에 맞는 해법을 직접 만들어가는 연습을 해야겠다고 느꼈다.
모노레포 해체기: 문제는 레포가 아니라 의존성
발표자의 이야기를 들어보면, 처음에는 여러 앱을 한 레포에서 함께 개발하면서 “공유하니까 편하다”는 장점이 컸다고 한다.
하지만 시간이 지날수록 props 하나를 더 뚫고, 공통 유틸 함수를 아무 데서나 끌어다 쓰는 일이 반복되면서 결국 괴물 같은 공유 모듈들이 생겨버렸다.
작은 수정 하나가 전사 장애로 번지고, 정기 배포는 3년간 160번 넘게 누적되면서 유지가 거의 불가능한 상황까지 간 것이다.
그래서 결국 1개의 모노레포를 14개의 폴리레포로 쪼개는 결정을 내렸다.
이 문제를 실제로 확인하고 싶어 발표자가 시도한 게 의존성 그래프 시각화였다.
그런데 결과는 말 그대로 한눈에 파악조차 불가능한 수준이었다.
공통 모듈이라고 묶어둔 코드들이 사실상 아무 데서나 끌어다 쓰이다 보니, 작은 props 하나가 전사 앱 전체를 흔드는 괴물 모듈로 커버린 사례가 줄줄이 튀어나왔다.
나도 예전에 모노레포에서 비슷한 경험을 했기 때문에 이 부분은 꽤 공감이 갔다.
재밌었던 건 단순히 “쪼갰다”로 끝나지 않고, 어떤 기준으로 어떻게 갈랐는지까지 공개했다는 거다.
발표자는 패키지를 네 가지 레이어로 정리했다.
Design System: 전사적으로 단일해야 하는 UI 컴포넌트/토큰Shared Packages: utils, API 타입 등 공통화하지 않으면 생산성이 크게 떨어지는 코드Domain Services: 특정 제품 라인에 종속된 로직Apps: 실제 서비스로 배포되는 최종 애플리케이션
여기서 ‘진짜 공통’이 아닌 건 전부 각 서비스 안으로 내재화했다. 중복이 늘더라도, 방치된 공유 모듈 괴물보다는 낫다는 판단이었다.
마이그레이션 과정도 만만치 않았다.
총 9개의 마일스톤, 약 1년 6개월 동안 진행됐는데, 레포를 나누는 것뿐만 아니라 배포 파이프라인까지 갈아엎어야 했다.
기존에는 모든 앱이 한 번의 정기 배포에 묶여 있어서, 사소한 수정 하나가 곧 전사 릴리즈였다고 한다.
최종적으로는 14개의 폴리레포로 분리되면서 앱별·서비스별 독립 배포가 가능해졌다.
발표에서 반복적으로 나온 키워드는 결국 “공유 모듈 기준”이었다. 질문은 단순하다.
- 이게 제품 전체에서 단일해야 하는가?
- 공통화하지 않으면 생산성이 크게 떨어지는가?
둘 다 아니면 공유하지 않는다.
이 룰 덕분에 무분별하게 props 뚫고 끌어다 쓰던 코드들을 정리할 수 있었다고 한다.
핵심은 의존성을 어떻게 시각화하고, 어디서 경계를 긋느냐이다.
이번 발표를 보면서 의존성 관리의 중요성을 뼈저리게 느꼈다.
어디까지 공유하고 어디서 끊을지를 분명히 하지 않으면, 레포 형태 따위는 사실 아무 의미도 없다.
결국 이런 기본기를 제대로 챙기는 게 내가 앞으로 더 큰 프로젝트를 감당할 수 있는 힘이 되지 않을까 싶다.
마치며
짧게 세 개 세션만 들었지만, 이번 FEConf는 나한테 꽤 선명한 메시지를 남겼다.
SEO에서는 단순 기술 지표를 넘어 비즈니스 퍼널과 연결되는 사고를 배웠고,RSC세션에서는 새로운 툴을 단순히 ‘써보는 것’이 아니라 문제 정의와 조합의 결과물이어야 한다는 걸 느꼈다.- 그리고
모노레포 해체경험담에서는 결국 의존성과 경계를 어떻게 관리하느냐가 팀 전체의 생존을 좌우한다는 걸 깨달았다.
결과적으로 기술 자체보다 그것을 어떻게 바라보고 다루어야 하는지에 대한 관점과 태도를 얻은 자리였다.
사실 요즘 개발 공부를 어떻게 이어가야 할지 방향이 잘 잡히지 않았다.
곰곰이 생각해보니, 내가 진짜 풀고 싶은 문제가 없으니 뭘 공부해야 할지도 보이지 않았던 거다.
이번 컨퍼런스를 통해 다양한 이야기를 들으면서 시야를 넓힐 수 있었고, 그 과정에서 이제는 내가 풀고 싶은 문제를 먼저 정의해야 한다는 필요성을 확실히 느꼈다.
