DeepInfer에서 DeepSeek Harness로: 감사 가능한 에이전트 범위 정하기

이전 게스트 글에서는 스택을 정리했다. 모델, DeepInfer 같은 추론 엔진, DeepSeek Harness 같은 에이전트 하네스, 그리고 에이전트가 호출할 수 있는 도구다. 이번 글은 그 지도를 실제 배포 하나를 위한 범위표로 바꾼다.

대부분의 팀은 처음에 잘못된 질문을 한다. 어떤 모델이 가장 똑똑한지, 어떤 API가 커넥터를 가장 많이 가졌는지, 금요일까지 어떻게든 돌리는 방법을 묻는다. 그 질문은 나중에 하면 된다. 첫 질문은 훨씬 좁다. 이 에이전트가 끝낼 수 있는 단 하나의 작업은 무엇이고, 제대로 끝났다는 것을 무엇이 보여 주는가.

그 지점이 가장 저렴하게 실패할 수 있는 곳이기도 하다. 목표가 모호하고 도구 권한이 넓은 에이전트는 생산성 승리가 아니라, 승인자가 실제 동작을 보지 못한 채 발생하는 사고의 대기 상태다. 아래는 에이전트를 돌리기 전에 경계를 그리는 방법이다.

하나의 작업, 하나의 종료 조건

"경쟁사를 조사한다"는 작업이 아니다. 종료 조건도, 받아들일 수 있는 산출물도, 유용한 브리프와 그럴듯한 문단 더미를 구분할 방법도 없다. 좁히면 덜 야심적으로 들리지만 실제로 작동한다.

이 범위는 입력, 산출물, 근거, 종료 조건을 명시하고 승인 지점도 분명하게 만든다. 마케팅 책임자는 브리프가 포지셔닝 문구가 되기 전에 검토한다. 조사 작업 안에서는 외부 동작이 일어나지 않는다.

코딩 에이전트라면 저장소 경로, 테스트 명령, 완료 정의가 해당한다. 지원 에이전트라면 티켓 범주 하나, 허용된 답변 집합, 사람에게 넘기는 규칙이다. 모양은 달라져도 규율은 같다.

도구 계약

작업이 좁아지면 실제로 필요한 도구를 나열한다. 벤더가 가진 도구 전부도, 다음 분기에 쓸지 모르는 도구도 아니다. 입력에서 '검토 가능한 산출물'까지 옮기는 두세 개의 연결이다.

목록은 제품 이름이 아니라 결과의 무게로 분류하는 편이 좋다.

첫 배포는 읽기와 준비에서 멈추는 게 좋다. 소심해서가 아니라, 검색 품질을 확인한 뒤 행동 권한을 주는 순서다. SpringBrand의 에이전트가 연결해야 할 도구를 정리하는 가이드도 다른 방향에서 같은 말을 한다. 하나의 비즈니스 질문에서 시작하고, 계정이나 출처를 해석한 뒤, 작업이 필요로 할 때만 연결을 늘린다.

계약에는 도구가 실패할 때의 동작도 적는다. 타임아웃은 "레코드 없음"이 아니다. 만료된 자격 증명은 빈 결과가 아니다. 이 둘을 구분하지 못하면 검토자는 '확인된 공백'과 '끊긴 연결'을 구분할 수 없다.

읽기와 쓰기는 자격 증명의 결정

권한을 프롬프트 지시로 쓰는 건 매력적이다. "아무것도 삭제하지 마." 그것은 통제가 아니다. 통제는 자격 증명, 도구 스키마, 실행 계층에 있다.

먼저 읽기 전용 자격 증명을 준다. 쓰기가 필요하면 별도 ID와 좁은 스코프를 주고, 승인 없이는 호출할 수 없는 도구 뒤에 둔다. 편하다고 관리자 토큰을 재사용하지 않는다. 에이전트가 관리자와 같은 레코드에 닿는다면 프롬프트 인젝션도 같은 범위에 닿는다.

SpringBrand의 AI 에이전트 보안 가이드가 여기서 유용하다. 데이터, 도구, ID, 동작의 경계를 그리고, 읽기 권한과 쓰기 권한을 분리하고, 가져온 내용을 신뢰하지 않는 입력으로 취급하고, 권한 부여를 모델 밖에 둔다. 마지막 항목이 가장 자주 빠진다. 웹 페이지는 지시를 담을 수 있지만 권한을 부여할 수는 없다.

DeepSeek Harness는 런타임에도 같은 이음매를 제공한다. 범위 지정 도구 레지스트리, 승인 정책, 샌드박스 모드, 추가 전용 세션 로그다. 이것들이 당신의 접근 모델을 대체하지는 않지만, 그것을 강제할 위치를 준다.

되돌릴 수 없는 단계 바로 앞에 사람을 둔다

승인 지점은 "워크플로 어딘가"가 아니다. 되돌릴 수 없는 동작 직전이며, 검토자에게 곧 일어날 구체적인 내용을 보여 준다. 수신자, 제목, 본문, 대상 주소, 금액, 레코드 변경이다.

메일을 보낸 뒤의 승인은 알림일 뿐이다. 발송 세 단계 전의 승인은 중간에 바뀐 초안을 승인하는 것일 수 있다. 검토자에게 필요한 것은 최종 제안이지 계획 요약이 아니다.

SpringBrand의 휴먼 인 더 루프 도구 비교의 핵심도 이것이다. 결과 직전에 멈추고, 검토한 값을 보존하고, 결정을 실제 실행되는 동작에 연결하고, 거부나 타임아웃 뒤의 동작을 정한다. Gumloop, n8n, Zapier, 자체 승인 큐 모두 패턴은 같다.

dsh에서는 승인 정책과 도구 호출 경계에 해당한다. 동작이 "발송"이라면 검토자는 그 메일을 봐야 한다. "게시"라면 페이지와 URL을 봐야 한다. "작업 승인"은 너무 거칠다.

봇 팀을 쓴다면 한계부터 읽어라

DeepSeek Harness의 커뮤니티 플러그인 생태계는 커지고 있다. 한 예가 DeepSeek Bot이다. 이름 있는 봇, 봇 간 메시지, 그룹 채팅을 하네스에 추가한다. DeepSeek 공식 제품이 아니고, dsh 사용에 필수도 아니다.

그래도 유용한 사례다. SpringBrand의 DeepSeek Bot의 역할과 한계는 조사 브리프를 수집, 비교, 작성 세 봇으로 나누고 진짜 중요한 질문을 던진다. 공유 메모리는 어디에 있고, 제거 후 저장 데이터는 어떻게 되며, 브리프를 쓰기 전에 누가 출처를 확인하는가.

질문은 봇 수만큼 커진다. 봇 팀은 조정과 모델 사용량을 늘리지만 커버리지를 자동으로 늘리지 않는다. 세 어시스턴트가 같은 페이지를 바꿔 쓰면 텍스트는 늘어도 근거는 늘지 않는다. 독립적인 일, 예를 들어 인용을 따로 확인하는 역할이 있을 때만 봇을 추가한다.

사람이 읽을 수 있는 감사 추적을 남긴다

재구성할 수 없는 에이전트에 결과가 큰 동작을 맡겨서는 안 된다. 최소한 다음을 기록한다.

• 작업과 승인된 범위.
• 호출한 도구, 입력, 출력.
• 모델 또는 제공자 버전, 하네스 버전.
• 되돌릴 수 없는 동작을 승인한 사람과 그가 본 내용.
• 외부 결과. 실패와 타임아웃 포함.

dsh의 추가 전용 세션 로그는 앞의 세 가지에 자연스러운 척추가 된다. 승인 큐와 대상 시스템이 나머지 두 가지를 맡는다. 중요한 설계는 안정적인 task ID 또는 proposal ID로 연결해, 검토자의 결정을 실제 실행된 동작과 맞추는 것이다.

"데모 성공"이 감사에서 떨어지는 지점도 여기다. 채팅에 "done"이라고 적혀 있어도 CRM 업데이트가 일어났는지, 메일이 발송됐는지, 검토자가 승인한 버전이 실제로 도착했는지는 증명하지 못한다.

한 페이지 범위표

첫 도구를 연결하기 전에 이 표를 채운다. 빈 행이 있으면 그 작업을 맡길 준비가 안 된 것이다.

방법은 일부러 화려하지 않다. 모델은 바꿀 수 있고, 추론 엔진도 바꿀 수 있고, 하네스도 바꿀 수 있다. 범위, 권한, 감사 추적이 이 배포를 설명 가능하게 만든다.

에이전트 범위, 도구 계약, 검토 설계에 대해 더 보려면 SpringBrand의 에이전트 워크플로 블로그에 긴 가이드가 모여 있다. 설계 참고로 읽고, 자기 워크플로 테스트를 대신하지는 말자.

FAQ

출처

• DeepSeek Harness 저장소 — README, 라이선스, developer preview 안내, 실행 명령.
• DeepSeek Harness 아키텍처 — 프로필, 번들, 도구 레지스트리, 세션 로그.
• DeepSeek Harness 안전 안내 — 샌드박스와 승인 지침.
• 추론 위의 계층 — 이 사이트의 이전 게스트 글. 네 계층 스택.
• DeepInfer의 한계 — 추론 엔진이 완전한 서빙 스택이 아닌 이유.

다음 글: 비교 허브, 또는 DeepInfer 아키텍처.