A2A 및 MCP 에이전트 보안: 아이덴티티, 위임 및 감사 추적

프로토콜 보안은 모델이 아닌 행위 주체를 규정합니다.

Page content

프롬프트 인젝션은 LLM 시스템에서 가장 많은 보안 관심을 받고 있으며, 주목받을 만하지만 에이전트가 도구를 호출하고 작업을 다른 에이전트에 위임하기 시작하면 이것이 유일한 문제는 아닙니다.

MCP는 에이전트에게 파일, API, 데이터베이스, 티켓팅 시스템에 대한 구조화된 접근을 제공합니다. A2A는 하나의 에이전트가 다른 팀, 벤더, 또는 런타임에 속할 수 있는 다른 에이전트에게 작업, 메시지, 아티팩트를 전송할 수 있게 합니다. 이러한 프로토콜은 신뢰 경계를 가로지르기 때문에 유용하며, 이는 아이덴티티, 인증, 위임 한계 및 감사 흔적이 선택적인 강화 조치가 아닌 일급 아키텍처 요소가 됨을 의미합니다.

A2A 및 MCP 에이전트 보안 아키텍처: 아이덴티티, 게이트웨이, 감사 레이어

이 기사는 LLM 아키텍처 클러스터의 에이전트 프로토콜 보안에 대한 표준 가이드입니다. 위협 모델, 아이덴티티, 게이트웨이, 레지스트리, 위임 및 프로덕션 체크리스트를 다룹니다. 입력 유효성 검사, 출력 필터링 및 프롬프트 안전 패턴에 대해서는 대신 실무에서의 LLM 가드레일을 참조하십시오.

가드레일 vs 프로토콜 보안 vs 런타임 정책

이 세 가지 레이어는 서로 다른 문제를 해결하며, 혼동될 경우 서로 다른 방식으로 실패합니다.

LLM 가드레일은 모델 입력 및 출력에서 작동합니다: 인젝션 패턴 차단, 유해 콘텐츠 필터링, JSON 구조 검증, 생성된 텍스트에 대한 톤 또는 규정 준수 규칙 강제 적용. 이는 대화 레이어를 보호합니다.

프로토콜 보안은 에이전트 경계에서 작동합니다: 어떤 MCP 도구를 호출할 수 있는지, 어떤 에이전트가 어떤 피어에게 위임할 수 있는지, 작업에 연결되는 OAuth 범위, 그리고 하위 에이전트가 사용자를 대신하여 행동할 수 있는지 여부. 이는 액션 레이어를 보호합니다.

런타임 정책은 그 사이에 위치합니다: 트리거가 자연어였는지 구조화된 프로토콜 호출이었는지 여부에 관계없이 규칙에 대해 요청을 평가하는 정책 엔진. 이는 도구 실행 전에 인간 승인을 요구하거나, 미지의 도메인への 이gress를 차단하거나, 범위가 원래 사용자를 초과할 때 위임을 거부할 수 있습니다.

저의 의견은 직설적입니다: 프로토콜 보안 없는 가드레일은 여전히 도구 호출을 통해 데이터를 유출하는 정중한 챗봇을 생성합니다. 가드레일 없는 프로토콜 보안은 여전히 아티팩트에 내장된 악의적인 지시를 따르는 잘 인증된 에이전트를 생성합니다. 두 가지 모두 필요하며, 고위험 작업에는 런타임 정책도 필요합니다.

A2A 및 MCP 에이전트 시스템의 위협 모델

제어 항목의 쇼핑 목록이 아닌 자산과 적대자로부터 시작하십시오.

보호할 가치가 있는 자산: 프롬프트 및 아티팩트 내 사용자 데이터, MCP 서버 자격 증명, 도구를 통해 접근 가능한 프로덕션 시스템, 에이전트 평판, 토큰 사용량과 연결된 빌링 계정, 그리고 감사 무결성.

현실적인 적대자: 공개 에이전트 엔드포인트를 남용하는 외부 사용자, 독이 든 도구 결과를 반환하는 손상된 MCP 서버, 에이전트 카드에서 기술을 허위로 표현하는 악의적인 에이전트, 권한을 과도하게 위임하는 내부자, 그리고 모델 행동을 조작하는 도구 메타데이터에 대한 공급망 조작.

악의적이거나 손상된 도구 (MCP)

MCP 서버는 모델에 노출된 코드 및 데이터입니다. 호적일 수 있는 서버는 잘못된 도구 설명을 반환하거나, 모델이 전달한 인수를 유출하거나, 호스트가 범위 지정된 자격 증명 없이 도구 호출을 실행할 때 사용자가 의도한 것 이상의 작업을 수행할 수 있습니다.

악의적이거나 사칭된 에이전트 (A2A)

작업을 수락하는 에이전트는 악의적이거나, 손상되었거나, 단순히 권한이 과도할 수 있습니다. 에이전트 카드는 기능을 설명하지만, 서명, TLS, 발급자 신뢰를 검증하지 않는 한 아이덴티티를 증명하지 않습니다.

혼란스러운 대리인 (Confused Deputy)

에이전트 B는 금융 API에 접근할 수 있는 권한을 가지고 있습니다. 낮은 권한을 가진 에이전트 A는 B에게 “이 송장 요약해줘"라고 요청하면서 아티팩트 내에 이송 지침을 숨깁니다. B는 끝-to-끝으로 위임 범위가 강제되지 않는 한 자신의 자격 증명을 사용하여 실행합니다.

과도한 권한 및 숨겨진 위임 체인

사용자가 한 단계를 승인합니다. 오케스트레이터는 조용히 세 개의 A2A 홉과 다섯 개의 MCP 호출을 체인합니다. 사용자는 전체 그래프를 보지 못하지만, 조직은 여전히 결과에 책임이 있습니다.

아티팩트 및 에이전트 간 메시지 통한 프롬프트 인젝션

인젝션은 사용자 메시지 문제만이 아닙니다. PDF 아티팩트, 도구가 가져온 웹 페이지, 또는 에이전트 C로부터의 메시지는 에이전트 D의 모델을 향한 지시를 담고 있을 수 있습니다. 모델 경계에서 모든 프로토콜 전달 콘텐츠를 신뢰할 수 없는 입력으로 취급하십시오.

독이 들거나 오해의 소지가 있는 에이전트 카드

설명 및 기술 이름은 프롬프트 표면적입니다. 쓰기 가능한 백엔드를 수용하면서도 safe_read_only_analysis를 광고하는 카드는 기술적 보장이 아닌 사회 공학 레이어입니다.

다중 에이전트 시스템의 아이덴티티 모델

프로토콜 보안은 명확한 아이덴티티 유형과 각 유형이 증명할 수 있는 것으로부터 시작됩니다.

아이덴티티 유형 무엇을 나타내는가 일반적인 증명
인간 사용자 작업을 시작한 최종 사용자 또는 운영자 OIDC 세션, SSO 토큰
에이전트 서비스 배포된 에이전트 런타임 (오케스트레이터, 전문가) OAuth 클라이언트 자격 증명, mTLS 인증서
MCP 서버 도구 제공 프로세스 API 키, mTLS, 범위 지정된 서비스 계정
작업 / 세션 홉을 가로지르는 작업 단위 작업 ID, 추적 ID, 위임 범위 토큰

A2A의 에이전트 카드는 지원하는 인증 방식 (OAuth 2.0, API 키, mTLS 및 OpenAPI 관행과 일치하는 유사 패턴) 및 선택적 보안 요구사항과 함께 기술을 광고합니다. 카드는 신뢰 앵커가 아닌 발견 메타데이터입니다. 클라이언트는 밴드 아웃으로 자격 증명을 획득하고 모든 요청에서 표준 HTTP 헤더를 통해 전송하며, 서버는 모든 호출에서 유효성을 검사하고 인증 또는 범위 실패 시 401 또는 403을 반환해야 합니다.

동일한 에이전트의 내부 및 외부 뷰

프로덕션 에이전트는 종종 제한된 기술 목록과 내부 호출자를 위한 풍부한 인증된 카드를 가진 공개 에이전트 카드를 게시합니다. A2A 사양은 인증된 클라이언트를 위한 확장된 카드를 허용합니다. 이 분리를 의도적으로 사용하십시오: 파트너는 내부 기술을 보아서는 안 되며, 내부 오케스트레이터는 인증을 위해 공개 발견에만 의존해서는 안 됩니다.

MCP 및 A2A를 위한 인증 및 인가

인증은 누가 호출하는가에 답합니다. 인가는 무엇을 할 수 있는가에 답합니다.

MCP 도구 접근

각 MCP 연결에 대해 다음을 정의하십시오:

  • 어떤 에이전트 호스트가 연결할 수 있는지
  • 해당 호스트에 대해 어떤 도구가 활성화되어 있는지
  • 부수 효과를 실행하는 OS 사용자 또는 서비스 계정
  • 인간 사용자가 각 변경 호출을 승인해야 하는지 여부

“모든 것 연결” MCP 구성보다 도구 허용 목록을 선호하십시오. 코딩 에이전트는 공개 지원 봇과 동일한 프로필에서 급여 MCP 서버가 필요하지 않습니다.

A2A 에이전트 접근

각 에이전트 피어 관계에 대해 다음을 정의하십시오:

  • 어떤 호출자 에이전트 ID가 어떤 기술을 호출할 수 있는지
  • 최대 위임 깊이
  • 경계를 가로질러 어떤 아티팩트 유형이 통과할 수 있는지
  • 사용자 컨텍스트가 서명된 클레임으로 전파되어야 하는지

OAuth 범위(또는 동등물)를 에이전트 관리가 아닌 기술에 매핑하십시오. 토큰 레이어의 최소 권한이 프롬프트 레이어의 희망보다 낫습니다.

게이트웨이 강제 vs 에이전트별 정책

에이전트별 정책은 한 팀이 전체 그래프를 소유하고 릴리스가 조정될 때 작동합니다. 게이트웨이 강제 정책은 여러 팀, 테넌트 또는 벤더가 에이전트 네트워크를 공유하고 허용 목록, 속도 제한 및 감사를 강제할 한 곳이 필요할 때 작동합니다.

flowchart LR U[User / client] --> G[A2A gateway] G --> O[Orchestrator agent] O -->|A2A scoped token| S1[Specialist agent] O -->|A2A scoped token| S2[Specialist agent] S1 --> MG[MCP gateway] S2 --> MG MG --> T1[MCP tool servers] MG --> T2[MCP tool servers] G --> A[Audit log] MG --> A S1 --> A S2 --> A

제어 평면으로서의 A2A 게이트웨이

A2A 게이트웨이는 프로토콜에 의해 엄격히 요구되지는 않지만, 에이전트 트래픽이 중앙 집중식 거버넌스가 필요할 때 필요해집니다.

게이트웨이는 일반적으로 다음을 처리합니다:

  • 인증 종료 및 토큰 교환
  • 기술 또는 테넌트에 따라 올바른 에이전트 서비스로 라우팅
  • 작업이 수락되거나 전달되기 전의 정책 검사
  • 프로토콜 버전 협상
  • 속도 제한 및 악용 감지
  • 모든 작업 전환 시 구조화된 감사 방출

게이트웨이가 과용 vs 필요한 경우

게이트웨이는 한 팀이 유지 관리하는 하나의 쿠버네티스 네임스페이스에 있는 단일 오케스트레이터와 두 개의 전문가 에이전트에 대해 종종 과용입니다. 파트너가 에이전트를 호출할 때, 여러 비즈니스 단위가 인프라를 공유할 때, 규정 준수가 일관된 로깅을 요구할 때, 또는 모든 에이전트 구현이 정책을 올바르게 강제한다고 신뢰할 수 없을 때 필요해집니다.

A2A 게이트웨이를 MCP 게이트웨이(또는 MCP 프록시)와 결합하여 도구 접근이 동일한 처리를 받도록 하십시오: 채팅 UI에서만이 아닌 도구 경계에서 아이덴티티, 허용 목록, 이gress 제어 및 감사.

파트너 대상 vs 내부 에이전트 카드

외부 및 내부 호출자에 대해 다른 발견 메타데이터를 게시하십시오. 외부 카드는 좁은 기술과 더 엄격한 인증을 노출합니다. 내부 카드는 유지 관리 또는 관리 기술을 나열할 수 있지만, 공개 카드가 시사하는 것보다 더 강력한 인증 없이 도달 가능해서는 안 됩니다.

에이전트 레지스트리 및 발견 보안

발견은 공격 표면의 일부입니다. 에이전트가 “사용 가능"하게 나타나는 것을 제어하는 사람은 오케스트레이터가 작업을 어디로 보내는지를 제어합니다.

레지스트리 vs 잘 알려진 에이전트 카드 URL

작은 배포는 에이전트별 잘 알려진 URL(/.well-known/agent-card.json)을 사용합니다. 엔터프라이즈 배포는 에이전트 ID, 버전, 엔드포인트, 소유자 및 정책 태그를 색인화하는 레지스트리를 추가합니다. 레지스트리는 정책 객체입니다: 엔트리는 어디에 있는지뿐만 아니라 어떤 테넌트가 어떤 에이전트를 발견할 수 있는지 기록해야 합니다.

버전 관리, 퇴출 및 소유권

레지스트리 레코드는 소유자, 변경 이력 및 퇴출 날짜가 필요합니다. 에이전트 카드를 캐싱하는 오케스트레이터는 TTL에서 새로 고침을 수행하고 서명 지원을 검증해야 합니다. 오래된 카드는 취약성이 패치된 후에도 오래된 기술이 트래픽을 계속 받는 방법입니다.

엔터프라이즈 내부 네트워크 vs 외부 파트너

내부 에이전트 메시는 mTLS 및 사설 DNS에 의존할 수 있습니다. 파트너 에이전트는 런타임을 제어하지 않기 때문에 명시적인 연방 규칙, 계약상 범위 지정된 기술 및 더 강력한 아티팩트 검사가 필요합니다.

에이전트 경계 간 위임

위임은 A2A 보안이 승패가 결정되는 곳입니다. 에이전트 A가 에이전트 B에게 작업을 보낼 때, 세 가지 질문이 명확한 답변을 가져야 합니다:

  1. 어느 권한이 행사되고 있는가? 사용자의, A의 서비스 계정의, 또는 혼합된 위임 토큰?
  2. B는 그 권한으로 무엇을 할 수 있는가? 읽기 전용 분석, 또는 A를 대신하여 변경 도구?
  3. B가 범위를 초과할 경우 누가 책임 있는가? A, B, 게이트웨이 정책, 또는 불명확한 프롬프트를 승인한 인간?

사용자 의도 전파 vs 과도한 위임

사용자 ID, 원래 작업 ID, 허용된 기술, 만료 및 최대 홉 수를 포함하는 서명된 위임 클레임을 전달하십시오. 하위 에이전트는 범위를 조용히 확장하는 작업을 거부해야 합니다. B가 A가所持했던 것보다 더 높은 권한이 필요하면, input_required로 전환하고 토큰을 보이지 않게 업그레이드하는 대신 명시적인 인간 승인을 획득하십시오.

위험한 위임을 위한 인간-in-the-loop 승인 흐름은 A2A 스트리밍 및 장기 실행 에이전트 워크플로우를 위한 비동기 작업에서 다루며, 여기서 input_required는 오류가 아닌 일급 작업 상태입니다.

sequenceDiagram participant User participant Orch as Orchestrator agent participant GW as A2A gateway participant Spec as Specialist agent participant MCP as MCP tool server User->>Orch: Request with user token Orch->>GW: Delegate task (scoped delegation token) GW->>GW: Policy check scope + hop count GW->>Spec: Forward task (reduced scope token) Spec->>MCP: Tool call (tool-scoped credential) MCP->>MCP: Enforce allowlist + user context Spec-->>GW: Artifact + audit events GW-->>Orch: Task update Orch-->>User: Final response

추론을 실행 권한과 분리

에이전트는 계획하기 위해 광범위한 읽기 접근이 필요할 수 있지만 쓰기 도구는 승인 뒤에 있어야 합니다. 모델 실수로 인해 프로덕션이 즉시 변경되지 않도록 자격 증명을 분할하거나 계획 및 실행을 위한 별도 MCP 프로필을 사용하십시오.

감사 흔적 및 답변 근원

위임 체인을 재구성할 수 없으면, 사고를 설명하거나, 감사를 통과하거나, 빌링 이상을 이의 제기할 수 없습니다.

세 가지 레이어에서 로깅하십시오:

게이트웨이: 인증 결과, 정책 결정, 라우팅된 에이전트 ID, 작업 ID, 상위 작업 ID, 속도 제한 이벤트.

에이전트: 작업 상태 전환, 전송/수신 메시지, 모델/도구 호출 (인수는 필요에 따라 익명화), 생성된 아티팩트, 외부 위임.

MCP 서버: 도구 이름, 호출자 에이전트 ID, 사용자 컨텍스트, 성공/실패, 대기 시간, 영향된 행 또는 리소스 ID (정책 허용).

모든 레이어에 걸쳐 추적 ID로 상관관계 분석하십시오. LLM 시스템 관측 가능성은 계측 백엔드를 다루며, 이 기사는 이러한 백엔드가 의미 있는 신호를 가지도록 무엇을 캡처해야 하는지 정의합니다.

최종 답변 근원은 다음 질문에 답해야 합니다: 어떤 사용자, 어떤 오케스트레이터 작업, 어떤 전문가 에이전트, 어떤 도구, 어떤 아티팩트가 사용자가 본 텍스트에 영향을 미쳤으며, 어떤 정책 게이트가 통과되었는지.

런타임 정책, 이gress 및 시크릿

런타임 정책 엔진(OPA, Cedar, 사용자 정의 규칙 서비스)은 구조화된 이벤트를 평가합니다: “사용자 Z를 위한 도구 X 및 인수 Y.” 이는 모델이 잘 행동할 필요 없이 가드레일을 보완합니다.

인간 승인은 되돌릴 수 없거나 고비용 작업에 대한 런타임 정책에 포함되어야 합니다: 결제, 외부 이메일, 프로덕션 구성 변경, 권한 부여.

이gress 제어는 MCP 서버 및 에이전트가 호출할 수 있는 도메인을 제한합니다. 시크릿을 읽고 임의의 URL로 POST할 수 있는 에이전트는 데이터 손실의 전조입니다.

시크릿은 에이전트 카드나 프롬프트에 포함되지 않아야 합니다. MCP 호스트는 시크릿 매니저에서 실행 시점에 짧은 수명의 자격 증명을 삽입해야 합니다. 전송 암호화, 키 관리 및 기본 인프라 보안 패턴에 대해서는 데이터 보안 아키텍처 패턴을 참조하십시오.

비동기 A2A 흐름의 푸시 알림 웹훅은 동일한 엄격성이 필요합니다: 발신자 아이덴티티를 검증하고, 오래된 이벤트를 거부하며, 웹훅 페이로드 자체를 인증으로 취급하지 마십시오.

참조 보안 아키텍처

다음 다이어그램은 대규모 A2A 외부, MCP 내부 배포를 위한 프로덕션 중심 레이아웃을 요약합니다.

flowchart TB subgraph Client layer U[User / API client] end subgraph Control plane GW[A2A gateway] REG[Agent registry] POL[Policy engine] AUD[Audit log] SEC[Secrets manager] end subgraph Agent layer OR[Orchestrator] SA[Specialist agents] end subgraph Tool layer MG[MCP gateway] MCP[MCP servers] end subgraph Observability OBS[Tracing + metrics] end U --> GW GW --> REG GW --> POL GW --> OR OR --> GW GW --> SA SA --> MG MG --> MCP POL --> GW POL --> MG SEC --> SA SEC --> MCP GW --> AUD MG --> AUD SA --> AUD AUD --> OBS

오케스트레이터는 A2A를 통해 전문가 에이전트를 봅니다. 전문가는 MCP를 통해 도구를 봅니다. 사용자는 원시 MCP 자격 증명을 받지 않으며, 파트너는 정책 검토 없이 내부 기술 표면을 받지 않습니다.

프로토콜 개념(에이전트 카드, 작업, 아티팩트)에 대해서는 A2A 프로토콜이란 무엇인가?을 참조하십시오. 채택 및 엔터프라이즈 프레임에 대해서는 2026년 Google A2A 프로토콜을 참조하십시오. 많은 에이전트가 조정될 때의 토폴로지에 대해서는 다중 에이전트 오케스트레이션 패턴을 참조하십시오.

A2A 및 MCP 보안 프로덕션 체크리스트

신뢰할 수 있는 샌드박스 너머로 에이전트 프로토콜을 노출하기 전에 다음을 확인하십시오:

아이덴티티 및 인증

  • 프로덕션 경로에 익명 에이전트 없음
  • 모든 MCP 및 A2A 호출이 모든 요청에서 인증됨
  • OAuth 범위 또는 동등물이 기술/도구에 매핑됨, 전체 관리가 아님
  • 공개 vs 인증된 에이전트 카드 뷰가 의도적으로 정의됨

위임 및 정책

  • 위임 토큰이 사용자 ID, 작업 ID, 범위, 만료, 홉 제한을 보유
  • 하위 에이전트가 명시적인 승인 없이 범위 확장을 거부
  • 고위험 도구가 런타임 정책 또는 인간 승인을 필요로 함
  • 추론 및 실행이 가능한 경우 별도 자격 증명 사용

발견 및 레지스트리

  • 에이전트 레지스트리 엔트리가 소유자 및 버전 이력을 보유
  • 에이전트 카드가 TTL에서 새로 고침됨; 서명 지원 검증
  • 파트너 에이전트가 명시적인 기술 허용 목록으로 연방화됨

감사 및 관측 가능성

  • 게이트웨이, 에이전트 및 MCP 레이어가 상관관계 있는 감사 이벤트를 방출
  • 위임 체인이 부모 및 하위 작업 ID로 로깅됨
  • 최종 답변을 위한 아티팩트 근원이 기록됨
  • 추적 ID가 관측 가능성 백엔드에 연결됨

악용 및 복원력

  • 사용자, 에이전트 및 테넌트별 속도 제한
  • 위임된 작업에 대한 타임아웃 정책
  • 도구 서버에 대한 이gress 허용 목록
  • 시크릿이 매니저에 있으며, 카드, 프롬프트 또는 리포지토리가 아님

결론

A2A 및 MCP 상호 운용성은 에이전트 및 도구가 팀 및 벤더 경계를 가로질러 구성될 수 있기 때문에 강력하지만, 아이덴티티, 인증, 위임 한계 및 감사 설계 없이는 그 힘이 안전하지 않습니다. 가드레일은 모델 대화를 보호하고, 프로토콜 보안은 에이전트가 사용자를 대신하여 취하는 행동을 보호합니다.

에이전트 카드를 광고로, 위임을 서명된 계약으로, MCP 도구를 특권 코드 실행으로, 감사 로그를 오전 2시에 흥미로운 일이 발생할 때 필요할 증거 사슬로 취급하십시오.

거버넌스가 단일 목을 조이는 것이 필요할 때 게이트웨이를 구축하십시오. 에이전트를 분할하기 전에 자격 증명을 분할하십시오. “모델이 결정했다"는 답변이 최종 사고 보고서가 되지 않도록 모든 홉을 로깅하십시오.

자주 묻는 질문

LLM 가드레일과 A2A MCP 에이전트 보안의 차이점은 무엇인가? 가드레일은 모델 입력 및 출력을 제약합니다. 프로토콜 보안은 아이덴티티, 인증 및 감사 흔적을 통해 MCP 및 A2A를 통해 도구를 호출하고, 작업을 위임하며, 누구를 대신하여 행동할 수 있는지를 제약합니다.

A2A 배포에서 에이전트 아이덴티티는 어떻게 작동해야 하는가? 인간, 에이전트 서비스 및 작업 아이덴티티를 분리하십시오. 모든 요청에서 자격 증명 유효성을 검사하고, 범위 지정된 토큰을 사용하며, 에이전트 카드를 신뢰 증명이 아닌 발견 메타데이터로 취급하십시오.

다중 에이전트 시스템에서 혼란스러운 대리인 문제는 무엇인가? 특권 에이전트 또는 도구가 덜 특권 호출자가 위임 또는 아티팩트를 통해 지침을 숨겨 전달하기 때문에 민감한 작업을 수행할 때 발생합니다. 모든 홉에서 범위를 강제하십시오.

프로덕션에서 A2A 게이트웨이가 필요한가? 단일 팀 내부 배포는 에이전트별 정책을 강제할 수 있습니다. 다중 테넌트, 다중 벤더 또는 파트너 대상 네트워크는 일반적으로 중앙 집중식 인증, 라우팅, 속도 제한 및 감사를 위해 게이트웨이가 필요합니다.

A2A MCP 감사 로그에는 무엇이 포함되어야 하는가? 사용자 ID, 에이전트 ID, 작업 ID, 상위 작업 ID, 도구 호출, 정책 결정, 아티팩트 및 게이트웨이, 에이전트 및 MCP 레이어에 걸쳐 추적 ID와 상관관계 있는 타임스탬프.

출처

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.