티스토리 뷰
경기도 성남시 분당구에 위치한 NAVER 그린팩토리에서 TECH CONCERT : FRONTEND 가 열렸어요. 프론트앤드 개발자가 되고 싶은 분들, 이미 프론트앤드 개발에 종사하고 계신분들 다양한 참가자들이 모여 진행된 이번 개발포럼 ! 프로그램 진행은 아래와 같아요.
플랫폼이란?
복수의 그룹이 참여하고 얻고자하는 가치를 교환할 수 있는 환경을 가진 서비스
플랫폼을 고려하지 않은 UI 개발을 했을 경우
- 커스텀 및 확장을 고려하지 않았기 때문에 추후 발생하는 서비스의 요구사항을 수용하기 어려움.
- 플랫폼의 css와 서비스의 css간섭이 발생하고 스타일의 우선순위 관리가 어려움.
- UI 요소간의 관계를 파악하기 어려워 버그 및 사이드 이펙트 발생.
플랫폼 UI 설계는 무엇이 중요할까?
- 구조를 먼저 파악하고 디자인은 스킨 개념으로 접근하여 UI 공통화는 기능 중심으로 이뤄져야 한다.
- css는 정적인 언어지만 설계는 동적이어야 한다.
- 설정으로 분리하여 하나의 파일에서 모두 변경할 수 있게 한다.
* 설계를 시작하기 전에는 다양한 관점에서 고민이 필요하다. 디자인이 주어졌을 때 추후 변경이 될 요소는 무엇인지, 절대 변경이 되면 안되는 요소, 속성이 있을지 등. 지금 현재는 일어나지 않았지만 약간의 예측을 통해서 확장 할 수 있는 유연한 구조까지 고려 할 필요가 있다.
모듈화
- 디자인보다는 기능에 집중하여 모듈화
- 현재의 요구사항에 맞게 최소한의 기능으로 모듈화 ( 확장 가능성은 배제 )
- 같은 기능을 하는 요소는 동일한 HTML 구조를 사용
플랫폼은 만능이 아니다
- 모든 요구사항을 플랫폼의 공통 코드로 소화 할 수 는 없다.
- 때로는 스펙협의와 커뮤니케이션이 설계보다 중요할 때 도 있다.
- 플랫폼의 공통코드는 불변이 아니며, 지속적인 리펙토링이 필요하다.
회사에서 성장하기
1. 업무를 소비하지 말자
- Production레벨에서 코드를 작성하는 일
- 구현한 코드에 책임을 지는 일
2. 삽질 (잘)하기
- 버그를 눈 앞에서 치워버려야 하는 것 중 하나라고 생각하지 말자
- 문제 원인 파악 → 학습 → 문제 해결로 이어질 수 있는 노하우
3. 질문하는 법
- 바보같은 질문은 없어도 성의없는 질문은 있다.
( 예 : 어? 이거 안되는데 왜 안될까요? )
* 충분한 구글링 선행
* 현재 발생한 상황 정리
* 자신의 시도들을 정리
* 최종적으로는 Yes / No로 대답할 수 있도록 정리
* 그럴수 없다면 자신의 결론에 대한 의견을 답할 수 있도록 정리
- 질문도 문제를 해결하는 과정 중 일부 노하우가 될 수 있다는 것
4. 트러블 슈팅
- 나는 어쩌다 이 버그를 마주했는가
- 그 원인은 무엇이었는가
- 그래서 어떤 시도를 해보았나
- 그래서 최종적으로는 어떻게 해결했나
5. 오픈소스 ISSUE TEMPLATE
6. 문서화하기
- 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 포용한다.
7. 팀의 생산성을 높이자
8. 변화 무쌍한 스펙 변경에 맞서는 경험
- 초기에 결정된 스펙은 무조건 변경된다.
- 나는 이에 어떻게 대응할 것인가
- 변경 될 수 있는 요소들을 어떻게 제어할 것인가
직업인과 직장인
소프트웨어 개발자한테 요구되는 자세 = 직업인의 자세
개발자라는 직업의 사명감과 프로페셔널
상사와 제품 사이
제품을 잘 만들 수 있고 그 제품을 사용하는 고객이 더 좋은 경험을 할 수 있는지에 대한 기준으로 판단
" 습관은 관성이되고 관성은 도전을 싫어한다. 우리 모두 이렇게 꼰대가 된다. "
Q. 어떤 개발자가 되고 싶은가
A. 제품의 품질을 고민하는 개발자, 품질은 함께 만들어가는 것임을 아는 개발자, 품질에 기여하고 싶은 개발자
1. 웹 개발에도 트렌드가 있었다.
서버 중심으로 개발 : 미리 만들어 두거나 서버에서 만든 웹페이지를 제공
↓
클라이언트 중심으로 개발 : 페이지를 부분적으로 갱신, 서버는 API 역할에 집중
일단 클라이언트를 준비하고 추가로 필요한 데이터를 클라이언트가 주도적으로 요청해서 이미 화면에 떠있는 페이지 부분에 추가, DOM에 적극적으로 개입
↓
고도화 : 프론트엔드 로직이 복잡해지면서 라이브러리 적극 활용
복잡해지는 프론트엔드 로직을 체계적으로 관리하기 위해 프레임워크, 라이브러리를 적극적으로 활용
2. 요즘 웹 개발
- 프레임워크, 라이브러리 적극 활용
- Task Runner / CLI 사용
- 개발 툴 ( Git, GitHub )
- UI/UX, 디자인 시스템
3. 정리
Full-stack에는 물리적인 한계가 존재합니다. 전문분야를 선택하는 것이 효율적일 수 있습니다.
1. FE에서 상태 관리란?
눈에 보이는것들과 보이지 않는것들의 상태
상태는 각각의 뷰에서, 때로는 뷰와 상관없이 필요에 의해서 실시간, 비동기로 계속해서 변화
결국 상태가 언제, 어떻게, 왜 변화했는지 제어할 수 없는 상황에 이르게 됨
- 상태가 언제, 어떻게, 왜 변화했는지 제어할 수 있도록 하는것을 상태 관리라고 한다.
2. jQuery와 상태 관리
- jQuery 개발은 DOM에 jQuery로 동작을 입히는 것
- DOM이 베이스
- 각 Element에 상태를 저장
- 서로 다른 Element의 상태변화 추적이 어려움
3. AngularJS와 상태 관리
* AngularJS의 기본개념 - 기본적으로 모듈이라는 개념을 사용 (컴포넌트와 비슷한 개념)
- 컨트롤러라는 지시자를 이용하여 마크업 상에 영역 생성
4. Redux와 상태 관리
FLUX + CQRS + Event Sourcing을 이용하면 상태가 언제, 어떻게, 왜 변화했는지 제어할 수 O = Redux
상태가 복잡한 큰 어플리케이션에서는 유용하게 사용
5. 정리
- FE앱은 상태(데이터)들의 유기적인 집합체
- 상태 관리는 DOM의 변화와 비동기 동작 간의 개념 충돌 등 여러 이슈가 발생하였음
- 상태 관리에 대한 다양한 접근법이 제시되었고 현재로 올수록 DOM 중심에서 상태 중심의 개발 방법이 제시
- 관점의 변화가 필요하고, 이에 따라 개발 방식 또한 변화 되어야 함
- 하지만 현재는 레거시(jQuery)와 AngularJS, Redux등이 혼재하기 때문에 경우에 따라 빠르게 관점의 적응이 필요
- 상태 관리 방법은 앱의 전체 구조, 아키텍쳐를 결정하는 매우 중요한 요소이기 때문에 앱 개발 시작 전 치열하게 고민해야 함
우리가 알고 있는 성능에 대한 상식
1. 성능 개선은 빠르면 빠를 수록 좋다.[x]
→ 목표를 설정해야한다.
2. 로딩속도는 수치적으로 빠르면 빠를수록 좋다.[x]
→ 수치가 높은 것보다는 사용자에게 보여줄 Hero 컨텐츠를 빠르게 보여주는게 더 좋다.
3. 특정 부분의 성능을 개선하면 개선한만큼 성능 향상이 된다.[x]
→ 전체 관점에서 가장 많이 사용하는 페이지를 살펴봐야 한다. 워터풀 차트의 경우 전체 폭이 줄어들 수 있도록 필요한 부분을 개선해야한다.
4. 서비스 성능이슈는 개발자의 무지에서 나온다.[x]
→ 사실 바빠서 신경을 못써서 나온다. 무지는 다른 이야기다.
5. 성능 전문가는 서비스의 성능개선 포인트를 찾고 개선 할 수 있다.[x]
→ 성능개선사항을 누구보다 잘 아는 사람은 서비스를 개발한 담당자이다. 성능전문가는 찾을 순 있지만 개선 할 수 는 없다.
6. 서비스 성능 개선은 전문성을 갖춘 영역이기에 아무나 할 수 없다.[x]
→ 오늘 강의만으로도 여러분은 충분히 할 수 있다. 노력과 관심이 중요하다.
서버성능분석가의 관심사
서버가 얼마나 많은 요청을 처리할 수 있나 = TPS (Transition Per Seconds)
* FE성능분석가의 관심사 = LAI (Loading and Interaction)
- 초기 로딩 속도 (Loading)
얼마나 빨리 페이지를 볼 수 있는가?
- 인터렉션 속도 (Interaction)
스크롤이 버벅거려요.
키보드를 입력하는데 버벅거려요.
얼마나 매끄럽게 애니메이션이 동작하는가?
성능 개선 작업 어떻게 할 것인가?
1. 대상 선정하기
- 서비스에서 가장 많이 사용하는 화면이 무엇인가?
- 서비스에서 사용자에게 가치있는 화면이 무엇인가?
2. 개선 프로세스
- 측정, 분석, 최적화, 측정, 분석, 최적화 ...
3. 언제까지?
- 목표에 도달할 때 까지
목표는 초기 로딩 속도 3초 !
가장 효과적인 방법 = 초기 로딩 시 불필요한 자원은 삭제하거나 뒤로
예) 실수로 요청한 자원들, 초기 로딩시 필요 없는 JS, *뷰 포트 바깥에 있는 이미지
성능 격언
- head 태그에는 css와 필수 JS만 넣어라
- JS는 body태그 마지막에 넣어라
프론트앤드 개발을 이제 막 시작하는 주니어 개발자로써 다양한 조언과 노하우, 프론트앤드 개발 방향성을 배울 수 있게 된거 같아 유익한 시간이었어요. 컨퍼런스 내용도 난이도가 높지 않아 충분히 이해하면서 들을 수 있어서 더욱 좋았던거 같네요 ㅎㅎ 앞으로도 종종 이런 좋은 컨퍼런스가 있다면 신청해서 들어봐야겠어요 : )
강연에 사용된 PPT 자료는 https://www.slideshare.net/NaverEngineering 에서 다운받아 볼 수 있고, 참가 신청을 했는데 참가자로 선정이 되지 않았거나 강연 내용이 궁금하신 분들은 https://tv.naver.com/naverd2 에서 라이브 동영상을 제공하고 있으니 참고하세요 ㅎㅎ!!