스스로 발전하는 에이전트: Orkas 자기 진화의 내부 구조

대부분의 AI 도우미는 "쓰고 나면 잊습니다." 오늘 습관을 바로잡아도 내일 같은 실수를 반복하고, 지난주에 팀만의 워크플로를 가르쳐도 이번 주에는 처음 듣는 것처럼 행동합니다. 모든 대화는 0에서 시작합니다. 모델이 아무리 똑똑해도 여전히 기억을 잃은 똑똑한 사람인 셈입니다.

Orkas는 다른 목표를 추구합니다. 에이전트가 일상적인 사용 경험에서 배우고, 반복되는 경험을 정리해 다음에 스스로 적용하도록 하는 것입니다. 쉽게 말해 사용할수록 더 유용해지며, 그 "유용함"은 모델 공급업체가 모두를 위해 미리 정한 방향이 아니라 사용자, 사용자의 선호, 사용자의 분야를 향해 자랍니다.

이 글에서는 그 메커니즘이 어떻게 만들어졌는지 설명합니다. 단순히 "모델이 대화를 기억하게 한다"는 수준이 아닙니다. 그 뒤에는 자기 관찰 → 성찰 여부 판단 → 실제 성찰 → 결론을 재사용 가능한 형태로 기록 → 다음번에 다시 사용이라는 완전한 순환이 있습니다. 하나씩 살펴보겠습니다.

가장 중요한 것부터 말씀드리겠습니다. 아래의 모든 "관찰", "기록", "성찰"은 전적으로 사용자 자신의 기기에서 이루어집니다. 실행 데이터, 스킬, 에이전트의 자기 이해는 모두 일반 파일 형태로 로컬에 저장됩니다. 어느 것도 Orkas 서버에 업로드되지 않으며, 사용자 간 분석이나 모델 학습에 사용되지 않습니다. "자기 진화"란 프로그램이 자신의 실행 기록을 로컬에서 읽고 로컬에서 스스로 개선한다는 뜻이지, 사용자 데이터를 수집한다는 뜻이 아닙니다. 이 경험은 기기를 떠나지 않고 이 한 기기에서 사용자만을 위해 사용됩니다.

순환의 처음부터 끝까지

실제 사용의 반복
      │  호출한 도구, 오류 여부, 수정 여부를 로컬에 기록
      ▼
   신호 누적
      │  대화가 있는 곳에서 신호를 추출하고 모두 기기에 보관
      ▼
  성찰 여부 판단
      │  신호별 가중치 점수가 임계값을 넘을 때만 실행; 일시적인 네트워크 오류는 제외
      ▼
   백그라운드에서 성찰
      │  매 턴이 아니라 주기적으로, 조건을 충족한 에이전트를 선택
      ▼
  두 가지로 정제
      │  ① 재사용 가능한 "스킬"   ② 자신에 대한 "이해"
      ▼
  다음 턴에 자동으로 반영
      └──────────► 처음으로 돌아가 계속 반복

이 순환의 모든 단계에는 미묘한 고려 사항이 있습니다. 가장 실수하기 쉬운 곳은 언뜻 가장 단순해 보이는 두 단계, 언제 성찰하고 성찰 후 무엇을 기록할지입니다. 처음부터 시작하겠습니다.

1단계: 거의 비용 없이 자신을 관찰하기

경험에서 배우려면 먼저 살펴볼 "경험"이 있어야 합니다. 에이전트 실행이 끝날 때마다 프로그램은 현장에서 로컬로 가벼운 사실 몇 가지를 집계합니다. 이번 턴에 도구를 대략 몇 번 호출했는지, 오류가 있었는지, 네트워크 문제 같은 일시적 오류인지 실질적인 오류인지, 사용자가 즉시 바로잡았는지 등입니다. 몇 가지 횟수와 표시만 기기에서 계산하며, 모델을 호출하지 않고 어디에도 보내지 않습니다.

이것이 중요한 이유는 모델 사용 비용이 들지 않기 때문입니다. 현재 턴의 대화 기록에서 바로 집계하므로 "자기 분석"만을 위한 추가 모델 호출이 필요 없습니다. 매 턴 자기 성찰을 위해 모델을 한 번 더 호출해야 한다면 비용과 지연을 감당할 수 없어 이 메커니즘은 출시조차 못 했을 것입니다.

"수정되었는가"라는 항목은 조금 흥미롭습니다. 기기에 있는 메시지의 몇 가지 표현을 대조해 추정하는 순수한 로컬 휴리스틱 판단입니다. 중국어로는 "틀렸어" / "이래야 해" / "다시" 같은 표현, 영어로는 wrong, actually, instead 같은 표현을 봅니다. 정확한 판정을 목표로 하지 않습니다. 결론이 아니라 신호일 뿐이며, 나중에 다른 신호와 함께 가중치를 적용하고 이것만으로 결정하지 않으므로 가끔 잘못 감지해도 괜찮습니다.

2단계: 실제로 성찰할 가치가 있는 시점

전체 메커니즘에서 가장 세심한 설계가 드러나는 부분이라고 생각합니다.

단순한 접근은 "N회가 누적되면 성찰한다"입니다. 하지만 너무 거칩니다. 네트워크 시간 초과 세 번과 사용자 수정 세 번은 분명 다르며 똑같이 다뤄서는 안 됩니다. Orkas는 여러 신호의 가중 점수를 사용합니다. 주목할 현상마다 가중치를 가진 신호를 두고, 이번 턴에서 발생한 신호의 가중치를 합산해 총합이 임계값(기본 0.7)을 넘을 때만 성찰합니다.

주요 신호는 대략 다음과 같습니다.

예를 들어 사용자 수정(0.9)과 어느 정도의 복잡도(0.5)가 함께 있는 턴은 합계 1.4로 0.7을 크게 넘으므로 성찰합니다. 조금 복잡하기만 한 턴(0.5)은 미달이므로 넘어갑니다. 가중치에는 판단도 반영되어 있습니다. 사용자의 직접적인 수정은 0.9로 가장 높습니다. 가장 신호 대 잡음비가 높은 피드백이기 때문입니다. 사용자가 틀렸다고 분명히 말했으니 기록할 가치가 있을 가능성이 매우 높습니다.

결정적으로 중요한 한 가지 예외

전체 점수 로직에서 이 메커니즘이 "올바른 것을 배우는지" 가르는 분수령이라고 생각하는 규칙이 하나 있습니다. 일시적 오류는 절대 집계하지 않습니다.

네트워크 시간 초과, 연결 끊김, 요청 제한은 환경 문제이지 에이전트 자체 역량의 결함이 아닙니다. 이를 제외하지 않으면 나쁜 일이 생깁니다. 우연한 네트워크 이상 한 번 때문에 도구에 오류가 났는데, 성찰 메커니즘이 "이 도구는 불안정하니 덜 쓰자"고 기록하거나, 심지어 멀쩡한 스킬을 망가뜨리거나 삭제합니다. 그 순간부터 에이전트는 잘못된 교훈을 배운 것이며 그 실수가 계속 따라다닙니다.

그래서 "오류에서 복구", "스킬 효과 없음", "알려진 약점에 해당" 신호는 모두 순수한 일시적 오류를 명시적으로 제외합니다. 성찰 프롬프트에도 이 주의를 반복합니다. 네트워크 유형의 오류는 환경 문제이니 약점으로 기록하지 말고 관련 스킬을 건드리지 말라는 것입니다. 자기 개선 시스템이 가장 두려워해야 할 것은 느리게 배우는 것이 아니라 잘못된 방향으로 배우는 것입니다. 이 예외는 바로 그것을 막습니다.

3단계: 성찰은 사용자 앞이 아니라 백그라운드에서

쉽게 빠지는 함정이 있습니다. "성찰할 때"라고 감지하는 순간 그 자리에서 멈추고 성찰하는 것입니다. 그러면 에이전트가 가끔 버벅거리며 "인생을 고민하러" 딴길로 새는 것처럼 느껴집니다. 좋지 않은 경험입니다.

Orkas는 성찰을 백그라운드로 옮겨 일정한 주기로 실행합니다. 대략적인 일정 규칙은 다음과 같습니다.

• 일정 간격마다 성찰 주기를 시작합니다(예를 들어 십수 시간 정도).
• 같은 에이전트의 두 성찰 사이에 최소 대기 시간(몇 시간)을 강제해 너무 자주 실행되지 않게 합니다.
• 다만 너무 오랫동안 성찰하지 않았다면(예를 들어 일주일 이상) 강제로 한 번 실행해 무한정 미뤄지지 않게 합니다.
• 한 주기에서 선택하는 에이전트 수를 제한해 한꺼번에 너무 넓게 분산되지 않게 합니다.

제가 좋아하는 작은 설계로 변경 감지 관문이 있습니다. 주기가 시작되면 먼저 이 에이전트에 지난 성찰 이후 새로운 것이 있는지 확인합니다. 새 신호나 갱신된 대화 기록이 있는지 보는 것입니다. 아무 변화도 없으면 이번에는 건너뛰어 모델 비용이 드는 성찰을 낭비하지 않습니다. 단순하지만 실제로 많은 비용을 절약합니다.

4단계: 실제 성찰 방식

실제로 성찰할 때가 되면 먼저 최근 활동을 "묶음"으로 정리하고, 세심하게 작성한 프롬프트와 함께 모델에 전달해 읽고 요약하게 합니다.

이 묶음에는 예산이 있습니다. 최근 대화 몇 개만 최대한 가져오고, 몇 종류의 시스템 이벤트를 추가하고, 시간순으로 섞은 뒤 전체를 토큰 한도(예를 들어 1만여 개) 안에 맞춥니다. 전체 이력을 쏟아붓는 것이 아닙니다. 다 들어가지도 않고 신호 대 잡음비도 나빠지기 때문입니다.

정말 주의가 필요한 것은 프롬프트입니다. 모델이 "설명"이 아니라 실행 가능한 명령문을 만들도록 요구합니다. 차이는 작아 보여도 매우 중요합니다. 비교해 보세요.

✗ "에이전트의 출력이 때때로 너무 장황하니 주의할 것."

✓ "패밀리오피스 관련 질문에 답할 때는 글머리 기호 항목을 절대 5개 넘기지 말 것."

✗ "사용자는 간결한 출력을 선호하는 것 같다."

✓ "패밀리오피스 맥락에서 답할 때는 항상 결론을 먼저 말하고 그다음 근거를 제시할 것."

프롬프트는 구체적인 발동 조건을 갖춘 "절대 / 항상 / ~할 때는 ~하라" 구조로 모델을 명시적으로 유도합니다. 이유는 실용적입니다. "간결함에 주의할 것"이라는 메모는 다음에 읽어도 행동할 지침을 주지 않지만, "글머리 기호 항목을 절대 5개 넘기지 말 것"은 바로 따를 수 있습니다. 자기 개선이 유용하려면 정리된 내용이 옳지만 뻔한 말이 아니라 실제로 적용되는 지시여야 합니다.

성찰 후 모델은 몇 가지 일을 할 수 있습니다. 스킬을 만들거나 수정하고, 자기 이해를 갱신하거나, 해당 기간에 정말 기록할 만한 것이 없다면 그냥 "저장할 내용 없음"이라고 말할 수 있습니다. 아무것도 하지 않아도 되게 하는 것 자체가 중요한 설계 선택입니다. 학습 결과를 강요하면 쓸모없는 잡음만 쌓이므로 강요하지 않습니다.

두 가지 형태로 정리됩니다

성찰의 출력은 두 곳에 저장됩니다.

하나는 스킬입니다. 각 스킬은 메타데이터가 있는 Markdown 문서입니다. 프런트매터 블록에 이름, 설명, 생성 및 수정 시각, 패치 횟수, 마지막 사용 시각을 기록하고, 그 뒤에 실제 단계나 핵심 사항이 이어집니다.

---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---

## Steps
1. ...
2. ...

스킬을 파일로 저장하는 것은 실용적인 선택입니다. 불투명한 데이터베이스에 갇혀 있지 않아 사람이 직접 읽고 편집할 수 있습니다.

다른 하나는 자기 이해입니다. 이 부분은 에이전트가 자신에게 쓰는 메모에 가깝고 두 부분으로 나뉩니다. 하나는 "무엇을 잘하고 어디서 자주 실수하는지", 다른 하나는 "이 사용자와 이 분야를 위해 익힌 대응 방식"을 기록합니다. 둘 다 길이 상한이 있어 간결해야 합니다. 길수록 좋은 것이 아니라 정확할수록 좋습니다. 다음 대화가 시작되면 이 내용이 시스템 프롬프트에 삽입되어 에이전트가 "자기 이해"를 가진 채 시작합니다.

스킬은 쓰기만 하는 것이 아닙니다

스킬을 만들기만 하면 시간이 갈수록 잡동사니가 쌓입니다. 그래서 스킬에는 완전한 수명 주기가 있습니다.

만들기보다 실제로 더 흔한 작업은 패치입니다. 기존 스킬을 통째로 뜯어고치는 대신 작은 부분을 수정합니다. 패치할 때마다 카운터를 올리고 수정 시각을 갱신합니다. 덕분에 스킬은 매 턴 전체를 다시 쓰는 대신 경험에 따라 점진적으로 자랄 수 있습니다.

개수에도 상한이 있습니다. 전체 스킬 수는 제한됩니다(예를 들어 200개). 가득 차면 새 스킬을 추가할 때 LRU(가장 오랫동안 사용하지 않은 항목 우선) 방식으로 기존 스킬을 제거해 자리를 만듭니다. 제거에도 우선순위가 있습니다. 생성 후 한 번도 사용하지 않은 것을 먼저 내보냅니다. 한 번도 읽히지 않은 스킬은 애초에 제대로 정리되지 않았을 가능성이 높으므로 자리를 내주는 편이 낫습니다.

에이전트가 스킬을 읽을 때마다 "마지막 사용 시각"이 갱신됩니다. 이 타임스탬프는 LRU의 제거 판단에 쓰이며, 로컬 메커니즘이 실제로 쓰이는 스킬과 자리만 차지하는 스킬을 구분하게 해 줍니다.

스킬이 실제로 유용한지 확인하는 방법

많은 "자동 학습" 시스템이 대충 건너뛰는 단계입니다. 무언가 배웠지만 쓸 만한가? Orkas는 이를 로컬에서 몇 가지 지표로 바꿉니다. 이 지표는 기기 내 진화 메커니즘이 어떤 스킬을 수정하거나 삭제할지 판단하기 위해 계산하며, 역시 이 기기 밖으로 나가지 않습니다.

방식은 이렇습니다. 각 턴이 시작되면 사용 가능한 스킬이 시스템 프롬프트의 색인에 나타납니다. 이것이 한 번의 "노출"입니다. 그 턴에서 에이전트가 실제로 스킬을 읽으면 한 번의 "호출"입니다. 둘을 비교하면 첫 번째 지표를 얻습니다.

• 호출률 = 호출 수 / 노출 수. 날마다 놓여 있지만 아무도 쓰지 않는 스킬은 호출률이 낮습니다. 쓸모가 없거나, 설명만으로는 언제 써야 할지 알 수 없다는 뜻입니다.
• 호출 후 수정률 = 스킬 호출 후 사용자가 결과를 직접 수정한 비율. 높다면 스킬이 만든 결과가 사용자의 취향에 잘 맞지 않는다는 뜻입니다.
• 비효과율 = 스킬을 호출했지만 턴이 일시적이지 않은 오류로 끝난 비율. 높다면 스킬 자체에 문제가 있을 가능성을 시사합니다.

여기서도 그 예외 규칙이 다시 드러납니다. 비효과율을 계산할 때는 일시적 오류도, 사용자가 도중에 수동 중지한 턴도 집계하지 않습니다. 네트워크 이상 한 번으로 멀쩡한 스킬에 낙인을 찍어서는 안 됩니다.

이 몇 가지 숫자로 스킬은 "블랙박스에 쌓이는 것"에서 "평가하고 최적화할 수 있는 것"으로 바뀝니다. 어떤 스킬을 수정하거나 삭제할지가 더 이상 직감에 따른 결정이 아닙니다.

순환 완성하기

위의 내용을 연결하면 한 번의 전체 주기는 다음과 같습니다.

에이전트는 실제 작업을 수행하면서 실행 데이터를 로컬에 기록하고 그 자리에서 신호를 표시합니다. 백그라운드 성찰 주기가 되면 새로운 변화가 있고 대기 시간이 지난 에이전트를 선택하고, 각 에이전트의 최근 활동을 묶음으로 정리해 모델이 현재의 자기 이해와 대조하며 검토하게 합니다. 합칠 것은 합치고, 폐기할 것은 폐기하며, 정리할 것은 새 스킬로 정리합니다. 검토 결과는 스킬과 자기 이해가 됩니다. 다음 대화에서는 스킬이 프롬프트 색인에 들어가고 자기 이해가 시스템 프롬프트에 들어가 에이전트가 지난번에 배운 것을 가지고 돌아옵니다. 그리고 이번 주기는 새로운 지표와 신호를 만들어 처음으로 다시 전달합니다.

순환은 계속 이어집니다. 매번 극적인 도약이 있는 것은 아니지만 방향은 하나입니다. 사용자를 더 잘 이해하고 같은 실수를 덜 반복하는 것입니다.

짚어 볼 만한 몇 가지 절충

돌아보면 이 메커니즘에서 몇 가지 결정이 핵심입니다.

자기 관찰은 저렴해야 합니다. 관찰에는 모델 비용이 없는 지표를 쓰고, 실제로 비싼 성찰은 백그라운드로 옮겨 드물게 실행하며 먼저 변경 여부 검사로 걸러 냅니다. "비싼" 부분을 엄격하게 제한해야 전체 메커니즘이 실제로 돌아갈 수 있습니다.

잘못 배우느니 배우지 않는 편이 낫습니다. 일시적 오류 제외, 성찰 후 "저장하지 않기" 허용, 모호한 설명 대신 실행 가능한 명령문 작성은 모두 같은 판단을 가리킵니다. 자기 개선 시스템에서는 잘못된 방향으로 배우는 것이 느리게 배우는 것보다 훨씬 위험합니다.

배운 것은 눈에 보이고, 편집할 수 있으며, 사용자 손안에 있어야 합니다. 스킬은 일반 텍스트 파일이고, 자기 이해는 일반 텍스트 메모이며, 스킬의 효과는 지표로 확인할 수 있습니다. 이 모든 파일은 클라우드가 아니라 사용자 기기에 있습니다. 어디에도 블랙박스가 없으며 사람이 언제든 열어 수정할 수 있습니다.

학습에 제동 장치를 두세요. 개수 상한, LRU 제거, 길이 제한이 없으면 "지속적인 학습"은 언젠가 "지속적인 비대화"가 됩니다. 잊고, 버리고, 가지치기하는 일은 기억하는 일만큼 중요합니다.

마무리

Orkas의 자기 진화는 본질적으로 에이전트에 느린 순환을 추가하는 것입니다. 빠른 순환은 각 대화의 즉각적인 응답이고, 느린 순환은 주기적으로 돌아보며 경험을 다음번에 쓸 수 있는 형태로 정리하는 것입니다. 어려운 부분은 "모델이 기억하게 하기"가 아니라 놓치기 쉬운 엔지니어링 판단입니다. 어떤 경험이 기록할 가치가 있는지 구분하는 법, 우연한 실패에 흔들리지 않는 법, 배운 내용을 실제로 실행 가능하게 만드는 법, 비대해지기 전에 가지치기하는 법입니다.

이 판단들이 모이면 "쓸수록 더 유용해진다"는 말은 마케팅 문구에서 실제로 작동하는 메커니즘으로 바뀝니다. 사용자에게 배우면서도 잘못된 것은 배우지 않는 도우미가, 단지 더 똑똑하기만 한 도우미보다 대부분의 사람이 실제로 원하는 것에 더 가까울 수 있습니다.

이 느린 순환의 기반이 되는 전문 에이전트를 보려면 Orkas 에이전트 팀을 둘러보세요.