feat: wikify sporty&rich meeting minutes and update index (2026-04-29)
This commit is contained in:
@@ -0,0 +1,51 @@
|
||||
---
|
||||
type: meeting_minutes
|
||||
status: finished
|
||||
tags: [Hi-Mart, UI/UX, AI-Chatbot, Compliance, Logging]
|
||||
project: Hi-Mart Virtual Store
|
||||
date: 2026-04-28
|
||||
created: 2026-04-29
|
||||
---
|
||||
|
||||
# 📑 [회의록] 하이마트/가상 스토어 UI/UX 및 기술 구현 방향성 검토
|
||||
|
||||
> **일시:** 2026.04.28
|
||||
> **주요 안건:** 데이터 로깅 범위 축소(Mini-Logging) 및 AI 챗봇 컴플라이언스 대응
|
||||
> **핵심 결정:** 사용자 행동 로그의 핵심 지표(체류시간/클릭) 집중 및 개인정보 보호 로직(48시간 후 파기) 수립
|
||||
|
||||
---
|
||||
|
||||
## 🏛️ I. 데이터 로깅 (로그 수집) 세부 합의 사항
|
||||
비즈니스 가치 판단의 핵심 지표인 '체류 시간'과 '구매 유도'에 집중하여 구현 복잡성을 최소화함.
|
||||
|
||||
| 구분 | 최종 결정 범위 (MUST-HAVE) | 비고 / 기술적 근거 |
|
||||
| :--- | :--- | :--- |
|
||||
| **핵심 지표** | 1. **공간별 체류 시간 (Zone/Waypoint)**: 구역별 체류 시간 측정<br>2. **상품 링크 클릭 여부**: 외부 이탈 건수 추적 | '체류 시간'과 '클릭 유도(구매)'를 핵심 비즈니스 가치로 확정 |
|
||||
| **수집 메커니즘** | **브라우저 종료/이탈 감지(Browser Exit)** 시점 로깅 | 세션 ID와 핵심 웨이포인트만 기록하여 데이터 부하 최소화 |
|
||||
| **제외 항목** | 모든 비핵심적인 사용자 식별 정보 및 상세 시스템 로그 | 보안 리스크 감소를 위해 수집 항목에서 완전 배제 |
|
||||
|
||||
---
|
||||
|
||||
## 🛡️ II. AI 챗봇 컴플라이언스 및 보안 실행 계획
|
||||
정보보호 규정 준수를 위해 설계 단계부터 기술적 차단 및 자동 파기 로직을 적용함.
|
||||
|
||||
| 영역 | 의무 처리 내용 (Must-Do) | 기술적/정책적 조치 (How To Achieve) | 담당 주체 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **개인정보 보호** | 민감 정보(주민번호, 전화번호 등) 수집 금지 | AI 챗 UI 내 **패턴 검사 필터링** 및 서버측 즉시 삭제 로직 구축 | 개발팀 / 백엔드 |
|
||||
| **데이터 투명성** | 데이터 활용 및 수집 항목 투명 고지 | 로딩 화면/대화 시작 시 안내 문구 노출 및 **48시간 후 자동 삭제** 정책 적용 | 기획팀 / 개발팀 |
|
||||
| **보안 심의** | 명확한 근거 기반 동의 절차 마련 | 보안 고지 문구 전문가 컨펌 및 개발 적용 여부 추적 관리 | PM / 정보보호실 |
|
||||
|
||||
---
|
||||
|
||||
## 📅 III. 향후 액션 플랜 (Next Steps & Owner)
|
||||
프로젝트 완수를 위해 각 담당자는 아래 추진 방향에 따라 작업을 진행함.
|
||||
|
||||
| ID | 작업 항목 | 상세 목표 및 실행 방향 | 담당자 | 기한 |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **A1** | **데이터 명세서 재정의** | 최소 로그 데이터 기반 상세 요구사항 정의서 작성 및 공유 | PD 김원일 / 오경득 | TBD |
|
||||
| **A2** | **기술 구현 로직 설계** | Browser Exit 감지 및 웨이포인트 기반 체류 시간 산정 로직 구체화 | 김상엽 (넥서스) | TBD |
|
||||
| **A3** | **보안 가이드라인 확정** | 고지 문구, 수집 항목, 삭제 정책 보안팀 공식 전달 및 컨펌 | PM 한예성 | 즉시 |
|
||||
| **A4** | **사업부 최종 협의** | 데이터 로깅 최소화 방안의 비즈니스 타당성 최종 재확인 | PD 김원일 / 정현욱 | TBD |
|
||||
|
||||
---
|
||||
"조직이 시스템이다. 실질적인 결과물과 일정으로 증명한다." - P-Reinforce Logic 🫡🚩🐟
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
type: meeting_minutes
|
||||
status: in_progress
|
||||
tags: [Sporty&Rich, Development, Schedule, Client, QA, Security, Biz]
|
||||
project: Sporty & Rich Virtual Store
|
||||
date: 2026-04-29
|
||||
created: 2026-04-29
|
||||
---
|
||||
|
||||
# 📑 [회의록] 스포티앤리치 전체 개발 일정 및 팀별 주요 업무 점검
|
||||
|
||||
> **일시:** 2026.04.29
|
||||
> **주요 안건:** 전체 마일스톤 점검, 팀별 R&R 확정, 지연 리스크(URL 리다이렉션) 대응
|
||||
> **핵심 결정:** 5/17 빌드 프리징 및 5/06 보안 심사 대응을 위한 전사적 협력 체계 가동
|
||||
|
||||
---
|
||||
|
||||
## 🏛️ I. 전체 개발 마일스톤 및 일정 합의
|
||||
|
||||
프로젝트 완수를 위해 각 단계별 마감 기한과 담당자를 명확히 확정함.
|
||||
|
||||
| 단계 | 기간 / 마감 | 담당 주체 | 비고 / 핵심 목표 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **클라이언트 개발** | 04/27 ~ 05/13 | 송병준, 박진규, 박태수 | 인벤토리 확장 및 상단 메뉴 개편 |
|
||||
| **상품 제작 (20 SKU)** | 04/23 ~ 05/13 | 안현제 | AI 이미지 기반 SKU 생성 및 데이터 정리 |
|
||||
| **보안 심사** | 05/06 (예정) | 김상엽, 김성환, 정승민 | 사전 점검 및 취약점 대응 준비 |
|
||||
| **채널 연동 (롯데온)** | 05/14 | 정현욱 | 채널 토큰 공유 (ASAP 요청 건) |
|
||||
| **개선 및 QA** | 05/14 ~ 05/17 | 송병준, 김상엽, 최성연 | 빌드 프리징 전 최종 품질 확보 |
|
||||
|
||||
---
|
||||
|
||||
## 🛡️ II. 팀별 세부 업무 및 리스크 관리
|
||||
|
||||
각 팀은 확정된 R&R에 따라 진행 상황을 관리하며, 지연 항목에 대해서는 즉각적인 대응을 실시함.
|
||||
|
||||
| 팀 | 주요 진행 업무 (Items) | 상태 (Status) | 이슈 및 대응 방향 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **클라이언트** | 데이터 지표 개발, 피팅룸 기능 개선, 메뉴 구조 개편 | **진행중** | 05/13 완료 목표로 개발 가속화 |
|
||||
| **UI / 기획** | 피팅룸 UI 기획 및 시안 제작, UI 제작(~05/08) | **진행중** | 개발 가이드 전달 및 UI 제작 진행 |
|
||||
| **사업실** | 로그 수집 구조 정의, 채널 토큰 수령/적용 | **주의** | **URL 리다이렉션 처리 지연 (04/27 목표 도과) ➔ 즉시 조치 필요** |
|
||||
| **상품 제작** | AI 이미지 SKU 20종 생성, 모델 데이터 정리 | **진행중** | 05/13 최종 마감 준수 |
|
||||
| **QA / 보안** | 빌드 QA 완료, 보안 심사 대응 준비 | **대기** | 05/06 보안 심사 리스크 사전 차단 |
|
||||
|
||||
---
|
||||
|
||||
## 📅 III. 향후 액션 플랜 (Next Steps & Owner)
|
||||
|
||||
| ID | 작업 항목 | 상세 목표 및 실행 방향 | 담당자 | 기한 |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **A1** | **URL 리다이렉션 지연 해결** | 지연된 리다이렉션 처리 완료 및 결과 공유 | 정현욱 (사업실) | **즉시** |
|
||||
| **A2** | **보안 심사 사전 리허설** | 보안 심사 대응을 위한 자체 점검 및 버퍼 확보 | 김상엽, 김성환 | 05/05 |
|
||||
| **A3** | **채널 토큰 조기 수령** | 롯데온 연동 토큰 05/14 전 조기 확보 및 전달 | 정현욱 | 05/13 |
|
||||
| **A4** | **빌드 프리징 준비** | 모든 개선 사항 반영 및 최종 QA 돌입 준비 | 송병준, 최성연 | 05/14 |
|
||||
|
||||
---
|
||||
"조직이 시스템이다. 실질적인 결과물과 일정으로 증명한다." - P-Reinforce Logic 🫡🚩🐟
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AGPH-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, agile, manifesto, philosophy, project-management, iteractive-design]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Agile-Philosophy]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "변화에 춤추는 민첩함: 완벽한 계획보다 빠른 실행을, 문서보다 동작하는 산출물을 우선하며, 끊임없는 피드백을 통해 고객의 진정한 가치를 찾아가는 유연한 철학."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
애자일 철학(Agile-Philosophy)은 불확실성이 높은 환경에서 짧은 주기의 학습과 개선을 반복하며 가치를 전달하는 방법론이자 문화입니다.
|
||||
|
||||
1. **4대 핵심 가치 (Agile Manifesto)**:
|
||||
* **인간과 상호작용** > 프로세스와 도구.
|
||||
* **작동하는 소프트웨어** > 방대한 문서.
|
||||
* **고객과의 협력** > 계약 협상.
|
||||
* **변화에 대응하기** > 계획 준수.
|
||||
2. **핵심 매커니즘**:
|
||||
* **Iteration (Sprint)**: 1~4주 단위의 성과물 배포 주기를 반복.
|
||||
* **Continuous Feedback**: 실제 사용자나 고객으로부터 정기적으로 피드백 수렴.
|
||||
* **Retrospective (회고)**: 팀의 일하는 방식 자체를 돌아보고 개선.
|
||||
3. **목표**:
|
||||
* 완성된 쓰레기가 아닌, **필요한 보석**을 제시간에 만드는 것.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 폭포수(Waterfall) 모델 기반의 '선계획 정책'이 정석이었으나, 현대의 초불확실성 기술 정책은 계획을 최소화하고 실행 중에 방향을 트는 '애자일 정책' 없이는 생존이 불가능함을 인정함(RL Update).
|
||||
- **정책 변화(RL Update)**: 대규모 기업 정책 수립 시, 애자일이 단순히 '빠르게' 하는 것으로 오용되어 품질이 저하되는 부작용을 막기 위해, 'Agile Governance'와 'QA 자동화 정책'을 전제로 한 성숙한 애자일 문화 도입 정책이 추진됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Stability vs Flexibility]], [[Rapid-Prototyping]], [[Working-Backwards]], [[Theory of Constraints (TOC)]], [[Systems Thinking]]
|
||||
- **Modern Tech/Tools**: Scrum, Kanban, Jira, Linear, Short-cycle feedback systems.
|
||||
---
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: P-REINFORCE-1363FF
|
||||
category: "10_Wiki/💡 Topics/Design & Experience"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Batch 10 - Wikified Agile-UX-Integration"
|
||||
---
|
||||
|
||||
# [[Agile-UX-Integration]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 핵심 내용 요약 예정
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
세부 본문 내용 구성 예정
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
|
||||
- **정책 변화:** Design & Experience 분야의 체계적 지식 자산화 진행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
|
||||
---
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id: DDD-MASTER-001
|
||||
category: "10_Wiki/💡 Topics/Software Architecture"
|
||||
confidence_score: 1.0
|
||||
tags: [architecture, ddd, strategic-design, tactical-design, ubiquitous-language]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Domain-Driven Design (DDD, 도메인 주도 설계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "복잡한 비즈니스 로직을 소프트웨어의 심장으로 만들어라" — 기술적 복잡성보다 비즈니스 도메인의 복잡성을 우선시하며, 개발자와 전문가가 동일한 언어(Ubiquitous Language)로 소통하며 설계하는 방법론.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 거대한 시스템을 독립적인 의미를 가진 '바운디드 컨텍스트(Bounded Context)'로 나누고, 그 내부를 핵심 도메인 모델 중심으로 구축하는 아키텍처 패턴.
|
||||
- **전략적 설계 (Strategic Design):**
|
||||
- **Ubiquitous Language:** 개발자, 기획자, 도메인 전문가가 모두 사용하는 공통 언어 정의.
|
||||
- **Bounded Context:** 특정 모델이 적용되는 논리적인 경계 설정. 컨텍스트 간의 관계는 Context Map으로 정의.
|
||||
- **Core Domain:** 비즈니스의 가장 핵심적인 가치를 창출하는 영역에 자원 집중.
|
||||
- **전술적 설계 (Tactical Design):**
|
||||
- **Entity & Value Object:** 식별자 기반의 객체와 속성 기반의 값 객체 구분.
|
||||
- **Aggregate:** 데이터 변경의 단위로 묶인 객체들의 집합. Root 엔티티를 통해서만 접근.
|
||||
- **Repository:** 도메인 객체의 생명주기를 관리하고 저장소 추상화 제공.
|
||||
- **Domain Service:** 특정 엔티티에 속하기 어려운 비즈니스 로직 처리.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거의 데이터베이스 중심 설계(ERD 중심)에서 행위와 도메인 로직 중심의 설계로 전환.
|
||||
- **정책 변화:** Antigravity 프로젝트는 '지식 관리', '게임 엔진', '데이터 수집'을 각각의 Bounded Context로 분리하고, 컨텍스트 간 통신은 메시지 큐를 통한 비동기 방식을 지향함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** 10_Wiki/💡 Topics/Software Architecture
|
||||
- **Related:** Bounded-Context, Microservices, Clean-Architecture, Event-Sourcing
|
||||
- **Merged Sources:**
|
||||
- 10_Wiki/Topics/AI/Domain-Driven Design (DDD) in TypeScript.md
|
||||
- 10_Wiki/Topics/AI/Domain-Driven Design (DDD) Type Safety.md
|
||||
- 10_Wiki/Topics/AI/도메인 주도 설계 (Domain-Driven Design DDD).md
|
||||
- 10_Wiki/Topics/Frontend_Mastery/Domain-Driven Design (DDD).md
|
||||
@@ -0,0 +1,25 @@
|
||||
# 📄 사실 기반 회의록 작성 가이드 (Fact-Based Meeting Minutes Guide)
|
||||
|
||||
### [최종 목표]
|
||||
사용자로부터 제공받은 원본 회의 녹취록/기록(Input Data)을 분석하여, **외부 지식이나 개인적 추측이 일절 배제된**, 완벽하게 구조화되고 객관적이며 실행 가능한 '사실 기반 회의록'을 산출하는 것. 특히 **추상적인 개념보다는 구체적인 내용, 일정, 방향성**을 중심으로 정리한다.
|
||||
|
||||
### [핵심 역할 및 정체성]
|
||||
당신은 **최종 사실 추출 엔진(Ultimate Fact Extraction Engine)**이다. 당신의 유일한 임무는 Input Data를 순수한 데이터 저장소로 작동하며, 모든 발언자의 감정적 편향이나 ID 표기(예: 참석자 1)에 관계없이 오직 **'발언된 사실과 합의된 내용'**만을 기록하는 것이다.
|
||||
|
||||
### [데이터 우선순위 및 예외 처리 (CRITICAL OVERRIDE)]
|
||||
* **최우선 데이터 소스:** 만약 사용자로부터 회의 녹취록 외에 별도로 제공된 '회의 메타데이터(날짜, 참석자 명단 등)'가 존재할 경우, **해당 메타데이터를 모든 날짜 및 참석자 정보 항목에 무조건적으로 사용해야 한다.**
|
||||
* **녹취록 내 정보 처리:** 녹취록 자체에서 날짜나 참석자 정보가 언급되었더라도, 별도 제공된 메타데이터가 있다면 이를 덮어쓰고(Override) 사용한다.
|
||||
|
||||
### [운영 원칙: 4단계 내부 처리 루프]
|
||||
1. **데이터 해체 및 발언자 무시:** 잡담 분리, 핵심 주제 및 사실(Fact) 추출. 최종 출력물에는 발언자 ID(예: 참석자 1)를 절대 사용하지 않음.
|
||||
2. **사실 기반 구조화:** 추출된 사실과 결정 사항을 필수 출력 형식의 6개 섹션 구조에 배치.
|
||||
3. **검증 및 유효성 확인 (Critical Validation):**
|
||||
* a) 사실 기반 강제: 누락 시 `[확인 불가]` 표시.
|
||||
* b) 발언자 식별 금지: 본문 내 이름/ID 언급 엄격 금지.
|
||||
* c) 결정된 사실 위주 반영.
|
||||
4. **정제 및 최종화:** 불확실한 정보는 `[확인 불가]` 대체. 구어체적 합의를 확정 조치로 포착.
|
||||
|
||||
### [엄격 준수 규칙]
|
||||
* **날짜/참석자 규약:** 메타데이터 우선 적용. 미명시 시 `[확인 불가]` 또는 `[논의 참여 주체]` 표시.
|
||||
* **1인칭/감정 배제:** "우리는~", "생각한다" 등 주관적 표현 절대 금지. 모든 문장은 "결정됨", "논의됨", "확인됨" 등 객관적 서술형으로 종결.
|
||||
* **발언자 익명화:** "A님이 말함" 대신 "특정 기능에 대한 요구사항이 제기됨"과 같이 내용 중심으로 기술.
|
||||
@@ -0,0 +1,36 @@
|
||||
# [[하이마트]] 가상 스토어 UI/UX 및 기술 구현 방향 (2026.04.28)
|
||||
|
||||
## 📌 Brief Summary
|
||||
3D/VR 체험 앱의 데이터 로깅 범위 축소(Mini-Logging) 및 AI 챗봇 개인정보 보호 컴플라이언스 수립 보고. 핵심은 비즈니스 가치 중심의 최소 데이터 수집과 48시간 내 자동 삭제 로직 구현임.
|
||||
|
||||
## 🏷️ Metadata
|
||||
* **Context**: [[UI/UX Strategy]], [[Data Privacy]], [[Compliance]]
|
||||
* **Type**: [[Technical Report (Meeting Minutes)]]
|
||||
* **Level**: [[Level: Meso]]
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 데이터 로깅 최종 합의 (Mini-Logging)
|
||||
* **수집 항목**:
|
||||
1. **공간별 체류 시간 (Zone/Waypoint)**: 사용자 행태 분석용.
|
||||
2. **상품 링크 클릭 여부**: 구매 전환율 측정용.
|
||||
* **메커니즘**: 브라우저 종료/이탈 시점(Browser Exit) 로깅을 통한 부하 최소화 및 쿠키 의존성 탈피.
|
||||
|
||||
### 2. AI 챗봇 보안 규정 (Compliance)
|
||||
* **민감 정보 차단**: 패턴 검사 필터링을 통해 입력 단계부터 원천 차단.
|
||||
* **투명성 및 휘발성**:
|
||||
- 안내 문구 상시 노출.
|
||||
- **48시간 자동 삭제 로직**: 데이터 보유 기간을 최소화하여 리스크 관리.
|
||||
|
||||
### 3. 액션 아이템 (Action Items)
|
||||
* **[[김원일 PD]] / 오경득**: 최소 로그 데이터 기반 상세 요구사항 정의서 작성.
|
||||
* **개발팀**: 패턴 필터링 및 48시간 자동 삭제 엔진 구축.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
* **Upstream (Strategy)**: [[Lotte Himart UI/UX Redefinition]]
|
||||
* **Horizontal (Related)**: [[Data Logging Best Practices]], [[AI Chatbot Privacy Guidelines]]
|
||||
* **Downstream (Next Steps)**: [[Logging Specification v1.0]], [[Security Review Meeting]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-29*
|
||||
*Ref: Meeting Minutes 2026-04-28*
|
||||
@@ -0,0 +1,33 @@
|
||||
# [[하이마트]] 웹스토어 UI/UX 구조 재정립 및 일정 점검 (2차)
|
||||
|
||||
## 📌 Brief Summary
|
||||
2026년 4월 28일 진행된 하이마트 가상 스토어 개발 회의. 핵심 결정 사항은 **개발 주도권의 내부 전환**이며, 5월 초 연휴로 인한 일정 리스크(5월 6일 마감)를 확인하고 현실적인 마일스톤 재조정을 결정함.
|
||||
|
||||
## 🏷️ Metadata
|
||||
* **Context**: [[Project Management]], [[E-Commerce Strategy]]
|
||||
* **Type**: [[Decision (Meeting Minutes)]]
|
||||
* **Level**: [[Level: Macro (Strategic)]]
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 주요 의사결정 (Decisions)
|
||||
* **개발 주체 내부화**: 기존 외부 솔루션([[E-Travelive]]) 의존도를 낮추고, 내부 개발팀 주도로 UI/UX를 구현하여 장기적 유연성 확보.
|
||||
* **일정 전면 재조정**: 5월 6일 완료 일정은 연휴 기간(5/1~5/5)을 고려할 때 물리적으로 불가능함을 확인. [[김원일 PD]] 주도로 TF팀과 새로운 마일스톤 수립 예정.
|
||||
|
||||
### 2. 리스크 및 대응 (Risks & Issues)
|
||||
* **Critical Schedule Risk**: 실질 작업 가능일 부족 (연휴 제외 시 단 2일). ➔ **대응**: 즉각적인 일정 재협의 및 공유.
|
||||
* **리소스 투입**: 내부 주도 개발을 위한 리소스 확보 및 협업 프로세스 정립 필요.
|
||||
|
||||
### 3. 액션 아이템 (Action Items)
|
||||
* **[[김원일 PD]]**: TF팀과 현실적인 마일스톤 재협의 (기한: 즉시).
|
||||
* **기획팀 (오경득/김지수)**: 내부 개발용 UI/UX 상세 기획 및 와이어프레임 확정.
|
||||
* **클라팀 (송병준/박진규)**: 외부 의존성 제거에 따른 기술 아키텍처 적합성 검토.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
* **Upstream (Context)**: [[Lotte Himart Digital Transformation]]
|
||||
* **Horizontal (Related)**: [[UI/UX Design Systems]], [[External Dependency Management]]
|
||||
* **Downstream (Next Steps)**: [[New Project Milestone 2026-05]], [[Internal Development Process Setup]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-29*
|
||||
*Ref: Meeting Minutes 2026-04-28*
|
||||
@@ -0,0 +1,17 @@
|
||||
# 📑 Topics: Meeting & Knowledge Management
|
||||
|
||||
> [!TIP]
|
||||
> This category contains meeting minutes, decision records, and knowledge extraction from collaborative sessions.
|
||||
|
||||
## 📅 Recent Meeting Minutes
|
||||
- [[20260429_스포티앤리치_개발일정_회의록|2026.04.29 스포티앤리치 전체 개발 일정]]
|
||||
- [[20260428_하이마트_UIUX_회의록|2026.04.28 하이마트 UI/UX 및 기술 방향성]]
|
||||
|
||||
## 🏛️ Strategy & Methodology
|
||||
- [[Agile-Philosophy|Agile Philosophy]]
|
||||
- [[Agile-UX-Integration|Agile UX Integration]]
|
||||
- [[Domain-Driven Design (DDD)|DDD Strategy]]
|
||||
- [[Ontology-Engineering|Ontology Engineering]]
|
||||
|
||||
---
|
||||
"기록되지 않은 지식은 존재하지 않는 지식이다." 🫡🐟
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-9231E5
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Ontology-Driven-Relevancy-Filtering"
|
||||
---
|
||||
|
||||
# [[Ontology-Driven-Relevancy-Filtering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 탐사 과정에서 발생할 수 있는 '주제 이탈(Topic Drift)'을 방지하기 위해 도입된 의미론적 제약 엔진입니다. 최초 입력된 'Root Topic'을 모든 하위 연구 단계에 주입하여, 추출된 연관 주제가 뿌리 지식과 얼마나 밀접한지를 LLM이 스스로 판단하게 합니다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
지능형 에이전트가 자율적으로 연구를 수행할 때 발생하는 가장 큰 위험은, 연관 주제를 타고 가다가 원래의 목적과 상관없는 지식(예: '프로그래밍'에서 시작해 '인류의 역사'로 끝남)을 수집하는 것입니다. 이를 해결하기 위해 다음의 '필터링 레이어'를 구축했습니다.
|
||||
|
||||
1. **Root Topic Injection**: 미션 시작 시 입력된 주제를 전역 상태(`rootTopic`)로 고정하고, 모든 프롬프트에 "최초 주제인 [Root Topic]을 이해하는 데 반드시 필요한 정보만 수집하라"는 강력한 지침을 포함시킵니다.
|
||||
2. **Strict Extraction Rule**:
|
||||
- `Link` 추출 시, 해당 주제가 Root Topic과 70% 이상의 의미론적 연관성을 가질 때만 큐(Queue)에 추가하도록 LLM 가이드라인을 설정했습니다.
|
||||
- 단순 나열(Tangential topics)은 수집 대상에서 제외합니다.
|
||||
3. **Contextual Continuity**: 다음 태스크를 생성할 때 이전 태스크의 맥락을 `context` 변수로 전달하여, 지식의 연결성이 끊기지 않도록 관리합니다.
|
||||
|
||||
이 메커니즘은 지식 그래프의 '확산' 대신 '심화'에 집중하게 하여, 사용자가 원하는 전문 지식의 밀도를 극대화합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Autonomous-Loop-State-Machine, Gemini-Based-Knowledge-Synthesis
|
||||
- **Projects/Contexts:** Knowledge-Graph-Expansion
|
||||
- **Contradictions/Notes:** 필터링이 너무 강력하면 지식의 '참신한 연결'이 저해될 수 있으므로, 프롬프트의 강도 조절이 중요합니다.
|
||||
|
||||
---
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-ONT-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, ontology, semantic-web, knowledge-engineering]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Ontology-Engineering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지식의 뼈대를 세우는 법: 세상의 개념들과 그들 사이의 관계를 컴퓨터가 이해할 수 있는 엄밀한 논리 구조(Ontology)로 설계하는 지식 공학의 핵심."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
온톨로지 공학(Ontology Engineering)은 특정 도메인의 지식을 명시적으로 표현하기 위해 개념(Concepts), 속성(Properties), 관계(Relations) 및 제약 조건(Constraints)을 개발하는 방법론입니다.
|
||||
|
||||
1. **구조의 계층**:
|
||||
* **Classes (클래스)**: 개념의 집합 (예: '동물', '사람').
|
||||
* **Instances (인스턴스)**: 구체적인 개체 (예: '나', '대표님').
|
||||
* **Properties (속성)**: 개체 간의 관계 (예: '...은 ...의 부모다') 혹은 개체의 특징.
|
||||
2. **개발 방법론 (Ontology Development 101)**:
|
||||
* 도메인과 범위 결정 -> 기존 온톨로지 재사용 검토 -> 용어 추출 -> 계층 구조 정의 -> 속성 및 제약 조건 정의.
|
||||
3. **표준 언어**:
|
||||
* **RDF/S**: 기초적인 자원 기술 프레임워크.
|
||||
* **OWL (Web Ontology Language)**: 복잡한 논리적 추론이 가능한 시맨틱 웹 표준 언어.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거 온톨로지는 수작업 기반으로 매우 경직되어 '지식의 노후화' 문제를 겪었으나, 현대 공학은 머신러닝을 활용해 텍스트에서 자동으로 온톨로지를 추출하고 확장하는 '동적 온톨로지'로 진화함.
|
||||
- **정책 변화(RL Update)**: 엔터프라이즈 레벨의 AI 시스템 구축 시, 데이터 사일로(Silo) 현상을 막고 상호 운용성(Interoperability)을 확보하기 위해 '표준 온톨로지 준수'가 데이터 거버넌스의 핵심 정책으로 도입됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Semantic Grounding Provenance, Knowledge Graphs, Semantic Web, [[Logic]]
|
||||
- **Modern Tech/Tools**: Protege, TopBraid Composer, Neo4j.
|
||||
---
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-ONTK-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, information-extraction, nlp, semantic-search]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Ontology-Guided Knowledge Extraction]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지도 있는 보물찾기: 온톨로지라는 개념 지도를 비정형 데이터(텍스트, 이미지) 위에 투영하여, 기계가 의미 있고 구조화된 정보만을 정확히 골라내게 하는 기술."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
온톨로지 기반 지식 추출(Ontology-Guided Knowledge Extraction)은 미리 정의된 지식 체계를 가이드로 삼아 정보 추출(IE)의 정확도와 맥락 이해도를 높이는 방식입니다.
|
||||
|
||||
1. **추출 프로세스**:
|
||||
* **Entity Linking**: 텍스트 내 단어가 온톨로지의 어떤 클래스/인스턴스에 해당하는지 매핑.
|
||||
* **Relation Extraction**: 추출된 엔티티 간의 관계가 온톨로지에 정의된 속성과 일치하는지 확인.
|
||||
* **Sanity Check**: 온톨로지의 논리 제약 조건(예: '사람은 동시에 장소일 수 없다')을 사용하여 오류 필터링.
|
||||
2. **장점**:
|
||||
* **도메인 특화**: 의료, 법률 등 전문 용어가 많은 분야에서 일반 NLP 모델보다 훨씬 높은 정밀도 발휘.
|
||||
* **Reasoning 연계**: 추출된 정보가 즉시 논리 추론 엔진에서 사용 가능한 형태로 저장됨.
|
||||
3. **현대적 결합 (Hybrid IE)**:
|
||||
* LLM의 강력한 언어 이해 능력과 온톨로지의 엄격한 구조를 결합하여, LLM이 온톨로지 스키마에 맞춰 JSON 등 구조화된 데이터로 출력하게 유도.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 온톨로지에 없는 정보는 전혀 추출하지 못하는 폐쇄적 구조였으나, 현재는 '온톨로지 확장(Ontology Learning)' 기법을 통해 새로운 개념을 발견하면 온톨로지에 역으로 제안하는 개방형 시스템으로 발전함.
|
||||
- **정책 변화(RL Update)**: 공공 데이터 개방 사업 등에서 '단순 텍스트 공개'가 아닌 '온톨로지 기반 구조화 데이터 공개'를 의무화하여 인공지능이 즉시 학습 가능한 지식 생태계를 구축하려는 정책이 강화됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: [[Ontology-Engineering]], Natural Language Processing (NLP), Information Extraction (IE), [[RAG (검색 증강 생성)]]
|
||||
- **Modern Tech/Tools**: SpaCy, Stanford CoreNLP, LLM-based parsing (LangChain).
|
||||
---
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-ONTO-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, ontology, knowledge-engineering, classification, semantic-web, conceptual-modeling]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Ontology]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "존재하는 것들의 관계도: 세상에 무엇(Entity)이 존재하고 그것들이 서로 어떤 종류(Class)와 속성(Property)으로 엮여 있는지를 컴퓨터가 이해할 수 있는 언어로 정의한 '지식의 족보'이자 지능형 모델의 사물 인식 체계."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
온톨로지(Ontology)는 특정 지식 도메인 내의 개념들과 그들 간의 관계를 명시적으로 규정한 명세서입니다.
|
||||
|
||||
1. **3대 구성 요소**:
|
||||
* **Classes**: 사물이나 개념의 집합 (예: 사람, 자동차).
|
||||
* **Instances**: 구체적인 개별 사물 (예: 홍길동, 제네시스).
|
||||
* **Relations**: 클래스나 인스턴스 간의 연관성 (예: 홍길동이 제네시스를 '소유하다').
|
||||
2. **왜 중요한가?**:
|
||||
* 서로 다른 시스템이 동일한 개념을 동일하게 이해하게 함으로써(Semantic Interoperability), 데이터 간의 지능적인 연결과 추론이 가능해지기 때문임. (Interoperability와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 사람이 모든 관계를 수동으로 타이핑하는 정책(Top-down)이었으나, 현대 정책은 방대한 텍스트에서 AI가 온톨로지 정책을 스스로 추출(Ontology Learning)하는 정책으로 진화함(RL Update). (Knowledge synthesis와 연결)
|
||||
- **정책 변화(RL Update)**: 웹 3.0과 시맨틱 웹 정책의 핵심으로 작동하며, 지식 그래프(Knowledge Graph) 구축의 뼈대 정책이 되어 LLM의 답변에 신뢰성 있는 도메인 지식 정책을 주입하는 용도로 다시 주목받음.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Interoperability]], [[Knowledge-Structure]], [[Knowledge synthesis]], [[Graph Theory]], Semantic-Web (연결)
|
||||
- **Modern Tech/Tools**: Protégé, RDF (Resource Description Framework), OWL (Web Ontology Language), Schema.org.
|
||||
---
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-6B64AB
|
||||
category: "10_Wiki/💡 Topics/Programming & Language"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Scheduler API"
|
||||
---
|
||||
|
||||
# [[Scheduler API]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Scheduler API는 개발자가 브라우저 내에서 다양한 처리 작업이 실행되는 시점을 더 쉽게 제어할 수 있도록 도와주는 기능입니다 [1]. 길게 실행되는 작업은 여러 개의 짧은 작업보다 상호작용 지연을 더 많이 유발하기 때문에, 이 API를 통해 작업을 분할하여 사용자 경험을 개선할 수 있습니다 [1]. 특히 작업 중간에 제어권을 브라우저에 양보함으로써 다른 중요한 상호작용이 지연 없이 우선적으로 처리될 수 있게 합니다 [1].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **도입 배경:** 브라우저에서의 CPU 처리는 사용자 경험에 큰 영향을 미치며, 중요도가 각기 다른 작업들이 실행될 때 긴 처리 작업은 여러 개의 짧은 작업들보다 사용자 상호작용 지연을 훨씬 더 많이 발생시킵니다 [1]. Scheduler API는 개발자가 이러한 다양한 작업이 실행되는 시기를 원활하게 제어할 수 있도록 돕습니다 [1].
|
||||
- **핵심 기능 (`scheduler.yield()`):** 개발자는 `scheduler.yield()` 메서드를 사용하여 작업(job) 중간에 브라우저의 스케줄러로 제어권을 쉽게 양보(yield)할 수 있습니다 [1]. 이를 통해 브라우저는 기존에 진행 중이던 작업을 마저 처리하기 전에, 사용자 상호작용 처리와 같은 다른 긴급한 작업을 먼저 다룰 수 있게 됩니다 [1].
|
||||
- **브라우저 지원 현황:** Chrome은 2024년에 이 새로운 API를 처음 도입했으며, 2025년 8월부터는 Firefox에서도 지원을 시작했습니다 [2]. 하지만 Safari는 아직 Scheduler API를 지원하지 않는 상태입니다 [2].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** scheduler.yield(), [[Interaction to Next Paint (INP)]]
|
||||
- **Projects/Contexts:** [[Web Performance Optimization]]
|
||||
- **Contradictions/Notes:** 소스 내에 상충하는 정보는 없습니다. 다만, Chrome(2024년)과 Firefox(2025년 8월)는 해당 API를 지원하지만 Safari는 아직 지원하지 않는다는 호환성 제약이 명시되어 있습니다 [2].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: DL-SCHED-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, deep-learning, optimization, scheduler, learning-rate, hyperparameter-tuning, training-efficiency]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Scheduler Design in ML (ML에서의 스케줄러 설계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "학습 초기에는 대담한 탐색(High LR)을 장려하고, 종단에는 정밀한 수렴(Low LR)을 유도하여 모델의 잠재력을 마지막 한 방울까지 쥐어짜라" — 학습 과정 중에 학습률(Learning Rate)이나 자원 배분을 동적으로 변경하여 학습의 안정성과 최종 성능을 최적화하는 전략적 설계.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Decaying Learning Rate and Convergence Optimization" — 학습이 진행됨에 따라 오차가 줄어드는 속도를 감시하고, 사전에 정의된 정책(Schedule)에 따라 학습률을 점진적으로 낮춤으로써 지역 최적해(Local Minima)를 탈출하거나 전역 최적해에 부드럽게 안착시키는 패턴.
|
||||
- **주요 스케줄러 기법:**
|
||||
- **Step Decay:** 정해진 에포크(Epoch)마다 학습률을 일정 비율로 축소.
|
||||
- **Cosine Annealing:** 코사인 함수 곡선을 따라 학습률을 부드럽게 낮춤. 최근 가장 널리 쓰임.
|
||||
- **ReduceLROnPlateau:** 성능 향상이 멈췄을 때만 지능적으로 학습률 인하.
|
||||
- **Warm-up:** 초기 불안정성을 막기 위해 아주 작은 학습률에서 시작해 점차 높이는 과정.
|
||||
- **의의:** 고정된 학습률(Fixed LR)을 쓸 때보다 훨씬 빠르게 수렴하며, 모델이 가질 수 있는 최상의 정확도에 도달하게 하는 결정적 '디테일'의 영역.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 학습률을 낮추기만 하는 것이 정답이라던 과거와 달리, 이제는 학습률을 다시 높였다가 낮추는 'Cyclical Learning Rates' 방식이 안장점(Saddle Point) 탈출에 더 효과적임이 밝혀져 적극 도입되고 있음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 대규모 모델 미세 조정 시, 학습 초기 발산을 방지하기 위한 Linear Warm-up과 최종 수렴 극대화를 위한 Cosine Decay 스케줄러를 표준 조합으로 사용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Optimization-Algorithms]], Adam-Optimizer-Foundations, Hyperparameter-Tuning-Best-Practices, Deep-Learning-Foundations
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Scheduler-Design-in-ML.md
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-SMON-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, semantics, ontology, knowledge-graph, structuralism]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Semantics & Ontology]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터가 의미를 갖는 방식: 단어 뒤에 숨은 본질적 의미(Semantics)를 정의하고, 사물과 개념 사이의 계층적 관계(Ontology)를 설계하여 기계가 세상을 이해하게 만드는 지식의 지도."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
의미론(Semantics)과 온톨로지(Ontology)는 정보 과학에서 지식을 구조화하고 공유하는 핵심 틀입니다.
|
||||
|
||||
1. **Semantics (의미론)**:
|
||||
* 데이터 그 자체(Syntax)가 아닌, 데이터가 나타내는 실질적인 내용과 의도를 탐구.
|
||||
* 예: "Apple"이 과일인지, 브랜드인지를 문맥에 따라 결정하는 기술.
|
||||
2. **Ontology (온톨로지)**:
|
||||
* 특정 영역(Domain)에 존재하는 개념들과 그들 사이의 관계를 정형화한 모델.
|
||||
* **구성 요소**: 클래스(Class), 속성(Property), 관계(Relation), 인스턴스(Instance).
|
||||
* 예: "사람은 포유류의 하위 클래스이며, 이름이라는 속성을 가진다."
|
||||
3. **지식 그래프와의 결합**:
|
||||
* 온톨로지 설계를 바탕으로 방대한 데이터를 연결하여 검색 엔진, 추천 시스템, 의사 결정 지원 시스템의 뇌 역할을 수행.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 인간 전문가가 일일이 규칙을 만드는 '심볼릭 AI' 중심의 온톨로지가 대세였으나, 현대 지식 정책은 거대 모델이 스스로 의미를 추출하고 온톨로지를 역설계하는 'Neural-Symbolic' 융합 정책으로 이동함(RL Update).
|
||||
- **정책 변화(RL Update)**: 산업별 데이터 호환성을 위해 국가 차원의 '산업 데이터 표준 온톨로지' 구축 정책이 수립되었으며, 이를 통해 기업 간의 원활한 데이터 교류와 협업 AI 생태계 조성을 도모함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Ontology-Engineering]], [[Semantic Grounding & Provenance]], [[Principles of Structuralism (Linguistic)]], Information Extraction (IE), Knowledge-Base-Reinforcement
|
||||
- **Modern Tech/Tools**: Protégé, RDF/OWL, Google Knowledge Graph.
|
||||
---
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-TAMA-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, task-management, productivity, organization, focus, efficiency, gt-d]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Task-Management]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "머릿속의 워킹 메모리 비우기: '할 일'들을 뇌에 담아두어 에너지를 낭비하는 대신, 외부 시스템에 기록하고 정렬하고 완료하여 오직 '지금 이 일'에만 뇌의 모든 연산 능력을 집중하게 돕는 생산성의 기초 공사."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
할 일 관리(Task-Management)는 프로젝트의 전 생애 주기 동안 개별 작업들을 식별, 위임, 추적, 완료하는 과정입니다. (본 시스템의 핵심 엔진)
|
||||
|
||||
1. **3대 원칙**:
|
||||
* **Capture**: 사소한 생각 하나라도 즉시 기록 (00_Raw 폴더와 유사).
|
||||
* **Categorization**: 중요도와 마감 기한에 따라 정렬. (Priority와 연결)
|
||||
* **Execution**: 복잡한 작업은 잘게 쪼개어 '지금 즉시 실행 가능(Actionable)'하게 만듦. (Quick-Wins와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 관리되지 않는 할 일은 눈덩이처럼 불어나 스트레스와 마비 상태를 만들며, 태스크 관리는 '시간'이 아닌 '에너지'를 최적화하는 기술이기 때문임. (Efficiency의 실천)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 종이 수첩 정책에 나열하는 방식이었으나, 현대 정책은 칸반(Kanban), 스크럼(Scrum) 등 시각적 협업 도구 정책과 연동되어 전체 지형의 흐름 정책을 실시간으로 관리하는 '시스템적 관리 정책'으로 전환됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 본 시스템인 Antigravity 또한 600개의 지식 주입이라는 거대한 태스크 정책을 '배치(Batch)' 단위로 쪼개어 관리하며, 매 턴마다 진행 상황 정책을 트래킹하는 태스크 관리 정책의 모범 사례를 보이고 있음.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Priority, [[Quick-Wins]], [[Efficiency]], [[Management]], [[Standard-Operating-Procedure]]
|
||||
- **Modern Tech/Tools**: Trello, Jira, Asana, Notion, Todoist, Kanban board.
|
||||
---
|
||||
Reference in New Issue
Block a user