자료 구조 설계 - id의 중요성

직관적으로 봤을 때, 우리가 느낄 수 있는 의미 단위, 덩어리를
object로 만들고 ID를 발급해서 DB의 key로 쓰면 좋다.

일단 object로 만들면 구체적인 것이 되고 ID가 있으면 각각을 구별하고 부를 수 있고
관리도 가능하다.

요즘 다른 사람이 설계해 놓은 걸 수정하고 있는 데,
처음부터 각 entity를 잘 정하고 relation을 잘 기술했으면 좋았을 텐데.
그냥 잘 모르는 사람이 설계하고, 기획자가 시키는 대로 만들어서
자료 구조가 상당히 엉망인 것 같다.

기획자들은 소프트웨어 전문가가 아니기 때문에 숨은 요구사항을 잘 표현하지 못한다.
소프트웨어 전문가인 개발자들이 그걸 충분히 고려하고 미리 유연하고 확장가능하고
명확하게 만들어 놔야지, 나중에 그들의 숨은 요구사항도 쉽게 들어 줄 수 있다.
빠르게 구현하다보니 직관적이지 않게 되어 있다.

결국 내가 모니터링 툴과 통계 툴을 만들려고 설계를 다시 뜯어보니,
설계에 문제도 있고, 잘못된 설계 때문에 버그도 있다는 걸 알게 됐다.
핵심적인 key(id)가 없었다.

그래서 구현을 여기저기 수정해서 key를 박아 넣으니
모듈간에 하나의 key를 가지고 data를 다룰 수 있게 되었고
통계를 낼 수도 있게 되었다.

드디어 transparent하게 외부에서 내부의 흐름을 잘 관찰할 수 있게 되었다.
예전에는 data 전체를 batch로만 돌려서 하나의 큰 덩어리로만 봐야 했는 데,
이제는 data를 id별로 tagging해 놨기 때문에 각각의 id에 해당하는 data의 상태를 각각 관찰할 수 있게 되었다.

----------
예를 들어 내가 의사라고 하자.
여기 50명의 환자가 있는 데, 그들은 이름과 얼굴이 없다.(구별이 불가능하다.)
우리는 50명 중 10명은 다리가 아프고, 10명은 고혈압이라는 사실은 물어서 count 할 수 있다.
하지만 각 환자를 구분할 수 없다면
각각의 환자 중 누가 다리가 아프고, 고혈압이고 이미 치료를 했는 지,
치료는 얼마나 진행되었는 지, 약은 먹었는 지는 알 수가 없다.

그래서 환자에게는 각자 이름이 필요하고 각자를 구분해서 부를 수 있다면
각자 차트를 따로 만들어서 관리할 수도 있게 되는 것이다.

이게 숫자의 신비인데, count할 수 있으면 enumeration을 통해 id로 naming할 수 있고
naming할 수 있으면 관리할 수 있고 내 것이 된다.

----------
설계 없는 구현을 해 놓은 걸 보면 일 자체가 잘못된 것은 아닌데, 일을 생각하는 방식에는 문제가 많다.

"내가 문제 삼는 것은 일을 진행하는 방식이 아니라 일을 생각하는 방식이다. - 에픽테투스"

----------
ID가 없는 object는 processing 할 수는 있지만 monitoring 할 수는 없다.