레이블이 설계인 게시물을 표시합니다. 모든 게시물 표시
레이블이 설계인 게시물을 표시합니다. 모든 게시물 표시

2012년 8월 15일 수요일

7명이 할 수 있는 일을 70명이 하고 있는 이유

최근에 한 글로벌 소프트웨어 회사(Y사, 가칭)의 한국 지사 관계자에게 들은 이야기이다.
비단 Y사 얘기만은 아니다. 세계적인 소프트웨어 회사의 한국지사에서 종종 벌이지는 일이다.

Y사의 본사에서는 처음에 한국지사를 만들었을 때 한국에서도 미국의 개발 프로세스를 따를 것을 종용했다고 한다. 하지만 한국에서 채용된 개발자들은 미국의 개발 프로세스는 너무 무겁다고 한국 방식으로 개발했다고 주장을 했다. 그리고는 미국의 개발 주문에 대해서 믿을 수 없는 속도로 해결을 해나가기 시작했고, 미국 본사는 이런 경이로운 결과를 보고는 한국식 개발을 묵인할 수 밖에 없었다.

그뒤 몇 년이 지난 지금은 어떻게 되었을까? 미국 본사의 개발 프로세스를 착실히 따른 호주 지사와 엄청난 차이를 보이고 있다고 한다. 똑같은 일을 호주 지사에서는 7명이 처리를 하고 있고 한국 지사에서는 70명이 야근까지 해야 간신히 처리를 하고 있다고 한다. 

그렇게 된 이유가 분석/설계도 없이 빨리빨리 개발을 하다보니 아키텍처가 엉망이고 개발자들이 많이 바뀌었는데 내용을 아는 사람도 별로 없다고 한다. 뭐 하나 고치려고 해도 보통 어려운 것이 아니라고 한다.

전해 들은 얘기라서 과장이 있다고 해도 문제가 심각하고 이미 많이 망쳐 놓은 것은 사실이다.

글로벌 소프트웨어 회사라고 하더라도 한국에 와서 착각하는 것들이 있다. 놀라운 속도를 보여주는 한국식 개발방식을 신기해 하지만 그 문제점을 피부로 심각하게 알지 못한다.  스펙도 제대로 작성하지 않고 분석/설계/구현을 섞어서 빠르게 개발하는 것이 신기해 하지만 얼마나 큰 문제가 있는지 실리콘밸리 회사들도 잘 모른다. 그런 식으로 개발해 본적이 없기 때문이다.

그렇다고 글로벌 소프트웨어 회사가 본사의 개발 프로세스를 강제화 한다고 잘 적용되는 것은 아니다. 한국에서 잔뼈가 굵은 개발자들은 몸에 밴 개발 방식 때문에 적응하기가 매우 어렵다. 차라리 신입사원들을 뽑아서 교육시키면서 개발을 하는 것이 더 빠를지도 모른다.

이는 한국의 소프트웨어 회사 내부에서도 그대로 적용된다. 글로벌 소프트웨어 회사의 개발 프로세스가 아무리 좋다고 하더라도 한국의 소프트웨어 회사에는 바로 적용이 안된다. 대부분은 무리한 시도이고 실패한다.

변화를 감당할 수 있을만큼씩 조금씩 바꿔나가야 한다.

2012년 8월 2일 목요일

개발자의 취향

소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다.

이 경우 Architecture상의 심각한 문제점을 내포하게 된다.

제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다.

Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 

이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.
그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에 심각한 문제를 초래하기도 한다.

그럼 어떻게 하면 이런 잘못된 결정을 막을 수 있을까? 답은 의외로 간단하다. 분석을 제대로 하는 것이다. 제대로된 스펙문서에는 최종 결론 뿐만 아니라 그런 결정에 이르게 된 근거와 의논 과정도 적어야 한다. 그래야 스펙을 읽는 사람들이 의문가 이의를 제기하지 않는다.

예를 들면 다음과 같은 것들이 있다.
  • 현재는 Windows만 지원하지만 3년안에 Mac을 지원할 가능성이 90%라서 엔진은 ANSI-C로 개발을 하고 UI를 QT Framework를 이용한다.
  • Java와 C로 모두 개발이 가능하고, 프로젝트 리더가 C언어를 더 좋아하지만, 기존 제품들이  Java로 되어 있고 회사에 Java개발자가 대부분이므로 Java를 선택한다.
  • 회사에 자연어 처리 전문가가 있지만 자연어 처리 엔진의 직접 개발 비용과 상용라이브러리를 구매했을 때를 비교했다. 10년 후까지의 유지보수 비용을 고려하여 자체 개발보다는 상용라이브러리 구매를 선택했다.
  • 현재 프로젝트는 아이폰/아이패드 용으로만 계획을 세웠지만, 영업부서와 논의결과 안드로이드를 지원할 가능성이 있어서 제품의 난이도가 그렇게 높지 않아서 Adobe Air를 사용하기로 했다.
이러한 결정 과정은 프로젝트를 진행하면 수십가지 또는 수백 번 진행이 된다. 스펙문서에는 이러한 결정과정까지 적어야 정확한 내용이 된다. 또한 중간에 상황이 변경되면 신속하게 영향평가를 할 수 있고 스펙을 변경할 수 있다.

소프트웨어 프로젝트는 개발자의 취향대로 진행되는 것이고 합리적인 근거를 바탕으로한 Architecture 결정에 따라 진행되어야 한다.

2012년 7월 16일 월요일

한 SI회사의 프로세스에 대한 오해

필자는 업계의 여러 사람과 얘기할 기회가 많다.

최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다.

SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.
"공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.

"공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다.

최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.

그래서 진행한 것이 해외에서 "분석/설계"를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 "구현"만 하면 되도록 하는 프로세스를 만든 것이다.

실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 "구현"은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다.

이렇게 공정을 분리하려면 "분석/설계" vs "구현" 보다는 "분석" vs "설계/구현"이 더 낫다.

설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 "설계/구현"을 할 수 있기 때문이다.

여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.

더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다. 

이렇게 제대로 "공정분리"를 하기 위해서 대전제가 하나 있다. 

바로 "분석"역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다.
현재의 분석역량은 기껏해야 "기능"분석과 약간의 "비기능"을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다. 

필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다.

시행착오를 겪는 시간은 짧을수록 좋다.

2009년 6월 29일 월요일

도대체 얼마나 자세히 적어 달라고?!

소프트웨어 개발자들에게 문서 작성은 고역이 아닐 수 없습니다. 그래서 문서는 소프트웨어를 개발한 후에 후배들에게 소프트웨어에의 스펙과 구조를 설명하기 위해서 작성하곤 합니다. 이런 경우에는 문서의 효용성도 별로 없을 뿐더러 문서가 제대로 작성되었는지 알기도 어렵습니다. 또 개발자들은 기억을 더듬어서 문서를 작성하기도 어려울 뿐더러 이러한 작업은 하기 싫은 고역이 될 수 밖에 없습니다.

소프트웨어를 개발하는데 있어서 필수적인 문서의 대부분은 개발한 내용을 정리하기 위해서 만드는 것이 아니고, 소프트웨어를 개발하는데 필요한 내용을 앞 단계에서 작성하는 것입니다.

즉, 설계를 하기 전에 스펙을 작성하고

구현을 하기 전에 설계서를 작성하고

테스트를 하기 전에 테스트 계획 및 TCL(Test Case List)를 작성합니다.

하지만 현실에서는 이렇게 작성된 문서를 가지고 다음단계 작업이 잘 안 된다는 문제가 있습니다.

즉, 다른 개발자가 작성한 스펙을 가지고 설계 및 구현(코딩)을 할 수가 없는 경우가 대부분입니다.

스펙을 제대로 작성하려면 남이 설계할 수 있을 정도로 상세하게 적어야 하는데, 잘못하면 백과사전이 되고 또는 흔히 빈약한 스펙서를 작성합니다. 이렇게 되면 스펙을 작성한 사람이 또 설계자에게 계속 스펙을 설명해줘야 합니다. 

이 글을 읽고 있으면서 이것이 뭐가 문제라고 생각하신다면 이미 가내수공업식 개발에 익숙해지신 겁니다. 한 개발자가 스펙도 작성하고 설계, 구현, 테스트를 모두 다하는 이런 가내수공업식 개발은 회사는 성장의 한계에 부딪히고, 개발자는 성장하지 못하는 악순환에 빠지기 쉽습니다.

개발문서는 그 문서를 보고 다음단계의 개발자들이 충분히 일을 진행할 수 있을 정도로 상세해야 합니다.

따라서 상세화 정도는 상황에 따라서 다르다는 것을 알 수 있습니다. 설계자가 해당 제품에 대해서 빠삭하게 알고 있으면 기능스펙을 적당히 적어도 문제가 없을 것이고, 신입사원에게 일을 시키려면 좀더 자세히 적어야 할 것입니다. 

또한, 좀더 작은 양으로 이해 가능한 문서를 작성하려면 소프트웨어를 다양한 뷰에서 바라보고 적어 주는 것이 좋습니다. 따라서 스펙을 작성할 때는 소프트웨어를 인터페이스에서 바라본 모습, UI에서 바라본 모습 그리고 기능, 비기능적인 내용을 적어주면 기능에 대하여 많은 양을 설명한 것보다 더 이해하기 쉽습니다.  설계에 있어서도 소프트웨어의 아키텍처를 데이터 관점, Flow 관점, 시간의 흐름, 시스템의 상태 등 다양한 관점에서 바라본 모습을 적당히 표현해 주는 것이 하나를 자세히 적어 주는 것보다 좋습니다.

매우 추상적인 글을 적어 놓은 것 같지만, 실제 개발문서를 제대로 적기 시작하면 잘 적었는지? 못 적었는지는 명확하게 구분 됩니다. 작성된 문서를 가지고 다음 단계 개발자들이 별 무리 없기 개발을 할 수 있고, 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

그래서 이를 위해서 기법을 쫓기 보다는 실제로 필요한 것이 무엇인가 생각하고 실질적인 접근이 필요합니다. 잘못 익힌 기법은 독이 될 수 있습니다.

2009년 4월 28일 화요일

과거의 개발자 vs. 미래의 개발자

개발자는 2가지의 상반된 가치를 가지고 있습니다.

하나는 과거의 가치
또 하나는 미래의 가치입니다.

"이 사람들 나가면 과거에 개발해 놓은 것 어떡하지?"라는 생각이 들면 과거의 가치를 가진 개발자이고

"이 사람들 나가면 미래에 개발은 누가 하지?"라는 생각이 들면 미래의 가치를 가진 개발자입니다.

과거의 가치를 가진 개발자들은 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식은 머리 속에 있기 때문에 자신이 과거에 만들어 놓은 소프트웨어를 인질 삼아서 회사와 인질극을 벌이고 있는 것과 같습니다. 이렇게 된 원인이 상당부분 회사에 있다고 하더라도, 개발자의 가치는 인질범과 별반 다를 바가 없습니다. 기존 소프트웨어를 망칠까봐 대우해줄 수 밖에 없습니다.

미래의 가치를 가진 개발자들은 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수 할 수 있도록 충분히 문서화를 해 놓았고, Peer review를 통해서 이미 많은 지식이 전달된 상태입니다. 이러한 개발과정을 거쳐서 본인은 분석, 설계 능력을 더욱 향상시켰고, 신기술들에 대한 연구에 집중하여 미래에는 과거의 제품들 보다 한 단계 높은 수준의 제품들을 만들어 낼 것입니다. 이러한 개발자들이 진정한 영웅이라고 할 수 있습니다.

인질범이 되겠습니까? 영웅이 되겠습니까? 이는 본인의 의지에 달려있습니다.

안타까운 것은 고참 소프트웨어 개발자 중에는 영웅보다 인질범이 더 많다는 겁니다. 물론 이 개발자가 인질범과 다를바가 없다는 것을 본인도 모르고 회사도 모르는 경우가 태반이지만 말입니다.

2009년 4월 15일 수요일

UML전문가가 설계전문가?

종종 "소프트웨어 설계를 잘 하려면 UML을 잘 알아야 합니까?"라는 질문을 받습니다. 

사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다.

기법은 기법일 뿐입니다. 내용은 아니죠.

UML은 잘 정리된 모델링, 설계 기법이며 툴이고 많은 장점을 가지고 있다고 생각합니다.

그럼에도 불구하고 소프트웨어 설계라고 하고 UML을 떠올리는 것을 보면 UML이 본의 아니게 나쁜 일도 했다는 생각이 듭니다. 

잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를 잘 설명한 것입니다. UML이 그 중의 하나가 될 수도 있고, 전통적인 Flowchart, DFD, 수도코드나 글로 설명할 수도 있습니다. 설계는 어떠한 다이어그램을 그리고 어떤 툴을 쓰냐에 따라서 잘 되었는지 결정되는 것이 아니고 어떤 식으로 접근해서 설계를 하였고, 리뷰 하였는지가 더 중요하고, 이를 보고 구현을 담당한 개발자(본인일지라도) 충분히 구현할 수 있는 적당한 정도가 좋습니다. 그리고 미래의 비즈니스 비전에 대응할 수 있는 구조여야 합니다.

따라서 나는 설계를 시작할 때 종이와 연필 또는 화이트보드를 가지고 시작합니다. 개발자들이 토론을 하면 깔끔하게 컴포넌트를 나누는 것으로 설계를 시작합니다. 

설계 초기부터 툴을 이용해서 정리를 시작하면 감이 잘 안 오고 잦은 수정 때문에 귀찮을 수가 있습니다.

UML을 아는 것은 좋습니다. 남들이 UML로 작성해 놓은 것을 읽을 수는 있어야 하니까요.  

2009년 4월 6일 월요일

이 정도도 안되면서 Peer Review를 한다고요?

소프트웨어 개발의 기초도 되어 있지 않으면서 무리하게 Peer Review를 시도하다가 실패하기 십상입니다.

개발의 체계도 전혀 없이 코딩위주로 개발을 하고 있다면 Peer Review할 것도 별로 없거니와 Peer Review를 통해서 공유의 문제와 품질을 향상할 수 있을 것으로 착각하는데, 이는 Peer Review를 너무 만만하게 보는 것입니다. 피아노 기초도 안되어 있으면서 쇼팽을 치려는 것과 같고, 기초 체력도 부족하면서 축구의 고급 기술은 배워서 무엇 하겠습니까? 그래서 히딩크가 강조한 것이 기초체력이지요.

Peer Review를 정상적으로 진행하려면 최소한 소스코드관리시스템과 버그관리시스템은 제대로 사용하고 있어야 하며, 스펙과 설계문서를 제대로 만들어야 하며, 코딩 컨벤션을 따라서 개발을 하고 있어야 합니다. 간단하게 2줄로 설명을 했지만, 이 정도의 역량을 가지고 있는 소프트웨어 회사는 흔하지 않습니다. 즉, 대부분의 회사들이 Peer Review를 시행할 준비가 되어 있지 않고, 억지로 시행한다고 해도 그 효과를 제대로 누리기는 어렵습니다.

스펙과 설계문서를 제대로 만든다는 의미는 이미 Peer Review를 모두 포함하고 있는 것입니다. 여기서 또 많은 개발자들이 스펙과 설계문서를 제대로 만들고 있다고 착각할 수도 있겠지만, 현실은 그렇지 않습니다. 필자의 경험에 의하면 많은 회사와 개발자들이 스펙과 설계문서를 만들고 있다고 착각을 하고 있습니다. 이에 관한 얘기들은 추후에 올릴 계획입니다.

이렇게 얘기를 하면 매우 비관적인 것처럼 보이는데 비관적인 것이 사실입니다. 굳이 거짓된 희망의 메시지를 전하고 싶은 생각은 없습니다. 현실이니까요. 이렇게 된 것은 개발자들만의 탓도 아니고 회사에서 제대로 된 개발 환경 및 교육의 기회를 제공했어야 하는데, 그렇지 못했고 많은 회사들이 그냥 개별 개발자들에 의존해서 주먹구구식으로 개발해왔고 뭔가를 시도하려고 한 회사들도 그렇게 좋은 성과를 낸 회사는 별로 없습니다. 

결론을 말씀드리면 그럼에도 불구하고 Peer Review를 시행하려고 노력하는 것은 의미가 있다고 할 수 있습니다. 하지만 그와 더불어서 개발의 기초를 닦기 위한 노력도 병행해야 합니다. 이미 개발을 잘하고 있는데 기초가 부족하다고 하면 기분이 나쁠 수도 있는데, 사실이기 때문에 말을 돌려서 하고 싶지는 않습니다. 코딩도 잘하고 꽤 근사한 제품도 만들어 내지만, 효과적인 개발의 체계를 갖추고 있지 못한 것을 사실입니다. 그래서 좀더 좋은 제품을 좀더 짧은 시간에 개발할 수 있는데 그렇지 못하고 개발자들은 제대로 성장할 수 있는 기회를 갖추고 있지 못한 것입니다. 

앞으로 개발자로서 10년, 20년 후의 모습이 그려지지 않는다면 소프트웨어 회사로서 제대로 체계를 갖추고 있지 못한 것이 확실합니다. 제대로 소프트웨어를 개발하기 위해서 우선적으로 해야 할 것이 무엇인지 생각해야 합니다.

2008년 11월 24일 월요일

코더(Coder)의 비애



블로그에서 설계에 대한 몇몇 글들을 의견을 적어보려고 합니다. 


안녕하세요. Ray입니다.
써니님이 지금 하시는 일을 코딩이라고 만 얘기할 수는 없는것 같습니다. 분석, 설계도 다 하고 계시는데, 문서화가 안되어 있거나 부족할 수는 있어도 분석, 설계는 하고 있는 거죠.
적은 인원이나 소규모 프로젝트에서는 설계가 별로 이슈가 되고 있지 않습니다.
이런 상황에서 인도에 외주를 줄만큼 설계를 하는것도 낭비죠.

하지만, 내가 설계를 해서 다른 사람이 내 설계서를 보고 약간만 물어보면서 구현(코딩)을 할 수 있느냐를 따져보면 설계 이슈는 전면으로 부각됩니다.

실제로 제대로 설계를 해서 산출물을 만들어 외부에 코딩(구현) 외주를 줄 수 있는 사람은 많지 않습니다.
하지만 이런 구현 외주는 미국과 인도에서는 흔한 일이죠. 물론 설계를 가르쳐 주는 곳도 없어서 배울 수는 있지만, 애초에 이러한 환경에서 같이 일을 했으면 잘 작성된 설계서를 보고 구현도 하고 아키텍쳐 설계회의에도 참석하고 많이 배우죠.

우리의 예를 보면 소규모 기업에서 좋은 소프트웨어를 히트쳐서 회사가 갑자기 켜지고 2,3명이서 개발하던 개발팀이 수십명으로 늘어나면서 제품은 복잡해지고 켜졌는데, 제품은 이전만 못한 경우를 많이 봤습니다.
여러 다른 이유가 있지만, 설계 방법에 대한 이슈도 그 문제에 한몫을 합니다.

밑에 Cavin님이 말씀하신 것 처럼 설계 컨설턴트는 있을 수 없습니다. 제 직업이 소프트웨어 컨설턴트이지만, 설계자체를 컨설팅 해줄 수는 없습니다.
또 설계를 가르쳐주는 것도 거의 불가능합니다.
설계의 기본 컨셉, 방법, 툴 사용법 등을 가르쳐 줄 수는 있습니다.
하지만 이것들이 설계를 할 수 있게 해주지 않습니다.
그런 것들을 모두 다 알고도 오랜 경험이 또 필요하고, 문서화를 할 수 있는 실력도 필요하죠. 알고 있는 기술 분야도 워낙 다양해서 최고의 설계 컨설턴트가 도와준다는 것도 말이 안되는 얘기고 일부 기술이나 아키텍쳐에 대해서 도움을 받는 정도 이죠.

여기서 "설계는 뭐다"라고 얘기할 것은 하나도 없습니다.
그래도 이렇게 끝나는 글이 되면 너무 썰렁하니 설계의 시작과 끝 정도 정의하고 그 속은 워낙 다양하니 차차 여러 가지 의견을 글로 남겨보도록 하겠습니다.

설계의 시작은 우선 인터페이스을 찾아내는 것입니다. 그래서 인터페이스와 컴포넌트들을 구분하면서 시작이 됩니다. 이 개념은 OOP에서 출발한 것도 아니고 가장 전통적인 방법입니다. 소프트웨어의 분야는 수없이 바뀌어 왔지만설계의 원리는 크게 변하지 않았습니다코볼로 만들던자바로 만들던 소프트웨어를 만드는 철학은 기본적으로 많이 다르지 않습다설계의 기본은 시스템의 단위를 좀 더 작은 단위로 분할해 가면서 아키텍처를 설계하는 것입니다설계는 시스템을 잘게 나눠서 컴포넌트와 모듈을 정의하고 그 인터페이스를 정하는 작업입니다수많은 설계 방법들이 있지만 그 기본은 바뀌지 않았습니다카네기-멜론 소프트웨어 엔지니어링 인스트튜트에서 주창한ADD(Attribute-Driven Design, 속성 주도 설계방법이든다른 여러 아키텍처 수립 방법론들은 결국 이 방법을 체계화 한 것입니다.

UML과 같은 도구는 설계를 하는데 일부 도움은 될 수 있지만 설계에 꼭 필요한 것은 아닙니다설계한 결과를 적는 하나의 도구일 뿐입니다설계라는 작업은 소프트웨어 개발에 있어서 가장 자유도가 높고 창의성이 요구되는 작업입니다설계 기간은 선임 개발자들의 실력이 가장 많이 드러날 수 있는 기회이기도 합니다소소의 사람만이 쓸 수 있는 능력을 가지고 있는 SRS와는 달리 설계는 모든 선임개발자가 가져야 하는 필수적인 역량입니다설계에 대해서 너무 많은 제약을 가한다면좋은 설계가 나오기는 어려울 것입니다

그럼 설계의 끝은 어디일까요. 적어도 어느 정도까지 설계가 되어야 구현이 진행될 수 있을 까요?
설계가 끝나면 빌드(Build)가 시작되는 것이 기본 원칙입니다.
Class나 수많은 Public함수들의 Prototype이 모두 정의 되어 있고, Build Script까지 완성이 되어서 Daily Build가 시작됩니다. 그러면 Coder는 함수들의 내용과 Sub-function을 만들게 됩니다. Coder에게 함수와 Class를 어떻게 작성해야 하는지 설계서를 작성하는 것은 여기서 설명하기는 어렵겠죠.
여기서 말하려고 하는 것은 이정도까지 설계 단계에서 진행이 되지 않으면 Coder에게 일을 시키는 것은 사실 상 어렵습니다. 
설계를 중점적으로 담당하는 선임 엔지니어들은 지루한 코딩 작업은 가능하면 하지 않을려고 하죠. 설계가 훨씬 재미고 창의적인 작업이기 때문이죠. 그래서 코딩 작업은 신입사원이나 초급 개발자를 시키는 거죠.

이글을 보고 개발자들이 설계를 하는데 일말의 도움이 될 것이라고 생각하지 않습니다.
그냥 주변에서 돌아다는 Software Engineer, Archict, Coder등의 용어들에 너무 구애 받지 말고 자신의 일을 했으면 하는 바랍입니다.

물론 설계 능력 향상을 위한 노력은 매우 중요하죠. 수많은 책을 봤다는 분도 계시는데, 분명 도움이 될 것입니다. 그동안 쌓아온 많은 경험도 필수고요.

앞으로 계속 이에 대한 글들을 써보도록 하겠습니다.
위 글중의 일부는 제 책(소프트웨어 개발의 모든것)에서 인용했습니다.



각 블로그들의 인용문입니다.

저는 여전히 코더(coder)입니다~ by 써니
 하지만, 분명하게 이야기 하고 싶은 것은 제가 매일 하고 있는 일은 코딩이지 설계가 아니라는 것입니다. 그 근거로서 말씀드리지요. 저희 회사에 개발자가 저 혼자 뿐입니다. 누구에게 지시를 내리고 할 위치가 아니라는 것입니다. 또한 코더와 아키텍트, 고수와 하수를 나누고 그들 사이에 편가르기를 시도하려고 하지도 않습니다. 편가르기를 하려면 어느 한 편에 서야만 하는데 저는 양쪽 위치에 다 서 있는 입장입니다. 개발을 하면서 프로젝트 매니저의 역할을 맡은 적도 몇번 있지만 그런 상황에서도 한번도 코딩을 손에서 놓은 적이 없습니다. 그러니까 지금도 코딩을 할 수 있는 것이죠.
Software Design은 결코 쉬운 일이 아닙니다. 10년 20년을 개발했다고 해도, UML을 철저히 공부했다고 해도 여전히 어려운 것이 소프트웨어 디자인입니다. 실용주의 프로그래머, GoF의 디자인 패턴, Head First 시리즈, 아무도 가르쳐주지 않는 프로그래밍 설계 기법, XP 방법론, 리팩토링, Test Driven Development... 온갖 좋은 책을 다 읽어도 구구단을 쉽게 설계하는 법은 아무 책에도 나와 있지 않습니다. 즉, 현실 문제는 책에서 다루는 이상과는 달리 그 변화와 종류가 너무나 방대하기 때문에 정답을 얻기가 어려운 것입니다. 앞서 언급한 기술들과 그 기술들을 저술한 분들은 분명히 손꼽히는 대가인데도 말입니다.
  
꼭 그래야만 하는 이유
 사실 Coder를 거치지 않는 Programmer, Architect는 존재하지 않는다고 봐도 무방합니다. 기본적인 Code에 대한 이해를 가지지 않고 그 일을 한다는 건(현실에서 ‘종종’ 있는 일입니다만..) 배재하고 이야기 해보겠습니다. Coder와 Programmer, Architect의 차이는 뭘까요? 남들 모르는 몇가지 알고리즘을 더 아는 것? 남들 모르는 지식 몇가지를 더 알고 있는 것? 그런 사소한 차이는 같은 Coder,Programmer 사이에 비일비재한 일입니다. 그런 것들로 Coder, Programmer, Architect 는 구분되지 않습니다. 그럼 (나름)구분 할 방법은 무엇일까요? 아니 사람들은 대체!! 어떤 기준으로 너는 Coder, 나는 Programmer! 이런 이야기를 하는 걸까요? 사실 저도 잘 모르겠습니다만… 위의 컨설팅 과정 중에 나온 여러가지 이야기들과 그간의 사람들과 대화를 나누며 격어본 경험들에 비추어 (여러가지로 표현가능하지만) 문제 인식의 차이라고 표현하고 싶습니다.
  
납득할 수 있는 설계를 어디서 배울 수 있을까?
 업계에 설계전문 컨설턴트란 롤은 들어보지 못했다. 예로, 최근 설계에 대한 이슈를 안고 있는 대형 프로젝트가 두 개가 있는데.. 이례적으로 아키텍처가 상세하게 분화되서 분야별 아키텍트가 컨설턴트로 투입되었고, 솔루션 기반의 implementation consulting이라는 롤도 별도로 존재하고 투입되었다. 하지만 이런 환경임에도 설계 컨설팅은 없다. 별도 롤로 구분하지 않고 기술관련된 전반적인 문제들을 아키텍처 팀이나 그룹에 위임을 하는게 일반적인 프로젝트들의 전략이기 때문. 실제로 대형 프로젝트 아키텍처 팀이나 그룹은 그러한 이유로 팀사이즈가 꽤 큰 편. 
 그렇다면 프로젝트에서 누가 설계를 가이드해야 할까? 설계는 다분히 전략에 대한 내용들도 많고, 영향을 미치거나 받는 부분이 많다. 시간적으로도 일정 'phase'에 국한되지 않고, 특정 'discipine'에 한정되지도 않는다. 전략들을 설계로 모으고 드라이브 하는 사람은 방법론과 아키텍트. 아키텍처 적용이전은 방법론, 적용되는 시점부터는 아키텍트. 따라서 방법론, 아키텍트 둘의 긴밀한 협조로 설계를 일궈나가야 한다. 그렇지만, 200억, 500억대 프로젝트에서 아키텍트, 방법론 둘 다 빵꾸내기도 하는 이 현실은 완전 시궁창이지만서도..(먼산~) 
  
 꼭 그래야만 하는 걸까요?
너희 같은 하수는 평생 그렇게 코딩만 해라 나는 아키텍트의 길로 가련다... 하는 분들도 있을것 같네요. 예, 저는 하수 입니다. 당장 MFC나 위저드의 도움 없이는 Window도 제대로 생성하지 못하는 바보일 뿐이죠. 당장 개발해야 할 당면 과제는 COM 이나 CORBA 컴포넌트 제작이 아닌 제공되는 컴포넌트와 API를 이용한 어플리케이션 제작 입니다. 그렇다고 해서 삽질이나 하는 바보 개발자로 취급 받아도 좋은 걸까요? 훌륭하신 여러분들이 그렇게 무시하는 코더들은 그야말로 코드를 생산하는 위자드 보다도 못한 그런 사람들 일까요? 저는 잘 모르겠습니다. 그렇게 자기가 정한 기준에 맞지 않는 다른 사람들을 무시하는 풍토가 IT 업종의 3D화를 이뤄냈다고는 생각해본적 없으신가요?