정답부터 말하면, 1Password SSH Agent 설정은 “키를 어디에 저장할지”보다 “어떤 앱과 터미널이 그 에이전트를 바라보는지”를 먼저 맞추는 작업입니다. 개인 PC에서 GitHub, GitLab, 클라우드 서버 접속 키가 늘어났다면 새 키를 계속 복사하기 전에 1Password 앱, SSH 에이전트 활성화, 공개키 등록, 터미널 확인 순서로 점검하면 실수를 크게 줄일 수 있습니다. 이 글은 개발자뿐 아니라 블로그 운영, 원격 서버 관리, 개인 프로젝트 배포를 시작한 사용자가 따라갈 수 있도록 화면 이름과 점검 기준을 실무형으로 정리했습니다.
요약: 1Password 앱에서 SSH Agent를 켜고, 금고에 SSH 키 항목을 저장한 뒤, 터미널의 SSH 설정이 1Password 에이전트를 사용하도록 맞춥니다. 이후
ssh-add -l, Git 원격 저장소 접속, 서버 로그인 테스트로 확인합니다. 앱 화면, 지원 OS, 요금제, 브라우저/데스크톱 기능은 업데이트로 바뀔 수 있으니 공식 도움말과 현재 앱 화면을 함께 확인하세요.
1. 이 설정이 필요한 상황부터 빠르게 구분하기
SSH 키는 Git 저장소, VPS, 홈서버, NAS, 배포 도구처럼 비밀번호 입력 없이 접속해야 하는 곳에서 자주 쓰입니다. 처음에는 ~/.ssh 폴더에 키 파일을 두고 쓰는 방식이 간단하지만, 노트북을 바꾸거나 여러 계정을 운영하거나 팀 프로젝트가 늘어나면 어느 키가 어느 서비스용인지 헷갈리기 쉽습니다. 1Password SSH Agent는 키 파일을 여기저기 복사하지 않고 1Password 항목으로 관리하면서, 터미널과 Git 클라이언트가 필요한 순간에 키 사용을 요청하도록 돕는 방식입니다.
특히 개인 노트북과 데스크톱을 함께 쓰는 사람, Git 계정을 둘 이상 쓰는 사람, 원격 서버 접속 기록을 정리하고 싶은 사람에게 유용합니다. 다만 모든 문제를 자동으로 해결하는 만능 설정은 아닙니다. 이미 로컬 SSH 설정이 복잡하거나 회사 장비 정책이 따로 있는 경우에는 기존 config 파일, Git 클라이언트, 터미널 앱이 어떤 에이전트를 호출하는지부터 확인해야 합니다.
2. 설정 전 준비물과 계정 조건 체크
먼저 데스크톱용 1Password 앱이 설치되어 있어야 하며, 사용 중인 운영체제에서 SSH Agent 기능을 지원하는지 확인해야 합니다. 또한 SSH 키를 저장할 금고가 준비되어 있어야 하고, GitHub 같은 서비스에 등록할 공개키와 1Password에 보관할 개인키의 차이를 이해해야 합니다. 공개키는 서비스 계정 설정에 붙여 넣어도 되지만, 개인키는 외부에 올리면 안 됩니다.
기존에 만든 SSH 키를 가져올 수도 있고, 1Password에서 새 SSH 키 항목을 만들 수도 있습니다. 어떤 방법을 쓰든 최종 목표는 “터미널이 1Password Agent를 통해 키 목록을 볼 수 있는 상태”입니다. 이미 ssh-agent, Windows OpenSSH Agent, Git Credential Manager, WSL을 함께 쓰고 있다면 한 번에 모두 바꾸기보다 현재 접속에 쓰이는 경로를 메모한 뒤 단계별로 전환하는 편이 안전합니다.
3. 1Password 앱에서 SSH Agent 켜는 흐름
공식 문서 기준으로 1Password는 데스크톱 앱에서 SSH Agent 기능을 제공하며, 앱 설정 안에서 개발자 또는 SSH 관련 메뉴를 확인하게 됩니다. 메뉴 이름은 버전과 운영체제에 따라 달라질 수 있으니 “Developer”, “SSH Agent”, “Integrations”에 해당하는 항목을 찾아보는 방식이 좋습니다. 기능을 켠 뒤에는 어떤 금고의 SSH 키를 에이전트가 사용할 수 있는지 범위를 정합니다.
여기서 중요한 기준은 최소 권한입니다. 개인 프로젝트 키, 회사 프로젝트 키, 테스트 서버 키를 모두 한 금고에 몰아넣기보다 용도별로 나눠 두면 나중에 접속 대상별 허용 범위를 추적하기 쉽습니다. 키 이름도 “github-personal-main”, “vps-blog-deploy”처럼 서비스와 용도를 함께 적으면 터미널에서 목록을 볼 때 헷갈리지 않습니다.
4. SSH 키 항목 만들기와 공개키 등록 순서
새 키를 만든다면 1Password의 SSH Key 항목에서 생성하고, 공개키 값을 복사해 GitHub, GitLab, Bitbucket, 서버의 authorized_keys 등 필요한 곳에 등록합니다. 기존 키를 가져온다면 개인키 파일을 1Password에 추가한 뒤, 원래 로컬 파일을 즉시 지우기보다 접속 테스트가 끝날 때까지 백업 위치를 확실히 확인합니다. 다만 개인키를 메신저, 메일, 클라우드 공유 링크에 그대로 올리는 방식은 피해야 합니다.
공개키 등록 후에는 서비스마다 키 제목을 명확하게 적어 두는 것이 좋습니다. 예를 들어 “2026 laptop 1Password agent”처럼 만든 날짜와 장치를 적으면 나중에 오래된 키를 정리할 때 도움이 됩니다. 서버 쪽에서는 권한 설정이 맞지 않으면 정상 키라도 거절될 수 있으니, 리눅스 서버라면 ~/.ssh와 authorized_keys 권한도 함께 확인해야 합니다.
5. 터미널, Git, WSL에서 확인하는 기본 명령
설정을 켠 뒤에는 터미널을 새로 열고 ssh-add -l로 에이전트가 제공하는 키 목록을 확인합니다. 목록이 비어 있다면 1Password 앱이 잠겨 있거나, SSH Agent가 꺼져 있거나, 현재 셸이 다른 에이전트를 바라보고 있을 가능성이 큽니다. Git 접속 확인은 ssh -T git@github.com처럼 서비스가 안내하는 테스트 명령을 사용하면 됩니다. 실제 사용자명 메시지가 나오면 키 매칭은 대체로 된 것입니다.
Windows와 WSL을 함께 쓰는 경우에는 어디에서 Git을 실행하는지가 중요합니다. Windows 터미널에서 실행하는 Git, WSL 내부의 Git, VS Code Remote 환경은 각자 다른 경로와 환경 변수를 볼 수 있습니다. 한쪽에서만 성공하고 다른 쪽에서 실패한다면 “1Password 문제가 아니라 실행 환경이 다른 문제”일 수 있으므로 같은 명령을 각 환경에서 따로 확인하세요.
6. 실수 줄이는 설정 체크리스트
- 1Password 데스크톱 앱이 최신 버전이며 잠금 해제되어 있는지 확인합니다.
- SSH Agent 기능이 켜져 있고 사용할 금고 범위가 너무 넓지 않은지 확인합니다.
- 키 항목 이름에 서비스, 용도, 생성 연도를 함께 적습니다.
- 공개키만 Git 서비스나 서버에 등록하고 개인키는 외부 입력란에 붙여 넣지 않습니다.
ssh-add -l로 목록을 확인한 뒤 실제 Git 또는 서버 접속 테스트를 진행합니다.- 기존
~/.ssh/config파일에 특정IdentityFile이 강제로 지정되어 있으면 충돌 여부를 확인합니다. - WSL, VS Code, GUI Git 클라이언트는 같은 에이전트를 쓰는지 각각 테스트합니다.
7. 흔한 오류와 빠른 해결 표
| 상황 | 가능한 원인 | 먼저 볼 곳 | 권장 조치 |
|---|---|---|---|
ssh-add -l에 키가 없음 |
앱 잠김, 에이전트 꺼짐, 셸 경로 불일치 | 1Password 앱 설정, 새 터미널 | 앱 잠금 해제 후 터미널을 다시 열고 목록 확인 |
| GitHub 테스트가 거절됨 | 공개키 미등록 또는 다른 계정에 등록 | GitHub SSH keys 화면 | 공개키 지문과 1Password 키 항목을 대조 |
| VS Code에서는 실패 | 내장 터미널과 확장 환경 차이 | VS Code Remote/터미널 설정 | 같은 명령을 OS 터미널과 VS Code에서 각각 실행 |
| 서버 접속만 실패 | 서버 사용자명, 포트, 파일 권한 문제 | ~/.ssh/config, 서버 로그 |
ssh -v로 어떤 키를 제안하는지 확인 |
8. 여러 계정과 여러 키를 관리하는 구조
개인 Git 계정과 업무용 Git 계정을 함께 쓴다면 키를 하나로 돌려 쓰기보다 계정별로 나누는 편이 깔끔합니다. ~/.ssh/config에서 호스트 별칭을 만들어 github-personal, github-work처럼 구분하면 저장소별 원격 URL도 명확해집니다. 1Password Agent는 키를 제공하고, SSH 설정은 어떤 대상에 어떤 키를 우선 제안할지 정리하는 역할로 나누어 생각하면 이해가 쉽습니다.
서버 접속도 마찬가지입니다. 블로그 배포 서버, 테스트 서버, NAS 접속 키를 같은 이름으로 두면 나중에 교체할 때 위험합니다. 키 항목 제목, 태그, 설명 필드에 서비스명과 사용 범위를 적어 두고, 더 이상 쓰지 않는 공개키는 서비스 쪽에서도 제거해야 합니다. 이 정리 습관이 있어야 장치를 분실했을 때 어떤 접속 경로를 막아야 하는지 빠르게 판단할 수 있습니다.
9. 최신 화면과 기능 변경 가능성 고지
1Password의 SSH Agent 메뉴 위치, 지원 운영체제, 브라우저 확장과 데스크톱 앱 연동 방식, 구독 요금제별 제공 기능은 업데이트에 따라 달라질 수 있습니다. 따라서 이 글의 흐름은 설정 순서를 이해하기 위한 기준으로 보고, 실제 버튼 이름과 세부 옵션은 1Password Developer 문서와 현재 설치된 앱 화면을 우선 확인해야 합니다. GitHub나 GitLab의 SSH 키 등록 화면도 서비스 개편으로 위치가 바뀔 수 있습니다.
또한 회사 장비, 학교 장비, 관리형 PC에서는 보안 정책 때문에 SSH Agent 기능이나 키 반출입이 제한될 수 있습니다. 이 경우 개인 판단으로 정책을 우회하지 말고 장비 관리자에게 허용된 개발 환경을 확인하세요. 개인 PC에서는 편의성과 안전성을 함께 보되, 공유 PC에서는 SSH 키 저장 자체를 피하는 것이 좋습니다.
10. 실전 적용 순서 요약
- 1Password 데스크톱 앱과 공식 SSH Agent 문서를 확인합니다.
- 용도별 SSH 키 항목을 만들거나 기존 키를 가져옵니다.
- 공개키를 Git 서비스 또는 서버 계정에 등록합니다.
- 앱에서 SSH Agent를 켜고 사용할 금고 범위를 제한합니다.
- 터미널을 새로 열어
ssh-add -l과 접속 테스트를 실행합니다. - WSL, VS Code, GUI Git 클라이언트처럼 실제 쓰는 환경별로 같은 테스트를 반복합니다.
- 성공 후 오래된 키, 중복 공개키, 불필요한 로컬 파일을 정리합니다.
FAQ
Q1. 1Password SSH Agent를 쓰면 기존 SSH 키 파일을 바로 지워도 되나요?
바로 지우기보다 새 방식으로 Git과 서버 접속이 모두 되는지 확인한 뒤 정리하는 편이 안전합니다. 백업 위치와 복구 방법을 확인하고, 더 이상 쓰지 않는 공개키도 서비스 쪽에서 함께 제거하세요.
Q2. GitHub에는 공개키와 개인키 중 무엇을 등록하나요?
GitHub 같은 서비스에는 공개키만 등록합니다. 개인키는 1Password 항목으로 보관하고 외부 웹 입력란, 메신저, 메일에 붙여 넣지 않는 것이 원칙입니다.
Q3. WSL에서만 키가 보이지 않는 이유는 무엇인가요?
Windows 터미널과 WSL은 서로 다른 셸 환경을 사용합니다. Windows 쪽 1Password Agent를 WSL에서 쓰도록 별도 연동이 필요한 경우가 있으므로 공식 문서의 WSL 관련 안내와 현재 환경 변수를 확인하세요.
Q4. 여러 Git 계정은 키 하나로 처리해도 되나요?
가능은 하지만 계정별 키를 나누는 편이 추적과 정리에 유리합니다. 특히 개인 프로젝트와 팀 프로젝트가 섞이면 키 제목, 호스트 별칭, 원격 URL을 분리하는 것이 실수를 줄입니다.
Q5. GUI Git 클라이언트가 계속 비밀번호를 묻는다면 어떻게 하나요?
해당 클라이언트가 시스템 SSH를 쓰는지, 내장 SSH를 쓰는지 확인해야 합니다. 같은 저장소를 OS 기본 터미널에서 먼저 테스트하고, 클라이언트 설정에서 SSH 실행 경로와 에이전트 사용 옵션을 점검하세요.