윈도우에서 리눅스 서버로 SCP 파일 전송하는 법: 명령어·경로·오류 해결

안전한 전송 7단계 체크리스트

1. 작은 시험 파일로 SSH 연결을 확인합니다.
2. 서버 주소·사용자·포트를 확인합니다.
3. 로컬과 원격의 전체 경로를 적습니다.
4. 원격 대상의 덮어쓰기 영향을 확인합니다.
5. SCP 명령을 실행하고 오류 전문을 보관합니다.
6. 서버에서 파일 크기와 권한을 확인합니다.
7. 중요 파일은 해시를 비교한 뒤 원본을 정리합니다.

자주 쓰는 명령 비교

오류 판단 표

SCP 전송을 시작하기 전에

SCP는 SSH 연결을 이용해 파일을 복사하는 명령입니다. 윈도우 10·11에는 OpenSSH 클라이언트가 기본으로 포함되는 경우가 많아 별도 프로그램 없이 PowerShell이나 Windows Terminal에서 실행할 수 있습니다. 먼저 서버 주소, 로그인 계정, SSH 포트, 비밀번호 또는 개인키 위치, 보내는 파일의 전체 경로를 적어 두세요. 이 다섯 가지 중 하나라도 틀리면 명령이 맞아도 연결이 실패합니다. 특히 서버의 공인 IP와 내부 IP를 혼동하지 않는지, 회사·집 네트워크에서 방화벽이 포트를 막지 않는지 먼저 확인해야 합니다.

처음에는 중요한 원본 대신 작은 텍스트 파일로 시험 전송하는 편이 안전합니다. 전송이 성공한 뒤 서버에서 파일 크기와 수정 시간을 확인하면 경로 실수나 동기화 착각을 초기에 잡을 수 있습니다. SCP는 복사 명령이므로 기본적으로 원본을 지우지 않지만, 같은 이름의 대상 파일은 덮어쓸 수 있습니다. 운영 서버라면 대상 경로를 홈 디렉터리나 임시 폴더로 시작하고, 확인 후 최종 위치로 옮기는 절차가 실수를 줄입니다.

윈도우에서 OpenSSH 준비 상태 확인

터미널에서 ssh -V를 입력해 버전 정보가 보이면 클라이언트가 준비된 것입니다. 명령을 찾을 수 없다는 메시지가 나오면 Windows 선택적 기능의 OpenSSH 클라이언트 설치 여부를 확인합니다. 설치 뒤에는 새 터미널을 열어야 경로가 반영되는 경우가 있습니다. PuTTY 계열 도구를 이미 쓰는 환경이라도, OpenSSH 형식 키와 포트 지정 방식을 혼동하지 않도록 한 가지 방식으로 통일하는 것이 좋습니다.

서버 쪽은 SSH 서비스가 실행 중이어야 합니다. 파일 전송 전에 ssh 사용자@서버주소로 로그인 테스트를 해 보세요. 로그인 자체가 안 되는데 SCP부터 반복하면 원인을 좁히기 어렵습니다. 처음 접속할 때는 호스트 키 확인 질문이 나올 수 있으며, 서버 지문을 관리자에게 확인한 뒤 승인해야 합니다. 낯선 지문을 무심코 승인하면 잘못된 서버나 중간자 공격을 구별하기 어려워집니다.

가장 기본적인 업로드 명령

내 PC의 파일을 서버로 보내는 기본 형식은 scp "로컬파일경로" 사용자@서버주소:/원격/경로 입니다. 예를 들어 scp "C:\work\report.pdf" user@203.0.113.10:/home/user/upload/ 처럼 씁니다. 윈도우 경로에 공백이 있으면 큰따옴표로 묶어야 합니다. 원격 경로 끝의 슬래시는 디렉터리라는 뜻을 분명히 하므로, 파일 이름까지 지정해 덮어쓰기를 의도한 것이 아니라면 붙이는 습관이 좋습니다.

비표준 포트를 쓰는 서버는 대문자 P 옵션을 사용합니다. 예시는 scp -P 2222 "C:\work\report.pdf" user@server:/home/user/upload/ 입니다. 포트가 22인데 -P를 넣을 필요는 없지만, 문서나 배치 파일에서는 실제 포트를 명시하면 인수인계가 쉬워집니다. 비밀번호를 명령줄에 적지 말고 프롬프트에서 입력하세요. 명령 기록과 화면 캡처에 비밀번호가 남는 일을 피할 수 있습니다.

서버 파일을 윈도우로 내려받는 법

방향만 바꾸면 다운로드가 됩니다. scp 사용자@서버주소:/home/user/log/app.log "C:\download\"처럼 원격 경로를 먼저 쓰고 로컬 폴더를 뒤에 둡니다. 경로에 와일드카드를 쓰거나 여러 파일을 받을 때는 서버 셸 해석과 윈도우 셸 해석이 달라질 수 있으므로 작은 범위로 먼저 테스트하세요. 날짜별 로그처럼 이름이 비슷한 파일은 별도 폴더를 만들면 기존 파일을 덮어쓸 위험이 줄어듭니다.

다운로드 후에는 파일이 있다는 사실만 보지 말고 크기와 해시를 확인합니다. 긴 전송이나 중요한 배포 파일은 서버와 로컬에서 SHA-256 값을 비교하면 전송 중 손상이나 잘못된 파일 선택을 확인할 수 있습니다. 텍스트 파일이라면 인코딩도 열어 보세요. SCP는 바이트를 그대로 옮기므로 한글이 깨진다면 전송 문제가 아니라 편집기 인코딩 설정일 가능성이 큽니다.

폴더 전체를 전송할 때의 절차

폴더를 보낼 때는 -r 옵션을 사용합니다. scp -r "C:\project\release" user@server:/home/user/deploy/ 형식입니다. 이때 대상 서버에 release 폴더가 어떻게 만들어지는지 사전에 이해해야 합니다. 원본 폴더 자체가 들어가는지, 그 안의 파일만 넣고 싶은지에 따라 로컬 경로와 대상 경로를 다르게 잡아야 합니다. 배포 폴더를 통째로 덮어쓰면 오래된 설정 파일이 남거나 필요한 파일이 사라지는 문제가 생길 수 있습니다.

대용량·반복 전송에는 SCP보다 rsync나 배포 도구가 더 적합할 때도 있습니다. SCP는 단순하고 빠르게 시작하기 좋지만, 중단 뒤 부분 재개나 변경 파일만 전송하는 기능은 제한적입니다. 따라서 일회성 자료 전달, 로그 수집, 작은 배포 산출물에는 SCP를 쓰고, 수백 MB 이상이거나 정기 동기화라면 전송 시간과 복구 방식까지 비교해 선택하세요.

개인키와 권한을 안전하게 다루기

키 파일을 쓸 때는 scp -i "C:\keys\server_ed25519" "C:\work\report.pdf" user@server:/home/user/upload/ 처럼 -i 뒤에 키 경로를 넣습니다. 개인키는 메신저나 공유 폴더에 올리지 말고 접근 권한이 제한된 위치에 보관해야 합니다. 키가 유출되었거나 노출이 의심되면 기존 공개키를 서버에서 제거하고 새 키 쌍을 발급하는 것이 안전합니다.

Permission denied 오류가 나면 비밀번호만 의심하지 말고 계정명, 키 파일, 서버의 authorized_keys, 대상 폴더 쓰기 권한을 차례대로 확인하세요. root 계정 직접 접속이 제한된 서버도 많으므로 일반 계정으로 업로드한 뒤 sudo 권한으로 이동하는 방식이 흔합니다. 권한을 해결하려고 chmod 777을 무조건 적용하는 것은 보안과 운영 모두에 좋지 않습니다. 필요한 사용자와 그룹에만 최소 권한을 주는 방식으로 원인을 해결하세요.

자주 만나는 오류와 해결 순서

Connection timed out은 주소·포트·방화벽·네트워크 경로를, Connection refused는 해당 포트의 SSH 서비스 상태를 먼저 봐야 합니다. No such file or directory는 로컬과 원격 경로를 따옴표까지 포함해 다시 확인합니다. 윈도우에서는 역슬래시와 공백, 리눅스에서는 대소문자와 슬래시가 흔한 원인입니다. 에러 메시지 전체를 보관하면 다음 점검이 훨씬 빨라집니다.

Host key verification failed는 서버 재설치나 IP 재사용 뒤에도 나타날 수 있지만, 보안 경고일 수 있으므로 곧바로 known_hosts를 지우지 마세요. 서버 관리자에게 새 지문을 확인한 뒤 기존 항목을 갱신합니다. 전송이 중간에 끊겼다면 대상 파일을 바로 신뢰하지 말고 크기·해시를 검증한 뒤 다시 보내세요. 실패한 명령을 무작정 여러 번 실행하는 것보다 연결, 인증, 경로, 권한 순서로 한 단계씩 확인하는 편이 빠릅니다.

시간과 비용을 줄이는 운영 팁

SCP 자체는 별도 사용료가 없지만 서버 트래픽, 클라우드 외부 전송 비용, 작업자 시간이 들어갈 수 있습니다. 대형 파일은 압축 전후 크기와 전송 시간을 비교하고, 사용량 과금이 있는 클라우드라면 리전 밖 전송 여부를 확인하세요. 업무 시간에 대용량 전송을 하면 회선이 느려질 수 있으므로 예약 시간과 속도 제한 정책도 팀과 합의하는 것이 좋습니다.

명령을 매번 손으로 고치기보다 전송 대상·서버 별칭·포트·키 위치를 짧은 작업 문서에 기록하면 실수가 줄어듭니다. 다만 비밀번호나 개인키 원문은 기록하지 않습니다. 팀에서 같은 서버를 쓴다면 목적별 업로드 폴더와 파일 이름 규칙을 정하고, 전송 뒤 확인 담당을 분명히 하세요. 작은 절차가 있어야 잘못된 서버에 올리거나 이전 버전을 배포하는 사고를 막을 수 있습니다.

SCP 전송 체크리스트와 FAQ

전송 전에는 서버 주소와 사용자, 포트, 원격 경로, 파일 이름, 덮어쓰기 여부를 확인합니다. 전송 후에는 서버에서 파일 존재·크기·권한을 확인하고, 중요한 파일이면 해시를 비교합니다. 원본은 검증이 끝날 때까지 지우지 않습니다. 이 순서는 1분 남짓 걸리지만 잘못된 배포를 되돌리는 시간보다 훨씬 짧습니다. 아래 명령 표와 체크리스트를 복사해 팀 문서에 맞게 조정해 두면 다음 작업이 편해집니다.

FAQ: SCP와 SFTP는 무엇이 다른가요? 둘 다 SSH 기반이지만 파일 탐색과 반복 작업에는 SFTP 도구가 편할 수 있습니다. 비밀번호 없이 가능한가요? 개인키 인증을 설정하면 가능합니다. 포트 옵션은 왜 대문자인가요? SCP의 포트 옵션은 -P이며 소문자 -p는 시간 정보 보존에 쓰입니다. 폴더는 어떻게 보내나요? -r을 사용합니다. 전송 속도가 느리면 무엇을 보나요? 회선, 서버 부하, 파일 수, 암호화 부담을 확인하고 대용량 반복 전송은 rsync도 비교하세요.

실무에서 경로를 읽는 법

로컬 경로와 원격 경로는 문법이 다릅니다. 윈도우의 C:\work\file.txt는 드라이브 문자와 역슬래시를 쓰지만, 리눅스의 /home/user/file.txt는 루트부터 시작하는 슬래시를 씁니다. 터미널에 붙여 넣기 전에는 파일 탐색기 주소와 서버의 pwd 결과를 각각 복사해 비교하세요. 홈 디렉터리를 뜻하는 물결표는 셸 환경에 따라 편리하지만 자동화 문서에서는 전체 경로가 더 명확합니다. 대상 폴더가 존재하는지 ls -ld로, 로컬 파일이 실제로 존재하는지 dir 또는 탐색기로 확인하면 오타 대부분을 막습니다.

파일 이름에 한글, 공백, 괄호가 있으면 큰따옴표가 사실상 필수입니다. 다만 따옴표 안에 서버 주소 전체를 넣으면 사용자와 경로를 구분하지 못하는 실수가 생길 수 있으니 로컬 파일 부분과 필요할 때의 원격 경로만 정확히 감싸세요. 리눅스는 Report.pdf와 report.pdf를 다른 파일로 봅니다. 윈도우에서 보기에 같은 이름처럼 느껴져도 서버에서는 별개일 수 있으므로, 배포 파일 이름은 영문 소문자·하이픈·날짜처럼 단순한 규칙으로 정하는 것이 안전합니다.

전송 전후 검증을 자동화하는 습관

수동 작업이라도 전송 전 파일 크기, 전송 시각, 대상 경로를 짧게 기록하면 문제가 생겼을 때 되짚기 쉽습니다. 서버에서 stat 명령으로 크기와 수정 시간을 확인하고, 필요하면 sha256sum으로 해시를 계산하세요. 윈도우에서는 Get-FileHash 같은 기능으로 같은 알고리즘을 선택해 비교할 수 있습니다. 해시는 파일 내용이 달라지면 값이 바뀌므로, 이름이 같아도 다른 버전을 보낸 사고를 잡는 데 유용합니다. 단, 해시 값 자체가 비밀은 아니어도 어떤 파일을 다루는지 드러낼 수 있으므로 공개 채널에는 업무 규정에 맞게 공유하세요.

배포 자동화 전에는 사람이 읽을 수 있는 로그부터 만드세요. 실행한 명령, 성공 여부, 오류 메시지, 서버에서 확인한 결과만 남겨도 다음 작업자가 같은 실수를 반복하지 않습니다. 비밀번호·토큰·개인키 경로처럼 민감한 정보는 로그에서 제외합니다. 오류가 났을 때는 전체 화면을 무분별하게 공유하기보다 에러 문구와 명령의 비밀 부분을 가린 사본을 남기는 편이 안전합니다. 반복 전송이 정착되면 SSH config의 Host 별칭을 이용해 주소와 포트를 줄일 수 있지만, 설정 파일 권한과 팀 공유 방식도 함께 관리해야 합니다.