Sillok 하네스는 어떻게 개선되는가: 루프 구조와 TOP 5 설계 원칙

PART 011. 두 루프가 서로 다른 일을 맡습니다

빠른 루프는 사용자 요청 하나를 처리합니다. 의도와 범위를 확인하고, 필요한 지식·절차를 고른 뒤, 도구를 실행하고 결과를 검증합니다. 작업 중 발견한 오류는 그 요청 안에서 수정합니다. 사용자가 얻는 산출물이 이 루프의 끝입니다.

느린 루프는 여러 실행에서 반복되는 문제를 찾습니다. 관측 기록을 모으고, 후보 하나를 고르고, 격리한 환경에서 실험합니다. 조건을 통과한 변경만 허용 범위 안에 반영합니다. 채택 후에는 새로운 기간의 결과와 회귀를 다시 관측합니다.

요청 경로의 라우터는 필요한 자산의 좌표와 소비 계획을 제공합니다. 해당 자료를 실제로 읽거나 생략 이유를 남기는 일은 호스트 에이전트가 수행합니다. 좌표를 반환했다는 사실만으로 검색과 근거 확인이 완료되지는 않습니다.

주기적 개선의 운영 진입점은 기존 예약 작업에 연결돼 있습니다. 일간 관측은 04:05, 주간 점검은 월요일 02:40에 시작하도록 설정돼 있습니다. 시간대는 한국 표준시입니다. 기본 관측 창은 최근 90일이고, 마지막 7일을 변화 탐지에 사용합니다. 이 값들은 현재 운영 설정이며 연구가 입증한 최적 주기는 아닙니다.

별도의 프롬프트 최적화·제안 경로도 있습니다. GEPA 계열 경로와 컨설팅 개선 실행기는 후보를 직접 주고받는 하나의 파이프라인이 아닙니다. 제안·승격·자동 흡수는 각 경로의 정책을 따릅니다. 컨설팅 개선 실행기가 자신의 라우터나 승인 규칙까지 자유롭게 고치는 구조로 읽으면 안 됩니다.

PART 022. TOP 5는 운영 문제에서 골랐습니다

여기서 TOP 5는 세계 공인 순위가 아닙니다. 반복 업무를 운영하는 Sillok에 적용할 설계 우선순위입니다. 선정 기준은 반복 오류를 설명하는가, 실제 코드로 검증할 수 있는가, 운영 비용과 결과 품질을 함께 살필 수 있는가입니다. 특정 제품을 도입해야만 성립하는 원칙은 제외했습니다.

아래 다섯 원칙은 서로 다른 1차 자료를 대조한 결과입니다. 문헌의 공통 설계 방향은 비교적 강한 근거가 있지만, 이를 Sillok에 적용했을 때의 개선 폭은 별도 실험이 필요합니다. 따라서 설계 방향의 근거는 A, Sillok의 효율·효과 개선 가설은 C로 구분합니다. A는 독립 출처 세 갈래의 수렴, B는 두 갈래의 수렴, C는 맥락에 적용한 추론을 뜻합니다.

이 등급은 설계 원칙에 대한 상호보완과 반증의 범위를 나타냅니다. 동일한 실험을 독립적으로 재현한 횟수나 성능 향상의 확률을 뜻하지는 않습니다.

다섯 항목을 한꺼번에 늘릴 필요는 없습니다. 비용이 많이 드는 반복 실패부터 적용하고, 구성요소를 하나씩 빼 보는 제거 실험(ablation)도 함께 해야 합니다. 하네스가 복잡해질수록 좋아진다는 가정은 이 글의 출발점이 아닙니다.

PART 033. 필요한 근거를 읽었는지 확인합니다

첫 번째 원칙은 컨텍스트의 양보다 역할과 사용 여부를 관리하는 것입니다. OpenAI의 2026년 2월 사례는 거대한 지침 파일을 지식 지도로 바꾸고, 저장소의 구체적인 문서를 탐색하도록 구성했습니다. Agent Skills 사양도 메타데이터에서 본문, 필요한 참조로 점진적으로 정보를 제공합니다.

Sillok의 지식 경로는 세 역할로 나뉩니다. Vault는 원문과 관측을 보관합니다. ATLAS는 관련 사례와 위치를 찾아가는 좌표입니다. 조직 프로세스 자산(Organizational Process Assets, OPA)은 검증된 절차·규칙·평가 기준을 제공합니다. 세 이름은 지식을 무조건 세 번 복사한다는 뜻이 아닙니다.

현재 구현은 분야별 원천 좌표와 평가 기준을 라우팅에 연결하고, 현재 파일 해시를 대조합니다. 호스트는 계획된 단계에서 자료를 읽거나 생략 사유를 기록합니다. 이렇게 하면 “어떤 근거로 이 답을 만들었는가”를 추적할 수 있습니다. 다만 잘못 고른 원천을 충실히 읽을 가능성은 별도로 검사해야 합니다.

반증도 함께 봐야 합니다. Evaluating AGENTS.md v2는 컨텍스트 파일을 추가하는 것만으로 과제 성공률이 일반적으로 높아지지 않았다고 보고합니다. 저장소의 비표준 관례를 명확히 전달하는 용도와 성능 향상 주장을 구분해야 합니다. 이 연구를 “지침은 모두 해롭다”거나 “짧을수록 항상 좋다”는 주장으로 확대할 수는 없습니다.

Sillok에서 다음으로 비교할 것은 필수 근거만 제공한 조건과 현재 조건입니다. 같은 과제에서 필수 원천 누락, 잘못된 인용, 입력 토큰, 재탐색 횟수를 함께 측정합니다. 컨텍스트를 줄였는데 필수 제약을 놓쳤다면 효율 개선으로 채택하지 않습니다.

PART 044. 다음 실행이 이어받을 상태를 남깁니다

두 번째 원칙은 대화가 끊겨도 작업의 사실을 복원하는 것입니다. Anthropic의 장기 실행 사례는 작업을 나누고 다음 세션이 이어받을 산출물을 남깁니다. LangGraph의 영속성 문서는 실행 상태를 체크포인트로 저장하고 복원하는 구조를 설명합니다.

Sillok에서는 실행 기록과 재사용 지식을 구분해 보는 것이 유용합니다. 실행 기록에는 후보, 시도, 실패, 적용 파일, 검증 결과가 남습니다. 재사용 지식에는 다음 요청에도 적용할 수 있는 근거와 절차가 남습니다. 시도했다는 기록을 완료한 작업으로 읽거나, 한 번의 반성을 보편적인 규칙으로 승격하면 두 층이 오염됩니다.

현재 컨트롤러는 점검 시도와 완료 이력을 분리하고, 동시 갱신 시 기존 이력을 보존합니다. 실행기는 잠금과 실행 프로세스의 식별 정보를 확인합니다. 이것이 곧 모든 장애에서 정확히 한 번 실행된다는 보장은 아닙니다. 외부 부수 효과가 있는 작업으로 확장하려면 중복 요청 처리와 장애 복구 시나리오를 추가로 검증해야 합니다.

설계 권고는 간단합니다. 다음 실행이 긴 대화를 다시 해석하기 전에, 완료한 일·남은 일·실패 근거·현재 파일 상태를 읽게 합니다. 원장 크기보다 재개에 필요한 상태를 정확히 복원하는가가 측정 대상입니다.

PART 055. 행동·결과·현장 효과를 따로 검증합니다

세 번째 원칙은 평가 질문을 나누는 것입니다. Google의 2026년 9월 9일 글은 작은 관측 행동의 검사와 전체 과제 평가를 상호보완으로 설명합니다. 최종 점수만 보면 실패 원인을 알기 어렵고, 도구 호출만 검사하면 실제 목적을 달성했는지 놓칠 수 있습니다.

행동 검사에서는 잘못된 귀속을 막는지, 실제 파일을 읽었는지, 실행한 검사 결과를 보존하는지 확인합니다. 종단 간(End-to-End, E2E) 평가에서는 사용자의 과제가 실제로 완성됐는지 확인합니다. 현장 평가에서는 적용 후 산출물과 명시적 사람 피드백을 확인합니다. 세 질문을 하나의 점수로 합치지 않는 편이 원인을 찾기 쉽습니다.

LangChain의 Deep Agents 평가 설명은 평가 범위와 실행 조건을 함께 관리합니다. Anthropic의 2026년 3월 사례는 생성자와 평가자를 분리하고, 실행 중인 애플리케이션을 직접 확인합니다. 평가자를 따로 둬도 과도하게 관대한 판단은 남을 수 있으므로 구체적인 기준과 검증 사례가 필요합니다.

Sillok의 현재 실행기는 작업자의 성공 선언만으로 반영하지 않습니다. 새 테스트가 기준선에서 행동 실패를 재현하는지, 후보에서 새 테스트와 기존 검사가 통과하는지 별도로 실행합니다. 실제 산출물 비교기는 동일 원천·모델·추론 설정·평가 판본의 기준선과 후보를 짝지어 검사합니다. 비교에 쓰는 파일의 존재와 내용 해시도 확인합니다.

여기에는 중요한 한계가 있습니다. 비교기의 eligible은 비교 근거가 형식상 적격하다는 뜻입니다. 평가자의 전문성이나 사람이 매긴 점수의 진실성까지 인증하지는 않습니다. 분야별 품질 저하를 평균값이나 비용 절감으로 상쇄하지 않는 정책은 있지만, 실제 전문가 대비 성과는 아직 측정되지 않았습니다.

PART 066. 한 번의 실험이 바꿀 범위를 제한합니다

네 번째 원칙은 자율성의 범위를 실행 전에 정하는 것입니다. 허용 파일, 최대 변경량, 반복 예산, 검증 조건, 복원 조건을 구체화해야 합니다. 이러한 경계는 실패했을 때 확인하고 되돌려야 할 범위를 줄이는 데 도움이 됩니다. 그 절감 폭은 실제 운영 비용으로 확인해야 합니다.

현재 초기값은 주간 최대 한 번의 시도, 기본 실행 제한 시간 1,800초입니다. 파일 수·바이트·변경 줄 수에도 상한이 있습니다. 기존 사용자 변경과 대상 파일 해시가 충돌하면 자동 반영을 보류합니다. 반영 후 또는 후속 기술 검사에 실패하면, 적용 이후 파일이 다시 바뀌지 않았는지 확인한 뒤 조건부로 복원합니다.

사람 피드백에서 회귀가 관측되면 신규 실행을 중단하고 별도의 판단을 요구합니다. 그 피드백 자체가 자동 복원 명령은 아닙니다. 후속 기술 검사는 최근 적용 건을 대상으로 하며, 모든 과거 변경을 항상 재검증하는 구조까지 갖춘 것은 아닙니다.

OpenAI의 하네스 사례는 경계를 문서와 기계 검사로 함께 유지합니다. Anthropic의 후속 실험은 모델 역량이 달라지자 구성요소를 하나씩 제거하며 필요성을 다시 확인합니다. LangChain의 평가 운영 역시 실행 조건과 평가 비용을 비교의 일부로 다룹니다.

따라서 “항상 더 많은 에이전트”나 “항상 더 많은 검토”가 정답은 아닙니다. 작업을 나눠서 독립적으로 수행할 수 있을 때 병렬화하고, 조정 비용이 큰 작업은 단순하게 유지하는 편이 합리적입니다. 이 선택도 같은 과제의 품질·시간·토큰·사람 재작업을 비교해 결정해야 합니다.

주간 한 번이라는 설정 역시 보편적인 최적값은 아닙니다. 반복 실패의 빈도, 검증 비용, 복구 부담을 보며 조정할 운영 예산입니다. 중요한 것은 멈출 조건을 실행 전에 정하고, 예산을 다 쓴 사실을 성공으로 해석하지 않는 것입니다.

PART 077. 반성은 검증된 작은 변경으로 남깁니다

다섯 번째 원칙은 “다음에는 주의하겠습니다”를 재사용 가능한 변경으로 바꾸는 것입니다. GEPA는 실행 궤적과 피드백을 후보 탐색에 사용합니다. Reflexion은 피드백에서 만든 언어적 반성을 다음 시도에 연결합니다. ACE는 구조화한 컨텍스트를 작은 변경으로 갱신하는 방법을 연구합니다.

Sillok에 적용할 핵심은 반성 문장의 길이가 아닙니다. 실패 근거를 보존하고, 무엇을 바꾸는지 좁히고, 기존 성공 사례를 유지하는지 확인하는 것입니다. 원천과 판단 조건을 잃은 채 전체 지식을 반복 요약하면 예외와 세부 규칙이 사라질 수 있습니다.

현재 컨설팅 개선 루프는 후보와 원천 해시, 실행 결과, 반영 증거를 연결합니다. 실제 적용 기록과 일치하고 채택 이후에 관측된 사람 피드백을 별도로 읽습니다. 미래 시각, 중복, 충돌한 피드백을 새 성과로 세지 않습니다. 사람의 응답이 없다는 이유로 만족을 합성하지도 않습니다.

이 구성은 세 연구에서 얻은 원리를 적용한 로컬 설계입니다. GEPA·Reflexion·ACE 전체 알고리즘을 그대로 재현하거나 모델 가중치를 학습시켰다는 뜻은 아닙니다. 운영 규칙·컨텍스트·도구·검증 사례를 바꾸는 개선과 모델 학습은 구분해야 합니다.

PART 088. 검사 통과만으로 효과를 확정할 수 없습니다

이 글의 출발점이 된 실제 실행에서 수정 대상은 상대 경로의 프로젝트 귀속 결함이었습니다. 실행기는 수정안을 만들었지만 최초 자동 반영은 테스트 명령 형식 때문에 차단됐습니다. 이후 부모 세션이 기준선 실패와 후보·기존 검사의 통과를 확인하고 반영했습니다. 최초 차단 기록도 보존했습니다.

종료 직전에는 기준 커밋에 선택한 변경만 얹은 독립 후보에서 관련 테스트 221개가 통과했습니다. 이것은 해당 회귀 범위의 코드 검증 결과입니다. 자동 실행 성공률, 전체 컨설팅 정확도, 사용자 생산성의 개선율을 뜻하지는 않습니다. 이 수치는 2026년 9월 13일 내부 종료 검증 기록에 근거합니다.

이 구조가 잘 작동하지 않는 조건도 있습니다. 원천 자체가 부정확하면 해시가 맞아도 잘못된 판단을 합니다. 평가 사례가 후보 작성에 노출되면 비교가 낙관적으로 치우칠 수 있습니다. 검사하기 쉬운 행동에만 맞추면 실제 업무 결과를 놓칠 수 있습니다. 검토 단계가 과도하면 개선으로 얻은 시간보다 운영 비용이 커질 수 있습니다.

효율은 수용 가능한 결과 한 건을 얻는 데 필요한 시간·토큰·사람 재작업으로 측정하는 편이 유용합니다. 효과는 요구 충족, 중요한 오류, 실제 사용자의 평가로 확인합니다. 두 지표를 함께 보되 품질 저하를 비용 절감으로 덮지 않는 것이 이 글의 권고입니다.

PART 099. 반복 실패 하나로 이번 주 실험을 시작합니다

처음부터 모든 루프를 자동화할 필요는 없습니다. 최근 작업에서 다시 발생한 실패 하나를 고르고, 무엇이 달라지면 개선으로 인정할지 적어 봅니다. 다음 문장을 자신의 하네스에 넣으면 비교 실험의 초안을 만들 수 있습니다.

최근 반복 실패 하나를 선택해 주세요.
1. 실패한 실제 근거와 과제 범위를 확인합니다.
2. 현재 조건을 기준선으로 고정하고 변경 후보 하나만 만듭니다.
3. 실패 재현 검사와 기존 성공 검사를 분리합니다.
4. 같은 원천·모델·추론 설정으로 기준선과 후보를 비교합니다.
5. 후보 작성에 쓰지 않은 사례에서 실제 결과를 확인합니다.
6. 품질, 시간, 토큰, 사람 재작업을 각각 기록합니다.
7. 변경 권한·반영 범위·중지 및 복원 조건을 먼저 명시합니다.
8. 실제 채택 이후의 새 결과만 후속 효과로 기록합니다.
증거가 없으면 미측정으로 남기고 성공을 추정하지 않습니다.

이 원문은 Sillok 전용 실행 명령이 아니라 재사용 가능한 실험 요청입니다. 산출물은 실패 근거, 변경 후보, 비교 조건, 검사 결과, 채택 여부가 담긴 짧은 기록 한 장이면 충분합니다. 실제 명령과 권한은 자신의 환경에 맞게 확정합니다.

권장 시작 순서는 실패 근거와 기준선 고정, 작은 후보의 비교, 채택 이후의 새 관측입니다. 소요 시간은 과제에 따라 다르므로 여기서 고정하지 않습니다. 한 차례 실험이 끝나면 추가한 구성요소가 정말 필요했는지 제거 실험으로 다시 살펴봅니다.

Sillok의 루프를 관통하는 질문은 하나입니다. “이번 변경이 다음 작업에서 무엇을 더 낫게 만들었고, 그것을 무엇으로 확인했습니까?” 이 질문에 답할 수 있도록 근거·상태·평가·권한·변경을 연결하는 것이 효율적이고 효과적인 하네스를 향한 설계 방향입니다.

이전 구조와 현장 적용 맥락은 Sillok 하네스 엔지니어링과 컨설턴트의 Sillok·3층 지식 운영 사례에서 이어서 볼 수 있습니다.

PART 1010. 원문과 판본을 함께 확인합니다

아래 목록은 본문에서 사용한 공개 1차 자료입니다. 제품 문서는 지속 갱신될 수 있으므로 확인일과 함께 읽어야 합니다. 내부 구현 기록은 설계의 존재와 테스트 결과를 확인하는 근거이며, 독립적인 효과 연구로 집계하지 않았습니다.

• Google Developers, The Anatomy of Harness Engineering, 2026-09-09. 행동 평가와 E2E 평가의 분업입니다.
• OpenAI, Harness engineering, 2026-02-11. 지식 지도·기계적 경계·피드백 운영의 실제 사례입니다.
• Anthropic, Harness design for long-running application development, 2026-03-24. 생성·평가 분리와 구성요소 제거 실험입니다.
• Anthropic, Effective harnesses for long-running agents, 2025-11-26. 세션 간 작업 분할과 상태 전달 사례입니다.
• LangChain, How We Benchmark Deep Agents, 2026-07-23. 평가 범위와 비교 조건을 운영하는 방법입니다.
• Agent Skills, Specification, 2026-09-13 현행 문서 확인. 필요한 정보를 점진적으로 제공하는 구조입니다.
• LangGraph, Persistence, 2026-09-13 현행 문서 확인. 실행 체크포인트와 복원 구조입니다.
• Gloaguen 외, Evaluating AGENTS.md, v2, 2026-06-23. 컨텍스트 파일의 효용을 과제에서 검증해야 한다는 반증 자료입니다.
• Agrawal 외, GEPA, v2, 2026-02-14. 실행 피드백을 활용하는 반성적 후보 탐색 연구입니다.
• Shinn 외, Reflexion, NeurIPS 2023. 언어적 피드백과 에피소드 기억을 연결합니다.
• Zhang 외, ACE, v3, 2026-03-29. 구조화한 컨텍스트의 점진적 갱신을 다룹니다.

김태영 · 프로젝트리서치