금융 클라우드 길라잡이 A to Z Part 2 – 연구개발망 예외와 망분리 개선 로드맵

본 블로그는 2026년 6월 기준으로 작성되었으며, 이후 규제 변경이나 AWS 서비스 업데이트가 반영되지 않을 수 있습니다. 규제 관련 내용은 기술적 관점에서의 해석을 제공하며, 법률 자문을 대체하지 않습니다. 구체적인 규제 적용에 대해서는 자체 컴플라이언스 팀 및 법률 전문가와 상담하시기 바랍니다.

본 글에서는 금융 클라우드 길라잡이 A to Z Part 1 — 전자금융감독규정으로 풀어보는 클라우드 도입 첫걸음에 이어, 전자금융감독규정 개정에 따른 망분리 예외 활용과 AWS 멀티 계정 아키텍처로 안전한 R&D 환경을 구현하기 위한 방법을 실무 관점에서 안내합니다.

서론: 금융 비즈니스 혁신의 가속화

생성형 AI의 등장은 금융 서비스 산업에 전례 없는 혁신의 기회를 가져왔습니다. 코딩 어시스턴트를 활용한 개발 생산성 향상, 머신러닝 기반 리스크 모델링, 자연어 처리를 통한 고객 서비스 자동화 등 새로운 비즈니스 기회가 빠르게 확대되고 있습니다. 동시에 Tech-Fin 기업과의 경쟁이 심화되면서, 전통 금융사의 기술 혁신 속도는 경쟁력의 핵심 요소가 되었습니다.

그러나 한국 금융권에는 고유한 도전이 있습니다. 2013년부터 시행된 망분리 규제는 금융 전산 보안의 근간이지만, 동시에 외부 인터넷 리소스를 활용한 연구·개발 환경 구축을 어렵게 만드는 제약이기도 했습니다. 개발자가 최신 오픈소스 라이브러리를 다운로드하거나, 클라우드 기반 AI 서비스를 활용하는 것이 기존 규제 체계에서는 사실상 불가능했습니다.

2024년 8월, 금융위원회가 발표한 ‘금융분야 망분리 개선 로드맵’은 이러한 상황의 전환점이 되었습니다. 연구·개발망에 대한 논리적 망분리가 허용되고, 생성형 AI 및 SaaS 활용이 가능해지면서, 금융사는 이제 보안과 혁신을 동시에 추구할 수 있는 길이 열렸습니다.

본 블로그에서는 연구·개발망의 규제 프레임워크를 이해하고, AWS 환경에서 이를 구현하기 위한 아키텍처 설계와 실제 활용 사례를 단계별로 안내합니다.

이 글에서 다루는 것

규제 프레임워크 이해: 연구·개발망이란 무엇인가

망분리 규제의 변천사

한국 금융권의 망분리는 2013년 금융위원회의 ‘금융전산 보안강화 종합대책’에서 시작되었습니다. 이후 10년간 단계적으로 변화해 왔습니다.

초기 연구·개발망의 모델은 카카오뱅크 금융기술연구소 사례에서 비롯되었습니다. 핀테크 개발시스템을 내부망 및 인터넷망과 물리적으로 분리하여 전자금융감독규정을 충족하는 방식이었습니다. 이 사례가 이후 규정에 반영되어 연구·개발망이라는 개념이 제도화되었습니다.

연구·개발망의 정의

연구·개발망이란, 프로그램 개발 등 금융서비스의 연구·개발을 할 수 있도록 금융회사의 내부업무망·전산실, 외부망으로부터 독립적으로 구성된 개발시스템망을 의미합니다.

전자금융감독규정 제15조 제1항 제3호 가목 신설에 따라, 연구·개발 목적의 내부통신망은 외부 통신망과의 분리·차단 및 접속 금지 예외가 가능해졌습니다.

<그림 1. 연구·개발 분야 망분리 구조도 (출처: 금융보안원, 연구·개발 목적의 망분리 예외적용에 따른 보안 해설서, 2025.4)>

2024년 8월 개선 로드맵 이후, 연구·개발망에는 다음과 같은 핵심 변화가 적용되었습니다.

• 논리적 망분리 허용: 기존 물리적 분리 요건이 논리적 분리로 완화
• 소스코드 내부 배포 허용: 연구·개발 산출물을 내부망으로 반입 가능
• 가명정보 활용 가능: 가명 처리된 데이터를 연구·개발 목적으로 사용
• IT 개발자 재택근무 가능: 보안 통제 하에 원격 접속 허용
• 소스코드 반출 가능: 예외적 상황에서 승인을 통해 반출 허용

연구·개발망 이용 절차

연구·개발망을 구축하고 활용하기 위해서는 4단계의 절차를 거쳐야 합니다.

1단계: 활용 범위 판단 : 어떤 업무를 수행할 것인지, 개인신용정보 이용이 필요한지 등을 검토합니다.

2단계: 자체 위험성 평가 : 소스코드 유출, 취약한 오픈소스 사용, 내부 침해위협 전파 등 보안 위협을 식별하고, 발생 가능성과 대응방안을 수립합니다.

3단계: 정보보호 통제 및 추가 보호대책 적용 : 외부 인터넷 접근통제, 내부망과의 논리적/물리적 분리, 단말기 및 시스템 보호대책, 침해사고 대응대책, 소스코드 보안관리대책 등을 구현합니다.

4단계: 정보보호위원회 심의·의결 : 업무 적정성, 망간 전송 자료 적정성, 보안 위험 식별 및 평가, 보안통제 적정성을 심의하여 최종 의결합니다.

이 절차에서 요구하는 기술적 통제 요건이 이후 설명하는 AWS 아키텍처의 설계 기준이 됩니다.

AWS 환경에서 연구·개발망 구성하기: 계정 및 사용자 관리

멀티 계정 전략의 선택

AWS에서 연구·개발망을 구성할 때 가장 먼저 결정해야 할 사항은 계정 전략입니다.

규제에서 요구하는 ‘독립적으로 구성된 개발시스템망’이라는 조건은 AWS의 멀티 계정 전략과 자연스럽게 대응됩니다. 연구·개발망 전용 계정을 분리하면, 네트워크 경계, IAM 경계, 비용 경계가 자연스럽게 형성됩니다.

Control Tower에 R&D OU 추가하기

이미 AWS Control Tower를 운영 중인 금융사라면, 별도의 Control Tower를 구성할 필요 없이 기존 Organization에 R&D OU만 추가하면 됩니다. 기존 거버넌스(SCPs, 로깅 정책, 보안 기준선)가 동일하게 적용되면서, R&D 특화 정책만 추가로 구성할 수 있습니다.

<그림 2. AWS Control Tower Organization 구조 내 R&D OU 배치>

R&D OU 내에서는 태그와 CIDR 블록을 통해 내부망과 연구·개발망 리소스를 명확하게 구분합니다.

IAM 권한 관리: 최소 권한 원칙

연구·개발망의 사용자 권한은 최소 권한 원칙(Least Privilege)에 기반하여 설계합니다. 접근 방식은 크게 두 가지입니다.

허용(Allow) 기반: 사용하고자 하는 서비스를 명시적으로 허용하고, 관리자가 미리 구성한 네트워크 요소를 제외한 나머지 서비스만 허용합니다.

거부(Deny) 기반: NotAction을 통해 사용할 서비스를 명시하고, 나머지를 거부합니다.

다음은 R&D OU에 적용할 수 있는 SCP(Service Control Policy) 예시입니다. 허용된 리전 외의 모든 API 호출을 거부하여, 연구·개발 활동이 승인된 리전에서만 수행되도록 합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "sts:*",
        "organizations:*",
        "support:*",
        "billing:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-2",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

참고: us-east-1은 Amazon Q Developer, Kiro 등 일부 글로벌 서비스의 엔드포인트가 위치한 리전으로, 필요에 따라 포함합니다. Kiro 사용 시 eu-central-1 리전도 검토하세요.

다음은 NotAction 패턴을 활용한 R&D 개발자 IAM 정책 예시입니다. 네트워크 인프라 변경을 방지하면서 개발에 필요한 서비스를 허용합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNetworkChanges",
      "Effect": "Deny",
      "Action": [
        "ec2:CreateVpc",
        "ec2:DeleteVpc",
        "ec2:CreateSubnet",
        "ec2:DeleteSubnet",
        "ec2:ModifyVpcAttribute",
        "ec2:CreateTransitGateway*",
        "ec2:DeleteTransitGateway*",
        "ec2:CreateVpnConnection",
        "directconnect:*"
      ],
      "Resource": "*"
    }
  ]
}

IP 기반 접근 제한

지정한 물리적 위치(사무실, 승인된 원격 근무 장소)에서만 AWS 콘솔 및 API에 접근할 수 있도록, 세션 정책에 IP 기반 조건을 추가합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessFromUnapprovedIPs",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "198.51.100.0/24"
          ]
        },
        "Bool": {
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

연구·개발망을 다중 계정으로 운영할 경우, IAM Identity Center(구 AWS SSO)를 통해 Permission Set을 관리하면 계정 간 일관된 접근 제어가 가능합니다. 정책 설정 후에는 IAM Access Analyzer를 통해 주기적으로 미사용 권한을 확인하고 조정합니다.

AWS 환경에서 연구·개발망 구성하기: 네트워크 아키텍처

기업 데이터센터와 클라우드 연결

연구·개발망은 기존 내부업무망(3호망), 전산실(5호망)과 독립적이면서도, 승인된 경로를 통해 제한적으로 통신할 수 있어야 합니다. AWS에서는 AWS Direct Connect와 Transit Gateway(TGW)를 활용하여 이 연결을 구성합니다.

<그림 3. 클라우드 상의 연구·개발망 연결 구성>

핵심 설계 원칙은 다음과 같습니다.

• 연구·개발망용 Account를 전산실 Account와 분리 구성 — 금융분야 망분리 개선 로드맵의 논리적 망분리 요건 충족
• 전용 구간 통신 및 VLAN을 활용한 논리적 망간 분리 — 전자금융감독법 제60조 5항 근거
• 망간 자료 전송은 승인 절차를 통해서만 허용 — 제한적·한시적 허용 원칙

각 Account의 Transit Gateway는 독립적으로 구성하고, 필요한 경우 TGW 피어링을 통해 연결합니다.

Ingress VPC 설계

연구·개발망으로 들어오는 모든 트래픽은 Ingress VPC를 통해 중앙 집중화하여 검사합니다.

<그림 4. Ingress VPC 구성>

Egress VPC 설계

연구·개발망의 핵심 특성인 인터넷 접속은 Egress VPC를 통해 통제합니다. 개발자가 외부 리소스(패키지 레지스트리, AI 서비스 API 등)에 접근할 수 있으면서도, 데이터 유출을 방지해야 합니다.

<그림 5. Egress VPC 구성>

다음은 AWS Network Firewall에서 허용된 도메인만 접근 가능하도록 구성하는 규칙 예시입니다.

{
  "RuleGroup": {
    "RulesSource": {
      "RulesSourceList": {
        "Targets": [
          ".pypi.org",
          ".npmjs.org",
          ".github.com",
          ".amazonaws.com",
          ".kiro.dev",
          ".docker.io"
        ],
        "TargetTypes": ["HTTP_HOST", "TLS_SNI"],
        "GeneratedRulesType": "ALLOWLIST"
      }
    }
  },
  "RuleGroupName": "rnd-egress-domain-allowlist",
  "Type": "STATEFUL",
  "Capacity": 100
}

Route 53 DNS Firewall은 AWS 관리형 도메인 목록을 활용하여 알려진 악성 도메인을 원천 차단합니다.

{
  "FirewallRuleGroupAssociation": {
    "FirewallRuleGroupId": "rslvr-frg-example",
    "VpcId": "vpc-rnd-egress",
    "Priority": 101,
    "Name": "rnd-malware-block"
  },
  "Rules": [
    {
      "Action": "BLOCK",
      "BlockResponse": "NXDOMAIN",
      "FirewallDomainListId": "AWSManagedDomainsMalwareDomainList",
      "Priority": 1
    },
    {
      "Action": "BLOCK",
      "BlockResponse": "NXDOMAIN",
      "FirewallDomainListId": "AWSManagedDomainsBotnetDomainList",
      "Priority": 2
    }
  ]
}

중앙 집중 트래픽 검사

모든 VPC 간 통신(East-West)과 인터넷 통신(North-South)의 침해 위협을 탐지하기 위해, Transit Gateway에 AWS Network Firewall을 연결한 중앙집중형 검사 아키텍처를 구성합니다.

<그림 6. VPC 간 보안 강화를 위한 AWS Network Firewall 중앙 검사 아키텍처>

Transit Gateway를 통해 VPC 간 통신을 수행하면 모든 트래픽을 탐지할 수 있으며, AWS Network Firewall을 TGW에 연결하면 복잡한 라우팅 설정 없이 적용할 수 있습니다.

보안 서비스 통합

네트워크 아키텍처 위에 다음 보안 서비스를 통합하여 지속적인 모니터링과 컴플라이언스를 확보합니다.

<그림 7. 연구·개발망 전체 보안 서비스 Landscape>

기존 온프레미스 환경에서 사용하던 3rd Party 방화벽 어플라이언스를 연구·개발망에도 그대로 적용할 수 있지만, 연구·개발 특성상 트래픽 사용량이 상대적으로 적어 고정 비용 대비 효율이 낮을 수 있습니다. AWS Native 보안 서비스(Network Firewall, GuardDuty, Security Hub, Config 등)를 활용하면 사용량 기반 과금으로 비용을 최적화하면서도, Account 내 보안 위협을 통합 대시보드에서 실시간으로 가시화할 수 있습니다. 특히 Security Hub는 여러 보안 서비스의 결과를 한곳에 집약하여, 정보보호위원회 보고에 필요한 보안 상태 현황을 자동으로 구성합니다.

AWS 환경에서 연구·개발망 활용하기

네트워크와 보안 인프라가 구성되면, 이제 실제 연구·개발 활동을 수행할 차례입니다. 다음은 연구·개발망에서 가능한 대표적 활용 사례입니다.

사례 1: Kiro — 코딩 어시스턴트 활용

연구·개발망에서 생성형 AI 코딩 어시스턴트를 활용하면 개발 생산성을 크게 향상시킬 수 있습니다. Kiro를 프라이빗 네트워크에서 사용하기 위해, VPC Peering과 PrivateLink를 통해 서울 리전(ap-northeast-2)과 미국 동부 리전(us-east-1) 간 프라이빗 연결을 구성합니다.

<그림 8. Kiro 크로스 리전 PrivateLink 구성>

# VPC Endpoint for Kiro (PrivateLink)
# Kiro는 기존 Amazon Q Developer VPC Endpoint를 계승하며,
# kiro.dev Private DNS로 자동 확장됩니다.

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  KiroEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcId: !Ref RnDVpcId
      ServiceName: com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxxx
      VpcEndpointType: Interface
      SubnetIds:
        - !Ref PrivateSubnetA
        - !Ref PrivateSubnetC
      SecurityGroupIds:
        - !Ref KiroEndpointSG
      PrivateDnsEnabled: false

참고: Amazon Q Developer에서 Kiro로의 전환
* 2026년 5월 15일부로 Amazon Q Developer IDE 플러그인의 신규 가입이 차단되었으며, 2027년 4월 30일에 완전 지원이 종료됩니다. Kiro는 Amazon Q Developer의 공식 후속 제품으로, 기존 Q Developer VPC Endpoint가 kiro.dev Private DNS로 자동 확장됩니다. 이미 Q Developer VPC Endpoint를 구성한 환경에서는 별도의 신규 VPC Endpoint 생성 없이 Kiro를 사용할 수 있으며, 방화벽 정책에서 .kiro.dev 도메인(runtime.{region}.kiro.dev, management.{region}.kiro.dev, telemetry.{region}.kiro.dev)을 허용 목록에 추가하면 됩니다. 현재 지원 리전은 us-east-1과 eu-central-1입니다.

개발자는 Kiro IDE 및 Kiro CLI를 통해 인터넷 없이도 코드 생성, 설명, 리팩토링, 보안 취약점 스캔 등의 기능을 활용할 수 있습니다. Kiro의 spec-driven development 방식은 요구사항 문서(spec)를 기반으로 코드를 자동 생성하므로, 금융사의 정형화된 개발 프로세스와 잘 맞습니다.

사례 2: Amazon SageMaker — ML 모델 연구와 개발

연구·개발망에서 가명 처리된 금융 데이터를 활용하여 ML 모델을 연구·개발할 수 있습니다. Amazon SageMaker를 프라이빗 서브넷에 배포하고, VPC Endpoint를 통해 S3, EFS 등 필요한 서비스에 접근합니다.

<그림 9. 연구·개발망을 활용한 ML 모델 연구와 개발 아키텍처>

학습이 완료된 모델은 Amazon S3에 저장되며, 전산실로의 반입은 승인된 망간 자료 전송 절차를 통해서만 이루어집니다.

사례 3: 연구·개발 산출물의 전산실 반입

연구·개발망에서 생성된 소스코드, 학습된 모델 등의 산출물을 전산실(내부망)로 반입할 때는 보안 스캐닝 → 승인 → 전송의 자동화된 워크플로우를 구성합니다.

<그림 10. 연구·개발 산출물 전산실 반입 워크플로우>

AWS Step Functions를 활용하여 이 파이프라인을 오케스트레이션합니다.

{
  "Comment": "R&D Artifact Transfer Workflow",
  "StartAt": "SecurityScan",
  "States": {
    "SecurityScan": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-2:ACCOUNT:function:security-scanner",
      "Comment": "보안 취약성 탐지 등 스캐닝 수행",
      "Next": "CheckScanResult"
    },
    "CheckScanResult": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.scanResult",
          "StringEquals": "PASS",
          "Next": "RequestApproval"
        }
      ],
      "Default": "ScanFailed"
    },
    "RequestApproval": {
      "Type": "Task",
      "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
      "Parameters": {
        "QueueUrl": "https://sqs.ap-northeast-2.amazonaws.com/ACCOUNT/approval-queue",
        "MessageBody": {
          "taskToken.$": "$$.Task.Token",
          "artifactId.$": "$.artifactId",
          "message": "담당자를 통한 결재 및 승인 요청"
        }
      },
      "Next": "TransferToProduction"
    },
    "TransferToProduction": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-2:ACCOUNT:function:datasync-transfer",
      "Comment": "AWS DataSync를 통한 망간 자료 전송",
      "Next": "TransferComplete"
    },
    "TransferComplete": {
      "Type": "Succeed"
    },
    "ScanFailed": {
      "Type": "Fail",
      "Error": "SecurityScanFailed",
      "Cause": "보안 스캔에서 취약점이 발견되었습니다."
    }
  }
}

대상 S3 버킷에는 Versioning, Object Lock, Logging을 활성화하여 산출물의 무결성과 감사 추적성을 보장합니다.

운영 고려사항

정보보호위원회 보고 체계

연구·개발망 운영 시 정기적으로 정보보호위원회에 보안 상태를 보고해야 합니다. AWS Security Hub의 통합 대시보드와 AWS Config의 규정 준수 보고서를 활용하면 보고 자료 준비를 자동화할 수 있습니다.

로깅 및 감사

CloudTrail Organization Trail을 구성하여 R&D OU 내 모든 계정의 API 호출을 중앙 로그 아카이브 계정에 수집합니다. 이는 규제 감사 시 핵심적인 증거 자료가 됩니다.

비용 관리

주요 비용 항목은 Network Firewall(시간당 과금 + 데이터 처리), Transit Gateway(어태치먼트 + 데이터 처리), WorkSpaces(월정액 또는 시간제)입니다. SageMaker 학습 작업에는 Spot Instance를 활용하고, 개발 환경은 업무 시간 외 자동 중지를 설정하여 비용을 최적화합니다.

연구·개발망의 활용 범위와 한계

연구·개발망의 가치를 극대화하기 위해서는, 이 환경이 할 수 있는 것과 할 수 없는 것을 명확히 이해해야 합니다.

연구·개발망은 기존 개발계의 대체재가 아닌 새로운 실험망

연구·개발망은 대외계 등 기존 정보처리시스템과 연결될 수 없습니다. 망분리 원칙상 개발계와 운영 환경이 직접 연결되지 않는 것은 동일하나, 기존 개발계는 대외계·외부 시스템이 별도로 구성한 개발 환경과 연동되어 실제 업무 흐름에 준하는 테스트를 수행할 수 있습니다. 연구·개발망은 여기서 한 단계 더 격리되어, 이러한 개발용 대외 연동 환경과의 접속 자체가 차단됩니다. 따라서 연구·개발망은 기존 개발계를 대체하는 것이 아니라, 새로운 기술 검증과 프로토타이핑을 위한 독립적인 실험 환경으로 활용해야 합니다. 검증이 완료된 산출물은 앞서 소개한 승인 기반 이관 프로세스를 통해 내부 개발계로 반입하여 운영 환경과 통합합니다.

AI-DLC 방법론과의 결합

연구·개발망의 진정한 가치는 AI-DLC(AI-driven Development Life Cycle)와 같은 AI 네이티브 개발 방법론과 결합할 때 극대화됩니다. 연구·개발망은 인터넷 접속이 가능하고 생성형 AI 서비스를 활용할 수 있으므로, 요구사항 분석부터 설계, 코드 생성, 테스트까지 AI와 협업하는 전체 개발 라이프사이클을 빠르게 실행할 수 있습니다. 이를 통해 기존 수주에서 수개월 걸리던 초기 개발 사이클을 수일로 단축하고, 검증된 산출물만 내부망으로 반입하여 품질과 속도를 동시에 확보할 수 있습니다.

블록체인 기반 금융 혁신의 실험장

금융사들이 새롭게 시도하는 Stablecoin, STO(Security Token Offering) 등 블록체인 기반 서비스 개발에는 다양한 외부 네트워크 연결이 필수적입니다. 퍼블릭 블록체인 노드 접근, 스마트 컨트랙트 테스트넷 배포, 외부 오라클 서비스 연동 등은 기존 내부망 환경에서는 수행할 수 없거나 사전 작업에 많은 준비가 필요한 작업입니다. 연구·개발망은 이러한 블록체인 개발에 필요한 외부 연결성을 제공하면서도, 보안 통제를 유지하는 최적의 실험 환경이 됩니다. 연구·개발망에서 비즈니스 의도를 빠르게 검증한 뒤, 확정된 설계와 코드를 내부망 개발계로 이관하여 본격적인 개발을 진행하는 전략이 가능합니다.

이후 규제 변화의 가능성

2026년 4월 20일, 금융위원회는 클라우드 기반 응용프로그램(SaaS)의 망분리 예외조치에 대한 내용을 발표하였습니다. (https://www.fsc.go.kr/no010101/86745)

해당 내용은 금융사의 업무 환경에 대한 예외조치로, 전자금융감독규정 제15조 제1항 제3호에 예외조항을 추가한 시행세칙을 발표한 것입니다. 이제 금융사들은 대내 부서 간 협업, 반복적인 업무 환경의 개선을 통한 생산성 향상, 그리고 내부 관리체계의 체계화를 위해 SaaS를 고려할 수 있습니다.

이는 앞서 언급한 망분리 개선 로드맵에 따른 것으로, 금융사들의 업무 효율을 높이며 금융소비자들의 권익을 보호하는 방향으로 제도가 점차 개선되고 있습니다. 이러한 변화를 미리 준비하고 대응하여 규제의 변화를 보다 능동적으로 활용할 필요가 있습니다.

마무리

Key Takeaways

• 연구·개발망은 기존 내부망, 인터넷망과 별도로 구축·운영합니다. AWS의 멀티 계정 전략을 통해 요구되는 논리적 분리를 구현할 수 있습니다. AWS Control Tower의 R&D OU, SCP, IAM Identity Center를 활용하면 규제 요건에 부합하는 거버넌스를 확보할 수 있습니다.
• 소스코드 등 연구·개발 산출물은 보안 절차를 거쳐 내부망으로 반입할 수 있습니다. Step Functions 기반 자동화 워크플로우가 보안 스캐닝, 승인, 전송을 체계적으로 관리합니다.
• 철저한 보안 대책 수립 및 내부 정보보호위원회 의결이 필수입니다. AWS의 보안 서비스(GuardDuty, Security Hub, Config, CloudTrail)가 지속적인 컴플라이언스 모니터링을 지원합니다.
• 연구·개발망은 개발계를 대체하는 것이 아니라, AI 방법론 적용과 블록체인 등 신기술 검증을 위한 혁신 실험장입니다. 검증된 산출물을 내부망으로 반입하는 전략으로 속도와 품질을 동시에 확보할 수 있습니다.

금융 혁신과 컴플라이언스는 양자택일의 문제가 아닙니다. 적절한 아키텍처 설계와 보안 통제를 통해 혁신과 컴플라이언스의 조화를 이루는 것이 가능합니다. AWS 클라우드 기반 연구·개발망이 그 시작점이 될 수 있습니다.

참고 자료

• 금융분야 망분리 개선 로드맵 (금융위원회, 2024.8)
• 연구·개발 목적의 망분리 예외적용에 따른 보안 해설서 (금융보안원, 2025.4)
• 전자금융감독규정 제15조 제1항 제3호 가목
• 금융분야 클라우드 컴퓨팅 서비스 이용가이드 (금융위원회)
• AWS Control Tower 사용자 가이드
• AWS Network Firewall 개발자 가이드
• AWS Transit Gateway 가이드
• Amazon Route 53 Resolver DNS Firewall
• AWS Well-Architected Framework — 금융 서비스