단 한 번의 프롬프트로 생성한 로테르담 항구(Port of Rotterdam)를 위한 인텔리전스 브리핑
요약
LLM의 환각 문제를 해결하기 위해 MCP(Model Context Protocol)를 활용하여 실시간 해양 데이터를 연동하는 방법을 소개합니다. VesselAPI를 MCP 서버로 구현하여 모델이 외부 API를 통해 정확한 선박 및 항만 정보를 검색하도록 설정하는 과정을 다룹니다.
핵심 포인트
- MCP를 통한 LLM의 외부 데이터 검색 및 도구 호출 구현
- VesselAPI를 활용한 실시간 해양 데이터(AIS, 배출량 등) 연동
- 학습 데이터의 한계를 넘어 실시간 데이터 기반의 신뢰성 확보
- 간편한 .mcp.json 설정을 통한 MCP 서버 통합 방법
로테르담(Rotterdam)은 유럽에서 가장 큰 항구입니다. 매년 약 27,000척의 해상 선박이 이곳을 방문합니다. 원유를 가득 실은 유조선, 높게 쌓인 컨테이너선, 북해 항구 사이를 오가는 트럭을 실은 Ro-Ro 페리 등이 그 예입니다. 24시간 내내 약 19분마다 한 척꼴로 해상 선박이 입항하거나 출항합니다.
실제 데이터에 기반해야 하는 인텔리전스 보고서(intelligence reports)를 생성하는 LLM(Large Language Models)을 보면 보통 약간의 불안함을 느낍니다. 환각(hallucination) 문제는 실재합니다. 만약 모델이 IMO 번호를 지어내거나 검사 기록을 조작한다면, 그 결과물은 무용지물보다 못합니다. 하지만 그 매력은 무시하기 어렵습니다. 쿼리(query)를 작성하거나 API 응답을 수동으로 결합할 필요 없이, 평이한 영어로 필요한 내용을 설명하기만 하면 몇 초 만에 구조화된 브리핑을 얻을 수 있기 때문입니다.
그래서 저는 그 경계를 테스트해보고 싶었습니다. 모델이 기억 속에서 사실을 생성하는 것이 아니라, 도구 호출(tool calls)을 통해 실시간 데이터베이스에서 정보를 가져올 때는 어떤 일이 벌어질까요? 실제 데이터에 근거(grounding)를 두는 것이 실제로 신뢰 문제를 해결할까요, 아니면 단지 숨길 뿐일까요?
설정 (The Setup)
추가적인 도구 없이는 언어 모델이 이미 알고 있는 것, 즉 정적이고 불완전하며 기본 출처를 추적하기 어려운 학습 데이터(training data)로만 작업할 수 있습니다. MCP (Model Context Protocol)는 그 간극을 메우는 한 가지 방법입니다. 이는 모델이 대화 중에 외부 API를 호출할 수 있게 해주는 표준 프로토콜로, 모델이 학습 데이터에서 내용을 재현하는 대신 데이터를 검색(retrieve)할 수 있도록 합니다.
데이터 측면에서, VesselAPI는 AIS 위치 데이터, EU MRV 배출 보고서, Paris MoU 항만국 검사(port state inspections), 선박 등록 정보를 하나의 REST API로 통합합니다. VesselAPI 팀은 이를 MCP 서버(vesselapi-mcp on npm)로 래핑(wrapped)하여, MCP 호환 AI 클라이언트라면 무엇이든 이를 직접 사용할 수 있도록 했습니다.
설정은 최소한입니다. MCP 호환 클라이언트(MCP-compatible client)를 사용 중이라면, 프로젝트 루트에 .mcp.json 파일을 추가하면 됩니다 (Node.js 18 이상 필요):
{
"mcpServers": {
"vesselapi": {
...
이를 통해 모델은 선박 검색, 항구 조회, 배출 기록, 검사, NAVTEX 경보 등 16가지 해양 데이터 도구에 접근할 수 있습니다. 이 MCP 서버는 모든 호환 가능한 클라이언트(Claude Code, Claude Desktop, Cursor 또는 자체 통합 환경)와 함께 작동합니다.
프롬프트 (The Prompt)
사용된 전체 프롬프트는 다음과 같습니다:
로테르담 항구(Port of Rotterdam)를 위한 오전 인텔리전스 브리핑을 생성하세요. 현재 선박 교통량, 선단 상세 정보, EU MRV 배출 데이터 및 항만국 통제(port state inspection) 기록을 포함하세요. 특이 사항이 있으면 표시하세요.
실제로 일어난 일
모델은 요청을 연구 계획으로 분해하고 자율적으로 수행했습니다. 이는 7개의 서로 다른 API 엔드포인트(endpoint)를 가로지르는 일련의 도구 호출(tool calls)로 이루어졌습니다:
search_ports("Rotterdam")— 로테르담의 UN/LOCODE인 NLRTM을 찾았습니다.get_port("NLRTM")— 항구 인프라 상세 정보(수로 깊이, 도선 요구 사항, 수리 능력)를 가져왔습니다.get_port_events("NLRTM")— 가장 최근의 선박 이동 정보 20건을 검색했습니다.get_vessel()— 교통 스냅샷에서 확인된 각 IMO 등록 선박의 정보를 보강했습니다(선종, 기국, 톤수, 건조사, 선급).get_vessel_emissions()— EU MRV 배출 기록(연간 CO2, 연료 소비량, 효율 지수)을 가져왔습니다.get_vessel_inspections()— 항만국 통제(port state control) 검사 이력(결함, 출항 정지, 검사 유형)을 가져왔습니다.get_navtex_messages()— 방송 주기 내의 활성화된 해양 안전 경보를 확인했습니다.
모델은 가능한 경우 병렬 처리를 수행했습니다. 즉, MCP 클라이언트가 동시에 실행할 수 있도록 단일 턴 내에서 여러 번의 선박 정보 보강 (vessel enrichment) 호출을 수행했습니다. 배출량 (emissions) 및 검사 (inspection) 조회 시에도 동일한 병렬 디스패치 (parallel dispatch)를 적용했습니다. 모델은 무엇을 동시에 실행할 수 있는지 결정하며, 클라이언트는 실행을 담당합니다. 결과는 현재 트래픽과 모델이 프롬프트를 어떻게 해석하느냐에 따라 달라질 수 있습니다.
브리핑 (The Briefing)
다음은 해당 API 호출을 통해 모델이 생성한 구조화된 보고서입니다:
트래픽 (Traffic)
API는 쿼리 시점을 기준으로 약 2시간의 시간 범위(18:11–19:59 UTC)에 걸친 가장 최근의 선박 이동 20건(도착 10건, 출발 10건)을 반환했습니다. 이는 결과의 한 페이지일 뿐이며, 이 정도 규모의 항구에서 발생하는 실제 물동량은 훨씬 더 많으며 모델은 더 많은 데이터를 위해 페이지네이션 (pagination)을 수행할 수 있습니다. 이 20건 중 4건은 외해 항해 선박 (seagoing vessels)이었습니다. 다른 2건은 내륙 상업용 선박 (inland commercial vessels, 급유선 및 강 유조선)이었으며, 나머지 14건은 도선선 (pilot boats), 서비스 선박 (service craft) 및 내륙 수로 트래픽으로, 주요 항구의 기능을 유지하는 운영 계층 (operational layer)을 구성했습니다.
4척의 외해 항해 선박:
| 선박명 | IMO | 유형 | 국적 | 건조 연도 | DWT |
|---|---|---|---|---|---|
| STENA FORETELLER | 9214666 | Ro-Ro 화물선 | 네덜란드 | 2002 | 12,300 |
| ... | |||||
| 로테르담 트래픽 스냅샷의 외해 항해 선박 |
두 척의 내륙 상업용 선박 — SOVEREIGN (IMO 9367023, 5,552 DWT, 모항인 Ridderkerk과 건조 프로필을 바탕으로 내륙 모터 탱커로 추정됨) 및 IMMUNITY (IMO 9316490, 2,934 DWT, 벨기에 국적, 건조사 및 운항 패턴을 바탕으로 급유선으로 분류됨) — 는 로테르담의 처리량 (throughput)이 내륙 수로 연결성에 크게 의존한다는 점을 상기시켜 줍니다. 이러한 선박들은 헤드라인을 장식하지는 않지만, 화물의 상당 부분을 운송합니다.
네 척의 외해 항해 선박 중 두 척은 유조선(tankers) — 화학 제품 및 오일/화학 제품 운반선(chemical and oil/chemical carriers) — 으로, 유럽의 주요 에너지 및 석유화학 허브로서 로테르담(Rotterdam)의 역할과 일치합니다. 나머지 두 척의 로로선(ro-ro vessels, STENA FORETELLER 및 THULELAND)은 로테르담을 영국 및 스칸디나비아 항구와 연결하는 단거리 해상 네트워크(short-sea network)의 일부입니다.
배출량 (Emissions)
네 척의 외해 항해 선박 중 세 척은 EU MRV 데이터(EU MRV data)를 사용할 수 있습니다. 이는 EU 항구에 기항하는 선박에 적용되는 의무적인 모니터링, 보고 및 검증(Monitoring, Reporting, and Verification) 체계입니다. 표에 기재된 EEXI 및 EEDI 값은 설계 기반 에너지 효율 지수(design-based energy efficiency indices)로, 기준 조건에서 계산되며 gCO2/tonne-nautical mile 단위로 표시됩니다(값이 낮을수록 좋습니다). EEXI는 기존 선박에 적용되며(2023년 1월부터 의무화), EEDI는 크기 및 선박 유형 임계값에 따라 2013년 이후 건조 계약을 체결한 신조선에 적용됩니다.
| 선박 (Vessel) | CO2 (2024) | 연료 (Fuel, 2024) | 전년 대비 변화 (YoY Change) | 효율성 (Efficiency) |
|---|---|---|---|---|
| STENA FORETELLER | 21,498t | 6,847t | N/A* | EEXI 14.38 |
| ... | ||||
| 외해 항해 선박에 대한 EU MRV 배출 데이터 (2024) |
_STENA FORETELLER는 2023년에 단 131해시(sea hours) 동안 1,292t의 CO2만을 보고하였으며, 이는 실제 배출량 증가라기보다 해당 연도에 선박이 주로 비활성 상태였음을 시사합니다.
THULELAND(-43%)와 CHEMICAL HUNTER(-32%)의 전년 대비 CO2 감소량은 맥락 파악이 필요합니다. THULELAND의 해상 시간(sea hours)은 약 7% 감소한 반면, CHEMICAL HUNTER는 약 14% 감소했습니다. 이러한 감소의 일부는 운항 횟수의 감소 또는 경로의 변경을 반영합니다. THULELAND의 연료 소비량은 해상 시간의 7% 감소에 비해 43%나 급감했는데, 이는 단순히 운항 횟수만으로는 설명하기에 너무 큰 수치이며, 경로 구성, 화물 프로필 또는 활동 감소 기간 등 두 연도 사이의 운영 패턴에 상당한 변화가 있었음을 나타낼 가능성이 높습니다.
이러한 차이점은 2023년 1월부터 의무화된 CII (Carbon Intensity Indicator, 탄소집약도지표) 등급 산정 시 매우 중요합니다. 절대적 CO2(이산화탄소) 수치는 총 배출량을 측정하지만, 달성된 CII는 수행된 운송 작업량을 기준으로 정규화하므로 운영 효율성을 측정하는 데 더 나은 지표가 됩니다. 2025년 1월부터 시행되는 FuelEU Maritime과 해상 배출을 포함하는 EU ETS (European Union Emissions Trading System, 유럽 연합 배출권 거래제)로 인해, 이 수치들은 직접적인 재무적 무게를 갖게 됩니다. 해운 분야의 EU ETS는 EU 역내 항해 배출량의 100%와 EU로 들어오거나 나가는 항해의 50%를 적용하며, 검증된 배출량의 40%를 2024년에, 70%를 2025년에, 그리고 2026년부터 100%를 단계적으로 적용합니다. CO2 톤당 약 65~70유로를 기준으로 할 때, 40% 단계적 적용률을 적용한 STENA FORETELLER의 2024년 ETS 부채는 완전한 EU 역내 운영 시 약 58만 유로 범위가 될 수 있습니다. 만약 항해의 상당 부분이 50% 세율이 적용되는 EU 역외(예: 로테르담-영국) 항해라면 이 금액은 더 낮아집니다.
세 척의 선박을 합산하면 2024년에 총 43,012톤의 CO2를 배출했습니다. 그중 2,231톤은 STENA FORETELLER와 THULELAND의 정박 중 배출량(at-berth emissions)이었습니다 (CHEMICAL HUNTER의 2024년 정박 중 데이터는 보고되지 않았습니다). 정박 중 보조 엔진 가동은 또한 SOx(황산화물), NOx(질소산화물) 및 미세먼지를 발생시키는데, 이러한 오염 물질은 MRV (Monitoring, Reporting, Verification, 모니터링·보고·검증) 데이터 세트에는 포함되지 않지만 항만 지역의 지역 대기 질 문제로 잘 알려져 있습니다.
점검 (Inspections)
항만국 통제 (Port State Control)는 국제 해운의 책임을 유지하는 시스템입니다. Paris MoU에 따라, 검사관은 유럽 항구에 기항하는 모든 외국 국적 선박에 승선하여 화재 안전부터 선원 근로 조건에 이르기까지 모든 것을 점검할 수 있습니다. 문제가 충분히 심각할 경우, 선박을 억류(detain)할 수 있습니다.
STENA FORETELLER호는 2024년 4월 Immingham(영국)에서 실시된 초기 검사(initial inspection)에서 7건의 결함(deficiencies)이 발견되었으며, 이후 2025년 1월 동일 항구에서 실시된 더 상세한 검사(more detailed inspection)에서 6건의 결함이 추가로 발견되었습니다. Paris MoU의 신규 검사 체계(New Inspection Regime, NIR)에 따르면, 결함 이력, 도선사 또는 항만 당국의 보고, 또는 해당 선박이 고위험 선박(High Risk Ship)으로 분류되는 등 압도적이거나 예상치 못한 요인이 확인될 경우 더 상세한 검사가 명령될 수 있습니다. 이전 방문에서 7건의 결함 기록이 있다는 점은 다음 입항 시 더 상세한 검사를 유발할 수 있는 정확한 요인에 해당합니다.
두 검사 모두 선박 억류(detention)로 이어지지는 않았으나, 동일한 항만 당국에서 반복되는 패턴은 컴플라이언스(compliance) 팀과 P&I 클럽(P&I clubs)이 주의 깊게 추적하는 신호입니다. 이러한 패턴이 반드시 안전하지 않은 선박임을 나타내는 것은 아니지만, 검사관과 언더라이터(underwriters)의 더 면밀한 조사(scrutiny)를 불러일으킬 것입니다.
반면, CHEMICAL HUNTER호는 여러 항만국 통제(Port State Control, PSC) 체계(Paris MoU, US Coast Guard, Mediterranean MoU 등)에 걸쳐 27건의 검사 기록을 보유하고 있으며, 가장 이른 기록은 2015년 12월로 — 모두 결함 0건을 기록했습니다.
실무적 활용 (Practical Applications)
업계 전반에서는 매일 동일한 데이터를 수동으로 추출하고 있습니다:
- **선박 중개인 및 용선자 (Ship brokers and charterers)**는 선박을 성약할 때 선박 제원, 배출량, PSC (항만국 통제) 이력 등이 결합된 선박 프로필을 추출합니다. 이러한 형태의 통합된 실사 (due diligence) 작업은 통상적으로 여러 시스템에 대한 질의를 필요로 합니다.
- **원자재 트레이딩 데스크 (Commodity trading desks)**는 화물 흐름을 추정하고 공급 중단을 예측하기 위해 선박의 움직임을 추적합니다. "현재 로테르담에 있는 유조선은 무엇인가?"라는 질문은 매일 아침 던져지는 질문입니다.
- **컴플라이언스 팀 (Compliance teams)**은 거래 상대방 리스크 (counterparty risk)를 평가하기 위해 검사 기록과 배출 데이터를 교차 참조합니다. PSC 기록이 좋지 않은 선박을 용선하는 것은 법적 책임 (liability)을 발생시킵니다.
- 항만 운영 (Port operations) 부문에서는 선석 계획 (berth planning) 및 자원 배분을 위해 실시간 교통 상황 인지가 필요합니다.
- **해상 보험사 (Maritime insurers)**는 선체 및 P&I (선주책임상호보험) 보험료를 산정할 때 검사 이력과 선령을 고려합니다. CHEMICAL HUNTER의 깨끗한 기록과 STENA FORETELLER의 최근 패턴은 보험료 산정 시 매우 다른 결과를 초래할 것입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기