Parece mentira

Parece mentira.

Parece mentira.


Parece mentira.


Parece mentira.


Y

Es mentira.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2012/05/20 01:30 2012/05/20 01:30
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/39

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

프리랜서로 IT 번역을 한다는 건

프리랜서로 IT 번역을 하는 건 별로 추천할 만한 일이 아니다.

일단 급여가 불규칙적이다.

보통 출판사들은 번역이 끝나고 돈을 주는데

(어떤 출판사는 책이 나온 후 주기도 한다)

보통 500페이지 책 한 권을 번역하는 데 드는 시간 등을 감안하면

매달 급여를 받는 게 현실적으로 어렵다.

두 번째로 매번 새로운 번역을 해야 한다.

예를 들어 한 번은 안드로이드 게임 개발 책을 번역했다

다음 번엔 아이폰 책을 번역하는 식이다.

그러다 보면 책 사이의 연계성도 떨어지고 그만큼 작업이 고되다.

세 번째로 한국 독자들은 그다지 우호적이지 않다.

예를 들어 나는 '역자도 공범이다'라는 소리까지 들어봤다.

내가 무슨 범죄자도 아닌데, 공범 취급을 받다니..

책을 잘 번역해도 잘 해야 본전이다.

별점을 좋게 주거나 좋은 독자평을 써주는 독자는 솔직히 별로 없다.

네 번째로 말 그대로 비정규직이다.

IT 번역 프리랜서로 생계를 유지할 수 있을까? 전세 대출을 받을 수 있을까?

글쎄...간단히 말해 월급이 매달 들어오지 않으면 은행 대출은 사실상 어렵다.

그럼 캐피탈 대출은? 그것도 6개월 정도 급여가 규칙적으로 들어와야 하는데

이것 자체가 아주 어렵다. 그 다음은 상상에 맡기겠다.

다섯 번째 이유는 독자들의 오해와 관련이 있다.

많은 독자들이 역자가 많은 돈을 받거나 책이 팔리는 만큼 돈을 받는다고 오해한다.

절대 그렇지 않다. 일단 책이 팔리는 만큼 돈을 받으려면 인세 계약을 해야 하는데

그런 계약을 하는 출판사는 거의 없다. 혹시 있다 해도 번역비 없이 인쇄 부수가 아니라

책이 팔리는 양에 따라 인세를 받게 될 테고, 요즘 IT 전문서 시장을 보면 차라리

번역비를 받는 게 나을 정도의 인세를 받게 될 것이다. 또 번역비는 장당 7,000원 ~ 10,000원이

업계 표준이다. 한 달 동안 500페이지 번역해도 350 ~ 500 정도 받는 거다. 그것도 세금 3.3%

떼고, 5월엔 종합 소득세도 뗀다. 이런 상황에서 매달 생활을 하려면 매달 새 책을 쉬지 않고

번역해야 하고, 그 와중에 독자들은 가끔씩 질문을 남기고, 개발 환경은 바뀌고, 책의 일부 내용은

더 이상 실행이 안 되기도 하고.. 이런 일들이 일어난다. 물론 독자들 입장에서야 책을 샀는데

제대로 안 되니 질문을 남길 수 있다. 그렇지만 역자 입장에서는 매번 몇 개월 전에 번역한 내용을

유지보수하기가 어려운 게 현실이다.


그래서 결론적으로

1. 우리나라 IT 전문서 독자들이 앞으로도 좋은 IT 전문서가 나오기를 바란다면 좀 더 관용적인

시선으로 IT 전문 번역서를 봐줬으면 좋겠다. 다른 사람 책 빌려보지 말고 커피 마실 돈으로

책 한 권씩 사주면 결국 그 혜택이 본인들에게 돌아갈 것이다.

2. IT 전문서 프리랜서로 일한다는  건 앞의 다섯 가지 이유를 다 듣고도

'이 정도면 할 만하겠네' 하는 생각이 드는 사람만 하면 좋겠다.

웬만해서는 말리고 싶다. 이건.. 내가 경쟁자(?)를 물리치고 이 시장을 독점하기 위해서

하는 얘기가 아니고, 그냥 진심으로 하는 얘기다.

3. 그럼 IT 전문서는 누가 다 번역해야 하나? 내 생각엔 전문 개발자가 하는 게 제일 좋다.

안드로이드 책은 안드로이드 개발자가, 유니티 책은 유니티 개발자가 하는 게 제일 좋다.

어색한 한국어나 불필요한 피동문은 편집자가 잘 수정해주면 된다. 이 경우 문제점은

개발자들이 일정에 쫓겨 번역이 제 때 끝나지 않을 수 있다는 점인데

이건 출판사가 적당히 개발자를 압박하면 되지 않을까 싶다.

4. 무엇보다도 한국 IT 개발자들이 번역서보다 빠르게 개발서를 내놓는 게 더 좋다.

그럼 외국에 로얄티를 지불할 필요도 없고 어색한 문장도 (비교적) 없을 것이다.



이 글은 계정이 만료될 때까지만 보관하겠다.

-끝-
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2012/05/19 13:21 2012/05/19 13:21
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/38

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

안드로이드와 아이폰 SDK에 대한 결론

1. 애플은 사용자 경험뿐 아니라 개발자 경험까지 고려해 API를 만들었다.

그에 반해 안드로이드는 개발자 경험은 전혀 별로 고려하지 않았고

사용자 경험마저 살리기 어렵게 만들었다.

2. 애플 SDK에서 스택 구조가 직관적이기는 하지만 좀 더 고수준으로 끌어올렸더라면

어떨가 하는 생각을 한다. 그에 반해 안드로이드의 인텐트와 액티비티는

uni-tasking을 프로그래밍적으로 잘 정의한 백미라 할 수 있다.

3. 전반적으로 안드로이드 프로그래밍은 파편화의 연속이다. 따라서 안드로이드 프로그래밍을

할 때는 기본 프로그래밍 요소 외에 파편화에 따른 예외 처리 및 코드 분기가 꼭 필요하다.

4. 안드로이드 구 버전 API도 좀 더 고수준으로 만들어준다면 어떨까 하는 생각을 한다.

아니면 새로운 API에서 하위 버전 호환성을 최대한 지원한다면 개발하기가 한결 쉬울 것 같다.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/05/25 01:17 2011/05/25 01:17
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/33

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

세상에는

스프링을 아는 개발자와

모르는 개발자가 있다.

스프링을 아는 개발자는 행복한 거고

모르는 개발자는 조금 불행한 거다.

-끝-
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/23 04:18 2011/04/23 04:18
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/29

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

adios는 아무 때나 쓰지 말자ㅠ

요즘 개콘을 보면

마지막 봉숭아 학당 끝날 때

adios라고 한다.

그런데 이건 잘못된 표현이다.

adios는 a (to) + dios (신)이란 뜻으로

프랑스어의 adieu와 어원적으로나 의미적으로 같으며

'영원한 안녕'이란 뜻이다.

따라서 adios라고 하면

적어도 살아 생전에는 다시 보면 안 된다.

개콘처럼 매주 다시 볼 거면

스페인어로는 hasta luego나 hasta la proxima semana(또는 vez)라고 해야 한다.

아니면 프랑스어로는 Au revoir라든가 A bientot라고 하든가.

여튼 adios는 아니다ㅠ

크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/22 22:30 2011/04/22 22:30
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/27

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

기본적인 웹 보안

이게 전부는 아닐지언정

이 정도는 해야 제대로 된 거 아닌가 싶다.

1. 비밀번호/개인 정보 암호화

당연하다. 그런데 너무 안 지킨다. 최근 일어난 일련의 보안 침해 사례를 가만히 보면서

'과연 비밀번호를 암호화했을까?' 하는 고민에 빠졌다.

이에 대해서는 내가 내부 개발자도 아니고 공식적인 입장을 들은 바도 없으므로

그냥 '과연? 과연?'이라고 추측만 할 뿐이지만

만약 비밀번호나 개인 정보를 암호화하지 않았다면

정말 안타까운 일이 아닐 수 없다.

물론 가만히 있는 사이트를 먼저 침해한 해커가 나쁘다.

그런데 웹 사이트도 만일의 사태에 항상 대비할 책임은 있다.

기본적인 비밀번호, 개인 정보까지 암호화를 하지 않았다면

정말 유감이다.

2. 비밀번호 솔트

이건 선택 항목이지만 필수처럼 생각하고 꼭 적용하기를 바란다.

비밀번호 솔트를 적용하면 레인보우 테이블 같은 공격을 피할 수 있다.

예를 들어 해커가 충분히 많은 값을 입력해 레인보우 테이블 공격을 하면

비밀번호 암호화를 했다 하더라도 비밀번호를 역추적할 수 있다.

하지만 여기에 소금(salt)을 뿌려서 해커를 혼란케 하면

레인보우 테이블 공격조차도 무력화할 수 있다.

즉, 자동화된 프로세스만으로는 비밀번호를 알아내 사용자 계정에 침입하기가

몹시 어려워지는 것이다.

3. 보안 프로토콜의 사용

익명 접근이 가능한 곳에서는 http 프로토콜을 사용하더라도 상관없지만

일단 로그인한 후에는 https 프로토콜을 사용해 패킷을 암호화하는 게 좋다.

4.  사용자 크리덴셜 요청

사용자 인증 정보를 제공해 한번 로그인하면 쿠키가 만료될 때까지

자동 로그인을 지원하는 사이트라 하더라도

주요 개인 정보에 접근해야 할 때는 꼭 별도로 로그인을 거치게 하는 게 좋다.

예를 들어 온라인 쇼핑 사이트라면 카트에 담는 것까지는 익명으로 또는

자동 로그인 인증 정보를 바탕으로 얼마든지 지원할 수 있지만

실제 구매 시에는 항상 로그인을 명시적으로 요청하는 게 좋다. 이렇게 하지 않으면

중간자 공격 등을 통해 다른 사용자 계정에 침입한 해커가

사용자의 주요 개인 정보를 마음대로 사용해 이를테면

값 비싼 물품을 웹사이트에서 구매하거나

개인 정보를 빼갈 수 있다.

5. 웹 사이트의 권한 영역을 세분화한다

4번과도 일맥상통하는 얘기인데 이를테면 guest/user/purchaser/admin 등으로

웹 사이트의 권한 영역을 세분화하고 각 권한 역할에 따라 보안을 강화한다.

6. 기왕이면 보안 프레임워크를 활용한다.

보안 프레임워크를 활용하지 않으면 전체 사이트에 보안을 적용하기가 몹시 어렵다.

예를 들어 한 곳에는 보안을 제대로 적용했지만 다른 곳에서는 특정 보안 요소를 빼먹기 일쑤고

이를 검증하기도 쉽지 않으며, 더불어 똑같은 보안 요소를

적용하기 위한 코드를 반복적으로 적용(boilerplate 코드의 양산)해야 한다.

따라서 가능하다면 스프링 시큐리티 같은 프레임워크를 사용해 사이트 전체에 보안을

일관되게 적용하는 게 좋다.

7. 지금까지의 내용은 모두 내가 번역한 스프링 시큐리티 3 책 (위키북스)에 나오는 내용들이다.

-끝-
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/21 00:18 2011/04/21 00:18
, , , ,
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/23

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

감정 노동

가끔 난

번역이 감정 노동이 아닌가 싶다.

본래 번역을 끝내고 나면

다른 저자나 역자들이 그렇듯이

책을 다시 안 펼쳐보는 나로서는

어떤 책은 가끔...

이대로 보내버리기엔 너무 좋은데...

하고 나 혼자 계속 읽어버리는 경우가 있다.

하지만 헤어질 때를 알아야 하기에

가끔은 헤어지기 싫어도 책을 손에서 놓아야 한다...

지금도 2권의 책을

손에서 내려 놓으려 한다...

언젠가 또 만날 날이 있겠지+_+

Je me suis bien amusé! Au revoir et merci :)
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/20 21:47 2011/04/20 21:47
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/22

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

Gmail의 놀라운 사용성

오늘 외국 저자한테 메일을 보내는데

파일을 첨부한다고 하고는 깜박하고

 '첨부한 파일은(attached is the file...)' 하고 쓰고 나서

 전송을 누르는 순간!

 제명이 됐어요;;;

Did you mean to attach files?

You wrote "attached is" in your message, but there are no files attached.  

Send anyway?

이런 경고창이 뜬다+_+

보통 파일 첨부한다고 하고 깜박하기가 쉬운데

이런 상황을 고려해 gmail에서는 메일을 전송하기 전에

한 번 내용을 스캔하고 '파일 첨부한다고 했는데

첨부된 파일은 없네? 확실해? 이게 최선이야?' 하고 물어봐주네

완전 소름 돋넹ㅠㅠ
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/13 12:49 2011/04/13 12:49
, ,
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/20

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

멀리 보이는 에펠탑


사용자 삽입 이미지

빠리 어느메에선가...

우연히 2009년에 찍었던 사진을 보다가 얻어 걸린 사진

정확히 어디서 사진을 찍은 건지 잘 모르겠다.

빠리 도심에서는 어디서든 에펠탑을 볼 수 있다.

꼭 서울에서 63빌딩이나 남산 타워가 항상 보이는 것처럼 말이다.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/09 17:03 2011/04/09 17:03
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/17

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

Mont Saint Michel

사용자 삽입 이미지

몽셀 미셸 꼭대기에서...

꼭 카톨릭 신자가 아니더라도 (물론 난 카톨릭 신자는 아니다)

몽셍 미셸(Mont Saint Michel)은 프랑스를 잘 아는 사람이라면

꼭 한 번씩은 간다.

빠리에서 떼제베를 타고 두 시간을 가고, 다시 거기서 버스로 한 시간을 넘게 가야

도착할 수 있는 이곳은 말 그대로 바다 위에 세워진 수도원이다.

예전에 대학에서 프랑스어 문법을 배울 때 교재로 배운 책에서도

몽셍 미셸에 대한 얘기가 나온다.

당시 교수님도 꼭 한 번 방문하라고... 에펠탑에 비할 바가 아니라고 해서

나도 꽤 큰 기대를 했는데

보다 시피... 바다라기보다는 지금은 늪에 가깝다 ('수영하지 마시오'라는 안내 표지도 써 있다)

하지만... 나름 꽤 인상적인 추억을 많이 안겨준 곳이다ㅇㅇ



크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/09 14:51 2011/04/09 14:51
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/16

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다


블로그 이미지

- joshy21

Archives

Authors

  1. joshy21

Recent Trackbacks

Calendar

«   2012/05   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Site Stats

Total hits:
4279
Today:
2
Yesterday:
10