시냅스

Megazone ICON 2026 행사 후기

ted k — Fri, 3 Apr 2026 22:41:09 +0900

개요

megazone 및 협력사들의 솔루션 소개와 함께 AI Infra/보안 관련 세미나

세션

Megazone
AWS
Google Cloud
New Relic
Splunk
GitLab
Cloudflare 등

개인적으로 앞으로 회사에서 ML 서버를 둘 수도 있어 구축과 관련된 내용을 기대했으나 모든 연사가 이미 참석자들이 ML 서버를 갖추고 있음을 기초로 함

우리 회사도 근미래에 ML 서버를 도입한다면 적용할 수 있는 보안 혹은 observability 관련된 인사이트를 얻을 수 있었음

Main Session

Megazone

Megazone 은 AI 와 관련된 서비스를 제공하려는 노력을 하고 있음
- HALO
- AIR
AI 관련된 서비스를 제공할 때 유의한 “TRUST”
- T : Tracebility, 토큰 사용량, 감사 로깅
- R : Regulation, 역할, 조직별 정책, 모델/데이터/에이전트 별 권한 정책
- U : User Access, 사내 권한 체계 연동, RAG/MCP/Agent 접근 권한 제어
- S : Standardization, AI APP 개발/배포 표준
- T : Tooling, AI Gateway, Guardrails
megazone 은 AI Gateway 를 두고 권한 제어를 함
- 토큰 사용량
- 인증
- 유량제어
- LLM / MCP 등 AI 접근 권한
- Guardrails
  - 프롬프트가 AI 로 하여금 공격이 될 수 있는지 (prompt injection)
  - Data Leakage 차단
  - 윤리/규정 필터
- Audit Logs

Amorepacific

아모레는 글로벌 서비스를 하지만 모든 infra 는 국내에서 운영함
- 따라서 글로벌에서 문의가 있을 경우 D+1 에 응답하는 경우가 많아 AI 자동화를 도입함
HelpDesk 관점에서의 AI 사용
- HelpDesk 는 프로그래밍과 거리가 있기 떄문에 무조건 자연어로만 처리하도록 유도
- 기존 모든 질답을 분석 후 16개 유형으로 가공하여 데이터 제공
인프라 문의 관련
- 현재 인프라 문의할 때 AI 가 50% 이상을 대신 답변함
- RAG 기반 지식검색으로 자동 답변 (domain context)
- JIRA 와 연동하여 티켓 단위 관리
AI 실행 자동화 영역을 어떻게 구현할 것인가?
- 실제 업무 처리 까지 연결 필요
- 외부 시스템과 연동 (DB, Gialab DUO(문서 하단 참조), ISE)
- 자동화로 속도 향상

각주 : 다른 세션에서도 지속적으로 강조되는 사항은, AI 에게 도메인 지식을 부여하는 것(AI 성능은 모델보다 데이터 품질 + 컨텍스트 중요), 그에 따른 보안에 유의하는 것. 이번 세미나의 공통된 주제처럼 보였음

Learning Session

러닝 세션에서는 관심있는 세션으로 계속 옮겨 다니며 들었음

특히 만약 회사에 ML 서버가 들어온다면 어떻게 대응하는 것이 좋을까? 하는 관점으로 세미나에 참석하였음

다만 이번 세미나에서는 모델 자체에 대한 보안보다 ML 서버와 public internet 간의 관계에 대한 집중이 많았음

ChatGPT 쓰지 말라고만 할 건가요? AI 도입의 ‘적’이 아닌 ‘가드레일’이 되는 보안 전략

Check Point 사의 자사 솔루션을 소개하며 AI Guardrail 에 대한 소개

AI 시스템이 윤리적, 법적, 기술적 경계 내에서 작동하게 하는 메커니즘
모델의 input / output, 처리 등을 제어하는 정책 + 기술 + 모니터링 시스템
방지하는 위험 요소
- AI 환각
- 데이터 유출 (민감 정보, 직원의 개인정보 등)
- prompt injection
  - e.g. email 내에 난독화된 악성 코드를 삽입하여 email 을 요약하는 ai agent 가 실행하게 함

1. 보안 아키텍처의 변화와 여정 - 기존 IP 중심의 네트워크 보안에서 Cloud 와 GenAI 를 관통하는 Zero Trust 보안 : Zscaler

2. 실 운영을 바탕으로 살펴보는 제로트러스트 사례 : Cloudflare

위 두개 세미나는 비슷한 측면이 많아 한 데로 묶었음

줄이면, 자신들이 auth server 로 대응하며 public internet/다른 서버와 통신할 때 trust layer 로 동작하게 할 수 있다는 것이었음

Zscaler

cloudflare

두 회사 모두 자신들이 trust layer 가 돼서 auth 를 중개하겠다는 방식

다만 cloudflare 는 자신들이 “SASE” 라는 플랫폼을 통해 AI, MCP 등에 대한 접근을 제어해준다고 함

아마도 향후에는 AI GW 가 API GW 통합이 이뤄지지 않을까... 혹은 이미 이뤄지지 않았을까

구조
- User → Cloudflare (SASE) → LLM
역할
- 인증
- prompt injection 탐지
- guardrail
- audit logging

Observability 데이터 수집 전략부터 인시던트 관리까지 - AIOps Ready 아키텍처 설계 방향 제안

Splunk 사의 SplunkITSI 를 사용하면 할 수 있는 효과

로그 / 메트릭 / 트레이스를 통합 수집함
- 좋은 데이터를 수집하기 위해 로그도 잘 찍어야 함…
수집된 데이터로 할 수 있는 것
- AI가 평소 학습한 데이터를 토대로 아래와 같은 일들을 할 수 있음
- anomaly detection
- event correlation
  - 알람 100개여도 실제 원인이 1개라면 여러 이벤트 묶어서 알려 줌
- episode
  - 관련된 이벤트를 묶어서 보여 줌 (문제 단위로)
- root cause 분석
  - 서비스 dependency 기반으로 원인을 분석함
  - API latency, DB latency…

1. AI 시대의 소프트웨어 개발 변화와 애플리케이션 보안의 대응 : Black Duck

2. AI 시대의 개발 흐름: 코드부터 배포까지 하나로 연결하는 DevOps 표준 : GitLab

1번 세미나에서 하는 일들을 2번 세미나에서 모두 포함하고 있음

Black Duck

Black Duck 세미나의 주된 내용은 AI 가 학습한 코드가 취약점을 유발하거나 버그인 코드가 있으니 SCA 를 강화하기 위한 차원으로 AI 가 SCA 하겠다는 것, 개인적인 생각으론 Coderabbit 이 opensource 로 잘 활용되고 있는데 Black Duck 사의 제품을 왜 써야하지…? 라는 생각이 들었음, 아직 내가 제품에 대한 이해를 자세히 못한 듯

GitLab

위 구성에 대한 모든 일을 AI Agent 가 처리할 수 있음

GitLab Duo
- 대화형 prompt 를 통해서 AI Agent 가 직접 티켓을 발행하고, 작업하고 MR 을 올리면 SCA 를 돌려 코드 리뷰까지 수행하고 GitLab Runner 가 돌아가는 것 까지 시연으로 보았음…

회사에서 GitLab 을 쓰고 있어 굉장히 흥미로웠으나 역시 모델이 자사 코드에 대한 학습 우려가 컸음

GitLab Duo 가 프로젝트를 읽고 컨텍스트를 만들어 MCP 와 통신하거나 자체적으로 작업을 수행
이때 자사 코드에 대한 유출이 염려되었음
SLM 혹은 bedrock 을 도입하는 방향으로 가지 않을까...

정리

ICON 행사를 통해 얻은 insight

AI의 성공은 모델이나 인프라뿐만 아니라 데이터, 접근 제어, 보안, 그리고 운영 체계를 포함한 종합적 관점 필요
이를 위해 AI Gateway, Guardrails, Zero Trust, Observability, AIOps와 같은 요소들이 공통적으로 강조
결국 AI는 더 이상 도입하는 기술이 아니라 통제하고 운영해야 하는 시스템
앞으로 중요한 것은 ML 서버를 구축하는 것이 아니라 AI가 안전하게 동작할 수 있는 구조와 정책 그리고 전체 운영 아키텍처를 어떻게 설계할 것인가라는 점

Road to Web3 (24) 멱등성 상태머신: 결제 중복 방지로 오프체인 버그를 구조적으로 막기

ted k — Sun, 4 Jan 2026 17:11:15 +0900

이 글은 EVM 계열을 기준으로 설명합니다.

하지만 핵심은 체인이 아니라 오프체인 시스템 설계입니다.
온체인 결제를 붙이는 순간, 결제 서비스는 분산 시스템이 됩니다.
그리고 분산 시스템은 중복과 역전과 재시도와 지연을 기본 옵션으로 제공합니다.

0) 요약

온체인은 최종 원장이고, 오프체인은 제품 상태 머신이다
중복과 역전과 reorg까지 고려하려면 멱등성과 상태 전이를 강하게 설계해야 한다

1) 제가 처음 겪은 오프체인 착각 3가지

제가 처음 web3를 접할 때 했던 오해는 이렇습니다.

tx hash가 있으면 결제는 끝났다고 생각했다
이벤트 로그를 한 번 읽으면 그게 진실이라고 생각했다
실패하면 다시 보내면 된다고 생각했다

현실은

tx hash는 접수 번호에 가깝고
이벤트는 되돌릴 수 있으며
재시도는 비용과 부작용이 있다

입니다.

2) 멱등성: 같은 요청이 여러 번 와도 결과는 한 번만

web2 결제에서 멱등성 키를 쓰는 이유는 명확합니다.

네트워크 타임아웃
재시도
PG 웹훅 중복
서버 재시작

온체인 결제에서는 여기에 더해

RPC 재전송
멤풀 replace
체인 reorg
인덱서 재색인 backfill

이 추가됩니다.

즉, 멱등성 키는 선택이 아니라 생존 장비입니다.

2.1 멱등성 키는 무엇으로 잡나

실무에서는 보통 2단계를 분리합니다.

외부 요청 키: client request id
결제 증빙 키: chain id + tx hash 또는 message id

한 줄로 말하면

사용자의 의도 식별자와 체인의 증빙 식별자를 분리해서 둘 다 멱등 처리한다

입니다.

참고
web2에서와 마찬가지로 멱등키는 외부에서 유출이 어렵게 설계하는 편이 안전합니다. client request id는 UUIDv4 같은 충분히 랜덤한 값으로 만들면 현실적으로 추측이 어렵습니다. 다만 트랜잭션 해시 tx hash는 추측은 어렵지만, 네트워크에 전파된 이후에는 노드나 인덱서가 관측할 수 있는 공개 정보가 될 수 있습니다. 그래서 멱등키는 중복 처리 방지용 식별자로 쓰고, 인증이나 권한 부여 목적의 비밀 토큰처럼 쓰지는 않는 것이 좋습니다.

3) 상태 머신: 결제와 제공을 한 문장으로 묶지 말기

web2 결제에서 가장 위험한 문장은 이것입니다.

결제가 되면 제공한다

온체인에서는 결제가 된다의 의미가 여러 층이기 때문입니다.

submitted: 브로드캐스트 성공
pending: 멤풀 대기
included: 블록 포함
confirmed: N 블록 쌓임
final: 되돌리기 어려움 또는 최종성 기준 충족

따라서 제공 정책도 상태 기반이어야 합니다.

포함 시에 미리 제공할 것인가
확인 후에 제공할 것인가
최종성 이후에 제공할 것인가

4) 오프체인에서 터지는 실전 버그 6가지와 처방

4.1 중복 처리

상황

같은 tx를 인덱서가 두 번 전달
서비스가 두 번 제공

처방

fulfillment는 반드시 단일 테이블에서 원자적 upsert로 처리
제공은 payment id 기준으로 유니크 제약을 둔다

4.2 누락

상황

특정 블록 범위를 읽다가 장애로 구멍이 생김
고객은 결제했는데 제공이 안 됨

처방

커서 기반 소비 cursor와 주기적 backfill
지표로 gap을 감지

4.3 reorg로 인한 취소

상황

included로 보고 제공했는데, reorg로 tx가 사라짐

처방

confirmation buffer를 둔다
빠른 UX가 필요하면 부분 제공과 사후 회수 정책을 문장으로 고정한다

4.4 순서 역전

상황

이벤트는 블록 순서로 오지만, 처리 큐에서 역전됨
상태가 되돌아가거나 중간 상태가 덮임

처방

상태 전이는 단조 증가 monotonic 해야 한다
상태 업데이트는 이전 상태보다 낮으면 무시

4.5 재시도 폭주

상황

pending이 길어지자 자동 재시도가 폭주
같은 nonce 또는 같은 메시지가 난사
비용과 지연이 커짐

처방

재시도는 큐 기반으로 제한
실패 원인별 정책
사용자 의도 없는 자동 재시도는 제한

4.6 환불과 제공의 레이스

상황

고객지원이 환불을 처리하는 동안 제공이 진행
또는 반대로 제공 후 환불이 자동 처리

처방

결제와 제공, 환불을 하나의 상태 머신으로 합친다
승인, 제공, 환불은 각각의 전이 조건을 가진다

5) web2 결제와 비교: 공통점과 차이점

공통점

멱등성 키는 필수다
상태 머신은 필수다
웹훅과 폴링, 재시도는 기본 실패 모델이다

차이점

차지백이나 네트워크 차원의 강제 롤백이 기본으로 없다
실패해도 프로토콜 수수료가 나갈 수 있다
확정은 하나가 아니라 단계다
인덱싱 대상이 분산되어 있고, 재색인이 자연스러운 운영 행위다

6) 실전 구현 스케치: Spring 개발자 관점

핵심 테이블 3개만 있으면 구조가 잡힙니다.

1) payment_intent

client_request_id unique
amount, currency, customer
status: created, awaiting_proof, fulfilled, cancelled

2) payment_proof

chain_id + tx_hash unique
block_number, log_index
status: seen, included, confirmed, final, orphaned

3) fulfillment

payment_intent_id unique
status: ready, done, reversed
delivered_at, reversed_at

처리 루프

인덱서가 proof를 upsert
상태 전이를 단조 증가로 업데이트
fulfillment는 정책에 맞는 상태에서만 전이

7) 결론

온체인 결제를 붙이면 오프체인에서 중복과 역전과 되돌림을 관리해야 한다
멱등성 키는 외부 의도와 체인 증빙을 분리해 두 겹으로 잡는 편이 안전하다
상태 머신은 결제와 제공, 환불을 하나로 묶어야 실전 버그를 막는다

Road to Web3 (23) 토큰 이코노미 정책: 수수료 환불 차지백 부재를 제품에 반영

ted k — Sun, 4 Jan 2026 16:53:36 +0900

이 글은 EVM 계열을 기준으로 설명합니다.

목표는 토큰 가격 얘기가 아니라, 결제와 정산 정책을 제품 언어로 번역하는 것입니다.
web2 결제 개발자가 온체인 결제를 붙일 때 가장 크게 부딪히는 구간이 바로 여기입니다.

0) 요약

온체인 결제는 승인과 정산이 하나로 붙어 있고, 되돌리기와 차지백이 기본 기능이 아니다
그래서 환불, 수수료, 분쟁 처리를 제품이 직접 설계해야 한다

1) 수수료는 누가 내나: 고객, 가맹점, 프로토콜

web2 결제에서는 수수료 구조가 어느 정도 표준화되어 있습니다.
하지만 온체인에서는 수수료가 두 갈래로 분해됩니다.

네트워크 수수료: 블록 공간과 실행 자원 비용
서비스 수수료: 제품이 부과하는 플랫폼 또는 사용료

즉, 결제 1건의 비용은

프로토콜 비용 + 서비스 비용

입니다.

그리고 중요한 차이가 있습니다.

프로토콜 비용은 실패해도 발생할 수 있다
서비스 비용은 정책에 따라 환불 가능하다

2) 환불은 어떻게 정의되나: 되돌리기와 별개다

여기서 제가 처음 web3를 접할 때 했던 오해는 이렇습니다.

환불은 결제 트랜잭션을 되돌리는 것이라고 생각했다

하지만 온체인에서는 일반적으로 직렬화 되어있기 때문에

되돌리기 rollback 라는 개념이 아니라
별도의 반대 방향 트랜잭션을 만드는 것

이 환불입니다.

즉, 환불은 보통

환불 트랜잭션이라는 새 결제

입니다.

그래서 환불을 설계하려면 다음이 필요합니다.

환불 가능한 조건과 기간
환불 시 수수료 부담 주체
환불 주소가 동일한지 여부
환불이 부분 환불인지 전체 환불인지
환불이 자동인지 수동인지

web2 비유로는

승인 취소가 아니라 매입 취소 또는 환불 전표를 새로 발행하는 것

에 더 가깝습니다.

3) 차지백이 없다는 말의 진짜 의미

차지백은 단순 환불이 아닙니다.
차지백은

네트워크나 카드사 같은 상위 권위가 개입해서
거래를 강제로 뒤집고
분쟁을 중재하는 절차

입니다.

온체인 결제에서 흔히 말하는 차지백 부재는

상위 권위가 강제로 뒤집어 주는 채널이 기본으로 없다

는 뜻입니다.

그래서 분쟁 처리 방식은 보통 3개로 갈립니다.

1) 제품이 환불 권한을 가진다

고객지원과 정책으로 해결

2) 에스크로 또는 분쟁 컨트랙트를 쓴다

조건 충족 시 자동 분배
또는 중재자 역할을 컨트랙트로 모델링

3) 아예 비가역 결제로 간다

디지털 재화나 즉시 제공 서비스에 더 적합

제품 정책 질문

분쟁이 났을 때 누가 판정자 역할을 하는가
제공이 끝난 서비스는 환불 가능한가
사기 거래를 어떻게 탐지하고 차단할 것인가

4) 토큰 경제는 가격이 아니라 상태 머신이다

토큰 이코노미라는 단어가 나오면 가격과 투자 얘기로 빠지기 쉽습니다.
하지만 제품 입장에서는 이게 더 중요합니다.

토큰은 결제 수단인 동시에, 상태와 권한을 표현하는 매개체가 될 수 있다

예를 들어

구독권 토큰: 보유하면 기능 접근
크레딧 토큰: 소모하면 사용량 차감
스테이킹: 예치하면 보상 또는 신뢰 점수

즉, 토큰은

요금제 데이터 모델

로 쓰일 수 있습니다.

web2에서는 이 역할을 보통

포인트
쿠폰
구독 상태
크레딧 잔액

이 담당합니다.

온체인에서는 이것이

공개 검증 가능한 상태

로도 구현될 수 있다는 차이가 있습니다.

5) 제품 설계 프레임: 결제 정책을 문장으로 고정하기

여기부터가 실무적으로 가장 유용합니다.
정책을 코드보다 먼저 문장으로 고정해야 합니다.

아래 질문에 답하면 제품 정책이 거의 완성됩니다.

5.1. 비용

가스비는 사용자, 서비스, 또는 분담 중 누구인가
실패 가스비를 보조할 것인가
서비스 수수료는 고정인가 비율인가

5.2. 환불

환불 가능 기간은 얼마인가
환불 시 가스비 부담은 누구인가
환불 주소는 원 결제 주소로 고정할 것인가
부분 환불을 허용할 것인가

5.3. 분쟁

차지백이 없으니 분쟁은 어디서 처리하나
에스크로가 필요한가
사기 거래는 어떤 기준으로 차단하나

5.4. 확정

몇 confirmations 이후 제공할 것인가
L2라면 소프트 확정과 하드 확정을 어떻게 다룰 것인가

6) 실전 예시: 결제 서비스에 바로 넣을 수 있는 정책

아래는 제품 문서나 고객지원 문구로 바로 쓸 수 있는 형태입니다.

결제는 블록 포함 이후 처리되며, 서비스 제공은 N confirmations 이후 시작됩니다
결제 실패 시 네트워크 수수료는 환불되지 않을 수 있습니다
환불은 별도의 환불 트랜잭션으로 처리되며, 환불 수수료는 정책에 따릅니다
분쟁은 온체인 차지백이 아니라 고객지원 절차로 처리됩니다
의심 거래는 자동 보류되며 추가 확인 후 처리됩니다

7) 결론

온체인 결제는 승인과 정산이 한 번에 커밋되는 구조에 가깝다
차지백 부재는 기술 문제가 아니라 제품 정책이 떠안는 책임이다
토큰 이코노미는 가격이 아니라 상태 머신으로 설계해야 한다

Road to Web3 (22) 멀티체인 기초: EVM vs SVM 서명 주소 트랜잭션

ted k — Sun, 4 Jan 2026 12:40:09 +0900

이 글은 Ethereum 및 EVM 계열, 그리고 Solana의 SVM을 기준으로 설명합니다.

목표는 둘 중 어느 쪽이 더 낫다를 말하는 것이 아니라, 멀티체인 지원이 왜 난이도 폭증인지 운영 관점에서 이해하는 것입니다.

0) 요약

EVM은 계정 nonce 기반 직렬화와 컨트랙트 호출 중심
SVM은 트랜잭션에 명시된 계정 집합과 병렬 실행 중심

같은 결제나 서명 기능을 만든다고 해도

키 타입
주소 표현
서명 포맷
트랜잭션 구조
실패 모델
인덱싱 방법

이 전부가 달라집니다.

1) 서명부터 다르다: secp256k1 ECDSA vs Ed25519

1.1 EVM의 기본 서명

보통 secp256k1 ECDSA
해시 함수는 Keccak-256 계열을 많이 사용
트랜잭션 서명은 chain id와 nonce를 포함한 특정 인코딩을 서명한다

1.2 SVM의 기본 서명

보통 Ed25519
트랜잭션은 메시지 바이트열을 만들고, 거기에 여러 서명이 붙는 형태가 일반적이다

1.3 멀티체인에서 폭발하는 포인트

키가 다르면 하드웨어 지갑과 라이브러리 스택이 갈라진다
서명 검증 로직도 갈라진다
동일한 서명 증거라는 말이 체인마다 다른 바이트 레벨 의미를 가진다

2) 주소도 다르다: 20바이트 vs 32바이트

2.1 EVM 주소

공개키에서 파생된 20바이트 주소를 주로 사용
보통 16진수 문자열로 표시한다

2.2 Solana 주소

공개키 자체가 32바이트로 주소 역할을 한다
보통 base58 문자열로 표시한다

2.3 운영상 함정

UI 입력 검증이 체인별로 완전히 다르다
체크섬, 대소문자 규칙, 인코딩이 서로 다르다
같은 문자열이라도 체인에 따라 유효 여부가 갈린다

3) 트랜잭션이 완전히 다르다: 호출 중심 vs 인스트럭션과 계정 목록

여기서부터 멀티체인이 진짜 어렵습니다.
동일한 결제를 한다고 해도 트랜잭션이 담는 정보가 구조적으로 다릅니다.

3.1 EVM 트랜잭션의 생각 방식

EVM에서 트랜잭션은 보통 다음을 담습니다.

from, to
value
data: 컨트랙트 호출 데이터
gas 관련 필드
nonce

즉, 한 문장으로

어떤 주소로 무엇을 호출할지와, 얼마를 보낼지를 담는다

입니다.

3.2 SVM 트랜잭션의 생각 방식

SVM에서 트랜잭션은 대략 이렇게 보입니다.

최근 블록 해시 또는 nonce 계열 참조값
여러 개의 instruction
instruction마다 프로그램 id와 계정 목록
여러 서명자

즉, 한 문장으로

어떤 프로그램을 실행할지와, 실행에 필요한 계정들을 명시적으로 나열한다

입니다.

4) 동시성과 직렬화가 다르다: nonce 큐 vs 계정 락

4.1 EVM은 계정 단위 직렬화가 기본

같은 EOA에서 보낸 트랜잭션은 nonce 순서로 직렬화된다
멤풀에서도 nonce 갭이 있으면 뒤 nonce 트랜잭션은 막히기 쉽다

4.2 SVM은 계정 집합을 기준으로 병렬 실행을 시도

트랜잭션이 어떤 계정들을 읽고 쓰는지 명시한다
읽기 전용과 쓰기 계정이 충돌하지 않으면 병렬로 실행될 수 있다
충돌하면 그 계정 집합에 대한 락처럼 동작하며 순서가 생긴다

즉

EVM은 순서가 먼저고, 그 순서를 맞추는 것이 기본
SVM은 병렬이 먼저고, 충돌하는 부분만 순서가 생기는 방식

입니다.

web2 비유로 바꾸면

EVM은 하나의 사용자 세션에 대해 단일 스레드로 커밋 로그를 만드는 방식
SVM은 테이블 또는 레코드 집합을 잠그고 충돌이 없으면 병렬 커밋을 허용하는 방식

에 더 가깝습니다.

5) 토큰도 같아 보이지만 다르다: ERC-20 vs SPL Token

5.1 EVM의 토큰

토큰은 컨트랙트다
전송은 transfer 함수 호출이다
잔액은 컨트랙트 스토리지에 저장된다

5.2 Solana의 토큰

토큰은 프로그램과 계정 레이아웃으로 표현된다
사용자는 보통 token account라는 별도 계정을 가진다
전송은 토큰 프로그램에 대한 instruction 호출이다

5.3 멀티체인 지원에서 생기는 문제

같은 USDC라도 체인마다 다른 인스턴스다
체인마다 잔액 조회 방식, 이벤트 인덱싱 방식이 달라진다
입금 주소 생성, 최소 단위, 소수점, 수수료 단위가 달라진다

6) 메시지 서명도 다르게 읽힌다: 서명 증거 설계가 갈린다

x402처럼 메시지 서명 기반 증거를 쓰는 설계에서는 특히 중요합니다.

6.1 EVM 쪽에서 흔한 선택지

사람이 읽는 메시지 서명
구조화된 데이터 서명
둘 다 도메인 분리와 컨텍스트 바인딩이 핵심이다

6.2 Solana 쪽에서 흔한 선택지

지갑이 제공하는 signMessage, signTransaction의 의미가 다르고
프로그램과 계정 목록이 포함되는 서명 흐름이 자주 등장한다

멀티체인에서 가장 흔한 사고는 이겁니다.

서명은 동일한 승인으로 보이지만, 실제로는 체인별로 다른 범위와 의미를 가진다

그래서 오프체인 서명 증거는

체인 id 또는 네트워크 식별자
서비스 도메인
리소스 범위
nonce
만료 시간

을 반드시 포함시키는 쪽이 안전합니다.

7) 멀티체인 난이도가 폭증하는 체크리스트

아래 항목 중 하나만 달라도 난이도가 크게 증가합니다.

구분	EVM 계열	SVM 계열
서명	secp256k1 ECDSA	Ed25519
주소	20바이트 파생	32바이트 공개키
트랜잭션	nonce, gas, calldata	blockhash, instructions, account list
실행 모델	전역 직렬화 성격 강함	계정 충돌 기반 병렬
토큰	컨트랙트 스토리지	프로그램 + token account
인덱싱	로그 이벤트 중심	계정 변화와 프로그램 로그 혼합

그리고 서비스 팀이 실제로 겪는 문제는 보통

체인별 지갑 연결 UX가 다르다
체인별 수수료 단위와 실패 메시지가 다르다
체인별 재시도와 확정 정책이 다르다
체인별 인덱서가 따로 필요하다

로 요약됩니다.

8) 결론: 멀티체인은 기능 추가가 아니라 제품 2개를 만드는 일에 가깝다

EVM과 SVM은 표면적으로는 둘 다 지갑 서명과 트랜잭션 전송이지만
바이트 레벨, 계정 모델, 실패 모델, 운영 모델이 다르다

그래서 멀티체인을 한다는 말은

지갑 및 서명 스택을 복수로 운영하고
인덱서 및 모니터링을 복수로 운영하고
제품 정책과 상태 머신을 체인별로 분기

한다는 뜻에 가깝습니다.

Road to Web3 (21) MEV 입문: 프런트런 샌드위치와 순서의 경제학

ted k — Sun, 4 Jan 2026 12:25:26 +0900

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

MEV는 한 문장으로 정리하면 이렇습니다.

같은 트랜잭션 집합이라도 어떤 순서로 실행하느냐에 따라 추가 이익이 생기고, 그 이익을 두고 경쟁이 벌어진다

web2 개발자에게는 이렇게 번역하는 편이 더 정확합니다.

전 세계가 공유하는 커밋 로그에서, 커밋 순서를 두고 생기는 경제적 경쟁

1) MEV가 왜 생기나: 락 대신 전역 직렬화의 부작용

EVM은 블록 안에서 트랜잭션을 순서대로 실행합니다.
이 순서는 가치에 영향을 줍니다.

DEX 가격은 먼저 실행한 거래에 의해 바뀐다
청산 liquidation은 먼저 잡은 사람이 보상을 가져간다
아비트리지 arbitrage는 먼저 맞춘 사람이 수익을 가져간다

즉, 블록은 단순 저장이 아니라

상태를 바꾸는 실행 순서표

입니다. 이 순서표를 통제하거나 예측할 수 있으면 돈이 됩니다.

2) 용어 정리: MEV, 프런트런, 샌드위치

2.1 MEV

MEV는 Maximal Extractable Value의 약자로 쓰입니다.
원래는 Miner Extractable Value였는데, PoS로 넘어오며 표현이 바뀐 맥락이 있습니다.

블록에 어떤 트랜잭션을 넣고, 어떤 순서로 넣을지 선택할 수 있을 때 발생하는 추가 이익

여기서 주의할 점은

MEV 자체는 현상이다
그중 일부가 공격이나 착취로 보일 수 있다

입니다.

2.2 프런트런 front run

누군가의 트랜잭션을 보고, 그보다 먼저 실행되도록 끼어드는 행위입니다.
가장 흔한 전개는

멤풀에서 대기 중인 대형 스왑을 보고
그보다 더 높은 수수료로 먼저 실행되게 올린다

2.3 샌드위치 sandwich

프런트런과 백런 back run을 결합한 형태입니다.

공격자가 먼저 매수하여 가격을 올리고
피해자의 스왑이 그 비싼 가격으로 체결되게 만든 뒤
공격자가 마지막에 매도하여 차익을 회수

피해자는 보통

슬리피지 허용치가 넓을수록 더 크게 당한다

3) 샌드위치가 어떻게 가능한가: 간단한 실행 흐름

DEX는 자동화된 시장 조성자 AMM 모델을 많이 씁니다.
여기서는 가격이 주문장이 아니라 풀의 비율로 결정됩니다.

따라서 순서가 바뀌면

피해자의 체결 가격이 바뀐다
공격자의 차익이 생긴다

web2 비유로는 이런 쪽에 가깝습니다.

거래소 주문장 기반 시장에서, 누군가의 큰 시장가 주문을 보고 먼저 선행 주문을 넣어 스프레드를 먹는 행위
또는 지연 시간 차이를 이용한 latency arbitrage

차이는 블록체인은

커밋 로그가 전 세계 공개로 공유되고
결제 취소나 차지백이 기본으로 없고
누가 먼저 들어가느냐가 수수료 경쟁으로 정해질 수 있다

입니다.

4) 누가 순서를 결정하나: MEV 공급망

많은 사람들이 MEV를

검증자가 마음대로 순서를 바꾸는 문제

로만 이해합니다.
하지만 현실은 분업되어 있습니다.

대략 이런 플레이어가 등장합니다.

사용자: 지갑에서 트랜잭션 생성
RPC 노드: 네트워크로 브로드캐스트
멤풀: 각 노드의 대기열
서처 searcher: 멤풀을 보고 수익 기회를 찾는 봇
빌더 builder: 서처 번들을 모아 블록 후보를 조립
프로포저 proposer: 실제 블록 제안 권한을 가진 검증자 역할
릴레이 relay: 빌더와 프로포저 사이 중개

핵심은 이겁니다.

많은 MEV는 멤풀 가시성에서 시작되고
그 다음은 블록 구성 권한과의 협상 문제로 이어진다

5) 서비스에 어떤 문제가 생기나

5.1 사용자가 예상한 가격으로 체결되지 않는다

DEX 스왑 UX에서 가장 흔합니다.

사용자는 가격이 변할 수 있다는 사실을 알고도 진행하지만
공격이 끼면 변동이 구조적으로 확대된다

그래서 슬리피지는 단순 UX 옵션이 아니라 공격 표면이 됩니다.

5.2 결제형 트랜잭션의 순서 민감도가 올라간다

x402 같은 모델에서 온체인 결제로 증거를 삼는다면

결제 트랜잭션이 블록에 언제, 어떤 순서로 들어가느냐

가 제품 SLA에 영향을 줍니다.

5.3 청산, 경매, 배치 실행에서 순서 경쟁이 직접 비용이 된다

예를 들어

담보 청산 시스템은 레이스가 붙으면 가스비가 급등한다
경매는 봇 경쟁이 붙으면 참여 비용이 급등한다

web2로 바꾸면

동일한 이벤트를 처리하는데, 경쟁이 붙어서 네트워크 비용이 튀는 상황

입니다.

6) 방어 전략: 서비스는 어디를 단단하게 해야 하나

MEV를 완전히 없애는 건 어렵습니다.
대신 공격 표면을 줄이는 쪽으로 접근합니다.

6.1 슬리피지와 가격 보호

슬리피지 허용치를 최소화
가격 보호 기능과 미리보기 강제
대형 스왑은 분할 실행 또는 TWAP류 전략 고려

6.2 프라이빗 오더 플로우

멤풀에 공개되면 관찰당할 수 있습니다.
그래서

트랜잭션을 공개 멤풀로 보내지 않고
프라이빗 릴레이나 번들 채널로 전달

하는 방식이 등장합니다.

이때 제품적으로 중요한 점은

프라이빗 라우팅은 성공률과 검열 리스크 같은 새로운 실패 모드를 만든다

입니다.

6.3 커밋 리빌 commit reveal 패턴

값을 바로 공개하지 않고

커밋 단계에서는 해시만 올리고
리빌 단계에서 실제 내용을 공개

하는 방법입니다.

장점

멤풀 관찰 기반 프런트런을 줄인다

단점

2단계 UX와 타임아웃, 실패 처리 상태 머신이 필요하다

6.4 배치 경매 또는 순서 무력화 설계

어떤 서비스는 아예

같은 블록 안의 순서를 약화시키는 경매나 배치 방식

을 설계합니다.
web2로 말하면

연속 거래가 아니라 콜 옥션처럼 묶어서 체결하는 방식

에 가깝습니다.

7) 결론

블록체인은 전역 직렬화를 만들기 때문에, 순서 자체가 돈이 된다
MEV는 채굴자나 검증자만의 문제가 아니라, 멤풀 가시성과 블록 구성 분업 구조에서 발생한다
서비스 관점에서는 슬리피지, 프라이빗 라우팅, 커밋 리빌, 배치 설계로 공격 표면을 줄여야 한다
web2의 주문장 선행매매나 지연 시간 아비트리지와 닮았지만, 커밋 로그 공개성과 되돌리기 어려움 때문에 제품 리스크가 더 직접적이다

Road to Web3 (20) 지갑 키 관리 실전: 핫 웜 콜드, 시드 HD, MPC 개요

ted k — Sun, 4 Jan 2026 12:14:05 +0900

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

이번 편의 목표는 한 문장입니다.

키를 어떻게 보관하고 서명할지의 선택이 곧 서비스 아키텍처와 운영 리스크를 결정한다

이 글은 세 축을 다룹니다.

핫 웜 콜드 지갑을 언제 어떻게 나누는가
시드와 HD 지갑이 왜 기본값이 되었는가
MPC가 무엇을 해결하고 무엇을 해결하지 못하는가

제가 처음 키 관리 얘기를 들을 때 했던 오해는 이렇습니다.

지갑은 앱이고, 키는 그냥 파일 같은 것이다
키를 잘 숨기면 끝이고, 보안은 암호학 문제다
서비스는 어차피 서버가 처리하니 지갑은 하나면 된다

현실은 이렇습니다.

키는 비밀이면서 동시에 권한이다. 권한 설계가 곧 보안 설계다
키를 온라인에 두면 운영 편의는 올라가지만 공격 표면도 같이 커진다
지갑을 나누는 이유는 성능이 아니라 피해 반경을 줄이기 위해서다

web2 결제 시스템 비유로 말하면

핫 지갑은 즉시 승인과 출금이 가능한 운영 계정
콜드 지갑은 금고에 있는 원장 보관 계정
웜 지갑은 금고와 운영 계정 사이의 중간 금고 역할

0) 한 번만 고정하는 위협 모델

이 글에서 최소 전제는 아래입니다.

서버가 뚫릴 수 있다
내부자 실수나 악의가 있을 수 있다
키가 유출되면 되돌리기 어렵다
체인 트랜잭션은 승인 취소나 차지백이 기본으로 없다

따라서 목표는 완벽이 아니라 피해 반경과 사고 대응 시간을 늘리는 것입니다.

1) 핫 웜 콜드 지갑: 돈의 흐름이 아니라 권한의 경계

핫 웜 콜드는 온도라기보다 연결성의 단계입니다.

구분	온라인 연결	서명 속도	권장 용도	사고 시 피해
핫	상시	매우 빠름	소액 출금, 즉시 처리	크게
웜	제한적	빠름	리밸런싱, 배치 출금	중간
콜드	오프라인	느림	트레저리, 장기 보관	작게

핵심은 이겁니다.

핫에서 모든 것을 처리하면 편하지만, 해킹 시 전액 손실이 가능하다
콜드만 쓰면 안전하지만, 운영이 불가능할 정도로 느리다
웜은 리스크와 속도의 타협점이다

1.1 실무 패턴: 잔고 상한과 스윕

핫 지갑에는 상한을 둡니다.

예: 운영 상한 10 ETH
초과분은 주기적으로 웜이나 콜드로 스윕

1.2 실무 패턴: 출금은 상태다

출금은 단일 API가 아니라 상태로 다뤄야 합니다.

요청 접수
위험 평가와 정책 적용
서명 생성
브로드캐스트
확정 정책 충족
사용자 통지
회계 반영

핫 지갑은 이 상태 머신의 서명 단계를 빠르게 하지만, 동시에 사고를 빠르게 만듭니다.

2) 키를 어디에 두는가: 키 저장소 옵션 5개

옵션	요약	장점	단점
앱 내 키	지갑 앱이 키를 저장	간단	디바이스 보안에 의존
서버 키	백엔드가 키 보유	자동화 쉬움	서버 침해 시 치명적
HSM	하드웨어 보안 모듈	추출 난이도 상승	비용과 운영 복잡
멀티시그	여러 키의 합의	단일 키 리스크 감소	서명 절차가 느림
MPC	키를 조각내 분산 서명	키 단일 보관을 피함	구성과 복구가 어렵다

서비스 관점에서 제일 흔한 조합은

핫: 서버 키 또는 MPC
웜: 멀티시그 또는 MPC
콜드: 오프라인 멀티시그 또는 콜드 보관

입니다.

3) 시드와 HD 지갑: 주소가 많아도 백업은 하나로 끝내는 방법

3.1 시드란 무엇인가

지갑에서 흔히 말하는 시드는 보통

니모닉 문구로 표현되는 비밀값

입니다. 니모닉은 사람이 적어둘 수 있게 만든 표현이고, 핵심은 그 뒤의 시드 비트열입니다.

3.2 HD 지갑이란 무엇인가

HD는 Hierarchical Deterministic 입니다.

하나의 시드에서
무수히 많은 개인키와 주소를 파생한다

여기서 결정적이라는 말은

같은 시드면 같은 키 트리가 다시 만들어진다

는 뜻입니다.

참고 : 키 파생에 대한 자세한 설명
니모닉으로부터 KDF로 seed 64바이트를 만들고, seed에서 HMAC-SHA512로 마스터 키 재료 32바이트와 chain code 32바이트를 만든 뒤, 각 노드에서 chain code를 HMAC의 key로 사용하고 index 0,1,2… 를 HMAC 입력에 넣어 매번 새로운 64바이트 출력을 얻어 그중 32바이트로 EC 연산을 통해 자식 개인키를 만들며, 동시에 나머지 32바이트는 다음 노드의 chain code로 갱신되면서 트리로 확장된다.

3.3 왜 서비스와 사용자 모두 HD를 좋아하나

백업이 단순하다. 니모닉 하나
주소를 재사용하지 않기 쉬워져 프라이버시가 개선된다
계정과 주소를 논리적으로 분리할 수 있다

참고: hardened 파생은 슬래시 경로에서 h 표기로 자주 씁니다.
예: m/44h/60h/0h/0/i

4) MPC 개요: 키를 나누고 서명은 같이 한다

MPC는 참여자들이 DKG 같은 분산 키 생성으로 개인키가 단일 지점에 나타나지 않게 secret share를 만들고 이를 인증된 암호화 채널로 교환해 각자 보관한 뒤, secure computation으로 임계치 t of n에서만 ECDSA와 동일하게 검증되는 정상 서명을 합성하는 분산 서명 프로토콜이다.

4.1 MPC가 해결하려는 문제

서버가 키를 한 번이라도 완전한 형태로 갖는 순간

침해 시 손실이 커진다

MPC는 이를 줄이기 위해

개인키를 여러 조각으로 나누고
각 조각이 부분 연산을 수행해
최종 서명만 합성되게

만듭니다. 목표는

어떤 단일 노드도 완전한 키를 가지지 않게 하기

입니다.

4.2 멀티시그와 MPC의 차이

멀티시그는 온체인 정책입니다.

트랜잭션 자체가 여러 서명을 요구한다

MPC는 오프체인 서명 방식입니다.

체인에는 일반 EOA 서명처럼 보일 수 있다

따라서 차이는 운영에 직접 반영됩니다.

비교	멀티시그	MPC
체인 상 가시성	여러 서명이 보인다	일반 서명처럼 보일 수 있다
통합 난이도	온체인 컨트랙트 필요	오프체인 시스템 필요
장애 모델	서명자 부재가 지연	조각 노드 장애가 지연
복구	서명자 교체로 대응	키 조각 재구성이 핵심

4.3 MPC가 해결하지 못하는 것

정책 자체가 없으면 키 분산만으로는 사고를 막지 못한다
충분한 임계치 조합이 탈취되면 끝이다
운영 실수, 잘못된 출금 정책은 MPC로도 막기 어렵다

즉, MPC는 보안의 전부가 아니라

키 보관 방식의 선택지

입니다.

결론

핫 웜 콜드는 돈을 나누는 게 아니라 권한과 피해 반경을 나누는 설계다
HD 지갑은 주소 수와 무관하게 백업과 운영을 단순하게 만든다
MPC는 단일 키 보관을 피하지만, 정책과 운영 절차 없이는 완전한 해결책이 아니다

Road to Web3 (19) 스마트컨트랙트 보안 기본 2: 업그레이드 프록시 권한 운영 리스크

ted k — Sat, 3 Jan 2026 22:23:27 +0900

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

이번 편의 목표는 한 문장입니다.

온체인 보안의 대형 사고는 취약한 코드 한 줄보다, 업그레이드와 권한과 운영 절차의 빈틈에서 더 자주 터진다

이 글은 세 축을 다룹니다.

업그레이드 프록시
권한 설계
운영 리스크와 사고 대응

제가 처음 업그레이드 가능한 컨트랙트를 접할 때 했던 오해는 이렇습니다.

코드는 체인에 박히니 운영자가 바꿀 수 없다
업그레이드를 넣으면 그냥 편해진다
권한은 어드민만 안전하게 관리하면 된다

현실은 이렇습니다.

업그레이드 가능성을 넣는 순간, 코드 보안이 아니라 운영 보안이 주 리스크가 된다
어드민 키가 뚫리면, 코드가 아무리 깔끔해도 끝난다
업그레이드는 기능 배포이면서 동시에 자산 관리자 권한 행사다

web2로 번역하면

업그레이드 프록시는 DB 스키마는 그대로 두고 애플리케이션 로직만 핫스왑하는 구조와 닮아 있다
권한 키는 마스터 비밀번호나 루트 계정과 비슷하다
운영 리스크는 배포 파이프라인과 접근 통제, 변경관리의 문제다

0) 기본 용어: 프록시와 구현 컨트랙트

업그레이드 프록시는 흔히 이렇게 구성됩니다.

proxy: 사용자 요청을 받는 주소, 상태 storage를 보관
implementation logic: 실제 코드, 실행 로직
admin: proxy가 가리킬 implementation을 바꾸는 주체

사용자는 proxy 주소만 보게 됩니다.
proxy는 호출을 구현 컨트랙트로 위임하고, 상태는 proxy에 쌓입니다.

1) 왜 업그레이드가 위험해지나: 신뢰 경계가 바뀐다

업그레이드를 허용하면 다음 문장이 성립합니다.

동일한 주소가 내일은 다른 코드가 된다

즉, 사용자가 신뢰하는 대상이

코드
에서
운영 주체의 변경 행위

로 이동합니다.

이게 위험한 이유는 두 가지입니다.

1) 공격자는 컨트랙트 버그를 찾을 필요가 없고, 키를 훔치면 된다
2) 운영 실수 하나가 곧바로 자산 손실로 연결된다

2) 업그레이드 방식 대표 3개

2.1 Transparent proxy

사용자 호출은 implementation으로 위임하고, admin만 업그레이드 함수를 호출합니다.
admin이 일반 함수를 호출하면 충돌을 피하기 위해 막아두는 패턴이 많습니다.

2.2 UUPS

proxy는 단순하고, implementation 쪽에 업그레이드 로직이 들어갑니다.
upgrades가 구현에 의존하므로, 업그레이드 함수의 검증 로직이 더 중요해집니다.

2.3 Beacon proxy

여러 proxy가 하나의 beacon을 통해 같은 implementation을 참조합니다.
대규모 시스템에서 유용하지만, beacon이 단일 실패점이 될 수 있습니다.

중요한 공통점

업그레이드 권한이 존재하는 순간, 권한 탈취는 곧 코드 교체다

3) 권한 사고의 전형: 기술보다 운영이 위험한 이유

3.1 키 탈취 또는 서명자 탈락

멀티시그라도

서명자 피싱
디바이스 탈취
내부자 사고
인력 변화로 인한 키 분실

이 모두가 현실 리스크입니다.

3.2 권한 과다와 권한 혼재

자주 보이는 위험 패턴

pause 권한과 upgrade 권한이 같은 키에 묶임
운영 편의로 owner를 EOA 단일 키로 둠
역할 분리가 없어서 사고 시 피해 범위가 과대

3.3 거버넌스 공격

토큰 거버넌스로 업그레이드를 하는 시스템은

투표 조작
대출로 토큰을 잠깐 빌려 투표
제안 통과 후 즉시 악성 업그레이드

같은 공격을 고려해야 합니다.

4) 운영 설계의 핵심 도구 5개

4.1 멀티시그

단일 키를 피하고, 서명 임계치를 둡니다.

m of n 서명
서명자 분산
키 교체 절차

4.2 타임락

업그레이드를 즉시 실행하지 않고 대기 시간을 둡니다.

커뮤니티와 모니터링이 사전에 감지할 시간을 준다
사고가 나면 취소하거나 대응할 여지를 만든다

4.3 역할 분리 RBAC

업그레이드, 파라미터 변경, 일시정지, 긴급출금 같은 권한을 분리합니다.

4.4 회로 차단기 pause

완벽한 해결책이 아니라 피해 확대를 줄이는 브레이크입니다.
pause 권한은 강력하므로 오남용 가능성도 함께 관리해야 합니다.

참고.
스마트컨트랙트의 pause는 목적은 circuit breaker와 비슷하지만, 보통 자동이 아니라 관리자 트랜잭션으로 켜고 끄는 긴급 정지 스위치에 더 가깝다.

4.5 모니터링과 알람

업그레이드 가능 컨트랙트는 모니터링 없이는 운영이 어렵습니다.

implementation 슬롯 변화 감지
관리자 주소 변화 감지
중요한 파라미터 변경 이벤트 감지
이상 출금과 승인의 급변 감지

5) web2 비유: 운영 리스크는 배포 권한과 같다

web2에서 이런 상황을 떠올리면 됩니다.

프로덕션 배포 권한을 가진 계정이 탈취되면, 코드가 안전해도 끝이다
DB 관리자 계정이 탈취되면, 애플리케이션 검증 로직은 무력해진다
변경관리 절차가 없으면, 실수로도 큰 사고가 난다

체인에서는 그 결과가 더 즉각적입니다.

잘못된 업그레이드는 되돌리기 어렵고
피해는 공개적으로 관측되며
공격자는 자동화로 초 단위로 움직입니다

6) 제품 의사결정 프레임: 업그레이드를 어디까지 허용할까

질문은 이겁니다.

편의성을 위해 신뢰를 얼마나 운영 주체로 옮길 것인가

대표 선택지

1) 업그레이드 불가

장점: 운영 리스크 최소화
단점: 버그 수정과 기능 개선이 어렵다

2) 제한적 업그레이드

장점: 치명적 버그 대응 가능
단점: 설계가 복잡해진다

3) 적극적 업그레이드

장점: 빠른 제품 반복
단점: 운영 절차가 보안의 대부분을 차지한다

7) 배포 전 체크리스트

1) proxy admin을 단일 EOA로 두지 않는다
2) upgrade 권한은 멀티시그로 둔다
3) 멀티시그 서명자는 조직과 디바이스를 분산한다
4) 타임락을 기본으로 고려한다
5) 타임락 취소 절차와 커뮤니케이션 채널을 준비한다
6) 역할을 분리한다 upgrade, pause, parameter, treasury
7) pause 권한의 범위를 정의한다 무엇을 멈추고 무엇을 남길지
8) 긴급 모드에서의 출금 정책을 문서화한다
9) 구현 컨트랙트 초기화 초기화자 재호출을 방지한다
10) 업그레이드 함수가 임의 구현으로 바뀌지 않게 검증한다
11) 스토리지 레이아웃 변경을 검토한다
12) proxy와 implementation 주소를 대시보드로 노출한다
13) 업그레이드 이벤트를 온체인 로그로 남긴다
14) 접근권한 변경도 이벤트로 남긴다
15) 배포 파이프라인에 리뷰와 승인을 강제한다
16) 감사 결과를 변경관리 문서로 연결한다
17) 장애 대응 런북을 만든다
18) 모의 사고 훈련을 한다 키 분실, 키 탈취, 악성 업그레이드

8) 운영 중 체크리스트

1) 관리자 주소 변화 알람을 운영 채널로 연결한다
2) implementation 변경 감지를 24시간 켠다
3) 주요 파라미터 변경 알람을 둔다
4) 대규모 allowance 급증과 drain 패턴을 탐지한다
5) pause 실행 후 사용자 커뮤니케이션 템플릿을 둔다
6) 업그레이드 전후로 리컨실을 한다 상태와 이벤트
7) RPC 장애에도 감지 시스템이 동작하도록 다중 제공자를 둔다
8) 서명자 교체 절차를 정기적으로 점검한다
9) 타임락 대기시간 변경은 별도 승인으로 제한한다
10) 권한을 최소화하는 방향으로 정기 감사한다
11) 신규 기능은 점진 배포한다 파라미터로 노출 제한
12) 서명기기와 시드 백업 정책을 준수한다
13) 파트너 컨트랙트 업그레이드도 의존성으로 추적한다
14) 사고 후 회고를 바탕으로 권한 구조를 재설계한다

결론

업그레이드 프록시는 기능이 아니라 신뢰 경계를 옮기는 설계다
권한 키는 가장 높은 가치의 공격 목표다
안전한 운영은 멀티시그 타임락 역할 분리 모니터링으로 만든다

Road to Web3 (18) 스마트컨트랙트 보안 기본 1: 재진입, 승인 allowance 사고 유형

ted k — Sat, 3 Jan 2026 22:13:58 +0900

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

이번 편의 목표는 한 문장입니다.

스마트컨트랙트 보안 사고는 코드 버그라기보다 권한과 상태 변경 순서의 설계 실패로 시작한다

이 글은 두 가지 전형을 먼저 익히는 데 집중합니다.

재진입 reentrancy
승인 allowance 기반 토큰 탈취

제가 처음 스마트컨트랙트를 접했을 때 인상은 이랬습니다.

컨트랙트는 서버 코드처럼 한 번만 실행된다
토큰은 송금이니까 잘못 보내면 끝이고, 승인은 별거 아니다
보안은 감사 업체가 잡아줄 영역이다

현실은 이렇습니다.

컨트랙트 호출은 외부 컨트랙트로 다시 튈 수 있다
승인 allowance는 장기 권한 위임이고, 실수하면 자동이체 권한을 넘겨준 것과 같다
한번 배포된 코드는 운영자가 바로 고치기 어렵다

web2로 번역하면

재진입은 콜백 기반 결제 승인 흐름에서 순서가 뒤집히는 버그와 닮아 있다
allowance는 결제수단 토큰화의 정기결제 권한 위임과 닮아 있다

0) 위협 모델을 한 번만 고정하자

보안 이야기는 위협 모델이 없으면 끝없이 흔들립니다. 최소한 이 정도는 전제로 둡니다.

내 컨트랙트는 임의의 외부 컨트랙트를 호출할 수 있다
외부 컨트랙트는 악의적일 수 있다
트랜잭션은 원자적이지만, 호출 체인은 깊어질 수 있다
실패하면 상태는 롤백되지만 가스는 소모된다

1) 재진입 reentrancy: 상태를 갱신하기 전에 돈부터 보내면 생긴다

1.1 재진입이란

내 컨트랙트가 외부로 자금을 보내거나 외부 컨트랙트를 호출했을 때
상대가 다시 내 컨트랙트를 호출해 들어오는 상황입니다.

핵심은 이것입니다.

외부 호출은 내 코드 흐름을 잠시 멈추고 상대에게 제어권을 준다

그래서 다음 순서가 위험합니다.

송금 또는 외부 호출
그 다음에 내부 상태 갱신

이 순서는 web2에서 말하면

DB 커밋 전에 외부 시스템에 성공 응답을 먼저 주는 것

과 비슷합니다.

1.2 취약한 패턴

아래는 의도적으로 단순화한 예시입니다.

// 취약 예시: 외부 전송 후 상태 갱신
function withdraw(uint256 amount) external {
    require(balance[msg.sender] >= amount);
    (bool ok,) = msg.sender.call{value: amount}();
    require(ok);
    balance[msg.sender] -= amount;
}

공격 컨트랙트는 콜백에서 다시 withdraw를 호출해, balance가 줄기 전에 여러 번 인출을 시도할 수 있습니다.

1.3 방어 원칙 3가지

원칙 1: 체크 후 상태 갱신 후 상호작용

check effects interactions 패턴

function withdraw(uint256 amount) external {
    require(balance[msg.sender] >= amount);
    balance[msg.sender] -= amount;
    (bool ok,) = msg.sender.call{value: amount}();
    require(ok);
}

원칙 2: 재진입 가드

락을 두는 방식입니다.

bool locked;

modifier nonReentrant() {
    require(!locked);
    locked = true;
    _;
    locked = false;
}

원칙 3: 풀 기반 설계

외부로 바로 보내기보다 사용자가 스스로 가져가게 설계하는 방식이 더 안전해지는 경우가 많습니다.
다만 이것도 결국 상태 갱신 순서를 지키는 게 핵심입니다.

1.4 web2 관점에서 재진입을 어떻게 이해할까

재진입은 동시성 락 이슈라기보다

콜백으로 제어 흐름이 역전되는 문제

에 가깝습니다.

예시

결제 승인 콜백에서 동일 주문을 다시 결제 승인 처리하는 버그
웹훅을 수신한 순간, 내 상태가 확정되기 전에 외부가 다시 내 API를 때리는 상황

그래서 web2에서 익숙한 방어도 그대로 유효합니다.

상태 머신을 둔다
멱등성 키를 둔다
외부 호출은 마지막에 한다

2) 승인 allowance 사고: 자동이체 권한을 무심코 넘기는 문제

2.1 allowance란

ERC20에서 transferFrom을 가능하게 하는 권한입니다.

owner가 spender에게 한도를 부여한다
spender는 그 한도 안에서 owner의 토큰을 가져간다

이 모델은 디앱에서 너무 자주 쓰입니다.

DEX 스왑
대출 담보 예치
구독형 결제
게임 아이템 민팅

그래서 사고도 많이 납니다.

2.2 전형적인 사고 유형 6개

유형	요약	web2 비유
무제한 승인	최대값 승인 후 방치	자동이체 한도를 무제한으로 설정
피싱 승인	UI가 속여 다른 spender에 승인	가짜 결제창이 다른 가맹점으로 결제수단 등록
승인 대상 업그레이드	spender가 프록시로 바뀌며 권한이 위험해짐	결제대행사가 계약상 다른 주체로 바뀌는 리스크
approve 변경 레이스	기존 값에서 새 값으로 바꿀 때 중간 상태가 공격 창구	한도 변경 중 중복 출금
permit 오남용	서명 기반 승인 메시지를 탈취해 승인 실행	서명으로 결제수단 등록 동의서를 위조 사용
권한 과다	필요한 범위를 넘어선 spender 권한 부여	업무 계정에 관리자 권한 부여 후 방치

2.3 approve 변경 레이스: 흔한 함정

approve를 0이 아닌 값에서 다른 0이 아닌 값으로 바로 바꾸면
중간에 spender가 이전 allowance로 먼저 가져가고, 새 allowance도 다시 가져가는 창이 생길 수 있다고 알려져 있습니다.

그래서 실무에서는 보통

먼저 0으로 설정
그 다음 새 값으로 설정

패턴을 사용하거나, increaseAllowance decreaseAllowance를 사용합니다.

2.4 제품 관점에서의 안전한 UX

사용자는 대부분 allowance를 돈처럼 이해하지 않고 권한으로 이해하지 않습니다.
따라서 제품은 다음을 명시해야 합니다.

승인이라는 행위는 결제가 아니라 권한 위임이다
승인 한도는 나중에 회수 revoke할 수 있다
무제한 승인 여부를 사용자에게 선택지로 준다

권장 UX 요소

승인 화면에 spender 주소와 의미를 표시
승인 금액을 최소로 제안
서비스 내에서 revoke 안내와 링크 제공
위험군 주소 차단 또는 경고

3) 체크리스트

배포 전 10개

1) 외부 호출은 마지막에 둔다
2) 상태 갱신 순서를 점검한다
3) 재진입 가드를 필요한 곳에 둔다
4) 토큰 전송은 안전한 라이브러리 사용을 검토한다
5) approve 레이스 방어를 반영한다
6) spender 업그레이드 가능성을 문서화한다
7) 이벤트 로그로 핵심 상태 변화를 남긴다
8) 실패와 재시도를 상태 머신으로 설계한다
9) 권한을 최소화한다
10) 통합 테스트에서 악성 컨트랙트를 포함한다

운영 중 10개

1) allowance 관련 고객 문의를 대응 문서로 만든다
2) 승인 한도와 revoke 가이드를 제품에 포함한다
3) 이상 출금 패턴을 탐지한다
4) 주요 기능의 업그레이드 경로와 권한을 감사한다
5) 오라클과 외부 의존성 장애 시 동작을 정의한다
6) 사고 대응 시나리오를 준비한다 pause 권한 등
7) 프론트에서 서명 메시지 피싱 방어를 강화한다
8) RPC 장애와 재전송 정책을 정리한다
9) 모니터링 지표를 둔다 실패율, revert, 가스 급등
10) 사용자 교육 자료를 주기적으로 갱신한다

결론

재진입은 외부 호출로 제어권이 넘어가면서 상태 갱신 순서가 무너지는 문제다
allowance는 토큰 이동이 아니라 권한 위임이며, 실수하면 장기 권한을 넘겨준다
보안은 코드 한 줄보다 제품 UX와 운영 정책까지 포함한 설계 문제다

Road to Web3 (17) 오라클과 가격 피드: 체인 밖 진실을 체인 안으로 넣는 방법

ted k — Sat, 3 Jan 2026 22:02:22 +0900

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

이번 편의 목표는 한 문장입니다.

외부 데이터가 들어오는 순간, 블록체인은 더 이상 닫힌 세계가 아니며 신뢰 설계가 급격히 어려워진다

제가 처음 디파이와 온체인 결제를 볼 때 했던 오해는 이렇습니다.

체인 위에서 돌아가니까 가격도 체인 위에 있을 것이다
가격이 틀리면 그냥 데이터 오류다
오라클은 API 한 번 호출하는 것과 비슷하다

현실은 이렇습니다.

체인은 외부 세계를 모른다
가격은 외부에서 넣어야 하고, 그 순간 신뢰 경계가 생긴다
오라클 문제는 데이터 정확도보다 조작 가능성과 가용성 실패가 더 위험하다

1) 오라클이란 무엇인가

오라클은 체인 밖 정보를 체인 안에 반입하는 메커니즘입니다.

자산 가격
환율
금리
날씨 경기 결과 같은 이벤트
KYC나 신용 점수 같은 오프체인 판정 결과

오라클이 없으면 체인 앱은

체인 내부 상태만으로 계산 가능한 것만

할 수 있습니다.

2) 가격 피드는 왜 가장 흔한 오라클인가

가격은 체인 서비스의 핵심 의존성입니다.

대출 담보 청산
스테이블코인 페그 유지
파생상품 정산
결제 금액 환산
수수료 계산

가격이 틀리면 돈이 새거나, 청산이 잘못되거나, 누군가가 공짜로 이익을 가져갑니다.
따라서 가격 피드는 기능이 아니라 보안 요소에 가깝습니다.

3) 오라클 파이프라인: 어디서 신뢰가 깨질 수 있나

대략적인 흐름은 이렇습니다.

1) 데이터 소스 거래소, 시장 데이터 제공자
2) 집계와 정제 여러 소스 평균, 이상치 제거
3) 게시자 노드 네트워크 또는 운영 주체
4) 온체인 피드 컨트랙트가 최신 값을 저장
5) 앱 컨트랙트가 값을 읽어 로직을 수행

이 흐름에서 위험은 각 단계마다 존재합니다.

소스가 오염될 수 있다
집계가 편향될 수 있다
게시자가 멈출 수 있다
온체인 값이 오래될 수 있다

4) 두 가지 대표 모델: 푸시형 피드 vs 풀형 검증

4.1 푸시형 push feed

게시자가 주기적으로 온체인에 값을 업데이트합니다.

장점: 컨트랙트는 읽기만 하면 된다
단점: 업데이트가 멈추면 값이 오래된다
운영 포인트: 하트비트와 staleness 체크가 필수

4.2 풀형 pull with proof

컨트랙트가 실행될 때 외부 데이터와 증명을 함께 가져와 검증합니다.

장점: 최신성을 확보하기 쉽다
단점: 트랜잭션이 무거워지고 통합이 복잡해진다
운영 포인트: 증명 검증 비용과 장애 시 대체 경로

두 모델 모두 본질은 같습니다.

체인 밖의 어떤 주체를 일정 부분 믿는다

5) 왜 신뢰 설계가 어려워지나: 3대 리스크

5.1 조작 가능성

정확도 오류가 아니라 경제적 공격을 상정해야 합니다.

5.2 최신성

값이 맞더라도 너무 늦으면 사고가 납니다.

급락장에서 오래된 가격을 쓰면 청산이 늦어져 부실이 쌓인다
급등장에서 오래된 가격을 쓰면 누군가 싸게 매수할 수 있다

그래서 피드에는 보통

updatedAt 또는 roundId 같은 메타데이터
maxDelay 같은 정책

이 따라옵니다.

5.3 가용성

오라클이 멈추면 프로토콜이 멈춥니다.
web2로 치면 결제 PG가 멈춘 순간 매출이 멈추는 것과 같습니다.

6) 공격 시나리오: 가격 조작은 어떻게 일어나나

가장 유명한 패턴은 조작 가능한 가격을 잠깐 만들어서

담보 가치를 부풀리고 대출을 최대한 땡긴 뒤
가격을 원복시키고
남는 차익을 들고 튀는

종류입니다.

대표 공격 벡터

1) 유동성 얕은 DEX 풀을 조작
2) 단일 소스 또는 약한 피드가 그 가격을 따라감
3) 컨트랙트가 그 값을 신뢰해 대출이나 정산을 실행
4) 공격자는 한 블록 안에서 수익 실현

그래서 가격 피드 설계에서 자주 나오는 방어가

DEX 스팟 가격을 그대로 믿지 말기
시간 가중 평균 TWAP 같은 지연 필터
여러 소스 집계
staleness 체크와 회로 차단기

입니다.

7) web2 비유: 오라클은 외부 기준값 공급 시스템이다

결제 서비스에서 금액과 환율은 종종 외부 기준을 씁니다.

카드사 고시 환율
은행 고시 환율
PG 정산 수수료
특정 시점 기준 금리

이 기준이 느리거나, 틀리거나, 멈추면 정산과 회계가 붕괴합니다.
오라클도 똑같습니다.

체인 앱의 외부 기준값을 공급하는 시스템

그래서 엔지니어링 포인트도 web2와 닮습니다.

소스 다중화
지표와 알람
장애 시 degrade 모드
정책 문서화

8) 제품 의사결정 프레임: 어떤 오라클을 언제 쓰나

오라클 선택은 트레이드오프입니다.

빠름 vs 보수적
최신 vs 안정
단순 통합 vs 복잡하지만 강한 검증

예시

결제 환산처럼 금액이 작은 경우: 보수적 가격도 괜찮다
담보 청산처럼 리스크가 큰 경우: 조작 저항이 최우선이다
트레이딩처럼 UX가 중요한 경우: 빠른 업데이트가 중요하다

9) 체크리스트

1) 피드 최신성 메타데이터를 확인한다
2) maxDelay 정책을 코드에 넣는다
3) 값이 비정상일 때 회로 차단기 동작을 정의한다
4) 단일 소스 오라클을 피한다
5) DEX 스팟 가격을 직접 신뢰하지 않는다
6) 가능한 경우 TWAP 또는 집계 피드를 쓴다
7) 가격 단위와 소수점 체계를 명확히 한다
8) 오라클 주소 변경과 업그레이드 리스크를 문서화한다
9) 오라클 장애 시 서비스 동작을 정의한다 정지 또는 보수적 모드
10) 모니터링 지표를 만든다 최신성, 결측, 급변, 게시 지연
11) 알람은 업데이트 지연과 값 급변을 분리한다
12) 테스트넷과 메인넷 피드는 다르다 환경별로 검증한다
13) 가격 읽기 로직을 한 곳에 모아 재사용한다
14) 오라클 입력을 신뢰 경계로 보고 보안 리뷰한다
15) 외부 공시 기준이 필요한 경우 기준을 고정한다
16) 책임 소재와 보상 정책을 제품 문서로 남긴다

결론

오라클은 체인 밖 사실을 체인 안에 넣는 다리다
다리가 생기는 순간 신뢰 경계와 공격 면적이 커진다
성공 조건은 정확도보다 조작 저항, 최신성, 가용성의 균형이다

Road to Web3 (16) 결제 시스템 비교: 카드 승인 매입 vs 온체인 정산

ted k — Thu, 1 Jan 2026 21:07:43 +0900

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

이번 편의 목표는 이 한 문장입니다.

web2 결제의 승인 매입 정산 프레임으로 온체인 포함 확정 정산을 맵핑하면 제품 의사결정이 쉬워진다

온체인 결제를 아래와 같이 이해했었습니다.

블록에 들어가면 카드 결제의 승인 같은 것이다
confirm은 정산 같은 것이다
온체인은 환불이 없으니 정책이 단순해진다

하지만 현실은 더 복잡합니다.

승인과 정산이 분리되는 문제는 web2도 web3도 동일하다
다만 web3는 실패 비용이 있고, 되돌림 reorg까지 고려해야 한다
환불과 분쟁이 사라지는 게 아니라 구현 레이어가 바뀐다

그래서 이 글은 결제 기획과 운영 언어로 체인을 번역합니다.

1) 카드 결제는 실제로 어떻게 굴러가나

상세 네트워크는 카드사와 국가마다 다르지만, 결제는 보통 이 단계로 이해합니다.

1) 승인 authorization
2) 매입 capture
3) 정산 settlement
4) 취소 환불 dispute refund

승인은 즉시 응답이 오지만, 정산은 지연될 수 있습니다.

승인은 빠른 UX
정산은 회계 확정

2) 온체인 결제는 어떤 단계로 보나

온체인도 단계를 나눠야 운영이 됩니다.

1) submitted: RPC에 제출됨
2) seen: 멤풀에서 관측됨
3) included: 블록에 포함됨
4) confirmed: k confirmations를 쌓음
5) finalized: 최종 확정 정책을 만족함
6) failed: 블록 포함 후 revert

이 단계는 서비스 레벨에서 의미가 다릅니다.

included는 사용자 체감 성공
confirmed는 제공 시작 기준으로 많이 쓰임
finalized는 회계 확정 기준으로 많이 쓰임

3) 맵핑 테이블: 승인 매입 정산과 온체인 상태

여기서 핵심 테이블 하나로 정리합니다.

web2 결제 용어	의미	온체인 상태에 가까운 것	제품적으로 쓰는 기준
승인 authorization	결제 의사 확인, 한도 확보	included 또는 confirmed	빠른 UX, 서비스 제공 시작
매입 capture	실제 청구 확정, 취소 가능성 축소	confirmed가 더 쌓인 상태 또는 finalized 정책 직전	정산 파이프라인 시작
정산 settlement	회계 확정, 대금 수령	finalized	회계 확정, 권리 확정
취소 refund	거래 되돌림	onchain refund tx 또는 오프체인 보상	정책과 비용의 문제

주의

이 맵핑은 1대1이 아니라 의사결정 프레임입니다
온체인은 승인과 매입을 한 트랜잭션으로 묶어버릴 수도 있고, L2는 다시 승인과 정산이 2층이 됩니다

4) 제품 의사결정 프레임: 언제 제공하고 언제 확정할까

결제 제품에서 항상 부딪히는 질문

결제 완료 문구를 언제 띄울까
재시도 버튼을 언제 보여줄까
서비스 제공을 언제 시작할까
환불 정책은 어떻게 할까

온체인을 결제 프레임으로 보면 이렇게 나뉩니다.

4.1 UX 성공 기준

included 또는 confirmed k
사용자에게는 지금 처리 중이라는 상태와 ETA를 보여준다

4.2 서비스 제공 기준

confirmed k 또는 L2 included + 위험 점수
고액, 고위험은 finalized까지 보수적으로 기다린다

4.3 회계 확정 기준

finalized
매출 인식, 정산 보고, 회계 마감은 이 기준으로 고정한다

web2와 같은 결론

승인으로 UX를 만든다
정산으로 회계를 고정한다

5) web3에서 달라지는 지점 5개

5.1 실패 비용이 있다

카드 승인은 실패해도 비용이 0에 가까운 경우가 많다
온체인은 revert도 가스를 소비한다

5.2 되돌림 리스크가 있다

카드도 승인 취소, 차지백이 있다
체인은 확정 전 reorg로 되돌아갈 수 있다

5.3 환불은 트랜잭션이다

카드 환불은 네트워크가 처리해준다
온체인 환불은 내가 트랜잭션을 만들어야 한다

5.4 결제 수단과 수수료 자산이 분리될 수 있다

USDC가 있어도 ETH가 없으면 전송이 막힌다

5.5 운영 의존성이 RPC와 네트워크다

PG 장애가 서비스 장애가 되듯이
RPC와 네트워크 혼잡이 곧 결제 장애다

6) 체크리스트

1) 결제 완료라는 문구를 included에서 쓰지 않는다
2) included confirmed finalized를 제품 상태로 분리한다
3) CS 스크립트도 상태별로 분리한다
4) 고액 거래는 확정 깊이를 더 보수적으로 잡는다
5) 멱등성 키로 중복 제공과 중복 청구를 막는다
6) 재시도는 비용이 든다는 점을 UX에 반영한다
7) 실패 원인별로 재시도 전략을 분리한다
8) 환불은 트랜잭션이라는 점을 운영 비용으로 잡는다
9) 정산 파이프라인을 별도로 둔다
10) 오프체인 원장과 온체인 상태를 리컨실한다
11) explorer 지연과 RPC 지연을 구분한다
12) pending과 dropped를 구분해 안내한다
13) nonce와 replacement를 운영으로 다룬다
14) L2는 소프트 확정과 하드 확정을 분리한다
15) 체인별 수수료 자산을 준비시킨다
16) 인덱서는 reorg를 전제로 설계한다
17) 장애 시 degraded mode를 설계한다
18) 대시보드에 lag와 확정 단계 분포를 띄운다
19) 수수료 급등 시 정책을 문서화한다
20) 분쟁과 보상 프로세스를 제품에 포함한다

결론

전통 결제의 승인 정산 프레임은 온체인에도 그대로 먹힌다
차이는 구현 디테일 실패 비용 되돌림 환불 트랜잭션에 있다
제품은 상태 머신과 정책으로 신뢰와 UX를 동시에 만든다