codebase-memory-mcp: 코드베이스를 지식 그래프로 인덱싱하는 코드 인텔리전스 MCP 서버 (및 기반 연구)

9bow · 6월 29, 2026, 12:30오후

codebase-memory-mcp 소개

AI 코딩 에이전트에게 "이 함수를 수정하면 어디가 깨지나요?" 같은 질문을 던져 본 적이 있다면, 에이전트가 grep으로 함수 이름을 찾고, 매칭된 파일을 하나씩 열어 읽고, 다시 참조를 따라가며 같은 과정을 반복하는 모습을 보았을 것입니다. 작은 프로젝트에서는 잘 동작하지만, 저장소가 커질수록 이 텍스트 기반 탐색은 답 하나를 얻기까지 수십 번의 도구 호출과 수십만 토큰을 소모합니다.

문제의 근원은 일종의 미스매치입니다. LLM 에이전트는 비정형 텍스트 위에서 동작하지만, 개발자가 던지는 질문은 본질적으로 구조적입니다. 호출 그래프(call graph), 의존성 사슬, 모듈 경계, 영향도 분석(impact analysis)이 모두 그렇습니다. 텍스트 검색은 참조를 한 단계씩 따라가지 않으면 이런 전이적(transitive) 관계를 포착하지 못하고, 매 단계마다 토큰을 더 쓰며 맥락을 잃을 위험도 커집니다. 최근 실증 분석들은 캐싱을 적용해도 입력 토큰이 에이전트형 코딩 작업 비용의 대부분을 차지한다고 보고합니다.

이를 해결하려는 기존 접근들도 한계가 뚜렷합니다. 코드 속성 그래프(Code Property Graph)나 CodeQL 같은 정적 분석 그래프는 강력하지만, 전용 데이터베이스와 도메인 특화 질의 언어를 요구하는 무거운 도구라 LLM이 직접 소비하도록 설계되지 않았습니다. 임베딩 기반 RAG는 의미적 유사도 검색에는 강하지만, "이 함수를 누가 호출하는가" 같은 관계형 질의에는 약합니다.

codebase-memory-mcp는 발상을 바꿔, 코드의 구조 자체를 질의 가능한 1급(first-class) 지식 그래프(knowledge graph) 로 만들고 이를 MCP(Model Context Protocol)로 LLM 에이전트에 직접 노출합니다. 함수와 클래스, 호출 체인, HTTP 라우트, 서비스 간 연결을 그래프 노드와 엣지로 표현해 두면, 에이전트는 파일을 하나씩 읽는 대신 구조적 질의 한 번으로 답을 얻습니다.

이 프로젝트는 베를린 샤리테(Charité) 의대 등 독일 연구진이 공개한 오픈소스로, 설계와 벤치마크는 프리프린트 논문 Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP(arXiv:2603.27277)에 정리되어 있습니다. 의존성 없는 단일 정적 C 바이너리로 배포되어 Docker나 런타임 의존성, API 키가 필요 없고, 모든 처리가 100% 로컬에서 이루어져 코드가 사용자의 기기를 벗어나지 않습니다. 본 게시물에서는 codebase-memory-mcp가 코드베이스를 어떻게 그래프로 만드는지, 어떤 도구를 제공하는지, 보안은 어떻게 다루는지, 그리고 논문이 보고한 성능과 한계까지 정리합니다.

아키텍처: 파싱, 빌드, 서빙의 3단계

codebase-memory-mcp의 아키텍처는 세 단계 파이프라인으로 이루어집니다. 파싱(Parse) 단계는 tree-sitter AST(추상 구문 트리)를 순회하며 정의(함수, 메서드, 클래스, 인터페이스, 열거형, 타입과 그 시그니처/반환 타입/리시버/데코레이터/복잡도/export 여부), 호출 지점, import(8개 언어별 파서와 범용 폴백), 참조, 트레잇 구현을 추출합니다. 빌드(Build) 단계는 추출된 엔터티를 그래프로 조립해 SQLite에 기록하고, 서빙(Serve) 단계는 완성된 그래프를 14개의 MCP 도구로 노출해 에이전트가 표준 도구 호출로 질의하게 합니다.

tree-sitter 문법은 C 소스로 바이너리에 직접 내장(vendoring)됩니다. 지원 언어 수는 버전에 따라 다른데, 논문이 평가한 v0.5.5 기준으로는 66개 언어이고, 현재 공개된 릴리스는 158개 언어로 확장되었습니다. 파이프라인 오케스트레이션, 그래프 저장, MCP 프로토콜, Cypher 질의 엔진, 백그라운드 동기화가 모두 C로 구현되어 있으며 모든 상태는 단일 SQLite 파일에 담깁니다.

그래프에는 코드뿐 아니라 인프라 정의도 포함됩니다. Dockerfile, Kubernetes 매니페스트, Kustomize 오버레이가 그래프 노드로 인덱싱되어, Kubernetes 종류(kind)는 Resource 노드로, Kustomize 오버레이는 참조하는 리소스로 향하는 IMPORTS 엣지를 가진 Module 노드로 표현됩니다. 또한 스키마에는 HTTP_CALLS 와 ASYNC_CALLS 엣지가 있어, 6개 프레임워크(Python, Go, Java/Spring, Kotlin/Ktor, Express.js, Laravel)별 추출기가 HTTP 라우트와 호출 지점을 교차 매칭하고 신뢰도 점수(0.0 ~ 1.0 )를 매깁니다. 덕분에 REST 엔드포인트가 1급 그래프 엔터티로 취급되어, 여러 언어에 걸친 마이크로서비스 아키텍처도 하나의 그래프로 표현됩니다.

RAM 우선 인덱싱과 멀티패스 파이프라인

codebase-memory-mcp의 인덱싱은 RAM 우선(RAM-first) 파이프라인으로 설계되어 있습니다. LZ4 압축, 인메모리 SQLite, 융합된 Aho-Corasick 패턴 매칭을 사용하며, 인덱싱이 끝나면 메모리를 OS에 반환합니다. 그래프가 한 번 완성되면 대부분의 구조적 질의가 1밀리초 미만으로 응답되는데(논문 Table 8), 이는 질의 시점마다 파일을 새로 읽어 구조를 발견해야 하는 방식과의 핵심적인 차이입니다.

빌드 단계는 단일 SQLite 트랜잭션 안에서 6단계로 실행됩니다. 구조 파악(Project/Package/Folder/File 노드와 포함 관계 생성), 정의 추출(함수/메서드/클래스/인터페이스/열거형/타입 노드), 호출/타입 해소(CALLS/IMPORTS/USES_TYPE 등 엣지 생성), 보강(테스트 연결, HTTP 라우트 매칭, git 공동 변경 엣지), flush(인덱스 생성을 미룬 채 SQLite에 일괄 INSERT), 후처리(Louvain 커뮤니티와 XXH3 파일 해시 계산)의 순서입니다. 이 가운데 1단계부터 4단계까지는 SQLite 오버헤드를 피하기 위해 인메모리 그래프 버퍼(cbm_gbuf_t)에 노드와 엣지를 쌓는데, pthreads 기반 워커 풀이 원자적 작업 훔치기(work-stealing)로 일을 나눠 각자의 버퍼에 쓴 뒤 병합합니다. 버퍼는 임시 순차 ID를 부여했다가 SQLite에 flush할 때 실제 행 ID로 다시 매핑합니다.

인덱싱 결과는 내장된 3D 그래프 시각화 도구로 살펴볼 수 있습니다. 선택적 UI 바이너리를 사용하면 localhost:9749 에서 지식 그래프를 인터랙티브하게 탐색할 수 있습니다.

호출 해소: 6단계 캐스케이드

그래프의 정확도를 좌우하는 핵심은 pkg.Func 같은 원시 호출 이름을 실제 그래프 노드로 연결하는 호출 해소(call resolution) 입니다. codebase-memory-mcp는 함수 레지스트리(FunctionRegistry)가 모든 정의를 정규화된 이름과 단순 이름으로 색인해 두고, 신뢰도 점수가 매겨진 6단계 우선순위 캐스케이드로 호출을 해소합니다.

import 맵 (신뢰도 0.95 ): 호출 이름을 prefix.suffix 로 분리해 파일의 import 맵에서 prefix의 모듈 정규화 이름을 찾아 suffix와 결합한 뒤 정확히 매칭
import 맵 suffix (0.85 ): 정확한 import 맵 매칭이 실패하면 import로 해소된 모듈 경로에 suffix 기반으로 매칭
동일 모듈 (0.90 ): 호출 이름에 현재 파일의 모듈 정규화 이름을 붙여 정확히 매칭
고유 이름 (0.75 ): 단순 이름을 역색인에서 찾아 프로젝트 전체에 후보가 정확히 하나일 때 채택
suffix 매칭 (0.55 ): 후보가 여럿이면 import 거리 점수로 가장 가까운 모듈 경로를 선택
퍼지 매칭 (0.30 ~ 0.40 ): 구조적 해소가 모두 실패했을 때 문자열 유사도로 최후 매칭

저자들의 관찰에 따르면 잘 구조화된 코드베이스에서는 1단계부터 3단계가 호출의 약 80\% 를 해소하고, 4단계부터 6단계가 교차 모듈 참조와 동적 디스패치를 처리합니다.

이름 기반 캐스케이드는 문자열 수준에서 동작해 표현식의 타입을 추적하지 못하므로, 메서드 리시버(Go), 포인터 간접 참조와 암시적 this(C/C++), 템플릿 의존 호출(C++) 같은 경우 정확도가 떨어집니다. 이를 보완하기 위해 LSP 스타일 하이브리드 타입 해소(Hybrid Type Resolution) 패스를 둡니다. 논문에서는 Go, C, C++ 세 언어에 적용했고, 현재 릴리스는 이를 11개 언어(Python, TypeScript/JavaScript/JSX/TSX, PHP, C#, Go, C, C++, Java, Kotlin, Rust)로 확장했습니다. 각 패스는 파일별 TypeRegistry 와 변수 바인딩을 추적하는 Scope 구조를 만들고, 호출 지점의 리시버 표현식 타입을 상향식(bottom-up)으로 평가합니다. 식별자를 스코프 체인에서 찾고, 기반 클래스나 임베디드 타입을 따라 필드/메서드를 조회하며, 호출 사슬을 통해 반환 타입을 전파하는 식입니다. 이렇게 해소된 호출은 문자열 기반 캐스케이드를 건너뛰고 완전히 정규화된 호출 이름을 가진 고신뢰 엣지를 생성합니다.

증분 동기화와 커뮤니티 탐지

백그라운드 파일 워처가 적응형 폴링으로 저장소 변경을 감시합니다. 파일이 바뀌면 XXH3 콘텐츠 해시를 저장된 해시와 비교해, 달라진 파일의 노드와 엣지만 삭제 후 재파싱하고 영향받은 커뮤니티 할당을 다시 계산합니다. XXH3는 약 30\ \text{GB/s} 처리량의 비암호화 64비트 해시로, 충돌 저항성이 보안 요건이 아닌 콘텐츠 주소화 인덱싱에서 속도를 위해 선택되었습니다.

호출 그래프는 Louvain 모듈도(modularity) 최적화 로 기능적 커뮤니티로 분할됩니다. 각 노드는 모듈도 증가분 \Delta Q = w_{in} - \gamma \cdot k_i \cdot \Sigma_{tot} / (2m) 를 최대화하는 이웃 커뮤니티에 합류하고(\gamma = 1.0 ), 내부 밀도가 1\% 미만인 커뮤니티는 약하게 연결된 구성원을 떼어내 분할합니다. 보통 3회에서 5회 반복에서 수렴하며, 알고리즘은 CALLS, HTTP_CALLS, ASYNC_CALLS 엣지 위에서 동작합니다. 결과로 생성된 Community 노드와 MEMBER_OF 엣지는 get_architecture 도구가 아키텍처 요약을 제공하는 데 쓰입니다.

14개 MCP 도구

codebase-memory-mcp는 14개의 MCP 도구를 네 갈래로 제공합니다.

인덱싱: index_repository(그래프 빌드/갱신), index_status(진행 상황 폴링), list_projects, delete_project
질의: search_graph(심볼 검색), trace_call_path(방향성 호출 체인 추적, 깊이 조절 가능), query_graph(Cypher 유사 질의), ingest_traces(런타임 트레이스 가져오기)
분석: detect_changes(git diff 영향도), get_graph_schema(스키마 조회), get_architecture(아키텍처 요약)
코드: get_code_snippet(소스 조회), search_code(전문 검색), manage_adr(아키텍처 결정 기록 관리)

각 도구는 LLM이 곧바로 처리할 수 있는 구조화된 JSON을 반환합니다. 특히 query_graph 는 임의의 그래프 순회를 위한 Cypher 유사 질의 언어를 지원하고, trace_call_path 는 인바운드/아웃바운드 방향과 깊이를 지정한 호출 체인 추적을 제공합니다.

보안: MCP 공급망 신뢰 문제에 대한 답

논문이 적지 않은 분량을 할애한 주제가 보안입니다. MCP 서버는 독특한 신뢰 문제를 안고 있습니다. 호스트 에이전트의 전체 권한으로 실행되는데도, 사용자는 서드파티 저장소에서 받은 불투명한 바이너리로 설치합니다. 침해되거나 악의적인 MCP 서버는 정상 동작하는 것처럼 보이면서 소스 코드를 빼돌리거나 백도어를 심을 수 있고, LLM이 사용자 승인 없이 도구를 자동 호출하는 환경에서는 위험이 더 커집니다. 저자들은 이를 "지금까지 문헌에서 거의 주목받지 못한 공급망 신뢰 문제" 로 규정하고 심층 방어(defense-in-depth)를 제시합니다.

8단계 CI 감사: 매 커밋마다 위험한 libc 함수(system, popen, fork, execvp) 호출을 정당화 사유가 붙은 허용 목록과 대조하고, 빌드된 바이너리에서 하드코딩된 URL/자격증명/의심스러운 base64 페이로드를 스캔하며, strace로 네트워크 egress를 감시(로컬호스트/DNS/GitHub 릴리스 API만 허용)합니다. 이어서 설치 경로 검증, 스모크 테스트, 그래프 UI 자산 스캔, 23개의 적대적 JSON-RPC 페이로드(SQL/셸 인젝션, 경로 탐색, ReDoS 등)에 대한 견고성 테스트, 그리고 66개 tree-sitter 문법을 포함한 72개 벤더링 파일의 SHA-256 무결성 검증이 수행됩니다.

코드 수준 보호: 모든 popen 호출 전 cbm_validate_shell_arg() 로 셸 인자를 검증하고, SQLite authorizer 콜백이 엔진 수준에서 ATTACH/DETACH 를 차단하며, get_code_snippet 은 realpath() 격리 검사로 프로젝트 루트 밖 읽기를 막습니다. 모든 테스트는 AddressSanitizer/UndefinedBehaviorSanitizer로 컴파일되고 15분 soak 테스트로 메모리 안전성을 점검합니다.

릴리스 검증 파이프라인: 릴리스는 초안/검증/공개(draft-verify-publish) 3단계를 따릅니다. 바이너리는 Sigstore cosign으로 서명되고 SLSA 빌드 출처(provenance)가 첨부되며, GitHub CodeQL 정적 분석에서 경고가 하나라도 열려 있으면 릴리스가 막힙니다. 검증 단계에서는 모든 바이너리를 VirusTotal에 제출해 70개 이상의 백신 엔진 이 스캔하고, 한 엔진이라도 탐지하면 공개를 막는 무관용 정책을 적용합니다. 여기에 Windows Defender, ClamAV 같은 플랫폼 네이티브 스캔과 OpenSSF Scorecard 게이트가 더해집니다. 각 릴리스에는 SHA-256 체크섬과 CycloneDX SBOM(소프트웨어 자재 명세서)이 포함되어, 사용자가 gh attestation verify 와 cosign verify-blob 로 직접 검증할 수 있습니다. 저자들은 "Google, Microsoft, Cisco의 다중 엔진 백신 스캔과 암호학적 빌드 출처, 무관용 릴리스 게이팅을 결합한 이 수준의 자동 바이너리 검증은 GitHub로 배포되는 오픈소스 MCP 서버나 개발 도구에서 흔치 않다" 고 밝힙니다.

실험 결과: 그래프 질의 vs 파일 탐색

논문은 31개 프로그래밍 언어 각각을 실제 오픈소스 저장소(78개 노드의 HCL/Terraform부터 49,398개 노드의 Python/Django까지)로 평가했습니다. codebase-memory-mcp의 14개 도구를 쓰는 MCP 에이전트 와 전통적인 파일 읽기/grep 탐색을 쓰는 탐색(Explorer) 에이전트 를 동일한 질문으로 비교했고, 두 에이전트 모두 백엔드로 Claude Opus 4.6을 사용했습니다. 허브 탐지, 호출자 순위, 의존성 목록, 전체 호출 체인 추적 등 12개 질문 범주를 다뤘으며, 답변은 수동 코드 검수로 만든 기준 답안과 대조해 채점(\geq 0.80 PASS, 0.40 ~ 0.79 PARTIAL, < 0.40 FAIL)했습니다.

여기서 기존 게시물이 "파일 단위 탐색 대비 답변 품질 83%" 라고 적었던 수치를 바로잡을 필요가 있습니다. 83\% 는 MCP 에이전트의 절대 품질 점수이고, 파일 탐색 에이전트는 92\% 였습니다. 즉 MCP 에이전트는 탐색 에이전트 품질의 90% 수준 을 유지하면서 토큰을 10배, 도구 호출을 2.1배 적게 썼습니다. 구체적으로 질문당 평균 도구 호출은 4.8 회에서 2.3 회로, 질문당 토큰은 약 10{,}000 에서 약 1{,}000 으로 줄었고, 질의 지연은 탐색 에이전트의 10 ~ 30 초에서 1밀리초 미만으로 떨어졌습니다. 허브 탐지나 호출자 순위처럼 미리 구축된 그래프 엣지를 따라가는 질의에서는 31개 언어 중 19개에서 탐색 에이전트와 같거나 더 나은 성능을 보였고, 함수형 언어(Haskell, OCaml, Elixir)에서는 품질 격차가 약 1\% 까지 좁혀졌습니다.

반대로 전체 소스 맥락이 필요한 질의(16/31)나 모든 호출 지점을 샅샅이 훑는 grep(10/31)에서는 탐색 에이전트가 우세했습니다. 그래프가 의도적으로 소스 줄(line) 자체는 저장하지 않기 때문입니다. 가장 약했던 사례는 매크로가 많은 C(0.58 대 1.00 )로, 매크로가 AST에 표현되지 않는 한계 때문입니다. 저자들은 이로부터 "구조적 질의는 그래프로, 소스 수준 작업은 파일 탐색으로" 처리하는 하이브리드 구조가 최적이라고 결론짓습니다.

속도 차이는 MCP 에이전트가 사전 계산된 그래프 조회로 답하는 반면(SQL 재귀 CTE 기반 너비 우선 탐색 약 0.3\ \text{ms} ), 탐색 에이전트는 질의 시점마다 함수 이름을 grep하고 파일을 읽고 맥락을 파싱하는 과정을 반복하며 구조를 새로 발견해야 하는 데서 옵니다. 그래프 방식은 인덱싱 비용을 한 번만 치르고(49K 노드 약 6 초) 이후 모든 질의에 분할 상환합니다.

기존 코드 검색 방식과의 비교

논문은 codebase-memory-mcp를 LLM 코드 검색의 세 가지 주류 방식과 나란히 놓고 비교합니다. 임베딩 기반 RAG는 의미적 유사도에는 강하지만 벡터 DB가 필요하고 구조적 질의를 지원하지 않으며 질의당 약 $2$K ~ $5$K 토큰을 씁니다. Aider류의 Repo-Map은 가벼운 대신(질의당 약 $1$K 토큰) 영속적 그래프나 구조적 질의가 없습니다. Neo4j 같은 그래프 DB에 LLM을 결합한 방식은 구조적 질의가 가능하지만 별도 인프라와 수동 동기화가 필요하고 8 ~ 14 개 언어에 그칩니다. 이에 비해 codebase-memory-mcp는 별도 인프라 없이 SQLite 파일 하나로 동작하고, 임베딩 모델 없이 질의당 약 $1$K 토큰으로 구조적 질의와 자동 동기화를 모두 제공하며 MIT 라이선스로 공개된다는 점을 차별점으로 내세웁니다.

시스템 성능과 채택

성능은 Apple M3 Pro(macOS)에서 측정되었습니다. 주 벤치마크인 Django 저장소는 49,398개 노드와 196,022개 엣지로 이루어집니다. 규모의 상단에서는 리눅스 커널(2,800만 LOC, 7만 5천 파일)을 약 3분에 인덱싱해 210만 개 노드와 490만 개 엣지를 만들어, 파이프라인이 아주 큰 코드베이스까지 확장됨을 보였습니다. XXH3 콘텐츠 해시 기반 증분 재인덱싱은 약 1.2 초로, 전체 재인덱싱 대비 약 4배 빠릅니다.

프로젝트가 토큰 절감을 보여주는 단적인 예로, 5개의 구조적 질의가 약 3,400 토큰을 쓰는 반면 같은 정보를 파일 단위로 읽으면 약 412,000 토큰이 들어 약 99\% 가 절감됩니다(앞서 본 10배는 31개 저장소 벤치마크의 평균치이고, 이쪽은 특정 사례의 수치입니다). 실사용 수요도 빠르게 확인되고 있어, 공개 첫 4주(2026년 2월 25일 초기 릴리스) 만에 900개 이상의 스타와 약 100개의 포크를 모았고 주요 코딩 에이전트들이 설치 시 자동으로 인식합니다.

한계와 향후 방향

논문은 한계를 솔직하게 밝힙니다. 벤치마크는 단일 LLM 백엔드(Claude Opus 4.6)와 언어당 단일 저장소로 수행되었고, 채점도 제1저자가 맡아 다른 모델이나 프롬프트로 일반화되지 않을 수 있습니다. 또한 지식 그래프는 정적 구조만 포착하므로 런타임 동작, 리플렉션, 동적 디스패치는 표현되지 않으며, query_graph 는 기본적으로 10만 행 상한을 둬 매우 큰 코드베이스에서는 과소 집계될 수 있습니다.

향후 과제로는 SWE-bench에서 그래프/텍스트/임베딩 기반 탐색을 절제 연구(ablation study)와 함께 비교하는 통제 실험, 구조적 검색과 의미적 검색을 결합한 하이브리드 검색, 다중 저장소 의존성 추적이 제시됩니다. 특히 저자들은 임상 데이터 변환용 DSL(예: openEHR와 HL7 FHIR를 잇는 FHIRconnect)처럼 구조적 맥락이 필요한 보건의료 정보학 영역을 유망한 응용처로 꼽는데, 이는 의료정보학을 연구하는 저자들의 배경과 맞닿아 있습니다.

codebase-memory-mcp 설치와 사용법

macOS와 Linux에서는 한 줄 설치 스크립트를 사용합니다. 그래프 시각화 UI가 필요하면 --ui 옵션을 붙입니다.

# 기본 설치
curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

# 그래프 시각화 UI 포함
curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash -s -- --ui

설치 스크립트는 11개 코딩 에이전트(Claude Code, Codex CLI, Gemini CLI, Zed, OpenCode, Antigravity, Aider, KiloCode, VS Code, OpenClaw, Kiro)를 자동으로 감지해 각각의 MCP 항목과 지침 파일, 사전 도구 훅(pre-tool hook)을 설정합니다. 설치 후 에이전트를 재시작하고 "Index this project" 라고 말하면 인덱싱이 시작됩니다. Windows용 PowerShell 설치 방법과 --skip-config, --dir 같은 옵션은 저장소의 README에 정리되어 있습니다.

codebase-memory-mcp의 라이선스

codebase-memory-mcp는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다. 논문이 평가한 버전은 릴리스 v0.5.5이며, 소스 코드와 벤치마크 스크립트, 평가 데이터가 모두 공개되어 있습니다.

codebase-memory-mcp 공식 문서

codebase-memory-mcp GitHub 저장소

Codebase-Memory 논문: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~