데이터 표준의 필드는 모두 물리 세계의 어떤 사정 때문에 존재한다. 심해 메시지는 수온 값마다 교정 일자를 달고, 위치에는 별도의 정확도 블록을 두며, 압력 허용 범위는 천 bar를 넘기고, 초당 수백 비트밖에 나르지 못하는 링크를 위해 바이너리 인코딩까지 갖춘다. 데이터가 나오는 환경을 감각적으로 이해하지 못하면 이런 선택은 어느 것도 납득되지 않는다. 이 장은 그 감각을 만드는 장이다. 수심 구역, 정수압, 수온과 화학의 범위, 그곳에서 움직이는 탐사 플랫폼, 플랫폼이 싣는 센서, 그리고 통신과 해저 지형 측량을 모두 지배하는 음향을 차례로 다루며, 내용은 의도적으로 물리에 집중한다.
해양학 배경지식은 필요 없다. 고등학교 물리면 충분하며, 모든 공식은 숫자를 넣어 끝까지 계산해 보인다. WIA-ENE-040 문서나 배포된 SDK가 물리를 잘못 적은 곳이 있으면 그 사실을 밝히고 올바른 형태를 제시한다. 잘못된 공식을 검증기에 그대로 옮긴 구현자는 여러 해 동안 멀쩡한 데이터를 거부하거나 잘못된 데이터를 통과시키게 되기 때문이다. 바다를 이미 잘 아는 독자는 1.3~1.5절을 훑어보고 1.1절과 1.2절의 함정, 1.6절의 링크 예산 논리에 집중해도 된다.
WIA-ENE-040은 수심 200 m보다 깊은 곳의 활동에 적용된다. 이 경계는 임의로 정한 것이 아니다. 대략 이 수심에서 대륙붕이 끝나고 해저면이 대륙사면을 따라 급격히 깊어지며, 햇빛은 광합성을 지탱하지 못할 만큼 약해진다. 상부 200 m인 표층(epipelagic zone)은 연안·표층 해양학 대부분이 이루어지는 곳이고, 이미 성숙한 자체 데이터 관행을 갖고 있다. 그래서 표준 §2.1의 범위는 환경이 어둡고 차갑고 고압이 되어 전용 플랫폼으로만 닿을 수 있는 지점에서 시작한다.
배포된 TypeScript SDK의 DepthZone 열거형에는 여전히 EPIPELAGIC 값이 있고, getDepthZone() 헬퍼는 200 m 미만의 모든 수심에 이 값을 돌려준다. 이것은 쓸모가 있다. 잠수정이 표층을 지나 하강하는 동안에도 실제 텔레메트리가 나오며 소프트웨어는 이를 분류할 수 있어야 하기 때문이다. 다만 수심 200 m 미만의 레코드는 표준의 규범적 범위 밖에 있으므로, 적합성 심사자는 그것이 왜 WIA-ENE-040 아카이브에 들어 있는지 물을 수 있다. 합리적인 규칙은 이 레코드를 epipelagic으로 표시해 잠수의 연속 항적 일부로 보존하되, 심해 관찰로 취급하지 않는 것이다.
표준은 바다를 수심 구역으로 나누는 방식을 두 가지 사용하며, 독자는 두 체계를 동시에 머릿속에 두고 있어야 한다.
수층(pelagic) 체계는 물기둥, 즉 잠수정이 지나가는 열린 바다를 기술한다. ENE-040 §2.1과 SDK의 DepthZone 열거형이 쓰는 체계가 이것이다.
mesopelagic(중층대): 200–1,000 m. 햇빛이 조금은 들어오지만 광합성에는 부족한 박명대이다.bathypelagic(점심해대): 1,000–4,000 m. 영구적으로 빛이 없는 수층이다.abyssopelagic(심해저대): 4,000–6,000 m. 심해저 평원 위의 수층이다.hadopelagic(초심해대·해구대): 6,000–11,000 m. 해구 안의 수층이다.저서(benthic) 체계는 해저면 자체, 즉 생물이 살고 시료를 채취하는 서식처를 기술한다. ENE-040 §4는 환경 서술을 이 방식으로 조직한다. 대륙사면대(bathyal, 200–4,000 m, 대륙사면과 대륙대), 심해저 평원대(abyssal, 4,000–6,000 m, 광대한 퇴적물 평원), 초심해대(hadal, 6,000–11,000 m, 해구)가 그것이다.
두 체계가 공존하는 이유는 서로 다른 질문에 답하기 때문이다. 수심 5,000 m 평원 위에서 2,500 m 수심의 수온을 잰 CTD 관측은 점심해대 수층에 속하지만 대륙사면대와는 아무 관계가 없다. 해저면은 거기서 2,500 m나 더 아래에 있기 때문이다. 같은 평원에서 채집한 해삼은 심해저 평원대 생물이며, 이를 심해저대 '수층'에서 왔다고 적으면 틀린 기록이 된다. 해삼은 물기둥이 아니라 바닥에 있었다. 수층 데이터에는 수층 체계의 이름이, 해저면 관찰과 시료에는 저서 체계의 이름이 맞는다. 해저면이 얕은 곳에서는 같은 수심 값에 대해 두 체계가 서로 다른 이름을 줄 수 있다.
depthZone 필드가 체계를 밝혀야 하는 이유이 문제가 왜 중요한지는 명세서 자체가 보여 준다. ENE-040 §12.3의 생물 관찰 기록 예시에는 저서 체계 용어인 "depthZone": "hadal"이 들어 있고, §13에는 ?depthZone=hadal 조건을 쓴 기록 조회가 나온다. 그런데 SDK의 DepthZone 타입은 수층 체계 값만 받으므로, 같은 기록을 SDK로 올바르게 표현하면 hadopelagic이 된다. 타입을 엄격히 검사하는 클라이언트는 명세서의 예시를 거부하고, 한쪽 어휘로만 색인한 서버는 다른 쪽 어휘로 들어온 조회에 빈 결과를 돌려준다.
개정판이 이를 해결할 때까지 구현자는 체계를 명시해야 한다. 기존과 호환되는 가장 단순한 방법은 depthZone을 문자열로 그대로 두고, 체계를 밝히는 형제 필드를 하나 더하는 것이다. 아래 구조는 이 책의 권고이며 v1.0의 규범 내용이 아니다.
{
"location": {
"latitude": 11.3750,
"longitude": 142.5920,
"depth": 8340,
"depthZone": "hadal",
"depthZoneScheme": "benthic"
}
}이렇게 하면 검증기는 값이 선언된 체계에 속하는지 확인할 수 있다. pelagic이면 mesopelagic | bathypelagic | abyssopelagic | hadopelagic 가운데 하나여야 하고, benthic이면 bathyal | abyssal | hadal 가운데 하나여야 한다. 수층 체계의 이름은 수심만으로 유도할 수 있다. 반면 저서 체계의 이름은 레코드가 해저면 위나 그 근처에 있는지에도 달려 있으므로 수심만으로는 유도할 수 없다.
경계 처리도 짚어 두어야 한다. 명세서는 범위를 '200–1,000 m'처럼 적을 뿐, 정확히 1,000 m가 어느 구역에 속하는지 말하지 않는다. SDK는 반열린 구간을 쓴다(depth < 1000이면 중층대, 1,000 m는 점심해대). 이 책도 같은 규칙, 즉 각 구역이 얕은 쪽 경계는 포함하고 깊은 쪽 경계는 제외한다는 규칙을 따른다. 또 명세서 §3.1은 '심해저 평원'을 3,000–6,000 m로 적어 §2.1과 §4의 4,000 m 경계와 어긋난다. §3.1은 구역 분류표가 아니라 지형 용어집이므로, 분류에는 §2.1과 §4의 경계를 써야 한다.
밀도 ρ인 유체 속 수심 h의 압력은 수면의 대기압에 그 위 물기둥의 무게를 더한 값이다.
P(h) = Patm + ρ · g · h
Patm = 101,325 Pa(표준 대기압 1기압), 대표적인 해수 밀도 ρ ≈ 1,025 kg/m³, 표준 중력가속도 g = 9.80665 m/s²를 넣으면 ρg는 미터당 약 10,052 Pa이다. 1 bar는 100,000 Pa이므로 해수 1 m마다 약 0.1005 bar씩 늘어난다. 여기서 익숙한 어림 규칙이 나온다. 10 m마다 약 1 bar이고, 수면에서 대기압 약 1 bar가 더해진다.
심해 데이터에서는 두 계열의 단위가 주로 쓰인다. 공학자는 bar나 MPa(1 MPa = 10 bar)를 쓰고, 해양학자는 데시바(dbar)(1 dbar = 0.1 bar)를 쓰며 관례적으로 대기압을 뺀 해수압(sea pressure)을 보고한다. 해수압을 dbar로 나타내면 수치가 미터 단위 수심과 거의 같아서 데시바가 널리 쓰인다. Phase 1 메시지는 압력을 bar로 싣는다. 뒤의 장에서 보듯이 dbar를 기대하는 저장소와 연동하려면 10배 환산이 필요하고, 대기압을 포함했는지도 분명히 밝혀야 한다.
Phase 1 예시 메시지는 잠수정 수심을 3,547.2 m로 둔다. 수심 3,547 m에서 계산하면 다음과 같다.
이 수심에서는 선체 1 cm²마다 약 365 kgf의 하중이 걸리며, 손바닥만 한 면적에는 수십 톤이 실린다. 이 하중이 모든 내압 용기와 커넥터, 관통부의 설계를 좌우한다. 압력 센서의 교정 일자가 측정값만큼 중요한 이유도 여기에 있다.
그런데 예시 메시지 자체는 3,547.2 m에서 "pressure": 354.72 bar를 보고해 공식보다 몇 bar 낮다. 명세서 예시의 숫자는 예시로만 받아들여야 한다. 압력과 수심을 교차 검사하는 검증기는 정확한 일치를 기대하지 말고 몇 퍼센트의 허용 오차를 두어야 한다. 실제 계측기, 실제 밀도 분포, 실제 위도가 모두 결과를 조금씩 움직이기 때문이다.
해수는 약간 압축되므로 현장 밀도는 수심에 따라 커지고, 중력가속도는 위도에 따라 달라진다. 그래서 일정 밀도 공식은 깊은 곳의 압력을 과소평가하며, 그 차이는 심해저 평원 수심에서 약 1%, 가장 깊은 해구에서는 3% 가까이 된다. 국제적으로 채택된 방법은 해수 상태방정식 TEOS-10이며, Gibbs SeaWater(GSW) 툴박스로 쓸 수 있다. 표준 해양 분포를 가정하는 GSW의 p_from_z 함수는 다음 해수압을 준다.
| 수심 | 일정 밀도 ρ = 1,025 kg/m³ (해수압) | TEOS-10 p_from_z (해수압) | 차이 |
|---|---|---|---|
| 1,000 m (위도 30°) | 1,005 dbar | ≈ 1,009 dbar | ≈ 0.4 % |
| 4,000 m (위도 30°) | 4,021 dbar | ≈ 4,066 dbar | ≈ 1.1 % |
| 6,000 m (위도 30°) | 6,031 dbar | ≈ 6,127 dbar | ≈ 1.6 % |
| 11,000 m (위도 11°) | 11,057 dbar | ≈ 11,342 dbar | ≈ 2.6 % |
간단한 점검과 경보에는 일정 밀도 공식으로 충분하다. 압력 센서 값에서 계산한 수심 같은 파생 데이터 산출물에는 TEOS-10을 쓰고, 그렇게 했다는 사실을 메타데이터에 남겨야 한다. 표의 마지막 행은 Phase 1 범위표의 실제 문제도 드러낸다. 범위표는 압력 상한을 1,100 bar로 두지만, TEOS-10으로 계산한 수심 11,000 m 부근의 절대 압력은 약 1,135 bar이다. 가장 깊은 해구 바닥에서 정상 작동하는 압력 센서가 OUT_OF_RANGE로 표시되는 것이다. 제8장은 이를 정오표 제안으로 올린다. 그때까지 구현자는 전해양 수심급 잠수정이 보낸 1,100 bar를 약간 넘는 값을 개연성 있는 값으로 보고, 버리지 말고 검토 대상으로 넘겨야 한다.
WIA-ENE-040 자료에는 압력을 잘못 적은 곳이 두 군데 있으며, 어느 쪽도 그대로 옮겨서는 안 된다.
ENE-040 §9.1은 P(atm) = 1 + depth/10과 P(bar) = 1 + depth/10을 나란히 적어 atm과 bar를 같은 단위처럼 다룬다(두 단위는 1.3% 다르다). 또 P(MPa) = depth × 0.1 × ρ × g를 제시하는데, 이 식은 차원부터 맞지 않는다. ρ = 1,025, g = 9.81을 넣으면 1,000 m에서 1,005,525라는, 의미 있는 단위가 없는 숫자가 나온다. 그 아래 적힌 계산값(예: 1,000 m ≈ 10.1 MPa)은 우연히 거의 맞는데, 이런 오류가 검토를 통과하는 전형적인 경로가 바로 이것이다.
SDK의 calculatePressure()(@wia/ene-040)는 MPa 필드를 depth × 0.1 × 1025 × 9.81 / 1e6으로 계산한다. 1,000 m를 넣으면 약 1.0 MPa를 돌려주는데, 올바른 값은 약 10.1 MPa이므로 10배 작다. atm과 bar 필드는 1~2% 안에 들기 때문에 반환 객체는 내부적으로도 모순이다. bar / 10은 mpa와 같아야 하는데 그렇지 않다. 이것은 알려진 버그로 다루어야 한다. mpa 필드를 쓰는 코드는 모두 자릿수 하나만큼 틀리며, 이에 대한 회귀 테스트는 모든 SDK 테스트 모음에 들어가야 한다(제8장).
올바른 헬퍼는 몇 줄이면 된다. 아래 함수는 절대 압력을 세 단위로, 해수압을 데시바로 함께 돌려주어 호출자가 게이지 압력과 절대 압력을 혼동하지 않게 한다.
// 일정 밀도 근사를 쓰는 정수압 계산.
// 깊은 곳에서 대략 1~3% 오차. 데이터 산출물에는 TEOS-10(GSW)을 쓸 것.
export const P_ATM_PA = 101_325; // 표준 대기압, Pa
export const RHO_SEAWATER = 1025; // kg/m^3, 표층 부근 대표값
export const G0 = 9.80665; // 표준 중력가속도, m/s^2
export interface Pressure {
pa: number; // 절대 압력, Pa
bar: number; // 절대 압력, bar (1 bar = 1e5 Pa)
mpa: number; // 절대 압력, MPa (항상 bar / 10)
seaDbar: number; // 해수압(게이지), dbar, 대기압 제외
}
export function pressureAt(depthM: number, rho = RHO_SEAWATER, g = G0): Pressure {
if (!Number.isFinite(depthM) || depthM < 0) {
throw new RangeError(`depth must be a non-negative number of metres, got ${depthM}`);
}
const gaugePa = rho * g * depthM;
const pa = P_ATM_PA + gaugePa;
return { pa, bar: pa / 1e5, mpa: pa / 1e6, seaDbar: gaugePa / 1e4 };
}
// pressureAt(1000).mpa -> 약 10.15 (SDK calculatePressure(1000).mpa -> 약 1.01)
// pressureAt(3547).bar -> 약 357.6아래 표는 구역 구분과 압력, 수온을 한데 모은 것이다. 압력은 각 구역의 깊은 쪽 경계에서 일정 밀도 공식으로 계산한 절대 압력이고, 수온은 대양의 대표값으로 해역에 따라 다르다.
| 수층 구역 (저서 구역) | 수심 | 깊은 쪽 경계의 압력 | 대표 수온 | 대표 플랫폼 |
|---|---|---|---|---|
| 중층대 (대륙사면대 상부) | 200–1,000 m | ≈ 101 bar / 10.1 MPa | 수온약층을 지나며 급격히 낮아짐, 해역별 차이 큼 | ROV, AUV, CTD 관측, 글라이더 |
| 점심해대 (대륙사면대) | 1,000–4,000 m | ≈ 403 bar / 40.3 MPa | 수 °C | ROV, HOV, AUV, 랜더 |
| 심해저대 (심해저 평원대) | 4,000–6,000 m | ≈ 604 bar / 60.4 MPa | 약 2–4 °C | 6,000–6,500 m급 HOV·ROV·AUV, 랜더 |
| 초심해대·해구대 (저서 구역도 초심해대) | 6,000–11,000 m | ≈ 1,107 bar / 110.7 MPa (TEOS-10으로는 ≈ 1,135 bar) | 약 1–4 °C, 수심에 따라 약간 상승 | 전해양 수심급 HOV, 랜더, 일부 ROV |
검증기는 전형적인 값이 아니라 물리적으로 가능한 값의 범위를 알아야 한다. 심해는 대부분의 장소에서 놀라울 만큼 균일하고, 몇몇 장소에서는 놀라울 만큼 극단적이다. Phase 1 범위표는 이 둘을 모두 담아야 한다.
수온약층 아래의 대양 물은 거의 어디서나 차갑다. 심층수와 심해저 평원 위의 물은 대략 2–4 °C이다. 해구 안에서는 현장 수온이 수심에 따라 약간 올라가는데, 열원이 있어서가 아니라 물이 단열 압축되기 때문이다. 극지 심층수는 0 °C 아래로 내려갈 수 있고, 보통 염분의 해수는 약 −1.9 °C에서 언다. 따라서 Phase 1 범위의 하한 −2 °C는 액체 상태 해수의 최저 온도 바로 아래에 놓인다.
상한은 열수 분출공에서 나온다. 고온 '블랙 스모커' 굴뚝에서 나오는 유체는 흔히 300–400 °C로 측정되며, 이 유체가 액체로 남는 것은 깊은 곳의 압력이 끓는점을 100 °C보다 훨씬 높이 올려 주기 때문이다. Phase 1이 400 °C까지 허용하는 이유가 이것이다. 문헌에 보고된 가장 뜨거운 분출 유체는 이 한계와 같거나 조금 넘기 때문에, 400 °C를 조금 넘는 탐침 값은 버리지 말고 OUT_OF_RANGE로 표시해 검토해야 한다. 여기서 얻는 설계 교훈은 범위표가 모든 측정원에 대한 포괄 범위라는 점이다. 그래서 범위표는 어느 한 센서가 실제로 보는 범위보다 훨씬 넓다. 350 °C를 읽을 리 없는 CTD 같은 센서별 타당성 한계는 전역 범위표가 아니라 계측기 메타데이터에 두어야 한다.
광합성에 쓸 만한 햇빛은 200 m 부근에서 사라지고, 약 1,000 m에 이르면 햇빛은 전혀 감지되지 않는다. 그 아래의 빛은 생물 발광과 잠수정이 가져간 조명뿐이다. 이는 데이터 설계에 두 가지 결과를 낳는다. 아카이브의 모든 영상은 인공 조명 아래에서 찍혔으므로 조명 구성과 카메라 설정이 영상 출처 정보의 일부가 된다. 또 심해 영상의 색은 조명과 수중 경로에 좌우되므로, 색에 기대는 동정은 메타데이터가 있어야 해석할 수 있다.
대양의 염분은 실용염분척도로 35에 가까우며(Phase 1은 'PSU'로 표기한다), 심층에서는 변화가 아주 작다. Phase 1의 0–50 PSU 범위는 넉넉하게 잡은 것으로, 브라인 풀이나 희석된 분출수·연안수까지 받아들이기 위한 것이다. 용존산소는 훨씬 크게 변한다. 중층의 산소 최소층에서는 0에 가까워질 수 있으며, Phase 1의 용존산소 범위가 0 mg/L에서 시작하는 이유가 여기에 있다. 대양 심층수의 pH는 8보다 조금 낮지만 분출 유체는 전혀 다르다. 블랙 스모커 유체는 강한 산성이고, Lost City 유형처럼 사문암화 작용에 기반한 계는 강한 알칼리성 유체를 내놓는다. Phase 1이 pH 0–14 전 범위를 허용하는 근거는 이 양 극단이다.
종합하면 Phase 1 검증표의 범위(수심 0–11,000 m, 수온 −2~400 °C, 압력 0–1,100 bar, 염분 0–50 PSU, pH 0–14, 용존산소 0–20 mg/L)는 '이 표준이 적용되는 어디에서든 물리적으로 가능한 값'으로 읽는 것이 가장 좋다. 범위 안의 값도 맥락상 틀릴 수 있고, 앞의 초심해 압력 사례처럼 범위를 조금 벗어난 값도 옳을 수 있다. 명세서가 거부 대신 품질 플래그를 요구하는 이유가 여기에 있다.
SDK의 SubmersibleType 열거형은 hov, rov, auv, lander, crawler의 다섯 가지 플랫폼 부류를 정의한다. 데이터 관점에서 이들은 두 가지 면에서 다르다. 첫째는 전력 공급과 연결 방식으로, 이것이 데이터가 실시간으로 오는지 회수 후에야 오는지를 결정한다. 둘째는 해저에서 할 수 있는 작업으로, 이것이 어떤 종류의 기록이 생기는지를 결정한다.
SubmersibleType | 수면과의 연결 | 전력과 운용 시간 | 주요 산출 데이터 | 대표 기체 (정격 수심) |
|---|---|---|---|---|
hov — 유인 잠수정 | 음향만 (음성, 문자, 저속 텔레메트리) | 탑재 배터리, 잠수 1회가 하루 작업 시간 이내 | 동영상·정지 영상, 관찰자 기록, 시료, CTD | Alvin (6,500 m), Shinkai 6500 (6,500 m), Jiaolong (7,000 m), Fendouzhe·Limiting Factor (전해양 수심) |
rov — 원격 조종 무인 잠수정 | 테더, 대개 광섬유 포함 | 모선에서 전력 공급, 배터리가 아니라 선박 운용 시간과 인력이 한계 | 연속 HD 영상, 실시간 센서 스트림, 시료, 텔레메트리 | Jason (6,500 m), 작업급 ROV는 흔히 수천 m급 정격 |
auv — 자율 무인 잠수정 | 잠항 중에는 음향, 수면에서는 위성 | 배터리, 임무 길이는 에너지 예산이 결정 | 멀티빔 측심, 측면주사, 지층 탐사, 자력, CTD, 사진 측선 | Sentry (6,000 m) |
lander — 자유낙하 착륙선(랜더) | 음향 이탈 장치와 트랜스폰더뿐 | 배터리, 명세서는 수 시간~수일의 단기 배치와 수개월의 장기 배치를 든다 | 저속 연속 촬영, 미끼 카메라 계수, 트랩 시료, CTD·DO·유속 시계열 | 목표 수심에 맞춰 제작, 초심해용 포함 |
crawler — 해저면 이동 로봇 | 해저 관측소 케이블 또는 없음 | 관측소 전력 또는 배터리, 장기 운용 | 한 지점의 장기 해저 시계열 | 대개 특정 관측소 전용으로 제작 |
표의 수심은 모두 정격 수심, 즉 기체가 설계·인증된 수심이며 특정 잠수의 기록을 주장하는 것이 아니다. 최심 잠수 기록은 출처마다 수십 m씩 다르므로 검증 한계의 근거로 삼기에 적합하지 않다.
HOV는 조종사 1명과 관찰자 1~2명을 내압구에 태운다. 내압구는 대개 티타늄으로 만들며 두꺼운 아크릴 관측창을 단다. HOV의 데이터는 사람이 타고 있다는 사실이 결정한다. 잠수는 길어야 하루로 짧고, 승무원의 생명 유지 장치가 바닥나기 전에 떠올라야 하며, 모선으로 가는 것은 음향 링크를 거친 것뿐이다. 그래서 HOV의 과학 데이터는 대부분 회수 시점에 한꺼번에 들어오고, 모선이 실시간으로 받는 것은 위치와 상태를 담은 가느다란 스트림에 그친다.
작업급 ROV는 테더로 모선과 이어지며(흔히 디프레서나 테더 관리 장치를 거친다), 테더는 전력을 내려보내고 광섬유로 데이터를 올려 보낸다. 그래서 ROV는 심해 플랫폼 가운데 유일하게 광대역 실시간 링크를 가진다. Phase 1의 VEHICLE_TELEMETRY 예시가 "fiber": "CONNECTED"를 보이고 음향 링크를 별도 대기 상태로 둔 것도 이 때문이다. 광섬유의 전파 지연은 무시할 만하다(빛은 광섬유 10 km를 약 50 µs에 지난다). 운용자가 느끼는 지연은 수심이 아니라 모선의 영상 인코딩, 처리, 네트워크에서 생긴다. 테더 지연이 수심에 따라 달라진다는 ENE-040 §5.2.1의 수치는 설계 입력으로 써서는 안 된다.
AUV는 미리 짜 둔 임무를 따라가며, 흔히 평행한 측선을 오가는 '잔디 깎기' 패턴으로 해저면 위 일정 고도를 유지해 난다. 바닥 가까이 날 수 있으므로 선박에 단 음향측심기보다 훨씬 자세하게 측량한다. 테더가 없으므로 가끔 음향으로 상태만 알리고, 전체 데이터 세트는 회수한 뒤에야 존재한다. 데이터 설계 관점에서 AUV 기록은 늦게, 큰 묶음으로 도착하며, 그 타임스탬프는 임무 내내 GPS와 단절된 시계에 의존한다. Phase 1 §3.3이 시간 드리프트를 문서화하라고 요구할 때 염두에 둔 것이 바로 이 경우이다.
랜더는 수면에서 떨어뜨리면 해저까지 자유낙하한 뒤 수 시간에서 수개월 동안 기록하고, 음향 명령을 받으면 밸러스트를 버리고 떠오른다. 단순하고 어떤 수심에도 맞춰 만들 수 있어서 초심해 연구의 주력 장비로 쓰인다. 해저면 이동 로봇은 궤도나 바퀴로 해저의 한 구역을 천천히 돌아다니는 기체로, 대개 케이블 관측소에 연결된다. 둘 다 한 장소의 긴 시계열을 만드는데, 이는 공간을 가로지르는 잠수 항적과는 다른 데이터 형태이다. 제4장의 기록 모델은 두 형태를 모두 수용해야 한다.
SDK의 ROVSensorSuite 인터페이스는 기체의 센서를 항법, 영상, 환경, 음탐의 네 블록으로 묶는다. 구현자에게 쓸모 있는 질문은 각 센서가 무엇이냐가 아니라 어느 Phase 1 메시지의 어느 필드를 채우느냐이다. 아래 표가 그 대응을 보인다.
| 센서 | 측정 대상 | Phase 1 대상 필드 | 구현 참고 |
|---|---|---|---|
| CTD — 전도도 셀 | 전기 전도도 | environment.salinity (PSU) | 염분은 전도도·수온·압력으로 계산한 값이므로 산출 알고리즘을 기록 |
| CTD — 서미스터 | 수온 | environment.temperature | 빠른 하강 시 시정수가 문제가 됨 |
| CTD·기체 압력 센서 | 압력 | environment.pressure (bar), location.depth | 수심은 측정값이 아니라 압력에서 유도한 값 |
| 용존산소(DO) 센서 | 용존산소 | environment.dissolvedOxygen (mg/L) | 옵토드는 수온·염분 보정이 필요 |
| pH 센서 | pH | environment.pH | 사용한 pH 척도를 메타데이터에 명시 |
| ORP 센서 | 산화환원전위 | Phase 1에 해당 키 없음 | value/unit/sensorId/calibrationDate 형태를 그대로 쓴 확장 필드로 전달 |
| 탁도계(광학 후방산란) | 입자 농도 | environment.turbidity (NTU) | 분출 플룸 탐지에 유용 |
| 음속계 | 음속 | environment.soundVelocity (m/s) | 측심 데이터가 참조하는 음속 프로파일에도 쓰임 |
| 도플러 속도계(DVL) | 대지 속도, 해저면 고도 | location.altitude, 텔레메트리 position.altitude | 바닥 추적 거리 안에서 INS 드리프트를 억제 |
| 초단기선 음향측위(USBL) | 모선 기준 거리와 방위 | location.latitude/longitude, accuracy.horizontal | 경사 거리가 늘수록 오차가 커지므로 측위마다 정확도를 보고 |
| 관성항법장치(INS) | 자세, 추측 항법 위치 | 텔레메트리 heading·pitch·roll, 융합 위치 | 항법해는 INS·DVL·USBL·수심을 융합해 얻음 |
| 카메라와 레이저 스케일러 | 영상, 크기 기준 | 아카이브 imagery/, specimen.photographs | 간격을 아는 평행 레이저로 생물 크기를 추정 |
| 멀티빔 음향측심기 | 해저 수심, 후방산란 | BATHYMETRIC_DATA의 soundings[] | 1.7절 참조 |
| 측면주사 음탐기, 해저 지층 탐사기 | 해저면 영상, 퇴적층 | sonarConfiguration, 임무 아카이브의 파일 | Phase 1에는 핑 단위 메시지 유형이 없음 |
이 대응표에서 뒤의 장들을 좌우할 관찰 세 가지가 나온다. 첫째, 수심은 파생 값이다. 압력 센서가 재는 것은 압력이고, 수심은 1.2절에서 보았듯이 밀도 모델과 위도를 거쳐 압력에서 얻는다. 산출 방법이 빠진 수심 필드는 초심해대에서 수십 m 수준의 모호함을 안는다. 센서 자체의 정확도도 측정 범위에 비례한다. 명세서가 예로 드는 전체 눈금 0.01% 정확도의 센서라도 전해양 수심 정격이면 오차 폭이 1 m 안팎이 된다.
둘째, 위치는 측정값이 아니라 융합 추정값이다. 4,000 m 수심에서 기체의 위치를 혼자 알려 주는 센서는 없다. USBL은 모선에서 멀어질수록 오차가 커지는 거친 측위값을 주고, INS는 매끄럽지만 드리프트하는 항적을 주며, DVL은 기체가 바닥을 추적할 수 있을 만큼 가까이 있는 동안 그 드리프트를 붙잡아 준다. Phase 1이 모든 위치에 accuracy.horizontal과 accuracy.vertical을 싣는 이유, 그리고 그 값을 데이터시트에서 베끼지 말고 측위마다 계산해야 하는 이유가 여기에 있다.
셋째, 모든 값에는 계보가 있다. Phase 1은 환경 값 하나하나를 value, unit, sensorId, calibrationDate를 가진 객체로 감싼다. 심해 센서는 압력과 온도의 반복 변화 속에서 드리프트하며, 몇 달 뒤 수상한 값을 점검하는 데이터 관리자는 어느 계측기가 그 값을 냈고 마지막 교정이 언제였는지 알아야 한다. 이 구조는 제3장에서 자세히 다룬다.
해수는 전기가 통하는 도체이며, 도체 속 전파는 표피 깊이라는 특성 거리 안에서 사그라진다. 전도도 약 4 S/m인 해수의 표피 깊이는 10 kHz에서 약 2.5 m, 1 MHz에서 약 0.25 m에 불과하고, 주파수가 높을수록 더 짧아진다. 그래서 Wi-Fi, 이동통신, 위성 링크는 수면 아래에서 쓸모가 없다. 빛은 그보다 멀리 가지만 수십 m 안에서 산란·흡수되고 시야가 트여 있어야 한다. 수 km의 해수를 건너는 신호는 소리뿐이며, 테더 없는 심해 링크가 모두 음향 모뎀인 이유가 이것이다.
해수 속 음속은 약 1,500 m/s이다(정확한 값은 수온·염분·압력에 따라 대개 1,450–1,550 m/s 범위에서 달라지며, Phase 1 예시는 1,489.3 m/s를 보고한다). 전파보다 다섯 자릿수 느린 이 속도 때문에 물리적 거리가 그대로 지연이 된다.
| 수직 거리 | 편도 전파 시간 | 왕복 (명령 + 확인 응답) |
|---|---|---|
| 1,000 m | ≈ 0.7 s | ≈ 1.3 s |
| 4,000 m | ≈ 2.7 s | ≈ 5.3 s |
| 6,000 m | ≈ 4.0 s | ≈ 8.0 s |
| 11,000 m | ≈ 7.3 s | ≈ 14.7 s |
이 값들은 곧은 수직 경로에 대한 하한이다. 수평 거리, 음선의 굴절, 모뎀 처리 시간이 모두 여기에 더해진다. 확인 응답을 기다린 뒤에야 다음 패킷을 보내는 프로토콜은 대부분의 시간을 기다리는 데 쓰게 된다. Phase 3 스택(제6장)이 선택적 재전송과 하이브리드 ARQ를 쓰고 타이머를 초 단위로 잡는 이유가 이것이다.
소리는 두 가지 방식으로 에너지를 잃는다. 확산 손실은 기하학적 손실로 주파수와 무관하며, 구면 확산이면 거리 r(m)에 대해 20 log₁₀ r 데시벨만큼 세기가 줄어든다. 흡수는 해수의 점성과 화학적 이완 작용으로 소리가 열로 바뀌는 현상이며, 주파수가 높을수록 가파르게 커진다. 널리 쓰이는 경험식인 Thorp 공식은 주파수 f(kHz)에 대한 흡수 계수를 dB/km로 준다.
α(f) ≈ 0.11 f²/(1+f²) + 44 f²/(4100+f²) + 2.75×10⁻⁴ f² + 0.003
| 주파수 | 흡수 계수 (Thorp 근사) | 10 km 동안의 흡수 |
|---|---|---|
| 1 kHz | ≈ 0.07 dB/km | ≈ 0.7 dB |
| 3 kHz | ≈ 0.2 dB/km | ≈ 2 dB |
| 8 kHz | ≈ 0.8 dB/km | ≈ 8 dB |
| 16 kHz | ≈ 2.8 dB/km | ≈ 28 dB |
| 30 kHz | ≈ 8.3 dB/km | ≈ 83 dB |
1차 링크 예산으로 그 의미를 따져 보자. 수신 레벨은 음원 레벨에서 전달 손실을 뺀 값이다. RL = SL − (20 log₁₀ r + α · r/1000). Phase 3의 최대 음원 레벨인 190 dB re 1 µPa @1 m와 거리 5 km를 가정하면, 구면 확산 손실은 20 log₁₀ 5,000 ≈ 74 dB이다. 3 kHz에서는 흡수가 약 1 dB 더해져 수신 레벨이 약 115 dB가 된다. 30 kHz에서는 흡수가 약 41 dB 더해져 수신 레벨이 약 75 dB로 떨어진다. 같은 송신기인데 40 dB, 곧 1만 배 차이가 난다. 수신기가 동작하려면 신호가 해당 대역의 배경 소음보다 일정 여유 이상 커야 한다. 배경 소음은 해상 상태, 선박 통항, 기체 자체의 소음에 따라 달라지므로 여기서 수치를 들지는 않는다. 그러나 방향은 분명하다. 먼 거리에는 낮은 주파수가 필요하고, 낮은 주파수는 좁은 대역폭을 뜻한다. 모뎀이 쓸 수 있는 대역폭은 대략 중심 주파수의 일부분이기 때문이다.
Phase 3 대역 계획(제6장)이 가장 낮은 1–3 kHz 대역에 10–20 km 거리와 초당 수백 비트의 속도를, 가장 높은 16–30 kHz 대역에 1 km 미만 거리와 초당 수십 킬로비트의 속도를 짝지은 이유가 이것이다. 여기서 쓴 모델은 의도적으로 단순하다. 실제 채널에서는 수면과 해저에서 생기는 다중 경로, 움직이는 기체가 만드는 도플러 편이, 음속 분포에 따른 굴절이 더해지며, 이들 모두가 손실 예산만으로 예상한 것보다 달성 가능한 속도를 낮춘다.
심해에서 영상급 대역폭을 얻는 유일한 방법은 케이블을 까는 것이다. ROV 테더와 해저 관측소 케이블은 광섬유를 품고 있고, 음향 링크보다 여러 자릿수 넓은 대역폭을 제공한다. 대가는 테더 자체이다. 항력, 취급 장비, 그리고 기체 위에 계속 머물러야 하는 모선이 필요하다. 데이터 설계의 원칙은 음향 조건을 전제로 삼는 것이다. 초당 수백 비트와 수 초의 지연에서 동작하는 메시지 형식과 프로토콜은 광섬유에서도 동작하지만, 그 반대는 성립하지 않는다. Phase 1의 선택적 바이너리 인코딩과 Phase 3 스택 전체가 존재하는 이유가 이 비대칭이다.
멀티빔 음향측심기는 짧은 펄스를 쏜 뒤, 기체 진행 방향과 직각으로 부채꼴을 이루는 여러 개의 좁은 수신 빔으로 동시에 반향을 듣는다(ENE-040 §6.1은 빔 100–500개의 부채꼴을 든다). 시스템은 빔마다 반향의 왕복 시간 t를 잰다. 음속이 균일한 바다라면 경사 거리는 c·t/2이고, 연직에서 θ만큼 기운 빔의 수심은 (c·t/2)·cos θ이다. 수심 3,547 m에서 연직 빔의 반향은 약 2 × 3,547 / 1,500 ≈ 4.7초 뒤에 돌아오며, 바깥쪽 빔은 더 오래 걸린다.
이 왕복 시간이 핑 주기를 정한다. 수심 4,000 m 해역의 선박 탑재 시스템은 앞선 핑의 바깥쪽 빔 반향이 모두 돌아올 때까지 다음 핑을 쏠 수 없고, 그 시간은 5초를 넘는다. 측량 속력 4 m/s라면 핑 사이에 선박이 20 m 넘게 움직이므로(예시 수치), 진행 방향 측심 밀도를 제한하는 것은 음탐기 전자 장치가 아니라 물리이다.
바다는 균일하지 않다. 음속은 수심에 따라 변하고, 음선은 층을 지날 때마다 스넬의 법칙에 따라 휜다. 하나의 음선을 따라 sin θ / c 값이 일정하게 유지된다. 왕복 시간과 발사 각도를 해저면 위치로 바꾸려면 처리 소프트웨어가 대개 CTD나 음속계 관측으로 얻은 음속 프로파일(SVP)을 따라 각 음선을 추적해야 한다. SVP가 틀리면 바깥쪽 빔이 엉뚱한 수심에 떨어져 측심 폭의 가장자리가 위나 아래로 휘는데, 보정하지 않은 측량에서 흔히 보는 인공물이다. Phase 1 BATHYMETRIC_DATA 메시지가 사용한 SVP(processingParameters.soundVelocityProfile)와 음선 추적 방식("rayTracing": "SNELL")을 밝히는 이유가 이것이다. 이 정보가 없으면 측심값을 재처리하거나 감사할 수 없다. INS가 주는 기체 자세(상하 동요, 종동요, 횡동요)와 연직 기준면에 대한 조석 보정이 이 연쇄를 마무리한다.
반향에는 시간 말고도 세기가 있다. 갓 굳은 용암이나 암반처럼 단단하고 거친 면은 부드러운 진흙보다 더 많은 소리를 음탐기 쪽으로 되돌린다. 이 후방산란을 모자이크한 영상은 해저면 성질의 지도이며 퇴적물 분류의 바탕이 된다. Phase 1 측심값은 intensity 값을 싣지만, 명세서 예시("intensity": 142)에는 단위가 없다. 구현자는 이 값이 dB 단위로 교정된 레벨인지 계측기의 원시 계수인지 기록해야 한다. 그렇지 않으면 두 측량을 비교할 수 없다.
1.6절의 흡수 물리가 음탐기 선택에도 그대로 작용한다. ENE-040 §6.1.2는 다음과 같은 대표값을 제시한다.
| 주파수 | 최대 수심 (명세서) | 해상도 (명세서) | 주 용도 (명세서) | 이유 |
|---|---|---|---|---|
| 12 kHz | 11,000 m | 낮음 (50–100 m) | 전해양 수심 매핑 | 흡수가 작아 해구 바닥의 반향도 돌아온다 |
| 30 kHz | 5,000 m | 중간 (20–50 m) | 심해저 평원 | 거리와 해상도의 절충 |
| 100 kHz | 1,000 m | 높음 (1–5 m) | 대륙붕, 정밀 조사 | 흡수 때문에 거리가 1 km 안팎으로 제한된다 |
| 400 kHz | 200 m | 매우 높음 (<1 m) | 천해, 인공 구조물 | 흡수가 매우 커서 거리가 아주 짧다 |
여기서 해상도는 주파수만큼이나 거리에 좌우된다. 폭 1°인 빔은 연직 방향에서 해저면의 약 D · tan 1° ≈ 0.017 D 폭을 비춘다(D는 해저면까지의 거리). 수심 4,000 m 위의 선박에서라면 약 70 m로, 심해용 시스템의 '낮은' 해상도와 들어맞는다. ENE-040 §5.3.2의 임무 프로파일처럼 해저면 위 50–100 m 고도로 나는 AUV라면 같은 1° 빔이 수심과 상관없이 약 1–2 m만 비춘다. 명세서가 깊은 곳을 조사하는 AUV에도 100–400 kHz 음탐기를 다는 이유가 이것이다. 기체가 음탐기를 충분히 가까이 데려가므로 높은 주파수도 닿는다. 데이터 설계 관점에서 측량의 해상도는 음탐기 단독이 아니라 플랫폼과 고도의 조합이 정하는 속성이다. BATHYMETRIC_DATA 메시지에 선언하는 gridResolution은 데이터시트가 아니라 빔 풋프린트로 정당화해야 한다.
측면주사 음탐기와 해저 지층 탐사기가 음향 도구 모음을 완성한다. 측면주사 음탐기는 항적 양옆 해저면의 고해상도 영상을 만들지만 수심을 정확히 재지는 못한다. 해저 지층 탐사기는 낮은 주파수(ENE-040 §6.3은 2–15 kHz를 든다)를 써서 소리가 퇴적물을 뚫고 들어가 묻힌 층에서 반향이 돌아오게 한다. 두 장비 모두 영상 성격의 산출물을 만들며, Phase 1은 이를 개별 측심값이 아니라 아카이브 파일로 다룬다.
depthZone 값은 모호하며, 명세서 자체의 "hadal" 예시도 SDK의 수층 열거형에 맞지 않는다.calculatePressure()의 MPa 값은 틀렸으므로 옮겨 써서는 안 된다. TEOS-10으로 보면 Phase 1의 상한 1,100 bar는 가장 깊은 해구에 비해 낮다.depthZone과 함께 저장한다. 각각 어느 체계의 어떤 이름을 받는가? 저서 체계의 이름을 수심만으로 유도할 수 없는 이유는 무엇인가?calculatePressure(6000).mpa는 어떤 값을 돌려주며, 어떤 불변식 테스트 하나가 이 버그를 잡아냈겠는가?