Zenn에서는 '다시 생각하는, AI 엔지니어링의 현재'라는 주제가 일일 트렌드 상위권에 올랐고, Qiita에서도 최근 2주 동안 AI 태그 및 Security 태그 글이 각각 스톡 20 이상의 반응을 모으고 있습니다. AI 에이전트에게 무엇을 어디까지 맡길지, 그 경계선을 어떻게 설계하는지가 2026년 10월 시점의 엔지니어 커뮤니티에서 다시 논의의 중심이 되고 있다는 실감이 있습니다.
필자는 CLI를 통해 구동되는 Claude Code를 '실행 역할'로, 그 위에 자신이 구축한 사고/기억/지시 레이어(본 기사에서는 편의상 'OpenClaw'라고 부르는 개인 AI 경영 OS)를 '판단 역할'로 분리하여 운영하고 있습니다. 이는 OpenAI나 Anthropic이 제공하는 기성품이 아니라, CLAUDE.md
・memory/
디렉토리 및 정책 파일군을 직접 쌓아 올린 구성입니다. 이번에는 이 연동의 구체적인 유스케이스와 실제로 겪었던 난관(지뢰)을 포함하여 공유하겠습니다.
'AI에게 코드를 작성하게 한다'는 글은 넘쳐나지만, 'AI에게 무엇을 기억시키고, 무엇을 판단하게 하며, 무엇만 실행하게 할지'를 설계한 글은 의외로 적습니다. 이 글이 바로 그 설계 메모입니다.
필자의 구성은 단순한 삼층 구조입니다.
| 레이어 | 담당 | 내용 |
|---|
| 사고/기억/지시 (OpenClaw) | 판단 | memory/ 하위의 user/feedback/project/reference 4종 메모리, ~/.claude/policies/의 방침 파일 |
| 하네스 (경계/문) | 통제 | ~/openclaw-gates/, check 명령어, cron의 안전 수칙 |
| 실행 (Claude Code) | 작업 | 코드 생성・파일 편집・명령어 실행・subagent 호출 |
중요한 것은, 실행 역할(Claude Code)에게 판단을 너무 많이 맡기지 않는다는 설계 사상입니다. 실제 운영 DB나 결제 관련 API, 외부 전송의 입구는 애초에 작업 역할이 도달할 수 없는 구조로 만들어 둡니다. '울타리(hook이나 lint)는 새어 나올 것을 전제로' 삼고, 정말 효과적인 것은 구조적으로 손댈 수 없게 만드는 것이라고 받아들이고 있습니다.
가장 효과를 체감하고 있는 부분은 수정과 확인을 '메모리'로 유형별로 기록하는 시스템입니다. 4가지로 나누었습니다.
user: 사용자의 역할・선행 지식 (예: Go는 10년 작성했지만 React는 처음, 등) -
feedback: '다음부터 이렇게 해 달라'는 지적, 또는 '그 판단으로 맞았다'는 확인. 둘 다 기록 -
project: 현재 진행 중인 프로젝트의 배경 (마감일・제약・누가 무엇을 언제까지) -
reference: 외부 시스템에 대한 포인터 (Linear의 프로젝트명, Slack 채널 등)
실제로 축적된 feedback 메모리의 예시를 들겠습니다. 포켓몬 카드 Kaggle 시뮬레이션 부문에서 4,549위/6,807팀이라는 결과로 끝났을 때의 회고입니다.
근거: 포케카Kaggle Simulation 부문 4,549위/6,807팀.
선별 메커니즘은 상위와 같은 구조였는데, 후보를 직접 만들었기 때문에 졌습니다.
상위권은 다른 팀의 일류 실데이터(상위 팀의 기보 9만~69만 판단)를 교사로 삼았습니다.
...
이것은 단순한 패인 분석으로 끝나지 않고, '후보 데이터는 반드시 외부의 일류 실데이터에서 가져온다'라는 영구 규칙으로 CLAUDE.md에 승격시켰습니다. 이후 기획서나 콘텐츠 생성 어떤 프로젝트에서도 이 규칙이 매번 판단 기준으로 작용합니다. 실패를 한 번 기록하면, 다음 세션의 AI가 같은 함정에 빠지지 않게 하는 것—이것이 메모리 레이어의 가장 큰 가치입니다.
무인 cron 실행에서는, 실행 역할에게 맡겨두면 사고가 발생합니다. 실제로 일어난 인시던트를 기반으로 5가지 원칙으로 지침을 희미하게 유지하고 있습니다.
경계를 먼저 그린다: 실제 운영 DB・결제・외부 전송・비밀 값은 작업 역할이 도달할 수 없는 구조로 한다 -
지침은 희미하게: 1줄=매번의 월세. 실제 실패했거나 규정에 대응하는 줄만 남긴다 -
문은 1 명령어: make check
(lint → 타입 → 빌드 → 테스트 → verify_claims)를 통과하는 것 외에는 '완료'라고 부르지 않는다 -
루프를 닫는다: 같은 절차를 3번 반복하면 Skill화, 같은 관점을 3번 확인하면 Subagent화 -
정리한다: ~/.claude/tools/harness_audit.sh
로 공장별로 git 상태・check 통과・테스트・중지 파일・전송 입구・.env 권한을 주기적으로 점검합니다.
실제로 harness_audit.sh
를 실행하면 이런 출력이 나옵니다 (이미지).
$ ~/.claude/tools/harness_audit.sh
[factory] content-automation
git: clean
...
'완료(完了)'의 정의를 자연어 보고문이 아니라, check 명령어 통과와 1차 데이터 유무로 판정합니다. 이를 통해 Claude Code가 '되었습니다'라고 해도 그것을 맹신하지 않는 운영 방식이 됩니다.
실제 서비스 환경에서 연구/학습 관련 무거운 처리를 돌리면, 실제 크론(cron) 작업을 지연시킵니다. 실제로 2026년 9월 29일 23시 14분, LeRobot의 시험적인 학습 처리가 멈추면서 10시간 동안 CPU 사용률 약 890%를 계속 사용했고, 부하 27~39 상태가 지속되면서 아침 정규 처리가 무려 571번이나 부하 대기(負荷待ち)되는 사고가 발생했습니다.
이에 따라 연구/실험 관련 작업은 반드시 전용 래퍼(wrapper)를 거치도록 규칙을 만들었습니다.
# 우선순위 최저(taskpolicy -b + nice 19)・병렬 수 고정 2・실행 시간 고정 2시간으로 실행
~/bin/research-run -t 3600 -j 2 -- python train_experiment.py
타임아웃, 병렬 수, 우선순위를 래퍼 측에서 강제함으로써 '일단 실행해 보자'가 그대로 본 서비스에 영향을 미치는 사고를 막고 있습니다. 실행 로그는 ~/tasks/research-run.log에 남기 때문에 나중에 '언제 무엇을 몇 분 동안 돌렸는지'를 정리할 수 있습니다.
마찬가지로 비용 사고의 교훈으로, Vercel에서는 아무도 사용하지 않는 시제품 사이트가 AI 크롤러에 하루 250만 번씩 접속당해 약 120만 엔이 청구된 사례가 있어, 이후 Vercel 신규 이용을 금지하고 배포처를 Cloudflare Pages/Workers로 통일했습니다. Supabase도 '이전했다'는 것이 과금 중단 증거가 되지 않아, 프로젝트 삭제와 청구 명세서의 행이 사라진 것을 완료의 정의로 삼고 있습니다 (과거에 11개 프로젝트가 남아 계속 약 2만 엔의 불필요한 청구가 발생했던 경험을 바탕으로).
SNS 게시물 자동화에서도 동일 계정으로 15분 간격 15건 연속 게시하여 Meta의 shadow ban을 받은 실제 사례(2026년 4월 30일)가 있어, 이후 '동일 계정에 연속 게시 시 최소 15분 간격'을 하네스 측의 강제 규칙으로 삼고 있습니다.
이러한 구성을 통해 얻은 가장 큰 깨달음은, 'AI 에이전트의 보고는 신뢰하지 않고, 로그와 1차 데이터로 판단한다'라는 원칙이 그대로 운영 비용 절감으로 이어진다는 것입니다.
- 실행 로그(
research-run.log)가 있으니 '언제 무엇이 폭주했는지' 나중에 추적할 수 있고 - check 명령어(문)가 있으니 '완료했습니다'를 맹신하지 않아도 되고 - 메모리(feedback형)가 있으니 같은 실수를 두 번 반복하지 않습니다.
- 정리 스크립트가 있으니 '울타리가 무너지지 않았는지' 주기적으로 확인할 수 있습니다.
이 모든 것이 단독으로는 사소한 메커니즘이지만, 조합함으로써 '사람 없이 돌려도 크게 벗어나지 않는' 상태에 가까워집니다. 반대로 말하면, 이러한 메커니즘을 넣기 전에는 Vercel 과금 사고, Meta shadow ban, LeRobot 멈춤 등 실제로 손실을 동반하는 인시던트가 발생하고 있었습니다. 하네스 설계는 정신론이 아니라, 실제로 일어난 사고의 재발 방지책을 쌓아 올린 것입니다.
여기까지의 이야기는 사내 AI 활용 기반에 대한 이야기지만, 프리랜서 엔지니어로서 여러 프로젝트를 병행하는 사람에게도 응용할 수 있는 생각이 있습니다.
SES(System Engineering Service) 엔지니어의 실태로 볼 때, 상주처마다 사용할 수 있는 툴이나 규칙이 달라서 주관적인 판단에 의존하기 쉬운 경우가 많습니다. SES 계약 시 주의점으로 자주 언급되는 것이 결과물 책임 범위나 지휘 명령 체계의 모호함이지만, 이는 '누가 판단하고 누가 실행할지'를 명문화하지 않은 데서 기인하는 경우가 많습니다. 자신의 작업 규칙을 '방침(方針)'과 '실행 로그'로 나누어 기록해 두는 것만으로도 계약상의 트러블이나 인식 차이를 줄일 수 있습니다.
프리랜서 엔지니어 가이드로 자주 소개되는 내용은 계약 형태나 단가 협상에 집중되어 있지만, 실무적인 면에서는 '자신의 판단 기준을 어떻게 외부화하고 재사용 가능하게 만드느냐'도 사소하지만 중요한 논점입니다. 프리랜서 가이드 전반에 공통되는 것은 주관적인 감(勘)에 의존하지 않고, 과거의 실패와 성공을 메모로 남겨 다음 프로젝트에 인계한다는 발상이며, 이는 AI 에이전트의 메모리 설계와 완전히 같은 구조를 가지고 있습니다.
프리랜서 엔지니어로서 여러 클라이언트의 작업을 수행할 경우에도, 건별 제약(project형), 클라이언트 피드백(feedback형), 클라이언트 배경 지식(user형)을 나누어 기록해 두면 다음번 제안이나 견적의 정확도가 높아진다. AI 에이전트 운영을 위해 만든 틀이 그대로 자신만의 지식 관리(knowledge management)에도 전용될 수 있다는 것은, 이 구성을 만들어보면서 얻게 된 부산물이었다.
| 체크 항목 | 확인 내용 | 미대응 시 리스크 |
|---|
| 송신・공개 진입점은 1개인가 | 복수 경로에서 외부 전송이 가능한가 | 무승인 게시・오전송 |
| ... | make check 등의 유무 | 검증되지 않은 '완료'를 신뢰해 버림 |
| 무거운 처리의 격리 Wrapper가 있는가 | 타임아웃・병렬 수・우선도의 강제 | 실제 운영 cron의 막힘・부하 사고 |
| 연속 실행 간격 제한이 있는가 | SNS 게시・API 호출 등 | shadow ban・계정 동결 |
| 실패・성공을 메모리화하는 메커니즘이 있는가 | feedback/project/user/reference 등의 틀 | 같은 실패의 반복 |
| 정기 정리 스크립트가 있는가 | git 상태・check 결과・중지 파일・권한 | 울타리의 형식화에 알아차리지 못함 |
이 표는 그대로 자신의 운영 환경 셀프 체크에 활용할 수 있도록 구성해 두었다. 위에서부터 순서대로 채워져 있지 않은 항목이 있다면, 그곳이 다음에 손을 대야 할 곳이다.
OpenClaw(사고・기억・지시)와 Claude Code(실행)의 연계는 'AI에게 무엇이든 맡기는 것'이 아니라, '무엇을 맡기고 무엇을 맡기지 않을지'를 명문화하는 작업이었다. 실제로 발생했던 비용 사고・정지 사고를 교훈 삼아, 경계・얇은 지침・1 명령어의 문・닫힌 루프라는 4가지 원칙에 녹여냄으로써, 무인 운영에서도 크게 벗어나지 않는 상태에 가까워지고 있다.
이 생각 방식은 AI 에이전트 운영에 국한되지 않고, 프리랜서 엔지니어나 SES 엔지니어가 자신의 업무 진행 방식을 시스템화할 때도 그대로 사용할 수 있다. 판단의 기록을 남기고, 완료의 정의를 명확히 하며, 위험한 조작의 진입점을 좁힌다—사소하지만, 사고를 막는 것은 언제나 이런 종류의 메커니즘이다.
- 월 매출 250만인 3인 회사가 AI 경영 OS를 만든 이야기 CFO도 COO도 AI 에이전트
- 【2026년 최신】AI 코딩 툴 5가지 비교 | 결국 어떤 것을 사용해야 할지 철저히 검증
- OpenClaw로 9개의 AI 에이전트 경영 OS를 구축한 실천 기록 | 설정과 SES 시장 분석 활용법
AI 구동塾 — AI를 사용해 스모비지(Smobiz)를 만드는 법을 배웁니다
Claude Code, OpenClaw, AI 경영 OS의 실전 노하우를 매주 공개 중입니다.
월액 ¥4,980으로 과거 기사 전체 무제한 열람 가능.
작성자: 합동회사 Radineer (프리랜서 대상 프로젝트 사이트 FreelanceDB 운영)
