2026 년 모두가 사용해야 할 AI 에이전트 메모리 스택 (빌더 가이드)

당신의 모델과 하네스는 더 이상 중요하지 않습니다.

이제 더 중요한 것은.....

바로 당신의 개인 컨텍스트/공유 메모리입니다

소개

코딩 에이전트를 위한 공유 메모리를 구축하는 방법을 알려드리겠습니다... 그래야 다음 도구가 이미 내린 결정을 찾을 수 있습니다.

Claude에서의 아키텍처 논의, Codex에서의 디버깅 세션, Cursor에 묻혀 있는 설명... 도구를 바꾸거나, 새 세션을 시작하거나, 한 달 후에 프로젝트로 돌아왔을 때도 여전히 사용할 수 있어야 하는 유용한 작업들입니다.

요약하자면, 3,845단어를 모두 읽고 싶지 않다면 이 GitHub 저장소를 에이전트에 전달하세요 ➡️ https://github.com/codejunkie99/agentic-stack-desktop

이 모든 것은 Codex Harness에서 Kimi K3를 사용하여 구축했습니다. 비디오는 Computer Use를 위한 Cua와 함께 Kimi K3를 사용하여 제작 및 편집되었습니다.

이것은 첫 번째 가져오기부터 에이전트가 이전 결정을 복구하고, 현재 코드와 비교하여 확인하고, 제한된 변경을 수행하고, 유용한 것을 남길 수 있는 워크플로우까지, agentic stack desktop에 대한 빌더 가이드입니다.

얻을 수 있는 것:

1. 기초: 도구를 전환할 때 살아남는 것
2. 가장 빠른 경로: 평가할 수 있는 워크스페이스 구축
3. 작동 설정: 조사와 구현 분리
4. 프로젝트 실습: 반복되는 버그를 전체 사이클로 처리
5. 공유 계층: 다른 도구로 검색 기능 가져오기
6. 지속 계층: 교훈이 될 가치가 있는 것
7. 운영 규칙: 간결하고, 경계를 정하고, 검사
8. 맞춤형 빌드: 실제 마찰 지점을 중심으로 워크스페이스 변경
9. 확장: 이전 사이클에서 노출된 격차를 해소
10. 빌드 시트

1. 기초: 도구를 전환할 때 살아남는 것

기능이 어떻게 작동해야 하는지 결정하는 데 오후 내내 시간을 보냈다고 상상해보세요. 대안을 탐색하고, 제약 조건을 발견하고, 명백한 해결책을 기각하고, 마침내 적합한 것을 찾았습니다.

구현은 커밋됩니다. 설명은 대화 속에 남아 있습니다.

일주일 후, 다른 에이전트가 코드를 보고 이미 기각했던 동일한 접근 방식을 제안합니다. 사용 가능한 정보로는 합리적인 제안일 수도 있습니다. 빠진 부분은 다르게 선택하게 만든 논의입니다.

추론을 복구 가능하게 만드세요

여기서 시작하세요: 그 논의를 복구 가능하게 만든 다음, 다음 에이전트가 행동하기 전에 확인하도록 만드세요.

agentic stack은 Claude Code, Codex, OpenCode 및 Cursor의 검색 가능하고 선별된 기록을 갖춘 네이티브 macOS 워크스페이스를 제공합니다. Claude Code와 Codex는 공식 CLI를 통해 실행됩니다. Cursor와 OpenCode는 현재 컨텍스트만 제공합니다. 저장소 개요

아래 워크플로우는 제가 이러한 기능을 사용하는 방법입니다. 브리핑, 책임 분담 및 프로젝트 실습은 여러분이 적용할 수 있는 제안된 운영 방식입니다.

2. 가장 빠른 경로: 평가할 수 있는 워크스페이스 구축

이해하는 저장소부터 시작하세요. 중요한 파일을 알고, 최근 결정을 기억하며, 잘못된 추천을 인식할 수 있는 것을 선택하세요.

익숙한 프로젝트는 기준점을 제공합니다. 익숙하지 않은 코드와 익숙하지 않은 기록으로 시작하면 도구를 검증하고 시스템을 동시에 배우려고 시도하게 됩니다.

소스 빌드의 경우, 문서화된 요구 사항에는 macOS 14+, Python 3.10+, Xcode Command Line Tools 및 Swift 6 툴체인이 포함됩니다. 실행하려는 코딩 CLI를 설치하고 로그인하세요. 요구 사항

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

앱에서 저장소를 열고 Guided 설정을 완료하세요. 이것은 임시 서명이 있는 미리보기이므로, macOS는 첫 실행 시 확인을 요구할 수 있습니다. 설정

첫 번째 수용 기준 설정

무엇이든 가져오기 전에, 첫 번째 에이전트가 답변해야 할 질문을 적어 두세요. 예를 들어, 내보내기 작업이 레코드를 배치로 처리하는 이유와 현재 구현에 여전히 그 제한이 필요한지와 같은 것입니다.

그 질문이 첫 번째 수용 기준이 됩니다. 올바른 결정, 올바른 지원 코드, 그리고 에이전트가 확인할 수 없는 것에 대한 정직한 설명을 찾고 있는 것입니다.

2.1 첫 번째 가져오기: 찾을 가치가 있는 결정 제공

Knowledge Graph → Graph → Import memory를 열고, 소스를 미리 본 다음 포함하려는 자료를 선택하세요.

그래프는 SQLite 전체 텍스트 검색을 사용하며, 주제, 저장소 링크 및 출처를 기반으로 연결됩니다. 원본 채팅 저장소는 변경되지 않습니다. 가져오기 동작

기억하는 결정이 포함된 완료된 대화부터 시작하는 것이 좋습니다. 특히 최종 코드에서는 명확하지 않을 제약 조건 때문에 매력적인 것을 기각했던 결정이 좋습니다.

가져온 후 해당 결정을 검색하세요. 결과를 열고 소스를 검사하세요. 의도한 대화를 가져왔는지, 그리고 무슨 일이 있었는지 이해할 수 있을 만큼 충분한 설명이 포함되어 있는지 확인하세요.

다시 찾을 수 있는지 테스트

그런 다음 다음 달에 자연스럽게 사용할 어휘를 사용하여 두 번째 검색을 시도해 보세요. 대화에서 내부 모듈 이름을 사용한 반면, 기능 이름을 기억할 수도 있습니다. 지금 그 불일치를 찾으면 나중에 자료를 검색하는 방법을 이해하는 데 도움이 됩니다.

첫 번째 컬렉션은 수동으로 검사할 수 있을 만큼 작게 유지하는 것이 좋습니다. 알려진 소스의 정답은 워크플로우가 작동한다는 유용한 증거입니다.

많은 가져오기 수는 시스템에 얼마나 많은 자료가 들어갔는지 알려주지만, 유용성은 테스트를 통해 확인해야 합니다.

다른 작업이 이유를 제공할 때 컬렉션을 확장하세요.

2.2 첫 번째 작업 세션: 실험을 완료할 수 있을 만큼 작게 만드세요

다른 설정 화면을 열기 전에 초기 설정에 완료 지점을 두는 것이 좋습니다. 세션이 끝날 때까지 알려진 결정을 복구하고, 저장소에 대해 확인하고, 다른 사람에게 설명할 수 있는 검토를 생성해야 합니다.

좁은 경계를 가진 예제를 선택하세요. 단일 내보내기 동작은 전체 데이터 플랫폼보다 검사하기 쉽습니다. 구성 요소에 대한 이전 선택은 아키텍처가 좋은지에 대한 광범위한 질문보다 확인하기 쉽습니다.

실습 옆에 짧은 메모를 남기세요: 질문, 예상 소스, 현재 구현, 그리고 판단이 필요한 부분. 이것이 답변을 평가하기 위한 참조 자료입니다.

올바른 실패 진단

• 검토자가 잘못된 대화를 복구하면 검색 기능을 개선하세요.
• 올바른 대화를 찾았지만 코드를 잘못 읽으면 조사 기능을 개선하세요.
• 결과는 타당하지만 구현이 요구 사항을 충족하지 못하면 인계 절차를 개선하세요.

이러한 구분이 중요한 이유는 각 실패마다 다른 수정이 필요하기 때문입니다. 더 많은 메모리를 추가한다고 해서 반드시 불명확한 브리핑이 해결되는 것은 아니며, 브리핑을 다시 작성한다고 해서 가져오지 않은 소스를 복구할 수 있는 것도 아닙니다.

가장 작은 완전한 사이클을 완료하고, 실패한 것을 기록하고, 그 증거를 사용하여 다음 개선 사항을 선택하세요.

3. 작동 설정: 조사와 구현 분리

제가 제안하는 첫 번째 설정은 읽기 전용 검토자와 프로젝트 편집 액세스 권한이 있는 구현자입니다. 각각에게 명확한 인도물을 제공하고, 변경이 시작되기 전에 읽을 수 있는 인계 절차를 만드세요.

에이전트 프로필은 러너, 모델, 노력, 지침 및 파일 액세스를 지원합니다. 대화는 프로젝트에 속하며, 후속 작업은 기본 CLI 세션을 재개합니다. 대화 모델

1. 에이전트 1: 검토자는 첫 번째 질문을 받습니다: 우리가 무엇을 결정했는지, 코드가 지금 무엇을 하는지, 그리고 해결할 가치가 있는 격차가 있는지?
2. 에이전트 2: 구현자는 검토된 답변과 제한된 요청을 받습니다: 이 동작 변경을 이 범위 내에서 수행하고, 이렇게 확인하세요.

역할을 구분하여 유지하세요

두 역할에 동일한 러너를 선택할 수 있습니다.

유용한 구분은 책임과 액세스에 있으며, 조사와 편집 사이에 명시적인 검토가 있어야 합니다.

어떤 에이전트도 유용한 작업을 완료하기 전에 전문가 카탈로그를 만드는 것은 피하는 것이 좋습니다. 실제로 구분할 수 있는 책임부터 시작하세요. 역할이 소유한 것 또는 완료된 출력물의 모양을 설명할 수 없다면, 다른 에이전트를 추가하기 전에 역할을 명확히 하세요.

3.1 검토자: 불확실성을 보이게 만드는 브리핑

검토자를 선택하고 @Claude, @Codex, @OpenCode 또는 @Cursor를 사용하여 관련 대화를 첨부하세요. 선택된 참조는 실행을 위한 고정 컨텍스트가 되며 작업이 시작될 때 선택한 에이전트로 전송됩니다. 참조

이 브리핑을 복사하여 빈칸을 채우세요:

1첨부된 대화와 현재 저장소를 사용하여 [기능 또는 하위 시스템]에 대한
2이전 결정을 검토하세요.
3
4원래 결정과 명시된 이유를 설명하세요. 관련 코드를 확인하고
5여전히 적용되는 사항, 변경된 사항, 사용 가능한 증거로 확인할 수 없는
6사항을 식별하세요.
7
8결론을 뒷받침하는 파일을 인용하세요. [원하는 동작]을 위해 필요한
9가장 작은 변경 사항과 검증 계획을 제안하세요.
10
11파일을 편집하지 마세요. 대화를 역사적 증거로 취급하고
12현재 프로젝트 지침과의 충돌을 표시하세요.

검토 내용 검사

저장소를 열고 답변을 읽으세요.

1. 인용문을 따라가 보세요.
2. 에이전트가 여전히 존재한다고 말하는 조건을 검사하세요.
3. 대화에서 주장한 것과 오늘날 코드가 보여주는 것 사이의 명확한 구분을 찾으세요.

답변이 모호하면 질문을 좁히세요. 동작을 제어하는 정확한 조건 또는 이전 대안을 부적합하게 만든 종속성을 식별하도록 요청하세요.

유용한 조사는 누락된 증거로 끝날 수 있습니다. 그것은 다음에 무엇을 제공해야 하는지 알려줍니다. 격차를 모호하게 만드는 답변은 다음 결정을 더 어렵게 만듭니다.

3.2 인계: 결과를 실행 가능한 브리핑으로 전환

검토에 동의하면 관찰 가능한 동작을 중심으로 구현 요청을 작성하세요. 이전 대화에서 설정된 제약 조건을 포함하되, 이 변경과의 관련성을 설명하세요.

제가 사용할 브리핑은 다음과 같습니다:

1아래 검토된 결과를 사용하여 [특정 동작]을 구현하세요.
2
3[기존 동작]을 그대로 유지하세요. 편집을 [허용된 범위]로 제한하세요.
4변경에 해당 범위를 벗어나는 작업이 필요한 경우, 확장하기 전에
5그 이유를 설명하세요.
6
7편집하기 전에 현재 저장소 지침을 확인하세요. [관련 테스트 또는
8수동 확인]을 사용하여 [예상 결과]를 확인하고, [중요한 실패 사례]를
9포함하세요.
10
11변경된 사항, 실제로 실행된 검사 및 해결되지 않은 모든 제한 사항에
12대한 간결한 설명을 반환하세요. 게시하거나 배포하지 마세요.
13
14검토된 결과:
15[확인한 결과를 붙여넣으세요]

인계를 구체적으로 만드세요

그 괄호 안에는 실제 답변이 들어가야 합니다. "더 좋게 만들어"는 에이전트가 목표를 발명하도록 만듭니다. "원래 오류를 유지하면서 재시도 작업으로 실패한 내보내기를 표시"는 둘 다 검사할 구체적인 대상을 제공합니다.

검토된 결과를 작업 가까이에 유지하세요. 중요한 제약 조건이 긴 대화록에 묻혀 있다면, 브리핑에 명시하고 뒷받침하는 대화를 첨부하세요.

소스는 제약 조건의 출처를 설명합니다. 현재 요청은 그것이 오늘날의 작업을 어떻게 규율하는지 설명합니다.

4. 프로젝트 실습: 반복되는 버그를 전체 사이클로 처리

워크플로우를 구체화하기 위한 가상의 실습입니다. 네트워크 중단 후 프로젝트에서 가끔 중복 내보내기가 생성되고, 이전 대화에 재시도 동작에 대한 조사가 포함되어 있다고 가정해 보세요.

1. 1단계: 먼저, 해당 대화를 검색하세요. 검토자에게 이전 조사에서 무엇을 확인했는지 식별하도록 요청한 다음, 현재 재시도 경로를 확인하세요.
2. 2단계: 이전 논의에서 불확실한 응답 후에 요청이 반복될 수 있다고 말한다고 가정해 보세요. 검토자는 현재 구현이 여전히 이를 허용하는지, 어떤 코드가 이를 제어하는지, 그리고 중복을 방지하기 위한 메커니즘이 이미 있는지 확인해야 합니다.
3. 3단계: 증거가 변경을 뒷받침한다면, 실패 사례를 중심으로 구현자에게 브리핑하세요. 반복된 요청이 수행해야 할 작업, 유지되어야 하는 기존 내보내기 동작, 중단된 응답을 확인하는 방법을 지정하세요.
4. 4단계: 그런 다음 변경 사항을 검사하고 관련 경로를 실행하세요. 성공적인 내보내기와 불확실성 이후의 재시도 모두를 확인하세요. 환경이 중단을 재현할 수 없는 경우, 그 제한 사항을 기록하고 추가 검증이 필요한지 결정하세요.
5. 5단계: 마지막으로, 유지할 교훈을 검토하세요: 중복을 유발한 조건, 이를 해결하는 메커니즘, 수정을 뒷받침하는 증거.

이 예제는 제안된 실습이며, agentic stack의 버그에 대한 주장이 아닙니다. 자신의 프로젝트에서 실제 실패 사례로 대체하고 동일한 순서를 유지하세요.

5. 공유 계층: 다른 도구로 검색 기능 가져오기

데스크탑은 Tools → Connections → Use @ in tools → Enable in all four tools를 통해 통합 기능을 설치할 수 있습니다. 명령줄 버전은 다음과 같습니다:

1agentic-stack context install

이후 도구를 다시 시작하세요. MCP 항목은 대화 검색, 선택된 채팅 읽기 및 공유 메모리 검색을 노출합니다. 통합

선택기 동작은 클라이언트에 따라 다릅니다. 리소스 완료를 사용할 수 없는 경우, 에이전트가 검색하여 일치하는 대화를 제시할 수 있습니다. 클라이언트 동작

도구 간 연속성 테스트

제 첫 번째 확인은 다른 도구에 방금 검토한 동일한 결정을 찾도록 요청하는 것입니다. 주제를 제공하고, 일치하는 소스를 제시하도록 요청한 다음, 분석을 요청하기 전에 선택을 확인하세요.

그런 다음 데스크탑에서 검사한 소스와 결과를 비교하세요. 도구 간 컨텍스트의 연속성을 테스트하는 것이므로, 질문을 안정적으로 유지하면서 질문하는 위치를 변경하세요.

또한 결정이 작업에 실질적으로 영향을 미칠 때마다 최종 작업 브리핑에 소스를 포함하는 것이 좋습니다. "전에 이걸 논의했어"는 에이전트에게 검색 문제를 제공합니다. "이 검토된 대화를 사용하고 이 조건을 확인해"는 특정 책임을 제공합니다.

6. 지속 계층: 교훈이 될 가치가 있는 것

검색은 오래된 자료를 다시 보이게 합니다. 그 자료가 어떤 권위를 가져야 하는지는 여전히 결정해야 합니다.

대화에는 포기된 계획, 잘못된 진단 또는 프로젝트가 변경되기 전에는 합리적이었던 답변이 포함될 수 있습니다. 이를 보존하면 나중에 추론을 검사할 수 있습니다. 교훈을 받아들이는 것은 별개의 결정입니다.

Tasks는 실행 기록을 보유합니다. Knowledge → Lessons는 교훈을 이유와 함께 준비, 수락, 거부 및 재검토하는 것을 지원하며, 가져온 기록은 수락된 교훈과 분리되어 유지됩니다. 검토 수명 주기

도전할 수 있는 교훈을 작성하세요

도전받을 수 있을 만큼 충분한 세부 정보와 함께 제안된 교훈을 작성하는 것이 좋습니다: 적용되는 조건, 권장하는 동작, 이유 및 증거.

가상의 내보내기 버그의 경우, "항상 안전하게 재시도"는 너무 모호하여 도움이 되지 않습니다. 유용한 메모는 재시도를 불확실하게 만드는 요소와 이 프로젝트의 구현이 반복 작업을 어떻게 인식해야 하는지 식별합니다.

그런 다음 교훈을 무용지물로 만들 것이 무엇인지 질문하세요. 다른 백엔드, 변경된 계약 또는 교체된 하위 시스템이 원래 제약 조건을 제거할 수 있습니다. 미래의 검토가 시작할 지점을 가질 수 있도록 해당 경계를 포함하세요.

이것이 유용한 수정이 그 이유보다 오래 지속되는 규칙이 되는 것을 방지하는 방법입니다.

6.1 메모리 구조: 각 지식을 제자리에 배치

데스크탑 아래에는 이식 가능한 .agent/ 아키텍처가 작업 상태, 이전 에피소드, 지속적인 패턴 및 개인적 선호도를 분리합니다. Skills는 재사용 가능한 절차를 제공하는 반면, Protocols는 권한 및 위임을 설명합니다. 아키텍처

• 현재 조사는 진행 중인 작업에 속합니다.
• 완료된 기록은 무슨 일이 있었는지에 대한 증거가 됩니다.
• 검증된 패턴은 지속적인 교훈이 될 수 있습니다.
• 결과를 어떻게 제시할지에 대한 선호도는 선호도에 속합니다.

의미를 명확히 유지하면 나중에 검토하기가 더 쉬워집니다. 임시 해결 방법은 언제 제거할 수 있는지 설명해야 합니다. 개인적인 글쓰기 선호도가 실수로 아키텍처 규칙이 되어서는 안 됩니다.

검증된 절차를 Skill로 전환

동일한 원칙이 Skills에도 적용됩니다. 절차가 반복할 가치가 있을 만큼 유용하고 따를 수 있을 만큼 구체적일 때 Skill을 만드는 것이 좋습니다. 필요한 입력, 중요한 단계, 예상 출력 및 다른 결정이 필요한 조건을 포함하세요.

내보내기 예제의 경우, 조사는 유용한 회귀 확인 절차를 생성할 수 있습니다. 프로젝트에서 단계가 작동하는지 확인한 후에만 저장하세요. 복사된 대화록은 다음 에이전트에게 이야기를 제공합니다. 검토된 절차는 평가할 수 있는 방법을 제공합니다.

7. 운영 규칙: 간결하고, 경계를 정하고, 검사

첫 번째 프로젝트부터 워크플로우에 적용할 규칙은 다음과 같습니다.

1. 규칙 1: 모든 브리핑은 인도물을 명명합니다. 검토는 증거와 함께 결과를 반환합니다. 구현은 검사와 함께 동작 변경을 반환합니다. 교훈 제안은 수락하거나 거부할 수 있는 주장을 반환합니다.
2. 규칙 2: 액세스는 작업을 따릅니다. 조사는 읽기 전용 액세스로 시작합니다. 구현은 합의된 변경에 필요한 범위를 얻습니다. 게시, 배포 및 기타 중요한 작업은 요청에 명시적으로 포함하세요.
3. 규칙 3: 실제 검증을 요청하세요. 보고서는 무엇이 실행되었고 무슨 일이 일어났는지 말해야 합니다. 확인을 사용할 수 없는 경우, 누락된 결과를 조용히 성공으로 처리하는 대신 표시하세요.
4. 규칙 4: 역사적 컨텍스트를 현재 증거 및 적용 가능한 프로젝트 지침에 종속시키세요. 검색된 대화는 이전 결정을 설명할 수 있지만 여전히 구식일 수 있습니다.
5. 규칙 5: 결론을 유지하기 전에 결과를 검토하세요. 에이전트의 자신의 작업에 대한 설명은 diff 및 관찰된 동작과 함께 검사해야 할 대상입니다.

이것들은 제가 설명하는 설정에 대한 운영 방식입니다. 프로젝트에 맞게 조정하되, 다른 사람이 작업이 브리핑을 충족했는지 알 수 있을 만큼 책임을 명확히 유지하세요.

7.1 검토 큐: 작업을 수락하거나 반송하기 쉽게 만들기

모든 구현이 동일한 형식으로 완료되도록 요청할 것입니다:

• 변경된 사항,
• 확인된 사항,
• 불확실한 사항,
• 재사용 가능한 교훈을 제안하는지 여부.

이렇게 하면 매번 전체 대화를 재구성하지 않고도 완료된 작업을 일관된 방식으로 읽을 수 있습니다. 지원 세부 정보는 검사해야 하는 부분에 대해 계속 사용할 수 있습니다.

무언가를 반송할 때는 놓친 요구 사항에 대한 수정 사항을 첨부하세요. "이건 틀렸어"는 또 다른 추측 라운드를 시작합니다. "재시도가 이 조건에서 두 번째 내보내기를 생성합니다. 원래 요청 ID를 보존하고 이 확인을 다시 실행하세요"는 격차를 식별합니다.

살아남을 가치가 있는 것을 결정하세요

수정이 통과된 후, 그것이 반복되는 제약 조건인지 해당 작업의 세부 사항인지 결정하세요. 증거가 뒷받침되는 경우 전자를 저장하세요. 후자는 작업 기록에 남을 수 있습니다.

모든 검토 의견을 영구 메모리로 전환하는 것은 피하는 것이 좋습니다. 일부 수정은 한 번만 유용합니다. 다른 수정은 나중 작업을 형성해야 하는 규칙을 드러냅니다. 이러한 구분을 하는 것은 시스템 유지 관리의 일부입니다.

검토가 끝날 때 유용한 질문은 다음과 같습니다: 미래의 에이전트가 유사한 작업을 시도하기 전에 무엇을 알아야 하며, 해당 지식을 어디에서 확인할 수 있습니까?

7.2 비용 규율: 모든 실행에 중지 조건 부여

계속 확장될 수 있는 모든 작업에 중지 조건을 포함시키는 것이 좋습니다. 검토의 경우, 관련 동작 및 해결되지 않은 질문에 대한 서면 설명이 될 수 있습니다. 구현의 경우, 명명된 검사를 통과하는 합의된 변경 사항이 될 수 있습니다.

에이전트가 더 큰 문제를 발견하면, 현재 변경에 해당 작업을 흡수하기 전에 결과와 원래 작업과의 관계를 설명하도록 요청하세요.

이것이 현재 작업에 속하는지 결정하세요.

결과 비교 및 제한 사항 적용

계정에서 실제로 사용 가능한 옵션을 사용하여 러너와 모델을 선택한 다음, 자신의 제한된 예제에서 평가하세요. 하나의 구성을 기본값으로 만들기 전에 결과의 품질, 필요한 수정 사항 및 제공된 검증을 비교하는 것이 좋습니다.

작업과 소스 자료를 안정적으로 유지하여 실험을 공정하게 유지하세요. 모든 시도가 질문, 컨텍스트 및 수용 기준을 변경하면 비교를 해석하기 어려울 것입니다.

그리고 도구나 제공자가 실제로 시행하는 곳에 지출 통제를 두세요. 에이전트에게 경제적으로 행동하도록 요청하는 문장은 선호도일 뿐입니다. 제한에 의존하기 전에 사용 가능한 통제 장치를 검사하세요.

8. 맞춤형 빌드: 실제 마찰 지점을 중심으로 워크스페이스 변경

기본 사이클을 완료하면 데스크탑 자체에서 원하는 것이 무엇인지 더 잘 알게 될 것입니다. 반복적인 탐색 단계가 거슬리거나, 작업 보기가 필드를 검사하기 어렵게 만들 수도 있습니다.

기능을 제안하기 전에 마찰을 기록하세요. 수행하려는 작업, 시간을 낭비하는 위치, 개선된 동작이 무엇을 가능하게 할지 설명하세요.

그런 다음 소스 저장소를 열고 에이전트에게 제한된 변경 요청을 제공하세요. 앱에서 결과를 검사할 방법을 포함하세요.

변경 사항 빌드 및 검사

저장소는 다음 개발 및 패키징 명령을 문서화합니다:

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

개발 명령

SwiftUI 변경 사항은 검사하기 위해 재빌드 및 재시작이 필요합니다. 데스크탑 워크플로우

변경을 동기로 한 상호 작용과 중단될 수 있는 인접 사례를 테스트하는 것이 좋습니다. 작업 필터링을 개선하는 경우, 필터링된 결과, 빈 결과 집합 및 전체 목록으로 돌아가는 경로를 검사하세요.

내보내기 실습에 적용한 것과 동일한 기준을 사용하세요: 구체적인 이전, 제한된 변경 및 관찰된 이후.

8.1 원격 옵션: 작업이 상주할 위치 결정

로컬 워크플로우가 작동한 후에는 영구 서버에서 실행을 원할 수도 있습니다. 자체 호스팅 경로는 네이티브 앱을 프로젝트, 메모리, 작업 기록 및 CLI 로그인을 소유하는 단일 소유자 서비스에 연결합니다. 호스트를 전환해도 Mac의 데이터나 자격 증명이 자동으로 전송되지는 않습니다. 호스팅 가이드

네, 그 결정은 프로젝트와 실행 환경을 이미 관리 중인 머신에 유지하는 것과 같은 구체적인 이유가 있을 때만 실행할 것입니다. 배포 작업을 시작하기 전에 그 이유를 기록해 두세요.

지원되는 구성, 인증 및 확인 단계에 대한 호스팅 가이드를 따르세요. 서버를 자체 상태를 검사할 수 있는 또 다른 작업 환경으로 취급하세요.

선택한 환경 확인

그런 다음 해당 환경에서 익숙한 작업을 반복하세요. 선택한 프로젝트를 확인하고, 에이전트가 의도한 소스에 접근할 수 있는지 확인하며, 결과가 선택한 서버 환경에 속하는지 검증하세요.

익숙한 작업을 사용하면 전환을 더 쉽게 평가할 수 있습니다. 호스트, 프로젝트 및 워크플로를 동시에 변경하면 예상치 못한 결과의 원인을 파악하기 어려워집니다.

로컬 환경만으로도 핵심 패턴을 배우기에 충분합니다. 작업이 필요할 때 인프라를 확장하세요.

9. 확장: 이전 사이클에서 드러난 격차를 메우기 위해 적용 범위 추가

실제 작업 중에 발견한 누락된 컨텍스트에 따라 이 설정을 확장할 것입니다.

• 리뷰에 이전 아키텍처 논의가 필요했다면, 해당 논의를 가져오세요.
• 구현 시 동일한 절차가 반복적으로 필요했다면, 스킬을 개발하고 검증하세요.
• 결정이 계속해서 재논의된다면, 이를 뒷받침하는 증거와 함께 범위가 정해진 레슨을 작성하세요.

이미 답을 알고 있는 소수의 질문을 모아두세요. 임포트나 워크플로를 변경한 후에 이 질문들을 사용하세요: 이 결정을 찾고, 이 제약 조건을 설명하고, 이를 구현하는 코드를 식별하며, 더 이상 유효하지 않은 부분을 표시하세요.

작업이 정당화될 때 확장하세요

에이전트 역할의 책임이 작업을 통해 명확해질 때만 추가할 것입니다. 반복적인 문서 리뷰는 전용 브리프를 정당화할 수 있습니다. 일회성 요청은 기존 역할에 완벽하게 맞을 수 있습니다.

자리를 잡은 부분만 확장하세요. 문제가 발생했을 때 이해할 수 있을 만큼 나머지는 단순하게 유지하세요.

9.1 유지 관리 습관: 시스템이 변경될 때 지식 재검토

하위 시스템이 가정을 변경할 만큼 충분히 변경될 때마다 관련 레슨을 검토할 것입니다. 변경 자체를 트리거로 사용하세요: 새로운 종속성, 교체된 스토리지 계층, 다른 배포 환경 또는 수정된 제품 요구 사항.

이전 동작에 의존하는 기존 레슨을 확인한 다음, 변경 사항과 함께 해당 소스를 검사하세요. 여전히 유효한 것은 유지하고, 범위를 좁혀야 하는 것은 수정하며, 더 이상 적용되지 않는 것은 사용 가능한 리뷰 워크플로를 통해 폐기하세요.

중요한 것은 설명을 보존하는 것입니다. 미래의 빌더는 이전 규칙이 왜 존재했고, 무엇이 변경되어 이를 대체하게 되었는지 이해할 수 있어야 합니다.

절차 새로 고침 및 충돌 해결

스킬의 경우, 입력이나 명령에 영향을 미치는 변경 후에 절차를 다시 실행하세요. 단계가 더 이상 작동하지 않으면 관찰된 실패를 기반으로 절차를 업데이트하고 관련 확인을 반복하세요.

이렇게 하면 유지 관리를 프로젝트의 실제 이벤트와 연결할 수 있습니다. 가장 오래되었을 가능성이 높은 지식을 현재 증거와 함께 검토하게 됩니다.

작업에서 상충되는 노트가 발견되면, 해당 충돌을 해결하는 것을 리뷰의 일부로 만드세요. 현재 버전에 적용되는 설명을 식별하고, 다음 에이전트가 전체 조사를 반복하지 않고도 추론을 따라갈 수 있을 만큼 명확하게 결과를 남기세요.

유용한 인계 남기기

다음 세션 전에 검증된 결과, 미해결 질문, 그리고 다른 에이전트가 먼저 읽어야 할 소스를 설명하는 짧은 인계를 남기세요. 실제로 검사한 프로젝트 상태에 특화된 내용으로 유지하세요.

이렇게 하면 특히 다른 도구를 통해 돌아오거나 시간이 지난 후에 돌아왔을 때, 원래 추론을 여전히 확인할 수 있는 시작점을 다음 작업에 제공할 수 있습니다.

10. 빌드 시트

1. 익숙한 저장소와 인식할 수 있는 결정을 선택하세요.
2. 데스크톱을 빌드하고, 설정을 완료한 후, 해당 결정이 포함된 완료된 대화를 임포트하세요.
3. 이를 검색하고, 소스를 검사한 후, 현재 코드에 대한 읽기 전용 리뷰에 첨부하세요.
4. 직접 결과를 확인한 다음, 눈에 보이는 승인 조건과 함께 범위가 정해진 구현을 브리핑하세요.
5. diff를 검사하고 관련 검증(작업의 동기가 된 실패 사례 포함)을 실행하세요.
6. 결과가 뒷받침될 때만 범위와 이유를 기록하여 레슨을 준비하세요.
7. 반복할 가치가 있다고 검증된 경우에만 절차를 스킬로 전환하세요.
8. 다른 도구에서 동일한 검색을 시도한 다음, 실제 작업이 필요할 때 컨텍스트나 인프라를 확장하세요.

이번 주에 하나의 결정으로 시작하여 전체 기록을 임포트하기 전에 전체 사이클을 완료하세요.

다음 에이전트는 당신의 판단을 이어받아야 합니다.