애자일(Agile) 방법론 시리즈를 읽고... 책을 읽자

저는 컴퓨터 전공은 아니지만, 직장을 프로그래머로 취직하였습니다.

임베디드펌웨어(생활 속의 각종 전자 장치 내에 탑재되어, 기기를 동작시키고 제어하기 위한 소프트웨어)를 시작으로 하여, 컴퓨터에서 동작되는 프로그램(Visual Basic, Visual C/C++)을 개발한 경험을 갖고 있습니다.

특별히 기술을 전수해주는 멘토없이 여러 가지 프로그램을 개발해왔습니다. 제안서와 설계서가 중요시되는 SI프로젝트에도 잠시 관여했었지만, 대부분 사내의 개발 계획에 의한 프로젝트를 수행하였습니다.

늘 약간 아쉬웠던 부분이 있었는데, 나름대로 NASA에서 만든 문서도 복사하여 읽어보고 했지만, 소프트웨어공학 책에서 읽었던 것들을 현실 프로젝트에 접목하는 것이 생각보다 쉽지 않다는 점이었습니다. 실천적인 문서는 찾기 어려웠고, SI(시스템통합)프로젝트 등을 통해 타사와 공동 개발을 하여 배우는 기회도 별로 없었습니다.

다행히 프로젝트가 대규모가 아니었으므로, 대부분의 경우 복잡한 설계를 요하지는 않았습니다. 물론, 화면과 키패드가 있는 장치를 RTOS의 코어만 있는 상태에서 구현하는 프로젝트는 코드가 대단히 길어져서 개발완료와 유지보수에 어려움을 겪은 적도 있습니다.

최근 스티브 맥코넬의 소프트웨어생존전략을 읽어보고, 지금 리뷰하는 애자일방법론을 읽다보니까, 이런 기억들이 납니다.

여럿이 같이 개발하는 경우에는 Visual SourceSafe를 설치해서, 코드의 체크인/아웃도 적용했는데, 일부 직원은 불편하게 여겨서 가끔 체크인을 안하거나 잊는 경우가 있었습니다.

같이 앉아서 코딩하는 것도 해보았는데, 코드를 같이 공유하여 개발하는 것은 대체로 프로젝트 마무리에 도움이 되었던 것 같습니다. 그리고, 일부 직원의 경우에는 프라이버시 보호와 믿는 차원에서 코드를 같이 안본 경우도 있었습니다. 나중에 유지보수할 때는 아무래도 같이 개발한 경우가 편하였지요.

가장 신경쓰이는 부분이라면, 문서화였던 것 같습니다. 일단, 표준 포맷을 갖고 있지 않았고, 사내 프로젝트이다보니 개발하다보면 문서화는 뒷전이 되는 경우가 많고, 코드 내에 있는 코멘트도 처음에 기록하고 수정한 후에 코멘트가 개정이 안되는 경우도 있었습니다.

소비자에게 릴리즈했는데, XML로 되어 있는 표준을 지키지 않아서 다른 프로그램과 호환이 안된 것도 기억이 납니다.

개발자를 신뢰하지 못하는 갑을 만날 경우 생기는 스트레스와 잦은 요구사항의 변경으로 인한 일정의 지연은 심각한 문제들 중의 하나였지요.   

그외 자잘한 문제점들을 많이 겪게 되었지만, 어떻게든 프로젝트들은 늦더라도 완결을 하였습니다.

이상 나열한, 누구나 프로그래밍을 하다보면 한번 쯤 경험하게 되는 실수와 낭비들을 줄이기 위해서는 시간을 내서 아래 책들도 더 읽어볼 필요가 있겠습니다.

특히, 애자일 방법론의 경우 과거 전통적인 소프트웨어의 개발방법을 부정하는 부분이 있으므로, 편견을 갖고 있는 개발자의 시야를 넓혀준다는 면만 보아도 충분히 가치가 있다고 하겠습니다. 물론, 그 내용이 읽어보면 공감이 가는 부분이 많습니다.  

그럼, 각 서적별로 간단하게 내용을 적어보겠습니다.

 

애자일 프랙티스
벤컷 수브라마니암,앤디 헌트 공저/신승환,정태중 공역 | 인사이트(insight) | 2007년 08월

책의 제목에서 알 수 있듯이, 다루는 내용이 상당히 광범위하고 구체적이었습니다. 45가지 팁의 나열로 갈음합니다.

1)비난은 버그를 수정하지 못한다.
2)땜질식 수정에 빠지지 말라.
3)사람이 아니라 아이디어를 비평하라.
4)올바른 일을 하라.
5)기술변화를 따라 가라.
6)여러분 자신과 팀에 대한 기대치를 높여라.
7)새로운 기술을 배우고 예전 기술은 버려라.
8)계속 왜냐고 물어보라.
9)일이 쌓이기 전에 부딪혀라.
10)고객이 결정하도록 하라.
11)좋은 설계는 지도다. 스스로 진화하게 하자.
12)필요에 따라 기술을 택하라.
13)프로젝트를 항상 릴리즈 가능하게 하라.
14)일찍, 자주 통합하라.
15)시작부터 애플리케이션을 자동 배치하라.
16)분명히 보이게 개발하라.
17)점진적으로 개발하라.
18)실제 일을 기초로 해서 견적하라.
19)자동화된 단위테스트를 사용하라.
20)만들기 전에 사용하라.
21)처이는 다른 결과를 만든다.
22)핵심비즈니스 로직에 해당하는 테스트를 만들자.
23)얼마나 많은 일이 남았는지 측정하라.
24)모든 불평은 진실을 담고 있다.
25)독창적이지 않고 명확하게 코드를 작성하자.
26)이야기하는 주석.
27)능동적으로 트레이드 오프를 평가하자.
28)짧은 수정/빌드/테스트 주기 안에서 코드를 작성하자.
29)동작하는 가장 단순한 해결책을 만들자.
30)클래스에 집중하고 컴포넌트를 작게 유지하라.
31)묻지 말고, 말해라. 객체나 콤포넌트에게
32)코드를 교체하여 시스템을 확장하자.
33)문제와 해결책의 로그를 보존하자.
34)경고를 에러처럼 다루자.
35)문제를 격리해서 공격하라.
36)모든 예외를 처리하거나 전달하라.
37)유용한 에러 메시지를 제공하자.
38)스탠드업 미팅을 사용하자.
39)좋은 디자인은 활동적인 프로그래머로부터 진화한다.
40)코드 공동 소유를 강조하자.
41)멘토가 되자.
42)다른 사람에게 문제를 해결할 기회를 주자.
43)준비되었을 때만 코드를 공유하라.
44)모든 코드를 리뷰하라.
45)다른 사람에게 계속해서 알리자.

 

린 소프트웨어 개발
메리 포펜딕,톰 포펜딕 공저/김정민,김현덕,김혜원,박영주 공역/김창준 감수 | 인사이트(insight) | 2007년 08월

애자일을 (소프트웨어 개발에 적용하여) 실천하기 위한 도구 22가지를 다음의 7가지 간단한 주제로 나누어 하나씩 설명하고 있습니다.

1)낭비를 제거하라.
2)배움을 증폭하라.
3)가능한 늦게 결정하라.
4)최대한 빠르게 납품하라.
5)팀에 권한을 위임하라.
6)통합성을 구축하라.
7)전체를 보라.

이 책은 꼭 소프트웨어 개발자가 아니더라도, 여러 가지로 도움이 될 것임에 틀림없습니다. 그것은 미국에 비해 월등하게 짧은 개발기간과 높은 생산성을 보여준 토요타자동차의 방식을 바탕으로 소프트웨어 개발에 적용하였기 때문입니다.

특히 기억에 남는 것을 몇가지 나열하고 마무리합니다.

가치흐름도의 개념은 처음 보는 것이었습니다. 기존 폭포수 개발방식에서는 각 단계가 순차적으로 넘어가야하므로 피할 수 없는 대기시간이 있습니다. 이러한 낭비는 일반적인 제품개발 과정에서도 나타나는 것이므로, 하나의 분석 방법으로 활용해도 좋을 듯합니다.

ISO9000과 CMM등에 대해 비판을 하면서도, 이러한 기존 시스템과의 차이 및 조화, 활용도 다룸으로써, 애자일의 유연한 면을 해치지 않습니다.

리더십과 동기부여에 대한 내용은 상당히 공감이 많이 가는 부분으로써, 여러 가지 생각을 하게 합니다. 사실, 회사에서 비효율적인 면의 대부분은 부족한 리더십으로부터 비롯된 경우가 많기 때문입니다. 또한, 직원들을 믿지 못하고 관리하려고 하는 구태의연한 태도도 일조하고 있습니다.

측정의 오류를 회피하는 내용의 설명에서 예를 든 것도 특이하다고 느꼈습니다. 비싼 투자를 한 공장가동률을 높이는 것이나 재무재표에 의한 기준을 갖고, 기계적으로 공장을 운영하는 것만이 능사가 아니다라는 것입니다. 애초에 측정 기준이 잘못되었으니, 결과가 좋을 리가 없다는 것입니다.

약간 와닿기 어려운 내용이었던, “늦게 결정하기"의 좋은 예로써, HP의 사례를 들고 있습니다. 그것은 프린터가 각국마다 전기코드가 다르므로, 최종적으로 물류창고에서 전기코드를 생산하는 것이 비용은 조금 더 들지만, 재고관리와 종합적인 차원에서 이익이라는 것입니다. 공장이 아닌 곳에서 만드는 것은 비록 상식에 맞지 않지만, 효율적인 것입니다.

 

익스트림 프로그래밍 2판
켄트 벡,신시아 안드레스 공저/김창준,정지호 공역 | 인사이트(insight) | 2006년 07월

이 책의 추천사에서 이클립스로 유명한 에리히 감마는 XP중에 다음 사항을 적용하고 있다고 합니다.

1)초기에 자주 자동화해서 테스트하라
2)점진적 설계
3)매일 배치(deploy)
4)고객참여
5)끊임없는 통합
6)짧은 개발주기
7)점진적 계획

1부에서는 익스트림프로그래밍(XP)개발을 이끌기 위한 다섯가지 가치로써, 의사소통, 단순성, 피드백, 용기, 존중을 들고 있습니다. 이러한 가치들을 바탕으로 여러 가지 실천 방법을 제시하고 있습니다. 다소 지루하게 느껴질 수도 있지만, 어차피 옆에 두고 자주 찾아봐야하니까 대강 주욱~ 읽어줄 수 있습니다.

2부에서는 XP의 여러 가지 철학에 대해 서술하고 있습니다.

저도 XP에 대해서는 마이크로소프트웨어 잡지를 통해서 진작부터 알고 있었고, 심지어 이 책을 읽기까지 했었지만, 당시에는 별다른 감흥을 받지 못하였습니다. 하지만, 최근에 스티브 맥코넬의 저서들을 읽은 후에는 다르게 다가오는군요.

사실, 새로운 것에 대해 본능적으로 거부감을 갖는 프로그래머가 많을 것으로 알고 있습니다. 그렇다면, 그것이 누구를 위한 거부감인지 잘 생각해 보셔야할 것입니다. 다른 누구도 아닌 나 자신을 위해서라도, 오픈마인드를 가지고, 편견/선입견을 버려야할 때입니다.

어쨌든, 소프트웨어의 위기라는 말은 지금보다 훨씬 덜 발달했던 과거부터 늘 있어왔습니다. 근거는 없지만(?) 한국의 프로그래머보다 열심히 일하고 반짝 반짝 빛나는 아이디어를 가진 (외국)사람들은 많지 않다고 자부합니다. 그럼에도 불구하고, 많은 프로그래머들이 방황하고 좌절하는 이유가 무엇일까요? 그것은 이러한 소프트웨어공학적인 측면의 발달이 느렸고, 이러한 좋은 정보를 받아들이려는 준비가 안되어 있었고, 고용주와 노동자, 갑과 을의 관계라는 후진적인 마인드를 소유한 사람들(주로 경영층이겠지만) 때문일 것입니다.

2001년에 애자일이라는 용어를 만들고, 이렇게 책을 쓰는 사람들이 대단하다고 생각을 합니다. 하지만, 그 내용을 살펴보면 꽤나 상식적이고 합리적이라는 것에 한번 더 놀라게 됩니다.

어떻게 보면, 우리는 이미 그 방법들을 자신도 모르게 현업에서 쓰고 있을 지도 모릅니다. 다만, 내맘대로 할 수 없는 공공SI프로젝트나 하청프로젝트에서 적용하는 것은 완전히 별개의 이야기일 것 같고, 그러한 현황에 대해서는 저도 잘 모르고 있고, 관심있게 찾아보려고 합니다.   


덧글

댓글 입력 영역