시크릿DNS로 상조서비스 반복 접속 오류 줄인 기록

마감 직전에 반복되던 접속 문제부터 정리했다

상조서비스 쪽 실무를 하다 보면 상담 등록, 증빙 조회, 제휴처 확인, 내부 문서 전달까지 한 번에 여러 사이트를 열어 두는 날이 많다. 문제는 필요한 페이지가 항상 같은 속도로 열리지 않는다는 점이었다. 어떤 날은 잘 열리다가도 특정 사이트만 유독 느리거나, 아예 접속이 멈춘 것처럼 보이는 일이 반복됐다.

업무 특성상 한 건만 늦어져도 뒤에 있는 전화 응대와 서류 확인이 함께 밀린다. 특히 발인 일정이나 증빙 제출처럼 시간 기준이 분명한 업무에서는 브라우저를 새로고침하는 몇 분도 체감이 크게 온다. 현장에서는 원인을 길게 분석할 여유보다, 당장 다시 열리게 만드는 방법이 먼저 필요했다.

처음에는 회선 문제로 보고 넘어간 적이 많았지만 패턴이 일정했다. 일반 검색이나 메일은 잘 되는데, 일부 사이트만 접속 과정에서 끊기거나 오래 걸렸다. 결국 전체 인터넷 속도보다 특정 주소를 확인하고 연결하는 과정에서 문제가 생긴다고 보고 따로 정리하기 시작했다.

기존 방식으로 버틴 한계와 선택 기준

가장 먼저 쓴 방법은 브라우저 재실행, 다른 회선 연결, 모바일 핫스팟 전환 같은 우회였다. 급할 때는 효과가 있었지만 매번 사람이 판단하고 다시 시도해야 했다. 한 건 처리할 때는 버틸 만해도 하루에 여러 번 반복되면 누적 시간이 커졌다.

다른 선택지도 검토했다. 첫 번째는 일반 VPN, 즉 전체 인터넷 연결을 다른 경로로 돌리는 방식이었다. 접속 자체는 되는 경우가 있었지만, 상조서비스 업무에서는 금융사 페이지나 공공기관 확인 화면도 자주 열기 때문에 전체 회선을 한꺼번에 바꾸는 방식이 항상 맞지는 않았다. 어떤 사이트는 로그인 보안 검사가 더 까다로워졌고, 업무와 무관한 사이트까지 모두 같은 처리를 받아 체감 속도가 오히려 들쑥날쑥했다.

두 번째는 공용 DNS 변경 프로그램이나 윈도우 네트워크 설정 직접 수정이었다. 한 번 바꾸면 간단해 보이지만, 문제는 원상복구와 예외 처리였다. PC를 같이 쓰는 환경에서는 누가 설정을 건드렸는지 추적하기도 어렵고, 금융권이나 학교 사이트처럼 민감한 곳에서 접속 이상이 생기면 다시 손으로 되돌려야 했다.

시크릿DNS를 고른 이유는 적용 범위를 나눌 수 있었기 때문이다. 전체 연결을 한 번에 바꾸지 않고, 우회가 필요한 주소만 따로 지정해서 처리할 수 있다. 상조서비스처럼 일반 업무 사이트, 공공기관, 결제 관련 페이지가 한 PC 안에 섞여 있는 환경에서는 이 구분이 생각보다 중요했다.

왜 직접 써 보게 됐는지, 업무 기준으로 본 작동 순서

필요했던 것은 복잡한 기능이 아니라 순서가 보이는 처리 방식이었다. 시크릿DNS는 사용자가 지정한 주소를 기준으로 동작이 갈린다. 모든 사이트를 건드리지 않고, 목록에 넣은 주소만 따로 확인한 뒤 필요한 처리만 붙이는 구조라서 업무 PC에 올렸을 때 부담을 예측하기 쉬웠다.

작동 순서를 업무 기준으로 풀면 이렇다. 먼저 사용자가 접속하려는 사이트 주소를 읽는다. 그다음 그 주소가 지정 목록에 있는지, 또는 예외 목록에 있는지 확인한다. 목록에 없으면 평소처럼 그대로 연결하고, 목록에 있으면 주소를 찾는 과정은 암호화된 경로로 보내고 사이트 접속 신호는 잘게 나눠서 보낸다. 마지막으로 처리 결과를 로그에 남겨서 어떤 주소가 적용됐는지 바로 확인할 수 있다.

여기서 중요한 기준은 두 가지였다. 하나는 우회가 필요한 주소인지 아닌지, 다른 하나는 예외로 빼야 할 주소인지 여부다. 예를 들어 금융, 정부, 학교처럼 접속 안정성이 더 중요한 곳은 화이트리스트, 즉 제외 목록으로 빼 두고, 자주 막히는 주소만 직접 지정 목록에 넣는 식으로 운영할 수 있었다.

설정도 복잡하게 가져가지 않았다. DNS는 암호화 방식으로 두고, SNI는 직접 지정 방식으로 맞췄다. 한 줄에 하나씩 도메인을 적는 구조라서 관리가 쉬웠고, 서브도메인까지 같이 잡히는 방식이라 같은 계열 주소를 여러 줄로 반복 입력할 필요가 없었다.

실제 사용 과정에서 달라진 점을 단계별로 적어 본다

처음 세팅할 때 한 일은 다섯 단계였다. 1단계는 프로그램 실행, 2단계는 DNS 암호화 선택, 3단계는 SNI 직접 지정 선택, 4단계는 우회가 필요한 도메인 입력, 5단계는 로그 확인 후 저장이다. 업무 인수인계 기준으로도 설명이 가능한 수준이라, 혼자만 아는 설정으로 남지 않았다는 점이 컸다.

실사용에서는 입력부터 결과까지 흐름이 더 분명했다. 먼저 접속이 자주 흔들리는 사이트를 로그로 확인하고 목록에 추가한다. 이후 다시 접속을 시도하면 프로그램이 해당 주소를 읽고, 우회 대상이면 암호화된 주소 확인과 신호 분할을 적용한다. 접속이 끝나면 로그 창에서 적용 여부를 바로 본다. 적용되지 않은 항목은 표시가 다르게 남기 때문에, 주소를 잘못 넣었는지 바로 확인할 수 있었다.

처리 시간 체감도 메모해 봤다. 오전 시작 전에 필요한 주소 18개를 미리 열어 확인하던 작업이 기존에는 새로고침과 재시도를 포함해 12분 안팎 걸렸다. 시크릿DNS에서 직접 지정 목록을 정리한 뒤에는 같은 확인이 5분에서 6분 정도로 줄었다. 절대적인 속도 향상보다 재시도 횟수가 줄었다는 점이 더 컸다.

파일 기준으로도 관리 단위가 단순했다. 목록 파일은 도메인 위주라 용량이 크지 않았고, 내부 공유용 메모에 30개 내외 주소만 정리해 두면 됐다. 기능이 많아 보여도 현장에서 계속 만지는 항목은 사실상 지정 목록, 예외 판단, 로그 확인 세 가지였다.

다른 방식과 비교해 보니 맞는 자리와 아닌 자리가 갈렸다

VPN은 전 구간을 한 번에 바꾸는 방식이라, 외부 접속 차단이 강한 환경에서는 더 강하게 작동할 수 있다. 대신 상조서비스 업무처럼 한쪽에서는 제휴사 페이지, 다른 쪽에서는 공공기관 조회, 또 다른 쪽에서는 사내 웹 도구를 같이 쓰는 상황에서는 과하게 넓게 적용되는 느낌이 있었다. 전체를 바꾸는 만큼 예외가 생겼을 때 원인도 넓게 찾아야 했다.

반면 시크릿DNS는 필요한 주소만 지정해서 처리할 수 있어 범위를 좁히기 좋았다. 접속 문제가 특정 사이트 몇 곳에 집중돼 있을 때는 이쪽이 관리가 편했다. 다만 모든 차단 상황을 다 해결해 주는 성격은 아니어서, 회사 정책이나 별도 보안 장비 때문에 막히는 경우까지 해결해 주는 것은 아니었다.

윈도우 네트워크 설정을 직접 바꾸는 방식과도 차이가 있었다. 직접 변경은 한 번 손대면 전체 PC 동작이 바뀌기 때문에 단순하지만, 이후 문제가 생겼을 때 어디까지 영향을 줬는지 확인이 번거롭다. 시크릿DNS는 네트워크 기본값을 직접 바꾸지 않고 별도 처리로 동작하는 편이라 업무 PC에서 시험 적용하기가 비교적 수월했다.

아쉬운 점도 있다. 처음에는 어떤 주소를 목록에 넣어야 하는지 사용자가 판단해야 한다. 막연히 실행만 해 둔다고 끝나는 구조가 아니라, 로그를 보면서 대상 주소를 정리하는 시간이 필요하다. 그리고 금융권이나 공공 사이트처럼 예민한 곳은 예외로 빼는 판단이 중요해서, 초기에 1~2일 정도는 관찰이 필요했다.

상조서비스 업무에서 어떤 사람에게 맞는지

반복 접속 오류 때문에 상담 입력, 서류 확인, 제휴처 조회가 자주 끊기는 사람에게는 맞다. 특히 같은 몇 개 사이트에서만 문제가 반복되고, 전체 인터넷 환경까지 바꾸고 싶지 않은 경우라면 적용 범위를 좁혀서 써 볼 만하다. 업무용 PC를 여러 사람이 함께 써서 설정 변경 이력을 단순하게 유지해야 할 때도 장점이 있다.

반대로 모든 사이트를 한 번에 다른 경로로 보내야 하거나, 회사 보안 정책상 별도 프로그램 실행이 어려운 환경이라면 맞지 않을 수 있다. 접속 문제의 원인이 단순한 차단이 아니라 계정 권한, 인증서, 사내 방화벽 같은 다른 요소라면 효과가 제한적이다. 이런 경우에는 네트워크 담당자 확인이나 VPN 같은 다른 선택지가 더 적절하다.

내 기준에서는 시크릿DNS가 만능 해결책은 아니었다. 다만 상조서비스처럼 마감 시간은 짧고, 접속 문제는 반복되며, 전체 설정을 크게 흔들기는 부담스러운 자리에서는 쓸모가 분명했다. 우회가 필요한 주소를 추려서 관리하고, 예외 사이트를 빼 두고, 로그로 적용 여부를 확인하는 정도까지 감당할 수 있다면 업무 중 끊기는 시간을 줄이는 데는 충분히 의미가 있었다.

공식 홈페이지로 가기