Gemini와 함께 Baseline 모델 수립 과정

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

지금의 접근 방식은 데이터 도메인 지식이 거의 없는 상황을 가정하고,

현실에서 떠오른 아이디어를 사용가능한 정도의 솔루션 기획으로 업데이트하는 것을 목표로 하고 있습니다.

이전 글에서는 고양이의 행동을 데이터로 이해하기 위한

수면, 놀이, 식사, 환경 변수 등을 중심으로 한 가설 모델과 데이터 스키마를 설계했습니다.

이 가설 모델은 실제 고양이를 대상으로 한 데이터 검증 없이,

텍스트마이닝과 이론으로부터 나온 것이기 때문에 실제로 키우는 반려 고양이를 대상으로

약 한 달 동안 엑셀에 데이터를 수기로 기록하며 데이터 수집을 진행했습니다.

(아이디어 → 데이터 수집 → 분석 → 모델 수정의 과정)

사실상 이번 글에서 수행된 내용이 일반적인 데이터 분석 시작에서 가이드되는 내용이고

이전까지는 본 목표의 사전 목표, 본 가설의 사전 가설 차원에서 충분한 설명과 함께 작성되었습니다.

이번 글에서는 이제 설명은 넘어가고(앞 글의 반복), 실제로 어떤 과정으로 분석을 진행했는지와

AI를 활용한 수행 방법에 초점을 맞추어 작성했습니다.

겨울을 나며 살아있는 데이터 근거가 되어준 반려묘 나루

이번 글에서 강조하고 싶은 것은

“의심하고 또 의심하기” 입니다.

이번 실험을 통해 얻은 핵심 인사이트는 다음과 같습니다.

글이 길어서, 요약 정리하면

(1) 초기 가설 모델은 실제 데이터에서 쉽게 깨진다
(2) 대화형 AI를 활용한 데이터 분석에서는 의심 → 전처리 → 재분석 과정이 필수적이다
(3) AI는 분석을 매우 빠르게 도와주지만 방향을 결정하는 것은 여전히 사람이다

그럼 한 번 수행의 과정을 살펴볼까요?

1. 가설 모델을 의심한다.

이전 글에서는 관측 가능한 변수들을 기반으로 인과 모델을 먼저 설계하고,

이후 연관 분석으로 확장하는 방식으로 일단은 모델 정의서 v1.0를 작성했습니다

인과 가설이 틀릴 가능성이 높기 때문에 방어 대응책을 둔 것인데,

고양이의 행동 패턴이 예상치 못한 외부 요인 때문에 바뀔 수 있습니다.

예를 들어 갑작스러운 소음, 날씨 변화, 방문객 등장, 집사의 일상 변화 같은 상황입니다.

이렇게 다양한 맥락 데이터가 존재하기 때문에
초기 분석 단계에서는 가장 첫 번째로는 연관 분석(Association Analysis)을 사용하기로 했습니다.

(+연관 분석에서는 보통 Apriori 알고리즘을 사용합니다.)

연관 분석은 특정 원인을 가정하기보다 데이터에서 자주 함께 나타나는 사건의 조합을 찾는 방식입니다.

(하지만 연관 분석은 성능이 나올 때까지 빅데이터가 필요해 현실적인 수행 방법이 아닐 수도 있습니다.

이러한 불확실성과 반신반의(?)가 Bottom-up 방식의 어려움인 것 같습니다.)

2. 태그 기반 데이터 수집 전략

아무튼 초기 가이드는 있어야 하니,

연관분석을 염두에 두고 ‘태그(tag) 방식의 데이터 입력 구조’를 설계했습니다.

여기서 ‘태그’라는 표현은 앱 인터페이스를 고려한 용어이며,

실제 데이터 수집에서는 자유 텍스트 형태의 기록을 의미합니다.

예를 들어 놀이 횟수, 급여량, 간식 섭취와 같은 변수들은 정형 데이터로 엑셀에 기록했습니다.

하지만 청소, 친구 방문, 갑작스러운 구토처럼 매일 발생하지 않는 사건은

하루 기록의 메모(Context note) 형태로 자유롭게 입력했습니다.

이렇게 엑셀 수기로 매일 기록하는 지난한 과정을 거쳤다

3. 서비스 관점에서의 데이터 입력 설계

이런 입력 방식은 실제 서비스 사용 환경을 고려한 설계이기도 합니다.

앞서 목표 변수로 ‘고양이의 자는 모습과 위치’를 설정한 것과 마찬가지로
이 솔루션이 실제 서비스로 기능하려면 쉬운 데이터 입력이 필수적입니다.

예를 들어 어떤 이벤트가 발생할 때마다
사용자가 앱을 열어 기록해야 한다면 서비스는 지속적으로 사용되기 어렵습니다.

현실적으로는 집사가 저녁 시간에 하루를 돌아보며 기록하는 상황이 가장 자연스럽습니다.

그래서 데이터 입력 방식도 “하루를 돌아보며 일기처럼 기록하는 방식” 을 상정했습니다.

실제 데이터 수집도 최대한 이 상황을 반영했습니다.

어떤 날은 늦게 기록하고, 어떤 날은 “모르겠다”라고 기록했습니다.

현실의 서비스 데이터는 항상 완벽하지 않습니다.

사용자의 입력 편차나 휴먼 에러 역시 실제 서비스 환경의 일부이기 때문입니다.

또한, 이전 글에서도 다뤘던 '시차'와 지행 지표' 문제도 계속 염두에 뒀습니다.

아래 서술될 AI 툴 결과를 '의심하기'에 있어 핵심적인 기준이 되었습니다.

서비스 기획에서도 집사가 저녁에 쉬면서 자고 있는 고양이를 바라보며

하루를 돌아보며 데이터를 입력하는 구조라면,

목표 변수에 영향을 미치는 요인은 시간적으로 선행 관계를 가집니다.

예를 들어 아침에 먹은 식사, 활동량, 환경의 변화가 밤의 잠에 영향을 줄 수 있습니다.

이 부분을 분석-전처리 반복 과정에서 지속적으로 고려했습니다.

---

5. AI 분석 과정

제 실험 대상(?)을 바탕으로 약 한 달 동안 데이터를 모았습니다.
30일 정도를 기준으로 잡은 이유는 인과나 상관 관계를 탐색하기 위해

최소한의 표본 규모를 확보하려는 목적이었습니다.

통계적으로도 보통 30개 정도의 표본이 모이면 기본적인 분포 특성을 살펴볼 수 있는

최소 단위로 자주 활용됩니다.

그리고 데이터의 전처리와 결과 분석에는 이전 글과 마찬가지로 ChatGPT와 Gemini를 함께 사용했습니다.

이번 글에서는 자연스럽게 두 AI가 데이터를 해석하는 방식의 차이도 함께 살펴볼 수 있습니다.

결과적으로 '데이터 전처리와 분석'에는 Gemini를 '논리적 서술'에는 ChatGPT를 추천합니다.

흰 스크린이 ChatGPT이고 검은 스크린이 Gemini입니다. 둘 다 유료 모델을 사용하고 있습니다.

(1 단계) RAW 데이터를 그냥 다주기

수집해온 데이터를 분석 프롬프트 요청과 함께 전달했습니다.

이미 26년 3월 현재 시점에서 버전 관계없이 AI 툴의 분석 테크닉 능력은 인간을 한참 앞섰기 때문에

엄청난 양의 빅데이터가 아니라면 그냥 파일 자체를 줘도 됩니다.

(최근에는 Agent 기반 환경에서 파일을

직접 연결하여 분석을 진행하는 방식도 점차 자리를 잡아가는 것 같고,

다음 글에서는 MVP 만들기를 AI agent 로 수행하는 것을 다룹니다.)

저는 개인적인 사용 경험에서 파일 읽기가 잘 안되는 경우들이 있어

'파일' 업로드와 함께 '채팅 내 텍스트'로 둘 다 줍니다.

LLM 특성상 채팅의 가장 처음에 준 데이터가 이후의 채팅 맥락을 좌우하기 때문에

초기 데이터는 일종의 설정값으로 매우 중요합니다.

(이 때는 전적으로 AI를 신뢰, 프라이버시 정보 가치는 어디로...)

제미나이가 아주 잘 분석해준다

이것은 중간 과정에서의 실제 대화 캡처로,

15일 수집, 20일 수집, 30일 수집 단위로 계속 재재재분석을 했습니다.

(수집만 하면 너무 지루해서)

일단 제미나이는 이렇게 raw 데이터 셋만 가지고, (사실 스키마 정의를 안줘도 됩니다)

기본 분석 결과를 매우 깔끔하게 정리해줍니다.

그런데 제미나이의 분석 결과에 의심이 듭니다.

(2단계) 초기 분석(AI의 채팅 대답)을 의심하기

아까 위에서 설명했듯이 수집의 핵심 전략은 '태그 방식'의 수집이었습니다.

그래서 그냥 줄글이 많고, NaN, Null의 결측값도 많습니다.

제가 볼 때는 지금 수집된 데이터 자체는 전혀 전처리가 안된 상황입니다.

그런데 결과까지 딱딱 도출해버리니, 별로 신뢰가 안갑니다.

읽어보니, 제미나이의 결과에는 논리 점핑이 있습니다. 그래서 의심을 해야 됩니다.

그래서 챗지피티에게도 동일한 데이터를 주고, 이 데이터 셋이 너무 복잡하지 않냐고 따졌

모델의 타당성을 평가해보라고 했습니다.

모델의 타당성을 짚으라고 했더니 통계적 한계를 짚어준다

그리고 냅다 일단 제미나이한테 다시 전달했습니다. 그러자 당연히(?) 프롬프팅에 맞춰 대답을 수정합니다.

제미나이의 답변 톤은 허황되고 뭔가 아첨꾼의 느낌이 든다;;

(3단계) 사람이 방향성을 정한다

일단 전처리부터 수행하는 것으로 다시 진행을 해보기로 했습니다.

프롬프팅도 미리 설정하지 않고 프롬프트를 짜기 위한 가이드부터 시작했습니다.

위와 같이 전처리의 전략을 짜는데에 매우 큰 도움을 줍니다.

전처리의 과정을 정확히 모르는 사람일지라도 AI를 통해 방법을 익힐 수 있고,

전문가도 일일이 해야 했던 일을 단순히 명령한 뒤, 검토하는 방식으로 엄청난 시간을 단축할 수 있습니다.

그렇지만 일을 시키는 사람이 '전처리'를 해야 한다라는 방향 자체를 모르면 의미가 없습니다.

* [AI 데이터 분석 활용의 마음가짐] AI에게 지시를 할 때에는...

LLM 활용에서는 대화를 길게 이어가지 않고 Task를 계속 세밀하게 쪼개가는 것이 핵심이 됩니다.

전체 작업의 맥락은 '사람'만이 기억할 수 있기 때문에

대화형 AI의 경우, 정말 사람같은 협력자 혹은 직원이라고 생각하면 안됩니다.

(AI 윤리 문제로 긴 채팅에서의 맥락 소실이 강화된 것으로 보입니다.

AI는 대화의 패턴과 특이(중요) 정보를 기억할 뿐 사람의 요청과 대화를 모두 기억하지는 않으며

이것은 프로젝트를 따로 운영하거나 반복 설정을 주어도 그렇습니다.)

개인적으로는 AI가 '매번 처음 만나는 알바'라고 생각하는게 효율적이라고 봅니다.

어떤 차이냐면 예를 들어 내가 주인인 카페에 카페 알바생을 6개월만에 만났습니다.

'우리 지난 번에 라떼 새로운 메뉴 만들었잖아 기억하지?' 라고 하면

사람 알바생은 '아~ 그랬던 것 같아요, ' 라고 경험을 기억합니다.

그런데 AI는 경험에 대한 기억이 없고, '데이터'에 대한 기록만 있습니다.

'맞아! 민트라떼지. 내가 레시피까지 차근차근 알려줄게' 라고 대답하는 겁니다.

이 때 민트라떼가 아니라 '시나몬'라떼 였는데....라는 것을 기억하는 것은 사람이라는 것입니다.

따라서 질문을 '우리 이제 시나몬라떼를 만들어보자. 시나몬라떼의 레시피는 어떻게 될까?'라고

처음 만나는 사이인데, 명확히 요구하는 사항에 대한 답변을 유도하는 형태로 물어야 됩니다.

그러면 AI는 이전에 채팅에서 시나몬라떼의 레시피를 논의했던 부분 정보들을

다시 불러오는 식으로 대답합니다.

6. 반복적인 분석 과정

위와 같이 전처리 전략(계획)을 훑어보고,

이를 검토 수정해 아래와 같이 전처리 파일을 새로 생성할 것을 요청했습니다.

제미나이는 데이터 분석과 처리에 용이하다.

전략이 확정되면 곧바로 실제 파일 생성으로 이어집니다.

제미나이는 구글 워크스페이스라는 오피스 생태계를 기반으로 하기 때문에

챗지피티도 파일 생성이 되는데, 개인적으로 효율성이나 완성도가 제미나이보다 떨어지고,

구글의 호환성을 능가하기 쉽지 않습니다.

(4단계) 의심하기-방향성 결정하기의 반복 작업

정리한 데이터를 살펴보고, 다시 한번 전처리를 했습니다.

그 이유는 아까 위에서 짚었던 분석 기준 '시차, 지행 지표'의 반영을 위해서 입니다.

이 때도 마치 처음 만나는 사이처럼,

왜 해당 요청을 수행하라고 하는 것인지 맥락을 다 풀어서 의도를 길게 전달합니다.

그 결과로, 앞서 수행했던 EDA와 함께 모든 변수 간 상관관계, 인과관계의 분석 결과도 요청해 받았습니다.

여기서는 중간 과정이 생략되어 있는데,

앞 서 말한 것처럼 15일, 20일, 30일 기반으로 위의 4단계의 과정을 계속 반복했고

또 초기에는 가설 모델 목표인 연관 분석을 위주로 수행을 했습니다.

그 과정에서 결과 변수로 '수면'을 잡는 것이 좋지 않다는 결론을 얻었고

데이터셋이 많지 않기도 하고, 가설 모델이라 새로 모델을 잡기로 하고

주요 변수 선별부터 다시 했습니다.

7. 기존 가설 모델의 폐기

변수 선별에는 단계적 후진법을 사용했습니다.

결과를 보면, '수면 시간'은 노이즈로 분류가 되었습니다. 그 이유는 사실 휴먼 에러로 보입니다.

(시간을 집사가 관측해 기록한다는 것은 도전적으로 시도해보았지만, 역시 정확도 측면에서 어려워보입니다.

이는 서비스 설계에서도 반영될 수 있습니다.)

8. 실제 데이터 기반 가설 재설정

데이터 분석을 해본 결과 그리고 제가 직접 긴 기간 고양이의 데이터를 수집해보면서

느꼈던 부분을 반영해보면

1. 놀이 시간은 고양이의 이상 행동(뜯기, 울기 등)을 발생시킨다.

2. 고양이마다의 평소 루틴이 있고 또 그 루틴 자체는 고양이의 성격(성향)을 반영한다.

이 두가지 정도를 체감했고, 이 부분은 기존에 수의사분들도 자주 얘기를 했던 부분이라

거의 기정 사실처럼 생각되었습니다.

하지만 실제 데이터의 결과도 그러한지, 전처리된 데이터 셋을 바탕으로 분석을 다시 해보았습니다.

9. 지행 지표(Lagging Indicator) 고려

그리고 이 부분에서도 '지행 지표'의 반영을 잊지 않고

오늘 데이터로 오늘 결과 검증, 오늘 데이터로 내일 결과 검증 두 가지를 모두 수행하도록 했습니다.

이것은 1차적인 결과인데, 논리적으로 맞지 않는 부분이 있다.

위의 결과를 보면 일단 지행 지표로 만드는 것이 모델 타당성 측면에서는 좋아보입니다.

그런데 결과를 보면 놀이시간과 이상행동 사이에 유의한 상관관계가 나타났는데,

여기서 이상한 점이 '양의 상관관계'라는 점이었습니다.

놀이 시간이 늘어날 수록 이상 행동이 늘어난다는 것인데, 이것은 기존 도메인 지식과 어긋나기 때문입니다.

(쉽게 얘기하면 많이 놀아줄수록 고양이가 짜증을 낸다)

따라서 결과 (의심하기) - 전처리 (요청하기) - 가설 검증을 여러번 반복했고

또 전처리를 하는 과정에서 '고양이에게는 루틴'이 있다는 기존 대명제를 최대한 반영했습니다.

이렇게 여러번 반복해도 사실 처리 속도가 너무 빨라서 1일 안에 다 끝납니다.

12. 최종 모델 정리

이러한 수집-분석의 반복 과정을 통해 최종적으로 실제 데이터를 반영하여

데이터 모델링 아키텍처와 데이터 파이프라인을 완성했습니다.

데이터 아키텍처(Data Architecture)는
데이터를 어떤 구조로 저장하고 어떤 변수들을 중심으로 분석할 것인지에 대한 전체 설계입니다.

예를 들어 어떤 데이터를 기록할 것인지, 어떤 변수가 핵심 변수인지,
그리고 데이터들이 서로 어떤 관계를 가지는지를 정리한 데이터 구조의 설계로

이번에는 실제 데이터 기록과 관측을 대상으로 했다는 점에서 베이스라인 모델이라고 할 수 있습니다.

반면 데이터 파이프라인(Data Pipeline)은
데이터가 실제로 수집되고, 정리되고, 분석까지 이어지는 흐름 전체를 의미합니다.

데이터 파이프라인은 서비스의 유저 플로우와 연결될 수 있습니다.

모델 v1.0이 고양이의 ‘잠(Sleep)’이라는 특정 상태를 관찰하는 데 초점을 맞추었다면,

모델 v2.0은 이 수면 상태를 고립된 지표로 보기보다
고양이의 다양한 활동과 환경을 포함한 ‘행동(Behavior)’이라는

컨텍스트 속에서 이해하도록 확장되었습니다.

또한 입력 변수 역시 기존의 놀이, 식사, 환경과 같은 제한된 항목에서 벗어나,
실제 서비스 사용 상황을 고려한 사용자 기록 중심의 컨텍스트 데이터까지 포함하도록 확장되었습니다.

여기서는 구체적인 기술적 설명을 모두 다루기 어렵지만,
실제 가설 모델을 바탕으로 데이터를 수집한 뒤 이를 바탕으로

지표를 설계하고 데이터를 정리하는 과정을 통해 알고리즘 단계까지는 아니더라도
데이터 수집 → 전처리 → 분석으로 이어지는 기본적인 데이터 분석 구조를 정리할 수 있었습니다.

이 과정을 정리하여 모델정의서 v2.0을 완성했습니다.

이 모델정의서를 바탕으로 MVP를 만들어보겠습니다.

이제는 드디어(?!) 서비스 기획으로 넘어가게 되겠습니다