프로젝트:샐로그
샐로그?
가장 최근에 진행했던 Wrieating 프로젝트는 헬스케어 보조 웹 애플리케이션이라면 이번에는 금융 보조 웹 애플리케이션이다.
샐로그(Salog) 프로젝트는 비쥬얼 가계부 웹 애플리케이션으로 기본적인 가계부 기능과 사용자의 수입, 지출 내역에 대한 통계, 일기식 개인 볼로그 기능들이 포함된다.
또한, 지출 내역을 작성할 시에 영수증 이미지를 업로드 해 API를 활용, 문자열로 읽어들여 자동 작성되는 기능도 추가할 것이다.
이외에도 목표 금액을 정해놓고 해당 금액 이상 지출하지 않으면 업적이나, 화면 구성을 통해 사용자에게 합리적인 지출을 유도하는 시스템도 추가할 예정이다.
기본적인 기능을 구현한 후 추가적인 리팩토링을 통해 많은 기능을 추가해볼 예정이고, 업데이트는 나 포함 팀원들의 일정이 맞으면 계속될 것이다.
왜 샐로그인가?
이 샐로그를 시작하게 된 이유는 사실 별거 없다.
나는 고정적인 지출을 확인하기 위해 액셀을 활용하고 있었는데, 가계부를 위한 프로그램이 아닌 만큼 불편한 점이 많았다.
그래서 가계부 웹 애플리케이션을 하나 만들까 생각이 든 것이다.
거기에 더 해 개발을 할 줄 아는데, 굳이 다른 이들이 만든 가계부를 사용할 이유가 있을까.
그래서 제작하기로 마음 먹었다.
이 뿐만 아니라, 금융은 남녀노소, 남녀, 성별을 불문하고 모든 사람들이 중요하게 생각하는 요소이고 특히나 효율적인 소비와 지출을 위해 가계부를 사용하는 사람들이 많다.
그렇기 때문에 다양한 연령층으로부터 피드백을 받을 수 있을 것이고, 불특정 다수에게 서비스하기 위한 방법을 알아 낼 수 있을 것이라 생각이 들었다.
그리고 서비스 목표가 개인 전용 웹 애플리케이션이기 때문에 많은 이들이 부담없이 사용할 수 있을 것이다.
이러한 이유로 인해 이번 샐로그 프로젝트를 시작하게 되었다.
처음에는 혼자 간단하게 만들어볼까 생각했지만 이왕 제작하는 거 메인급으로 제대로 해보기 위해, 특히 협업 툴과 커뮤니케이션을 업그레이드하기 위해 팀을 꾸리게 되었다.
적용해볼 특별한 기술은?
Wrieating에서 집중적으로 사용한 기술은 AWS와 Github Action, 주로 배포 관련이었고, 개발 시에는 JPA를 통한 쿼리 활용이었다.
이 당시에는 첫 프로젝트인 만큼 배웠던 웹 개발의 기본을 적용했기 때문에 API를 활용했던 것과 배포, JPA를 조금 더 깊게 다루어 페이징 처리에 대한 이해와 검색 쿼리 구현, 통계 쿼리 구현이 최대 문제였다.
그래서 이번 샐로그 프로젝트에서는 당시에 해보려고 했지만 못 했던, 당시에는 이해하지 못 했던 기술들을 적용해볼 것이다.
첫 번째로, Docker를 사용하여 자동 배포 환경 구성이 있다.
이 도커는 최근 많은 기업에서 활용 중이고 개발, 배포, 실행 시에 어느 환경이든 동일한 환경을 구성할 수 있다.
다시 말해, “내 컴퓨터에서는 잘 돌아가는데, 왜 서버에서는 안 돌아가지?”를 해결할 수 있는 것이다.
특별히 도커를 사용해 배포를 하려는 이유는 위와 같다.
일관된 환경을 유지하여 서로 다른 환경에서도 서버가 동일하게 동작하도록 하기 위함이다.
이외에도 효율적 리소스 사용, 확장성 등을 위해 사용할 수 있지만, 지금 당장은 도커에 대해 알아가야하는 단계이기 때문에 위 내용 정도만 숙지하고 일단 진행할 것이다.
두 번째로, APM 툴 사용이다.
Wrieating 배포 당시 서버에서 응답이 지연되는 문제가 있었는데, 이 문제가 회원 관련 요청 시에만 나타나서 어떤 문제인지 파악하기가 힘들었다.
브라우저 개발자 툴로 열어서 요청과 응답을 보면 요청이 보내진 것인지도 제대로 확인이 안되, 어디서 문제가 있는지 알지 못하고 케이스가 종료되어서 굉장히 아쉬웠던 적이 있다.
당시에는 결국 재배포를 하여 해결하였는데 APM 툴을 적용해서 뜯어보았으면 핀포인트로 확인할 수 있지 않았을까 싶다.
그래서 이번에는 APM 툴을 AWS 클라우드와치나 데이터독 등을 활용하여 서버에 적용해볼 것이다.
모니터링을 통해 문제를 빠르게 파악하여 해결해보려고 하는 연습이 될 것이다.
아마 그런데 AWS로 배포를 하기 때문에 클라우드와치를 활용할 가능성이 높다.
세 번째로, 대규모 트래픽 테스트와 핸들링이다.
항상 서비스는 대규모 트래픽에 대해 대비가 되어 있어야 한다고 생각한다.
어떤 시점에 요청이 과도하게 들어오는지 파악하여 서버가 문제없이 가동될 수 있게 해야 사용자 입장에서도 편할 것이다.
요즘 시대에 무엇이든 느리면 무조건적으로 불편한 것이다.
특히나 내가 담당하는 서버에서 그런 일이 있어서는 안된다고 생각한다.
물론 비용적 측면이나 트래픽이 과도하게 몰릴 일이 없는 상황 등등을 생각해야하지만, 해당 조건은 기업 내 프로젝트 시에 고려할 문제이고, 이 프로젝트는 연습이고 내가 어디까지 무엇을 할 수 있을까를 파악해야한다.
그렇기 때문에 이번 과제가 포함되었다.
이 과제는 JMeter로 테스트하고 APM 툴을 활용해 어느 부분에서 문제가 생기는지 파악, Redis, Kafka 등 서버 최적화 기술을 사용하여 핸들링할 것이다.
사실 Redis, Kafka는 정확히 모르는 기술이기 때문에 추후 과제를 진행할 때 공부할 것이다.
이 프로젝트가 진행된지는 이제 3주가 되었다.
아무래도 하루종일 진행하는 것이 아니라 하루 일과를 마치고 진행하기 떄문에 wrieating을 진행할 때보다 진척이 빠르지 않다.
기본 기능 구현 종료 예상 일은 1월 쯤이 되지 않을까 생각 중이다.
우선은 진행된 기간 동안 작성된 프로젝트 문서에 대해 정리하고, 현재 기본 배포는 도커를 활용한 자동 배포를 구성해 놓았기 때문에 해당 내용을 정리할 것이다.
현재는 구현 단계에 들어섰는데, 특별히 기록해놓아야할 내용이 없다면 블로그에 기록하지는 않을 것이다.
아마 구현 단계에서는 주요 기록 내용이 특별한 것이나, 에러 핸들링이 될 것이다.