기획&설계 - 시스템 설계를 위한 기획, 기획과 설계는 밀접한 관계가 있다.
오늘은 저만의 생각일지도 모르겠지만, 이런 주제를 들고와봤습니다.
- 시스템 설계를 위한 기획, 기획과 설계는 밀접한 관계가 있다.
저는 몇년간 여러 프로젝트를 진행하면서, 그 프로젝트들 사이에서 주로 개발을, 때로는 설계를 진행해보기도 했는데요,
(어떤때는 혼자 프로젝트를 진행하며 모든걸 해보기도 하고..)
경험속에서 어떠한 상황이 있었고, 이러한 경우에는 어떤 방식을 택해 해결을 해볼 수 있는지 고민해보고자 글을 작성해봅니다!
보통 요즘의 기업들이 에자일 방식(소프트웨어 개발론으로 생각해보자면)을 택하고 있는 이상 기존의 요구사항을 토대로 프로토타입성의 결과물을 만들어내고 이후 추가적인 요구사항을 받아 보완해나아가는 형식을 취하고 있습니다.
에자일 방식은 그만큼 유저가 필요한 기능을 파악하고 검토 그리고 다시 수정을 하기 위한 프로젝트에서 가장 적합한 프로세스이기는 하지만, 문제는 이 에자일 방식에서의 설계 방식에 많은 어려움을 겪기도 합니다.
(에자일방식이라고 해서 설계자료 없이 개발을 할 순 없으니 말이죠.)
시스템 개발이라는건 상황에 따라서는 기존 개발방식을 깨고 새로운 개발방식이 필요한 경우가 있습니다.
이러한 경우는 기존 요구사항에서 새로운 요구사항으로 변경되면서 어쩔수없이 시스템의 구조가 변경되어야하는 경우인데,
이런 경우에는 개발자들은 리팩토링이나, 그냥 새로 개발하는 경우가 종종 발생하곤 합니다. (그냥 새로 만드는게 더 빠른 경우)
큰 문제는 리팩토링이 되었건, 새로 만드는 만드는 경우가 되었건 시간적, 인력적 코스트는 엄청나게 들곤 하죠..(결국엔 Money!)
그렇다면 설계자는 이러한 경우를 피하기 위해서는 어떻게 해야할까요?
기획의 명확한 의도를 파악하고(요구사항을 정확히 파악), 그 의도에서 새로 생길 수 있는 수정사항을 미리 고려하는 것입니다.
말이 어려울 수 있으니, 쉽게 설명해보자면.. 흠..
기획단계에서 나온 모든 요구사항을 전부 고려를 하는겁니다.
더 쉽게 말하면 확장성을 모두 고려해서 설계를 해야한다는 말이 가장 와닿을 수 있겠네요.
물론, 그 모든 요구사항을 충족할만한 시스템은 만들기 어렵겠지만,
확장성을 고려한 한번의 설계로 나중에도 문제 없이 개발을 진행할 수 있는 견고한 시스템(확장성이 쉬운)이 만들어진다면
개발자에게 있어서는 너무 감사하게도 나중에 생성될 야근시간이(시간적 코스트) 줄어들테고,
투입될 인력적인 부분(인력적 코스트)에 있어서도 많은 최적화를 이뤄낼 수 있을겁니다.
여기서 중요한건 설계뿐만이 아니라는 겁니다.
당연하게도 기획자는 기획의 의도를 명확히 해야할 필요가 있으며,
그 기획의 의도속에서도 추가적인 아이디어가 있다면 미리미리 첨언해준다면(그냥 툭 튀어나온 반영하지 않을 요구사항도 따로 정리해서) 설계에 있어 미리 확장성을 고려할 여지를 남겨두게 된다는 겁니다.
여기서 제 경험상으론 단순 아이디어(그냥 툭 내뱉은 아이디어)는 결코 단순 아이디어가 아닙니다.
그저 후보군으로 나왔었던 아이디어더라도, 추후 어떠한 결과로 다시 구현하게 될 지 모르는 암흑속의 존재(?)일지 모르기 때문에
기획자는 번거롭겠지만, 추후에 확장이 될 여지가 단 0.0000001%라도 있다면 설계자에게 어떠한 상황으로든 알려주는 것이 좋습니다.
이런 면에 있어서 저는 보통 기획부분과 설계부분을 엮어서 생각하는 경우가 있는데요,
보통 기획단에서 사용하는 Wireframe을 저는 개발하기에 좀 더 편한 저만의 Wireframe으로 조금 변형을 해서 쓰곤 합니다.
이러한 이유는 기획자의 의도가 개발단으로 넘어가면서 변질되지 않는것을 추구하기 때문이기는 하는데..
사실 개발자(저)의 시선으로 보면 기획 단의 Wireframe은 개발에 참고하기 위한 부분이 많이 부족하다고 느껴집니다. (구체적일수록 좋은데 말이죠..)
화면설계서라는 설계문서가 중간에 들어가기는 하지만, 이러한 화면설계서에서도 단순히 Wireframe과 요구사항만 보고 설계문서를 만들어내기란 쉽지 않기에 사람이 보기 편한 이미지적인 요소인 Wireframe을 좀 더 개발자에게도 확 와닿는 하나의 개발문서가 되었으면 좋겠다는 생각으로 커스텀을 해보게 되었습니다. (제가 본 블로그에 작성한 Wireframe에 관한 내용도 있으니, 하단의 링크를 통해 구경해보셔도 좋을 것 같습니다.)
-> Wireframe 참고
Wireframe - 백문이 불여일견
Wireframe - 백문이 불여일견 깔끔하게 휴식을 마치고 와서 그런지 그나마 머리가 말끔해져서 오늘은 Wireframe을 소개해볼까 합니다. (?! 갑자기 ?!) 사실 제가 쓰는 이런 설계단의 문서들은 어려워하
karzin.tistory.com
물론 해당 게시글은 개인적인 감상, 견해가 듬뿍듬뿍 들어가 있으므로, 다른분들은 어떠한 생각이실지 궁금하기는 합니다. 그냥 이런 생각을 하는 사람도 있구나 생각을...ㅋ...
(좋은 글, 좋은 생각이 있으시다면 댓글 달아주세요! 저도 많이 배우고, 또 배워야합니다 ㅠㅠ)
이렇듯 기획과 설계는 거의 한몸(??)이 되어 서로의 생각을 아낌없이(???) 나눠야하며,
최소한의 코스트로 최대한의 완성도가 높은 결과물을 뽑는게 최고의 협업 환경이 아닐까 생각이 듭니다.
버전정보 (v1.0)
- v1.0 2021.01.02 배포
* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.
* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.
* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.
Karzin
abbeea@naver.com
'컴퓨터 이야기 > 분석 및 설계' 카테고리의 다른 글
| Wireframe - 백문이 불여일견 (0) | 2020.07.28 |
|---|---|
| 프로젝트 개발 모형 : 폭포수 모델, 애자일 방법(XP방법론) (0) | 2020.07.13 |
| Persona - 효율적인 UX디자인을 위한 시작 (0) | 2020.07.07 |
| [언어분석] 자전거를 이용한 언어의 이해!_1-1 (0) | 2018.09.09 |
| [언어분석] 자전거를 이용한 언어의 이해!_프롤로그 (0) | 2018.09.08 |
