Effective Programming

이 글을 통해 알리려고 하는 내용은 사실 객체지향에 국한된 얘기는 아니다. 그래서 우선 시작은 구조적 언어(C언어)를 중심으로 이야기 하려고 한다. 하지만 객체지향에서 이 부분이 더욱 강화되고 원칙화 된 것이므로 당연히 객체지향으로의 확장도 다루도록 하겠다.

속성과 행위

결과물은 객체지향 쪽으로 흘러갈테니 용어도 객체지향으로 시작하겠다. 속성이란 기존 구조적 언어에서는 변수라고 부르는 것이고, 행위란 함수라고 부르는 것이다. 변수는 데이터를 저장할 수 있는 것, 변경되는 것이며 함수는 제어, 연산을 수행하는 것, 변경할 수 없는 것으로 이해한다. 일반적으로는 맞는 이야기이지만 이 이해에 매몰되면 좋은 소프트웨어를 만들기 어려운 것이 사실이다.

속성을 통한 행위의 변경

행위(함수)는 변경될 수 없다. 이것은 사실이다. 이미 코드 상에서 행위를 정의한 이후에 이것을 런타임에 변경하는 것은 불가능하다. 하지만 상황에 따라서 다른 행위를 해야 하는 경우는 비일비재 하다. 그래서 이러한 경우에 보통 값에 대한 변경이 가능한 변수를 활용한다. 지금 상황(state)에서는 덧셈을 해야 한다면 상황을 표현하는 변수를 만들고, 이 변수 값(ADD_STATE)을 통해서 덧셈을 하도록 행위를 유도한다. 반대로 뺄셈을 해야하는 상황이라면 변수 값(SUB_STATE)을 변경해서 뺄셈을 하도록 유도한다. 이것은 속성과 행위의 특성을 보면 당연하다. 변경이 가능한 것(변수)을 이용해서 변경이 불가능한 것(행위)을 변경하는 것이다. 그래서 프로그래머들은 상황을 알려 주기 위해서 변수를 선언하고 이를 상태(state)라고 보통 부르고(flag를 사용하기도 한다), 행위의 변경은 이 상태 변수가 어떤 값을 가지는지에 따라 조건문을 작성하고 그에 종속된 행위들을 나열한다.

말로 설명하는 것보다 코드를 보는 편이 더 빠르겠다. 자 다음과 같은 코드를 한번 보자. 일단 이 문제는 구조적 언어로부터 출발해 보도록 하겠다.

상태에 따른 동작 변경

위의 예제는 state 변수의 값에 따라서 덧셈과 뺄셈을 조건적으로 수행하는 코드이다. 위 코드를 요구사항 관점에서 기술해 보면 다음과 같다. "상태가 덧셈 상태이면 결과에 덧셈 결과를 저장하고, 상태가 뺄셈 상태이면 결과에 뺄셈을 저장하라." "상황에 따라서 다른 동작을 수행해야 한다"는 관점에서 살펴 봤을 때 위의 코드에 어떤 문제점이 있겠는가? state 변수의 값을 if문으로 살펴보는 것은 상황에 따라 다르게 동작해야 한다는 조건을 만족시키는 일이므로 전혀 이상하지 않을 만한 코드이다. 그리고 셀 수 없이 많은 프로그래머들이 이런 형태로 프로그래밍을 하고 있다. 어찌보면 상황에 따라서 다른 동작을 하라는 요구사항을 만족시키는 방법은 위의 코드 밖에 없어 보인다.

자 문제에 대한 관점을 조금씩 바꿔 나가기 위해서 다음과 같이 코드를 수정해 보도록 하겠다.

먼저 위와 같이 덧셈과 뺄셈을 수행하는 코드를 별도의 함수로 독립 시킨 다음, 조건문이 있는 곳을 다음과 같이 수정한다.

논리적인 결과는 첫번째 소스와 전혀 차이가 없다. 단지 덧셈 구문과 뺄셈 구문을 함수로 독립시켰을 뿐이니까.

그런 다음 한가지 생각을 떠올려 보자. state가 변수로서 하는 일은 오직 add()와 sub()함수를 바꿔서 실행 시킬 수 있도록 하는 것이다. 그렇다면 state 변수 대신 add() 함수와 sub 함수를 바꿔 넣어도 되지 않을까?

행위에 대한 직접 변경

생각하는 방식이 바뀐 것을 간단히 정리 해 보면 다음과 같다.

기존 : 상태 변수를 선언하고, 상태 변수에 상태 값을 할당하고, 상태 값을 체크하고 상태 값에 따라 덧셈과 뺄셈을 바꿔 계산한다.

변경 : 하고 싶은 행위에 따라 덧셈과 뺄셈을 하는 함수를 집어 넣는다.

간접적으로 행위를 변경하던 것을 직접 행위를 변경하는 것으로 바꾼 것이다. 이것이 일면 별 것 아닌 것처럼 보이지만 효과는 상당하다. 효과를 정리해 보면 다음과 같다.

1. 조건문이 사라졌다. 부수적으로 코드가 단순해졌다.

2. 이해하기가 쉬워졌다. 계산이 덧셈 뺄셈만이 아니라 곱셈 나눗셈 등 온갖 계산들이 나열되었다면 저 한가지 변화의 크기를 직감할 수 있을 것이다.

3. calculate 함수가 조건 체크에 실패 했을 때 return 0을 수행하던 것이 사라졌다. 이는 의도하지 않은 결과로 소프트웨어가 계속 동작하는 것을 방지해 준다.

생각보다 강력한 결과

이 방법은 상태 변수를 사용하는 모든 경우에 적용이 가능하다. 그 말은 상태 대신 행위를 직접 바꾸면 모든 상태 변수를 없앨 수 있고, 모든 조건문을 없앨 수 있다는 말이다. 이 결과로 유추해 보면 100 라인의 코드든 1000라인의 코드든 이론적으로는 조건문 없이 구현할 수 있다는 얘기다. 실제로 몇 달 전에 작성한 차트 그리기 프로그램(자바)은 5000라인(공백 제외)이었는데 조건문을 조사해 보니 60개 정도였다. 약 100라인에 if 문 혹은 switch 문이 한 개 있는 비율이다. 이것이 상태 변수를 없애고 행위를 직접 변경한 결과이다.

<바 차트, 라인 차트, 레전드 위치 변경, 레이블, 폰트 변경, 바 컬러 변경, 값에 따른 바 컬러 변경, 차트 흐름 고정, 테마 변경 등에 이르는 수많은 옵션들을 지원하도록 만들어졌지만 조건문은 단 60개 뿐이다>

상태에 종속적인 행위 변경

나는 상태를 선언하고, 상태에 대해 조건문을 작성하고 조건에 따른 행위를 수행하는 과정을 "상태 종속적 행위 변경"이라고 부른다. 지금도 많은 프로그래머들이 이러한 안티 패턴을 통해서 소프트웨어를 만들고 있다. 상태 변수를 선언하고, 상태에 따른 조건문을 작성하고 조건에 따라 다른 코드들을 집어 넣는다면 모두 "상태에 종속적인 행위 변경"이라는 안티 패턴을 사용하고 있는 것이다.

객체 지향에서의 행위 변경

객체지향 언어에는 상태 종속적 행위 변경 문제를 해결하는 디자인 패턴이 이미 정의 되어 있다. 전략 패턴과 상태 패턴이 바로 그것이다. 그리고 null 객체 패턴 + Special Case 패턴처럼 조금 덜 유명한 디자인 패턴도 상태 문제를 행위 문제로 바꿔주는 패턴들이다. 

전략 패턴에서는 A라는 객체가 B라는 객체에게 일을 시킬 때 일부 변경하고자 하는 행위가 있다면 이 행위를 객체화 하여 B에게 인자로 넘겨 준다. 이러한 방식으로 행위를 상태 변수 없이 변경한다. 맨 처음 예제가 사실 전략 패턴의 C언어 버전이라고 할 수 있다.

전략 패턴 예제

< 맨 처음 예제를 Java로 전략 패턴 형태로 바꾸어 본 것이다. 함수 포인터 대신 객체를 넣는다는 점 만 다를 뿐이다>

상태 패턴은 상태가 필요한 객체가 각 상태를 객체화시킨다. 그리고 필요한 상태에 따라 상태 객체를 변경시킨다. 그러면 상태 객체의 메소드를 호출할 때마다 상태에 따라 행위가 바뀌게 된다.

null 객체 패턴은 인자로 넘어온 객체가 null인지 체크(null 상태인지 아닌지를 체크하는 것이다) 하는 대신 아무 동작도 하지 않는 Null 객체를 만들어 넘긴다. 그려면 객체를 받는 쪽에서는 넘어온 객체에 대해 null 인지를 체크하지 않아도 된다. 실행해도 아무 동작도 하지 않을 뿐이다.

객체지향 언어는 무 조건문/무 상태 언어이다

객체지향 언어를 사용하면 switch 문의 사용이 줄어든다는 얘기가 있다. switch - case 문에서 체크  되는 변수 대신 상위 클래스에 대한 레퍼런스를 선언하고, 각각 실행되는 문장들을 개별 객체화하여 레퍼런스에 할당해주면 switch-case문이 없어지기 때문이다.(이것이 디자인 패턴에서 말하는 상태 패턴이다) 여기서 조금 더 나가보면 이런 상태 변수들은 모두 객체 레퍼런스로 대체될 수 있고, 변수에 의해 바뀌는 행위, 즉 조건문 안의 행위들은 모두 개별 객체로 대체될 수 있다. 그러면 조건문들이 모두 사라진다.

객체지향을 이야기 할 때 다형성은 빼 놓고 이야기 할 수 있는 특징이다. 다형성은 여러 객체가 있지만 외부적 관점(즉 "타입" 관점)에서는 동일한 객체로 취급하겠다는 것을 의미한다. 동일하다는 것은 구분하지 않는다는 것이고, 구분하지 않는다는 것은 조건을 체크할 필요가 없다는 것이다. 그것은 상태에 따른 조건문 체크가 없는 것과 같다.

좀 더 나가보면 근본적으로 객체지향이 추구하는 방향은 상태를 보지 않겠다는 것이다. 오직 상대를 행위 대상으로만 바라본다. 인터페이스에는 변수가 없다. 즉 상태를 보지 않아도 된다는 의미다. 어느 객체가 동작 불가능한 상태에 있다고 가정하자. 이것을 외부에 알려줄 필요가 있을까? 객체가 동작 불가능한 상태라고 판단하면 그 객체는 실제 동작들을 객체화 해 두었다가 동작 객체를 동작 불가능한 객체로 바꾸기만 하면 된다. 그러면 외부에 자기 상태를 알려줄 필요가 없다.

객체와 객체 간에는 공유하는 변수가 없다. 상태는 변수의 부분집합이므로 상태도 공유되지 않는다는 의미이다. 인터페이스가 보여주는 것처럼 다른 객체의 상태를 몰라도 사용할 수 있다. 외부적 관점에서 상대방 객체는 상태가 없다. 그러면 조건문 없이 사용할 수 있다. 내부적으로는 상태를 객체로 대체한다. 그러면 상태 없이 구현될 수 있다. 그러면 조건문 없이 사용될 수 있다.

따라서 객체지향 언어는 무 조건문 / 무 상태 언어이다.

(구조적 언어도 함수 포인터라는 무 상태 언어적 특성을 가지고 있다. 하지만 이러한 관점이 널리 보급되지는 못했다. 아무래도 객체지향 언어에서 처럼 상태 제거를 위한 함수 포인터를 다중 중첩해서 사용하기가 어려운 문제가 있었을 것이다. 함수 포인터를 많이 사용한 코드는 사실 이해하기가 어렵다. 함수 포인터는 근본적으로 변수이고, 변수적인 타입만 체크 할 뿐 객체지향 언어의 "타입"처럼 특별한 제약이 없기 때문에 문제가 발생할 가능성이 많다.)

가장 단순한 적용 방법

우선 변수를 선언할 때 생각을 해보자. 변수가 상태를 나타낼 것이고, 조건문에 사용될 것인가? 그렇다면 그 변수는 필요 없다. 객체로 대체하라.

조건문을 만들기 시작했다. 조건문에 사용되는 변수가 하나 인가? 그러면 그 변수는 필요 없다. 객체로 대체하라.

조건문에 들어가는 변수가 여러개인가? 여러 변수를 하나의 변수로 바꿔라.

이 과정을 따르면 반복문을 제외하고는 단 한 줄의 코드도 들여쓰여지지 않은 코드가 만들어질 것이다.

객체지향은 참 어렵다.

이제 객체지향을 그래도 좀 이해하고 프로그래밍을 한다는 생각을 하고 있지만 객체지향 언어로 개발을 해 오면서도 그 개념을 제대로 이해하지 못하고 지낸 시간이 훨씬 더 길다는 점을 생각해보면 지금의 이해한 것을 다른 사람들에게 잘 설명하는 것이 얼마나 힘든 일일지 상상이 간다.

개인적인 경험으로 보면, 객체지향 언어를 배우고 잘 사용하게 될 때까지의 난관을 보면 대략 다음과 같다. 

처음 : 개념 및 문법에 대한 이해

처음에는 객체지향 언어 문법을 열심히 공부하게 된다. 객체지향 언어의 난감한 점은 우리가 풀어 내려고 하는 문제에 대한 직접적인 구현(변수 선언, 함수 선언, 조건문, 반복문, 연산자 등)을 이해하는데 들어가는 노력에 비해 객체지향 개념(클래스, 객체, 캡슐화, 상속, 다형성?, 재정의, 인터페이스, 추상 클래스 등) 자체를 이해하는 것이 훨씬 더 어렵다는 점이다. 어려운 이유는 간단하다. 객체지향 개념이 필요한 이유를 문법을 공부하는 당시까지는 전혀 알 수 없기 때문이다. 하지만 이 단계를 일단 거치고 나면 이제 마치 객체지향을 제대로 다룰 수 있겠다는 생각이 든다.

난관 : 잘 짜여진 객체지향 코드를 접했을 때

이제 어떻게든 클래스와 객체도 알고, 돌아가는 프로그램을 작성할 줄도 알게 된다. 그래서 개발에도 속도가 좀 붙고, 기능을 이렇게 저렇게 만들어 가게 된다. 그러다가 어느 순간 오픈 소스 혹은 잘 짜여진 라이브러리들을 접하고 충격을 받게 된다. 처음에는 너무 난잡해 보여서 이해가 가질 않는다. 어떤 기능이 어떻게 동작하는지를 보려면 이 클래스, 저 클래스 파일을 넘나 들어야 하고, 굳이 상속을 왜 받아서 하위 클래스를 이해하는데 상위 클래스로 이동해야 하고, 상속을 넘어서 인터페이스로 넘어 가면 구현부가 없는 것을 보고 당황해 해야 한다. 온갖 기교를 써가면서 어떻게든 여러 클래스를 같은 클래스 혹은 인터페이스에 대한 하위 클래스로 만들기 위해 노력하는 이유를 대체 알 수가 없다.

깨닫기 전 : 이제 잘하고 있다고 생각했는데

이제 상속을 통한 기능의 확장에 대해서도 이해하고 나름 중복 코드를 보고 줄일 줄 알게 되고, SRP 쯤은 알아서 기능도 잘 구분해서 구현할 줄도 알게 되었다. 하지만 그래도 누군가 와서 내가 만든 코드를 보고 이렇게 이야기 한다. 객체지향의 핵심은 다형성이다, 인터페이스를 중심으로 설계하라, 상속을 통해 기능을 확장하지 마라 등등.

개인의 능력에 따라서는 이 과정이 생각보다 짧았을 수도 있을 것이다. 하지만 개인적인 경험에 비춰 보자면 앞으로 이야기 할 내용을 미리 알고 있었을 정도가 되었다면 객체지향을 접한지 최소 5년은 되었다고 봐야 한다. 그보다 더 오래되었어도 이해하지 못하는 경우도 있다.(좋은 개발 선배가 있었다면 모르지만.) 혹시 아래 내용을 보고 "겨우 그거 이야기 하려고 이런거야?" 라고 하신다면 내 능력이 부족한 것이니 할 말은 없다. 아까운 시간을 빼앗아 죄송스럽다는 말을 할 수 밖에.

이제 본론으로 넘어가서 그러면 과연 상속이란 무엇인가? 우선 위키를 찾아보면 다음과 같다.

사실 이 내용 중에는 이후에 이야기 할 내용에 딱 맞는 내용이 없다. 하지만 살펴볼 가치는 있다.

우선 2번이 적절한 정의로서 확 와 닿을 것이다. 일반적으로 상속이라는 의미는 단어가 가진 의미와 마찬가지로 무엇인가를 "물려 받는다"는 의미이기 때문이다. 즉, 상위 클래스가 가진 속성(변수)과 행위(멤버 함수)를 내려 받는 것을 상속이라고 보통 말한다. 이것이 이해하기 쉬운 이유는 상속이라는 단어의 실생활 속에서의 의미와 가장 유사한 개념이고, 프로그래밍을 할 때 변수와 함수를 물려 받아 재 구현해야 하는 번거로움을 없애준다는 점에서 실질적인 이득을 주기 때문이다.

아주 마음에 들지는 않지만 1번과 3번이 그나마 좀 더 객체지향을 이해하는데 도움이 되는 정의이긴 하다.

자 그러면 저 정의들이 명시적으로 보여주지 못한 가장 중요한 부분은 무엇일까?

잘 이해가 안 갈 수도 있기 때문에 질문을 살짝 바꿔서, 상속을 받았을 때, 상속 받은 것 중에서 가장 중요한 것은 무엇인가?

정답은 "타입"이다.

사실 2번의 정의는 핵심을 빠뜨렸다. 클래스는 기존 클래스로부터 가장 중요한 것인 "타입"을 물려 받고, 속성이나 동작 "따위"의 소소한 것을 물려 받는다가 정확한 정의다.

객체지향에서 객체를 바라 볼 때 가장 중요한 것은 "외부적 관점"과 "내부적 관점"의 분리이다. 익히 알고 있는 속성과 행위가 아니다. 내부적 관점이라는 것은 객체의 동작을 어떻게 구현할 것인가 하는 점이다. 이 때 보이는 것이 속성과 행위이다. 이것을 잘 구현해야 하는 것은 당연한 것이다. 하지만 이것보다 중요한 것이 외부적 관점이다. 외부적 관점은 "그 객체를 어떤 객체로 인식할 것이며, 어떻게 다룰 것인가?" 이다.

만약 어떤 객체가 실제로는 Rectangle이라고 해도 (Shape을 상속 받았다 치고) 외부에서 인식하기를 Shape이라면 그것은 외부적 관점에서는 Shape이다. 그 실체가 Rectangle이라는 사실은 그 객체 내부에서나 중요한 것이지 밖에서 그 객체를 사용하는 입장에서는 아무런 의미가 없는 것이다. 그 객체는 그냥 Shape일 뿐이다. 오케스트라의 지휘자는 자신의 연주자들이 자신의 지휘에 맞춰 연주할 수 있느냐에 관심이 있지 그 사람이 바이올린 연주자인지 첼로 연주자인지는 관심을 가질 필요가 없다. 그저 지휘만 하면 알아서 연주를 할 것이고, 그것이면 충분하다.

그렇다면 외부적 관점, 즉 "타입"이 왜 그렇게 중요한지 간단한 예제를 통해 살펴보자.

크게 이해하는데 어려움은 없을 것으로 생각된다. 두 개의 List를 만들어서 각각 Rectangle과 Color를 저장할 수 있도록 하고, 객체 하나씩을 만들어 넣은 후 이를 for 문을 이용해서 출력하는 구문이다. 반복되는 느낌은 있지만 어찌하겠는가? Rectangle과 Color는 엄연히 "타입"이 다른데!

그러면 다음을 보자.

예상했겠지만 둘의 출력 결과는 같다. 이것이 왜 가능한지도 이미 알고 있을 것이다. Java의 모든 객체는 Object 클래스를 상속 받았기 때문이다. 즉 Object "타입"이다. 코드 상에서, 즉 객체의 외부에서 (실제 객체는 서로 다르더라도) Object 타입으로 불려지게 되는 순간, 둘의 차이는 사라진다. 그리고 그와 함께 중복된 코드들도 함께 사라진다. 만약 서로 다른 종류의 객체가 훨씬 더 많았더라면 더욱 많은 코드들이 마법처럼 사라졌을 것이다. 마치 오케스트라 지휘자가 바이올린 연주하세요, 첼로 연주하세요, 플룻 연주하세요......와 같이 끝나지 않을 것 같은 XXX 연주하세요를 반복하지 않는 것과 같다. 부조리함이 많은 현실 세계에서도 이런 합리성을 추구하는데 매일 논리와 싸우는 우리 같은 사람들이야 어떠하겠는가?

간단한 예제였지만 상속의 진정한 가치와 의미를 이해하는데는 어려움이 없었을 것으로 생각된다. 상속 개념에는 분명 속성과 행위를 내려 받아 중복된 코드를 작성하는 것을 방지해 준다는 이점도 있다. 하지만 상속이 진정한 위력을 발휘 하는 것은 이러한 내부적 관점이 아니라 "타입" 상속이라는 외부적 관점이다. 이 관점이 위력적인 이유는 아무리 실질적으로는 다른 객체들이라도 동일하게 취급할 수 있고, 동일하게 취급되는 순간 유사하긴 하지만 반복적으로 구현되었던 수많은 중복 코드들을 사라지게 만들 수 있다는 점이다. 이러한 관점에서 보면 속성이나 행위 따위를 상속 받는 것은 매우 소소한 것으로 취급될 수 밖에 없다.

그래서 한 번 쯤 더 생각해 볼만한 부분이 바로 인터페이스와 추상 클래스의 개념이다. 인터페이스는 속성과 실제 구현부라는 실체는 눈 씻고 찾아봐도 없고 눈으로 보기에는 빈 껍데기에 불과한 API만을 제공한다. 하지만 이 빈껍데기는 "외부적 관점"을 제공해 주고, 이 관점을 이용하는 외부에서 그 객체를 다루는데는 전혀 어려움이 없다. 따라서 같은 인터페이스를 상속 받은 객체들에 대해서는 같은 관점을 유지할 수 있고, 같은 관점을 유지할 수 있다는 것은 동일하게 취급할 수 있다는 것이고, 이들 객체에 대해서 별도의 코드들을 작성할 필요가 없다는 것이다. 추상 클래스의 경우 인터페이스에 비해 조금 더 많은 것을 주긴 하지만 물려 받은 것에 비해 역시 더 중요한 것은 추상 클래스의 "타입"이다. 이 "타입" 이라는 외부적인 관점을 이용해서 인터페이스와 같은 위력을 발휘할 수 있다. 덤으로 내부적 관점에서의 중복 코드도 줄일 수 있다는 장점과 함께.

타입이 같다는 것이 주는 또 하나의 장점은 적절한 시기에 기존의 객체 대신 실질적으로는 다른 객체로 대체시킬 수 있다는 점이다. 이것은 마치 컴퓨터라는 하드웨어에 내부 소프트웨어만 바꿔 실행하면 여러 기능을 하는 범용 컴퓨터와 유사한 개념이다. 이것은 구조적으로 동일하게 구현된 코드 상에서 서로 다른 로직을 구현한 객체들을 바꾸어 가면서 사용함으로써 소스 코드의 양을 줄이면서도 다양한 기능을 수행하게 만들 수 있다는 말이다. 또한 기능의 확장을 위해서 다른 코드를 수정하지 않고 동일한 "타입"의 새로운 객체 하나만 만들어 넣으면 된다. 이것은 수정이나 기능의 확장을 위해서도 도움이 된다는 말이다. 

만약 상속을 통해 외부적 관점의 통일성, 즉 "타입"을 상속 받지 못하고 단순히 속성과 기능만을 상속할 수 있는 것이었다면 이러한 이점은 생각지도 못할 일이다. 아무리 속성과 기능을 동일한 클래스로부터 상속 받았다 해도 하위 클래스들은 서로 엄연히 다른 관점으로 봐야 했을 것이고, 그렇다면 어떤 방법으로도 이들을 다루는 코드들을 통합 시킬 수 없었을 것이다. 그리고 기존의 객체를 새로운 객체로 간단히 교체한다는 것은 상상하기도 힘들었을 것이다. 상속은, 특히 "타입"의 상속은 이처럼 위대한 개념이다.

혹시 이러한 개념을 잘 생각하지 않고 있었던 분들이라면 이 타입 상속이라는 개념을 염두해 두고 어떻게 하면 동일한 외부 관점을 유지시킬 수 있을 것인지 항상 생각하면서 프로그래밍을 했으면 좋겠다. 그것이 개발자로서의 수명(신체적인 수명까지도;)을 길게 가져가는 길이기도 하니까 말이다.