AI 에이전트를 실무에서 적극적으로 활용하다 보면 어떤 벽에 부딪히게 된다. 하나의 AI에게 '생각하는 것'과 '손을 움직이는 것'을 모두 맡기면, 둘 다 어중간해진다는 벽이다.

장기 기억이나 의사결정의 문맥(Context)을 유지하며 경영 판단적인 지시를 내리는 층(OpenClaw)과, 그 지시를 받아 파일을 편집하고, 커맨드를 실행하며, 테스트를 돌리고, 배포(Deploy)까지 가져가는 층(Claude Code) —— 이 두 층으로 역할을 분리하면, AI 활용은 갑자기 '실무에서 돌아가는 것'으로 변한다.

본 기사에서는 필자가 실제로 운용하고 있는 「OpenClaw(사고·기억·지시) × Claude Code(개발·실행)」의 연계 패턴을 구체적인 커맨드와 함께 소개한다. 2026년 8월 현재, 여러 프로덕트를 1인~소수 인원으로 운영하는 개인 개발자·프리랜서 엔지니어에게 이 구성은 현실적인 선택지가 되어가고 있다.

먼저 전제를 정리한다.

포인트는 OpenClaw 측은 '무엇을 해야 하는가'를 판단하고, Claude Code 측은 '어떻게 하는가'를 묵묵히 실행한다는 비대칭적인 관계에 있다는 점이다. 경영 판단과 코드 구현을 동일한 컨텍스트(Context) 내에서 혼재시키면 둘 다 정밀도가 떨어진다. 분리함으로써 각각이 잘하는 입도의 사고에 전념할 수 있다.

필자의 환경에서는 OpenClaw 측을 「CEO/CFO/CTO/COO/CMO」라는 경영 페르소나로 분할하여, 각각이 담당 영역의 데이터 소스와 접속되어 있다.

/ceo → CFO/CTO/COO/CMO의 보고를 통합하여 경영 대시보드 생성
/cfo → freee 연동으로 재무 데이터 취득·PL 생성·분개 계상·미결제 관리
/cto → 프로덕트 군의 헬스 체크(Health Check), 기술 스택 관리, 개발 우선순위 제안
...

실제 커맨드 예시를 든다.

# 기술적인 건전성 체크를 매일 아침 정례화
/cto health
# 재무의 미결제 항목을 확인한다
...

이것들은 단순한 리포트 생성이 아니다. CTO 페르소나가 "이 프로덕트는 기술 부채가 임계치를 넘었다"라고 판단하면, 그 지시가 Claude Code 측의 실행 태스크로 변환되는 흐름으로 되어 있다. 즉, OpenClaw는 "알아차리고 우선순위를 정하는" 층이며, 실제로 손을 움직이는 것은 어디까지나 Claude Code다.

가장 효과를 실감하고 있는 것이 코드베이스의 감사(Audit)부터 구현, 배포까지 일괄적으로 잇는 파이프라인이다.

# 1. 코드베이스 전체를 대규모 컨텍스트로 감사
/analyze
# → 아키텍처·보안·퍼포먼스 관점에서 리포트 생성
...

이 파이프라인의 핵심은 각 단계가 「독립된 컨텍스트를 가진 서브 에이전트(Sub-agent)」로서 동작한다는 점에 있다. 감사를 수행하는 에이전트는 구현의 상세 내용을 알지 못하며, 구현하는 에이전트는 경영 판단의 문맥을 갖지 않는다. 각각이 필요한 정보만을 전달받아 동작함으로써 컨텍스트의 오염을 방지하고 있다.

특히 /deploy 전단에는 검증 전용 서브 에이전트를 배치하고 있다. 커밋되지 않은 작업 내용이 섞여 들어가지 않았는지, 차이(Diff)가 의도대로인지 독립적으로 체크한 후에야 비로소 배포를 허가하는 구성이다. 이는 실제로 "커밋되지 않은 WIP(Work In Progress)를 포함한 채로 배포해 버리는" 사고를 경험한 뒤에 추가한 가드레일(Guardrail)로, AI에게 실행 권한을 넘긴다면 검증 단계를 별도의 에이전트로 분리해야 한다는 교훈을 얻었다.

OpenClaw 측의 「기억」은 단순한 로그의 축적이 아니라 종류별로 구조화되어 있다. 필자가 채택하고 있는 것은 다음 4가지 분류다.

user: 사용자의 역할·전문성·지식 수준 -
feedback: 과거의 지적·수정·"이것은 좋았다"라는 확인 -
project: 진행 중인 의사결정·마감일·배경에 있는 제약 -
reference: 외부 시스템(Linear, Slack, Grafana 등)으로의 참조처

각 메모리는 다음과 같은 형식의 파일로 저장한다.

---
name: deploy-safety-rule
description: 미커밋 WIP 혼입으로 인한 배포 사고 재발 방지 규칙
...

그리고 MEMORY.md

라는 단 하나의 파일에 인덱스(Index)로서 집약하고, 1행 150자 이내의 요약만을 상시 컨텍스트(Context)에 싣는 설계로 하고 있다. 이를 통해 기억이 늘어나도 컨텍스트 윈도우(Context Window)를 압박하지 않으며, 필요한 때에만 해당 파일을 심층적으로 탐색할 수 있다.

이 "인덱스는 가볍게, 본체는 필요 시에 로드"하는 설계는, 사고의 입도(Granularity)가 다른 OpenClaw와 Claude Code를 연결하는 데 있어 은근하게 효과를 발휘한다. 경영 판단의 페르소나(Persona)는 요약만 보고 움직이고, 실행층은 필요한 파일만 읽는(Read) 비대칭적인 액세스 패턴(Access Pattern)이 성립하기 때문이다.

솔직히 말하자면, 이 구성을 무인 cron으로 돌리기 시작했을 초기에는 몇 번인가 가슴을 쓸어내린 적이 있다.

가장 큰 교훈은 "AI에게 실행 권한을 부여하는 비용은 생각보다 비대칭적이다"라는 점이다. 문장 생성이나 분석뿐이라면 실패해도 다시 쓰면 그만이지만, 배포(Deploy)나 SNS 게시, 결제 관련 조작은 되돌릴 수 없다. 그래서 필자의 환경에서는 다음과 같은 안전 규칙을 OpenClaw 측의 상시 컨텍스트에 고정해 두고 있다.

• 유료 API 호출은 정해진 경로(Claude CLI) 이외에는 금지하며, 종량제 API의 신규 호출은 인간의 승인을 필수적으로 한다.
• SNS 게시물은 초안 작성까지만 자동화하고, 공개는 반드시 인간의 승인을 거친다.
• 동일 계정으로의 연속 게시에는 최소 간격을 강제한다 (플랫폼의 스팸 판정을 피하기 위해).
• 배포는 반드시 클린한 commit/worktree에서 수행하며, 차분 검증(Diff Verification)을 별도의 에이전트(Agent)를 통해 독립적으로 통과시킨다.

이것들은 모두 "한 번 실패한 뒤에 추가한 규칙"이며, 처음부터 완벽한 안전 설계를 준비할 수 있었던 것은 아니다. 역발상적인 결론이 되겠지만, AI 오케스트레이션(Orchestration)을 무인으로 돌릴 경우, 첫 설계에서 완벽을 기하기보다 "작게 실패하고 즉시 규칙화하는" 사이클을 돌리는 것이 실용적인 측면에서는 더 빠르다. OpenClaw의 feedback 메모리는 바로 이 사이클을 뒷받침하기 위한 메커니즘으로서 기능하고 있다.

잠시 이야기가 샐 수도 있지만, 이 연계 패턴을 구축하는 과정에서 깨달은 점이 있다. SES(System Engineering Service)나 고객사 상주를 통해 커리어를 쌓아온 엔지니어일수록, 이러한 AI 오케스트레이션 설계 기술은 향후 시장 가치와 직결되기 쉽다는 점이다.

SES 1년 차에 이직이나 커리어 방향성에 대해 고민하는 엔지니어는 많지만, 단일 언어·프레임워크의 숙련도만으로 연봉이나 SES 단가 시세가 결정되는 시대는 저물고 있다. 오히려 "여러 AI 에이전트에게 역할을 분담시켜, 감사부터 구현, 배포까지의 일련의 개발 플로우(Flow)를 설계할 수 있는가"라는, 시스템 설계에 가까운 기술이 평가받는 장면이 늘어나고 있다.

프리랜서로서 SES를 떠나는 선택을 할 경우에도, 이러한 자동화 파이프라인을 자신의 무기로 가지고 있느냐에 따라 프로젝트 단가 협상력이 달라진다. SES 단가 시세는 프로젝트나 스킬셋에 따라 폭이 크지만, AI 도구를 능숙하게 사용하여 개발 속도나 감사의 정밀도를 높일 수 있는 엔지니어는 단순한 공수(Man-month) 기반의 평가에서 벗어나기 쉽다. SES라는 방식 자체를 부정하는 것이 아니라, 그곳에서 얻을 수 있는 다양한 현장 경험과 AI 오케스트레이션 기술을 곱할 수 있느냐가 향후 연봉 범위를 좌우하는 분기점이 될 것이다.

OpenClaw와 Claude Code의 연계는 궁극적으로 "판단은 문맥을 유지하는 에이전트에게, 실행은 일회용 서브 에이전트(Sub-agent)에게"라는 역할 분담 설계로 귀결된다.

• 경영 판단의 페르소나(CEO/CFO/CTO/COO/CMO)가 우선순위를 판단하고 지시를 내린다.
• Claude Code 측의 독립된 서브 에이전트가 감사·설계·구현·검증·배포를 분담하여 실행한다.
• 기억은 타입(Type)별로 구조화하고, 인덱스는 가볍게, 본체는 필요 시에 로드하는 설계로 한다.
• 실행 권한을 가진 조작(배포, 게시, 결제)에는 반드시 검증 단계와 인간의 승인을 거친다.

완벽한 설계를 처음부터 만들려 하지 말고, 실패를 feedback 메모리로 규칙화해 나가는 사이클이야말로 무인 운용을 안정시키는 가장 빠른 길이었다. 앞으로 자신의 개발 플로우에 AI 오케스트레이션을 도입하고 싶은 엔지니어에게는, 우선 "사고"와 "실행"을 분리하는 것부터 시작할 것을 권하고 싶다.

• AI 에이전트 9대로 경영 OS를 구축한 모든 기록【OpenClaw 실전】
• Claude Code를 매일 사용하며 깨달은 실전 Tips 모음【2026년판】 SES 엔지니어의 프리랜서 전향에도 유효함
• SES 엔지니어가 프리랜서 독립 전 반드시 확인해야 할 세무·절세의 모든 지식【2026년 최신판】

AI 구동 학원 — AI를 사용한 스몰 비즈니스 만드는 법을 배우다

Claude Code, OpenClaw, AI 경영 OS의 실전 노하우를 매주 공개 중.

월간 ¥4,980으로 과거 기사 모두 무제한 열람 가능.

SES 해체신서 프리랜서 DB에서는 고단가 프로젝트를 다수 게재 중입니다.

• ✅ 마진율 공개로 투명한 거래
• ✅ AI/클라우드/Web 계열 엄선 프로젝트
• ✅ 전담 코디네이터가 단가 협상을 지원