1. Requirement의 생활화
모든 업무의 진행은 UI(Wireframe) + Requirement 가 필수.
그러고보면 한국은 모든 것들이 익숙해져 있어서인지 기획자와 개발자 사이에는 '스토리보드'라는 일종의 'Core Language'가 존재 했던 것이지만 (물론 한국에서도 당연히 스토리보드가 다는 아니지만), 이곳에서는 '스토리보드' 보다는 'Requirement'가 더욱더 필수적이다. 장단점이 있어 보인다. 어떻게 보면 역으로 좀 더 Creative한 (좋게 말해서) 결과물 산출이 가능할 수도 있을 것으로 보이나, 정확한 기획 의도의 전달은 사실상 많이 힘들다. UI와 Usability는 괜히 필요한 것이 아니기 때문에.. 거기에다가 모든 Requirement 작업은 완벽한 영문으로 작성되어야 하기 때문에, 기획 기간에 Translation과 Review의 과정들은 아직까진 나름 심난한 작업이다. 따라서 '기획'이라는 과정이 완료 되기까지는 많은 사람들의 일정이 고려되어야 한다. 답은 하나 있다. 내가 빨리 완벽한 영어를 구사하는것.. 그러나.. (장난해? ㅡㅜ)
2. Labeling은 멀고도 험난하다.
사실 한국에서는 웹사이트에서의 영문이 '부수'적으로 사용되는 경우가 많다. 디자인적인 요소를 더욱 풍요롭게 하기 위해서 영문 타이틀이 꼭 하나씩 들어가기 마련이다. 물론 기능 및 목적에 의한 영문 사용도 있겠지만 그 보다는 '꾸며주는'요소로서의 영문 사용이 대부분이 아닐까 싶다. 하지만.. 이곳은 절대 '콩글리쉬'가 허용되지 않는 곳.. 모든 메뉴의 Labeling과 Content는 정확하고도 어색하지 않은 영문이 사용되어야 하기 때문에 Korean American이 로컬라이징을 했다고 해도 Review의 과정은 필수적이다. 프로젝트의 마감 시한이 급박한 상황에서는 모든 일정을 소화하기 정신 없을 정도다. 게다가 시간이 없다 보니 Labeling의 수정은 Requirement 작성 때 많이 발견된다. 그러다 보니 이미 넘어간 디자인들을 다시 수정하는 커뮤니케이션만 해도 '일'들이다. 사소하게는 Notice가 아니라 Notices로 해야하고, Event가 아니라 Events라고 해야하는 것들이다. 물론 학습 효과를 통해 반복되는 부분들은 극복되겠지만 Native가 아닌 이상 아직 벽이 높다.
3. ...
이 모든 작업들에 대한 진행들을 일단 거의 다 혼자 해야 하니 무척이나 힘들게 느껴지는 것.
하지만 모든것들이 다 새로운 지식과 경험으로 쌓이고 있는 이 과정들은 솔직히 흥미롭다.
점점 조직도 모습을 갖춰가고 있기때문에 조만간 잘 세팅 되리라 기대하고 있고..
그리고.. 오늘은 여기까지.. 귀찮다. To Be Continued 로 하자..
el.
