141: tweet overflow

파일 시스템에 기반한 개인 정보 시스템의 한계

이 글은 2016년 8월 1일에 다른 블로그에 공개했던 글을 옮겨온 것이다.


광역적인 맥락에서 정보 시스템은 구글로 대표되며, 구글이 다루지 않는 전문 분야들은 각 분야 별로 별도의 데이터베이스가 구축되어 있다. 하지만 이러한 광역적 정보 시스템의 개인의 정보 시스템을 대체할 수 있냐고 묻는다면 그렇지 않다고 생각한다. 왜냐하면 구글은 정말로 광역적인 맥락만을 수용하기 때문에, 각 개인의 고유한 정보와 맥락들까지 모두 포용할 수는 없기 때문이다.

이러한 관점에서 2000년 중후반에는 광역적인 정보 시스템이나 유사 서비스들에서 이른바 개인화라고 불리는, 개인의 맥락을 덧씌우는 작업이 활발하게 진행되었다. 하지만 여기서 말하는 개인화는 개인의 정보나 맥락을 온전하게 포함하지 못 하며 근본적인 두 시스템(광역 정보 시스템과 개인 정보 시스템)의 차이와 개인 정보 문제 때문에 완결을 이루지 못 한 채로 시들어져 갔다. 개인화는 개인 정보 시스템을 완결하지 못 했고, 재미있게도 개인 정보 시스템은 구글이 급속하게 성장하면서 정보 시스템으로서 실질적인 발전을 이룩하는 동안에, 거의 아무런 발전도 하지 못 했다.

아직도 대부분의 사람들은 개인 정보 시스템의 기반으로 파일 시스템을 사용한다. 예를 들어 어떤 디자이너를 상상해보자. 이 디자이너는 포토샵(Photoshop)과 일러스트레이터(Illustrator)를 주로 사용한다. 하나의 작업을 할 때마다 작업 내용을 담고 있는 자체 포맷(예를 들어, psd)와 최종 퍼블리싱 포맷(예를 들어, png)으로 다수의 파일을 생산해낸다. 이러한 작업물들은 처음부터 파일 시스템에 저장된다는 전제에서 생산된다. 이 디자이너는 파일 관리에 고충을 겪어와서 자신만의 디렉터리 관리 방법을 정해서 사용하고 있다.

2016/09/낰욧 기획사/봉투 디자인/20160902 초기 시안.ai
2016/09/낰욧 기획사/봉투 디자인/20160921 최종 디자인.ai
2016/09/낰욧 기획사/봉투 디자인/20160921 최종 디자인.png
2015/05/낰욧 블로그/로고 디자인/20150513 디자인.psd

아마 현실에서 이 정도로만 파일이 관리되면, 충분할 지 모른다. 이러한 접근 방법은 하나의 디렉터리에서 모든 맥락을 소실한 채 이름만으로 파일만을 관리하는 것보다 훨씬 더 구조적이다. 하지만 디렉터리 깊이가 깊어짐에 따라서 파일들을 일일히 탐색하는데 고충이 생길 수도 있다. 이 디자이너에게 파일 시스템은 자신의 작업물 전체를 저장하고 관리하고 기억하고 탐색하는 개인 정보시스템이다. 하지만 이 시스템은 효율적이지 않다.

안타깝게도 컴퓨터 위에서 모든 작업은 파일 기반으로 이루어지고, 파일이라는 것은 서로 다른 애플리케이션들이 작업을 공유할 수 있는 기반이기도 하다. 하지만 파일 시스템의 근본적인 원시성에 대해서 이야기해볼 필요가 있다. 파일 시스템은 근본적으로 정보의 가치를 극대화하기 위해서 만들어진 시스템이 아니라, 컨텐츠를 특정한 단위(파일)로 저장하기 위해서 설계된 시스템이다. 파일엔 메타데이터를 유연하게 담기 위한 충분한 공간이 준비되어있지 않으며, 만약 그러한 파일 시스시템이 있다고 하더라도 그것을 인덱스하고 검색하기 위한 기능들이 내장되어있지 않다.

이러한 근본적인 한계를 극복하기 위해서 각 운영체제들은 파일 시스템에 덧씌워 별도로 파일을 인덱스하고 검색할 수 있는 인터페이스를 제공한다. 각 시스템에서 제공하는 이러한 기능들을 충분히 활용하고 있다면 이미 그 사람은 개인 정보 시스템에 있어서 충분히 파워유저라고 할 수 있다. 하지만 이러한 접근은 근본적인 한계가 있는 접근이다. 첫번째로 이러한 레이어는 운영체제 간에 공유되지 않는다. 두번째로 운영체제는 기본적으로 모든 종류의 파일 형식들을 지원하지 않는다. 즉, 파일 내부에 포함된 내용이나 메타 데이터들을 모두 적절히 처리할 수 있는 것은 아니다. 마지막으로 여전히 파일 시스템 기반의 경로에 지나치게 의존적이다.

파일 시스템을 개인 정보 시스템으로 이해한다면, 이 시스템은 개인이 가진 정보를 유용하게 한다는 맥락을 포함하지 않는다는 점을 인지할 필요가 있다. 파일 시스템은 철저히 데이터를 구조적으로 저장한다는 맥락에서 설계되었다. 하지만 정보 시스템의 본질적인 가치는 정보의 저장에 있지 않다. 앞선 디자이너의 예에서 다음 파일을 찾고 싶다고 가정해보자.

2016/09/낰욧 기획사/봉투 디자인/20160902 초기 시안.ai

이 디자이너는 분명히 구조적으로 폴더 시스템을 잘 활용하고 있다. 하지만 이러한 디렉터리 구조는 얕은 경로에서 작업 시기를 정확히 알고 있어야만 해당하는 주제를 찾을 수 있도록 구성이 되어있다. 단순 이름 검색이 가능하다고 하더라도 실제로 찾고 있는 파일인지를 확인하는 방법은 경로를 확인하거나 실제로 열어보는 일이다.

다시 광역적인 정보 시스템을 생각해보자. 구글과 같은 거대한 검색엔진은 우리가 상상할 수도 없을만큼 많은 정보를 매일 인덱스하고 검색 가능하게 해준다. 이 때 우리에게 중요한 것은 실제 데이터가 어디에 있는 지가 아니다. 구글 덕분에 우리는 정보를 검색할 때 정보의 위치(즉, 파일시스템의 경로)를 완전히 무시한 채, 키워드만으로 어떤 정보에 이르는 새로운 경로를 가질 수 있게 된다. 구글이 가진 근본적인 가치는 무수히 많은 문서 중에서 가장 가치 있는 문서로 정렬을 해준다는 점이다. 우리는 때때로 나중에 필요한 것들을 로컬 파일 시스템에 저장해놓곤 한다. 하지만 어떤 정보가 필요할 때 그것을 파일 시스템에서 찾는 것보다, 구글에서 다시 검색하는 게 더 빠른 경우가 자주 발생한다. 즉, 구글의 본질적인 가치는 이 세상의 모든 정보를 저장하는 것이 아니라, 이전 글(정보 과잉과 개인을 위한 정보 관리 도구)에서 이야기했듯이, 기록된 것을 유용하게 하는 능력의 진화에 있다.

버니바 부시가 지적했듯이 정보 과잉이 디지털 시대의 전유물이라고 생각하는 것은 착각에 불과하다. 정보 과잉은 이미 1900년대 초반부터 시작되었다. 앞서 이야기했듯이 광역적 정보 시스템의 본질적 가치는 정보의 양이 많아지는 속도보다 기록된 것을 유용하게 하는 능력을 빠르게 증가시키는 일이다.

안타깝게도 파일 시스템에 기반한 개인 정보 시스템이란 한 수십년 동안 정체중인 것으로 보인다. 추측컨데, 개인 정보 시스템에 있어서 정보 과잉이란 깊게 논의되지 않았던 게 아닐까 싶다. 개인 정보 시스템은 광역적인 정보 시스템과는 본질적인 차이가 하나 있다. 광역적 정보 시스템은 매우 탐욕적이라서 수집하고자 하는 모든 대상을 가능한 한 모두 수집하려고 한다. 이러한 탐욕성은 구글 북스와 같은 시스템에서 여실히 드러난다. 하지만 개인 정보 시스템은 지극히 개인적으로 정보(파일)을 늘려나간다. 그것은 개인의 창작물일 수도 있으며, 타인이 생산한 정보들일 수도 있다. 파일 시스템에 파일이 추가되는 것은 철저히 개인의 행동에 의해서 이루어진다. 즉, 파일 시스템은 시스템이 가진 정보를 유용하게 하는 능력보다도, 소유자가 파일 시스템 전체를 충분히 파악하고 있는 동안에만 유용하다. 그리고 바로 그러한 사실에 의존적으로 존재해왔던 셈이다.

나는 파일 시스템의 한계를 여실히 드러냈던 사례 중에 하나가 NAS(network attached storage)였다는 생각이 든다. NAS는 기존 파일 시스템에 기반해 파일을 통째로 넣을 수 있는 보조장치에 불과하고 결코 개인 정보 시스템은 아니다. 저장장치를 확장해주는 동시에, 지나치게 많은 파일들을 가질 수 있게 만들어준다는 점과 레이턴시의 증가로 컴퓨터를 개인 정보 시스템으로 활용하고자 할 때 더 지옥 같은 경험을 만들어준다.

예를 들어 사진을 관리하고자 한다면 NAS보다는 구글 포토스(Google Photos)어도비 라이트룸(Adobe Lightroom) 같은 모델이 훨씬 던 미래적이고, 개인 정보 시스템에 가까울 것이다. 중요한 것은 사진 수만-수십만 장을 한 파일 시스템에 저장하는 것이 아니다. 오히려 저장 장치는 파일의 경로에 의존하지 않도록 분산화될 수 있어야하고, 이것들을 관리하는 데이터베이스와 그것을 유용하게 하는 소프트웨어가 필요하다. 어도비 라이트룸은 데이터베이스를 구축하고, 메타데이터를 통해서 사진들을 분류하고 관리할 수 있도록 도와준다. 구글 포토스는 (다른 제약을 가지고 있지만) 좀 더 급진적이다. 사진을 분석하고 새로운 메타데이터를 생성해내서, 수동으로 태그나 메타데이터를 관리하지 않더라도 사진을 탐색할 수 있는 새로운 접근을 가능하게 해준다.

파일 시스템 위에서 개인들은 정보 과잉에 시달리고 있다. 이는 자신들이 가진 정보를 충분히 유용하게 만드는 능력이 없기 때문에 발생하는 일이다. 이는 개인의 한계가 아니라 소프트웨어적인 한계이다. 이런 맥락에서 보더라도 데스크탑에서 개인 정보 시스템을 구축하는 가장 근본적인 접근은 파일 시스템을 벗어나는 일이라고 생각한다. 운영체제의 접근이 성공적이진 못 했지만, 여전히 파일 시스템에 의존적이라고 할 지라도, 그 위에 하나 이상의 레이어가 덧씌워져야 함은 분명하다. 이러한 방향에서 서비스나 애플리케이션들이 존재하지 않는 것은 아니다. 앞서 보았듯이 어도비 라이트룸 같은 경우는 기존의 저작물 생산 도구들과는 확연이 다른 방향에서 개인 데이터베이스를 구축하는 데 초점을 맞추고 있다. 구글 포토스 역시 최근에 알파고가 보여준 것과 비슷한 맥락에서 정보에 대한 새로운 패러다임을 제시한다. 좀 더 범용적인 도구로는 에버노트(Evernote)데본싱크(Devonthink)와 같은 도구들이 있을 것이다. 이러한 소프트웨어들은 파일 시스템을 극복하고 어떻게 개인이 구축한 좀 더 많은 정보들을 유용하게 만들 수 있는 지를 보여준다.

개인 정보 시스템은 이제 첫 걸음을 시작했을 뿐이다. 앞으로도 이러한 소프트웨어에 대한 필요는 갈수록 늘어갈 것이다.

밀레니얼 세대, 살아남을 위험, 그리고 투자

한국에서 1980년대 이후에 출생한 밀레니얼 세대에게 20대는 결코 쉽지 않은 시간이었을 것이다. 여유있는 대학 생활을 보내고 코스피 200에 속한 대기업에 취직해서 아주 무난한 인생의 코스를 밟아 미래를 그려가는 사람은 한 줌에 지나지 않는다. 고시원은 대학생들의 일반적인 주거 수단이 되었고, 20대 후반에 어렵게 들어간 일자리에서 받는 월급으로는 생활하기에도 넉넉치 않다. 지방에는 좋은 일자리가 없지만, 서울의 집값은 너무 높아서 현실성이 없다.

대부분의 사람에게 이러한 현실에 적극적으로 대처할 수 있는 방법은 현실적으로 없다. 사치를 부리는 것은 아니지만 한 달 생활비로 쓰고 나면 남는 돈은 없다. 지금 되돌아서 생각해보면 20대에는 미래가 없었다. 현재를 감당하기도 버겁기 때문이다. 3포 세대라는 말이 나온 것도 자연스럽게 느껴진다. 이렇게 살아서는 연애도 결혼도 출산도 불가능하다. 여기에 몇 가지가 더해져서 N포 세대라는 말이 나왔다.

이러한 변화를 가속화한 데는 인식 변화도 큰 영향을 끼쳤다고 생각하지만, 적지 않은 사람들에게 기존의 삶의 양식이 불가능해졌다는 것을 암시한다. 20대 후반이나 30대 초반에 스스로 돈을 모아서 서울에 작은 집 하나 마련해서 아이 하나 낳고 신혼 생활을 꾸리는 건 하고 싶더라도 불가능하다. 적어도 2018년에 상식적인 사람이라면 그런 삶이 불가능하다는 것 정도는 알고 있어야한다.1

3일 한국은행에 따르면 서울의 연간 가처분소득 대비 주택가격 비율은 지난해 3분기 기준 10.3배를 기록했다.
서울지역 가계가 소득을 하나도 쓰지 않고 10년 넘게 모아야 집을 장만할 수 있다는 뜻이다. 이 비율은 미국 로스앤젤레스(9.3배)나 영국 런던(8.5배)보다 높았고, 캐나다 벤쿠버(11.8배)나 호주 시드니(12.2배)보다는 낮았다.

한국일보 : 경제 : 서울서 집 사려면 월급 10년 모아야

자녀의 결혼은 적절한 증여의 핑계가 되곤 하지만, 그것도 부모가 집 한 채는 있고 모아놓은 돈이 넉넉할 때나 가능한 이야기이다. 자녀 결혼에 집팔고 빚진다는 얘기를 보면 불행은 단순히 청년 층만의 몫도 아니다. 기존의 삶의 양식대로 살 수 있는지 없는지는 대학 졸업하고 취업할 때 쯤이면 거의 결정이 난다. 그것은 그 사람의 능력이나 의지에 의해서 결정되는 게 아니다. 그나마 뒤집을 수 있는 방법은 배우자를 잘 만나는 방법 정도밖에 없다.

그런 삶을 바란 적도 없고, 그렇게 살아갈 수 있다는 게 딱히 부럽다고 생각하지는 않는다. 하지만 사회가 선택의 기회조차 주어지지 않는다면 개인이 감당해야할 문제이지만은 않다. 밀레니얼 세대가 포기당한 건 연애도 결혼도 출산도 내집마련도 아니고, 바로 미래다.

하지만 미래는 반드시 도래한다. 단지 내가 원하는 시점이나 의도한 대로 오지 않을 뿐이다. 나는 이 사실을 결혼하고 30대가 되서야 깨달았다. 아내는 가끔씩 나중에 늙어서 폐지 줍고 살게 되지는 않을까 하는 얘기를 하곤 한다. 그런 미래는 일상에서도 자주 목격된다. 안타깝지만 한국에서 청년층만큼이나 불행한 세대가 노년층이다. 한국의 노인 빈곤률은 OECD 국가들 중에서도 압도적인 1위지만 사회적인 합의나 해결책은 찾지 못 하고 있는 실정이다. 미래가 반드시 도래한다는 사실을 깨닫게 되자마자 그 미래가 결코 밝지 않다는 것도 함께 바라보아야만 한다. 우리가 도달할 수 있는 미래의 경로는 한정적이다.

하지만 나는 미래는 반드시 도래한다는 것을 인지하는 것이 아주 중요한 출발점이었다고 생각한다. 미래가 오지 않는다면 우리는 크게 걱정할 일이 없다. 1900년대까지만 하더라도 0세를 기준으로 한 기대 수명은 50년보다 낮았던 것으로 알려져있다. 평균 수명이 낮을 때는 살아남는 게 중요하다. 하지만 현재 한국인의 0세 기대 수명은 82년으로 OECD 국가들 중에도 상당히 높은 수준에 속한다. 환갑은 장수를 축하하는 의미를 가지고 있었지만 이제는 60이면 노인 축에도 끼지 못 한다고 이야기한다. 이제 위험은 일찍 죽는 것뿐만이 아니다. 살아남아서 도래하는 미래를 계속해서 맞아해야만 하는 것도 새로운 위험이 되었다.

세상은 비교적 평화롭고 이러한 상황이 쉽게 달라질 것 같진 않다. 지금 30대라면 앞으로 50년은 더 살아야만한다. 지금 20대라면 앞으로 60년은 더 살아야한다. 이것은 어디까지나 통계적인 것이고 어쩌면 그 이상을 더 살아야할 지도 모른다. 한국에서 노인 세대가 이렇게까지 비참해진 원인은 사실 사회적으로 살아남을 위험에 대해서 충분히 준비하지 못 했기 때문이다. 국민연금은 1980년에 들어서야 호혜성 정책으로 시작되었다. 주진형 씨가 지적하듯이 국민연금은 빠르게 쌓여가고 있지만, 현재 노인 세대의 빈곤을 해소하는 것에 대해서는 어떠한 사회적 합의도 하지 못 하고 있다. 퇴직연금은 2005년에 시작되어 2022년에나 전 사업장이 의무가입 대상으로 확장된다.

이러한 정책의 가장 큰 수혜를 볼 수 있는 사람들은 역설적으로 바로 지금의 청년층이다. 얄궂게 느껴질지도 모른다. 현재의 삶이 가장 힘든 세대가 살아남을 위험에 가장 많이 노출되어있는 세대이기도 하기 때문이다. 하지만 아직 그러한 사실을 깨닫지 못 한 사람들은 국민연금이니 퇴직연금이니 월급 통장에 직접 찍히지 않는 돈이 아쉽게 느껴질 것이다. 사람들은 국민연금의 소득대체율은 들어봤을지도 모르지만 40년을 채워야 받을 수 있는 돈이라는 건 모른다. 하지만 30년 후에도, 50년 후에도 살아남아 있는다고 가정한다면 연금 제도를 대하는 태도는 달라져야만 한다.

이 이야기가 연금 제도에 대한 이야기는 아니다. 현재는 과거와 미래 사이에서 진행된다. 미래는 미지의 영역이자 상상력이 필요한 시간이다. 과거에 기반한 합리적인 상상력이 필요하고, 좀 더 멀리까지 바라볼 수 있어야만 한다. 그래서 미래가 도래한다는 사실을 인지해야하고, 미래를 상상할 수 있는 능력이 절실하다고 느낀다. 내가 지금까지 과거의 경험을 바탕으로 1년 후의 미래를 상상해본다면 내가 부자2가 되어있을 가능성은 제로에 수렴한다. 현재로부터 1년 후에 내가 부자가 될 수 있는 그런 경로는 아직 내 상상력으로는 발견하지 못 했다.3

이건 내 결론이다. 여전히 삶이 녹녹치는 않지만 나는 경제적인 관점에서 바라보는 미래가 몇 가지 있다. 첫 번째는 30년 후에 아내와 충분히 여유있게 노후를 보낼 수 있는 미래이다. 앞서 연금을 얘기했던 건 이러한 미래에 다다르는 경로에 있어서 국민연금과 퇴직연금이 가장 중요한 역할을 할 것임이 분명하기 때문이다. 부자는 되지 못 하더라도 어렵지 않게 가능하다고 생각한다. 단지 직장 생활을 해가면서 연금 자산을 축적해나갈 30년이란 긴 시간이 필요할 뿐이다.

두 번째는 부자가 되는 미래이다. 1년 후는 아니다. 다양한 투자를 시작했고 충분한 성과는 빨라도 10년 이상 걸릴 것이다. 나는 투자에서 가장 중요한 것은 종목 선택도, 내제 가치도, 시드 머니도, 자산 배분도, 위험 관리도 아니라고 믿는다. 그건 두 번째로 중요한 것들일 뿐이고 제일 중요한 것은 충분한 시간이다. 투자에는 변수가 너무 많다. 나는 내가 부자인 확정된 미래의 경로를 아직 찾지 못 했지만, 적어도 그러한 미래에 다다를 수 있는 경로들의 가능성들을 모색하고 있다.


  1. 나는 결혼 후에도 이것이 불가능하다는 것을 부모님한테 설득하는데 1년이 넘게 걸렸다. 
  2. 부자에 대한 명확한 정의는 모르겠지만, KB 2017 한국 부자 보고서에서는 기준인 금융자산 10억을 기준으로 제시한다. 
  3. 복권에 당첨되거나 코인 가즈아가 아닌 경로가 있다면 저에게도 공유해주길 알려주길 바랍니다 ;) 

기록은 되어야하며, 그리고 활용되어야한다

기록은 자산이다. 기록이 그 자체로서 큰 의미를 가지는 것은 아니다. 기록은 되어야하며, 그리고 활용되어야한다. 예를 들어 온라인 상에는 어마하게 많은 정보가 있고, 이것 자체만으로도 인류의 집단 지성 그 자체라고 말할 수 있을 것이다. 여기서 기록은 각자의 몫이다. 그리고 서로 다른 목적을 가진 개인들이 이러한 공개된 기록에 접근하고 가치있게 사용할 수 있도록 돕는 것이 바로 검색엔진의 몫이다. 그래서 기록은 되어야하며, 활용되어야한다.

일반적으로 구글과 같은 범용적인 검색엔진은 사용자의 맥락까지 염두에 두진 않는다. 하지만 모든 기록이 범용적인 것은 아니다. 기록은 방대하며, 검색엔진은 범용적이다. 이를 보완하기 위한 기법 중 하나는 개인화된 기록이다. 이는 개개인이 자신을 위해서나 국소적인 맥락에서 일부 사람들과 공유하기 위해서 만들어내는 것이다. 인간의 기억은 한계를 가지고 우리가 보고 들은 것, 그리고 검색하고 탐구한 것을 전부 기억하지는 못 한다. 개인화된 기록은 이를 보완하는 장치이며, 컴퓨터에 기반한 개인화된 기록 장치는 일반적으로 무한에 가까운 저장용량을 제공한다. 위키위키, 블로그, 노트 애플리케이션, 서지 애플리케이션, 웹 스크랩 도구와 같은 것들은 모두 기록을 돕고, 이를 활용하기 위한 다양한 기능들을 제공하는 도구이다. 여전히 많은 사람들이 개인의 내제적인 능력을 중요하게 여기지만, 나는 기록을 대하는 태도가 궁극적으로는 개인의 경쟁력에 있어서 더 큰 의미있는 차이를 만들어 낼 것이라고 믿는 쪽이다.

그리고 이는 법인에 있어서도 마찬가지이다. 나는 오래된 기업이 신생 기업에 비해서 가질 수 있는 거의 유일한 장점은 기록이라고 믿는다. 직원으로서 개인의 신체에 축적되는 경험은 개인에게 귀속된다. 이 때 이 경험을 법인과 개인이 공유할 수 있는 방법은 기록밖에 없다. 만약에 이 경험에 대한 어떠한 기록도 남기지 않는다면, 개인은 회사에 다니면서 얻은 수많은 신체에 각인된 능력(혹은 기록)들을 가지고 회사를 떠날 수 있지만, 기업은 그 사람이 떠난 이후에 아무런 가치도 얻지 못 할 것이다. 이런 일은 현실에서 빈번하게 일어나는 것처럼 보인다. 전임자가 떠나고 나면, 후임자는 마치 백지에서 일을 시작하는 것처럼 보이기도 한다. 아니면 전임자가 떠날 때야 비로소 인수인계를 하라고 이야기하지만 이 역시 빈틈이 많고 문서화 되기보다는 구전되는 경우가 많다. 하지만 기업 내에 기록을 위한 충분한 시스템이 갖추어져있다면, 인수인계라는 것은 업무에 대한 것이 아니라, 권한에 대한 것만으로도 충분해질 것이다.

법인은 어떤 면에서 개인보다도 이러한 가치를 인지하는데 무능할 수 있다. 왜냐면 법인으로서 살아남기 위해서는 장기적인 맥락에서 가치를 축적하는 것보다 당장 돈을 보는 것이 급급하기 때문이고, 법인은 스스로 기록의 가치를 인지하지 못 하고, 항상 법인을 운영하는 주체들에 의해서 기록의 가치를 인지할 수 있기 때문이다. 법인이라고 본질이 달라지는 것은 아니다. 개인보다 나은 점도 있다. 그 가치를 이해하기만 한다면, 시스템으로 잘 갖추기만 한다면 기록은 자동적으로 이루어지고 또한 오랜 시간 남아 법인의 가치를 높여갈 것이다.

테크 기업들의 매출 주도 성장: 아틀라시안, 아마존, 그리고 애플

The Entire Economy Is MoviePass Now. Enjoy It While You Can. 뉴욕 타임즈의 5월 16일자 기사.


요즘 느끼고 있던 테크 기업들의 매출과 이익에 대한 감정이 이 기사 하나에 잘 정리되어있다. 미국에서 작년에 상장한 기업 중 76%는 적자였다고 한다. 그리고 잘 알려진 적지않은 테크 기업들이 적자거나 이제 막 흑자로 돌아선 정도이다. 잘나가는 것처럼 느껴지는 테크 기업들 대부분이 이렇다. 잘 나간다는 것처럼 보이는 것은 외형적인 성장에 의존하는 경향이 강하다. 일단 지속적으로 사용자를 확보해서 매출을 늘려나간다. 이런 기업들의 외형 성장은 눈부시다. 최소 매년 20% 이상씩 꾸준히 매출이 성장한다. 하지만 이익이 매출만큼 성장하는 것은 아니다.

오히려 반대로 매출에 비례해서 손실이 커져나가는 경우도 있다. 개인적으로 의아하게 느껴졌던 기업 중 하나가 아틀라시안(Atlassian Corporation, NASDAQ:TEAM)이었다. 아틀라시안의 협업 소프트웨어의 대표적인 기업이다. 아틀라시안의 지라는 독보적인 지위를 가지고 있고, 구독제 모델을 가지고 있기 때문에 지속적으로 성장해나가는 좋은 기업일 것이라고 막연히 생각해왔다. 하지만 막상 재무 정보를 열어보니 상황은 조금 달랐다.

물론 주가와 매출은 지속적으로 성장해왔다. 아틀라시안의 2013년 매출은 1억 5천만 달러 정도에서 2017년에 6억 달러를 기록했다. 하지만 순이익을 보면 조금 상황이 다르다. 2013년에는 1천만 달러 순이익을 기록했지만, 매출 규모가 증가에 따라서 순이익이 줄어들더니 2017년에는 4천만 달러 손실을 기록했다. 기사에서 언급된 사례는 아니지만 수익보다 외형적인 성장을 쫓아가는 전형적인 테크 기업의 모습을 보여주고 있다.

물론 외형을 키우는 것이 나쁜 것은 아니다. 외형을 키우고 이익을 내면 된다. 이런 성장의 좋은 성공 사례로는 아마존이 있다. 기사에서도 성공적으로 흑자 전환한 The king of money-loserse로 아마존을 꼽고 있다.

The king of money-losers, of course, is Amazon, which went years without turning a profit. Instead, it plowed billions of dollars back into its business, building out its e-commerce infrastructure and jump-starting side efforts like Amazon Web Services and Amazon Prime Video. Those years of investments paid off, and Amazon is now the second most valuable company in the world, with $1.6 billion in profit last quarter alone.

현재 아마존은 전 세계 시가총액 2위 회사이다. 하지만 아마존의 성공은 아직 과장된 감이 없지 않아 있다. 애플이 2018년 3월에 발표한 분기 순이익은 138억 달러로, 아마존 설립 이래의 총이익인 96억 달러보다도 많다고 한다.

참고로 애플은 전 세계 시가총액 1위 기업이다. 단순 비교는 어렵겠지만 10년 전과 비교해면 이렇다. 아마존의 매출은 2017년에 2008년보다 9.2배가 성장했다. 순이익은 들쑥날쑥 했지만 최종적으로 4.7배가 성장했다. 애플의 매출은 같은 기간 7배가 성장했다. 순이익은 꾸준히 증가해왔고 최종적으로 10배가 성장했다. 지금은 애플의 성장세가 더뎌진 것처럼 보일지 모르겠지만 매출을 중심으로 키워나가는 기업과의 차이는 여실히 드러난다.

클라우드 혁명의 끝자락에서: 테라폼 모듈로 스쳐보는 인프라스트럭처 추상화의 미래

컴퓨터는 크게 하드웨어와 소프트웨어로 구성된다. 범용 컴퓨터는 고정된 물리적 하드웨어에서 변경 가능한 소프트웨어를 실행 가능하도록 하면서 등장했다. 흥미로운 건 원래 소프트웨어도 물리적 실체가 있었다는 점이다. 그 이전에는 더욱 그랬지만, 천공 카드만 보더라도 눈에 보이고, 만질 수 있고, 촉감이 있고, 온도가 있으며 심지어 사람이 내용을 읽고 이해할 수 있는 물체였다. 하지만 저장장치와 입출력 장치의 발전에 따라서 이러한 물리적인 성질은 사라져버린다. 이제 소프트웨어는 가상적인 실체가 되었다. 눈에 보이지도 않고, 만질 수도 없으며, 촉감도 없고, 온도도 없고 오직 컴퓨터 하드웨어 연결된 출력 장치(모니터)를 통해서만 내용을 확인하거나 실행해볼 수 있는 가상의 존재이다.

하드웨어의 물리적인 지위는 공고해보인다. 특히 입력장치(키보드, 마우스 등)와 출력장치(모니터) 세트로 구성된 인간과 계산 유닛의 인터페이스로서 컴퓨터의 물리적인 실체가 위협 받은 일은 아직까지는 없는 것 같다. 하지만 모든 계산 장치(컴퓨터)가 인간과 직접 상호작용하는 인터페이스와 직접 연결되어있는 것은 아니다. 일반적으로 서버 컴퓨터는 사용자가 이 컴퓨터에 접근하기 위한 물리적인 인터페이스를 가지지 않는다. 이러한 인터페이스는 초기 셋업이나 컴퓨터가 정상적으로 작동하지 않는 비상시에만 사용되며, 평시에는 네트워크를 사용해 외부의 인터페이스를 사용해서 접근한다. 인터페이스로 사용하는 컴퓨터에서는 직접 계산을 하지 않고, 서버 컴퓨터의 자원을 사용해 계산을 할 수 있다.

명령을 내리는 클라이언트 컴퓨터와 계산만을 수행하는 서버 컴퓨터의 구성은 지금은 너무나도 당연한 것이 되었다. (인터페이스 역할을 하는) 컴퓨터에서 가능한 많은 일들이 실제로 클라이언트 컴퓨터에서 일어난다고 생각하면 오산이다. 연산은 네트워크 상에 있는 사람 컴퓨터를 통해서 이루어진다. 단순히 웹브라우저로 어떤 웹사이트에 접속하는 것조차도 사실은 다른 사람 소유의 컴퓨팅 자원을 사용하는 일이다. 네트워크의 본질은 다른 컴퓨팅 자원을 활용하는 일이다.

그렇다고 원격에 존재하는 물리적인 실체가 사라지는 것은 아니다. 서버 컴퓨터는 누군가 조립해서 만든 특정한 CPU와 메모리, 저장용량을 가진 한 단위의 컴퓨터이기 때문이다. 네트워크 너머의 물리적 실체. 인터넷 데이터 센터(IDC)에 가면 이러한 독립적인 단위의 서버 컴퓨터들이 무수히 많이 설치되어있다. 서버 컴퓨터를 관리하는 사람들에게 이런 물리적인 실체와 물리적으로 셀 수 있는 단위를 가진 컴퓨터란 굉장히 중요하다.

하지만 클라우드가 등장하면서 컴퓨터의 단위가 도전받기 시작한다. 예를 들어서 특정한 사양을 가진 컴퓨터 10대가 필요하다고 해보자. 기존에는 IDC 상에 물리적 실체를 가진 서버 컴퓨터 열 대를 설치해서 네트워크 설정을 해야했다. 하지만 클라우드에서는 사양과 필요한 대수를 지정하면 곧바로 서버 컴퓨터들을 사용할 수 있다. 여기서 중요한 점은 클라우드 서비스가 서버 설치 업무를 대행해주는 일을 하는 서비스가 아니라는 점이다. 실제로는 클라우드 데이터 센터에 이미 무수히 많은 서버 컴퓨터가 존재하고 있다. 이러한 서버 컴퓨터들은 여전히 셀 수 있는 물리적 실체를 가지고 있지만, 이제 더 이상 이 물리적인 단위를 기준으로 사용자에게 제공되지는 않는다. 클라우드 서비스는 이러한 인프라스트럭처(서버 컴퓨터들의 집합) 위에서 가상화된 컴퓨팅 자원(=새로운 단위의 서버 컴퓨터)을 제공한다. 따라서 데이터 센터에서 허용하는 한 어떠한 사양(크기)의 컴퓨터라도 요청받는 즉시 생성해서 제공할 수 있게 된 것이다.

가상화라는 기술을 클라우드 서비스에서 처음 사용한 것은 당연히 아니다. 하지만 클라우드가 혁명적이었던 이유는 서버 컴퓨터가 필요한 사람들이 더 이상 서버 컴퓨터의 물리적 실체를 고려할 필요가 없도록 만들어주었다는 점이다. 클라우드 서비스를 제공하는 쪽에게 여전히 서버 컴퓨터는 물리적 실체를 가지고 있지만, 적어도 이를 이용하는 사람들은 서버 컴퓨터의 물리적인 제약에 대해서 고려를 할 필요가 없어졌다. 이제 컴퓨팅 자원은 사양이 고정되어있지 않으며, 아무리 많이 사용하더라도 공간을 차지하지도 않는다. 클라우드가 등장하면서 이제 컴퓨터를 세는 단위는 물리적 하드웨어가 아니며, 클라우드 위에서 진정으로 가상화된 실체가 되었다.

클라우드 데이터 센터는 물리적인 실체를 가지고 있지만 클라우드 서비스의 컴퓨팅 자원을 비롯한 모든 하드웨어 장비는 가상화되어있다. (제대로 된) 클라우드 서비스들은 기존의 물리적인 하드웨어가 하는 역할을 하는 가상화된 장치를 생성하고 수정하고 삭제하는 일련의 작업을 코드로 실행할 수 있도록 API를 제공한다. 소프트웨어가 동적인 성격을 가진 것처럼, 소프트웨어를 실행하는 하드웨어 자체가 동적으로 구성될 수 있는 가능성이 열린 것이다. 물리적인 실체는 이제 가상화된 자원을 조작하는 인터페이스 뒤로 숨어버린다. 하드웨어가 소프트웨어로 추상화되었다.

컴퓨터 네트워크 구성을 위한 물리적인 장비들을 구성하고 설계한 것을 아키텍처라고 한다. 설계란 제약 위에서 어떤 문제를 해결하기 위해 상상력을 펼치는 공간이다. 그러나 현실에서 아키텍처를 구성하는 요소는 모두 물리적인 실체를 가지고 있으며, 이러한 설계로부터 구현된 아키텍처가 얼마나 경직되어있는지는 쉽게 상상할 수 있다. 물리적으로 구현되어야하는 아키텍처는 자연스럽게 물리적인 제약들에 대해서 고려해야만 한다. 가장 간단한 경우를 생각해보자. 서버 컴퓨터를 한 두 대 설치할 때 공간은 문제가 아니지만, 이런 서버를 1000대씩 설치하기 시작한다면 공간에 대한 비용이나, 건물이 서버 무게를 견딜만큼 튼튼한지가 현실적인 문제가 된다. 처음 구상하던 아키텍처를 서버실의 형태나 크기를 확인하고 다시 처음부터 설계해야할 수도 있다. 이외에도 다양한 구성요소들이 있으며 처음 아키텍처를 구현할 때 드는 비용도 높지만, 이를 다시 수정하는 비용은 처음에 설치하는 비용보다 더 클 수도 있다. 이런 면에서는 컴퓨팅은 물리적 공간을 설계하는 건축의 영역에 걸쳐있다.

클라우드를 감히 혁명이라고 말하는 것은 이러한 아키텍처의 물리적인 속성을 증발시켜버렸기 때문이다. 클라우드 위의 모든 자원은 가상화되어있으며 아키텍처를 상상하기만 한다면 그대로 만들어질 수 있다. 물론 기존 하드웨어 리소스를 가상화된 리소스가 완벽히 대체하는 것은 아니다. 클라우드 위에서는 아키텍처를 설계하기 위해서는 클라우드 리소스들이 어떤 역할을 하는지에 대한 충분한 이해가 필요하며, 게임의 논리 자체가 달라졌으므로 완전히 새로운 설계 원칙들을 익혀야만 한다. 기능이 아니라, 리소스의 실체 때문에 설계 전략도 달라진다.

클라우드 위에도 여전히 설계와 구현 사이의 갭은 존재한다. 설계를 클라우드 자원들로 구현하는 작업은 의외로 쉽지 않다. 이런 작업을 처음하는 사람이라면 상당한 시행착오를 거쳐야만 한다. 클라우드가 다음으로 발전할 방향은 사실 여기서부터 이미 확정되어있던 걸지도 모른다.

설계와 구현의 갭을 메우기 위해 자연스럽게 코드로서의 인프라스트럭처(Infrastructure as Code, IaC) 패러다임이 등장한다. 여기서 코드는 절차적인 명령이라기보다는 아키텍처 설계를 위한 문법이라고 이해되어야한다. 이러한 대표적인 도구로는 아마존 웹 서비스의 클라우드 포메이션(CloudFormation)이나 하시코프의 테라폼(Terraform)이 있다. 테라폼은 HCL이라는 전용 언어를 사용하며, 이를 사용해 컴퓨팅 자원을 정의하는 코드는 다음과 같다.

resource "aws_instance" "web" {
  instance_type = "t2.micro"
}

이 코드가 곧 컴퓨팅 자원 한 단위를 정의하는 명령어이다. 실제로 이 코드가 곧 컴퓨팅 자원이라는 것을 이해한다면 클라우드의 강력함을 실감할 수 있을 것이다. 이 코드 어디에도 물리적인 실체에 대한 고려는 없다.

훨씬 더 좋은 성능을 가진 컴퓨터 10 단위를 정의하는 코드도 크게 다르지 않다. instance_typecount 속성을 지정하면 그만이다.

resource "aws_instance" "web" {
  instance_type = "m4.4xlarge"
  count = 10
}

IaC는 아키텍처 설계와 구현의 갭을 메워준다. 테라폼의 HCL 코드는 그 자체가 클라우드 아키텍처의 설계도이며 동시에 구현이다. 테라폼에는 planapply 명령어가 있는데, plan은 HCL로 설계한 아키텍처가 실제로 구현 가능한 아키텍처인지를 임시로 검증해주며, apply는 설계도 대로 클라우드 위에 아키텍처를 구현한다. 설계도가 곧 실체가 되었다. 이 실체는 기존의 물리적인 하드웨어들로 구성된 아키텍처와 같은 역할을 하는 실체이다.

이러한 변화는 놀라운 것이지만 아직 끝이 아니다. 테라폼에는 모듈 기능이 있다. 모듈은 아키텍처 재사용을 위한 추상화된 형태로 아키텍처를 작성하는 방식을 지원한다. 모듈은 재사용될 수 있으며 몇 가지 매개변수에 따라 다양한 양태로 실체화된다. 물리적인 아키텍처든 클라우드 아키텍처든 기존에 아키텍처를 조금이라도 설계해보고 구현해본 적이 있다면 이러한 접근이 마냥 반갑지만은 않을 것이다. 앞서 살펴보았지만 하드웨어가 물리적인 실체였던 시절에 아키텍처란 매우 경직되어있는 것이었다. 아키텍처는 다양한 제약들을 바탕으로 최적화된 형태로 만들어져야 했으며, 아키텍처 설계를 위해 공유할만한 패턴들이 존재하더라도 아키텍처 자체를 재사용한다는 발상은 상식적으로 받아들이기 쉽지 않은 것이었다. 클라우드에 온다고 이런 사정이 완전히 달라지는 것은 아니다. 일반적인 아키텍처 설계를 받아들인다고 하더라도 항상 자신의 상황에 맞춰 최적화를 해야하기 때문이다. 따라서 여전히 아키텍처는 재활용하는 것이 아니라 상황에 따라 최적화된 형태로 매번 재설계하는 것이었다. 나는 모듈 기능에 대해 회의적인 입장이었지만, 하시코프(Hashicorp)는 이런 생각에 게의치 않고 하시콘프(Hashiconf) 2017에서 테라폼 모듈 레지스트리(Terraform Module Registry)를 발표한다.

테라폼 모듈의 본질은 아키텍처를 추상화하는 것이다. 이에 대한 불신은 아키텍처가 추상화할 수 있는 성질의 것인지에 대한 의문이다. 테라폼 모듈 레지스트리를 보면서 아키텍처 추상화가 비록 어려운 것이더라도 결국 이 방향으로 발전해나갈 것이라는 확신이 들었다. 아키텍처가 추상화 되면 복잡한 설계는 모듈 뒤로 숨어버린다. 모듈을 사용하면 복잡한 아키텍처 구현에 대한 충분한이해 없이도 아키텍처의 가치를 충분히 향유할 수 있게 된다. 예를 들어보자. 클라우드에서 병렬적으로 딥 러닝 학습을 수행하고 싶은 데이터 과학자가 있다. 하지만 클라우드 위에서 이러한 학습 환경을 구축하기 위해서는 클라우드를 비롯해 아키텍처에 대해서도 상당한 지식을 필요로 한다. 하지만 이러한 학습 환경을 지원하는 잘 구현된 아키텍처 모듈이 있다면 이 데이터 과학자는 이 아키텍처를 사용하고 자신은 학습 프로그램을 개발하는 데만 집중할 수 있다.

이런 일이 정말로 가능하냐고 묻는다면 현재 내 답은 당연히 아니오이다. 아키텍처에 대한 이해없이 아키텍처를 향유한다는 것 자체가 어려운 일이기 때문이다. 모듈은 여전히 가상화된 자원 자체를 완벽하게 숨겨주지는 않는다. 사용자는 아키텍처 모듈을 사용하더라도 클라우드 콘솔과 API를 직접 사용해서 많은 문제에 대응해야 하며, 이를 위해서 극단적인 경우 아키텍처 모듈을 설계한 사람만큼의 지식이 필요할 수도 있다. 또 다른 문제도 있다. 원칙적으로 모듈을 같은 클라우드 계정 안에서 매개변수만 바꿔서 여러번 정의할 수 있어야한다. 그러나 클라우드는 모듈을 구현하기 위해 충분히 격리된 공간을 제공하지 않는다. 이 때문에 아키텍처를 모듈로 추상화하는 작업이나 사용하는 방식은 상당히 교묘해질 수 있다. 예를 들어 이름 충돌을 방지하기 위해서 리소스의 자원이 어느 정도 범위에서 공유되는지 이해하고 있어야한다. AWS의 경우 S3의 이름은 모든 사용자 수준에서 공유되며, IAM은 계정 수준에서 공유된다. ELB는 리소스 이름이 곧 id로 사용되며(즉, 이름이 같으면 충돌이 난다), EC2와 같은 어떤 자원은 리소스 이름을 태그로 지정되기 때문에 전혀 충돌이 일어날 일이 없기도 하다. 모듈을 정의하려면 추상적으로 아키텍처를 설계해야하며 이러한 예상가능한 충돌에 대해서 충분히 대비해야한다. 바로 이러한 이유들 때문에 아키텍처 모듈(추상화)에 대한 의심은 합리적으로 보인다.

마법은 없다. 현실적으로 아직은 쉽지 않고, 많은 시행 착오들이 필요해보인다. 현실적인 한계는 있지만, 그럼에도 불구하고 아키텍처 추상화는 충분히 이상적인 발전 방향이다. 결국에 테라폼의 모듈도 진화해나갈 것이고, 클라우드 역시 이러한 추상화를 충분히 지원하는 방향으로 진화해나갈 것이다. 컴퓨터의 진화라는 관점에서 이러한 변화는 하루 아침에 시작된 것이 아니다. 이 아래에는 분명히 물리적인 제약으로부터의 해방과 더 높은 추상화라는 일관적인 저류가 흐르고 있다.

블로그nacyot이 운영합니다.