Liked

• 비행기편 지연 데이터를 분석하면서 하나의 흐름으로 정리하면서 보는 재미가 있었다. 단순히 숫자만 보는 게 아니라 어떤 항공사가 왜 지연이 많은지를 하나씩 파악해 나가니까 점점 흥미가 생겼다.
  
• carrier, atc, weather 각각 따로 비교하고 막대그래프랑 선그래프 같이 그려보면서 아 이 항공사는 운항 수는 많은데 생각보다 지연은 적네? 같은 걸 직접 눈으로 확인할 수 있었던 게 좋았다.
  
• 결측치를 무작정 제거하거나 무시하지 않고 ‘지연률 3종 모두 결측’이라는 상황적 의미를 먼저 파악한 후 삭제 여부를 결정했다.
  
• describe() 표를 해석하면서 각 항공사의 지연률 통계가 무엇을 말해주는지 단순히 수치 나열이 아니라 스토리로 정리해낼 수 있었다. carrier, atc, weather 각각의 특성과 항공사별 분포가 달라지는 부분에서 왜 이 값이 중요한가를 설명할 수 있게 된 점이 큰 수확인 것 같다.
  
• 결측치 비중이 적어도 보고서에 내가 처리한 근거를 명확히 문장으로 작성하면서 읽히는 보고서를 작성하는 시각을 얻었다.

Learned

• pd.cut()으로 구간을 나눠서 도수분포표처럼 시각화할 수 있다는 거 처음 알았고

  그냥 value_counts()만 쓰는 것보다 훨씬 시각적으로 보기 좋다는 것도 배웠다.
  

• twinx()로 막대그래프랑 선그래프를 같은 x축에 겹쳐서 표현하는 것도 해봤는데

  이걸로 지연률과 전체 항공편 수를 한 번에 비교할 수 있는 게 신기하고 유용했다.
  

• 'tab:blue', 'tab:orange' 같은 색상 표현도 있다는 걸 알게 돼서 그래프 색감 조절할 때 도움될 것 같다.

• import 방식에서 from ... import ...와 import ... as ...의 차이를

  이론이 아니라 코드 흐름 속에서 명확히 이해하게 되었다.
  

• dropna(subset=[...])을 이용해 조건부 결측치 제거를 실제 분석에서 자연스럽게 사용할 수 있게 되었다.

  지금까지는 그냥 전체 dropna()만 썼던 나에게 정제된 도구가 생긴 느낌이었다.
  

• 분석 보고서는 데이터를 읽을 줄 모르는 사람들에게 설명하는 도구이다.

Lacked

• 처음엔 무슨 그래프부터 그려야 할지 순서가 헷갈렸고,

  변수별로 뭘 분석해야 하는지도 정리되지 않은 상태에서 시작해서 약간 헤맸다.
  

• 각 항공사의 지연 원인을 조금 더 깊이 파고들고 싶었는데

  carrier, atc, weather를 단순히 평균값만 보고 끝낸 게 살짝 아쉬웠다.
  

• 통계량과 데이터를 보면 그냥 그렇구나… 싶었는데 계속 생각을 해봐야 하는게 조금 힘들었다.

• 처음에는 describe() 표를 봐도 수치 하나하나가 어떤 의미를 가지는지 해석이 잘 안됐다.

  IQR, 최대값 같은 값을 단순히 크다/작다로만 보려다 이 값이 왜 커졌는지, 어떤 구조가 숨어있는지까지 생각하는 게 힘들었다.
  

• 결측치를 무시하려는 마음이 잠깐 들었던 것도 반성해야 할 부분이다.

  데이터 수가 적다는 이유만으로 처리를 하지 않을 건지 고민 없이 판단하려 했다는 건

  앞으로 예측에서 실수를 만들 수 있는 여지였다고 생각한다.
  

• 보고서에서 자연스러운 문장을 작성하려다 보니 글을 쓰는 것도 꽤 어려웠다.

  내용을 잘 포함하면서 이해하기 쉽게라는 기준을 유지하는 데 시간이 꽤 걸렸다.

Longed for

• 요일별, 시간대별로도 지연이 몰리는 패턴이 있는지 분석해보고 싶다.

• 분석한 내용을 기반으로 한눈에 보기 쉽게 항공사별 정리 리포트처럼 만들어보는 것도 해보고 싶다.

• 더 힘들겠지만.. 항공사별 지연률을 시간대/요일별로 나눠보면 더 재미있는 인사이트가 나올 것 같다.

  특정 항공사는 주말 밤에 지연이 많다든지 어떠한 시간대만 이슈가 집중된다든지 하는 패턴이 궁금해졌다.
  

• 보고서 시각화도 단순히 subplot이 아니라 대비를 더 강조할 수 있는 색상, 인포그래픽 스타일로 발전시키고 싶은 욕심도 생겼다.

  시각화 자체도 잘 읽히게 하는 게 목표라고 생각한다.

프로젝트

툭툭 프로젝트의 전체 구조와 문제 정의를 정리하면서 왜 우리가 이 시스템을 만들고 있는지를 다시 되짚는 시간이었다.
가장 기억에 남는 건 상담사 중심의 시선으로 문제를 재구성해본 것이다.

초반에는 사용자인 고객 중심 문장이 많았는데 회의와 피드백을 통해

지금 이 시스템은 상담사에게 보여지는 시스템이다
라는 점을 명확히 하면서 문장의 방향과 용어 선택도 많이 바뀌었다.

또 하나 의미 있었던 건 디자인 관점에서 지나치게 AI가 모든 걸 대신하는 것처럼 보이지 않게 하기를 고민한 점이라 생각한다.
툭툭은 상담사를 돕는 보조자라는 메시지를 전달해야 하니까
그런 부분을 시각적으로 그리고 슬로건이나 표 형식에도 녹이려고 애썼다.

작업을 하면서 정리했던

문제 상황 → 해결방식 → 기술 요소 흐름
이 자연스럽게 잡혀가서 한층 팀 프로젝트의 아이덴티티가 명확해진 느낌이다.

피그마 디자인 시도에 이어 툭툭 시스템이 실제로 어떻게 동작하는지를 설명할 수 있는 흐름도(Flow Diagram)를 그리는 작업에 집중했다.
단순한 기능 나열이 아니라

툭툭이 상담사의 어떤 업무를 어떻게 도와주는가?를 스스로 납득할 수 있어야 설명과 특색이 명확해지기 때문에 그걸 시각적으로 정리하는 게 오늘의 가장 큰 목표였다.

중간중간 헷갈렸던 건
이 기능은 사용자에게 보이는 건가, 백엔드 처리인가?
같은 부분이었는데 gpt 한테도 물어보고 직접 그리면서 만드는 시스템을 더 깊게 이해하게 되는 경험이었다.

느낀 점
흐름을 명확히 잡는 게 먼저라는 것.
오늘은 이 기술이 이 시점에 이런 방식으로 상담사에게 도움이 된다는 설명이 가능해지는 느낌!