박희범 아크서브코리아 상무

▲ 박희범 아크서브코리아 상무


[컴퓨터월드] 혹시 아직도, 자신이 천재가 아닐까 하는 분이 있을까 하는 생각에 진짜 천재 이야기를 하나 소개한다.

존 폰 노이만 박사는 세계적인 수학자이자 초기 컴퓨터 이론 발전에 지대한 공헌을 한 사람이다. 특히 악마적인 기억력으로 유명했다. 브리태니커 사전 전집 내용을 오탈자까지 하나 틀리지 않고 문자와 그림 모두 그대로 기억하고 있었다고 한다. 종종 파티에서 박사를 둘러싸고 브리태니커 사전을 펼쳐서 몇 페이지부터 몇 페이지까지 외워 달라고 조르는 일도 있었다고 전해진다.

초기 컴퓨터는 이진수로 된 기계어 코드로 작동했는데, 어느 날 박사의 조수가 도저히 1과 0으로 된 기계어를 기억할 수가 없어서, 몰래 어셈블리 테이블을 만들었다고 한다. 기계어 코드와 1:1로 대응하는 일종의 니모닉(MNEMONIC)으로 심볼 테이블을 작성한 것이었다. 아마 최초의 어셈블리어일 것이다.

조수는 그걸 이용해서 프로그램을 개발했다. 그런데 어느 날 그만 작업 중에 노이만 박사에게 들키고 말았다. 박사는 조수를 아주 호되게 야단쳤다. “도대체, 그게 몇 개나 된다고 그걸 기억 못해서, 바보같이 이런 테이블을 만들어 놓고, 그걸 하나씩 변환하는 불필요한 작업을 하는거야?” 브리태니커 사전을 통째로 외우는 사람에겐 그게 바보 같고 불필요한 일이었겠지만, 우리 같은 보통 사람에겐 그런 도구가 없으면 작업 자체가 고통스럽다는 것을 박사 같은 천재들은 정말 이해를 못 했던 것 같다.

존 폰 노이만 박사의 일화 중에서 가장 압권은, 6살때의 일이다. 겨우 6살짜리가 8자리 숫자의 나눗셈을 암산으로 할 수 있었다고 한다. 그런데 어느 날 엄마가 허공을 멍하니 바라보는 것을 보고는 폰 노이만이 엄마에게 물었다. “엄마, 지금 뭘 계산하시는 거에요?” 남들도 다 자기처럼 암산하는 중으로 안거다. 엄마는 그냥 멍 때린 것 뿐인데…


소프트웨어 품질평가에 대한 국제표준

위의 일화에서 알 수 있는 내용은 많은 사람들이 천재든 아니든 자신의 관점에서 사물을 바라보며 현상을 이해하려고 한다는 것이다.

소프트웨어의 오류/결함(Error/Defect)을 통한 ‘버그(Bug)’라고 한다. ‘벌레’라는 뜻이다. 그 이유는 자못 역사적(?)이다. 프로그래밍 언어 COBO의 어머니이자 전설적인 프로그래머였던 그레이스 호퍼(Grace Hopper)가 1947년 초창기 전자계산기의 모델 중 하나인 MARK II의 오동작 원인을 찾던 중 발견한 ‘나방(MOTH)’이 그것이다.

그 이후로 컴퓨터 프로그램의 오류를 찾아서 제거하는 작업인 ‘디버깅(DEBUGGING)’이라는 용어가 사용되기 시작한 것이다. 재미있는 얘기이기는 하지만 이것 때문에 소프트웨어 결함과 오류를 나타내는 말을 ‘버그’라는 귀엽고도 낯선 전문용어로 부르면서 실수와 착오를 부드럽게 포장하는 경향이 생긴 건 아닌지 의구심이 든다.

소프트웨어의 품질과 연관된 얘기라면 빠질 수 없는 것이 소프트웨어 품질평가에 대한 국제표준(ISO 9126)이며 여기에서는 다음 6가지 요소를 제시한다.

1. 기능성
2. 신뢰성
3. 사용성
4. 효율성
5. 유지보수성
6. 이식성

모두 좋은 얘기이다. 중요한 순서를 생각해보니, 위에 나열한 순서가 대략 맞는 것같다. 기능성이 제일 중요하다. 뭔가 유용해야 하니까. 그 다음, 신뢰성이다. 원하는 대로 오류 없이 잘 작동되어야 한다. 그 다음은 사용성. 사용하기 편해야 한다. 그리고 효율성. 너무 자원이 낭비되면 안 된다. 속도로 빨라야한다. 적은 메모리와 CPU 자원을 소모해야 한다. 마지막 유지보수성과 이식성이 좋으면 정말 좋다.

많은 기업의 운영자들이 관리하는 시스템을 보면 메인프레임, 유닉스, x86 기반의 리눅스(Linux), 윈도우(Windows) 운영체제이다. 아직까지는 일부 산업계에서 여전히 유닉스 플랫폼을 운영하고 있지만 많은 선도적인 기업은 x86 기반의 리눅스(Linux)/윈도우(Windows) 운영체제로 플랫폼을 전이했으며 계속 추진 중이다.

메인프레임은 이미 많은 고객들이 유닉스로 다운사이징을 했으며, 최근까지 메인프레임을 운영하던 고객은 x86기반의 리눅스로 다운사이징을 하면서 메인프레임은 서서히 사라져 가고 있는 것을 볼 수 있다. 한때 메인프레임 시장과 유닉스 시장에서 툴(TOOL) 분야의 선도적인 기업이었던 CA Technologies가 약 21조 3,000억 원에 브로드컴에 인수된다는 기사를 접하면서 기업이 운영하는 플랫폼의 변화가 이러한 소프트웨어 솔루션 기업의 생사에까지 영향을 미치는 것을 실감할 수 있었다.
 

멀티 백업 대상에 멀티 백업 에이전트

운영자들이 관리하는 시스템(흔히 서버라고 부름)은 크게 4가지 레이어로 나눌 수 있다. 운영체제, 파일 데이터, 데이터베이스 데이터, 애플리케이션 등이 그것이다. 애플리케이션에는 기업의 비즈니스 로직이 담겨져 있으며 수많은 비즈니스 데이터를 산출하는 역할을 한다.

▲ 운영자들이 관리하는 시스템의 4가지 레이어

흔히들 일반적으로 백업을 한다고 하면 파일 데이터, 데이터베이스를 백업하는 것을 의미해 왔다. 여기서 ‘백업’에 대한 정의가 필요한데 백업의 정의는 다음과 같다.

백업이란, 데이터의 논리적/물리적 장애를 대비하여 운영데이터를 제2의 저장소, 또는 제3의 저장소에 복사본을 저장하여 두는 것을 의미하며, 백업 주기와 보관 주기에 따라서 백업 이미지를 관리한다.

그리고 흔히들 많은 사람들이 백업과 아카이빙 그리고 복제 개념에 대한 혼선을 가지고 있는데 ‘아카이빙’과 ‘복제’의 정의는 다음과 같다.

1. 아카이빙: 데이터의 중/장기 기간동안 운영매체가 아닌 다른 비용 효율적인 매체에 이동을 해 두었다가 특별한 목적을 위해 조회할 수 있는 시스템을 구성하기 위해 운영데이터를 제2 또는 제3의 매체로 이동 저장한다. 여기에서는 아카이빙 데이터의 손쉬운 조회와 CONTEXT 수준의 신속한 조회를 위한 메타데이터 관리를 필요로 한다.

2. 복제: 흔히들 ‘백업’과 혼돈을 하고 있는 용어이기도 하다. 복제는 로컬 사이트 또는 원격지 사이트에 동일한 운영데이터를 별도의 매체에 복사해 두었다가 운영데이터 유실/손실 시 바로 접근하여 서비스를 재개 할 수 있는 장점을 가지고 있다. 그러나 운영데이터와 실시간으로 복사되고 있어서 바이러스가 침투되거나 논리적인 장애에 대한 대비는 없는 것이다.

백업/아카이빙/복제는 구분되어 구축되어야 한다. 일반적으로 데이터의 종류 및 기업의 SLA(Service Level Agreement)에 따라서 적용된다. 메인프레임 중심의 플랫폼에서 유닉스 플랫폼으로 전환되면서 대다수의 기업이 구축하여 운영하던 백업 아키텍처를 ‘러거시 백업 아키텍처’라고 하는데 일반적으로 레거시 백업의 경우 파일 백업 에이전트, 데이터베이스 에이전트 및 다양한 형태의 에이전트를 별도로 설치해 운영해야 했다. 물론 통합 관리를 위하여 백업 서버를 별도로 구축해야 했다.

1. 파일 백업 에이전트: 운영체제 파일 시스템의 파일 데이터 백업을 위해 별도로 설치되는 에이전트
2. 데이터베이스 백업 에이전트: Oracle, My-SQL, MS-SQL 등 다양한 온라인 트랜잭션 데이터베이스를 백업하기 위해 별도로 설치되는 에이전트
3. 운영체제 백업 에이전트: Windows, Linux, Unix 등 다양한 운영체제의 온라인 백업을 하여 동일한 기종 또는 다른 서버에 운영체제 복구를 하기 위해 별도로 설치되는 에이전트
4. 애플리케이션 백업 에이전트: ERP, SharePoint Server, Exchange 등 다양한 애플리케이션의 온라인 백업을 위한 별도로 설치되는 에이전트

백업 시스템을 구축하고 운영하면서 백업 에이전트의 ‘운영 자원의 점유율’과 ‘백업 윈도우(Backup Windows)’를 고려해야 한다. 이 두 가지는 모두 기업 운영 시스템의 자원 소모와 제한된 운영 시간 자원을 소모하는 요소로 재 정의할 수 있다.

간단하게 생각 해 보자. 중요한 데이터베이스 서비스를 운영하고 있다고 가정하면, 파일 백업과 데이터베이스 및 운영체제 백업을 위해 최소한 3가지 종류의 에이전트를 설치해야 한다. 그리고 각 에이전트가 평균 5%의 시스템 운영자원을 사용한다면 최대 15% 정도의 기업 운영시스템 자원이 백업을 위해 소모된다고 할 수 있다. 그리고 야간에 백업 작업을 수행한다면, 파일 백업을 위한 정책(스케줄), 데이터베이스 백업을 위한 정책(스케줄)과 운영체제 백업을 위한 정책(스케줄)을 한 개의 서버 내에서 최소 3가지 종류의 백업 정책으로 스케줄 해야 한다. 이러한 시스템이 100대일 경우 최소 300개 이상의 정책(스케줄)이 적용되어야 한다.

보통 U2L(Unix to Linux)로 다운사이징 한 기업은 최소 500대에서 3,000여대 이상의 서버를 운영하고 있다. 이러한 기업이 기존 레거시 방식의 백업 정책을 고집한다면 구축하자마자 다양한 이슈에 마주칠 것이다.

아래 그림은 약 100대 시스템을 위한 XX 기업의 레거시 백업의 진단을 했을 때, 백업 대기시간 현황을 보여주고 있다. 다양한 오브젝트 백업을 위해, 그리고 다수의 백업 정책을 적용하기 위해 ‘백업 대기 시간’이 매우 길다는 것을 알 수 있다.

▲ 백업 대기시간 현황


멀티 백업 대상에 단일 백업 에이전트

아크서브사의 Arcserve UDP는 단일 백업 에이전트로 구축 및 운영이 가능하다. 최근 X86서버 환경의 물리 및 가상화 환경에서 백업 시스템을 구축하기 위해서는 기존의 레거시 백업 아키텍처를 아무 고민 없이 기존의 운영환경을 유지하기 위한다는 명목을 내세워 여전히 UNIX 플랫폼 환경에서 운영되던 레거시 백업 솔루션을 도입하고 있는 것이 현실이다.

그러나 x86 환경에서는 다른 접근 방법을 가져야한다. 대용량의 파일 백업을 위해 파일 단위의 레거시 백업은 여전히 해결해야 할 문제가 있으며, 최근 트렌드인 이미지 백업으로 구축 되면 그동안의 고민은 전혀 고민이 아닌 당연한 일이 될 것이다. 또한 단일 에이전트로 구축 되는 최근 트렌드의 백업 아키텍처는 단일 에이전트를 통해 운영서버 자원 사용율을 최소화 하며, 단순한 ‘백업 윈도우(Backup Windows)’ 정책을 지원하게 된다.

▲ 과거와 현재의 백업

Arcserve UDP의 단일 백업에이전트는 이미지 백업을 가능하게 하며, 단일 파일/폴더 및 데이터베이스 그리고 단일 이메일 단위의 논리적인 단위로 복원이 가능하다. 기업이 운영하고 있는 물리/가상화 환경에서 이 모든 기능이 가능하다. 백업은 리스토어 과정이 절대적으로 필요하지만 Arcserve UDP는 리스토어 과정 없이 백업 이미지를 파일시스템에 직접 마운트하여 파일을 접근하거나 가상화 시스템에 즉시 VM(Guest OS)으로 재 시작할 수 있어서 고 가용 서비스 수준을 제공한다. 한마디로 One Source, Multi-Use하게 하는 단일 솔루션이다.

저작권자 © 컴퓨터월드 무단전재 및 재배포 금지