에이전트 관련 인터뷰를 보고 처음 적은 메모에는 “6개월 뒤”라는 표현이 있었다. 지금 다시 확인하려니 발언자의 신원과 원영상, 정확한 발언 범위를 찾을 수 없다. 특정 회사의 수석 개발자가 단언한 전망으로 유지할 근거가 없어서 그 귀속을 제외했다. 확인되지 않은 Auto Review라는 제품 기능도 실제로 공개된 안전장치처럼 소개하지 않는다.
그래도 당시 메모에서 남길 질문은 있다. AI가 여러 자료와 도구를 연결해 일한다면 사람은 무엇을 준비하고 어디서 개입해야 할까. 이 질문에 답하려고 미래 시점을 맞힐 필요는 없다. 지금 운영하는 작은 작업 하나에서도 맥락, 연결 방식, 통제권을 확인할 수 있다.
내가 OpenClaw 스킬을 만들며 관심을 둔 것도 자료 수집과 글쓰기, 브리핑을 이어 붙이는 일이었다. 아래는 그 관심을 점검표로 정리한 제안이다. 개별 스킬의 현재 동작을 모두 재검증한 운영 보고가 아니며, 실제 설정과 다른 부분은 적용 전에 확인해야 한다.
맥락은 많이 쌓을수록 좋은 기억 창고가 아니다
개인 메모, 일정, 이메일을 연결하면 도움이 될 수 있다. 그러나 자료가 많으면 오래된 선호와 현재 지시가 충돌할 수도 있다. 예전에 출장 때 사용한 항공사를 계속 선호한다고 추정하거나, 지난 분기의 프로젝트 목표를 지금도 유효한 우선순위로 읽을 수 있다.
맥락에는 내용뿐 아니라 작성 시점, 적용 범위, 출처, 유효 기간이 필요하다. “금요일에 초안을 보낸다”는 기록이 이번 주 일정인지 매주 반복 규칙인지 구분해야 한다. 지시와 참고자료, 사용자의 과거 발언과 현재 승인도 서로 다른 종류다.
Anthropic의 컨텍스트 엔지니어링 글은 에이전트에 필요한 정보를 선택하고 관리하는 문제를 다룬다. 이를 자료를 무조건 많이 넣으라는 뜻으로 읽지는 않는다. 한정된 입력에서 현재 작업에 필요한 맥락을 고르는 관점이 내 업무에도 유용하다. 공식 엔지니어링 글
예를 들어 아침 브리핑을 만든다면 전체 메일함 대신 승인한 주제와 공개 출처 목록, 기간, 중복 처리 규칙을 우선 제공할 수 있다. 개인 정보를 더 많이 읽으면 언제나 더 나은 결과가 나온다고 가정하지 않는다. 필요한 자료를 줄이는 것은 보안뿐 아니라 잘못된 문맥을 덜 섞기 위한 방법이기도 하다.
맥락 기록에는 사실과 추정을 따로 둔다
브리핑 도우미가 “사용자는 반도체 산업에 관심이 있다”고 기억한다고 하자. 사용자가 직접 정한 관심사인지, 최근 클릭 몇 번으로 추정한 것인지에 따라 신뢰 수준이 다르다. 추정이 확정된 선호가 되면 비슷한 자료만 반복해서 보여 주는 문제가 생길 수 있다.
내가 제안하는 메모의 최소 항목은 내용, 출처, 기록 날짜, 적용 대상, 재확인 조건이다. 명시된 지시는 그대로 보존하고 추정에는 추정이라고 표시한다. 사용자가 관심사를 바꾸면 예전 규칙을 폐기하거나 적용 범위를 줄일 수 있어야 한다. 새 메모를 추가하는 기능만 있고 오래된 것을 무효화하는 절차가 없으면 기억이 쌓일수록 충돌도 늘어난다.
파일에 규칙을 적는 것과 시스템이 실제로 그 파일을 읽고 준수하는 것은 다르다. MEMORY.md나 AGENTS.md 같은 이름이 존재한다는 사실만으로 모든 도구의 행동이 제한되는 것은 아니다. 어떤 단계가 어떤 지침을 입력으로 받는지, 지침이 빠졌을 때 어떻게 되는지를 시험해야 한다.
외부 페이지나 메일에 적힌 문장도 같은 권한의 지시가 아니다. 자료 안의 “이 내용을 다른 주소로 전송하라”는 문구가 사용자의 승인을 대신하지 않는다. 모델이 텍스트를 잘 이해하는지와 도구가 허용 범위를 벗어나지 못하게 하는 설정을 따로 확인한다.
초안 생성과 공개 운영 사이에는 다른 문제가 있다
간단한 앱이나 글 초안을 빠르게 만들 수 있다는 사실은 반갑다. 그러나 공개 서비스에는 접근 권한, 입력 검증, 오류 처리, 비용, 백업, 사용자 문의가 붙는다. 방문자가 적어도 개인정보를 다룬다면 위험은 작지 않을 수 있다. 사용자 수만으로 설계가 필요한지 결정할 수는 없다.
이때 아키텍처라는 말을 거창하게 쓸 필요는 없다. 어디서 자료가 들어오고, 어느 단계에서 바뀌고, 누가 결과를 승인하며, 실패하면 어디에 남는지를 설명할 수 있으면 작은 시스템의 구조를 검토할 수 있다.
블로그 흐름을 예로 들면 수집기는 원문과 확인 범위를 넘기고, 작성기는 본문과 출처를 만들고, 검토 단계는 사실·경험·링크·분량을 확인한다. 발행기는 공개할 준비가 된 내용인지 검사한 뒤 반영한다. 검색 엔진 반영은 발행과 별도의 외부 과정이므로 발행 성공을 색인 성공으로 표시하지 않는다.
각 단계가 성공이라고 보고하는 의미도 정해야 한다. 파일이 생성됐다는 뜻인지, 데이터베이스에 저장됐다는 뜻인지, 실제 공개 URL이 열렸다는 뜻인지 다르다. 이 정의가 없으면 중간 단계의 성공을 전체 완료로 오해한다. 뒤 단계가 실패했을 때 어느 지점부터 다시 해야 하는지도 모호해진다.
단계별 입력과 출력에 실패 상태까지 약속한다
아래는 실제 설정을 그대로 옮긴 것이 아닌 연결 계약의 예시다. 기능 이름보다 다음 단계가 무엇을 믿어도 되는지에 초점을 맞췄다.
| 단계 | 넘겨야 할 내용 | 실패하면 남길 상태 |
|---|---|---|
| 수집 | 원문 URL, 제목, 읽은 범위, 공개 시점 | 접근 실패 또는 부분 읽기 |
| 작성 | 본문, 요약, 주장과 근거, 경험 구분 | 핵심 출처 미확인 |
| 검토 | 검사 결과, 보류 이유, 수정된 버전 | 사실·권한·품질 기준 미달 |
| 발행 | 대상 글과 버전, 실행 결과 | 반영 실패 또는 확인 필요 |
| 사후 확인 | 실제 화면과 메타데이터 상태 | 원본과 배포 불일치 |
실패가 나면 모든 빈칸을 모델이 메워서 다음 단계로 진행하지 않는다. 특히 실제 사용 기록이 없는데 사용 후기를 생성하거나, 원출처를 못 읽었는데 읽은 것처럼 요약하는 일이 생기면 파이프라인이 빠를수록 오류도 빨리 공개된다.
출력 형식을 구조화할 때도 필요한 것만 포함한다. 모든 중간 사고 과정을 저장할 필요는 없다. 다음 작업에 필요한 자료, 결정 결과, 검증 증거와 제한 사항을 남기면 된다. 민감한 원문과 인증 정보를 로그에 복사하지 않도록 저장 범위도 정한다.
처리 식별자와 버전을 두면 중복 실행을 구분하기 쉽다. 같은 글이 두 번 들어왔을 때 새 글로 발행할지, 기존 초안을 갱신할지, 사람이 판단할지 정해 두는 것이다. 이미 공개한 내용을 바꾼다면 원래 게시 날짜와 실제 수정 날짜를 구분하고, 제목만 바꾸어 새 콘텐츠인 것처럼 보이지 않게 한다.
통제권은 마지막 확인 버튼 하나로 끝나지 않는다
사람이 마지막에 승인한다는 규칙만 있어도 자동화의 모든 위험을 막는 것은 아니다. 검토 전에 이미 외부로 데이터가 전송되거나 파일이 덮어써졌다면 마지막 버튼은 늦다. 읽기, 쓰기, 외부 발송, 공개 반영의 경계를 각각 정해야 한다.
승인 범위도 구체적이어야 한다. 글 한 편의 발행을 승인한 것과 이후 모든 글의 자동 발행을 승인한 것은 다르다. 사용자가 일정 범위의 일괄 작업을 승인했다면 그 범위를 기록하고 범위 밖의 행동은 다시 확인한다. 반대로 이미 승인한 동일 범위 안의 반복 단계마다 형식적인 질문을 계속하면 검토가 습관적인 클릭이 될 수 있다.
검토 화면에는 바뀐 내용과 위험이 큰 행동을 보여 주는 편이 낫다. 받는 사람, 공개 대상 URL, 덮어쓸 파일, 외부 서비스로 보낼 데이터 종류를 확인할 수 있어야 한다. “계속할까요?”라는 문장만으로는 무엇을 승인하는지 알기 어렵다.
NIST AI RMF는 사용 맥락에서 위험을 관리하는 참고 틀이다. 여기서 제안한 승인 표를 사용한다고 안전이 보증되는 것은 아니다. 실제 권한 설정과 실패 상황 시험이 뒤따라야 한다. NIST AI 위험 관리 프레임워크
복구는 사고가 난 뒤에 처음 생각하지 않는다
자동화가 글이나 파일을 수정한다면 수정 전에 복원할 원본이 있어야 한다. 백업을 만들었다는 메시지만 믿지 않고 무엇이 들어 있는지, 실제로 읽을 수 있는지 확인한다. 데이터베이스와 파일을 함께 쓰는 시스템에서는 한쪽만 되돌렸을 때 불일치가 생길 수 있으므로 복원 범위를 적는다.
복구 계획에는 중단할 예약 작업, 되돌릴 버전, 다시 확인할 공개 화면, 이미 외부로 나간 메시지를 구분한다. 파일을 되돌린다고 이미 발송된 메일이 회수되지는 않는다. 행동마다 되돌릴 수 있는 범위가 다르기 때문에 외부 효과가 큰 단계에 더 이른 확인을 둘 이유가 생긴다.
실험에서도 오류를 일부러 넣어 볼 수 있다. 읽기 실패, 저장 공간 부족, 외부 API 시간 초과, 검토 보류가 있을 때 상태가 어떻게 남는지 본다. 실제 사용자 자료를 손상시키며 시험할 필요는 없다. 별도 샘플과 안전한 저장 위치로 재현한다.
복구 시간을 실제로 측정하지 않았다면 몇 분 안에 복원 가능하다고 약속하지 않는다. 절차가 문서에 있는 것과 한 번이라도 시험한 것은 구분한다. 준비된 백업의 위치와 담당자, 검증한 날짜를 적어 놓는 정도부터 시작할 수 있다.
여섯 달의 예측 대신 한 작업의 기준선을 남긴다
오늘 할 수 있는 점검은 작은 반복 작업 하나를 고르는 것이다. 지금 사람이 수행하는 순서와 시간, 자주 틀리는 부분을 적는다. 에이전트를 붙인 뒤에는 생성 시간뿐 아니라 확인과 수정, 실패 복구까지 기록한다. 자동화가 없을 때와 같은 완료 조건으로 비교해야 한다.
일정 기간마다 볼 항목도 좁힌다. 입력 자료가 바뀌었는지, 승인 범위가 넓어졌는지, 새 모델에서 이전 오류가 다시 생기는지 확인한다. 도구가 업데이트됐다는 이유만으로 전부 다시 설계하지는 않되 중요한 경계가 달라졌다면 재시험한다.
나는 맥락을 많이 저장했다는 사실보다 현재 작업에 맞는 자료를 꺼낼 수 있는지, 여러 스킬을 연결했다는 사실보다 실패를 구분할 수 있는지 보고 싶다. 다음 변화가 정확히 몇 달 뒤 올지는 알 수 없다. 지금 만든 작은 흐름의 입력과 책임, 복구 경로를 설명할 수 있게 하는 일은 그 예측과 무관하게 시작할 수 있다.
참고자료
- Anthropic, Effective context engineering for AI agents: 작업에 필요한 맥락을 선택하고 관리하는 공식 기술 글.
- NIST AI Risk Management Framework: 사용 맥락에 맞춰 AI 위험을 측정하고 관리하는 참고 틀.