Redundancy는 잉여가 아니다
적어도 Engineering에서는. 그렇다면 Engineer는?
Redundancy는 단순한 잉여가 아니다. 적어도 Engineering에서는. 그렇다면 Engineer는?
redundancy의 사전적인 뜻은 여분이다. 근데 영국에서는 정리해고라는 뜻으로도 사용된다고하고 구글의 이미지 검색 결과도 온통 인원감축에 대한 이야기뿐이다.
the state of not being necessary or useful
엔지니어링에서 redundancy는 조금 다른 의미로 사용된다. 사전에서는 예비 추가 구성품 정도로 설명하고 있다.
the inclusion of extra components which are not strictly necessary to functioning, in case of failure in other components.
기능적으로 당장 꼭 필요로하는 요소는 아니지만 다른 요소에 문제가 생겼거나 오류가 발생했을 때, 정상적으로 동작하도록 하기 위해서 사전 예비로 준비하는 요소를 뜻하는 것이다.
NAS와 RAID
네트워크와 스마트폰이 급속도로 발전하면서 개인 휴대폰에서 대용량의 컨텐츠를 사용하는 일이 많아졌다. 음악이나 영상 같은 컨텐츠를 보다 쉽고 안전하게 관리하기 위해서 휴대폰에 저장하기보다는 클라우드 서비스를 이용하는 사용자가 늘어나게 되었는데, 이때 컴돌이 형들은 클라우드를 직접 클라우드를 대체할만한 네트워크 스토리지 즉, NAS를 구축해서 사용했다. NAS는 HDD와 같은 저장장치를 이용해서 집안에 서버처럼 구축해두고 자신만의 클라우드 서비스를 만드는 것과 비슷하다.
스토리지 관리만하기 때문에 서버처럼 대용량의 컴퓨팅 파워나 전력을 소모하는 것이 아니고, 전기 요금이외에 별도의 추가 비용이 들지 않기 때문에 클라우드보다 훨씬 싸게 클라우드 스토리지 서비스를 대체할 수 있다.
물론, 관리비용까지 생각하면 어쩌면 클라우드가 더 저렴할 수 있다. 하지만 컴돌이 형들이 돈 때문에 NAS를 만드는 것은 아니다. 우리 형들은 자기가 구축하고, 자기 손으로 직접 관리하는 것을 더 선호하기 때문에 LED를 깜박이며 우웅~ 돌아가는 NAS 본체를 보고 희열을 느낀다.
NAS를 구축할 때 결정하고 사용해야 할 것이 바로 RAID 기술이다. RAID Redudant Array of Independent/Inexpensive Disk의 첫단어가 바로 우리가 이야기하고 있는 Redundancy와 관련이 있다. 간단하게 설명하자면 디스크 여러개를 사용해서 스토리지를 구성하는 것인데, 이때 여러개의 디스크를 하나의 논리적 디스크로 작동하게 하는 기술이다.
RAID는 디스크를 구성하는 방법에 따라서 레벨로 구분을 한다. 레이드 레벨 0은 데이터를 단순하게 분리해서 저장하는 방식이며, 단순하게 분리되어 있기 때문에 많은 저장공간을 확보할 수 있지만 오류가 발생할 경우 데이터를 손실될 위험이 크다. 레이드 레벨 1은 디스크를 둘로 나눠서 데이터를 양쪽에 동일하게 저장한다. 저장공간은 반으로 줄어들게 되지만 한쪽에 데이터에 오류가 발생해도 다른 하나를 사용할 수 있기 때문에 디스크 오류 문제에 대처할 수 있다. 레이드 레벨은 0과 1만 있는 것이 아니다 패리티 비트를 사용해서 여러개의 디스크에 오류 검출 및 복구를 위한 데이터를 저장하는 방법에 따라서 구분되는 다른 레벨도 있다. 레벨 5는 3개의 디스크에는 데이터를 나눠서 저장하고 1개의 디스크는 패리티 비트를 저장하는 것이며, 레벨 6은 2차 패리티 비트를 구성해서 저장하는 방식이다.
패리티비트는 오류 검출 코드로 전달 받은 데이터의 1비트의 모든 숫자가 짝수인지 홀수인지 구분하여 추가되는 비트로써 전체 데이터에 오류가 있는지 확인 할 수 있는 방식이다. 오류를 검출하기 위한 용도이지만 디스크에 오류가 생겨서 읽기가 불가능한 경우 해당 디스크에 저장된 비트를 확인할 수 있기 때문에 RAID에서는 디스크의 오류에 따른 비트를 복구하기 위해 사용할 수 있다. 단, RAID 레벨 5의 경우 패리티비트 1개를 추가로 저장하고 있으므로 디스크 1개의 오류만 복구 할 수 있다. 2개 이상의 디스크 오류를 대응하기 위해서는 레벨 6을 사용하거나 복합적으로 구성이 필요하다.
Disaster Recovery
얼마전에 있었던 카카오톡 판교 IDC 장애문제로 잠깐이나마 핫 이슈가 된것이 있었으니, 재난에 의해서 시스템에 문제가 생겼을 때 시스템을 복구하는 Diaster Recovery, DR이라고 불리는 기술이다. 재난에는 여러가지 종류가 있다. 지진이나 홍수와 같은 자연적인 재난도 있고, 전력 공급에 문제가 있거나 네트워크 설비에 문제가 생기는 기술적인 재난도 있으며 사람에 의해 발생하는 소위 말하는 인재도 재난으로 분류할 수 있다.
RAID에서 레벨에 따라 디스크의 오류에 대응하는 다양한 방법을 고안했던 것처럼 클라우드 시스템 엔지니어링에서도 재난을 대비하는 여러가지 방법이 사용된다.
DR에서 두가지 중요한 지표가 있는데, 복구되는 시스템과 데이터의 기준시점이 재난시점과 얼마나 떨어져있는지 판단하는 재난 복구 시점 목표RPO과 복구에 걸리는 소요 시간이 얼마나 되는지 판단하는 재난 복구 시간 목표 RTO가 있다. 당연한 이야기이지만, RPO, RTO의 기준을 어떻게 설정할 것인지에 따라서 시스템의 구성이 달라진다.
장애가 발생했을 때 빨리 복구하기 위해서 주요 데이터베이스를 실시간으로 복제하고 있는 것은 물론이고, 서버 역시 복제본을 준비해서 문제가 발생한 서버와 데이터 베이스를 빠르게 교체하여 시스템을 정상화하는 전략을 사용한다. 서버와 데이터 베이스에 국한 되는 것이 아니라, 전력, 네트워크 등의 다양한 부분에서 대비가 필요하고, 이렇게 준비된 여분의 시스템을 Redundancy라고 한다.
SW Engineer의 Redundancy
안정성을 갖춘 NAS를 위해서는 반드시 Redundancy가 필요하다. 잘 설계된 시스템은 당연히 Redundancy를 고려하고 있으며, 장애와 재난에 대해서 대비하고 있다. Engineering에서 Redundancy는 단순한 잉여가 아니다. 계획된 헤드룸이고, 준비된 범퍼이고, 계산된 마진이다.
그렇다면, SW Engineer도 Redundancy가 필요할까? 물론이다. 개발 중에도 필요하고, 개발이 완료된 후에도 필요하다.
SW Engineer의 Redundancy를 추가 가용 인력 정도로 정의하고 이야기를 시작해보자.
SW 개발 중에 추가 가용 인력이 왜 필요한지는 굳이 말할 필요가 없을 정도로 당연한 상식일 것이다. 단순히 예비 인력이 필요하다는 뜻이 아니다. SW는 변경이 아주 많은 제품이다. 이름 자체가 변경 가능한 Soft한 것임을 나타내듯이, 출시 직전까지도 제품은 끝 없이 변경되고, 심지어 출시 이후에도 제품은 계속 변경되어 업데이트 된다.
모든 개발자들은 변경에 빠르게 대응하기 위해 모든 순간 노력하지만 대응이 쉽지 않을 때도 많다. 그리고 기능적으로 변경이 완료된 것처럼 보이지만 임시 코드와 구조를 사용해서 기술적 부채를 안고 개발이 진행될 때도 많다. 인력이 여유가 있다면 팀에서 변경에 보다 빠르게 대처할 수 있을 뿐만 아니라 지속적으로 기술적 부채를 갚아가면서 프로젝트를 진행함으로써 보다 안정적이고 뛰어난 성능의 제품을 개발할 수 있다.
개발이 완료된 후에도 추가 가용 인력이 필요하다. 대부분의 SW는 살아있는 시스템처럼 계속 업데이트가 이뤄진다. 요구사항이나 사용 환경의 변화에 대응하기도 하고 때로는 자체 결함을 해결하기 위해서 지속적으로 업데이트를 해야한다. SW 개발은 단편적으로 제품을 생산해 내는 것 이상으로 마치 서비스와 같다. 당연히 출시 이후에도 SW Engineer는 SW를 개선하고, 변경하고 관리하는 역할을 수행해야 한다. 하지만 비용 때문에 여기에 충분한 인력이 배치되지 못하는 경우가 허다하다.
제품을 유지보수하면서 업데이트하는 과정을 통해서 안정적으로 서비스를 제공할 수 있고, 심지어 그 과정에서 발굴되는 가치가 처음 기획했던 것 이상으로 고객에게 만족을 가져다 줄 수 있는 것이 SW 제품이다. 따라서 이 때 가용 인력은 단순히 문제를 대응하는 인력이 아니다. 새로운 기회를 창출할 수도 있고, 치명적인 문제점을 사전에 보완 할 수도 있는 막중한 임무를 갖고 있는 것이다. 하지만, 우리나라에서는 아직도 출시를 가장 큰 업적으로 평가하기에 대기업에서도 유지보수나 관리에는 관심을 주지 않고, 당연히 인력도 최소한으로 운영하고, 심지어 외주를 준다거나 사기가 바닥인 인력을 모아서 유지보수 팀을 구성하기도 한다.
SW Engineer의 Redundancy는 단순한 잉여가 아니다. RAID나 DR에서처럼 단순히 대기하고 있는 예비 리소스가 아니다. SW Engineer는 항상 충분한 가용인력을 두어야 한다. 그리고 그들이 새로운 기술을 습득하고, 기회를 모색하고, 기존 시스템을 지속적으로 개선할 수 있도록 열정과 기회를 제공해야 한다. 그러한 자극을 위해서 글로벌 SW 기업에서 기술 블로그를 운영하고, 내부 개발자간의 교류를 확대할 뿐만 아니라 공개적으로 개발자 컨퍼런스를 열어서 개발자들이 직접 기술을 뽐낼 수 있는 자리를 마련해 주는 것이다.
프로젝트 리더는 단순히 인력을 줄일 생각을 하기보다는 적절한 인력으로 팀을 구성했는지 먼저 돌아봐야 하고, 그 인력들이 충분히 동기부여가 되었는지 살펴보는 것이 더 중요하다. 그리고 SW Engineer에게 기술 습득과 개인 능력 향상에 기회를 부여하면서 자발적으로 프로젝트의 기술 부채를 해결하고, 프로젝트에 다양한 접근 방법을 적용해볼 수 있도록 장려해야 한다. SW 품질의 일부분은 온전히 SW Engineer라는 지식 노동자의 직업 정신과 실력에 의존하기 때문이며, 따라서 Redundancy를 어떻게 구성하고 운영할 것인지가 결국 팀과 프로젝트의 성공에 큰 영향을 미치게 된다는 것을 잊어서는 안된다.
