2021.03.22

“사람과 프로세스를 위해” 컨테이너에도 표준 운영 환경이 필요한 이유

Scott McCarty | InfoWorld
“컨테이너 안녕? 나는 네 표준 운영 환경인 SOE야. 혹시 나를 기억하니? 물론 못하겠지. 네 덕분에 모든 사람들이 고도로 자동화된 애플리케이션 모음을 구축, 관리, 유지하는 역량에 부정적인 영향을 미치지 않으면서 아무 때나, 아무 기술이라도 사용할 수 있다고 믿게 되었으니까. 그렇지 않다는 걸 너는 알겠지. 그건 사실이 아니야. 너에게는 내가 필요하고, 기업에도 내가 필요해. 같이 예전으로 돌아가자.”

그리 멀지 않은 과거에는 모두가 표준 운영 환경(Standard Operating Environment, SOE)을 사용했다. 일반적으로 SOE는 기본 운영체제(커널 및 사용자 공간 프로그램), 맞춤형 구성 파일, 조직 내에 사용되는 표준 애플리케이션, 소프트웨어 업데이트, 서비스 팩을 포함하며, 운영 환경의 보안을 강화하고 프로세스를 간소화하고 코드를 자동화하도록 설계된다. 관리자는 SOE를 조직 내의 대규모 배포를 위한 디스크 이미지, 킥스타트 또는 가상머신 이미지로 구현한다. 

SOE는 서버, 데스크톱, 노트북, 씬 클라이언트, 모바일 디바이스, 컨테이너 디바이스에 적용할 수 있다. 물론 컨테이너 이미지에도 해당된다. 사실 SOE는 컨테이너화된 애플리케이션을 배포, 구성, 유지, 지원, 관리하는 데 소요되는 시간을 줄여줄 수 있다. 

그런데 컨테이너가 사실상 SOE를 버린 이유는 무엇일까? 

잃어버린 표준 
일각에서는 표준화가 혁신에 방해가 되고 대체로 개발 및 배포 프로세스의 속도를 저하시킨다고 주장한다. 그러나 생각해볼 점이 있다. 개발팀은 코드 품질과 구문, 나아가 노트북에서 새로운 개발 환경을 설정하는 방법까지 자연스럽게 표준을 둔다는 점이다. 느린 것이 꾸준하고, 꾸준한 것이 순조롭고, 순조로운 것이 빠르다는 말이 있다. 컨테이너 기본 이미지를 표준화하면 개발자의 작업 속도를 높이는 데 도움이 될 수 있다. 

또한 표준화가 보안을 강화한다는 데는 이론의 여지가 없다. 하지만 SOE 반대론자는 컨테이너는 크기가 작으므로 공격 표면도 작다고 주장한다. 물론 컨테이너 하나의 공격 표면은 작지만 컨테이너를 하나만 사용하는 조직이 얼마나 될까? 소프트웨어 환경에 사용되는 컨테이너의 수가 수백, 수천 개로 늘어나면 공격의 크기와 복잡성도 함께 커진다. 

다음 그림은 표준화되지 않은 환경에서 치환 및 공격 표면이 얼마나 빠르게, 폭발적으로 증가하는지 보여준다. C 라이브러리와 오픈SSL 두 가지만 해도 총 22가지의 패키지 버전을 추적하고 패치해야 한다. 이 모델에는 확장성이 없다. 
 
ⓒ Red Hat

실제로 컨테이너와 SOE를 재결합해야 할 좋은(아주 좋은) 이유와 중요한(아주 중요한) 이유가 하나씩 있다. 바로 사람과 프로세스다. 
 

사람을 위한 표준 운영 환경 

조직에는 각 소프트웨어 요소마다 그 요소를 책임지는 SME(Subject Matter Expert, 주제 전문가)가 필요하다. 운영체제 자체, 다양한 데이터베이스, 자바, 파이썬, DNS, 웹 서버 등에 대한 전문가가 있다. 

이 SME 모델은 소프트웨어가 컨테이너로 배포되는 경우에도 바뀌지 않는다. SME는 여전히 최선의 아키텍처를 설계하고 기본 구성을 지정하고 백업의 작동 방식을 결정하고 데이터가 위치하는 곳을 구축하는 등의 일을 한다. 또한 이 모델은 데이터베이스, DNS, 캐싱 계층 등의 서비스에 적용되는 데 끝나지 않고, 새로 만들어지는 소프트웨어를 위한 애플리케이션 스택도 포함한다. 달리 말하면, 새 애플리케이션을 구축하는 경우에도 루비, Node.js, 러스트, 파이썬, C/C++, 고랭, 자바, 닷넷, 그리고 당연히 이런한 언어에서 공통적으로 사용되는 모든 프레임워크에 대한 SME는 반드시 필요하다. 

품질과 보안성이 높은 하나의 리눅스 기반 이미지로 표준화하면, 이런 SME의 업무가 간소화된다. SME는 리눅스 라이브러리를 평가하고 집어넣는 고단한 작업 대신 자신의 전문 영역에 집중할 수 있다. 또한 개발자, 애플리케이션 관리자, 보안 전문가, 그리고 방대한 기반 서버를 운영하는 운영팀 간의 골치 아픈 상호작용도 줄어든다(특히 이 기반 서버가 동일한 리눅스 배포판으로 구축된 경우). 

표준 컨테이너 이미지를 두면 신규 인력 채용도 더 쉬워진다. 새로 채용된 개발자나 SRE는 더 빠르게 업무에 적응할 수 있다. 선임 개발자가 감당해야 하는 인지 부하(Cognitive load)가 경감된다. 운영팀이 공휴일을 마음 편히 보낼 수 있다. 
 

프로세스가 복잡해지는 이유 

복잡한 프로세스는 더 빠르고 민첩하게 움직이고자 하는 조직에 득 될 것이 없다. 데브옵스와 구성 관리를 통한 경험으로 이 사실을 배웠음에도, 컨테이너 들어서서는 그것을 잊은 듯하다. 



2021.03.22

“사람과 프로세스를 위해” 컨테이너에도 표준 운영 환경이 필요한 이유

Scott McCarty | InfoWorld
“컨테이너 안녕? 나는 네 표준 운영 환경인 SOE야. 혹시 나를 기억하니? 물론 못하겠지. 네 덕분에 모든 사람들이 고도로 자동화된 애플리케이션 모음을 구축, 관리, 유지하는 역량에 부정적인 영향을 미치지 않으면서 아무 때나, 아무 기술이라도 사용할 수 있다고 믿게 되었으니까. 그렇지 않다는 걸 너는 알겠지. 그건 사실이 아니야. 너에게는 내가 필요하고, 기업에도 내가 필요해. 같이 예전으로 돌아가자.”

그리 멀지 않은 과거에는 모두가 표준 운영 환경(Standard Operating Environment, SOE)을 사용했다. 일반적으로 SOE는 기본 운영체제(커널 및 사용자 공간 프로그램), 맞춤형 구성 파일, 조직 내에 사용되는 표준 애플리케이션, 소프트웨어 업데이트, 서비스 팩을 포함하며, 운영 환경의 보안을 강화하고 프로세스를 간소화하고 코드를 자동화하도록 설계된다. 관리자는 SOE를 조직 내의 대규모 배포를 위한 디스크 이미지, 킥스타트 또는 가상머신 이미지로 구현한다. 

SOE는 서버, 데스크톱, 노트북, 씬 클라이언트, 모바일 디바이스, 컨테이너 디바이스에 적용할 수 있다. 물론 컨테이너 이미지에도 해당된다. 사실 SOE는 컨테이너화된 애플리케이션을 배포, 구성, 유지, 지원, 관리하는 데 소요되는 시간을 줄여줄 수 있다. 

그런데 컨테이너가 사실상 SOE를 버린 이유는 무엇일까? 

잃어버린 표준 
일각에서는 표준화가 혁신에 방해가 되고 대체로 개발 및 배포 프로세스의 속도를 저하시킨다고 주장한다. 그러나 생각해볼 점이 있다. 개발팀은 코드 품질과 구문, 나아가 노트북에서 새로운 개발 환경을 설정하는 방법까지 자연스럽게 표준을 둔다는 점이다. 느린 것이 꾸준하고, 꾸준한 것이 순조롭고, 순조로운 것이 빠르다는 말이 있다. 컨테이너 기본 이미지를 표준화하면 개발자의 작업 속도를 높이는 데 도움이 될 수 있다. 

또한 표준화가 보안을 강화한다는 데는 이론의 여지가 없다. 하지만 SOE 반대론자는 컨테이너는 크기가 작으므로 공격 표면도 작다고 주장한다. 물론 컨테이너 하나의 공격 표면은 작지만 컨테이너를 하나만 사용하는 조직이 얼마나 될까? 소프트웨어 환경에 사용되는 컨테이너의 수가 수백, 수천 개로 늘어나면 공격의 크기와 복잡성도 함께 커진다. 

다음 그림은 표준화되지 않은 환경에서 치환 및 공격 표면이 얼마나 빠르게, 폭발적으로 증가하는지 보여준다. C 라이브러리와 오픈SSL 두 가지만 해도 총 22가지의 패키지 버전을 추적하고 패치해야 한다. 이 모델에는 확장성이 없다. 
 
ⓒ Red Hat

실제로 컨테이너와 SOE를 재결합해야 할 좋은(아주 좋은) 이유와 중요한(아주 중요한) 이유가 하나씩 있다. 바로 사람과 프로세스다. 
 

사람을 위한 표준 운영 환경 

조직에는 각 소프트웨어 요소마다 그 요소를 책임지는 SME(Subject Matter Expert, 주제 전문가)가 필요하다. 운영체제 자체, 다양한 데이터베이스, 자바, 파이썬, DNS, 웹 서버 등에 대한 전문가가 있다. 

이 SME 모델은 소프트웨어가 컨테이너로 배포되는 경우에도 바뀌지 않는다. SME는 여전히 최선의 아키텍처를 설계하고 기본 구성을 지정하고 백업의 작동 방식을 결정하고 데이터가 위치하는 곳을 구축하는 등의 일을 한다. 또한 이 모델은 데이터베이스, DNS, 캐싱 계층 등의 서비스에 적용되는 데 끝나지 않고, 새로 만들어지는 소프트웨어를 위한 애플리케이션 스택도 포함한다. 달리 말하면, 새 애플리케이션을 구축하는 경우에도 루비, Node.js, 러스트, 파이썬, C/C++, 고랭, 자바, 닷넷, 그리고 당연히 이런한 언어에서 공통적으로 사용되는 모든 프레임워크에 대한 SME는 반드시 필요하다. 

품질과 보안성이 높은 하나의 리눅스 기반 이미지로 표준화하면, 이런 SME의 업무가 간소화된다. SME는 리눅스 라이브러리를 평가하고 집어넣는 고단한 작업 대신 자신의 전문 영역에 집중할 수 있다. 또한 개발자, 애플리케이션 관리자, 보안 전문가, 그리고 방대한 기반 서버를 운영하는 운영팀 간의 골치 아픈 상호작용도 줄어든다(특히 이 기반 서버가 동일한 리눅스 배포판으로 구축된 경우). 

표준 컨테이너 이미지를 두면 신규 인력 채용도 더 쉬워진다. 새로 채용된 개발자나 SRE는 더 빠르게 업무에 적응할 수 있다. 선임 개발자가 감당해야 하는 인지 부하(Cognitive load)가 경감된다. 운영팀이 공휴일을 마음 편히 보낼 수 있다. 
 

프로세스가 복잡해지는 이유 

복잡한 프로세스는 더 빠르고 민첩하게 움직이고자 하는 조직에 득 될 것이 없다. 데브옵스와 구성 관리를 통한 경험으로 이 사실을 배웠음에도, 컨테이너 들어서서는 그것을 잊은 듯하다. 



X