시크릿DNS 심리상담소에서 차단 사이트와 기록 조회가 겹칠 때

시크릿DNS 심리상담소에서 차단 사이트와 기록 조회가 겹칠 때

시크릿DNS 심리상담소에서 차단 사이트와 기록 조회가 겹칠 때

상담 기록을 확인하는데 사이트마다 접속 상태가 달랐던 문제

심리상담소 업무는 상담만으로 끝나지 않는다. 예약 확인, 비대면 상담 도구 접속, 보호자 안내 자료 전달, 외부 기관 서식 확인까지 한 자리에서 이어진다. 문제는 이 과정이 한 번에 이어져야 하는데, 특정 사이트만 유독 늦게 열리거나 아예 접속이 끊기는 날이 반복됐다는 점이었다.

처음에는 인터넷 회선 문제로 봤다. 그런데 같은 시간에 메신저와 전자우편은 정상인데, 일부 자료실이나 해외 기반 서비스만 느려졌다. 상담 기록을 정리하다가 참고 링크를 열어야 할 때 10초 넘게 기다리는 경우가 하루에 여러 번 생겼고, 상담사 6명이 함께 쓰는 환경에서는 작은 지연도 금방 누적됐다.

특히 곤란했던 건 접속 실패가 일정하지 않았다는 점이다. 오전에는 열리던 주소가 오후에는 막히고, 본원 컴퓨터에서는 되는데 상담실 보조 PC에서는 실패하는 식이었다. 이런 상태에서는 직원이 문제를 이해하기도 어렵고, 관리자 입장에서도 원인을 설명하기가 쉽지 않았다.

기존 방식으로 버티던 때의 한계와 직접 정리하게 된 이유

처음에는 가장 단순한 방법부터 썼다. 브라우저의 보안 설정을 바꿔 보거나, 다른 인터넷 프로그램으로 다시 접속하고, 안 되면 휴대전화 테더링으로 우회했다. 급한 업무는 그럭저럭 넘길 수 있었지만, 상담 중에 네트워크를 바꾸는 방식은 매번 손이 많이 갔다.

이 방식의 한계는 분명했다. 첫째, 누가 해도 같은 결과가 나와야 하는데 사람마다 조치 방법이 달랐다. 둘째, 접속 문제를 해결하려고 전체 인터넷 경로를 바꾸면 필요 없는 사이트까지 영향을 받았다. 셋째, 금융기관이나 공공기관처럼 민감한 사이트는 오히려 접속이 더 꼬이기도 했다.

상담소에서 필요한 것은 모든 접속을 무조건 우회하는 방식이 아니었다. 평소처럼 열리는 사이트는 그대로 두고, 막히거나 감시 영향을 받는 일부 주소만 따로 다루는 방법이 필요했다. 그래서 새 프로그램을 처음부터 만드는 대신, 시크릿DNS를 기준으로 우리 업무에 맞는 지정 목록과 예외 목록을 직접 구성해 쓸 수 있는지 검토하게 됐다.

시크릿DNS를 고른 이유와 다른 선택지와의 차이

비슷한 문제를 풀려면 보통 세 가지 방향이 있다. 전체 인터넷 경로를 다른 서버로 보내는 방식, 브라우저 안에서만 별도 확장 기능을 쓰는 방식, 필요한 도메인만 골라 처리하는 방식이다. 상담소처럼 업무용 사이트와 일반 사이트가 섞여 있는 곳에서는 세 번째가 가장 덜 거슬렸다.

전체 경로를 바꾸는 방식은 한 번 켜면 대부분의 접속 문제가 줄어드는 대신, 모든 트래픽이 같은 규칙을 타게 된다. 영상 상담, 정부 민원 페이지, 은행 보안 모듈처럼 민감한 조합에서는 예상 밖 충돌이 생길 수 있다. 반대로 브라우저 확장 기능은 설치가 쉽지만, 브라우저 밖에서 열리는 프로그램이나 일부 내장 웹 화면에는 적용되지 않는 경우가 있다.

시크릿DNS는 필요한 도메인만 지정해서 다룰 수 있다는 점이 업무 환경과 맞았다. 기본적으로 주소를 물어보는 과정은 암호화해서 바꾸고, 사이트를 확인하는 과정에서 특정 문자열이 보이는 구간만 잘게 나눠 보낸다. 말이 어렵게 들릴 수 있지만, 사용자가 보기에는 전체 인터넷을 뒤집는 것이 아니라 문제를 일으키는 구간만 건드리는 방식에 가깝다.

우리 쪽에서는 우회가 필요한 주소를 처음 18개로 시작했다. 상담 자료 저장소 4개, 해외 설문 도구 3개, 화상 상담 관련 주소 5개, 외부 번역 자료 링크 6개였다. 이후 로그를 보면서 2주 동안 11개를 추가했고, 반대로 공공기관과 금융기관 관련 주소 9개는 예외 목록으로 분리했다.

어떤 순서로 동작하는지 이해한 뒤에야 업무에 붙일 수 있었다

시크릿DNS를 업무에 쓸 수 있었던 이유는 동작 순서를 읽어 보면 사용자가 납득할 수 있기 때문이다. 단순히 알아서 우회한다고 적혀 있으면 관리자가 설명하기 어렵다. 이 프로그램은 입력부터 결과까지 흐름을 비교적 명확하게 나눠 볼 수 있었다.

첫 단계는 입력이다. 사용자가 접속하려는 사이트 주소가 생기면, 프로그램은 그 주소를 바로 인터넷 사업자 쪽에 평문으로 묻는 대신 암호화된 방식으로 보낸다. 쉽게 말해, 어느 사이트를 찾는지 중간에서 읽기 어렵게 바꿔 묻는 단계다.

둘째는 판단이다. 여기서 모든 주소를 똑같이 처리하지 않는다. 지정 목록에 있는 도메인인지, 예외 목록에 들어 있는지, 일반 접속으로 충분한지 먼저 가른다. 예를 들어 목록에 .example.com처럼 넣어 두면 sub.example.com도 같은 계열로 보고 함께 처리된다.

셋째는 처리 방식 선택이다. 우회가 필요한 주소면 사이트 이름이 드러나는 부분만 계산해서 나눠 보낸다. 반대로 예외 목록에 있으면 파편화라는 분할 전송을 건너뛴다. 은행, 학교, 정부 사이트처럼 예민한 곳을 자동으로 제외하는 이유가 여기에 있다.

넷째는 실행이다. 프로그램은 나눠진 조각을 한 번에 던지는 대신 순서를 조정해 전송한다. 사용자는 그 내부 순서를 몰라도 되지만, 핵심은 상대 서버는 정상적으로 다시 조립해 읽고 중간 감시 장비는 식별하기 어려워진다는 점이다. 다섯째는 결과 확인인데, 로그 창에서 어떤 도메인이 처리됐는지와 예외 처리됐는지를 바로 볼 수 있어 다음 목록 수정이 쉬웠다.

상담소에서 적용한 방식과 설정 기준

처음 설치한 뒤 바로 전 직원에게 배포하지는 않았다. 데스크 PC 2대와 상담실 PC 1대, 총 3대에서 먼저 테스트했다. 5일 동안 같은 주소를 반복 열어 보면서 접속 시간, 실패 횟수, 다른 사이트 영향 여부를 같이 적었다.

설정은 복잡하게 가져가지 않았다. 주소를 묻는 과정은 암호화된 방식으로 두고, 사이트 이름 분할은 지정 목록에만 적용했다. 모든 사이트를 다 건드리면 안정성은 떨어질 수 있으니, 우회가 필요한 주소만 한 줄씩 적는 방식이 관리하기 편했다.

실제 적용 순서는 단순했다. 1단계에서 자주 막히는 도메인을 로그나 직원 제보로 모은다. 2단계에서 해당 주소가 반복적으로 실패하는지 확인한다. 3단계에서 지정 목록에 추가하고, 공공기관이나 결제 관련 주소는 예외 목록으로 분리한다. 4단계에서 다시 접속 테스트를 하고, 5단계에서 문제 없으면 그 설정을 다른 PC로 복사했다.

여기서 유용했던 점은 네트워크 전체 설정을 뒤집지 않는다는 부분이다. 윈도우의 기본 네트워크 값을 크게 바꾸지 않고, 실행 중인 동안 필요한 패킷만 따로 다루는 구조라 원상 복귀가 간단했다. 상담소처럼 담당자가 바뀌는 환경에서는 이 차이가 작지 않았다.

사용 전후를 숫자로 비교하면 변화가 더 분명했다

도입 전에는 외부 자료 링크 20개를 오전에 한 번씩 점검할 때 평균 11분 정도가 걸렸다. 접속 실패가 3건 안팎 나오면 다른 브라우저로 다시 열고, 안 되면 휴대전화 연결까지 시도해야 했기 때문이다. 같은 점검을 시크릿DNS 적용 후 2주 동안 기록해 보니 평균 6분 40초로 줄었다.

상담사들이 체감한 변화도 비슷했다. 비대면 상담 자료실과 설문 페이지를 여는 작업에서 재시도 횟수가 하루 평균 14회에서 4회 수준으로 내려갔다. 완전히 0회가 된 것은 아니지만, 적어도 상담 시작 직전에 주소가 안 열려 허둥대는 일이 크게 줄었다.

속도만 보고 판단하면 오해가 생길 수 있어 실패 유형도 같이 봤다. 적용 전에는 특정 사이트가 아예 안 열리는 경우가 잦았다면, 적용 후에는 열리지만 첫 응답이 약간 늦는 사례가 드물게 있었다. 즉, 전면적인 속도 향상이라기보다 접속 불안정이 안정적인 대기 시간으로 바뀐 쪽에 가깝다.

메모리 사용량도 확인했다. 백그라운드 실행 상태에서 우리 환경 기준으로 대체로 30MB 안팎에서 움직였고, 일반 문서 작업과 상담 기록 프로그램 사용에는 눈에 띄는 영향이 없었다. 다만 오래된 저사양 PC 1대에서는 로그 창을 계속 켜 둔 상태에서 체감이 약간 무거워져, 그 장비는 평소 로그를 닫아 두는 쪽으로 정리했다.

아쉬운 점과 맞지 않는 환경도 분명히 있었다

모든 환경에 잘 맞는 것은 아니었다. 우회가 필요한 주소를 처음부터 정확히 알고 있어야 지정 목록 방식이 빛난다. 자주 바뀌는 서비스나 하위 주소가 많은 플랫폼은 목록 관리가 번거롭고, 초기에 누락이 생기면 다시 실패를 겪는다.

또 하나는 예외 사이트 관리다. 상담소 업무에는 공공기관, 결제, 보험 관련 페이지가 자주 섞인다. 이런 주소는 분할 전송이 오히려 접속 문제를 만들 수 있어 반드시 제외해야 했다. 처음 이 구분 없이 넓게 적용했을 때 주민등록등본 발급 페이지와 카드 결제 화면에서 오류가 발생했고, 그 뒤로는 업무군별 예외 목록을 따로 뒀다.

브라우저만 쓰는 개인 환경이라면 더 단순한 선택지가 나을 수도 있다. 특정 브라우저 안에서만 접속 문제가 생기고 다른 프로그램은 멀쩡하다면, 브라우저 확장 기능이나 보안 DNS 설정만으로 끝나는 경우도 있다. 반대로 상담소처럼 브라우저, 화상상담 링크, 외부 설문, 문서 열람이 한 컴퓨터에서 섞여 돌아가면 프로그램 단위의 제어가 더 안정적이었다.

이런 상황이라면 맞고, 이런 상황이라면 굳이 쓸 필요는 없다

반복해서 같은 사이트 몇 곳이 막히거나 늦게 열리고, 그 때문에 상담 준비나 기록 확인 순서가 자주 끊기는 환경이라면 시크릿DNS가 맞는다. 특히 모든 트래픽을 한꺼번에 우회하고 싶지는 않지만, 필요한 주소만 골라 관리하고 싶은 곳에서 장점이 분명했다. 상담소, 교육기관, 소규모 사무실처럼 예외 사이트와 업무 사이트가 함께 섞인 환경이 여기에 가깝다.

반대로 접속 문제보다 단순한 속도 개선이 목적이라면 우선순위가 떨어진다. 목록을 직접 정리해야 하고, 예외 사이트를 구분해야 하며, 가끔은 로그를 보면서 원인을 확인해야 한다. 한두 번 쓰고 끝나는 개인 용도라면 다소 손이 많이 간다.

우리 쪽에서는 지금도 모든 PC에 동일하게 쓰지 않는다. 외부 자료 조회와 비대면 상담 링크를 자주 다루는 자리에는 유지하고, 행정용 공공 사이트만 주로 쓰는 자리는 적용 범위를 좁혔다. 결국 핵심은 프로그램 자체보다, 어떤 주소를 왜 분리해서 다룰지 기준을 세울 수 있느냐에 달려 있었다.

공식 홈페이지로 가기