오래 전 서버는 우리 같은 사람만을 위한 그런 것이었다. 필자를 비롯한 IT 종사자들은 사양을 철저히 조사하고, 구매 주문서를 작성해 보내 서버 하드웨어를 배달 받았다. 그런 후, 일하는 자리에서 조금 떨어진 서버실에 조심스럽게 설치를 한 후 테스트를 했다. 개발자들은 서버실로 가서 서버를 만지고, LED 등이 제대로 들어오는지 확인하고, 조용히 팬이 돌아가는 소리를 들으며 안정을 찾았다. 혹자는 셔츠 소매 자락으로 앞 패널을 깨끗이 닦기도 했을 것이다.

그런데 지금은 하드웨어와 관련해서 할 일이 없을지도 모르겠다. 일부는 ‘인스턴스’를 생성하기 위해 여전히 클라우드 서비스 업체의 웹페이지를 클릭하겠지만, 상당수는 서버 시작 작업을 자동 스크립트 실행에 맡긴다. 여기에 계속해서 봇이 배포 및 통합되고 있는 추세이다. 기껏해야 빌드 루틴을 구성할 때 인스턴스 크기를 논의하는 데 잠깐 시간을 투자할 뿐이다. 이후 작업은 로봇 배포 루틴 중 하나에 맡긴다. 이 소프트웨어는 우리가 아무 일을 하지 않아도, 예비 사이클을 위한 경매를 협상할 수 있을 정도로 똑똑할 수도 있다.

또 ‘서버리스’가 점점 더 보편화되면서, 하드웨어와의 단절’이 더 커지고 있다. 물론 기업이 직접 보유하고 구동하는 서버가 전혀 없다는 말은 아니다. 다만 어딘가에서 ‘윙’ 소리를 내며 돌아가고 있는 칩이 가득한 철제 상자와 관련된 일은 신경쓰지 말라는 의미이다. 몇 줄의 코드만 주면, 뒤쪽 창고에서 서버가 확실히 가동하도록 만들어줄 것이다.

이런 미스터리 중 상당수는 노동력 절약과 스트레스 경감이라는 혁신과 관련이 있다. 우리가 어둠 속에 남겨지는 이유는 메모리 구성이나 드라이브 파티션, 고장난 DVD-ROM 트레이가 문제가 될지 여부 등 ‘디테일’을 생각하는 데 시간을 낭비하지 않기 위해서이다. 이런 부분을 신경 쓸 필요가 없는 것은 좋은 일이다. 사실 개발자는 귀찮은 문제에 대해 논의하고 검토하는 회의를 건너뛰기 위해 오랜 기간 애자일 도구와 봇을 열심히 개발했다.

그러나 때때로 너무 많은 것이 깔개 밑에 쓸려 들어가 숨겨지기도 한다. 논의를 할 때 디테일을 지나치게 많이 생략한 채, 누구도 읽지 않을 정도로 긴 계약과 계약 조건에 동의를 하고, 버튼을 클릭하기도 한다.

그나마 다행인 것은 이런 디테일이 중요하지 않을 때가 많다는 것이다. 그리고 우리는 이미 약속을 했고, 과거에도 아무런 문제가 없었기 때문에 여기에 대한 걱정을 관뒀다. 과거에도 좋은 ‘모험’ 이었기 때문에 다시 한 번 모험을 한다.

그러나 때로는 우리가 건네준 몇 줄의 코드가 문제가 될 때를 대비해서 이런 미스터리에 대해 생각해 볼 필요가 있다. 백번 중에 한 번, 아니면 천 번 중에 한 번, 아니 그 이상의 희박한 가능성에 대비하기 위해 몇 가지 추가 질문을 해야 한다. 물론 지나칠 정도로 의심을 하고, 걱정하라는 의미는 아니다. N가지 미스터리를 걱정하면서 밤잠을 설칠 필요는 없다. 그러나 잠은 안오고 할 일은 딱히 없는 밤을 위해 곰곰이 생각해볼 수 있는 현대 하드웨어의 N가지 미스터리를 소개한다.
 

서버는 어디에 있는가?

클라우드에 있다. 아마 이것이 우리가 아는 전부일 것이다. 클라우드 서비스 업체는 인스턴스가 뉴욕이나 카라치에서 실행되고 있다고 알려준다. 더 이상은 알려주지 않는다. 도시 이름, 심지어 국가 이름 정도만 알 수 있는 때가 많다. 

정확한 주소까지 신경 써야 할까? 보안과 안전 때문에 건물 자체의 정확한 위치를 숨기는 것일 수도 있다. 우리가 서버의 정확한 (물리적) 위치를 모른다면 악당도 그 위치를 모를 것이다. 우리는 아마 영원히 과거 서버실을 방문했을 때처럼 서버를 직접 만지고 팬 돌아가는 소리를 듣지 못하게 될 수도 있다.

그런데 우리 가운데 일부는 데이터센터의 실제 물리 위치에 대해 고민해야 할 필요가 있다. 사법 관할권과 직결된 법적 문제, 세법 등을 걱정해야 한다. 우리 가운데 일부는 수출 관련 법률, 데이터가 국경을 넘을 때 발생하는 문제 등을 걱정해야 한다. 우리 가운데 일부는 이런 문제 때문에 변호사와 통화를 하는 상황에 직면할 것이다. 우리 가운데 일부는 ‘소환장’을 받을 수도 있다.
 

CPU 종류는?

6세대 칩 선택 여부에 대해 고민하고, ‘핫’한 고성능 7세대 칩에 투자를 할 근거를 찾느라 고민하던 시절을 기억하는가? 벤치마크 수치를 자세히 들여다보고, 속도를 기준으로 비용을 비교하던 시절을 기억하는가? 예산 문제로 3세대 칩을 1년 간 더 써야 하는 친구 크리스와 점심을 먹으면서, 4세대 칩으로 업그레이드하는 것을 자랑하던 시절을 기억하는가?

그런데 지금은 CPU 제조업체, 모델 번호, 기타 세부사항을 전혀 모르고 있을 것이다. 클라우드 서비스 업체는 ‘m1’이나 ‘large’ 같은 암호 같은 이름을 붙여 인스턴스를 판매한다. 큰 의미가 없는 이름들이다. 예를 들어, ‘m1’과 ‘m2’ 사이에 상관관계가 없을 수도 있다. 그냥 이름, 명칭에 불과할 수 있다.

일부 클라우드 서비스 업체는 구입하는 ‘가상’ CPU 성능을 분류, 적합한 성능으로 확장을 하도록 유도한다. 어쩌면 쓰레딩와 병렬 알고리즘에 영향을 주는, 서버 내부의 코어 수와 관련이 있을 수도 있고, 그러지 않을 수도 있다. 그냥 고객이 구매하는 ‘양’을 측정한 ‘외양’에 불과할 수도 있다.

하지만 때론 하드웨어 자체가 차이를 만들기도 하고, 특정 칩이 원인인 보안 취약점이나 문제가 존재할 수도 있다. ‘히든 갓 모드(Hidden God Mode)’ 취약점의 경우, VIA x86 칩 C3에 영향을 미쳤다. 알고리즘이 더 빨리 실행되도록 만들기 위해 쓰레딩 모델과 코어를 알아야 하는 경우도 있다. 이렇게 별것 아니지만, 동시에 중요한 문제들이 수십 가지에 달한다. 우리는 클라우드 서비스 업체가 고객을 위해 항상 최고의 기술을 사용한다는 말만 믿고 계약을 한다. 그렇지만 그냥 그렇게 말만 하는 것일 수 있다.
 

메모리의 종류는?

과거에는 더 빠른 ECC 메모리를 설치할 필요가 있을지 고민했다. 또 어떤 RAM이 더 안정적인지 고민했다. 특정 메모리 제조업체를 고집하기도 했는데, 브랜드와 기술적 접근법에 대한 견해’를 갖고 있었기 때문이다.

그런데 지금은 하드웨어가 얼마나 좋은지 알지 못한다. 클라우드 서비스 업체의 엔지니어가 걱정해야 할 문제이기 때문이다. 우리는 걱정할 필요가 없다. 그러나 클라우드 서비스 업체의 엔지니어는 정말 고민하고 걱정할까? 알 수 없다. 알 방법이 없다. 어쩌면 메모리가 나빠 인스턴스에 문제가 발생할 수 있다. 그 원인이 우리가 잘못 개발한 코드 때문일 가능성도 있다.

드라이브의 종류는?

SSD를 사용하고 있다고 자랑하는 클라우드 서비스 업체가 있다. 더 빠른 하드 디스크를 사용한다고 뻐기는 업체도 있다. 또 25GB의 스토리지를 빌려주면서 세부 정보를 제공하지 않는 업체도 있다. 디스크 드라이브마다 안정성 등급이 다르다. 플래시 메모리 종류도 다양하다. 너무 많이 덮어쓰기를 해서 문제가 발생한 플래시 셀 때문에 코드에 문제가 발생한 것은 아닐까? 아니면 서둘러 새 코드를 배포하려 시도한 신입 프로그래머의 실수가 문제의 원인일까? 더 이상은 걱정할 필요가 없는 문제이다. 또 다른 인스턴스를 부팅해 옮기면 된다.
 

심지어 트랜지스터도 단순하지 않다.

아마 서버에서 가장 단순한 구성 요소가 메모리일 것이다. 그렇지만 기초적이면서 지루한 ‘시멘틱(Semantics)’이 수반된다. 어떤 비트는 특정 주소와 짝을 지어서 해당 주소와 함께 제시할 때 동일한 비트로 구현된다.

트랜지스터는 2개 값만 저장하는 디지털 서비스로 보일 수도 있다. 그러나 이는 ‘이론적’으로 접근했을 때의 이야기이다. 실제는 아날로그 회로이고, 때론 공포스러운 유출 사고를 초래할 수도 있다. 보안 연구원들은 Rowhammer나 RAMBleed  같은 영리한 기법을 발견했다. 능력 있는 해커들은 원격으로 이를 악용하는 방법을 찾아낼 수 있다. RAM의 기초 시멘틱도 믿을 수 없는 데 무엇을 믿을 수 있을까?
 

다른 칩은 더 ‘미스터리’ 하다.

대부분의 경우, 컴퓨터의 나머지 구성요소에 대해 생각하는 시간은 더 적다. CPU와 GPU에 대해 간헐적으로 이야기를 한다. 그러나 네트워킹 부서를 제외하고, NPU(Networking Processing Unit)에 대해 이야기하는 사람이 있는가? NPU는 모든 사람이 존재 자체를 잊고 있음에도 불구하고, 조용히 헌신적으로 데이터를 이동시키는 구성 요소이다. 

그러나 NPU에도 자체 펌웨어가 있다. 클라우드는 가장 정교한 시멘틱 가운데 일부가 적용된 정교하고 재구성이 가능한 네트워킹 계층을 갖고 있다. 분기 예측(Branc prediction) 악용과 Rowhammer에 대해 고민을 하지만, 해커들이 네트워크 카드를 이용해 할 수 있는 일을 생각하는 데 많은 시간을 투자하는 사람이 있는가?
 

기술의 종류는?

특정 서비스를 설명할 적절한 ‘용어’를 모르는 경우도 있다. 아마존 글래시어(Glacier) 스토리지는 가장 저렴한 서비스 중 하나이지만, 아마존은 여기에 사용하는 기술에 대해 설명하지 않는다. 느린 하드 디스크 랙을 이용하고 있을까? 아니면 데이터를 여러 블루레이 디스크에 구워 사용하는 방식일까? 아니면 로봇 팔이 자동 적재하는 자기 테이프 방식을 사용하고 있을 가능성도 있다. 또는 비용에 따라 교체가 가능하도록 2~3가지 기술을 사용하고 있을 가능성도 있다. 모두 미스터리로 남아 있다. 우리는 기가바이트 당 가격, 정보를 검색하거나 되찾는 데 소요되는 시간 정도의 정보만 알 수 있다.
 

무슨 일이 일어나고 있는가?

때론 무슨 일이 일어나도 모를 수 있다. 클라우드로 마이그레이션을 해도 정전이나 디스크 드라이브 파열, 랜섬웨어의 위험이 사라지는 것은 아니다. 그러나 우리는 이에 대한 정보를 얻지 못할 수도 있다. 서버실을 활용했던 시절에는 모두가 같은 팀이고, 같은 상사에게 보고를 했다. 물론 항상 사실만 보고하는 것은 아니지만, 일반적으로 더 솔직히 공개적으로 정보를 제공한다. 

그런데 클라우드의 경우, 문제를 다루는 사람이 누구인지 모를 수도 있다. 이메일과 지원 티켓을 통해 커뮤니케이션을 하게 될 것이다. 때론 변호사, 매니저, PR 담당자가 끼어들 수도 있다. 우리가 받게 되는 정보는 잘 준비된 변명에 불과할 것이다. 잘하면 ‘실수가 있었다’는 이야기를 들을 수 있을 것이다. 그러나 최악의 경우에는 아무런 이야기를 듣지 못할 수도 있다.

최근 퀵북(QuickBooks) 회계 데이터를 표적으로 한 랜섬웨어 공격이 좋은 사례가 될 수 있다. 클라우드에 데이터 처리를 맡기면 걱정할 필요가 없다는 마케팅 미사어구를 믿었던 고객들은 무슨 일이 일어났는지 몰라 노심초사하는 상태로 남겨졌다. 이런 종류의 공격은 내부 데이터센터에도 발생할 수 있다. 하지만 최소한 간혹 회사 야유회에서 만나기도 하는 담당자의 이름 정도는 알고 있을 것이다. editor@itworld.co.kt

원문보기:
http://www.itworld.co.kr/news/127767#csidx7a73e730f4361f99dfd01c81a43f77a