며칠 전, 여러 개의 AI 코딩 도구를 병행해서 사용하는 많은 개발자가 공감할 만한 작은 패닉의 순간을 경험했습니다.

저는 케냐 Ruiru의 Mt. Kenya Regional League에서 활동하는 커뮤니티 축구 클럽인 Mugutha FC를 위한 멤버십 및 경기일 플랫폼을 구축하고 있습니다. 여러 AI 어시스턴트(AI assistants)를 사용하며 밤늦게까지 빌드 작업을 이어가던 혼란스러운 과정 속에서, 대시보드의 특정 버전이 제 컴퓨터의 _어디_에 저장되어 있는지 놓쳐버렸습니다.

저에게는 스크린샷 하나와 localhost URL에 대한 희미한 기억뿐이었습니다. 그게 전부였습니다.

제가 그것을 어떻게 찾아냈는지 — 그리고 문제를 해결한 작은 포렌식(forensic) 트릭을 소개합니다.

내가 가진 단서

유일하게 확실한 증거는 브라우저에서 실행 중인 대시보드의 스크린샷이었습니다:

• URL 바: 127.0.0.1:5173
• Windows 작업 표시줄 시계에 보이는 타임스탬프(timestamp): 2026년 6월 25일, 오전 12:09
• 사이드바 항목: Dashboard, Members, Fixtures, Broadcasts, Templates, Analytics, Settings
• "Welcome, Wakili Eric" 인사말과 Active Members, Messages Sent, Fixtures This Month, Expiring Soon에 대한 KPI 카드

포트(Port) 5173이 첫 번째 실질적인 단서였습니다. 이는 Vite의 기본 개발 서버(dev server) 포트입니다. 따라서 이것이 무엇이든, Vite로 스캐폴딩(scaffolded)된 React 또는 Vue 프로젝트이며, 어디에 배포된 것이 아니라 로컬(locally)에서 실행 중이라는 뜻입니다.

하지만 어떤 폴더일까요? 저는 여러 접근 방식을 비교하면서 다양한 AI 코딩 어시스턴트를 사용해 프로젝트 폴더를 생성하는 습관이 있는데, 솔직히 어떤 도구가 어떤 버전을 생성했는지 파악하지 못한 상태였습니다.

스크린샷을 검색 쿼리로 바꾸기

돌파구는 스크린샷의 타임스탬프가 단순히 "있으면 좋은 정보"가 아니라, 검색 필터(search filter)라는 사실을 깨달은 것이었습니다.

Windows에는 수정 날짜별로 파일을 필터링할 수 있는 forfiles라는 내장 명령어가 있습니다. 이를 재귀적 검색(recursive search) 및 키워드 필터와 결합하면, Windows에게 다음과 같이 요청할 수 있습니다: "이 정확한 날짜 또는 그 이후에 수정된 모든 프로젝트 파일을 보여줘."

첫 번째 시도 — 파일 이름으로 검색:

forfiles /P "C:\Users\%USERNAME%" /S /M *mugutha* /D +0 /C "cmd /c echo @path @fdate @ftime" 2>nul

이 명령어는 이름에 "mugutha"가 포함된 모든 파일을 검색합니다. 합리적인 첫 번째 추측이지만, 명백한 결함이 하나 있습니다. 바로 _폴더 자체_의 이름에 "mugutha"가 포함되어 있어야만 작동한다는 점입니다. 만약 AI 도구가 프로젝트를 dashboard-app과 같이 일반적인 이름이나 샌드박스(sandboxed) 임시 폴더에 생성했다면, 이 검색으로는 아무것도 찾을 수 없었을 것입니다.

그래서 저는 프로젝트의 이름이 아니라, Vite 프로젝트가 실제로 무엇을 포함하고 있는지를 기준으로 검색하는 방식으로 전환했습니다:

forfiles /P "C:\Users" /S /D +06/24/2026 /C "cmd /c echo @path @fdate @ftime" 2>nul | findstr /I "package.json vite.config"

명령어를 분석하면 다음과 같습니다:

• /P "C:\Users" — Users 디렉토리에서 검색을 시작합니다.
• /S — 모든 하위 폴더를 포함하여 재귀적으로(recursively) 검색합니다.
• /D +06/24/2026 — 이 날짜 이후 또는 당일에 수정된 파일만 찾습니다.
• /C "cmd /c echo @path @fdate @ftime" — 일치하는 항목마다 전체 경로, 날짜, 시간을 출력합니다.
• findstr /I "package.json vite.config" — 결과를 필터로 전달하여, 거의 모든 Vite 프로젝트 루트에 존재하는 두 파일인 package.json 또는 vite.config가 언급된 줄만 남깁니다.

이것이 핵심 아이디어입니다. 프로젝트 이름을 추측하는 대신, 기술의 지문(fingerprint) — 즉, 폴더 이름을 무엇이라 부르든 Vite 프로젝트가 존재한다면 반드시 존재할 수밖에 없는 파일들을 검색한 것입니다.

검색 결과

출력 결과는 즉시 흥미로웠습니다:

"C:\Users\CodexSandboxOffline\.codex\.sandbox\cwd\c01195b0e0a02dfa\package.json" 6/24/2026 8:22:03 PM
"C:\Users\CodexSandboxOffline\.codex\.sandbox\cwd\c01195b0e0a02dfa\node_modules\.vite\deps\package.json" ...
"C:\Users\CodexSandboxOffline\.codex\.sandbox\cwd\c01195b0e0a02dfa\node_modules\@vitejs\plugin-react\package.json" ...

드디어 찾아냈습니다. 제가 평소 사용하는 프로젝트 폴더들 중에는 없었습니다. Desktop\projects\Mugutha_MembersClub 안에도 없었습니다. 그것은 완전히 별개의 Windows 사용자 프로필인 CodexSandboxOffline 안에 들어 있었습니다.

그 폴더 이름이 모든 것을 말해주었습니다. 이 특정 버전의 대시보드는 제가 일반적인 프로젝트 디렉토리에 직접 구축한 것이 아니었습니다. 그것은 OpenAI Codex에 의해 생성된 격리된 샌드박스 (sandbox) 환경 내부에서 실행되고 있었으며, 자체 사용자 계정, 자체 node_modules, 그리고 @vitejs/plugin-react, lightningcss, rolldown, lucide-react를 포함하는 의존성 트리(dependency tree) — 즉, 현대적이고 빠른 Vite + React 툴체인(toolchain) — 를 갖추고 있었습니다.

미스터리가 풀렸습니다. 제 스크린샷에 있던 대시보드는 제가 다른 곳에서 사용하던 동일한 도구의 다른 세션이 아니었습니다. 그것은 내내 파일 시스템의 자신만의 구석에 격리된 완전히 다른 AI 어시스턴트였습니다.

여기서 얻을 수 있는 실제 교훈

이 이야기에서 흥미로운 부분은 Codex나 샌드박스 그 자체에 관한 것이 아닙니다. 여러 AI 코딩 도구를 사용하는 환경에서 일한다면 기억해 둘 만한 패턴입니다.

스크린샷의 타임스탬프는 단순한 기억 보조 도구가 아니라 검색 필터입니다. 스크린샷 구석의 시계를 forfiles를 위한 문자 그대로의 날짜 필터로 취급하자마자, 검색 방식은 "폴더 이름 추측하기"에서 "정확히 이 시간대에 수정된 모든 항목 보여주기"로 바뀌었습니다. 이는 훨씬 더 신뢰할 수 있는 검색 방법입니다.

프로젝트의 이름이 아니라, 프로젝트가 무엇을 '포함'하고 있는지로 검색하세요. 저는 폴더 이름을 몰랐습니다. 하지만 그 안에 package.json과 아마도 vite.config가 포함되어 있어야 한다는 것은 알고 있었습니다. 툴체인(toolchain)의 특징을 검색함으로써, 제가 전혀 찾아볼 것이라고 예상하지 못했던 위치 — 제 컴퓨터에 존재하는지도 몰랐던 별도의 격리된 Windows 사용자 프로필 — 에서 단 몇 초 만에 찾아낼 수 있었습니다.

서로 다른 AI 코딩 어시스턴트는 디스크에 매우 다른 지문(fingerprints)을 남길 수 있습니다. 어떤 도구는 일반 작업 공간에 평범한 프로젝트 폴더를 생성합니다. 반면 Codex의 샌드박스 모드와 같은 다른 도구들은 완전히 분리된 환경 — 다른 사용자 계정, 다른 node_modules, 다른 모든 것 — 으로 자신을 격리합니다. 도구 사이를 전환하며 사용한다면, 각 도구가 실제로 파일을 어디에 두는지 알아두는 것이 가치가 있습니다.

필요한 경우 사용할 수 있는 명령어

만약 여러분도 비슷한 상황에 처해 있다면 — 무언가가 만들어진 시점은 대략적으로 알지만 어디에 있는지는 모르는 경우 — 다음과 같은 범용적인 방법을 사용할 수 있습니다:

forfiles /P "C:\Users" /S /D +MM/DD/YYYY /C "cmd /c echo @path @fdate @ftime" 2>nul | findstr /I "package.json vite.config"

package.json과 vite.config를 여러분의 기술 스택(stack)과 일치하는 파일 이름 지문(fingerprint)으로 교체하세요. 예를 들어 Python의 경우 requirements.txt, Rust의 경우 Cargo.toml, PHP의 경우 composer.json을 사용할 수 있습니다. 원리는 동일합니다. 여러분이 잊어버렸을지도 모르는 폴더 이름이 아니라, 반드시 존재할 것이라고 보장할 수 있는 파일을 찾는 것입니다.

후보를 찾았다면, 너무 들뜨기 전에 확인 과정을 거치세요:

cd path\to\folder
type package.json

이 명령어 하나만으로 프로젝트 이름, 의존성 (dependencies), 그리고 스크립트 (scripts)를 알 수 있으며, 이는 여러분이 올바른 것을 찾았는지 즉시 판단하기에 충분합니다.

작은 조사였지만 만족스러운 과정이었습니다. 때때로 디버깅 (debugging)은 코드에 관한 것이 아니라, 여러분이 남긴 디지털 빵부스러기 (digital breadcrumbs)를 통해 자신의 과거 행동을 재구성하는 과정일 때가 있습니다.