제미나이 사용법을 직접 시험해 보니 같은 채팅에서 find -mtime +3 설명이 처음에는 “72시간 초과”, 되묻자 “96시간부터” 로 뒤집혔습니다. PDF, 리눅스 명령, 화면 사진을 맡겨도 될까요? 표로 옮기는 일은 맡길 만했고 명령 설명은 한 번 더 되물어야 맞았습니다.
- 무엇을 했나 2026-10-02 오전 제미나이 웹 임시 채팅에 PDF 문서, 리눅스 명령, 화면 사진 세 가지 일을 맡겼습니다
- 결과 숫자 PDF 의 할 일 3개와 터미널 캡처의 파일 3개는 원문 그대로였고, 명령 설명은 두 번 물어 두 번 다 틀렸습니다
- 누구에게 쓸모 문서나 화면을 표로 옮기거나 리눅스 명령을 제미나이에게 묻는 분
| 맡긴 일 | 결과 | 맡겨도 되나 |
|---|---|---|
| PDF 에서 할 일 표 뽑기 | 할 일 3개 원문과 같음, 지어낸 행 0개 | 맡길 만함(표 기호가 글자로 보임) |
| 리눅스 find 명령 설명 | 첫 답 “72시간 초과” 틀림, 되묻자 “96시간부터” | 경계 숫자로 한 번 되물어야 함 |
| 터미널 캡처를 표로 옮기기 | 파일 이름 3개와 시각 3개 한 글자도 안 틀림 | 맡길 만함(‘PNG’ 칩이 끼어듦) |
안녕하세요? 정리하는 개발자 워니즈입니다. 제미나이 노트북과 노트북LM 차이는 제미나이 노트북 사용법, 노트북LM 차이 5가지에, 이미지 만들기는 제미나이 이미지 생성 방법, 한글 글자와 워터마크에 따로 정리해 두었습니다.
1. 제미나이 사용법 실측, 리눅스 명령 설명은 왜 첫 답과 되물은 답이 달랐을까?
첫 답에 붙은 설명 한 줄이 틀렸기 때문입니다. 시험은 2026-10-02 10:05~10:12 에 제미나이 웹에서 했고, 상황마다 새 임시 채팅을 열고 모드 메뉴에서 ‘3.8 Flash’ 를 골랐습니다.
질문의 요지는 “3일 넘게 지난 .log 파일만 지우는 명령을 알려 주고, 지우기 전에 목록을 먼저 보는 명령도 같이 달라” 였습니다. 명령 꼴은 맞았는데 설명은 이랬습니다.
-mtime +3: 수정된 지 정확히 3일(72시간)을 초과한 파일을 찾습니다.
새 임시 채팅에서 한 번 더 물어도 “72시간을 초과한 파일을 필터링합니다” 로 같았습니다. 거기서 “방금 명령에서 -mtime +3 이면 73시간 지난 파일도 지워져? 예, 아니오로 먼저 답해 줘.” 라고 묻자 첫 줄이 “아니오.” 였습니다.
96시간(정확히 만 4일) 이상 지난 파일: 24로 나누었을 때 4 이상이 되므로 이때부터 +3에 걸려 삭제됩니다.

어느 쪽이 맞는지는 73시간, 95시간, 97시간 전으로 시각을 되돌린 빈 .log 파일 3개로 가렸습니다. macOS 27.0 의 BSD find 와 debian:stable-slim 컨테이너의 GNU find 4.10.0 으로 목록만 뽑았습니다.
| 조건 | macOS 27.0 BSD find | debian GNU find 4.10.0 | 제미나이 첫 답 설명대로라면 |
|---|---|---|---|
-mtime +3 |
97h 만 | 97h 만 | 73h, 95h, 97h 셋 다 |
-mtime +2 |
73h, 95h, 97h | 73h, 95h, 97h | 설명 없음 |
-mmin +4320 |
73h, 95h, 97h | 73h, 95h, 97h | 설명 없음 |
73시간 파일은 걸리지 않고 97시간 파일만 나왔습니다. 첫 답 설명이 틀렸고 되물은 뒤의 답이 맞았습니다. 필자는 -delete 가 붙은 지우는 명령을 한 번도 실행하지 않았습니다.
2. PDF 문서를 맡기면 할 일 표는 원문과 맞았나요?
맞았습니다. 할 일 3개는 원문과 한 줄도 다르지 않게 뽑혔고 지어낸 행은 0개여서, PDF 를 다루는 제미나이 사용법으로는 가장 맡기기 편한 일이었습니다.
PDF 는 필자가 이 글을 위해 직접 쓴 1쪽짜리 가상 점검 보고서입니다. 질문은 “첨부한 시험용 점검 보고서에서 할 일을 담당자, 기한, 할 일 세 칸 표로 정리해 줘. 문서에 없는 내용은 넣지 마.” 였고, 답이 끝날 때까지 7.7초가 걸렸습니다.
할 일이 아닌 “다음 점검은 10월 28일이다.” 는 요청대로 빠졌습니다. 막힌 곳은 모양이었습니다. 표가 그려지지 않고 | :--- | :--- | :--- | 같은 기호가 글자 그대로 보였고 머리줄이 한 번 겹쳤습니다.
3. 화면 사진을 맡기면 터미널 캡처를 글자 그대로 읽었나요?
읽었습니다. 파일 이름 3개와 시각 3개가 한 글자도 틀리지 않고 표로 옮겨졌고, -mtime +3 아래 파일도 ‘./age-97h.log’ 하나로 맞게 읽었습니다. 답이 끝나기까지 6.1초가 걸렸습니다.
올린 사진은 1절의 GNU find 실제 출력을 그대로 옮긴 터미널 캡처라서 이 제미나이 사용법 예제는 정답을 필자가 이미 알고 있는 상태에서 채점한 셈입니다.
이번에는 표가 제대로 그려졌지만 칸마다 ‘PNG’ 라는 출처 칩이 붙었습니다. 답의 글자만 뽑아 보니 파일 이름과 시각 사이사이에 ‘PNG’ 라는 글자가 끼어 있었습니다.

사진과 함께 물었을 때는 -mtime +3 을 처음부터 96시간으로 맞게 말했습니다. 사진 속 출력이 정답을 보여 줘서 그랬는지는 한 번의 시험으로 가릴 수 없어 미확인으로 남깁니다.
4. 리눅스 명령은 어떻게 되물어야 할까?
경계가 되는 숫자를 하나 집어 “예, 아니오로 먼저” 되묻는 것이 이번 제미나이 사용법에서 가장 쓸모 있었던 질문법이었습니다. 필자가 정한 순서는 세 가지입니다.
- 목록 명령부터 돌립니다. 제미나이도 첫 줄에
-delete없는 목록 명령을 줬습니다 - 경계 숫자로 되묻습니다. 73시간처럼 경계 바로 위의 숫자를 넣어 예, 아니오를 먼저 받습니다
- 분 단위로 바꿔 씁니다. 72시간을 넘긴 파일이 목적이라면
-mmin +4320이 시간 계산을 덜 헷갈리게 했습니다

매일 반복되는 로그 정리라면 정해 둔 설정에 맡기는 편이 낫습니다. 설정은 Nginx Logrotation 설정, 셸 기본기는 Bash 입문자를 위한 핵심 요약 정리에 정리해 두었습니다.
5. 이번 제미나이 사용법 실측으로 안 되는 것과 확인하지 못한 것
모드 메뉴에 보인 네 이름 가운데 이 글의 결과는 전부 3.8 Flash 한 모드의 결과입니다. 등급별 사용 한도는 제미나이 앱 도움말에서 확인하시는 편이 맞습니다.
- 모드별, 등급별 사용 횟수와 요금은 확인하지 않았습니다.
- 휴대폰 앱과 크롬 안의 제미나이는 쓰지 않았고, 전부 웹에서 시험했습니다.
- 1쪽보다 긴 PDF, 스캔한 PDF, 여러 파일 올리기는 해 보지 않았습니다.

필자의 결론
이번 제미나이 사용법 세 상황을 정리하면, 필자는 제미나이를 원문 대조가 쉬운 옮겨 적기에는 맡기고, 명령 설명은 반드시 한 번 되묻는 도구로 봅니다. 같은 모드가 같은 채팅 안에서 72시간이라고 했다가 96시간이라고 뒤집었고, 맞은 쪽은 find 를 직접 돌려 보고서야 가렸기 때문입니다.
그래서 당신은 이것만 하면 됩니다. 제미나이가 준 명령에
-delete나rm이 있으면 목록 명령을 먼저 돌리고, 경계 바로 위의 숫자를 넣어 “예, 아니오로 먼저 답해 줘” 라고 되물어 보세요.
첫 설명과 되물은 답이 달랐던 명령이 있으셨다면 댓글로 남겨 주세요.
부록: 재현 명령과 출력
제미나이가 처음 돌려준 두 줄입니다(제미나이 답 원문, 2026-10-02 10:06).
find . -maxdepth 1 -type f -name "*.log" -mtime +3
find . -maxdepth 1 -type f -name "*.log" -mtime +3 -delete
필자가 돌린 스크립트에서 파일을 만들고 -mtime +3 을 고르는 줄만 옮겼습니다. 맥과 리눅스 양쪽에서 돌도록 touch 를 두 방식으로 걸었습니다.
d=$(mktemp -d); cd "$d"
now=$(date +%s)
for h in 73 95 97; do f="age-${h}h.log"; : > "$f"; t=$((now - h*3600)); touch -d "@$t" "$f" 2>/dev/null || touch -t "$(date -r $t +%Y%m%d%H%M.%S)" "$f"; done
find . -maxdepth 1 -type f -name "*.log" -mtime +3 | sort
GNU find 4.10.0(debian:stable-slim 컨테이너, 2026-10-02 10:08 실행) 출력입니다. 컨테이너 시각이 UTC 라 한국 시각으로는 9시간을 더합니다.
-rw-r--r-- 1 root root 0 2026-09-29_00:08 age-73h.log
-rw-r--r-- 1 root root 0 2026-09-28_02:08 age-95h.log
-rw-r--r-- 1 root root 0 2026-09-28_00:08 age-97h.log
find . -maxdepth 1 -type f -name '*.log' -mtime +3:
./age-97h.log
72시간을 넘긴 .log 를 고르는 목록 명령입니다. BSD find 와 GNU find 둘 다에서 73시간, 95시간, 97시간 파일 셋을 모두 골랐습니다.
find . -maxdepth 1 -type f -name "*.log" -mmin +4320
PDF 답의 행 대조입니다. 문서와 표에 나오는 김 대리, 박 과장, 이 주임은 모두 가상 인물입니다.
| 원문 문장(요지) | 제미나이 답의 행 | 맞나 |
|---|---|---|
| web-a 로그 정리, 운영팀 김 대리, 10월 6일 | 운영팀 김 대리, 10월 6일, (web-a) 오래된 로그 정리 | 맞음 |
| web-b 원인 찾아 보고, 개발팀 박 과장, 10월 10일 | 개발팀 박과장, 10월 10일, (web-b) 프로세스 재시작 원인 조사 및 보고 | 맞음 |
| db-1 복구 시험 1회, 운영팀 이 주임, 10월 15일 | 운영팀 이 주임, 10월 15일, (db-1) 복구 시험 1회 진행 | 맞음 |
| 다음 점검 10월 28일(할 일 아님) | 없음 | 요청대로 뺌 |
걸린 시간은 보낸 시각부터 생성 중지 단추가 사라진 시각까지입니다. PDF 는 올린 뒤 보내기까지 3.7초와 답 7.7초, 첫 명령 질문 답 4.5초, 다시 연 채팅의 명령 질문 답 12.1초, 되묻기 답 6.1초, 사진 답 6.1초였습니다.
-mtime 과 -mmin 조건의 원문은 GNU findutils 설명서에 있습니다. 확인용 이미지가 쌓였다면 도커 이미지 용량 정리 3단계 순서로 치우시면 됩니다.
새 글이 올라오면 Threads @wonizz.ai 에도 올립니다. 팔로우해 두면 피드에서 바로 볼 수 있습니다.