[프로젝트 #2-9] 두 번째 프로젝트 발표회가 끝났다(feedback).

프로젝트 마지막 날, 발표회가 끝나고 피드백을 받았다.

---

발표 FeedBack

- Kruskal-Wallis test(비모수 검정)을 사용해보았으면(다양한 검정 사용 차원?) 더 좋았을 것

* price는 표본이 많고, 로그변환 후 정규성 충족이 되어서 아닌 것 같고, 지역을 검정하는 부분에서 표본이 적은 지역들에 대한 검정을 말씀하셨던 걸까?

- 표본 자체가 너무 작으면 통계량이 적어 nan 값으로 보여짐. 표본수가 몇갠지 판단하고 크러스카-월리스를 사용하였다면 좋았을 것.

Kruskal–Wallis나 ANOVA 계산 시 그룹별 표본 수가 너무 작으면 분산을 계산할 수 없어 NaN이 발생한다.
튜터님이 이 말을 한 이유는, “어떤 변수는 그룹별 숙소 수가 적었을 것 같다 → 그래서 Kruskal–Wallis를 썼다면 그 문제를 직접 체험했을 것” 이라는 맥락에서 언급한 것입니다.
즉, 데이터의 불균형(예: Staten Island 숙소 수 적음)에 대한 인식과, 통계검정의 한계 설명이 필요하다는 지적입니다.

 
- 청취자가 '효과 크기'를 모를 수 있으니 이에 대한 설명과 크기 기준이 언급되었으면 더 좋았을 것

* cohen's d 는 두 집단 평균의 차이가 얼마나 큰지를 표준화하여 나타내는 효과 크기 지표
두 집단의 평균 차이를 통합표준편차(pooled standard deviation)로 나누어 계산하며, 이를 통해 연구마다 다른 스케일을 가진 데이터를 비교할 수 있다. 효과 크기가 클수록 두 집단의 차이가 크고, 작을수록 차이가 작음을 의미한다.
아래 코드에서 실제 프로젝트에서 진행했던 코드(슈퍼호스트와 일반호스트 비교)를 확인해 보면서 다시 한 번 정리하자.
우리는 아래와 같이 4단계 범위로 크기 효과를 정의했다.

# Cohen's d 효과 크기
pooled_std = np.sqrt((superhost.var() + normalhost.var()) / 2)
cohens_d = (superhost.mean() - normalhost.mean()) / pooled_std
abs_d = abs(cohens_d)

if abs_d < 0.2:
    effect = "매우 작은 효과"
elif abs_d < 0.5:
    effect = "작은 효과"
elif abs_d < 0.8:
    effect = "중간 효과"
else:
    effect = "큰 효과"

print(f"Cohen's d = {cohens_d:.3f} ({effect})")

>>> Cohen's d = -0.162 (매우 작은 효과)

- 신뢰구간 같은 경우도 넣어주면 해당구간을 확실하게 알려줄 수 있을 것 같다.

단순히 평균값 비교나 p값만 제시하면, “실제 가격이 어느 구간에 있을 가능성이 높은가?”를 보여주지 못 한다.
따라서 95% 신뢰구간을 제시하면, “추정치의 불확실성”을 더 명확히 보여줄 수 있습니다. (예: 95% CI [4.85, 5.10])
특히, 발표 주제가 “가격 가이드라인 제시”였기 때문에, 신뢰구간을 포함하면 훨씬 실무적으로 설득력 있었을 것이다.

 
- 그래도 가격 책정에 대한 불확실성을 통계 가설검정을 통해 근거를 쌓아가며, "가격 가이드라인 제시" 모델을 만들었다는 점에서 좋았다는 피드백을 받았다.
 
 
 

다른 조 피드백

- 시간이 부족하여 전처리 과정을 발표자료에 넣지 못했을 경우라면, 장표 맨 뒤 부록으로라도 넣으면 좋음.
- 함수의 옵션: 어떤 이유에서 그 옵션을 적용했는지, 핸들언노운:ignore( 새 범주를 0으로 실행하려고 )
- etc...
 
 
 

오늘의 회고

1. 발표
발표회를 끝나고 느꼈던 점은 해당 프로젝트의 도메인에 대한 이해가 정말 중요하다는 것을 느꼈다. 다음에는 프로젝트 주제를 선정했다면 도메인에 대한 정보를 최대한 많이 찾아야 겠다는 생각을 했다. 
 
2. 개인
프로젝트 시작 전, 가이드 세션에서 보여주셨던 전처리 과정에서 파생변수를 다수 생성을 하셨었다. 그래서 이번 프로젝트에서 우리팀에서 생성해 볼 수 있는 파생변수가 무엇이 있을지에 대해서 많은 고민을 했다. 하지만 당시 답이 나오지는 않았고 튜터님에게 질문하여 받은 답변은 "도메인에 대한 깊이 있는 이해"였다. 이해가 있어야만(물론 분석 목적도 분명해야 한다.) 무엇이 중요한지 알고 분석 목적에 맞게 활용할 수 있는 변수도 만들어 낼 수 있다는 것이다. 이 점을 꼭 가지고 가야겠다고 다짐하는 순간과 과정이 되었다. 
 
3. 팀
여러 사람이 모이면 물론 다 같을 수는 없다. 하지만, 나와 다를 뿐 틀린 것은 아니다. 이번 프로젝트가 잘 마무리 된 것은 팀원 한 명 한 명의 장점과 사소하더라도 소중한 의견들이 모여졌기 때문이라고 생각한다.
장점을 하나씩 기억을 되짚어보면:
일정을 철저히 관리하고 소통이 적극적이며 빠른 판단으로 의견을 종합해 아이디어를 던져내는 점, 묵묵히 자신의 소임을 다하고 타인의 의견을 모두 수용하는 점, 평소에는 소용하지만 중요한 순간에 자진해서 역할을 더 맡으며 도움이 되려고 하는 점 등
이렇게 다양한 부분들이 모여서 불협화음 없이 잘 마무리 되어서 다행이다. "모두 고생하셨습니다." 
 
 
 

내일 할 거

- 실전 프로젝트 학습주간 발제 세션
- taebleau 세션
- QCC 코딩테스트 😵‍💫🤪
- API를 활용한 크롤링 세션
- QCC 해설 세션