패키지가 다른 컴퓨터에서는 빌드되는데 맥에서 컴파일 오류가 나거나, 검사 결과가 무엇을 보장하는지 불분명한가요?
macOS 지원이 필요하면 실제 맥에서 R CMD check을 실행하세요. 먼저 R과 명령줄 도구 체인을 확인한 다음 소스 패키지, 컴파일 코드, 테스트와 문서를 차례로 검수해야 합니다. 맥에서 통과해도 Windows, Linux 또는 CRAN 검수까지 통과한다는 뜻은 아닙니다.
이 글은 연구실 R 패키지를 배포하거나 인계하려는 연구자, macOS arm64용 코드를 확인해야 하는 개발자, 팀의 맥 검수 환경을 마련하는 대학 기술 담당자를 위한 안내입니다. macOS에서의 검수와 여러 운영체제 검수를 구분하는 데 초점을 둡니다.
준비 단계: 검수할 환경을 기록합니다
검사 결과를 비교하려면 프로젝트 상태와 실행 환경을 먼저 남겨야 합니다. R 버전, R의 실행 아키텍처, macOS 버전, 의존 패키지, 프로젝트 커밋을 기록하세요. Apple Silicon 맥을 쓰더라도 R이 어떤 아키텍처로 실행 중인지 확인해야 합니다. 하드웨어 이름만으로 실행 환경을 단정하면 안 됩니다.
R.version$version.string
R.version$arch
R.version$platform
Sys.info()[["machine"]]
이 값과 sessionInfo() 출력을 검사 기록에 보관하면, 다른 사람이 결과를 재현하거나 환경 차이를 좁힐 때 도움이 됩니다. 의존 패키지는 프로젝트에서 사용하는 방식과 함께 기록하고, 검사 전에 임의로 업데이트하지 마세요. 의존성이 바뀌면 이전 결과와 직접 비교하기 어려워질 수 있습니다.
맥에서 R CMD check을 시작하기 전에 무엇을 준비해야 하나요?
깨끗한 프로젝트 사본, 현재 커밋 정보, R과 실행 아키텍처 기록, 패키지 의존성 목록이 필요합니다. 또한 Apple Command Line Tools가 설치되어 있고 예상한 개발자 디렉터리가 선택됐는지 확인하세요. Apple은 명령줄 도구 설치와 선택 설정을 별도로 안내하므로, 설치 여부와 활성 경로를 각각 점검해야 합니다. Apple의 명령줄 도구 설치 안내와 활성 도구 경로 설정 설명을 기준으로 현재 환경을 확인하세요.
도구 설치가 곧 모든 패키지의 컴파일 준비를 의미하지는 않습니다. 패키지가 별도 헤더 파일이나 시스템 라이브러리에 의존한다면 해당 의존성도 갖춰야 합니다. 필요한 도구는 R 설치 환경과 패키지 구성에 따라 달라질 수 있으므로, 전체 Xcode를 무조건 설치하는 식으로 해결책을 일반화하지 마세요. macOS의 R 설치와 구성은 R 설치 및 관리 안내서도 참고할 수 있습니다.
| 선택지 | 확인할 점 | 판단 기준 |
|---|---|---|
| Apple Command Line Tools | 설치 여부와 선택된 도구 경로를 확인합니다. | 패키지의 컴파일 요구사항을 충족하는지 확인한 뒤 사용합니다. |
| 전체 Xcode | 프로젝트가 요구하는 구성 요소와 개발 환경을 확인합니다. | 패키지나 작업 흐름이 전체 Xcode 구성에 의존할 때 고려합니다. |
| 현재 환경 유지 | R의 실행 아키텍처와 컴파일 설정을 기록합니다. | 의존성이 이미 갖춰졌고 검수 조건을 재현할 수 있을 때 사용합니다. |
실행 단계: 작업 폴더가 아니라 소스 패키지를 검사합니다
개발 폴더에서 바로 검사를 실행하면, 배포용 산출물에 빠진 파일을 놓칠 수 있습니다. 먼저 소스 패키지를 만든 다음, 생성된 압축 파일을 검사하세요. R 공식 안내는 패키지 빌드와 검사 명령의 사용법을 설명하며, 검사 대상과 옵션은 Writing R Extensions과 R 패키지 빌드·검사 도구 문서에서 확인할 수 있습니다.
set -o pipefail
R CMD build . 2>&1 | tee build.log
R CMD check --as-cran 패키지_버전.tar.gz 2>&1 | tee check.log
패키지_버전.tar.gz는 실제 빌드 결과 파일명으로 바꿉니다. 명령과 로그를 보관하고, 검사 산출물 디렉터리도 함께 확인하세요. 파이프를 사용하는 셸에서는 앞선 명령의 실패가 로그 저장 과정에 가려지지 않도록 셸의 파이프 동작도 점검해야 합니다. 검사 환경 변수와 실행 조건은 R 공식 검사 안내에 따라 확인할 수 있습니다.
결과의 ERROR, WARNING, NOTE는 같은 의미가 아닙니다. 각 항목이 발생한 검사 단계와 메시지를 함께 살펴보세요. 특정 상태가 나왔다는 사실만으로 배포 가능 여부를 단정하지 말고, 문제가 패키지 코드인지, 환경 설정인지, 검사 정책에 관한 것인지 분리해야 합니다.
검사 로그에는 명령, 실행 환경, 커밋 식별 정보와 원본 메시지를 같이 보관하세요. 오류 문장을 복사해 없애기보다, 어떤 조건에서 다시 발생하는지 재현하는 편이 수정 검토에 유용합니다.
컴파일 단계: 도구 체인과 패키지 의존성을 나눠 봅니다
C, C++ 또는 Fortran 코드를 포함한 패키지에서는 컴파일러 이름만 확인해서는 부족합니다. 헤더 파일 위치, 링크할 라이브러리, R의 아키텍처가 서로 맞는지도 살펴야 합니다. 한쪽 환경에서 쓰던 설정값을 맥에 그대로 복사하면 경로 또는 아키텍처 차이로 실패할 수 있습니다.
xcode-select -p
R CMD config CC
R CMD config CXX
R CMD config FC
먼저 선택된 개발자 도구 경로와 R이 사용하는 컴파일러 설정을 기록합니다. 이어서 실패한 컴파일 명령에서 빠진 헤더 또는 라이브러리 이름을 찾아, 해당 항목이 패키지 자체에 포함되는지 외부 의존성인지 확인하세요. 빌드 로그는 R의 빌드와 검사 설명과 대조할 수 있습니다.
맥에서 R 패키지 컴파일 오류가 나면 어디부터 확인하나요?
실패 메시지에서 컴파일러 호출, 헤더 파일, 링크 단계 중 어디에서 멈췄는지 먼저 확인합니다. 다음으로 R의 실행 아키텍처와 도구 경로를 비교하고, 외부 시스템 라이브러리가 누락됐는지 점검하세요. 같은 오류가 최소 예제에서도 재현되는지 확인하면 패키지 코드 문제와 환경 문제를 좁히기 쉽습니다. 근거 없이 특정 도구 체인을 설치하거나 빌드 플래그를 바꾸기보다, 실패한 명령과 환경 기록을 함께 검토해야 합니다.
| 실패 위치 | 우선 확인할 증거 | 다음 조치 |
|---|---|---|
| 컴파일 시작 전 | 선택된 개발자 도구 경로, 컴파일러 설정 | 설치 여부와 활성 경로를 확인합니다. |
| 헤더 파일 탐색 | 오류에 표시된 헤더 이름과 검색 경로 | 패키지 또는 외부 의존성 중 제공 주체를 찾습니다. |
| 링크 단계 | 누락된 라이브러리 이름과 대상 아키텍처 | 라이브러리 설치 여부와 R 실행 아키텍처를 대조합니다. |
| 특정 함수의 테스트 | 재현 입력, 기대 결과, 플랫폼별 동작 | 최소 예제로 패키지 코드와 환경 차이를 분리합니다. |
검증 단계: 테스트와 문서를 깨끗한 세션에서 확인합니다
검사 전에 개인 작업 폴더에 있는 파일을 읽거나, 사용자의 홈 디렉터리에만 존재하는 설정을 참조하는 테스트가 없는지 확인하세요. 다른 연구자가 같은 저장소를 받아도 실행돼야 검수 결과를 인계할 수 있습니다. tests, examples, vignette와 도움말 문서는 서로 다른 경로에서 문제가 나타날 수 있으므로, 로그에 기록된 단계와 해당 파일을 연결해서 살펴봅니다.
문서나 vignette 검사에 실패하면 어떻게 위치를 좁히나요?
먼저 로그에서 실패한 문서 이름과 실행 단계를 찾습니다. 그 문서가 참조하는 파일이 저장소에 포함됐는지, 코드 청크가 깨끗한 세션에서 필요한 객체를 직접 만드는지 확인하세요. 도움말 예제와 vignette 실행 결과가 다르면, 전역 옵션이나 기존 작업 공간에 기대는 코드가 없는지 점검합니다. R 도구 문서의 설치된 패키지 테스트 설명도 테스트 방식과 범위를 살펴볼 때 참고할 수 있습니다.
랜덤 결과나 부동소수점 값은 플랫폼마다 계산 결과가 달라질 가능성을 고려해야 합니다. 프로젝트에서 허용하는 결과 범위와 비교 방식을 미리 정의하고, 검사 실패 때 임의로 기준을 완화하지 마세요. 계산 목적에 맞는 허용 오차와 결과 검증 절차를 연구팀이 문서화해야 합니다.
인계 단계: 통과 범위와 남은 검수를 구분합니다
맥에서 검사가 끝나면 환경 기록, 검사 로그, 수정한 실패 항목, 확인하지 않은 플랫폼을 한 묶음으로 정리합니다. macOS arm64에서의 성공은 그 환경에서 얻은 결과입니다. Windows와 Linux의 컴파일러, 시스템 라이브러리, 경로 처리 차이는 별도 검사 없이는 확인되지 않습니다.
R CMD check이 통과하면 Windows와 Linux에서도 사용할 수 있나요?
아닙니다. 맥에서 실행한 결과는 해당 맥 환경에서 확인한 범위만 보여 줍니다. 지원 대상에 Windows나 Linux가 포함되면 각 환경에서 빌드와 검사를 따로 수행해야 합니다. CRAN 제출을 목표로 한다면 플랫폼 검사 결과와 제출 요건을 별도로 확인하세요. 정책은 바뀔 수 있으므로 제출 직전 CRAN Repository Policy를 다시 검토해야 하며, 로컬 검사가 CRAN의 승인이나 접수를 보장하지는 않습니다.
| 검수 목표 | 맥에서 할 일 | 추가로 필요한 확인 |
|---|---|---|
| macOS arm64 지원 | 해당 환경에서 소스 패키지 빌드와 검사를 실행합니다. | 검사 당시 R, 아키텍처와 의존성을 기록합니다. |
| Windows와 Linux 지원 | 맥 검사 결과를 해당 플랫폼의 통과로 간주하지 않습니다. | 지원 플랫폼별 환경에서 별도 빌드와 검사를 수행합니다. |
| CRAN 제출 | 로컬 결과와 제출 전 체크 항목을 정리합니다. | 최신 CRAN 정책과 요구 플랫폼을 다시 확인합니다. |
현재 Windows나 Linux만 있는 연구실에서는 맥 검사만으로 드러나는 도구 경로, 시스템 라이브러리, arm64 컴파일 문제를 확인하기 어렵습니다. 반대로 장기간 반복해서 큰 작업을 돌리거나 물리적인 기기 연결이 필요한 경우라면 원격 맥 임대가 자가 장비보다 적합하지 않을 수 있습니다. 출시 직전 검수처럼 사용 기간이 정해져 있고 실험실에 맥이 없다면, 필요한 기간에 실제 macOS 환경을 확보해 검사하는 선택지를 검토할 수 있습니다. macOS 검수 환경이 당장 없다면 NodeMini의 맥 환경 안내와 원격 맥 주문 정보를 살펴보고, 패키지 일정과 필요한 검수 범위에 맞는지 판단하세요. R CMD check의 결과는 실행한 환경과 확인한 범위를 함께 남길 때 연구팀이 신뢰할 수 있는 인계 자료가 됩니다.