AI 에이전트가 쓸모 있는 일을 하게 만드는 브리프 작성법: 목표, 입력, 제약, 완료 정의, 검토

브리프 없는 에이전트가 나쁜 결과를 내는 이유

에이전트는 루프입니다. 작업을 읽고, 도구를 고르고, 행동하고, 결과를 읽고, 끝났다고 판단할 때까지 반복합니다. 그 결정 하나하나가 당신이 준 텍스트를 기준으로 내려집니다. 텍스트가 "완료"의 모습을 말해 주지 않으면 에이전트가 스스로 정하는데, 그것도 일찍 정합니다. 계속하는 것보다 멈추는 것이 싸기 때문입니다. 텍스트가 건드리면 안 되는 것을 말해 주지 않으면 가장 가까운 것을 건드립니다.

2026년 중반까지 실무자들의 공감대는 여러 방향에서 같은 지점으로 모였습니다. 에이전트에서 가치를 얻는 팀은 외주 인력에게 하듯 브리프를 주고 풀 리퀘스트처럼 결과를 검토합니다. 채팅창에 한 문장을 치고 돌아온 것을 받아들이는 팀은 다시 해야 하는 그럴듯한 작업의 흐름을 받습니다. 도구는 좋아졌지만 브리프의 필요성은 사라지지 않았습니다. 오히려 커졌습니다. 에이전트가 이제 더 오래 실행되고 더 많은 것을 건드리기 때문입니다.

브리프는 프롬프트 요령이 아닙니다. 첫날 그 작업을 맡는 신입에게 써 줄 바로 그 문서이며, 에이전트에게는 사회적 맥락이 필요 없어서 짧아진 것뿐입니다.

브리프의 다섯 부분

목표: 활동이 아니라 결과를 한 문장으로

"예약 리마인더 요구사항 문서 작성"은 활동입니다. "목요일 계획 회의에서 엔지니어링이 추정할 수 있도록 예약 리마인더 요구사항을 만든다"는 독자와 기한이 있는 결과입니다. 두 번째 버전은 에이전트에게 어느 정도의 상세함이 중요한지, 누가 판단할지를 알려 줍니다.

입력: 출처를 명시하고, 무엇이 우선인지 말하기

에이전트가 써도 되는 문서, 이슈, 페이지, 데이터를 각각의 위치와 함께 나열하고, 서로 어긋날 때 어떻게 할지 적습니다. "/pages/booking-reminders의 PRD가 기준선이다. Slack 스레드는 배경 정보일 뿐이다. 충돌하면 PRD가 우선이며 충돌을 표시하라." 이것이 없으면 에이전트는 출처를 섞고 맥락을 잃습니다.

제약: 건드리지 말 것, 가정하지 말 것

세 종류가 중요합니다. 범위: "캘린더 동기화 변경을 제안하지 말 것". 사실: "고객 이름, 가격, 날짜를 지어내지 말고 '알 수 없음'이라고 쓸 것". 행동: "읽기 전용. 이슈를 만들거나 업데이트를 게시하지 말 것". 마지막 것은 에이전트에 부여하는 스코프와 직접 대응하므로, 브리프와 권한은 함께 써야 합니다.

완료 정의: 에이전트가 스스로 돌릴 수 있는 체크리스트

"좋은 문서"가 아니라 "목표, 사용자 스토리, 비목표, 미해결 질문 섹션이 있는 문서. 모든 사용자 스토리에 인수 기준이 있음. 빈 섹션 없음. 1,200단어 이하". 에이전트는 멈추기 전에 이것을 확인하고, 검토자도 같은 목록을 확인하므로 두 사람이 같은 것을 봅니다.

검토 단계: 이름이 있는 사람과 이름이 있는 산출물

"이슈가 하나라도 생성되기 전에 Moeid가 요구사항 페이지를 검토한다." 이름 대신 역할("PM")로 적힌 검토 단계는 건너뛰어집니다. 산출물 없는 검토 단계("작업을 검토한다")는 흘끗 보는 것으로 끝납니다.

복사해 쓸 수 있는 브리프 템플릿

목표: <결과, 독자, 기한>

입력:
- <출처 1, 위치, 역할: 기준선 | 배경>
- <출처 2 ...>
출처가 충돌하면: <무엇이 우선인지; 충돌을 표시>

제약:
- 범위: <제외되는 것>
- 사실: <이름, 숫자, 날짜>를 지어내지 말 것; "알 수 없음"이라고 쓸 것
- 행동: <읽기 전용 | X를 만들어도 됨 | Y는 안 됨>

완료 정의:
- [ ] <섹션 또는 산출물 1이 있음>
- [ ] <각 항목에 ...이 있음>
- [ ] <길이 또는 형식 제한>
- [ ] 미해결 질문은 나열하고, 추측으로 해결하지 않음

검토: <사람>이 <다음 행동> 전에 <산출물>을 검토한다.

200단어 이하로 유지하세요. 긴 브리프는 작업이 사실 두 개라는 신호입니다.

실제 사례: Atrix의 Develop 실행

우리 AI 에이전트는 브리프를 받아 Develop 실행에서 세 가지를 돌려줍니다. 요구사항 문서, 아키텍처 문서, 계획된 이슈 묶음이며, 모두 실제 작업이 되기 전에 사람이 승인합니다. 실행 한 번은 플랜의 AI 실행 한 회를 씁니다(Builder는 월 100회, Studio는 월 500회). 에이전트와 채팅하는 것은 쓰지 않습니다. 지난주에 준 브리프를 약간 다듬은 것입니다.

목표: 금요일에 다음 사이클을 계획할 수 있도록 "예약 리마인더"의
요구사항, 아키텍처, 계획된 이슈를 만든다.

입력:
- 페이지 "예약 리마인더: 메모" (기준선)
- Calendar 제품에서 "reminders" 라벨이 붙은 이슈 (배경)
출처가 충돌하면 페이지가 우선. 충돌은 미해결 질문에 나열한다.

제약:
- 범위: 이메일과 인앱만. 이번 사이클에는 SMS 없음.
- 사실: 발송 성공률이나 고객 인용문을 지어내지 말 것.
- 행동: 계획 실행임. 계획된 이슈만 만들고, 기존 이슈의 상태는
  바꾸지 말 것.

완료 정의:
- [ ] 사용자 스토리와 인수 기준이 있는 요구사항
- [ ] 건드리는 구성요소와 건드리지 않는 구성요소를 명시한 아키텍처
- [ ] 한 사람이 한 사이클에 끝낼 만큼 작은 계획된 이슈. 각각 구현하는
      요구사항에 연결됨
- [ ] 미해결 질문 나열

검토: Moeid가 요구사항 페이지를 승인하고, 이어서 계획된 이슈를 승인한 뒤
백로그에 넣는다.

돌아온 것은 계획된 이슈 11개, 미해결 질문 2개(그중 하나는 메모 페이지와 오래된 이슈 사이의 실제 충돌), 그리고 동기화 계층을 제대로 건드리지 않은 아키텍처 문서였습니다. 요구사항 감사는 나중에 납품된 이슈를 그 고정된 기준선과 비교해 커버리지를 보고했습니다. 감사는 코드가 아니라 계획에 대해 요구사항을 확인하므로, "아키텍처 문서가 정직한가"는 여전히 우리가 검증할 몫이었습니다.

에이전트가 부족했던 점: 이슈 두 개를 너무 크게 잡았고, 제약이 있는데도 미해결 질문 하나를 추측으로 해결했습니다. 둘 다 검토에서 잡혔고, 그것이 검토를 두는 이유입니다.

나쁜 결과를 만드는 실수

• 목표를 활동으로 쓴다. 에이전트는 활동을 하고 멈춥니다.
• 기준선을 명시하지 않는다. 출처 셋을 섞고 결과는 어느 것과도 맞지 않습니다.
• 사실에 대해 "알아서 판단해". 숫자를 지어냅니다. "알 수 없음"이 허용된다고 말하세요.
• 완료 정의가 검토자의 머릿속에만 있다. 에이전트는 듣지 못한 것을 확인할 수 없습니다.
• 역할로 검토를 지정한다. 아무도 맡지 않고, 그냥 나갑니다.
• 작업 두 개에 브리프 하나. 나누세요. 짧은 실행 두 번이 긴 실행 한 번을 이깁니다.
• 실행 후에 브리프를 쓴다(결과를 정당화하려고). 브리프는 계약이며 먼저 옵니다.

자주 묻는 질문

AI 에이전트 브리프에는 무엇이 들어가야 하나요?

다섯 가지입니다. 결과와 독자가 담긴 한 문장 목표, 써도 되는 입력과 우선순위, 범위·사실·행동에 대한 제약, 스스로 확인할 수 있는 완료 정의, 이름이 명시된 산출물을 보는 이름이 명시된 검토자. 200단어 이하로.

에이전트 브리프는 챗봇 프롬프트와 어떻게 다른가요?

챗봇은 한 번 답하고 당신이 읽습니다. 에이전트는 당신이 무언가를 보기 전에 여러 번 행동하므로, 브리프는 무엇을 말할지뿐 아니라 무엇을 건드려도 되는지와 언제 멈출지를 다뤄야 합니다. 표현보다 제약과 완료 정의가 더 중요합니다.

완료 정의는 얼마나 상세해야 하나요?

에이전트가 당신에게 묻지 않고 각 항목을 체크할 수 있을 만큼 상세하고, 검토자가 실제로 확인할 만큼 짧게. 보통 체크리스트 5–8줄입니다.

에이전트가 미해결 질문을 해결하게 해도 되나요?

아니요. 나열하게 하세요. 모호함을 추측으로 해결하는 에이전트는 끝난 것처럼 보이지만 가장 중요한 세부에서 틀린 결과물을 냅니다.

에이전트 실행이란 무엇인가요?

브리프에 대한 에이전트의 한 번의 실행으로, 시작과 끝, 검토할 산출물이 있습니다. Atrix에서 Develop 실행은 요구사항, 아키텍처, 계획된 이슈를 돌려줍니다. 에이전트 실행 용어집 항목과 AI 에이전트 정의를 보세요.

좋은 브리프가 있으면 검토가 필요 없나요?

아니요. 좋은 브리프는 검토를 빠르게 합니다. 검토자가 모든 것을 처음부터 읽는 대신 완료 정의를 확인하면 되기 때문입니다. 검토 단계는 그래도 에이전트가 틀린 두세 가지를 잡아내는 부분입니다.

다음 단계

다음에 에이전트에게 맡기려던 작업을 가져와 시작하기 전에 다섯 부분을 써 보세요. 완료 정의를 쓰기 어렵다면 그 작업은 아직 에이전트에 맞지 않습니다. 브리프를 받은 실행이 실제로 무엇을 돌려주는지는 AI 에이전트 페이지에서 Develop 실행이 만드는 요구사항, 아키텍처, 계획된 이슈를 볼 수 있습니다.