본문 바로가기

짧게 쓰기/칼럼

객체지향 글쓰기 (글쓰기 프로그래밍이 가능할까?)

프로그램 개발자가 가장 싫어하는 일중 하나는 무엇일까? 문서 작성이다. 나도 문서 작성을 밤새 야근 하는 것처럼 싫어한다.

그런데 개발자들이 문서 작성을 싫어하는 결정적인 이유는 아마도 개발자 문서 작성이 노가다성이기 때문일 것이다. 화면 캡춰나 기능에 대한 가이드 라인 설명 문구는 지극히 단순 작업으로 개발자를 지치게 하는 요소 중의 하나이다.

그리고 개발자와 글쓰기라는 단어 자체가 북극과 남극처럼 멀리 떨어진 이미지로 느껴진다. 개발자 중 글쓰기를 좋아하는 사람은 많지 않다. 이유는 아마도 프로그램 개발은 이공계 영역이고 글쓰기는 인문계 영역이라는 극단의 차이가 이 둘은 별개의 사고영역이라 생각하면서 내가 잘하기 힘들고, 내가 싫어하는 영역이라고 처음부터 단정짓는 것이 아닐까 싶다.

그러나 개발자인 나는 글쓰기를 좋아한다. 정확하게 말해서 글쓰기를 잘하는게 아니고 다만 좋아한다. 내가 글쓰기를 좋아하는 이유는 ‘복잡하게 얽힌 내 생각을 깔끔하게 정리’ 하는 글쓰기 효과가 재미있기 때문도 있지만 글쓰기를 할 때 프로그래밍을 하듯 쓰기 때문에 프로그래밍으로 단련된 내 능력과 프로그래밍을 통해 얻는 재미가 글쓰기에서도 그대로 살아있기 때문이다.

프로그래밍과 관련하여 여러 가지 프로그래밍 방식이 있지만 내가 주로 하는 것은 '객체지향' 프로그래밍이다. 이것 역시 정확하게 말해서 객체지향을 잘하는게 아니고 다만 자연스럽게 적용하기 위해 노력하고 있다.

나는 글쓰기를 프로그래밍 하는 마음으로 쓰긴 하는데 한번 제대로 적용하고 싶어졌다. 엉뚱하지만 창의적인 시도가 아닌가. 남과 다른 창의적인 길만이 살길이다. 살길이라 하니 갑자기 비장해졌고 엉뚱하지만 글쓰기를 프로그래밍, 그 중 객체지향 프로그래밍과 비교하고 적용하고 싶어졌다.


+ 그렇다면 객체지향 프로그래밍이란 무엇인가


일단 객체란 무엇인가? 객체의 사전적인 정의는

‘객체 지향 프로그래밍이나 설계에서, 데이터(실체)와 그 데이터에 관련되는 동작(절차, 방법, 기능)을 모두 포함한 개념. 예를 들어 기차역에서의 승차권 발매를 생각할 때, 실체인 ‘손님’과 동작인 ‘승차권 주문’은 하나의 객체이다. 실체인 ‘역무원’과 동작인 ‘승차권 발매’도 하나의 객체이다.’

그리고 객체지향 프로그래밍의 사전적인 정의는

'독립적인 각각의 객체로 프로그램이나 시스템을 구성하는 일.’

그렇다면, 내가 생각하는 객체지향 프로그래밍은

‘독립적인 각각의 객체를 이용, 각 기능간의 의존성은 줄이고 내부 기능을 강화하는 식으로 프로그램이나 시스템을 구성하여, 개발을 깔끔하게 진행할 수 있고 편하게 유지보수 할 수 있고 기능을 쉽게 확장할 수 있는 품질 좋은 S/W를 지향하는 개발 기법이다’

혹시 이해가 안된다면 (아마도..^ ^;) 한마디로

객체지향 프로그래밍으로 품질 좋은 S/W 개발을 지향한다는 것이라고만 이해해도 좋을 것 같다.


+ 객체지향의 어떤 요소가 품질 좋은 S/W 개발을 가능하게 하는가

- 일단 어떤 종류의 프로그래밍 개발 방식에도 적용되는 대원리 2가지

1. 낮은 결합도, 높은 응집도(Low Coupling, High Cohession)
각 기능간의 의존성은 줄이고 내부 기능을 강화하는 소프트웨어 공학의 전통 이론

2. OAOO(Once And Only Once)
 하나의 코드가 다른 부분에 존재해서는 안 된다는 뜻이다. 왜냐면 만약 똑 같은 코드가 여러 군데 존재하면 그들 중의 어떤 것은 시간이 흘러갈수록 구식이 될 것이다.

- 객체지향의 기본 요소

1. 유일성과 책임
객체는 하나의 기능/책임만을 수행해야 하며 그 기능/책임은 모든 객체중에 오직 자기만 수행해야 한다.
-> 코드의 중복 없는 깔끔한 개발 및 관리 가능

2. 캡슐화와 정보은닉
캡슐화는 관련있는 여러 정보들을 어떤 틀안에 담는 것이다. 정보은닉은 외부에 필요 없는 정보들을 노출시키지 않고 숨기는 것이다.
-> 객체간의 의존성을 줄여주고(결합도) 내부 기능성을 강화한다. (응집성)

3. 상속과 폴리모피즘
객체간 모계 구조의 계층도를 만들어서 자식이 부모 객체의 기능을 재사용할 있고, 해당 계층도의 부모 객체를 대표로 선언하고 자식을 부모 객체처럼 각 기능간에 주고 받으면서 재사용성과 유연성을 향상시킬 수 있다.

- 위의 두가지 요소를 발전시킨 3가지 요소

1. ORR (One Responsibility Rule)
객체는 한가지 종류의 책임만을 다음과 같이 수행해야만 한다.
a. 그 책임에 해당하는 일을 빠짐없이 모두 해야 한다.
b. 그 일을 다른 객체보다 더 잘 할 수 있어야 한다.
c. 그 일을 자신만이 유일하게 한다.

2. OCP (Open Closed Principle)
한번 만들어진 객체는 기능을 확장할 수는 있지만 수정해서는 안 된다. 수정을 하게 되면 관련된 다른 객체까지도 영향을 받는다. 확장을 하는 방법은 상속이나 폴리모피즘을 통해 이루어진다.

3. LoD (Law of Demeter)
객체의 메소드(동작)은 다음 객체들의 메소드만 호출해야 한다. 는 정의로 낮은 결합도와 관계 있는데 글쓰기와 관계가 거의 없으므로 나머지 설명은 생략한다.

* 참고 : 객체지향 방법론 설명 출처는 '디자인 패턴과 리팩토링' 책에서 발췌



사용자 삽입 이미지
[객체지향 설계를 하고 있는 전문가의 모습 -
4년전 프로그래머로 취직을 위해 자바로 홈페이지를 만든적이 있는데 그때 홈페이지 타이틀 이미지가 이 그림이었다. 지금 봐도 멋있다.



+ 이제 객체지향 요소를 글쓰기에 대입하여 보자.


1. 객체지향 구성 요소의 글쓰기 적용

객체는 하나의 단락

필드(속성, 데이터)는 글의 주제 및 주제와 관련된 재료

메소드(동작, 함수)는 하나의 문단

객체 간의 연결은 ‘그러나, 그래서, 그런데’ 등의 접속사

2. 객체지향 방법론의 글쓰기 적용

- 일단 어떤 종류의 프로그래밍 개발 방식에도 적용되는 대원리 2가지

1. 낮은 결합도, 높은 응집도(Low Coupling, High Cohession)
글의 각 단락간에 잦은 수식어, 접속사, 내용 중복 등으로 지저분하게 연결되면 안되며, 각 단락은 고유의 주제와 목표를 담고 있어야 한다.

2. OAOO(Once And Only Once)
하나의 주제를 담은 단락이 다른 부분에 존재해서는 안 된다는 뜻이다. 왜냐면 만약 비슷한 내용이 여러 군데 존재하면 독자들이 식상해 하고 지저분하게 보일것이며 각 단락의 존재 여부가 희미하게 된다.

- 객체지향의 기본 요소

1. 유일성과 책임
글의 단락은 하나의 주제/목표만을 수행해야 하며 그 주제/목표는 모든 단락중에 오직 자기만 담고 있어야 한다.
-> 깔끔한 글 작성 가능

2. 캡슐화와 정보은닉
..내가 생각할 때 글쓰기에 적용은 쉽지 않음..

3. 상속과 폴리모피즘
..내가 생각할 때 글쓰기에 적용은 쉽지 않음..

- 위의 두가지 요소를 발전시킨 3가지 요소

ORR (One Responsibility Rule)
글의 단락은 한가지 종류의 주제/목표만을 다음과 같이 수행해야만 한다.
1. 그 주제에 해당하는 내용과 주장을 빠짐없이 모두 해야 한다.
2. 그 주제의 논증을 다른 단락보다 더 잘 할 수 있어야 한다.
3. 그 주제/목표를 자신만이 유일하게 한다.

OCP (Open Closed Principle)
..내가 생각할 때 글쓰기에 적용은 쉽지 않음..

LoD (Law of Demeter)
..내가 생각할 때 글쓰기에 적용은 쉽지 않음..

- 그렇다면 결론은

1. ORR (One Responsibility Rule)
글의 단락은 한가지 종류의 주제/목표만을 다음과 같이 수행해야만 한다.
a. 그 주제에 해당하는 내용과 주장을 빠짐없이 모두 기술해야 한다.
b. 그 주제의 논증을 다른 단락/문단 보다 더 잘 할 수 있어야 한다.
c. 그 주제/목표를 자신만이 유일하게 한다.

이것 하나로 정리하여 글쓰기에 비슷하게 적용될 수 있겠다.

2. 그런데 추가 할만한 객체지향 프로그래밍 요소가 하나 더 있다.

“구현이 아닌 인터페이스에 맞춰서 프로그래밍 하라”

라는 객체지향 개발 조언이 있다.

인터페이스가 객체지향 개발 관점에서 여러 의미가 있지만 글쓰기에 적용할만한, 내가 생각하는 인터페이스는 기능의 내부 구현 로직을 어떻게 머리 써서 짜볼 것인가를 고민하는게 아니라, 전체적인 관점에서 어떤 기능들이 있어야 되고 그 기능들은 어떻게 그룹 지어지고 연결되는지를 고민하는 것이라고 이해했다.

한마디로 나무가 아니고 숲을 봐라, 이 조언을 글쓰기에 적용하면

“내용이 아닌 주제에 맞춰서 글을 써라”

라고 정리할 수 있겠다. 내가 지금 쓰고자 하는 글을 통해 전달하고자 하는 주제/목표, 각 단락, 문단별로 전달하고자 하는 주제 및 얻고자 하는 목표에 우선 신경을 써야 된다는 조언이다.

+ 객체지향 고급 기술을 글쓰기에 적용해 보자.

1. TDD(Test Driven Development) 테스트 주도 개발
-> 글쓰기로 바꾸면 ‘주제 주도 글쓰기’

보통 프로그램을 짤 때 내 마음대로 코드를 만들고 그 다음에 대충 테스트 하는 방식이 일반적인데, TDD는 테스트 코드를 먼저 만들고 이 테스트 코드를 통과하는 실제 코드를 나중에 만드는 개념으로 이 개발 방식을 추구하면,

‘구현이 아닌 인터페이스에 맞춘 개발’이 가능한 효과가 있다.

이 방식을 글쓰기에 도입하면 그냥 생각나는대로 글쓰는게 아니라 각 단락, 문단별 ‘주제’를우선 생각하고 내용을 쓴 다음,

그 내용이 내가 원하는 ‘주제’와 일치하는지 확인하는 새로운 개념이 될 것이다. 다음 포스팅에서는 TDD 방식을 이용한 글쓰기를 실제로 실험해 볼 예정이다.

2. 리팩토링(Refactoring)

리팩토링이란, 기능은 그대로인 상태에서 내부 소스만 유지보수와 확장성 높은 질높은 코드로 개선하는 작업인데 이 기술을 글쓰기에 대입하면 한마디로,

‘고쳐쓰기’ 가 될 것이다.

글을 잘쓰는 방법으로 지속적인 ‘고쳐쓰기’를 얘기하고 있다. 객체도 중복, 뚱뚱, 홀쭉한 놈들이 있듯이 글에도 중복되고, 지나치게 수식어 갔다 쓰거나, 지나치게 빈약한 단락이 있다. 저런 단락을 다듬기 위해 리팩토링 식으로 ‘고쳐쓰기’를 한다면 더욱 매끄러운 글쓰기가 될 것이다.

다음 포스팅에서는 리팩토링을 실제로 실험한 글쓰기를 포스팅 할 예정이다.

3. 디자인 패턴(Design Pattern)

내가 생각하는 디자인 패턴은 정형화된 객체지향적 문제 해결 기법이라 이해하면 될 것 같다. 글쓰기에도 독자들의 호응을 불러일으키는 정형화된 패턴이 있는 것 같다.

그 패턴이 있다는 것을 느끼기는 하는데 딱히 꼬집어 정리하기는 쉽지 않을 것 같다. 글쓰기 디자인 패턴도 한번 시도해볼 예정이다.


+ 글쓰기에 프로그래밍 기법을 적용하여 내가(우리가) 얻고 싶은 것은 무엇인가.

블로그를 오래 하면서 뿌듯한 성과도 얻고 싶다면 글쓰기 실력 향상이 계속 되야 하는데, 이런 밑바닥 기초를 쌓는 것이 글쓰기 능력 향상에 도움이 많이 될 것이다.

그리고 무엇을 하더라도 내 본업인 프로그래밍을 잊지 않고 생각하며 적용하고 싶다.

요즘 글쓰기는 블로그 덕분에 많이 하는 대신, 프로그래밍은 회사 업무외에는 실습 및 공부를 많이 하지 못하고 있다. 일단 프로그래밍 지향 사고를 무엇을 하더라도 계속 이어갔으면 하는 바램이다.

글쓰기는 인문계이고 프로그래밍은 이공계지만 둘 다 문제 해결을 하고, 무에서 유를 창조하고, 논리 적이어야 하고, 각 세부 구성요소들이 서로 비슷함을 많이 느끼고 있다.

엉뚱하지만 창의적인 시도라고 생각하며, 그래서

주제는 중복되지 않고 하나의 구성요소에만 담겨야 하며, 내용보다 주제에 집중하는 객체지향 글쓰기,

다시 말해 '주제지향 글쓰기' 를 실천할 것이다.


Daum 블로거뉴스에서 이 포스트를 추천해주세요. [추천]

올블로그 추천은 http://link.allblog.net/6789207/http://mckdh.net/179 입니다.