Operation을 판단한다는 것
Operation은 agent가 실제로 하는 일입니다. 읽기, 쓰기, 변환, 공개, 삭제, 알림, 결제, 위임 같은 행동이 모두 operation입니다. 중요한 점은 operation이 자연어 목표보다 훨씬 구체적이어야 한다는 겁니다. '정리해줘'는 목표이고, 파일 읽기와 새 파일 쓰기는 operation입니다.
Agent에게 operation을 판단시키려면 각 action에 actor, target, tool, permission, precondition, side effect, postcondition을 붙여야 합니다. 이 슬롯이 없으면 모델은 실행 가능성과 실행 허용을 섞습니다.
Invariant를 agent에게 보여주고, 그것을 기반으로 planning하게 해야 합니다. 주장과 가설이 memory에 들어가고 나가는 과정이 정리되어야 agent taxonomy를 제대로 활용할 수 있습니다. 들어오는 모든 가설을 하나하나 처리하기에는 2026년에도 메모리 가격이 비쌉니다. 가설 합병이 필요하지만, 과하게 묶였을 때는 적극적으로 분할해야 합니다. 시간이 지난 가설은 메모리에서 빼내는 것이 agent 설계의 중요한 원칙입니다.
Internalization Boundary
Internalization Boundary는 무엇을 모델의 습관으로 기대하고, 무엇을 장기 기억이나 외부 조회로 남길지 가르는 선입니다. 예를 들어 법적 규제 준수 우선, destructive action 확인, 출처 확인 같은 원칙은 내재화되어야 합니다.
장점은 빠르다는 것입니다. 한 번 내재화된 원칙은 매번 retrieval하지 않아도 작동합니다. 단점은 수정이 어렵다는 것입니다. 한 번 모델 안에 들어간 습관은 외부 rule처럼 즉시 바꾸기 어렵습니다. 그래서 Internalization Boundary는 특히 제한적으로 활용되어야 합니다.
반면 특정 프로젝트의 배포 명령, 사용자의 세부 선호, 최근 장애 기록, 광고 단위 ID는 LongTerm Memory나 외부 파일로 두는 편이 낫습니다. 바뀌는 정보를 모델 내부 지식으로 믿으면 곧 낡습니다.
Action Ontology
Action Ontology는 action을 문장보다 구조로 봅니다. DeleteFile은 target path, backup status, user approval, reversibility를 요구합니다. PublishPage는 content license, privacy notice, build status, served content check를 요구합니다. SendEmail은 recipient, consent, sensitive data check를 요구합니다.
이 구조가 있으면 agent는 action 전 필요한 질문을 스스로 찾습니다. target이 없으면 실행하지 않고, approval이 없으면 멈추고, postcondition이 없으면 성공을 확정하지 않습니다. Action Ontology의 장점은 바뀔 수 있는 rule을 넣기 좋다는 점입니다. 단점은 Internalization Boundary에 비해 덜 내재화되어 있어 매번 구조를 읽고 적용해야 한다는 점입니다.
메모리에 들어가는 내용은 문제가 없어 보이는데 결과가 계속 아쉽다면 repair rule이 필요합니다. 이때 No Operation도 하나의 operation이라는 점을 잊으면 안 됩니다. 아무것도 하지 않는 판단이 최고의 action일 때가 있습니다.
정리
Action Ontology는 주장, 가설, Belief를 철저하게 구분해야 하며 혼용은 금지됩니다. 논리적 규칙의 엄격한 준수, 멱등성, 순서, monotonic 관리도 필수입니다. 같은 action을 두 번 해도 괜찮은지, 순서가 바뀌면 안 되는지, 새 정보가 들어와도 기존 결론이 유지되는지 따져야 합니다.
추론 기능이 있는 2026년 LLM들의 추론 품질을 올리려면 논리체계를 최대한 잘 설계해야 합니다. 법적 규제 준수는 action ontology의 필수 슬롯입니다. publish, transmit, delete, purchase, advise 같은 operation은 모두 법적·정책적 조건을 가질 수 있습니다.
Taxonomy
- operation taxonomyread, write, transform, publish, delete, notify, purchase, delegate operation을 분리합니다.
- internalization boundary taxonomy항상 지킬 원칙, 장기 기억으로 둘 사실, 매번 조회할 상태, 인간에게 물을 판단을 나눕니다.
- long-term memory taxonomy사용자 선호, 프로젝트 convention, 과거 결정, 실패 기록, 승인 기록을 다른 타입으로 둡니다.
- action ontology taxonomyactor, target, tool, permission, precondition, side effect, postcondition을 action의 슬롯으로 둡니다.
- operation proof taxonomy왜 실행해도 되는지 보여주는 근거, 승인, 정책 통과, 검증 결과를 나눕니다.
- invariant taxonomy상황이 바뀌어도 유지되어야 할 원칙과 도메인 불변식을 분리합니다.
- hypothesis lifecycle taxonomy입력, 합병, 분할, 만료, 삭제, belief 승격 단계를 둡니다.
- no operation taxonomy멈춤, 질문, 보류, 거절, 관찰 지속을 실행 가능한 operation으로 취급합니다.
- idempotency taxonomy반복 실행 가능, 한 번만 가능, 순서 의존, rollback 필요 action을 나눕니다.
- repair rule taxonomy결과가 아쉬울 때 memory, rule, planner, ontology 중 무엇을 고칠지 분류합니다.