BUILD LOG / 004

SwiTra를 만든 이유

대량의 데이터를 처리해 보고 싶다는 기술적 관심과 차트를 계속 지켜봐야 하는 불편이 만나 SwiTra가 시작됐다.

SwiTra를 만든 첫 번째 이유는 대량의 데이터를 직접 다뤄보고 싶었기 때문이다.

대량의 데이터를 다뤄보고 싶었다

일상적인 개발에서는 수십만 건 이상의 데이터가 지속해서 들어오는 환경을 접할 기회가 많지 않다. 시장 데이터라면 Kafka와 Flink 같은 스트림 처리 기술을 실제 문제에 적용해 볼 수 있다고 생각했다.

기술 자체를 시험하는 데서 끝내지 않고, 계속 운영할 수 있는 제품으로 만들어 보고 싶었다. 다만 이때까지는 어떤 제품을 만들 것인지 구체적으로 정해지지 않은 상태였다.

차트를 계속 지켜봐야 하는 불편

제품의 형태를 구체화한 계기는 주변 사람들과 나눈 대화였다.

원하는 조건이 나타나는 순간을 찾으려면 차트를 계속 확인해야 하지만, 현실적으로 화면을 계속 지켜보는 일은 쉽지 않다는 이야기를 들었다. 조건이 충족되는 순간을 자동으로 확인하고 알려줄 수 있다면 이 불편을 줄일 수 있을 것 같았다.

관련 서비스를 찾아보니 여러 기술적 지표를 조합해 알림을 받는 기능은 이미 존재했다. 다만 원하는 지표와 조건을 설정하는 과정은 쉽게 접근하기 어려워 보였다.

기술과 UI로 풀어볼 수 있는 문제

이 문제에는 서로 다른 두 가지 과제가 있었다.

하나는 지속해서 들어오는 시장 데이터를 처리하고, 사용자가 정한 조건이 충족됐는지 확인하는 기술적인 문제였다. 다른 하나는 RSI와 MACD 같은 지표를 AND와 OR 조건으로 조합하는 과정을 쉽게 만드는 UI 문제였다.

대량의 데이터를 처리해 보고 싶다는 기술적 관심과, 차트를 계속 지켜봐야 하는 불편이 이 지점에서 만났다. 기술과 UI를 함께 설계하면 직접 풀어볼 수 있는 문제라고 생각했고, 그렇게 SwiTra를 만들기 시작했다.

만들 수 있다는 것과 필요한 제품이라는 것

당시 확인한 것은 주변에서 들은 불편과 기존 서비스의 설정 방식이었다. 이것만으로 많은 사용자가 같은 문제를 겪고 있거나, SwiTra의 방식이 실제 해결책이 될 것이라고 단정할 수는 없었다.

SwiTra는 충분히 검증된 수요에서 시작한 제품이라기보다, 기술적으로 풀어보고 싶은 문제와 대화에서 발견한 불편을 바탕으로 먼저 만든 제품에 가깝다.

기술적으로 만들 수 있다는 것과 사용자가 계속 쓸 이유가 있는 제품이라는 것은 서로 다른 문제다. SwiTra는 첫 번째 질문에서 시작했고, 지금은 출시 후의 반응을 관찰하며 두 번째 질문을 확인하고 있다.

Build Log로 돌아가기 메인 허브로 돌아가기