기사 (Articles)

🔍 효율적인 MCP 서버를 구축하기 위한 4가지 규칙

서버를 단순한 API 프록시(proxy)가 아닌 LLM(대규모 언어 모델)을 위한 사용자 인터페이스로 취급하는 MCP 서버를 위한 구체적인 설계 규칙입니다. 원시 API 엔드포인트 대신 사용자의 의도(intentions)를 중심으로 도구를 설계할 것, 토큰 소비를 제한하기 위해 서버당 도구 노출을 약 1520개로 제한할 것, 모델을 적극적으로 유도할 수 있는 도구 설명 및 에러 메시지를 작성할 것, 그리고 필요한 필드만 반환하도록 응답 페이로드(payload)를 공격적으로 필터링(예: JMESPath 사용)할 것을 권장하며, 이를 통해 페이로드를 8090%까지 줄일 수 있다고 설명합니다.

🔍 A2A는 무의미한 프로토콜이다

독특한 기여점은 아키텍처 비평에 있습니다: 이 글은 "에이전트 프로토콜 (agent protocol)"의 기본 요소(primitives)를 직접적인 엔드포인트 메시징에서 스트림 우선(stream-first) 이벤트 인프라로 재정의합니다. Kafka 스타일의 기본 요소들(컨슈머 그룹, 내구성이 있는 추가 전용 로그(durable append-only logs), 지연/관찰 가능성(lag/observability), 재생(replay), 보존(retention), 데드 레터 처리(dead-letter handling), 파티셔닝)이 어떻게 직접적인 메시징 방식에서는 모든 에이전트에 강제되었을 백프레셔(backpressure)와 장애 복구를 중앙 집중화하는지 설명합니다. 그런 다음 상관관계/인과관계(correlation/causation), 버전 관리, 대체/압축(supersession/compaction), 트레이싱(tracing) 필드를 포함하는 에이전트 이벤트 엔벨로프(envelope)를 제안합니다.

🔍 Carousell Group의 API 정의 및 Protobuffer 관리

독특한 기여점은 각 사업부(BU)별 리포지토리(repo) 전반에 걸쳐 proto 계약을 표준화하는 프로덕션 CI 파이프라인입니다: protobuf 어노테이션을 통해 RPC 소유권/인증/PII(개인정보)를 강제하고, 정규식(regex)+CI를 사용하여 어노테이션되지 않은 PII를 차단하며, protoc-gen-validate로 입력을 검증합니다. 아키텍처 측면에서는 proto 소스를 생성된 Go 모듈(서버/클라이언트)과 분리하고, 화이트리스트를 통해 서비스 간 proto 임포트(import)를 방지하며, buf.build의 변경 사항 감지(breaking-change detection)와 병합 안전성(service go.mod에 피처 브랜치 커밋 금지)을 갖춘 피처 브랜치 코드 생성(codegen)을 사용합니다.

🔍 비트랜잭션 API를 통한 트랜잭션 워크플로 구축 (Building Transactional Workflows Across Non-Transactional APIs)

비트랜잭션 (non-transactional) SaaS API를 위해 에이전트 중심적이고 운영 지향적인 독특한 사가 (saga) 설계를 제안합니다. 즉, 오케스트레이션 (orchestration, 조정자)과 내구성이 있는 런타임 (durable runtimes)을 사용하여 긴 대기 시간 동안 상태를 유지하고, 단계를 실행하기 전에 보상 (compensation) 작업을 등록하며 (피벗 세맨틱스, pivot semantics), 보상 작업을 의미론적 비즈니스 액션으로 취급합니다. 또한, LLM의 신뢰할 수 없는 "내러티브 (narrative)"를 극복하기 위해 모든 제3자 호출 시 쓰기 후 읽기 (read-after-write)를 강제하며, 실행/단계/도구 (별도의 보상 네임스페이스 포함)로부터 구조적 멱등성 키 (idempotency keys)를 도출하여 재시도를 안전하게 재개할 수 있도록 합니다.

🔍 분산 시스템처럼 Salesforce 설계하기 (Design Salesforce Like a Distributed System)

Salesforce를 위한 주관적인 "분산" 설계라는 독특한 기여를 제공합니다. 동기적이고 단일 소유자 도메인 로직을 위한 트리거 액션 (Trigger Actions)과 도메인 사실만을 게시하는 플랫폼 이벤트 (Platform Events)를 결합합니다. 이는 비대한 외부 경계 사실 (fat external-boundary facts) 대신 얇은 조직 내 알림 이벤트 (thin in-org notification events, 커밋 후 게시, ID만 포함, 로컬에서 재조회)를 강제합니다. 또한 로컬 조정자/사가 (local coordinators/sagas)를 통해 오케스트레이션 (orchestration) 대 코레오그래피 (choreography)를 프레임화하며, 즉시 게시 대 커밋 후 게시, 비동기 인큐 (async enqueue) 대 전달, 보존 (retention), 중복 제거 (dedupe), 파티션 키 순서 지정과 같은 구체적인 플랫폼 이벤트 메커니즘에 기반하여 가이드를 제시합니다.

🔍 API를 잠그지 마세요 - 대신 스케줄러를 잠그세요 (Don t Lock Your API - Lock Your Scheduler Instead)

독특한 기여점: 개별 요청별 인제스션 (Ingestion) 단계에서의 분산 잠금 (Distributed Locking) 대신, 윈도우당 한 번 실행되는 스케줄러 (Scheduler)로 책임을 전가하여 역전시켰습니다. API는 주문을 PENDING 상태로만 저장하며, 스케줄링된 작업은 ShedLock을 사용하여 클러스터 전체에서 단일 실행을 보장합니다. 또한 JPA 영속성 컨텍스트 (Persistence Context)를 비우고, 각 참여자를 REQUIRES_NEW 트랜잭션으로 처리하며, 컷오프 (Cutoff) 시점에 늦은 주문을 명시적으로 거절하고, TransactionSynchronizationManager.afterCommit을 통해 배치 이벤트를 Kafka로 발행합니다. Kafka 파티셔닝은 추가적인 잠금 없이 순서를 보존하기 위해 windowKey를 키로 사용합니다.

🔍 Upcaster를 활용한 이벤트 버전 관리: 리플레이 (Replay)를 깨뜨리지 않는 스키마 진화 (Schema Evolution)

독특한 기여점: 컨슈머 (Consumer)가 버전 분기 (Version Branching)를 피할 수 있도록 스키마 진화를 중앙 집중화하는 단계별 업캐스터 체인 (Upcaster-chain) 설계입니다. vN에서 vN+1로의 변환 (이름 변경 및 단위 수정, 평면 구조에서 중첩 구조로의 재구성)을 구현하며, 저장된 schema_version을 기반으로 읽기 시점에 이를 실행하여 현재 구조로 통합합니다. 또한 리플레이를 위한 결정론적 제약 조건 (시계 사용 금지, 외부 조회 금지, 무작위성/맵 순서 유출 금지)을 열거하고, 긴 체인의 비용을 제어하기 위해 업캐스트 (Upcast) 결과를 캐싱하는 방법에 대해 논의합니다.

🔍 상위 이벤트 포맷 변경에도 생존하는 멱등성 키 (Idempotency Keys) 설계 방법

독창적 기여: 상위 이벤트 형식 드리프트 (upstream event format drift) 상황에서도 정확성을 유지하는 내구성 있는 멱등성 키 (idempotency key) 체계. 페이로드 해시 (payload-hash) 키를 위한 네 가지 구체적인 규칙을 규정합니다: 상위 단계에서 안정적인 필드만 해싱할 것, 입력을 결정론적으로 정규화할 것, 해시 알고리즘과 직렬화 와이어 포맷 (serialization wire format)을 고정할 것, 그리고 키 내에 v1:hash(...)와 같이 스키마 버전 (schema version)을 포함할 것. 그 후 스키마 드리프트 (schema-drift) 탐지 워크플로우, v2 키 발행 (minting), 이중 키 조회 (dual-key lookup)를 통한 점진적 백필 (backfill), 선택적 병렬 통합 전환 (parallel-integration cutover), 그리고 누출을 포착하기 위한 방어적 SQL/메트릭 (중복 보고, 충돌률, 필드 세트 드리프트)을 제시합니다.

🔍 Cloudflare Workflows를 위한 Saga 롤백 구축 방법

독창적 기여는 Cloudflare Workflows에서 Saga 롤백 (saga rollbacks)을 위한 구체적인 설계입니다: 롤백 메타데이터가 각 step.do에 {rollback, rollbackConfig}를 통해 부착되어, 보상 (compensation) 작업이 워크플로우의 최종 실패 시에만 실행됩니다. 대상 핸들러 (eligible handlers)에는 출력이 정의되지 않은 (undefined) 경우에도 실패한 단계가 포함됩니다. 보상 작업은 (완료 순서가 아닌) 역순의 내구성 있는 단계 시작 (durable step-start) 순서로 실행됩니다. 내부적으로는 내구성 있는 단계 이력 (durable step history)이 적격성/출력을 기록하는 한편, 롤백 핸들러 코드는 호출 가능한 스텁 (callable stubs)으로 유지되며, 완료된 외부 사이드 이펙트 (external side effects)의 재실행을 방지하기 위해 영속화된 결과 (persisted results)를 사용한 재생 (replay)을 통해 재구축됩니다.

🔍 50건의 API 침해 사례를 역공학했습니다. 동일한 5가지 실수가 반복됩니다.

고유한 기여점은 다섯 가지의 반복되는 침해 패턴을 특정 엔지니어링 통제(engineering controls)와 연결하는 프로덕션 지향적인 "API 보안 수명 주기 (API Security Lifecycle)"입니다. 즉, 엔드포인트별 적대적 CI/CD 테스트를 통해 데이터 계층에서 BOLA(Broken Object Level Authorization)를 강제하고, 권한 범위(scopes)를 문서화하며 90일마다 검토 및 취소함으로써 제3자 신뢰를 관리하며, Vault 우선 코드 리뷰와 실행 가능한 비밀 정보 스캐닝 SLA를 통해 비밀 정보 확산(secrets sprawl)을 방지하고, 엔드포인트별로 작성된 행동 기준선(behavioral baselines)과 소유권 컨텍스트를 사용하여 열거(enumeration)/유출(exfiltration)을 탐지하며, 보안이 분기별이 아닌 지속적으로 이루어지도록 API 인벤토리 및 엔드포인트 폐기(decommissioning)를 유지하는 것입니다.

🔍 핵심은 오케스트레이션하고, 엣지는 코레오그래피하라: 실제로 두 방식 사이에서 선택하는 방법

고유한 기여점은 "핵심은 오케스트레이션(orchestrate the core)하고, 엣지는 코레오그래피(choreograph the edges)하라"는 원칙에 대한 의사결정 사분면(decision quadrant)과 구체적인 경계 기준(seam criteria)을 제시합니다. 이는 오케스트레이션을 워크플로/상태 머신(workflow/state machine)을 통한 인간 개입(human-in-the-loop), 타임아웃, 보상 취소(compensating undo)를 포함하는 복잡하고 상태가 있는 분기(stateful branching)와 연결합니다. 반면 코레오그래피는 발행된 이벤트(published events)를 사용하여 경계 컨텍스트(bounded contexts) 전반에 걸쳐 자율적이고 다수 팀으로 퍼져나가는 팬아웃(fan-out)과 연결합니다. 그 경계(seam)는 오케스트레이션의 이벤트 발행이며, 다운스트림 실패는 롤백 요청(rollback-request) 이벤트를 방출하여 처리하며, 파티션된 고용량 전파 순서(partitioned high-volume propagation ordering)에 대한 참고 사항을 포함합니다.

🔍 팬텀 API가 공격 표면을 잠식하고 있지만, 대부분의 보안 팀은 여전히 외면하고 있다

고유한 기여: 스펙 차이 분석 (spec-diffing), 라이브 트래픽 검증 (live traffic verification), 게이트웨이 강제 적용 (gateway enforcement)을 결합하여 팬텀 API (phantom APIs)를 위한 운영 제어 청사진을 제시합니다. 생성된 OpenAPI 스펙이 검토되지 않은 라우트(routes)를 추가하거나 인증/속도 제한 (auth/rate-limit) 범위를 누락한 경우 머지 (merge)를 차단해야 한다고 주장하며, 이후 런타임 프로파일러 (runtime profiler)를 실행하여 요청된 경로의 지문 (fingerprint)을 식별하고 승인된 스펙에 없는 200 응답에 대해 경고를 보냅니다. 마지막으로 서비스 코드와 독립적으로 게이트웨이의 기본 거부 (default-deny) 정책, 요청/응답 스키마 검증 (schema validation), 그리고 인증/권한 범위 (auth/scope) 체크를 강제합니다.

🔍 Saga 타임아웃: 대부분의 팀이 테스트하지 않는 보상 경로 (Compensation Path)

고유한 기술적 가치는 "타임아웃은 제3의 상태"라는 모델에 있습니다. 원격 시스템이 오케스트레이터 (orchestrator)의 마감 시간 이후에 작업을 완료했을 가능성이 있는 경우, StepTimedOut은 즉각적인 보상 (compensation) 대신 조정 (reconciliation)을 트리거합니다. 또한 DB 스위퍼 (DB sweeper, FOR UPDATE SKIP LOCKED 사용)를 통해 마감 시간을 영속화하여 재시작 시에도 대기 중인 단계를 timed_out 상태로 전환하며, 보상이 안전하게 재시도될 수 있도록 2계층 멱등성 (two-layer idempotency: DB 상태 가드 + 외부 멱등성 키)을 제공합니다. "공급업체는 결제되었으나 응답은 타임아웃된" 상황을 강제하는 테스트와 환불 없이 조정이 성공함을 확인하는 테스트를 포함합니다.

🔍 당신의 통합 시스템이 처리할 수 없는 반품 (The Return Your Integration Can’t Handle)

고유한 기여: 반품을 ERP와 스토어프런트 (storefront) 전반에 걸쳐 명시적인 "완료 (done)" 기준을 가진 별도의 라이프사이클 (lifecycle)로 취급하며, 시스템 간의 불일치를 방지하기 위한 구체적인 해결책을 제시합니다. 방법론: 확정 전 원본 전기 (posting)를 기반으로 ERP 할인 할당 및 세금 취소를 호출하여 고객에게 보이는 환불 금액을 계산합니다. 검사 승인 후에만 스토어프런트 재고를 복구하며, 완료 과정을 세 가지 스레드 (고객 확정, 창고 수령/검사, 재무 전기 완료)로 모델링합니다. 또한 원본 인보이스/세금 코드를 참조하는 트랜잭션 연결 취소 (transaction-linked reversals)를 수행합니다.

🔍 Well-Known URIs

RFC 8615 저자가 전하는, Well-Known URIs가 도움이 되는 시점과 해가 되는 시점에 대한 전문가 가이드입니다. 이 방식은 클라이언트가 이미 사이트를 인식하고 있지만 사이트 전반의 탐색(discovery)이 필요할 때(robots.txt의 경우처럼) 가장 효과적입니다. 프로토콜이 단순히 전체 URL을 전달할 수 있는 상황에서 정당성 확보나 URL 편의성을 위한 지름길로 사용해서는 안 됩니다. 실제 배포 과정에서의 복잡한 문제들, 즉 사용자 상호작용 범위와 탐색 지점 간의 불일치, 다중 발행자(multi-publisher) 환경에서 깨지는 아키텍처적 가정, 그리고 메타데이터 세밀도(metadata-granularity) 간의 트레이드오프를 다루며, 전환 계획, 스킴 열거(scheme enumeration), 등록에 관한 실행 가능한 조언을 제공합니다.

🔍 When Event Time Meets Reality: Lessons from Building Billing on Apache Flink

연쇄적인 keyBy/repartitioning 이후에 왜 Kafka 소스에서의 Flink 워터마크(watermark) 정렬만으로는 불충분한지를 보여주는, 빌링(billing) 수준의 디버깅 서사를 담은 독특한 기여입니다. 연산자/슬롯(operator/slot) 레벨의 이벤트 시간(event-time) 진행 상황이 경로마다 달라질 수 있으며, 이로 인해 늦게 도착한 이벤트가 "이미 방출된" 72시간 텀블링 윈도우(tumbling windows)를 다시 열어 중복을 발생시킬 수 있음을 보여줍니다. 이 글은 중복 제거 및 통합을 위한 파티션 키를 통일하고, 윈도우 적용 전의 다중 keyBy를 피하며, 조기 트리거를 방지하기 위해 재생 전용(replay-only) 통합 타이머 지연 및 명시적인 오래된 타이머 삭제를 추가함으로써 이 문제를 해결합니다.

🔍 Your Server Is Already Compromised — Here’s Why the Gateway Is the Last Thing Standing

고유한 기여점은 게이트웨이 강제 적용(gateway enforcement)을 위한 '침해 가정(assume-breach)' 준수 프레임워크를 제공한다는 것입니다. 백엔드 침해(backend compromise)는 발생할 수 있는 일로 간주되므로, 게이트웨이는 서명 검증(signature validation), 만료 시간 확인(exp checks), 범위/대상 강제 적용(scope/audience enforcement), 소비자 수준의 속도 제한(consumer-level rate limiting), 그리고 감사 가능한 결정 로그(auditable decision logs)를 통해 토큰 사용성을 제한해야 합니다. 이 모델은 재사용 가치(replay value)를 제한하기 위해 expires_in=3600을 보여주는 실제 OAuth2 클라이언트 자격 증명 흐름(client_credentials flow)을 바탕으로 근거를 제시하며, 수명이 긴 클라이언트 비밀(client_secret)의 리스크를 분리하고 유예 기간(grace period)을 둔 병렬 로테이션(parallel rotation)을 명시합니다.

Apache Camel

🔍 라우트가 어떻게 연결되는지 확인하세요: Apache Camel의 라우트 토폴로지 다이어그램 (Route Topology Diagrams in Apache Camel)