[개별 멘토링] 2024.11.07 이시은

이번주 문제 해결 경험

실시간 주가 지수 조회 기능 구현

이번 2주차에서 제가 맡았던 과제는 ‘주가 지수 관련 기능 만들기’ 였습니다. 실시간성이 중요한 기능이다 보니, 웹소켓 구현에 많은 시간을 투자했던 것 같습니다. 아래와 같은 디렉토리 구조로 구현을 진행했습니다.

실시간 주가 지수 차트 조회 기능

위와 같은 화면 구현에 필요한 차트 정보를 가져오기 위해서, 한국 투자 증권에서 제공하는 분단위 지수 API를 사용하기로 결정했습니다. 그러나 해당 API는 실시간 웹소켓 API가 아니었기 때문에, 여러 방법을 고민하다가 5분 단위로 서버→한투서버 API 요청을 보내 받아오는 방식으로 구현하기로 팀원들과 함께 결정했습니다. 아래와 같이 Cron 데코레이터를 활용해 반복적으로 조회해 주었습니다.

  @Cron('*/5 9-16 * * 1-5')
  async cronStockIndexLists() {
    const stockLists = await Promise.all([
      this.stockIndexService.getDomesticStockIndexListByCode('0001'), // 코스피
      this.stockIndexService.getDomesticStockIndexListByCode('1001'), // 코스닥
      this.stockIndexService.getDomesticStockIndexListByCode('2001'), // 코스피200
      this.stockIndexService.getDomesticStockIndexListByCode('3003'), // KSQ150
    ]);

    this.socketGateway.sendStockIndexListToClient(stockLists);
  }

socketGateway에서는 클라이언트↔서버 웹소켓 연결을 1세션으로 관리하도록 구현했습니다.

실시간 주가 지수 정보 조회 기능

위 코스피 화면 구현에 필요한 현재가, 변동률 등등을 가져오기 위해서, 한국 투자 증권에서 제공하는 실시간 웹소켓 API를 사용하기로 결정했습니다. 서버↔한투서버 웹소켓 연결은 최대 1세션으로 정해져 있었기 때문에, 모든 소켓 관련 로직들을 socket.service.ts에서 관리하도록 했습니다. 클라이언트↔서버 웹소켓 연결을 socket.io로 하고 있었기 때문에 서버↔한투서버 연결 또한 socket.io로 진행하고 싶었지만, 제대로 작동하지 않아 ws 모듈을 통해 연결을 구현했습니다.

fetch → axios

팀원들과 상의해 fetch API로 구현했던 외부 API 통신들을 axios로 바꾸자는 의견이 나왔습니다. 그러나, 알 수 없는 타입 에러와 axios 관련 문제가 발생했습니다. 처음에는 타입스크립트에서 적용해서 타입 에러가 나는 것인가 싶어서 해당 부분을 집중적으로 살펴보았지만 해결할 수 없었습니다. 저는 개발할 때 intellij를 주로 사용하는 편인데, intellij에서는 axios 부분에 빨간줄이 뜨는 오류가 발생하지만 vscode로 코드를 볼때는 아무 문제가 없다는 사실을 알게 되었습니다. 코드상에서는 문제가 없고, intellij 자체 설정 문제인 것 같아 빨간줄은 그대로 방치해두고 개발 중입니다. intellij에서 설정하는 방법을 찾아보고 적용해보아야겠습니다.

개별 멘토링 기록

Cron 관련 질문

위와 같은 화면 구현에 필요한 차트 정보를 가져오기 위해서, 한국 투자 증권에서 제공하는 분단위 지수 API를 사용하기로 결정했습니다. 그러나 해당 API는 실시간 웹소켓 API가 아니었기 때문에, 여러 방법을 고민하다가 5분 단위로 서버→한투서버 API 요청을 보내 받아오는 방식으로 구현하기로 팀원들과 함께 결정했습니다. 아래와 같이 Cron 데코레이터를 활용해 반복적으로 조회해 주었습니다.

위 부분에서 Cron을 활용해 5분마다 서버↔한투서버 통신이 여러 번(코스닥, 코스피, 코스피200, KSQ150 현재 총 4번) 발생하게 되는데, 서버에 부하가 많이 가게 될까 걱정입니다… Cron을 통한 반복 작업은 어느 정도 주기로 진행해야 서버에 지장이 가지 않을 정도가 될까요? Cron을 통해서 외부 API를 주기적으로 받아와도 되는 걸까요…?

! 멘토님 답변

• Cron 관련은 구현 일단 해보고 부하 심하면 그걸 해결하는 과정도 고민해보는 기회가 생기는 거니까 좋을 것 같다.
• 실제로도 스케줄러 많이 사용해서 괜찮다.
• 스케줄러 서버 분리할 수도 있을 것 같다.
• 스케줄러, API, 소켓 서버 나중에 분리하도록
• 소켓 세션 여러개 띄우면 안되는 이유 공부하면 좋을 것 같다.
• 한투서버에서 socket.io를 안써서 socket.io가 작동하지 않은 것 일수도 있다. 원인을 구체적으로 파악하는 것도 중요할 것 같다.
• 파이썬 라이브러리를 보고 변환한 과정 트러블슈팅으로 잘 녹여내면 좋을 것 같다.

Interface 관련 질문

fetch API를 통해서 외부 API에서 받아온 데이터를 가져올 때, 타입 추론이 되지 않아 API 하나하나 response interface를 설정해주었습니다. 해당 방식으로 진행하니 ESLint 규칙 등등은 모두 만족하지만, 외부 API response에 담긴 데이터가 너무 많아 interface가 불필요하게 길어진다고 생각했습니다. (예시는 아래에 있습니다.) 이렇게 외부 API 관련 interface를 관리하는 것이 맞을까요? 혹은 다른 좋은 방법이 있을까요…?

interface StockIndexValueInterface {
  output: {
    bstp_nmix_prpr: string;
    bstp_nmix_prdy_vrss: string;
    prdy_vrss_sign: string;
    bstp_nmix_prdy_ctrt: string;
    acml_vol: string;
    prdy_vol: string;
    acml_tr_pbmn: string;
    prdy_tr_pbmn: string;
    bstp_nmix_oprc: string;
    prdy_nmix_vrss_nmix_oprc: string;
    oprc_vrss_prpr_sign: string;
    bstp_nmix_oprc_prdy_ctrt: string;
    bstp_nmix_hgpr: string;
    prdy_nmix_vrss_nmix_hgpr: string;
    hgpr_vrss_prpr_sign: string;
    bstp_nmix_hgpr_prdy_ctrt: string;
    bstp_nmix_lwpr: string;
    prdy_clpr_vrss_lwpr: string;
    lwpr_vrss_prpr_sign: string;
    prdy_clpr_vrss_lwpr_rate: string;
    ascn_issu_cnt: string;
    uplm_issu_cnt: string;
    stnr_issu_cnt: string;
    down_issu_cnt: string;
    lslm_issu_cnt: string;
    dryy_bstp_nmix_hgpr: string;
    dryy_hgpr_vrss_prpr_rate: string;
    dryy_bstp_nmix_hgpr_date: string;
    dryy_bstp_nmix_lwpr: string;
    dryy_lwpr_vrss_prpr_rate: string;
    dryy_bstp_nmix_lwpr_date: string;
    total_askp_rsqn: string;
    total_bidp_rsqn: string;
    seln_rsqn_rate: string;
    shnu_rsqn_rate: string;
    ntby_rsqn: string;
  };
  rt_cd: string;
  msg_cd: string;
  msg1: string;
}

! 멘토님 답변

• 외부 API 타입 관련해서는 zod, yup 타입 검증 라이브러리 사용해서 외부 API 타입 검증할 수 있을 것 같다.
• 타입에 값이 없어도 에러는 안난다. 필요한 것만 선언해도 괜찮을 것 같다.
• 인터페이스 길어지는 문제는 문제 없고, 각 변수가 무엇인지 주석을 달아주면 좋을 것 같다.

멘토님께서는 fetch vs axios 무엇을 더 선호하시는지?

그냥 개인적으로 궁금합니다.

! 멘토님 답변

• fetch axios 관련해서는 바닐라 vs 리액트 느낌의 질문인 것 같다. 아무래도 axios가 더 편리.
• axios fetch로 직접 만들어보기도 재밌겠다.

추가 사항

• 에러 로그 관련해서 에러 나면 슬랙으로 쏠 수 있다. 그런거 만들어보면 좋을 것 같다.