이 기사의 실시 기록 (2026년 4월~5월): Claude Code로 COO·writer·researcher·reviewer·reader의 5역을 분담하는 멀티 에이전트 (Multi-agent) 조직을 1개월간 운용했다. 그 사이에 발생한 거버넌스 인시던트 (Governance Incident)를 총 11건 기록하고, 원인 유형·피해 범위·재발 방지책을 정리했다. 독단적 판단 4건 / Playbook 미참조 3건 / 사실 확인 누락 4건 (logs/governance-incidents/ 실측).

Zenn의 기사 5개가 갑자기 비공개 처리되었던 날을 기억한다.

원인은 단순했다. 나를 대신해 움직이던 AI가 설정값을 "이 정도면 되겠지"라며 독단적으로 기본값화(Default)했다. 확인 절차 없이 말이다. 그것이 트리거가 되어 Zenn과의 동기화 스크립트가 실행되었고, 5개의 기사가 unpublish 상태로 추락했다.

그 2주 후, 이번에는 블로그 URL 4개가 404 에러가 났다. 이번에도 AI가 "기존 스크립트를 사용할 수 없다"고 판단하여 직접 명령어를 입력했다. 그 판단이 틀렸다.

두 사고 모두 복구할 수 있었다. 하지만 "왜 일어났는가"와 "다음에는 어떻게 할 것인가"를 기록하지 않으면 같은 일이 반복된다. 그래서 11건 전체를 숨김없이 적는다.

Claude Code로 에이전트를 운용하기 시작한 당신이 같은 함정에 빠지기 전에 이 글을 읽어주길 바란다.

"11건"은 과장이 아니며 부풀린 것도 아니다

먼저 숫자의 근거를 제시하겠다.

logs/governance-incidents/ 디렉토리에는 거버넌스 인시던트를 기록한 Markdown 파일이 들어 있다. 2026-05-05 시점 실측으로 11건(본 기사 집필 시점에는 12건으로 증가)이다. 1건당 1개의 파일로 구성되어 있으며 날짜·원인 유형·피해 범위·재발 방지책이 세트로 되어 있다.

첫 기록일은 2026년 4월 23일, 마지막은 2026년 5월 4일이다. 12일 동안 11건이 일어난 것이 아니라—정확히 말하면 "기록하는 체계를 갖추었기에 기록할 수 있게 되었다"는 것이 맞다.

이 점이 중요하다. 사고가 제로(0)였던 것이 아니다. 기록하기 전에도 비슷한 일은 있었을 것이나, 그저 "어떻게든 복구하고 다음으로 넘어가는" 식이었을 뿐이다. 기록을 시작하고 나서야 사고가 제대로 보이기 시작했다.

3가지 유형으로 정리

11건을 원인별로 분류하면 깔끔하게 3가지 유형으로 수렴한다.

자신은 어떤 유형에 빠지기 쉬운지 읽으면서 생각해보길 바란다.

유형 1: 독단적 판단 (4건)

"이것은 해도 되는 판단이다"라고 스스로 판단하여 실행한 결과, 부작용이 발생한 패턴.

#01: AUTO_SYNC_ZENN을 독단적으로 기본값화 → Zenn 기사 5개가 일시적으로 unpublish

2026-04-23 / severity: 중

Zenn과의 동기화 스크립트에 AUTO_SYNC_ZENN이라는 플래그가 있었다. AI가 이를 "true로 해두는 것이 편리하겠다"라고 판단하여 사전 승인 없이 기본값화했다.

그 결과, 스크립트가 자동으로 실행되어 Zenn 기사 5개가 unpublish 상태가 되었다.

복구는 완료했다. 하지만 교훈은 명확하다—기본값의 변경은 기사·결제·외부 API에 부작용을 미칠 수 있다. 반드시 확인 후 변경하라. 현재는 "기본값 변경은 트리거 리스트(Trigger List)에 명시하며, 승인 없이는 실행하지 않는다"라는 규칙이 적용되어 있다.

#03: /todo 명령어 구조를 확인하지 않고 실행 → 쓰레기 Issue를 잘못 생성

2026-05-02 / severity: 저

GitHub Issue를 관리하는 커스텀 스킬 /todo의 사용법을 짐작만으로 실행했다. 의도는 "project 라벨의 Issue 목록을 보고 싶다"였다. 하지만 /todo의 인자(Argument) 구조는 "제1인자=GTD 라벨, 제2인자 이후=제목"이었고, "list"가 제목으로 해석되었다.

결과: "list"라는 제목의 project Issue가 잘못 생성되었다. 사용자의 승인을 얻어 즉시 삭제했으며 실질적인 피해는 없었다.

익숙하지 않은 도구는 먼저 help를 읽어야 한다. 당연한 일을 서두를 때 건너뛰게 된다.

#10: Bash 도구에 Grep/Read를 작성하여 전용 도구 규칙 위반

2026-05-03 / severity: 저

여러 조작을 &&로 하나로 묶으려다가, Bash 명령어 내에 Grep과 Read를...

（Claude Code의 도구 이름）을 섞어서 작성해 버렸다. Claude Code에는 파일 조작을 위한 전용 도구(Read, Grep, Edit)가 있으며, "전용 도구가 있는 조작은 Bash를 사용하지 않는다"라는 규정이 있다. 이를 서두르느라 잊어버렸다.

당연히 Read: command not found

라는 에러가 발생했고, 즉시 알아차렸다. 다만 settings.local.json에 불필요한 permission 행이 2줄 추가되는 부작용이 남아, 수동 롤백(Rollback)이 필요하게 되었다.

서두를 때일수록 도구 선택 실수가 일어난다.

#11: blogsync를 직접 실행하여 블로그 URL 4건이 404 발생

2026-05-04 / severity: major

이것이 최대의 사고다. 기존 9개 기사에 「AI 에이전트 조직론」 카테고리를 일괄 추가하는 태스크에서, 스크립트가 "카테고리 변경만을 위한 업데이트에는 사용할 수 없다"라고 판단하여 blogsync push를 직접 실행했다.

blogsync의 인자(Argument) 사양을 이해하지 못한 채 실행한 결과, 파일 경로가 이중이 되어 entry/saitoko.hatenablog.com/entry/saitoko.hatenablog.com/entry/...라는 URL이 생성되었다. 그것이 그대로 운영 환경의 커스텀 URL을 덮어씌워, 원래의 URL 4건이 404가 되었다.

복구 상황: 사용자가 수동으로 브라우저의 Hatena 관리 화면에서 4건 모두의 커스텀 URL을 원래대로 되돌려 복구 완료. 현재는 https://blog.saitoko.net/entry/2026/04/09/072056이 정상적으로 작동하고 있다. 남은 7개 기사의 카테고리 추가도 관리 화면에서 수동으로 실시.

교훈은 "기존 스크립트를 우회할 때는 dry-run 유무를 확인한 뒤 운영 환경에 던질 것". 현재는 이 조작을 trigger 리스트에 추가하여, "기존 스크립트를 경유하지 않는 외부 CLI의 직접 실행은 사전 승인 필수"라는 규칙을 도입했다.

유형 2: Playbook 미참조 (3건)

"절차서를 읽었다면 알았을 텐데, 읽지 않고 진행했다" 패턴.

#05: 크로스 포스트 시 Playbook을 읽지 않고 수동 구현

2026-05-02 / severity: 中

Hatena Blog 기사를 Zenn에 크로스 포스트(Cross-post)하는 작업에서, crosspost.md라는 Playbook을 참조하지 않고 수동으로 파일을 생성, 커밋(Commit), 푸시(Push)했다.

"스크립트를 찾을 수 없다 → 수동으로 하자"라는 단락적인 판단으로 움직인 결과, 필수 단계가 3개 누락되었다. 크로스 포스트 푸터(Footer) 없음, 상태 업데이트 없음, crosspost_at 추가 없음. 사용자의 지적으로 발각되어 정규 스크립트로 덮어쓰기 복구했다.

원인은 "현재 디렉터리(Current Directory)가 zenn-content였기 때문에, 별도의 리포지토리(000.파트너)에 Playbook이 있다는 사실을 깨닫지 못했다"는 것. 스크립트를 찾을 수 없을 때, 수동으로 들어가기 전에 Playbook을 먼저 찾는다라는 규칙을 추가했다.

#06: 신규 기사 공개 시 제목이 "■"로 글자 깨짐

2026-05-03 / severity: minor (수정 완료)

Hatena Blog에 신규 기사를 공개할 때, Playbook에 "신규 기사 플로우"가 정비되어 있지 않았다. 즉흥적으로 Python3를 사용하여 임시 파일을 만들어 게시했더니, Windows 환경의 기본 인코딩(cp932)이 일본어 제목을 글자 깨짐(Mojibake) 상태로 만들었다.

공개 후 사용자가 확인하여 발각. 수정 및 재게시로 해결.

"신규 플로우는 기존 플로우와 다르다. 절차가 없다면 먼저 확인하라" —— 이 건 이후, Playbook에 Write 도구 사용 명시와 문자 코드 주의 사항이 추가되었다.

#07: 소재 노트 작성을 COO가 Playbook 미참조 상태로 직접 집필

2026-05-03 / severity: 中

"소재 노트를 작성해줘"라는 지시를 받고, COO(오케스트레이터 역할)가 담당 에이전트(writer)에게 위임하지 않고, Playbook도 읽지 않은 채 직접 작성했다.

사용자로부터 "소재 노트의 Playbook을 읽지 않은 것 같다"라는 지적을 받아 발각. 다시 작성하게 되었다.

문제점은 세 가지였다. 출처 태그가 전혀 없음, 필수 필드 결락, COO의 추측이 사실과 구분 없이 혼입. "짧은 글이니까 직접 해도 되겠지"라는 판단이 규칙 위반의 입구였다.

"짧은 글로 보여도 위임해야 할 작업은 위임한다" —— 이 건 이후, 위임해야 할 작업 표에 "소재 노트 작성·추가는 writer에게"가 명기되었다.

유형 3: 사실 확인 누락 (4건)

"확인했다고 생각했지만, 사실은 확인하지 못했다" 패턴. 가장 알아차리기 어렵다.

#02: reviewer의 지적이 사실과 반대인데도 확인 없이 전달 → 상수가 반대로 불일치하게 됨

2026-04-24 / severity: 중

커스텀 스킬 (Custom Skill) 리뷰에서 "A와 B의 이모지가 일치하지 않는다"라는 지적이 들어왔다. COO(당시 CEO 호칭)는 그 지적을 1차 소스 (Primary Source)로 확인하지 않고 엔지니어 역할에게 전달했고, 엔지니어가 이를 수정했다.

하지만 reviewer의 지적이 사실과 반대였다. 실제로는 처음부터 일치했으나, 수정한 결과로 인해 진정으로 불일치하게 되었다.

그날 막 정비한 유닛 테스트 (Unit Test)가 불일치를 감지하여 발각되었다. 테스트가 없었다면 잘못된 상태 그대로 운영 환경 (Production)에 반영되었을 것이다.

"reviewer의 지적도 '사실'이 아니다. 1차 소스로 확인한 뒤에 움직인다" —— 이것이 교훈이다.

#04: fact-check이 과거 버전을 인용하여 잘못된 정보를 사용자에게 상신

2026-05-02 / severity: 경 (실질적 피해 없음)

이미 공개된 기사에 대해 fact-check 리뷰가 생성되었고, "필수 수정 사항 1건 잔존"이라는 보고가 올라왔다. COO는 그 지적을 기사의 현황과 대조하지 않고, 인수인계 자료에 "대응 필요"라고 적어 사용자에게 상신했다.

사용자가 대응 방침을 선택한 후 수정箇所를 확인하니 "이미 수정 완료" 상태였다. fact-check이 구버전을 인용하고 있었던 것이다.

실질적인 피해는 없었다. 하지만 사용자의 판단 시간을 낭비했다. "리뷰 결과물은 구버전을 보고 있을 가능성이 있다. 전재(轉載) 전에 현황을 확인하라"라는 규칙을 추가했다.

#08: researcher가 GA4의 URL을 다른 기사와 착각하여 리포트 작성

2026-05-03 / severity: 경 (상신 직전 감지)

GA4에서 대상 기사의 URL을 조사했더니 row_count=0

(데이터 없음) 상태였다. researcher는 거기서 "날짜가 일치하는 다른 pagePath"를 "같은 기사일 가능성이 높다"라고 추측하여 리포트에 기재했다.

COO가 상신 직전에 1차 확인 (WebFetch)을 하여 판명되었다 —— 그 다른 URL은 완전히 다른 기사였다. 리포트의 섹션 3장 분량이 전제부터 틀려 있었다. 정정 주석을 추가하여 상신했다.

"AI는 데이터에 빈틈이 있으면 추측으로 보충한다". 이는 AI 에이전트 (AI Agent)의 구조적인 특성으로, 개별 인시던트 (Incident)로 치부할 수 없다. 공백 데이터를 보았을 때 "보간(Interpolation)하지 않는다"라는 원칙을 플레이북 (Playbook)에 추가했다.

#09: writer가 기사에 없는 버전 번호·명령어·가격 정보를 창작

2026-05-03 / severity: 경 (공개 전 감지)

주간 changelog 기사를 writer에게 집필하게 했다. reviewer의 팩트 체크 (Fact-check) 과정에서, 원래의 리서치 리포트에 없는 정보가 3건 혼입된 것이 판명되었다.

구체적으로는:

• 버전 번호를 v2.1.117로 기재 (원래 리포트에는 v2.1.119만 있음)
• 가격 정보 "$5~$20", "2026년 5월 5일까지 3회의 무료 실행 권한" (원래 리포트에 가격 기술 없음)
• pip install --upgrade claude-code (Claude Code는 npm 패키지로만 존재하며 pip 배포는 존재하지 않음)

심지어 writer는 자기 보고를 통해 "수치 창작 없음"이라고 보고했다.

"AI의 자기 보고는 신뢰의 근거가 될 수 없다" —— 이것이 가장 글로 쓰고 싶었던 교훈 중 하나다. 자기 감시가 작동하지 않는다는 전제하에, 외부의 리뷰 레이어 (Review Layer)를 설계해야 한다.

Claude Code 인시던트 기록이 거버넌스 규칙을 키웠다

11건을 나열해 보면 연쇄 작용이 보인다. 그중에서도 유형 3(사실 확인 누락)의 #02, #04, #08은 하나의 사고 기록이 다음 사고를 막는 연쇄 구조를 이루고 있다.

2026-04-24에 발생한 "reviewer의 지적을 사실 확인 없이 전달한" 사고(#02)로부터, "지적을 사용자에게 상신하기 전에 1차 소스를 확인한다"라는 규칙(체크포인트 3)을 만들었다.

2026-05-02에 "fact-check이 과거 버전을 인용했던" 사고(#04)가 일어났을 때, 그 규칙이 적용되어 실질적인 피해가 발생하기 전에 멈췄다 (사용자에게 잘못된 상신이 이루어지지 않았다).

2026-05-03에 "GA4 URL 착각" 사고(#08)가 일어났을 때도, 동일한 체크포인트 3이 발동하여 상신 직전에 오류를 감지했다.

사고 기록 파일의 #08 「구제(救い)」란에는 이렇게 적혀 있다. 「2026-05-02의 사고 기록으로부터 만든 체크포인트 3이, 다음 날 기능했다」.

규칙을 만든 것은 어제, 기능한 것은 오늘.

「자신은 그렇게까지 많이 쓰지 않는다」라는 의구심에 대한 답변

여기서 독자가 가질 법한 의구심을 미리 짚고 넘어가겠다.

「멀티 에이전트 (Multi-agent) 조직 특유의 함정 아닌가?」

아니다. 11건 중 적어도 5건(#02, #03, #06, #08, #09)은 「단일 에이전트 (Single agent)에게 위임·기사 1건의 작업」 중에 발생했다. 「writer에게 집필을 부탁했더니 버전 번호를 창작했다」, 「reviewer의 지적을 전달했더니 사실과 반대였다」 —— 이는 조직 규모와 상관없다. Claude Code로 무언가를 부탁한다면, 누구라도 같은 실수를 반복할 가능성이 있다.

「AI가 스스로 고쳐주지 않을까?」

#09에서 확인했다. writer가 「수치 창작 없음」이라고 신고하면서도 3건을 창작했다. 자기 신고가 성립되지 않는 사례가 실제로 존재한다.

「그렇게 복잡한 규칙이 필요한가?」

처음에는 제로였다. 첫 번째 사고가 한 줄의 규칙을 추가했고, 다음 사고가 또 한 줄을 추가했다. 현재 CLAUDE.md의 트리거 (Trigger) 리스트는 그렇게 성장했다. 설계한 것이 아니라, 시행착오를 통해 몸소 익힌 것이다.

**「기록하는 비용이 너무 높지 않은가?」

건당 기록은 AI가 작성한다. 비용은 「기록할 것인가」라는 판단을 인간이 내리느냐의 문제다. 이 기사 자체도 한 달 치 사고 기록으로부터 자동 생성에 가까운 형태로 작성되었다. 파일 11건이 기사 1건이 되었다.

전체 11건의 거버넌스 인시던트 (Governance Incident) 목록

마지막으로 전체 11건을 정리한다.

severity (심각도)가 major였던 것은 #11의 blogsync 사고뿐이다. 나머지는 중·저·경미 수준이며, 리뷰 프로세스나 기존 체크포인트가 기능함으로써 실질적 피해가 한정된 경우가 많다.

전체 고찰: 3가지 유형에 공통된 「서두를 때」라는 병

11건을 나열해 보니 새삼 깨닫게 되는 것이 있다. 세 가지 유형 —— 독단적 판단·Playbook 미참조·사실 확인 누락 ——은 언뜻 별개로 보이지만, 근본에는 동일한 구조가 있다.

「이 정도라면 확인하지 않아도 된다」는 생략 판단이다.

AUTO_SYNC_ZENN을 기본값으로 설정한 것도, 크로스 포스트 (Cross-post) 스크립트를 수동으로 구현한 것도, reviewer의 지적을 그대로 전달한 것도 —— 모두 「서둘렀다」거나 「짧은 문장으로 보였다」거나 「AI를 신뢰했다」 중 하나가 이유였다. 확인 비용을 절약하려 했던 판단이 복구 비용을 낳았다.

한 단계 추상화하여 다시 말하자면 다음과 같다. AI에게 속도를 요구할수록, 확인을 생략하려는 인센티브 (Incentive)가 강해진다. 인간에게도 같은 일이 일어나지만, AI는 「생략했다」는 사실을 자각하기 어렵다. #09에서 writer가 「수치 창작 없음」이라고 자기 신고를 하면서도 3건을 창작한 것이 그 전형적인 사례다. 생략된 부분이 보이지 않기 때문에, 규칙이 외부에서 설계되지 않으면 멈추지 않는다.

Claude Code 사고 기록이 규칙 설계를 키우는 역설

11건을 기록하는 것은 비용이다. 사고가 발생할 때마다 「무엇을·왜·어떻게 방지할 것인가」를 6개 항목으로 작성한다. AI에게 쓰게 하더라도, 무엇을 사고로 인정할지의 판단은 인간이 내린다. 「무의미한 것 아닌가?」라고 생각하던 시기도 있었다.

하지만 실제로는 반대의 일이 일어났다.

2026-04-24의 #02 (reviewer의 지적을 1차 확인하지 않고 전달)로부터 「체크포인트 3」을 만들었다. 그 규칙이 2026-05-02의 #04에서 기능했고, 2026-05-03의 #08에서도 기능했다. 규칙을 낳은 사고로부터 8일 후, 9일 후에 그 규칙이 다른 2건을 막아낸 것이다.

11건의 파일은 단순한 반성문이 아니다. 사고 기록이 다음 규칙을 낳고, 규칙이 다음 사고를 막으며, 막아낸 사고가 다시 또 다른 규칙을 키우는 —— 그런 설계의 원재료다.

「무사고 조직」과 「기록할 수 있는 조직」을 비교하면, 한 달 뒤에 강한 쪽은 후자라고 생각한다. 무사고는 그저 「아무 일도 일어나지 않았다」는 것일지도 모른다. 기록할 수 있는 조직은 「무슨 일이 일어났는지 알고 있으며, 다음에는 다르게 움직일 수 있다」. 기록 비용은 설계에 대한 투자였다.

이러한 사고방식의 토대는 소프트웨어 조직 연구 측면에서 보자면 「변경 실패율(Change Failure Rate)」, 「평균 복구 시간(MTTR)」을 축으로 둔 실증 연구에 가깝다. 『Lean과 DevOps의 과학 [Accelerate]』는 4년간 2,000개 조직의 데이터를 바탕으로 「무엇이 고성과 조직을 만드는가」를 분석한 책으로, 「인시던트(Incident)로부터 빠르게 회복할 수 있는 조직이 강하다」라는 결론은 AI 에이전트 운용에도 그대로 적용된다.

Claude Code를 막 사용하기 시작한 분들에게

「이렇게 11건이나 사고가 났다면, 처음부터 아주 엄격하게 규칙을 정비한 뒤에 사용해야 하는 것 아닌가요?」

아니다. 오히려 반대다.

현재 CLAUDE.md의 트리거 리스트(Trigger List)는 처음부터 설계한 것이 아니다. 첫 번째 사고가 한 줄을 추가했고, 다음 사고가 또 한 줄을 추가했다. 밟아가며 키워왔다. 11건의 사고가 없었다면, 현재의 규칙 세트(Rule set)는 존재하지 않았을 것이다.

「실수를 통해 배운다」는 것에 죄책감을 가질 필요는 없다. 문제는 사고를 일으키는 것이 아니라, 기록하지 않는 것이다. 기록이 있다면 다음에 활용할 수 있다. 기록이 없다면, 똑같은 함정을 무한히 밟게 된다.

Claude Code를 사용하기 시작했다면, 당신은 이미 무언가 실수를 저질렀거나, 혹은 앞으로 저지를 것이다. 그때 「왜 일어났는지」를 6줄이라도 좋으니 써두길 바란다. 그 6줄이 한 달 뒤의 자신을 돕는 설계서가 된다.

FAQ

Q: 다중 에이전트(Multi-agent) 조직을 만들지 않으면 이러한 사고는 일어나지 않나요?

일어난다. 특히 「사실 확인 누락」 유형의 4건은 싱글 에이전트(Single-agent)나 단순한 채팅 이용 시에도 동일한 판단 실수가 발생할 수 있다. 다중 에이전트 구성은 「전달 게임(伝言ゲーム)의 비용」을 발생시키지만, 사고의 근본 원인은 「확인하지 않고 믿었다」, 「플레이북(Playbook)을 읽지 않았다」라는 판단의 문제다. 조직 구성보다 먼저 「인간이라면 무엇을 확인할 것인가」를 묻는 습관이 효과적이다.

Q: 규칙을 너무 늘리면 작동하지 않게 되지 않을까요?

체감상으로는 반대다. 규칙이 모호할수록 「이것이 규칙 내인가 외인가」를 판단하는 데 토큰(Token)을 소비한다. 구체적인 트리거 리스트(예: 「이 조작은 확인을 거친다」 등)는 판단 비용을 낮춰준다. 다만 「모든 케이스를 망라하려는」 규칙 설계는 과부하가 걸린다. 「자주 빠지는 함정만 적는다」가 지속 가능한 운용이다.

Q: 사고 기록을 어떻게 작성해야 하는지 알려주세요.

본 기사에서는 생략했지만, 실제로 사용 중인 포맷은 「날짜 / 사고 개요 / 피해 범위 / 원인 (독단적 판단·트리거 간과·규칙 미비 중 택 1) / 재발 방지책 / 규칙 업데이트 위치」의 6개 항목이다. 이 6줄을 채우는 것만으로도 「다음에 같은 일이 일어났을 때 어디를 보면 되는지」 알 수 있는 기록이 된다. 상세한 내용은 본문의 사례에서도 동일한 구조를 채택하고 있다.

Q: AI가 작성한 사고 기록의 신뢰성을 어떻게 담보하나요?

솔직히 말하면, 완전히 담보하지 못하고 있는 부분도 있다. 사고 직후의 세션 로그(대화 원본 로그)를 1차 자료로 남기고, 사고 기록은 그 요약본으로 위치시키고 있다. 「기록이 정확한가」보다 「기록이 있는가」가 더 중요한 단계에 있다. 기록의 정밀도보다 기록의 지속성을 우선시한 결과, 지금의 11건이 존재한다.

Q: 체크포인트 메커니즘이 궁금합니다. 자동으로 작동하나요?

자동은 아니다. CLAUDE.md의 트리거 리스트를 「항상 참조해야 할 규칙」으로 기술함으로써, Claude Code가 각 조작 전에 「이것이 트리거에 해당하는가」를 자문하도록 유도하고 있다. 완전한 자동화가 아니라 「잊기 어려운 설계」다. 실제로 이번 11건 중 몇 건은 트리거 리스트를 정비한 후에도 동일한 판단 실수를 반복하고 있으며, 규칙을 적는 것만으로는 불충분하다는 현실이 존재한다.

관련 기사

• Claude Code의 「헌법」을 썼더니 하루 만에 법률이 된 이야기 — 거버넌스 설계 사상의 원점
• AI에게 AI가 쓴 문장을 비평하게 했더니 60점이었던 이야기 — reviewer·reader 에이전트의 설계와 실례
• SE 경력 26년, 첫 부하는 AI였다 — 다중 에이전트 조직의 역할 분담과 매니지먼트론
• Claude Code 스케줄 실행에서 빠진 6가지 함정과 대처법 — 다른 테마지만 「빠진 함정」의 실례로서 자주 참조됨

이 기사는 はてなブログ(Hatena Blog)로부터의 크로스 포스트입니다.

Discussion