2026년 6월 26일, 미리캔버스 디자인허브에 올린 요소 20개가 승인됐다. 20개는 심사 대기, 86개는 제출 예정이었다. 그런데 이걸 만들던 중 코덱스의 이미지 생성 스킬이 갑자기 안 잡히는 일이 겹쳤다.
통념과 실제, 무엇이 달랐나
통념은 "내가 명령을 잘못 불렀다"였고, 실제는 스킬 캐시가 재생성되는 타이밍에 폴더가 비어 보이는 문제였다.
| 구분 | 통념 | 실제(원문 기준) |
|---|---|---|
| 원인 | 내가 명령어를 잘못 불렀다 | .system 스킬 폴더가 생겼다가 사라지는 캐시 문제 |
| 스킬 존재 여부 | 스킬 자체가 삭제됐다 | codex exec를 띄우면 다시 생겼다가 프로세스가 끝나면 사라짐 |
| 대응 | 그냥 다시 시도하고 넘어간다 | 요소만 만든 게 아니라 Codex 이슈까지 올렸다 |
표로 정리하면 셋 다 첫인상과 실제 결과가 달랐다. 아래에서 각 항목의 근거를 원문 순서대로 짚는다.
왜 처음엔 내 실수라고 생각했나?
$imagegen이 안 잡히는 순간, 가장 먼저 의심한 건 내 입력이었다.
처음엔 내가 뭘 잘못 부른 줄 알았다고 적었다. 미리캔버스 요소 20개 승인, 20개 심사 대기, 86개 제출 예정이라는 작업량을 처리하던 중이라, 스킬 호출이 안 먹히면 가장 쉬운 설명은 "내가 실수했다"는 것이었다. 손이 아니라 입술로 명령을 부르는 작업 방식에서는 발음이나 타이밍이 어긋났을 가능성도 배제할 수 없었기 때문에, 자신을 먼저 의심하는 건 이상한 순서가 아니었다.
하지만 확인해보니 이상했다고 적힌 다음 문장이 이 통념을 뒤집는다. 같은 방식으로 다시 불러도 증상이 반복됐고, 단순 오타나 발음 문제로는 설명되지 않는 패턴이 보였다는 뜻이다.
스킬이 사라진 게 아니라면 무슨 일이었나?
codex exec를 실행하는 순간에만 폴더가 다시 생기고, 끝나면 사라지는 캐시 재생성 문제였다.
원문은 이 부분을 정확하게 짚는다.
codex exec를 띄우면 .system/imagegen이 다시 생겼다. 그런데 프로세스가 끝나면 또 사라졌다. 스킬이 없는 게 아니라 스킬 캐시가 재생성되는 타이밍에 비어 보이는 순간이 있었던 것이다.
이 관찰이 통념을 완전히 뒤집는 지점이다. 스킬 자체가 삭제된 게 아니라, .system 스킬 폴더가 생겼다가 사라지는 캐시 문제였다. 실행 중에는 존재하고 종료 후에는 없어지는 타이밍 차이를, 겉보기로는 "스킬이 사라졌다"로 오해하기 쉬운 상황이었던 셈이다.
단순 버그인데 왜 이슈까지 올렸나?
입술로 작업하는 사람에게 도구가 사라지는 건 흐름이 끊기는 문제였기 때문이다.
원문은 이 판단을 이렇게 남겼다. 입술로 작업하는 나한테 도구가 사라지는 건 그냥 버그가 아니라 작업 흐름이 끊기는 일이다. 이 문장이 통념과 실제의 세 번째 차이를 만든다. 일반적인 통념이라면 재현이 안 되는 순간적 버그는 다시 시도하고 넘어가는 것으로 끝난다. 하지만 실제 대응은 달랐다. 그래서 요소만 만든 게 아니라 Codex 이슈까지 올렸다고 적었다. 미리캔버스 쪽 승인 작업과 별개로, 도구 쪽 문제도 기록해서 남겨야 다음에 같은 상황을 다시 겪지 않는다는 판단이었다.
이 세 가지를 표로 다시 보면
- 승인 현황: 20개 승인 완료, 20개 심사 대기, 86개 제출 예정
- 증상: $imagegen 호출 실패, codex exec 실행 중에는 정상
- 원인: .system 스킬 폴더가 생겼다 사라지는 캐시 재생성 타이밍 문제
- 대응: 미리캔버스 제출 작업과 별개로 Codex 이슈 등록
숫자로 보면 이날은 결과만 좋았던 날이 아니었다. 20개 승인이라는 성과와, 86개를 더 준비해야 하는 남은 작업량과, 그 와중에 도구가 흔들린 사건이 같은 날 겹쳐 있었다.
참고로 확인해볼 것
아래는 제가 겪은 일이 아니라 배경 이해에 참고할 수 있는 일반적인 자료다. 각 서비스나 프로젝트의 세부 정책은 시점에 따라 달라질 수 있으니 링크 원문을 직접 확인하는 편이 안전하다.
미리캔버스 디자인허브의 제출·심사 절차 전반은 디자인허브 크리에이터 고객센터에서 확인할 수 있다.
스킬 폴더가 실행 중에만 생기고 종료 후 사라지는 현상처럼, 프로그램이 임시로 만들어 쓰는 캐시 파일의 일반적인 동작 방식은 캐시(컴퓨팅) 위키백과 문서에 개략적으로 정리되어 있다.
자주 묻는 질문
요소 20개는 최종 승인인가요?
원문 기준으로는 20개가 승인됐고, 별도로 20개가 심사 대기 중이었다.
86개는 이미 만든 건가요, 앞으로 만들 건가요?
원문은 86개를 제출 예정이라고 적었다. 아직 제출 전 단계였다는 뜻이다.
$imagegen이 아예 삭제된 상태였나요?
아니다. codex exec 실행 중에는 폴더가 다시 생겼고, 종료 후에만 사라졌다.
이 캐시 문제는 왜 그냥 넘기지 않았나요?
입술로 작업하는 방식에서는 도구 공백이 곧 작업 중단이라 이슈로 남겼다.
이 글의 수치는 지금도 유효한가요?
이 글은 2026년 6월 26일 시점 기록이다. 이후 상황은 달라졌을 수 있다.
다음에는
이날의 기록을 다시 보면, 통념과 실제의 차이는 결국 "무엇을 눈으로 확인했는가"에서 갈렸다. 스킬이 사라졌다는 인상만으로 멈췄다면 재부팅이나 재설치로 시간을 더 썼을 것이다. 하지만 codex exec 실행 중과 종료 후를 직접 대조해봤기 때문에, 캐시 재생성 타이밍이라는 진짜 원인에 닿을 수 있었다.
미리캔버스 쪽 20개 승인, 20개 심사 대기, 86개 제출 예정이라는 숫자도 같은 태도의 결과였다. 되는 것과 안 되는 것을 뭉뚱그리지 않고 상태별로 나눠 적어 두었기 때문에, 다음 제출 작업을 어디서부터 이어가야 할지가 그 자체로 분명해졌다.
다음에 비슷한 상황을 만나면, 증상이 "완전히 없다"인지 "특정 조건에서만 없다"인지부터 구분해볼 생각이다. 이번 캐시 문제처럼 실행 중과 종료 후의 차이를 확인하는 것만으로도, 통념이 만든 잘못된 결론을 피할 수 있었다.
돌이켜보면 이날 작업은 크게 두 갈래였다. 하나는 미리캔버스 디자인허브에 요소를 제출하고 승인 결과를 확인하는 흐름이었고, 다른 하나는 그 작업을 도와주던 도구 자체가 흔들리는 흐름이었다. 두 갈래는 서로 다른 일처럼 보이지만, 실제로는 하나의 작업 세션 안에서 동시에 벌어졌다.
20개 승인, 20개 심사 대기, 86개 제출 예정이라는 세 숫자를 다시 놓고 보면, 전체 작업량 중 아직 완료되지 않은 부분이 절반을 훌쩍 넘는다. 승인된 20개는 이미 끝난 결과지만, 나머지 106개는 앞으로 확인하고 처리해야 할 작업으로 남아 있었다는 뜻이다. 이 비율을 미리 적어 두지 않았다면, 나중에 전체 진행 상황을 다시 짐작으로 채워야 했을 것이다.
캐시 문제 쪽도 마찬가지다. codex exec를 실행할 때만 스킬 폴더가 보이고, 종료 후에는 사라진다는 관찰은 한 번 우연히 맞은 게 아니라 반복 확인을 거친 결과였다. 그 반복 확인이 있었기 때문에 "내 실수"라는 첫 번째 통념과 "스킬이 삭제됐다"는 두 번째 통념을 모두 접고, 캐시 재생성 타이밍이라는 세 번째 설명에 도달할 수 있었다.
이 글을 다시 정리하면서 남기고 싶은 건 결론 하나가 아니라 확인 순서다. 증상을 처음 본 순간의 인상, 그 인상을 뒤집은 재현 확인, 마지막으로 이슈로 남긴 판단까지의 순서를 기록해 두면, 나중에 비슷한 캐시 문제를 다시 만났을 때 같은 순서를 그대로 다시 밟아볼 수 있다.
이 글은 제가 2026-06-26에 스레드에 올리고 직접 겪은 일을, 빠졌던 맥락과 확인 방법까지 더해 다시 쓴 글입니다. 원문은 여기서 볼 수 있습니다 → 원본 스레드 글