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

감히 시도하는 설계의 정석

11시간전

초등학교[1] 다니는 아이가 수학 문제집을 풀다가 질문을 해 왔습니다. 연거푸 거기에 답을 하는 과정에서 저도 모르게 아이에게 추상(抽象)이라는 말을 하면서, 아이에게 말하지 않은 생각을 여기 담습니다.

목표를 제외한 나머지 질적 특성을 제거하는 수학

검색해 보니 이미 2024년 비슷한 글을 썼습니다. <다시 배우는 수학과 추상 그리고 추상화 수준>인데요. 지금 보니 그 글을 쓴 바탕에도 수학이 있었습니다. 이번에는 아래 보이는 아이의 수학 문제에서 출발했습니다.

반복해서 보이는 '수'가 여기서는 추상抽象이 겨냥하는 목표 자체가 된다고 하겠습니다. 나머지는 무시하는 것이죠. 그러고 보니 일론 머스크로 대표되는 제1원칙 사고도 떠오릅니다. 하지만, 초점을 벗어날 수 있어서 다시 주제로 돌아옵니다.

앞선 문제를 보면 줄과 매듭은 질적으로 전혀 다른 것입니다. 하지만, 수학에서는 수를 다루는 일에만 관심을 두기 때문에 수로 나타낼 수만 있다면 다른 특성은 무시합니다. 아니 무시해야만 수학을 활용할 수 있다고 해야 할까요.

그 수로 무엇을 하려고 하느냐? 그렇게 묻자.

질적 특성을 무시한다는 말은 앞서 <다시 배우는 수학과 추상 그리고 추상화 수준>을 쓰는 과정에서 기억에 남았습니다. 그리고 기록으로 남긴 글은 반갑게도 둘째 아들의 질문도 소환합니다.

아빠, 우리는 모양 비누는 참 안 써요. 거품 비누만 쓰고

학창 시절 수포자였던 저는 아이들에게 수학의 필요성을 꼭 알려주고 싶습니다. 제가 수포자가 된 이유가 무작정 외워서 푸는 것으로 수학을 강요받았다고 믿기 때문입니다. 아무튼 그런 과거와 열망이 저에게 이렇게 말합니다.[2]

주어진 문제에 갇히지 않으려면, '그 수로 무엇을 할 건데'라고 물으면 되겠네.

원하는 특성만 뽑아 적절한 형태를 만들기

제가 좋아하는 모델링은 수학과는 다른 목표로 추상을 활용합니다. 하지만, 원하는 특성만 뽑(抽)아 적절한 형태(象)를 만든다는 행위는 똑같습니다. 맥락과 쓸모와 의도가 다를 뿐이죠. 쓰고 나서 보니 마음에 드는 추상에 대한 정의입니다. 아직 완성형은 아니지만, 언젠가 될 때까지 계속 가 보죠.

앞선 아이의 문제를 보면 '기호'란 낱말도 있습니다.

<낱말의 뜻을 깊고 넓게 묻고 따지는 일의 소중함> 실천으로 한자사전을 봅니다. 어떤 사물이나 일을 두고 추상을 하게 되면 생각이 만든 별도의 뭔가가 만들어집니다.

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

그걸 개념이라고 할 수도 있겠고, 개체라 할 수도 있습니다. 한국말에는 아주 편리한 '것'이라는 낱말이 있습니다. '것'이 어색하면 '일'에 담을 수 있고요.[3] 하지만, 그것이 뭐든 '그것'을 쓰려면(記) 이름(號)이 필요합니다. 여기서 저는 인터페이스 개념과 다시 만나게 되었습니다.

제 머릿속 과정을 UML 도식을 이용해 드러내면 다음과 같습니다. (초등 수준) 수학에서는 수로 물건의 양이나 무게 따위를 추상화합니다. 그때 기호(記號)로 숫자를 씁니다. 그러한 기호적 측면은 자바의 인터페이스와 정확히 같다는 생각이 들었습니다.

객체 지향적으로 말하면, 객체 내부에 무엇이 있든 관여하지 않고 외부에 서비스하고 싶은 기능(혹은 오퍼레이션이나 메소드)만 정의하여 노출한 것이니까요. 그게 바로 추상의 결과죠. 한 때, 인터페이스 기반 프로그래밍Programming to interfaces의 팬이었던 지라, 기호와 인터페이스의 상관관계를 늦게라도 알게 되어) 반갑습니다.