(번역) 훌륭한 프론트엔드 개발자가 되는 법 by Google Engineer

※ 이글은 훌륭한 프론트엔드 개발자가 되는 법에 대해서 Google Engineer PHILIP의 개인적인 의견을 기록한 글 중 주요부분을 발췌하여 번역한 것입니다.

[이 글의 목적]

In this article I’m going to talk about the mindset of a front-end engineer, and hopefully give a more lasting answer to the question: how do you become great?

어떻게 최고가 되는지 그리고 프론트엔드 개발자로서의 가져야할 마음가짐에 대해서 이 글을 적습니다.

[단순히 문제를 풀지말고, 어떤것이 일어나고 있는지를 보라]

I get that there are times when you need something that works, and you need it now. But if you never take the time to understand the root of your problem, you’ll find yourself in the same situation over and over again.

진짜 문제의 근원이 무엇인지 생각을 햅지 않는다면 그 상황을 계속해서 반복적으로 직면하게 될 것이다.

Taking the time to figure out why your hack works may seem costly now, but I promise it’ll save you time in the future. Having a fuller understanding of the systems you’re working within will mean less guess-and-check work going forward.

시간을 내어 왜 당신의 일이 많은 비용을 소모하는 지 생각해보세요, 이게 미래에 당신에게 더 많은 시간을 절약하게 해줄 것입니다. 시스템에 대한 완벽한 이해는 앞으로 갈수록 더 적은 점검과 예측을 하도록 도와줄 것 입니다.

[브라우저가 미래에 변하는 것을 예측하는 법을 배우라]

One of the main differences between front and back-end code is back-end code generally runs in an environment that’s under your control. The front end, by contrast, is completely outside of your control. The platform or device your users have could completely change at any moment, and your code needs to be able to handle that gracefully.

백엔드와 프론트 엔지니어의 차이점은 바로 프론트엔드 영역이 엔지니어가 제어할 수 없는 범위를 포함하고 있다는 것입니다. 웹서비스를 사용하는 사용자의 플랫폼과 디바이스에 따라서, 완전히 다른 환경이 펼쳐질 수 가 있는 것이죠. 따라서, 당신의 코드가 이러한 환경을 자연스럽게 제어할 수 있어야 합니다.

I remember reading through the source code of a popular JavaScript framework back in 2011 and seeing the following line (changed for simplicity):

var isIE6 = !isIE7 && !isIE8 && !isIE9;

In this case IE6 was the catchall for IE versions, presumably to handle versions of IE older than 6. But at soon as IE10 came out, large portions of our application completely broke.

여기 이 코드를 보면, 전혀 IE10을 고려하지 않은 코드여서 IE10가 나오자마자 바로 엄청난 양의 어플리케이션들이 다 망가지게 되었습니다.

[스펙을 읽어라]

In addition, so-called “great” front-end engineers are often the people on the forefront of change, adopting new technologies before they’re mainstream and even contributing to the development of those technologies

소위 말하는 훌륭한 프론트엔드 개발자들은 변화에 앞장서서 새로 등장한 기술들이 주요 기술이 되기전에 발견하여, 그 기술의 발달에 기여하는 사람들입니다.

[다른사람의 소스를 보아라]

Reading other people’s code, for fun, is probably not your idea of a fun Saturday night, but it’s without a doubt one of the best ways to become a better developer.

토요일 저녁에 다른사람의 코드를 재미로 읽는 것은 정말 재밌지 않은 일일지 모르지만, 그렇게 주말을 보냄으로써, 당신은 보다 나은 프론트엔드 개발자가 될 수 있습니다.

[당신보다 똑똑한 사람들과 일을 하라]

The problem with being both self-taught and also working for yourself is you generally don’t get the benefit of learning from people smarter than you. You don’t have anyone to bounce ideas off of or review your code.

혼자 배우고 일하는 것은 당신보다 똑똑한 사람들과 일을 했을 때의 이점을 전혀 얻지 못할 것입니다. 왜냐면, 당신의 코드를 리뷰해주고, 아이디어를 굴려줄 사람이 없기 때문이죠.

If you do end up working for yourself at some point in your career, make a point of becoming (or staying) involved in open source. Actively contributing to open-source projects gives you many of the same benefits of working on a team, sometimes even more.

그래서 혹시나 당신의 커리에어서 혼자 일할 시기가 온다면, 오픈소스에 기여해보세요. 팀으로 일하는 것보다 훨씬 많은 혜택을 가져다 줄 것입니다.

[바퀴를 재창조하라]

Reinventing the wheel is bad for business, but it’s great for learning. You may be tempted to grab that typeahead widget or event delegation library from npm, but imagine how much more you’d learn by trying to build those things yourself.

기존의 것을 재창조하는게 사업의 관점에서는 나쁠지 모르겠으나, 배우기에는 매우 좋은 기회입니다. 3rd Party Library 같은 것을 혼자 만들어보면 정말 많은 것을 배울 수 있거든요.

But in this article I’m talking about how to go from good to great. Most of the people I consider great in this industry are the creators or maintainers of very popular libraries that I use all the time.

제가 생각하는 이 분야의 최고인 사람들은 자주 사용되는 유명한 라이브러리의 제작자이거나 유지하는 분들입니다.

You could probably have a successful career without ever building your own JavaScript library, but you’ll probably also never work close enough to the metal to really get your hands dirty

당신이 아마 자바스크립트 라이브러리를 제작하지 않고도 훌륭한 커리어를 가질 수 있지만, 절대 훌륭한 프론트엔드 개발자가 되기 위한 필요한 경험들은 해보지 못할 것입니다.

[너가 무엇을 배웠는지 적어라]

Last but certainly not least, you should write about what you learn. There are so many good reasons to do this, but perhaps the best reason is it forces you to understand the topic better. If you can’t explain how something works, there’s a decent chance you don’t really understand it yourself. And oftentimes you don’t realize you don’t understand it until you try writing it down.

마지막으로, 배운 것을 꼭 기록하세요. 수많은 이유가 있겠지만서도, 가장 중요한 이유는 당신이 그 토픽을 이해하는데 많은 도움을 준다는 것이니다. 아마 직접 써보기 전까지는 당신이 그것을 제대로 이해하고 있지 않다는 것을 깨닫지 못할거에요.

from http://philipwalton.com/about/


PageSpeed Insights 에서의 모바일 분석

What is PageSpeed Insights?

  • 구글에서 제안하는 튜닝 가이드를 포함한 크롬 플러그인
  • 구글에서 진행한 연구결과에서 페이지 로딩시 일초 이상 지연이 발생하면 사용자에게 poor experience 를 초래한다고 나와있다.
  • PageSpeed Insights 는 사용자가 페이지를 접속했을 때 모바일 네트워크에서도 일초 내로 로딩될 수 있도록 자세한 가이드를 제공한다.
  • 여기서 말하는 1초 이내의 페이지 렌더링은 사용자가 웹 어플리케이션을 조작할 수 있도록 기본적인 ATF (Above The Fold) 콘텐츠를 로딩하는 것을 의미한다.
  • 첫 페이지만 일단 렌더링이 되서 사용자가 조작을 할 수 있으면, 나머지 페이지는 점차적으로 로딩이 되는 형식이다.

Adapting to high latency mobile networks

  • 모바일 웹을 접속하는 사용자들은 대부분 2G, 3G, 4G 등 다양한 네트워크를 이용한다.
  • 전 세계적으로 3G를 대부분 사용하고 있고, 4G는 아직 성장하고 있는 중이다.
  • 네트워크 지연시간은 아래와 같은 범위를 갖는다.
  • 3G 네트워크 : 200 ~ 300ms 의 왕복시간
  • 4G 네트워크 : 50 ~ 100ms 의 왕복시간
  • 여기서 브라우저와 서버와의 일반적인 통신 절차를 보면 아래와 같다. !


  • 위 표를 보면 네트워크 오버헤드에 고정적으로 600ms 시간이 쓰이는데, 내역은 아래와 같다.
  1. hostname (예. google.com) 을 IP 주소로 매칭하는 DNS 작업
  2. TCP handshake 수행을 위한 네트워크 왕복
  3. HTTP 요청을 보내기 위한 네트워크 왕복

Delivering the sub one second rendering experience

  • 위에서 설명한 네트워크 지연시간을 제외하고는 페이지 렌더링 처리를 위해 약 400ms가 남는다. 해당 시간안에 아래와 같은 내용을 처리해야한다.
  • 서버에서 응답을 준다
  • 클라이언트 사이트 코드가 실행 되어야 한다.
  • 브라우저가 콘텐츠의 레이아웃을 조정하고, 렌더링을 해야한다.
  • 이제 각 항목에 대해서 자세히 들여다보자.

(1) Server must render the response (< 200 ms)

  • 서버의 응답시간은 서버가 초기 HTML 파일을 클라이언트에 전달하는데 걸리는 시간이다.
  • Optimization 을 위한 시간이 많지 않기 떄문에 최대한 200 ms 이내가 걸리도록 한다.

(2) Number of redirects should be minimized

  • HTTP redirect 요청이 늘어날 때마다 최소 1개에서 2개의 네트워크 왕복이 늘어난다. (추가적인 DNS 이용이 필요할 시 2개)
  • 따라서, redirect 요청을 최소화 하거나 혹은 아예 없도록 구현한다. (HTML에서 "m dot" 하지 않도록 주의)

(3) Number of roundtrips to first render should be minimized

  • TCP 통신 특성
    • 서버는 첫 네트워크 왕복에서 TCP 패킷을 10개까지 보낼 수 있다. (~14KB)
    • 서버가 보낸 요청을 클라이언트가 인식하기까지 약간의 대기 시간이 발생한다.
  • 이러한 TCP 특성 떄문에 페이지의 첫 렌더링을 위한 콘텐츠의 양을 최대한 줄여 네트워크 왕복 수를 줄여야한다.
  • 브라우저가 한 번의 네트워크 왕복만 하고 바로 페이지를 그릴 수 있게끔 ATF는 14KB 이하로 맞추는 것이 좋다.
  • TCP 표준이 최근에 업데이트가 되어 10개까지 패킷을 보낼 수 있기 때문에, 서버의 구성정보를 최신 버전으로 맞추어 3~4 개가 아닌 10개가 되도록 한다.

(4) Avoid external blocking JavaScript and CSS in above-the-fold content

  • 브라우저는 페이지를 사용자에게 보여주기 전에 파싱을 해야한다.
  • 파싱을 하는 동안 non-async 스크립트나 외장 스크립트를 마주치면 진행하던 파싱을 멈추고 해당 리소스를 다운로드 해야한다.
  • 이렇게 매번 수행할 때마다 네트워크 왕복이 매번 증가하기 때문에 페이지 렌더링이 늦어진다.
  • 결론적으로 Javascript 와 CSS 는 인라인으로 포함하는 게 좋다.
  • 첫 페이지 렌더링에 필요한 리소스만 먼저 로딩하고 나머지 기능은 추가로 로딩하도록 구현해야한다.

(5) Reserve time for browser layout and rendering (200 ms)

  • HTML과 CSS 파싱과 Javascript 실행은 모두 시간을 요하는 작업이다.
  • 모바일 기기의 속도와 페이지의 복잡도에 따라서 이 작업이 수백초가 걸릴 수 있다.
  • 브라우저 오버헤드는 200ms 이하가 되도록 설정한다.

(6) Optimize JavaScript execution and rendering time

  • 복잡하고 비효율적인 코드는 수십 ~ 수백 초가 걸린다.
  • 브라우저에 내장된 개발자도구를 이용하여 코드를 profile 하고 최적화 한다. Chrome Developer Tool Course

Critical Rendering Path

What is it?

  • The sequence of steps the browser goes through to render the page, to convert the HTML, CSS and Javascript into actual pixels on the screen.
  • Always measure first! and Optimize it!

Converting HTML To The DOM

  • Make a request to Server with HTML -> The HTML will be converted to DOM (The browser will be processing the HTML and building the DOM)
  • The specific rules
  1. Every time the browser meets a tag bracket, it automatically emits a token.
  2. e.g)
  3. This entire process is done by the tokenizer.
  4. While it’s being processed, another process is happening which is consuming the token to create nodes.


  • DOM : a tree structure that captures the content and properties of the HTML and all the relationships between the nodes.
  • How Google does optimize it? :
  • [Incremental HTML Delivery] Think about the Google Search Engine. The header renders first and the rest of the HTML based on your search query will be shown to the user. (Returning the partial HTML could be a really nice performance optimization)
  • StackTrace in Timeline :
  • (1) Send Request –> (2) Receive Response -> (3) Receive Data -> (4) Finish Loading -> (5) Parse HTML (Request CSS, Javascript and Images)


Render Tree

  • Combine above those two DOM tree and CSSOM into the render tree.
  • Render tree only captures visible contents
  • How does it work?


  • To know where and how all the elements are positioned on the page
  • “ setting the width as your device width. e.g) device width=320px is width=320px

CRP workflow

  1. Request HTML Resources
  2. Receive Data
  3. Parse HTML (Converting the received Bytes to DOM tree)
  4. Request CSS / Images / Javascript
  5. Contruct CSS Object Model
  6. Recalculate Style (Layout : Build Render Tree (Computing all the styles for the visible contents)
  7. Layout (Compute the location and the size of the render tree elements)
  8. Paint (Render the page on screen)

Hybrid Application Tuning Guide

Mouse Event 보다는 Touch Event를 사용하자

  • 모바일 단말기에서 ‘mousedown’, ‘mousemove’, ‘mouseup’, ‘click’ 등의 마우스 이벤트들 보다는 ‘touchstart’, ‘touchmove’, ‘touchend’ 등의 터치 이벤트들의 속도가 더 빠르다.
  • Mouse 이벤트들의 경우 OS 레이어에서 그 동작을 탐지하여 실행하고, Touch 이벤트들의 경우 OS까지 가지 않고 웹뷰 단에서 즉시 이벤트를 감지하기 떄문이다.
  • Touch 이벤트에서 마우스 click에 대한 이벤트 감지를 하지 않기 떄문에, Zepto, HammerJS 등의 라이브러리를 이용하여 click 이벤트를 처리한다.

Content Reflow를 최소화한다

  • Reflow란 HTML DOM 요소의 위치와 차원을 계산하는 브라우저 프로세스를 의미한다. width, height, wrapping of text, DOM 요소의 절대, 상대 위치 선정 등이 다 여기에 포함된다.
  • DOM 내용이 바뀌거나, DOM 요소가 Resizing 되거나, CSS의 값이 바뀐다거나 할 떄 Reflow가 일어난다.
  • Google Reflow Guideline 의 내용은 아래와 같다.
    1. 불필요한 DOM Depth 줄이기
    2. CSS rules 최소화 하기
    3. 애니메이션 사용 시에는 position-absolute 또는 position-fixed 사용하기
    4. 불필요하게 복잡한 CSS selector 사용하지 않기

Deel Level의 HTML DOM 사용은 피하자

  • HTML의 DOM Level이 깊어질수록 Reflow시에 속도가 더뎌진다. 예를 들어, 특정 DOM 요소의 맨 아래 자식요소를 변환시에 그 요소에 연관된 모든 요소가 변하게 된다.

HTML DOM 요소를 현명하게 사용하자

  • Javascript Array 객체에 데이터가 있고 이 데이터를 <table>에 추가하여 화면에 나타낸다고 하자.
  • <table> 요소를 HTML DOM 요소에 추가하고, Array 객체 안의 데이터들을 한row 씩 DOM 요소에 추가하게 되면 엄청난 비용이 발생한다.
  • 대신 <table> 안에 배열의 값들을 모두 미리 집어 넣어, 한 table을 만든 후 <table>만 HTML DOM 요소에 Append 하는 식으로 코딩한다.

고정된 DOM 요소를 사용하라

  • DOM 요소의 값이 이미 지정되어 있다면, 불필요한 Reflow는 일어나지 않는다.
  • 특히 이미지의 경우 미리 사이즈를 지정하지 않으면, 이미지 로딩시에 상당히 expensive 한 cost가 발생되므로, 항상 이미지를 비롯한 DOM 요소는 미리 크기를 지정하도록 한다.

CSS 스타일에 관련된 Asset들은 Pre-Loading 한다

  • 미리 CSS 관련 자원들을 로딩 해놓는 경우, 웹 로딩시에 자원 로딩하는 시간을 기다리지 않아도 된다.
  • 또한, 자원을 미리 로딩하였기에 Reflow 작업이 일어나지 않는다.

Google Mobile Site Design 25 Principles

Google Mobile Website Design 25 Principles

What makes a good mobile site?

  • 구글에서 119시간 동안 진행한 연구결과에서 다음과 같은 결론이 도출되었다.
  • “Mobile users are very goal-oriented. They expect to be able to get what they need, immediately, and on their own terms.” (모바일 사용자들은 목적 지향적이고, 웹 사이트 이용시에 자신들이 필요로 하는 것들이 즉시 얻어질 수 있기를 기대한다)
  • 연구결과를 토대로 아래의 25가지의 원칙을 도출하였다.

Home page and Site navigation

1. Keep calls to action front and center (주요 기능은 가급적 메인 페이지와 중간에 배치)

  • 사용자가 가장 빈번하게 사용하는 기능을 접근하기 쉽게 배치
  • learn more 같은 사용성이 떨어지는 화면으로 화면을 차지하는 것을 기피하라

2. Keep menus short and sweet (메뉴는 간단하고 심플하게)

  • 사용자들은 메뉴를 사용하기 위해 스크롤링 하는 것을 좋아하지 않는다.
  • 가급적 메뉴는 적고 심플하게

3. Make it easy to get back to the home page (메인 홈으로 가기 쉬워야 한다)

  • 사용자들은 보통 앱의 상단에 있는 로고를 클릭했을 때, 메인 홈으로 가기 원한다

4. Don’t let promotions steal the show (광고나 프로모션이 사용성을 낮추지 않게 한다)

  • 광고나 프로모션이 팝업창 형태로 화면을 가리거나 하는 일은 없어야 한다.최대한 없어지기 쉽게 한다

Site Search

5. Make site search visible (사이트 검색은 쉽게)

  • 정보 검색시에 필요한 것을 빨리 찾을 수 있도록 검색창을 눈에 잘 보이는 곳(가급적 첫 번째 페이지)에 비치한다

6. Ensure site search results are relevant (사이트 검색 결과는 연관성이 높아야 한다)

  • kid 라는 단어를 검색했을 때, kid 글자만 포함된 연관성 떨어지는 단어보다는 해당 사이트의 목적에 맞는 단어조합을 제시할 수 있어야 한다.
  • 자동완성 이나 자동수정 기능등을 이용하여 사용자가 검색하기 더 수월하도록 돕는다

7. Implement filters to narrow results (더 구체적인 결과를 얻기위한 필터는 필수)

  • 필터링을 하기 쉽도록 눈에 띄기 쉬운 곳에 배치한다 (필터를 숨기지 않을 것)

8. Guide users to better site search results

  • 사용자가 원하는 결과를 정확히 얻도록, 검색 하기 전 몇가지 질문들을 던지거나 placeholder 등을 이용하여 필터 값을 유도한다

Commerce and conversion

9. Let users explore before they commit (가입하기 전 사이트 둘러볼 수 있도록 허용)

  • 사용자가 사이트를 둘러보기도 전에 가입을 요구한다면, 비주류 브랜드인 경우에 사용자 유치에 실패할 수 있다.
  • 가입 없이도 사이트를 충분히 둘러볼 수 있도록 설계

10. Let users purchase as a guest (게스트 계정으로도 구매 가능하게)

  • 불필요한 사이트 가입 보다는 게스트 계정으로도 간단한 구매가 가능해야한다

11. Use existing information to maximize convenience (기존 정보로 편리함 극대)

  • 기존의 데이터로 자동완성 기능을 활용하여 편리함을 극대화 하자

12. Use click-to-call buttons for complex tasks (click to call 기능으로 간단하게 전화를)

  • 대부분의 사용자들은 전화 번호를 클릭시에 바로 전화가 걸어지길 기대한다
  • 이외에도 전화 번호를 저장 및 발신에 관한 메뉴로 나타낼 수 있다

13. Make it easy to finish on another device (다른 장치에서 작업을 끝낼 수 있도록 한다)

  • 가끔 많은 사용자들이 구매나 다른 작업들을 진행하다가 기타 device에서 이어 마치기를 원한다.
  • 아이템 구매를 하다가도, 아이템을 확대해서 보고 싶은 경우 등이 이에 해당한다.
  • 따라서, 해당 아이템을 쉽게 SNS에 공유할 수 있게 하거나
  • 사용자들이 해당 링크를 바로 자신의 메일이나 기타 sns에 공유할 수 있게 한다

Form Entry

14. Streamline information entry (정보 입력은 자연스러워야 한다)

  • 사용자들이 해당 데이터 필드의 입력을 마치고 Return을 눌렀을 시에는 다음 필드로 가게끔 한다
  • 결과적으로 사용자들이 더 적게 화면을 터치하도록 한다

15. Choose the simplest input (가장 간단한 입력 폼을 선택)

  • 해당 링크를 참고한다.

16. Provide visual calendar for date selection (날짜 선택시에는 달력이 보이게)

  • 사용자가 날짜 입력을 위해 달력을 따로 찾아보지 않게한다.

17. Minimize form errors with labeling and real-time validation (데이터 폼 입력 시 실시간 validation으로 오류 최소화)

  • 데이터 입력을 위한 레이블 표시 및 입력 폼의 유효성 체크는 항상 중요하다

18. Design efficient forms (효율적인 폼을 설계하라)

  • 자동완성 과 이전 작성데이터를 이용하여 사용자의 수고를 덜어준다
  • 특히 물건 배송을 위한 주소 작성시 requestAutoComplete을 이용하자

Usability and form factor

19. Optimize your entire site for mobile (웹 사이트는 모바일에 최적화 되도록)

  • 사용자 디바이스에 따라 유연하게 레이아웃이 바뀔 수 있는 responseive-layout 을 활용

20. Don’t make users pinch-to-zoom (zoom in & out 이 필요한 화면은 불편하다)

  • 사용자들은 일반적으로 수직 스크롤을 선호하고 수평 스크롤에 불편함을 느낀다.
  • 특정 viewport width 에 국한되는 콘텐츠 설계는 지양

21. Make product images expandable (상품 이미지는 확대 가능하게)

  • 의류 소비자들은 상품을 면밀히 볼 수 있는 확대 기능을 선호한다
  • 구매를 할 떄 상품을 자세히 관찰할 수 없다면 소비량은 줄어든다

22. Tell users which orientation works best (사용자에게 어떤 오리엔테이션이 효과적인지 가이드)

  • 연구 결과에서 사용자는 한번 설정한 화면 orientation에 대해 특정한 상황이 아니면 그 task가 끝날 떄까지 바꾸지 않는 다는 것을 발견하였다.
  • Landscape & Portrait 둘다 지원하도록 설계하고, 그렇지 않을 경우에는 사용자가 최적의 orienation으로 설정하고 볼일을 볼 수 있도록 가이드
  • 화면 전환과 관계없이 중요한 동작들은 모두 실행되도록 설계하는 것이 가장 중요

23. Keep your user in a single browser window (사용자를 한개의 브라우저 안에 있도록)

  • 사용자가 특정 기능으로 사이트 밖으로 나가거나, 새로운 윈도우를 띄우게 하는 요소들을 제거
  • 예를 들어, 쿠폰을 홍보하는 경우, 사이트에서 직접 받을 수 있도록 설계

24. Avoid ‘full site’ labeling (Full Site 표시를 지양)

  • 사용자들이 full site(desktop site) 라는 표시를 보는 경우, 보통 mobile site에는 콘텐츠가 더 적게 들어가 있을 것이라고 추측한다

25. Be clear why you need a user’s location (사용자의 위치가 왜 필요한지 명확히 하라)

  • 사용자의 위치정보가 왜 필요한지 다시 한번 비즈니스 로직에 맞춰 생각하라
  • 호텔 예약 사이트를 예로 보면, 사용자가 다른 지역에 있는 호텔을 예약하려고 하는데 자기 현재 위치 기준으로 근처의 호텔을 추천 받았을 떄 얼마나 당황하겠는가.
  • 가능하면 위치 필드는 빈칸으로 놓고, 사용자들이 필요시에 이용할 수 있도록 한다