1. RDB에서 JSON 타입은 언제 써야할까?

1. 비즈니스 로직에 엮이는 테이블에는 안 쓰는 것이 좋다.

   1. 어떤 행에는 데이터가 없고, 어떤 행에는 데이터가 문자열이 아닌 문자열 배열이거나 하는 경우가 발생한다.

   2. 위와 이어지는 이야기로, 데이터의 정합성을 유지하기 힘들다. JSON안에 특정 키가 존재해야한다, 어떤 값은 유일해야 한다, 어떤 값이 문자열 타입이어야 한다 등은 JSON 타입 컬럼을 사용할 때 불가능에 가깝다.

   3. Redash등에서 SQL만으로 query하려고 할 때 JSON 컬럼이 있으면 복잡도가 매우 증가한다. (특히 JSON 내부 값을 이용해서 JOIN하려는 경우 정말 귀찮다.)

2. 기록용 테이블에는 매우 유용하다.

   1. 내역(history) 등을 저장할 때 유용하다. 이전 값과 현재 값을 모두 JSON 컬럼에 쑤셔박아 넣을 수 있다.

   2. 로그(log)성 테이블에도 유용하다. 특히 로그의 유형(action 등)이 나뉘는 경우, 유형마다 서로 다른 정보를 저장하게 될 때가 많은데, 이 경우 payload: JSON 과 같이 선언하여 payload 컬럼에 로그의 정보를 저장하는 것이 쉽고 간편했다.

2. 기업 평가가 낮은 회사의 제품을 사용하지 않는다?

독서 모임을 찾다가 트레바리를 알게 되었다. 후기를 몇 개 찾아보다가 장점만 나와서 트레바리 단점으로 검색해보니, 트레바리 잡플래닛 기업 평가가 떴다. 평점 2.1점(!) 내가 제품이나 서비스를 이용하려는 회사에 재직중인 직원들의 회사에 대한 만족도가 너무 낮을 때 해당 제품을 이용하지 않으면, 우리 사회를 피고용인에 더 친화적인 사회로 만들 수 있을까? 만약에 기업 평가를 조작하기 시작한다면? 잡플래닛을 더 이상 신뢰할 수 없게 된다면? 직원의 고혈을 모두 빨아먹어서 경영인이 먹는 것이 아니라 100% 사회에 환원하는 기업이 있다면??

그런 생각을 하면서 독서 모임 가입을 또 미뤘다.

3. 낭만은 낭비에서 온다.

Romance의 음차로 만들어진 단어, "낭만"은 전혀 로맨틱하지 않다. 현대 한국인은(최소한 나는) 로맨틱과 낭만을 별개의 개념으로 사용하며, 요새 말하는 낭만의 뜻은 두 가지가 있다. 첫 번째는 옛 시절에 대한 향수, 그리고 야생과 같은 옛 사고방식 등을 미화하는 단어로써 낭만을 사용한다. 다른 하나는 "캬 그거 낭만이네요" 할 때의 낭만이다. 재화, 시간, 공간, 기회 등을 비효율적으로 소모할 때 우리는 그것을 낭비라고 부르고, 이 낭비에 감성이 추가되면 낭만이라고 부른다.

4. 직장과 집이 적당한 거리인지 판단하려면

이어폰을 두고 나왔을 때, 이어폰을 가지러 다시 들어가는 경우 너무 먼 곳으로 통근한다고 판단할 수 있지 않을까? 일단 나부터 성남에서 출퇴근할 때는 다시 돌아갔으나, 서울로 이사온 뒤로는 그냥 퇴근하는 편이다.

5. 강남 자동차들은 왜 이렇게 보행자가 느끼기에 공격적으로 운전할까?

신논현역 근처에서 거주하면서 느낀 점이다. 심지어 강남에 살지 않고 놀러온 사람들에게 의견을 물어도 비슷할 것이라 확신한다. 횡단보도를 건너려고 하면, 강남 차들은 공격적으로 대가리를 들이민다. 어쩌다 이렇게 됐을까?

내가 추측한 이유는 "보행자가 많아서"인데, 물론 보행자의 횡단이 더 우선순위가 높은 것은 맞지만, 계속 보행자를 먼저 보내주다가는 해당 챠량은 영원히 횡단보도를 지나갈 수 없게 될 정도로 사람들이 계속 밀려온다. 적당히 대가리를 넣어서 흐름을 끊지 않으면, 그 죄로 운전자들은 강남을 탈출할 수 없게 되는 것이다.

체감상, 과하게 대가리를 들이넣는 차가 대다수다. 하지만 이 자동차가 강남이라는 인간 정글을 헤쳐나가며 얼마나 많이 대가리를 들이 밀었을 것인가. 그 과정이 길어지면 길어질 수록, 강남에서 보낸 체류시간이 길어질 수록 인내심이 줄어들어 공격적으로 운전하게 된 것은 아닐까. (하고 생각하기로 했다.)