AI 시스템 설계

AI 시스템 설계 핵심 질문 주관식 답변 예시

1. 사용자의 구매 패턴이 코로나19 이후 완전히 달라져 기존의 추천 모델이 더 이상 맞지 않는 상황이 발생했습니다. 이는 '데이터 드리프트'와 '개념 드리프트' 중 무엇에 더 가까우며, 그 이유는 무엇인가요?

정답: **개념 드리프트(Concept Drift)**에 더 가깝습니다.

핵심 설명: 이 상황은 단순히 유입되는 데이터의 특성이 바뀐 것을 넘어, '상품을 추천하는 기준' 또는 '사용자가 상품을 선호하는 근본적인 관계' 자체가 변했기 때문입니다.

1. 개념 드리프트의 정의: 개념 드리프트는 입력 변수 X(사용자 정보, 상품 정보)와 목표 변수 y(구매 여부, 선호도) 사이의 통계적 관계, 즉 조건부 확률 분포 $P(y|X)$가 변하는 현상을 의미합니다.
2. 시나리오 분석: 코로나19라는 외부 환경의 급격한 변화로 인해 사용자들의 라이프스타일이 바뀌었습니다.
   • 이전: '여행용품', '외출복'(X)을 구매하는 행동이 '높은 선호도'(y)를 의미했습니다.
   • 이후: '홈트레이닝 기구', '밀키트'(X)를 구매하는 행동이 '높은 선호도'(y)를 의미하게 되었습니다.
   • 이처럼 동일한 사용자라도 선호하는 상품의 '개념'이 바뀌었으므로, 모델이 예측해야 할 X와 y의 관계 자체가 변한 것입니다.

헷갈리기 쉬운 점 (데이터 드리프트와의 차이):

• **데이터 드리프트(Data Drift)**는 입력 데이터 X의 분포, 즉 $P(X)$가 변하는 것입니다. 예를 들어, 특정 연령대의 사용자가 갑자기 많이 유입되거나, 특정 카테고리의 상품이 대량으로 추가된 경우가 해당됩니다.
• 만약 단순히 '홈트레이닝 기구' 상품의 재고가 많아져서 추천 후보군에 많이 등장하는 상황이라면 데이터 드리프트에 가깝겠지만, 이 질문의 핵심은 사용자의 '구매 패턴' 즉, 선호도 기준이 바뀐 것이므로 개념 드리프트로 해석하는 것이 더 정확합니다.

2. 금융 시스템에 매우 중요한 업데이트를 배포해야 합니다. 서비스 중단은 절대 허용되지 않으며, 문제 발생 시 즉시 이전 버전으로 되돌릴 수 있어야 합니다. '카나리 배포'와 '블루-그린 배포' 중 어떤 전략이 더 적합할까요?

정답: 블루-그린 배포(Blue-Green Deployment) 전략이 더 적합합니다.

핵심 설명: 제시된 요구사항인 '무중단 배포'와 '즉각적인 롤백'을 가장 효과적으로 만족시키는 전략이기 때문입니다.

1. 요구사항 분석:
   • 무중단(Zero Downtime): 업데이트 중에도 서비스는 계속 정상적으로 제공되어야 합니다.
   • 즉각적인 롤백(Instant Rollback): 배포 후 문제가 발견되면 지체 없이 이전의 안정적인 버전으로 되돌릴 수 있어야 합니다.
2. 블루-그린 배포 방식:
   • 블루(Blue): 현재 운영 중인 실제 서비스 환경.
   • 그린(Green): 새로운 버전을 배포한, 블루 환경과 동일한 복제 환경.
   • 배포 과정: 그린 환경에 새 버전을 배포하고 충분히 테스트한 뒤, 라우터 설정을 변경하여 모든 사용자 트래픽을 블루에서 그린으로 한 번에 전환시킵니다.
3. 적합성: 이 방식은 트래픽 전환이 순간적으로 일어나므로 서비스 중단이 발생하지 않습니다. 또한, 심각한 문제 발생 시 라우터 설정만 이전(블루)으로 되돌리면 되므로, 시스템 전체를 재배포할 필요 없이 즉각적인 롤백이 가능합니다.

헷갈리기 쉬운 점 (카나리 배포와의 차이):

• 카나리 배포는 일부 사용자(예: 1%)에게만 새 버전을 먼저 노출시켜 점진적으로 안정성을 확인하는 전략입니다. 이는 일부 사용자에게는 잠재적 문제가 있는 버전이 서비스될 수 있음을 의미합니다. 모든 거래의 안정성이 중요한 금융 시스템에는 부적합할 수 있습니다.
• 또한, 카나리 배포는 문제가 생겼을 때 트래픽을 다시 점진적으로 이전 버전으로 되돌려야 하므로 '즉각적인 전체 롤백'이라는 요구사항을 충족하기 어렵습니다.

3. '학습-서빙 스큐'가 발생하는 구체적인 시나리오를 한 가지 설명하고, '피처 스토어'가 이 문제를 어떻게 해결해 주는지 설명해 보세요.

답변:

1. 학습-서빙 스큐(Training-Serving Skew) 발생 시나리오:
   • 상황: 사용자의 '최근 7일간 평균 장바구니 금액'을 피처로 사용하는 추천 모델을 개발한다고 가정합니다.
   • 학습 환경: 데이터 과학자는 모델 학습을 위해 데이터 웨어하우스에 있는 과거 로그를 Python Pandas 라이브러리를 사용하여 일 단위 배치(Batch)로 계산합니다. 이때, 주말 동안 활동이 없는 사용자의 경우 평균 계산 시 0으로 처리했습니다.
   • 서빙 환경: 실시간 추천을 위해 데이터 엔지니어는 Java 기반의 스트리밍 애플리케이션에서 실시간으로 들어오는 로그를 처리합니다. 이 시스템에서는 활동이 없는 경우 데이터 자체가 존재하지 않아 평균 계산에서 **제외(NULL 처리)**했습니다.
   • 스큐 발생: 이처럼 학습과 서빙 환경에서 피처를 계산하는 로직(코드, 라이브러리, 데이터 소스, 처리 방식)이 달라, 동일한 사용자에 대해서도 다른 피처 값이 생성됩니다. 모델은 이 차이를 인지하지 못하고 잘못된 예측을 하게 되는데, 이것이 바로 학습-서빙 스큐입니다.
2. 피처 스토어(Feature Store)의 해결 방안: 피처 스토어는 피처 생성 로직을 중앙화하여 이 문제를 근본적으로 해결합니다.
   • 중앙화된 피처 로직: '최근 7일간 평균 장바구니 금액'을 계산하는 로직을 한 번만 정의하여 피처 스토어에 등록합니다.
   • 온라인/오프라인 저장소: 피처 스토어는 이 로직을 사용하여 계산된 피처 값을 **오프라인 스토어(Offline Store)**와 온라인 스토어(Online Store) 두 곳에 동시에 저장합니다.
     • 오프라인 스토어: 대용량의 과거 피처 데이터를 저장하며, 모델 '학습'에 사용됩니다.
     • 온라인 스토어: 실시간 서빙에 필요한 최신 피처 값을 저장하며, 모델 '추론'에 사용됩니다.
   • 일관성 보장: 모델 학습 시에는 오프라인 스토어에서, 실시간 추론 시에는 온라인 스토어에서 피처를 가져다 씁니다. 두 데이터는 완전히 동일한 로직으로 생성되었으므로, 환경 차이로 인한 스큐가 발생하지 않습니다.

4. 실시간 결제 시스템에서 중복 결제를 방지하기 위해 '멱등성'이 왜 필수적인지 설명해 보세요.

답변: 멱등성(Idempotency)은 동일한 요청을 여러 번 보내더라도 시스템이 항상 동일한 결과를 반환하도록 보장하는 성질입니다. 실시간 결제 시스템에서 멱등성이 필수적인 이유는 네트워크의 불안정성으로 인해 발생할 수 있는 중복 결제를 막아 사용자의 금전적 손실과 서비스 신뢰도 하락을 방지하기 위함입니다.

1. 문제 발생 시나리오:
   • 사용자 측면: 사용자가 통신 상태가 좋지 않은 곳에서 '결제' 버튼을 눌렀을 때, 응답을 받지 못해 버튼을 여러 번 중복해서 클릭할 수 있습니다.
   • 시스템 측면: 결제 요청이 서버에 전달되었으나, 서버의 응답이 사용자에게 도달하기 전에 네트워크가 끊기는 경우, 사용자의 앱은 결제가 실패했다고 판단하고 자동으로 재시도를 할 수 있습니다.
2. 멱등성의 역할:
   • 위와 같은 상황에서 멱등성이 보장되지 않는다면, 시스템은 중복된 요청을 모두 새로운 결제로 인식하여 사용자의 돈을 여러 번 출금하게 됩니다.
   • 멱등성이 보장된 시스템은 각 결제 요청에 **고유한 요청 ID(Idempotency Key)**를 부여하여 이를 해결합니다. 서버는 요청 ID를 확인하여 이전에 성공적으로 처리된 요청이라면, 추가적인 결제 로직을 실행하지 않고 첫 번째 성공 결과를 그대로 반환합니다.
   • 결과적으로 사용자가 버튼을 여러 번 누르거나 시스템이 요청을 재시도하더라도 결제는 단 한 번만 안전하게 처리됩니다.

 

배치 레이어 (Batch Layer) 스피드 레이어 (Speed Layer)

처리 방식	대용량 데이터를 묶어서 처리	실시간으로 스트리밍 처리
결과 속성	정확하고 완전한 결과	근사치, 임시 결과
속도	느림	매우 빠름
사용 목적	장기적, 정확한 분석	즉각적 반응, 실시간 모니터링
대표 기술	Hadoop, Spark	Kafka, Flink, Storm

 

 

 

람다(Lambda) 아키텍처와 카파(Kappa) 아키텍처, 시험에 정말 자주 나오는 중요한 개념이죠! 두 아키텍처가 왜 등장했고, 어떤 문제를 해결하는지, 그리고 어떤 점이 헷갈리기 쉬운지 핵심만 쏙쏙 알려드릴게요.

배경: 왜 이런 아키텍처가 필요할까요?

빅데이터 시스템은 크게 두 가지 요구사항을 동시에 만족시켜야 할 때가 많습니다.

1. 배치 처리 (Batch Processing): 전체 데이터를 대상으로 깊이 있고 정확한 분석 (예: 일일/주간 리포트, 모델 학습)
2. 실시간 처리 (Real-time Processing): 지금 막 들어온 데이터를 빠르게 처리하여 즉각적인 결과 제공 (예: 금융 사기 탐지, 실시간 추천)

이 두 가지 상반된 요구사항을 하나의 시스템에서 우아하게 처리하기 위해 등장한 것이 바로 람다 아키텍처입니다.

---

1. 람다 아키텍처 (Lambda Architecture) 🏛️

한 줄 요약: "정확하지만 느린 배치(Batch)"와 "빠르지만 덜 정확할 수 있는 실시간(Real-time)"이라는 두 개의 길로 데이터를 처리한 뒤, 마지막에 합쳐서 보여주는 방식입니다.

마치 정확성을 위해 전체 역사를 담은 **'역사서'(배치)**를 쓰는 동시에, 지금 일어나는 일을 놓치지 않기 위해 **'뉴스 속보'(실시간)**를 계속 내보내는 것과 같습니다.

핵심 구조 (반드시 알아야 할 내용)

람다 아키텍처는 세 개의 레이어(Layer)로 구성됩니다.

1. 배치 레이어 (Batch Layer)
   • 역할: 모든 원본 데이터를 저장하고, 주기적으로 전체 데이터를 대상으로 복잡하고 정확한 계산을 수행합니다. (예: 6시간마다 전체 사용자 로그를 분석)
   • 결과: '배치 뷰(Batch View)'라는 마스터 데이터셋을 생성합니다.
   • 특징: 매우 정확하지만, 계산에 시간이 오래 걸려 결과가 나오는 데 지연(Latency)이 있습니다.
   • 수식 개념: View_batch = f(전체 데이터)
2. 스피드 레이어 (Speed Layer)
   • 역할: 배치 레이어의 계산이 끝날 때까지의 공백을 메우기 위해, 실시간으로 들어오는 데이터만을 빠르게 처리합니다.
   • 결과: '실시간 뷰(Real-time View)'라는 증분 데이터셋을 생성합니다.
   • 특징: 속도가 매우 빠르지만, 전체 데이터가 아닌 일부 데이터만 보기 때문에 정확성은 떨어질 수 있습니다.
   • 수식 개념: View_realtime = g(새로운 데이터)
3. 서빙 레이어 (Serving Layer)
   • 역할: 사용자의 요청이 들어오면, 배치 뷰와 실시간 뷰의 결과를 조합하여 최종 결과를 제공합니다.
   • 특징: 사용자에게는 두 뷰가 합쳐진, 정확하면서도 최신 데이터가 반영된 것처럼 보입니다.
   • 수식 개념: 결과 = Merge(View_batch, View_realtime)

헷갈리기 쉬운 내용 (장점 vs 단점)

• 장점:
  • 견고함 (Robust): 원본 데이터를 보존하므로, 언제든 전체 데이터를 다시 계산하여 오류를 수정할 수 있습니다.
  • 정확성과 속도: 배치와 실시간 처리를 모두 수행하여 두 마리 토끼를 다 잡습니다.
• 치명적인 단점:
  • 복잡성: 배치 레이어와 스피드 레이어에 각각 다른 로직을 가진 두 개의 코드 베이스를 개발하고 유지보수해야 합니다. 이는 상당한 개발 비용과 운영 부담을 유발합니다.

---

2. 카파 아키텍처 (Kappa Architecture) streamlined

한 줄 요약: "모든 것은 스트림(Stream)이다!" 람다 아키텍처의 복잡성을 해결하기 위해, 배치 레이어를 없애고 모든 것을 실시간 스트림 처리로 통일한 방식입니다.

마치 모든 것을 '뉴스 속보'로만 처리하고, 만약 '역사서'가 필요해지면 처음부터 모든 속보를 다시 재생(replay)해서 만들어내는 것과 같습니다.

핵심 구조 (람다와의 차이점)

1. 단일 스트림 처리 파이프라인:
   • 역할: 실시간으로 들어오는 데이터를 스트림 처리 엔진(예: Kafka, Flink)을 통해 처리하여 바로 결과 뷰를 업데이트합니다.
   • 특징: 코드 베이스가 하나로 통일되어 개발 및 유지보수가 매우 단순해집니다.
   • 수식 개념: View = h(이벤트 스트림)
2. 데이터 재처리 (Reprocessing):
   • 역할: 만약 로직을 변경하거나 과거 데이터를 다시 계산해야 할 경우, 저장된 이벤트 스트림의 처음부터 데이터를 다시 읽어와 동일한 스트림 처리 파이프라인을 통해 재처리합니다.
   • 특징: 람다 아키텍처의 배치 레이어가 하던 역할을 스트림 재처리로 대체합니다.

헷갈리기 쉬운 내용 (장점 vs 단점)

• 장점:
  • 단순함: 코드 베이스가 하나이므로 아키텍처가 단순하고 개발 및 운영이 용이합니다.
• 단점:
  • 스트림 처리 시스템에 대한 높은 의존도: 스트림을 처음부터 빠르게 재처리할 수 있는 강력한 스트림 처리 시스템이 필수적입니다.
  • 재처리 복잡성: 전체 데이터를 재처리하는 데 여전히 많은 시간과 자원이 소요될 수 있습니다.

핵심 비교 정리

구분	람다 아키텍처	카파 아키텍처
구조	배치, 스피드, 서빙 3개 레이어	단일 스트림 처리 파이프라인
코드베이스	2개 (배치용, 스피드용)	1개 (스트림 처리용)
복잡성	높음	낮음
장점	견고함, 정확성과 속도 동시 만족	단순함, 개발/운영 용이성
단점	높은 복잡성, 이중 코드 관리 부담	스트림 시스템 의존도 높음, 재처리 비용

 

 

피처 해싱은

해시 함수를 사용하여 고차원의 범주형 피처를 미리 정해진 저차원의 벡터로 매핑합니다. 이 과정에서 일부 정보 손실(해시 충돌)이 발생할 수 있지만, 메모리를 효율적으로 관리할 수 있어 고차원 데이터에 매우 효과적입니다.

 

 

35. AI 기반 채용 서류 심사 모델을 개발 중입니다. 모델이 특정 학교 출신 지원자나 특정 성별의 지원자에게 불리한 예측을 하지 않도록, 모델 학습 단계에서부터 공정성을 확보하고자 합니다. 이를 위한 가장 직접적인 접근법은 무엇일까요?

 

 

---

적대적 디바이어싱(Adversarial Debiasing)

 

배경: "경찰과 위조지폐범" 게임

적대적 디바이어싱을 이해하는 가장 좋은 방법은 **'경찰과 위조지폐범'**의 경쟁 관계를 떠올리는 것입니다.

• 위조지폐범: 진짜와 거의 똑같은 위조지폐를 만들려고 노력합니다. (목표: 경찰을 속이자!)
• 경찰: 위조지폐를 기가 막히게 감별해내려고 노력합니다. (목표: 속지 말자!)

이 둘이 서로 경쟁하면서, 위조지폐범의 실력(진짜와 구분 안 되는 지폐 만들기)과 경찰의 실력(감별 능력)이 함께 발전하겠죠? 적대적 디바이어싱은 바로 이 원리를 AI 모델 학습에 적용한 것입니다.

---

1. 적대적 디바이어싱(Adversarial Debiasing)이란?

한 줄 요약: 모델이 주어진 임무(예: 대출 심사)는 잘 수행하면서, 동시에 민감한 정보(예: 성별, 인종)는 예측하지 못하도록 두 개의 모델을 서로 경쟁시키며 학습시키는 'In-processing' 공정성 확보 기술입니다.

즉, 모델이 정답은 잘 맞추되, 편향된 예측을 하는 데 사용할 수 있는 '나쁜 힌트'(민감 정보)는 일부러 잊어버리도록 훈련시키는 방법입니다.

2. 어떻게 동작할까? (반드시 알아야 할 내용)

적대적 디바이어싱은 두 개의 신경망 모델이 서로 경쟁하며 학습합니다.

1. 예측 모델 (Predictor Model) - "주어진 임무를 수행하는 직원"
   • 역할: 우리가 원하는 주된 작업을 수행합니다. 예를 들어, 지원자의 이력서(X)를 보고 합격 여부(Y)를 예측합니다.
   • 목표:
     1. 합격 여부(Y)를 최대한 정확하게 예측해야 합니다. (기본 임무)
     2. 동시에, 자신의 예측 결과에서 성별(Z)과 같은 민감한 정보는 드러나지 않도록 노력해야 합니다. (공정성 임무)
2. 적대자 모델 (Adversary Model) - "편향을 찾아내는 감시관"
   • 역할: 예측 모델의 예측 결과(Y^)를 보고, 거꾸로 그 사람의 민감 정보(Z, 예: 성별)를 맞추려고 노력합니다.
   • 목표: 예측 모델의 결과물에 편향이 남아있는지 기가 막히게 찾아내는 것이 목표입니다. 만약 적대자 모델이 성별을 높은 확률로 맞춘다면, 이는 예측 모델의 결과에 성별 정보가 많이 남아있다는 뜻이겠죠.

학습 과정 (Minimax Game)

이 두 모델은 서로 반대되는 목표를 가지고 경쟁합니다.

• 1단계: 적대자(감시관) 학습
  • 예측 모델의 결과를 보고, 성별을 더 잘 맞추도록 학습합니다. (감시 실력 UP)
• 2단계: 예측 모델(직원) 학습
  • 두 가지를 동시에 학습합니다.
    • 합격 여부를 더 잘 맞추도록 학습합니다. (업무 실력 UP)
    • 그리고 적대자(감시관)가 성별을 맞추지 못하도록, 즉 적대자의 손실(Loss)을 최대화하도록 학습합니다. (감시를 피하는 능력 UP)

이 과정을 계속 반복하면, 예측 모델은 합격 여부 예측에 꼭 필요한 정보만 남기고 성별과 관련된 정보는 점차 지워나가게 됩니다. 결국 적대자가 더 이상 성별을 맞출 수 없게 되면, 우리는 공정성이 확보된 예측 모델을 얻게 됩니다.

3. 수식을 통한 이해 (백그라운드)

• X: 입력 피처 (예: 이력서 내용)
• Y: 예측할 목표 변수 (예: 합격=1, 불합격=0)
• Z: 보호해야 할 민감 변수 (예: 남성=1, 여성=0)
• θp​: 예측 모델의 파라미터
• θa​: 적대자 모델의 파라미터

1. 예측 모델(Predictor)의 손실 함수(Loss Function)
   • Lp​: 주된 임무(합격 예측)에 대한 손실입니다. 이 값은 **최소화(minimize)**해야 합니다. (일을 잘해야 하므로)
   • La​: 적대자(감시관)의 손실입니다. 이 값은 **최대화(maximize)**해야 합니다. (감시를 피해야 하므로)
   • 손실 함수에 **마이너스(-)**를 붙여서 전체를 최소화하는 것은, 결국 La​를 최대화하는 것과 같습니다.
   • λ: 정확성과 공정성 사이의 중요도를 조절하는 하이퍼파라미터입니다.
2. Lpredictor​(θp​)=Lp​(X,Y;θp​)−λ⋅La​(X,Z;θp​,θa​)
3. 적대자 모델(Adversary)의 손실 함수
   • 적대자는 민감 변수 Z를 잘 예측해야 하므로, 자신의 손실 La​를 **최소화(minimize)**하려고 합니다.
4. Ladversary​(θa​)=La​(X,Z;θp​,θa​)

이처럼 예측 모델은 La​를 키우려 하고, 적대자는 La​를 줄이려 하는 제로섬 게임(Minimax game)이 벌어지는 것입니다.

4. 헷갈리기 쉬운 내용

• Q: 그냥 데이터에서 '성별' 컬럼을 빼면 되는 거 아닌가요?
  • A: 아닙니다. 단순히 민감 정보 컬럼을 제거해도, 다른 피처들이 그 정보의 대리(Proxy) 역할을 할 수 있습니다. 예를 들어, '졸업한 여고 이름', '가입한 동아리' 등의 정보가 성별을 암시할 수 있습니다. 적대적 디바이어싱은 이런 숨겨진 대리 변수까지 고려하여 편향을 제거하는 데 매우 효과적입니다.
• Q: 정확도가 떨어지지는 않나요?
  • A: 네, 떨어질 수 있습니다. 이것이 바로 **정확성-공정성 트레이드오프(Accuracy-Fairness Trade-off)**입니다. 민감 정보가 실제 예측에 유의미한 정보였다면, 이 정보를 강제로 제거하는 과정에서 모델의 전체적인 정확도는 약간 하락할 수 있습니다. λ 값을 조절하며 이 둘 사이의 적절한 균형점을 찾는 것이 중요합니다.

 

접근법 1: 하나의 '만능 감시관' (Multi-Task Adversary)

이 방식은 하나의 적대자(Adversary) 모델이 예측 모델의 결과를 보고 성별, 인종, 지역 등 여러 민감 정보를 동시에 맞추도록 학습하는 것입니다.

• 예측 모델(직원)의 목표: 나의 예측 결과(Y^)를 보고, 저 만능 감시관이 성별도, 인종도, 지역도 그 어떤 것도 맞추지 못하게 하자!
• 적대자 모델(만능 감시관)의 목표: 직원의 예측 결과(Y^)만 보고 성별, 인종, 지역을 모두 최대한 정확하게 맞추자!

장점

• 단순한 구조: 전체 시스템의 구조가 비교적 단순하고, 관리해야 할 모델이 적습니다.
• 상관관계 학습: 여러 민감 정보 간의 복합적인 상관관계까지 학습하여 제거할 수도 있습니다.

단점

• 불균형한 학습: 적대자가 여러 개의 답을 동시에 맞추다 보면, 상대적으로 맞추기 쉬운 '성별' 편향은 잘 제거되는데, 더 미묘한 '지역' 편향은 잘 제거되지 않는 등 학습이 불안정해질 수 있습니다.

---

접근법 2: 여러 명의 '전문 감시관' (Multiple Adversaries)

이 방식은 각 민감 정보마다 별도의 전문 적대자 모델을 두는 것입니다. '성별'을 감시하는 적대자, '인종'을 감시하는 적대자, '지역'을 감시하는 적대자를 각각 따로 만드는 것이죠.

• 예측 모델(직원)의 목표: 나의 예측 결과(Y^)를 보고, 성별 감시관은 성별을 못 맞추게, 인종 감시관은 인종을 못 맞추게, 지역 감시관은 지역을 못 맞추게 하자! (모든 전문 감시관을 동시에 속여야 합니다.)
• 각 적대자 모델(전문 감시관)의 목표: 나는 오직 나의 전문 분야(예: 성별)만 집요하게 파고들어서 맞추겠다!

장점

• 강력하고 안정적인 성능: 각 적대자가 자신의 임무에만 집중하므로, 각각의 편향을 더 효과적이고 안정적으로 제거할 수 있습니다.
• 세밀한 제어: "우리 시스템에서는 인종 편향이 성별 편향보다 더 중요하니, 인종 적대자와의 경쟁에 더 가중치(λ)를 두자" 와 같이 각 편향의 중요도를 다르게 설정하여 세밀하게 제어할 수 있습니다.

단점

• 복잡한 구조: 시스템의 구조가 더 복잡해지고, 학습하고 관리해야 할 모델의 수가 늘어나 계산 비용이 증가합니다.

---

결론: 실제 현업에서는?

실제로는 접근법 2 (여러 명의 전문 감시관) 방식이 더 안정적이고 제어하기 쉽기 때문에 선호되는 경향이 있습니다.

하나의 만능 감시관을 두는 방식은 구조는 간단하지만 학습 과정이 까다로워 원하는 만큼의 공정성을 확보하기 어려울 때가 많기 때문입니다. 따라서 중요한 민감 정보가 여러 개라면, 각각에 대한 전문 감시관(Adversary)을 두는 것이 더 확실한 해결책이 될 수 있습니다.

 

 

 

---

배치 예측(Batch Prediction)과 온라인 예측(Online Prediction)

 

'신문'과 '인터넷 뉴스'를 생각해보세요

1. 배치 예측(Batch Prediction) = 📰 인쇄된 신문
   • 신문은 어떻게 만들어지나요? 하루 동안 일어난 모든 사건(데이터)을 밤새 모아서 편집한 뒤, **새벽에 딱 한 번 인쇄(배치 처리)**합니다.
   • 우리가 아침에 이 신문을 읽을 때, 그 안의 기사는 최소 몇 시간 전의 과거 정보입니다. 새벽에 인쇄가 끝난 직후에 발생한 긴급 속보는 신문에 실려있지 않죠.
   • 이처럼 배치 예측은 정해진 시간(예: 매일 밤)에 모아둔 데이터를 한꺼번에 처리해서 결과를 만들어 둡니다. 그래서 우리가 그 결과를 사용할 때는 이미 과거의 정보가 되어버리는 것입니다. 이것이 바로 **"결과의 최신성이 떨어진다"**는 의미입니다.
2. 온라인 예측(Online Prediction) = 💻 실시간 인터넷 뉴스
   • 인터넷 뉴스는 어떤가요? 사건이 터지는 즉시 기사가 올라오고 계속 업데이트됩니다.
   • 우리가 웹사이트를 새로고침할 때마다 가장 최신 정보를 볼 수 있습니다.
   • 온라인 예측도 이와 같습니다. 사용자가 어떤 행동을 하는 그 순간에 바로 예측을 수행하기 때문에, 결과는 항상 가장 최신 데이터를 반영합니다.

---

실제 AI 시스템 예시

'오늘의 추천 상품' 시스템을 만든다고 가정해 봅시다.

• 배치 예측 방식:
  • 밤 12시 ~ 새벽 2시: 어제 하루 동안 모든 사용자의 활동 데이터를 모아서 '오늘 추천할 상품'을 사용자별로 미리 계산해 둡니다.
  • 오전 10시: 사용자가 앱에 접속하면, 어젯밤에 미리 계산해 둔 추천 상품을 보여줍니다.
  • 문제점: 이 사용자가 오전 9시 59분에 검색한 상품은 추천 결과에 전혀 반영되지 않습니다. 왜냐하면 추천 결과는 이미 8시간 전 데이터로 만들어졌기 때문이죠. 이것이 바로 "결과의 최신성이 떨어지는" 상황입니다.
• 온라인 예측 방식:
  • 오전 10시: 사용자가 앱에 접속하는 그 순간, 바로 직전까지의 모든 활동을 종합하여 실시간으로 추천 상품을 예측해서 보여줍니다.
  • 사용자가 상품을 하나 클릭하면, 그 다음 페이지에서는 클릭한 정보를 즉시 반영하여 새로운 추천 상품을 보여줄 수 있습니다.

이처럼 **처리량(Throughput)**과 비용 효율성을 위해 **최신성(Freshness)**을 희생하는 것이 배치 예측의 핵심적인 트레이드오프라고 이해하시면 됩니다.

 

---

 

모델의 오프라인 테스트(AUC, F1-score 등) 결과는 매우 높았지만, 실제 서비스에 A/B 테스트를 진행했을 때 비즈니스 지표(예: 사용자 클릭률)가 오히려 하락했습니다. 이 문제의 가장 가능성 높은 원인은 무엇일까요?

 

오프라인 평가 지표와 실제 비즈니스 목표 간의 불일치(Misalignment)

정답입니다!

이것이 가장 흔하고 근본적인 원인입니다. 예를 들어, 모델이 '클릭할 확률' 자체는 잘 예측했지만, 사용자의 피로도를 높이는 자극적인 추천만 하여 장기적인 사용자 경험을 해쳤을 수 있습니다.

 

---

feature 처리 기법 비교

 

 

• 스케일 조절 (숫자 다루기): 값의 범위가 다른 숫자 피처들을 비슷한 범위로 맞춰주는 기법.
  • 정규화 (Normalization/Standardization)
• 범주형 데이터 변환 (글자 다루기): '서울', '부산'과 같은 문자 데이터를 모델이 이해할 수 있는 숫자로 바꾸는 기법.
  • 레이블 인코딩 (Label Encoding)
  • 피처 해싱 (Feature Hashing)
• 차원 축소 (복잡성 줄이기): 여러 개의 피처를 핵심 정보만 남기고 더 적은 수의 피처로 압축하는 기법.
  • 주성분 분석 (PCA, Principal Component Analysis)

 

1. 정규화 (Normalization / Standardization)

한 줄 요약: 제각각인 숫자들의 '단위'를 통일시켜 모델이 편애하지 않도록 만드는 과정입니다.

마치 '키(cm)'와 '몸무게(kg)'의 단위와 범위가 너무 달라서, 모델이 범위가 더 큰 몸무게를 더 중요한 피처로 착각하는 것을 막아주는 것과 같습니다.

반드시 알아야 할 내용

두 가지 대표적인 방법이 있습니다.

1. 표준화 (Standardization):
   • 방법: 데이터의 평균을 0, 표준편차를 1이 되도록 변환합니다.
   • 수식: z=σx−μ​ (여기서 μ는 평균, σ는 표준편차)
   • 특징: 이상치(outlier)가 존재할 때도 비교적 안정적인 성능을 보입니다. 가장 널리 사용되는 방법입니다.
2. 정규화 (Normalization, Min-Max Scaling):
   • 방법: 데이터의 모든 값을 0과 1 사이의 범위로 변환합니다.
   • 수식: x′=xmax​−xmin​x−xmin​​
   • 특징: 이상치에 매우 민감합니다. 예를 들어, 1, 2, 3, 100이라는 데이터가 있다면 1, 2, 3은 거의 0에 가깝게 뭉쳐버립니다.

헷갈리기 쉬운 내용

• 언제 사용하나요?: 거리 기반 알고리즘(SVM, K-Means 등)이나 경사 하강법을 사용하는 모델(선형 회귀, 로지스틱 회귀, 신경망 등)에서는 거의 필수적입니다. 하지만 트리 기반 모델(결정 트리, 랜덤 포레스트)은 각 피처를 독립적으로 보기 때문에 정규화의 영향이 거의 없습니다.
• '정규화' vs '표준화': 용어가 혼용되기도 하지만, 보통 '표준화(평균 0, 분산 1)'가 더 일반적이고 안정적인 방법입니다.

---

2. 레이블 인코딩 (Label Encoding)

한 줄 요약: '빨강', '파랑', '노랑' 같은 문자 카테고리를 0, 1, 2처럼 숫자로 간단히 바꾸는 것입니다.

반드시 알아야 할 내용

• 방법: 각 카테고리에 고유한 정수를 순서대로 부여합니다.
  • ['빨강', '파랑', '노랑'] -> [0, 1, 2]
• 치명적인 단점: 모델이 이 숫자들 사이에 순서나 크기가 있다고 오해할 수 있습니다. 예를 들어, '노랑(2)'이 '빨강(0)'보다 2배 더 중요하다거나, '파랑(1)'이 중간값이라고 잘못 학습할 수 있습니다.

헷갈리기 쉬운 내용

• 언제 사용하나요?:
  • 사용 가능: 카테고리 간에 실제로 순서가 있을 때 (예: '초졸(0)', '중졸(1)', '고졸(2)', '대졸(3)')
  • 사용하면 안 됨: 순서가 없는 명목형 변수(예: '국가', '도시 이름')에는 사용하면 안 됩니다. 이 경우에는 **원핫 인코딩(One-Hot Encoding)**을 사용하는 것이 정석입니다.
  • 트리 기반 모델에서는 숫자 크기보다 분기점으로 사용되므로 비교적 괜찮게 동작하기도 합니다.

---

3. 주성분 분석 (PCA, Principal Component Analysis)

한 줄 요약: 여러 피처에 흩어져 있는 정보들을 가장 잘 설명하는 새로운 '핵심 축'(주성분)을 찾아 데이터를 압축하는 기술입니다.

마치 여러 각도에서 찍은 3D 자동차 사진들을 보고, 자동차의 '길이'와 '높이'라는 두 가지 핵심 축(주성분)만으로 자동차의 전체 모습을 효과적으로 요약하는 것과 같습니다.

반드시 알아야 할 내용

• 목표: 데이터의 분산(Variance)을 최대한 보존하는 새로운 축을 찾습니다. 정보의 손실을 최소화하면서 차원을 줄이는 것이 핵심입니다.
• 방법:
  1. 데이터의 공분산 행렬을 계산합니다.
  2. 공분산 행렬의 고유값(Eigenvalue)과 고유벡터(Eigenvector)를 찾습니다.
  3. 고유값이 큰 순서대로 고유벡터(이것이 바로 주성분)를 선택하여, 원본 데이터를 이 축에 투영(projection)시킵니다.
• 주의사항: PCA는 수치형 데이터에만 적용 가능하며, 적용 전에 반드시 정규화(표준화)를 수행해야 합니다. 피처들의 스케일이 다르면 분산이 큰 피처가 주성분을 왜곡하기 때문입니다.

헷갈리기 쉬운 내용

• PCA는 단순히 피처를 몇 개 **'선택(selection)'**하는 것이 아니라, 기존 피처들을 조합하여 '새로운 피처를 만들어내는(extraction)' 것입니다. 따라서 압축된 결과는 원래 피처의 의미를 직접적으로 설명하기 어렵습니다.

---

4. 피처 해싱 (Feature Hashing, Hashing Trick)

한 줄 요약: 수백만 개의 카테고리를 해시 함수를 이용해 정해진 개수의 '바구니'에 강제로 욱여넣어 차원을 줄이는 기술입니다.

퀴즈에서 다루었던 '사용자 ID'처럼 고유한 값이 너무 많은 범주형 데이터를 원핫 인코딩하면 수백만 차원의 벡터가 생깁니다. 피처 해싱은 이를 1024개와 같이 고정된 수의 바구니(차원)에 담아버리는 것입니다.

반드시 알아야 할 내용

• 방법: 해시 함수를 사용하여 범주형 데이터를 미리 정해둔 차원의 벡터로 직접 매핑합니다.
• 장점:
  • 메모리 효율성: 매우 적은 메모리로 고차원 데이터를 다룰 수 있습니다.
  • 온라인 학습에 유리: 새로운 카테고리가 등장해도 미리 사전을 만들어 둘 필요 없이 바로 처리가 가능합니다.
• 단점 (트레이드오프):
  • 해시 충돌(Hash Collision): 서로 다른 카테고리가 같은 바구니에 담길 수 있습니다. 이로 인해 정보의 손실이 발생합니다.
  • 해석 불가능: 해싱된 결과는 원래 어떤 카테고리였는지 역추적이 불가능하여 해석이 어렵습니다.

헷갈리기 쉬운 내용

• PCA와의 차이점: PCA는 수치형 데이터의 '분산'을 기반으로 정보를 압축하는 반면, 피처 해싱은 범주형 데이터의 '고유값 개수'를 줄이는 데 초점을 맞춥니다.
• 레이블 인코딩과의 차이점: 레이블 인코딩은 순서 정보 왜곡의 위험이 있지만, 피처 해싱은 순서 정보를 만들지 않는 대신 해시 충돌의 위험이 있습니다.

 

배경: "정리할 수 없는 수많은 물건들"

거대한 도서관에 수백만 권의 책이 새로 들어왔다고 상상해 보세요. 각 책에 고유 번호를 붙여 서가를 만들려면(원-핫 인코딩 방식) 수백만 개의 서가가 필요해서 공간이 부족해집니다.

이때, 사서가 이런 규칙을 만듭니다.

"어떤 책이든 책 제목의 첫 글자를 기준으로 딱 **26개(A-Z)**의 서가에만 나눠서 꽂자!"

이것이 바로 피처 해싱의 핵심 아이디어입니다. 매우 많은 종류의 데이터를 정해진 개수의 '바구니(bucket)'에 규칙적으로 욱여넣는 기술이죠.

---

1. 피처 해싱 (Feature Hashing) 이란?

한 줄 요약: '해시 함수'라는 마법의 규칙을 사용해, 잠재적으로 무한할 수 있는 범주형 데이터를 미리 정해둔 고정된 크기의 벡터로 압축 변환하는 기법입니다.

이 기법은 '해싱 트릭(Hashing Trick)'이라고도 불립니다.

2. 어떻게 동작할까? (반드시 알아야 할 내용)

피처 해싱은 두 가지 핵심 요소로 동작합니다.

1. 해시 함수 (Hash Function): 어떤 텍스트 입력값(예: 'user_id_12345')을 받아서 항상 동일한 숫자를 출력하는 함수입니다. 마치 모든 단어에 고유한 주민등록번호를 부여하는 것과 같습니다. (예: hash('서울') -> 283401, hash('부산') -> 940231)
2. 바구니의 개수 (Number of Buckets / n_features): 우리가 최종적으로 만들 벡터의 크기입니다. 즉, 서가의 개수를 몇 개로 할지 미리 정하는 것이죠. (예: 1024개)

처리 과정은 이렇습니다:

1. 입력: 범주형 데이터 'city=서울' 이라는 텍스트가 들어옵니다.
2. 해싱: 해시 함수를 적용하여 이 텍스트를 큰 정수로 바꿉니다.
   • hash('city=서울') -> 283401
3. 나머지 연산 (Modulo): 이 해시 값을 '바구니의 개수'로 나눈 나머지를 구합니다. 이 나머지가 바로 벡터의 인덱스가 됩니다.
   • 283401 % 1024 -> 841
4. 벡터화: 크기가 1024인 0벡터를 만든 뒤, 841번째 위치의 값을 1로 바꿔줍니다.
   • [0, 0, ..., 1, 0, ...] (841번째 인덱스가 1)

이렇게 하면 'user_id_987654321' 처럼 한 번도 본 적 없는 새로운 사용자가 등장해도, 사전을 업데이트할 필요 없이 즉시 해싱을 통해 벡터로 변환할 수 있습니다.

💡 심화: 해시 충돌 완화 (Signed Hashing)

가장 큰 단점은 해시 충돌(Hash Collision), 즉 서로 다른 책('서울', '대전')이 같은 서가(같은 인덱스)에 꽂히는 문제입니다. 이때 정보가 섞여버리죠.

이를 완화하기 위해, 일부 똑똑한 구현에서는 두 번째 해시 함수를 사용해 값을 +1 또는 -1로 정합니다. 만약 '서울'과 '대전'이 같은 인덱스 3에 매핑되더라도, '서울'은 +1, '대전'은 -1 값을 가지게 되면, 모델은 두 피처가 서로 다른 영향을 준다는 것을 학습할 수 있게 됩니다.

3. 피처 해싱의 명확한 장단점 (주관식 대비)

장점 (언제 사용해야 할까?)

• 엄청난 메모리 효율성: '사용자 ID', '검색어'처럼 고유값(cardinality)이 수백만, 수천만 개인 피처를 다룰 때, 원-핫 인코딩의 메모리 폭증 문제를 해결할 수 있습니다.
• 사전(Dictionary) 불필요: 모든 카테고리를 미리 파악하고 사전을 만들 필요가 없습니다.
• 온라인 학습에 최적화: 새로운 카테고리가 실시간으로 유입되어도 시스템 변경 없이 바로 처리할 수 있어 스트리밍 데이터 환경에 매우 유리합니다.

단점 (무엇을 희생하는가?)

• 해시 충돌: 피처 해싱의 가장 본질적인 트레이드오프입니다. 메모리를 아끼는 대신, 서로 다른 피처가 충돌하여 정보 손실이 발생할 수 있습니다. 바구니 개수가 너무 적으면 충돌이 심해져 성능이 저하됩니다.
• 해석 불가능 (Non-interpretable): 해싱된 벡터의 특정 인덱스가 원래 어떤 피처였는지 역추적이 불가능합니다. 따라서 "이 모델은 왜 이런 예측을 했는가?"를 설명하기가 매우 어렵습니다.

기법	장점	단점	주요 사용처
원-핫 인코딩	정확함, 해석 가능	메모리 사용량 큼	카테고리 수가 적을 때 (예: 성별, 요일)
피처 해싱	메모리 효율적, 온라인 학습 용이	해시 충돌, 해석 불가능	카테고리 수가 매우 많을 때 (예: 사용자 ID)
임베딩	성능 가장 좋음, 의미 학습	학습 필요, 데이터 많이 요구	자연어 처리, 추천 시스템 등

 

 피처 해싱 이해하기 

두 가지 접근법: "개인 사물함" vs "공용 사물함"

상황: 수억 명의 학생(사용자)이 있는 거대한 학교에 개인화된 정보를 저장해야 합니다.

1. 일반적인 임베딩 방식 (개인 사물함)

• 방법: 모든 학생에게 고유한 개인 사물함을 하나씩 배정합니다. 학생 ID는 그 사물함의 열쇠입니다.
• 학습: 'user_123' 학생이 어떤 행동을 하면, 모델은 'user_123' ID라는 열쇠로 개인 사물함을 열고, 그 안의 프로필(임베딩 벡터)을 업데이트합니다.
• 문제점: 학생 수가 수억 명이면, 수억 개의 사물함을 설치할 공간(메모리)이 부족해집니다.

2. 피처 해싱 + 임베딩 방식 (공용 사물함) ✨

이것이 바로 사용자님의 질문에 대한 답입니다. 메모리가 부족할 때, 학교는 이런 규칙을 만듭니다.

"개인 사물함은 없다! 대신, 10,000개의 공용 사물함만 설치한다. 모든 학생은 자신의 ID를 해시 함수에 넣어 나온 번호의 사물함을 다른 학생들과 함께 사용한다!"

• 방법: 사용자 ID를 피처 해싱하여 정해진 개수(예: 10,000개)의 인덱스 중 하나로 매핑합니다. 이 인덱스가 바로 공용 사물함의 번호가 됩니다.
• 학습:
  1. 'user_123'이 어떤 행동을 합니다.
  2. hash('user_123') % 10000 -> 582번이 나옵니다.
  3. 모델은 582번 공용 사물함을 열고, 그 안의 프로필(임베딩 벡터)을 'user_123'의 행동에 맞춰 약간 수정합니다.
  4. 나중에 'user_987'이 다른 행동을 합니다.
  5. hash('user_987') % 10000 -> 또 582번이 나올 수 있습니다! (해시 충돌)
  6. 모델은 다시 582번 공용 사물함을 열고, 이번에는 'user_987'의 행동에 맞춰 프로필을 또 수정합니다.

피처 해싱은 여기서 어떻게 쓰이는가?

결론적으로 피처 해싱은 '임베딩 벡터를 찾아가는 주소'를 만드는 과정에서 사용됩니다.

• 일반적인 임베딩: ID -> 고유한 주소(인덱스) -> 개인 프로필(임베딩 벡터) (ID와 주소가 1:1)
• 피처 해싱 + 임베딩: ID -> 해싱 -> 공용 주소(인덱스) -> 공동 프로필(임베딩 벡터) (ID와 주소가 N:1)

이 방식에서 582번 사물함에 담긴 프로필은 'user_123'만의 취향이 아니라, 582번 사물함을 함께 쓰는 모든 사용자들의 평균적인 취향이 됩니다.

트레이드오프: 무엇을 얻고 무엇을 잃는가?

• 얻는 것:
  • 엄청난 메모리 절약: 수억 개의 개인 프로필 대신, 딱 10,000개의 공동 프로필만 저장하면 됩니다.
  • 신규 사용자 처리: 처음 보는 사용자가 와도 즉시 해싱을 통해 기존 사물함 중 하나에 배정하여 예측을 수행할 수 있습니다.
• 잃는 것:
  • 개인화의 정교함: 해시 충돌 때문에, 완벽한 개인화 대신 '비슷한 해시 값을 가진 사용자 그룹'에 대한 개인화가 이루어집니다. 내 사물함을 다른 사람과 같이 쓰니, 내 물건이 아닌 것들도 섞여있는 셈이죠.

이처럼 피처 해싱은 개인화의 정교함을 약간 희생하는 대신, 메모리 문제를 해결하고 시스템을 확장 가능하게 만드는 매우 강력하고 실용적인 엔지니어링 기법입니다. 특히 광고 시스템처럼 사용자 ID의 개수가 폭발적으로 많은 도메인에서 필수적으로 사용됩니다.

 

 

---

온라인 예측이 더 복잡한 4가지 이유

1. '실시간' 데이터 처리 파이프라인이 추가됩니다.

• 배치 예측: 이미 데이터베이스(Data Warehouse)에 잘 정리된 과거 데이터를 가져와 쓰면 됩니다. 데이터 파이프라인이 비교적 단순하고, 정해진 시간에 한 번만 돌면 됩니다.
• 온라인 예측: 사용자의 클릭, 검색 같은 행동이 발생하는 **'바로 그 순간'**에 데이터를 잡아채서 실시간으로 피처를 계산하고 업데이트해야 합니다. 이를 위해 Kafka 같은 이벤트 스트리밍 플랫폼과 Flink 같은 스트림 처리 엔진이 추가되어, 24시간 내내 흘러 들어오는 데이터를 처리하는 복잡한 파이프라인을 구축해야 합니다.

2. '초저지연(Low-latency)' 피처 조회가 필요합니다.

• 배치 예측: 모델이 예측에 필요한 모든 피처를 데이터 웨어하우스에서 여유롭게 가져와 계산할 수 있습니다. 몇 초, 몇 분이 걸려도 괜찮습니다.
• 온라인 예측: 사용자가 기다리지 않도록 수십 밀리초(ms) 안에 예측에 필요한 모든 피처를 가져와야 합니다. 일반적인 데이터베이스로는 이 속도를 맞출 수 없기 때문에, Redis나 DynamoDB 같은 **인메모리 기반의 온라인 피처 스토어(Online Feature Store)**라는 별도의 복잡한 시스템을 구축하고 운영해야 합니다.

3. '항상 켜져 있는' 고가용성 API가 필요합니다.

• 배치 예측: 예측 작업은 내부적으로 실행되는 스크립트에 가깝습니다. 작업이 끝나면 결과를 데이터베이스에 저장하고, 서버는 꺼져도 상관없습니다.
• 온라인 예측: 언제 들어올지 모르는 예측 요청에 항상 응답하기 위해 24시간 365일 안정적으로 작동하는 API 서버를 운영해야 합니다. 이를 위해서는 쿠버네티스(Kubernetes) 같은 컨테이너 오케스트레이션 도구를 사용하여 자동 확장(Autoscaling), 장애 복구(Failover), 무중단 배포 등 훨씬 더 복잡한 인프라 관리가 필요합니다.

4. '실시간' 모니터링 시스템이 필수적입니다.

• 배치 예측: 작업이 실패하면, 그냥 로그를 보고 원인을 파악한 뒤 다음 날 다시 실행하면 됩니다.
• 온라인 예측: 실시간으로 서비스에 영향을 주기 때문에, 모든 것을 지켜봐야 합니다.
  • 지연 시간: "API 응답이 100ms를 넘어가고 있진 않은가?"
  • 에러율: "갑자기 예측 실패 요청이 늘어나고 있진 않은가?"
  • 데이터 드리프트: "지금 들어오는 데이터가 학습했던 데이터와 너무 달라지진 않았는가?"
  • 이 모든 것을 실시간으로 탐지하고 경고를 보내주는 정교한 모니터링 및 얼러팅(Alerting) 시스템을 반드시 갖추어야 합니다.

 

---