개념
이 레슨의 대상은 지상 소프트웨어다
위성 사업의 소프트웨어는 크게 둘로 갈린다. 탑재 소프트웨어 는 위성에 올라가는 것이고, 레슨 2~4 의 규격 환경에 가깝다. 지상 소프트웨어 는 받은 데이터를 처리해 산출물을 만드는 것이고, 성격이 전혀 다르다.
이 레슨은 지상 데이터 처리 파이프라인 을 다룬다. 이쪽은 일반 데이터 엔지니어링과 닮아 보이지만 세 가지가 다르다.
- 기준값(정답) 이 없거나 드물다. 관측 결과가 맞는지 비교할 대상이 없다
- 같은 입력을 다시 처리한다. 알고리즘이 개선되면 과거 데이터 전체를 다시 처리하고, 그러면 이미 배포된 산출물의 값이 바뀐다
- 산출물이 크다. 한 건이 수백 MB 에서 수 GB 이고, 비교를 눈으로 할 수 없다
이 세 가지가 QA 의 질문을 바꾼다.
처리 레벨 — 단계마다 검증 질문이 다르다
위성 관측 데이터는 레벨로 나눠 다룬다. 널리 쓰이는 체계로 NASA 의 지구관측 데이터 시스템(EOSDIS) 이 공개한 처리 레벨 정의가 있고, 공개 문서가 각 레벨을 이렇게 설명한다.
| 레벨 | 공개 정의의 성격 |
|---|---|
| Level 0 | 재구성된 미처리 기기·탑재체 데이터. 전 해상도. 통신 산출물(동기 프레임·헤더·중복) 제거됨 |
| Level 1A | 재구성된 미처리 기기 데이터. 전 해상도, 시각 참조, 보조 정보 주석(복사·기하 보정 계수, 지리참조 매개변수 등) |
| Level 1B | Level 1A 를 센서 단위로 처리한 것(기기마다 1B 가 있지는 않다) |
| Level 2 | Level 1 원천과 같은 해상도·위치의 유도된 지구물리 변수 |
| Level 3 | 균일한 시공간 격자로 사상된 변수. 보통 어느 정도의 완전성·일관성을 가짐 |
| Level 4 | 모델 출력 또는 하위 레벨 데이터 분석 결과(여러 측정에서 유도된 변수 등) |
이 레벨 구분이 QA 에게 주는 것은 검증 질문의 지도다.
| 레벨 | QA 의 주된 질문 |
|---|---|
| 0 | 수신한 것이 빠짐없이·중복 없이 들어왔는가 |
| 1A | 시각과 위치 정보가 맞게 붙었는가, 보조 정보가 완전한가 |
| 1B | 센서 단위 변환이 맞는가(복사·기하 보정의 적용) |
| 2 | 유도된 물리량이 타당한가, 품질 플래그가 맞는가 |
| 3 | 격자로 모을 때 무엇이 버려지고 섞였는가 |
| 4 | 모델 가정이 산출물에 어떻게 반영됐는가 |
레벨이 올라갈수록 "맞는지" 를 판정하기 어려워진다. 레벨 0 은 건수와 체크섬으로 판정되지만, 레벨 2 의 물리량이 맞는지는 비교할 정답이 없다. 그래서 전략이 달라진다 — 아래에서 다룬다.
주의 — 레벨 체계는 기관·미션마다 세부가 다르다. 위 정의는 공개된 체계 하나이고, 우리 사업의 산출물 레벨 정의와 각 레벨의 산출물 규격은 미션 문서에서 확인한다 (원문 확인). 같은 "Level 2" 라는 이름이 미션마다 다른 것을 가리킬 수 있다.
정답이 없을 때 정확도를 판정하는 네 가지 방법
"이 값이 맞습니까" 에 직접 답할 수 없으므로, 우회해서 답한다. 실무에서 쓰이는 방법은 네 가지이고, 대개 여러 개를 조합 한다.
1) 독립 기준과 비교한다. 지상 관측소 측정값, 다른 위성의 같은 영역 관측, 항공 관측처럼 독립적으로 얻은 값 과 비교한다. 이것이 검보정(calibration / validation) 활동의 뼈대다. QA 관점의 핵심은 비교 조건 이다 — 관측 시각 차이, 공간 범위 차이, 대기 조건, 기기 특성 차이. 조건을 맞추지 않은 비교는 차이가 나도 무엇 때문인지 알 수 없다.
2) 물리적 타당성을 검사한다. 값이 물리적으로 가능한 범위 안에 있는가. 온도가 절대영도 아래로 내려가지 않는가, 반사율이 범위를 벗어나지 않는가, 공간적으로 급격한 불연속이 설명되는가. 이것은 정답 없이도 할 수 있는 검증 이고, QA 가 가장 먼저 자동화할 대상이다.
3) 내부 일관성을 검사한다. 같은 산출물 안에서 서로 맞아야 하는 값들이 맞는가. 채널 간 관계, 인접 화소 간 연속성, 품질 플래그와 값의 정합(플래그가 "양호" 인데 값이 비정상이면 둘 중 하나가 틀렸다), 메타데이터와 실제 데이터의 일치 (기록된 관측 시각·영역이 데이터와 맞는가).
4) 알려진 사례로 검사한다. 과거의 특정 사건이 산출물에 나타나는지 본다. 그 사건이 보이지 않으면 처리에 문제가 있을 가능성이 있다. 이 방법은 회귀 시험의 기준 사례(reference case) 로 쓰기 좋다.
QA 가 만들 산출물은 이 네 방법을 레벨별로 배분한 표 다. 레벨 0~1 은 2·3번 중심, 레벨 2 이상은 1·4번이 필요해진다.
품질 플래그가 값보다 중요할 수 있다
위성 산출물에는 보통 각 화소·각 관측에 품질 플래그 가 붙는다. 구름에 가렸다, 센서가 포화됐다, 보정이 불확실하다, 사용하지 말라 같은 정보다.
플래그 검증이 값 검증보다 실무적으로 중요한 경우가 많다. 이유는 사용자가 플래그를 보고 데이터를 걸러 쓰기 때문이다. 플래그가 틀리면 쓸 수 없는 데이터가 연구·업무에 들어가거나, 쓸 수 있는 데이터가 버려진다.
QA 가 플래그에 대해 확인할 것은 셋이다.
- 플래그가 붙는 조건이 문서와 일치하는가 — 구름 판정 임계를 넘었는데 플래그가 없는 화소가 있는가
- 플래그와 값이 모순되지 않는가 — "양호" 플래그에 결측값이 들어 있는가
- 플래그 분포가 그럴듯한가 — 어느 영역의 구름 플래그 비율이 0% 또는 100% 로 나오면 판정 로직을 의심한다
재처리 — 이 분야에서 가장 어려운 검증
알고리즘이 개선되거나 보정 계수가 갱신되면, 과거 데이터 전체를 다시 처리 한다. 이것이 재처리(reprocessing) 다. 그리고 재처리는 QA 가 가장 다루기 어려운 작업이다.
어려운 이유는 "값이 바뀌는 것이 의도된 결과" 이기 때문 이다. 일반 회귀 시험은 "전과 같으면 통과" 다. 재처리는 전과 달라야 하고, 그러면 판정 기준이 사라진다.
그래서 재처리 검증은 "달라진 것이 의도한 것뿐인가" 를 보는 작업으로 바뀐다. 실무 절차는 이렇다.
1) 변경 명세를 먼저 받는다. 무엇을 왜 바꿨고, 어느 레벨·어느 변수·어느 조건에서 값이 달라져야 하는지. 이것이 없으면 검증 기준이 없다. 변경 명세가 없으면 재처리를 검증할 수 없다 는 것을 분명히 말하는 것이 QA 의 일이다.
2) 달라질 곳과 달라지지 않을 곳을 미리 가른다. 명세에서 유도한다. 예: "구름 판정 임계만 바꿨으므로 구름 플래그와 그에 따라 걸러지는 값만 달라지고, 복사 보정 값 자체는 같아야 한다."
3) 달라지지 않을 곳이 같은지 확인한다. 이것이 가장 강한 검증이다. 의도하지 않은 변화는 결함이다. 비트 단위 동일성을 요구할 수 있는지, 부동소수 오차 범위를 허용할지는 미리 정해 둔다.
4) 달라진 곳이 명세대로 달라졌는지 확인한다. 방향(커졌는가 작아졌는가), 크기(명세가 예상한 범위 안인가), 분포(영향받은 화소 비율이 예상과 맞는가).
5) 산출물 버전과 이력을 확인한다. 재처리 결과에는 처리 버전과 사용한 보정 계수·알고리즘 버전 이 메타데이터로 들어가야 한다. 들어가지 않으면 나중에 어느 버전인지 알 수 없고, 서로 다른 버전이 섞여 분석에 쓰인다.
6) 혼용 위험을 점검한다. 재처리 중에는 구버전과 신버전이 동시에 존재한다. 사용자가 섞어 쓰면 결과가 틀린다. 버전 표기, 접근 경로 분리, 공지 절차가 설계되어 있는지 확인한다.
대용량 산출물을 비교하는 방법
한 건이 수 GB 인 파일을 수천 건 비교해야 한다. 눈으로 볼 수 없고, 전체를 메모리에 올릴 수도 없다. 실무에서 쓰는 단계적 방법은 이렇다.
1단계 — 메타데이터만 비교한다. 건수, 파일 크기, 관측 시각·영역, 처리 버전, 변수 목록, 차원 크기. 여기서 걸러지는 문제가 의외로 많다(파일 누락, 영역 어긋남, 변수 누락).
2단계 — 요약 통계를 비교한다. 변수별 최소·최대·평균·표준편차·결측 비율· 플래그별 건수. 전체를 안 읽고도 "크게 달라졌는가" 를 본다. 이 통계를 산출물마다 생성해 저장 해 두면 이후 모든 비교가 빨라진다.
3단계 — 차분의 분포를 본다. 두 버전의 차이를 계산해 분포를 본다. 0 이 아닌 화소의 비율, 차이의 크기 분포, 차이가 몰린 영역. 전체를 보는 대신 차이의 모양 을 본다.
4단계 — 표본을 정해 자세히 본다. 차이가 큰 곳, 경계 조건에 해당하는 곳, 알려진 기준 사례를 의도적으로 골라 값 단위로 확인한다. 무작위 표본보다 설계된 표본 이 훨씬 효과적이다.
5단계 — 시각화로 확인한다. 2차원 격자 데이터는 그림으로 보면 이상이 즉시 드러난다. 줄무늬, 블록 경계, 좌우 반전, 누락 영역은 통계로는 안 보이고 그림으로는 보인다. 다만 시각화는 발견 수단이고 판정 수단으로는 쓰지 않는다 — 판정은 정량 기준으로 한다.
이 5단계는 모듈 61 레슨 2 의 정합성 조회를 대용량 과학 데이터로 확장한 것이다. 기본 발상은 같다 — 결과가 0건(또는 허용 범위) 이면 통과인 판정 가능한 검사 를 쌓는 것.
파이프라인 운영의 결함
데이터 처리 파이프라인에는 알고리즘과 별개로 운영 결함 이 있다. 이쪽은 일반 데이터 엔지니어링 QA 와 겹친다.
- 지연 도착 데이터 — 나중에 도착한 관측이 이미 만든 산출물에 반영되지 않는다
- 중복 처리 — 같은 입력이 두 번 처리되어 산출물이 2개 생긴다
- 부분 실패 — 배치 중간에 실패해 일부만 산출물이 생기고, 그 상태가 "완료" 로 기록된다
- 보조 데이터 버전 어긋남 — 궤도 정보나 보정 계수가 갱신 전 버전으로 쓰인다
- 시각 처리 — 시각 기준계(UTC 와 다른 시간 척도) 와 윤초 처리. 1초 차이가 위치 오차로 번진다. 시각 기준계의 정의와 변환은 미션 문서와 해당 표준에서 확인한다(원문 확인)
- 좌표계·투영 — 좌표 기준계와 투영 정의의 불일치. 화면에는 그려지지만 위치가 어긋난다
QA 가 이 영역에서 만들 것은 파이프라인 단계별 대조 지점 이다. 입력 건수와 출력 건수, 처리 상태와 실제 파일 존재, 사용된 보조 데이터 버전의 기록. 모듈 62 레슨 4 의 대조 지점 발상과 같은 구조다.
실무에서 왜 필요한가
위성·관측 데이터 사업에서 QA 자리는 두 종류로 나온다. 하나는 탑재 소프트웨어 검증 이고(레슨 2~4 의 세계), 다른 하나는 지상 처리 시스템 검증 이다. 후자가 인력 수요가 더 많고, 진입 경로도 넓다 — 데이터 QA 경험이 전이되기 때문이다.
이 분야에서 QA 가 신뢰를 얻는 방식은 알고리즘을 논하는 것이 아니다. 알고리즘은 해당 분야 연구자가 맡는다. QA 가 기여하는 자리는 분명하다.
1) 정답 없이도 할 수 있는 검증을 자동화한다. 물리적 타당성, 내부 일관성, 메타데이터 정합, 플래그 모순. 이것들은 알고리즘을 몰라도 설계할 수 있고, 매 산출물마다 돌아가는 검사 가 되면 사업 전체의 안전망이 된다.
2) 재처리를 검증 가능하게 만든다. "변경 명세 없이는 검증할 수 없습니다" 를 말하고, 명세에서 "달라질 곳 / 달라지지 않을 곳" 표를 만들어 오는 QA 는 연구팀에게 실질적 도움이 된다. 의도하지 않은 변화를 잡아낸 경험 한 번이면 신뢰가 생긴다.
3) 버전 혼용을 막는다. 산출물에 버전이 기록되고, 경로가 분리되고, 공지가 나가는 체계를 요구하는 것은 QA 의 전형적 기여다. 혼용 사고는 한 번 나면 그 기간의 분석 결과 전체를 다시 검토해야 한다.
채용 관점에서는 데이터 QA 와 도메인의 교집합 이 희소하다. SQL·정합성 검증을 할 수 있고(모듈 61), 처리 레벨 체계를 읽을 수 있고, 재처리 검증 절차를 설계할 수 있는 사람은 많지 않다. 공고에는 "위성 영상 처리", "지상국 시스템", "데이터 품질 검증", "검보정" 같은 말이 적힌다.