2019년에도 못이루고, 2020년에도 못이뤘던 내 소망하나. 그건 바로 타입스크립트 배우기였다. 그리고 그 소망을 2021년에 드디어 이루어냈다. TypeScript를 배우면서 라이브러리 제작하기!

라이브러리 제작하기

yarn add @tradehelper/common

해당 라이브러리는 내 숙원사업중 하나였다. 지속적으로 거래소마다 파편화된 API 라이브러리를 내가 만든 어딘가에서 끌어와서 사용한다는것 자체가 상당히 스트레스였고, ccxt는 정리되지 않은 사용방법으로 머리를 아프게했다.

내 돈이 오가는데 남이 짠 라이브러리는 절대 못믿겠다는 일념하에 내가 직접 라이브러리를 짜기도 어연 대여섯개의 거래소가 넘어가면서 점점 직접 짠 라이브러리들의 버전관리조차 안될 지경에 이르렀다.

더이상 못참겠다라는 느낌으로 common library라는 이름으로 ECMAScript로 처음 시작한 프로젝트는, "아 타입스크립트 배워야지" 라는 일념 하나로 타입스크립트로 기반을 싹갈아엎고 프로젝트를 시작하게 되었다.

싹 갈아엎읍시다.

1월 23일에 시작해서 어느정도 수면위로는 3개월만에, 그리고 정식적인 공개는 8개월만에 드러났는데, 당연히 "온전히 프로그래밍에 100% 모든 역량을 쏟아부을 수 없는 상황 (opens new window)"이였기에, 정말 짬나는대로 틈틈히 코드를 구성하고 개발하기 시작했다.

해당 라이브러리는 어떤 문제를 해결하기 위해서 개발했는지 이야기해보고자 한다.

기존에 내가 겪고있던 문제점

• 개인적으로 사용할 프로그램들에서 너무 파편화된 호출형태로 골머리를 앓고있어서 통합할 수 있는 형태의 라이브러리가 필요했다.
• 고도화되어 작성된 API 라이브러리의 경우 한곳의 거래소만 지원하는 문제점이 있었다.
• 거래소마다 천차만별에 HTTP 스테이터스 코드마저 무시하는 경우로 인해 쉽게 구분할 수 없는 오류코드들을 한데 모아서 정리해야했다.
• 거래소들마다 노후화된 문서, 그리고 문서상에 지원하는 기능, 지원하지 않는 기능을 쉽게 파악할 수 없었다
  • 심지어 어떤 거래소는 POST요청에 form request 형태로 요청을 받는 거래소가 존재했다. 모든 요청을 form request로 감싸야된다..
• 숫자에 민감해질수밖에 없는 type check 문제
  • 예시를 들어보자. 7천만원짜리 비트코인을 '1' + 0.33 하여 10.33개 사는것과 1 + 0.33 해서 1.33개를 사는것은 다른 문제다.
• JSDoc을 지원하지않는 라이브러리들
  • JSDoc을 지원하지 않으면 적어도 에디터에서라도 힌팅이 지원되어야 하는데, 다들 그렇지 않더라. 문서를 보면서 지속적으로 어떤것이 어떤 용도로 쓰이는지 모르겠었다.
• 특정 상황에서 다중계정을 구성해야하는 문제
• 리스폰스 데이터가 거래소별로 명확하지 않은 문제
  • 특히 빗썸
• API서버에서 요청제한을 요청횟수 혹은 가중치 환산 형태로 진행하는 경우가 있는데, 이러한 요청제한을 현재의 API 라이브러리들의 클라이언트단에서는 관리하지 못했다.

이번 개발에서 내가 시도한것

다양한것들을 시도해보면서 배워봤다.

• 모노레포라는 형태를 처음으로 이용해보았다.
  • Yarn의 Workspace를 적극 활용하였다. 주로 테스팅할때 테스팅 항목들을 분리해서 테스트해보았다.
• 타입스크립트를 이용하여 처음 작성해보았다.
  • 기본적인 타입 검사부터 시작해서 타입 정의, 인터페이스, 추상 클래스, 유니온 형태의 타입정의, import / export 로 비롯되는 모듈 관리를 시도했다!
  • 이정도면 그래도 어디가서 타입스크립트 쓸줄안다 말할 수준은 되는것같다!
• eslint를 활용하여 타입스크립트의 엄격한 타입체크와 더불어 엄격한 코드 작성을 해보았다.
  • 딱히 만족스럽진 못했다. 아직도 코드를 보면 상당히 지저분하다라는 느낌이 먼저 드는 상태다.

결론적으로 성공한 프로젝트가 되었는가 물어보신다면 당연히 대답은 NO가 되었다. 너무 내가 감당할 수 있는 규모에 비해서 일을 크게 저지른것같기도 하고, 무엇보다 타입스크립트의 기본조차 안되어 있는 상황에서 너무 많은걸 시도하려고 한게 아닐까 싶을정도로 아쉬웠다.

이번 개발에서 아쉬운것

그렇게 100% 만족하지 못할 라이브러리로 개발되었음에는 틀림없다. 핵심 문제들은 해결했다고 생각하지만, 조금 더 세부적인 내용들에 있어서 완성도가 떨어짐을 자각하게 되었다.

• 작업을 위해 시간을 들이지 못한 점
  • 아직까지.. 먹고사는게 최우선 문제인 나에게 있어서는 코드보단 돈인가보다.
• 여전히 쪼개서 커밋하는 습관을 들이지 못한 점
  • 이게 협력해서 업무를 진행하게되면 최악의 습관인데 커밋을 어디부터 어디까지 쪼개서 작성해야되는지도 감이 안잡히는 문제점이 있었다
• 타입스크립트의 컴파일러 옵션중 하나인 strict가 false인점
  • 돈 들어가고 민감한 라이브러리인데 엄격하지 않으면.. 끔찍하다.
  • 사실 프로젝트 진행하면서 한번 true로 바꿔보았는데.. 에러가 40개 넘게 표시되는걸 보고 도저히 감당이 안되어서 false로 다시 바꾸었다.
  • 언제 한번 날잡아서 strict: true 에서도 오류가 없는 코드를 위해 다시한번 점검할 계획이다.
• 타입스크립트의 데코레이터(Decorator)를 한번도 활용하지 못한점
  • Request의 클래스가 현재 메서드 체이닝 형태로 되어있는걸 Decorator를 활용하면 메서드 체이닝을 사용하지 않아도 되는게 아니였나 생각된다.
  • 그외 믹스인, 네임스페이스같은 기능들도 사용해보지 않은점이 아쉽다. 어찌 이해해보고 코드에 적용해보면 적용할곳은 분명 존재하리라 생각하는데 이해하질 못한게 아쉬울 뿐이다.
• 차트(캔들스틱)를 위한 데이터를 불러올 수 없는점
  • 거래소별로 리퀘스트의 파편화가 가장 심한곳이 캔들스틱 관련 부분이였다. 이걸 통합한 결과로 표시하기에는 추가적인 시간이 더 필요하다고 생각하여 뒤로 미루어 둔 상태다.
• 일부 거래소의 지원하지 않는 메소드에 대한 대책을 세워놓지 않았다거나
• 에러 처리 과정이 너무 지저분하게 되어있어서 에러 표시 및 처리를 어디를 통해서 해야될지 모른다는것
  • 아예 오류처리용 클래스를 별도로 제작해야된다 생각했는데, 점점 오류 예외처리를 넣는다는 그 과정이 머리가 아파오기 시작했다.

결론

타입스크립트를 100% 활용하여 공부하고 개발해보진 않았지만, 타입스크립트를 그래도 "초보 수준으로라도 쓸수있는 레벨"이라고 할 수 있지 않나 싶다.

해당 라이브러리는 npm에서 npm install @tradehelper/common 명령어로 설치 가능하고, github에서는 저장소(https://github.com/tradehelper-pro/Common (opens new window))를 통해 확인 가능하다.

사용하면서 불편한점이 있거나, 고쳐야 되는 점들이 있다면 과감하게 이슈리포트 혹은 Pull Request를 넣어주셨으면 한다.

단순히 내 불편함을 고치기 위해, 그리고 타입스크립트를 배우기 위해 만든 라이브러리지만 모두가 참여하여 코드의 퀄리티가 올라갔으면 하는 바람이다 😁