위키 동기화 2026-06-19: 보안 트러블슈팅 노트·회의록·lessons·Digests + ASTRA 성장 산출물
- 00_Raw: ASTRA 보안 가이드 3종(SSRF/셸 명령/파일 경로 경계), 회의록 p/q/r 추가 - Topics: Digests 5종, lessons 4종, 메모리 에피소드/장기기억 갱신 - .astra: growth(decay/regression/weakness)·eval(corrections/report) 학습 산출물 갱신 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Agent"
|
||||
generated_at: 2026-06-18T18:01:28.797Z
|
||||
sources: ["self envolving", "self evolving", "Value Proposition Canvas", "Zero-Trust Foundation Models"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Agent
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: Self-Evolving Agent(자가 진화 에이전트)란 무엇이며, 기존 LLM과 무엇이 다른가요?** — A: 정적인 모델의 한계를 넘어, 인간의 개입 없이 스스로 코드, 도구, 아키텍처를 재설계하여 성능을 개선하는 지능형 시스템입니다. 기존 모델이 고정된 파이프라인을 따르는 것과 달리, 실시간 데이터와 경험을 통해 자율적으로 변화합니다. [self envolving / self-evolving]
|
||||
- **Q: Value Proposition Canvas(VPC)를 사용할 때 '검증 공백'이 발생하는 경우는 언제인가요?** — A: 제품의 고통 완화제(Pain Relievers)가 고객의 최상위 3개 과업(Jobs-to-be-Done)과 제대로 연결되지 않을 때 발생합니다. [Value Proposition Canvas]
|
||||
- **Q: Zero-Trust Foundation Models(ZTFM)의 핵심 보안 원칙은 무엇인가요?** — A: '지속적 검증'과 '최소 권한 원칙'입니다. 에이전트의 모든 상호작용을 매번 확인하고, 임무 수행에 필요한 최소한의 권한만 부여하여 피해를 최소화합니다. [Zero-Trust Foundation Models]
|
||||
- **Q: 자가 진화 에이전트에서 '재귀적 자가 설계(Recursive Self-Design)'는 어떤 의미인가요?** — A: 단순히 하이퍼파라미터를 최적화하는 수준을 넘어, 에이전트의 프롬프트 정책, 워크플로우, 실행 메커니즘 등 시스템의 스캐폴드 자체를 수정 대상으로 삼는 것을 의미합니다. [self envolving / self-evolving]
|
||||
- **Q: VPC를 통해 제품 개발 과정에서 수행할 수 있는 검증 단계는 무엇인가요?** — A: 문제 검증(문제가 해결 가치가 있는가), 솔루션 검증(해결책이 근본 원인을 해결하는가), 비즈니스 모델 검증(고객이 실제 비용을 지불하는가)의 3단계 계층 구조를 따릅니다. [Value Proposition Canvas]
|
||||
|
||||
## 핵심 사실
|
||||
- **Self-Evolving Agent의 진화 차원**: 무엇을(모델/정책, 컨텍스트/메모리, 도구/기술), 언제(실행 중 진화 vs 실행 간 진화) 진화시킬 것인지가 핵심입니다. [self envolving / self-evolving]
|
||||
- **VPC의 전략적 가치**: 제품 기능과 고객 요구 사이의 정렬을 시각화하여 '문제-해액 적합성'을 검증하고 자본 효율성을 극대화합니다. [Value Proposition Canvas]
|
||||
- **ZTFM의 적용 분야**: 6G 생태계 및 IoT 환경에서 에이전트 간의 안전한 협업과 적대적 공격으로부터 시스템을 보호하는 데 필수적인 인프라입니다. [Zero-Trust Foundation Models]
|
||||
|
||||
## 문서 간 연결
|
||||
- **기술적 상호보완성**: `self-evolving` 기술은 자율성이 높아지는 만큼 보안 위협이 커지므로, 이를 방어하기 위한 `Zero-Trust Foundation Models`의 도입이 필수적인 관계에 있습니다.
|
||||
- **비즈니스와 기술의 결합**: `Value Proposition Canvas`는 제품의 가치를 정의하는 도구이며, `self-evolving` 에이전트가 생성하는 새로운 기능이나 '도구 제작(Tool Maker)' 패턴은 이러한 가치 제안을 실현하는 기술적 수단이 될 수 있습니다.
|
||||
- **패턴의 공통성**: 여러 문서에서 '자율적 학습', '재귀적 구조', '지속적 검증'과 같은 자동화된 피드백 루프와 자기 개선(Self-improvement) 메커즘을 공통적으로 다루고 있습니다.
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Engineering_Intelligence"
|
||||
generated_at: 2026-06-18T18:01:19.599Z
|
||||
sources: ["안티패턴_카탈로그", "엔지니어링_트레이드오프_분석", "아키텍처_휴리스틱", "디버깅_플레이북"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Engineering_Intelligence
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 코드를 작성할 때 에러를 `try { ... } catch {}`로 처리하면 왜 위험한가요?** — A: 에러를 이유 없이 삼키면(Silent swallow) 실패가 숨겨져 디버깅이 불가능해지고 시스템이 잘못된 상태로 진행될 수 있기 때문입니다. 단, 부가 작업에 한해 이유를 주석으로 명시하고 처리하는 것은 허용됩니다. [안티패턴 카탈로그]
|
||||
- **Q: 에이전트 설계를 할 때 '에이전트 남발'을 피하기 위한 기본 원칙은 무엇인가요?** — A: 기본값은 "에이전트를 늘리지 않는 것"입니다. 문제마다 새 페르소나를 추가하면 컨텍스트 누적, 자원 폭증, 디버깅 난해 등의 문제가 발생하므로, 단일 작성자가 다중 역할을 수행하거나 정말 필요한 경우에만 순차적으로 협업하도록 설계해야 합니다. [안티패턴 카탈로그, 아키텍처 휴리스틱]
|
||||
- **Q: 5계층 메모리 시스템에서 발생할 수 있는 주요 장애와 진단 방법은 무엇인가요?** — A: 오래된 사실을 현재로 착각하거나 기억이 반영되지 않는 장애가 발생할 수 있습니다. 이는 `expiresAt` 미설정이나 추출 실패 때문일 수 있으며, 진단 시에는 계층별 `buildContext` 출력을 확인해야 합니다. [디버링 플레이북, 5계층 메모리 시스템]
|
||||
- **Q: 하이브리드 검색(RAG)의 성능을 높이기 위한 예방 조치는 무엇인가요?** — A: 정기적인 평가 하니스 실행, 정규화 일관성 유지, 인덱스 무결성 점검 등이 필요합니다. [디버깅 플레이북, RAG 검색 파이프라인]
|
||||
- **Q: 동시성 제어를 위한 락(Lock) 사용 시 반드시 지켜야 할 예방 규칙은 무엇인가요?** — A: 락은 반드시 `try/finally` 구문을 사용하여 release 누락을 방지해야 하며, 토큰 기반으로 정리하고 무거운 작업은 직렬화해야 합니다. [디버깅 플레이북, 동시성 제어 Lock Queue Transaction]
|
||||
|
||||
## 핵심 사실
|
||||
- **안티패턴의 정의:** 안티패턴은 처음에는 그럴듯해 보이지만 시간이 지나면 버그와 복잡도를 유발하는 습관이며, ConnectAI의 실제 사례에서 추출된 피해야 할 목록입니다. [안티패턴 카탈로그]
|
||||
- **설계의 본질:** 모든 설계는 무언가를 최적화하기 위해 다른 무언가를 희생한 결과(Trade-off)입니다. [엔지니어링 트레이드오프 분석]
|
||||
- **아키텍처 결정 규칙(휴리스틱):** 좋은 설계자는 0부터 고민하는 것이 아니라, "언제 X를 만들고 언제 만들지 않을 것인가"에 대한 결정 규칙을 적용합니다. [아키텍처 휴리스틱]
|
||||
- **디버깅의 원칙:** 디버깅은 증상에서 근본 원인으로 좁혀 들어가는 체계적인 절차이며, '증상 $\rightarrow$ 가설 $\rightarrow$ 검증 $\rightarrow$ 최소 변경'의 과정을 거칩니다. [디버깅 플레이북]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제:** 모든 문서는 소프트웨어 엔지니어링의 **'의사결정 지능(Decision Intelligence)'**을 다루고 있습니다. 안티패턴은 '피해야 할 것', 트레이드오프는 '선택의 근거', 휴리스틱은 '판단 기준', 플레이북은 '사후 대응'이라는 측면에서 상호 보완적입니다.
|
||||
- **상호 참조 관계:**
|
||||
- **[안티패턴] $\leftrightarrow$ [트레이드오프]:** 에이전트 남발(A-04)과 멀티에이전트 설계의 최적화/희생 관계는 서로 연결됩니다.
|
||||
- **[아키텍처 휴리스틱] $\leftrightarrow$ [디버깅 플레이북]:** 특정 기술(예: 락, 메모리 타입)을 언제 사용하는지에 대한 규칙(휴리스틱)은 해당 기술이 실패했을 때의 대응책(플레이북)과 직결됩니다.
|
||||
- **[ConnectAI 사례]:** 모든 문서는 ConnectAI 프로젝트에서 실제로 검증되고 적용된 사례를 바탕으로 구성되어 있어 데이터의 일관성을 가집니다.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Pattern_Catalog"
|
||||
generated_at: 2026-06-18T18:01:08.478Z
|
||||
sources: ["React_State_Pattern", "Repository_Pattern", "Infinite_Scroll_Pattern", "JWT_Authentication_Pattern", "Push_Notification_Pattern"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Pattern_Catalog
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: React에서 상태를 관리할 때 가장 권장되는 위치와 방법은 무엇인가요?** — A: 상태를 필요한 가장 낮은 곳에 두되, 공유가 필요하면 부모로 끌어올리고(lifting state up), 서버 데이터는 UI 상태와 분리하여 캐시 라이브러리(react-query 등)를 사용하는 것이 핵심입니다. [React State Pattern]
|
||||
- **Q: Repository 패턴을 사용할 때 얻을 수 있는 이점과 주의할 점은 무엇인가요?** — A: 도메인 로직을 저장 기술(DB, API 등)로부터 분리하여 테스트와 구현 교체가 용이하다는 장점이 있지만, ORM이 이미 유사한 추상을 제공하는 경우 중복 설계가 될 수 있으므로 주의해야 합니다. [Repository Pattern]
|
||||
- **Q: 무한 스크롤 구현 시 성능 저하를 막기 위해 반드시 포함해야 할 요소는 무엇인가요?** — A: 커서 기반 페이징, DOM 가상화(virtualization), 그리고 중복/경쟁 요청 방지 로직이 필수적입니다. [Infinite Scroll Pattern]
|
||||
- **Q: JWT 인증 방식의 구조적 약점과 이를 보완할 방법은 무엇인가요?** — A: 토큰을 즉시 무효화하기 어렵다는 것이 약점이며, 이를 위해 Access/Refresh Token의 수명을 분리하거나 블랙리스트/토큰 회전(Rotation) 방식을 사용하여 보완할 수 있습니다. [JWT Authentication Pattern]
|
||||
- **Q: React 상태 관리 시 '파생 상태'를 처리하는 올바른 방법은 무엇인가요?** — A: 파생된 값은 별도로 저장하지 않고 `useMemo`를 통해 계산하여 사용합니다. [React State Pattern]
|
||||
|
||||
## 핵심 사실
|
||||
- **React State Pattern:** 상태는 최소 단위에 두되, 공유 시 끌어올리고 서버 데이터는 분리함. 파생 상태는 저장하지 않고 계산함. [React State Pattern]
|
||||
- **Repository Pattern:** 도메인 코드와 데이터 저장 방식 사이에 인터페이스를 두어 결합도를 낮춤. [Repository Pattern]
|
||||
(참고: ConnectAI의 `eventSourcedStore`는 Repository 패턴을 적용한 사례임)
|
||||
- **Infinite Scroll Pattern:** 커서 기반 페이징과 DOM 가상화가 성능 유지의 핵심임. [Infinite Scroll Pattern]
|
||||
- **JWT Authentication Pattern:** 서버 세션 없이 상태를 유지(stateless)하는 방식이며, 확장성이 좋으나 즉시 무효화가 어렵다는 특징이 있음. [JWT Authentication Pattern]
|
||||
|
||||
## 문서 간 연결
|
||||
- **상태 관리와 데이터 접근의 관계:** `React State Pattern`은 프런트엔드 UI 상태 관리에 집중하며, `Repository Pattern`은 백엔드/데이터 계층의 추상화에 집중합니다. 두 패턴 모두 '관심사의 분리'를 지향합니다.
|
||||
- **공통 주제 (Pattern Catalog):** 모든 문서는 웹 및 소프트웨어 공학의 설계 패턴을 다루고 있으며, 특정 기술(React, SQL, JWT)에 종속되지 않는 추상화된 구조를 제안합니다.
|
||||
- **기술적 상호보완:** `Infinite Scroll Pattern`은 대량의 데이터를 처리할 때 `React State Pattern`에서 관리하는 상태(로컬/서버)와 결합되어 동작하며, `JWT Authentication Pattern`은 API 호출 시 보안을 위한 인증 수단으로 사용됩니다.
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Platform_Guides"
|
||||
generated_at: 2026-06-18T18:01:47.199Z
|
||||
sources: ["웹_개발_가이드", "백엔드_API_개발_가이드", "AI_에이전트_개발_가이드", "데스크탑_앱_개발_가이드"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Platform_Guides
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 웹 개발 시 상태 관리의 핵심 원칙은 무엇인가요?** — A: 서버 데이터와 UI 상태를 분리하고, 단방향 데이터 흐름(SSOT)을 유지하며, 가능한 한 낮은 곳에서 상태를 관리하는 것이 원칙입니다. [웹 개발 가이드]
|
||||
- **Q: 백엔드 API 설계 시 '멱등성'이 왜 중요한가요?** — A: 동일한 요청이 여러 번 전달되어도 결과가 같아야 시스템의 신뢰성을 보장할 수 있기 때문입니다. 이는 복원력 있는 시스템 구축의 핵심입니다. [백엔드 API 개발 가이드]
|
||||
- **Q: AI 에이전트 개발에서 '환각(Hallucination)' 문제를 줄이기 위한 전략은 무엇인가요?** — A: RAG(검색 증강 생성) 활용, 강력한 Grounding, 자기 검증(Critic/Reflection) 레이어 구축, 그리고 프롬프트 엔지니어링을 통한 결정론적 응답 유도가 필요합니다. [AI 에이전트 개발 가이드]
|
||||
- **Q: 데스크탑 앱 개발 시 메모리 누수를 방지하기 위한 가장 좋은 방법은 무엇인가요?** — A: 모든 자원을 사용한 후 `dispose`를 등록하고, 무거운 작업은 UI 스레드가 아닌 워커 큐나 별도 프로세스로 분리하여 관리해야 합니다. [데스크탑 앱 개발 가이드]
|
||||
- **Q: 백엔드 아키텍처에서 마이크로서비스(MSA) 도입 시 고려해야 할 트레이드오프는 무엇인가요?** — A: 독립적인 확장과 배포가 가능하지만, 분산 시스템 특유의 복잡도와 데이터 일관성 문제를 감수해야 합니다. 따라서 초기에는 모놀리스로 시작하는 것을 권장합니다. [백엔드 API 개발 가이드]
|
||||
|
||||
## 핵심 사실
|
||||
- **웹 개발:** 프레임워크보다 상태, 비동기, 데이터 흐름, 에러, 계층 분리라는 본질적 문제를 푸는 것이 중요함. [웹 개발 가이드]
|
||||
- **백엔드 개발:** 계층 분리(라우터→서비스→리포지토리)와 명확한 API 계약이 신뢰성의 핵심임. [백엔드 API 개발 가이드]
|
||||
- **AI 에이전트:** RAG, 메모리, 도구 호출, 검증의 조합이 핵심이며, 특히 작은 모델일수록 자기 검증과 강한 Grounding이 품질을 결정함. [AI 에이전트 개발 가이드]
|
||||
- **데스크탑 앱:** 프로세스 분리(UI↔백그라운드)와 자원 관리(Lifecycle/Dispose)가 안정성의 핵심임. [데스크탑 앱 개발 มี 가이드]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제 (Software Engineering Principles):** 모든 문서는 공통적으로 **계층 분리(Layered Architecture)**, **에러 핸들링 패턴**, **테스트 전략(단위/통합/E2E)**, 그리고 **확장성(Scaling) 전략**을 핵심 설계 원칙으로 다루고 있습니다.
|
||||
- **상호 보완적 관계:** 웹/백엔드 가이드가 일반적인 시스템의 구조적 안정성을 다룬다면, AI 에이전트 가이드는 그 시스템 내에서 지능형 로직을 구현하기 위한 특화된 아키텍처(RAG, Memory)를 설명합니다.
|
||||
- **실증 사례 연결:** 모든 가이드는 `ConnectAI`라는 프로젝트의 실제 적용 사례나 구조(VS Code 확장, 웹뷰 UI 등)를 통해 이론의 실재성을 뒷받침하고 있습니다.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Subsystems"
|
||||
generated_at: 2026-06-18T18:01:38.365Z
|
||||
sources: ["TFIDF_이중언어_스코어링", "LLM_프로바이더_추상화", "RAG_검색_파이프라인", "Agent_오케스트레이터_분해"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Subsystems
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: ConnectAI의 검색 엔진은 어떤 방식으로 작동하나요?** — A: 임베딩 엔진 없이도 가벼운 검색이 가능하도록 '좋은 토크나이저'와 'TF-IDF 가중치'를 사용합니다. 한국어/영어 혼합 토크나이저, 불용어 제거, 동의어 확장, 제목 가중치(3배) 등을 적용하여 단순 매칭 이상의 점수를 산출합니다. [TF-IDF 이중언어 스코어링]
|
||||
- **Q: 다양한 LLM 공급자(Provider)를 하나의 코드로 관리하는 방법은 무엇인가요?** — A: '어댑터 패턴'을 사용합니다. Model ID의 접두사(prefix)로 공급자를 결정하는 라우팅 방식을 사용하며, 각 공급자의 API 차이(인증, 바이트 형식 등)는 어댑터가 흡수하고 출력은 OpenAI 호환 SSE 포맷으로 정규화하여 통일합니다. [LLM 프로바이더 추상화]
|
||||
- **Q: RAG 파이프라인에서 검색된 결과의 우선순위는 어떻게 결정되나요?** — A: 소스별로 점수를 0~1로 정규화한 후 소스 우선순위 가중치를 곱합니다. 이후 Actionability(작업 상태 신호)와 Hierarchical(질의/문서 매칭) 지표로 재가중(Re-rank)하여 최종 선택합니다. [RAG 검색 파이프라인]
|
||||
- **Q: 에이전트 오케스트레이터 설계 시 'God-class' 문제를 어떻게 해결했나요?** — A: 거대한 하나의 클래스가 모든 것을 처리하는 대신, 전체 흐름의 골격만 유지하고 세부 구현은 `handlePrompt`, `llm`, `actions` 등의 모듈로 추출하여 위임하는 구조를 가집로 유지보수성을 높였습니다. [Agent 오케스트레이터 분해]
|
||||
|
||||
## 핵심 사실
|
||||
- **TF-IDF 스코어링:** 한글-영문 경계 분리 정규식을 사용하며, 제목 일치 시 본문보다 3배 높은 가중치를 부여합니다. [TF-IDF 이중언어 스코어링]
|
||||
- **LLM 라우팅:** `anthropic:`, `gemini:` 등 모델 ID의 접두사(prefix)를 통해 공급자를 결정하며, 로컬 엔진 사용 시에는 접두사가 없는 형태를 따릅니다. [LLM 프로바이더 추상화]
|
||||
- **RAG 검색 단계:** 질의 계획 $\rightarrow$ 다중 소스 병렬 검색 $\rightarrow$ 점수 정규화 및 재가중 $\rightarrow$ 토큰 예산 내 선택 순으로 진행됩니다. [RAG 검색 파이프라인]
|
||||
- **멀티에이전트 전략:** 단순한 병렬 실행보다 자원 제약에 맞춘 '순차 실행'과 단일 작성자가 여러 역할을 수행하는 'ChunkedWriter' 방식이 더 견고합니다. [Agent 오케스트레이터 분해]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제:** 모든 문서는 ConnectAI 시스템의 효율적인 구조 설계(검색, LLM 호출, 에이전트 실행)를 위한 아키텍처 패턴(어댑터, 오케스트레이터 분해, 모듈화)을 다루고 있습니다.
|
||||
- **기술적 연결:**
|
||||
- `TF-IDF 스코어링`의 토크나이저 기술은 `RAG 검색 파이프라인`의 첫 단계인 Query Planning과 직접적으로 연결됩니다.
|
||||
- `LLM 프로바이더 추상화`를 통해 정규화된 출력(SSE)은 `Agent 오케스트레이터`가 사용자에게 진행 상황을 전달하는 메시지 프로토콜(`streamChunk` 등)의 기반이 됩니다.
|
||||
- `RAG 파이프라인`에서 사용하는 섹션 청킹 기술은 `TF-IDF 스코어링`의 정밀도를 높이는 요소로 작용합니다.
|
||||
Reference in New Issue
Block a user