Jungseob's Note
포스트

Keel의 결정 하네스, 모델이 고르는 일과 실행 권한을 나누기

Keel 0.2.0의 고정 소스에서 신규 작업 라우팅과 도구 묶음 선택, 권한·폴백·기록의 경계를 확인하고 자기 개선 주장에 필요한 평가 조건을 정리한다.

Keel의 결정 하네스, 모델이 고르는 일과 실행 권한을 나누기

TL;DR

  • Keel 0.2.0은 호스트가 준비한 후보 가운데 Laya나 Jev가 하나를 고르는 macOS 코딩 앱이다. 모델은 후보 ID 또는 보류를 반환하고 앱 코드가 유효성과 실행 가능 여부를 다시 확인한다. 선택 결과나 높은 확신도는 도구 실행 권한을 대신하지 않는다.
  • 자동 라우팅은 사용자가 제공자·모델을 고정하지 않은 새 작업에 적용한다. 진행 중이거나 재개하는 세션과 명시적으로 선택한 경로는 유지한다. 로컬 Laya가 기본이고 호스팅 Jev는 별도 선택이며 Normal 모드는 결정 모델 호출을 건너뛴다.
  • 내장 DeepSeek 루프에서는 inspect·implement·verify·answer에 따라 도구 묶음이 달라진다. answer에는 도구를 주지 않고 verify의 셸 실행에는 기존 권한 검사를 적용한다. 외부 ACP 에이전트가 소유한 내부 루프까지 Keel이 통제하는 것은 아니다.
  • 잘못된 선택과 오래된 상태는 거부하거나 기존 하네스로 되돌린다. 이 폴백을 결정 모델의 성공으로 집계하면 효과를 잘못 평가하게 된다. 결정 기록에는 후보와 선택, 검증과 폴백, 관찰된 결과가 함께 필요하다.
  • 공개 빌드는 결정 기록을 남기지만 스스로 모델을 학습하거나 정책을 바꾸지 않는다. 코딩 품질 향상과 총비용 절감도 아직 입증되지 않았다. 자기 개선은 실패 사례 재생과 별도 평가 작업, 사람의 승인과 롤백을 갖춘 후속 개발 과정으로 제안된다.

코딩 앱에서 결정 모델의 자리를 좁힌다

Avid가 공개한 Keel 0.2.0은 Rust와 GPUI로 만든 Apple Silicon용 코딩 작업 공간이며 macOS 15 이상을 대상으로 한다. 기존 앱의 작업·저장소·제공자 세션·도구 실행 위에 결정 계층을 붙였다. 이 계층의 역할은 새 작업을 맡을 제공자와 모델을 고르거나 내장 코딩 루프의 다음 단계에서 사용할 도구 범위를 고르는 일이다. 코드 패치의 내용과 개별 명령까지 결정 모델이 모두 작성하는 구조는 아니다.

호스트는 모델 바깥의 애플리케이션 코드다. 호스트가 이름 붙은 후보를 만들고 결정 모델이 고정 형식으로 후보 ID나 보류를 반환하면 호스트가 다시 검사한다. 반환된 ID는 미리 저장해 둔 실행 내용과 연결되므로 모델이 없는 제공자나 임의의 명령을 새로 만들어 적용할 수 없다. 원문 끝의 링크는 일반 main이 아닌 정확한 0.2.0 소스 스냅샷을 가리킨다. 아래 구현 설명도 그 스냅샷의 아키텍처 문서와 라우팅·에이전트 루프 코드를 기준으로 한다.

새 작업의 경로와 사용자가 고른 경로

자동 경로 선택은 새 작업을 시작하는 제한된 지점에 들어간다. 제공자가 설치·활성화돼 있고 모델을 찾을 수 있으며 요청한 추론 수준을 지원해야 후보가 된다. 이미 고정한 제공자·모델과 진행 중이거나 재개하는 세션은 자동으로 갈아타지 않는다. 코드의 requested 검사도 원래 제공자에 속한 Fast·Plan 등의 옵션을 다른 제공자로 옮기지 않도록 제한한다. 후보 자격을 통과해도 실제 세션 시작 시 제공자의 로그인 검사는 별도로 실패할 수 있다.

Laya와 Jev는 같은 모델의 별칭이 아니다. Laya는 로컬 Core ML 결정 모델이며 기본 선택이고 Jev는 기존의 보호된 로컬 자격증명으로 TypeSafe를 직접 호출하는 선택 모드다. Normal 모드에서는 결정 선택을 생략한다. Laya를 선택했지만 모델 설치가 끝나지 않았다면 선호 설정은 유지하면서 일반 하네스를 사용한다. 설정 내용이 손상되거나 읽히지 않을 때도 임의의 외부 서비스로 전환하지 않고 Normal로 돌아가도록 decision_mode.rs에 분기가 있다.

입력 제한도 다르게 잡혀 있다. 라우팅 코드는 전체 후보 상한을 16개로 두지만 Laya에는 최대 8개의 짧은 후보를 제공하고 여러 제공자가 먼저 포함되도록 순서를 섞는다. Laya에 전달하는 작업 설명과 후보 설명도 더 짧게 제한한다. 작은 결정 호출이 유리한지는 이런 후보 구성까지 포함해 평가해야 한다. 호스트가 좋은 후보를 빠뜨리면 선택 모델의 성능만 높여도 그 경로를 선택할 수 없으며 로컬 Laya를 쓴다는 사실만으로 뒤의 코딩 작업자까지 로컬에서 실행되지는 않는다.

도구 이름을 알려 주는 것과 실제로 제한하는 것

내장 DeepSeek 루프의 admitted_tool_names는 선택을 도구 이름에 직접 연결한다. inspect에는 read·grep·glob을 허용하고 implement에는 여기에 write·edit을 더한다. verify는 읽기·검색 도구와 bash를 허용하며 answer는 빈 도구 목록을 받는다. 따라서 답변 단계라는 설명만 프롬프트에 넣고 셸을 계속 노출하는 방식과 다르다. 필요한 쓰기 도구나 셸이 없으면 그 기능에 대응하는 후보 묶음도 준비하지 않는다.

선택한 묶음은 코딩 모델에 전달할 도구 스키마를 좁히며 실행 단계에서도 허용 목록을 검사한다. verify가 선택됐다고 검증이 통과한 것은 아니고 셸 명령의 안전성이 입증된 것도 아니다. 셸에는 기존 실행 권한 검사가 적용된다. 폴백의 의미도 정확히 읽어야 한다. 선택이 없거나 도구 묶음이 오래돼 적용되지 않으면 코드가 원래 도구 목록으로 복귀하므로 결정 계층의 실패를 모든 도구의 차단으로 이해해서는 안 된다.

호스트가 소유하지 않은 루프는 통제하지 않는다

Keel은 ACP로 외부 코딩 에이전트를 연결하지만 그 에이전트의 모든 도구 호출을 가로채지 않는다. Codex·Claude Code·Cursor 등은 자신의 내부 루프를 유지한다. 제공자가 광고한 명령·스킬·모드·도구 목록도 실행 API와 구분된다. 문서에 따르면 ACP의 availableCommands는 메타데이터를 제공하며 현재 경로에서 /name은 프롬프트 텍스트로 전달된다. /compact가 목록에 있다는 이유만으로 Jev가 검증 가능한 압축 작업을 호출할 수 있는 것은 아니다.

컴퓨터 사용도 같은 구분을 따른다. keel computer-use decide는 호스트가 준비한 저위험·되돌릴 수 있는 행동 후보의 ID를 선택하거나 보류할 뿐 데스크톱 조작을 실행하지 않는다. 설치된 Codex Computer Use MCP를 호환 ACP 세션에 연결할 수 있지만 외부 에이전트의 내부 루프 소유권은 바뀌지 않는다. 사용자 승인과 macOS의 접근 허용도 그대로 남는다. 아키텍처 그림에 결정 계층을 그리는 것만으로 모든 클릭과 명령이 그 계층을 통과하는 것은 아니다.

선택 이후의 상태와 결과를 기록한다

후보 목록을 만들 때 가능했던 경로가 모델 응답을 기다리는 동안 사라질 수 있다. 라우팅 코드는 후보 카탈로그의 지문과 만료 시각을 저장하고 선택이 돌아오면 목록을 다시 구성해 대조한다. 제공자의 설치·활성화 상태와 선택한 모델·추론 수준도 재확인한다. 알 수 없는 ID와 바뀐 카탈로그, 사용할 수 없어진 모델은 원래 하네스를 유지하는 폴백으로 연결된다. 이는 경로 선택의 검증이며 저장소의 모든 변경이나 외부 에이전트의 모든 행동을 포괄하는 검증으로 확대할 수는 없다.

기록은 모델의 비공개 추론 과정을 수집하는 용도가 아니다. 호스트가 제시한 후보, 선택 또는 보류, 검증 결과와 폴백, 실제로 뒤따른 결과를 남겨 결정의 효과를 검토한다. 내장 루프의 기록에는 도구 실행·거부·실패 등의 관찰값도 들어간다. 모델을 호출하기 전에 후보가 없어 건너뛴 경로와 실제 모델 호출 후의 보류도 구분한다. 최종 작업이 성공했더라도 폴백 뒤에 원래 작업자가 해결했다면 그 성공을 선택 모델의 공으로 돌릴 근거는 없다.

자기 개선은 릴리스 기능이 아니라 평가 과제다

공개 앱은 채팅 기록으로 Laya를 자동 학습하거나 실패 직후 자신의 정책을 몰래 수정하지 않는다. 원문이 제안하는 개선 과정은 실패 기록을 재현 가능한 시나리오로 바꾸는 개발 절차다. 같은 후보와 작업 조건에서 기존 정책과 변경한 프롬프트·모델·도구 묶음을 실행하고 유효한 선택, 보류, 폴백, 지연과 후속 결과를 비교한다. 조정에 쓴 사례와 마지막 평가에 쓸 작업을 나누고 실패 사례를 남기며 사람의 검토를 거쳐 새 기준을 채택한다. 이전 버전과 롤백 경로도 유지한다.

추가 결정 호출의 이득은 호출 단가만으로 판단하지 않는다. 선택 시간과 코딩 작업 시간, 재시도와 사람의 검토 부담을 합친 전체 작업 비용을 비교해야 한다. 원문은 이러한 코딩 벤치마크의 이득을 아직 입증하지 않았다고 명시한다. 작업자·프롬프트·저장소·채점 기준이 함께 바뀌면 선택 모델의 기여를 분리하기 어려우므로 일반 하네스와의 비교 조건도 고정해야 한다. 앱의 구현 검사가 통과했다는 사실과 코딩 성능이 좋아졌다는 주장은 서로 다른 증거를 요구한다.

빌드 보고서도 저자의 검증 범위를 제한해서 읽어야 한다. 보고서는 전체 작업 공간에서 테스트 1,477개가 통과하고 실서비스 제공자 테스트 18개를 의도적으로 제외했다고 기록하지만 그 실행은 마지막 수정 전 시작됐다. 이후 UI 테스트 444개와 오래된 엔진 상태 관련 테스트 40개가 통과했으며 최종 검사에서 유료 TypeSafe 호출은 하지 않았다. 배포물은 임시 서명한 로컬 개발 빌드로 공개 배포용 Developer ID 서명과 Apple 공증이 남아 있다. 이 노트에서는 해당 문서와 소스를 대조했으며 Keel 앱 설치나 그 테스트 실행을 재현하지 않았다.

참고 자료

Avid — How to Build Agentic Harness using Jev (Builder’s Guide)

Keel 0.2.0 아키텍처 — 고정 소스 스냅샷

Keel 경로 선택 구현

Keel 내장 DeepSeek 에이전트 루프

Keel 결정 모드 구현

Keel 빌드·검증 보고서

Keel 사용 안내

원문 출처는 본문의 Source에서 확인할 수 있습니다.