diff --git "a/05\354\236\245/5\354\236\245_\353\260\230\354\235\221\355\230\225_\354\233\271_\353\224\224\354\236\220\354\235\270_\353\260\260\354\247\204\354\230\244.md" "b/05\354\236\245/5\354\236\245_\353\260\230\354\235\221\355\230\225_\354\233\271_\353\224\224\354\236\220\354\235\270_\353\260\260\354\247\204\354\230\244.md" new file mode 100644 index 0000000..69455c0 --- /dev/null +++ "b/05\354\236\245/5\354\236\245_\353\260\230\354\235\221\355\230\225_\354\233\271_\353\224\224\354\236\220\354\235\270_\353\260\260\354\247\204\354\230\244.md" @@ -0,0 +1,126 @@ +--- +title: 5장 반응형 웹 디자인 +--- + +모바일 기기는 다음과 같은 문제를 가지고 있다. + +- 모바일 네트워크의 긴 대기시간 +- 배터리를 전원으로 사용하는 하드웨어 + +이러한 제약사항이 있음에도 불구하고 우리가 디자인하는 웹 사이트는 사용자에게 불필요한 오버헤드를 줄여 체감 성능을 최적화 해야한다. + +## 전략적 컨텐츠 로딩 + +미디어 쿼리를 잘못 사용하면 엄청난 오버헤드를 줄 수도 있다. 특히 데스크톱 버전으로 디자인 한 후 모바일을 디자인 할 때 이러한 현상이 자주 발생한다. 따라서 이러한 점을 고려해 어떤 콘텐츠를 어떻게 로딩할지 결정하고 사용자에게 꼭 필요한 바이트만 전달하도록 해야한다. + +### 이미지 + +이미지는 페이지에 표시되는 크기와 동일한 이미지를 제공해야 한다. + +레티나 화면은 같은 물리적 크기의 화면에 두 배 많은 픽셀을 표기하기 때문에 필요에 따라 두 배 큰 이미지를 전송한 후 브라우저에서 표시할 때 크기를 줄일 수 있다. 레티나 디스플레이를 사용하는 사용자는 이미지가 선명하게 보이지만 다른 사용자는 불필요하게 큰 이미지 파일을 다운받도록 하는 것이기도 하다. + +사용자에게 어떤 이미지를 전달할지 RESS기법, CSS 미디어 쿼리, picture 태그 등을 활용할 수 있다. + +RESS(Responsive web design with server-side components)는 사용자에게 어떤 자원을 제공할지 서버측에서 사용자의 유저 에이전트를 분석하여 화면 크기, 터치 여부 등을 추측하여 제공하는 방식이다. 그러나 이 기법은 사용자 장치의 화면 크기 변화에 올바르게 대응할 수 없다. + +CSS 미디어 쿼리를 사용하여 제공할 경우 주의할 점은 브라우저가 예상치 못한 동작을 할 수 있으므로 주기적인 테스트가 필요하다. 예를들어 `display: none`을 설정하는 것으로는 브라우저가 이미지를 다운받는 것을 방지할 수 없다. 배경이미지 역시 동일한데 부모 요소를 `display: none` 설정하거나 미디어 쿼리에서 어떤 파일을 받을지 명시하여 방지할 수 있다. + +```css +#parent { + display: none; +} + +#children { + background: url(...) +} + +or + +@media ... { + #children { + background: url(...) + } +} +``` + +최신 브라우저 가장 권장하는 방법은 picture 태그를 사용하는 것이다. picture 태그는 **위에서 아래의 순서대로 확인하면서 일치하는 이미지를 다운받는다.** + +```html + + + + + +``` + +고해상도 이미지를 제공할 때는 `srcset`을 다음과 같이 작성할 수 있다. + +```html + + + + + +``` + +`type` 옵션을 사용하여 브라우저 지원하는 파일 타입을 제공할 수도 있다. + +```html + + + + +``` + +아래와 같이 브라우저별 최적화 이미지를 제공하기 좋은 방법인 것 같다. + +```html + + + + + + Photo of my cute Kitty Cat + +``` + +sizes...? + +### 글꼴 + +글꼴 역시 추가적인 요청이 발생하고 총 페이지의 크기도 증가하기 떄문에 많은 양의 오버헤드를 줄 수 있다. 미디어 쿼리를 이용하여 모바일 사용자가 접근한 경우에는 글꼴을 다운받지 않도록 (대부분의 브라우저는 글꼴이 필요한 상황에서만 명시된 글꼴를 다운받도록 동작함) 하여 사용자의 트래픽을 아낄 수 있다. + +## 접근 방법 + +### 프로젝트 문서화 + +사용자가 사용하는 기기가 무엇이든 페이지의 크기나 요청 횟수를 불필요하게 증가시키는 상황을 피하자는 것을 프로젝트 문서에 남겨두는 것이 좋다. 개발할 때 사이트 속도도 타협 대상이 될 수 있다. 상황에 맞는 성능 예산을 정해두고 목표를 얼마나 달성했는지 확인할 것이라는 점도 언급해야 한다. 프로젝트에 참여하는 사람들이 성능에 대한 예상치를 가지도록 돕자. (7장에서 자세히 다룸) + +### 모바일 퍼스트 + +모바일을 중심으로 생각하면 사이트를 디자인할 때 도움이 된다. 다음의 행동들이 자연스럽게 따라오기 때문이다. + +- '이 페이지의 가장 중요한 목적은 무엇인가?'와 같은 핵심적인 질문에 대한 고민 +- 사용자에게 가장 중요한 기능과 콘텐츠를 구분 +- 재사용할 수 있는 디자인 패턴을 만들고 그것을 화면 크기기에 따라 변경하는 방법 고민 +- 사이트 접근성, 인터넷이 느리거나 성능이 낮은 기기에서도 접속이 용이한지 생각 + +데스크톱 대신 모바일을 중심으로 생각하면 기능을 추가하거나 더 강력한 애니메이션과 스타일을 적용하거나 혹은 새로 출시된 디바이스의 기능을 사용할 때마다 이런 새로운 변화가 성능에 미치는 영향을 추적해서 점진적으로 사이트를 향상시킬 수 있다. + +모바일 사용자 경험이 데스크톱보다 무조건 빈약해서는 안된다. 의도적으로 어느정도 줄일수는 있지만 렌더링되는 플랫폼의 한계를 이해하고 난 후 결정한 것이어야 한다. 모바일 버전과 데스크톱 버전 모두가 중요하며 한쪽이 다른 한쪽을 보조하는 관계는 아니다. + +모바일을 우선하면 자연스럽게 사용자의 요구 사항에 관심이 생기고 이는 사이트의 성능을 개선하는 데도 도움이 된다. 사용자가 사이트에 바라는바를 이해하면 사용자가 원하는 콘텐츠를 중심으로 보여주는 것에 집중할 수 있다. 작은 화면 크기에 적합한 기능과 콘텐츠가 무엇일지 결정하다보면 자연스럽게 총 페이지 크기와 요청 수도 낮게 유지될 것이다. + +반응형 웹사이트를 만들 때 가장 작은 화면을 먼저 고려하는 것이 좋다. 가장 작은 화면에 맞는 CSS를 재정렬하고, 사용자의 화면 크기가 커질 때 필요한 콘텐츠와 기능을 추가하는 점진적 개선을 하자. 화면 크기에 적절한 자원을 제공하고 스크롤하는 과정에서 쟁크(버벅거림)가 없는지 확인하자. + +## 모든 것 측정하기 + +반응형 웹사이트에서도 일반 사이트에서 수행했던 방법대로 테스트를 할 수 있다. 하지만 반응형 웹 디자인 측정에는 몇 가지를 추가적으로 고려해야 한다. + +먼저 화면 크기게 맞춰 알맞은 콘텐츠만 제공하고 있는지 확인해야 한다. + +가능하면 선택한 기준별로 총 페이지 크기를 측정할 수 있는 자동화 테스트를 구현하자. 크롬 개발자 도구를 활용하여 가상 기기를 활용해 수동으로 테스트 할 수도 있다. + +특정 기기가 이미지를 의도한대로 다운받는지 혹은 여러 이미지를 동시에 다운받은 것은 아닌지 주의해서 확인해야 한다. + +지속적이고 반복적으로 사이트의 성능을 측정해두면 새로운 기능을 추가할 때나 사이트가 오래되어서 페이지 로딩 시간을 개선해야 할 때 좋은 참고 자료가 될 것이다. (6장에서 자세히 다룸) diff --git "a/06\354\236\245/6\354\236\245_\353\260\230\353\263\265\354\240\201_\354\204\261\353\212\245_\354\270\241\354\240\225_\353\260\260\354\247\204\354\230\244.md" "b/06\354\236\245/6\354\236\245_\353\260\230\353\263\265\354\240\201_\354\204\261\353\212\245_\354\270\241\354\240\225_\353\260\260\354\247\204\354\230\244.md" new file mode 100644 index 0000000..fa06490 --- /dev/null +++ "b/06\354\236\245/6\354\236\245_\353\260\230\353\263\265\354\240\201_\354\204\261\353\212\245_\354\270\241\354\240\225_\353\260\260\354\247\204\354\230\244.md" @@ -0,0 +1,61 @@ +--- +title: 6장 반복적 성능 측정 +--- + +벤치마크는 현재 사이트가 제공하는 사용자 경험의 상태를 이해하기 위해서만 중요한게 아니라 시간에 따라 무엇이 성능에 영향을 미치고 있는지 파악하는 데도 도움이 된다. + +## 브라우저 도구 + +### 와이슬로우 + +와이슬로우는 자원의 총 파일 크기를 확인할 수 있고 로딩 시간 개선을 위한 기본 권장사항도 얻을 수 있다. (플러그인 설치가 불가능하여 사용해보지 않음) + +> 권장사항을 검토할 때 우리 사이트는 우리가 가장 잘 알고 있다는 사실을 잊어서는 안된다. 권장사항 중에는 사이트에 적용하기 적합하지 않은 항목들이 있을 수 있다. 모든 권장 사항은 읽고 적용이 가능할지 고민해야 하지만 모든 안을 적용하지 못한다 해도 상관없다. + +### 크롬 개발자 도구 + +크롬 개발자 도구 내 검사(Audits, 아마도 Lighthouse로 바뀐 거겠죠?)에서 제공하는 개선 권장사항을 확인할 수 있다. + +네트워크 탭에서 자원에 대한 요청의 타임라인을 확인할 수 있다. 어떤 자원이 로딩할 때 오래 걸리는지, 각 요청마다 어떤 종류의 대기 시간이 발생했는지 쉽게 확인할 수 있다. 중요 랜더링 경로가 양호하고 긴 시간을 잡아먹는 요청이 없다는 것을 확인하기 위해 네트워크 탭을 계속 확인하는 것이 좋다. + +쟁크를 구분할 때도 크롬 개발자 도구를 사용할 수 있다. 렌더링 도구창에서 FPS 미터를 켜면 페이지를 스크롤할 때 페이지의 어떤 부분이 프레임 드롭하는지 볼 수 있다. + +## 모의테스트 + +모의테스트는 다른 기기에서 사이트에 접속한 경우에 어떻게 동작하는지 살펴보는 것이다. 인위적 성능 도구를 사용하면 전세계 여러 지역, 다양한 플랫폼에서 접속한 것처럼 테스트가 가능하다. + +[웹페이지테스트](https://www.webpagetest.org/)는 가장 인기있고 문서화가 잘 되어있는 테스트 솔루션이다. 기본 설정으로 테스트를 하면 같은 화면을 두 번 확인한다. 이를 통해 페이지에 처음 로딩했을 때와 자원이 캐싱된 후 로딩했을 때를 비교할 수 있다. 보통 다섯 번 정도는 테스트하는 것을 권장한다. 최대 1년 동안의 테스트 결과를 보관하므로 페이지 로딩 시간을 개선할 때 이전에 수행했던 테스트와 비교가 가능하다. + +개인 인스턴스를 호스팅해 볼 수도 있는데 이를 통해 개발중인 사이트를 테스트 할 수 있다. 또한 개인 인스턴스에서는 자동화 테스트를 실행할 수 있어 시간을 절약할 수 있는 장점이 있다. + +성능 리뷰와 첫 바이트 시간(TTFB), 이미지 압축 점수만 볼 것이 아니라 폭포수 차트를 주의깊게 살펴보아야 한다. 이를 통해서 긴 시간을 잡아먹는 요청을 구별할 수 있다. 어떻게 하면 짧은 폭포수를 가질 수 있을지 고민하자. + +## 실제 사용자 모니터링 + +실제 사용자 모니터링은 사용자가 사이트의 페이지를 방문했을 때 웹 트래픽을 기록하여 사이트를 이용하는데 걸리는 실제 시간을 분석할 수 있게 도와주는 도구다. 구글 애널리틱스, 엠펄스, 글림스 등이 대표적인 실제 사용자 모니터링 도구이다. 이를 통해서 + +- 지리적 위치 (거주하는 지역과 데이터 센터의 물리적인 거리) +- 네트워크의 종류 (모바일 네트워크, 무선 랜) +- 중간 값과 페이지 로딩 시간의 95번째 백분위수 + +> 페이지 로딩 속도의 중간 값은 사용자가 페이지를 로딩하는데 걸리는 시간에 대한 일반적인 경우를 설명하는 경우에 유용하다. 한편 95번째 백분위수 지표는 대부분의 사용자가 우수한 사용자 경험을 느끼고 있는지를 확인하는데 유용하다. 95번째 백분위수를 다시 말하면 가장 느린 하위 5% 페이지뷰인데 총 사용자 수의 5%는 무시할 수 없는 숫자다. + +95번째 백분위수의 페이지 로딩 시간과 평균 페이지 로딩 시간은 어떻게 다를까? 각 국가에 따라 사이트가 어떻게 다르게 동작할까? 모바일 기기를 통해 접속한 사용자는 어떨지? 사이트 상위 다섯 개 페이지의 로딩 시간들 사이에 큰 차이가 있는지? 등의 내용을 생각해보면 좋을 것이다. + +## 시간에 따른 변화 + +콘텐츠가 추가되고 디자인도 바뀌는 등 사이트는 계속 변하기 때문에 정기적인 사이트 성능 점검을 통해 페이지 크기, 총 로딩 시간, 체감 성능의 큰 변화 혹은 다른 부서에서 비롯된 갑작스러운 일을 최대한 빨리 찾는 것이 중요하다. + +예를 들어 새로 추가한 이미지 전시 방식 때문에 로딩 속도가 갑자기 느려졌는가? 사이트 내의 모든 페이지에 마케팅을 위한 스크립트가 추가되었는가? 컨텐츠 담당자가 권장 파일 크기보다 큰 이미지를 업로드했는가? 이처럼 성능에 갑작스러운 일이 생길 때 문제 지점을 찾을 수 있도록 정기적으로 주요 페이지를 검사해야 한다. + +혹은 조금씩 꾸준히 성능이 낮아지는 경우도 있을 수 있다. 이럴때는 발견하기도 수정하기도 어렵다. 가능하다면 매주 정기적으로 성능을 벤치마크해 두면 성능 저하가 미세하게 발생하는 경우라도 감지할 수 있다. + +3장에서 살펴본 것처럼 정기적으로 이미지를 확인해야 한다. 이미지 스프라이트, 이미지 형식, 압축을 확인하는 정기적인 일정을 만들자. 새로 추가한 이미지는 자동으로 압축이 되는지 필요한 크기에 다라서 제공되는지 확인하자. + +사용자가 가장 많이 접속하는 상위 5개 페이지의 크기도 확인하자. 만약 페이지 크기가 눈에 띄게 증가했다면 이유가 무엇인지 찾아 수정하고, 만약 수정할 수 없다면 다른 부분을 개선할 수는 없는지 찾아보자. 그러나 이 모든 작업은 정기적으로 사이트의 성능을 확인하고 시간에 따라 차이점을 비교하기 쉽도록 문서화했을 때만 가능하다. + +성능 지표로서의 가치뿐만 아니라 성능 변화의 원인을 파악하기 위해서라도 문서화는 하는 것이 좋다. 문서화를 하면 어떤 종류의 변화가 사이트의 성능에 큰 영향을 주었고, 어떤 것이 그렇지 않은지 등 시간에 따라 확인할 수 있기 때문이다. + +(스크립트의 사이즈 변화나 파일의 사이즈 변화를 PR에서 체크할 수 있도록 기본적인 셋팅을 해볼 수 있을 것 같다.) + +지속적으로 지켜봐야 할 것이 하나 더 있다. 바로 경쟁 사이트의 로딩 시간이다. 할 수 있다면 경쟁 사이트도 어떻게 동작하는지 지속적으로 테스트하고 벤치마크하자. 이를 통해 그들이 성능을 얼마나 중요하게 생각하고 사이트를 만들 때 어떤 측면의 사용자 경험을 중요하게 여기는지 알 수 있다. diff --git "a/07\354\236\245/7\354\236\245_\354\225\204\353\246\204\353\213\244\354\233\200\352\263\274_\354\204\261\353\212\245_\354\202\254\354\235\264_\353\260\260\354\247\204\354\230\244.md" "b/07\354\236\245/7\354\236\245_\354\225\204\353\246\204\353\213\244\354\233\200\352\263\274_\354\204\261\353\212\245_\354\202\254\354\235\264_\353\260\260\354\247\204\354\230\244.md" new file mode 100644 index 0000000..c8d9e6d --- /dev/null +++ "b/07\354\236\245/7\354\236\245_\354\225\204\353\246\204\353\213\244\354\233\200\352\263\274_\354\204\261\353\212\245_\354\202\254\354\235\264_\353\260\260\354\247\204\354\230\244.md" @@ -0,0 +1,64 @@ +--- +title: 7장 아름다움과 성능 사이 +--- + +사이트 전체 사용자 경험은 룩앤필, 접근성, 정보 아키택처, 사용성을 비롯한 많은 요소에 의해 좌우된다. 그 중 성능은 사이트 전체에 영향을 주는 요소 중 하나일 뿐이다. + +성능을 개선하는 것은 모바일처럼 제한된 대역폭을 통해 접속하는 사용자의 접근성을 높이고 사용자가 사이트에 더 우호적인 느낌을 가지는데 도움이 된다. 그러나 성능에만 집중하면 사용자 경험의 다른 부분을 개선하는데 쓸 개발 비용이 상대적으로 줄어들 것이다. + +아름다음과 성능 사이에서 적절한 균형을 찾아야 한다. + +## 균형 찾기 + +성능을 개선하는 작업에는 어려운 결정을 내리는 작업이 필수적으로 동반된다. 웹이 어떻게 동작하는지, JPEG의 압축 원리가 무엇인지, 웹 폰트가 페이지 성능에 어떤 영향을 미치는지 이해한다면 성능 개선을 위한 결정에 도움이 될 것이다. + +- 성능을 가늠할 때 + - 얼마나 많은 요청 횟수를 추가하거나 제거할 것인가 + - 페이지 크기를 얼마나 늘리거나 줄일 것인가 + - 체감 성능에 어떤 영향을 줄 것인가 +- 아름다움을 가늠할 때 + - 사이트 이미지에 어떤 양향을 미칠 것인가 + - 기존의 재사용을 위한 디자인 패턴에 어떤 영향을 미칠 것인가 + - 전반적인 사용자 경험에 어떤 영향을 미칠 것인가 +- 예산이나 시간 같은 비용을 가늠할 떄 + - 이 해결책은 얼마나 쉽게 유지보수할 수 있는가? 사이트의 코드를 깨끗하게 만드는가 + - 함께 일하는 팀이 보유한 기술이 해결책을 적용하는데 도움이 되는가? + - 얼마나 많은 시간이 걸리는가 + - 이 기법을 배우는 것이 팀에 도움이 되는가? 다른 프로젝트에도 활용할 수 있는가? + +때로는 상반되기까지 한 많은 요소들을 가늠하고 적절한 균형점을 찾는 것은 매우 어려운 일이다. + +## 성능 작업을 워크플로의 일부로 만들기 + +성능 작업의 운영 비용을 최소화하는 한 가지 방법은 성능 벤치마크를 위한 도구와 절차를 개발하여 일일 워크플로에 통합하는 것이다. + +- 사이트에 새로운 이미지를 추가할 때 자동으로 이미지 압축하기 +- 화면의 크기나 해상도 등의 기준에 따라 이미지의 크기를 자동으로 조정해주는 서비스를 이용하거나 기존에 만들었던 이미지를 재사용하여 다양한 화면 크기를 지원하기 위한 이미지를 직접 만들지 않기 +- 스타일 가이드를 복사해 붙여넣을 수 있는 디자인 패턴을 만들어 쉽게 재사용할 수 있도록 문서화하기 +- 브라우저의 플러그인을 이용하여 페이지 크기와 중요 경로 검사하기 + +장기적인 계획에도 성능은 항상 고려 대상에 포함해야 한다. 프로젝트 주기에 따라 성능을 지속적으로 개선하고 변화를 벤치마크해 두면 나중에 성능 개선 작업을 할 때 비용을 줄일 수 있다. + +시간이 가면서 사이트에 접속하는 사용자의 환경이 개선되고 브라우저들도 최신 버전으로 업데이트되므로 특정 브라우저에 한정된 스타일시트나 편법, 오래된 기법들은 정기적으로 찾아 정리해야 한다. + +이런 작업들이 시간이 지남에 따라 성능 개선 작업을 위한 비용을 최소화해주고 아름다움과 성능의 균형을 맞추기 위해 선택할 수 있는 옵션의 폭을 넓혀준다. + +## 성능 예산을 이용해 새로운 디자인 시도하기 + +성능 예산을 미리 정해 두면 어떤 곳에서 성능 저하를 감수하고 기능이나 그래픽을 추가했더라도 다른 곳에서 이를 만회할 수 있다. 어떤 때에는 아름다움을, 다른 때에는 성능을 선택할 수 있다. 그러면 항상 페이지 속도를 우선할 필요가 없다. + +성능 목표를 결정하기 위해 경쟁 사이트의 분석이 필요할 수도 있다. 경쟁 사이트가 어떻게 동작하는지 확인하고 여러분이 만들 사이트의 성능 예산이 경쟁 사이트보다 적은지 확인하자. + +혹은 산업 표준을 성능 예산의 기준으로 쓸 수도 있다. 대다수 사람들이 보통 2초 안에 페이지가 로딩되면 속도가 빠르다고 느끼므로 이를 페이지 로딩 시간의 목표로 잡을 수 있다. + +사이트의 성능이 나아졌거나 산업 표준이 변경될 때마다 성능 예산을 가지고 측정을 반복해야 한다. 이런 과정을 통해 스스로와 여러분의 팀에게 더 나은 사이트를 만들도록 지속적인 자극을 주자. + +성과 목표 대부분은 항상 측정 가능해야 한다. 달성할 수치와 측정에 사용할 도구를 상세하게 정하고, 누가 무엇을 측정할지도 모두 정한다. + +## 성능을 염두에 두며 디자인 실험하기 + +우리가 내린 결정의 결과를 측정하여 결정이 옳았는지 알아보자. 개발자와 디자이너들은 사용자가 어떻게 느낄지 측정해보지도 않고 사용자 경험에 가장 좋은 것이 무엇인지 이미 알고 있다는 듯이 결론을 내리는 경우가 많다. + +A/B 테스트를 진행하기 위해서는 사용자를 두 그룹으로 나눈 후 두 가지 버전의 페이지를 동시에 서버에 올려둔다. 두 그룹의 사용자들이 두 가지 버전의 사이트를 각각 어떻게 이용하는지 측정하면 아름다움과 성능 사이에서 내린 결정이 전반적인 사용자 경험에 어떤 영향을 미치는지 알 수 있다. A/B 테스트를 하기 위한 자세한 방안은 [이 글](https://alistapart.com/article/a-primer-on-a-b-testing/)을 참고하자 + +개발자는 성능 개선만을 위한 사람이 아니며, 마찬가지로 디자이너도 아름답게 만드는 일만 하는 사람이 아니다. 팀은 최고의 사용자 경험이라는 공통의 목표를 가질 수 있다. 그러므로 아름다움과 성능 사이에서 결정을 내리기 위해서는 어떤 것이 사용자에게 좋을지 고민하는 것이 유리하다. **여러분이 보낸 하루의 결과는 뛰어난 사용자 경험을 가진 사이트를 만드는 것이어야 한다.** diff --git "a/08\354\236\245/8\354\236\245_\354\241\260\354\247\201_\353\254\270\355\231\224_\353\260\224\352\276\270\352\270\260_\353\260\260\354\247\204\354\230\244.md" "b/08\354\236\245/8\354\236\245_\354\241\260\354\247\201_\353\254\270\355\231\224_\353\260\224\352\276\270\352\270\260_\353\260\260\354\247\204\354\230\244.md" new file mode 100644 index 0000000..c3dfdfb --- /dev/null +++ "b/08\354\236\245/8\354\236\245_\354\241\260\354\247\201_\353\254\270\355\231\224_\353\260\224\352\276\270\352\270\260_\353\260\260\354\247\204\354\230\244.md" @@ -0,0 +1,96 @@ +--- +title: 8장 조직 문화 바꾸기 +--- + +눈부신 성능을 가진 사이트를 만들고 유지해 가는 데 가장 큰 장애물은 다름 아닌 조직의 문화다. 조직의 구성원 모두가 성능이 사용자 경험에 미치는 영향을 가치 있게 생각하는 성능 중심 문화를 가지고 있는 곳이 매우 드물다. 해당 업무를 자발적으로 하거나 가끔은 성능 향상을 위한 인프라팀을 구성하여 전담하기도 한다. 하지만 **소수의 사람들이 성능에 대한 책임을 지고 있는 구조에서는** 새로운 사람들이 합류하면 **성능을 안정적으로 제어하는 것이 점점 불가능해진다.** + +
+ +## 성능 경찰과 성능 문지기 + +조직에서 성능 향상은 한 사람의 목소리에서 시작되는 경우가 많다. 이렇게 성능 경찰이나 문지기를 자처하는 사람은 보통 개인이다. 그런 사람들은 보통 다른 디자이너나 개발자의 작업이 끝난 후에도 반복적으로 정리를 수행한다. 떄로는 스스로가 정리를 도맡기도 하고 업무로 할당받는 경우도 있다. 어떻게 일을 맡았든 간에 이런 식으로 한 사람이 일을 처리하다가는 지쳐 쓰러질 것이다. 누가봐도 안정적이라 생각되는 사이트조차도 **시간이 갈수록** 성능 개선을 어렵게 만드는 요인이 늘어난다. + +- picture처럼 그림 파일의 새로운 성능 기법 등장 +- 사이트에 사용되는 하드웨어, 콘셉트, 코드의 노후화 +- 새로운 디자이너와 개발자 합류 +- 성능 개선을 고려하는 습관을 가진 기존 구성원의 이탕 +- 브라우저의 지속적인 발전 +- HTTP/2처럼 기존의 성능 제약을 개선하는 웹 표준 공개 + +이런 변화들을 추척하는 책임을 가진 전담팀을 운영하는 것이 중요하다. 웹이 변화할수록 회사가 의지하게 될 최고의 동료이자 도구가 될 것이다. 단, 이 팀에만 높은 성능을 가진 사이트를 만드는 책임을 지워서는 안된다. 사이트에 관련된 모든 사람이 성능의 중요성을 받아들이고 성능을 개선하기 위해 무엇을 할 수 있는지 이해하고 있어야 한다. 성능 전담팀은 다음에 집중할 수 있어야 한다. + +- 구성원의 성능 개선 교육을 위한 강의, 미팅, 워크숍 진행하기 +- 사이트 속도를 개선한 다른 팀의 디자이너나 개발자 축하하기 +- 구성원 개개인의 작업이 성능에 직접적으로 미치는 영향을 쉽게 이해할 수 있도록 워크플로에 성능 데이터 표식 도구 만들기 +- 새로운 프로젝트의 성능 예산, 사이트 내 최대 페이지 로딩 시간 등 성능을 위한 기본 요구사항 정의하기 +- 신기술과 성능을 개선하기 위한 새로운 방법 공부하기 +- 사이트 성능의 변화와 최근 실험 결과, 학습 내용을 공개 토론하기 + +성능 팀은 사이트의 현재 성능이 어떤지 전체적인 시각에서 살펴봐야 한다. 문제 영역을 유심히 지켜보고, 개선할 영역을 찾고 사이트 디자인과 개발에 관여하는 사람들에게 제안을 해야 한다. 그러나 실제로 성능을 개선하고 유지하기 위해 **실천하는 것은 조직 전체**가 공유하고 함께 짊어져야 제대로 수행될 수 있다. + +
+ +## 상향식 관리 + +다른 문제들과 비교할 때 페이지 속도는 형태가 불분명하기 때문에 상대적으로 그 중요성을 간과하기 쉽다. 페이지의 속도 자체를 구치화하는 것은 쉽지만 페이지 속도로 인해 발생하는 성능 문제는 수치보다 체감의 문제인 경우가 많기 때문이다. 따라서 다른 사람들을 설득하는 것이 생각보다 어렵다. + +성능의 중요성을 경영진들에게 강조하기 위해 비즈니스 지표와 최종 사용자 경험을 시각적으로 보여주는 것에 집중하자. 가장 중요한 시각적 요소는 숫자이다. 유료 사용자 전환 비율, 총 수익, 재방문 비율에 영향을 주는 숫자들을 중점적으로 알리자. 최종 사용자의 입장에서 사이트가 느리다는 것을 직접 느낄 수 있도록 노력하자. + +
+ +### 비즈니스 지표에 미치는 영향 + +인터넷 환경에서 성능이 비즈니스 지표에 영향을 미친다는 것을 보여주는 연구는 이미 많다. + +- 아카마이는 사이트 멈춤, 에러, 긴 로딩 시간이나 복잡한 결제 과정을 경험한 온라인 구매자의 75%가 그 사이트에서 구매하지 않는다고 보고했다. +- 고메즈에서 온라인 구매자의 행동을 연구한 결과, 사이트에서 나쁜 경험을 한 사용자의 88%는 사이트를 재방문할 가능성이 낮다고 발표했다. 같은 연구에서 사이트의 트래픽이 몰리는 시간대에는 75%의 온라인 구매자가 느린 사이트로 인해 고통받기보다는 경쟁 사이트로 이동하는 것도 발견되었다. +- 느린 사이트를 경험한 사용자가 해당 사이트를 재검색하는 비율이 감소한다는 구글의 연구에서 알 수 있듯이 사용자는 빠른 사이트를 재방문하는 경향이 있다. +- 구글의 광고 서비스를 개발하고 제공하는 더블클릭이 클라이언트 재전송 단계를 하나 줄이자 모바일 기기 사용자의 광고 진입률이 12% 증가했다. + +경영진이 어떤 숫자에 관심이 있는지 확인하고 그 내용과 연관이 있는 성능 연구들을 찾아 공유하자. 듣는 사람이 공감할 수 있는 실질적인 지표들과 엮자. 비즈니스 지표와 성능 개선의 상관관계를 확인하기 위한 테스트는 가능하다면 자신의 사이트에서 직접 확인하자. (의도적으로 성능을 저하하는 테스트는 ㄴㄴ...) + +눈에 띄는 개선을 만들어 지표에 미치는 영향을 측정하다. 가능하면 A/B 테스트를 실행하자. **수익과 관련된 지표**(유료 사용자 전환 비율)에 가시적인 영향을 줄 수 있다면 가장 좋다. 어렵다면 이탈률이나 방문자당 페이지뷰와 같은 연관 지표에 초점을 맞추어 결과를 수집하도록 한다. + +성능 개선을 적용할 때는 이에 소요되는 시간도 측정해야 한다. 디자인과 개발 시간도 비즈니스 측면에서는 비용에 해당한다. 비즈니스 측면에서 **가장 빠르게 적용할 수 있으면서** 동시에 긍정적인 영향이 가장 큰 개선 사항을 찾아서 많은 비용을 지불하지 않고도 사용자 경험을 개선할 수 있다는 점을 강조하자. + +
+ +### 사이트 속도 체감하기 + +사용자가 느끼는 것을 경영진이 직접 느끼도록 하는 것이 중요하다. 조직 내 사람들은 빠른 인터넷과 최신 하드웨어를 통해 사이트를 접속하고 있으므로 타 지역에서, 그리고 느린 기기에서 접속하는 사용자들이 사이트를 어떻게 느끼고 있는지 (웹페이지 테스트를 활용하여) 강조하자. + +대화를 성공적으로 이끌어가기 위한 또 다른 도구는 자존심이다. 경쟁 사이트의 성능을 측정하여 점수를 비교하여 그 사이트보다 뛰어난 점이 있어야 함을 적극적으로 강조하는 것이 좋다. 경쟁 사이트도 우리 사이트를 자신들의 사이트와 비교하거나 어떻게 구축했는지 확인할 수 있다. 이러한 점도 어필하는 것이 좋다. 우리 사이트가 경쟁 사이트를 능가할 수 있도록 하자. + +마지막으로 사이트 로딩이 얼마나 달라졌는지 시각적으로 보여주는 것도 지표만큼이나 큰 도움이 된다. + +사용자 경험에 영향을 미치는 모든 구성원이 사용자가 사이트를 빠르다고 느끼게 만드는 일이 업무에서 가장 중요하며 이를 위해 성능을 우선시해야 한다고 생각하는 것이 필요하다. + +
+ +## 디자이너, 개발자와 일하기 + +성능에 초점을 맞추능 디자이너와 개발자에게 여러모로 도움이 된다. 사이트를 만들기 전부터 코드의 문맥과 재사용성을 고려하면 나중에 디자이너와 개발자의 시간을 많이 아낄 수 있다. + +
+ +### 교육하기 + +성능에 대해서 교육을 해야할 기회가 온다면 다음의 주제들을 가지고 이야기 해보자. + +- 모바일 기기의 성능은 무엇에 의해 좌우되는가 +- 설계 단계에서 사람들은 성능에 어떤 영향을 미치는가 +- 체감 성능을 향상시킬 수 있는 방법은 무엇인가 + +교육은 꾸준히 진행해야 한다. 성능 우선 문화에 익숙하지 않은 신입사원이나 자료를 찾아 볼 수 없을 정도로 바쁜 사람들을 위해서 스터디나 비공식 교육을 통해서 구성원 모두가 성능에 긍정적인 영향을 미칠 수 있는 방법을 정기적으로 공유하자. + +조직에서 **허용 가능한 페이지 로딩 시간의 기준을 만들자.** 페이지 로딩 시간의 허용 범위 값을 정하고 조직 내 모두에게 알리자. 최고의 성능을 보이는 페이지는 무엇인지. 반대로 성능이 최악인 페이지의 로딩 시간도 측정하고, 팀 모두에게 그 페이지를 가능한 한 빠르게 만드는 일에 집중하자고 제안하자. 사람들에게는 따르기 쉬운 가이드라인과 벤치마크가 필요하며 목표와 성취 기준을 명확하게 가이드해야 한다. + +
+ +### 역량 강화 + +사람들이 업무를 진행하면서 **올바른 결정을 주도적으로 내릴 수 있게 하려면** 그들이 현재 수행하고 있는 **작업이 성능에 미치는 영향을 가시적인 성능 데이터를 통해 볼 수 있도록 해야 한다.** 엣시 사이트에는 직원이 사이트에 로그인하면 표시되는 툴바가 있다. 디자이너와 개발자들은 페이지의 툴바를 통해 현재 작업하고 있는 페이지의 정보를 확인할 수 있다. 방문 트래픽 데이터, 이 페이지에서 수행하고 있는 실험 목록, 성능 타이밍 데이터와 서비스 레벨에서 미리 합의한 성능 합의 기준을 초과하는 경우에 대한 경고도 보여준다. + +이러한 방법으로 성능 데이터를 보여주면 디자이너와 개발자에게 성능이 사용자 경험의 일부라는 사실을 지속적으로 상기시키는데 유용하다. + +성능 개선 작업을 게시해 (고객을 위한 성능 작업들을 마치고나면 고객들에게 숫자를 공유) 공개적으로 축하하는 것은 많은 디자이너와 개발자들에게 자극이 된다. 이는 조직 문화의 변화를 이끌어낼 뿐 아니라 성능 개선에 기여하도록 격려하는데 매우 좋은 방법이다.