FECONF 2024 오프라인 참석

첫 오프라인 참석

방구석 유튜브로만 보다가 처음으로 오프라인에서 발표를 들으니까 집중이 더 잘됐다.
필기하며 들었던 내용을 정리하면서 회고해보고자 한다.

1. 바퀴 대신 로켓 만들기

연사자: 양의현님 토스페이먼츠

MISSION

10년 이상 지속 가능한 서비스로 레거시 프로젝트 리뉴얼으로
400개의 화면 프로토타입을 최적화하여 디자인 해야 한다.
기간 6개월 개발자 6명

문제 해결

1. 디자인 시스템 구축

• 다양한 기능과 형태가 필요함
• 재사용성 고려

다양한 기능과 형태를 패턴으로 정의하여 재사용 가능한 컴포넌트 구현으로 디자인 의존성을 낮추었다.
동일한 패턴 -> 동일한 구현체

	<YearMonthDayDate
		label="적용 기간"
		size="small"
		value={new Date()...}
	>
      {children}
	<YearMonthDayDate/>

유연하게 변형할 수 있도록 children을 받고 size로 형태를 결정.

2. Refine: FE이 가장 많이 반복하는 작업들을 정의

1. Data Fetching
   • 쉽게 사용할 수 있도록 최대한 자동화 ex) useFetch({type: "get_users", params?: "..."})
     그리고 type 추론할 수 있도록 구현
2. Form Control
   • 멀티폼을 query parameter로 단순화
3. Table
   • 모델을 만들어서 페이지네이션, 체크박스 등 다양한 기능을 구현하여 템플릿화

성과

팀원들이 일관성 있는 같은 퀄리티로 빠르게 개발할 수 있으므로 개발 기간 획기적으로 단축, 유지보수 향상

느낀점

최근 회사에서 현재 페이지의 경로를 보여줘야 하는 요건 구현중 ex) 관리 > 마이페이지 > 이메일 설정
url을 파싱, 순회하며 미리 만들어놓은 테이블에 매칭시켜 자동화 시킨 경험이 있었는데
이 세션을 듣고 회사 코드에 더 자동화 시킬 수 있는 작업들이 생각났다.
data fetch 부분의 로직을 테이블로 매칭시켜놓고 인자로 request와 params를 받아
type 추론까지 가능하게 구현해볼 수 있을것 같았다.
깨달은 것은, 프론트엔드 업무 중 가장 반복적인 작업들을 정의하고 최대한 쓰기 쉽게 컴포넌트 설계, 자동화하여
모든 팀원들이 재사용 할 수 있게 구현하고 유지보수 향상을 위해 팀원의 실력 편차를 떠나 모두가 일관성 있는 코드를 구현 할 수 있도록 구현하는것.

---

2.모던 웹 기술로 C++ 기반 렌더링 엔진 테스트 자동화하기

연사자: 유진의님 LottieFiles

MISSION

C++에서 만든 애니메이션을 웹에서 테스트 자동화를 구현하기

WASM은 웹의 유일한 저언어이다.

웹을 구성하는 요소 HTML, JS, CSS, 그리고 새롭게 등장한 WASM
단, 아직 WASM 성숙단계가 아니기 때문에 빌드 과정에서 오류가 좀 있다.

WASM 전환 사례

• 피그마
  - 화면 런타임시 WASM을 사용해서 3배 이상 로딩 시간을 단축
• AutoCAD
  - C++로 작성된 로직을 웹에서 사용 가능하게 했다.
• 굿노트
  - IOS 전용앱을 WASM을 활용해 크로스 플랫폼으로 거의 모든 디바이스에서 사용 가능해졌다.
  

글루 코드란

WASM은 2개의 파일이 존재한다.
a.wasm -> C++로 작성된 바이너리 파일이다.
a.js(glue code) -> a.wasm의 바이너리를 js가 이해핼 수 있도록 변환해주는 즉 글루 코드라고 한다.

React에서 테스트 환경 구축

1. drag & drop이 가능한 웹페이지를 구축
2. Resemble.js 라이브러리를 사용하여 사람의 눈으로 구분할 수 없는 것들을 확인해준다.

하나의 코드 베이스로 CLI, GUI 모두 배포

웹환경은 vercel로 배포하였고 Github CI/CD를 활용하여 특정 이벤트를 트리거하여 자동화 구현하였다.

cli 배포는 npm으로 배포하여 전역으로 설치만 하면 언제든지 사용할 수 있다.

$ npm i -g tvg-cli

느낀점

이 세션을 들으며 WASM이 많이 성숙해지면 언젠가 C++로 짠 코드로 웹에서 게임도 돌릴 수 있게 될까? 생각하게 됐다. WASM 코드를 짜기 복잡하고 어렵다고 하지만 계속 관심 갖고 공부해나가야 할것 같다. Go언어와 마찬가지로.

---

3. 메타버스 서비스(ZEP)에서 게임과 WebRTC를 함께 적용하기

연사자: 박영진 네이버 with ZEP

기존 서비스 솔루션

• 기존에 있는 솔루션을 사용하여 대상이 참여하고 방을 나갈때마다 통화를 새로 생성하여 비용이 증대됐음

새로운 솔루션

• LiveKit을 개발하여 하나의 통화에 다수가 참여하는 방식으로 비용을 줄임.
  ( 최대 사용 시준 90%이상 감소 )

Angular -> React 전환 과정의 문제

1. 변경이 즉시 반영이 안됨

• Angular는 .apply로 DOM을 강제 업데이트 할 수 있었는데 React는 DOM에 직접적으로 접근하지 않아 문제가 있었다.

2. 리렌더링 로직

• 수많은 유저들이 움직일 때마다 비디오박스 컴포넌트를 렌더링하는 문제가 있었다.

문제 해결

1. MobX 상태 관리 라이브러리

• UI 프레임워크 밖에서 상태를 관찰하고 변경할 수 있다.

2. EventEmitter

• EventEmitter를 통해 구독한 유저들을 탐색하고 브로드캐스팅으로 이벤트 업데이팅

3. RxJs

• 데이터들을 스트림으로 변환시켜주는데 그 과정에서 map, filter로 데이터를 정제할 수 있다. ( 최적화에 사용 )
  그리고 카메라, 마이크 on/off에 따라 이벤트 우선순위의 차별화를 줄 수 있었다.

---

4. 7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기

연사자: 정석호님 비바리퍼블리카

1. 이미지 최적화

• 기기에 적절한 이미지를 렌더링
• 레이아웃 시프트를 발생하지 않게 차단
  -> 구현 방법

  Web -> AWS CDN -> AWS Lamda

AWS에 이미지를 보내 최적화한 이미지를 받아오는것.

2. 비디오 썸네일 ( FFMPEG )

• 비디오 태그의 poster 속성을 이용하여 poster="https://.../00.05"

  경로로 받은 시간을 ffmpeg으로 비디오 안에 해당 시간의 이미지를 보여줄 수 있게 된다.

서버없이 프론트에서 WASM으로 FFMPEG을 사용하여 확장자 변경을 구현한 프로젝트가 있는데 그 프로젝트에서도 시간을 입력받아 썸네일을 쉽게 자동화 적용을 해봐야겠다.

3. 폴리필

• 보통 babel을 통해 최신 js를 받아올 수 있다.
• 폴리필 서버를 구현하여 userAgent를 읽어 필요한 es버전의 js을 내려받게 구현하였다.

  Web -> AWS CDN -> AWS Lamda

4. 스켈레톤

• 웹뷰는 네트워크 통신이 완료될때까지 빈 화면이 발생한다.
• 스켈레톤을 데이터 타입 기반으로 미리 구현해놓고 서버에서 JSON을 받아 구현하였다.
• 정확하게는 네이티브에서 백그라운드로 JSON 모듈을 받아왔다.

하지만 서버 비용이 발생하고 결국 어쨋든 네트워크가 완료되는 시간이 달라지지는 않으므로 현재는 이 방법을 사용하고 있지 않는다고 한다.

데이터 타입에 따라 어떠한 UI를 자동화하기 위해서는 디자인 컴포넌트 기반이 필수적으로 있어야 한다.
스켈레톤 UI도 마찬가지이다. ㅎ

5. 에셋 ( Asset )

다크 테마 큰 글씨 모드 노치 UI 등 토스에서는 이런 기능들을 제공하고 있다.
1. 웹뷰에서는 디바이스 기기의 정보에 접근할 수 없다. 네이티브에서만 접근할 수 있는 정보들이다.
2. 네이티브에서 userAgent를 확인하고 userAgent를 Custom한다. ex) Mozila....dark(사용자 기기 테마)
3. 웹에서는 스타일 시트에 미리 작성해 놓는다. 테마가 다크라면 블랙, 글씨 모드가 크다면 폰트 사이즈 업 등
( 개인 생각으로는 CSS-IN-JS로 안한 이유는 깜빡 현상이 있을 수도 있을것 같다. )

6. og 이미지를 title에 맞게 동적으로 변경

서버에서 title을 보내주면 title에 맞게 자동적으로 og이미지가 변경된다.
구현 방식을 공유해주시진 않았지만 개인 생각으로는 테이블로 key(title), value(image)를 구현해놓고
title값을 key로 넣어 value를 반환받는 느낌일것 같다.

7. QueryString의 부재

• .../query?color=red

• .../query?width=90&color=red

  위 둘은 브라우저가 다르게 캐시한다. 즉 캐시 연동이 안된다.
  그래서 경로 기반으로 변경하였다.

• image/width=90,height=80/...

정리

브라우저 캐시 기능을 최대한 활용하고 API 설계시 QueryString보다 경로 기반으로 설계하라.

느낀점

회사 검색 기능과 필터링 기능이 기존에 상태 기반으로 되있어 로직이 복잡하고 불안정하였던 것을
QueryString으로 새로 구현하고 나서 로직이 매우 단순해지고 불안정성도 굉장히 낮아져서 개인적 만족도와 성취감이 높았는데
이 세션을 듣고 생각이 또 바뀌었다. `queryString으로 순서가 다르면 캐시가 되지 않는 것을 처음 알았다..
물론 queryString도 순서를 일정하게 맞춘다면 캐시할 수 있겠지만 한번 더 찾아보고 공부해야 할 것 같다.

경로 기반으로 구현했을때가 오히려 더 복잡해질 수 있고 tanstack query를 사용하면 자체적으로 캐시를 해주기 때문에
굳이 브라우저 캐시를 사용하지 않아도 되지 않을까? 생각도 들었다.
도메인에 따라 캐시 중요도가 많이 필요로 한다면 경로 기반으로 구현하는 방법이 있겠다를 새로 깨달았다.

총 정리

예전에 이런 컨퍼런스를 들으면 모르는 내용이 더 많았고 이해도 안되고 용어도 어려워서 이해를 잘 못했는데
어느덧 여러 컨퍼런스를 다니다 보니 그리고 꾸준히 공부하며 새로운 것을 회사에 도입하다 보니 어느덧 조금은 성장한것 같다.
발표를 들으며 어떻게 구현했을까 더 깊게 궁금증도 있었고 내가 생각한 방법은 이건데.. 연사자님도 그런 방법으로 하셨을까?
이런 고민들을 하며 더 깊게 집중할 수 있었다.
굿즈도 받고 기분 좋은 추억이였다. 내년에도 갈 수 있도록 노력하겠다 ㅎ