드디어 Structure and Interpretation of Computer Programs 번역서 출간되는군요.

후후후.

기다리고 있었습니다.

정식 판매 시작하면 바로 학교 도서관에 구입 신청해야겠네요. +_+

Dreaming in Code 영어 책으로 사서 이미 다 읽었는데 왠지 손해본 느낌이에요. 흑흑. (책은 좋습니다.)

번역본 관련 링크 부탁합니다. 강컴 어디에 있는거죠? 음 제가 잘 못찾는건가 ...

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

번역이 별로인가요?
괜히 샀나? Orz.
책으로 가지고 있는 것은 first edition이라... second edition을 원서로 또 살까 고민하다가 second edition 번역서 나온다고 해서 주문했는데...

소프트웨어 개발에서 소스를 오픈해서 참여를 유도하는 방법을 번역쪽에서도 좀 배울 때가 되지 않았나 싶습니다.

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

SICP 번역 초기에 참여를 했었습니다. 물론 지금 제 이름은 들어가 있지 않습니다.
제가 번역한 부분도 시간에 비해 얼마안되고 수준도 낮았기에 포기하고 다른 분들이 처음부터 하셨죠.
번역하신 김재우님을 잘 알기 때문에 번역에 대해서 몇가지 말씀드리고자 합니다.
일단 SICP에 대해서 잠깐 소개를 하자면, MIT에서 1~2학년을 대상으로 한 교육과정에서 쓰는 교재입니다. 즉, 이 책은 프로그래밍을 모르는 사람들을 위해 만들어졌습니다.
현재 프로그래밍을 많이 해오신 분들은 이 책의 번역이 이상하다 생각할지 모르겠습니다. 하지만 프로그래밍을 모르는 후배들이나 학생들에게 처음부터 프로그래밍을 가르쳐본 분들은, 사람들이 용어에서 얼마나 당황스러워 하는지 아시리라 생각합니다. "추상"이나 "재귀"와 같은 표현은 정상적인(프로그래밍과는 관계 없는) 교육만 받고 자란 분들이라면 쉽게 이해하기 힘든 말입니다.
김재우님과 감수를 맏으신 이광근 교수님은 10년이상을 학생이나 일반인들을 가르치면서 이런 문제에 대해서 고민을 하셨던 분들입니다.
책에서 쓰고 있는 익숙하지 않은 단어 중 실제로 수학계/물리학계에서 쓰고 있는 단어의 경우, 학계에서 권장하는 순우리말 표현으로 가져와서 쓴 것으로 알고 있습니다. 그 외, 프로그래밍과 관련된 단어의 경우 실제 영어의 원뜻과 우리말의 원뜻을 비교해서 밀접하게 가까운 말로 재정의한 것이 대부분입니다. 우리가 쓰고 있는 object 즉, "객체"라는 것은 순 우리말의 입장에서 보면 "주체"의 반대말에 가깝습니다. 즉 기준이 되는 주체가 있고 주체의 작용 대상을 객체라 부릅니다. 때문에 객체라는 번역은 뜻으로 비교한다면 잘못된 번역이 맞습니다. 그래서 object의 번역에 대해서 "개체"등의 대안이 떠오른 적도 있는 것으로 기억합니다. object는 영어를 쓰는 나라에서는 5살짜리 아이도 알아듣는 단어입니다. 하지만 우리말로 "객체"라 바꾸면 영어를 배운 사람도 쉽게 못알아듣는 말이 되고 맙니다. 우리말로 굳이 따지자면 거시기, 어떤 것, 그거 등으로 표현되는 너무나도 쉬운 말입니다. 그렇다고 이렇게 적을 수는 없기에 적당한 명사를 찾다보니 "물체"라는 단어가 그나마 object의 원 뜻에 가장 가까운 말로 선택되었습니다. 프로그래밍을 하면서 굳이 어려운 말을 배워가면서 프로그래밍을 배울 이유는 없지 않을까요?
그 외의 단어도 거의 유사한 뜻에서 고쳐졌습니다. 만약에 도저히 우리말과 같은 의미를 찾을 수 없다면, 기존의 용어를 그대로 쓰거나 원어 그대로를 적은 것으로 알고 있습니다. 저 또한 이렇까지 고심해서 번역했다고 이것이 "최상"의 번역이라 생각하지 않습니다. 하지만 이 책을 처음으로 보게될 분들이 프로그래밍을 아예 모르는 분들이라고 가정했을 때, 또한 SICP의 대상이 역시 같다는 것을 생각했을 때, 알 수 없는 은어만이 가득한 소프트웨어 업계의 용어보다는 조금이나마 쉽게 알아들을 수 있지 않을까 생각합니다.
김재우님과 이광근 교수님은 기존의 프로그래밍을 하던 분들, 즉 여러분이 지금 보이는 반응을 이미 예상했습니다. 그리고 한편으로는 비난도 많이 들을 것을 각오하신 것으로 알고 있습니다. 20~30년동안 프로그래밍을 하셨고 아직까지 하고 계신분들이 여러분이 쓰고 있는 단어를 모르시지 않습니다. 그 분들도 잘난 척하려면 여러분들이 듣지도 못한 전문용어를 써가면서 설명하실 수 있습니다. 만약에 그렇게 하셨다면 번역기간이 몇년이 걸리는 것이 아니라 몇개월 정도로 줄일 수도 있었을테고, 출판사 분들이 발을 동동구르지는 않으셨겠지요. 그 분들이 이렇게 욕먹을 각오를 하고 적은 것은 지금 프로그래밍을 배웠다고 (프로그래밍을 모르는) 사람들이 알지도 못하는 용어가 입에 달린 기존의 프로그래머가 아니라, 소프트웨어에 대해서는 아무것도 모르지만 프로그래밍을 진심으로 배우고 싶어하는 분들을 위해서입니다.
개인적으로 수년전에 이 번역에 참여하면서 익숙하지 않은 용어때문에 초기에 약간의 트러블이 있었습니다. 하지만 지금에 와서는 누구보다도 열렬한 추종자가 되어버렸네요. 그 때는 그 분들의 뜻이 너무나도 높은 곳에 있기에 저같은 소인배가 겉만 보고 말았던 것이죠.
제가 이렇게 길게 적었지만, 이 글을 보고 여러분들의 생각이 저와 같아 지리라 생각하기는 힘들 것 같습니다. 또, 이렇게 힘들게 번역한 것이, 힘이 빠지게도, 훗날에는 언급하신 "그 책"과 같은 평가를 받을지도 모르겠습니다.
하지만 이 분들이 자신들에게 편한 용어를 버리고, 비난까지 감수해가면서, 굳이 어려운 길로 간 것을 "프로그래밍을 모르는 사람이 대충대충 쉽게쉽게 번역했다"라고 감정적으로 생각하지는 말아주시기 바랍니다.
그 이외의 번역에 대한 불만이나 오역의 가능성이 있는 것은 김재우님과 연락하시거나 이광근교수님의 홈페이지에서 이야기를 나누는 것이 어떨까 합니다.
이광근 교수님의 홈페이지에 가시면(http://ropas.snu.ac.kr/~kwang/#industrialize) "우리분야의 한글 용어"라는 ppt 자료가 있습니다. 한글 번역에 정말 관심이 있으시다면 한번 읽어보시기를 권합니다.
역시 이광근 교수님의 번역에 대한 자유게시판(http://ropas.snu.ac.kr/lib/term/bbs/zboard.php?id=term&page=1)에 가시면 우리말로 어떻게 번역할지에 대해서 대화를 나누고 있습니다. 여기에서 의견을 올리시면 좋을 것 같습니다.
김재우 교수님과 이광근 교수님은 각각 동명정보대학교와 서울대학교에서 재직중이십니다. 개인적인 연락은 학교 홈페이지를 통해서 연락드리는 것이 좋을 것 같습니다.
추가> 그 분들에게 연락하시는 것이 부담스러우시다면 번역에 대해서 저와 같이 이 글타래나 아니면 이메일을 통해서 이야기를 해보는 것도 좋을 것 같습니다. 제가 그 분들에 비해서는 어쩡쩡하지만 아는 부분에 대해서는 여러분들과 진심으로 토론해볼 생각이 있으니까요.
------------------------------
How many legs does a dog have?

일반인, 신입생이 쉽다고 느낀다면 기존의 프로그래머에게도 쉬울 수 있다는 말입니다. 단지 익숙하지 않아서 그냥 싫을지는 몰라도요.
SICP를 배우는 사람이 기존의 전문가(?)에게 뭔가를 물었을 때, 용어에 대해서 익숙치 않다는 이유만으로 비난만 하지 않는 다면 배우는 사람도 별 불만이 없을거라 생각합니다.
아... 물론 이렇게 된 번역이 일반인, 신입생에게 정말 쉽다면 말이지요. 이건 시간이 지나고 평가가 들려야 아는 것이기때문에 지금 단계에서 쉽다 안쉽다를 굳이 따지고 싶지는 않습니다. 쉽다고 생각해서 만들었는데 물론 아닐 수도 있습니다. 어쨌든, 초보자에게 쉬운 용어가 전문가들이 쓰기에도 당연히 쉽다는 생각이 틀리지는 않다고 생각되는데요. 저만의 생각인가요?

또한 SICP의 내용의 수준은 상당히 높습니다. 실제로 우리나라에서 왠만큼 공부하지 않았다면, 설령 열심히 공부했다고 하더라도 결코 쉬운 내용은 아닙니다. 괜히 SICP에 대응하는 HTDP같은 책이 나온게 아닙니다. 왠간한 미국사람들도 SICP는 MIT 다니는 공부벌레나 보는 책이라고 했을 정도니까요. 하지만 그렇다고 SICP의 대상이 전문가인건 분명 아닙니다.
실제로 MIT에서 그렇게 교육을 하고 있고(시간이 흘러 제가 알고있는 것고 달라지지 않았다면), 일반인을 대상으로하는 강좌도 많이 열려있습니다. 수준의 차이는 있지만 SICP나 HTDP가 추구하는 방향은 컴퓨터를 쓰는 모든 사람이 프로그래밍 언어를 쓸 줄 알아야 한다는 공통적인 기초에서 출발합니다. 왜 이런 주장을 하는지는 HTDP의 서문(http://www.htdp.org/2003-09-26/Book/curriculum-Z-H-2.html)에서 Why Everyone Should Learn to Program 항목을 참고하시기 바랍니다.

SICP가 명저로 대우받는 이유는 초보자를 대상으로 시작하지만, 그 안에 컴퓨터 공학 또는 과학, 심지어는 전자나 전기공학에서 배워야하는 중요한 지식 대부분이 다 스며들어가 있기 때문입니다. 특히 연습문제 하나하나가 대단한 수준의 고민까지 담고있습니다. 하지만 지나치게 많고 어려운 내용이기때문에 책을 만든 서스만 부부도 고민을 했는지, 일반적인 전문서적과는 다르게 아주 쉬운 영어로 풀이해서 적어놨습니다. 원문을 읽어보시면 내용이 결코 딱딱하지 않고, 단어의 수준도 그다지 높지 않다는 걸 알게됩니다. 하지만 아이러니하게도 쉽게 풀어놓은 영어를 그냥 번역해놓으면 도저히 알아볼 수가 없는 말이 됩니다. 수많은 비유가 나타나고, 앞의 말을 꾸미는 구나 절이 반복되기 때문에 보통의 전공서적 번역과는 천양지차가 날 정도로 어렵습니다. 굳이 따지자면 그냥 보통 번역하듯이 해버리면, 반지의 제왕을 번역했는데 원래의 느낌이 안나는 것처럼 보인다고 할까요? 소프트웨어쪽에서도 난다 긴다하는 분들이 몇년을 소모한 번역입니다.

번역서가 정말 마음에 안드신다면 (제발) 원문이라도 보시기 바랍니다. 정말 원서를 보시고 단 한줄이라도 더 좋은 번역을 할 수 있다고 생각하면, (제발) 그렇게 해주셔서 공유해 주시기 바랍니다. 번역에 참여했던 저나 김재우님이나 다른 분들이 그저 인지값이나 벌려고 이 책을 번역하기 시작했던 것이 아닙니다. 저희 스스로가 원서를 보면서 너무나도 답답했기에 벌린 일일뿐입니다. 그냥 마음에 안든다, 나는 그냥 싫다, 이러이러한 점이 싫다라는 의견은 저 또한 한 명의 개인으로 가져보았기에, 여러분들 또한 가질 수 있는 생각이라 인정합니다. 하지만 여기에 대해서 말이 오고간다면 저만의 바램이기는 하지만 좀 더 좋은 대안을 가지고 건설적인 방향으로 대화가 진행되었으면 합니다. 딱히 더 좋은 대안이 없다고 생각하신다면 한번 더 이해해 보거나 조금 색다른 방향이라도 제안을 해주시면, 나중에는 SICP를 온국민이 누구나 쉽게 볼 수 있는 책으로 만들어 볼 수 있는 날이 올지도 모른다는 생각이 드네요.

글을 적고보니 앞의 글이나 지금의 글도 제가 너무 흥분했다는 생각이 듭니다. 장황하게 적은것도, 그저 조금만 더 열린 생각으로 봐 주십사하는 바램이고, 자신을 위해서가 아니라 다른 대부분의 사람들을 위해서 어떻게 번역하는 것이 좋을까, 한번 더 생각해주셨으면 하는 바램인걸요. 이런 책이 그저 오해나 편견에 뭍혀버리지를 않기를 간절히 바랄 뿐입니다.

추가로, 개인적으로 잘 아는 사이지만 책 한권도 공짜로 받지 못했습니다. 저한테 인지값에서 1원도 떨어지지 않기때문에 장사를 하려고 이런 글을 적는 것도 아닙니다. 혹여나 오해하지 마시길 바랍니다.
------------------------------
How many legs does a dog have?

Lisp을 써보신 적있으신가요? 또는 Smalltalk를 써보신 적 있으신가요? 둘다 까마득한 과거에 만들어져서 아직까지 스스로 살아남거나 또는 다른 언어에 모태가 되어서 내려온 언어죠. 제가 맨처음에 C를 먼저 접하고 근 10년이 지나도록 저 두가지 언어를 한번도 써보지 않았다는게, 나중이 되어서는 너무나도 (절망에 가까울 정도로) 아쉬웠습니다.
C에서 C++/Java로 옮겨가면서 OOP를 이해하려고 발버둥친 몇년의 기간은, 사실 Smalltalk를 단 몇 개월이라도 써봤다면 없었던 일이었을 겝니다. 또한 (프로그래밍 언어 수준의) 설계가 뭐니 추상이 뭐니 이해하려고 발버둥친 몇년의 기간도 Lisp을 몇 개월이라도 써봤다면 없었던 일이 되었을텐데요. SICP 또한 그렇습니다.
SICP를 진정으로 다 보고 이해를 했다면, 그 사람은 어디에 가도 어떤 언어로든 프로그래밍을 할 수 있을거라 자신합니다. 나름대로 잘난 맛에 살고 자만심에 가득차 있는 저인데도, SICP에 있는 연습문제도 제대로 풀지 못하는 경우가 허다합니다.
이미 다른 언어를 배웠다면 또다른 언어의 문법 배우는데 몇일, 길어도 몇주면 되지 않나요?
어쩌면 위의 분은 지금 너무나도 실력이 좋으시고, 예전에 이미 그런 좌절을 겪으시고 그런 말씀을 하시는 건지는 모르겠습니다.
스스로 프로그래밍 고수다라고 말할 수 없는 저의 입장에서 생각이긴 하지만, SICP를 봤다고 좌절을 느끼리라 생각되지는 않습니다. 나중에 엄청난 도움이 되면 도움이 될지언정 말이죠.
------------------------------
How many legs does a dog have?

곰곰히 생각해 보면서 이광근 교수님의 전공분야를 살펴 보니, abstraction을 abstract로 번역한 것은 깊이 있는 프로그래밍 언어 전문가의 내공에서 나온 적절한 해석입니다. 제 짐작으로는 아마 초벌 번역에서는 abstraction을 "추상"이라고 했다가 이광근 교수님이나 혹은 다른 프로그래밍 언어 연구자들의 조언에 따라 "요약"이라는 더 올바른 번역으로 개선했다고 봅니다.

생각해 보니 이광근 교수님의 전문 분야가 abstract interpretation입니다. 여기서 abstract interpretation은 말 그대로 "요약 해석"이죠. 예를 들면 {...,-2,-1,0,1,2,3,...} 와 같은 정수를 {음수,0,양수}로 요약한다든지 {짝수,홀수}로 요약한다든지 해서 프로그램 결과의 어림값을 예상해 보는 이런 것을 "요약 해석"(abstract interpretation)이라고 합니다. 요약 해석은 model checking 등의 프로그래밍 분석 분야에 응용되고 있습니다.

다음과 같은 일련의 식을 생각해 봅시다.
{...,-1+1,-2+1,0+1,1+1,2+1,3+1,4+1,5+1,(1-3)+1,e+1,pi+1,(pi/2)+1,...}
자 위 식들을 어떻게 요약할 수 있을까요?
예, 그렇습니다. 바로 다음과 같이 조건제시법으로 요약해서 똑같은 집합을 나타낼 수 있습니다.
{ e' | (\ x . x + 1) e --beta_n--> e' where e is any expression }
(위에서 \ 는 람다를, --beta_n--> 은 1 step normal order bet reduction 을 뜻함)
\ x. x + 1 이라는 람다 식은 어떤 임의의 식을 주면 그 임의의 식에 더하기 1을 하는 형태의 식을 만들어 낼 수 있는 일종의 요약된 표현이죠.

논리학에서 람다 셈법(lambda calculus)이 나온 맥락을 생각해 보면 위와 같이 식을 요약할 수 있기 때문에 람다로 함수를 만드는 것을 abstract(요약)한다는 의미에서 abstraction이라고 불렀라고 생각합니다. 보다 정확한 것은 수리논리학이나 현대논리학 혹은 프로그래밍 언어 기초 분야를 연구하시는 전문가에게 자문을 해 보아야 하겠으나, 제 짧은 지식과 기억으로도 람다 식이 여러 식을 요약하는 데 쓰인다는 것을 기억해 낼 수 있었씁니다. 전산학과의 프로그래밍 언어 과목이나 수학과 혹은 철학과의 현대논리학 등의 과목에서 람다 셈법에 대해 공부해 보신 분들이라면 위의 예를 보시고 abstraction을 요약이라고 해석한 것은 참으로 올바른 해석이라고 무릎을 탁 치시리라 생각합니다.

제가 역자들의 깊은 뜻을 이해하지 못하고, 순간적으로 abstract와 abstraction은 다르다고 한 말에 귀가 얇아저서, 깊이 있는 번역을 문제가 있다고 짧은 생각으로 함부로 판단한 것 죄송합니다. semmal 님께서는 아래에 요약이 번역이 이상하다고 제가 맞장구친 것은 잊어버리시고 이광근 교수님과 김재우 교수님께 정말로 좋은 단어를 선택했다고 전해 드리기 바랍니다.

@ 그럼 여러분들께서도 프로그래밍 언어 연구자의 깊이 있는 시각에서 나온 번역을 단지 영한사전 번역에 나오지 않는다는 이유로 잘못된 것이라 저처럼 넘겨짚는 우를 더 이상 범하는 분이 없기를 바랍니다. 무식하면 용감하다, 서울에 안 가 본 사람이 서울을 제일 잘 안다고 큰소리친다 뭐 이런 옛말이 떠오르는군요 ㅠ.ㅜ

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

'object는 object지 왜 객체인지 물체인지를 따져야 하나?'
이런 생각을 하다가 문득 제가
원서로 이해하고 원어로 대화하는게 제일 좋다고 생각하는
편견을 가지고 있다는걸 느꼈습니다.

저조차도 신입생때 전공 입문을 한글로 배웠으면서
지금 좀 배웠다고 원어로만 생각했네요..

실생활에서 객체라는 말을 쓸때가 있나 생각해봅니다.
우리는 implementation을 구현이라고 생각하는데
원래는 실행/완성 이라는 말이 더 맞지요.
공대나 이과대에서는 아직도 예전 일본식 한자로 된 표현이 많습니다.

물론 너무 오래되서 거의 공학용어처럼 되서
적응이 안되고 혼돈되지만
이런 잘못된 표현들이 바로잡아지면 장기적으로는 더 좋겠지요.

application program이 응용 프로그램일까요 이용 프로그램이 맞을까요?
사용자가 이용하는 프로그램이니까 이용프로그램이 맞는것 같은데
응용 프로그램이라고 말을 해야 어플리케이션이라고 연상이 되네요.
응용이라면 뭔가를 활용해서 다른 일을 한다는 건데
응용 프로그램이라면 오히려 개발 툴을 활용해서 프로그램을 만드니까 헷갈리네요.
응용 프로그램이 사용자가 응용해서 자기 실생활에 활용한다는 것도 되니까 맞기도 한것 같구요.

지금의 컴퓨터 용어에 대해 논란이 많으니
이런 토론도 생기는것 같습니다.
장기적으로 많은 분들이 계속 노력하면 정립이 되겠지요.

----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.