FEConf 2025 후기: SEO부터 TanStack Query까지, 개발자의 시야를 넓힌 하루

1. FEconf 2025 가게 된 이유

이번 FEConf에 신청하게 된 이유는 생각보다 단순했다. 프로그램을 살펴보는데 강연 제목들이 하나같이 흥미로웠기 때문이다. 한두 개가 아니라 여러 세션이 동시에 눈에 들어왔고, "현장 분위기를 직접 느끼고 나면 자연스럽게 유튜브 다시 보기까지 챙겨보게 될 텐데?"라는 기대감이 생겼다. 그런 동기부여가 될 것 같아 망설임 없이 신청 버튼을 눌렀다.

 

현장에 도착해서 가장 먼저 눈에 띈 것은 넓게 마련된 네트워킹 공간이었다. 내가 신청한 당근 모임 네트워킹도 바로 그곳에서 진행될 예정이었는데, 설렘과 동시에 "너무 긴장해서 말도 제대로 못 하면 어떡하지?"라는 걱정이 스쳐 지나갔다.

 

 

---

 

 

2. 가장 인상 깊었던 세션: 1년에 10억원을 절약한, 강남언니의 SEO 웹 전략 공개

개발 공부를 하면서 SEO를 대하는 내 자세는 항상 이랬다. "아, 그냥 메타 태그 몇 개 넣고 구글 서치 콘솔에 등록하면 끝이겠지?"

 

개인 블로그 만들 때도 마찬가지였다. 대충 <title>태그 넣고, description 적고, 사이트맵 한 번 등록해놓으면 "자! 이제 SEO 완료!"라고 생각했던 게 전부였다.

 

그동안 나에게 SEO는 그냥 '검색 순위 올리기 게임'이었다. 하지만 이번 세션을 듣고 깨달았다. SEO는 게임이 아니라 비즈니스 성과와 직결되는 핵심 전략이었다.

 

세션을 들으면서 생소한 용어들이 계속 나왔다. 나중에 찾아보니 이런 뜻이었다.

- LCP(Largest Contentful Paint): 페이지에서 가장 큰 콘텐츠가 화면에 렌더링되는 시간. 빠를수록 사용자 경험이 좋고, 구글도 더 좋아한다.
- CAC(Customer Acquisition Cost): 고객 한 명을 데려오는데 드는 비용. 광고비, 마케팅 비 등을 포함한다. 당연히 낮을수록 좋다.
- LTV(Life Time Value): 한 고객이 우리 서비스를 이용하면서 평생 가져다주는 수익. 높을수록 좋다.

 

---

 

2-1. 아하! 순간의 연속

준혁님이 설명하신 SEO 전략을 들으면서 "아하!" 하는 순간들이 계속 있었다. 

 

[ 준혁님이 설명해주신 SEO의 3가지 가치 ]

1. SEO는 브랜딩이다 

검색 결과 상위에 계속 노출 -> 사람들이 우리 브랜드를 자연스럽게 기억 -> 브랜드 인지도 상승 

 

2. SEO는 광고비 절약이다 

자연 검색(Organic Search)으로 유입 상승 -> 유료 광고에 덜 의존 -> CAC 감소 -> 마케팅 비용 절약 

 

3. SEO는 고품질 트래픽이다 

검색해서 온 사람들은 이미 관심이 있는 상태 -> 전환율 높음 -> LTV증가

 

 

이렇게 연결고리를 따라가니까 "아, 그래서 10억원이구나!" 하는 이해가 됐다.

 

---

 

2-2. 실전 전략 3단계

1단계: 일단 많이 노출시켜라

크롤링 버짓을 늘려라

• 구글봇이 우리 사이트에 할애하는 시간과 리소스를 늘리는게 핵심
• 사이트맵 제대로 만들기 (강남언니는 이것만으로도 크롤링이 확늘었다고 함)

링크 구조를 제대로 만들어라 

• <button onclick="goSomewhere()"> ❌
• <a href="/somewhere"> ✅
• 구글봇은 JavaScript보다 HTML 링크를 더 잘 따라간다

 

2단계: 클릭하고 싶게 만들어라

메타 태그로 어필하기

<title>홍길동 성형외과 후기 | 실제 수술 경험담 총정리</title>
<meta name="description" content="홍길동 성형외과에서 실제로 수술받은 300명의 생생한 후기와 전후사진을 확인하세요. 가격, 회복기간, 부작용까지 솔직하게 공개합니다.">

 

구조화 데이터 활용하기

• 별점, 가격, 리뷰 개수 같은 정보를 검색 결과가 바로 보여주면 클릭률이 확 올라간다

 

3단계: 유명하게 만들어라

외부 링크 늘리기

• 다른 사이트에서 우리를 링크해줄수록 구글이 "아, 여기 유명한 사이트네"라고 인식

페이지 속도 최적화

• LCP 개선하면 사용자도 좋고 구글도 좋아한다
• 필자가 내용 추가) 이미지 최적화, CDN 사용, 불필요한 JavaScript 제거

 

---

 

2-3.완전히 몰랐던 꿀팁들

1. 일본어 검색에서 한국어 나오면 신뢰도 급감

이건 정말 생각해보지 못했던 부분이라 충격이었다. 사실 생각해보면 내가 한국어로 검색했는데 일본어 페이지가 나오면 바로 뒤로가기 버튼을 누를 것 같다. 타겟 국가별로 언어 전략을 완전히 다르게 가져가야 한다는 걸 깨달았다.

 

2. 다양한 페이지 타입으로 노출 기회 늘리기

• 랭킹 페이지: "2024년 최고의 성형외과 TOP 10"
• 비교 페이지: "A병원 vs B병원 비교"
• FAQ 페이지: "코 수술 전 궁금해요"

(제목들은 제가 이해하기 쉽게 임의로 만든 예시입니다)

각각 다른 검색 의도를 가진 사용자들을 잡을 수 있다는 점이 인상적이었다.

 

3. 사이트맵의 위력

강남언니팀이 사이트맵을 제대로 구축하자마자 크롤링이 폭증했다는 이야기를 들으니, 그동안 내가 얼마나 기본기를 소홀히 했는지 반성하게 됐다. 단순해 보이는 사이트맵 하나가 이렇게 큰 차이를 만들 줄 몰랐다.

 

---

 

2-4. 나는 이걸 당장 적용해볼수 있을까?

1. 사이트 크롤링 현황 체크 - 구글 서치 콘솔에서 크롤링 통계 확인
2. 페이지 속도 측정 - PageSpeed Insights로 LCP 확인
3. 링크 구조 점검 - JavaScript 대신 HTML 링크로 바꿀 수 있는 부분 찾기
4. 경쟁사 분석 - 비슷한 도메인에서 상위 랭킹된 페이지들은 어떤 전략을 쓰고 있는지 관찰

 

정말 인상 깊었던 세션이었다. SEO를 단순한 기술적 작업이 아닌 비즈니스 임팩트를 만들어내는 전략적 도구로 바라보게 되었다. 

이제 다음 프로젝트에서는 처음부터 SEO를 염두에 두고 설계해봐야겠다. 혹시 내가 놓치고 있는 SEO 전략이 또 있을까?

 

 

---

 

 

3. 가장 인상 깊었던 세션: 음성 인터페이스 개발에서 DX 향상하기

사이드프로젝트를 하다 보면 자주 마주치는 순간이 있다. "어? 이 기능도 추가해야겠네", "이 라이브러리가 더 좋다던데?"하면서 코드를 뒤엎게 되는 그 순간 말이다. 특히 혼자 개발하다 보니 처음에 생각했던 구조로는 한계가 보이기 시작할 때가 그렇다. 이 섹션이 바로 그런 현실적인 개발자의 고민을 담고 있다.

 

---

3-1. 매주 바뀌는 모델, 매주 뒤엎어지는 코드

민수님이 STT/TTS 모델이 계속 변했는데 전체 코드를 재작성해야 하는 상황이 매주 오셨다고 한다. Web Speech API에서 Google Cloud STT로, 다시 Naver Clova로 바뀔 때마다 관련된 모든 컴포넌트를 수정해야 했다고 한다. 그중 해결과정이 가장 인상적이었다.

 

해결과정

1단계: 공통 인터페이스 설계

먼저 모든 STT/TTS 엔진이 공유할 수 있는 인터페이스를 정의했다. 각 모델의 특성은 다르지만, 본질적으로 하는 일(음성->텍스트, 텍스트->음성)은 같다는 점에 착안한 것이다.

 

2단계: 전략 패턴 + 팩토리 패턴 적용

모델별로 구현체를 분리하고, 팩토리에서 설정에 따라 적절한 엔진을 생성하도록 했다. 이렇게 하니 새로운 모델 추가는 새 클래스 하나만 만들면 되고, 기존 코드는 건드릴 필요가 없어졌다.

 

3단계: React Hook으로 개발자 경험 개선

복잡한 내부 로직은 커스텀 훅으로 감싸서 개발자가 쉽게 쓸 수 있게 했다. `useSTT()` 하나로 어떤 모델이든 동일하게 사용할 수 있도록 했다.

 

---

 

3-2. 인상적이었던 포인트들

문제가 생기면서 점진적으로 디버깅 도구 추가 

음성 처리 과정에서 문제가 생기기 시작하자, 어디서 막히는지 파악하기 위해 상태 추적과 모니터링 도구를 점진적으로 추가한 점이 인상적이었다. 브라우저 개발자 도구에서 실시간으로 STT/TTS 상태를 확인할 수 있게 만든 건 실용적인 해결책이었다. 복잡해지는 시점에서 빠르게 디버깅 환경을 구축한 게 핵심인 것 같다.

 

기술적 완벽함보다 사용자 편의성 우선

연속 대화가 기술적으로는 더 자연스럽지만, 실제 사용자들의 말하기 패턴을 고려해서 Push-to-Talk 방식을 택한 점이 인상적이었다. "띄엄띄엄 말하는 사람과 연속으로 말하는 사람" 모두를 배려한 현실적인 선택이었다. 개발자로서는 기술적으로 멋진 기능을 만들고 싶겠지만, 실제 사용자 경험을 우선시한 판단이 돋보였다.

 

---

 

 

3-3. 나는 이걸 당장 적용해볼수 있을까?

1. 추상화는 필요할 때 점진적으로 - 처음부터 과도하게 추상화하지 말고, 패턴이 보일 때 리팩토링하자
2. 3개월 후의 나를 위한 코드 쓰기 - 주식과 네이밍에 조금만 더 신경 쓰면 미래의 내가 고마워한다
3. 기술적 완벽함보다 실제 사용성 우선 - 사용자 실제로 어떻게 쓸지 상상하며 개발하자
4. 복잡해지면 바로 디버깅 환경 구축 - 문제가 보이기 시작할 때가 디버깅 도구를 만들 적기다

이 섹션을 들으면서 "좋은 개발자"가 무엇인지 다시 생각해봤다. 최신 기술을 완벽하게 적용하는 개발자가 아니라, 변화하는 요구사항에 유연하게 대응하면서도 동료 개발자와 사용자 모두를 배려할 수 있는 개발자 말이다.

 

변화가 많아서 좌절하는 대신에 그 변화를 받아들이고 대응할 수 있는 구조를 만들어내는게 중요해보였다. 앞으로 내가 짜는 코드도 "이게 바뀌면 어떻게 할까?" 항상 염두에 두고 작성해야겠다. 그게 미래의 나와 동료들에게 하는 가장 큰 배려 테니까.

 

 

---

4. 가장 인상 깊었던 세션: TanStack Query 너머를 향해! 쿼리를 라우트까지 전파시키기

솔직히 세션 제목을 보고 상상이 안 갔다. 상원님이 토스 SLASH 22에서 김도환님 발표를 들으며 자극받았던 것처럼, 이번 상원님의 세션에서 "나도 언젠가 이런 라이브러리를 만들 수 있을까?"라는 생각이 들게 했다. 특히 TanStack Query와 React Server Components(RSC)의 조합에서 겪는 현실적인 문제점들과 그에 대한 해결방안을 제시한 점이 인상 깊었다.

 

---

 

4-1. 문제인식: useQuery의 복잡성

발표에서 가장 인상적이었던 부분은 useQuery가 반환하는 수많은 속성들을 적나라하게 보여준 순간이었다. 실제로 개발하다 보면 이런 상황을 마주하게 된다.

const queryResult = useQuery({
  queryKey: ['posts'],
  queryFn: fetchPosts
});

// 이 중에서 진짜 필요한 건 data뿐인데...
console.log(Object.keys(queryResult));
// 출력 결과: ['data', 'error', 'isLoading', 'isFetching', 'isError', 
//           'isSuccess', 'status', 'fetchStatus', 'isRefetching', 
//           'isStale', 'dataUpdatedAt', 'errorUpdatedAt', ...]

"useQuery에 값이 너무 많다"는 솔직한 표현이 개발자라면 누구나 공감할 만한 지점이었다. 실제로 대부분의 경우 우리가 필요한 건 data뿐인데, 많은 값이 딸려온다.

---

 

4-2. Dataready 프레임워크

상원님이 제시한 Dataready 프레임워크의 핵심은 단순화였다. 기존 방식과 비교해보면 차이가 명확하다.

기존 TanStack Query + RSC방식

// 서버 컴포넌트에서 prefetch
export async function PostsPage() {
  const queryClient = new QueryClient()
  await queryClient.prefetchQuery(postsQuery)
  
  return (
    <HydrationBoundary state={dehydrate(queryClient)}>
      <Posts />
    </HydrationBoundary>
  )
}

// 클라이언트 컴포넌트에서 사용
function Posts() {
  const { data } = useQuery(postsQuery)
  return data.map((post) => ...)
}

Dataready 방식

// 한 번에 해결
const Loader = dataready().using({
  field: queries.data.list()
});

const Client = Loader.component(({ data }) => {
  return data.field.QueryResult.map((post) => ...)
});

// 서버에서 자동으로 prefetch하고 클라이언트로 전달
export async function Page() {
  const props = await Loader.fetchQueries(queryEngine, extraContext);
  return <Client {...props} />;
}

 

내가 느낀 흥미로운 지점 

사실 이런 라이브러리를 처음 접했을 때 보통 드는 생각들(마이그레이션 비용, 러닝 커브, 의존성 부담 등)보다는 "이런 발상의 전환이 가능하구나"라는 점이 더 인상적이었다.

 

특히 arr.slice(0, offset + length) vs arr.slice(offset, offset + length) 무한 스크롤 최적화 설명에서, "서버 성능 부하가 심하다 → 클라 로직 부담이 심하다"는 어떤 걸 포기할 건가의 문제라고 인정한 부분이 현실적이었다.

 

 

 

4-3. 더 나은 도구를 향한 도전

'바퀴 재발명을 금지하자' 철학을 바탕으로 한 상원님 발표를 들으며 "완벽한 솔루션은 없지만, 더 나은 도구는 만들 수 있다"는 생각이 들었다. Dataready가 모든 프로젝트에 적합한 것은 아니겠지만, 현재 TanStack Query + RSC 조합에서 겪고  있는 문제들에 대해 현실적인 해결책을 제시했다는 점에서 큰 의미가 있었다.

 

무엇보다 "나도 언젠가 이런 도구를 만들 수 있을까?"라는 동기부여를 받았다는 것이 이 세션에서 얻은 가장 큰 수확이었다.

 

 

---

 

 

5. FEConf 현장에서만 느낄 수 있는 경험들

5-1. 부스체험과 소소한 즐거움

각 회사 부스를 돌아다니는 재미도 쏠쏠했다. 특히 집이 서울에서 꽤 먼 거리에 있는 나에게는 오늘의집에서 받은 보조배터리가 귀중했다. 덕분에 긴 귀갓길에도 휴대전화를 안심하고 쓸 수 있었는데, 집에 도착해보니 배터리가 겨우 3%나 남아있었다. 강남언니 부스에서 받은 귀여운 스티커들도 소소한 즐거움이었다.

 

 

4-2. 네트워킹에서 얻은 진짜 인사이트

TanStack Query 네트워킹 시간이 가장 기억에 남는다. 세션에서는 기술적인 내용을 배웠다면, 네트워킹에서는 그 기술을 둘러싼 사람들의 진솔한 이야기를 들을 수 있었다. 

참석한 대부분이 "TanStack Query를 그냥 잘 쓰고 싶어서" 모였다는 솔직한 동기가 인상적이었다. 거창한 이유가 아니라 단순히 더 잘 쓰고 싶다는 마음으로 모인 사람들과의 대화는 편안하면서도 유익했다. 

성원님은 AI 도구 활용 경험을 나누며 GPT나 Claude Code 등을 다양하게 사용하지만 "통계학적으로는 맞지 않는 부분도 있다"는 현실적인 조언을 해주셨다. 

그리고 어떤 분이 "라이브러리를 직접 만드는 건 정말 차원이 다른 수준"이라고 말했을 때 모두가 고개를 끄덕였던 순간도 기억에 남는다. 그중에서도 가장 와닿았던 것은 성원님의 "일단 해보는 게 중요하다. 그리고 숲을 보는 게 좋다"는 조언이었다. 완벽하지 않더라도 시작하는 것의 중요성과 세부적인 구현에만 매몰되지 않고 전체적인 그림을 보는 관점의 필요성을 동시에 강조한 말이었다.

 

 

---

 

 

5. 다음 FEConf를 기대하며

이번이 나에게 두번째 FEConf였다. 첫번째는 아무것도 모르는 완전 초보였다면, 이번에는 이제 막 아장아장 걸음을 떼는 18개월 아기같은 기분이었다.(18개월이면 벌써 잘 걷나?🤔)

 

여전히 배울 것투성이지만, 이번에는 프로젝트에 직접 적용하고 싶은 구체적인 아이디어들이 머릿속에 가득찼다. 그래서 더욱 즐거웠다.

 

다음에 또 참여한다면 꼭 골드 티켓으로 신청해보고 싶다. 그리고 무엇보다도, 이런 좋은 컨퍼런스가 앞으로도 오래오래 이어지길 진심으로 바란다.

 

FEConf 운영진분들, 발표자분들, 그리고 함께 참여한 모든 개발자분들께 감사드린다. 다음에 또 만나요~!

 

 

ps. 사진 공유해주신 든씨에게도 감사합니다.