2026 DeepSeek Harness OpenTelemetry를 어떻게 켜야 세션이 유출되지 않을까?

이번 주에는 DeepSeek Harness OpenTelemetry 설정을 DISABLED로 고정한 뒤 데이터 분류부터 시작해야 합니다. 피드백 수집이 꼭 필요하면 FEEDBACK_ONLY를 테스트하고, FULL은 세션 데이터의 허용 범위와 삭제 책임, OTLP 인증, 전송 실패 동작을 모두 확인한 뒤에만 검토하는 순서가 안전합니다.

이 글은 원격 맥에서 Agent 장애를 집중적으로 추적해야 하는 플랫폼 엔지니어, 세션 내용이 실행 환경 밖으로 나가도 되는지 판단하는 보안·컴플라이언스 담당자, 관찰 가능한 DeepSeek Harness 환경을 팀에 넘겨야 하는 운영 책임자를 위한 내용입니다.

SECTION 01 이번 주 적용 시간표

시점	해야 할 일	통과 조건
1일 차	세션 데이터 분류	소유자, 허용 용도, 금지 항목이 문서화됨
2일 차	공유 모드 결정	권한자와 변경 승인 절차가 정해짐
3일 차	격리된 OTLP 테스트	테스트 수신 기록과 발신 기록이 일치함
4일 차	실패·재시도 검증	Agent 작업과 텔레메트리 실패의 관계를 확인함
5일 차	원격 맥 종료·인계	추가 전송 없음, 자격 증명 폐기, 삭제 책임 지정

DeepSeek Harness의 공식 구성 범위에는 DISABLED, FEEDBACK_ONLY, FULL 세 가지 세션 텔레메트리 공유 모드가 포함된 것으로 확인됩니다. 다만 모드 이름만으로 어떤 필드가 전송되는지, 기본값이 무엇인지, 버전별 동작이 같은지 단정하면 안 됩니다. 현재 버전의 구성 디렉터리와 플러그인 소스를 함께 확인해야 합니다.

OpenTelemetry는 데이터 전달 형식과 전송 방식을 정의하는 계층입니다. 그것이 곧 개인정보 차단 장치라는 뜻은 아닙니다. 로그 레코드에 사용자 입력, 도구 결과, 저장소 경로가 들어간다면 OTLP 로그로 보내는 순간 해당 값도 외부 전송 대상이 될 수 있습니다. OTLP는 로그·트레이스·메트릭을 전달하는 프로토콜일 뿐, 민감한 내용을 자동으로 삭제하지 않습니다. (OpenTelemetry 프로토콜 사양)

SECTION 02 활성화 전 데이터 경계

먼저 “세션 텔레메트리”를 일반 실행 로그와 분리해서 정의해야 합니다. 다음 항목은 각각 허용 여부를 따로 정해야 합니다.

사용자의 원문 입력과 시스템 지시문
Agent가 생성한 응답과 내부 추론 관련 값
도구 호출 이름, 인자, 반환 결과
파일 경로, 저장소 이름, 브랜치와 커밋 식별자
오류 메시지, 네트워크 주소, 계정 식별자
사용자가 남긴 평가와 피드백
실행 시간, 종료 상태, 작업 식별자

데이터 목록마다 세 가지 책임을 붙이십시오.

데이터 소유자: 어떤 팀이나 고객이 해당 값을 통제하는지 기록합니다.
허용 용도: 장애 분석, 품질 개선, 내부 성능 관찰처럼 목적을 좁힙니다.
금지 업로드: 비밀 키, 개인정보, 고객 코드, 보호 대상 저장소 내용을 명시합니다.

이 중 하나라도 확인되지 않으면 DISABLED를 유지해야 합니다. 특히 “로그니까 괜찮다”는 판단은 위험합니다. 도구 결과와 경로 정보만으로도 프로젝트 구조와 고객 이름이 노출될 수 있기 때문입니다.

공식 OpenTelemetry 설정에서도 전체 SDK를 비활성화하면 텔레메트리 구현이 동작하지 않는 무동작 상태가 되도록 정의합니다. 다만 DeepSeek Harness의 공유 모드와 SDK 전체 비활성화는 같은 설정 계층인지 반드시 구분해야 합니다. (OpenTelemetry SDK 환경 변수 사양)

SECTION 03 공유 모드 결정

세 모드는 다음처럼 운영해야 합니다.

모드	적합한 사용 시점	허용 전제	금지해야 할 상황
DISABLED	초기 설치, 고객 코드 처리, 인계 직전	외부 공유가 필요하지 않음	데이터 분류가 끝났다는 이유만으로 자동 전환
FEEDBACK_ONLY	제한된 피드백 수집 시험	피드백에 포함될 필드와 보관 기간이 승인됨	원문 입력과 도구 결과의 포함 여부가 불명확함
FULL	넓은 관찰 범위가 실제로 필요함	전체 필드 분류, 인증, 삭제, 감사 로그가 준비됨	개발 편의를 위해 일괄 활성화

FEEDBACK_ONLY와 FULL은 “간단한 로그”와 “상세한 로그”의 차이가 아닙니다. 공유 정책 자체가 다릅니다. 따라서 설정 변경 권한도 분리하십시오. 개발자가 개인 테스트에서 바꿀 수 있는 값인지, 플랫폼 운영자만 바꿀 수 있는 값인지 정하지 않으면 원격 맥 여러 대의 정책이 서로 달라집니다.

다음 체크리스트를 승인 기록으로 남기면 됩니다.

[ ] 각 세션 데이터 항목에 소유자를 지정했습니다.
[ ] 외부 전송이 허용된 목적을 한 문장으로 적었습니다.
[ ] 사용자 입력과 도구 결과의 허용 여부를 따로 결정했습니다.
[ ] FEEDBACK_ONLY와 FULL의 변경 권한자를 정했습니다.
[ ] 설정 변경 이력을 확인할 위치를 정했습니다.
[ ] 데이터 보존 기간과 삭제 담당자를 지정했습니다.
[ ] 불확실한 항목은 DISABLED로 되돌렸습니다.

SECTION 04 테스트 엔드포인트 연결

첫 연결은 운영 수신기가 아니라 격리된 OTLP 테스트 엔드포인트여야 합니다. DeepSeek Harness가 요구하는 완전한 로그 주소, 인증 방식, TLS 검증, 원격 맥의 네트워크 출구를 각각 기록하십시오.

구성 예시는 실제 주소나 토큰을 포함하지 않아야 합니다.

telemetry:
  mode: FEEDBACK_ONLY
  exporter:
    protocol: otlp_http
    endpoint: https://<격리된-수신기>/v1/logs
    headers:
      authorization: Bearer <임시-토큰>
    tls:
      verify: true
    timeout: <검증된-시간>

위 값은 형식 예시일 뿐이며, 실제 DeepSeek Harness 키 이름은 현재 버전의 공식 구성 디렉터리와 소스에서 확인해야 합니다. 일반적인 OTLP 설정에서는 HTTP 전송에 http/protobuf를 사용할 수 있고, 로그 전용 주소를 별도로 지정할 수 있습니다. 환경 변수 방식은 구현에 따라 지원 범위가 다르므로 이름을 추측해 복사하지 마십시오. (OpenTelemetry 에이전트 설정 문서)

인증 정보는 코드와 문서에 넣지 마십시오. 셸 히스토리, 프로세스 목록, 구성 백업 파일에 남는지도 확인해야 합니다. 원격 맥에서는 실행 계정에 필요한 최소 권한만 부여하고, 테스트 종료 즉시 임시 토큰을 폐기하는 방식이 적합합니다.

첫 테스트 세션은 다음 조건을 만족해야 합니다.

민감하지 않은 임시 입력만 사용합니다.
도구 호출을 사용하지 않거나 결과가 비어 있는 도구를 사용합니다.
발신 측 요청의 시간과 식별자를 기록합니다.
수신 측 레코드에 실제로 도착한 필드를 비교합니다.
수신 서버의 원문과 변환 후 레코드를 모두 확인합니다.

수신 기록이 예상보다 많으면 FULL로 확대하지 말고 DISABLED로 돌아가야 합니다. 반대로 기록이 적더라도 필드가 항상 안전하다는 뜻은 아닙니다. 다른 세션 유형, 도구 결과, 오류 상황을 별도로 시험해야 합니다.

SECTION 05 실패와 종료 경계

텔레메트리 전송 실패가 Agent 작업에 영향을 주는지는 OpenTelemetry라는 이름만으로 결정되지 않습니다. OTLP 규격은 서버 응답에 따라 재시도 가능한 상태와 재시도하지 않을 상태를 구분하지만, 실제 재시도 횟수와 로컬 버퍼, 작업 차단 여부는 클라이언트 구현에 달려 있습니다. 일반적으로 429, 502, 503, 504는 재시도 대상으로 다뤄질 수 있고, 잘못된 데이터에 해당하는 400은 재시도하지 않는 방식이 규격에 설명되어 있습니다. (OTLP 전송 규격과 재시도 가능한 응답)

따라서 다음 순서로 검증하십시오.

정상 수신 상태에서 최소 세션을 실행합니다.
테스트 엔드포인트의 DNS 또는 방화벽 경로를 차단합니다.
같은 Agent 작업이 계속되는지 확인합니다.
작업 지연, 오류 메시지, 종료 상태를 기록합니다.
네트워크를 복구한 뒤 누락 기록이나 중복 기록을 확인합니다.
프로세스를 정상 종료하고 종료 뒤 추가 전송이 있는지 확인합니다.
강제 종료 상황도 별도로 재현하되, 결과를 정상 종료와 섞지 않습니다.

OpenTelemetry 구성은 내보내기 시간 제한과 로그 속성 개수·길이 같은 제한을 제공하지만, DeepSeek Harness가 이를 그대로 따르는지는 버전별 확인이 필요합니다. 공식 설정 자료에는 로그 속성 개수 기본값으로 128이 제시되어 있으나, 이 수치를 Harness의 세션 레코드 한도로 간주해서는 안 됩니다. (OpenTelemetry 구성 형식과 로그 내보내기 설정)

재시도와 큐도 같은 방식으로 확인해야 합니다. 일부 수집기 구성에는 재시도, 전송 큐, 시간 제한이 제공되지만, 큐가 켜져 있으면 종료 시 아직 보내지 않은 데이터가 디스크에 남을 수 있습니다. 원격 맥 인계 전에 이 저장 위치와 삭제 방식을 확인하지 않으면 “전송되지 않았다”와 “삭제되었다”를 혼동하게 됩니다.

SECTION 06 원격 맥 인계 절차

원격 맥을 다른 팀이나 고객에게 넘길 때는 다음 7단계를 고정 절차로 사용하십시오.

공유 모드를 DISABLED로 변경합니다.
설정 파일, 환경 변수, 실행 인자에 남은 중복 설정을 찾습니다.
Harness와 관련 수집기 프로세스를 정상 종료합니다.
종료 후 일정 시간 동안 추가 네트워크 연결이 없는지 확인합니다.
로컬 큐, 임시 로그, 캐시, 셸 기록에 남은 인증 정보를 삭제합니다.
OTLP 엔드포인트의 토큰과 인증서를 폐기하거나 교체합니다.
수신 측에 저장된 레코드 삭제 담당자와 완료 기준을 인계 문서에 적습니다.

정상 종료와 전원 차단은 같은 결과가 아닙니다. 배치 내보내기나 종료 시 정리 작업이 구현되어 있더라도, 현재 Harness 버전이 모든 미전송 레코드를 보장해서 전송한다고 가정하면 안 됩니다. 종료 시 내보내기 완료 여부, 시간 제한, 미전송 데이터 처리 결과를 소스와 실측으로 확인해야 합니다.

SECTION 07 세 가지 운영 선택

운영 조건	권장 모드	필요한 증거
고객 코드와 개인정보가 섞임	DISABLED	외부 전송이 없다는 설정 및 네트워크 확인
제한된 내부 피드백만 필요	FEEDBACK_ONLY	실제 수신 필드, 삭제 일정, 변경 권한
중앙 장애 분석이 핵심	FULL 검토	전체 필드 분류, TLS, 인증 교체, 실패 회귀, 보존 정책

점검 항목	통과 기준	실패 시 조치
데이터 범위	금지 필드가 수신 기록에 없음	즉시 DISABLED
엔드포인트	승인된 테스트 주소로만 연결	출구 규칙과 인증 재검토
인증 정보	코드·화면·셸 기록에 노출되지 않음	토큰 폐기 후 재발급
실패 동작	Agent 작업 영향과 누락 여부를 설명 가능	운영 전환 보류
종료 동작	정상 종료 뒤 추가 전송과 잔여 큐를 확인함	인계 중지

단계	변경 권한	검토 주기	다음 단계 조건
DISABLED	플랫폼 운영자	배포마다	데이터 분류 승인
FEEDBACK_ONLY	운영자와 보안 담당자	시험 종료 시	수신 필드 승인
FULL	지정된 변경 관리자	정기 보안 검토	삭제·실패·인계 검증 완료

지금 사용 중인 환경이 여러 원격 맥으로 나뉘어 있다면, VPSNIX의 원격 맥 운영 안내에서 계정과 접근 절차를 먼저 통일하고, 개인정보 처리 기준을 데이터 보존과 삭제 책임 문서에 연결하는 편이 좋습니다. 단순히 설정값 하나를 바꾸는 것보다, 누가 어떤 환경을 언제 끄고 확인했는지를 남기는 것이 인계 사고를 줄입니다.

현재 방식이 개인 장비나 임시 클라우드 서버라면 세 가지 문제가 자주 생깁니다. 설정이 여러 위치에 흩어지고, 네트워크 출구를 통제하기 어렵고, 임대 종료 시 로컬 큐와 인증 정보 삭제를 놓치기 쉽습니다. 장기 고정 부하나 물리 장치 접근이 필요하면 직접 구매가 더 적합할 수 있지만, 짧은 기간의 보안 검증과 팀 단위 관찰 환경이 필요하다면 VPSNIX에서 원격 맥 환경을 임대해 DISABLED에서 단계적으로 시험하는 편이 관리하기 쉽습니다.