C로 다시보는 알고리즘 01 – 알고리즘이란

어떤 문제를 해결하기 위한 논리나 절차를 알고리즘이라고 한다. 하나의 문제를 해결하기 위한 알고리즘의 형식은 다양하지만, 일반적으로는 사람이 생각하는 알고리즘을 그대로 적용하는 데에는 한계가 있다.

예를 들어서 최대 공약수를 구하는 방법에 대해서 생각하게 되면, 두 수의 약수를 찾는 것은 사람의 경험적 직감에 의존하게 된다. 경험에 따라 문제를 해결하기 위해 접근하는 숫자에 대해서 도중식이 다를 수 있다. 이를 컴퓨터에서 실행한다면 논리가 엄청나게 복잡해지게 된다. 그래서 이를 기계석인 방법(=정형화된 수식화)을 통해서 해결하는데 유클리드 호제법을 이용한다.

그리고 하나의 문제를 해결하기 위해서는 여러 방법이 존재할 수 있다. 이 중에서 가장 적합한 방법의 알고리즘을 찾는 것 또한 중요하다. 그러한 것을 찾기 위해서는 여러 요건들이 존재한다.

  1. 신뢰성이 높을 것
    정밀도가 높고 올바른 결과를 얻을 수 있어야 함.
  2. 처리 효율이 높을 것
    계산 횟수가 적고 처리 속도가 빨라야 한다. 알고리즘의 효율성은 O 표기법(Big-O Notation) 단위를 사용하여 처리하는데, 이에 대해서는 뒤에서 추가로 설명한다.
  3. 일반적일 것
    특정 상황에서만 사용되는 알고리즘이 아닌, 다양한 상황에서 통용될 수 있어야 한다.
  4. 확장성이 있을 것
    변경 사항을 간단하게 수정할 수 있어야 한다.
  5. 알기 쉬울 것
    누가 봐도 알기 쉬워야 한다. 이해하기 힘든 알고리즘은 프로그램의 유지, 보수에 엄청난 걸림돌이 된다.
  6. 이식성이 높을 것
    유용한 프로그램은 다른 곳에서도 사용할 가능성이 높다. 따라서 프로그램의 이식성을 높일 수 있도록 해야 한다. 그 프로그램에서 이용된 알고리즘 또한 마찬가지이다.

이 알고리즘이 학문적일 경우에는 사실 1,2번에만 신경을 써도 된다. 그러나 실제로 사용할 경우에는 어느 정도 나머지 것들에 대해서도 고려를 해야 한다.

또한 컴퓨터에서는 다양한 형테의 데이터를 다루게 되는데, 데이터를 처리하는 데에는 특정한 데이터 구조(자료 구조)를 사용하느냐에 따라서도 문제 해결에 필요한 알고리즘이 생기게 된다. 이 이야기는 “Algorithms + Data Structure = Program” (Prentice-Hall, 1976)이라는 책에서도 언급되었던 내용이다. 데이터 구조와 알고리즘은 밀접한 관련이 있으므로 좋은 데이터 구조를 선택하는 것은 좋은 프로그램을 만드는 기초로 이어지게 된다. (그래서 자료구조도 중요하다)

그래서 이 블로그에서는 알고리즘에 대한 이야기를 주로 작성하지만 일반적인 자료구조에 대해서도 다루게 될 것이다.

C로 다시보는 알고리즘 00 – 시작

알고리즘과 디자인 패턴 중에서 여러모로 고민을 좀 많이 했다… 기존에 못썼던 C 내용을 더 쓰긴 할텐데 그거 말고도 내가 뭘 좀 더 해볼까 하는 것을…. 개발 기술이야 뭐 하나하나 느긋하게 올려서 쓰면 된다만…. 활용에 대한 것들을 적다보면 역시 도달하는 과정 중 하나는 알고리즘과 디자인 패턴이기 때문이다.

이 둘에 대해서 고민하는 이유… 내 블로그는 그냥 내가 쓰고싶은대로 글을 만들어 쓰고 있지만 그냥 여러모로 ㅂ고 들어오는 사람들이 맣ㄴ을 꺼라 생각해서 정리해본다.

알고리즘과 디자인 패턴은 컴퓨터공학에서 주로 2~3학년 과목으로 있는데, 이 둘은 주로 개발에 대한 이론적인 것을 다루는 여러모로 골아픈 과목 취급당할 수 있다. 그러나 이 둘을 잘 하는 것은 중요하다. 쉽사리 잘 할 수 있는 과목들은 아니지만 말이다…ㅇㅅㅇ;;;

특히 알고리즘은 프로그래밍 할 때의 문제 해결을 위한 생각의 기초 체력을 올려주는 것에 비유할 수 있다. 반면 디자인 패턴은 문제 해결을 할 수 있는 여러 가지 툴을 써보면서 이 툴을 어떻게 응용해야 할 지를 고민하게 해준다. 둘 다 사고력 업을 위해서 공부하는 것이지만 이 사고의 방향성이 다르게 된다.

이 중에서도 우선적으로 선택한 것이 바로 알고리즘이다. 디자인 패턴은 범위도 너무 넓지만 이렇다할 정답 또한 있는 것이 아니기 때문에…. 그래서 옛날에 공부했던 내용들을 다시 꺼내보면서 하나하나 진행해 보려고 이 챕터를 시작하였다.

참고로 내가 공부할 때에 봤던 자료들을 다시 정립하면서 코드를 짜는 거라 걍 내가 쉽게(?) 할 수 있는 C를 기반으로 작업한다.

….쉽잖아요. C언어….

C와 객체지향 – 01 – 시작

C언어에 대한 글을 쓰고 있다. 리눅스 환경에서 동작하는 C언어를 쓰면서 C언어의 기본적인 내용을 작성하였고, 리눅스 환경에서 C언어를 개발하는데 이용하는 라이브러리들, 그리고 gcc와 make에 관한 글을 작성하고 있습니다.

그런데 문득 작업 진행이 제대로 이루어지고 있지 않는다는 것을 깨달았다. 이젠 리눅스 환경에서의 사용이 중점이기 때문에 그쪽 자룔 정리해서 올리는 작업이다 보니 언어에 관한 작업이 더뎌지고 해서 그런지 작업 속도가 늘지 않았다. 졸업논문 쓰고 난 후의 피로감도 있고…

그래서 이와는 별개로, C에 대한 내용을 작성하였으니 이젠 C 자체만에 추가적인 내용을 적어보고자 합니다. 그게 바로 고급지게 쓰는 C입니다.

그 중에 첫번째로 바로 C와 객체지향에 대해서 작성해 보려고 합니다.

C는 절차지향적 언어라고 기본적으로 배우죠. 따라서 프로그램의 흐름이 중요하고, 그에 맞도록 함수를 잘 써서 분할하고 하는 작업에 대해서 중요하게 여깁니다. 그러다 보니 아무리 몇만 라인의 코드를 작성하더라도 코드 자체가 상당히 평평한 구조를 가지게 됩니다. 함수 하나만 해도 몇백 라인이 되기 일쑤고, 비슷한 기능 하는 함수들 미친듯이 만들고, 그런 함수들이 뒤에 숫자 2,3,4 이런 식으로 막 붙은 그런 함수들… 양산하기 무지 쉽습니다. (이 글을 읽어야 할 수준이라면 내 이야기 아니라고 생각하는 분 없을겁니다.)

내부 처리 로직 중에서는 공통으로 처리할 수 있는 부분은 공통으로 처리할 수 있지만, 동작 제어 함수들은 좀 사정이 다릅니다. 다양한 인자가 필요한 함수, 사용하는 데이터가 전역 변수로 연결, 독립성 결여된 함수들, 서로 의존관계가 너무 깊어 개별적인 테스트 할 수 없는 함수들….

사실 C에서는 특정 내용을 처리하기 위해 함수라는 것이 존재하고 이를 이용해 프로그램을 구조화할 수 있어야 한다고 가르치는데 왜 이런 현상이 발생할까요?

바로 디자인 패턴의 부재 때문입니다. 소프트웨어 개발에서 말하는 디자인 패턴은, 프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로, 과거의 소프트웨어 개발 과정에서 발견된 설계의 노하우를 축적하여 이름을 붙이고, 이를 재사용하기 좋은 형태로 특정 규약을 묶어서 정리한 내용을 말합니다. 문제 해결을 위해 해결 방법을 제시하고, 이를 사용 가능한 구조로 묶고 코드로 만들 수 있는 단계를 알고리즘이라고도 하기 때문에 알고리즘을 가르치는 것인가를 생각하기 쉽지만 디자인 패턴에서는 구조적으로 이미 정의된 문제를 해결하는 방식을 알려줍니다. 이미 정형화된 패턴을 문제에 적용하는 점이 아무것도 없는 상태에서 하나 하나 설계하는 중에 최적화 작업을 하는 알고리즘과는 접근 방법이 조금 다르죠.

그리고 이런 디자인 패턴의 많은 부분이 객체 지향 언어에서 사용하는 것을 전제로 하기 때문에 C랑은 상당히 무관하다는 듯이 배우고, 가르치는 분들 또한 그렇게 가르칩니다. 컴퓨터공학 전공한 분들을 아시겠지만, 객체 지향 프로그래밍 과목을 수강한 후에 디자인 패턴에 대한 강의를 들을 수 있다는 것을 알 수 있습니다.

그러나, C에서도 객체지향을 실현할 수 있습니다. 객체 지향을 잘 활용하면 프로그램의 구조가 기존의 C 프로그램들과는 달리 크게 변하게 됩니다. 또한 각 함수들이 독립적으로 작동하게끔 만들 수 있습니다. 이를 위해서는 C로 객체 지향을 염두해 두고 설계하고 프로그래밍할 수 있어야 합니다. 특히, 현대의 임베디드 시스템들과 C 프로그래밍에서는 이런 사고가 상당히 많이 적용되어 있기 때문에 C를 할 수 있다고 하려면 이런 수준까지 할 수 있어야 합니다.

그래서, C로 객체 지향과 같은 설계와 프로그래밍을 할 수 있는 방법을 포스팅하려 합니다.

p.s. 기존의 리눅스 환경에서의 C 프로그래밍과 별도로 활동합니다.