본문 바로가기
카테고리 없음

#3. 에이전트 설계의 핵심: ‘목표’가 아니라 ‘제약조건’부터 쓰는 법

by mycalmarchive 2026. 1. 14.

에이전트형 AI를 쓰다 보면 이런 경험이 생깁니다. 같은 일을 시켜도 어떤 날은 “와, 깔끔하게 끝났다” 싶은데, 어떤 날은 결과가 애매하거나 방향이 살짝 새요. 이 차이를 만드는 건 의외로 ‘목표를 얼마나 잘 설명했는지’가 아니라, 제약조건을 먼저 정했는지예요. 오늘은 목표를 길게 말하기 전에 “어디까지가 완료인지, 무엇은 하면 안 되는지, 무엇을 우선으로 지킬지”를 먼저 써두면 에이전트가 훨씬 안정적으로 완료까지 가져가는 이유와, 그 제약조건을 실전에 바로 쓰는 방식으로 정리해볼게요.

 

에이전트 설계의 핵심: ‘목표’가 아니라 ‘제약조건’부터 쓰는 법
에이전트 설계의 핵심: ‘목표’가 아니라 ‘제약조건’부터 쓰는 법

1) 왜 ‘목표’보다 ‘제약조건’이 먼저인가: 완료를 흔들림 없이 만드는 핸들

에이전트에게 “이거 해줘”라고 말하는 건 목표를 주는 거예요. 문제는 목표만 주면 결과가 자꾸 흔들린다는 겁니다. 에이전트는 스스로 계획하고 실행하는 만큼, 목표를 향한 경로가 너무 많아요. 그래서 같은 목표라도 무엇을 강조하느냐에 따라 완전히 다른 결과가 나올 수 있습니다.

 

예를 들어 “블로그 글을 3,000자 이상 써줘”라는 목표가 있어도,

  • 설명을 쉽게 풀어야 하는지(입문자)
  • 전문적인 구조가 필요한지(운영자)
  • 예시를 많이 넣어야 하는지(체감형)
  • 중복 없이 간결해야 하는지(정보형)

이 우선순위가 없으면, 에이전트는 그때그때 다른 길을 택해요. 그러면 2편에서 만든 ‘완료형 작업 덩어리(입력/출력/과정/검증/승인)’도 중간에 흔들립니다.

 

반대로 제약조건을 먼저 주면, 에이전트의 움직임에 핸들이 생겨요.
“여기까지가 완료야(범위). 이건 하지 마(금지). 이걸 먼저 지켜(우선순위).”
이 세 가지가 정해지면, 에이전트는 계획 단계부터 똑같은 기준으로 움직이고, 실행 중에도 경계선을 넘지 않으며, 검증 단계에서 스스로 고칠 수 있는 기준을 갖게 됩니다. 즉, 목표는 도착지라면 제약조건은 도로 규칙이에요. 도착지만 주면 헤맬 수 있지만 규칙이 있으면 같은 목적지도 훨씬 안전하고 일관되게 도달합니다.

 

2) 제약조건을 3줄로 쓰는 프레임: 범위·금지·우선순위

제약조건을 어렵게 쓰지 않아도 돼요. 실전에서 가장 강력한 건 딱 이 3줄입니다.

 

(1) 범위(스코프): 어디까지 해야 ‘완료’인가?

가장 먼저 “완료의 끝”을 고정합니다. 범위가 없으면 에이전트는 더 해야 할지 멈춰야 할지 흔들려요.

  • 예: “결과물은 소제목 3개 + 본문 3,000자 이상 + 맺음글에 다음 편 예고까지 포함하면 완료.”
  • 예: “여행 계획은 일자별 일정표 + 예상 비용 + 이동 동선 + 예약 필요 항목 리스트까지면 완료.”

범위가 잡히면 계획이 정교해지고, 검증 기준도 자동으로 따라옵니다.

 

(2) 금지(가드레일): 절대 하면 안 되는 것

에이전트는 실행력이 강해서, ‘하지 말 것’을 적어두는 게 안전장치가 됩니다. 동시에 결과의 일관성을 만드는 경계선이기도 해요.

  • 예: “개인정보/실명/계정 정보는 포함하지 말 것.”
  • 예: “결제/예약 확정/외부 전송은 내 승인 없이는 진행하지 말 것.”
  • 예: “근거가 불확실하면 단정하지 말고 ‘추정’이라고 표시할 것.”

금지가 명확할수록 에이전트는 쓸데없는 시도를 줄이고, 결과가 안정됩니다.

 

(3) 우선순위: 무엇을 먼저 지킬 것인가?

목표가 여러 개(정확하게, 빠르게, 보기 좋게…)일수록 우선순위가 없으면 결과가 들쭉날쭉해요.

  • 예: “정확도 > 간결함 > 속도”
  • 예: “독자 이해도(쉬운 말) > 전문성 > 재미”
  • 예: “예산 절감 > 편의성 > 일정 밀도”

이 한 줄은 에이전트가 선택해야 하는 순간마다 동일한 판단 기준을 제공합니다. 그래서 같은 작업을 맡겨도 매번 결과가 비슷한 톤과 품질로 나와요.

 

3) 제약조건이 ‘검증→수정’ 루프로 이어지게 만드는 방법: 체크리스트로 고정하기

1편에서 에이전트의 강점은 계획→실행→검증→수정 루프라고 했죠. 그런데 제약조건을 ‘문장’으로만 두면, 검증 단계에서 흐려지기 쉬워요. 그래서 제약조건은 반드시 체크리스트로 바꿔두는 게 좋습니다. 이 순간부터 에이전트는 “그럴듯한 답변 생성기”가 아니라 “운영 가능한 완료 시스템”이 됩니다.

아래는 블로그 글 작업에 바로 붙여 쓸 수 있는 형태예요.

 

✅ 제약조건 기반 30초 검증 체크리스트(블로그 글 기준)

[범위 체크]

  • 소제목이 정확히 3개인가?
  • 본문이 3,000자 이상인가?
  • 도입부에 ‘오늘 무엇을 다룰지’가 한 문장으로 들어갔나?
  • 맺음글에 다음 편 예고가 포함됐나?

 

[금지 체크]

  • 과도한 단정/근거 없는 확신 표현이 있으면 완화했나?
  • 개인정보/실명/계정 관련 내용이 들어가지 않았나?
  • 결제/예약/신청을 ‘완료했다’고 쓰지 않았나? (승인 전 단계 유지)

 

[우선순위 체크]

  • 쉬운 표현과 구체 예시를 우선했나?
  • 중복되는 문장이 있으면 줄였나?
  • 각 소제목의 핵심이 1문장으로 요약 가능한가?

 

이 체크리스트를 글의 “검증 단계”에 붙여두면, 에이전트는 초안을 만든 뒤 스스로 점검하고 수정하면서 완성도를 끌어올릴 수 있어요. 2편에서 만든 ‘작은 플레이북(작업서)’이 여기서 완성됩니다. 그리고 이 플레이북을 재사용하는 순간부터, 매번 새로 지시하지 않아도 일정한 품질로 결과물이 누적돼요. 이게 진짜 “에이전트를 굴리는 감각”입니다.

 

1편에서 우리는 에이전트형 AI가 ‘답’이 아니라 완료를 목표로 움직인다는 걸 확인했고, 2편에서는 반복 업무를 찾아 완료형 작업 덩어리로 묶는 방법을 정리했어요. 오늘 3편에서는 그 덩어리가 흔들리지 않게 만드는 설계 기술, 즉 ‘목표’가 아니라 ‘제약조건’부터 쓰는 법을 다뤘습니다. 범위(완료의 끝), 금지(경계선), 우선순위(판단 기준)만 먼저 고정해도 에이전트는 훨씬 안전하고 일관되게 완료까지 갑니다.

 

다음편에서는 이 제약조건 설계를 가장 실전적인 장면에 적용해볼 거예요. 바로 브라우저 에이전트 실전: 예약/구매/신청을 맡길 때 생기는 변수와 해결 패턴입니다. 로그인, 옵션 선택, 재고 변동, 결제 직전 확인, 캡차 같은 ‘변수’가 몰려오는 환경에서, 오늘 정리한 제약조건과 승인 지점이 어떻게 작동하는지 사례로 풀어보겠습니다.