연락처에서 성 이름을 추출하는 방법 고민

shint 님은 뭐하시는 분인지 저도 잘 모르겠네요. kldp에 글올린건 처음이고 첫 댓글이 달려서 반가운 마음에 읽어봤는데, 뭔가 내용이 구름 잡듯 붕뜬, 저랑은 관계없는 내용이고, 혹시나해서 작성글 검색해보니 죄다 영양가 없는, 무쓸모 댓글만 널려있네요.

한 일주일동안 제 연락처 데이터를 계속 들여다봤습니다. 한 400개 남짓 있는데, 친한 친구한테도 달라고 해서 700개 정도 되는 연락처를 하루에 몇시간씩 멍하니 들여다보면서 아이디어를 고민했던거 같아요

원래 목표는 연락처에서 성 이름 파싱해서, 이걸 바탕으로 성별 추측을 하는게 목표였습니다. 성별 추측은 http://www.erumy.com/nameAnalyze/eDefault.aspx 쪽으로 api 요청을 하려고 했지요. 외국은 이미 머신 러닝 분야에서 gender prediction이 꽤 보편적인 이슈가 되었는데, 이런 연구를 기반으로 할 수 있는 이름,성별 데이터도 미국 정부측에서 제공하고 있었구요 https://www.ssa.gov/oact/babynames/limits.html 근데 국내는 아무리 찾아도 이름 성별 통계 데이터를 제공하는곳이 하나도 없어서, 저 이루미란 쪽에서 만든 통계 데이터를 이용한 성별 예측이 거의 유일한 방법이라고 판단했습니다.

근데 어쨌든 연락처에서 성 이름 추출해서 성별까지 예측하는게 제 목표긴 했는데, 성 이름 파싱이 생각보다 꽤 어려운 작업이다 보니 고민고민하다가, 지금 제 서비스에 과연 성별이 핵심 기능인가...를 더 고민해 보니, 그렇게까지 핵심은 아닌거 같더군요. 그래서 그냥 성 이름 추출은 일주일정도 고민한 선에서 접기로 했습니다. 그래도 한 일주일정도 데이터를 들여다보니 어느정도 추출에 대한 실마리를 얻을 수 있었는데, 혹시 나중에 저와 비슷한 고민을 하시는 분이 있을까봐 흔적을 남겨놓도록 하겠습니다.

1. 일단 성 이름을 파싱하기 전에, 유저의 연락처 저장 행동 방식과 성 이름에 대한 어느정도 가정을 해 놓는게 필요했습니다. 완전히 제로 베이스에서 파싱을 할려고 하면 변수가 너무 많아서 통제가 안되더군요. 근거는 저의 행동 패턴을 근거로....
1) 연락처에 성을 안저장하고 이름만 저장하는 경우는 없다고 가정합니다.
2) 성과 이름 사이에는 띄어쓰기 외에 다른 문자가 오지 않는다고 가정합니다. 띄어쓰기는 있을수도있고 없을수도 있고.
3) 일단 사람 이름이란게 문화권별로 워낙 다양하기 때문에, 여기서 언급하는 모든 방식은 우리나라 사람, 그리고 한글 기준입니다.
4) 우리나라 사람 이름은 대부분 성+이름 3자이기 때문에 3글자 이름을 기준으로 합니다. 그리고 여기서 예외적으로 2글자와 4글자일때 파싱을 하도록 해야 합니다.
5) 아무리 파싱을 잘했어도 100% 신뢰가 불가능하기 때문에, 최종 작업 이전에 파싱 확률이 떨어지는 연락처들에 대해선 유저가 성 이름을 확인하고 입력하는 작업을 추가시켜줘야합니다.
6) 우리나라 성씨는 다행히 100개 내외로 한정되어 있습니다. https://namu.wiki/w/%ED%95%9C%EA%B5%AD%EC%9D%98%20%EC%84%B1%EC%94%A8 여기에서 1000명 이상만 사용하는 성씨 중에서 한자가 달라서 중복되는 성을 다 합쳐보니 120개 내외가 나오더군요 이것들을 familyNameArr에 저장해놓습니다.
7) 각 연락처의 input과 output 은 [(연락처)] -> [(성,이름,태그,확률)] 이 되겠습니다. 유저가 구분하기 위해 추가적으로 달아놓은 태그 문자열은 남겨놓는게 좋을거같더군요.

2. 사전 작업 (pre-processing)
1 ) globalTokenArr 들을 준비해놓습니다.
ㄱ) globalTokenArr 에는 어머니, 아버지, 선생님, 교수님, 대리님 처럼 모든 사람들이 보편적으로 쓸법한 토큰 목록을 의미합니다. 가족 호칭, 직함, 직위 이런것들은 적당히 인터넷에서 사전식으로 구할 수 있기 때문에 미리 저장해 놓습니다.
ㄴ) 이 globalTokenArr는 너무 넓으면 searching space에서 손해가 생기기때문에 최적화 시켜놓는게 중요합니다. 그래서 globalTokenThresholdArr가 필요하게 됩니다. 후술하겠습니다.
ㄷ) 차후에 personalTokenArr도 필요한데 이건 후술하도록 하겠습니다.
2) 사람 이름을 파싱하는게 기본 전제이기 때문에, 사람 연락처가 아닐 경우 일단 배제시켜놓는게 좋습니다.
- 연락처에는 전화번호 필드가 여러개 있습니다. 핸드폰전화번호, 집 전화번호, 회사 전화번호, 추가 전화번호 등등, 뽑아보면 한 6,7개정도 필드가 있는데, 보통은 핸드폰 전화번호에 010~으로 저장하는게 보통이지만, 조작 실수로 집 혹은 회사에 핸드폰 번호를 저장하는 경우도 꽤 있습니다. 저도 그렇구요. 그래서 모든 전화번호 필드를 다 긁은다음에 010 시작하는 필드가 하나도 없으면 non-human 으로 가정하고 빼버려야 합니다.
- 가끔 보면 +82 10으로 시작하는 핸드폰번호도 있기 때문에 이것들 010으로 replacing 해줘야 합니다.
- 국제 번호는 처리 포기... 안습...
3) fullName 필드 만들기띄어쓰기.. 골치아픔
- 성과 이름을, 성/이름 필드에 이쁘게 따로 저장되어 있을수도 있고, 한곳에 몰아서 저장되어 있을 수 있습니다. 따라서 성과 이름을 concat 시킨 fullName 필드를 따로 만들어서 이걸 source string 으로 보는게 합당합니다.
- 이름 필드에 성과 이름을 몰아넣을때 띄어쓰는 사람도 있고 안띄어쓰는 사람도 있습니다. "홍 길동 날쌘돌이" 처럼 이쁘게 성, 이름, 태그 사이에 띄어쓰기를 했으면 참 고마운데, "홍길동날쌘돌이"처럼 하는 경우도 있습니다.
- fullName을 만들때 띄어쓰기 한칸을 넣어야 하나 말아야하나? 결론은 넣는게 좋을거같다 입니다. 후술 하겠습니다.
4) 사전 작업 의 결과는 iOS나 android에서 연락처에 쓰이는 모든 필드 중에서 필요한 부분만 파싱한 필드들+fullName 필드가 됩니다.
(raw 연락처) = (성,이름,경칭,중간이름,호칭,닉네임,휴대폰번호,이메일,그룹명,회사번호,집번호,회사Fax번호,집Fax번호, 기타번호, .......)
(pre-processed 연락처) = (성,이름,fullName, 휴대폰번호)

3. iterating : for contact in preProcessedContactsArr
- iterating 은 정말 단순하게 length와 globalTokenArr 매칭을 기준으로 한 분류입니다.
1) fullName length 를 기준으로한 필터링
ㄱ) fullName length == 4 이면서, (word) + (space) + (word)(word) 인경우
a) 첫번째 word가 familyNameArr 에 해당할 경우 && 첫번째 word가 "성"필드 값과 일치할경우 => highest 확률 부여 // 이건 원래 성/이름 필드에 있던 성/이름이 fullName에 "성 이름"으로 합쳐진 케이스 입니다.
b) 첫번째 word가 familyNameArr 에만 해당할 경우 => 2nd highest 확률 부여 // 이건 이름 필드에 "성 이름" 으로 저장되어 있던 케이스라고 봐야합니다.
ㄴ) fullName length == 3 이면서 (word)(word)(word) 인 경우
a) 첫번째 word가 familyNameArr 에만 해당할 경우 => 3rd highest 확률 부여 // 이건 이름 필드에 "성이름" 으로 저장되어 있던 케이스라고 봐야합니다.
// 1) 에서 필터링 통과하면 확률 부여 후 다음 연락처로 넘어갑니다.
// 참고. 이름이 2자인것과 4자인건 두번째 iterating 단계에서 분류합니다.
// 1) 단계만 해도 꽤 많은 이름이 걸러지게 됩니다 제 연락처 기준 7~80% 정도?
2) globalTokenArr 매칭 필터링
ㄱ) fullName 이 아빠, 엄마, 수학쌤 이런것들과 매칭되면 볼거 없이 lowest 확률을 부여시키면 됩니다.
- globalTokenArr에서 반복적으로 검색을 해야하기 때문에, globalTokenArr은 해시 구조로 만드는게 이득일겁니다
3) 1), 2) 단계에서 필터링 되지 않은 것들에 한해서 tokenMixedContactsArr 로 넘겨주고 5번 스텝으로 넘어갑니다.

4. tokenMixedContactsArr 에서 token 뽑아내기
- 3. 단계를 거치고나면, 성+이름의 길이가 2자인 이름, 4자인 이름, 그리고 성, 이름 앞뒤로 태그가 달린 이름들만 남게 됩니다.
- 모임1 - 홍길동, 모임1 - 김말자 아니면 홍길도 우리과 08, 김말자 우리과 09 이런식으로
- 여기서 문제는 띄어쓰기를 위 예시처럼 이쁘게 했으면 토큰 파싱이 쉬워지는데, 모임1홍길동 모임김말자 홍길동우리과08 김말자우리과09 이런식으로 띄어쓰기 없이 태그를 달았으면 파싱이 어려워집니다. 그래서 좀 트릭이 필요합니다.
1) 띄어쓰기가 잘 되어있으면, 토큰 비교가 쉬워집니다. 띄어쓰기가 잘 안되어있으면 2)로
2) tokenMixedContactsArr 에서 fullName 기준으로 정렬 시키면, 자연스레 같은 태그가 앞에 달린 연락처들은 이쁘게 정렬이 됩니다. 여기서 fullName의 첫번째 문자부터 시작해서 공통된 문자열을 가진 다른 fullName이 있으면 (어차피 연속적으로 존재할겁니다) 늘려나다가 최대길이가 되면 토큰으로 끊고 personalTokenArr에 저장시킵니다. 다만 이 토큰이 familyNameArr에 존재할 경우, 태그가 아니라 성에 해당하므로 토큰에 저장시키지 않습니다. 그리고 토큰을 뺀 뒷 첫문자가 성씨에 들어가는지 확인하고, 나머지 글자 길이가 2이면 성 이름으로 파싱하고 tokenMixedContactsArr 에서 뺍니다.
3) tokenMixedContactsArr에 있는 모든 element들을 reversing 시킵니다.
4) tokenMixedContactsArr를 fullName 기준으로 정렬시키면, 뒤쪽에 있는 토큰을 기준으로 정렬이 됩니다. 2)과 마찬가지 작업을 해주면 뒤쪽에 있는 토큰만 이쁘게 뽑아내면 성,이름만 남게 됩니다

5. personalTokenArr -> globalTokenThresholdArr
1) personalTokenArr에서 생긴 토큰을 globalTokenThresholdArr로 반영시킵니다
2) globalTokenThresholdArr은 매 새로운 유저의 연락처를 파싱할때마다, 내부 값들을 decaying 시킵니다
3) 여러 유저들에게서 자주 발생하는 토큰들은 당연히 threshold값을 증가시킵니다
4) globalTokenThresholdArr에서 일정한 값이 넘으면 globalTokenArr 으로 elevate 시킵니다. (사람별로 자주 발생하는 토큰은 비슷하다는 전제하에 할수있습니다)

어쨌든 여기까지가 제가 생각한 휴리스틱 알고리즘 ㅜㅜ 효율 개떡일거같은데..... 그래서 그냥 성 이름 파싱은 포기할랍니다