es-hangul이 해결하려는 문제를 더 뾰족하게 정의하는 것이 필요하다고 생각합니다

[okinawaa]

문제를 수면위로 올려주시고, 너무나 좋은 아이디어를 제공해주신 @suhdonghwi 님 감사합니다 🙇
아래 글은 서동휘님께서, 작성해주신 글을 거의 차용했습니다.

---

주제

좋은 라이브러리들의 공통점은 자신들이 풀고자 하는 통점을 명확하게 정의하고, 오직 그것만 완벽하게 해결한 뒤에 나머지 사항은 외부에 위임한다는 것이에요. es-hangul이 제공하는 여러 함수들을 보니 라이브러리가 지향하는 목표가 어떤 것인이 명확하지 않다는 생각이 들었어요.

es-hangul이 제공하는 유틸은 '한글 유니코드 문자에 대한 도메인 지식이 있어야만 수행할 수 있는 문자열 처리 메서드'에 한정되어야 한다고 생각해요.

Why?

라이브러리의 관심사가 명확하고 좁게 정해지지 않는다면 추후 기능 추가 요청/수정 요청이 들어왔을 때 어떤 것을 수용하고 거절할 것인지에 대한 기준 또한 모호해지는 것이 우려되었어요. 그러면 라이브러리의 유지보수 비용이 계속 증가하고, 결국 범용 문자열 처리로 변질될 것 같다는 생각이 들었습니다.

예시

chosungIncludes : 한글 문자열에서 초성을 검색하는 함수
어떤 한글 문자열이 주어졌을 때 해당 문자열에서 초성만 추출하는 것은 한글 처리에 대한 도메인 지식이 필요하지만, includes라는 동작은 그렇지 않아요.
저는 choseongify("안녕하세요") === "ㅇㄴㅎㅅㅇ"만을 제공하는 것이 더 나은 인터페이스라고 생각해요. 초성을 추출하는 동작은 표준 라이브러리만으로는 구현이 쉽지 않고, 따라서 es-hangul이 이 문제를 해결해주면 나머지 처리(.includes)는 사용자가 원하는 방식, 익숙한 방식대로 진행할 수 있어요.
예를들어 "맛있다 사과"에서 "ㅅㄱ"라는 초성이 몇 번째 index에 등장하는지를 알고 싶다면, es-hangul에서는 현재 마땅한 방법이 없어요. 다만 위에서 제가 제시한 대안대로면 얼마든지 다른 문자열 처리 메서드를 사용할 수 있어서 choseongify("맛있다 사과").search("ㅅㄱ")로 가능하구요.

하고자 하는 일

위 chosungIncludes를 시작으로, 여러 메서드들이 한글 유니코드 문자에 대한 도메인 지식이 있어야만 수행할 수 있는 문자열 처리 메서드 가 되도록 수정하는 Breaking Change를 발생하는 수정사항이 많이 일어나고, es-hangul은 version2로 올라가고자 합니다. 많은 분들의 의견이 궁금해요.

[okinawaa]

@minchodang @chaaerim @tooooo1 논의에 참여하셨던 분들도 멘션 드립니다!

[okinawaa]

@manudeli @minsoo-web 🙇

[po4tion]

저는 @okinawaa 님이 가지신 혹은 앞으로 가야할 방향성에 대해 긍정적으로 생각해요.

앞으로 한글 유니코드 문자에 대한 도메인 지식기반 범주로 es-hangul이 운영된다면, 지금보다 더 전문성을 갖춘 라이브러리가 될 것 같네요. 또한, 많은 개발자들이 es-hangul에 기여하기 위해 도메인 지식을 얻는 과정에서 한글이라는 우리나라 언어에 더욱 가깝게 다가갈 수 있을 것 같아요.
그리고 es-hangul에 한글 도메인 지식을 갖춘 컨트리뷰터들이 많아질수록 지금과는 달리 "도메인 지식 기반"으로 만들어진 함수들에 대한 코드 리뷰가 풍부해지고 트러블 슈팅 관련 이슈레이징 사항들도 빨리 해결될 수 있을 것 같아요.

이 논의사항이 긍정적으로 끝까지 진행된다면 es-hangul이 한글을 대표하는 최고의 라이브러리가 될 수 있는 발판이 될 것 같아요.

[minchodang]

저도 @okinawaa 님과 논의 나눴던 대로, 이제 es-hangul은 한글 도메인에 대한 기반으로 코어 로직만 담았으면 좋을 거 같습니다.

물론, v1에서 편의성을 위한 유틸 함수들이 나쁜 시도는 아니었다고 생각해요.
그래서 지금과 같은 기준 점을 마련할 수 있는 논의의 발판이 되었다고 생각합니다.

이번 논의를 토대로, v2에서는 메인테이너께서 생각하셨던 대로 한글 코어 영역을 기반으로 한 순수 한글 도메인 라이브러리가 되었으면 좋겠습니다.
그래야, 기준점이 한글 코어인가 아닌가의 유무(즉, 기준점이 외부 영역인가)에 따라 유틸성 함수의 기준점도 보다 명확해 질 거 같구요.

이를 바탕으로 얼핏 의견 드렸지만, v3에서는 한글 코어 로직 + @로 es-hangul에서만 볼 수 있는 한글 코어 로직 기반 파생 함수들이 다양해 질 거 같습니다.
함께 논의할 수 있어서 감사했고, 만약 특정 유틸 함수(저번 논의 때 ex) amountHangul)가 기준이 모호한 경우, 언제든 discussion을 토대로 논의를 열어 주셔도 좋을 거 같아요.

그래야 다양한 의견을 듣고 발전 시킬 수 있는 오픈 소스의 매력이 더 커질 거 같습니다.

감사함니다.