딥시크 하네스 세션 로그는 맥에서 어디에 저장되나요?

고정된 경로를 전제로 하지 않는 것이 안전합니다. 구현체와 버전에 따라 세션 디렉터리, 사용자 라이브러리, 프로젝트 작업 공간이 달라질 수 있습니다. 실행 중인 프로세스와 설정 파일에서 저장 경로를 확인한 뒤, 작업 전후의 실제 디렉터리 크기를 비교해야 합니다. 공개된 하네스 규격도 적용 결과가 구현체의 실행 환경에 반영된다고 설명합니다.

긴 세션은 맥 디스크를 얼마나 사용하나요?

대화 횟수만으로는 예측할 수 없습니다. 모델 응답보다 명령 결과, 빌드 출력, 검색된 코드, 압축 전후 이벤트, 재시도 기록이 더 큰 증가를 만들 수 있습니다. 대표 작업을 정해 시작 전과 종료 후의 로그 및 작업 공간 크기를 측정하고, 단위 작업 증가량에 하루 작업 수와 보존 일수를 곱하는 방식이 가장 안전합니다.

이미지 첨부는 세션과 함께 저장되나요?

이미지 저장 여부와 저장 방식은 클라이언트와 하네스 구현에 따라 달라집니다. MCP 규격은 도구 결과에 이미지 데이터를 포함할 수 있도록 정의하지만, 이를 곧바로 로컬 파일 보존으로 해석해서는 안 됩니다. 원본 파일, 변환본, 회복용 복사본을 각각 확인하고, 실제 파일 크기와 세션 재개 후 증가량을 따로 기록해야 합니다.

클라우드 맥에는 로그 공간을 얼마나 남겨야 하나요?

고정된 기가바이트 값을 먼저 정하지 말고 측정값으로 계산해야 합니다. 온라인 데이터에 작업 공간, 실행 캐시, 백업 복사본, 여유 공간을 더한 뒤 동시 실행 수를 반영합니다. 감사 기록을 오래 보존하거나 이미지와 빌드 결과가 많은 경우에는 임시 정리보다 별도 저장소 또는 더 큰 맥 저장 공간을 검토해야 합니다.

어떤 세션 데이터를 안전하게 지울 수 있나요?

복구에 필요한 이벤트, 감사 대상 기록, 민감한 첨부 파일은 보존 정책 확인 없이 삭제하면 안 됩니다. 먼저 세션을 내보내거나 백업하고, 복구 테스트를 통과한 캐시와 중복 도구 출력부터 정리합니다. 삭제 전후에 세션 재개, 도구 호출 기록, 작업 결과물 접근이 정상인지 확인해야 하며, 단순히 오래된 파일이라는 이유만으로 지우면 안 됩니다.

딥시크 하네스 세션 로그 공간, 먼저 측정하세요

딥시크 하네스 세션 로그 공간은 대화 수가 아니라 세션 이벤트, 도구 출력, 이미지 첨부, 작업 공간 결과물, 실행 캐시, 백업 복사본을 각각 측정한 뒤 계산해야 합니다. 이번 주에는 대표 작업 1개를 정해 실행 전후의 디렉터리 크기를 기록하고, 그 값을 작업 빈도와 보존 기간에 곱하는 방식으로 시작하는 것이 안전합니다.

이 글은 장기간 에이전트를 실행하는 개발자, 실제 작업량으로 클라우드 맥 저장 공간을 구매하려는 기술 구매 담당자, 백업과 복구 정책을 정해야 하는 운용팀을 위한 안내서입니다. 단기 테스트만 실행하거나 세션 기록을 보존하지 않는 사용자는 전체 절차가 필요하지 않을 수 있습니다.

먼저 고정할 계산 범위

계산식은 다음처럼 나눠야 합니다.

필요 저장 공간
= 세션 이벤트 로그
+ 도구 결과 로그
+ 이미지 첨부
+ 작업 공간 결과물
+ 실행 캐시
+ 백업 및 복구 복사본
+ 운영 여유 공간

여기서 모델 토큰 사용량과 로컬 디스크 사용량은 서로 다른 지표입니다. 토큰은 API 요청과 비용을 계산하는 기준이고, 디스크는 이벤트 구조, 원문 보존, 도구 결과, 이미지 파일, 압축본, 임시 파일을 포함한 결과입니다. 토큰 수가 같아도 한 작업이 긴 명령 결과와 여러 파일을 남기면 디스크 증가량은 달라질 수 있습니다.

측정 기록에는 다음 항목을 함께 적어야 합니다.

하네스와 클라이언트 버전
운영 체제 버전
작업 유형
실행 시간
동시 실행 수
이미지 첨부 유무
도구 출력 제한 여부
압축 또는 요약 이벤트 발생 여부
측정 전후의 저장 경로와 디렉터리 크기

하네스 규격은 플러그인, 도구 서버, 환경 변수, 권한, 지침을 하나의 실행 문맥으로 다룹니다. 따라서 설정 파일의 크기만 보고 세션 공간을 추정하면 안 됩니다. 하네스 실행 문맥의 공식 설명과 적용 결과 및 세션 상태에 관한 규격을 기준으로, 실제 구현체가 어느 항목을 영속화하는지 확인해야 합니다.

주의: 공개 문서에 저장 구조가 정의되어 있지 않다면 임의의 폴더명이나 파일 형식을 공식 동작처럼 기록하지 않아야 합니다. 현재 버전에서 실제로 만들어진 경로를 측정값으로 남기는 편이 정확합니다.

세션 이벤트는 기본 증가량만 보여 줍니다

세션 기록에는 화면에 보이는 사용자 메시지와 모델 답변만 들어간다고 가정하면 안 됩니다. 일반적으로 측정 대상에는 다음 유형이 포함될 수 있습니다.

사용자 입력과 모델 출력
도구 호출과 도구 반환값
승인, 거부, 재시도 이벤트
세션 압축 또는 요약 이벤트
권한 변경과 실행 상태
오류, 중단, 복구 관련 기록

SessionEvent라는 이름이 소스나 저장 구조에 나타나더라도, 그 한 줄이 정확히 몇 바이트인지 먼저 정해 두면 안 됩니다. 직렬화 방식, 중첩된 도구 결과, 원문 보존 여부에 따라 단위가 달라지기 때문입니다.

첫 번째 측정은 작업 전후의 디렉터리 차이로 진행할 수 있습니다.

before=$(du -sk "$SESSION_DIR" "$WORKSPACE_DIR" 2>/dev/null | awk '{sum += $1} END {print sum}')
date
printf 'before_kib=%s\n' "$before"

# 대표 작업을 여기서 실행합니다.

after=$(du -sk "$SESSION_DIR" "$WORKSPACE_DIR" 2>/dev/null | awk '{sum += $1} END {print sum}')
date
printf 'after_kib=%s\n' "$after"
printf 'delta_kib=%s\n' "$((after-before))"

출력 예시는 형식만 보여 주는 예시입니다. 실제 용량을 뜻하지 않습니다.

Tue Aug 18 10:00:00 PDT 2026
before_kib=측정값
after_kib=측정값
delta_kib=after_kib-before_kib

경로를 모를 때는 실행 명령, 설정 파일, 프로세스 인자, 현재 작업 디렉터리를 먼저 확인해야 합니다. 애플의 셸 스크립트 도구 안내는 du, stat, diskutil 같은 기본 도구의 역할을 설명하지만, 특정 하네스의 저장 경로를 보장하지는 않습니다.

도구 결과가 긴 세션의 상한을 결정합니다

장시간 실행에서 가장 먼저 확인할 항목은 도구 결과입니다. 빌드 로그, 테스트 결과, 명령어 오류, 대규모 코드 검색 결과는 짧은 대화보다 훨씬 큰 기록을 만들 수 있습니다.

다음 두 가지를 구분해야 합니다.

세션 이벤트에 원문으로 들어가는 도구 결과
작업 공간에 파일로 남고 세션에는 경로만 기록되는 결과물

두 항목을 합치면 같은 결과물을 이중으로 계산할 수 있습니다. 반대로 세션에는 요약만 남는다고 가정하면 감사 기록에 필요한 원문을 놓칠 수 있습니다.

측정 항목	확인할 내용	용량 계산에 넣는 방식
명령 결과	원문 전체인지 일부인지	세션 로그 증가량에 포함
빌드 산출물	세션 밖 파일인지	작업 공간 결과물로 별도 계산
코드 검색	반환된 코드와 파일 사본 여부	각각 확인 후 중복 제거
오류 재시도	같은 결과가 여러 번 저장되는지	반복 실행 횟수 반영
압축 이벤트	원문 삭제 또는 보존 여부	보존본과 압축본을 따로 측정

출력 제어 정책을 바꿀 때는 “몇 퍼센트 절약된다”는 식의 고정값을 사용하지 않아야 합니다. 같은 저장소와 같은 기준 작업을 실행해 전체 출력, 줄인 출력, 파일 저장 후 경로 반환을 각각 비교해야 합니다.

예를 들어 다음처럼 세 번 실행합니다.

기준 작업 A: 전체 테스트 실행 결과를 세션에 반환
기준 작업 B: 실패 요약과 마지막 로그만 세션에 반환
기준 작업 C: 전체 결과를 작업 공간에 저장하고 세션에는 파일 경로만 반환

이때 비교해야 하는 값은 토큰이 아니라 세션 디렉터리 증가량, 작업 공간 증가량, 복구 후 읽을 수 있는 기록의 범위입니다.

이미지 첨부는 별도 지표로 분리합니다

이미지 첨부는 파일 개수만으로 계산하면 안 됩니다. 같은 이미지라도 원본, 변환본, 미리 보기, 인코딩된 메시지, 회복용 사본이 함께 만들어질 수 있습니다.

MCP 공식 규격은 도구 결과에 이미지 콘텐츠와 인코딩된 데이터를 포함할 수 있다고 정의합니다. MCP 도구 결과의 이미지 콘텐츠 규격을 참고할 수 있지만, 이 규격만으로 특정 클라이언트가 이미지를 로컬에 얼마나 오래 보존하는지 판단할 수는 없습니다.

측정 순서는 다음과 같습니다.

첨부 전 세션과 작업 공간 크기를 기록합니다.
원본 이미지의 실제 파일 크기를 stat으로 확인합니다.
이미지를 포함한 작업을 실행합니다.
실행 직후 세션, 캐시, 작업 공간의 변화를 각각 기록합니다.
세션을 종료한 뒤 다시 열어 추가 파일이 생기는지 확인합니다.
복구 또는 내보내기 후 생성된 사본을 별도로 측정합니다.

stat -f '%N %z bytes' "$IMAGE_FILE"
find "$SESSION_DIR" "$WORKSPACE_DIR" -type f -print0 2>/dev/null \
  | xargs -0 stat -f '%z %N' \
  | sort -nr | head -20

이미지가 민감한 설계도, 고객 자료, 내부 화면이라면 공간뿐 아니라 보존 책임도 함께 정해야 합니다. MCP 보안 원칙은 외부 데이터 접근과 실행 경로에 사용자 동의와 데이터 보호가 필요하다고 설명합니다. 따라서 용량을 줄이기 위해 무조건 원본을 삭제하는 방식은 감사와 사고 대응 요건을 위반할 수 있습니다.

백업은 사용 가능한 작업 공간과 분리합니다

온라인 세션 데이터가 1개 있다고 해서 필요한 저장 공간도 1개라고 볼 수 없습니다. 백업 정책이 있으면 다음 항목이 따로 생깁니다.

현재 실행 중인 세션과 작업 공간
정기 스냅샷
다른 위치로 옮긴 마이그레이션 복사본
장애 발생 시 되돌릴 복사본
복구 검증용 임시 공간

APFS는 스냅샷과 공간 공유를 지원하며, 복제본은 일반 파일 복사와 다르게 실제 사용량이 표시되는 방식이 달라질 수 있습니다. 애플의 APFS 설명을 확인한 뒤, df, du, 백업 도구의 보고값을 한 화면의 동일한 숫자로 취급하지 않아야 합니다.

공간 구분	목적	작업 공간으로 계산할지
온라인 데이터	현재 세션과 프로젝트 실행	예
스냅샷	빠른 되돌리기	아니오
외부 백업	장기 보존과 장애 대응	아니오
마이그레이션 사본	다른 맥으로 이동	아니오
복구 임시 공간	실제 복구 검증	별도 여유로 확보

Time Machine 설정에는 백업 대상, 제외 경로, 백업 크기 제한, 로컬 백업 스냅샷 관련 항목이 존재합니다. 애플의 Time Machine 관리 문서을 참고해 백업 정책을 확인할 수 있습니다. 다만 스냅샷이 존재한다는 사실만으로 해당 공간을 즉시 삭제 가능한 공간으로 분류해서는 안 됩니다.

경험상 가장 위험한 착각은 백업 파일이 있다는 이유만으로 복구도 된다고 보는 것입니다. 새 버전에서 백업을 읽을 수 있는지, 기존 세션을 이어 실행할 수 있는지는 별개의 검증 항목입니다.

FAQ: 저장 위치와 정리 범위

딥시크 하네스 세션 로그는 어디에서 확인합니까?

고정 경로를 추정하지 말고 현재 버전의 설정과 실행 프로세스에서 확인해야 합니다. 세션 폴더, 프로젝트 폴더, 사용자 라이브러리, 임시 폴더를 각각 조사하고, 대표 작업 전후에 du와 stat으로 차이를 기록합니다. 공개 하네스 규격은 실행 문맥을 정의하지만 모든 구현체의 로컬 경로를 하나로 정하지 않습니다.

긴 세션의 디스크 사용량은 무엇이 좌우합니까?

대화 횟수보다 도구 호출 횟수와 반환 결과의 길이가 더 중요한 경우가 많습니다. 빌드 출력, 전체 테스트 로그, 코드 검색 결과, 재시도 기록, 압축 전 원문 보존 여부를 함께 확인해야 합니다. 따라서 “긴 세션 1개는 일정 용량”이라는 식의 일반값보다 기준 작업 1회의 실제 증가량을 확보하는 편이 안전합니다.

이미지 첨부는 항상 세션에 남습니까?

항상 그렇다고 단정할 수 없습니다. MCP는 이미지 콘텐츠를 전달할 수 있지만, 클라이언트가 이를 원본 파일로 저장하는지, 인코딩된 데이터만 이벤트에 넣는지, 회복 과정에서 사본을 만드는지는 구현체마다 다를 수 있습니다. 원본과 세션 재개 후 생성된 파일을 각각 읽어 실제 사용량을 기록해야 합니다.

클라우드 맥에는 로그 공간을 어떻게 배정합니까?

먼저 온라인 데이터의 단위 작업 증가량을 구합니다. 여기에 하루 작업 수, 보존 일수, 동시 실행 수를 적용하고, 작업 공간과 백업 복사본을 더합니다. 이미지와 대형 도구 결과가 포함된 업무라면 평균값만 사용하지 말고 가장 큰 기준 작업을 별도 측정해 용량 부족 시점을 계산해야 합니다.

어떤 기록부터 정리할 수 있습니까?

복구와 감사에 필요한 이벤트, 승인 기록, 민감한 이미지, 아직 완료되지 않은 작업물은 먼저 보존 대상으로 분류해야 합니다. 그 다음 중복 캐시, 재생성 가능한 빌드 결과, 이미 외부 백업에서 복구 검증을 마친 임시 파일을 정리합니다. 삭제 후에는 세션 재개와 도구 결과 확인을 실행해야 합니다.

측정값으로 임대와 확장을 결정합니다

단위 작업 증가량을 작업증가량이라고 하면 다음 공식을 사용할 수 있습니다.

온라인 필요량
= 작업증가량 × 일일 작업 수 × 보존 일수 × 동시 실행 수
+ 작업 공간 결과물
+ 실행 캐시

백업까지 포함한 전체 계획은 다음처럼 확장합니다.

전체 계획 용량
= 온라인 필요량
+ 백업 복사본 용량
+ 마이그레이션 사본 용량
+ 복구 검증 공간
+ 운영 여유 공간

여기서 백업 복사본 수와 보존 기간은 조직 정책에 입력해야 하는 값입니다. 출처가 없는 고정 일수나 고정 기가바이트를 일반적인 정답처럼 쓰지 않는 이유도 여기에 있습니다. 각 팀의 작업 유형과 보존 책임이 다르기 때문입니다.

결정 조건

대표 작업 3회 이상의 증가량이 비슷하고, 보존 기간과 백업 수가 확정되어 있다면 측정된 총량에 맞춰 맥 저장 공간을 선택합니다.
도구 결과가 작업마다 크게 달라진다면, 평균값 대신 가장 큰 기준 작업을 사용하고 출력 제한 정책을 먼저 조정합니다.
이미지 첨부가 많고 원본 보존이 필요하다면, 세션 공간과 별도 파일 저장 공간을 분리합니다.
정리해도 감사 기록이나 복구 요건을 충족할 수 없다면, 삭제보다 확장을 선택합니다.
새 버전으로 이전할 예정이라면, 기존 백업을 읽는 테스트와 세션 재개 테스트를 모두 통과하기 전까지 기존 환경을 제거하지 않습니다.
동시 실행 수가 늘어날 예정이라면, 단일 세션 측정값을 그대로 복사하지 말고 공유 캐시와 충돌 여부를 다시 측정합니다.

이번 주에는 다음 기록표를 만들어 두면 구매 판단이 쉬워집니다.

버전:
운영 체제:
작업 유형:
관찰 시간:
동시 실행 수:
세션 전 크기:
세션 후 크기:
도구 결과 증가량:
이미지 원본 크기:
이미지 보존본 크기:
작업 공간 증가량:
백업 복사본 수:
복구 테스트 결과:
정리 가능한 항목:
확장이 필요한 시점:

장기간 실행하는 환경에서 현재 방식이 개인 맥이나 로컬 디스크에 의존하면, 세션 로그와 작업 결과가 같은 공간을 잠식하고, 백업 시점마다 여유 용량이 달라지며, 장애가 발생했을 때 복구용 사본을 둘 장소도 부족해질 수 있습니다. 반면 무조건 클라우드 맥을 선택하는 것도 정답은 아닙니다. 물리 장치 접근이 필요하거나 장기간 일정한 고부하를 유지하는 작업이라면 직접 구매가 더 합리적일 수 있습니다.

다만 임시 프로젝트, 팀 단위 검증, 세션 보존이 필요한 원격 에이전트 운용이라면 NodeMini의 클라우드 맥 주문 안내를 기준으로 실제 작업 증가량과 백업 공간을 함께 확인하는 편이 낫습니다. 맥 미니를 클라우드에서 운영하는 방법과 원격 맥 인수 확인 항목을 함께 검토하면, 로그 공간만 보고 임대하는 실수를 줄일 수 있습니다.