
예측 점수 말고 근거 점수 — 데이터가 부족한 대상을 유리하게 만들지 않기
기업 점수를 매기는 엔진을 만들며 부딪힌 함정. 정보가 적은 회사가 오히려 높은 점수를 받는 문제를 신뢰도 가중으로 해결한 과정.
기업의 재무 데이터를 읽어 점수를 매기는 엔진을 만들었다. 목적은 “이 회사 매출이 늘까?“를 맞히는 게 아니었다.
만들면서 가장 먼저 정한 건 점수의 성격이었다.
미래 매출을 예측하는 게 아니라, “매출이 늘 근거가 얼마나 강한지“를 점수화한다. 예언 점수가 아니라 근거 점수다.
이 구분이 왜 중요했는지부터 적는다.
예측 점수는 검증할 수 없다
“이 회사는 80점”이라는 예측 점수를 만들면, 그게 맞았는지 어떻게 아나. 주가가 올랐으면 맞은 건가? 매출이 늘었는데 주가가 빠지면?
검증 기준이 모호하면 시스템이 계속 그럴듯한 숫자를 뱉는데 아무도 틀렸다고 말할 수 없다. 그리고 그 숫자로 판단하게 된다.
반면 근거 점수는 검증이 명확하다. “매출이 3년 연속 늘었다”는 사실이거나 아니다. “영업이익률이 개선됐다”도 마찬가지다. 점수는 이런 사실들의 집계이고, 각 항목을 확인할 수 있다.
미래를 맞히는 건 사람이 한다. 시스템은 근거를 모아 보여준다.
배점 구조
항목은 이렇게 나눴다.
| 항목 | 배점 | 성격 |
|---|---|---|
| 현재 매출 성장 | 15 | 재무제표 |
| 이익화 능력 | 20 | 재무제표 |
| 위험 감점 | -10 | 재무제표 + 거래 상태 |
| 피어그룹 매출성장 순위 | 10 | 동종 업계 비교 |
| 가격·밸류 (피어그룹 내 PER/PBR 백분위) | 10 | 시장 가격 |
감점 항목을 넣은 게 중요했다. 가점만 있으면 나쁜 신호가 점수에 반영되지 않는다. 부채가 급증했거나 거래 정지 이력이 있으면 점수가 깎여야 한다.
정보가 적은 회사가 유리해지는 함정
여기서 진짜 문제를 만났다.
작은 회사나 상장한 지 얼마 안 된 회사는 데이터가 부족하다. 3년치 재무제표가 없고, 피어그룹이 정의 안 돼 있고, 가격 정보도 부실하다.
이런 회사를 단순히 “해당 없음”으로 처리하면 어떻게 되나. 감점 항목도 평가되지 않는다. 결과적으로 나쁜 신호가 없는 것처럼 보이고, 남은 항목의 점수 비율이 높아진다.
즉 정보가 없을수록 점수가 좋아진다. 이건 완전히 거꾸로다.
신뢰도로 점수를 깎는다
해결은 이렇게 했다.
최종점수 = 환산점수 × 데이터신뢰도
데이터 신뢰도는 “평가 가능했던 항목의 비율”이다. 절반만 평가됐으면 점수도 절반으로 깎인다.
그리고 신뢰도가 임계값 아래면 아예 “평가불가” 등급으로 분리한다. 낮은 점수를 주는 게 아니라 목록에서 빼는 것이다. 점수를 주면 그 숫자로 비교하게 되는데, 근거가 부족한 대상을 근거가 충분한 대상과 같은 축에 놓으면 안 된다.
보너스 항목은 분모에 넣지 않는다
여기서 미묘한 부분이 하나 더 있었다.
피어그룹 순위와 가격·밸류는 보너스 항목이다. 피어그룹이 정의 안 된 종목이나 가격 정보가 없는 종목은 이 항목이 N/A가 된다.
이걸 신뢰도 분모에 넣으면, 피어그룹을 내가 아직 정의하지 않았다는 이유로 멀쩡한 회사의 신뢰도가 떨어진다. 데이터가 없는 게 대상의 문제인지 내 설정의 문제인지 구분해야 했다.
그래서 보너스 항목은 신뢰도 분모에서 빼고 환산점수에만 반영한다. 재무제표처럼 “있어야 마땅한” 데이터가 없을 때만 신뢰도가 깎인다.
데이터 소스를 겹치지 않게
재무 데이터는 공시 API에서, 가격과 밸류는 별도 가격 API에서 가져온다. 여기서 규칙을 하나 정했다. 같은 데이터를 두 곳에서 가져오지 않는다.
가격 정보를 이 엔진에서 직접 수집하는 어댑터를 만들 수도 있었다. 그런데 이미 다른 프로젝트가 그걸 하고 있었다. 양쪽에서 각자 수집하면 값이 어긋나는 날이 온다. 그럼 어느 쪽이 맞는지 알 수 없다.
그래서 가격은 무조건 지정된 API를 소비한다. 그 API가 설정되지 않으면 가격 항목 전체가 N/A(휴면)가 된다. 없는 데이터를 대충 채우는 것보다 없다고 표시하는 편이 낫다.
점수 자체를 API 로 내보낸다
이 엔진의 점수를 다른 프로젝트나 에이전트가 소비한다. 별도 토큰 인증은 두지 않고, VPN 신뢰망 기반 접근 제어를 쓴다.
내부 서비스끼리 토큰을 돌리기 시작하면 관리 대상이 늘어난다. 이미 네트워크 경계가 있으면 그걸 신뢰 경계로 쓰는 편이 단순하다. 앞서 포트·바인딩 이야기에서 적었듯 인터페이스 자체가 경계가 되는 구조다.
정리
- 예측 점수는 검증할 수 없다. 근거 점수는 항목별로 확인할 수 있다
- 가점만 있으면 나쁜 신호가 반영되지 않는다. 감점 항목이 필요하다
- 데이터가 부족한 대상을 “해당 없음”으로 넘기면 정보가 없을수록 유리해진다
- 신뢰도를 곱해 점수를 깎고, 임계 미만은 아예 별도 등급으로 뺀다
- 데이터 부재가 대상의 문제인지 내 설정의 문제인지 구분한다. 후자는 신뢰도에서 뺀다
- 같은 데이터를 두 곳에서 수집하지 않는다. 어긋나는 날 어느 쪽이 맞는지 알 수 없다