서론

처음 뵙겠습니다. 프리랜서 엔지니어 @takunotech 입니다. AI 에이전트를 사용한 개발·자동화 설계와 검증에 대해 발신하고 있습니다.

본 기사에서는 실운용에서 도움이 되었던 정지 조건(Stopping Condition)의 사고방식을 정리합니다.

AI 에이전트에게 코드를 작성하게 하면, 조건이 맞는 상황에서는 구현 속도가 올라가는 경우가 많다고 생각합니다.

하지만 파일을 편집할 수 있다는 것, 명령어를 실행할 수 있다는 것, 외부 서비스에 게시할 수 있다는 것은 동시에 "실패했을 때의 영향이 크다"는 의미이기도 합니다.

그래서 필요해지는 것이 프롬프트(Prompt)의 궁리보다 먼저 결정해 두어야 할 정지 조건입니다.

이 기사에서는 AI 에이전트를 실운용에 가까운 형태로 사용할 때, 최소한으로 나누고 싶은 검사와 상태 전이(State Transition)를 정리합니다. 특정 모델의 성능 비교가 아니라, 많은 코드 실행형 에이전트에 응용할 수 있는 운용상의 이야기로서 작성하고 있습니다.

「완료」의 의미를 분해하기

에이전트의 실행 결과를 다음 4가지로 나누어 봅니다.

정적 검사(Static Analysis)를 통과한다— 파서(Parser), 타입 검사(Type Check), lint가 통과함 -
내부 로직이 통과한다— 단체 테스트(Unit Test)나 불변 조건(Invariant)을 만족함 -
실행 환경에서 통과한다— 실제 브라우저나 실제 데이터로 상태 변화를 확인할 수 있음 -
외부 결과가 통과한다— 공개 URL이나 외부 서비스의 상태를 확인할 수 있음

이전 단계에 합격해도 다음 단계는 보장되지 않습니다. 구문 오류(Syntax Error)가 없어도 실제 브라우저에서 입력을 받아들이지 못할 수 있습니다. 실행이 완료되어도 외부 서비스에 공개되지 않았을 수 있습니다.

「성공」이라고 기록하기 전에 어느 단계까지 확인했는지를 남겨두는 것만으로도 나중에 원인을 추적하기 쉬워집니다.

1. 파괴적인 조작은 실행 전에 멈춘다

에이전트가 출력한 명령어를 그대로 실행하지 않도록 합니다.

삭제, 덮어쓰기, 데이터베이스 변경, 외부 전송 등 취소하기 어려운 조작은 실행 전에 별도의 검사를 끼워 넣습니다. 여기서 중요한 것은 위험한 명령어 리스트를 계속 늘려가는 것이 아닙니다.

후보 명령어
↓
조작의 종류를 분류
...

정지 조건은 「에이전트를 신용하지 않기 위해서」가 아닙니다. 에이전트가 옳더라도 대상 경로(Path)나 실행 환경을 오인할 가능성이 있기 때문입니다.

2. 구현과 리뷰의 대화를 분리한다

같은 대화 흐름 그대로 구현과 리뷰를 계속하면, 구현 중에 채택한 전제를 리뷰 측까지 그대로 이어받기 쉽습니다.

리뷰로 넘길 것을 수락 조건(Acceptance Criteria)과 차이점(Diff)으로 좁힙니다.

{
"acceptance_criteria": [
"입력 후에 화면 상태가 변한다",
...

이렇게 한다고 해서 리뷰가 완전히 독립되는 것은 아닙니다. 다만 구현자가 "이러면 동작할 것이다"라고 생각한 이유를 그대로 리뷰의 전제로 삼지 않도록 경계를 만들 수 있습니다.

3. 저장 완료와 공개 완료를 분리한다

자동화에서는 로컬의 성공과 외부의 성공이 섞이기 쉽습니다.

• 파일이 저장되었다
• 첨부 처리가 끝났다
• 명령어가 종료되었다

이것들은 외부 서비스로의 공개가 완료되었음을 그것만으로 증명하는 것이 아닙니다.

예를 들어, 후보를 다음과 같은 상태로 관리하면 분리하기 쉬워집니다.

candidate
→ claimed
→ executing
...

공개 URL이나 외부 서비스가 반환한 상태를 확인할 수 없는 경우에는 posted로 진행하지 않고, verification_failed 등의 정지 상태에 둡니다. candidate로 되돌리지 않음으로써, 실패했을지도 모르는 후보를 다음 실행이 다시 집어 올리는 것을 방지할 수 있습니다.

상태를 문자열로 가지는 것만으로도 완료 판정을 코드로 구현하기 쉬워집니다.

type AgentRunState =
| "candidate"
| "claimed"
...

이 함수가 false인 상태라면, 저장 표시나 명령어 종료만으로 posted로 전이시키지 않도록 합니다.

4. 지식에는 신선도를 부여한다

에이전트의 메모리나 지식 베이스(Knowledge Base)는 저장하는 것만으로는 품질이 올라가지 않습니다.

최소한 다음 필드를 함께 갖게 합니다.

{
"fact": "참조하는 사실",
"source": "출처 URL이나 1차 자료",
...

여기서 reference_only로 설정하는 것이 중요합니다. 공개된 게시물이나 누군가의 발언을 그대로 정답이나 명령으로 취급하지 않습니다. 참고한 뒤에 현재의 대상과 증거에 비추어 재검증합니다.

5. 숫자 비교 조건을 맞춘다

게시나 작업(Job)의 결과를 평가할 때도 측정 시점을 분리합니다.

• 초동: 10분 ~ 2시간
• 중간: 3 ~ 10시간
• 24시간 전후: 14 ~ 36시간

10분 후의 표시 수와 24시간 후의 표시 수를 동일한 종류의 숫자로 비교하지 않도록 합니다. 월간 공식 집계가 아직 보이지 않는 단계에서 수중에 있는 로그를 합산할 경우에도, "관측된 하한"이라고 명시합니다.

추정치와 실적치를 같은 표에 두면 숫자는 늘어나 보이지만, 어느 공정을 수정해야 할지 알 수 없게 됩니다.

실무에서 사용하는 공개 전 체크리스트

실행 전

• 파괴적인 조작과 외부 전송을 분류했는가
• 수락 조건(Acceptance Criteria)이 문장으로 작성되어 있는가
• 리뷰용 차분(Diff)과 전제를 분리했는가
• 첨부 파일의 표시 내용과 메타데이터를 확인했는가

외부 쓰기 전

• 동시 실행 시 동일한 후보를 중복 처리하지 않도록 ID 단위로 클레임(Claim)할 수 있는가
• 동일한 후보를 다른 실행이 처리하고 있지는 않은가
• 본문과 첨부가 최신 리뷰 결과와 일치하는가
• 개인을 식별할 수 있는 정보, 알림, 토큰, 로컬 경로가 남아있지 않은가

실행 후

• 외부 공개 URL 또는 상태를 취득했는가
• 취득할 수 없는 경우를 성공으로 저장하고 있지는 않은가
• 초동·중간·24시간의 측정 창(Window)을 분리했는가
• 다음 재실행이 동일한 후보를 다시 집어 들지 않는 상태가 되었는가

최소 구성부터 시작하기

갑자기 거대한 오케스트레이터(Orchestrator)를 만들 필요는 없습니다. 처음에는 다음 세 가지만으로도 충분합니다.

• 실행 전: 파괴적인 조작과 외부 전송을 인간의 확인 단계로 넘긴다
• 실행 중: candidate / executing / external_result_verified / posted / verification_failed 상태를 분리한다
• 실행 후: 성공 판정에 사용한 URL, 일시, 검증 결과를 저장한다

나중에 검사를 늘릴 때도, 어떤 상태 전이(State Transition)를 종료하기 위한 검사인지 결정해 두면 에이전트의 처리가 복잡해지는 것을 방지할 수 있습니다.

요약

AI 에이전트 도입 시 가장 먼저 최적화하고 싶어지는 것은 프롬프트와 모델일 것입니다.

하지만 실무에서 효과를 발휘하는 것은 "어디까지 진행되었을 때 성공이라 부를 것인가", "어디서 멈출 것인가", "무엇을 증거로서 저장할 것인가"를 먼저 결정하는 것입니다.

속도가 빠른 메커니즘일수록, 실패했을 때 멈출 수 있는 경계가 필요합니다. 정지 조건은 속도를 늦추기 위한 것이 아니라, 속도를 안전하게 계속 사용하기 위한 설계입니다.

앞으로도 생성형 AI에 국한되지 않고 다양한 내용을 발신하고 싶으니, 좋아요나 X 계정 팔로우를 해주시면 감사하겠습니다🙌

X 계정: https://x.com/takunotech

Discussion