Media Log

대한민국에는 소프트웨어가 없다 - 8점
김익환 지음/미래의창

소프트웨어 개발의 모든 것글로벌 소프트웨어를 꿈꾸다를 읽으면서, 김익환 선생님의 책에 완전히 빠져버렸다.

이 책은 2003년 12월에 출간되었는데, 동네 도서관에도 없길래 알라딘에서 중고책으로 4000원에 사버렸다.

이 책 역시 다른 두 책들 만큼이나 재밌게 읽었다.
글을 읽기 쉽게 쓰는 재주가 있는건지, 언제나 그의 책은 달콤하게 술술 읽혀서 좋다.

지금보다 젊었을 때의 글이라서 그런지, 조금 과격하게 말하는 것들이 글에서 조금씩 드러난다. 지금은 상당히 온화한 인상을 가지고 계신데, 그 당시에는 꽤나 무서웠을 것 같다는 생각이 들었다.

'소프트웨어 개발의 모든 것'이나 '글로벌 소프트웨어를 꿈꾸다'에 비하면 이 책의 내용이 조금 더 가볍게 읽을 수 있다.
영어에 대한 조언들이나 실리콘 밸리의 문화같은 내용들도 있다.

나는 여지껏 회사를 한번도 옮겨본 적이 없는데, 이런 책에서나마 다른 회사의 개발 환경이나 문화를 엿볼수가 있어서 참 좋았다.

이 책에서 말하는 내용은 10년 가까이 지난 그의 새 책에서 말하는 내용과 똑같다.
아마도 그의 생각과 경험들이 바로 정답이고 바뀌지 않는 진리이기 때문일지도 모르겠다.

책 중간에, 프로그래머들에게는 빌 게이츠 다음으로 유명한 또 하나의 '빌'인 빌 조이의 이야기도 조금 나오는데, 너무 짧아서 아쉬웠다. 아마 Sun에 계셨을 때 한번쯤 마주쳐보지 않았을까. 빌 조이의 비하인드 스토리같은 내용을 블로그 같은 곳에 써준다면 너무나 재밌을 것 같다.

다른 두 책들과 다른 점 중의 하나는 이 책의 마지막에는 진짜 코드도 있다는 것이다. 책의 서두에서 그는 실전 비법이라고 언급하면서, 그 비법 중 한가지만이라도 알고 있으면 꽤 수준 높은 프로그래머라고 말을 하였다.
도대체 무슨 내용일까, 나는 모르면 어쩌지 하는 마음에 가슴이 쿵쾅 쿵쾅 거리면서 읽었는데, 너무나도 간단한 내용들이어서 조금 실망스럽기는 했다. 진지한 마음가짐으로 프로그래밍을 생각해왔던 사람들에게는 아마 시시할지도 모르겠다. 만약 그런 비법들을 모아놓은 책을 원한다면 내가 아는 책은 딱 하나, Code Complete 뿐이다.

나도 그의 바램처럼 대한민국에서 좋은 글로벌 소프트웨어 기업들이 많이 나오기를 바라고 있다.
앞으로도 재미있고 유익한 책을 많이 써주셨으면 좋겠다.
저작자 표시 비영리 동일 조건 변경 허락
신고
  1. 고딩개발자 at 2011.01.07 22:16 신고 [edit/del]

    꿈이 소프트웨어 회사 창업인 고등학생입니다.
    저책을 읽어 보진 않았지만, 우리나라 개발자를 위한 책을 보면
    우리나라의 소프트웨어는 일단 돌아가고 보자라는 식의 개념을 가지고 만드는것 같네요(모든회사가 그런건 아닙니다.)
    버그픽스도 한지않고, 테스트도 하지않고, 오직 S/W의 출시날짜에맞춰서.....

    Reply
    • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2011.01.08 00:08 신고 [edit/del]

      네 모든 회사가 그런건 아닐꺼에요.
      저는 오히려 형상관리툴도 안쓰고 테스트도 안하고 제품 릴리즈하는 회사가 진짜 얼마나 있을까 싶은데.. 금방 망하겠죠.
      잘하고 있는 좋은 회사들도 많아요.^^

submit
글로벌 소프트웨어를 꿈꾸다 - 9점
김익환 지음/한빛미디어
얼마전에 나온 김익환 선생님의 새 책이다.

이전 책인 소프트웨어 개발의 모든 것과 크게 다른 내용은 아니다. 오히려 이 책에서는 기술적인 사항이나 세부적인 요건들에 대해서는 다루지 않고, 소프트웨어 공학에 있어서의 올바른 그림만을 제시해주고 있다.

그렇기 때문에 이슈 관리시스템이나 소스 관리 시스템 같은 내용을 다루면서도 실제로 어떤 도구들이 있는지에 대해서는 언급하지 않는다.

언제부턴가 나는 어떤 소프트웨어를 선택해야 할 일이 생겼을 때, 항상 위키피디아를 먼저 찾아보게 되었는데 이런 이슈, 소스 관리 시스템을 선택할 때도 위키피디아가 어느 정도 도움이 될 수 있을 것이다. 이 책에서 이 내용을 설명해주지 않아 나처럼 아쉬움이 느껴졌다면 아래 위키피디아 링크에서 해소할 수 있기를 바란다.

이슈관리 시스템
소스관리 시스템

나는 이슈 트래커는 맨티스, 버전 콘트롤은 VSS와 SVN밖에 써본 적이 없기 때문에 어떤 것들이 좋다고 추천해주지는 못하겠다. 위 링크에서 여러가지 조건들을 비교해보고 자신의 상황에 맞는 도구를 선택하면 되겠다.
-사실 어떤 소프트웨어를 선택할 때 내 첫번째 우선순위는 지원되는 기능들보다 해당 프로젝트가 오픈소스인지 아닌지이다. 나는 오픈소스를 무척이나 선호하는데 영감님들이 잔뜩 있는 대기업에 다녔더라면 허구헌날 깨지고 다녔을지도 모르겠다.

다시 책 이야기로 돌아와서, 이 책은 SRS 같은 문서 작성에 대해서 이야기 할 때도 그것의 중요성에 대해서만 다루지 실제로 문서를 어떻게 작성해야 하는지에 대해서는 설명하지 않는다.

그런 기법들을 배우려면 '소프트웨어 개발의 모든 것'이나 다른 소프트웨어 공학 책들을 찾아봐야 할 것이다.

비록 기술적인 내용은 없다만, 이 책에서 말하는 내용들은 모두 공감이 많이 되고 옳은 이야기들만 있기 때문에 충분히 읽어볼만한 가치가 있다.
편하게 개발해오면서 해이해졌던 마음 가짐을 다시 조일 수 있는 계기도 되기 때문에 이런 좋은 충고를 해주는 책들은 주기적으로 읽어주어야 한다. -그런 책 중 가장 좋았던 책은 실용주의 프로그래머였다.

여러 우화나 인용을 제시한 후 그것과 비교하면서 독자를 설득해 나가는 글쓰기 방식도 인상적이다.

이 책에서 말하는 점들을 간추려서 적어보았다.
글에서 묻혀나는 뉘앙스들을 내가 느낀대로 적었기 때문에, 오해한 점도 껴 있을 수 있겠다.

  • 소프트웨어 아키텍쳐는 코더보다 고급 인력이다.
  • 소프트웨어 공학은 뻥이 아니다. 즉, 이를 (잘) 사용하면 개발 시간이 (정말로) 더 단축된다.
  • 그렇다고는 해도 생각없이 무작정 따라하면 쫄딱 망한다.
  • 코딩은 개발의 일부이며, 스펙 작성과 설계를 모두 할 줄 알아야 소프트웨어 개발자라고 할 수 있다.
  • 그리고 코딩보다는 스펙 작성과 설계 능력이 더 중요하고 고급 기술(돈도 많이 버는) 이다.
  • 난이도는 코딩 < 설계 < 스펙 순이다.
  • 중요성도 코딩 < 설계 < 스펙 순이다.
  • 사실 코딩능력은 아무것도 아니다.
  • 소프트웨어를 설계하는데 있어서 가장 중요한 것은 컴포넌트와 인터페이스를 잘 정의하는 것이다.

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. Favicon of http://revirth.me BlogIcon tack at 2010.12.11 13:31 신고 [edit/del]

    그르게요.. 저도 SRS에 대한 관심은 높아졌지만 정작 뭘 어찌 해야 할지는 ㅎㅎㅎ

    Reply

submit
소프트웨어 개발의 모든 것 - 9점
김익환.전규현 지음/페가수스
소프트웨어 개발의 모든 것이라 제목이 붙긴 했다만 물론 제목은 뻥이다.
어떻게 이 얇은 책이 소프트웨어 개발의 모든 것을 다루겠는가.

사실은 소프트웨어 공학의 모든 것이 책 내용과 조금 더 어울리긴 하지만 그렇게 이름지었으면 난 죽을 때까지 이 책을 안 읽었을 것이다.

나는 컴퓨터 과학의 대부분의 분야가 아주 재밌고 흥미롭지만 소프트웨어 공학 만큼은 질색이다.
그럼에도 불구하고 이 책은 꽤나 재밌게 잘 쓰여졌다. 내가 읽은 -몇 권 안되긴 하지만- 소프트웨어 공학 책 중에서는 가장 재밌는 책이었다. 스티브 맥코넬의 책보다도 재밌다! -물론 Code Complete는 빼고.

이 책은 개발자뿐만이 아니라 프로젝트 매니저, 기획자, 테스터, 그리고 심지어 세일즈맨까지도 읽어보면 도움이 되는 책이다.

얼마 전에 저자의 블로그에서 재밌는 포스팅을 읽었다.

하수
소스코드관리시스템을 거의 제대로 쓰지 못하는 경우, 오늘 고치고 있는 소스코드를 수동으로 하나씩 지워서 원래 버전을 만들어냅니다. 이러한 경우는 믿기 힘들겠지만 제가 컨설팅을 하면서 많은 회사들이 이렇게 하고 있다는 것을 접했습니다. 이렇게 원래 버전을 만들어서 Hotfix를 만들어서 내보낸 후에 다시 재작업을 합니다.

중수
이보다 조금더 나은 경우, 원래 고치고 있던 소스코드의 디렉토리를 임시로 백업 받아 놓고 소스코드관리시스템에 있는 어제 버전의 소스코드를 다시 Check out합니다. 이렇게 Check out한 소스코드를 가지고 Hotfix를 만들어서 내보내고 오늘 작업하던 백업을 받아 놓은 소스코드와 Merge tool을 이용해서 Merge를 한 후에 정기 업데이트 버전을 만들어서 내보내는 방법입니다. 아까보다는 조금 나아 졌지만, 여전히 수작업에 많이 의존을 하고 귀찮은 작업들을 해줘야 합니다.

고수
Subversion등의 소스코드 관리시스템을 제대로 사용한다면 이보다 좀더 손쉽습니다.
우선 어제 릴리즈를 한 소스코드의 Baseline(Tag)에서 Hotfix용 브랜치를 만듭니다. 기존에 개발하고 있던 디렉터리는 그대로 놔두고 새로운 디렉터리에 Hotfix를 Check out 받습니다. 보고된 버그를 수정하여 자동화된 빌드스크립트를 이용해서 Hotfix를 만들어내고 업데이트에 올립니다. 정상적으로 Hotfix가 배포된 것을 확인하고 Hotfix 브랜치는 Trunk로 Merge를 합니다. 이때 3Way Merge 툴을 이용하면 됩니다.

나는 처음 회사에 들어갔을 때는 하수였고 지금은 중수이다.
저자는 하수가 하는 짓을 믿기 힘든 짓이라 말하지만, 형상관리툴 사용을 잘 모르는 입장에서 보면 사실 그리 믿기 힘든 일도 아니다. 똥줄이 바짝 타는 상황이 생기면 믿기 힘든 무식한 일도 하게 되는 법이다. -핫픽스를 만든다는 것이 바로 그 똥줄이 타들어가는 상황이기도 하다.

시간이 좀 흘러서 고수가 하는 저 방법을 알게 되었음에도 불구하고 계속 중수의 방법을 고수해 온 것은 전적으로 나의 게으름 때문이었다. 저렇게 핫픽스를 만들어내야 하는 상황은 자주 오지 않기 때문에 나중에 배워야지하고는 계속 미루고 있었는데, 위 글을 읽으면서 몹시 부끄러움을 느꼈다.

그래서 잠시 시간을 내서 이것 저것 실험해보며 테스트를 해봤는데, 그동안 왜 그토록 게으름을 부렸을까 싶을 정도로 쉽게 해낼 수 있었다. -Subversion과 KDiff3의 개발자들 그리고 전규현씨께 감사한다. :-)

처음에는 정말 재미있게 읽었다.
하지만 폭포수 모델하고 SRS(요구사항 명세)에 대해서 설명하기 시작할 때는 읽다가 읽다가 결국 포기해버렸다.
저자가 지금 이 글을 보면 아니 그 중요한 부분을 그냥 넘어가면 어떻하나 하고 안쓰러워 할 것이 눈에 훤할 정도로 SRS의 중요성에 대해 입에 침이 닳도록 설명하지만, 그래도 정말 어쩔 수 없었다.

이 책의 내용에서 아쉬운 점 하나는 내가 가장 궁금해하는 내용이 빠졌다는 것이다.

나는 마이크로소프트 같은 커다랗고 프로세스가 잘 정립된 회사의 형상 관리툴의 소스트리를 보고 싶다.
그들이 모듈을 어떤 식으로 분리하고 어떤 구조로 트리를 구성하는지, 중복되는 코드들을 어떤 식으로 제거하고 또 공유하는지, 체크인 되는 코드의 코멘팅은 어떤 규칙으로 하는지 등이 너무 너무 궁금하다. 1시간 만이라도 들어가서 차근차근 살펴볼 수 있다면 내 실력은 훨씬 나아질 것이다.

이 책의 저자 중 김익환 선생님께서는 마이크로소프트에 버금가는 훌륭한 회사들에서 일했었는데, 그런 내용도 함께 알려주었더라면 나는 이 책에 주저 없이 별 5개를 줬을 것이다!

...물론 그래도 SRS는 싫다.

신고
  1. Favicon of http://dol9.tistory.com BlogIcon 오산돌구 at 2010.06.16 16:22 신고 [edit/del]

    하수인 저로서는 잠시 시간을내어 핫픽스관련 테스트를 하셨다는 글귀에
    ㅎㄷㄷ 부러움이...ㅎ
    무엇을 하든 게으름이 가장 큰 적인것같습니다.
    좋은글 잘 읽었습니다.

    Reply
  2. BlogIcon 김용혁 at 2014.04.19 14:11 신고 [edit/del]

    어제 전규현님 세미나 들었어요 책은 안 읽어봤지만 한번 읽어봐야겠네요 소프트웨어공학에 관심이 생겨서 ㅋㅋ

    Reply

submit