기본 콘텐츠로 건너뛰기

iOS와 OS X의 메모리 관리 입문서 - ARC, 블록, GCD를 활용한 iOS와 OS X의 메모리 관리와 멀티스레딩 기법

iOS와 OS X의 메모리 관리와 멀티스레딩 기법 - 가즈키 사카모토 & 도모히코 후루모토 지음, OSXDEV 옮김/지&선(지앤선) 이 책은 iOS와 OS X의 메모리 관리에 대한 입문서라고 할 수 있습니다. 개발자가 아니라 하더라도 쉽게 읽고 이해할 수 있을 정도록 쉬운 예제와 비유로 iOS와 OS X의 메모리 관리에 대한 내용을 설명하고 있습니다. 이 책은 당장 실무에서 응용가능한 활용서라기보다는 기본적인 내용에 충실한 입문서의 성격에 더 가깝습니다. 이 책을 보니 안드로이드도 이와 같은 메모리 관리에 대한 입문서가 있었으면 좋겠다는 생각이 들었습니다. 안드로이드 관련 메모리 누수나 메모리 관리에 대한 테스트를 하고 있긴 하지만 안드로이드 메모리 관리에 대한 전반적인 내용을 저는 아직 잘 이해를 못하고 있습니다. 관련 자료를 찾아봐도 쉽게 정리된 사이트는 없더군요. 심지어 구글 개발자 사이트에 가보아도 별다른 내용이 없습니다. 아마도 iOS도 별반 다를 것 없을 것 같은데, 이참에 이런 책이 나와서 참 괜찮다라는 생각이 들었습니다. 다만, 한가지 아쉬운 점은 iOS상에서 메모리 누수나 기타 메모리와 관련된 효율성과 같은 테스트 방법에 대한 소개가 없는 것이 아쉬운 점이네요. 개인적으로 이 책에 5점 만점에 저는 4점을 부여합니다.

K 사 제약이론 컨설팅 후기

지난 한달동안 정말 오랜만에 제약이론의 처음부터 끝까지 컨설팅을 한 뜻깊고 힘든 시간을 가졌습니다. 보안 어쩌구 때문에 자세한 자료를 여기서 공유할 수는 없고, 제약이론을 오랜만에 현장에 적용해서 개선 목표를 도출하는 과정에서 느꼈던 점과 어려웠던 점을 기록으로 남겨볼까 합니다. 사실, 이번 컨설팅은 개선 방안을 도출하는 과제였고, 추후에 정말 수행에 대한 컨설팅이 진행되어서 개선의 효과까지 검증 될 수 있다면 좋을 것 같습니다. 우선 저희 회사는 공식적으로 제약이론 컨설팅을 수행하지 않습니다. 모두들 제약이론을 그다지 신뢰하고 있지 않고 좋게 생각하지도 않습니다. 다른 분들이 워낙 바쁘신 관계로 저 하나 달랑 이 사이트에 방치하신 기념으로 제 독단적 판단에 따라 제약이론 컨설팅을 진행하게 되었습니다. 덕분에 참 힘든 시간을 보냈습니다. 제가 이 사이트에 제약이론을 적용하기로 마음을 먹게 된 이유는 이 사이트가 지난 5년간 무던한 개선 노력에도 개선이 이루어지지 않고 있고, 조직원들이 그런 사실에 피로감과 무력감을 나타내고 있었기 때문입니다. 이런 사이트에는 제 개인적으로 제약이론이 최고의 처방이라고 생각하고 있습니다. 아래는 그런 전차로 제약이론 컨설팅을 하면서 느꼈던 점과 어려웠던 점입니다. 1. 고객의 경력이 너무 높아도 문제입니다. 이론적인 설명을 듣지 않으려고 하시더군요. 덕분에 실제 수행 과정에서 왜 이런 일을 하는지 이해가 부족하다보니 충돌이 좀 많았습니다. 결국에는 수행 과정에서 공감을 어느정도는 하지만 이해가 부족하다보니 확신이 부족해지는 결과가 되었습니다. 제약이론은 수행하는 사람의 확신이 가장 큰 원동력인데 좀 난감합니다. 2. UDE라는 문제점으로부터 CRT를 작성하는데 있어서 그 상세함을 어느정도까지 가져가야할지 정말 힘들었습니다. 시간은 짧고 상세하게 만들기는 힘들어서 조금 압축된 형태로 만들다보니 나중에 검토 과정에서 상세한 내용이 빠져서 인과관계를 잘못 추론하게 되거나 정말 심각한 문제인데 누락되어버리는...

뜨거운 열정, 차가운 열정 그리고 무관심..

벌써 9월이 코앞입니다. 세월이 정말 시속 30km로 내달리고 있습니다. 올 한해 무엇을 했나? 돌아보니 해놓은게 없군요.. OTZ 최근의 몇군데 고객사를 떠돌며 이런저런 일을 했습니다. 이런저런 고객사를 살펴보며 올해처럼 다양한 고객사를 만나보기는 처음이라는 생각이 들었습니다. 이런저런 고객사들을 유형별로 정리해보니 대충 아래처럼 세가지 유형으로 정리할 수 있겠다라는 생각이 들었습니다. 첫번째는 뜨거운 열정을 가진 고객사입니다. 이런 유형의 고객사는 가슴도 뜨겁고 머리도 뜨겁습니다. 무슨 얘기인고 하니 변하고자 하는 열정, 무엇인가를 하고자 하는 열정이 있지만, 자만으로 가득찬 그런 조직이 있습니다. 이런 조직은 참 대하기 껄그럽습니다. 컨설턴트가 무슨 실수는 안하는지 감시(?)하고, 자신들이 이미 알고 있는 내용이나 해본 내용은 거들떠보려고 하지 않습니다. 설득하기도 힘들고, 여러면에서 참 대하기 어렵다는 것이 제 생각입니다. 대체로 이런 조직들은 진심으로 다가가 머리를 차갑게 식히기 위한 여러가지를 시도해야하는 경우라서 참 힘듭니다. 열정이 독이 되는 그런 경우입니다. 이런 조직은 만약에 어떤 시도가 실패하는 경우 아주 빠르게 무관심한 상태로 들어가버리는 경우가 많다는게 제 경험입니다. 두번째는 무관심한 고객사입니다. 이런 고객사는 답이 없습니다. 갑갑합니다.. 세번재는 차가운 열정을 가진 고객사입니다. 이런 유형의 고객사는 가슴은 뜨겁지만 머리는 차갑습니다. 자신들의 문제를 직시하려고 하고, 모든 문제에 대해 컨설턴트의 조언에 귀를 기울이고 냉철하게 판단하려고 합니다. 뜨거운 가슴의 열정이 있기 때문에 무엇을 하든 열심으로 하고 건설적인 제안도 자주 하는 편입니다. 하지만 이런 조직은 자칫 머리가 뜨거워지지 않도록 조심해서 컨설팅을 해야하는 어려움이 있습니다. 무엇인가에 변화와 혁신을 가져오기 위해서는 동기부여, 열...

iOS 휴먼 인터페이스 가이드라인 안내서 - iOS WOW Factor

iOS Wow Factor - 티모시 우드 지음, 이상훈.민경욱 옮김/지&선(지앤선) 안드로이드나 아이폰 앱을 테스트 하는 테스터 중인서 디자인 가이드 문서나 휴먼 인터페이스 가이드라인을 읽어본 사람이 얼마나 될까요? 테스터는 읽어본적이 없다고 친다면, 제대로 읽고 이해하는 디자이너는 얼마나 될까요? 많은 개인 개발자와 회사에서 수도 없는 앱을 쏟아내고 있지만 실제로 이익이 발생하는 앱이 얼마나 될까요? 테스터로서 안드로이드 앱을 테스트하는 방법에 대해서 강의도 하고 있지만, 많은 사람들이 굳이 돈을 써가며 앱을 테스트해야할 이유를 찾기 못하고 있습니다. 제가 만나본 많은 사람들은 앱을 통한 수익이 크지 않다 보니 굳이 디자인 가이드에 따라 앱을 만들거나 테스트해야할 이유를 찾지 못하는 사람들이 많았습니다. 그런데, 달리 생각해보면 그러한 것들을 이해하지 못하고 사용자가 원하는 것을 이해하지 못하고 테스트하지 못한 앱이 과연 성공할수나 있는 것일까요? 처음 이 책을 접했을 때 iOS 휴먼 인터페이스 가이드라인에 대한 내용과 중요성이 언급되어 있어서 반가움을 금치 못했습니다. 사실 저도 iOS 휴먼 인터페이스 가이드라인이나 안드로이드의 디자인 가이드 문서를 모두 읽고 이해하지 못하고 있습니다. 여러 이유가 있지만 사실 읽을 분량이 적지 않은 것도 이유겠지요. 시중에 이러한 가이드 문서들에 대한 가이드가 일부 나와 있긴 하지만 내용에 대해 만족할만한 책이 없어서 이 책이 해당 가이드라인에 대한 충실한 설명서인가? 라는 기대를 가지고 읽어보았습니다. 결론은 책의 내용 자체는 매우 훌륭합니다. 우리가 그동안 중요하게 생각하지 못했던 많은 것들에 대한 많은 것들이 담겨 있습니다. 하지만 이제 막 아이폰의 앱을 만드는 사람에게는 내용이나 사용된 단어가 생경할 수 있다고 생각됩니다. 어떤 구체적인 가이드나 내용, 예제보다는 가이드의 성격이 강하다보니 이해하기 쉽지 않을 수 있을 것 같습니다. 반면 휴먼 인터페이스...

테스터는 창조적 인간형이 어울리지 않을지도 모른다??

최근 주변을 보면 너도나도 모두 창조적 인간이 되어야 한다고 난리입니다. 정부가 하는 꼬라지를 보면.. 무슨 스티브 잡스 같은 인간을 육성(이게 남새 기르듯 기르면 길러지는건지..)한답시고 꼴같지도 않은 지랄이 풍년이고... 어디서 듣도 보도 못한 사람들이 너도 나도 저마다의 커리큘럼을 쏟아대면서 당장 창조적 인간이 되지 않으면 큰일이 나는 것처럼 호들갑을 떨며 한 몫 챙겨보려고 혈안입니다. 하지만, 입시 위주로 찌들대로 찌들어버린 공교육과 사교육의 한복판에서 과연 1~2년 난리 굿을 친다고 얼마나 사람들이 창조적이 될지는 글쎄요.. 그런데, 테스터로써 나도 과연 창조적인 인간이 되어야 하는걸까? 하고 곰곰히 생각해보았습니다. 결론은.. 머. 나름 일정 정도의 창의성은 테스터에게도 필요하지만 그게 꼭 중요해보이지는 않습니다. 소프트웨어를 개발하는 조직의 모든 이해관계자들은 누구나 창조적인 인간이 되어야 하는게 맞습니다. 일단은 무(?)에서 유를 창조해내는 작업이 소프트웨어 개발이니까요.. 아키텍처, 개발자, 기획자, 디자이너 등등 모두 새로운 것을 만들어내는 사람들입니다. 그런데, 테스터는 아주 특이하게 이들과는 정 반대의 위치를 점하고 있습니다. 테스터는 만들어진 것을 부수고, 분석하고, 분해해서 확인을 하는 사람들입니다. 물론, 테스터도 새로운 자동화 도구나 기법, 설계 기법, 테스트 방법론 등 일부 창조적인 작업을 하기도 하지만 대체적으로 이러한 작업들은 보다 잘 부수고, 잘 분석하고, 잘 분해하기 위한 방법들이지 이것이 주된 활동이 되지는 않습니다. 특히나 테스터가 창조적인 인간과는 거리가 멀어야 하는 이유로 생각나는 것은 사람은 기본적으로 자기가 만든것에 무한한 애착을 가지는 경우가 많습니다. 그 만화에 보면 자기가 만든 인조인간에게 애착을 가지다 사랑에 빠지거나 살해 당하거나 머 그런 경우도 많죠.. 사실 테스트의 기본 원칙 중 살충제 패러독스라는 테스트 케이스에 대한 이해관계자와 제품의 내성 증가의...