들어가며: 규제와 협업이 만든 새로운 데이터 교환의 장
유럽연합(EU)의 탄소국경조정제도(CBAM)와 공급망 실사 지침(CSDDD)이 본격화되면서, 자동차 산업의 공급망 탄소 배출 데이터(PCF, Product Carbon Footprint)는 단순한 ESG 보고 자료를 넘어 규제 준수의 핵심 요소로 자리 잡았습니다. 하지만 현실은 녹록지 않아요. 대부분의 기업이 여전히 엑셀 파일과 이메일로 PCF를 주고받고 있고, 데이터 형식도 제각각이라 비교와 검증이 어렵습니다.
이런 상황에서 Catena-X는 자동차 산업의 표준화된 데이터 교환 네트워크로 주목받고 있습니다. 핵심은 **데이터 주권(Data Sovereignty)**입니다. 즉, 내 데이터는 내가 통제하되, 필요한 정보만 협력사와 안전하게 공유할 수 있어야 합니다. BASF와 CircularTree가 공동 개발한 PACIFIC은 이 Catena-X 데이터 스페이스 위에서 동작하는 멀티테넌트 SaaS 플랫폼으로, AWS의 네이티브 서비스만으로 이 까다로운 요구사항을 해결했습니다.
이 글에서는 PACIFIC의 아키텍처를 세 가지 핵심 축으로 나누어 살펴보겠습니다:
- IAM 기반의 테넌트 격리 (Amazon Cognito + AWS Secrets Manager)
- EDC 발행 인증 토큰을 통한 데이터 교환 보안
- 공급사 PCF 시스템 통합을 위한 유연한 모듈 설계
각 설계가 왜 필요했고, 어떤 트레이드오프를 고려했는지 함께 고민해봅시다.
참고 자료: 이 사례는 AWS Architecture Blog에 게재된 내용을 바탕으로 재구성했습니다.
본론 1: IAM 기반 멀티테넌트 격리 — "계정 대신 정책으로"
멀티테넌트 SaaS를 설계할 때 가장 먼저 부딪히는 질문은 '테넌트를 어떻게 격리할 것인가?' 입니다. 전통적인 방법은 고객사마다 별도의 AWS 계정을 할당하는 것이지만, 이는 관리 오버헤드가 크고 온보딩 속도를 떨어뜨립니다.
PACIFIC은 다른 길을 선택했습니다. Amazon Cognito + AWS IAM + AWS Secrets Manager 조합으로 계정 없이도 완벽한 격리를 구현한 거죠.
동작 방식
- 테넌트 온보딩: 새로운 회사가 가입하면, 자동으로 전용 IAM 역할이 생성됩니다. 이 역할에는 해당 회사의 Secrets Manager 비밀만 읽을 수 있는 스코프 정책이 연결됩니다.
- 사용자 인증: 사용자는 Amazon Cognito 사용자 풀에 속하며, 자신의 회사 그룹에 매핑됩니다. 로그인 시 Cognito Identity Pool이 그룹 정보를 IAM 역할로 연결하고, AWS STS가 임시 자격 증명을 발급합니다.
- 데이터 접근 제어: 발급된 자격 증명으로는 오직 자기 회사의 EDC(데이터 커넥터) 시크릿과 DTR(디지털 트윈 레지스트리) 자격 증명만 조회할 수 있습니다. 다른 테넌트의 데이터는 IAM 정책 레벨에서 완전히 차단됩니다.
# 예시: 테넌트별 IAM 정책 (Python-like pseudo code)
# 실제 AWS IAM 정책 JSON입니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:PutSecretValue"
],
"Resource": "arn:aws:secretsmanager:region:account:secret:tenant-{TENANT_ID}-*"
},
{
"Effect": "Deny",
"Action": "secretsmanager:*",
"Resource": "*",
"Condition": {
"StringNotLike": {
"secretsmanager:ResourceTag/TenantId": "${aws:PrincipalTag/tenant-id}"
}
}
}
]
}
실무 포인트
- 확장성: 새 테넌트 추가 시 IAM 역할과 Cognito 그룹만 생성하면 되므로, 수백 개의 고객사도 빠르게 온보딩할 수 있습니다. BASF는 이 방식을 통해 2024년 대비 2025년에 신규 온보딩 회사 수가 80% 증가했다고 합니다.
- 보안: 계정 단위 격리보다 정책 단위 격리는 실수로 인한 크로스 테넌트 접근 위험이 상대적으로 높을 수 있습니다. 따라서 **태그 기반 조건 키(Tag-Based Condition Key)**를 반드시 사용하고, 정기적으로 IAM Access Analyzer로 권한 경계를 점검하는 것이 좋습니다.
- 한국 SI 환경에서의 적용: 국내 금융권이나 대기업 전산실에서는 '계정 분리'가 규정상 필수인 경우가 많습니다. 이 아키텍처는 규제가 상대적으로 덜한 B2B SaaS나 스타트업에 먼저 적용해보고, 점진적으로 규제 요건을 충족하는 방향으로 발전시키는 전략이 좋습니다.
본론 2: EDC 인증 토큰으로 데이터 교환의 신뢰 확보
테넌트 격리가 플랫폼 내부 보안을 담당한다면, 데이터 교환 레이어의 보안은 Catena-X 생태계와의 상호 운용성을 결정짓는 핵심입니다. PACIFIC은 pcf-exchange-module이라는 전용 엔드포인트를 통해 이 문제를 해결합니다.
EDC-to-EDC 통신 흐름
- 정책 협상: 소비자(Consumer) EDC가 공급자(Supplier) EDC에 PCF 데이터를 요청합니다. 두 EDC는 Catena-X 표준에 따라 사용 정책(Usage Policy)을 협상합니다. (예: "이 데이터는 30일 동안만 사용 가능")
- 토큰 발급: 협상이 완료되면, 공급자 EDC는 공급자 회사의 Cognito 앱 클라이언트 자격 증명을 사용하여 특별한 OAuth2 인증 토큰을 발급합니다. 이 토큰은 오직 공급자의 pcf-exchange-module 엔드포인트만 접근할 수 있습니다.
- 데이터 전송: 소비자 EDC는 발급받은 토큰을 사용해 공급자의 전용 엔드포인트를 호출하고, PCF 데이터를 수신합니다.
// 예시: EDC 정책 협상 후 발급되는 OAuth2 토큰 요청 (curl)
curl -X POST https://supplier-cognito-endpoint/oauth2/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-d "client_id=supplier-edc-client-id" \
-d "client_secret=supplier-edc-client-secret" \
-d "scope=pcf-exchange-module:read"
# 응답 예시
{
"access_token": "eyJhbGciOiJSUzI1NiIs...",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "pcf-exchange-module:read"
}
주의사항 및 한계
- 토큰 만료 관리: EDC 토큰은 기본적으로 1시간 유효합니다. 장기간 데이터 동기화가 필요한 배치 작업의 경우, 토큰 리프레시 로직이 반드시 필요합니다.
- EDC 커넥터 설정 복잡성: Catena-X EDC는 오픈소스이지만 초기 설정이 까다롭습니다. 특히 각 회사마다 EDC 인스턴스를 운영해야 하므로, 운영 부담이 작지 않습니다. PACIFIC은 이를 SaaS로 감싸서 제공하지만, 자체 구축 시에는 EDC 운영 인력이 필요합니다.
- 한국 개발 생태계에서의 적용: 국내에서는 Catena-X가 아직 생소할 수 있습니다. 하지만 현대차그룹이나 기아가 글로벌 공급망 규제에 대응하기 위해 유사한 데이터 스페이스 도입을 검토 중이라는 점을 고려하면, 이 아키텍처는 향후 2~3년 내에 국내 자동차 부품사에도 큰 영향을 미칠 가능성이 높습니다. 미리 공부해두면 좋습니다.
본론 3: 공급사 PCF 시스템 통합 모듈 — 유연성과 격리의 균형
PACIFIC의 또 다른 강점은 integration-module입니다. 이 모듈은 BASF와 같은 대형 공급사가 내부 PCF 시스템(예: 자체 API, 레거시 ERP)과 PACIFIC을 연결할 수 있도록 설계되었습니다.
설계 원칙
- 비동기 및 확장성: AWS Fargate에서 실행되므로 트래픽에 따라 자동으로 스케일링됩니다. 공급사가 많아져도 인프라를 걱정할 필요가 없습니다.
- 인증 유연성: 각 공급사마다 다른 인증 방식을 지원합니다. OAuth2 클라이언트 자격 증명, 인증서 기반 인증, API 키 등 모든 시크릿은 AWS Secrets Manager에 안전하게 저장됩니다.
- 데이터 형식 표준화: 통합 모듈은 들어오는 PCF 데이터가 이미 Catena-X 표준 JSON 형식을 따르고 있다고 가정합니다. 이는 데이터 정합성을 유지하는 핵심입니다.
// Catena-X 표준 PCF JSON 형식 예시
{
"@context": {
"pcf": "https://catena-x.net/pcf/v1"
},
"pcf:productId": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
"pcf:companyId": "BASF",
"pcf:measurementDate": "2025-04-01T00:00:00Z",
"pcf:carbonFootprint": 12.34,
"pcf:unit": "kgCO2e",
"pcf:status": "Active",
"pcf:declaredUnit": "kg",
"pcf:geographyCountry": "DE"
}
통합 모듈의 장점
- 느슨한 결합: 공급사 시스템 변경이 데이터 교환 레이어에 영향을 주지 않습니다. 새로운 공급사를 추가할 때도 integration-module만 확장하면 됩니다.
- 데이터 주권 강화: PCF 데이터는 Amazon S3에 회사별 접두사로 저장되며, IAM 정책이 해당 회사만 접근 가능하도록 통제합니다. 데이터 소유권이 명확히 보장됩니다.
한계와 보완점
- 실시간성: 현재 설계는 배치(batch) 기반에 가깝습니다. 실시간 PCF 업데이트가 필요하다면, Amazon S3 이벤트 알림 + Lambda를 조합하여 near-real-time 파이프라인으로 전환할 수 있습니다.
- 데이터 검증: 표준 형식을 가정하지만, 실제로는 형식 오류가 발생할 수 있습니다. 통합 모듈에 JSON Schema 검증 단계를 추가하는 것이 안전합니다.
결론: PACIFIC이 주는 교훈과 다음 단계
PACIFIC의 사례는 단순한 기술 구현을 넘어, 데이터 주권과 협업이라는 상충되는 가치를 AWS 네이티브 서비스만으로 어떻게 해결할 수 있는지를 보여줍니다. 특히 다음과 같은 점이 인상적입니다:
- IAM 기반 격리는 계정 분리보다 운영 효율성이 높고, 자동화된 온보딩을 가능하게 합니다.
- EDC 토큰 기반 교환은 Catena-X 표준을 준수하면서도 실무에서 바로 쓸 수 있는 보안 수준을 제공합니다.
- 통합 모듈의 분리는 공급사 시스템의 다양성을 흡수하면서도 핵심 데이터 교환 로직을 깨끗하게 유지합니다.
비즈니스 성과도 뚜렷합니다. BASF는 PCF 데이터 교환 시간을 7일에서 수초로 단축했고, 온보딩 회사 수는 80% 증가했습니다. 이는 단순한 기술 도입이 아니라, 규제 대응을 넘어 경쟁 우위로 연결된 사례입니다.
다음 단계 학습 방향
- Catena-X 및 EDC 실습: Eclipse Dataspace Components의 공식 튜토리얼을 따라해보세요. 직접 EDC 인스턴스를 띄워보면 이해도가 훨씬 높아집니다.
- AWS SaaS 아키텍처 심화: AWS Well-Architected Framework의 SaaS 렌즈 문서를 읽어보세요. 특히 테넌트 격리 패턴(계정/정책/데이터 계층)을 비교해보는 것을 추천합니다.
- 탄소 회계 데이터 모델: PCF 데이터의 의미를 더 깊이 이해하려면, GHG Protocol과 ISO 14067 표준을 공부해보세요. 데이터의 신뢰성은 기술보다 도메인 지식에서 나옵니다.