if(kakaoAI)2024 day2 시청 및 정리 ... 프론트엔드

이번주에 if(kakaoAI) 2024 발표 영상이 공개됐다.

개인적으로 AI 모델링, 서빙, Feature Store보다는 AI 사용하는 거에 관심이 많아 정리는 안 하고 간단하게 보기만 했다.

 

Day2와 Day3 발표에서 관심가는 발표 영상을 보고 정리할 텐데

이번 포스트는 Day2에서 프론트엔드 관련 발표다.

---

 

React to PDF: 좌충우돌 PDF 생성 기능 개발기

카카오 헬스케어 파스타 서비스에서 노출되는 화면을 PDF로 다운로드하거나

PDF를 브라우저에서 보여주는 요구사항을 만족하기 위한 개발기를 소개한다.

 

 

라이브러리를 사용하지 않고 직접 개발한 이유?

PDF 전환하기 위해 라이브러리의 별도 작업이 필요한 라이브러리가 있었다.

기존 컴포넌트를 그대로 사용하지 못하면 이중작업 부담, 테스트 복잡성 증가, 라이브러리 의존성 증가하는 문제가 있어
제외했다.

그리고 자동 페이지 분할 기능이 없었다.

 

html2pdf.js는 자동 페이지 분할 기능을 지원했지만

너비가 A4 사이즈를 벗어나는 경우가 발생했는데 html2pdf 에는 해당 기능을 제공하지 않았고

Github의 활동이 활발하지 않았다.

그래서 직접 만들기로 했다.!! html2pdf를 곁들인

 

html2pdf의 자동페이지 분할 기능을 파악했다.

관점을 바꿔서 자동페이지 분할이 아니라

중단점을 잡아 패딩을 주고 요소를 밀어서 화면을 만들어 준다고 생각한다면??

@media print {
	.page-break {
		break-inside: avoid; 
	}
}

 

 

렌더링 완료 후

viewport 기준으로 바텀 가져와서 패딩 추가하고

히든 된 헤더와 푸터 추가, 그리고 넘버링 추가하는 순서로 진행한다.

 

react-query의 useIsFetch 기능을 이용해서 모든 fetch가 완료됐는지 확인했다.

 

PDF에서만 적용되어야 하는 속성이 있었는데 이를 위해 가장 상위에 useContext를 pdfMode를 주입했다.

그리고 PDF가 아니라 이미지 파일 처리도 필요했는데 모든 순서를 관리해서 손쉽게 구현 가능했다.

 

 

우리는 왜 차트를 쪼갰을까: 복잡한 데이터 시각화에 유연하게 대응하기

의료 연구 데이터를 한 곳에서 검색하고 분석 가능한 연구자용 B2B 데이터 플랫폼을 제공하는데
해당 플랫폼에서 사용되는 차트의 다양한 요구사항이 있었다.

이런 거...

 

오픈소스 차트 라이브러리를 쓰지 않고 직접 만들게 된 이유는?

문제점 1. 세부사항이 감춰진 인터페이스

문제점 2. 너무 커다란 객체와 함수

문제점 3. 내부에 감춰진 예측 불가능한 로직

 

차트의 세부동작 로직은 감춰지고, 데이터와 도형들 상태와 UI는 드러난 차트.

행동은 감춰지고, 상태와 UI는 드러난 컴포넌트를 목표로 만드는 과정을 소개한다.

 

Radix UI, Shadcn처럼 차트도 디자인 시스템처럼 만들 수 있지 않을까?

 

Compound Component.

Context API기반으로 한다.

UI와 관계없이 데이터를 기반으로 계산되는 값들을 차트의 로직으로 정의하고 추상화했다.

 

배열의 인덱스가 아니라 id로 접근

react-query, relay 같은 클라이언트에서 사용.

 

알아야 하는 것을 명시적으로 드러내자.

상태만 제공하고 UI 제어권은 사용자에게 넘길 때 유용한 패턴이다.

tailwind HeadlessUI, React trasition group에서 쓰인다.

 

마지막 멘트가 너무 멋있다.

문제에 집중하다 보면 어떻게 해결하는지에만 집중하면 왜 해결해야 되는지를 놓치게 된다.

문제의 본질을 돌아보고 생각보다 간단하게 해결할 수 있는 문제는 아니었는지 생각해 보는 계기가 되었으면 좋겠습니다.

 

Node.js(Next.js) 애플리케이션 모니터링을 위한 메모리 인사이트

Node.js 메모리 구조

카카오페이에서 모니터링은 Prometheus를 사용하는데

Prometheus는 Node.js Native API를 사용하여 메트릭을 수집한다. process.memoryUsage

rss > heapTotal > heapUsed

 

// GC를 사용자가 직접 호출할 수 있다.
$> node --expose-gc index.js

// GC가 실행되는 로그를 볼 수 있다.
$> node --trace-gc index.js

 

 

C++ 구현한 모듈이 Javascript에서 언제 사용가능해지는가? 언제 바인딩되는가?

 

Node.js C++ main 함수부터 메크로, 그리고 바인딩하는 순서까지 코드 단에서 설명한다.

Prometheus의 수집하는 메트릭도 의심했었는데 엔진 기능을 바로 가져다 사용한 것을 확인하고 의심을 거뒀다.

 

힙덤프를 떠서 메모리 릭 원인을 파악했는데

Next.js 특정 middleware가 만들어내는 객체가 제대로 GC에 포함 안 되는 것을 확인했다.

 

 

선물하기 프론트엔드 성능 개선기

이전에 적용된 성능 최적화 방법들 소개한다.

 

성능 개선에 적용된 기법 소개 (리소스 투입이 적은 순으로)

 

1. 이미지 최적화

. 적절한 이미지 사이즈 변환

. PNG, JPG, GIF 포맷을 WebP 포맷으로 변환 (지원 브라우저 확인 필수)

. fetchPriority와 preconnect를 적용해서 LCP 0.4초 단축

. 노출되지 않은 영역에는 지연로딩, Intersection Observer API 이용

 

2. 폰트포맷 최적화

. font 명시한 순서대로 적용한다. 

. local -> woff2 -> woff

. 지원 브라우저 확인

 

3. index.html에서 특정 API 호출 미리하기

 

4. 디펜던시 중복 탐지 스크립트 개발 및 적용

Javascript는 폰트나 이미지보다 KB 절감이 적지만

같은 용량의 이미지에 비해 처리하는데 더 많은 비용이 들고 main thread가 많은 관여를 한다.

 

스크립트로 추출된 중복은 개발자의 판단으로 진행한다.

. yarn.lock의 dependency 이름과 버전을 추출

. Direct dependency(package.json에 정의한 dependency) 추출

. 개발자의 판단하에 중복 제거

 

5. 사내 라이브러리 코드 스플리팅 고도화

공통 라이브러리는 번들링을 통해 하나의 파일로 제공한다.

. 사내 앵귤러 라이브러리 ng-packagr. secondary entry points angular library

. 유틸 라이브러리

 

6. ES6 전환 및 core-js 폴리필 최적화

. 중요한 내용 같았는데 이해 못 함... 어렵다.

 

7. 페이지 내 큰 컴포넌트의 지연로딩

- 홈 경로에 보이는 큰 컴포넌트 18개

- 최초 진입 시 당장 필요하지 않은 컴포넌트 지연로딩. Dynamic Import

  * 스크롤 케이스 지연로딩 > 기준선을 높였다.

  * 클릭 케이스 지연로딩 > MoseEnter 이벤트 마우스 진입 시점에 미리 불러온다.

  * 특정 조건 케이스 지연 로딩 > prefetch 적용(ios, safari 미지원, 자원경쟁, 제한적으로 사용 권고)

 

 

TDD로 앞서가는 프론트엔드: 디자인, API 없이도 개발을 시작하는 방법

일반적인 FE 개발 흐름도를 소개한다.

 

 

병목을 줄이기 위해, FE에서 화면 없이 개발하기 위해선 어떤 부분에 주목을 해야 할까?

 

컴포넌트는 상태를 입력받고 뷰를 반환하는 일종의 함수라고 생각하고

필요한 element를 선택하여 의도한 값이 노출되고 있는지를 확인한다.

 

디자인 없이 마크업 없이 기능 개발하기

이 때 개발한 기능들은 마크업 구조가 아닌 해당 테스트 선택자에 의존성이 있다.

data-testid로 선택자를 지정해서 테스트를 진행한다.

 

API 없이 기능 개발하기

API Layer와 View Layer 사이에 ViewModel Layer를 둔다.

React의 hook 처럼 useProfileViewModel 정의

 

1. API Layer는 api를 호출하고 api interface를 그대로 반환하는 계층이다.

2. ViewModel Layer는 API Layer에 리턴한 데이터를 View Model에 맞는 구조로 파싱한다.

3. 테스트 코드에 API Mocking 추가

 

그런데 말입니다... 실무에서도 아름답게 동작할까요?

패턴 1 같은 입력에 같은 컴포넌트를 리턴한다.

패턴 2 외부에서 암묵적으로 상태를 주입받아 렌더링 해주는 컴포넌트 ... 부수효과인 state를 mocking

패턴 3 여러 컴포넌트로 구성된 컴포넌트.
     안에 있는 컴포넌트까지 다시 테스트할 필요 없다. 이미 앞에서 테스트 했으니 잘 됐다고 신뢰를 하고 진행

 

 

 

---

경험을 공유하는건 그 자체만으로 아름답다.