• e-book
• 회원가입
• 정기구독신청
• 전체보기
• 로그인

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

프린트 이메일 전송

기영모 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. 
열 둘, 프로세스를 도입하면 결과적으로 개발자들은 회사를 떠나거나 생산성이 떨어진다.