🏃🏻 others

2025 FEConf 후기

dev.daisy 2025. 8. 23. 22:52
이번 FEConf는 단순히 발표를 듣는 것을 넘어서 현장에서 다양한 사람들과 이야기를 나누고 개발자로서 앞으로 어떤 방향성을 가져야 할 지 고민할 수 있었던 의미 있는 경험이였습니다!

세션마다 전달된 메세지는 다 달랐지만, 공통적으로 FE 개발자는 기술 그 자체가 아니라 비즈니스와 사용자의 가치를 연결해야 한다는 것을 느꼈습니다.

또 영상은 유튜브로 올라오겠지만 오프라인으로 직접 참여하면서 다른 개발자분들과 네트워킹도 하고 현장의 열기를 체감할 수 있었던 점이 가장 좋았습니다. 내년에도 꼭 참석해서 또 다른 배움과 자극을 얻어가고 싶습니다 :)

 


 

기존에는 유튜브로 FEConf 영상을 찾아보며 간접적으로 접했는데,

이번에 직접 현장에서 참여하면서 좋은 인사이트를 많이 얻게 되어 경험을 기록하고자 후기를 작성해보려고 합니다 :)

 

이번 컨퍼런스의 세션은 아래와 같이 다양하게 준비되어 있었고, 제가 들은 세션 목록은 다음과 같습니다.

세션 1. ‘memo’를 지울 결심 - React Complier의 미래 - 장용석 (리멤버앤컴퍼니)

세션 2. 중요하지만 긴급하지 않은 일, ‘그럼에도 계획해야 하는 웹 접근성’ - 김무훈 (A11YKR 커뮤니티)

세션 3. 1년에 10억원을 절약한, 강남언니의 SEO 웹 전략 공개 - 손준혁 (힐링페이퍼(강남언니))

세션 4. Tanstack query 너머를 향해! 쿼리를 라우트까지 전파시키기 - 임상원 (라프텔)

세션 5. 그리드 기반 웹 에디터 - 이선협 (마플코퍼레이션)


 

컨퍼런스는 세종대학교 광개토홀 B2층에서 진행되었습니다.

컨퍼런스 시작 전에 후원 기업에서 진행하는 강남언니, 오늘의집, moyo, aws 부스에서 이벤트도 진행했는데, 뽑기에서 1등에 당첨되어 키보드를 받아 시작부터 기분이 너무 좋았습니다 ㅎㅎ

 


 

참여한 세션은 총 네개였는데, 발표 세션 전에 당근 모임 탭을 활용해 '취업 및 이직' 이라는 주제로 다른 프론트엔드 개발자분들과 네트워킹 시간을 가졌습니다. 신입부터 7년차까지 다양한 연차의 FE 개발자 5-6명의 사람들이 모여 약 30분정도 각자의 고민과 경험을 나눴는데, 공통적으로 FE 시장에서 살아남기 위해서는 본인만의 뾰족한 강점을 가져야 한다는 조언을 들을 수 있었습니다.

 

덕분에 링크드인 교환도 하고, 우연히 같은 테이블에 이전에 슬랙으로만 대화했던 분을 만나기도 해서 신기했습니다!


 

세션 1. ‘memo’를 지울 결심 - React Complier의 미래

메모이제이션, 어디까지 해야할까?

React로 개발을 하다 보면 성능 최적화를 할 때 메모이제이션에 대해 고민하게 되는데, 메모이제이션은 과도한 리소스 소모, 의존성 배열 관리가 번거롭고 최적화 코드가 많아지면서 본질적인 코드의 가독성이 떨어진다는 한계점이 있습니다.

 

그래서 늘 '어떤 기준을 가지고 메모이제이션을 해야할까?'라는 고민이 있었는데요, 이를 신경쓰지 않고도 최적의 성능을 내기 위해서는 자동 메모이제이션이 되는 React Complier를 사용하는 것도 좋은 대안이 될 수 있습니다.

React Complier의 효과는?

React Complier는 코드를 자동으로 분석해 필요한 부분만 메모이제이션해줍니다.

  • 인터랙션 성능 향상
  • 네비게이션 속도 향상
  • 메모리 증가 없이 성능 향상 가능

React Compiler 동작 과정

React Compiler는 단순히 코드를 “트리밍”하는 게 아니라 코드를 분석 → 최적화 → 다시 변환하는 과정을 거칩니다.

 

1. AST (Abstract Syntax Tree)

- 코드 구조 분석

 

2. HIR (High-level Intermediate Representation)

- 코드의 흐름을 나타냄

- AST가 “모양”을 설명한다면, HIR은 “동작”을 설명

 

3. SSA (Static Single Assignment)

- 변수 재할당을 버저닝하여, 각 변수가 한 번만 할당되도록 변환

 

4. Reactive Function 분석

- 어떤 값이 시간에 따라 변할 수 있는지 분석

- reactive 값에 영향을 받는 코드 영역을 그룹화 → 필요한 부분만 메모이제이션

 

마지막으로 다시 JS 코드로 변환하여 최적화된 최종 결과물이 만들어집니다.

→ 우리가 작성한 리액트 코드를 컴파일러가 대신 분석하고 최적화해주는 방식이라고 이해할 수 있습니다.

제일 인상깊었던 부분은 컴파일러를 통해 수동 메모이제이션에서는 해방되었고, 변화하는 값들이 어떻게 흐르는가에 접근하는 것이 더 중요하다는 내용이였습니다. React를 단순한 UI 라이브러리가 아니라 언어처럼 다루는 감각이 중요한 역량이 될 것 같습니다.

 

https://ko.react.dev/learn/react-compiler

 

React 컴파일러 – React

The library for web and native user interfaces

ko.react.dev


세션 2. 중요하지만 긴급하지 않은 일, ‘그럼에도 계획해야 하는 웹 접근성’

  • 심미성 = “어떻게 보일지”
  • 접근성 = “무엇을 보여줄지”

보이는 것에만 집중하면 일부 사용자만 고려하게 되고, 모두가 인지하고 조작할 수 있는 보편성을 지향해야 비로소 ‘접근 가능한 웹’을 만들 수 있습니다.

접근성의 원칙 - POUR

접근성은 단순히 시각장애인을 위한 보조 개념이 아니라 모든 사용자를 위한 원칙입니다.

이를 POUR라고 정리할 수 있습니다.

  • Perceivable: 쉽게 인지할 수 있어야 함
  • Operable: 조작이 가능해야 함
  • Understandable: 이해할 수 있어야 함
  • Robust: 기계와도 호환 가능해야 함

접근성을 지키는 방법

1. 시멘틱 마크업 우선

HTML 요소만 제대로 사용해도 상당 부분 접근성이 보장됩니다.

하지만 커스텀 UI나 서드파티 컴포넌트를 쓰는 경우에는 WAI-ARIA 속성을 활용해야 합니다.

  • ARIA = Accessible Rich Internet Applications
  • 역할(role), 상태(state), 속성(property)을 명시해 보완
    ex) 스크린리더가 실시간으로 마우스 위치나 UI 상태를 읽어줄 수 있음

단, 필요할 때만 최소한으로 사용해야 하며, 잘못 쓰면 오히려 접근성을 해칠 수 있다는 점도 고려해야 합니다.

2. 초점 흐름(Focus Flow) 설계

접근성은 키보드 내비게이션에서도 드러납니다.

  • tab 순서, 화살표 이동, 초점 이동이 자연스러워야 함
  • roving tabindex 같은 패턴을 적용해 초점을 올바르게 이동시켜야 함

3. Headless UI 적극 활용

요즘 많이 쓰는 Headless UI 라이브러리들은 이미 접근성을 지원하도록 설계되어 있습니다.

불필요하게 직접 구현하기보다 기본기를 믿고 맡기는 것이 더 안전합니다.

 

4. UI 테스트에서 접근성 활용

Playwright, Testing Library 같은 UI 테스트 도구는 접근성 트리를 기반으로 동작하기 때문에 적극적으로 활용할 수 있습니다.

  • aria-controls 같은 속성을 활용하면 컴포넌트 간 관계를 명확히 표현 가능
  • UI 테스트는 두 가지 방법으로 접근성을 검증할 수 있습니다.
    1. Assertion: 요소를 쿼리해 기대하는 텍스트/속성 확인
    2. Snapshot: 스크린샷이나 DOM 스냅샷을 비교해 변경 감지
웹 접근성은 “긴급하지 않은 일”처럼 보일 수 있는데, 계획하지 않으면 결국 놓치게 되는 중요한 일 중 하나라고 생각합니다. 시멘틱 마크업으로 기본기를 지키고, 필요할 때만 WAI-ARIA를 보완적으로 사용하며, 초점 흐름과 UI 테스트까지 챙긴다면 그 결과는 단순히 장애인을 위한 배려가 아니라 모든 사용자가 편하게 쓰는 웹, 나아가 검색엔진과 AI가 더 잘 이해하는 웹으로 이어집니다. 웹 접근성은 결국 “모두를 위한 UX”라는 점이 다시 한번 와닿았습니다.

세션 3. 1년에 10억원을 절약한, 강남언니의 SEO 웹 전략 공개

왜 SEO인가?

강남언니는 웹 유입을 통한 앱 다운로드 → 예약 전환으로 연간 10억 원 이상의 가치를 만들어냈습니다.

  • 마케팅 유입 대비 2.7배 높은 전환율
  • 단순 비용 절감을 넘어 매출로 직결

SEO는 단순 노출이 아니라 비즈니스 임팩트를 만드는 전략이었습니다.

 

강남언니 채용 오픈 후 지원한 약 550개의 웹 개발자 이력서에서도 SEO는 많이 사용되고 있습니다.

실제로 지원자들이 자주 언급한 키워드가 시멘틱 태그, 메타 데이터, LCP였지만, 이는 임팩트와 직접 연결되진 않는 개선 액션이라고 합니다.

중요한 건 퍼널 단계별 전략적 접근이었습니다.

 

SEO 퍼널 전략

웹 가치는 브랜딩, CAC, LTV와 연결됩니다. 퍼널은 다음과 같습니다.

  1. 검색 노출 (Discover → Crawl → Index)
  2. 검색 유입 (클릭 유도, 메타태그, 시멘틱 태그, 구조화 데이터)
  3. 앱 내 전환 (예약 / 구매)
  4. 브랜드 신뢰 강화

전략 1. 페이지를 더 많이 노출시키기

크롤링이 많이 된다고 해서 검색 노출이 증가하는 것은 아닙니다. 크롤링이 많이 되더라도 인덱싱이 되지 않으면 노출디지 않습니다.

여기서 중요한 개념이 크롤링 버짓(Crawling Budget)입니다.

  • 크롤링 버짓 = 검색엔진 로봇이 하루 동안 우리 사이트에 할당하는 총량
  • 버짓을 늘리려면?
    1. 페이지 크기 줄이기 (LCP 개선)
    2. 퀄리티 높은 페이지에 집중 (= 크롤링 버짓을 키운다)

LCP 개선 = 크롤링 효율 = 더 많은 페이지 인덱싱 → 노출 확장

전략 2. 클릭을 유도하기

검색 결과에 노출된다고 끝이 아니라 클릭을 유도하기 위한 방법을 사용해야합니다.

  1. 메타 태그: 언어/국가별 메타 처리 → 글로벌 사용자도 적절한 언어로 노출
  2. 시멘틱 태그: h1, h2 태그 활용 → 네이버 등에서 인터랙티브하게 노출
  3. 구조화 데이터: 구글 검색에 다양한 정보 제공

전략 3. 신뢰와 권위 높이기

  1. Core Web Vital 관리 → 특히 LCP는 크롤링 효율과 직결
  2. External Link Management → 신뢰도 높은 사이트에서 링크 획득
  3. Page Silo 구조 → 관련 주제를 묶어 전문성을 어필, 사이트 권위 강화

SEO 분석 방법

  • Google Search Console → 기본 중의 기본
  • User Tracking 툴 병행 → 실제 전환까지 이어지는 흐름 파악
단순히 SEO = 검색 노출이 아니라, 퍼널 전체를 아우르는 전략이라는 점이 인상깊었습니다!

- SEO는 곧 비즈니스 임팩트이고, 퍼널 단계별로 전략을 달리해야 한다.
- 기술적 개선(LCP, 시멘틱 태그 등)과 비즈니스 목표를 연결하는 게 중요하다.

세션 4. Tanstack query 너머를 향해! 쿼리를 라우트까지 전파시키기

1. React Server Component(RSC) 빠르게 살펴보기

RSC는 서버만 알고 있는 정보(DB, 서버 자원)를 클라이언트로 직접 가져올 수 있게 합니다.

  • 기존에는 클라이언트 훅(useEffect)에서 API를 호출해야 했지만,
  • RSC는 hooks 대신 await 기반 비동기 연산을 활용해 데이터를 불러옵니다.

“그럼 Next.js 쓰면 되는 거 아닌가?” 싶지만, 실제 앱 규모가 커지면 이야기가 달라집니다.

 

2. TanStack Query와 RSC가 함께하는 법

현실적으로 복잡한 앱(무한 스크롤, 캐싱/리트라이 등)을 RSC만으로 처리하기는 어렵습니다.

  • RSC는 서버 데이터 전달에는 좋지만,
  • 클라이언트에서 반복적으로 데이터를 다루는 로직은 TanStack Query가 여전히 더 유용합니다.

따라서 RSC + TanStack Query 조합이 가장 실용적입니다.

 

3. RSC와 친해지는 방법

토스 Lash 22에서 김도환 님이 언급한 구조가 소개되었습니다.

각 컴포넌트는 특정 리소스에 의존한다는 개념입니다.

 

즉, 쿼리를 정의하고 이를 컴포넌트 단위로 분리해서 관리하는 방식입니다.

4. 쿼리의 정의

  1. 캐시가 가능해야 한다.
  2. 비동기 연산이다.
  3. 읽기 전용 연산이다.
  4. 같은 쿼리 연산은 같은 키를 가진다.

쿼리를 단순 API 호출로 보지 말고, “재사용 가능한 데이터 리소스”로 바라봐야 합니다.

 

단순히 RSC vs TanStack Query의 대립 구도가 아니라,
“서버 데이터는 RSC로, 클라이언트 캐싱/상호작용은 Query로” 사용하는게 어떨지 제안해주신 부분이 인상깊었습니다.

앞으로 Next.js + TanStack Query 프로젝트를 설계할 때, 쿼리를 단순 호출이 아닌 리소스로 정의하고 라우트 전반에 전파하는 구조를 먼저 고민해보려고 합니다!

 


 

+) '그리드 기반 웹 에디터' 라는 이선협님의 세션도 짧게 들었는데,

지금 코딩테스트 스터디를 진행하면서 읽고있는 책의 저자분이셔서 너무 신기했습니다!

(책 잘 읽고 있다고 전달드릴 기회가 있어서 좋았습니다)

https://product.kyobobook.co.kr/detail/S000213641007

 

코딩 테스트 합격자 되기: 자바스크립트 편 | 이선협 - 교보문고

코딩 테스트 합격자 되기: 자바스크립트 편 | ★ 코딩 테스트 합격자가 되는 가장 확실한 방법! ★ 프로그래머스 제공, 전문가가 모여 엄선한 빈출 100 문제로 철저하게 대비하세요!신입 사원 코

product.kyobobook.co.kr