우리가 흔히 접하는 윈도우OS를 이용하는 퍼스널 컴퓨터 안에는 앞서 설명한 ‘연산’, ‘조건문’, ‘루프’, ‘데이터’, ‘프로세스’를 효과적으로 하기 위해 만든 나름 최선의 조합의 ‘역사’가 들어있다. 그 역사는 지금 우리가 어떻게 ‘인공지능’이나 ‘클라우드’, ‘빅데이터’ 같은 새로운 컴퓨팅 아키텍처를 갖게 되었는지에 대해 이해할 수 있는 단서를 제공한다.
퍼스널 컴퓨터와 컴퓨팅 아키텍처의 진화
최적의 마이크로 연산을 위해 CPU는 진화해왔다. 그 안에서 초당 더 많은 연산을 하기 위해 ‘마스터 클럭’이 더 빨라졌고, 연산의 진행 과정에서 다양한 유형의 연산에 최적화된 형태의 데이터를 저장하고 읽어들일 수 있도록 CPU 내에 임시 저장용 메모리가 탑재되었고(L2 Cache) 좀 덩치가 큰 프로그램 명령과 프로세스를 실행하기 위해 고속으로 CPU가 읽어들일 수 있는 메모리 영역에 임시 저장해두기 위해서는 DRAM이라고 불리는 메모리와 CPU 간의 고속 통신을 위한 통신 방식이 CPU의 PIN과 소켓을 통해 메인보드의 PCB(인쇄회로기판)를 통해 이 둘을 연결한다.
데이터를 미디어에 쓰는 기술도 나름의 역사로 발전해 왔다. 그중 가장 놀랍게 발전한 것은 고해상도 디스플레이에 데이터를 ‘그래픽’ 형식으로 쓰는 것이다. 디스플레이에 쓰게 되는 데이터는 대개 데이터량은 매우 크지만 서로 간에 의존도가 낮기 때문에, 쉽게 여러 덩어리로 쪼갤 수 있다. 그러므로 디스플레이에 더 빠르게 더 많은 양의 데이터를 쓰기 위해서는 데이터를 쪼개서 ‘병렬’로 처리하는 것이 매우 효과적이다. 그런 이유에서 PC의 그래픽카드는 ‘병렬 데이터 연산’을 처리하는데 효과적인 연산 모듈과 메모리 구조를 담고 있으며, 이들의 연결 형태도 병렬 연산에 최적화되어 있다.
‘그림’으로 표현하는 ‘데이터 쓰기’를 제공한다는 점에서 디스플레이와 유사한 것은 ‘프린터’였다. 그런 이유에서 프린터 케이블은 컴퓨터로부터 매우 대량의 데이터를 외부 기기로 ‘쓰는’ 용도의 케이블이었다. PC의 초기에 사용된 이 케이블은 ‘병렬포트’라고 불린 단자를 통해 마치 프린터를 컴퓨터에 연결된 ‘부품’과 비슷한 방식으로 연결했다. 그보다 소량의 데이터를 주고 받는 것은 ‘시리얼 포트’라고 불리는 불리는 것을 이용했는데, 지금도 PC의 뒷면에는 PS/2와 같은 마우스나 키보드를 연결할 수 있는 포트들이 남아 있는 경우가 있다.
PC에서는 주로 CPU가 너무 많은 일을 처리하지 않아도 되도록 메인보드에 회로(버스)를 깔아놓고 입출력 같은 역할을 분리해냄으로써 CPU가 최대한의 성능을 내면서도 입출력 성능을 유지할 수 있도록 하는 방향으로 아키텍처가 진화해 왔다. ISA, PCI, SCSI와 같은 용어를 들어봤다면, 그것은 아마 컴퓨팅을 위해 다른 장치를 확장하여 다는 경우였을 것이다. 퍼스널 컴퓨터가 발달할 수록 점점 더 속도가 빠르고 범용적인 메인보드 위의 버스(컴퓨터 내에서 구성 요소들 간 연결을 위해 메인 보드에 인쇄된 여러 차로를 가진 통신 선로라고 보면 된다)와 포트(컴퓨터 내의 구성 요소 뿐 아니라 외부 장치로의 연결까지를 담당하는 연결점)이 발전해 왔다. 그리고 그 중 하나가 바로 ‘통신 모뎀’(LAN이나 와이파이를 포함하는)이다.
파일 시스템과 데이터베이스
초기 컴퓨터에는 ‘파일’이라는 개념이 없었다. 왜냐하면 ‘파일’이라는 개념은 마그네틱 저장장치가 등장한 이후에 나타난 ‘특정 응용 프로그램이 처리하는 데이터 단위’이기 때문이다. 파일이라는 개념이 등장하자, 컴퓨터의 마그네틱 저장장치에 대한 ‘관리’가 필요해졌는데, 그 이유는 CPU가 특정한 파일이 마그네틱 저장장치의 어느 위치에 기록되어 있는지를 알고 있어야 찾아서 읽어들일 수가 있기 때문이었다. 그러다보니 ‘저장위치정보, 파일식별자’ 쌍으로된 별도의 테이블이 저장장치의 정해진 위치에 기록되어 있어야 했고, 이것이 고도화된 것이 이른바 ‘파일시스템’이다. FAT16, FAT32, NTFS와 같은 용어는 바로 이 ‘파일시스템’의 명칭들이다.
비유를 들자면 FAT32는 ‘동이름 주소체계에 의한 주소등록원부’이고 NTFS는 ‘도로명 주소체계에 의한 주소등록원부’라고 할 수 있다. 만약 ‘도로명 주소원부’만 갖고 있는 상태에서 누군가 ‘동이름 주소’를 불러주면 그 주소가 어디 있는 장소인지 알 수 없듯이, NTFS로 포맷된(주소 원부가 작성된) 하드디스크를 FAT32만 지원하는 컴퓨터로는 읽어들일 수가 없다. ‘포맷’이라는 용어도 일상에서는 ‘데이터 삭제’의 의미로 사용하지만, 실제로는 ‘주소 재정리’의 의미다. 주소가 바뀌면 데이터를 찾을 수 없게되기 때문에 마치 데이터가 ‘삭제’된 것처럼 느껴지는 ‘빠른포맷(하이레벨포맷)’과 실제로 주소 정리한 후에 건물들을 모두 철거해서 빈땅으로 만드는(데이터 내용도 모두 0으로 만드는) ‘로우레벨포맷’이 있다.
그런데 ‘파일’은 특정한 응용 프로그램이 사용하는 데이터를 그 응용 프로그램이 정한 규격에 의해 저장하는 방식이다. 따라서 파일 안의 데이터를 사용하기 위해서는 반드시 그것을 읽어들일 수 있는 응용 프로그램을 필요로 한다. 이것을 넓은 의미로 ‘뷰어(Viewer)’라고 하는데, 파일을 작성하는 프로그램과 동일한 프로그램인 경우도 있고 그렇지 않은 경우도 있다. 하지만 ‘파일’은 컴퓨팅 입장에서보면 몇 가지 문제를 안고 있다.
먼저 다른 프로그램이 데이터에 접근할 수 없다는 것이다. 물론 이 문제를 해결하기 위해 파일 규격을 표준화하려는 시도도 있다. 하지만 웹(HTML)이나 이미지(BMP, JPG)와 같이 처음부터 공동으로 만들어진 규격이 아니라면, 한 회사가 만든 파일 규격에 대해 완전하게 호환되는 뷰어를 만들기는 쉽지 않다. 왜냐하면 그 안에는 그 파일 규격을 만든 회사의 노하우가 담겨있기 때문이다.
그 다음으로는 파일의 크기가 커지면, 그 안에 있는 정보의 일부분을 이용하고자 하는 경우에도 전체 파일을 열어야(메모리에 읽어들여야) 하므로 전체 컴퓨팅 효율이 떨어진다. 일부 데이터를 자주 갱신해야 하는 응용 프로그램의 경우 실제로 데이터를 연산하는 것에 비해 파일을 열고 다시 저장매체에 쓰는데 들어가는 자원이 너무 커진다. 이 문제에 대한 해결책으로 제시된 것이 이른바 ‘데이터베이스(DBMS)’이다.
그러나 ‘파일’이 이런 한계를 가진다는 선입견을 깨버린 것이 바로 구글의 클라우드 컴퓨팅 아키텍처인데, ‘파일’을 기반으로 하더라도 파일의 내용 자체를 갱신하는 것이 아니라면, 파일 시스템을 이용해서도 다양한 응용 프로그램이 데이터를 활용하는 컴퓨팅 방법(맵리듀스MapReduce와 같은 방식으로)을 만들 수 있으며, 그 효과는 데이터량이 엄청나게 커졌을 때 가장 극대화된다는 것이다.
파일 시스템과 DBMS, 빅데이터
빅데이터에 대해 보통 사람들이 이해하는 방식은 ‘데이터를 많이 모으면 전에는 할 수 없던 일을 할 수 있게 된다’는 것이다. 그러나 이것은 한 가지 질문을 숨기고 있다. 그것은 바로 ‘왜 전에는 이것을 못했을까?’라는 질문이다. 그 답을 하자면, 그것은 바로 컴퓨팅 비용 때문이다. 빅데이터는 과거의 파일 시스템이나 DBMS를 기반으로 하는 컴퓨팅의 비용구조로는 감당할 수 없는 데이터의 양과 데이터 트랜잭션을 의미한다. 너무나 많은 양의 데이터가 짧은 시간에 발생하여 이를 채 연산하기도 전에 새로운 데이터가 밀려든다. 그렇다고 컴퓨팅 자원의 양을 늘리자니 비용이 기하급수적으로 증가한다. 그에비해 단기적으로 그러한 데이터를 컴퓨팅하여 얻을 수 있는 이익은 크지 않다. 합리적 사람이라면 이 데이터는 버리는 것이 맞다.
하지만 빅데이터 컴퓨팅의 창시자들은 이 ‘비용 문제’를 해결해냈다. 그러기 위해서는 가장 먼저 버려야 할 것이 ‘관계형 DBMS’다. “’DBMS’로 시작되는 문장을 모두 찾아줘’ 같은 명령을 ‘쿼리(Query)’라고 하는데, 이 명령을 수행하기 위해 DBMS는 자신의 Index 테이블을 뒤지기 시작하고, 그 조건에 맞는 ‘레코드’를 결과로 내어준다. 빅데이터 컴퓨팅 창시자들은 바로 이것이 ‘너무 고비용’이라고 내다 버렸다. 이것은 DBMS가 데이터를 파일 단위로 열고 갱신하지 않기 때문에 비용 효율성이 높은 데이터 컴퓨팅 아키텍처를 제공한다는 ‘고정 관념’에 정면으로 배치되는 접근이다. 그러나 빅데이터 컴퓨팅의 창시자들은 이들이 처리해야 할 데이터가 ‘원본’ 자체를 갱신할 이유가 없는 데이터라는 사실을 발견해 냈고, 구글이 클라우드 컴퓨팅을 발명할 때 했던 접근법을 실시간 데이터들에 그대로 적용해본 것이다. 이 말이 무슨 뜻인지 이야기해 보기로 하자.
일단 ‘데이터’를 만들 때부터 가장 간단한 규칙을 지켜서 ‘인덱싱 절차 없이 검색 가능하게’ 데이터를 만드는 것이다. DBMS에서 우리가 어떤 ‘쿼리’로 데이터를 찾을 수 있는 이유는 ‘인덱싱’이 되어 있기 때문이다. 그런데 만약 모든 데이터의 형식이 ‘Key, Value’ 구조여서 오직 ‘Key’를 ‘쿼리’로 입력하면 ‘Value’ 값을 내주는 방식의 데이터 컴퓨팅이라면 인덱싱이 필요할까? 일단 여기서 비용을 줄인 것이다.
물론 모든 데이터가 그렇게 생성되기는 어렵다. 그러나 데이터 컴퓨팅의 전처리 과정에서 모든 데이터를 ‘Key, Value’ 구조로 바꿔주는 작업을 미리 해둔다면, 그 다음부터는 ‘인덱싱 없는 검색’이나 ‘임의의 응용 프로그램(‘Key, Value’ 구조를 고려해서 만들기만 하면)에 의한 데이터 접근’이라는 DBMS의 잇점을 그대로 누릴 수 있게 된다.
그 다음으로는 ‘저장 장치에 쓰지 않고 연산하기’라는 방법이다. 이것은 ‘전자적 현상’을 기초로 하는 ‘연산’에 비해 여전히 ‘전기적 현상’을 이용하는 ‘데이터 저장’의 속도가 느리다는 것을 고려한 것이다. 네트워크를 데이터 저장 장치로 보고, 그냥 네트워크로부터 데이터를 읽어들여서 바로 ‘연산’하는 것인데, 여기서도 ‘Key, Value’ 구조의 장점이 나타난다.
왜냐하면 ‘데이터’가 ‘Key, Value’ 구조로 되어 있으면, 우리는 네트워크를 단순히 ‘저장 장치’가 아니라 DBMS 처럼 사용할 수 있기 때문이다. ‘특정한 Key 값을 가진 데이터를 연산’하려는 프로세스가 네트워크로부터 데이터를 받아들여 ‘Key’ 값이 자신이 ‘연산’하려는 대상의 ‘Key’ 값과 일치하면 그 데이터만을 받아들여 ‘연산’하면, 이는 마치 응용 프로그램이 ‘Key’ 값으로 ‘쿼리’를 DBMS에 보내서 반환된 결과값을 가지고 ‘연산’하는 것과 같은 컴퓨팅 방법을 제공하기 때문이다. 물론 이것을 더 효과적으로 하기 위해 다양한 응용 기법들을 사용할 수 있지만 본질은 이것이다.
(출처 : http://lambda-architecture.net/)
그럼 ‘데이터는 어떻게 되냐?’는 의문이 생길 수 있다. 데이터는 ‘연산’으로 보내진 후에 저장 장치에 ‘쓰기’를 하면 된다. 그것도 하나씩이 아니라 여러개를 모아서 큰 파일 단위로 ‘쓰기’를 해도 된다.(구글은 64MB 단위로 쓰는 방식을 택했다) 당연히 ‘쓰기’를 한 후에도 ‘연산’은 계속된다. 이때 진행하는 연산은 ‘실시간’ 처리를 필요로 하지 않는 연산들인데, 대개는 천천히 ‘배치(batch)’ 작업으로 처리하는 경우가 대부분이다. ‘배치’ 작업이 문제가 없는 이유는 다른 데이터와는 달리 그 사이에 데이터를 ‘갱신’하려는 프로세스가 없기 때문이다.
이것이 바로 빅데이터 컴퓨팅에서 사용되는 ‘람다(Lambda)’ 아키텍처라는 것인데, 실시간으로 IoT 기기와 같은 데이터 소스로부터 엄청난 양의 데이터가 몰려들어올때, 그 데이터에서 ‘실시간’으로 처리해야 하는 연산은 ‘저장 장치’에 쓰기 전에 ‘Key’ 값에 따라 전담 응용 프로그램이 받아서 ‘연산’ 처리하고, 그 외의 ‘연산’은 ‘저장’된 후에 천천히 ‘배치’ 프로세스로 처리하는 것을 의미한다.
이것으로 충분한 설명이 된 것은 아니다. 이 설명은 ‘빅데이터’ 같은 용어가 왜 ‘가치가 있다’고 이야기되는 것인지에 대해 조금 더 이해하는데 도움이 되는 것을 목적으로 하는 설명이다. 전문가들의 설명이 빈 곳을 찾아서 메우는.
(다음편은, ‘DBMS와 응용 프로그램 아키텍처의 진화 결과로서의 인공지능’ 이야기를 써볼 계획인데, 너무 단순화했다는 비난을 받을 가능성이 있지만 ‘일반인들을 위한’ 것이라는 방어막을 치고 써볼 생각이다.)
