프로젝트 소개
JusiCool 프로젝트는
현재 국내 주식을 10분마다 가져와 실시간 주식을 기반으로 모의 주식 투자의 경험을 제공하는 앱 서비스이다.
백엔드 깃허브:
기간
6월 13일 ~ 7월 17일
멤버
AOS: 3명
BACK-END: 1명
DESIGN: 1명
시작 배경
어느 날 GSM(광주 소프트웨어 마이스터고)에는 GSM DEV FEST라는 컨퍼런스가 찾아왔다.
DEV FEST 컨퍼런스가 열린다고 하여 전시팀에 무조건 속해야 한다는 말이 들려왔다.
그래서 나는 여러 프로젝트가 거기에 신청한다고 하여 걱정하지 않던 참에
어느 친구가 말을 걸어왔다. 이렇게..
친구: 우리 모의 주식 투자 프로젝트해서 DEV FEST 나갈래??
사실 난 딱히 하고 싶지 않은 마음이 컸다.
그래서 난
나: 내가 왜?
그러다가 친구가 계속해달라고 했다.
사실 DEV FEST로 나가야 돼서 프로젝트를 하는 게 아닌
그냥 진지하게 배포를 목적으로 개발하고 싶기 때문이었다.
왜냐면 너무 주제가 신선하고 학교 안에서 이런 프로젝트를 해본 적도 드물기 때문이다.
그래서 난 KEEP GOING 하기로 하였다.
프로젝트 스타트
프로젝트 회의
사실 프로젝트를 하자는 친구 말고는 주식의 이해도는 거의 바닥이었고 사실 바닥마저도 아닌
바닥 밑으로 내려가고 싶어 바닥에 노크를 하는 그 정도였다.
그래서 어떻게 해야 될지도 모르겠었고 백엔드로 참여한 나는 ERD 조차 짜기 힘든 정도였다.
그리고 내가 이 프로젝트에 참여한다고 하는 조건이 있었는데 기능명세서를 짜서 오라는 것이었다.
그래서 친구가 짠 기능 명세서..
지금 보기에도 많이 부족하고 프로젝트 완성까지 해야 되는 기간이 1 달인데 너무나 많은 api가 존재했다.
지금도 후회되는 것 중 하나가 기능 명세서를 자세히, 상세히 쓰는 것이다.
넘어가서 그래서 기능 명세서에 없는 것도 있고 있는 것도 없는 기능이 존재한다.
하지만 난 어떻게든 ERD를 짜야 되기 때문에 짠 ERD이다.
여기서 수정되어 반영되지 않은 것도 존재하지만 틀은 이 정도이다.
지금 봐도 혼자 개발 어떻게 했는지 의문인 프로젝트이다..;
개발 시작
이제 ERD를 맞춰 개발하기 앞서 하나 짚고 넘어가야 되는 것이 있다.
이 프로젝트의 중심이자 핵심인 실시간 주식을 가져오는 것이다.
주식 API는 친구가 준 키움증권 OPEN API를 사용하기로 하였다.
그래서 이것을 어떻게 가져와서 DB에 넣을 것인가 고민을 하는 도중 검색을 하였다.
키움증권 API 자바..
하지만 자바는 존재하지 않고 python, c, c++ 밖에 존재하지 않았다.
중요한 건 내가 여기서 잘하는 언어는 하나도 없다는 것..
그래서 python 하는 친구를 구해서 개발을 맡기고 맘 편하게 개발을 진행했다.
처음에는 주식을 불러와야지 테스트하기 편하기 때문에 주식 관련 API는 뒤로 밀어놓고
부가적인 서비스의 API의 개발을 시작하기 시작했다.
Email -> Auth -> Community -> Board -> Like -> Stock -> Reservation -> User -> Day -> Receipt
이 순서로 API 개발을 진행하였다.
사실 Email 인증은 내가 해보고 싶어서 프로젝트에 넣어서 하자고 하였다.
그런 만큼 직접 이메일 인증 템플릿을 코드를 작성하여 추가하였다.
Auth API
어스 부분은 다른 소셜 로그인을 사용하지 않고 자체 로그인을 사용하여 서비스를 사용할 수 있게 작성하였다.
회원가입의 흐름을 간단히 보자면
이러한 프로세스로 진행되어 회원가입이 완료되고
로그인은
이러한 과정으로 진행되어 메인 페이지로 이동되게 된다.
Community , Board , Like
셋을 묶은 이유는 딱히 간단한 CRUD였고 별다른 로직이 없어 간단히 이야기하자면
Community
커뮤니티는 만드는 api는 존재하지 않는다. 왜냐면 이 부분을 개발할 때 이 프로젝트는 주식을 50개로 지정하였기 때문에
생성 또는 삭제, 수정할 필요가 존재하지 않는다. 그래서 DB에 SQL을 작성하여 넣기로 하였기 때문에 리스트를 가져오는
API밖에 존재하지 않는다.
Board
게시물 api는 커뮤니티에 하위에 존재한다. 예를 들어 삼성전자라는 커뮤니티에 게시물을 쓴다고 가정하면
삼성전자 주식 페이지 -> 삼성 전자 커뮤니티 -> 커뮤니티의 게시물
이런 식으로 존재하기 때문에 커뮤니티 아래에 게시물이 있다.
그래서 게시물에 커뮤니티를 단방향으로 매핑하여 커뮤니티의 정보를 가지고 있게끔 코드를 작성하였다.
Like
좋아요 api는 게시물에 좋아요를 누르고 취소하는 기능이다.
단지 좋아요를 누르는 것으로 끝나는 것이 아닌 좋아요를 누르고 만약에 좋아요를 누른 게시물이라면 좋아요를 중복으로 누를 수 없게
api를 추가하여 좋아요를 중복으로 누를 수 없게 개발했다.
Stock
이제 이 프로젝트의 핵심인 주식 api이다.
api 명세서를 보다시피 일단 매도와 매수 그리고 매도 예약, 매수 예약으로 크게 두 가지가 존재한다.
사실 처음에는 엔드포인트가 "stock_code"가 아닌 "stock_id"이었다. 그 이야기는 뒤에 다시 하니 계속 읽어주세요~
여기서 조금 힘든 점이었다면 리스트와 상세 보기를 빼고 매도 매수와 예약은 기록이 남거나 예약 중이라면 예약 테이블에 넣어야 되는
로직을 추가해야 되기 때문에 조금 복잡하고 힘들었다.
간단하게 주식 매수 api의 로직 중에 하나를 예시로 보자.
위에 로직을 보면 이미 존재하는 보유한 주식이라면 그것을 불러오고 존재하지 않는다면 포인트와 매수한 주의 개수가 0으로 초기화되어
있는 것을 확인할 수 있다. 사실 이거 간단한 게 저렇게 쓸 수 있는데 내가 바보같이 이상하게 쓰다가 저렇게 쓰면 되는 거 깨달음.
그리고 Receipt에 추가하는 로직을 보자면
이것은 Receipt에 추가하는 로직이다.
영수증에는 자신이 구매한 주식의 총 가격, 내가 매수한 것인지 매도한 것인지를 나타내기 위한 Enum과 주식의 이름 등을 추가하여 저장한다.
그리고 이제 예약 로직을 잠깐 보자면
이제 일반 매수와 다른 점이라면 Receipt와 OwnedStocks에 추가하는 것이 아닌 Reservation 테이블에 저장하는 것이다.
여기도 위에 주식 매수 로직의 Receipt에 저장하는 것과 비슷하게 저장하는 것을 볼 수 있다.
여기서 나오는 변수들은 내가 혼자 개발하느라 좀 이상하거나 말이 안 되는 거 일 수도 있다는 거 감안^^~
Reservation
여기도 Stock API 못지않게 힘들었던 파트이다.
여기서 고민해야 될 것이 존재했다.
여기 파트는 예약 중인 주식 리스트와 예약이 걸려있는 주식을 처리하는 스케줄러로 구성되어 있다.
그럼 예약 중인 주식을 처리하는 스케줄러의 로직에 관해 이야기해보자면
일단 모든 코드를 첨부해 보겠다.
여기 파일의 줄만 해도 100줄을 조금 넘긴다.
여기 로직에서 고민해야 될 것은
매수
매수과정의 로직을 작성할 때 내가 큰 실수를 한 것이 있었다.
이 프로젝트는 1초마다 주식이 바뀌는 것이 아닌 "10분"간격으로 변동이 생긴다.
그것을 생각하지 않고 코드를 작성할 때
if (reservation.getReservationPrice() == findReservationStock.getPresentPrice()) {
if (reservation.getStatus() == Status.BUY) {
processBuyingStock(reservation, findReservationStock);
} else if (reservation.getStatus() == Status.SELL) {
processSellingStock(reservation, findReservationStock);
}
}이런 식으로 작성한 것이었다.. 바보 같죠?
이렇게 봐서 이해가 안 될 수 있으니 설명하자면 예약을 걸어놓은 금액과 현재 금액이 일치해야 매도, 매수 프로세스가 진행되는 것이다.
이것이 왜 안되냐라고 한다면 10분은 코인만큼은 아니지만 주식에서도 매우 시간 간격이 크다고 볼 수 있다.
그럼 예시를 들자면
내가 3만 원에 매수 예약을 걸었다고 가정하자. 그러면 주식의 현재가가 5만 원이 되었다. 이 상황을 가정하고 위에 로직에 접근한다면
예약을 걸어놓은 금액과 현재가가 일치하지 않아 프로세스가 진행되지 않는다. 이러한 문제점을 거의 만들어지고 알았다는 사실!!!
이 문제를 깨닫고 바로 이슈를 파고 고쳤다는 이슈 중에 하나였습니다 ㅎㅎ
이것 말고는 딱히 어려운 점은 없었다.
User
여기에서는 모두 Get요청이라 어려운 게 없었지만 힘들었던 점을 하나 뽑자면 퍼센트 식이다.
여기서 말하는 퍼센트 식은
위에 사진을 보면 퍼센트가 존재한다. 저게 의미하는 것은 원래 가지고 있던 포인트에서 얻거나 잃었는지 계산하여 백분율로 나타낸 것이다.
저거의 계산식을 적용하는 것이 생각보다 힘들었다.
위에 보면 저기 선택되어 있는 곳이 가장 중요한 로직이다.
여기에서 사용한 식은
퍼센트 = 변화한 값 / 원래 보유하던 포인트 * 100
이렇게 하면 변동된 퍼센트를 구할 수 있다.
여기서 조금 힘들었던 것은 처음에 percent를 자료형을 Long을 사용하였다. 하지만 Long이 음수/ 양수를 하면 0으로 변한다는 것을 모르고 로직을 짰더니 갑자기 어느 날 0이 등장하였다.
난 아무것도 모르고 그냥 변동이 없나?라는 생각으로 나 두었는데 계속 0%이길래 테스트를 진행하였더니 Long에서 저런 상황이 나오면 0으로 변하는 것을 깨달았다. 그 후에 Double로 바꿔서 진행하였다는 사실..
Day
Day가 하는 일은 스케줄러와 그래프 그리기 위한 값 전달 api가 존재한다
이 스케줄러의 존재이유는 Stock의 테이블을 단지 파이썬 코드와 스프링과의 중간에서 데이터를 전달해 주는 역할 느낌으로 사용하기로 하였기 때문이다.
왜냐하면 Stock에 계속 저장한다고 하기에는 데이터가 제대로 들어온 지 잘 보이지 않았고 그냥 따로 관리하는 것이 나을 것 같다고 생각하여 Day라는 테이블을 구성하여 추가하였다. 먼가 지금 생각해 보면 굳이라는 생각이 들긴 함
저장할 때는 이런 식으로 언제 저장했는지 시간을 추가하여 클라이언트가 그래프를 나타낼 때 유용하게 추가하였다.
그리고 여기에 존재하는 값들은 하루의 값들을 이용하여 그래프를 그리는 등 하는 용도이기 때문에 한국 주식 본장 시간이 8시 ~ 15시 30분
이기 때문에 7시 59분에 모든 값을 초기화하는 스케줄러도 존재한다.
Receipt
마지막으로 Receipt는 매수, 매도 등 내역 등이 남아야 되는 것들을 담당하는 곳이다.
디자인을 보면 완료된 주문의 목록이 존재하는데 구매, 판매 등을 아까 위에서 보았던 Enum을 통해 구매인지 판매인지 구별하여 나타낸다.
모든 내역은 매월 첫날에 삭제되어 버린다. 날짜 계산해서 할 2개월 뒤에 이런 식으로는 할 수 있지만 기간 이슈..
느낀 점
이 프로젝트를 진행하면서 느낀 점은 매우 많고 아쉬운 점도 매우 많았다.
지금 생각해 보면 아 이것부터 제대로 해놓았더라면... 이것만 좀 더 생각했더라면이라는 감정이 많이 드는 프로젝트였다.
위에서 "Stock_code"로 바꾼 이유를 간략하게 설명하자면 파이썬에서 DB로 데이터를 저장할 때 사소한 이슈가 있었는데
그래서 식별자인 id를 지우고 "어차피 code도 고유한 코드인데 그냥 이걸 식별자로 하면 되는 거 아닌가?"라는 생각으로 수정했는데
나중에 해결하고 보니깐 그럴 필요가 없어서 어쩌다 보니 변경하기에는 좀 늦어서 code로 해도 상관없어서 그냥 나 두었다는 그런 이야기였습니다. ^^
정말 중요하게 생각이 드는 것은 기능 명세서, 변경사항 공지, 팀원들 간에 소통 등이 이것을 진행하면서 중요하게 느껴졌다.
이런 프로젝트를 학교에서 진행했다는 점과 다들 1 달이라는 짧으면 짧고 길면 긴 시간 동안 모두가 집중해서 프로젝트를 100%까지는 아니라도 포기하지 않고 계속해주어서 모두에게 의미 있는 프로젝트로 남았으면 좋을 것 같다!