[Day 6-8] 4/24~26 (토픽4) 소프트웨어 이해하기 ①

4/24 (토)는 아웃라인만 잡고 잠
4/25 (일) 휴식 - 부동산 경매 & 친구 만남
4/26 (월) 오후 10시 반부터 수강 시작

[토픽 소개]
세상의 수많은 프로그래머들은 어떤 프로그램을 만들고 있을까요?
크롬, 엑셀, 카카오톡, 게임. 이런 것들이 먼저 떠오르겠지만, 사실 이건 빙산의 일각에 불과합니다. 우리가 직접적으로 사용하는 프로그램 이면에 보이지 않는 프로그램도 많이 있죠.

프로그래밍의 세계를 제대로 이해하기 위해서는 보이지 않는 프로그램들에 대해서도 잘 이해해야 합니다. 그래야 프로그래머들이 어떤 일을 하고 있는지, 프로그래밍 시장이 어떻게 움직이고, 우리는 어떤 공부를 해야 하는지 제대로 파악할 수 있겠죠?

이번 토픽에서는 이 세상에 어떤 프로그램들이 존재하는지 살펴보고, 소프트웨어의 큰 그림을 이해해 봅시다.

컴파일러와 인터프리터

다양한 어플리케이션

얼마나 다양한 프로그램이 있는지 살펴봄
가장 자주 사용하고 눈에 잘 보이는 애플리케이션

애플리케이션/앱/어플/App = 사용자가 직접 사용하는 프로그램
cf. 실제 사용자 / 유저를 엔드유저라고 부름 (제일 마지막 단계)

애플리케이션은 스마트폰에 국한 된 건 아님. 사실상 컴퓨터 노트북에 있는 것도 포함 (포토샵, 크롬, 엑셀)

다들 애플리케이션이라고 하면 '휴대폰에서 실행하는 애플리케이션'을 생각하기 쉽지만,생각보다 애플리케이션의 범위가 넓음
사람들이 실제로 직접 사용하는 기계(에어컨, 키오스크 등)등 있는 애플리케이션까지 '사용자가 직접 사용하는 모든 프로그램'을 지칭

애플리케이션을 만드는 프로그램

세상에 있는 다양한 애플리케이션을 살펴봤습니다.

이 애플리케이션들은 어떤 과정을 통해 만들어지는 걸까요?
프로그래밍 언어로 코딩을 해서 만들게 됩니다.

하지만 코딩을 하면 영어와 숫자가 섞인, 코드가 만들어질 텐데, 어떻게 이런 프로그래밍 코드가 실행할 수 있는 애플리케이션으로 바뀌는 걸까요?

어떤 소프트웨어가 이 프로그래밍 코드를 실행할 수 있는 애플리케이션으로 바꿔주기 때문에 이게 가능한 겁니다.

이렇게 애플리케이션을 만들어 주는 소프트웨어는 크게 두 종류로 나눌 수 있습니다. 들어보셨을 수도 있는데요, 바로 컴파일러와 인터프리터 입니다.
정리하자면, 컴파일러와 인터프리터가 프로그래밍 코드를 실제 동작하는 프로그램으로 바꿔 주는 겁니다.

컴파일러를 활용하는 방식과 인터프리터를 활용하는 방식에는 차이가 있는데요. 다음 레슨에서 하나씩 살펴봅시다.

프로그래밍 언어의 번역기, 컴파일러

프로그래밍 언어는 매우 다양했었죠?
하지만 컴퓨터가 이해하는 언어는 기계어 뿐.
한 언어의 코드를 다른 언어의 코드로 번역하는걸 컴파일러라고 함

컴파일러 = 프로그래밍 언어의 "번역기"
고수준 프로그래밍 언어 => 컴파일러 => 머신코드 (개발자 컴퓨터)
=> 컴퓨터가 이해하고 실행할 수 있게 됨
=> 머신코드만 (사용자 컴퓨터)에 보냄, 머신코드만 실행해서 프로그램 실행하게 됨
(이미 번역된 머신코드를 전달, 사용자 컴퓨터는 실행하면 되고)

컴파일러의 단점 = 빠르게 개발 할 수 없다!
코드 작성 => 컴파일 => 코드 실행 해야하는데,
코드가 잘 돌아가는지 확인하고 싶은데
컴파일은 시간이 소요됨
한줄의 코드를 확인해보려고 해도, 매번 몇 분씩 기다려야 함
좋지만, 빠르게 개발 할 수 없음!

실시간 코드 실행기, 인터프리터

컴파일러를 사용하면, 개발할때 매번 컴파일을 다시 해야 하는 어려움이 있음. 그래서 사람들이 컴파일이라는 과정 없이 고급언어를 바로 실행할 수 있는 방법이 없을까 생각하다 만든 방식

컴파일러 한번에 번역

인터프리터는 한줄씩 즉흥 번역.
실행기임. 개발 속도가 빨라짐

컴파일러
이미 번역된 머신 코드를 주는
전달받은 걸 실행만
vs
인터프리터
프로그래밍 코드 자체를 전달
번역 과정을 실시간 거침
사용자 컴퓨터에서 인터프리터를 가지고 있어야함
실행속도 떨어짐
프로그램 용량 더 작음
코드가 유출 될 수도 있음

컴파일러 vs 인터프리터

프로그래밍 언어의 종류에 따른 실행 방식 차이
컴파일러 방식과 인터프리터 방식의 장단점을 한번 살펴 봅시다.

컴파일러는 “개발 편의성은 떨어지지만, 실행 속도는 빠르다.”
인터프리터는 “개발 편의성이 높지만, 실행 속도는 느리다.”

그런데 어디서 들어본 이야기인 것 같지 않나요?
사실 코드의 실행 방식은, 프로그래밍 언어의 특징과도 연결이 되는데요.

기억을 되살려 봅시다.
저수준 언어는 개발 편의성은 떨어지지만 실행 속도는 빨랐고요.
고수준 언어는 개발 편의성이 높지만, 실행 속도는 느렸습니다.

하나의 장점을 살리기 위해, 다른 것들을 일부러 포기한 거죠.

그런데 동일한 특징이 컴파일러와 인터프리터에서도 각각 나타나고 있는 거죠. 그래서 언어 마다 주로 쓰이는 실행 방식이 있습니다.

고수준 언어는 개발 편의성이 생명인 언어인데, 컴파일 과정을 매번 거쳐야 한다면, 그 장점을 다 잃어버리고 말겠죠?
그래서 파이썬, 루비같은 고수준 언어는 인터프리터 방식을 주로 사용합니다.

반면, 저수준 언어는 개발 과정이 좀 힘들더라도, 어떻게든 최고의 성능, 효율, 속도를 만들어내고자 했습니다. 그런데 그게 인터프리터 방식으로 실행되어서, 느린 환경에서 실행된다면, 힘들여서 저수준 언어로 개발한 이유가 다 사라지겠죠?
그래서 C, C++ 같은 저수준에 비교적 가까운 언어들은 컴파일 방식으로 실행되는 경우가 많습니다.

꿀팁 노트 : 첫 번째 컴파일러는 어떻게 만들었을까요?

재미있는 질문을 하나 던져봅시다.
첫 번째 컴파일러를 만들 때는 컴파일러가 없었을 텐데, 어떻게 이 컴파일러 프로그램을 번역해서 실행할 수 있었을까요?
정답은 "번역을 하지 않고 컴퓨터의 언어로 사람이 직접 작성했다.” 입니다.
머신코드에 가장 가까운, 어셈블리 언어라는 걸 살펴본 적이 있었죠?

파이썬

print("Hello")

어셈블리 언어

        extern printf
        section .data
msg:    db "Hello", 0
fmt:    db "%s", 10, 0
        section .text
        global main
main:
        push    rbp
        mov     rdi,fmt
        mov     rsi,msg
        mov     rax,0
        call    printf
        pop rbp
        mov rax,0
        ret

머신 코드

0010011010011001
1101010011100101
1100010101001010
0100101101010010
1101011000101100

이 어셈블리 언어를 사람이 직접 사용해서 첫 번째 컴파일러가 만들어졌습니다. 거의 머신 코드를 사람이 하나 하나 만든 셈이죠.

컴파일러가 만들어지기 전에는 사람이 컴퓨터의 언어를 직접 배워서, 컴퓨터가 실행할 수 있게 직접 코딩하는 것이 일반적이었습니다. 생각만 해도 매우 힘든 과정이었겠죠?

하지만 첫 번째 컴파일러가 만들어진 이후에는, 그 컴파일러를 이용해서 여러 가지 프로그램을 번역할 수 있었습니다. 그 다음 컴파일러도, 첫 번째 컴파일러로 번역했겠죠. 이제는 컴퓨터가 사람의 언어를 배우고 있는 것입니다!

최근에는 한 언어에도 여러 컴파일러 종류가 생기기도 했고, 한 언어에 대한 컴파일러를 자기 자신의 언어로 만들기도 한답니다.
실제로 Haskell 이라는 언어의 컴파일러는 최초에 Lazy ML이라는 언어로 작성되었다가, 자기 자신의 언어인 Haskell로 재작성 되었다고 합니다.