비대칭적인 일상의 순간이 알려준 이벤트와 스키마 대응
설계: 생각을 ‘차려’ 물질로 만드는 힘
뜻밖의 사건들을 그냥 지나치지 않고 곱씹어 기록을 남기는 일은 일상의 기록을 넘어 부산물을 만듭니다. 이 글은 여러 뜻하지 않은 사건들에 대해 깊이 사고하다가 설계와 관련 있는 인사이트를 얻은 기록입니다.
비대칭적인 일상의 순간이 알려준 이벤트 드리븐
이야기의 시작은 이렇습니다. 육아의 의무를 <두 아들과 함께 배우기> 기회로 활용하는 과정에서 쓴 <한자가 드러나는 장면에서 씨말로 인식하게 돕기>는 지식 덕후에게 어울리는 득템(?)의 순간이었습니다. 바로 다음 사진을 찍는 장면에서 시작한 연상 작용이죠. 두 달쯤 전에 <Event Driven의 기원과 현실적인 활용 방법>을 쓰면서 'Event Driven과 Object Oriented의 연관성?'을 다룬 일이 있습니다.
그 사유의 흔적이 기억에 남아서 일상에서 뜻하지 않은 연상을 만들어 낸 것이죠. 정확하게는 다른 요인이 개입합니다. 일상과 독서 과정에서 자주 발견하는 '대칭에 대한 느낌에 담긴 의미를 묻따풀 하는 활동'이 영향을 끼쳤죠.
그리하여 아이가 사전에서 '백미'를 찾은 후에 버섯 사진에서 마당에 핀 '참비늘버섯'을 찾게 된 장면을 보고 제가 '아하 모먼트'를 맞이한 것이죠.
출처: 구글링 검색 결과대칭으로 깊어 갔더니 발견한 객체의 대칭 그룹
제가 의도한 일 이후에 벌어지는 사건을 보며 이번에는 비대칭이란 느낌이 들었습니다. 자연스럽게 이렇게 물었습니다.
왜, 비대칭이지? 그럼 대칭은 뭐야?
시점을 뛰어넘어 기억을 연결하는 연상 행위를 할 때 '대칭적'이라고 느끼는 느낌을 다룬 바 있습니다. 바로 <대칭으로 깊어 갔더니 발견한 객체의 대칭 그룹>을 쓰던 순간이죠. 그런데 여기서 대칭적인 것이 아니라 특정 주제를 기준으로 흐르는 시간을 건너뛰며 사건을 연결시키는 인식이 있었습니다.
특정 주제(Subject)를 기준으로 하여 다수의 주체가 사건을 인지하는 방식은 앞서 제가 그린 도식과 그대로 일치했습니다. 그리고 이는 하나의 주체가 자기 관점에서 사건을 풀어낼 이유가 없는 방식이죠. 마치 main 프로그램이 제어 흐름을 일관성 있게 짤 수가 없는 것과 같은 이치입니다.[1] 어떻게 양상이 펼쳐질지 모르는 경우에는 main 프로그램에서 다룰 수 없으니까요.
내용이라고 써도 되고, 사건이라도 써도 되는 순간
이제는 전혀 다른 일에서 추가적인 영감을 얻은 바를 씁니다. <'스스로 하는 나'에서 '위하는 나'로의 전환>을 쓰는 도중에 '내용'이라고 써도 되고, '사건'이라도 써도 되는 순간을 맞이했습니다.
다시 한번 유레카를 외치는 장면[2]입니다. 뒤에 인용한 구절은 내용일 수도 있고, 사건과 대응하는 내용일 수도 있습니다. 프로그래밍 모델과 대응시켜 보면 '내용'인 경우는 양식(Form)에 데이터를 입력하는 경우와 유사합니다. 흔히 CRUD로 개발하는 일이 익숙하니까 '내용'을 다루면 익숙한 프로그래머가 많습니다.
반면에 '사건'이라고 하면 해석의 여지가 생깁니다. 사건을 어떻게 묘사할 것인가는 관찰자의 관점을 따르게 되고 청자나 독자까지 고려하면 조금 더 노력이 필요한 작업이죠. 개발로 치면 창의적인 프로그래머가 필요합니다. 아니면 소통에 능하거나.
이렇게 내용과 사건의 대별로 알게 된 사실은 사용자 인터페이스를 크게 대별하는 데에 이러한 이분법을 사용할 수 있다는 가정입니다. 기업용 프로그램이 문서의 전산화를 중심으로 발전했다는 점을 생각하면 '내용'을 다루는 방법이 자연스럽습니다. 문서 내용을 CRUD 하면 되니까요.
그런데 사용자의 맥락이 달라지면요? 작은 핸드폰을 들고 다니며 일을 처리하거나 키오스크에서 혹은 음성으로 뭔가 하고 싶은 경우는요? 그럴 때면 사건을 따져서 맥락에 맞는 사용자 경험을 처리해 줘야 할 듯합니다. 이때는 문서 단위보다는 더 작은 데이터 단위를 택하는 편이 좋겠습니다. 근데 그때 데이터 모양은 어때야 할까요?
이벤트 드리븐 그리고 스키마 없애기
여기에 대해서도 동료와 일하는 중에 아주 우연하게 '아하 모먼트'를 맞이했습니다. 동료가 상품 데이터 속성이 바뀌는 상황에서 이를 저장하기 위해서 스키마를 없애겠다고 합니다. 의도는 금세 이해했지만, 혼자서 가만히 등록된 업무를 보는데 '왜'라는 질문을 하게 되었습니다.
스키마를 없앤다는 말은 무슨 뜻일까요? PostgreSQL를 적용하면서 json 형태 저장이 쉬워서 RDB의 데이터 스키마를 쓰지 않는다는 의미입니다. 그런데 여기서 최봉영 선생님께 들은 '스키마'가 다가옵니다. 물론 전혀 다른 맥락의 이야기였습니다. 인지와 인식 수준에서 스키마가 없으면 감각한 바를 대응시킬 수 없으니 알 수가 없습니다!
그래서, 인지와 인식 수준으로 '번역'할 수 있습니다. 데이터베이스 스키마를 쓰지 않고, 프로그램에서 스키마를 다루겠다고 말이죠.
스키마Schema란 무엇인가?
<낱말의 뜻을 깊고 넓게 묻고 따지는 일의 소중함>을 실천하기 위해 위키피디아를 찾아봅니다. 데이터베이스 스키마는 별도 페이지가 있습니다. 최봉영 선생님이 말씀하신 감각 도식은 Body schema,에 해당하는 듯합니다. 하지만, 아쉽게도 프로그램에서 이를 다루겠다면 그에 상응하는 정의는 없습니다.
혹시나 해서 Schema (genetic algorithms)와 Schema (logic)를 찾아보았지만, 공통점이 있을 뿐 제가 상상하는 것을 지칭하는 개념은 아니었습니다. 혹시나 해서 'json schema'를 키워드로 찾아보니 역시 이미 존재하네요.
이 부분의 구현 연관성은 나중에 개발자 동료에게 묻는 편이 좋겠습니다.
이벤트와 스키마의 대응
한편, 앞서 '사건'이라고 하면 해석의 여지가 생긴다고 했습니다. 그에 대해 조금 더 설명해 보겠습니다. 앞서 소개한 내용은 카톡으로 문서를 받은 사건에서 출발합니다. 여기서 '제가 필요한 내용만 발췌'한 것이죠.
사건에서 '제가 필요한 내용만 발췌'하는 장면은 마치 구독 모델을 연상시킵니다. 그리고 그렇게 발췌한 내용을 보내면 수신하는 쪽에서는 읽을 준비가 되어야 합니다. 아주 포괄적인 의미에서 스키마가 필요합니다. 위키피디아 정의에는 없는 영어 사전에 나오는 수준이라고 할 수 있을까요?
A schema is an outline of a plan or theory.
그런데 구현(realization)을 하려면 구체적인 기술과 방법이 필요하고, json schema가 이를 규격화하는 시도 중에 일부가 아닐까 짐작해 봅니다.
암튼, 이때 구독하는 프로그램이 여럿이라면 각자 필요에 따라 발췌할 수 있고, 그에 따라 여러 개의 스키마 혹은 스키마 소비가 존재할 수 있습니다. CRUD 기반 프로그램에서 데이터베이스 스키마가 해 주는 역할에 대한 대안으로 이런 것들이 필요하다는 사실을 깨달은 것으로 굉장한 소득이 있다고 느낍니다. 이제 그 문제를 실용적으로 다뤄볼 수 있는 기회를 찾아봐야겠습니다.
주석
[1] 와~ 그렇게 생각하니 RDBMS 이름 오라클은 정말 잘 지은 이름이네요.
[2] 챗GPT4o에서 다음 프롬프트를 사용하여 만들었습니다: 정조가 욕조에서 유레카 하는 장면을 간결하게 묘사해 주세요
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
7. Event Driven의 기원과 현실적인 활용 방법
8. 모델링에 대한 메타 인지: 모델링이라는 생각 차림법
10. 업무 분석 과정에서 UML 클래스도를 쓰면 얻는 것
13. 프로그래밍에서는 몰라도 설계에서 작명은 엄청 중요하다
14. 설계란 결국 번역인가?
15. 설계를 번역이라 한다면...
