맥북을 손에 넣고 부푼 마음으로 안드로이드 앱 개발의 세계에 첫발을 내디딘 순간, 많은 개발자가 공통으로 마주하는 첫 번째 장벽이 있습니다. 바로 터미널에 adb 명령어를 입력했을 때 시스템이 차갑게 내뱉는 "zsh: command not found: adb" 메시지입니다. Android Studio를 설치하면 분명 SDK와 함께 ADB(Android Debug Bridge)가 설치되었음에도 불구하고, 왜 시스템은 ADB의 존재를 알지 못하는 걸까요? 이 문제는 단순히 파일이 없는 것이 아니라, 시스템이 그 파일이 '어디에' 있는지 몰라서 발생하는, 즉 '경로(PATH) 설정'의 부재에서 비롯됩니다. 이 글은 풀스택 개발자의 관점에서 이 고질적인 문제를 가장 확실하고 현대적인 방법으로 해결하는 과정을 심도 있게 다룹니다. 우리는 강력한 macOS용 패키지 관리자인 Homebrew를 통해 ADB를 설치하고, 그 과정의 이면에서 어떤 일이 일어나는지 낱낱이 파헤쳐 볼 것입니다. 단순히 명령어 몇 줄을 따라 치는 것을 넘어, 왜 수많은 방법 중 Homebrew가 최선인지, 환경변수의 근본적인 원리는 무엇인지 완벽하게 이해하여 여러분의 개발 환경을 반석 위에 올려놓는 굳건한 토대를 마련해 드리겠습니다.
ADB란 무엇이고 왜 필수적인가?
설치 방법을 논하기에 앞서, 우리가 왜 이토록 ADB 설치에 공을 들여야 하는지 그 본질을 이해하는 것이 중요합니다. ADB는 'Android Debug Bridge'의 약어로, 그 이름이 모든 것을 말해줍니다. 개발용 컴퓨터(우리의 맥북)와 안드로이드 기기(실제 스마트폰, 태블릿, 또는 가상 에뮬레이터) 사이에 데이터를 주고받고 명령을 내릴 수 있는 '디버깅용 다리'를 놓아주는 핵심적인 커맨드 라인 도구입니다. 이 다리가 없다면, 우리는 개발 중인 앱을 기기에 설치하거나, 앱이 왜 갑자기 죽는지 원인을 파악하거나, 기기 내부의 파일을 들여다보는 등 개발에 필수적인 거의 모든 작업을 수행할 수 없습니다.
ADB는 단순히 앱 설치와 실행을 넘어, 개발과 테스트의 전 과정을 아우르는 막강한 기능들을 제공합니다. 이것이 단순한 유틸리티가 아니라 안드로이드 개발 생태계의 '표준 통신 규약'으로 불리는 이유입니다. 구체적으로 ADB가 어떤 놀라운 일들을 가능하게 하는지 살펴보면 그 중요성을 더욱 깊이 체감할 수 있습니다.
- 애플리케이션 생명주기 관리:
adb install [apk_path]명령어를 통해 개발 중인 APK(Android Package) 파일을 수 초 내에 기기에 설치할 수 있습니다. Google Play Store를 통하는 번거로운 과정 없이, 코드 수정 후 즉시 빌드하여 테스트하는 빠른 개발 사이클의 핵심입니다. 반대로adb uninstall [package_name]으로 깔끔하게 앱을 삭제할 수 있습니다. - 실시간 로그 분석 (Logcat): 안드로이드 운영체제와 실행 중인 모든 앱은 끊임없이 자신의 상태와 활동에 대한 로그를 남깁니다.
adb logcat은 이 모든 로그를 개발자의 터미널 화면에 실시간으로 쏟아내 주는, 디버깅의 가장 첫 번째 단추입니다. 앱의 예상치 못한 종료(Crash), 성능 저하, 로직 오류 등의 원인을 파악하는 결정적인 단서를 바로 이 로그캣에서 찾게 됩니다. - 기기 내부 쉘(Shell) 접근:
adb shell명령어는 안드로이드 기기의 리눅스 커널 기반 쉘 환경으로 직접 들어가는 문을 열어줍니다. 이를 통해 우리는 마치 서버에 SSH로 접속한 것처럼 파일 시스템을 탐색(ls), 파일 권한을 변경(chmod)하거나, 숨겨진 시스템 설정을 확인하고 변경하는 등 일반적인 앱 UI로는 불가능한 고수준의 제어를 할 수 있습니다. - 자유로운 파일 전송: 내 맥북의 파일을 기기로 보내는
adb push와 기기의 파일을 내 맥북으로 가져오는adb pull은 데이터를 다루는 모든 작업에 필수적입니다. 테스트에 필요한 대용량 미디어 파일을 기기에 미리 넣어두거나, 앱이 생성한 데이터베이스 파일이나 로그 파일을 컴퓨터로 가져와 정밀하게 분석하는 데 사용됩니다. - 화면 캡처 및 녹화: 버그 리포트를 작성하거나, 앱의 새로운 기능을 시연하는 영상을 만들 때 매우 유용합니다.
adb shell screencap으로 현재 화면을 이미지 파일로 저장하고,adb shell screenrecord로 사용자의 조작 과정을 동영상으로 녹화할 수 있습니다. - 디버깅 세션 관리:
adb devices명령어로 현재 연결된 모든 안드로이드 기기 목록과 그 상태를 한눈에 파악할 수 있습니다. 또한, USB 케이블 없이 Wi-Fi를 통해 무선으로 ADB를 연결하여 케이블의 제약에서 벗어나 자유롭게 개발 환경을 구축할 수도 있습니다.
이처럼 ADB는 안드로이드라는 거대한 생태계와 개발자가 소통하는 가장 근본적이고 강력한 창구입니다. 따라서 어떤 방법을 사용하든 안정적이고 올바른 ADB 환경을 구축하는 것은 선택이 아닌, 생산적인 개발을 위한 필수 전제 조건이라 할 수 있습니다. 이제 왜 그 구축 방법으로 Homebrew가 가장 현명한 선택인지 알아보겠습니다.
왜 Homebrew인가? 수동 설치와의 결정적 차이
맥북에 ADB를 설치하는 방법은 전통적으로 두 가지로 나뉩니다. 첫 번째는 안드로이드 공식 개발자 사이트에서 'SDK Platform-Tools'라는 이름의 zip 파일을 직접 다운로드하여, 사용자가 원하는 폴더(예: ~/Library/Android/sdk/platform-tools)에 압축을 해제하고, 이 폴더의 경로를 ~/.zshrc나 ~/.bash_profile 같은 쉘 설정 파일에 수동으로 추가하는 고전적인 방식입니다. 두 번째가 바로 이 글의 주인공인 Homebrew를 이용하는 방식입니다.
Homebrew는 "The Missing Package Manager for macOS"라는 슬로건처럼, macOS에 기본적으로 포함되어 있지 않은 수많은 오픈소스 소프트웨어들을 터미널 명령어 한 줄로 설치, 업데이트, 관리할 수 있게 해주는 마법 같은 도구입니다. 풀스택 개발자로서 저는 다양한 언어의 런타임, 데이터베이스, CLI 도구들을 설치하고 관리해야 하는데, Homebrew가 없었다면 프로젝트마다 다른 버전의 도구들을 관리하다가 엄청난 시간을 낭비했을 것입니다. ADB 설치 역시 마찬가지입니다. 왜 굳이 Homebrew를 사용해야 할까요? 그 이유는 단순히 '편리함'을 넘어섭니다.
Homebrew를 사용하다 보면 `Formula`와 `Cask`라는 용어를 접하게 됩니다.
- Formula: 주로 커맨드 라인에서 사용되는 소스 코드 기반의 작은 유틸리티들을 설치할 때 사용됩니다. Homebrew가 소스를 직접 컴파일하여 설치하는 경우가 많습니다. (예: `brew install wget`)
- Cask: 이미 컴파일된 바이너리 파일이나 GUI를 포함한 일반적인 macOS 애플리케이션을 설치할 때 사용됩니다. `android-platform-tools`는 구글이 직접 빌드한 바이너리 파일(adb, fastboot 등)을 포함하므로 Cask를 통해 설치합니다. (예: `brew install --cask google-chrome`)
Homebrew 방식이 수동 설치 방식보다 압도적으로 우월한 이유를 다음 표를 통해 명확하게 비교해 보겠습니다.
| 평가 항목 | 수동 설치 (SDK Platform-Tools 직접 다운로드) | Homebrew를 이용한 설치 |
|---|---|---|
| 설치 과정 | 웹사이트 방문 → zip 파일 다운로드 → 압축 해제 → 원하는 위치로 폴더 이동 → 쉘 설정 파일(.zshrc 등) 열기 → export PATH=... 구문 직접 추가 → 터미널 재시작. 과정이 복잡하고 실수할 여지가 많음. |
터미널에 brew install --cask android-platform-tools 명령어 한 줄 입력. 모든 과정이 자동으로 처리됨. |
| 경로(PATH) 설정 | 사용자가 직접 쉘 설정 파일을 편집해야 하는 가장 큰 단점. 경로를 잘못 입력하거나 파일 형식을 깨뜨릴 경우 터미널 전체가 오작동할 수 있음. | 설치 시 Homebrew가 알아서 시스템 PATH에 등록된 디렉토리에 심볼릭 링크(Symbolic Link)를 생성. 사용자는 경로 설정에 대해 전혀 신경 쓸 필요가 없음. |
| 업데이트 관리 | 새 버전이 나왔는지 직접 확인하고, 다시 1번의 다운로드 및 압축 해제 과정을 반복해야 함. 이전 버전을 삭제하는 것도 수동으로 해야 함. | 터미널에 brew upgrade 명령어 하나만 입력하면 Homebrew가 관리하는 모든 패키지(ADB 포함)를 최신 버전으로 업데이트해줌. |
| 일관성 및 체계 | 사용자마다 설치 경로가 제각각이라 협업 환경에서 문제를 일으킬 수 있음. 어디에 설치했는지 잊어버리기 쉬움. | 모든 패키지는 Homebrew가 정한 일관된 경로(/opt/homebrew/Caskroom 등)에 체계적으로 관리됨. brew list 명령어로 설치된 모든 패키지를 한눈에 볼 수 있음. |
| 삭제 과정 | 설치했던 폴더를 직접 찾아 삭제하고, 쉘 설정 파일에 추가했던 PATH 설정 구문도 수동으로 제거해야 함. 찌꺼기 파일이 남기 쉬움. | brew uninstall --cask android-platform-tools 명령어 한 줄로 심볼릭 링크와 원본 파일 모두 흔적 없이 깔끔하게 제거됨. |
결론은 명확합니다. Homebrew를 사용하는 것은 단기적인 편리함을 넘어, 장기적인 관점에서 맥북의 개발 환경을 예측 가능하고, 안정적이며, 깨끗하게 유지하는 가장 현명하고 전문적인 선택입니다. 이제 이론은 충분하니, 직접 터미널을 열고 Homebrew의 강력함을 체험해 볼 시간입니다.
실전: Homebrew로 ADB 완벽 설치 (단계별 상세 가이드)
지금부터 스크린샷 없이도 누구나 따라 할 수 있도록 각 단계를 상세히 안내하겠습니다. 터미널(Terminal) 앱을 실행하고 아래 과정을 차근차근 따라와 주세요. Spotlight(Cmd+Space)에서 'Terminal'을 검색하면 쉽게 찾을 수 있습니다.
1단계: Homebrew 설치 여부 확인 및 신규 설치
가장 먼저, 당신의 맥북에 Homebrew가 이미 설치되어 있는지 확인해야 합니다. 터미널에 다음 명령어를 입력하고 Enter 키를 누르세요.
brew --version이 명령어를 실행했을 때, 아래와 같이 Homebrew와 함께 버전 번호(예: Homebrew 4.2.0)가 출력된다면 Homebrew는 이미 준비된 상태입니다. 축하합니다! 바로 2단계로 넘어가시면 됩니다.
하지만 만약 zsh: command not found: brew 라는 메시지가 나타난다면, 아직 Homebrew가 설치되지 않았다는 의미입니다. 걱정할 필요 없습니다. Homebrew 공식 웹사이트에서 제공하는 안전한 설치 스크립트를 사용하여 설치할 수 있습니다. 아래 명령어를 그대로 복사하여 터미널에 붙여넣고 Enter를 누르세요.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"이 스크립트는 Homebrew를 설치하는 데 필요한 파일들을 다운로드하고 설치를 진행합니다. 설치 과정에서 몇 가지 설명을 보여주고 진행 여부를 물어볼 수 있습니다. Enter 키를 눌러 계속 진행하고, 중간에 macOS 사용자 계정의 비밀번호를 요구하면 입력해주세요. (비밀번호 입력 시 화면에 아무것도 표시되지 않는 것이 정상이니 당황하지 말고 입력 후 Enter를 누르세요.)
설치가 거의 끝나갈 무렵, 터미널 화면에 'Next steps:'라는 문구와 함께 몇 줄의 명령어가 나타날 수 있습니다. 이는 Homebrew의 실행 경로를 현재 사용 중인 쉘(zsh)에 등록하는 과정으로, 매우 중요합니다. 보통 아래와 같은 형식의 명령어 두 줄을 실행하라고 안내합니다. 화면에 나온 그대로 복사하여 실행해주세요.
# (Apple Silicon Mac 예시, 터미널에 나온 안내를 따르는 것이 가장 정확합니다)
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zshrc
eval "$(/opt/homebrew/bin/brew shellenv)"모든 과정이 끝났다면, 터미널을 완전히 껐다가 다시 켜거나, source ~/.zshrc 명령어를 실행하여 변경사항을 적용합니다. 그리고 다시 한번 brew --version을 입력하여 Homebrew가 성공적으로 설치되었는지 최종 확인합니다.
2단계: android-platform-tools 패키지 설치
Homebrew라는 강력한 무기가 준비되었으니, 우리의 목표인 ADB를 설치하는 것은 식은 죽 먹기입니다. ADB는 단독으로 제공되지 않고, fastboot 등 안드로이드 플랫폼 개발에 필요한 여러 도구들과 함께 android-platform-tools라는 패키지로 묶여 있습니다. 터미널에 다음 명령어를 입력하세요.
brew install --cask android-platform-tools이 명령어는 Homebrew에게 'Cask' 타입의 android-platform-tools를 설치하라고 지시하는 것입니다. 명령을 실행하면 Homebrew는 가장 먼저 자체 패키지 목록을 업데이트(Updating Homebrew...)한 후, 구글 서버에서 최신 버전의 android-platform-tools 패키지를 다운로드합니다. 다운로드가 완료되면 정해진 위치(보통 /opt/homebrew/Caskroom/android-platform-tools/ 아래 버전별 폴더)에 압축을 해제하고, 가장 중요한 작업, 즉 adb, fastboot 같은 핵심 실행 파일들을 시스템이 바로 인식할 수 있는 경로(Apple Silicon의 경우 /opt/homebrew/bin)에 심볼릭 링크로 연결해줍니다. 이 모든 과정은 사용자의 개입 없이 자동으로 진행되며, 네트워크 속도에 따라 몇 초에서 몇 분 정도 소요될 수 있습니다.
3단계: 설치 성공 여부 최종 검증
소프트웨어 설치 후에는 반드시 제대로 설치되었는지 확인하는 습관을 들이는 것이 좋습니다. 우리는 두 가지 명령어를 통해 ADB 설치를 완벽하게 검증할 것입니다.
1. ADB 실행 경로 확인:
which 명령어는 우리가 입력한 명령어의 실제 실행 파일이 시스템의 어느 위치에 있는지 정확하게 알려줍니다. 터미널에 다음을 입력해보세요.
which adbHomebrew를 통해 정상적으로 설치되었다면, 아키텍처에 따라 아래와 유사한 경로가 출력되어야 합니다. 이 결과는 adb라는 명령어가 이제 시스템의 PATH 경로 내에 존재하며, 터미널 어디에서든 실행될 준비가 되었음을 의미합니다.
# Apple Silicon Mac (M1, M2, M3 등)의 경우
/opt/homebrew/bin/adb
# 구형 Intel Mac의 경우
/usr/local/bin/adb만약 이 명령어 실행 후 아무것도 출력되지 않거나 에러가 발생한다면, 2단계 설치 과정에서 문제가 있었을 가능성이 높습니다. brew doctor 명령어를 실행하여 Homebrew의 상태를 점검해보는 것이 좋습니다.
2. ADB 버전 및 정보 확인:
이제 실제로 ADB가 잘 실행되는지 확인하기 위해 버전 정보를 요청하는 명령어를 실행합니다. 이는 ADB가 정상적으로 작동하는지 확인하는 가장 확실한 방법입니다.
adb --version성공적으로 설치되었다면, 다음과 같이 현재 설치된 ADB의 버전과 함께 상세한 정보가 출력됩니다.
Android Debug Bridge version 1.0.41
Version 35.0.0-11411520
Installed as /opt/homebrew/Caskroom/android-platform-tools/35.0.0/platform-tools/adb여기까지 아무런 오류 없이 진행되었다면, 여러분의 맥북에 ADB가 완벽하게 설치된 것입니다! 이제 마지막 관문이 남았습니다. 실제 안드로이드 기기를 USB 케이블로 맥북에 연결하고, 기기의 '설정' > '개발자 옵션'에서 'USB 디버깅'을 활성화해주세요. 그리고 터미널에서 adb devices를 실행했을 때, 연결된 기기의 시리얼 번호와 함께 'device'라는 문구가 보인다면 모든 준비가 성공적으로 끝난 것입니다.
원리 파헤치기: PATH 환경변수와 Homebrew의 마법
우리는 "command not found" 문제를 해결했지만, 그 근본적인 원리를 이해하면 앞으로 마주할 다른 개발 환경 설정 문제에도 자신감 있게 대처할 수 있습니다. 터미널에 adb라는 세 글자를 입력했을 때, 운영체제(macOS)는 도대체 어떻게 그 명령어가 /opt/homebrew/bin/adb라는 긴 경로에 있는 실제 파일이라는 것을 알고 실행하는 걸까요? 그 비밀의 열쇠는 바로 'PATH'라는 이름의 환경변수에 있습니다.
PATH는 운영체제가 사용자가 입력한 명령어를 찾기 위해 탐색해야 할 디렉토리(폴더)들의 목록을 담고 있는, 약속된 변수입니다. 일종의 '명령어 검색 경로 지도'라고 생각할 수 있습니다. 터미널에 다음 명령어를 입력하여 현재 여러분의 PATH 설정을 직접 확인해 보세요.
echo $PATH아마 아래와 같이 콜론(:)으로 구분된 여러 디렉토리 경로들이 길게 나열될 것입니다.
# 출력 예시 (시스템마다 다를 수 있습니다)
/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin이것이 바로 마법의 지도입니다. 우리가 터미널에 adb라고 입력하고 Enter를 치는 순간, 쉘(Shell, zsh)은 다음과 같은 순서로 행동합니다.
- PATH 변수에 등록된 첫 번째 경로, 즉
/opt/homebrew/bin으로 이동합니다. - 그 디렉토리 안에 'adb'라는 이름의 실행 파일이 있는지 확인합니다.
- (발견!) 파일이 있으면 즉시 그 파일을 실행하고, 탐색을 멈춥니다. 이것이 우리가 본 결과입니다.
- 만약
/opt/homebrew/bin에 'adb'가 없었다면, 쉘은 포기하지 않고 다음 경로인/opt/homebrew/sbin을 탐색합니다. - 이 과정을 PATH에 등록된 모든 경로에 대해 반복합니다.
- 목록의 마지막 경로까지 모두 확인했는데도 'adb'라는 파일을 찾지 못하면, 쉘은 최종적으로 "zsh: command not found: adb"라는 메시지를 우리에게 보여주는 것입니다.
이제 Homebrew의 역할이 명확해집니다. 수동 설치 방식의 가장 큰 문제점은, 사용자가 직접 android-platform-tools의 압축을 푼 경로(예: /Users/myname/mytools/platform-tools)를 PATH 변수에 수동으로 추가해줘야 한다는 것입니다. 이 과정에서 오타가 나거나, 설정 파일을 잘못 건드리면 심각한 문제가 발생할 수 있습니다.
하지만 Homebrew는 이 모든 것을 대신해줍니다. Homebrew를 설치할 때, 설치 스크립트는 Homebrew의 핵심 경로인 /opt/homebrew/bin을 우리의 PATH 변수 목록 맨 앞에 추가하도록 설정합니다. 그런 다음 brew install --cask android-platform-tools를 실행하면, 실제 adb 원본 파일은 /opt/homebrew/Caskroom/... 같은 깊숙한 곳에 설치되지만, Homebrew는 그 원본을 가리키는 심볼릭 링크(Symbolic Link, 또는 symlink)를 /opt/homebrew/bin 디렉토리에 생성합니다. 심볼릭 링크는 Windows의 '바로 가기'와 유사한 개념으로, 원본 파일을 대신하는 가짜 파일이라고 생각하면 쉽습니다.
결론적으로, 쉘은 PATH의 첫 번째 경로인
/opt/homebrew/bin에서adb라는 이름의 심볼릭 링크를 발견하고, 그 링크가 가리키는 실제 원본 파일을 실행시켜주는 것입니다. 이 우아한 방식 덕분에 우리는 복잡한 원본 파일의 경로를 전혀 알 필요도,.zshrc파일을 직접 수정할 위험을 감수할 필요도 없이, 언제나 터미널에서adb라는 편리한 이름으로 명령을 실행할 수 있게 됩니다. 이것이 바로 Homebrew가 제공하는 '관리의 마법'입니다.
생산성을 200% 올리는 필수 ADB 명령어 모음
ADB 설치라는 산을 넘었으니, 이제 그 강력한 기능들을 마음껏 활용할 차례입니다. 현업 안드로이드 개발자들이 매일같이 사용하는 필수 ADB 명령어들을 익혀두면, 마우스를 여러 번 클릭해야 할 작업을 명령어 한 줄로 끝내며 개발 생산성을 비약적으로 향상시킬 수 있습니다. 아래 목록은 단순한 소개를 넘어, 실무에서 마주할 수 있는 상황과 유용한 옵션까지 함께 다룹니다.
1. 기기 연결의 시작과 끝: `adb devices`
모든 ADB 작업의 시작점입니다. 현재 맥북에 연결되고 ADB가 정상적으로 인식한 기기들의 목록을 보여줍니다. 항상 어떤 작업을 하기 전에 이 명령어로 타겟 기기가 제대로 연결되었는지 확인하는 습관을 들이는 것이 좋습니다.
adb devices
# 정상 출력 예시
List of devices attached
R5CR826ABCD device <-- 실제 기기
emulator-5554 device <-- 안드로이드 스튜디오 에뮬레이터unauthorized: 기기 화면에 'USB 디버깅을 허용하시겠습니까?'라는 팝업이 떠 있다는 의미입니다. 기기에서 '허용'을 눌러주세요.offline: 기기와의 연결이 불안정하거나 끊겼다는 의미입니다. USB 케이블을 다시 연결하거나 다른 포트에 꽂아보세요.(목록에 없음): 케이블 문제, 드라이버 문제, 혹은 기기의 USB 디버깅 옵션이 꺼져 있을 수 있습니다.
2. 신속한 앱 설치/업데이트: `adb install`
빌드된 APK 파일을 기기에 설치합니다. Android Studio의 'Run' 버튼을 누르는 것과 동일한 작업을 터미널에서 수행할 수 있습니다. CI/CD 파이프라인에서 자동화된 테스트를 위해 빌드된 APK를 테스트 기기에 설치할 때 필수적으로 사용됩니다.
# 다운로드 폴더에 있는 my-app.apk 파일을 설치
adb install ~/Downloads/my-app.apk
# 이미 설치된 앱을 데이터는 유지한 채 업데이트하려면 -r (reinstall) 옵션을 사용
adb install -r ~/Downloads/my-app-v2.apk
# 권한을 자동으로 허용하면서 설치하려면 -g (grant permissions) 옵션을 추가
adb install -r -g ~/Downloads/my-app-v2.apk3. 깔끔한 앱 제거: `adb uninstall`
앱의 고유 식별자인 '패키지 이름'을 사용하여 기기에서 앱을 삭제합니다. 패키지 이름은 보통 `com.company.appname`과 같은 형식을 가집니다.
# 유튜브 앱 삭제 (패키지 이름: com.google.android.youtube)
adb uninstall com.google.android.youtube팁: 현재 설치된 모든 앱의 패키지 이름 목록을 보고 싶다면 `adb shell pm list packages` 명령어를 사용하세요. 특정 키워드로 필터링하고 싶다면 `grep`과 조합할 수 있습니다: `adb shell pm list packages | grep 'google' `
4. 데이터 주입과 백업: `adb push` & `adb pull`
컴퓨터와 기기 간의 파일 전송을 담당합니다. 디버깅에 있어 매우 중요한 역할을 합니다.
`adb push [로컬 경로] [기기 경로]`: 내 컴퓨터의 파일을 기기로 복사합니다.
# 내 컴퓨터 'Desktop'의 'config.json' 파일을 기기의 다운로드 폴더로 전송
adb push ~/Desktop/config.json /sdcard/Download/`adb pull [기기 경로] [로컬 경로]`: 기기의 파일을 내 컴퓨터로 가져옵니다. `.`은 현재 터미널 위치를 의미합니다.
# 기기에서 찍은 스크린샷을 내 컴퓨터 'Desktop'으로 가져오기
adb pull /sdcard/Pictures/Screenshots/shot.png ~/Desktop/
# 앱의 내부 데이터베이스 파일을 분석하기 위해 현재 폴더로 가져오기
adb pull /data/data/com.myapp.debug/databases/app.db .5. 기기의 심장부로 접속: `adb shell`
기기의 내부 리눅스 쉘 환경으로 직접 들어갑니다. 파일 시스템 탐색, 프로세스 확인, 시스템 속성 변경 등 무궁무진한 활용이 가능합니다.
# 쉘 접속
adb shell
# 이제부터의 명령어는 기기 내부에서 실행됨
generic_x86:/ $ ls -l /sdcard/
generic_x86:/ $ cat /proc/meminfo # 메모리 정보 확인
generic_x86:/ $ exit # 쉘 종료단일 명령어를 실행하고 바로 빠져나오고 싶을 때는 `adb shell [command]` 형식을 사용하면 매우 편리합니다.
# 현재 기기의 배터리 상태 상세 정보 출력
adb shell dumpsys battery
# 현재 화면의 해상도 확인
adb shell wm size6. 버그 사냥꾼의 필수품: `adb logcat`
기기에서 발생하는 모든 로그를 실시간으로 터미널에 출력합니다. 디버깅의 시작과 끝이라고 할 수 있습니다. 아무 옵션 없이 실행하면 모든 로그가 쏟아져 나오므로, 필터링 옵션을 잘 활용하는 것이 중요합니다.
# 모든 로그 보기 (Ctrl+C를 눌러 종료)
adb logcat
# 특정 로그 태그(예: "MainActivity")의 로그만 필터링해서 보기
adb logcat -s "MainActivity"
# 특정 프로세스 ID(PID)의 로그만 보기 (앱 크래시 직후 원인 파악에 유용)
adb logcat --pid=$(adb shell pidof -s com.myapp.debug)
# 로그를 파일로 저장하기
adb logcat -d > my_app_log.txt7. 특정 화면 강제 실행: `adb shell am start`
Activity Manager(am)를 통해 특정 액티비티(앱의 화면)를 강제로 실행시킵니다. 앱을 처음부터 실행하지 않고 특정 화면으로 바로 진입하여 테스트할 때 시간을 크게 절약해 줍니다. 딥링크(Deep Link)가 올바르게 동작하는지 테스트하는 데 매우 유용합니다.
# 카카오톡 앱의 메인 액티비티 실행
adb shell am start -n com.kakao.talk/.activity.main.MainActivity
# 특정 데이터를 전달하며 액티비티 실행 (URL 스킴 테스트)
adb shell am start -a android.intent.action.VIEW -d "myapp://product/12345" com.myapp.debug8. 증거 수집: 스크린샷과 화면 녹화
버그를 설명하거나 기능을 시연할 때 백 마디 말보다 한 번의 시각 자료가 효과적입니다.
스크린샷: `adb shell screencap`
# 1. 기기의 /sdcard/ 경로에 screenshot.png 라는 이름으로 화면 캡처
adb shell screencap /sdcard/screenshot.png
# 2. 캡처한 파일을 현재 컴퓨터 폴더로 가져오기
adb pull /sdcard/screenshot.png화면 녹화: `adb shell screenrecord`
# 1. 기기의 /sdcard/ 경로에 demo.mp4 라는 이름으로 화면 녹화 시작 (Ctrl+C로 중단)
adb shell screenrecord /sdcard/demo.mp4
# 2. 녹화된 비디오 파일을 현재 컴퓨터 폴더로 가져오기
adb pull /sdcard/demo.mp4결론: 이제 당신은 준비되었습니다
지금까지 우리는 맥북 환경에서 안드로이드 개발의 첫 관문인 'adb command not found' 오류를 마주하는 것에서부터 시작하여, Homebrew라는 가장 현대적이고 안정적인 도구를 통해 이 문제를 해결하는 전 과정을 함께했습니다. 더 나아가 단순히 문제를 해결하는 것을 넘어, 그 이면에 숨겨진 PATH 환경변수의 동작 원리와 Homebrew의 우아한 심볼릭 링크 방식까지 깊이 있게 이해했습니다. 이 지식은 앞으로 여러분이 마주할 수많은 개발 환경 설정 문제 앞에서 당황하지 않고, 원인을 분석하여 체계적으로 해결해 나갈 수 있는 튼튼한 지적 자산이 될 것입니다.
오늘 구축한 이 견고한 ADB 환경은 여러분이 앞으로 만들어나갈 위대한 안드로이드 애플리케이션 개발 여정의 가장 굳건한 초석입니다. 더 이상 번거로운 설정에 시간을 낭비하지 마세요. 이제 터미널을 열고, 오늘 배운 강력한 ADB 명령어들을 자유자재로 활용하며 개발의 효율을 극대화하고, 더 넓고 깊은 안드로이드 개발의 세계로 힘차게 나아가시길 바랍니다. 당신의 성공적인 개발 여정을 응원합니다.
Post a Comment