[weekly] [nb] 웹 개발 시작하기(3)

절차지향 프로그래밍과 객체지향 프로그래밍의 차이점에 대해 설명해 주세요.

프로그램(program)

미리(pro) + 그리다(gram) 의 합성어로 '미리 작성해둔 것' 의 의미를 가진다.

즉, 특정한 업무 혹은 특정한 진행을 위해서 어떤 순서로 어떤 것을 해야 하는지 정리 해둔 것인데, 우리가 흔히 쓰는 시간표도 사실 이 범주 안에 들어간다. 프로그램이 더 큰 범주인 것.

단어 자체가 직관적인 만큼, 고대 그리스 시절부터 사용된 의외로 역사가 굉장히 긴 단어다.

그 당시에는 도시 마다 아고라(광장)에 공지사항을 적고, 그 공지사항을 지칭할 때 프로그램이라고 했다고 한다.

프로그래밍(programming)

아무튼, 다시 주제로 돌아가서 프로그래밍(programing) 은 이 프로그램(program) 을 작성하는 행위를 말한다.

그 프로그램을 작성할 때 사용하는 언어를 상황에 따라 다양한 언어로 쓸 수 있는데, 그게 바로 프로그래밍 언어(programming language) 다.

대부분의 경우, 프로그래밍 언어는 단 하나의 기계어 라고 하는 언어로 번역되어서 사용된다.

모든 길(코드)는 로마(기계어) 로 향한다!

절차지향(procedure oriented)

절차지향은 전지적작가 시점 이라고 볼 수 있다.

// index.mjs
const name = 'gyunam'
function hello(name='') {
  console.log(`hello,${name}.`)
}

hello(name)

절차(procedure) 이라는 단어에서도 알 수 있듯이, 정해진 순서에 따라서 코드를 읽어가는 방식이다.

이 패러다임을 사용한 최초의 프로그래밍 언어는 공식적으로는 포트란(fortran) 이다.

포트란(fortran)

1957년에 만들어진 프로그래밍 언어 계의 대부 중의 대부다.

이 포트란을 사용한 대표적인 프로젝트가 바로 아폴로 미션(apollo program) 이다.

그래서 nasa 에서는 여전히 포트란을 사용한 프로그램들이 유지보수 되고 있다..!

상향식(bottom-up)

이 절차지향 패러다임은 아래(부품) 을 먼저 만들고, 위(main) 에서 그 부품을 조립해서 프로그램을 만든다.

아래에서 부터 위로 천천히 쌓아 올라가기 때문에 bottom-up 이라는 표현을 쓴다.

그렇기 때문에 모듈(module) 이란 용어는 객체지향에서만 쓰는 용어는 아니다. 절차지향에서도 모듈(module) 은 당연히 쓰인다!

절차지향 패러다임에서 모듈(module) 은 기능(function) 단위로 쪼개지고, 필요에 따라서 전역 변수(global variables) 가 묶인 형태다.

간단해서 생긴 장점

상대적으로 빠르다

상대적 이라는 단어가 중요하다.

정해진 순서, 무조건 위에서 아래로 진행되기 때문에 절차지향 패러다임에 비해서 상대적으로 빠르게 실행된다.

다만, 상대적인 이유는 프로그래머의 역량에 따라서 이 성능 차이는 굉장히 의미 없어지기 때문이다.

굉장히 높은 확률로 내가 작성한 C언어 프로그램은 존 카멕이 작성한 파이썬 프로그램보다 훨씬 느릴 것이다.

문법과 구조가 단순하다

기본적으로 기능(function) 단위로 모듈(module) 을 만들기 때문에, 문법이 단순한 경우가 많다.

사람따라 다르긴 하지만, 기본 제공 되는 기능의 가짓수가 적기 때문에 상대적으로 배우기가 쉽다.

대게의 경우 절차지향 프로그래밍 언어를 배우기 어렵다고 칭하는 경우가 c언어 일 때가 많은데, 그냥 c언어로 눈에 바로 보이는 결과를 만들기가 애매해서 그렇다.

문법이나 구조 자체는 정말 단순하다!

간단해서 생긴 단점

기능(function) 단위로 나뉘고 단순하기 때문에 생긴 단점도 있다.

의존성, 결합도 상승

여러 기능이 사용되는 하나의 복합적인 기능을 만들다 보면, 서로가 서로를 참고하고 사용하는 결합도가 높아진다.

이 결합도가 높아지면, 하나의 기능을 수정했을 때 다른 기능들도 같이 수정해야하는 경우가 발생할 가능성이 높아진다.

그래서 이 결합도가 높아지는 것을 유지보수 비용 이 높아진다고 표현한다.

보안 취약

절차지향 패러다임에서는 모듈(module) 내에서 사용하는 공통적인 변수를 전역 변수로 관리하는 경우가 많다.

그래서 이 전역 변수가 공유되거나 해서 임의로 수정될 수도 있다.

물론, 절차지향 패러다임에서는 그에 맞는 보안 강화를 따라서 프로그램을 작성하게 되지만, 기본적으로 은닉성이 낮다는 것은 사실이다.

객체지향(object oriented)

객체지향은 1인칭 관찰자 시점 이라고 볼 수 있다.

// greeting.mjs
export default class Greeting {
  static #name = 'gyunam'

  static hello(){
    console.log(`hello,${this.#name}.`)
  }

  static helloTo(name){
    console.log(`hello,${name}`)
  }
}

// index.mjs
import greeting from './greeting.mjs'

const greeting = new Greeting()
greeting.hello()
greeting.helloTo('cat')

시뮬라(simula)

최초의 객체지향 프로그래밍 언어는 시뮬라(simula) 다.

1967년에 만들어진 이 언어는 노르웨이에서 만들어졌다. 북유럽의 IT 강세는 이때부터였나보다.

시뮬라에서 최초로 사용한 개념은 클래스, 객체, 상속, 동적 바인딩 등이 있으며, 현대의 객체지향 패러다임은 모두 시뮬라의 개념을 기초로 설계되었다.

개선된 장점

절차지향 패러다임에서 가졌던 몇몇 단점들을 보완하기 위해서 만들어진 것이 바로 객체지향 패러다임이다.

객체지향 패러다임의 가장 큰 특징은 은닉성 이 높고, 의존성 이 낮다는 것 이다.

의존성과 은닉성

그중에서도 의존성을 낮추고, 은닉성을 높였다는 것이 가장 중요하다.

상기했듯이 절차지향 패러다임으로 프로그램을 만들 때엔 기능(funciton) 끼리 서로 의존성이 강한 경우가 많다. 그래서 하나의 기능을 수정하면, 그것과 연관된 수많은 다른 기능을 수정해야 한다.

이 불편함은 여러 사람이 하나의 프로그램을 만들 때에 정말 많이 발생한다. 게임 같이 수억줄의 코드의 프로그램을 만들 때는 찾아서 수정하는 걸 생각하는 것만으로도 막막해진다.

// greeting.mjs
export default class Greeting {
  static #name = 'gyunam'

  static hello(){
    console.log(`hello,${this.#name}.`)
  }

  static helloTo(name){
    console.log(`hello,${name}`)
  }
}

위에서 보였던 이 greeting.mjs 코드를 보면, #name 으로 감춰진 채 사용되고 있다.

이 Greeting 클래스를 사용하는 개발자는 이 내부에 #name 이 뭔지 몰라도 hello() 기능을 쓰는데는 아무런 문제가 없다.

이걸 은닉성이 높아졌다 고 표현한다.

// index.mjs
import greeting from './greeting.mjs'

const greeting = new Greeting()
greeting.hello()
greeting.helloTo('cat')

반대로 이 greeting.mjs 를 가져와서 사용했던 index.mjs 를 보자.

이 greeting.mjs 를 가져와서 사용하는 사람은 Greeting 클래스를 사용만 할 수 있으면 되지, 내부 동작을 알 필요가 없다.

물론, 이 클래스를 사용하는 사람에게 어떤 파라미터가 필요한지는 알려줘야 하지만, 그 정도만 알려주면 된다.

이걸 의존성이 낮아졌다 고 표현한다.

그리고 이 의존성이 낮아지는 것은 한 사람이 하나의 객체만 수정해도 된다는 의미기 때문에 유지보수가 편해졌다 고도 볼 수 있다.

마무리

객체지향이 더 좋은건가요?

그런 건 아니다.

필요에 따라 어떤 방식을 사용할 것인지 정하는 것이 맞다.

보통의 경우 소규모 프로그램의 경우엔 절차지향 패러다임이 더 편한 경우가 많다.

성능 역시 상대적으로 절차지향 패러다임이 더 빠른 경우가 많다.

그러나, 일정 수 이상의 인원이 같이 작업하는 경우에는 객체지향 패러다임이 훨씬 유지보수가 편해진다.

최근에는 거의 모든 앱이나 프로그램이 여러 사람이 협업하는 경우가 많기 때문에 객체지향 패러다임이 주로 사용되고 있다.