Files

T

Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

2026-07-05 00:33:48 +09:00

5.3 KiB

Raw Blame History

id, title, category, status, verification_status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, created_at, updated_at, review_reason, merge_history, tags, raw_sources, applied_in, github_commit

title

Sprint

🎯 한 줄 통찰 (One-line insight)

검증된 요구사항을 바탕으로 제품 증분을 반복적으로 구축, 테스트 및 개선하여 변화에 유연하게 대응하는 짧고 규율 있는 인도(Delivery) 주기 [1, 2].

🧠 핵심 개념 (Core concepts)

반복적 인도 (Iterative Delivery): 전체 작업을 1주에서 4주 사이의 짧은 주기로 나누어 실행 가능한 제품 증분을 지속적으로 생성함 [1, 2].
의식적 구조 (Ceremonial Structure): 스프린트 계획(Planning), 데일리 스탠드업(Daily Standups), 리뷰(Review), 회고(Retrospective)를 통해 흐름과 개선을 관리함 [3, 4].
백로그 기반 (Backlog-Driven): 우선순위가 지정된 요구사항 목록인 '백로그'에서 작업을 가져와 계획된 범위 내에서 수행함 [3, 4].
디자인 스프린트 (Design Sprint): 디자인 씽킹 원칙을 5일이라는 짧은 시간으로 압축하여 제품 백로그에 반영할 연구 기반의 사용자 스토리를 생성하는 하이브리드 방식 [5-8].

🧩 추출된 패턴 (Extracted patterns)

구축-검토-조정 루프 (Build-Review-Adjust Loop): 모든 스프린트 끝에 시연(Demo)과 회고를 배치하여 피드백을 수용하고 다음 주기에 반영하는 구조 [1-4].
상류 발견 의존성 (Upstream Discovery Dependency): 스프린트의 성공은 '무엇을 만들 것인가'를 정의하는 상류의 발견 단계(디자인 씽킹)에 의존하며, 이 단계가 누락되면 잘못된 문제를 해결하는 효율적 실패가 발생함 [9-14].
타임박싱 (Time-Boxing): 고정된 기간(1-4주 또는 5일)을 설정하여 팀의 집중력을 유지하고 실행 모멘텀을 형성함 [1, 2, 6, 8].

📖 세부 내용 (Details)

스프린트는 애자일(Agile) 및 스크럼(Scrum) 프레임워크의 핵심 메커니즘으로 작동하며 다음과 같은 상세 프로세스를 포함한다.

스프린트 계획 (Sprint Planning): 팀이 백로그에서 다음 주기에 인도할 항목을 선택하고 목표를 설정하는 초기 단계이다 [3, 4].
실행 및 동기화: 스프린트 기간 중 매일 짧은 스탠드업 미팅을 통해 장애물을 파악하고 팀의 동력을 유지한다 [3, 4].
피드백 루프 (Sprint Review): 주기가 끝나면 이해관계자에게 구축된 증분을 시연하고 피드백을 수집하여 솔루션의 방향성을 검증한다 [3, 4].
지속적 개선 (Retrospective): 팀은 프로세스를 되돌아보고 다음 스프린트에서 개선할 구체적인 행동을 정의한다 [3, 4].
디자인 씽킹과의 연계: 애자일 스프린트가 '검증된 솔루션의 인도'에 집중한다면, 디자인 스프린트는 '문제 정의와 검증'에 집중하며 보통 애자일 인도 트랙보다 1~2단계 앞서 실행되는 것이 이상적이다 [5, 7].

⚖️ 모순 및 업데이트 (Contradictions & updates)

효율성 vs 유효성: 애자일 스프린트는 제품을 구축하는 데 매우 효율적이지만, 상류의 문제 정의(디자인 씽킹)가 부실할 경우 "잘못된 제품을 아름답게 구축"하는 결과를 초래할 수 있다는 경고가 소스에서 반복적으로 나타난다 [9, 12, 15, 16].
가짜 애자일 (Fake Agile): 많은 조직이 스프린트의 의식(스탠드업, 리뷰 등)은 채택하지만, 실제 의사결정은 여전히 하향식 폭포수(Waterfall) 방식으로 이루어져 팀의 권한이 제한되는 모순이 발생한다 [17-22].

🛠️ 적용 사례 (Applied in summary)

대형 민간 은행 (Large Private Sector Bank): 모바일 대출 신청 중단 문제를 해결하기 위해 UI 최적화(버튼 배치, 필드 축소 등)에 초점을 맞춘 애자일 스프린트를 3회 실시했으나 성과가 없었다. 이후 디자인 씽킹을 통해 실제 원인이 '신용 점수 하락에 대한 불신'임을 발견하고 이를 해결하는 기능을 스프린트에 반영하여 전환율을 34% 높였다 [15, 16, 23-26].
중견 IT 서비스 기업 (Mid-Sized IT Services Firm): 전사적으로 스크럼과 스프린트를 도입했으나 초기 단계에서 문제 정의가 부실하여 스프린트 도중 잦은 범위 변경이 발생했다. 디자인 씽킹 기반의 문제 정의 단계를 상류에 도입한 결과, 스프린트 도중 발생하는 범위 변경이 40% 감소했다 [11, 14, 27, 28].

✅ 검증 상태 및 신뢰도

상태: draft
검증 단계: conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
출처 신뢰도: B (Official Documentation / Primary Source via NotebookLM)
중복 검사 결과: 신규 생성 (New discovery)

📝 변경 이력 (Change history)

2026-05-23: Initial draft generated via Datacollector_MAC P-Reinforce engine.

5.3 KiB Raw Blame History