KAIROS

왜 이렇게 설계했나

1. 01비행마다 몇 대가 일하고 있는지 말한다 — 기체가 도착할 때마다 "0/2"가 채워지고 순찰 범위도 0 %에서 시작한다. 출격을 순찰로 착각하지 않는다.
2. 02가는 길이 그려진다 — 이동 중인 기체는 자기 구역까지의 갈 길을 보여 준다. 계획이지 날아온 길이 아니라서 점선이다.
3. 03갑판 위에서는 에너지를 쓰지 않는다 — 이륙한 순간부터만 소모하고, 완충 상태로 이륙한다.

왜 이렇게 설계했나

1. 01위급은 마감과 해로운 기본값이 함께 있을 때만 — 첫 버전은 마감만 있으면 올렸고 모의 한 시간에 인터럽트가 27번 나왔다. 규칙을 좁히자 같은 한 시간에 세 번이 됐다.
2. 02인터럽트는 한 번에 하나 — 빨간 배너에는 가장 급한 결정만 둔다. 다른 위급은 배너 뒤 목록으로 가고, 위에 쌓이지 않는다.
3. 03큰 카운트다운은 한 곳에만 — 배너에만 크게 두고, 목록 행과 결정 도크에서는 작게 반복한다. 눈이 읽을 시계는 하나다.
4. 04결정 탭은 한 화면에 — 상황, 아무도 결정하지 않으면 생기는 일, AI의 제안, 선택지가 1440×900에서 스크롤 없이 들어간다. 처음에는 1,658 px였다.

왜 이렇게 설계했나

1. 01제안은 승인된 것으로 보이지 않는다 — 카드는 "not executed"를 글자로 말한다. 진한 초록 채움은 승인된 행동에만 쓴다.
2. 02추론은 글자로 말한다 — "inferred", 이탤릭, 보라. 예전의 사선 빗금은 잡음으로 읽혔고 스크린 리더에는 아무것도 전하지 않았다.
3. 03반대 근거는 펼치지 않아도 보인다 — AI와 반대되는 한 줄(옆 기체는 항법이 정상)은 아무것도 열지 않아도 보인다.
4. 04셀마다 관계를 단어로 — + supports, − conflicts, ? missing. 기호만 있으면 "값이 높다"로 읽혔다. 값은 행에 한 번만 둔다.
5. 05근거를 열었는지 기록한다 — 감사 기록에 운용자가 결정 전에 근거를 봤는지, 얼마나 봤는지 남는다.

왜 이렇게 설계했나

1. 01AI가 틀릴 수 있어야 한다 — 그렇지 않으면 콘솔은 사람에게 승인 버튼 누르는 법만 가르친다. 숨은 진실은 실행마다 기록되고, 실행 중에는 절대 보이지 않는다.
2. 02데모는 결과까지 보여 준다 — 디브리핑이 반대한 근거, 실제 진실, 디자인 시스템이 단계마다 한 일을 알려 준다.
3. 03사용자 테스트가 재는 것이 이것이다 — 본 시행의 절반은 AI가 틀린다. 반대 근거 한 줄을 제때 읽는지가 질문이다.

왜 이렇게 설계했나

1. 01권한은 결과의 무게에 따라 — L1은 되돌릴 수 있는 것, L2는 경로가 바뀌는 것, L3는 임무가 끝나는 것. 등급은 고르기 전부터 모든 선택지에 적혀 있다.
2. 02미리보기 없이는 승인할 수 없다 — 승인 버튼은 예상 결과를 본 다음에만 생긴다. 기본값은 AI의 제안이 아니라 언제나 안전한 쪽이다.
3. 03거부되면 운용자에게 돌아온다 — Mission Lead의 사유와 함께, 결정은 다시 열린다. 몰래 다시 시도하지 않는다.
4. 04긴급 단독 권한은 시간이 모자랄 때만 — 남은 시간이 Mission Lead의 평소 응답 시간보다 짧을 때 나타나고, 그 결정은 사후 검토 대상으로 표시된다.

왜 이렇게 설계했나

1. 01감사 기록은 화면이 아니라 계약이다 — 엔진에서 상태 변화와 기록은 하나의 동작이다. 기록 없이 결정을 바꾸는 코드 경로는 없다.
2. 02승인마다 그때 알던 것을 남긴다 — 미리보기를 봤는지, 근거를 열었는지, AI의 확신도와 근거 개수, 남은 시간, 걸린 시간.
3. 03사람은 역할과 ID로 부른다 — OPR-4417, MCL-0921, SYS-KAIROS. "당신"이라고 쓰지 않는다.
4. 04이유는 결정 뒤에 묻는다 — 한 번 누르면 되고 선택이다. 건너뛴 것도 기록된다. 임무를 끝내는 결정(L3)만 사유를 먼저 받는다.

왜 이렇게 설계했나

1. 01시스템이 이미 움직였으면 안전한 쪽이 주 버튼이다 — "Let the return stand"가 큰 버튼이고, 계속 비행은 미리 봐야 하는 대안이다.
2. 02기본값이 안전하면 위급이 아니다 — 아무것도 안 해도 괜찮으니 카운트다운이 붙은 경고로 두고, 빨간 배너를 차지하지 않는다.
3. 03대기열은 자기 규칙을 보여 준다 — 남은 비행 시간이 적은 기체부터 내리고, 기다리는 기체마다 갑판에 내렸을 때 남을 시간을 보여 준다.
4. 04비행의 담당 구역도 결정이다 — 한 대가 돌아가면 AI가 짝 기체가 두 구역을 함께 맡는 방법을, 순찰 범위로 치르는 대가와 함께 제안한다.

왜 이렇게 설계했나

1. 01콘솔은 본 것이 아니라 예상하는 것을 말한다 — "lost-link procedure expected (hold, then return)"는 예측이고, 상태는 Offline이다.
2. 02표지는 마지막으로 확인한 위치가 된다 — 속이 빈 표지에 "last" 표시, 연락이 없는 동안 커지는 불확실성 원.
3. 03링크 상실 대기 지점은 미리 정한 공역이다 — 모든 기체가 문제가 생기기 전부터 대기 지점을 갖고 있고, 지도의 공역 구역 중 하나다.
4. 04비행의 담당 구역은 결정이다 — 짝 기체가 두 구역을 맡거나(L2) 빈 곳을 받아들이거나(L1), 순찰 범위로 치르는 대가와 함께.

왜 이렇게 설계했나

1. 01잃은 기체도 여전히 객체다 — ID와 목록 행과 지도 표지를 그대로 갖고, 상태만 Lost로 바뀐다.
2. 02부분마다 어떻게 아는지 말한다 — 마지막 텔레메트리는 관측(시각과 함께), 회수 구역은 파생(표류에 따라 커짐), 추정 원인은 추론(다른 가능성과 함께).
3. 03원인은 단정하지 않고 따진다 — 하강 전의 모터 전류 이상, 마지막 프레임의 충격 하중, 모델보다 큰 소모. 보고서마다 근거와 다른 가능성을 보여 준다.
4. 04알 수 없는 것도 적고, 경우마다 다르다 — 떠 있는지, 무엇과 부딪혔는지, 배터리 상태. 빼 버리면 "다른 건 상관없다"로 읽힌다.
5. 05확인은 두 번이 아니라 한 번 — 보고서를 확인하면 그 경보도 확인된다. 비행의 담당 구역 결정은 따로 따라온다.

왜 이렇게 설계했나

1. 01물에 사람이 있으니 위급이다 — 임무 배정 시간은 마감이고, 아무것도 안 하면 해로운 결과가 남으니 배너를 차지한다.
2. 02모든 선택지에 대가가 보인다 — 수색에 걸리는 시간과 순찰 범위가 얼마로 떨어지는지, 결정하지 않는 경우의 행까지.
3. 03승인하면 수색이 객체가 된다 — 자기 건(case)으로 생기고, 수색한 면적 비율과 맡은 기체가 보인다.

왜 이렇게 설계했나

1. 01정체는 추론이고 그렇게 보인다 — 이탤릭, 보라, 물음표, 근거 개수. AIS로 스스로 보고하는 배는 관측으로 보인다.
2. 02모든 행동은 우리 비행체를 움직인다 — 거리를 두고 보러 보내기, 계속 추적, 상부 보고, 무시. 배에 무언가를 하는 행동은 없다.
3. 03아군·적군 표시는 없다 — 접촉물은 민간 선박이고, 시스템 어디에도 피아 식별 기호가 없다.

왜 이렇게 설계했나

1. 01주의는 예산이다 — 화면에 인터럽트는 최대 하나, 주의 항목은 최대 셋. 넘치면 하나를 더 띄우지 않고 묶는다.
2. 02나머지는 숨기지 않고 순서를 매긴다 — 주의 단계는 목록에서 조용히 있고, 비행은 접혀서 중요한 하나가 보인다.
3. 03바라는 게 아니라 검사한다 — 모든 시나리오에서 아무도 결정하지 않는 모의 40분 동안 예산을 넘지 않는다.

왜 이렇게 설계했나

1. 01심각도 넷, 색 넷 — 알림 청록, 주의 노랑, 경고 주황, 위급 빨강, 꽉 찬 모양. 둘이 같아지면 빌드가 실패한다.
2. 02검사는 빌드마다 돈다 — 글자 대비 4.5:1 이상, 스타일시트에 날 색상 값이나 px 반경 금지.
3. 03원본 하나, 플랫폼 둘 — 같은 토큰으로 CSS 변수와 QML 테마를 만든다.