🇰🇷 리액트 컴포넌트를 한글로 만들어도 될까?

SCM 프로젝트 개발 과정에서 가장 어려웠던 것 중 하나는 변수 및 컴포넌트의 이름을 정하는 일이었습니다. 프로젝트의 특성상 “견적요청등록”, “견적품 공정정보”와 같은 도메인 특유의 용어들이 자주 등장했는데, 이를 영어로 번역하여 프로젝트에 적용하다 보니 가독성과 생산성이 떨어지고 유지보수가 어려워졌습니다. 특히, 유사한 이름을 가졌지만 다른 기능을 가진 컴포넌트들이 많아져서 협업하거나 요구사항에 대응하는 것이 더 어려워졌습니다.

예를 들어 “견적품공정외주처값”에 대한 수정 요청이 생기면, 개발자들은 해당 용어의 영문 컴포넌트명이 무엇인지부터 생각해내야 했습니다. 이러한 용어들을 억지로 영어로 번역하다 보니 실제 SCM 서비스를 사용하는 직원들조차 생소한 용어들을 개발에 사용하게 되었고, 회사 내 사용 용어와 개발 용어 간의 괴리가 심화되었습니다. 이에, 실무 환경에서는 영어 사용이 거의 없음에도 불구하고 왜 실무와 동떨어진 용어들로 프로젝트를 구성해야 하는지 의문이 들기 시작했습니다.

이러한 문제를 해결하기 위해 리액트 컴포넌트명을 한글로 변경하는 방안을 고민하기 시작했습니다. 처음에는 한글 컴포넌트가 조금 낯설고, 특히 호환성 문제가 걱정되어서 여러가지 레퍼런스를 찾았으나, 단순한 구글링으로는 한글 컴포넌트 사용에 대한 신뢰할 만한 자료를 찾기가 힘들어서 직접 타당성 검토를 진행했습니다.

한글 컴포넌트 고려사항

1. 호환성 및 인코딩 문제

한글 컴포넌트 사용의 가장 먼저 걱정된 것은 유니코드 문자 처리와 관련된 호환성 문제였습니다. 물론 대부분의 개발 환경과 도구들이 유니코드를 지원하기 때문에 큰 문제가 없을 것이라고 예상했고, 실제로 한글 컴포넌트를 테스트했을 때 이름이 깨지거나 오류가 발생하는 경우는 없었습니다. 그러나 특정 환경이나 오래된 라이브러리에서는 호환성 문제가 발생할 가능성이 있을 수도 있다고 생각했습니다.

이와 관련해서는 진유림님의 실무에서 바로 쓰는 Frontend Clean Code 발표와 토스에서의 한글 컴포넌트 사용 사례를 참고했습니다. 이 사례들은 한글 컴포넌트 사용이 토스와 같은 복잡하고 큰 서비스의 실제 환경에서도 문제 없이 적용되고 있다는 것을 보여줬고, 우리 프로젝트에서도 한글 컴포넌트를 사용하는데 큰 지장이 없다고 판단했습니다. 물론, 오래된 라이브러리에서의 호환성 문제는 여전히 염두에 두어야 할 수도 있지만 이로 인해 얻는 가독성 향상과 같은 이득이 더 크다고 판단했습니다.

2. 기존 코딩 컨벤션(ESLint)과의 불일치

한글 컴포넌트 사용 시 또 다른 문제는 기존 ESLint 규칙과의 불일치였습니다. 특히 저희 프로젝트의 경우에는 react/jsx-pascal-case 규칙에 의해 경고가 발생했습니다. 이 문제를 해결하기 위해 eslint 설정에서 규칙을 영어일 경우에는 그대로 기존 규칙을 따르고, 한글이 포함된 경우에만 규칙을 적용하지 않도록 커스텀하였습니다. 이를 통해 코드의 일관성을 유지하면서도 한글 명명의 유연성을 확보할 수 있었습니다.

{
  "rules": {
    "react/jsx-pascal-case": ["error", { "ignore": ["*[가-힣]*"] }]
  }
}

3. 자동완성의 어려움

한글 컴포넌트 사용 시 자동완성 기능에 문제가 발생하는 경우도 있었습니다. 특히 VSCode 환경에서 자동 import 기능이 제대로 작동하지 않는 경우가 있었습니다. 이 문제는 컴포넌트명 앞에 회사명의 이니셜을 붙이는 방식으로 해결했습니다. 예를 들어, "J견적품분류정보"와 같이 명명함으로써 자동완성 기능을 원활하게 사용할 수 있었습니다.

---

결론

위 내용을 바탕으로 한글 컴포넌트 사용에 대해 건의하였고, 팀과의 논의 끝에 백엔드와의 통신에 필요한 부분은 기존 방식을 유지하되 프론트엔드 내부에서만 사용하는 컴포넌트의 이름은 한글로 변경하기로 결정했습니다. 특히 영어로 번역했을 때 의미가 명확하지 않거나 괴리가 발생하는 경우 새로 만드는 컴포넌트에 한해 점진적으로 적용하기로 했습니다.

이러한 결정은 프로젝트에 긍정적인 영향을 미쳤습니다. 한글 컴포넌트명을 사용함으로써 가독성이 크게 향상되었고, 개발자들이 컴포넌트의 기능을 더 빠르고 정확하게 이해할 수 있게 되었습니다. 또한, 컴포넌트의 한글명과 관련 요청사항의 영어명을 일일이 매칭할 필요가 없어져 생산성도 상당히 향상되었습니다.

물론, 한글 컴포넌트 사용이 일반적이지 않으며 국제적인 접근성을 고려해야하거나 다양한 협업 환경에서는 적합하지 않을 수 있습니다. 그러나 저희 프로젝트와 같이 복잡한 도메인 용어로 인해 어려움을 겪는 경우에는 한글 컴포넌트 사용을 진지하게 고려해볼만하다고 생각합니다. 혹시 저희와 비슷한 이유로 한글 컴포넌트 사용에 대해 고민 중이시라면 저희 사례가 어느 정도 참고가 되었으면 합니다. :)