이 방식에는 처음부터 안고 있던 문제가 있었습니다. 파일만 쌓아 두는 구조라서, 읽는 도중에 쓰기가 일어나거나 스키마가 바뀌면 고객이 어긋난 데이터를 볼 수 있었습니다. Delta Lake나 Iceberg 같은 Open Table Format이 풀려는 바로 그 문제입니다.

고객이 늘면서는 다른 문제가 커졌습니다. AWS를 직접 쓰는 고객도 있었지만 BigQuery, Databricks, Snowflake를 쓰는 고객도 꽤 있었고, 데이터 자산의 규모가 크다 보니 플랫폼이 늘 때마다 복제본을 하나씩 더 둘 수는 없었습니다. 그래서, Open Table Format으로 옮기면서 같은 사본을 여러 플랫폼에서 읽을 수 있게 하는 방법이 필요했습니다. 데이터를 소비하는 쪽이 회사 내부가 아닌 외부 고객이다 보니, 테이블 포맷을 고르는 일이 곧 고객 플랫폼과의 호환성을 고르는 일이기도 했습니다.

이 글에서는 S3 Parquet과 BigQuery로 이중 운영하던 구조를 Delta Lake 한 벌로 합치고, Delta Sharing과 UniForm으로 네 가지 플랫폼의 고객에게 제공한 과정을 살펴보겠습니다. 각 플랫폼 기능의 동작은 2026년 10월 기준 공식 문서를 함께 참고했습니다. 운영하던 시기와 세부 동작이 다를 수 있다는 점을 미리 밝혀 둡니다.

기존 구조와 문제

파일 직접 제공의 한계

파일을 그대로 넘기는 방식에는 세 가지 문제가 있었습니다.

• schema evolution: 스키마를 기록해 두는 곳이 없어서, 읽는 쪽이 파일마다 스키마를 추론해야 했습니다. 컬럼을 추가하면 예전 파일과 새 파일의 스키마가 달라지고, 엔진마다 이를 합치는 방식이 달라 고객 쪽에서 컬럼이 보이지 않을 수 있었습니다.
• 트랜잭션 부재: 고객이 파일을 읽는 도중 같은 경로에 쓰기가 일어나면, 일부만 바뀐 상태를 읽을 수 있었습니다.
• 이중 보관: S3와 BigQuery에 같은 데이터가 두 벌 있었습니다.

앞의 두 문제는 테이블 포맷을 도입하면 풀립니다. Iceberg나 Delta Lake 같은 테이블 포맷은 스키마와 파일 목록을 메타데이터로 관리하고, 커밋 단위로 원자적인 쓰기를 보장하기 때문입니다. 하지만, 당시 테이블 포맷이나 데이터 처리 엔진을 선택하는 데는 다음과 같은 다른 문제가 있었습니다.

기관 고객 플랫폼의 다양성

기관, 특히 금융권 기관 고객들은 Databricks, BigQuery, Snowflake와 같은 SaaS 형태의 클라우드 데이터 플랫폼을 쓰는 경우가 많았습니다. 그래서, 테이블 포맷을 고른다는 것은 기술적인 점만 고려하는 것이 아닌, 고객의 읽기 편의성도 생각해야 했습니다.

모든 고객이 각자 플랫폼에서 편하게 가져가면서, 데이터의 중복 저장을 최대한 줄이는 것이 필요한 상황이었습니다.

대안 검토

Iceberg

업계에서 오픈소스이면서 엔진 중립적인 테이블 포맷의 주류는 Iceberg였습니다. 다행인 것은 위 SaaS 플랫폼들이 자체적으로 최적화된 managed storage(native table)를 넘어 오픈 테이블 포맷을 지원하는 추세였다는 점입니다. Snowflake와 BigQuery, Databricks의 Spark Engine 모두 Iceberg 외부 테이블에 대한 읽기를 지원하므로, 처음에는 Glue 카탈로그에 Iceberg 테이블을 두고 EMR Spark로 쓰는 구성을 유력하게 봤습니다.

그런데 검토할수록 걸리는 점이 있었습니다. 첫째, 원본을 Iceberg로 두면 Databricks를 쓰는 고객에게 Delta 테이블로 제공할 수 없었습니다. Iceberg 테이블은 Spark로 쓰고 읽을 수 있지만, Databricks 고객이 자기 워크스페이스에서 Delta 테이블로 받아 가는 편의는 원본이 Delta일 때만 줄 수 있었습니다. 반면, Delta Lake로 쓴 테이블은 UniForm으로 Iceberg 메타데이터를 함께 만들 수 있어서, Iceberg 클라이언트에서도 읽을 수 있었습니다. 당시에는 그 반대 방향, 곧 Iceberg 테이블을 Delta로도 읽히게 하는 방법이 없었습니다.¹ 둘째, 적은 데이터 엔지니어로 EMR Spark를 운영하는 비용이나 학습하는 비용이 Databricks에 비해 훨씬 높다는 점이었습니다. 분석가가 많은 회사 특성상, Databricks Notebook의 압도적인 사용성은 매력적이었고 job compute mode, warm-up 등을 잘 사용하면 EMR보다 비싸지도 않았기 때문입니다.

Delta Lake와 UniForm

그래서 결론적으로는, Databricks 플랫폼을 사용하는 것으로 결정을 했습니다. Databricks의 Delta UniForm은 Delta 테이블을 쓸 때 Iceberg 메타데이터를 함께 만들어 줍니다. 용량의 대부분을 차지하는 데이터 파일(Parquet)은 한 벌이지만, Delta로도 읽히고 Iceberg로도 읽히는 것이 가능합니다.

고객은 읽기만 하고 쓰기는 내부 파이프라인에서만 일어나므로, Iceberg 쓰기를 포기하는 비용은 작았습니다. 또한, Databricks 고객에게는 플랫폼 내부에서 Delta Sharing을 통해 데이터를 쉽게 제공하는 것이 가능했습니다.

구조

실시간 데이터는 앞단의 Database에 실시간으로 적재되고, 이를 분석 목적으로 활용하기 위해 CDC로 데이터를 적재합니다. 그리고, 각각의 도메인에 맞게 정의된 Spark Job들이 Unity Catalog에 등록된 Delta 테이블에 데이터를 적재합니다(INSERT + UPSERT). 블록체인 데이터 특성상 UPSERT는 sliding window처럼 최근 n개 구간의 데이터만 고쳤고, 테이블이 클러스터링되어 있어서 테이블 전체를 다시 쓰는 일은 없었습니다.

• Delta Sharing: Databricks를 쓰는 고객에게 Delta 테이블을 그대로 공유합니다. 권한은 Databricks의 거버넌스 기능으로 관리했습니다.
• UniForm + Iceberg REST Catalog: AWS를 직접 쓰거나 Snowflake를 쓰는 고객은 Unity Catalog가 제공하는 Iceberg REST Catalog를 이용해 플랫폼에서 Iceberg 테이블을 읽습니다. BigQuery를 쓰는 고객은 BigQuery Omni로 Iceberg 테이블을 읽습니다.

UniForm 설정

UniForm은 Delta 테이블의 TBLPROPERTIES로 켤 수 있습니다. 테이블은 Unity Catalog에 등록되어 있어야 하고, Databricks Runtime 14.3 LTS 이상이어야 합니다.

CREATE TABLE market.history.exchange_flows (
  asset STRING,
  exchange STRING,
  ts TIMESTAMP,
  value DOUBLE
)
TBLPROPERTIES (
  'delta.columnMapping.mode' = 'id',
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg'
);

UniForm은 column mapping이 켜진 테이블에서만 동작합니다. 새 테이블은 만들 때 UniForm을 켜면 column mapping도 함께 켜지고, Databricks는 호환성을 위해 위 예시처럼 id 모드를 권장합니다. 이미 있는 테이블에 켤 때는 Databricks Runtime 15.4 LTS 이상에서 column mapping을 name 모드로 함께 설정합니다 (Databricks, 2026).

ALTER TABLE market.history.exchange_flows SET TBLPROPERTIES (
  'delta.columnMapping.mode' = 'name',
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg'
);

받아들인 제약

읽기 전용 Iceberg

UniForm을 켠 Delta 테이블은 Iceberg 클라이언트에서 읽기만 할 수 있습니다. 고객이 데이터를 쓸 일은 없었기 때문에 문제가 되지 않았습니다.

신선도 지연

Delta Sharing 고객은 커밋이 끝나면 바로 새 데이터를 관찰할 수 있습니다. 하지만, Iceberg로 읽는 고객이 새 데이터를 보기까지는 지연이 두 번 생깁니다.

첫 번째로 지연이 발생하는 지점은 UniForm 변환입니다. Iceberg 메타데이터는 Delta 커밋을 마친 compute가 커밋 뒤에 비동기로 생성합니다. 한 compute에서 변환 작업이 한 번에 하나만 돌기 때문에, 메타데이터 변환 중에 들어온 커밋은 다음 변환에서야 묶여 반영됩니다. 따라서, Delta 버전과 Iceberg 스냅샷이 하나씩 대응한다는 보장도 없습니다 (Databricks, 2026).

두 번째는 소비처에서의 카탈로그 갱신 방식입니다. Spark처럼 Iceberg REST Catalog에 직접 붙는 클라이언트는 테이블을 열 때 카탈로그에서 최신 메타데이터 위치를 받아 갑니다. 다만, Iceberg의 Spark catalog는 불러온 테이블을 기본 30초 동안 캐시하므로, 한 세션 안에서는 새 스냅샷이 그만큼 늦게 보일 수 있습니다 (Apache Iceberg, 2026). 반면, Snowflake와 BigQuery는 테이블 정의를 자기 쪽에 등록해 두기 때문에 메타데이터를 다시 읽어야 새 스냅샷이 보입니다. Snowflake는 테이블을 만들 때 AUTO_REFRESH를 켜 두면 카탈로그를 기본 30초 간격으로 확인합니다. 이 옵션은 기본값이 꺼져 있어서, 켜지 않은 테이블은 ALTER ICEBERG TABLE ... REFRESH로 직접 갱신해야 합니다 (Snowflake, 2026c, 2026b, 2026a). BigQuery는 BigQuery Omni에서 S3의 Iceberg 테이블을 BigLake 테이블로 등록해 읽었습니다 (Google Cloud, 2026). 이렇게 등록한 테이블은 정의가 특정 metadata.json 파일을 가리키기 때문에, 새 스냅샷이 생겨도 이 경로를 바꿔 주기 전까지는 이전 스냅샷을 읽습니다 (Google Cloud, 2026b). 그래서, 최신 metadata.json 경로를 주기적으로 찾아 BigQuery의 테이블 정의에 반영하는 작업을 따로 돌렸고, BigQuery를 통해 데이터를 조회하는 경우 이 주기만큼 데이터가 늦게 보이게 됩니다.²

데이터 레이크를 통해 제공하는 데이터를 소비하는 고객이 원한 것은 실시간성보다는 히스토리 데이터를 백필하는 것이었기 때문에 이 지연은 감내할 수 있었습니다. 변환이 밀렸을 때는 동기적으로 작동하는 MSCK REPAIR TABLE <table> SYNC METADATA로 수동 변환을 걸 수 있습니다.

Databricks 의존성

쓰기와 데이터 거버넌스가 모두 Databricks(Unity Catalog)에 묶입니다. 플랫폼의 사용성이 뛰어나다고 판단하기도 했고, EMR을 직접 운영하는 부담을 줄이는 대가로 받아들인 의존성입니다.

결과

• 수백 개의 테이블을 Delta Lake로 합쳤고, S3와 BigQuery에 이중으로 보관하던 수백 TB의 데이터를 줄일 수 있게 되었습니다.
• 쓰기 트랜잭션, 스키마 변경 등을 추상화된 테이블 포맷 인터페이스(SQL)를 통해 간편하게 Spark SQL로 수행할 수 있게 되었습니다.
• Snowflake와 BigQuery를 쓰는 고객이 자기 플랫폼에서 직접 데이터를 연결할 수 있게 되어, API 외의 데이터 판매 채널이 생겼습니다.

복기

Unity Catalog 기반의 거버넌스 관리, 데이터 중복 제거 등 만족스러운 점은 많았지만 기관 고객들이 중요하게 생각할 데이터 품질 지표인 SLA(Service Level Agreement) 세팅이나, 이를 관리하기 위한 데이터 품질 관리 플랫폼을 동시에 붙이지 못했던 점은 아쉬운 점입니다. 당시 DataHub를 구축하는 것을 계획하고 있었는데, Unity Catalog에도 품질이나 리니지 관련 기능이 꾸준히 추가가 되고 있어 앞으로는 이 기능으로도 충분하지 않을까 하는 생각이 들긴 했습니다.

참고문헌

• Apache Iceberg. (2026). Spark configuration. https://iceberg.apache.org/docs/latest/spark-configuration/
• Databricks. (n.d.). What is Apache Iceberg in Databricks? Retrieved October 22, 2026, from https://docs.databricks.com/aws/iceberg
• Databricks. (2026a). Access Databricks data using external systems. https://docs.databricks.com/aws/en/external-access/
• Databricks. (2026b). Read Delta Lake tables with Iceberg clients. https://docs.databricks.com/aws/en/delta/uniform
• Databricks. (2026c). Unity Catalog credential vending for external system access. https://docs.databricks.com/aws/en/external-access/credential-vending
• Google Cloud. (2026a). About cross-cloud data access. https://docs.cloud.google.com/lakehouse/docs/about-cross-cloud-data-access
• Google Cloud. (2026b). Create Amazon S3 BigLake tables. https://docs.cloud.google.com/bigquery/docs/omni-aws-create-external-table
• Google Cloud. (2026c). Create Apache Iceberg external tables. https://docs.cloud.google.com/bigquery/docs/iceberg-external-tables
• Microsoft. (2026). Access Azure Databricks tables from Apache Iceberg clients. https://learn.microsoft.com/en-us/azure/databricks/external-access/iceberg
• Snowflake. (2026a). ALTER ICEBERG TABLE … REFRESH. https://docs.snowflake.com/en/sql-reference/sql/alter-iceberg-table-refresh
• Snowflake. (2026b). Automatically refresh Apache Iceberg tables. https://docs.snowflake.com/en/user-guide/tables-iceberg-auto-refresh
• Snowflake. (2026c). CREATE ICEBERG TABLE (Iceberg REST catalog). https://docs.snowflake.com/en/sql-reference/sql/create-iceberg-table-rest

QTG 개발 배경

송금 추적 표준화 부재

CCXT 같은 거래소 연동 라이브러리에서는 출금 요청과 조회가 표준화되어 있습니다. 예를 들어, CCXT에는 withdraw, fetchDepositAddress, fetchDeposits, fetchWithdrawals와 같은 통합 메서드가 있습니다. fetchWithdrawals는 출금 내역을 조회하는 메서드로, 거래소마다 다른 상태 값을 pending, ok, failed, canceled 네 가지로 바꿔 돌려줍니다.

하지만, CCXT는 조회 한 번의 응답만 표준화합니다. 출금이 끝날 때까지 언제 다시 조회할지, 출발 거래소의 txid를 도착 거래소의 입금 내역에서 어떻게 찾을지, 응답이 끊겼을 때 출금이 나갔는지 어떻게 확인할지는 사용자가 직접 정해야 합니다.

거래소 간 송금 한 건은 대략 다음 순서로 진행됩니다.

출금 API는 1번 단계에서 응답을 돌려줍니다. 2번부터 5번까지의 상태는 사용자가 직접 추적해야 합니다. 거래소마다 차이가 가장 큰 것도 이 구간입니다. 출금 상태를 나타내는 문자열이 거래소마다 다르고, 문서에 없는 값이 내려오기도 합니다. CCXT의 변환도 완전하지는 않습니다. CCXT 4.5.88의 Upbit 구현은 출금 상태 accepted를 ok로 바꾸는데, QTG는 같은 값을 아직 처리 중으로 봅니다. 변환 표에 없는 waiting 같은 값은 원본 문자열 그대로 내려옵니다. 트래블룰 때문에 출금 주소를 미리 등록해야 하는 거래소도 있고, 출금 주소 화이트리스트를 따로 관리해야 하는 거래소도 있습니다.

브릿지를 거치면 단계가 더 늘어납니다. Circle의 CCTP로 USDC를 다른 체인에 보내려면, 출발 체인에서 USDC를 burn하고 Circle의 attestation을 받은 뒤 도착 체인에서 mint해야 합니다. burn할 때 지정한 destination_caller와 실제로 mint를 호출하는 주소가 다르면 mint가 실패하고, 이미 burn된 USDC는 어느 체인에서도 되찾을 수 없습니다.

송금 수단마다 실패하는 방식도 다릅니다.

물론, 이 과정을 대신 처리해 주는 서비스도 있습니다. 기관용 커스터디 솔루션은 거래소 간 이체와 승인 정책을 함께 제공합니다. 하지만, 기관을 대상으로 한 서비스여서 개인이 쓰기에는 비용 부담이 컸습니다. 개인 트레이더나 에이전트 트레이딩을 해 보려는 사람, 작은 퀀트 팀은 직접 짠 스크립트와 기관용 솔루션 사이에서 마땅한 선택지를 찾기 어려웠습니다. 이런 사람들을 타겟해 QTG를 개발했습니다.

QTG는 셀프 호스트 방식이기 때문에 키를 대신 보관하지 않습니다. 키는 사용자의 KMS나 암호화된 keystore에 두고, 어떤 이체를 어디로 누구의 승인으로 허용할지 정하는 통제만 기관용 솔루션 수준으로 가져가려 했습니다.

QTG는 출금 요청부터 입금 확인까지의 과정 전체를 표준화합니다. 거래소와 브릿지마다 다른 부분은 각 단계의 구현 안에 숨기고, 밖에서는 같은 상태와 같은 이벤트로 보이게 했습니다.

예를 들어, CEX 출금 상태는 일곱 가지로 통일했습니다. 거래소 어댑터는 모두 같은 메서드를 구현하고, 거래소에서 받은 원본 값을 이 상태로 바꿔 돌려줍니다. 아래 코드는 이해를 돕기 위해 일부 메서드와 인자를 생략한 것입니다.

class WithdrawalState(StrEnum):
    SUBMITTED = "SUBMITTED"
    PROCESSING = "PROCESSING"
    WAITING_CONFIRMATION = "WAITING_CONFIRMATION"
    COMPLETED = "COMPLETED"
    CANCELLED = "CANCELLED"
    REJECTED = "REJECTED"
    FAILED = "FAILED"
 
 
class TransferAdapterBase(ABC):
    # 지금 이 자산과 네트워크로 출금할 수 있는지 확인
    async def check_withdrawal_available(self, asset, network) -> WithdrawalChance: ...
    async def submit_withdrawal(self, request) -> WithdrawalResult: ...
    # 원본 상태를 WithdrawalState로 바꾸고 txid, confirmation 수와 함께 돌려줌
    async def get_withdrawal_status(self, withdrawal_id) -> WithdrawalStatus: ...
    async def get_deposit_status(self, deposit_id) -> DepositStatus: ...

거래소별 원본 값은 다음과 같이 바뀝니다.

Upbit 어댑터는 표에 없는 값이 내려오면 경고 로그를 남기고 PROCESSING으로 둡니다. 완료로 잘못 판단하면 도착 거래소의 입금 확인이 너무 일찍 시작되지만, 처리 중으로 두면 조회를 한 번 더 할 뿐이기 때문입니다. 송금 요청과 노드 단위의 상태는 뒤의 승인과 결과를 알 수 없는 상태 절에서 다룹니다.

개인키 관리 부담

CEX 출금은 거래소 API 키만 있으면 가능하지만, Circle의 CCTP처럼 블록체인에 직접 트랜잭션을 보내려면 개인키 서명이 필요합니다. 대부분, 초기 테스트 단계에서는 서버의 .env 파일에 개인키를 두고 프로세스가 읽어 쓰게 합니다.

하지만, AI의 발달로 공격 시나리오도 상당히 정교해지면서, 로컬 머신에 개인키를 평문으로 두는 방식의 문제가 점점 커지기 시작했습니다. 2025년 8월 npm에 올라온 Nx 빌드 도구의 악성 버전(s1ngularity 공격)이 대표적인 사례입니다. 이 악성 코드는 개발자 PC에 설치된 Claude, Gemini, Amazon Q의 CLI를 실행해 파일 시스템에서 암호화폐 지갑, .env 파일, SSH 키, GitHub 토큰을 찾게 했습니다. Wiz의 집계에 따르면 GitHub 계정 2,180개와 저장소 7,200개가 노출되었습니다.

그 뒤로도 비슷한 공격이 이어졌습니다.

Shai-Hulud 2.0은 탈취한 maintainer 계정으로 감염된 패키지를 다시 배포하며 스스로 퍼졌고, 훔친 secret을 공개 GitHub 저장소에 올렸습니다. Injective 사례에서는 공격자가 SDK의 GitHub 저장소를 장악해, 정식 배포 파이프라인으로 18개 패키지에 악성 버전을 올렸습니다. 이 코드는 키 유도 함수 안에 숨어 있어서 설치할 때는 아무 일도 하지 않았고, 애플리케이션이 지갑 키를 만들 때 개인키와 시드 문구를 외부로 보냈습니다. 키를 다루는 코드 자체가 오염되면 키를 어디에 보관하든 소용이 없다는 뜻입니다.

코딩 에이전트가 .env를 읽는 것은 hook 같은 설정으로 어느 정도 막을 수 있습니다. 하지만, 의존성 공급망 공격은 개발자가 설치한 패키지 안에서 실행되고, 로컬 파일 시스템을 훑어 secret을 찾아내는 수법도 갈수록 정교해지고 있습니다. 개인키를 평문 파일로 디스크에 두는 한 이런 공격을 피하기 어렵다고 판단했습니다.

디스크에 평문을 남기지 않는 방법도 있습니다. 1Password CLI(op run, op read)를 쓰면 키를 vault에 두고, 프로세스가 시작될 때만 환경 변수로 주입받을 수 있습니다. 이렇게 하면 로컬 파일을 훑는 공격은 막을 수 있습니다. 하지만, 키가 프로세스 메모리에 올라온 뒤에는 같은 머신에서 실행되는 코드가 키를 읽어 갈 수 있습니다. 메모리 덤프나 /proc/<pid>/environ 조회가 그 예이고, Injective 사례처럼 의존성 안에서 실행되는 코드는 키를 쓰는 순간에 가로챌 수 있습니다. 그래서, 키는 별도 vault에 두고 애플리케이션은 서명 결과만 받아 쓰는 방식이 가장 안전하다고 판단했습니다.

QTG는 기본적으로 EVM 서명을 AWS KMS에 맡깁니다. 개인키는 KMS의 HSM 안에서 생성되고, 밖으로 나오지 않습니다. QTG의 서명 서비스는 키 ID만 가지고 있다가, 서명이 필요할 때마다 KMS API를 호출합니다. 모든 서명 요청은 CloudTrail에 기록되고, IAM 권한을 회수하면 곧바로 서명이 막힙니다. 또, secp256k1 키 하나로 여러 EVM 체인에서 같은 주소를 쓸 수 있어서 체인별로 키를 따로 관리하지 않아도 됩니다.

서명 방식에 따라 공격 시나리오별 위험은 다음과 같이 달라집니다.

KMS는 키 자체를 지켜 주지만, 서명 권한까지 지켜 주지는 않습니다. 표의 마지막 두 줄처럼 공격자가 접근을 유지하는 동안에는 서명을 요청할 수 있습니다. 다만, 그 요청은 모두 CloudTrail에 남고, IAM 권한을 회수하면 그 자리에서 끝납니다. 키가 통째로 유출되는 것보다는 훨씬 나은 위치이지만, 완전한 방어는 아닙니다.

암호화 keystore는 AWS를 쓰지 않는 로컬 배포를 위해 나중에 추가한 방식입니다. 디스크에는 암호화된 파일만 남아서 passphrase를 모르면 쓸 수 없지만, 서명 서비스가 잠금을 푼 동안에는 그 프로세스의 메모리에 키가 있습니다. 같은 호스트의 root나 Docker 관리자 권한을 가진 공격자는 이 메모리를 읽을 수 있고, CloudTrail 같은 외부 서명 기록이나 IAM 권한 회수 같은 수단도 없습니다. 그래서, 원격 서버나 여러 사람이 함께 쓰는 호스트에는 KMS를 권장합니다. 동작 방식은 뒤의 서명 서비스 분리에서 다룹니다.

서명 키 말고도 QTG가 다루는 secret이 있습니다. 각각이 유출됐을 때 공격자가 할 수 있는 일은 다음과 같습니다.

* 거래소마다 지원 범위가 다릅니다. API 키에 IP 제한을 걸 수 있는지, 출금 주소 화이트리스트를 강제할 수 있는지는 거래소별로 확인해야 합니다.

이 secret들을 QTG에 전달하는 방식도 바꾸었습니다. 처음에는 다른 설정과 함께 .env나 환경 변수로 받았습니다. 하지만, 환경 변수는 자식 프로세스에 그대로 복사되고, docker inspect나 /proc/<pid>/environ으로도 읽힙니다. 그래서, DB 접속 정보, HMAC secret, 알림 봇 토큰 같은 런타임 secret은 권한이 0600인 파일로만 받게 했습니다. 환경 변수나 .env에 secret 값이 남아 있으면 QTG는 아예 시작하지 않습니다. 다만, 파일도 디스크에 평문으로 있다는 점은 같아서, secret manager를 대신하지는 않습니다.

DB 쓰기 권한이 넘어가면 QTG 안의 통제는 모두 무력해집니다. 거래소 API 키는 DB에 레코드별로 암호화해 저장하고, 암호화 키(KEK)는 배포 모드에 따라 로컬 파일이나 AWS KMS가 맡습니다. DB 덤프만으로는 거래소 키를 읽을 수 없습니다. 하지만, 요청마다 서명해야 하기 때문에 실행 중인 프로세스 메모리에는 평문으로 있을 수밖에 없습니다. 다만, 대부분의 거래소는 보안상 IP 화이트리스트나 출금 주소 화이트리스트를 API로 추가할 수 없게 해 두었습니다. 거래소 웹이나 앱에서 직접 등록해야 합니다. 그래서, 이 두 가지를 미리 설정해 두면, 거래소 API 키가 유출되더라도 등록하지 않은 주소로 자산이 빠져나가는 치명적인 사고로 이어지지는 않습니다. 서버가 완전히 장악된 뒤에도 작동하는 통제는 QTG 밖에 있습니다. 거래소의 IP 제한과 출금 주소 화이트리스트, 그리고 KMS 키 정책입니다. 그래서, QTG를 어디에 어떻게 배포하느냐가 설정 하나보다 더 중요한데, 이 내용은 뒤의 배포 구성과 보안 수준에서 다룹니다.

송금 과정 추상화 필요성

세 번째 이유는 송금 경로가 길어졌기 때문입니다. 거래소에서 출금해 온체인 지갑으로 받고, 브릿지로 다른 체인에 옮긴 다음, 다시 거래소나 DEX에 입금하는 식입니다. 단계마다 확인해야 할 것도 있습니다. 출금이 나갔는지, 체인에 기록됐는지, confirmation이 충분히 쌓였는지, 도착지에 반영됐는지 같은 것들입니다.

이런 확인 작업은 송금 수단이 달라도 성격이 비슷합니다. 외부에 무언가를 제출하고, 그 결과가 외부 시스템에 나타나기를 기다리는 것입니다. 그래서, 송금 한 건을 단계별 노드로 이루어진 DAG로 표현하고, 확인 작업을 몇 가지 유형으로 묶었습니다. 이렇게 하면 경로가 바뀌어도 그래프 모양만 바꾸면 되고, 노드의 동작은 다시 짤 필요가 없습니다.

QTG 구조

QTG Core는 다음과 같이 구성됩니다.

• 요청 API: 전략, 에이전트, 대시보드는 HMAC 서명으로 인증한 뒤 송금 요청을 보냅니다.
• Plan compiler: 경로 템플릿과 입력값으로 노드 그래프를 만들고, 그 내용을 해시로 고정합니다.
• 승인: owner가 직접 승인하거나, 조건에 맞는 요청은 auto-approve 정책에 따라 승인됩니다.
• Worker: Postgres를 주기적으로 조회해 실행할 노드를 가져가고, executor를 호출합니다.
• Executor: 거래소 API나 체인과 실제로 통신하며, CEX Lane과 Bridge Lane으로 나뉩니다.
• Callback outbox: 상태가 바뀔 때마다 요청한 쪽에 서명된 콜백을 보냅니다.

EVM 서명은 Core 밖의 서명 서비스가 처리합니다. 모든 상태는 Postgres 한 곳에 저장하며, 메시지 브로커나 별도 스케줄러 프로세스는 두지 않았습니다. 이 결정은 뒤의 Airflow 구조를 참고한 스케줄링에서 다시 설명합니다.

송금 그래프와 Executor

CEX 간 송금은 노드 3개로 이루어집니다. 출금을 요청하고, 출금 상태를 확인해 txid를 얻고, 도착 거래소의 입금 내역에서 그 txid를 찾습니다.

CCTP 송금은 노드 5개로 이루어집니다. burn, attestation, mint 뒤에 받은 금액을 확인하는 노드와 finality를 확인하는 노드가 붙습니다.

각 노드는 executor가 처리합니다. Executor는 송금 수단에 관계없이 같은 메서드를 구현합니다. 아래 코드는 이해를 돕기 위해 인자를 줄인 것입니다.

class ExecutorProtocol(Protocol):
    async def preflight(self, ctx) -> ExecutionResult | None: ...  # 실행 전 점검
    async def prepare(self, ctx) -> ExecutionResult: ...           # 제출할 내용 준비
    async def submit(self, ctx, prepared_action) -> ExecutionResult: ...  # 외부에 제출
    async def observe(self, ctx) -> ExecutionResult: ...           # 결과 확인
    async def recover(self, ctx) -> ExecutionResult: ...           # 결과를 모를 때 대조

preflight는 allowlist, 잔고, 한도를 확인합니다. 잔고 조회가 타임아웃되는 것처럼 확인 자체가 실패하면, 통과로 보지 않고 실패로 처리합니다(fail-closed). prepare와 submit을 나눈 이유는 서명 전에 제출할 내용을 해시로 고정하기 위해서입니다. prepare가 만든 payload와 실제로 서명할 payload의 해시가 다르면 서명 단계에서 거부됩니다.

출금이 나갔는지는 거래소 API로 확인하고, 그 이후의 확인 작업은 세 가지 probe로 묶었습니다.

class ChainReceiveProbe(Protocol):   # 입금 감지: 이 txid가 도착지에 기록됐는가
    async def check_receive(...): ...
 
class ChainFinalityProbe(Protocol):  # finality: confirmation이 충분히 쌓였는가
    async def check_finality(...): ...
 
class ProtocolProbe(Protocol):       # 프로토콜 증명: CCTP attestation이 발급됐는가
    async def check_proof(...): ...

새 송금 수단을 추가할 때는 executor와 probe를 구현해 등록하기만 하면 됩니다. 기존 노드 코드는 건드리지 않습니다. 부팅할 때 설정에서 켠 Lane만 등록되므로, CEX만 쓰는 배포에는 브릿지 코드가 아예 올라가지 않습니다.

승인과 실행 전 재검증

송금 요청 한 건은 택배 한 건과 비슷한 과정을 거칩니다. 접수하고, 내용을 검수하고, 승인을 받은 뒤, 포장해서 발송하고, 배송을 추적하다가, 수령을 확인하면 끝납니다.

송금 요청이 들어오면 plan compiler가 템플릿과 입력값으로 노드 그래프를 만들고 compiled_plan_hash를 기록합니다. 요청은 PENDING_APPROVAL 상태로 승인을 기다립니다. owner는 승인할 때 자신이 검토한 계획의 해시를 함께 보내야 하고, 이 값이 서버의 해시와 다르면 승인은 거절됩니다. 승인한 내용과 실행될 내용이 같은지 해시로 확인하는 셈입니다.

승인을 받았다고 바로 실행되지도 않습니다. Worker는 노드를 실행하기 직전에 계획의 해시를 다시 계산하고, allowlist도 다시 확인합니다. 그래서, 승인 후에 owner가 어떤 주소를 allowlist에서 빼면, 그 주소로 가는 다음 출금은 실행 직전에 멈춥니다.

Auto-approve는 템플릿 단위로 설정합니다. 다만, 에이전트가 보낸 요청은 auto-approve 대상이 아니며, 항상 사람의 승인을 거칩니다.

설계 결정

Airflow 구조를 참고한 스케줄링

노드 그래프를 만들고 나니, 각 노드를 누가 언제 실행할지 정해야 했습니다. 이 부분은 데이터 엔지니어로 일하며 오래 써 온 Airflow의 구조를 참고했습니다. Airflow는 정해진 일정에 따라 데이터 파이프라인을 실행하는 도구이고, QTG는 송금 한 건의 상태를 끝까지 추적하는 도구여서 목적이 다릅니다. 그래서, 상태를 DB에 두고 실행할 작업을 DB에서 골라 가는 구조만 가져왔습니다.

Airflow는 DAG의 실행 상태를 메타데이터 DB에 저장하고, 스케줄러가 주기적으로 DB를 조회해 실행할 태스크를 고릅니다. 스케줄러를 여러 대 띄울 때도 스케줄러끼리 통신하거나 Raft 같은 합의 알고리즘을 쓰지 않고, DB의 행 잠금(SELECT ... FOR UPDATE)으로 조율합니다. Airflow 문서는 그 이유로 운영의 단순함을 듭니다. 어차피 모든 구성 요소가 이 DB와 통신하기 때문입니다. 다시 말해 DB를 공유 큐로 쓰는 셈입니다.

이 구조는 실행 요청을 바로 밀어 넣는 방식보다 느립니다. 스케줄러가 다음번에 DB를 조회할 때까지 기다려야 하기 때문입니다. 하지만, QTG에서는 이 지연이 문제가 되지 않았습니다. 블록체인의 시간은 연속적으로 흐르지 않고 블록 단위로 끊어집니다. 이더리움은 12초마다 블록이 만들어지고, finality까지는 약 13분이 걸립니다. CCTP 표준 전송은 attestation을 받는 데만 10분 이상 걸리고, CEX 출금은 거래소 심사에 따라 수 분에서 수 시간이 걸립니다. 이런 환경에서는 밀리초 단위로 이벤트를 감지할 일이 거의 없습니다. 몇 초 간격으로 조회해서 생기는 지연은 전체 송금 시간에 비하면 무시할 만합니다.

그래서, QTG는 Airflow의 구조는 가져오되, 스케줄러 프로세스는 따로 두지 않았습니다. Worker가 Postgres를 직접 조회해 작업을 가져갑니다.

Worker는 역할별로 나뉩니다. node_dispatcher는 2초마다 실행할 노드를 찾아 제출하고, node_observer는 5초마다 제출된 노드의 결과를 확인합니다. node_recovery는 60초마다 결과를 알 수 없는 노드를 대조합니다. Observer가 노드를 가져갈 때 쓰는 쿼리를 단순화하면 다음과 같습니다.

SELECT n.id
FROM movement_request_nodes n
JOIN movement_requests r ON r.id = n.request_id
WHERE n.node_state IN ('SUBMITTED', 'OBSERVING')
  AND r.request_state = 'EXECUTING'
  AND (n.next_observe_at IS NULL OR n.next_observe_at <= NOW())
FOR UPDATE OF n, r SKIP LOCKED;

SKIP LOCKED를 쓰면 다른 트랜잭션이 이미 잠근 행은 기다리지 않고 건너뜁니다. 그래서, worker 두 개가 동시에 조회해도 서로 다른 노드를 가져가고, worker가 죽으면 트랜잭션이 끝나면서 잠금도 함께 풀립니다. 처리량을 늘리고 싶으면 worker 프로세스를 더 띄우면 됩니다.

실제 구현에서는 잠금 없이 후보 ID를 먼저 뽑고, ID마다 조건을 다시 확인하면서 잠그는 두 단계로 나누어 처리합니다.

next_observe_at은 노드별로 다음 확인 시각을 저장하는 컬럼입니다. 몇 초면 끝나는 경로는 짧은 간격으로, 수십 분이 걸리는 브릿지는 긴 간격으로 확인합니다. 확인 간격을 데이터로 관리하기 때문에, Lane별로 간격을 바꿔도 worker 코드는 고칠 필요가 없습니다.

스케줄러를 따로 두지 않았기 때문에 송금 상태를 가진 시스템은 Postgres 하나뿐입니다. 스케줄러와 DB가 각자 상태를 가지고 있으면, 두 기록이 어긋났을 때 송금이 실제로 나갔는지 판단하기 어려워집니다. 대신, Airflow가 제공하는 UI, 일정 기반 실행, 다양한 오퍼레이터는 포기했습니다.

지금의 QTG는 정해진 간격으로 DB를 조회하는 폴링 방식입니다. Airflow도 3.0에서 외부 이벤트를 받아 바로 실행하는 이벤트 기반 스케줄링을 도입했는데, QTG도 같은 방향을 계획하고 있습니다. 노드 상태가 바뀔 때 Postgres의 LISTEN/NOTIFY로 worker를 깨우는 방식입니다. 아직 구현하지는 않았습니다. Circle의 Arc 테스트넷에서 노드 3개짜리 Circle Gateway 송금을 측정해 보니, 전체 13.0초 중 5.6초(43%)가 폴링을 기다리는 시간이었습니다. 블록 시간이 짧은 체인에서는 이 대기가 무시할 수 없는 비중이 됩니다. 다만, 지금은 폴링 간격이 거래소별 rate limit의 상한 역할도 하고 있어서, 우선순위와 리소스 풀 같은 장치를 먼저 갖춘 뒤 바꿀 계획입니다.

결과를 알 수 없는 상태

분산 시스템에서 외부 호출의 결과는 성공, 실패, 알 수 없음 세 가지입니다. 출금을 요청했는데 응답을 받기 전에 연결이 끊기면, 거래소가 요청을 처리했는지 알 수 없습니다. 이때 다시 요청하면 같은 금액이 두 번 나갈 수 있습니다.

QTG는 이 구간을 별도의 상태로 남깁니다. Worker는 외부에 무언가를 제출하기 전에 intent 행을 먼저 기록하고, 제출이 끝나면 결과를 기록합니다. 두 기록 사이에 worker가 죽으면 해당 노드는 UNKNOWN 상태가 됩니다. UNKNOWN 노드는 자동으로 다시 제출하지 않습니다. 대신, recovery worker가 거래소 출금 내역이나 체인을 조회해, 실제로 제출됐는지부터 확인합니다.

돈이 이미 나간 뒤에 생긴 실패는 따로 다룹니다. 예를 들어, CEX 송금에서 withdrawal_action은 완료됐는데, withdrawal_observe가 거래소 API 오류로 실패했다고 해 보겠습니다. 이 요청을 단순 실패로 처리하고 처음부터 다시 실행하면 출금이 한 번 더 나갑니다. 그래서, 부작용이 있는 노드(has_side_effect=true)가 완료된 뒤에 다른 노드가 실패하거나 결과를 알 수 없게 되면, 요청 전체를 MANUAL_INTERVENTION 상태로 보냅니다. 이때 자동 재시도는 멈추고 owner에게 알림이 갑니다. owner는 거래소 화면에서 상황을 확인한 뒤, 실행을 이어 가거나 완료 또는 실패로 확정합니다.

전체 상태와 전이 규칙은 State Machine 문서에서 볼 수 있습니다.

서명 서비스 분리

Core가 KMS를 직접 호출하게 만들 수도 있었습니다. 하지만, 그러면 공급망 공격으로 Core 프로세스 안에서 코드가 실행됐을 때 KMS 자격 증명까지 노출됩니다. 그래서, 서명은 별도의 서명 서비스에 맡기고, Core는 이 서비스에 HTTP로 서명을 요청하게 했습니다. Core는 프로세스 안에 서명 설정이 들어 있으면 아예 시작하지 않습니다.

if any(value not in (None, "") for value in local_values):
    raise ValueError(
        "qtg.main forbids in-process signer configuration; configure MG_REMOTE_SIGNER_*"
    )

KMS 키 ID와 AWS 자격 증명은 서명 서비스에만 있습니다. Core와 서명 서비스 사이의 요청은 HMAC과 일회용 nonce로 인증하며, 서명 서비스는 사용한 nonce를 Postgres에 기록해 같은 요청이 다시 들어오면 거부합니다. 서명 요청에는 payload와 함께 signing intent(자산, 수량, 수신 주소)와 payload 해시가 들어갑니다. Core는 서명 서비스가 알려 준 서명 주소가 미리 설정해 둔 주소와 같은지도 확인합니다.

Core는 서명을 요청하기 전에 서명 서비스가 준비된 상태인지 먼저 봅니다. 서명 서비스가 내려갔거나, 마지막 확인이 오래됐거나, 잠겨 있으면, 그 서명 서비스에 묶인 노드는 서명을 시도하지 않고 READY 상태로 기다립니다. 아직 아무것도 제출하지 않은 상태여서 UNKNOWN 노드가 생기지 않고, 다른 송금도 멈추지 않습니다. 반면, 인증 실패나 서명 주소 불일치처럼 기다려도 풀리지 않는 문제는 바로 노드를 실패로 처리합니다. 지갑 서명 승인 API도 같은 기준을 따르며, 서명 서비스가 준비되지 않았으면 job 상태를 바꾸지 않고 409 SIGNER_NOT_READY를 돌려줍니다.

서명 방식은 하나의 인터페이스(SignerProtocol)로 추상화했습니다. 처음에는 운영 환경에서 AWS KMS 구현을 쓰고, 로컬 개발에서는 .env나 1Password에서 키를 읽는 개발 전용 서명기를 쓸 수 있게 했습니다. Core는 이 서명기를 거부했지만, 실거래 점검 스크립트나 일회성 CLI 같은 호스트 도구는 프로세스 안에서 키를 읽어 서명할 수 있었습니다. 앞의 표에서 보았듯 이 방식은 키가 프로세스 메모리에 올라온다는 문제를 그대로 안고 있습니다. 그래서, 개발 전용 서명기를 없애고 호스트 도구도 AWS KMS로만 서명하게 바꾸었습니다.

대신, AWS를 쓰지 않는 로컬 배포를 위해 서명 서비스에 암호화 keystore 방식을 추가했습니다. keystore는 scrypt로 유도한 키로 개인키를 암호화한 Ethereum V3 형식의 파일입니다. 서명 서비스는 항상 잠긴(LOCKED) 상태로 시작하고, owner가 컨테이너 안에서 signer_control unlock을 실행해 passphrase를 직접 입력해야 서명을 시작합니다. 잠금 해제 요청은 컨테이너 안의 unix socket으로만 받고, HTTP로는 열어 두지 않았습니다. passphrase는 환경 변수, Compose 파일, 명령 인자, 로그 어디에도 남기지 않고, 키를 밖으로 꺼내는 API도 없습니다. 재시작하면 다시 잠기는데, 자동으로 잠금을 푸는 기능은 아직 없어서 owner가 매번 직접 풀어야 합니다. KMS와 같은 인터페이스에 구현을 추가하는 방식이어서, 나중에 다른 KMS를 써야 할 때도 같은 방법으로 넓힐 수 있습니다.

배포 구성과 보안 수준

앞의 표에서 보았듯 QTG의 통제는 대부분 QTG 프로세스와 DB 안에서 동작합니다. 그래서, QTG를 어디서 운영하느냐가 설정 하나를 바꾸는 것보다 보안 수준에 더 큰 영향을 줍니다.

로컬 호스팅에는 분명한 한계가 있습니다. 패키지를 설치하고 브라우저를 여는 개발 머신에서 돈을 옮기면, 공급망 공격이 떨어지는 곳과 secret이 있는 곳이 같아집니다. 그래서, 실제 자금을 다룰 때는 다음과 같은 구성을 권장합니다.

• 모든 구성 요소를 AWS에: QTG Core, 서명 서비스, Postgres를 모두 AWS에 올리고, EC2의 IAM 인스턴스 역할로 KMS를 호출합니다. 서버에는 AWS 자격 증명 파일이 없습니다.
• 네트워크는 Tailscale VPN으로: QTG의 포트는 tailnet 주소에만 열고, Postgres는 외부에서 접근할 수 없게 둡니다.
• owner PC는 CLI로만: 개발과 패키지 설치는 owner PC에서 하고, QTG에는 VPN을 거쳐 qtg CLI로만 접근합니다.
• 거래소 쪽 통제: 거래소 API 키에 서버의 IP만 허용하고, 출금 주소 화이트리스트를 겁니다.

이렇게 구성하면 개발 머신에 공급망 공격이 떨어져도 서명 키와 거래소 키에는 닿기 어렵습니다. 서버가 장악되더라도 KMS 서명 기록은 CloudTrail에 남고, 거래소 쪽 통제는 그대로 유지됩니다. 개인이나 작은 팀이 운영하면서도 기관에 가까운 수준의 보안을 갖출 수 있는 구성이라고 생각합니다. 다만, tailnet에 연결된 모든 기기가 QTG에 닿을 수 있기 때문에, Tailscale ACL로 접근할 수 있는 기기를 좁혀 두어야 합니다.

LLM 에이전트 권한 설계

QTG의 API 키에는 admin과 agent 두 가지 역할이 있습니다. admin은 사람인 owner가 쓰는 키로, 송금 승인과 거절, 템플릿, 서명 서비스, allowlist 관리를 모두 맡습니다. agent는 허용된 템플릿, 거래소, 자산, 금액 범위 안에서 송금을 제안만 할 수 있습니다. 처음에는 설정 권한 없이 승인만 하는 operator 역할도 있었습니다. 그런데 owner가 Passkey로 로그인해 admin 키 하나로 승인과 설정을 모두 처리하는 구조로 바뀌면서 operator 키를 발급할 일이 없어졌고, 지금은 admin과 agent 두 역할만 남겼습니다. 여러 사람이 나눠 승인하는 구조는 이후 과제로 남겨 두었습니다. 앞에서 설명했듯이 에이전트가 보낸 요청은 auto-approve되지 않습니다.

에이전트는 전용 CLI인 qtg-agent나 MCP 서버인 qtg-mcp로 QTG를 사용합니다. qtg-mcp는 시작할 때 whoami로 API 키의 역할과 네임스페이스를 확인하고, 설정과 다르면 실행되지 않습니다. 잘못된 키가 데스크톱 앱에 조용히 연결되는 일을 막기 위해서입니다.

오픈 코어와 수익화

QTG는 오픈 코어(open core) 방식으로 공개할 계획입니다. 기본 기능은 무료 버전(Free)에, 일부 기능은 유료 버전(Pro)에 넣습니다.

승인, allowlist, 감사 기록 같은 안전 장치는 모두 Free에 들어 있습니다. 무료 버전을 쓴다고 송금이 덜 안전해지면 안 된다고 생각했기 때문입니다. Pro에는 트레이딩 편의성을 높이는 기능을 넣습니다. 쓸 수 있는 거래소와 브릿지를 늘리고, 예산 안에서 자동으로 승인하는 기능처럼 운영 부담을 줄여 주는 기능들입니다.

가격은 아직 정하지 않았지만 연간 구독 방식을 생각하고 있습니다. 서명을 AWS KMS에 맡기는 구조인 만큼, 장기적으로는 AWS Marketplace에서 바로 설치해 쓸 수 있게 만드는 것이 목표입니다.

마무리

QTG는 주문 API처럼 입출금도 표준화할 수 없을까 하는 질문에서 출발했습니다. 송금을 노드 그래프와 probe로 나눠 거래소와 브릿지 간 차이를 감췄고, 개인키는 KMS와 별도 서명 서비스 뒤로 옮겼습니다. 또, 블록 생성과 거래소 심사라는 느린 시간 단위에 맞춰, Airflow처럼 DB를 조회하는 worker 구조를 택했습니다. QTG는 아직 개발 중이며, 공개 후 운영하면서 배운 점은 따로 정리하겠습니다.

외부 시스템의 느린 이벤트를 기다리는 서비스를 만든다면, 메시지 브로커를 도입하기 전에 DB를 조회하는 worker만으로 충분한지 먼저 따져 보시길 권합니다.

참고자료

• QTG 문서
• QTG 문서: QTG Overview
• QTG 문서: CCTP Lane
• QTG 문서: Worker Orchestration
• QTG 문서: Movement Authorization Model
• QTG 문서: Security Tradeoffs
• Apache Airflow 문서: Scheduler
• BleepingComputer: AI-powered malware hit 2,180 GitHub accounts in s1ngularity attack
• CCXT Manual
• BleepingComputer: Shai-Hulud malware infects 500 npm packages, leaks secrets on GitHub
• The Hacker News: Injective Labs GitHub Compromise Pushes Wallet-Key-Stealing npm Packages
• Startup Fortune: Two npm attacks in four days show crypto's weak point is the supply chain

MAB 프레임워크로 OLTR을 어떻게 정의하는지와, 그 변천사를 간략히 정리해보았습니다.

언급된 MAB 알고리즘

기존 Classical MAB : $ϵ$-greedy, UCB, Thompson Sampling

Contextual MAB : LinUCB (WWW 10), LinTS (ICML 13), GIRO (ICML 19)

Non-stationary MAB : DiscountedUCB + SlidingWindowUCB (ALT 11), CUSUM-UCB + PHT-UCB (AAAI 18), dTS (NIPS 17)

Contextual + Non-stationary MAB : NeuralBandit (ICONIP 14), dLinUCB (SIGIR 18)

Multiple Play MAB

• 단순 해결 : MP-TS + IMP-TS (ICML 15)
• Click Model과 결합 : CascadeUCB1 + CascadeKL-UCB (ICML 15), RecurRank(ICML 19)-Non MAB
• Combinatorial 관점: CUCB (ICML 13)
• Combinatorial + Volatile arm : CC-MAB (NIPS 18)

Batched Update MAB : bTS (IEEE BigData 18)

Using Feedback as Relative Perspective : RUCB (ICML 14), CDB (RecSys 19)

Exploration-Exploitation Dilemma

외팔이 강도가 2개의 슬롯머신을 당길 기회가 있는데, 두 개의 슬롯머신은 reward를 반환할 확률이 다르다고 합시다. 그걸 모르는 상태에서 어떻게 슬롯 머신을 당겨야 가장 높은 reward 기댓값을 얻을 수 있을까요?

Classical MAB의 가장 단순하고 흔한 예시는 슬롯머신이 reward를 반환할 확률이 베르누이 분포를 따른다고 가정하는 것입니다. 그렇다면 둘 중에 확률이 높은 슬롯머신만 계속 당긴다면 최고의 결과를 얻을 수 있을 것입니다. 하지만, 우리는 oracle (확률 또는 분포를 알고 있는 절대자)이 아니기 때문에 일단 당겨보면서 어떤 슬롯머신이 더 많은 reward를 반환할지 탐험을 해야할 필요가 있습니다.

여기서, 최선의 선택 (그림에서는 오른쪽 슬롯머신)을 했을 때의 reward 기댓값, 그리고 최선의 선택을 하지 않았을 때의 reward 기댓값의 차이를 regret이라고 합니다. 위 그림을 예시로 들면 왼쪽 머신을 당길 때마다 0.2의 regret이 누적되는 것입니다. regret을 정의하는 방법은 논문마다 다르기도 하지만, 실서비스 적용에서 그리 중요한 포인트는 아니기 때문에 컨셉만 알고 넘어가면 될 것 같습니다.

그렇다면, 추천 시스템에서는 reward를 어떻게 정의할까요? 노출 (impression) 후 click이 발생한 경우 reward 1이 발생, unclick이 발생한 경우는 reward가 발생하지 않는다고 정의하면, reward의 기댓값은 노출대비 클릭의 기댓값이 되고, 그리고 그건 CTR이 됩니다!! Tada~~ 그렇기 때문에 regret 최소화 == CTR 최대화와 동일해집니다.

요약하면: 모르지만, 당겨보면서 알아가보자

Classical MAB

1. $e$-greedy

트래픽 중, $ϵ$ 만큼의 비율은 무작위로 탐색(exploration)하고, 나머지 $1-ϵ$ 에 대해 지금까지 관찰된 결과를 바탕으로 탐욕적으로 가장 최선의 arm을 draw하는 (empirical) 전략을 $ϵ$-greedy 전략이라 부릅니다. 시도마다 슬롯 손잡이 $a$ 의 reward의 기댓값 (CTR)을 추정해 나가고, 시도가 계속될 수록 reward의 추정치는 참값에 수렴함을 가정합니다. 하지만, 관측 횟수가 적은 경우에는 관측결과의 신뢰도가 매우 낮기 때문에 문제가 생깁니다. (ex. 12345를 4번 추천했는데 3이 2번 4가 1번 실제로 클릭되었다. 그러면 3이 best case일까? 이 결과를 믿을 수 있을까?) 반대로, 관측 횟수가 충분히 많아 신뢰도가 높은데도 $ϵ$ 만큼의 explore를 반드시 해야한다는 점이 문제가 됩니다. 이러한 문제를 시간의 흐름 (시도 횟수)에 따라 $ϵ$ 값을 적절하게 감소시켜가며 해결할 수도 있습니다. 적절하게 탐색 확률을 감소시킨다면 T시점에 최선의 선택을 하지 않는데서 발생하는 Regret $R_A(T)$를 T로 나눈 값, $R_A(T)/T$ 는 0에 수렴하게 됩니다.

2. Optimism in Face of Uncertainty (OFU)

OFU는 불확실한 것을 낙관적으로 보자는 컨셉의 알고리즘입니다.

앞서 설명한 $ϵ$-greedy는 항상 empirical mean이 좋은 arm만을 고르고, 나머지를 입실론의 확률로 고르지만, 실제 arm에서 얻는 보상은 constant가 아닌 특정 분포에서 draw되는 r.v라고 보는 것이 합리적이기 때문에 탐색 전략에 신뢰구간의 개념을 도입합니다. OFU는 현재까지 관찰된 결과를 바탕으로 통계적으로 계산된 신뢰구간의 상한선 (Upper Confidence Bound) 를 그 arm의 가치로 보고, 그 arm을 draw 합니다.

예를 들어, 관찰된 결과를 바탕으로 아래와 같은 사후분포를 추정해 냈을 때, 누가봐도 평균값은 파란색<초록색<주황색 순서이지만, 95% 신뢰구간의 상한선은 파란색이 제일 높으므로, 파란색 arm을 draw하는 것입니다.

UCB를 정의하는 방법에 따라 여러 변형 알고리즘들이 있지만, 대표적인 UCB 알고리즘인 UCB1이 arm을 고르는 방식은 다음과 같습니다.

$x_i$ 는 i번째 arm의 지금까지 관측한 reward (클릭)의 평균값이고, $n_i$ 는 arm i가 play (impression)된 횟수를 의미합니다. 위의 값은 arm i의 실제 보상에 대한 $1-\frac{1}{t}$ 의 신뢰구간의 upper bound를 의미하는 것으로, Chernoff-Hoeffding bound 에 의해 얻어지는 값입니다. 처음에는 관측 결과 수가 적은 arm들이 뽑힐 확률이 높지만 (exploration), time은 log scale로 증가, $n_i$ 는 linear하게 증가하므로 우항의 값은 시간이 흐를 수록 작아지고, exploration의 비율이 시간이 흐름에 따라 감소합니다.

3. Thompson Sampling

Probability Matching이라고도 불립니다. Google Analytics의 AB 테스팅 최적화에도 사용된 알고리즘이며, 일반적으로 UCB나 $ϵ$-greedy 보다 성능이 높다고 알려져 있습니다. 시간 t마다 정책에 따라 arm a를 선택하고, 그에 상응하는 reward $r$ 을 받을 때, Thompson sampling은 관측치 ($a_t,r_t$) 와 파라미터 $\theta$ 를 사용해 likelihood function $P(r\mid a,\theta )$ 를 설계한 다음, prior를 가정해 posterior를 업데이트하고, 그 posterior에서 직접 샘플을 뽑아 의사결정을 하는 방식입니다. 이 때, 각각의 arm의 reward가 관찰될 확률 ${\theta }_k$이 독립적인 베르누이 분포를 따른다고 가정했을 때, conjugacy 특성으로 인해 prior를 베타분포로 잡는다면, posterior 또한 베타분포가 됩니다. 이 때, ${\theta }_k$ 는 다음과 같은 파라미터를 가집니다.

분포가 가정되었기 때문에 분포를 통해 평균과 분산을 알 수 있습니다. 이 때, 분산이 의미하는 것은 Explore 입니다. 베타 분포의 평균과 분산은 다음과 같은 모양입니다.

Thompson Sampling의 파라미터 업데이트는 다음과 같이 이루어지기 때문에, 시행이 거듭될 수록 분산은 작아지게 되므로, Exploration의 정도는 줄어들게 됩니다. 이 때, $c_i\in \{0,1\}$ 는 클릭의 유무를 의미합니다.

OFU 알고리즘은 추정된 분포의 신뢰구간 상한선을 바탕으로 의사결정을 했다면, TS 알고리즘은 추정된 분포로부터 직접 샘플을 뽑아 의사결정을 합니다.

아래 영상은 베르누이 밴딧에서 Thompson Sampling을 구현하여 시뮬레이션 한 것입니다. 각 밴딧에서 reward가 관찰될 확률이 $\theta =[0.1,0.2,0.3,0.4]$ 인 $K=4$ 인 밴딧 상황에서 베타분포가 적합되는 과정을 관찰할 수 있습니다. 동시에, Exploration-Exploitation의 정도도 관찰할 수 있습니다.

After Classical

하나의 논문을 정독하기보다는 MAB 연구의 추세를 폭넓게 이해해보고자 하였습니다.

MAB 리서치를 진행하며 느낀점은, sota 논문들은 대부분 기존 MAB 방법론들을 베이스라인으로 실험을 진행하고, 그 것들보다 성능이 나음을 주장하고 있다는 점입니다. 그러나, 대부분의 MAB 논문들이 stationary, Top-1 draw, reward ~ R-sub gaussian 등 이상적인 상황을 가정하고 있기 때문에 sota 알고리즘을 소개하는 논문에서의 성능 향상, 특히 offline evaluation 상황은 실 서비스에 적용했을 때 성능향상이 실제로 일어날지 최대한 의심하며, sota 알고리즘이 기존의 알고리즘에서 극복하려고 한 한계는 무엇인가? 를 중심으로 리서치를 진행했습니다. 여러 알고리즘들의 컨셉을 잘 정리해두면 후일에 더 빠른 문제해결에 도움이 될 것이라고 생각하기 때문입니다.

1. Non-stationary MAB

Classical MAB에서 reward distribution이 time-independent하다는 가정을 파괴합니다. 시간이 흐르면 특정 arm의 CTR 기댓값은 감소하거나 증가할 수 있다는 것입니다. Non-stationary 환경은 서서히 reward의 기댓값이 변한다는 Slowly-varying, breakpoint 전후에는 일정함을 유지한다는 Abrubtly-changing 두 가지로 구분되어 정의되고, 이러한 각각의 환경에 맞게 MAB policy도 크게 두가지 범주로 나뉩니다.

1.1. Passively Adaptive Policies

시간 할인의 개념을 이용해 최근 데이터에 높은 가중치를 줌으로써 현재 의 best arm을 찾습니다. 이 범주에 속하는 ofu 방법으로는 DiscountedUCB, SlidingWindowUCB 가 있고, 톰슨 샘플링 기반으로는 Taming Non-stationary Bandits: A Bayesian Approach (NIPS 2017) 에서 소개된 discounted Thompson Sampling (dTS)가 있습니다.

DiscountedUCB는 지난 관측 결과일수록 gamma를 이용해 시간할인을 하여 그 영향력을 감소시키며, SlidingWindowUCB는 지정된 윈도우 기간만큼의 관측 결과만을 사용합니다. 이러한 수동적인 적응 방법론은 과거의 데이터의 영향력을 줄이는 것이지 사용하지 않는 것이 아니기 때문에 급격한 변화에 발빠르게 대응을 하지 못하는 Time-lag 문제가 발생합니다.

1.2. Actively Adaptive Policies

급격한 변화를 빠르게 잡아낼 수 있는 Change Detection Algorithm을 사용합니다. Two-sided CUSUM UCB, PHT-UCB가 A Change-Detection based Framework for Piecewise-stationary MAB Problem (AAAI 2018) 에서 소개되었습니다. 이 중 Two-sided CUSUM UCB는 Fault Detection을 위해 주로 사용하는 통계적 관리도 (SPC) 변화 탐지 모형 중 누적합을 이용한 CUSUM 관리도를 이용한 것이고, PHT-UCB 는 Page-Hinkley Test를 이용해 변화 탐지를 하는 모형입니다.

모형이 CUSUM 또는 PHT Chart의 UCB나 LCB에 변화 탐지 신호를 보내는 경우 bandit algorithm을 리셋하여 재학습을 진행합니다. 그 구조는 다음과 같습니다.

contextual bandit 상황에서의 non-stationary 환경을 고려한 알고리즘은 A Neural Networks Committee for the Contextual Bandit Problem (ICONIP 2014)에서 소개된 NeuralBandit, Learning Contextual Bandits in a Non-stationary Environment (SIGIR 2018)에서 소개된 dLinUCB가 있습니다.

dLinUCB 알고리즘은 여러 개의 slave bandit model을 동시에 업데이트하며, reward의 신뢰구간을 바탕으로 낡은 모델을 폐기하고 재학습시키며 현재 최적의 model을 사용하는 독특한 방식을 사용하는데 slave model들이 LinUCB 한 종류여야 할 필요가 없기 때문에 여러 모델을 앙상블하여 사용할 수 있는 독특한 구조를 제안합니다.

2. Context-Reward Relationship

슬롯머신이야 reward가 관찰될 확률이 고정되어 있지만, 실제 서비스에서는 reward가 관찰될 확률이 주변 환경이나 사용자에 따라 변할 수 있습니다. 그렇다면, reward의 분포가 컨텍스트와 무관하게 Bernoulli 분포를 따른다고 가정하는 순간 치명적인 문제가 생깁니다.

그래서 기존 MAB 스키마에서 사용하고 있지 않던 정보인 context와 feedback을 결합해 reward의 분포를 학습하는데 반영하는 시도가 contextual bandits으로 이어졌습니다. LinTS와 LinUCB는 user(query), content의 context와 reward의 기댓값이 선형 관계를 가짐을 가정함으로써 feedback 뿐만 아니라 context 정보를 이용해 reward의 기댓값을 학습하는데 사용합니다. 두 알고리즘 모두 SGD 등의 방식을 사용하지 않고 Closed Form으로 ridge regression 파라미터를 업데이트합니다.

하지만, context와 reward의 기댓값은 선형관계라는 LinTS와 LinUCB의 기본 가정에 의문을 제기할 수도 있습니다. NNBandit (ICONIP 2014) 은 Neural Net이 Universal approximator임을 이용하여 context와 reward의 기댓값 사이의 non-linear한 관계를 표현하는 모델입니다.

이외에도, GLM, Balanced linear model, Adaptive learning, Bootstrap 등의 해결책도 제시됐습니다. 모델이 복잡할 수록 context-reward 관계를 잘 잡아내는 것은 당연하나, 이 연산이 bandit들의 모든 arm에 대해 이루어져야 하기 때문에 조금이라도 연산량이 많아지면 실 실행시간이 가장 크게 증가할 여력이 있는 부분이고, linear form 이 아닌 경우 online learning 상황에서 closed form이 아닌 SGD, Mini-Batch 방식의 업데이트를 수행해야 하기 때문에 연산량과 가용자원을 고려해서 반드시 상황에 맞는 모델을 선택해야 합니다.

3. Multi-play

Multi-armed bandit의 multi는 arm이 K개 있다는 것을 가정하지만, 한 번에 1개의 arm만 당길 수 있는 single play 상황을 가정합니다. 하지만, 실서비스에서는 문어가 K arms 들 중 한 개만 draw하는 것이 아닌 여러 개를 한꺼번에 draw를 해야하는 경우도 분명 존재합니다.

1개만 draw (impression)을 했을 경우 이 추천결과를 click한다면 1, 아니면 0의 reward 값을 주는데, 여러 개 (best L)을 한꺼번에 draw하는 경우에도 같은 방법으로 reward를 업데이트하는 것이 reasonable한지 의문을 가질 필요가 있습니다. 왜냐하면, 각 arm에서 독립적으로 ${\theta }_k$ 의 확률로 reward가 관찰되는 것이 아닌, 최대 1번의 reward가 관찰된다는 제약이 있기 때문입니다.

3.1 Simple Idea

Optimal Regret Analysis of Thompson Sampling in Stochastic MAB Problem with Multiple Plays (ICML 2015) 에서 multi-play 상황에 대처하는 방식을 소개하고 있습니다. 해당 논문에서 제안된 MP-TS는 사실상 TS와 큰 차이가 없는데, multiple-play 상황에서 Beta draw를 실시하여 top-1이 아닌 스코어 순으로 top-L개를 draw하고, 1 또는 0의 reward를 업데이트 합니다.

동시에, MP-TS의 개선 버전으로 I(mproved)MP-TS를 제안하는데, suboptimal draw가 너무 많이 일어나니 L개의 slot 중 L-1개에는 기존 관찰 결과로부터 최선의 결과를 (exploitation), 1개에서만 기존 Thompson sampling의 Beta draw를 실시(Exploration)한다는 것입니다.

위 방법은, L개의 draw된 모든 arm들이 독립적인 Expectation reward을 가지고 있다는 가정하에는 합리적이지만, 현실은 그렇지 않습니다. L개의 노출 컨텐츠 중, n번째의 컨텐츠를 클릭한 유저 중에는 n+1번째부터의 노출 컨텐츠는 쳐다보지도 않은 사람이 있을 수도 있고, 3번째 노출 컨텐츠가 4번째 노출 컨텐츠 클릭에 영향을 줄 수도 있습니다. L개가 모두 마음에 들었어도 클릭은 최대 한 개뿐입니다.

3.2 Click Model

이러한 연구는 IR 분야에서 유저의 행동 패턴을 분석하는 Click Model과 MAB를 결합하여 해결하려는 시도로 이어졌는데, 대표적인 Click Model은 다음과 같습니다. (참고 : Click Models for Web Search (Authors' version))

Notation

$u$ : document id

$q$ : user's query

$u_r$ : A document at rank r

$C_u$ : r.v for Click document u

$E_u$ : r.v for Examinate document u

$A_u$ : r.v for Attractiveness of document u

$S_r$ : r.v for Satisfaction level after click

• Random Click Model (RCM)

가장 기본이 되는 CTR 예측 모델로 모든 컨텐츠 u는 동일한 클릭 확률 $\rho$ 를 가지고 있다고 가정하는 모델입니다. Classical MAB는 해당 모델을 기본 가정으로 하고 있습니다.

• Rank-Based CTR Model (RCTR)

컨텐츠가 노출된 순서(rank)에 따라 CTR의 기댓값이 달라진다고 가정하는 모델입니다. RCM보다는 상당히 현실적인 베이스라인 모델인데, Accurately interpreting clickthrough data as implicit feedback (SIGIR 2005) 의 유저 행동 패턴 연구에서 관측된 데이터에서도 Rank 1 컨텐츠의 CTR이 0.45인 것에 비해 Rank 10 컨텐츠의 CTR은 0.05보다 낮은 CTR 값을 보여줬고, 실제 사내 서비스의 클릭 모델도 위치에 따라 위 실험결과와 유사한 CTR을 보여줍니다.

다만, 이 Click ratio를 그대로 RCTR 모형에 적용을 할 수는 없는 것이, 실제 슬롯별 CTR은 rank의 효과에만 영향을 받는 것이 아닌, MAB가 최선의 rank를 찾기 위한 노력의 효과에도 같이 영향을 받기 때문입니다.

• Position-based Model (PBM)

PBM의 CTR은 위와같은 Bayesian Network(참고 : PRML-Bayesian Network)로 나타낼 수 있습니다. 이 모형은 유저 q가 추천 컨텐츠를 확인(Examine)함과 동시에 해당 컨텐츠에 이끌려야 (Attracted) 클릭이 일어난다는 모형입니다. 해당 모형에서 검사 여부와 이끌림 여부는 독립이라고 가정하며, 검사 여부는 컨텐츠 u의 rank에 영향을 받고, 이끌림 여부는 유저 q와 컨텐츠 u에 동시에 영향을 받는다고 가정합니다. 따라서 위의 베이즈 네트워크는 아래와 같은 수식으로 표현됩니다.

• Cascade Model (CM)

An experimental comparison of click position-bias models (WSDM 2008) 에서 소개된 가장 널리쓰이는 유저 행동패턴 가정으로, 유저가 컨텐츠를 top-to-bottom으로 원하는(relevant) 컨텐츠를 찾을 때까지 계속 스크롤한다는 것입니다. 이를 나타내는 베이즈 네트워크는 아래와 같습니다.

CM 모델에서는 1번째 추천 컨텐츠는 항상 검토(examined)되며, r번째 컨텐츠는 r-1번째 컨텐츠가 검토되고 동시에 클릭되지 않아야만 검토됩니다. 그 수식은 다음과 같습니다.

이외에도 DCM 등 다양한 클릭 모델들이 존재합니다.

이러한 클릭 모델은 슬롯별 CTR 예측에 사용되는데, 해당 모델들이 Eye Tracking 등 HCI 기반의 연구와 함께 이루어져 실제 유저의 행동패턴을 잘 반영한다는 특성때문에 클릭 모델과 MAB를 결합하려는 시도가 Cascading Bandits: Learning to Rank in the Cascade Model (ICML 2015) 에서 이루어지게 됩니다. 이는 Click Model 중 가장 널리쓰이는 Cascade model과 MAB를 결합한 것이며, 논문에 CascadeUCB1, CascadeKL-UCB가 소개되어 있습니다.

또한 위에서 언급한 IMP-TS를 소개한 논문 Appendix에 Cascade 상황에서 생기는 bias를 해결하기 위해 MP-TS를 변형한 BC-MP-TS (Bias-Corrected MP TS)도 소개합니다.

해당 모델에 contextual 버전을 추가한 CascadeLinTS, CascadeLinUCB는 Cascading Bandits for Large-Scale Recommendation Problems (UAI 2016)에 소개되었습니다.

3.3 Combinatorial Bandit

Combinatorial bandit 은 클릭 모델을 이용하는 것보다 더 폭 넓은 관점의 bandit 알고리즘입니다.

이 밴딧 알고리즘의 활발한 후속 연구를 이끈 논문은 Combinatorial MAB: General Framework, Results and Applications (ICML 2013) 입니다. Cascade Bandit은 Vertical 방식으로 추천결과가 나열되면서, 같은 추천 결과에서 여러 번의 클릭이 일어날 수 있는 IR 분야에 적합한 밴딧 알고리즘이라고 한다면 Combinatorial 방식은 Super arm의 개념을 도입해 조금 더 범용적이고, 추천시스템에 적합한 multiple-draw 상황의 전략을 도출해냅니다.

여러 개의 arm을 draw해야 하는 상황에서, arm끼리 상관관계도 있어 개별 arm의 절대적 가치를 추정하는 것의 정당성이 흔들리니, 함께 draw 하는 arm의 조합을 super arm으로 정의하는 것입니다.

가장 단순하게 생각한다면, 존재할 수 있는 모든 super arm을 각각의 arm처럼 다룬다면 기존 Classical 1-draw bandit 방식으로 문제를 풀 수 있습니다. 하지만, arm이 $m$개 존재한다면 존재 가능한 super arm은 최대 $2^m$ 개, L개를 draw하는 상황에서는 ${}_m{C}_L$개로 기존 arm의 개수보다 exponential 하게 증가하기 때문에 이러한 방식으로 문제를 풀어나갈 수는 없습니다.

그렇기 때문에, 위 논문에서는 적절한 arm들의 조합을 구성하기 위한 oracle 함수를 만들 것을 제안합니다. oracle 함수는 논문마다 그 방식이 다르지만, 지금까지 관찰된 arm들의 draw와 reward 데이터를 바탕으로 개별 arm (underlying arm)들의 Expectation vector를 구성해 이 벡터를 바탕으로 최적의 arm의 조합인 super arm을 구성해주는 함수입니다. 어떻게 매핑을 하냐가 가장 중요한 부분인데, 위 논문에서는 $\alpha ,\beta$-Approximation 을 통해 super arm을 구성하고, Efficient Ordered Combinatorial Semi-Bandits for Whole-Page Recommendation (AAAI 2017)에서는 Oracle 대신 Maximization 문제를 정의하고, 이를 integer programming으로 푸는 대신 연산 효율을 위해 다음과 같은 구조의 네트워크로 계산합니다.

Combinatorial Bandit을 늦게 공부하기 시작해 더 정리하지 못한 점이 아쉬운데, Contextual Combinatorial MAB with Volatile Arms and Submodular Reward (NIPS 2018)는 사용 가능한 arm의 풀이 지속적으로 변하는 (volatile arms) 상황을 고려한 combinatorial bandit 알고리즘인 CC-MAB 를 소개합니다.

4. Batched Update

A Batched Multi-Armed Bandit Approach to News Headline Testing (IEEE BigData 2018) 야후 리서치에서 이루어진 연구입니다. MAB는 arm을 draw하는 것과 reward를 업데이트 하는 것이 이벤트 단위로 순차적으로 바로 일어난다고 가정하고 있는데, 실제 서비스에서는 트래픽이 매우 빠른 속도로 들어와 batch 단위로 일어날 수 밖에 없는 상황을 고려한 bTS (batched Thompson Sampling) 알고리즘을 제안합니다.

해당 논문에서는 베타분포의 파라미터를 업데이트 하는 방법을 summation과 normalization을 제안했는데, normalization 업데이트 방식은 배치 단위로 트래픽이 쏠림으로서 발생하는 부작용을 해결하고자 제안된 방법입니다.

[Summation] $c_t$ : 배치 t의 click, $u_t$ : 배치 t의 unclick

[Normalization] $M_t$ : t 배치에서 해당 밴딧의 모든 arm들의 impression 수, $K$ : arm의 수

그러나, 해당 논문에서의 실험 결과는 summation 방식이 훨씬 좋은 성능을 보였는데 저자들은 normalization update를 하면서 발생하는 noise의 효과가 side-effect를 처리하는 효과보다 큰 것 같다고 분석했습니다.

5. Arm의 가치는 절대적인가? (OLTR)

이번엔 조금 큰 틀에서의 문제 제기입니다. Top L from N 문제에서 MAB의 기본 가정은 arm마다 절대적인 가치가 있다는 것입니다. (reward의 기댓값), 해당 가정을 이용하지 않는 방식으로 Online Learning to Rank (OLTR) 문제를 풀어나가는 방법 또한 간략히 조사해보았습니다.

Learning to Rank는 IR 분야에 뿌리를 두고 있습니다. 추천 시스템에서는 MAB 방식의 online learning 방식이 널리 사용되고는 있지만, IR 분야에서는 다른 방식과 MAB 방식의 learning to rank를 다음의 논문에서 비교한 적이 있었습니다. Online Learning to Rank : Absolute vs Relative (WWW 2015)

Absolute 접근법은 일반적인 contextual bandit을 의미하는 것으로, document context, query, user context로부터 정보를 종합해 context features를 구성하고 이를 이용해 유저 피드백 데이터의 절대적 가치 (MAB 방식에서는 reward의 기댓값인 CTR)을 추정해 나가는 접근법입니다.

하지만, Relative 접근법은 특정 컨텐츠의 절대적 가치의 존재 자체에 의문을 제기합니다. 여러 개의 추천 결과를 노출하는 상황에서 유저 피드백 데이터로부터 얻는 정보는 해당 컨텐츠의 절대적 가치라기 보다는 같이 노출된 컨텐츠들 간의 상대적 우위(relative preference)일 뿐이라고 생각하는 것입니다. 이러한 상대적 접근법에 해당하는 모델들은 유저 피드백을 Stochastic Gradient Descent 방식으로 업데이트 함으로써 랭킹을 학습합니다.

위 논문에서는 LinUCB를 변형한 Lin-$ϵ$과 Candidate Preselection(CPS) Learning to Rank 알고리즘을 비교했는데, 적은 숫자의 유저 쿼리와 문서(arm)이 있는 경우, 그리고 피드백에 노이즈가 없는 경우에는 MAB 방법론이 더 좋은 성능을 보이나, 유저 피드백에 노이즈가 많은 경우나 pool의 범위가 넓은 경우에는 Relative 접근법 (LTR)이 더 좋은 성능을 보인다고 결론지었습니다.

이런 Relative 접근 방법을 Bandit 알고리즘과 결합하려는 시도도 있었는데 이 분야의 Bandit 알고리즘은 Dueling Bandit이라 합니다. Relative UCB for the K-Armed Dueling Bandit Problem (ICML 2014)에서는 Feedback으로 얻은 정보를 한 쌍의 arm으로 부터의 상대적 선호를 나타낸다는 relative 해석법을 결합한 RUCB 알고리즘을 소개하고 있고, Online Learning to Rank for Sequential Music Recommendation (RecSys 2019)에서는 CDB 알고리즘을 소개하고 있습니다.

LTR 분야가 너무 폭 넓은 분야라 더 자세히 조사하지는 못했는데, SIGIR 2016에서 튜토리얼로 진행된 Online LTR for Information Retrieval 자료가 IR 분야에서의 LTR, 특히 Online LTR에 대해 상세하게 다루고 있으니 읽어보시면 좋을 것 같습니다. 기회가 된다면 더 읽어보고 정리할 예정입니다.

우리는 정말 無에서 시작하는가?

Exploration, Exploitation 딜레마의 근본적인 가정은 우리가 실제 노출결과가 어찌될지 모르기 때문에 일단 노출시켜보면서 탐색하고 알아낸다는 것입니다. 그렇다면, 우리는 정말 노출결과가 어찌될지 전혀 모르는 상태로 시작하는 걸까요?

(출처: Deep Neural networks for YouTube Recommendations (Recsys 16))

일반적인 추천시스템 구조에서 Candidate Generation과 Ranking 사이에는 Scoring, Ensemble 단계가 있습니다 (이를 품질 평가 모델이라 부르기도 하는 것 같습니다). 해당 scoring이 online 상황에서의 reward가 상관계수가 높다면, 그냥 해당 score를 초기값처럼 사용할 수도 있습니다. 요즘은 쓸 수 있는 feature도 잘 정제되어 있고, 모델이 계속 발전함에 따라 (deep! deeeeeep!) 조금 더 정밀한 사전 CTR Prediction이 가능하기 때문에, 오프라인 모델의 CTR 예측치를 MAB의 초기값으로 활용하는 방식으로 (ex. deep model의 컨텐츠 A에 대한 CTR 예측값이 0.1인 경우, Thompson Sampling의 컨텐츠 A에 대한 파라미터 초기값을 $\alpha =1$, $\beta =9$ 로 세팅한다.) MAB의 cold start 문제를 줄일 수도 있습니다.