Gender-API vs. ChatGPT: 이름의 성별은 무엇으로 판별해야 할까
Sandra가 보통 여성 이름이라는 건 둘 다 알려줄 수 있어. 하지만 그걸 어떻게 아는지 설명하고, 내년에도 같은 답을 주고, 시작 전에 100만 건 가격을 제시할 수 있는 건 한쪽뿐이야
짧은 답
- 이름 몇 개에 대한 판단이나 읽을 수 있는 문장이 필요하면 LLM을 써. 설명, 유래, 인사말 같은 것들
- 답이 내일도 똑같아야 하거나, 근거가 함께 와야 하거나, 건당 가격이 나와야 하거나, 개인정보 보호 책임자의 질문을 견뎌야 하면 이름 데이터베이스를 써
- 규모가 커지면 결정적인 차이는 정확도가 아니라 설명 가능성이야. 9,124,598개국에 걸친 192개의 이름, 답마다 자기 표본 수를 갖고 있어. 반대편에는 계산 과정을 보여줄 수 없는 생성이 있어
- 둘은 잘 어울려. 모델에 이 API를 도구로 줘. 그걸 위한 호스팅형 MCP 서버를 공개하고 있어. 그러면 라벨은 데이터에서, 문장은 모델에서 나와
이 둘이 실제로 무엇인가
Gender-API.com는 이름 데이터베이스 위에서 동작하는 조회 서비스야. 관측된 국가별로 나뉜 9,124,598개의 이름, 192개국 지원. 이름을 보내면 성별과 확률, 그리고 그 답이 근거로 삼은 표본 수가 돌아와. 생성되는 건 아무것도 없어
ChatGPT는 — 다른 모든 범용 언어 모델과 마찬가지로 — 텍스트 생성기야. “Sandra”가 여성 문맥에 나온다는 걸 아는 건 학습 텍스트에서 그 단어가 그렇게 쓰였기 때문이야. 이건 실제로 유용한 신호이고, 흔한 이름이면 올바른 라벨을 내놔. 하지만 포르투갈에서 몇 명의 Sandra가 여성이었는지 저장하는 장치는 구조 어디에도 없어. 인용할 것도, 기준선을 둘 대상도, 감사할 것도 없다는 뜻이야
이 하나의 구조적 사실이 아래의 모든 실무적 차이를 만들어
나란히 비교
어떤 모델을 고르든 그대로 남는 차이들
| 필요한 것 | Gender-API.com | 범용 LLM |
|---|---|---|
| 같은 입력에 매번 같은 답 | 그래 — 데이터베이스 조회니까 | 아니 — 샘플링, 프롬프트 문구, 모델 버전이 다 답을 흔들어 |
| 하나의 답 뒤에 있는 근거 | 결과별, 국가별 표본 수와 확률 | 없어. 확신도를 물어봐도 그 숫자 자체가 생성된 거야 |
| 문서로 밝힐 수 있는 커버리지 | 이름 9,124,598개, 192개국 | 알 수 없고 명시도 안 돼 있어 |
| 국가별 답 | 국가나 locale, IP 파라미터가 결과를 바꿔 | 프롬프트에 적었을 때만. 그래도 여전히 추측이야 |
| 12개월 뒤의 동작 | 같은 엔드포인트 규약을 OpenAPI로 공개. v1과 v2 모두 살아 있어 | 모델은 폐기되고 교체돼. 답도 함께 움직여 |
| 대량 처리 | 요청당 이름 100개, 또는 최대 1000만 행 CSV | 컨텍스트 한계, 분할, 레이트 리밋, 재시도를 직접 구현해야 해 |
| 비용 단위 | 조회당 credit 하나, 미리 구매한 패키지에서 차감 | 입력과 출력 토큰 — 프롬프트 길이와 재시도에 따라 달라져 |
| 데이터가 처리되는 곳 | 서버는 독일, 처리는 EU 내, DPA는 요청 시 제공 | 공급업체와 요금제, 배정된 리전에 따라 달라 |
| 전체 이름 분리, 이메일 주소에서 이름 추출 | 전용 엔드포인트가 있어 | 프롬프트를 손봐야 하고, 경계 사례에서는 조용히 실패해 |
| 아무도 데이터를 가지고 있지 않은 이름 | 그렇다고 말해줘 — result_found가 false이거나 확률이 낮아 | 그래도 답해. 똑같이 자신 있는 말투로 |
| 이름과 그 유래, 변형을 설명하기 | 그런 용도가 아니야 | 정말 더 나아 — 언어 모델은 이걸 위해 있어 |
이름 100만 건의 성별 판별에는 얼마가 들까
마케팅용 숫자 대신 계산 방법을 적어둘게. 오늘 단가로 직접 다시 계산할 수 있어
API를 쓰면: 조회 한 번이 credit 하나야. 공개된 최적 대량 단가는 이름 1,000개당 약 €0.35이니까, 100만 건은 대략 €349(부가세 별도)야. 시작 전에 아는 고정 금액이고, VAT 청구서가 나와. 단건 패키지의 credit은 만료되지 않아
LLM을 쓰면: 요청마다, 재시도마다, 입력과 출력 양쪽으로 토큰 단위 과금이야. 여러 이름을 한 프롬프트에 묶으면 건당 비용은 내려가지만, 배치마다 지시문을 다시 보내야 하고, 긴 이름이나 낯선 문자 체계는 짧은 것보다 토큰을 더 쓰고, 형식이 깨진 답은 재시도 비용까지 물려. 결과는 추정치이고, 예산에 적을 수 있는 숫자는 아니야
공정하게 말하면, 몇 천 건 정도면 범용 모델은 충분히 싸서 이 얘기 전부가 의미 없어. 갈림길은 규모와 함께 와. 그리고 토큰 가격이 시사하는 것보다 빨리 와. 배치 처리와 재시도, 출력 검증을 둘러싼 개발이 조회 엔드포인트에서는 아예 필요 없는 일이기 때문이야
재현성: 보통 이게 결정을 가른다
고객 목록을 두 번 처리해서 서로 다른 결과가 나오면, 설명할 수 없는 문제를 안게 돼. 어느 실행이 맞았는지, 무엇이 바뀌었는지, 그리고 지난달에는 “귀하(남성)”, 이번 달에는 “귀하(여성)”로 불린 그 사람에게 뭐라고 말할지
조회는 결정적이야. 같은 이름에 같은 국가면 같은 성별, 같은 확률, 같은 표본 수가 돌아와. 기반 데이터가 늘어나면 표본 수도 응답 안에서 눈에 보이게 늘어나. 그래서 변화는 그냥 벌어진 일이 아니라, 짚어 보일 수 있는 것이 돼
생성된 답에는 그런 보장이 없어. temperature, 새 모델 버전, 다시 쓴 시스템 프롬프트, 아무도 알려주지 않은 안전성 조정. 어느 하나만으로도 경계선에 있는 이름이 뒤집힐 수 있고, 어느 것도 데이터에 흔적을 남기지 않아
모든 답이 자기 근거를 함께 가져와
v2 엔드포인트에 보내는 요청 하나:
POST https://gender-api.com/v2/gender/by-first-name
{ "first_name": "Sandra" }{
"input": { "first_name": "Sandra" },
"details": {
"credits_used": 1,
"samples": 464,
"country": null,
"first_name_sanitized": "sandra",
"duration": "436ms"
},
"result_found": true,
"first_name": "Sandra",
"probability": 0.85,
"gender": "female"
}생성된 답이 절대 주지 못하는 일을 두 필드가 해줘. “samples”는 그 답이 몇 건의 관측에 근거하는지, “probability”는 그중 여성의 비율이야. 이 둘이 있으면 기준선을 직접 정할 수 있어. 표본 수가 충분하고 0.9를 넘는 결과는 받아들이고 나머지는 수동 검토로 보내는 식이지. 데이터베이스 전체에 하나의 확신도를 적용할 필요가 없어
전체 문서: v2 API 문서
같은 이름이 어디서나 같은 성별은 아니야
Andrea는 이탈리아에서 주로 남성, 독일에서 주로 여성이야. Jean은 프랑스에서 남성, 영어권에서는 대부분 여성이야. Nikita는 러시아에서 남성, 그 밖에서는 보통 여성이야. 특이한 예외가 아니라, 평범한 고객 목록에 있는 평범한 이름들이야
국가를 밝히지 않고 범용 모델에 물으면 학습 텍스트에서 우세했던 해석이 나와. 실제로는 영어권 해석이라는 뜻이야. API는 국가를 명시적으로 받아:
locale(en_US)이나 방문자의 IP 주소도 똑같이 동작해. 그리고 반대 질문, 즉 이름이 어느 국가에서 왔는지에는 별도의 엔드포인트가 있어
GDPR, 그리고 보낸 이름이 실제로 어디로 가는지
실제 고객의 이름은 개인정보야. 그러니 이건 각주가 아니라 구매 판단의 문제야. 우리가 분명히 말할 수 있는 것:
- 우리는 독일 회사야. 모든 서버가 독일에 있고 데이터는 EU 안에서 처리돼
- 데이터 처리 계약은 계정에서 요청할 수 있어
- 서버 로그에는 전송된 이름이 담기고, 회계상의 이유로 14일 보관돼
- 업로드한 CSV와 Excel 파일은 암호화되어 저장되고 10일 후 삭제돼
- 모든 구매에서 정식 VAT 청구서가 발행되고, EU VAT 번호도 올바르게 처리돼
특정 모델 공급업체를 같은 데이터에 써도 되는지는 너희 개인정보 보호 책임자가 판단할 문제야. 다만 그건 더 긴 검토이고, 공급업체가 재처리자를 바꿀 때마다 다시 물어야 해. 우리 쪽 답은 개인정보 개요에 있어
ChatGPT가 더 나은 경우
답이 항상 “API를 사라”라면 이 페이지는 읽을 가치가 없겠지. 그렇지 않아
- 한 번뿐인 작업. 스프레드시트에 이름 마흔 개, 파이프라인 없음, 다시 돌릴 사람도 없음
- 라벨이 아니라 이유가 필요할 때. 이름의 유래, 변형, 보통 어떻게 줄여 부르는지, 특정 문화에서 정중하게 부르는 방법
- 어떤 데이터베이스에도 없는 이름. 새로 만든 말, 가상의 인물, 어느 등록부에도 없는 음역. 조회가 아무것도 갖고 있지 않은 곳에서 모델은 합리적인 추측을 내놔
- 출력으로 필요한 게 필드가 아니라 자유 문장일 때. 성별 열이 아니라 인사말 한 줄
관대해서 하는 말이 아니야. 우리도 똑같이 쓰고 있어. 자체 이름 페이지의 유래 설명은 언어 모델이 생성해. 문장은 언어 모델이 잘하는 일이니까
가장 좋은 건 둘 다야: 모델이 API를 호출하게 해
이미 LLM 위에서 만들고 있다면 고를 필요가 없어. 요즘 모델은 도구를 호출하고, 성별 조회는 이상적인 도구야. 범위가 좁은 질문이고, 답은 사실이고, 모델에는 그 데이터가 없으니까
MCP를 지원하는 어시스턴트나 에이전트가 데이터베이스를 직접 조회할 수 있도록 호스팅형 MCP 서버를 공개하고 있어. 도구는 query_first_name, query_full_name, query_email, get_country_of_origin, get_statistics야
직접 도구를 정의할 때 쓸 수 있도록 아홉 개 언어(PHP, Python, Node, Java, Go, Ruby, Rust, Perl, .NET)의 공식 클라이언트, OpenAPI 명세, 그리고 /skill.md에 코딩 어시스턴트에 그대로 넘길 수 있는 구현 가이드가 있어
이 역할 분담이 핵심이야. 무엇을 할지는 모델이 정하고, 무엇이 사실인지는 데이터베이스가 정해
자주 묻는 질문
ChatGPT가 이름으로 성별을 판별할 수 있어?
할 수 있고, 흔한 이름이면 대체로 맞혀. 못 하는 건 그 답이 몇 건의 레코드에 근거하는지 알려주는 것, 같은 답을 두 번 보장하는 것, 같은 이름을 다른 국가에서 다르게 답하는 것이야. 게다가 한 번도 본 적 없는 이름에도 똑같이 자신 있게 답해. 규모가 커질 때 문제가 되는 건 바로 이 실패 방식이야
성별 판별 API가 LLM보다 정확해?
이름 데이터베이스에 있는 이름이라면 조회는 구조상 정확해. 추론이 아니라 관측된 분포를 그대로 알려주기 때문이야. 모르는 이름에서는 두 방식 다 믿을 수 없지만, 그걸 인정하는 쪽은 조회뿐이야. 믿을 수 있는 차이는 하나의 정확도 수치가 아니라, 모든 조회에 표본 수와 확률이 함께 오고 거기에 기준선을 둘 수 있다는 점이야
이름 100만 건의 성별을 판별하면 얼마야?
Gender-API에서는 조회 한 번이 credit 하나라서, 100만 건은 고정된, 이미 아는 금액이야. 공개된 최적 대량 단가로 약 €349(부가세 별도), VAT 청구서로, 시작 전에 확정돼. LLM에서는 요청마다 그리고 재시도마다 토큰 단위로 지불하니까, 청구액은 프롬프트 길이에 달렸고 추정만 가능해
LLM과 성별 판별 API를 같이 쓸 수 있어?
쓸 수 있고, 그게 가장 좋은 구성이야. 모델에 이 API를 도구로 주면 돼. 바로 그걸 위해 호스팅형 MCP 서버를 공개하고 있어. 그러면 라벨은 데이터베이스에서, 문장은 모델에서 나와. 모델은 데이터가 없는 사실을 추측하지 않게 돼
같은 이름이 모든 국가에서 같은 성별이야?
아니야, 그리고 국가 없이 던진 프롬프트가 틀리는 지점이 정확히 여기야. Andrea는 이탈리아에서는 주로 남성, 독일에서는 주로 여성이야. Jean은 프랑스에서는 남성, 영어권에서는 대부분 여성이야. API는 국가나 locale, IP 주소를 받아서 그 국가에 맞게 답해
데이터베이스가 모르는 이름은 어떻게 돼?
result_found: false가 오거나, 표본 수가 적고 확률이 낮은 결과가 와. 그건 대응할 수 있는 신호야. 그 레코드를 수동 검토로 보내거나 모델로 넘기면 돼. 생성된 답은 그런 신호를 전혀 주지 않아
Gender-API는 GDPR을 지켜?
우리는 독일 회사이고, 모든 서버가 독일에 있고 데이터는 EU 안에서 처리돼. 데이터 처리 계약은 계정에서 요청할 수 있어. 전송된 이름이 담긴 요청 로그는 회계상의 이유로 14일 보관되고, 업로드한 CSV와 Excel 파일은 암호화되어 저장된 뒤 10일 후 삭제돼
네 이름 목록으로 시험해 보기
모든 계정에 매월 무료 조회 100회가 포함돼. LLM이 틀린 이름을 확인하기엔 충분해. 신용카드 필요 없어
