ux/ui의 10가지 심리학 법칙 읽다가, 다행히 누락된 이 후기를 작성했습니다. 이 책은 원서로도 대충 읽었는데, 다시 정리하고 이 내용을 제 삶에 적용해보는 효과를 보고 싶네요! 다만, 명성에 경도되어 좋은 책인지 어떤지에 대해선... ... ... 읽고 판단하셨으면 좋겠네요!
_______
2007/01/21
왜 읽게 되었을까?
순번까지 붙여야 할 정도로 많은 이유(?) 가 있긴 했다. 첫째로, 저자의 서문을 읽었다면 읽을 수 밖에 없는 책. 덧붙어 옮긴이가 쓴 서문의 수식은 매력적이기까지 했던 것도 유혹(?)을 뿌리치지 못했다.
단순화하기=기본에 충실하기
둘째로, [란체스터의 법칙], [설득의 심릭학], [엔트로피], [롱테일의 경제학], [링크Linked], [블링크], [티핑포인트], [스마트초이스], [선택] 등등의 책을 통해 법칙化 된 것을 읽으면서 간단 명료함이 좋았고, 저자가 말하는 법칙의 생성 과정을 상상해 보는 것도 좋았기 때문이다. 네이밍을 하고 자신의 주장에 맞게 의견을 제시하고 예를 제시하는 것 아름답기 까지 하다.( 브랜드 관련 책도 읽어야 되는데^^) 그랬기에 읽어야 했다. 특히 블링크를 읽어본 독자라면 유사점을 발견할 수도 있지 않을까......
셋째로는 프로그래머로서 운영체제중 하나인 UNIX의 철학( http://en.wikipedia.org/wiki/Unix_philosophy )에서 이전 부터 익히고 있던 small is beautiful을 알았기에 읽고 싶었던 것이다. XP(Extreme Programming), Agile 쪽 부분에서 말하는 것들과 연결될 수 있을 것 같았다.
넷째로는 저자보다 옮긴이의 명성 때문이었다. 옮긴이는 공학과 예술이란 상반된 듯한 양 분야를 자유자재로 넘다들며 치열함과 창의성의 극한을 보여주어 학생들의 감탄을 자아냈던 마에다 교수님의 책을 한국에 소개하게 된 것을 영광스럽게 생각한다. p11은 저자를 이해할 수 있는 단서가 되었고, [컨버전스]라는 트렌드를 다시금 떠올리게 한 대목이기도 했다.
그럼, 어떻게 읽었는가?
서문에서 저자는 "단순함에 대한 해답을 제시하지 않는다. 대신 단순함과 관련된 많은 질문이 담겨 있다." 란 방향을 말하고 있다. 제대로 된 질문이 주는 효과를 알기에 이해가 되기도 했다.
거기에 저자가 말하는 10가지는 저자 것이고 보편성을 얻기 위해선, 저자와 대화를 시도하며 읽었다. 후반부에 저자 역시 밝힌대로 앞 부분에 제시된 것은 명쾌했지만, 뒷부분의 것은 단순함이란 것과 연결 인과가 약했다. [새로운 미래가 온다]에서 제시한 내용을 읽었다면 후반부에 언급된 주장에 대해 좀더 나은 이해가 이루어질 수 있을 것이다.
또한 단순함에 관한 이야기를 하는 두꺼운 책은 아니다 싶어 얇게 출간했다는 이야기에 나도 모르게 미소짓다. 그랬기에 2-3시간이면 완독할 분량임에도 물리적 독서시간을 길게 했다. 출퇴근하는 지하철에서 한 부분을 읽고, 멍하니 생각해 보는 시간을 가져보는 방식으로 읽었다.
그럼 내용은 어떨까?
< 첫페이지에 있는 아이콘들 - 그림과 법칙이 연관되는데 한참 걸렸다.^^;>
그는 아이콘을 연상해 읽어내기를 바랬던 것 같다. 읽어보면 될 내용을 업급할 필요는 없겠고(사실 단순하기도 해서), 그가 말하는 10가지 법칙[Ten Laws]가 시험에 나오지도 않는데 외우는 수고따위는 할 필요가 없는 것이다. 그의 통찰을 나누고, 생각의 힘을 키우고 그러는 것이 낫지 않겠나 싶다. 또한 사이트를 통해서 저자와 대화할 수 있으니 ... URL이 더 큰 정보가 될 것으로 본다. http://lawsofsimplicity.com
과연 읽을 만한가? 시간을 투자해, 돈을 투자해 재미나고, 예쁜 책이다. 내용도 깔끔하다. 과장 이상의 레벨에게 적합지 않을까 싶다. 업무나 과정에서 오는 복잡도에 힘겨워 한다면 단순함의 법칙을 무기로 나은 결과물을 만들 힌트를 제공할 것이다. 또한, 현상에서 법칙을 추출해내고자 하는 사람 모두에게도 도움이 되겠지만.
책에서 애매했던 부분은?
마지막 부분에 이상하게 스토리텔링 책들이 가지는 두어 페이지가 애매했다. 화두를 던진다는 의도에서 이해는 되지만 생뚱맞다고 생각되는 건 나뿐일까!
줄긋기
디지털 기술은 삶의 군더더기를 없애고 기본에 충실할 수 있게 해주는 수단일 뿐이다. 디지털오디오 CD는 소수에게만 허용됐던 비엔나 필하모니 오케스트라의 연주를 저렴한 가격에 실제와 매우 근접한 품질로 감상하는 것을 가능케 했다. p10 (옮긴이의 서문에서) => [손이 지배하는 세상Die Hand]를 읽고 있었기에 좀더 깊이 이해할 수 있었다.
The Pragmatic Programmers, LLC (TPP)에서 나온 책이라 눈이 갔다. 원제와 우리나라 번역서의 제목은 아쉽다만, 전산이 아닌 다른 비전공자가 컴퓨터 언어를 배우기 위해 선택한 언어가 파이썬이라면 나쁘지 않는, 추천 할 책이다. 메모리 구조부터 하나 하나 설명하고 있고, 원서 페이지에 가보니 연습문제 답도 pdf로 올라와 있더라! 이거 하나면 인공지능 부분에 R 과 함께 처리하는 부분에 어려운게 전혀 없을 듯.
인공지능 프젝을 한번이라도 하신 분이 이야기 하는 줄 알았는데, 그렇지가 않은지, 내용이 붕떠 있는 느낌이다. 새롭지 않고, 인공지능이 거짓말에 관계되는 것 이야기할 때 정말 멘붕인게, 코팅한 개발자가 training data 로 괜찮은 모델이 나오면 그것을 가지고 돌리면 되는게 현재 인공지능이라 생각하는데,
입문서라면 정말 전문가가 써야 되는데, 불우이웃 기부라는 좋은 의도와 다르게 미래의료에 대한 상상 정도로 끝나지 않았나 하는 생각이 들어 아쉽다. 전자책으로 나온게 작년 7월21일인데, 일론 머스크이야기 정도는 연결될 줄 알았는데... 많이 아쉽다.
코드 작성을 위해 고용된 대다수 프로그래머는 동작하는 소프트웨어를 납품합니다. 평범한 프로그래머와 뛰어난 프로그래머는 후속 작업자를 얼마나 더 편하게 해주는가에서 차이가 납니다.
옮긴이의 말에서 책을 너무 강조한다. 프젝에 들어가 실전에서 배우는게 최고인데, 뭐 우선 이 책을 잘보란 이야기도 맞겠지만, 암묵지를 책을 통해 전달받기는 많이 힘들다. 1-2년 정도 코딩한 경험을 가진 사람이라면 이 책을 통해 좀 단단해지는 느낌, 한글판에 나온 글로는 레벨업시킬 수 있을 듯.
바보도 컴퓨터가 이해하는 코드는 작성할 수 있다. 훌륭한 프로그래머는 인간이 이해하는 코드를 작성한다. - 마틴 파울러 Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler.
노가다(?) 했습니다. 참고 문헌 전자문서를 보는데, 책 열어두고 보기 귀찮아서 링크 다 확인했습니다. keep에 복사해두고 저만 보려고 하다가... 이런거라도^^;
주석
주석: 반갑습니다!
* 오라클에서 이미 자바9를 출시했습니다. 이 책의 모든 코드는 자바 9에서도 유효하니 안심하세요.
역주 2019년 9월 자바 13이 출시되었고 오라클 사는 매년 3월과 9월에 새로운 자바 버전을 출시하고 있습니다. 2020년 3월에는 자바 14, 9월에는 자바 15가 출시될 예정입니다. => 2020년3월23일 현재 java 16 릴리즈 됨. 11버전 이후 17버전이 장기 지원이니, 17버전 되면 또 재학습해야겠군요!
이 책은 나에게 아주 좋았다. 그래서 읽기를 미뤘다. 왜냐면 아껴먹고 싶은 맘, 이게 실수다. 그렇게 알았다. 내생각엔 [지적 대화를 위한 넓고 얕은 지식] 이상 일줄 알았다. 그런데 역시 내것화 시키는 부분에서 약했다는 것을 나중에 알았기에... 요약은 정말 좋았는데.
그래도 이 책 내용 정도는 제대로 내것화 시켜둬야... 안에서 찾기 전에 내 밖에서 타인의 이야길 들어보자!
파트1
행복happiness
=> 행복은 목적이 아님만 알면 된다! 마왕이 이야기 했듯 태어난 것으로 모든게 다 이뤘으니, 행복하면 된다는 것으로 이해했고, 괜한 질문을 안하고 있는 상태다. 그 바탕엔 생활과 생존의 파동에서 생존보단 생활에 집중!
100년 인생에 50년 살고 나서 할 이야기가 있음을, 그러나 말하기 머뭇거리는, 20대가 어리다고 무시한다는게 아니라 호기심을 잃지 않고 50년은 살아보고 이야기 하자는 것. 논의하지 말자는게 아니라 어리면, 그냥 삶의 무게에 대해선 생각하지 말고 나아가자! (나에게 하는 말일수도)
오라클 제품은 오라클에서 만든 교재를 보면 되는데 굳이 이런 책을 볼 필요가 있을까? 특히 현업 도메인에 관계된 암묵지라면 또 모르겠는데 말이지, 그래도 구입안하고 빌려 읽으니 생략.
oracle express edtion이 나오면서 오라클 운영이 아닌 오라클을 데이터베이스로 개발할 프로그래머에겐 그런 교재보단 이런 책이 더 쉽게 이해할 수 있는 바탕이 되게 해주겠군! 건데 웬만해선 오라클을 윈도 계열 보단 유닉스나 리눅스에서 운영할테고 운영이나 튜닝은 또 다른 분야인데, 역자는 이 책부터 보고 오라클 실무 테크닉을 보라는 추천을 하는데, 난 잉! 했다.
아무말 대잔치
적확한 접근을 해보면, 오라클을 사용한다는 건 그래도 중견 기업은 될테고 그렇다면 운영과 튜닝은 따로 할 사람이 있을테고, db 관련 종사자 말고 오라클 접할 사람은 sql문을 잘하는게 베스트라고 보는게 정상적이다. 거기에 sql 표준에서 통계나 성능에 관련된 추가 함수나 키워드를 제대로 배우는게 나을텐데... 물론 개발자라면 그바탕엔 odbc/jdbc 표준에 맞는 반복적인 코드 부분이야 기본이다. 난 odbc/mfc로 했었고, java/jdbc 으로 구현했고, 이젠 mybatis도 현업해서 적용해본 입장에서 데이터베이스 접근 쿼리는 달라지지만 넓게 보면 odbc에서 벗어나지 않는다는 것을 이해했다. jpa로 넘어오면서 java로 query를 대체한다고 하고, 게시판 모듈 같은데 더 빨라졌다고 하지만 궁극에 접근해서 결과값 가져와 보여주려면 oracle native sql문이 최고라는 생각엔 변함없다.
당연히 이런 경험을 이기고자 하기에 지금 시작하는 개발자는 그걸 건너뛴 그무엇이라면 sql문보단 jpa라고 하지만 그것 역시 환경을 잘 이해하고 구현하지 않으면 사이드 이펙트가 아주 많은 것 같더라. 개인적으로 인프런이란 곳에서 jpa 두강좌를 개인비용으론 고가에 들었지만, 딱 입문 수준이었고, join했을 경우의 성능 부분도 메모리에 로딩이 되던데 gc가 잘 처리 되는 것을 이해하지 못하면. 여기까지. 거기에 난 sql문을 그런대로 아니 jpa보단 mybatis가 제품 딜리버리 하는 데 개발시간 면에서 낫기 때문이기도 하다. 알고 있는 것을 잊어버릴 필요는 없으니.
어제 올린 박재호씨의 영상에서 레거시 정의를 현재 돈을 벌어다 주는 시스템이라고 했는데, 이런 측면으로 이해하면 나이먹어 일자리 고민보단, 새로운 것 배우는 것도 좋지만 현재 시스템을 잘 운영하는 것도 아주 쓸모있는, 가치 있는 일이란 걸...
책을 보니 디스크 부터 나옴. 아흐 SSD 시대인데 ㅋㅋ. 거기에 하드디스크 물리적 구조부터 설명하는 건 오버라고 본다. 왜냐면 물리적인 하드디스크를 이해 안해도 잘 작동 되게 오라클 개발자들이 잘 만들었고, 그것을 개념화한 교재도 있는데, 저런 설명은 굳이. 오라클 9 수업 돈내고 들었기에 이런 말은 해도 되겠지?! 들었다고 다 아는 건 아니지만.
SQL*Plus
'여러 사용자나 프로그램이 데이터베이서의 데이터를 공유하고 있다' -p19 =>db 사용자가 multi user라는 건 당연한 이야기인데,
오라클은 서버 프로세스라고 불리는 SQL문을 처리하는 프로세스와 백그라운드 프로세스라고 불리느, 주로 서버 프로세스를 도와주는 프로세스로 구성되어 있습니다.-p24 => 이것은 오라클 만든 사람이 이렇게 설계했다고 생각하는게 더쉬운 이해가 된다.
sql문의 수신
sql문의 파싱
데이터 읽기
데이터 기록
sql문의 결과 회신
로그 기록
각종 정리
로그 보관
오라클에서 데이터 캐시(버퍼 캐시)
오라클은 '블록'이라고 하는 단위로 데이터를 관리
SGA
PGA
DB_CACHE_SIZE
LRU알고리즘
DBWR 프로세스
hint 예) /* + index (A B) */ A 테이블의 B라고 하는 인덱스를 사용하라는 뜻.
옵티마이저(파서)가 sql문을 분석하고 '실행 계획(excute plan)'이라고 하는 처리 방법을 생성해 주기 때문이다.
오라클에서는 처리 시간이나 I/O 횟수를 예측하기 위해서 '비용'이라고 불리는 수치를 이용합니다. 비용을 단순하게 이야기하며, '처리에 필요하다고 생각되는 시간 또는 자원 사용량'입니다.
