제2장: 왜 표준인가 — WIA-ENE-040의 범위·구조·거버넌스

제1장은 심해를 하나의 장소로 다루었다. 수심 구역과 압력, 소리가 전달되는 방식, 그리고 그곳에 내려가는 탐사 플랫폼이 그 내용이었다. 이 장은 심해의 ‘서류 작업’을 다룬다. 잠수 한 번이 끝나면 항법 위치, CTD 프로파일, 소나 파일, 영상, 시료, 그리고 작성된 일지가 남는다. 이것들은 저마다 다른 형식으로, 서로 다른 시계를 기준으로, 식별자에 대한 서로 다른 관념을 가지고 들어온다. WIA-ENE-040은 이 조각들을 서로 맞물리게 하려고 만들어진 표준이다. 제3장에서 메시지 형식을 본격적으로 열기 전에, 이 표준이 무엇을 고치려 하는지, 어디까지를 다루는지, 네 단계(Phase)가 일을 어떻게 나누는지, 그리고 표준 바깥의 어떤 규범을 따라야 하는지를 분명히 해 둘 필요가 있다.

이 장에서부터는 표준을 구성하는 문서들끼리 서로 어긋나는 지점도 기록해 나간다. 원문 문서만 보고 WIA-ENE-040을 구현하는 사람은 조만간 이런 불일치를 만나게 된다. 통합 시험이 실패한 뒤에 만나는 것보다, 해석 방침과 함께 여기서 먼저 만나는 편이 낫다.

2.1 상호운용성 문제

심해 데이터 표준이 왜 필요한지 가장 쉽게 이해하는 방법은 잠수 한 번이 선박의 여러 시스템을 어떻게 거쳐 가는지 따라가 보는 것이다. 아래의 잠수는 설명을 위해 지어낸 예시이지만, 등장하는 형식은 모두 표준 자신이 ENE-040 §11.2.1이나 Phase 1 참고문헌에서 거명한 것들이다.

잠수 한 번, 파일 여러 개

작업급 ROV가 열수 분출공 지대로 8시간 동안 잠수했다고 하자. 잠수정이 갑판으로 돌아왔을 때 이 잠수는 다음과 같은 흔적을 남긴다.

데이터 흐름	흔한 원천 형식	기준 시계	흔히 빠지는 정보
잠수정 위치(USBL)	USBL CSV 내보내기 또는 약 1 Hz의 EIVA NaviPac 로그	항법 PC(대개 선박 GPS에 동기화)	레버암 오프셋, 적용한 음속 프로파일, 측위 품질
수질(CTD, 용존산소, pH)	약 1 Hz의 Sea-Bird `.cnv` 텍스트 파일	CTD 데크 유닛 또는 잠수정 컴퓨터	검교정 일자, 기계가 읽을 수 있는 위치의 센서 일련번호
멀티빔·측면주사 소나	`.xtf` 또는 `.gsf` 바이너리 파일	소나 처리기(자체 시각 입력으로 동기화)	해당 잠수와의 연결, 적용된 SVP와의 연결
영상·정지 사진	H.264 또는 ProRes 파일(HD/4K)	카메라·녹화기 타임코드	타임코드와 UTC의 대응, 프레임별 위치
잠수정 상태	제조사 텔레메트리(대개 독자 규격의 바이너리나 텍스트 로그)	잠수정 제어 시스템	필드와 단위에 대한 문서
시료	종이 라벨, 스프레드시트, MySQL·PostgreSQL 목록	입력자가 적은 시각	정확한 채취 시각과 수심, 해당 시료를 허가한 허가증
잠수 경과 기록	당직자 일지(자유 서술)	관제실 벽시계	구조, 다른 파일에 대한 참조

일곱 개의 흐름이 적어도 여섯 가지 형식으로, 적어도 네 개의 시계를 기준으로 기록된다. 누군가 손으로 파일 이름을 바꿔 주지 않는 한 이들 사이에 공통된 잠수 식별자는 없다. 목록에 특이한 것은 하나도 없다. 형식마다 존재 이유가 있고, 각자의 영역에서는 문서화도 잘 되어 있다. 문제는 승선하지 않았던 누군가가, 대개 몇 달 뒤에, “12번 시료를 채취한 지점의 수온은 얼마였는가?”와 같은 평범한 질문에 답하려 할 때 시작된다.

세 가지 실패 양상

형식이 파편화되어 있다. 12번 시료의 질문에 답하려면 .cnv 파서, 항법용 CSV 판독기, 시료 목록 스프레드시트, 그리고 세 자료의 행을 맞춰 줄 방법이 필요하다. 하나하나는 어렵지 않다. 그러나 이것들이 합쳐지면 데이터를 재사용할 때마다 작은 소프트웨어 프로젝트가 생기고, 그 결과물은 거의 공유되지 않는다.

메타데이터가 사라진다. 단위와 센서, 검교정 일자가 없는 수온 값은 측정값이 아니라 그냥 숫자다. 기존 형식은 이런 정보를 파일 헤더에 두는 경우가 많은데, 변환 과정에서 헤더가 떨어져 나가거나 데이터와 함께 다니지 않는 항해 보고서에만 남는다. 한번 잃어버리면 대개 되살릴 수 없다.

시계가 어긋난다. 긴 잠수 중에 시각 기준을 잃은 잠수정 컴퓨터는 수 초씩 어긋날 수 있다. 카메라는 녹화를 시작할 때 타임코드를 0부터 세기도 한다. 서로 다른 시계를 따르는 흐름을 합치면 시료가 엉뚱한 수심이나 엉뚱한 사진에 연결될 수 있다. 이 오류는 “열수 분출공” 사진에 평범한 퇴적물 바닥만 찍혀 있다는 것을 누군가 알아챌 때까지 드러나지 않는다.

표준이 바꾸는 것

표준이 계측 장비의 내부 언어까지 통일할 수는 없고, WIA-ENE-040도 그렇게 하려 하지 않는다. 표준이 하는 일은 장비에서 나오는 데이터를 담을 공통 봉투를 정의하는 것이다. 그 봉투 안에서 모든 값은 단위와 검교정 이력을 함께 지니고, 모든 메시지는 UTC 타임스탬프와 원천 식별자와 순번을 지니며, 모든 레코드는 자신이 속한 잠수와 탐사를 가리킨다. .cnv의 한 행에 있던 CTD 측정값은 다음과 같이 스스로를 설명하는 메시지가 된다.

변환 전 (변환된 CTD 텍스트 파일의 한 행, 열의 의미는 헤더를 봐야만 안다):
  8271.500  3547.180  2.4710  34.8910  7.820

변환 후 (WIA-ENE-040 Phase 1 메시지 발췌, 전체 구조는 제3장):
{
  "wiaVersion": "1.0",
  "messageType": "OCEANOGRAPHIC_DATA",
  "timestamp": "2031-05-14T13:52:07.412Z",
  "sequenceNumber": 48213,
  "sourceId": "ROV-EXAMPLE-01",
  "priority": "NORMAL",
  "payload": {
    "environment": {
      "temperature": { "value": 2.471, "unit": "celsius",
                       "sensorId": "CTD-0421", "calibrationDate": "2031-02-03" }
    }
  },
  "metadata": { "expeditionId": "EXP-2031-004", "diveId": "DIVE-ROV-2031-017" },
  "checksum": "SHA256:..."
}

두 번째 형태는 길다. 음향 링크에서는 이 길이가 문제가 되므로 Phase 1은 바이너리 인코딩을, Phase 3은 압축 텔레메트리 레코드를 따로 정의한다(이 레코드의 수심 필드에는 제6장에서 다룰 결함이 있다). 그러나 갑판과 육상에서는 이 추가 바이트가 나중에 어떤 노력으로도 되살릴 수 없는 것을 사 준다. 측정값이 스스로를 설명한다는 점이다. 참고로 metadata 안의 expeditionId와 diveId는 2.4절에서 다룰 이 책의 권장 연결 규약이다. Phase 1 명세는 metadata를 “라우팅·필터링용” 선택 객체로만 규정하며, 이 두 키를 정의하지 않는다.

2.2 표준의 정체성과 적용 범위

WIA-ENE-040은 문서 한 편이 아니다. 여러 문서와 코드가 함께 하나의 표준을 이룬다. 어느 문서가 무엇을 말하는지 알아 두면 나중에 생길 혼란을 크게 줄일 수 있다.

항목	공표된 값	비고
표준 번호	WIA-ENE-040	“ENE”는 WIA 표준 목록의 에너지 및 환경(Energy & Environment) 분류를 뜻한다.
명칭	심해 탐사 표준(Deep Sea Exploration Standard)	핵심 문서는 한국어로, 네 개의 Phase 명세는 영어로 작성되어 있다.
버전	1.0.0(핵심 문서, README, SDK), “1.0”(Phase 명세와 `wiaVersion`)	“1.0”과 “1.0.0”은 같은 릴리스로 본다. 아래 버전 표기 항목 참조.
상태	정식 표준(핵심 문서), Active(Phase 명세)	두 표기 모두 같은 첫 릴리스를 가리킨다.
핵심 문서	`spec/WIA-ENE-040-v1.0.md`	과학적 배경, 기록 모델(§12), 기록 API(§13), 접근·윤리(§14)
Phase 명세	`PHASE-1-DATA-FORMAT.md` ~ `PHASE-4-INTEGRATION.md`	데이터 형식, 운용 API, 음향 프로토콜, 통합과 인증
참조 코드	TypeScript SDK `@wia/ene-040` 1.0.0, CLI `deep-sea-exploration.sh`	README의 `@wia/deep-sea-exploration` 패키지와 `WIADeepSeaClient` 클래스는 실제 배포된 코드와 일치하지 않는다(제5장).

표준이 다루는 것

ENE-040 §1.1은 대상을 200 m보다 깊은 해양 심해부로 정하고, 과학적 탐사, 생물다양성 연구, 지질 조사, 자원 평가라는 네 가지 목적을 제시한다. §2.2는 이를 표준이 지원할 탐사 활동 목록으로 구체화한다.

생물다양성 조사와 신종 발견
멀티빔 음향측심기를 이용한 해저 지형 매핑
열수 분출공 탐사와 모니터링
냉수 용출대 연구
심해 퇴적물 코어링
해저 광물 자원 탐사
심해의 플라스틱과 오염 조사
생물 시료 채취와 유전자 분석

지리적 범위는 전 지구적이다. 다섯 대양과 주요 해구가 모두 포함된다. 적용 대상(§1.3)도 연구 기관과 선박 운영자부터 ROV·AUV 제조사, 국가 해양 관리 기관, 환경 영향 평가 기관까지 폭넓다. 이 폭이 2.4절에서 다룰 두 개의 기록 계층을 설명해 준다. 같은 잠수에서도 잠수정 운용자와 데이터 큐레이터가 필요로 하는 것은 서로 다르다.

표준이 다루지 않는 것

WIA-ENE-040이 어디서 멈추는지 아는 것도 그만큼 중요하다. 이 표준은 잠수정을 데이터의 생산자이자 소비자로서만 기술한다. 선체 설계, 내압 용기 공학, 부력재, 조종사 훈련은 규정하지 않는다. 따라서 “WIA-ENE-040 준수”라는 말은 그 잠수정이 안전하게 잠수할 수 있는지에 대해 아무것도 말해 주지 않는다. 실험실 처리 절차도 표준화하지 않는다. 퇴적물 코어가 몇 도에서 냉동되어 어느 냉동고의 어느 칸에 보관되었는지는 기록하지만, 그 코어를 어떻게 처리할지는 정하지 않는다. 생물 시료도 마찬가지로 표준은 시료와 관찰의 메타데이터를 담을 뿐이고, 방법론은 해당 학계의 몫이다. 핵심 문서에는 잠수부 감압이나 일부 지구화학 설명처럼 데이터 범위를 벗어나는 배경 절도 있는데, 이 책은 이를 규범적 요구사항이 아니라 배경 지식으로 취급한다.

버전 표기, 라이선스, 변경 절차

세 가지 거버넌스 사항은 정확히 짚어 둘 필요가 있다. 문서들이 이를 일관되게 기술하지 않기 때문이다.

버전 문자열. 핵심 문서, README, SDK는 1.0.0이라고 쓴다. Phase 명세는 “1.0”이라 쓰고, Phase 1의 예시 메시지는 필드 설명이 시맨틱 버전을 요구하는데도 "wiaVersion": "1.0"을 담고 있다. Phase 2 API는 X-WIA-Version: 1.0 헤더를 쓰지만 SDK는 X-WIA-Standard: ENE-040과 함께 X-WIA-Version: 1.0.0을 보낸다. 견고한 구현이라면 입력에서는 두 표기를 모두 받아들이고, 패치 버전이 없으면 0으로 간주해 MAJOR.MINOR로 비교하며, 출력에서는 한 가지 표기만 일관되게 써야 한다. 이 책은 메시지 안에서는 “1.0”을, 릴리스를 가리킬 때는 “1.0.0”을 쓴다.

라이선스. 핵심 문서는 MIT 라이선스를 선언한다. README는 표준 본문을 CC BY 4.0으로, SDK와 참조 구현을 MIT로 배포한다고 밝히며, Phase 1의 문서 관리 항목도 CC BY 4.0이라고 적는다. 가장 일관된 해석은 README의 구분, 즉 명세 본문은 CC BY 4.0, 코드는 MIT라는 것이다. 법무 검토가 엄격한 조직이라면 이 책에 기대지 말고 발행 주체에 이 해석을 확인받아야 한다.

변경 절차. README는 공개된 절차를 설명한다. 공개 저장소의 이슈와 기능 요청, 실질적 변경을 위한 WIA 개선 제안(WEP), 코드와 문서를 위한 풀 리퀘스트가 그것이다. Phase 1 §6.2와 Phase 4 §8은 인증을 WIA 인증 위원회의 동료 검토에 맡긴다. 그러나 문서들은 의결 규칙, 유지보수 주기, 폐기(deprecation) 정책을 정의하지 않는다. 그래서 이 책이 찾아낸 정오 사항은 이미 반영된 변경이 아니라, WEP가 취할 법한 형태의 변경 제안 목록으로 제8장에 모아 둔다.

2.3 4단계 아키텍처

표준은 네 개의 Phase로 나뉜다. “단계”라는 말은 시간 순서를 떠올리게 하지만, 각 Phase는 계층으로 이해하는 편이 정확하다. 각 계층은 다른 계층이 기댈 수 있는 계약을 정의하며, 실제 시스템은 네 계층을 동시에 사용한다.

                   육상 / 클라우드
  +-----------------------------------------------------------+
  | Phase 4  통합                                             |
  |   OOI, NCEI, MBARI | PANGAEA, BCO-DMO | 객체 저장소       |
  |   ISO 19115 + DataCite 메타데이터, RBAC, 엠바고, 라이선스 |
  +-----------------------------^-----------------------------+
                                | 아카이브, 내보내기, 연합 질의
  +-----------------------------+-----------------------------+
  | Phase 2  API                                              |
  |   운용 계층:  /v1/vehicles  /v1/missions                  |
  |               /v1/telemetry /v1/samples                   |
  |   기록 계층:  /api/v1/expeditions  /dives  /samples       |
  |               /observations  /vents  /bathymetry          |
  +-----------------------------^-----------------------------+
                                | 요청·응답 본문으로 쓰이는 Phase 1 메시지
  +-----------------------------+-----------------------------+
  | Phase 1  데이터 형식                                      |
  |   JSON 봉투 | 32바이트 바이너리 헤더 + Protobuf           |
  |   mission-<id>/ 아카이브 트리, JSONL 시계열              |
  +-----------------------------^-----------------------------+
                   선박         | 수면 게이트웨이에서 프레임 재조립
  - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - -
                   수층         |
  +-----------------------------+-----------------------------+
  | Phase 3  음향 프로토콜 (또는 광케이블 테더)               |
  |   물리 / 링크 / MAC / 네트워크 / 전송 / 응용              |
  |   WIA-UWRP 라우팅, WIA-UTP, WIA-UFTP, PTPu 시각 동기      |
  +-----------------------------------------------------------+
        ROV       AUV       랜더       크롤러       HOV

각 Phase가 보장하는 것

Phase	정의 대상	다음 계층에 주는 보장	넘겨주는 것
1 데이터 형식	기본 봉투, `OCEANOGRAPHIC_DATA`·`BATHYMETRIC_DATA`·`SAMPLE_METADATA`·`VEHICLE_TELEMETRY`, 검증 범위, 선택적 바이너리 형식, 아카이브 구조	보낸 쪽 소프트웨어를 몰라도 모든 메시지를 검증하고, 원천·순번으로 정렬하고, 무결성을 확인할 수 있다	Phase 2의 본문, Phase 3의 페이로드, Phase 4의 아카이브가 될 메시지와 파일
2 API	REST 자원, 인증, 헤더, 오류, 요청 한도, 웹훅, WebSocket 텔레메트리, ENE-040 §13의 기록 API	계약에 맞춰 작성한 클라이언트는 어떤 준수 서버와도 동작하며, 재시도가 안전하다	Phase 4 커넥터와 육상 도구를 위한 안정된 엔드포인트
3 프로토콜	음향 대역과 프레임, FEC·ARQ, TDMA MAC, 주소 체계와 라우팅, 전송, 시각 동기, 비상·QoS 규칙	수층을 건너는 메시지는 완전하고 순서대로 도착하거나, 유실로 보고된다. 긴급 트래픽은 대용량 데이터보다 먼저 간다	수면 게이트웨이로 가는 재조립된 페이로드(게이트웨이가 Phase 1 메시지로 복원)
4 통합	연구망·저장소·클라우드 커넥터, ISO 19115·DataCite 메타데이터, RBAC·엠바고·라이선스, 인증, 이전(migration)	데이터가 외부 아카이브가 받아들이는 형태로, 접근 규칙을 유지한 채 프로젝트를 떠난다	DOI가 부여된 공개 데이터셋, 시스템 전체에 대한 인증

측정값 하나가 거쳐 가는 길

2.1절의 수온 측정값이 테더 없는 AUV에서 나왔다고 하자. 잠수정에서 이 값은 단위, 센서, 검교정 일자를 갖춘 Phase 1 값으로 생성된다. 전송할 때는 Phase 1 바이너리 인코딩으로 묶인다. 초당 수 킬로비트에 불과한 음향 링크로는 장황한 JSON을 감당할 수 없기 때문이다. 이것을 Phase 3이 실어 나른다. 링크 계층은 순방향 오류 정정을 덧붙이고, MAC 계층은 잠수정에 배정된 TDMA 슬롯을 기다리며, 전송 계층은 프레임이 유실되면 재전송한다. 선박에서는 게이트웨이가 페이로드를 재조립해 완전한 Phase 1 봉투로 복원하고, API 서버가 이를 저장한 뒤 Phase 2의 WebSocket 구독자에게 밀어 보낸다. 항해가 끝나면 임무 아카이브가 Phase 4를 거쳐 ISO 19115 메타데이터를 갖춘 CF-NetCDF 형태로 국가 데이터 센터에 제출된다.

대부분의 작업급 ROV처럼 광케이블 테더가 있으면 대용량 데이터는 음향 계층을 거치지 않는다. 그래도 봉투, API, 통합 규칙은 그대로다. 이것이 계층화의 핵심 이점이다. 육상의 분석가는 어떤 값이 광케이블로 올라왔는지 물속을 건너왔는지 알 필요가 없다.

놓치기 쉬운 결과가 두 가지 있다. 첫째, Phase들은 데이터 타입을 공유하지만 전송 방식은 공유하지 않는다. 따라서 게이트웨이가 Phase 1 형태를 정확히 복원할 수 있기만 하면, Phase 3 구현은 전송 구간에서 긴 필드 이름을 생략해도 된다. 둘째, 준수는 부분적일 수 있다. 육상 저장소는 Phase 1, 2, 4만 구현하고 음향 모뎀은 전혀 다루지 않을 수 있다. 표준의 적합성 수준이 이를 어떻게 반영하는지는 2.7절에서 본다.

2.4 두 개의 기록 계층과 그 연결

4단계 스택은 데이터가 어떻게 움직이는지를 설명한다. 또 하나의 축은 데이터가 무엇에 관한 것인지를 설명하며, 여기서 WIA-ENE-040은 뚜렷이 구별되는 두 계층을 둔다. 두 계층 모두 “시료(sample)”라는 말을 쓰고 둘 다 API를 가지고 있어서 혼동하기 쉽다.

운용·텔레메트리 계층

이 계층은 Phase 1과 Phase 2가 정의한다. 이 계층의 세계는 잠수정, 임무, 명령, 텔레메트리, 센서 측정값으로 이루어진다. 식별자는 봉투의 sourceId(명세의 예로는 ROV-ATLANTIS-001)로, API에서는 이것이 그대로 vehicleId가 된다. 여기에 POST /v1/missions가 돌려주는 missionId가 더해진다. 자원은 /v1/… 아래에 있다. /v1/vehicles, /v1/missions, /v1/telemetry, /v1/sensors, /v1/samples가 그것이다. 시간 규모는 초에서 시간 단위이고, 주 사용자는 선상의 운용팀이다.

과학 기록 계층

이 계층은 ENE-040 §12와 §13이 정의하고 SDK가 구현한다. 이 계층의 세계는 탐사, 잠수, 생물 관찰, 시료, 열수 분출공, 멀티빔 조사로 이루어진다. 식별자는 EXP-, DIVE-, OBS-, SAMPLE-, VENT- 접두어를 따른다. 자원은 /api/v1/… 아래에 있다. /api/v1/expeditions, /api/v1/dives, /api/v1/observations, /api/v1/samples, /api/v1/vents, /api/v1/bathymetry가 그것이다. 시간 규모는 수년에서 수십 년이고, 주 사용자는 과학자, 큐레이터, 데이터 저장소다.

빠져 있는 연결 고리

잠수 한 번은 두 계층 모두에 레코드를 만들므로, 두 계층은 서로 연결되어야 한다. 그런데 명세는 이 연결을 정의하지 않는다. Phase 2의 임무에는 expeditionId도 diveId도 없다. ENE-040의 잠수 기록에는 missionId가 없다. POST /v1/samples로 등록한 시료는 missionId를 지니는데, 같은 실물 시료가 §12.4에서는 expeditionId와 diveId를 지닌다. 문서들에 나오는 시료 식별자 예시 세 개(SAMPLE-2025-01-15-001, SAMPLE-2025-001-012, SAMPLE-2025-MT-001)는 서로 다른 세 가지 패턴을 따른다.

향후 개정에서 이 공백이 메워질 때까지, 이 책은 다음 규약을 권한다. 선택 필드나 명시적으로 표시한 확장 필드만 사용하므로 준수 여부를 해치지 않는다.

식별자	발급 주체	함께 기재해야 할 곳	규칙
`expeditionId`	기록 API `POST /api/v1/expeditions`, 출항 전	임무 요청 메타데이터, 봉투의 `metadata`, 모든 잠수·시료·관찰	항해 구간(leg)마다 하나, 재사용 금지
`diveId`	기록 API `POST /api/v1/dives`, 진수 시점	잠수 중 생성되는 모든 메시지의 봉투 `metadata`, 시료, 관찰	잠수정 투입 1회마다 하나
`missionId`	운용 API `POST /v1/missions`	잠수 기록의 확장 필드, 아카이브 디렉터리 이름 `mission-<id>/`	잠수 단위로 움직이는 잠수정은 잠수 1회에 임무 하나. 장기 AUV·랜더 투입은 임무 하나가 여러 회수를 포괄할 수 있고, 회수마다 별도 잠수로 기록한다
`sampleId`	운용 API `POST /v1/samples`, 채취 시점	기록 계층의 시료, 관리 이력, 용기 라벨, 보관소 목록	한 번만 발급해 그대로 복사한다. 기록 계층은 같은 실물에 두 번째 ID를 만들지 않는다
`sourceId` / `vehicleId`	운영자, 잠수정마다 한 번	모든 봉투, 탐사 기록의 `submersibles[]`	항해가 바뀌어도 유지. 문자 집합은 Phase 1 §3.1을 따른다

실제 연결은 다음과 같다. 임무 요청은 Phase 2가 이미 정의한 permissions 객체를 사용하고, 과학 식별자는 확장 필드로 덧붙인다. 잠수 기록도 같은 방식으로 자신의 임무를 가리킨다. x- 접두어는 이 필드들이 확장임을 표시한다. Phase 1 §6.2는 구현자가 확장을 문서화하도록 요구한다.

POST /v1/missions                      (운용 계층, 발췌)
{
  "missionName": "Vent field survey, dive 17",
  "vehicleId": "ROV-EXAMPLE-01",
  "missionType": "SCIENTIFIC_RESEARCH",
  "permissions": {
    "chiefScientist": "chief.scientist@example.org",
    "permits": ["EX-EEZ-2031-0042"]
  },
  "x-expeditionId": "EXP-2031-004",
  "x-diveId": "DIVE-ROV-2031-017"
}
  -> { "missionId": "MISSION-2031-017", "status": "PLANNED", ... }

POST /api/v1/dives                     (기록 계층, 발췌)
{
  "diveId": "DIVE-ROV-2031-017",
  "expeditionId": "EXP-2031-004",
  "x-missionId": "MISSION-2031-017",
  ...
}

이 규약을 따르면 연결 작업이 기계적으로 처리된다. 잠수 기록은 x-missionId와 아카이브 디렉터리 이름으로 자신의 텔레메트리를 찾는다. 텔레메트리 메시지는 metadata.diveId로 자신의 잠수를 찾는다. 시료는 두 계층에서 같은 ID를 가진 같은 대상이다. 이렇게 하지 않으면 시간 창과 잠수정 이름으로 레코드를 짝지어야 하는데, 이 방법은 시계가 어긋날 때, 즉 2.1절에서 출발한 바로 그 문제가 생길 때 정확히 실패한다.

2.5 기존 표준과의 정합

심해 과학은 백지에서 출발하지 않는다. 국가 데이터 센터, 생물다양성 데이터베이스, 해저 지형 프로그램에는 이미 자리 잡은 형식과 어휘가 있고, 연구자는 그곳에 데이터를 제출할 의무를 진다. 이를 대체하려는 새 표준은 형식 목록에 하나를 더 보탤 뿐이다. WIA-ENE-040은 반대 방향을 택한다. 자신의 레코드를 기존 표준으로 손실 없이 대응(mapping)시킬 수 있도록 정의하고, 원본 파일은 그대로 곁에 보존한다.

외부 표준·형식	무엇인가	WIA-ENE-040에서의 역할	등장 위치
CF Conventions(NetCDF)	NetCDF 파일의 변수 이름, 단위, 좌표에 관한 공동체 규약	시계열과 격자의 내보내기 대상, 표준 변수 이름과 단위 문자열의 원천	Phase 1 참고문헌, Phase 4 NCEI 파이프라인(제7장)
ISO 19115	지리 정보 메타데이터 국제 표준	데이터셋 수준 기술: 제목, 초록, 범위, 계보, 연락처	Phase 4 §6.1 필수 요소
Darwin Core	TDWG가 관리하는 생물다양성 어휘	생물 관찰과 생물 시료의 대응 기준(학명, 출현, 수심)	ENE-040 §11.2.2, 관찰 기록(제4장)
OBIS	Darwin Core 레코드를 모으는 해양 생물다양성 정보 시스템	관찰 데이터의 공개 대상	ENE-040 §11.2.2, §15.2
GEBCO	전 지구 격자 해저 지형도(General Bathymetric Chart of the Oceans)	조사 지점 선정의 기초 자료, 새 조사 격자의 제출처가 될 수 있음	ENE-040 §11.1.1, §15.2
IODE	IOC-UNESCO의 국제 해양 자료·정보 교환 프로그램	국가 해양 데이터 센터와의 교환 체계	Phase 1 참고문헌, Phase 4 범위
DataCite	연구 데이터용 DOI 등록 기관이자 메타데이터 스키마	공개 데이터셋의 영구 식별자	Phase 4 §6.2
ORCID	연구자 영구 식별자	시료와 DOI 메타데이터의 채집자·작성자 신원	Phase 1 `SAMPLE_METADATA`, Phase 4 §6.2
XTF, GSF	측면주사·멀티빔 데이터용 바이너리 형식	`bathymetry/multibeam-raw/` 아래 원본 파일로 보존하고, 재인코딩하지 않고 참조만 한다	ENE-040 §11.2.1, Phase 1 §5.1
Sea-Bird `.cnv`	Sea-Bird 처리 소프트웨어가 변환해 내놓는 CTD 텍스트 출력	단위·센서·검교정 일자를 갖춘 `OCEANOGRAPHIC_DATA` 값으로 파싱하고, 원본은 보존	ENE-040 §11.2.1

대응의 세 가지 규칙

이름을 바꾸지 말고 대응시킨다. WIA-ENE-040의 필드 이름은 camelCase JSON 키이고, 대상 표준에는 CF의 sea_water_temperature나 Darwin Core의 scientificName 같은 고유한 이름이 있다. 대응 관계는 내보내기 도구가 관리하는 교차 대응표(crosswalk)에 둔다. 데이터 안에서 그때그때 이름을 바꾸어서는 안 된다. 같은 원천을 서로 다르게 바꾼 두 결과는 나중에 조정할 수 없기 때문이다.

단위는 지니고 다니고, 변환은 경계에서 한다. 모든 Phase 1 값은 단위를 지닌다. 변환은 내보낼 때에만, 대상이 선언한 단위에 맞추어 수행한다. 흔한 예가 압력이다. Phase 1은 bar로 기록하지만 해양학에서는 흔히 데시바(dbar)를 쓰므로, 내보내기 도구가 10을 곱한다. 제7장에서는 Phase 4 명세가 제안하는 수온 변환이 대상 시스템이 원하는 것이 아닐 가능성이 높은 경우를 다룬다.

원본 파일을 보존한다. 대응된 레코드는 파생 산출물이다. 원본 .xtf, .gsf, .cnv 파일은 임무 아카이브에 남기고 파생 레코드에서 이를 참조한다. 그래야 나중에 더 나은 음속 프로파일로 재처리하는 경우처럼 원천에서 다시 시작할 수 있다.

2.6 데이터 요구사항으로서의 법적·윤리적 틀

심해 연구는 국제법의 틀 안에서 이루어지며, 데이터 표준도 이를 무시할 수 없다. WIA-ENE-040은 법을 해석하지 않는다. 그것은 법률가와 허가 당국의 일이다. 표준이 할 수 있는 일, 그리고 좋은 구현이 반드시 해야 하는 일은 준수의 증거를 데이터의 일부로 만드는 것이다. 그래야 증거가 각 레코드와 함께 이동하고, 소리 없이 떨어져 나가지 않는다.

연구 허가: UNCLOS, 배타적 경제수역, ISA

유엔 해양법 협약(UNCLOS)에 따라 연안국의 배타적 경제수역(EEZ)이나 대륙붕에서 수행하는 해양 과학 조사에는 그 연안국의 동의가 필요하다. 국가 관할권 밖 해저, 즉 UNCLOS가 “심해저(the Area)”라 부르는 곳에서의 광물 관련 활동은 국제해저기구(ISA)의 관할을 받는다. ENE-040 §14.3은 둘을 모두 거명하고, §11.1.1은 EEZ 허가 확인을 항해 전 사전 조사의 일부로 둔다.

데이터 측면의 결과는 탐사 기록의 permits[] 배열이다. SDK 타입은 각 항목을 type, issuedBy, permitNumber, validUntil의 네 필드로 정의한다. 탐사 기록의 location.eez 필드는 작업이 어느 나라의 수역에서 이루어졌는지를 기록한다. 여기서 두 가지 실무 규칙이 나온다. 첫째, 위치가 EEZ 안에 있는 잠수나 시료는 채취 시각보다 validUntil이 늦은 허가로 뒷받침되어야 한다. 검증기가 이를 자동으로 확인할 수 있고, 운영자가 추가할 수 있는 검사 가운데 가장 쓸모 있는 것 중 하나다. 둘째, Phase 1의 SAMPLE_METADATA 메시지는 허가를 단순 문자열로 나열하지만 탐사 기록은 객체를 쓴다. 가장 단순하고 일관된 해석은 이 문자열을 탐사 기록 permits[]의 한 항목으로 해석되어야 하는 permitNumber 값으로 보는 것이다.

유전자원: 나고야 의정서

생물 시료, 특히 그 유전 정보는 접근 및 이익 공유(ABS)에 관한 나고야 의정서의 적용을 받는다. 의정서는 유전자원을 이용할 때 제공국의 사전 통보 승인(PIC)과 상호 합의 조건(MAT)을 요구하며, ENE-040 §14.2는 세 개념을 모두 열거한다. 배포된 SDK는 생물 시료의 준수 여부를 불리언 하나로 기록한다. 코드상 철자는 nagoyadCompliant이다(구현자가 찾을 수 있도록 철자를 그대로 옮겼다). 여기에 선택 항목인 materialTransferAgreement 참조가 더해진다.

불리언은 주장을 기록할 뿐 증거를 기록하지 않는다. 이 책은 호환성을 위해 불리언을 유지하되, 문서화된 확장으로 제공국, PIC 참조, MAT 참조, 그리고 제공국이 발급하는 경우 ABS 정보공유체계(ABS Clearing-House)를 통해 공개되는 국제 인증 준수 증명서의 식별자를 덧붙이기를 권한다. 이 필드들이 시료 기록의 어디에 놓이는지는 제4장에서 보인다. 국가 관할권 밖 해역에서 채취한 시료의 경우 적용 체제가 변하고 있다. 2023년에 채택된 국가 관할권 이원 지역의 해양 생물다양성에 관한 UNCLOS 협정(흔히 BBNJ 협정이라 부른다)은 해양 유전자원에 관한 자체 규칙을 더한다. 구현은 그런 필드가 들어올 자리를 남겨 두되, 그 내용을 미리 단정해서는 안 된다.

민감 위치와 세 개의 접근 등급

어떤 좌표는 공개하는 것 자체가 위험하다. 취약한 산호 군락이나 새로 발견된 열수 분출공 군집의 정확한 위치는 파괴적인 채집을 부를 수 있다. 광물 매장지의 정밀 위치는 상업적으로나 국가적으로 민감할 수 있다. ENE-040 §14.1은 세 개의 데이터 접근 등급으로 이에 답한다. 제4장은 이를 레코드 단위의 분류로, 제7장은 역할 기반 접근 제어로 구체화한다.

등급	ENE-040 §14.1이 드는 예	기본 처리
공개(Public)	저해상도 멀티빔 해저 지형(50 m 격자), 종 수준의 생물 관찰 목록, 탐사 개요 메타데이터(위치, 날짜)	품질 관리 후 공개, 데이터셋별 라이선스 적용(제7장)
제한(Restricted)	10 m 미만 고해상도 멀티빔(2년 엠바고), 생물 시료의 유전자 데이터(연구자 동의 필요), 광물 자원 정밀 위치(국가 안보 사유)	권한 있는 역할에만 제공, 엠바고 종료일을 데이터셋과 함께 저장
비공개(Confidential)	상업 탐사 데이터, 군사 관련 데이터, 민감 생태계의 정확한 좌표(밀렵 방지)	원 정밀도로는 절대 공개하지 않음, 공개 파생물은 일반화한 좌표 사용

등급은 데이터셋 전체가 아니라 레코드마다 붙는다. 잠수 한 번이 같은 순간에 공개 관찰과 비공개 좌표를 함께 만들어 내기 때문이다. 미묘한 실패는 파생 산출물을 통한 유출이다. 비공개 조사로부터 계산한 공개 50 m 격자나, 잠수 궤적을 되살릴 수 있을 만큼 정밀한 수심과 타임스탬프를 담은 공개 종 목록은 등급이 보호하려던 바로 그 정보를 드러낸다. 따라서 공개 등급으로 내보내는 모든 산출물은 그것이 파생된 비공개 레코드와 대조해 점검해야 한다.

2.7 적합성 한눈에 보기

표준은 어떤 시스템이 그것을 따르는지 판정할 수 있을 때에만 쓸모가 있다. WIA-ENE-040은 적합성 수준을 두 곳에서 정의하는데, 두 정의는 서로 일치하지 않는다.

수준	Phase 1 §6.1(데이터 형식)	Phase 4 §8.1(시스템 전체 인증)
Level 1	기본: 모든 필수 필드를 갖춘 핵심 메시지 형식	기본: Phase 1 형식, Phase 2 API 제공, 주요 저장소 한 곳과의 통합
Level 2	표준: Phase 1의 모든 데이터 타입	표준: 네 Phase 전부, 세 곳 이상의 연구망과의 통합, ISO 19115 메타데이터
Level 3	고급: 바이너리 형식과 전체 검증	고급: 실시간 스트리밍 통합, 클라우드 네이티브 아키텍처, 머신러닝 파이프라인 통합, 99.9% 가동률 SLA

두 척도는 서로 다른 것을 잰다. Phase 1의 수준은 한 구성 요소가 데이터 형식을 얼마나 구사하는지를 말한다. Phase 4의 수준은 한 조직이 생태계 전체와 얼마나 연결되었는지를 말한다. 어떤 시스템은 바이너리 지원과 검증을 모두 갖춘 Phase 1 Level 3이면서, 저장소 한 곳과만 연결된 Phase 4 Level 1일 수 있다. 적어도 문면상으로는 그 반대도 가능하다. Phase 4 Level 2는 Phase 1 Level 3이 요구하는 바이너리 형식을 명시적으로 요구하지 않는다.

이 책과 모든 조달 문서에 적용할 실무 규칙은 간단하다. “Level 2”라고만 쓰지 말고, “Phase 1 Level 2” 또는 “Phase 4 Level 2”라고 쓴다. 제8장은 한 걸음 더 나아가 두 척도를 한 축은 형식 프로파일, 다른 축은 인증 수준인 행렬로 읽자고 제안하고, 각 칸에 해당하는 시험을 열거한다.

인증 절차 자체는 공통이다. Phase 1 §6.2는 준수를 주장하는 시스템에 네 가지를 요구한다. 공식 검증 시험 모음을 통과할 것, 구현한 모든 메시지 타입의 표본 데이터를 제출할 것, 확장이나 표준과의 차이를 문서화할 것, WIA 인증 위원회의 동료 검토를 받을 것이다. Phase 4는 문서, 코드, 보안, 성능에 대한 수동 검토를 더하고, 그 결과물로 서명된 인증서, 배지, 인증 시스템 목록 등재를 들며, 매년 갱신하도록 한다. 2.4절에서 권장한 확장 필드는 세 번째 요구사항에 해당한다. 허용되지만 반드시 문서로 남겨야 한다.

장 요약

잠수 한 번은 여러 시계를 따르는 여러 형식의 데이터를 만든다. WIA-ENE-040은 계측 장비의 형식을 대체하지 않고, 장비에서 나오는 데이터를 단위·검교정 이력·UTC 시각·식별자를 갖춘 자기 기술적 봉투에 담는다.
표준은 하나의 문서군이다. 한국어 핵심 문서, 영어 Phase 명세 네 편, TypeScript SDK(@wia/ene-040), CLI로 이루어진다. 버전 문자열(“1.0”과 “1.0.0”)과 라이선스 표기(MIT와 CC BY 4.0)가 문서마다 다르므로 2.2절의 해석을 따른다.
네 Phase는 계층이다. 형식, API, 음향 프로토콜, 통합으로 나뉘며, 육상 시스템은 그중 일부만 구현할 수 있다.
운용 기록(/v1/…)과 과학 기록(/api/v1/…)은 별개의 계층이다. 명세는 둘을 연결하지 않으며, 이 책의 규약은 각 ID를 한 번만 발급해 두 계층에 그대로 싣는다.
외부 표준(CF, ISO 19115, Darwin Core, OBIS, GEBCO, IODE, DataCite)은 경쟁자가 아니라 대응 대상이다. 단위는 내보낼 때 변환하고 원본 파일은 보존한다.
허가, ABS 증거, 민감 위치는 필드와 접근 등급이 된다. 가장 큰 위험은 공개 파생 산출물을 통한 유출이다.
“Level N”은 모호하다. 언제나 Phase 1 수준인지 Phase 4 수준인지 밝힌다.

복습 질문

ROV 잠수 한 번이 만드는 데이터 흐름을 나열하고, 각각에 대해 변환 과정에서 흔히 사라지는 메타데이터를 하나씩 들어라. 이 가운데 Phase 1 봉투로 막을 수 있는 손실과 선상의 운영 규율이 필요한 손실은 각각 무엇인가?
한 업체가 ROV를 “WIA-ENE-040 준수, 정격 수심 6,000 m”라고 광고한다. 이 주장 가운데 표준이 뒷받침할 수 있는 부분과 표준의 범위를 벗어나는 부분은 무엇인가?
AUV 센서의 압력 측정값이 국가 데이터 센터의 CF-NetCDF 파일에 이르기까지의 경로를 추적하라. 단계마다 담당하는 Phase와, 마지막에 일어나는 단위 변환을 밝혀라.
명세에 missionId–diveId 연결이 없다는 사실은 왜 시계가 어긋날 때 가장 큰 문제가 되는가? 2.4절의 권장 규약과 그 규약이 기대는 적합성 요구사항을 설명하라.
새로 발견된 열수 분출공의 공개 종 목록에 관찰마다 센티미터 단위의 수심과 초 단위의 시각이 들어 있다. 이것이 왜 비공개 등급을 침해할 수 있는지 설명하고, 안전한 일반화 방법을 제안하라.
입찰 요건에 “Level 2 적합성”이라고 적혀 있다. 두 척도 각각에 맞춘 명확한 표현을 하나씩 써 보고, 한쪽은 통과하지만 다른 쪽은 통과하지 못하는 시스템을 묘사하라.