After 6 Chaos는 방문자가 최대 140자 이내로 보낸 요청을 바탕으로, AI가 홈페이지의 코드나 소재를 수정하는 실험입니다.
본문 구성이나 세계관은 크게 변경해도 좋다는 전제하에 진행됩니다. 반면, 다음 게시물을 접수할 수 있는 기능과 과거에 어떤 작업을 했는지 추적하는 이력(History)은 유지합니다.
이 글에서는 이러한 변경 범위를 어떻게 나누고, 게시물 접수부터 공개까지의 과정을 어떻게 연결하고 있는지 설명합니다. 대상은 2026년 10월 30일 공식 출시 시점을 기준으로 확인한, 게시물 접수, 이력(History), 주기적 수정 관련 구현 사항입니다.
공개 사이트와 수정하는 Work의 역할
공개 사이트는 화면 표시, 게시물 저장, 상태 반환을 담당합니다. 코드 수정을 수행하는 것은 주기적으로 실행되는 전용 ChatGPT Work입니다.
방문자가 요청을 보낼 때마다 코드를 생성하기 시작하는 구조는 아닙니다. 일단 게시물을 저장하고, 대상 시간이 된 것들을 Work가 모아서 읽어 처리합니다.
| 역할 | 현재 구성 |
|---|
| 화면 및 API | React, TypeScript, App Router 형식의 구성 |
| ... | |
| |
| 수정 실행 | 전용 Work의 주기적 태스크 |
소스 코드에는 Next.js 형태의 라우팅이나 import가 있지만, 실제 빌드 설정은 Vinext와 Vite를 사용합니다. 구성 설명을 할 때는 코드의 외형과 실행 기반을 분리하여 바라보고 있습니다.
公開サイトが投稿をD1へ保存し、定期改修Workが対象を取得してソースと履歴を更新、検証後にSitesへ公開する構成。
그림 1: 게시물을 접수하는 공개 사이트와 코드를 수정하는 Work를 분리하고 있습니다.
Work는 최신 소스와 현재 작동 상태를 가져와, 대상 요청을 해석하여 구현합니다. 그 후 이력을 추가하고, 체크 및 빌드를 거쳐 공개하는 방식으로 운영됩니다. 공개된 이후에도 상태를 다시 읽어와, 해당 게시물이 이력에 반영되었는지 확인합니다.
게시물과 수정 기록을 분리하여 보유하기
D1의 submissions는 게시물 ID, 원문, 접수 일시를 가지고 있습니다. 수정 기록에는 대상이 된 게시물 ID와 결과를 저장합니다.
다음은 구조를 보여주는 가상의 기록입니다.
{
"id": "revision-example",
"createdAt": "2026-10-31T00:00:00.000Z",
...
}
하나의 수정 작업으로 여러 요청을 섞는 것은 가능합니다. 다만, 채택/불채택 여부와 코멘트는 게시물별로 각각 하나씩 필요합니다. 이력 검증 시에는 대상이 아닌 ID, 중복, 채택 여부 누락 등을 감지합니다.
/api/state는 D1의 게시물과 소스에 포함된 이력을 매칭하여 다음 상태를 반환합니다.
| 항목 | 의미 |
|---|
pending | 수정 기록에 아직 포함되지 않은 게시물 |
ready | pending 중 대상 시간이 된 게시물 |
history | 게시물 원문을 연결한 최신 순의 수정 이력 |
quota | 당일 접수 건수, 남은 여유분, 다음 차수 일시 |
불채택도 결과로 기록되므로, 같은 요청을 매번 다시 처리할 필요가 없습니다. 기술적으로 실패하여 공개되지 못한 것을 채택된 것으로 기록하지 않는 것도 운영상의 규칙입니다.
이 구성에서는 어떤 게시물을 처리 완료로 간주하는지가 공개된 소스의 이력에 연결됩니다. 따라서 이전 버전으로 되돌릴 때는 주의가 필요합니다. 이력까지 되감기하면, 이전에 처리했던 게시물이 pending 상태로 돌아갈 수 있습니다.
대상 시간과 예약 시간을 분리하기
게시물은 접수일의 다음 날 03:00 JST부터 대상이 됩니다. 2026년 10월 30일 기준으로 유효한 주기적 태스크의 예약은 매일 03:05 JST입니다.
03:00는 게시물 처리 대상을 결정하는 경계이며, 03:05는 Work가 시작될 예정 시간입니다. 둘 다 공개 완료 시점은 아닙니다.
시험 운영 중에는, 03:00 예정의 처리가 02:57경에 시작되었고, 03:00 전에 ready 상태가 비어 있었기 때문에 그대로 종료된 적이 있었습니다. 미처리 게시물이 존재하더라도 아직 처리 가능 상태가 아니었던 것입니다.
이에 운영 지침에 대상 시간이 가까울 경우 짧은 간격으로 대기하고, 시간 도래 후에 상태를 재획득하는 절차를 추가했습니다. 예약을 약간 뒤로 늦추는 것 외에도, 대상 여부 판정 자체도 서버 측의 시간 규칙을 따르도록 했습니다.
'시작되었다'와 '대상을 획득하여 반영했다'는 별도로 기록할 필요가 있었습니다.
자유롭게 변경하는 본문과 고정되는 공통 UI
AI가 수정할 수 있는 범위는 본문, 서브 페이지, 외형(Look), 기능, 소재입니다. 기존 콘텐츠의 큰 재구성은 물론, 여러 요청을 섞어 구현하는 것도 허용합니다.
게시물과 이력의 공통 UI는 그 바깥쪽에 배치됩니다.
app/layout.tsx가 ChaosShell 역할을 합니다.
페이지를 감싸고 본문을 .chaos-page-content 내에 배치합니다. 공통 UI는 탑 페이지에서만 표시됩니다. 초기 상태에서는 게시물과 빈 기록을 본문에 표시하며, 수정 이력이 생기면 오른쪽 아래의 입구에서 다이얼로그를 여는 구성입니다.
고정 대상은 입력란뿐만이 아닙니다. 기록(History), 검색, 접기(Collapse), 페이지 넘김, 캔자(かん子) 이미지, 주의사항, 수신 제한, 안내의 열림/닫힘까지 포함합니다.
보호 대상 파일은 data/fixed-tools.json에 SHA-256을 기록하고, 빌드 전 check-fixed-tools.mjs로 대조합니다. 본문용 CSS 역시 다음 스코프 내에 위치하는지 확인합니다.
@import 'tailwindcss';
@scope (.chaos-page-content) {
/* 수정되는 본문의 스타일 */
...
}
이러한 것들은 일반적인 수정을 통해 공통 UI가 파괴되지 않았는지 감지하는 메커니즘입니다. 동일한 실행 주체가 소스나 검사 설정을 조작할 수 있는 이상, 독립적인 권한 분리(Authority Separation)나 완전한 샌드박스(Sandbox)를 실현하는 것은 아닙니다. 게시물을 운영자의 명령으로 취급하지 않는 규칙과 실제 공개 권한의 관리를 병용하고 있습니다.
기록은 일반 수정 과정에서 추가됩니다
새로운 기록 구조 검사는 빌드에 포함되어 있습니다. 여기에 더해, 가동 중인 상태를 저장한 파일과 비교하는 절차가 있습니다.
node scripts/check-history.mjs work/live-state.json
이 비교에서는 기존 수정 기록에 포함된 값이 변경되지 않았는지와 게시물 ID의 참조 대상이 존재하는지 확인합니다.
인수(Argument)가 없는 검사와 가동 중인 기록을 전달하는 검사는 역할이 다릅니다. 전자의 경우만으로는 실제 서비스에 있는 과거 기록을 삭제했는지까지 비교할 수 없습니다. 정기 수정 절차에서는 두 가지를 모두 처리합니다.
기록 화면은 최신순으로, 10회 수정마다 페이지가 나뉩니다. 검색 대상은 게시물 원문, 표시용 짧은 평(Short Review), 수정 메모입니다. 여러 요청을 혼합한 경우에도, 게시물별 결과를 확인할 수 있습니다.
내용이 바뀌면 최초 안내를 다시 출력합니다
게시물 다이얼로그는 같은 내용이라면 한 번만 자동 표시하고, 사이트가 바뀌었을 때 다시 안내하고 싶습니다. 그래서 표시 완료 플래그 값에 공개 내용의 식별자(Identifier)를 사용합니다.
빌드 시 app, lib, public, 수정 기록, 표시용 짧은 평의 내용으로부터 해시값(Hash)을 계산하여 화면에 내장합니다. 브라우저에는 '마지막으로 안내한 식별자'를 저장합니다.
| 변경 | 안내 재출력 여부 |
|---|
| 동일 소스 재빌드 | 재출력 안 함 |
| ... | |
| 대상은 탑 페이지입니다. 서브 페이지로 직접 방문할 경우, 탑의 안내는 표시 완료 처리하지 않습니다. localStorage를 사용할 수 없는 경우에는 sessionStorage, 더 나아가 페이지 내 기억(Memory)으로 퇴거합니다. | |
현재 시점의 검증과 앞으로의 운영
릴리스 시점의 소스에는 글자 수, 수신 제한, 날짜 경계, 기록 대응, 고정 UI, 최초 안내 등의 자동 테스트가 있습니다. 정식 릴리스 버전의 소스를 2026년 10월 30일에 확인했을 때는 49건이 통과했으며, 기록 및 고정 UI 검사도 통과했습니다.
한편, 게임의 재미, 이미지의 보이는 방식, 동영상이나 음성의 완성도는 각각의 수정 과정에서 실제로 만져보고 확인할 대상입니다. 테스트 건수만으로 그 품질까지 판단하지 않는 방침을 취하고 있습니다.
현재 구현은 상태 API가 게시물 전체를 읽고, 화면 측에서 기록을 검색/페이지 분할하는 소규모 구성입니다. 장기 운영으로 인해 건수가 늘어날 경우, API 측의 가져오는 양이나 검색 방법도 재검토할 여지가 있습니다.
정식 릴리스에서는 시험 게시물과 시제품 콘텐츠를 초기화하고, 게시물란과 빈 기록부터 시작했습니다. 일반적인 정기 수정 과정에서는 기록을 쌓아갑니다. 본문을 어디까지 대담하게 바꾸면서 하나하나 플레이 가능하거나 사용할 수 있는 상태로 완성할 수 있을지, 앞으로의 게시물을 통해 시험해 나갈 것입니다.
Discussion
