FE Conf 2026 후기: 결국 다 "공학"이더라

10월 24일 잠실 롯데월드타워에서 열린 FEConf 2026에 다녀와서, 기억에 남는 세션들을 정리한 후기다.

올해가 10주년인 FEConf 2026에 다녀왔다. 들은 세션 중 기억에 남는 것들을 정리해 봤다. 다 듣고 나서 남은 한 문장은 이거였다.

"OOOO 문제를 OOOO 방법으로 해결한다."

여러 발표에서 사람이 일일이 챙기던 걸 시스템이 챙기게 만드는 이야기가 나왔다.

1. 법대로 하는 프론트엔드 개발 🏛️

윤해민 · WYYYES(와이스)

비개발자가 AI로 어드민을 만들고 개발자가 검토하는 작은 팀에서, 정책 문서를 실제 법령 구조로 만든 발표였다.

법률 ↔ 시행령 = 비즈니스 정책서 ↔ UI 정책서. "경매 중인 상품은 삭제 불가"는 어느 화면에서든 지켜야 하는 법률이고, "삭제 불가 사유를 토스트로 안내"는 화면별 집행 기준인 시행령이다.
인용도 법처럼. 배송 정책서는 주문 상태를 직접 정의하지 않고 주문 정책서 조항을 가리킨다. 이 인용이 코드 주석까지 이어진다. 상수 옆에 "주문 정책서 4조 1항"이라고 적는 식이다.
본문엔 지금 유효한 조항만 두고, 바뀐 내용은 부칙처럼 시행 시점과 함께 기록한다. 조마다 고유 ID를 붙인다.

문서와 코드가 어긋나지 않게 막는 장치는 두 가지였다. Claude 훅으로 합의되지 않은 정책은 구현 단계로 넘어가지 못하게 하고, AI가 정책서를 쓰다 번호를 빠뜨리거나 삭제된 ID를 재사용하면 린트로 잡아서 차단한다.

도입 전후 3개월을 비교하면 기획자가 올린 기능 PR은 2.5배, 기획자만 고친 서비스 코드는 약 5.5배 늘었다고 한다. 정책 문장을 테스트 시나리오로 바꿔 돌렸더니 446개 시나리오에서 11개 오류를 찾았다고 한다. 개발자는 코드 전체 대신 PR에 적힌 조항부터 보면서 리뷰한다고 했다.

2. 절대 지워지지 않는 E2E 테스트를 위해 필요한 것들 📱

김지원, 박서진 · 토스

처음엔 Appium으로 개발자 노트북에 기기를 직접 연결해서 테스트했다고 한다. 기기 충전, 인증, 버전·OS 차이 때문에 한 환경에선 되고 다른 환경에선 실패하는 일이 잦았고, CI에서 100~200개를 돌리는 데 50분 넘게 걸렸다. 발표에서는 이런 Appium 기반 방식의 한계를 짚었다.

그래서 사내 디바이스 팜 Nebula 위에 테스트 라이브러리 Nova를 만들었다. 흥미로웠던 건 연결 방향이 반대라는 점이다. 보통은 로컬 기기를 개발 서버에 붙이는데, 여기선 원격 기기의 요청을 개발자 노트북의 로컬 서버로 보낸다.

안정성 원칙도 배울 점이 많았다.

시간 대신 상태를 기다린다. 고정 대기 대신 "페이지가 실제로 열렸는지"를 확인한다.
실패하면 이유를 남긴다. 기기 정보, 스크린샷, 녹화, 코드별 리플레이 타임라인까지 제공한다.
그 결과 테스트 수는 2배 넘게 늘었는데 실행 시간은 3분의 1로 줄었다고 한다.

가장 좋았던 건 마지막 파트였다. 테스트가 실패해도 기기는 반납하고, 만든 사용자는 지우고, 지급한 포인트는 회수해야 한다. 순서도 중요하다. try/finally로 처리하면 자원이 여러 개일 때 코드가 금방 복잡해진다. 그래서 JavaScript의 await using과 비동기 dispose로 스코프가 끝날 때 정리 순서를 언어 차원에서 보장했다고 한다. 새 문법을 이렇게 활용할 수 있다는 게 새로웠다.

3. 디자인 시스템, 더 나아가서 🎨

정현수 · 당근

당근은 디자인 시스템 "시드"를 바탕으로 AI 디자인 도구를 만들었지만, 프로덕션에서 쓰기엔 한계가 있었다고 한다. 그래서 문제를 의도, 맥락, 레퍼런스, 디자인 시스템, 디자인 언어로 나눠서 접근했다.

의도: 사용자가 말하지 않은 조건은 AI가 임의로 채운다. 좋은 질문 도구는 "지금 결정에 필요한데 빠진 조건"을 찾아준다.
레퍼런스: 실제 앱 화면을 CI에서 시뮬레이터로 수집하는 사내 도구 "엠퍼러"를 만들고 있다고 한다.
디자인 시스템은 의사결정의 압축. 토큰과 컴포넌트만으로는 부족하고, 빈 화면·오류·로딩 같은 패턴까지 담아야 한다.
디자인 언어: Elyx처럼 디자인을 자체 언어로 표현해 코드처럼 변경을 추적하는 사례도 소개됐다. 다만 만능은 아니라고 했다.

마무리 한마디가 오래 남았다. "생각을 멈추면 그 자리는 AI가 차지한다."

4. 오프라인 우선 Micro Frontend 구축기 📦

나석주 · 토스플레이스

매장 POS는 Windows·macOS·Android·iOS에서 돌아가야 하고, 네트워크가 끊겨도 버텨야 한다. 예시로 든 기기는 RAM 2GB, Windows 7, 32비트였다. 듣기 전엔 "PWA 구현일까, 직접 만든 체계일까"가 궁금했는데, 직접 만든 체계였다.

서비스 워커는 제외. 캐시가 없으면 결국 네트워크가 필요하다. React Native는 Windows 7을 지원하지 않는다.
Web Bundles(.wbn)는 아이디어만 참고. 파일 하나로 묶어 오프라인에서 쓰는 방식인데, 실험 기능이라 2023년 2월에 제거됐다.
그래서 웹뷰 번들을 직접 만들었다. 번들 파일을 네이티브 앱에 미리 넣어두고, 웹 요청을 가로채 로컬 파일로 응답한다. 플랫폼마다 핸들러는 다르지만 같은 번들 파일을 공유한다.
OTA 서버로 번들만 업데이트하고, POS는 잘 꺼지지 않으니 이번에 받아두고 다음 진입 때 교체한다.

MFE 쪽은 호스트가 리모트의 라우트를 동적 import로 합치고, Import Maps로 React를 한 번만 불러온다. 웹뷰 번들은 Electron·Tauri·Android·iOS에서 쓸 수 있게 오픈소스로 공개됐다. (Webview Bundle · wvb.dev)

👉 내가 참고할 건 .wbn이 아니라 이 웹뷰 번들 방식이다.

함께 들은 세션: 수백개 패키지의 모노레포와 함께 micro frontends로 전환하기 (김종현 · 미리디). 패키지마다 레이어를 지정하고, 잘못된 방향의 의존성이 있으면 pnpm 설치 단계에서 에러를 낸다. 롤백은 다시 배포하지 않고 manifest 버전만 되돌린다. 여기서도 "문서가 아니라 시스템이 지킨다"는 이야기가 나왔다.

현업 문제를 풀면서 만든 도구를 오픈소스로까지 공개한 점이 멋졌다. 마이크로 프론트엔드를 처음 접한다면 두 발표를 함께 다시 보는 걸 추천하고 싶다.

5. 조합이 폭발하는 디자인 시스템, 이걸 눈으로도 테스트하라고요? 🧩

유길종 · 토스

토스 디자인 시스템(TDS)의 시각 회귀 테스트 이야기. 개인적으로 가장 많이 배운 세션이었다.

느리면 안정적이고, 빠르면 잘 깨진다

안정화를 보수적으로 하면 느리고, 공격적으로 하면 잘 깨진다. 자주 겪는 딜레마라 많이 공감됐다. 그래서 크로매틱 대신 Vitest + Storybook 위에 얇은 래퍼를 두고, GitHub Actions를 단일 실행 환경으로 삼았다고 한다. 로컬 변경을 임시 브랜치로 올려 CI에서 스냅샷을 찍어주는 CLI "찰칵"도 만들었다. 폰트는 로컬 파일로 두고, 폰트 로드 실패는 테스트 실패로 처리한다.

조합 폭발

MUI 버튼에서 중요한 속성만 골라도 조합이 1만 개가 넘는다고 한다. 컴포넌트는 60개다. 전부 찍는 건 현실적으로 어렵다.

여기서 페어와이즈 테스트가 소개됐다. 모든 조합 대신 두 요소씩 짝지은 조합만 한 번씩 보는 방법이다. 비유하자면 가진 옷을 전부 입어보는 대신, 조합별로 몇 벌만 입어보고 비슷한 건 건너뛰는 것에 가깝다.

솔직히 글로는 이해가 되는데, 이게 어떻게 가능한지 감은 아직 잘 안 온다. 라운드 로빈을 처음 배울 때와 비슷한 느낌이다. 이런 게 공학의 힘이구나 싶었다.

다만 TDS는 페어와이즈를 그대로 쓰지는 않았다. 스냅샷이 한꺼번에 바뀌면 원인을 찾기 어렵고, 어떤 속성이 중요한지는 결국 사람이 골라야 했기 때문이다. 대신 아이디어를 빌려 왔다.

속성을 레이아웃과 시각 요소로 나눈다. 레이아웃이 바뀌면 리플로우가 일어나지만 색은 대부분 리페인트에서 끝난다. 그러니 둘은 따로 조합해도 된다. 내 식으로 이해하면 사람의 골격과 피부색을 따로 보는 것과 비슷하다. 이렇게 해서 16,128개 조합을 384개로 줄였다고 한다.

중요한 속성은 사람이 고르고, 케이스 생성은 "조합" 패키지가 자동으로 한다. defineJohabComponent라는 이름이 재밌었다 😄

기억에 남는 문장. "테스트는 버그가 있다는 건 보여줄 수 있어도, 없다는 건 보여줄 수 없다." 그래서 무엇을 검증할지가 명확해야 하고, 테스트에 은탄환은 없다고 정리했다.

비슷한 주제를 다룬 발표가 또 있었는데, 그중 이 발표의 정리가 가장 잘 와닿았다.

6. 붙어야 할 때와 떨어져야 할 때 🔗

진유림 · 토스

부제는 "Module Federation과 Web Component로 보는 결합의 트레이드오프". 토스의 광고·쇼핑·페이 같은 B2B 서비스를 하나로 잇는 공통 내비게이션 이야기였다. 만드는 사람은 1명, 쓰는 팀은 30~50명 규모였다고 한다.

V1: Module Federation. "사용 팀이 업데이트하지 않아도 늘 최신"을 위해 결합 시점을 런타임으로 미뤘다. 1년간 잘 운영됐다.
그러다 전제가 바뀌었다. 연동처가 3곳에서 7곳으로 늘었고, 한 팀이 React 19로 올리자 내비게이션이 깨지는 일이 생겼다.
V2: Web Component + Shadow DOM. 결합 시점뿐 아니라 결합 깊이도 줄였다. React와 TDS를 번들에 포함해(약 44KB) 사용처는 HTML에 두 줄만 추가하면 된다.

결론이 좋았다. 결합은 버그가 아니라 상황에 맞게 고르는 설계 요소다. 지금의 선택도 정답이라 고집하지 않고, 요구가 바뀌면 다시 판단하겠다고 했다.

7. 이미지 한 장을 편집 가능한 레이어로 🖼️

김민성 · 미리디

Cloud AI에서 On-device AI, WebGPU까지 이어지는 발표였다. 데모: feconf2026-demo.vercel.app

설명이 기초부터 차근차근 이어져서 배경지식이 많지 않아도 따라가기 쉬웠다. 이미 아는 부분에서는 조금 길게 느껴지기도 했는데, 청중의 배경이 제각각인 컨퍼런스에서 어디에 눈높이를 맞출지는 늘 어려운 문제라 이해가 됐다.

내용은 정말 좋았다.

WebGPU로 브라우저에서 이 정도까지 된다는 게 놀라웠다.
TensorFlow를 비롯해 여러 도구를 폭넓게 활용한 게 인상적이었다.
최적화와 결과물 품질을 둘 다 챙긴 점에서 디테일에 대한 집요함이 느껴졌다.

디자이너가 쓰는 도구에 가까워 보이지만, 그걸 만드는 과정은 확실히 엔지니어링이었다. UX 엔지니어링이 이런 거구나 싶었다.

마무리 ✨

올해 가져가는 것.

웹뷰 번들 → .wbn은 제거됐지만 아이디어는 남아 있다. 직접 적용해 볼 생각
관심사 분리로 조합 줄이기 → 페어와이즈 아이디어 + 레이아웃/시각 분리
await using → 테스트 자원 정리를 try/finally 대신 언어 기능으로
"지키는 건 시스템이" → 훅, 린트, pnpm 훅, CI. 문서에만 적어두지 않기

돌아보면 다 비슷한 이야기였다. 사람이 매번 챙기던 걸 시스템에 녹이는 것. 좋은 발표를 해주신 연사분들께 감사드린다 🙌

전체 시간표: 2026.feconf.kr · 발표 영상은 공개되면 링크를 추가할 예정