R

프로젝트 중심 작업흐름(Project-based Workflow)를 채택(Aja, 2024)한다는 것은 프로젝트 설정의 각 계층을 프로그래밍 방식으로 관리할 수 있게 해주는 도구들을 사용한다는 의미로 이러한 계층은 “프로젝트 양파(Project Onion)”로 시각화할 수 있다.

프로젝트 양파는 프로젝트 설정의 여러 계층으로 표현되고, 가장 바깥 층에서 안쪽으로 들어가면서 다음과 같은 구조를 가진다. 이 구조에서 각 바깥 층은 그 안쪽 층의 설치와 관리를 담당한다. 즉, 패키지 관리자가 언어 관리자를 설치하고, 언어 관리자는 특정 언어 버전을 설치하며, 언어 버전은 환경을 설치하고 관리한다.

패키지 관리자가 가장 바깥 층을 차지한다.
그 다음 층에는 언어 관리자가 위치한다.
그 안쪽에는 언어 버전이 자리잡고 있다.
가장 안쪽 핵심에는 환경이 위치한다.

이러한 접근 방식을 통해 개발자는 프로젝트의 모든 측면을 체계적으로 관리할 수 있으며, 재현 가능하고 일관된 개발 환경을 유지할 수 있다.

R 작업흐름

R 작업흐름(workflow)은 데이터 과학업무를 효율적으로 수행하기 위한 과정이다. R을 시작하고 필요한 패키지를 설치한다. 재현 가능한 환경을 생성하여 일관된 결과를 보장한다. R을 최신 버전으로 설치하고 업그레이드하여 새로운 기능과 개선사항을 활용한다. 이러한 순환적인 과정을 통해 R 사용자는 데이터 불러오기, 전처리, 분석, 시각화, 모형개발, 결과 해석 등의 작업을 체계적으로 수행한다.

R 시작과정

R은 리눅스 서버와 같이 공유 컴퓨팅 자원(shared computing resource)으로 사용되도록 설계되었다. R의 시작 과정은 시스템의 모든 사용자를 지원하는 경우와 개별 사용자 모두에게 맞춤 설정 기회도 제공한다. 하지만 이런 유연성에는 대가가 따른다. 즉, ‘복잡성’(complexity)이다.

대부분의 R 사용자는 이런 복잡성의 대부분을 무시하고 두 가지 주요 파일에만 집중하면 된다.

.Renviron - R 세션에서 설정될 환경 변수를 지정한다.
.Rprofile - 각 세션에서 실행될 R 코드를 설정한다.

점파일(dotfiles)은 특히 유닉스 명령줄에 뿌리를 두고 있으며 많은 프로그램의 동작을 조정하는 데 사용된다. .Renviron, .Rprofile 파일은 ’점파일(dotfiles)’이라고 불리는 더 넓은 범위의 맞춤 설정 파일 중 R에 특화된 것이다. R 관련 점파일을 찾는 한 방법은 GitHub에서 ’filename:.Rprofile’로 검색하는 것이다.

`.Renviron`	`.Rprofile`
API 키 등 인증정보	개발 의존성(`usethis`, `devtools` 등)
환경 정보 (`R_LIBS_USER`)

`.Renviron`

.Renviron 파일은 주로 API 키(예: GitHub, OpenAI)와 같은 민감한 정보나 R 관련 환경 변수(예: 히스토리 크기 R_HISTSIZE=100000, 기본 라이브러리 위치 R_LIBS_USER)를 정의하는 데 유용하다. R 코드는 담기지 않는다. .Renviron 파일을 편집하려면 usethis::edit_r_environ()을 실행한다.

R_HISTSIZE=100000
RETICULATE_PYTHON=.venv/bin/python
DB_USER=elephant
DB_PASS=p0stgr3s
GITHUB_PAT=abc123
R_LIBS_USER=~/R/%p/%v

usethis::edit_r_environ(scope = ?)을 사용해서 환경설정변수 파일(.Renviron) 위치를 지정할 수 있다.

사용자	프로젝트
`~/.Renviron`	`path/to/your/project/.Renviron`

R_LIBS_USER=~/R/%p/%v의 의미

R_LIBS_USER=~/R/%p/%v는 R에서 사용자 지정 라이브러리의 위치를 설정하는 환경 변수로 다음과 같은 의미를 갖는다.

~: 사용자 홈 디렉토리
/R/: R 관련 파일들을 저장할 디렉토리
%p: R의 플랫폼 이름으로 대체 (예: “x86_64-pc-linux-gnu”).
%v: R의 주요 버전 번호로 대체 (예: “4.1”).

따라서 리눅스 시스템에서 R 4.3 버전을 사용한다면, 실제 경로는 다음과 같을 수 있다.

/home/username/R/x86_64-pc-linux-gnu/4.3

`.Rprofile`

.Rprofile 파일은 R 세션 시작 시 실행될 R 코드를 포함되고, 주로 사용자의 홈 디렉토리에 위치하며, usethis::edit_r_profile()로 편집할 수 있다. .Rprofile 파일에 공유하는데 문제를 야기할 수 있는 코드는 담지 않는다.

.Rprofile GitHub 검색어 → https://github.com/search?q=.Rprofile

재현성

.Rprofile에는 R 터미널에서 대화식으로 실행하는 것만 포함해야 한다. R 스크립트나 R 마크다운 파일에 나타나는 것은 포함하지 않아야 한다. 대부분의 코드는 interactive() 함수로 감싸서 대화형 세션에서만 실행되도록 해야 한다.

options(repos = c(CRAN = "https://cran.rstudio.org"))
if (interactive()) {
  options(width = 120)
}

.Rprofile 설정에서 newline 활성화

시작 파일(startup)들은 반드시 새 줄(newline)로 끝나야 한다. 만약 이렇게 하지 않으면, R이 마지막 줄을 아무 경고 없이 무시할 수 있다.

실습

`.Renviron` 환경변수 파일 편집

R 콘솔에서 usethis::edit_r_environ() 실행
WTF_USER={사용자명}_user 추가
R 세션 새로 실행: CTRL + SHIFT + F10(윈도우), CMD + SHIFT + 0(맥)
WTF_USER 환경변수 값 Sys.getenv("WTF_USER") 명령어로 확인

`.Rprofile` 환경변수 파일 편집

R 콘솔에서 usethis::edit_r_profile() 혹은 usethis::edit_r_profile("project") 실행
print(“Rprofile 코드 추가”)
R 세션 새로 실행: CTRL + SHIFT + F10(윈도우), CMD + SHIFT + 0(맥)
WTF_USER 환경변수 값 Sys.getenv("WTF_USER") 명령어로 확인

R 패키지

R 패키지 설치 방법은 크게 바이너리 설치와 소스 코드 컴파일 설치로 구분된다. 바이너리 설치는 미리 컴파일된 패키지를 사용하는 방식으로, install.packages("패키지이름")으로 간단히 실행할 수 있다. 이 방법은 빠르고 편리하지만, 시스템 특정적이며 최신 버전이 늦게 제공될 수 있다. 반면 소스 코드 컴파일 설치는 install.packages("패키지이름", type = "source")로 실행하며, 사용자 시스템에서 직접 컴파일하여 설치한다. 이 방식은 시간이 더 걸리고 추가 도구가 필요할 수 있지만, 시스템 최적화와 최신 버전 사용이 가능하다다. 일반 사용자에게는 간편한 바이너리 설치가 권장되나, 특수한 요구사항이나 최신 기능이 필요한 경우 소스 코드 설치가 적합할 수 있다.

운영체제에 맞게 패키지를 구할 수 있는 곳은 CRAN, Posit Public Package Manager (p3m)가 대표적이다.

운영체제	CRAN	Posit Public Package Manager (p3m)
윈도우즈	✅	✅
맥 OS	✅	✅
리눅스	❌	✅

`R_LIBS_USER` 패키지 저장소

수만개의 R 패키지 중에서 일부를 로컬 컴퓨터에 설치하여 프로젝트에 활용하여 성과를 내게 된다. CRAN, P3M에서 다운로드하여 패키지가 설치된 R_LIBS_USER 환경정보를 .Renviron 파일에 설정하는 방법은 몇단계를 걸친다.

R 콘솔에서 usethis::edit_r_environ() 명령어를 실행하여 .Renviron 파일을 연다.

R_LIBS_USER 환경변수 설정을 한다.

R_LIBS_USER=C:/Users//AppData/Local/R/win-library/4.4

CTRL + SHIFT + F10(윈도우), CMD + SHIFT + 0(맥) 명령어를 실행하여 세션을 재시작한다.

 Sys.getenv("R_LIBS_USER")
[1] "C:/Users/<사용자명>/AppData/Local/R/win-library/4.4"

R 패키지 개발과 활용

R 패키지는 개발과정과 개발된 패키지를 활용하는 두가지 단계로 크게 구분할 수 있다. 소스코드를 번들로 만들고 이를 빌드하여 바이너리 배포용 패키지를 제작하는 과정과 패키지를 설치한 후에 이를 활용하는 두가지 단계로 나눌 수 있다.

바이너리와 소스

패키지를 바이너리(binary)를 기본으로 설치하는 것을 추천하지만 GitHub 저장소에서 R 패키지를 설치할 경우 불가피하게 패키지를 소스(source)에서 설치해야한다.

install.packages() 함수를 사용할 때 type 파라미터를 “source”로 지정하면 CRAN, P3M 에서 바이너리 대신 소스를 컴파일하여 설치할 수 있다.

install.packages("패키지명", type = "source")

devtools 패키지를 사용하여 GitHub 등에서 특정 버전의 소스를 직접 설치할 수 있는데 컴파일 시간이 더 오래 걸릴 수 있고, 시스템에 필요한 개발 도구가 설치되어 않으면 패키지를 설치할 수도 없다.

devtools::install_github("사용자명/레포지토리명")

로컬 컴퓨터 환경에 맞춰 C, C++, 포트란(Fortran), 러스트(Rust) 언어로 된 코드를 컴파일할 수 있는 도구를 운영체제에 맞춰 설치를 해야만 소스코드 형태 R 패키지를 설치할 수 있다.

Rtools

XCode

xcode-select --install

install tools via package manager, e.g.

apt install make

운영체제에 맞춰 도구를 설치하면 devtools::has_devel() 명령어로 설치여부를 점검할 수 있다.

코드

devtools::has_devel()

Your system is ready to build packages!

재현가능 환경

데이터 과학 작업의 환경을 재현하는 전략을 크게 재현성 환경관리 책임자와 패키지 접근 개방이라는 두 가지 축을 기반으로 ‘스냅샷 및 복원(Snapshot)’, ‘공유 기준선(Shared Baseline)’, ‘검증(Validated)’이라는 세 가지 성공적인 전략을 제시하는 동시에 ’무법 지대’, ‘티켓 시스템’, ’차단’이라는 세 가지 위험 구역도 언급하고 있다. ¹

스냅샷 전략은 데이터 과학 작업의 재현성을 보장하는 효과적인 방법으로 널리 인정받고 있다. 주요 장점으로 특정 시점의 환경을 정확히 캡처하고 나중에 그대로 복원할 수 있다는 점으로, 프로젝트의 모든 종속성, 패키지 버전, 설정을 포함한 전체 작업 환경을 보존함으로써 연구 결과의 정확한 재현을 가능하게 한다.

스냅샷 전략은 동시에 유연성도 제공한다. 데이터 과학자들은 필요에 따라 자유롭게 패키지를 설치하고 업데이트할 수 있으며, 동시에 각 프로젝트의 고유한 환경을 유지할 수 있다. 이를 통해 혁신과 실험을 장려하면서도 프로젝트의 안정성을 보장하는 균형 잡힌 접근 방식으로 팀 협업 시에도 모든 구성원이 동일한 환경에서 작업할 수 있게 하여 “내 컴퓨터에서는 작동합니다”와 같은 문제를 해결하는데 기여할 수 있다.

그러나 스냅샷 전략에도 몇 가지 단점도 존재한다. 첫째, 스냅샷 관리에 추가적인 시간과 리소스가 필요하다. 특히 큰 조직이나 많은 프로젝트를 다루는 경우, 여러 스냅샷을 관리하고 추적하는 것이 복잡해질 수 있다. 둘째, 스냅샷은 시간이 지남에 따라 용량을 많이 차지할 수 있으며, 이는 저장 공간 문제로 이어질 수 있다. 마지막으로, 보안 업데이트나 중요한 버그 수정이 있을 때 모든 관련 스냅샷을 업데이트해야 하는 번거로움이 있을 수 있다.

프로젝트 공유환경

:::

코드

> .libPaths()
[1] "C:/Users/statkclee/AppData/Local/R/win-library/4.4"  # 사용자
[2] "C:/Program Files/R/R-4.4.1/library"                  # 시스템

프로젝트 격리 환경

코드

- Project '~/sample-project' loaded. [renv 1.0.7]
> .libPaths()
[1] "C:/Users/statkclee/Documents/sample-project/renv/library/windows/R-4.4/x86_64-w64-mingw32"        
[2] "C:/Users/statkclee/AppData/Local/R/cache/R/renv/sandbox/windows/R-4.4/x86_64-w64-mingw32/88765555"

참고문헌

Aja, E. D. (2024). Personal radmin - throw your computer into the ocean with confidence. R-Ladies Global. https://www.youtube.com/watch?v=XXXXXXXXX

각주

Strategy Maps - Strategies to Reproduce Environments Over Time ↩︎

# R 프로젝트 중심 작업흐름(Project-based Workflow)를 채택[@aja2024personal]한다는 것은 프로젝트 설정의 각 계층을 프로그래밍 방식으로 관리할 수 있게 해주는 도구들을 사용한다는 의미로 이러한 계층은 **"프로젝트 양파(Project Onion)"**로 시각화할 수 있다. 프로젝트 양파는 프로젝트 설정의 여러 계층으로 표현되고, 가장 바깥 층에서 안쪽으로 들어가면서 다음과 같은 구조를 가진다. 이 구조에서 각 바깥 층은 그 안쪽 층의 설치와 관리를 담당한다. 즉, 패키지 관리자가 언어 관리자를 설치하고, 언어 관리자는 특정 언어 버전을 설치하며, 언어 버전은 환경을 설치하고 관리한다. 1. 패키지 관리자가 가장 바깥 층을 차지한다. 2. 그 다음 층에는 언어 관리자가 위치한다. 3. 그 안쪽에는 언어 버전이 자리잡고 있다. 4. 가장 안쪽 핵심에는 환경이 위치한다. 이러한 접근 방식을 통해 개발자는 프로젝트의 모든 측면을 체계적으로 관리할 수 있으며, 재현 가능하고 일관된 개발 환경을 유지할 수 있다. ::: {#fig-project-onion layout-ncol="2"} ![R 프로젝트 양파](images/project-oyster-kr.svg) ![파이썬 프로젝트 양파](images/project-oyster-py.svg) R과 파이썬 프로젝트 양파 사례 ::: ## R 작업흐름 **R 작업흐름(workflow)**은 데이터 과학업무를 효율적으로 수행하기 위한 과정이다. R을 시작하고 필요한 패키지를 설치한다. 재현 가능한 환경을 생성하여 일관된 결과를 보장한다. R을 최신 버전으로 설치하고 업그레이드하여 새로운 기능과 개선사항을 활용한다. 이러한 순환적인 과정을 통해 R 사용자는 데이터 불러오기, 전처리, 분석, 시각화, 모형개발, 결과 해석 등의 작업을 체계적으로 수행한다. ```{mermaid} %%| label: r-workflow flowchart LR start(R 시작) packages(R 패키지<br>설치) repro(재현가능<br>환경 생성) installing("R 설치 및<br>업그레이드") start --> packages --> repro --> installing --> start ``` # R 시작과정 R은 리눅스 서버와 같이 공유 컴퓨팅 자원(shared computing resource)으로 사용되도록 설계되었다. R의 시작 과정은 시스템의 모든 사용자를 지원하는 경우와 개별 사용자 모두에게 맞춤 설정 기회도 제공한다. 하지만 이런 유연성에는 대가가 따른다. 즉, **'복잡성'(complexity)**이다. ![R 시작과정 도해](images/R-startup.svg) 대부분의 R 사용자는 이런 복잡성의 대부분을 무시하고 두 가지 주요 파일에만 집중하면 된다. 1. `.Renviron` - R 세션에서 설정될 환경 변수를 지정한다. 2. `.Rprofile` - 각 세션에서 실행될 R 코드를 설정한다. [점파일(dotfiles)](https://www.quora.com/What-are-dotfiles)은 특히 유닉스 명령줄에 뿌리를 두고 있으며 많은 프로그램의 동작을 조정하는 데 사용된다. `.Renviron`, `.Rprofile` 파일은 '점파일(dotfiles)'이라고 불리는 더 넓은 범위의 맞춤 설정 파일 중 R에 특화된 것이다. R 관련 점파일을 찾는 한 방법은 GitHub에서 'filename:.Rprofile'로 검색하는 것이다. | `.Renviron` | `.Rprofile` | |:-------------------------:|:-------------------------------------:| | API 키 등 인증정보 | 개발 의존성(`usethis`, `devtools` 등) | | 환경 정보 (`R_LIBS_USER`) | | ## `.Renviron` `.Renviron` 파일은 주로 API 키(예: GitHub, OpenAI)와 같은 민감한 정보나 R 관련 환경 변수(예: 히스토리 크기 `R_HISTSIZE=100000`, 기본 라이브러리 위치 `R_LIBS_USER`)를 정의하는 데 유용하다. R 코드는 담기지 않는다. `.Renviron` 파일을 편집하려면 `usethis::edit_r_environ()`을 실행한다. ``` R_HISTSIZE=100000 RETICULATE_PYTHON=.venv/bin/python DB_USER=elephant DB_PASS=p0stgr3s GITHUB_PAT=abc123 R_LIBS_USER=~/R/%p/%v ``` `usethis::edit_r_environ(scope = ?)`을 사용해서 환경설정변수 파일(`.Renviron`) 위치를 지정할 수 있다. | 사용자 | 프로젝트 | |:-------------:|:--------------------------------:| | `~/.Renviron` | `path/to/your/project/.Renviron` | ::: callout-note ### `R_LIBS_USER=~/R/%p/%v`의 의미 `R_LIBS_USER=~/R/%p/%v`는 R에서 사용자 지정 라이브러리의 위치를 설정하는 환경 변수로 다음과 같은 의미를 갖는다. 1. `~`: 사용자 홈 디렉토리 2. `/R/`: R 관련 파일들을 저장할 디렉토리 3. `%p`: R의 플랫폼 이름으로 대체 (예: "x86_64-pc-linux-gnu"). 4. `%v`: R의 주요 버전 번호로 대체 (예: "4.1"). 따라서 리눅스 시스템에서 R 4.3 버전을 사용한다면, 실제 경로는 다음과 같을 수 있다. ``` /home/username/R/x86_64-pc-linux-gnu/4.3 ``` ::: ## `.Rprofile` `.Rprofile` 파일은 R 세션 시작 시 실행될 R 코드를 포함되고, 주로 사용자의 홈 디렉토리에 위치하며, `usethis::edit_r_profile()`로 편집할 수 있다. `.Rprofile` 파일에 공유하는데 문제를 야기할 수 있는 코드는 담지 않는다. > `.Rprofile` GitHub 검색어 → <https://github.com/search?q=.Rprofile> ### 재현성 `.Rprofile`에는 R 터미널에서 대화식으로 실행하는 것만 포함해야 한다. R 스크립트나 R 마크다운 파일에 나타나는 것은 포함하지 않아야 한다. 대부분의 코드는 `interactive()` 함수로 감싸서 대화형 세션에서만 실행되도록 해야 한다. ``` r options(repos = c(CRAN = "https://cran.rstudio.org")) if (interactive()) { options(width = 120) } ``` ::: callout-warning ### `.Rprofile` 설정에서 `newline` 활성화 시작 파일(startup)들은 반드시 새 줄(newline)로 끝나야 한다. 만약 이렇게 하지 않으면, R이 마지막 줄을 아무 경고 없이 무시할 수 있다. ![`newline` 활성화](images/insert-newline-end-highlight.png) ::: ## 실습 ### `.Renviron` 환경변수 파일 편집 1. R 콘솔에서 `usethis::edit_r_environ()` 실행 2. WTF_USER={사용자명}\_user 추가 3. R 세션 새로 실행: `CTRL + SHIFT + F10`(윈도우), `CMD + SHIFT + 0`(맥) 4. `WTF_USER` 환경변수 값 `Sys.getenv("WTF_USER")` 명령어로 확인 ### `.Rprofile` 환경변수 파일 편집 1. R 콘솔에서 `usethis::edit_r_profile()` 혹은 `usethis::edit_r_profile("project")` 실행 2. print("Rprofile 코드 추가") 3. R 세션 새로 실행: `CTRL + SHIFT + F10`(윈도우), `CMD + SHIFT + 0`(맥) 4. `WTF_USER` 환경변수 값 `Sys.getenv("WTF_USER")` 명령어로 확인 ## R 패키지 R 패키지 설치 방법은 크게 바이너리 설치와 소스 코드 컴파일 설치로 구분된다. 바이너리 설치는 미리 컴파일된 패키지를 사용하는 방식으로, `install.packages("패키지이름")`으로 간단히 실행할 수 있다. 이 방법은 빠르고 편리하지만, 시스템 특정적이며 최신 버전이 늦게 제공될 수 있다. 반면 소스 코드 컴파일 설치는 `install.packages("패키지이름", type = "source")`로 실행하며, 사용자 시스템에서 직접 컴파일하여 설치한다. 이 방식은 시간이 더 걸리고 추가 도구가 필요할 수 있지만, 시스템 최적화와 최신 버전 사용이 가능하다다. 일반 사용자에게는 간편한 바이너리 설치가 권장되나, 특수한 요구사항이나 최신 기능이 필요한 경우 소스 코드 설치가 적합할 수 있다. 운영체제에 맞게 패키지를 구할 수 있는 곳은 [CRAN](https://cran.r-project.org/), [Posit Public Package Manager (p3m)](https://packagemanager.posit.co/client/#/)가 대표적이다. | 운영체제 | CRAN | Posit Public Package Manager (p3m) | |:-------------------------:|:----------------:|:--------------------------:| | {{< fa brands windows >}} 윈도우즈 | ✅ | ✅ | | {{< fa brands apple >}} 맥 OS | ✅ | ✅ | | {{< fa brands linux >}} 리눅스 | ❌ | ✅ | ## `R_LIBS_USER` 패키지 저장소 수만개의 R 패키지 중에서 일부를 로컬 컴퓨터에 설치하여 프로젝트에 활용하여 성과를 내게 된다. CRAN, P3M에서 다운로드하여 패키지가 설치된 `R_LIBS_USER` 환경정보를 `.Renviron` 파일에 설정하는 방법은 몇단계를 걸친다. ::: panel-tabset ### `edit_r_environ()` R 콘솔에서 `usethis::edit_r_environ()` 명령어를 실행하여 `.Renviron` 파일을 연다. ### `R_LIBS_USER` `R_LIBS_USER` 환경변수 설정을 한다. R_LIBS_USER=C:/Users/<사용자명>/AppData/Local/R/win-library/4.4 ### 세션 재시작 `CTRL + SHIFT + F10`(윈도우), `CMD + SHIFT + 0`(맥) 명령어를 실행하여 세션을 재시작한다. ### 수정사항 확인 ```r Sys.getenv("R_LIBS_USER") [1] "C:/Users/<사용자명>/AppData/Local/R/win-library/4.4" ``` ::: ### R 패키지 개발과 활용 R 패키지는 개발과정과 개발된 패키지를 활용하는 두가지 단계로 크게 구분할 수 있다. 소스코드를 번들로 만들고 이를 빌드하여 바이너리 배포용 패키지를 제작하는 과정과 패키지를 설치한 후에 이를 활용하는 두가지 단계로 나눌 수 있다. ```{mermaid} %%| label: pkg-downstream %%| fig-align: center flowchart TD subgraph dev["개발"] direction LR 소스 -- "devtools::build()" --> 번들 번들 -- "devtools::build(binary = TRUE)"--> 바이너리 end subgraph use["설치 활용"] direction LR 바이너리 --"install.packages()"--> 설치됨 설치됨 --"library()"--> 로드됨 end ``` ### 바이너리와 소스 패키지를 바이너리(binary)를 기본으로 설치하는 것을 추천하지만 `GitHub` 저장소에서 R 패키지를 설치할 경우 불가피하게 패키지를 소스(source)에서 설치해야한다. `install.packages()` 함수를 사용할 때 `type` 파라미터를 "source"로 지정하면 CRAN, P3M 에서 바이너리 대신 소스를 컴파일하여 설치할 수 있다. ```r install.packages("패키지명", type = "source") ``` `devtools` 패키지를 사용하여 GitHub 등에서 특정 버전의 소스를 직접 설치할 수 있는데 컴파일 시간이 더 오래 걸릴 수 있고, 시스템에 필요한 개발 도구가 설치되어 않으면 패키지를 설치할 수도 없다. ```r devtools::install_github("사용자명/레포지토리명") ``` 로컬 컴퓨터 환경에 맞춰 C, C++, 포트란(Fortran), 러스트(Rust) 언어로 된 코드를 컴파일할 수 있는 도구를 운영체제에 맞춰 설치를 해야만 소스코드 형태 R 패키지를 설치할 수 있다. ::: panel-tabset ### 윈도우즈 {{< fa brands windows >}} [Rtools](https://cran.r-project.org/bin/windows/Rtools/) ### 맥OS {{< fa brands apple >}} [XCode](https://apps.apple.com/us/app/xcode/id497799835?mt=12) ``` bash xcode-select --install ``` ### 리눅스 {{< fa brands linux >}} install tools via package manager, e.g. ``` bash apt install make ``` ::: 운영체제에 맞춰 도구를 설치하면 `devtools::has_devel()` 명령어로 설치여부를 점검할 수 있다. ```{r} devtools::has_devel() ``` ## 재현가능 환경 데이터 과학 작업의 환경을 재현하는 전략을 크게 재현성 환경관리 책임자와 패키지 접근 개방이라는 두 가지 축을 기반으로 '스냅샷 및 복원(Snapshot)', '공유 기준선(Shared Baseline)', '검증(Validated)'이라는 세 가지 성공적인 전략을 제시하는 동시에 '무법 지대', '티켓 시스템', '차단'이라는 세 가지 위험 구역도 언급하고 있다. [^strategy-map] [^strategy-map]: [Strategy Maps - Strategies to Reproduce Environments Over Time](https://solutions.posit.co/envs-pkgs/environments/reproduce/) ![재현성 환경 전략지도](images/reproducibility-strategies-and-danger-zones.png) **스냅샷 전략**은 데이터 과학 작업의 재현성을 보장하는 효과적인 방법으로 널리 인정받고 있다. 주요 장점으로 특정 시점의 환경을 정확히 캡처하고 나중에 그대로 복원할 수 있다는 점으로, 프로젝트의 모든 종속성, 패키지 버전, 설정을 포함한 전체 작업 환경을 보존함으로써 연구 결과의 정확한 재현을 가능하게 한다. 스냅샷 전략은 동시에 유연성도 제공한다. 데이터 과학자들은 필요에 따라 자유롭게 패키지를 설치하고 업데이트할 수 있으며, 동시에 각 프로젝트의 고유한 환경을 유지할 수 있다. 이를 통해 혁신과 실험을 장려하면서도 프로젝트의 안정성을 보장하는 균형 잡힌 접근 방식으로 팀 협업 시에도 모든 구성원이 동일한 환경에서 작업할 수 있게 하여 "내 컴퓨터에서는 작동합니다"와 같은 문제를 해결하는데 기여할 수 있다. 그러나 스냅샷 전략에도 몇 가지 단점도 존재한다. 첫째, 스냅샷 관리에 추가적인 시간과 리소스가 필요하다. 특히 큰 조직이나 많은 프로젝트를 다루는 경우, 여러 스냅샷을 관리하고 추적하는 것이 복잡해질 수 있다. 둘째, 스냅샷은 시간이 지남에 따라 용량을 많이 차지할 수 있으며, 이는 저장 공간 문제로 이어질 수 있다. 마지막으로, 보안 업데이트나 중요한 버그 수정이 있을 때 모든 관련 스냅샷을 업데이트해야 하는 번거로움이 있을 수 있다. ### 프로젝트 공유환경 ```{mermaid} graph L --- P1 L --- P2 L --- P3 L(library) P1(프로젝트1) P2(프로젝트2) P3(프로젝트3) ``` ::: ```{r} #| eval: false > .libPaths() [1] "C:/Users/statkclee/AppData/Local/R/win-library/4.4" # 사용자 [2] "C:/Program Files/R/R-4.4.1/library" # 시스템 ``` ### 프로젝트 격리 환경 ```{mermaid} graph C --- L1 C --- L2 C --- L3 L1 --- P1 L2 --- P2 L3 --- P3 L1(library1) L2(library2) L3(library3) P1(프로젝트1) P2(프로젝트2) P3(프로젝트3) C(글로벌 캐쉬) ``` ```{r} #| eval: false - Project '~/sample-project' loaded. [renv 1.0.7] > .libPaths() [1] "C:/Users/statkclee/Documents/sample-project/renv/library/windows/R-4.4/x86_64-w64-mingw32" [2] "C:/Users/statkclee/AppData/Local/R/cache/R/renv/sandbox/windows/R-4.4/x86_64-w64-mingw32/88765555" ```