시크릿DNS로 정리한 ERP구축 업무 사이트 접속 문제

ERP 구축 업무를 하다 보면 프로그램 자체보다 먼저 막히는 일이 있다. 고객사 서버에 붙어야 하고, 외부 전자세금계산서나 그룹웨어, 개발 문서 사이트도 함께 열어야 하는데 어느 날은 잘 되다가 어느 날은 특정 주소만 늦게 뜨거나 아예 열리지 않는다. 화면 설계 검토나 마감 직전 점검처럼 시간이 촉박한 순간에 이런 문제가 나오면, 원인을 따지는 것보다 우선 접속부터 살려야 하는 상황이 더 많다.

내가 겪은 문제도 비슷했다. ERP 구축 중에는 테스트 서버, 운영 서버, 협력사 문서함, 클라우드 관리 화면처럼 서로 다른 주소를 계속 오가는데, 같은 회선 안에서도 어떤 주소는 바로 열리고 어떤 주소는 중간에서 끊겼다. 특히 고객사 현장이나 외부망이 섞인 환경에서는 같은 브라우저, 같은 계정인데도 접속 결과가 달라져서 작업자가 통제하기 어려웠다.

업무 사이트 접속 문제가 반복될 때 먼저 드러나는 한계

처음에는 흔히 하는 방식부터 썼다. 브라우저를 다시 열고, 인터넷 설정을 바꾸고, DNS 주소를 손으로 바꾸고, 안 되면 휴대폰 테더링으로 잠깐 우회했다. 한 번은 해결되지만 다음 주에 같은 문제가 다시 나오면 처음부터 다시 확인해야 했다.

ERP 구축에서는 이 반복이 더 치명적이다. 한 사람이 막히면 끝이 아니라, 테스트 시나리오 확인, 사용자 교육 자료 캡처, 승인 화면 점검 같은 뒤 작업이 줄줄이 밀린다. 실제로 한 주 동안 자주 쓰는 업무 사이트 32개를 기준으로 정리해 보니, 접속이 불안정한 주소는 7개였고 문제 생길 때마다 확인 단계가 5단계 이상으로 늘어났다. 브라우저 재실행, 회선 변경, DNS 변경, 캐시 비우기, 다시 로그인까지 거치면 한 번에 7분에서 10분이 빠졌다.

문제는 속도만이 아니었다. 사람이 수동으로 바꾸는 방식은 원인 기록이 남지 않는다. 어느 주소에서 막혔는지, 어떤 설정을 켰을 때 풀렸는지 남겨 두지 않으면 다음에 같은 현상이 나와도 다시 감으로 움직이게 된다. 현장 대응에서는 이 부분이 생각보다 크게 작용했다.

시크릿DNS를 만든 이유와 선택 기준

필요했던 것은 모든 통신을 무조건 다른 길로 보내는 방식이 아니었다. ERP 구축 환경에서는 금융, 정부, 학교 계열 사이트처럼 건드리면 오히려 접속이 꼬일 수 있는 주소도 함께 다루기 때문이다. 그래서 우회가 필요한 곳만 골라서 적용하고, 나머지는 평소처럼 두는 쪽이 더 맞았다.

시크릿DNS를 보게 된 이유도 여기에 있다. 주소를 확인하는 과정에서 중간에 내용이 바뀌지 않도록 보호하는 기능과, 특정 사이트에서만 접속 방식을 잘게 나눠 보내는 기능이 함께 들어 있다. 말이 어렵게 들릴 수 있는데, 사용 기준으로 보면 단순하다. 사이트 주소를 찾는 단계에서 정보가 바뀌지 않게 하고, 접속 신호를 보낼 때도 필요한 주소만 골라 형태를 바꿔 보내는 구조다.

비슷한 선택지와 비교하면 차이가 더 분명하다. VPN은 컴퓨터의 인터넷 길 전체를 우회하는 데 유리하다. 외부 출장처럼 회선 자체가 불안정하거나, 회사 정책상 한 번에 넓게 분리해야 할 때는 VPN이 낫다. 대신 속도 저하가 생기거나, 고객사 내부 시스템처럼 같은 망 안에서 직접 붙어야 하는 서비스와 충돌하는 경우가 있다.

브라우저의 보안 DNS 설정은 손쉽다. 다만 브라우저 안에서 주소를 찾는 일부 단계만 바뀌는 경우가 많아서, ERP 클라이언트나 별도 실행 프로그램, 설치형 업로더까지 같이 다루는 환경에서는 범위가 좁다. 반면 시크릿DNS는 윈도우에서 오가는 통신을 기준으로 판단하므로 브라우저 밖 작업까지 함께 보기 쉽다. 모든 환경에 정답은 아니지만, "몇 개 주소만 자주 문제를 일으키는 현장"에는 이쪽이 더 맞았다.

업무 사이트 접속 문제를 줄인 사용 순서

처음 쓸 때 복잡한 설정부터 만질 필요는 없었다. 내가 정리한 순서는 4단계다. 첫째, 자주 막히는 도메인을 목록으로 추린다. 우리 팀은 초기에 12개로 시작했고, 한 달 뒤 로그를 보고 18개까지 늘렸다. 둘째, DNS 암호화 옵션을 켠다. 주소를 조회할 때 내용을 숨겨서 중간에 변형될 가능성을 줄이는 단계다. 셋째, 접속이 필요한 도메인만 직접 지정한다. 넷째, 실행 후 로그를 보면서 어떤 주소에 적용됐는지 확인한다.

입력부터 결과까지의 흐름도 비교적 선명하다. 사용자가 도메인 목록을 넣으면 프로그램은 먼저 "이 주소가 지정 목록에 있는지"를 본다. 있으면 접속 신호를 그대로 보내지 않고, 감시가 쉬운 부분만 잘게 나눠 순서를 바꿔 보낸다. 없으면 굳이 건드리지 않는다. 주소를 찾는 요청도 암호화된 방식으로 바꿔 보내서, 중간에서 다른 주소로 바뀌는 일을 줄인다. 마지막으로 로그 창에 처리된 도메인이 남기 때문에, 무엇이 적용됐고 무엇이 제외됐는지 사람이 바로 확인할 수 있다.

여기서 중요했던 건 "전부 적용"이 아니라 "선별 적용"이었다. 현장에서는 업무 사이트 접속 문제가 없는 주소까지 손대면 오히려 장애 범위가 넓어진다. 지정 목록 방식은 필요한 주소만 한 줄씩 넣으면 되기 때문에 관리가 단순했고, 적용 기준도 팀원끼리 공유하기 쉬웠다. 우리 쪽 기준으로는 사용자 교육 사이트, 외부 문서 저장소, 테스트용 웹 관리 화면처럼 반복 접속이 필요한 대상만 넣었다.

처리 방식이 어떻게 갈리는지 알아야 운영이 쉬워진다

겉으로는 실행 버튼 하나지만 내부 판단 기준은 나름 분명하다. 먼저 주소를 찾는 요청이 들어오면, 프로그램은 그 요청을 바로 보내지 않고 암호화된 방식으로 보낼지 결정한다. 이 단계는 "주소를 알아내는 과정이 중간에서 바뀌지 않게 하는 것"에 가깝다. 업무 담당자 입장에서는 같은 주소를 입력했는데 전혀 다른 결과가 나오는 일을 줄여 주는 역할이다.

다음은 접속 신호 처리다. 여기서는 모든 사이트를 동일하게 보지 않는다. 지정 목록에 있는 주소인지, 예외로 빼야 하는 주소인지부터 확인한다. 금융이나 공공 계열처럼 민감한 사이트는 예외 목록으로 두고, 우회가 필요한 주소만 별도로 적용한다. 이 판단이 선행되기 때문에 불필요한 개입이 줄어든다.

그 뒤에는 실행 방식이 갈린다. 대상 주소라면 접속 신호 안에서 사이트 이름이 드러나는 부분만 찾아 중간을 나눈다. 쉽게 말해 편지를 통째로 찢는 것이 아니라, 겉봉에 적힌 핵심 부분만 나눠 보내는 식이다. 받는 쪽 컴퓨터는 이를 다시 이어 붙여 읽기 때문에 정상 접속이 가능하고, 중간 장비는 한 번에 알아보기 어려워진다. 반대로 목록에 없는 주소는 그대로 통과한다.

ERP 구축 실무에서는 이 구분이 운영 부담을 줄였다. 예전에는 문제가 생기면 네트워크 설정을 바꾼 뒤 전체 업무를 다시 확인해야 했다. 지금은 로그에서 특정 주소에만 적용됐는지 보고, 필요하면 목록에서 빼거나 추가하면 된다. 설정 변경이 "컴퓨터 전체" 단위에서 "문제 주소" 단위로 좁혀진 셈이다.

다른 접근과 비교했을 때 맞는 경우와 맞지 않는 경우

같은 업무 사이트 접속 문제를 풀더라도 접근은 여러 가지다. 첫 번째는 회선을 바꾸는 방법이다. 휴대폰 테더링이나 다른 인터넷망으로 바꾸면 바로 해결될 때가 있다. 다만 사용자 교육 중이거나 다수가 같은 네트워크를 쓰는 현장에서는 개인 회선으로 버티기 어렵다. 접속은 되더라도 자료 업로드나 대용량 다운로드가 이어지면 금방 한계가 온다.

두 번째는 VPN처럼 넓게 우회하는 방법이다. 해외 서비스 접속이나 장기간 원격 근무에는 이쪽이 더 낫다. 반면 고객사 내부 시스템과 외부 웹서비스를 동시에 다루는 ERP 구축에서는 전체 우회가 부담이 될 수 있다. 내부 프린터, 내부 서버, 특정 인증 프로그램까지 한 번에 영향받기 때문이다.

세 번째가 시크릿DNS처럼 필요한 주소만 선별하는 방식이다. 자주 막히는 대상이 몇 개로 모여 있고, 나머지 업무는 기존 회선 그대로 써야 할 때 잘 맞는다. 대신 모든 차단 상황을 만능으로 해결하지는 못한다. 프로그램 설치가 제한된 PC, 관리자 권한이 막힌 환경, 네트워크 정책이 매우 강한 기관에서는 적용이 쉽지 않을 수 있다. 즉, 문제 범위가 좁고 대상이 분명할수록 강점을 보이고, 네트워크 전체를 바꿔야 하는 상황에서는 다른 선택지가 더 맞다.

써보면서 달라진 점과 남은 불편

가장 먼저 바뀐 것은 대응 시간이었다. 예전에는 접속 문제 한 번에 5단계를 오가며 7분 이상 쓰는 일이 잦았다. 지금은 실행, 로그 확인, 목록 추가 여부 판단 정도로 2단계에서 끝나는 경우가 많다. 자주 쓰는 18개 도메인 기준으로 보면, 한 달 동안 반복된 접속 이슈 대응 시간이 체감상 절반 이하로 줄었다. 특히 테스트 마감 주간에는 "안 되면 다른 회선으로 바꿔 본다"는 임시 대응이 거의 사라졌다.

두 번째 변화는 기록이다. 로그에 처리된 도메인이 남으니, 어느 주소가 목록에 있었고 실제로 적용됐는지 팀 내 공유가 가능해졌다. 새로 투입된 인원이 와도 "문제 생기면 이 설정부터 본다"가 아니라, "이 주소는 목록에 있고 로그에 이렇게 찍혀야 한다"고 바로 설명할 수 있었다. 구두 전달보다 훨씬 덜 흔들렸다.

아쉬운 점도 있다. 처음 목록을 만드는 데 시간이 든다. 문제 주소를 한꺼번에 모아 두지 않으면 한동안은 로그를 보면서 계속 다듬어야 한다. 또 예외로 빼야 하는 사이트를 모르고 넓게 적용하면 금융 인증이나 학교 포털처럼 민감한 페이지에서 예상치 못한 접속 장애가 생길 수 있다. 즉, 설치만 하면 끝나는 프로그램이라기보다, 초반에 기준을 정리해야 손에 익는 편에 가깝다.

이런 상황이라면 맞고, 이런 경우엔 덜 맞다

ERP 구축에서 외부 업무 사이트를 여러 개 오가고, 그중 일부만 반복적으로 접속 불안정이 생기는 팀이라면 시크릿DNS가 맞을 가능성이 높다. 고객사 현장 지원, 테스트 서버 점검, 사용자 교육 자료 준비처럼 브라우저와 설치형 프로그램을 함께 쓰는 일정에서 특히 도움이 됐다. 주소 단위로 관리할 수 있어 팀 공유도 어렵지 않다.

반대로 회사 정책상 프로그램 설치가 제한돼 있거나, 네트워크 전체를 한 번에 다른 경로로 보내야 하는 환경이라면 다른 방법이 더 낫다. 해외 접속 전체를 묶어서 관리해야 하면 VPN이 편하고, 브라우저에서만 잠깐 확인하면 되는 수준이면 보안 DNS 설정만으로도 충분할 수 있다. 결국 선택 기준은 단순하다. 문제 주소가 몇 개로 좁혀지는지, 전체 회선을 바꿔도 되는지, 현장에서 누가 유지할지를 먼저 보면 된다.

메타 설명: ERP구축 중 반복되는 업무 사이트 접속 문제를 시크릿DNS로 줄인 과정을 정리했다. 기존 방식의 한계, 적용 순서, 다른 방법과의 선택 기준까지 담았다.

공식 홈페이지로 가기