[과제 상세안내]
1. 스토리보드 작성하기
스토리보드는 보는 사람이 스토리의 내용을 쉽게 이해할 수 있도록 주요 장면을 그림으로 정리한 계획표를 말한다. 스토리보드는 시나리오의 내용을 시각화하여 표현하기 위한 도구인 동시에, 제작진 사이의 의사소통을 돕기 위한 중요한 수단이라 할 수 있다.
스토리보드에는 주제와 화면제목, 화면의 구성, 화면설명, 연결화면 등을 기록한다. 스토리보드는 그 형식과 용도에 따라 다양한 형식으로 작성할 수 있다. [네이버 지식백과] 스토리보드
스토리보드의 정의는 위와 같지만, 현업에서의 정의와 해석은 다르다는 것을 자료를 수집하면서 알게 되었습니다. 다양한 해석이 있겠지만 스토리보드를 과제로 안내한 이유는 '각 화면별로 필요한 기능들을 기재하고, 순서를 정리하기 위함'이었습니다.
* 스토리보드 보다는 '기능이 표현된 화면이 곁들여진 정보구조도'가 보다 정확한 표현일 것 같습니다.
이전 작업했던 'gelato' 스토리보드
이전 작업했던 'Frutto' 스토리보드 중 일부
첨부한 이미지와 같이 화면별로 필요한 기능들을 기재하고 화면의 순서를 배열하여 흐름을 정리해주세요. 화면의 단계가 많아지고, 구성이 복잡해질때 유용하게 활용하실 수 있습니다.
[스토리보드 관련 참고자료]
- How to Storyboard an App or Website
- 프로젝트의 최종산출물 스토리보드
* 스토리보드 이전과 쉽게 전달하기 위한 작업, 즉 이야기를 전개하는 작업으로 보는 분도 있지만 최근에는 화면 명세서와 같이 고도화된 작업으로 사용되기도 하나봅니다. 정보구조도(IA), 유저 플로우, 화면명세서 등과 혼재되어 사용되는데, 이 부분은 조금 더 공부하여 추후 안내드리겠습니다.
2. 디자인 컨셉 정하기(무드보드 만들기, 브랜딩)
무드보드는 이미지, 텍스트 및 구성의 개체 샘플로 구성된 시각적 표현 또는 '콜라주'의 한 유형입니다. 설정된 주제를 기반으로하거나 무작위로 선택한 모든 자료가 될 수 있습니다. 무드보드는 특정 주제에 대한 일반적인 생각이나 느낌을 전달하는 데 사용할 수 있습니다. https://en.wikipedia.org/wiki/Mood_board
'Moodboard' Google 검색 결과
무드보드를 만드는 이유는 만들고자 하는 서비스, 상상하고 있는 모습을 구체적으로 시각화 하기 위함입니다. 전문 디자인 툴을 활용해 일목요연하게 정리할 수도 있겠지만 서비스를 리서치해서 정리해두거나, 원하는 느낌의 이미지들을 캡쳐해서 PPT에 간단하게 구성하는 것도 방법입니다. 무드보드를 활용해 팀원들과 같은 완성하고자 하는 서비스의 모습을 일치시켜 혼선을 줄일 수 있습니다.
* 이미 디자인 방향성이 잡힌 팀들은 어디서 영감을 얻었는지 설명해주시면 좋을 것 같습니다.
NEWBASE 재직시절 작성했던 무드보드
발췌
브랜드를 구성하는 다양한 요소들이 있습니다. 이번 act.3에서는 컬러, 폰트, 닮고 싶은 서비스 3가지를 픽스하고, 한 페이지에 정리해서 팀원들과 공유하고, Paring에 활용해주세요.
* 디자이너들의 포트폴리오가 많이 올라오는 Behance가 디자인 레퍼런스를 찾기 용이하나 실현가능성보다는 컨셉에 집중되어 있는 경향이 있으니 리서치시 참고해주세요!
3. 와이어프레임 작성
페이지 회로도 또는 화면 청사진이라고도하는 웹 사이트 와이어 프레임은 웹 사이트의 골격 프레임 워크를 나타내는 시각적 가이드입니다. 와이어 프레임은 특정 목적을 가장 잘 달성하기 위해 요소를 배열하기 위해 만들어집니다. 이 분야는 L. te Pas에 의해 만들어졌습니다. https://en.wikipedia.org/wiki/Website_wireframe
이름 그대로 철사(wire)로 틀(frame)을 만드는 과정으로 화면 단위의 레이아웃을 설계하는 작업입니다. 의사소통 관계자들과 레이아웃을 협의하거나 서비스 흐름을 공유하기 위해 사용하며 UI, UX 설계에 집중되어 있습니다.
손 스케치로 초안을 만들고, 흑백 점선면을 활용해 간략하게 화면을 그리고 레이아웃을 잡아 페이지를 점검합니다.컬러, 폰트, 이미지등의 디자인 요소를 배제하고 흑백, 기본서체, 박스를 활용해 작업하는 것이 일반적입니다.
4. 서비스 DB 설계
여러분의 서비스는 혹시 DB가 필요한 서비스인가요?
정말 단순한 토이 프로젝트가 아니라, 진지하게 운영까지 생각하고 있으시다면 서비스의 DB는 정말로 x100 중요합니다. 짧게는 몇 개월, 길게는 몇 년 동안 서비스를 운영해본 경험이 있다면 이 부분을 매우 공감하실 것 같아요. 그런 경험이 없더라도 이미... 그 중요성은 몸으로 느끼시고 계실 것 같네요 
운영중인 API 서버나 프론트엔드의 로직을 변경하는 것이 달리는 자동차의 바퀴를 갈아끼우는 정도의 난이도를 가지고 있다면... 운영중인 DB를 다른 종류의 DB로 Migration하는 일은 날아가는 로켓의 엔진을 바꾸는 정도의 난이도를 가지고 있다고 생각합니다. 한 번 정하고 나면 옮기기 매우 난감한 컴포넌트라서 매우 신중하게 결정해야 하는 부분이겠죠! 그래서 서비스 DB를 설계하는 부분에 대해서 조금의 가이드를 드리려고 해요.
아래의 질문에 대해서 스스로 대답하고, 기록해보면 이번 가이드로는 충분할 것 같아요.
1.
어떤 종류의 DB를 사용하고 계신가요?(ex: RDB, NoSQL, GraphDB, TSDB), 왜 해당 종류의 데이터베이스를 선택하셨나요?
2.
어떤 DB(ex: SQLite, MySQL, PostgreSQL, MariaDB, MongoDB, Firebase, Neo4j)를 사용하고 계신가요? 왜 해당 데이터베이스를 선택하셨나요?
3.
클라우드 서비스인가요? 가격은 얼마인가요? SLA가 있는 서비스인가요?
4.
어느 정도 성능이 나오나요? 1,000명의 유저가 사용한다고 가정한다면 병목이 예상되는 테이블이 있나요?
5.
ERD를 그려보셨나요? 서비스 DB 구조 중 특이하다고 생각하는 부분이 있으신가요?
(꼭 백엔드 데이터베이스를 운영하고 있지 않더라도 클라이언트 데이터베이스 또는 언어나, 프레임워크등 기술의 선택 이유에 대해서 진지하게 생각해 보셨으면 좋겠어요)
위에서 1,2,3,4 부분은 ADR (Architecture Decision Records)로 작성해두면 새 팀원이 합류했을 때 백그라운드를 이해하기 쉽게 해주고, 5부분을 작성해보면 실 서비스를 운영하기 전에 리스크가 있는 부분을 미리 점검해 볼 수 있습니다. 미리 고민하고 기록해두면 새 팀원이 합류할 때 온보딩이 빨라지는 효과 말고도, 기술면접에서 자신 있게 본인의 프로젝트에 대해서 설명할 수 있어지겠죠?
[서비스 DB 설계 관련 참고자료]
다이어그램 작성 도구
- https://drawsql.app/templates → 프로젝트의 DB 구조를 웹으로 보여줄 수 있어 포트폴리오로 활용!
- https://www.jetbrains.com/help/datagrip/creating-diagrams.html → Database에 연결만 하면 Diagram으로!
ADR (Architecture Decision Records)을 써야 하는 이유
- https://news.hada.io/topic?id=2665
ADR (Architecture Decision Records)이란, 예제
- https://github.com/joelparkerhenderson/architecture_decision_record
AWS RDS SLA (Service Level Agreement)
- https://aws.amazon.com/rds/sla/