Qvil Blog

컨퍼런스에 대한 자세한 내용은 아래 링크에서 확인 가능합니다.

https://if.kakao.com/

• 최대한 객관적인 내용을 전달하려고 했으며 사견은 인용방식으로 적었습니다.
• 발표 자료가 공개되었습니다. 아래 내용은 발표자료가 공개되기 전 메모한 내용이므로 발표 PDF를 보시면서 사견을 참고하세요.

10시 Keynote

카카오뱅크

Tech.kakao.com 카카오 기술 공유 사이트

카카오뱅크가 기존 금융업계와 다르게 오라클을 제외하고 x86 리눅스 베이스로 MySQL, Postgres, Tomcat, Nodejs 등을 사용한 배경 설명

모바일 First에 기술 중심 전략, 제품에 개발자 의견 들어가게함

카카오 Vison

• 카카오 1.0: 카카오톡 트래픽
• 카카오 2.0: 여러개 사업 펼침
• 카카오 3.0: 안정화 단계

카카오 Culture

창의, 자기주도, 수평커뮤니케이션

11시 리액트: 그것마저 결정해주마 PDF

카카오페이지 Spring JSP를 리액트로 포팅한 과정 소개

1.  컴포넌트 코드 일관성

함수형 컴포넌트 컨벤션

1. 속성값 타입 정의(propTypes를 본것 같은데 기억이 잘 안남. Typescript Interface였던것 같기도 하고)
2. 컴포넌트
   1. 매개변수 비구조화 (props) 대신 ({ props1, props2 })
   2. 조건부 연산자 삼항연산자는 2depth이상 들어가면 복잡하므로 &&
3. 기타 상수 혹은 함수

클래스 컴포넌트 컨벤션

1. 속성값 타입
2. 상태값
3. 생명주기
4. 기타메서드
   1. () => 로 this.bind 해결
5. render

컨벤션 도구 ESLint(Custom Rule), Prettier

2. 클래스 컴포넌트를 훅으로?

클래스가 지상파 방송이면 훅은 Youtube다.

클래스 컴포넌트 단점-1

didMount Update로 user바뀌면 setState하던 중복코드를

useEffect로 관리

클래스 컴포넌트 단점-2

Mount Unmount eventHandler등록/해제

useEffect에서 eventHandler등록/해제

클래스 컴포넌트 단점-3

기능별로 Effect를 여러개따서 관리 가능

클래스 컴포넌트 단점-4

HOC는 작성해야할 코드 많음.

지금회사도 HOC쓰는데 훅으로 걷어내야될듯

훅으로 해결 useState와 useEffect

3. 서버렌더링

힘든점

1. 서버 배포, 인스턴스 스펙, 모니터링 로그, 서버비용 등  => SPA는 정적파일 서빙하면 끝
2. 코드가 서버에서 실행되므로 분기처리 필요(window, localStorage 등)
3. 서버는 스크린 사이즈 모름

'피할 수 있으면 피하자'라고 함.

• Q: 카카오페이지도 필요할텐데 어떻게 해결했는가?
• A: NextJS사용했다. 최신버전 사용 중(국내만 v8, 나머지는 v9 사용)
• Q: Custom Express 서버는 사용하는가?
• A: v9부터 다이나믹 라우팅이돼서 필요없다.

지금회사는 서비스 특성 상 서버렌더링이 필수임. 현재프로젝트가 NextJS v8로 되어있는데 이미 진행되고 규모가 훨씬 클것으로 예상되는 카카오페이지가 최신 버전(v9)으로 포팅을 완료하고 다이나믹라우팅까지 쓴다는 얘기를 듣고 좋은 기술이 나왔는데, 회사 내부에서 이미 공유했었는데 '더 작은 조직인 우리는 왜 빠르게 대응하지 못했을까?' 라는 생각을 하게 되었음.

4. 렌더 함수 안에서 새로운 객체 생성이 가능한가?

• 렌더링이 CPU 가장 많이 사용한다.
• 요즘 브라우저는 객체 생성은 충분히 빠름.
• shouldComponentUpdate는 1depth 비교, 즉 객체 reference비교
• useCallback이용해서 handler memoization해서 사용하기(onClick, handleChange 등)
• 스와이프 기능 성능고민 안하고 느렸던 사례 공유
  • useCallback으로 빨라짐.
    • 문제가 생겼을 때 성능최적화 추천

5. Redux

아래와 비슷한 그림(Redux 원리)으로 설명 시작

Mobx, Hook, Context 많이 있지만 성숙한 라이브러리이므로 Redux 추천

다른 개발조직(카카오페이)에도 물어봤는데 데이터 변화가 눈에 확실히 보이는 Redux를 선호한다고 했다. Mobx는 사용하기는 쉽지만 데이터가 어떻게 변화하는지 흐름 파악이 쉽지 않다고 함.

리덕스 문제

1. 액션 추가마다 reducer, action, actionType 파일 추가를 해야함
   1. ducks패턴
   2. action, reducer만 나누던가
2. ...state 불변성 관리
   1. createReducer, immer사용
3. setValue만들어서 재활용(정적타입과 함께 사용 추천)
   1. 카카오 내부에서 만든 redux store에 말 그대로 value를 set하는 함수를 사용한다고 함. 1. (Type이 명확하지 않은 단점이 있다고 함)
4. connect, map
   1. redux v7의 useSelector, useDispatch를 사용해서 해결

지금회사에서도 이미 고민했던 부분과 해결 방법이 대부분 일치한다. ducks패턴, immer 등

HOC패턴의 코드를 제거하는게 좋겠다는 생각을 했음. (지금회사 코드에 connect, map, HOC패턴 존재함)

무조건 HOC를 제거하자는게 아니다. withLayout같은 컨셉은 HOC로 구현해도 좋지만 withMobile같은 단순 props를 주입받기 위해서 쓰는 HOC코드를 useMobile과 같이 리팩토링할 수 있겠다고 생각함.

리덕스 장점

1. redux-saga같은 미들웨어 => API는 미들웨어가 처리하고 컴포넌트는 UI에 집중
2. makeFetchSaga만들어서 isFetching, isSlow 같은 상태 관리

지금회사도 redux-saga를 통해서 API Logic은 미들웨어에서 처리하고 컴포넌트는 UI에 집중하게 되어있다.

그러나 Request, Success, Failure로 상태관리하는 코드는 코드가 너무 많아지고 이를 질문한 사람이 있었는데 내가 대답한 내용은 velopert가 세미나에서 발표한 패턴을 참고해도 좋다고 했다.

2번처럼 saga자체에 상태관리 함수를 만들어도 좋을듯

6. 정적타입

타입스크립트가 리액트 NPM 다운로드 추월

Typescript가 React의 NPM다운로드 순위를 추월한 그래프를 보여줬다.

아래와 똑같은 그래프는 아니고 아래 그래프는 현재(2019.09.11)기준 NPM Trend 그래프다.

https://www.npmtrends.com/react-vs-typescript

생산성 많이 좋아지므로 도입 추천

아래와 비슷한 느낌의 그래프를 보여줬는데 세미나 자료가 없어서 비슷한 그래프로 대체한다.

Javascript 생산성 그래프

Typescript 생산성 그래프

1. 없는 객체에서 lengh호출하는 것 없어짐
2. 객체 속성 리스트업 가능
3. VSCode에서 Rename기능으로 interface부터 모든 속성 한번에 수정 가능
4. IDE에서 코드간 이동 Auto Import
5. 번들링 과정 중 최적화 가능 => 자동으로 필요한 폴리필만 삽입

• Q: Generic type 지원안해주는 경우 어떻게 해결?
• A1: 유명한 라이브러리는 거의 다 types지원, 없으면 any처리
• A2(다른 카카오 개발자): 타입을 우리가 만들어서 쓴다.

세미나 내용을 듣고 스스로 내린 결론은 카카오의 대부분의 개발조직이 Typescript를 사용하며 만족한다. 개발일정에 코드테스트와 코드리뷰 시간까지 모두 포함해서 일정을 산출하거나 PR을 통해서 Reviewer의 승인이 없으면 아예 Merge도 안되는 조직도 있다고 했다. (플랫폼팀)

이는 빠르게 서비스를 출시해야되는 지금회사의 상황과는 맞지 않을 수도 있다. 그러나 서비스를 열었다가 금방 닫는게 아니라면 '우리도 코드리뷰를 충분히 하면서 개발을 했으면 좀 더 변화게 대응이 빠르지 않았을까?' 라고 생각했다.

한가지 예로 지금회사에서도 Typescript 도입이 의논된 적이 있었으나 외부라이브러리 사용할 때 type을 지원안하거나 모든 컴포넌트에 props Interface를 작성해야해서 속도가 늦어진다고 생각해서 도입하지 않았다.

그러나 카카오는 Typescript에 대해서도 아래와 같은 그래프(똑같은 그래프는 없어서 비슷한 그래프를 찾아서 넣었다.)를 보여주며 말했다.

'빠르게 결과물을 도출하는게 처음엔 빨라보이지만 프로젝트가 일정 수준이 되면 유지보수 및 기능추가에 Typescript가 더 빠르다고 말했다.

절대 'Typescript가 좋다.' 라는 말을 하고 싶은게 아니다. 카카오의 대부분의 개발 조직은 Typescript 도입을 만족한다고 말한 내용을 전달하고 지금회사에서도 고려했던 경험을 말한 것이다.

7. css-in-js

styled-components, rebase추천(아래와 같은 예제 보여줌)

Copycopy code to clipboard
1<Box ml="10px" <Text fontSize={[10, 12, 14]}

COLORS, FONT_SIZE 상수로 관리

이미 지금회사에서 하고 있는 좋은 패턴

12시 FE 개발자가 브라우저를 확장하기 PDF

Paint API

Paint API로 컴포넌트 모듈을 작성/추가/사용 하는 예제를 보여줌.

React 컴포넌트와 비슷한 개념이지만 CSS API기 때문에 라이브러리 종속적이진 않다.(이 부분은 웹 컴포넌트와 비슷한 느낌)

그러나 브라우저 지원이 모던브라우저밖에 안돼서 현재 카카오도 개발자 내부에서 쓰는 어드민페이지 같은 곳에서만 사용한다고 말함.

성능 비교로 기존 툴팁 컴포넌트를 Paint API로 구현한 예제(카카오맵에 툴팁 1000개 띄우고 맵을 좌우로 이동)를 보여줬는데 프레임 속도가 확실히 차이났다.

CSS layout

크롬 기준으로 JS로 레이아웃처리 시 렌더링 파이프라인 2번 타는데 이 방식을 사용하면 렌더링 최적화를 더 할 수 있다고 했음.

예제 사이트: https://css-houdini.rocks

Animations API, Web Audio API, 웹어셈블리, 확장 가능한 웹 표준 서명 등에 대해서 설명했다.

14시 프론트엔드 기술로 동료들 삶의 질 높여주기 (카카오뱅크 Fun 프로젝트 개발기) PDF

프론트 개발자가 일거리를 찾아서 해낸 사례(카카오 뱅크였나 기억이 잘 안나는데 회사 초기에 인트라넷부터 아무런 시스템이 없는 상황이었다고 말함.).

1. 누구도 이거해라 하지 않음
2. 무엇을 개발해야 할지 모름
3. 무작정 돌아다님(커피타임). 직원들 모두 고민(DRM 문서뷰어, Web Auth, 회의주최 서비스 등)이 있었음. => 일거리가 널려있다.
4. 프로토타입을 만들어서 시간(돈)을 투자받음. => 프로젝트 진행

OCR Slayer

카카오뱅크 신분증검수 서비스로 업무효율 3~4배 향상시킴.

업무 도메인이 다른 사람과 1년 동안 트레이드오프 과정이 걸렸음.

몇번 엎더라도 라이프사이클 검토하면서 진행.

업무 도메인이 다른 사람과 개발자의 시각이 달라서 의견을 맞추는 시간이 오래 걸렸다고함.

프로젝트를 몇번 엎더라도 서비스 사용 라이프사이클을 계속 검토했다고함. => 결국 유저에게 초점을 맞추고 개발함.

카카오뱅크 이벤트 플랫폼

개인의 만족을 위해 혼자 다 만들자 vs 분야별 전문가를 모아서 좋은 프로덕트를 만들자

개인 욕심 포기하니 간단하게 해결되었다고 함.

좋은 프로덕트를 만들기로 함.

이미 주변에서 프로젝트 껴달라고 하는 분야별 좋은 개발자들이 많았다고 함.

Floor 3D

도서검색처럼 카카오 직원 자리 검색 서비스

프론트개발자로써 보는 순간 감탄나오고 바라만봐도 즐거운 서비스를 만드려고 노력했다고함.

해당 세션에서 가장 많은 감탄이 나온 서비스

워크온

카카오 업무시간 관리 툴

• 필요한 것 발견하고 만들었다.
• 복잡한 것보다 단순화
• 동료들에게 깜짝선물
• 일하는 문화 참여

결론 동료를 위한 일이 유저를 위한 일이 된다. 동료가 곧 유저다.