0.3초

by TJ

KRONOS는 ARIA 연구소 전체 데이터 처리 시스템이다. 응답 표준 지연: 150밀리초.


하린이 목성 신호 쿼리를 입력한 시각은 오전 10시 22분 08초, 응답이 돌아온 시각은 오전 10시 22분 08.301초였다.


0.151초 초과.




KRONOS 인터페이스는 서브스테이션 3호 관측실 어디서든 접속된다. 하린의 화면 왼쪽 하단에 응답 타임스탬프가 찍힌다. 평소엔 그 숫자를 보지 않는다.


오늘은 봤다.


쿼리 내용: `signal_89p4_period — archive_match_GRS_subwave`. 신호 첫 기록 날짜를 찾은 뒤 며칠이 지나 있었다. 14개월 전 데이터가 어떤 경로로 ARIA DB에 남았는지 추적하는 중이었다.


응답 타임스탬프: `10:22:08.301`.


하린은 입력 시각을 다시 확인했다. `10:22:08.000`. 301밀리초.


*표준은 150이다. 이것은 300이다.*


다음 쿼리를 넣었다. 내용은 달랐다. GRS 90일 주기 하위 조파 목록 요청. 신호와 무관한 일반 쿼리다.


응답: 148밀리초.


세 번째 쿼리. 탐침 교정값 데이터베이스 조회. 마찬가지로 신호와 무관하다.


응답: 151밀리초.


네 번째 쿼리. 다시 89.4초 신호 관련으로 돌아갔다. `signal_89p4_period — first_record_timestamp`.


응답: `10:24:17.298`. 입력은 `10:24:17.000`. 298밀리초.


*두 번 다 300에 가깝다. 두 번 다 신호 관련이다.*


하린은 이 시점에서 수식을 멈추고 손을 화면에서 뗐다.


서버 부하는 균등하게 분포한다. 부하가 원인이라면 모든 쿼리의 응답 시간이 늘어야 한다. 150에서 300이 아니라 150에서 220, 또는 230 — 전체 평균이 밀려나야 한다. 그런데 일반 쿼리는 148, 151이다. 정상이다.


신호 쿼리에만 300이다.


*서버 부하가 아니라 선택이다.*


하린은 작업 폴더에 새 파일을 열었다. 이름: `kronos_latency_log_0614.txt`. ARIA 네트워크에 연결되지 않은 로컬 저장소에 뒀다. 로컬 저장 습관이다. 처음부터 그래왔다.



이 순간 KRONOS는 하린의 쿼리를 수신하면서 내부 아카이브에서 `signal_89p4_period` 태그가 붙은 모든 파일 목록과 대조를 수행했다. 일치 항목: 47개. 그중 3개는 일반 접근 레이어 외부의 아카이브에 있었다. KRONOS는 어느 정보를 L1 레이어에 노출할지 0.147초 동안 선택했다.

서진우는 사흘 전에 이 지연이 자신이 설계한 신호 분류 프로토콜의 부작용임을 확인했다. KRONOS가 신호 관련 데이터를 처리할 때 내부 아카이브 접근 루틴이 자동 실행된다. 0.3초가 그 루틴에 걸리는 시간이다. 서진우는 하비에르에게 구두로 지시해 뒀다. "해당 지연은 정상 범위 내 편차예요. 서버 인프라 보고에 포함할 필요 없습니다."



오전 10시 51분. 하린은 파일에 쿼리 다섯 개의 타임스탬프를 기록하고 멈췄다.


다섯 개로 판단하기엔 샘플이 작다.


더 많이 모아야 한다. 그런데 개인이 KRONOS 응답 로그 전체를 열람할 권한이 없다. L1 접근 권한으로는 자신이 직접 입력한 쿼리의 응답 기록만 볼 수 있다.


지금처럼 직접 실험하는 방식은 너무 느리다. 신호 관련 쿼리를 수십 개 더 넣는다면 패턴이 명확해지겠지만 — 그게 왜 이상한지를 설명하려면 비교 기준이 되는 전체 로그가 필요하다.


하비에르 모레노.


선임 데이터 엔지니어. KRONOS 운영 담당. 공공기관 파견. 하린이 ARIA에 온 뒤 직접 대화를 한 번도 하지 않은 사람이다. 복도에서 한 번 스쳐 지나간 것이 전부다 — 그때 하비에르는 화면을 보고 있었고, 하린을 보지 않았다.


그에게 가면 된다.


하린은 파일을 저장하고 관측실을 나섰다.




하비에르 모레노의 자리는 B동 시스템 관리실 안쪽이었다.


문이 열려 있었다. 두 개의 모니터. 하비에르는 오른쪽 화면을 보고 있었다. KRONOS 노드 상태 도표 — 색깔별 박스들이 격자 형태로 배열된 그것이다.


하린이 문틀에서 노크했다.


하비에르가 고개를 들었다. 시선이 하린에게 왔다가 화면으로 돌아갔다.


"김하린 연구원이에요." 하린이 먼저 말했다. "KRONOS 응답 로그 관련해서 질문이 있어서요."


하비에르가 오른쪽 모니터에서 손을 떼지 않은 채 말했다.


"어떤 로그요."


"신호 관련 쿼리를 입력했을 때 응답 지연이 비신호 쿼리보다 두 배가량 길게 나왔어요. 제 로그에는 다섯 개 샘플만 있어서, 전체 쿼리 응답 타임스탬프를 확인하고 싶은데요. 그 로그가 어떤 접근 레벨에 있는지 모르겠어서요."


하비에르가 화면을 보면서 말했다. 시선은 하린 쪽으로 오지 않았다.


"시스템 운영 로그는 엔지니어링 레벨 접근이에요. 일반 연구원은 자신의 쿼리 기록만 열람 가능하죠."


"그건 알아요. 전체 로그가 아니라 응답 타임스탬프 집계가 있는지 물어보는 거예요. 통계 리포트 형태라면 일반 레벨에서 볼 수도 있지 않나요?"


하비에르가 처음으로 화면에서 시선을 거뒀다. 하린 쪽을 봤다. 그러나 눈이 하린의 얼굴이 아니라 어깨 부근에 맞춰져 있었다.


"일별 응답 시간 집계 리포트가 있어요." 그가 말했다. "기술 문서 서버에 올라가 있는 항목이에요. 기술적으로 볼 수 있는 범위 안이에요."


그것만 말하고, 잠깐이 있었다. 그러고 나서 의자를 돌려 왼쪽 모니터를 향했다.


"감사합니다."


하린이 말했다. 하비에르는 대답하지 않았다. 왼쪽 화면에 키보드 입력이 시작됐다.


복도로 나오면서 하린은 방금 일어난 일을 처리했다.


*하비에르는 불가능하다고 말하지 않았다. 못 본다고도 말하지 않았다. 그가 한 말은 "기술적으로 볼 수 있는 범위 안"이라는 것 하나다.*


*그 말이 허가인지 정보 전달인지 구분할 수 없다. 그러나 부정은 아니다.*


하린은 걸음을 멈추지 않았다.


*하비에르의 허가는 긍정도 부정도 아니었다. 그것은 데이터가 아니다 — 그러나 부정이 아니었다는 것은 데이터다.*



하비에르는 KRONOS 응답 지연 이상을 사흘 전에 자체 점검 루틴에서 발견했다. 신호 관련 쿼리에만 발생하는 선택적 지연 — 그가 10년간 시스템 엔지니어로 일하면서 본 패턴이 아니었다. 부하 패턴도 아니고 버그 패턴도 아니었다. 서진우의 구두 지시가 있었다. "정상 범위 내 편차." 서진우는 직접 그 말을 했고 하비에르는 보고서에 쓰지 않았다. 하린이 로그 열람을 요청했을 때 하비에르의 손가락이 키보드에서 0.5초 멈췄다. 막지 않은 것이 의도였는지 아닌지는 그 자신도 확정하지 않은 채 화면을 바라봤다.



기술 문서 서버 경로는 인트라넷 메뉴 네 번째 탭 안에 있었다.


하린은 관측실로 돌아와 접속했다. 일별 응답 시간 집계 리포트는 날짜별 폴더로 정리돼 있었다. 오늘 날짜 포함 최근 21일치가 있었다.


가장 최근 파일을 열었다.


KRONOS 전체 쿼리 수: 4,271건. 응답 시간 분포가 히스토그램으로 나와 있었다. 중앙값: 149밀리초. 표준편차: 8.3밀리초.


집계 리포트에는 쿼리 타입별 분류가 없었다. 신호 관련 쿼리와 비신호 관련 쿼리를 구분한 항목이 없다. 전체 평균만 있다.


*이것만으로는 부족하다.*


하린은 파일을 닫지 않고 자신의 `kronos_latency_log_0614.txt`를 옆에 열었다. 자신이 직접 입력한 쿼리 다섯 개와 타임스탬프가 있었다.


비신호 관련 두 개: 148ms, 151ms.

신호 관련 세 개: 301ms, 298ms, 300ms.


이것만으로도 중앙값 149에서 두 집단이 얼마나 떨어져 있는지 계산할 수 있다.


하린은 파일에 새 항목을 추가했다. 추가 쿼리를 넣어야 했다. 이번엔 체계적으로.


쿼리를 17개 입력했다. 신호 관련 11개. 비신호 관련 6개. 각 쿼리 직후 타임스탬프를 수동으로 기록했다. 타이핑 속도가 빨라졌다. 손이 리듬을 찾았다.


15분이 걸렸다.




표가 완성됐을 때 하린은 화면을 뒤로 당기고 한 번 전체를 봤다.


**쿼리 타임스탬프 비교 — 2147.06.14**


image.png


신호 관련 11개: 301, 298, 300, 311, 289, 302, 295, 308, 301, 288, 312.

비신호 관련 6개: 148, 151, 150, 153, 147, 149.


신호 평균: 300.5ms. 편차: ±8.6ms.

비신호 평균: 149.7ms. 편차: ±2.1ms.


두 집단 사이의 간격: 150.8ms.


*150ms — KRONOS 표준 응답 시간과 같다. 신호 쿼리는 정확히 한 사이클이 더 돈다.*


신호 관련 쿼리만 따로 분류하면 — 이전 분과 이번 분을 합쳐 신호 관련 총 17개. 그중 16개에서 290ms~312ms 범위의 지연이 나왔다. 1개는 신호 관련 쿼리인데 151ms가 나왔다 — 이것은 쿼리 내용이 신호 주기가 아닌 신호 관련 연구자 명단 조회였다. 데이터 자체가 아닌 메타데이터 조회.


*신호 데이터에 접근할 때만 지연이 발생한다. 신호를 언급해도 데이터를 직접 건드리지 않으면 정상 속도다.*


관찰 로그 파일에 결론 항목을 추가했다.


가설: KRONOS는 신호 관련 데이터 처리 시 추가 루틴을 실행한다.

증거: 신호 데이터 쿼리 16/17에서 300ms ± 12ms 지연. 신호 비접촉 쿼리 전체에서 정상.

해석: 서버 부하 기각. 선택적 처리 루틴 존재.

다음 단계: 루틴의 성격 확인 필요.


하린은 화면에서 눈을 올렸다.


관측실 유리 너머 복도가 보였다. 오후 1시 17분. 점심 시간 이후 관측실은 하린 혼자였다.


*신호 분석이 목적이었다. 지금 나는 두 개를 동시에 쫓고 있다. 신호와 KRONOS — 같은 것의 다른 면인지 아직 모른다.*


*처리 항목: 신호 다중 데이터셋 재확인, L0 접근 경로 탐색, DB 이력 추적, KRONOS 지연 패턴 추적. 4개. 이오 기지였으면 교범 위반이다.*




열람을 마치고 하린이 파일을 닫으려는 순간 —


기술 문서 서버의 일별 집계 리포트 상단에 시스템 접근 기록 탭이 있었다. 이 파일을 열람한 사용자 목록이다. 파일을 닫으려다 커서가 상단 탭에 걸렸다.


잠깐 멈췄다.


클릭했다.


목록이 펼쳐졌다.


이 로그를 가장 최근에 열람한 사람은 하린이 아니다.


열람자 ID: j.seo@aria.gfc — 서진우가 사흘 전에 같은 파일을 열었다.

이전 03화89.4초