리액트 문자열 원격관리 시스템 구축기 with 깃허브 액션, 슬랙커맨드 🚀

Published in

MJ Studio

11 min readAug 29, 2020

https://www.rockandnull.com/android-viewmodel-resources/

React Native 프로젝트에 적용한 슬랙봇을 이용한 편리한 원격 문자열 관리 시스템을 소개하려고 합니다. 상세한 코드보다는 이러한 시스템을 만들게 된 문제 상황과 해결 방법, 기능들을 주로 글에 담아보았습니다.

기능 & 사용된 라이브러리

시작하기 전에 앞서, 글에서 소개하려는 구축한 시스템의 기능과 사용한 라이브러리 및 API 들을 나열합니다.

기능

깃허브에서 원격으로 앱에 쓰이는 문자열들을 바꿀 수 있음
슬랙 봇의 커맨드를 통해 원하는 문자열의 Key, Value 값을 로컬에 저장
깃에 커밋하듯이 슬랙 봇의 커맨드를 통해 Push해서 PR을 만들 수 있음
슬랙 봇의 커맨드를 통해 커밋 기록 열람, 불러오기 등 가능
개발에 대해 몰라도 쉽게 사용하고 디자이너, 마케터가 앱내 문자열을 개발자에게 요청하지 않고 바꿀 수 있음
PR은 깃허브 액션이 만들고 이 과정에서 자동으로 jest의 스냅샷 테스트도 실행되어 앱에 어떤 영향을 주는 지 확인하고 안전한 배포 가능

라이브러리 & API

Github Action
Slack bot

문제 상황

저는 1인 개발을 하고있기 때문에 꽤나 바쁩니다. 아키텍처 설계, 도메인 모델 관리, UI 컴포넌트 개발, 테스트 코드 및 유틸리티 개발, 그로스 마케팅에 사용되는 AB 테스팅 환경 구축, 이벤트 로깅(Firebase, Facebook, Adbrix, Airbridge, Amplitude), dependabot이 물어다주는 package bump PR 확인, 미들웨어 개발, CI/CD 구축, 기획 회의 참여, 디자이너와의 회의, 서버 팀과의 회의, 앱 건의사항 해결, 버그 수정 및 재배포 등 앱개발과 관련된 것 말고도 사내 몇 가지의 노무업무를 도와주는 슬랙 봇 개발 등을 맡아하고 있으니 제가 시간낭비를 하면 프로젝트엔 꽤나 타격이 가게됩니다.

이 중에서 상당히 귀찮은 일중 하나는 문자열 관리였습니다. 가끔 오타도 들어가고 기획쪽의 의견에 따라 자잘하게 수정해야 할 부분이 한 두군데가 아니였습니다. 스케치나 제플린에 스크린이 업데이트가 되도 전 정신이 없기때문에 뭐가 바뀐건지 하나하나 따져가며 JSON 파일에 반영해서 커밋을 하는것은 상당한 노동이며 실수가 생기기 쉽습니다.

게다가 로컬에서 커밋을 하고 재배포를 해야 문자열이 업데이트가 되기때문에 code-push를 사용하지 않기때문에 재배포가 될때까지 플레이 스토어와 앱스토어 심사를 동시에 맡겨 하루 이틀 이상 시간이 소요된 다음에야 반영이 되니 꽤나 난감한 상황이었습니다.

즉, 정리하자면 다음과 같은 문제점들이 있었습니다.

배포하는 데 오래걸림
문자열 수정이 번거롭고 시간이 많이듦 + 실수가 잦아짐
기획팀과 동기화가 안되어서 어떤 문자열이 현재 들어가야 하는 것인지 혼란스러움

해결 방법

1

우선, 1번 문제는 해결이 그렇게 어렵지는 않습니다. 앱이 처음 실행될 때, 네트워크 요청을 통해 원격에 있는 문자열들을 가져와 저장해두고, 앱 내에 문자열을 가져오는 함수에서 원격에서 가져온 동일한 Key를 가진 문자열이 있다면 그걸로 덮어씌우기 해서 보여주는 식으로 해결을 하면 됩니다. Lokalise 같은 서비스도 있지만 저는 그런 서비스를 붙이는걸 별로 안좋아해서 직접 Github에서 받아오는 식으로 구현했습니다.

2, 3

2, 3번 문제는 조금 더 까다롭습니다. 애초에 저는 개발만 하는데 기획적으로 A라고 부르던 걸 B라고 용어가 바뀌었다는 걸 알 필요도 없고 알고싶지도 않습니다. 게다가 그 A라는 용어가 앱의 거의 모든 화면에 들어가있다면 이건 하루 날잡고 문자열만 노가다로 바꿔도 제가 한 기획, 디자인도 아니니까 결국엔 실수가 생겨서 안바뀐 부분이 존재할 수도 있고 오타와 같은 문제가 생길 가능성이 농후하겠죠.

저는 그래서 제가 관여안하고 직접 기획팀의 누군가가 문자열을 바꾸고 그 영향을 제가 검증하고 승인하여 앱의 문자열이 변경되는 시스템을 구축하려고 했습니다. 하지만 개발자가 아닌 팀원에게 저장소를 clone 해서 문자열을 바꿔서 PR을 날려달라고 하면 웬만큼 진보적인 사내 문화가 아닌이상 난감한 상황이 발생할 수도 있겠죠(개인적으론 꼭 개발자가 아니더라도 깃허브 정도는 쓸 줄 알아야 한다고 생각합니다).

그래서 저는 사내의 슬랙봇을 이용해 문자열들을 하나의 작은 Git 처럼 로컬에 커밋하고 푸시를 하여 PR을 날려주면 제가 review하고 merge를 하여 앱에 안전하게 배포할 수 있는 flow를 구축했습니다.

다음은 실제 실행 스크린샷입니다.

이 기능을 이용해 저는 문자열에 신경을 하나도 안쓰고 팀원들이 알아서 PR을 날려주고 승인만 하면 되는 사람이 되었습니다. 제가 저의 일을 덜었을 뿐더러 소통 비용을 많이 줄이고 여러 이점을 챙겼습니다.

이제 대략적인 기능 구현을 살펴보겠습니다.

기능 구현

1. 리액트(네이티브) 앱에서 원격의 문자열 동기화

리액트에서는 주로 i18n 이나 i18n-next 같은 자바스크립트 라이브러리들을 통해 JSON 형식의 문자열 파일을 관리하게 됩니다. 이는 보통 다음과 같은 형식일 것입니다.

ko.json

{
  "COMMON_APP_NAME": "수학대왕",
  "COMMON_YES": "예",
  "COMMON_NO": "아니오",
  "COMMON_OK": "확인",
  "COMMON_CANCEL": "취소",
  ...
}

그리고 보통 다음과 같이 Key와 interpolation 객체를 넘겨 원하는 문자열을 생성하는 함수를 사용할 수 있겠죠.

getString.ts

export function getString(key: string, mapObj?: object): string {
  /* 1. Github remote strings */
  const githubFetchedValue = GithubString.fetchedStrings[key];

  if (typeof githubFetchedValue === 'string' && githubFetchedValue.length > 0) {
    return interpolateArguments(githubFetchedValue, mapObj);
  }

  /* 2. Local ko.json with i18next */
  if (mapObj) {
    return i18next.t(key, mapObj);
  }
  return i18next.t(key);
}

위의 getString 함수는 만약 GithubString 이란 모듈에서 해당되는 key 값이 미리 저장되어 있으면 그 문자열을 반환하고 아니면 로컬에 있는 문자열을 반환합니다. interpolateArguments 는 interpolation 객체를 이용해 문자열의 placeholder들을 채워주어 문자열을 완성해주는 유틸리티 함수이므로 깊게 살펴보진 않겠습니다.

그리고 GithubString 모듈이 받아오는 문자열 JSON 파일은 이 React Native 앱 저장소의 master branch에 저장되어있습니다. 쉽게 말하면 로컬에서 사용하는 JSON 파일이 바로 그 파일입니다. git pull origin master 를 하면 로컬에 있는 JSON 파일이 master branch에 있는 JSON 파일로 덮어씌워지겠죠.

그러나 큰 차이는 이미 배포가 된 상태에서는 로컬에 있는 문자열을 변경할 수 없지만, masterbranch에 있는 JSON 파일을 업데이트 하기만 한다면 배포가 된 이후에도 문자열을 바꿔서 앱내에서 보여줄 수 있다는 것입니다.

GithubString 모듈은 단순히 fetch 를 이용해 깃허브에 GET요청을 해 문자열을 가져와 저장하는 역할만 수행합니다. 이 과정에서 저처럼 repository 가 private 라면 깃허브 유저 설정에서 API 토큰을 발급해 가져올 수 있습니다. 그리고 저장소의 이름이나 설정이 변하지 않는 이상 특정 저장소의 특정 ref의 특정 파일의 내용을 가져오는 url은 고정되어 있으므로 이를 GET 요청으로 헤더에 토큰을 담아 보내주면 깃허브에 있는 JSON 객체를 받아올 수 있습니다.

2. 깃허브 액션 만들기

깃허브 액션은 깃허브에서 제공하는 CI/CD 컨테이너 환경입니다. 특히 uses 커맨드를 이용해 yml 파일에 다른 public한 저장소에 있는 액션을 기재함으로써 다른 사람이 만든 커뮤니티의 액션을 자유자재로 활용할 수 있다는 점이 매력적입니다. 어떤 종류의 이벤트가 깃허브에서 발생될 때나 직접 API or 브라우저를 이용해 원하는 workflow를 실행시켜줄 수 있습니다.

이런 경우엔 이벤트를 구독하기 보다는 제가 직접 API로 실행을 시켜줘야 하는 방식이기 때문에 후자가 적합하겠죠. 저는 다음과 같은 깃허브 워크플로우 yml 파일을 만들어서 제가 원하는 동작을 해주도록 했습니다.

string-modification.yml

스크립트가 조금 긴데, 각 step마다 주석을 남겨두었으니 천천히 읽으시면 아주 간단할 것입니다. 눈여겨 볼 것은 다음과 같습니다.

workflow_dispatch 타입의 액션 실행조건을 정의해서 제가 직접 API를 통해 실행시킬 수 있도록 했습니다.
jq 라는 JSON을 터미널에서 쉽게 조작할 수 있게 해주는 유틸리티를 이용합니다.
결과 JSON을 아티팩트로 저장합니다. 그러면 액션이 끝난다음에 직접 다운로드 받을 수도 있습니다.
skipTest 라는 input을 받아 만약 true라면 jest의 스냅샷 테스트를 실행시켜 주지 않도록 합니다. 앱에 아무런 영향을 안미치고 스냅샷이 변경되지 않을 것이라는 것을 확신할 수 있을 때 슬랙 커맨드에서 설정하여 commit 할 수 있습니다.
create-pull-request 라는 다른 유저가 만든 깃허브 액션을 사용해 PR을 생성해줍니다. 직접 시도해봤으나 커밋과 푸시를 깃허브 API로 직접 하는것은 절대 쉬운 과정이 아니더군요.

이 액션이 끝난다음에는 다음과 같은 PR이 자동으로 생성됩니다.

위와 같이 문자열 JSON 파일과 문자열과 관련된 파일이 변경되는 것을 확인할 수 있습니다. jest의 스냅샷도 스냅샷 테스트를 거친 후에 PR이 만들어지기 때문에 앱의 어떤 부분이 변했는 지 안전하게 검사할 수 있습니다.

저희 디자이너가 직접 문자열들 끝에 붙어있는 점들을 모두 지우겠다며 슬랙 커맨드를 이용해 PR을 날린 결과물입니다. 저였다면 점들 지우는 데만 하루가 걸렸겠죠.

3. 슬랙봇에서 문자열을 위한 작은 git을 만들고 깃허브 액션 API 실행시키기

사실 이건 그렇게 중요한 부분이 아니라 간단하게만 적겠습니다. AWS EC2에서 돌고 있는 노드 앱에 Bolt라는 슬랙 봇을 만드는 라이브러리를 사용해 커맨드를 입력받고 메모리 캐시나 fs 를 이용해 커밋 기록을 관리한 것 밖에 없습니다.

그리고 Github Action API를 이용해 직접 workflow를 실행시켜 주는 함수는 다음과 같습니다. 다음과 같은 함수만 보아도 절반은 살펴본 것입니다. 자세한 깃허브 액션 API는 링크를 참조해주세요.

GithubUtil.ts

결론

최근에 많은 CI/CD 및 자동화 관련 API와 봇을 직접 만들어보며 이번 글에서 다룬 것과 같은 여러 시스템들을 구축했는데, 하나하나 알아가는 재미가 있었습니다. 이러한 자동화 작업을 필요할 때 마다 구축하는게 적은 팀원으로 큰 Output을 낼 수 있는 이유라고 생각합니다.

제가 슬랙봇에 관련해 글을 쓴 것이 하나 더 있는데, 혹시 관심있으시면 읽어보시면 좋을 것 같습니다.