일을 자동화해도 결과에 대한 책임은 사람에게 남는다.
그래서 설계 순서는 확인 지점이 먼저고, 맡길 범위는 거기서 따라 나온다.

확인 지점을 안 정하면 두 가지 문제가 생긴다.

• 결과를 믿지 못해 전부 다시 검토한다 — 자동화 효과가 없다
• 아예 확인하지 않다가 오류를 늦게 발견한다

확인 지점은 적고 명확해야 한다.
"이 조건일 때만 사람을 부른다"가 한 문장으로 적히면 된 것이다.

• 복구 가능한 작업 — 자료 수집, 초안 작성, 파일 수정, 정리. 맡긴다. 틀리면 다시 실행하면 된다
• 복구 불가능한 작업 — 외부 전송, 삭제, 결제, 공개. 사람이 확인한다. 예외를 두지 않는다

판단 기준은 하나다. "잘못됐을 때 몇 분 안에 되돌릴 수 있는가."
답이 "아니오"거나 "모름"이면 맡기지 않는다.

실패 확률이 낮아도 1회 비용이 크면(고객 원고 유출 등) 자동화하지 않는다.
실패가 잦아도 비용이 작으면(초안 등) 자동화가 이득이다.

실수를 세 등급으로 나눈다.

• 무시해도 되는 실수 — 맡기고 확인하지 않는다
• 알아야 하는 실수 — 맡기되 알림을 받는다
• 나면 안 되는 실수 — 실행 전에 승인을 받는다

이 분류는 사고가 나기 전에 해 둔다.

• 조용한 실패 — 실패했는데 성공으로 표시된다. 가장 위험하다. 실패는 멈추고 알리게 만든다
• 억지 채우기 — 새 내용이 없는데 결과를 만들어 낸다. "오늘은 없음"이 정답인 날이 많다
• 전수 재검토 — 결과를 믿지 못해 사람이 전부 다시 본다. 1.1의 확인 지점 설계로 돌아가야 한다
• 무통보 변경 — 도구 업데이트로 전제가 바뀌었는데 아무도 모른다. 이 사이트가 감시하는 대상이 이것이다

효과가 확인된 작성 원칙:

• 완료 조건을 적는다. 무엇이 되면 끝인지 없으면 에이전트도 끝내지 못한다
• 금지 사항을 적는다. 할 일만 적으면 지시 밖의 일까지 한다
• 모호할 때의 행동을 적는다. 대부분 "멈추고 질문"이 맞다

길수록 좋은 것이 아니다. 프롬프트는 매 요청마다 다시 읽히므로 길이가 곧 비용이고,
길면 중요한 지시가 묻힌다. 최근 도구들은 기본 프롬프트를 줄이는 방향으로 가고 있다.

에이전트 자체는 텍스트 생성만 한다.
파일 읽기, 명령 실행, 네트워크 접근은 전부 도구로 부여된 권한이다.

도구를 추가하면 기능과 사고 가능성이 같이 늘어난다. 필요한 도구만 부여한다.

도구 설명도 매 요청마다 읽힌다. 도구 수를 줄이면 보안과 비용이 같이 개선된다.

저장 대상 선별 기준:

• 저장한다 — 결정, 결정의 이유, 하지 않기로 한 것과 그 이유. 재생성이 안 된다
• 저장 안 해도 된다 — 코드, 정리 문서, 표. 근거가 있으면 재생성된다

파일로 저장하면 사람이 읽고 수정할 수 있다. 에이전트의 기억을 감사할 수 있다는 뜻이다.

• 컨텍스트에 없는 내용은 모른다. 초과하면 앞부분부터 밀려난다.

긴 대화에서 앞 내용을 잊는 것은 고장이 아니라 이 한계 때문이다

• 비용은 입력+출력 토큰으로 계산한다. 한글은 대략 1글자에 1토큰 남짓이다
• 결론: 긴 대화 1회보다, 필요한 내용만 담은 짧은 실행 여러 회가 싸고 정확하다

에이전트 하나에 큰 작업을 통째로 맡기면:

• 컨텍스트가 초과된다 (2.4)
• 중간 오류가 끝까지 전파된다
• 자기 작업을 자기가 평가하게 된다 — 항상 통과한다

나누면 느려질 수 있다. 그래도 나눈다. 검증이 가능해지기 때문이다.

• 지시 — 작업을 정의하고 분배한다. 직접 실행하지 않는다
• 실행 — 받은 작업만 한다. 범위를 임의로 넓히지 않는다
• 검증 — 결과가 지시와 일치하는지 확인한다. 실행한 쪽과 달라야 한다

핵심은 검증 분리다. 실행자가 스스로 검증하면 자기 전제를 재확인할 뿐이다.

"완료됐는지 제3자가 확인할 수 있는 단위"로 나눈다.
완료 조건이 한 문장으로 안 적히면 더 나눠야 한다.

분할된 작업 사이의 의존은 줄인다.
앞 작업이 끝나야 뒤가 시작되는 사슬이 길면, 하나가 막힐 때 전체가 멈춘다.

승인은 자동화를 막는 장치가 아니라 자동화를 신뢰 가능하게 만드는 장치다.

승인 응답은 세 가지를 모두 처리해야 한다.

• 승인 — 실행한다
• 거부 — 실행하지 않는다. 사유를 기록한다
• 무응답(시간 초과) — 실행하지 않는다. 다음 주기에 다시 요청한다

무응답 처리를 빼먹는 설계가 많다.
무응답 시 무조건 진행하는 것도, 무조건 정지하는 것도 오답이다.

실패는 반드시 발생한다. 설계할 것은 실패를 없애는 것이 아니라 실패 시 동작이다.

• 기본 — 멈추고 알린다. 실패를 무시하고 진행하면 오류 결과가 정상 결과처럼 전파된다(1.4 조용한 실패)
• 일시적 실패(네트워크 오류 등) — 몇 회 재시도한다
• 구조적 실패(권한 없음, 형식 변경) — 재시도해도 같다. 즉시 정지하고 사람을 부른다

모델은 일반 지식만 안다.
내 방식은 내가 쌓은 자료 — 작업물, 결정, 제외 결정 — 에서 나온다.
같은 모델도 이 자료를 읽고 시작하면 내 방식으로, 안 읽으면 일반적인 방식으로 판단한다.

자료가 쌓이는 속도가 복제되는 속도다.

• 반드시 저장 — 결정, 이유, 하지 않기로 한 것과 그 이유, 고객과 주고받은 실제 맥락.

사라지면 복원이 안 된다

• 저장 불필요 — 문서, 요약, 코드, 표. 근거가 남아 있으면 재생성된다

특히 "하지 않기로 한 것"을 빠뜨리기 쉽다.
이유를 안 남기면 나중에 같은 검토를 반복하고 같은 결론을 다시 낸다.

• 정본은 한 곳. 나머지는 전부 사본이다. 내용이 다르면 정본이 우선한다
• 정본을 안 정하면 "어느 것이 최신인가"를 매번 사람이 판단하게 된다
• 정본 위치는 검색이 되고 오래 유지될 곳으로 정한다

사용되기 위한 조건 3가지:

• 검색된다 — 제목만으로 내용을 알 수 있게 이름 짓는다
• 인용된다 — 답변에 출처가 함께 표시된다. 출처 없는 답은 신뢰할 수 없다
• 갱신된다 — 낡은 자료를 수정한다. 안 하면 낡은 답이 계속 나온다

세 번째가 이 사이트가 하는 일이다.

기록 항목 4가지: 무엇을 / 언제 / 어느 에이전트가 어떤 승인으로 / 근거는 무엇.

기록은 실행 시점에 자동으로 남긴다. 사후에 따로 적는 기록은 누락된다.

기록이 있으면 "이게 왜 이렇게 됐나"를 사람에게 묻지 않고 확인할 수 있다.

이전 문장을 조용히 삭제하고 새로 쓰면, 읽는 사람이 변경 여부를 알 수 없다.
지금 문장이 원래 그랬는지 어제 바뀐 것인지 구분이 안 되면 전체를 신뢰할 수 없게 된다.

• 정정은 삭제선 + 새 문장 + 변경 날짜로 표시한다
• 원문(회사 발표문)은 수정하지 않는다. 수정 대상은 항상 우리 해석이다

• "주의한다"는 대책이 아니다. 사람이 기억해야 하는 규칙은 잊힌다
• 차단 설정만 대책이다. 외부 전송을 기본 차단하고, 필요한 곳만 허용한다
• 에이전트에게는 이유를 설명하는 것보다 경로를 없애는 것이 안전하다

비용 발생 지점:

• 매 요청 읽히는 것 — 프롬프트, 도구 설명, 규칙 문서. 줄이면 매번 절감된다
• 긴 대화 — 이전 내용을 반복해서 다시 읽는다 (2.4)
• 실행 주기 — 짧을수록 비용이 배수로 늘어난다. 새 내용이 없으면 실행하지 않는다

절감 순서도 이 순서다. 모델을 싼 것으로 바꾸는 건 마지막 수단이다.
싼 모델 2회가 비싼 모델 1회보다 비쌀 수 있다.

상한을 설정해 둔다. 초과를 늦게 발견해도 손해가 상한에서 멈춘다.