이런 책이 있으면 정말 좋겠다.

권순선의 이미지

오랜만에 서점에 갔었는데 그동안 참 많은 책이 나왔더군요. 컴퓨터 서적 분야도 예외가 아니어서 새로운 출판사도 많고, 새로 나온 책도 많았는데 정작 선뜻 손이 가는 책은 없더군요. 아마 서점에 가시면 모두들 비슷한 경험 한두번쯤은 가지고 계실텐데 각자의 입장에서(개발자/관리자/사용자....) "이런 책이 있었으면 좋겠다." 내지는 "이런 책은 없었으면 좋겠다." 하는 생각 역시 한두번쯤은 해봤을 것입니다.

만약 여러분이 컴퓨터에 관한 책을 쓰신다면 어떤 책을 쓰시겠습니까? 어떤 책이 나오기를 기다리고 계십니까? 아마 출판사 쪽에 계신 분들이 참 좋아할 만한 주제가 될듯 하군요. :-)

익명 사용자의 이미지

윈도 소스 프린트 하면 한 100권은 나오지 않을 까요

익명 사용자의 이미지

파일 포맷은 아래 사이트에 들어가면 대부분 구할 수 있지요.

http://www.wotsit.org

근데 상용 파일포맷들(*.hwp 등등...)은 안보이더군요.

익명 사용자의 이미지

자료구조 화일구조를 C#으로 저술한 책이 있었으면 좋겠네요
아직까지는 C가 대부분이고 C++로 쓰여진 책이 드물게 몇권 있지요.

익명 사용자의 이미지

솔직히.. 자료 구조 공부하는데 그냥 c 책 보시는게 좋을거 같네요

대부분의 c 소스 그냥 가져다 놔도 컴파일 될거 같은데 ^^

익명 사용자의 이미지

꿩대신 닭이라고..^^;
자바로는 DS책들이 많이 나오고 있습니다..
자바가 DS수업에서 상당히 좋은 언어이기 때문에..
요즘 대학에서도 DS수업을 자바로 대체해 나가고 있죠..
서점 가시면 자바로 쓰여진 DS책들을 많이 보실 수 있을 겁니다..
그중에서 Waite가 쓴 책이 좋은 평을 얻고 있더군요..

eric의 이미지

따악.. Design Patterns같은 책들이 나왔으면 좋겠네요..

익명 사용자의 이미지

UML for Java

익명 사용자의 이미지

저는 개인적으로 기업환경에서의(대규모사이트를 이야기함 : Active Directory Services 같은 ) 리눅스 서비스책이 나왔으면 합니다.
참고로 예전에 MCSE 공부을 할때 그들의 Window2000 서비스는 저로서는 아주 신성한 충격이었읍니다.

권순선의 이미지

아 저도 평소에 있었으면 좋겠다...라고 생각했던 책이 방금 떠올랐네요. 자유 소프트웨어/오픈소스 소프트웨어 개발과 운영 및 참여에 관한 자세한 책이 하나 있었으면 좋겠습니다.

개발자의 입장에서는 gcc를 비롯한 gdb, make, autoconf, automake등의 gnu툴의 사용 방법과 vi/emacs에디터를 프로그래머의 관점에서 설명하고,

프로젝트 운영자의 입장(대부분 개발자 본인이 운영자인 경우가 많겠지만 안그런 경우도 있죠.)에서는 프로젝트 운영을 어떻게 효과적으로 진행하고 좀더 많은 개발자들을 효율적으로 조율하며 홍보할 것인가에 관한 내용을 설명하고,

프로젝트 참여자의 입장에서는 이에 활용되는 여러 도구들(cvs, patch 등)을 사용하는 방법과 메일링 리스트나 웹보드 등을 통한 의사소통 방법을 자세히 설명한

그런 책이 하나쯤 있었으면 좋겠습니다. 시중에 나온 책들은 많지만 이런 부분들을 전체적으로 한권에 다루고 있는 책은 별로 없으며 프로젝트의 운영에 관한 내용을 다루고 있는 책은 더구나 거의 전무합니다. 원서들 역시 상황은 크게 다르지 않습니다. 지나치게 기술적이거나, 혹은 기술적인 내용은 전혀 없이 사회적/철학적인 내용만을 담고 있는 경우가 많죠. (적어도 제가 살펴본 바로는)

그리고 가장 중요한것....이런 책들의 내용이 GFDL이나 OPL등의 공개 라이센스 하에 배포되어 온라인 상에서 계속해서 갱신되고 내용이 추가되는 살아 있는 문서가 되었으면 좋겠습니다. 척박한 출판시장의 현실을 감안한다면 이건 쉽지 않겠지만요. :-)

수우_의 이미지

Open Source Howto -_-?

역시 필요하다고 느끼던 차에 순선님이 지적을 해주시는군요.
생각난 김에 필요한 하우투라도 주섬주섬 챙겨봐야겠네요 :)

익명 사용자의 이미지

흠.. 저도 어제 오늘 auto tools에 대한 책을 살까 어쩔까 고민인데
오렐리에도 그런 책은 없는 것 같더군요.
와우북에서 autoconf로 찾아보면 하나 있긴 한데 번역본이 나온 것도 아니고..
--
from [ke'izi] : where is [r]?

권순선의 이미지

익명 사용자의 이미지

동감합니다.

딱 순선님께서 말씀하신 내용을 가진 책이 한권정도 있었으면 하는 바램입니다.

혜진의 이미지

##### 출판사에 들어간지 며칠 지났습니다. ^^
.....퍼다가 두고두고 곰탕 우려먹고 싶은 기분.....^^ 농담이고요.
저는 개인적으로.......
적수보드부터 시작해서, 각종 프로젝트들......
사실, 참여하고 싶어도 "잘 모르니까" 부담스럽구.......
그래서, 그런 주제로 핸드북처럼
"적수보드 프로젝트"
"소리받아 프로젝트" 하는 식으로
각 프로젝트를 설명헤 주는
그래서 많~~~~은 사람들이 참가할 수 있는 계기를 만들어 주는......
그런 책이 나왔으면 좋겠는데.........

언.젠.가...... 만들어야죠. ^^ 지금이야..... 한달도 안 된, 신입......

박영록의 이미지

두고두고 본전 뽑는 책들..

Java Server Programming J2EE Edition, Wrox. 정보문화사
한글 리눅스 알짜 레드햇 5.2 바이블, 정보문화사
Beginning XML, Wrox. 정보문화사

제가 산 책 중에 저 세 권은 정말 두고두고 볼 만한 가치가 있는 것 같습니다. Wrox의 책은 사서 후회해본 적이 거의 없네요. 오라일리는 사고 나서 돈 아까워 눈물을 흘린 적이 많은데 ㅠ.ㅠ

기술을 설명하면서 풍부한 배경 지식과 이론적 설명을 담는 책이 좋습니다. 예제 코드는 적으면 적을수록 좋구요. 예제 코드는 적더라도 환경 설정에 대한 상세한 설명은 빠뜨리지 말았으면 좋겠습니다. 가능한 한 중복투자를 하게 만들지 않는 책이 좋습니다.(돈독 오른 오라일리가 싫습니다-_-)

익명 사용자의 이미지

왜 돈독이 올랐다면서 그렇게 싫어하는 것인지??
사실 내용을 설명해주고 'O'reilly의 어떤어떤 책을 봐라'라는 건 그런 생각을 들게 만들기도 하지만.. -_ㅡ;

어느 한편을 편들려고 하는게 아닙니다.
솔직히 Wrox랑 O'reilly 둘다 후회한적이 꽤 되니까요.
하지만 풍부한 배경지식과 이론적설명이라면 그래도 O'reilly아닙니까??
다른 곳은 몰라도 Wrox만큼은 풍부한 배경지식과 이론적 설명이 있다고는 생각해 본적이 없습니다.
항상.. 이론적설명보다 잔기술 중심이라 도서관에서 빌려보길 잘했구나 라고 생각들게 하는게 Wrox인데..

익명 사용자의 이미지

저도 비기닝 시리즈 좋아하는데요
전 괜찬게 봤는데요..좋다구 느꼈구요...오히려 오레일리는 별루...그냥 겉보기만 보는듯하던데요...

박영록의 이미지

그런가요? 서로 본 책들이 달라서 그런가봅니다. 저랑 정반대로 느끼고 있으시군요-_-
제가 위에 예로 든 두 권은 정말 자신있게 추천할 수 있습니다. J2EE 책 저거는 진짜 바이블이라 할 만한 책이고 XML도 XML의 기초에 대해 저거 이상으로 설명해놓은 책은 본 적이 없습니다. 그 외에도 비기닝 씨리즈들은 이론 설명이 풍부해서 후회한 적이 거의 없죠.

오라일리는 두께에 비해 책값이 다른 책보다 10% 이상 비싸면서 책의 내용의 일부 밖에 필요하지 않은 경우가 많더라고요. 제가 본 게 오라클 XML 어플리케이션, 러닝 리눅스, 그누이맥스, VI 레퍼런스, 자바 서블릿 프로그래밍, Lex & Yacc, JFC 인어넛셀 정돈데 자바 서블릿 프로그래밍을 제외하면 하나같이 돈 아까웠습니다. 설명 많이 해줬으면 하는 부분은 대강 넘어가고 그냥 레퍼런스 정도로만 써놓으면 될 껄 구구절절 풀어놓고 심심하면 다른 책 참고하라그러고-_- 러닝 리눅스는 Running 대신 Learning을 붙이는 게 맞다 싶을 정도고--;

제 생각에 오라일리 씨리즈는 회사나 학교 등에서 공동으로 사용할 수 있는 도서관 같은 곳에 세트로 비치해놓고 찾아보면서 하면 좋은 게 많은 것 같습니다. 에시당초 그런 목적으로 나온 인어넛셀 씨리즈나 각종 툴을 다루는 레퍼런스 성격의 책들이 특히 그렇죠. 자바 관련 책들도 엄청나게 세분화되어 있어서 개인이 다 사기엔 부담이 크죠-_- 저번에 세보니까 20권 넘는 거 같던데 ㅡ.ㅡ 자바 IO 프로그래밍을 배우기 위해 책 한 권을 산다는 거..저처럼 가난한 프로그래머에겐 힘든 일이죠.
Wrox가 좋은 건 한두 권만으로 내가 알고 싶은 건 다 알 수 있거든요. 어차피 그 너머는 개인의 몫이라 생각하기에..

머..사실 이건 취향의 문제이기도 해서.. 결론 낼 문제는 아닌 것 같지만, 그냥 주절주절 써봤습니다--;

익명 사용자의 이미지

beginning xml책이 좋다고 느끼시는건 이해가 않가네요..^^;;

익명 사용자의 이미지

저도 그책 와우북에서 엄청나게 세일 하길래 구입 해서
자기전이나 공부 안될때 짬짬이 보고 있습니다만
예제에 비해 말이 너무 많더군요 ㅡ.ㅡ;; 학문적인것도 아닌데 그냥 30일 완성 같은거나 볼껄 그랬습니다.

익명 사용자의 이미지

대부분의 O'Reilly 책은 다른 책보다 나은 점이 많은데요.
특히 다른 책에서는 구할 수 없는 것들이 많습니다. Java나
리눅스 책은 널렸지만, CJKV Information Processing이나
lex & yacc, sed & awk, 낙타책, X 윈도우 시리즈(특히
1,3,4번) 등은 다른 책으로는 대체가 불가능한 것들이죠.
Learning UNIX in a nutshell이나 unix, perl, ruby 등의
nutshell 시리즈도 다른 책으로는 대체할 수 없고요.

그래서 사람들이 O'Reilly의 책을 좋아하는게 아닌가
싶습니다. 저는 같은 주제에 대해 책이 두권 있으면
무조건 O'Reilly 것 삽니다. -_-

익명 사용자의 이미지

내용 자체가 나쁘다고는 하지 않았습니다. 내용이 다른 책보다 나은 것은 동의 못하지만 다른 책에서 볼 수 없는 내용들을 많이 담고 있는 것은 사실이죠. 그러나, 그 내용들도 대부분 웹에서 볼 수 있는 것입니다. 그리고, 지나치게 세분화해서 두 번 세 번 돈을 쓰게 만드는 데다가 권당 책 가격도 다른 책에 비해 좀 비싸서 '돈독 오른'이라고 표현한 것이구요. 돈 많은 사람이야 별 상관 없겠지만 저는 부담이 되는 걸 넘어서서 좀 짜증이 나더군요. 조금만 신경 써서 편집하면 좋을 텐데..

성현의 이미지

정말로 본전을 뽑는 책들을 사야져.
--
세벌사랑, L!nux사랑, 나라사랑

L!nux사랑, 세벌식 사랑, 나라사랑

우겨_의 이미지

출판사 입장에서는 어느정도의 책이 팔려야 하고,
그렇게 하려면, 어느정도 타겟이 되는 독자층이 많아야 합니다.

소수를 위한 깊은 내용보다는, 다수에게 팔아먹을수 있는
평범한 내용으로 책을 출판하는 것이 많이 팔수 있겠죠.

기초나 기본적인 내용을 제외하면 책보다는 인터넷에서
찾아보는 것이 더 좋을 것 같습니다.

익명 사용자의 이미지

man과 msdn을 비교해보면 솔찍히 msdn이 더 편하더군요
또 msdn라이브러리만 나열한 책도 몇권 보이더군요

요즈음은 리눅스 라이브러리를 유추하려면
unistd.h 파일을 열어버리는 버릇이 생겼어요.

그래서 말인데요
시스템 콜 함수들에 대해 나열한 서적이 있으면
나한테는 조금 편하겠다는 생각이 드네요

익명 사용자의 이미지

저도 리눅스의 모든 시스템콜을 설명 + 커널내부 설명 해서
책을 써보면 어떻겠나 하는 망상을 해본적이 있습니다
시간도 오래 걸리고 돈도 못번다고 하고(책 하나 써봤자 600만원 번다더군요)
만약 누가 그런책을 쓴다면 잘팔릴거 같네요 ㅡ.ㅡ;;

익명 사용자의 이미지

개인적으로 10분 가이드 형식으로 얇게 나온 책을 매우 좋아합니다.

요즘도 서점에 가면 이런 시리즈 나오는지 궁금하지만,

간단한 항목별로 적당히 세분화 시킨 얇은 책이 나오면 좋겠네요.

예를 들어 qt프로그래밍,

이런식으로...

(앗 전문가님들은 보시면 눈살을 찌푸리시겠네요....죄송합니다.)

익명 사용자의 이미지

10분 가이드 형식이라...;;

O'Reilly에서 나온 수첩 사이즈만한 책(XML,자바 스크립트,EMACS-_-)이 있는데,

휴대할수 있고 내용도 볼만하더군요...:P

권순선의 이미지

10분 가이드 리눅스...94년인가 95년도에 서울역 지하 한양문고(지금도 있는지 모르겠네요.)에서 3000원인가 주고 샀었는데 그때 제가 알기론 거의 최초의 한글로 된 리눅스 관련 서적이었을 겁니다. 그때 역에서 기차 기다리다가 우연히 보고 뛸듯이 기쁜 마음으로 그자리에서 사버린 책이었죠. (근데 나중에 잃어버렸습니다.) 그러고 보니 요즘은 그런 책이 거의 안나오는것 같네요. 두꺼운 책만 가득하더군요. 분야별로 vi나 emacs, 혹은 gnu 툴을 사용한 프로그래밍 개발에 관한 10분 가이드 류의 얇은 책이 좀 나와 주면 좋으련만....

익명 사용자의 이미지

몇달전 비슷한 주제의 글에서 본 글인네요..^^

박영록의 이미지

맞아요.. 그런 책들 정말 필요하죠. 오라일리에서 포켓북 씨리즈로 그런 걸 내놓긴 했는데 포켓북 답지 않은 가격-_-과 본편에 비해 부실한 내용으로 사람 짜증을 돋구더군요-_-

수우_의 이미지

포켓북.. 저두 하나 사서봤었는데 간단한 레퍼런스 용으로는
나쁘지 않던데요?

얼마 안보고 쌓아뒀지만.
(항상 컴퓨터 앞에 있다보니 책 뒤지는거보단 웹 레퍼런스 보게 되더라는..)

혜진의 이미지

그 책, 저도 샀었는데....98년에요.
.....잃어버렸어요. 어디 외출할 때 들고 나갔다가
지하철에 놓고 내려서...... 멍청하게도.......

처음 산 리눅스 책이었는데..... 싼맛에.....^^;;;;; (이런, 뭐야!!!!)

익명 사용자의 이미지

저도 그 10분가이드 가지고 있지요. 만년초보가 요즘도 유용하게
사용하고 있답니다. ^^;

산들바람_의 이미지

요즘 책들은 너무 두꺼워만 가는것 같아요.
사실 점점 많은 내용을 담아야 하고 그러니깐 그렇겠지만 진짜로 쓸만한 내용을 많이 담고 있는 책들은 그리 많지가 않으니깐요.

음 저는 개인적으로 핸드북이 좋습니다.
간단하면서 정말 쓸만한 내용만을 간추린..
그런데 요즘은 우리나라에서는 핸드북을 안 만드는것 같아요. 돈이 안 되서 그런가.

그리고 두꺼운 책들은 분리가 쉽도록 챕터별로 재본을 해서 통합제본을 했으면 좋겠어요. 그러면 출퇴근 지하철에서 보기도 쉬울텐데. 책 통체로 들고 다니기 힘들구, 자르면 너덜거리고.. 쩝.

siabard의 이미지

예전에 소책자 형식의 책을 기획해서 출판사를 돌아다닌 일이 있었습니다. 웹 프로그래밍에 대해서 분야별로 소개하는 형식이었는데 대부분의 출판사가 거절하더군요.
가장 큰 이유는 가격이었습니다. 아무래도 소책자는 한번에 큰 금액을 받기가 어려습니다. 그 예로 국내에서는 페이퍼백같이 같은 책이라도 저렴하게 만든 책을 보기가 어렵다고 하더군요. 책 자체의 판매가 한정되어있기때문에 재판을 찍는 것은 무리랍니다. 기술서적의 경우는 상당히 판매가 저조하다고 하네요.

그리고 또 다른 이유는 서점에서 조금 꺼린다고 하는군요. 책자가 작아질경우 상당히 분실이 많아진다고 합니다. 서점에서 가장 없어지는 책도 문고본이라는 조그마한 책자가 상당한 양을 차지한다고 하는군요.
--
새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

익명 사용자의 이미지

야근, 철야하지 않고 프로젝트, 기간내에 완수하는 10가지 방법... --;;;

gilchris의 이미지

프로그래머의 배가 안나오는 10가지 방법

뭐 이런 책 없을까요? ㅡㅡ;;;


--------------------------------------------------------------------------------
새로운 세상으로...

자룡의 이미지

밑에 어노니머스로 올리신 분 말같이
오픈소스 프로젝트를 분석해놓은 책이 있었으면 좋겠습니다.

실은 예전에 블랙박스 소스를 정리하면서
이것을 분석하면서 C++ 에 대한 공부도 같이하면
재미있겠다 싶었었는데.. ^^;
능력이 없어놔서 결국 정리만 하고는 거의 잊고 살고있습니다.

하나의 오픈소스 프로젝트를 분석해보고 따라해보는것도
정말 좋은 경험이 될것이라 생각되거든요. :D
--
이글을 읽는 모든이에게 평화가 함께 하기를...

-----
이글을 읽는 모든 이에게 평화가 함께 하기를... ^^;

김영희의 이미지

음 자세한 내용을 담아도 좋을듯 합니다.

헌데 보통은 처음에 시작하기가 어렵지 그다음부턴
여기저기 레퍼런스도있으며, 어떻게 도움을 얻을지도 있지 않나요?

책에는 그냥 처음 "기초 정도"와 보다 많은 내용을 하기위해선 어떠게 접근해야 한다는 "길잡이" 정도만 해주면 되는것도 좋은거 같습니다. 그 이상의 것을 하겟다면 혼자서 열심히 이것저것 해봐야한거 같구요.

프로그래밍은 보통은 훌륭한 API와 약간의 예제 코드만 있으면 배울수있는거 같습니다. 레퍼런스도 좋지만 보통의 레퍼런스는 API번역한거에 지나는 않는 경우가 대부분인거 같은데요...

따라서 제가 책을 쓰면 간단히 처음에 시작하는 방법과, 약간의 예제, 도움을 얻는 방법, FAQ 정도를 담고 싶습니다
하하 그러면 책에 내용이 없군요... 그래서 API를 뒤에 붙이나?

익명 사용자의 이미지

제발 안나왔으면 하는 책

김치하씨 번역의 책.

제발.. 제발.. 다른분께서 다시 번역해 주시면 감사하겠습니다.
김치하씨께서 번역하신것 말고도 다른 이상한 번역의 책들도. 제발.. 이제 그만.

나와줬으면 하는 책.
Gnu C Library Refrence Manual

이거 gnu에서 pdf로 다운받을수 있어서 모두 프린트 했는데 두께가 장난이 아니네요. 제본비도 들고.
가장 중요한점은 영어라는것.. ㅡ.ㅡ
예전에 하이텔 직장인C동호회분들께서 번역해주신게 있지만 조금 오래됐더군요. (좀있으면 거의 10년... ㅡ.ㅡ)

이거 나와줬으면 합니다.. 짧은 영어로 봤지만 역시 레퍼런스더군요.. 좋습니다~~~~ 구웃!

익명 사용자의 이미지

저도 제본해서 보고 있습니다.

이거 정독하는 책은 아니라서 ㅋㅋㅋ

간간히...

익명 사용자의 이미지

Gnu C Library Refrence Manual PDF파일 어디서 구할수 있나요?

알려주시면 감사하겠습니다.

익명 사용자의 이미지

김치하씨는 아마도
학생들이 원서로 공부하기를 바라는 마음에
그런 번역을 하신것 같네요.
영한사전은 구하기 쉽지만
외계어사전은 체계적으로 정리된게 없으니.

익명 사용자의 이미지

아무리 한글 번역이 이상할지라도.2-3번 보면.이해갑니다..

전 한글책으로도...이해잘 되던걸요...

익명 사용자의 이미지

제가 보기는 그런 식으로 우리말 단어를 쓰려고 하는 것도 괜찮게 보이는데요.

무분별하게 영어 단어를 그대로 쓰는 것보다는 그
런 식으로라도 우리 말을 쓰려고 하는 것도 의미가 있다고 생각합니다.

익명 사용자의 이미지

stack : 더미
queue : 대롱
zombie : 강시
kernel : 알맹이
shell : 껍데기

이런게 의미 있는건가요 ?

http://kimchiha.manazone.com/

이런 프로젝트가 나올 정돈데요.

익명 사용자의 이미지

의미가 있습니다.

저는 이 책을 먼저 원서로 보고 한글판으로 보았는데, 한글판 봤을때 처음엔 황당했고 그담엔 어느정도 수긍이 가고 다음엔 끄덕끄덕했습니다.

stack 이란 단어를 책에서 봤을때 어떤 이미지가 떠오릅니까? 저는 영어를 잘 못하기 때문에, 우선 영어구나.. 하는 생각뿐이었습니다. 그 담엔 자주 나오기 때문에 외어야 겠구나 싶었습니다. 하지만, 더미 라고 했을때에는 어디 쓰레기장 같은데에 쌓여있는 쓰레기 더미가 생각이 났고, stack 이 실제 사용되는 방법과 곧장 연관이 되어졌습니다.

queue 하면 생각나는게.. 저는 이주일의 수지큐가 생각나더군요. (윽.. 구시대인가..) 뒤뚱뒤뚱 걸어가는 이주일의 댄싱워킹이 queue 의 작동원리와는 별반 비슷한 바가 없죠. 반면에, 대롱 하면 빨대도 연상이 되고 풀피리도 연상이 됩니다. 한쪽 끝을 불면 다른 한쪽 끝에서 바람이 나오고 소리가 나오죠.

이걸 쓴 스티븐스 (고인이죠..이젠.. 과음땜에 죽었다나.. 어쨌대나..) 도 stack 이고 queue 이고 를 사용할때 연상되었던 이미지는, 바로 우리가 더미와 대롱을 쓸때 연상되었던 이미지와 비슷할 것입니다. 즉, 이렇게 번역을 하는 것이 원서의 뜻을 보다 더 잘 이해해시켜주도록 노력한 번역서라고 생각할 수 있겠습니다.

암튼 방향성은 제대로 된 것이라고 봅니다만, 조금 늦었다는 생각도 들고는 합니다. 하지만, 이런 시도가 기존 번역가들이나 기존 학술세력을 형성하고 있는 중진이 아닌 우리같은 젊은이들한테도 부정적으로 보인다는 사실이 조금은 놀랍습니다.

익명 사용자의 이미지

외국 모든 책들이 한글로 번역되어있다면 모르겠지만요.
어차피 이쪽 있는 사람들은 다 원서도 봐야되지 않나요 ?
저도 영어는 잘 못합니다만, 원서 안보고는 공부하기 힘들더군요.
원서 보려면 영어 단어는 기본으로 알고,
한글 용어가 사실 부차적인 것이죠.
이런 것은 이 용어들이 일반 용어가 아닌 전문 용어이기 때문입니다.
그럼 그냥 원서보면 되지 않냐고 하실 수도 있겠습니다만,
번역서가 좀더 편한 것은 사실이죠, 제대로 번역만 되어있다면요.

특히나 김치하 교수님께서 번역(?)하신 책들은
해당하는 해당 전문 용어에 대해 모르고는 어차피 볼 수 없는 책이고요.
영어로 된 원래 단어들을 썼으면 잘 이해할 수 있었을 내용을,
오히려 이해하기 힘들게 만든 것 같더군요.

간단히, 책의 목적이 무엇인지 생각해보면 되지 않을까요 ?
학생들이 김치하 영한사전을 가지고
새로운 한글 용어들을 공부해야 한다는 것이 해당하는 도서들의 목적인지,
그것도 하필이면 해당 계열에서 유명한 도서들인데 말입니다.

익명 사용자의 이미지

시도자체에 의의가 있다고 생각합니다.
외국말을 그래도 우리말로 바꾸려는 시도는 있었다고 해야.. 좀 덜 창피하죠..

저번에 스톨만이 세미나 할때(연대였던걸로 기억합니다) 통역하는 사람한테 왜 소프트웨어라는 말을 번역하지 않냐?고 하더라구요. 통역하는 사람은 난처해하고...
그때 무른모라는 말같은게 사람들 사이에서 퍼져 성공했으면 어떨까? 생각해봤습니다.
소프트웨어나 하드웨어처럼 일반인도 사용하는 용어는 우리말로 나와야 하지 않을까요?

솔직히 영어 -> 일본어-> 한문 -> 한국어 이런식의 번역된 용어외에는 우리나라에 전문용어가 있나요?

그걸 벗어나려고한 노력을 그게 무슨 의미가 있냐고 하시면 가슴아프지요.

익명 사용자의 이미지

문제는 기존의 사람들이 이해한 stack, queue같은 것의 의미가 더미, 대롱 이런 것과는 거리가 있기 때문이 아닐까요?
뉘앙스의 차이가 분명히 존재합니다..
더미만 보더라도 heap또한 더미로 이해 될 수 있는 것이고..
대롱이란 단어는 누가 이걸 보고..FIFO를 생각해 낼 수 있겠습니까?
번역 작업이 조심스러워야 하는 것은 이런 뉘앙스의 변형을 가져오기 때문이죠..
제대로 된 번역이 되기 위해서는 번역된 우리말이 원 단어의 뉘앙스도 표현할 수 있어야 한다고 생각합니다..

익명 사용자의 이미지

어차피 외국에서도 전문 용어를 이용할 때는 원래 뜻과 차이가 좀 있는 단어에 새로운 의미를 부여해서 씁니다. stack의 원래 뜻은 더미이며, queue의 뜻은 땋아 늘인 머리 내지는 열, 행렬(줄선 것)입니다. 고급 관념어도 크게 다르지 않은데, 컴퓨터 관련 어휘는 아니지만 idea(이데아)같은 말도 원래 그냥 생각이란 뜻이지만 거기에 플라톤 철학의 '형상'이라는 뜻을 넣어서 철학 어휘가 되었습니다. (아마 칸트인가 헤겔인가가 맨 처음 썼죠.)

단어를 새로운 뜻으로 써서 말이 되면 그것이 뜻이 되는 것이지, 시도도 하지 않고 무조건 외래어를 쓰는 것은 바람직하지 않다고 봅니다.

익명 사용자의 이미지

왜 꼭 우리말 전문용어가 있어야 한다고 생각하시는지요 ?
꼭 우리것이어야 한다는 생각도 좋지 않다고 보는데요.
컴퓨터는 외래 문화권에서 온 것이고, 일상적인 어휘가 아닌 학술적인 어휘라면
오히려 외국어를 쓰는 것이 의사소통에도 쉽고 바람직하다고 생각합니다.
( 일상적인 어휘이고 원래의 외국어와 의미상, 뉘앙스상 다르다면 바꾸는게 좋겠죠. )

전문 용어라면 굳이 우리식을 찾을 필요가 없지 않나요 ?
여기저기서 한국식OS를 찾는 사람들과 같은 게 아닌가 합니다.
우리말이 무조건 좋다면, 한자어들(특히 일본식)도 다 안쓰도록 시도해야죠.

말이 좀 샜는데요.
(한국어의 자소를 이용한) 외계 어휘로 바꿈으로 해서
그 번역서가 일으킨 문제를 생각해봅시다.
해당 번역서가 읽기 쉽게 외국어들을 써서 번역이 됐다면,
보다많은 사람들이 쉽게 이해하고 외계인어 번역에 시간투자 안해도 됐을겁니다.
책 사고 후회한 사람들도 보다 적었을 것이고요.
우리말 용어를 알면 외국 용어를 몰라도 되는 상황이라면 모를까,
학생들은 그 책에서 '더미'라고 봤어도 결국 'stack'이란 단어를 알아야합니다.
( 게다가 사실 교수님들은 전부 원서 보기를 권합니다. )
이것들이 다 문제가 되는거죠.
학생들의 시간낭비는 곧 국가적인 손해라는걸 생각한다면,
정말 그따위식의 번역은 좀 과장하면 반국가적인 행위라고 볼수도 있죠.

생활용어라면, 그러니까 우리 말이 있어서 원래의 외국 단어를 몰라도 되는 상황이라면
우리말로 바꾸는 것이 바람직하겠습니다만, 전문용어는 아니라고 봅니다.

제발 이런데 머리굴리기보다
우리나라에서 새로운 이론, 새로운 기술을 만들어서 우리말로 이름붙이고
외국에서 그 말을 고유명사처럼 받아들일수 있게 하는데 시간을 들였으면 좋겠습니다.

익명 사용자의 이미지

님의 글은 여러가지 논지가 뒤섞여 있군요. 이런식으로 글을 전개함은
상대방의 의견을 이모저모로 둘러가면서 반박하고 공격하는데에는
효과적일지 모르지만, 협력하고 주제를 앞으로 발전시켜나가는데에는
전혀 도움이 되지 못합니다.

정리해 보자면,

첫번째단락은 외래문화이므로 외래어를 써야한다. (그러므로 김치하교수의
순수한글단어의 사용은 안좋다.)
두번째단락은 전문용어이므로 한국어보다 일본식한자어가 더 낫다. (그러므
로 순수한글단어 사용은 안좋다)
세번째단락은 .. 도저히 정리가 안되는군요. 주장하는 바라기 보다 힐난
하는 말 뿐이라서.. 암튼 한글용어가 나쁘다.
네번째단락은 생활용어가 아닌 전문용어는 한글로 쓰지 말자.
다섯번째단락은 한글용어 쓸 시간에 연구나 해라.

일맥하는 주장은 없고 서로 부딪치는 내용뿐이네요. 외래문화이기 때문에
외래어를 써야 한다면, 원서만 보자는 말입니까? 이게 불가능하기 때문에
번역이 있는 것인데, 번역 할 바엔 명사고 동사고 간에 모두 번역하는것이
가장 바람직한데도, 기존에는 주요 명사들을 (베껴온) 일본식한자 및 영어의
병기를 해 왔었죠. (주로 서울대 쪽 교수들이 즐겨 해온 일입니다) 그런데,
그게 좋다는 말이군요. 지금이 신라시대입니까? 차라리 이두를 쓰자고
하는 것이 낫겠군요. 가능한한 모두 직독직해가 되도록 한글화 하는 것이
가장 바람직한 것입니다. 그 과정이 매우 어렵기 때문에 어쩔 수 없이
차선책으로 한자어 내지는 영어 병기를 하는 것입니다. 결코 그게 바람직
해서가 아닙니다.

어쩔수 없이 이루어져온 사실이 기준인 것 처럼 생각하시면 곤란합니다.
어쩔수 없이 일본식 한자단어 및 영어병기로 점철되어 있는 기술서적
번역물에 익숙해 져서 김치하교수가 쓴 글이 어색해 보인 것이지.. 그게
바람직한 것은 아니라는 것이죠. 물론 현실을 너무 고지식하게 보는
바람에 동의 영단어를 병기 하지 않은 저자의 순진함도 한 몫 했습니다.

님의 주장은 아무리 간추려 봐도 번역서의 정의를 이렇게 내리는 것
같습니다. 기술서적 번역에 있어서 주어 및 목적어는 모두 일본식
한자어와 원어를 둘다 같이 병기하여야 하고, 순수한글어는 모두 이두식
으로 써야 제대로 된 번역이다. 의미가 잘 맞는 한글단어가 있어도 그것을
쓰는 것은 국가적 반역이다. 음.. 번역이 반역이 되는군..

논리가 승만이형 논리입니다. 기존의 친일교수 친일경찰들이 교육 및
치안을 담당했으니, 그대로 그 방식대로 하는 것이 기준이다. 편하므로,
괜히 불편함을 감수하여 새로 사람을 뽑을 필요성이 없다. 불편을
초래함은 국가적 반역이다... 그런 논리는 1공 이후 국가적 기조가
되어 전통인습이 되어 잘 전승되어 오고 있지요. T_T

마지막 말도 걸작입니다. ..할바엔 ..나 해라. 이런 말투는
초등학생끼리 싸울때나 하는 말입니다.

쓰다보니 주장보다는 비난만 되었습니다. -1 점 주세요 관리자님...

익명 사용자의 이미지

제대로 된 우리말 단어가 있다면 우리말로 배우는 것이 쉬울까요, 아니면 영어로 배우는 것이 쉬울까요.

한번 제대로 안다면 그 이후에 다른 말로 어떻게 쓰는가를 아는 것은 금방입니다. 그리고 영어로 된 단어는 한국어로 된 단어에 비해 배우기 어려울수밖에 없죠. 지금 영어로 된 것이 더 쉽게 느껴지는 것은 이미 영어 단어에 익숙해졌거나, 아니면 제대로 된 한국어 단어가 없기 때문입니다. 솔직히 지금 나온 책들이 단어 선택이 그리 잘 됐다고 할 수는 없지만, 이런 식으로라도 시도가 계속되어서 언젠가 주요 어휘들이 모두 한국어로 적절하게 번역이 되어 널리 쓰인다면 그때는 배우는 사람들도 아무 불편이 없을 것입니다.

한편으로는 이렇게 생각할 수 있지 않을까요? 한국어로 된 단어가 있다면 원래 그 단어의 뜻에서 이 단어가 컴퓨터에서 어떻게 쓰이는가를 유추할 수 있지만, 영어로 된 단어라면 그 영어 단어를 먼저 알고 컴퓨터 쪽에서는 어떻게 쓰일까도 같이 알아야 하니 두 배로 노력이 들어, 그것도 국가적인 손해라고요.

익명 사용자의 이미지

>> 제대로 된 우리말 단어가 있다면 우리말로 배우는 것이 쉬울까요, 아니면 영어로 배우는 것이 쉬울까요.

영어로 배우는 것이 쉽습니다.
모든 책이 다 번역되어 나오지 않는 이상은요.

익명 사용자의 이미지

십년 넘게 원서를 보아왔어도 쓰이는 용어 자체를 이해하면서 기억하기란
어렵습니다. 보통 외우게 되죠. kernel 이라든지 stack 이라든지 그냥
말그대로를 외우게 됩니다. 이게 제대로 번역이 된 상태로 처음에 머리
속으로 들어왔다면 얼마나 쉬었을지를 생각하면, 그동안 조금이라도
헤맸었던 시간이 너무나 아깝죠.

이미 머리속에 들어온 단어들이었기때문에, 그 책을 읽었을때에는 저도
상당히 헷갈렸습니다. 하지만, 처음 읽는 것이라면 아주 잘 만든 책이라고
생각이 들더군요. 알맹이/더미 같은 순수 우리말로 그 용어의 의미를 잘
설명해 놓은 것이니까요. 기존의 한자어들은 다들 일본책을 베껴서 가져온
것입니다. 이왕 쓸 것 우리말로 처음에 받아들이는 것이 백번 낫습니다.

영어가 능통해서 단어를 듣는 순간 그 이미지가 머리속에 그려지는 분이라면
(kernel 이라는 단어를 처음 원서에서 봤을때 그냥 머리속에 이해되는...)
원서를 보는 것이 가장 좋겠지만서두요...

익명 사용자의 이미지

신선하지 않나요?...대충보다보면..이해 가던데..-_- 물론.... 당황스럽긴 하지만...

익명 사용자의 이미지

Silberschatz 의 Operating System Concepts 를 번역해 놓은 것을 보면 아주 가관입니다.
context switching 을 "문맥 교환" 이라고 번역해 놨더군요. 이것을 비롯하여 곳곳에서 아주 난감한 번역들이 눈에 거슬렸더랩니다.

얼마전에 치루었던 정보처리기사필기시험에서 문제의 보기에 "문맥 교환" 이라는 영 해괴한 단어가 등장한 것을 보고 기가막혔던 일이 생각납니다.

할려면 제대로 번역을 하던지, 아니면 그냥 영어로 표기하거나 발음대로 표기하여 외래어로 쓰는게 나을듯 싶더군요. 이렇게 번역하느니 차라리 김치하 교수님의 번역이 낫지 싶었습니다.

익명 사용자의 이미지

문맥교환 맞는데.-_-

익명 사용자의 이미지

그럼 context switching에 어울리는 번역은 어떤 것일까요?
제가 보기에는 나쁘지 않은 번역이라고 생각합니다만.

익명 사용자의 이미지

그 Silberschatz 의 책 6차 개정판에서 103 페이지를 보면 이렇게 적혀 있구요.

The context of a process is represented in the PCB of a process; it includes the value of the CPU registers, the process state (Figure 4.1), and memory-management information.

144 페이지를 보면 이렇게 적고 있습니다.

The register set, stacks, and private storage area are known as the context of the thread and are architecture-specific to the hardware on which the operating system is running.

여기에 기술된 context 라는 단어가 우리나라말 文脈 이라는 단어와 무슨 연관이 있는지 저는 잘 모르겠습니다.

Oxford Adnvanced Lerner's Dictionary 에서 context 를 찾아보면 다음과 같이 적혀 있습니다.

con•text noun [C, U]
1 the situation in which sth happens and that helps you to understand it: This speech needs to be set in the context of Britain in the 1960s. His decision can only be understood in context. Such databases are being used in a wide range of contexts.
2 the words that come just before and after a word, phrase or statement and help you to understand its meaning: You should be able to guess the meaning of the word from the context. This quotation has been taken out of context (= repeated without giving the circumstances in which it was said).

누가 봐도 Silberschatz 책에 나온 context 라는 단어는 설명 1 번에 가까운 뜻을 가지고 있습니다.

야후에서 제공하는 국어 사전에는 文脈 을 다음과 같이 설명합니다.

문맥 (文脈) 내용상 서로 이어져 있는 문장의 앞뒤 관계. 글발. ¶ ∼이 통하다 / ∼이 닿다 / ∼을 파악하다.

우리말 "문맥" 은 context 의 설명 1 번과 별로 연관이 없어 보입니다. 2 번에 가깝군요.

물론 번역하신 분들은 나름대로 수고를 하셨겠지만, 이렇게 번역을 하려면 차라리 영어로 그대로 적든지, 아니면 발음대로 표기하여 외래어로 만드는 것이 낫다고 봅니다. 그것도 싫으면 김치하 교수님처럼 번역을 하는것이 차라리 나은것 같군요.

이 번역은 단순히 영한사전에 나와 있는 우리말 단어를 그대로 대치한 경우죠. 이로 인해서 기존에 우리가 알고 있던 우리말 단어가, 의미상 별로 상관이 없는 외국어의 뜻을 가지고 쓰였기 때문에 매우 부자연스러운 느낌을 줍니다.

전 이런 번역들이 아주 싫은데, 제대로 번역할 능력은 없어서 웬만해선 좀 비싸도 원서로 사서 봅니다.

익명 사용자의 이미지

언어는 사회적 약속입니다.

google.co.kr 가서 문맥교환이라고 입력해 보세요. 그것이 잘된 번역인지 아닌 지를 떠나서 context switch 라는 말을 한국어로 쓸 때, 문맥 교환이라는 말을 많이 쓰고 있습니다.

물론 정확히 보자면, CPU가 어떤 작업을 수행하다가 다른 상황으로 넘어갈 때 사용하는 용어 이므로, CPU가 돌아가고 있던 맥락, 상황 등이 바뀌는 맥락 교환 정도가 될 것 같습니다만, 문맥교환이라고 하더라도 그러한 느낌을 잘 반영합니다.

그리고 님께서 제시하신 두 가지 뜻 중 제가 볼 때는 2번 뜻이 더 맞는 것 같습니다. 1번 뜻은 어떠한 일이 일어난 배경 내지는 원인 정도로 해석되는데, 이것이야 말로 컨텍스트 스위치에서 컨텍스트하고 무슨 관계가 있는 지 궁금합니다.

오히려 CPU가 기계어를 읽어 내려 가다가, 갑자기 다른 부분의 기계어를 읽기 위해 context를 교환한다. 즉 하나의 작업을 하기 위해 일련의 기계어를 읽는데, 이 기계어를 문맥이라고 볼 수 있습니다. 그런데 프리엠션이라도 일어나서 컨텍스트 스위치가 필요할 경우, 새로운 프로세스를 CPU에 돌리기 위해서는 새로운 기계어 문맥이 필요하다.

충분히 설득력 있는 번역어라고 할 수 있습니다.

문맥 교환은 이미 많이 쓰이는 용어이고, 뜻을 자세히 따져 보아도 거의 정확한 역어입니다. 이 역어는 다른 이상한 역어에 비하면 훌륭한 역어라고 생각합니다. zombie를 강시라고 번역하는 것과 이것을 비교하면 이 쪽이 훨씬 낫습니다.

그리고 이 책을 번역하신 교수님의 수업을 들은 적이 있는데, 저희보고는 번역책 읽지 말라고 하시더군요. 저희들을 위해서 번역하신게 아니랍니다. 이러한 의도에서 볼 때, 컨택스트 스위치라고 적으면 영어를 모르는 사람은 그 뜻을 짐작도 할 수 없습니다. 그러나 문맥 교환이라는 말을 들으면, 무언 지는 몰라도 진행 중이라는 것이 변하는 작업이구나라는 정도로 지레 짐작을 할 수 있고, 이 짐작은 이해에 많은 도움이 될 것 입니다.

그럼... :)

익명 사용자의 이미지

Anonymous wrote...
> 언어는 사회적 약속입니다.
>
> google.co.kr 가서 문맥교환이라고 입력해 보세요. 그것이 잘된 번역인지 아닌 지를 떠나서 context switch 라는 말을 한국어로 쓸 때, 문맥 교환이라는 말을 많이 쓰고 있습니다.

제가 짜증이 나는 이유는, 이러한 의미 전달 과정이 왜곡된 번역에 의하여 우리말이 오염되고 있다고 때문입니다.

> 물론 정확히 보자면, CPU가 어떤 작업을 수행하다가 다른 상황으로 넘어갈 때 사용하는 용어 이므로, CPU가 돌아가고 있던 맥락, 상황 등이 바뀌는 맥락 교환 정도가 될 것 같습니다만, 문맥교환이라고 하더라도 그러한 느낌을 잘 반영합니다.

문맥은 문장의 맥락입니다.

> 그리고 님께서 제시하신 두 가지 뜻 중 제가 볼 때는 2번 뜻이 더 맞는 것 같습니다. 1번 뜻은 어떠한 일이 일어난 배경 내지는 원인 정도로 해석되는데, 이것이야 말로 컨텍스트 스위치에서 컨텍스트하고 무슨 관계가 있는 지 궁금합니다.

context 가 무엇인지는 위에 Silberschatz 의 책에서 발췌한 부분에 나와 있습니다. process 또는 thread 의 context 라 함은, 해당 process 또는 thread 와 관련된 register 와 process/thread 의 state 등의 것을 말한다고 하는군요.

OALD 보다는 좀 더 간결하게 나와있는 Merriam-Webster's Collegiate Dictionary 를 보면 다음과 같이 context 를 설명하고 있습니다.

Main Entry: con·text
Pronunciation: 'kän-"tekst
Function: noun
1 : the parts of a discourse that surround a word or passage and can throw light on its meaning
2 : the interrelated conditions in which something exists or occurs : ENVIRONMENT, SETTING

여기선 OALD 에 나온 것과 1, 2 번이 바뀌어 있네요.

> 오히려 CPU가 기계어를 읽어 내려 가다가, 갑자기 다른 부분의 기계어를 읽기 위해 context를 교환한다. 즉 하나의 작업을 하기 위해 일련의 기계어를 읽는데, 이 기계어를 문맥이라고 볼 수 있습니다. 그런데 프리엠션이라도 일어나서 컨텍스트 스위치가 필요할 경우, 새로운 프로세스를 CPU에 돌리기 위해서는 새로운 기계어 문맥이 필요하다.

저는 Silberschatz 의 Operating System Concepts 6차 개정판에서 기계어가 context 라고 설명하는 부분을 찾을 수 없었습니다. 혹 이전판이나 한글 번역판에 그렇게 되어 있나요?

context 는 compiled code 또는 text, bss, data 등을 말할때 쓰이는 text 와는 다른 뜻을 가집니다. Silberschatz 는 분명 context 라고 적었습니다. 글 쓰신 분께서는 아마도 기계어와 context 를 혼동하고 계신 것 같네요.

> 충분히 설득력 있는 번역어라고 할 수 있습니다.

따라서 저는 이 번역이 설득력 차원이 아닌, 틀린 번역이라고 지적합니다.

> 문맥 교환은 이미 많이 쓰이는 용어이고, 뜻을 자세히 따져 보아도 거의 정확한 역어입니다. 이 역어는 다른 이상한 역어에 비하면 훌륭한 역어라고 생각합니다. zombie를 강시라고 번역하는 것과 이것을 비교하면 이 쪽이 훨씬 낫습니다.

제가 보기에 김치하 교수님께서는 극단적으로 한자어의 사용마저 배제하려고 하신 것 같습니다. 아직까지 이렇게 하기엔 분명 무리가 있다고 생각합니다만..

그렇게까지 하지는 않더라도 적절한 다른 우리말을 적을수도 있겠죠. 최소한 context 를 영한사전에서 찾았을때 제일 처음에 나오는 단어를 무작정 적는 것 보다는 나았을 것이라고 봅니다.

> 그리고 이 책을 번역하신 교수님의 수업을 들은 적이 있는데, 저희보고는 번역책 읽지 말라고 하시더군요. 저희들을 위해서 번역하신게 아니랍니다. 이러한 의도에서 볼 때, 컨택스트 스위치라고 적으면 영어를 모르는 사람은 그 뜻을 짐작도 할 수 없습니다. 그러나 문맥 교환이라는 말을 들으면, 무언 지는 몰라도 진행 중이라는 것이 변하는 작업이구나라는 정도로 지레 짐작을 할 수 있고, 이 짐작은 이해에 많은 도움이 될 것 입니다.
>
> 그럼... :)

저같은 경우는 "어떻게 context 가 문장의 맥락을 뜻하는 문맥이 될수 있는가" 때문에 우리말 문맥과 영단어 context 에 대한 개념 자체에 혼란이 왔었습니다.

거듭 말하지만, 이러한 식의 잘못된 번역은, 그 번역에 의한 표현이 의미상 영 어색한 단어의 조합을 탄생시키고, 시간이 좀 지나면, 그 의미상 영 이상한 단어가 공공연한 표준으로 자리잡게 한다는 데에 문제가 있다고 생각합니다.

게다가 저로선 예상치 못했던, machine code 와 context 를 혼동하는 모습까지 이곳에서 목격했습니다. 난감할 수 밖에 없군요.

번역서를 많이 보신 분들은 잘 아시겠죠. 이러한 엉망인 번역이 생각보다 꽤 많다는 것을요..

장수원의 이미지

아까 그 글을 쓴 사람입니다.

먼가 오해가 심한 것 같습니다. :)

저는 단 한번도 machine code 가 context 라고 말한 적이 없습니다. 일단 기계어도 언어입니다. 사람이 이해하는 언어가 아닌 기계가 이해하는 언어 입니다. 이러한 언어를 통해 컴퓨터와 의사소통을 하는 것입니다.

이는 인간의 언어도 마찬가지입니다. 인간의 언어에서 문맥이라는 것은 말 그대로 말의 맥락입니다. 예를 들어, "철수야, 밥 먹고 세수해라" 라는 문장을 이해할 때, 문맥을 잘 따라 간다면 밥을 먹고 세수를 하겠지만, 잘못 따라간다면 세수하고 밥을 먹을 수도 있고, 세수 하면서도 밥을 먹을 수도 있을 것 입니다.

그렇다면 context switch 에서 context의 뜻도 이런 맥락에서 이해하는 것이 더 좋다고 생각합니다. 예를 들어,

mov ebx, eax
mov eax, ecx

라는 인스트럭션이 있으면 CPU는 이를 읽어 들이면서 context를 형성할 것 입니다. 베이스 포인터는 어디를 가르키고 있고, 인스트럭션 포인터는 어디를 가르키고 있고, eax에는 무엇이 들어 있고 등등 일련의 기계어를 CPU가 읽어 들이면서 형성되는 것이 context입니다.

다시 사람의 예로 돌아와서 "철수야, 세수하고 밥먹어라" 라고 말하는 도중에 "철수야 심부름좀 갔다와라"는 말이 끼어 들 수 있습니다. "철수야, 세수하고 ; 철수야 심부름 좀 갔다 와라 ; 밥먹어라". 이럴 경우 철 수는 첫번째 문장의 문맥과 두번 째 문장의 문맥을 잘 구분해야 합니다. 세수한 후에 밥을 먹어야 하지만, 심부름은 세수랑 밥과는 전혀 다른 문맥에서 나온 것입니다. 따라서 두 개의 문맥을 기억해야 겠죠.

컴퓨터에서 context도 마찬가지입니다. 어떤 프로세스가 CPU에서 실행되고 있는 도중에, 다른 프로세스가 선점, 즉 프리엠션을 하면 지금까지 실행되고 있던 프로세스의 context와는 전혀 다른 context로 실행됩니다. 그러므로 두 가지의 context를 메모리에 잘 기억해 두어야 합니다.

이렇게 보면 일상 생활에서의 문맥과 OS에서의 context가 너/무/나/도/ 똑같지 않은가요?

이러한 측면에서 보면 문맥 전환이라는 역어는 별로 잘못된 점이 없습니다.

야후 영한 사전의 풀이를 보면,

1. (문장, 내용 등의) 전후관계, 문맥
2. 배경, 상황

이렇게 되어 있더군요. 영영사전이랑 별반 다를 바가 없습니다.

context switch 가 과연 배경 전환 혹은 상황 전환이라고 해야 할까요?

제 생각에는 "내용의 전후관계" 전환이 더 정확해 보입니다.

그리고 그런 어감을 풍기는 것이 문맥이구요.

다시 한번 말씀들이지만 context 혹은 문맥 자체가 machine code라고 말하는 것이 아닙니다. 이 글 전에 썼던 글을 다시 한 번 자세히 읽어 봐 주시면 감사하겠습니다. 제가 context라고 말했던 것은, 일련의 기계어가 CPU와 메모리에 올라가서 실행되면서 생기는 특정한 문맥입니다. 상황이나 환경이라고 해도 상관은 없겠지만, 그렇게 쓰면 굳이 environment를 사용하지 않고 context라고 계속 쓰는 원어의 어감을 살리지 못합니다.

따라서 문맥 전환은 나쁜 번역 아니고, 그럭저럭 제대로 된 번역입니다. 제가 번역하더라도 context switch는 문맥 전환이라고 번역할 것입니다. 물론 짜증나는 역어들이 정말로 많지만 문맥 전환이 그 곳에 들어갈 정도로 엉망인 번역인 것은 아니라고 생각합니다.

잘못된 점은 지적을...

그럼 :)

익명 사용자의 이미지

> 오히려 CPU가 기계어를 읽어 내려 가다가, 갑자기 다른 부분의 기계어를 읽기 위해 context를 교환한다. 즉 하나의 작업을 하기 위해 일련의 기계어를 읽는데, 이 기계어를 문맥이라고 볼 수 있습니다. 그런데 프리엠션이라도 일어나서 컨텍스트 스위치가 필요할 경우, 새로운 프로세스를 CPU에 돌리기 위해서는 새로운 기계어 문맥이 필요하다.

우리말 문맥이라는 말이 뜻하는 것은 "문장의 맥락" 입니다. main memory 상에 들어있는 process 와 thread, 그리고 그의 실행에 관련된 process 또는 thread 의 state, register set 등은 분명 국어시간이나 국문학, 시간에 다루는 문장이 아닙니다. 또한 machine code 들의 조합을 sentence 또는 clause, phrase 라고 부르는 경우 또한 아직 접하지 못했습니다. 말을 쓰는 분야 자체가 분명 다릅니다.

여기엔 분명히 "일련의 기계어를 읽는데, 이 기계어를 문맥이라고 볼 수 있다" 라고 되어 있습니다. 또, preemption / non-preemption 은 process 또는 thread 에 대한 정책이지 preemption 이 일어난다고 하지는 않죠. 일어나는 것은 process 또는 thread switching 이며, 이 switching 의 과정에서 context switching 이 발생한다고 Silberschatz 의 책에 나와 있습니다.

장수원님이 직접 책을 쓰신다면 장수원님 뜻대로 적으셔도 상관이 없겠지만 이것은 분명 Silberschatz 의 원저를 번역을 하는 것입니다. 일상생활에서 context 라는 말이 어떻게 쓰이는지는 이 책이 일상적인 것이 아닌 전문분야를 다루는 것이기 때문에 중요하지 않다고 봅니다. 지금 제가 하는 이야기는 "이러한 번역을 가지고 독자가 이를 어떻게 해석할 것인가" 에 대한 것이 아닙니다.

중요한 것은 Silberschatz 가 책에 적은 context 는 정수원님이 생각하는 그러한 "문맥" 또는 context 가 아니라는데 있습니다. "내용의 전후 관계" 가 아닌 것이죠. Silberschatz 가 말하는 context 라는 것이 어떤 것인지는 이곳에 적은 글과, 그의 책을 보면 잘 나와 있습니다.

특히나 이러한 기술 서적은 원저자가 의도했던 내용 만큼은 가능한 그대로 전달되어야 그나마 제대로 된 번역이라고 생각합니다.

자, 잘못된 단어의 사용으로 원저자가 뜻하던 바에서 많이 빗겨나간 해석을 가능하게 해 주고, 기존의 우리말 개념에도 혼란을 가져올 수 있는 이러한 번역이 과연 잘된 것인가요?

장수원의 이미지

^^;;

먼제 선점되었다라는 말은 씁니다. 선정형 커널, 비선점형 커널 이렇게 부를 때도 쓰찌만, 지금 실행중인 프로세스보다 우선순위가 높은 프로세스가 도착하면 선점 혹은 프리엠션이 일어납니다. 이런 표현은 많이 쓰고 있습니다.

그리고 분명히 저의 경우는 문맥 교환이라는 표현이 context switch라는 것의 뜻을 이해하는데 도움이 많이 되었습니다.

더 이상 논쟁은 하기 싫습니다. 하지만 님께 부탁드리고 싶은 것은, 제발 제 글을 자세히 읽어 보시고 제가 내린 정의를 좀 더 정확하게 이해해 달라는 것입니다.

:main memory 상에 들어있는 process 와 thread, 그리고 그의 실행에 관련된 process 또
:는 thread 의 state, register set 등은 분명 국어시간이나 국문학, 시간에 다루는 문장
:이 아닙니다. 또한 machine code 들의 조합을 sentence 또는 clause, phrase 라고 부르
:는 경우 또한 아직 접하지 못했습니다. 말을 쓰는 분야 자체가 분명 다릅니다.

저는 프로세스의 상태나 레지스터 들을 문장이라고 한 적이 없습니다. 오히려 그런한 것들의 전체가 context이다라고 말씀드렸습니다.

:일련의 기계어를 읽는데, 이 기계어를 문맥이라고 볼 수 있다

이 부분에서는 제가 실수를 한 것 같습니다. 죄송합니다(__). 일련의 기계어를 읽어 일어 들이면서 문맥이 형성되는 것이라고 정정해야 겠네요.

OSC 책도 읽고 있고, bach 책도 읽었지만 context 는 내용의 전후관계로 이해하는게 환경 보다 좀 더 정확하게 이해했다고 생각했는데요.

그리고 context는 차용어 입니다. context가 전산 쪽에서 새롭게 생겨난 말이라면, 일상적인 뜻을 고려하지 않아도 되겠지만, context의 경우 어떠한 이유로 차용되었는 가를 잘 따져야 합니다. 저는 그런 따지는 과정에 의거 했을 때, 문맥이라는 말이 나쁘지 않다고 말씀드린 거구요.

원저자의 의도를 가장 잘 반영하는 것은 번역하지 않는 것이라고 할 수 있습니다. 그리고 OSC 정도의 책이 전문서라고 생각하시는 지요? 제가 읽었을 때는 입문서 정도 인 것 같습니다만... 정말 일반인이 읽지 않을 고도의 전문서라면, 번역이 되지도 않았을 겁니다. 어차피 번역할 것이라면 저자의 의도를 100% 살리는 것은 불가능하고, 번역의 중요한 목적은 외국어에 관한 지식이 없는 사람도 그 책을 읽을 수 있도록 만드는 것입니다. 원어의 뜻과 얼마나 맞는 지에 대해서는 저하고 의견 차가 큰 것 같으시니 일단 그 쪽은 접어두더라도 사회적으로 어느 정도 인정된 용어이므로 컨택스트 스위치라고 번역하는 것보다는 문맥 전환이라고 번역하는 것이, 처음 접하는 사람에게는 도움이 되지 않을까요?

또 길어져 버렸네요. 제가 쓴 글에 자의적 해석이 들어 있는 것은 인정하겠습니다. 그리고 이 스레드는 토론의 주제와 많이 벗어나 버렸군요. ^^;;; 하지만 과연 문맥 전환이라는 단어가 기존의 우리말 개념에 혼란을 가져올 정도로 문제가 심각한 역어 인지, 원저자의 의도를 심하게 왜곡하는 역어인지 다시한 번 잘 생각 부탁 드립니다. 더 이상 답 글은 달지 않겠습니다 :) 메일로 의견을 드리려고 보니. 메일 주소가 없으셔서...

그럼 :
)

익명 사용자의 이미지

OSC 가 전문서적이 아니라니..

옆집에 살고있는 평범한 회사원인 철수아빠나 평범한 주부인 영희엄마에게
컴퓨터에 대해서 공부할수 있는 책이라고 하면서 OSC 를 선물했을때
영희아빠나 철수엄마가 OSC 내용중의 1/10 이라도 이해할까요?
(물론 영희아빠나 철수엄마 모두 영어를 못해서 한글판을 선물했다고 하죠.)

컴퓨터 일주일만 하면 전유성만큼 한다.. 이런거면 1/10 이상도 가능하겠죠?

컴터장이의 입장에서 보면 OSC 는 분명 운영체제에 대한 입문서이자,
난이도는 좀 낮되 분명 컴퓨터 전문 서적이 맞겠죠?

대체 얼마나 대단한 곳에서 얼마나 대단한 일을 하길래
OSC 가 전문서적이 아니라고 말씀하시는지 궁금해지는군요.
프로세스 스케쥴링 알고리즘 같은것 하나 정도는
그냥 쉽게 만들고 우습게 증명을 할 수 있나보죠?

장수원의 이미지

제가 잘못을 인정해야 할 것 같습니다.

저 밑의 어떤 님께서 올려 주신 것을 보니, context는 맥락이라고 정의 되어 있네요.

맥락 교환이 문맥 교환보다는 나은 역어 이겠군요.

이미 표준화가 되어 있는 말을 가지고 이래 저래 떠들어서 죄송합니다.

그럼 :)

익명 사용자의 이미지

그러면 context의 적확한 번역은 어떤 것이라 생각하십니까?

저는 그게 궁금하네요. 님의 논지는 잘 이해하고 있습니다만
그렇다고 틀린 번역을 하느니 앞으로는 그런 글은 전혀
번역하지 말고 소리나는 대로 읽자고 주장하지는 않으실
것으로 믿습니다.

대안을 듣고 싶습니다.

익명 사용자의 이미지

컴퓨터 서적에서 process 를 방법, thread 를 실 이라고 번역하지는 않습니다.
마찬가지로 OS 에서 등장하는 context 를 문맥 이라고 번역하는것 또한 잘못되었다고 생각합니다.

아직 적당한 우리말을 못찾았끼 때문에, 굳이 이걸 한글로 적어야 할 경우에는 그냥 "컨텍스트" 라고 적습니다. thread 나 process 의 경우도 발음대로 표기하고 있으니까요.

익명 사용자의 이미지

제 생각에는 이런 경우 세가지 정도가 방안일 것 같습니다.

1. 그냥 원어를 소리나는 대로 읽는다.
번역에 큰 의미가 없다고 봐도 되겠죠. 가령 context에 어울리는
우리말이 있다면 직관적으로 이해가 될테지만 그냥 context라고
쓰면 무슨 말인지 알기 위해 부가적으로 설명이 더 필요하니까요.
하지만 번역서에서 그런 추가 설명까지 해 주는 경우는 드뭅니다.
따라서 읽는 사람의 이해도는 가장 떨어집니다. 물론 원서를
먼저 숙지한 분들에게는 전혀 문제가 되지 않겠죠.
하지만 번역서만 읽어 본/읽을수밖에 없는 분도 아주 많습니다.

2. 현재 사전 내에서 가장 적절한 우리말을 찾아 쓴다.
이것이 가장 바람직합니다만 찾기 어려운 경우가 많습니다.
process나 thread가 그러한 예겠죠. kernel이나 shell도
마찬가지라고 할까요? 혁신적인 시도가 김치하 교수님의
역서에서 사용되었지만 받아들여지려면 시간이 걸리거나
부정적 반응이 더 크기도 합니다.

3. 새로운 단어 또는 기존의 단어에 그 뜻을 부여한다.
context => 문맥이 그러한 예에 해당할 것 같습니다. 기존에 뜻이
없었다면 그러한 뜻도 부여할 수 있겠죠. 처음에는 거북할 수도
있겠지만 시간이 지나 많은 사람들이 받아들이면 괜찮다고
생각합니다. 언어란 변하는 것인데 언제나 한가지 뜻만 가지지는
않을지도 모르죠.

번역하기 애매한 말 많습니다. case-sensitive를 뭐라고 번역해야
할지 오래 고민했습니다. ;_; (한번 생각해 보세요). 이정도는 약과입니다.
윈도우 도움말에 등장하는 용어인 context-sensitive help는 뭐라고
번역해야 좋을까요? 하지만 그렇다고 소리나는 대로 읽을 수는 없는 것입니다.

최근에는 XML의 well-formed/valid document에 대해 고민해 보았습니다. ;_;
이건 well-formed formula에서와 같은 의미인데... "잘 형성된" 정도가 웹에서
볼 수 있는 번역 같은데 잘 와닿지가 않죠. "형식에 맞는" 정도가 적당해
보이지만 그럼 원문과 동떨어진 번역이란 이야기를 들을지 모르죠. 그런 의미는
valid가 더 가까울지 모르니까... 이것도 그렇다고 소리나는 대로 읽을 수는
없죠. :<

한국어로 잘 된 번역 나오기란 참 힘듭니다.

익명 사용자의 이미지

context -> 문맥은 분명 문제가 있습니다.

context 에서 con 은 with, together 을 뜻하는 latin 계 접두어이고 text 는 to weave 의 의미를 가지는 어근입니다. 文脈 이 뜻하는 것과는 분명 차이가 큽니다.

굳이 脈이 들어가는 말로 옮겨야 한다면 맥락, 기맥 등의 말이 그나마 좀 비슷한 것 같고요. 상황, 상태, 배경 등의 말로 옮길수 밖에 없겠군요.

그리고, 여기에 등장하는 context 라는 말은, 상통하는 뜻을 가지고 유사한 개념으로 통용되는 우리말이 없는 상태고 (이래서 문제가 되는 것이죠), 전문 기술 서적에 쓰이는 말인데 굳이 이를 우리말 단어로 옮길 필요가 있겠냐는 생각이 드는군요.

익명 사용자의 이미지

그런 깊은 뜻이 있었군요.

제 생각으로는 한국어에 원래 없던 영어로 된 전산 용어를 제대로
표기하는 것은 아주 어려운 일입니다. 그래서 그냥 영어로 된
책 보실 것이라면 할말 없지만, 번역해야 한다면 어울리는 낱말을
찾거나, 기존 낱말 중에 새로운 의미를 추가하는 것도 나쁘지
않다고 봅니다. context의 예를 들면 결국은 현재의 프로세스 상태를
나타내는 말인데, 우리말로 딱 어울리는 그런 말을 찾기란(아랫분이
환경이라고 하셨는데 그럼 environment와 혼동할 우려가 있습니다)
어렵거나 존재하지 않을 수 있으므로 기존의 단어에 그러한 새로운
의미를 부여할 수도 있다고 봅니다. 즉 우리말 '문맥'에 영어
context의 의미 1을 부여할 수도 있다는 이야기지요. 계속 그렇게
쓰인다면 낱말이 그 뜻을 사회적으로 획득할 수도 있다는 이야기입니다.

제 경험으로는 대부분의 전산 용어는 그렇게 하지 않으면 그냥 소리나는
대로 적는게 최선입니다. 컴퓨터부터 당장 컴퓨러 비슷하게 적어야
겠군요 :)

번역은 단순히 영문 -> 한글의 1:1 매핑이 아니라 때로는 새 단어의
창조도 필요하다고 봅니다. 단 어느정도 받아들일 수 있는 선에서
이루어져야 겠죠...

익명 사용자의 이미지

environment와 혼동이라면

file/pile

화일 파일과의 혼동과는 어떻게 생각하십니까?

문맥 교환보다는 환경 전환이

더 어울리는거 같은데

어디서 튀어나온지도 모른 문맥교환, 의미조차 알기 어려운거보단

훨씬 더 낫다고 생각하는데

음 전 밑에 글쓴 놈-_-이예요~

익명 사용자의 이미지

어떻게 context - environment의 예가 file - pile로 바뀌는지
모르겠군요. context - 문맥, 환경 - environment라고 쓴 분이
있어서 그렇게 말했는데, file - 파일, () - pile 의 괄호를
채워 주시면 좋겠습니다. 저한테는 이해가 안되는군요.

환경이라 쓰는 것도 나쁘지 않다고 생각합니다. 다만 보는
사람에 따라서 - 저같으면 context와 environment는 다르다고
생각하기 때문에 - 다르겠지요. environment of context라는
말도 있을 수 있는데 그러면 번역이 어떻게 되죠? :)

익명 사용자의 이미지

file/pile은 그냥 흔히 쓰는거 하나 들었을뿐이죠

environment of context는 좀 더 다르게 번역해야겠죠?

익명 사용자의 이미지

환경 전환

context -> 환경, 상태

익명 사용자의 이미지

전산용어를 자기 마음대로 '나쁘지 않게' 번역하면,
읽는 사람들은 자신의 배경 지식을 이용해서 책을 이해하기가 쉬울까요?

전 기본적으로 자의적인 한글화를 해서 번역하지 말았으면 좋겠더군요.
읽다보면 화가 나니깐.

익명 사용자의 이미지

한글 전산용어 사전, 이런 거 없나요?

익명 사용자의 이미지

익명 사용자의 이미지

헛소리긴 하지만 으흠...

플그래머를 위한 101가지 야참꺼리 라는 요리책 같은건 안나오나요 -_-a

*푸데데데데덱~~~*

익명 사용자의 이미지

참 그리고
모든 리눅스 국내 서적은
3분의 1이 설치 관련 사항이더군요.
그거 제발 좀 빼주세요.
화면 캡쳐한건 이것저것 알록달록한데
결국 엔터치란 얘기더군요.
각설하고 본론만 쓰고, 책 분량이 적으면 값좀 싸게해서
많이 팔면 되지 않을까요?
설치 부분 설명된거만 따로 분리해 보으면 2000페이지는
거뜬히 넘을거 같습니다.
출판사 분들 참조좀 해주시면 좋겠네요... ^^

익명 사용자의 이미지

정말 두고두고 본전 뽑는 책은 잘 없는 것 같더군요.
특히 실무 활용서는 더욱 그렇구요,
순수 이론서적은 그래도 좀 두고 두고 보는 편입니다.
그래서 책을 구매할때도 순수 이론서 위주로 사는 편입니다.

제가 바라는 책이 있다면,
하나의 주제를 정해서 끝까지 설명하는 거죠.
독자와 같이 프로젝트를 하는 형태로 말입니다.
비트 시리즈 같은 책이 리눅스 쪽에도 많이 있었으면 합니다.

그리고, 또하나는 인기있는 OpenSources 프로젝트를
설명해주는 서적이 있었으면 합니다.
예를들면, 머 Xmms라던가 OpenH323, QT, GnomeICQ, 등
적당한 크기의 오픈 소스프로젝트 말이죠.
이런 소스들을 책을 통해 설명하는 거죠. ^^

사실 너무 어려워서 스터디 그룹을 만들려고 생각도 해봤는데
실천이 어려웠죠. 참여자의 정성도 그렇구요...

김주경의 이미지

국내서적을 보면..

바이블이랍시고 이것저것 두리뭉실 맛만 보게 하지 깊은 내용이 없는 경우가 많고..
(바이블을 종합세트 개념으로 아는것 같더라구요)

머 깊이 생각하지 말고 그저 이렇게 따라해라 투의 설명..

이건 정말 퇴고 한번도 안했구나 생각이 드는 오타들..

아무리 시장이 국내밖에 안되고 초보자 대상 책이 대다수라고는 하지만..

좀 심한 책들이 많이 보입니다.

원서보다 더 권위있는 국내서적들이 많이 나오고 번역되어 아마존에 상위랭크되는 날이 왔으면 좋겠네요..

익명 사용자의 이미지

없어져야 할 책: 많은 부분을 두루두루 대충대충 넘어가는 책.

제 경우엔 그놈 프로그래밍을 시작하기 위해 책을 뒤져봤더랬는데
그놈 책이라고 나온 것들은 죄다 GTK+의 간단간단한 위젯 몇 개로 책의 팔할을 써버리고
끄트머리에 가서야 GnomeDialog 정도만 떨렁 소개하고 치우더군요.

책이라고 하는 건 최소한 레퍼런스 이상의 무엇이 있어야 한다고 생각합니다.
--
from [ke'izi] : where is [r]?

익명 사용자의 이미지

괜찮은 건 괜찮은데 Wrox가 의외로 이런 경우가 많은 거 같아요. -_ㅡ;

페이지