핵심 개념 2: 근거·자동화·결정

1. RAG — 등록은 저장이 아니라 감시다

문서를 에이전트의 근거로 쓰게 하는 절차는 “업로드”가 아니라 등록입니다. 이 차이가 전부입니다.

등록은 일회성 업로드가 아니라 감시입니다. 폴더를 소스로 등록하면 그 순간의 파일만 들어오는 게 아니라, 이후 추가되는 파일까지 주기적으로 자동 수집됩니다. 좋은 뜻으로 읽으면 “쌓아 나가는 자산”이고, 나쁜 뜻으로 읽으면 “누가 잘못된 문서를 넣어도 다음 주기부터 근거가 된다”는 뜻입니다.

수집과 임베딩은 별개 단계입니다. 문서가 들어오면 요약·엔티티·관계까지는 자동으로 추출되지만, 검색이 가능해지려면 임베딩이라는 별도 단계를 한 번 더 거쳐야 합니다. “등록했는데 검색이 안 된다”는 증상은 대개 여기서 멈춰 있습니다.

가장 중요한 관찰은 두 가지입니다.

도구를 명시하지 않으면 모델은 가장 가까운 길을 택합니다. 검색 도구 대신, 연결된 프로젝트 폴더에서 파일을 직접 찾아 읽어버립니다. 답의 내용은 맞을 수 있지만, 이 경로는 등록·검증되지 않은 문서도 근거로 쓰고, 애써 만든 요약·구획·임베딩을 전혀 거치지 않습니다. 등록된 지식을 쓰게 하려면 검색 도구를 명시해야 합니다 — 그러면 도구도 스킬처럼 필요할 때만 로드되는 것이 화면에 보입니다.

검색의 가장 위험한 실패 모드는 “결과 없음”이 아니라 “유사하지만 답이 아닌 문서”입니다. 라이브러리에 관련 문서가 없으면 검색은 빈손으로 오지 않고, 단어가 겹치는 엉뚱한 문서를 돌려줍니다. 이 원재료를 에이전트가 추측으로 짜맞추는지, 아니면 “근거 없음”으로 정직하게 보고하는지가 갈림길입니다. 그리고 이 거부는 저절로 보장되지 않습니다 — “없으면 없다고 말하고 추측하지 마”를 규칙으로 걸어 두지 않으면, 모델이나 상황이 바뀌었을 때 그럴듯한 오답이 만들어질 수 있습니다.

무엇을 등록할지 정하는 판별 질문은 하나입니다. 이 문서가 틀렸을 때, 누가 알아차리는가. 답이 없으면 등록하지 않습니다.

2. MCP — “연결됨”은 세 계층이다

에이전트가 처음부터 가진 도구만으로는 부족할 때가 있습니다. MCP(Model Context Protocol)는 에이전트와 외부 도구를 잇는 공개 표준입니다 — 세상에 공개된 MCP 서버는 형식만 맞으면 무엇이든 같은 방식으로 꽂을 수 있습니다.

여기서 중요한 것은 “연결됨”이라는 말이 실제로는 세 계층으로 나뉘어 있다는 사실입니다.

서버가 온라인이어도 첫 번째 계층일 뿐입니다. 두 번째·세 번째 계층까지 연결해야 세션이 실제로 그 도구를 씁니다. “그런 도구는 없다”는 답을 받으면 에이전트가 거짓말을 하는 게 아니라, 계층 어딘가가 아직 안 이어진 것입니다 — 그리고 도구가 없으면 에이전트는 셸 명령 같은 다른 길로 우회하려 듭니다.

도구를 꽂을지 말지의 기준도 명확합니다. 모델은 자기가 할 수 있는 일에는 도구를 쓰지 않습니다. 시간 계산처럼 모델 스스로 할 수 있는 일은 도구 없이 직접 계산해 버립니다. 도구가 진짜 필요해지는 것은 모델이 원리로는 알 수 없는 일 — 실시간 데이터, 조직 내부 문서, 지금 이 순간의 외부 시스템 상태 — 일 때입니다. 도구를 심기 전에 “이건 모델이 못 하는 일인가”부터 물어야 합니다.

3. 루프 — 모호함은 사라지지 않는다

자동화 루프는 설명 → 명세 → 계획(DAG) → 실행 → 검증 순서로 흐릅니다. 이 흐름에서 가장 중요한 원칙 하나가 전체를 지배합니다.

모호한 문장은 각 단계 사이에서 확정되거나, 확정되지 않은 채 다음 단계로 미뤄집니다. 그리고 미뤄진 모호함은 사라지지 않습니다 — 더 늦게, 더 안 보이는 곳에서 반드시 확정됩니다. 사람이 쓴 설명이 모호하면 명세 정제 단계가 조용히 하나의 해석을 골라 확정하거나, 그마저도 못 하면 실행 계획 단계가 태스크 지시문 속에서 확정합니다. 검토가 늦어질수록 발견도 늦어집니다 — 그래서 가장 싼 개입 지점은 언제나 가장 이른 단계입니다.

실행에는 몇 가지 구조적 장치가 있습니다.

• 격리 — 실행은 원본이 아니라 복제된 미러에서 이뤄집니다. 실패해도 원본은 다치지 않지만, 그 대가로 결과를 원본에 반영하는 것은 별도로 챙겨야 하는 일이 됩니다.
• 자동 분해 — 의존성이 없는 작업은 계획 단계가 스스로 병렬로 배치하고, 완료 조건이 있으면 최종 검증 단계까지 스스로 추가합니다.
• 재시도 예산 — 각 작업에는 정해진 재시도 횟수가 있습니다.

검증에도 함정이 있습니다. 검증 루프 자체가 일을 만들고, 그 일이 다른 제약을 어길 수도 있습니다. “산출물을 남겨라”는 검토 요구가 “이 파일 하나만 만들어라”는 명세와 충돌하면, 에이전트는 검토를 따르다 명세를 어길 수 있습니다. 그리고 검증은 계획에 오른 것만 검증합니다. 완료 조건에 없는 제약은 실행에서 어겨져도 통과됩니다 — 그래서 명세 검토는 완료 조건까지 끝까지 읽어야 끝납니다.

마지막으로, 성공 보고를 읽는 습관이 있습니다. “무엇이 성공했는가”와 “그래서 결과가 어디에 남았는가”는 함께 읽어야 합니다. 격리된 실행이 완료되면 미러가 정리되면서, 완료 조건에 최종 위치가 명시되지 않은 산출물은 흔적도 없이 사라질 수 있습니다. 반대로 완료 조건에 최종 위치까지 올라 있으면, 시스템은 그 의도를 원본에 반영하는 절차까지 스스로 만들어냅니다. 결국 루프의 품질은 명세의 품질입니다 — 모호한 설명으로 시작해 무엇이 깨지는지 보는 게 아니라, 처음부터 정확히 쓰는 것이 실무의 순서입니다.

4. 스케줄링 — 등록은 절반이다

루프를 시간에 걸면 자동화가 됩니다. 그런데 시간이 실행을 시작시키는 순간, 이전 랩까지는 없던 문제가 하나 생깁니다 — 그 시각에는 승인을 눌러줄 사람이 없습니다.

이 문제에 대한 답은 잡마다 정하는 정책입니다. 승인 대기(Default)는 안전하지만, 아무도 눌러주지 않으면 시간을 흘려보내다 “확인 불가”로 끝날 수 있습니다. 자동 승인(Auto-approve)은 빠르지만 무엇을 하든 묻지 않습니다. 같은 작업이 승인 대기에서는 수 분을 허비하다 실패로 끝나고, 자동 승인에서는 수십 초 만에 실제 결과를 냅니다 — 정책 하나가 결과 자체를 가릅니다. 판별 기준은 그 잡이 시킬 수 있는 일의 범위입니다. 읽기만 하는 잡은 자동 승인을 열어도 되지만, 쓰거나 지우거나 외부로 보내는 잡이라면 자동 승인은 그 일이 아무도 없는 시각에 검토 없이 실행된다는 뜻입니다.

등록은 자동화의 절반일 뿐입니다. 나머지 절반은 첫 실행을 직접 확인하는 것입니다 — 트리거가 무엇이었고, 승인은 어떻게 처리됐고, 보고된 결과가 실제로 확인된 사실인지 확인 불가였는지까지. 이 확인을 습관으로 만들지 않으면 실패는 아무도 모르게 반복됩니다. 화면도 세 가지 시제로 나뉘어 이 확인을 돕습니다 — 진행 중인 것, 이미 끝난 것, 앞으로 예정된 것을 각각 다른 곳에서 봅니다.

안전한 무인 자동화를 설계할 때 참고할 만한 원칙 몇 가지도 확인됩니다.

• 위험한 기능은 기본값이 꺼져 있고, 이름 자체에 경고가 들어 있습니다.
• 전체 신뢰처럼 강력한 권한도 무기한이 아니라 일정 시간 뒤 만료됩니다.
• 무인 실행에는 시간 초과·멈춤 감지·자원 하한 같은 한도가 붙습니다 — 사람이 지켜보지 않으므로 멈춰 줄 사람이 없기 때문입니다.
• 외부 채널 연동은 기능보다 허용 목록이 먼저입니다 — 목록이 비어 있으면 아무도 쓸 수 없습니다.

5. HITL — 승인과 결정은 다르다

지금까지 여러 번 승인 카드를 눌렀습니다. 그런데 그 승인이 곧 사람의 개입(Human-in-the-Loop)의 전부는 아닙니다. 승인과 결정은 다른 층에 있습니다.

승인은 “파일을 읽어도 되는가” 같은 수단에 대한 예/아니오이고, 반복되면 자동 승인 목록에 넣어 결국 사라지는 개입입니다. 결정은 “이 결과를 릴리스할 것인가” 같은 목적에 대한 선택이고, 판단의 재료는 에이전트가 모아도 최종 선택의 책임은 사람에게 남습니다. 자동 지표는 판단 자료이지 판단이 아닙니다 — 테스트 통과율이 아무리 높아도, 그것이 조직이 정한 성공 기준과 다른 이야기라면 결정하는 것은 사람입니다.

이 구분이 실제로 작동하려면 몇 가지가 갖춰져야 합니다.

• 병렬 위임의 승인은 한 층이 아니라 두 층입니다 — 여러 작업을 동시에 맡기는 행위 자체와, 맡겨진 작업 각각이 따로 승인 대상입니다. 병렬화는 속도만이 아니라 승인 비용도 함께 늘립니다.
• 부분 실패의 대응은 한 가지가 아니라 세 갈래입니다 — 실패한 것만 다시 시키기, 개별 중단, 전체 중단. “하나가 실패했으니 전부 다시”가 기본값이 아닙니다.
• 실패는 숨기지 않고 전제로 밝혀야 합니다. 그렇지 않으면 사람은 모든 작업이 정상이었다고 오해한 채 결정을 내리게 됩니다.
• 판단 지점은 저절로 생기지 않습니다. 승인 카드는 런타임이 강제하지만, 질문 카드는 에이전트가 명시적으로 그렇게 하도록 설계했을 때만 나타납니다 — 설계하지 않으면 에이전트는 스스로 결정해 버립니다.
• 결정은 아티팩트로 남겨야 세션 밖에 남습니다. 대화는 세션이 닫히면 사라지지만, 아티팩트는 버전 이력을 갖고 세션과 무관하게 다시 조회할 수 있습니다.

정리

다섯 가지는 결국 하나로 모입니다. 에이전트가 다루는 근거·도구·자동화·시간·결정 각각에 통제 지점이 있고, 그 지점을 설계하는 것이 시스템을 만드는 일의 실체입니다. 등록된 지식만 근거가 되고, 도구는 계층을 다 갖춰야 실제로 연결되고, 명세에 없는 의도는 루프 어딘가에서 사라지고, 무인 실행은 정책 하나로 결과가 갈리고, 결정은 설계하지 않으면 자동으로 사람을 건너뜁니다. Lab 1~3의 정리가 에이전트 한 대의 구성이었다면, 여기서는 그 에이전트를 신뢰하고 맡기는 범위를 어떻게 설계하는가를 다뤘습니다.