강의가 경고한 키 유출을 저는 이미 당하고 복구했습니다: 저장소 9개를 다시 훑어 0건을 확인했습니다

소개

2주차 과제는 깃허브와 버셀, 슈퍼베이스로 나가는 것입니다. 그리고 스터디장이 시간을 따로 들여 경고한 대목이 있습니다.

클로드 코드 API 키, 슈퍼베이스 롤 키 (…) 요런 것들은 깃허브에 올리시면 안 돼요. 안 됩니다.

저는 이 경고를 이미 겪었습니다. 얼마 전 제 지식 vault를 정리하다 저장소 히스토리에 있으면 안 될 파일들이 들어 있는 것을 발견하고 제거했습니다. 정부 공모 문서, 단톡방 로그 같은 것들이었습니다.

그래서 이번 주에는 나가기 전에 되돌아보기로 했습니다. 제 저장소 아홉 개에 지금도 남아 있는 것이 있는가. 그리고 1주차에서 "오케스트레이터를 0회 불렀다"고 확인했으니, 어디까지 나가 있는지도 함께 셌습니다.

진행 방법

사용 도구: Claude Code, git

Step 1. 추적 중인 파일에 키가 있는가

git이 지금 관리하고 있는 파일 목록에서 위험한 이름을 찾았습니다.

git -C "$d" ls-files | grep -icE '\.env$|\.env\.|secret|credential|_token|api_key|apikey'

아홉 개 전부 .gitignore가 있고 추적 중인 위험 파일은 0건입니다.

Step 2. 히스토리에도 없는가

지금 없어도 과거 커밋에 남아 있으면 소용이 없습니다. 이번 주 강의의 경고가 정확히 그 지점입니다.

git -C "$d" log --all --pretty=format: --name-only | sort -u | grep -icE '\.env$|secret|credential|_token|api_key'

Step 3. .env는 어디 있고 제외되어 있는가

실제 .env 파일이 있는 곳을 찾았습니다.

하나뿐이고 제대로 제외되어 있습니다.

Step 4. 이 0이 그냥 얻어진 것이 아니다

knowledge-hub의 현재 상태를 봤습니다.

정리 전에는 166MB였습니다. 히스토리에서 16개 파일을 제거하면서 줄어든 것입니다. 지금의 0건은 정리한 결과이지 처음부터 깨끗했던 것이 아닙니다.

Step 5. 강의의 흐름에서 어디까지 갔나

이번 주 과제는 로컬 → 깃허브 → 버셀 → 슈퍼베이스입니다. 제 저장소가 어느 칸에 있는지 셌습니다.

원격이 없는 두 곳은 citation-verifier와 knowledge-hub입니다. 지식 vault는 민감 파일을 정리한 뒤 원격을 붙이지 않은 채로 두었습니다.

DB 연동 흔적도 찾아봤습니다.

grep -ril "supabase|postgres|firebase" --include='*.py' --include='*.js' ~/projects

2개 파일이 걸렸는데, 실제 연동이 아니라 언급 수준이었습니다.

결과와 배운 점

측정 결과

배운 점

1. .gitignore는 미래만 막습니다. 아홉 개 전부 .gitignore가 있는데도 knowledge-hub에는 민감 파일이 히스토리에 들어 있었습니다. 파일이 커밋된 뒤에 규칙을 추가하면 과거는 그대로 남습니다. 강의가 나가기 전에 이 이야기를 한 이유가 여기 있습니다. 순서가 반대면 히스토리를 다시 써야 합니다.

2. 정리는 지우는 것으로 끝나지 않습니다. 166MB에서 12MB가 된 것은 파일을 지우고 나서 압축까지 다시 한 결과입니다. 그 과정에서 작업 폴더의 파일까지 사라져 백업에서 복구했습니다. 미리 백업해 두지 않았으면 잃었을 것입니다.

3. 깃허브까지는 갔는데 그다음이 비었습니다. 9개 중 7개가 원격에 있습니다. 그런데 버셀 0개, 슈퍼베이스 0개입니다. 강의의 네 칸 중 두 칸에서 멈춰 있습니다. 백업은 하고 있는데 남에게 보여지는 형태로는 내보내지 않았습니다.

4. 원격을 안 붙인 것도 판단이었습니다. knowledge-hub에 원격이 없는 것은 게을러서가 아니라, 민감 파일을 정리한 직후라 공개 전에 다시 확인하려고 미룬 것입니다. 이번에 0건을 확인했으니 미룰 이유가 없어졌습니다.

시행착오

• 처음 검사 결과 출력이 0\n0 형태로 깨져 나왔습니다. grep -c가 매치가 없을 때 종료 코드 1을 반환해 || echo 0이 함께 붙은 탓입니다. 숫자를 그대로 표에 옮겼다면 이상한 값이 들어갔을 것입니다. 셸에서 개수를 셀 때는 출력이 숫자 하나인지 눈으로 확인해야 합니다.

• 슈퍼베이스 관련 파일을 넓게 검색해 2건이 나왔을 때 "조금은 해 봤다"로 볼 뻔했습니다. 열어 보니 연동 코드가 아니라 언급이었습니다. 검색어가 걸린 것과 그것을 쓰고 있는 것은 다릅니다. 이번 스터디에서 반복해서 확인하는 지점입니다.

앞으로의 계획

• knowledge-hub에 원격을 붙이겠습니다. 0건을 확인했으니 미룰 근거가 없어졌습니다. 다만 공개 저장소가 아니라 비공개로 시작합니다.

• 버셀 배포는 paper-radar부터 하려 합니다. 이미 주간 다이제스트를 만들고 있고 정적 페이지라 4단계 중 3단계까지 바로 갑니다.

• 슈퍼베이스는 읽은 논문 기록을 첫 대상으로 잡았습니다. 지금은 파일로만 쌓여 있어 검색이 불편합니다. 동적 페이지가 필요한 자리가 여기입니다.

• 1주차에 0회였던 오케스트레이터를 이번 배포 작업에서 불러 보겠습니다. 깃허브 연동, 버셀 배포, 슈퍼베이스 연결이 여러 단계를 거치는 일이라, 순서를 지켜야 하는 작업에 입구가 하나여야 한다는 것을 1주차에 확인했습니다.

도움 받은 글 (옵션)

• 23기 내 업무 에이전트 2주차 강의 (송주환): 로컬에서 깃허브, 버셀, 슈퍼베이스로 이어지는 네 단계, 정적 페이지와 동적 페이지의 구분, .env와 .gitignore로 키를 분리하라는 경고, LLM 위키에 작업 과정을 쌓아 AI가 이어받게 하는 방식

• 23기 내 업무 에이전트 1주차 사례글 (본인): 서브에이전트 21명 중 12명만 호출됐고 오케스트레이터는 0회였다는 측정