이름이 오히려 트릭
절차지향이라고 많이 알려져 있는 절차적 프로그래밍은 번역 때문에 오해의 여지가 크다. Procedural에 해당하는 프로시저를 그냥 절차 혹은 절차지향이라고 번역했기 때문이다. 절차적 프로그래밍은 절차를 중시하는 프로그래밍이라는 뜻이 아니라 (사실 모든 프로그램은 절차적이어야 한다...) 프로시저를 호출함을 통해서 추상화와 재사용성을 얻어내는 것이 본질이다.
프로시저 프로그래밍
절차적 프로그래밍의 정의
- 루틴, 서브루틴, 메소드, 함수 등을 이용한 프로그래밍 패러다임을 뜻한다.
- 단순히 순차적인 명령 수행이 아니다. 프로시저와 프로시저의 입출력을 다루는, 프로시저를 이용한 프로그래밍을 한다는 것이다.
프로시저란?
일반적인 의미로 어떤 행동을 수행하기 위한 일련의 작업 순서, 절차를 말한다. 또 특정한 로직을 처리하기만 하고 결과값을 반환하지 않는 서브 프로그램을 의미하거나, 함수와 비슷하지만 함수가 기능을 수행하는 반면 프로시저는 좀 더 넓은 의미로 함수들의 실행을 바탕으로 하는 일련의 작업을 수행하는 것으로 정의되기도 한다.
하지만 현대 프로그래밍 언어에서의 프로시저와 함수의 구분은 없어진 것이나 다름이 없다. 그래서 함수와 비슷한 개념으로 보면 되지만 그렇다고 함수형 프로그래밍과 동일하게 봐서는 안된다. 절차적 프로그래밍은 함수(그리고 함수를 관리하는 모듈)를 사용함으로써 얻어지는 재사용성에 초점을 두고 있다.
장점
프로시저를 이용해서 프로그래밍을 하게 되면 기본적으로 코드의 재활용성이 높아진다. 또한 메인 프로시저 뿐만 아니라 함수의 호출을 통해 여러 부분을 생략하여 프로그램 흐름을 쉽게 볼 수 있으므로 코드의 가독성 또한 높아진다. 모듈화, 구조화가 더 용이해지므로 대규모 프로젝트에서는 각자 자신의 맡은 부분만 프로그래밍하여 조립하는 것도 가능하다.
단점
프로시저를 호출하는 것은 그냥 코드를 사용하는 것보다 시간이 매우 많이 걸린다. 꽤 복잡한 과정을 거치며 코드를 그냥 쓰는 것(인라인)보다 적어도 네 번의 메모리 접근을 더 요구하고, 인자를 전달하는 경우 적어도 인자의 갯수만큼의 메모리 접근을 추가적으로 필요로 하는 등 많은 자원과 시간을 잡아먹는다. 그러므로 함수를 사용할 때 원칙적으로는 이것이 꼭 필요한지 생각해보는 것이 좋다. 하지만 이것도 옛날 이야기... 현재는 대부분의 컴파일러 성능, 하드웨어 성능이 좋아졌기 때문에 오버헤드를 걱정할 필요는 없다.
다음에 살펴볼 객체지향 프로그래밍과의 관계
절차적 프로그래밍은 객체지향 프로그래밍과 반대편에 서있지 않다. 일치한다고 볼 수는 없어도 서로 공유하는 부분이 차이보다 더 많다. 바른 개념은 절차적 프로그래밍의 관점이 프로시저에서 객체로 확장된 것에 가깝다. 절차적 프로그래밍에서는 프로시저의 입출력으로 코드를 관리했다면 객체지향은 객체의 단위를 추가, 그 내부의 프로시저를 통해 작업을 수행한다.
정리
절차적 프로그래밍은 우리가 흔히 함수를 사용해야 하는 이유를 다룰 때 가장 많이 등장하는 개념, 관점을 소개하고 있다. 프로시저라는 작업의 단위를 나누어 필요한 곳에 사용하고 또 사용함으로서 코드의 재사용성과 가독성을 높인다는 생각은 우리 코드를 훨씬 더 간결하게 목적성있게 만들어줄 것이다.
