[🤖] Codex가 내 기술 블로그에서 나를 지워버렸다

✨ GPT-5.6 Sol의 요약 　

기술 블로그를 써달라고 했더니 Codex가 내가 문제를 인식하고 명령한 과정 대신 자기 작업 보고서를 써버렸다. 원인을 추적해 글쓰기 Skill의 서사 중심을 사용자에게 되돌린 기록.

내가 쓴 기술 블로그에서 내가 사라졌다

그래프 엔지니어링이라는 말을 접하고, 이 방법이 내가 겪은 Codex 장기 작업 실패를 막는 데 정말 적절한지 계속 따져 물었다. 처음부터 거창한 프레임워크를 원한 것도 아니었다. 작업 세션이 한 단위를 끝내면 독립된 감사 세션에 넘기고, 감사 결과가 돌아오기 전에는 다음 작업으로 넘어가지 못하게 하는 가장 작은 구조가 내 생각이었다.

Codex는 처음부터 내 제안을 비판하기보다 그럴듯하게 동의했고, 내가 반론을 가져올 때마다 또 그 반론에 맞춰 말을 바꿨다. 그래서 비판적 검토를 반복해서 명령했고, 쓸데없이 복잡해지거나 토큰만 빨아먹는 구조가 되지 않도록 계속 걷어냈다. 결국 내가 원한 것은 그래프 엔지니어링이라는 유행어를 설명하는 글이 아니라, 내가 실제 실패에서 무엇을 발견했고 어떤 명령으로 Codex의 작업 방식을 바꾸었는지를 기록하는 일기였다.

그런데 Codex가 써온 글의 중심에는 내가 없었다. 내가 어떤 문제를 발견했는지, 왜 처음 답을 거부했는지, 어떤 반론으로 구조를 줄였는지는 뒤로 밀렸다. 대신 Codex가 Skill에 무슨 구조를 넣었고, 어떤 감사 절차를 돌렸고, 어떤 검증을 통과했는지가 글의 주인공이 되어 있었다. 내 기술 블로그에 Codex의 작업 보고서가 올라갈 뻔한 셈이다.

나는 그제야 문제를 정확히 말했다.

항상 메인은 내가 어떤 문제를 인식하고 너에게 어떻게 명령해서 문제를 해결했는가가 중심이지, 네가 어떻게 작업했는지는 아주 간단히 언급해도 될 정도로 전혀 중심이 아니야.

AI의 구현 과정은 독자에게 도움이 되는 팁일 때 조금 더 설명하면 된다. 그것이 아무리 기술적으로 복잡하고 검증까지 잘됐어도 내 글의 서사를 빼앗을 이유는 없다.

고쳤다고 생각한 Skill이 원인을 품고 있었다

더 황당했던 것은 이 문제를 예전에 이미 고쳤다고 기억하고 있었다는 점이다. 7월 말에 Codex Skill로 작업의 흐름과 감각을 이어 붙였다는 글을 쓰면서, 글쓰기 Skill이 cdb의 규칙을 복제해 들고 다니지 말고 매번 현재 프로젝트의 규칙과 대화, Git 기록을 직접 읽게 만들었다.

당시에는 분명 중요한 문제를 해결했다. 오래된 규칙을 Skill 안에 복사해두면 프로젝트가 바뀔 때마다 글쓰기도 어긋난다. 그래서 규칙의 저장 위치를 바로잡고, 현재 맥락을 다시 읽게 했다. 나는 그 정도면 Skill이 제대로 고쳐졌다고 생각했다.

하지만 이번에 확인해보니 고친 것은 규칙을 어디서 읽느냐였지, 글이 누구의 경험을 말해야 하느냐가 아니었다.

기존 Skill은 먼저 작업 증거에서 독자에게 줄 기술적 가치를 찾게 했다. 개인 일기와 재사용 가능한 기술 글을 나눈 뒤, 기술 소재가 많으면 자연스럽게 일반화된 보고서 구조로 기울었다. 심지어 개인적인 시간순 서사를 제거해도 기술적 가치가 선명한지를 확인하는 자기검사까지 있었다. 내가 겪고 판단하고 명령한 과정은 보존해야 할 원문이 아니라, 기술 설명을 깔끔하게 만들기 위해 제거할 수도 있는 잡음으로 취급되고 있었다.

그러니 Codex가 계속 같은 짓을 한 것도 우연이 아니었다. 대화에서 아무리 내 의도를 말해도, 실제 글을 만드는 Skill은 기술적 사실과 구현 과정을 먼저 뽑고 있었다. Git과 도구 기록은 사실 확인 자료여야 하는데 글의 목차가 되었고, Codex가 한 작업은 보조 설명이어야 하는데 주인공이 되었다. Skill은 작업을 안정적으로 반복시키는 도구인 만큼, 잘못된 전제도 아주 안정적으로 반복했다.

서사의 주체부터 다시 뒤집게 했다

처음에는 혹시 일부 문구만 잘못된 것인지 의심했다. 그러나 Codex가 또 “대체로 괜찮고 조금 보강하면 된다”는 식으로 물러서려 하자 확실하게 개선하라고 명령했다. 문장을 몇 줄 추가하는 것으로는 부족했다. 글을 만드는 순서 자체를 뒤집어야 했다.

새 기준의 첫 문장은 기술 주제가 아니라 사용자였다. 내가 왜 이 일을 시작했는지, 무엇이 잘못됐다고 판단했는지, AI에 무엇을 명령했는지, 첫 결과를 왜 거부했는지, 조건을 어떻게 다시 좁혔는지, 그래서 결과가 어떻게 달라졌는지를 먼저 복원하게 했다.

Git, 도구 출력, 코드 변경과 검증 결과는 그 서사를 대체하지 않고 사실을 확인하는 데만 쓰게 했다. AI가 어떤 파일을 고쳤고 어떤 검사를 통과했는지는 내 판단의 결과를 설명하거나 다른 사람에게 실제 팁이 될 때만 남긴다. 사용자가 명시적으로 튜토리얼이나 기술 참고문서를 요청한 경우에만 구현 자체를 중심에 둘 수 있도록 예외도 좁혔다.

자기검사도 반대로 바꿨다. 이제 AI의 구현 세부를 걷어낸 뒤에도 내가 발견한 문제와 명령, 비판, 교정, 배운 점이 분명히 남아야 한다. 그것이 남지 않으면 문장이 아무리 매끄럽고 기술 정보가 많아도 내 일기가 아니다. 수정한 Skill은 문법 검증까지 통과시켰지만, 이번에 중요한 것은 검사 통과가 아니라 이 판단 기준이 뒤집혔다는 사실이다.

다음 글에서 볼 것은 문장이 아니라 내가 남았는지다

이번 일에서 가장 크게 착각한 것은 “예전에 고쳤다”는 기억이었다. 나는 Skill이 현재 규칙을 다시 읽게 만들었고, 그래서 글쓰기 문제도 해결됐다고 생각했다. 실제로는 규칙의 출처만 고쳤고 글의 목적은 고치지 않았다. 최신 규칙을 정확히 읽어도 그 규칙이 내 경험을 기술 보고서의 재료로 취급한다면 결과는 계속 틀린다.

AI에게 반복 작업을 맡길수록 Skill과 공용 규칙은 강력해진다. 동시에 잘못된 관점도 더 끈질기게 재생산한다. 한 번의 답변이 이상하면 그 자리에서 싸워 고칠 수 있지만, 잘못된 서사 모델이 Skill에 들어가면 다음 세션도 같은 방식으로 나를 지운다.

앞으로 기술 블로그 초안을 볼 때 가장 먼저 확인할 것은 문장이 얼마나 그럴듯한지, 기술 설명이 얼마나 자세한지가 아니다. 내가 무엇을 문제로 봤고, 어떤 명령과 반박으로 결과를 바꾸었는지가 남아 있는지를 먼저 볼 것이다. AI가 엄청난 일을 대신 해줄 수는 있어도, 내가 왜 그 일을 시켰는지까지 자기 이야기로 바꾸게 둘 수는 없다.