[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

2016년 4월 4일 월요일

[Book] 개발자를 부탁해..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

개발자를 부탁해 - 6점
주한나(새퍼 양파) 지음
인사이트

이 책은 저자가 새퍼 앙파의 런던 일기라는 블로그를 운영하면서 작성한 글을 바탕으로 책을 구성한 것이라고 볼 수 있습니다. 물론 이 책을 보기전에는 블로그에 대해서 알기 때문에 이 책의 어느정도가 블로그에 있는 글인지는 잘 모르겠습니다. 책을 읽기 전부터 큰 기대를 한 것은 아니었지만 사실 이 책에 대해서 좀 실망했습니다. 이 책에 대한 정보를 보신 분들은 아시겠지만 대부분 개발자에 대한 연애가이드 정도로 생각하실텐데 실제 내용은 약간 다르고 아무래도 기대와 다르기 때문에 실망한 감도 없지 않습니다.

1장 "개발자 팬터의 연애"와 2장 "SOS!! 개발자 팬더가 애인이예요!"는 말그대로 개발자를 위한 연애 가이드입니다. 사실 이 두장은 상당히 재미있게 읽었습니다. 이 책에서는 개발자 혹은 공대성향의 사람들을 팬더라고 정의하고 있고(이는 이공계 종사자가 아닌 이공계적인 성격을 가진 사람을 의미합니다.) 여성분들을 꽃팬더라는 호칭으로 부르고 있습니다. 전혀 모르고 있던 사실은 아니지만 상당히 팬더들의 심리적인 부분이나 성향을 잘 파악하고 있고 그 부분에 대해서 유쾌하게 잘 설명하고 있습니다. 2장은 팬더를 애인으로 두고 있는 여자분들한테 어떻게 다루어야 하는지 안내해주는 내용인데 이또한 꽤 재미가 있습니다. 팬더들의 사고방식을 여러가지 상황에 비추어 설명하고 있기 때문에 웃음도 나면서 꽤 재미있게 보았습니다.

하지만 여기까지였습니다. 1,2장이 이 책의 1/3정도인데 연애에 대한 부분은 여기까지가 끝입니다. 3장 "꽃팬더의 개발일기"는 딱히 무엇을 말하려고 하는지 알수 없는 저자가 개발하면서 틈틈히 쓴 일기가 기록되어 있습니다. 회사에서 기술선택하면서 논쟁했던 얘기, 신입들에 대한 생각, 구직하던 얘기등등인데 머 그냥 에세이 정도로 딱히 전달하려고 하는 내용은 없는듯 합니다.

4장 "초보 개발자에게 보내는 편지"는 제가 느끼기에는 신입 개발자에게 대한 조인이라기 보다는 일반적인 사회적인 조언에 더 가깝다고 할 수 있습니다. 물론 개발에 대한 얘기도 어느정도 있지만 전체적인 느낌이 그러하다는 것입니다.  신입으로써 사랑받기 위한 방법이라든지 신입한테 딱히 기대하는것 없으니 착가하면 안된다던가 일 열심히 한다고 월급오르지 않는다던가 하는 이야기입니다.

1,2장 이후에는 책을 읽으면서 좀 지루했는데 팬더적 성향을 가지고 있는 저에게는 이 책의 표현대로라면 "반복적이거나 뻔한 정보를 접하는 것"이기 때문에 지루하다는 표현을 쓴 것입니다. 내용이 어떤 인사이트를 주기 어려울 만큼(물론 이는 제가 이젠 신입의 입장이 아니기 때문일수도 있습니다.) 평이한 내용이고 강압적인 보스에게는 복종하는 것이 낫다라고 하는 것은(혹은 그게 더 승진하는 방법이다.) 너무 뻔한 내용이고 다들 알만한 내용일 뿐만 아니라 그게 책으로 전달되어야 할 만큼 권장사항이 되어야 하는 것인가 하는 것입니다. 저는 별로 동의할 수 없는 내용들이 종종 나옴으로써 더 책에 집중하기 어려웠습니다. 예를 들면 프로그래머로써 HTML/CSS는 최악의 선택 톱 3에 들어간다면서 자바스크립트도 권장하지 않는 부분인데 요즘 분위기에 반하는 것이기도 하고 제 경험상 대부분 서버쪽 개발자들은 이런 프론트앤드 기술에 너무 무지하기 때문에 잘 만들어진 마크업을 망가뜨려버리는 것이 대부분이었습니다. 이런 부분은 위의 언급처럼 이런 기술을 무시(?)하는 경향때문에 잘 모르면서 딱히 공부하려고도 하지 않는 영향이라고 생각합니다.

이 책을 읽으면서 어떤 생각지 못한 인사이트나 자극을 받으려고 한 것은 아니었습니다. 하지만 연애에 대한 부분이 더 많은 부분을 차지했다면 그냥 즐겁게 읽었을것 같기도 합니다.



[Talk]SNS 서비스들에 대한 개인적인 생각..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

요즘 개인사정으로 다른 기술만질 시간도 없고 해서 SNS를 많이 쓰는터라 각 SNS에 대한 개인적인 생각을 좀 적어봅니다. 싸이월드같은 서비스는 거의 써보질 않았었지만 페이스북, 트위터등이 인기를 얻은뒤에 다 가입해서 써보려다가 친구를 구하지 못해서 실패해서 한참동안 방치하다가 최근 몇년간은 없어서는 안될 서비스들이 되어버렸습니다. 그리고 이는 지극히 주관적인 것임을 밝힙니다.

트위터
트위터는 SNS중에 제가 가장 좋아하는 서비스입니다. 머 트위터가 SNS이냐라고 할수도 없는데 요즘같은 상황에 Social Network의 범주에 넣을수 없는 것이 거의 없지만 Social Network를 맺는 것이 주요한 서비스이용의 기반이라고 생각했을 때 저는 SNS에 포함된다고 생각하고 있습니다. 물론 Social Network를 맺은 뒤에 어떤 활동을 중점으로 하는가는 다른 SNS와는 확실히 다른 성향을 가지고 있습니다. 트위터 스스로도 서비스의 정체성을 "Real-time Information Network"로 새로 정의한 바 있습니다.

트위터가 실시간 정보네크워크로 정의한것처럼 트위터는 정보전달력이 무척이나 강력합니다. 저는 관계지향적이라기 보다는 정보지향적이기 때문에 엄청난 정보가 흘러다니는 트위터를 다른 서비스보다 중요하고 훨씬 유용하게 생각하고 있습니다. 140자밖에 기록할 수 없는 트윗이지만 트위터 특유의 Retweet이라는 기능으로 인하여 유용한 정보가 엄청나게 빠른 속도로 전파되기 때문에 트위터만 제대로 보고 있으면 세계각지에서 일어다는 IT관련 소식을 말그대로 실시간으로 알 수 있습니다. 저는 이런 트위터를 좋아하기 때문에 제 모든 웹의 활동이 트위터로 모이도록 하고 있습니다. 딜리셔스의 북마크나 플리커에 사진업로드, 블로그의 포스팅등이 최종적으로 트위터로 모이고 전파됩니다.

트위터의 140자라는 것은 트위터의 제약이기도 하지만 동시에 엄청난 장점이라고도 생각하고 있습니다. 대부분의 메시지가 인스턴트성이 강한데다가 140자로 메시지의 사이즈가 일정하기 때문에 매시간 올라오는 수십, 수백개의 메시지를 확인하는 것에 다른 서비스에 비한다면 그리 많은 피로도가 느껴지지 않고 빠르게 제가 원하는 정보만 취할 수 있습니다. 물론 사적인 얘기를 이곳에서 안하는 것은 아니지만 그 가운데 대부분은 정보의 취득과 개발자들과 이야기에 중점을 두고 있습니다. 그렇기 때문에 Why Twitter's "Information Network" Strategy Is Under Pressure From Facebook & Google Plus라는 글도 있기는 하지만 저는 페이스북과 구글 플러스가 정보네트워크에서 트위터를 상대할 수 없을꺼라고 생각하고 있습니다. 제 성향상 페이스북보다 오히려 트위터를 더 높은 가치에 두고 있습니다.

페이스북
현재 세계에서 가장 큰 소셜네트워크 서비스이고 엄청난 성장과 F8 플랫폼등 화려한 시절을 보내고 있습니다. 페이스북은 말그대로 SNS라는 이름에 충실한 서비스이고 최근에 발표한 새 UI는 완전히 한 사람의 일상을 모두 담아낼 수 있는 서비스로 발전하려고 하고 있습니다. 이는 확실히 페이스북이 잠시 인기를 누린 서비스정도가 아닌 아직도 미래가 창창한 서비스임을 스스로 보여준 일이라고 생각합니다. 단순 SNS서비스에만 있지 않고 Like버튼과 페이스북 댓글까지 페이스북의 영향력을 전체 웹으로 영향을 미치면서 그 강력함을 더 강화시키고 있고 대부분의 SNS에 기능에 영향을 미치고 선두해 나가고 있습니다.

페이스북은 그 컨셉대로 오프라인 인맥을 그 중심으로 두고 있고 앞으로도 그게 크게 달라지지는 않을듯 합니다. 사실 SNS라는 것 자체가 어떤 사람을 친구로 두느냐에 따라 서비스를 이용하는 행태가 크게 달라지고 있습니다. 저같은 경우는 트위터의 친구와 페이스북의 친구가 약간 다른데 실제로도 오프라인에서 알고 있는 사람들의 상당수이고(페이스북의 제 친구는 140여명밖에 되지 않습니다.) 제가 페이스북에 직접 글을 올리는 경우는 많지 않고 트위터의 올라온 글이 연동되어서 페이스북으로 올라가고 그글에 대한 사람들의 피드백에 리액션을 하는 정도입니다.

또한 저의 페이스북의 주요 활동은 그룹입니다. 다른 서비스보다 강력한 기능으로 아는 사람들과 어떤 비공개 논의를 하기위해서 여러가지 그룹에서 이야기를 하는 것이 저의 페이스북의 활동의 대다수입니다. 그럼에도 페이스북은 제 주위사람들의 삶을 알 수 있는 아주 강력한 도구이고 이는 관계를 상당히 돈독하게 하고 있습니다. 점점 UI가 바뀌어 갈때마다 스토킹 수준으로 느껴질 정도로 이런 부분이 강력화되어가고 있고 지속적으로 성장하는 페이스북의 힘이라고 생각하고 있습니다. 당분간은 SNS의 1위의 바뀔 일은 별로 없을꺼라고 생각하고 요즘은 정보네트워크로의 영향력을 넓히려고 하고 있습니다. 하지만 저는 소셜네트워크에 비해서 정보네트워크는 트위터에 비해서 약하다고 생각하고 있습니다. 이는 각 글의 길이가 꽤나 길고(사진과 링크도 올라오는 등) 주위사람의 개인적인 사생활과 정보성 글의 구분이 약간 애매한 부분이 있다고 생각하기 때문입니다.

구글 플러스
그다지 많이 쓰지는 않고 구글 플러스만 쓰시는 분들이 약간 있어서 하루에 몇회정도만 방문해서 보는 정도로만 쓰고 있습니다. 구글은 SNS를 잘 못한다고 알려진대로 이번에는 야심차게 내놓기는 했지만 여전히 애매하기는 마찬가지라고 생각하고 있습니다 . 너무 많은 기능들을 섞어놓은 관계로 오히려 구글 플러스만의 색이 거의 느껴지지 않은 서비스가 되었다고 생각합니다. 이런 저런 성장에 대한 통계가 나오고 있기는 하고 IT업계 위주로 사용하고 있기는 한데 이는 트위터의 140자 한계에 대한 아쉬움과 개발자들이 자주 쓰는 구글의 가가까 붙어있는 덕이 상당부분 있다고 생각하지만 거기까지가 아닌가 생각합니다.

일단 써클이란 개념은 UI적으로는 무척 흥미롭지만 개념상은 아주 모호하다고 생각합니다. 트위터의 경우 내가 팔로잉한 사람의 글을 보고 나를 팔로잉한 사람이 내글을 본다는 구독개념이 아주 명확하고 관계가 단방향이라는 것이 트위터의 장점이라고 생각합니다. 페이스북의 경우는 서로 친구를 맺어서 서로의 글을 보고 유명한 사람의 글을 구독해서 본다는 점이 명확합니다. 하지만 써클은 그렇지 않습니다. 많은 사람들을 써클에 그룹지어서 분류한다는 것은 특징이긴 하지만 이는 오히려 모든 사람은 어떤 분류에 넣어야 한다는 피로도를 제공하고 내가 써클에 추가한 사람의 글을 본다는 건 명확한데 구글플러스에서는 써클을 타겟으로 글을 쓸수도 있기 때문에 내가 특정써클의 타겟으로 글을 쓰면 그 중에 저를 써클에 포함하지 않은 사람에게 글이 어떻게 전달되는가는 이해하기 어렵습니다. 물론 이는 Incoming으로 들어오기는 하는데 저는 이사실을 알기전까지 한번도 Incoming을 눌러본 적도 없기 때문에 다른 사람도 이사실을 인지하고 있는지 의심스럽습니다. 내가 누군가를 대상으로 글을 작성했는데 그 사람이 인지하지 못한다는 것은 이해하기가 어렵습니다.

행아웃등의 흥미롭고 괜찮은 서비스가 있기는 하지만 이런 서비스때문에 구플이 성장하지는 않을꺼라고 생각하고 기본적인 SNS의 요소가 제대로 강화되고 있지 못합니다. 일단 한달에 글을 한번 쓸까말까한 저를 계속 추가하는 사람들이 계속 있다는 것만 보아도 사람들의 행동패턴이 다른 서비스에 비해서 일반적이지 않습니다. 자신만의 서비스를 만들지 못하고 모든 SNS요소를 다 합친 뒤에 억지로 추가적인 요소를 넣으려다보니 오히려 애매하게 되지 않았나 생각하고 있습니다. 물론 구글플러스를 좋아하는 분들이 계시고 서비스의 미래는 더 두고 보아야 할일이지만 저로써는 별로 정을 못 붙히고 있습니다.

미투데이
미투데이는 가장 먼저 써보려고 했다가 실패했었지만 스터디등을 통해서 알게된 개발자들이 주로 미투데이에 있어서 사용하게 된 서비스입니다. 미투데이는 트위터를 벤치마킹해서 공감을 의미하는 미투라는 컨셉으로 성공한 국내서비스입니다. 성공여부에 대해서는 이견이 있을수도 있겠지만 벤처가 척박한 국내에서 서비스를 성공적인 수준으로 올려서 대기업에 인수된 것은 성공사례로 볼 수 있다고 생각합니다.

미투데이는 약간 폐쇄적인 서비스라고 생각합니다. 미투데이의 제 친구들은 70여명정도밖에 되지 않는데 주로 이런 저런 농담따먹기를 하는데 이용하고 있습니다.(물론 이는 무척 즐겁고 저는 미투데이를 좋아합니다.) 하지만 제가 폐쇄적이라고 하는 이유는 SNS는 그 성격상 관계가 계속 증가하고 그 관계로 인하여 새로운 유저가 (본인이 원치 않더라도) 서비스를 이용하게 되는 것이 SNS가 강력하고 여기에 많은 서비스들이 집중하고 있는 이유라고 생각합니다. 저도 이런 관계때문에 미투데이를 이용하기 시작하기는 했지만 서비스특성상 지속적으로 친구관계가 증가할 수 있는 요소가 그리 많지 않았습니다. 트위터의 경우 리트윗이라는 개념으로 모르는 사람의 글이 저한테 계속 노출되고 그러면서 저는 새로운 사람을 추가하게 됩니다. 페이스북의 경우도 제 친구들이 하는 행위들이 저한테 계속 보고되기 때문에 그로인해서 친구의 친구를 발견하고 친구를 맺게 되는데다가 지속적인 친구추천으로 인해서 이런 활동을 적극 권장하고 있습니다.

하지만 미투데이는 이런 시스템이 그리 강력하지 않았습니다. 제 친구들의 글에 다른 사람들의 댓글이 나타나긴 하겠지만 그 외에는 새로운 사람들이 저한테 영향을 끼칠 일이 많지 않습니다. 그런 패턴에서 사용하던 미투데이사용자들은 일정 친구범주이내에서만 교류하는 것에 만족하고 있었기 때문에 미투데이측에서도 이런 부분에 대해서 고민이 있었을 꺼라고 생각합니다.(물론 연예인 마케팅으로 이 문제를 해결하려고 했지만 이는 시스템상으로 지속적으로 커져갈 수 있는 방법은 아니었다고 생각합니다.) 이 부분을 해결하기 위해서 미투데이는 친구추천을 포함하고 소셜게임을 붙히고 미투버튼에 Like이나 리트윗같은 전파기능을 추가하였습니다.

미투버튼에 전파기능을 넣은 것은 미투데이측에서는 어쩔수 없는 선택이었을 꺼라고 생각하고 얼마전에는 페이스북과 같은 미투댓글 플러그인도 공개했습니다. 하지만 저는 초기 미투데이의 성공요인중의 하나였던 공감이라는 의미의 미투라는 시맨틱이 지금은 방해(?)가 된다고 보고 있습니다. 미투는 사실 전파요소를 넣기에 그다지 좋은 시맨틱을 가지고 있지 않습니다. Like는 말그대로 이글을 내가 좋아한다는 의미로 리트윗은 단순히 이글을 전파하겠다 정도, +1버튼은 단순히 추천이라는 의미를 가지고 있습니다. 하지만 미투는 그 말대로 me too라는 시맨틱을 가지고 있습니다. 이는 전파에 약간 제약이 된다고 생각합니다.

"내일 장가갑니다." -> "좋아요"
"내일 장가갑니다." -> "미투"

"A국회의원 부정비리 발각" -> "좋아요"
"A국회의원 부정비리 발각" -> "미투"

위 예를 보면 시맨틱적으로 이상합니다. 저 글을 전파할 필요가 있는가는 다른 얘기이고 위의 내용을 보면 미투의 시맨틱이 그다지 이어지지 않는 것을 느낄 수 있습니다. 좋아요는 시맨틱적으로 많이 이상하지 않지만 미투는 시맨틱적으로 약간 이상합니다. 전파기능이 필요하게 되자 미투에 억지로 전파기능을 넣다보니 스스로 시맨틱을 뭉개버리는 결과를 낳았다고 봅니다. 제가 저 글에 미투를 눌렀을때 사람들은 "저도 장가갑니다."로 볼지 그냥 전파를 위해서 했다고 볼지는 저도 잘 모르겠습니다. 저는 웹은 시맨틱적으로도 매우 중요하다고 생각하기 때문에 시간이 갈수록 이부분이 미투데이에 극복해야할 문제중 하나라고 생각합니다.(실제로도 저는 미투를 누를까 말까 고민하게 되는 일이 상당히 많이 있습니다.)

SNS가 웹에서 점점 중요해지고 있는 가운데 많은 서비스들의 움직임을 바라보는 건 꽤 즐거운 일입니다.


My Comment..
위 글은 햄이 서두에 언급한것처럼 지극히 주관적인 견해를 담은 글이라서 읽기만 하고서 지나치려고 했다.. 하지만 읽다보니 내가 SNS 를 많이 사용하지 않는 사람이다보니 특성들이나 몰랐던 기능, 활용도 등을 알 수 있게 되어서 꼭 내가 아니더라도 SNS 에 입문하려는 사람이 혹시라도 행당 글을 보게되면, 조금이라도 도움이 될 듯 해서 갖고 왔다.. 나도 SNS 활용을 좀 잘해야되는데 생각처럼 잘 안된다.. IT 업계에 있으면서도 왜 그런게 잘 안되는지 원.. ㅠㅜ

[UFC]다니엘 코미어 UFC197 Out.. 대체자는 생프루..

출처 : SPOTV NEWS

UFC 라이트헤비급 챔피언 다니엘 코미어(37, 미국)는 오는 23일(이하 한국 시간) UFC 197 출전을 포기할 때 무척 속상했다. 2009년 9월 종합격투기에 데뷔하고 18경기(17승 1패)를 뛰면서 한번도 부상 때문에 출전을 연기하거나 취소한 적이 없었기 때문이다.

코미어는 3일 인스타그램 등 SNS에 팬들에게 전하는 사과문을 남겼다. "UFC 197에 나서지 않기로 한 것은 살면서 가장 힘든 결정 가운데 하나였다. 지금까지 18경기를 예정대로 모두 소화했다. 존 존스, 로렌조 퍼티타, 데이나 화이트, 모든 UFC 팬들에게 사과하고 싶다. 지금 너무 슬프다. 그러나 인생이 그렇듯, 이렇게 흘러갈 것이다. 회복하는 데 그리 오래 걸리지 않을 것 같다. 빨리 타이틀 방어전에 나서고 싶다. 팬들의 응원 하나하나에 감사하다."
▲ UFC 라이트헤비급 챔피언 다니엘 코미어는 종합격투기 파이터 생활 처음으로 부상으로 출전을 포기했다. ⓒGettyimages
▲ UFC 라이트헤비급 챔피언 다니엘 코미어는 종합격투기 파이터 생활 처음으로 부상으로 출전을 포기했다. ⓒGettyimages
미국 종합격투기 뉴스 사이트 MMA 파이팅에 따르면, 코미어는 지난달 26일 가볍게 킥복싱 훈련하다가 왼쪽 다리를 다쳤다. 자기공명영상(MRI) 촬영 결과 정강뼈와 종아리뼈의 골간막(interosseous membrane)이 파열돼 있었다. 골간막은 긴 뼈와 뼈 사이를 잇는 인대를 말한다.

■ UFC 197 대진
[라이트헤비급 잠정 타이틀전] 존 존스 vs 오빈스 생프루
[플라이급 타이틀전] 드미트리우스 존슨 vs 헨리 세후도
[라이트급] 앤서니 페티스 vs 에드손 바르보자
[미들급] 로버트 휘태커 vs 하파엘 나탈
[페더급] 야이르 로드리게즈 vs 안드레 필리
[플라이급] 서지오 페티스 vs 크리스 켈라데스
[여성 스트로급] 카를라 에스파르자 vs 줄리아나 리마
[웰터급] 대니 로버츠 vs 도미닉 스틸
[라이트급] 글라이코 프란카 vs 제임스 빅
[라이트헤비급] 마르코스 호제리오 데 리마 vs 클린트 헤스터
[라이트급] 에프라인 에스큐데로 vs 케빈 리

My Comment..
해당 기사는 우선 슬픈일이 아닐 수 없다.. 다니엘 코미어존 존스 간의 라헤비급 타이틀전은 정말 기다리던 대진이고, 과거 코미어가 지고 난 후에도 빨리 재대결을 해서 존 존스를 때려눕혀주길 바랬다.. 그렇다 난 존 존스가 싫다.. 왜냐면, 우선 상대에 대한 배려가 없다.. 그리고 본인의 실력이 강하고 잘 하는건 맞지만, 사생활이 너무 방탕하다.. 이미 수감되었던 전적도 그렇고 문제가 있었던 선수이기에 이번에야 말로 코미어가 챔피언 입장에서 존 존스를 확실하게 이겨주길 바랬던게 개인적인 소망이자 바램이었다.. 흥행성에서 좋은 활약을 하는것은 맞지만, 존 존스를 어느정도면에서 감싸주는 UFC 의 태도도 솔직히 맘에는 안든다.. 너무 돈에만 치우치는 행보 같아서 말이다.. 어쩔 수 없지만, 코미어가 부상에서 어서 완쾌하길 빈다.. 그렇다면 바뀐 대전 상대는 누구냐 생프루 이다.. 생프루는 약간 생소한 선수였는데 과거 쇼군에게 충격의 KO 승을 따내는 것을 보고, 운동신경 하나는 타고났다고 느끼게 된 선수였다.. 이번에는 라헤비급 잠정 챔피언전에서 가망성이 좀 희박해보이지만, 존 존스를 이겨줬으면 한다..

[Talk]Steve Jobs, Rest In Peace..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/


해당 글은 스티브 잡스 추모성의 글이다.. 그래 이미 시간은 꽤나 지난 시점이다.. 2011년도 글이니.. But, IT 업계에 한 획을 그은 사람의 죽음 그리고 그에 대한 글.. 내가 딱히 애플사를 좋아하거나 동경하지는 않지만, 대단한 사람, 대단한 회사임에는 틀림 없기에 추억하며 글을 갖고와본다..

이미 많은 사람들이 글을 남겨서 대부분의 RSS의 글들이 스티브잡스에 대한 추모로 가듣찼지만 그만큼 큰 일기에 저도 기록을 남깁니다. 아침에 평소처럼 SNS를 키자 믿기힘든 뉴스가 SNS에 가득하더군요. CEO에서 물러난지 얼마되지도 않았고 무척 수척해진 모습을 알고는 있었지만 이렇게 빨리 갈줄은 몰랐습니다. 56세라니 빨라도 너무 빠르지요...

애플 홈페이지에 걸린 스티브

지인의 부고가 아니었음에도 하루동일 왠지 기분이 짠했습니다. 잡스없는 세상은 여전히 빠르게 흘러가고 있는데 말이죠. 그 유명한 스탠포드 연설의 "Stay Hungry. Stay Foolish"는 제 블로그 스킨에 걸어놓은 문구이기도 하고 현재 제 맥북의 바탕화면이기도 합니다.


Steve-Jobs-Timeline


생각해 보면 제가(정확히는 저희 형제가) 처음 가졌던 PC가 애플 2e였었습니다. (그당시에는 애플도 잘 몰랐지만..) 제가 애플빠가 아님에도 온 생애가 도전과 혁신으로 가득찬 스티브 잡스는 항상 많은 영감을 주었습니다. (잡스의 생애를 담고 있는 all about Steve Jobs라는 사이트도 있더군요.)

잡스의 프리젠테이션은 항상 감탄스럽지만 1984년에 매킨토시를 발표하는 모습은 지금봐도 감동인것 같습니다. 즐겁게 보던 이런 영상들이 이젠 맘속에 애잔함이 묻어나오는군요. 오늘 전 세계의 IT인들이 울었습니다. 락스타도 아닌 잡스가 얼마나 많은 사람에게 영향을 끼치고 있었는지 느낄 수 있는 하루였습니다. 그냥 추모만 하는게 아니라 그가 추구하던 혁신과 도전을 닮으려고 노력해야 겠지요. 애플의 많은 제품을 가지고 있지만 잡스가 이렇게 되고 보니 잡스가 제게 남긴 것은 단순한 뮤직플레이어, 노트북, 스마트폰이 아닌 그 이상의 것이었다는 생각이 드는군요. 수차례나 세상의 패러다임을 바꾼 잡스가 한 20년만 더 건강히 살았다면 세상이 어떻게 더 달라졌을까 궁금하기도 합니다.

그는 제가 아는 한 가장 기술과 사용자를 잘 결합할수 있는 사람이었습니다. 현실에 맞춰서 기술을 가로막지도, 너무 기술만 내세워서 현실과 동떨어지지도 않은 결과물을 상상하고 이뤄낼 수 있었기에 이런 혁신이 있었던것 같습니다.

사용자 삽입 이미지

19살의 jonathan mak가 만든 애플마크에 잡스의 얼굴을 절묘하게 합친 디자인이 참 인상적이군요.

Innovation distinguishes between a leader and a follower.
Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.

당신과 동시대에 살면서 당신의 생애를 보고 느낄 수 있어서 영광이었습니다.

I already miss you.

덧) 37signals의 Jason Fried가 심플하게 가장 잘 정리한듯 하군요. 마지막의 Now what are you going to change? 가이제 생각해 보아야 할 문제인듯 합니다.


[DEV]크로스브라우져 테스팅 서비스 : BrowserStack..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

프론트앤드 개발에서 사실 가장 피곤한 것중 하나는 크로스브라우져에 대한 테스트를 하는 것입니다. 브라우저 개발경쟁이 가속화되서 빠르게 버전업이 되는 가운데 브라우저의 교체도 빨라질테지만 현재 상황에서는 점점 수가 많아지는 브라우저때문에 테스트가 귀찮기도 하지만 사실 한 머신에 이 수많은 브라우저를 다 설치할 수도 없기 때문에 테스트환경을 마련하기가 쉽지 않습니다. 대부분의 버전에 대한 테스트환경이 갖추어져 있다면 모를까 특정 브라우저에서만 발생하는 문제의 경우 개발자의 컴퓨터에 해당 브라우저가 설치되어 있지 않다면 확인할 수 없기 보통 곤욕이 아닙니다.

BrowserStack은 크로스브라우징 테스트를 할 수 있도록 해주는 웹서비스입니다. 웹서비스 이기 때문에 브라우저 내에서 사용이 가능하고 웹브라우저만 있으면 로컬머신에 어떤 환경설정도 필요하지 않기 때문에 사용하기가 편리합니다.(물론 무료서비스는 아니고 상용서비스입니다.)

브라우저 스택에 로그인한 화면

브라우저스택에 대시보드입니다. 가운데 퀵스타트가 있고 왼쪽에 사이드바가 있습니다. 뭐 메뉴는 간단하기 때문에 굳이 설명할 필요도 없습니다. 브라우져스택의 상용모델은 여러가지가 준비되어 있고 처음 가입을 하면 1시간의 사용시간을 줘서 서비스를 사용해 볼 수 있습니다. 1시간을 다 써보지는 않았지만 매달 1시간이라거나 그렇지는 않고 처음 1시간만 주는것 같습니다.

브라우저 스택의 지원브라우저

사용가능한 웹브라우저 리스트는 위와 같습니다. 보다시피 5대브라우저를 모두 지원하고 있으며 실제 서비스를 한다고 생각하면 필요한 거의 모든 브라우저를 다 지원해 주고 있습니다.

브라우저스택의 지원 해상도

해상도에 대한 확인을 위해서 해상도도 선택해서 실행할 수 있고 Full Screen옵션에 체크하면 풀스크린으로 볼 수도 있습니다. 물론 PC의 풀스크린은 아니고 왼쪽 사이드바가 없어진 접속한 브라우저 창 내에서의 풀스크린입니다.(딱히 큰 의미는 없어보입니다.)

퀵스타트 화면에서 원하는 URL을 입력하고 Start Testing버튼을 클릭하면 아래와 같이 서버가 시작되고 있다는 상태가 나타납니다.

브라우저 스택의 테스트 시작화면

제가 했을 때는 7초정도면 스타트가 끝나고 아래와 같이 브라우저를 확인할 수 있었습니다.

브라우저 스택의 IE 사용화면

설정한 IE7.0으로 입력한 구글홈페이지가열렸습니다. 사실 브라우져스택은 웹기반의 VNC를 이용해서 클라우드에 올려져 있는 PC에 접속해서(아마 Virtual Machine이겠죠) 브라우저를 보는 것이기 때문에 실제 브라우저와 완전히 동일합니다. 직접 VNC를 쓰는것 보다는 약간 느리겠지만 테스트하는데 무리는 없을 정도의 성능은 보여준다고 생각합니다.

브라우저 스택의 크롬 사용화면

브라우저 스택의 파이어폭스 사용화면

위처럼 구글 크롬과 파이어폭스도 잘 나옵니다. 개발자 입장에서 브라우저로 접속해 볼수만 있는 것은 큰의미가 없습니다. 저같은 경우는 QA분 자리에서만 오류날때가 특히 그러한데 디버깅도구가 없기 때문에 확인해보기는 없고 제PC의 최신브라우저는 잘 돌아가고 할때 참 골치아픈데 브라우저스택을 개발자도구까지 모두 지원해 주기 때문에 테스트하면서 디버깅까지 해 볼수 있습니다. 지원하는 디버깅 도구에 나와 있듯이 파이어버그, 크롬개발자도구, IE개발자도구, 드래콘 플라이등 익히 알려진 대부분의 개발자도구가 이미 설치되어 있고 그 외에 유용한 플러그인까지 깔려있습니다.

터널링 설정화면

왼쪽의 Setup Tunnel버튼을 누르면 자바애플릿이 실행되면서 아직 퍼블릭도메인을 갖지 않은 서비스에 대해서도 테스트해볼 수 있도록 로컬에 대한 터널링을 할 수 있도록 제공하고 있습니다.(이건 테스트까진 안해봤습니다.)

불편한게 없다고 할 수 있는 서비스는 아니겠지만 크로스브라우징의 현실을 생각했을 때는 현재로썬 가장 깔끔한 대안서비스가 아닌가 생각합니다. 동작하는 것은 아래의 스크린캐스트를 보시면 금방 이해하실 수 있을것입니다. [어느 정도는 내 기준이지만, 시간이 좀 지난 포스팅이기도 하고, 스크린캐스트를 봐야 될 정도의 난이도 높은 부분은 아니기에 해당 부분은 가져오지 않았다..]



[JS]해시뱅(#!)에 대해서..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

해시뱅을 처음 본 것은 작년에 트위터가 새로운 웹사이트를 선보였을 때입니다.

트위터 접속 화면

제 트위터 계정인 http://twitter.com/outsideris로 접속하면 http://twitter.com/#!/outsideris로 리다이렉트 되는데 URL의 중간에 있는 #!를 해시뱅(HashBang)이라고 부릅니다.(저도 이번에 알게 되었네요.) 처음에 저 URL을 보았을때 상당히 찝찝했습니다. "이 보기 좋지 않은 URL은 무엇인가?"정도의 생각을 하면서 넘어갔던 같습니다.

저는 약간 웹 순수주의자에 가깝기 때문에 웹에 기본은 HTML이고 극단적으로 말하자면 요즘 같은 게임이나 지도같은 특이케이스 아니고 웹사이트라면 자바스크립트를 끈 채로도 동작할 수 있어야 한다고 생각합니다. 물론 그것을 지향점이라는 것이지 현실적인 어려움을 부정하는 것은 아닙니다. 여기서 현실적인 어려움이란 개발자나 관련자의 마인드나 기술 부족이나 일정관련된 문제등을 이야기 하는 것이고 위에 말한대로 다 하기 어려운 부분이 있지만 가능하다면 그렇게 되어야 된다고 생각합니다. 그런 부분에는 URL이 시맨틱해야 한다고 생각하는 것도 포함되어 있기 때문에 URL가운데 의미없는 #!가 들어가 있는 것은 눈에 영 거슬렸습니다. 그렇게 넘어갔다가 최근에 다른 글을 보다가 해시뱅에 대해서 많은 논의에 대한 글을 보게 되어서 관련 글들을 읽고보고 정리합니다.

해시뱅(#!)은 무엇인가?
해시뱅에 대해서 이야기 하기 전에 일반적인 웹사이트의 동작을 먼저 보겠습니다.

  1. 사용자가 브라우저에 http://twitter.com/outsideris를 입력합니다.
  2. 브라우저가 http://twitter.com/outsideris를 서버로 보냅니다.
  3. http://twitter.com가 가리키는 트위터서버로 이동이 됩니다.
  4. 서버는 /outsideris가 무엇인지 알기 때문에 적당한 HTML을 만들어서 클라이언트에게 리턴합니다.
이게 해시뱅을 사용하기 전의 트위터나 일반적인 웹사이트가 동작하는 구조입니다. 해시뱅을 이용한 현재의 트위터는 아래와 같이 동작합니다.

  1. 사용자가 브라우저에 http://twitter.com/#!/outsideris를 입력합니다.
  2. 브라우저가 #뒤에 부분인 !/outsideris를 로컬에 저장하고 http://twitter.com/를 서버에 보냅니다.
  3. http://twitter.com가 가리키는 트위터서버로 이동이 됩니다.
  4. 서버는 루트페이지의 HTML을 대량의 자바스크립트 링크와 함께 클라이언트에게 리턴합니다.
  5. 브라우저가 자바스크립트를 실행시키고 /outsideris를 파싱해서 oustideris에 대한 데이터를 서버에 요청합니다.
  6. 서버에서 받은 데이터를 화면에 적절하게 뿌려집니다.
위 동작 설명을 보면 알 수 있듯이 URL의 # 기능인 앵커(anchor)를 이용한 것입니다. 현재 페이지에서 #뒤에 있는 name으로 되어 있는 태그를 찾아서 그곳으로 이동되기 때문에 보통 가이드 문서에서 목차의 내용으로 바로 이동되는 데 사용되는 것이고 이것을 이용해서 #뒤에 !/outsideris를 붙혀서 마치 URL처럼 보이도록 한 것입니다. 일반적으로 이 방법을 사용할 때 #!라고 쓰기 때문에 해시뱅이라고 부릅니다.

왜 해시뱅이 필요한가?
해시뱅이 필요한 이유는 단일 페이지 웹애플리케이션을 만들기 위해서입니다. 해시뱅을 사용하는 사이트들은 전통적인 웹사이트가 아닌 웹애플리케이션이라고 보아야 합니다. 자바스크립트의 성능이 급격히 증가한 이후에 페이지의 전체를 로딩하는 대신에 페이지를 딱 한개만 두고 자바스크립트 만으로 모든 메뉴를 다루는 것에 대한 요구사항이 생겼고 그것을 구현하기 위해서는 페이지가 갱신되지 않는 것이 중요한데 현재 기술로는 페이지 갱신없이 URL을 변경할 수 있는 방법이 없습니다. 그렇기 때문에 페이지 갱신없이 URL이 변경되는 것처럼 보이도록 하기 위해서 해시뱅을 사용하는 것입니다. 해시뱅에서 #뒤에 이는 부분을 fragment identifier라고 부릅니다.

기존의 레가시를 위해서 웹애플리케이션도 북마크할 수 있고 링크를 공유하고 검색엔진에 인덱싱 될수 있으려면 현재는 해시뱅이 없이는 불가능합니다. 해시뱅을 사용한 것은 전통적인 웹사이트의 레가시를 깨뜨리지 않으려는 절충안이라고 볼 수 있습니다. 현재 기술로써는 웹애플리케이션과 웹사이트를 동시에 지원할 수는 없기 때문에 어느쪽이든 한쪽을 선택할 수밖에 없는 것이었습니다. 해시뱅을 사용하고 있는 곳에서도 pushState같은 기술이 완전히 보급되어 웹애플리케이션과 웹사이트를 동시 지원할 수 있게 되는 것이 가장 좋다는 데는 이견이 없습니다.(현재 사파리, 크롬, 파이어폭스가 지원하고 있습니다.)

이는 과도기적인 기술입니다. HTML5의 Histroy API인 pushState가 모든 브라우저에서 지원이 된다면 보기싫은 해시뱅은 사용하지 않아도 되지만 현재 pushState는 일부의 브라우저에서만 지원이 가능한 것이기 때문에 그때까지 이같은 요구사항을 이뤄내기 위해서 해쉬뱅이라는 것이 도입된 것입니다. 해시뱅을 사용하는 곳에서도 해시뱅이 별로 이쁘지 않고 완벽하지도 않다는 것은 동감하지만 현실적으로 유용하다는 것입니다.

해시뱅은 웹에 좋지 않습니다.
해시뱅의 문제점은 단순히 이쁘지 않은 URL의 문제가 아닙니다. 이는 웹페이지가 아닌 자바스크립트 웹애플리케이션이기 때문에 자바스크립트가 동작하지 않으면 사이트전체가 동작하지 않습니다. 단순히 자바스크립트를 사용할 수 없는 환경에 있는 사용자 뿐만 아니라 어떤 문제로든 자바스크립트 파일이 제대로 로드되지 않는다면 사용자는 사이트를 전혀 이용할 수가 없습니다.(인터넷이 좋지 않은 환경등에서는 얼마든지 발생할 수 있는 일입니다.)

자바스크립트 로드문제 뿐만 아니라 스크립트 오류 혹은 흔히 실수하는 JSON에서 마지막 엘리먼트뒤에 콤마(,)를 찍는 단순한 실수로도 전체 웹사이트를 망가뜨릴 수 있습니다. 더군다나 웹사이트에 광고를 게제하는 경우 광고가 포함하고 있는 자바스크립트는 일반적으로 품질이 좋지 않기 때문에 이 자바스크립트로 인하여 웹사이트가 망가질 수 있습니다. 이는 컨텐츠가 자바스크립트와 아주 강력하게 커플링 되었음을 의미하는데 프로그래밍에서 커플링은 항상 좋지 않은 것으로 인식되어 왔습니다.

국내에서는 유명하지 않지만 GwakerLifeHacker라는 사이트가 올 초에 해시뱅을 사용해서 리뉴얼하고 오픈하면서 이 잠재적인 문제로 사고가 크게 터졌었다고 합니다. 이전의 LifeHacker는 100만개의 페이지를 가진 사이트였지만 새로운 사이트는 100만개의 Fragment Identifier를 가진 하나의 페이지가 된 것입니다. (이유는 모르겠지만) 수시간동안 자바스크립트 파일이 로드되지 않았고 그 덕에 사용자들은 두 사이트의 어떤 컨텐츠에도 접속을 할 수 없었습니다. 이 장애가 해결되기 까지는 거의 하루가 걸렸던것 같습니다.  기존의 웹에 비해서 해시뱅이 깨지기 쉬운 웹이라는 것을 Gwaker와 LifeHacker가 몸소 보여준 격이 되었습니다.

또 다른 문제로는 크롤러의 문제가 있습니다. 크롤러는 검색엔진이 웹사이트의 내용을 알기 위해서 사이트의 컨텐츠를 긁어가는 봇인데 대부분의 크롤러는 HTTP 1.1과 URL 스펙(RFC-2396같은)을 따르고 있는데 이것을 따르는 크롤러는 자바스크립트를 실행시키지 않기 때문에 해시뱅으로 만들어진 사이트의 컨텐츠를 가져갈 수 없습니다. 크롤러가 보는 페이지는 내용이 없는 빈 페이지일 뿐입니다.

구글은 fragment idendifier URL을 변경하는 것으로 이 문제를 해결했습니다.  예를 들어 www.example.com/ajax.html#!key=value 와 같은 해시뱅 URL을 구글은 www.example.com/ajax.html?_escaped_fragment_=key=value와 같은 괴상한 URL로 변경 합니다. 이렇게 변경된 URL은 실제 컨텐츠를 가리키는 URL이 되고(서비스 업체에서 그렇게 만들어야 겠죠.)구글은 이것을 색인합니다. 구글은 이것을 일반적인 앵커용도의 #과 웹애플리케이션에서 사용한 #를 구별하기 위해서 #뒤에 !를 붙혀서 웹애플리케이션 사이트들을 구별할 수 있도록 제시함으로써 해시뱅이 생기게 된 것입니다. 하지만 현재 구글봇만 색인이 가능하고 실제로 Gwaker와 LifeHacker가 문제가 생겼을때 구글 검색 및 여러 뉴스 사이트에서 Gwaker와 LiferHacker가 제외되었다고 합니다.

또한 이제 캐시를 제대로 할 수 없게 되었습니다. 중개서버가 이를 다룰 수 있는 방법이 없기 때문에 사이트는 모든 트래픽을 다루어야 합니다. 그리고 구글봇이나 웹브라우저 기반의 봇만 마이크로포맷의 데이터를 볼 수있기 때문에 마이크로 포맷을 비롯한 시맨틱 기술들이 잠재적으로 버려졌습니다. 페이스북의 Like 위젯같은 경우 페이지의 URL로 구분을 하기 때문에 글에 위젯을 달기 위해서는 추가적인 작업이 필요하게 되었습니다. 더군다나 이는 리퍼러도 깨뜨립니다. 리퍼러에는 fragment identifier가 넘어오지 않기 때문에 리퍼러를 보고 실제 방문자가 찾아온 원글을 찾아갈 수 없게 되었습니다.

결론
양쪽의 의견이 다 어느정도 합리적이라고는 보지만 저 같은 경우에는 해시뱅을 반대하는 입장입니다. 게임같은 경우가 아닌 트위터나 LifeHacker는(LifeHacker는 현재는 원래로 돌아간듯 합니다.) 페이지 설질상 애플리케이션보다는 컨텐츠의 성격이 강하기 때문에 애플리케이션을 선택한 것 자체가 그다지 좋지 않은 선택이었다고 생각하는 편입니다.

URL이 퍼머링크의 역할을 하는 것이나 검색의 중요성, 웹브라우저뿐만 아니라 모든 크롤러나 리더등도 내용을 문제 없이 읽을수 있어야 하는 것은 웹의 근본에 포함되어야 하는 것이기 때문에 설사 과도기적이라고 하더라도 이런 돌연변이 형태의 것이 생기는 것은 그다지 찬성할 수 없습니다.(각 서비스에 따라 다른 의견을 가질수는 있겠지만요.) 관련글들에서 본것 처럼 curl로 사이트의 정보를 얻을 수 없다면 그 사이트는 이미 깨진 것이라는 것에 동의하고 있습니다.

사실 구글도 해시뱅을 사용하고 있지는 않지만(아마 구글을 크롤링하는 곳은 없어서인지 몰라도) 그냥 #만을 사용해서 웹애플리케이션처럼 리뉴얼 되어있습니다. 그래서 현재 curl로 구글에 요청해서 검색결과를 받아올 수 없습니다. 얼마전에 검색결과를 가져와서 보여주는 예제 소스를 짜다가 이문제를 발견했었는데 그당시에는 원인도 자세히 몰라서 무척 고생한 기억이 납니다.

금융권이나 정부기관같은 한국형[여기서 한국형이란 웹의 사상을 전혀 이해하지 못한채 요구사항만으로 기술을 억지로 가져다 붙혀서 엉망으로 만들어버렸다는 의미로 사용했고 대부분의 한국형이란 말이 붙은 것들도 결과물을 보면 그다지 다르지 않다고 생각합니다.] 사이트들도 아닌 어느정도 웹의 사상등을 이해하고 있다고 생각하던 구글이나 트위터가 이런 선택을 했다는 것은 약간 실망스러운 부분입니다.


[참고 글]
Thoughts on the Hashbang
Breaking the Web with hash-bangs
Broken Links
Hash, Bang, Wallop.


My Comment..
지금은 해당 이슈가 지속적으로 거론 될 시점은 아니지만, 해시뱅이란 것이 있었구나 하면서 글을 가져왔다.. 단어 자체도 생소하지만, 내가 사이트를 많이 보고 그런것도 아니고 트위터나 구글을 잘 사용 안하다보니 해당 url 패턴을 더더욱 몰랐던 것 같다.. 흠.. 저런 일이 있었다니..

[Book] 번역의 탄생..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

번역의 탄생 - 10점
이희재 지음
교양인

개발을 하다보니 원서나 영문문서를 봐야할 일이 많고 영어가 짧다보니 읽는것 만으로는 잘 이해가 안되서 중요하다 싶은 문서는 번역을 하면서 보고 그걸 블로그에 올리다 보니 번역에 대한 관심이 많아졌습니다. IT서적은 아니지만 읽은 동기가 개발과 관련이 있기 때문에 이 곳에 올립니다.

일단 영어가 짧기 때문에 원문의 의미를 제대로 이해하기 어려운 경우도 많이 있기는 하지만 이건 이해를 못하면 번역자체가 불가능하니 넘어가더라도 한국말로 번역을 하는 건 그 이상으로 어려운  일이었습니다. 내용을 이해했다고 하더라도 번역은 또 새로운 작업이었고(번역서를 내는게 아닐지라도) 왜 번역은 한국말 실력이 중요하다는 것인지 어느정도 이해가 되었습니다.

적절한 한국말로 바꾸는 것도 어려웠지만 무엇보다 신경쓰였던 건 오랜 주입식 영어교육으로 인하여 영어문체의 한국말도 너무나 익숙해져서 어느게 맞는 한국말인지 잘 감이 안오는 부분이었습니다. 예를 들면 한국말에는 없었던 과거분사같은 "했다"가 아닌 "했었다"나 "했었었다"같은 시제나 수동태같은 느낌의 번역문들은 어려서부터 영어공부를 할때 너무나 많이 사용했기 때문에 이미 상당히 자연스러워 져서 괜찮은 번역문인지 감을 잡기가 어려웠습니다.

주위에서 추천을 받아서 읽게 되었는데 이 책은 너무나 좋은 책이었고 번역에 대한 생각이 있다면 한두번쯤은 꼭 읽어보아야 할 책이라고 생각합니다. 단순히 번역에 대한 테크닉 뿐만 아니라 이 책의 저자는 한국어에 대한 애착을 갖고 있어서 한국어 답지 않은 문체나 표현에 대한 가이드도 절적히 해주고 있으며 번역할때 한국어에 대한 어떤 마음가짐을 가져야 하는지까지 설명해 주고 있습니다. 책을 읽는 내내 저자가 한국어에 대해서 번역에 대해서 얼마나 많은 고민의 시간을 가지고 제대로 이해하려고 노력했는지 알 수 있었습니다.

이 책에서는 직역과 의역을 들이밀기와 길들이기라는 단어로 표현을 하고 있습니다. 국내에서는 들이밀기 즉 직역을 하는 전통이 아주 강한데 저자는 특별한 이유가 있는 것이 아니라면 길들이기 즉 의역을 해야한다는 입장에 있고 저도 상당히 공감하는 부분입니다. 물론 이 책에서는 다양한 번역을 이야기 하고 있기 때문에 어린이를 위한 책이나 소설들에 대한 얘기도 많이 나오지만 제가 보는 책이나 문서는 거의 다 기술서이기 때문에 일부는 가려읽어야 될 부분도 있지만 전체적으로 의역을 해야하는 부분에는 크게 동감하고 있습니다.

이 책에는 번역을 자연스럽게 할 수 있는 많은 기법들을 아래와 같이 제시하고 있습니다.

  • 영어는 명사가 한국어보다 훨씬 많아서 그대로 직역하면 글이 어려워집니다.
  • 영어명사에 동사를 덧붙히면 글이 쉬워집니다.
  • 명사는 동사로 바꾸고 형용사는 부사로 바꿉니다.
  • 지시 대상이 모호해질것 같으면 대명사를 명사로 바꾸고 불필요한 대명사는 제거합니다.
  • 한국어는 주어가 약하므로 번역할때 주어를 빼고 접속사를 사용하면 좋습니다.
  • 사물이나 관념이 주어일 때는 이유를 나타내는 부사어나 사람주어로 바꾸면 좋습니다.
  • 수동태는 능동태로 바꾸는 것이 좋습니다.
  • 사물의 시각을 사람의 시각으로 바꾸면 좋습니다.
  • "의"가 들어간 소유격을 주어를 이용하면 자연스러워집니다.
  • 행위주체인 사람이 안나올때 사람을 드러내면 좋습니다.
  • 사역동사는 "~게하다"로 나타낼수 있지만 "~시키다"라고 할 수도 있습니다.
  • 현재 한국어는 "~되다"라는 표현을 남용하고 있습니다.
  • 사물이 주어로 오는 타동사 문장은 사람이 주어로 오는 자동사 문장으로 바꿉니다.
  • 포괄적인 뜻의 영어 부사는 구체적인 뜻의 한국어 부사로 옮깁니다.
  • 영어동사는 한국어 동사에 부사를 덧붙여서 번역합니다.
  • "형용사+명사"는 명사를 작은 주어로 삼고 형용사를 작은 서술어로 나타냅니다.
  • "~적"이라는 표현이 너무 많이 들어가면 딱딱해지므로 "~롭다", "~답다"같은 접미사를 씁니다.
  • "명사 of 명사"같은 둘째 명사에 은/는을 붙여 주제어로 삼고 첫째 명사를 주어로 삼거나 뒤의 명사를 주어로 삼고 앞의 명사는 술어로 옮기면 자연스럽습니다.
  • 복수를 나타내는 '들'은 빼는 것이 자연스럽습니다.
  • "~고 있다", "~어 있다.", "~에 관한"은 남발하면 지저분해 집니다.
  • 전치사가 들어간 영어문장은 동사를 붙여주면 자연스럽습니다.
  • 부정문은 긍정문으로 옮기면 더 자연스러울 수 있습니다.
  • 한국어는 결과를 말하고 이유를 나중에 말하는 것이 안정적입니다.
물론 이는 한번에 다 익힐 수 있는 것은 아니고 계속적으로 수련해 나가야 겠지만 사실 책을 한번 읽은 것 만으로도 어떤 번역이 자연스러운지 직역으로 해서 너무나 어색하고 딱딱한 문장을 어떻게 하면 자연스럽게 바꿀 수 있는지에 대한 감 정도는 온 것 같습니다. 계속 참고한다면 훨씬 자연스러운 번역문을 만들 수 있을 정도로 참 좋은 책이라고 생각합니다.

My Comment..
내가 번역을 한다거나 관심이 있는 것은 아니지만, 이렇게 가이드 책이 있을 거라곤 생각 못했다.. 막연하게 생각해보면, 영어 잘하는 사람이나 할 수 있는게 번역이라고 생각을 했으니.. 지금의 나에게는 번역이라는 것이 가당치도 않은 상황이지만, 이러한 가이드성의 책에 대한 포스팅은 나중에 도움이 될 수도 있기에 항상 갖고 오게 된다..