[펌] 소프트웨어 개발의 미래

digg 을 여기저기 뒤져보다가 재미 있는 글을 발견했습니다..
제가 생각하고 있는 부분을 상당히 잘 반영한 글이라 생각이 되어..
원저자의 허락을 안 받고 번역을 했습니다..
아마도 CEO나 PM 등의 입장에서 보는 것이기 때문에 개발자의 관점과 다를 것이고
그것이 의미가 있으리라 생각합니다..
(사실은 팀원들 보라고 번역을 한겁니다..)

번역 실력이 미진한 부분이 있어서 원문과 같이 게시합니다..

요약 :
새로운 소프트웨어의 시대는
1. 애자일 방법론
2. 새로운 프로그래밍 언어
3. 멋진 인프라와 라이브러리
가 핵심이 됩니다..

체계화된 소프트웨어 공학 보다는 장인정신이 중요합니다..
왜냐고? 위와 같은 것을 능동적으로 해내려면 소프트웨어 공학보다는 똑똑함이 요구될 것이니까요...

스스로 유연하게 설계하고 프로세스를 만들며, 남들이 잘 만들어 놓은 것을 효율적으로 사용할 줄 아는 사람이 진정한 개발자가 된다는 얘기입니다..


-----

The Future of Software Development (소프트웨어 개발의 미래)


In 1975, Frederick Brooks wrote a classic book on software project management called The Mythical Man-Month. In the book, he famously argued that adding more people to a development project will hinder rather than help to get things done faster. The reason is that having more people working on the project introduces a non-linear overhead in communication.

1975 년에 Frederick Brooks는 소프트웨어 프로젝트 관리 분야에서 고전으로 꼽히는 "맨먼쓰의 미신(The Mythical Man-Month)"이라는 책을 썼다. 이 책에서, 그는 개발 프로젝트에 사람을 더 많이 투입하는 것은 일을 빠르게 진행시키지 못하고 오히려 방해가 된다는 것을 주장하였다. 그 이유는 프로젝트에 더 많은 사람이 투입된다는 것은, 사람 간의 커뮤니케이션 패스가 기하급수적으로(non-linear)가 증가하기 때문이라는 것이다.

Five years before Brooks' book, a software development methodology called the Waterfall Model was coined. This approach applied the insights from mature engineering disciplines (mechanical, civil, etc.) to software. The idea was to construct systems by first gathering requirements, then doing the design, then implementing it, then testing, and finally getting it out the door in one linear sequence.

Brooks 씨의 책이 나오기 5년전에, "폭포수 모델(Waterfall Model)"이라는 소프트웨어 개발 방법론이 나타났다. 이 방법론은 성숙한 단계의 엔지니어링 분야(기계공학, 도시공학 등)에서 얻어진 "식견"을 그대로 소프트웨어에 적용한 것이다. 이 모델은 "요구사항 수집", "설계", "구현", "테스트", 그리고 마지막으로 "출시"까지 하나의 순차적인 순서에 의해서 진행하는 방식을 뜻한다.


We have come a long way since then and learned a lot about making software. The Waterfall Model is now considered a flawed method because it is so rigid and unrealistic. In the real world, software projects have ill-defined and constantly evolving requirements, making it impossible to think everything through at once. Instead, the best software today is created and evolved using agile methods. These techniques allow engineers to continuously re-align software with business and customer needs.

폭 포수 모델 이후 오랜 기간이 흘렀고, 소프트웨어 개발에 대해서 많은 지식이 쌓였다. 이제 폭포수 모델은 너무 경직되어 있고 비현실적이라는 이유로 한물간 모델이 되었다. 현실 세계에서라면, 소프트웨어 프로젝트의 요구 사항은 제대로 정의가 안되고, 지속적으로 변경 되며, 따라서 한번에 모든 것을 고려한다는 것은 불가능하다. 대신, 요즘은 "애자일(agile, 기민한)" 방법론을 통해 최고의 소프트웨어를 만들 수 있다. 이와 같은 테크닉을 통해 엔지니어는 비즈니스적인 혹은 고객의 요구에 따라 꾸준히 소프트웨어를 변경(re-align) 할 수 있다.


With the advent of modern programming languages (Java, PHP, Python and Ruby), rich libraries, and unprecedented infrastructure services like those from Amazon, we are arriving at yet another evolutionary step. Digg, del.icio.us, YouTube and other poster children of the new web era were developed by just a handful of programmers. To build software today all you need is a few good men (or women!). In this post we trace how we got here and where we are heading next.


현 대적인 프로그래밍 언어(Java, PHP, Python, Ruby 등), 풍부한 라이브러리, 그리고 아마존에서 제공하는 것과 갈은 참신한 인프라스트럭처 서비스(역자주: 아마 Open API 같은 것을 의미하는 듯) 등이 등장함에 따라, 이제 새로운 혁신의 단계가 도래했다. Digg, Del.icio.us, YouTube와 같은 새로운 웹 세대들은 불과 몇 명의 프로그래머가 만들어 낸 것이다. 이 글에서, 우리는 어떻게 현재에 이르었으며, 앞으로 어떻게 나아갈 것인지에 대해서 논해 보고자 한다.


Why The Waterfall Model Failed
폭포수 모델의 실패 이유

Non-technical people tend to think that software is soft or easily changeable. Since there are no visible nuts and bolts and no hood to open people think that software can be tweaked and re-wired on a whim. Of course, this is not the case. Software, like any mechanical system, has a design and the structure; it is not as soft as it seems.

비전문가인 사람들은 흔히 소프트웨어는 매우 "유연(Soft)"해 서 쉽게 바꿀 수 있다고 생각을 한다. 눈에 보이는 너트나 볼트, 혹은 열어야 할 포장 등이 전혀 없기 때문에, 소프트웨어는 "변덕"에 따라 얼마든지 고치거나, 재조립할 수 있다고 생각한다. 물론, 이것은 사실이 아니다. 다른 기계적인 시스템과 마찬가지로, 소프트웨어는 설계와 구조가 있으며, 보이는 것처럼 그렇게 유연하지 않다.


Yet the accelerating pace of business requires constant changes to software. Older development methods completely fail to address business needs. Using the Waterfall Model, these changes were impossible, the development cycle was too long, systems were over engineered and ended up costing a fortune, and often did not work right.


그 럼에도 불구하고, 비즈니스가 점점 빠른 속도로 변하고 있기 때문에, 소프트웨어에서도 꾸준한 변화가 반드시 필요하다. 예전의 개발 방법론은 비즈니스 요구를 반영하는데 확실히 실패를 했다고 할 수 있다. 폭포수 모델을 사용할 경우, 이런 변경 사항은 반영이 불가능하며, 개발 싸이클은 너무 길고, 시스템은 오버엔지니어링이 되고, 굉장히 많은 비용이 들고, 상당수는 정상적으로 작동을 하지 않게 된다.


The problem was that the Waterfall Model was arrogant. The arrogance came from the fact that we believed that we could always engineer the perfect system on the first try. The second problem with it was that in nature, dynamic systems are not engineered, they evolve. It is the evolutionary idea that lead to the development of agile methods.


이 런 문제의 원인은 폭포수 모델에 교만함이 내포되어 있기 때문이다. 이런 교만함은 "단 한번에 완벽한 시스템을 구축할 수 있다"는 자신감으로부터 비롯된다. 폭포수 모델의 두번째 문제점은, 근본적으로 다이내믹한 시스템은 "구축"될 수 없고, 진화한다는 것이다. 이와 같은 혁신적인 문제인식을 통해 애자일방법론의 개발이 대두된 것이다.
Agile Methods - Evolving Software
애자일 방법론 - 진화하는 소프트웨어

In the early nineties a number of agile software development methods emerged. While they differed in details, they agreed at large that software development needed a major rethinking. First, software has to embrace change. Today's assumptions and requirements may change tomorrow, and software needs to respond to changes quickly. To meet the challenge, agile approaches advocate focusing on simplicity. Make the simplest possible system that satisfies today's requirements and when tomorrow comes, be ready to adapt.


1990 년대 초반에 많은 애자일 소프트웨어 개발 방법론이 등장하게 되었다. 상세한 부분에서는 많이 달랐지만, 이들 방법론은 소프트웨어 개발에 있어 재인식이 필요하다는 점에서는 대부분 동의했다. 첫째, 소프트웨어는 변화를 수용해야 한다. 오늘의 가정과 요구사항은 내일 싹 바뀔 수 있으며, 따라서 소프트웨어는 이런 변화에 빠르게 대응해야 한다. 이와 같은 요구를 만족시키기 위해, 애자질적인 접근 방법은 단순함에 초점을 맞추자는 방식을 추구한다. 가장 단순하게 만드는 것을 통해, 오늘의 요구사항을 만족시키는 시스템을 구축할 수 있고, 내일의 변화에 대응할 준비를 할 수 있다.


Two techniques pioneered by agile methods are worth particular attention - refactoring and developer testing. Refactoring, elegantly described by Martin Fowler in his classic book is the idea of improving the design of the existing code without changing how it works.


" 리팩토링", "개발자 테스트"라는 두 개의 기법은 애자일 방법론에서 시도되었으며, 특별히 주의를 기울일만한 것들이다. 마틴 파울러에 의해 소개된 리팩토링은 동작 방식에 변경을 주지 않으면서 기존 코드의 설계와 디자인을 향상시키는 방법을 말한다.


Refactoring is what allows agile systems to embrace change, while remaining elegant and free from rot. Like an interior decorator continuously changes and improves the layout of your furniture, agile developers move code around to improve the product as a whole. Code is constantly changed to make sure we end up with the simplest, and best possible system that reflects our current needs.


리 팩토링을 통해 애자일 방법론 등이 변화를 수용할 수 있게 되었고, 부패와 타락으로 부터 자유롭고 우아하게 존재할 수 있게 되었다. 인테리어 디자이너(원문은 decorator이나 흔히 쓰는 표현이 아니어서..)가 꾸준히 변경을 하고 가구 배치를 발전시키는 것처럼, 애자일 개발자들은 코드를 이리저리 옮기면서 자신의 결과물의 질을 높이게 된다. 코드는 가장 단순한 형태를 띠고 현재의 요구(needs)를 충실히 반영한 가장 훌륭한 시스템이 될 때까지 꾸준히 변경된다.


To make sure that changes do not break the code, agile methods introduced unit tests. As each agile project unfolds, it grows the base of unit tests. Each test is focused on a single component of the system and acts as an insurance that the component works as expected. Typically, the tests are run continuously against the code and require immediate fixes in case of a failure.


변 경이 코드가 깨지는 문제를 일으키지 않게 하기 위해, 애자일 방법론에서는 유닛 테스트를 활용한다. 애자일 기반의 프로젝트가 커질 수록, 유닛 테스트의 크기도 커지게 된다. 각각의 테스트는 시스템의 하나의 컴포넌트에 초점을 맞추며, 그 컴포넌트가 예상했던 대로 동작하는지를 검증하는 역할을 한다. 일본적으로, 각 테스트는 지속적으로 수행이 되며, 실패(failure)가 발생하는 경우 즉각적으로 코드를 수정해야 한다.


The software systems created using agile methods are much more successful because they are evolved and adapted to the problem. Like living organisms, these systems are continuously reshaped to fit the dynamic landscape of changing requirements. Without a doubt, agile methods made a major impact on how we think about building software today - dynamically and continuously.


애 자일 방법론을 통해 개발된 소프트웨어 시스템은 다른 것들에 비해 훨씬 성공적이다. 왜냐하면 지속적으로 진화를 했고, 발생하는 문제에 대해 대응을 했기 때문이다. 생태계와 비슷하게, 이런 시스템들은 요구사항 변경에 따라 자신의 모양을 끊임없이 변화해 나간다. 의심의 여지 없이, 애자일 방법론은 오늘날 우리가 소프트웨어를 구축하는 방법에 대해서 가장 중요한 영향을 끼치고 있다. 그것은 바로 "역동적으로 그리고 지속적으로"(dynamically and continuously) 를 뜻한다.


It's The Libraries, Stupid!
라이브러리가 핵심이야, 바보야!

While we discovered better way of making software, we also discovered better programming languages. C was replaced with C++, then came Java. Perl was great, but PHP and Python took its lessons further. More recently came Ruby, which has become very popular because of its natural way of expressing code. Because of this evolution, today we have a number of excellent, and virtually equivalent programming languages.


앞 에서 소프트웨어를 더 잘 만드는 방법에 대해서 알아보았지만, 또한 더 좋은 프로그래밍 언어에 대해서도 알아볼 것이다. C는 C++에 의해서 대체 되었고, 그 이후에 Java 가 등장했다. Perl은 물론 훌륭하지만, PHP와 Python은 더 멋지다. 더 최근에는 Ruby가 등장했는데, code를 표현하는 방식 때문인지 급속도로 인기를 얻고 있다. 이런 변혁의 덕택에, 오늘날 우리는 멋지고 거의 동등한 수준의 프로그래밍 언어를 많이 사용할 수 있게 되었다.


While the choice of programming language is typically a sensitive subject, the truth is that it is not the language, but the libraries that come with it that make a difference. C++ never had the standard libraries that Java has. Yes, Java is the simpler language, but people used C++ for a decade just fine. What gives Java the edge is its rich set of reusable libraries. The story is similar with PHP. It has been the language of choice for web developers precisely because it comes with such rich support for web and database processing.


프 로그래밍 언어를 선택하는 것은 매우 민감한 문제이지만, 사실은 프로그래밍 언어 자체보다 같이 사용할 수 있는 라이브러리가 각 언어를 구분하는 중요한 요소가 되고 있다. C++의 경우 Java에서 사용할 수ㅤㄴㅣㅆ 표준 라이브러리를 전혀 가지고 있지 않다. 물론, Java는 더 단순한 언어이지만, 사람들은 10년이 넘는 세월동안 C++을 잘 사용해왔다. Java를 더 멋지게 만들어 주는 것은 재사용이 가능하고 기능이 풍부한 표준 라이브러리들이다. 이와 같은 이야기는 >HP에서도 비슷하다. PHP 역시 웹과 DB를 위한 훌륭한 지원 기능이 함께 제공되었기 때문에 웹 개발자들이 많이 선택해왔다.


In addition to the libraries that come with modern languages, the open source movement has also contributed a wealth of code towards global software infrastructure. Notably, just the Apache foundation on its own has created a huge amount of high quality reusable code. We have now arrived at an age where we have a strong foundation for building complex software systems. We know the methods and we have the tools, so what does that mean?


현 대의 프로그래밍 언어가 제공하는 라이브러리들뿐 아니라, 오픈 소스 운동 역시 전세계의 소프트웨어 인프라에 많은 기여를 해왔다. 누구나 인정하듯이, 아파치 재단은 높은 품질의 재사용 가능한 코드를 엄청나게 많이 만들어 제공하고 있다. 지금은 복잡한 소프트웨어 시스템을 구축하는데 필요한 많은 라이브러리와 기초가 제공되는 시대가 되었다. 우리는 방법론을 알게 되었고, 멋진 도구를 갖게 되었다. 이게 무슨 의미가 될까?


The Future of Software Development: Just a Few Good Men

소프트웨어 개발의 미래 : 몇명의 멋진 사람들(?)


Since early days of software development people struggled to build good systems. More and more people where thrown at the problem, making matters worse. But with the recent explosion of social web we've witnessed a new and interesting phenomenon: a handful of developers are now able to build systems that are used by millions of people. How can this be?


소 프트웨어 개발의 초창기에 개발자들은 좋은 시스템을 만들기 위해서 매우 많은 고생을 했다. 매우 매우 많은 사람들이 문제점 때문에 고생을 했고, 문제를 더 복잡하게 만들곤 했다. 하지만, 소셜 웹(social web)이 발달하는 최근에 와서는, 새롭고 재미있는 현상이 발견되었다. 단 몇 명의 개발자가 수백만명이 사용하는 시스템을 구축할 수 있게 된 것이다. 어떻게 그렇게 된 것일까?


The secret is that as with any good endeavor it only takes a few good men (and/or women!). With a bit of discipline and a ton of passion, high quality engineers are able to put together systems of great complexity on their own.


비밀은 바로 멋진 시도들은 대부분 몇명의 멋진 사람들(혹은 여자들)만으로 충분하였다는 것이다. 약간의 훈련과 많은 열정 만으로, 훌륭한 수준의 개발자들은 복잡한 시스템을 그들 스스로 멋지게 연동하여 만들어 낼 수 있다.


Equipped with a modern programming language, great libraries, and agile methods, a couple of smart guys in the garage can get things done much better and faster than an army of mediocre developers.


현대적인 프로그래밍 언어, 훌륭한 라이브러리들, 그리고 애자일 방법론, 이것으로 창고에서 개발하는 몇 명의 똑똑한 개발자들은 다수의 평범한 개발자들 하는 것보다 빠르고 훌륭하게 작업을 해낼 수 있다.


We are likely to see a few changes over the coming years:

* High-quality, passionate software engineers will be in very high demand and will make substantially more money.
* The developers who do not have great programming skills are going to have to look for jobs elsewhere.
* The changes that we are witnessing today in the social software market are going to reach the enterprise level.
* Software off shoring will make less and less economical sense.
* Computer science is going to remain a highly competitive and prestigious field.

최근 몇 년간 다음과 같은 변화가 일어나고 있다.

* 자질이 훌륭하고 열정이 있는 개발자들에 대한 수요는 엄청나게 많아지고 있으며, 이 사람들이 돈도 잘 번다.
* 프로그래밍 스킬이 훌륭하지 못한 개발자들은 점차 다른 직업을 찾아보고 있다.
* 오늘날 소프트웨어 시장에서 일어나는 변화를 보면, 엔터프라이즈 레벨로 점차 중심이 이동하고 있다.
* Software off shoring will make less and less economical sense. (아.. 이건 답이 안나오네.요.. 소프트웨어 아웃소싱이 활성화가 될거라는 얘기인지.. 아니라는 얘기인지..)
* 컴퓨터 과악은 지속적으로 높은 수준의 경쟁력이 있는 일류 분야로 남아 있늘 것이다.


Conclusion
결론

Ironically, we are coming full circle with the mythical man-month. What was true twenty years ago is true of course today, but for a whole new set of reasons. An awesome array of programming languages and infrastructure libraries combined with agile methods has allowed us to break free of old software development dogmas. Just a handful of great engineers can now successfully build systems of great complexity. Craftsmanship has finally come to software engineering!


아 이러니 하게도, 우리는 맨먼쓰 미신과 비슷하게 가고 있다. 20년전에 진실이었던 것은 지금도 그대로 진실이다. 하지만 그 이유는 완전히 다르다. 애자일 방법론과 결합된 프로그래밍 언어와 라이브러리 등을 통해 이전의 소프트웨어 개발 교리로부터 벗어날 수 있게 되었다. 단지 몇 명의 훌륭한 엔지니어만 있다면, 매우 복잡한 시스템도 성공적으로 개발해날 수 있게 되었다. 소프트웨어 공학 분야에서 장인 정신의 시대가 드디어 온 것이다.


원문출처 : http://www.readwriteweb.com/archives/the_future_of_software_development.php