9/6에 myID 영문 서비스를 오픈한 후, 언제나 그렇듯이 좀 더 잘 할 수 있었다는 생각을 많이 했습니다. 물론, 한 번 오픈하고 끝이 아니라 앞으로 계속 발전시켜 나갈 것이기에 그 이후에 더 잘 하면 되겠지만 미리 알았더라면 하는 아쉬움이 남는 것 같습니다.
다음 주에는 스프링노트가 팀 노트를 본격적으로 지원하면서, 많은 변화를 보여 드릴 것 같습니다. Xquared의 오픈과 함께, 그동안 많은 분들을 괴롭혀 드렸던 에디터 상의 버그들도 많은 부분이 해결될 것으로 기대하고 있습니다. 그리고 드디어 10월에는 스프링노트의 영문 서비스를 보여 드릴 수 있을 것으로 생각합니다.
비단 마이아이디와 스프링노트뿐만 아니라, 이후의 오픈마루 서비스들도 많은 서비스들이 영어를 비롯한 다양한 언어들도 제공이 될 것이기 때문에, 가장 처음으로 그 과정을 겪은 마이아이디 팀이 이번에 영어 서비스 오픈을 준비하면서 느꼈던 점들을 정리해서 공유하는 자리를 가졌습니다. 이 포스팅은 그 자리에서 공유된 내용을 정리한 것입니다.
사실 이 글에 정리된 내용들은, I18N, L10N 관련해서 이미 정리되어 있는 많은 내용들에 비하면 정말 빈약합니다만, 실제로 그 일을 진행하면서 느꼈던 것을 나름대로 정리한 것이라고 생각하시면 좋을 것 같습니다.
1. 먼저 제품 측면에서 신경 써야 할 것들을 살펴 보겠습니다.
1) 라벨링/메시징
- 모든 라벨과 메시지의 리소스를 분리해 놓는 것이 필수입니다. 따로 말을 하지 않아도 너무 당연한 얘기죠.
2) www, 약관, 도움말 등 국가별 페이지 분리. - 컨텐츠 차원의 지역화
- 실제로 영어 서비스를 준비하다 보면, 한글로 된 페이지와 무조건 1:1로 대응하기 힘든 부분이 있습니다. 언어적인 부분만 리소스로 관리하고 되도록이면 같은 코드를 사용하는 것이 좋지만 운영관련 페이지와 같이 운영에 따른 변경이 잦은 페이지들은 언어별로 따로 가도 좋은 것 같습니다.
3) 실제 서비스 화면에서 작업한다.
- 급하게 번역을 진행하다 보니 각 언어 별 리소스 파일을 직접 건네 주고 그것을 보면서 번역하는 경우가 있습니다. 그런 경우에 정말 많은 경우에 엉뚱한 번역이 나오는 것 같습니다. 직접 화면을 보면서 번역한 결과를 적을 수 있는 툴을 사용하는 것이 큰 도움이 되었습니다.
4) 관련 영문 서비스를 최대한 참고한다.
- 실제로 해당 영역의 서비스에서만 쓰는 용어/표현들이 있습니다. 영어를 잘 하는 것과는 별개로, 비슷한 서비스에서 어떤 말들을 사용하는 지를 미리 참고하여 정리해 놓는 것이 좋습니다.
5) 작업 순서
(1) 핵심이 되는 컨셉,기능,라벨 등 '핵심 단어' 들을 먼저 번역합니다.
A. 관련 영문 서비스를 최대한 참고합니다.
B. 이 작업은 영어를 잘 하는 사람보다는, 관련 영역에 대한 이해가 있는 기획자가 주도하는 것이 효과적입니다. Native는 차후 검수를 하는 것이 좋은 것 같습니다.
C. 핵심 단어들은 이후 메시징에서 일관되게 사용합니다.
(2) 화면상의 기본 메시지
(3) 예외 메시지
(4) 검수 리소스
A. 리소스파일 만으로는 부족합니다. 해당 컨텍스트를 같이 전달할 수 있어야 합니다.
B. 주요화면 스샷을 전달해야 합니다. 특히 AJAX 로 나타나는 대화등은, 정적인 파일로 전달되지 않기 때문에 적절한 스샷을 통해 기획 의도가 정확히 전달 되도록 합니다.
2. 두번째로, 디자인 측면에서 신경 써야 할 것들을 살펴 보겠습니다.
1) 가변성 확보
(1) 언어별로 라벨/메시지의 길이가 다르기 때문에 이것을 염두에 두어야 합니다. 따라서 고정된 폭으로 디자인하는 것을 지양해야 합니다.
(2) 텍스트를 단지 이쁘게 보이기 위하여 이미지로 버튼을 만드는 것을 지양해야 합니다. 서비스의 탑 화면과 같이 언어별로 전용 페이지가 있는 곳이나, 디자인 임펙트가 큰 곳은 예외일 수 있겠지만 그렇지 않은 곳에서는 최대한 지양해야 합니다.
(3) 표준 UI를 최대한 활용해야 합니다.
(4) 가변성이 확보 되야 하는 컨텐츠 일수록 CSS의 한계를 인정하고 CSS로 표현 할 수 있는 디자인을 선택해야 합니다.
2) 페이지 최적화
(1) 한국의 4 년전 속도 기준으로 작성해야 합니다. 아직도 많은 지역에서는 초고속 인터넷이 제공되고 있지 않는 것을 생각해야 합니다.
(2) 이미지 최소화. 페이지를 빠르게 보여 주기 위해서는 당연한 얘기라고 생각합니다.
(3) 디자인 요소를 줄이면서도 최대한 의도를 드러낼 수 있도록 해야 합니다. 디자인 요소가 줄어드는 만큼 (x)HTML과 CSS의 양도 줄어들기 때문입니다.
(4) CSS 로 그림 그리지 말 것. 오픈마루의 서비스는 HTML과 CSS의 분리는 어느 정도 잘 하고 있다고 생각합니다. 그렇지만 페이지 스타일의 일관성이 없으면 사실 CSS를 분리해 놨더라도 그것을 다시 사용하는 장점을 누릴 수가 없기 때문에 CSS량이 엄청 많아지게 됩니다.
A. CSS로 그림을 그리는 현상을 없애려면 화면 개발 순서를 제고해야 할 수 있습니다.
IA -> (x)HTML -> Design -> CSS 와 같이 말이죠.
B. 이 과정을 잘 하기 위해서는 (x)HTML 및 CSS에 대한 디자이너의 이해가 필요합니다.
3. 세 번째로 언어나 시간대, 그리고 국가의 설정에 대해서 정리해 봤습니다. 서비스를 사용자 context에 최적화하기 위해서는 언어/국가/시간대를 명확히 구분해야 합니다. (참고자료: OpenID Simple Registration Extension 1.0)
1) 언어 (openid.sreg.language) -> UI 측면
(1) 사용자 인터페이스 리소스(라벨, 메시지, 도움말)를 선택하기 위해서 사용자의 언어 설정이 필요합니다.
(2) 기본적으로 사용자가 만드는 컨텐츠는 다국어(UTF-8) 이므로, 이 언어로 사용자가 만드는 컨텐츠 언어를 제약하면 안 됩니다. 예)영문 UI 에서도 한글 텍스트를 작성할 수 있어야 한다.
(3) 이 설정은 OpenID Consumer 인 경우, IDP 로 부터 받을 수 있습니다.
(4) 사용자 언어 결정 순서 ( 로케일결정로직 )
A. 쿠키 > 계정속성 > 브라우저 (accept-lang)
B. 로그인시 계정속성 -> 쿠키 갱신
2) 시간대 (openid.sreg.timezone) -> UI 측면
(1) 이 개념은 사용자 PC 의 표준시간대라고 생각할 수 있습니다.
(2) 사용자에게 보이는 시간과는 달리 데이타베이스의 시간은 하나로 고정해야 합니다. (GMT 기준이건, 한국 표준시 기준이건)
(3) timezone 은 시간 출력시에만 활용합니다.
(4) 결정 방법
A. OpenID IDP 제공 > javascript 로 PC timezone 추출
3) 국가 (openid.sreg.country) -> 기능/컨텐츠 측면
(1) 현재 사용자 거주 국가로, 국적과는 다를 수 있습니다.
(2) 컨텐츠 관점에서의 Localization 의 결정 기준은 lang 보다는 이 값이 우선합니다. 예를 들면, 메일 주소를 추천할 때 해당 국가에서 많이 쓰는 이메일 서비스 목록을 제공해야 하는 것이 맞겠죠.
(3) 결정 방법
A. OpenID IEP 제공
B. 이 값을 받지 못하는 경우에는 언어에 따라서 한국어=>한국, 영어=>미국으로 처리.
이번에 이 일을 처리하면서 그 전에 몰랐던 것을 알게 된 것은 OpenID가 줄 수 있는 장점이 또 있다는 것입니다. 언어/시간대/국가와 같은 정보를 IDP 가 알고 있고 그 정보를 전달해 주기 때문에, consumer들은 사용자들을 또 괴롭히지 않고 사용자 자신의 context에 딱 맞는 정보를 제공해 주기가 쉽다는 것입니다.
오픈마루가 처음 OpenID를 택할 때, 글로벌한 환경에서 OpenID에 동조하는 적극적인 사용자들이 관심을 가져 줄 거라는 생각도 있었지만, 실제로 작업을 진행하면서 서비스의 글로벌화를 생각한다면 더욱 더 좋은 선택이라는 생각이 많이 들었습니다.
마지막으로 이번 영문 서비스 오픈 과정을 회고하면서 느꼈던 것 몇 가지를 더 말씀 드리면, 소스에 대한 유지보수 보완책이 필요하다는 것입니다.
언어를 담고 있던 것이 리소스 파일로 빠져 버리게 되면 코드에 대한 가독성이 떨어집니다. 따라서 소스 코드가 실제 서비스에서 표현되는 언어를 담고 있을 때보다 훨씬 더 코드를 잘 작성해야지만 추후 유지 보수가 가능할 것 같습니다.
그리고 컨텐츠, 리소스들과 기능 코드들은 분리하여 관리할 필요가 있는 것 같습니다. 여러 개의 언어로 서비스가 제공되는데, 각 서비스 별로 조금의 수정 사항마다 전체 코드를 다시 build해야 한다면 대응이 늦어질 수박에 없습니다. 소스코드는 CVS, SVN 등을 이용해서 관리하겠지만, 컨텐츠는 따로 관리하는 방안이 필요합니다.
아직은 적용되지 않았지만 현재 고려하고 있는 컨텐츠 관리 방안으로는 스프링노트에 관련 컨텐츠를 적고, openAPI를 이용하여 스프링노트에 적힌 내용을 각 페이지의 컨텐츠로 활용하는 부분에 대해서 생각하고 있습니다.
앞에서도 말씀 드렸지만, 이미 이런 이슈와 관련해서는 훨씬 전문적으로 정리한 책들도 많이 나와 있습니다. 그리고 이미 글로벌하게 서비스를 제공하는 많은 외국 회사와 또 국내의 다른 회사에 계신 분들 입장에서 보실 때는 너무 당연하고 초보적인 얘기라고 생각하실 것 같습니다.
그렇지만, 언제나 경험이 중요한 것은, 내가 몰랐던 것을 새로 알기 때문이 아니라, 내가 정말 알아야만 하는 것이 무엇이고, 그것이 얼마나 중요한 것인지를 느끼게 해 주기 때문이라고 생각합니다.
마이아이디의 영문 서비스, 오픈마루의 글로벌서비스의 첫 발자국입니다. 정말 모자란 부분이 많지만 앞으로 더욱 열심히 하도록 하겠습니다. 감사합니다.
다음 주에는 스프링노트가 팀 노트를 본격적으로 지원하면서, 많은 변화를 보여 드릴 것 같습니다. Xquared의 오픈과 함께, 그동안 많은 분들을 괴롭혀 드렸던 에디터 상의 버그들도 많은 부분이 해결될 것으로 기대하고 있습니다. 그리고 드디어 10월에는 스프링노트의 영문 서비스를 보여 드릴 수 있을 것으로 생각합니다.
비단 마이아이디와 스프링노트뿐만 아니라, 이후의 오픈마루 서비스들도 많은 서비스들이 영어를 비롯한 다양한 언어들도 제공이 될 것이기 때문에, 가장 처음으로 그 과정을 겪은 마이아이디 팀이 이번에 영어 서비스 오픈을 준비하면서 느꼈던 점들을 정리해서 공유하는 자리를 가졌습니다. 이 포스팅은 그 자리에서 공유된 내용을 정리한 것입니다.
사실 이 글에 정리된 내용들은, I18N, L10N 관련해서 이미 정리되어 있는 많은 내용들에 비하면 정말 빈약합니다만, 실제로 그 일을 진행하면서 느꼈던 것을 나름대로 정리한 것이라고 생각하시면 좋을 것 같습니다.
1. 먼저 제품 측면에서 신경 써야 할 것들을 살펴 보겠습니다.
1) 라벨링/메시징
- 모든 라벨과 메시지의 리소스를 분리해 놓는 것이 필수입니다. 따로 말을 하지 않아도 너무 당연한 얘기죠.
2) www, 약관, 도움말 등 국가별 페이지 분리. - 컨텐츠 차원의 지역화
- 실제로 영어 서비스를 준비하다 보면, 한글로 된 페이지와 무조건 1:1로 대응하기 힘든 부분이 있습니다. 언어적인 부분만 리소스로 관리하고 되도록이면 같은 코드를 사용하는 것이 좋지만 운영관련 페이지와 같이 운영에 따른 변경이 잦은 페이지들은 언어별로 따로 가도 좋은 것 같습니다.
3) 실제 서비스 화면에서 작업한다.
- 급하게 번역을 진행하다 보니 각 언어 별 리소스 파일을 직접 건네 주고 그것을 보면서 번역하는 경우가 있습니다. 그런 경우에 정말 많은 경우에 엉뚱한 번역이 나오는 것 같습니다. 직접 화면을 보면서 번역한 결과를 적을 수 있는 툴을 사용하는 것이 큰 도움이 되었습니다.
4) 관련 영문 서비스를 최대한 참고한다.
- 실제로 해당 영역의 서비스에서만 쓰는 용어/표현들이 있습니다. 영어를 잘 하는 것과는 별개로, 비슷한 서비스에서 어떤 말들을 사용하는 지를 미리 참고하여 정리해 놓는 것이 좋습니다.
5) 작업 순서
(1) 핵심이 되는 컨셉,기능,라벨 등 '핵심 단어' 들을 먼저 번역합니다.
A. 관련 영문 서비스를 최대한 참고합니다.
B. 이 작업은 영어를 잘 하는 사람보다는, 관련 영역에 대한 이해가 있는 기획자가 주도하는 것이 효과적입니다. Native는 차후 검수를 하는 것이 좋은 것 같습니다.
C. 핵심 단어들은 이후 메시징에서 일관되게 사용합니다.
(2) 화면상의 기본 메시지
(3) 예외 메시지
(4) 검수 리소스
A. 리소스파일 만으로는 부족합니다. 해당 컨텍스트를 같이 전달할 수 있어야 합니다.
B. 주요화면 스샷을 전달해야 합니다. 특히 AJAX 로 나타나는 대화등은, 정적인 파일로 전달되지 않기 때문에 적절한 스샷을 통해 기획 의도가 정확히 전달 되도록 합니다.
2. 두번째로, 디자인 측면에서 신경 써야 할 것들을 살펴 보겠습니다.
1) 가변성 확보
(1) 언어별로 라벨/메시지의 길이가 다르기 때문에 이것을 염두에 두어야 합니다. 따라서 고정된 폭으로 디자인하는 것을 지양해야 합니다.
(2) 텍스트를 단지 이쁘게 보이기 위하여 이미지로 버튼을 만드는 것을 지양해야 합니다. 서비스의 탑 화면과 같이 언어별로 전용 페이지가 있는 곳이나, 디자인 임펙트가 큰 곳은 예외일 수 있겠지만 그렇지 않은 곳에서는 최대한 지양해야 합니다.
(3) 표준 UI를 최대한 활용해야 합니다.
(4) 가변성이 확보 되야 하는 컨텐츠 일수록 CSS의 한계를 인정하고 CSS로 표현 할 수 있는 디자인을 선택해야 합니다.
2) 페이지 최적화
(1) 한국의 4 년전 속도 기준으로 작성해야 합니다. 아직도 많은 지역에서는 초고속 인터넷이 제공되고 있지 않는 것을 생각해야 합니다.
(2) 이미지 최소화. 페이지를 빠르게 보여 주기 위해서는 당연한 얘기라고 생각합니다.
(3) 디자인 요소를 줄이면서도 최대한 의도를 드러낼 수 있도록 해야 합니다. 디자인 요소가 줄어드는 만큼 (x)HTML과 CSS의 양도 줄어들기 때문입니다.
(4) CSS 로 그림 그리지 말 것. 오픈마루의 서비스는 HTML과 CSS의 분리는 어느 정도 잘 하고 있다고 생각합니다. 그렇지만 페이지 스타일의 일관성이 없으면 사실 CSS를 분리해 놨더라도 그것을 다시 사용하는 장점을 누릴 수가 없기 때문에 CSS량이 엄청 많아지게 됩니다.
A. CSS로 그림을 그리는 현상을 없애려면 화면 개발 순서를 제고해야 할 수 있습니다.
IA -> (x)HTML -> Design -> CSS 와 같이 말이죠.
B. 이 과정을 잘 하기 위해서는 (x)HTML 및 CSS에 대한 디자이너의 이해가 필요합니다.
3. 세 번째로 언어나 시간대, 그리고 국가의 설정에 대해서 정리해 봤습니다. 서비스를 사용자 context에 최적화하기 위해서는 언어/국가/시간대를 명확히 구분해야 합니다. (참고자료: OpenID Simple Registration Extension 1.0)
1) 언어 (openid.sreg.language) -> UI 측면
(1) 사용자 인터페이스 리소스(라벨, 메시지, 도움말)를 선택하기 위해서 사용자의 언어 설정이 필요합니다.
(2) 기본적으로 사용자가 만드는 컨텐츠는 다국어(UTF-8) 이므로, 이 언어로 사용자가 만드는 컨텐츠 언어를 제약하면 안 됩니다. 예)영문 UI 에서도 한글 텍스트를 작성할 수 있어야 한다.
(3) 이 설정은 OpenID Consumer 인 경우, IDP 로 부터 받을 수 있습니다.
(4) 사용자 언어 결정 순서 ( 로케일결정로직 )
A. 쿠키 > 계정속성 > 브라우저 (accept-lang)
B. 로그인시 계정속성 -> 쿠키 갱신
2) 시간대 (openid.sreg.timezone) -> UI 측면
(1) 이 개념은 사용자 PC 의 표준시간대라고 생각할 수 있습니다.
(2) 사용자에게 보이는 시간과는 달리 데이타베이스의 시간은 하나로 고정해야 합니다. (GMT 기준이건, 한국 표준시 기준이건)
(3) timezone 은 시간 출력시에만 활용합니다.
(4) 결정 방법
A. OpenID IDP 제공 > javascript 로 PC timezone 추출
3) 국가 (openid.sreg.country) -> 기능/컨텐츠 측면
(1) 현재 사용자 거주 국가로, 국적과는 다를 수 있습니다.
(2) 컨텐츠 관점에서의 Localization 의 결정 기준은 lang 보다는 이 값이 우선합니다. 예를 들면, 메일 주소를 추천할 때 해당 국가에서 많이 쓰는 이메일 서비스 목록을 제공해야 하는 것이 맞겠죠.
(3) 결정 방법
A. OpenID IEP 제공
B. 이 값을 받지 못하는 경우에는 언어에 따라서 한국어=>한국, 영어=>미국으로 처리.
이번에 이 일을 처리하면서 그 전에 몰랐던 것을 알게 된 것은 OpenID가 줄 수 있는 장점이 또 있다는 것입니다. 언어/시간대/국가와 같은 정보를 IDP 가 알고 있고 그 정보를 전달해 주기 때문에, consumer들은 사용자들을 또 괴롭히지 않고 사용자 자신의 context에 딱 맞는 정보를 제공해 주기가 쉽다는 것입니다.
오픈마루가 처음 OpenID를 택할 때, 글로벌한 환경에서 OpenID에 동조하는 적극적인 사용자들이 관심을 가져 줄 거라는 생각도 있었지만, 실제로 작업을 진행하면서 서비스의 글로벌화를 생각한다면 더욱 더 좋은 선택이라는 생각이 많이 들었습니다.
마지막으로 이번 영문 서비스 오픈 과정을 회고하면서 느꼈던 것 몇 가지를 더 말씀 드리면, 소스에 대한 유지보수 보완책이 필요하다는 것입니다.
언어를 담고 있던 것이 리소스 파일로 빠져 버리게 되면 코드에 대한 가독성이 떨어집니다. 따라서 소스 코드가 실제 서비스에서 표현되는 언어를 담고 있을 때보다 훨씬 더 코드를 잘 작성해야지만 추후 유지 보수가 가능할 것 같습니다.
그리고 컨텐츠, 리소스들과 기능 코드들은 분리하여 관리할 필요가 있는 것 같습니다. 여러 개의 언어로 서비스가 제공되는데, 각 서비스 별로 조금의 수정 사항마다 전체 코드를 다시 build해야 한다면 대응이 늦어질 수박에 없습니다. 소스코드는 CVS, SVN 등을 이용해서 관리하겠지만, 컨텐츠는 따로 관리하는 방안이 필요합니다.
아직은 적용되지 않았지만 현재 고려하고 있는 컨텐츠 관리 방안으로는 스프링노트에 관련 컨텐츠를 적고, openAPI를 이용하여 스프링노트에 적힌 내용을 각 페이지의 컨텐츠로 활용하는 부분에 대해서 생각하고 있습니다.
앞에서도 말씀 드렸지만, 이미 이런 이슈와 관련해서는 훨씬 전문적으로 정리한 책들도 많이 나와 있습니다. 그리고 이미 글로벌하게 서비스를 제공하는 많은 외국 회사와 또 국내의 다른 회사에 계신 분들 입장에서 보실 때는 너무 당연하고 초보적인 얘기라고 생각하실 것 같습니다.
그렇지만, 언제나 경험이 중요한 것은, 내가 몰랐던 것을 새로 알기 때문이 아니라, 내가 정말 알아야만 하는 것이 무엇이고, 그것이 얼마나 중요한 것인지를 느끼게 해 주기 때문이라고 생각합니다.
마이아이디의 영문 서비스, 오픈마루의 글로벌서비스의 첫 발자국입니다. 정말 모자란 부분이 많지만 앞으로 더욱 열심히 하도록 하겠습니다. 감사합니다.
- 마이아이디팀 드림.
TAG 글로벌
Trackback
트랙백 주소 :: http://www.openmaru.com/trackback/167
Comment