프로그래밍언어 발전 과정

sith-call.dev·2021년 10월 28일
0

Computer Science

목록 보기
7/15

1. 튜링머신

컴퓨터의 원천 아이디어는 튜링의 한 논문에서 제시되었다.
튜링은 인간의 사고과정을 따라하는 어떤 기계를 제시하였다.
그리고 그 기계는 훗날 컴퓨터의 청사진이 되었다.
튜링머신의 자세한 내용은 생략한다.

2. 폰노이만 구조

튜링이 컴퓨터의 청사진을 제시했다면, 이를 구체적으로 컴퓨터 하드웨어 아키텍쳐로 표현해낸 것은 폰 노이만이었다.

폰노이만 구조의 핵심은 저장된 프로그램을 메모리에 불러와 그 프로그램의 명령어들을 순차적으로 실행한다는 것이다.

여기서 중요한 점은 "순차적"이다.

즉, CPU는 어떤 메모리 위치에서부터 순차적으로 한 줄씩 명령어를 읽어내려간다. 아래는 기계어의 예시다.

0001 1010 1110 0101
0111 1100 0000 1111
1010 1001 1111 0010
....

여기서 첫 번째 문제가 발생한다. 기계어는 사람에게 친숙하지 못하다. 그래서 사람이 사용하기 어렵다.

3. 어셈블리어

기계어의 첫 번째 문제점을 해결하기 위해 어셈블리어가 탄생되었다.
어셈블리어는 기계어와 일대일 대응이 된다. 그래서 사람이 보다 더 직관적으로 기계어를 이해할 수 있다.
(기계어)
0001 1010 1110 0101
0111 1100 0000 1111
1010 1001 1111 0010
....

(어셈블리어)

LOAD 1230
ADD 233
STA 3344
....

4. 절차적 프로그래밍 패러다임

사실 어셈블리어도 low-level의 언어이다. 즉, 인간보단 아직 기계에 더 가까운 언어라는 것이다. 그래서 어셈블리어보다 더 인간친화적인 high-level의 언어들이 만들어진다.

위에서도 말했듯이 폰 노이만 구조의 컴퓨터는 명령어를 순차적으로만 처리한다. 그러나 오직 순차적이기만 하다면 다양한 알고리즘을 구현하기 어렵다. 그래서 CPU 명령어에는 JUMP라는 것이 있는데, 이 명령어를 만나면 특정 위치로 이동하여 그곳에서부터 다시 순차적으로 명령어를 처리하게 된다. 그리고 JUMP는 high-level의 언어에서 GOTO라는 문법으로 구현되었다.

그러나 여기서 두 번째 문제가 발생된다. GOTO문법으로 인해 코드가 읽기 상당히 어려워진 것이다. 다양한 알고리즘을 구현하려면, GOTO를 사용할 수 밖에 없는데 이로 인해 코드가 복잡해진 것이다.

즉 인간 친화적인 언어로 코드를 작성할 수 있게 되었지만, 작성된 코드가 너무나 복잡해지는 문제를 만나게 된 것이다. 그리고 이렇게 GOTO문으로 인해 복잡해진 코드를 스파게티 코드라고 한다.

5. 구조적 프로그래밍 패러다임

GOTO문에 의해 발생된 문제를 해결하기 위해서 구조적 프로그래밍 패러다임이 고안된다. 이는 구조적으로 Control Flow를 처리하겠다는 패러다임이다. 이때 Control Flow는 컴퓨터가 코드를 읽어나가는 흐름이라고 생각 하면 된다.

그리하여 반복문, 조건문 등을 통해서 Control Flow를 구조적으로 처리할 수 있게 되었고 다양한 알고리즘 구현을 위해 GOTO문을 사용할 이유가 없어지게 되었다.

6. 소프트웨어 위기(Software Crisis)

위와 같은 해결법에도 불구하고 소프트웨어 세계는 갈수록 위태로워졌다.
초창기 하드웨어 기술이 중요시 되던 시기에는 보이지 않던, 소프트웨어만의 문제가 나타나기 시작했기 때문이다. 개발비용이 초과되고, 개발기간을 맞추지 못하는 일이 자주 발생된 것이다.

이런 현상을 위기로 보고 컴퓨터과학자들은 다양한 해법을 제시하기 시작한다. 그리고 객체지향 프로그래밍 패러다임은 그 해법 중에 하나였다.

7. 객체지향 프로그래밍 패러다임

객체지향 프로그래밍 패러다임은 이전 패러다임과는 완전히 다른 것이다. (물론 객체지향 프로그래밍을 구현한 언어에는 대부분 절차적, 구조적 프로그래밍 패러다임의 특성도 같이 포함되긴 한다.)

이것은 인간이 세상을 인지하는 관점을 소프트웨어에 적용한 것이다. 인간은 어떤 사물이 가질 수 있는 상태와 그것이 할 수 있는 행동을 중심으로 그것을 사고한다. 덧붙여 이런 사물들의 관계 또한 관심 대상이다.

그래서 소프트웨어에서 프로그램을 설계할 때, 프로그램에도 상태와 행동을 부여하고 다른 프로그램 간의 관계 또한 정의하여 하나의 큰 프로그램을 설계한다.

자세한 내용은 나중에 객체지향 프로그래밍 패러다임만을 독립적으로 다루는 글에서 서술하겠다.

틀린 부분이 있다면 언제든 지적 부탁드립니다.

profile
Try again, Fail again, Fail better

0개의 댓글