brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Oct 31. 2023

후배 덕분에 한 번 더 생각하는 객체 지향

한국의 마틴 파울러가 되기

이 글은 아래 (두레이를 이용한) 대화가 주는 자극을 글로 풀어낸 것입니다.

머금다 혹은 지향

사실 황호성 님과 만남에 앞서 동료와의 대화가 있었습니다. 동료와 저는 최봉영 선생님을 알고 있던 탓에 <줏대와 잣대에 대해 새롭게 생각해 보기>를 쓰면서 제가 느낀 바를 공유할 수 있었죠. 1년 전과 2년 전에 쓴 글을 글 쓸 당시보다 지금의 제가 더 잘 이해한다는 역설적인 상황을 흥분하며 말했습니다. 그리고 말하는 가운데 깨달았습니다. 이럴 때 어울리는 개념이 '지향'이라는 사실을 말이죠. 그리고 박문호 박사님 영상에서 '학습과정에서 반드시 머금어야 한다'는 말을 들은 것이 떠올랐습니다.


다시 어제 대화 과정을 음미해 보니 '연금술사'의 문구가 떠올랐습니다. 그

래서 다시 브런치 글 검색을 했더니 <귀찮음 vs 정성 - 무엇이 빠졌을까?>를 클릭했고, 너무나도 익숙한 '정성'을 언급하는 역린 대사 혹은 중용 문구를 만났습니다.


소프트웨어는 현상을 물리적 세계에 대응시키는 기술

이번에는 호성님이 쓴 글을 살펴보겠습니다. 두 개의 구절이 눈에 띕니다. 하나는 호성님이 인용한 Alan Kay의 문구입니다.

it carries special ways of thinking about situations that in contrast with other knowledge and other ways of thinking critically boost our ability to understand our world. 다른 지식이나 다른 사고방식과는 대조적으로 상황에 대한 특별한 사고방식을 전달하여 세상을 이해하는 능력을 비판적으로 향상합니다.

문구 자체에 대한 이야기보다는 마침 제가 박문호 박사님의 영상에서 배우는 소프트웨어 대한 많은 영감과 어우러집니다.[1] 하지만, 이러한 영감을 제대로 활용하기 위해서는 현상적 세계와 물리적 세계가 일치하지 않는다는 사실을 정확하게 인지하고 양쪽을 오가는 사고가 필요한데, Alan Kay의 글을 이를 기반에 두고 글을 쓴 듯합니다.


사고는 프로그램 언어에 갇히지 말자

두 번째로 눈에 띄는 내용은 아래 문장입니다.

조영호 님은 객체지향의 사실과 오해에서 흔히 프로그래머들이 객체지향을 어렵게 느끼는 이유가 클래스로 보기 때문이라고 말하는데, 이를 극복하기 위해서 자유롭게 정의하고 합당한 은유를 표현하라고 말씀하십니다.

이 역시 박문호 박사님 영상에서 배운 바와 시너지를 내는 장면입니다. 저 역시 클래스 기반 사고에 굉장히 비판적이었습니다. 하지만, '왜 그렇게 할까?' 생각해 보면 자바 같은 언어들이 제공하는 틀에서부터 생각을 시작하는 이유일 수 있습니다. <집합론적 사고는 여러 가지를 동시에 해결하는 것이다>를 쓸 때, 그리고 <조건이 만들어 가는 지식의 경계>와 그 글에 뒤따른 페친님의 댓글 등을 보면 프로그래밍 언어의 유산 속에 클래스를 강제하는 힘들이 있습니다.

하지만, 프로그래밍 기술 이전에 현상에 대해 더욱 자유롭게 사고할수록 더 나은 집합 또는 클래스를 정의할 수 있습니다. 더 나은 집합이란 무엇일까요? 저는 <박문호 박사님의 집합론적 사고 설명이 주는 영감>에 있는 내용으로 설명을 대신할 수 있을 듯합니다.


인스턴스 이해와 바운더리 구현

프로그래밍 세계에서는 '인스턴스'라고 하는데요. 개성이나 개별적 상황에 대해 더 잘 이해하는 일이 선행해야 합니다.

집합론적 사고는 궁극적으로 내가 속해 있는 집합을 깨닫는 것이다.


그러한 사유를 통해 얻은 이해를 바탕으로 내가 정의하는 객체(혹은 프로그래밍 개체)에게도 든든한 바운더리를 부여합니다.

남을 탓할 필요가 없다. 내가 갇혀 있다는 것을 깨달으면 타인을 원망하지 않는다. 이게 자유입니다. 자유는 상대를 원망하지 않는 것입니다.

제가 아는 가장 세련된 바운더리 부여 방법론은 Kent Beck의 TDD입니다. 꼭 그것을 써야 한다고 주장하는 것은 아니고, 바운더리를 잘 만들기 위해 고민해야 한다는 말입니다. 마침 귀염둥이 일민 형이 페북에 쓴 글도 바운더리 구현에 대한 주제를 다루고 있네요. 프로그래머가 바운더리를 구현한다는 것은 이런 일상의 연속입니다.

그런 점에서는 좋은 프로그램은 무엇을 지향하던 일단 개발자의 지향은 필요한 듯합니다.


글을 쓰고 난 후에 후배님의 질문이 이어져 추가합니다.


주석

[1] 박문호 박사님을 통해 배우는 내용은 별도 글로 쓰고 있습니다.


지난 한국의 마틴 파울러가 되기 연재

1. 현실과 시스템의 불일치, 그리고 UX의 역할

2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기

3. Code Smells 비유와 기술 부채

4. 기술 부채를 Code Smell로 관리할 수 있는가?

5. 형상 구성단위로 TestCase 유용할까?

6. 설계 요소의 사분면

7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기

8. 즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기

9. 소프트웨어 설계에서 입자의 응용

10. 소프트웨어 설계에서 파동의 응용

11. 설계란 무엇인가 IV Part.1

12. 설계란 무엇인가 IV Part.2

13. 설계는 변화에 대한 준비인가?

14. 대상이 되는 사태의 주요 내용을 한 장에 담다

15. 스윔레인으로 경계와 상호작용 드러내기

16. 짝 프로그래밍처럼 함께 설계하기

17. 짝 모델링으로 탄생한 상태도 초안

18. 동료의 상태도를 검토하기

19. 분산 환경 무결성 문제와 상태도 연결하기

작가의 이전글 지식 근로자의 생산성을 어떻게 끌어올릴 것인가(上)
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari