본문 바로가기
SW LAB/Algorithm

Clean Architecture : (3장) 패러다임 개요

by 프롬스 2020. 5. 24.
반응형

 프롬스의 SWDEVLAB 

패러다임 개요

 소프트웨어 아키텍처는 코드로부터 시작합니다. 따라서 아키텍처에 대한 논의도 최초로 작성된 시점부터 우리가 코드를 통해 배운 내용을 살펴보는 데서 출발하고자합니다

 1938년 엘런 튜링(Alan Turing)은 컴퓨터 프로그래밍이라고 부르는 분야의 토대를 쌓았습니다. 튜링은 프로그래밍이 가능한 머신을 최초로 상상한 사람은 아니었지만, 프로그램을 단순한 데이터라고 이해한 최초의 사람이었습니다.

 1945년경 튜링은 사람이 식별할 수 있는 형태의 실질적인 프로그램을 실제 컴퓨터에서 코드로 작성했습니다. 이들 프로그램은 반복문, 부기문, 할당분, 서브루틴, 스택 등 우리에게 익숙한 구조를 사용했습니다. 그리고 바이너리 언어를 사용했습니다. 이 때 이후로 프로그래밍에는 수많은 혁신적인 변화가 이뤄졌습니다.

 1940년대 후반 어셈블리가 처음으로 등장하였고, 이 언어의 등장으로 프로그래머의 단조롭고 고된 일이 줄어들었습니다.

 1951년 그레이스 호퍼(Grace Hoper)는 최초의 컴파일러 A0를 발명했습니다. 사실 컴파일러라는 용어도 그레이스가 처음으로 만들었습니다.

 1953년에는 포트란이는 언어가 발명되고 이 후로 코볼, PL/1, SNOBOL, 파스칼, C++, JAVA 등 홍수처럼 언어가 쏟아졌습니다.

 또 다른, 어쩌면 더 중요한 혁신적인 변화가 프로그래밍 패러다임에도 몰아쳤습니다. 패러다임이란 프로그래밍을 하는 방법으로, 대체로 언어에 독립적입니다. 패러다임은 어떤 프로그래밍 구조를 사용할지, 언제 이 구조를 사용해야 하는지를 결정합니다. 현재까지 이러한 패러다임에는 세 가지 종류가 있습니다. 나중에 설명할 이유 때문에.. 이들 세 가지 외의 패러다임은 존재하지 않을 것입니다.

 

구조적 프로그래밍

 최초로 적용된 패러다임은 구조적 프로그래밍으로, 1968년 에츠허르 비버 데이크스트라가 발견했습니다. 데이크스트라는 무분별한 점프(goto 문장)는 프로그램 구조에 해롭다는 사실을 제시했습니다. 데이크스트라는 이러한 점프드를 if/then/else와 do/while/until과 같이 더 익숙한 구조로 대체했습니다. 구조적 프로그래밍 패러다임을 요약하자면 ...

 

구조적 프로그래밍은 제어흐름의 직접적인 전환에 대한 규칙을 부과한다.

 

객체 지향 프로그래밍

 두 번째로 도입된 패러다임은 구조적 프로그래밍보다 사실 2년 앞서 1966년, 올레 요한 달(Ole Johan Dahl)과 크리스텐 니가드(Kristen Nygard)에 의해 등장했습니다. 이들은 알골(Algol) 언어의 함수 호출 스택 프레임을 힙으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견합니다. 바로 이러한 함수가 클래스의 생성자가 되었고, 지역 변수는 인스턴스 변수, 그리고 중첩 함수는 메서드가 되었습니다. 함수 포인터를 특정 규칙에 따라 사용하는 과정을 통해 필연적으로 다형성이 등장하게 되었습니다. 객체 지향 프로그래밍 패러다임을 요약하자면 ...

 

객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다.

 

함수형 프로그래밍

 세 번째 패러다임은 최근에 들어서야 겨우 도입되기 시작했지만, 세 패러다임 중 가장 먼저 만들어졌습니다. 사실 함수형 프로그래밍은 컴퓨터 프로그래밍 자체보다 먼저 등장했습니다. 알론조 처치(Alonzo Church)는 앨런 튜링도 똑같이 흥미를 느꼈던 어떤 수학적 문제를 해결하는 과정에서 람다 계산법을 발명했는데, 함수형 프로그래밍은 이러한 연구 결과에 직접적인 영향을 받아 만들어졌습니다. 1958년 존 메카시(Jone McCarthy)가 만든 LISP 언어의 근간이 되는 개념이 바로 이 람다 계산법입니다. 람다 계산법의 기초가 되는 개념은 불변성으로, 심볼의 값이 변경되지 않는다는 개념입니다. 이는 함수형 언어에는 할당문이 전혀 없다는 뜻이기도 합니다. 사실 함수형 언어가 변수 값을 변경할 수 있는 방법을 제공하기는 하지만, 굉장히 까다로운 조건 아래에서만 가능합니다. 함수형 패러다임을 요약하지면 ...

 

함수형 프로그래밍은 할당문에 대한 규칙을 부과합니다.

 

생각할 거리

 앞으로 포스팅에서 이들 세 가지 프로그래밍 패러다임을 소개하면서 신중하게 설정한 패턴이 보일 것입니다. 각 패러다임은 프로그래머에게서 권한을 박탈합니다. 어느 패러다임도 새로운 권한을 부여하지 않습니다. 각 패러다임은 부정적인 의도를 가지는 일종의 추가적인 규칙을 부과합니다. 즉, 패러다임은 무엇을 해야 할지를 말하기보다는 무엇을 해서는 안 되는지를 말해줍니다.

 이러한 논의를 바라보는 또 다른 방법은 각 패러다임이 우리에게서 무언가를 빼앗는다는 사실을 인지하는 것입니다. 세 가지 패러다임 각각은 우리에게서 goto문, 함수 포인터, 할당문을 앗아갑니다. 우리에게서 가져갈 수 있느게 더 남아 있는가?

 이 관점에서 볼 때.. 아마 없을 것입니다. 따라서 프로그래밍 패러다임은 앞으로도 딱 세 가지밖에 없을 것입니다. 최소한 부정적인 의도를 가진 패러다임으로는 이 세 가지가 전부일 것입니다. 또 다른 근거로는 .. 1958년부터 1968년까지 10년동안 이 패러다임들이 모두 만들여졌지만 수십년간 현재까지 새롭게 등장한 패러다임은 전혀 없다는 것입니다.

 

결론

 패러다임의 역사로부터 얻을 수 있는 교훈은 아키텍처와 밀접한 관계가 있다는 것입니다. 우리는 아키텍처 경계를 넘나들기 위한 매커니즘으로 당형성을 이용합니다. 우리는 함수형 프로그래밍을 이용하여 데이터의 위치와 접근 방법에 대해 규칙을 부과합니다. 우리는 모듈 기반 알고리즘으로 구조적 프로그래밍을 사용합니다.

 세 가지 패러다임와 아키텍처의 세 가지 큰 관심사 (함수, 컴포넌트 분리, 데이터 관리) 가 어떻게 서로 연관되는지에 주목해야 합니다.

 이번 장은 거의 책의 내용을 읽으며 그대로 작성했습니다. 개요를 함축적이고 명확하게 정말 잘 작성한 것 같습니다 !

 

관련글

내용이 도움이 되셨으면 공감 버튼 꼬옥 눌러주세요
본문을 퍼가실 경우 댓글을 달아주세요

반응형

댓글