소프트웨어 개발팀에서 성과를 이끌어 내는 비결

Source : http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=32305

 

개발자들이 잠을 줄여 가며 열심히 일을 하는 데도 왜 개발 프로젝트는 늘 납기를 못 맞추고 비용을 초과하고 또 생각지도 못 한 인적/물적 리소스를 투입해야 하는 걸까? 이 질문을 하니 떠오르는 예가 있다. 호랑이 담배 피던 시절, 병이 나면 무당을 찾아 가서 주술과 신의 힘으로 병을 고치려 했단다. 무당이 드물게 영적 능력이 뛰어나거나 여러분이 착한 일을 많이 해서 신이 돕는다면 분명 뭔가 효험이 있었을 거다. 그렇지만 대부분의 경우는 ‘원인’을 밝혀 ‘치료’를 하는 게 상식이다. 위가 아프다면 위 염증 여부를 확인하고 염증을 없애는 게 답이다. 아직도 우린 소프트웨어 개발 프로젝트에 한한 한, 뭔가 잘못 되면 무조건 ‘개발자’만 탓하는 호랑이 담배 피던 시절에 머물고 있는 것은 아닐까? 영어 공부도 영어 공부지만 이런 아픈 현실을 잘 꼬집어 소개한 책이 있어서 일부 내용을 여기서 소개한다. ‘소프트웨어 개발 팀에서 성과를 이끌어 내는 비결’(가칭)(Getting Results From Software Development Teams, Microsoft Press 2008)에서 로렌스 피터스(Lawrence J. Peters)는 소프트웨어 엔지니어링 분야에서 40년을 일한 베테랑으로써 자신의 경험에서 우러나오는 ‘진실’을 들려 준다.

기영모 helenjoh1@dreamwiz.com｜기술과 영어를 공부하는 모임이다. 개발자와 마케터가 함께 모여 기술과 영어를 교환하며 공부하는 모임으로 현재 MSDN magazine과 그 때 그 때 관심 있는 영역의 아티클을 공부하고 있다.

Myths Associated with Software
소프트웨어 개발 프로젝트의 12가지 오해

 

Myth #1: Software easier to change than hardware.
첫째, 소프트웨어는 하드웨어보다 변경 및 수정하기가 쉽다?

This Myth is more common and more counterintuitive than most managers would care to admit. At first glance, changing software looks a lot easier than changing hardware. For example, how easy would it be to change Hoover Dam? Not very.
이 오해는 사회적 통념으로 통용되고 있고 직관에 반하는 내용임에도 불구하고 대부분의 프로젝트 매니저들이 생각하는 것보다 더 많이 퍼져 있다. 언뜻 보아 소프트웨어를 변경하는 것이 하드웨어를 변경하는 것보다 훨씬 쉬워 보인다. 예를 들어, 후버 댐을 바꾸는 게 쉬울까? 그렇게 쉽지는 않을 것이다.

So what about software? The problem is that we take the ease-of-change issue for granted; we ?ee?solutions early on and often begin programming without really understanding the problem we are trying to solve and without looking to the future. The Year 2000 problem was a perfect example. People just did not realize that what they built in 1980 might still be in use in the year 2000. Furthermore, they took great pride at that time in achieving storage savings by storing only a two-digit number rather than a four-digit number to represent the year. A simple analysis or survey would have shown that a lot of software used in 1980 had been written much earlier, and it would be too expensive to replace it all every 20 or so years.
그럼, 소프트웨어를 바꾸는 건 어떨까? 소프트웨어를 바꾸는 게 쉽다는 통념을 당연한 것처럼 받아 들이는 데 근본적인 문제가 있다. 즉, 해결해야 하는 문제의 본질을 이해하려고 노력하거나 미래에 닥칠 문제들을 고려함 없이 초기에 ‘해결책’이라고 속단하고 종종 프로그래밍을 시작한다는 것이다. Y2K 문제가 대표적 예다. 1980년에 만든 소프트웨어를 2000년에도 계속 쓰게 될 거라는 걸 미처 생각지 못 한 거다. 어처구니없게도 당시에는 연도를 표기하기 위해 네 자리를 쓰는 것보다 두 자리를 쓰는 게 스토리지를 절감해서 좋다고 자랑스럽게 생각했다는 것이다. 간단한 분석이나 조사만 했더라도 1980년대의 많은 소프트웨어들이 훨씬 이전에 만들어 졌을 뿐만 아니라 그걸 20년마다 대체하는 게 매우 어려운 일이고 고비용이 든다는 것을 알았을 것이다.

 

Myth #2: We?e in maintenance mode, and it? rare that we write something new, so we don? need to measure what we?e doing, gather statistics, or define processes.
둘째, 늘 유지보수 모드이기 때문에 새로운 것을 만드는 건 드물다. 그러니, 우리가 뭘 하든 평가를 한다거나 이것을 통해 통계를 내거나 혹은 프로세스를 규명할 필요가 없다.

 

Myth #3: We don? need to document the code by including comments, because any proficient programmer can tell what the code does by looking at it.
셋째, 코멘트를 포함해서 코드에 대해 문서화할 필요가 없다. 이유는, 능력 있는 개발자라면 한 눈에 그 코드가 어떤 내용인 지 바로 알 수 있기 때문이다.

 

Myth #4: Quality can be tested into the system-What we should do is get it coded as rapidly as possible and then test it as thoroughly as possible.
넷째, 소프트웨어의 품질은 시스템에서 운영하는 단계가 되어야 테스트될 수 있다. 그래서 가능한 한 빨리 코딩을 끝내고 통째로 테스트하면 된다.

 

Myth #5; Why bother performing analysis and design? After all, the code, not these preliminary documents, results in a marketable product.
다섯째, 소프트웨어를 개발할 때 분석과 설계는 신경 쓸 필요 없다? 이런 문서는 중요 하지 않고 제품이 되는 것은 결국 코드이기 때문에 코드만이 중요하다.

Subscribers to this myth really don? understand the roles that analysis and design have played in engineering for more than two thousand years. There is evidence that the Romans built models, drew the equivalent of blueprints, and otherwise labored over a project before executing it.
이런 오해를 진실로 믿는 사람은 지난 2천년 동안 엔지니어링 분야에서 ‘분석과 설계’가 얼마나 중요한 역할을 해왔는지를 이해 못 하는 사람이다. ‘로마는 하루 아침에 이뤄진 것이 아니다’라는 말이 바로 증거다. 로마를 짓기 전에 분명히 상세계획을 세우고 프로젝트를 위해 많은 노력을 기울였기에 오늘 날의 로마가 생겨난 것이다.

 

Myth #6: We don? need a quality assurance group-we hire smart people, and they don? make mistakes.
여섯째, 품질보증팀(Quality Assurance)은 필요 없다. 그냥 뛰어난 인재를 뽑아서 쓰면 된다. 왜냐면 그들은 결코 실수를 하는 법이 없기 때문이다.

 

Myth #7: Increasing their compensation gets software professional to perform at a higher level.
일곱째, 프로 개발자들이 일을 더 잘하게 하려면 돈만 많이 주면 된다.

상세한 내용은 기회가 되면 책을 읽어 보기 바란다. 미국도 한국과 마찬가지인가 보다는 위안을 찾을 수 있다. 외국 개발자들도 사생활 없이 개발 프로젝트를 하고 있는 게 현실이란다. 그리고, 대부분의 매니저들은 돈만 올려 주면 개발자들이 그런 삶을 지속하면서 심지어 더 잘 일할 거라고 잘못된 생각을 갖고 있다고 한다.

 

Myth #8: The way to encourage people to get into management is to give them special perquisites.
여덟째, 개발자로 하여금 매니저가 되게 하는 길은 특별보너스를 주는 것이다.

 

Myth #9: Software processes are great, but when the project is behind schedule, we don? have time for such things.
소프트웨어 개발 프로젝트의 프로세스는 완벽하다. 그렇지만 프로젝트가 일정을 못 맞추고 있다면 프로세스를 따를 시간이 없다.

 

Myth #10: The marketplace requires that we get to market as quickly as possible. Using some sort of prescribed method or process is just going to slow things down.
열, 경쟁력을 유지하려면 가능한 한 빨리 시장을 공략해야 한다? 규정된 방법과 프로세스를 따르는 것은 시간을 빼앗을 뿐이다.

 

Myth #11: There is so much software out there that either is included with various development environments or can be licensed inexpensively-we can employ it and write very little new code.
열 하나, 다양한 개발 환경 제공하면서 저렴한 소프트웨어는 많이 있다? 그저 그걸 도입해서 조금만 고쳐 쓰면 된다.

 

Myth #12: If we institute processes into this organization, people will either leave the company or become unproductive.
열 둘, 학습 프로세스를 도입하면 결과적으로 개발자들은 회사를 떠나거나 생산성이 떨어진다.