KnowledgeBase/PARA/04_Archive/이전 Root/98. 미분류/FE Conf 타임테이블

FE Conf 후기

개요

지인이 FE Conf 2025 갈거냐고 물어봤다.
(본인은 안간다고 함)

나는 평일에 하는줄 알고
회사에서 시간죽이느니 거기라도 다녀왔다는 생각에 신청했다.

출발 전 날

전날 집에 날아다니는 날파리를 잡으려고 살충제를 꺼내다가 폰이 박살 났다.
어지간하면 그냥 쓰겠는데, 휴대폰의 절반이 초록빛이라 선택지가 없었다.

눈물을 머금고 수리센터를 찾아보니 다행히 FE Conf 행사장 근처에 AS센터가 있었다.

나는 어지간하면 다음날 일정이 있더라도 컨디션 관리를 하지 않는편인데,
휴대폰 수리같은 대소사는 어쩔 수 없었다.

아침

아침 일찍 일어나서 어느정도 상쾌한 마음으로 세종대로 출발했다.
휴대폰 화면이 잘 보이지 않아 음악을 듣기 어려우니
지금 내가 얼마나 안좋은 상황이 되었는지 감이 오기 시작했다.
(수리를 미뤘다면 고통이 오래갔을 것이다.)

다행히 AS센터가 열리기도 전에 도착해 일찍 수리를 받을 수 있었지만
수리비에는 자비가 없었다.

무려 40만원

진지하게 수리를 포기하고 깡통 휴대폰을 써야하나 고민했지만
이미 잠을 포기하고 AS센터까지 온 내 기회비용이 너무 아쉬워서
그냥 40만원을 나의 멍청비용에 추가했다.

수리를 하고 나서 밖으로 나오니 고작 9시반이었다.
12시 행사 시작이니 엄청나게 많은 시간이 남았다.

근처 스타벅스에서 커피를 마셨다.
딱히 준비해온것이 없어 마냥 멍때리다가 마침 가방에 넣고 잊어버렸던 책이 생각났다.

독서

그 책은 밀리의 서재 무슨 행사로 받은 교보문고 신인작가 단편선 2025였다.
신인작가 단편선은 21년쯤 판교 책방에 출퇴근할때 재미있게 읽은 기억이 있다.

원래 물건이든 음식이든 비싸고 유명한게 제 값을 한다는 주의지만, 책은 다르다.
난 가끔 거장이나 기성 작가의 글보다 신인작가의 글이 좋다고 느낀다.
예를들어 수십권의 책을 낸 최재천과 기욤 뮈소는 좋아하는 작가지만, 가끔 글에서 생명력이 느껴지지 않을때가 있다.
뭐랄까 그냥 책으로 기능하기위해 필요한 것들을 적절하게 배치하여 만든 책, 책의 문법을 그대로 따른 그저 책일 뿐이라고 느껴진다.
이것은 어쩔 수 없다고 생각한다. 그들에게 이 책은 그저 자신이 낸 수많은 책 중 하나일테니

그런 관점에서 신인작가들의 등용문이라고 할 수 있는 공모전 수상작을 읽노라면 그들의 진한 생명력이 느껴진다.
그들의 간절함이나 그들의 모든것을 쏟아내었다는 그런 느낌이 든달까?
이미 4년이 지났지만 아직도 21년 수상작들이 머릿속에 남아있는 이유이다.
(더 최근에 읽은 기욤 뮈소의 장편 소설은 읽고나서 독후감도 썼는데 기억이 잘 안난다)


시작

단편선 하나를 읽고나니 시간이 다 되어서 입장할 수 있었다.
생각보다 사람이 많이 와 있었고, 여러 행사도 진행하고 있었지만
빨리 가서 앞에 앉아야 잘 들을 수 있을 것 같아 서둘러 자리를 잡았다.
함께 컨퍼런스를 듣기로 한 지인도 이때쯤 도착했다고 연락을 보내왔다.

스벨트를 통해 리액트 더 잘 이해하기

1. 개요

FE 커뮤니티에는 늘 수상할정도로 스벨트를 열정적으로 사랑하는 개발자들이 있다.
(생각해보니 대부분은 이사람임)

다만 한국에서는 아직 스벨트로 프로덕트 레벨에서 의미 있는 성과가 크게 없어서 개인적으로는 크게 관심이 없었다.

그럼에도 불구하고 개발자로서 깊게 공부하다 보면, 프레임워크 자체보다 언어와 라이브러리의 동작 원리에 집중하게 된다.
이런 맥락에서 스벨트를 경험하면 오히려 리액트를 더 잘 이해하는 데 도움이 될 수 있다는 생각이 들어서 이 강연을 선택했다.

2. 강연 요약

발표자는 리액트와 스벨트를 비교하면서 얻은 인사이트를 공유했다.
주요 주제는 세 가지였다:

1. 리렌더링 방식 차이

   • 리액트: 상태 변경 시 해당 컴포넌트 전체가 재실행됨 → 자식까지 영향
     → 따라서 useEffect, useCallback, useMemo 같은 최적화 기법 필요
     → 참조 변경 여부를 기반으로 리렌더링 판단 (immutable 패턴 필수)

   • 스벨트: 사용된 부분만 업데이트(FGR, Fine-Grained Reactivity)
     → 값 사용 순간 의존성이 자동 등록되고, 상태 변경 시 관련 effect만 재실행
     → 동적 추적 시스템 기반 (observable, effect)
     → 불필요한 최적화 도구가 덜 필요

2. DOM 조작 패턴

   • 리액트: hook + 컴포넌트 패턴 기반, 모달/드롭다운 같은 DOM 조작은 비교적 복잡

   • 스벨트: use 디렉티브로 DOM 생명주기에 직접 연결 가능

   • React 19: 스벨트처럼 element 생성·소멸 시점 콜백을 받을 수 있게 개선됨
     → 점점 더 직관적인 DOM-로직 연결이 가능해짐

3. 애니메이션 구현

   • 리액트: 기본적으로 애니메이션이 불편 → framer-motion 같은 외부 라이브러리에 의존

   • 스벨트: transition 디렉티브로 간단히 구현 가능 (fade, slide, fly 등 내장)
     → 커스텀 트랜지션도 쉽게 작성 가능

   • React 19: ref 콜백을 통한 생성/소멸 시점 애니메이션 가능 → 스벨트와 접근성 유사해짐

3. 발표자의 메시지

• 리액트를 잘하는 것도 중요하지만, 다른 프레임워크 경험이 리액트를 더 잘 이해하는 지름길이 될 수 있다.
• 스벨트의 장점을 경험하면 “리액트에서 왜 이런 최적화 기법이 필요한가”를 더 명확하게 이해할 수 있다.
• 특히 FGR 개념, DOM 직관적 조작, 내장 애니메이션은 리액트에도 적용할 수 있는 시사점을 준다.

4. 개인적 인사이트

• 발표자의 의견처럼 리액트를 먼저 배우고, 이후 스벨트를 찍먹해 보는 것이 가장 합리적이라는 생각이 들었다. → 내 생각과 동일.

• 단, 발표에서는 스벨트의 장점 위주로만 언급했는데, 스벨트의 단점도 반드시 짚고 넘어갈 필요가 있다.

  • 생태계 규모가 작음 (라이브러리, 커뮤니티, 사례 부족)

  • 대규모 프로덕션 경험 부족

  • 한국 시장에서는 아직 레퍼런스 프로젝트가 거의 없음

결론

스벨트는 한국 프로덕트 레벨에서 실질적 성과는 부족하지만, 개발자 개인의 성장 관점에서는 매우 유익한 학습 도구다.
스벨트의 동작 원리를 학습하면 리액트의 최적화 방식, DOM 제어, 애니메이션 구현을 더 깊이 이해할 수 있다.
즉, “스벨트를 사랑하자. 하지만 리액트를 더 잘하기 위해서.”

'memo'를 지울 결심 React Compiler가 제안하는 미래

0. 개요

A홀이 노잼일 것 같아서 골랐다.
(리액트 네이티브)

1. 왜 React Compiler인가

리액트는 트리 구조로 동작하며, 부모 → 자식 컴포넌트가 재귀적으로 호출된다.
이 때문에 성능 최적화를 위해 우리는 흔히 메모이제이션(memo, useMemo, useCallback) 을 사용한다.

하지만 문제점은 명확하다:

• 모든 곳에 쓰면 리소스 낭비
• 어디에 적용해야 효율적인지 판단하기 어렵다
• 잘못 쓰면 오히려 성능 악화 및 코드 복잡도 증가

-> 이 문제를 해결하기 위해 제시된 해법이 바로 React Compiler.
즉, “메모이제이션을 자동화하는 컴파일러” 라고 볼 수 있다.
리액트 컴파일러가 뭐 엄청 거창한게 아니라 걍 메모이제이션만 해주는거였다.

2. React Compiler 동작 원리

2.1. 캐시 기반 동작

• useMemoCache를 내부적으로 활용
• 캐시에 값이 있으면 재사용, 없으면 새로 계산
• “비싼 계산”은 최초 한 번만 수행하고 이후에는 캐시된 값 사용

2.2. 컴파일 파이프라인

컴파일러는 코드 변환 과정을 거쳐 최적화된 결과물을 만든다.
과정이 아주 복잡하다.

1. AST(Abstract Syntax Tree)

   • Babel 같은 툴로 JS 코드를 추상 구문 트리로 변환

2. HIR(High-level IR)

   • AST를 제어 흐름 그래프(CFG) 로 변환

3. SSA(Static Single Assignment)

   • 각 변수는 단 한 번만 할당
   • 재할당되는 변수는 버저닝(x1, x2, x3) 처리

4. React Function 분석

   • 시간에 따라 변할 수 있는 값을 추적
   • ex) 함수 파라미터, hook 결과, 전역 상태, 그로부터 파생된 값들
   • 이를 reactive 값이라 정의

5. JS 코드로 재생성

   • 최종적으로 메모이제이션/캐시 최적화된 JS 코드 산출

3. 캐싱 전략

3.1. 리스트 렌더링 (map)

• 배열 전체에 대한 캐시 슬롯 + 각 항목별 슬롯 계층 구조
• 배열이 바뀌지 않았다면 변경된 항목만 다시 그림
  → 리스트 전체 리렌더링 방지

3.2. 조건 분기 (if/else)

• 분기마다 별도 캐시 슬롯 생성
• <A/> → <B/> 전환 후 다시 <A/>로 돌아오면 이전 캐시 그대로 사용
  → 전환 성능 개선

---

4. 한계와 도전 과제

4.1. 낙관적 가정(Optimistic Assumptions)

• 컴파일러는 순수성(purity) 을 가정하고 최적화함

• 그러나 실제 코드가 순수하지 않으면 → 런타임에서 예기치 못한 동작 발생 가능
  -> 코드를 가이드라인대로 짰다는걸 어떻게 확신할 수 있지?

• 대응:

  • ESLint 규칙 (순수성/의존성/Hook 규칙 검증)
  • 모듈·라우트 단위의 점진적 도입
  • React Forgive(실험적 도구, 일부 규칙 보정)

4.2. 번들 크기 증가

• 코드 변환 후 번들 크기 최대 2배 증가 보고
• 컴포넌트 수에 선형적으로 증가
• 대응: 코드 스플리팅, 청크 전략, 옵트인 최소화

---

5. React Compiler가 요구하는 개발 습관

• React를 “언어”처럼 다룰 것

  • 순수 함수 지향, 부수효과 격리, 엄격한 규칙 준수

• 데이터 흐름(Dataflow) 추적

  • state/props/context가 어디서 변하고 어디서 소비되는지 명확히 인지

• 캐시 계층 구조 이해

  • 반복·분기 구조에서 어떤 캐시 슬롯이 쌓이고 재사용되는지 숙지

---

6. 결론

React Compiler는 “memo, useMemo, useCallback 없는 세계” 를 지향한다.

• 개발자가 최적화 포인트를 직접 찾지 않아도,
• 컴파일러가 자동으로 캐싱 전략을 적용해 성능을 보장한다.

물론 순수성 유지, 번들 크기, 런타임 안전성 등 도전 과제가 남아 있지만,
React 팀은 이를 ESLint·도구·점진적 도입을 통해 풀어나가고 있다.

-> 미래의 리액트 개발은 최적화 기법(메모이제이션)이 아니라 엄격한 문법을 통해 발전할 것이라고 말했다.

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

1. 개요

T 멤버십 앱 개발을 하면서 웹 접근성은 반드시 고려해야 하는 요소라는 생각이 들어 이번 강연을 듣게 되었다.
SKT의 B2C 앱은 단순한 기능도 복잡하고 까다로운 배포 파이프라인이 존재하는데,
이것이 전부 접근성 때문이다.(alt, tabIndex 등 무슨 정부 인증 받아야 된다고 함)
이걸 개발자 관점에서 최적화 할 수 있을지 고민해봐야 한다.

강사가 엄청 병아리개발자여서 신기했다.

2. 웹 접근성이란?

• 모든 사용자가 동등한 방식으로 제품을 인식·이해·조작할 수 있도록 설계하는 것.
• 이는 사용자 중심 디자인의 또 다른 관점이며, 포용적 설계 와 직결된다.

예시:
열차 조회 서비스 → 예쁘게 보이는 UI보다 잘 보이는 UI가 더 중요하다.
리뉴얼 후 더 세련되더라도 접근성이 떨어지면 사용자 경험은 나빠진다.
-> 쿠팡도 그렇고 우리 앱도 그렇다.

3. 접근성의 4대 원칙 (POUR)

1. 인지(Perceivable)

   • 대체 텍스트, 자막 제공
   • 모션 최소화, 고배율/고대비 지원

2. 조작(Operable)

   • 키보드·터치 등 다양한 입력 방식 지원
   • 포커스 이동, 키보드 네비게이션 고려

3. 이해(Understandable)

   • 예측 가능한 상호작용
   • 일관된 UI 제공

4. 견고함(Robust)

   • 보조기기(스크린리더, 음성인식 등)와 다양한 환경에서 정상 동작

4. 접근성 구현 방법

• 시멘틱 마크업: header, nav, main, footer 같은 태그를 올바르게 쓰는 것만으로도 기본 보장.

• WAI-ARIA 활용: HTML이 제공하지 못하는 역할·상태를 보강.

  • 상태 속성: aria-expanded, aria-checked
  • 관계 속성: aria-labelledby, aria-describedby
  • 동작 속성: aria-live, aria-hidden

단, class 이름에 의미를 부여하는 것은 접근성과 무관하다.
가능한 한 시멘틱 태그 → 부족한 경우에만 ARIA를 보충적으로 활용해야 한다.

5. Headless UI & 테스트

• Headless UI 라이브러리: 접근성 지원이 내장되어 있어 직접 속성을 하나하나 지정할 필요가 줄어든다.
• 테스트 전략:
  • 기존: getByRole 같은 단순 접근성 쿼리
  • 개선: 접근성 트리(Accessibility Tree) 를 활용한 정밀 테스트

6. 고려해야 할 한계

• ARIA는 아직 브라우저별 표준화가 완벽하지 않음 → 일부 환경에서 예측 불가능한 동작 가능.
• 따라서 “모든 상황에서 똑같이 보장된다”는 전제는 위험하다.

7. 소감

• 강연 주제와 자료는 유익했지만, 강사의 전달력이 부족해 이해하기 다소 어려웠음.
• 다만 큰 메시지는 분명했다:
  -> 접근성은 나중에 덧붙이는 게 아니라, 초기부터 파이프라인에 포함시켜야 한다.
  -> 우린 망했다.

라이트닝 토크

지속 가능한 개발이란

• 난 시니어 개발자다.
• 오늘 개발 얘기는 안할거지만 어쩌면 가장 중요한 얘기일수도 있다.
• 지속 가능한 개발이란 건강이다
• 난 건강이 무너졌다
  • 딥다이브 해봤다 개발자처럼
  • 장애보다 무서운건 안보이는 코드다
    • 버그보다 무섭다
  • 안구 건조증, 눈피로, 근시 등등
  • 나만 그런거 아닐거다
    • 난 한번 튜닝을 했다
• 도구를 쓰자
  • IDE보다 더 중요한건 건강 도구다
    • 야간모드
    • 눈 찜질기
    • 인공 눈물
    • 모니터암
  • 답은 페이투윈이다.
  • 커브드 모니터는 눈에 좋다
    • 경추에도 좋다
  • 양손을 열심히 비비고 눈두덩이에 얹으면 좋다
• 다크모드
  • 어두울때는 다크모드가 눈에 좋지만
  • 밝은곳에서는 라이트모드가 좋다
• 블루라이트
  • 블루라이트와 시력손상은 관련있는지 의학적 증거가 없다
  • 수면에는 도움이 된다
• 눈 감기
  • 눈감아도 눈이 쉬지 않는다
  • 멀리 보는게 더 좋다
• 결론
  • 멀리보기
  • 눈 운동
  • 장비 셋팅
  • 전문가
  • 개발자 건강은 눈 외에도 챙길것이 많음
    • 손목, 경추 등

사수에 기대지 않는 성장법

• 난 5년차 FE 김재환이다
• 난 5년동안 사수가 없었다
• 꼬리질문, T자형 성장, 기본 충실 등등 좋은말들이지만 난 당장 눈앞의 문제들에 고민했다
  • 여력이 없었으니까
• 1년차때 경험을 얘기하자면 한파일에 1200줄
  • 요건 하나 작업하는데에 하루씩 걸림
  • 기획하나 바뀌면 하루가 걸림
  • 코드에는 책임이 따른다고 배움
  • 그래서 모듈화, 파이프라인 구조 적용함
    • 복잡도 증가로 인한 리팩토링을 하게됨
    • 결과적으로 봐야할 것이 늘어났을뿐 크게 바뀐게 없음.
    • 바퀴를 재발명 하지 말자는 것을 배움
• 3년차때 디자인 패턴 습득, 적용함
  • 여전히 기획 변경, 대응은 느림
  • 클린아키텍처라는 책을 봄
    • 객체지향 패러다임을 알게됨
  • 데이터 주도 설계에 대해 공부하게 됨
    • 나름대로 변경에 유연한 시스템을 구축함
  • 이전에 시도가 실패했던 이유는 기초가 부족했기 때문이라는 것을 배움
• 내가 배운 성장법
  • 눈앞의 문제를 각자의기준으로 정의
  • 최선을 다해 해결
  • 끝나면 회고
• 결론
  • 나의 성장은 다른 사람의 조언이 아닌, 지금 눈앞의 문제를 풀고 회고하는 과정에서 나온다.

주니어 개발자의 1인 생존기

• 나는 임채준이다
• 내가 입사하자마자 팀원 3명이 3달만에 다 나갔다
  • 내 얘기 듣고 니들은 어땠는지 말해줘도 좋을 것 같다.
• 내가 이 발표를 하게 된 이유는
  • 시스템과 사람과의 관계에 대해 이야기하고싶다
  • 동료는 자산이지만 리스크다
• 4명 -> 1명이 됐다.
  • 팀원들이 타팀과 싸우고 나갔다
  • 나도 나가고싶었지만 난 군인이라 못나갔다
    • tmi지만 난 내일 복무가 끝난다
• 그래서 문제들이 쌓였다
  • 처음듣는 업무 간 커뮤니케이션 히스토리
  • 기술부채
  • 시니어도 아닌데 시니어로서의 책임
• 어쩔 수 없이 원영적 사고를 하게 됐다
• 문제를 극복하려고 아래 내용들을 했다
  • 히스토리 도식화
  • 업무 범위 리스트업
  • 이해 관계자들에게 현재 상황 어필
    • 힘들다 라는 말을 잘 꾸며서 얘기했다
  • 업무 우선순위를 결정했다
  • 동료들과 많은 이야기를 나눴다
  • 내가 한일을 자랑했다
    • 내가 이렇게힘들었다
  • 돈을 올려달라고 했고, 성공했다.
• 지속 가능한 시스템 만들기를 리스트업하고 실천했다.
  • 기술 부채 목록화
  • 지속 가능한 코드 작성
  • 중요 코드 베이스 문서화
  • 코드 컨벤션 및 팀 내에 롤 정하기
• 하고싶은말
  • 스스로를 제한하지 말자
    • 주니어라고 주니어같이 일하지 말자
    • 어차피 하려고하면 다 된다
  • 철학을 가지자
    • 내가 왜 이걸 하고 있지? 에 대한 자기만의 답변을 가지자
  • 춤추는 별을 낳기 위해서는 내면의 혼돈을 가져야한다

비IT기업에서 웹 개발자로 살아남기

• 나는 남은경이다

• 취준생들에게 중요한 얘기를 하고싶다

• 난 4년차 제조업 기업에서 일하고잇다

• 모두가 IT기업에 갈 수는 없다

• IT기업은 별로 없고, 점점 줄어들것이다

• 생각보다 개발자는 주류가 아니다

• 개발자에 대한 시선은 이렇다

  • 컴퓨터 안되면 고쳐준다
  • 사내 와이파이 관리하는 사람
  • 뭔가 어려운거 하는사람

• 타팀은 이렇게 생각한다

  • 내가 말하는대로 만들어줘
  • 이렇게 동작하게 해줘
    -> 하면 해줘야 한다고 생각함

• 클린 아키텍처 이런건 비IT기업에서 사치이다.

  • 이해하고싶어하지 않는다

• 주니어가 입사하게되면

  • 코드리뷰
  • 테스트코드
  • 방법론

• 이런것들을 생각하게 되는데 의미가 없다.

• 개발자가 취해야 할 자세는 아래와 같다

  • 신뢰 얻기
  • 빠르게 소통하기
    • 빨리 만들기
    • 빨리 보고하기
    • 중간 공유하기
  • 예외케이스 이런건 알아서 처리하기
  • 결과물은 무조건 시각화
  • 말로 어필 열심히 어필하기

• 일 잘하는 애 <- 이 이미지를 만드는게 중요함

• 사실 나는 못살아남았다

  • 이번달까지 일하고 퇴사함
  • 블랙기업 다니지 마라
  • 눈물

팀 리드인데 팀원이 1명? 3명?

• 난 토스코어에서 FE인프라 하는 정석호이다
• 난 혼자서 일하다가 4명이 됐다가 축소됐다가 다시 커졌다
• 원래는 1인팀으로 커버가 가능했는데 인원이 5배가 되면서 못하게 됐다.
• 일 자체는 자동화가 가능했지만 커뮤니케이션은 인력이 필요하다
• 둘이 됐다
  • 커피챗 = 전체미팅
  • 내 목표 : 나를 클론하기
  • 너무 좋았다
    • 두사람이 상호보완 가능하다
• 넷이 됐다
  • 알아야 할 맥락이 많아졌다
  • 더 세분화되고 분산된 역할을 하게 됐다.
  • 매니징 업무를 하게됨
    • 팀원 관리
    • 팀원 성향 파악
      • 잘하는 사람 못하는 사람 착한사람 나쁜사람 있음
    • 개발문화 만들기
    • 반복업무 시스템화하기
    • 마일스톤 전략
    • OKR 및 우선순위
• 명확한 역할 기반 팀 빌딩이 중요하다

팀 빌딩과 성공하는 습관 기르기

• 난 당근 6년차 진혁이다.
• 나는 내가봐도 엄청나게 뛰어난 개발자이자 매니저다
• 난 초기 멤버부터 매니저까지 성장 과정을 공유하겠다.
• IC 시절에는 이랬다.
  • 약속한 날짜보다 하루 먼저 전달
  • 결과물 외에 기술적 산출물(NPM, 문서 등) 남기기
  • 스스로 자랑스러운 결과물 만들기
  • 팀 속도감 불어넣기
• 팀 빌딩 시절:
  • 팀의 존재 이유 정의
  • 팀 습관 설계 (정기 미팅, 공유 의식)
  • 생존 전략:
    • 내일 팀이 없어진다면 오늘 가장 후회할 일은?
    • 일주일 뒤 팀이 없어진다면 오늘 해야할 일은?
• 매니저 시절
  • 팀원 스스로 집중할 수 있게 코칭
  • 적절한 시점에 성장 기회 부여
  • 역할 조정으로 최적의 스쿼드 구성
  • 습관 유지와 디테일 관리
• 결론 :
  • 성공을 위해 모든것이 변해도, 변하지 말아야 할 것은 습관이다.
  • 니들이 여기 오기전까지 이직을 위해 노력한게 있어?
    • 그럼 그걸 평생 한다고 생각해
    • 안하면 못해
      

AI 시대에 프론트엔드 개발자가 살아남는법

• 난 유튜버다
• AI 전문으로 하고 있다
• AI는 무서울정도로 커졌다
  • 99.9% 를 AI가 해도 잘 돌아간다
• 난 인텔리제이보다 완벽한 IDE가 없을거라고 생각했다
  • 근데 나왔다
  • 지금 상상도 못한 일이 벌어지고 있다
• AI는 완벽한 파트너가 아니라 완벽하게 나를 대체하고 있다
• 프론트엔드 개발자가 생존하려면?
  • 프론트를 버려야한다
    • AI 사용 잘하는 개발자가 되어야 한다
  • 그동안은 개발자가 되기 위한 진입장벽이 있었다
    • 이젠 진입장벽이 없어졌다
  • 평범한 개발자들은 AI를 잘쓰는 사람을 절대로 이길 수 없다
    • 평범한 개발자들은 99.99%의 개발자들을 말하는것이다.
  • 예전에는 성장하기 위해 사이드프로젝트, 알고리즘 트레이닝 등을 공부했지만 이젠 의미가 없는 것 같다.
• AI를 잘쓰기 위해선 3가지만 알면 된다
  • 모델, 프롬프트, 컨텍스트
    ->
  • 적절한 LLM을 선택
  • 적절한 문맥을 제공
  • 적절한 프롬프트를 작성

라이트닝 토크 2

• 박현우: 킵올빌런 은퇴식

• 나는 트위터에 전세계 킵올 처리 안된 기업 박제하는 사람이다
• 트위터에서 전 세계 기업들의 word-break: keep-all 미적용 사례를 박제했던 경험 공유한다.
• 띄어쓰기는 한국어에서도 100년도 안 된 역사다
• CSS에서의 줄바꿈 처리(word-break)는 2001년 초안, 2003년부터 실제 지원 시작했다.
• 브라우저 최초 지원은 IE(인터넷 익스플로러)다.
• CSS 표준화·브라우저 구현의 역사와 맥락을 풀어낸 발표였다.

• 한상욱: 오픈소스 밥상차리기: 환경설정과 디버깅편

• 나는 평범한 스타트업에 다니지만, 노드, vercel 등 주요 오픈소스에 컨트리뷰터이다.
• 오픈소스 기여로 얻게 되는 인사이트와 학습 기회가 아주 많다.
• 오픈소스 처음 기여 시 많이 하는 실수들
  • 환경 구축 대충 하기
  • 공식 문서 안 읽고 버그라 착각
  • 어려운 이슈 도전하다 실패
• PR 성공 전략
  • 쉬운 이슈부터 (예: Mantine, React Hook Form → 문서 잘 돼 있고 리뷰 빠름)
  • 어려운 건 Next.js 같은 대형 프로젝트
    • 코드가 너무너무너무너무너무 어려움
    • 코드보면
      • 이건 "자바스크립트"다
    • 정도밖에 모름
• 환경 구축 & 테스트 환경 구성 중요
  • 린트, 프리티어, 패키지 빌드, 서비스 빌드, 전체 빌드 숙지
  • 대부분의 오픈소스들은 이게 매우 까다롭더라
• AI 활용해서 디버깅과 이슈 재현
  • 익숙해지면서 기여 확장
• 결론: 자주 쓰는 라이브러리부터, 바로 시작하라

• 최관수: 최신 CSS? 10년 뒤에 쓰면 되나요?

• 난 아이돌 관련 서비스 만드는 최관수다

• 프론트 개발자들이 CSS에 관심 없는 이유: 실무 적용까지 오래 걸림

  • Flexbox, Grid 같은 것들도 초안 → 브라우저 지원까지 6~8년 걸림

• 이번에 구글 IO에서 많은게 나왔다

  • 구글발표자도 쪼개면서 10년뒤에나 쓰게될거라 말함

• 그러나 최근엔 기간 단축 (예: Popup API → 5개월 만에 베이스라인 지원)

  • IE가 사라지고 브라우저 협업이 강화됨
  • 사용자 니즈 증가

• JS로 구현하던 걸 CSS로 대체 시 장점

  • 코드 단순화
    • 셀렉트박스를 커스텀 대신 최신 CSS로 개선하면 코드가 몇백줄에서 몇십줄이 됨
  • 렌더링 최적화
  • 접근성 향상
    • 셀렉트박스에서 키보드 지원 기능 등등

• 실무 적용 사례

  • Popup API: z-index/포커스 관리 문제 해결
  • Custom Select: 네이티브 기능 유지하면서 커스터마이징 폭 확대

• 결론: “10년 뒤에나 쓰자”가 아니라 “서비스 개선에 어떻게 쓸 수 있을까?”를 고민해야 한다

• 김재서: React Memoization 언제 적용하는 것이 좋을까요?

• 나는 강남언니에서 KOS만드는 김재서임

• 님들은 최적화 어떻게 하는게 좋다고 생각함?

  • 미리 일괄로 메모이제이션 걸기 vs 필요한 곳에만 걸기
  • 아마 많은 분들이 메모이제이션 필요한 곳에 걸어야 한다고 생각할텐데
    • 결론부터 말하자면 우린 그냥 다 걸었음...!

• 문제: 예약 현황/차트 페이지 진입이 매우 느림
  → 분석해보니 최상위 useLocation 의존으로 전체 리렌더 발생

• 해결 과정

  • 일괄 메모이제이션 적용 → 1650ms → 270ms (84% 개선)
  • 구조적 개선 (스토어 분리, 연산 분리) → 677ms → 48ms (93% 개선)

• 고민: 사전 최적화 vs 사후 최적화

  • 리소스 부족으로 성능 이슈를 즉시 고치기 힘듦
    • 보통 제품팀에다가 성능 개선하겠다고하면 혼남
  • 제품은 성장하며 반드시 성능 문제가 발생 → 사전 최적화 선택
    • 어차피 사전 최적화 안하면 나중에 최적화 안할거잖아

• 메모리 사용은 문제보다 이득이 크다

• React Compiler가 Memoization을 완전히 대체하지 않음
  → 우리는 컴파일러가 더 똑똑하게 해주는 보조 장치일 뿐이라고 생각함

• 손효정: UI 코드 생성 자동화를 프로덕션까지: 우리 팀은 Figma MCP + Cursor(AI)와 함께 일합니다

• 난 손효정이고 오늘의 집 FE 테크리드임 9명 팀 운영함

• 우린 피그마랑 커서 씀

• 우린 어떤 방식으로 하고 있는지 공유하고자 함.

  • 난 인테리어 좋아해서 한우물만 팜
    • 7년째임

• 문제: B2B와 B2C를 동시에 만족시킬 디자인 시스템 필요

  • 그러나 우리의 서비스는 1가지가 아님
    • B2B에는 적절해도 B2C에는 아쉬운 디자인 시스템
      • 그렇다고 디자인 시스템을 새로 만들기에는 시간이 너무 많이 듬
      • 기존 시스템에서 커스터마이징 해야 하는 경우가 너무 많음
      • 만들어놓고 안쓰는것들도 많음

• 해결 방향: 디자인 시스템 전체를 새로 만드는 대신, AI 기반 워크플로우 구축

  • 도구: Figma MCP + Tailwind + Shadcn + Cursor

• 프로세스

  • 개발: UI 코드 디렉토리와 비즈니스 로직 철저히 분리
  • 디자인: 토큰(컬러, 타이포, 보더 등) 체계 명확히 정의
  • 커뮤니케이션 구조 확립: 디자이너가 피그마 디자인
    → 링크 전달 → Cursor가 컴포넌트 생성

• 얻은 점

  • UI 코드의 90% 이상 자동화 성공
  • 디자인 QA에서 해방됨 (픽셀 단위 논쟁 사라짐)
  • 디자이너는 사용자 가치 테스트에 집중, 개발자는 설계/최적화 집중

• 교훈

  • 도구보다 구조/룰 세팅이 중요
    • 아주 아주 중요함
  • 디자인 토큰/디렉토리 설계/커뮤니케이션이 성공의 핵심

모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년

1. 개요

• 나는 플렉스의 김종혁이다
  • 강의 할 생각에 신난다
• 플랙스는 일주일 정기배포를 없앴다
• 14개의 모노레포로 쪼갰다
  • 참고로 올해 6월까지였다
• 플렉스는 올인원 플랫폼을 지향 → 여러 도메인이 강하게 연결됨
• 초기엔 모노레포 + Turborepo 도입 → 빠른 확장에는 도움
• 하지만 시간이 지나며 의존성이 폭발적으로 복잡해짐
  • 작은 변경도 전체 배포 필요
  • 빌드 그래프가 너무 커서 툴이 에러남
  • 일주일에 한 번 정기배포 → 모두가 동시에 모니터링해야 하는 불안정한 구조
• 결론: 모노레포 망함 → 폴리레포 전환 결정

2. 전환 과정

• 14개 모노레포를 폴리레포로 분리 (1년 5개월 소요)

• 개별 레포지토리로 분리하면서:

  • 빌드/버저닝/배포 프로세스 재정의
  • 각 패키지를 고립시켜 영향 범위 최소화

• 폴리레포 장단점

  • 단점 : 코드 파편화, 공유 어려움, 원자적 커밋 불가
  • 장점 : 경계가 물리적으로 강제됨 → 안정성·정기배포 부담 해소

3. 첫번째 교훈 : 경계 없는 공유 금지

• 경계 없는 export → 사이드이펙트 폭발
• 개발자는 빠른 작업을 위해 “쓸 수 있는 코드”는 다 씀 → 무분별한 확산
• “쓰지 말자” 캠페인은 소용 없음 → 명확한 경계(의존성 룰) 필요

4. 두번째 교훈 : 복잡한 코드베이스 방치 금지

• 복잡해지면 개발자가 코드 변경을 두려워함 → 숨기는 문화로 퇴행
• 공유 모듈은 많지만 어디에 뭐가 있는지 모름
• 패키지를 1~2개 공유하려고 새로 만드는 상황 발생
• 해결책:

  • 우린 고구마라는걸 만듬

    • 의존성을 고구마 줄기처럼 만들기때문
      • 구문분석을 해주는 패키지
      • 패키지 개수 절반 감소 (375개 → 약 190개)
      • 패키지 개수가 줄어드는것 만으로도 전체 패키지 빌드 성능 38% 개선됨.

  • 버저닝 체계 도입

    • 같은 버전 내에서만 상호작용 가능
    • 패키지 → 디자인시스템 → 서비스 3단계 구조
    • 의존성 깊이를 줄여 인지부하 완화

5. 3번째 교훈 : 공유 모듈 정의와 의사결정

• 심플했던 컴포넌트가 점점 기능 누적 → “뭔지 모를 공유 모듈”로 변질
• 결국 아무도 안 씀 → 공유 모듈의 가치 상실
• 공유 모듈 조건
  • 제품 전체에서 “하나만 있어야 하는 코드”
  • 공용화하지 않으면 생산성이 급격히 떨어지는 코드
• 나머지는 각 사용처에서 내재화
• 공유 모듈 판단을 위한 의사결정 트리 운영

6. 정기배포 그만두기

• 코드 고립 작업 대상을 리스트업 & 작업 계획서 작성
• 치밀한 계획 & 투명한 진행으로 개발자 신뢰 확보
• 결과: 정기배포 폐지 성공 → 각 스쿼드가 자유롭게 배포 가능해짐

7. 앞으로의 계획

• 스쿼드가 더 자유롭게 개발할 수 있도록 플랫폼 고도화
• AI를 활용한 코드 명세/문서화 제공
• 공용 모듈 정의, 디자인 시스템, WCP 명세를 MCP 등과 연결해 생산성 향상 추진

8. 내 생각

• 듣다보니 “굳이 이렇게까지 복잡하게 해야 하나?” 싶은 부분도 있었음
  • 젊은 애들이라 그런가 일을 굉장히 어렵게 하는 느낌
• 하지만 매우 복잡한 문제를 기술적으로 풀어낸 사례라는 점에서 인상 깊음
• 결론: 모노레포/폴리레포의 문제는 툴링이 아니라 경계 설정과 인지부하 관리의 문제다.

FE Conf가 끝나고

이번 컨퍼런스는 솔직히 아쉬움이 많았다.

과거의 FE Conf는 스타트업들이 차세대 기술을 검토하는 무대였고, 모노레포, SSR, MSF 같은 기술 결정 분석이나 아키텍처·방법론 논의가 활발했다. 하지만 이번에는 그런 깊이 있는 주제들이 잘 보이지 않았다.

GeekNews였나 어디서 "이제 FE 기술이 극한까지 올라갔다"라는 글을 봤는데 그게 맞을 수도 있고, 내 스스로가 예전보다 배움의 깊이가 쌓여서 그렇게 느낀 걸 수도 있다. 아직 내가 그정도로 잘하지는 않으니 전자일 가능성이 높지만 말이다.

그래도 현재의 최신 FE 기술 트렌드를 살펴보니 아직은 내가 뒤처지지 않은 것 같다. 오랜만에 긴 시간 동안 강연에 몰입했더니 피곤하기도 했지만 배가 고프기도 했다.

지인과 함께 식사하려다 컨디션 문제로 취소하고, 대신 다른 친구들과 잠깐 만났다. 저번 컨퍼런스 때 같이 갔던 친구가 있어서 자연스럽게 컨퍼런스 후기 이야기가 이어졌다.

결론

시니어로 향해 가는 30대 개발자 친구들과 대화를 나누면서 내린 결론은 이렇다.

앞으로 프론트엔드 개발은 독립적인 영역이라기보다 백엔드 개발의 하위 스택으로 자리 잡을 가능성이 크다. FE는 끊임없이 생산성 향상을 추구하고 있고, 실제로 이번 강연에서 '오늘의 집' 팀은 UI 코드 생성을 90% 이상 자동화했으며, '강남언니' 팀은 컴포넌트 최적화를 일괄 적용하는 방식으로 개발 프로세스를 혁신했다.

물론 다양한 방식의 개발자들이 계속 등장하겠지만, FE만을 전문으로 삼는 개발자는 점점 설 자리를 잃을 것이다. 대신 풀스택 역량을 갖추거나, AI와의 협업에 능숙한 개발자가 더 큰 가치를 인정받게 될 것이다.

이것이 내가 이번 컨퍼런스를 통해 얻은 가장 큰 인사이트다.