다양한 사람들이 기부와 봉사를 더 쉽게 참여하고 능동적으로 기여할 수 있는 기회를 제공하여 사회적 가치와 연대감을 증진시키는 데 초점을 맞춘 서비스
기부하고자 하는 의지를 가진 사람들은 많지만 기부에 대한 불신이나 활동을 하고싶어도 접근성이 낮아 기부나 봉사활동에 참여하기 어려운 현실을 확인하고
투명하고 신뢰되는 기부 및 봉사 참여 플랫폼을 만들어 보자는 의견을 모아 제작하게 되었습니다.
- 23.08.05 - 23.09.01
- 팀장 : 임웅빈 - 로그인, 회원가입, 마이페이지
- 부팀장 : 허은상 - 사이트 소개, 늘해랑,검색,알람,고객지원,통계
- 팀원1 : 김보령 - 늘하장, 메인 페이지
- 팀원2 : 조현상 - 관리자 페이지, 공지사항
- 팀장 : 임웅빈 - 메인서비스(늘해랑, 늘하장)
- 부팀장 : 허은상 - 관리자 페이지, 공지사항, 문의사항,알림기능,메인페이지,작성페이지,소개페이지,통계페이지,AWS서버배포
- 팀원1 : 김보령 - 회원가입, 로그인, 검색
- 팀원2 : 조현상 - 마이 페이지
봉사활동에 참여 또는 주최 하고자 하는 사람들에게 편리한 플랫폼을 제공하여, 다양한 봉사기회를 찾을 수 있도록 돕고 사용자가 원하는 각 봉사 활동에 기부할 수 있어 좀더 세부적이고 구체적인 기부를 촉진할 수 있으며 본인이 기부한 기부금이 어디에 어떻게 쓰였는지 확인이 가능하고 그 기부금으로 도움을 받은 사람의 마음이 담긴 의미있는 보상도 받을 수 있는 기회를 제공해 좀 더 사용자의 기부에 대한 현장감과 동질감을 느낄 수 있게 하는것이 목적입니다.
1.다양한 채널에서 참여 촉진: 온라인 및 오프라인에서 기부와 봉사 활동에 참여할 수 있는 다양한 채널과 방법을 제공하여 모든 사람들이 쉽게 참여할 수 있도록 돕습니다.
2.기부와 봉사 투명성 강화: 기부금 사용 내역과 봉사 활동 결과를 투명하게 공개하여 참여자들이 자신의 기여가 어떤 영향을 미치는지 알 수 있도록 합니다.
3.사회적 홍보와 인센티브 제공: 참여자들의 기부와 봉사 활동을 사회적으로 인정하고 홍보하여 다른 사람들에게 영감을 줍니다. 또한, 기부와 봉사를 통해 얻는 인센티브나 혜택을 제공하여 참여를 유도합니다.
4.결론: 전국민 대상 기부 및 봉사 촉진과 독려 플랫폼은 사회적 참여와 협력을 강화하여 더 나은 사회를 구축하고자 하는 목표 아래 다양한 사람들이 더 쉽게 기부와 봉사에 참여하고 긍정적인 변화를 만들어내는 데 기여합니다.
- python
- Django
- Django-Model
- Django-Template
- HTML, CSS, JS
- MySQL
- AWS
- REST:API
- git, gitHub
- Kakao OAuth
- Email Api
- Chart.js
- BootPay
- 프로젝트 부팀장, 서비스 기획 및 전반적인 구성, 엔티티(ERD) 설계
- 퍼블리싱 업무 : 사이트 소개, 늘해랑,검색,알람,고객지원,통계페이지
- 백엔드 업무 : 관리자 페이지, 공지사항, 문의사항,알림기능,메인페이지,작성페이지,소개페이지,통계페이지
- aws 서버 배포 www.giboontake.site
- 사이트소개
-사이트소개 및 통계페이지 - 늘해랑
-늘해랑 목록
-늘해랑 상세보기
-늘해랑 리뷰 목록
-늘해랑 리뷰 상세보기 - 검색
-검색 폼
-입력 검색 페이지
-태그,카테고리 클릭 검색 페이지 - 알림, 고객지원
-알림 받는 페이지
-고객지원 목록
화면 구성
- 관리자페이지
-요약관리
-회원관리
-게시물관리
-공지사항
-문의사항 - 메인페이지
- 작성페이지(늘해랑,늘하장,리뷰)
- 소개페이지(소개,통계,파트너기관,기부&제안FAQ)
- 알림,고객센터
플로우차트
1.봉사와 기부펀딩을 주최하는 글을 작성할 때 입력받아야 하는 데이터도 매우 많고 자유로우며 사용자한테 직접적으로 보여질 상세보기에 들어갈 글 같은 경우 작성자 마음대로 소제목과 본문 추가삭제가 가능했고 이미지는 한개의 이미지 모음에 10개까지
추가삭제가 가능하고 각 사진마다 사진 설명도 달 수 있으며 이미지모음은 실제 상세보기에서 슬라이드가 가능해야 했습니다.
이부분에서 한번에 작성에 많은 데이터를 잘 정제해 담아야했고 하나의 작성글에 작성자의 마음대로 추가되는 정보들을 DB에 저장해야하는 부분에서 어려움을 겪었습니다.
이를 극복하기 위해 먼저 실제 상세보기글을 제외한 세부정보들은 모두 해당 작성글인 늘해랑을 외래키로 사용하는 모델을 만들어 데이터를 저장하고 불러왔고 각종 유효성검사로 우리가 원하는 방식으로 사용자가 데이터를 입력할 수 있게끔 설계했습니다.
마지막 상세보기 작성페이지 같은 경우는 모델 설계가 매우 힘들었는데 소제목,본문,이미지모음 이 세가지가 각자의 컨텐트의 순서를 기억하게하고 이미지모음 같은 경우 전체글의 순서도 가지고 각 이미지마다의 순서도 기억할 수 있도록 모델을 설계해
해당 문제를 해결하였고 데이터를 불러올때는 저장해두었던 컨텐트 오더로 데이터를 정렬한 후 컨텐트 오더가 달라질때마다 모델 객체를 분별하는 분기처리를 통해 올바른 태그와 데이터를 삽입하고 이미지모음 같은 경우 같은 컨텐트 오더를 가진 데이터라면
큰 이미지 모음 중 다음 이미지 이므로 리스트를 이어붙여 만들고 이전 컨텐트 오더를 기억했다가 다음 컨텐트오더와 비교해 달라지기 전까지 반복해 해결하였습니다.
2.기부를 하는 과정에서 우리가 설계했던 방식으론 주최자가 작성한 최대 모금액보다 더 많이 기부할 수 없도록 설계했습니다.
이 과정에서 사이트를 여러사람이 이용하는 동시성을 생각해봤을때 한 유저가 기부를 진행하는동안 다른유저도 기부를 진행하고있었고 두사람 모두 기부가 끝난 후엔 실제 DB에 최대 모금액보다 더많은 금액이 저장되었습니다.
이를 해결하기 위해 처음으로 생각했던 방식은 기부 결제를 진행하는 APIView를 싱크로나이즈를 걸어 하나의 쓰레드만 해당 뷰의 흐름을 이어나갈 수 있게 설계하고 다른 쓰레드는 락을 걸어주는 방식 이였습니다.
뷰의 앞단에 DB를 접근해 결제하려는 금액과 총 모금액을 비교해 막아주는 로직을 작성해 멀티 쓰레드 환경에서 결제 진행은 우리의 설계 방식대로 진행될 수 있도록 동기처리를 하려했습니다.
하지만 마감기한으로 인해 후속작업으로 진행하는것으로 결정하고 결제를 진행하는 그 순간에 APIView를 이용해 DB에 저장된 총 모금액과 결제 금액을 바탕으로 유효성검사만 진행해 최대한으로 해결했습니다.
3.관리자페이지 또는 무한스크롤을 이용하는 목록페이지, 댓글, 마이페이지에 정보를 나타내는 페이지들 너무많은 곳에서 페이징처리가 필요했습니다.
하지만 각 서비스마다 offset과 limit가 달랐고 필요한 데이터와 다음 데이터의 존재여부가 필요한지도 달랐습니다.
각 페이징처리가 필요한 서비스마다 로직을 뷰에서 작성하는것은 너무 비효율적이라고 느껴졌습니다.
저는 페이징 처리에 대한 불편함을 느끼자마자 클래스를 제작했고 처음에는 rowCount,pageCount,page,그리고 모델객체를 전달받아 페이징 처리에 필요한 모든 데이터를 가진 pagenator을 반환하도록 설계했습니다.
하지만 이렇게 설계하니 정확히 모델객체에서만 사용할 수 있었고 여러 모델객체가 섞이거나 다른 데이터의 페이징처리는 할 수 없었습니다.
따라서 페이지네이션 클래스를 list를 전달받을때와 querySet객체를전달받을때로 분기처리를 진행했고 전달받은 데이터에따른 페이징 처리 결과를 paged_data에 담아 모든곳에 사용할 수 있었습니다.
4.APIView를 이용해 데이터를 응답받을 때 DICT 타입이 아닌 모델객체 자체를 직렬화해 전달받아 이용하고 싶었습니다.
또한 해당 모델객체의 필드가 아닌 여러 테이블의 조인과 집계함수가 필요한 데이터 또한 같이 한번에 전달받고 싶었습니다.
이를 위해 Serializer에 대해 공부했고 ModelSerializer을 이용해 모델 객체를 직렬화해 전달했고 더 나아가 Serializer에 여러 필드 기능을 이용하여 특히히 methodField를 통한 내가 필요한 정제된 데이터를 같이 전달받을 수 있었습니다.
가장먼저 드는 생각은 너무 뿌듯했습니다.
열정이 넘치는 팀원들을 만나 짧은시간이지만 정말 많은 기능과 사이트 다운 사이트를 만들고 싶어 한달 내내 거의 매일 밤을 세듯 달려온 결과 만족스러운 결과물이 만들어 졌을 때 저는 희열을 느꼈습니다.
건강을 잃으면 모든걸 잃는다고 하지만 건강을 조금 잃었어도 너무 행복했던 결과였습니다.
두번째는 팀원들에게 너무 죄송했습니다.
같이 열정 바쳐 달려왔지만 제 욕심이 조금 커 팀원들한테 부담이 간 것 같아 죄송했고 그래도 각자에 위치에서 최선을다해 다같이 만들고자한 목표를 이뤄 너무 행복했습니다.
장고 프레임워크의 장단점에 대해 크게 느낀 것 같습니다.
장고의 장점으로는 빠른 개발속도와 인터프리터 내부의 컴파일러를 둔 설계 방식을 이용한 migrate를 통한 쉬운 모델 변경과 설계 그리고 강력한 orm기술을 제공한다는 점에서 시간이 매우 부족할 수 있는 양의 기능들을 손쉽고 빠르게 해결 가능하도록 도와주었습니다.
하지만 단점으로는 그만큼 많은 모듈을 내장해야하고 빌드속도가 느리며 알 수 없는 버그들이 있었습니다.
제가 겪었던 것은 헤더에있는 로그인 기능에서 로그인을 진행하기 전의 경로를 기억해 로그인이 완료되고 해당 경로로 다시 redirect하도록 설계하였는데 가끔 로그인 진행이 안되는 버그가 있었고
해당 버그가 발생할 때 마다 LoginView에서 redirect를 메인페이지로 보내는 문자열로 변경해야 했습니다.
1.매 로컬환경의 12시마다 실행되는 뷰를 만들어 늘해랑,늘하장의 endDate를 확인해 상태값을 변경해주는 로직과 변경되는 상태값에 따라 리뷰를 작성하거나 공략 진행글을 작성하라는 알림을 보내고 특정 기간내에 이행하지 않을 시 제제를 주는 로직이 필요합니다.
해당 부분은 후속작업에서 꼭 마무리하고싶은 작업입니다.
2.기회가 된다면 봉사활동의 현장을 담은 영상을 넣는 기능과 글작성을 도와주고 기부와 테이크에 대한 사이트 기능을 소개하며 사용자의 사이트 이용을 도울 챗봇을 만들어 더 높은 퀄리티의 사이트로 업그레이드 하고 싶습니다.
3.관리자 인증에 대한 인증과 인가에 대한 로직을 미들웨어를 사용해 구현해보고 싶습니다.
4.또한 기능 구현에 급급해 조금 막 짜여진 코드들에 대해서 다음번엔 조금더 신중하고 섬세한 설계를 바탕으로 재사용성 높고 가독성좋은 코드를 구현하고 싶고
그러기 위해 끊임없이 고민하고 공부하는 개발자로 성장할 것입니다.