“이 시스템은 외부 접속이 아예 막혀 있어요”
보안팀에서 이렇게 말하면 데이터 연동 작업은 처음부터 다시 생각해야 합니다. 클라우드 기반 데이터 플랫폼은 대개 “대상 시스템에 접속해서 데이터를 가져온다”는 그림을 전제로 설계되어 있습니다. 그런데 외부에서 접속 자체가 막힌 폐쇄망 시스템이라면, 이 전제가 통하지 않습니다. Foundry는 이런 상황을 위해 연동 구조를 두 축으로 나눠 놓았습니다.
두 개의 축: Data Connection과 Data Pipeline
Data Connection은 “데이터를 어디서, 어떻게 가져오느냐”를 다루고, Data Pipeline은 “가져온 데이터를 어떻게 가공하느냐”를 다룹니다. 이 둘을 섞어서 생각하면 설계가 꼬입니다. 연동이 안 될 때는 Connection 문제인지 Pipeline 문제인지부터 구분해야 합니다.
파이프라인을 만드는 3가지 방법
| 방법 | 적합한 상황 |
|---|---|
| Pipeline Builder | 로우코드로 빠르게 변환 로직을 구성할 때 |
| Code Transforms | 복잡한 커스텀 로직이 필요할 때 |
| HyperAuto | SAP 같은 표준화된 ERP 데이터를 대량으로 자동 매핑할 때 |
폐쇄망 SAP 시스템처럼 표준 스키마를 쓰는 시스템은 HyperAuto로 매핑 작업 자체를 자동화할 수 있어서, 처음부터 Code Transforms로 직접 짜는 것보다 훨씬 빠르게 시작할 수 있습니다.
Foundry Worker vs Agent Worker — 폐쇄망 문제의 답
연동 아키텍처는 Control Plane과 실제 데이터를 가져오는 Worker로 나뉩니다. Worker에는 두 종류가 있습니다.
Foundry Worker는 클라우드에 호스팅되어 있어서, 대상 시스템이 외부 접속을 허용하는 경우에 씁니다. 설정이 간단합니다.
Agent Worker는 고객사 내부망에 설치해서, 대상 시스템에서 Foundry 쪽으로 나가는 방향(outbound)으로만 연결을 엽니다. 외부에서 내부로 들어오는 접속을 허용할 필요가 없습니다. 앞서 언급한 폐쇄망 SAP 시스템이라면 답은 Agent Worker입니다. 보안팀이 요구하는 “외부에서 접속 못 하게”라는 조건과, “outbound만 열면 된다”는 Agent Worker의 동작 방식이 정확히 맞아떨어집니다.
핵심 개념 정리
| 개념 | 설명 |
|---|---|
| Dataset | Foundry에 저장되는 데이터 단위 |
| Branch / Build | Git의 브랜치·커밋과 유사한 버전 관리 단위 |
| Stream | 실시간으로 흘러들어오는 데이터 처리 방식 |
| CDC (Change Data Capture) | 변경분만 감지해서 가져오는 방식 |
| Virtual Table | 실제 복제 없이 원본 시스템 데이터를 그대로 참조하는 가상 테이블 |
흔한 실패 패턴 3가지
폐쇄망 시스템에 Foundry Worker를 쓰려다 막힌다. 클라우드 Worker는 대상 시스템에 접속해야 하는데, 접속 자체가 차단된 환경이면 애초에 동작하지 않습니다. Agent Worker로 바꿔야 합니다.
브랜치 관리 없이 여러 팀이 같은 파이프라인을 건드린다. Git처럼 브랜치를 나눠 작업하지 않으면, 한 팀의 변경이 다른 팀의 파이프라인을 깨뜨리는 충돌이 생깁니다.
CDC를 안 쓰고 매번 전체 스캔한다. 데이터가 커질수록 전체 스캔은 느려지고 비용도 커집니다. 변경분만 가져오는 CDC로 바꾸면 이 문제가 해결됩니다.
실전 적용 — Agent Worker 설치 흐름
폐쇄망 SAP 시스템을 연동한다고 하면, 실무에서는 대략 이런 순서로 진행합니다.
- Agent Worker 설치: 고객사 내부망(SAP 서버에 접근 가능한 네트워크 구간)에 Agent Worker를 설치합니다. 설치 자체는 가벼운 에이전트 바이너리 실행 수준입니다.
- Outbound 연결 등록: Agent Worker가 Foundry Control Plane으로 나가는 outbound 연결만 맺습니다. 방화벽 설정은 “이 포트로 나가는 것만 허용”이면 끝나고, inbound 룰을 추가로 열 필요가 없습니다.
- 소스 커넥션 구성: SAP 테이블·RFC 등 가져올 대상을 Foundry 콘솔에서 커넥션으로 등록합니다.
- CDC 또는 배치 스캔 선택: 변경분만 가져올지, 전체를 주기적으로 가져올지를 데이터 특성에 맞게 선택합니다. 거래 데이터처럼 변경이 잦고 양이 많다면 CDC가 유리합니다.
- Dataset 적재 확인: 적재된 Dataset을 Branch·Build 단위로 확인하고, 이후 파이프라인(Transform) 단계로 넘깁니다.
보안팀 입장에서 중요한 건 3번 항목입니다 — “외부에서 내부로 들어오는 포트를 새로 열어달라”는 요청이 아니라, “내부에서 바깥으로 나가는 연결 하나만 허용해달라”는 요청이라는 점을 분명히 설명하면 승인이 훨씬 빨리 납니다.
Foundry Worker vs Agent Worker
| 구분 | Foundry Worker | Agent Worker |
|---|---|---|
| 설치 위치 | 클라우드(Foundry 측) | 고객사 내부망 |
| 연결 방향 | Foundry → 대상 시스템 접속 | 내부망 → Foundry (outbound만) |
| 적합한 환경 | 외부 접속을 허용하는 시스템 | 폐쇄망·방화벽으로 격리된 시스템 |
| 설정 난이도 | 낮음 | 내부망 설치·방화벽 협의 필요 |
정리하면
연동이 막혔을 때 먼저 물어야 할 질문은 “이게 Connection 문제인가, Pipeline 문제인가”입니다. 그리고 대상 시스템이 외부 접속을 허용하지 않는다면, 답은 거의 항상 Agent Worker입니다. 표준화된 ERP라면 HyperAuto로 매핑 시간을 줄일 수 있고, 데이터가 커지면 CDC 없이는 성능이 버티지 못합니다.
자주 묻는 질문
Q. Agent Worker는 설치와 운영이 복잡한가요? Foundry Worker보다 초기 설치 단계가 하나 더 있지만, 보안 요건이 엄격한 환경에서는 이 단계를 건너뛸 수 없습니다. 설치 후 운영 부담은 크지 않습니다.
Q. HyperAuto를 쓰면 Code Transforms는 전혀 필요 없나요? 표준 스키마 밖의 커스텀 필드나 특수 변환 로직이 있다면 Code Transforms를 함께 써야 합니다. HyperAuto는 표준 부분을 빠르게 처리해주는 역할입니다.
폐쇄망 연동을 시작하기 전 점검할 6가지
- 접속이 막힌 이유가 방향(inbound 차단) 때문인지 전면 차단 때문인지 보안팀과 먼저 확인했는가
- 문제가 생겼을 때 Connection(가져오기) 문제인지 Pipeline(가공) 문제인지 나눠 볼 체크포인트를 정했는가
- 대상 시스템이 표준 스키마를 쓰는지(예: ERP) 확인해 매핑 자동화 가능 여부를 판단했는가
- 내부망에 설치하는 구성 요소의 운영 주체와 패치 책임이 정해져 있는가
- 방화벽에서 허용해야 할 outbound 목적지를 목록으로 정리해 승인받았는가
- 연동 실패·지연을 누가 어떻게 감지할지(헬스체크, 알림) 정했는가
추가로 자주 나오는 질문
Q. Agent Worker를 쓰면 외부에서 내부망으로 들어오는 접속을 열어야 하나요? 아닙니다. 내부망에 설치한 Worker가 외부로 나가는 방향(outbound)으로만 연결을 여는 구조이므로, 인바운드 허용을 요구하지 않는 것이 핵심 이점입니다. 다만 outbound 목적지는 방화벽에서 허용해야 합니다.
Q. 처음부터 Code Transforms로 짜는 게 더 유연하지 않나요? 유연성은 높지만 시작이 느립니다. 표준화된 ERP 데이터라면 자동 매핑으로 빠르게 시작하고, 이후 예외가 생기는 부분만 코드로 보완하는 편이 보통 효율적입니다.
Q. 연동이 안 될 때 가장 먼저 무엇을 구분해야 하나요? 데이터를 가져오는 단계의 문제인지, 가져온 뒤 가공하는 단계의 문제인지입니다. 두 축을 섞으면 원인 분석이 길어집니다.