Block Busting

출처... 모르겠음..

과거 5~70년대 전산학의 초기 단계때, 최단 거리 알고리즘의 고안과 같은 지대한 공헌을 한 덴마크의 물리학자 에츠허르 데이크스트라(Edsger Dijkstra) 교수가 남겼던 격언입니다.

Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
프로그래밍은 응용 수학에서 가장 어려운 분야다. 어설픈 수학자는 그냥 순수 수학자가 되는게 낫다.

The easiest machine applications are the technical/scientific computations.
가장 간단한 컴퓨터 응용분야는 기술적/과학 연산 분야이다.

The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
우리가 사용하는 도구는 우리의 사고 습관에 영향을 끼치며, 따라서 우리의 사고 능력에 영향을 준다.

FORTRAN --"the infantile disorder"--, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.
포트란 -- “발달 장애”-- 20년이나 지났기에 오늘날의 컴퓨터 어플리케이션에는 전혀 적합치 않다. 너무 거추장스럽고, 너무 위험 부담이 크고, 너무 비싸다.

PL/I --"the fatal disease"-- belongs more to the problem set than to the solution set
PL/I -- “치명적 질병” -- 이건 솔루션이라기 보다는 문제다.

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
베이직을 먼저 익혔던 학생들에게 좋은 프로그래밍 기술을 가르친다는 것은 사실상 불가능하다. 왜냐하면 절대로 회복 불가능한 정신적 데미지를 입히기 때문이다.

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
코볼을 쓰는 것은 멘탈을 붕괴시키는 짓이다. 따라서 이딴걸 가르치는 행위는 범죄 행위로 여겨야 할 것이다.

APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.
APL은 완벽함의 경지에 다다른 실책이다. 이건 구시대식 테크닉으로 만든 미래의 프로그래밍 언어이다. 신세대 프로그래밍 골칫거리나 만든다.

The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.
일반적인 데이터 베이스 매니지먼트의 관리자들이 갖는 문제점은 그들은 생각은 IBM語로 하면서 어설픈 영어로 말한다는 것이다.

About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
언어의 활용에 대해서 말하자면, 연필을 무딘 도끼로 깎는 것은 불가능하다. 무딘 도끼를 10개 가져와 봐야 마찬가지로 쓸모없다.

Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
우수한 프로그래머의 가장 중요한 자산은 수학적 능력 외에도 자신의 모국어에 대해 매우 뛰어나야 한다는 것이다.

Many companies that have made themselves dependent on IBM-equipment (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the unmastered complexity of their data processing systems.
IBM 기기들에게 의존하고 있는 많은 업체들은 (그러기 위해서 놈들은 자신의 영혼을 팔았다) 자신들의 데이터 처리 시스템의 미칠듯한 복잡함의 무게를 견디지 못하고 쓰러지게 된다.

We can found no scientific discipline, nor a hearty profession on the technical mistakes of the Department of Defense and, mainly, one computer manufacturer.
특정 컴퓨터 제조업체와 국방부에서 저질러지는 기술적 오류에서는 그 어떠한 과학적인 사고 방식이나 장인정신이라곤 찾아볼 수 없다.

The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity.
컴퓨터를 다루는데 의인화한 단어들을 쓰는 것은 기술적인 미숙함의 증상이다.

By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.
돌팔이 과학자(soft scientist)들은 자신들이 소프트웨어 공학에 기여할 수 있다고 주장함으로 자신들을 더욱 멍청하게 만든다. 명칭에 소프트라는 말이 들어가 있으나, 소프트웨어 공학에는 진짜 과학(hard science)이 필요하다.

In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.
옛날옛적엔 물리학자들은 검증을 위해 서로의 실험을 반복하곤 했다. 오늘날 물리학자들은 포트란이나 돌려대면서 서로의 버그를 포함한 프로그램을 공유한다.

Projects promoting programming in "natural language" are intrinsically doomed to fail.
자연어를 통한 프로그래밍을 홍보하는 프로젝트는 망하게 되어 있다.

(출처 : http://www.buggymind.com/366 )

소프트웨어 개발 방법론 중 가장 널리 쓰이고 있는 것은, 아마 아직도 폭포수(waterfall) 방법론일 것 같습니다. 요구사항 분석 - 설계 - 개발 - 검증으로 이어지는 이 단순한 방법론은 그 단순성과 명료함 때문에 '그다지 심각한 고민 없이도' 현업에 도입되어 쓰이고 있습니다. 그런데 폭포수 방법론에는 대관절 무슨 문제점이 있길래 그토록 많은 비난의 대상이 되고 있는 걸까요?

이미 많은 증거들이 있어서 사실 제가 또 언급할 필요까지는 없는건데, 집으로 돌아오는 비행기 안에서 이런 저런 생각하다보니 이런 결론에 이르게 되더군요. '단순성'

폭포수 방법론은 사실 프로젝트 진행중에 벌어지는 다양한 상황을 처리하기에는 좀 지나치게 단순합니다. 일단 요구사항 분석이 끝났다고 치죠. 그러면 설계 단계가 진행되는데, 이 와중에 새로운 요구사항이 등장한다면? 제품을 개발하는 사람들이 어떻게 대응할 것이냐와는 별개로, 방법론 자체는 그런 상황을 처리하기에 그다지 걸맞지 않습니다. 사람들이 유연하게 대처하면 괜찮습니다만, 사실 그런 지경에 이르면 '방법론'이라고 부르기 껄끄러워지죠. 지키지 않는 방법론을 과연 방법론이라고 부를 수 있을까요?

사실 폭포수 방법론은 그 단순성을 커버하기 위해 굉장히 많은 문서들을 요구합니다. (아마 해 보신분들은 아실 듯.) 가능한한 모든 시나리오를 문서에 적어두고, 그 틀을 벗어나는 상황이 벌어지지 않기를 기대하죠. 유스케이스 문서에 장황하게 적혀있는 개발 시나리오는 그 중 한 예입니다. 하지만 예외 상황(exceptional case)이 한 가지만 새로 생기더라도, 유스케이스 문서는 고쳐져야 합니다. 유스케이스 문서의 양이 너무 많아서, 대체 어디를 고쳤는지 추적하기가 좀 난감하다는 점도 문제죠.

폭포수 방법론의 대척점에 서 있는 개발 방법론들은, 그래서 가능하면 프로젝트 개발의 각 단계를 '제어 가능한' 작은 단계들로 쪼개려고 합니다. 스프린트(sprint) 같은 것은 그 좋은 예로, 한두주 단위로 쪼개진 기간 안에 설계-개발-검증을 완료하고 또 그 다음 구간에 설계-개발-검증을 반복합니다.

각각의 구간이 굉장히 짧기 때문에, 그 구간이 진행되는 만큼은 불확실성(uncertainty)을 적절히 통제할 수 있습니다. 그 구간이 끝나야만 새롭게 등장한 요구사항들을 검토할 수 있죠. (애자일 개발 방법론도 그 중 한가지입니다.)

그런데 단순히 하나의 방법론에서 다른 방법론으로 이행한다고 해서 크게 나아지지 않는 것이 있습니다. 그건 프로젝트에 참여하는 사람 사이에 발생하는 역학관계죠. 그런 역학관계때문에 발생하는 문제를 해결하려면, 누군가는 프로젝트에 참여하는 사람에게 긍정적인 영향을 끼칠 수 있도록 수직적 관리방식에 영향력을 행사하거나, 아니면 팀원들간의 소통방식을 개선해야 합니다.

이 문제는 사실 개발 방법론의 한 부분일수도 있고 아닐 수도 있습니다만, 적어도 프로젝트의 성공을 위해서는 반드시 고려해야 하는 부분입니다. 방법론이 달라진다고 해서 프로젝트에 대한 압박이 사라지지는 않겠습니다만, 그런 스트레스에 대응하는 내적 능력은 달라질 수 있습니다. 프로젝트를 수행하는 데 필요한 방법론을 개선하는 데 있어서 가장 크게 고려해야 하는 부분은 그런 내적 능력을 증진시켜 팀원 모두가 적절한 수준의 항상성을 유지할 수 있도록 만드는 것이 되어야 할 겁니다.

보통 스트레스가 적절한 수준 이상으로 늘어나면 그런 항상성을 유지하는 것이 불가능하기 때문에, 결국 프로젝트를 성공으로 이끄는 것은 (적절한 능력을 가진 팀원들이 모여있다는 가정 하에서) 결국 스트레스를 어떻게 관리할 것이냐 하는 부분으로 귀결되는 일이 많죠. )

스트레스를 관리하는 방식은 여러가지가 있겠습니다만, 최근까지 등장한 방법들은 대략

1. 업무 시간이 일정 시간 이상이 되지 않도록 하여 팀원들이 휴식할 수 있도록 하는 방법
2. 팀원들에게 프로젝트 결과후 성과에 대한 유무형의 보상을 제시하여 감내하도록 하는 방법
3. 팀원들의 의사소통 방식을 개선하여 업무와 관련한 스트레스를 줄이는 방법
4. 프로젝트 수행에 관계된 수직적 관리 오버헤드와 태스크 스위칭을 줄이는 방법
5. 프로젝트 진도와 성과를 정량적으로 추정할 수 있도록 하여 보고 오버헤드를 줄이는 방법

등등이 있겠습니다. 이 중 5는 4와 관련이 있고, 3은 1과 관련이 있습니다. 1이 되도록 하면 가장 좋겠지만, 프로젝트 말미에는 불가능한 경우가 많기 때문에 2가 반드시 있어야 합니다. 2를 흔히 우리는 비전(vision)이라고 부르는데, 비전 없는 프로젝트가 팀원의 이직을 초래하는 경우가 많기 때문에 주의해야 합니다.

비전을 제시할 때 주의해야 할 것은, 비전에 대한 착시효과입니다. 팀원들은 비전이 없다고 생각하는데, 관리자는 비전이 있다고 생각하는 경우가 그 한 예입니다. 관리자가 보는 비전과, 팀원들이 생각하는 비전은 굉장히 많이 차이가 날 수 있습니다. 따라서 2는 3과도 관련이 있습니다. 비전이 하나로 수렴되려면, 관리자와 팀원 간의 의사소통 방식이 개선될 필요가 있습니다. 비전은 이야기하지 않으면 알 수 없는 부분 중 하나이기 때문에, 관리자와 팀원은 서로를 설득하거나 비전에 대한 간격을 줄이기 위해 애쓸 필요가 있습니다.

비전을 제시하는 가장 좋은 방법은, '무엇이 어떻게 나아질 것인지'에 대한 정량화된 지표를 제시하는 것입니다. 아쉽게도, 사람들은 '심증'이라도 없으면 아무것도 믿지 않습니다. 프로젝트가 종료된 후 팀원들이 떠나는 것은, 아무도 그 부분을 어떻게 제시할 것인지 고민하지 않기 때문이기도 합니다.

그래서 떄로 프로젝트를 관리하는 것은 단순히 야근을 하지 않는 회사를 만드는 것 그 이상입니다. 성공적인 프로젝트 개발 방법론을 만들고 싶으신가요? 어쩌면 정말로 중요한 것은 그 너머 어딘가에 있을지 모릅니다. 방법론이 잘못되어 프로젝트가 실패하는 것이 아닌지 의심하고 계시다면, 여러분의 프로젝트가 팀원들에게 어떤 비전을 제시하고 있는지 자문해 보세요.

세상에는 비전 하나만으로 야근을 견뎌낼 사람들이, 아직은 많으니까요.

(출처 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20091129180815&type=det)

체계화된 프로세스와 산출물들로 무장한 개발방법론은 회사에 필요한 이상적인 무기를 제공해줄 것 같지만, 개발방법론을 도입해 크게 효과를 본 회사를 찾기는 쉽지 않다. 개발방법론이 개발을 더 지연시키고 개발자들을 번거롭고 힘들게 한다고 하기도 하고 개발방법론을 도입해서 사용하다가 포기하고 다른 방법들을 기웃거리기도 한다. 왜 이렇게 성공적으로 개발방법론을 도입하는 것이 어렵고, 개발방법론을 효과적으로 소프트웨어 개발에 적용하기 위해서는 어떻게 해야 하는지 알아보자.

독자들 중에서도 개발방법론들을 경험해 본 사람들이 꽤 있을 것이다. 실제로 개발방법론을 경험해 봤다면 그 개발방법론이 실제 소프트웨어를 개발하는 데 얼마나 도움이 되었는지 묻고 싶다. 즉, 이전에 나름대로의 방법으로 알아서 개발하던 때와 비교하면 얼마나 나아졌는지 묻고 싶다. 진짜 개발이 더 빨라지고 생산성이 높아졌는지? 아니면 개발은 오히려 느려졌고 과거보다 번거로울 뿐이지만 그래도 문서를 남겨야 나중에 정보 공유가 가능하니까 따르는 것인지 묻고 싶다.

필자는 소프트웨어 개발 컨설턴트로서 여러 개발자들이 이러한 질문에 답변하는 내용을 들을 기회가 많다. 그 중에 개발방법론은 고객이 요구하기 때문에 어쩔 수 없이 적용한 경우가 많았고, 실제로 개발하는 데는 필요도 없는 문서를 많이 만들어야 했으며, 그로 인해 개발에 더 많은 시간이 소요되었다는 얘기를 종종 듣게 된다. 하지만 회사에서 시키기 때문에 억지로 하곤 한다고 말한다. 시중에 개발방법론은 넘쳐나는데 왜 개발방법론을 적용해 큰 효과를 봤고 개발 생산성이 크게 향상되었던 경험을 접하기가 어려운 것일까?

■개발방법론은 필요하다

회사가 작을 때는 소프트웨어를 개발하는 데 있어서 대부분 확실한 개발 체계 없이 시작한다. 대부분의 경우 이렇게 주먹구구식으로 또는 가내수공업 형태로 소프트웨어 개발을 시작해도 별 문제가 없다. 체계가 없다는 것은 소프트웨어를 개발하는 데 문서를 제대로 만들지도 않고, 정형화된 프로세스 없이 개발자들의 경험에 의해 주먹구구식의 절차를 통해 별도의 개발 시스템 없이 순전히 개발자들의 기억력과 약간의 기록만 가지고 개발하는 것을 의미한다.

그렇게 개발하더라도 대부분 큰 문제에 봉착하지 않는다. 대부분의 정보라는 것도 그리 방대하지도 않아서 개발자들의 머릿속에 잘 저장되어 있고, 시스템도 그리 복잡하지 않아서 몇몇 소수의 개발자들이 머리를 맞대고 개발해도 별 문제가 없다. 또 충성심 가득한 개발자들은 회사에 언제까지나 있을 것 같고, 문제가 발생하면 특공대처럼 문제를 빠르게 해결한다.

이러한 시기에는 오히려 주먹구구 방식이 훨씬 빠르고 비용이 적게 든다고 생각할 수 있다. 실제로 이런 개발 방법이 여타 개발방법론을 적용한 개발 방법보다 효율이 더 높은 경우도 있다. 소수의 개발자에게 너무 많은 부분을 의존하고 있는 이런 방식은 장점인 것처럼 보이지만, 사실은 대단히 큰 위협요소가 된다.

성장하는 회사는 조직이나 소프트웨어의 규모가 점점 커지고, 개발해야 하는 제품의 수와 개발자는 점점 늘어가고, 더 이상 주먹구구식으로는 개발이 어려워진다. 회사는 점점 성장하는데 여전히 주먹구구식으로 개발하고 있다면 개발 과정은 점점 혼란스러워지고 설상가상으로 대부분의 정보를 머릿속에 담고 있는 개발자가 퇴사를 하기도 한다.

개발방법론은 이렇게 소수의 개발자에 편중되어 있는 대부분의 리스크를 시스템적으로 커버할 수 있도록 한다. 문서도 만들어야 하고, 프로세스도 따라야 하기 때문에 당장에는 기존의 주먹구구식의 방식보다는 시간도 많이 들어가고 비용도 많이 들어가는 것처럼 보이지만, 그 대가로 리스크를 줄일 수 있다.

모험심이 가득한 벤처 회사라면 얼마든지 리스크를 감수할 수 있겠지만, 회사가 점점 커지면 리스크보다는 비용을 선택하게 되어 있다. 따라서 주먹구구식으로 시작한 소프트웨어 회사라도 규모가 커지면 자연스럽게 개발방법론에 눈을 돌리게 된다.

이렇게 개발방법론을 시도해보기 위해 개발방법론 도입을 도와주는 컨설팅회사에 의뢰를 하기도 하지만, 대부분은 인터넷이나 책을 통해 개발방법론을 배워보려고 시도한다.

■개발방법론을 공짜로 배울 수 있을까?

개발자들은 인터넷에서 수많은 소스 코드 샘플을 보고 개발에 활용해 왔듯이, 개발방법론도 인터넷에서 특정 개발방법론의 템플릿과 샘플 그리고 프로세스를 가져와서 따라하면 개발방법론을 그럴싸하게 흉내 낼 수 있을 것으로 생각하기도 한다.

하지만 실제로 따라해보면 생각만큼 잘 되지 않는 것이 사실이다. 일단 기존에 주먹구구식으로 개발하던 개발자들은 개발방법론에서 제시하는 템플릿을 보게 되면 생전 처음 보는 내용도 많을 뿐더러 왜 그러한 것이 필요한지 진짜 의미를 이해하기 어렵고, 어떻게 작성해야 하는 것인지 파악이 잘 안 되는 것이 일반적이다. 그리고 이것이 정말로 자신의 회사에서 필요한 것인지 또는 필요 없는 것인지 판단이 안 되기도 한다.

그래서 일단 이것저것 시도를 해보고 효과가 신통치 않으면 나중에 “그거 해봤는데 별로더라”라는 자신만의 편협한 평가를 내리기도 한다. 이러한 서투른 시도는 개발방법론에 대한 나쁜 인식만 키워주기 때문에 아니 한 만 못하다.

여러 개발방법론에서 제시한 문서들이 작성하기 부담스럽다고 문서를 적게 작성해도 된다는 XP, 애자일(Agile) 등에 쉽게 눈을 돌리곤 하는데, 이 또한 너무 쉽게 접근해 실패하는 경우도 많다. XP 방법론이 모든 종류의 소프트웨어를 커버하는 것은 아니지만, 나름대로 적절하게 쓰이면 훌륭한 개발방법론인 것은 사실이다. 하지만, 왠지 간편해 보인다고 만만하게 접근하다간 큰 코 다칠 수 있다.

소프트웨어를 개발하는 데 있어서 가장 어려운 것 중에 하나가 무엇을 만드는지 결정하는 일이다. XP 방법론에서는 이러한 스펙 작성의 어려움을 덜고자 다른 접근을 하는데, 이것이 마치 스펙을 작성하지 않아도 되고, 문서를 적게 만들어도 되기 때문에 개발자들에게는 최고의 개발방법론인 것처럼 생각할 수도 있지만, 그리 만만한 것은 아니다. 스펙 대신 테스트를 이용하고 있지만, 이 또한 공짜로 되는 것은 아니다. 기존에 이미 분석 능력을 가지고 있고, 유닛 테스트(Unit test)에 능통한 경우라면 무리 없이 받아들일 수 있지만, 주먹구구 방식에 익숙한 경우라면 이 또한 어려운 도전이 될 수 있다.

즉, 그냥 쉽게 배우고 프로세스, 템플릿을 좀 익혀서 개발방법론을 제대로 적용해 보기는 어렵다. 공짜로 배워보기에는 개발방법론은 그리 만만하지 않다.

■몸에 맞지 않은 개발방법론이 문제

그렇다고 컨설팅을 통해 개발방법론을 도입하는 경우도 그렇게 쉬운 것은 아니다. 여기에는 몇 가지 함정들이 도사리고 있다. 자칫하면 이론에 치우치기 쉽고 회사의 역량이나 규모에 걸맞지 않은 무거운 개발방법론을 도입하게 되기도 한다. 개발방법론을 도입하려는 회사는 어떤 개발방법론이 자신의 회사에 알맞은지 직접 판단하기 어려우므로 외부의 전문가의 판단에 의존하는데 외부의 전문가가 실전 경험이 부족한 경우 회사의 특징과 역량 수준을 고려하지 않고 거대 개발방법론을 기계적으로 도입할 수 있다.

이 경우 큰 Learning Curve를 겪게 되고 결국 이를 극복하지 못하고 실패할 가능성이 높다. 따라서 자신의 회사에 알맞은 수준의 개발방법론을 선택해야 하는데, 이렇게 몸에 딱 맞는 개발방법론을 선택하는 것도 쉬운 일은 아니다.

또, 개발방법론을 하나 정해 놓고 회사의 모든 프로젝트에서 그 개발방법론을 무조건 따르게 하는 것도 문제다. 모든 프로젝트는 그 성격이 다른데, 하나의 개발방법론을 무조건 따르게 되면 간단한 프로젝트에서도 과도한 비용을 지불해야 한다. 이는 개발방법론이 자칫 관료화되는 것을 조심해야 한다는 뜻이다. 애초에 개발방법론을 도입한 이유를 망각하고 관리자나 프로세스 부서에서는 무조건적인 강요로 효율성을 떨어뜨리는데, 애초에 개발방법론을 도입할 때 유연하게 적용을 할 수 있는 여지를 남겨 둬야 할 것이다.

■방법론의 목적은 효과적인 개발

소프트웨어 개발방법론의 근본 목적은 소프트웨어를 빠른 시간 안에 적은 비용을 들여 요구되는 품질의 소프트웨어를 만들어내는 것이다. 이런 과정에서 개발자들이 혹사되어서는 안 되며 개발자들은 자연스럽게 소프트웨어 전문가로서의 능력이 향상되어야 한다. 즉 프로젝트도 성공하고 개발자에게도 도움이 되어야 진정한 방법론인 것이다.

그렇지 않고 단순히 절차를 지키기 위한 방법론, 개발자는 희생하면서 프로젝트만 어떻게든 성공하기 위한 방법론은 반쪽짜리일 뿐이다. 그럼에 불구하고 개발방법론은 왠지 무겁고 형식적이고 소프트웨어를 개발하는 데 진짜 도움은 되지 않는다는 생각들은 개발방법론 시도 실패에 대한 반작용으로 생겨난 경험담들 때문이다.

■국내 현실은 도 아니면 모

국내 대부분의 소프트웨어 회사는 소프트웨어를 개발하는 방법에 있어서 아래 세 가지의 부류로 나눌 수 있다.

첫째, 주먹구구식으로 소프트웨어를 개발하는 회사. 특별한 프로세스 없이 개발자들의 경험에 의존해 자체적으로 약간의 문서를 만들면서 소프트웨어를 개발하고 있는 회사. 주로 작은 회사들이며 개발자가 100명 이상인 중견 기업들도 상당히 많은 회사들이 이 단계에 머물러 있다.

둘째, 거대 방법론을 도입해서 흉내 내는 회사. 이 경우도 상당수가 내부적으로는 주먹구구이나 형식적으로는 방법론을 따라하고 있다. 주로 대기업에 해당하며 이들 기업은 개발 효율성보다 리스크 감소에 더 관심이 많으며 개발자들보다 회사의 힘이 압도적으로 크므로 추진력 강하게 이러한 개발방법론을 도입할 수 있고, 이러한 무리한 도입 과정에서 벌어지는 비효율성은 개발자들이 요령껏 편법을 이용해 피해가는 경우가 많다. 즉, 내용보다는 형식에 치우친 경우라고 할 수 있다. 이 경우 리스크는 줄어드나 개발 효율성도 따라서 줄어들어 일정 수준 이상을 넘을 수가 없다.

셋째, 거대 방법론이 회사에 맞지 않음을 깨닫고, 다시 주먹구구 개발방법으로 되돌아 온 회사. 그러면서 다른 방법이 없을까 고민하고 있는 회사들이다. 이런 실패의 경험이 반복될수록 내부에 불신이 쌓여가므로 쉽게 새로운 시도를 못하고 주먹구구와 개발방법론 사이를 떠도는 경우이다.

물론 이 세 부류에 속하지 않은 회사들도 있다. 그런 회사들은 스스로를 잘 알고 있으므로 별도로 언급할 필요가 없을 것이다. 그리고 그런 회사는 그리 많지 않다. 첫째와 셋째는 ‘도’에 해당하고 둘째는 ‘모’에 해당하는 경우이다. ‘도’도 바람직하지 않고 ‘모’도 소프트웨어를 개발하는 데 비효율적이다. 가장 좋은 경우는 ‘개’나 ‘걸’처럼 회사의 규모와 개발자들의 역량이 같이 성장해 나가면서 그 단계에서 딱 필요한 것들을 차근차근 하나씩 도입해 나가면서 내재화시켜 나가는 것이다.

■뭐든지 단계가 있는 법

뭐든지 배우려면 그 단계가 있고, 차근차근 배우고 익혀나가야 한다. 예를 들어서 골프를 배우고 싶다면 어떻게 될까? 소프트웨어를 취미로 개발하고 있는 것은 아니므로 골프로 프로 선수가 되는 것을 목표로 삼는 경우를 예로 들어보자.

골프를 처음 배워나가면서 타이거 우즈가 공을 치는 방법이 가장 완벽하다고 해서 그 방법을 그대로 따라하기란 불가능하다. 타이거 우즈가 그렇게 공을 치기까지는 십 수 년의 훈련이 필요했고, 타이거 우즈에 가장 알맞은 방법으로 진화해 온 것이다.

그런데 타이거 우즈가 그 방법으로 세계에서 가장 골프를 잘 치는 사람이 되었다고 그것을 그대로 흉내 내는 것은 어리석은 짓이다. 사실 그대로 흉내 내는 것 자체도 불가능하다. 타이거 우즈와 똑같이 치는 방법을 책을 쓰면 책 한 권은 넘을 것이다.

하지만 타이거 우즈는 그 방법을 일일이 생각하면서 공을 치지 않는다. 그 방법이 몸에 익었을 뿐이다. 그냥 공을 치면 저절로 되는 것이다. 이를 ‘내재화’가 되었다고 한다. 그 최고의 방법을 모델로 놓고 그대로 따라하고 훈련한다고 해서 그 방법을 익힐 수 있는 것은 아니다. 그러한 단계로 가기 위해서는 기초부터 배워나가는 방법이 따로 있을 것이다. 또 우리 몸에 맞는 모델은 타이거 우즈의 방법이 아닐 수도 있다. 그런데 최고의 방법이 타이거 우즈의 방법이라고 따라하는 것은 무리한 시도이며 대부분 포기하게 될 것이다.

진짜 프로골퍼를 목표로 하고 골프를 배우고 있다면 타이거 우즈가 골프를 치는 것을 그대로 따라하는 것이 좋은 방법이 아님을 누구나 알 수 있을 것이다. 재미로 마구 골프를 쳐보다가는 평생 프로선수가 되지 못할 것이다. 누구나 상식적으로 생각해도 아주 기초부터 차근차근 훈련을 받아나가야 한다는 것을 알 수 있을 것이다.

그런데 소프트웨어 세상에서는 이런 섣부른 시도들이 종종 발생한다. 개발자들의 역량은 아직 기초 수준인데 세계 최고의 방법론들을 도입해서 시도하면 개발자들도 저절로 세계 최고의 역량을 갖출 수 있을 것으로 착각하는 것 같다.

■개발방법론이 가르쳐주지 않는 것

개발방법론은 소프트웨어 회사라면 당연히 갖추고 있어야 하는 것은 가르쳐주지 않는다. 즉, 소스 코드를 어떻게 관리하고, 버그는 어떻게 추적할 것이며, 빌드/릴리즈는 어떻게 할지는 크게 상관하지 않는다.

하지만, 이러한 것들이 아직 체계적으로 갖춰지지 않는 회사가 개발방법론을 도입한다고 하면 따라가기만 하는 것도 벅차고 성공적으로 내재화되기는 어려울 것이다. 축구팀이 기초 체력은 갖추지도 못하고 기본적인 드리블이나 슛 실력이 부족한 상태에서, 다양한 전술과 전략을 익혀봤자 말짱 허사일 것이다. 여기서 말하는 기초 역량은 개발자에게 있어서 설계, 코딩 능력을 말하는 것은 아니다.

우리나라 개발자들의 코딩 능력은 전 세계 어디 내놔도 손색이 없을 만큼 뛰어나다. 여기서 말하는 기초 역량은 소프트웨어 회사라만 기본적으로 갖춰야 할 요소들과 설계, 코딩을 제외한 소프트웨어 전문영역의 다양한 지식들을 말한다. 이러한 것들은 워낙 당연한 것들이기 때문에 개발방법론을 만든 사람들은 소프트웨어 회사라만 당연히 보유하고 있어야 하는 것으로 생각한다.

방법론에서는 그러한 것들은 너무나 당연한 것이라 어떤 방법을 사용하든 별 개의치 않는 경우가 많기 때문에, 그러한 기초조차 제대로 갖추고 있지 않은 소프트웨어 회사라면 현재의 수준을 자각하지 못하고 자칫 그럴듯하게 포장된 방법론만 눈에 들어올지도 모른다. 이런 경우 방법론은 공염불이 되기 십상이다. 방법론을 고민하기보다는 기초부터 다져야 하는 경우이다.

■개발자들의 역량

기초란 회사에만 적용되는 것은 아니다. 개발자들도 개발방법론을 따라 개발하기 위해서는 필요한 역량이 있다. 가장 먼저 방법론 하면 산출물이 떠오르는데 대부분의 개발자들은 문서를 작성하는 데 익숙하지도 않고 그보다 먼저 문서 작성을 싫어한다. 이러한 상황에서 템플릿만 잔뜩 제공하고 이를 만들어내라고 하면 보통 괴로운 일이 아니다.

그럼 이쯤에서 의문이 생긴다. 과연 개발자가 문서를 잘 작성한다는 것은 무엇을 말하는 것인가? 개발자들 스스로도 본인이 문서를 잘 작성하고 또 잘 작성할 능력이 있는지 알지 못하는 경우도 많다. 개발자들의 문서 작성 능력을 한번에 알아내기는 어렵지만, 아래와 같은 질문을 해보고 싶다.

소프트웨어를 개발하면서 문서를 만드는 이유가 무엇이라고 생각하는가?

1. 고객이 원해서
2. 나중에 유지보수를 위해서
3. 개발 시간과 비용을 단축하려고

이 중에서 1이나 2라고 답하는 사람들은 아직 문서를 제대로 작성할 능력이 낮을 가능성이 높다. 그 동안 문서를 형식적으로 작성해 왔거나, 문서 작성을 거의 하지 않고 개발을 해오면서 문서는 거추장스러운 것이라고 생각하고 있는 경우가 많을 것이다.

이런 상태라면 개발방법론은 정말 거추장스러운 방해밖에 될 수 없다. 3번이라고 자신 있게 답할 수 있는 사람들은 개발하면서 문서들도 진정 필요한 시점에서 필요한 내용으로 작성했을 것이고, 그렇게 오랜 시간 훈련이 되어 필요한 문서 작성에 능숙할 것이다. 하지만 이렇게 3번이라고 자신 있게 답할 수 있는 개발자들이 많지 않은 것이 현실이다.

방법론에서 만들어내는 수많은 문서들은 문서 자체가 목적이 아니다. 모든 문서들은 다음 작업을 진행하는 데 필요하기 때문에 만드는 것이다. 따라서 다른 개발자들이 내가 만들어 놓은 문서들을 보고 그 다음 작업을 진행할 수 있어야 한다.

즉, 내가 작성한 스펙문서를 보고 설계를 담당한 개발자는 설계를 할 수 있어야 한다. 또 테스트팀은 테스트 계획과 테스트 케이스를 만들어낼 수 있어야 한다. 그리고 기술문서팀(Techpub)에서는 스펙문서만 보고도 매뉴얼을 작성할 수 있어야 한다. 또한 빌드/릴리즈팀에서는 빌드 준비를 할 수 있어야 한다. 하지만, 분석 역량이 부족한 개발자에게 템플릿만 제공해 스펙문서를 만들어 낸들 제대로 설계가 가능하고 테스트 케이스를 만들어 낼 수 없다.

그리고 방법론을 도입하고 약간의 교육으로 그런 수준까지 역량을 끌어올리기는 어렵다. 오히려 거대한 방법은 역량을 차근차근 끌어올리기에는 거추장스러운 옷처럼 방해 요소가 될 수 있다. 차라리 방법론 전체보다는 각 회사에 필요한 기초적인 부분을 추출해 조금씩 적용하는 것이 좋을 것이다. 그러한 과정을 거치면서 개발자들의 역량도 같이 키워나가야 한다.

여기서 필요한 것은 분석, 설계, 프로세스, 형상관리, 테스트 등 개발에 필요한 다양한 것들이다. 이러한 지식과 경험은 하루 아침에 배운다고 익힐 수 있는 것이 아니고, 회사에서 일하면서 조금씩 쌓아 나가는 것들이다. 또한 개발자 혼자서 스스로 익힐 수 있는 것도 아니고, 회사와 같이 개발 업무를 해나가면서 계속 배우고 익혀나가야 하는 것들이다.

■잘못 사용되는 개발방법론

개발방법론을 사용하는 이유가 고객이 해당 개발방법론을 적용하기를 원해서인 경우가 종종 있다. 이러한 경우 고객들도 목적이 개발방법론은 아니지만, 소프트웨어 개발에 대한 전문지식이 모자라므로 회사의 규정에 의해서든 여러 연유로 인해 개발방법론 적용을 요구하게 된다. 이 과정에서 개발방법론을 효과적으로 추려내서 적용하지 못하고 전체를 그대로 적용해 달라고 요청하는 일이 발생한다.

고객은 개발방법론 교과서에 나온 대로 기계적으로 산출물과 프로세스를 요구하고 소프트웨어 개발사는 비효율적인 것을 알아도 고객이 원하므로 울며 겨자 먹기 식으로 무조건 따라야 하는 경우가 많다. 하지만 우리나라 개발자들이 어떤 개발자인가. 모든 난관은 헤쳐 나가는 방법이 있다. 방법론에서 요구하는 문서는 어쨌든 만들어내고 있다.

다양한 편법을 통해 문서를 만들어 내고 있고, 대부분의 경우 문서들이 실제 소프트웨어를 개발하는 데 도움이 되지 않더라도 고객이 요구하는 문서는 충족하고 있다. 이렇다 보니 문서 작업은 소프트웨어를 개발하는 데 도움이 되기는커녕 시간만 축내는 낭비요소가 되곤 한다. 하지만 고객의 요구사항이기 때문에 따르는 수밖에 없다.

그 결과, 이렇게 만들어 낸 산출물은 고객에게도 실제로는 아무런 쓸모없이 책꽂이만 차지하는 경우가 허다하고 개발자들은 방법론에 대한 부정적인 생각만 키워나가게 된다. 이렇게 잔뜩 만들어낸 산출물은 유지보수 시 매우 유용하게 사용될 것으로 홍보하지만, 막상 유지보수 때는 개발에 참여했던 개발자를 찾게 되고 문서보다도 소스 코드를 가지고 유지보수를 하게 된다. 이런 것들이 반복되면 개발자들은 개발방법론이란 형식적이고 실제 소프트웨어를 개발하는 데는 별 도움이 안 된다고 생각하게 되고 진짜 제대로 된 방법을 더욱 더 배우기 어렵게 만든다.

■고객의 무리한 개발방법론 적용 요구

개발 회사는 아무리 개발방법론을 효과적으로 적용하려고 해도 이렇게 고객이 기계적으로 또는 규정에 의해 무리하게 개발방법론을 요구하는 경우에는 어쩔 도리가 없다. 실제로 고객이 개발방법론을 콕 찍어서 **CBD 또는**OOP 방법론을 요구하기도 하는데, 고객을 잘못 만나면 30~40종류 이상의 산출물을 에누리 없이 만들어 내야 하는 경우도 있다. 또 마일스톤마다 산출물을 검사하기도 하기 때문에 프로젝트가 끝나고 밤샘해서 산출물을 만들어 낼 수도 없는 노릇이다.

이러한 경우에는 진짜로 소프트웨어를 잘 개발하기 위해 필요한 문서와 고객의 요구 때문에 어쩔 수 없이 만들어야 하는 문서를 구별할 필요가 있다. 사실 웬만한 규모의 소프트웨어까지는 주요 문서 2, 3개로 충분히 프로젝트를 진행할 수 있고, 그 외의 문서들은 가능하면 최소한의 노력으로 고객의 요구를 만족시켜주는 수준으로만 만들어주는 것이 가장 효율적일 것이다.

이러한 상황에서 진짜 개발에 필요한 문서와 고객의 요구 때문에 어쩔 수 없이 만드는 문서의 구별이 없다면 자칫 모든 문서가 형식적으로 작성될 수도 있다. 이 과정에서 개발자들은 모든 문서에 대한 거부감만 커지고, 방법론을 제대로 적용한 것 같지만 실제 개발은 주먹구구와 다름없게 될 수도 있다. 아니 오히려 주먹구구에다가 문서를 잔뜩 만들어야 하므로 주먹구구만도 못한 경우가 될 수도 있다.

■방법이 목적인 개발방법론

이쯤 되면 개발방법론이 진짜 필요한 것인지 오히려 개발을 방해하는 것인지 헷갈리기도 한다. 하지만 서두에서 말했다시피 개발방법론의 목적은 소프트웨어를 적은 비용으로 짧은 시간에 효과적으로 개발하는 데 있다. 하지만 개발방법론을 만든 사람들의 진짜 목적은 돈을 버는 것이다. 방법론을 팔아서 돈을 버는 회사들은 자신들의 개발방법론을 비싸게 많이 팔아야 한다. 그리고 누구나 쉽게 흉내 낼 수 없게 만들어야 한다.

그래서 자신들의 개발방법론을 다른 방법론들과 차별화하기 위해 노력하고 점점 복잡하게 만들게 된다. 그래야 아무나 따라할 수 없게 되고 또 더욱 비싼 값에 팔 수 있다. 이러다 보니 소프트웨어 업계에는 소프트웨어를 개발하는 수많은 개발방법론들이 넘쳐나고 점점 복잡해지고 있다. 그 반작용으로 간단하다고 어필하고 있는 개발방법론이 출현하기도 한다.

이렇게 되니 대부분의 개발방법론 자체가 잘못된 것은 아닐지라도 우리 회사에 알맞은 개발방법론을 찾기란 쉬운 일이 아니게 돼 버렸다. 오히려 잘못된 함정에 빠지기 쉬운 상황이 된 셈이다.

특히 이전에 어느 정도 경험과 기초가 되어 있는 회사들은 개발방법론을 바라볼 때 어느 정도의 판단 능력을 가지고 자신의 회사에 필요한지 그렇지 않은지 판단할 수 있겠지만, 주먹구구에서 시작한 대부분의 소프트웨어 회사들은 그저 혼란스럽기만 할 것이다.

■어떻게 해야 하나?

필자의 경험에 의하면 국내의 많은 소프트웨어 회사들은 거대 개발방법론을 당장 도입하기에는 아직 적당한 상황이 아니다. 개발방법론을 거론하기 이전에 소프트웨어 회사라면 필수적으로 갖춰야 할 조직과 시스템을 먼저 갖추고 회사에 필수적인 프로세스를 만들어가면서 회사와 개발자 모두 필수 역량을 갖출 때쯤 그리고 회사가 좀 더 크고 복잡해지면 방법론을 생각해보는 것이 좋겠다.

또, ‘자전거’를 만드는 회사에서 ‘우주선’을 만드는 방법론을 사용해서는 안 된다. ‘자전거’ 정도의 소프트웨어를 만드는 수많은 국내 소프트웨어 회사들은 거대 개발방법론이 필요하지 않다. 고객이 요구해서 방법론을 꼭 적용해야 하는 경우가 아니고 자체적으로 소프트웨어를 잘 개발하는 것이 목적이라면, 회사에 알맞은 작고 가벼운 개발방법론이면 충분할 것이다.

럼 소프트웨어 회사가 갖춰야 할 필수 역량에는 무엇이 있는가? 가장 먼저 소스 코드 관리시스템, 버그 관리시스템, 빌드 자동화 등 기본적인 인프라스트럭처 시스템들은 갖춰야 한다. 물론 이것이 그렇게 쉬운 것은 아니다.

실제로 이들을 사용하는 많은 회사들이 기본적인 기능만 사용하고 있음에도, 전혀 이런 시스템들의 도움을 받지 않고 소프트웨어를 개발하고 있는 회사들보다는 훨씬 나은 형편이다. 이런 시스템들을 사용해 개발하다 보면 자연스레 그러한 시스템들에 묻어 있는 소프트웨어 개발 철학을 익히게 되고 기본적인 개발 프로세스도 배울 수 있게 된다.

또, 조직적인 측면으로는 소프트웨어 개발에 필수적인 전문 조직이 기본적으로 필요하다. 대부분의 소프트웨어 회사는 처음 시작하게 되면 개발자들이 전문성을 가리지 않고 온갖 일들을 다하게 된다. 개발도 하고 테스트도 하고 고객지원도 하고, 심지어는 영업을 하기도 한다.

하지만 회사의 규모가 커져 가는데 소수의 개발자들이 개발하던 방식과 똑같이 개발하고 있다면 효율성은 점점 떨어져 간다. 이럴 때는 꼭 필요한 부분부터 전문화된 팀으로 구분하고 전담자를 둬서 해당 분야의 전문성을 높이고 개발자는 개발에 집중할 수 있도록 해줘야 한다. 이러한 대표적인 분야는 테스트와 빌드/릴리즈다. 아직도 테스트를 전적으로 개발자들이 담당하고 있는 회사들이 많다.

개발자 10명만 있는 조직보다는 개발자 7명과 테스터 3명이 있는 조직이 더 효율적인 경우가 많다. 개발자들은 자신이 개발한 소프트웨어를 잘 테스트하지도 못하는데, 해당 소프트웨어의 스펙을 상세히 아는 사람이 개발자 밖에 없고 별도의 테스터를 뽑아도 개발자만큼 제품을 알아서 테스트하기 어렵다고 개발자에게 테스트를 계속 맡기는 것은 잘 하지도 못하는 일을 비싼 인건비를 주고 계속 맡기는 것과 같다.

테스트를 별도의 조직에 맡기는 것이 제품의 품질을 더 높여주고 비용 효율적이며 개발자는 개발에 더 집중할 수 있게 한다. 또 이와 더불어 빌드/릴리즈팀은 빌드/릴리즈 과정을 자동화하고 효율을 높임으로써 그 동안 보이지 않지만 많은 비용을 차지하던 것을 절약하면서도 개발을 더 원활하게 진행하도록 지원한다.

이런 회사의 기본 역량 확보와 더불어 개발자들은 문서를 작성하는 능력, 리뷰하는 능력, 분석 능력, 설계 능력 등 개발자들이 갖춰야 할 코딩 능력 외의 필수 능력들을 쌓아 나가야 한다. 이들은 학교에서 배울 수도 없고, 실무를 통해 오랜 시간에 걸쳐서 차근차근 쌓아 나가야 하는 것들이다.

이렇게 기본적인 조직, 프로세스, 시스템을 갖춰나가면 소프트웨어 회사가 내적으로나 외적으로 기본적인 역량을 갖추게 된다. 이쯤 되면 어떤 개발방법론을 접하더라도 이전보다는 조금 더 잘 이해할 수 있게 된다.

개발방법론을 성공적으로 도입하기 위해서는 소프트웨어 회사와 개발자들이 기초 역량을 갖추고 있어야 한다. 회사가 어느 정도 역량을 갖추고 판단력이 생기면 무작정 좋다고 하는 개발방법론을 도입하기보다는 회사의 수준에 알맞은 방법들을 취사선택해서 조금씩 받아들이는 방법을 택하게 될 것이다.

결국 개발방법론의 목적인 소프트웨어를 빠른 시간 내에 적은 비용으로 효율적으로 개발한다는 것에 좀 더 가까워질 수 있다.

mkfifo(const char *pathname, mode_t mode)

- 2개의 매개 변수가 필요하네.

- mkfifo(파이프사용할 파일명, 모드)

- 이걸로 FIFO 파일을 생성하면 이후로는 이파일을 가지고 파이프로 이동할 수 있다.

- 동일한 fd를 이용한다면 다른 프로세스에서도 메시지를 받을 수 있다.

- 주고 받는 양방향 불가.

수신하는 곳

#include 
#include 
#include 
#include 
#include 

#define  FIFO_FILE   "/tmp/fifo"
#define  BUFF_SIZE   1024

int main( void)
{
    int   counter = 0;
    int   fd;
    char  buff[BUFF_SIZE];

    if(mkfifo(FIFO_FILE, 0666) == -1)
    {
        perror( "mkfifo() failed\n");
        return -1;
    }

    if (( fd = open( FIFO_FILE, O_RDWR)) == -1)
    {
        perror( "open() failed\n");
        return -2;
    }
    printf("FD=%d\n", fd);

    while( 1 )
    {
        memset( buff, 0x00, BUFF_SIZE);
        read( fd, buff, BUFF_SIZE);
        printf( "%d: %s\n", counter++, buff);
    }
    close(fd);
    return 0;
}
/* The end of function */

송신하는 곳

#include 
#include 
#include 
#include 
#include 

#define  FIFO_FILE   "/tmp/fifo"

int main( void)
{
    int   fd;
    char *str   = "TEST FIFO IPC";

    if ( -1 == ( fd = open( FIFO_FILE, O_WRONLY)))
    {
        perror( "open() failed\n");
        return -1;
    }
    printf("FD=%d\n", fd);

    write(fd, str, strlen(str));
    close(fd);
    return 0;
}
/* The end of function */

수신쪽 결과 
$ ./recv 
FD=3
0: TEST FIFO IPC
1: TEST FIFO IPC
2: TEST FIFO IPC

송신쪽 결과
$ ./send 
FD=3
$ ./send 
FD=3
$ ./send 
FD=3

=============================================

open함수는 파일 열고 fd를 반환한다.

write함수는 바로 그 fd에다가 쓴다.

같은 시스템에서 같은 파일을 열면

동일한 fd를 가지게 되므로 위와 같이 쓸 수 있다.

=============================================

출처 http://forum.falinux.com/zbxe/?document_srl=420145