Gate 조건과 Orchestration Preset — 복잡한 작업을 파이프라인으로 분해하는 법

-

4단계 게이트 시스템과 Preset으로 AI 에이전트의 작업 흐름을 통제하는 구조

핵심 요약

  • AI 에이전트에게 복잡한 작업을 시키면 중간 과정이 불투명해진다. 게이트 시스템으로 각 단계에 진입/종료 조건을 걸면 품질을 통제할 수 있다
  • brainstorming → writing-plans → execution → verification, 4단계 각각에 Built-in Rules가 있다. 추상적 표현 금지, 3회 실패 서킷브레이커, "should work" 금지 같은 구체적 규칙
  • Orchestration Preset으로 반복되는 파이프라인을 단축하고, Ambiguous Request Gate로 불명확한 요청은 자동으로 인터뷰 단계로 보낸다

배경

에이전트에게 "블로그 글 써줘"라고 하면 어떤 일이 일어날까요?

에이전트는 바로 글을 쓰기 시작합니다. 주제가 뭔지, 독자가 누군지, 어떤 구조가 좋은지 — 이런 고민 없이 출력을 생성합니다. 결과물이 나와도 검증 없이 "완료"라고 보고합니다.

사람이 글을 쓸 때는 이렇게 하지 않습니다. 주제를 정하고, 구조를 잡고, 쓰고, 퇴고합니다. 각 단계를 넘어갈 때 "이 정도면 다음으로 넘어가도 되겠다"는 판단이 있습니다.

에이전트에게도 이 판단 구조를 심어줄 수 있습니다. 그것이 게이트 시스템입니다.

본문

1. 4단계 게이트 — 각 단계에 진입 조건과 종료 조건이 있다

게이트 시스템의 핵심은 단순합니다. 다음 단계로 넘어가려면 조건을 충족해야 한다. 조건을 못 채우면 넘어갈 수 없습니다.

단계 진입 조건 종료 조건
brainstorming 복합 분류된 요청 사용자의 설계 승인
writing-plans brainstorming 통과 구체적 구조 + 명령어 + 예상 출력 포함
execution writing-plans 통과 전 단계 완료 또는 3회 실패 시 STOP
verification execution 통과 증거 기반 검증 통과

왼쪽에서 오른쪽으로 흐릅니다. 중간 단계를 건너뛸 수 없습니다. brainstorming을 통과하지 못하면 writing-plans에 진입할 수 없고, writing-plans를 통과하지 못하면 execution에 진입할 수 없습니다.

이 구조가 왜 필요한지, 각 단계별로 봅니다.

2. 각 게이트의 Built-in Rules

brainstorming: 2~3개 대안 비교 필수

brainstorming 단계에서는 하나의 안을 바로 확정하지 못합니다. 반드시 2~3개 대안을 서로 다른 관점에서 비교해야 합니다. 그리고 반대 서사(counter-narrative)가 필수입니다.

왜? 에이전트는 기본적으로 첫 번째 떠오른 안을 밀고 나가려는 경향이 있습니다. 사람도 마찬가지지만, 에이전트는 확증 편향에 대한 자각이 없습니다. "이 방법이 틀리려면 어떤 조건이 필요한가?"를 강제로 묻게 만드는 것입니다.

종료 조건은 사용자의 설계 승인입니다. 에이전트가 자체적으로 "이 안이 좋겠다"고 결정하지 않습니다. 대안을 제시하고 사용자가 선택합니다.

writing-plans: 추상적 표현 금지

이 단계의 규칙은 명확합니다. "콘텐츠를 추가한다", "필요에 따라 리팩터링한다" 같은 표현은 금지. 실제 구조, 실제 명령어, 예상 출력이 포함되어야 합니다.

에이전트가 계획을 세울 때 가장 흔한 문제가 이것입니다. "데이터를 수집하고 분석한다"는 계획이 아닙니다. "A 소스에서 B 데이터를 가져와서 C 형식으로 정리하고, D 기준으로 필터링한다"가 계획입니다.

추상적 계획은 실행 단계에서 에이전트가 임의로 해석하게 만듭니다. 구체적 계획은 해석의 여지를 줄입니다.

execution: 3회 실패 서킷브레이커

실행 단계에서 같은 작업이 3번 실패하면 자동으로 중단됩니다. 더 시도하지 않습니다.

이 규칙이 없으면 에이전트는 같은 접근법으로 반복 시도합니다. 토큰을 소모하고 시간을 낭비하면서 다른 방법을 시도하지 않습니다. 3회 실패 시 STOP이 걸리면 에이전트는 접근 방식 자체를 재검토해야 합니다.

3이라는 숫자에 특별한 이론적 근거가 있는 것은 아닙니다. 1회는 너무 엄격하고(일시적 오류 가능), 5회는 이미 낭비가 시작된 후입니다. 실운영 결과 3이 적절한 균형점이었습니다.

verification: "should work" 금지

검증 단계의 규칙은 하나입니다. "아마 괜찮을 것이다(should work)", "대체로 문제없다(probably fine)" 같은 표현은 금지. 오직 증거만 인정됩니다.

이게 왜 중요한가? 에이전트는 자신이 생성한 결과물에 대해 긍정적으로 평가하는 경향이 있습니다. "이 정도면 괜찮겠죠?"는 검증이 아닙니다. "A 조건을 충족하고, B 데이터와 일치하며, C 출처에서 확인했다"가 검증입니다.

검증 실패 시 수정 후 재검증합니다. 3회 재검증 실패 시 사용자에게 에스컬레이션합니다.

3. Orchestration Preset — 반복 파이프라인의 단축

매번 4단계를 전부 거칠 필요는 없습니다. 자주 반복되는 작업 유형에는 미리 정의된 파이프라인이 있습니다.

Preset 파이프라인
research deep-interview → research → compile → verify → publish
quick-draft executor → verify
review code-review(content) → verification

research preset은 심층 조사용입니다. 주제가 불명확하면 인터뷰로 명확화하고, 조사하고, 소스 파일로 정리하고, 검증하고, 발행합니다. 전체 파이프라인을 탑니다.

quick-draft preset은 이미 소스가 있을 때 씁니다. 바로 초안을 작성하고 검증만 거칩니다. brainstorming이나 planning 단계가 필요 없는, 단순한 작업에 적합합니다.

review preset은 이미 작성된 글을 점검할 때 씁니다. 콘텐츠 리뷰와 검증만 수행합니다.

Preset은 게이트를 없애는 것이 아닙니다. 불필요한 게이트를 건너뛰는 것입니다. quick-draft에서도 verification 게이트는 동일하게 적용됩니다.

4. Ambiguous Request Gate — 불명확한 요청 처리

"이것도 조사해줘"라는 요청이 들어오면 어떻게 할까요?

주제는 있지만 범위가 없습니다. 용도가 블로그인지 트위터인지 모릅니다. 어떤 깊이로 조사할지 불명확합니다.

Ambiguous Request Gate는 이런 상황을 처리합니다. 요청에 구체적 신호(키워드, 범위, 용도)가 없으면 → 자동으로 deep-interview 단계로 진입합니다. 에이전트가 사용자에게 질문을 던져서 범위를 좁힙니다.

이 게이트는 force: 접두사로 우회할 수 있습니다. "force: AI 에이전트 조사해줘"라고 하면 인터뷰 없이 바로 실행에 들어갑니다. 사용자가 이미 충분히 생각했을 때 유용합니다.

설계 판단

게이트 시스템을 처음 설계할 때 빠진 것이 종료 조건의 구체성이었습니다.

초기 버전에서는 writing-plans의 종료 조건이 "계획이 충분히 구체적일 때"였습니다. 에이전트는 이 조건을 자기 기준으로 판단했고, "데이터를 수집하고 분석한다" 같은 추상적 계획을 통과시켰습니다.

이후 "구체적 구조 + 명령어 + 예상 출력 포함"으로 종료 조건을 변경한 후, execution 단계에서의 오류가 줄었습니다. 게이트의 종료 조건이 모호하면 게이트가 없는 것과 같다는 교훈이었습니다.

서킷브레이커 임계값도 5회에서 3회로 조정했습니다. 실측 결과 3회 실패한 작업이 4~5회차에서 성공하는 경우가 거의 없었습니다. 임계값을 낮추는 것이 토큰 효율과 품질 모두에 유리했습니다.

OpenClaw → Hermes 마이그레이션 과정에서 이 게이트 구조의 필요성이 가장 명확하게 드러났습니다. OpenClaw는 안정적으로 운영 중이었지만, Hermes 전환 초기에 토큰 폭주 문제가 발생했습니다. execution 단계의 서킷브레이커가 없었다면 수습하기 훨씬 어려웠을 것입니다. 현재는 OpenClaw로 회귀한 상태에서 Hermes를 재검증 중이며, 게이트 조건이 이 검증 루프의 핵심 도구가 되고 있습니다.

마무리

게이트 시스템의 본질은 에이전트의 자율성을 구조로 통제하는 것입니다. 에이전트가 자유롭게 작업하되, 단계 전환 시점에서는 반드시 조건을 충족해야 합니다.

이 구조가 없으면 에이전트는 "받은 즉시 실행, 바로 완료 보고"를 합니다. 빠르지만 품질을 보장할 수 없습니다. 게이트가 있으면 느려지지만 예측 가능해집니다.

다음 글에서는 이 파이프라인 안에서 각 단계를 어떤 모델이 담당하는지 — 모델 라우팅 전략을 다룹니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »