잉여인간, Redundancy
SW Engineer에 잉여 인간이란 없다
redundancy의 사전적인 뜻은 여분, 중복, 과잉을 나타내며, 실제로는 다소 부정적인 의미로 많이 사용되는 것 같다. 영국에서는 정리해고라는 뜻으로도 사용된다고 하고 구글의 이미지 검색 결과도 온통 인원 감축에 대한 이야기뿐이다.
a situation in which someone loses their job because their employer does not need them. - Cambridge Dictionary
구글의 이미지 검색 결과뭔가 불필요한 낭비 요소가 있고, 비효율적이고, 정리가 필요한 것 같은 느낌을 풍기지만, 엔지니어링에서 redundancy는 막연히 부정적으로 사용되기보다는 오히려 일정 부분 필요한 요소로 여겨진다. 사전에서는 안정적 시스템 구축을 위한 추가 예비 구성품 정도로 설명하고 있다.
In engineering and systems theory, redundancy is the intentional duplication of critical components or functions of a system with the goal of increasing reliability of the system - 위키백과
기능적으로 당장 꼭 필요로 하는 요소는 아니지만 다른 요소에 문제가 생겼거나 오류가 발생했을 때, 정상적으로 동작하도록 하기 위해서 사전 예비로 준비하는 요소를 뜻하는 것인데, 몇 가지를 예를 들어 이야기해보자.
NAS와 RAID
네트워크와 스마트폰이 급속도로 발전하면서 개인 휴대폰에서 대용량의 콘텐츠를 사용하는 일이 많아졌다. 음악이나 영상 같은 콘텐츠를 보다 쉽고 안전하게 관리하기 위해서 휴대폰에 저장하기보다는 클라우드 서비스를 이용하는 사용자가 늘어나게 되었는데, 컴퓨터 잘하는 덕후들은 직접 클라우드를 대체할만한 네트워크 스토리지 즉, NAS를 구축해서 사용한다. 클라우드 서비스의 요금이 부담되기도 하지만 무엇보다 직접 시스템을 만들고 운영하고 싶은 덕후력이 충만하기 때문이다.
NAS는 HDD와 같은 저장장치를 이용해서 집안에 서버처럼 구축해 두고 자신만의 클라우드 서비스를 만드는 것과 비슷하다. 스토리지 관리만 하기 때문에 서버처럼 대용량의 컴퓨팅 파워나 전력을 소모하는 것이 아니고, 전기세 이외에 별도의 요금이 들지 않기 때문에 클라우드보다 훨씬 싸게 클라우드 서비스를 이용할 수 있다. 물론, 관리비용까지 생각하면 어쩌면 클라우드가 더 저렴할 수 있다는 것이 함정이지만, 앞서 말했듯이 덕후들은 자기가 구축하고, 자기 손으로 직접 관리하는 것을 더 선호하기 때문에 LED를 깜박이며 우웅~돌아가는 NAS 본체를 보고 희열을 느낀다.
NAS를 구축할 때 구성 방법을 결정하고 사용해야 할 기술 중 하나가 RAID 기술인데, RAID Redudant Array of Independent/Inexpensive Disk의 첫 단어가 바로 우리가 이야기하고 있는 Redundancy와 관련이 있다. 간단하게 설명하자면 디스크 여러 개를 사용해서 스토리지를 구성하는 것인데, 이때 여러 개의 디스크를 하나의 논리적 디스크로 작동하게 하는 기술이 바로 RAID인 것이다.
RAID는 디스크를 구성하는 방법에 따라서 레벨로 구분되는데, 레이드 레벨 0은 데이터를 단순하게 분리해서 저장하는 방식이며, 단순하게 분리되어 있기 때문에 많은 저장공간을 확보할 수 있지만 오류가 발생할 경우 데이터를 손실될 위험이 크다. 레이드 레벨 1은 디스크를 둘로 나눠서 데이터를 양쪽에 동일하게 저장한다. 저장공간은 반으로 줄어들게 되지만 한쪽에 데이터에 오류가 발생해도 다른 하나를 사용할 수 있기 때문에 디스크 오류 문제에 대처할 수 있다. 레이드 레벨은 0과 1만 있는 것이 아니다 패리티 비트를 사용해서 여러 개의 디스크에 오류 검출 및 복구를 위한 데이터를 저장하는 방법에 따라서 구분되는 다른 레벨도 있다. 레벨 5는 3개의 디스크에는 데이터를 나눠서 저장하고 1개의 디스크는 패리티 비트를 저장하는 것이며, 레벨 6은 2차 패리티 비트를 구성해서 저장하는 방식이다.
갑자기 훅 들어오는 레이드 레벨에 대한 설명이 당황스럽겠지만, 중요한 것은 여분의 디스크를 준비해서 데이터를 보다 안정적으로 저장하고 유지한다는 개념이고 이 과정에서 디스크 공간이 더 많이 필요하게 되고, 디스크를 읽고 쓰는데 더 많은 시간이 소요된다는 것이다. 안정성을 위해 합의된 성능과 비용에 대한 일종의 타협과도 같다.
Disaster Recovery
2022년 10월 있었던 SK C&C 판교 데이터센터의 카카오톡 판교 IDC 장애문제로 잠깐이나마 핫이슈가 된 기술이 있었으니, 재난에 의해서 시스템에 문제가 생겼을 때 시스템을 복구하는 DR Diaster Recovery이라고 불리는 기술이다. 재난에는 여러 가지 종류가 있다. 지진이나 홍수와 같은 자연적인 재난도 있고, 전력 공급에 문제가 있거나 네트워크 설비에 문제가 생기는 기술적인 재난도 있으며 사람에 의해 발생하는 소위 말하는 인재도 재난으로 분류할 수 있다.
앞서 RAID에서 레벨에 따라 디스크의 오류에 대응하는 다양한 방법을 고안했던 것처럼 클라우드 시스템 엔지니어링에서도 재난을 대비하는 여러 가지 방법이 사용된다. DR에서 두 가지 중요한 지표가 있는데, 복구되는 시스템과 데이터의 기준시점이 재난시점과 얼마나 떨어져 있는지 판단하는 재난 복구 시점 목표 RPO과 복구에 걸리는 소요 시간이 얼마나 되는지 판단하는 재난 복구 시간 목표 RTO가 있다. 예를 들어 내가 핸드폰의 사진을 하루에 한 번씩 PC로 백업한다고 할 때, 핸드폰을 분실했을 때 RPO는 최대 하루가 될 것이고, RTO는 내가 새로운 폰을 마련해서 PC의 사진을 다시 옮겨놓아 이전처럼 핸드폰으로 찍어둔 사진을 볼 수 있게 되는 데까지 걸리는 시간이다.
재해 복구(DR) 목표안정성 원칙, 재해복구 목표 - https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html
당연한 이야기이지만, RPO, RTO의 기준을 어떻게 설정할 것인지에 따라서 시스템의 구성이 달라진다. 보통 상용 서비스들은 장애가 발생했을 때 빨리 복구하기 위해서 주요 데이터베이스를 실시간으로 복제하고 있는 것은 물론이고, 서버 역시 복제본을 준비해서 문제가 발생한 서버와 데이터 베이스를 빠르게 교체하여 시스템을 정상화하는 전략을 사용한다. 서버와 데이터 베이스에 국한되는 것이 아니라, 전력, 네트워크 등의 다양한 부분에서 대비가 필요하고, 이렇게 준비된 여분의 시스템을 Redundancy라고 한다.
2022년 화재 사고에 대해서 카카오에서는 본인들의 문제점을 분석해서 공개했다. 어느 정도 예상된 내용이지만, DR 시스템 구성이 미비했고, 특히 데이터 센터 간 Redundancy가 부족했던 것 같다. 자세한 내용은 카카오가 홈페이지에 공개한 내용을 확인할 수 있다.
우리가 부족했던 이유 - https://www.kakaocorp.com/page/detail/9902SW Engineer의 Redundancy
안정성을 갖춘 NAS를 위해서는 반드시 Redundancy가 필요하다. 잘 설계된 시스템은 당연히 Redundancy를 고려하고 있으며, 장애와 재난에 대해서 대비하고 있다. Redundancy는 단순한 잉여가 아니다. 계획된 헤드룸이고, 준비된 범퍼이고, 계산된 마진이다.
그렇다면, SW Engineer도 Redundancy가 필요할까? 물론이다. 개발 중에도 필요하고, 개발이 완료된 후에도 필요하다.
가끔 소수의 개인기에 크게 의존하는 프로젝트에서 그 담당자가 갑작스럽게 자리를 비우게 되어서 위기를 맞는 경우를 목격하기도 하고, 그런 사태를 미리부터 준비하고 싶어서 컨설팅을 요청하는 경우도 있다. 기술적으로 그리고 프로세스적으로 준비할 것을 강조하지만, 동시에 추가 가용 인력을 확보할 것을 권장한다. 혼자 할 수 있는 일 2개를 두 명이서 각각 따로 하고 있다면, 둘이서 함께 2개의 일을 담당할 것을 권장한다. 소프트웨어 업무의 특성상 자동차 공장 컨베이어 벨트처럼 일이 정해진 주기에 맞춰서 들어오지 않을 뿐만 아니라 확장하고 유연하게 대처해야 하는 경우가 많기 때문이다.
제품 개발 중에 추가 가용 인력은 단순히 예비 인력이 필요하다는 뜻이 아니다. SW는 변경이 아주 많은 제품이다. 이름 자체가 변경 가능한 Soft 한 제품임을 나타내듯이, 출시 직전까지도 제품은 끝없이 변경되고, 심지어 출시 이후에도 제품은 계속 변경되어 업데이트된다. 모든 개발자들은 변경에 빠르게 대응하기 위해 모든 순간 노력하지만 대응이 쉽지 않을 때도 많다. 그리고 기능적으로 변경이 완료된 것처럼 보이지만 임시 코드와 구조를 사용해서 기술적 부채를 안고 개발이 진행될 때도 많다. 이때 최소한의 가용 인력이 있다면 팀에서는 변경에 보다 빠르게 대처할 수 있을 뿐만 아니라 동시에 지속적으로 기술적 부채를 갚아가면서 프로젝트를 진행함으로써 보다 안정적이고 뛰어난 성능의 제품을 개발할 수 있다. 즉, 추가 가용 인력이라고 해서 유휴 인력처럼 할 일 없이 대기 상태로 있는 것이 아니라 미래에 진행돼야 할 일들을 먼저 진행하거나, 직접적으로 문제 대응에 투입되어 활용되는 것이다.
그리고 개발이 완료된 후에도 추가 가용 인력이 필요하다. 대부분의 SW는 살아있는 시스템처럼 계속 업데이트가 이뤄진다. 요구사항이나 사용 환경의 변화에 대응하기도 하고 때로는 자체 결함을 해결하기 위해서 지속적으로 업데이트를 해야 한다. SW 개발은 단편적으로 제품을 생산해 내는 것 이상으로 마치 서비스와 같다. 당연히 출시 이후에도 SW Engineer는 SW를 개선하고, 변경하고 관리하는 역할을 수행해야 한다.
물론, 비용 때문에 여기에 충분한 인력이 배치되지 못하는 경우가 아주 허다하다. 하지만 제품을 유지보수하면서 업데이트하는 과정을 통해서 안정적으로 서비스를 제공할 수 있고, 심지어 그 과정에서 발굴되는 가치가 처음 기획했던 것 이상으로 고객에게 만족을 가져다줄 수 있는 것이 SW 제품이라는 것을 잊어서는 안 된다. 따라서 이때 가용 인력은 단순히 문제를 대응하는 인력이 아니라, 새로운 기회를 창출할 수도 있고, 치명적인 문제점을 사전에 보완할 수도 있는 막중한 임무를 갖고 있는 것이다.
그런 의미에서 SW Engineer에 잉여 인간이란 없다. RAID나 DR에서처럼 단순히 대기하고 있는 예비 리소스가 아니다. SW Engineer는 충분한 가용인력을 두어야 한다. 그리고 그들이 새로운 기술을 습득하고, 기회를 모색하고, 기존 시스템을 지속적으로 개선할 수 있도록 동기부여하고 기회를 제공해야 한다. 그러한 목적을 위해서 SW 기업들은 굳이 시간을 들여 기술 블로그를 운영하고, 내부 개발자 간의 교류를 확대할 뿐만 아니라 공개적으로 개발자 콘퍼런스를 열어서 개발자들이 직접 기술을 뽐낼 수 있는 자리를 마련해 준다.
단순히 인력을 줄일 생각을 하기보다는 훌륭한 인력으로 팀을 구성했는지 먼저 돌아봐야 하고, 그 인력들이 충분히 동기부여가 되었는지 살펴보는 것이 더 중요하다. 여기에 문제가 없다면 인력을 줄이기보다는 기술 습득과 능력 향상에 시간을 투자하고 그 능력들을 발휘할 수 있는 기회를 제공하는 것이 SW 산업에서 미래를 준비하는 가장 큰 투자라고 확신한다.
