위키

- CDLC(Context Development Lifecycle) 는 Generate, Evaluate, Distribute, Observe의 네 단계로 구성된다 - Generate에서는 **암묵지**를 기술·프로젝트·비즈니스 맥락으로 **구조화** - Evaluate에서는 시나리오 기반으로 컨텍스트가 의도한 결과를 내는지 **테스트**한다. - Distribute에서 **컨텍스트를** 버전된 패키지처럼 **배포·업데이트** - Observe에서 실제 에이전트 동작을 관찰해 부족한 맥락과 드리프트를 찾아 **반복 개선**한다.

- 소프트웨어의 중심이 사람을 위한 대시보드 사용에서 API를 통해 시스템을 오가는 에이전트 실행으로 이동 - B2B에서 B2A(Business to Agent)로의 전환. - 앞으로는 UI 완성도보다 API의 속도, 신뢰성, 데이터 모델, 문서화, 오류 처리 품질이 구매 결정의 중심이 된다는 전망이다. - WebMCP 같은 표준이 확산되면 “모든 SaaS는 사실상 API”가 될 수 있다

- Peter Steinberger의 방식은 과한 오케스트레이션 대신 단일 저장소, 단일 개발 서버, 단일 main 브랜치에서 여러 Codex 인스턴스를 동시에 운영 - 핵심은 작업을 명확히 쪼개 에이전트 간 파일 충돌을 줄이고, 변경 파일 기준으로 atomic commit을 만들기 - 하지만 네이티브 앱처럼 에이전트가 실제 컴퓨터 접근으로 테스트해야 하는 경우에는 동시 검증이 어려움

- 문제의 본질은 에이전트의 코딩 능력 부족이 아니라, 사람의 주의력과 운영 부담이 쉽게 확장되지 않음 - 자동 피드백 루프. CI 실패나 리뷰 변경 요청이 발생하면 오케스트레이터가 해당 컨텍스트를 다시 에이전트 세션에 주입해 수정하도록 구성 - 개별 모델 성능 경쟁보다 병렬 작업을 배치하고 관찰하며 교정하고 개선하는 오케스트레이션 시스템

- 소프트웨어가 사람과 에이전트의 지속적인 관계 속에서 만들어지는 결과물 - 익숙한 소통, 피드백, 교육의 능력으로 에이전트를 길들이는 방식 - 역할별로 전문화된 에이전트 팀을 전제 - 개인 에이전트(deputies)와 권한·규칙을 관리하는 상위 에이전트(Sheriff) 같은 구조를 통해, 에이전트가 조직도와 유사하게 배치

- 좋은 아이디어를 실제로 돌아가는 자동화로 바꾸려면 "프롬프트", "작업 구조", "검증 기준"을 함께 설계 - 중요한 역량은 "UI", "플로우", "제약", "통합 조건"을 명확히 언어화하고 "검증 기준"까지 설계하는 능력

- compaction 자체가 문제가 아니라, compaction 전에 기록되지 않은 정보가 사라지는 구조

- 복잡한 기능 추가가 아닌 모델이 잘하는 영역에 맞춘 단순한 제품설계와 빠른 반복 - 엔지니어 역할: 문제 정의, 검증, 운영 콘텍스트 지휘

- CLAUDE.md의 핵심이 내 프로젝트에만 필요한 지속적 맥락을 정확히 담는 데 있다 - 예를 들어 build/test/lint/run의 정확한 명령어, env var 관리 방식, 비표준 프로젝트 구조, 팀 고유 코딩 규칙, 알려진 footgun, 모듈 경계와 소유권, 테스트 패턴처럼 코드만으로 추론하기 어려운 정보 - 반대로 “읽기 좋은 코드 작성” 같은 일반론, 코드에 이미 드러난 사실, secrets/credentials, 오래된 지침, 지키지 않는 이상적 규칙, 장황한 아키텍처 에세이는 노이즈

- 무엇이 실제로 일어났는지”를 보여 주는 유일한 기록이 트레이스라는 주장이다. - 실패 원인 분석, 프롬프트 개선 전후 비교, 반복 실수 패턴 탐지처럼 기존의 코드 중심 작업이 트레이스 비교와 분석 중심으로 바뀐다고 본다. - 예시로 같은 실패 API 호출을 반복하는 에이전트 문제를 들며, 코드의 재시도 로직이 정상이어도 추론 품질 문제는 트레이스에서만 드러날 수 있다고 설명한다

- Claws는 orchestration, scheduling, context, tool calls, persistence를 더 끌어올리는 다음 레이어 - config 파일 대신 skills로 설정을 다루는 방식 밝힌다. - /add-telegram처럼 에이전트가 실제 코드를 수정해 통합하도록 지시하는 패턴은

- AI 시대에 코딩의 본질은 ‘직접 작성’에서 ‘지시·검토·배포’로 이동 - AI가 더 이상 코드 생성 도구에 머물지 않고, 피드백·버그 리포트·텔레메트리까지 해석해 기능 아이디어를 제안하는 ‘동료’ - 실행 원칙. 지금의 모델이 아니라 6개월 뒤 모델을 기준으로 설계하고, 사용자가 억지로 시도하는 행동에서 잠재 수요를 찾으며, 초기에는 토큰 비용 최적화보다 실험 속도를 우선하라는 제안 - 인원을 의도적으로 제한해 AI 위임을 강제하고, 싼 모델보다 유능한 모델을 써 재작업 비용을 줄이라는 운영 철학

- “누가 코드를 썼는가”보다 “문제가 났을 때 누가 복구하고 손실을 최소화할 수 있는가 - 미래 실패를 설계 단계에서 얼마나 대비하느냐 - 인증 기능에서 엔지니어는 rate limiting, 세션 타임아웃, 보안 로그, 비밀번호 재설정 검증, 정보 노출 없는 에러 처리, 이상 징후 모니터링, 사고 대응 문서화까지 포함해 운영 가능한 시스템 - 엔지니어는 명시적 파싱과 테스트, 배치·청크 처리, 요구 재정의, 캐시·저비용 모델·예외 처리 분리 같은 현실 제약 기반 의사결정 - 검증·운영·비용·보안까지 포함한 책임 체계

- tmux와 Zellij를 결합(세션 관리와 인터페이스를 빠르게 통합) - tmux 세션 관리를 위해 Zellij로 감싸 세션 선택 기능

- 무엇을 읽고 어떻게 통제하느냐의 중심이 코드 자체에서 컨텍스트로 이동 - 코드를 통째로 맡긴 경우와 개념만 묻고 직접 작성한 경우의 극단적 격차 - 대규모 코드를 가능하게 한 핵심 투자는 문서, 테스트, 린터, 아키텍처 규약 - 스펙·테스트 의도·설계 기록·도메인 모델·에이전트 지시 문서

빨리 만드는 능력”보다 “무엇을 왜 만드는가”를 증명하는 능력이

- AI 에이전트를 24/7로 운영하며 리서치, 콘텐츠 작성, 코드 리뷰, 뉴스레터 작업을 자율 처리 - 새 계정과 범위 제한 API 키를 부여

- 세션별 큐로 동시성 제어 - 컴포넌트별 역할과 책임 분배 - fallback 과 최대 시도 횟수 제한

model: 신경망(ex) opus 4.6) harness: 에이전트(ex) claude code) surfaces: 사용자가 AI를 사용하는 UI