첫 오픈소스(opensource) 기여 후기

1.  오픈소스에 기여하게 된 계기

    1) 관리가 불편한 번역 파일 

현재 사내에서 운영 중인 플랫폼은 해외 고객에게도 제공하고 있어 번역이 필수이다.

번역을 제공하는 오픈소스 라이브러리 중 redux-i18n을 적용하여 번역을 제공하고 있었다.

먼저, 번역을 제공하려면 번역을 json 파일로 관리해야 했다. 

{안녕하세요: 'hello', 택시: 'taxi', 버스: 'bus'}

하지만 프론트엔드를 개발하다보면 문구가 바뀌고, 새로 추가되고, 삭제되는 경우는 굉장히 빈번한 일이다.

이렇게 문구가 바뀔 때 마다 json 파일을 수정해야하는데 항상 수기로 하다보니 휴먼에러가 누적되어 있어 결국엔 어떤 문구가 사용되고 있는지, 사용 안되는지 파악이 어려워졌다.

    2) 자동화 빌드 스크립트 작성

Toast UI팀에서 우리와 같은 어려움을 겪어 엑셀로 자동화 스크립트를 만들어 관리한다는 글을 보았고 나도 자동화를 시작했다.

다만, Toast UI팀에서는 react-i18n을 사용중이였고 우리는 redux-i18n을 사용중이였다.

redux-i18n의 공식 문서를 보니 react-i18n과 마찬가지로 번역에 사용된 문장을 추출하는 스크립트가 존재하였고 해당 기능을 이용하여 엑셀로 단어 추출 스크립트를 작성하였다.

    3) 오픈소스(redux-i18n의 오류 발견)

redux-i18n에서 제공하는 번역에 사용된 문장을 추출하는 스크립트를 사용하여 단어를 추출하였는데 '한 글자 단어' - ('총', '약')는 추출이 안되는 오류를 발견하였다.

 

2.  오픈소스 수정 

    1) 원인 파악

node_modules안의 redux-i18n의 코드를 파악해보면서 추출 스크립트를 사용할 때 실행되는 함수들을 살펴보았고 원인을 파악했다.

원인은 추출 시 정규식을 통해 번역에 사용된 문장을 인식하는데 해당 정규식이 잘못되어 있었다.

이런 정규식이 왜 이렇게 되어있을까? 고민해본 결과 다음과 같은 결론을 내렸다.

'영어는 한 글자로 이루어진 단어가 없다' ('r' , 's' 이런 단어는 당연히 의미가 없었던 것이다.)

 

    2) 오픈소스 Pull Request

구글에 '깃허브 오픈소스 pr' 관련 검색하면 오픈소스 pr 방법이 자세히 나와 어렵지 않다.

중요한것은 PR하려는 오픈소스에 PR정책이 있는지를 확인해야한다.

따라서, PR 정책도 확인하고 closed된 PR들, Issue 작성법 등을 redux-i18n 깃허브에서 찾아보았고 다행히(?)도 특별한 규칙은 없어보여서 PR 올렸다.
(PR 보러 가기)

 

pull request

PR을 할 때 내가 발견한 오류에 대한 설명, commit 명, test code 작성 등 세세한 내용에 신경을 많이 썼다.

내가 수정한 코드가 나 뿐만 아니라 해당 라이브러리를 사용하는 모든 개발자에게 영향이 가기 때문이다.

(사실.. closed될까봐 조마조마 했는데 다행히 Merged)