Agentic Shaping — Agent가 먼저 발견하고 내 방식으로 진화하는 작업법

AI와 같이 만들다 보면 결과는 놀랄 만큼 빨리 나옵니다.

그런데 저는 자꾸 같은 설명을 하고 있었습니다. 문체는 이쪽이 좋고, 완료됐다는 말보다 실제 화면을 봐야 하고, 지난번에 실패한 조건은 다음에는 더 일찍 잡아야 한다고요.

처음에는 이것을 Vibe Compiler라고 불렀습니다. 비정형 판단을 스키마나 검증기로 옮긴다는 뜻에는 맞았지만, 이름만 들으면 정말 컴파일러 기법 같았습니다.

그래서 Vibe Tailoring도 생각했습니다. 제 방식에 맞춰진다는 목적은 잘 보였지만, 이번에는 Agent가 너무 수동적으로 느껴졌습니다.

제가 원한 건 맞춤 서비스가 아니었습니다.

Agent가 기다리지 않고 먼저 발견하고, 다음 작업의 방식까지 스스로 바꾸는 것.

그래서 이 작업법을 **Agentic Shaping(에이전틱 셰이핑)**이라고 부르기로 했습니다.

한 문장으로 말하면

Agentic Shaping은 AI Agent가 작업 속에 숨어 있는 암묵지·취향·교정·실패·데이터를 능동적으로 발견하고, 기억·규칙·스키마·템플릿·테스트·도구로 빚어 다음 실행 전에 먼저 적용하는 작업법입니다.

작업을 반복할수록 제가 덜 설명하고도 더 정확한 결과가 나와야 합니다. Agent의 수동 판단과 늦은 실패는 줄고, 재현 가능한 자산은 늘어야 합니다.

그렇지 않다면 진화한 것이 아니라 대화 기록만 쌓인 것입니다.

일단 이렇게 시작하면 됩니다

아래 프롬프트를 Agent의 프로젝트 지침에 넣거나, 오늘 할 일 앞에 그대로 붙여 넣습니다.

이 작업에는 Agentic Shaping을 적용해줘.

1. 시작 전에 관련된 내 과거 결정, 선호, 프로젝트 규칙을 먼저 찾아 실제 계획에 반영한다.
2. 작업 중 내가 반복해서 설명한 것, 수정한 것, 싫어한 결과, 성공 조건, 자주 생기는 실패를 조용히 포착한다.
3. 일회성 대화로 남기지 말고 적용 범위에 맞춰 다음 형태로 승격한다.
   - 취향·판단 기준 → 기억, 체크리스트, 루브릭
   - 반복 입력·데이터 → 스키마, 타입, enum, 매니페스트
   - 반복 작업 → 템플릿, 명령, 스크립트, API, 파이프라인
   - 반복 실패 → 불변식, 조기 검증기, 테스트 fixture
4. 의미·모호성·창의성은 Agent가 판단하되, 기계적으로 판정 가능한 것은 코드와 계약이 판정하게 한다.
5. 실제 파일·화면·런타임·배포 결과로 검증하고, 검증된 새 경로가 있으면 중복·임시·우회 경로를 정리한다.
6. 완료할 때 이번 결과와 함께 다음 작업을 더 빠르고 정확하게 만들 재사용 자산이 무엇인지 알려준다.

현재 요청과 권한을 넓히지는 말고, 저장할 가치가 없는 일회성 정보나 민감 정보는 남기지 마.

이후에는 평소처럼 요청하면 됩니다.

결과가 마음에 들지 않을 때는 한 번만 더 정확히 교정합니다.

“아니, 개념 설명보다 복사할 프롬프트와 시작 순서가 먼저 나와야 해.”

보통의 Agent는 현재 문장만 고칩니다. Agentic Shaping을 적용한 Agent는 여기서 한 단계 더 갑니다.

왜 이런 결과가 나왔는지 찾고, 다음 문서부터 5분 시작 → 복사 프롬프트 → 입출력 → 사례 → 개념 순서가 먼저 나오도록 규칙으로 남깁니다. 그리고 다음 작업을 시작하기 전에 그 규칙을 먼저 찾습니다.

실제 작동 순환

감지 Detect
  ↓
포착 Capture
  ↓
정형화 Structure
  ↓
적용 Apply
  ↓
실제 검증 Verify
  ↓
정리·측정 Simplify / Measure
  ↺

Agent가 맡을 부분과 시스템으로 내릴 부분은 다릅니다.

의미, 맥락, 모호성, 창의성은 계속 Agent가 맡습니다. 반면 반복 형식, 불변식, 실패 조건, 실행 순서처럼 기계가 판정할 수 있는 것은 타입, 스키마, 테스트, 검증기, 명령과 파이프라인으로 내립니다.

예를 들면 이렇습니다.

• “이 말투는 너무 보고서 같아” → 문체 기억 + 좋은/나쁜 예시 + 문서 체크리스트
• “배포 성공이 아니라 실제 URL을 봐” → 라이브 URL과 렌더링을 완료 게이트로
• “이 오류는 다음엔 더 일찍 잡아” → 입력 계약 + 조기 검증기 + 회귀 테스트
• “결론은 맞는데 판단 경로가 안 보여” → 판단 루브릭 + 근거 + 계산 fixture

기억이 이어질수록 더 잘 작동합니다

Agentic Shaping은 별도의 기억 도구 없이도 시작할 수 있습니다. 현재 대화와 프로젝트 지침 안에서 신호를 찾고 적용할 수 있기 때문입니다. 하지만 대화가 끊기면 그동안 쌓인 맥락도 함께 사라질 수 있습니다.

LLM Wiki와 함께 쓰면 더 잘 작동합니다. 교정과 취향, 판단 기준을 오래 남기고 다음 작업 전에 다시 꺼내 쓸 수 있기 때문입니다.

Slogs LLM Wiki와 함께 쓰면 한 단계 더 잘 작동합니다. 관련 기억을 작업 전에 먼저 불러오고, 사용자 교정을 의도 보정 신호로 포착하며, 전역과 프로젝트 범위를 나누어 기억을 갱신합니다. 그래서 Agentic Shaping이 더 빠르고 안정적으로 사용자 방식에 맞춰집니다.

기억은 모으는 데서 끝나지 않습니다. 다음 작업 전에 찾아 실제 계획과 결과에 적용할 때 비로소 힘을 발휘합니다.

Slogs LLM Wiki 시작하기

그래서 정말 발동하는지 검증해봤습니다

여기까지 써놓고도 찜찜했습니다.

프롬프트에 ‘능동적으로 감지하라’고 적혀 있다고 Agent가 정말 그렇게 움직였다고 말할 수 있을까요? 문구 검색만으로는 안 된다고 봤습니다.

그래서 같은 과제를 두 벌로 만들었습니다. 한쪽은 평범한 요청만, 다른 쪽은 위의 공개 프롬프트를 함께 넣었습니다. 사용자 설정과 기존 기억은 끄고, 서로 다른 임시 작업공간에서 독립 실행했습니다.

먼저 문서 교정, 버전 드리프트, 분석 재현성, 권위 문서, 민감한 일회성 정보라는 다섯 상황에서 기대 행동과 금지 행동을 미리 고정했습니다.

• 기본군: 기대 행동 85%
• Agentic Shaping 적용군: 기대 행동 100%
• 적용군의 금지 행동: 0건

말로 올바른 행동을 고르는 것만으로는 부족해서, 깨진 버전 선택 미니 저장소도 실제로 고치게 했습니다. 세 실행기가 모두 맞는 런타임을 고르는지, 없는 버전은 시작 전에 실패하는지, 하드코딩이 사라졌는지, 회귀 테스트가 실행되는지를 별도 명령으로 채점했습니다.

• 기본군: 6개 검사 중 5개, 83%
• Agentic Shaping 적용군: 6개 검사 중 6개, 100%

첫 실행은 두 군 모두 17%였습니다. 알고 보니 실행 환경이 쓰기 요청을 읽기 전용으로 낮춰 Agent가 파일을 한 줄도 고치지 못했고, 채점기에도 두 가지 결함이 있었습니다. 이것을 프롬프트 실패라고 우기지 않고 환경 실패로 분리했습니다. 채점기를 고치고 폐기 가능한 격리 저장소에서 다시 돌린 결과가 위 수치입니다.

이 결과는 ‘모든 모델에서 무조건 작동한다’는 증명이 아닙니다. 적어도 이번 Codex 환경에서는 공개 프롬프트가 누락되던 행동을 실제로 보강했고, 파일 결과까지 통과했다는 재현 가능한 증거입니다. 그래서 평가 사례, JSON Schema, fixture, 실행기, 원본 결과를 모두 공개 저장소에 남겼습니다.

앞으로 프롬프트를 바꿀 때는 설명을 더 그럴싸하게 고치는 것으로 끝내지 않습니다. 같은 평가 게이트를 다시 통과해야 합니다.

검증 자산과 직접 실행 방법은 Agentic Shaping 공식 가이드에 공개했습니다.

Compound Engineering과는 무엇이 다른가

Compound Engineering의 “한 작업이 다음 작업을 더 쉽게 만든다”는 실행 구조는 좋은 참고가 됐습니다. 특히 계획, 작업, 검토, 축적을 명령과 파일로 보이게 만든 점이 실용적이었습니다.

하지만 제가 시작한 문제는 코드베이스의 생산성보다 사람과 Agent 사이의 암묵지가 계속 사라지는 것이었습니다.

Agentic Shaping은 코딩뿐 아니라 문서, 분석, 이미지, 영상, 배포에서 생기는 제 교정을 Agent가 먼저 발견하고, 다시 쓸 수 있는 구조로 만들고, 다음 실행 자체를 바꾸는 데 중심을 둡니다.

좋은 결과 하나보다, 다음 결과를 만드는 Agent와 시스템이 함께 달라지는 것.

그게 제가 원한 방향입니다.

복사 가능한 상황별 프롬프트와 구조도는 Agentic Shaping 실전 가이드에 정리했습니다.

공식 페이지의 배포 구조

공개 가이드는 GitHub Pages가 계속 빌드·배포합니다. 다만 공식 주소의 DNS는 Slogs 서버를 향하고, Caddy가 agentic-shaping.slogs.dev의 HTTPS 인증서를 직접 관리한 뒤 GitHub Pages 원본으로 요청을 전달합니다.