[iOS] UX Writing을 보다 편하게 관리하기 위한 노력

1. String 관리는 매우 귀찮다..

첫 앱을 개발할 당시에 길거나 짧은 String을 모오오오두 복붙해서 넣곤 했습니다.

이게 무슨 이야기냐 하면.. 바로 아래와 같이 무식하게 때려 넣는 방법인데요.

testLabel.then {
    $0.text =
     """
     1. 하단의 [파일 선택하기] 버튼을 눌러주세요.
     2. 팝업창에서 불러올 파일을 선택해주세요
        메뉴얼의 백업 파일은 '.zip' 형식이에요.
     3. [메뉴얼 가져오기] 버튼을 눌러 불러오기를 진행해주세요.
     4. 메뉴얼 가져오기가 완료됐어요 :)
     """
}

이러다 보니, UX Writing이 수정되거나 오탈자가 있을 경우에 수정하기가 매우 번거롭다는 단점이 있었습니다.

물론 아무 생각 없이 쓰윽 긁어서 복붙 해서 넣게 되니까 개발할 당시에는 매우 편리했지만,

시간이 지나면서 유지보수를 하게 되는 시점부터는 매우 귀찮게 만드는 놈으로 변신하는 것은 당연했습니다.

 

특히, 다국어를 지원하게 되는 시점부터는 지옥을 보게할 것이 분명했죠.

사실 다국어를 지원하게 되면 저렇게 넣는 방법은 애초에 사용이 불가능 하지만요.

그때부터 저렇게 작성 되어있는 모든 String을 교체하는 것은 참 귀찮고 하기 싫은 작업이예요.

 

그래서, 앱 개발 초기부터 UX Writing에 대한 String 관리 시스템을 잡고 싶었습니다.

이전에 디모다모를 개발할 때 매우 힘들었던 경험이 있었기도 했고,

회사를 다니기 시작하면서 어떻게 하면 String을 조금 더 쉽고 간편하게 관리할 수 있을 지에 대해

고민하게 되었던 것도 큰 영향이 있엇습니다.

 

---

 

2. Menual은 어떻게 관리해야 할까?

가장 처음에 고민한 것은 바로 이거였어요. 우리는 어떻게 관리 해야할까?

사실 아직 다국어를 지원할 생각은 딱히 없었기도 했고,

당장 한국어 지원만으로도 UX Writing에 대해서 많은 고민을 하고 있었던 상황이었죠.

 

그런데,, 런칭 전에 메뉴얼 프로토타입을 만들고 있을때부터 약간의 문제점이 발견되기 시작했습니다.

이 문제점을 해결하다 보면 조금 윤곽이 나오지 않을까 했어요.

마침 시스템을 구축하려고 했으니, 오히려 좋아! 했던 기억이 있습니다.

 

2-1. 개발자, 디자이너, 기획자 모두 다르다(?)

정말 웃픈 상황이 발생했어요.

프로토타입을 만들고 런칭 전 최종 점검을 진행하는 상황이었는데요.

기획자, 디자이너, 개발자 모두 각자 다른 UX Writing을 사용하고 있는 상황이 생겼습니다.

시간 순으로 정렬하면 이런 식이죠.

 

사건의 발단

1. 기획자가 스크린을 기획한다. 이 스크린 안에 다양한 UX Writing이 포함된다
2. 디자이너는 기획자가 기획한 스크린을 기반으로 디자인을 진행한다.
3. 개발자는 디자이너의 스크린을 보고 개발하고,
   디자이너의 GUI에 포함된 UX Writing을 반영한다.

문제가 보이시나요? 사실 이렇게 보면 문제가 없어보여요.

조금 더 세분화 해보죠.

 

디테일한 상황

1. 기획자가 스크린을 기획한다. 이 스크린 안에 다양한 UX Writing이 포함된다
   
   1. "메뉴얼을 작성해주세요." 라는 문구를 기획자가 작성했습니다.
   2. 이 기획자는 Description에는 마침표를 붙이기로 정했어요.
   3. 이 문구는 따로 문서로 정리된 것은 없고, 기획한 스크린에만 있습니다.
   4. (핵심) 기획자는 수시로 문구 디테일 작업을 진행합니다.
      
      
2. 디자이너는 기획자가 기획한 스크린을 기반으로 디자인을 진행한다.
   
   1. 디자이너는 처음엔 기획자가 기획한 스크린대로 디자인을 진행합니다.
   2. 그런데 GUI나 디자인시스템을 구성하다 보니, Description에 있는 마침표가 거슬립니다.
   3. (핵심) 마침표를 제거하거나, 약간의 Writing 톤을 수정하는 디테일 작업을 진행합니다.
      
      
3. 개발자는 디자이너의 스크린을 보고 개발하고,
   디자이너의 GUI에 포함된 UX Writing을 반영한다.
   1. 개발자는 디자이너가 당연히 기획자의 기본 UX Writing을 반영했을 거라 굳게 믿고 작업합니다.
   2. (핵심) 그러다가 가끔 GUI에는 반영되지 않는 디테일한 문구는 최초 기획자의 기획서를 보고 작업합니다.

 

결국 '기획자 -> 디자이너 -> 개발자' 를 거치게 되고 각 포지션의 디테일 작업이 병렬적으로 진행되면서,

최초에 기획했던 문구가 일부 수정되기도 하고, 개발자는 디자이너와 기획자의 작업물을 둘다 보고 작업하다보니,

디자이너의 문구, 기획자의 문구가 짬뽕되는 상황이 연출이 되었던 것이죠.

 

심지어, 서로 디테일 작업을 진행하는 상황에서는,

디자이너는 기획자의 디테일 작업이 완료된 문구를 적용했지만,
개발자는 기획자의 디테일 작업이 되지 않은 문구를 적용하게 되면서

서로서로 알 수 없는 문구들이 적용이 되어 있는 대참사가 생기게 되었죠 ㅋㅋㅋ...

 

2-2. 자.. 문제는 생겼고.. 어떻게 해결할까?

가장 큰 문제는 "기획-디자인-개발" 세 단계를 거치며 파편화 된다. 였어요.

그러면 파편화 되지 않으려면 어떻게 할까? 라는 고민을 하게 되었는데요.

 

그렇다고 "기획자의 문구를 앞으로 디자이너와 개발자는 절대 수정할 수 없다"고 하는 것은 피하고 싶었어요.

사이드 프로젝트로 서로 진행하는 룰을 한정하고, 절대 변경할 수 없다! 라고 도장을 찍고 경직되는 상황은

앞으로 사이드 프로젝트의 진행뿐만 아니라, 아디이에이션을 진행할 때도 긍정적인 효과를 기대하기 힘들었습니다.

 

결국 기획자/디자이너/개발자 모두 문구를 조금씩 수정하거나, 제안할 수 있지만

실제로 사용되는 UX Writing은 한 곳에 모아서 관리하자!로 결정되었습니다.

 

"그걸 어디서 관리하냐?" 라는 물음으로 돌아왔죠.

 

 

---

 

3. 구글 스프레드시트로 통일하자

메뉴얼에 사용되는 모든 문구는 아래 구글 스프레드시트에 입력하도록 룰을 정했습니다.

여기서 기획자, 디자이너, 개발자 모두가 자유롭게 수정을 할 수 있되,

변경 되었는지 여부를 파악하기 위한 버전명은 꼭 작성하도록 했어요.

 

앱에 실제로 적용되기 위해서는 개발을 염두할 수밖에 없었어요.

서로 작성하고 싶은대로 작성할 수는 없지만, 조금이라도 구성원들이 편리하게 작성할 수 있도록 스프레드시트를 꾸렸습니다.

 

3-1. 작성 방법

작성하는 방법은 쉽습니다.

1. 사용화면 작성
2. 세부 구분 작성 (Title, Description, Alert, Title, Button ...)
3. 한글 문구 작성 (영문 문구는 미래를 위해..)
4. 해당 문구의 고유 이름 작성

 

이렇게 되면, 사용화면과 세부 구분에 따라서 Prefix를 자동으로 생성해주기 때문에

많은 UX Writing에 대해 일관적인 룰으로 매우 편리하게 작성할 수 있습니다.

 

3-2. 개발버전과 싱크하는 어떻게?

스프레드시트로 적으면 실제 앱과는 어떻게 연동하는 것이 좋을까 많은 고민을 했는데요.

스프레드시트로 적은 사람은 "UX 버전"의 버전을 0.01씩 올려주고,
개발자는 실제로 앱에 적용할때 0.01을 올려서 서로 싱크가 맞도록 하고 있습니다.

 

위에 적은 String들은 아래와 같이 Swift에서 사용할 수 있도록, Localization 포맷에 맞게 자동 생성되도록 했는데요.

프로토 타입 제작 과정 중에 이런 저런 불편함을 몸소 겪으면서,

다양한 해결책 중 가장 합리적이고 효율적인 방법을 찾게 되면서

드디어 기획자, 디자이너, 개발자 등 팀원 모두가 UX Writing 관리 지옥에서 조금은.. 해방되는 순간이었습니다.

 

---

 

4. 앱에 적용하기

Build Phase에 빌드할 때마다 Localization 파일을 업데이트하도록 했습니다.

조금 더 최적화를 위해서는, UX Writing 버전과 실제 적용된 버전을 비교해서 업데이트가 되었을 때만 하도록 할 수 있을 것 같아요.

아직까지는 약 200개가 안되는 String 개수로, 빌드 성능에는 큰 영향을 끼치지 않는 수준이기 때문에,

추후에 다국어를 지원하게 되는 날이 오면 조금 더 업그레이드 할 수 있지 않을까 합니다.

 

 

4-1. 실제로 사용하기

    noticeLabel.do {
        $0.text = MenualString.backup_desc_notice
    }

앱에서 사용하는 것은 매우 간단합니다.

스프레드시트에서 작성한 것과 동일한 이름으로 MenualString Struct에 static 변수로 사용할 수 있습니다.

 

메뉴얼에는 모든 UX Writing은 위처럼 관리되고 있고, 수정할 때도 한 곳에서 수정할 수 있도록 하고 있습니다.

출시 후, 약 3-4달 동안 위와 같은 룰을 가지고 진행하고 있는데 매우 만족하며 사용하고 있습니다.

 

추가적으로 개선하고 싶은 것은,
Localization String이 앱이 빌드될 때 포함이 되다보니까 앱이 배포되고 나서 오탈자가 발견되었을 경우

수정하기 위해서는 새로 빌드를 내야한다는 것이 가장 큰 단점으로 생각하고 있습니다.

 

추후에, 다국어를 지원하게 될 때는,

기본적으로 앱에 포함되어 빌드되고 배포되는 것은 동일 하지만,

서버에서 버전 비교를 해서 추가 배포 없이 수정할 수 있도록 하는 것이 목표입니다.

 

아직까지는 메뉴얼에 서버는 포함되어 있지 않기 때문에,

위와 같은 기획은 조금 더 메뉴얼 앱이 고도화 되는 시점부터 진행할 수 있지 않을까 합니다.