👤 성명 → 성 · 이름 분할
한 줄에 하나씩 성명을 붙여넣으면 공백 구분 → 300+ 성씨 사전 → 2자 성 기본값 순으로 추정합니다. 신뢰도 표시, 인라인 수정 후 CSV / TSV 출력. 읽기는 약 50 KB 내장 사전으로 즉시 부여.
기본은 브라우저 처리. 고정밀 모드 체크 시 MeCab 서버 처리 (로그 없음).
⚠️ 정확도 주의
100% 정확하지 않습니다. 복합 성 · 희귀 성 · 외국인 이름은 오판 가능. 출력 전 수동 확인 필요.
읽기는 내장 사전(약 50 KB)을 사용. 즉시 동작하지만 드문 고유명사·난독 한자는 빈칸이 될 수 있습니다.
🔒 개인정보 보호
- ・모든 처리는 브라우저 내에서 완료됩니다
- ・이름 데이터는 서버로 전송되지 않습니다
- ・저장 로그 · 업로드 기록 · 데이터베이스 없음
📖 자주 걸리는 지점
성명을 성과 이름으로 분할하고 읽기를 추정합니다. 기본값은 브라우저 안의 내장 사전으로 끝나고 고정밀 모드를 골랐을 때만 MeCab 에 의한 서버 처리를 합니다(로그는 남기지 않습니다). 이 처리는 원리적으로 100% 가 되지 않습니다 — 어디서 자를지도 어떻게 읽을지도 표기만으로는 정해지지 않기 때문입니다. 같은 네 글자라도 자르는 위치는 사람마다 다르고 같은 표기라도 읽기는 본인마다 다릅니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 분할할 수 없는 · 잘못 분할되는 이름이 있다 | 내장 성 사전은 300 건 이상을 최장 일치로 대조하지만 드문 성 · 복합성 · 지명 유래의 성은 빗나갑니다. 더 근본적인 문제로 성과 이름이라는 틀 자체가 보편적이지 않습니다 — 아이슬란드에는 가족이 공유하는 성이 없고(부칭을 씁니다) 인도네시아에는 단일한 이름만 갖는 사람이 있습니다. 일본 국내에 한정해도 미들네임이 있는 사람, 통명과 본명을 함께 적는 사람, 혼인으로 성이 바뀌어 옛 성을 함께 적는 사람이 있습니다. 잘못 분할한 결과는 단순한 데이터의 오류가 아니라 그 사람의 이름을 틀린다는 결례가 됩니다. | 신뢰도가 낮음인 행은 반드시 사람이 확인하세요 — 이 도구가 신뢰도를 돌려주고 있는 것은 전건을 눈으로 보는 것은 현실적이지 않으므로 봐야 할 행을 좁히기 위해서입니다. 공백 구분으로 분할할 수 있었던 것은 높음, 사전에 최장 일치한 것은 중간, 그 외는 낮음이므로 낮음만 확인하면 노력 대비 효과가 가장 커집니다. 그리고 설계의 이야기로 더 중요한 것은 애초에 분할이 필요한지를 다시 묻는 것입니다 — 폼에서 성과 이름을 따로 입력하게 하는 설계는 일본 국외의 이용자나 단일 이름인 사람을 튕깁니다. OO 님이라고 부르고 싶을 뿐이라면 분할은 불필요하고 성명을 하나의 필드로 받아 그대로 표시하는 편이 정확합니다 — 분할로 생기는 오류 쪽이 분할하지 않음으로써 생기는 불편보다 큰 경우가 많습니다. |
| 읽기가 공란이 된다 · 틀렸다 | 같은 표기에 복수의 읽기가 있고 어느 것이 옳은지는 본인만 압니다. 東海林 은 쇼지 라고도 도카이린 이라고도 읽고 둘 다 실재하는 성입니다. 新谷 는 신타니 · 니이야 · 아라야, 中田 는 나카타 · 나카다 — 이들은 방언이나 지역차가 아니라 집안마다 다르므로 사전을 아무리 충실히 해도 기계적으로는 정해지지 않습니다. 이름 쪽은 한층 더 자유로워 같은 한자에 어느 읽기를 붙일지는 이름 지은 쪽의 재량입니다. 난독의 고유명사나 옛 자체에서는 애초에 사전에 없으므로 읽기가 공란이 됩니다. |
읽기는 본인에게 입력받는 것이 유일한 정답입니다. 신청 폼이나 회원 등록에서는 성명 칸과 나란히 후리가나 칸을 준비하세요 — 추정에 기대지 않는 것이 정확성의 점에서도 예의의 점에서도 최선입니다. 이 도구가 도움이 되는 것은 읽기 칸이 없는 채로 축적되어 버린 기존 데이터를 보완할 때이며 그 경우에도 추정한 읽기를 확정값으로 저장하지 마세요 — 추정임을 알 수 있는 형태(별도 열, 플래그 붙임)로 갖고 본인과 접촉할 기회가 있으면 확인해 덮어쓰는 것이 올바른 취급입니다. 추정한 읽기를 명부의 정렬이나 수취인의 읽어 주기에 그대로 쓰면 잘못이 겉으로 드러납니다. |
| 고정밀 모드의 전제를 확인하지 않은 채 쓴다 | 고정밀 모드는 MeCab 에 의한 형태소 분석을 서버에서 실행하므로 입력한 성명이 네트워크를 통해 전송됩니다. 이 사이트는 로그를 남기지 않고 처리 직후에 파기하지만 전송된다는 사실 그 자체가 제약이 되는 장면이 있습니다 — 고객 명부 · 종업원 명부 · 환자 정보처럼 조직의 규정으로 외부 서비스로의 전송이 금지된 데이터는 드물지 않습니다. 성명은 단독으로 개인을 특정할 수 있는 정보이므로 정확도가 올라가니까라는 이유만으로 전환하면 규정 위반이 되어 있을 가능성이 있습니다. | 먼저 기본값인 브라우저 내 모드로 충분한지 시험하세요 — 공백으로 구분된 성명이라면 애초에 사전도 분석도 불필요하고 신뢰도 높음이 돌아옵니다. 실무상 명부 데이터의 상당수는 이미 공백 구분이므로 고정밀 모드가 필요한 것은 공백이 없는 성명이 뭉쳐서 존재하는 경우에 한정됩니다. 그래도 필요한 경우에는 조직의 규정을 확인하고 나서 쓰세요 — 판단의 기준은 그 파일을 메일로 사외에 보내도 되는가 입니다. 보내면 안 된다면 로컬에 MeCab 을 넣어 자기 환경에서 처리하는 것이 올바른 선택입니다(brew install mecab mecab-ipadic / apt install mecab mecab-ipadic-utf8) — 같은 사전 · 같은 엔진이므로 결과는 여기와 동등해집니다. |
성명은 개인정보입니다. 이 페이지의 기본 모드는 브라우저 안에서 끝나고 데이터는 전송되지 않지만 결과를 CSV 나 TSV 로 다운로드한 시점부터는 그 관리가 당신의 책임이 됩니다 — 고객 명부가 다운로드 폴더에 계속 남는다, 안건명을 포함한 파일 이름 그대로 공유된다 같은 사고는 처리 그 자체보다 일어나기 쉽습니다. 파일 이름에 안건명이나 회사명을 넣지 않는다, 작업이 끝나면 삭제한다 같은 취급을 정하고 나서 시작하세요. 마지막으로 설계에 관여하는 입장의 사람에게 한 가지 — 성명을 분할해 저장한다는 설계는 많은 경우에 필요한 것보다 강한 전제를 두고 있습니다. 수취인에 쓸 뿐이라면 분할은 불필요하고 정렬에 쓰고 싶다면 분할이 아니라 읽기가 필요합니다. 정말로 성만 필요한 장면(OO 님이라고 부른다, 성으로 그룹 짓는다)이 얼마나 있는지를 세어 보면 그것을 위해 전 레코드의 정확성을 걸 가치가 있는지가 보입니다 — 분할하지 않는다는 선택지를 맨 처음에 검토하세요.
📖 사용법
-
1
성명 붙여넣기한 줄에 하나씩. 공백 유무 모두 지원.
-
2
분할 실행클릭. 공백 → 사전 → 2자 기본값 순.
-
3
CSV / TSV 다운로드신뢰도 낮음 행은 인라인 수정 후 출력.
❓ 자주 묻는 질문
신뢰도는 어떻게 결정되나요?
복합 성도 정확합니까?
외국인 이름은?
🔗 관련 도구
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.