이 글은 개인 서버, 클라우드 VPS, GitHub, 홈랩을 운영하는 초보자를 위해 SSH 키 관리의 기본 구조를 정리합니다. 목표는 단순합니다. 어떤 파일을 어디에 둬야 하고, 무엇을 절대 공유하면 안 되는지 이해하는 것입니다.

핵심 판단

• 개인키는 절대 서버나 타인에게 보내면 안 됩니다. 내 컴퓨터에만 있어야 합니다.
• 서버에는 공개키만 등록합니다. 보통 ~/.ssh/authorized_keys에 들어갑니다.
• 새로 키를 만든다면 일반적으로 Ed25519를 우선 검토하면 됩니다. OpenSSH의 ssh-keygen도 인자 없이 실행하면 Ed25519 키를 생성합니다.
• SSH 접속 문제의 상당수는 키 내용보다 파일 권한과 사용자명에서 발생합니다.

SSH 키는 왜 필요한가

SSH는 원격 서버에 안전하게 접속하기 위한 표준적인 방법입니다. 비밀번호로도 접속할 수 있지만, 인터넷에 노출된 서버에서는 비밀번호 로그인보다 공개키 인증을 쓰는 편이 훨씬 안전합니다.

공개키 인증은 한 쌍의 키를 사용합니다.

비유하면 공개키는 자물쇠, 개인키는 열쇠에 가깝습니다. 서버에 자물쇠를 등록해두고, 내 컴퓨터의 열쇠로 접속하는 구조입니다.

id_rsa와 id_ed25519의 차이

과거에는 id_rsa를 많이 사용했습니다. 지금도 RSA 키는 널리 쓰이고 호환성이 좋습니다. 하지만 새로 키를 만든다면 Ed25519를 우선 선택하는 경우가 많습니다.

OpenSSH 매뉴얼 기준으로 ssh-keygen은 인증 키를 생성·관리·변환하는 도구이며, 인자 없이 실행하면 Ed25519 키를 생성합니다. 새 개인 서버용 키는 다음처럼 만들 수 있습니다.

ssh-keygen -t ed25519 -C "my-server-key"

명령을 실행하면 개인키 파일과 공개키 파일이 함께 만들어집니다. 예를 들어 ~/.ssh/id_ed25519가 개인키이고, ~/.ssh/id_ed25519.pub가 공개키입니다.

authorized_keys는 무엇인가

authorized_keys는 서버 쪽 파일입니다. 이 파일에는 “이 서버 접속을 허용할 공개키 목록”이 들어갑니다.

~/.ssh/authorized_keys

내 컴퓨터의 id_ed25519.pub 내용을 서버의 authorized_keys에 넣으면, 서버는 해당 공개키와 짝이 맞는 개인키를 가진 클라이언트의 접속을 허용할 수 있습니다.

반대로 authorized_keys에 개인키를 넣으면 안 됩니다. -----BEGIN OPENSSH PRIVATE KEY----- 같은 문구가 보이면 개인키입니다. 이 값이 서버, 메신저, 노션, GitHub 공개 저장소에 올라갔다면 노출로 보고 즉시 교체해야 합니다.

known_hosts는 또 무엇인가

known_hosts는 서버가 아니라 보통 내 컴퓨터에 있는 파일입니다.

~/.ssh/known_hosts

이 파일은 “내가 전에 접속한 서버의 호스트 키”를 기억합니다. 처음 접속할 때 보이는 다음 질문은 서버의 신원을 로컬에 저장할지 묻는 과정입니다.

The authenticity of host 'example.com' can't be established.
Are you sure you want to continue connecting?

이후 같은 서버인데 호스트 키가 바뀌면 경고가 뜹니다. 서버를 재설치했거나 IP가 재사용된 경우일 수 있지만, 중간자 공격 가능성도 있기 때문에 무시하고 넘어가면 안 됩니다.

파일 권한은 왜 중요한가

SSH는 개인키가 너무 넓은 권한으로 열려 있으면 위험하다고 보고 사용을 거부할 수 있습니다. 초보자가 가장 많이 만나는 오류 중 하나가 이 부분입니다.

키를 여러 개 쓸 때는 SSH Config를 쓰자

서버가 하나일 때는 다음처럼 접속해도 됩니다.

ssh -i ~/.ssh/id_ed25519 ubuntu@203.0.113.10

하지만 서버가 늘어나면 ~/.ssh/config를 쓰는 편이 안전하고 편합니다.

Host oci-server
  HostName 203.0.113.10
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

이제 다음처럼 접속할 수 있습니다.

ssh oci-server

OpenSSH의 ssh_config는 명령줄 옵션, 사용자 설정 파일, 시스템 설정 파일 순서로 설정을 읽습니다. 여러 서버를 운영한다면 host별 설정을 앞쪽에 두고, 공통 기본값은 뒤쪽에 두는 방식이 관리하기 좋습니다.

GitHub 키와 서버 키는 분리하는 편이 좋다

초보자는 하나의 SSH 키를 GitHub, 개인 서버, 클라우드 콘솔에 모두 등록하기 쉽습니다. 가능은 하지만 운영 관점에서는 권장하기 어렵습니다. 한 키가 노출되면 연결된 모든 서비스의 접근 권한을 한 번에 회수해야 하기 때문입니다.

실무적으로는 용도별 키를 나누는 편이 안전합니다.

~/.ssh/config에 host별로 어떤 키를 쓸지 적어두면 실수도 줄어듭니다.

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
  IdentitiesOnly yes

Host oci-web
  HostName 203.0.113.10
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519_oci
  IdentitiesOnly yes

이렇게 분리해두면 GitHub 키를 바꿔도 서버 접속에는 영향이 없고, 서버 키가 노출되어도 GitHub 접근 권한은 유지됩니다.

키를 잃어버리거나 노출했을 때

OpenSSH 매뉴얼은 passphrase를 잃어버리면 복구할 방법이 없고 새 키를 만들어 공개키를 다시 배포해야 한다고 설명합니다. 개인키가 노출된 경우도 마찬가지입니다. 노출된 키를 계속 쓰면 안 됩니다.

1. 새 키를 생성합니다.
2. 서버의 authorized_keys에 새 공개키를 추가합니다.
3. 새 키로 접속되는지 확인합니다.
4. 기존 공개키를 authorized_keys, GitHub, 클라우드 콘솔에서 제거합니다.
5. 노출 경로가 Git 저장소라면 히스토리와 배포된 사본까지 확인합니다.

초보자 체크리스트

• 새 키는 가능하면 ssh-keygen -t ed25519로 만든다.
• 개인키 파일은 절대 공유하지 않는다.
• 서버에는 공개키만 authorized_keys에 넣는다.
• 개인키 권한은 chmod 600으로 제한한다.
• 여러 서버를 쓰면 ~/.ssh/config로 관리한다.
• GitHub, 운영 서버, 실험 서버 키는 가능하면 분리한다.
• 키가 노출되면 수정이 아니라 교체한다.

출처와 검증

• OpenBSD manual: ssh-keygen
• OpenBSD manual: ssh_config
• OpenBSD manual: sshd

이 글은 OpenSSH 매뉴얼을 기준으로 SSH 키 관리 개념을 초보자용 운영 가이드로 재구성한 ActualStack 편집본입니다.

이 글은 개인 서버, OCI/AWS/GCP/Azure VPS, 홈서버에서 SSH가 안 될 때 확인할 순서를 정리합니다. 핵심은 무작정 설정을 바꾸지 않고, 내 컴퓨터 → 네트워크 → 서버 → 인증 순서로 범위를 좁히는 것입니다.

핵심 판단

• Timeout은 보통 IP, 포트, 방화벽, 클라우드 보안그룹 문제입니다.
• Permission denied는 사용자명, 키 파일, 공개키 등록, 서버 인증 설정 문제일 가능성이 큽니다.
• Host key 경고는 서버 재설치일 수도 있지만 중간자 공격 가능성도 있어 원인을 확인해야 합니다.
• 가장 먼저 실행할 명령은 ssh -vvv입니다. 추측보다 로그가 빠릅니다.

1단계: 에러 메시지부터 구분하기

2단계: 접속 대상이 맞는지 확인

가장 단순하지만 가장 자주 틀리는 부분입니다.

• 서버 IP가 맞는가?
• 공인 IP와 사설 IP를 혼동하지 않았는가?
• SSH 포트가 22번이 맞는가?
• 클라우드 인스턴스가 running 상태인가?
• 접속해야 하는 사용자가 root, ubuntu, ec2-user, opc 중 무엇인가?

예를 들어 Ubuntu 이미지는 보통 ubuntu, Oracle Linux는 opc, Amazon Linux는 ec2-user를 사용합니다. 사용자명이 틀리면 키가 맞아도 접속이 실패합니다.

3단계: 포트가 열려 있는지 확인

Timeout이라면 인증보다 네트워크를 먼저 봐야 합니다.

nc -vz 서버_IP 22

또는 포트를 바꿨다면 해당 포트를 확인합니다.

nc -vz 서버_IP 2222

연결이 안 되면 다음을 확인합니다.

• 클라우드 Security Group / Security List / NSG 인바운드 규칙
• 서버 내부 UFW 또는 firewalld
• 공유기 포트포워딩
• 서버의 공인 IP 연결 여부
• 회사·학교 네트워크에서 22번 포트가 막혀 있는지

4단계: ssh -vvv로 인증 흐름 보기

OpenSSH 클라이언트는 -v 옵션으로 디버그 로그를 늘릴 수 있습니다. 문제 상황에서는 다음처럼 실행합니다.

ssh -vvv -i ~/.ssh/id_ed25519 ubuntu@서버_IP

여기서 봐야 할 포인트는 다음입니다.

• 내가 의도한 키 파일을 실제로 시도하는가?
• 서버가 publickey 인증을 허용하는가?
• 어느 단계에서 Offering public key 이후 거절되는가?
• 너무 많은 키를 시도하다가 Too many authentication failures가 나는가?

키가 여러 개라면 IdentitiesOnly yes를 ~/.ssh/config에 넣어 의도한 키만 쓰게 하는 것도 도움이 됩니다.

5단계: 키 파일과 권한 확인

Permission denied (publickey)가 뜬다면 키와 권한을 확인합니다.

ls -l ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

서버에 접근할 수 있는 다른 경로가 있다면 서버 쪽도 확인합니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

authorized_keys에는 공개키 한 줄이 들어가야 합니다. 개인키 전체를 붙여넣었거나 줄바꿈이 깨졌다면 인증이 실패합니다.

6단계: 서버의 sshd 상태 확인

Connection refused라면 서버에서 SSH 데몬이 실행 중인지 봐야 합니다. 콘솔, VNC, 클라우드 serial console 등으로 들어갈 수 있다면 다음을 확인합니다.

sudo systemctl status ssh
sudo systemctl status sshd

배포판에 따라 서비스명이 ssh 또는 sshd일 수 있습니다. 설정을 바꿨다면 재시작 전 문법 검사도 해야 합니다.

sudo sshd -t

OpenSSH의 sshd 매뉴얼은 -t를 설정 파일과 키의 sanity check 용도로 설명합니다. 원격 서버에서 SSH 설정을 바꿀 때는 기존 세션을 닫지 말고, 새 터미널로 접속 테스트를 먼저 하는 습관이 안전합니다.

7단계: 로그 확인

서버 쪽 로그는 원인을 좁히는 데 가장 확실합니다.

sudo journalctl -u ssh -n 100 --no-pager
sudo journalctl -u sshd -n 100 --no-pager

Ubuntu 계열에서는 다음 파일도 볼 수 있습니다.

sudo tail -n 100 /var/log/auth.log

로그에서 Authentication refused: bad ownership or modes가 보이면 권한 문제입니다. Invalid user가 보이면 사용자명이 틀린 것입니다.

8단계: known_hosts 경고 처리

서버를 재설치했거나 같은 IP에 다른 서버를 붙이면 호스트 키가 바뀔 수 있습니다. 이때 다음 경고가 나옵니다.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

정말 내가 서버를 재설치한 것이 맞다면 기존 호스트 키 기록을 제거할 수 있습니다.

ssh-keygen -R 서버_IP

하지만 이유 없이 갑자기 이 경고가 떴다면 무시하면 안 됩니다. DNS, IP, 네트워크 경로, 클라우드 콘솔의 인스턴스 정보를 먼저 확인해야 합니다.

빠른 진단 순서

1. ssh -vvv user@host로 실제 실패 지점을 본다.
2. Timeout이면 IP·포트·클라우드 보안규칙·방화벽을 본다.
3. Permission denied면 사용자명·개인키·authorized_keys·권한을 본다.
4. Connection refused면 sshd 실행 여부와 포트 설정을 본다.
5. Host key 경고는 서버 변경 여부를 확인한 뒤 처리한다.
6. 설정 변경 전에는 현재 SSH 세션을 닫지 않는다.

출처와 검증

• OpenBSD manual: ssh
• OpenBSD manual: sshd
• OpenBSD manual: ssh-keygen
• OpenBSD manual: ssh_config

이 글은 OpenSSH 매뉴얼과 일반적인 Linux 서버 운영 흐름을 기준으로 SSH 접속 문제를 빠르게 좁히는 ActualStack 트러블슈팅 가이드입니다.

이럴 때 검토할 만한 선택지가 Oracle Cloud Free Tier입니다. 오라클 클라우드는 가입 초기 체험용 크레딧과 별개로, 조건 안에서 계속 사용할 수 있는 Always Free 리소스를 제공합니다. 특히 Arm 기반 Ampere A1 Compute는 개인 서버 용도로 꽤 매력적인 구성입니다.

핵심 판단

• 무료 개인 서버가 목적이라면 OCI Free Tier는 가장 먼저 검토할 만합니다.
• Ampere A1 기준 Always Free 한도는 월 3,000 OCPU 시간과 18,000 GB 시간이며, Always Free 테넌시에서는 총 4 OCPU와 24GB 메모리에 해당합니다.
• 주의점은 홈 리전 선택, out of host capacity, ARM 호환성, 유휴 인스턴스 회수 가능성입니다.

Oracle Cloud Free Tier는 무엇인가

Oracle Cloud Free Tier는 크게 두 부분으로 나눠서 봐야 합니다.

개인 서버 운영 목적이라면 중요한 것은 Trial Credit이 아니라 Always Free 리소스입니다. Trial Credit은 다양한 서비스를 테스트하는 데 좋지만, 장기 운영 서버는 Always Free 범위 안에 들어와야 비용 리스크를 줄일 수 있습니다.

무료 서버 관점에서 중요한 리소스

OCI Always Free에서 개인 서버와 직접 관련 있는 항목은 Compute, Block Volume, Virtual Cloud Network입니다. 공식 문서 기준으로 Always Free 테넌시는 Compute 인스턴스를 홈 리전에 만들어야 하며, Ampere A1은 총량 기준으로 사용할 수 있습니다.

• Compute: AMD Micro 인스턴스 또는 Arm 기반 Ampere A1 인스턴스
• Block Volume: 부트 볼륨을 포함한 스토리지 구성에 사용
• VCN: 서브넷, 라우팅, 보안 목록 또는 NSG 설정
• Monitoring / Logging: 간단한 상태 확인과 운영 로그 확인

서버를 처음 만드는 입장에서는 Compute 스펙보다도 네트워크와 방화벽을 어디에서 열어야 하는지가 더 헷갈릴 수 있습니다. OCI는 클라우드 네트워크 보안 규칙과 OS 내부 방화벽을 따로 봐야 합니다.

Ampere A1을 고르는 이유

Ampere A1은 Arm 기반이기 때문에 x86 서버와 완전히 같지는 않습니다. 하지만 개인 서버 용도에서는 장점이 큽니다.

• 웹서버, API 서버, 봇, 모니터링 서버를 가볍게 운영하기 좋음
• Docker Compose 기반 개인 서비스 운영에 적합
• 학습용 Linux 서버와 홈랩 대체 용도로 활용 가능
• Always Free 한도 안에서 CPU와 메모리를 유연하게 나눌 수 있음

다만 일부 Docker 이미지나 바이너리는 Arm64를 지원하지 않을 수 있습니다. 배포하려는 서비스가 있다면 Docker Hub에서 linux/arm64 이미지를 지원하는지 먼저 확인하는 편이 안전합니다.

인스턴스 생성 흐름

1. Oracle Cloud 계정을 생성합니다.
2. 홈 리전을 신중하게 선택합니다. Always Free Compute는 홈 리전 조건을 받습니다.
3. Compute Instance 생성 화면으로 이동합니다.
4. Ubuntu 이미지를 선택합니다.
5. Shape에서 Ampere A1 또는 Always Free 대상 Shape를 선택합니다.
6. SSH 공개키를 등록합니다.
7. 공인 IP 주소를 확인합니다.
8. 터미널에서 SSH로 접속합니다.

ssh ubuntu@서버_IP

처음에는 서버 생성보다 SSH 키 관리가 더 중요합니다. 개인키를 잃어버리면 접속 복구가 번거롭기 때문에, 생성한 키는 안전한 위치에 보관해야 합니다.

처음 만들 때 자주 막히는 지점

생성 직후 30분 점검 루틴

인스턴스를 만들었다면 바로 서비스를 올리기보다, 무료 한도와 접속 경로를 먼저 확인하는 편이 좋습니다. 이 단계에서 꼬이면 이후 Nginx, Docker, 봇 배포까지 모두 같은 문제를 반복하게 됩니다.

1. 인스턴스 Shape가 Always Free 대상인지 확인합니다.
2. 부트 볼륨 크기와 추가 Block Volume이 무료 범위를 벗어나지 않는지 확인합니다.
3. 공인 IP가 붙어 있는지 확인합니다.
4. SSH 접속 사용자명이 이미지에 맞는지 확인합니다. Ubuntu는 보통 ubuntu, Oracle Linux는 opc입니다.
5. Security List 또는 NSG에서 22번 포트 접근 범위를 확인합니다.
6. 서버 안에서 uname -m을 실행해 Arm64 환경인지 확인합니다.

uname -m
df -h
free -h
ip addr show

aarch64가 보이면 Ampere A1 같은 Arm 서버입니다. 이 경우 Docker 이미지를 고를 때 linux/arm64 지원 여부를 함께 봐야 합니다.

무료로 유지하려면 매달 봐야 할 것

Always Free라고 해도 운영자가 아무것도 안 봐도 된다는 뜻은 아닙니다. 비용 리스크를 줄이려면 콘솔에서 다음 항목을 주기적으로 확인하는 편이 안전합니다.

• Billing 또는 Cost Analysis에서 예상 비용이 0에 가까운지 확인
• 사용하지 않는 Block Volume, 백업, 로드밸런서, 예약 공인 IP가 없는지 확인
• 인스턴스가 실제로 쓰이는 서비스인지, 유휴 상태로 방치된 것은 아닌지 확인
• OS 업데이트와 재부팅 필요 여부 확인
• SSH 실패 로그와 방화벽 차단 로그 확인

개인 서버는 “만들기”보다 “계속 무료로 안전하게 유지하기”가 더 중요합니다. 특히 초보자는 Trial Credit으로 만든 리소스와 Always Free 리소스를 섞지 않는 것이 좋습니다.

누구에게 추천할까

OCI Free Tier는 다음에 해당하는 사람에게 잘 맞습니다.

• 무료 VPS가 필요한 개인 개발자
• Linux, Docker, Nginx, SSH를 실습하고 싶은 학생
• 개인 자동화 서버나 봇을 24시간 운영하고 싶은 사용자
• 홈서버를 들이기 전 클라우드 홈랩을 가볍게 경험해보고 싶은 사람

반대로 x86 전용 프로그램을 반드시 써야 하거나, 리전 재고 문제를 기다리기 싫거나, 기업 실무와 같은 AWS 중심 생태계 학습이 목적이라면 다른 선택지도 함께 보는 편이 좋습니다.

마무리

Oracle Cloud Free Tier는 개인 개발자에게 꽤 강력한 무료 서버 선택지입니다. 특히 Ampere A1 Always Free 한도를 이해하고, 홈 리전과 네트워크 설정만 조심하면 블로그, API, 봇, Docker 서버까지 비용 부담 없이 시작할 수 있습니다.

다음 단계는 이 서버에 Nginx를 설치하고 실제 웹서버로 운영해보는 것입니다. 서버를 만드는 것에서 끝내지 말고, 외부 접속·도메인·HTTPS까지 연결해보면 클라우드 운영 감각을 훨씬 빠르게 익힐 수 있습니다.

공식 참고자료

• Oracle Cloud Free Tier
• Oracle Cloud Infrastructure Free Tier
• Always Free Resources
• Oracle Cloud Free Tier FAQ

이 글에서는 OCI Free Tier 인스턴스에 Nginx 웹서버를 설치하고 외부에서 접속 가능하게 만드는 과정을 정리합니다. 단순 설치 명령어만 나열하기보다, OCI에서 자주 막히는 네트워크 보안 설정까지 함께 다룹니다.

핵심 판단

• Nginx 설치 자체는 쉽지만, OCI 보안 목록 또는 NSG 설정을 놓치면 외부 접속이 되지 않습니다.
• HTTP는 80번, HTTPS는 443번 포트를 OS 방화벽과 OCI 네트워크 양쪽에서 확인해야 합니다.
• 도메인과 HTTPS까지 연결해야 “진짜 운영 가능한 웹서버”에 가까워집니다.

준비물

• Oracle Cloud Free Tier 계정
• 생성된 Ubuntu Compute 인스턴스
• SSH 접속 가능한 개인키
• 선택 사항: 개인 도메인

아직 인스턴스를 만들지 않았다면 먼저 Always Free 대상 Shape인지 확인해야 합니다. Ampere A1을 사용할 경우 Arm64 환경이므로, 이후 Docker까지 고려한다면 Arm64 이미지 지원 여부도 함께 보는 편이 좋습니다.

1. 서버 접속하기

먼저 SSH로 서버에 접속합니다.

ssh ubuntu@서버_IP

접속 후 패키지 목록을 업데이트합니다.

sudo apt update
sudo apt upgrade -y

운영 서버라면 업데이트 후 재부팅이 필요한지 확인하는 습관도 좋습니다.

test -f /var/run/reboot-required && cat /var/run/reboot-required

2. Nginx 설치하기

Ubuntu에서는 다음 명령어로 Nginx를 설치할 수 있습니다.

sudo apt install nginx -y

설치 후 서비스 상태를 확인합니다.

sudo systemctl status nginx

active (running) 상태가 보이면 서버 내부에서는 Nginx가 정상 실행 중입니다. 하지만 이 단계만으로 외부 접속이 되는 것은 아닙니다.

3. OS 방화벽 확인하기

Ubuntu에서 UFW를 사용하는 경우 HTTP, HTTPS, SSH를 허용합니다.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

주의할 점은 sudo ufw enable을 실행하기 전에 반드시 SSH 허용 규칙을 먼저 넣어야 한다는 것입니다. 그렇지 않으면 현재 SSH 세션은 유지되더라도 이후 접속이 막힐 수 있습니다.

4. OCI 보안 목록 또는 NSG 열기

OCI에서는 OS 내부 방화벽과 별개로 클라우드 네트워크 보안 규칙이 있습니다. 인스턴스가 속한 VCN의 Security List 또는 Network Security Group에서 인바운드 규칙을 추가해야 합니다.

웹서버는 누구나 접속해야 하므로 80/443은 일반적으로 0.0.0.0/0으로 열 수 있습니다. 반면 SSH 22번 포트는 가능하다면 본인 IP로 제한하는 것이 안전합니다.

5. 브라우저에서 확인하기

이제 브라우저에서 서버 공인 IP로 접속합니다.

http://서버_IP

Nginx 기본 페이지가 보이면 성공입니다. 접속이 안 된다면 다음 순서로 확인합니다.

1. Nginx 서비스가 실행 중인지 확인
2. Ubuntu 방화벽에서 80번 포트가 열려 있는지 확인
3. OCI Security List 또는 NSG에 80번 포트 인바운드 규칙이 있는지 확인
4. 인스턴스에 공인 IP가 연결되어 있는지 확인

접속 실패를 줄이는 진단 명령

웹서버가 안 열릴 때는 설정을 한꺼번에 바꾸기보다, 어느 구간에서 막히는지 분리해서 봐야 합니다. 서버 안에서는 Nginx와 로컬 포트를 먼저 확인합니다.

sudo systemctl status nginx --no-pager
sudo ss -lntp | grep ':80'
curl -I http://127.0.0.1

서버 내부에서는 응답하는데 외부 브라우저에서 안 열린다면 OS 방화벽이나 OCI 네트워크 규칙 쪽을 봅니다.

sudo ufw status verbose
curl -I http://서버_공인_IP

도메인 연결 후에는 DNS가 실제 공인 IP를 가리키는지도 확인합니다.

dig example.com +short
dig www.example.com +short

이 세 단계에서 어디까지 성공하는지 보면 문제 범위가 좁아집니다. 127.0.0.1은 성공하고 공인 IP가 실패하면 클라우드 보안 규칙 가능성이 크고, 공인 IP는 성공하지만 도메인이 실패하면 DNS 문제일 가능성이 큽니다.

6. 간단한 HTML 페이지 올리기

Nginx 기본 웹 루트는 보통 다음 경로입니다.

/var/www/html

기본 페이지를 간단히 바꿔봅니다.

sudo tee /var/www/html/index.html > /dev/null <<'HTML'
<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8" />
  <title>My OCI Web Server</title>
</head>
<body>
  <h1>Hello, Oracle Cloud!</h1>
  <p>This page is running on OCI Free Tier.</p>
</body>
</html>
HTML

브라우저를 새로고침했을 때 문구가 바뀌면 정적 웹페이지 배포까지 성공한 것입니다.

7. 도메인 연결하기

도메인이 있다면 DNS에서 A 레코드를 추가합니다.

DNS 반영에는 몇 분에서 몇 시간이 걸릴 수 있습니다. 반영 여부는 다음 명령어로 확인할 수 있습니다.

dig example.com +short

8. HTTPS 적용하기

도메인 연결이 끝났다면 Let’s Encrypt 인증서를 사용할 수 있습니다.

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx

안내에 따라 도메인을 선택하면 Nginx 설정에 HTTPS가 자동으로 추가됩니다. 인증서 자동 갱신은 보통 systemd timer로 등록되지만, 다음 명령어로 테스트해볼 수 있습니다.

sudo certbot renew --dry-run

작은 사이트 운영 구조 예시

처음에는 모든 파일을 /var/www/html에 바로 두어도 되지만, 글이나 프로젝트가 늘어나면 사이트별 디렉터리를 나누는 편이 좋습니다.

sudo mkdir -p /var/www/example.com/public
sudo chown -R "$USER":www-data /var/www/example.com
sudo chmod -R 755 /var/www/example.com

Nginx 서버 블록은 별도 파일로 관리합니다.

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

이 구조를 쓰면 나중에 API 서버, 정적 사이트, 블로그를 같은 인스턴스 안에서 분리해 운영하기가 쉬워집니다.

운영 전 보안 체크리스트

• SSH 키 로그인 사용
• root SSH 로그인 차단
• SSH 22번 포트 접근 IP 제한
• 정기 업데이트 적용
• 불필요한 포트 닫기
• Nginx access/error 로그 확인
• Always Free 한도와 유휴 인스턴스 조건 확인
• 백업이 필요한 데이터는 별도 볼륨 또는 외부 저장소에 보관

다음 단계

정적 HTML 페이지가 정상적으로 뜬다면 다음으로 확장할 수 있습니다.

• Nginx reverse proxy로 Node.js, FastAPI, Spring Boot 연결
• Docker Compose로 여러 개인 서비스 운영
• Cloudflare DNS와 프록시 연결
• Uptime 모니터링과 로그 알림 구성
• GitHub Actions 또는 간단한 rsync 배포 자동화

마무리

OCI Free Tier와 Nginx를 조합하면 비용 부담 없이 개인 웹서버를 운영할 수 있습니다. 중요한 것은 Nginx 설치보다 네트워크 경로 전체를 이해하는 것입니다. 브라우저에서 접속하려면 Nginx, OS 방화벽, OCI 보안 규칙, 공인 IP, DNS가 모두 맞아야 합니다.

이 흐름을 한 번 익혀두면 이후 API 서버, 블로그, 봇 대시보드, 개인 자동화 페이지까지 같은 구조로 확장할 수 있습니다.

공식 참고자료

• Oracle Cloud Free Tier
• OCI Always Free Resources
• Ubuntu Server documentation: Install Nginx
• Certbot

알림은 시스템이 말하는 방식입니다. 모든 상태 변화를 보내면 중요한 실패가 묻히고, 결국 사용자는 알림을 무시하게 됩니다.

이 글은 알림을 더 많이 보내는 방법이 아니라, 실제로 대응할 수 있는 신호만 남기는 기준을 정리합니다. 개인 서버나 자동화 워크플로우에서는 실패, 지연, 비용 증가처럼 다음 행동이 있는 이벤트만 분리해야 오래 유지할 수 있습니다.

먼저 볼 신호

• 즉시 대응이 필요한 실패인지
• 이전 상태와 달라졌는지
• 하루 요약으로 충분한지
• 반복 알림을 억제할 기준이 있는지

왜 이 기준이 필요한가

도구 업데이트는 대부분 좋아 보이는 표현으로 공개됩니다. 하지만 실제 사용자는 기능 이름보다 적용 범위, 가격, 제한, 기존 도구와의 중복을 먼저 봐야 합니다. 이 과정을 건너뛰면 필요 없는 구독이 늘어나거나, 팀/연구 자료를 옮긴 뒤 다시 되돌리기 어려워질 수 있습니다.

특히 AI 제품과 생산성 도구는 짧은 데모만 보고 판단하기 쉽습니다. 그래서 글을 읽을 때는 “좋아 보인다”가 아니라 “내가 매주 반복하는 작업 하나를 줄일 수 있는가”를 기준으로 보는 편이 좋습니다.

적용 체크표

작업 흐름

1. 긴급 실패는 즉시 보냅니다.
2. 일반 상태 변화는 정각에 모읍니다.
3. 변화가 없으면 침묵합니다.
4. 하루 한 번은 전체 요약을 보냅니다.

처음부터 모든 자료와 작업을 옮기지 않는 것이 좋습니다. 새 도구나 운영 방식은 작은 작업 하나에만 붙여보고, 하루나 일주일 단위로 결과를 확인해야 합니다. 결과를 볼 때는 만족감보다 수정 횟수, 실패 횟수, 다시 찾는 시간, 비용 변화를 기록하는 편이 더 정확합니다.

선택 기준

좋은 자동화는 많이 말하지 않습니다. 필요한 순간에만 정확히 말하고, 나머지는 대시보드에서 확인하게 두는 편이 오래 갑니다.

• 바로 써볼 만한 경우: 즉시 대응이 필요한 실패인지 항목이 명확하고, 긴급 실패는 즉시 보냅니다. 단계를 부담 없이 실행할 수 있을 때
• 기다리는 편이 나은 경우: 가격, 권한, 데이터 보존, 내보내기 조건이 불명확하거나 현재 도구와 큰 차이가 없을 때
• 기록해둘 것: 테스트 날짜, 사용한 플랜, 실패한 조건, 다시 확인할 링크를 남겨야 나중에 같은 판단을 반복하지 않습니다.

예시 상황

예를 들어 개인 프로젝트나 연구 작업에서 새 도구를 도입한다고 가정하면, 먼저 작은 입력 하나로 결과를 확인하고 기존 방식과 비교해야 합니다. 결과가 비슷한데 설정이나 비용이 더 복잡하다면 당장 이동할 이유가 없습니다. 반대로 반복 작업 시간이 줄고 결과를 다시 검증하기 쉬워진다면 제한적으로 도입할 수 있습니다.

이때 중요한 것은 “좋은 기능”을 찾는 것이 아니라 “내가 계속 쓰게 될 흐름”을 찾는 것입니다. 기능은 많지만 매번 열어보지 않는 도구보다, 기능은 적어도 매일 쓰는 과정에 자연스럽게 들어오는 도구가 실제 가치가 큽니다.

주의할 점

처음에는 알림이 부족한 듯 보여도 운영하면서 임계값을 조정하는 편이 낫습니다. 과한 알림은 되돌리기 어렵습니다.

자주 묻는 질문

지금 바로 바꿔야 하나?

대부분은 바로 바꾸기보다 테스트 범위를 작게 잡는 편이 좋습니다. 계정, 데이터, 비용이 얽힌 도구일수록 한 번에 옮기면 되돌리기 어렵습니다.

무료 플랜이면 그냥 써도 되나?

무료 플랜도 제한, 데이터 사용 조건, 내보내기 가능 여부를 확인해야 합니다. 특히 나중에 유료 전환이 필요한 구조라면 처음부터 월 비용을 계산해두는 것이 좋습니다.

기존 도구와 겹치면 어떻게 하나?

겹치는 기능이 많다면 역할을 나눠야 합니다. 하나는 기록용, 하나는 실행용처럼 경계를 정하지 않으면 자료가 흩어지고 검색 비용이 늘어납니다.

마무리

좋은 도구 선택은 최신 기능을 모두 따라가는 일이 아닙니다. 실제 작업을 줄이고, 결과를 확인하기 쉽고, 비용과 권한을 예측할 수 있을 때만 도입 가치가 있습니다. 이 글의 체크표를 기준으로 하나씩 확인하면 불필요한 전환을 줄이고 필요한 변화만 가져갈 수 있습니다.

서버 용량이 제한되어 있다면 논문 본문을 저장하지 않는 편이 낫습니다. 중요한 것은 파일 자체보다 왜 읽어야 하는지와 어떤 프로젝트에 연결되는지입니다.

이 글은 논문 관리 도구를 크게 늘리기보다 링크, DOI, 읽는 목적을 가볍게 남기는 방식에 초점을 둡니다. 모든 PDF를 저장하기 전에 왜 읽는지와 어떤 프로젝트에 연결되는지를 먼저 남기면 큐가 오래 유지됩니다.

먼저 볼 신호

• URL과 DOI
• 읽는 목적
• 프로젝트 연결
• 우선순위와 읽음 상태

왜 이 기준이 필요한가

도구 업데이트는 대부분 좋아 보이는 표현으로 공개됩니다. 하지만 실제 사용자는 기능 이름보다 적용 범위, 가격, 제한, 기존 도구와의 중복을 먼저 봐야 합니다. 이 과정을 건너뛰면 필요 없는 구독이 늘어나거나, 팀/연구 자료를 옮긴 뒤 다시 되돌리기 어려워질 수 있습니다.

특히 AI 제품과 생산성 도구는 짧은 데모만 보고 판단하기 쉽습니다. 그래서 글을 읽을 때는 “좋아 보인다”가 아니라 “내가 매주 반복하는 작업 하나를 줄일 수 있는가”를 기준으로 보는 편이 좋습니다.

적용 체크표

작업 흐름

1. 링크를 저장할 때 한 줄 메모를 붙입니다.
2. 태그는 연구주제, 방법론, 참고자료 정도로 제한합니다.
3. 읽은 뒤에는 요약보다 적용 가능성을 남깁니다.
4. 본문은 필요할 때 원문에서 다시 엽니다.

처음부터 모든 자료와 작업을 옮기지 않는 것이 좋습니다. 새 도구나 운영 방식은 작은 작업 하나에만 붙여보고, 하루나 일주일 단위로 결과를 확인해야 합니다. 결과를 볼 때는 만족감보다 수정 횟수, 실패 횟수, 다시 찾는 시간, 비용 변화를 기록하는 편이 더 정확합니다.

선택 기준

가벼운 큐는 유지 비용이 낮고 모바일 입력이 쉽습니다. 장기 보관과 인용이 필요한 논문만 Zotero로 승격시키면 됩니다.

• 바로 써볼 만한 경우: URL과 DOI 항목이 명확하고, 링크를 저장할 때 한 줄 메모를 붙입니다. 단계를 부담 없이 실행할 수 있을 때
• 기다리는 편이 나은 경우: 가격, 권한, 데이터 보존, 내보내기 조건이 불명확하거나 현재 도구와 큰 차이가 없을 때
• 기록해둘 것: 테스트 날짜, 사용한 플랜, 실패한 조건, 다시 확인할 링크를 남겨야 나중에 같은 판단을 반복하지 않습니다.

예시 상황

예를 들어 개인 프로젝트나 연구 작업에서 새 도구를 도입한다고 가정하면, 먼저 작은 입력 하나로 결과를 확인하고 기존 방식과 비교해야 합니다. 결과가 비슷한데 설정이나 비용이 더 복잡하다면 당장 이동할 이유가 없습니다. 반대로 반복 작업 시간이 줄고 결과를 다시 검증하기 쉬워진다면 제한적으로 도입할 수 있습니다.

이때 중요한 것은 “좋은 기능”을 찾는 것이 아니라 “내가 계속 쓰게 될 흐름”을 찾는 것입니다. 기능은 많지만 매번 열어보지 않는 도구보다, 기능은 적어도 매일 쓰는 과정에 자연스럽게 들어오는 도구가 실제 가치가 큽니다.

주의할 점

읽을거리 큐가 커지면 안 읽은 목록이 됩니다. 매일 추가보다 매주 정리가 더 중요합니다.

자주 묻는 질문

지금 바로 바꿔야 하나?

대부분은 바로 바꾸기보다 테스트 범위를 작게 잡는 편이 좋습니다. 계정, 데이터, 비용이 얽힌 도구일수록 한 번에 옮기면 되돌리기 어렵습니다.

무료 플랜이면 그냥 써도 되나?

무료 플랜도 제한, 데이터 사용 조건, 내보내기 가능 여부를 확인해야 합니다. 특히 나중에 유료 전환이 필요한 구조라면 처음부터 월 비용을 계산해두는 것이 좋습니다.

기존 도구와 겹치면 어떻게 하나?

겹치는 기능이 많다면 역할을 나눠야 합니다. 하나는 기록용, 하나는 실행용처럼 경계를 정하지 않으면 자료가 흩어지고 검색 비용이 늘어납니다.

마무리

좋은 도구 선택은 최신 기능을 모두 따라가는 일이 아닙니다. 실제 작업을 줄이고, 결과를 확인하기 쉽고, 비용과 권한을 예측할 수 있을 때만 도입 가치가 있습니다. 이 글의 체크표를 기준으로 하나씩 확인하면 불필요한 전환을 줄이고 필요한 변화만 가져갈 수 있습니다.

공개 IP를 가진 서버는 거의 바로 스캔됩니다. 실패 로그가 많다고 모두 침해는 아니지만, 반복 시도는 자동 차단과 요약 알림이 필요합니다.

이 글은 공개 서버에서 반복되는 SSH 로그인 시도를 과장하지 않고, 실제 방어에 필요한 설정과 확인 순서를 정리합니다. fail2ban은 만능 보안 도구가 아니라 비밀번호 로그인 차단, 키 관리, 로그 확인과 함께 써야 의미가 있습니다.

먼저 볼 신호

• 비밀번호 로그인 비활성화
• 키 파일 권한과 사용자 제한
• fail2ban jail 상태
• Oracle Cloud 보안 목록과 UFW 규칙

왜 이 기준이 필요한가

도구 업데이트는 대부분 좋아 보이는 표현으로 공개됩니다. 하지만 실제 사용자는 기능 이름보다 적용 범위, 가격, 제한, 기존 도구와의 중복을 먼저 봐야 합니다. 이 과정을 건너뛰면 필요 없는 구독이 늘어나거나, 팀/연구 자료를 옮긴 뒤 다시 되돌리기 어려워질 수 있습니다.

특히 AI 제품과 생산성 도구는 짧은 데모만 보고 판단하기 쉽습니다. 그래서 글을 읽을 때는 “좋아 보인다”가 아니라 “내가 매주 반복하는 작업 하나를 줄일 수 있는가”를 기준으로 보는 편이 좋습니다.

적용 체크표

작업 흐름

1. sshd 설정에서 PasswordAuthentication을 확인합니다.
2. fail2ban status로 현재 ban과 누적 ban을 봅니다.
3. auth.log에서 반복 IP를 확인합니다.
4. 알림은 변화가 있을 때만 보내도록 조정합니다.

처음부터 모든 자료와 작업을 옮기지 않는 것이 좋습니다. 새 도구나 운영 방식은 작은 작업 하나에만 붙여보고, 하루나 일주일 단위로 결과를 확인해야 합니다. 결과를 볼 때는 만족감보다 수정 횟수, 실패 횟수, 다시 찾는 시간, 비용 변화를 기록하는 편이 더 정확합니다.

선택 기준

키 인증과 fail2ban이 정상이라면 일반 스캔은 대부분 차단됩니다. 다만 새 국가·대역에서 급증하거나 실패 카운터가 계속 올라가면 정책을 강화해야 합니다.

• 바로 써볼 만한 경우: 비밀번호 로그인 비활성화 항목이 명확하고, sshd 설정에서 PasswordAuthentication을 확인합니다. 단계를 부담 없이 실행할 수 있을 때
• 기다리는 편이 나은 경우: 가격, 권한, 데이터 보존, 내보내기 조건이 불명확하거나 현재 도구와 큰 차이가 없을 때
• 기록해둘 것: 테스트 날짜, 사용한 플랜, 실패한 조건, 다시 확인할 링크를 남겨야 나중에 같은 판단을 반복하지 않습니다.

예시 상황

예를 들어 개인 프로젝트나 연구 작업에서 새 도구를 도입한다고 가정하면, 먼저 작은 입력 하나로 결과를 확인하고 기존 방식과 비교해야 합니다. 결과가 비슷한데 설정이나 비용이 더 복잡하다면 당장 이동할 이유가 없습니다. 반대로 반복 작업 시간이 줄고 결과를 다시 검증하기 쉬워진다면 제한적으로 도입할 수 있습니다.

이때 중요한 것은 “좋은 기능”을 찾는 것이 아니라 “내가 계속 쓰게 될 흐름”을 찾는 것입니다. 기능은 많지만 매번 열어보지 않는 도구보다, 기능은 적어도 매일 쓰는 과정에 자연스럽게 들어오는 도구가 실제 가치가 큽니다.

주의할 점

무작정 포트를 닫거나 IP를 넓게 차단하면 본인 접속도 막힐 수 있습니다. 방화벽 변경 전 접속 경로를 하나 더 확보하는 것이 안전합니다.

자주 묻는 질문

지금 바로 바꿔야 하나?

대부분은 바로 바꾸기보다 테스트 범위를 작게 잡는 편이 좋습니다. 계정, 데이터, 비용이 얽힌 도구일수록 한 번에 옮기면 되돌리기 어렵습니다.

무료 플랜이면 그냥 써도 되나?

무료 플랜도 제한, 데이터 사용 조건, 내보내기 가능 여부를 확인해야 합니다. 특히 나중에 유료 전환이 필요한 구조라면 처음부터 월 비용을 계산해두는 것이 좋습니다.

기존 도구와 겹치면 어떻게 하나?

겹치는 기능이 많다면 역할을 나눠야 합니다. 하나는 기록용, 하나는 실행용처럼 경계를 정하지 않으면 자료가 흩어지고 검색 비용이 늘어납니다.

마무리

좋은 도구 선택은 최신 기능을 모두 따라가는 일이 아닙니다. 실제 작업을 줄이고, 결과를 확인하기 쉽고, 비용과 권한을 예측할 수 있을 때만 도입 가치가 있습니다. 이 글의 체크표를 기준으로 하나씩 확인하면 불필요한 전환을 줄이고 필요한 변화만 가져갈 수 있습니다.