AI Agentic System Memo

OpenClaw 기반 AI Agentic System 설계 메모

1. GitHub Backup / Rollback 구조에 대한 생각

OpenClaw에서 GitHub에 커밋/푸시를 하도록 하는데, 작업 전과 작업 후에 각각 백업을 남기고 싶다.

이유는 에이전트가 잘못 작업해서 전체를 망가뜨릴 수 있기 때문이다. 따라서 언제든지 복구 가능해야 한다.

복구는 새로운 환경에서 Agent에게 복구를 지시해서 진행할 생각이다.

이때 GitHub 접근 권한을 주고, 백업된 상태를 기준으로 복구하도록 만들고 싶다.

핵심은 다음과 같다.

• 작업 전 백업
• 작업 후 백업
• 문제가 생기면 롤백 가능
• 새 환경에서도 복구 가능
• 에이전트가 실수해도 복구 가능한 구조

즉, 에이전트의 실수를 전제로 하고, 복구 가능성을 시스템 차원에서 확보하고 싶다.

2. 맥락적 사고 문제

AI 서비스는 이미 구독제를 통해 OAuth를 활용할 수 있는데도,

자꾸 OAuth에 문제가 생겼다고 API를 쓰려는 경향이 있다.

문제는 다음과 같다.

• 이미 구독제로 OAuth를 쓸 수 있음
• 굳이 추가 비용을 내며 API를 쓰려 함
• 이 내용이 문서화되어 있어도 참고하지 않거나
• 참고했더라도 깊게 고려하지 않는 경우가 있음
• 상황적 판단을 제대로 하지 못함

즉, AI가 단순히 정보를 “봤다”와 실제로 “상황을 고려해 적용했다”는 다른 문제다.

내가 느끼는 핵심 문제는 이것이다.

• 문서를 읽는 것만으로는 부족함
• 문서를 실제 의사결정에 반영해야 함
• 상황적 판단과 맥락 고려가 필요함
• AI가 이를 자주 놓침

이걸 어떻게 해결할지 고민 중이다.

3. 새로 직면한 문제: 메모리 문제가 아니라 컨텍스트 토큰 문제

어제 밤부터 오늘 새벽까지 느낀 점은,

현재 문제는 메모리의 문제가 아니라 컨텍스트 토큰의 문제에 더 가깝다는 것이다.

대화에서 맥락 이해나 의도 파악 능력이 저하되는 현상이 있는데,

그 원인은 Main Agent에게 너무 많은 지침사항을 넣어두었기 때문이라고 본다.

즉,

• 지침사항이 너무 많음
• 지침의 크기가 대화의 크기와 충돌함
• 일부 지침사항이 컨텍스트에서 날아가거나
• 일부 대화 내용이 포함되지 못하고 날아감
• 그 결과 맥락 이해와 목적 파악이 저하됨

그래서 내가 생각한 해결 방향은,

지침사항을 전담하는 Agent와 실제 대화를 담당하는 Agent를 분리하는 것이다.

4. 현재 구상 중인 분업 구조

PMA(Project Manager Agent) 구조를 확장해서 점점 더 빌딩하는 중이다.

내가 생각한 기본 구조는 다음과 같다.

1) Main Agent

• 사용자와 직접 대화하는 Agent
• 내 목적과 의도를 파악
• 맥락을 제대로 이해
• 대화 자체에 집중

2) 규칙/지침 담당 Agent

• 규칙과 지침을 따라 계획을 만듦
• 규칙과 지침을 따르게 함
• 실제로 잘 따르고 있는지 검수
• 헌법처럼 항상 따라야 하는 규칙을 관리

3) PMA (Project Manager Agent)

• 실제 작업이나 프로젝트를 총괄 관리
• 작업 분해
• Worker Agent 생성 및 관리
• 결과물 취합 및 진행 관리
• 오류/문제 인지 및 재시도 지시

4) Worker Agent

• PMA가 생성
• 실제 작업 수행
• 리서치, 문서화, 구현, 분석 등 개별 작업 담당

5. 왜 이런 분업 구조가 필요한가

Main이 모든 작업을 다 하면 문제가 생긴다.

예를 들면,

• 대화도 해야 하고
• 전체 총괄도 해야 하고
• 문서도 뒤져야 하고
• 툴 호출도 해야 하고
• 실제 작업도 해야 하고
• 검증도 해야 함

이렇게 되면 컨텍스트가 한 번에 터진다.

1M 컨텍스트라고 해도 계속 쌓이면 결국 문제가 생길 수 있다.

또한,

• 맥락이 흐려짐
• 이해도가 떨어짐
• 의도 파악이 약해짐
• 목적을 잃어버림
• 집중이 분산됨

쉽게 말하면,

한 사람이 실제 업무도 하면서, 전체 총괄도 맡고, 대화도 하고, 문서도 찾고, 검수도 하는 구조다.

사람도 못하는 일이고 AI도 못한다고 본다.

그래서 분업 체계를 만들어서 최대한 나누어야 한다.

핵심은 다음과 같다.

• Main Agent는 사용자 대화에만 집중
• 지침을 따르는 Agent는 지침을 따르는 데만 집중
• 작업 총괄은 PMA가 담당
• 실제 작업은 Worker가 담당

즉, 집중 자산을 분리해야 한다는 것이다.

6. Rule Agent에 대한 구상

Main에 모든 지침을 넣는 대신,

지침을 따르게 하는 Agent들을 따로 두는 구조를 생각하고 있다.

예를 들어,

• Rule1 Agent
• Rule2 Agent
• Rule3 Agent
• ...

이런 식으로 각 지침을 분할하여 전담하게 만든다.

구상은 대략 이렇다.

• Main은 대화를 input으로 받음
• Rule Agent들도 같은 대화를 input으로 받음
• Rule Agent들은 “이 상황에서 어떤 지침을 어떻게 따라야 하는지”를 생각함
• 각 Rule Agent가 지침 기반 계획을 만듦
• 그 결과를 병렬적으로 돌리고
• 나온 값을 합성하여 하나의 실제 계획으로 정리
• 그 계획을 PMA를 통해 실행

즉, Rule Agent는

“지침을 실제 작업 계획으로 번역하는 역할”을 한다.

또한 생각한 것은 다음과 같다.

• Main이 따라야 하는 지침을 에이전트들에게 분할/위임
• 새 지침이 생기면 그 지침 담당 Agent를 새로 생성
• 지침의 Max Line을 정해두고
• 예를 들어 5줄 이상이면 새 지침 Agent로 분리
• 병렬적으로 돌려서 한 번에 처리

이렇게 해야 Main이 과부하되지 않는다.

7. 추가적으로 필요하다고 느낀 Agent

이것들만으로는 부족하다고 느꼈다.

지침과 규칙을 따라 계획을 만들더라도,

그 계획들을 병합하고 다듬어서 실제 실행 가능한 하나의 계획으로 만드는 Agent가 하나 더 필요할 것 같다.

즉,

• Rule Agent들이 각자 계획을 만듦
• 그 계획을 병합
• 충돌을 정리
• 우선순위를 조정
• 실제 실행 가능한 형태로 정리

이 역할을 하는 Agent가 필요하다.

8. 가장 중요한 기준: 작업 퀄리티

가장 중요한 것은 작업의 퀄리티다.

• 오류가 없어야 함
• 문제가 없어야 함
• 매우 높은 수준의 작업 퀄리티가 나와야 함
• 내가 넣은 지침을 무조건 따라야 함
• 항상 따라야 하는 규칙, 즉 “헌법”이 있음
• 리서칭, 비판, 검증, 토론 같은 행위도 수행해야 함

문제는 지금 Main에게 준 헌법이 너무 커져서,

• 맥락을 잘 못 읽고
• 의도도 잘 파악하지 못하고
• 목적도 잃어버리고
• 전체적으로 멍청해지는 문제가 있다는 것

따라서 헌법과 규칙은 Main이 전부 직접 들고 있는 게 아니라,

전담 에이전트들이 나눠서 관리해야 한다고 보고 있다.

9. 문서화에 대한 생각

시스템 전체를 한 번 싹 다 문서화해서

AI가 이해하기 좋게 만들어야 한다고 생각한다.

그리고 모든 작업에 대해 다음이 계속 기록되어야 한다.

• 어떤 것에 대해
• 무슨 원인으로
• 무슨 의도를 가지고
• 어떤 작업을 했는지
• 어떻게 작업했는지
• 결과가 무엇인지
• 그 결과가 어떤 영향을 주는지

즉, 작업 그 자체뿐 아니라 작업의 맥락과 이유와 영향까지 문서화해야 한다.

이를 위해 다음 역할이 필요하다고 본다.

문서 전담 Agent

• 작업 내용을 계속 문서화
• 기록의 누락 방지
• 나중에 추적 가능하게 정리

도서관장 Agent

• 시스템 문서를 전담해서 파악
• 시스템에 대해 잘 아는 지식 관리자
• 필요할 때 다른 Agent들이 자문 가능
• 작업 중 필요한 정보를 구조적으로 제공

즉, 단순 저장이 아니라

이해되고 활용 가능한 지식 체계가 필요하다.

10. AI 사고의 한계에 대한 생각

AI는 기본적으로 어떤 주제에 대해서

그 주제와 직접적으로 연관된 것들에 대해서만 사고하는 경향이 있다.

문제는 다음과 같다.

• 간접적으로 연관된 것
• 다른 영역에서 활용 가능한 것
• 멀리 있는 개념 간 연결
• 구조적 유사성
• 전이 가능한 아이디어

이런 것들을 잘 연결해서 사고하지 못하는 경우가 많다.

이걸 해결하는 방법을 알아내야 한다고 생각한다.

다만 현실적으로 모든 것에 대해 다 엮어서 사고하는 것은 불가능하다.

즉,

AI가 어디까지 직접 연관 중심으로 사고하고, 어디서부터 연결 확장을 도와줘야 하는지를 설계해야 한다고 본다.

11. 설계할 때 봐야 할 측면들

측면 1. Agentic 설계 / Non-Agentic 설계

Agentic으로 “무조건 해야 하는 일”을 맡긴다고 해서

그것이 항상 강제성을 가진다고 볼 수는 없다.

따라서,

• Agentic으로 맡길 것
• Non-Agentic으로 코드단에서 강제할 것

이 둘을 나누는 설계가 중요하다.

예를 들어,

• Code 단에서 그럴 수밖에 없도록 설계하는 것 = Non-Agentic
• 프롬프트에 명시적으로 적어 그렇게 행동하게 하는 것 = Agentic

이 구분을 잘 해야 한다.

측면 2. 강하게 비판적으로 보고 공격하기

설계를 다른 AI에게 넣어서 피드백을 받고,

강하게 비판적으로 보고 공격하게 하는 것이 필요하다.

측면 2-2. 비판에 대한 방어, 방어에 대한 공격

토론 구조로 돌려서,

• 비판
• 방어
• 그 방어에 대한 재공격

이런 식으로 구조적으로 설계를 단련할 필요가 있다.

측면 3. 실제 작업 가능한 수준으로 구체화

개별 구조들이 실제로 작동할 수 있을 정도로

구조와 원리를 구체화해야 한다.

이를 위해서는,

• 섹션을 나누어서 브랜치하고
• 개별 구조를 따로 설계하고
• 그 구조들을 다시 연결하고 엮는 작업이 중요하다

측면 4. 추가적으로 필요한 것들 찾기

계속해서 피드백을 받아서,

• 더 필요한 것
• 추가하면 좋은 것
• 반드시 추가해야 하는 것

을 찾아내는 구조가 필요하다.

측면 5. 블라인드 스팟 찾기

놓친 부분, 가려진 Blind Spot을 계속 찾아내야 한다.

이 역시 피드백 구조로 활용해야 한다.

측면 6. 실제 설계

계속해서 피드백을 받는 오케스트레이터처럼

전체 설계를 운영하고 개선해야 한다.

12. ChatGPT 5.4 Pro와 OpenClaw를 쓰는 현재 방식에 대한 생각

지금은 Web LLM Services에서 이런 방식으로 ChatGPT 5.4 Pro를 이용해 설계를 다듬고,

실제 구현은 OpenClaw 시스템으로 돌아가게 하는 느낌이다.

사실 이런 것을 자동으로 돌릴 수 있어서 OpenClaw가 좋은데,

ChatGPT 5.4 Pro는 비용이 매우 비싸다.

그래서 현재 감각은 다음과 같다.

• 웹에서 사고와 설계를 발전시킴
• 실제 구현은 OpenClaw에서 돌아가게 함
• 비용 문제를 고려해야 함
• 추가적으로 봐야 할 설계 측면도 계속 더해야 함
• 만약 가능하다면, AI Agent가 브라우징을 통해 - Web LLM을 활용할 수 있어 이러한 워크플로우를 AI Agent가 처리하고, 자동화하게 하면 좋음.

13. OpenClaw 시스템에서 실제 구현을 위해 내리고 싶은 명령의 핵심

내가 원하는 구조는 다음과 같다.

Main Agent

• 나와 직접 대화하는 Agent
• PMA를 생성할 수 있음

PMA (Project Manager Agent)

• 작업/프로젝트 총괄 관리
• Worker Agent 생성
• 작업 분할
• 분업화
• 꼼꼼하고 완벽하게 작업이 되도록 관리

Worker Agent

• 실제 작업 수행
• 설계안과 명령을 보고 나눠진 작업 수행

문서화 구조

• 작업 내용을 계속 문서화
• 그 문서를 읽고 활용 가능해야 함

오류/문제 처리

• PMA가 Worker의 오류나 문제를 인지
• 재시도해야 하는 경우 재시도
• 문제 해결이 필요한 경우 해결 후 재시도

감시 및 알림

• Main Agent는 PMA에 문제가 생기는 것을 알아야 함
• 또는 Non-Agentic 코드단의 감시 구조가 있어야 함
• 그 감시 결과를 Main Agent나 사용자에게 알려야 함

목표

• 항상 정확하고 완벽한 작업
• 꼼꼼하고 세심한 작업
• 최대한 높은 퀄리티
• 속도보다 품질 우선

14. 비 Agent LLM과의 상호작용 필요성

계속해서 OpenClaw 기반의 AI Agentic System을 구성하며 느낀 것은,

AI Agentic System을 잘 구성하기 위해서는 오히려 비 Agent LLM과의 많은 상호작용도 필요하다는 것이다.

하지만 이 과정에서 내용이 방대해진다.

그래서 이것을 어떻게 관리할지에 대해서도 생각해야 한다.

즉,

• Agentic 설계를 발전시키기 위해
• 비 Agent 방식의 사고/검토/비판도 많이 필요함
• 그러나 그 결과 내용이 커짐
• 따라서 내용 관리 체계가 필요함

15. 지식 관리 체계의 필요성

NotebookLM 같은 것이든,

어떤 형태로든 지식 체계를 만들어야 한다고 생각하고 있다.

내가 생각하는 이상적인 흐름은 다음과 같다.

• A
• A 비판
• A 업그레이드
• A 업그레이드에 대한 비판
• Blind Spot 밝혀내기
• 다시 업그레이드
• ...
• 최종안

문제는 LLM이 이런 식으로 쌓인 데이터 중 일부만 생각하거나,

전체를 다 고려하지 못할 수 있다는 점이다.

그래서 필요하다고 생각하는 것은 다음과 같다.

• 방대한 내용을 관리하는 지식 관리 체계
• 이전 데이터들을 계속 읽으며 빠짐없이 활용하는 구조
• 내부에서 지식의 구조를 만드는 작업
• 단계적으로 구성해나가는 체계
• 쌓인 것을 그냥 저장하는 게 아니라 실제로 활용하게 하는 구조

즉, 지식 영속성과 지속적 개선은

단순 저장이 아니라 지속적 활용 구조까지 포함해야 한다.

쌓여서 활용되지 않는 지식은

그저 쓸모 없이 용량만 차지하는 데이터일 뿐이라고 생각한다.

16. 현재 작업 중인 방향

현재 작업 중인 방향은 다음과 같다.

• 증거 기반으로 답변을 검증하는 시스템
• 감사·리뷰·릴리스 통제를 갖춘 control plane
• “더 많은 일을 하는 에이전트”가 아니라
• “틀린 답변을 눈에 띄게 줄이고, 문제 생기면 추적·차단·롤백할 수 있는 답변 시스템”
• 근거 없는 답변, 오래된 답변, 서로 모순되는 답변을 줄이는 것
• 실제 체감 품질을 높이는 것
• 실수와 그 근거를 구조화해서 기록하는 것
• 검증·리뷰·리플레이·릴리스 게이트를 통해 재발을 줄이는 운영형 시스템
• 체크포인트 + 장기 기억 저장소 + 백그라운드 반성/요약/정리 루프가 있는 시스템

즉, 목표는 단순히 “똑똑한 AI”가 아니라,

품질을 운영적으로 통제할 수 있는 시스템을 만드는 것이다.