⚓ Between the Sea and Technology — A Smart Marine Consultant's Story : Part 2: On the Ground — What I Actually See, and What I Actually Solve
Part 2: On the Ground — What I Actually See, and What I Actually Solve
The gap between what a regulation says and what a shipyard can actually do — that's where I spend most of my time. This is what it looks like from the inside.
조선소 회의실은 항상 비슷하게 생겼다. 형광등, 화이트보드, 그리고 테이블 위에 놓인 두꺼운 도면 롤. 처음 몇 번은 그 분위기에 압도됐다. 저 도면 안에 내가 모르는 세계가 있다는 걸 본능적으로 알았으니까. 그리고 그게 맞았다.
Part 1에서 "컨설턴트가 뭘 하는 사람인지 설명하기 어렵다"는 이야기를 했다. 이번엔 좀 더 구체적으로 들어간다. 현장에서 내가 실제로 마주치는 것들 — 어떤 문제를 보고, 어떤 방식으로 접근하고, 결국 무엇을 남기는지.
화려하지 않다. 하지만 이 일이 왜 필요한지는 — 현장을 보고 나면 자연스럽게 이해된다.
- 현장에서 가장 자주 마주치는 문제는 "규정은 알겠는데, 우리 배에 어떻게 적용하는 건지 모르겠다"는 것이다. 이게 생각보다 훨씬 흔하다.
- OT 시스템 현황 파악이 첫 번째 벽이다. 선박 위에 어떤 시스템이 있는지 정확하게 아는 사람이 — 놀랍게도 — 잘 없다.
- 데이터는 있다. 하지만 의미 있게 쓰이는 데이터는 그 중 일부다. 수집은 되는데 활용이 안 되는 구조가 대부분이다.
- 결국 내가 남기는 것은 보고서가 아니다. "이제 우리가 뭘 해야 하는지 안다"는 담당자의 말. 그게 실질적인 결과물이다.
첫 번째 벽 — "규정은 알겠는데, 우리 배에 어떻게 적용해요?"
프로젝트 킥오프 미팅에서 가장 많이 듣는 말이 있다. "IACS UR E26이요? 저도 읽어봤는데 — 솔직히 우리 상황에 어떻게 맞춰야 하는지 잘 모르겠어요." 이 말을 처음 들었을 땐 의외였다. 규정 담당자가 규정을 모른다는 게 아니라 — 그 규정과 자기 현장 사이의 거리를 어떻게 좁혀야 하는지 모른다는 거였다.
이게 생각보다 훨씬 흔한 상황이다. 규정 문서는 범용적으로 쓰여 있다. 모든 선종, 모든 운항 조건, 모든 조선소를 아우르는 언어로. 그러다 보니 실제 현장에 적용하는 순간 — "우리 LNG선에서 이 조항은 어떻게 해석하나요?" "이 시스템은 OT 범위에 포함되나요?" 같은 질문들이 쏟아진다.
"규정이 틀린 게 아니에요. 그냥 우리 배 얘기로 번역이 안 돼 있는 거죠." — 한 조선소 설계팀장의 말
이 한 문장이 내가 하는 일의 절반을 설명한다.
그래서 첫 번째로 하는 일은 항상 비슷하다. 규정을 현장 언어로 번역하는 것. 이 선박의 구조, 이 시스템의 구성, 이 조선소의 역량 — 이것들을 기준으로 규정 요건을 구체적인 실행 항목으로 풀어내는 것. 들으면 단순해 보인다. 하지만 선박마다, 프로젝트마다 다 다르다.
두 번째 벽 — "이 배에 OT 시스템이 몇 개예요?"
이 질문을 처음 던졌을 때, 회의실 분위기가 묘하게 조용해졌다. 담당자들이 서로 얼굴을 봤다. 잠시 후 누군가 말했다. "정확히는 저도 잘…"
충격적인가? 사실 그렇지 않다. 이게 거의 모든 현장의 현실이다. 선박 위에는 수십 개의 OT 시스템이 있다. 엔진 제어 시스템, 추진 관리 시스템, 항법 장비, 화물 관리 시스템, 밸러스트 시스템, 화재 감지 시스템… 그리고 이것들은 대부분 서로 다른 벤더가 만들고, 서로 다른 시기에 설치되고, 서로 다른 프로토콜로 통신한다.
사이버보안 관점에서 가장 먼저 필요한 건 자산 목록 (Asset Inventory) 이다. 어떤 시스템이 있고, 어떻게 연결되어 있고, 어디가 외부와 접점이 있는지. 이게 없으면 그 다음 단계는 전부 추측이다. 그리고 현장에서 이 목록이 완성된 형태로 있는 경우는 — 솔직히 드물다.
그래서 현장 조사가 필요하다. 실제로 선박에 올라가거나, 설계 도면을 뒤지거나, 벤더 문서를 수집하면서 퍼즐을 맞춰간다. 이 과정이 생각보다 시간이 걸린다. 그리고 이 과정이 끝나야 — 비로소 "어디에 구멍이 있는지"를 말할 수 있다.
세 번째 벽 — 데이터는 있다. 근데 쓰이고 있지 않다.
요즘 선박은 데이터를 엄청나게 만든다. 엔진 RPM, 연료 소비량, 배기가스 온도, GPS 위치, 선속, 기상 데이터… 1분에 수백 개의 데이터 포인트가 기록된다. 그걸 다 모으면 하루에도 수백만 건이다.
근데 이상한 게 있다. 그 데이터로 뭘 하냐고 물어보면 — "일단 저장은 해요"라는 답이 돌아오는 경우가 생각보다 많다. 수집은 된다. 분석은 안 된다. 데이터가 있지만 인사이트는 없는 구조다.
이 세 가지를 정리하는 것 — 데이터를 통합하고, 의미 있는 지표를 정의하고, 이상 탐지 구조를 만드는 것 — 이게 데이터 관련 프로젝트에서 내가 하는 일의 핵심이다. AI 모델을 붙이는 건 그 다음 단계다. 기반이 없으면 모델을 아무리 좋은 걸 써도 소용이 없다.
결국 내가 남기는 것
프로젝트가 끝나면 보고서가 나온다. 수십 페이지짜리 문서. 현황 분석, 갭 분석, 이행 권고사항, 우선순위 로드맵. 형식상으로는 그게 결과물이다.
근데 진짜 결과물은 따로 있다. 한 프로젝트가 마무리될 때쯤, 담당자가 이런 말을 했다.
"처음엔 뭐가 문제인지도 몰랐는데, 이제 뭘 해야 하는지는 알겠어요. 순서도 보이고요."
이 말을 들었을 때 — 이 일을 왜 하는지 다시 한번 확인했다.
보고서는 책상 서랍에 들어가거나 공유 드라이브 어딘가에 저장된다. 하지만 담당자가 "이제 우리가 뭘 해야 하는지 안다"는 상태로 바뀌면 — 그건 남는다. 다음 미팅에서, 다음 예산 심의에서, 다음 신조선 프로젝트에서 그 이해가 작동한다.
그게 내가 현장에서 남기려는 것이다. 문서가 아니라 이해. 권고사항이 아니라 방향 감각.
현장은 생각보다 훨씬 복잡하고, 동시에 생각보다 훨씬 단순한 문제들로 가득하다.
규정을 현장 언어로 번역하는 것, 시스템이 몇 개인지 파악하는 것, 데이터가 쓸모 있게 흐르는지 확인하는 것. 하나하나 보면 크지 않은 일 같다. 하지만 이게 안 되어 있으면 — 아무리 좋은 기술을 도입해도, 아무리 최신 규정을 따라도 — 실제로 작동하지 않는다.
Maritime 4.0은 기술의 이야기이기도 하지만, 결국은 사람과 현장의 이야기다. 현장을 이해하는 사람이 기술을 제대로 연결할 수 있다. 나는 그 연결고리를 만드는 사람이 되고 싶다.
"현장에서 가장 많이 배운 건 — 모르는 게 많다는 걸 모른 채 일하는 사람이 생각보다 많다는 것이다. 그리고 그게 부끄러운 일이 아니라는 것도."
— Captain Ethan
Key Takeaways
Comments
Post a Comment