• date: 2020-12 ~ 2021-01
• project url: https://github.com/redgoose-dev/checker-board
• app url: https://redgoose-dev.github.io/checker-board/

매일 원신이라는 게임을 플레이하고 있는데 아무래도 숙제라는 부분이 존재하다보니 반복적으로 할일들을 처리하는게 뒤죽박죽이었다. 그래서 착안한것이 미리 할일목록을 정해두고 거기에 집중해서 할일을 하고 체크를 한다면 해야할 일들이 혼란스럽지 않고 집중하기 때문에 처리 시간을 단축시킬 수 있을것이라고 생각했다.

매일마다의 할일에 대한 고민 포스팅에서 할일에 대한 필요성을 고민한적이 있었다. 이렇게 고민을 쭉 적어보다보니 하루하루 할일을 관리해야 할 필요성을 강하게 느낀다.
현재 trello서비스를 사용하고 있고, 미리알림이나 캘린더같은 일정관리 도구가 대단히 많지만 다들 하나하나 부족한점이 느껴졌다.

이리하여 checker-board라는 이름으로 프로그램을 만들자고 결심했다.
그전에 사용해왔던 todo list 프로그램이나 서비스들 중에 내가 원하는 방식이 존재하는지 고민해봤지만 원하는 기능을 가진 프로그램이 없어서 새로 만들자는 결론을 내린 것이다.

특징

체크박스 사용

글 본문은 마크다운 문서 형식으로 작성하며 - [ ] text 형식을 이용하여 체크박스를 만들어서 버튼 클릭으로 쉽게 항목을 체크하고 풀 수 있다.
마크다운 문서를 이용하여 문서를 유연하게 편집을 할 수있는것에 기초를 두고 핵심적인 기능인 체크박스를 쉽게 껏다켤 수 있도록 도와주는것을 핵심적인 기능으로 강조하고 있다.

매일매일 문서를 복제

설정한 리셋시간이 지난때에 접속하면 이전 날짜의 문서에서 복제한 상태로 오늘날짜 문서로 사용할 수 있다. 그리고 매일매일 문서가 복제되면서 체크박스가 풀리며 문서를 편집할 수 있다.

매일 오늘의 일에만 집중하지만 과거의 문서들을 찾아보면서 참고할 수 있어야 하기 때문에 과거의 문서는 편집할 수 없도록 규칙을 정해두었다.

구상하기

처음 아이디어를 떠올렸을때 매일 할일에 대한 체크리스트 포스트에다 생각나는대로 막 적어댔다. 그래서 포스트의 내용은 하나도 정리가 안되어있다.
그리고나서 아이디어를 더 늘려보기 위하여 다음과 같이 노트에 이리저리 끄적거려 보았다.

노트에 프로젝트 이름이랑 특징들을 적으면서 와이어프레임을 대략적으로 끄적여 보았다. 와이어프레임을 그리면서 다음과 같은 화면을 디자인할 목표가 만들어졌다.

• 보드 상세화면
• 보드목록
• 박스목록
• 박스 추가, 편집
• 환경설정

이정도 화면을 만들거라 예상하고 들어가는 UI 요소들을 글로 대략적으로 적어두었다.
이 프로젝트에서 가장 중요하게 여기는 요소는 오늘의 할일 문서를 보고 편집을 하는 것이기 때문에 다른 화면들은 전부 부가적인 부분이며 덧붙이면 될거라고 생각하고 있다.

각각 컨텐츠 요소들에 대한 용어는 다음과 같다.

• board: 글 하나하나에 대한 기초적인 요소들이라고 볼 수 있다. 아이템은 매일 하루에 하나씩 만들어지는걸 원칙으로 한다.
• box: 보드를 그루핑하는 요소. 주제를 여러가지 잡고 보드목록을 만들고 싶을때 사용할 수 있다.

프로젝트 이름이나 기능, 요소들을 노트에 낙서하며 디자인 작업을 하면서 구체화 시키는 단계로 넘어간다.

디자인 작업

구상하면서 그렸던 와이어프레임을 토대로 본격적인 디자인 작업을 시작하게 되었다.

컬러 선택하기

먼저 사용할 컬러를 설정하고자 Adobe Color 라는 서비스를 통하여 사용할 컬러조합을 찾아보았다. 컬러를 새로 만드는것보다 만들어져 있는 컬러 조합을 찾아서 쓰는것이 안전할거라 생각되어 인기있는 컬러조합을 찾아서 사용했다.
색을 정하고 라이트 모드에서만 적용해보고 진행했는데 다크모드에서도 썩 잘 어울려서 다행이다.

레이아웃 제작

대부분의 요소는 글자로 이루어져 있고, 면으로 영역을 나누었으며 위에 떠있는 컨텐츠는 그림자를 넣어서 공간을 분리시켜 보았다.
버튼같은 부분들은 대부분 아이콘을 사용하여 화면을 좀더 단순화 시켰다.

모든 화면을 전부 만든것은 아니고 주요 부분과 에셋 부분들을 미리 지정해두기 위한 작업이라고 볼 수 있다.
반응형을 위하여 모바일 화면을 먼저 만들고 데스크탑은 기본 화면과 창이 띄어졌을때의 모습만 만들어 두었다.

구상할때 모든 화면을 페이지로 나눌까 생각해보았지만 현재 바라보고 있는 문서의 내용은 고정적으로 노출되어있어야하는걸 집중시키기 위하여 다른 모든 화면을 모달창으로 돌린것은 잘한점이라고 보고있다.

스케치에서 다 만든 디자인을 제플린으로 옮겨두고 UI 제작할 단계로 넘어갔다.

심볼 제작하기

심볼은 개발작업까지 다 하다보니 앱 아이콘으로 심볼은 하나 만들어야겠다는 생각이 들어서 마지막으로 심볼을 구상하고 만들게 되었다.

이렇게 여러가지 디자인을 만들었다.
먼저 일반적으로 사용하는 체크를 넣고 박스속에 체크모양을 넣어보니 유닛이 많아져서 복잡해지니 작게 줄이면 명확해지지 않았다. 그래서 다른 부분은 전부 빼버리고 체크 부분만 남긴 안을 확정지어 버렸다.

프로그래밍

가장 핵심적인 단계인 구상했던것을 구현할 차례가 왔다.

처음에 고민할적에 개발스택을 어떻게 꾸려야할지 고민하고 리서치 해본적이 있었다. Web SQL이라는게 있었는데 이제는 안쓰게될 거라는것을 알게되었고, indexeddb라는것을 찾아서 이것으로 정하게 되었다. 그리고 기왕에 새로운 프로젝트를 만들면서 vue3 x typescript로 시작해서 공부해볼까 싶었다.
라우팅을 사용할까 고민해봤지만 어짜피 한페이지만 노출되고 그 외의 화면은 전부 모달로 열렸다 닫히게 할 계획이라 SPA 방식으로 만들기로 했다.

처음에 정했던 스택대로 개발환경을 구성하고 UI 만들기 위한 컴포넌트 제작 단계로 넘어갔다.

UI 만들기

먼저 컴포넌트를 제작하면서 html 마크업을 하고 css 코드도 작성했다.
처음 vue3를 접해보니 vue2와의 사용방법이 꽤 다른부분들이 많이보여 생소한 인상을 많이 받는다. 처음에는 자주 구글링을 하고 버벅대면서 조금씩 UI를 만들어 나갔다.

이번 프로젝트에 UI를 만들면서 처음부터 css var()를 적극적으로 활용하니 대단히 편하고 효율적이라는것을 많이 느끼게 된다. 하지만 scss의 중첩기능과 mixin 같은 유용한 기능들이 필요해서 scss를 완전히 버릴 수 없게된다. (순수한 css로 작성하기엔 코드작성 속도와 관리엔 여전히 scss가 필요하다.)

코딩하면서 문서의 본문을 좀 다른글꼴로 사용하는게 어떨까 싶어 좀 독특한 글꼴을 찾아보았다.
정말로 고맙게도 눈누라는 글꼴 서비스에서 공개된 글꼴을 쉽게 프리뷰 할 수 있으면서 다운로드 받을 수 있었다. 여기서 여러가지 글꼴을 적용해 보다가 빙그레 싸만코체라는 글꼴을 최종으로 선택하고 적용시켰다. 모든 글꼴이 고딕으로 이루어져 있으니 너무 삭막해 보이는것을 완화해보고 싶다는 생각에 좀 느려지더라도 웹글꼴을 사용하게 된것이다.

타입스크립트를 빼버리다.

컴포넌트를 하나씩 만들면서 타입스크립트도 같이 사용하다보니 하나부터 열까지 하는일이 전부 제동이 걸린다.
모든 부분들이 lint에 의해서 에디터에 경고 메시지 알림이 올라오면 신경이 쓰이고 경고문을 읽고 그걸 고치느라 구글링하며 삽질하느라 진행하고 있는 일을 잊어버리게 된다. 결국에 작업속도가 현저하게 떨어지는것을 느끼게 되는것을 깨닫게 되었다. 그걸 깨닫고 그 당시에 하... 타입스크립트 ㅠㅠ 라는 포스트를 작성한적이 있었는데 이걸 적을 당시에는 빡쳐서 타입스크립트를 빼야겠다는 결심을 하게 되었다.

데이터베이스 개발

여태까지 데이터베이스는 mysql만 다루어보았다.
indexeddb는 아마도 nosql종류라고 생각되는데 처음에 간단한 기능을 구현할때는 할만하다고 느껴졌다. 그래서 자바스크립트 데이터베이스 개발중.. 포스팅을 작성한적이 있었다.

데이터베이스 컨트롤러를 만들면서 점차 복잡한 요구가 필요하게 된다. 예를 들어서 box=1 && date=now > 2020-06 형태로 2개 이상의 필드를 복합적으로 데이터를 검색하는 요청이 나온다면 mysql 쿼리문이라면 그냥 쭉 작성하면 되겠지만 indexeddb는 쿼리문이 없다보니 금방 막혀버리게 된다.
새로운 방식이라 이해를 못하고 있는것인지 친절한 레퍼런스가 없고 그저 기초적인 사용방법만 적힌 문서들 뿐이라서 조금만 더 깊이 파고드려하면 해결이 쉽지 않았다.
그나마 다행이라는 것은 로컬로 db를 읽고 쓰기 때문에 속도에 큰 지장이 없어서 좀 무리가 가는 코드를 작성해도 괜찮을거라는 기대감이 생겨 좀 비효율적인 코드를 작성를 작성하게 된다. 하지만 sql 쿼리문을 대체할 좋은 방법이 쉽게 찾아지지 않아서 비효율적으로 데이터를 처리한 부분이 좀 있긴하다.

처음으로 새로운 db를 사용해보는것도 숙련도가 떨어지지만 즐거운 경험을 느끼게 된 좋은 기회가 되었다.

컨트롤 처리

개발 파트를 처음 접할때는 '뭐.. 간단하겠지' 싶었는데 어느정도 진행되어가니 실타래가 점점 복잡하게 꼬여가는 기분이 든다.
라우터가 있었으면 페이지마다 명확하게 분리되어 있었겠지만 컴포넌트끼리 상호작용이 일어날때 복잡해지는 관계를 잘 정리하는 일이 관건이 되어버렸다.

vuex를 사용하면서 store 데이터는 환경설정을 담고, 값이 변경되면 localstorage에 업데이트 되도록 조정하고 나머지 데이터 부분은 indexeddb 컨트롤러에 요청을 하면서 작동들을 처리하게 역할을 분리시켰다.
부모-자식 컴포넌트간의 통신을 얼마나 정리를 잘하느냐에 따라 컴포넌트의 복잡성이 결정짓다보니 아무래도 고민 좀 하면서 코드를 작성하게 된다.

vue3에서 composition api를 적극적으로 사용하다보니 기존 vue로 작성하는 스크립트 파트를 새로운 기분으로 작성할 수 있어서 재미있게 코딩을 할 수 있는 계기가 되었다.
처음 composition api가 작업하면서 예전의 vue로 되돌아가고싶다는 생각도 여러번 해봤다. 하지만 만든 사람들이 이렇게 쓰자는데 어떻게 하랴.. 따라갈 수 밖에 없는것을.. 어짜피 적응해서 잘 활용할 수 있다면 그만일 것이다.
결국 작업하다가 불가능이라는 이유로 진행에 막힌적이 없다는것이 다행이다.

이번에는 setup()라는 메서드속에 컴포넌트의 모든 로직이 다 들어가게 되니 규칙의 강제성은 약해지지만 자유롭게 코드를 작성할 수 있다는것이 react에서 느꼈던 인상이다. 그래서 react를 다시한번 만져보고 싶다는 생각도 문득 들었다.

테스트

기능을 어느정도 작업을 끝내고 간단하게 테스트를 하고 실제로 사용해보면서 문제가 있거나 개선해야할 부분들을 이슈에 기록해두고, 하나씩 처리를 하면서 얼추 이정도면 됐다싶을때 버전을 1.0.0으로 올리고 마무리 지었다.

마치며

프로그램을 어느정도 완성하면서 테스트겸 다음과 같이 몇일째 사용하고 있다.

1. 아침에 일어난다.
2. checker-board url 에 접속한다.
3. 오늘 무엇을 해야하는지 고민하면서 전날에서 복제된 할일목록 문서를 수정한다.
4. 하루 일과를 보내면서 하나씩 체킹한다.
5. 하는일에 대한 뭔가 기록을 해둘만한것이 있으면 할일목록 문서를 편집해가면서 내용을 추가하면서 기록한다.
6. 내일 할일들은 새로운 섹션을 만들어서 내용을 추가해도 좋을 것이다.
7. 자기전에 오늘 할일에 대하여 좀더 확인해보고 내일로 미룰거나 오늘 어땠는지에 대하여 생각해본다. (자아성찰의 시간)
8. 잠을 잔다.

대략적으로 일주일정도 사용하고 있을때 목록을 확인해보니 마치 일기같이 데이터가 모이는 느낌이다.
체크리스트를 작성하고 거기에 대한 코멘트들을 같이 기록해두니 과거의 하루하루가 어떤일을 해왔는제 좀더 명확하게 확인해볼 수 있어 보인다.
첫인상은 사용하기 쓸만하다고 느껴지고 오랫동안 사용하면 좋은 데이터가 만들어질거라는 기대감도 든다.

마치 일기같은 모습을 한 프로그램이지만 규칙적인 생활을 이끌어나갈 수 있는 도구가 될 수 있기를 바라면서 만들었기 때문에 기왕에 만들었으니 잘 썼으면 좋겠다.

첫인상으로 느끼는 점이 좋아서인지 goose프로젝트에 이 기능을 붙여볼까 하는 생각마저 들었다.
아마도 2,3달정도 사용하다가 계속 쓰이겠다 싶으면 이 기능을 goose프로젝트에 추가 해보는것도 어떨까 생각해보면서 하루하루 잘 써볼것이다.