Homebrew 공식 설치 문서는 Apple Silicon Mac의 기본 설치 위치를 /opt/homebrew, Intel Mac의 기본 위치를 /usr/local로 안내합니다. 이 차이는 명령이 어느 실행 환경에 속하는지 확인할 때 중요합니다. 이번 주에는 프로젝트에 필요한 패키지를 먼저 조사하세요. macOS 공용 도구와 공유 의존성은 Homebrew, 프로젝트별 언어와 바이너리 의존성은 Conda를 우선 검토하면 됩니다. 둘 다 필요하면 역할을 나눠 함께 쓰고, 실제 분석 작업으로 검수하세요.

이 글은 새 프로젝트의 설치 방식을 정하는 연구생, 여러 프로젝트의 충돌과 재현성을 관리하는 개발자, 연구실의 맥 환경을 지원하는 담당자를 위한 안내입니다.

01

맥 연구 소프트웨어는 Homebrew와 Conda 중 무엇이 맞을까요?

패키지 관리자 이름보다 패키지가 제공되는지, 의존성을 어디까지 격리해야 하는지, 결과 환경을 다시 만들 수 있는지를 기준으로 판단하세요. Homebrew와 Conda는 같은 문제를 푸는 완전한 대체재가 아닙니다.

Homebrew는 macOS의 명령줄 도구나 여러 프로젝트가 공유할 도구를 설치하는 데 적합합니다. Conda는 프로젝트별 환경을 만들고, 그 안에서 언어와 바이너리 패키지 의존성을 관리하는 데 강점이 있습니다. 따라서 선택은 다음처럼 나눌 수 있습니다.

  • 여러 프로젝트에서 공통으로 사용할 명령줄 도구가 필요하면 Homebrew를 먼저 확인합니다.
  • 프로젝트마다 Python이나 바이너리 라이브러리 버전이 달라야 한다면 Conda 환경을 검토합니다.
  • 프로젝트가 두 부류의 구성 요소를 모두 요구한다면, 설치 위치와 호출 경로를 나눈 뒤 함께 사용합니다.

단, 어떤 도구를 선택하든 필요한 패키지가 해당 macOS와 칩 구조에 맞는 빌드로 제공되는지는 따로 확인해야 합니다. Conda 패키지 사양에는 패키지 이름과 버전뿐 아니라 빌드와 채널 정보도 포함될 수 있으므로, 단순히 패키지 이름만 검색해서 설치 가능성을 단정하지 마세요. Conda 패키지 사양 문서에서 패키지 식별 정보를 확인할 수 있습니다.

02

패키지 제공 여부와 설치 경로를 먼저 확인하세요

설치하려는 도구의 이름을 적기 전에 프로젝트가 실제로 사용하는 구성 요소를 목록으로 만드세요. 프로그램 본체, 명령줄 도구, 라이브러리, GUI 앱을 구분해야 합니다. 설치법이 하나로 보이더라도 실제 패키지는 Homebrew formula, Conda 채널, 소프트웨어 자체 설치 문서에 따로 있을 수 있습니다.

Homebrew는 조건에 맞는 사전 빌드 패키지인 bottle을 제공할 수 있지만, 모든 패키지에 같은 조건으로 제공되는 것은 아닙니다. Homebrew bottle 문서에서 bottle이 제공되는 조건을 살펴보고, 원하는 패키지의 현재 상태를 확인하세요. Conda도 마찬가지입니다. 사용하려는 채널에서 대상 플랫폼에 맞는 빌드가 있는지 확인해야 합니다. 특정 패키지 하나가 설치된다는 사실만으로 프로젝트 전체가 Apple Silicon에서 동작한다고 볼 수는 없습니다.

연구실 사례를 생각해 보겠습니다. 한 프로젝트가 공용 변환 도구와 Python 분석 라이브러리를 함께 요구한다면, 공용 명령은 Homebrew에서 검토하고 라이브러리는 Conda 환경에서 관리할 수 있습니다. 반대로 모든 의존성이 프로젝트 환경 안에 잘 들어오고 외부 프로그램을 호출하지 않는다면 Conda 중심 구성이 더 단순할 수 있습니다. 최종 기준은 도구 이름이 아니라 대표 입력 자료로 분석이 끝까지 실행되는지입니다.

03

Apple Silicon Mac에서 Homebrew와 Conda를 함께 써도 될까요?

함께 사용할 수 있습니다. 다만 같은 이름의 실행 파일이 양쪽에 있거나, 셸의 PATH가 예상과 다르면 의도한 버전 대신 다른 프로그램이 실행될 수 있습니다. 함께 쓸 때는 어떤 도구를 어느 쪽에서 관리하는지 기록하고, 터미널에서 실제 경로를 확인하세요.

Homebrew의 macOS 설치 안내에 적힌 기본 경로처럼, 칩 구조에 따라 설치 prefix가 달라질 수 있습니다. Conda 환경을 활성화한 뒤에는 which 같은 셸 명령으로 실행 파일 경로를 확인하고, 새 터미널에서도 같은 결과가 나오는지 살펴보세요. GUI 앱에서 외부 명령을 부르는 경우에는 터미널에서 성공했다는 이유만으로 검수가 끝난 것이 아닙니다.

Homebrew 공식 FAQ는 macOS GUI 앱이 기본적으로 Homebrew의 PATH를 물려받지 않을 수 있다고 설명합니다. 따라서 GUI에서 도구를 호출하는 연구 소프트웨어는 앱을 실제로 실행해 검증하세요. 터미널에서는 되지만 GUI에서는 명령을 찾지 못하는 상황이 생길 수 있습니다. GUI 앱과 PATH에 관한 Homebrew FAQ를 참고하세요.

04

Conda 환경 밖에 둘 연구 의존성은 무엇일까요?

여러 프로젝트에서 공통으로 사용하는 macOS 명령줄 도구, 시스템에 가까운 도구, 프로젝트 환경 안에 넣기 어려운 외부 프로그램은 Conda 환경 밖에 둘 후보입니다. 반대로 프로젝트마다 버전이 달라질 수 있는 언어 라이브러리나 바이너리 의존성은 Conda 환경 안에서 관리하는 편이 분리하기 쉽습니다.

이 구분은 절대 규칙이 아닙니다. 어떤 프로그램이 외부 명령을 부르는지, Conda 환경 안의 실행 파일을 사용할 수 있는지 확인해야 합니다. Conda에는 활성화된 환경을 거치지 않고 프로그램을 실행하는 conda run도 있습니다. conda run 문서를 보고 실행 방식을 검토한 뒤, 연구 도구가 실제로 그 경로를 사용할 수 있는지 확인하세요.

Homebrew와 Conda가 같은 역할을 맡도록 중복 설치하면 업데이트와 실행 경로를 추적하기 어려워질 수 있습니다. 채널을 여러 개 섞는 경우에도 패키지 선택과 충돌을 살펴야 합니다. Conda 공식 문서는 채널 우선순위와 채널 간 충돌 가능성을 다루므로, 채널을 추가할 때는 Conda 채널 관리 안내를 기준으로 구성을 남기세요.

05

환경 파일은 그대로 복사하는 것보다 다시 검수하는 것이 중요합니다

환경 기록에는 서로 다른 목적이 있습니다. 직접 의존성을 적어 새 환경을 만들기 쉽게 하는 기록과, 특정 플랫폼에서 해결된 의존성 구성을 더 자세히 남기는 기록은 쓰임이 다릅니다. Conda는 환경 내보내기와 가져오기를 지원하지만, 한 플랫폼에서 저장한 구성이 다른 플랫폼에서도 그대로 재현된다고 보장하는 것은 아닙니다. 환경 생성과 내보내기 안내를 참고해 연구실에서 사용할 기록 방식을 정하세요.

Homebrew 쪽에서 필요한 도구 목록은 Brewfile 문서의 방식으로 관리할 수 있습니다. Conda 환경 기록과 Brewfile을 함께 보관하면 Conda가 관리하는 프로젝트 의존성과 macOS 공용 도구의 설치 출처를 구분하기 쉽습니다. 여기에 사용한 채널, macOS와 칩 구조, 실행 명령, 입력 자료의 위치와 결과 확인 방법을 프로젝트 문서에 적으세요.

연구실 구성원에게 환경을 전달할 때는 기록 파일만 보내고 끝내지 마세요. 받는 사람이 목표 맥 환경에서 새로 구성한 다음, 동일한 최소 입력 자료로 대표 분석을 실행해야 합니다. 이 과정에서 빠진 외부 라이브러리, GUI 앱의 명령 호출, 경로 차이를 찾을 수 있습니다. 재현 가능성은 파일의 존재가 아니라 작업 결과로 확인해야 합니다.

06

프로젝트에 맞는 설치 경로를 결정하는 실행 목록

다음 항목을 확인한 뒤 설치 방식을 정하세요.

  • [ ] 프로젝트가 직접 사용하는 프로그램, 라이브러리, 명령줄 도구, GUI 앱을 따로 적습니다.
  • [ ] 각 패키지의 공식 설치 안내와 Homebrew formula 또는 Conda 채널에서 대상 macOS와 칩 구조에 맞는 빌드를 확인합니다.
  • [ ] 여러 프로젝트가 공유할 도구와 프로젝트별 버전이 필요한 의존성을 분리합니다.
  • [ ] Conda 환경 밖에서 관리할 도구가 Conda 안의 프로그램과 이름이나 호출 경로가 겹치는지 살펴봅니다.
  • [ ] Conda 환경 기록과 Brewfile에 설치 출처, 채널, 플랫폼 정보를 남깁니다.
  • [ ] 새 환경을 만든 뒤 연구실에서 실제로 사용할 대표 분석이나 GUI 작업을 실행합니다.
  • [ ] 실행 결과와 오류, 외부 명령의 경로를 기록하고 다른 구성원도 같은 절차를 따라 할 수 있는지 확인합니다.

공용 macOS 도구 체인이 중심이면 Homebrew부터 검토하세요. 프로젝트별 라이브러리와 바이너리 의존성의 분리가 우선이면 Conda를 중심에 두세요. 둘을 조합한다면 각 도구가 맡는 일을 나누고 호출 경로까지 검수하세요. 설치가 끝나도 대표 작업이 통과하지 않으면 연구 환경을 넘기지 않는 것이 안전합니다.

기존 Linux나 Windows 환경만으로는 macOS에서만 확인할 수 있는 동작과 GUI 호출을 검증하기 어렵습니다. 개인 맥을 구매하면 프로젝트가 끝난 뒤에도 장비를 보유하고 관리해야 하며, 연구실 공용 맥은 다른 작업과 사용 시간을 조율해야 할 수 있습니다. 이미 충분한 장비가 있고 장기간 같은 작업을 계속한다면 보유 장비를 쓰는 편이 나을 수 있습니다. 반면 Apple Silicon 맥이 없어 실제 macOS 환경에서 패키지 빌드와 프로젝트 실행을 확인해야 한다면, 짧은 검증 기간에는 원격 맥 임대가 구매보다 부담이 적은 선택지가 될 수 있습니다. 먼저 VpsMesh의 맥 미니 이용 안내에서 이용 방식을 확인하세요. 접속 위치를 포함해 선택지를 비교하려면 서울 지역 맥 미니 안내도 살펴볼 수 있습니다. 프로젝트 파일 반출과 연구실 보안 규칙도 함께 검토하세요. 임시 검증 환경에서 패키지 설치부터 대표 분석까지 통과시키면, 장비를 구매하거나 연구실 공용 환경을 바꾸기 전에 필요한 근거를 확보할 수 있습니다.