.jpg)
.jpg)
전통의 IT 구조에서 막강한 영향력 발휘했으나
개발자가 시스템 관리자 역할 맡을 수 있어...코딩 배워야
[보안뉴스 문가용 기자] 보통 중소기업의 IT 조직 내에서는 시스템 관리자가 가장 중추적인 역할을 맡아왔다. 시스템 관리자는 119 출동대이기도 했으며, 따라서 비상시 가장 먼저 연락해야 하는 인물이었다. 직원들 모두 시스템 관리자 전화번호를 저장해두고 있었으며, 주말이고 휴일이고 당직들은 시스템 관리자에게 전화를 걸어 크고 작은 질문들을 했다.
하지만 가장 잦은 러브콜의 대상이었던 이 시스템 관리자는 현재 가장 흔들리고 있는 직책이다. 이게 모두 디지털 변혁과 클라우드 때문이다. 기기나 소프트웨어의 설치를 담당하고, 백업을 책임지던 시스템 관리자의 할 일을 다른 서비스 업체가 앗아가고 있다.
90년대 후반 무렵, 가상화, 사전 모니터링(proactive monitoring), 스마트 스위치 등이 등장하면서 시스템 관리자의 힘은 더욱 막강해졌다. 버튼 몇 개만 누르면 가상화 기기를 가동시킬 수 있었고, 저장소와 네트워크도 마음대로 설정할 수 있었다. 그 과정에서 서버를 분해하거나 사다리를 가져와 서버실 꼭대기까지 기어 올라가 라우터 전선을 재연결시킬 필요도 없게 되었다.
시스템 관리자가 이런 방식으로 권한을 가져가는 환경에서의 가장 큰 문제점은 서버 및 네트워크 확장이 너무나 어려웠다는 것이다. 사업이 자랄수록, 해가 갈수록 규모를 키워야 했는데 제동이 걸릴 수밖에 없는 구조였다는 것이다. 그저 낡은 시스템이 고장날 때까지 기다렸다가 업그레이드된 기기로 갈아 치우는 것만이 방법이었다. 물론 이 과정에서 시스템을 다운시키는 건 당연한 일이었다. 유명 웹 서비스가 ‘시스템 점검으로 인해’ 오프라인 되는 건 흔한 경험이었고, 산업 표준과도 같은 일이었다.
그런 상태에서 2000년이 찾아왔다. 이때도 클라우드 기술은 존재했다. 그러나 시스템 관리자를 중심으로한 IT 구조를 흔들기에는 역부족이었다. 그것은 10년이 넘는 시간이 지난 후인 최근에서야 나타나기 시작한 현상이다. 클라우드 기술의 발전도 발전이지만 그와 함께 IT 업계의 다양한 변화들이 맞물리면서 기존 IT 환경의 근본적인 결함에 대한 질문들이 생겨나기 시작한 것이다. 그 요인들은 다음과 같다.
코드로서의 인프라 : IaC(Infrastructure as Code)라고 불리는 이 기술은 컴퓨팅, 저장, 네트워크 및 관련 인프라에 대한 관리 및 보급을 간단한 코드로 해결해내는 프로세스라고 정의할 수 있다. 패러다임의 전환이라고 볼 수 있는 개념인데, 한 마디로 인프라스트럭처 전부를 ‘애완동물’처럼 대하는 게 아니라 ‘가축’처럼 관리하는 것이라고 볼 수 있다. 한 마리 한 마리 내 식구처럼 애지중지 하는 게 아니라 효율과 ‘전체’를 우선적으로 생각하는 방식이다.
IaC와 소프트웨어 정의 데이터센터의 등장으로 시스템 관리자와 개발자의 역할을 구분 짓는 경계선이 급작스럽게 흐려졌다. ‘코드’라고 하면 시스템 관리자가 손을 대지 않던 부분이었는데, 인프라를 ‘코드’로 관리하는 것이 IaC의 개념이다보니 개발자의 지위는 상승하고 시스템 관리자의 그것은 내려가게 되었다.
콘테이너 : 콘테이너 기술의 현존 최강자는 도커(Docker)다. 이 기술을 통해 사용자는 기저에 깔려 있는 인프라에 대한 추상화 작업을 쉽게 할 수 있게 된다. 이 때문에 실험 환경에서나 실제 생산 프로세스에서 같은 실험을 하고 같은 결과를 얻을 수 있게 된다. 실험은 다 통과했는데 실제 출시된 제품 및 서비스에서 오류가 발생해 리콜을 한다거나 롤백을 해야 하는 리스크가 크게 줄어든다는 것이다. 실험 환경이나 실제 생산 환경을 같게 만들어 실험을 최대한 ‘진짜처럼’ 할 수 있게 해주는 것이 콘테이너의 가장 큰 장점이다. 그러므로 실험 후 실제 생산 및 서비스 배포에 차질이 줄어든다. 시스템 관리자의 역할 역시 줄어들긴 마찬가지다.
챗 봇 : 시스템 관리자라고 서버실 내 24시간 365일 살 수도 없는 노릇인데, 하필 자리를 잠깐 비운 고 사이에 윗선과 아랫선에서 작업 요청 전화가 참 많이도 오는 것이 일상다반사였다. 그래서 등장한 것이 휴봇(Hubot)과 같은 챗 봇이다. 시스템 관리자에게 물어야 할 것들을 챗 봇을 통해 물을 수 있게 되었으며, 앞으로 인공지능까지 탑재해 자연어로 대화까지도 나누는 것은 물론 각종 사태를 학습해 최적의 해결책을 내놓을 전망이다. 시스템 관리자가 갑작스럽게 스케줄 조정을 하지 않아도 되게끔 돕는 역할을 넘어, 아예 그 자리를 빼앗지 않을까 한다.
위 세 기술이 발전하면 할수록 24시간 항시 지원과 줄어든 리스크를 누릴 수 있게 될 전망인데, 일반 임직원들이 가장 반기는 건 ‘시스템 관리자에게 아쉬운 소리를 하지 않아도 된다는 것’이다. 그밖에도 다음 기술이나 개념들의 등장으로 시스템 관리자 축출 속도는 더욱 빨라지고 있다.
마이크로서비스 : 거대한 하나의 수직 구조로 되어 있는 클라이언트-서버 애플리케이션들은 천천히 사라지고 있다. 서버에 부담을 줄 수밖에 없는 ‘수직적인 확장’ 대신 경제적인 ‘수평 확장’이라는 개념을 기반으로 한 클라우드 인프라가 널리 활용되고 있기 때문이다. 이 ‘수평적 확장’을 가능하게 하는 게 바로 마이크로서비스라는 개념이다.
마이크로서비스는 여러 기능을 가진 대형 애플리케이션을 통째로 만드는 것과 반대로, 한두 가지 기능을 수행하는 작은 ‘부품’들을 조립해 커다란 애플리케이션을 만드는 것으로, 개발 및 출시 속도가 중요한 현재 IT 시장에서 당연히 나타나 정착될 수밖에 없는 개념이었다. 이때 작은 ‘부품’에 해당하는 프로그램이나 코드들을 조립하는 역할 역시 개발자가 할 수밖에 없어 시스템 관리자의 지위는 상대적으로 더 낮아지게 되었다. 마이크로서비스 방식으로 개발을 하는 업체는 데브옵스(DevOps)를 많이 차용하는데, 데브옵스 구조는 관리자에 대한 의존도가 극히 낮은 것이 특징이기도 하다.
데브옵스 : 이제 IT 업계 누구나 아는 용어처럼 굳어져버린 데브옵스는 시스템 관리자의 역할을 크게 감소시킨 장본인이다. 작은 모듈들을 빠르게 가져다 붙이고, 그 과정에서 취약점들을 더 빠르고 즉시적으로 점검, 보완할 수 있기 때문에 중앙에서의 관리하는 기능이 소멸되다시피 했다. 사실 중앙 관리 기능뿐 아니라 ‘개발’을 둘러싼 전통의 기업 문화를 통째로 바꾸고 있는 게 바로 데브옵스다.
시스템 관리자의 역할, 어떻게 바뀌나?
여기서 기고를 끝낼 수도 있었지만, 시스템 관리자들의 원성이 높을 거 같아 이들의 새로운 역할에 대해서 몇 줄 첨가하고자 한다. 시스템 관리자들은 앞으로 실업자가 될까? 솔직히 말하자면, 기업들이 시스템 관리자 부문의 고용인원을 늘릴 것 같지 않다. 차세대 네트워크 환경에서는 개발자들이 이 역할을 대부분 담당할 수 있기 때문이다.
반대로 말하자면 시스템 관리자가 이제는 필수적으로 코딩을 배워야 한다는 뜻으로 해석이 가능하다. 개발팀과 관리팀이 하나로 합쳐질 것이 거의 분명하고, 돌아가는 상황 상 개발 능력이 조금은 더 요구 되는 것이 사실이다. 시스템 관리자라는 직책은 유지될 지도 모르나, 필요한 기술과 툴셋은 전혀 달라질 것이다.
글 : 산토시 발란(Santosh Balan)
[국제부 문가용 기자(globoan@boannews.com)]
개발자가 시스템 관리자 역할 맡을 수 있어...코딩 배워야
[보안뉴스 문가용 기자] 보통 중소기업의 IT 조직 내에서는 시스템 관리자가 가장 중추적인 역할을 맡아왔다. 시스템 관리자는 119 출동대이기도 했으며, 따라서 비상시 가장 먼저 연락해야 하는 인물이었다. 직원들 모두 시스템 관리자 전화번호를 저장해두고 있었으며, 주말이고 휴일이고 당직들은 시스템 관리자에게 전화를 걸어 크고 작은 질문들을 했다.
[이미지 = iclickart]
하지만 가장 잦은 러브콜의 대상이었던 이 시스템 관리자는 현재 가장 흔들리고 있는 직책이다. 이게 모두 디지털 변혁과 클라우드 때문이다. 기기나 소프트웨어의 설치를 담당하고, 백업을 책임지던 시스템 관리자의 할 일을 다른 서비스 업체가 앗아가고 있다.
90년대 후반 무렵, 가상화, 사전 모니터링(proactive monitoring), 스마트 스위치 등이 등장하면서 시스템 관리자의 힘은 더욱 막강해졌다. 버튼 몇 개만 누르면 가상화 기기를 가동시킬 수 있었고, 저장소와 네트워크도 마음대로 설정할 수 있었다. 그 과정에서 서버를 분해하거나 사다리를 가져와 서버실 꼭대기까지 기어 올라가 라우터 전선을 재연결시킬 필요도 없게 되었다.
시스템 관리자가 이런 방식으로 권한을 가져가는 환경에서의 가장 큰 문제점은 서버 및 네트워크 확장이 너무나 어려웠다는 것이다. 사업이 자랄수록, 해가 갈수록 규모를 키워야 했는데 제동이 걸릴 수밖에 없는 구조였다는 것이다. 그저 낡은 시스템이 고장날 때까지 기다렸다가 업그레이드된 기기로 갈아 치우는 것만이 방법이었다. 물론 이 과정에서 시스템을 다운시키는 건 당연한 일이었다. 유명 웹 서비스가 ‘시스템 점검으로 인해’ 오프라인 되는 건 흔한 경험이었고, 산업 표준과도 같은 일이었다.
그런 상태에서 2000년이 찾아왔다. 이때도 클라우드 기술은 존재했다. 그러나 시스템 관리자를 중심으로한 IT 구조를 흔들기에는 역부족이었다. 그것은 10년이 넘는 시간이 지난 후인 최근에서야 나타나기 시작한 현상이다. 클라우드 기술의 발전도 발전이지만 그와 함께 IT 업계의 다양한 변화들이 맞물리면서 기존 IT 환경의 근본적인 결함에 대한 질문들이 생겨나기 시작한 것이다. 그 요인들은 다음과 같다.
코드로서의 인프라 : IaC(Infrastructure as Code)라고 불리는 이 기술은 컴퓨팅, 저장, 네트워크 및 관련 인프라에 대한 관리 및 보급을 간단한 코드로 해결해내는 프로세스라고 정의할 수 있다. 패러다임의 전환이라고 볼 수 있는 개념인데, 한 마디로 인프라스트럭처 전부를 ‘애완동물’처럼 대하는 게 아니라 ‘가축’처럼 관리하는 것이라고 볼 수 있다. 한 마리 한 마리 내 식구처럼 애지중지 하는 게 아니라 효율과 ‘전체’를 우선적으로 생각하는 방식이다.
IaC와 소프트웨어 정의 데이터센터의 등장으로 시스템 관리자와 개발자의 역할을 구분 짓는 경계선이 급작스럽게 흐려졌다. ‘코드’라고 하면 시스템 관리자가 손을 대지 않던 부분이었는데, 인프라를 ‘코드’로 관리하는 것이 IaC의 개념이다보니 개발자의 지위는 상승하고 시스템 관리자의 그것은 내려가게 되었다.
콘테이너 : 콘테이너 기술의 현존 최강자는 도커(Docker)다. 이 기술을 통해 사용자는 기저에 깔려 있는 인프라에 대한 추상화 작업을 쉽게 할 수 있게 된다. 이 때문에 실험 환경에서나 실제 생산 프로세스에서 같은 실험을 하고 같은 결과를 얻을 수 있게 된다. 실험은 다 통과했는데 실제 출시된 제품 및 서비스에서 오류가 발생해 리콜을 한다거나 롤백을 해야 하는 리스크가 크게 줄어든다는 것이다. 실험 환경이나 실제 생산 환경을 같게 만들어 실험을 최대한 ‘진짜처럼’ 할 수 있게 해주는 것이 콘테이너의 가장 큰 장점이다. 그러므로 실험 후 실제 생산 및 서비스 배포에 차질이 줄어든다. 시스템 관리자의 역할 역시 줄어들긴 마찬가지다.
챗 봇 : 시스템 관리자라고 서버실 내 24시간 365일 살 수도 없는 노릇인데, 하필 자리를 잠깐 비운 고 사이에 윗선과 아랫선에서 작업 요청 전화가 참 많이도 오는 것이 일상다반사였다. 그래서 등장한 것이 휴봇(Hubot)과 같은 챗 봇이다. 시스템 관리자에게 물어야 할 것들을 챗 봇을 통해 물을 수 있게 되었으며, 앞으로 인공지능까지 탑재해 자연어로 대화까지도 나누는 것은 물론 각종 사태를 학습해 최적의 해결책을 내놓을 전망이다. 시스템 관리자가 갑작스럽게 스케줄 조정을 하지 않아도 되게끔 돕는 역할을 넘어, 아예 그 자리를 빼앗지 않을까 한다.
위 세 기술이 발전하면 할수록 24시간 항시 지원과 줄어든 리스크를 누릴 수 있게 될 전망인데, 일반 임직원들이 가장 반기는 건 ‘시스템 관리자에게 아쉬운 소리를 하지 않아도 된다는 것’이다. 그밖에도 다음 기술이나 개념들의 등장으로 시스템 관리자 축출 속도는 더욱 빨라지고 있다.
마이크로서비스 : 거대한 하나의 수직 구조로 되어 있는 클라이언트-서버 애플리케이션들은 천천히 사라지고 있다. 서버에 부담을 줄 수밖에 없는 ‘수직적인 확장’ 대신 경제적인 ‘수평 확장’이라는 개념을 기반으로 한 클라우드 인프라가 널리 활용되고 있기 때문이다. 이 ‘수평적 확장’을 가능하게 하는 게 바로 마이크로서비스라는 개념이다.
마이크로서비스는 여러 기능을 가진 대형 애플리케이션을 통째로 만드는 것과 반대로, 한두 가지 기능을 수행하는 작은 ‘부품’들을 조립해 커다란 애플리케이션을 만드는 것으로, 개발 및 출시 속도가 중요한 현재 IT 시장에서 당연히 나타나 정착될 수밖에 없는 개념이었다. 이때 작은 ‘부품’에 해당하는 프로그램이나 코드들을 조립하는 역할 역시 개발자가 할 수밖에 없어 시스템 관리자의 지위는 상대적으로 더 낮아지게 되었다. 마이크로서비스 방식으로 개발을 하는 업체는 데브옵스(DevOps)를 많이 차용하는데, 데브옵스 구조는 관리자에 대한 의존도가 극히 낮은 것이 특징이기도 하다.
데브옵스 : 이제 IT 업계 누구나 아는 용어처럼 굳어져버린 데브옵스는 시스템 관리자의 역할을 크게 감소시킨 장본인이다. 작은 모듈들을 빠르게 가져다 붙이고, 그 과정에서 취약점들을 더 빠르고 즉시적으로 점검, 보완할 수 있기 때문에 중앙에서의 관리하는 기능이 소멸되다시피 했다. 사실 중앙 관리 기능뿐 아니라 ‘개발’을 둘러싼 전통의 기업 문화를 통째로 바꾸고 있는 게 바로 데브옵스다.
시스템 관리자의 역할, 어떻게 바뀌나?
여기서 기고를 끝낼 수도 있었지만, 시스템 관리자들의 원성이 높을 거 같아 이들의 새로운 역할에 대해서 몇 줄 첨가하고자 한다. 시스템 관리자들은 앞으로 실업자가 될까? 솔직히 말하자면, 기업들이 시스템 관리자 부문의 고용인원을 늘릴 것 같지 않다. 차세대 네트워크 환경에서는 개발자들이 이 역할을 대부분 담당할 수 있기 때문이다.
반대로 말하자면 시스템 관리자가 이제는 필수적으로 코딩을 배워야 한다는 뜻으로 해석이 가능하다. 개발팀과 관리팀이 하나로 합쳐질 것이 거의 분명하고, 돌아가는 상황 상 개발 능력이 조금은 더 요구 되는 것이 사실이다. 시스템 관리자라는 직책은 유지될 지도 모르나, 필요한 기술과 툴셋은 전혀 달라질 것이다.
글 : 산토시 발란(Santosh Balan)
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
