자동화와 코딩과의 상관관계
'정리하는 뇌'를 통해서 본 자동화(제약)와 자율성(코딩)의 관계의 모범
'뇌의 정보를 외부로 내보내라!'
- 대니얼 J. 레비틴, '정리하는 뇌'
1. 책 개관(After Reading)
기억의 '외부화 원칙'을 지켜라. 그러면 업무의 효율성을 극대화할 수 있다.
클라우드 컴퓨팅의 도입 까닭은 아래와 같다.
어떤 모바일 앱의 개발이 이루어지면, 개발자가 잠든 사이에도 항상 앱의 서비스가 이루어지게끔 구동하고 있는 서버가 한 대 필요하다. 놀고 있는 서버나, 한대 새로 장만하기보다 물리적으로 관리할 필요가 없는 가상의 서버를 클라우드를 통해서 구입하는 게 비용이나 시간 측면에서 효율적이다.
이것이 클라우드 서비스의 수요가 증가하게 된 원인이다. '정리하는 뇌'의 저자가 말했듯이 내부(뇌)의 정보를 외부로 내보내서 내부에서 관리해야할 정보량을 줄일 수 있게 된다. 즉, 서비스 제공자의 인지 과부하를 줄여서 서비스의 품질에 더 초점을 맞출 수 있게 된다.
시스템이 구조화(마이크로 서비스)되어 있을수록 그것을 기술하는 데 필요한 정보의 양은 줄어든다. 정돈되지 않고 구조화되지 않은 시스템을 기술하는 데는 그만큼 많은 정보가 필요하다. 무작위 시스템 안에는 어떤 패턴(유의미한 정보)도 존재하지 않기 대문에 각각의 요소가 개별적으로 기술되어야만 하고, 여기에는 막대한 양의 소통, 혹은(새넌의 표현을 빌리자면) 정보가 필요하다(대니얼, 2014).
정보이론의 힘은 모든 것에 적용할 수 있다는 데 있다. 웹사이트 구조, 법률 영역, 윤리 영역, 심지어 집을 구하려는 사람에게 해줄 충고에도 적용할 수 있다고 한다. 이 글의 앞선 섹션에서 다룬 수평적 조직과 수직적 조직에 대해 논의했던 것을 떠올려보면, 새넌의 정보이론은 그 안에 들어 있는 구조나 정보의 수준을 정량화하는 데도 적용할 수 있다(여기서 말하는 정보란 웹사이트에 들어 있는 정보의 내용이 아닌 계층구조 그 자체, 메타데이터를 말한다).
클라우드 서비스가 거의 모든 업계의 시스템으로 도입되면서, 이 서비스의 장점과 더불어 인지되어야 할 폐해도 부각되고 있다. 이 책에서도 언급되었지만, 모든 데이터(정보)를 클라우드에 백업하는 것은 장단점이 있다고 지적했다. 장점은 자기를 대신해서 다른 누군가가 대형 서버를 백업하면서 하드웨어의 유지를 책임져주고(이들은 당신의 세금 문서나 가족사진을 하나만 복사해두지 않고 여러 개 복사해 둔다), 모든 것이 매끄럽게 운영되게 해 준다는 것이다. 하지만, 미국의 '메가업로드 MegaUpload'는 사람들이 백업 파일을 올리게 하는 데 그치지 않고 점점 거대한 해적 사이트가 되어서, 결국 미 법무부가 2012년에 강제로 사이트를 차단했다. 이후 아무도 거기서 자기 파일을 가져올 수 없게 됐다고 한다. 전문작가나, 영화감독을 비롯해 그곳의 모든 고객이 보관해둔 정보를 잃고 말았다.
그래서 나온 교훈은,
자기 데이터는 자기가 보관하자!
이다.
데이터 이송(Data Migration)이란 컴퓨터 시스템, 소프트웨어, 하드웨어 등의 업데이트로 읽을 수 없게 된 데이터를 읽을 수 있게 만드는 과정을 말한다. 단순히 파일을 클라우드 서버에 올리는 과정만을 일컫는 게 아니다. 이를테면 필자의 집에 있는 클래식 테이프들은 이제 카세트가 달린 오디오가 없으면 들을 수 없다. 이 낡은 골동품들은 그냥 버려야 하는가? 이것을 계속 들으려면 오래된 클래식 테이프를 MP3 포맷으로 변환할 수 있는 기기를 사서 전부 컴퓨터에서 재생 가능한 파일로 바꿔야 한다.
이것들이 만약, 법인, 공개기업, 연구실 그리고 기록물을 입수해야 하는 기자들은 이런 부분이 법적 문제로 이어질 수도 있으므로 신경 써야 한다(대니얼, 2014). 컴퓨터를 자기 삶의 디지털 기록보관소로 이용하는 나머지 우리들의 경우, 파일 이송은 그냥 일상적인 실패에 대비한 계획에 해당한다고 저자가 말한다.
저자는 이 정보 과부하의 시대에 대비해야 하는 비즈니스 사람들을 위한 대비책을 상기시키면서 인간만이 어떤 재해가 발생했을 때 어떻게 복구할지 생각할 수 있다고 한다. 다른 그 어떤 동물도 미래를 대비해 계획을 세우고, 아직 일어나지도 않은 상황에서 어떻게 행동을 할지 전략을 짜지 않는다(대니얼, 2014).
이런 계획은 개인적으로 정돈된 삶을 꾸리는 데만 중요한 것이 아니라 사업을 성공적으로 영위하는 데도 필수적이라고 하며, 결국 앞선 섹션에서 언급한 '통제 소재'로 귀결된다고 한다. 유능한 조직은 인간, 환경 등 외부적인 힘에 휘둘려 움직이기보다는 자신의 미래를 스스로 관리하기 위한 단계를 밟아 나가는데, 이 가운데 바로 '클라우드 서비스'가 있다.
앞서 말한 모든 데이터를 클라우드 서비스에 위탁하는 대신, 정말 중요한 데이터는 같은 클라우드 장소가 아닌 물리적으로 따로 보관시키는 서비스도 있다. Azure(애저, MS 클라우드 서비스)나 AWS(아마존 클라우드 서비스) 등 주요 IaaS(클라우드 서비스를 이용하기 위해 인프라 전반을 제공하는 클라우드 책임 모델 중 하나) 업체에서 제공하는 '전용 하드웨어'를 사용할 수 있다. 전용 하드웨어를 사용하게 되면 혹시나 모를 재해(해킹)로 인해 나의 클라우드 상의 데이터가 동일한 서버에 존재할 가능성을 없앨 수 있다. Azure는 격리 인스턴스 및 최근 발표한 전용 호스트, AWS는 전용 인스턴스, 구글은 단독 테넌트 노드로 전용 하드웨어를 제공한다. 기본 공유 테넌시(클라우드 서비스 이용을 위한 구독 단위) 기반 옵션에 비해 일반적으로 6~10% 정도 더 비싼 비용을 지불해야 한다(에밀리, 2022).
조직은 클라우드 서비스를 사용하는 시스템에서 여러 재해 위협(자연재해뿐만 아니라, 해킹)에 반드시 주의해야 하는데, 이 클라우드 서비스에서 현재 가장 필요로 하는 기술력은 '자동화'이다.
산재가 아닌 인재(사람의 실수)를 대비한 서비스 자체의 규격화이다. 이 규격화(→Infrastructure As Code, 코드로써 인프라 관리)를 도입하기 위해 앞서 마이크로 서비스를 언급하였고, 서비스 제공자의 작지만 자율적인 느슨한 결합을 통해서 동적인 서비스 상태에서도 형상관리가 가능한 이점이 있다.
서비스 제공자(개발자나 운영자)는 지속적인 품질 개선을 위해 언제든지 코드의 품질을 개선(리펙터링)하거나 사용 언어의 서비스 버전을 업데이트해야 하는데 이것이 자동화 배포로 이루어지고, 자동화되지 않은 그 어떤 변경도 허용되어서는 안 된다는 게 현재 클라우드 업계에서 가장 핫하게 떠오르고 있는 공리와 같은 말이 되었다.
서비스의 신속한 배포(agile)와 동시에 보안이 핵심 이슈로 떠오르면서 DevSecOps라는 타이틀이 생겼다. 예를 들어 SQL(Structured Query Language의 약자이며, '시퀄'이라고 읽는다.) 관리자가 SQL 서버가 있는 자원 그룹에 대한 모든 권한이 반드시 필요하지도 않을뿐더러, 단순히 읽기 권한만 있어도 업무를 수행하는데 큰 제약이 없다. 그들에게 생성된 로그에 접근하는 데까지만 권한을 부여하고 절대로 '자동화 없이' 제품을 변경해서는 안되도록 해야 한다. 그렇지 않으면 장애 복구 전략은 소용이 없어진다(에밀리, 2022).
이렇게 개발자 소스 코드조차 전부 자동화로 규격화(관리 함수 단위, FaaS)시켜서 배포하고 또 이것을 검증하는 것조차 프로세스화 해서 PID 번호를 붙이는 것이 관례가 되는 게 과연 클라우드 업계의 엔지니어(필자임...)에게는 이제 더 이상 자율성을 요구(필자의 성향임...)하는 프로그래밍 능력이 필요 없다는 뜻일까?
아니다. 코드를 볼 줄 아는 능력은 더욱더 필요하고, 이것이 여러 번의 테스트로 이루어져야 한다면 다행이지만, 서비스가 이루어지는 가운데 배포된다면 이 코드 품질에 대해서 한 번의 테스트(디버깅 능력)로 결과를 시뮬레이션할 수 있는 TDD(Test Driven Development) 능력은 더욱 요긴해진다.
그러니깐, 앞으로 클라우드 엔지니어로 먹고살려면, '정리하는 뇌'의 저자가 언급한 미래를 대비해 계획을 세우고, 아직 일어나지도 않은 상황에서 어떻게 행동을 할지 전략을 짤 수 있는 기술역량이 클라우드 서비스를 대하는 자세의 밑바탕이어야만 한다.
위에서 말한 코딩 기술력은 책에서 언급한 주어진 업무에서 일부만 예측할 수 있는 어떤 재량권과 판단력을 발휘해볼 수 기회를 말한다. 일하면서 너무 많지 않은 일부 측면에서 흥미로운 방식(새로운 알고리즘)으로 놀라운 사실(최적화)을 발견하게 되면, 이는 무언가를 발견하고 스스로 성장했다는 느낌으로 이어진다고 한다.
이것은 뇌의 전전두엽 피질에 47번 영역이라는 부분을 자극하는 데, 이 영역은 자기 안에 들어 있는 예측 회로를 기억력과 함께 이용해서 사건의 미래 상태를 추정한다. 앞서 말한 대로 우리가 일이 어떻게 진행될지 일부만 예측할 수 있다면 아주 보람 있을 것이다.
이 47번 영역을 행복하게 유지할 적절한 균형을 찾아내는 일은 무척 까다롭다고 하는데, 대부분의 직무 만족은 다음의 두 가지가 결합됐을 때 찾아온다고 한다. 우리는 어느 정도의 제약(클라우드 서비스의 네이티브 툴, 쿠버네티스나 앤저블 혹은 테라폼) 아래 있으면서 그 제약 안에서 개인적인 창의력(로직을 고객 사이트에 맞게끔 구현하는 코딩능력)을 발휘할 수 있도록 허락받았을 때 최고로 기능한다고 한다(개인적으로 제약시키는 플랫폼과 같은 툴을 개발할 수 있는 소프트웨어 능력이 한국도 빨리 성장했으면 좋겠다는 생각이 든다).
음악 역사상 가장 창의적인 작곡가들은 제약 하에서 창의력의 균형을 맞춘다는 이런 묘사와 딱 맞아떨어진다(대니얼, 2014). 모차르트는 교향곡을 발명하지 않았고, 비틀스는 로큰롤을 발명하지 않았다. 하지만 그러한 형식의 경계를 넓히고 재정의한 것은 바로 모차르트와 비틀스가 형식의 엄격한 제약 속에서 이룬 일들, 즉 그들이 자신의 작품에 불어넣은 엄청난 창의력과 독창성이다.
서양 음악은 열두 개의 음만 사용하는데, 이 시스템 안에는 커다란 유연성이 존재한다는 말과 같이 베토벤이 음악 역사상 처음으로 교향곡(‘합창’)이 흐르는 가운데, 갑자기 성악가가 노래를 불러서 당대 청중에게 충격을 줬다는 일화도 있다. 지금으론 이해가 안 되겠지만, 기존의 형식을 완전히 바꾸지 않더라도 얼마든지 충격요법을 줄 수 있는 창의성 발휘를 어느 분야를 막론하고 클라우드 엔지니어라도 십분 발휘해볼 수 있다고 생각한다.
그래서 테라폼(Terraform)이라는 서비스가 운용 중인 가운데 코드 배포가 가능한 각광받고 있는 기술 스택으로 떠오른 지 꽤 되었는데, 이것이 테러 폼(Terror form)이 되지 않고도 얼마든지 유연하게 사용할 수 있는 엔지니어가 아마도 현재 클라우드 업계에서 라이징 스타가 되지 않을까 싶다. 업계에서 요구하는 자격증만 주구장창 따기보단(제약, 하지만 필요선) 말이다.
발췌
1) 레비틴 대니얼 J. (2014). 정리하는 뇌 (Vol. 1). 와이즈베리.
2) 프리먼 에밀리. (2022). 클라우드 엔지니어를 위한 97가지 조언 (1st ed., Vol. 1). 길벗.
