기술 및 문화, 번역 및 정리

StudioEgo의 마음내키는대로 번역요약 및 정리하는 저장소. 티스토리 블로그( http://blog.studioego.info/ )와 병행하여 운영합니다

[transego]

Worldwide, Korea, Japan, Taiwan's developer meetup sites List

Yesterday, I met Japanese developer from Nagoya(名古屋), Japan(日本) at HiveArena Coworking space(하이브아레나 코워킹스페이스) in Seoul(서울), Korea(한국).

When I met Japanese developer, I recommended Korean trip sites to him. then I spoke to him in Japanese about development environment of Korea and Japan.

He is traveling Taiwan, Korea, Malaysia, etc.

Yesterday, He was final day in Korea, then next day he'll go to malaysia.

He is very interesting guy for me. He said to me Worldwird, Japan & Taiwan’s developer meetup site. so I aggregated Korea, Japan, Taiwan’s meetup site.

World Wide

Meetup https://www.meetup.com/

Eventbrite https://www.eventbrite.com/

Korea

onoffmix https://onoffmix.com/

Japan

Connpass https://connpass.com/

Doorkeeper https://www.doorkeeperhq.com/

ATND https://atnd.org/

TECH PLAY https://techplay.jp/

Taiwan

kktix https://kktix.com/

Accupass https://www.accupass.com/

I have no information in China meetup site. haha

If I'll meet Chinese developer, I'll add China's meetup sites in that List.

2017.07.17. Nogata Jun informed me about Japanese developer meetup sites(ATND, TECH PLAY). so I add that list. Thank You!

[transego]

Rostow's forth revolution will do two things in particular. First, it will enable us to refurbish manufacturing industry. Older industries like steel, automobiles and engineering will, by using robots, increase output per man and reduce cots to tay competitive even with industry in countries like Japan and South Korea. Secondly, a new range of high-technology industries will develop, many concerned with the information revolution I think especially of consumer electronics, electrical activities like the production of cables, switching equipment and microwave communication equipment, as well as aerospace, especially communication satellites. We can also look forward to dramatic developments in biotechnology. The Forth Industrial Revolution may also see the development of alternative sources of energy. 로스토우의 제4차 산업혁명은 특별히 두 가지의 일을 수행할 것이다. 첫째, 우리는 이 산업혁명으로 제조산업을 일신할 수 있게 될 것이다. 강철, 자동차, 공학과 같은 좀 오래된 산업은 로보트를 사용하여 1인당 생산량을 늘리고 생산원가를 낮춰서 일본이나 한국과 같은 국가들과 경쟁을 할 수 있게 될 것이다. 둘째, 새로운 부류의 첨단 기술 산업이 발달할 것이며 그들 중 정보 혁명과 관련된 것이 많을 것이다. 특히 통신위성 등 항공 우주 관련 제품은 물론이려니와 가전제품과 케이블, 교환장비 그리고 마이크로파 통신장비의 생산 등 전기,전자분야 산업이 발전할 것으로 전망한다. 또 생물공학 분야의 산업은 극적인 발전을 바라볼 수 있다. 이밖에도 제4차산업혁명은 대체(代替)에너지원의 발전으로 가져올 것으로 보인다.

New Scientist 26 April. 1984, "The Forth Industrial Revolution" byProfessor Sir Douglas Hague.

1984년 4월 26일자 “뉴 사이언티스트”, 영국의 저명한 Sir. Douglas Hague 교수의 “제4차산업혁명” 컬럼.

30년전의 기사와 현재의 한국에서 유행하는 제4차산업혁명 기사의 내용이 일맥상통한걸보고 깜짝 놀랐었다. 

 Sir. Douglas Hague의 컬럼에 나오는  “일본(Japan), 한국(South Korea)”을 중국(China,中国)로 고치면 한국의 기자, 교수등 저명한 사람이 기사를 쓴것과 비슷한 글을 본 기시감을 느낀다.

한국에서 제4차산업혁명이야기 하는 사람들 보면 대부분 고민을 많이 하지 않고, 어디서 주어들은 내용을 가지고 말장난하는 느낌이 많이 들

출처: https://books.google.co.kr/books?id=0CD4q0J1CrcC&pg=PA24&lpg=PA24&dq=The+fourth+industrial+revolution+douglas+hague&source=bl&ots=AHPV8MSHWi&sig=o4zTFGlLJ3QpvO70MGj5j_gx0Bw&hl=ko&sa=X&ved=0ahUKEwjj3Z2Ny-_UAhUMOrwKHSrBDFIQ6AEIKjAB#v=onepage&q=The%20fourth%20industrial%20revolution%20douglas%20hague&f=false

[transego]

Think Perl 6 PDF파일 및 LaTex파일 공개

출처: https://twitter.com/nogoodnickleft/status/868197580337020928

"Think Perl 6" now available from @OReillyMedia: https://t.co/ShVAwmJAeM and as a free PDF at https://t.co/bCohzhqabm (it's #OpenSource!)

— Moritz Lenz (@nogoodnickleft) 2017년 5월 26일

안녕하세요, 저는 동아시아 문자 처리에 관심이 많아 2012년도경에 한자정보를 담은 Unihan Database를 찾아보았습니다.

이때 일본인 Dan Kogai(小飼弾, Japanese open-source developer, former CTO of Livedoor) 씨의 Unihan Perl라이브러리( https://metacpan.org/pod/Unicode::Unihan ) Perl자료를 보았습니다.

이후, 오드리 탕(唐鳳, Audrey Tang)씨가 개발한 萌典(Moedict)의 한자정보에 대하여 관심이 많아 연구하다 Perl에 입문하게 된 사람입니다.

이번에 O'Reilly에서 새로운 Perl6책 "Think Perl 6 - How to Think Like a Computer Scientist"가 나왔습니다.

이 책이 종이책으로 판매가 되었는데, 저자인 Laurent Rosenfeld씨께서 오픈소스로 온라인으로 전자책 형식인 LaTex파일, PDF파일로도 공개를 하였습니다.

책 소개를 보면, Think Perl 6는 아무런 경험이 없는 사람에게 컴퓨터과학의 소개 및 프로그래밍에 대한 소개를 하는 책이라고 하군요.

이 책은 주로 Perl6를 가르치는 것이 아니라 "Perl 6"를 이용하여 프로그래밍 기술을 알려주는 것이라고 하군요. 이 책을 다 읽으면 Perl6라는 언어로 컴퓨터 과학, 소프트웨어 프로그래밍 및 문제 해결을 가르치는 것이라고 하군요.

Think Perl 6 is an introduction to computer science and programming intended for people with little or no experience. This aim of this book is not primarily to teach Perl 6, but instead to teach the art of programming, using the Perl 6 language. After having  completed this book, you should hopefully be able  to write programs to solve relatively difficult problems in Perl 6, but my main aim is to teach computer science, software programming, and problem solving rather than solely to teach the Perl 6 language itself.

Perl6에 대해 관심 많으신 분이나 프로그래밍 초심자가 "Think Perl6"로 Perl6를 입문하면 괜찮을 듯 합니다.

O'reilly Book Link: http://shop.oreilly.com/product/0636920065883.do

Book : http://greenteapress.com/wp/think-perl-6/

Free PDF Link: http://greenteapress.com/thinkperl6/thinkperl6.pdf

Latex Source[Github]: https://github.com/LaurentRosenfeld/thinkperl6/

[transego]

Add Hangul jamo representation by selected Hangul Syllable on GNOME gucharmap

I'm writing proposal english document about add Hangul jamo(초성[初聲,choseong, initial consonant], 중성[中聲,jungseong,vowel], 종성[終聲,jongseong,final consonant]) representation by selected Hangul Syllable on GNOME gucharmap. (gucharmap is Character Map for GNOME Desktop on Linux) (Hangul jamo as known as consonants and vowels)

After my some gucharmap code reviewing, I'll commit next weekend.

English writing for proposal about open source is very difficult for me.

Because I am not very familiar with the English words for the Korean alphabet(Hangul).

( My mother tongue is Korean Gyeongsang Dialect not Standard Korean. so Standard Korean is very difficult for me too. 😂

However, Standard Korean is easier for me than English, Chinese and Japanese )

Gyeongsang Dialect(Korean)

If I have some times, I'll expand add Hangul jamo(초성[初聲,choseong], 중성[中聲,jungseong], 종성[終聲,jongseong]) representation by selected Hangul Syllable on KDE kcharselect.

(KDE kcharselect is Character Map for KDE Desktop on Linux)

Reference

Unicode Hangul jamo character table(유니코드 한글 자모 목록)

Unicode Hangul Syllables table (유니코드 한글 음절 목록)

gucharmap - the GNOME Character Map, based on the Unicode Character Database

kCharSelect - a tool to select special characters from all installed fonts and copy them into the clipboard on KDE

[arachneng]

유니코드 한중일 잔혹사

작년에 Awesome Unicode라는 유니코드에 대한 이런 저런 사실들을 모아 놓은 저장소를 본 적이 있는데, 한글 채움 문자 얘기가 있는데 왜 공백인지 잘 모르겠다고 쓰여 있어서 옛날에 레딧에 올렸던 내용과 함께 내친 김에 한중일(CJK) 관련된 것들을 생각나는 대로 왕창 써서 올린 적이 있다. 그러고 나서 잊어 버리고 있었는데, 몇 달 뒤에 아는 분께서 저 글에 미묘한 오류가 있다면서 알려 주시길래 깜짝 놀란 적이 있다(“아니 저 이슈를 어디서 보셨길래?”).

사실 유니코드는 당연히 서양에서 개발이 시작되었고, 서양의 많은 문자들은 결국 페니키아 문자에서 출발하여 분화된 것이므로 알파벳에서 멀어지는 문자일 수록 유니코드에 매끈하게 통합되기 어려웠던 건 사실이다. 설계 과정에서 한중일 문자가 고려가 되지 않은 건 아니지만 (오히려 한자의 존재 자체가 유니코드 제정의 동력이 되었다는 얘기도 있다) 워낙 이질적인 구조다 보니 삐끗난 부분이 여럿 있는데, 그 때문에 지금까지 남아 있는 이상한 것들이 여럿 있다. 그리하여, 예전에 써 놓았던 글을 피드백을 반영해서 재작성에 가까운 번역을 해 보기로 한다. 내용 자체는 한중일 문자에 대해 잘 모르는 외국인을 위해 쓴 것이므로 이미 잘 알고 있는 내용이 있어도 그러려니 하시길… 대괄호 안에 있는 내용은 원문의 맥락이 부족해서 추가했거나 나중에 가필/수정한 부분.

한글 채움 문자

한글 채움 문자(U+3164 HANGUL FILLER)는 문자 집합이 선택할 수 있는 가장 멍청한 선택이라 할 수 있다. 한글은 간단한 알고리즘으로 조립되는 문자이기에 한글 문자 집합도 이상적으로는 그렇게 구성되어야 하겠으나, 기존에 널리 쓰이던 멀티바이트 인코딩들(ISO 2022, EUC)은 모두 94 × 94 = 8836자라는 상대적으로 작은 문자 집합1만을 사용할 수 있었고, 이는 현대 한글 음절 19 × 21 × 28 = 11172에 비해 훨씬 부족했다.

따라서 KS X 1001 문자 집합은 2350자의 자주 쓰이는 한글 음절(이랑 다른 이유로 유니코드에서 말썽이 된, 중복을 포함하는 한자 4888자)만을 포함하게 되었다. 다른 한글 음절이 지원되지 않는다는 점은 차치하고라도, 이 설계 때문에 한글을 지원하는 모든 소프트웨어의 복잡도가 늘어나 버렸고 유니코드 이전에 존재하던 또 다른 “조합형” 인코딩과의 충돌 및 논란이 있어 왔다. 표준화 기구는 나중에 설계가 부족했음을 인정했으나, 그 대안이라는 것이 문자 4개의 조합, 즉 8바이트의 열로 남아 있는 음절들을 임시로 표현할 수 있게 한다는 것이었다! 한글 채움 문자는 이런 조합을 표시하는 문자로, 이를테면 ㄱㅏ은 가를 나타내고 ㅂㅞㄺ은 KS X 1001에 포함되지 않은 뷁을 나타내는 식이다.

한글 채움 문자는 너무 늦게 추가되었기 때문에 소프트웨어 업계에서 사실상 외면받았다. 하지만 한글 채움 문자가 KS X 1001에 포함되어 있는 이상 유니코드에도 추가되어야 했고, 유니코드에는 한글 조합에 대한 표준이 존재하지 않지만 어쨌든 문자의 일부로 쓰일 수 있으니까 문자처럼 취급되어야 했다. [그래서 분명히 보이지 않는 문자임에도 불구하고 문자나 더 나아가 식별자의 일부로 쓰일 수 있게 된 것이다.] 이러어언.

한중일 통합 한자

시작하기에 앞서, 사실 “한중일” 통합 한자(Unified CJK Ideograph2)에는 베트남이 과거에 사용했던 쯔놈도 들어 있다는 걸 알아 두자. 물론 이제 이 이름은 고칠 수 없다.

한자 통합(Han unification)은 역사적으로 동일하게 취급되던 살짝 살짝 다른 이체자들을 하나의 한자로 합쳐서 인코딩하는 거대한 작업이었다. 문제는 역사적으로 동일하다고 실제 사용이 동일한 건 아니었다는 점인데, 이를테면 특정한 고유명사는 항상 똑같은 한자로만 쓰이는 경우가 있다. 확인해 보진 않았지만, 내 생각에 이건 기본다국어평면(BMP)의 제한된 크기와 관련되어 있지 않나 싶은데, 이런 한자들은 유니코드가 16비트로 제한되던 시절 초기에 추가되었기 때문이다. 물론 다양한 예외도 존재하는데 보통 한자가 유래한 문자 집합에서 통합이 되어 있지 않은 경우가 대부분이며, 원래 통합되었던 문자들이 나중에 쪼개지는 경우도 있다. 이체자 선택자(variation selector)와 한자 이체자 데이터베이스(IVD)가 이 오래된 문제를 마침내 제대로 해결할 거라고 다들 믿는데, 이들을 지원하는 글꼴과 소프트웨어 모두 아직 충분히 널리 쓰이고 있진 않다.

완전히 같은 모양의 한자가 여럿 인코딩된 경우도 있는데, 여러 종류로 나눌 수 있다. 일단 Big5에서 실수로 합치지 않은 U+FA0C랑 U+FA0D 같이 쌩 버그인 경우가 있고, 앞에서 언급되었던 KS X 1001의 경우 독음만 다른 같은 문자가 수백자나 인코딩되어 있는데 실제로는 신뢰할 수 없는 정보가 되어 버린 사례같이 그냥 멍청한 경우도 있으며, 물론 강희자전의 한자 부수도 중복이다.

아예 그 원전을 알 수 없는 한자가 등록된 경우도 있다. 가장 유명한 것으로는 JIS X 0208에서 유래한 문자들이 있는데, 그 중에서도 彁는 원전도 원전이 어떤 오류로 그렇게 인코딩된 건지도 알 수 없다는 점에서 두 배로 알 수 없는 경우이다.

[실은 한자 말고 한글에도 버그가 좀 들어 있다고 알려져 있다. 정확히는 옛한글 낱자의 문제인데, 옛한글 겹낱자 중에 옛이응이 들어가야 할 것이 이응이 들어 있다거나(초기 한글에서 그냥 이응은 음가가 없기 때문에 겹낱자의 일부로 들어와서는 안 된다), ㆅ(U+3185)의 오자로 보이는 ꥼ(U+A97C)가 문헌 출처도 없이 버젓이 들어 있는 것 같다거나… 현대 한글과는 달리 옛한글은 절대적으로 문헌 발굴에 의지하기 때문에 생길 수 있는 문제들이다.]

호환 기호

[한중일 문자 집합이 가져다 준 것은 다양한 보통 문자 말고도] 호환 기호들이 많이 있는데, 이들은 한중일에서 많이 쓰이는 네모낳게 여러 문자를 뭉친 기호들(이를테면 U+3392는 “MHz”를 한 문자로 표시한다)에서 유래한 것으로 트윗을 최적화하는데 매우 매우 유용하다. 물론 실수도 있는데, 이를테면 Ken Lunde3가 설명하길 오타 때문에 네모낳게 뭉친 기호가 실제로 사용되는 어떤 단위나 약자에도 대응되지 않게 된 경우가 있다고 한다.

아 물론 에모지도 일본에서 온 것이다. 이게 다 일본의 통신 삼사 때문이니 그 쪽을 탓하라.

[에모지에 대해서는 옛날에 긴 글을 쓴 적이 있으니 이 쪽을 참고. 6.0 이후에도 에모지는 크고 작은 사건을 일으켜 왔는데 최근의 사례를 하나만 들면 애플이 비난에 못 이겨 총을 나타내는 에모지를 장난감 물총(…)으로 바꾼 사례 따위가 있다. 그러니까 이런 거 넣지 말라고.]

정규화 문제

심지어 유니코드 정규화가 제대로 동작하지 않는 사례도 있다. 유니코드에서 한글 음절은 두 개의 정규화된 형식이 있는데, 하나는 완전히 합쳐진 형태(예: U+AC00 가)이고 하나는 완전히 풀린 형태(예: U+1100 ㄱ + U+1161 ㅏ)이다. 정규화 후 이들은 똑같이 취급되어야 하는데, 이 정규화 알고리즘에는 완전히 합쳐지는 게 불가능한 옛한글과 관련해서 중요한 오류가 있다. (예: U+1103 U+1172 U+11F0 듀ᇰ은 종성 때문에 옛한글로 분류되는데, 정규화 뒤 첫 두 낱자가 U+B4C0 듀로 합쳐지면서 두 개의 글자로 쪼개진다.) 유니코드 알고리즘을 더 이상 고칠 수는 없으므로, 결국 한국에서 쓸 목적으로 한글을 제대로 처리하는 정규화 알고리즘(KS X 1026-1)이 따로 나와 버리고 말았다.

유니코드 2.0 이전의 한글

이 사건은 워낙에 유명해서 “Korean mess"라는 용어가 따로 있을 정도이다. 한글은 유니코드 역사를 통틀어 통째로 움직여 다닌 유일한 문자일 것이다.4 유니코드 2.0 이전에 한글은 조합되는 형태로 인코딩되지 않았고, U+3400..4DFF 영역에 할당되어 있었다. 현대 한글이 종국에는 아무 의미 있는 순서 없이 유니코드에 통째로 인코딩될 때가 올 거라는 것이 시간이 갈수록 분명해지자, 긴 토론 끝에 한글은 U+AC00..D7FF로 옮겨 갔고 순서도 규칙적으로 바뀌었다. 이 때문에 현재의 한중일 한자 블록이 기존 한글 블록 바로 뒤인 U+4E00에서 시작하는 것이다. (자세한 사항. 여러 참석자들에 따르면 이 전체 과정은 거의 박빙이었고 개판 일보 전이었다 카더라.)

[이 부분에 대해서는 조금 더 설명할 필요가 있겠다. 요전에 신정식 씨가 한글의 11172자 인코딩 자체가 불합리하게 이루어졌다는 주장을 한 적이 있어서 개인적으로 이리 저리 찾아 본 적이 있는데, 실제로 어느 정도의 야바위(…)가 있던 건 사실로 보인다. 인터넷으로 접근할 수 있는 자료가 없어서 불명확한 부분도 많은데 내가 파악한 바를 간단히 요약하면, 유니코드 1.0의 한글은 KS X 1001이 존재한다는 이유만으로 사용자 피드백이 없이 대강 들어간 것이었고, 이 때문에 2.0 표준화 과정에서 한글을 재인코딩하려는 실 사용자측(국가가 아니다! 이 작업을 주도한 주체 중 하나는 다름 아닌 한컴이었다.)의 움직임이 있었는데 표준화 과정에 너무 늦게 들어 오는 바람에 국가들의 반대가 거셌던 것으로 보인다. 그래서 뭔 짓을 했냐 하면 반대파 대표에게 식사를 사 주기도 하고 미국이 중재안을 만들어 오자 아예 비토해 버렸다는 듯… 최종적으로는 한자와는 달리 한글은 현대 한글이 완전히 할당되면 추가 할당이 없을 것이라는 논리가 어떻게든 받아들여져서 통과되었다고 하는데, 과연 어떻게 보면 떼 써서 자기 원하는 바를 관철해 낸 나쁜 선례처럼 보이기도 한다. 다만 기술적인 참작 여지가 어느 정도 있고(유니코드 구현자 입장에서는 확실히 규칙적인 쪽이 편하다), 유니코드에서 허구한 날 싸우는 건 이 때에 국한된 일이 아니긴 하므로 개인적으로는 그냥 초창기 유니코드의 혼돈·파괴·망ㄱ…를 보여 주는 예시로만 보는 것이 옳지 않나 싶다.]

기술적으로는 3바이트 인코딩을 써서 94 × 94 × 94 = 830584자를 사용할 수도 있었다. 하지만 내가 아는 한 이러한 인코딩을 요구하는 문자 집합이 실제로 설계된 적은 없으며, 따라서 실제로 쓸 수 있는 구현도 없다고 볼 수 있다. ↩

[원문에서는 언급하지 않았지만 사실 한자는 한 문자가 (어떤 기준에서든) 낱말을 나타내는 표어문자(logogram)이지 완벽히 뜻만을 나타내는 표의문자(ideograph)가 아니기 때문에 이 영문 표기조차 틀렸다. 한자에는 오로지 문법적으로만 사용되는 문자도 들어 있기 때문이다. 근데 물론 이것도 바꾸기에는 늦었다.] ↩

[어도비에서 유니코드 표준화 과정에 오랫동안 참여해 온 유니코드 전문가. 만약 유니코드에 관심이 많다면 이 분의 블로그는 필독할 것.] ↩

[지적을 받았던 부분이 바로 이 문장인데, 움직인다는 것을 한 종류의 문자 전체가 삭제 없이 다음 버전에 이동한다는 것으로 정의한다면 한글이 유일한 사례인 것이 맞다. 그러나 삭제 후 재인코딩된 경우까지 포함하면 티베트 문자가 1.1에서 사라졌다가 2.0에서 다른 곳에 나타난 경우가 있다고 한다. 개별 문자까지 포함하면 몇 가지 사례가 더 있다는 듯. 아니 나도 유니코드 1.0을 세세히 읽어 볼 생각은 하지 않아서…] ↩

[transego]

유니코드(Unicode)에 대한 혼돈의 역사내용. 흥미진진하다.

[transego]

일본 교토대학 인문과학연구소 부속 동아시아인문정보학연구센터에서 발간한 "한국의 인명용한자와 한자코드"라는 학술지를 읽어보았다. 나는 일본어로 된 "한국의 인명용한자와 한자코드" 내용을 읽고는 전율을 느꼈다. 일본의 한국어 연구 수준, 그리고 인문학 연구수준이 어마어마하다는 걸 느꼈다. 한국에서도 연구가 덜 된 한자의 문자집합과 문자코드 내용에 대하여 일본의 대학연구소에서 밑줄 쫙 정리를 함. 한국의 대학교와 인문연구소는 과연 뭐했나는 생각을 해보았다. (한국에서 인문학 하는 사람은 IT 배경이 없고, IT로 밥벌이 하는 사람은 인문학 배경이 없어 일본의 학술지 내용을 이해할 사람이 있을지 궁금하다) 京都大学人文科学研究所附属 東アジア人文情報学研究センター[교토대학 인문과학연구소 부속 동아시아 인문정보학연구센터] 特集 韓国の人名用漢字と漢字コート ゙[특집 한국의 인명용한자와 한자코드] (安岡孝一・安岡素子編) ● 韓国の人名用漢字[한국의 인명용한자] ● 韓国の漢字コード[한국의 한자코드] ● 韓国の人名用漢字と漢字コードの乖離 [한국의 인명용한자와 한자코드의 괴리] ● 韓国憲法裁判所2016年7月28日決定[한국 헌법재판소 2016년 7월 28일 결정{일본어 번역}]

[transego]

Very few words are borrowings from other languages in the sense that Japanese has many borrowings from English.  Some of these word elements regularly translate a foreign suffix: 化huà, for example, which originally means "to change", translates English -ize, so 現代化(现代化) xiàndàihuà [present era change] is "modernization," 國有化(国有化) guóyǒuhuà [country having change] is "nationalization." 化huh does not always correspond to English -ize, or -ization: 老年化  lǎoniánhuà [old year change] means "aging" in the sense of an aging population, and 複雜化(复杂化) fùzáhuà means "to make something more complicated than it has to be." 化學(化学) huàxué, the study of changes, is "chemistry." Other examples as follow  The suffix 學(学) xué translates－ology, as in  社會學(社会学)  shèhuìxué "socialolgy," or 人類學(人类学) rénlèixué [human type study] "anthropology" The suffix 主義(主义) zhǔyì translates -ism, so 社會主義(社会主义) shèhuìzhǔyì "socialism" 資本主義(资本主义) zīběnzhǔyì "capitalism" 共產主義(共产主义) gòngchǎnzhǔyì [common property -ism] "communism" The classical suffix 者 zhě is added to these to indicate a person who practices the ideology: 社會主義者(社会主义者) “socialist" 學者学者 "scholar"

“The Chinese Language - Its History and Current Usage” written by Daniel Kane

I think, Many wasei kango(和製漢語,Japanese-made Chinese words) were "back-borrowed" into Chinese and Korean around the turn of the 20th century.

Example)

Japanese: 科学 kagaku ('science')

Chinese:  科學/科学 kēxué (from kagaku)

Korean: 과학[科學]  gwahak (from kagaku)

Japanese: 社会 shakai ('society')

Chinese: 社會/社会 shèhuì (from shakai)

Korean: 사회[社會] sahoe (from shakai)

Japanese 哲学 tetsugaku ('philosophy')

Chinese: 哲學/哲学 zhéxué (from tetsugaku)

Korean: 철학[哲學] cheolhak (from tetsugaku)

Japanese: 電話 denwa ('telephone')

Chinese: 電話/电话 diànhuà (from denwa)

Korean: 전화[電話] jeonhwa (from denwa)

[transego]

The spies who need to love data International espionage is now more likely to involve stolen bytes than secret cameras. Agencies such as MI6 are having to fight for their existence By Gordon Corera Security correspondent at the BBC; 
author of Intercept: The Secret 
History of Computers and Spies (W&N)

WIRED (UK) MAY. 2016

[transego]

The authoritative Japanese dictionary Koujien (1983) defines Han characters to be: ...characters that originated among the Chinese to write the Chinese language. They are now used in China, Japan, and Korea. They are logographic (each character represents a word, not just a sound) characters that developed from pictographic and ideographic principles. They are also used phonetically. In Japan they are generally called kanji (Han, that is, Chinese, characters) including the “national characters” (kokuji) such as touge (mountain pass), which have been created using the same principles. They are also called mana (true names, as opposed to kana, false or borrowed names).

The Unicode Standard Version 8.0 - Core Specification Chapter18. East Asia

[transego]

Python의 CJK 라이브러리 조사

Python의 CJK(Chinese-Japanese-Korean,동아시아문자처리) 라이브러리 조사

1. Cjklib 0.3.2 

Homepage: http://cjklib.org/0.3/

Python Package Index: https://pypi.python.org/pypi/cjklib/0.3.2

2. cjktools 1.6.0

Homepage: https://pypi.python.org/pypi/cjktools

Github: https://github.com/larsyencken/cjktools/

위의 2개의 CJK라이브러리를 조사해본 결과, Python2기반으로 작성되었으나, Python3로 변환되지 않았음.

cjklib의 경우는 중국어 중에서 만다린(보통화, 북경어), 상하이어, 광동어(홍콩어), 일본어, 한국어에 대한 지원이 있음을 확인했으나, 라이브러리 사용이 어렵게 느껴짐을 확인.

cjktools의 경우는 중국어와 일본어만 다루기 때문에 CJK(Chinese-Japanese-Korean)의 Korean이 없다는 것을 확인.

위의 라이브러리가 Python3로 변환되지 않은 것을 보고, 이번에 Python3를 공부할겸, Python3의 문자열 처리 및 Unicode Consortium의 unihan database 내용을 확인해보겠습니다.

CJK(Chinese-Japanese-Korean)의 개발에 대한 내용은 Adobe에서 활동하는 Ken Lunde의 책 "CJKV Information Processing"을 참조하여, 사용하기 편한 Python3 라이브러리를 만들어볼 계획입니다.

  아래는 Python CJK라이브러리 조사전에 CJK에 관심을 가지게 된 트윗글

I should seriously consider a revised/updated/retitled version of my #IUC35 presentation: “CJK Uniform Ideographs” → https://t.co/ivGOx1eu8u

— Adobe CJK Type Blog (@CJKType) 2016년 1월 19일

CJK Type - Genuine Han Unification

“Genuine Han Unification is not outside the realm of extreme possibilities.”— Fox William Mulder, FBI Special Agent

슬라이드의 마지막장에 있는 의미심장한 문구

[transego]

Move AWS Tokyo Region's instance to AWS Seoul Region (AWS도쿄 리젼에서 AWS서울 리젼으로 인스턴스 옮기기)

2016년 1월 7일, Amazon에서 AWS Seoul Region(서울 리젼) 설립을 발표하였습니다.

AWS CLOUD ON-DEMAND SEOUL - KOREA

AWS 서울 리젼 홈페이지

Now Open – AWS Asia Pacific (Seoul) Region

AWS Asia Pacific (Seoul) Region 정식 오픈!

위의 발표를 듣고 나서, AWS Seoul Region의 Latency와 AWS Tokyo Region의 Latency를 측정해보았습니다.

측정은 Apache ab와 nginx를 이용하여 다음의 링크를 사용하여 측정했습니다.

AWS Network Latency 측정

http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/cloud/AWS/NetworkLatency

AWS Tokyo Region 

 # ab -n 10 -c 1 http://**.**.**.**/index.html

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking **.**.**.** (be patient).....done

Server Software:        nginx/1.9.9

Server Hostname:        **.**.**.**

Server Port:            80

Document Path:          /index.html

Document Length:        612 bytes

Concurrency Level:      1

Time taken for tests:   0.848 seconds

Complete requests:      10

Failed requests:        0

Total transferred:      8440 bytes

HTML transferred:       6120 bytes

Requests per second:    11.79 [#/sec] (mean)

Time per request:       84.805 [ms] (mean)

Time per request:       84.805 [ms] (mean, across all concurrent requests)

Transfer rate:          9.72 [Kbytes/sec] received

Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:       40   42   1.3     42      45

Processing:    41   43   1.2     43      45

Waiting:       41   42   1.2     42      45

Total:         82   85   1.8     84      88

Percentage of the requests served within a certain time (ms)

  50%     84

  66%     85

  75%     85

  80%     87

  90%     88

  95%     88

  98%     88

  99%     88

 100%     88 (longest request)

AWS Seoul Region

 # ab -n 10 -c 1 http://**.**.**.**/index.html

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking **.**.**.** (be patient).....done

Server Software:        nginx/1.9.9

Server Hostname:        **.**.**.**

Server Port:            80

Document Path:          /index.html

Document Length:        612 bytes

Concurrency Level:      1

Time taken for tests:   0.172 seconds

Complete requests:      10

Failed requests:        0

Total transferred:      8440 bytes

HTML transferred:       6120 bytes

Requests per second:    58.14 [#/sec] (mean)

Time per request:       17.201 [ms] (mean)

Time per request:       17.201 [ms] (mean, across all concurrent requests)

Transfer rate:          47.92 [Kbytes/sec] received

Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        7    9   1.3      9      11

Processing:     6    8   2.2      8      14

Waiting:        6    8   2.2      8      14

Total:         14   17   2.4     17      22

Percentage of the requests served within a certain time (ms)

  50%     17

  66%     18

  75%     18

  80%     19

  90%     22

  95%     22

  98%     22

  99%     22

 100%     22 (longest request)

AWS Tokyo Region Avg. Latency

 87.11111111(ms)

AWS Seoul Region Avg. Latency

 20.22222222(ms)

AWS Seoul Region 의 Latency와 AWS Tokyo Region의 Latency를 비교하니 AWS Seoul Region이 훨씬 빠르다는걸 체감하였습니다.

이후 다운로드 전송량 측정을 해보아도 AWS Seoul Region이 빠르다는 것도 확인하였습니다.

AWS Tokyo Transfer Rate

 9.72 [Kbytes/sec] 

AWS Seoul Transfer Rate

 47.92 [Kbytes/sec]

측정결과 AWS Tokyo와 AWS Seoul간의 엄청난 속도차이를 경험하였고, AWS Tokyo Region의 사용료보다 AWS Seoul Region의 사용료가 조금 더 저렴하다는 걸 보고 깜짝 놀랐습니다.

Cloud Services Pricing

Tokyo 보다 접근 속도가 빠르면서, Tokyo보다 저렴한 Seoul을 사용해야겠다는 결론을 내렸습니다.

기존에 AWS Tokyo Region에서 생성한 인스턴스(Instance)를 AWS Seoul Region으로 옮기는 작업을 진행하였습니다.

AWS Tokyo Region(도쿄/東京 리젼)의 인스턴스를 AWS Seoul Region(서울 리젼)으로 옮기는 방법

이 방법은 

AWS EC2 인스턴스를 다른 지역으로 복사하는 방법

위의 링크를 참조하였습니다. 위의 링크에 있는대로 따라하니 문제 없이 Tokyo Region의 Instance가 그대로 Seoul Region의 Instance로 옮겨지고, 정상작동함을 확인함.

1. AWS Tokyo Region EC2 Instances 메뉴 

옮길려는 인스턴스의 속성 메뉴에서 Create image(EBS AMI)함.

2. AMIs 메뉴 - 새로 만든 AMI 이미지로 Launch Instance 하고 기존에 생성한 Instance와 같은 사양의 Instance를 만든다.

3. Instances 메뉴 - 새로운 Instance가 Running 되면 Instance의 속성 메뉴에서 Stop 한다.

4. Volumes 메뉴 - Instance에 연결된 볼륨의 속성 메뉴에서 Create Snapshot 한다.

5. Snapshots 메뉴 - 새로 만든 스냅샵의 속성 메뉴에서 Copy Snapshot 한다. 

6. 팝업창에서 Destination region 항목에 Seoul Region을 선택한다.

7. AWS Seoul Region EC2Snapshots 메뉴 - Tokyo Region 에서 복사 된 스냅샷의 속성 메뉴에서 Create Volume from Snapshot 한다.

8. Volumes 메뉴 - 스냅샷으로 만든 볼륨의 Volume ID를 확인 한다.

9. Instances 메뉴 - Tokyo Region Instance 와 같은 사양의 Instance를 Launch Instance로 생성하고 Instance가 Running 되면 속성 메뉴에서 Stop 한다.

10. Volumes 메뉴 - Instance에 연결(sda1)된 볼륨의 속성 메뉴에서 Detach Volume 하고 Instance에서 볼륨을 때어낸다. Tokyo Region의 스냅샷으로 만든 볼륨을 속성 메뉴에서 Attach Volume 한다. 

팝업창에서 Instance 항목에 해당 Instance를 선택하고, Device 항목에  "/dev/sda1"으로 수정한 다음 Yes, Attach 해서 볼륨을 붙인다.

12. Instance 메뉴 - Stop 되어 있는 Instance를 Start 한다. Instance가 Running 되면 접속해서 확인한다.

이제 AWS Seoul Region이 생겼으니 Seoul Region을 애용해야겠습니다 ~_~

[transego]

[일본어(日本語) 및 한국어 번역 링크] 무료로 읽을 수 있는 전자책 정리 + 추가 Github의 awesome list 소개

출처:  【合計600冊以上】無料で読める技術系の電子書籍 2015年版まとめ

번역(飜譯, 翻訳,翻译,Translation) - [총 600 권] 무료로 읽을 수 있는 기술적인 전자 책 2015 년판 정리 by Google Translate

관련링크: 무료로 읽을 수 있는 기술서적 추천입니다. 

Facebook에서 돌아다니고 있는 2015년도에 정리한 무료로 읽을 수 있는 기술관련 전자책 링크가 화제입니다.

일본어 포스팅을 쭉 보다 보니, 영어로 된 좋은 전자책들이 무료로 풀린걸 대부분 정리한 것 같군요. 

일본어로 된 블로그 포스팅에 올라온 몇몇 전자책 다운로드 링크를 보고 다운로드 받아서 보고 있는데, 상당히 좋은 영어 원서 책들을 잘 정리한 것 같더군요.

2016년도에는 영어 공부 하면서 기술 공부도 틈틈히 할 계획입니다.

추가로, 필요한 영역에 대한 전자책이 부족하다 생각하면 GitHub의 Awesome List 를 참조하면 됩니다. 

Github의 Awesome List는 다양한 분야에 대하여 정리된 자료들의 모음입니다. Github사이트에서 여러 사람들이 작성된 컨텐츠를 모으고 정리한 걸 공개하는게 유행이더군요.

저는 가끔씩 개발하다 막히는 부분이 있으면 GitHub의 Awesome list를 검색해서 개발 관련 정리된 글목록들을 보고 있습니다.

(대부분이 영어 컨텐츠, 한국어로 된 컨텐츠는 xguru님이 정리한 "대학생을 위한 웹 개발 공부용 체크리스트"목록을 참조하면 되지만 컨텐츠가 부족하다고 느낄수 있을 것입니다.)

jnv/lists  - https://github.com/jnv/lists 

The definitive list of lists (of lists) curated on GitHub

아래는 Github에 올라온 Awesome에 대한 정리를 한 목록입니다.

awesome-* - https://github.com/jnv/lists#awesome-

Xguru님께서 정리한 "대학생을 위한 웹 개발 공부용 체크리스트"

https://github.com/xguru/WebDevTutorial 

아래는 제가 예전에 블로그에 정리한 무료 전자책 링크입니다

2011/11/15 - [컴퓨터] - [StackOverflow] 무료로 제공되는 컴퓨터 프로그래밍 서적들

위의 내용을 정리하다보니 Github의 Awesome-*으로 시작하는 목록의 글이나 일본사람이 정리한 전자책의 링크를 보면 집단지성이라는 것이 대단하다는 생각을 해보았습니다.

[studioego]

유명한 일본 기술컨퍼런스들의 운영체제에 대한 표 정리

2015년 3월 25일 발간된 WEB+DB Press Vol. 85의 기사- “技術カンファレンス運営の本当の裏側(기술 컨퍼런스 운영의 실제 뒷면)"을 읽어보았습니다. 여기서는 표에 대한 내용만 발췌하여 정리하였습니다.

"技術カンファレンス運営の本当の裏側(기술 컨퍼런스 운영의 실제 뒷면)"에서 일본의 기술 컨퍼런스가 어떻게 운영되는지에 대하여 정리된 표를 보니, 준비를 열심히 해야되는거라는걸 깨달았습니다.

각 이벤트의 운영체제(運營體制)[各イベントの運営体制]

이벤트명

 참가자수

 주요스태프수

 당일 스태프수

 사용툴(Tool)류

 RubyKaigi

 약 750명

 일본Ruby회이사+감사5명, 기타 5명

 20명 

 GitHub

 YAPC::Asia Tokyo

 약1,300명

 기획+JPA이사, 5~6명의 핵심스태프

 40~50명

 Slack, GitHub

 JANOG

 약1,000명(도쿄)  약600명(지방)

 위원회제, 전체 30~40명 

 없음

 Mail, ChatWork, Confluence, JIRA

 PyCon JP

 약550명

 위원회제, 전체 30~40명

 없음

 Slack, JIRA

나의 평:

위의 컨퍼런스 참가자 수를 보니 엄청난 수의 일본 개발자들이 컨퍼런스에 참여한다는 것을 알게 됨.

위의 참가자와 발표자를 지원하는 스태프를 약 30~40명정도로 구성되어 도와준다는 걸 보고 대단하다는 생각을 해봄.

그리고 사용 툴을 보니 생각보다 Slack을 많이 사용한다는 것을 느끼게 됨.

예전 2015년 8월 21일~2015년 8월 22일에 열린 YAPC::Asia Tokyo 2015행사를 가봤는데 발표하는 사람이나 참가자나 대부분 Slack으로 의사소통을 하는 걸 보고 신기하다고 느끼던 적이 한둘이 아니였던 강렬한 기억이랄까?

컨퍼런스를 준비하려면 정말 꼼꼼하게 준비해야되는걸 느끼게 된 기사였음.

위의 기사와 관련된 링크 정리

Conference Organizers Summit (Sort Of) https://medium.com/@lestrrat/conference-organizers-summit-sort-of-b84eddf6534b#.jc6lsidgx

技術イベント主催者の本音がココにある！ WEB+DB PRESS Vol.85 スペシャル企画でチョロっと出てます http://blog.kushii.net/archives/1951972.html

Software Design 2015/3月号とWeb+DB Press vol 85 http://lestrrat.ldblog.jp/archives/43483020.html

[transego]

블로그 및 내가 사용하고 있는 텀블러 계정으로 업로드.

[transego]

2016년 새해를 맞이하여 WIRED(UK)[와이어드 영국판]편집국에서 2016년도의 유행(Trend)등을 예측한 WIRED - The World in 2016 을 보고 있습니다. 2015년도와 뭐가 달라졌는지 구경중입니다. 와이어드 잡지를 볼 수록 세상에 다양한 생각을 가진 사람이 많구나를 느끼고, 내 생각이 짧고 멀리 보지 못한다는 걸 느끼고 있음.

[transego]

Web+DB Vol.89 Special Report - YAPC::Asia Tokyo 2015 발췌번역 및 핵심 발표 동영상 및 슬라이드 공유

이 내용은 일본 IT잡지 WEB+DB Vol.89의 특별기고 “YAPC::Asia Tokyo 2015″의 요약, 축약 번역이며, 발표때 공개된 발표 동영상과 슬라이드를 한국어 사용자들을 위해 공유합니다.

잡지 내용은 요약, 축약 번역이기 오역. 직역체가 난무합니다. 잡지 내용의 일본어를 완전히 아는 것이 아니므로 동영상과 슬라이드를 참조하여 이 글을 구성하였습니다. 전체 글에 대한 번역은 아닙니다.

そして今回は@VienosNotesさんによるYAPC::Asia 2015のレポートも掲載。Larry Wallの基調講演（トールキン話だ！）など3つをピックアップしてご紹介しています。Perl 6もリリース間近ですね……みなさんもう試されましたか……？ #wdpress

— WEB+DB PRESS編集部 (@wdpress) 2015년 10월 26일

青木大佑(AOKI Daisuke, 아오키 다이스케) 

Twitter: @VienosNotes 

2015년 8월 20일부터 22일에 걸쳐, 도쿄 빅사이트에서 “YAPC::Asia Tokyo 2015”가 개최되었습니다. 올해는 10회째로 열린 YAPC::Asia이지만, 이번 행사는 마지막으로 발표되는 것도 있고 훌륭한 토크가 몇몇 있었습니다, 그 중 몇가지를 소개합니다. -----

メリークリスマス！ / Larry Wall(메리크리스마스/래리 월)

Perl6와 반지의 제왕(Perl6と指輪物語) 기조연설은 Perl을 만든 아버지로 알려진 Larry Wall씨가 “메리크리스마스!”을 이야기 하였습니다. Larry Wall씨는 J.R.R. Tolkien씨의 “호빗"과 "반지의 제왕” 2개의 소설의 관계를 Perl5와 Perl6의 관계 간의 동통점이 많다는 것을 이야기 했습니다. “호빗”을 출간한 후로, 톨킨(Tolkien)이 15년의 세월동안 "반지의 제왕”을 완성한 것과 같이, Perl6도 올해에 발표까지 15년째입니다.  지금까지, "반지의 제왕"과 “호빗”의 줄거리를 바탕으로 좋은 작품이 되었습니다만, Perl6도 다양한 컨셉(개념)을 Perl5에서 가져와, 좋은 언어를 목표로 하였습니다 그러나 "표현력이 뛰어나다, 쉬운 것은 쉽게, 어려운 것일수 있다”는 점을 Perl5에서 받아 연결한 이념을 이야기 하였습니다 그래서 Larry Wall씨는 “제대로 실패”라는 것의 중요성을 강조하였습니다. Perl6를 좋은 것으로 모으기 위하여 여러가지 신기능을 검토하였습니다. 좋은 아이디어로 판명하는데 시행착오 중의 흥미를 깊이 끄는 심층 조달를 여러가지 범 지금까지 “약속은 할 수 없지만”이라고 전제를 한 뒤, 올해의 크리스마스는 Perl6을 릴리즈할 예정입니다. 이것이 오늘의 발표입니다. 기대되네요! ps. 역자주: 영화 및 책  The Hobbit(한국어명: 호빗)을 일본에서는  ホビットの冒険(호빗의 모험)으로 번역되었고, The Lord of the Rings (한국어명: 반지의 제왕)을 일본에서는 指輪物語(반지이야기)로 번역이 되었습니다. 번역자는 한국어 사용하는 독자를 위해   ホビットの冒険(호빗의 모험)를 “호빗”이라고 번역 및 指輪物語(반지이야기)를 "반지의 제왕”이라고 번역했습니다. 세계규모서비스를 디플로이하는 방법

世界展開する大規模ウェブサービスのデプロイを支える技術 (글로벌 출시하는 대규모 웹서비스의 디플로이를 지원하는 기술)

Miiverse는 멀티 디바이스에 대응하는 커뮤니케이션 서비스입니다. 구조는 일반적인 웹 서비스와 대체로 같습니만, 일본, 미국, 유럽의 3개의 지역에 걸친 세계규모의 디플로이는 특유의 곤란함을 가지고 있습니다. 처음에는 Git을 사용한 pull형의 배치를 하고 있습습니다만, 부하의 높이와 Github Enterprise를 사용한 개발 모델과의 상성이 불편한 문제등이 있었습니다, 우선 서브프로젝트를 위한 새로운 디플로이툴을 작성하기로 결정했습니다. 이 새로운 디플로이툴은 내부는 Consul과 Stretcher같은 툴을 이용하여 효율적인 디플로이를 실현하고 있습니다. 버젼업할때, 성과물을 Amazon S3등의 스토리지들에 설치하고, Consul의 이벤트기능을 사용하여 각호스트에 요구를 통지하였습니다. 통지를 받은 호스트는 디플로이 순서로 성과물을 받아서, 메니페스토 파일(Manifesto file)을 바탕으로 아티팩트(Artifact)를 검색하고 배포를 실행하는 흐름입니다. 이 새로운 도구의 벤치마킹에서 기존의 수법을 비교하여 약 40배의 퍼포먼스를 발휘하는 대성공을 하였습니다. HTTP/2시대의 웹(HTTP/2時代のWeb)

HTTP/2시대의 웹(HTTP/2時代のWeb) / jxck

HTTP/2는 브라우저등의 통신에 이용하는 HTTP/1.1의 차기버전이고, 올해 2월달에 RFC7540으로 책정한 새로운 사양입니다. 웹의 진보에 따라 리퀘스트 숫자도 1회당 전송량도 증가를 하였습니다. HTTP/2는 이러한 문제를 해결하기 위해 다양한 방법이 도입되었습니다. jxck씨에 따르면 HTTP/2는 책정phase부터 사용phase로 이행했다고 합니다. HTTP/2는 이미 많은 브라우저에 대응되어 있으며, 웹서버에도 대응하는 것이 많아지고 있습니다. 에코시스템(생태계)의 성숙을 위해서도, 구조를 이해하고 있는 상태로 전환이 중요하다고 언급

아래는 "HTTP/2시대의 웹(HTTP/2時代のWeb)"의 발표슬라이드 입니다.

HTTP2 時代の Web - web over http2 from Jxck :)

[transego]

iOS 9.2 Released.

2015년 12월 09일에 Apple사에서 iOS9.2를 출시하였습니다

Apple사가 iOS 9.2출시를 하였으니, 지금 사용중인 iPad mini2와 iPhone 6s Plus에 업데이트를 하였습니다 ​

변경 사항은 다음과 같습니다

이 업데이트는 다음과 같은 기능 향상 및 오류 수정을 포함합니다. •  Apple Music 향상         ◦ 재생목록에 노래를 추가할 때 새로운 재생목록을 생성할 수 있음         ◦ 재생목록에 노래를 추가할 때 최근에 변경한 재생목록이 목록의 가장 위에 위치함         ◦ iCloud 다운로드 버튼을 탭하여 iCloud 음악 보관함에서 앨범 또는 재생목록을 다운로드함         ◦ 나의 음악 및 재생목록에 있는 각각의 노래 옆에 새로 표시되는 다운로드 표시기를 통해 어떤 노래가 다운로드됐는지 알 수 있음         ◦ Apple Music 카탈로그에서 클래식 음악을 탐색할 때 작품, 작곡가 및 연주자를 표시함 •  하루 중 가장 중요한 뉴스를 최신으로 접할 수 있도록 News에서 Top Stories 섹션을 새로 제공(News App은 미국, 영국 및 호주에서 사용 가능함) •  Mail의 Mail Drop으로 대용량 첨부 파일을 보낼 수 있음 •  iBooks에서 목차, 메모, 책갈피의 페이지 또는 책 안의 검색 결과 페이지를 Peek 및 Pop 할 수 있도록 3D Touch 제공 •  iBooks에서 보관함을 탐색하고, 다른 책을 읽고, iBooks Store를 탐색하는 동안 오디오북을 들을 수 있음 •  iPhone에서 사진 및 비디오를 가져오기 위한 USB 카메라 어댑터 지원 •  Safari 안정성 향상 •  Podcast 안정성 향상 •  POP 이메일 계정을 사용하는 일부 사용자들이 메일 첨부 파일에 접근할 수 없던 오류 수정 •  일부 사용자들에게 메일에서 첨부 파일이 텍스트와 겹쳐서 보이던 문제 수정 •  이전 iCloud 백업을 복원한 후 Live Photo가 꺼지던 문제 해결 •  연락처에서 검색 결과에 아무것도 표시되지 않던 오류 수정 •  캘린더의 주별 보기에서 요일 일부가 표시되지 않던 문제 해결 •  iPad에서 비디오를 촬영하려고 할 때 카메라 화면이 검은색으로 보이던 문제 해결 •  서머타임제 변경일을 표시할 때 활동 App이 불안정해지던 문제 해결 •  건강 App에서 데이터가 표시되지 않던 오류 수정 •  Wallet 업데이트 및 잠금 화면 알림이 표시되지 않던 문제 수정 •  iOS를 업데이트하면 알람이 울리지 않던 문제 해결 •  일부 사용자들이 나의 iPhone 찾기에 로그인할 수 없던 문제 해결 •  일부 iCloud 수동 백업이 완료되지 않던 오류 수정 •  iPad 키보드를 사용할 때 예기치 않게 텍스트 선택 모드가 작동하던 문제 수정 •  빠른 답장을 사용할 때 키보드 반응 향상 •  10-키 중국어(병음 및 자획) 키보드에서 문장 부호 및 개선된 예상 단어를 확장하여 표시함으로써 구두점 입력을 향상함 •  LGU+ 네트워크상에서 통화 및 문자에 영향을 미치던 문제 해결 •  키릴어 키보드에서 URL 또는 이메일 필드에 입력할 때 caps lock 키가 활성화되던 문제 해결 •  손쉬운 사용 향상         ◦ 카메라 얼굴 인식을 사용할 때 발생하던 VoiceOver 관련 문제 수정         ◦ 화면을 깨우는 데 VoiceOver 지원 추가         ◦ 3D Touch 동작으로 App 전환기를 실행하는 데 VoiceOver 지원 추가         ◦ 통화를 종료하려고 할 때 발생하던 사용법 유도 관련 문제 해결         ◦ 3D Touch를 사용할 때 스위치 제어 사용자를 위한 기능 향상         ◦ 화면 말하기의 말하기 속도와 관련된 문제 수정 •  Siri의 아랍어(사우디 아라비아, 아랍 에미리트 연합국) 지원 이 업데이트의 보안 콘텐츠와 관련된 자세한 정보는 다음 웹 사이트를 참조하십시오.  https://support.apple.com/ko-kr/HT201222

[radiofun]

영어로 일하기

디자인 관련 글은 아니지만, 혹시나 외국 회사로의 이직을 생각하는 분이 있다면 도움이 될까 싶어서 제 경험을 공유해 봅니다. 다른 곳으로 전재되지 않았으면 좋겠습니다.

–

외국 회사에서 영어를 쓰며 일하기 시작한 지 이제 1년이 거의 다 되어간다. 그 동안은 한국 회사에서 한국말만 쓰며 일해왔기 때문에 ‘말이 안통한다'는 건 의견이 대립될때나 쓰는 표현이었다. 하지만 정말 말이 안통하는 곳에서 일하게 될 줄이야.. 

참고로, 나는 영어권 국가에서 거주한 경험이 없고, 30여년 동안의 인생을 모조리 한국에서 보냈다. 학창시절엔 영어 점수를 제법 잘 받는 편이었지만, 지하철에서 길을 헤매는 외국인이 보이면 혹시나 말을 걸까 가던 길을 돌아가는 평범한(?) 한국 남자 중 한명이라고 할 수 있다.

벙어리 3개월

한국에서 일할 때에도 말수가 많은 편은 아니었지만, 입사 후 첫 3개월은 말이 없어도 너무 없었다. 회의 시간엔 거의 묵언 수행을 하는 수준이었고, 리액션이라고 해봐야 고개를 끄덕이는 게 전부였다(못 알아 들었는데도 장단을 맞춘 적도 있었다). 일단 들리는 말이 모두 영어라는 것이 과부하를 줬고, 생각이 정리되어 의견을 말할 수 있을 때 즈음엔 이미 나는 호텔 침대에 누워 있었다. 

일을 할 때엔 내가 외국인이라고 생각해서 천천히 말해주거나, 내 의견을 일부러 물어봐주지 않는다. 나서서 말하지 않으면 누구도 “자네 의견은 어떤가" 라고 말하지 않는다. 대화의 흐름 속에 자연스레 의견을 끼워넣는 분위기에서 가뜩이나 처리 속도가 느린 내가 말을 보탤 여유따윈 없었다. 하필이면 오자마자 디자인 스프린트에 들어가서 그런지, 더더욱 힘들었다.

하지만 입을 다물고 있으면 영원히 다물고 있게 된다. 어느 날은 “굳이 내가 의견을 보태지 않아도 될 정도였어" 라고 자위하기도 했지만, 보통은 내가 의견을 내지 않으면 모든 것은 남들 뜻대로 흘러가게 된다. 영겁과도 같은 시간이었다. 내가 과연 말을 하게 될 시간이 오기나 할까? 자신감이 많이 떨어졌고, 한국으로 돌아가고 싶다는 생각이 들었다.

굳이 내가 여기 있을 이유가 없다는 생각을 많이 했던 시기였는데, 어차피 내가 여기 오려고 계획했던 것도 아니고, 지금으로선 서울에서 일하는 게 더 자연스러운 일이었다. 언제 돌아가도 이상한 일은 아니다. 안되면 돌아가면 되지 뭐.

그렇게 바닥을 치고 나자 차라리 아무 말이나 해보자는 생각이 들었다. 어차피 자연스럽게 끼기는 무리다. 그래서 무작정 손을 들었다. 번쩍 손을 든 나를 보고 처음엔 모두 당황했는데, 어쨌든 내가 발언권을 확실하게 가지게 되었고, 그 순간엔 긴장도 되고 해서 뭐라고 했는지 기억도 안날 정도로 횡설수설했지만 그 순간 이후로 말하는 것에 조금씩 부담을 덜게 되었다.

아직도 대화 중에 자연스레 말을 얹는 건 어려운 일이다. 하지만 조금씩 요령이 늘었다. “hmmm..”, “uhmmm..”, “well”, “one question” 같이 말길을 일단 터 놓고 그 다음에 되는대로 이야기하거나, 아니면 말할 키워드를 슬쩍 적어둔다. 그리고 적어둔 순간에서 그리 멀지 않은 순간에 그냥 일단 끼어든다. 내가 지금 말 안하면 누가 비슷한 내용의 말을 해버리기가 쉽고, 그럼 내가 적은 키워드는 버려지기 때문이다. 

사실 말하는 것에 집착할 이유는 전혀 없긴 하지만 말을 못하는 상황이 싫어서 계속 어거지로 말을 보태려고 노력했던 것 같다.

뭐라고? (Sorry?)

이번에 깨달은 안좋은 습관은, 확실하게 모르는데도 대충 아는 것 처럼 퉁치고 넘어가는 것이었다. 처음에 다소 바보같이 보이더라도 정확하게 질문을 파악하고, 내 의견을 확실하게 이야기하는 것이 낫다. 두루뭉술하게 넘어가는 건 외국어에선 거의 불가능한 것 같다. 특히 저쪽에서 요구사항을 이리저리 이야기했는데 내가 대강 알아들었다고 해서 넘어가면 디테일한 부분에서 문제가 생기는 경우가 있다. 서로 다른 아이콘을 3개 달라고 했는데, 같은 아이콘을 3 버전 그려간다거나 하는 경우는 비일비재하다. 특히 구두로 이야기가 오가는 경우에 실수가 많이 생긴다.

어차피 나는 네이티브가 아니고, 질문은 나쁜 일이 아니다. 오히려 제대로 안물어보고 마음대로 하는게 문제다. 하지만 처음엔 뭔가 “뭐라고?”하는 말 자체가 왠지 모르게 실례처럼 느껴졌다. 그래서 되도록이면 한번에 알아들은 척을 하려고 넘어갔다. 

회사의 특성 상 화상 회의가 잦은데, 화상 회의는 더더욱 고역이었다. 일단 내 의견을 제대로 표현하지도 못할 뿐더러, 남의 질문조차 제대로 들리지 않기 때문에 대답을 제대로 하지 못하는 경우가 많았다. 그냥 회의에 들어가면 슬쩍 묻어가기가 쉽지만, 화상회의는 정확하게 내 이야기를 하지 않으면 할 이유 자체가 없다. 그래서 더욱 힘들었다. 발표를 할 때에는 대본을 준비하기도 했지만 질문에는 속수무책이었다.

잘 안들리던 말이 제대로 들릴 리도 없다. 그럴 때엔 그냥 “뭐라고?”를 말해야 하는 것 같다. 내가 어떤 말을 제대로 못알아 들을때면, 그 사람은 똑같은 말을 반복하기도 하지만, 좀 더 쉬운 표현으로 바꿔주는 등의 노력을 해서 뜻을 전하려고 노력한다. 그렇게 하면 두 배 세 배의 시간이 들긴 하지만, 무턱대고 일을 진행해서 일을 되돌리는 수고를 덜 수 있다. 

구두로 확인이 되었다고 해도 모든 게 확실하지 않을 수도 있으니 처음 몇 개월 간은 다시 메일을 보내 내가 이해한 바를 전달했고, 틀린 게 있으면 수정해달라고 물어봤다. 그렇게 해서 구두 커뮤니케이션에서 생길 수 있는 오류를 미리 잡으려고 노력했다.

인정했어야 하는 것은 나는 영어를 잘 못하는 사람이라는 사실이었다. 그 동안은 겉멋이 들었는지 대충 발음 굴리고 하면 말 잘하는 것 처럼 보이겠지 하는 착각속에 살았다. “번역도 좀 하니까 난 영어를 잘해, 그러니 영어를 잘하는 사람처럼 굴어야지.” 라고 생각했다. 그래서 발음이 이상할까봐 걱정했고, 내가 잘 못 알아듣는 것 처럼 보일까봐 걱정했다. 

하지만 그런건 전혀 중요한 게 아니었고, 그 사람이 말하는 바를 얼마나 잘 이해하고, 내가 말하고자 하는 바를 정확하게 전달하는 것이 핵심이라는 것을 깨달았다. 표현이 틀리거나 문법이 이상한 건 문제가 아니다. 점잖은 사교 자리라면 문제가 될 수도 있겠지만, 나는 일을 하러 왔고, 일을 잘 끝낸다면 그 외의 문제는 그렇게 중요하지 않다.

잡담

위에 적어둔 것 처럼 힘겹게 일을 하고 나면 만사가 피곤했다. 내 모국어가 아닌 언어로 하루종일 이야기하는 것은 쉬운 일이 아니다. 영어를 하루 종일 하고 나면 마치 밥을 굶은 사람 처럼 한국어가 고파진다. 그래서 한동안은 바깥에도 안나가고 그냥 한국 방송만 찾아봤다. 하지만 그렇게 하고 나면 다음 날이면 다시 모든 것이 리셋이 된다. 그러면 다시 영어를 힘들게 말해야 하고 돌아오면 한국어가 고파지는 악순환이 이어졌다.

이 회사에는 1:1이라는 게 제법 널리 퍼져있다. 잘 모르는 사람이라도 같은 회사 안에 있다면 쉽게 “커피나 한잔 하며 이야기하자" 라고 미팅을 잡을 수 있다. 순다 피차이나 마티아스 듀왈테 같은 사람이야 좀 어렵겠지만, 사실 만나자고 한다면 그런 사람들 조차 의외로 쉽게 만나줄 수도 있을 것 같은 느낌이다. 내 경우엔 Framer 커뮤니티에서 조금 알려진 덕을 봤는데, 원래 커뮤니티에서 알던 친구들이 나에게 커피를 마시자고 연락을 하는 경우도 있었고, 내가 커뮤니티에서 보던 친구에게 커피를 마시자고 연락을 하는 경우도 있었다.

만나서 하는 이야기는 미팅에서 하는 이야기보다 훨씬 가벼울 수 밖에 없고, 내가 잘 아는 분야 (Framer) 였기 때문에 말을 하기도 쉬웠다. 게다가 1:1 이기 때문에 내가 하는 말의 속도를 그쪽에서도 쉽게 받아주고, 내가 말을 할 기회도 훨씬 많아진다. 게다가 만약 그 친구가 다음 회의에 들어오게 된다면 긴장도 좀 덜 하게 되기도 한다. 억양이나 자주 쓰는 표현들도 잡담을 하면서 좀 더 익히게 되기 때문에 전반적으로 자신감이 올라가는 효과가 있다.

잡담은 일보다 긴장도가 낮고, 계속 나를 영어를 쓰는 환경에 노출시켜 내가 영어로 말하는 데에 거부감을 줄여주는 효과가 있었다. 그래서 내가 먼저 1:1을 많이 요청했다. 단순히 영어에 익숙해지는 것을 넘어서 회의 때 차마 못한 말을 하거나, 서로간에 공감대를 형성하는 데도 효과가 컸다. 그렇게 한 두번 만나다 보면 회사 밖에서도 가끔 보게 되고, 그렇게 하다 보면 어느새 친구가 된다. 이렇게 한 덕분에 이제 회사에는 아는 사람들도 제법 생겼고, 그 덕분에 회의도 쉬워지고, 일도 쉬워지게 되었다. 상대적인 이야기긴 하지만.

–

여전히 영어는 힘겹다. 일주일 내내 영어로 말하고 나면 여전히 한국어가 고프다. 하지만 이제 적어도 집에 가고 싶다는 생각은 들지 않는다. 처음의 악몽같은 시간은 결국 영원히 이어지지는 않았다. 외국이라고 해도 사람이 사는 곳이고, 사람이 사는 곳이니 어떻게든 익숙해지게 되어있는 것 같다. 내가 조금 덜 체면을 차리고, 본질에 집중했다면 괴로운 시간이 빨리 끝날 수 있었을 것 같다.