IT에 대한 짧은 단상

   IT라는 것은 우리가 속해서 항상 일을 하고 있는 영역이긴 하다. 하지만 삶도 비슷하지만 정신없이 살다 보면 현재 어디에 있는지 잊어버리기 쉽다. IT에 대해서 어떤 것이라는 의견을 내기는 너무 넓고 많은 전문가들이 있는 영역이라 조금 조심스럽긴 하지만 개인적인 경험을 기반으로 한번 이야기를 풀어보려 한다.

 

1.1  자동화의 추구

    사람은 아마도 본능적이라고 생각될 만큼 효율적인 면을 추구하는 편인 것 같다. 본인이 직접 참여하지 않아도 축적된 지식적 패턴을 이용해 자동으로 돌아가는 기술적, 경제적인 무언가를 만드는 것을 계속적으로 추구해 왔다고 본다. 해당 부분이 초기에는 물리적인 요소와 대상을 기반으로 시도가 되었다고 보고, 현재는 사람의 행동과 정신적인 부분 양 쪽을 목표로 나아가고 있다고 본다.

 

    물리적인 부분을 여기에서 얘기할 건 아니고, 또 요즘은 물리적인 부분이 데이터 화와 AI 같은 측면과 결합해 결국 논리적인 문제로 귀결되는 듯하니 논리적인 부분에 대해 얘기해 보자. 논리적인 부분의 자동화에 대해서는 주판이나 톱니바퀴 및 실린더를 이용한 기계식 컴퓨터를 이용해 자동으로 계산하는 시도에서부터 시작했다고 본다. 증기 기관 등의 기계식 자동화는 기존에 사람이 하던 방식보다 몇 백배(인간의 달리기 속도가 몇십 킬로 정도이고, 이러한 물리 엔진이 최대화된 전투기 속도가 몇 천 킬로 미터인 부분으로 추정할 때) 빠른 자동화를 이뤄냈지만, 아쉽게도 거시 물리 환경에 제한되기 때문에 논리의 자동화 측면에서는 아주 큰 변화를 가져오지는 못했다고 생각한다.

[그림 1-1 증기 기관]

  이후 진동 및 전기(전자)를 이용해 움직이는 논리 게이트(and, or, 트랜지스터)가 발명이 되었고, 해당 논리 게이트를 활용한 사칙 연산 및 상태 저장 등의 알고리즘이 현대 프로그램의 기반이 되지 않았나 싶다. 이러한 논리 게이트에 기반하여 연산을 하는 CPU, GPU와, 해당 신호를 임시 또는 영구로 저장하는 테이프, 메모리, HDD, SSD, 그 사이를 중계하는 버스 등이 생겼다.

 

    CPU는 수십 억 개의 트랜지스터 반도체의 집합체이며 1초에 10억 번의 신호에 동기화되어 수천만 번의 사칙연산을 할 수가 있다고 한다.

 

    GPU는 CPU의 절차적인 연산의 한계를 뛰어넘어(물론 CPU 도 코어랑, 쓰레드 같은 걸 사용해 제한적으로 병렬 수행을 하지만) CPU 보다는 연산의 자유도는 작지만 서로 독립적인 데이터의 병렬 처리를 진행한다. RTX 3090의 경우 만개의 코어가 동시에 연산한다고 하며, 이런 부분이 모니터의 픽셀 값 계산, 벡터, 행렬 연산에 장점을 가져와 게임에서 사용하는 DirectX 나 AI 분야에서 사용하는 CUDA 라이브러리 등을 통해서 기술자들이 쉽게 병렬 연산의 혜택을 이용할 수 있도록 제공하고 있다.

 

    또한 요즘에는 컴퓨터나 모바일 장비 내의 데이터에 기본적으로 적용되고 있는 암복호화 작업에 대해 CPU 성능의 저하가 적으면서도 빠르게 지원하기 위한 암호화 연산 전용 칩들도 메인보드 내에 탑재되어 있다고 한다.

[그림 1-2 진동과 전기(전자)의 이용]

    컴퓨터로 이루어진 여러 세상은 컴퓨터 내부 동작을 이해할 기회가 없던 사람들의 입장에서는 신기하고, 이해하기 힘든 마법 같을 진 모르지만, 컴퓨터를 이용한 자동화된 동작들은 사실 엄청 빠르고 단순한 동작들의 조합에 의한 눈 속임으로도 볼 수 있다. 앞서 얘기한 초당 몇 천만번의 연산(요즘은 당연히 이것도 여러 CPU 나 컴퓨터를 통해 병렬로 더 많이 일어난다), 몇 만개의 동시 연산에 의해서 사람에 비해 엄청 빠른 동작으로 처리하는 연산 능력을 현실과 등가로 디지털 한 데이터(텍스트, 그림, 영상, 3D 구조체), 그 데이터를 받아들이고 표시해 주는 하드웨어와 연결시킴으로써 인간의 여러 인지 능력에 어필하여 현실에 의미가 있는 마법 같은 일이 실시간으로 일어난 것으로 보이게 한다.

 

   결국 거시적 힘을 이용한 자동화를 벗어나 미시적 힘을 이용하는 컴퓨터를 이용 함으로서 추가로 미시적 힘을 시뮬레이션하고 컨트롤하기가 가능해졌다고 본다. 이렇게 과학 분야가 발전함으로써 계산은 컴퓨터에게 맡기고 사람은 추상적 생각 또는 인터페이스에 집중하는 게 가능 해졌다. 뭐 이것도 검색엔진 기술이 점점 생성형 AI 기술에게 자리를 뺏기고 있다 하고, 사람의 일자리도 그럴 거라고 하고 있고, 양자 컴퓨터 같은 새로운 접근 방식들에 의해서 엎치락뒤치락하는 분위기인 것 같긴 하지만 말이다. 이 부분은 다른 주제에서 조그마한 근거라도 기반해 개인적인 의견을 얘기해보려 한다.

 

1.2  IT의 시작

    컴퓨터 아키텍쳐는 레고블록과 비슷한 느낌이 있다. 지금 보면 조촐한 초기의 8086 CPU부터 시작해서 인텔에서는 펜티엄, 하스웰, 아이스레이크 등의 n세대 CPU 가 계속 나오고 있으며, AMD에서도 애슬론, 라이젠 등의 CPU들이 계보를 잇고 있다. 애플은 아예 CPU에 OS를 맞추지 않고(뭐 하드웨어 의존성 탈피 등의 다른 이유도 있겠지만) OS에 하드웨어를 맞춘 새로운 m1~m3 CPU+GPU를 만들어 성능 향상과 소프트웨어와 하드웨어 플랫폼의 완성을 꾀하고 있는 듯하다.

 

    건축에서 벌판을 구획하고, 기반 시설을 짓고, 건물을 올리 듯이 CPU, 디스크, 램, 캐시메모리, 메인 보드, 파워 등 이쪽에서 얘기하는 여러 물리적 구조들을 조합해 범용 하드웨어 환경들이 준비되고 이 환경을 움직이는 기계어를 감싼 어셈블리, C 언어를 이용해 MBR, 데이터, 실행파일, 프로세스, 쓰레드 등의 논리적 구조를 응용한 DOS, 윈도우, 리눅스, IOS 등의 운영 체체들이 만들어졌다.

 

    이 과정에서 단순한 논리 연산들을 조합하여 기계어나 어셈블리의 하드웨어를 이용하는 정형화된 동작들이 정의되었으며, 그것을 추상화하여 C와 같은 언어와 해당 언어로 만든 OS들이 만들어졌다. OS는 미리 만들어진 API와 여러 라이브러리들을 제공하여 고수준 언어들이 해당 하드웨어를 다루기 위해서 다시 땅바닥부터 파지 않아도 되게 만들었다. 이런 많은 사람들이 좋아하는 고수준 언어들을 기반으로 라이브러리와 같은 작은 도구들이 엄청 많이 만들어졌고, 이를 통해 여러 오픈 소스나 상용 제품들이 나오게 되었다고 본다.

[그림 1-3 블록 조립 하기]

    그럼 여기서 간단한 C++ 코드와 어셈블리로 그 안을 잠시 살펴보자(개인적으로 잘 아는 분야도 아니어서 이야기의 진행을 위해 최대한 쉬운 예제로 만들어 봤으니 잠시 논리적 모드로 생각을 전환해 보자).

 

    아래 코드는 아주 단순하게 2개의 수를 정의하고 두 수를 더한 값을 커맨드 화면에 뿌려주는 C++ 코드이다. 마지막의 getchar는 사용자 입력을 하나 받아 프로그램 종료 후 커맨드 창이 휙 닫히는 거를 방지하기 위해 넣어봤다.

[그림 1-4 C++ 코드]

 

 

    이제 Visual Studio Community 버전에서 제공하는 기능을 이용하여 해당 코드를 디버그 모드로 실행하면서 C++ 코드와 매칭되는 내부 어셈블리 코드를 봐보자(직접 실행을 해보고 싶으면 위처럼 마우스 오른쪽 버튼으로 클릭해 브레이크 포인트를 걸고 디버그 모드로 실행하면 해당 라인에서 실행이 멈추게 된다. 해당 라인에서 컨텍스트 메뉴를 띄워 “디스어셈블리로 이동” 메뉴를 선택하면 아래 “디스어셈블리” 창이 뜬다. 여기에서 한 단계씩 코드를 실행하며(F11) 레지스터에 저장된 값도 살펴볼 수도 있어 우리가 만든 추상적 코드의 내부 동작을 살펴보기에 좋다).

[그림 1-5 대응하는 어셈블리 코드]

    그럼 해당 코드를 간단히 살펴보자.

    첫 번째 섹션(int a = 1, b = 2, sum = 0)에서 [a], [b], [sum]이라는 특정 포인터가 가리키는 메모리에 숫자 1, 2, 0을 저장(mov)한다.

    두 번째 섹션(sum = a + b)에서 더하기를 하게 되는데 바로 메모리끼리 더할 수는 없고, CPU 내에 있는 여러 연산을 위한 레지스터(CPU 전용의 아주 작은 크기의 빠른 내장 메모리) 들이 있는 데 그중 eax라는 데다 [b] 포인터 주소가 가리키는 값(2)을 ecx라는 데다 [a] 포인트가 가리키는 값(1)을 넣는다. 그리고 두 개의 레지스터를 더하기(add)하게 되는데 이렇게 되면 ecx에 두 레지스터 값을 더한 3이 들어가게 된다. 다음 줄에서 ecx에 담긴 값(3)을 다시 eax로 옮기고, 마지막 줄에서 [sum]이라는 포인터 주소가 가리키는 곳에 eax 값(3)을 저장한다(우리 직관보다는 뭔가 엄청 길을 돌아가는 느낌이 들지만 전자 회로로 이루어진 하드웨어 세상에서는 아마 최적의 경로일 것이다)

    마지막 섹션(printf(“hello, world - %d\n”, sum))에서 edx라는 레지스터에 [sum] 주소에 저장되었던 3을 저장하고, rcx라는 레지스터에 “hello world \d\n”이라는 스트링이 저장된 주소 값을 저장(lea-Load Effective Address) 한다. 이후 윈도우에서 지원하는 printf 함수를 호출하게 되면 아마 해당 함수가 rcx 레지스터 주소 값을 가져다 화면에 출력하려다 %d 값을 발견하고, edx 레지스터의 값(3)을 기존 문자열에 조합을 해서 “hello, world – 3”이라는 값을 만들어 화면에 출력하게 된다.

    

  이런 어셈블리 코드 또한 기계어보다는 조금은 추상적인 코드일 테지만, 명령어가 CPU와 메모리에 행하는 행동을 여러 어셈블리 명령어로 나름 직접적으로 표현해 주기 때문에 앞에서 얘기한 컴퓨터를 구성하는 여러 기본 요소들과 코드의 관계를 좀 더 직관적으로 보여준다고 생각한다.

 

    저 C++ 코드로 개발하기도 어렵긴 하겠지만 더 나아가 만약 우리가 아는 자바, .NET, 파이썬, 고, 리액트, 자바스크립트 같은 고수준 언어가 없고, 어셈블리어로만 현재의 프로그램들을 하나하나 만들어야 한다면 얼마나 막막할까 싶다(같은 언어라도 예전 Visual C++ 1.0 같은 초기 툴을 경험해 본 적이 있다면 현재의. NET과 같은 고수준 툴과 추상적 효율성 면에서 엄청 차이가 나는 부분을 알 수 있다). 실제로 예전 프로그래머들은 그런 시절이 있었을 테고, 지금도 리버싱이나 일부 임베디드 분야들에서는 어셈블리 세상에서 살아가는 사람들이 있을 것이다. 또 C를 전문적으로 다루는 사람들도 가끔 성능 개선을 위해 어셈블리 코드 세상으로 내려가서 체크해야 될 일이 있다고 한다.

 

    OS는 우리가 처음부터 다시 컴퓨터 요소들을 다루지 않도록 해주는 컴퓨터 하드웨어 및 그 하드웨어에 기반한 기본 구조들에 대한 거대한 중계상이며, 현실에서의 레고 블록 밴더 같은 존재라고 생각한다. 우리는 그러한 블록들을 프로그래밍을 이용해서 조립하며, 새로운 추상화된 레고 블록을 만들기도 한다.

 

    정리하자면 하드웨어가 인프라 라면, OS는 인프라를 끌어 쓰는 기술의 표준이자 인터페이스라고 볼 수 있으며, 프로그래밍 언어는 쉽고, 표준화되고 추상화되고 재생성 가능한 커스터마이즈 제작 도구, 라이브러리나 모듈은 표준 부품 또는 레고블럭의 모터 같은 엔진, 어플리케이션은 그 모든 것을 통해 구현된 빌딩이나 집이라고 볼 수 있다. 그리고 그 기반과 요소들을 포괄적으로 얘기하는 아키텍쳐(물론 이 부분은 하나의 컴퓨터에 벗어나 연결되는 네트워크, 시스템의 여러 다른 영역까지 포함될 것이지만)라는 단어도 있고 말이다.

 

    프로그래밍 같은 기술적 언어는 확실히 우리의 일반적 언어와는 다르긴 하지만, 위의 흐름을 생각해 보면, 문자들의 모임이 단어 및 문법요소가 되고 -> 문장 -> 구조 -> 스토리(책)로 되는 일반적 언어의 구조와 비슷한 느낌이 있다. 그래서 이러한 프로그래밍 기술들을 건축이나 예술과 비교하여 얘기할 수 있는 것 같고 말이다.

 

    또한 이 개개의 컴퓨터들이 내부 네트워크나 인터넷으로 서로 연결되고, 이러한 통신을 이용하여 병렬성을 가지게 됨으로써 인간의 집단 지성과 비슷한 연산 및 자원의 추상화도 이루어졌다고 본다. 이러한 컴퓨터 및 프로그래밍 언어들의 특성들을 이용해서 우리가 해결해야 할 문제를 데이터와 데이터를 풀어내는 퀴즈(알고리즘)로 표현하여 계산하는 것이 IT의 본질이 아닐까 싶다.

 

1.3  IT와 데이터

    개인적으로 생각했을 때 모든 IT의 근간은 데이터라고 생각한다. 개발, 데이터 분석, AI, 테스팅, 보안, 시스템, 네트워크, 직감, 의사 결정 등의 모든 과정이 결국은 특정한 인풋들이 모여서 이루어지게 된다. 단순하게 생각하면 필요한 데이터를 파악하고, 적절한 타이밍과 공간에 옮길 수 있는 방법을 찾고, 그것을 어떻게 처리하냐의 문제라고 볼 수 있다.

 

    프로그래밍도 해당 관점에서 보면 데이터를 다루기 위한 구조적 활동으로 볼 수 있다. 변수나 파일 같은 개념도 데이터를 잘 담기 위한 개념이고, 클래스, 인터페이스, 오브젝트, 디자인 패턴 등도 모두 구조화된 데이터와 그걸 어떻게 잘 처리하고 유지하느냐에 대한 일인 듯싶다.

 

    IT의 여러 분야도 이러한 관점에서 보면 모두 데이터를 만들어내고 다루는 분야들이다. DB, 보안, QA, 시스템, 개발, AI 같은 직접적인 기술이라고 생각되는 분야뿐만 아니라, 비즈니스, 기획, 고객 지원 부서 들 또한 그 기반이 되는 데이터를 생성하고 변화에 영향을 주는 주요한 요소이다. 결국 모두들 접근 방식의 차이만 있지 각각의 뷰로 데이터를 보고, 생성하고, 취합하고 처리한다고 본다. 그 결과로 만들어지는 회사 내의 여러 데이터를 저장해 놓는 SQL, NoSQL 디비라든지, 이상거래 시스템, 고객지원 시스템, 로그, 개발 소스, 비즈니스 정의서 등의 모든 자료(시스템) 안 에는 결국 데이터가 그 본질이 아닐까 싶다(물론 프로그래밍 및 다른 주요 분야에서 일어나는 수많은 추상적인 탑들이 모두 데이터를 위한다고 얘기하기는 조금 조심스럽지만 적어도 데이터를 떼어 놓고는 현실과 유리되어 큰 의미가 없는 것은 사실이다).

[그림 1-6 IT의 여러 분야]

 

    예전의 IT의 캐치프레이즈인 디지털화(Digitalization)라는 단어는 빅데이터, 메타버스 등 해당 이름만 조금씩 세련되고 세분화해 바꿀 뿐 아직도 여전히 계속 영역을 넓히고 있다고 본다. 물리적인 현실을 잘 옮기는 부분을 넘어서, 요즘은 뇌과학, AI 분야 등에서 사람의 감정과 의식 흐름까지 그 데이터 안에 담기를 원하는 것 같다. 현실의 센서와 행위에 연결된 여러 데이터를 기반으로 현실을 추적하고 대응을 하려는 시도가 CCTV, 자동운전, 사람의 시각-소리-촉감 등의 센서, 검색, 전자 상거래 등의 여러 데이터들을 통해 시도되고 있다.

 

    이렇게 데이터는 현실과 연결되기 때문에 반대로 해당 데이터를 만든 비즈니스와 현실을 제대로 이해 못 하면 데이터를 충분히 이해 못 하게 되는 일이 생기기도 하며, 이 점이 맨 처음 특정 분야에 발을 들인 사람들이 적응하기 힘든 이유 중에 하나인 것 같다.

 

1.4  마무리하면서

    얼마나 공감이 됐었을진 모르겠지만, 개인적인 관점에서 IT라는 세상은 각자의 뷰에 따라 이런 데이터들을 찾아다니는 직업 군들의 집합이 아닐까 싶다. 반딧불을 찾아다니기는 하지만 우리 자신도 저 반딧불 중 하나일지도 모르고 말이다(매트릭스 같은 얘기이긴 하지만).

 

    반딧불을 따라가는 아이처럼 각자 발견한 반딧불이 세상의 전부라고는 생각하진 않는 것이 좋다. 다른 사람들이 반딧불을 쫓아가는 방법이나 발견한 다른 반딧불에서도 많은 것들을 배울 수 있기도 하고, 보통 의식은 못하지만 같이 손잡고 뛰어가는 경우도 많은 듯하기 때문이다.

[그림 1-7 데이터 따라가기]