간단함

4분

1.2K

TL;DR

macOS로 전환한 후, WinSSHTerm만큼 편리하게 일상적인 시나리오를 해결해주는 SSH 클라이언트를 찾지 못했습니다.
끊임없는 타협에 지쳐서 요구사항을 정리하고, 클라이언트를 직접 만들어 코드를 오픈소스로 공개했습니다.

저장소

컨텍스트

여러 서버를 다룰 때 거의 모든 SSH 클라이언트가 "그럭저럭" 맞습니다.
매일 수십, 수백 대의 호스트를 다룬다면 슬라이드에 있는 기능보다 속도와 예측 가능성이 중요해집니다.

• 호스트를 얼마나 빨리 찾는지;

• 연결까지 몇 단계가 필요한지;

• 환경 구조를 정리하는 것이 얼마나 편리한지;

• 애플리케이션이 한 달간 활발히 사용된 후 어떻게 작동하는지.

Windows에서는 WinSSHTerm이 이 점에서 오랫동안 나를 도와주었다.
macOS로 전환한 후 하룻저녁에 유사한 도구를 찾을 수 있을 거라고 생각했다. 그렇지 않았다.

기존 솔루션에서 마음에 들지 않았던 점

나는 '이상'을 찾지 않았다. 일을 방해하지 않는 도구를 찾았다.
문제는 고객마다 반복되었다:

1. 세션까지의 경로가 너무 긺
   주 시나리오는 빨라야 하는데, 불필요한 클릭에 묻혀 있는 경우가 많았다.

2. 대규모 호스트 풀의 조직화가 미흡함
   환경과 프로젝트가 많을 때, 제대로 된 그룹, 태그, 검색이 없으면 모든 것이 혼란에 빠진다.

3. 과부하된 인터페이스
   화려한 패널과 '풍부한 UI'는 종종 앱을 여는 목적(연결과 작업)을 저하시켰다.

4. 설정 이식성의 불편함
   저장, 이전, 버전 관리가 쉬운 투명한 구성을 원했다.

몇 주간의 테스트 후에 나는 도구와 싸우는 데 문제를 해결하는 것보다 더 많은 시간을 쓰고 있다는 생각이 들었다.

왜 스스로 쓰기로 결정했는가

이유는 “주변 모든 사람들이 잘못했다”는 것이 아니다.
이유는 내가 특정 일일 업무 부하에 맞는 구체적인 요구 사항 집합을 가지고 있었기 때문이다.

나는 앉아서 내가 필수라고 생각하는 것을 정형화했다:

• 최대한 빠른 시작 및 연결;

• 이름/IP/태그로 검색;

• 환경 및 프로젝트별 그룹 구조;

• 자주 사용하는 작업을 위한 단축키;

• 예측 가능한 설정 저장;

• 최소한의 시각적 잡음;

• 대규모 호스트 목록에서 안정적인 동작.

그 후에 분명해졌다: 끝없이 다른 사람의 타협에 적응하는 것보다 자신의 도구를 만드는 것이 더 쉽다.

클라이언트가 구축한 원칙

1) Local-first

주 시나리오는 네트워크 의존 없이 빠르게 작동해야 한다.
호스트 및 세션 데이터는 로컬에서 사용 가능하며, UI는 목록을 열기 위해 '외부 서비스'를 기다리지 않는다.

2) 연결까지 더 빠르게

모든 기능은 "활성 세션까지의 경로를 단축시키는가?"라는 질문으로 평가됩니다.
그렇지 않다면 백로그로 이동합니다.

3) 예측 가능성은 '마법'보다 중요합니다.

약간 덜 '자동화된 지능'이더라도, 이해 가능하고 제어 가능한 로직이 낫습니다.

4) 설정은 자산으로 취급합니다.

설정은 다음 조건을 충족해야 합니다:

• 사람이 읽을 수 있을 것;

• 백업이 가능할 것;

• 머신 간에 이식 가능하며;

• Git에 편리합니다.

아키텍처 (개괄적)

애플리케이션을 여러 독립적인 레이어로 나누었습니다:

1. UI Layer
   호스트 목록, 검색, 필터, 세션 카드, 빠른 작업.

2. Session Layer
   SSH 세션의 수명 주기: 시작, 재연결, 종료, 상태.

3. 구성 레이어
   구성 읽기/검증/마이그레이션 (호스트, 그룹, 태그, 프리셋).

4. 저장 레이어
   서비스 데이터를 위한 로컬 저장소 (예: recent/favorites/history).

5. 통합 레이어
   시스템 SSH 및 macOS 환경과의 상호작용.

이것은 UI 로직과 연결을 혼합하지 않고 설정 형식이 변경될 때 모든 것을 망가뜨리지 않게 해주었습니다.

실제로 도움이 되는 데이터 모델

처음에는 단순화된 «호스트 목록» 모델을 시도했습니다.
빠르게 명확해졌습니다: 인프라가 성장함에 따라 적절한 구조가 필요합니다.

기본 엔티티:

• Host
  이름, 주소, 포트, 사용자, 인증 매개변수, 메타데이터.

• 그룹
  논리적 그룹화 (예:  prod, staging, clients/*).

• 태그
  교차 슬라이스 (k8s, db, critical, legacy).

• 프로필
  재사용 가능한 연결 매개변수.

• 세션 프리셋 (SessionPreset)
  세션 동작 사전 설정.

정확히 조합은 그룹 + 태그 + 검색 실제로 속도 측면에서 가장 큰 이점을 제공했습니다.

최대 효과를 낸 UX 솔루션

1. 기본 검색에 초점
   클라이언트를 열면 바로 인쇄하고 필터링할 수 있습니다.

2. 키보드 빠른 동작
   키보드/마우스 전환 횟수가 적을수록 작업 주기가 빨라집니다.

3. 최신 및 선택된 호스트
   잦은 연결은 1회의 작업으로 이루어져야 합니다.

4. 최소 모달 창
   모달이 흐름을 늦춘다. 그것들 없으면 더 나쁜 경우에만 사용했다.

5. 안정적인 정보 계층
   동일한 유형의 정보는 항상 한 곳에 있습니다.

보안 및 운영

나는 자주 "나중으로 미루는" 기본적인 것들을 따로 마련했습니다:

• 애플리케이션 내에 개인 키를 저장하지 않음;

• 시스템 SSH 메커니즘 사용;

• 다음 텍스트를 영어에서 한국어로 번역하십시오: __JHSNS_SEG_529e2a41_109__연결이 어떤 호스트/환경으로 가는지 명확히 표시;

• 위험한 기본값을 피함;

• 진단에 필요한 것만 로깅하고 민감한 데이터 유출 없음.

이것이 클라이언트를 '절대적으로 안전하게' 만드는 것은 아니며(그런 일은 없습니다), '편리하지만 위험한' 유형의 일반적인 실수를 제거합니다.

가장 어려웠던 점

1. 불필요한 기능을 포기하는 것
   버튼 추가는 쉽지만, 불필요한 것을 제거하는 것은 어렵다.

2. 단순성과 유연성의 균형 유지
   "간단하면서도 강력한" 것을 콤바인 없이 만드는 것은 반복의 결과이지, 한 번의 디자인이 아니다.

3. 작은 세부 사항을 편리하게 다듬다
   가장 "보이지 않는" 것들(포커스, 탭 순서, 키보드 시나리오)이 큰 기능보다 더 많은 것을 결정한다.

최종적으로 얻은 것

주요 변화는 "또 다른 SSH 클라이언트가 등장했다"는 것이 아닙니다.
핵심은 일상적인 마찰이 사라졌다는 것입니다:

• 필요한 노드를 더 빨리 찾고;

• 환경 전환 시 실수가 줄어들고;

• 인터페이스에 신경 쓰지 않으며;

• 이전/백업 시 설정과 씨름하지 않게 되었습니다.

간단히 말하면: 도구는 더 이상 문제의 일부가 아니며 다시 해결책의 일부가 되었습니다.

로드맵

프로젝트의 다음 단계:

1. 대규모 호스트 팜을 위한 벌크 작업 개선.

2. 구성 가져오기/내보내기 확장.

3. 더 유연한 필터 및 저장된 보기.

4. 장기 실행 시나리오(매일 몇 시간 작업)를 위한 UX 개선.

5. 기본 설정에서 추가 보안 검사.

비슷한 상황에 있는 사람들을 위해

macOS의 기성 솔루션이 마음에 들지 않는다면, 코드부터 시작하지 말고 매일 겪는 고통의 체크리스트부터 시작하는 것을 추천합니다.
요구사항이 정직하게 공식화되면, 계속 찾을지 아니면 직접 작성할지 명확해집니다.

제 경우에는 답이 두 번째였습니다.

저장소