항상 충실하게

 비전공자로서 자료구조를 공부하다가 궁금했던 것이 있다. 내가 파이썬부터 배우기 시작해서 그런지는 몰라도.

스택/큐 다되는 deque가 있는데, 왜 굳이 스택/큐를 나누어서 쓰는 것일까? 그냥 그 모든 기능을 다 되게하면 안되는 걸까?

이 질문에 대한 답을 오늘 드디어 깨달아서, 이렇게 글을 쓴다.

일단 자료구조의 정의부터 알아보자.

In computer science, a data structure is a particular way of storing and organizing data in a computer so that it can be used efficiently

즉, 효율적으로 사용되기 위해, 데이터를 저장하고 표현하기 위한 특정한 방식이 자료구조라고 할 수 있다.

그러니까 스택이나 큐가 먼저 있었고, 그에 따른 기능들이 나온 것이 아니라.

FIFO, LIFO등의 데이터를 저장하고 표현하기  위한 방식이 있었고, 이에 대한 이름을 스택, 큐라고 붙인 것이다.

여기서부터는 내 상상이자, 뇌피셜이 살짝 섞여있다. (실제로는 아닐 수 있음 주의)

컴퓨터과학자들이 먼저 자료구조를 만들고, 프로그래머들이 이를 사용했을까?

아니면 프로그래머가 먼저 코드를 짜다보니 특정한 데이터의 저장/표현방식이 반복되었고, 이를 컴퓨터과학자들이 스택/큐라고 이름을 붙였을까?

나는 후자라고 생각한다. 사실 프로그래밍 세계의 발전이 그러한 것 같다. 계속 해결해야한느 문제점들이 발생하고, 이를 해결하려고 노력하고, 그 해결점들이 컴퓨터과학으로 학문화되는 것 같다. (그래서 나는 운영체제 과목을 물리적 한계에서 최적화된 컴퓨터를 개발하기 위한 컴퓨터과학자들의 분투들이 담겨있다고 느꼈다.)

그리고 C언어로 된 책을 보면 ADT를 설정하고 이를 자료구조로 구현한다.

이는 ADT는 설계도 같은 것으로, FIFO를 구현하는데 LIFO까지 가능하게 하면 이는 사족이 달려있는 것과 같다.

또한 다른 프로그래머들이 어떠한 맥락을 파악하는데 어려움을 겪을 것이다.

예를 들어, a라는 프로그래머가 FIFO기능이 필요한데 그냥 deque로 짜놓았다면, b란느 프로그래머는 deque가 fifo기능을 위해 들어갔다는 사실을 전후 코드를 살펴야하는 노력이 필요하다. 이러한 비효율을 줄이기 위해서라도, queue/ stack은 나누어서 쓰여져야 한다.

여튼 내가 가졌던 의문은 전제가 잘못되었다.

일단 나누어서 개발한게 아니라, 개발된것에 이름을 붙인것 뿐이다.

그리고 나뉘어져있어야 타 개발자와의 협업, 소통 등에서 유리하다.

발단

왜 프로세스와 스레드를 배우는지는 알겠다. 한정된 리소스를 효율적으로 관리하고, 최상의 아웃풋을 내기 위해서이다.

그런데 ENIAC 시절부터 프로세스와 쓰레드가 있었을까?

그건 아닐 것이다. 그러면 어떠한 이슈때문에 프로세스 쓰레드가 탄생하게 됐을까?

전개

사실 처음 공부한 자료에서는 이에 대해 잘 안나와있었는데, 공룡책을 참고하다보니 이에 대해 나와있었다.

결

프로세스 탄생 배경

 초기의 컴퓨터 시스템은 한번에 하나의 프로그램만을 실행하도록 허용했다. 따라서 프로그램이 시스템을 완전히 제어하고, 모든 자원에 접근해도 됐다. 그런데 메모리에 다수의 프로그램이 적재되어 병행실행되는 것이 허용되면서 다양한 프로그램을 보다 견고하게 제어하고 구획화할 필요가 생기면서 프로세스라는 개념이 탄생하게 되었다.
-운영체제 Abraham Silberschatz (공룡책) 10판, 117pg

쓰레드 탄생 배경

하나의 응용프로그램이 여러개의 비슷한 작업을 수행할 필요가 있는 상황들이 존재한다. 이때 각각의 프로세스를 생성하고 컨텍스트 스위칭을 한다면, 많은 오버헤드를 감수해야한다.

따라서 스택만 따로 할당받고, 코드,데이터, 힙영역은 공유하는 쓰레드가 탄생하게 되었다.

발단

이전에 프로젝트를 했을때, 왜 seriallizer를 사용하는지 몰랐다.

굳이 사용해야 싶나 했는데, marshmallow같은 라이브러리까지 있는거보면 필요성이 분명히 있으리라 생각하고 찾아보게 되었다.

전개

은근히 바로 안나왔는데, 그래도 결국 quora에서 찾았다.

https://www.quora.com/Do-I-really-need-serializers-in-Django-Rest-Framework-app

결

 custom code의 양을 줄여준다.

serializer 없이 한두개 정도는 일일히 작성할 수 있지만, 현업에서 대량의 api를 만들어야 하는 경우, 이는 많은 노력이 들어가고 수정보완하기 까다롭게 된다.

발단

네트워크를 공부하다보니, 이 과목은 약간 통신규약을 배운다는 느낌을 접근해야겠다는 생각이 들었다.

그러면, 어떡하다가 그러한 protocol이 탄생하게 됐는지 궁금해졌다.

전개

TCP 개발동기는 나무위키에 잘나와있었다.

그런데 혹시 몰라서 팩트체크를 위해서 영어자료도 찾아봣는데, 아주 틀린정보는 아닌것 같다.

https://namu.wiki/w/TCP

https://en.wikipedia.org/wiki/Bob_Kahn

이 할아버지는 TCP를 만든 사람중에 하나인데, TCP를 만들 당시 DARPA(미 국방부 고등연구원)에서 일한 경력이 있다.

결

미국 국방부가 관심을 갖던 것은 핵전쟁이 발발하더라도 정상적으로 작동하는 네트워크이다.

TCP이전 일반적으로 사용하던 통신방식은 회선교환(circuit switching)인데, 이는 특정 경로만을 설정해서 전달하는 방식인거다.

따라서 특정 경로가 폭격에 바갈나면 통신이 끊어진다.

이에따라 패킷교환방식을 사용하게 되었는데, 이는 데이터를 패킷단위로 나누어, 여러 경로들을 거쳐서 전달되게 된다.

다만 이는 네트워크환경의 안정성이 떨어진다는 단점이 있다. 왜냐하면 모든 패킷이 안전하게 도착한다는 보장이 없기 때문이다.

이에 따라 신뢰성을 보장하기 위한 TCP 방식이 탄생하게 되었다.

발단

docker에 대해 공부하다가, Yaml 파일 형식에 대해 처음 접하게 되었다.

그런데 문득 왜 yaml파일이라는 것이 생긴거지?라는 생각이 들었다.

전개

인터넷에 검색해봤는데, yaml파일을 만들게 된 이유에 대해서는 설명이 없었다.

그래서 yaml 공식문서에 있는 사람에게 메일을 보내 물어보기로 했다.

https://yaml.org/spec/1.0/#id2488873

결론

오렌은 친절하게 답변을 해줬는데, 답변내용은 아래와 같다.

2004년 당시 어떠한 프로그래밍 언어에서도 사용 가능한 data structure를 de/seriallizing 가능한 포맷을 찾고 있었다.

그런데 그때 당시 XML은 이것이 불가능햇고, 우리가 새로 만들게 되었다.

+ 궁금했던 것.

1. Yaml의 장단점은 무엇인가?

장점: 주석 사용가능, 한글을 그대로 사용해도됨

단점: 개행, 공백으로 블록 인식. 이에 따라 한줄로 작성 불가함.

(사실 이는 단점이라기보다는 특징에 가까운 것 같다.)

https://yaml.org/spec/1.2-old/spec.html#id2759572

공식문서에 따르면, JSON의 최우선 디자인 목표는 간단함과 보편성이고 이에 따라 가독성을 조금 포기하는 대신에 생성과 파싱이 용이하게끔 한것이다.

반면에 YAML의 최우선 설계 목표는 가독성과 데이터구조 serialization이다. 따라서 가독성이 매우좋지만, 생성하고파싱하는데 약간 더 시간이 걸린다.

2. Yaml을 restful api에서 데이터 전송형식으로 쓸 순 없을까?

일단 앞서 언급했듯이, json이 좀더 생성과 파싱에 용이하다.

그리고 yaml은 공백으로 구분하는데, 이것은 json파일보다 크게 만들고, json보다 복자하다.

그리고 브라우저들은 json을 natively 제공한다 

하지만 위와 같은 복잡한 구조 떄문에 configuration file로는 yaml이 적합하다.

https://www.quora.com/Why-isnt-YAML-used-instead-of-JSON-for-the-web-as-its-easier-to-read-for-both-humans-and-machines

https://www.quora.com/Will-YAML-replace-JSON

https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json

발단

필자는 경제학도이다. 경제학은 대부분 이미 존재하던 경제현상들을 해석하는 과정에서 발달한 학문이다.

예를 들어 가격이 오른다. --> 수요가 많아져서 그런것이다. 이런 식이다.

그러다보니 이 이론이 왜 나왔는지 딱히 따질 필요가 없다. 

그런데 경제학도로서 컴퓨터 공학을 접하다보니, 도대체 이게 왜 생긴거지? 라는 의문이 드는게 너무 많았다.

전개

사실 이는 너무 당연하다. 

왜냐하면 컴퓨터 과학의 대부분은 이미 있었던 현상에 대한 답이 아니라, 개발자들과 컴퓨터과학자들이 맞닥뜨린 문제에 대한 해결책들을 모아놓은 것이기 때문이다.

예를 들어, 에니악 시절부터 프로세스 쓰레드가 존재하지는 않았을 것이다.

컴퓨터가 발전하다보니, 프로세스가 필요하고, 쓰레드가 필요하니 탄생한 것이다.

사실 그래서 운영체제를 공부하다보면, 약간 한정된 자원안에서 최선을 이끌어내기 위한 컴퓨터과학자들의 분투가 담겨있는 과목같아서 약간 감동적이기 까지 했다.

결

나의 궁금증을 해결하기도 하고, 추후 내가 맞닥뜨릴 문제들의 힌트를 얻기 위해서.

이 시리즈를 작성하고자 한다.