voyager 딥다이브
— 실행 중인 BEAM의 속을 화면과 AI로 들여다보기

1프로젝트 한줄 요약

웹 서비스의 응답이 느려졌다고 가정해 봅시다. 소스 코드만 읽으면 어떤 함수가 있을지는 알 수 있지만, 지금 어떤 프로세스가 메모리를 많이 쓰는지, 누구의 메시지함이 밀리는지는 알 수 없습니다. Voyager는 코드에 적힌 설계와 실제로 실행 중인 시스템 사이의 간격을 보여 주는 도구입니다.

노드 이름과 cookie로 연결하면 노드 정보, 감독 트리, 프로세스 목록·상세, ETS 목록·내용을 탐색할 수 있습니다. 화면의 진입점은 lib/voyager_web/router.ex이고, 원격 연결은 Voyager.NodeSession이 관리합니다. 프레임워크 전용 플러그인이 아니라 Erlang distribution을 사용하므로 README는 Erlang·Elixir·Gleam 시스템을 대상으로 설명합니다.

1-1. 사용자가 보는 기능과 코드의 대응

2왜 주목받는가

2026-10-23 선정 기준은 GitHub Trending Elixir Daily #7입니다. 같은 날짜의 GitHub 수치는 스타 106개, 포크 7개이고 최신 릴리스는 2026-10-20의 v0.2.0입니다. 순위나 누적 스타만으로 유입 경로·당일 증가량·흥행 원인을 확정할 수는 없습니다. 아래의 주목 요인은 README의 제품 방향과 구현을 바탕으로 한 해석입니다.

2-1. 화면 사용자와 코딩 에이전트가 같은 런타임을 봅니다

MCP 도구는 소스 검색 결과 대신 현재 연결된 노드의 실제 값을 돌려줍니다. lib/voyager/mcp/server.ex에는 6개 도구가 등록되어 있고, process_list는 화면에서도 쓰는 Voyager.Services.ProcessList.top/7을 호출합니다. 사람의 화면과 AI의 도구가 같은 조회 서비스를 공유한다는 점이 이 저장소의 중요한 제품 설계입니다.

예를 들어 AI가 메모리 문제를 조사할 때, 먼저 process_list로 후보를 좁히고 process_info로 한 프로세스를 더 자세히 볼 수 있습니다. 다만 도구가 관측값을 전달한다고 해서 AI의 원인 분석까지 맞는 것은 아닙니다. 순간값을 보고 추정한 원인은 여러 시점의 값과 코드 흐름으로 다시 검증해야 합니다.

2-2. 대상 앱에 의존성을 추가하지 않는 연결 방식

README의 “대상 노드에 설정이 필요 없다”는 설명은 대상 앱에 Voyager 패키지를 추가할 필요가 없다는 뜻으로 읽어야 합니다. 실제로는 분산 노드 이름, 올바른 cookie, 네트워크 접근, OTP 27 이상, 원격 컴파일러가 필요합니다. 연결 시 도우미 코드를 메모리에 올리므로 대상 런타임에 아무 변화도 없는 관찰은 아닙니다.

2-3. 익숙한 도구와 비교하면 무엇이 다른가?

비교 근거는 Observer 공식 문서와 LiveDashboard 공식 문서입니다. Observer에도 감독 트리와 ETS가 있고, LiveDashboard도 분산 노드를 지원합니다. 따라서 Voyager의 장점은 기존에 없던 BEAM 정보를 발명했다는 데보다, 연결과 탐색·MCP를 한 제품에 묶은 데 있습니다.

3기술 스택 전체 지도

의존성 파일의 ~>·^는 허용 범위이고 잠금 파일은 해결된 구체 버전입니다. 아래 값은 모두 커밋 39bdbae 기준이며, 지금 배포된 최신 패키지 버전을 뜻하지 않습니다. 개발 환경을 재현하려면 설명 문장보다 설정 파일과 잠금 파일을 함께 읽어야 합니다.

3-1. 백엔드: Phoenix가 화면과 도메인 기능을 함께 담당합니다

3-2. 프론트엔드: LiveView와 필요한 부분의 JavaScript

React나 Vue를 사용하는 앱으로 읽으면 흐름을 놓치기 쉽습니다. assets/js/app.js는 LiveSocket('/live', ...)을 연결하고 훅을 등록합니다. 감독 트리처럼 브라우저에서 직접 다루기 편한 부분만 SupervisionTree 훅과 Cytoscape가 담당합니다. Node.js 버전 불일치는 설정에서 확인되는 사실이며, 어느 조합이 실제로 오류를 내는지는 별도 검증이 필요합니다.

3-3. 데스크톱·빌드·검증 도구

mix.exs의 assets.build는 정적 파일 정리, 포맷, 폰트 복사, 컴파일, Tailwind·esbuild 실행을 묶습니다. assets.deploy는 여기에 phx.digest를 더합니다. mix precommit도 단순 검사 이름과 달리 포맷·의존성 잠금 정리처럼 파일을 바꾸는 작업을 포함합니다. 명령 이름만 보고 “읽기 전용 검사”라고 판단하지 않는 습관을 배울 수 있습니다.

4아키텍처 심화 분석

4-0. 시스템 전체 지도

이 그림에서 SQLite는 대상 서비스의 운영 DB가 아닙니다. Voyager 자신의 설정과 접속 정보를 보관합니다. 대상 노드의 ETS도 별개입니다. 화면을 위한 원격 조회 결과와 앱 설정의 영속 저장을 구분하면 데이터 흐름이 단순해집니다. 관찰 도구의 설계에서는 무엇을 읽을지뿐 아니라, 읽는 동안 대상 시스템에 얼마의 일을 시킬지도 결정해야 합니다.

4-1. 패턴 ① 상태 소유자 한 곳 + 교체 가능한 연결 전략

lib/voyager/application.ex의 start/2는 Vault, Repo, PubSub, Task.Supervisor, NodeSession, RateLimiter, 웹 엔드포인트, MCP 등을 :one_for_one 감독자 아래 시작합니다. 한 자식의 실패에 대해 그 자식을 재시작하는 기본 전략입니다. 이것만으로 모든 런타임 문제가 자동 해결되지는 않습니다.

lib/voyager/node_session.ex의 Voyager.NodeSession은 GenServer이며 활성 연결을 하나만 소유합니다. 이미 연결되어 있으면 {:error, :already_connected}를 반환합니다. 이 때문에 화면과 MCP는 각각 독립적인 대상 노드를 갖는 대신 동일한 현재 연결을 사용합니다.

# lib/voyager/node_session/connector.ex — 핵심 계약 발췌
@callback connect(node_name :: String.t(), cookie :: String.t(), opts :: keyword()) ::
            {:ok, node(), meta()} | {:error, term()}
@callback disconnect(node(), meta()) :: :ok
@callback subscriptions() :: [String.t()]
@callback teardown?(msg :: term(), meta()) :: boolean()

이것이 Elixir의 behaviour입니다. 연결 방식이 지켜야 할 함수 모양을 정의합니다. lib/voyager/node_session/connectors/distribution.ex는 직접 연결을, lib/voyager/node_session/connectors/ssh.ex는 SSH 연결을 구현합니다. NodeSession은 공통 계약만 사용하고, SSH 연결 핸들·로컬 포트 같은 차이는 세션의 meta에 담습니다.

연결 성공의 의미도 엄격합니다. connect_and_install/4는 전송 연결 뒤 Agent.install/1까지 성공해야 세션을 확정합니다. 설치가 실패하면 connector.disconnect/2로 되돌립니다. 이는 “소켓이 열렸다”와 “관찰할 준비가 끝났다”를 별개 단계로 다루는 작은 트랜잭션과 비슷합니다.

handle_info/2는 :nodedown과 연결 전략의 teardown?/2 결과를 처리합니다. 이벤트는 Phoenix.PubSub의 node_session 토픽으로 전달됩니다. 화면이 네트워크 상태를 제각각 추측하지 않고, 상태 소유자가 알리는 변화를 구독하는 구조입니다.

SSH의 상세 경로는 lib/voyager/services/remote_node_connector.ex의 connect/6·discover_dist_port/4에서 볼 수 있습니다. SSH로 EPMD에 접근해 대상 distribution 포트를 알아내고, 그 포트를 터널로 연결합니다. rel/app/vm.args.eex의 -proto_dist dual_tcp -epmd_module Elixir.Voyager.ProxyEpmd가 이 경로를 부팅 시 활성화합니다.

4-2. 패턴 ② 데이터를 가져오기 전에 원격에서 줄이기

프로세스가 P개인데 상위 K개만 보고 싶다면, 모든 상세 데이터를 로컬로 보내는 설계는 전송량이 큽니다. lib/voyager/services/process_list.ex의 top/7은 먼저 속성 허용 목록을 검사하고, priv/voyager_agent.erl의 proc_top/5를 원격 호출합니다. 메시지 본문·프로세스 사전·백트레이스처럼 커질 수 있는 속성은 목록 조회에서 거절합니다.

Erlang 쪽의 scan/5·fold/9·insert/7는 프로세스를 순회하며 gb_trees에 후보 K개만 유지합니다. 큰 값 우선이면 현재 후보 중 가장 작은 값을 교체합니다. 비교 트리 연산만 보면 시간은 대략 O(P log K), 후보 보관은 O(K)입니다. 실제 비용에는 속성 조회·검색 문자열 처리·프로세스 변동도 더해집니다.

# 동작을 이해하기 위한 의사 코드 — 구현 언어 문법과 무관
후보 = 비어 있는 정렬 트리
각 프로세스에 대해:
  허용된 고정 크기 속성을 읽는다
  검색 조건과 맞지 않으면 건너뛴다
  후보가 K개 미만이면 넣는다
  새 값이 현재 최하위보다 좋으면 최하위를 바꾼다
후보만 정렬해 반환한다

여기서 반환 25개가 조회 25번이라는 뜻은 아닙니다. 도우미는 전체 프로세스 표를 순회하고, 그중 일부만 보냅니다. iterator/0는 :erlang.processes_iterator/0를 우선 사용하며 없으면 목록 방식으로 돌아갑니다. 프로세스가 순회 도중 종료되면 process_info 결과를 확인해 건너뜁니다. 원자적인 전체 스냅숏은 아닙니다.

도우미 모듈은 어떻게 대상 노드에 도착하나요?

1. lib/voyager/agent.ex의 install/1이 대상 OTP 버전을 확인합니다.
2. 소스의 SHA-256 앞 12자리를 붙인 voyager_agent_… 모듈이 이미 로드됐는지 검사합니다.
3. lib/voyager/services/code_injector.ex의 load/3가 로컬에서 :epp.parse_file/2로 전처리합니다.
4. remote_compile/2가 대상의 :compile.forms/2를 호출해 BEAM 바이너리를 만듭니다.
5. remote_load/4가 대상의 :code.load_binary/3로 메모리에 올립니다. 이어서 Agent.install/1의 등록 단계가 실행됩니다.

컴파일 제한 시간은 15,000ms, 로드 제한 시간은 5,000ms입니다. 원격에서 컴파일하므로 대상에 compiler가 필요합니다. 소스별 이름을 쓰면 서로 다른 Voyager 버전이 같은 노드에 접속해도 상대의 모듈을 덮어쓰지 않습니다. register/1은 접속한 Voyager 노드를 감시하고 마지막 노드가 사라지면 종료·코드 정리 경로로 들어갑니다.

ETS도 select_chunk/6·select_spec/7·lookup/7으로 나누어 읽습니다. 잘린 값에는 $voyager_truncated 표시가 남고 다음 조회에는 continuation을 사용합니다. 다만 메시지함 조회는 런타임 API 특성상 잘라내기 전에 큰 값을 복사할 수 있습니다. 반환값 제한, 힙 제한, 시간 제한이 각각 다른 위험을 줄인다는 점을 기억해야 합니다.

4-3. 패턴 ③ 비동기 조회와 화면 상태를 분리하기

lib/voyager_web/live/processes_live.ex는 폼·정렬·현재 표시 페이지를 소유합니다. lib/voyager_web/live/processes_live/query.ex의 page/3는 검증된 입력을 조회 서비스 호출로 바꿉니다. lib/voyager_web/live/processes_live/fetcher.ex는 start/1·fetch/2·start_fetch/2로 조회 수명주기를 관리합니다.

• 브라우저의 저장된 설정을 복원한 뒤 첫 조회를 시작해, 기본값 조회와 복원값 조회가 겹치지 않게 합니다.
• debounce_refetch/1은 입력 변경을 1,500ms 모아 반복 스캔을 줄입니다.
• 한 조회가 진행 중이면 refetch_queued?에 재조회 필요 여부를 기록하고 완료 뒤 한 번 더 처리합니다.
• start_async/3로 조회하는 동안 AsyncResult.loading에 이전 성공 결과를 남깁니다.
• 자동 갱신의 제한 초과는 건너뛰고, 일시적인 시간 초과는 기존 행이 있으면 유지하면서 오류를 알립니다.

조회 상한과 표시 페이지 크기도 다릅니다. GUI의 기본 조회 상한은 100개이고 표시 페이지는 25개입니다. GUI 조회 상한은 25~5,000의 정해진 선택지, 시간 제한은 1,000~30,000ms입니다. 표의 다음 페이지는 받아 둔 결과를 잘라 보여 주며, 전체 원격 프로세스의 다음 25개를 별도로 가져오는 기능은 아닙니다.

감독 트리는 lib/voyager/services/supervision_tree/fetch.ex의 start/1에서 Task.Supervisor.async_nolink/2로 탐색을 시작합니다. 작업 실패를 화면 프로세스에 전파하지 않는 선택입니다. 브라우저 쪽 assets/js/hooks/supervision_tree/graph.js의 applyPayload는 전체 결과와 변경분을 구분해 적용합니다. 서버는 조사·상태를, Cytoscape는 배치·선택·확대 같은 시각적 상호작용을 담당합니다.

4-4. 패턴 ④ 얇은 입구 여러 개 + 공통 서비스와 사용량 제어

lib/voyager/mcp/tools/process_list.ex의 execute/2는 스키마로 받은 문자열을 미리 만든 허용 목록에 대응시키고, Remote.reply/2로 결과를 반환합니다. MCP는 기본 25개, 최대 100개이며 GUI와 상한이 다릅니다. UI 전용 상태를 서비스에 섞지 않아 MCP가 기존 서비스를 재사용할 수 있습니다.

# lib/voyager/services/rate_limiter.ex — 기본 설정 발췌
@default_config %{
  high_capacity: 5,
  high_refill: 2,
  low_capacity: 2,
  low_refill: 1,
  low_starvation_threshold: 2,
  refill_interval_ms: 1_000
}

RateLimiter.run/2는 수동 GUI·MCP 요청을 :high, 자동 갱신을 :low로 나눕니다. 1초마다 높은 우선순위 토큰 2개, 낮은 우선순위 토큰 1개를 각 용량 한도까지 채웁니다. 높은 우선순위의 잔여 토큰이 2개 미만이면 낮은 우선순위 요청을 거절합니다. 이 토큰 버킷은 요청 허용 여부를 제어합니다. 이미 시작한 RPC의 실행 시간을 제한하지는 않습니다.

lib/voyager/mcp.ex는 MCP 구성 요소들을 :one_for_all로 묶습니다. 서버·동적 감독자·엔드포인트 관리자가 함께 동작해야 하므로 앱 전체의 :one_for_one과 다른 전략을 선택한 것입니다. EndpointManager는 새 포트를 먼저 열고, commit_endpoint/3에서 설정 저장에 성공한 뒤 이전 리스너를 닫습니다. 실패 시 기존 서비스를 남기는 순서 자체가 학습할 만한 설계입니다.

MCP는 기본 설정에서 127.0.0.1:4040에 바인딩하며 lib/voyager/mcp/router.ex가 Host·Origin을 검사합니다. Origin이 없으면 허용하고, 있으면 loopback 호스트인지 확인합니다. 별도 인증은 없습니다. 따라서 로컬 경계를 전제로 한 기능이며, 이를 외부 공개 API처럼 그대로 노출해서는 안 됩니다. 구현 근거: MCP 소스.

5디렉토리 구조 해부

services라는 이름만 보면 모든 업무가 한곳에 몰린 것처럼 보일 수 있습니다. 실제로는 lib/voyager/services/node_info/, lib/voyager/services/ets/, lib/voyager/services/supervision_tree/처럼 기능별 하위 모듈이 있습니다. 폴더를 외우기보다 화면 입력, 업무 처리, 원격 호출, 결과 표현의 경계를 따라 읽는 편이 효과적입니다.

5-1. 처음 읽는 사람에게 권하는 세 경로

웹 화면은 lib/voyager_web/, 도메인·서비스는 lib/voyager/ 아래에 있습니다. lib/voyager_web/hooks/는 Elixir 서버 훅이고 assets/js/hooks/는 브라우저 훅입니다. 이름은 같아도 실행 위치와 수명주기가 다르므로 함께 묶어 생각하지 않는 것이 좋습니다.

5-2. 코드 규모는 어떻게 읽어야 하나요?

Git 추적 파일의 물리적 줄을 세면 lib/의 Elixir 구현은 165개 파일·23,260줄, test/의 Elixir 파일은 108개·15,587줄입니다. 주석·공백·HEEx 문자열을 포함하므로 순수 실행 코드량이나 테스트 커버리지 수치가 아닙니다. 언어별 전체 집계와 범위는 11절에 정리했습니다.

6학습 포인트 (기술별)

6-1. Elixir: 패턴 매칭으로 성공과 실패를 연결합니다

lib/voyager/services/code_injector.ex의 load/3는 with로 전처리와 컴파일의 성공을 연결합니다. {:ok, 값}이 이어질 때 다음 단계로 가고, 다른 모양이면 그 결과를 반환합니다. 예외만으로 실패를 전달하는 코드에 익숙하다면, 반환값 자체에 성공·실패를 드러내는 방식부터 익혀 보세요.

# lib/voyager/services/code_injector.ex — 실제 흐름 발췌
def load(node, path, macros \\ []) do
  with {:ok, forms} <- preprocess(path, macros),
       {:ok, module, binary} <- remote_compile(node, forms) do
    remote_load(node, module, Path.basename(path), binary)
  end
end

반대로 lib/voyager/erpc.ex의 safe_call/5는 원격 예외·종료·throw를 잡아 오류 튜플로 바꿉니다. 실습 아이디어: 읽기 실패, 컴파일 실패, 연결 끊김 세 경우가 어느 함수에서 어떤 튜플로 바뀌는지 표를 만드세요. 함수의 정상 경로와 오류 경로를 함께 따라가면, 문법이 실제 설계 도구가 되는 지점을 볼 수 있습니다.

6-2. OTP: 상태를 모으되, 비싼 일을 모두 직렬화하지 않습니다

NodeSession은 “지금 어디에 연결됐나”라는 공유 상태를 소유합니다. RateLimiter는 토큰 상태를 소유하지만, run/3는 토큰 획득 후 fun.()을 호출자 쪽에서 실행합니다. 긴 원격 조회 전체를 RateLimiter의 GenServer 안에서 수행하는 구조가 아닙니다. 상태를 보호하는 짧은 구간과 실제 작업을 구분하는 예입니다.

실습 아이디어: NodeSession.connect_via/4의 무한 대기 옵션과 CodeInjector의 15초·5초 제한이 각각 어느 단계의 대기를 제어하는지 표시하세요. “GenServer를 쓴다”만으로 응답성이 보장되는지, 내부 함수가 어떤 제한을 갖는지까지 질문해 보세요.

6-3. LiveView·Ecto: 입력 검증과 화면 상태를 분리합니다

lib/voyager_web/form_schemas/process_list_controls.ex는 DB 테이블이 아닌 embedded_schema로 검색어·상한·시간 제한·열 선택을 정의합니다. changeset/2가 검증하고 apply/2는 잘못된 필드의 변경을 빼서 이전 유효 값을 보존합니다. 숫자를 지우고 다시 입력하는 중에도 표가 불필요하게 무너지지 않게 하는 설계입니다.

실습 아이디어: 기존 상한이 100일 때 검색어는 유효하고 시간 제한은 잘못된 입력이라고 가정하세요. 어떤 변경이 적용되고 어떤 값은 남는지 valid_part/1까지 따라가세요. 이어서 Fetcher의 dirty?·fetched_with가 현재 폼과 마지막 결과 사이의 차이를 어떻게 표현하는지 읽어 보세요.

6-4. Erlang: 원격에서 실행할 코드는 호환성도 설계해야 합니다

도우미는 Elixir 모듈이 아니라 priv/voyager_agent.erl입니다. -module(?AGENT).의 매크로를 로컬 전처리에서 치환한 뒤 대상 노드에서 컴파일합니다. CodeInjector 문서가 ?OTP_RELEASE 조건부 사용을 경고하는 이유는 전처리 시점에 보이는 버전이 대상이 아니라 Voyager 쪽 OTP이기 때문입니다.

실습 아이디어: iterator/0의 function_exported/3 검사와 목록 대체 경로를 비교하세요. 배포 시점의 버전 숫자를 믿는 방법과, 실행 시점에 기능의 존재를 검사하는 방법의 장단점을 설명해 보세요. 모듈 이름에 소스 해시를 넣는 방식은 코드 버전과 원격 설치 상태를 함께 식별하는 아이디어로 연결됩니다.

6-5. ETS: 검색 조건은 데이터로 파싱하고, 무제한으로 읽지 않습니다

lib/voyager/services/ets/search.ex는 키 일치·접두사·필드 일치 조건을 match spec으로 바꿉니다. 키 완전 일치는 Fetch.lookup/7로 보내 키 조회 경로를 사용합니다. 고급 문자열 입력은 lib/voyager/services/ets/match_spec.ex의 parse/1이 :erl_scan.string/1·:erl_parse.parse_term/1으로 리터럴 term만 읽습니다. 임의 코드를 평가하지 않습니다.

# Erlang match spec: {키, 값}에서 값이 10보다 큰 행의 키를 선택
[{{'$1', '$2'}, [{'>', '$2', 10}], ['$1']}]

이 예의 머리 패턴은 2원소 튜플이고, 두 번째 목록은 조건, 마지막 목록은 반환할 값입니다. 파서에는 4,096바이트 상한과 atom 여유 10,000개 검사가 있습니다. erl_scan이 새 atom을 만들 수 있기 때문에 “eval하지 않는다”만으로 모든 자원 위험이 사라지지는 않습니다. 실습 아이디어: 함수 호출 문자열과 단순 term 문자열을 왜 다르게 취급하는지 관련 테스트에서 확인하세요.

6-6. MCP·Rust: 제품 경계마다 계약이 필요합니다

MCP의 schema는 허용 입력을 정의하고, lib/voyager/mcp/tools/remote.ex는 현재 연결 확인·사용량 제어·응답 변환을 묶습니다. Remote의 비공개 함수 jsonable/1에는 비 UTF-8 바이너리, 구조체, charlist 등을 JSON으로 전달하기 위한 처리가 있습니다. BEAM의 모든 값이 JSON의 기본 타입과 그대로 대응하는 것은 아니라는 점을 보여 줍니다.

Rust 쪽 rel/app/src-tauri/src/lib.rs의 run()은 ElixirKit 통신을 열고 Elixir 프로세스를 시작한 뒤 ready 메시지를 기다려 창을 만듭니다. 단순히 프로세스를 생성했다고 UI 준비가 끝난 것으로 처리하지 않습니다. 실습 아이디어: 서버 준비 전, 준비 완료, 서버 종료 때 창과 앱이 어떻게 반응하는지 호출 순서를 그려 보세요.

6-7. 테스트: 성공 사례보다 경계 조건에서 설계를 배웁니다

테스트 파일은 해당 사례를 자동 검사하도록 작성한 코드입니다. 파일의 존재만으로 모든 실행 환경에서의 통과나 모든 장애에 대한 안전성을 보장할 수는 없습니다.

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

7-1. 포트 번호가 여러 개인 이유

웹 개발 기본 포트는 config/runtime.exs의 4000이고, E2E는 4001입니다. 데스크톱 앱은 Rust 코드에서 4005를 시작점으로 사용 가능한 포트를 찾습니다. MCP는 별도 서버로 기본 4040입니다. 따라서 “Voyager의 포트”를 하나로 외우기보다 어떤 연결의 포트인지 구분해야 합니다.

7-2. 패키징 대상과 실제 배포 안내는 다릅니다

.github/workflows/build-apps.yml에는 macOS arm64·x64와 Linux arm64·x64의 빌드 행렬이 있습니다. README의 설치 안내는 Linux x64만 명시합니다. CI에 arm64 빌드 항목이 있다는 사실만으로 해당 릴리스에서 내려받을 배포 파일이 있다고 보장할 수는 없습니다. 설치 시에는 공식 다운로드 안내와 릴리스 자산을 확인하세요.

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

1번은 소스만 읽어도 완료할 수 있습니다. 실행이 필요한 과제는 개인 실습용 BEAM 노드와 민감하지 않은 데이터로 진행하세요. 앱 설치·빌드 절차는 개발 안내를 참고합니다. 화면에 나타난 값이 어느 함수에서 만들어졌는지 설명할 수 있어야 실습을 완료한 것입니다.

# 터미널: 개인 실습용 노드 시작
iex --name study@127.0.0.1 --cookie study-only-cookie

# IEx: 메시지를 소비하지 않고 대기하는 프로세스
pid = spawn(fn ->
  receive do
    :stop -> :ok
  end
end)
Enum.each(1..3, fn n -> send(pid, {:study_message, n}) end)
Process.info(pid, :message_queue_len)
# 기대: {:message_queue_len, 3}

# 관찰을 마치면 선택적 receive가 :stop을 받아 종료
send(pid, :stop)

# IEx: 실습용 테이블과 데이터 100개
table = :ets.new(:voyager_study, [:named_table, :set, :public])
Enum.each(1..100, fn n -> :ets.insert(table, {n, "item-#{n}"}) end)
:ets.info(table, :size)
# 기대: 100

# 페이지·검색 관찰 후 정리
:ets.delete(table)

{
  "name": "process_list",
  "arguments": {
    "limit": 10,
    "sort_by": "memory",
    "direction": "desc",
    "attrs": ["memory", "message_queue_len", "registered_name"]
  }
}

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

Elixir가 처음이라면 거대한 감독 트리 탐색부터 시작할 필요는 없습니다. 반환값을 읽는 연습에서 출발해 상태, 원격 호출, 화면, 도구 계약 순서로 넓혀 가세요. 매주 기능을 많이 구현하기보다 설명 가능한 작은 결과물을 하나씩 남기는 계획입니다.

9-1. 관심 분야에 따라 더 깊게 들어가기

• 백엔드: rate limit과 동시성 제한의 차이, 시간 초과 뒤 남는 원격 작업, 일부 실패를 포함하는 결과 표현을 공부하세요.
• 프론트엔드: 서버 상태와 브라우저 상태의 소유권, 전체 그래프 교체와 변경분 적용의 차이, 큰 그래프의 배치 비용을 비교하세요.
• 인프라: 분산 프로토콜의 네트워크 경로, SSH 터널의 수명주기, 여러 CPU 아키텍처의 패키징을 살펴보세요.
• AI 도구: 도구 설명·스키마·반환값을 사람이 오해 없이 읽을 수 있는지, 잘린 데이터 표시를 에이전트가 이해하는지 검토하세요.

10핵심 키워드 사전

11참고 링크

11-1. 프로젝트와 핵심 소스

• 공식 저장소 · 공식 웹사이트 · v0.2.0 릴리스
• README · 노드 연결 안내 · 개발 환경 안내
• Elixir 의존성 선언 · Elixir 잠금 파일 · 프론트엔드 의존성
• 현재 연결과 실패 처리 · 원격 컴파일·메모리 로드
• Erlang 도우미 모듈 · 조회 우선순위·토큰 버킷
• 비동기 프로세스 목록 갱신 · Tauri와 Elixir의 시작 순서
• CI 검사 · OS·아키텍처별 패키징 · Voyager User License 원문

11-2. 관련 기술의 공식 문서

• GenServer · Supervisor · Task.Supervisor
• 분산 Erlang · erpc · ETS · match spec 문법
• Phoenix LiveView · Ecto changeset · Cytoscape.js
• Tauri 2 · ElixirKit의 Tauri 연결 안내 · MCP 개념과 구조
• Observer 사용 안내 · Phoenix LiveDashboard · GitHub Trending Elixir Daily

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

11-3. 언어별 물리적 줄 수

커밋 39bdbae의 Git 추적 파일 중 해당 확장자의 텍스트를 줄 단위로 집계했습니다. 공백·주석·테스트·설정 및 해당 확장자의 벤더 파일을 포함하고, 이미지·폰트·잠금 파일은 아래 표의 집계 대상이 아닙니다. HEEx는 Elixir 문자열 안에도 있으므로 HTML 템플릿이 174줄뿐이라는 뜻으로 해석하면 안 됩니다.

범위를 좁히면 lib/의 .ex는 23,260줄, test/의 .ex·.exs는 15,587줄입니다. 테스트 쪽 물리적 줄 수는 구현 쪽의 약 67%이지만, 이는 커버리지나 품질 점수가 아닙니다. Rust와 Swift가 상대적으로 작다는 점은 이 앱의 업무 로직이 주로 Elixir 쪽에 있다는 구조와도 맞습니다.