에이전트 운영 Q&A — 환각·비용·실행 권한, 그리고 조직이 바뀌는 지점 22문답

돌아가는 에이전트와 운영할 수 있는 에이전트는 다르다. 차이를 만드는 것은 대개 세 가지다 — 검증이 실제로 무엇을 보장하는가, 언제 멈추는가, 무엇을 실행할 수 있는가.

이 글은 그 셋과, 그다음에 오는 질문을 다룬다. 에이전트를 도입하면 조직이 무엇을 바꿔야 하는가다. 마지막 세 문항이 그 축이다.

프레임워크 선택은 기본기 Q&A, 상태·도구·체크포인터는 실행 모델 Q&A, 분할 경계와 토폴로지는 멀티에이전트 Q&A에 있다.

종료 조건 4겹

사이클 그래프에서 "언제 멈추는가"는 기능이 아니라 아키텍처다. 한 겹만 두면 그 겹이 뚫릴 때 대안이 없다.

Q. 검증 노드를 붙이면 환각이 없어지나

없어지지 않는다. 측정되는 것은 사실성이 아니라 groundedness — 답변이 검색된 문서와 어긋나지 않는가다.

문서 자체가 오래되었거나 틀렸다면, 그 오류를 충실히 옮긴 답변은 "근거 있음"으로 통과한다. 정확히 말하면 이 구조가 하는 일은 근거 없는 답변이 사용자에게 도달하는 경로를 차단하는 것이다.

Q. "환각 0"이라는 표현은 왜 위험한가

측정 가능한 주장이라 검증 근거를 요구받기 때문이다.

세 가지가 겹친다. 코드가 실제로 재는 것은 groundedness이고, 판정자도 생성기와 같은 계열 모델이라 자기채점의 순환 문제가 남으며, "0"을 뒷받침할 데이터가 대개 없다.

보장 범위를 좁혀 쓰면 그 안에서는 주장이 성립한다. 넓히면 근거가 따라가지 못하고, 근거가 없으면 좁은 주장까지 함께 흔들린다. 한계 다섯 가지는 groundedness와 그 대가에 있다.

Q. 환각 대응을 어떻게 하나

두 방향이다.

실무는 둘을 함께 쓴다. 입력만 손보면 검색이 빗나갔을 때 막을 것이 없고, 출력만 손보면 판정 비용이 계속 붙는다.

Q. 판정도 LLM인데 판정이 틀리면 어떻게 하나

이 구조의 상한이 판정기 품질이다.

완화책은 다른 계열 모델을 판정기로 쓰거나, 사람 라벨로 판정기를 주기적으로 검증하는 것이다.

Q. LLM이 자기 확신도를 정확히 알 수 있나

아니다. 캘리브레이션되지 않은 자기보고값이다.

그래서 확신도 단독으로 분기하지 않고 뒤에 충분성 판정을 한 겹 더 두는 다단 판정이 필요하다. 확신도를 임계값으로 쓰는 라우팅 설계는 코딩 에이전트의 동적 RAG 라우팅에 있다.

Q. 답이 확신에 차서 틀렸을 때는 어떻게 하나

프롬프트를 고치는 것이 아니라 구조로 분리한다.

종합 단계에서 도구를 제거하고, 검토 단계를 삽입하고, 출력을 스키마로 강제한다. "더 신중하게 답하라"는 지시는 재현되지 않는다.

Q. 인용의 신뢰성은 어떻게 보장하나

소스에 ID를 부여해 상태에 남기지 않으면 검증할 대상 자체가 없다.

도구가 문자열을 반환하는 순간 소스 경계가 사라진다 — 그 지점의 상세는 Focus 라우팅과 인용 정합성에 있다.

Q. 개선을 무엇으로 측정하나

"환각률을 얼마나 줄였나"에 숫자로 답하려면 먼저 측정 체계가 있어야 한다. 없으면 측정 설계로 답하는 것이 정확하다.

평가 지점과 메트릭을 3계층으로 나누는 방법은 "에이전트 잘 되나요"는 답할 수 없는 질문이다에서 다룬다.

Q. 에이전트의 비용과 지연을 어떻게 통제하나

상한을 다층으로 걸고, 구조를 세 방향으로 손본다.

그리고 병렬화는 지연만 줄이고 비용은 줄이지 않는다.

Q. 어디에 비싼 모델을 쓰나

결과물 품질이 걸린 곳에만 쓴다.

첫 행이 요점이다. 순서가 정해진 구간에 LLM 라우터를 쓰면 비용과 비결정성을 함께 얻는다.

Q. 무한 루프는 어떻게 막나

재귀 한도는 안전벨트지 설계가 아니다.

실제 해법은 종료 조건 명문화 + 호출 횟수 카운터 + 정체 감지다. 위의 종료 조건 4겹이 그 형태다.

Q. 재귀 한도에 걸리면 값을 올리면 되나

올리기 전에 왜 안 끝나는지를 본다.

한도에 걸린다는 것은 종료 조건이 부실하다는 신호다. 값만 올리면 같은 실패를 더 비싸게 반복한다.

Q. 재시도 카운터는 어디에 두나

지역변수가 아니라 그래프 State에 둔다.

체크포인트 복원 시 살아남아야 하고, 스트리밍 UI가 읽어야 하기 때문이다. 함수 안에 두면 재개할 때 0으로 돌아간다.

Q. 실패를 언제 사람에게 넘기나

다섯 가지 신호가 있다 — 시도 소진, 동일 오류 반복, 환경 문제, 파괴적 조작, 요구 모호.

넘길 때 시도 이력과 마지막 오류를 함께 전달한다. 결과만 넘기면 받는 사람이 처음부터 다시 재현해야 한다.

Q. LLM이 만든 코드를 서버에서 실행해도 되나

실행기가 붙는 순간 신뢰 경계가 무너지는 지점이 생긴다.

실행기가 없으면 최악의 사고가 "틀린 문장"이지만, 붙으면 "파일 삭제"와 "자격증명 유출"이 된다. 그리고 검색 결과를 컨텍스트에 넣는 구조라면 프롬프트 인젝션이 곧 코드 실행이 된다.

Q. 작업 디렉터리를 지정하면 격리인가

아니다. 저장 폴더 설정일 뿐 보안 경계가 아니다.

상위 경로 접근을 막지 못한다. 이 오해가 "격리했다"는 착각으로 이어져 다른 통제를 생략하게 만든다. 격리 4등급과 각 등급의 한계는 실행 권한을 주는 순간에 있다.

Q. 노트북으로 만든 것을 팀에 전파할 때 무엇을 조심하나

노트북은 코드 셀과 출력 셀 양쪽이 유출 경로다.

코드에 키를 안 썼어도 실행 결과에 환경변수가 찍혀 남는 일이 흔하다. 통제는 둘이면 충분하다 — CI에 시크릿 스캐너를 걸어 커밋 시점에 막고, 토큰은 코드 밖에 둔다.

Q. 벡터 인덱스 캐시는 어떻게 관리하나

키에 소유자까지 포함해 동명 충돌을 막고, 원본 리비전을 메타데이터에 저장해 변경 시 재임베딩한다.

무효화 없는 영구 캐시는 기능이 아니라 결함이다. 문서를 고쳤는데 옛 답이 계속 나오는 사고가 여기서 나온다.

무효화 방식 네 가지와 TTL 설계 원칙은 캐시 무효화와 동시성에 정리해 두었다.

Q. AI 에이전트가 개발조직 구조를 어떻게 바꾸나

일하는 단위가 바뀐다.

지금까지 조직은 기능 단위로 사람을 배치했다. 에이전트가 실행을 가져가면 사람은 검증 가능한 작업으로 일을 쪼개고 결과를 판정하는 쪽으로 이동한다.

조직도를 다시 그리기 전에 볼 것이 둘 있다.

도입 순서는 파일럿 2주 → 최적화 4주 → 확산으로 잡고, 성공 지표를 도구 사용률이 아니라 변경 리드타임·재작업률·변경 실패율로 둔다. 도구를 얼마나 썼는지는 성과가 아니다.

역할을 세 층으로 다시 나누는 구체적 프레임은 도입 사례와 AX 실행 프레임워크에, 확산 방식은 표준을 강제하지 말고 seed를 주라에 있다.

Q. 팀 생산성을 AI로 어떻게 끌어올리나

자사 베이스라인을 재는 것이 먼저다.

도입 전 리드타임과 재작업률을 모르면 나중에 좋아졌다고 말할 근거가 없다. ROI를 묻기 전에 측정 체계부터 만드는 것이 순서다.

그다음이 적합 업무 선정이다. 반복적이고, 결과를 기계적으로 검증할 수 있고, 실패해도 되돌릴 수 있는 일부터 넘긴다. 여기서 중요한 것은 공통 규칙은 엄격하게, 개인 작업 방식은 느슨하게 두는 것이다. 팀 표준을 개인에게 강제하면 도입이 멈춘다.

그리고 반드시 함께 설계하는 것이 가드레일이다. 생산성 루프는 그대로 공격 표면 루프이기도 해서, 부작용을 내는 도구 바로 옆에 승인 지점을 놓는다. 에이전트 레벨 가드레일만 믿지 않는다.

90일 로드맵과 15개 실행 항목은 seed와 fork 편에, 거버넌스 설계는 자기진화 루프와 비대칭 거버넌스에 있다.

Q. 조직에 코딩 에이전트를 도입한다면 무엇부터 정하나

모델 선택보다 권한 등급 설계가 먼저다.

읽기 → 로컬 실행 → 쓰기 → 배포 순으로 나누고 등급마다 게이트를 다르게 둔다. 어느 등급까지 열 것인지가 정해지지 않은 상태에서 도입하면 그 자체가 리스크다.

Q. 최근의 흐름 중 무엇을 눈여겨볼 만한가

Agent Harness와, 그것이 확장된 Loop Engineering이다.

출발점은 문제 제기다. 모델은 상향 평준화됐는데 만들어 둔 에이전트 성능은 비례해서 좋아지지 않는다. 원인이 모델이 아니라 모델을 감싼 실행 구조가 배포 시점에 고정돼 있다는 것이다. Agent = Model + Harness인데 그동안 모델만 봤다는 진단이다.

실제로 모델을 고정한 채 하네스만 바꿔 벤치마크가 오른 사례가 보고됐다. 핵심 메커니즘은 컨텍스트를 파일로 밀어내고 필요할 때 다시 읽는 것 — 컨텍스트 관리가 곧 성능이라는 관점이다.

이것이 Loop Engineering으로 확장됐다. 모델 호출 이후를 설계하는 것 — 실패하면 무엇이 멈추고, 무엇이 기록되고, 누가 승인하며, 어떤 증거로 성공을 판단하는가다. 여기가 중요한 이유는 기술 주제가 아니라 조직 운영 주제이기 때문이다.

두 축은 Agent Harness 편과 Agent = Model + Harness에서 각각 다룬다.

용어 정리

네 편으로 나눈 문답은 여기서 끝난다. 각 문항의 근거가 되는 구조와 코드는 본문 시리즈에 있고, 어느 편부터 읽을지는 카테고리 지도에서 고르면 된다.