Data Model:Why is a data model important to computation?
카테고리: Clinical Informatics
Data Model이란 무엇이고 computation에 왜 중요할까요?
1. 들어가며
오늘은 데이터 모델에 대해 말해보겠습니다. CDM들도 각자 하나의 데이터 모델이죠. (이 글을 읽으신 다음 관심있으신 CDM의 ERD를 펼쳐서 한 번 가만 들여다 보시는 것도 재밌을 것 같네요.)
“Data modelling is the first and most crucial step in the multi-tiered design of information systems. The final product reliability, for example specific clinical decision support algorithms or integrated information systems, is hardly improved over the designed reliability on the lower level of architecture (data-level).”
Kim, H.J., Kim, H.J., Park, Y. et al. Clinical Genome Data Model (cGDM) provides Interactive Clinical Decision Support for Precision Medicine. Sci Rep 10, 1414 (2020). https://doi.org/10.1038/s41598-020-58088-2
저의 글은 저보다 똑똑하기 때문에.. 위와 같이 제가 작성했던 discussion을 인용해 보았습니다. 데이터 모델과 아키텍쳐는 눈에 보이지 않기 때문에 (매의 눈이 있고 소프트웨어가 많은 기능을 제공한다면 살짝 보이긴 보임) 간과되는 경우가 많은데, 이럴 경우 오픈까지 개발보다 유지 보수가 더 손이 많이가는 시스템이 탄생합니다 (…)
CDW 구축이 도입되던 2010년 전후로 여러 병원들에서 대규모 클렌징(이라고 쓰고 눈물의 재설계..)를 수행하기도 했는데, 오픈 이래 십수년 이상 쌓아온 데이터가 초기 설계와 유지보수 철학에 따라 그 유용성과 뒷감당의 차이가 엄청나다는 것을 커뮤니티가 같이 학습할 수 있는 시기이기도 했습니다.
소프트웨어를 설계할 때, UML은 그려도 data layer설계는 그냥 변수의 모음집 아닌가 싶게 하거나, DBMS에 때려넣었으면 데이터 모델… 이렇게 생각하는 경우도 있는 것 같습니다. 제가 본 사례 중 가장 멋진(!) 사례는 UI에서는 모두 분리되어 잘 돌아가는 데이터 처럼 보였는데, DW를 하려고 보니 RDBMS의 한 컬럼에 UI 코드에서 정의한 순서대로(…) 쉼표로.. 데이터를 저장해 놓은 것이었습니다.
더 멋졌던 것은 코드에서 특정 경우나 특정 시점으로 분기를 해서 화면에서 보여주는 형태가 달라지면, 데이터도 태그값 텍스트 하나를 추가해서 한 컬럼에 구겨넣었더라고요. (멋지다 연진아! 브라보!)
대부분의 의사결정권자는 사용자에 가까워서, 눈에 다 분리되서 잘 동작하는데 데이터가 엉망이라니 무슨소리야, 할 수 밖에 없었습니다.
기쁘게도(?) 격변의 시대에 사는 우리는 이제 모두가 “보는 눈”은 갖춰야 할 때가 왔습니다. 이걸 처음부터 모델링이란 무엇인가로 가는 것 보다, computation에서 (잘 만든) data model의 중요성을 먼저 보여드리고자 합니다.
소프트웨어는 데이터 + 코드로 이루어집니다. 여기서 컴퓨테이셔널 파워가 작던 시절에는 (8비트 컴퓨터 시절 상상해보세요) 데이터를 코드와 분리하지 않고 저장하고, 다루기도 했습니다. 이 떄에도 변수 설계와 데이터타입의 선언은 엄청나게 중요했지만, 컴퓨테이셔널 파워가 올라가고 우리가 컴퓨터에게 세상을 가르치기 시작하면서, knowledge representation이 엄청나게 중요해집니다.
이건 제가 너무 좋아하는 주제라서 TMI방지를 위해 오늘은 “computation에 있어서 data model의 중요성”을 보여드리는데 집중해 보겠습니다.
2. 효과적인 데이터 모델이란
여기 체리가 있어요.
2.1 체리는 체리색이죠!
우리는 color라는 entity에 대해서 "cheery" 라는 이름을 줄 수 있습니다. 물론 이걸 컴퓨터가 인식하려면 어떤 dictionary가 필요할 거에요. cheery를 이름으로 지칭할 수 있도록 하는 reference set이죠.
이 방법은 아주 직관적입니다. 그리고 우리가 평소에 쓰는 지칭인 “이름”으로 색상을 match할 수 있어요. 대신, 이것은 매우 난잡하고 (놀랍게도 이름은 unique identifier가 아니죠! 한 반에 김효정A, 김효정B가 있던 시절을 생각해보세요) 다음과 같이 표준화된 dictionary를 참조한다고 해도 확장성이 매우 떨어지고 경직되어 있습니다.
쉬운 테스트 방법으로 이 표에 색상을 추가한다고 생각해 보세요. 색상의 이름을 아는만큼/붙이는 만큼 추가가 가능할 것이고, 만 개의 색상을 표현하려면 만 개의 서로 다른 단어가 필요합니다.
2.2 지식을 더해봅시다
그런데 사실 우리는 color라는 entity에 대해서 매우 잘 알고 있어요. 세가지 색상과 밝기로 모든 색상을 표현할 수 있다는 것을 알고 있습니다. 무려 삼원색! 초등학교때 배웠던 것 같네요.
우리 머리속에 떠오른 “빨강”, “파랑”, “노랑”은 아니지만 RGB (red, green, blue) 로 표현해 볼까요? “ color라는 entity는 red, green, blue의 3가지 속성(properties)으로 구성되었다 “ 그럼 다음과 같은 데이터 모델이 생성되겠죠.
| color | ||
|---|---|---|
| green | red | blue |
| … | … | … |
이 데이터 모델을 각 색상 값은 진한 정도에 따라 0~255의 구간값을 갖는다고 정의해 주면, “체리 색상 표현하기 예제”에 다음과 같이 적용할 수 있을 거에요. (“체리색”은 여전히 2번입니다)
잘 정의된 데이터 모델은 컴퓨테이셔널해야 합니다.
즉, 각 객체(한 줄? 이라고 할까요?)을 비교가능하고, 연산가능하고, 예상가능하게 합니다. 여기서 연산은 논리적 연산을 포함합니다
3. 효과적인 데이터 모델의 강점
위 예시에서 RGB라는 색상 데이터 모델을 통해서 우리는
1) 3번과 4번 색상의 차이를 말할 수 있고,
2) 1~4번 색상을 보고 5번 색상의 값을 예상할 수 있습니다.
뿐만 아니라 이 데이터 모델을 보면, (쉬운 예시를 드느라 모두 아는 정보였지만)
3) 색상을 세 가지 색으로 표현할 수 있다는 이해도 얻을 수 있습니다.
게다가 모델이 적용한 지식의 근거에 따라, data 값의 논리적 validation도 수행할 수 있습니다. Red 값에 999가 들어있다면 error겠죠. 이 모델에서는 15줄 위에서 :) 255의 구간을 정의하기로 했으니까요.
4) 고도로 추상화 된 모델은, 어떤 값이 들어와도 robust합니다.
파랑, 민트, 보라.. 다 넣을 수 있죠.
5) 높은 퍼포먼스를 보장합니다.
“이름”으로 구성했던 모델에서는 색상과 데이터가 1:1이기 때문에 10000개의 색상을 저장하려면 10000개의 가변형 문자값이 필요했지만, 지금은 0~255*3이고 심지어 숫자값으로 처리할 수도 있습니다. 전자는 심지어 하나의 dictionary(reference dataset)도 거쳐가야 하고요. 시스템에 얹었을 때 처리 속도가 완전히 다릅니다. 데이터 모델이 복잡할수록, entity와 property, 즉 table 또는 컬럼, 변수의 수가 많아질 수록 이 차이는 증폭됩니다.
꼭 RGB가 아니어도 좋습니다. 우리는 색상을 여러 층위와 목적으로 사용해서 정말 잘 정립된 모델과 딕셔너리들이 많아요.
체계적으로 잘 정립되었다면, 같은 현상을 대상으로 한 데이터 모델들은 심지어 상호운용도 됩니다. (어느정도는)
왜냐하면, 우리는 어차피 같은 현상(색상)을 representation 하려고 했거든요. 그러니까 목적에 따라 다른 관점에서 접근했더라도 어느 정도는 통해야 정상입니다.
EHR도 입원/외래/응급의 workflow와 기록/검사/약/(시술)수술/방사선치료 와 같은 큰 덩어리들은 모두 있을 것입니다. 게다가 우리나라는 결국 심평원에 같은 형태로 전송해야 하는 이슈가 있어서, in-house 방식 개발이어도 informatician들은 각 데이터 구조를 (accessible하다면) 빠르게 이해할 수 있습니다. 그래서 in-house라는 것이 원래 100% 다를 수 있다고 가정해도, 실제로는 데이터 레이어는 어느 정도 연결가능할 수 있습니다. 데이터 레이어가 체계적으로 잘 정립 되었다면 말이죠.
쉽게 생각하면 환자별 ‘키’, ‘체중’ 은 연결할 수 있겠죠. (현실은… 제가 다 아는 것도 아니므로.. 노 코멘트하겠습니다 껄껄)
데이터 모델은 잘 설계하기는 어렵고, 도메인과 컴퓨터, 소프트웨어 아키텍트에 대한 지식도 있어야 합니다. 그리고 데이터 모델은 일반적으로 DBMS로 다루는데, applicational coder는 진입장벽도 낮고 눈에 보이는 산출물을 낼 수 있기 때문에 더 많고 흔하게 접할 수 있는 반면 DB를 설계하는 사람들은 드뭅니다. ~~특히 연구자이면서 데이터 플랫폼을 한다는 것은… 필요성 대비 사회적 자살행위에 가까운 것 같… ~~
그런데 뭔가 데이터가 있으면, 개발 또는 분석만 하면 될 것 같았는데 뭔가 수월성있게 안되거든요? 그러니까 자꾸 데이터 플랫폼 해야한다고 하는데 별도의 산업에 가까운 하드웨어 엔지니어링, 아키텍트는 전문성을 인정하고 헬스케어/의료데이터의 모델링과 파이프라인은 인식이 없거나/일방향 클렌징만 하다가 포기하거나 하는 경우가 많습니다. 좋은 설계는 때로 방대한 작업일지라도, 그것이 그나마 덜 돌아가는 길일 때에는 그냥 무식하게 가는게 가장 빠른 길이라고 생각합니다.
원천 데이터 레벨의 설계가 가지고 있는 신뢰성과 표현력 이상의 분석/상용 알고리즘은 불가능하기 때문에, 목적으로 하고 있는 현상 또는 도메인에 적합한 데이터 모델링이 바로 원천기술이고 경쟁력이 될 수 있습니다. 시작에 언급한 임상데이터유전체모델의 경우처럼, 특허도 가능합니다. 소프트웨어 회사들은 UI 스크린샷은 공개하더라도 ERD나 본인들이 데이터를 다루는 방식은 절대로 공개 하지 않습니다. 나는 분석계만 할거고 AI 알고리즘들 중 일부는 feature selection을 해주니까 일단 다 때려넣었으면 하는 접근 방식은…. 지양하시라고 말씀드리고 싶습니다. GIGO(gabage in, gabage out)하고 이 문제는 은연중에 다르게 생각하시는 경향도 있더라고요. (선한 현실 부정 단계 인정합니다) 앞서 말씀드렸듯이 도메인에 대한 이해가 곧 데이터 모델과 직결되어 있기 때문에, 엉망인 모델에서 나온 데이터는 넣어봐야 알고리즘에 불균일하고 중첩된 시그널의 향연만 제공할 수 밖에 없습니다. 수식이란 숫자를 넣으면 결과를 뱉는 것이니까요. 그게 내가 원래 추정/예측하려고 했던 현실과 일치하는지는 모델의 선택에 있고, 그 모델의 선택은 연구의 개념적 기틀부터 데이터 모델, 알고리즘 모델, 통계적 분석 모델에 이르기까지 일련의 과정이지 이 중에 어느 하나만이어서는 결국 현실에는 영향을 줄 수 없는 분석을 위한 분석에 그칠 위험이 있습니다.
우리가 건강을 저 “color” 수준으로 이해를 획득할 날이 올까요?
그 날이 온다면 (그 때의) informatician들은 컴퓨터와 손을 잡고, 철학자와 물리학자 사이에서 맨 앞줄에 앉아 있지 않을까요? :)
(현실의 informatician들은 analysis와 application 개발자들 사이에 껴서 너희의 퍼포먼스를 증명해랏 도전에 시달리며 근근히 연명.. 쿨럭쿨럭)
정말 막 두근두근 재밌지 않나요?!! (껄껄)
4. 나가며 (잡생각)
전체적인 아키텍쳐와 철학을 어떻게 가져가느냐는 data management와도 직접적으로 연결됩니다.
Big data시대라는 것에는 모두 동의하지만 big data를 다루기 위한 새로운 양상(mode)에 대한 인식은 낮은 것 같습니다.
경쟁력은 지속가능한 데이터 핸들링(순환)의 구현에 있습니다.
지속가능한 데이터 핸들링을 손으로 CRF모으던 시절과 같은 방식으로 하고 있진 않은가? 한 번 다시 생각해보시면 재미있을 것 같은데요, 데이터 거버넌스, 매니지먼트, 지식 엔지니어링과 데이터 엔지니어링, 소프트웨어 아키텍쳐 등의 지평은 적어도 알아야 합니다. (데이터 쉐어링과 크레딧도요!) 너무 거대한 이야기들이라 쉽게쉽게 “체리!”처럼 쉽게 설명 가능할 때 하나씩 올려보도록 할게요.
우리는 정말 대변혁의 시대에 살고 있습니다. 혁신은 이미 일어났고, 거스를 수 없이 우리 가까이 와있고, 파괴적 혁신이 가져올 파괴들과 창발들이 이어질거에요. 정보와 디지털의 무서움은 선점과 독점 자체가 또 힘이 되서 전복이 어렵다는 것입니다. 정말 소수의 뛰어난 플레이어들만이 살아남을거에요. 우리는 COVID 백신과 치료제 개발에서 이미 따라잡을 수 없는 격차란 무엇인가를 보았고, LLM에서 또 보고 있습니다.
어느 분야의, 기관의, 팀의 리더라면 정말 절박한 마음이 있어야 하지 않을까? 하는 시대의 변곡점이라고 생각합니다. 저는 꼬꼬마 개인이지만 나만 마음이 급한가 싶어 안타까운 마음이 들 때가 종종 있었습니다. 그래서 무엇이 중요할까에 대해서 절박하게 생각을 나누고 정보를 찾는 분들을 위해서 조금이나마 시간을 할애해서 생각을 나누어 가려고 노력해 보려고 합니다.
댓글 남기기