설모의 기록
naver tech concert : front end 참여 후기 본문
SOPT라는 동아리를 통해 이번 04월 11일에 naver 그린팩토리에서 열린 네이버 테크 콘서트가 열린다는 소식을 듣게 되었다. 업무와 관련된 외부교육이나 컨퍼런스를 휴가 사용없이 참석할 수 있게 해주는 회사 덕분에 (좋은 회사!!) 사전신청을 한 후에 참여할 수 있었다!
아래의 글에서 네이버 테크 콘서트를 참여한 후기를 남겨보려 한다.
이주용님 (네이버 스마트에디터 원) - 플랫폼 UI 개발 전략의 모든 것
- 플랫폼이란? 공통의 활용 요소를 바탕으로 본연의 역할도 수행하지만, 보완적인 파생 제품, 서비스를 개발할 수 있는 기반
- 초반엔 전략보단 퍼포머스 위주로 개발을 진행했다.
1. 서비스 구분없이 모든 스타일이 포함된 css
2. 여러 서비스의 요구사항을 한 css 에 합쳤기 때문에 최종 산출물인 css 가 불필요하게 커지는 결과가 되었다.
3. 커스텀 및 확장을 고려하지 않음 → 플랫폼 css 와 서비스 css 간 간섭이 발생하고 스타일의 우선 순위 관리가 어려웠다.
- 플랫폼 UI 설계에서 중요한 것
1. UI 공통화는 디자인 중심이 아닌 기능 중심으로 이루어져야 한다.
2. 조건 및 상태에 따라 다른 스타일이 적용 되어야 한다.
3. 각기 다른 요구사항으로 빠르고 쉽게 적용할 수 있어야 한다.
- css preprocessor : 시간이 많이 드는 작업들을 간소화시켜주는 도구 ex) sass, post css 등-
- 공통 요소의 분리
1. 기능 중심으로 분석
2. 일부 UI 가 다른 경우는 전체 스펙으로 구현 가능한지 검토
- 동적인 UI 스타일 로직
1. @include @mixin, @each 을 사용해 여러 서비스에 따라 달라지는 css 를 적용한다.
- 초반과 달라진점
1. 여러 서비스의 요구사항을 하나의 css 로 사용했다.
2. 공통 스타일이 중심이 되고, 각 서비스의 요구사항을 커스터마이징 한 css 를 추출
3. 모듈화
→ 각각의 요소가 하는 기능에 집중해 모듈화
→ 현재의 요구사항에 맞게 최소한의 기능으로 모듈화
→ 같은 기능을 하는 요소는 동일한 HTML 구조를 갖도록 한다.
4. 설정과 공통 코드
→ 간격, 색상, 서체 등 서비스별로 변경이 쉽도록 설정(config)으로 관리한다.
→ 반복적인 코드는 css preprocessor 기능을 활용
→ 연관된 ui 및 수치는 공통으로 묶는다.
- 모든 요구사항을 플랫폼의 공통 코드로 소화할 수 는 없다.
- 플랫폼의 공통코드는 불변이 아니며 지속적인 리팩토링이 필요하다.
한재엽님 (라인 파이낸셜 플러스) - 주니어 개발자의 성장에 대한 뻔하지만 뻔하지 않은 이야기
- 성장해야 하는 부분
1. 스페셜 리스트 : 성능에 대한 전문가, 특정 라이브러리의 전문가, 데이터 시각화 전문가
2. 제너럴 리스트 : 분야에 대한 이해, 여러 언어에 대한 이해, 여러 플랫폼에 대한 이해
3. 소프트스킬 : 스펙분석, 일정 예측, 리스크 관리, 설계, 커뮤니케이션, 협업에 대한 이해, 사업에 대한 이해
- 왜 성장해야 하는가?
1. 자기만족
2. 높은 연봉
3. 팀원에게 피해를 끼치지 않기 위해
4. 유명해지기 위해
5. 회사로부터 갑질을 당하면 다른 곳으로 이직하기 위해
6. 좋은 개발자가 되기 위해
- 좋은 개발자란... 좋은 개발자가 되기 위해선...
1. 한재엽님은 스페셜 리스트가 되는 것을 성장하는 것의 목표로 잡았다.
2. 성장해야하는 이유부터 정리하라
3. 그것을 바탕으로 어느 쪽으로 성장하고 싶은지 구체화하라.
- 어떻게 성장해야 하는가?
1. 출근 전, 퇴근 후, 주말에 학습해라
2. 사이드 프로젝트를 해라
3. 개발관련 도서를 독파
4. 블로그 좋다
5. 알고리즘도 하루에 한 문제씩 풀기
=> 다 좋지만 이 모든 것을 이루기엔 시간이 부족하다!
- 회사에서 성장하기?
1. 업무를 소비하지 말자
2. 개인 프로젝트의 함정 (예 : 버그 무시, 디바이스 이슈)
3. 삽집을 많이 하자
→ 해결해야 할 문제라고만 생각하지 말자
→ (문제 원인 파악 → 학습 → 문제 해결) 이 과정이 노하우가 되고, 노하우가 쌓여 전문성이 된다.
4. 질문을 잘 하자 바보같은 질문은 없어도 성의없는 질문은 있다. → 동료의 시간을 낭비하지 마라 질문 전에는 질문을 준비하기 어떤 상황인지 구체적으로 물어보기
- 문서화를 잘하자 트러블 슈팅
1. 나는 어쩌다 이 버그를 마주했는가
2. 그 원인은 무엇이었는가
3. 그래서 어떤 시도를 해보았나?
4. 그래서 최종적으로는 어떻게 해결했나
5. 오픈 소스 ISSUE TEMPLATE 을 참고하자
- 팀의 생산성을 높이자.
김민태님 (우아한형제들) - 일 만드는 개발자 vs 일 부풀리는 개발자
요구사항은 어디까지 수용해야 할까? 에 대한 고민상담을 들은 적이 있다.
- 직업인 vs 직장인?
1. 직업인 : 직업에 대한 프로페셔널을 외부에 발산할 수 있는 사람
2. 직장인 : 월급쟁이 → 내가 일을 열심히 하지는 않아도 적당히 하는(?) 사람
- 습관은 관성이 되고, 관성은 도전을 싫어하지. 우리 모두 이렇게 꼰대가 된다... → 건강하고 건전한 마인드를 키우자
- 예외는 사람이 만든다.
- 요구사항은 결국 사람이 만들어내고 분석하고 계획하고 만들어가는 사람 또한 사람이다.
- 다른 분야의 일을 잘 모른다는 전제하에 질문을 많이하면 더 좋은 제품을 만들 수 있다.
→ 내가 그 분야를 많이 안다고 생각하지마라. (예 : 디자인, 기획 등)
- 모든 것에는 의도가 있는데 (각자가 심어놓은 의도) 그걸 알리지 않고 넘어가면 제품의 퀄리티가 높아지지 않는다. 그걸 밸런스를 잘 맞춰주는게 개발자다.
- 본인이 생각했을 때 제품에 좋은 영향을 준다면 그 요구사항을 수용해야 한다. (product 의 product 에 의한 product 을 위한)
- 동료를 위한 개발자가 되어라
- (민태님은) 어떤 개발자가 되고 싶은가?
1. 제품의 품질을 고민하는 개발자
2. 품질은 함께 만들어가는 것임을 아는 개발자
3. 품질에 기여하고 싶은 개발자
- 신입 때 좋은 습관을 길들일 수 있는 최적의 시기이기 때문에 처음부터 좋은 회사를 선택하는 것이 좋다.
한장현님 (카카오뱅크) - 빠르게 훑어보는 웹 개발 트렌드
- 서버중심 개발 → 클라이언트 중심 개발 → 고도화
- 웹 개발 트랜드 ( https://github.com/devJang/developer-roadmap )
1. 서버 중심으로 개발 : 미리 만들어 두거나 서버에서 만든 웹페이지를 제공
2. 클라이언트 중심으로 개발 : 페이지를 부분적으로 갱신, 서버는 API 역할에 집중 (jquery, ajax 출시 시작부터) → 일단 클라이언트를 준비하고, 추가로 필요한 데이터를 클라이언트가 주도적으로 요청해서 이미 화면에 떠있는 페이지 부분 추가 ( DOM 에 적극적으로 개입)
3. 고도화 : 프론트엔드 로직이 복잡해지면서 라이브러리 적극 활용 → 웹 기술로 native 앱을 만들어보자(native script). 오프라인일 때도 실행되게 하자(pwa). 웹 앱을 데스크탑에 설치해보자(node-webkit, electron).
- 요즘 웹 개발
1. 프레임워크, 라이브러리 적극 활용 (리액트, 앵귤러, 뷰 / bootstrap, angular material, clarity)
2. component 기반으로 개발 → 역할에 맞게 추상화된 DOM Element
3. 템플릿 : HTML
4. 스타일 : css, scss, styl
5. 로직 : javascript, typescript
→ 위의 세개를 합쳐 컴포넌트(.jsx, .tsx, .vue)
→ 빌드(babel, webpack, tsc, parcel) 하면 javascript, css 가 나옴
→ 빌드된 결과를 웹 브라우저에서 실행
6. 개발 툴 : git, github
7. UI & UX 디자인 시스템
- 프론트엔드 개발 트렌드는 빠르게 변하기 때문에 계속 찾아보고 공부해야 한다.
- full-stack 에는 물리적인 한계가 존재한다. 전문분야를 선택하는 것이 효율적일 수 있다.
최현철님 (네이버) - 데이터 상태관리. 그것을 알려주마
- 스토어 관리가 힘들다
1. 비동기적으로 데이터가 바뀌기 때문에 데이터 관리가 중요하다.
- 리덕스 : 상태를 관리하기 위한 하나의 아키텍처, 툴 이라고 보면 된다.
- jQuery 와 상태관리
1. jquery 개발은 DOM 에 jquery 로 동작을 입히는 것
2. DOM 이 베이스
3. element 에 상태를 저장
4. 서로 다른 element의 상태변화 추적이 어렵다.
5. 이러한 이유로 유지보수가 커지고 레거시가 점차 커진다.
- angularJS 상태관리
1. 기존 DOM 제어방식은 변경이 필요한 대상 DOM 요소를 먼저 선택(document.getElementById() 와 같이) 하고 필요한 작업을 수행하는 형태
2. angularJS 는 출력할 데이터에 초점을 맞추어 작업이 수행되며, 데이터 값이 변경되면 같이 변경된다. 따라서 DOM 에 접근해 값(상태)를 변경시키는 코드가 없는데도 뷰가 변경된다.
3. 상태가 언제 왜 어떻게 바꼈는지는 알기가 어렵다.
- Redux 와 상태관리
1. 상태(데이터)를 언제, 왜, 어떻게 변화했는지 알기가 어려움
2. (flux) view 는 store 의 상태를 읽기만 하고, 업데이트 할 경우에는 action 을 수행해 dispatcher 를 통해 수정
3. action 을 통해 상태가 업데이트 되기 때문에 로그 확인이 쉽고, 항상 데이터가 일관성있게 유지된다.
4. 문제점 : 많은 보일러 플레이트 / 과한 기술..? / 어렵다....
- FE 앱은 상태(데이터) 들의 유기적인 집합체
- 상태관리는 DOM 의 변화와 비동기 동작 간의 개념 충돌 등 여러 이슈가 발생했다.
- 관점의 변화가 필요하고, 이에 따라 개발 방식 또한 변화 되어야함
- 하지만 현재는 레거시와 angularJS, redux 등이 혼재하기 때문에 경우에 따라 빠르게 관점의 적응이 필요
- 상태 관리 방법은 앱의 전체 구조, 아키텍처를 결정하기 때문에 프로젝트 초기에 치열하게 고민해야한다.
손찬욱님 (네이버) - 오늘부터 나도 FE 성능 분석가
- FE 성능 분석가의 관심사는?
1. 사용자 입력에 얼마나 빠르게 반응 할 수 있나? (LAI : loading and interaction)
2. 초기 로딩 속도(얼마나 빨리 페이지를 볼 수 있나?)
3. 인터렉션 속도 (스크롤 버벅, 키보드 입력할 때마다 깜빡, 애니메이션 진행될 때 깜빡)
- 성능 개선 작업 어떻게 할 것인가?
1. 대상 선정하기 (숲을 보자)
2. 가장 많이 사용하는 화면 요소는 무엇인가?
3. 서비스에서 사용자에게 가치있는 화면은 무엇인가?
4. 개선 프로세스
5. 측정 (어디가 문제야? 어디가 느린 곳이야?)
6. 분석
7. 최적화
=> 이 사이클이 반복
- 성능 개선 작업 시작하기 1
1. 초기 로딩속도 개선하기
→ 웹 서비스 로딩에 대한 이해 필요 ( url 주소로 요청, html 을 string 으로 받아.... 등등)
2. waterfall 차트 개선하기 (높이를 줄이고, 폭을 줄이고, 간격을 땡긴다)
3. js, css 파일을 나눈것을 합친다.
4. 여러 이미지를 하나의 request 로 함치기(sprite 기법)
5. 캐싱되지 않아도 될 이미지를 html 요청에 포함시켜서 요청
6. 초기 로딩 시 불필요 없는 자원은 삭제하거나 뒤로 (lazy)
7. request 를 줄여야하는 이유는 호스트당 동시에 받을 수 있는 요청의 수는 제한되어 있다.
8. request 시간 줄이기(폭 줄이기)
9. request 정보에 대해 알아야 할 필요가 있다.
10. ttfb(time to first byte) 가 높다면 서버 비즈니스 로직을 살펴볼 필요가 있다.
11. content download 속도 줄이기 (js, css)
12. 가장 효과적인 것은 큰 이미지 줄이기 (네트워크 비용, 렌더링 비용이 크다)
- css 가 불러진 다음에 css 에서 사용하는 폰트, 이미지가 로딩.
→ 따라서 (html → css → font, image) 가 로딩 순서
→ head 태그 안에 preload 를 사용하면 css 와 함께 로딩할 수 있음
- HTTP2 에 Server Push 기능이 있다. HTML 과 함께 js, css, 이미지 로딩
- 총체적으로 점검하기
1. 체감 속도 높이기
→ First Paint(FP): HEAD 태그 종료 후
→ First Meaningful Paint(FMP): Hero 엘리먼트가 보이는 시기
→ Time to Interactive
2. 균형감 찾기
3. 각각의 request 를 균등한 크기를 맞추기 (튀는 놈을 없애자)
- 성능 개선 작업 시작하기2
1. CPU 도움 받기
→ javascript 가 DOM 을 건들면 기본적으로 main thread dp dmlgo rendering pipeline 이 동작 rendering pipeline (javascript → style chrome devtool 에서 (computed attribute 를 계산하는 시간) → layout → paint → composite)
→ https://csstriggers.com/ 참고
2. GPU 도움 받기
→ composite : 웹페이지는 하나의 거대한 레이어이며 GPU 는 각각의 레이어를 합치는 작업을 한다.
→ GPU 의 도움을 받기 위해 레이어를 만든다.
> 브라우저가 규칙에 따라 레이어를 구성
> 명시적으로 레이어를 구성
→ GPU 의 side effect
> 레이어를 초기 구성하는 작업은 CPU 가 진행
> 레이어를 원래 비트맵 정보를 복사하기 때문에 2배의 작업이 필요
→ 60fps 보장하기
> 렌더링 파이스가 계속해서 발생하는 경우 프레임은 16ms 내에 완료되어야 한다.
> 애니메이션을 위해서는 requestAnimationFrame 으로 16ms 주기를 보장
→ DOM 건드리지 않는 JS 코드 실행 시간도 16ms 유지하자
렌더과정
1. 서버로부터 HTML 문자열을 Stream 으로 받음(렌더 레이어를 바탕으로 렌더링을 진행)
2. <head> 태그에 포함된 자원을 병렬로 다운로드
3. <head> 태그부터 화면을 그리기 시작
4. <body> 태그부터 화면을 그리기 시작
5. DOM 구성이 완료되면 DOMContentLoaded 이벤트 발생
6. 모든 자원의 로딩 완료되면 load 이벤트 발생 ( 이미지가 로딩 완료된 시점)
( defer : DOM 제어와 관련이 있는 스크립트 / async : 의존성이 없는 스크립트 )
느낀점 : 오랜만에 컨퍼런스를 참여하게 되었고, 개인적으로는 학습의 필요성과 그동안의 나태함을 반성한 계기가 되었다. 다시 공부를 시작해야겠다!