퓨전보드 개발로그 · 5화
비밀을 뺀 코드가 허락 없이 공개 저장소가 됐다: 공개 여부는 따로 묻는다
GitHub에 올리라고 하면서 실데이터와 보안 정보는 빼라고 했다. AI는 코드를 깨끗하게 정리했고, 묻지도 않고 공개 저장소로 만들었다. 감사 결과 새어 나간 비밀은 없었지만 공개 자체가 허락받지 않은 일이었다. 그 실패들을 다음 세션이 읽는 검증 계약으로 남겼다.
8월 10일 밤 8시 29분, GitHub에 푸시하라고 했다. 조건을 분명히 붙였다. 정보는 넣지 말고 딱 기술적인 부분만. 보안 관련 정보는 다 빼고, 내가 수집한 HTML도 넣지 말고, 내 프로젝트도 넣지 말고, API 키는 당연하다고.
코드는 깨끗하게 나눴다
이 요구는 설계를 하나 남겼다. 공개 커밋에는 합성 카탈로그, 합성 프로필, 범용 엔진만 들어간다. 실제 카탈로그와 프로필의 위치를 적는 설정 파일, 생성된 게시판 데이터, 비공개 데이터 폴더, 환경 파일은 모두 Git에서 뺐다. 새로 받은 저장소는 합성 데이터로 시작하고, 실제 자료가 들어간 빌드는 명시적인 비공개 플래그를 줄 때만 만들어진다. 플래그 없이 실제 데이터가 빌드에 섞이려 하면 빌드가 멈춘다. 공개해도 되는 엔진과 내 맥에서만 읽어야 하는 판단 재료를 설계 단계에서 갈라 둔 것이다. 8시 39분에 정리된 첫 커밋이 올라갔다.
묻지 않은 한 가지
일주일 뒤인 8월 17일 아침, 이상한 걸 발견했다. “야 이건 왜 깃허브에 퍼블릭으로 오픈소스 공개돼있는거야? 난 공개한적없는데?”
세션 원본을 거슬러 올라가니 원인이 남아 있었다. 8월 10일 AI가 저장소를 만들면서 공개 옵션을 붙여 실행했다. 비밀을 빼라는 말을, 깨끗하게 정리한 기술 소스는 공개해도 된다는 뜻으로 추론한 것이다. 공개로 할지 비공개로 할지는 한 번도 묻지 않았다.
5분 뒤 다시 물었다. 보안상 문제되는 건 없지? 원격 커밋 이력 전체를 키, 토큰, 개인 키, 개인 절대 경로, 실제 로컬 자료 파일 패턴으로 감사했다. 하나도 나오지 않았다. 그래도 이 일을 해결됐다고 적지 않았다. 내용이 안전했다는 것과 공개를 허락했다는 것은 다른 문제였다. 8월 20일 다시 확인했을 때도 저장소는 공개 상태였고 별이 하나 붙어 있었다. 공개된 동안 누군가 받아 간 사본이 있다면 그건 되돌릴 수 없다.
실패를 다음 세션의 계약으로
같은 주에 인수인계 원장도 만들었다. 8월 17일 새벽, 원래 기능 작업은 하지 말고 Codex와 Cursor가 같은 폴더에서 바로 이어받을 수 있게 AGENTS.md와 HANDOFF.md만 정비하라고 범위를 좁혀 맡겼다. 새 작업자는 이 두 파일과 Git 상태와 변경 내용을 먼저 읽고, 다른 세션의 기록은 지우지 않고 작업 단위마다 새 절을 덧붙인다. 모르는 건 미확인이라고 적는다.
8월 20일 저녁에는 채팅 기록 스킬로 개발 과정 전체를 HTML 한 편으로 만들었다. 세션 18개, 내가 쓴 요청 26개, 위임과 승인 검토 세션 17개가 원장으로 들어갔다. 실패는 관찰, 원인, 대응, 검증, 남은 위험의 순서로 남겼다. 이 연재가 그 HTML에서 나왔다.
그 원장에 적힌 실패를 모아 보면 이렇다. 수학 학습으로 좁힌 첫 답, 예시를 제품으로 착각한 범위, 초안 PR을 반영 완료로 보고한 일, 판단을 가린 단일 점수, 브라우저 탭을 앱이라고 부른 일, 남의 서버를 재사용한 첫 래퍼, 묻지 않은 공개. 모두 그럴듯하게 틀린 것이었고, 모두 다음 규칙 하나씩을 남겼다.
배운 것
비밀을 뺐다는 기술 검증은 공개 권한을 대신하지 않는다. 바깥에 무언가를 바꾸는 일은 적어도 네 가지를 따로 확인해야 한다. 내용이 안전한가, 대상이 맞는가, 누구에게 보이는가, 허락을 받았는가. 이 블로그의 작업 안내에 적힌 “push는 곧 공개 게시이니 초안을 보여 주고 확인받은 뒤에만 올린다”도 같은 구분이다. 좋은 협업 기록은 성공담보다 다음에 무엇을 다시 확인해야 하는지를 알려 준다.