들어가는 말

꽃이 지기 전에도 알았지만 지고 난 후에는 더 뼈저리게 봄이었음을 느낀다.
내가 얼마나 편한 환경에서 프로젝트에 임했는지를 깨닫...는 것을 매주 갱신한다.
공통 프로젝트때 예비군 다녀올 동안 많은 일이 있었구나 싶다.
그때 예비군 가지 말고 프로젝트 초기 설정하는걸 보고 배웠어야 했는데..
진규는 군대가 밉다

이번주에는 프로젝트 초기 설정인 스키마와 API를 짜보았다.
솔직히 맞게 짜는건지도 모르겠고.. 정답을 알려줄 개발의 아버지가 없으니(실제론 계십니다 아빠미안) 혼란스럽다..
이것저것 꽉~ 짜면서 고민했던 것들을 정리해보았다.

---

지난 프로젝트에서 발전한 것

데이터베이스 스키마

문제

사실 이전 프로젝트에서는 기능들을 나열해두고 이 기능에서 필요한 것들을 정리해서 테이블을 만들었다.
기능이 말과 글로만 설명되어있었다보니, 초반엔 무엇이 필요한지 정확히 알지 못하고 약간 혼란스러워했던 것 같기도 하다(나만).

해결

이번에는 프론트에서 와이어프레임을 만들어주셔서 훨씬 수월하게 작업할 수 있었다~!

리빙포인트: 와이어프레임이란?
웹사이트의 골격(실제 서비스 화면)을 보기쉽게 그림으로 나타내고, 다이어그램으로 엮은 것!

우리 서비스의 각 화면에서 보여줄 컨텐츠들과 그 내용들을 명확히 정해놓으니, 서버에서 어떤 정보를 저장해야 하는지도 쉽게 알 수 있었다!

얻은 것

개발은 절대 혼자 하는게 아니다.
말과 글로만 설명된 서비스는 개발자의 상상력에 의존하고, 모두 다른 내용을 상상할 수 있다.(재앙)
명확히 정의된 기능과 화면이 있어야 같은 방향을 보고 진정한 협업을 할 수 있는 것 같다.

---

고민했던 것들

증권사 API의 유량제한

문제 1 - WebSocket

원래 사용하고자 했던 증권사 API는 한국투자증권에서 제공하는 API였다.
하지만 여기에는 치명적인 단점이 있었으니.. 바로 웹소켓 연결이 1세션만 제공되고, 41채널만 구독이 가능했던 것!!
그래서 우리는 5개의 계정으로 200개의 종목을 선별하여 서비스하기로 했다.

하 지 만
종목 별 상세 페이지를 위해서는 종목 당 2개의 채널 사용이 필요했다. 왜??
종목의 상세 정보 페이지에는 실시간 호가정보, 실시간 체결 정보가 필요하고, 이들은 각각 다른 채널에서 발행되는 메시지이므로 종목 당 2개의 채널 구독이 필요한 것..like
그럼 제공 종목이 100개로 확 줄어버린다.
이렇게 되면 모의투자의 의미가 사라질 것 같아 대안을 고민해보았다.

접근

유저가 상세정보를 조회하는 종목에 한해 동적으로 구독하는 방법을 생각했..으나 유저가 50개의 서로다른 종목을 구독하기만 하면 벌써 유량을 꽉 채워버린다.
또한 계속해서 채널 구독을 했다끊었다 다른걸했다그것도끊었다 이랬다저랬다 사랑을했다 던질까말까 하면 API 제공사 측에서 접근을 제한한다는 경험담도 있었다..

해결

그때! 난세에 등장한 영웅! 대 동 부
(DB그룹의 DB가 동부의 약자인걸 아신다면 옛사람)
DB증권의 API는 2세션, 세션당 50채널 구독이 가능한 것을 발견하게 되었더랬다.

그래서 우리는 200개 제한 종목을 제공하되, 실시간 정보(체결, 호가)는 안정적으로 계속해서 받아올 수 있게 되었다.

문제2 - REST API

"누구나 모의투자 API를 사용하려고 하지.. 유량제한에 쳐맞기 전까지는.."
증권사 API가 1초에 받는 주문 REST요청은 10건..
우리의 목표 유저는 200명..
유저의 10%만 주문을 해도 유량이 넘친다..
..비상!(flight X emergency O)

접근

이 주문 유량제한 사태는 아무리 해결사 갓동부여도 해결해주지 못했다..
그래서 일정 시간 간격으로 주문 정보를 모아서, 종목끼리 묶은 후 주문을 넣자! 라는 생각을 했으나..
서로 다른 10개 이상의 종목에 대해 주문이 들어오는 경우에는 의미없는 짓이 되어버린다.
심지어 체결이 1초 이상, 많게는 수 십초 까지 queueing될 수 있어서.. 매우 곤란한 상황에 빠져버렸다.

해결

그래서 어쩔 수 없이 우리의 역량 강화를 위해 직접 체결 엔진을 간단하게나마 만들기로 했다~ 오예~
이렇게 되면 모의투자 계좌당 액수 제한 있는 것도 신경쓰지 않고, 심지어 유저에게 시드를 더 많이 제공할 수 있다!
완전 일석이조 꿩먹고알먹기 도랑치고가재잡기잖슴~~~
체결의 경우, 우리 서비스는 부분체결 없이 해당 주문의 체결조건이 만족되면 즉시 전체 체결되도록 구현할 예정이다.

얻은 것

기획 단계에서 내가 사용하고자 하는 API에 대해 더 탐색해볼 필요가 있었다.
유량 제한을 미리 알았더라면, 진작 대안을 생각했을 것이고 시행착오를 줄일 수 있었을 것 같다.

체결 시스템 구현의 경우에도 생각해볼 것이 많다. 같은 종목에 대해 여러 주문이 들어왔을 때, 체결의 우선순위, 체결 여부 판별 등 로직을 빈틈없이 설계해야 할 것 같다.

메인페이지의 종목 순위 정렬

우리는 메인페이지에서 종목들의 순위를 제공하고 싶었다.
거래대금, 거래량, 급상승, 급하락 순으로 정렬된 정보를 실시간으로 업데이트하여 오늘의 투자정보를 주고 싶었달까?

문제

그런데 위 기준들(거래대금, 거래량, 급상승, 급하락)이 실시간으로 변동되는지라 이 차트 또한 실시간성을 유지해야했고, 변동 시마다 웹소켓을 통해 유저에게 순위정보를 그때그때 보내주어야 한다고 생각했다.
이미 종목별로 실시간 체결가를 받아오고 있으니, 변동이 생기면 그걸 반영하여 정렬하고 이벤트를 발생시키면 된다~! 너무 쉽잖아?
TreeSet은 자동으로 정렬도 해줘버려~~

여기서 잠깐!
순위가 변동될 때마다, 체결이 일어날 때마다 이벤트를 발생시킨다고?!?!
체결은 1초에 몇 십, 몇 백 건 이상 발생할텐데, 감당 가능해?

아뇨
너무 naive한 생각이었다..(나는 바보입니다)

접근

아니 그럼
우리의 우상 꿈 레퍼런스 토스증권은 이 문제를 어떻게 해결했지??
뜯어보니.. 토스증권도 일정 시간 간격으로 폴링해서 실시간 차트 정보를 받아오고 있었던 것..(토스야 날 속인거니)

"토스가 못한거면 우리도 못해"

하지만 여전히
실시간 정보 기반으로 정렬하는 것에 대한 문제는 해결하지 못한 상태였다.
이건 어떡하지..하는 찰나..
"안녕 친구들? 해결사가 왔어!"
"누구세요?"
누구긴 누구야 그저 빛 동 부

해결

그의 API에는 멀티 현재가 조회라는 API가 존재했고, 단 한 번의 요청으로 50개 종목의 현재가, 시가, 고가, 저가, 대비율을 알 수 있었다..
더불어 거래량과 대금은 기존 구독 중인 실시간 체결가를 통해 알 수 있기에 너무너무 행복해졌다!!

이제 이 정보들로 서버에서 시간 간격을 두고 정렬을 하고, rest로 요청이 들어오면 정렬되어있는 배열을 기반으로 응답하기로 극적 타결을 이룰 수 있었다.

생각한 것

서비스를 개발하는 데 있어 부족한 부분들을 상당 부분 API에 의존하여 해결한다는 점이 아쉽다.
애당초 우리가 기획한 서비스가 API 의존도가 너무 높은 것 같다.

다행히도, 체결 시스템은 직접 구현으로 바뀌었지만 핵심인 주가정보는 자체 구현할 수가 없기에 아쉬움으로 남는다..

---

맺는 말

스키마와 API는 최대한 수정이 필요없게끔 빈틈없이 설계하고 싶었는데 실제 개발 들어가고는 어떻게 될지 모르겠다.
블로그 작성하면서 느낀건데, 당장 이번 주의 고민들인데 벌써 왜, 어떤 방식을, 대안을 고민했었는지 가물가물했다.
개발 진행하다보면 다른 고민거리도 많이 생길 것 같은데.. 뭔가 생길 때마다 메모를 해놔야겠다.

오늘의 퀴즈
과학자는 빨래를 어떻게 짤까요
정답은
.
.
.
.
꽈학~ 짜