저는 몇년간 여러 프로젝트를 진행하면서, 그 프로젝트들 사이에서 주로 개발을, 때로는 설계를 진행해보기도 했는데요, (어떤때는 혼자 프로젝트를 진행하며 모든걸 해보기도 하고..)
경험속에서 어떠한 상황이 있었고, 이러한 경우에는 어떤 방식을 택해 해결을 해볼 수 있는지 고민해보고자 글을 작성해봅니다!
보통 요즘의 기업들이 에자일 방식(소프트웨어 개발론으로 생각해보자면)을 택하고 있는 이상 기존의 요구사항을 토대로 프로토타입성의 결과물을 만들어내고 이후 추가적인 요구사항을 받아 보완해나아가는 형식을 취하고 있습니다.
에자일 방식은 그만큼 유저가 필요한 기능을 파악하고 검토 그리고 다시 수정을 하기 위한 프로젝트에서 가장 적합한 프로세스이기는 하지만, 문제는 이 에자일 방식에서의 설계 방식에 많은 어려움을 겪기도 합니다.
(에자일방식이라고 해서 설계자료 없이 개발을 할 순 없으니 말이죠.)
시스템 개발이라는건 상황에 따라서는 기존 개발방식을 깨고 새로운 개발방식이 필요한 경우가 있습니다.
이러한 경우는 기존 요구사항에서 새로운 요구사항으로 변경되면서 어쩔수없이 시스템의 구조가 변경되어야하는 경우인데,
이런 경우에는 개발자들은 리팩토링이나, 그냥 새로 개발하는 경우가 종종 발생하곤 합니다. (그냥 새로 만드는게 더 빠른 경우)
큰 문제는 리팩토링이 되었건, 새로 만드는 만드는 경우가 되었건 시간적, 인력적 코스트는 엄청나게 들곤 하죠..(결국엔 Money!)
그렇다면 설계자는 이러한 경우를 피하기 위해서는 어떻게 해야할까요?
기획의 명확한 의도를 파악하고(요구사항을 정확히 파악), 그 의도에서 새로 생길 수 있는 수정사항을 미리 고려하는 것입니다.
말이 어려울 수 있으니, 쉽게 설명해보자면.. 흠..
기획단계에서 나온 모든 요구사항을 전부 고려를 하는겁니다.
더 쉽게 말하면 확장성을 모두 고려해서 설계를 해야한다는 말이 가장 와닿을 수 있겠네요.
물론, 그 모든 요구사항을 충족할만한 시스템은 만들기 어렵겠지만,
확장성을 고려한 한번의 설계로 나중에도 문제 없이 개발을 진행할 수 있는 견고한 시스템(확장성이 쉬운)이 만들어진다면
개발자에게 있어서는 너무 감사하게도 나중에 생성될 야근시간이(시간적 코스트) 줄어들테고,
투입될 인력적인 부분(인력적 코스트)에 있어서도 많은 최적화를 이뤄낼 수 있을겁니다.
여기서 중요한건 설계뿐만이 아니라는 겁니다.
당연하게도 기획자는 기획의 의도를 명확히 해야할 필요가 있으며,
그 기획의 의도속에서도 추가적인 아이디어가 있다면 미리미리 첨언해준다면(그냥 툭 튀어나온 반영하지 않을 요구사항도 따로 정리해서) 설계에 있어 미리 확장성을 고려할 여지를 남겨두게 된다는 겁니다.
여기서 제 경험상으론 단순 아이디어(그냥 툭 내뱉은 아이디어)는 결코 단순 아이디어가 아닙니다.
그저 후보군으로 나왔었던 아이디어더라도, 추후 어떠한 결과로 다시 구현하게 될 지 모르는 암흑속의 존재(?)일지 모르기 때문에
기획자는 번거롭겠지만, 추후에 확장이 될 여지가 단 0.0000001%라도 있다면 설계자에게 어떠한 상황으로든 알려주는 것이 좋습니다.
이런 면에 있어서 저는 보통 기획부분과 설계부분을 엮어서 생각하는 경우가 있는데요,
보통 기획단에서 사용하는 Wireframe을 저는 개발하기에 좀 더 편한 저만의 Wireframe으로 조금 변형을 해서 쓰곤 합니다.
이러한 이유는 기획자의 의도가 개발단으로 넘어가면서 변질되지 않는것을 추구하기 때문이기는 하는데..
사실 개발자(저)의 시선으로 보면 기획 단의 Wireframe은 개발에 참고하기 위한 부분이 많이 부족하다고 느껴집니다. (구체적일수록 좋은데 말이죠..)
화면설계서라는 설계문서가 중간에 들어가기는 하지만, 이러한 화면설계서에서도 단순히 Wireframe과 요구사항만 보고 설계문서를 만들어내기란 쉽지 않기에 사람이 보기 편한 이미지적인 요소인 Wireframe을 좀 더 개발자에게도 확 와닿는 하나의 개발문서가 되었으면 좋겠다는 생각으로 커스텀을 해보게 되었습니다. (제가 본 블로그에 작성한 Wireframe에 관한 내용도 있으니, 하단의 링크를 통해 구경해보셔도 좋을 것 같습니다.)
깔끔하게 휴식을 마치고 와서 그런지 그나마 머리가 말끔해져서 오늘은 Wireframe을 소개해볼까 합니다. (?! 갑자기 ?!)
사실 제가 쓰는 이런 설계단의 문서들은 어려워하시거나 모르시는 분들이 많을 수 있습니다.
개발을 진행하시는 분들은 문서를 받아서 볼 수 있겠지만, 보기보다는 그냥 고객의 설명이나 상급 개발자의 설명만 듣고(회의 등) 변경된 내용으로 진행하는 경우가 많은 것 같더라구요.
그만큼 폭포수 모형보다도 애자일 방식을 택하는 기업도 많다는 의미이기도 하구요. (Prototype 만들고 수정하고 반복적인..)
사실 이 설계라는게 생각보다 시간도 잡아먹는거기도하고, 개발자에게 대충 '대략적인 혹은 완성된 UI' 그림만 던져주면 된다! 이런 부분이 없지않아 있어서 개발자는 그 대략적이거나 완성된 UI를 시작으로 개발-수정작업을 거쳐 완성본을 만드는 경우가 많은 것 같습니다. (ㅠㅠ)
저는 개인적으로 이런 부분들을 보완하고자 제가 개발하면서 개인적으로 만드는 문서들이기 때문에 어려워하시거나 잘 모르시는 분들도 많은 것 같습니다.
(사실 잘 찾아보면 소프트웨어 공학적인 부분에서 많은 내용을 찾아볼 수 있지만.. 개발 문서가 우선이다보니..)
근데 웃긴 사실은 이런 문서를 미리 만들어 두면 몇번의 수정만 거치면 완료 보고서 제출시에 편리해진다는 점이 장점이있습니다. (우려먹기? ㅋㅋㅋ)
또 설계서가 있는 만큼 개발을 진행해야하는 사람들에게도 이렇게 개발을 해야한다! 라는 프로젝트 개발 가이드 라인이 잡히다보니 같이 개발하는 동료나 후배들에게 입아프게 말할 필요도 많이 줄어 만족도는 꽤나 높은 편입니다. (개인적으로는 말이죠 ㅋㅋ)
물론 이해가 안되는 부분은 커뮤니케이션을 진행해야하지만 말이죠 ㅎ
음.. 벌써부터 말이 너무 많네요. 이런 주저리 거리는 부분은 본론에 들어가서 추가적으로 하도록 하고! 지금! 바로! 본론으로 들어가보겠습니다.
Wireframe?
Wireframe...? 그게.. 뭐예요...?
협업 중에 있어서도 Wireframe의 존재를 잘 모르시는 분들은 생각보다 많습니다.
그만큼 분석 및 설계시에 화면설계로 바로 넘어가는 경우는 많아도, Wireframe을 잡고 넘어가는 경우는 생각보다 드물기 때문에(ㅠ..ㅠ) 이런 경우가 생각보다 많이 발생하는 것 같습니다.
음.. 화면설계가 나오면 그나마 낫긴하지만, 이보다 더 심각한건 Wireframe이 확정되지 않은 상태에서 바로 디자인을 진행하는 경우는 생각보다 여러모로 힘들어집니다. (이러한 경우 Wireframe이 불안정하다보니, 바로 디자인을 시작하는 경우 여러번의 디자인 변경을 체험할 수 있습니다... 심한경우에는 서로의 이해관계가 통하지 않아 만족도가 낮은 완성본이 나올 가능성도 있습니다.ㅠㅠㅠ)
이런 경우 UI를 디자인 하는 디자이너, UI 목업이나 화면설계서만 보고 개발을 진행하던 개발자는 날마다 다크써클이 생겨나기 일쑤입니다. ㅇ_ㅇ;;;
이런 변경을 초기에 잡는 방법 중 하나가 개인적으로는 Wireframe이라 생각합니다.
그래서 Wireframe이 무엇이죠?
우선 어려운 내용들 다 접어두고 쉽게 설명하자면 기본 설계를 위한 '뼈대'입니다.
Wireframe을 잡아주면 거기에 쌓아 올리는 디자인적 요소든 개발적 요소든 어느정도 기본적인 '뼈대'가 잡혀있기 때문에 이후 구조적인 요소에서는 큰 변동사항이 거의 없어지게 됩니다.
사실 그 내면을 들여다보면 기획적인 요소가 조금 섞여있을 수 있는데, 이는 프로젝트의 제작을 원하는 사람의 생각을 '명확'하게 해주는 작업이기 때문에 그럴겁니다.
이 '명확'해진 '뼈대'위에 *구조물을 쌓아올리는 작업이 바로 디자이너와 개발자의 협업을 통한 분석-설계-개발이 진행 되는 거죠.
그만큼 Wireframe을 잡는건 굉장히 어려운 작업이기도 하지만, 한번 확실하게 잡아진 Wireframe 하나만 있으면, 이후 분석 설계 디자인 등은 굉장히 편리하고 빠르게 넘어갈 수 있습니다.
음.. 이렇게 말로만 하면 어려우니까 이쯤에서 비장의 카드 이미지를 넣어봐야겠네요.
직접 보시죠!
백문이 불여일견
백번 듣는거보다 한번 보시죠!
Wireframe (장비 관리 - 장비 등록)
장비관리 Wireframe, 만든이 : Karzin
위 이미지는 제가 Project.다원 Ensemble을 진행하면서 그렸던 Wireframe입니다. (참고 링크)
사실 여기에는 제 개인적인 개발적 요소들이 들어가기도 했는데(Component의 종류), 이 문서 하나로 기획을 했던 저의 아이디어를 종합하고, 어떤식으로 개발을 해나가야할지 미리 '뼈대'가 잡아지고, 이렇게 진행을 해야겠다는 정보가 그림 하나로 완성이 된겁니다.
'뼈대'가 어느정도 작업이 완료되었다면, 이제 화면설계서가 굉장히 빠르게 나올 수 있는데, 이 화면설계서까지 나오면 사실 개발자에게 있어 이런 확정된(화먼설계서) 내용을 만드는 작업만큼 쉬운일은 또 없을겁니다.
그럼 Wireframe을 토대로 만들어진 화면설계서를 잠깐 구경을 해보실까요?
화면설계서(장비 관리 - 장비 등록)
장비관리 화면설계서, 만든이 : Karzin
화면설계서를 어떻게보면 한단계 위의 Wireframe과 비교를 해보면 크게 변경된 내용은 없어보입니다.
하지만 좀 더 그 내부를 살펴보면 Button Component는 '등록'이라는 text가지정되어 변경되었거나, 이외에도 각 Component들의 사용의 예시를 보여줌으로써 개발자는 Wireframe과 비교를 해가며 알맞는 개발 Component를 선택하여 개발해 나갈 수 있게 해주는 것을 알 수 있습니다.
사실 이런 부분들이 제 입맛대로 바꾼 부분이 있어 조금 변칙적일 수는 있으나, 저의 경우 'Wireframe'단에서는 어떠한 Component를 사용할지 명확하게 뼈대를 잡아주고, 이후 해당 화면에 DB를 연동했을 때 어떤식으로 화면에 보일것인지를(뿌려줄 것인지를) '화면설계서'를 통해서 보일 수 있게 화면설계서를 마치 Prototype인 마냥 설계를 진행하는데, 이렇게 해주면 좋은점이 개발자 입장에서는 이 정도의 설계서만 있으면 이후에는 걱정없이 개발에만 집중할 수 있다는 점입니다.
물론 제가 진행중인 개인 프로젝트에서는 Wireframe과 화면설계서만으로 개발을 진행하지만 이는 기본적으로 Bootstrap을 사용함으로써 어느정도 디자인 단계를 보완할 수 있는 부분이라서 그런거기도하지만, 사실 여러가지 따지자면 디자인도 들어갈테고, Diagram같은 좀 더 개발의 기초를 잡아주는 부분도 있을 수 있으나, 이러한 부분들은 디자이너나 개발자간에 서로 협업(커뮤니케이션)을 하며 어떠한 디자인을 어떠한 로직으로써 어떻게 구현을 할지 머릿속에 상상하며 그려가야하는 작업이라고 생각하기 때문에, 자세한 언급은 삼가했습니다. (또 주저리주저리 말만 길어져서 다들 졸리게됩니다 ㅠㅠ)
이처럼 Wireframe을 한번 그려두면 자신의 생각을 남들에게 명확하게 전달할 수 있기 때문에 좀 더 자신이 원하는 프로젝트로 진행이 될 수 있는데, 물론 아쉬운 부분이 생길수 없다는 보장은 못하지만(기술적 요소 등으로 Wireframe대로의 개발이 힘든 경우 등등), 서로간 계속되는 커뮤니케이션을 통해 보완을 해나간다면 마지막에는 기획물에 걸맞는 마음에 드는 결과물을 뽑아낼 수 있습니다.
그만큼 Wireframe 자체가 굉장히 중요하기도 하구요.
* 위에서도 언급했지만(개발적 요소-Component의 종류), 항상 그렇듯 저는 제 개인적인 입맛대로 문서작성을 진행하기에 기존 Wireframe보다 변칙적인 부분이 많을 수 있습니다.
* 이는 제가 좀더 개발자의 측면에서 바라보는 부분들과 개인적인 경험들을 토대로 변칙적인 부분으로써 발전한거이므로 양해부탁드립니다 ㅠ
그럼 Wireframe은 누가 만들어야 하나요??
이쯤오면 궁금해질겁니다. Wireframe은 매우 어려워보이는데 누가 만들어야할까요?
그 내면을 깊이 파고들면 Wireframe은 기획적인 요소가 많이 들어가 있기 때문에 기획자가 만들면 기획자가 원하는 굉장히 고퀄리티의 결과물을 뽑을 수 있을겁니다.
하지만, 생각보다 Wireframe을 쉽게 보기란 힘들 수 있는데요, 저는 생각합니다. 이럴때는 바로 유비무환(有備無患)이라는 사자성어가 있습니다.
그냥 누가 되었든 미리 준비해두시고 confirm을 받아야할 담당자에게 보여주는겁니다!
'우리는 지난 회의를 통해 이렇게 뼈대를 잡았으며, 때문에 담당자님께 이대로 진행해도 될지에 대해 confirm을 요청합니다. 맘에 드신다면 이대로 분석-설계-개발이 진행될 것입니다.' 라고요!
사실 이러한 경우에는 대체적으로 담당자에게도 아직 확고한 '뼈대'가 없거나, 어떻게 만들어야할지를 모르는 경우가 대다수입니다. 이럴때 이런식으로 만드려 하는데 진행해도 괜찮을까요? 라고 연락이 오는 만큼 반가운일은 특히나 없을겁니다.
분명 담당자는 확인을 하고 자신이 생각한(그려본) 내용과 비교를 해가며 어느정도의 피드백과 커뮤니케이션이 오가다보면 확고하게 '뼈대'가 잡혀나갈겁니다.
그만큼 커뮤니케이션에 시간이 많이 걸릴수도 있지만, 이런 확실한 '뼈대'가 완성되는 순간에는 분명 담당자에게 있어서는 굉장히 좋은 결과물로 남을 것입니다.
Wirframe의 장단점
마지막으로 Wireframe을 사용함으로써의 장단점을 한번 보시죠!
음.. 우선 단점부터 이야기해보겠습니다.
- 시간적 Cost
- 명확함의 어려움
하나씩 잡고 설명을 해보자면
첫번째로 시간적인 비용이 있습니다.
기획자-디자이너-개발자 간 서로의 커뮤니케이션으로 인해 잃을 수 있는 시간적인 비용을 말하는건데, 사실 이는 명확한 Wireframe의 설계로 분석/설계 단계에서 더 많은 시간적인 비용을 절약할 수 있어 어찌보면 양날의 검같은 존재입니다. 사실 이러한 부분은 제가 생각하고 경험하기로는 중간의 PM역할이 가장 중요하다고 생각을 하는데요, 커뮤니케이션의 중간에 서서 시간의 비용을 최대한 절약할 수 있는 방법을 숙련된 자신의 경험 등을 사용해 저울질해가며 작업을 원활하게 진행을 해주는 부분으로, 앞서 이야기 나온것처럼 경험에서 우러러 나오는 부분이 아닐까 생각하고 있습니다.
그만큼 분석/설계단계에서의 작업이 더뎌진다면 개발은 더더욱이 미뤄지게 될테니 시간적인 요소를 꼭 체크해가면서 커뮤니케이션을 하는게 가장 중요하지 않을까 합니다.
두번째로는 명확함의 어려움이 있습니다.
사실 명확하다는 말처럼 또 어려운게 어딨을까 싶네요. 말이 명확하다일뿐이지 보는 시각에 따라 명확하지 않음은 분명이 나타날테니 말이죠. 이러한 부분의 해결은 사실상 위에서 말한 커뮤니케이션을 통해 해결을 해나가는 방법밖에는 없다고 생각합니다. 분명 기획-디자인-개발- 등등 여러 관점에서의 시점은 각각 다르니까요.
그럼 이번에는 장점을 이야기해보도록 하겠습니다.
- 시간적 Cost
- 이후 작업이 용이 (스무스)
- 인력의 최적화
- 백문이 불여일견
첫번째 시간적인 비용부터 설명해보자면, 위의 단점처럼 장점과 단점이 될 수 있는 양날의 검인 부분입니다.
그만큼 잘 저울질해가면서 최상의 시간적 비용을 들이고 원하는 프로젝트로 이끌어가는 방법을 찾아가야하는게 최우선이라 보여집니다. 이런 부분은 어쩔수 없이 저에게는 부족한 경험에서 우러러나오는 부분이기 떄문에, 결국 조율은 경험자에게 유리할 수 있다 보여집니다.
두번째로는 이후의 작업이 용이(스무스)해진다는 부분입니다.
잘 만들어둔 Wireframe만 있다면, 이후 분석/설계문서는 기획의 의도가 정확하게 파악이 되었기 때문에 스무스하게 작업이 진행이 된다는 겁니다. 또 그만큼 잘 제작이 되었다면 개발까지도 큰 이슈없이 진행이 될거고, 빠른 Prototype이 나옴으로써 기획을 한 담당자도 검토를 통해 개발진등은 어느정도의 기간내 수용가능한 기능 변경이나 디자인 변경까지도 가능하다는 장점이 있을 수 있습니다. 물론 이런 기능이나 디자인의 변경에 한해서는 민감한 부분이 많이 있어서 변경에 대한 작업진행시에는 어느정도 서로의 커뮤니케이션을 통한 이해관계가 꼭 필요하겠지만 말이죠.
세번째는 인력의 최적화입니다.
인력이 많다면 분명 개발은 빠르게 진행될 수 있겠지만, 그렇다고해서 오버해서 넣을 필요는 없는 프로젝트가 많을텐데요, 이러한 경우 개발을 위한 설계문서가 제대로 잡힌다면 인력의 최적화 또한 이루어지게 됩니다. 해당 부분도 사실 경험자가 필요한 부분이긴 한데, 미리 각 인력의 시간당 개발 진행도를 미리 파악하고 알아둘 필요가 있고, 어느정도 파악이 된 경우 설계문서에 맞춘 각 개발인력을 최적화해서 배치할 수 있어 개발 인력을 정말 최적으로 부려(??)먹을 수 있습니다. 경험자가 필요한 만큼 이는 PL이나 PM의 역할이 중요한데, 그만큼 자신이 관리하는 인력의 실력등을 미리 파악하는 시간이 필요할 것입니다.
네번째로 백문이 불여일견입니다!
사실 이걸 저는 큰 장점으로 뽑고는 있는데, 이는 기획자의 의도를 백번의 말보다도 한번의 Wireframe으로써 상대방을 이해시킬 수 있다는 부분입니다. 우리는 커뮤니케이션을 진행할 때 항상 문제시 되는 부분은 서로 다른 성격의 사람들을 '이해'시켜야한다는 부분일겁니다. 자신의 의도를 명확하게 알려주고 상대를 이해시킴으로써 더 좋은 퀄리티의 프로젝트 완성물을 탄생시키는 것이죠. 사실 이러한 부분은 쉬운부분이 아닌만큼 굉장히 중요한 부분으로 자리잡고 있는데, 백번의 말보다 한번의 Wireframe으로 해결이 된다면? 이처럼 좋은 해결방법은 또 없을겁니다. (물론 이런 부분은 Wireframe의 완성도나, 추가적인 커뮤니케이션이 있을 수 있으나, 여러번의 커뮤니케이션을 최소화할 수 있는 좋은 방법이라고는 생각합니다.)
이처럼 우리에게 당장 필요한건 개발도 중요하지만, 분석/설계를 제대로 할줄 아는 기술도 중요하다고 생각합니다.
오늘은 Wireframe에 대해서 잠깐(???) 설명하는 시간을 가져봤는데, 좀 더 이미지를 많이 넣어서 졸음 방지를 해드릴껄(???) 하는 글이네요.
슬슬 졸음이 몰려올 시간일거라 오늘은 이쯤에서 마무리를 하도록 하겠습니다~
쓰면서도 알았지만 말 진짜 많이썼네요.
누가보려나 싶을정도로요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
글을 읽어보시는 분들에게 큰 도움이 되려나 모르겠지만 되었으면 좋겠네요.
음.. 그래도 개인적인 경험과 공부를 토대로 작성을 하다보니 프로그램쪽으로 진출하는 새내기들에게는 조금이나마 유익한 글이 되지 않을까 싶습니다. 저 꼬꼬마때는 개발도 개발이지만, 기획단계부터 시작해서 분석이나 설계 등등 이런한 글을 읽어보고싶었는데, 없었어가지구.. Google에 'JAVA OOO만들기' 같은건 검색하면 쉽게 쉽게 나온다지만, 이런 기획부터 설계관련 이야기를 풀어놓은곳이 (제가 찾아봤을땐) 없었거든요.ㅠㅠ 제가 가진 경험과 공부한 내용들을 토대로 짜집기해서 머릿속에 나온거라 많은 부분 부족할 수 있지만, 한번쯤 읽어보시면 유익할거라 생각듭니다.
혹시 수정해야할 부분이라던가 있으면 댓글이나 메일주시면 확인해서 수정해두도록하겠습니다.
물론 질문도 항상 받고 있구요~
그럼 오늘 하루도 고생 많으셨습니다!
버전정보 (v1.1)
- v1.0 2020.07.28 배포
- v1.1 2020.07.28 장점에 새로운 항목 추가
* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.
* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.
* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.
* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.
* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.
사실 고객도 저이고, 개발자도 저인 이상 어느정도 제 머릿속에 정립된 시스템은 바뀔일이 없다보니 거의 빠꾸는 없겠지요.. 다만, 개발하다가 막히는 부분이라던가, 문제가 생겨 바뀔수밖에 없는 부분에 대해서는 로직이 바뀔뿐이지 보이는 UX/UI상에는 크게 바뀌는 부분은 없을겁니다.
그렇다면 제가 베이스로 두는 개발모형 폭포수 모델은 무엇일까요?
제가 느끼는 특징은 이렇습니다.
* 확고하게 정립된 프로젝트(계획, 분석, 설계가 고객에게는 확고하게 정리가 된 상태 - 이렇게 만들 것이다!)
- 앞에서부터 차례대로 나아가는 모델
- 노빠꾸 모델
- 프로젝트의 철저한 문서화 (앞으로 철저하게 하겠습니다..ㅠㅠ)
사실 이는 확고하게 정립된 프로젝트 즉, 제 자신이 생각하는 틀에서 벗어나지 않기 때문에 폭포수모델을 사용할 수 있었습니다.
뭐.. 확고하게 정립된 프로젝트라고해서 보통의 프로젝트에서 사용하지 않는건 아닙니다.
기본적으로 일반적인 프로젝트에서도 폭포수 모델은 많이 사용되기는 합니다.
고객과의 커뮤니케이션을 통해 미리 분석을 하고, 분석된 자료들을 토대로 설계를 확정지어버리는 것이죠.
설계까지 확정만 되었다면, 다음으로는 개발을 진행합니다. 개발이 마무리되면 이제 테스트를 하고 배포가 끝나고나면 유지보수가 마지막 단계이겠지요.
이걸 머릿속에 기억하시고 아래 이미지를 보시면 이해하기가 편합니다.
아래는 폭포수 모델의 구조입니다.
폭포수 모델은 위에서 아래로 흐르는 듯한 구조를 가지고 있습니다.
여기서 한가지! 개발자에게 있어 가장 행복한건 역시 잘 짜여진 설계 문서이겠죠. 확고한 프로젝트의 설계자료는 개발자에게 있어서 굉장한 도움입니다.
그도 그럴게 버튼에 입혀질 디자인이 바뀌더라도 그 디자인의 원본 Structure인 Button은 바뀌지 않으니까요!
이 부분을 설명하기 위해서는 당연하게도 설계가 되어 있겠지만, Wireframe이나 화면설계단에서는 이미 이것은 Button이라는게 확고하게 잡혀 있을 것입니다.
그렇기에 개발자 입장에서는 Button을 만들어놓고 그 위에 어떤 디자인을 입히든 문제가 되지 않는 다는거죠.
Button의 위치, 글자 혹은 이미지는 그대로지만, 그 아래 디자인을 입히는건 어쩌면 개발자에겐 어렵지 않은 일이 될겁니다. (물론 상황에 따라 이미지를 바꾸는게 어려운 상황이 있기도 합니다.)
하지만 문제는 여기서 일어납니다. 바로 설계문서가 바뀌어버리는 경우가 있습니다.
물론 이 설계문서가 바뀌는건 계획단계-분석단계-설계단계까지는 그나마 문제가 적을 수 있으나,
문제는 개발에 들어가서부터 문제가 하나 둘 터지기 시작됩니다.
예를 들어 개발자는 디자인(버튼의 스킨)을 바꾸는건 쉬울지는 몰라도, 설계문서의 UX나 화면설계서가 크게 바뀌는 경우 그 구조 차체를 새로 만들어야하는 문제가 생길 수 있습니다.
이는 결코 작은 문제가 아닙니다. 개발자는 변경된 설계로 인해 지금까지 쌓아 올린 모든걸 새로 쌓아올려야하는 위험한 도박이 될 수 있습니다.
이런 경우에는 폭포수모델과 조금 방식이 다른 애자일 방법론을 사용해야하는 경우가 있습니다.
애자일 방식의 하나인 XP(익스트림 프로그래밍)방법론처럼 개발자 개개인의 역량에 맡긴채로 고객과 계속 소통을 해가면서 진행을 해가는 방법입니다.
수시로 변경이 되어가는 고객의 요구사항을 맞춰가며 팀원과의 대화를 통해 문서보다는 어느정도 개발이 진행된 시스템을 먼저 보여주는 형식입니다. 여기서 개발이 진행된 시스템은 프로토타입이라고 봐도 문제가 없을정도의 퀄리티가 있는(높은) 시스템입니다.
쉽게 말하면 프로토타입을 마구 찍어내면서 고객에게 모두 보여고 또 고객이 원하는 요구사항에 맞추어 프로토타입을 변경해가며 완료되어가는 시스템을 보여주는 것이죠.
아래는 애자일 방식의 구조입니다.
애자일은 계속된 반복을 통해 결과물을 만들어갑니다.
그만큼 고객과 개발자간 서로의 커뮤니케이션이 가장 중요한 개발론이기도 합니다.
애자일 방식의 특징으로는
- 중요한 커뮤니케이션
- 요구사항의 변동에 유연하고 그만큼 빠른 대처가 가능
여기서 잠시 한가지! 애자일에 대한 예시를 생각해보다보니 좋은 예시가 떠올랐습니다.
그 좋은 예시로 설명을 든다면! 개인적으로는 가장 적합한 프로젝트로는 R&D가 적합하지 않나 싶습니다.
사실 R&D는 요구사항이 계속해서 바뀌는 프로젝트 중 하나입니다.
진행을 하다보니 시스템의 구조가 틀어져버린다거나, 아무래도 새로운 요구가 들어가야한다던가 여러가지 이유로 계속해서 변동에 유연해져야하는 경우가 많이 발생하죠. 특히 연구가 진행이 되고 있는 상태라면 그 연구에 맞춰지기 위해 요구도 계속해서 변동하는게 R&D라고 생각하고 있습니다.
그렇기에 애자일방법론(XP방법론)을 사용해서 고객과의 끊임없는 커뮤니케이션을 통해 Prototype을 만들어내고 테스트함을 반복함으로써 고객에게 만족도가 높은 시스템에 가까워지는 방법이라고 생각합니다.
폭포수 모델 이야기를 꺼내다가 잠시동안 애자일 방법론을 이야기해봤지만, 저는 보통 두가지를 다 경험해가면서 진행을 하고 있습니다.
어떤때는 개발보다 분석과 설계를 통한 문서화를, 어떤때는 문서보다는 개발이 앞서서 진행이 되어 PM과 PL과 소통해가며 프로토타입을 최단시간으로 또 최상의 퀄리티를 내기위해 노력하기도 하죠.
다만 이런 방식을 택하기 위해서는 위에서 말한것처럼 계획을 철저히 지켜나가는 '노빠꾸' 폭포수 모델이 굉장히 좋아보일 수 있으나.. 제 생각으로는 어느정도 규모가 있는 프로젝트에서는 폭포수 모델이, 규모가 적고 투입되는 인원이 적어지는 프로젝트에서는 애자일 모델이 가장 적합하다고 생각합니다. (위에서 말했던 R&D와 같은 타입)
이유는 규모가 있는 프로젝트(투입인력이 많고 프로젝트가 큰 경우)의 경우 어느정도 규모가 있는 만큼 고객의 요구사항이 어느정도 정립이 되어 있다고 보여집니다. 그런 경우 철저한 계획을 수립하고 수립된 계획대로 요구에 맞춘 분석, 설계를 진행하여 알맞은 결과를 내어주는게 필요하다고 생각을 하고 있습니다.
반면 규모가 적은 프로젝트(투입인력이 적고 프로젝트가 상대적으로 작다 싶을때)의 경우 고객과 팀원간의 커뮤니케이션을 통해 정립이 덜 된 프로젝트를 눈치껏(?) 빠르게 만들어주는게 중요하다고 보여지기 때문입니다.
그만큼 애자일의 경우 (여기서는 XP방법론을 예시로 들어보겠지만), 고객 - (PM, PL) - 팀원들간의 커뮤니케이션이 제일 중요하게 부각이 되는게 그 이유중 하나입니다.
실제로 프로젝트 진행시에도 상황에 따라서(규모 혹은 요구사항 등) 폭포수나 XP방법론을 사용하고 있습니다.
위에서 적은 내용은 저의 생각일 뿐이고 어느 하나가 더 좋다고도 할 수 없는 방법론들이지만, 현재 자신의 팀원이 처한 상황에서 가장 효율좋은 방법을 찾아내는게 중요하지 않을까 싶습니다.
PM, PL분들 모두 고생많으시고 멋지십니다! 화이팅입니다! (갑자기???)
물론 개발자들도 말이죠!ㅎㅎㅎ
흠흠.. 그냥 제가 만드는 프로젝트는 폭포수 모델을 베이스로 두고 있고, 폭포수 모델은 이런겁니다! 라는걸 적으려했는데.. 또 길어졌네요. 항상 이럽니다ㅠㅠㅠ 뭔 말이 이렇게 많냐 싶으시겠네요.. ㅎㅎ... 그래서 그냥 적당히 끊었습니다. ( 사실 더 주저리주저리 적어 나갈순 있는데.. 다들 졸리실겁니다.. 그 마음 다 압니다ㅠㅠ 밥먹을시간만 되면 꼭 잠 다 깨다가도 교장선생님의 말씀이 이어지면 졸리는 그... 뭔가모를 그런 분위기.. 저도 다 경험해봤거든요 ㅋㅋㅋㅋㅋㅋㅋ)
오늘은 그냥 제가 사용중인 프로젝트의 개발 모형에 대해서 잠깐이나마(???) 설명하는 시간을 가졌습니다.
물론 제가 틀린부분도 있을 겁니다. (아직 많이많이 부족해서..ㅠㅠ) 이런부분들은 지적해주시면 바로바로 공부해서 수정하도록 하겠습니다!
이제 슬슬 샤워하고 Class Diagram이나 작성해봐야겠네요 ㅋㅋㅋ
는 샤워하면서 아 일단 쓴거 그냥 다 쓸껄 아쉬워하면서 생각만하다가 나오자마자 에자일방식 구조랑 내용을 좀 추가해뒀습니다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
이빨닦으면서도 이런거 생각하고 있는 나는....(절래절래)ㅋㅋㅋㅋㅋㅋㅋㅋ
+ 음.. 생각해보니 내일 오전부터 중요한 회의가 있었네요. 오늘은 Class Diagram보다는 내일 오전에 있을 회의에 졸지 않기 위해 일찍 공부하고 마무리해서 조금 일찍 취침을 해야겠군요! (변명이지만 이래서 프로젝트 WBS(일정관리)를 작성하지 않았습니다 ㅠㅠ 워낙 스케쥴에 변동이 많다보니...)
버전정보 (v1.2)
- v1.0 2020.07.13 배포
- v1.1 2020.07.13 애자일 방식 구조 및 내용 추가, 오타 수정
- v1.2 2020.07.13 내용 수정
* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.
* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.
* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.
* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.
* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.
Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등
하나의 프로젝트를 완성하기 위해서는 좋은 설계가 필요하다. 그를 위해선 여러가지 카테고리를 나눠 보고서를 작성해두는 것이 좋은 방법이지만, 설계를 뛰어넘고 바로 개발로 넘어가는 경우가 허다하다. (귀찮기도하고..)
오늘은 대학을 졸업하고도 잊지 않기 위해 보고서에 들어가야할 내용들을 메모해놓기로 했다.
물론 개인적인 생각으로 정리된 부분들이지만, 대학졸업작품 보고서에도(컴공과등) 해당형식을 맞춰준다면 좋아하실 교수님들이 꽤나 있을것이다.(아마..도..? 맞겠죠..?) 그래도 워낙 각 교수님들이 성격들이 다르시다보니.. 원하시고 추구하시는것도 다르시기에 그냥 참고만 했으면 좋겠다.
1. 제대로 된 Project명과 개발프로그램의 명칭. 예) Projcet.다원, app명:runplay
2. 개발 내용 : 이 프로그램은 무엇을 하는것인데 무엇을 하기위해서 어떠한 개발을 할것인지에 대한 내용.
3. 개발 동기 : 이 프로젝트를 개발하게 된 동기가 무엇인지
4. 개발 목표 : 이 프로젝트를 개발할때의 목표.
5. 기대 효과 : 해당 프로젝트를 진행하면 어떠한형식의 효과를 볼수 있는지.
6. 벤치 마킹(중요) : 벤치마킹을 무척이나 헐겁게 볼 수도 있는데, 자세히보면 벤치마킹안에는 다른 프로그램과 내가 만들 프로그램을 비교하면서 어떤 부분을 강점으로세우고 어떤부분을 지워서 해당프로그램을 조금 더 좋게 만들지를 뚜렷하게 들어나게 해준다. 자기가 무언가를 만든다고 생각을 하면 그것에따라 어떠한 형식으로 만들지 생각하기 전에 벤치마킹을 해두는것이 중요하다. 자신의 프로그램을 조금 더 좋게 만드는 하나의 방법이라고 생각한다.
7. 특징 및 장점 : 해당 프로그램의 특징과 장점. 어떠한 형식의 특징이 있으며 장점이 있는지. (물론 단점을 마구 얘기하진않겠지만..)
8. 문제설명서 : 사실 문제설명서라고하면 문제를 설명한다 라는의미에서 안좋게 받아들일 수 있는데 사실, 그게 아니고, 이 프로그램에 대한 설명이라고 보면되겠다. 쉽게 말해 설명서? 같은건데.. 해당은 나중에 기회가 되면 다시한번 더 자세히 다뤄보도록...
9. UI : 꼭 UI가 아니어도 좋다. 개발직전의 WireFrame을 보여줘도 되는데, 해당은 개발단계 거의 바로직전에 어떠한 형식으로 개발이 될지 틀을 잡아주기때문에 꼭 있어야하는 부분이다. 물론 설계에 있어 모든부분이 필요하겠지만, UI(WireFrame)같은 경우 설계를 잘해두면 나중에 개발할시에 시간을 단축시켜주기 때문에 디자이너와 잘 연계해서 설계해두면 편하다고 볼 수 있다.
10. 요구사항분석 : 자신의 프로그램에 필요한 요구사항들을 모아놓는것으로, 쉽게말해 어떤 기능들이 필요한지 모두 짜집기하는 부분이다. 해당이 있어야 함수등의 개발시에 어려움없이 조금이라도 더 쉽게 설계하여 개발할 수 있다.
11. 여러 다이어그램 : 해당은 자신이 무슨프로그램을 개발하느냐에 따라 제작해야하는 다이어그램이 조금씩 달라지는데, 내가 자주사용하는 다이어그램은 클래스 및 시퀀스 다이어그램이다.
- 클래스다이어그램 같은 경우 개발에 있어 어디 클래스에 어떠한 함수가 제작되어야하는 지를 명확하게 해주기때문에 설계단계에서 제대로 해줘야 개발시에 함수작성시에도 쉽고 편하게 개발할 수 있다. - 시퀀스다이어그램은 각 클래스나 함수에서 어떠한 형식으로 타임을 할당하고 실행이 되는지를 나타내는데 시퀀스 다이어그램을 제작하다보면 자신이 만들 프로그램에 대해서 좀더 체계적으로 개발할 수 있다고 볼 수 있다. (편하게 개발하는것과 체계적으로 개발하는것과는 전혀 다른차이. 꼭 알아둬야한다.) - ER다이어그램은 DB연동시에 꼭 필요한 부분이다. 프로그램에 DB가 들어가는데 ER다이어그램이 없다는건 개발을 할 마음이 없다는거다. 간략하게라도 ER다이어그램은 꼭 있어야하며, 추가적인 다이어그램은 추후에 기회가되면 설명하도록 하자.
12. 추가예정사항 : 자신이 프로그램을 만들고(혹은 런칭을 하고) 기능을 어떤것들을 추가할지를 작성한다. 주로는 프로그램을 업데이트를 하면서 어떤기능이 추가될지에 대해서를 작성.
13. 부록 : 해당 프로그램을 작성하면서 처음다루는 사람들을 상정해서 몇가지의 단어들이나, UI에 대해 짤막하게 정리해두면 좋다.
14. 여기서부터는 어플이나 웹프로그래밍등에 필요한 부분인데, 어쩌면 꼭 필요한 부분은 아니지만 알아두면 좋은 부분이다. - SITEMAP : 홈페이지나 어플을 작성할때 어떤식으로 각 액티비티들을 연결하고 연결이 될지가 나와있는 부분이다. 홈페이지 및 어플을 작성할때 꼭 필요한 부분. - Persona : 해당 홈페이지 및 어플을 이용하기 위한 가상의 인물을 만든다. - Context Scenario : 위 페르소나에 연동되는 부분 중 한부분으로, 가상의 인물이 자신이 개발할 홈페이지 및 어플을 어떠한 형식으로 이용하게 되었고 어떠한 느낌을 받았는지를 작성하는 부분이다. 위 두가지 경우에는 해당 어플 혹은 홈페이지를 어떠한 사용자가 사용할지 주요 타게팅을 잡을때 매우 편리하다.
15. 추가 : 벤치마킹을 할때에 홈페이지나 어플의 경우 Jacob Nielson's Heuristic Evaluation을 이용해 작성하면 매우 편리하다. - 1. Visibility of system status (사용자에게 시스템의 현재 상태를 시각화하여 보여준다.) - 2. Match between system and the real world (현실세계와 부합되도록 시스템을 설계한다.) - 3. User control and freedom (사용자에게 적절한 통제권을 부여한다.) - 4. Consistency and standards (일관성과 표준성을 높인다.) - 5. Error prevention (사용자의 실수를 미연에 방지할 수 있도록 설계한다.) - 6. Recognition rather than recall (사용자가 적은 인지적 노력으로 시스템을 사용할 수 있게 한다.) - 7. Flexibility and efficiency of use (사용자가 시스템을 유연하게 사용할 수 있도록 한다.) - 8. Aesthetic and minimalist design (심미적이고 간결한 시스템 디자인을 제공한다.) - 9. Help users recognize, Diagnose, and recover from errors (에러 발생시 사용자 스스로 문제를 파악하고 수정할 수 있도록 설계한다.) - 10. Help and documentation (사용자에게 충분한 도움말을 제공한다.) 또한 해당에 대한 평가가 따로 4가지로 나뉘어 존재하는데 해당은 나중에 기회가 된다면 추가하는걸로..
16. 개발기간 : 개발기간은 꼭 필요하다. 언제부터 언제까지 어떠한 기능을 구현하고 결국 언제 완성을 할것인지. 꼭 있어야하는부분. 이부분이 없다면 개발자들은 헤이하게 멍때리고 있을지도..(웃음)
17. 시연의 경우 있어도 되고 없어도 되지만 있으면 좋은게 해당 프로그램을 어떠한형식으로 실행하는지 타인들에게 좀더 이해력 높게 보여주기위해 있으면 좋다.
>> 사실 졸업작품을 개발할때 부랴부랴하느라 클래스도그렇고 함수들도그렇고 여기있을게 저기있고등등 아주 뒤죽박죽이다. 100점을 기준으로한다면 0점.. 역시 개발은 설계를 확실하게 잡아두고 진전을해야 괜찮은 프로그램이 나온다고 생각할 수 있다. 다음부터는 꼭 설계를 착실하게하고 개발을 할 수 있도록 해야겠다. 기회가 된다면 뒤죽박죽으로 짜여진 졸업작품을 조금 더 다듬어보는것도 내 실력을 향상시킬 좋은 기회가 될 것 같다.
