# 작업 지시서: 외부 개발규칙 vs 아누시스템 개발부 심층 비교분석

## 작업 ID: task-1056.1
## 레벨: Lv.2 (한정승인)
## 팀: dev5-team (마르둑)

## 배경
제이회장님보다 AI 업무능력이 뛰어난 분이 공유한 개발규칙 일부분을 입수함.
이 규칙과 우리 아누시스템 개발부(개발1~7팀 + 8팀 외주)의 현행 규칙을 심층적이고 체계적으로 비교평가하여 배울 점을 찾아야 함.

## 외부 개발규칙 원문 (사진 2장에서 추출)

### [섹션 1] 개발 규칙
> 경고: 개발 규칙을 읽지 않고 개발을 진행하면 안 된다. 경고: 모든 개발은 아래 규칙을 먼저 확인한 뒤 시작해야 한다.

1. 모든 개발은 반드시 문서화를 함께 진행한다.
2. 기능 추가, 구조 변경, 정책 변경, API 변경이 있으면 관련 문서 즉시 갱신한다.
3. 구현은 가능한 한 잘 알려진 소프트웨어 디자인 패턴을 따른다.
4. 임시 로직이나 산발적인 분기 추가보다 역할이 분명한 구조를 우선한다.
5. 공통으로 재사용되는 로직은 중복 복사하지 말고 공통 모듈로 정리한다.
6. 모든 개발은 객체지향적으로 모듈화하는 방향을 우선한다.
7. 클래스, 모듈, 서비스 책임이 명확해야 하며 결합도는 낮추고 응집도는 높인다.
8. 작은 기능 수정이라도 장기적으로 확장 가능한 구조인지 먼저 검토한다.
9. 변경사항이 생기면 해당 파일만 국소적으로 보지 말고 전체 흐름에서 점검한다.
10. 특히 비즈니스 흐름 단위로 반복적으로 검사하여 앞뒤 단계와의 연결이 깨지지 않도록 수정한다.
11. 수정 후에는 입력, 처리, 저장, 출력, 발행까지 이어지는 사용자 흐름을 기준으로 영향을 다시 확인한다.
12. 모든 개발 전후에는 반드시 영향분석을 수행한다.
13. 영향분석에서는 전체 성능, 개발 규칙 위반 여부, 다른 모든 영향 여부를 합산하여 검증한다.
14. 변경이 작아 보여도 공통 모듈, 데이터 흐름, API, UI, 발행 흐름에 미치는 영향을 매번 확인한다.
15. 모든 개발은 공통 디자인 규칙을 먼저 확인하고 반드시 그 기준을 따른다.
16. 공통 디자인 규칙은 docs/design/README.md를 기준 문서로 사용한다.
17. 새로운 개발 내용이 공통 디자인 규칙에 없는 유형이라면 먼저 디자인 문서를 정의하거나 갱신한 뒤 개발한다.
18. 문서 정의 없이 예외 구현을 먼저 추가하지 않는다.
19. 프로젝트 공통 용어는 docs/glossary/README.md의 용어사전을 기준으로 사용한다.
20. 새로운 용어, 기능명, 화면명, 아키텍처 개념이 생기면 먼저 또는 동시에 용어사전을 갱신한다.
21. AGENTS.md와 CLAUDE.md는 항상 동일한 기준 문서로 유지하고, 한쪽이 바뀌면 다른 한쪽도 반드시 즉시 양방향 동기화한다.
22. 모든 개발 시작 전에는 Kimi가 먼저 관련 자료를 실질적으로 조사하고, 그 결과를 Claude 개발 단계에 반드시 적용해야 한다.
23. Claude는 Git worktree 기반 분산 작업 공간에서 개발하고, Codex는 이를 영향평가와 린 리포지토리 반응을 담당한다.
24. 이 역할 분리는 workflow/README.md의 공식 개발 프로세스를 따른다.
25. 에이전트 실행은 CLI 기반으로 수행하며, 자동화 프로그램이 생성한 실행 스크립트를 표준 진입점으로 사용한다.
26. 이 문서는 Codex와 Claude를 포함한 에이전트가 이 저장소에서 안전하게 작업하기 위한 공통 운영 문서다.

### [섹션 2] 문서 우선순위
- 에이전트 작업 규칙: AGENTS.md, CLAUDE.md (항상 동일 내용 유지, 변경 시 즉시 양방향 동기화)
- 일반 프로젝트 사용법: README.md
- 테스트 상세: TEST_GUIDE.md
- 상세 코드 분석: docs/analysis/
- 공통 디자인 규칙: docs/design/README.md
- 공통 용어사전: docs/glossary/README.md
- 공식 개발 프로세스: workflow/README.md
- 기능/기획 문서: docs/

### [섹션 3] Daily 기록 규칙
- 모든 작업 기록은 docs/daily/ 아래에 날짜별로 저장한다
- 날짜 폴더 형식은 YYYY-MM-DD
- 각 날짜 폴더에는 아래 파일을 유지한다: codex.md, claude.md, kimi.md
- Codex는 작업 후 같은 날짜의 docs/daily/YYYY-MM-DD/codex.md에 내용을 누적 기록한다
- Claude는 claude.md, Kimi는 kimi.md를 같은 방식으로 사용한다
- 큰 구조 변경, 파일 이동, 삭제, 테스트 결과는 반드시 기록한다
- 기본 운영 규칙과 예시는 docs/daily/README.md를 따른다
- AGENTS.md와 CLAUDE.md는 항상 함께 수정하고 동일하게 유지한다

### [핵심 특징] 외부 시스템의 멀티 AI 구조
- **Claude**: Git worktree 기반 분산 개발 (코딩 실행)
- **Codex**: 영향평가 + 린 리포지토리 반응 담당 (검증/리뷰)
- **Kimi**: 개발 전 리서치 조사 전담 (사전 조사)
- 3개 AI 엔진이 역할 분리되어 협업하는 구조

## 비교 대상: 우리 아누시스템 개발부

### 반드시 참고할 우리 시스템 자료
1. `/home/jay/workspace/memory/specs/anu-guide.md` — 아누 가이드 (최상위 업무 기준서)
2. `/home/jay/workspace/memory/specs/work-level-system.md` — 작업 레벨 시스템
3. `/home/jay/workspace/memory/organization-structure.json` — 전체 조직도
4. `/home/jay/workspace/memory/specs/bot-team-mapping.md` — 봇-팀 매핑
5. `/home/jay/.cokacdir/workspace/autoset/CLAUDE.md` — 아누 CLAUDE.md (개발실장 규칙)
6. `/home/jay/workspace/dispatch.py` — 위임 시스템 (팀 간 작업 배분)
7. `/home/jay/workspace/prompts/team_prompts.py` — 팀 프롬프트 (팀별 역할 정의)
8. `/home/jay/workspace/memory/specs/composite-team-system.md` — 복합팀 시스템
9. `/home/jay/workspace/memory/MODULARIZATION-PHILOSOPHY.md` — 모듈화 철학
10. `/home/jay/workspace/teams/security/CLAUDE.md` — 보안팀 운영
11. `/home/jay/workspace/memory/specs/telegram-report-format.md` — 보고 포맷
12. 스킬 시스템: `/home/jay/.claude/skills/` (85+개 스킬)

### 우리 시스템 핵심 구조 요약 (참고용)
- **아누(Opus)**: 개발실장, 코딩 금지, 설계/판단/위임/검증만
- **7개 개발팀**: 팀장(Opus) + 팀원 4명(Sonnet). 팀장도 코딩 금지, 설계/검토만. Sonnet 팀원이 코딩.
- **8팀(라)**: Sonnet 팀장 + GLM-5 순차작업. 외주 성격.
- **횡단조직**: Gemini센터(비너스), Codex센터(아틀라스), DevOps(야누스), QC(마아트), 전략(프로메테우스), 회고(크로노스), 보안팀(로키)
- **멀티 AI**: Claude(Opus/Sonnet) + Gemini + GPT(Codex) + GLM — 4대 엔진 활용
- **dispatch.py**: 중앙 위임 시스템, 파일 기반 지시, worktree 격리
- **작업 레벨 시스템**: Lv.0~Lv.4, "어떻게 확인하지?"까지 답 나온 후 코딩 진입
- **핵미사일 발사코드**: 에이전트 미팅 반복 → 3문서 → 제이회장님 강제 승인 → 코딩
- **Phase 분리 원칙**: 호흡이 긴 작업은 무조건 Phase로 쪼갬
- **.done 프로토콜**: 완료 감지 → 보고 → 다음 작업 배정
- **레드팀(로키)**: 모든 미팅에 필수 참석, Devil's Advocate
- **셀프 QC 체크리스트**: 각 팀원이 완료 전 자체 검증
- **fact_guard**: 수치 환각 방지 3중 안전장치

## 분석 요구사항

### 1. 항목별 대응 비교 (필수)
외부 규칙의 각 항목(26개)을 우리 시스템의 대응 규칙과 1:1 매핑.
- 우리가 **이미 보유한 것** (어떤 파일/규칙에 있는지 명시)
- 우리가 **부분적으로 보유한 것** (어디가 약한지)
- 우리가 **아예 없는 것** (도입 가치 평가)

### 2. 구조적 차이 분석 (필수)
- 외부: Claude + Codex + Kimi (3 AI 역할 분리) vs 우리: 4대 엔진 + 수직/횡단 조직
- 문서 체계 비교: 외부 docs/ 구조 vs 우리 memory/ + skills/ + specs/ 구조
- Daily 기록: 외부 에이전트별 daily log vs 우리 task-timers + daily/ + .done 프로토콜
- 영향분석: 외부 전후 영향분석 필수 vs 우리 셀프 QC + 레드팀 검증

### 3. 우리 시스템의 강점 (이미 우월한 영역)
외부 규칙에는 없지만 우리가 가진 것들도 명확히 식별.
예: 작업 레벨 시스템, 핵미사일 발사코드, 보안팀, 복합팀, 85개 스킬 등

### 4. 배울 점 + 도입 제안 (핵심)
외부에서 배울 만한 것을 **구체적 도입안**으로 제시:
- 어떤 규칙을 도입할 것인가
- 어디에(어떤 파일에) 추가할 것인가
- 기존 규칙과 충돌 여부
- 도입 우선순위 (즉시/검토 후/불필요)

### 5. 종합 평가
- 외부 시스템 성숙도 vs 우리 시스템 성숙도
- 외부가 우리보다 나은 영역 / 우리가 외부보다 나은 영역
- 점수 비교 (가능하다면 영역별 10점 만점 스코어링)

## 산출물
- 비교분석 보고서: `memory/reports/task-1056.1.md`
- SCQA 구조 포함
- 항목별 대응 비교표, 구조적 차이 분석, 강점/약점, 도입 제안 포함

## 주의사항
- 우리 시스템 파일을 **반드시 직접 읽고** 비교할 것 (추측 금지)
- 외부 규칙을 과대/과소 평가하지 말 것 — 객관적 비교
- "일부분"이라는 점 유의 — 외부 시스템의 전체 그림은 이 규칙만으로 판단 불가
- 도입 제안은 **기존 시스템을 깨뜨리지 않는** additive 방식으로