Media Log

거꾸로 배우는 소프트웨어 개발 - 8점
이호종 지음/로드북
소프트웨어 개발의 모든 것과 비슷한 종류의 책이며 아래 내용들을 다룬다.
재미있는 편이며, 대체로 그 내용에 동의한다. 책의 완성도는 소프트웨어 개발의 모든 것이 좀 더 낫다고 생각한다.

  • 개발 표준
    • 코딩 스타일
    • 공통 라이브러리/프레임워크
    • 문서화 표준
  • 개발 기반
    • 소스 코드 관리 시스템
    • 이슈 트래커
    • 개발/테스트/운영서버 분리
    • 지속적 통합
  • 개발 기법
    • 단위 테스트
    • TDD
    • 리팩터링
  • 개발 방법
    • 폭포수 vs. 애자일
    • 조직론.
    • 스크럼.
    • 협업.
    • 개발 관리.

위의 내용들은 소프트웨어 개발에 있어서 아주 중요한 내용들이지만 학생 때는 쉽게 접하지 못하는 내용들이다. 보통은 처음 회사에 들어가고 나서 저런 것들을 배우게 되는데, 아주 잘하는 회사도 있고 그저 그런 회사도 있기 때문에 회사를 잘 골라 들어가는 것이 중요하다.

취업이 안된다고 초조한 마음에 우선 1, 2년만 배우고 좋은 회사로 옮겨야지 하고는 저기 구로공단에 이름 없는 아무 회사나 들어가서는 안된다는 뜻이다. - 구로공단은 그냥 예로만 들었을 뿐 나쁜 의도는 없다.

그런 작은 회사들 중에는 소스코드 관리 툴도 사용하지 않는 곳이 잔뜩 하기 때문에 그런 곳에 들어가면 고생은 고생대로 하고 시간만 낭비하는 셈이다.

이 책에서 나오는 내용들을 가장 쉽고 빠르게 터득하고 싶은 방법은 이런 시스템이 잘 구축되어 있는 회사에 들아가는 것이다. 어떤 회사가 잘하는 회사인지 잘 모르겠다면 어느 정도 이름을 많이 들어봤고 개발자 수가 많은 회사를 찍는 것이 맞을 확률이 높다.
만일 그런 회사에 다니고 있지 않다면 회사를 옮기는 것도 좋다고 생각한다. 스스로 공부하면서 배울 수도 있겠지만 쉽지는 않을 것이다. 서버를 구성하는 것도 몹시 귀찮은 일인데다가, 혼자서 이슈 트래커에 이슈를 기록하고 완료하면 (왕따놀이를 하는 것도 아니고) 도대체 무슨 재미로 하나.

아래 위키 페이지에 있는 회사들은 적어도 소스코드 형상 관리툴 정도는 모두 사용할 것이라 생각한다.
대한민국의 IT기업

반면에 CI 서버를 구성해놓고, 코드 커버리지 측정이나 정적 분석 등을 자동으로 수행 하고 있는 회사는 여전히 별로 없는 것 같다. NHN에서는 위 목차의 내용을 모두 하고 있고 심지어는 코드의 라인 수 까지도 체크해서 라인이 얼마가 늘었고 라인당 버그수가 얼마인지 까지 보고 되는데 이건 얼핏 보면 한심하고 쓸데 없어 보이지만, 내 생각은 안하는 것보다는 훨씬 낫다이다.

잘 구축된 CI 서버는 마치 똑똑한 군사와도 같다. 전쟁의 상황에 대해서 지속적으로 보고 해주고 위험한 일이 발생하면 적절한 조언도 해주는 것이다.

어떤 사람들은 위에서 나오는 내용들을 꼭 대학교 커리큘럼에 넣어야 한다고 주장하는데, 거기에는 별로 동의하지 않는다. 이 많은 과정을 쑤셔넣으려면 그만큼을 빼내야 하는데 무슨 과목을 빼낼 셈인가.

소프트웨어 개발의 모든 것 - 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는 싫다.