[Feature]: romanizeHangulName

[BO-LIKE-CHICKEN]

Description

왜 필요한가요?

romanize는 이미 충분히 잘 동작하고 있지만, romanize가 필요한 일부 도메인에서는 제한되는 부분이 있습니다.

여권 이름 추천 기능

1. 성과 이름을 하나의 인풋에 입력받습니다.
2. 띄어쓰기를 한 형태로 로마자표기된 한글 이름을 보여주세요 / 성에만 볼드처리를 해서 보여주세요

romanize(honggildong)
// honggildong

성과 이름을 따로 받는 경우에는 문제가 되지 않지만, 그렇지 않은 경우에는 romanize를 활용할 수 없습니다.

하여, 성과 이름을 분리한 형태로 라이브러리의 사용자에게 제공하고 사용자가 더 유연하게 사용할 수 있도록 romanizeHangulName을 제안합니다.

이 기능이 필요하다고 느껴지시면 제가 구현해 보도록 하겠습니다 🙏🏻

Possible Solution

성씨 추천이 하나만 있는 경우

2차원 배열로 제공할지 아니면 공백을 넣어서 사용하는 측에서 공백을 기준으로 split할지가 고민 지점입니다.

• “홍” 씨의 경우
• 하나의 성만 추천됩니다.
• [[’HONG’, ’TOSEU’]]
• ['HONG TOSEU']

성씨 추천이 두 개 이상 있는 경우

• “박” 씨의 경우 "BAK" 혹은 "PAK"이 추천됩니다.
• [[’BAK’, ’TOSEU’], [’PAK’, ’TOSEU’]]
• [’BAK TOSEU’, ’PAK TOSEU’]

추론되는 성씨가 두 개 이상 있는 경우

• “선우”씨의 경우 "선우" 혹은 "선"씨로 추론됩니다.
• [’SEONU TOSEU’, ’SEON UTOSEU’]]

etc.

참고

[okinawaa]

좋은 제안 감사해요!
주로 여권 이름을 입력할때는 성과 이름을 별도 인풋에 받는게 일반적이라고 생각했는데, 아닌 경우도 있나 보군요!
성과 이름을 별도 인풋으로 받는게 정책적으로 불가능할 것 같지도 않고, 유저 경험에도 하나의 인풋으로 받는 경우와 차이가 없을 것 같은데 이 기능을 개발이 아닌, 비즈니스적으로 팀원 혹은 정책적으로 소통을 통해 두 가지 인풋을 받는것으로 해결하여 romanize를 사용하는것은 어떤가요??

romanizeHangulName이 여권이라는 특정 도메인 이외에도 다양한 분야에 사용될 일이 많은지 이것을 꼭 es-hangul에서 해결해야하는지 고민을 해보면 좋을 것 같아요!

성 / 이름 을 분리하는것 자체가 마이크로한 함수로 분리할 수 있을 것 같은데, 성 / 이름을 분리하는것도 es-hangul에서 맡아야 하는지 고민이 필요해보이네요!

[BO-LIKE-CHICKEN]

@okinawaa
답변 주셔서 감사합니다!

정확히 필요한 케이스는 "여권 이름을 입력할 때" 보다는 "여권 이름에 입력해야 할 영문 이름을 모르는 경우" 였어요.

저는 여전히 다음과 같은 이유로 이 함수가 니즈가 있을 것이라고 생각되어서 한 번 더 챌린지 해보겠습니다. 🙏🏻

다양한 도메인에서 사용될 수 있다

다음과 같은 경우에 유용하게 사용될 것이라고 생각됩니다.

• 해외배송을 위한 영문명 기입
• 체크카드발급시 영문명 기입
• 앞서 언급한 여권을 제외한 국제 서류 발급에 대한 니즈가 있는 곳에서 이용

DB상에서 성과 이름을 따로 가지고 있지 않을때 이 기능이 유효하게 사용될 수 있어요

"선우토스" 라는 이름이 저장되어있고, 이를 바탕으로 카드 발급시 영문 이름을 추천해주어야 하는데 성과 이름을 구분할 수 없다.
(토스에서도 DB상의 이름으로 영문 이름을 추천해주는 경우가 있는 것 같아 링크를 첨부해요)

이미 니즈가 있었던 기능이다

네이버에서 2024년 6월 13일까지는 해당 기능과 API를 제공해 주었지만, 어떤 이유인지 더 이상 지원해주지는 않더라구요. 물론 대안으로 제시했던 [외교부의 로마자 성명 표기의 기본방법](https://www.passport.go.kr/home/kor/contents.do?menuPos=37) 에서도 해당 기능을 사용할 수 있지만 서비스에 이 기능을 넣고 싶은 플랫폼들은 다른 해결책을 찾아야 해요.

es-hangul에서 맡아야 하는가?

이건 저도 고민이 꽤나 되는 대목이네요 🤔

es-hangul이 공식문서의 설명처럼 최종적으로 궁극의 한글 라이브러리가 되는것이 목표라면

한글을 위한 모든 인터페이스를 제공하는 것을 목표합니다

저는 이미 잘 짜여진 core 함수들을 바탕으로 tree-shakable하면서 니즈가 확실히 있는 함수들은 추가되어도 괜찮지 않을까?

라는 생각입니다 🙂

아직 초기이기도 하고 es-hangul의 목적성과 해결하려는 문제가 더 명확해진 이후에 다시 논의해보는 것도 저는 좋습니다!

[okinawaa]

니즈는 충분히 말씀해주셔서 파악이 되었습니다!
한글의 복잡함을 느낄 개발자에게, 충분히 도움도 될 함수라고 생각해요

다만 이미 romanize 함수가 제공되고 있고
이를 한번 더 래핑하는 함수일텐데, 래핑하여 성 / 이름 으로 나누는건 라이브러리 사용 개발자에게 위임해도 되지 않을까 생각이 들기도 하네요
es-hangul에서는 궁극의 한글 라이브러리가 되는것도 목표이지만, 높은 추상화 단계를 가진 함수를 제공하는것은 자율성이 좋지 않아서 지양하고 있습니다. 오히려, 한글 성(last name) 목록을 constant형태로 export해주고 사용하는쪽에서 처리할수도 있을 것 같고요.

하지만 romanizeHangulName이 단순, romanize만 사용하는것이 아닌, 본문의 예시처럼 같은 한글 성이어도 다른 영어 철자로 변환되는 한글적 성질이 있어서 es-hangul에 충분히 구현되도 괜찮은 함수라고 생각하는데 다른분들 의견도 한번 들어보고 싶어요

c.c @po4tion 님, 혹시 이 이슈에 대해서 의견 나눠주실 수 있나요?

[po4tion]

@BO-LIKE-CHICKEN 님 좋은 의견 감사합니다.

제 생각에는 romanizeHangulName이 가지는 기능이 '한글 유니코드 문자에 대한 도메인 지식이 있어야만 수행할 수 있는 문자열 처리 메서드'일지에 대한 의문이 들어요.

현재 존재하는 romanize 함수를 단순 랩핑하여 romanizeHangulName의 기능을 구현해야 하는 것이라면 한글 도메인에 대한 지식이 없더라도 충분히 사용자가 구현할 수 있을 것이라고 생각해요.

이는 es-hangul이 제공하는 유틸적 기능의 방향성이에요. #176 에서 참고하실 수 있어요.

@okinawaa 님의 의견처럼 단순 romanize를 활용하는 것이 아니라 한글 도메인에 대한 지식이 필요로 하는 것이라면 romanizeHangulName 기능이 구현되어도 좋다고 생각해요.

[BO-LIKE-CHICKEN]

@po4tion 님 함께 고민해 주셔서 감사합니다!

저는 해당 함수가 단순 기본 함수를 랩핑한 함수가 아니라는 생각에 제안드렸어요 🙇🏻‍♂️

다음의 경우에는 기본 함수를 활용하여 사용하기에는 구현이 어렵고, 한글의 성(last name)에 대한 이해가 추가되어도 괜찮다고 생각합니다.

성씨 추천이 두 개 이상 있는 경우

• “박” 씨의 경우 "BAK" 혹은 "PAK"이 추천됩니다.
• [[’BAK’, ’TOSEU’], [’PAK’, ’TOSEU’]]
• [’BAK TOSEU’, ’PAK TOSEU’]

추론되는 성씨가 두 개 이상 있는 경우

• “선우”씨의 경우 "선우" 혹은 "선"씨로 추론됩니다.
• [’SEONU TOSEU’, ’SEON UTOSEU’]]

다만,라이브러리가 가고자 하는 방향과 여전히 거리감이 있다고 생각이
드신다면 앞서 @okinawaa 님이 제안주신것 처럼 한글 성(last name) 목록을 constant형태로 export해주고 사용하는쪽에서 처리하도록 상수를 추가하는 방향은 어떻게 생각하시나요?

이 상수 추가나 함수 추가가 필요하다고 생각이 드신다면 상수의 구조나 함수의 시그니쳐도 함께 얘기나눈다면 무척이나 기쁠 것 같아요!

[po4tion]

저는 단순 랩핑이 아니고 한글의 성에 대한 이해가 필요로 하는 기능이라면 상수 추가보다는 romanizeHangulName을 구현하는 것도 좋다고 생각해요.

[okinawaa]

저는 @BO-LIKE-CHICKEN 님이 들어주신 예시를 보니, 한글의 성에 대한 이해가 있어야 풀 수 있는 문제이므로 es-hangul에서 다루는것에 매우 동의하고, @po4tion 님이 제안해주신것처럼, 상수만 export하기보다는 개발자 경험을 높여줄 수 있도록 romanizeHangulName을 제공해주는것이 좋을 것 같아요

함수시그니쳐는 고민 해본 뒤, 남겨볼게요! @BO-LIKE-CHICKEN 님이 제안해주시고, 직접 구현의사도 있으시기때문에
@BO-LIKE-CHICKEN 님이 DRI로서 여러 의견을 듣고 시그니쳐를 정해주시면 될 것 같아요!

[okinawaa]

제가 간단히 생각해봤을때는, 아래 정도 생각이 나네요!

interface RomanizeHangulNameResponse {
  surnames: string[]; 
  givenNames: string[]; 
}

function romanizeHangulName(
  fullKoreanName: string,
): RomanizeHangulNameResponse {
}

[BO-LIKE-CHICKEN]

제가 간단히 생각해봤을때는, 아래 정도 생각이 나네요!

interface RomanizeHangulNameResponse {

  surnames: string[]; 

  givenNames: string[]; 

}



function romanizeHangulName(

  fullKoreanName: string,

): RomanizeHangulNameResponse {

}

함수 시그니쳐에 대한 의견 주셔서 감사해요!
저도 시간을 조금 더 투자해서 인터페이스나 예외적인 상황을 고민해보고 한번 더 의견드리겠습니다.

@po4tion 님 함께 고민해 주셔서 한번 더 감사드려요! 🙇🏻‍♂️