Code & Coffee

2019 네이버 테크콘

April 11, 2019

4/11일 목요일에 네이버 테크콘에 참석했습니다. 신청했던 지인이 못가게 되면서 양도를 받아서 볼 수 있었습니다. 처음 세션 제목만 보았을 때 많은 기대를 했었는데, 역시 기대 이상의 좋은 발표를 들을 수 있었습니다. 특히 네이버, 카카오뱅크, 우아한 형제들 등 국내 굴지의 대기업에 다니시는 분들과 발표 후 질문 타임을 가지면서 많은것을 물어볼 수 있는 점도 좋았습니다. 특히 두번째와 세번째 세션에서 ‘언제까지 주니어 개발자로만 머무를 생각을 버리자’라는 말과, ‘좋은 개발자란 무엇인가’는 말을 들으면서, 어떻게 하면 좋은 개발자가 될지에 대해 고민하던 저에게 많은 것을 깨닫게 해주었습니다. 앞으로도 이런 좋은 기회가 많이 생기고, 저도 저 자리에서 발표할 수 있도록 부단히 노력하겠습니다.

‘좋은 개발자’에 대해 끊임없이 생각해보면서, 즐겁게 개발을 하도록 하겠습니다.

개별 요약

  1. 플랫폼 UI 개발 전략의 모든것

    • 플랫폼이란?
    • 스마트 에디터 기존 설계의 문제점
    • 퍼포먼스 위주의 개발 - 서비스 구분이 없이 모든 스타일이 포함 => 불필요하게 커짐
    • 새로운 설계 시작
    • 디자인이 아닌 디자인 중심으로 : 구조 파악하고 디자인은 스킨 개념으로
    • 상태에 따른 다른 스타일의 적용 : css는 정적인 언어지만, 설계는 동적
    • 다른 요구사항을 쉽고 빠르게 적용 : 설정분리를 통해 하나의 파일에서 변경 가능하게
    • BEM, OOCSS, SMA
    • CSS preprocessor : Sass, less, postcss 등
    • 구현과 문제 해결

    • 공통 요소 분리 : 기능상 공통된 부분

      • 디자인보다는 기능에 중심
      • 동일한 기능을 하는 요소는 동일한 html,
      • 공통화 요소 중 일부 UI가 다른 경우는 전체 스펙으로 구현 가능한지 검토하기

    • 동적인 UI 스타일 로직 - 컴포넌트 간격과 연관된 UI 스펙 분석과 구현: 컴포넌트 종류에 따른 간격 분리

      • 스팩 분석 및 정리 : 컴포넌트에 따라 간격이 달라짐/ 간격과 같은 높이의 텍스트 추가 버튼 필요/ 컴포넌트 사이 간격은 서비스별로 요구사항이 다를 수 있다..
      • 조건에 따른 간격 정하기와 숨겨진 UI
    • 정리
    • 모듈화 : 각각 요소의 기능에 집중해서 모듈화/ 최소한의 기능만으로, 확장성을 배재 /같은 기능의 html은 같게
    • 설정과 공통 코드 : 간격, 색상, 서체, 폰트사이즈 등 변경이 쉽게/ 연관된 ui및 수치는 공통으로 묶어서
    • 플랫폼은 만능이 아니다. : 공통 코드로만 100%안됨, 지속적인 리펙토링, 스펙협의와 커뮤니케이션의 중요성
    • Q&A
    • 리팩토링의 기준 : 반복되는 코드, 설정을 기준
    • 공통코드의 변경시 영향 체크 : 사람의 힘을 빌어서 체크함 => visual migration

  1. 주니어 개발자의 성장에 대한 뻔하지만 뻔하지 않은 이야기

    • 성장?

    • 개발자로서의 성장 => 선택과 집중을 통한 성장

      • 스페셜리스트 : 성능, 특정 라이브러리, chrominum, 데이터 시각화
      • 제너럴리스트 : 다른분야, 여러 언어, 여러 플랫폼
      • 소프트스킬 : 스펙, 일정, 리스크, 설계, 커뮤니케이션, 협업, 사업

    • 왜 해야하는가?

      • 자기만족, 연봉, 이직 등

    • 선택과 집중

      • 내가 하고 있는 일부터!
    • 해야하는 이유 정리 / 구체화

    • 어떻게?

      • 학습, 사이드 프로젝트, 기본 공부, 블로그, 알고리즘?
    • 회사에서 성장하기

    • 업무를 소비하지 말자 : 시키는것, 하던대로, 일단 돌아가게, 그냥 개발을 지양

      • 코드에 대한 책임
      • 개인 프로젝트의 함정
      • 버그
      • 디바이스 이슈

    • 삽질 : 치워버려야 할 버그라 생각하지 말자

      • 원인 파악 (디버깅) : chrome devtools Charles, mobile browser log / remote debugger
      • 해결을 위한 학습하기
      • 해결 시도
      • 축적을 통하 노하우 (원인 분석 및 학습, 해결방안) => 자신만의 전문성으로!

    • 질문을 잘 하자.

      • 바보같은 질문은 있어도 성의없는 질문은 있다.
      • 동료의 시간을 낭비하지 말자.
      • 구글링을 선행
      • 질문의 사전 정리 및 비슷한 수준의 동료에게 질문
      • 질문을 통해 노하우가 됨 : 질문도 문제를 해결하는 과정 중 일부

    • 문서화를 잘 하자 : 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다.

      • 트러블 슈팅 정리
      • 버그를 마주친 계기-상황, 버그 원인, 해결하기 위한 시도, 해결을 기록
      • 문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려 하지 말아라.
    • 공유하기 : 쉬운 것이라도, 처음부터 알던것은 아님

    • 팀의 생산성을 높이자.

      • 개발 환경의 중요성
      • 개선
      • 자동화의 중요성
      • 비판적인 사고
      • 변화무쌍한 스펙 변경에 맞서는 경험
      • 초기에 결정된 스펙은 무조건 변경됨. => 변경될 수 있는 요소를 어떻게 제어할 것인가 고민하기
    • Q&A
    • 간단히 정리 후 회고를 통해 좀 더 Deep 하게 정리 및 문서화
    • 커밋로그를 통한 기록도 좋은 방법중 하나
    • 회사 스펙 외의 다른 기술을 사이드로 하는것이 좋음.
    • 내가 공부한 내용을 정리하면서 진짜 이해한 것인지 파악
    • 코드리뷰 : UX, zeplin guide, api 문서 가이드 참고 및 테스트
    • 테스트코드 : 최대한 많을수록 좋음 - 상태관리 / 단위 - 통합 - e2e 테스트

  1. 일 만드는 개발자 vs 일 부풀리는 개발자

    • 요구사항으로부터 시작
    • 어디까지 요구사항을 수용해야 할까?
    • 결정권의 크기
    • 직업인과 직장인

    • 직업인으로서의 자세

      • 직업으로의 사명감, 전문성

    • 직장인으로서의 자세

      • 적당히 일하려는 자세

    • 상사와 제품 사이

      • 언제까지나 주니어라는 생각을 버리기
    • 습관은 관성이 되고, 관성은 도전을 싫어하개 됨.
    • 개발 Life cycle
    • 분석, 계획, 실행, 측정, 보정
    • 사람이 예외 발생 => 커뮤니케이션을 통한 최대한 줄이기 ex) 이해한 내용에 대해 말함으로써 동의 구하기 => 일 (크고 잘)만드는 개발자
    • 자기식대로 이용해버린다면 일을 부풀리는 개발자가 될 것임
    • 원하는 의도
    • 각자의 의도를 cross check하지 않으면 다들 모름
    • 선한의도와 악한 의도 (판단하는 기준: 제품? 등)
    • 본인이 생각하는 결과가 제품에 긍정적인 효과를 가져온다면 해야함
    • 어떤 개발자가 되고 싶은가?
    • 제품의 품질을 고민하고, 기여하는 개발자
    • 함께 만드는 것을 아는 개발자

  1. 빠르게 훑어보는 웹 개발 트렌드

    • 서버 중심의 웹 개발
    • 클라이언트 중심의 웹 개발
    • 모바일 : 반응형 개발 촉진
    • 클라이언트를 준비 => 필요한 데이터를 주도적으로 서버에 요청
    • 고도화 - 로직이 복잡해지면서 라이브러리 적극적 활용
    • Native app 개발 : Phonegap, nativescript, react native
    • 오프라인에도 사용 : pwa
    • 데스크톱 앱 : Electron
    • 요즘 웹 개발은?
    • Angular, react, vue + css library
    • Component 기반
    • task runner / cli
    • 공부하면 좋은 것들
    • 기본지식 : html , css, js(es6, ts, Framework)
    • Ui, ux
    • 데이터 시각화

  1. 데이터 상태관리

    • 프론트엔드에서의 상태관리
    • 상태는 각각의 뷰에서, 또는 뷰와 상관없이 비동기적으로 변경됨
    • 상태관리 패러다임의 변화
    • jQuery : Dom이 베이스 - 각 element의 상태에 저장 => 상태변화 추적이 어려움
    • angularJs : 출력할 데이터에 초점을 맞추어 작업이 수행되며, 데이터의 값이 변경되면 출력도 자동적으로 수행됨.
    • Redux : 상태를 언제, 왜, 어떻게 변화했는지 알기 위해
    • CQRS
    • EventSourcing

  1. FE 성능 관리

    • 성능에 대한 상식
    • 성능개선은 빠를수록 좋다 => 목표를 정해야 한다.
    • 로딩속도는 수치적으로 빠르면 빠를수록 좋다 => 수치가 높은것도 좋지만 중요 컨텐츠를 빠르게 보여주는 것이 좋다
    • 특정부분 성능을 개선하면 개선한 만큼 향상된다. => 전체 관점에서 봐야함
    • 서비스 성능이슈 개발자의 무지에서 나온다 => 신경 못써서 나옴.
    • 성능 전문가는 서비스의 성능개선 포인트를 찾고 개선할 수 있다.
    • 서비스 성능 개선은 전문성을 갖춘 영역이기에 아무나 할 수 없다. => 노력과 관심이 중요함.
    • 성능 분석가의 관심사
    • 서버 : 얼마나 많은 요청을 처리할 수 있는가? TPS
    • FE : 사용자 입력에 얼마나 빠르게 반응할 수 있는가? (Loading And Interaction)
    • 초기 로딩속도
    • 인터렉션 속도 (스크롤이 버벅거린다, 키보드가 버벅거린다)
    • 성능 개선 작업 어떻게 할 것인가?
    • 대상 선정하기 (숲-시스템의 상태를 보기)
    • 개선 프로세스
    • 측정, 분석, 최적화 Cycle
    • 초기로딩속도 개선 : 3초 내 권장 - naver 는 1.5, 2초내,
    • 구글은 반응성, 애니메이션 로드 등 각각을 세부적으로 나눔 - 사용자에게 꼭 보여줘야하는 부분 기준
    • 초기 로딩속도 개선하기
    • 웹 서비스 구동의 이해
    • 요청 => html 응답 => 브라우져에 도착시 렌더링 => js
    • 로딩 속도 측정 / 분석
    • Waterfall 차트 개선이 핵심
    • 높이를 줄이고, 폭을 줄이고, 간격을 땡기기 => 점검
    • Js, css를 합치기
    • css sprite
    • Data uri - 캐싱하지 않아도 될 이미지를 HTML 요청에 포함
    • 초기 로딩시 불필요 없는 지원을 삭제하거나 뒤에서 로딩하기
    • 실수로 요청한 자원들
    • 초기 로딩시 필요없는 js
    • 뷰포트 바깥에 있는 이미지 : 이미지는 50%이상을 잡아먹음
    • 브라우져는 호스트당 동시에 연결할 수 있는 개수가 정해져 있다. => 많으면 대기하게 됨
    • 폭 줄이기
    • initial connection : http 프로토콜 마다 활용방법이 다르다.
    • 프로토콜 변경 (http2로 변경 권장)

    • TTFB (time to first byte)

      • TTFB가 느리다면 서버가 그만큼 돈 것

    • Content download

      • 네트워크 속도가 낮거나
      • 용량이 크거나
      • 주석제거, 공백제거, 변수명 변경, 난독화
      • Http2를 사용한다 해서 header는 되지만, content 압축이 되지 않음
    • Img 사이즈 줄이기
    • 이미지 포맷, 이미지 메타정보, 이미지 크기 규격화

    • Decode 비용 (렌더링 비용) - 이미지 데이터를 rgb로 변환하는 과정

      • picture, source, srcset 이용 => but 요즘 브라우저는 다 레티나 이상
      • 현실적으로는 이미지 2배크기로 받아서 사용
    • 간격 땡기기
    • 브라우져 렌더링 순서에 대한 이해
    • HTML, CSS => (DOM, CSSOM) => JS
    • 서버로 부터 HTML 문자열을 stream으로 받음 => render tree => layout => paint
    • but js는 Dom을 어디서든 건드릴 수 있음
    • Head 태그에 포함된 자원을 병렬로 다운로드
    • 동시에 받지만, 모두 실행될 떄 까지 기달림
    • DOM 구성이 완료되면 DOMContentload 이벤트 발생
    • Head에는 CSS와 필수 JS만 받아라 / body tag 마지막에 js를 넣어라 => 중간중간에 js를 넣지 말아라
    • defer / async
    • defer : body가 끝난 뒤 실행 - dom 제어에 사용
    • async : download 된 뒤 바로 실행 - analytics 등 dom에 영향이 없는 것에 사용
    • link preload
    • Http2 server piush 기능
    • HTML과 함께 js, css 같이 보냄
    • 중요 요소 선택
    • 빠르게, 또는 lazy하게 처리해서는 안되는 요소들
    • 어떤 정보를 빠르게 보내야 할 지 결정 필요
    • 인터렉션 속도

    • case by case 이지만, 브라우져 main thread 괴롭히지 않는 것이 중요함

      • Style recalculate : DOM의 최종 스타일 계산
      • Layout : DOM의 배치와 크기 계산 => 최소한으로 하는 것이 중요
      • layout발생하는 속성 건드리지 않기

    • GPU의 도움 받기

      • 웹 페이지는 하나의 거대한 레이어이다.
      • GPU는 각각의 레이어를 합치는 작업을 한다.
      • 레이어 만들기
      • 브라우저 규칙에 따라 레이어를 구성
      • 명시적으로 레이어를 구성
      • side effect
      • CPU 부하가 초기에 큼
Written by@Seunghun Kang
Code & Coffee

GitHub