pile·
DB / 데이터·매드업매드업·

선형 모델과 회귀분석의 직관적 이해 (1)

머신러닝·딥러닝에 밀려 "올드 스쿨" 취급받는 선형 모델이 왜 여전히 필수인지를 짚고, 선형성의 정의부터 바로잡는 연재 1편이다. 코드나 개념 나열이 아니라 직관을 목표로 한다고 미리 밝힌다.

핵심 포인트
  • 딥러닝을 포함한 최신 기법들은 하늘에서 떨어진 것이 아니다. 선형 모델에 커널을 씌워 비선형으로 매핑하거나, Tree Model 처럼 직선으로 파티션을 나눠 비선형 패턴을 만드는 식으로 일반화한 것이다.
  • 그래서 비선형 모델링을 잘하려면 선형 모델과 회귀분석의 이해가 먼저다.
  • 핵심 정의: 모델이 선형이라는 것은 **추정해야 할 파라미터에 대해** 선형변환을 만족한다는 뜻이다. 가지고 있는 변수는 일차식일 필요가 없다.
  • 그래서 제곱·세제곱 항이 들어가도 파라미터에 대해 선형이면 선형 모델이다. 이 지점을 가장 흔한 오해로 짚는다.
  • 예시 6개 중 마지막 하나를 뺀 다섯 개가 선형이거나 선형으로 변환 가능한 모델이라는 문제 제기로 글을 연다.
상세 정리
  • 역사적 배경으로 18세기 말 가우스가 정규분포와 최소제곱법을 만든 이후 선형 모델이 다양하게 진화해 왔음을 든다.
  • 20세기 이후 컴퓨터 계산과 모델링 기법의 발전으로 빅데이터 시대의 머신러닝·딥러닝이 각광받게 된 흐름도 함께 정리한다.
  • 문제의식: 데이터 분석가·사이언티스트를 지망하거나 이미 현업에 있는 상당수가 선형 모델과 회귀분석을 "단순한 것" 으로 여기는 경향이 있다.
  • 선형변환의 정의: 실변수 벡터공간에서 벡터 X, Y 와 스칼라 a 에 대해 특정 조건을 만족하는 함수 T 로 정의한다.
  • 그 조건을 두 성질로 나눠 이름 붙인다. 벡터를 각각의 식으로 분리해 계산할 수 있는 성질이 가산성(Additivity), 스칼라를 식 밖으로 뺄 수 있는 성질이 동질성(Homogeneity)이다.
  • 예시 (1)은 다중 선형회귀모델(Multiple Linear Regression Model)을 나타낸 식으로 선형성이 자명하며 다음 글에서 다룰 예정임을 예고한다.
  • 연재 방향을 명시한다. 앞으로 데이터 사이언티스트가 알아야 할 선형 모델과 머신러닝 기법을 개념이나 코드 예제보다 핵심을 찌르는 직관 위주로 다룬다.
왜 읽나회귀분석을 안다고 생각했지만 "왜 제곱항이 있는데도 선형인가" 에 답하지 못하는 데이터 분석가에게 정의부터 다시 잡아 준다.
매드업
매드업 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

    여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.

    요약 이어보기
    #data-pipeline#kafka#postgres+2
  2. DB / 데이터·vercel-blogVercel Blog·

    모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

    Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

    요약 이어보기
    #database-migration#zero-downtime#redis+2
  3. DB / 데이터·channel-talk채널톡·

    DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

    채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.

    요약 이어보기
    #migration#dynamodb#hot-partition+5