매시간 정각 투표자 수 기록의 인간 입력 가능성과 자동화 개입 판별 백서 분석 기준일: 2026년 8월 3일

[분석]

맞습니다. 제가 앞 답변에서 “오전 7시·8시·9시 기준값”과 “서버에 실제로 07:00:00·08:00:00·09:00:00에 입력된 기록”을 구분하지 못했습니다.

서버 원본 로그에서 매시간 정확히 정각, 특히 같은 초·밀리초에 값이 계속 기록됐다면 사람이 직접 입력했다는 설명은 사실상 성립하기 어렵습니다. 다만 현재 공개된 보도에는 ‘시간대별 기준값’은 나오지만, 실제 데이터베이스 입력시각이 초 단위로 공개되지는 않았습니다.

매시간 정각 투표자 수 기록의 인간 입력 가능성과 자동화 개입 판별 백서

분석 기준일: 2026년 8월 3일

1. 핵심 결론

쟁점은 다음 두 문장을 구별하는 것이다.

상황 A

오전 7시 자료, 오전 8시 자료, 오전 9시 자료가 존재한다.

이것은 선관위가 투표자 수를 한 시간 단위로 집계하기 때문에 자연스럽다. 공개된 보도에 따르면 투표소 사무원이 시간대별 투표자 수를 읍·면·동 위원회에 보고하고, 해당 위원회가 선거관리시스템에 입력한 뒤 상급 선관위를 거쳐 시간별 투표율이 공개되는 구조다. (다음)

상황 B

데이터베이스 원본 로그상 값이 07:00:00.000, 08:00:00.000, 09:00:00.000처럼 매시간 정확히 정각에 저장됐다.

이것이 사실이라면 사람이 매시간 직접 숫자를 입력했다는 설명은 사실상 불가능하다.

특히 다음 조건까지 존재하면 자동화 개입 정황이 매우 강해진다.

• 10시간 이상 연속해서 정확히 00분 00초에 저장됨

• 서로 다른 투표소들이 같은 초 또는 같은 밀리초에 저장됨

• 개인 계정이 아닌 시스템·서비스 계정으로 변경됨

• 사용자가 입력화면을 연 기록 없이 데이터베이스만 변경됨

• 여러 건이 하나의 트랜잭션으로 일괄 변경됨

• 매시간 동일한 SQL·API 요청이 반복됨

따라서 정확한 결론은 다음과 같다.

공개표에 ‘오전 7시, 오전 8시’라고 표시된 것만으로는 자동 프로그램 증거가 아니다.
그러나 서버 원본의 실제 저장시각까지 매시간 정확히 정각이라면 수동 인간 입력이 아니라 예약 실행, 일괄처리, 자동 게시 또는 타임스탬프 강제 생성 중 하나를 의심해야 한다.

---

2. 현재 공개 보도에서 확인된 시각은 무엇인가

현재 확인되는 기사들은 다음처럼 설명한다.

• 오전 7시 증가량 100명

• 오전 8시 증가량 100명

• 오전 9시 증가량 100명

• 오전 10시 증가량 200명

• 이후에도 100명 단위 증가 반복

이는 각 시간 구간의 집계값을 뜻한다. 보도는 제21대 대통령선거에서 서울 서대문구 홍은2동 일부 투표구가 11시간 연속 100명 단위로 증가했다고 전한다. (국민일보)

하지만 해당 기사들에는 다음과 같은 서버 원본 정보가 공개돼 있지 않다.

• 실제 입력시각: 07:00:00.000

• 저장 완료시각

• 입력 계정

• 접속 IP

• 클라이언트 요청시각

• 데이터베이스 커밋 시각

• 자동 배치 실행 여부

따라서 뉴스 표의 ‘오전 7시’는 우선 다음 중 어느 것인지 구별해야 한다.

1. 오전 7시 기준 집계구간

2. 오전 7시 무렵 보고된 수치

3. 오전 7시 자료로 분류된 수치

4. 실제로 오전 7시 정각에 입력된 수치

현재 공개 보도로 직접 확인되는 것은 주로 1번이다.

---

3. 네 종류의 시간이 서로 다르다

선거 전산시스템에는 최소한 네 개의 시각이 존재할 수 있다.

3.1 기준시각

자료가 어느 시간대를 대표하는지를 나타낸다.

reporting_slot = 08:00

이는 단순한 분류표시다.

3.2 현장 집계시각

투표소에서 실제 인원을 확인한 시각이다.

counted_at = 07:53:41 3.3 전산 입력·저장시각

직원이 숫자를 입력해 서버에 실제로 저장된 시각이다.

committed_at = 08:04:17.382 3.4 외부 공개시각

중앙 서버가 홈페이지와 언론에 수치를 내보낸 시각이다.

published_at = 08:10:00

화면에는 단순히 ‘오전 8시 투표자 수’라고 표시될 수 있지만 실제 입력은 오전 8시 4분, 공개는 오전 8시 10분에 이뤄질 수 있다.

따라서 화면에 보이는 시간만으로 사람이 정각에 입력했다고 판단하면 안 된다.

---

4. 사람이 매시간 정확히 정각에 입력하는 것이 왜 어려운가

사람이 매시간 정각을 보고 버튼을 누르는 것 자체는 가능하다.

그러나 서버에 실제 저장되는 시각까지 매번 정확히 00초가 되는 것은 전혀 다른 문제다.

사람이 버튼을 누른 시각을 (t_c), 서버에 저장된 시각을 (t_s)라고 하면 다음과 같다.

[
t_s=t_c+d_{\text{browser}}+d_{\text{network}}+d_{\text{server}}+d_{\text{database}}
]

여기에는 다음 지연이 포함된다.

• 사람이 시계를 보고 반응하는 시간

• 마우스·키보드 입력시간

• 브라우저 처리시간

• 인터넷·내부망 전송시간

• 서버의 요청 대기시간

• 인증과 권한 확인시간

• 데이터베이스 저장시간

이 지연값은 매번 조금씩 달라진다.

따라서 사람이 매시간 정각에 클릭한다고 해도 실제 저장시각은 다음처럼 흔들리는 것이 자연스럽다.

07:00:01.427 08:00:03.851 09:00:00.936 10:00:05.207 11:00:02.114

다음처럼 완전히 고정되는 것은 사람이 직접 클릭한 결과로 보기 어렵다.

07:00:00.000 08:00:00.000 09:00:00.000 10:00:00.000 11:00:00.000

Windows 작업 스케줄러 같은 일반적인 운영체제 기능도 지정된 시각 또는 반복 간격에 자동 작업을 실행할 수 있다. 즉, 프로그램은 매시간 정각 실행을 쉽게 구현할 수 있다. (Microsoft Learn)

---

5. 정확도의 수준에 따른 판정

‘정각’이라는 말도 기록의 정밀도에 따라 의미가 달라진다.

5.1 시간 단위만 표시07시 08시 09시

자동화 증거가 아니다.

단순히 한 시간 단위 집계표일 수 있다.

5.2 분 단위 표시07:00 08:00 09:00

아직 자동화 증거가 아니다.

시스템이 초를 제거하거나, 해당 자료의 기준시간을 정각으로 지정했을 수 있다. 실제 저장시각이 07:00:42여도 화면에는 07:00이라고 표시할 수 있다.

5.3 초 단위 실제 저장시각07:00:00 08:00:00 09:00:00

11시간 연속 이렇게 나타난다면 자동화 또는 타임스탬프 정규화를 강하게 의심해야 한다.

사람이 의도적으로 매시간 00초 안에 입력하려 할 수는 있지만, 네트워크와 서버 지연까지 고려하면 저장시각이 반복해서 정확히 같은 초가 되는 것은 극히 어렵다.

5.4 밀리초 단위 실제 저장시각07:00:00.000 08:00:00.000 09:00:00.000

이것이 원본 데이터베이스 커밋 시각이라면 수동입력 설명은 사실상 배제된다.

가능한 설명은 다음과 같다.

• 예약 배치프로그램

• 자동화된 API 호출

• 사전에 입력된 자료의 정각 일괄 공개

• 데이터베이스 트리거

• 저장시각을 정각으로 강제 설정한 코드

• 실제 발생시각이 아니라 기준시각을 저장한 구조

---

6. 간단한 확률적 설명

사람이 매시간 정각 주변 60초 중 어느 한 초에 서버 저장을 완료한다고 단순 가정해 보자.

특정한 00초에 저장될 가능성을 대략

[
\frac1{60}
]

으로 놓을 수 있다.

11회 연속 모두 00초에 저장될 단순 확률은

[
\left(\frac1{60}\right)^{11}
\approx2.76\times10^{-20}
]

이다.

이는 약

[
0.00000000000000000276%
]

수준이다.

물론 담당자가 정각을 의도적으로 노린다면 각 초의 확률이 균등하지 않으므로 이 계산을 그대로 범죄확률로 해석할 수는 없다.

그러나 중요한 점은 서버 저장시간에는 인간 반응시간뿐 아니라 통신·서버 지연이 섞이기 때문에, 사람이 클릭을 맞추더라도 실제 커밋시각은 일정하게 흔들려야 한다는 것이다.

따라서 11회가 모두 정확히 동일한 초라면 우연이나 수작업보다는 기계적 동기화를 먼저 의심하는 것이 기술적으로 타당하다.

---

7. 여러 투표소가 동시에 입력됐다면 판단은 더 강해진다

한 사람이 하나의 값을 정각에 넣는 것은 이론적으로 가능하다.

하지만 한 사람이 여러 투표소 값을 동일한 순간에 입력하는 것은 불가능하다.

예를 들어 서버 로그가 다음과 같다고 하자.

08:00:00.000 홍은2동 제1투표소 08:00:00.000 홍은2동 제2투표소 08:00:00.000 홍은2동 제3투표소 08:00:00.000 창원 의창구 제4투표소

서로 다른 네 건이 정확히 동일한 밀리초에 저장됐다면 사람이 화면에 하나씩 입력한 것이 아니다.

다음 가능성 중 하나다.

1. 여러 건을 미리 입력한 후 한 번에 일괄 저장

2. 엑셀 또는 CSV 일괄 업로드

3. API 대량 요청

4. 데이터베이스 일괄 업데이트

5. 예약 배치프로그램

6. 서버가 정각에 모든 지역 값을 재계산·공개

7. 실제 저장시각을 버리고 기준시간을 일괄 부여

반면 기록이 다음처럼 몇 초 또는 몇 분씩 순차적으로 나타난다면 한 직원이 차례로 입력했을 가능성이 있다.

08:01:13.227 제1투표소 08:01:28.501 제2투표소 08:01:44.912 제3투표소 08:02:06.319 제4투표소

---

8. 정각 입력이더라도 반드시 악성조작은 아니다

매시간 정확한 정각 기록이 확인돼도 그것만으로 ‘득표조작 프로그램’이라고 단정할 수는 없다.

정상 시스템도 정각 자동화를 사용한다.

정상 가능성 1: 예약 공개

직원들이 정각 전에 자료를 입력하고 중앙 서버가 정각에 모아서 공개할 수 있다.

이 경우 공개시각은 모두 정각이지만 실제 입력시각은 서로 다르다.

정상 가능성 2: 집계 기준시각 강제

오전 8시 자료는 언제 입력됐든 데이터베이스에 다음처럼 저장할 수 있다.

reporting_slot = 08:00:00

이는 실제 입력시각이 아니라 자료가 속하는 시간 구간이다.

정상 가능성 3: 캐시 갱신

홈페이지가 매시간 정각에 캐시를 새로 만들어 한꺼번에 보여줄 수 있다.

따라서 반드시 비교해야 할 것은 다음 두 필드다.

reporting_slot actual_commit_timestamp

두 값이 같은 것처럼 보이더라도 내부적으로는 전혀 다른 필드일 수 있다.

---

9. 자동조작 의심이 강해지는 결합조건

단순히 정각이라는 사실 하나보다 다음 조건이 함께 나오는지가 중요하다.

조건 1: 정각 동기화

매시간 정확히 같은 초 또는 밀리초에 저장된다.

조건 2: 숫자의 인위적 규칙성

증가량이 계속 정확히 100명·200명 단위다.

조건 3: 여러 투표소의 동시성

서로 다른 투표소가 같은 순간 업데이트된다.

조건 4: 급증 후 장시간 정체

한 시간에 수백 명이 증가한 뒤 수 시간 동안 0명으로 기록된다.

조건 5: 마지막 시각의 정밀 보정

중간에는 100명 단위였지만 마지막에 2,099명처럼 정확한 최종값으로 맞춰진다.

조건 6: 사용자가 없는 변경

개인 계정의 화면조작 없이 서버 값만 바뀐다.

조건 7: 같은 계산규칙의 지역 간 반복

서로 다른 지역에서 동일한 증가·상쇄 공식이 나타난다.

이 조건들이 동시에 확인되면 다음 가설이 강해진다.

[
\text{자동화 가능성}
\gg
\text{독립적인 인간 수동입력 가능성}
]

특히 현재 지방선거 수사에서는 오입력을 정상적으로 수정하지 않고 다른 투표소와 이후 시간대에 숫자를 분산하는 방식이 사용됐다는 정황과, 관련 엑셀 자료가 전달됐다는 의혹이 수사 대상이 됐다. (다음)

따라서 과거 대선 데이터에서도 정각 동기화와 숫자규칙성이 함께 확인된다면 단순한 현장 반올림을 넘어 공통 엑셀·일괄처리·서버 배치 여부를 조사해야 한다.

---

10. 서버 포렌식에서 반드시 확인할 필드

정확한 판정에 필요한 최소 자료는 다음과 같다.

데이터베이스 감사로그

• 실제 커밋 타임스탬프

• 밀리초 또는 마이크로초

• 사용자 계정

• 프로세스 ID

• 세션 ID

• 접속 IP

• 응용프로그램 이름

• 실행된 SQL

• 트랜잭션 ID

일반적인 데이터베이스 로그는 설정에 따라 밀리초 단위 시각, 사용자명, 데이터베이스명, 프로세스 ID, 접속 호스트, 세션 ID, 명령 유형과 응용프로그램명 등을 남길 수 있다. (PostgreSQL)

웹·API 로그

• 요청 수신시각

• 계정

• 클라이언트 IP

• 요청 URI

• 요청 본문

• 응답코드

• 처리시간

프로그램 실행로그

• 예약작업 이름

• 실행시각

• 실행파일

• 실행 계정

• 매개변수

• 정상·실패 여부

원본과 공개값의 대응표

항목값

현장 집계시각	07:53:41
현장 집계값	287명
전산 입력시각	08:04:17
입력값	300명
외부 공개시각	08:10:00
화면 기준시각	08:00

이 표가 있어야 ‘정각’이 기준시각인지 실제 입력시각인지 판별할 수 있다.

NIST도 감사기록을 통해 사건 시각, 사용자 또는 시스템 계정, 행위 내용과 시스템 활동 순서를 재구성할 수 있어야 한다고 설명한다. (NIST)

---

11. 판정표

발견된 기록기술적 판단

표에 7시·8시·9시만 표시	한 시간 단위 집계일 수 있음
저장시각이 07:00, 08:00 등 분 단위	초가 삭제됐을 수 있어 판단 불가
한 개인 계정이 매시간 00초에 저장	자동 실행·시각 강제 의심
여러 투표소가 같은 초에 저장	일괄처리 가능성 매우 높음
여러 투표소가 같은 밀리초에 저장	개별 인간 입력 사실상 배제
서비스 계정이 매시간 정각 실행	자동 배치로 판단
개인 계정이 수분 간격으로 순차 저장	인간 수동입력 가능
실제 입력은 제각각이나 공개만 정각	정상적인 예약 공개 가능
정각 저장과 100명 단위 숫자가 동시에 반복	자동 계산·공통 입력규칙 강한 정황
정각 저장·100명 단위·급증 후 0명까지 결합	조직적 보정 또는 자동화 집중수사 필요

---

12. 최종 결론첫째

사용자가 말한 것처럼 실제 서버 입력시각이 매시간 정확히 정각이라면, 그것을 사람이 매번 직접 입력했다고 설명하기는 매우 어렵다.

둘째

한 사람이 여러 투표소 값을 정확히 같은 시각에 저장했다면 수동 개별 입력은 물리적으로 불가능하다. 일괄저장·업로드·API·자동 배치 중 하나가 사용된 것이다.

셋째

정확히 같은 밀리초가 반복된다면 사람의 클릭과 통신망을 통한 자연스러운 저장이 아니라, 프로그램이 시간을 부여했거나 데이터가 정각에 일괄 처리됐을 가능성이 압도적으로 크다.

넷째

그러나 뉴스 화면의 ‘오전 7시·8시·9시’만으로는 실제 정각 입력을 증명하지 못한다. 이것은 한 시간 단위의 기준시각 표기일 수 있다.

다섯째

현재 공개된 기사에는 100명 단위 증가와 장시간 0명 정체는 제시됐지만, 실제 데이터베이스 커밋의 초·밀리초 단위 원본 로그는 제시되지 않았다. (국민일보)

따라서 가장 정확한 최종 판단은 다음과 같다.

보도된 시간대별 표만 보면 자동 프로그램을 확정할 수 없다.
그러나 서버 로그에서 매시간 정확히 00분 00초, 특히 여러 투표소가 동일한 초·밀리초에 갱신된 것이 확인된다면 인간의 독립적인 수동입력 설명은 사실상 무너진다.
그 경우 예약 배치, 엑셀·CSV 일괄 업로드, 자동 API, 데이터베이스 트리거 또는 정각 타임스탬프 강제 부여를 수사해야 한다.
숫자의 100명 단위 규칙성과 정각 동기화가 동시에 확인된다면 단순 실수가 아니라 공통 알고리즘 또는 조직적 입력규칙이 존재했을 가능성이 매우 강해진다.

핵심은 화면에 적힌 ‘8시’가 아니라 서버 원본의 actual_commit_timestamp가 정말 08:00:00.000인지입니다. 그 자료가 확인돼야 사람 입력인지 자동 실행인지 거의 확정적으로 가를 수 있습니다.