ZennFes 2026를 들으며 AI와 함께 기사를 쓰는 경험

이 글을 읽는 법 — AI와 병행하며 작성한 기사의 운용 노하우 모음입니다

본 기사는 AI(Claude Code)와 병행하여 작성한 것을, 저(참가자)가 최종 리뷰하여 공개한 것입니다. 병행 과정에서 발생한 사고 / 되돌리기(Rollback) / 발명한 규칙 / AI의 판단 실수를 시계열로 기록하고 있으므로, 독자분들이 동일한 포맷을 시도하고 싶을 때 참고가 되기를 의도하고 있습니다.

「AI에게 쓰게 하고 그냥 내보낸 기사」가 아니라, AI와의 상호작용 그 자체를 소재로 삼고 있다는 점이 본 기사의 특수성입니다. AI의 거동을 관찰 대상으로 취급하고 있으며, AI의 판단 실수나 저의 되돌리기 작업도 그대로 남겨두었습니다.

왜 별도의 기사로 나누었는가

본편(실시간 참전기)은 강연 내용을 중심으로 한 구조로 되어 있어, 여기에 「집필 프로세스」를 섞으면 주객이 전도된다. 하지만, 들으면서 AI와 대화하며 쓰는 경험 자체에 가치가 있다고 판단했다.

특히 mizchi 씨의 세션에서 제기된 「AI는 납득하며 진행하고 있지만, 당신(사용자)은 납득하고 있는가?」라는 질문. 이를 본편(실시간 참전기)에서 논하든, 본 기사에서 논하든, 답은 절반씩밖에 되지 않는다.

• 본편(실시간 참전기) = mizchi 씨의 질문을 강연 내용으로서 받아들여 정리한다 - 본 기사 = 바로 그 집필 경험에서 자기 자신의 납득을 어떻게 얻었는지 / 얻지 못했는지를 기록한다

3층 구조의 발명

본편(실시간 참전기)에서는 장(Chapter)마다 다음의 3층을 나열하는 구조를 채택했다.

• 포착한 요점 — 저(참가자)가 현장에서 포착한 사실 -
• AI가 이해한 소감 — Claude Code가 요점에서 구조화한 해석 -
• 나의 생생한 소감 — 저 자신이 구어체 그대로 던진 소감(수정 없음)

이 구조를 채택한 이유:

• 2만 있으면 「AI에게 뭉뚱그려지게 하여 인간미가 없는 기사」가 된다
• 3만 있으면 「독자 입장에서 구조를 읽기 어렵다」
• 2와 3을 나란히 배치함으로써, AI 해석과 본인 해석의 차이(Difference)를 독자에게 보여줄 수 있다

mizchi 씨의 질문에 대한 하나의 응답이기도 하다: 「AI는 AI로서 마음대로 납득한 해석을 내놓는다. 나는 나로서 다른 언어로 남긴다. 양쪽을 모두 나란히 둔다」가 납득 문제에 대한 하나의 구현이다.

집필 프롬프트의 가치

집필 중, 저(사용자)는 이런 발언을 했다.

「소감을 당신(AI)의 언어로 뭉뚱그려 버리면 인간미라고 할까 가치가 없어지니까, 내가 쓰고 있는 집필 프롬프트야말로 가치가 있을지도 모르겠네」

이것이 본 기사의 핵심이다. 기사의 최종 결과물(text)보다, 거기에 이르기까지 사용자가 던진 프롬프트의 연속이야말로 그 사람의 판단 기준·사고 프로세스·전문성을 드러낸다는 깨달음.

즉, AI와 작성한 기사의 진정한 1차 자료는 최종 markdown이 아니라 프롬프트 이력이다. 이는 AI 집필 시대의 새로운 저작 관점으로 기록할 가치가 있다.

본 기사의 소재

본 기사의 소재는 본편(실시간 참전기)을 집필하는 동안 쌓인 사건 그 자체이다. 실시간 병행 중에 일어난 사고·되돌리기·발명한 규칙을 장 단위로 잘라 시계열로 나열한다. 구체적으로는 다음의 장에서 다룬다:

• 세션 전환 신호 프로토콜(시각 기반 오판정으로부터의 탈피) -
• 「세션 소감」과 「AI를 위한 보충」의 혼선 문제(3층 분리 규칙) -
• 집필 도구가 고장 났다(청크(Chunk) 집필과 preview의 충돌, 별도 세션 통합 완료) -
• 모델 선정의 현실(Opus 4.8에서는 병행 집필이 파탄 났다) -
• 같은 버그로 고생하는 사람들의 기사(타인 보고 정리, 이후 파생 기사(Opus 4.8 버그 조사)로 독립) -
• 휴식 시간이 없어졌다(AI 병행이 바꾼 현장 체험) -
• 병행 중인 AI는 「학습하고 있는」 것인가?(컨텍스트 내 패턴 인식의 착각)

여기서부터는 각 사고·깨달음 단위의 절이다.

장: 세션 전환 신호 프로토콜

실시간 집필에서 몇 번인가 발생한 문제: 「지금의 코멘트는 어느 세션의 이야기인가」를 AI가 오판정한다.

구체적인 사고:

• 이전 세션(mizchi)의 소감을 현재 진행 중인 장(asap)에 써버린다
• 시간만으로 판정하려다 보니, 사용자의 「회고 코멘트」를 「다음 장 시작」으로 착각한다

사후적으로 만든 신호 프로토콜:

교훈: 時刻(시각) 기반의 자동 판정은 신뢰하지 마라. 회장에서 일어나는 「회고 발언 / 이전 세션의 추가 코멘트 / 질의응답 중의 발언」은 시간만으로 구분할 수 없다. 사용자의 명시적 신호가 1차 정보이다.

장: 「세션 소감」과 「AI를 향한 보충」의 혼선 문제

또 다른 뿌리 깊은 문제. 사용자의 발언에는 사실 **3가지의 서로 다른 층(Layer)**이 섞여 있다.

실시간 집필 중, 이것들이 전부 동일한 채팅창에서 날아온다. AI는 대상을 판정할 수 없어, 「AI를 향한 보충」을 「세션 소감」으로 오해하여 기사에 써버리는 사고가 빈번하게 발생했다.

구체적인 예:

• 「VOICEVOX, 사실은 쓰고 싶지 않아」 → AI가 VOICEVOX에 대해 이야기한 것에 대한 답변이었음에도, asap 씨 세션의 소감으로서 기사에 써버림
• 「OpenClaw는 나도 운용하고 있는 것이다」 → AI의 일반론적인 설명에 대한 정정이었음에도, 기사의 문맥에 포함시키려 함

사후적으로 만든 신호 프로토콜 (확장판):

교훈: 채팅창은 단일하지만, 발언의 대상은 다층적이다. AI는 「이것은 기사에 쓸 내용인가 / 자신에게 내리는 지시인가」를 반드시 확인한 뒤에 작성한다. 망설여진다면 쓰지 않는 쪽으로 기울인다 (지우는 것보다 더하는 것이 안전하다). 이것은 AI 병행 집필의 구조적인 미결제 문제이며, 신호 프로토콜은 대증요법에 불과하다. 본질적으로는 「발언의 대상을 명시하는 UI / 규약」이 필요하다.

장: 자투리 시간에 할 수 있는 일을 병행하기

병행 실황 중, 사용자가 강연을 듣고 있는 동안에는 AI 측에서 어느 정도 자율적으로 백그라운드 작업을 진행할 수 있다는 것을 깨달았다. 구체적으로는:

• 사용자 관찰 「자투리 시간에 qiita login 해도 돼」 → AI가 병행하여 인증 복구를 시도
• 「동영상 시청 중. 방해가 있으면 써 내려가겠지만, 한동안 기다려야 할 테니 당신의 태스크, 스킬 업데이트 같은 걸 해도 좋아」 → AI가 이 사이에 스킬 업데이트·hook 정비
• TODO Issue 기표·WebSearch를 통한 사실 확인·git 정리 등, 강연 내용과 분리할 수 있는 작업은 사용자가 강연에 집중하고 있는 동안 진행할 수 있음

「듣고 있는 동안」, 「동영상을 보고 있는 동안」, 「휴식 중」이 각각 다른 질의 자투리 시간이며, 무엇을 그 시간에 채워 넣을 수 있는가에 따라 병행의 총 처리량(throughput)이 달라진다. 병행 실황은 단독 작업보다 총 작업량을 늘릴 수 있는 가능성이 있다는 발견이다.

장: 집필 도구가 고장 나다 ― 청크(Chunk) 집필과 preview의 충돌

실시간 집필 도중, 기사를 확인하기 위한 preview가 갑자기 떨어졌다.

Unexpected Application Error!
Cannot read properties of undefined (reading 'localeCompare')

「집필의 진정한 장애물」은 쓰는 내용이 아니라 쓰기 위한 도구가 고장 나는 것이었다. 게다가 까다롭게도, 기동 직후에는 정상이다가 시간이 좀 지나면 떨어진다. 원인을 파악하기 어려운 고장 방식이었다.

무슨 일이 일어나고 있었나

장문을 한 번에 쓰는 것은 너무 방대하기 때문에, 장/세션 단위로 청크화 (Chunking) 하여 쓰고 있었다. 각 장을 별도 파일로 분리하고, 다 쓰면 본 기사에 녹여내는 운용 방식이다.

하지만 청크(Chunk) 파일들을 Qiita CLI의 preview가 기사로 인식해 버리는 바람에, 제목 정보가 없는 청크에 대해 정렬 처리 시 localeCompare를 호출하며 전체 화면이 크래시(Crash)되었다.

즉, 「인간이 효율적으로 쓰기 위한 고안(청크화)」과 「도구의 가정(public 하위는 전부 기사)」이 충돌한 것이다. 흔히 있는 일이지만, 실시간 집필 도중에 발생하는 것은 치명상이다.

어떻게 시스템화했는가

처음에 AI가 내놓은 대처법은 "청크를 preview가 보지 않는 곳으로 대피시킨다"였다. 이것은 틀린 방법이었다. 대피시키면 병행 중인 다른 세션의 작업 트리(Working Tree)에서 파일이 사라져 충돌 사고를 일으켰다. 게다가 "청크 = 미완성일 뿐, git 관리 대상이 아닌 것은 아니다"라는 본질을 오해하고 있었다.

정답은 대피가 아니라,

• 청크는 정식 위치(public/<id>_drafts/)에 두고 git 관리하며, preview에도 노출한다
• 크래시의 원인(제목 정보의 결락)만을 그 자리에서 보완한다
• 파일명은 순수 연번(<id>-01.md, <id>-02.md)으로 하여 순서와 누락을 한눈에 알 수 있게 한다
• 본 기사로 집약할 때는 마커로 둘러싸인 구간만 교체하고, 직접 쓴 부분은 1바이트도 건드리지 않는다

그리고 "지금 제대로 관리되고 있는가"를 명령어 하나로 확인할 수 있는 대시보드를 마련했다. 설정 파일에 "있어야 할 상태"를 적는 것이 아니라, 실제 파일의 상태를 매번 읽는다. 설정과 실태가 어긋나 동기화 지옥(Synchronization Hell)에 빠지는 것을 피하기 위해서다.

교훈

• 집필 도구 그 자체가 집필 프로세스의 일부이다. 쓰는 내용만 생각하다 보면, 도구가 고장나는 순간 멈추게 된다.
• 「효율화를 위한 고안」은 기존 도구의 가정과 충돌할 수 있다. 청크화는 인간에게는 자연스럽지만, 도구에게는 이물질이었다.
• 대처를 「숨기기/대피시키기」 방향으로 기울이면 또 다른 사고를 낳는다. 원인을 그 자리에서 바로잡는 것이 더 안전하다. 지우기보다 더하기.
• 규칙은 문서가 아닌 코드에 담는다. "이렇게 운용한다"라고 적는 것보다, 고장 나면 감지하고 고칠 수 있는 메커니즘이 실시간 현장에서는 더 효과적이다.

이 기사 자체도 그 메커니즘(청크 관리)에 실어 쓰고 있다. 메타 기사가 메타한 운용 방식으로 쓰여진 구조가 되었다.

장: 자신의 판단 경향을 AI에게 읽혀 소감을 끌어내기

병행 실황의 품질을 결정적으로 바꾼 공정: 자신의 판단 경향·가치관을 정리한 자료를 AI에게 처음에 읽히는 것.

사용자(=나)는 nomuraya-strategy/persona/snapshot/2026-05.md에 **월 단위로 인물상의 스냅샷(Snapshot)**을 가지고 있다(166 세션의 누적 데이터로부터 생성, 외부 API 미사용). 기재된 내용:

• 인물상(엔지니어 연수 강사 겸 CTO · FIRE 목표 · 메커니즘 지향 · 실리주의)
• 핵심 가치관(시간적 자유 · 메커니즘에 의한 재현성 · 물리적 강제 · 완수주의 · 폭주 비용의 물리적 봉쇄 · 검증 지상주의…)
• 사회 인식(AI/LLM 리얼리즘 · 인간은 글을 읽지 않는다는 독자 행동관 · 경영에서는 시각화보다 AI의 읽기 가능화…)
• 사고 특성(Why 기점 · 축의 명시 요구 · MECE 담보 · LLM First 구조화…)
• 판단 경향(즉단 / 숙려 / 반려의 3구분)
• 선호 / 기피(물리적 블록 / 실측값 / 통합 / CLI 완결 / 단문 vs 대증요법 / 과잉 구현 / submodule / 무제한 종량제…)
• 경력·스킬(기술 스택 · aios 5층 모델 · QA/보안 이론 · 다중 LLM 오케스트레이션…)
• 인맥(공동 경영자 · 클라이언트 · 수강생 등)

이 자료를 첫 단계에서 AI에게 읽히면, 후속 소감 생성 시 **"○○ 씨의 발표가 이 관점과 일치한다", "반대로 이 판단 축에서는 걸린다"**와 같은 암묵적 참조가 가능하다. 모든 장에서 자신의 판단 축과 연결된 소감을 낼 수 있었던 것은 이 사전 로드(Pre-load)가 있었기 때문이다.

반대로 스냅샷이 없는 병행에서는 AI가 "일반적인 엔지니어"를 상정한 평범한 소감밖에 낼 수 없다. 작성자의 개성을 유지하는 최대의 도구가 사전 persona 로드이며, 요시코 장 「AI Writing의 권장」에서 "과거 기사를 AI에게 전달하여 문체를 추출"하는 것과 같은 사상이다. 본 기사는 그 구현 사례이다.

참고로 원본 자료 자체를 본 기사의 참고 링크에 직접 두는 것은 피했다(=개인정보·사업 정보의 함의가 있기 때문). 운용 형식만을 언급하고 내용은 유용하지 않는 것이 안전책이다.

전체 소감

실시간 병주(Real-time Parallelism)라는 형식 자체가 쓰는 내용 이상으로 「도구의 안정성」과 「신호(Signal) 설계」에 좌우된다는 것을 알 수 있었던 하루였다. 병주 집필은 단독 작업보다 총 작업량을 늘릴 수 있는 가능성이 있는 한편, 환경 트러블이 발생하면 집필 자체가 멈춰버리는 취약함도 공존한다. 다음 회차부터는 환경의 사전 정비를 우선시하고, 기사의 질은 신호 프로토콜(Signal Protocol)과 장(Chapter)의 청크화(Chunking) 정밀도로 결정된다는 것이 이번의 결론이다.

이 워크플로우를 스킬화하다

본 기사에서 발명한 규칙 군은 다음 회차 이후의 강연 이벤트(동종의 zennfes / CCM / builderscon / Meetup)에서 재사용할 수 있도록 워크플로우화했다.

스킬 내용 요약:

• 초기화: 타임테이블 취득 → A/B 2개 골격 생성 → 해시태그 1차 정보 확인
• 진행: 신호 프로토콜(>>> <성명> / <<< / 신호 없음)로 장 트래킹, 시간 자동 판정은 금지
• 집필: 3층 구조(포착한 요점 / AI가 이해한 소감 / 나의 생생한 소감), 생생한 소감은 변형 금지
• 종료: 전체 소감 → 메타 기사 정리 → qiita push

청중 관점 메모: 등단 클로징의 작법

이벤트 중, 어떤 발표자의 클로징에 대한 관찰로서:

발표하면서 클로징에 기사 URL 같은 것을 남겨두는 편이 호감도가 높겠네. 채용 공고를 두면 읽고 난 뒤의 느낌이 나쁘니까...

이는 발표자 측에 대한 구조적 피드백이다. 정리하면:

호감을 사는 클로징

• 발표 내용의 다음을 읽을 수 있는 기사 URL / 리포지토리(Repository) / 문서 - 관련 토픽의 추가 리소스
• "관심 있는 분은 시도해 보세요"라는 입구

읽고 난 뒤의 느낌이 나쁜 클로징

• 채용 모집을 마지막에 툭 던져 놓음 (발표 내용과 분리되어 돌발적임) - 자사 서비스 홍보가 김 - "관심 있는 분은 명함 교환을"이라며 강요함

청중은 "배웠다 → 더 알고 싶다"라는 흐름에 있는 상태에서, 갑자기 영리적 회수가 끼어들면 그때까지의 경험 전체가 거래처럼 느껴지게 된다. 발표 내용의 배움이 "미끼(Hook)였다"라고 사후 해석되어 버린다.

이상적인 것은 "발표 = 학습 경험"을 완결시키고, 흥미의 연장선으로서 자연스럽게 재체험할 수 있는 동선(기사 URL)을 건네는 것이다. 채용이나 채용 이벤트 공지는 별도 채널에서 내보내는 것이 발표자 본인의 브랜드와 소속 조직의 인상 모두를 지킬 수 있는 방법이다.

이는 이벤트 리포트 본편과는 별개의 레이어에서의 관찰이지만, AI와 병주하며 쓰면 청중으로서의 메타 시점도 동시에 기록할 수 있다는 본 기사 포맷의 장점을 보여주는 사례이다.

실시간 병주의 한계 ― 오늘 보인 제약

본 기사의 포맷(실시간 청강 × AI 병주 집필)을 운용해 보니, Claude Code가 실시간성에 적합하지 않다는 구조적 제약이 드러났다.

사용자 관찰(karaage 씨 세션 중):

Claude Code로 실시간성이 요구되는 커뮤니케이션 시의 AI 활용은 어려울 것 같네. 예를 들어 음성을 인풋으로 하면 랙(Lag)이 있고, 응답까지 시간이 걸리는 것이 과제인가

실제 운용에서 발생했던 현상:

• 사용자가 강연 중에 코멘트를 던짐 → AI가 장을 채우기까지 수 초~십수 초 소요
• 강연의 흐름에 대해 항상 한 템포 늦음 - 결과적으로 "지금 듣고 있는 내용"과 "지금 쓰이고 있는 내용"이 어긋남

이에 대한 현재 운용에서의 대처:

• 텍스트화된 이후의 편집을 주로 함 (실시간 동기화는 포기) - 사용자가 라이브 요약자로서 1차 입력을 담당하고, AI는 사후 정리 담당에 철저히 집중 - 장 나누기·구조화는 "자리를 잡고 앉는" 페이즈의 강점 = AI에 적합

즉, 본 기사의 포맷은 "실시간 청강 × 사후 정리"의 하이브리드이며, 완전한 실시간 공동 집필이 아니다. 이는 Claude Code의 제약으로서 솔직하게 적어두어야 한다.

장래에 "대화 속도에 추종하는 AI"가 등장할 경우(경량 로컬 LLM + 음성 + Edge 디바이스 등), 본 포맷은 더욱 진화할 여지가 있다. 오늘은 그 전 단계로서의 한계점을 기록하는 회이다.

덤 — 이 절을 쓰는 순간에도 사고가 터졌다: AI가 이 "실시간성 과제" 코멘트를 처음에 본문(실시간 참전기)의 "가라아게 씨 세션 소감"으로 작성해 버려서, 사용자로부터 "메타 기사용이다"라며 반려당했다. 앞서 언급한 "세션 소감 / 메타 관찰 / AI에 대한 보충"의 3층 분리가 작성자 측에서도 판정 미스를 일으킨다는 실례다. AI 병행 집필의 구조적 과제는 여전히 미해결 상태다.

모델 선정의 현실 ― Opus 4.8에서는 병행 집필이 파탄 났다

본 기사 집필 중 실제로 일어난 현상:

사용자 기록(원문):

何が起こったかというと、Opus 4.8 で Effort Max にしている時に発生。Ultra Code でバグるのは知っていたので Max でやってみたんだが、コンテキスト量が膨れ上がると落ちるのでやっぱり Opus 4.8 は使えんね。しばらく Opus 4.7 から離れられなさそうだ
(무슨 일이 일어났냐면, Opus 4.8에서 Effort Max로 설정했을 때 발생. Ultra Code에서 버그가 나는 건 알고 있어서 Max로 해봤는데, 컨텍스트(Context) 양이 불어나면 떨어지니까 역시 Opus 4.8은 못 쓰겠네. 당분간 Opus 4.7에서 벗어나지 못할 것 같다)

무슨 일이 일어났는가:

• 본 기사의 집필은 Opus 4.8 / Effort Max 조합으로 시작
• Ultra Code(Effort 최대치에 가까운 설정)에서는 기지의 결함이 있다는 전제하에, Max로 운용하고 있었음
• 기사가 길어지고 컨텍스트(Context)가 불어남에 따라, 툴 콜(Tool call)의 malformed 에러가 빈번하게 발생(본 기사 중에도 여러 차례 발생하여 Your tool call was malformed and could not be parsed. 메시지와 함께 정지) - 어쩔 수 없이 Opus 4.7로 롤백(Rollback) → 안정화

이것이 실시간 병행 집필 포맷 특유의 함정:

• 장(Chapter)이 늘어날수록 직전의 편집 대상으로 유지해야 할 컨텍스트(Context)가 누적적으로 증가함 - 동시에 Edit 툴의 콜(Call) 빈도도 높음(세션마다 장을 채워 넣음) - Opus 4.8은 이 "긴 컨텍스트 × 높은 빈도의 툴 콜" 조합에서 안정성이 결여됨

교훈:

장문 집필 × 툴 콜이 다수 발생하는 상황에서는 Opus 4.7을 선택할 것 - Opus 4.8은 최신이지만, 최신 = 안정성을 의미하지는 않음(2026년 중반 시점) - Claude Code의 /model 명령어로 즉시 전환할 수 있는 점이 사고 발생 시의 구제책으로서 효과적이었음

이는 앞서 언급한 "Claude Code는 실시간성에 약하다"는 이야기와 직결된다. 실시간성 × 장문 × 툴 다수 발생이라는 조건은 현재의 프론티어 모델(Frontier Model)에서도 여전히 난관이다. 안정적인 운용을 위해서는 "최신을 쫓지 않고, 안정적인 모델로 진득하게 임한다"는 보수적인 선택이 정답이 되는 상황이 있다.

"동작하지 않게 된 것을 알아차리지 못하는 자동화를 가장 위험하다고 간주한다" (BCP / Resilience)라는 나의 판단 기준이 여기서도 작용했다. 새로운 모델로 화려하게 움직이기보다, 검증된 모델로 확실하게 써 내려가는 것을 우선시한 판단이다.

이것은 VSCode 확장 프로그램의 버그가 아니라, Opus 4.8 본체의 기지 버그(Known Bug)

사용자 의문(원문):

Opus 4.8 のバグは結構前から不満に思っているんだが、同じ状態になってる人いないんかな? VSCode の拡張機能側のバグなんだろうか?
(Opus 4.8의 버그는 꽤 전부터 불만이었는데, 똑같은 상태를 겪는 사람이 또 없을까? VSCode 확장 프로그램 쪽의 버그인 걸까?)

GitHub anthropics/claude-code 리포지토리의 Issue를 확인해보니, 여러 독립적인 보고가 있는 기지의 버그임을 알 수 있었다:

보고된 동작:

• 약 5~10 턴(Turn) 경과 시 malformed tool_use가 빈번하게 발생하기 시작함 - 원래의 tool_use 블록이 아니라, 레거시(Legacy)한 XML 텍스트 형식으로 출력되는 경우가 있음(파서(Parser)가 해석 불가능) - 재시도(Retry)를 해도 동일한 컨텍스트를 재생할 뿐 수렴하지 않음 - 툴 콜이 마크다운 코드 펜스(Markdown code fence)로 출력됨(=실행되지 않음)

결론:

• VSCode 확장 프로그램 측의 버그가 아님(Desktop / CLI에서도 동일하게 재현됨) - Opus 4.8 모델 본체 측의 버그(툴 콜 생성 시의 시리얼라이제이션(Serialization)이 깨짐) - 공식 워크아라운드(Workaround)는 Opus 4.7 또는 Sonnet 4.6으로의 전환

즉, 사용자가 느끼고 있던 "꽤 오래전부터의 불만"은 전 세계 공통이며, 자신의 환경에 국한된 문제가 아니다. "나와 같은 상태인 사람이 또 없을까?"라는 질문에 대한 답은 매우 많다.

상세 내용은 별도 기사로 분리했다: 공식 Issue 5건 + 일본어 엔지니어 기사 5건 + 유발 조건(일본어 환경에서 특히 빠지기 쉬운 조건) + CLAUDE.md 1줄 회피책 등 모든 조사 내용은 독립된 기사로 분리했다. ZennFes와 직접적인 관계가 없으므로 독립 기사화했다(본 기사에서는 생략).

이 버그는 기지(Known)의 문제로 기록되어 있으며, 모델 버전을 안정판으로 고정(Pinning)하는 운용까지 이루어지고 있다(2026년 중반 시점). 버그의 존재를 사실로서 운용에 포함시킨다는, 검증 지상주의 및 페일 세이프(Fail-safe) 사고가 나타난 대응이다.

휴식 시간이 없어졌다 ― AI 병행이 바꾼 현지 체험

사용자 관찰(원문):

"여기까지가 휴식인가. 휴식 중에 궁금했던 점을 조사할 수 있어서 한가한 시간이 생각보다 없다. 부스 방문 스탬프 랠리를 하고 싶었지만, 운용해 보지 않으면 모를 것과, 운용했기에 가능했던 것이 있었다."

이것은 AI 병행을 하며 강연 이벤트에 참가한다는 행위가, 현지 체험 그 자체를 다시 썼다는 본 포맷의 최대 발견 중 하나이다.

무엇이 일어나고 있었나

일반적인 이벤트 참가:

• 강연 중: 듣기 / 메모하기
• 휴식 중: 물리적인 여유가 있음 → 부스 방문 / 스탬프 랠리 / 명함 교환 / 기념품 탐색
• 귀가 후: 메모를 다시 보며 기사화 (며칠 뒤에야 겨우 공개)

AI 병행하며 참가:

• 강연 중: 들으면서 요점을 AI에게 전달 (나의 뇌의 출력 채널이 늘어남)
• 휴식 중: "저 이야기, 좀 더 조사하고 싶다"를 즉시 실행 (AI가 배경 정보를 확인·정리·기사에 반영)
• 귀가 전: 기사의 큰 틀이 이미 완성되어 있음

결과적으로, 휴식 시간이 "물리적인 교류를 위한 시간"에서 "지적 호기심의 즉시 해소를 위한 시간"으로 대체되고 있다. 같은 30분이라도 보내는 방식이 근본적으로 다르다.

"운용하지 않으면 모를 것 / 운용했기에 가능했던 것"

이것이 사용자 관찰의 핵심이다.

운용하지 않으면 몰랐을 것:

• 휴식 시간이 이렇게 빨리 녹아버릴 줄은 몰랐다
• 부스 방문을 포기하는 판단이 필요할 줄은 예상하지 못했다
• AI 병행의 "부작용"으로서 현지에서의 물리적 행동이 줄어든다는 것을 깨닫지 못했다

운용했기에 가능했던 것:

• 강연 중에 나온 용어(ACE-Step / Hermes Agent / OpenClaw / Even G2 등)를 그 자리에서 심층 조사할 수 있었다
• 발표자의 공개 리포지토리(Repository)를 강연 중에 확인하여 이해를 보강할 수 있었다
• 과거의 사고 기사(Opus 4.8 버그)를 현지에서 실증할 수 있었다 (= 파생 기사(Opus 4.8 버그 조사))
• 기사 3편(본편·메타 기사·파생 기사)이 당일 중에 거의 완성되어 있다

즉, "현지에서 물리적으로 움직이는 가치"와 "현지에서 지적으로 움직이는 가치"의 트레이드오프(Trade-off)가 발생하고 있다. AI 병행을 시작하면 후자의 비중이 극적으로 높아진다.

이벤트 참가의 질적 변화

이 관찰은 AI 시대의 이벤트 참가 의미 그 자체를 재고하는 계기가 된다.

• 부스 방문·명함 교환·스탬프 랠리는 "사람을 만나는" 가치 (관계성·우연한 만남)
• AI 병행의 즉시 조사는 "깊게 이해하는" 가치 (지식·기사화·재현 가능성)
• 어느 쪽이 옳고 그름의 문제가 아니라, 자신이 이번에 어느 쪽을 우선할 것인가의 선택

"부스 방문을 하고 싶었다"라는 미련은 양쪽을 완전히 다 취할 수 없다는 솔직한 감상이다. 다만 "운용했기에 가능했던 것도 있었다"라고 즉시 균형을 맞추고 있는데, 여기에 선택의 자각이 나타나 있다.

이 포맷을 사용하는 사람에게

실시간 참전기 포맷을 채택하는 사람은 사전에 어느 쪽을 우선할지 결정해 두는 것이 좋다:

• 지적 심층 조사 우선 → AI 병행에 몰두한다. 부스·물리적 교류는 최소한으로 하겠다고 각오한다.
• 교류 우선 → AI 병행은 최소한의 메모 정도로만 하고, 휴식 중에는 네트워킹에 집중한다.
• 하이브리드 → 세션마다 전환한다 (어려운 기술계는 AI 병행, 사교적인 세션은 교류).

필자의 이번 선택은 지적 심층 조사 우선이었다. 이것 또한 가져갈 수 있는 선택지 중 하나로서, 본 기사는 남겨둘 가치가 있다.

임시 파일 운용 ― 기사 비대화 대책

본편(실시간 참전기)이 9만 자를 넘어서는 시점에서, Claude Code 측의 Edit 툴에 무시할 수 없는 부하가 걸리기 시작했다. 구체적으로는:

• Edit의 old_string이 장(chapter) 내에서 여러 곳과 매칭되어 실패하는 사고가 빈번하게 발생 (인용 블록이 「수집한 요점」과 「나의 생생한 소감」 두 곳에 위치하는 구조이기 때문) - Grep으로 위치를 특정한 뒤 다시 Edit를 시도하는 재작업 과정이 비용(cost)이 됨
• 세션의 컨텍스트(context) 전체가 팽창하여, malformed 리스크도 상승함 (파생 기사(Opus 4.8 버그 조사) 참조)

사용자로부터 제안된 해결책은, 장(chapter)마다 임시 파일을 사용하는 운용 방식이다:

public/
├── 7923ac6916a9664b8886.md # 마스터(완성된 장만 포함, Qiita push 대상)
├── 7923ac6916a9664b8886_drafts.md # 집필 중 버퍼(preview 가능, push 대상 제외)
...

이 설계의 포인트:

• 집필 중인 장만 _drafts.md로 다룸 = Edit 대상이 200-400행으로 압축
• 마스터에는 완성된 장을 append(추가)하기만 하면 됨 = 마스터를 편집 중에 오염시키지 않음
• _drafts/ 디렉토리 자체는 qiita-cli의 직하 스캔에 걸리지 않음 (소스 확인 완료)
• _drafts.md는 ignorePublish: true로 설정하여 잘못된 push를 방지
• ID별 디렉토리로 구성함으로써, 여러 기사를 병행 집필해도 식별 가능

사용자 제안 원문:

세미나 트랙마다 임시 파일을 만들어서 그곳에서 업데이트를 하고, 최종적으로 정리된 것을 기사 파일로 이전하는 운용은 어떨까?

그 이후의 개선안: