반응형
기업 데이터에서 가장 먼저 틀어지는 지점은 가격도, 재무제표도 아니다. 대개는 “이 코드가 어느 회사를 가리키는가”라는 식별자 문제에서 시작한다. 티커는 사람이 읽기 쉽지만 재사용될 수 있고, 회사명은 표기가 자주 흔들린다. 그래서 매핑 설계는 단순한 이름 맞추기가 아니라 이력 관리에 가깝다.

먼저 고정할 기준 키
내부에서는 사람이 기억하기 쉬운 티커보다 오래 살아남는 키를 기준으로 잡는 편이 낫다. 회사, 증권, 거래소, 통화를 따로 두고 필요한 순간에 조합한다.
| 대상 | 권장 키 | 틀어지는 순간 |
|---|---|---|
| 회사 | company_id | 사명 변경, 합병, 분할 |
| 증권 | security_id | 티커 재사용, 클래스 변경 |
| 상장 시장 | exchange_id | 이전 상장, 복수 상장 |
| 원천 매핑 | source_mapping_id | 공급사 코드 변경 |
판단식으로 보는 매핑 위험
매핑을 사람이 검토할지 자동으로 넘길지는 점수로 잘라두면 운영이 편하다. 예를 들어 아래처럼 이름 유사도와 거래소 일치 여부를 함께 본다.
match_score = 0.45 * name_similarity
+ 0.25 * exchange_match
+ 0.20 * active_period_overlap
+ 0.10 * currency_match
manual_review = match_score < 0.82
운영에서 중요한 것
한 번 맞춘 매핑을 덮어쓰지 말고, 언제부터 언제까지 유효했는지 따로 남겨야 한다. 그래야 과거 가격과 현재 기업 정보가 엉뚱하게 붙지 않는다.
실무 체크
- 신규 원천을 붙일 때는 표본 50개 정도를 먼저 뽑아 회사명, 거래소, 상장 상태를 대조한다.
- 같은 외부 키가 여러 내부 키에 붙는 경우를 매일 따로 집계한다.
- 티커만으로 조인한 쿼리는 장기 백테스트에 쓰지 않는다.
함께 보면 좋은 글
반응형
'Data Engineering' 카테고리의 다른 글
| 분기 재무 데이터 구축 방법: 제출일, 수정 데이터, 재처리 기준 (0) | 2026.06.14 |
|---|---|
| 외부 금융 데이터 소스 전환 검토 기준: 범위, 품질, 비용 (0) | 2026.06.14 |
| 주식 데이터 정합성 점검: 누락, 중복, 기준일 확인 방법 (0) | 2026.06.02 |
| Learning Rate와 Iteration 관계: 반복 횟수에 따른 수렴 변화 (0) | 2026.05.24 |
| 최대우도추정 MLE 개념: 확률과 likelihood 차이 (0) | 2026.05.21 |
