의 내용 중에서 Front-end 개발자가 하는 일 부분을 뽑아 봄.
대부분의 사람들이 생각하는 프론트엔드 엔지니어링
- 포토샵 파일, 이미지, 와이어프레임 등을 가지고 웹 페이지를 만드는 일
- 때로는 앞서 나온 포토샵 파일, 이미지, 와이어프레임을 그리는 일
- 웹 페이지에 애니메이션을 만들고 트랜지션 효과를 주기 위해 자바스크립트를 작성하는 것
- 콘텐츠를 정의하고 이를 꾸미는 HTML과 CSS를 작성하는 것
프론트엔드 개발자가 실제로 하는 일
- 디자이너와 엔지니어 간의 시각적 언어 확립
- 시각 디자인으로부터 콘텐츠, 브랜드, 기능 등을 표현할 컴포넌트 세트 정의.
- 컨벤션, 프레임워크, 요구 사항, 시각적 언어, 스펙 면에서 웹 애플리케이션의 기준 확립
- 웹 애플리케이션의 범위를 기기, 브라우저, 화면, 애니메이션의 측면에서 정의
- 브랜드 충성도, 코드 품질, 관계자의 상품 리뷰를 위한 품질 보증 가이드라인 개발
- 적절한 간격, 타이포그래피, 헤딩, 글꼴, 아이콘, 여백, 그리드 등을 사용해 웹 애플리케이션 꾸미기
- 디자인 가이드라인을 따르며 다양한 해상도에 대응하는 이미지, 디바이스별 목업 등을 사용해 웹 애플리케이션 꾸미기
- 시맨틱, 접근성, 검색엔진 최적화, 스키마, 마이크로포맷 등을 고려하여 웹 애플리케이션 마크업하기
- API에 접근하여 사용하기 편하고 배터리 소모가 없는 디바이스 및 클라이언트가 인지하는 방식으로 정보를 가져오기
- 부드러운 애니메이션, 트랜지션, 게으른 로딩lazy loading, 인터랙션, 애플리케이션 워크플로우를 수행하는 클라이언트 사이드 코드 개발. 대부분 점진적 기능 향상 및 하위 표준 호환성까지 고려.
- CORSCross Origin Resource Sharing을 고려하는 한편 XSSCross Site Scripting와 CSRFCross Site Request Forgery 공격을 막아낼 수 있도록 백엔드 접속에 대한 안전성 확보
- 엄격한 데드라인, 관계자들의 요구, 기기별 제한에도 불구하고 항상 사용자가 최우선이라는 점을 잊지 않는 것
- 이러한 목표를 달성하기 위해 프론트엔드 엔지니어들은 시각 디자인 도구(포토샵, Adobe, Macaw, Sketch)부터 프로그래밍 도구(IDE, Command Line, Source Version Control, Bash 스크립트, 빌드 태스크)까지 다양한 도구를 사용한다. 심지어 간혹 마케팅(뉴스레터, 캠페인, 분석, 검색엔진최적화, 소셜미디어), UX(애니메이션, 트랜지션, 피드백, 인터페이스, 시각적 언어)부터 콘텐츠 수정(구획점, 단어가 뚝 떨어지지 않게 하는 일, 가독성, 색상)까지 신경써야 한다.
나쁜 프론트엔드 엔지니어
- 자바스크립트 라이브러리를 남용하는 사람. 자바스크립트 내부를 제대로 알지 못하기 때문에 라이브러리를 남용한다(예. 모든 작업에 jQuery 가져다 붙이기).
- 자바스크립트 플러그인을 남용하는 사람. 다른 사람의 코드를 읽을 능력도 없이 가져다 쓰는 경우(예. jQuery.doParallaxPls.js).
- 전체 CSS/JS 기능의 5% 밖에 안 쓰면서 요구사항이나 디자인도 안보고 성능 비교/평가도 안하고 웹 애플리케이션 CSS 프레임워크를 붙이는 사람.
- CSS 프레임워크만 가져다 붙이면 “반응형” 웹 사이트가 된다고 생각하는 사람. 또는 이러한 반응성이 웹 애플리케이션에 언제든 뿌리기만 하면 되는 양념으로 생각하는 사람.
- “반응형 웹 디자인”에 대해 말하면서 서버측 기법에 대해서는 알지 못하는 사람.
- 컨벤션, 전처리 도구(preprocessor), 네이밍 표준, 모범 예시없이 CSS 코딩을 하면서 셀렉터, 아이디, 매직 넘버, !important를 과하게 사용하는 사람.
- 성능, 메모리 누수(+메모리 누수가 무엇인지 잘 모르는 점)에 대해 무시하고 자신의 코드를 검사하거나 측정하지 못하는 사람.
- 아무런 기준없이 제품을 보여주는 사람 또는 “제 컴퓨터/브라우저/디바이스에서는 잘 됩니다” 따위를 기준으로 삼는 사람.
- 30년 된 소프트웨어 엔지니어링을 무시하면서 소프트웨어를 작성하는 사람
숙련된 프론트엔드 엔지니어가 알아야 하거나 작업시 해야할 일 (힌트: 바로 여러분이 고용하고 싶은 사람이다)
- DNS Resolution, CDNContent Delivery Networks 사용, 여러 호스트 이름을 통한 리소스 요청 성능 향상
- HTTP 헤더 (Expires, Cache-Control, If-Modified-Since)
- 스티브 사우더스의 규칙 전부 (고성능 웹사이트)
- PageSpeed, YSlow, 크롬 개발자 도구 Audit, 크롬 개발자 도구 Timeline에서 보여주는 문제를 해결하는 법
- 작업을 서버에서 해야할 때와 클라이언트에서 해야할 때 구분
- 캐시, 프리 페칭pre-fetching 및 지연 로드 기법
- 네이티브 자바스크립트. 직접 바닥부터 코드를 작성해야 할 때 혹은 다른 사람의 코드를 가져다 써야 할 때를 아는 것. 그리고 두 작업의 장점과 단점을 평가할 수 있는 능력
- 최신 MVC 자바스크립트 라이브러리(예. AngularJS, EmberJS, ReactJS), 그래픽 라이브러리(예. D3, SnapSVG), DOM 관련 라이브러리(예. jQuery, Zepto), 게으른 로딩 또는 패키지 관리 라이브러리(예. RequireJS, CommonJS), 태스크 관리자(예. Grunt, Gulp), 패키지 관리자(예. Bower, Componentjs), 테스팅(예. Protractor, Selenium)에 대한 지식과 사용.
- 이미지 포맷과 장점. 언제 무엇을 어떻게 써야 하는가에 대한 지식. 이미지 최적화 기법과 사용 계획 (스프라이트, 게으른 로딩 기법, 캐시 비움, 인터레이스드 PNG)
- CSS 표준, 최신 컨벤션과 기법(예. BEM, SMACSS, OOCSS)에 대한 지식과 사용
- 자바스크립트의 컴퓨터 과학(메모리 관리, 싱글 스레드 특성, 가비지 컬렉터 알고리듬, 타임아웃, 스코핑, 호이스팅, 패턴)
참으로 적절하구나.
웹을 구축한다는 것은 프론트와 백엔드에 대한 높은 이해도가 필요하다.
양쪽을 모두 잘 이해하고 발전해 가는 것은 정말 좋은 좋은 방향일 것이다.
대부분 웹사이트 속도 문제는 백엔드 개발이 진짜 개판이 아닌 이상 프론트엔드에서 발생한다고 생각한다.
특히나 프론트엔드 개발자가 아닌 백엔드 개발자가 프론트에 덕지덕지 붙여놓은 Javascript가 문제될 때가 많다.
지금은 거의 소멸해 가고 있는 중이지만, 예전 xhtml dtd를 배운 개발자들은 JS를 무조건 head 안쪽에 박아넣고 문제를 일으킨다. defer나 async를 알았으면 참 좋으련만..
예전에 한 개발대장님께서 내가 만든 JS코드를 보고 이런 얘기를 한 적이 있었다.
‘왜 이렇게 코드를 어렵게 만들었어요? 그냥 function banana(){} 하고 banana() 호출하면 되지.’
아마 그때 코드가 몇가지 IIFE(immediately invoked function expression) 패턴, closure를 조금 사용해
팀원들의 스킬업을 하려는 목적도 갖고 있었던 코드였다.
실제로 국내에선 JAVA개발자가 여러가지 이유로 Javascript를 꽤 많이 손대는 상황인데도 참 안타까운 일이었다.
참고로 아직 잘 모르는 백엔드 개발자는 기억해 주면 좋겠다.
head 태그 안쪽에 JS를 그냥 링크하거나 작성한다면 Function expression 으로 작성하던지 defer나 async 를 사용해 주길 바란다.
늘상 사용하던 것처럼 function apple() {} 을 head태그 안쪽에 넣어둔다면
코드만 메모리에 올리는 게 아니라 실제 구동되는 내용을 모두 메모리에 올리게 된다.
또한 이것들이 모두 완료될때까지 body에 렌더링은 늦춰진다.
그래서 되도록이면
- 제발 head 에 JS때려넣지 마세요.
- 되도록 body 닫는 태그 직전에 JS를 링크해 주세요.
- 꼭 필요한 경우가 아니라면 선언 함수 사용을 자제해 주세요.
function apple() {} - 그리고, 우리 모두 계속해서 공부합시다!