Bottom-up 변수에서 시작하는 스키마 설계

HITL(Human-in-the-Loop)의 데이터 솔루션 기획 (4)

이번 글은 '변수(Variable)'와 데이터 수집을 위한 '스키마' 개념을 세워가는 과정에 대한 이야기입니다.

이 작업은 일단 어떤 데이터를 수집할 것인가에 대한

구체적인 가이드라인이 없이 시작하는 Bottom-up 프로젝트에 있어 참고가 될 수 있습니다.

(제가 통계학 기반이라서 완전한 AI 프로젝트는 아니고, 반반이랄까요...)

데이터 설계의 Top-down VS Bottom-up 방식 (챗지피티 정리, 도식을 나보다 잘만든다...ㅎ)

가설이 폐기되더라도 데이터 수집의 1차적인 가이드 스키마를 세워볼 수 있기 때문입니다.

하지만, 이 부분은 다소 정성적인 얘기여서 내용이 다소 깁니다..

(지루할 수 있기 때문에, 영감의 원천? 우리집 고양이 사진을 다수 넣었습니다..)

이번 프로젝트의 뮤즈, 치즈태비 나루

마지막 부분에 챗지피티와 제미나이를 통해 설계 검증을 수행한 포인트를 정리해두었습니다.

지난 사전 분석의 결과로

가설 1.

'어떤 사료나 용품을 구매 또는 사용하면 고양이의 자는 모습이 달라진다.'를 도출했습니다.

수의학과 동물행동학(Ethology) 논문들을 참고하여 이 가설이 과학적으로 타당한지 살펴보았습니다.

결과를 덧붙이자면, 이것은 실제 데이터 수집-분석의 1차 과정을 거친 약 한달 후 폐기되었는데요,

그것은 나중 다시 한번 설명드려보기로 하고

---

먼저, '고양이가 자는 모습'을 평가하는 종속 변수는

정확히 어떤 의미이고, 또 무엇으로 구성될까요? (관측을 위한 개념 쪼개기)

자는 모습이라는 것은 매우 추상적입니다.

이제 구체적으로 '자는 모습'을 '어떻게' 수학적으로 정의할 것인가(측정할 것인가)를 위해

자는 모습을 형성하는 요소들을 잡아보겠습니다.

(변수의 구성, 실제 입력-추출될 관측 요인)

찾아보니, 구체적으로 자는 모습이라는 것은 자세와 위치, 그리고 호흡수로 구성될 수 있었습니다.

그러고 보니 나루도 밥을 먹으면 잔다. 밥은 하루 네번 나오는데...거의 온종일 자는구나

---

이제 마찬가지로 독립 변수를 살펴볼까요?

독립 변수와 종속 변수는 어떤 관계를 지녀야 합니다.

통계적, 수학적으로는 실제로는 전혀 관계가 없는 변수들도 마치 관계가 있는 것처럼 나올 수 있습니다.

예를 들어, 어느 날 내가 귤을 먹었더니 주가가 올랐다.

이런 정성적인 의미로는 실제 아무 관계가 없지만, 통계적으로는 충분히 관계가 있다고 나올 수 있습니다.

우연찮게 귤을 먹는 날마다 정말 주가가 오를 수 있거든요.

따라서 종속 변수에 어떤 것이 영향을 미치는가는

그 개념과 의미, 맥락 속에서 파악하여야 하는 도메인 지식의 영역입니다.

먼저 앞 선 결과로 '사료/용품의 구매(사용)'을 독립변수로 잡았습니다.

이 독립 변수, 사료와 용품의 사용은 '자는 모습'에 영향을 미칠 수 있을까요?

한번 논리적으로 따져보는 겁니다.

사료와 용품의 사용은 정확히는 고양이가 하는 것은 아니고 집사가 하는 행위입니다.

어떤 사료를 먹인다고 해서 바로 고양이가 잠이 들거나 하는 것은 아닙니다.

그렇지만, 찾아보니 육식동물인 고양이는 단백질 식사 후 소화를 위해 깊은 잠에 빠지는

'식후 휴식(Post-prandial sleep)' 본능이 있습니다.

즉, 사료의 사용과 자는 모습 사이에는 선후의 시간 인과적 관계가 성립될 수 있습니다.

만약, 이것이 사료가 바뀌어 소화가 불편하다면 식후 휴식 수면 패턴에 영향을 줄 수 있습니다.

밥밖에 모르는 밥 바라기 나루

마찬가지로 용품도 생각해볼까요?

여러 고양이 용품 중에서도 장난감은 고양이의 자기 전 활동에 영향을 미칩니다.

충분한 사냥 놀이(장난감)는 에너지를 소진시켜 깊은 렘수면(REM)을 유도합니다.

또 용품 중 발톱을 긁는 스크래쳐나 숨숨집은 고양이에게 잠자는 환경으로써

스트레스를 낮추고 수면의 질을 높여줄 수 있습니다.

이처럼 직접적인 인과에서 시작하는 것은 모델이 단순하기 때문에

어려운 모델을 떠올리기 전 우선적으로 생각하기 좋습니다.

(비정형 데이터가 아니라 이렇게 트래킹을 하는 경우는

비선형 --> 선형 모델 보다는 선형 모델에서 비선형 모델로 발전시키는 것이

개인적으로는 Bottom-up 방식에서 더 쉬운 것 같습니다.

설계는 선형으로 했지만, 모델링 과정에서 비선형이 될 수 있기 때문이죠. )

이제 지금까지의 정의와 구성을 반영해 단순한 방정식 모델을 정리해보겠습니다.

입력(X): 놀이 (장난감) + 식사 (사료) + 환경 (숨숨집/스크래쳐)

출력(Y): 자는 모습 (자세, 위치, 지속시간)

이 때 장난감은 사실은 놀이라는 속성을, 사료는 식사를, 숨숨집/스크래처는

환경 속성을 대변하는 측정 가능한 변수인 셈입니다. 이 측정 변수는 바뀔 수도 있고,

또 놀이, 식사, 환경을 상위 속성으로 카테고리화 할수도 있습니다.

이렇게 정리를 하니, 왜 어떻게 자는 모습이 사료와 용품에 따라 달라질 수 있는지를

직관적으로 이해하기 쉽습니다.

또 이제 데이터 모델로써 어떤 것들을 측정할 수 있을 지도 대충 감이 잡힙니다.

그런데 이 모델을 그대로 사용할 수는 없을 것 같다는 생각도 동시에 듭니다.

하지만 이러한 과정은 데이터 수집의 정확성과 또 모델링에서의 유의점을 미리 생각하게끔해주는

질적 향상의 중요한 포인트가 되었습니다.

---

[통계학 기반 모델링 주의점]

통계학적 선형 모델의 현실 적용의 한계가 있습니다.

인과적 방정식 모델 또는 회귀 모델은 잘 통제된 환경 하에서만 그 예측력이 잘 가동될 수 있습니다.

자, 다시 한번 돌아가서 생각해보았습니다.

이 모델의 활용 결과를 생각해볼까요?

어떤 사료를 먹었더니 고양이의 자는 모습이 이상하다 그래서 병원에 데려갔다.

병원에서는 검사와 진단을 통해 고양이 사료의 특정 성분이 고양이의 신체적 질병을 유발했음을 진단했다.

어떤 사료는 고양이의 자는 모습을 이상하게 만들 수 있다. (왜냐하면 특정 질병을 유발할 수 있음으로)

이건 아픈건 아니고.. 하품 모습. 아직 젊어 튼튼한 나루

이게 바로 통계학이 의학에 활용될 때의 모습이자 '원인'을 찾는 '예측'입니다.

그런데, 통계적 추론에서는 단순히 독립 변수와 종속 변수를 잘 세우는 것만 중요한게 아니고,

내가 측정하는 변수 외에 영향을 미칠 수 있는 다른 변수를 고려하는 것이 더욱 중요합니다.

이게 바로 그 유명한 ceteris paribus 입니다.

(다른 모든 것들이 다 동일하다는 전제 하에)

만약 어떤 사료를 먹고 나서, 고양이가 자기 전에

물도 마시고, 또 밖에 나가서 놀기도 하고, 또 갑자기 예기치 못한 사고가 난다거나,

또는 집사 외에 또다른 가족구성원이 다른 사료를 또 먹였다면?

이 요인들 역시 자는 모습이라는 결과에 영향을 미칠 수 있다는 것입니다

이런 '변수의 간섭'이 문제입니다.

고양이가 구석에 숨어서 자는 이유가 정말 '아까 먹은 사료' 때문일까요?

혹시 창밖에 비가 와서 기압이 낮아졌기 때문은 아닐까요?

단순 모델은 이런 외부 환경 변수(Context)를 고려하지 못해,

엉뚱한 인과관계를 만들어내는 '허위 상관(Spurious Correlation)'의 함정에 빠지기 쉽습니다.

또한 현재의 단순한 인과 모형(회귀 모형)

다음과 같은 데이터 분석 한계에 부딪힐 수 있었습니다.

입력과 출력 사이에 '시차(Time Lag)'가 존재합니다.

이유를 알고 싶은 대상을 '수면'에 초점을 맞췄기 때문에,

놀이(장난감)와 식사(사료)와 같은 입력변수가

오후, 야간의 수면이라는 종속변수와 꽤 차이가 날 수 있습니다.

오전에 먹은 간식이 소화불량을 일으켜 밤늦게 수면 자세를 망가뜨릴 수도 있습니다.

이것이 바로 '지행 지표(Lagging Indicator)'의 문제입니다.

고양이가 자기 직전에 사료를 먹고 이런 모습으로 잠을 잔다.라는 인과가 성립하기 위해서는

매일 동일한 환경과 동일한 상태에서 '원인'에 해당하는 그 요인만 영향을 미쳤을 때,

결과에 영향을 준다. 라고 말 할 수 있습니다.

따라서 위의 단순한 방정식 (또는 회귀 모델)은 실용적인 모델로는 좋지 않다고 판단했습니다.

그 측정 환경에서 예측되지 않는 다른 변수들이 너무나도 많아,

'어떤 요인을 인과적으로 가려낸다는 것이 실질적인 효과는 없겠다' 라는 것입니다.

(인과를 찾으려면, 병원에 가는 게 맞죠)

---

이제 다시 비즈니스 문제를 살펴볼까요?

제가 주목한 비즈니스 문제는 '집사들은 내 고양이 행동의 이유를 알고 싶어한다'는 것이었습니다.

(이를 해결하기 위한 데이터 가설이 '사료와 용품의 사용이 자는 모습에 영향을 미친다' 였구요)

'이유'를 제공하는 것은 '원인'을 짚어내는 것과는 다릅니다.

뭔가 흥미로운 것이 있을 때, 보통 꼬리가 수직으로 끝에만 살짝 꺾인 모습

아주 쉽게, 예를 들어 고양이의 꼬리 언어가 있습니다.

사람들은 고양이의 꼬리의 모양이 변한다고 해서 '이것이 문제이니 원인은 뭐지'라고 생각하지 않습니다.

그냥 왜 그런 행동을 하는지가 궁금한 것이죠,

만약 고양이가 수면 중에 갑자기 코를 곤다면 이건 너무 잘 놀았기 때문일 수도 있고

아니면 밥을 너무 많이 먹어서 일 수도 있습니다. (이유)

그리고 밥을 너무 많이 먹는 것은 어떤 질병과 관계가 있을 수 있습니다. (문제)

제가 초점으로 잡았던 것은 이 중 '이유'에 해당하는 것이었습니다.

그 이유가 위의 예시처럼 밥을 너무 많이 먹어서,

질병이 될 수 있는 것이라면 병원에 가서 '문제'로 진단을 받아야겠죠?

"집사는 '진단(Diagnosis)'보다 '해석(Translation)'을 원한다."

이것은 병원의 진단(Health)에서 라이프스타일(Lifestyle)로

비즈니스 도메인을 확장하는 아주 중요한 전환점입니다.

아픈 고양이는 소수지만, 궁금한 고양이는 모두니까요.

그래서 모델을 회귀 모델이 아니라 연관 규칙 모델으로 하고자 했습니다.

(연관 규칙 모델은 흔히 장바구니 모델이라고 불립니다.

연관 규칙을 하려고 했다는 것 자체가 사실상 영향을 미치는 변수를 일단 다 넣어보겠다 라는 방향인데,

이것은 다음 편에서 자세히 설명하겠습니다.)

---

이제 그 다음으로는 실제 모델을 위한 데이터 수집 및 전처리 과정이 필요합니다.

이제, 모델 정의는 나왔으니 스키마 수립을 하면 되는데요,

스키마(Schema)는 쉽게 말해 "데이터를 담을 그릇의 설계도"입니다.

집을 지을 때 평면도를 그리듯, 데이터를 엑셀이나 데이터베이스(DB)에 저장할 때

"어떤 항목(Column)을, 어떤 형태(Type)로, 어떤 순서로 저장할지" 미리 약속해두는 틀을 말합니다.

논리의 언어를 물리적인 데이터의 구조로 변환하는 작업입니다.

이 설계도가 잘 짜여 있어야 나중에 데이터를 쌓았을 때 분석이 가능합니다.

(설계도가 없으면 뒤죽박죽 섞여서 분석할 수 없는 쓰레기 데이터가 됩니다.)

제 모델에 대한 정의서를 정리하고

(일단은 가설을 중심으로 적었습니다.)

각각 챗지피티와 제미나이에게 전달하고 이를 평가해보라고 했습니다.

결론부터 얘기하자면, 각 생성형 AI는 각기 다른 부분을 짚었습니다.

그래서, AI를 여러개 돌려보는 것이 도움이 됩니다.

1. Chat GPT의 보완

: 기록과 커뮤니케이션을 위한 탄탄한 논리 보완

⚠ 보완 1. “연관 규칙 분석”의 기술적 정의가 모호함

⚠ 보완 2. “호흡수”는 현재 모델과 불일치

⚠ 보완 3. “예측 vs 해석” 구분을 더 명확히

챗지피티는 논리적인 부분을 짚어주었습니다.

먼저, 2와 3의 경우 언어적인 부분인데요,

종속 변수의 잠자는 모습 (수면)에서

현재 모델에서 자세, 위치, 지속시간 외에 맨 처음에 '호흡수'가 추가되어 있었습니다.

(수의학 논문에서 참조를 하여 구성을 잡다보니)

그런데 이 부분은 집사가 측정하여 기록하기에는 한계가 있어 분명하게 할 것을 요청했습니다.

따라서 1차 모델에서는 '호흡수'는 일단 제외합니다.

(추후 업데이트 사항이 될 수는 있겠습니다.)

3번의 경우, 본 모델의 정의가 회귀 모델에서 연관 규칙 모델로 바뀌면서

미래 예측 정확도와 과거 패턴 해석이 혼재되어 있는데 이것을 지적했습니다.

이 모델은 미래 행동을 정확히 맞히는 것이 아니라,

과거에 관측된 패턴을 조건부로 해석하는 모델이다

라고 단언할 것을 조언했습니다.

이런 논리적인 부분은 별거 아닌 것 같지만(?) 아 다르고 어 다른 듯하지만

매우 중요한 포인트입니다.

실제 실무에서 이러한 데이터 분석과 모델 수립 검증의 과정을 혼자서 하는 것이 아니고

여러명의 담당자가 협업의 형태로 진행하게 됩니다.

이 때 모델의 정의에 대해서 각기 다르게 이해한다면 결국 그것은 시스템의 품질 저하로 이어질 수 있습니다.

또한 미래 행동을 정확히 맞히는 모델과 조건부로 해석하는 모델은

모델 성능의 평가에 있어 각기 다른 지표를 검토해야 합니다.

(이 성능 평가는 추후 모델 검증하면서 다뤄보겠습니다.)

이처럼 AI를 활용한 검토는 매우 중요한 포인트를 교차 검증할 수 있게 해줍니다.

문서나 정의서 혹은 커뮤니케이션 전에 한번 필터링해보는 것이 좋겠습니다.

“초기 단계에서는 빈도 기반 연관 패턴을 사용하되,

이후 분류 모델의 설명 변수로 확장 가능하다.”

위의 내용이 챗지피티가 추천해준 정리 문장입니다. 너무 깔끔하죠?

일단은 모르겠고, 모델링 하면서 차차 정리해봐야지. 라고 생각했던 부분을 말로써 분명하게 표현해줍니다.

다음으로 제미나이의 답변입니다.

혹시, 챗지피티와 제미나이의 차이점을 아시나요?

도입 초 제미나이는 챗지피티보다 '착한' 인공지능을 만드는 것을 목표로 했습니다.

(불과 1년 전인데 벌써 까마득한 옛날같이 느껴지네요.. AI의 발전속도란..)

지금은 두 생성형 AI 툴 모두 보다 객관적이고 분석적 활용이 가능하게끔 되어있으나

제미나이는 기본적으로 요청자의 요구를 이해하고 이를 보다 긍정적인 방향으로

디벨롭하는 것에 초점을 두는 것이 초기에는 정말 많이 다르게 느껴졌습니다.

특히 언어적 커뮤니케이션에서 보다 따뜻함을 지향하는 경향이 있었습니다 ㅎㅎ

2. Gemini 의 보완

: 기술적 포인트 (Technical Considerations)

제미나이를 통해 기술적 포인트 보완을 받을 수 있었습니다.

1) 시계열적 연관성 (Sequential Pattern Mining)

2) 지지도(Support)와 신뢰도(Confidence)의 밸런스

위의 두 가지가 제미나이가 제안한 보완 사항입니다.

먼저, 1. 시계열적 연관성의 고려

현재 연관 규칙 분석은 흔히 장바구니 분석이라고도 합니다.

일반적인 장바구니 분석은 (맥주를 살 때 기저귀를 산다)은 시간 개념이 없습니다.

발생 빈도를 바탕으로 패턴을 찾는 것이니깐요.

그런데, 우리 데이터는 시계열 연관이 있을 수 있다는 것입니다.

[낮: 사냥놀이] -> [밤: 꿀잠] 처럼 선후 관계가 중요합니다.

이를 위해 제미나이는

단순 연관 분석(Apriori)을 넘어, 순차 패턴 마이닝(Sequential Pattern Mining) 개념을 도입하거나, 데이터를 입력할 때 시간대(Morning/Afternoon/Night)를 태그와 함께 묶어서

트랜잭션을 구성할 것을 추천했습니다.

이를 챗지피티의 보완과 묶어서 보면,

초기 단계에서는 빈도 기반 연관 패턴을 사용하되, 순차 패턴 마이닝이나 분류 모델의 설명 변수를 확장한다.

라고 일종의 모델링의 순차적인 계획, 단계를 세워볼 수 있습니다.

어때요? 유용하죠? (이런 것들은 기존에는 실무적인 노하우 였습니다만...)

두번 째는 지지도(Support)와 신뢰도(Confidence)의 밸런스입니다.

관점이 다르지만, 챗지피티가 말한 '기술적 정의의 모호함'과도 비슷한 맥락의 논점입니다.

너무 희귀한 변수는 데이터가 적어서 패턴을 못 찾을 수 있습니다.

"집사님들의 공통 데이터"를 활용한 '전체 집사 평균 모델'과 '내 고양이 맞춤 모델'을 하이브리드로

가져가는 전략을 추천했습니다.

초기 데이터가 부족할 땐 전체 통계를 보여주는 것이죠.

이는 베이스라인 모델을 만들 때에 "공통 데이터"를 우선 찾아야겠구나 라는 데이터 수집에 도움을 줍니다.

이처럼, 생성형 AI는 단순히 코드를 짜주는 것뿐만 아니라

나의 모델을 보완하기 위한 '논리적' '기술적' 보완의 파트너로 사용하기에도 적합합니다.

그러나 각 툴이 사용하는 사용자의 평소 요구사항을 강화시키는 편향이 있기 때문에

되도록이면, 툴 마다의 목적과 목표를 따로 두고 평소에도 따로 사용하시는 것을 권장합니다.

저는 평소에 글을 쓸 때 챗지피티를 많이 쓰고,

제미나이는 데이터 분석 공부를 할 때 질문 용도로 많이 사용했습니다.

그러다보니 각 툴이 분명히 서로 다른 저와의 대화의 배경 지식을 가지고

답변하고 있다는 것이 곧바로 느껴졌습니다.

여러가지를 함께 교차해서 쓰시는 것을 추천드리지만

툴을 많이 쓰는게 번거롭다면, 요청을 줄 때에 지정과 제한을 해서 프롬프팅을 줘도 됩니다.

(기술적 측면만 고려해줘, 논리적 측면 위주로 고려해줘 등과 같은)

자, 이제 스키마 설계를 해볼까요?

생성형 AI와의 논의를 통해서

기술적인 정의의 모호성이나 분석의 단계별 목표 등도 잘 수립하여 반영하였습니다.

스키마는 쉽게 생각하면, '데이터 테이블'로 표현된다라고 이해하면 좋습니다.

“운영/확장”을 염두에 둔 정규화 설계와

“빠른 PoC”의 단일 테이블 설계는 다릅니다.

우리는 먼저 데이터 수집을 통해 모델링을 해야하고,

단계적 모델 확장의 경우도 고려해야 하기 때문에

“빠른 PoC”의 단일 테이블 설계로 간단하게 현재까지 정리한 모델을 정리해보았습니다.

구분 - 칼럼명 - 예시- 설명으로 간단하게 테이블 정의서 수준으로 정리했습니다.

이처럼 스키마를 미리 짜두면,

데이터 수집 단계에서 '어떤 데이터'를 수집해야 하는지 명확히 알 수 있을 뿐만 아니라,

내가 계획한 대로 실제 수집이 가능한지(Feasibility),

만약 엑셀로 편하게 수집한다면 나중에 어떻게 전처리(Preprocessing)를 해야

분석이 가능한지 미리 알 수 있게 됩니다.

추후 본 데이터 분석을 진행하면서 발견되는 문제점들을 통해 다시 지속적으로 업데이트해 나가겠습니다.

덕분에 일이 커졌구나.. 고맙구나! (멱살)