2008년 11월 24일 월요일

The 12 Best Questions for Team Members

제가 구독하는 블로그에서 유용한 정보가 있어서 소개를 할까합니다.
이 설문은 First, Break All the Rules: What the World's Greatest Managers Do Differently (Marcus Buckingham and Curt Coffman)에 소개가 되어 있습니다.

아래 12가지 설문을 통해서 직업의 만족도, 상사와의 관계, 자기계발등 조직의 몰입도를 측정할 수 있습니다.
IT나 Software 조직에 국한 된 것이 아니라, 모든 회사나 조직에 적용 가능한 일반적인 설문입니다.

1. Do you know what is expected of you at work?
Do you know what are wrong ways and right ways of doing your work? Or do you think nobody would notice the difference if you’d switched to coding on your office walls with a crayon marker?
2. Do you have the materials and equipment you need to do your work right?
Are tools and processes supplied and customized for you? Or do you feel that buying and carrying your own stone tablets for writing source code would be an improvement over your current situation?
3. Do you get the opportunity to do what you do best every day?
Are your talents being used to their fullest potential? Or will your mother and her Chihuahua have just about the same chance at success when they’d attempt to take over the work that you do?
4. Did someone recently give you recognition or praise for doing good work?
Is anyone noticing you’re making a difference, in a positive way? Or are they more eager to point at that minor error that almost completely blew up the company, but actually didn’t?
5. Do your colleagues seem to care about you as a person?
Are they interested in your hobbies, your spouse, your friends and family? Or are you not comfortable enough to reveal that you have this fascination for bonsai trees, and are planning to marry one?
6. Are you encouraged to work on your (self-)development?
Has someone discussed with you how you can further improve as a person? Or do you think they won’t even care if you changed into Captain Code, saving the world from bugs and bad formatting?
7. Do people make your opinion count?
Are your colleagues listening to you? Or might you just as well talk to the receptionist’s hair dresser, for all the good it would bring you?
8. Do you feel that your job is important?
Do you understand how your work is a significant part of the value your organization tries to create? Or do you feel that your holidays have about the same amount of impact on the success of your organization?
9. Are your colleagues committed to doing quality work?
Do you feel that doing the best work possible is important to your co-workers? Or do they care more about their working times, their dogs, their collections of beer bottles, and the value of their stock?
10. Do you (or would you like to) consider some colleagues as friends?
Do you enjoy meals, movies, games, or even holidays with some of your colleagues? Or do you intentionally live at the other side of the country, staying as far away from them as possible?
11. Does someone care about the progress of your work?
Is someone interested in what you do at work, and how your work is coming along? Or do they prefer to talk about the weather, or their own heroic stories of saving the company?
12. Are you given the opportunity (time/resources) to learn and grow?
Do you have the means and ability to improve the way you do your work? Or are you expected to learn and grow on your own time, while walking the dog, or taking a shower?

2008년 11월 21일 금요일

책(소프트웨어개발의 모든것)을 미국에 있는 친구에게 보냈다.

며칠 전에 책(소프트웨어개발의 모든것)을 미국에 있는 친구부부에게 보냈습니다.
오늘 받았다고 연락이 와서 잠시 얘기를 했습니다.

그 친구들은 과거 나와 같이 일을 했었던 친구인데,
버클리(UC Berkeley)에서 Computer Science를 전공을 했고, 십여년간 실리콘 벨리에서 소프트웨어 개발자로 일을 하고 있는 친구입니다.

그 친구가 책을 본 소감은 다음과 같더군요.

"책의 내용이 매우 친숙하다. 미국의 개발자들이 당연히 따른 것들이다."

사실 그렇습니다. "소프트웨어개발의 모든것"이라는 책은 소프트웨어 회사라면 당연히 갖춰야할 기초를 다루는 것으로 미국에서는 당연히 되는 것들이 우리나라에서는 너무나도 낯선 것이 많더군요.

Peer ReviewSCMBugTrack, Technical Path, Technical Steering Commitee, Spec, Conding Convention, Risk Management, Branch, Merge, Baseline, Tagging, Change Control, Daily Build, Regression Test, Requirement Engineering, Alpha, Beta, Release Candidate, WBS, B/R, Interface, Non-functional Requirement

이러한 것들이 특이한 것이 아니고 소프트웨어를 개발한다면 그냥 "공기와 물"같은 것인데 말입니다.
이 책을 영어로 번역을 해서 미국에서 판다면 아마 안 팔릴 거예요. 기껏해야 경험이 부족한 대학생들이나 살지도 모르죠. 미국에서는 일단 개발자로 소프트웨어 회사에 들어가면 이 책의 내용들은 2,3년이면 누구나 익히는 것들입니다.
그래서 이런 종류의 책이 미국 또는 한국 어디에도 없나 봅니다.
미국에서는 당연한 내용이라서 없고, 한국에서는 그러한 필요를 못느끼거나 저변이 부족해서 없다고 생각합니다.

하지만 우리나라 소프트웨어 회사들을 보고 개발자들을 만나보면 대단히 뛰어난 기술력과 열정에 비해서 책에서 소개하고 있는 기초에 대해서 취약한 경우가 많습니다. 그러한 소프트웨어 엔지니어링은 학교에서 배우는 것이 아니고 회사에서 자연스럽게 일을 하면서 배우는 것인데, 회사가 기초를 갖추지 못하고 있으니 개발자도 배울 수 없고, 나중에 가르칠 것도 별로 없는 "악순환"이 계속 되는 것이죠.
이건 엔지니어의 책임이 아닙니다. 소프트웨어 회사의 책임이죠. 회사는 입사하는 소프트웨어 엔지니어를 트레이닝 시킬 의무가 있는데, 우리나라 대부분의 소프트웨어 회사는 그냥 개발자에 의존해서 개발자가 하는대로 따라가는 것이 보통의 겨우죠.

그에 비하면 인도는 처음부터 개발자들이 미국에 많이 진출을 했고, 미국의 일을 많이 받아서 해오느라고 미국의 방식대로 그대로 배우면서 소프트웨어 산업이 발전해왔죠. 인도는 정말 잘되어 있습니다. 우리와 소프트웨어 산업의 태생이 다른 인도의 행운이라고 볼 수도 있죠. 모든 업무가 전문적으로 나눠져 있고, 분석, 설계, 테스트, Tech Pub 모든 작업이 전문적으로 진행되고, 문서 작성, 시스템 사용 이런한 것들이 기본적으로 다 갖춰져 있고, Global 표준인 미국의 방식을 따르고 있죠.

솔직히 제가 소프트웨어 컨설팅을 하고 있지만, 단 시일내에 우리나라의 소프트웨어 개발 환경이 좋아지리라고 생각하지 않습니다. 하지만 꾸준한 노력이 필요하고 그 일환으로 책도 쓴 것입니다.
어차피 나를 비롯해서 수많은 소프트웨어 엔지니어들은 이 소프트웨어 바닥이 잘 되어야지 다른 뾰족한 재주가 없으니까요. 지금은 3D 직업으로 점점 인기를 잃어 가고 있지만 소프트웨어 엔지니어가 최고로 대접받는 때가 와야 하지 않겠습니까?

Diff and Merge in SCM(Software Configuration Management)

에 관한 포스팅에 대하여 답변 겸 SCM에서의 Diff와 Merge에 대해서 글을 남겨 봅니다.

일단 헝그리맨님의 글에 대한 답변을 먼저 해야 겠군요.
사실 그동안 소스코드를 Diff하고 Merge하는데는 GUI Diff, Merge툴의 한글 깨지는 문제는 크게 신경을 쓰지 않았습니다.
  • 대부분의 소스코드는 거의 영어로 되어 있고, 
  • 주석에 일부 한글이 들어 갔어도 이부분이 수정되서 Diff, Merge가 필요한 부분이 거의 없었고,
  • 대부분의 머지는 줄단위로 이루어져서 줄 내에서 한글을 깨지게 표현하는 것은 사실 문제가 안되었습니다.
  • 3-way merge를 할때는 오랫동안 Unified diff를 사용했기 때문에 문제가 안되었습니다.
이것은 단지 한글 깨지는 것이 큰 이슈가 아니었다는 얘기입니다.
하지만 한글이 큰 이슈라면 AcroDiff나 WinMerge를 사용하시면 될 것 같습니다.
TortoiseSVN은 외부 Application을 등록하여 사용할 수 있도록 되어 있으니 한글(2byte)문자를 지원하는 AcroDiff나 WinMerge를 사용하세요. 
물론 Araxis Merge같은 상용제품을 사용하시면 금삼첨화지요.
Araxis Merge은 단순히 한글 지원 장점 외에도 3-way Merge를 지원하므로 제대로된 Merge Tool이라고 할 수 있습니다.
3-Way Merge를 지원하는 Merge Tool 중에서 무료로 사용할 수 있는 것은 KDiff3가 있습니다.
GPL 라이센스라서 무료이기는 하나 한글지원에서 약간 문제가 있습니다.
머지 기능 자체의 문제는 아니고 한글 부분이 약간 깨져서 보입니다만 Merge는 잘됩니다.
그래서 저는 KDiff3를 사용합니다.

얘기가 나온 김에 3-Way Merge가 무엇이며 왜 필요한지 "소프트웨어개발의 모든것"이라는 책의 내용을 잠시 소개하겠습니다.

 머지(Merge)
머지는 분기된 소스코드를 하나로 합치는 일이다머지를 능수능란하게사용할 수 있어야 소스코드관리시스템을 원활하게 사용할 수 있다.
머지는 크게 2-way 머지와3-way 머지로 나뉜다. 2-way 머지는 두 개의 파일을 가지고 서로 다른 부분을 비교하면서하나로 합치는 것이다이 방법은 100% 수동에 의존할수 밖에 없다서로 다른 부분 중 어느 것을 빼고 어느 것을 남겨야 하는지 어느 것이 옛날 내용이고어느 것이 새로 바뀐 것인지 직접 보고 판단해야 한다우리가 흔히 보는 머지툴의 대부분이 2-way 머지툴이다.


위 그림은 파일1과 파일2를합쳐서 파일3을 만들려는 것이다파일1과 파일는 원래는 하나의 파일이었으나 과거에 브랜치가 되어서 각각따로 수정된 것이다이 경우 어떻게 합쳐야 할 지 막막하다. B shark일지 monkey일지 판단하는 것이 쉽지 않다. F=mango는 새로 추가된 것인지 원래 있던 것이 반대 파일에서 삭제된 것인지 알기 어렵다따라서 소스코드를 잘 알고 있는 사람이 내용을 모두 보고 판단하는 수밖에 없는 것이다.
하지만 3-way 머지는 방법이 좀 다르다. 두 파일을 단순히 비교하는 것이 아니고 두 파일로 나누어지기 전의 파일도 같이 포함하여 비교하며 머지하는 것이다그렇게 되면 어떤 내용이 추가되거나 삭제되거나 변경되었는지를 알 수 있기 때문에 최종본으로 합치는 일이 훨씬수월하다파일의 충돌만 없다면 자동으로도 머지가 가능하다파일의충돌이 있을 경우에만 충돌된 부분을 사람이 판단하여 통합하면 되는 것이다.


여기서 새로 등장한 파일0은 파일1과파일2가 브랜치 되기 전의 원래 파일이다파일0, 파일1, 파일2를 각각비교하면파일1에서 monkey shark로 수정된 것을 알 수 있다파일2에서 apple은삭제되고 mango가 추가된 것도 알 수 있다이 정도면사람이 별도로 판단할 필요 없이 자동으로 머지가 가능하다. 이러한3-way 머지툴에는 다음과 같은 것들이 있다.
  • Perforce Merge
    • Publisher: Perforce software
    • License: 무료
  • Araxis Merge
    • Publisher: Araxis ltd.
    • License: 유료
  • KDiff3
    • Publisher: KDevelop
    • License: GPL
이 중에서 KDiff3는 인터넷을 통해서 쉽게 구하여 사용할 수 있다.


3-way 머지를 이용하면 또 다른 기능을 이용할 수도 있는데부분 머지(Range Merge)가 바로 그것이다예를 들어 브랜치를 하여 수정한 여러 부분에서 특정 부분만 트렁크와 머지를 하고 싶을 때가 있다고객의 요구에 의해 브랜치를 했고해당 브랜치에는 고객의 특별요구 기능이 반영이 되어 있었다그런 다음 브랜치에서 발견한 버그를 수정했는데이를 트렁크에도 반영하고 싶을 때가 있다이 경우에 3-way 머지를 이용하면 다른 부분은 빼고 버그를 수정한 부분만 골라서 머지를 할 수 있다.


소스코드관리시스템과 3-way 머지툴을 효과적으로 사용하면 머지작업이아주 효율적으로 진행된다그러나 3-way 머지가 매우유용한 방법인 것은 사실이나 100% 자동에 의존할 수는 없다.3-way 머지툴이 충돌없이 머지에 성공했다 하더라도그 결과를 눈으로 직접 확인하는것이 더욱 안전할 것이다.

2008년 11월 19일 수요일

SRS(Software Requirements Specification)의 중요성

본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만, 
특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다.
"소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다.
그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다.

먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다.

 요구사항 분석

소프트웨어 프로젝트에 있어서 가장 흔한 실수 중의 하나가 요구사항이 불명확한 상태에서 급하다는 이유로 일단 설계, 구현을 시작하는 일이다. 어떤 경우는 스펙문서가 아예 없는 상태에서 프로젝트를 진행하는 경우도 있다. 또는 간단한 요구사항 목록을 가지고 스펙이라고 착각하는 경우도 많다.
제대로 된 요구사항 개발 없이 프로젝트를 성공적으로 수행하는 것은 거의 불가능하다. 고객의 요구사항을 상세히 기술하였다고 해서 좋은 요구사항은 아니다. 고객도 자신이 원하는 것을 자세히 모르는 경우가 아주 흔하기 때문이다. 고객의 요구사항을 단순히 기술한 정도의 요구사항은 프로젝트 후반에 많이 바뀔 수 있는데, 요구사항 개발 시 간단히 해결할 수 있는 것을 프로젝트 후반이나 유지보수 시까지 와서야 처리함으로써 수십 배의 비용을 추가로 치르는 경우도 있다.
요구사항 개발은 단순히 요구사항을 옮겨 적는 일이 아니다. 요구사항을 수집하고, 분석하고, 정리하고, 리뷰하는 일을 반복하여 완성도를 높여가는 일이다.
책을 보고, 샘플을 보고, 템플릿을 이용해서 독학함으로써 SRS를 잘 쓰는 것은 거의 불가능하다. 책이 도움은 될 수 있으나, SRS를 제대로 쓰려면 제대로 된 회사에 가서 몇 년 동안 일하면서 배워야 한다. 때에 따라서는 전문가에게 컨설팅을 받는 것도 좋은 방법이다. SRS는 기능공처럼 기법에 따라 작성하면 되는 것이 아니라 인간의 판단이 핵심인 문서이기 때문에 작성이 생각처럼 간단하지 않다.

 요구사항의 중요성

요구사항 문서는 프로젝트에서 작성하는 산출물 중에서 가장 중요하다. 요구사항 문서인 SRS는 소프트웨어 프로젝트의 기둥이다.
소프트웨어 시스템 구축에서 가장 어려운 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다. 그러나 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이 허락하는 한 최대 한도로 많은 정보를 파악하는 것이 좋다. 
잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발 비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며 많은 추가 비용을 발생시킨다. (출처, Software Requirements, Karl E. Wiegers, Microsoft Press)
완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다. 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수 있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다.



요구사항 오류는 개발 단계가 지나가면 갈수록 그 수정 비용이 기하급수로 증가한다. 유지보수 단계에서 요구사항 오류를 바로 잡으려면 요구분석 단계에서 바로 잡는 것보다 200배의 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는 요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.

SRS란?

요구사항 분석 문서의 종류는 수없이 많다. 개발 방법론에 따라서 제시하는 요구사항 문서가 다르고, 그 개수도 다르다. 여기서 소개할 문서는 SRS이다. SRS는 이 책 전체에서 소개하는 많은 문서 중에서 가장 중요하다. 프로젝트를 성공으로 이끄는데 가장 중요한 핵심이기 때문이다. 만약 소프트웨어 프로젝트에서 문서를 딱 하나밖에 만들 시간이 없다고 하면 SRS를 만드는 것이 좋을 것이다.




SRS는 IEEE에서 만든 가이드와 표준 Template이 있다. 회사들마다 사용하는 Template이 약간씩 다르지만 문서이름, 목적, 취지는 전세계적으로 표준이라고 보면 된다. 소프트웨어 개발 회사라면 회사에 맞게 각자 커스트마이즈 된 SRS Template을 가지고 있어야 한다.

2008년 11월 15일 토요일

Release Branch, Function Branch and Customer Branch

서영아빠님의 "브랜치를 이용하여 운영환경에 선별적으로 배포하기"란 글을 보고 소프트웨어 프로젝트에서 브랜치란 어떤 의미를 가지는지 "소프트웨어 개발의 모든것"이라는 책에서 이에 대하여 소개한 내용이 있는데 이를 인용하여 설명을 하려고 합니다.

여기서 소개하는 브랜치에 대한 얘기의 핵심은 브랜치의 위험성에 대한 "경고"입니다.
브랜치는 위험하지만 소프트웨어 개발에서는 흔히 꼭 필요하게 되어서 철저히 통제가 되어야 한다는 것입니다.

 브랜치(Branch)

브랜치란 필요에 의해서 소스코드를 분기하는 것이다. 
브랜치를 얼마나 잘 통제하는가가 훌륭한 소프트웨어 회사와 평범한 소프트웨어 회사를 구별하는 핵심 요소 중 하나이다. 
브랜치를 해야 하는 경우를 예로 들면 다음과 같다.

  • 제품을 출시 후 유지보수를 하면서 동시에 업그레이드 프로젝트를 진행할 경우
  • 이미 출시 된 제품에 복잡한 기능을 추가하려고 할 경우
  • 고객이 제품에 특정 기능을 넣어 달라고 요구를 하는데, 그 기능이 제품의 표준 기능에서 벗어날 경우
  • 고객이 제품에 특정 기능을 넣어 달라고 요구를 하는데, 표준 기능으로 넣을 시간이 부족한 경우

제품 출시 후 유지보수와 업그레이드 프로젝트를 진행하면서 하나의 소스코드를 같이 사용한다면 완전히 뒤죽박죽이 될 것이다. 아직 완성되지 않은 기능들이 고객에게 전달 될 수도 있다. 이 경우 소스코드를 브랜치하여 브랜치 된 소스코드를 유지보수를 위해 사용할 수도 있고, 업그레이드 용으로 사용할 수도 있다. 상황에 따라서 적절하게 선택하면 된다. 가능하면 적게 바뀔 것을 브랜치로 사용하는 것이 좋을 것이다. 왜냐하면 브랜치는 나중에 트렁크(Trunk)와 머지를 할 것이기 때문이다. 이렇게 서로 다른 소스코드를 가지고 개발하다가 업그레이드 프로젝트가 끝날 때쯤 그 동안 유지보수를 하면서 버그를 수정하거나 일부 기능을 추가한 것들을 서로 머지하게 된다. 이러한 브랜치를 릴리즈 브랜치(Release Branch)라고 부른다.
이미 제품이 출시되어서 유지보수를 하고 있을 경우, 시간이 많이 걸리거나 리스크가 큰 기능을 추가할 때도 브랜치를 사용할 수 있다. 예를 들어 어떤 제품이 2주일에 한번씩 업데이트를 한다고 할 때, 어떤 기능은 구현하는데 4주가 걸린다면 2주 만에 업데이트를 할 때, 완성되지 않은 기능이 포함될 수 있다. 또는 구현의 가능성이 확실하지 않은 기능을 원래 소스코드에서 개발하느라고 소스코드를 마구 건드릴 경우 나중에 기능을 빼려고 해도 깔끔하게 원래대로 되돌려 놓기가 쉽지 않다. 이럴 때 브랜치를 해서 해당 기능이 완성된 후 메인 소스코드와 머지를 하면 된다. 이러한 브랜치를 기능브랜치(Function Branch, Feature Branch)라고 부른다.

브랜치 중에 가장 문제가 되는 경우는 고객의 특수한 요구를 만족시키기 위해서 제품이 분기되는 경우(Customer Branch)이다. 제품이 분기된 뒤, 나중에 머지되지 않고 영원히 브랜치가 유지되는 경우가 많다. 브랜치를 만들고 어느 시점이 지나면 원래 소스코드와 브랜치가 너무 차이가 많이 나서 머지가 거의 불가능해지기 때문이다. 
브랜치를 쉽게 생각하고 일단 소스코드를 분기해서 별도의 제품을 만들기 시작하는 것은 되돌아 올 수 없는 강을 건넌 것이나 다름없다. 경험이 부족한 개발자는 브랜치의 부담을 우습게 생각하기 쉽다. 실제로 초기에는 브랜치가 있어도 견딜만하고 관리할 만 하다. 특히 브랜치를 해야만 매출을 일으키는 경우라면 브랜치의 유혹을 뿌리치기가 쉽지 않다.

그러나 이렇게 브랜치를 계속 만들다 보면 더 이상 감당이 안 되는 때가 오게 된다. 회사가 어느 정도 매출이 일어나고 잘되기 시작하면 과거에 많이 만들어 놓은 브랜치가 더욱 발목을 잡는다. 어차피 제품이 많이 팔리지도 않았다면 문제가 될 것도 없다. 오히려 회사가 잘될 때 문제가 된다. 이쯤 되면 제품의 업그레이드나 신제품 개발보다는 브랜치 관리에 더 많은 노력을 기울일 수밖에 없게 된다. 버그를 하나 고쳐도 여기저기 브랜치를 다 손대야 한다. 어느 브랜치를 어느 고객이 쓰고 있는지 헷갈려서 배포 사고도 가끔 발생한다. 무슨 툴을 하나 만들어도 각 브랜치마다 다르게 개발해야 하는 어려움이 발생한다. 

브랜치가 많아지면 웬만큼 관리를 잘하지 않고는 어느 브랜치에 무슨 기능이 포함되어 있는지 정확하게 파악하기 힘들어 진다. 초기에 브랜치를 만들었던 개발자들도 얼마 간은 브랜치 내용을 정확하게 기억하고 있을지 모르지만, 시간이 지나면 브랜치를 만든 개발자마저도 브랜치 내용을 정확하게 기억하기 어려워진다. 게다가 문서는 없고, 사람마저 바뀌어버리면 정말 알 수 없는 상황이 된다. 이로 인한 문제를 말하자면 끝이 없지만, 한마디로 아수라장이 되어버린다고 할 수 있다.

브랜치가 필요하다고 해서 개발자가 원할 때마다 브랜치를 해서는 안 된다. 브랜치를 하려면 개발 조직의 최고 책임자나 위원회의 허락을 받도록 하는 것이 좋다. 이 때는 브랜치를 해야 하는 이유를 타당하게 설명해야 하고 가능하면 빨리 머지를 할 수 있는 계획도 세워야 할 것이다.

특히 영업 지향의 회사에서는 브랜치의 위험성에 대해서 이해하지 못하는 경우가 많다. 단기적인 매출의 유혹이 회사의 미래를 망치는 경우를 종종 보게 된다. 고객마다 소스코드가 다르고 매번 각 사이트를 지원하기 위해 개발자들이 고객 전용 소스코드를 수정하고 있어도 이를 당연한 것으로 생각하기 쉽다. 이렇게 되풀이 되는 일들이 개발자들의 사기를 떨어뜨리는 것은 물론이다.

2008년 11월 14일 금요일

빌드와 컴파일의 차이

kenu님의 블로그에 빌드와 컴파일에 대한 차이를 묻는 글이 올라와서 간단히 설명해보려고 합니다.

컴파일 : 소스코드 파일 등의 원시파일을 실행파일, 라이브러리 등의 Object 파일로 바꾸는 작업

빌드 : 소스코드 파일들을 컴퓨터에서 실행할 수 있는 소프트웨어로 변환하는 일련의 과정

컴파일은 빌드의 부분 집합입니다.
빌드 과정은 제품마다 서로 다르지만 간단한 예를 하나 들어보면 다음과 같습니다.
보통 아래 과정은 Build Script에 의해서 한번에 자동으로 실행됩니다.
실제 예는 아래 나열한 것보다 수십배는 더 복잡합니다. ^^
  1. 소스코드관리시스템에 태그(베이스라인) 작성
  2. 작성된 태그(베이스라인) 체크아웃을 통해 빌드 전용시스템으로 소소코드 가져오기
  3. 새로운 빌드번호 획득 및 반영
  4. 컴파일(빌드) 시작
  5. 컴파일(빌드)시 발생한 에러 처리
  6. Doxygen 또는 JavaDoc 생성
  7. 팩키징 절차를 통해서 마스터 파일 생성
  8. 스모크 테스트 등 자동화 테스트 실시
  9. 테스트 결과 처리
  10. 빌드 결과를 관련자에 이메일로 전송
  11. 마스터 서버로 마스터 파일 복사
  12. 릴리즈 결과 전사 공지
또 빌드와 릴리즈는 항상 짝을 이뤄 따라 다니며, 수많은 B/R(Build/Release) 엔지니어들이 이에 대한 자동화와 효율성/생산성 증대를 위해서 연구를 하고 있지요. 
소프트웨어 프로젝트에서 빌드의 중요성에 대해서는 제가 이미 포스팅을 한 글이 있으니 참고하세요.

내부 세미나

영회님의 공감이 가는 글(http://younghoe.info/994#footnote_link_994_1)을 보고 의견을 남겨보려고 합니다.

소프트웨어를 개발하는 회사라면 당연히 갖추고 있어야 할 개발 문화는 여러가지가 있지요.
Peer Review, Sharing, 규칙 준수 ...

이 중에서 좋은 문화 중의 하나가 일상화된 내부세미나입니다.

유수의 소프트웨어 회사들을 보면 회사에 늘상 세미나 공지가 있습니다.
누구나 세미나를 진행할 수 있고, 
대부분 직원들이 관심을 가질 만한 주제들이고,
누구나 부담없이 참여를 합니다.
오다가다 들려서 보기도 하고, 
관심이 많으면 준비를 해와서 발표자와 토론도 하기도 하기도 합니다.
누가 시켜서 의무적으로 하는 세미나는 아니지요.

그러한 과정에서 발표자에게도 지식을 더욱 깊고 굳건히 할 수 있는 기회가 되고,
참가자는 새로운 지식을 쉽게 익힐 수 있는 기회가 되고,
회사는 항상 연구하고 새로운 기술을 추구하는 자연스런 분위기가 됩니다.

항상 프로젝트에 치여서 이럴 시간이 전혀 없다면 곤란하지요.
강제로 해야 하고 강제로 참여해야 한다면, 문화로 자리잡을 수가 없지요.
회사에서는 이에 대한 시간적인 공간적인 배려와 약간의 금전적인 지원도 좋죠.

이를 포함한 여러 개발문화들이 뿌리깊게 자리잡지 않고는 Global 경쟁력을 갖춘 소프트웨어 개발 회사가 된다는 것은 불가능하다는 것을 인식해야 하지 않을까요?