Velocity Conference를 다녀와서,
안녕하세요, NTS 접근성팀의 최인숙입니다.
지난 1월 NTS에 입사하고 나서 전반적인 Front-end부분의 성능최적화 부분을 맡아 일해오고 있던 중에 흥미있는 conference에 대해 접하게 되었습니다. 테크 분야의 서적을 출판하는 미국 출판 업체 중 가장 규모가 큰 O'reilly에서 주최하는 Velocity라는 conference였는데요, 내용도 알차고 인지도와 명성이 높은 업체들과 발표자들의 참여로 conference의 진정성과 수준면에서 관련 업계의 전문가들 사이에서 유명한 conference라고 알려져 있었습니다.
그렇게 느끼던 중 사내에서 직원들의 해외 교육, conference등의 참여를 도와주고자 사내협의회를 열고 있다는 사실을 알게 되어 속으로 큰 기대는 하지 않았지만 conference 참석 희망여부를 서식을 통해 제출하였습니다.
결과는 너무나도 감사하게 사원협의회에서 저를 뽑아주셨고, 그래서 3일동안의 의미있는 시간을 보내고 올 수 있었습니다. 먼저 이 글을 통해서 기회를 주신 사원협의회 분들에게 감사드립니다.
개인적으로는 Velocity가 열리는 San Francisco Bay 지역이 제가 11년동안의 미국생활을 마무리 짓고 돌아오기 전 미국에서의 마지막 직장생활을 하던 지역이었기 때문에 이번 conference가 더욱 더 의미가 있었습니다.
그럼 3일동안의 꽉 찬 일정내내 어떤 일들이 있었고 또 무엇을 배우고 돌아왔는지 지금부터 소개해 드리도록 하겠습니다.
1. Velocity Conference 소개
1.1 Velocity 란?
2008년도에 처음 개최된 Velocity는 웹 성능 향상에 위해 고민하고 연구하는 엔지니어, 운영자, 메니저들이 한자리에 모여 현재와 미래의 기술들을 공유할 뿐 아니라 각각의 연구, 작업 활동들을 소개하고 시연하는 세계 최고의 컨퍼런스 입니다. 3일동안의 꽉찬 일정으로 짜여진 이 컨퍼런스는Google, Facebook, Twitter등 전세계 수억명의 사용자들을 보유하고 있는 회사들에서 사용자들의 접속 환경과 접속하는 기기들을 고려하여 어떻게 성능을 향상하고 유지하려고 노력하는지에 대한 방법들을 나누기도 하고, 여러 다른 업계의 고수들이 나와 방법을 직접 workshop등을 통해서 공유하기도 하며, 또한 office hour를 통해 성능 최적화 분야에서 널리 알려진 유명한 엔지니어들을 직접 만나 평소 궁금해 하던 점을 논의 할 수 있는 기회도 주어지며, 성능에 대해 연구하고 관련 제품을 만들고 있는 회사로부터 상품 시연과 정보교환의 기회도 가질 수 있는 유일무이한 이벤트입니다.
웹 서비스를 구축, 설계하고 제공하는 사람들이 한자리에 모여Building a Faster and Stronger Web라는 슬로건을 내걸고 고성능 웹 서비스를 구축하고 배포하기 위한 기술들을 공유하고 기기와 장소, 전송 방식에 상관없이 어느 사용자에게나 성능과 효과면에서 동일한 만족도롤 줄 수 있도록 노력하고 방법을 전파하자는 것이 궁극적인 목적이라고 할 수 있겠습니다.
Yahoo에서 Chief Performance를 맡으셨다가 지금은 Google의 ‘make the web fast’ 팀에서 Head Engineer 로 계시고, YSlow의 개발자이시자 Velocity의 co-chair로 계시는 Steve Souders (http://stevesouders.com/)
Velocity 세션을 들을 수 있는 출입증 : 출입증 오른쪽 아래에 보면 TUE-THU라고 적혀 있는데 이는 화요일부터 목요일까지3일 full-pass를 구입했다는 것을 의미합니다. 일단위로 출입증이 구입할 수도 있습니다. 그 위에 있는 바코드에는 개인 프로필과 연락처등이 담겨 있어 관심 업체의 부스에 가서 스캔을 하면 업체의 담당자로부터 상품에 대한 자세한 내용등을 이메일을 통해 받아보거나 할 수 있도록 제작되었습니다.
1.2 참여업체 (sponsors and exhibitors)
Velocity는 2008년 처음 개최당시 스폰서 업체가 10개 미만으로 그 규모가 크지 않았으나 혁신적인 기술들과 기기들의 다양성으로 인해 웹/모바일 어플리케이션을 접속 할 수 있는 방법이 다양해지고 또 접속하는 사용자가 급속도로 늘어남에 따라 성능의 향상은 비지니스의 성공이다라는 통계가 생길정도로 성능최적화에 대한 관심또한 급속도로 높아져 2013년 Velocity를 스폰하는 업체와 박람회를 참여하는 업체는 60개 이상으로 처음 참여업체의 수와 비교하면 6배 이상으로 그 규모가 크게 성장했으며 일년에 한번 실리콘 벨리에서 개최되던 것이 이제는 개최 장소와 햇수를 늘려 매년 6월 실리콘 벨리를 기점으로 베이징, 뉴욕 런던등 세계 다른 지역에서도 개최되고 있습니다.
2008년 첫번째 Velocity conference 참여업체
2013년 6번째 Velocity conference 참여업체
1.3 장소 : Santa Clara Convention Center, California
실리콘 벨리의 끝자락에 있는 Santa Clara Convention Center는 센프란시스코 국제공항에서 차로 30-40분정도 또 산호세 공항에서는 10분정도의 거리에 위치하고 있고 하얏트, 힐튼과 같이 대규모 호텔들이 인접해 있어 미국내 뿐만 아니라 해외에서 방문하는 참가자들에게 편리한 요건을 갖추고 있습니다.
장소: Santa Clara Convention Center, California
일정: 2013.6.18 ~ 6.20 (3일간)
3일동안 꽉찬 일정으로 이루어진 Velocity는 오전 coffee time을 시작으로 9시부터 6시까지 세션들과 tutorial, workshop등으로 짜여져 있고 exhibit hall에서는 관련업체들의 홍보 시연회가 계속해서 이루어집니다. 또한 6시 세션들이 끝이나면 cocktail과 저녁을 같이 하면서 엔지니어들과 social networking을 할수 있는 poolside party, reception등이 매일 저녁 제공됩니다. Conference의 전반적인 분위기는 아래 사진과 같습니다.
세션 전체 강의
세션 주제 별 강의
박람회에 참여중인 사람들
디너 리셉션 풍경
자세한 사진들은 아래 링크에서 확인 하실 수 있습니다.
http://www.flickr.com/photos/oreillyconf/sets/72157634209656690/
2. Velocity의 주제
Velocity의 주제는 크게 4가지로 분류할 수 있으며 주제별 강의, 토론, workshop, tutorial 내용들을 요약해 보면 다음과 같습니다.
2.1 Web Performance
▷ Performance measuring tools and mechanism :
업체, 기업들에서 성능최적화를 위해 실제로 사용하고 있는 성능 측정도구, 방법, 또한 성능측정/최적화가 web development cycle에 어디에 위치하며, 실시간 모니터링을 위해 어떤 기술들을 사용하는가?
▷ Web architecture optimization (HTTP, TCP, TLS, IP, DNS, CDN...) :
웹 서비스를 구축함에 있어 적절한 component의 선택은 서비스의 Scalability(확장성)뿐만 아니라 성능에도 크게 영향을 주게 됩니다. 각각의 component가 성능에는 어떤 영향을 주는지에 대한 토론, 발표.
▷ Image optimization, CSS preprocessors:
이미지와 스타일링은 front-end성능 최적화에 핵심이 되는 요소라고 할 수 있습니다. 단순히 어떤 image format를 써야 하는지의 문제부터 어떤 방법으로 서로 다른 접속 환경(network connections, devices..)에서의 request에 대응할 것인가, 또한 사용자의 만족도를 높힐 수 있다는 *progressive JPEG의 사용이 적절한 환경과 이미지느 어떤 것들이 있는지에 대한 발표내용들.
▷ RUM, RUM, RUM:
RUM이라는 주제가 세션, workshop, 박람회의 주를 이루는 내용이었으며 사용자의 실질적인 데이타가 얼마나 중요한지 Conference 3일동안 꾸준하게 언급이 되었습니다.
▷ Synthetic test vs. RUM (Real User Monitoring/Measurement):
성능 최적화에 있어서 성능 측정은 뼈대라고 할 수 있습니다. 성능측정에 있어서 simulator등을 이용하여 측정하는 synthetic test와 실제 사용자의 활동에서 부터 데이타를 얻어서 실제 사용자들의 사용 환경과 사용 패턴을 관찰하는 Real User Monitoring방식은 어떤 차이점이 있으며 각각의 결과를 어떻게 사용하는것이 좋은지에 대한 내용들. .
2.2 JavaScript:
▷ "JavaScript is an ever-growing component within web services". Jquery와 prototype을 시작으로 JavaScript framework은 지금 전성기를 맞이하고 있다고 해도 과언이 아닙니다. 어떤 framework들이 어떻게 쓰이고 있으며 또한 적절한 framework을 이용해서 성능 최적화에 어떻게 도움이 되었는지 실제 사례를 발표하기도 했으며 JavaScript의 오남용 사례들을 나누기도 했습니다.
2.3 Mobile Performance
▷ Mobile performance challenges:
Mobile환경에서 성능최적화를 하는데 있어서 일반적인 browser에서 사용하는 것과 어떤 다른 점이 있으며, 또 어떤 어려운 점이 있는지, 그 기술적인 장애요소와 또 그것을 극복하기 위한 방법은 어떤 것이 있을까???
▷ Differences within mobile environment (3G, 4G, LTE): LTE will be our savior??? Network 공급자들이 흔히 말하는 속도의 개념과 또 실제 사용자들이 느끼는 속도의 차이점은 많이 다르죠? 과연 Network 환경은 어느정도 성능 최적화에 도움을 주며 또 각각의 다른 network환경에서 중점을 두어야 할 성능 최적화는 어떤 것이 있는지에 대한 고민과 토론, 발표.
▷ Mobile web vs. app: Mobile web을 개발하는데 있어 native app처럼 사용성의 만족감(예를 들어 UI움직임이나 touch event의 반응)을 줄 수 있는 방법은 어떤것이 있는지에 대한 발표와 web과 app의 성능 측정 방식등을 나누는 시간들.
2.4 Operations and more
▷ Load Balancing
▷ Scalable architecture
▷ Cloud Services
▷ HTTP 2.0: what's next? Do we all need to do what we're doing now?? HTTP 1.1에서 파생된 지금의 최적화 어떻게 변화해야 할까???
2.5 Talking in the hallway
(그밖에 사람들과 나누었던 내용들, 다른 엔지니어들의 관심사는??)
▷ Performance on Mobile: Challenging
▷ Website내의 광고나 marketing의 용도로 쓰이는 third-party contents: performance bottle neck!!
▷ images: too many of them in one page, too often poorly optimized (실제로 한 대기업의 성능진단을 하던 중 2MB짜리 이미지가 올라와 있던 걸 본적이 있습니다. 굉장히 용감한 디자이너/개발자라고 생각을 했었죠)
▷ Cache: 적절하게 잘 적용하고 있는가??? 이미지와 같이 제대로 하고 있는 사이트가 많이 없다는 결론입니다.
▷ JavaScript: 불필요하게 많은 Library들을 사용하고 있는 것은 아닌가, 아니면 전혀 필요없는 JavaScript 파일을 그냥 방치하고 있지는 않은가.. 이 모든게 performance에는 악영향을 준다는 얘기들..
▷ Web fonts
전체 Conference의 스케쥴은 아래 링크에서 보실 수 있습니다. 세션 비디오나 tutorial, workshop자료들은 비공개이지만 PDF자료들 중 상당수가 공개가 된 상태라 관심있으신 분들은 다운받아 보실 수 있습니다.
http://velocityconf.com/velocity2013/public/schedule/full/public-grid
3. Highlights from my favorite sessions
3.1 Avoiding Performance Regression at Twitter
Marcel Duran @marcelduran: Performance FE Engineer at Twitter
이 session은 전세계 수억명의 사용자를 보유하고 있고, 새로운 기능과 bug fix들로 release 사이클이 짧은 트위터에서 application의 성능을 어떻게 강화하고 유지 하는지, 또 성능 테스트가 development cycle에서 어떻게 작용하고 있는지 발표하고, 또 성능실험을 위해 새로 개발한peregrine이라는 framework을 소개하는 시간이었습니다.
Application의 특성상 twitter는 사용자들의 접속 빈도수가 높고 동시 접속자 수가 많습니다. 그렇기 때문에 bug fix나 새로운 feature의 개발로 인한 application의 업데이트가 성능에 악영향을 끼쳐서는 절대로 안될 것입니다. 성능저하는 사용자 감소라는 성능최적화의 golden rule을 항상 염두하고 있는 twitter의 성능 강화팀에서는 어떤 노력을 하고 있는지 엿볼 수 있는 시간이었습니다.
▶ Key points
위 세개의 이미지에서 보여지는 것과 같이 보통의 개발 cycle에서 보면 성능저하나 향상에 대한 감지는 release되고 난 후에 모니터링을 통해서 이루어 졌던게 일반적입니다. 그런데 앞서 언급했듯이 사용자의 수가 많은 twitter의 경우 성능이 저하되었을 경우 나타나는 business측면의 손실과 이미지 하락은 우리가 상상하는 그 이상으로 심각할 것입니다. 그래서 twitter에서는 production level의 배포가 이루어지기 전 반복적인 성능 실험을 통해 새로 추가된 feature나 bugfix중에 성능에 악영향을 주는 요소를 골라내 적정수준의 성능을 유지하고 있습니다. 이 과정에서 쓰이는 툴들은 다음과 같습니다.
▶ Tools used
▷ Cuzillion (cuzillion.com)
▷ HAR file (waterfall을 JSON형태로 변환)
▷ PhantomJS + YSlow + Jenkins
▷ Peregrine (open source coming soon)
3.2 Bits on the wire
Mark Notthingham (also chair of HTTPbis Working Group) from Akamai (http://www.mnot.net)
이번 세션은.. 한마디로 얘기하자면 .. 어려운 주제였습니다.
그래도 요약을 해보면, Web구조는 한마디로 말해 어떤 상황에서 연결을 하더라도 멀리 떨어져 있는 bit들을 사용자의 기기로 옮기는 작업이라고 할 수 있습니다. 여러가지 구조와 조합들로 성능과 보안등의 문제들을 해결하려는 노력들이 있어 왔는데요, 이 세션에서는 그 다양한 연결구조와 그 구조들이 성능에 영향을 미치는 요인들은 무엇이며 성능에 도움을 주는 component와 그렇지 않은 component를 설명해주는 시간이었습니다.
▶ Topics covered
▷ TCP optimizations
▷ How DNS works
▷ TLS and SSL
▷ Firewalls, proxies, routers and other middle boxes
▷ Differences on Mobile
▷ 성능에 좋은 영향을 주는 components: Proxies, Gateways
▷ 성능에 나쁜 영향을 주는 components: interception proxies
▷ 성능에 나쁜 영향을 주는 이유: virus scanner, strip accept encoding, block responses, buffer responses, content modification, insert ads, filter content, adapt contents, captive portals...
내용은 어려웠지만 듣는 내내 제 부족함도 깨닫고 또 더 알아야 할 것이 많은 최적화 분야에 대한 학업(?) 의지를 충전할 수 있는 세션이었습니다.
3.3 Speeding up your mobile HTML5 Experience
Maximiliano Firtman (ITMaster Professional Training, http://firt.mobi/)
모바일 개발은 성능 측정과 최적화를 다루는 데 있어서 어려움이 많이 있는 분야입니다. 이 세션은 모바일 플랫폼에서 websites, webapps과 native hybrids 등이 어떻게 다른지 설명하고 또 현재 시장에 존재하는 browser와 플랫폼들은 어떤 것들이 있는지 소개하는 시간이었습니다. 또한HTML5를 이용해서 성능면에서 좋지 않은 평가를 받았었던 facebook app으로부터 배울점은 무엇이 있나 살펴보기도 했습니다
▶ Mobile 개발시 고려해야 할 점
▷ CSS sprite vs. inline images
▷ Application cache
▷ Different view port definitions
▷ JavaScript frameworks usage
▷ Web Storage vs. SQL storage vs. IDB
▷ Large DOM vs. iframe vs. object pool
▷ SVG vs. high resolutions canvas
▷ Mouse vs. touch/pointer events
▷ Animation Timing API
▷ Images vs CSS3 effects and gradients
▶ Tools can be used
▷ Remote inspector tools
▷ Traffic analyzers
▷ Bandwidth simulators (Charles)
▷ The web navigation timing API (limited support)
▷ Profiling tools
3.4 Optimizing the critical rendering path for Mobile
Ilya Grigorik Web performance enginner and Developer Advocate on the "Make the web fast" team at Google
개인적으로 이분은 제가 성능최적화를 공부하고 리서치하면서 Steve Souders만큼이나 많은 영향을 받은 분입니다. 두분이 Google내에서 같은 사무실을 쓰고 계신다고 하네요.
Google I/O나 예전 Velocity같은 conference 비디오 자료들로 강의를 접하다가 직접 뵙게 되니 왠지 더 반가운 느낌이 들었습니다.
이번 세션은 Mobile환경에서 성능 최적화를 생각할때 시간적인 예산이 얼마나 되는가에 대한 설명과 함께 사용자들의 사용패턴에 대한 조사결과를 공유하는 시간이었습니다.
실제로 의미있는 content를 사용자에게 전달하기 전에 발생하는 network overhead는 3G, 4G환경에서 어떻게 다르며 그 overhead를 제외한 시간 내에 얼마나 빠르게 의미있는 content를 전달 할 수 있는지에 대한 방법들이 소개 되었습니다.
또한 사용자 패턴을 연구한 결과에 따르면 사람들은 300ms ~1초 사이에 로딩이 되는 페이지내에서 페이지에 집중하는 정도가 가장 높으며 로딩시간이 1초 이상 지연되어도 순식간에 다른 생각을 하게되어 (예를들어 누구누구한테 전화를 해야한다던지 공과금을 내야 한다던지에 대한 생각) 싸이트에 대한 집중력이 떨어진다고 합니다. 페이지 방문이 매출과 직접적인 영향이 있는 shopping 사이트의 경우 최적화가 얼마나 중요한지 다시 한번 일깨워 주는 시간이기도 했습니다. 10초 이상 지연이 되는 사이트는 사용자가 다시 방문하지 않을 확률이 굉장히 높다는 연구결과도 공유되었습니다.
3.5 Enough with the JavaScript already
Nicholas Zakas (Staff software engineer at BOX)
성능진단을 하다보면 많은 JavaScript로 인해 rendering이 block되는 경우를 종종 볼 수 있습니다.
위의 이미지에서 볼 수 있듯이 HTTPArchive의 자료에 의하면 지난 8개월간 JavaScript의 사이즈와 request의 수가 각각 17%, 20% 증가했다고 합니다. 사용자들이 기능이 풍부하고 사용감이 좋은 사이트(feature-rich, fluid)를 원하지만 그것이 꼭 JavaScript의 사용의 의미하는 것인지, JavaScript의 오용과 남용이 성능에 가지고 오는 불이익은 얼마나 큰지, 또 그렇기 때문에 web component 각각의 본연의 목적(아래 이미지 참조)은 무엇인지 다시 한번 되집어 보는 시간을 가졌습니다.
요점은 Don't use JavaScript frameworks just because they are cool!! 
3.6 The curious case of dust JavaScript and performance
Veena Basavaraj (Systems Engineer at LinkedIn)
위의 세션에서는 JavaScript의 오남용에 대한 사례들이 소개가 되었었는데요, 반대로 이 세션에서는 적절한 JavaScript의 사용으로 긍정적인 변화를 경험한 사례를 소개했습니다.
LinkedIn에서는 작년에 design(both look & feel and architecture) 에 대한 대대적인 변화가 있었는데요, 특히 web architecture부분이 어떻게 변화했는지에 대해서 자세히 설명하는 시간을 가졌습니다.
제일 큰 변화라고 하면 Rendering layer에 JSP를 제거하고 dust라는 강력한 template을 도입한 부분인데요, 전세계 15개국에 19개의 다른 언어로 서비스를 제공하고 있으며 한달에 UV(unique visitor)수가 1억 7천명가량 되는 LinkedIn에서 이 template을 도입한 후 눈에 띄는 성능변화는 어떤 것이 있는지도 자세히 공유하는 시간이었습니다.
Key points
▶ LinkedIn 사용자에게 듣는 Web-Experience의 단점들은?
▷ visually boring
▷ lack-of one-click actions
▷ full-page-refresh
▷ dis-engaging
▷ complex navigation flows
▶ 위에 나열된 문제를 해결하고자 할때 고려해야 하는 점(challenges)
▷ No single web-technology
▷ What about mobile?
▷ No sharing UI across pages
▶ LinkedIn에서 찾은 해결책은?
▷ Unify by enabling the web-applications to serve JSON (JSON mapper의 도입) 
▷ 그러나 Brorwser는 HTML을 이해하기 때문에 JSON을 HTML로 변환시켜줄 "something"이 필요하다. 그래서 선택된 것이 바로 Dust.js
▷ 그리고 server쪽에서 Data를 모으는 데 사용된 component는 Fizzy
▶ Design change, dust 도입 전과 후
▷ Visually rich and simplified design
▷ TTFB (time to first byte): 평균 832ms --> 228ms 으로 약 600ms감소하였고 따라서 사용자들이 site와 engage되는 속도가 빠름. 
▷ NOTE: Dust rendering을 도입했을때 IE browser 엔진에서는 오히려 성능저하 현상이 나타나기 때문에 이런 특정 user agent에서 요청이 올 경우 server-side JS 엔진을 사용
4. Lightening Demo
이번 conference는 참가자들이 세션을 듣는 것 뿐만 아니라 직접 고수들에게 배울 수 있는 workshop, tutorial과 많은 demo시연들로 이루어졌습니다.
그중에서도 재미있고 유용했던 Demo시연 하나를 공유하도록 하겠습니다.
4.1 HTTPArchive + BigQuery
성능 최적화쪽에서 일하시는 분이라면 HTTPArchive에 대해서 잘 알고 계실텐데요, 이 프로젝트는 Steve Souders를 중심으로 Google, Mozilla, O'reilly등의 기업에서의 지원을 받아 운영되고 있습니다. 한달에 두번 300,000개 정도의 website에 대한 성능진단을 실시하여 그 자료를 보관하는 프로젝트로 트렌드 조사나 bench marking을 하는데 유용하게 쓰이는 자료입니다.
네이버 메인 페이지의 자료를 살펴보면 다음과 같습니다. 
BigQuery는 큰 데이타를 다루기에 적합한 infrastructure를 갖추지 않고 Google의 강력한 infrastructure를 이용하여 빠르게 데이타를 process (loading, transforming, visualizing) 할 수 있게 만든 서비스 입니다.
BigQuery를 이용하면 500GB이 넘는 HTTPArchive의 데이터를 SQL과 비슷한 query를 작성하여, HTTPArchive 페이지에서는 볼 수 없는 흥미로운 자료들을 뽑아낼 수 있습니다.
자세한 syntax는 아래 링크를 참조하세요.
https://developers.google.com/bigquery/docs/query-reference
▶ Naver 도메인을 이용하는 service
SELECT pageid, pagespeed, url, renderStart, rank FROM [httparchive:runs.2013_06_15_pages] WHERE REGEXP_MATCH(url, r'.naver') 
▶ Google 도메인을 이용하는 service 
▶ Ranking 1위는
SELECT pageid, pagespeed, url, renderStart, rank FROM [httparchive:runs.2013_06_15_pages] WHERE rank is not null order by rank LIMIT 100
느낀점
Velocity는 이번 참가가 처음이었지만 제가 느끼기에 현재 성능 최적화의 현황과 문제점등을 업계 최고의 기업들을 통해서 듣고, 같은 분야에 종사하는 엔지니어와 운영자 또는 메니저들과 세션 중간중간, 점심 또는 reception시간을 통해 심도 있는 대화를 할 수 있는 최고의 자리가 아니었나 생각합니다. Case study들을 통해 성능에 도움이 되었던 사례 아니면 반대로 오히려 해가 되었던 사례들을 공유하여 Bench marking할 수 있는 좋은 기회를 주며, 미래의 기술은 어떻게 변화할 것인가 또 그 변화에 대해 우리가 알아야 할 기술 상식은 어떤 것들이 있는지를 성능 최적화 분야에서 일하는 가장 똑똑하고 경력이 탄탄한 고수들에게서 직접 들을 수 있는 소중한 기회도 제공합니다.
조금 아쉬웠던 점은 3일동안의 기간동안 한없이 강조되었던 RUM의 활용에 대한 중요성이 아직 우리나라 기업에서는 중요하게 다루어지지 않고 있다는 점이며, 흔히 말하는 인터넷 강국이라는 것은 대한민국내에 인터넷이 어디나 존재하고 스마트 폰이나 인터넷 보급률이 높다는 점에서일 뿐이며 실제 웹서비스의 성능과 기술면에서는 개선되어야 할 점이 많다는 점입니다. 여기저기 나타나는 pop-up 창부터, 보기힘든 layout과 복잡한 navigation flow등등... 국내 유명 사이트에서 보이는 흔한 현상이지만 우리가 자주 즐겨찾는 외국의 사이트에서는 사라져가거나 이미 사라진 이슈입니다. 실제 사용자의 데이터를 수집하고 변화를 시도하는 것이 처음에는 물론 resource의 낭비라고 생각될수 있겠지만 성능 향상이 가져오는 비지니스 측면의 변화를 체험하며 기업들이 사용자의 만족도를 높이기 위해 항상 노력하는것이 진정한 인터넷 강국으로 도약하는 길이 아닐까 생각합니다.
다음에는 성능최적화의 필요성을 좀 더 알리기 위해 conference를 통해 배우고 익힌 흥미로운 이슈들을 자세하게 하나하나 공유하도록 하겠습니다.
감사합니다.