한 사람이 끝낸 작업인지, 이전 사용자의 백그라운드 프로세스인지 확인되지 않는다면 공용 계정은 이미 한계에 도달한 상태입니다. 개인 개발자의 임시 협업이고 저장소와 자격 증명이 낮은 민감도라면 전용 계정 하나를 제한적으로 공유할 수 있지만, 장기 운영·다중 API Key·책임 추적이 필요하면 맥OS 사용자 계정을 사람별로 나눠야 합니다. 고객별 신뢰 경계가 다르면 계정 분리만으로 부족하므로 클라우드 맥 환경 자체를 분리해야 합니다.
이 글은 한 대의 클라우드 맥을 여러 개발자에게 순서대로 배정하려는 팀 책임자를 위한 글입니다. DeepSeek Harness의 지속 프로세스를 관리하는 운영 담당자와 저장소, 서명 자료, 여러 API Key의 회수 기준을 정해야 하는 보안 담당자에게도 해당합니다.
[ SECTION_01 ] 먼저 확인할 기준은 로그인 기록이 아니라 실행 주체입니다
공용 계정에서 흔한 장애 흐름은 다음과 같습니다.
- 개발자 A가 Harness 세션을 시작합니다.
- 작업 공간과 저장소를 열어 둔 채 연결을 종료합니다.
- 개발자 B가 같은 맥OS 계정으로 접속합니다.
- B의 화면에는 이전 세션이나 같은 이름의 작업 공간이 보입니다.
- 백그라운드 작업이 A의 저장소와 자격 증명을 계속 사용합니다.
- 문제가 발생하지만 화면 로그인 기록에는 단순히 같은 계정만 남습니다.
DeepSeek Harness가 작업 공간, 모델 자격 증명, 도구 실행을 다루는 구조라면 화면에 표시되는 서비스 로그인 기록만으로는 맥OS에서 실제 명령을 실행한 주체를 증명할 수 없습니다. 공개된 구현 자료에서도 작업 기록, 세션 상태, 환경 변수, 도구 호출이 실행 환경에 함께 연결될 수 있음을 확인할 수 있지만, 여러 사람이 하나의 맥OS 계정을 공유해도 안전하다는 공식 보장은 확인되지 않습니다. (공개된 DeepSeek Harness 안내 자료)
따라서 운영자가 작성해야 할 기본 대응표는 다음과 같습니다.
- 사람: 누가 작업을 시작하고 승인했는가
- 맥OS 사용자 계정: 어떤 홈 디렉터리와 로그인 세션을 사용했는가
- Harness 프로세스: 어떤 방식으로 시작됐고 누가 중지할 수 있는가
- 저장소: 어느 프로젝트를 읽고 수정했는가
- 자격 증명: 어떤 소유자가 발급했고 누가 회수할 수 있는가
폴더 이름이나 메신저의 사용 순서만으로는 접근 제어가 되지 않습니다. 애플 문서도 사용자별 홈 폴더와 파일 권한을 별도 개념으로 설명합니다. 다른 사용자가 읽거나 수정할 수 있는지는 실제 소유자와 권한 설정에 달려 있습니다. (애플의 파일 및 폴더 권한 안내)
여러 사람이 DeepSeek Harness를 하나의 계정으로 써도 되는가?
낮은 민감도의 단일 저장소에서 개인 작업을 임시로 이어받는 정도라면 가능합니다. 단, 다음 교대 조건을 모두 지켜야 합니다.
- 현재 세션과 실행 중인 작업을 목록으로 남깁니다.
- 사용자가 작업 공간과 저장소 변경 사항을 인계합니다.
- 개인 API Key를 공용 계정에 넣지 않습니다.
- 다음 사용자가 이전 프로세스를 중지했는지 확인합니다.
- 작업 종료 시 로그와 변경 파일의 책임자를 기록합니다.
이 중 하나라도 지킬 수 없다면 공용 계정은 거부하는 편이 안전합니다.
[ SECTION_02 ] Keychain과 환경 변수가 같은 사람의 경계를 가릴 수 있습니다
맥OS의 Keychain은 암호, 로그인 토큰, 디지털 신원, 암호화 키 같은 민감한 정보를 저장할 수 있습니다. 애플은 각 맥 사용자에게 기본 Keychain이 생성되며, 사용자별 Keychain과 시스템 수준 Keychain이 함께 존재한다고 설명합니다. (애플의 Keychain 보안 안내)
문제는 API Key가 항상 같은 방식으로 저장되지 않는다는 점입니다. Harness 버전에 따라 환경 변수, 설정 파일, Keychain, 별도 비밀 저장소가 사용될 수 있습니다. 구체적인 읽기 위치는 버전별로 확인해야 하며, 문서에 없는 동작을 일반화해서는 안 됩니다.
운영자는 자격 증명을 세 부류로 나눠야 합니다.
- 개인 API Key: 특정 개발자의 사용량과 책임에 연결되므로 개인 계정에서만 읽도록 합니다.
- 팀 서비스 키: 자동화 프로세스가 사용한다면 사람 계정이 아닌 전용 서비스 계정과 제한된 작업 공간에 둡니다.
- 코드 서명 자료: 개인 로그인과 개발자 인증 자료가 섞이면 회수와 사고 조사가 어려워집니다. 별도 승인과 사용 기록을 둡니다.
판단 기준은 저장 위치가 아니라 소유권입니다. 키의 소유자, 읽을 수 있는 주체, 폐기할 수 있는 주체가 서로 명확하지 않다면 계정을 나눠야 합니다.
원격 맥에서 개발자별 API Key를 격리하려면 어떻게 해야 하는가?
가장 먼저 개발자별 맥OS 사용자 계정과 홈 디렉터리를 분리합니다. 각 계정의 환경 변수와 Keychain을 따로 관리하고, 공용 폴더에는 키를 저장하지 않습니다. 서비스 프로세스가 필요한 키는 개인 계정의 로그인 세션에 의존하지 않는 전용 서비스 계정으로 이전합니다.
애플의 파일 권한 모델에서는 읽기, 쓰기, 실행 권한을 사용자와 그룹별로 설정할 수 있습니다. 다만 권한 설정은 잘못 적용하면 다른 사용자에게 파일을 열어 주거나 소유자 자신이 접근하지 못하게 만들 수 있습니다. 변경 후에는 실제 계정으로 읽기와 쓰기를 각각 시험해야 합니다. (애플의 파일 권한 변경 안내)
[ SECTION_03 ] 저장소와 세션 로그는 같은 홈 디렉터리에서 겹치기 쉽습니다
공용 계정 하나를 계속 사용하면 다음 자료가 한 경계 안에 모입니다.
- 저장소의 작업 트리와 변경되지 않은 파일
- Harness 설정과 플러그인
- 세션 기록과 명령 실행 결과
- 셸 기록과 환경 변수
- 임시 파일과 캐시
- 이전 사용자가 남긴 인증 상태
같은 홈 디렉터리에서 프로젝트 폴더를 이름으로만 구분하는 방식은 접근 통제가 아닙니다. 특히 고객 프로젝트와 내부 프로젝트의 민감도가 다르거나, 서로 다른 고객의 코드가 한 맥에 놓이면 독립 계정만으로도 충분하지 않을 수 있습니다.
다음 조건에 해당하면 독립 환경으로 승격해야 합니다.
- 서로 다른 고객의 저장소를 동시에 다룹니다.
- 한 프로젝트에 코드 서명 자료가 포함됩니다.
- 개발자마다 API Key의 소유자가 다릅니다.
- 세션 로그에 소스 코드나 고객 정보가 남습니다.
- 한 사람의 삭제가 다른 사람의 작업에 영향을 주면 안 됩니다.
- 사고 발생 시 특정 사용자의 자료만 보존하거나 폐기해야 합니다.
맥OS는 사용자별 홈 폴더와 별도의 공유 폴더를 제공합니다. 공유 폴더에 둔 자료는 여러 사용자가 읽을 수 있으므로, 전달용 파일과 비밀 자료를 같은 위치에 두면 안 됩니다. (애플의 사용자 폴더 안내)
DeepSeek Harness 서비스 계정과 개인 계정은 어떻게 선택하는가?
사람이 직접 승인하고 대화하는 세션은 개인 계정이 적합합니다. 정해진 작업을 계속 실행하는 프로세스는 서비스 계정이 적합합니다. 서비스 계정에는 개인 브라우저 로그인, 개인 Keychain, 개인 저장소 권한을 넣지 않아야 합니다.
다음과 같은 구조가 기본값입니다.
- 개인 계정: 대화형 개발, 수동 승인, 개인 작업 기록
- 서비스 계정: 예약 작업, 지속 프로세스, 제한된 저장소와 팀 키
- 독립 맥 환경: 고객별 환경, 서로 다른 보안 등급, 별도 회수 단위
서비스 계정은 책임자를 없애는 장치가 아닙니다. 서비스 계정마다 소유 팀, 시작 방법, 로그 위치, 중지 권한, 키 교체 담당자를 문서화해야 합니다.
주의: 브라우저 탭을 닫거나 원격 화면 연결을 끊는 것은 신원 전환이 아닙니다. 백그라운드 프로세스가 남아 있으면 이전 사용자의 저장소와 자격 증명이 계속 사용될 수 있습니다.
[ SECTION_04 ] 백그라운드 프로세스는 교대 이후에도 남을 수 있습니다
Harness나 보조 작업이 터미널, 실행 도구, 작업 스케줄러, 서비스 관리자를 통해 시작되면 화면을 닫은 뒤에도 실행될 수 있습니다. 이때 운영자가 확인할 대상은 프로세스 이름이 아닙니다.
- 프로세스가 실행된 사용자 계정
- 작업 디렉터리
- 환경 변수와 자격 증명 주입 방식
- 표준 출력과 오류 로그 위치
- 재시작 정책
- 중지와 인계 방법
교대 절차는 최소 5단계로 고정하는 것이 좋습니다.
- 현재 사용자가 실행 중인 Harness와 보조 작업을 목록화합니다.
- 각 프로세스의 사용자, 저장소, 세션 식별자를 기록합니다.
- 계속 실행할 작업과 중지할 작업을 책임자가 승인합니다.
- 중지 대상은 실제 프로세스 종료와 자격 증명 폐기를 확인합니다.
- 다음 사용자가 최소 작업을 실행하고, 새 로그와 저장소 경로를 검증합니다.
새 사용자가 이전 세션을 볼 수 없게 만드는 것만으로는 부족합니다. 이전 프로세스가 남아 있지 않고, 새 프로세스가 올바른 사용자와 저장소를 사용하는지까지 확인해야 합니다.
[ SECTION_05 ] 네 가지 선택 조건으로 계정 구조를 결정합니다
아래 결정 조건 목록을 그대로 적용하면 됩니다.
-
낮은 민감도 저장소 하나를 짧은 기간 동안만 함께 사용합니까?
그렇다면 임시 공용 계정을 선택할 수 있습니다. 단, 교대 기록, 프로세스 종료, 개인 키 미사용, 작업 인계가 모두 가능해야 합니다. 하나라도 불가능하면 개인 계정으로 되돌립니다. -
여러 개발자가 장기간 사용하거나 개인별 책임 추적이 필요합니까?
그렇다면 일인 일계정을 선택합니다. 개인 홈 디렉터리, Keychain, 저장소 권한, 세션 로그를 분리합니다. 단, 관리자 계정이나 공유 폴더를 통한 우회 접근이 가능하므로 완전한 테넌트 격리로 보지 않습니다. -
사람이 자리를 비워도 계속 실행해야 하는 자동화 작업입니까?
그렇다면 전용 서비스 계정을 선택합니다. 서비스 키와 제한된 저장소만 연결합니다. 개인 인증서와 개인 API Key가 들어가면 서비스 계정으로서 거부합니다. -
고객별 신뢰 경계나 민감도가 서로 다릅니까?
그렇다면 맥 환경 자체를 분리합니다. 계정 분리만으로 해결하지 않습니다. 저장소, 세션, 로그, 자격 증명, 초기화 단위를 함께 분리합니다. -
특정 사용자 하나만 제거해도 나머지 작업을 유지할 수 있습니까?
그렇지 않다면 현재 구조를 승인하지 않습니다. 개인 계정 또는 독립 환경으로 바꾼 뒤 회수 시험을 다시 진행합니다.
배포 전 계정 구조 판정 체크리스트
아래 항목에서 하나라도 확인되지 않으면 공용 계정 배포를 승인하지 않는 편이 안전합니다.
- [ ] 작업마다 담당자와 승인자가 기록됩니다.
- [ ] 현재 실행 중인 Harness 프로세스의 사용자와 작업 디렉터리를 확인할 수 있습니다.
- [ ] 개인 API Key가 공용 Keychain이나 공용 환경 변수에 저장되지 않습니다.
- [ ] 서비스 계정의 소유 팀과 키 교체 담당자가 정해져 있습니다.
- [ ] 개발자별 저장소와 세션 로그의 읽기 범위를 시험했습니다.
- [ ] 이전 사용자의 프로세스를 중지하는 방법이 문서화되어 있습니다.
- [ ] 계정 하나를 삭제하거나 잠가도 다른 작업이 계속됩니다.
- [ ] 퇴사자 회수 절차를 실제 환경에서 한 번 실행했습니다.
- [ ] 고객별 저장소와 서명 자료가 같은 환경에 섞이지 않습니다.
- [ ] 위 조건을 충족하지 못할 때 개인 계정 또는 독립 맥 환경으로 전환하는 담당자가 정해져 있습니다.
판정 결과는 다음처럼 해석합니다.
- 모든 항목을 확인했으면 낮은 민감도의 임시 공용 계정을 검토할 수 있습니다.
- 첫 7개 항목 중 하나라도 실패하면 일인 일계정으로 전환합니다.
- 고객별 저장소, 서명 자료, 서로 다른 보안 등급이 섞이면 독립 맥 환경으로 전환합니다.
- 지속 실행 작업이면 개인 계정이 아니라 전용 서비스 계정을 사용합니다.
운영 판단용 점수로 보면 임시 공용 계정은 책임 추적 1점, 키 회수 1점, 프로세스 통제 2점, 작업 편의 5점입니다. 개인 계정은 책임 추적 4점, 키 회수 4점, 프로세스 통제 4점, 작업 편의 3점입니다. 독립 맥 환경은 책임 추적 5점, 키 회수 5점, 프로세스 통제 5점, 작업 편의 2점입니다. 이 점수는 성능 수치가 아니라 선택을 돕는 운영 등급입니다.
최종 인수 기준은 네 가지입니다.
- 계정 전환 뒤 최소 작업이 새 저장소에서 실행됩니다.
- 새 사용자가 이전 사용자의 세션 로그와 Keychain에 접근하지 못합니다.
- 특정 사용자나 서비스 계정 하나만 제거해도 나머지 작업은 유지됩니다.
- 중지, 키 폐기, 저장소 접근 제거, 로그 보존을 실제로 한 번 실행합니다.
팀원이 퇴사한 뒤 에이전트 환경은 어떻게 회수하는가?
먼저 해당 개인 계정과 서비스 계정을 구분합니다. 개인 계정은 로그인 차단, 저장소 권한 제거, API Key 폐기, Keychain과 세션 자료 보존 여부 확인 순서로 회수합니다. 서비스 계정은 작업 중단, 실행 프로세스 종료, 서비스 키 교체, 자동 재시작 설정 확인까지 진행합니다.
회수 테스트의 핵심 질문은 하나입니다. “이 주체만 제거하고 나머지 개발자의 작업과 로그를 그대로 유지할 수 있는가?” 대답이 아니면 현재 구조는 공동 책임 구조이며, 장기 운영에 적합하지 않습니다.
한 대의 공용 클라우드 맥은 단기 협업에는 비용과 관리 부담을 줄일 수 있지만, 공동 홈 디렉터리, 겹치는 세션, 남아 있는 백그라운드 프로세스, 넓은 키 권한 때문에 사고 범위가 커집니다. 장기적으로 안정적인 개발 흐름이 필요하다면 NOVAKVM의 클라우드 맥 환경을 검토하면서 계정과 환경을 함께 설계해야 합니다. 특히 계정 전환 기록과 독립 환경이 필요한 팀은 한국 대상 맥 미니 렌탈 안내에서 실제 운영 단위를 먼저 정한 뒤, 필요한 경우 맥 미니 렌탈 요금 안내와 비교하는 순서가 안전합니다.
결국 공용 계정이 항상 잘못된 것은 아닙니다. 다만 사람이 바뀌어도 실행 주체, 저장소, 자격 증명, 로그, 회수 권한을 한 줄로 연결할 수 없다면 공용 구조를 유지할 이유가 줄어듭니다. 임시 테스트 환경이나 짧은 기간의 낮은 민감도 작업에는 제한적 공용 계정이 맞을 수 있지만, 여러 개발자의 지속 작업과 고객 코드를 함께 다룬다면 개인 계정 또는 독립 맥 환경이 더 책임 있는 선택입니다.