눈 깜빡할새 엔지니어링

이번에 새로운 Bing을 출시하고 조금 숨통이 트여서, 일을 하면서 언젠가는 하는 일에 대해서 간단히 나열하고 싶었던 소원을 한번 풀어보고자 적어본다.

내가 하는 일에 대한 대화는 항상 이렇게 진행된다: “마이크로소프트 어디에 계세요?” “Bing에 근무합니다.” “검색엔진이요? Bing에서 무슨 일을 하나요?” “퍼포먼스 팀에 있습니다.” 여기서 “퍼포먼스”라는 말은 다양한 작은 조각으로 질문이 이어진다. 예를 들면, “데이타베이스와 같은 백엔드의 퍼포먼스”라던가, “웹페이지의 속도라던가”, “검색 응답속도라던가” 등등. 모두 맞는 말이긴 하지만, 사실 어떤 IT 분야가 되었던 퍼포먼스라는 것은 개별 기술에 대한 것이라기보다는 사용자 경험”UX”의 일부로써 “사용자가 만족할 알맞는 속도의 매직넘버를 향한 엔지니어링”이라는 것이다. 들켰다, 매직넘버란 것은 뻥이다. 사람 – 인간 – 사용자에 있어서 절대적인 숫자는 없다. 기분이 좋으면 한참 기다려줄수도 있고, 성격이 급하면 조금만 늦어도 화를 낼 수 있기에 이를 제어할 수 있는 신의 영역이 아닌 이상 있을 수가 없다. 하지만, 어떤 엔지니어링이 되었던 목표로하는 정량적”Qualitative” 숫자 혹은 대역은 있기 마련이니까 그렇게 둔다.

아무리 기능이 좋고 삐까뻔쩍해도 느리고 답답하면 사용자는 외면한다. 사용자가 외면하는 정도 혹은 집중하는 정도”Engagement”는 요기처럼 이를 나타낼 수 있는 회사마다 업계마다 다른 다양한 측정치”Measurement”를 사용 한다. 퍼포먼스가 느리면 이 측정치가 좋지 않은 결과를 보이고, 사용자는 떠나가버린다는 사실은 상식이다. 그런데, 이 퍼포먼스라는 것이 초 단위가 아니라 밀리(혹은 나노)초”Second”에 따라 달라진다. UX구루의 말로는 0.1초 1초 10초를 이야기하지만, 웹/검색 업계에서는 요즘 2초를 기준으로 하기도 하고, 경쟁 사이트보다 250밀리초 이상 느리면 사용자가 떠난다고도 하고, 구글에서 400밀리초 느린 것이 0.44% 검색량 감소로 이어진다하고, 찾아보면 이런 이야기는 쏟아지고 논문도 많다. 아무튼 각설하면, Engagement를 기준으로 매직넘버 비스무리한 부분을 찾아서 이를 지키고 향상하는 것이 기본이라는 이야기다.

그래서, 우리 퍼포먼스팀의 업무는 여기서부터 출발한다.

• 측정해야하는 대상을 설계하고(데이타는 다양한 곳에서 온다, 어느 부분이 어느 정도이어야하는가는 상대적인 것이기에 설계가 중요하다)
• 계측”Instrumentation”을 하고(설계에 맞춰 직접 구현)
• 이를 통해 측량”Measurement”하고(필요에 의해 설계된 측정치들을 보고)
• 이를 교정”Calibration”/확인”Validation”하고(측정치가 올바른지, 계측 오차/마진이 얼마나 큰지, 신뢰도가 어느정도인지등을 점검)
• 결과에 따라 오류”Bug”를 수정”Fix”한다(잘못된 계측, 너무 큰 계측오버헤드, 코드 버그등등 해결)

이 사이클에 의해서 수집된 “Big Data” 측정치들은 요즘 “Data Science“라고 부르는 것과 비스무리한 분석”Analytics”의 도마에 오르고, 요기서 나열한 다양한 기법들을 통해 분석한다. 이 못생긴 형태의 수백수천억의 데이타를 보는 사람들이 알아먹을 수 있는 형태로 가공하여:

• 현재의 퍼포먼스와 추이를 보여주는데,
• 높은 분들 비즈니스 결정하는데,
• 다른 팀들의 새 기능 퍼포먼스를 제시하는데,
• 퍼포먼스 문제를 찾고 새로운 아이디어롤 만드는데,
• 퍼포먼스와 다른 데이타들과의 상관관계를 분석하는데,
• 그리고, 퍼포먼스 문제를 다양한 사람들에게 이해시키는데,

등등에 사용할 수 있게 데이타를 쓰다듬어준다. 위의 가공된 데이타 혹은  다양한 실험/도구를 통해 분석 결과 퍼포먼스 문제를 발견하면:

• 이를 진단”Diagnose”하고(어디의 – 코드? 네트웍? 외부영향?등등 -이 문제인가를 찾아내고)
• 어떤 기능상 오류라면 이를 디버깅”Debug”하고(무엇이 문제인가를 찾아내고)
• 오류를 해당 팀에 알리거나 고친다(Bing전체와 협력업체들 모두와 코디네이션)
• 다음을 위해 진단 방법을 향상할 기술적 방법을 찾는 것도 중요하다.

또한 다양한 분석 결과를 통해:

• 새로운 아이디어나 문제점을 해결할 방법을 찾고
• 퍼포먼스를 향상 혹은 문제를 고칠 기능이나 방법을 개발하고(설계-구현-테스트)
• 실제 퍼포먼스 향상을 분석하고(AB테스트나 새로운 계측/측정을 통해서 데이타 수집)
• 분석 결과에 따라 개량”Refine”하고(이론과 현실은 괴리가 있다)
• 문제가 없다면 이를 배포”Deploy”한다.

많은 다른 팀들 모두가 퍼포먼스 전문가가 아니기에 그들의 결과물을:

• 지속적으로 전체 퍼포먼스에 문제가 있는지를 살피고”Monitor”
• 문제가 되는 기능/팀을 찾아서 알리고”Notify”
• 모범기준”Best Practice”를(구글의 예) 모든 팀들이 따르는지를 다양한 방법으로 체크해야하고(물론 팀 자체에서 교육도 많이 한다.)
• 지키지 않을 경우 이해시키고 고치는데 가이드를 제시하고
• 고치고 난 뒤에 배포후에 문제가 없는지도 점검해야하며,
• 문제가 다시 일어나지 않도록”Regress”, 자동화”Automate”하고 발생할때 알릴”Alert” 수 있게 만들어야한다.

위의 다양한 업무를 위한 도구들을 자체적으로 만들어야하는 것 자체도 업무이고, 다른 팀들의 퍼포먼스를 컨설팅하는 것도 업무다. 규모 문제의 밸런스도 중요하다. 매주 새로운 기능이 나가는 현실에서 이 모든 것을 지속적으로 할 수 있도록 하는 것이다.

이런 업무들은 모두가 그 눈 깜빡할새의 밀리초를 향상하고 지키기 위해서 이뤄진다는 것을 생각하면 재미있다. 몇달을 일해서 십몇밀리초를 향상하고 좋아하는 모습을 생각해보면 어쩌면 관련 없는 사람들에게는 웃긴 일일 것이다. 하지만, 이 눈깜빡할새에 이뤄지는 일들이 모두 퍼포먼스를 향상할 수 있는 대상인데, 그새에 얼마나 많은 과정을 거치는지를 들여다보면 왜 그리 복잡한지를 이해하는 단초가 될 수 있지싶다. 퍼포먼스팀의 대상은 사용자와 사용자가 원하는 정보 소스 사이의 모든 곳을 대상으로한다, 떠오르는 것들만 예로 들면:

• 사용자 – 기능으로 인한 사용자의 행위가 퍼포먼스에 해가 될 수 있다. 요즘에는 페이지가 뜨는 속도가 아니라 사용자가 눈으로 확인하고 행위를 하는 것을 대상으로 퍼포먼스를 바라보는 방향으로 가고 있다.
• 브라우저 – 브라우저의 속도 뿐만 아니라 만든 페이지가 브라우저에서 CPU를 어떻게 사용하는지 밀리초단위로 들여다봐야한다.
• 웹 Best Practice – HTML/CSS 혹은 JavaScript등에 문제가 있는지 봐야한다. 새로운 표준을 적용하면 이도 들여다봐야한다.
• 다양한 웹 리소스 – 이미지, 비디오, 혹은 다른 리소스 모두 다르게 최적화한다.
• 프로토콜과 각 구현 – Name resolution이나 HTTP나 TCP/IP 패킷단위의 문제점들도 제어가 가능한한 분석한다.
• 네트웍 토폴로지, 지오로케등 – 어떤 데이터센터에서 어떤 일이 있었는지, 어떤 병목이 있어서 어떻게 해결해야하는지, 어떤 사용자가 어디서 어떻게 오는지도 중요한 요소이고 이에 맞춰 향상해야한다.
• 웹서버 – 서버코드에 병목이 있다면, 이를 핫픽스 같은 것으로 해결해야한다.
• 웹서버 커튼 뒤 – 하면 안될 이야기들이 많기에 한 항목으로 뭉쳐놨지만, 백엔드에 사용되는 다양한 기술들에 퍼포먼스 문제가 없는지, 향상할 부분이 없는지를 봐야한다.
• 혹은 몇가지 복합적인 문제일수도 있다.
• 이외에도 거시적인 퍼포먼스도 당연히 중요하다.

이 각각의 대상을 두고, 그위에 나열한 다양한 과정을 거치는 것이다. 이게 퍼포먼스 팀이 하는 일이다(적어도 내가 관련한 부분). 이해가 가든 안가든.^^

퍼포먼스라는 것이 안정성이라든지, 국제화라든지, 혹은 보안처럼 수직 기능이 아니라 수평”Horizontal” 요소이기 때문에 각 팀들이 물론 알아서 반드시 점검해야되는 것이지만, 큰 조직에서는 작은 문제들이 눈덩이처럼 불어나기 때문에 이를 가지가 아닌 나무로 보는 팀이 필요하다. 어떤 회사에서는 V팀(TF팀)을 만들어서 하기도 하지만, 없어질 팀이 아니기에 이를 코디하는 팀은 꼭 필요하다는 생각을 한다. 하지만 수평적인 요소는 항상 정치와 관련이 있기도 하기에 쉽지 않은 것 같다.

이렇게 적고나니 사실 별것 없어 보인다. 뭔가 깊이있는 수직적인 일을 하고 싶었는데, 우연히도 퍼포먼스팀으로 흘러들어가 또다시 가지와 나무를 같이 봐야하는 팀에서 허덕이고 있다. 현재는 아직 작은 팀이기에 팀원들이 모두 특정 영역이 없이 모두 들여다봐야 하는 이유로 정신이 없지만, 앞으로 사람이 늘어나면서 담당 분야가 뚜렷해지면서 좀 더 일다워질 기대를 하고 있다.