ds-harness-remote 딥다이브
— 내 코딩 에이전트까지 이어지는 암호화 통로

1프로젝트 한줄 요약

ds-harness-remote는 DeepSeek Harness의 플러그인으로 동작하는 Host와 여러 Client를 연결합니다. 사용자가 Android에서 프롬프트를 보내면 실제 작업은 Host의 Harness 또는 연결된 에이전트 백엔드가 수행합니다. 작업 환경을 휴대전화로 옮기는 대신, 원래 컴퓨터의 작업 환경에 암호화된 요청을 보내는 구조입니다.

1-1. 한 번의 요청이 지나가는 길

1. Host와 Client가 같은 Server에 각자의 기기 자격 증명으로 연결합니다.
2. Client가 Host를 선택하고, Host는 계정 소속과 고정된 상대 공개키를 확인합니다.
3. 두 기기가 Noise IK 핸드셰이크를 마쳐 연결 전용 암호화 상태를 만듭니다.
4. Client가 RPC 요청을 전송하고, Host가 허용된 Harness·Codex·ACP 기능으로 전달합니다.
5. 결과와 실시간 이벤트가 다시 암호화되어 Client 화면에 나타납니다.

Desktop에서는 Harness의 기존 UI를 재사용하고, Android는 React Native 앱을 제공합니다. VS Code 확장과 Chrome/Edge 확장도 포함되지만 역할이 다릅니다. apps/browser는 온라인 Host를 골라 Remote Web을 여는 입구이며, 자체 대화 UI나 원격 전송 엔진을 구현한 브라우저 앱은 아닙니다.

2왜 주목받는가

2-1. 선정 사실과 관심의 이유를 구분하기

이 글의 선정 근거는 TrendShift Daily #16입니다. 2026-10-23 GitHub 기준 스타 699, 포크 70이며, 생성일은 2026-08-14입니다. 이 숫자만으로 사용자 증가 속도나 인기의 원인을 확정할 수는 없습니다. 아래의 주목 포인트는 README와 구현을 바탕으로 한 기술적 해석입니다.

코딩 에이전트는 프로젝트 파일, 터미널, 인증 상태, 대화 이력에 의존합니다. 이동할 때마다 다른 기기에 환경을 복제하면 같은 작업을 이어 가기 어렵습니다. 이 프로젝트는 오래 실행되는 Host에 여러 화면을 연결해 그 마찰을 줄이려 합니다.

주목할 지점은 원격 접속 자체보다, 코딩 에이전트의 세션·승인·파일·터미널을 연결 단위로 다루는 설계입니다. ConnectionController.acceptOne()은 인증된 연결마다 별도의 router를 만들고, HarnessRemoteBridge는 스트림과 큰 응답의 전송 상태를 관리합니다. 채팅 화면만 붙이는 일과는 구현 범위가 다릅니다.

2-2. 다른 접근과 비교하면 보이는 위치

아래 표는 특정 상용 제품의 최신 기능표가 아니라 접근 방식의 비교입니다. 우열은 원격으로 무엇을 하려는지에 따라 달라집니다.

2-3. P2P 우선이라는 설명의 정확한 범위

공유 전송 구현인 AdaptiveTransport의 기본 선호 순서는 ['lan', 'p2p', 'turn', 'relay']입니다. 하지만 실제 경로는 양쪽 capability와 Server 지원을 협상해 정합니다. 직접 통신을 시도한다고 항상 직접 연결되는 것은 아닙니다.

2-4. 최신 릴리스에서 읽을 수 있는 실제 문제

.github/release-notes.md의 v0.5.18 기록은 Android 로그인 방식 자동 조회, 서버 변경 후 늦게 도착한 로그인 결과의 격리, 도구 응답 파싱 경계, 대기 메시지 표시 수정 등을 설명합니다. 이는 새로운 네트워크 기술만큼 비동기 상태의 일관성이 제품 품질에 중요함을 보여 줍니다.

해당 릴리스 기록에 따르면 전체 794개 테스트가 통과했습니다. v0.5.18에서 추가된 실기기·기기 간 검증은 없다고 명시되어 있으므로, 자동화 테스트 결과와 실환경 검증 범위를 구분해야 합니다.

3기술 스택 전체 지도

루트 package.json과 각 하위 패키지는 버전 0.5.18로 맞춰져 있습니다. pnpm-workspace.yaml은 apps/*, packages/*, examples/*를 묶습니다. 여러 앱이 같은 프로토콜을 공유하되, 각 실행 환경의 의존성과 버전은 따로 관리합니다.

3-1. 백엔드와 Host 플러그인

근거 파일은 apps/server/package.json, packages/plugin/package.json, packages/crypto/package.json입니다. 자체 호스팅 서버는 Express·NestJS 없이 node:http의 createServer()를 사용합니다. apps/server/src/store.ts는 데이터베이스 대신 JSON 파일과 메모리 상태를 조합합니다.

3-2. 프론트엔드와 기기별 접속면

3-3. 인프라·빌드·배포

• 워크스페이스: 루트는 packageManager: pnpm@9.15.4를 지정합니다. 공유 패키지 의존성은 workspace:*로 같은 저장소의 코드를 가리킵니다.
• 타입 검사: tsconfig.base.json은 target: ES2022, module: NodeNext, strict: true입니다. Android는 TypeScript ~6.0.3, 공유 패키지들은 주로 ^5.7.3을 선언합니다.
• 번들: Plugin과 브라우저 확장은 esbuild ^0.25.0을 사용합니다. Android는 Expo·Metro 계열의 별도 빌드 경로를 가집니다.
• 테스트: 여러 패키지가 Vitest ^2.1.8을 선언합니다. 요청 취소·연결 종료 같은 핵심 동작의 검증 사례를 담고 있습니다.
• 컨테이너: apps/server/Dockerfile은 node:22-bookworm-slim으로 빌드·실행 단계를 나눕니다. 실행 사용자는 node입니다.
• CI: .github/workflows/ci.yml은 Node 22, .github/workflows/release.yml의 주 릴리스 작업은 Node 24, Android 작업은 Node 22와 Java 17을 사용합니다.

루트 package.json에는 의도적으로 scripts가 없습니다. AGENTS.md의 설명에 따르면 Harness가 GitHub에서 플러그인을 설치할 때 루트 패키지를 사용하기 때문입니다. 커밋된 packages/plugin/dist/index.js와 packages/plugin/dist/client.github.js는 배포 진입점이며, CI가 다시 만든 번들과 차이가 없는지 검사합니다. 일반적인 “모든 dist는 무시한다” 규칙을 그대로 적용할 수 없는 사례입니다.

4아키텍처 심화 분석

위 도식의 보안 전송 래퍼는 역할을 나타냅니다. 실제 구현은 Client마다 접속 코드가 있으며, Desktop 쪽 대표 구현이 ClientSecureTransport입니다. Server와 오가는 제어 연결과 기기끼리 보내는 업무 데이터는 개념적으로 분리되지만, Relay를 선택하면 둘 다 같은 WebSocket을 이용할 수 있습니다.

4-1. 설계 패턴 ① 인터페이스로 경로를 교체한다

packages/webrtc/src/transport.ts의 RemoteTransport는 바이트를 보내고 받는 최소 약속을 정의합니다. RPC 계층은 현재 경로가 WebRTC인지 Relay인지 몰라도 이 약속만 사용하면 됩니다.

// 원본 RemoteTransport에서 핵심 메서드만 발췌
export interface RemoteTransport {
  connect(): Promise<void>
  send(data: Uint8Array): Promise<void>
  onMessage(cb: (data: Uint8Array) => void): () => void
  onClose?(cb: () => void): () => void
  close(): Promise<void>
  getStats(): TransportStats
}

AdaptiveTransport.negotiate()는 capability로 걸러진 선호 경로를 이용합니다. WebRTC를 쓸 수 있으면 tryWebRtc()를 호출하고, 협상 실패 시 허용된 Relay로 내려갑니다. forceRelay: true는 선호 경로를 Relay 하나로 제한합니다.

업무 요청은 같은 형태를 유지하고, 연결 경로와 암호화는 그 아래 계층에서 책임집니다. 이런 분리는 새 전송 수단을 추가할 때 UI나 모든 RPC 호출부를 바꾸지 않게 해 줍니다.

4-2. 설계 패턴 ② 전송 위에 인증 암호화 래퍼를 씌운다

packages/plugin/src/client-secure-transport.ts의 ClientSecureTransport는 내부 SecureHandshakeTransport를 감싸면서 자신도 RemoteTransport를 구현합니다. 기존 인터페이스를 유지한 채 보안 책임을 추가하는 데코레이터 패턴으로 읽을 수 있습니다.

1. connect()가 내부 전송을 연결하고, 반환된 기기 ID가 예상한 Host·Client와 같은지 확인합니다.
2. NoiseIkSession을 만들고 createNoisePrologue()에 연결 ID와 두 기기의 ID를 묶습니다.
3. waitForResponder()가 두 번째 핸드셰이크 메시지를 기다립니다. 기본 제한 시간은 10초입니다.
4. send()는 메시지를 분할한 뒤 각 조각을 암호화합니다. 수신은 복호화 후 재조립합니다.
5. 인증 실패나 분할 형식 오류가 발생하면 연결을 닫아, 불확실한 상태에서 업무 요청을 계속 처리하지 않습니다.

packages/crypto/src/noise.ts는 암호 모음을 Noise_IK_25519_ChaChaPoly_SHA256으로 고정합니다. verifyRemoteStatic()은 상대의 정적 공개키가 로컬에서 신뢰한 키와 같은지 확인합니다. 계정 로그인 성공만으로 상대 기기의 정체까지 보장되지는 않는다는 뜻입니다.

// createNoisePrologue()가 만드는 문맥의 형태
DSH-REMOTE\0v=1\0connection=...\0host=...\0client=...

// 메시지의 계층별 변화
RPC JSON 바이트
  -> SecureMessageCodec.encode()
  -> NoiseIkSession.encrypt()
  -> DataChannel 또는 Relay
  -> NoiseIkSession.decrypt()
  -> SecureMessageCodec.decode()
  -> RPC 요청 처리

Noise 공식 명세는 메시지 상한을 65,535바이트로 정합니다. 그래서 이 프로젝트의 SecureMessageCodec은 48 KiB보다 큰 메시지를 먼저 분할합니다. 완성 메시지 상한은 4 MiB, 동시에 조립할 수 있는 메시지는 8개입니다.

분할 헤더에는 메시지 ID·조각 순번·전체 조각 수·전체 길이가 들어갑니다. decode()는 순번과 길이를 검증하므로, 조각을 모으는 배열 하나로 끝나는 구현이 아닙니다.

4-3. 설계 패턴 ③ 요청 ID와 수명으로 비동기를 관리한다

packages/client-core/src/index.ts의 RemoteClientCore.rpc()는 pending: Map<string, PendingCall>에 요청별 완료 함수와 타이머를 넣습니다. 응답은 requestId로 원래 요청을 찾아 완료시킵니다. 응답 순서가 바뀌어도 요청을 구별할 수 있습니다.

// 원본 제어 흐름을 줄여 표현한 학습용 의사 코드
요청 A 등록 -> pending[A] = 완료 함수 + 타이머 + 취소 해제 함수
요청 B 등록 -> pending[B] = 완료 함수 + 타이머 + 취소 해제 함수
응답 B 도착 -> takePending(B) -> B만 완료
A 취소      -> takePending(A) -> A만 거절
늦은 응답 A -> 등록된 요청 없음 -> 무시

takePending()은 Map에서 제거하고 타이머와 취소 리스너를 함께 정리합니다. 기본 RPC 제한 시간은 30초이며, 전송 자체를 await한 뒤 기다리지 않습니다. send()가 끝나지 않는 상황에서도 타임아웃·취소·연결 종료가 호출자를 풀어 줄 수 있게 한 선택입니다.

여기서의 취소는 우선 Client의 기다림을 끝내는 동작입니다. 이것만 보고 Host의 실행 중인 작업도 반드시 취소됐다고 말하면 안 됩니다. 작업 중단은 session/cancel 등 해당 업무 API의 의미를 따로 확인해야 합니다.

4-4. 설계 패턴 ④ 연결마다 권한과 상태를 격리한다

packages/plugin/src/connection-controller.ts의 acceptOne()은 Noise 프로토콜, 비어 있지 않은 연결·membership 문맥, IdentityStore.isTrusted()를 확인합니다. 통과한 연결에는 createRouter({ connectionId, peerDeviceId }, ...)로 router를 만듭니다.

이후 packages/plugin/src/harness-remote-bridge.ts의 HarnessRemoteBridge.call()이 HARNESS_REMOTE_ALLOWLIST와 입력 스키마를 검사합니다. 예를 들어 일반 설정 API가 허용 목록에 있어도 Remote 자신의 설정을 바꾸는 요청은 별도로 거절합니다.

// HarnessRemoteBridge.call()의 원본 일부
if (['settings/update', 'settings/replace', 'settings/mutate'].includes(params.endpoint)) {
  const args = requestArgs(params.payload)
  if (args.ns === 'ds-harness-remote' || args.ns === 'dsh-remote') {
    throw new RpcError('PERMISSION_DENIED',
      'Remote access settings can only be changed locally on the Host.')
  }
}

이 검사는 원격 접속자가 터미널·포트 접근 정책을 원격에서 다시 넓히는 것을 막는 경계입니다. ACP도 packages/plugin/src/acp/method-policy.ts의 parseAcpCall()에서 메서드와 매개변수를 제한합니다. 암호화와 허용 목록은 서로 다른 문제를 해결합니다.

5디렉토리 구조 해부

5-1. 폴더 이름보다 의존성 방향을 본다

protocol은 통신 양쪽이 동의해야 할 데이터 형태를 제공합니다. crypto는 기기 키와 암호화 상태를 담당하고, webrtc는 전송 경로를 담당합니다. client-core는 그 위에서 요청·응답과 업무 이벤트를 연결합니다.

앱은 이 공유 코드를 조합하되 로그인 UI, 네이티브 보관소, 네트워크 생명주기 같은 플랫폼별 문제를 직접 처리합니다. Host 플러그인은 공식 Harness API와 외부 에이전트 프로세스에 접속하므로 가장 많은 업무 코드가 모입니다. 폴더를 분리했다는 사실보다 어느 계층이 어느 사실을 알아야 하는가가 중요합니다.

5-2. 커밋 기준 코드 규모

집계 대상은 커밋 fac5e60의 추적 파일이며, 확장자별 물리적 줄 수를 기준으로 합니다. 빈 줄·주석·테스트를 포함하며, packages/plugin/dist/ 아래 배포 번들은 별도 항목입니다. JSON·YAML·Markdown·이미지는 아래 언어별 합계에 포함하지 않았습니다.

TypeScript와 TSX를 합치면 406개 파일, 101,648줄입니다. 그 안의 TypeScript 테스트는 tests·__tests__ 경로나 .test. 파일명 기준 117개 파일, 31,276줄입니다. 줄 수는 구현의 복잡도나 품질 점수가 아니라, 읽기 범위를 가늠하기 위한 대략적인 규모입니다.

같은 기준으로 Plugin의 TypeScript·TSX는 테스트 포함 51,555줄, Android는 32,552줄입니다. 처음부터 화면 전체를 읽기보다, 요청 하나를 여러 계층에 걸쳐 추적하는 편이 낫습니다.

6학습 포인트 (기술별)

이 레포에서 가장 좋은 공부 방법은 정상 요청 하나와 실패 요청 하나를 같은 경로로 따라가는 것입니다. 예를 들어 “세션 목록이 보인다”와 “세션 목록 응답 전에 연결이 끊긴다”를 함께 그려 보세요. 오류 처리가 어느 클래스의 책임인지 선명해집니다.

6-1. TypeScript와 Zod: 컴파일 뒤에도 입력은 검증해야 한다

TypeScript의 타입은 개발 중 실수를 줄여 주지만 네트워크에서 도착한 JSON이 그 타입이라고 보장하지 않습니다. packages/protocol/src/index.ts의 parseControlFrame()은 바깥 메시지 형태를 검사한 뒤, controlFramePayloadSchemas에서 종류별 본문 스키마를 선택합니다.

// 원본 parseControlFrame()의 핵심
const frame = controlFrameSchema.parse(input)
const payloadSchema = controlFramePayloadSchemas[frame.type]
if (payloadSchema) {
  return { ...frame, payload: payloadSchema.parse(frame.payload) }
}
return frame

실습 아이디어: relayPayloadSchema를 읽고 counter가 음수·소수·문자열인 입력을 각각 종이에 써 보세요. 어떤 조건이 거절하는지 표시하면 “타입이 숫자”와 “프로토콜에서 유효한 숫자”의 차이를 이해할 수 있습니다.

6-2. Promise와 AbortSignal: 완료 경로를 빠짐없이 닫는다

RemoteClientCore는 성공, RPC 오류, 타임아웃, 취소, 전송 실패, 연결 종료를 처리합니다. 등록된 요청의 완료·실패 경로가 takePending()를 거쳐 정리되도록 만든 점을 보세요. “응답이 오면 resolve한다”만 구현하면 나머지 경로의 타이머·리스너·Map 항목이 남을 수 있습니다.

실습 아이디어: packages/client-core/tests/client-core.test.ts에서 LoopbackTransport를 읽고, 실제 네트워크 없이도 연결 종료를 표현하는 drop()을 찾아보세요. 이는 테스트가 외부 서비스 대신 작은 인터페이스를 대체하는 방법입니다.

6-3. WebSocket와 역압력: 보내기만 빨라서는 안 된다

packages/webrtc/src/websocket-backpressure.ts의 waitForRelayCapacity()는 bufferedAmount가 512 KiB를 초과하면 기다립니다. 10초를 넘기거나 소켓이 닫히면 실패합니다. 소비자가 느릴 때 생산자의 속도를 조절하는 장치입니다.

SerialSend.run()은 Promise 체인으로 송신을 순서대로 실행하고, 대기량을 최대 8 MiB·256건으로 제한합니다. 암호화와 송신 순서를 함께 지켜야 nonce 상태와 실제 전송 순서가 어긋나지 않습니다.

// SerialSend.run()의 원본 핵심
if (this.bytes + bytes > 8 * 1024 * 1024 || this.count >= 256) {
  throw new Error('Encrypted send queue exceeds its limit')
}
this.bytes += bytes; this.count += 1
const task = this.tail.then(send)
this.tail = task.catch(() => undefined)
try { await task } finally { this.bytes -= bytes; this.count -= 1 }

실습 아이디어: 첫 작업이 대기 중일 때 두 번째 작업이 시작되는지, 첫 작업이 실패하면 세 번째 작업은 계속 가능한지 추적해 보세요. packages/webrtc/tests/serial-send.test.ts가 순서와 대기량을 검증하는 이유도 설명할 수 있어야 합니다.

6-4. WebRTC: 후보를 모으는 것과 암호화는 다른 책임이다

packages/webrtc/src/rtc-adapter.ts는 실행 환경의 WebRTC 구현을 추상화하고, packages/webrtc/src/rtc-data-channel.ts는 실제 DataChannel과 ICE 협상을 다룹니다. packages/webrtc/src/adaptive-transport.ts는 그 결과를 업무 전송 경로로 선택합니다.

ICE는 연결 가능한 후보를 찾는 절차이고, STUN은 외부에서 보이는 주소를 찾는 데 도움을 주며, TURN은 직접 통신이 어려울 때 중계합니다. 이 기본 구분은 MDN의 WebRTC 프로토콜 설명에서 확인할 수 있습니다.

실습 아이디어: tryWebRtc()에서 ICE 서버 조회가 실패했을 때의 코드를 읽어 보세요. 빈 ICE 서버 목록으로도 직접 연결 후보를 시도하는 흐름과, 최종 협상 실패 후 Relay를 선택하는 흐름을 두 단계로 나눠 그립니다.

6-5. 암호화: 원시 함수와 실제 보안 채널을 구별한다

packages/crypto/src/index.ts에는 deriveSharedKey()와 encryptFrame()도 있습니다. 하지만 현재 Desktop 원격 연결 경로의 핵심은 packages/crypto/src/noise.ts의 NoiseIkSession입니다. 폴더에서 함수 하나를 찾았다는 이유로 그 함수가 현재 통신 전체를 구현한다고 판단하면 안 됩니다.

실습 아이디어: packages/crypto/tests/noise.test.ts와 fixtures/crypto/v1/noise-ik.json을 비교해 보세요. 고정 입력과 기대 출력이 왜 다른 구현끼리의 호환성을 확인하는 데 유용한지 적습니다. 학습용 고정 난수와 실제 실행용 난수의 목적도 구분해야 합니다.

6-6. React Native와 상태 저장소: 늦은 결과를 거절한다

apps/android/src/state/account-actions.ts의 createAccountActions()는 accountGeneration을 증가시키고, captureAccount()로 현재 계정·설정·identity가 여전히 같은지 확인합니다. exclusive()는 자격 증명 관련 쓰기를 Promise 체인으로 순서화합니다.

사용자가 A 서버 로그인 도중 B 서버로 전환한 뒤 A의 응답이 도착할 수 있습니다. 이때 단순히 “가장 늦게 도착한 값을 저장”하면 새 서버의 상태를 덮어씁니다. 요청을 시작한 세대와 현재 세대가 같은지 확인하는 방식으로 그런 결과를 걸러낼 수 있습니다.

실습 아이디어: A 로그인 시작 → B 서버 선택 → B 로그인 완료 → A 응답 도착의 시간표를 만드세요. 각 단계의 세대 번호를 쓰고, 어떤 결과가 보관소와 화면 상태를 바꿀 수 있는지 표시합니다.

6-7. 파일 보관과 CI: 운영 가능한 작은 시스템을 읽는다

apps/server/src/store.ts의 Store.save()는 임시 파일을 쓰고 renameSync()로 교체합니다. 폴더 생성은 0o700, 파일 생성은 0o600을 지정합니다. 장기 보관되는 토큰은 원문 대신 SHA-256 다이제스트로 색인합니다.

파일 교체 방식이 곧 다중 프로세스 데이터베이스의 동시성 보장을 뜻하지는 않습니다. 이 구현은 단일 프로세스를 전제로 하며, 동기 파일 쓰기와 상태 크기도 운영 특성에 영향을 줍니다. 실습 아이디어: 두 프로세스가 같은 파일을 따로 읽고 저장한다면 어떤 갱신이 사라질 수 있는지 그립니다.

CI의 전체 빌드에는 --workspace-concurrency=1이 지정되어 있습니다. 워크플로 주석은 Android 사전 빌드가 공유 패키지를 다시 컴파일하므로, Plugin 번들이 작성 중인 dist를 읽지 않도록 직렬화한다고 설명합니다. 빌드 도구의 빠른 병렬 실행도 산출물 간 의존성을 무시할 수 없다는 사례입니다.

7하드웨어 / 시스템 요구사항

원격 접속 프로그램의 자원 요구량과, 그 뒤에서 실행되는 AI 모델의 자원 요구량은 별개입니다. 이 저장소 자체가 모델 가중치를 제공하거나 GPU 추론 서버를 구현하는 것은 아닙니다. Host에서 사용하는 모델 제공자·도구·프로젝트에 따라 추가 자원이 필요합니다.

7-1. 네트워크는 Host와 Server를 구별한다

README의 “공개 수신 포트가 필요 없다”는 설명은 Harness Host에 대한 것입니다. Client와 Host가 외부로 연결하더라도 중계 Server 자체에는 접근 가능한 주소가 있어야 합니다. 자체 호스팅 시에는 Server의 공개 경로와 Host의 내부 작업 환경을 나눠 설계해야 합니다.

apps/server/compose.yaml의 기본 호스트 바인딩은 127.0.0.1이고, 컨테이너 안의 DSH_SERVER_HOST는 0.0.0.0입니다. 이 둘은 모순이 아닙니다. 앞의 값은 호스트에서 공개할 인터페이스, 뒤의 값은 컨테이너 내부에서 수신할 인터페이스입니다.

서버 README는 공개 서비스 앞에 HTTPS 역방향 프록시를 두고, /ws/v1/connect의 WebSocket Upgrade와 75초보다 긴 유휴 시간을 지원하도록 안내합니다. 실제 Gateway의 ping 주기는 25초, 응답이 없을 때의 종료 기준은 75초입니다.

7-2. 코드 상한은 성능 보장 수치가 아니다

256개를 허용하는 검사문이 있다고 256개 접속에서 일정한 지연 시간을 보장하는 것은 아닙니다. 현재의 하드 상한, 안정적으로 처리 가능한 부하, 실제 운영 용량은 서로 다른 수치입니다. 특히 큰 대화 이력과 파일 전송은 짧은 텍스트 프롬프트보다 메모리·중계 대역폭을 더 사용합니다.

8직접 해볼 수 있는 실습 과제

아래 과제는 읽기와 계산으로 완성할 수 있습니다. 저장소 코드나 설치기를 실행할 필요가 없습니다. 각 과제의 목표는 기능 이름을 설명하는 데서 끝나지 않고, 실패할 때 어느 상태가 바뀌는지 보여 주는 것입니다.

9관련 기술 심화 학습 로드맵

주차는 권장 순서이며, 정해진 학습 시간이나 숙련 속도를 보장하는 계획은 아닙니다. JavaScript의 함수·배열·객체를 읽을 수 있다면 1주차부터, Promise와 타입을 이미 이해한다면 2주차부터 시작할 수 있습니다.

학습 순서는 화면의 화려함보다, 데이터의 형태와 요청의 수명을 먼저 이해하는 쪽으로 잡는 것이 좋습니다. 화면부터 읽으면 접속·승인·재연결 상태가 한꺼번에 나타납니다. 바닥의 인터페이스와 정리 규칙을 알고 돌아오면 같은 UI 코드가 훨씬 단순해집니다.

9-1. 다음 단계로 넘어가는 기준

• 네트워크 단계 전: 타임아웃과 서버 작업 취소의 차이를 설명할 수 있습니다.
• 암호화 단계 후: Server가 볼 수 있는 연결 메타데이터와 업무 내용을 구별할 수 있습니다.
• 모바일 단계 후: 화면 상태, 자격 증명, Host의 권위 있는 대화 상태를 구분할 수 있습니다.
• 마지막 단계: README의 제품 지원, 저장소에 포함된 구현, 실제 검증 기록을 따로 말할 수 있습니다.

암호 알고리즘을 새로 설계하거나 운영 서비스를 재현하는 일은 이 로드맵의 선행 조건이 아닙니다. 먼저 이미 있는 코드에서 실패 경계와 자원 상한을 읽을 수 있는 수준을 목표로 삼습니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 커밋 기준 문서

• 공식 저장소 · 분석한 커밋의 파일 목록 · v0.5.18 릴리스
• 제품 README · v0.5.18 변경·검증 기록
• 프로토콜 계약 · 암호화·메타데이터·키 수명 문서 · 네트워크·재연결 문서
• 자체 호스팅 서버 안내 · 구현 범위와 시점별 검증 기록

11-2. 본문의 근거가 되는 핵심 소스

• RemoteClientCore · 업무 Gateway와 capability 발견
• AdaptiveTransport · 송신 순서·대기량 제한
• NoiseIkSession · 프레임 스키마·보안 메시지 분할
• 연결별 router·신뢰 검사 · Harness API 허용 목록
• 자체 호스팅 Relay · 기기·토큰 파일 보관
• Android 계정 전환·비동기 격리 · CI 구성

11-3. 관련 기술의 공식 학습 자료

• Noise 공식 명세 — IK 패턴·메시지 상한·prologue의 정의
• MDN WebRTC 프로토콜 — ICE·STUN·NAT·TURN의 구분
• TypeScript 공식 핸드북 — 인터페이스·유니언·제네릭
• Expo 공식 문서 — 네이티브 모듈과 개발 빌드 학습
• pnpm 9 워크스페이스 문서 — workspace 의존성의 의미
• GitHub의 저장소 라이선스 안내 — 저장소 메타와 실제 라이선스 파일을 확인할 때 참고
• TrendShift — 2026-10-23 Daily #16 선정 출처

11-4. 현재 상태 (2026-10-23 확인)

저장소 메타데이터는 2026-10-23 GitHub 기준입니다. 코드·설정·줄 수의 기준은 커밋 fac5e60입니다. 릴리스 검증 결과의 출처는 아래에 명시한 릴리스 기록입니다.