단순함은 일 처리 방법이 아니라 일을 대하는 마음가짐

감히 시도하는 설계의 정석

by 안영회 습작

개발 관련 책으로는 최근에 가장 기대했던 두 권의 책을 증정 받았습니다.

그중에서 먼저 손이 간 책은 이민석 교수님이 번역한 <미니멀리즘 프로그래머>입니다.


더 복잡해지도록 그대로 두지 말고 정리된 상태로 만들라

책을 펼쳤더니 머리말 격인 <이 책에 대하여>에서 이미 의미심장한 구절을 만납니다.

소프트웨어의 복합적인 면을 다루기 어렵지만, 그 안에는 분명한 규칙이 존재합니다. 하지만 그 규칙을 무시하면 '복잡함'이 찾아옵니다. 그리고 이 복잡함은 우리의 프로젝트를 이해할 수도, 예측할 수도 없는 엉킨 논리 덩어리로 만들어 버립니다. <중략> 복잡함을 다루는 일은 규칙도 모른 채 게임을 하는 것과 같습니다. 더 심각한 문제는 이 규칙은 애초에 알 수 없다는 점입니다.

언젠가 영어 단어인 complex와 complicated의 차이를 명확히 알고자 시도했던 기억이 어슴푸레하게 남아 있습니다. 인용한 구절은 마치 그 기억을 꺼내서 다시 생각하게 유도하는 듯합니다. 그리고, 프로그래머만 이해할 수 있는 말들이긴 하지만, 제법 명확한 기준 제시입니다.


인공지능 삼총사[1]에게 둘의 차이를 물었더니 제미나이와 클로드가 준 결과에서 다음 내용이 마음에 듭니다.


복잡한 클래스를 엮어서 단순한 복합체를 만드는 일

두 개념에 대하여 이전에 제가 썼던 글도 찾아보았습니다. 이미 두 개념을 비교해서 쓴 글 제목도 보입니다. <복잡한 클래스를 엮어서 단순한 복합체를 만드는 OCP>인데요. 다음 그림을 그리면서 프레임워크의 쓸모(價値)를 '복잡한 클래스를 엮어서 단순한 복합체를 만드는 일'로 규정했습니다.


복잡함을 다스리기 위해 인터페이스를 도입하다

계속해서 해당 글의 '재사용 컴포넌트의 상호작용은 인터페이스를 통해서'로 이름 붙인 구절을 보면 복잡함을 다스리기 위해 인터페이스를 도입한 것을 컴포넌트를 적용한 것으로 해석했습니다. 컴포넌트가 일종의 박스나 컨테이너로 작동한 것이고, 컴포넌트가 통용되기 위한 규칙으로 인터페이스가 도입됩니다.[2]

최근에 물류 관련 설계를 하고 있는 탓에 관련 비유가 떠오릅니다. 컴포넌트를 만드는 일은 물류 효율화를 위해 패키지나 팔레트, 컨테이너 따위를 도입하는 것과 이치가 같고 그렇게 할 경우 '식별' 기호(記號)로 바코드나 QR 코드가 쓰이는 것과 거의 비슷한 이치라고 할 수 있습니다


원하는 것만 노출하는 인터페이스 기반 프로그래밍

그 글을 계속 읽다 보면 앞선 두 가지 내용이 모두 OCP의 예시라는 저의 주장을 만납니다. 제가 쓴 것이지만 거의 일 년이 다 지나서 기억이 분명하지 않네요.

그런데, 최근에 이 글 <추상과 수학과 기호 그리고 인터페이스>를 쓴 잔상으로 인해 OCP라는 말과 '원하는 것만 노출하는'이라는 표현이 거의 비슷한 말이란 사실을 발견합니다.

여기까지 쓰고 나서 유레카를 외치고 싶었습니다. 대략 2014년 이후로 '집적'[3]이라는 말에 담아 기억에 보관하던 어떤 느낌이 무엇인가 어렴풋하게 깨달은 듯했습니다. 다만, 지금 글로 쓰기엔 분명하지 않아 당장 설명하려는 조급함을 버리고 다시 책으로 돌아갑니다.


단순함을 추구하려면 사후 정리를 통해 배워라?

시간을 마련한다고요?

어떻게든 시간을 마련해야 합니다. 그렇지 않으면 배우고 개선할 수 없습니다. 단순함을 받아들이고 단순한 결과물을 만들 방법을 찾아야 합니다.

대번에 <켄트 벡의 Tidy First?>가 떠오릅니다. 두 거장이 각자 자신의 관점에서 비슷한 곳을 겨냥한 것일까요? '시간을 마련한다'는 저자의 말은 켄트 벡의 책을 번역하면서 익힌 느낌을 소환합니다. 아마도 NPV 개념 설명을 거쳐 기능 추가 없이 코드를 정리하는 일이 미래의 선택권을 늘려 준다는 사실을 배울 때 생긴 느낌과 기억일 것입니다.

켄트 벡의 책을 직접 번역하지 않았다면, 책을 읽었더라도 이 부분은 제대로 이해하고 넘어가지 않았을 가능성이 큰 부분이었죠.


아무튼, 복잡한 문제를 단순하게 하기 위해서는 정리를 해야 합니다.[4] 저자는 '단순함'이라는 아름다운 개념을 북극성 삼아 자신의 경험을 나누는 항해를 준비하는 듯합니다. 켄트 벡과 같은 가치를 지향했더라도 지표와 경험이 다르겠지만, 두 거장이 쓴 글에서 발견하는 묘한 공통점이 놀라움을 선사합니다.


데이비드 토머스의 글에서 켄트 벡의 사유를 만나다

책은 얇지만 거장의 글은 기대를 저버리지 않습니다. 고작 머리말 격인 네 쪽을 보고 만들어진 영감으로 글 한 편을 썼습니다. 이 글의 제목은 내용을 포용하기보다는 이 책에서 <켄트 벡의 Tidy First?>의 향기가 나는 것을 드러내려고 했습니다. 하지만, 너무나 멋진 문장이 있어서, 마음을 바꿉니다.[5]

단순함은 일을 처리하는 '방법'이라기보다는
일을 대하는 '마음가짐'에 더 가깝습니다.


주석

[1] 퍼플렉시티, 제미나이(무료), 클로드(무료)에게 인용한 구절을 복사한 후에 이렇게 프롬프트를 던졌습니다.

아래 글에서 '복잡함'은 complicated를 말하고 '복합적'은 complex를 번역한 것입니다. 한국말로는 모두 '복잡하다'인데, 아래 글의 맥락에서 complicated와 complex는 어떤 차이가 있을까요?

[2] 직전에 발행한 글인 <추상과 수학과 기호 그리고 인터페이스>의 표현을 빌면 컴포넌트 사이의 소통을 위한 기호(記號)라고도 할 수 있습니다.

[3] 심지어 뇌 과학 책을 읽다가 쓴 이글, <뇌 구성의 우아함을 음미하기>에도 흔적이 있군요.

[4] 반도체 회로와 같은 이치라고 언급하고 싶은 충동을 꾹 누릅니다.[5] 브런치 제목 글자 수 제약으로 실제 제목은 다시 수정합니다.


감히 시도하는 설계의 정석 연재

1. 옵션: 공동의 가치에 대한 믿음에 기초한 안내와 제안

2. 바보야 문제는 콘텐츠야

3. 빨래를 개다가 떠오른 식별성과 태그, 라벨

4. Perspective와 Viewpoint는 무엇인가?

5. 하나의 시스템을 보는 다양한 생각을 담는 조감도鳥瞰圖

6. 소프트웨어 조감도의 기초 재료는 기호, 작명, 구조

7. 플랫폼의 다면성과 다층적 처리 영역을 표현하기

8. 메뉴는 콘텐츠 노출과 그에 따른 사용자 트리거 도구이다

9. LLM의 Stateless 구현과 AI제품의 싱글톤

10. 모델링이 주는 핵심 가치에 대하여

11. 소프트웨어 설계에 대한 책을 왜 쓰려고 하는가?

12. 설계라는 묘한 활동, 드러나지 않는 결정 대상

13. 이슈화, 이름 붙이기 그리고 개념과 설계의 관계

14. 보이지 않는 것에 대한 의사결정을 위해 드러내기

15. 모호함이라는 적진을 단박에 제압하는 모델의 힘

16. 추상과 수학과 기호 그리고 인터페이스

keyword
작가의 이전글추상과 수학과 기호 그리고 인터페이스