저도 처음에는 프로그래밍 언어만 할 줄 알면 프로그램을 만들 수 있다고 생각했던 적이 있었습니다.
실제로 그렇게 만들었던 프로그램도 꽤 많지요. ^^

하지만, 지금 생각해 보면 그렇게 만들었던 프로그램은 세상에 빛을 보지 못했거나 그리 오래 가지 못했던 것 같습니다.
반면에 체계적인 분석과 설계로 만들었던 몇몇 솔루션은 아직도 현업에서 잘 사용하고 있는 것을 볼 수 있었습니다.

바로 체계적인 분석과 설계라고 하는 것이 소프트웨어 개발 생명주기(Software Development Life Cycle)의 핵심이 아닌가 합니다.
여기에 추후 운영에 필요한 유지보수도 무시할 수는 없겠죠..

흔히 SDLC라고 하면 Waterfall, Prototyping, Spiral, RAD, Incremental Development, Evolutionary Development, 4 Generation 등의 모델을 들면서 어렵게 이야기 하는 경우가 많습니다.

물론 어떤 모형을 사용하는지 중요하지만, SDLC가 왜 필요한지 생각하지 않고 사용하는 것은 무의미하다고 봅니다.
단순하게 이런 모델로 개발을 진행한다고 하면서 코팅부터 하고, 프로젝트 개발이후 문서작업을 따로 하는 경우를 종종 봐왔기 때문입니다.

특정 모델들을 떠나서 가장 기본적인 또는 고전적인 SDLC의 형태는 다음과 같습니다.


프로젝트를 수행하려면 먼저 계획을 세워야 합니다. 투입될 인력이나 기간을 토대로 비용도 산정해 봐야하고 비즈니스 타당성도 검토해 봐야겠죠.. 물론 분석이나 설계 없이 이 작업을 정확하게 할 수는 없을 겁니다.
그러나 기존의 경험을 토대로 개괄적인 계획은 세워야만 프로젝트를 시작할 수 있을 겁니다.
추후 분석과 설계를 토대로 계획을 수정할 수도 있을 겁니다.

다음으로 분석과 설계입니다. 먼저 둘의 차이점에 대해서 알아보죠..
분석은 무엇(what)에 관심을 갖는 것이고 설계는 어떻게(how)에 관심을 갖는 겁니다.
만들어야 할 프로그램은 하나지만, 그것을 만드는 방법은 여러가지가 있을 수 있습니다.

즉, 분석은 만들려고 하는 프로그램을 하나로 명확하게 정의하는 과정이라고 할 수 있습니다.
설계는 프로그램을 만드는 방법을 찾아보는 것이라 할 수 있겠죠..

이것을 반대로 수행한다면 어떨까요? 어떻게 만들까를 먼저 생각하고 무엇을 만들지를 결정한다..
말이 안되는 것처럼 보이지만 의외로 현업에서 자주 발생하는 듯 합니다.
특히, 개발자의 관점에서 브레인스토밍 회의시 무엇을 만들지를 이야기 하고 있는데, 어떻게 구현할지를 걱정해서 "이건 안된다, 저건 안된다" 하는 경우를 종종 볼 수 있었습니다.

앞에서도 이야기 했듯이 분석에서 만들려고 하는 프로그램을 명확하게 정의해야 합니다.
그것을 어떻게 구현할 지는 설계 단계에서 결정하면 되는 것이죠..

"개발하지 못할 것이 어디 있겠는가?"하는 마인드가 분석 단계에서 중요하다고 볼 수 있겠죠..

설계 단계에서는 가장 효율적이고, 사용자가 편리하고, 개발을 빠르게 할 수 있는 방법을 찾아서 정리하고 모듈별로 나누는 작업까지 해야 겠죠..

코딩및 구현은 프로그램 개발에 있어 기본적인 사항이라 할 수 있습니다.

테스트의 중요성이 요즘 커져서 Test Driven Development라고 하는 방법도 나오고 있고, JUnit과 같은 단위 테스트 도구도 많이 발달한 상태입니다.
통합 테스트에 대해서는 좀 더 고려가 필요하겠죠...

마지막으로 유지보수입니다. 실제 보면, 개발 기간보다 시스템을 운영하는 기간이 더 길기 때문에 유지보수의 중요성이 점차 커지고 있습니다. 천만원에 개발했는데, 유지보수에 억단위가 들어간다면 좋은 시스템은 아니겠지요..

기본적인 SDLC의 단계를 나열해보니, 그리 어렵지 않다는 생각이 들겁니다.
물론 실제 적용하다 보면, 구현 단계에서 특정 부분을 변경할 경우 해당하는 분석/설계 산출물까지 변경해야 하는 번거로움이 존재할 수 있습니다.
이런 문제들은 반복이나 자동화 툴을 이용하는 다양한 SDLC의 모델들을 통해서 해결해 나갈 수 있을 것입니다.

중요한 것은 소프트웨어 개발 생명주기가 단순히 문서 작업을 늘리고, 이론적일 뿐인 방법론이 아니라 제대로 된 소프트웨어를 개발하기 위한 필수 사항이라는 것을 이해해야 한다고 봅니다.

[읽을만한 자료]
소프트웨어 개발 생명 주기의 이해
코딩보다 먼저 할 일 ‘분석과 설계’
설계도가 우선, 그 다음이 구현이다

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

조엘 온 소프트웨어 조엘 스폴스키 지음, 박재호.이해영 옮김/에이콘출판

어느날 FineApple(http://fineapple.org/)이 한번 읽어보라고 준 책입니다.
(좋은 책 소개해 준 FineApple님에게 감사드립니다. ^^)

처음 받았을 때는 표지도 좀 별루고~ 다른 볼 책들도 있었기에.. 한쪽에 두고 있었슴다. 그러다가 "이거 한 번 읽어볼까.." 하고 봤더니..
오~~ 처음부터 내용이 너무 괜찮은 거예요..

개발자에 대한 이야기들..
유니코드~~
기능명세 관련 글..

내용이 너무 괜찮아 웹에서 찾아봤더니.. 2006년인가 베스트셀러에 강컴 어워드였더군요.. (그동안 책을 너무 안읽었어 -.-)

끝까지 읽어보니 첫 느낌대로 책의 내용은 괜찮았습니다.
이것저것 블로그 글을 모아둔 것이라서 그런지.. 뒤로 갈수록 약간 산만한 감은 있지만..
전체적으로 좋은 내용이었구.. 번역도 나름 매끄러웠습니다.

그래서 앞으로는 직접 블로그를 방문해서 읽어보려구.. 사이트를 북마크도 해 두었습니다.
http://www.joelonsoftware.com/

일단 기억에 남는 내용을 좀 적어보면..

개발자 선발하는 부분이 첫번째로 떠오릅니다.
"조금이라도 아닌 것 같다." 혹은 "글쎄.. 라는 답이 나온다.. "
또는 "다른 팀에서는 괜찮을 것 같은데.. 우리팀은 아냐.."

이런 경우, 무조건 No라는 겁니다.
솔직히 실질적인 개발자가 부족한 우리 현실에서는 상당히 어려운 문제죠.. -.-
그러나.. 잘못 뽑은 개발자 한명이 프로젝트를 망칠 수 있으니..
절대적으로 조엘의 말에 공감하는 부분이었슴다..

두번째는 한 장에 걸쳐 언급된 유니코드...
한글과 같은 멀티바이트를 처리할 때는 꼭 알아둬야 하는데요~
솔직히 저도 정확히 몰랐다는..

특히, IE가 자동으로 언어인코딩을 처리한다는 점.. (음.. 한국어 자동감지가 그거였던 것 같습다.)
항상 보면서도 몰랐네요.. -.- (어쩐지 불여우에서는 가끔 내 홈피가 이상한 문자로 나오더라니.. )

세번째로는 조엘 테스트..
12개 항목 중.. 7점 정도~~

10점 이하는 심각하다고 하니.. 쩝~~ 심각한 편이네요 -.-
참고로 12개 항목은 다음과 같습니다.

1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어 낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?

그외에도..
닭이 먼저냐 달걀이 먼저냐~ 하는 부분에 대한 이야기~~
마이크로소프트의 API 전쟁 관련 이야기에서의 하위 호환성 문제...
성과급이나 측정이 오히려 해가 된다는 이야기 ~~ (역시 공감.. ㅋㅋㅋ)
종이 프로토타이핑.. (음.. 어떤 교수님이 프로그래밍에서 손뮬레이션이 중요하다고 하셨는데.. 일맥상통)

그러나.. 설계를 최대한 늦춰야 한다는 부분은 XP하고도 약간 상충된다고 나와있는데요..
제 경험상으로는 XP식으로 빠른 개발을 들어가는 것이 설계를 늦추는 것보다 낫기는 했는데~~
설계문서로 버그를 줄일 수 있다면, 조엘의 방식이 맞을 수 있겠으나~~
추상화된 설계를 보고 버그를 찾아낼 수 있는 사람이 과연 몇이나 될까요??
그래서 전 빠른 설계.. 빠른 수행.. 그리고 반복의 XP가 더 낫다고 보네요~~

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.