2026 TOS 구매 가이드 — 항만 IT 및 시스템 팀을 위한 기술적 분석

대부분의 TOS 평가가 잘못 짚고 있는 시스템 문제

항만 IT 및 시스템 팀은 TOS (Terminal Operating System) 평가 프로세스의 대부분을 벤더의 데모를 시청하는 데 소비합니다. 데모는 세련되었고, 기능 목록은 길며, 통합(Integration) 슬라이드는 인상적입니다.

하지만 실제 가동(Go-live)이 시작되면 상황이 달라집니다. 커스텀 미들웨어(Custom middleware)가 깨집니다. 크레인 스케줄링 API가 약속했던 것과 일치하지 않습니다. 국가 관세 시스템과의 EDI (Electronic Data Interchange) 연결을 위해 벤더가 언급하는 것을 잊었던 제3자 통합업체(Third-party integrator)가 필요해집니다.

이 포스트는 TOS 선정 팀의 기술적 측면, 즉 통합 계층(Integration layer)을 소유하고, 배포를 관리하며, 향후 10년 동안 아키텍처 결정의 결과를 감당해야 하는 사람들을 위해 작성되었습니다. 그 수준에서 실제로 중요한 사항은 다음과 같습니다.

벤더를 즉시 후보군에서 제외시키는 통합 아키텍처 질문

모든 TOS 평가에서 가장 유익한 기술적 질문은 기능에 관한 것이 아닙니다. 그것은 바로 통합 소유권(Integration ownership)에 관한 것입니다.

이렇게 질문하십시오: "귀사의 표준 커넥터 라이브러리 중 어떤 통합 기능이 내부적으로 유지 관리되며, 어떤 기능이 제3자 시스템 통합업체(System integrators)를 통해 제공됩니까?"

답변에 따라 벤더는 두 가지 아키텍처 모델로 분류됩니다:

모델 A — 자체 통합 기능을 보유한 플랫폼
벤더가 관세 EDI, 선사 API, ERP 플랫폼 (SAP/Oracle), 그리고 항만 커뮤니티 시스템 (Portbase, INAPORT 등)을 위한 네이티브 커넥터(Native connectors)를 직접 유지 관리합니다. 해당 커넥터의 업데이트는 벤더 자체의 릴리스 주기 내에서 이루어집니다. 변경 사항으로 인한 오류(Breaking changes)를 수정하는 것은 벤더의 책임입니다.

모델 B — 통합 마켓플레이스를 갖춘 플랫폼
벤더의 핵심 플랫폼은 견고합니다. 대부분의 통합은 파트너 생태계에 의해 제공됩니다. 터미널 운영사는 핵심 라이선스 비용을 지불한 후, 각 연결마다 별도로 시스템 통합업체(System integrator)를 고용해야 합니다. 이것이 결함 모델인 것은 아니지만, 총 소유 비용(Total cost)과 장기적인 소유 구조에 상당한 영향을 미칩니다.

대부분의 대형 터미널은 미션 크리티컬 (mission-critical) 연결(세관, 선사)을 위해 모델 A가 필요하며, 부수적인 통합(ERP 보고, BI 도구)에는 모델 B로도 충분합니다. 위험한 상황은 벤더가 모든 통합을 "네이티브 (native)"라고 제시하지만, 탐색 (discovery) 단계에서 대부분이 마켓플레이스 커넥터 (marketplace connectors)임이 드러날 때입니다.

API 평가: 계약 체결 전 실제로 테스트해야 할 사항

현대적인 TOS 플랫폼은 세 가지 통합 패러다임을 지원합니다:

REST API        → JSON 기반, 무상태 (stateless), 이벤트 기반 웹훅 (webhooks)
EDI (EDIFACT)   → BAPLIE, COPARN, CODECO, COARRI, CUSCAR 메시지 유형
Proprietary API → 플랫폼 전용 SDK, 종종 레거시 (legacy) 크레인/장비 인터페이스

계약 서명 전 서면으로 확인해야 할 5가지 API 질문:

1. "귀사의 API 버전 관리 (versioning) 전략은 무엇이며, 메이저 릴리스 이후 지원 중단 (deprecated)된 버전은 얼마나 오랫동안 지원됩니까?"
   답변이 12개월 미만이라면 = 업그레이드 주기마다 마이그레이션 (migration) 리스크가 발생합니다.

2. "샌드박스 (sandbox)에서 인증된 것이 아니라, 현재 실제 운영 (live production) 연결로 유지 관리 중인 선사 API는 무엇입니까?"
   샌드박스 인증 연결은 가동 (go-live) 시점에 터미널 측의 통합 작업이 필요합니다. 이 차이를 명확히 알아야 합니다.

3. "실시간 야드 위치 (yard position) API의 속도 제한 (rate limit)과 SLA는 어떻게 됩니까?"
   RTG 및 크레인 자동화 시스템은 분당 수천 건의 호출을 수행합니다. 속도 제한이 걸린 API는 단순한 속도 저하가 아니라 운영 실패를 야기합니다.

4. "장비 PLC 인터페이스 연결은 어떻게 처리됩니까 — 네이티브 드라이버 (native driver), 미들웨어 (middleware), 또는 제3자 OEM 통합입니까?"
   이 단 하나의 질문이 표준이 아닌 크레인 구성을 가진 터미널의 경우 후보군의 절반을 걸러냅니다.

5. "선석 계획 (berth planning) 모듈의 API 문서를 보여주십시오 — PDF가 아닌 실제 운영 버전으로 말입니다."
   만약 라이브 API 문서가 없다면, 해당 통합은 성숙하지 않은 상태입니다.

클라우드 vs 온프레미스 (On-Premise): 기술 아키텍처 결정

클라우드 (Cloud) 대 온프레미스 (On-Premise)에 대한 비즈니스 케이스는 보통 영업 팀의 영역입니다. 하지만 기술적 리스크는 시스템 팀의 몫입니다. 아키텍처 측면에서의 고려 사항은 다음과 같습니다.

지연 시간 요구사항 (Latency Requirements)

실시간 야드 운영 (Yard operations)을 위해서는 크레인 작업 지시 (Crane work instruction) 전달 시 100ms 미만의 응답 시간이 필요합니다. WAN을 통해 야드 제어 시스템 (Yard control systems)에 서비스를 제공하는 클라우드 호스팅 TOS 플랫폼은 지연 시간 (Latency)을 유발하며, 이는 처리량이 높은 터미널에서 크레인 시퀀싱 (Crane sequencing) 오류를 일으킬 수 있습니다.

아키텍처 측면의 해결책은 엣지 컴퓨팅 (Edge computing)입니다. 즉, 실시간 운영 기능은 로컬에서 처리하고, 분석, 계획 및 보고 워크로드 (Workloads)는 클라우드 라우팅을 사용하는 방식입니다. 이것이 단순히 비용 절충안이 아닌, 실질적인 의미에서의 "하이브리드 TOS (Hybrid TOS)"가 의미하는 바입니다.

엣지 계층 (Edge layer, 터미널 내):
  - 크레인 작업 지시 생성
  - RTG 포지셔닝 및 스택 계획 (Stack planning)
...

데이터 거주성 (Data Residency)

여러 항만 당국 시장에는 명시적인 데이터 현지화 (Data localisation) 요구사항이 있습니다:

• 인도 (India): DPDPA 2023에 따른 항만 데이터는 민감한 운영 기록에 대해 현지화 영향을 미칩니다.
• 인도네시아 (Indonesia): 정부 규정 No. 71/2019는 특정 데이터의 역외 처리 (Offshore processing)를 제한합니다.
• 사우디아라비아 (Saudi Arabia): PDPL 2021 및 NCA 클라우드 컴퓨팅 통제 규정이 주요 인프라 운영자에게 적용됩니다.
• 브라질 (Brazil): LGPD는 연방 양수도(Federal concession) 하에 운영되는 항만에 대해 데이터 거주성 영향을 미칩니다.

규제 검토 없이 선택된 클라우드 네이티브 (Cloud-native) TOS는 단순한 컴플라이언스 (Compliance) 문제를 넘어, 사후 조치 (Remediation) 문제를 야기합니다.

업그레이드 제어 (Upgrade Control)

클라우드 TOS 플랫폼은 벤더의 일정에 따라 업데이트를 강제로 적용합니다. 대부분의 소프트웨어 카테고리에서는 이것이 허용 가능하지만, TOS의 경우에는 항상 안전한 것은 아닙니다.

구체적인 리스크는 다음과 같습니다: 작업 지시 시퀀싱 로직을 변경하는 크레인 스케줄링 알고리즘 업데이트가 터미널별 테스트 없이 운영 환경 (Production)에 적용될 경우 운영 중단을 초래할 수 있습니다. 2023년에서 2025년 사이 북유럽의 최소 두 곳의 주요 TOS 구축 사례에서 이러한 현상이 발생했습니다.

클라우드 배포(Cloud deployments)에 대한 계약적 요구사항: 스테이징 환경(Staging environment) 접근 권한. 업데이트가 운영 환경(Production)에 도달하기 전에 이를 수신, 테스트, 그리고 승인 또는 거부할 수 있는 능력입니다. 일부 벤더는 이를 제공하지만, 대부분은 기본적으로 제공하지 않습니다. 이를 위해서는 명시적인 계약 문구가 필요합니다.

AI/ML 역량: 네이티브(Native) vs 볼트온(Bolt-On)

벤더의 마케팅 슬라이드에는 "AI 기반(AI-powered)"이라고 적혀 있을 것입니다. 기술적 평가(Technical evaluation)를 통해 그것이 무엇을 의미하는지 결정해야 합니다.

**네이티브 AI (Native AI)**는 예측 모델(Predictive model)이 플랫폼 자체의 운영 데이터로 학습되고, TOS 데이터 환경 내에서 실행되며, 데이터 추출 없이 실시간으로 운영 결정에 영향을 미치는 것을 의미합니다.

**볼트온 AI (Bolt-on AI)**는 TOS로부터 데이터 내보내기(Data export)를 받아 별도로 분석을 수행하고, 플래너(Planner)가 수동으로 실행할 권장 사항을 반환하는 제3자 분석 레이어(Palantir, C2RO 또는 유사 솔루션)를 의미합니다.

두 방식 모두 가치가 있을 수 있습니다. 하지만 두 방식은 동일하지 않습니다. 다음과 같은 측면에서 그 차이가 중요합니다:

• 데이터 파이프라인(Data pipeline) 신뢰성 (볼트온은 안정적인 내보내기 작업이 필요하며, 네이티브는 항상 최신 상태를 유지함)
• 의사결정 지연 시간(Decision latency) (볼트온은 몇 시간의 지연을 추가하지만, 네이티브는 사이클 내 결정에 영향을 줄 수 있음)
• 벤더 책임(Vendor accountability) (볼트온의 실패 책임은 분산되지만, 네이티브의 실패는 TOS 벤더의 책임임)

평가 질문: "귀사의 예측 선석 할당 모델(Predictive berthing model)을 위한 학습 데이터는 어디에 저장되며, 선박의 도착 예정 시간(ETA) 업데이트부터 수정된 선석 할당 권장 사항까지의 지연 시간(Latency)은 얼마입니까?"

답변이 30분을 초과한다면, 그것은 배치 내보내기 파이프라인(Batch export pipeline)을 사용하는 볼트온 모델입니다.

구현 리스크: 기술적 실패 모드(Technical Failure Modes)

시스템 팀이 책임져야 할 다섯 가지 TOS 구현 실패 모드는 다음과 같습니다:

1. 데이터 마이그레이션 범위 산정 미흡 (Data migration underscoping)
10년 이상의 운영 데이터를 보유한 활성 터미널은 컨테이너 이력, 선박 기록, 고객 프로필, 장비 유지보수 로그가 기존 TOS, 별도의 과금 시스템, 그리고 거의 확실하게 일부 Excel 파일에 분산되어 있습니다. 마이그레이션 범위 조사 (Discovery) 자체만으로도 4~8주가 소요되는 작업입니다. 초기 제안서에서 마이그레이션 일정을 바로 견적 내는 업체들은 범위 조사를 수행하지 않은 것입니다.

2. EDI 변형 불일치 (EDI variant mismatch)
EDIFACT 메시지 유형은 표준화되어 있습니다. 하지만 구현 방식은 그렇지 않습니다. Maersk의 BAPLIE는 MSC의 BAPLIE와 동일하지 않습니다. 선사별 특화된 EDI 변형(variants)은 터미널 측의 매핑 (Mapping) 작업을 요구합니다. 터미널의 활성 선사 연결 수가 많을수록 통합 프로그램의 복잡도는 정비례하여 증가합니다.

3. 장비 PLC 인터페이스 격차 (Equipment PLC interface gaps)
기존 크레인 제어 시스템 (Siemens, ABB, Kalmar, 2018년 이전 모델 Konecranes 등)은 TOS 벤더의 커넥터 라이브러리에 문서화되지 않은 독자적인 PLC 인터페이스를 사용하는 경우가 많습니다. 맞춤형 드라이버 개발은 구현 프로그램에 3~6개월의 시간을 추가합니다.

4. 운영 전환 리스크 (Production cutover risk)
활성 상태인 기존 TOS에서 새로운 플랫폼으로 전환하려면 전환 기간 (Cutover window)이 필요합니다. 일정 기간 두 개의 TOS 플랫폼을 병행 운영하는 것이 유일하게 안전한 전환 모델입니다. 단일 단계 전환 (기존 시스템 종료 후 새 시스템 가동)은 운영상의 모든 리스크를 수반합니다. 구현 프로그램에는 명확한 Go/No-go 기준을 포함한 병행 운영 단계가 반드시 포함되어야 합니다.

5. 하이퍼케어 절벽 (Hypercare cliff)
대부분의 TOS 계약에는 구현 팀의 밀집도가 높은 6~12개월간의 하이퍼케어 (Hypercare) 지원이 포함되어 있습니다. 하이퍼케어가 종료되면 지원 모델은 표준 SLA (Service Level Agreement)로 급격히 떨어집니다. 기술 팀은 하이퍼케어 기간 동안 이 전환이 지원 공백이 아닌 기능적인 전환이 될 수 있도록 지식 전수 (Knowledge transfer) 프로그램을 운영해야 합니다.

TOS 비교표 (기술적 검토)

플랫폼 (Platform)	API 성숙도 (API maturity)	실시간 야드 API (Real-time yard API)	AGV 네이티브 통합 (AGV native integration)	업데이트 제어 (Update control)	엣지 지원 (Edge support)
Navis N4	REST + EDI, 성숙한 문서화	예, 높은 처리량 (high-throughput)	예 (주요 제조사)	스테이징 환경 (Staging env.) 사용 가능	제한적
...

토론 (Discussion)

항만 IT 팀 및 시스템 아키텍트(system architects)분들의 의견을 듣고 싶습니다:

• TOS 도입 과정에서 어떤 통합 실패 모드 (integration failure mode)가 가장 큰 고통을 주었습니까?
• 클라우드 TOS 계약 시 스테이징 환경 (staging environment) 액세스 권한을 성공적으로 협상한 사례가 있습니까?
• 현재의 TOS 이전부터 존재했던 레거시 크레인 PLC 인터페이스 (legacy crane PLC interfaces)를 관리하는 귀하만의 접근 방식은 무엇입니까?

전체 기술 및 조달 가이드 (17분 분량):
https://theintechgroup.com/blog/tos-buyers-guide-terminal-operating-system/