[CS] 프로그래밍 패러다임

해당 주제는 가톨릭대학교 GDSC에서 진행되는 테코톡 세션의 주제로 활용되었습니다.

 

프로그래밍 패러다임

특정 관점과 접근 방식에 따른 개발자의 코딩 방식

 
어느 분야이건 관점에 따른 여러 방법론이나 체계들이 분명히 존재한다. 당연히 프로그래밍 분야에서도 "어떻게 프로그래밍을 할 것인가?" 라는 질문에 대한 여러 의견들이 모여 이론적 틀(패러다임)이 생겨나고 개발자들은 패러다임을 바탕으로 프로그래밍하려고 노력하는 것이 중요하다. 즉, 프로그램이 실행되는 것에만 목적성을 두지 말고 프로그램 실행, 그 이상의 것을 위해 패러다임을 바탕으로 프로그래밍하는 것이 중요하다는 의미이다.
 

프로그램 실행, 그 이상의 것?

 

출처) https://t2informatik.de/en/smartpedia/spaghetti-code

 
스파게티 코드란 정상적으로 동작하지만, 사람이 코드를 읽으면서 그 코드의 작동을 파악하기는 어려운 코드를 의미한다. 좋게 말하면 가독성이 낮은 코드 더 나아가 재사용성, 확장성이 낮은 코드를 의미하고, 나쁘게 말하면 같이 일하기 싫은 코드를 의미할 것이다.
 
프로그래밍 경험이 적은 사람들이 가장 많이 하는 생각이자 실수는 "제대로 돌아가는 거 보니 해치웠군... 후훗..." 일 것이다. 이렇게 프로그래밍 실행 결과의 초점을 맞춘 프로그래밍을 한다면 그 이상의 것을 보지 못하게 되고, 스파게티 코드 개발자가 될 여지가 충분하다.
 
프로그램 실행, 그 이상의 것인 가독성, 재사용성, 확장성이 높은 코드를 짜고 싶다면 프로그래밍 패러다임에 대해 주목해 보자. 이제부터 가독성, 재사용성, 확장성, 즉 유지보수 측면에서 바라본 프로그래밍 패러다임에 대해 설명을 할 것이니 참고해 주길 바란다.
 
 

프로그래밍 패러다임의 등장

 

프로그래밍 패러다임의 진화(?)

 
대부분의 사람들은 위의 그림과 같이 프로그래밍 패러다임이 진화하면서 등장했다고 알고 있을 것이다. 하지만, 등장 순서는 이와 정반대로 함수형 프로그래밍 -> 객체지향 프로그래밍 -> 절차적 프로그래밍이다. 우리가 알고 있는 패러다임의 순서는 등장 순서가 아닌 해당 패러다임이 각광받은 시점이다. 왜 등장 순서와 각광받은 시점이 다르게 되었는지는 아래 링크를 참고하자.
 

[개발 상식] 3대 프로그래밍 패러다임의 등장과 부흥

 
프로그래밍 패러다임은 단순히 진화론적 관점에서 우열을 판단하는 요소가 아니다. 접근 방식과 사용 환경에 따라 유동적으로 활용되는 것일 뿐 어느 패러다임이 좋고 나쁘고를 따질 수 없다는 점 알아두고 이 글을 봐줬으면 한다.

 

명령형 프로그래밍 / 선언형 프로그래밍

 

출처) https://medium.com/@vincentbacalso/imperative-vs-declarative-programming-f886d3b65595

 
프로그래밍 패러다임은 방법과 목적에 따라 크게 명령형 프로그래밍과 선언형 프로그래밍으로 분류된다. 명령형 프로그래밍은 개발자가 직접 어떤 작업의 처리 과정에 대한 구체적인 방법을 명령하는 방식으로 프로그래밍된다. 알고리즘 문제를 풀 때의 프로그래밍을 생각하면 이해하기 쉬울 것이다.
 
반면, 선언형 프로그래밍은 개발자가 일일이 명령하는 것이 아니라 원하는 작업의 결괏값을 선언하는 방식의 프로그래밍이다. 정말 러프하게 말하면, 각 프로그래밍 언어에서 지원해 주는 순수 함수들을 적극 사용하여 프로그래밍하는 방식이다.
 
이 정도의 배경 지식을 가지고 각 패러다임에 대해 자세하게 알아보자.

---

절차지향 프로그래밍? 절차적 프로그래밍!

절차적 프로그래밍은 명령형 프로그래밍의 대표적인 프로그래밍 패러다임이다. 대부분의 사람들이 객체지향 프로그래밍과 엮어 생각하여 절차지향 프로그래밍이라고 알고 있을 텐데, 이는 한국어로 번역할 때 생긴 잘못된 용어이다.
 
절차적 프로그래밍 패러다임은 프로시저(Procedure)를 호출함으로써, 추상화와 코드의 재사용성을 목표로 하는 패러다임을 의미한다. 이때, Procedure를 사용하여 프로그래밍한다고 하여 Procedural Programming이라는 이름이 붙여졌고 이를 한국어로 번역하려고 절차적 프로그래밍이 되어버려서 대부분의 사람들이 프로시저가 아닌 이름 그대로 위에서 아래로 흘러가는 "절차"에만 집중하게 되는 헤프닝(?)이 벌어진 것이다.
 
프로시저는 곧 우리가 프로그래밍하면서 자주 사용하는 "함수"라고 생각하면 된다. 즉, 큰 기능(목표)을 처리하기 위해 작은 단위의 기능(함수)을 만들어 모듈화 하면서 프로그래밍하는 것이다. 모듈화는 반복하여 활용될 가능성이 있는 기능(함수)을 묶어 재활용할 수 있게 하는 것을 의미한다. 더 나아가, 모듈화 한 함수를 프로그램의 순서와 흐름에 맞는 적절한 위치에 호출하면서 전체적인 프로그램이 유기적으로 연결되게 프로그래밍하는 것을 의미한다.
 
정말 러프하게 말하자면, 알고리즘 문제를 풀다가 코드 줄이 너무 길어져 알아보기 쉽게 특정 로직을 함수로 만들어 빼놓고 그 자리에 함수를 호출한다던가, 협업 중에 동료 개발자들과 같이 자주 사용할 만한 유틸리티 기능을 하는 함수를 따로 만들어 필요할 때 적절한 위치에 호출하며 프로그래밍하는 것과 같다.

---

객체지향 프로그래밍

객체지향 프로그래밍은 명령형 프로그래밍의 꽃이라고 할 수 있는 프로그래밍 패러다임이다. 객체지향 프로그래밍은 절차적 프로그래밍의 한계점을 극복할 수 있는 패러다임으로 주목받았다.
 
절차적 프로그래밍은 로직적인 부분은 모듈화가 가능하였지만, 데이터 그 자체는 모듈화가 되지 못했다. 데이터 그 자체는 모듈화가 되지 못했다는 말이 무슨 의미일까?
 

객체지향의 대표적인 예시

 
스타크래프트의 각 유닛들을 절차적 프로그래밍을 사용해서 프로그래밍한다고 가정해 보자. 공격, 치료, 이동 등의 기능을 하는 함수들은 모듈화가 가능할지 모르지만, 각 유닛 자체를 모듈화 할 수 있겠는가? 위 사진처럼 많은 유닛들을 렌더링 하기 위해서 Dictionary나 Map 같은 Key-Value 타입의 변수로 선언한다고 가정해 보자. 서로 다른 종류의 유닛이라도 체력이나 종족 같은 공통의 Key 값을 가질 수 있을 것이다. 이때, 굳이 공통의 Key 값에 대해 반복적으로 선언을 해줄 필요 없이 함수에 매개 변수로 넘겨주듯이 Value 값만 넘겨주면 해당 Key에 대한 Value 값으로 적용될 수 있게 모듈화 하면 유지보수 측면에서 얼마나 좋을까?
 
객체지향 프로그래밍은 이렇게 데이터 그 자체를 모듈화 하지 못하는 절차적 프로그래밍의 한계점을 "객체"라는 모듈화 된 데이터의 개념을 도입하여 해결하였다. 
 

출처) https://wikidocs.net/113438

 
위 그림처럼 객체지향 프로그래밍을 하게 된다면 마치 설계도에 맞게 제품을 찍어내는 공장처럼 한 번의 설계로 수많은 다양한 객체들을 생성할 수 있다.
 
이러한 객체지향 프로그래밍을 간략하게 정리하자면 "데이터(프로퍼티)와 행위(메서드)가 담긴 객체 간의 관계를 통해 문제를 해결하는 방식의 프로그래밍"라고 할 수 있다.
 
객체지향 프로그래밍의 개념과 특징에 대해 자세하게 설명하면 한도 끝도 없어지기 때문에 중요 키워드 정도만 언급만 하고 넘어가겠다.
 

객체지향 프로그래밍의 중요 키워드

1) 클래스, 인스턴스, 인터페이스
2) 객체지향 프로그래밍의 4가지 특징 - 추상화, 캡슐화(은닉화), 상속성, 다형성
3) 객체지향 프로그래밍 설계원칙 - SOLID 원칙
4) GoF 디자인 패턴 - 생성 패턴, 구조 패턴, 행위 패턴
 
무조건 객체를 만들어 모듈화를 한다고 해서 유지보수하기 좋은 프로그래밍을 하는 것이 아니므로 꼭 위의 중요 키워드를 공부해 보고 자신의 코드에 적용해 보기 바란다.

---

함수형 프로그래밍

함수형 프로그래밍은 선언형 프로그래밍의 대표적 프로그래밍 패러다임이다. 절차적 프로그래밍이나 객체지향 프로그래밍처럼 코드의 구조적인 부분을 생각하는 패러다임이 아니라 코드 스타일에 관련된 프로그래밍 패러다임이다.
 
다음은 함수형 프로그래밍과 명령형 프로그래밍의 차이를 전적으로 보여주는 예시 코드이다. 배열에서 짝수를 필터링하고, 해당 짝수들을 제곱한 후 일정 개수만 추출하여 모두 더한 결괏값을 출력하는 코드를 각각 다른 프로그래밍 패러다임으로 구현한 것이다.
 

// 명령형 프로그래밍

const numbers = [1, 2, 3, 4, 5, 6];
const filteredNumbers = [];
for (let i = 0; i < numbers.length; i++) {
    if (numbers[i] % 2 === 0) {
        filteredNumbers.push(numbers[i]);
    }
}

const squaredNumbers = [];
for (let i = 0; i < filteredNumbers.length && squaredNumbers.length < 3; i++) {
    squaredNumbers.push(filteredNumbers[i] ** 2);
}

let sum = 0;
for (let i = 0; i < squaredNumbers.length; i++) {
    sum += squaredNumbers[i];
}

console.log(sum);

 

// 함수형 프로그래밍

const numbers = [1, 2, 3, 4, 5, 6];

const result = numbers
  .filter(num => num % 2 === 0)
  .map(num => num ** 2)
  .slice(0, 3)
  .reduce((acc, curr) => acc + curr);

console.log(result);

 
함수형 프로그래밍의 예시 코드에서 볼 수 있듯이 원하는 작업 자체를 함수로 "선언"만 해주면 각 언어마다 구현되어 있는 내장 함수들이 대신 처리해 준다. 이와 더불어 코드의 양이 확연하게 줄어들고 가독성이 크게 올라간다. 그렇다면 내가 사용하고 있는 프로그래밍 언어에서 지원하는 함수를 적극 이용해서 프로그래밍하면 함수형 프로그래밍을 하고 있는 것일까?
 
함수형 프로그래밍의 가장 주요한 특징은 순수 함수의 사용이다.
 
순수 함수란?

동일한 입력에 대해 항상 동일한 출력을 반환하며, 부작용(Side Effect) 이 없는 함수를 말한다.
즉, 함수의 실행은 오직 인자에만 의존하고 외부 상태를 변경하지 않는다.

 
순수 함수와 순수 함수가 아닌 함수의 차이를 보여주는 예제 코드를 보자
 

var a: [Int] = [2, 3, 1, 4, 5]

let b = a.sort()

var c: [Int] = [2, 3, 1, 4, 5]

let d = c.sorted()

print("결과: ", a, b, c, d)

// 결과: [1, 2, 3, 4, 5] () [2, 3, 1, 4, 5] [1, 2, 3, 4, 5]

 
결론부터 말하자면, sorted()는 순수 함수이고 sort() 함수는 순수 함수가 아니다. sorted()는 외부 상태, 즉 c의 데이터를 바꾸지 않는다. 함수형 프로그래밍은 데이터의 불변성을 지향한다. 데이터를 바꾸는 행위는 그로 인해 의도하지 않은 결과(Side Effect)를 초래할 수 있다. 함수형 프로그래밍은 순수 함수의 사용으로 이러한 Side Effect가 발생할 여지조차 주지 않겠다라는 컨셉의 프로그래밍 패러다임인 것이다. 더 나아가, Side Effect가 초래되지 않으니 예측 가능한 결과를 보장받을 수 있다.
 
이러한 함수형 프로그래밍은 기술의 발달로 멀티스레드 환경에서의 작업이 빈번하게 발생하는 요즘 같은 시대에 적합한 프로그래밍 패러다임이라고 할 수 있다. 멀티스레드 환경에서의 프로그래밍, 즉 동시성 프로그래밍의 가장 큰 적은 값이 변하는 데이터, 즉 변수이다. 두 스레드가 동일한 변수의 값을 하나는 +1, 하나는 -1을 상황이 발생하면 어떻게 될까? 당연히 Side Effect가 발생할 수밖에 없다. 따라서, 이러한 Side Effect가 생기지 않는 프로그래밍을 지향하는 함수형 프로그래밍이 각광받고 있는 것이다.