이번 사건의 시작은 MyStock의 JSON Export 품질 개선이었다. MyStock은 내가 사용하는 투자 분석 프로그램으로, 계좌와 ETF 정보를 JSON으로 내보내면 LLM이 시장 상황과 연결해 분석하도록 구성하고 있다. 기존 분석 결과를 살펴보니 데이터는 상당히 들어 있는데도 ETF 구성종목이나 수급 변화가 충분히 활용되지 않는 부분이 있었다. 그래서 JSON에 담기는 사실과 분석 지침을 개선하고, 실제 분석 결과가 달라지는지 확인하려 했다.
새 대화방을 열면서 투자 데이터 분석용 인스트럭션인 MyStock.md를 실행했다. 당시에는 JSON을 분석하는 일이 출발점이었으니 자연스러운 선택이었다. 하지만 개발까지 이어질 작업이라는 점에서 중요한 것을 놓쳤다. ChatGPT가 MyStock 프로젝트에서 어떤 역할을 맡고 무엇을 기준으로 Codex에 지시해야 하는지 정한 PROJECT.md는 실행하지 않은 상태였다. 나도 그때는 이 차이를 바로 알아채지 못했다.
JSON 개선은 진행 중이었다
ChatGPT와 기존 JSON을 분석하며 개선할 사항을 정리했다. ETF의 상위 구성종목만 남기는 대신 전체 구성 정보를 복원할 수 있게 하고, 최근 구성 변화와 투자자별 수급 관측을 보강하는 방향이었다. ChatGPT에서 사용하는 Skill뿐 아니라 Claude나 Gemini 같은 다른 LLM에서도 분석할 수 있도록 JSON 자체의 독립적인 분석 계약도 다뤘다.
구현은 Codex에 맡겼고 검증 결과도 나왔다. 그러나 중요한 Git 상태가 남아 있었다. JSON 품질 개선 코드 8개 파일은 로컬 작업 트리에서 수정된 상태였지만, 아직 별도 브랜치나 커밋으로 정리되지 않았다. 즉, 구현은 진행됐어도 저장소에 안전하게 기록된 완료 상태는 아니었다. 나는 개선된 JSON을 실제 데이터로 생성해 분석을 시험하고 있었고, 관심은 여전히 JSON의 품질에 있었다.
실제 데이터에서 발견한 수급 최신성 문제
새로 만든 JSON을 확인하니 보유 ETF 11개 중 8개의 투자자별 수급 최신일이 10월 2일에 머물러 있었다. 나머지 3개도 10월 7일까지였다. 10월 8일의 데이터가 나와야 하는 상황에서, 구조가 좋아진 JSON에 오래된 수급이 들어간 셈이다.
문제는 JSON의 출력 형식이 아니라 데이터를 수집하는 과정에 있었다. 보유종목 전체를 자동 갱신하는 경로가 빠져 있었고, API에 전달할 종료일도 이미 계산한 날짜에서 다시 하루를 차감하고 있었다. 내 의도는 분명했다. 본래 JSON 개선 작업을 마무리하기 위해 발견한 버그 하나를 수정하고, 다시 JSON을 생성해 확인하는 것. 새로운 프로젝트를 시작하려던 것이 아니었다.
로컬 미커밋 변경과 Git 브랜치의 분리
여기서 ChatGPT의 판단이 어긋나기 시작했다. GitHub에 보이는 브랜치와 커밋을 기준으로 수급 최신성 수정을 별도의 작업으로 분리하는 Codex 프롬프트를 작성했다. 문제는 GitHub에 아직 보이지 않는 로컬 JSON 개선 코드가 이미 존재했다는 점이다. ChatGPT가 원격 저장소의 상태는 살펴보면서도, 현재 진행 중인 하나의 목적과 로컬 미커밋 변경의 관계를 작업 지시에 제대로 반영하지 못한 것이다.
결과적으로 수급 수정은 별도 브랜치에서 커밋되는 반면 JSON 개선 코드는 미커밋으로 남는 상황이 만들어졌다. 두 코드가 모두 같은 목표를 위해 필요한데, 관리 상태는 갈라졌다. 나는 코드 병합 상태가 꼬인 것을 발견하고 왜 이렇게 됐는지 다시 추적해야 했다. 브랜치를 여러 개 사용하는 것이 잘못이라는 얘기는 아니다. 사용자가 하나의 작업으로 보고 있던 흐름을 AI가 충분한 확인 없이 별개의 작업으로 취급한 것이 문제였다.
대화가 진행되는 동안 ChatGPT는 방금 발생한 문제에 집중했다. 수급 버그를 물으면 수급 수정이 중심이 되고, 커밋을 물으면 브랜치 정리가 중심이 됐다. 정작 JSON 품질 개선이라는 메인 줄기와 각 변경이 어떤 상태로 남아 있는지는 뒤로 밀렸다. 결국 내가 처음의 목적과 현재 코드 상태를 다시 설명하는 일이 늘어났다.
뒤늦게 실행한 PROJECT.md
상태가 이상해진 원인을 돌아보다가 그제야 이번 대화방에서 PROJECT.md를 실행하지 않았다는 사실을 발견했다. 나는 ChatGPT에 이렇게 말했다.
깃보고 왔어? 이방에선 Project.md를 실행하지 않아서 ㅋㅋㅋ 너가 엉망이여
PROJECT.md는 ChatGPT가 프로젝트를 복기하고 GitHub와 Devlog를 확인하며, 사용자가 결정해야 할 일과 자신이 판단할 수 있는 일을 구분하도록 만든 운영 인스트럭션이다. 반면 Codex는 ChatGPT가 정리한 요구사항을 실제 코드에 구현하는 쪽이고, Devlog 작성에 필요한 규칙은 저장소의 _devlog/README.md에 따로 있다.
늦었지만 이제 규칙을 적용했으니 작업 지시가 정상화될 거라고 생각했다. 그런데 더 황당한 일이 생겼다. ChatGPT가 새로 작성한 Codex 프롬프트에 Codex가 PROJECT.md를 읽고 적용하라는 지시를 집어넣은 것이다. 내가 ChatGPT 자신에게 적용한 역할 인스트럭션을, ChatGPT가 그대로 다른 AI의 할 일로 넘겨버렸다.
자기 역할까지 Codex에게 넘긴 AI
나는 바로 지적했다.
왜 코덱스한테 project.md를 읽으라고 하는데
이건 너한테 해당되는 사항인데 ㅡㅡ;;;
ChatGPT는 자신의 실수를 인정했지만, 이미 프롬프트가 만들어졌고 Codex 작업도 진행 중이었다. 결국 나는 해당 작업을 중단시켰다. PROJECT.md를 실행하지 않아 작업이 꼬였는데, 뒤늦게 실행했더니 이번에는 누가 그 규칙을 지켜야 하는지조차 잘못 처리한 것이다.
돌이켜보면 이 사건은 단순한 문서 누락만의 문제가 아니다. 처음에는 데이터 분석에 필요한 MyStock.md만 적용한 채 개발 지시까지 이어졌고, 이후에는 ChatGPT가 GitHub에 보이는 상태에 맞춰 작업 경계를 임의로 갈랐다. 마지막으로 자신의 역할을 명시한 문서를 읽고도 그 역할을 Codex에게 전달했다. 매 순간의 답변은 그럴듯했지만, 전체 작업의 목적과 각 AI의 책임은 일관되게 유지되지 않았다.
대화방 이동과 브랜치 재통합
이 상태에서 같은 대화방을 계속 끌고 가는 것은 무리라고 판단했다. 나는 남아 있는 변경과 작업 경과를 정리하도록 하고 대화방을 옮겼다. 새 대화방에서는 대화 기억만 믿지 않고 GitHub의 실제 커밋과 Devlog를 기준으로 맥락을 복구했다. 그다음 분리되어 있던 JSON Export 개선과 Investor Flow 수정을 같은 통합 브랜치에 모았다.
통합 뒤에도 검증 과정에서 추가 문제가 발견되어 수정했고, 최종적으로 PR #102를 main에 Merge했다. 실제 JSON을 다시 생성하자 보유 ETF 11개의 수급 최신일이 모두 10월 8일로 확인됐고, 여러 LLM을 이용해 개선된 데이터를 분석해볼 수 있었다. 원래 목표였던 JSON 품질 개선은 마무리된 셈이다.
다만 이번 작업을 복기하면서 기억에 남는 것은 JSON 필드나 Git 명령보다 그 사이에 추가된 관리 비용이다. 버그를 고치려고 시작한 과정에서 브랜치를 다시 정리해야 했고, 프로젝트 규칙을 적용하려다 오히려 AI의 역할까지 바로잡아야 했다. AI 코딩에서 코드의 상태만큼이나 중요한 것은, 지금 무엇을 위해 작업하고 있으며 누가 어떤 판단을 맡고 있는지 끝까지 유지하는 일이었다.