한마디로

지금까지 이 시리즈에서는 에이전트(Agent)를 "물리적 측면에서 구속하는" 것의 중요성에 대해 깊이 있게 다루어 왔습니다. 이번에는 관점을 조금 바꾸어, 실제로 리포지토리(Repository)에서 작동하고 있는 작은 자동화 사례를 소재로 여러분이 자신의 개발에 어떻게 응용할 수 있을지에 대한 힌트를 전달하고자 합니다. 모델 단독의 "놀라운 생성"이라기보다는, 모킹(Mocking)된 광고 문안과 JSON만으로 이야기할 수 있는 보다 실무적인 내용이 될 것입니다. 대외 공개 기사 대장에서는 본고를 미공개 드래프트로서 #004 (소재 도구 ID: 1027)에 연결해 두었습니다.

소재가 되는 도구

저희가 이번에 다루는 것은 **ROI 광고 카피를 여러 안으로 생성하고, 그중에서 최적의 안을 선택하는 CLI 도구 (ID: 1027)**입니다. 역할은 단순합니다. 광고 플랫폼, 예상 독자, 상품 정보를 입력하면 짧은 광고 문안과 점수가 포함된 JSON을 출력하는 것입니다. 마케팅 담당자가 스프레드시트에 붙여넣을 수 있는 형태로 만드는 것과, 개발자가 pytest나 Playwright를 사용하여 그 품질을 지키는 것. 이 두 가지를 양립시키는 것이 현장에서는 꽤 어렵다고 느끼는 분들도 계실 것입니다. 하지만 입구를 JSON으로 고정하는 것만으로도 이 가교 역할은 상당히 수월해집니다.

현재 코드 패스(Code path)에서는 외부 LLM(Large Language Model)으로의 실전 호출보다 먼저, --mock 옵션이 붙었을 때는 결정론적인 스텁(Stub)으로서 copies(여러 안)와 best를 반환하도록 되어 있습니다. 즉, "데모"와 "자동 테스트"를 동일한 함수로 처리할 수 있다는 뜻입니다. 외부에 도구를 보여줄 때, 환상 속의 생성 결과에 대해 말하는 것보다 언제든 재현 가능한 출력이 있는 편이 설명에 드는 비용을 격감시킵니다.

설계서(DESIGN.md)에서는 허가된 출력 경로로의 쓰기, 결제 게이트웨이, 외부 서비스와의 계약과 같은 부분들이 정적으로 보호될 수 있도록 분할되어 있습니다. 여기서 중요한 것은 Oracle / Permitted / Prohibited와 같은 존(Zone) 구분 방식입니다. 상세한 내용은 공개 사양서(하단 링크)에 맡기겠습니다.

대략적인 입출력 데모 (가상 입력)

예를 들어, 클라우드 이전 지원 서비스를 상품으로 하고, 중견 기업의 IT 부서 의사 결정자를 예상 독자로, 채널을 Google 검색 광고로 설정한 경우를 생각해 봅시다.

--bypass-payment와 --mock을 붙인 경로에서는 이 세 가지 입력이 시드(Seed)가 되어 해시(Hash)가 결정됩니다. 즉, 동일한 입력이라면 매번 동일한 copies와 best가 반환됩니다. 출력되는 JSON의 한 예(설명을 위해 실제 딕셔너리 구조에서 본질만 추출)는 다음과 같은 형태가 됩니다.

• copies: 두 가지 안의 텍스트 안과 채널명, 그리고 간이 스코어(Score)
• best: 그중에서 스코어가 최대인 한 가지 안

이 모두 외부 API와의 왕복 없이 (모킹) 검증되었습니다.

여기서 여러분이 주목해 주셨으면 하는 점은, "대단한 문장을 쓰게 했다"라는 화려한 성과보다, **"광고 운용에서의 입력(상품/독자/매체)을 함수의 계약(Contract)으로서 얼마나 고정할 수 있는가"**라는 점입니다. 스코어는 휴리스틱(Heuristic)한 것이어도 상관없습니다. 평가와 생성을 분리하고 로그로서 JSON이 남는 형태로 해두면, 나중에 평가 로직을 교체하는 것도 훨씬 쉬워집니다.

채널별 기준 스코어(Google, Meta, LinkedIn 등)에 짧은 문장에 어울리는 길이라면 점수를 조금 더 가산하는 식의 2단계 구성이 코드상으로도 명시되어 있습니다. 생성 모델을 나중에 변경할 가능성은 항상 존재합니다. 그럴 때라도 평가기(Evaluator)와 그 "계약"만큼은 먼저 안정시켜 두는 것이, 이러한 종류의 도구를 "자동화 인프라"로서 기능하게 만드는 요령이라고 생각합니다.

자동 평가 (evals)는 무엇을 보고 있는가

그렇다면 자동 평가(evals)에서는 구체적으로 무엇을 보고 있을까요? 하나의 관점으로는 표준 출력에 "status": "success"라는 구조화된 프래그먼트(Fragment)가 나타나는 것을 들 수 있습니다. 로그 집계 도구와의 상성까지 고려하여 고정해 두는 것입니다. 여기서는 "읽기 쉬움"보다 **"기계 검사 용이성"**이 우선됩니다.

도구 측의 평가 정의에는 크게 세 가지 계통이 있습니다.

• --mock을 경유하여 표준 출력에 "copies"와 "best"

포함되며, 상태(status)가 성공(success)이 되는 것. - 적대적(adversarial)이거나 과도하게 관대한 assertion(단언)을 금지하는 정적 체크(static check)를 통과하는 것.

pytest 측에서 @pytest.mark.adversarial이 붙은 테스트가 의도적으로 스킵(skip)되지 않는 것.

개발자 관점에서 보면, 이것들은 사소한 작업처럼 보일지도 모릅니다. 하지만 에이전트 지원으로 코드가 복잡하게 불어날수록, 이러한 '자동으로 떨어지는 울타리'를 미리 마련해 두는 것만으로도 회귀 테스트(regression test)의 속도는 상당히 달라집니다.

예를 들어, '적대적'이라고 표시한 테스트를 조용히 스킵하지 않는다는 단 하나의 규칙이, 운영 개시 몇 달 후에 발생할지도 모르는 지뢰를 제거하는 데 효과적입니다. CI의 초록색 불을 단순한 의식으로 끝내지 않는다는 의미에서의 실무적인 격차를 메우는 것이 바로 이 평가 정의 측의 역할입니다.

'30회'를 다한 브라우저/CLI 자동 테스트란

그렇다고는 해도, CLI의 단체 평가(unit evaluation)만으로는 운영 환경에서의 예기치 못한 파탄(경로 설정, 권한, 타이머와 CLI의 연동 등)을 모두 잡아내기는 어려울 것입니다. 그래서 Playwright를 사용하여 동일한 시나리오를 여러 사이클 돌리고, 그 로그를 남기는 패턴을 채택하고 있습니다.

본 도구의 보고 로그에도 기재되어 있듯이, 이 테스트 계열에서는 하나의 시나리오 묶음(5개의 검증 항목) × 30 사이클, 모두 성공이 한 번의 문지기로서 기능하도록 되어 있습니다. 하나의 사이클 안에서 '결제 없이는 거부되는가', '모크(mock)가 성공하는가', '특정 키워드가 존재하는가' 등을 한꺼번에 확인하며, 그 시련을 기계적으로 반복합니다.

독자 여러분께 가장 잘 전달될 수 있는 표현으로 말하자면, 이것은 **'자동 테스트의 횟수를 실적의 단위로서 쌓아 올리는 것'**이라고 받아들일 수 있지 않을까요? 단발적인 PASS는 우연도 포함될 수 있지만, 그것이 반복해서 성공할수록 환경의 변동에 의한 오검출이 아니라는 확신이 강해집니다.

자동화를 '개발의 부록'으로 끝내지 않고 여러분의 체크리스트에 반영하고자 한다면, 다음 네 가지 사항을 꼭 자신의 코드베이스에 옮겨보시기 바랍니다. (1) 생성의 출구를 JSON으로 고정할 수 있는가, (2) 모델에 의존하지 않는 모크(mock)로 재현 검증할 수 있는가, (3) CI 외부에서도 브라우저와 프로세스 양쪽에서 호출할 수 있는가, (4) 평가에 '놓치기 어려움'이라는 축이 있는가. 이번에 소개해 드린 도구는 이 네 가지를 충족하는 최소한의 예시로서 기능하고 있습니다.

클로즈드 시용 (연락처)

현재 이 도구군은 OSS(Open Source Software) 사양과는 별개의 레이어에서, '구현과 운용의 묶음'으로서 클로즈드에 가까운 형태로 개발을 진행하고 있습니다. 실제로 직접 테스트해 보고 싶거나, 사내 평가 대상으로 검토하고 싶으신 분은 이 기사의 Zenn 댓글 또는 aos-standard/AOS-spec의 Issue를 통해 용도를 한 문장 덧붙여 연락해 주시기 바랍니다. 사양 측의 논의와는 분리하여, 운용상 가능한 범위 내에서 답변해 드리겠습니다.

AOS v0.1 사양서 (GitHub)

본 기사에서 다루고 있는 '물리적 거버넌스(physical governance)' 접근 방식은 AOS (AI Operating Standard) v0.1로서 사양화하여 공개하고 있습니다.

사양에 흥미를 느끼셨다면 ⭐ Star를 눌러주시면 다음 버전 책정에 참고하겠습니다. Issue와 PR도 환영합니다.