Isolate 컨텍스트를 분리하라

긴 일을 하는 AI를 설계할 때 사람들은 자주 같은 유혹에 빠집니다. 많이 넣으면 더 잘하겠지라는 생각입니다. 사용자 정보도 넣고, 정책 문서도 넣고, 최근 대화도 넣고, 도구 설명도 넣고, 에러 로그도 넣고, 예전 작업 메모도 넣습니다. 겉으로 보면 든든합니다. 빠진 것이 없어 보이기 때문입니다.

그런데 이상하게도 이런 시스템은 종종 더 멍청하게 보입니다. 질문 하나에 대답하면서 엉뚱한 정책을 들고오고, 지금 필요한 작업보다 이전 대화의 분위기에 끌려가고, 한쪽에서는 "반드시 간단히 답하라"고 하고 다른 쪽에서는 "가능한 한 자세히 분석하라"고 해서 스스로 충돌합니다. 정보가 부족해서가 아니라, 너무 많은 것이 한 공간에서 서로 방해하기 때문입니다.

Write는 흔적을 남기는 기술이었고, Select는 필요한 것을 고르는 기술이었고, Compress는 길어진 맥락을 다시 정돈하는 기술이었습니다. 이제 남은 질문은 이것입니다. 애초에 왜 다 한곳에 넣으려 하는가? Isolate는 이 질문에서 출발합니다. 중요한 것을 잘라 버리는 것이 아니라, 서로 다른 목적의 맥락을 분리해서 안전하고 선명하게 쓰는 설계입니다.

분리는 축소가 아니라 질서다

Isolate를 처음 들으면 어떤 사람은 이렇게 이해합니다. "덜 넣으라는 말이구나." 절반만 맞는 말입니다. 더 정확히 말하면 Isolate는 덜 넣는 기술이라기보다, 섞지 말아야 할 것을 섞지 않는 기술입니다.

예를 들어 고객지원 챗봇이 있다고 해 봅시다. 이 시스템에는 최소한 네 종류의 정보가 들어옵니다. 고객이 방금 한 질문, 회사의 최신 정책, 고객 계정 상태, 내부 상담 매뉴얼입니다. 이 네 가지는 모두 중요하지만 성격이 다릅니다. 고객 질문은 지금 처리해야 할 사건이고, 정책은 정답의 기준이며, 계정 상태는 개인화된 사실이고, 상담 매뉴얼은 운영 절차입니다. 이것들을 한 덩어리 텍스트로 길게 합쳐 두면 AI는 필요한 순간에 무엇이 규칙이고 무엇이 사례인지 헷갈리기 쉽습니다.

분리의 핵심은 간단합니다. 같은 화면에 보이더라도, 같은 종류의 정보처럼 다루지 않게 만드는 것입니다. 규칙은 규칙답게, 상태는 상태답게, 도구는 도구답게, 기억은 기억답게 다뤄야 합니다.

모든 것을 한곳에 모으면 생기는 문제

한곳에 다 넣는 방식은 처음에는 편합니다. 설계가 단순해 보이고, 빠르게 데모를 만들기 좋습니다. 하지만 시스템이 조금만 커지면 문제가 터집니다.

첫째, 지시가 충돌합니다. 시스템 프롬프트에서는 정중하고 짧게 답하라고 했는데, 이전 대화 요약에는 자세한 비교 분석을 선호한다고 적혀 있고, 현재 작업 요청은 한 문단 이내로 끝내 달라고 말할 수 있습니다. 분리가 없으면 AI는 어느 신호를 더 우선해야 하는지 흐리게 받아들입니다.

둘째, 관련 없는 정보가 집중력을 흐립니다. 코딩 에이전트가 버그를 고쳐야 하는데 제품 브랜딩 문서, 팀 회고 메모, 지난주 회의 잡담까지 함께 들어오면 핵심 문제를 보는 힘이 약해집니다. 사람도 책상 위에 모든 서류를 펼쳐 놓고 일하면 오히려 느려집니다.

셋째, 민감 정보가 불필요하게 퍼집니다. 일정 조정만 하면 되는 비서형 AI가 사용자의 상세 인사 정보나 결제 정보까지 항상 들고 있을 이유는 없습니다. 그런데 한 통합 컨텍스트에 다 담아 두면, 원래 필요 없던 작업에도 민감한 데이터가 함께 노출됩니다.

넷째, 오류가 전염됩니다. 하나의 대형 프롬프트 안에 잘못된 사실이나 오래된 규칙이 들어 있으면, 그 정보가 여러 종류의 작업에 동시에 영향을 줍니다. 분리된 구조에서는 문제 구역만 고치면 되지만, 뭉쳐 있는 구조에서는 어디까지 오염되었는지 추적하기 어렵습니다.

이쯤 되면 Isolate는 성능 최적화 기법이라기보다, 혼선을 줄이는 기본 위생 습관에 가깝습니다.

Isolate는 작업 공간을 나누는 설계다

사람은 일을 할 때도 머릿속 작업 공간을 나눕니다. 계약서를 검토할 때는 마케팅 카피를 쓰는 감각을 잠시 내려놓고, 일정 조율을 할 때는 기술 설계 문서를 옆으로 치웁니다. AI 시스템도 마찬가지입니다. 한 모델이 여러 일을 할 수 있다고 해서, 모든 일을 같은 컨텍스트 안에서 동시에 잘하는 것은 아닙니다.

그래서 실무에서는 하나의 거대한 두뇌를 만드는 생각보다, 작업별 워크스페이스를 만드는 생각이 더 유용합니다. 워크스페이스란 단지 별도 채팅창을 뜻하지 않습니다. 그 작업에 필요한 목표, 규칙, 데이터, 도구, 기억의 범위를 따로 정하는 구조를 말합니다.

예를 들어 문서 작성 에이전트의 워크스페이스에는 독자, 톤, 참고 자료, 초안 상태, 수정 지시가 중심이 됩니다. 반면 데이터 분석 에이전트의 워크스페이스에는 데이터 스키마, 계산 규칙, 쿼리 결과, 검증 조건이 중심이 됩니다. 두 시스템 모두 같은 조직에서 쓰이더라도, 둘의 컨텍스트는 섞일수록 불리합니다.

Isolate의 질문은 늘 이렇습니다. 이 정보는 지금 이 작업 공간에 꼭 있어야 하는가, 아니면 다른 방에 있어야 하는가?

역할별 워크스페이스를 설계하는 법

역할별 워크스페이스는 AI에게 "너는 누구인가"를 말하는 것에서 끝나지 않습니다. 더 중요한 것은 너는 지금 어떤 재료만 보고 판단해야 하는가를 정하는 일입니다.

예를 들어 하나의 비즈니스 어시스턴트 안에 다음 역할이 있다고 합시다.

• 일정 조정 담당

• 이메일 초안 작성 담당

• 회의 요약 담당

• 비용 정산 확인 담당

이 네 역할은 모두 비서형 AI처럼 보이지만, 실제로 필요한 컨텍스트가 다릅니다. 일정 조정은 캘린더 상태와 참석자 우선순위가 핵심이고, 이메일 초안은 상대방 맥락과 톤 가이드가 중요합니다. 회의 요약은 녹취와 결정 사항이 중심이며, 비용 정산은 영수증 규칙과 승인 정책이 중심입니다.

이때 좋은 설계는 하나의 초대형 프롬프트를 만들고 그 안에 네 역할을 다 설명하는 것이 아닙니다. 대신 역할별로 따로 작업 공간을 만들고, 공통으로 필요한 정보만 좁게 공유합니다. 예를 들어 사용자 이름, 기본 톤 선호, 조직 기본 규칙 정도만 공통 계층에 두고, 나머지는 역할 전용 공간으로 보냅니다.

이 구조의 장점은 분명합니다. 일정 조정 작업이 갑자기 비용 정산 규칙에 끌려가지 않고, 이메일 작성이 회의 요약의 형식 규칙에 묶이지 않습니다. 각각이 자기 일에 더 집중할 수 있습니다.

큰 에이전트 하나보다 작은 에이전트 여러 개가 나을 때

많은 팀이 처음에는 "만능 에이전트"를 꿈꿉니다. 모든 질문에 답하고, 모든 도구를 쓰고, 모든 문서를 읽고, 모든 상황을 기억하는 AI 말입니다. 데모에서는 멋집니다. 하지만 운영에 들어가면 만능은 자주 만능이 아닙니다. 너무 많은 역할을 한 몸에 얹으면, 판단 기준이 흐려지고 실패 원인도 찾기 어려워집니다.

작은 에이전트는 이 문제를 정면으로 피합니다. 작은 에이전트란 기능이 약한 에이전트가 아니라, 목표와 권한과 컨텍스트 범위가 좁은 에이전트입니다.

예를 들어 리서치 시스템을 설계한다고 합시다. 하나의 에이전트가 질문 분해, 검색 쿼리 생성, 자료 선별, 근거 요약, 최종 보고서 작성까지 전부 하게 만들 수 있습니다. 하지만 더 안정적인 방식은 이를 나누는 것입니다. 질문을 구조화하는 에이전트, 근거를 모으는 에이전트, 초안을 쓰는 에이전트, 출처와 주장을 검토하는 에이전트를 따로 두는 식입니다.

이렇게 나누면 각 단계의 컨텍스트도 달라집니다. 검색 단계는 넓게 보는 것이 중요하고, 검토 단계는 정확한 근거 대조가 중요합니다. 둘을 같은 창에 밀어 넣으면 "넓게 보기"와 "엄격하게 확인하기"가 같은 순간에 충돌합니다. 반면 분리하면 각 에이전트는 자기 방식으로 더 선명하게 일합니다.

작은 에이전트 설계가 특히 유리한 경우는 다음과 같습니다.

• 작업 단계마다 필요한 정보 종류가 다를 때

• 단계마다 권한 범위를 다르게 줘야 할 때

• 실패 원인을 추적하고 교정해야 할 때

• 민감 정보 접근을 최소화해야 할 때

핵심은 작게 쪼개기 자체가 목적이 아니라, 한 번에 한 종류의 판단만 하게 만드는 것입니다.

분리는 안전을 만든다: 민감 정보 격리

Isolate가 특히 빛나는 곳은 보안과 프라이버시입니다. AI 시스템이 다루는 데이터는 종종 성격이 다릅니다. 공개 가능한 제품 문서도 있고, 내부 운영 매뉴얼도 있고, 고객 개인정보도 있고, 재무 정보도 있습니다. 이 모든 것을 언제나 같은 컨텍스트 경로로 태워 보내면 사고는 언젠가 납니다.

민감 정보 격리의 기본 원칙은 단순합니다. 필요한 순간에만, 필요한 범위만, 필요한 역할에게만 보여 줍니다.

예를 들어 고객지원 챗봇이 배송 지연 문의를 받았다고 해 봅시다. 답변에 필요한 것은 주문 상태와 배송 정책일 수 있습니다. 이때 고객의 전체 결제 내역, 다른 주문 기록, 내부 사기 탐지 점수까지 같이 볼 필요는 없습니다. 필요한 필드만 추출한 안전한 상태 정보가 더 낫습니다.

민감 정보를 격리할 때 실무적으로 자주 쓰는 방법은 이렇습니다.

• 원본 데이터 저장소와 AI 작업 컨텍스트를 분리한다.

• AI에는 원문 전체 대신 필요한 필드나 요약된 상태만 넘긴다.

• 작업 종류에 따라 접근 가능한 데이터 범위를 다르게 둔다.

• 민감 정보를 본 단계와 보지 않은 단계를 로그로 구분한다.

여기서 중요한 것은 "모델이 믿을 만하냐"가 아닙니다. 시스템은 실수할 수 있고, 사람이 잘못 연결할 수도 있습니다. 그래서 신뢰보다 먼저 필요한 것은 경계입니다.

충돌을 막는 구조가 필요하다

AI가 이상한 답을 낼 때 우리는 종종 모델의 추론 능력을 의심합니다. 그러나 실제로는 추론 이전에 이미 입력 구조가 엉켜 있는 경우가 많습니다. 가장 흔한 문제는 서로 다른 층위의 정보가 한 문단 안에서 섞이는 것입니다.

예를 들어 이런 식입니다. "당신은 친절한 고객지원 상담사다. 환불은 7일 이내만 가능하다. 단 VIP는 30일까지 허용될 수 있다. 사용자는 자세한 설명을 싫어한다. 하지만 모든 예외 조항을 자세히 설명하라. 내부적으로는 우선 고객을 유지하는 방향으로 설득하라. 고객이 화가 나 있으면 더 짧게 답하라." 이 텍스트는 정보가 많지만, 역할, 정책, 사용자 선호, 내부 목표, 상황별 예외가 뒤섞여 있습니다.

좋은 구조는 이런 요소를 층위별로 나눕니다.

• 상위 규칙: 절대 어기면 안 되는 정책과 금지 사항

• 역할 규칙: 이 작업에서 수행할 역할과 책임

• 상황 상태: 지금 고객이 누구이고 무슨 상태인지

• 사용자 선호: 있으면 반영하되 상위 규칙보다 아래인 항목

• 출력 과제: 이번 턴에서 만들어야 할 결과물

이렇게 층을 나누면 충돌이 생겨도 어디서 해결해야 하는지 보입니다. 예를 들어 사용자 선호가 "짧게 답해 달라"여도 상위 규칙이 "환불 불가 사유와 이관 절차는 반드시 포함"이라면, 시스템은 짧되 필요한 필수 항목은 남기는 방향으로 판단할 수 있습니다.

분리 없는 시스템은 모든 목소리가 동시에 소리치는 회의실 같고, 분리된 시스템은 발언 순서가 정리된 회의실 같습니다.

도구도 분리해서 다뤄야 한다

도구를 많이 연결할수록 Isolate의 중요성은 더 커집니다. AI가 검색, 이메일 발송, 데이터 조회, 코드 실행, 캘린더 수정까지 할 수 있다면 똑똑해 보이지만, 실제로는 각 도구가 서로 다른 위험을 가집니다.

예를 들어 일정 조회 도구와 일정 수정 도구는 이름이 비슷해도 성격이 완전히 다릅니다. 하나는 읽기 권한이고, 다른 하나는 쓰기 권한입니다. 이를 같은 작업 공간에서 무분별하게 열어 두면, 단순 확인 작업이 실수로 변경 작업으로 이어질 수 있습니다.

그래서 실무에서는 도구도 역할별로 격리하는 편이 좋습니다. 초안 작성 에이전트는 메일을 바로 보내지 못하고 초안만 만들게 하고, 최종 승인 단계의 다른 에이전트나 사람이 실제 발송을 맡는 방식이 대표적입니다. 코딩 에이전트도 코드 읽기, 테스트 실행, 배포 실행을 같은 권한으로 묶기보다 단계적으로 나누는 편이 안전합니다.

도구 격리는 성능을 떨어뜨리는 제약처럼 보일 수 있습니다. 하지만 오히려 그 반대입니다. 무엇을 할 수 없는지가 분명할수록, 에이전트는 자기 역할 안에서 더 안정적으로 움직입니다.

핸드오프는 많이 넘기는 것이 아니라 잘 넘기는 것이다

작은 에이전트 여러 개를 쓰면 자연스럽게 문제가 하나 생깁니다. 정보를 어떻게 넘길 것인가입니다. 여기서 흔한 실수는 앞 단계의 전체 대화와 전체 로그와 전체 메모를 다음 단계에 통째로 넘기는 것입니다. 그렇게 하면 겉으로는 분리한 것 같아도 실제로는 다시 합쳐 버린 셈입니다.

좋은 핸드오프는 "모든 것 전달"이 아니라 목적에 맞는 상태 전달입니다. 다음 단계가 꼭 알아야 할 것만 구조적으로 넘겨야 합니다.

예를 들어 초안 작성 에이전트에서 검토 에이전트로 넘길 때는 이런 정보면 충분할 수 있습니다.

• 문서 목적

• 독자와 톤

• 반드시 포함해야 할 주장

• 인용 또는 근거가 필요한 문장 목록

• 작성자가 확신하지 못한 부분

반대로 검토 에이전트가 초안 작성 중의 사소한 망설임, 삭제된 문장 후보, 실험용 표현까지 전부 볼 필요는 없습니다. 핸드오프의 품질은 친절함이 아니라 절제에서 나옵니다.

좋은 분리 설계에서는 각 워크스페이스가 자기 내부에서는 풍부할 수 있어도, 경계를 넘을 때는 더 엄격해집니다. 문을 통과할 때는 짐 검사를 하는 셈입니다.

실전 예시: 고객지원 시스템을 분리해서 설계해 보기

한 회사가 환불과 배송 문의를 처리하는 고객지원 AI를 만든다고 가정해 봅시다. 처음 설계는 보통 이렇게 시작합니다. 최신 정책 문서, 과거 상담 로그, 고객 계정 정보, 상담원 매뉴얼, 응대 톤 가이드를 한 에이전트에 넣고 "알아서 답해 달라"고 하는 방식입니다.

초기에는 그럴듯하게 돌아갑니다. 하지만 곧 문제가 생깁니다. 배송 문의에 환불 정책 예외가 불필요하게 길게 붙고, VIP 고객 규칙이 일반 고객에게 섞이고, 내부 상담원용 표현이 고객 답변에 드러납니다.

Isolate 관점으로 다시 설계하면 구조가 달라집니다.

먼저 질문 분류 단계가 있습니다. 이 단계는 고객 질문만 보고, 배송인지 환불인지 계정 문제인지 구분합니다. 여기에는 상세 정책이 많이 필요하지 않습니다.

그다음 정책 조회 단계가 있습니다. 이 단계는 분류 결과에 따라 해당 정책만 불러옵니다. 배송 문의라면 배송 정책과 주문 상태만 보고, 환불 문의라면 환불 정책과 예외 규칙만 봅니다.

그다음 응답 작성 단계가 있습니다. 이 단계는 고객에게 보여 줄 언어를 만드는 역할만 맡습니다. 내부 운영 메모는 보지 않고, 고객에게 전달 가능한 사실과 절차만 받습니다.

마지막으로 이관 판단 단계가 있습니다. 정책상 애매하거나 감정적으로 민감한 상황이면 사람 상담으로 넘깁니다. 이 단계는 "답변 품질"보다 "위험 회피"가 우선인 별도 공간입니다.

이렇게 나누면 전체 시스템이 오히려 더 똑똑해집니다. 이유는 간단합니다. 각 단계가 자기 일만 보기 때문입니다.

작은 방을 많이 만든다고 복잡해지기만 할까

분리를 싫어하는 사람들은 종종 이렇게 말합니다. "그렇게 나누면 관리가 더 복잡하지 않나?" 맞는 말입니다. 분리는 어느 정도의 설계 비용을 요구합니다. 워크스페이스를 나누고, 경계를 정의하고, 핸드오프 형식을 만들어야 합니다.

하지만 복잡함에는 두 종류가 있습니다. 보이는 복잡함과 숨은 복잡함입니다. 분리 설계는 처음에 보이는 복잡함을 늘립니다. 반면 한 덩어리 설계는 처음에는 단순해 보이지만, 운영 단계에서 숨은 복잡함이 폭발합니다. 왜 이상한 답이 나왔는지 설명하기 어렵고, 작은 수정이 다른 기능을 망가뜨리고, 민감 정보가 어디까지 흘렀는지 추적하기 힘들어집니다.

실무에서는 대체로 초기 설계의 약간의 번거로움이, 운영 단계의 큰 혼란을 줄여 줍니다. Isolate는 이 교환을 받아들이는 태도이기도 합니다.

Isolate를 설계할 때 꼭 던져야 할 질문

분리 설계를 시작할 때는 거창한 아키텍처보다 좋은 질문이 먼저입니다. 다음 질문들은 거의 언제나 도움이 됩니다.

• 이 작업이 정말 알아야 하는 정보는 무엇인가?

• 있으면 좋지만 없어도 되는 정보는 무엇인가?

• 절대로 섞이면 안 되는 정보는 무엇인가?

• 누가 이 정보를 볼 권한이 있는가?

• 다음 단계로 넘길 때 어떤 형식으로 줄여야 하는가?

• 한 에이전트가 아니라 둘로 나누면 더 선명해지는가?

이 질문에 답하다 보면 자연스럽게 경계가 생깁니다. 경계가 생기면 역할이 분명해지고, 역할이 분명해지면 실패도 더 다루기 쉬워집니다.

Isolate의 핵심 원칙

마지막으로 이번 장의 내용을 짧게 정리해 봅시다.

• 모든 정보를 한곳에 몰아넣는다고 시스템이 똑똑해지지는 않는다.

• 서로 다른 종류의 정보는 서로 다른 작업 공간에서 다루는 편이 낫다.

• 작은 에이전트는 약한 에이전트가 아니라, 더 선명한 에이전트다.

• 민감 정보는 기본적으로 분리하고, 필요한 순간에만 제한적으로 연결해야 한다.

• 좋은 핸드오프는 전체 전달이 아니라 목적에 맞는 상태 전달이다.

• 충돌을 줄이려면 규칙, 상태, 선호, 과제를 층위별로 나눠야 한다.

결국 Isolate의 핵심은 하나입니다. 똑똑한 시스템은 모든 것을 다 아는 시스템이 아니라, 지금 무엇만 봐야 하는지 아는 시스템이라는 점입니다.

사람도 중요한 결정을 할 때는 조용한 방으로 들어갑니다. AI도 비슷합니다. 더 나은 판단을 원한다면, 더 많은 소음을 주는 대신 더 나은 방을 설계해야 합니다. 다음 장부터는 이런 분리 원칙이 실제 업무형 에이전트 설계에서 어떻게 살아나는지 더 구체적으로 살펴보게 될 것입니다.