2023. 2. 18. 09:02ㆍ프로젝트/8주차 실전 프로젝트
이전 포스팅
https://ksw0627.tistory.com/101
1. 기술 스택 선정에 대한 고찰 -1편-
1. TypeScript(이하 TS) 앞서 두 프로젝트(미니 프로젝트/클론 코딩)의 경우에는 Node.js로 작성되었다. JavaScript(이하 JS)를 이용하여 Node.js를 통해 서비스를 개발하면서 가장 많이 직면했던 문제점이 있
ksw0627.tistory.com
https://ksw0627.tistory.com/102
1. 기술 스택 선정에 대한 고찰 -2편 데이터베이스-
https://ksw0627.tistory.com/101 1. 기술 스택 선정에 대한 고찰 -1편- 1. TypeScript(이하 TS) 앞서 두 프로젝트(미니 프로젝트/클론 코딩)의 경우에는 Node.js로 작성되었다. JavaScript(이하 JS)를 이용하여 Node.js를
ksw0627.tistory.com
https://ksw0627.tistory.com/103
1. 기술 스택 선정에 대한 고찰 -3편 웹 서버-
이전 포스팅 https://ksw0627.tistory.com/101 1. 기술 스택 선정에 대한 고찰 -1편- 1. TypeScript(이하 TS) 앞서 두 프로젝트(미니 프로젝트/클론 코딩)의 경우에는 Node.js로 작성되었다. JavaScript(이하 JS)를 이용
ksw0627.tistory.com
https://ksw0627.tistory.com/104
1. 기술 스택 선정에 대한 고찰 -4편 유저 인증-
이전 포스팅 https://ksw0627.tistory.com/101 1. 기술 스택 선정에 대한 고찰 -1편- 1. TypeScript(이하 TS) 앞서 두 프로젝트(미니 프로젝트/클론 코딩)의 경우에는 Node.js로 작성되었다. JavaScript(이하 JS)를 이용
ksw0627.tistory.com
드디어 마지막 편이 될 것 같다. (그외 포스팅 해야할 것도 산더미....)
11. Cron(Scheduling)

스케쥴링을 사용하게 된 계기는 다음과 같다.
돈 모으기 목표의 상태 변화 갱신 : recruit -> proceeding -> done
참여한 유저의 중간 테이블(UserGoal)의 상태 변화 : recruit -> proceeding -> done
당연히 일일이 수작업으로 DB의 상태를 변경시키는 것은 말이 안되고, 매일 자정 목표가 시작되거나 끝날 경우, 상태를 자동적으로 적용하는 스케쥴링을 사용하게 되었다.
처음 기획 의도는 매일 자정 일괄 처리보다는 각각의 시작 시간에 대해 개별적인 스케쥴링을 작성하는 것이었으나(실제로 그렇게 구현 중이었다 ㅠㅠ) 프론트와의 통일과 일괄처리를 하는 것이 구현 난이도가 더 쉽고(일정에 쫓기고 있었기 때문에..) 테스트가 용이하다는 측면의 이유로 매일 자정 갱신하는 것으로 합의를 보았다.
Cron은 Unix 기반 운영체제에서 사용되는 가장 유명한 스케쥴러 중 하나로 특정 요일 시간에 대해 예정된 작업을 진행할 수 있도록 구현을 가능하게 해준다.
자세한 내용은 추후 포스팅에서 다룰 예정이다.
12. Slack Alarm

해당 기술의 사용은 기획 단계서 존재하지 않았던 것으로, 사용자 피드백을 받아 기능을 구현하기 위해 사용된 기술이다.
구체적으로는 불건전한 단어를 사용했을 때 신고하기 위해 만들어진 기능이다.

물론 다른 선택지로 디스코드나 다른 플랫폼이 있겠지만, 슬렉(텍스트)/ 게더(화상)을 통해 의사소통을 했기 때문에 슬렉을 통해 알람이 울리는 것이 합리적이라 판단되어 채택된 기술이다.
기획 단계서 기술적인 의사결정이 되었으나
실제 프로젝트에서는 사용하지 못한 기술
기획 단계서 팀원들과 함께 자료 조사하고 사용하기로 결정했으나 모종의이유(보안, 법적 문제, 책임 문제)로 사용하지 못한 기술이다. 이대로 묻히기엔 아쉬운 것 같아 포스팅을 하기로 했다.
13. Hyphen API

사설 API 플랫폼이다. 실제 계좌와 연동하기 위해 처음 알아보았던 것은 금융 결제원 API였으나, 사업자 정보와 승인받는 데 걸리는 시간을 고려하여 가격이 어느정도 나가더라도 사설 API를 사용하기로 했었다.
자료 조사를 통해 알게 된 사소한 정보들이 있다면
- 우리가 금융 어플에서 사용하는 1원 인증을 사설 API를 사용하면 300원이나 한다.
- 신분증 사진을 찍어 본인 인증을 하는 서비스는 50원이다.
정도가 될 것이다. 당연히 여기에는 박리다매도 있을 것이므로 이게 정가는 아닐 것이다(...)
그리고 직접 구현하면 비용이 더 절감되겠지만 우리 서비스에서는 비용을 어느정도 감수하더라도 이용자가 적고(회사에서 런칭하는 서비스가 아니므로) 이용에 제한을 둬서 조절하겠다는 계획이었다.
돈 모으는 습관을 형성하기 위한 서비스였으므로 금액 또한 제한을 두려고 하기도 했었다.
한 줄 요약으로 치면 이렇다.
보안 문제와 개발 일정을 못 맞췄다 ㅠㅠ
해당 내용은 좀 더 자세한 내용이 필요하다고 느꼈고, 추후 포스팅 이후 여기에 링크를 첨부할 예정이다.
'프로젝트 > 8주차 실전 프로젝트' 카테고리의 다른 글
| 2. 트러블 슈팅 -소셜 로그인 OAuth 2.0- (0) | 2023.02.18 |
|---|---|
| 2. 트러블 슈팅 -연관 테이블- (0) | 2023.02.18 |
| 1. 기술 스택 선정에 대한 고찰 -4편 유저 인증- (0) | 2023.02.18 |
| 1. 기술 스택 선정에 대한 고찰 -3편 웹 서버- (0) | 2023.02.18 |
| 1. 기술 스택 선정에 대한 고찰 -2편 데이터베이스- (0) | 2023.02.18 |