코빗 기술 블로그

진짜 만들고 싶었던 건 명세서가 아니라 그 옆의 한 개 JSON 파일이었습니다. 매 PR 머지마다 갱신되는 1,852개 엔드포인트의 양방향 호출 그래프 — 단방향 정보만으로 시스템 토폴로지를 자동 구성하는 방법, 그리고 이 그래프가 장애 분석·배포 리스크·엔드포인트 폐기 결정을 어떻게 바꿨는지 2부에서 이야기합니다.

코드는 매일 바뀌는데, 문서는 어디쯤에서 멈춰 있을까요? 1,852개 엔드포인트를 운영하면서 7년 가까이 안고 있던 문제를, PR이 머지되면 명세까지 자동으로 따라오게 만들어 풀어 본 이야기입니다. 1부에서는 PR 60초 안에 시작되는 AI 코드리뷰와, 신규 엔드포인트가 5분 안에 명세로 따라붙는 자동화를 다룹니다.

페이스북은 ‘10일 내 친구 7명’, 슬랙은 ‘팀 내 메시지 2,000개’. 그렇다면 가상자산 거래소의 아하 모먼트는 무엇일까요? 코빗 데이터 팀이 약 10%에 머물던 코빗의 리텐션 플래토를 끌어올리기 위해 데이터에서 아하 모먼트를 찾아내고 신규 가입 보상 프로그램에 반영해 그 효과까지 검증한 이야기를 풀어 봅니다.

입금 처리는 AML 스크리닝, 자산 계류, 블록체인 컨펌까지 완료 시점을 예측할 수 없는 단계들이 이어집니다. 재시도와 상태 추적을 직접 구현하는 대신, 코빗 플랫폼 팀은 Temporal을 도입해 이를 안정적으로 풀어냈습니다. 입금 처리의 어떤 특성이 Temporal과 맞았는지, 도입 후 무엇이 달라졌는지를 소개합니다.

새벽 3시, 입출금 중단을 위해 알람을 맞춰 일어나본 적 있으신가요? 100% 수동이었던 운영 업무를 자동화한 Chronos 프로젝트를 소개합니다. Temporal을 사용해 개발자를 24시간 대기에서 해방시키고 안정적인 스케줄링과 동적 제어를 보장하기 위한 코빗 Blockchain Tech 팀의 고민과 아키텍처 설계 과정을 이야기합니다.

코빗은 기술 공유와 테크 브랜딩을 위해 2025년 9월, 기술 블로그를 개설했습니다. 그런데 잘 알려진 블로그 도구 대신 CTO가 직접 정적 사이트 생성기를 만들어 블로그를 구축했습니다. 왜 굳이 바퀴를 다시 발명하는 길을 택했는지 그 이유와 함께, Lighthouse 100점의 쾌적함과 가독성을 갖춘 블로그를 구현한 이야기를 공유합니다.

가상자산 시장은 쉼 없이 운영되며, 시장 급등락 상황에서는 평소 대비 몇 배의 트래픽 증가에도 안정성을 유지해야 하는 기술적 도전 과제를 안고 있습니다. 이 글에서는 코빗이 거래 시스템을 이벤트 기반 마이크로서비스 아키텍처를 바탕으로 재구축하면서 이러한 과제를 어떻게 극복했는지 소개합니다.

코빗은 본인인증 기반으로 로그인 과정을 개편하면서 1원 인증 단계에서의 불편을 줄이기 위한 작은 실험을 진행했습니다. 저희는 은행을 먼저 고르는 기존 방식을 버리고 계좌번호를 입력하면 은행을 추천하는 방식을 도입했는데, 이 글에서는 1년간의 데이터를 통해 어떤 효과가 있었는지 공유하려고 합니다.

Jetpack Compose는 선언형 UI를 구성하는 현대적인 Android 툴킷으로, UI 갱신을 Recomposition이라는 방식으로 처리합니다. 하지만 이 과정이 비효율적으로 처리되면 성능 저하를 일으킬 수 있습니다. 이 글에서는 Jetpack Compose에서 Recomposition을 효율적으로 관리하고 최적화한 경험을 실제 코드와 함께 소개합니다.

코빗의 새로운 거래 시스템은 Go와 Rust를 적극적으로 사용했습니다. 구체적으로는 주문 서비스와 Open API 서비스는 Go, 특히 거래소의 핵심이라고 할 수 있는 체결 엔진과 시세 정보 서비스는 Rust로 개발되었습니다. 코빗에서는 왜 Go와 Rust를 새로운 거래 시스템을 만드는 데 적극적으로 사용했는지, 그리고 어떻게 적재적소에 나누어 쓰는지를 공유하고자 합니다.