마르크스와 함께 객체지향을

그냥 재미로 소설처럼 프로그래밍 분석 설계 과정을 현업의 분위기를 버무리면서 써보았습니다. 사실 객체지향에 대한 글도 많고 개념도 잘 안내되었으니 제가 뭘 보탤까요. 그냥 이렇게 소설처럼 하면 재밌지 않을까 싶어 써보았네요.

발단

"아. 현 차장님."

영업팀의 정 대리가 갑작스레 부르는 소리에 현정경 차장은 아랑곳하지 않고 키보드를 두드리고 있었다.

"저기 현 차장님..?"

"네. 듣고 있으니 말씀하세요. 지금 바빠서 그렇습니다."

"아 그러면 조금 있다가 들리겠습니다."

"아닙니다. 지금 말씀하시죠."

뭐야 이 인간. 궁금한 건 못배기는 그런 스타일인가 하며 영업팀 정 대리는 속으로 투덜거렸다. 하지만 이번에 따온 사업을 밀어붙이려면 이 사람이 필요하기에 지금 느낀 치사해지는 기분은 뒤에 풀어보도록 하자(?)고 다짐했다. 정 대리는 이내 입을 열었다.

"아 이번에 까다로운 사업을 맡았는데, 이건 현 차장님이 딱!인 것 같아서요.'

"뭔데요?"

요구사항 분석

아. 그러냐. 그래서 내가 맡은 거냐?

"안녕하세요. 이번에 프로젝트 책임을 맡게 된 마르크스입니다. 이쪽은 투자자이신 프리드리히 앵겔스죠. 그리고 이쪽은 진행상황을 점검하고 커뮤니케이션 할 창구역할을 할 예니입니다."

"반갑SO."

"반가워요."

당분간 정적이 흘렀다.

"네. 고객님. 요구사항을 분석하기 위해 회의 일정을 잡아야 합니다만."

"요구사항이라면 여기에 정리해두었SO."

와. 이렇게 고객 쪽에서 요구사항을 잘 정리하는 경우는 없는데 하면서 좋아하는 현 차장. 앵겔스는 그에게 몇 장의 페이퍼를 전달한다. 앞 표지는 이렇게 쓰여있었다.

[서문, 1859]^[각주:1]

거기에 붙어있는 포스트잇

"그런데... 이 포스트잇에 휘갈기신(?) 글이 뭐라고 썼는 지 도통 알아듣기 어렵네요."

"음. 나도 무슨 말인지 모르겠네.(긁적긁적)"

"나DO.."

뭐야. 네가 썼잖아 악필러 이 멍청아! 그러다 옆에서 잠자코 보고 있던 예니가 끼어들었다.

"이 페이퍼를 객체지향 코드로 작성하시오. 라고 써있네요,"

쑥쓰러운 듯 아하하 웃는 마르크스 무슨 소린지 못알아들은 앵겔스 천진난만하게 웃는 예니 그리고 그 앞에서 망연자실해하는 개발자인 나. 이렇게 지옥이 시작되었다. 살려줘..

팀 결성

회사에서는 PM(Project Manager, 프로젝트 책임자)으로 코헨 부장. PL(Project Reader, 개발 팀장)로 나 그리고 개발자로 라이트 사원을 붙여주었다. 코드 하나 짜는 것 가지고 사람이 이렇게 많을 필요는 없을 것 같지만 뭐 어쨌든 회사는 코헨 부장이 아마도 한 달 후에 다른 프로젝트에 들어가야 할 것 같은데 놀게는 내버려둘 수는 없으니 일단 수준이 얉은 이번 프로젝트의 관리자로 자리에 앉혀두었다.

"현정경 차장. 자네만 믿네. 그래서 이 프로젝트 PM을 하겠다고 한 거라고."

라고 회의 자리에서 한마디 툭 던져놓은 후 법인카드도 역시 툭 던진 후(아아 법인카드라면 얼굴에 던지셔도 좋다구요!) 바로 회의실을 빠져나갔다. 바로 바깥에서 어이. 이 과장. 커피나 먹으러 갈까. 다음 프로젝트에 대해 얘기 좀 나누지~ 하는 정다운 코헨 부장의 목소리가 들려왔다. 아무래도 이새끼 분석 설계만 하고 빠져나갈 각이잖아. 사실상 내가 PM/PL 다 하게 생겼네. 미친. 부담력 5623941231924이라구..

"라이트 사원. 아무 생각 말고 내 지시만 잘 따라줘요. 오늘 부장님이 법인카드도 주셨으니 맛있는 거나 먹으러 가자구요."

"네! 알겠습니다!"

아아 역시 사원이다! 젊은 에너지가 느껴져서 나도 힘이 난다!

띠로롱 띠롱 띠리리로롱

"여보세요. 아 네네. 아 고쳐놓겠습니다!"

라고 라이트 사원은 전화기에 대고 말한 후 끊었다. 뭐지? 아마도 이전 프로젝트 관련 이슈가 생겼나. 미친...

"어라. 저번 프로젝트 끝난 거 아니었나요?"

"모르겠습니다. 해야 한다고 하는데요..."

"그 프로젝트는 완료보고 후 철수한 건데? 유지보수 담당 정해졌을 텐데요? 담당이 누구죠?"

그래서 찾아갔습니다!

"안녕하세요. 강 대리님."

"옛씁니다?"

"저번 프로젝트 그거 끝나서 다 철수하고 무상 유지보수 중인 거잖아요? 왜 우리 라이트 사원한테 그 프로젝트 수정 관련 일을 또 시키는 거죠?"

"그거 제가 개발한 게 아니지 말입니다. 라이트 사원이 개발한 거니까 개가 잘 알지 말입니다. 더 빨리 대응할 거지 말입니다."

"저기.. 사원이 뭔 어려운 걸 했겠어요.. 강 대리라면 금방 분석해서 할 수 있을 거 아닌가요?"

"아니지 말입니다. 그거 PDA 프로그램을 개발한 거라 제가 그거 또 개발환경 셋팅도 해야 하고 관련 개발 툴도 설치하고 귀찮아져서 말입니다. 무엇보다 고객이 지금 급하게 요청한 지급건이지 말입니다."

"아니.. 지급 건인 건 알겠는데 지금 저랑 라이트 사원이 프로젝트를 시작했는데 다른 일을 시키면 어쩌란 말예요.. 어차피 환경 셋팅 하실 거 고객에게 늦어질 거 같다고 안내하세요."

"안되지 말입니다. 기술 이사님과 고객사 책임자까지 일정이 다 보고된 내용이라 물릴 수가 없지 말입니다."

그래서 찾아갔습니다!

"안돼. 일단 라이트 사원은 일단 그 일 시키게. 어디까지나 사원 급이라 큰 도움은 안될텐데?"

"그래도 저랑 함께 스타트! 하면 계속 그것만 시킬 수 있도록 분위기가 있어야 저도 예상을 해가며 일을 할 거란 말이죠? 하는 중에 다른 일 시키시면 집중도 안 되고요."

"그런 이유는 부차적인 거 같네."

아아.. 정치를 너무 모르는 내가 밉다... 좀 더 논리를 준비하고 왔어야 했건만..

"강 대리 시키면 개발환경 셋팅 때문에 하루를 날려먹는다고 하더군. 그래서 현재로써는 라이트 사원을 시키는 편이 빠르다고 하니 그럴 수밖에 없잖은가?"

결국 권력에 졌습니다!

요구사항 정리

이렇게 분석/설계 와꾸 잡는 것은 나 혼자 맡게 되었다. 뭔가 같이 이야기 하면서 하는 편이 더 좋은데.. 어쩔 수 없지.

그래도 PM인 코헨 부장은 고객의 요구사항을 아주 간단히 요약하여 정리해주었다. 고객과도 이미 회의를 한 번 했고 요약에 대해 예니는 마르크스가 긍정했다고 피드백을 주었다. 그래. 요구사항이 요약된 걸 어디 한 번 볼까나.

1. [...] 생산관계는 [...] 물질적 생산력의 일정한 발전단계에 상응한다.

2. 생산력발전의 특정 단계에서, 사회의 물질적 생산력은 그것들이 지금까지 작동해온 [...] 현존하는 생산관계와 갈등상태에 들어간다.

3. 생산력발전의 형태라는 측면에서, 이들 관계는 생산력 발전에 족쇄로 전환한다.

4. 그때 [경제구조의 변화를 초래하는] 사회혁명의 시대가 시작된다.

5. 어떠한 사회구성체도 그 속에서 발전할 수 있는 모든 생산력이 모두 다 발전하기 전까지는 결코 소멸하지 않는다. ...

6. ... 좀 더 높은 단계의 새로운 생산관계는 그것의 물질적 존재조건이 종래의 사회 그 자체의 태내에서 성숙되기 이전에는 결코 출현하지 않는다.

^{[각주:2]
[각주:3]}

아주 훌륭한 요약본이다. 그러면 어디 와꾸를 잡아보자.

분석/설계

우선 가장 기본이 되는 생산에 대해 정의해보자. 이로부터 생산력과 생산관계로 분할되기 때문에 아래와 같이 정의하는 것이다.

public abstract class Production
{

}

그리고 생산력과 생산관계 클래스를 만든다. 단, 생산을 모두 상속하게 한다.

public abstract class RelationsOfProduction : Production
{
    public abstract void ProductMaximum();
}

public abstract class ProductiveForces : Production
{
    private LevelOfProduction _level;
    public LevelOfProduction Level
    {
        get { return _level; }
    }
    public delegate void R_LevelUp();
    public abstract void LevelUp();
}

생산관계는 물질적 생산력 발전 수준에 상응한다. 때문에 생산력은 Level이라는 정보가 있다. 여기서 LevelOfProduction 이라는 클래스의 내용을 보자.

public class LevelOfProduction
{
    public enum Relation 
    {
    	PrimitiveCommunism, 
        Slavery, 
        Feudalism, 
        Capitalism, 
        Socialism, 
        Communism 
	};
}

이는 열거형 멤버변수로 이루어져있는데, 원시공산주의(), 고대 노예제, 중세 봉건제, 자본주의, 사회주의, 공산주의로 이루어져있으며 생산력이 높아질수록 그에 상응하는 생산관계를 나타내므로 열거형으로 구현하였다.

여기서 ProductiveForces 클래스에서 delegate로 만든 R_LevelUp()이 있는 이유는 사실 이렇다. 생산력을 발전시키는 것은 분명 생산영역에서 이루어지지만 실상 여러 경로를 통해 발전할 가능성이 있다. 예컨대 요구사항 5번에 "어떠한 사회구성체도 그 속에서 발전할 수 있는 모든 생산력이 모두 다 발전하기 전까지는 결코 소멸하지 않는다. ... "라는 문장을 생각해보자. 생산관계는 분명 생산력을 발전시키는 데에 그 당시의 생산력 발전수준에 합당한 생산관계임을 시사한다. 그럼에도 불구하고 생산력은 결국 생산영역에서 변해야 하기 때문에 대리자인 delegate를 만들어 생산관계에서 생산력 수준의 가능한 최대 발전을 '유인한다'는 관계를 시사하고자 하였다.

그런데 이렇게 어떤 역할도 하지 않는 추상클래스(abstract, virtual)를 만드는 이유는 관계를 나타내기 위함이 크다. 어떤 구체적인 역할을 하지는 않지만 이게 어디와 관계가 있는가에 대해 말해주기 때문에 쓴 것이다.

그리고 클래스를 상속 시키는 관계 역시 생각해보자. 이는 사실 "재사용성"과 관련이 있지만 이는 또 코드 수정에 따른 문제를 해결하려는 것과 관련이 깊다. 설계 때는 분명히 생산에서 생산력과 생산관계만이 존재한다고 생각할지 모른다. 그래서 그냥 별 생각없이 아래와 같이 짰다고 생각해보자.

public class Production
{
    private RelationsOfProduction _relationsOfProduction;
    private ProductiveForces _productiveForces;
}

그런데 어느 순간 뜬금없이 생산지배력이라는 개념이 새로 등장했다고 생각해보자. 그래서 저기에다 멤버 변수를 새로 추가해서 수정하면 될 것 같지 않은가? 이런 경우는 문제가 없을 지도 모르지만 예컨대 생산관계가 이제 쓸모없는 개념이 되어서 사라지게 되었다고 생각해보자. 그러면 저 Production 클래스의 멤버변수인 _relationsOfProduction을 삭제할 것인가? 또는 저걸 약간 수정해야 할 일이 발생하면 어떨까?

그러면 이제 이걸 참조하거나 상속하고 있는 클래스들까지 모두 수정해야 하는 번거로운 일이 발생하게 된다. 예컨대 해당 모듈만 손을 대는 패키지팀 입장에서는 와~ 컴파일러 오류가 안나네ㅋ 소스 올렸당ㅋ 했는데 그 모듈을 가지고 개발하고 있던 사람들은 컴파일러 오류가 뻐버버벙 터져서 패키지팀에 항의하러 오는 참변이 벌어진다(?)

그렇기 때문에 상위와 하위로 구체적인 코드를 내려보내도록 만들고 필요한 경우가 있으면 수정보다는 새로운 class를 만들어서 추가해버리는 것이 훨씬 이득이다. 그러면 오류도 안나고 적절한 수정은 하위 단에서 그 클래스를 참조하도록 수정을 유도하는 것이다.

이제 계급을 정의해보자.

public abstract class Class
{
  
}

계급 자체는 그냥 구조에 불과하지만 고유의 기능을 갖는다. 바로 착취다. 하지만 착취는 계급이라는 추상적인 개념에서 이루어지는 것은 아니다. 착취는 다양한 생산관계에 따라 그 내용이 달라진다. 이런 점을 생각해보건데 Class 클래스의 멤버로 캡슐화하기보다는 interface로 구현하여 각 사회구성체마다 이를 구현하도록 하는 것이 어떨까 한다. 우선 Exploite를 interface로 구현해보자.

interface Exploite
{
    void Exploite();
}

이제 사회구성체(Social Formation)라는 상위 클래스를 만들고 각 사회구성체 별로 이를 상속하는 구조로 만들자.

public abstract class SocialFormation
{

}

이 사회구성체 클래스와 착취 interface를 상속하는 구조로 만드는 거다. 참고로 C#은 다중상속을 원칙적으로 금지하고 있으나 interface는 다중상속이 가능하다!

class PrimitiveCommunism : Class, Exploite
{
    public void Exploite()
    {

    }
}
class Feudalism : Class, Exploite
{

    public void Exploite()
    {

    }
}
class Slavery : Class, Exploite
{
    public void Exploite()
    {

    }
}
class Capitalism : Class, Exploite
{
    public void Exploite()
    {

    }
}

이러한 작업으로부터 다음과 같은 클래스 다이어그램을 만들어주면 전체적인 그림을 그릴 수 있게 된다.

클래스 다이어그램

분석/설계는 이 정도 수준만 해주면 끝나는 거다. 나머지 구체적인 구현은 우리의 라이트 사원에게 모두 맡겨놓고 나는 코나 풀고 쿼리나 때리면서 놀면 되는 겁니다(?)

결론

고객 쪽 책임자인 마르크스와 투자자 앵겔스는 만족했을까나? 글쎄 잘 모르겠다. 우리의 사원만 열심히 해준다면야 만족했겠지?

뭔가 현업에서 분석/설계하는 분위기를 조금은 참고가 되셨을지 모르겠군요. 뭐 그냥 크게 일하고 싶지는 않아서 이정도만 하고 멈추려 합니다;; 일하는 것 같아서 넘모 싫네요;; 글은 여기서 마칩니다. 해당 소스는 GitHub에 올려두었습니다.

[이관 글. 2019-07-19 작성]

1. Marx, K. (1859). Preface to a Contribution to the Critique of Political Economy. The Marx-Engels Reader, 2, 3-6. [본문으로]
2. Cohen, G. A. (2000). Karl Marx's theory of history: a defence. Oxford: Clarendon Press. [국역본] 카를 마르크스의 역사이론 - 역사유물론 옹호. 박형신, 정헌주 옮김. p256. [본문으로]
3. 대괄호 []와 ...은 모두 국역본에서 저작자가 직접 인용한 문구의 표현을 그대로 가져왔다. [본문으로]