제미나이 사용법을 직접 시험해 보니 같은 채팅에서 find -mtime +3 설명이 처음에는 “72시간 초과”, 되묻자 “96시간부터” 로 뒤집혔습니다. PDF, 리눅스 명령, 화면 사진을 맡겨도 될까요? 표로 옮기는 일은 맡길 만했고 명령 설명은 한 번 더 되물어야 맞았습니다.
무엇을 했나 2026-10-02 오전 제미나이 웹 임시 채팅에 PDF 문서, 리눅스 명령, 화면 사진 세 가지 일을 맡겼습니다
결과 숫자 PDF 의 할 일 3개와 터미널 캡처의 파일 3개는 원문 그대로였고, 명령 설명은 두 번 물어 두 번 다 틀렸습니다
첫 답에 붙은 설명 한 줄이 틀렸기 때문입니다. 시험은 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 이 시간 계산을 덜 헷갈리게 했습니다
모드 메뉴에 보인 네 이름 가운데 이 글의 결과는 전부 3.8 Flash 한 모드의 결과입니다. 등급별 사용 한도는 제미나이 앱 도움말에서 확인하시는 편이 맞습니다.
모드별, 등급별 사용 횟수와 요금은 확인하지 않았습니다.
휴대폰 앱과 크롬 안의 제미나이는 쓰지 않았고, 전부 웹에서 시험했습니다.
1쪽보다 긴 PDF, 스캔한 PDF, 여러 파일 올리기는 해 보지 않았습니다.
필자의 결론
이번 제미나이 사용법 세 상황을 정리하면, 필자는 제미나이를 원문 대조가 쉬운 옮겨 적기에는 맡기고, 명령 설명은 반드시 한 번 되묻는 도구로 봅니다. 같은 모드가 같은 채팅 안에서 72시간이라고 했다가 96시간이라고 뒤집었고, 맞은 쪽은 find 를 직접 돌려 보고서야 가렸기 때문입니다.
그래서 당신은 이것만 하면 됩니다. 제미나이가 준 명령에 -delete 나 rm 이 있으면 목록 명령을 먼저 돌리고, 경계 바로 위의 숫자를 넣어 “예, 아니오로 먼저 답해 줘” 라고 되물어 보세요.
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단계 순서로 치우시면 됩니다.