내 취미는 프로그래밍이다. 늙어 치매에 안걸리려고 젊은 시절 조금씩 배운 것인데, 어느덧 아마추어 경지는 좀 넘어섰지 싶다. 최근에 모 제품을 개발해서 출시했다. 잘 팔리지는 않지만 괜찮다. 어차피 취미로 한 일이니까.

내가 처음 배운 컴퓨터 언어는 C언어라는 놈이었고, 이놈이 좀 발전해서 C++이 되었다. 좀 나중에는 파스칼 언어를 채택한 당시 볼랜드라는 회사의 델파이 언어와 접하게 되었는데 생산성이 좋아 지금도 애용하고 있다.

프로그램의 세계에는 OOP(Object Oriented Programming)라는 개념이 최근 몇 년 동안(적어도 C++ 언어 이래로) 하나의 주된 컨셉을 이루고 있다. 우리말로는 흔히 객체지향이라고 하는데 프로그래밍 세계에 있어서 그야말로 획기적인 분기점을 형성하는 개념이다.

OOP 개념의 등장

OOP 이전의 프로그래밍은 특정한 상황에서(프로그래밍적인 언어로는 주어진 변수 하에서) 주어진 특정의 일을 반복하는 소단위의 코드(이를 루틴, 혹은 함수라 부른다)들을 만들고 필요에 따라 몇몇 개의 코드를 묶어 더 큰 단위의 코드를 묶는 방식이 주된 방식이었다. 즉 A, B, C, D, E, F, G의 소단위 코드들은 ABC가 결합된 K코드나 ADE가 결합된 J코드를 만들어내고 어떤 경우에는 A와 J가 결합한 P코드를 만들어내고, 어쨌든 그런 식이었고 최종적으로는 이를 하나의 커다란 코드로 묶는 방식이었다.

이런 프로그래밍 방식은 곧 한계에 부딪치게 된다. 프로그램 세계에서는 만드는 것이 하나의 주된 과제라면 유지, 보수, 확장은 또 다른 주요 과제가 된다. 가령 기존의 방식에서는 P코드가 고장이 나면 A와 J코드의 잘못을 찾아야 하고 결국 A코드를 수정하게 되면 이번에는 A코드를 포함하고 있는 K코드 또한 오작동을 할 수 있다. 그러면 결국 K코드를 사용했던 더 큰 코드들이 전체적으로 오작동을 하게 되므로 이를 수정해야 하고... 오죽하면 최초의 베이직 언어(인터프리터 언어시절이었을 때)를 스파게티 언어라고 비꼬았을까?

OOP의 세계는 다르다. OOP의 세계에서는 프로그램의 1차 하위단위로 클래스라는 개념이 도입되고, 모든 프로그램은 클래스간의 결합으로 이루어진다. 각각의 클래스는 자기 자신의 멤버코드(이를 멤버변수, 혹은 멤버함수 등등으로 부른다)를 갖게 되는데 이들의 멤버 코드들은 철저하게 해당 클래스 안에서만 기능하고 작동하도록 설계된다.

적어도 잘 설계된 프로그램에서는 가령 A클래스와 B클래스는 서로 간섭하는 일 없이 혹은 상대방 클래스가 하는 일이 무엇인지 전혀 알지 못한 채 자신에게 주어진 역할만을 충분히 수행할 수 있도록 설계된다. 즉 자동차의 바퀴를 갈아 끼우거나 문짝을 갈면서 엔진의 상태를 알 필요가 없도록 하는 방식으로 설계된다. 이런 방식에서는 나중에 유지, 보수, 확장시 필요한 다른 클래스에 대한 관심없이 해당 클래스만을 수정하는 것만으로 충분하게 된다. 프로그래머들이 지향하는 최고의 이상적인 상태이다.

말처럼 쉬운 것만은 아니다. 그래서 OOP를 가장 완벽하게 하기 위해서 많은 프로그래머들이 나름대로 노력하고 있고, 그 중 한 가지가 요즘 유행하는 '디자인 패턴'이라는 것이다. 내가 디자인 패턴과 관련한 원서를 읽고 있었더니 우리 집사람이 나더러 많이 세련돼졌다고 하던데 집사람이 생각하는 그런 디자인 패턴은 물론 아니다. 프로그램 설계를 가장 OOP적으로 하기 위한 선배 프로그래머들의 피나는 연구 산물인 것이다.

OOP적인 프로그래밍은 좋은 것이지만 많은 경우에 이를 따르지 않는 경우가 있다. 대표적인 경우가 빨리 제품을 생산하기 위해서이다. 좋은 OOP 프로그램을 만들기 위해서는 초기 단계에서 꼼꼼한 설계가 필수적으로 요구되고 통상 코딩과정도 훨씬 길고 복잡해진다. 그렇지만 일단 필요한 기능만 구현하는 경우 굳이 OOP적인 방법을 동원하지 않더라고 쉽고 빠르게 코딩을 마칠 수 있고 첫 제품이 나오기까지 상당한 시간을 줄일 수 있다. 이 때문에 게으르거나 귀찮을 때, 혹은 어떤 시간상의 이유 등으로 OOP적인 설계를 건너뛰고 싶은 유혹은 언제나 있기 마련이다.

하지만 이렇게 만든 프로그램은 대충 거기까지가 끝이 된다. 처음 생각하지 못했던 다른 환경, 혹은 사용자로부터의 다른 요구, 업그레이드 상황 등이 발생했을 때 누더기 코딩과 OOP에 입각한 코딩의 생산성은 현격히 달라진다. 누더기 코드라면 심지어 어느 곳을 고쳐야 할지 찾기도 어려울뿐더러, 설령 고쳐놓고도 완전성을 장담하기 힘들어진다. 반면 OOP에 입각한 코딩이라면 필요한 작업을 담당하는 특정 클래스의 특정 코드를 수정함으로써 쉽고 빠르게 일을 마칠 수 있다. 그래서 OOP적인 코딩은 처음에는 힘들지만 도중에 프로그램을 쓰고 버릴 요량이 아니라면 어떤 의미에서는 반드시 지켜야만 하는 원칙과도 같은 것이 된다.

OOP에서 최고의 생산성은 언제 발휘될까? 가령 KBS라는 클래스는 청와대라는 클래스와 완전히 독립적으로 설계되는 경우이다. KBS 클래스가 하는 일은 청와대 클래스가 전혀 알지 못한다. 청와대 클래스의 내부가 어찌 변하든 KBS 클래스는 이에 따라 변하지 않는 경우이고 그 반대의 경우도 마찬가지다. 대한민국이라는 프로그램 안에 분명 KBS와 청와대는 꼭 필요한 클래스이고 아주 중요한 역할을 하는 반면 클래스간의 독립성이 완전히 보장되는 경우이다.

노짱과 MB, 쓸모있는 '분'과 없는 '놈'의 차이

청와대라는 클래스의 내부 움직임이 변함에 따라 검찰이라는 클래스 내부가 따라 움직이는 것은 아주 잘못된 프로그램의 전형이다. 이런 프로그램은 검찰 클래스의 내부 버그를 고치려 들면 청와대 클래스가 오작동하게 되고 결국 청와대 클래스의 버그를 같이 고쳐야만 한다. 청와대 클래스의 버그를 바로잡으려 들면 이번에는 KBS와 YTN 클래스의 버그를 바로잡아야 하고. 경제계의 클래스도 다시 고쳐야 하고...... 뭐 그런 식이다. 한마디로 스파게티 구조가 되는 셈이다.

요즘 프로그래밍을 하면서 노짱께서는 타고난 프로그래머가 아닌가 하는 생각이 든다. 왕년에 모 DB 프로그램을 손수 만드신 적이 있다고 들었는데 아마 프로그램밍을 하셨어도 지금쯤 엄청난 대 프로그래머가 되셨을 것 같다. 즉 노짱께서는 각 클래스간의 독립성이 전체 국가프로그램의 유지, 보수, 확장을 가장 원활하게 할 수 있는 빠른 길임을 간파하고 계셨던 것 같다.

노짱께서 검찰의 속성을 잘 간파하고 계셨지만 어느 때보다도 이의 독립성을 최대한 지키고자 노력하셨던 것 같다. 심지어는 조중동처럼 패악질을 일삼는 언론에 대해서까지 노짱께서는 하나의 클래스로(이런 클래스를 프로그램 세계에서는 obsolete class라 부른다, 더는 쓸모가 없는 클래스라는 뜻) 인정하고 계셨던 것 같다. 각기 클래스들이 다른 외부클래스와 독립한 상태에서 최대한의 효율성을 발휘할 때 전체 프로그램이 최대의 효율성을 발위한다는 OOP적인 원리를 이미 체득하고 계셨던 것이다.

청와대 클래스와 KBS 클래스, YTN 클래스, 검찰 클래스, 경찰 클래스, 이런 것들을 최대한 함께 뒤섞으려는 지금 청와대의 노력은 OOP 이전 시대에나 적합한 것이다. 지금은 옛 박정희 시대의 주장처럼 국가라는 프로그램을 어쨌든 빨리 개발해내야 하는 그런 상황도 아니다. 국가라는 프로그램은 이미 많은 부분이 성숙한 상태이고, 따라서 지금 우리에게는 원활한 유지, 보수, 확장이 더 필요한 과제가 되고 있는 시기이다. 그러기 위해 각 클래스간의 철저한 독립성 보장은 어느 때보다도 더 필수적이다.

OOP적인 프로그래밍 방식은 누가 뭐래도 훌륭한 방식이다. 이는 누가 창조한 것도 아니고 수많은 프로그래머들의 실제 경험과 체득과정에서 누적돼 서서히 '발견된' 업적의 산물이다. OOP적으로 잘 만들어지고 있는 프로그램을 비 OOP적으로 되돌리려는 프로그래머는 아마 바보 프로그래머이거나 혹은 실력이 부족한 프로그래머 둘 중의 하나일 것이다. 안타깝게도 나는 요즘 청와대 프로그래머들에게서 OOP 시대 이전으로 되돌아가고자 하는 이해할 수 없는 몸부림을 자주 보게 된다.

ⓒ 천년세월