에이전틱 워크플로우의 멘탈 프레임워크 — AI에게 일을 맡기는 사고 체계

AI 에이전트에게 일을 맡겨도 결과가 기대에 못 미친다면, 모델 탓이 아니라 위임 방식의 문제일 가능성이 높다.

에이전틱 워크플로우를 잘 쓰려면 "명령을 내리는 감각"이 바뀌어야 한다. 이 글은 AI에게 작업을 분해하고 위임하는 5단계 멘탈 프레임워크를 정리한다.

왜 멘탈 프레임워크가 필요한가

사람 주니어에게 일을 시킬 때와 AI 에이전트에게 일을 시킬 때의 차이를 생각해보자.

이 차이 때문에 사람에게 쓰는 지시 방식 그대로 AI에게 쓰면 품질이 낮아진다. 에이전트용 사고 체계가 따로 필요하다.

5단계 프레임워크

1. Outcome — 결과 정의

가장 먼저 "끝난 상태가 어떤 모습인지" 정의한다. 행동이 아니라 결과물이다.

❌ "코드를 리팩토링해줘"
✅ "UserService 파일이 200줄 이내로 줄고,
    테스트가 모두 통과하며,
    public API는 변경되지 않은 상태"

비유하면 여행사에 "파리로 보내줘"가 아니라 **"에펠탑 앞에서 4월 첫 주말에 사진 찍을 수 있게 해줘"**라고 요청하는 것과 같다.

2. Context — 필요한 맥락 제공

에이전트가 모르면 안 되는 배경 정보를 모두 넣어준다. 관련 파일 경로, 비즈니스 규칙, 과거 결정.

- 현재 코드: src/services/user.ts (500줄)
- 사용처: 8개 API 엔드포인트
- 지난달 이 파일에서 발생한 장애: 동시성 이슈
- 팀 원칙: Repository 패턴 사용

3. Constraints — 제약 조건 명시

무엇을 하지 말아야 하는지를 명시한다. 금지 사항이 명확할수록 엉뚱한 결과물이 줄어든다.

- 의존성 추가 금지
- public API 시그니처 변경 금지
- 데이터베이스 스키마 건드리지 말 것
- Node 16 호환성 유지

[💡 잠깐! 이 용어는?] 제약 기반 프롬프팅: 할 일보다 "하지 말 일"을 명시해서 에이전트 행동을 좁히는 기법. 탐색 공간을 줄여 품질을 높인다.

4. Verification — 검증 방법 설계

에이전트 산출물이 맞는지 어떻게 확인할지를 미리 정한다. 사람 눈 검토에 의존하지 말고 자동화 가능한 기준을 만든다.

- npm run test 통과
- npm run lint 에러 0
- bundle 크기 10% 이내 증가
- 기존 API 호환성 테스트 통과

검증 기준이 없으면 에이전트는 **"그럴듯한 코드"**를 내놓고 멈춘다. 기준이 있으면 스스로 반복해서 수렴한다.

5. Escape Hatch — 중단 조건

에이전트가 언제 멈추고 사람에게 물어야 하는지를 명시한다. 이게 없으면 잘못된 가정으로 멀리 가버린다.

- 파일을 5개 이상 수정해야 하면 계획 먼저 제시
- 의존성 변경이 필요하면 중단하고 확인 요청
- 테스트가 2회 연속 실패하면 진단 결과 보고 후 대기

비유하면 택시 기사에게 **"목적지까지 가되, 경로가 막히면 우회보다 나에게 물어봐"**라고 말해두는 것과 같다.

전체 프레임워크 적용 예

앞의 5단계를 하나로 묶은 프롬프트가 어떻게 생겼는지 보자.

## Outcome
UserService가 Repository 패턴으로 분리되고, 모든 테스트 통과
 
## Context
- 현재: src/services/user.ts (500줄)
- 8개 API가 의존
- 팀 컨벤션: src/repositories/ 디렉토리에 리포 배치
 
## Constraints
- public API 시그니처 불변
- 의존성 신규 추가 금지
- DB 스키마 불변
 
## Verification
- npm test 통과
- lint 에러 0
- ESLint complexity 룰 통과
 
## Escape Hatch
- 변경 파일 5개 초과 시 계획 먼저 제시
- 테스트 2회 연속 실패 시 중단하고 보고

이 구조로 프롬프트를 쓰면 같은 모델, 같은 에이전트로도 산출물 품질이 눈에 띄게 올라간다.

흔한 실수

• Outcome을 과정으로 쓴다. "리팩토링해줘"는 과정, "200줄 이하 + 테스트 통과"는 결과다.
• Context를 생략한다. AI는 당신 팀의 관례를 모른다. 명시하지 않으면 평균적인 선택을 한다.
• Verification이 모호하다. "잘 돌아가면 된다"는 검증 기준이 아니다.
• Escape Hatch가 없다. 에이전트는 막혀도 물어보지 않는다. 기본값은 **"끝까지 시도"**다.

정리

• 에이전트 위임은 사람 위임과 사고 체계가 다르다
• Outcome → Context → Constraints → Verification → Escape Hatch 5단계로 구조화한다
• 금지 사항과 중단 조건이 명확할수록 품질이 올라간다
• 검증은 자동화 가능한 기준으로 설계한다

도구가 좋아지는 속도보다 사람이 도구를 잘 쓰는 속도가 더 중요해진다. 프레임워크는 그 격차를 좁히는 지렛대다.

참고:

• Dev.to: https://dev.to/somedood/mental-framework-agentic-workflows