-
Notifications
You must be signed in to change notification settings - Fork 1
operating model closed loop reasoning_ko
언어: 🇺🇸 English | 🇰🇷 한국어
Closed-loop reasoning은 Ghost-ALICE OS가 복잡한 작업을 다루는 기본 방식이다. 한 번 추론하고 끝내는 모델이 아니라, 현재 상태를 기준과 반복 대조하고 mismatch가 나오면 되감는 작업 방식이다.
핵심 명제는 간단하다.
- 복잡한 작업은 일회성 추론이 아니라 폐루프 추론이다.
- 검증은 후처리가 아니라 작업 진행 방식 자체다.
- 검증 강도는 작업의 verification burden에 비례한다.
폐루프 추론은 다음 흐름을 반복한다.
- 임시 상태를 만든다.
- 비교 기준을 꺼낸다.
- 현재 상태와 기준을 대조한다.
- mismatch를 식별한다.
- 상태를 수정하거나 사람에게 넘긴다.
- stop condition까지 반복한다.
여기서 중요한 점은 설명을 덧붙이며 계속 앞으로 가는 것이 아니라, 실제 상태를 바꾸거나 작업을 되감는다는 점이다. mismatch를 말로 합리화하면 루프가 닫히지 않는다.
state는 지금 검토 중인 임시 산출물이다.
예시는 다음과 같다.
- 현재 초안
- 현재 claim
- 현재 코드
- 현재 작업 계획
- 현재 source-target 매핑
- 현재 설치 또는 업데이트 상태
state는 완성물이 아니다. 기준과 대조되기 전까지는 가설이다.
reference는 state를 평가하는 기준이다.
주요 reference는 다음과 같다.
- schema
- SSOT
- evidence
- source locator
- user constraint
- target format
- platform contract
reference가 없으면 검증은 느낌에 가까워진다. Ghost-ALICE OS는 claim을 reference와 연결하려고 한다.
mismatch는 state와 reference 사이의 불일치다.
대표 유형은 다음과 같다.
- 논리 불일치
- 근거 부족
- schema 위반
- overclaim
- source-target 매핑 오류
- 구현과 사양의 불일치
- 형식은 맞지만 의미가 틀린 상태
mismatch는 실패 신호이지만, 동시에 루프가 작동하고 있다는 신호다. 중요한 것은 mismatch를 발견했을 때 작업 초점을 올리거나 내리며 실제로 수정하는 것이다.
Ghost-ALICE OS는 모든 작업에 같은 강도의 루프를 강제하지 않는다.
| Level | 성격 | 루프 강도 |
|---|---|---|
| task-complexity-level-1 | 자명하거나 회복 비용이 낮은 작업 | 가벼운 확인 1회 |
| task-complexity-level-2 | source 선택, 양식 매핑, 외부 근거가 필요한 작업 | checkpoint 기반 재대조 |
| task-complexity-level-3 | claim, 수치, 정책, 논문, 구현, 문서화가 얽힌 작업 | 폐루프 자체가 작업 본체 |
툴 호출 수가 많다고 항상 task-complexity-level-3인 것은 아니다. 반대로 한 줄 복사처럼 보여도 source 선택과 양식 매핑이 있으면 task-complexity-level-2 이상일 수 있다.
calls 그래프는 정적이고 희소해야 한다. 반복 검증 루프, 재조회, mismatch 기반 수정은 정적 그래프에 모두 올리지 않는다.
그 대신 Ghost-ALICE OS는 다음 구조를 쓴다.
-
task-router가 작업 의미와 적용 스킬 후보를 잡는다. -
boundary-contract가 allowed/prohibited surface를 잠근다. - 각 작업은 reference와 대조된다.
- 완료 주장은
claim-evidence-map으로 닫힌다.
이 분리 덕분에 스킬 그래프는 읽을 수 있게 유지되고, 런타임은 필요한 만큼 강한 검증 루프를 돌 수 있다.
사용자 입장에서 closed-loop reasoning은 이렇게 느껴진다.
- 에이전트가 바로 고치지 않고 먼저 범위를 묻거나 고정한다.
- 중간에 파일이나 evidence를 다시 확인한다.
- 완료 전에 왜 완료인지 근거를 요구한다.
- 작은 변경이라도 전체 문서나 계약과 충돌하면 되돌아본다.
이 동작은 지연이 아니라 품질 하한을 지키는 운영 방식이다.
AidALL/ghost-alice | This wiki stores design documents only. Runtime files live in the main repository.
- Team onboarding
- Install troubleshooting
- Windows installation tips
- Addon authoring
- Ghost-ALICE OS full design
- Design Philosophy: Floor, Not Ceiling
- Operating Model: Closed-Loop Reasoning
- Operating Model: Fallback and Escalation
- 팀 온보딩
- 설치 문제 해결
- Windows 설치 팁
- Addon 작성
- Ghost-ALICE OS 전체 설계
- 설계 철학: Floor, Not Ceiling
- 운영 모델: Closed-Loop Reasoning
- 운영 모델: Fallback and Escalation