"응답시간 500ms, 적절한 건가요?" | 목표 응답시간 정하는 방법

Video: "응답시간 500ms, 적절한 건가요?" | 목표 응답시간 정하는 방법
Channel: 코딩하는기술사
Duration: 17m 35s
Source: subtitle (auto, ko)
Transcript:
안녕하세요. 지난 시간에이 품질 목표를 세우는 법에 대해서 말씀을 드렸는데요.이 성능 목표를 정할 때 단순히 빠르게가 아니라 검증 가능하도록 이렇게 수치로 목표를 세워야 한다고 했습니다. 그런데이 목표값을 어떻게 정해야 될까요?이 목표값은 시스템마다이 서비스의 성격마다 다르겠죠. 여러분들은 지금 운영하고 있는 시스템의 목표 응답값을 어떻게 정하고 계신가요?이 영상에 이런 댓글도 달렸더라고요. 정성이 아닌 정량적 목표 제시를 하기 위해서는 결국 개발 감각이 중요하다는 걸 알게 되는 것 같습니다. 예를 들어서 응답 시간이 0.5초 5초 이하가 통상적으로 적절한 수치인지 더 느리거나 더 빠른 기준을 제시해도 되는지 메모리 부하가 있는 상태에서는 또 어디까지 허용을 할지 등 기준 하나를 놓고도 결정에 영향을 주는 요인이 많아 보이네요. 네. 그렇죠. 어, 그래서 오늘은이 목표값을 정하는데 참조할 만한 기준과 어, 접근법에 대해서 간략하게 말씀을 드려 볼까 합니다. 자, 목표 응답 시간 200ms 500ms 1초 어떻게 정할까요?

자, 요구상 회의를 가정해 보겠습니다. 어, 기획에서 응답시 목표는 얼마로 할까요라고 질문을 했습니다. 그러니까 개발자가 어, 1초 정도면 되지 않을까요라고 답변을 했습니다. 그런데 다른 개발자는 어, 다른 곳은 500ms 정도 되는 거 같습니다. 자, 그러니까 어, 팀장님이 빠를수록 좋죠라고 얘기를 합니다. 자, 어떻습니까? 빠를수록 좋습니까?이 응답 시간 목표 맨밀리 세컨드로 잡아야 좋을까요? 자,이 응답 시간 목표도 어 참고할 수 있는 기준이 있으면 좋겠죠? 그래서이 기준 두 가지를 말씀드리고 어 우리 시스템의이 목표 응답값을 정하는 방법에 대해서 말씀을 드리겠습니다. 자, 첫 번째 기준입니다. 어, 사람은 얼마나 기다릴 수 있을까? 자, 이건 오래 전부터 연구된 영역입니다.이 사용성 분야에 야곱 닐슨이라는 분이 1960년대부터 이어진 연구들을 세 개의 숫자로 정리를 했습니다. 자, 첫 번째 0.1초입니다. 컴퓨터 시스템이 사용자의 액션 이후에 0.1초 1초 안에 반응을 하면 사용자는이 시스템이 즉각적으로 반응했다고 느낍니다.

예를 들어서 버튼을 클릭했을 때 버튼이 바로 눌린 표시가 나는 것처럼요. 다음으로 1초입니다. 여기까지는 사용자가 약간 기다림을 느끼기는 하지만이 생각의 흐름은 어 끊기지 않는다고 합니다. 보통 우리가 화면을 넘기거나 검색 결과를 기다리는 정도가 여기에 해당 가겠죠. 그리고 10초입니다. 자, 10초는 사용자의 주의를 붙잡아둘 수 있는 한계라고 합니다. 10초를 넘어가면 사용자는 다른 일로 관심을 돌린다고 하네요. 그래서이 사용자 경험상 오래 걸리는 작업에는 항상이 진행 상황을 보여 줘야 되는 거죠. 어, 참고로이 세 개의 수치는 서버의 응답 시간만을 말하는 것은 아닙니다. 사용자가 어떤 액션을 하고 결과를 보기까지 즉이 네트워크 통신 시간과 화면의 어떤 렌더링 시간까지 다 포함한 전체 시간입니다. 자, 이게 올해 전에 연구된 결과이지만이 수치를 정리한 릴스는 30년 가까이 거의 바뀌지 않았다고 말합니다. 어 컴퓨터는 빨라졌어도 사람의인지 특성은 그대로니까요. 어 실제로이 뒤에서 볼 구글의 기준도이 연구를 근거로 삼고 있습니다.

자 두 번째 기준입니다. 웹사이트라면 구글이 제시한 기준이 있습니다. 구글은이 웹자 경험을 대표하는 지표 세 가지를 정해 두고 코어 웹이틀 핵심 웹 지표라고 부릅니다. 자, 화면이 얼마나 빨리 뜨는지 그리고 클릭에 얼마나 빨리 반응하는지 그리고 화면이 밀리지 않는지 등을 측정합니다.이 구글의 검색 순위에도 반영되는 지표라서 어 웹 개발자라면 한 번쯤은 들어 보셨을 겁니다. 자, 오늘은 그중에서이 응답 시간과 관련된 것만 보겠습니다. 자, INF입니다. 인터액션투 넥스트 페인트. 사용자가 클릭하거나 키를 눌렀을 때 화면이 그의 반응에서 다음 모습으로 바뀌기까지에 걸리는 시간을 말합니다. 자, 구글은 이p를 200m 이하로 하는 것이 좋다. 좋음이라고 구분하고 있습니다. 그리고이 500m세를 넘어서는 것을 나쁨이라고 분류하고 있고요. 어, 앞에서 본이 닐슨의 0.1초 1초 즉시 반응한다고 느끼는 구간.이 구간하고 여기서 말하는이가 같은 성격이죠. 어, 그리고이 수치는이 75번째 100분이 기준입니다. 평균 값이 아니라네 번 중에서 세 번이이 안에 들어와야지 통과한다는 뜻입니다.

자,이 이야기는 뒤에서 다시 하겠습니다. 자, 두 번째 수치는 TTFB입니다. 타임투 퍼스트 바이트이고요. 페이지를 요청하고 응답의 첫 바이트를 받기까지의 시간이고 구글은 대부분의 사이트가 0.8초 8초 이하를 목표로 하라고 안내하고 있습니다. 어 다만 이것은 방금 말씀드린 핵심 지표 세 가지에는 속하지는 않는 것이고요. 구글도 어 반드시 뭐 이것을 맞출 필요는 없고이 핵심 지표를 방해하지 않는 수준에서 관리를 하라고 하고 있습니다. 자 그러면이 구글은 앞서 봤던이 imp밀라는 숫자를 어떻게 정했을까요? 자, 여기에는 두 가지를 같이 봤습니다. 그 첫 번째는 사람의인지 연구입니다. 앞서 보신 것처럼 화면 반응이 약 100m이면 사람은 자기가 한 행동의 결과로 인식한다는 연구가 있었죠. 두 번째는이 수치에 대한 달성 가능성입니다.이 실제 사이트 중에서 최소 10%가이 기준을 통과할 수 있어야 한다고 봤습니다. 자, 아무도 지킬 수 없는 목표 수치는 기준이 될 수 없겠죠. 그래서 연구상 이상적인 값은 100ms였지만 현실까지 함께 고려해서 구글에서는 200m세로 정한 것이죠.

좋은 목표는 사용자에게 의비가 있고 그리고 또 우리 시스템이 현실적으로 달성 가능한 숫자야 된다는 맥락입니다. 자, 이제 우리 시스템의이 목표값을 어떻게 정해야 될지이 접금 방법론을 말씀드리겠습니다. 자, 첫 번째 사용자 기대입니다.이 구글 SR 문서에서는 이런 말이 있습니다. 측정하기 쉬운 것이 아니라 사용자가 중요하게 여기는 것에서 출발하라. 자, 우리가 흔히 하는 실수가 우리 모니터링 화면에 CPU 사용량이랑 평균 응답 시간이 이미 있으니까 그것을 목표로 잡는 거죠. 어, 그런데 사용자는 CPU 사용률에는 관심이 없습니다. 사용자는 내가 주문 버튼을 눌렀을 때 결과가 얼마나 빨리 나오는지에 관심이 있죠. 그러니까 우리가 먼저 질문해야 할 것은이 기능에서 사용자가 기다릴 수 있는 시간은 얼마인가? 이것부터 생각을 해야 되는 거죠. 자, 그리고 나서 두 번째 공신력 있는 기준 값을 참고합니다. 어, 방금 전에 본 것들이죠. 사람이 느끼는 0.1초 그리고 1초, 10초이 세 가지 값이 있었죠. 그리고 웹사이트라면 구글에 IMP 200m.

자, 감으로 정하는게 아니라 이런 근거에서 출발을 하는 것입니다. 자, 다음으로 세 번째. 그리고 현재 우리 시스템의 성능을 파악합니다. 지금 우리 시스템이 얼마나 걸리는지 측정을 해 보는 것이죠. 어,이 목표가 현실적인지 그리고 얼마나 개선해야 하는지 파악하는 과정입니다. 다만 여기서 조심해야 할게 있습니다. 현재 우리 시스템의이 P95 값이 600m로 나와 있다면 목표값을 600m로 하자. 어, 이건 아닙니다. 그러면 지금 시스템의 한계를 그대로 요구상항으로 굳혀 버리는 거죠. 현재 성능은 출발점이지 목표가 아닙니다. 자, 다음으로네 번째. 어떻게 보면 제일 중요한 기준이 될 수 있습니다. 자, 비용과 가치를 따져야 되죠. 늘 말씀드렸듯이 아키텍처 결정에는 트레이드 오프가 있죠. 구글 클라우드 문서에서도 이렇게 말하고 있습니다. 사용자가 300ms와 500ms의 차이를 구분하지 못한다면 더 높은 값인 500mms를 목표로 쓰라는 것입니다. 성능의 목표값이 낮을수록 비용이 많이 들고 그러나 사용자는 그 차이를 그 비용만큼 느끼지 못할 수도 있으니깐요.

어 결국 무조건 빠를수록 좋다는 건 아니라는 말이죠. 필요한만큼 빠르게 만드는게 핵심입니다. 자, 그런데이 P50, P95 이런게 무슨 말일까요? 자, 이것은이 요청을 응답 시간 순으로 줄을 세웠을 때 빠른 것부터 느린 것까지 줄을 세웠을 때이 P95라는 것은 앞에서 95% 지점에 있는 요청. 그 요청의 응답 시간이 P95입니다. 자, 예를 들어서 P95가 500ms이다. 자, 이것은 요청이 100개라면 그 100개 중에서 95건은 500ms 안에 응답을 했다는 뜻입니다. 그리고 나머지 다섯 거는이 500ms보다는 더 많이 걸렸을 수 있다는 것이고요. 어,이 값이 얼마나 늘린지는 알 수는 없겠죠. 자, 밑에이 표를 보겠습니다. 자, 첫 번째 P50은 말 그대로 중앙 값이죠. 줄을 세웠을 때 정 중간에 있는 값입니다. 자, 구글 SR 문서에서는 이것을 전형적인 경우를 보여주는 값이라고 말하고 있습니다. 평소 우리 서비스가이 정도로 응답한다. 그 감각을 주는 값인 거죠. 다만 이것은 목표값으로는 쓰지 않습니다. 왜냐하면이 값을 목표로 잡으면 나머지 절반은 얼마나 느려도 상관없다는 말이 되니깐요.

자, 그런데이 값을 그러면 왜 볼까요? 어, 문제가 생겼을 때 어디를 봐야 하는지 알려 주기 때문에 어, 봅니다.이 배포하고 나서 시스템이 느려졌다고 해 보겠습니다. 그때이 P50까지 같이이 응답 시간이 많이 올라갔다면 모든 요청이 공통적으로 느려졌다고 판단할 수가 있겠죠. 반면에 P50 값은 변화가 없는데 P95 P99만 더 높게 튀었다면 특정 조건에 요청에서만 문제가 생긴 걸 수 있겠죠. 그래서 P95 P99가 느려진 걸 판단했을 때 P50을 같이 보면 똑같이 느려졌다인데도이 우리가 파악해야 될 상황이 다를 수 있음을 알 수 있는 거죠. 자, 그리고 P95는 95%가이 값 이하로 응답한다는 의미고요. 이것은 느린 쪽에 사용자 경험까지 포함하는 값인 거죠. 어, 목표값으로 많이 사용되는 기준입니다. 대부분은 괜찮은데 일부가 느린 상황인 거죠. 자, 그리고 P99는 어, 극단적으로 느린 요청. 자, 그것을 우리 꼬리 지연이라고 하는데요. 이런 꼬리 지연까지 관리를 하고 싶을 때 사용하는 기준입니다. 자, 이렇게 높은 100분위까지 보장할수록 돈이 많이 들고 아기택도 복잡해지겠죠.

어 만일에이 결제나 주문처럼 우리 서비스의 핵심이고 또이 결제나 주문처럼 하나의 요청 자체가 아주 중요한 것이라면 P99까지 볼 의미가 있겠지만 모든 서비스가 P99까지 관리할 필요는 없겠죠. 자, 그러면이 왜 이렇게 100분을 봐야 되는지 보겠습니다. 자, 여기 요청이 100개가 있습니다.이 중에서 90거는 100m 만에 응답했고 열거는 어, 3초가 걸렸습니다. 자, 이때 우리의 응답 시간 목표가 500ms였다고 해 보겠습니다. 자, 이때이 100근의 요청을 평균을 내보면 390ms죠. 자, 그러면 우리 목표인 500ms보다 작기 때문에 목표를 달성한 것이죠. 어, 그런데 실제로는 어떤가요? P95를 따져 보면 3초죠. 95%의 요청은 3초가 나온 것이죠. 사용자 입장에서는 열 번에 한 번씩 3초짜리 응답을 만나는 것이죠. 자, 이렇게이 평균 값은 이런 문제를 완전히 가려 버릴 수 있습니다. 그리고 또 하나 사용자는이 평균값 390ms를 직접 경험한 사람은 한 명도 없겠죠. 이것은 평균일 뿐인 거죠. 실제로 사용자가 겪은 건 100m이거나 또는 3초인 거죠.

그래서이 평균은 아무도 겪지 않은 값으로 목표 달성을 판단하는 것이라는 거죠. 어 구글 SR 문서에서도 이렇게 말하고 있습니다. 어 대부분의 지표는 평균보다 어 분포로 보는게 낫다. 이렇게 평균은 사용자가 직접 만나는 값도 아니고 어 테일 레이턴시 즉 꼬리 지연을 알 수 없게 만듭니다. 그래서 목표를 쓸 때는 단순히 응답 시간만 쓰면 안 되고 평균인지 P95 분포인지 정확하게 기준을 정해야 되고요. 같은 500ms라도 평균과 분포는 완전히 해석이 달라지는 겁니다. 자, 이렇게 응답 시간 목표를 정할 때 참고할 수 있는 숫자를 정리를 했고요. 우리 API의 응답 시간 목표를 정할 때는 어 정해진 값은 없지만이 우리 서비스별 품질 목표에 따라서 정하시면 되겠습니다. 자, 이때 우리가 지금까지 봤던 이런 기준들을 참고해서 우리 서비스에 맞게 결정하면 되겠습니다. 어, 그리고 마지막으로 한 가지 더 말씀드리고 싶은 것이이 응답 시간이라는 것도 결국에는 UX 즉 사용자 경험의 문제입니다. 앞서 봤던이 닐슨의 사람이 느끼는 시간과이 구글의 사용자가 겪는 화면의 반응구와 같은이 느린 경험을 하는 사용자 이런 사용자 관점에서 좋은 경험을 주는 것을 목표로 해야 되고 모든 것을 0.1초로 만들 수는 없겠죠.

0.1초가 중요한게 아니라 사용자가 불편하지 않게 만드는 것이 중요한 것이죠. 자, 우리 시스템에 핵심 기능은 빠르게 하더라도 비핵심 기능은 약간 느리게 하더라도이 사용자 경험 예를 들어서 로딩발을 보여 준다든지이 진행 상태를 알려 준다든지 사용자가 내가 액션을 취하고 나서이 시스템이 내 액션에 적각적으로 반응을 한다는 것을 알려 주는 것이 중요합니다. 목표 응답 시간이 조금 몇 초 많이 걸리더라도 그 사이에 사용자가 뭔가를 액션을 취하고이 사이에 기다리는 시간도 사용자에게 피드백을 줄 수 있어야 한다는 것이죠. 그것이 좋은 UX입니다. 제 채널에서는 아키텍트를 위한 멤버십을 운영하고 있습니다. 소프트웨어 아키텍처의 정통 이론부터 실무 설계, 프로젝트 관리와 리더십 등 아키텍트로 성장하는데 도움이 될 만한 다양한 콘텐츠를 제공하고 있습니다. AI 시대에는 단순 구현을 넘어서 시스템 전체를 조망하고 판단하는 역향이 더욱 중요해지고 있습니다. 개발에 머무르지 않고 아키텍트로 한 단계 더 성장하고 싶다면 멤버십에서 저와 함께 공부하고 성장해 보시기 바랍니다.

그리고 지금까지 함께 해 주시는 우리 멤버 여러분 늘 감사드립니다. 함께 성장하는 멤버십이 될 수 있도록 계속 고민하겠습니다. 감사합니다.