📝 한 줄 요약
업무용·개인용 PC 사이 SCP 전송을 두 창 탐색기와 승인형 전송 큐로 바꾸고, 크기·파일 지문(SHA-256) 검증과 Windows 설치파일까지 만들었다.
바쁘시면 이것만 읽어도 돼요: - 목표: 명령어 없이 두 PC 사이 파일 전송을 준비하고 전송 결과를 검증하도록 설계한 SCP Route Manager를 만들었다 - 핵심 과정: 명령어로 전송 경로를 관리했다 → GUI에서 연결·검증·전송을 준비하게 했다 - 검증 경계: 개발 환경 검증을 실제 두 PC 간 전송 완료로 표현하지 않는다.
🎯 이런 분께 추천해요
SCP 명령어가 부담스러운 비개발자
두 PC 사이 파일 전송 결과를 검증해야 하는 분
자동 덮어쓰기와 자격증명 저장이 걱정되는 분
😫 문제 상황
SCP는 강력하지만 경로와 옵션을 잘못 입력하기 쉽고, 폴더 전송이 제대로 끝났는지 확인하기도 번거로웠다. 편의성을 높인다고 비밀번호를 저장하거나 충돌 파일을 자동 덮어쓰면 더 큰 위험이 생긴다.
🛠️ 사용한 도구
Electron Windows 앱
SCP·SSH 전송 계층
전송 큐·충돌 정책
파일 지문(SHA-256)·파일수·바이트 검증
Windows 설치 프로그램
AI 도구/모델: 현재 공개 근거에서 확인되지 않음
🔧 작업 과정
업무노트북과 집 PC 사이 파일 전송을 반복 설정 없이 두 창 탐색기에서 안전하게 처리하는 Windows 앱을 만들어줘.
로컬과 원격을 두 창 탐색기로 보여주고 보내기·받기 작업을 큐에 넣도록 했다. 파일 충돌 시 자동 덮어쓰지 않고 사용자가 정책을 선택하게 했다. 전송 후에는 파일 크기와 파일 지문(SHA-256), 폴더라면 파일 수와 전체 바이트를 비교했다.
비밀번호와 개인키 내용은 저장하지 않고, 실제 파일 변경은 파일 변경을 담당하는 앱 내부 영역에서 다시 승인하도록 경계를 뒀다.
초기 아이디어는 전송 명령을 감싸는 간단한 UI였지만, 실제 사용에서 더 중요한 것은 충돌과 실패 복구였다. 같은 이름의 파일이 있을 때 건너뛰기·이름 변경·덮어쓰기를 명시적으로 고르게 하고, 폴더 이동 중 일부만 성공하면 성공한 항목과 실패한 항목을 분리해 보여줬다.
기존 DEVLOG에는 이어쓰기 방식으로 개발 기록을 보존했다. 화면 구현, 실제 전송, 전송 후 해시 비교를 서로 다른 검증 단계로 나눠 “목록에 보였다”와 “상대 PC에 같은 파일이 저장됐다”를 혼동하지 않았다.
🧩 막힌 점
개발 환경의 테스트 성공과 실제 원격 PC 쓰기는 다른 문제였다. 승인 없는 원격 쓰기는 수행하지 않았고, 서명되지 않은 Windows 앱의 SmartScreen 경고 가능성도 남겼다.
✅ 결과
개발 환경의 자동 테스트와 기본 실행 검증을 통과했고 패키징된 EXE와 Windows 설치 프로그램을 만들었다. 실제 원격 쓰기 검증은 사용자 승인 이후 단계로 명확히 분리했다.
Before vs After
항목
Before
After
작업 방식
명령어로 전송 경로 관리
GUI에서 연결·검증·전송 준비
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
전송도구는 빠른 복사보다 무엇을 어디에 썼고 동일하게 도착했는지 증명하는 영수증이 중요했다.
이렇게 하면 안 돼요
개발 환경 검증을 실제 두 PC 간 전송 완료로 표현하지 않는다.
🌍 다른 업무에 적용한다면?
사내 PC 간 자료 전달과 현장 장비 로그 수집에 적용할 수 있다.
🚀 다음 계획
승인된 테스트 서버에서 실제 E2E 전송 영수증을 확인하고 코드서명 여부를 결정한다.
📋 재사용 프롬프트
비개발자가 쓸 SCP 전송 UI를 설계해줘. 자격증명은 저장하지 않고, 충돌은 승인받고, 전송 후 크기·해시·폴더 통계를 검증하며 원격 쓰기는 명시적 승인 뒤에만 실행해줘.
🖼️ 게시 전 체크
[ ] 두 창 UI 캡처
[ ] 호스트·사용자명 마스킹
[ ] SmartScreen 안내 추가
추천 이미지: - 문제 상황: 기존 방식의 불편을 보여주는 합성 화면 - 작업 과정: 입력→판단→검증 흐름도 - 결과: 실제 정보가 제거된 합성 결과 화면
