코드에 대한 추론 엔진: 변경 사항의 '이유'를 저장하는 Lore
요약
Lore는 AI 에이전트가 코드 변경의 '왜'를 이해할 수 있도록 돕는 고(高) 컨텍스트 리포지토리입니다. Git이 누가, 언제를 알려준다면, Lore는 의도와 추론 과정을 저장하여 개발 이력을 풍부하게 만듭니다. 이는 추가 전용 병합 전략을 통해 여러 브랜치의 모든 컨텍스트를 손실 없이 보존합니다.
핵심 포인트
- 코드 변경의 '왜'를 기록하는 고(高) 컨텍스트 리포지토리
- 의도, 추론 과정, 거부된 대안 등 상세한 사고 과정을 저장
- 추가 전용 병합 전략으로 모든 브랜치의 결정 이력을 보존
- 개발자가 AI 에이전트와 협업할 때 필수적인 도구
Lore는 AI 에이전트가 단순히 코드를 읽는 것이 아니라, 해당 코드에 작업했던 이전 개발자들과 에이전트들의 생각까지 읽을 수 있게 하는 고(高) 컨텍스트 리포지토리를 만듭니다.
Git은 누가 코드를 변경했고 언제를 알려주지만, Lore는 왜를 알려줍니다. Lore는 다음 사항들을 저장합니다:
- 의도 (Intent): 무엇을 달성하려고 했는지에 대한 간략한 설명
- 추론 추적 (Reasoning Trace): 수천 단어에 달할 수 있는 전체 사고 과정(chain-of-thought)
- 거부된 대안 (Rejected Alternatives): 시도했지만 작동하지 않은 것들 (그리고 그 이유)
- 태그 (Tags): 쉬운 검색을 위한 분류
모든 항목은 파일 콘텐츠 해시와 암호학적으로 연결되며, 선택적으로 Git 커밋과도 연결됩니다.
| 기능 | 댓글 | 커밋 메시지 | Lore |
|---|---|---|---|
| 용량 (Volume) | 짧아야 함 | ~50자 | 무제한 (5000+ 단어) |
| 검색 가능성 (Searchable) | 코드만 | 메시지만 | 전체 추론 + 대안 |
| 안정성 (Stability) | 자주 삭제됨 | 수정 가능 | 불변(Immutable), 해시 연결 |
| 컨텍스트 (Context) | 코드가 무엇을 하는지 | 무엇이 변경되었는지 | 왜 그렇게 작성되었는지 |
여러 개발자가 다른 브랜치에서 작업하고 모두 같은 파일에 대한 추론을 기록할 때, Lore는 **추가 전용 병합 전략(append-only merge strategy)**을 사용하여 모든 컨텍스트를 보존합니다:
Branch A: "JWT 유효성 검사 리팩토링"
Branch B: "토큰 캐싱 최적화"
↓
...
Lore는 하나의 버전(컨텍스트 손실)을 선택하는 대신, 자동으로 다음 작업을 수행합니다:
-
✅ 두 브랜치의 추론 보존 - ✅
-
수동 충돌 해결이 필요 없음 - ✅
-
lore explain <파일> --all로 완전한 결정 이력(decision history) 표시 -
✅ 동일한 항목이 두 브랜치에 나타날 경우 중복 제거
예시:
# 충돌하는 추론을 가진 두 브랜치를 병합한 후
lore explain src/auth.rs --all
# 둘 다 표시됨:
...
macOS, Linux, Windows용 사전 빌드 바이너리가 제공됩니다. 아래에서 사용하려는 플랫폼을 선택하세요:
# Apple Silicon (M1/M2/M3)
sudo curl -L https://github.com/avraammavridis/lore/releases/latest/download/lore-macos-aarch64 -o /usr/local/bin/lore && sudo chmod +x /usr/local/bin/lore
# Intel
...
x86_64
sudo curl -L https://github.com/avraammavridis/lore/releases/latest/download/lore-linux-x86_64 -o /usr/local/bin/lore && sudo chmod +x /usr/local/bin/lore
ARM64
...
최신 릴리스에서 lore-windows-x86_64.exe를 다운로드하여 PATH에 추가하거나, 다음을 사용하세요:
# PowerShell (관리자 권한으로 실행)
$url = "https://github.com/avraammavridis/lore/releases/latest/download/lore-windows-x86_64.exe"
$output = "C:\Program Files\lore.exe"
...
소스에서 빌드하거나, 아직 해당 플랫폼용 사전 구축된 바이너리가 없는 경우:
# Rust 필요: https://rustup.rs
git clone https://github.com/avraammavridis/lore.git
cd lore
...
Lore를 사용하여 추론을 기록하려면 명령줄에서 직접 사용할 수 있습니다:
# 프로젝트에 Lore 초기화
lore init --agent "my-agent-id"
# 코드 변경 후, 추론 내용을 기록합니다
...
Lore는 AI 코딩 어시스턴트와 원활하게 작동하도록 설계되었습니다. 에이전트의 시스템 명령어에 다음을 추가하세요:
You have access to a tool called `lore`.
Before you edit a file, run `lore explain <file>` to understand the hidden context.
After you finish a task, run `lore record` to save your chain-of-thought so future agents understand your decisions.
여러 AI 에이전트가 동일한 코드베이스에서 작업할 때:
맥락 손실 없음: 각 에이전트의 추론은 영원히 보존됩니다반복 실수 방지: 거부된 대안들은 막다른 길을 다시 탐색하는 것을 방지합니다의도 이해: 미래의 에이전트는 코드가 무엇을 하는지만 아는 것이 아니라, 왜 존재하는지 알게 됩니다검색 가능한 기록: 전체 프로젝트 히스토리에서 추론 내용을 쿼리할 수 있습니다
Claude Code는 모든 코드 변경에 대해 Lore를 자동으로 사용하도록 구성될 수 있습니다.
프로젝트에 Lore 초기화:lore init --agent "claude-code"
프로젝트 루트에 다음 내용으로 CLAUDE.md 생성:
파일 # Lore 통합: 코드 변경의 추론 과정을 기록하는 방법
이 프로젝트는 Lore를 사용하여 코드 변경 뒤에 숨겨진 추론(reasoning)을 추적합니다. Lore는 "고맥락(high-context)" 저장소를 생성하여 코드가 무엇을 하는지뿐만 아니라, 왜 그렇게 작성되었는지 이해할 수 있게 합니다.
파일 편집 전
파일을 수정하기 전에 기존의 추론 맥락이 존재하는지 확인하세요:
lore explain <file-path>
이 명령은 다음 내용을 보여줍니다:
- 코드가 왜 이렇게 작성되었는지
- 어떤 대안들이 고려되고 거부되었는지
- 이전 개발자/에이전트가 남긴 경고나 메모
만약 추론 과정이 존재하지 않는다면, 이는 새롭거나 문서화되지 않은 코드임을 나타내는 메시지가 표시됩니다.
변경 후
어떤 코드 변경을 완료했든, 반드시 lore record를 사용하여 당신의 추론 과정을 기록해야 합니다:
lore record -f <changed-file> \
-m "수행한 내용에 대한 간략한 설명" \
--trace "다음 내용을 설명하는 전체적인 추론 과정 및 사고 흐름(chain-of-thought):
- 왜 이러한 특정 변경을 했는지
- 어떤 대안들을 고려했는지
- 발생 가능한 트레이드오프나 우려 사항은 무엇인지
- 미래 개발자를 위한 경고 사항" \
-r "거부된 대안 1" \
-r "거부된 대안 2" \
-T 관련태그 ```
### 매개변수 (Parameters)
| 플래그 | 설명 | 필수 여부 |
|------|-------------|----------|
| `-f <file>` | 추론을 기록할 파일(생략 시 git에서 자동 감지) | 아니요 |
| `-m "message"` | 간략한 의도/목적 (1~2문장) | 예 |
| `--trace "..."` | 전체적인 추론 과정 (상세할 수 있음) | 예 |
| `-r "alternative"` | 거부된 대안 (여러 번 사용 가능) | 아니요 |
| `-T tag` | 분류를 위한 태그 (여러 번 사용 가능) | 아니요 |
| `--lines "10-45"` | 추론이 적용되는 하위 범위의 특정 라인 | 아니요 |
## 몇 가지 예시 (Few-Shot Examples)
### 예시 1: 버그 수정
레이스 컨디션(race condition) 버그를 수정한 후:
```bash
lore record -f src/worker.py \
-m "작업 처리의 레이스 컨디션을 수정함" \
--trace "워커가 작업 상태 확인과 상태 업데이트가 원자적(atomic)이지 않았기 때문에 간헐적으로 동일한 작업을 두 번 처리했습니다. SETNX 명령을 사용하고 30초 TTL을 가진 Redis 기반 분산 잠금장치(distributed lock)를 추가했습니다. 가장 긴 작업이 약 20초이므로, 50%의 여유 시간을 주기 위해 30초를 선택했습니다. 잠금 키에는 작업 ID가 포함되어 있어 다른 작업을 병렬로 처리할 수 있습니다. 경고: Redis를 사용할 수 없는 경우, 중복을 감수하는 대신 작업이 실패하게 됩니다. 이는 의도된 사항입니다. (중복 처리는 청구 문제(billing issues)를 일으킵니다.)" \
-r "데이터베이스 행 수준 잠금(Database row-level locking) (너무 느림, 100ms+ 지연 시간)" \
-r "인메모리 잠금(In-memory lock) (여러 워커에 걸쳐 작동하지 않음)" \
-r "버전 필드를 사용한 낙관적 잠금(Optimistic locking with version field) (스키마 변경 필요)" \
-T bugfix -T concurrency -T redis ```
### 예시 2: 신규 기능 추가
새로운 API 엔드포인트를 추가한 후:
```bash
lore record -f src/api/users.py -f src/models/user.py \
-m "GDPR 준수를 위한 사용자 내보내기(export) 엔드포인트 추가" \
--trace "모든 사용자 데이터를 JSON 형식으로 반환하는 GET /api/users/{id}/export 엔드포인트를 추가했습니다. 이는 GDPR 제20조 (데이터 이동권, right to data portability)에 필요합니다. 이 엔드포인트는: 1. 인증이 필요하며 사용자는 자신의 데이터만 내보낼 수 있습니다. 2. 남용을 방지하기 위해 속도 제한(rate limiting, 시간당 1회 요청)을 포함합니다. 3. 메모리 문제를 피하기 위해 대용량 응답을 스트림으로 처리합니다. 저는 컨트롤러를 간결하게 유지하고 나중에 더 많은 내보내기 형식을 추가하기 쉽게 하기 위해 내보내기 로직을 별도의 서비스 클래스(UserExportService)에 넣었습니다. 참고: 법률 검토 결과 'internal_notes' 필드는 GDPR 상 사용자 데이터로 간주되지 않으므로, 내보내기에서 이 필드를 의도적으로 제외했습니다." \
-r "CSV 형식 (JSON이 더 이식성이 높고 데이터 유형을 보존함)" \
-r "이메일 전송을 포함하는 백그라운드 작업 (복잡성 증가, 사용자는 즉시 다운로드를 원함)" \
-T feature -T gdpr -T api ```
### 예시 3: 리팩토링
복잡한 모듈을 리팩토링한 후:
```bash
lore record -f src/billing/calculator.py \
-m "비용 계산기(billing calculator)를 전략 패턴(strategy pattern)을 사용하도록 리팩토링함" \
--trace "비용 계산기는 다양한 가격 등급에 대해 깊게 중첩된 if/else 체인으로 800줄 이상까지 커졌습니다. 저는 전략 패턴을 사용하여 리팩토링했습니다: - PricingStrategy 추상 기본 클래스를 생성했습니다 - FreeTier, ProTier, EnterpriseTier 전략을 구현했습니다 - 계산기가 적절한 전략에 위임하도록 했습니다. 이로 인해 메인 클래스의 크기는 800줄에서 150줄로 줄어들고 새로운 등급 추가가 매우 쉬워졌습니다 (새로운 전략 클래스만 추가하면 됩니다). 중요: 이전 calculate_legacy() 메서드는 2024-01-01 이전의 청구 작업을 위해 유지됩니다. 모든 과거 송장이 마이그레이션될 때까지 제거하지 마십시오. 마이그레이션 일정은 티켓 BILL-1234를 참조하십시오." \
-r "단순 함수 추출 (핵심 복잡성을 해결하지 못함)" \
-r "설정 기반 가격 책정 (기업 맞춤 거래에 충분히 유연하지 않음)" \
-T refactoring -T billing -T design-pattern ```
## 과거 추론 검색하기
```bash
# 용어 언급 검색: "JWT"라는 용어가 언급된 모든 내용을 검색합니다.
lore search "JWT"
# 특정 파일 내에서 검색: auth 파일 내의 "validation"을 검색합니다.
lore search "validation" --file auth
# 에이전트별 검색: claude가 수행한 "refactor"를 검색합니다.
lore search "refactor" --agent claude ```
## 중요 지침 (Important Guidelines)
1. **낯선 코드를 편집하기 전에는 항상 `lore explain`을 실행하세요**
- 이는 의도적인 결정을 되돌리거나 거부된 접근 방식을 재탐색하는 것을 방지합니다.
2. **작업 완료 후에는 항상 `lore record`를 실행하세요**
**커밋(Commit)하여** 모든 Claude Code 세션이 이를 사용하도록 저장소에 추가하세요. `CLAUDE.md`
파일
Cursor를 구성하여 지속적인 추론 컨텍스트로 Lore를 사용하게 하세요.
-
**프로젝트에서 Lore 초기화:** `lore init --agent
AI 자동 생성 콘텐츠
본 콘텐츠는 GitHub Claude Ecosystem의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기