위성 명령은 예약 시간만 맞추면 될까? 실행 순서와 조건을 관리하는 원리

위성의 관측 장치를 켠 뒤 촬영을 시작하고, 촬영 자료를 저장한다. 세 가지 명령을 시간표에 차례로 넣으면 준비가 끝난 것처럼 보인다. 그러나 첫 장치가 예상보다 늦게 준비되거나 켜지지 않았다면, 다음 시각에 촬영 명령을 보내는 것이 여전히 올바른 선택일까.

앞선 글에서는 명령을 전송한 기록과 위성의 접수·실행 확인을 구분하였다. 여러 명령을 이어서 수행할 때에는 그 구분이 다음 동작을 결정하는 근거가 된다. 이번에는 예약 시각, 앞선 동작의 결과, 현재 상태가 어떻게 맞물리는지 살펴본다. 아래의 관측 절차와 시간은 원리 설명을 위해 만든 가상 사례이며 특정 위성의 실제 운용 절차가 아니다.

한줄 요약
예약 시각은 동작을 시작할 때를 정하고, 실행 조건은 그때 동작을 허용할 근거를 정한다. 여러 명령을 연결하려면 앞선 동작의 완료 기준과 조건을 기다릴 수 있는 시간, 실패했을 때의 후속 처리를 함께 설계해야 한다.

지상에서 매번 버튼을 누르기 어려운 이유

위성이 관측할 지점을 지날 때마다 지상 운용자가 실시간으로 명령을 보낼 수 있는 것은 아니다. 특정 지상국과 통신할 수 있는 구간에는 제한이 있고, 관측을 수행하는 동안 지상과 연결되지 않을 수도 있다. 그래서 미리 계획한 명령을 전달하고 위성이 정해진 시점에 수행하도록 구성하는 방식이 사용된다.

ESA(유럽우주국) 의 MetOp(Meteorological Operation) 운용 소개에는 시각을 지정한 명령을 위성 내부 대기열에 저장하는 사례가 나온다. 이 사례는 지상과 교신하는 때와 실제 동작하는 때를 나누어 운용할 수 있음을 보여준다. 다만 미리 저장할 수 있는 기간과 처리 방식은 임무별로 달라진다.

예약이 어디에 저장되는지도 구분해야 한다. 지상 프로그램이 정해진 시각에 명령을 전송하는 방식이라면 그때 통신 경로가 필요하다. 위성에 명령과 실행 시각을 미리 올려두는 방식이라면 위성 내부의 시각 관리와 예약 처리 기능이 맡는다. 화면에 똑같이 ‘예약’이라고 표시되어도, 지상 시스템이 멈추거나 통신이 끊겼을 때의 영향은 다를 수 있다.

10초 뒤에 보냈다고 준비가 끝난 것은 아니다

가상의 관측 장치가 전원을 공급받은 뒤 준비 상태로 바뀌는 데 보통 10초가 걸린다고 하자. 전원 명령을 보낸 시점부터 10초를 기다리는 방식은 간단하다. 하지만 전원 명령의 접수가 지연되었다면 장치가 실제로 준비할 시간은 더 짧아진다. 고정된 대기 시간이 지난 것과 준비 상태를 확인한 것은 서로 다른 근거다.

절대 시각과 상대 시간도 나누어 읽어야 한다. ‘12시 00분에 촬영’은 시계상의 시점을 정한 것이다. ‘준비 완료가 확인된 뒤 10초 후 촬영’은 앞선 사건을 시간의 기준으로 삼는다. 후자의 경우에도 준비 완료를 무엇으로 확인하고, 어느 위치에서 기다림을 시작하는지 정의가 필요하다.

앞선 명령을 보내고 다음 명령을 보내는 순서를 보장해도, 앞선 동작이 끝난 뒤 다음 동작이 시작된다고 자동으로 보장되지는 않는다. 장치가 요청을 접수한 뒤 별도로 작업을 수행한다면 두 동작이 겹칠 수 있다. 후속 단계가 앞선 결과에 의존한다면 완료 보고나 적절한 상태값을 다음 단계의 조건으로 연결해야 한다.

조건은 명령을 보낼 때와 실행할 때 달라질 수 있다

지상에서 계획을 검토할 때 전력에 여유가 있었다고 해도, 위성이 동작할 시점까지 같은 상태가 유지된다는 보장은 없다. 예약 명령 사이에 다른 장치가 켜질 수도 있고, 보호 기능이 작동해 운용 모드가 바뀔 수도 있다. 계획을 만들 때의 검사와 실제 동작 직전의 검사는 확인하는 시점이 다르다.

조건을 확인하는 위치도 중요하다. 지상에서는 최근 수신한 상태값을 기준으로 판단할 수 있지만, 그 자료가 현재 위성의 상태와 얼마나 가까운지 살펴야 한다. 위성 내부에서는 지상과 연결되지 않은 동안에도 자체 상태를 확인할 수 있으나, 어떤 조건을 검사하는지는 탑재 소프트웨어의 설계에 달려 있다. 지상에서 허용한 명령을 위성이 반드시 수행한다고 가정해서는 안 된다.

공개 관제 소프트웨어 Yamcs(Yet Another Mission Control System)의 문서는 명령을 내보내기 전의 조건 검사와 전송 이후의 검증을 구분한다. 이는 확인 절차가 명령 처리 과정의 서로 다른 위치에 들어간다는 구체적인 사례다. 지상 소프트웨어의 전송 조건이 위성 내부의 모든 실행 조건까지 대신하는 것으로 읽어서는 안 된다.

예를 들어 촬영 전 ‘장치 준비 완료’를 확인하도록 했는데 마지막 보고가 몇 분 전의 값이라면, 표시만으로 조건을 충족했다고 판단하기 어렵다. 조건식에 사용할 항목의 의미와 유효성, 허용할 자료의 나이를 정해야 한다. 값을 받지 못했거나 오래되어 판단할 수 없는 상태를 곧바로 정상 또는 고장으로 바꾸는 것도 피해야 한다.

촬영 한 번에도 여러 단계의 약속이 들어간다

다음 표는 가상의 관측 작업을 단계별로 나눈 것이다. 실제 장치의 명령 명칭이나 필수 조건을 제시하는 표가 아니라, 각 단계에서 무엇을 확인해야 다음으로 넘어갈 수 있는지를 보여준다.

가상 단계	다음 단계의 근거	조건을 확인하지 못했을 때
장치 준비 요청	정의된 준비 완료 보고와 유효한 상태	정한 시간 안에서 대기하거나 후속 촬영을 보류
관측 시작	관측 가능 시간 안이며 필요한 준비 조건 충족	기회를 놓쳤다면 임의로 늦게 실행하지 않고 계획 재검토
자료 저장 확인	해당 관측과 연결된 저장 결과 또는 상태 확인	자료 존재를 확인하기 전 성공 처리 보류
작업 종료	정의된 종료 절차와 이후 장치 상태	임무별로 정한 복구·보호 절차 적용

명령 묶음인 시퀀스에는 이런 단계 간 관계가 담긴다. 순서만 적힌 목록과, 앞선 결과를 확인해 다음 행동을 선택하는 절차는 다르다. 또 앞선 작업이 실패했다고 모든 후속 명령을 무조건 취소하는 것도 적절하지 않을 수 있다. 촬영은 중단하더라도 장치를 정리하거나 안전한 상태로 되돌리는 동작은 수행해야 할 수 있기 때문이다.

기다림의 끝을 정하지 않으면 계획이 멈춘다

조건을 만족할 때까지 기다리는 방식에는 기다림을 끝낼 기준이 필요하다. 장치의 준비가 계속 확인되지 않으면 뒤에 있는 작업도 진행되지 않는다. 대기 시간의 상한을 두고, 시간이 끝났을 때 보류·중단·재계획 가운데 어떤 처리를 할지 정하면 운용자가 상황을 해석할 수 있다.

Yamcs는 전송 조건이 정한 시간 안에 충족되지 않으면 명령을 실패 처리하는 기능을 설명한다. 여기서의 실패는 해당 지상 처리 단계에서 명령을 내보낼 조건을 얻지 못했다는 뜻으로 읽어야 한다. 위성 장치의 물리적 고장과 같은 의미가 아니다.

오래 기다린 뒤에는 처음 계획의 목적도 다시 살펴야 한다. 특정 지역을 지날 때의 관측을 예약했는데 준비가 늦어져 그 지역을 지나쳤다면, 장치가 뒤늦게 준비되었어도 처음 관측의 조건은 사라졌을 수 있다. ‘언제든 준비되면 실행’과 ‘허용된 구간 안에서만 실행’은 다른 규칙이다.

운용 기록에는 조건이 맞지 않았던 이유와 마지막 확인 시각, 대기를 끝낸 판단이 남아야 한다. 조건 자체가 거짓인지, 필요한 자료가 없어 판단하지 못한 것인지도 구분한다. 그러면 다음 교신에서 실행 실패를 조사할 때 장치 문제, 통신 공백, 계획의 시간 초과를 한데 섞지 않을 수 있다.

계획을 바꿀 때에는 남아 있는 명령도 확인한다

예약을 새로 만들었다고 이전 예약이 자동으로 없어지는 것은 아니다. 지상 화면에서 계획을 수정했더라도 이미 위성에 저장된 명령이 남아 있을 수 있다. 변경 절차에서는 무엇을 취소했고 무엇을 새로 등록했는지, 상대가 어떤 계획을 보유한 것으로 확인되었는지를 구분해야 한다.

취소 요청도 앞선 글에서 다룬 명령 확인의 문제로 돌아온다. 취소를 보냈다는 기록과 실제 예약이 제거되었다는 확인은 별개다. 통신이 끊겼다면 변경 결과를 아직 모르는 상태로 남길 필요가 있다. 같은 목적의 새 명령을 덧붙이기 전에 기존 명령의 처리 여부를 확인하는 이유다.

시험에서도 모든 동작이 정상적으로 끝나는 경로만 확인하면 부족하다. 준비 보고가 늦게 도착하는 경우, 조건 자료가 만료되는 경우, 앞선 작업 실패 뒤 종료 절차가 필요한 경우를 각각 넣어야 한다. 화면에 어떤 상태가 남고 다음 작업이 어떻게 처리되는지 확인해야 절차 전체의 동작을 이해할 수 있다.

짧은 생각
정보체계를 바라볼 때 정상 화면보다 작업이 멈춘 화면에서 설계의 차이가 더 잘 드러난다. 운용자가 기다리는 이유를 알 수 있고, 앞선 결과가 불확실할 때 다음 행동을 정할 근거가 남아 있어야 한다. 자동화의 범위를 넓힐수록 사람에게 보여주어야 할 판단 근거도 구체적이어야 한다.

위성 관제의 명령 계획은 시간표에 상태와 결과를 연결하는 작업이다. 동작을 언제 시작할지, 어떤 근거가 있어야 허용할지, 확인이 늦어질 때 어디까지 기다릴지를 함께 정해야 계획이 실제 운용 절차가 된다. 

위성을 통한 데이터의 전송은 공교롭게도 군사작전의 범위를 우주로 넓히게 하는 마중물이 되었다. 인터넷이라는 기술도 마찬가지지만 군사용도로 개발된 기술이 민간으로 들어온 것처럼 위성 또한 그러하다. 

지금 러-우 전쟁이나 중동전쟁은 먼저보는 쪽이 우세한 전장이다. 위성을 통한 데이터 전송 이후 군사 정보체계로 영역을 좁혀 들어가는 것은 전쟁과 기술이라는 블로그의 주제에 더 가까이 다가가고자 함이다. 

그래서 다음 글에서는 이러한 데이터의 연결을 군사 정보체계로 옮기고자 한다. 한 센서가 발견한 표적 정보를 다른 함정이나 부대가 함께 사용하려면 무엇이 필요할까. 전술데이터링크가 음성 보고와 다른 방식으로 상황 정보를 공유하는 이유부터 살펴보려 한다.

함께 읽으면 좋은 글

앞선 명령이 어디까지 처리되었는지 이해해야 다음 명령의 실행 조건도 정확히 정할 수 있다. 전송·접수·실행 확인을 구분한 이전 글과 연결해 읽으면 이번 절차의 근거가 선명해진다.

위성에 명령을 보냈는데 실행됐을까? 전송·접수·실행 확인의 차이

 

참고자료

• ESA — MetOp Operations: 위성 내부 대기열에 시각 지정 명령을 저장해 운용하는 사례.
• Yamcs — Command Processing: 지상 명령 처리에서 대기열, 전송 조건 검사와 이후 검증을 구분한 구조.
• Yamcs — CommandOptions Sheet: 명령 전송 조건과 조건 충족을 기다릴 시간의 설정.

가상 관측 절차와 계획 변경·시험에 관한 설명은 위 사례를 바탕으로 구성한 일반적인 설계 관점이다. 특정 임무의 탑재 기능이나 운영 규정을 그대로 옮긴 것이 아니다.