HTTP/2에 대한 비즈니스 사례 만들기

HTTP/2는 성능을 염두에 두고 개발되었습니다.

즉, 특히 모바일 앱이 관련된 경우 성과가 가장 중요하다는 현실을 바탕으로 비즈니스 사례를 만드는 것은 간단해 보입니다. 비용이 생산성이나 이익으로 측정되든, 성과가 좋지 않다는 것은 소비자가 모바일 애플리케이션에서 구매, 참여, 사용과 관련하여 제기하는 중요한 문제입니다.

하지만 그건 쉬운 경우예요. 이 주제에 대한 수많은 설문조사를 살펴보면 누구나 그걸 알 수 있습니다. 앱이 5초 이내에 응답하지 않으면 소비자와 직원 모두 불안해진다는 것은 누구나 알고 있습니다. HTTP/2로의 전환 외에도 조직에서 문제를 해결하는 데 사용할 수 있는 다양한 성능 관련 서비스가 있다는 점을 감안할 때, 조직이 "클라우드 우선" 기업이라는 확신을 가지고 HTTP/2로 전환하기로 결정하기 전에 더 많은 추진력이 필요할 수 있습니다.

그렇다면 HTTP/2의 많은 기능은 HTTP/1.1에서 개발자들이 자주 사용하던 방식을 이해한 데서 비롯되어 표준 관행이 되었다는 점을 고려하세요. 인라이닝, 연결, 도메인 샤딩과 같은 관행. 이러한 모든 것이 성능 향상에 기여했지만, 불행히도 각각의 기술 부채가 발생했고 이는 지금까지도 개발자와 운영진 모두에게 부담을 주고 있습니다. HTTP/2로 마이그레이션하면 이러한 관행이 앞으로 기술 부채의 원천이 되는 것을 제거할 수 있으며 현재 존재하는 부채를 "갚는" 경로를 제공합니다.

기술적(그리고 구조적) 부채는 선택으로 인해 발생합니다 . 어떤 기술을 채택할 것인지, 어떤 제품을 구매할 것인지, 어떤 아키텍처를 구현할 것인지에 대한 선택. 또한 특정 솔루션이 애플리케이션 아키텍처의 어느 부분에 구현될 것인지에 따라 결정이 내려질 수도 있습니다.

예를 들어, HTTP/1.1의 일부 제한은 개발자들이 작은 이미지를 인라인으로 삽입하고 작은 파일을 연결하는 방식으로 우회할 수 있었습니다. 실제로 이렇게 하면 성능이 향상되지만, 옵션으로 네트워크에서 애플리케이션 외부 캐싱을 제거하는 단점이 있습니다. 또한, 인라인 이미지나 단일 연결 파일을 구성하는 파일에 대한 모든 변경 사항은 모든 애플리케이션에 반영되어야 하므로 앱 수명 주기 동안 주의가 필요했습니다.  모듈성이 부족하면 해당 애플리케이션이 서비스되는 한 계속 기술 부채가 발생합니다.

실제 부채와 마찬가지로 기술적 부채도 서비스가 필요합니다. 이는 대가로 발생합니다. 바로 이자가 붙습니다. 모든 변화와 업데이트가 있을 때마다 관심은 더욱 커집니다. 개발자의 시간과 주의가 필요합니다. 테스트 리소스가 필요합니다. 네트워크와 컴퓨팅 리소스가 필요합니다. 이로 인해 조직은 혁신이나 확장보다는 "부채"를 상환하는 데 더 많은 시간을 소비하게 되고, 경쟁 우위를 제공하는 새로운 기술, 방법론 및 아키텍처 개념을 활용하기 어렵게 됩니다.

이 부채는 해결되어야 합니다. 실제로는 없어졌지만 최소한 해결해야 할 문제가 있습니다.

HTTP/1.1의 경우, HTTP/1.1의 부채 악순환을 끝내는 수단은 앞으로 HTTP/2를 채택하는 것입니다. HTTP/2는 다양한 기술적, 프로토콜적 한계를 해결함으로써 개발자에게 과거의 해결책에서 벗어나 앞으로 다른 선택을 할 수 있는 방법을 제공합니다. 기술적 부채가 따르지 않는 선택. 기존 애플리케이션은 그러한 부채를 그대로 유지하지만 HTTP/2를 사용하는 애플리케이션으로 옮기거나 교체할 수 있으며, 이를 통해 개발자와 운영자 모두 HTTP/1.1에 대한 이전 대기 애플리케이션에서 가해진 제약으로부터 해방될 수 있습니다.

HTTP/2는 단순히 더 빠른 프로토콜과 앱에 관한 것이 아닙니다. 또한 개발 및 운영에 대한 제약을 제거하여 기술 부채로부터 자유로워지고 조직이 성과를 개선할 수 있는 다른 방법을 활용할 수 있는 기회를 제공하는 것입니다. 애플리케이션 게임 에서 승리하기 위한 경쟁에서 기업이 승리하는 것을 방해할 수 있는 기술적 또는 구조적 부채가 발생할 가능성이 낮은 방법입니다.