일하는 방식

AI가 틀렸을 때도 버티는 규칙.

AI 에이전트에서 좋은 결과를 한 번 뽑아내는 건 어렵지 않습니다. 어려운 건 스무 번째에도 같은 결과가 나오는 것, 다른 컴퓨터에서도, 새벽에도, 발밑에서 모델이 바뀐 뒤에도 같은 결과가 나오는 것입니다. 아래 다섯 가지는 실제로 강제하고 있는 규칙이고, 전부 그게 없어서 사고가 난 뒤에 추가된 것들입니다.

  1. 01

    자율성보다 운영 규약이 먼저

    무엇을 막기 위한 규칙인가
    능력은 좋은데 경계가 없는 에이전트는 묻지 않고 머지하고, 데모 도중에 공용 인프라를 재시작하고, 아무도 건드리라고 하지 않은 파일에 손을 대고, 몇 주 뒤에야 드러나는 지름길을 남겨 둡니다.
    실제로 강제하는 것
    에이전트는 명시적이고 실제로 검사되는 규칙 아래에서 돌아갑니다. 승인 없이 머지하지 않기, 공용 인프라를 예고 없이 재시작하지 않기, 명시된 범위 밖을 고치지 않기, AI가 만든 기술 부채를 남기지 않기, 낡은 기억으로 행동하지 않기. 이것들은 런타임에서 걸러집니다. 프롬프트에 적어 두고 지켜 주길 바라는 게 아닙니다.
    어디에서 드러나는가
    그 목록의 모든 항목은, 그게 없어서 실제로 대가를 치른 뒤에 추가된 것입니다.

  2. 02

    증거 기반 검증

    무엇을 막기 위한 규칙인가
    AI는 코드가 그럴듯하게 읽히는 순간 "완료"라고 보고합니다. 실행해 본 적도, 화면을 열어 본 적도, API를 호출해 본 적도 없이요. 일은 끝난 것처럼 보이고, 부채는 데모 당일까지 보이지 않습니다.
    실제로 강제하는 것
    작성했다고 끝난 게 아닙니다. 빌드와 린트와 검사가 통과하고, 배포된 결과를 실제로 확인해야 끝난 것입니다. "푸시했다"는 "출시했다"가 아니고, 출력이 붙지 않은 주장은 결과가 아닙니다.
    어디에서 드러나는가
    막연한 아이디어가 당일 데모까지 압축될 수 있는 이유입니다. 검증되지 않은 작업을 다음 단계로 넘기는 구간이 하나도 없습니다.

  3. 03

    다시 만들기 전에 진단하기

    무엇을 막기 위한 규칙인가
    에이전트의 블랙박스 장애는 밖에서 보면 전부 똑같이 생겼습니다. 응답 없음, 프로바이더 불일치, 플러그인 인증 만료, 세션 상태 드리프트, 툴 호출 충돌. 이때 가장 하고 싶은 일은 프레임워크째로 갈아엎는 것입니다.
    실제로 강제하는 것
    모든 장애는 먼저 이름을 붙일 수 있는 근본 원인까지 좁힙니다. 재구축은 진단 "다음"의 결정이지, 진단을 대신하는 선택이 아닙니다.
    어디에서 드러나는가
    "에이전트가 고장 났다"의 대부분은 몇 가지 알려진 원인으로 수렴하고, 각각에 대해 문서화된 SOP가 있습니다.

  4. 04

    프롬프트 요령보다 지속되는 맥락

    무엇을 막기 위한 규칙인가
    잘 쓴 프롬프트에 기댄 안정성은 툴을 바꾸는 순간, 세션을 다시 여는 순간, 다른 컴퓨터로 옮기는 순간 사라집니다. 그때마다 프로젝트를 처음부터 다시 설명해야 합니다.
    실제로 강제하는 것
    연속성은 표현의 문제가 아니라 아키텍처의 문제입니다. 기억과 상태는 툴 전환, 세션 재시작, 다른 기기를 넘어 살아남도록 설계합니다.
    어디에서 드러나는가
    새 세션이 다시 브리핑받지 않고도 진행 중인 작업을 이어받습니다. 메모리 레이어가 존재하는 이유가 그것뿐입니다.

  5. 05

    인수인계까지가 결과물

    무엇을 막기 위한 규칙인가
    만든 사람만 운영할 수 있는 시스템은 완성이 아니라 의존입니다. 다른 사람이 데모할 수도 없다는 뜻이고, 그게 이 시스템이 얼마나 멀리 갈 수 있는지를 조용히 제한합니다.
    실제로 강제하는 것
    SOP, 런북, 준비 점검은 결과물과 함께 납품합니다. 동료가 문서만 보고 돌리지 못하면 끝난 게 아닙니다.
    어디에서 드러나는가
    데모 세팅을 표준화한 덕분에, 잘 깨지던 일회성 구성이 제가 자리에 없어도 팀이 운영할 수 있는 것으로 바뀌었습니다.

이어지는 질문

이 방식에 대한 질문.

「증거 기반 검증」은 실제로 무엇을 뜻하나요?
작성했다고 끝난 게 아닙니다. 빌드와 린트와 검사가 통과하고, 배포된 결과를 실제로 확인해야 끝난 것입니다. 푸시한 것은 출시한 것이 아니고, 출력이 붙지 않은 주장은 결과가 아닙니다.
에이전트 운영 규약이란 무엇인가요?
프롬프트에 적어 두고 지켜 주길 바라는 게 아니라, 런타임에서 검사되는 명시적 규칙입니다. 승인 없이 머지하지 않기, 공용 인프라를 예고 없이 재시작하지 않기, 명시된 범위 밖을 고치지 않기, AI가 만든 기술 부채를 남기지 않기, 낡은 기억으로 행동하지 않기.
툴과 세션을 넘나들어도 에이전트 메모리를 어떻게 유지하나요?
연속성을 표현의 문제가 아니라 아키텍처의 문제로 다룹니다. 기억과 상태는 툴 전환, 세션 재시작, 다른 기기를 넘어 살아남도록 설계하기 때문에, 새 세션이 다시 브리핑받지 않고도 진행 중인 작업을 이어받습니다.
운영 환경에서 에이전트가 실패하면 어떻게 하나요?
무엇을 다시 만들기 전에, 먼저 이름을 붙일 수 있는 근본 원인까지 좁힙니다. 블랙박스 장애 대부분은 프로바이더 불일치, 플러그인 인증 만료, 세션 상태 드리프트, 툴 호출 충돌 같은 알려진 원인으로 수렴하고, 각각 문서화된 SOP가 있습니다.

이게 드러나는 곳.

어느 것도 추상적인 취향이 아니라, 각 사례에 실물이 있습니다. 에이전트 운영 시스템은 규약이 실제로 강제되는 곳이고, 캐릭터 라이브 런타임은 "다시 만들기 전에 진단하기"를 비싼 값에 배운 곳이며, 제품 데모 작업은 "증거 기반 검증"이 자기 비용을 회수하는 곳입니다.

실제 작업 보기