요즘 “AI 에이전트”라는 단어를 정말 자주 접하게 됩니다. 처음에는 단순한 유행어처럼 느껴졌지만, 다양한 고객 환경을 경험하면서 “우리 환경에 맞게 안전하게 동작하는 업무용 에이전트 엔진이 필요하다”는 요구가 분명히 늘어나고 있다는 생각이 들었습니다.
이러한 배경에서 현재 업무와 맞닿아 있는 DevOps 작업을 대상으로, Ops 에이전트를 하나의 백엔드 서비스로 구현해보자는 고민을 시작하게 되었습니다. 실제 개발 과정에서는 OpenAI Codex와 같은 코딩 에이전트의 도움을 받아 구현을 진행했습니다.
그런데 막상 만들려고 고민을 해보니 금방 부딪히는 질문이 생깁니다.
“자율적으로 판단하게 하되, 어디까지 허용할 것인가?”“실수했을 때 어떻게 멈출 것인가?”“중간 과정은 믿을 수 있게 관찰 가능한가?”
처음에는 단순히 “질문 → 도구 호출 → 답변”으로 시작했지만, 실제 요청이 복잡해질수록 다음 이슈가 반복됐습니다.
- 점검은 잘 되는데 조치로 자연스럽게 이어지지 않음
- 중간 판단이 있었는지, 그냥 정해진 레시피를 돈 건지 불분명함
- 출력은 그럴듯한데 실행 결과와 미묘하게 어긋남
- 같은 문제를 다시 파고들 때 로그만으로 원인 분석이 어려움
이 글은 그 시행착오를 거치면서 정리한 현재 아키텍처와 메커니즘, 그리고 왜 이렇게 설계했는지에 대한 기록입니다.
개발에서 지키려는 원칙
먼저 원칙부터 명확히 했습니다. 원칙이 흔들리면 구현은 빨라 보여도 결국 재작업(리팩토링)이 늘 뿐입니다.
- 본체(runtime/flow/resolver)에 도메인 하드코딩 금지
- 행동 제어는 코드 분기보다 계약/정책의 선언형 외부화 우선
- 동작은 자율적으로, 하지만 가드레일 안에서만
- 결과뿐 아니라 과정도 검증/관측 가능해야 함
핵심은 “자율성”과 “통제”를 대립시키지 않는 것입니다.자율성은 판단의 유연성이고, 통제는 실패의 반경을 줄이는 장치입니다.
아키텍처 요약
구현에 있어 정리한 패턴은 다음과 같습니다.
LLM + Tools + State + Control + Guardrails
그리고 동작 방식은 다음 네 가지 축으로 봅니다.
동적 계획 + 엄격 검증 + 상태전이 계약 + 관측/피드백
상태 전이 기반 실행 (State Machine) 다이어그램
1) 동적 계획: ‘무엇을 할지’는 고정하지 않는다
사용자 요청은 항상 완벽하게 구조화되어 들어오지 않습니다.예를 들어 “개발계 배포 상태 점검하고 조치해줘”는 상태 확인부터 완화 조치까지 넓은 범위를 포함합니다.
여기서 중요한 건, 처음부터 모든 단계를 하드코딩하지 않는 것입니다. 대신 Planner가 현재 요청과 컨텍스트를 보고 계획을 만들고, 필요한 capability를 선택합니다.
다만 “아무거나 선택”하게 두면 위험하니, 선택 가능한 능력은 카탈로그로 제한합니다. 즉, 동적이지만 무제한은 아닙니다.
예를 든다면 kubernetes 를 조회할 수 있는 능력 등 미리 준비해 둔 카탈로그 내에서 선택해서 수행할 수 있습니다.
2) 엄격 검증: 계획은 실행 전 반드시 걸러낸다
계획이 나오면 바로 실행하지 않습니다.Preflight 단계에서 계약 검증을 수행합니다.
검증 포인트는 대략 이런 식입니다.
- 허용 capability 목록에 있는가
- 필수 선행 capability가 빠지지 않았는가
- 실행 스타일(loop/recipe/conditional 등)이 계약과 맞는가
- 인자 참조가 해석 가능한가
이 단계가 중요한 이유는, “실행 중 장애”를 “실행 전 거절/보정”으로 바꿀 수 있기 때문입니다.실제로 존재하지 않는 capability, 누락된 필수 인자 같은 문제는 이때 걸러내야 비용이 줄어듭니다.
3) 상태 전이 계약: 단계별 게이트를 명시한다
요청 하나를 단발 실행으로 보지 않고 상태머신으로 다룹니다.
예시 흐름:
- planned
- preflight_validated
- executing
- completed / waiting_approval / failed / rejected
여기서 핵심은 “언제 다음 상태로 넘어갈 수 있는지”를 계약으로 명시하는 것입니다.특히 조치가 포함된 요청은 read-only 관찰만으로 종료하면 사용자 기대와 어긋날 수 있습니다.
그래서 개발과 테스트를 하다보니 점진적으로 다음과 같은 계약들을 강화하게 됩니다.
- 이상 신호가 있는데 사용자가 조치 의도를 포함했으면, action branch를 재계획하도록 유도
- 고위험 조치는 waiting_approval로 전이
- 승인 정보 무결성 검증 실패 시 즉시 reject
4) 관측/피드백: 결과만 보면 늦다
요청 단위 요약 분석 최적화를 위해 로그 체계를 갖추고 기능 업그레이드에 따라 지속적으로 보완해야 합니다.
- request-analysis: 상태 전이 경로, 실패 원인, LLM call count 등
- request-answer: 최종 응답
이 방식의 장점은 비용이 낮고, 운영 중 빠르게 원인 추적이 가능하다는 점입니다. 단점으로는 중간 스트림 이벤트를 완전히 재생하긴 어렵다는 점입니다.
그래도 현재 목적(효율/품질 분석)에는 충분히 유효합니다.특히 빠른 문제 분석을 위해 아래 질문들에는 빠르게 답할 수 있어야 합니다.
- 왜 failed/rejected가 됐는가
- 어떤 capability에서 막혔는가
- LLM 호출이 왜 늘었는가
- 최종 응답이 실행 결과와 일치하는가
계약 기반”이 자율성과 충돌하나?
이런 고민을 많이 하게 되었고 결론부터 말하면, 충돌하지 않습니다. 오히려 상호보완적입니다.
- 자율성: 어떤 capability 조합을 선택할지, 어떤 순서로 재계획할지
- 계약: 무엇이 금지/필수인지, 어떤 상태 전이만 허용되는지
계약이 없으면 자율성은 쉽게 임기응변이 됩니다.자율성이 없으면 계약은 그냥 정적 워크플로우가 됩니다.
현실적으로는 “계약 기반 가드레일 위에서 자율 오케스트레이션”이 가장 균형이 좋은 구조라고 생각하고 있습니다.
현재 진행 상태를 간략히 말하면
좋아진 점:
- 상태 전이/실패원인/호출수 분석이 가능해졌고
- read-only/approval/action 경계가 명확해졌고
- 일부 반복 루프와 불필요 호출이 줄었습니다.
아직 남은 점:
- “조치해줘”류 요청에서 조치 전이 충족률을 더 높여야 합니다.
- 응답 포맷의 일관성(특히 섹션 경계)은 더 단단히 해야 합니다.
- 계약 기반 재계획 루프의 범용성을 더 올려야 합니다.
즉, “동작한다”를 넘어서 “기대대로 일관되게 동작한다”로 가는 중입니다.
마무리
에이전트를 만들다 보면, 모델 성능만 이야기하기 쉽습니다.하지만 운영형 에이전트에서 더 중요한 건 구조적 신뢰성이라고 생각합니다.
- 계획은 상황에 맞게 유연해야 하고
- 실행은 사전에 검증되어야 하며
- 상태 전이는 계약으로 통제되어야 하고
- 결과뿐 아니라 과정도 관측 가능해야 합니다
Ops Agent는 범용 에이전트를 목표로 아래의 단계를 거쳐 왔습니다.
- 시나리오 고정형 단계
처음에는 scenarioId/scenarioType 중심으로, 미리 정한 흐름을 안정적으로 실행하는 데 집중했습니다. 장점은 예측 가능성이었고, 한계는 새로운 요청에 대한 유연성이 낮다는 점이었습니다.
- 계약 중심 통제 단계
다음으로 capability 카탈로그, preflight 검증, 승인 게이트, 응답 계약을 붙여 “무엇을 해도 되는지/안 되는지”를 명시적으로 관리하기 시작했습니다. 이 단계에서 안정성은 올라갔지만, 여전히 계획이 레시피에 가까운 경우가 있었습니다.
- 현재: 가드레일 + 계약 기반 자율 오케스트레이션
지금은 동적 계획을 기본으로 두고, 엄격 검증과 상태 전이 계약(예: planned → validated → executing → waiting_approval/completed)을 통해 실행을 통제합니다. 또한 관측 로그를 통해 실패 원인과 반복 패턴을 추적하면서, 재계획 루프를 점진적으로 고도화하고 있습니다.
아직 갈 길이 멉니다. 그래도 시나리오 고정형에서 시작해 계약 중심 통제를 거쳐, 지금의 가드레일 + 계약 기반 자율 오케스트레이션으로 넘어오면서 “설명 가능한 실행”에 한 걸음 가까워졌다고 생각합니다.
완성보다는 개선의 연속에 가깝지만, 기반을 갖추기 위해 노력하고 있고 앞으로도 같은 원칙 위에서 작게 검증하고, 확실하게 확장해나가는 계획입니다.
Andy