모델링에 대한 메타 인지: 모델링이라는 생각 차림법
설계: 생각을 ‘차려’ 물질로 만드는 힘
고맙게도 <모델링 과정의 효용성과 모델링 결과의 쓰임새>를 쓰면서 모델링 과정의 효용성을 다시 한번 깨달았습니다. 너무나 익숙해서 아이러니하게 그토록 즐겨왔던 시간의 존재 자체를 잊었다는 점도 깨달았습니다. 새삼스럽게 그 가치를 깨달은 김에 모델링에 대해서 조금 더 기록을 남기고 공유하려는 마음에 쓰는 글입니다.
모델링에 대한 메타 인지: 모델링이라는 생각 차림법
한편, 동료에게 <모델링 과정의 효용성과 모델링 결과의 쓰임새>를 공유했더니 굉장히 정교하게 모델링 과정을 표현한 피드백을 보내주었습니다.
이 부분을 읽고 나는 스스로 왜 모델링을 왜 하는지 생각해 보았습니다. 상대와 소통을 위해서도 하지만 상대가 없어도 하는 경우가 많기 때문입니다. 상대가 없음에도 스스로 모델링하는 하는 이유는 생각만 하는 것보다는 내 머릿속의 내용을 쓰고 보는 것이 내 인식을 더 정교하게 볼 수 있기 때문입니다. 이른바 '인출'과 '정교화' 과정의 일환으로 볼 수 있는데요. 이 과정에서 개념들을 도출해 내고 도출된 개념을 보면서 관계를 생각하게 됩니다. 관계를 그리면서 잘못을 인지하기도 하고 작명의 오류도 발견하죠. 그리고 누락된 부분이 없는지 확인하게 되고 전체적인 추상화 수준을 보게 됩니다. 추상화 수준은 내가 무엇을 '중요'하게 생각하는지 보여 줍니다.
서두에 인용한 그림 즉, <모델링 과정의 효용성과 모델링 결과의 쓰임새>에서 그렸던 그림에 동료의 피드백에 보이는 낱말을 추가해 봅니다.
한편, 소프트웨어 모델링에 흔히 쓰이는 어휘를 제거하여 보편적인 인간의 인식과 말을 활용하는 과정에 모델링을 대입할 수도 있습니다. '모델링'을 소프트웨어와 관계없이 '바로 보고 제대로 녀기는 역량'을 활용하는 하나의 활동으로 바라보아도 그대로 뜻이 통합니다. 그런 점에서 다음 그림도 모델링과 공통점이 많은 도식이라고 할 수 있습니다.
공통점은 바로 '차려서' 생각을 한다는 점인데요.
모델러가 모델링을 할 때 생각과 행동 흐름
위 그림을 인용하면서 한 가지 간과하던 내용을 포착할 수 있었습니다. 바로 '안과 밖'의 양상인데요. 무슨 말이냐면 우리의 인식이 작동할 때, 밖에서 받은 어떤 자극이나 감각 정보와 교류한다는 측면입니다. 이런 생각을 담아서 그림을 다시 그려 보았습니다.
최초에 모델링을 하게 되는 동기는 모델러에게 있겠으나 대개 그 동기는 외부의 자극에 의해 만들어집니다. 예를 들어 <내가 아닌 다른 사람은 모델링을 왜 하게 되는가?> 에서 인용한 그림은 자신이 작성한 코드를 다른 동료에게 설명해야 할 때, 전달 효과를 높이기 위해 그가 스스로 그린 것이죠.
다음 그림이 바로 그 모델링 결과입니다. 그리고, 위 그림에서 '모형'이라고 부르는 하나의 예시가 될 수 있습니다. 한편, 아래 그림을 구성하는 정보는 모두 기억에 의존한 것이거나 어딘가 찾아보고 표기한 내용입니다.
모델링의 필연적 자기 중심성 이해하기
이를 정리하는 과정에서 사전에 정의한 개념이나 이름이 없다고 하면, 그림을 그리면서 부여한 이름이 개념으로 만들어집니다. 그리고, 개념들이 서로 무관한 것이 아니라면 이들의 관계가 드러나고 이를 표현하게 됩니다. 이를 정제하는 과정에서 스스로 '원칙'을 부여하곤 합니다. 명시적으로 '원칙'을 내세우지 않더라도 오랫동안 스스로 믿어온 방식이 원칙으로 작용할 수도 있습니다.
이 과정에서 경계가 존재한다는 사실을 평소에 생각하지 못했습니다. 최봉영 선생님의 말과 글을 토대로 묻고 따지는 일을 하는 과정에서 우리의 말과 인식에는 '자기 중심성'이 내포될 수밖에 없음을 배우게 되었습니다. 아무튼 우리가 자기 중심성을 내포하고 있다는 전제 하면 '경계'는 '있는 그대로'를 뜻하는 자연(自然)과 '자기중심적 인식'을 나누는 개념이 될 수 있습니다.
박문호 박사님 표현으로 바꾸면 이러한 인식을 <현상적 세계와 물리적 세계를 구분하기>라고 할 수 있습니다. 그래서 필연적으로 모델링 결과는 필연적으로 자기 중심성이라는 한계를 갖게 됩니다. (사실은 모델링만 그렇지는 않겠죠.)
그 한계를 너무나도 분명하게 인식시켜 주는 멋진 그림이 있어 자주 인용해 왔습니다. 바로 <같은 현상도 서로 다른 일로 인식할 수 있으니 차리기>에서부터 써 온 그림이죠.
무상(無常)한 세상에서 모델링 결과가 갖는 한계
여기에 더하여 모델링이 갖는 필연적 한계가 또 있습니다. 고맙게도 Yeti 님이 두레이로 올려 주신 댓글이 이를 인식하는 자극이 되어주었습니다.
제 입장에서는 모델링이라는 개념을 적당히 잘 설명하신 글로 와닿았습니다. 한편으로 모델링이 문서화라는 것과 개념이 연결되는 특성이 있다고 생각하는데요. 여기까지 확장해 보면 문서화된 모델링 자료는 해당 시점의 생각의 스냅숏으로 보는 것이 자연스럽게 느껴집니다.
모델링 결과물 혹은 '모형'은 바로 '해당 시점의 생각의 스냅숏'이라는 점입니다. 사진처럼 생각을 찍어서 남긴 모형은 그것을 보는 시점에서 여전히 유효할 수도 있지만, 지나간 추억이거나 지금은 옳지 않은 내용을 담을 수도 있습니다. 우리가 사는 세상이 모두 그러하지만 무엇보다 우리의 삶과 인식이 무상(無常) 하기 때문입니다. 무상이라는 말은 생소할 수 있는데, '언제나 변하는 유기물적인 성질'을 표현하는 데에는 이만한 표현이 없는 듯합니다.
소프트웨어를 설명하는 문서를 열심히 작성하고 이를 현실에 맞춰 계속 고치는 일을 '현행화'라고 부릅니다. 아무리 열심히 일하는 조직도 보통은 어느 시점에서 현행화를 포기하게 되는데, 마찬가지 이치가 작동하고 있다고 할 수 있습니다. 문서화나 현행화가 무용하다는 말이 아니라 우리가 사는 세상이 끊임없이 변한다는 거스를 수 없는 사실 위에서 실천 가능한 방안과 도구가 필요하다는 말입니다.
그래서, 이를 보완하는 장치가 있어야 합니다.
모델링 저장소와 버저닝의 필요성
이와 관련해서 떠오르는 기억이 있습니다. 한때, 본격적으로 모델링을 배우고자 했던 동료가 있었는데요. 그에게 모델 저장소에 대해 소개했던 글이 떠오릅니다. 바로 <모델 저장소의 의미와 구현>인데요. 앞서 말씀드린 끊임없이 변하는 상황에서 현상을 어떻게 지속적으로 묘사할 것인가를 다루는 장치인데요.
마치 우리가 도서관에 적절한 수준의 책만 보관할 수 있듯이, 모델러가 선별한 개념들을 토대로 지속적으로 스냅숏에 해당하는 모형을 제작하고 변경해 갈 수 있는 작업 공간을 말합니다. 이러한 저장소가 보완 장치의 하나입니다.
한편, 중국 플랫폼의 API 문서를 보다가 다음과 같이 UML 순차도(sequence diagram)로 작동 방식을 설명한 내용을 발견한 일이 있는데요. 이 경우 API 구현 내용이 바뀌면 함께 업데이트되어야 합니다. 당연한 이야기지만, 그렇게 하려면 코드와 마찬가지로 버전 관리가 되어야 하겠죠.
출처: https://mp.kuaishou.com/docs/develop/server/epay/applyIntra-new/serverIntra-new.html
두 번째 보완 장치가 바로 버저닝이죠.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
