몇 년째 서버를 만지면서도 Lightsail 인스턴스 생성 화면만 열면 늘 막막했다. Linux 앱 아래 18개, Linux 운영 체제 아래 11개, 도합 30여 개의 선택지 — 뭐가 뭔지도 모르고, 뭘 고르면 안 되는지도 감이 안 잡힌 채로 그냥 “다들 쓰는 것 같은” WordPress나 Node.js를 눌러왔다. 오늘 Cloudflare 보안 설정을 손보다가 곁가지로 시작된 대화가 결국 이 오래된 궁금증까지 풀어줬다. 초보자 입장에서 이해한 순서 그대로 정리해본다.

1도메인 보안 설정 손보기 — Cloudflare Security Insights

시작은 Cloudflare 대시보드의 Security Insights였다. 도메인의 IT 인프라를 자동 스캔해서 보안 개선 여지가 있는 항목을 알려주는 기능인데, 심각도는 대체로 Moderate/Low 수준의 “설정 권장사항”들이었다.

DNSSEC, 한마디로 “디지털 부절(符節)”

DNSSEC(DNS Security Extensions)의 구조는 옛날 병력 동원용 신표였던 부절과 정확히 닮았다. 두 조각이 딱 맞아야 진짜로 인정되는 방식.

개인 블로그 규모에서 DNSSEC의 메리트는 “필수”라기보다 거의 공짜인 보험에 가깝다. 공용 와이파이 사용자를 DNS 스푸핑으로부터 보호하는 정도의 실질 효과가 있고, 속도 영향은 체감이 안 될 만큼 미미하다(DNS 응답 캐싱 덕분).

2Lightsail 인스턴스 생성, 그 많은 선택지의 정체

본론이다. Lightsail에서 인스턴스를 새로 만들 때 “플랫폼”을 먼저 고르고, 그 아래 “블루프린트”를 고르게 되어 있다. 이 두 단계, 두 축만 분리해서 보면 나머지는 전부 그 조합의 변주다.

블루프린트란: “미리 갖춰진 기 메이드 상태”

블루프린트가 없다면, 워드프레스 하나 돌리려 해도 DB(MySQL) 설치 → Apache/Nginx 설치 → PHP 설치 → 서로 연결 → 워드프레스 소스 설치까지 전부 손으로 해야 한다. 블루프린트는 이 과정을 미리 조립해둔 “완제품 상태에서 출발”하게 해주는 것 — 이름처럼 Lightsail(가벼운 돛단배)은 이미 어느 정도 갖춰진 배를 타고 출항하는 셈이다.

2-1. Linux 앱 — 완제품 블루프린트 18종

2-2. Linux 운영 체제 — 순수 배포판 11종

여기는 앱이 하나도 안 깔린, 완전히 빈 OS 상태에서 출발하는 옵션들이다. 목록에 있는 것들은 사실 두 종류가 섞여 있다.

3cPanel — hosting.kr 시절 그 편리했던 화면의 정체

hosting.kr 웹호스팅에서 워드프레스를 편하게 관리했던 그 GUI가 바로 cPanel & WHM이다. Lightsail에서도 “Linux 운영 체제 → AlmaLinux 계열” 안에 cPanel & WHM for AlmaLinux 블루프린트로 존재한다.

결론적으로 — 이미 SSH·Git 워크플로우에 익숙해진 지금 시점에서는, cPanel의 “명령어 몰라도 된다”는 장점의 체감 가치가 예전보다 줄었다. 여러 워드프레스를 GUI로 통합 관리하고 싶거나 이메일 서버까지 자체 운영하려는 니즈가 강할 때만 가치가 있는 선택지.

4Lightsail vs EC2 — 결국 어디까지 가야 하나

Lightsail은 사실 EC2를 쉽게 쓸 수 있도록 단순화해서 포장한 서비스다. 내부적으로는 같은 AWS 인프라(EC2 기반)를 쓰지만, 복잡한 설정을 다 숨기고 “블루프린트 고르고 클릭 몇 번”으로 끝나게 만든 것.

지금 규모(워드프레스 몇 개 + 새솔CRM)에서는 EC2로 넘어가는 게 발전이 아니라 오히려 불필요한 복잡성을 떠안는 것에 가깝다. taxwork.kr을 여러 세무사무실에 서비스하는 SaaS로 확장해 동시접속자·트래픽이 실제로 늘어나는 시점이야말로 EC2를 고민할 진짜 신호다.

5인스턴스 다음 단계 — 컨테이너와 관리형 데이터베이스

Lightsail 좌측 메뉴에는 인스턴스 외에도 컨테이너, 데이터베이스 메뉴가 있다. 지금 당장 쓸 일은 없지만, 뭔지 알아두면 나중에 판단이 쉬워진다.

6그런데 Windows Server는 왜 아직 살아있나

Lightsail 플랫폼 선택 화면에서 Windows는 블루프린트 5개뿐이다. Linux 앱(18개)+Linux 운영 체제(11개)에 비하면 초라해 보이지만, 이건 Lightsail이라는 “저렴한 소규모 웹호스팅 플랫폼”에서의 이야기고, Windows Server가 여전히 확고한 영역이 따로 있다.

정리하면 Windows Server의 강점은 “웹사이트를 빠르고 저렴하게 띄우는 것”이 아니라, 이미 Windows 생태계 위에 구축된 기업 내부 인프라와 레거시 소프트웨어를 계속 굴리는 것에 있다. 그래서 Lightsail 같은 가벼운 플랫폼에서는 존재감이 작지만, 대기업 사내 IT나 Azure 같은 엔터프라이즈 클라우드에서는 지금도 확고하다.

저 네 가지, 좀 더 와닿게 풀어보면

위 카드 4개가 다 좀 추상적으로 들릴 수 있어서, 실제로 접해봤을 법한 것들로 하나씩 풀어본다.

① 기업 인증 — “사원증 하나로 다 되는 이유”
대기업 다니는 사람을 상상해보자. 아침에 컴퓨터 로그인하면 그 계정 하나로 이메일, 사내 파일서버, 프린터, 회의실 예약 시스템, 심지어 사내 ERP까지 다 접근된다. 그리고 “이 사람은 대리니까 이 폴더는 못 보고, 부장급 이상만 인사 데이터 접근 가능” 같은 권한도 IT팀이 중앙에서 관리한다. 이걸 뒤에서 돌리는 게 Active Directory다. 직원이 1만 명 되는 회사에서 “누가 뭘 볼 수 있는가”를 일일이 관리하는 건 AD 없이는 사실상 불가능하고, 이게 90년대부터 깔려서 회사 시스템 전체가 AD를 전제로 설계돼 있으니 뜯어내려면 IT 인프라를 통째로 갈아엎어야 한다.

② 레거시 — “돌아가는데 왜 바꿔?”
오래된 세무 프로그램이나 관공서 시스템 중 “UI가 왜 이렇게 옛날 느낌이지” 싶은 것들은 대부분 옛날 .NET Framework(윈도우 전용)로 짜인 것이다. 보통 15~20년 전에 수억~수십억 들여서 만든 시스템인데 지금도 업무가 잘 돌아간다. 문제는 리눅스로 옮기려면 코드를 처음부터 다시 짜야 하는 수준이라는 것 — .NET Framework 자체가 리눅스에서 안 돌아간다. “고장 안 났는데 왜 고쳐?”라는 논리와 “다시 짜는 비용이 무섭다”는 이유가 겹쳐서 그냥 Windows Server 위에서 계속 돌린다.

③ DB 통합 — “엑셀의 큰형님”
위하고나 홈택스 데이터를 엑셀로 다루는 것처럼, MS SQL Server는 그 엑셀의 “기업용 초강력 버전”이다. 은행, 제조업 재고 시스템, 대기업 회계 시스템에서 수백만 건의 거래 데이터를 실시간 처리한다. 2017년부터 리눅스에서도 돌아가긴 하지만, 관리 도구(SSMS)나 다른 마이크로소프트 제품(엑셀, Power BI, Office)과의 연동은 Windows Server 위에서 훨씬 매끄럽다. 은행 같은 곳은 “시스템 하나 잘못 건드리면 하루 매출이 날아간다”는 리스크 때문에, 20년 넘게 검증된 조합(Windows + SQL Server)을 바꿀 이유가 없다.

④ 업계 소프트웨어 — “이 업계는 이거 아니면 안 돼”
한국 세무회계 업계의 더존(Douzone)이나 세무사랑, 케이렙, 혹은 병원 EMR, 건설업 CAD 연동 프로그램들은 애초에 “이 업계 회사들만 쓸 거니까”라는 전제로 Windows 전용으로 만들어졌다. 업계 고객사들이 전부 Windows PC를 쓰고 있고, 개발사 입장에서도 굳이 리눅스 버전을 별도로 만들 이유가 없기(수요가 없으니까) 때문이다. IIS는 이런 프로그램들이 서버로 돌아갈 때 쓰는 윈도우용 웹서버다. 새솔CRM을 리눅스(Lightsail)에서 Node.js로 만든 건 오히려 “요즘 스타트업/개인 개발” 방식이고, 전통적인 업계 소프트웨어 회사들은 여전히 그 반대편에 있다.

그런데 4개 다 “같은 이유”는 아니다

위 4가지를 다시 들여다보면 성격이 갈린다. 2·3·4번(레거시 앱, DB 통합, 업계 소프트웨어)은 “이미 오래전부터 Windows 기반으로 짜여서 검증된 것을, 지금 와서 갈아엎을 이유가 없어서” 살아남는 쪽이다. 반면 1번 기업 인증(Active Directory)은 조금 다르다 — 곰곰이 따져보면 지금 시점에 리눅스 기반으로 새로 인증 체계를 구성하는 것 자체는 기술적으로 전혀 문제가 없다.

핵심은 “직원들이 어떤 PC를 쓰느냐”보다 “인증을 어디서 관리하느냐”다. 옛날 방식(전통적인 AD)은 “회사 안에 서버 한 대 놓고, 그 서버가 사내 PC들을 직접 통제”하는 구조였다. 이건 당연히 Windows Server가 필요했다. 근데 요즘은 이 자체가 클라우드로 옮겨갔다.

즉 “AD가 아니면 안 된다”가 아니라, AD는 옛날에 선택지가 그거밖에 없어서 표준이 된 것이고 지금은 대체재가 차고 넘친다. 그래서 새로 시작하는 회사라면 인증 체계만 놓고 볼 때 리눅스·클라우드 기반으로 구성하는 데 애로사항이 없다 — 오히려 이게 요즘 표준에 가깝다.

그럼에도 사무실 PC의 대다수가 이미 Windows인 상태라면 결과적으로 얘기가 달라진다 — 이유는 인증 자체의 기술적 한계가 아니라, PC에 직접 설치해서 쓰는 업계 전용 프로그램(더존, 홈택스 연계 프로그램, 한글, ERP·CAD 연동 소프트웨어 등)이 Windows 전용으로 남아있기 때문이다. 이 프로그램들을 쓰는 한 PC 자체는 Windows일 수밖에 없고, 그 Windows PC들을 정책 배포·보안 관리하려다 보면 결국 Active Directory(또는 그 클라우드 확장판인 Intune)로 자연스럽게 수렴하게 된다. 이런 의미에서 기업 인증(AD)은 그 자체의 기술적 우위 때문이 아니라, 이미 깔려있는 Windows PC 생태계에 딸려서 함께 살아남는 것에 가깝다 — 4번(업계 소프트웨어)이 사실상 1번(기업 인증)을 떠받치고 있는 구조인 셈이다.

정리하면 — 서버(뒷단 인프라)와 클라이언트(사무실 PC)는 완전히 분리된 문제다. 새솔CRM처럼 웹으로 접속하는 서비스는 서버가 Linux든 Windows든 사무실 PC엔 아무 영향이 없다(진 님이 Windows PC에서 크롬 켜서 Linux 서버 위의 새솔CRM에 접속하는 것처럼). 하지만 PC에 직접 설치해서 쓰는 업계 표준 프로그램이 Windows 전용으로 남아있는 한, 그 PC들을 통제하는 인증 체계 역시 Windows 생태계 안에 머물 수밖에 없다. Windows Server가 스스로 강해서라기보다, Windows PC 기반 업계 소프트웨어 생태계가 워낙 두꺼워서 그 위에 얹힌 인증·관리 체계까지 함께 떠받쳐지고 있는 것으로 보는 편이 더 정확하다. 예외는 회사가 Windows 전용 업계 소프트웨어(3·4번)를 필수로 써야 하는 경우뿐이며, 새솔CRM을 여러 세무사무소가 쓰는 SaaS로 확장할 때도 인증은 Google/카카오 소셜 로그인이나 자체 JWT 인증으로 충분히 가는 것이지 Windows/AD 쪽을 신경 쓸 이유는 없다.

몇 년을 헤맸던 “왜 이렇게 선택지가 많지”라는 막막함이, 결국 두세 개의 축으로 정리된다는 걸 알고 나니 뻥 뚫린 기분이다. 서버 운영을 처음 시작하는 사람이라면, 이 글의 표 하나만 옆에 두고 인스턴스 생성 화면을 열어봐도 훨씬 수월할 것 같다.