깔끔하게 휴식을 마치고 와서 그런지 그나마 머리가 말끔해져서 오늘은 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은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.
그래서 빠르게! 오늘 할 수 있는 부분만 정리하고 일찍 잠 좀(...) 자려고 합니다! (그러는 지금 시간은 0시 4분...)
아마 오늘 한 부분은 졸면서, 또 일단 주먹구구식으로 한 부분도 있어서 추후 변경될 부분이 많이 있을 것 같습니다.
무엇보다 이것저것 요구사항이 늘어지다보니 타협이 잘 안되더라구요. (자신이 자신한테 많은 요구사항을 던지다니..)
그래도 개발을 진행하기 위해서는 미뤄지면 안된다는 생각에 후딱 정리해보았습니다.
Wireframe (장비관리-장비목록)
Wireframe (장비관리 - 장비목록)
이 프로젝트에서의 저의 역할은 아무래도 기획자인 동시에 설계자이고 개발자이기 때문에 요구사항을 제가 직접 밀어(?) 넣을 수 있습니다. 그렇다보니, 장비 목록을 오픈마켓들과 같은 느낌으로 이미지와 정보를 한 눈에 볼 수 있는 화면을 요구사항으로 생각하게 되었습니다. 그래서 설계시에도 많은 고려를 했구요.
지금 Wireframe만 보고는 조금 판단이 어려울 수 있으나, 아래 화면설계서를 보시면 어딘가 살짝 오픈마켓과 같은 느낌을 받을 수 있을 것 같습니다.
화면설계서 - PC (장비관리-장비목록)
화면설계서 - PC (장비관리-장비목록)
이제 설명 3번을 눈으로 보고 있다보면 오픈마켓의 화면과 비슷한 느낌을 받으실 수 있습니다.
이로써 장비를 관리하는 관리자 입장에서는 어떤 장비인지 이미지를 통해 확실하게 확인을 할 수 있지 않을까 싶습니다.
또 각 상태별로 이미지를 신호등 색으로 보여줌으로써 어떠한 상태인지도 확인이 가능하게 하도록 생각중입니다.
추가적인 부분이지만, 아마 detail한 규격이나 사용용도도 Tooltip 형식등을 통하여 확인을 할 수 있도록 하려고 생각중입니다.
다만, 현재 화면설계서와 앞으로 나올 디자인된 UI와의 갭이 생길 수 있어 이 부분은 추후 다시한번 고려해볼 생각입니다.
화면설계서 - Mobile (장비관리-장비목록)
화면설계서 - Mobile (장비관리-장비목록)
마지막으로 모바일버전의 장비목록입니다.
여기서는 상태가 안보이는 모습으로 보이는데, 모바일로 볼 수 있는 정보는 PC보다는 적게 만들어볼까 합니다.
(PC보다는 적은양의 정보 - 대신 중요한 정보는 더 부각되어 볼 수 있도록)
어차피 목록은 목록일뿐 더 detail한 정보가 보고 싶다면 큰 화면으로 볼 수 있는 PC나 상세정보페이지에서 봐야하는게 맞다고 생각하고 있습니다.
어쩌면 PC와 Mobile에 차이를 두고 정보의 양을 제한한다는 점은 조금 위험한 생각일 수 있으나, 보이는 화면의 크기가 다르고, 물리적인 제약이 따를 수 밖에 없는 만큼 고려하고 있는 부분입니다.
