일정과 투두리스트를 연관지어 같이 관리하면 더욱 일정관리를 체계적으로 할 수 있을 것 같아 기획하게 되었음
- 일정을 보다 체계적으로 관리하고 싶은 mbti J를 타겟
- 계획성이 부족하여 도움을 받고 싶은 mbti P를 타겟
- 할일을 잘 까먹거나 정리하고 싶은 사람들을 위해
기획 및 설계 : 06.24 ~ 06.25 (2일)
- 기획 : 프로젝트 아이디어 논의, 주제 구체화, 기술 스택 선정
- 설계 : 화면 설계, 기능 명세, DB 설계
개발 : 06.25 ~ 06.28 (4일)
- Front : 프로젝트 환경 설정, 페이지 UI 구현, Todo리스트 및 달력 등 핵심 기능 구현
- Back : API 개발 및 수정, DB 구성, 배포 및 인프라 구축
테스트 및 배포 : 06.28 ~ 06.29 (2일)
- 통합 테스트 및 QA
- 산출물 정리
- 버전 관리
- Git
- GitHub
- SourceTree
- 일정 관리
- Jira
- 화면 및 흐름 설계
- Excalidraw
- Frontend: React, TailwindCSS
- Backend: Node.js, Express
- Database: MongoDB
- Deployment: AWS S3, AWS EC2
| 로그인, 회원가입 기능 |
|---|
![]() |
| Todo리스트 추가 기능 | 기한 있는 Todo리스트 추가 기능 |
|---|---|
![]() |
![]() |
| ### 👨🏫완료 여부 체크 및 중요한 투두리스트 고정 기능 | ### 📸투두리스트 상세보기, 수정 및 삭제 기능 |
|---|---|
![]() |
![]() |
| 이름 | 개발 내용 |
|---|---|
| 전승규 | 기한 있는 Todo CRUD 구현, Todo와 기한 있는 Todo 간 연결, Todo가 있는 날짜 조회 |
| 배성호 | 특정 날짜에 해당하는 Todo 가져오는 기능, 상단 고정 기능 추가에 따른 변경 사항 적용 |
| 이민욱 | 로그인/회원가입, Todo 리스트 CRUD 구현 |
| 이름 | 개발 내용 |
|---|---|
| 전승규 | Todo와 기한 있는 Todo 간 연결 기능, Todo가 있는 날짜 시각화 기능(달력) |
| 배성호 | 케이스에 따른 api 호출 로직 구현, 상단 고정 및 정렬기능 구현 |
| 이민욱 | 로그인/회원가입, 달력 UI/기능, 웹 디자인, Todo UI/기능 |
| 화면설계서 |
|---|
| 깃 | 지라 |
|---|---|
Jira, excalidraw, SourceTree를 처음 사용해봄
- 개발 첫 날에 협업이 매끄럽지 않음
- 어떤 기능들이 필요한지 확실하게 인지하지 못해서 각자 어떤 작업을 해야 하는지 파악이 잘 되지 않았습니다. 그래서 첫 날에는 각자 분업을 한 시간보다 셋이 같은 화면을 보며 작업을 한 시간이 더 길었던 것 같습니다.
- 둘째날 개발 시작 전 전체 진행 흐름을 그리며, 어떤 기능들이 필요한지 Jira에 작성함
- 전체 흐름을 그려보니, 해야 할 작업들이 조금 더 명확하게 보였습니다. 팀원들과 같은 공간에서 작업하여 Jira가 굳이 필요하지 않다고 느껴졌었지만, Jira를 사용하려고 노력하였습니다. Jira를 사용하다 보니, 팀원들과 대화를 하지 않고도 진행 상황을 파악할 수 있다는 것을 느꼈습니다.
- 깃허브 충돌 발생
- 작업을 하던 중 업데이트가 되면 로컬에서 먼저 merge를 하고 push를 해야 하는데, 까먹고 계속 pull을 하고 있었습니다. 그래서 어느 순간 코드가 없어진 것을 발견하게 되었고, merge를 하지 않았다는 것을 알았습니다. 이후 같은 상황이 와서 로컬에서 merge를 하였는데 충돌이 발생했고, 해결하는 과정이 조금 까다로웠지만 좋은 경험이었습니다.
개발 중 endpoint가 겹치는 상황 발생
- 겹쳤던 endpoint :
/api/todos/:id,/api/todos/:date,/api/todos/hasDate- 앞의 2개는 변수를 각각 다르게 받기에 별 생각 없었고,
/hasDate는 “hasDate”를 받기 때문에 전혀 겹치지 않는다고 생각했습니다. 해당 endpoint들을 사용할 때 오류가 발생해서 생각해보니, 예전에 비슷한 경험을 한 것이 떠올라서 endpoint를 바꾸었더니 잘 실행되었습니다. 각 endpoint를/api/todos/id/:id,/api/todos/date/:date로 수정(마지막껀 수정X)하였습니다.
- 앞의 2개는 변수를 각각 다르게 받기에 별 생각 없었고,
- 느낀 점
- 이러한 문제들을 겪으니, 기능을 확실히 정해두고 api 명세도 하면 좋았을 것 같다는 생각이 들었습니다.
초기 깃 전략 및 협업 툴 사용 미숙에 대한 아쉬움
한공간에서 그것도 바로 옆자리에서 작업을 했기에 깃 전략 및 협업 툴에 대해 체계적으로 전략을 수립하지 않아도 큰 무리 없이 프로젝트를 진행할 수 있었습니다. 하지만 조금 더 시간을 들여 체계적으로 전략을 수립하였다면 좋았을 텐데라는 아쉬움이 있습니다.
커밋 메세지에 대한 구체적인 명세를 정하지 않았기 때문에 가독성이 떨어졌고, 지라를 이용한 프로젝트 진행 현황 및 업무 할당 기능을 제대로 활용하지 않아 개발 도중에 본인이 무얼 해야 할지 헤매는 시간이 있었습니다.
그럼에도 무사히 마칠 수 있었던 이유는 팀원들 간에 원활한 의사소통에 있다고 생각합니다. 감사합니다.
투두리스트 기능을 개발하면서 React의 기능이 매우 유용했습니다. 할 일 항목을 추가하고 삭제하는 기능을 컴포넌트로 분리하여 관리함으로써 코드의 가독성과 유지보수성을 높일 수 있었습니다. 상태 관리를 통해 사용자 인터페이스를 동적으로 업데이트할 수 있어 사용자 경험을 크게 개선할 수 있었습니다.
또한, TailwindCSS를 사용해 빠르고 효율적으로 스타일링할 수 있었습니다. 유틸리티 클래스 기반의 접근 방식 덕분에 별도의 CSS 파일 없이도 스타일을 적용할 수 있었고, 이는 프로젝트 진행 중 스타일 충돌을 줄이는 데 큰 도움이 되었습니다. 투두리스트 애플리케이션의 핵심 기능을 구현하면서 각 기술의 강점을 체감할 수 있었습니다. React를 이용해 사용자가 투두 항목을 추가하고 삭제하는 인터페이스를 직관적으로 만들 수 있었고, 상태 관리를 통해 실시간 업데이트를 구현할 수 있었습니다.
이 기술 스택을 이용한 투두리스트 프로젝트는 최신 웹 개발 트렌드와 기술을 경험하고, 실무에 적용할 수 있는 좋은 기회였습니다. 각 기술의 장점을 극대화하면서도 단점을 보완하는 방법을 배우는 과정이 매우 유익했습니다. 앞으로도 이와 같은 기술 스택을 활용하여 더 많은 프로젝트를 진행하고, 지속적으로 발전해 나갈 계획입니다.






