Claude Code 세션 한 번으로 구현한 결과물: 실시간 mempool 러그(rug) 탐지 파이프라인
요약
Claude Code를 활용하여 Ethereum mempool 내 실시간 스캠 토큰(rug pull) 탐지 파이프라인을 구축한 사례를 다룹니다. 기존 코드 패턴을 학습하여 4개의 새로운 탐지 시그널을 구현하고, 3개의 리포지토리를 연동한 프로덕션 환경 배포 과정을 상세히 기록했습니다.
핵심 포인트
- Claude Code를 이용한 실시간 mempool 러그 탐지 기능 구현
- 기존 코드 패턴(DeployWatcher)을 재현하는 에이전트의 능력 확인
- 3개의 리포지토리(Watcher, DB, Telegram Bot)를 잇는 파이프라인 구축
- 에이전트와 개발자 간의 효율적인 역할 분담 및 협업 방식 제시
저는 Ethereum을 위한 실시간 스캠 토큰 탐지기인 RektRadar를 운영하고 있습니다. 이 글은 Claude Code (Fable 모델)를 사용한 한 세션의 솔직한 빌드 로그입니다. 저는 "우리 스캠 탐지 기능이 몇 가지를 놓치고 있다"는 상태에서 시작하여, 4개의 새로운 탐지 시그널(detection signals)을 배포하고 3개의 리포지토리(repo)로 구성된 실시간 알림 파이프라인을 프로덕션 환경에 라이브로 올렸습니다. 아래에 링크된 모든 PR(Pull Request)은 공개되어 있습니다.
"AI가 마법처럼 모든 것을 다 했다"는 뜻은 아닙니다. 흥미로운 점은 노동의 분업입니다. 에이전트(agent)가 진정으로 강력한 부분은 어디인지, 제가 어디에서 방향을 잡아야 했는지, 그리고 에이전트가 멍청한 짓을 하려던 순간 제가 어떻게 막았는지에 대한 이야기입니다.
설정 (The setup)
RektRadar는 약 7개의 리포지토리로 구성되어 있습니다: mempool 와처(watcher), 컨트랙트 분석기 (7개의 서브 분석기), 그래프 크롤러(graph crawler), Telegram 봇, Astro 마케팅 사이트, Vue 앱, 그리고 Ansible 인프라입니다. 전체적으로 Node/TypeScript를 사용하며, 실제 테스트 스위트(test suites)가 갖춰져 있습니다 (컨트랙트 분석기에만 약 7,000개의 테스트가 있습니다).
저는 보안 논의에서 드러난 탐지 공백(detection gaps) 목록을 가지고 세션을 시작하여, 이를 하나씩 해결해 나갔습니다.
1. 핵심 성과: 마이닝되기 전, mempool에서 러그(rug)를 포착하기
러그(rug)는 보통 단일 트랜잭션으로 발생합니다: removeLiquidity, 몰수 수준의 세금을 설정하는 setFee, setBlacklist, pause, mint 등입니다. 트랜잭션이 브로드캐스트(broadcast)된 후 포함(inclusion)되기 전까지 몇 초 동안 공개된 mempool에 머뭅니다. 저희는 이미 샌드위치 공격(sandwich detection) 탐지를 위해 대기 중인 트랜잭션(pending txs)을 스트리밍하고 있으므로, 우리가 이미 고위험(high-risk)으로 분류한 토큰에 대해 러그 동작이 발생하는지 동일한 트랜잭션들을 감시하는 것이 다음 단계였습니다.
Claude가 도출한 설계는 리포지토리에 기존에 존재하는 DeployWatcher 패턴을 반영했습니다:
export function classifyPrivilegedCall(
tx: PrivilegedTxLike,
byToken: Map<string, WatchEntry>,
...
**순수 분류기(pure classifier)**와 몇 분마다 고위험 토큰 세트를 갱신하는 주입된 와처(injected watcher)의 조합입니다. 이러한 분리가 중요했습니다. 분류기에는 모킹(mock) 없이 19개의 유닛 테스트(unit tests)가 적용된 반면, I/O는 와처에 머물렀습니다. 이것이 바로 에이전트들이 조용히 잘해내는 부분입니다. 깨끗한 기존 패턴이 주어지면, 새로운 것을 발명하기보다 그 형태를 그대로 재현해냅니다.
이 지점에서 서비스 간 연동(cross-service)이 발생합니다. 탐지는 mempool watcher(mempool 감시자)에서 이루어지고, 알림은 Telegram 채널에 도달해야 합니다. 따라서 세션은 세 개의 리포지토리(repo)로 구성된 파이프라인을 구축했습니다.
- Postgres
privileged_alerts핸드오프(hand-off) 테이블 (인프라 마이그레이션), - 탐지된 알림을 해당 테이블에 기록하는 mempool watcher (트랜잭션 해시 기준 멱등성(idempotent) 보장),
- 게시되지 않은 행을 폴링(polling)하여 "임박한 러그(imminent rug)" 메시지를 게시하고, 각 알림이 한 번만 실행되도록
posted_at을 찍는 Telegram bot.
각각의 테스트를 갖춘 분리된 프로듀서/컨슈머(producer/consumer) 구조입니다. 이 세 가지 모두가 동일한 세션 내에서 병합되고 배포되었습니다.
2. 정직함을 유지해야 했던 부분
ABI 검증. 락 품질(lock-quality) 신호는 "3일 후 락 만료"와 같은 플래그를 표시하기 위해 유동성 락의 _unlock date(해제 날짜)_를 읽어야 했습니다. 이는 온체인(on-chain) 상의 UNCX locker 컨트랙트를 읽어야 함을 의미합니다. Claude는 문서화된 tokenLocks(lpToken, index) ABI를 바탕으로 읽기 코드를 작성하려 했습니다. 저는 먼저 실제 컨트랙트와 구조체(struct)를 대조하여 검증하도록 만들었습니다. 우리는 locker의 글로벌 인덱스에서 실제 락이 걸린 토큰을 가져와 필드 순서를 신뢰하기 전에 실제 unlockDate를 디코딩했습니다. 보안 도구에서
"밀어붙이지 마세요(don't push)"라고 느낀 순간. 어느 시점에 Claude에게 PR(Pull Request)을 열어달라고 요청했는데, 곧바로 브랜치를 먼저 더 검토하고 싶다는 생각이 들었습니다. 하지만 Claude는 이미 PR을 열어버린 상태였습니다. 제가 "잠시만"이라고 말하자마자 몇 초 내에 이를 초안(draft)으로 전환했고, 제가 확인을 해주자 깔끔하게 닫았습니다. 복구 비용은 적게 들었지만, "PR을 열어라"라는 명령은 확인을 위한 한 박자의 여유가 필요한 외부 액션(outward action)이라는 점을 상기시켜 주었습니다.
3. 실제로 배포된 결과물
네 가지 새로운 시그널(signal)이 모두 라이브로 적용되었습니다:
- Mempool 임박 러그(imminent-rug) 경고 (위에서 설명한 파이프라인)
- Sybil 자금 조달 홀더(Sybil-funded holders) - CEX(중앙화 거래소)를 제외한 자금 조달 그래프 클러스터링 (funding-graph clustering)
- 락 품질(Lock quality) - 부분 락(partial lock) + 온체인에서 검증된 만료 예정 락(verified-on-chain expiring lock)
- 피싱 미끼(Phishing-bait) - 토큰의 온체인 이름에 포함된 URL / 클레임 채널 (claim-channel)
여기에 지원 작업도 포함되었습니다: 시그널 문서 카탈로그가 55페이지에서 105페이지로 늘어났으며(이제 분석기가 제기하는 모든 플래그에 대해 설명하는 페이지가 존재합니다), 앱의 UI 팔레트 및 간격(spacing) 리프레시 작업도 완료되었습니다.
7개의 리포지토리(repo)에 걸쳐 약 18개의 PR이 생성되었으며, 모두 테스트를 포함하여 일반적인 CI + 리뷰 파이프라인을 통해 병합되었습니다. Mempool 와처(watcher) 스위트는 2,496개의 테스트, 컨트랙트 분석기(contract analyzer)는 약 7,089개, 텔레그램 봇은 114개의 테스트를 보유하고 있습니다.
솔직한 성적표
에이전트(agent)가 강점을 보인 부분:
- 코드베이스 패턴 매칭. 새로운 코드가 기존 코드와 유사한 형태를 유지했습니다. 동일한 로거(logger) 구조, 동일한 포트/어댑터(port/adapter) 분리, 동일한 테스트 스타일을 따랐습니다.
- 테스트 규율. 모든 동작 변경에는 테스트가 수반되었으며, 실제 실패 사례를 바탕으로 반복 개선했습니다 (새로운 export를 추가했을 때 모의 설정(mocked-config) 테스트 몇 개가 깨졌는데, 에이전트가 이를 찾아내어 수정했습니다).
- 교차 서비스 배관(Cross-service plumbing). 맥락을 놓치지 않고 세 개의 리포지토리에 걸쳐 프로듀서/컨슈머(producer/consumer) 파이프라인의 형태를 유지했습니다.
나의 개입이 필요했던 부분:
- 주장을 현실에 근거시키기 (ABI를 실시간으로 검증할 것, 문서를 맹신하지 말 것).
- 오탐(false positives)으로만 나타나는 도메인 제약 사항 (CEX 제외 처리).
- 외부 액션 (아직 푸시하고 싶지 않았던 PR).
제가 드릴 수 있는 요약은 다음과 같습니다: 이 도구는 매우 빠르고 매우 직관적인 페어 프로그래머 (pair-programmer)이며, 당신이 '무엇을 (what)' 할지 명확히 정했다면 '어떻게 (how)' 할지에 대해 탁월한 능력을 발휘합니다. 그리고 보안 도구는 바로 당신이 여전히 '무엇을 (what)' 할지 결정권을 쥐고 있어야 하는 영역입니다.
rektradar.io의 무료 탐지기에 어떤 Ethereum 토큰 주소든 붙여넣어 이 신호들이 실시간으로 작동하는 것을 확인할 수 있습니다. 만약 신호 자체에 대한 제품 측면의 기술 문서를 원하신다면, 블로그에서 확인하실 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기