2021.09.03

'클라우드 네이티브 앱의 품질 해결책' 개발자 전용 가시성 툴이 필요한 이유

Leonid Blouvshtein | InfoWorld
소프트웨어를 만들어 제공하는 과정은 항상 속도와 품질 관리 사이의 균형 잡기다. 실제로 많은 성공한 IT 기업은 이 기술을 마스터해서 지금의 제국을 건설했다.
 
그 균형을 정확히 찾기 위한 아이디어와 작업 방식에 따라 새로운 툴이 만들어졌고 그 툴이 지금 소프트웨어 분야의 주류로 부상했다. 미래를 생각하는 전 세계 기업의 소프트웨어 조직은 애플리케이션 컨테이너화, CI/CD 파이프라인, 클라우드 컴퓨팅을 빠르게 도입하고 있다. 현대의 소프트웨어 생태계는 사용자에게 제공되는 최종 소프트웨어를 생산하는, 상호 연계되어 능률적으로 작동하고 거의 완전히 자동화된 시스템을 향해 천천히 진화하고 있다

그러나 이 '인프라의 부흥'에도 문제는 있다. 온갖 혁신이 이뤄지고 있지만 그 와중에 오래된 한 가지 문제는 개발자가 대처하기가 오히려 더 어려워지고 있다. 바로 사용자가 좋아하는 멋들어진 소프트웨어 내부에서 정확히 어떤 일이 일어나는지를 파악하는 일이다. 더 중요한 점은 이러한 소프트웨어를 구축하는 개발자가 프로덕션에서 발생한 문제를 수정하기 위해 할 수 있는 일을 이해하기도 갈수록 어려워지고 있다는 것이다.
 

알 수 없는 방대한 버그의 세계

애플리케이션이 대부분 하나의 머신에서 실행되도록 설계됐던 시절에는 여러 가지 버그를 예측하고 확인하기가 지금보다 쉬웠다. 개발 환경과 테스트 환경을 대상 프로덕션 환경과 거의 똑같이 만들 수 있었고 서드 파티 서비스의 수가 적었으며(따라서 서드 파티 구성의 종류도 더 적었음) 종속성의 수도 지금보다 훨씬 적었다.

지금의 애플리케이션은 대체로 분산 시스템에서 실행되도록 구축된다. 더 구체적으로 보면, 많은 기업이 확장 가능한 클라우드 인프라에서 실행되도록 설계되는 클라우드 네이티브 애플리케이션을 구축하는 방식을 도입하고 있다. 과거의 베어메탈, 싱글 테넌트 모놀리스는 이제 쿠버네티스, 서비스 메시, 마이크로서비스로 대체됐다.

이러한 클라우드 네이티브 기술은 프로덕션 환경의 복잡성을 급격하게 늘린다. 문제는 기술 자체가 아니라 '움직이는 요소'가 증가하면서 개발자가 시스템의 모든 잠재적 결함을 알아내기가 더 어려워지는 데 있다는 사실이다. 또한 이 복잡성으로 인해 개발자가 논리상의 실수를 저지를 수 있는 부분이 늘어나고 구성 실수의 여지가 더 많아지고 한 대화에서 시스템 전체를 논의하기도 어려워진다(모든 구성요소에 대해 대화하려면 온종일 걸린다).

이 문제에 맞서기 위해서는 더 개선된 품질 관리가 필요하다. 실무 관점에서 보면 소프트웨어가 기대한 기준에 부합하지 않을 때 이를 알려주는 일종의 메커니즘이 필요하다는 의미다.
 

프로덕션의 디버깅은 품질 관리

코드 리뷰, 적절한 테스트와 같은 품질 관리는 앞으로도 사라지지 않을 것이다. 품질 관리는 이 세계에 꼭 필요한 요소이기 때문이다.

그러나 모든 문제를 사전에, 즉 개발 중이거나 테스트하는 시점에서 예상하기에는 프로덕션에 복잡한 부분이 너무 많다. 사실 개발과 테스트는 이러한 마인드 사이클을 적용하기에는 적절하지 않다. 프로덕션 문제의 근본 원인을 파악하는 가장 실질적이고 빠른 방법은 프로덕션에서 디버깅하는 것이다. 실제 사용자, 실제 요청, 실제 데이터, 실제 인프라를 대상으로 진행하는 것이다.

모든 버그가 로컬로 재현되지는 않고, 모든 애플리케이션을 프로덕션 시스템 상태를 복제하는 환경에서 적절한 시점에 손쉽게 가동할 수 있는 것도 아니다. 디버깅하는 개발자가 모든 데이터를 손쉽게 추출해서 사용할 수는 없다. 이론적으로는 쉽지만, 실제로는 구성, 데이터베이스에 대한 특정 부하, 서드 파티 서비스의 중단 등 항상 이 과정에서 모조해야 할 또 다른 뭔가를 깜박한다.

결국, 관건은 소프트웨어 제공의 속도와 품질 관리 사이의 균형 잡기로 귀결된다. 모든 기업은 새로운 기능을 빠르게 제공하고 이를 반복하길 원한다. 그러나 빠르게 움직이기 위해 팀은 코드를 프로덕션에 넣고 이 코드가 실제 사용 시 어떻게 동작하는지를 봐야 한다. 개발자에게는 이미 사용 중인 툴 내에서 프로덕션 서비스를 파악하기 위한 안전하고 쉬운 방법이 필요하다.
 

아무것도 보이지 않는 블랙박스의 문제 해결

IT 운영자 또는 데브옵스 엔지니어는 공포의 '서비스 다운' 페이지가 뜨면 온갖 종류의 상태 메트릭을 살펴보고 이런저런 버튼을 누르고 조작해 서비스 정상 복원을 시도한다. 이들에게는 상황을 360도로 볼 수 있는 메커니즘이 있다.

반면 개발자는 그런 호사를 누릴 수 없다. 개발자는 끝이 보이지 않는 로그를 스크롤하면서 살펴보고 인프라 메트릭의 대시보드와 스스로 기억해 낸 정보로 근근이 버텨야 한다. 개발자가 두려운 버그 알림을 받을 때의 상황은 용의자도 없고 단서의 흔적만 있는 범죄 현장 조사의 초기 단계와 같다.

일반적으로 첫 단계는 “이 문제가 이 사용자에게만 발생했는가, 아니면 모든 사용자에게 발생했는가?” 또는 “최근 기능 배포 또는 구성 변경과 관계가 있는가?”와 같은 질문이다. 개발자가 애플리케이션 로그를 뒤적거리면서 이러한 질문을 통해 가능성이 없는 원인을 하나씩 제외하며 이론과 실제 발생한 일 사이의 상관관계를 파악하는 긴 과정이 시작된다. 그러나 우리의 희망 사항과는 반대로 많은 문제가 블랙박스, 즉 애초에 로그가 없는 객체나 경로 안에 숨어 있다.

이 경우 보통 실행 중인 프로덕션 애플리케이션 내부에서 어떤 일이 벌어지고 있는지 더 자세히 보기 위한 조사 과정에서 일련의 핫픽스가 나와 적용되며, CI/CD 파이프라인이 완료되고 릴리스가 배포되는 사이 귀중한 사고 대응 시간이 흘러간다. 많은 시간이 걸리고 값비싸고 민첩하지 않은 프로세스다. 게다가 이 프로세스는 개발자를 익숙한 툴에서 끄집어내 IT 모니터링, 대시보드, GUI의 세계로 던져 넣는다. 전혀 좋지 않은 일이다.
 

개발자에겐 개발자를 위한 관찰 기능이 필요

소프트웨어 세계에서 지금 일어나고 있는 극적인 발전을 잠시 돌이켜 생각해 보자. 개발자가 코드부터 프로덕션에서 실행 중인 애플리케이션에서 더 적은 수작업으로 더 빠르게 코드를 추출할 수 있는 최신 시스템의 수는 놀라울 정도로 많다.

이와 같은 툴이 프로덕션 코드의 문제를 해결하는 데도 필요하다. 수정 과정은 빠르고 쉬워야 하며 민첩한 실시간 개발자 중심의 프로세스를 가능하게 해주는 툴이어야 한다. 개발자(운영자가 아님)는 프로덕션 버그의 발견과 교정뿐만 아니라 애플리케이션 논리의 안정성도 관장할 수 있어야 한다. 결국 개발자에게는 개발 워크플로우, IDE, 소스 제어에 통합되는 관찰  툴이 필요하다.

그러나 안타깝게도 아직 그 지점에는 이르지 못했다. 코드 수준 문제를 실시간으로 해부하기 위한 툴은 여전히 불편하다. 다른 대륙의 기기로 손쉽게 코드를 보낼 수 있는 시대지만, 처음부터 명시적으로 로깅을 하지 않은 경우 객체의 구조 또는 메모리 내에서의 크기를 알기는 여전히 어렵다.

오랜 기간 개발자와 관리자로 일하면서 운 좋게 유능한 개발자를 이끈 경험도 있는 사람으로서 확실히 말할 수 있는 부분은 개발자에게 더 나은 툴이 필요하다는 것이다. 개발자의 작업에 꼭 맞는 툴, 회사 내의 다른 부서에서 빌려온 툴이 아닌 개발자 워크플로우에 통합되는 툴이 필요하다. 시스템의 실제 상태에 영향을 미치지 않으면서 시스템을 조작할 수 있게 해주고 애플리케이션이 비정상적으로 작동할 때 더 정확한 시야를 제공하는 툴이 필요하다. editor@itworld.co.kr


2021.09.03

'클라우드 네이티브 앱의 품질 해결책' 개발자 전용 가시성 툴이 필요한 이유

Leonid Blouvshtein | InfoWorld
소프트웨어를 만들어 제공하는 과정은 항상 속도와 품질 관리 사이의 균형 잡기다. 실제로 많은 성공한 IT 기업은 이 기술을 마스터해서 지금의 제국을 건설했다.
 
그 균형을 정확히 찾기 위한 아이디어와 작업 방식에 따라 새로운 툴이 만들어졌고 그 툴이 지금 소프트웨어 분야의 주류로 부상했다. 미래를 생각하는 전 세계 기업의 소프트웨어 조직은 애플리케이션 컨테이너화, CI/CD 파이프라인, 클라우드 컴퓨팅을 빠르게 도입하고 있다. 현대의 소프트웨어 생태계는 사용자에게 제공되는 최종 소프트웨어를 생산하는, 상호 연계되어 능률적으로 작동하고 거의 완전히 자동화된 시스템을 향해 천천히 진화하고 있다

그러나 이 '인프라의 부흥'에도 문제는 있다. 온갖 혁신이 이뤄지고 있지만 그 와중에 오래된 한 가지 문제는 개발자가 대처하기가 오히려 더 어려워지고 있다. 바로 사용자가 좋아하는 멋들어진 소프트웨어 내부에서 정확히 어떤 일이 일어나는지를 파악하는 일이다. 더 중요한 점은 이러한 소프트웨어를 구축하는 개발자가 프로덕션에서 발생한 문제를 수정하기 위해 할 수 있는 일을 이해하기도 갈수록 어려워지고 있다는 것이다.
 

알 수 없는 방대한 버그의 세계

애플리케이션이 대부분 하나의 머신에서 실행되도록 설계됐던 시절에는 여러 가지 버그를 예측하고 확인하기가 지금보다 쉬웠다. 개발 환경과 테스트 환경을 대상 프로덕션 환경과 거의 똑같이 만들 수 있었고 서드 파티 서비스의 수가 적었으며(따라서 서드 파티 구성의 종류도 더 적었음) 종속성의 수도 지금보다 훨씬 적었다.

지금의 애플리케이션은 대체로 분산 시스템에서 실행되도록 구축된다. 더 구체적으로 보면, 많은 기업이 확장 가능한 클라우드 인프라에서 실행되도록 설계되는 클라우드 네이티브 애플리케이션을 구축하는 방식을 도입하고 있다. 과거의 베어메탈, 싱글 테넌트 모놀리스는 이제 쿠버네티스, 서비스 메시, 마이크로서비스로 대체됐다.

이러한 클라우드 네이티브 기술은 프로덕션 환경의 복잡성을 급격하게 늘린다. 문제는 기술 자체가 아니라 '움직이는 요소'가 증가하면서 개발자가 시스템의 모든 잠재적 결함을 알아내기가 더 어려워지는 데 있다는 사실이다. 또한 이 복잡성으로 인해 개발자가 논리상의 실수를 저지를 수 있는 부분이 늘어나고 구성 실수의 여지가 더 많아지고 한 대화에서 시스템 전체를 논의하기도 어려워진다(모든 구성요소에 대해 대화하려면 온종일 걸린다).

이 문제에 맞서기 위해서는 더 개선된 품질 관리가 필요하다. 실무 관점에서 보면 소프트웨어가 기대한 기준에 부합하지 않을 때 이를 알려주는 일종의 메커니즘이 필요하다는 의미다.
 

프로덕션의 디버깅은 품질 관리

코드 리뷰, 적절한 테스트와 같은 품질 관리는 앞으로도 사라지지 않을 것이다. 품질 관리는 이 세계에 꼭 필요한 요소이기 때문이다.

그러나 모든 문제를 사전에, 즉 개발 중이거나 테스트하는 시점에서 예상하기에는 프로덕션에 복잡한 부분이 너무 많다. 사실 개발과 테스트는 이러한 마인드 사이클을 적용하기에는 적절하지 않다. 프로덕션 문제의 근본 원인을 파악하는 가장 실질적이고 빠른 방법은 프로덕션에서 디버깅하는 것이다. 실제 사용자, 실제 요청, 실제 데이터, 실제 인프라를 대상으로 진행하는 것이다.

모든 버그가 로컬로 재현되지는 않고, 모든 애플리케이션을 프로덕션 시스템 상태를 복제하는 환경에서 적절한 시점에 손쉽게 가동할 수 있는 것도 아니다. 디버깅하는 개발자가 모든 데이터를 손쉽게 추출해서 사용할 수는 없다. 이론적으로는 쉽지만, 실제로는 구성, 데이터베이스에 대한 특정 부하, 서드 파티 서비스의 중단 등 항상 이 과정에서 모조해야 할 또 다른 뭔가를 깜박한다.

결국, 관건은 소프트웨어 제공의 속도와 품질 관리 사이의 균형 잡기로 귀결된다. 모든 기업은 새로운 기능을 빠르게 제공하고 이를 반복하길 원한다. 그러나 빠르게 움직이기 위해 팀은 코드를 프로덕션에 넣고 이 코드가 실제 사용 시 어떻게 동작하는지를 봐야 한다. 개발자에게는 이미 사용 중인 툴 내에서 프로덕션 서비스를 파악하기 위한 안전하고 쉬운 방법이 필요하다.
 

아무것도 보이지 않는 블랙박스의 문제 해결

IT 운영자 또는 데브옵스 엔지니어는 공포의 '서비스 다운' 페이지가 뜨면 온갖 종류의 상태 메트릭을 살펴보고 이런저런 버튼을 누르고 조작해 서비스 정상 복원을 시도한다. 이들에게는 상황을 360도로 볼 수 있는 메커니즘이 있다.

반면 개발자는 그런 호사를 누릴 수 없다. 개발자는 끝이 보이지 않는 로그를 스크롤하면서 살펴보고 인프라 메트릭의 대시보드와 스스로 기억해 낸 정보로 근근이 버텨야 한다. 개발자가 두려운 버그 알림을 받을 때의 상황은 용의자도 없고 단서의 흔적만 있는 범죄 현장 조사의 초기 단계와 같다.

일반적으로 첫 단계는 “이 문제가 이 사용자에게만 발생했는가, 아니면 모든 사용자에게 발생했는가?” 또는 “최근 기능 배포 또는 구성 변경과 관계가 있는가?”와 같은 질문이다. 개발자가 애플리케이션 로그를 뒤적거리면서 이러한 질문을 통해 가능성이 없는 원인을 하나씩 제외하며 이론과 실제 발생한 일 사이의 상관관계를 파악하는 긴 과정이 시작된다. 그러나 우리의 희망 사항과는 반대로 많은 문제가 블랙박스, 즉 애초에 로그가 없는 객체나 경로 안에 숨어 있다.

이 경우 보통 실행 중인 프로덕션 애플리케이션 내부에서 어떤 일이 벌어지고 있는지 더 자세히 보기 위한 조사 과정에서 일련의 핫픽스가 나와 적용되며, CI/CD 파이프라인이 완료되고 릴리스가 배포되는 사이 귀중한 사고 대응 시간이 흘러간다. 많은 시간이 걸리고 값비싸고 민첩하지 않은 프로세스다. 게다가 이 프로세스는 개발자를 익숙한 툴에서 끄집어내 IT 모니터링, 대시보드, GUI의 세계로 던져 넣는다. 전혀 좋지 않은 일이다.
 

개발자에겐 개발자를 위한 관찰 기능이 필요

소프트웨어 세계에서 지금 일어나고 있는 극적인 발전을 잠시 돌이켜 생각해 보자. 개발자가 코드부터 프로덕션에서 실행 중인 애플리케이션에서 더 적은 수작업으로 더 빠르게 코드를 추출할 수 있는 최신 시스템의 수는 놀라울 정도로 많다.

이와 같은 툴이 프로덕션 코드의 문제를 해결하는 데도 필요하다. 수정 과정은 빠르고 쉬워야 하며 민첩한 실시간 개발자 중심의 프로세스를 가능하게 해주는 툴이어야 한다. 개발자(운영자가 아님)는 프로덕션 버그의 발견과 교정뿐만 아니라 애플리케이션 논리의 안정성도 관장할 수 있어야 한다. 결국 개발자에게는 개발 워크플로우, IDE, 소스 제어에 통합되는 관찰  툴이 필요하다.

그러나 안타깝게도 아직 그 지점에는 이르지 못했다. 코드 수준 문제를 실시간으로 해부하기 위한 툴은 여전히 불편하다. 다른 대륙의 기기로 손쉽게 코드를 보낼 수 있는 시대지만, 처음부터 명시적으로 로깅을 하지 않은 경우 객체의 구조 또는 메모리 내에서의 크기를 알기는 여전히 어렵다.

오랜 기간 개발자와 관리자로 일하면서 운 좋게 유능한 개발자를 이끈 경험도 있는 사람으로서 확실히 말할 수 있는 부분은 개발자에게 더 나은 툴이 필요하다는 것이다. 개발자의 작업에 꼭 맞는 툴, 회사 내의 다른 부서에서 빌려온 툴이 아닌 개발자 워크플로우에 통합되는 툴이 필요하다. 시스템의 실제 상태에 영향을 미치지 않으면서 시스템을 조작할 수 있게 해주고 애플리케이션이 비정상적으로 작동할 때 더 정확한 시야를 제공하는 툴이 필요하다. editor@itworld.co.kr


X