시크릿DNS로 태양광설치 현장 자료 접속 지연 줄인 기록

태양광설치 업무에서 막히는 순간은 설치보다 자료 확인일 때가 많다

태양광설치 일을 하면 현장에서 손으로 하는 작업만 많은 게 아니다. 인버터 매뉴얼, 구조 계산 자료, 모니터링 접속 주소, 납품처가 올린 문서, 해외 제조사 기술 문서를 계속 확인해야 한다. 문제는 이런 자료를 찾는 시간이 일정하지 않다는 데 있다. 어떤 날은 바로 열리는데, 어떤 날은 같은 자리에서 같은 주소를 눌러도 한참 멈추거나 아예 접속이 끊긴다.

처음에는 인터넷 회선 문제라고 생각했다. 현장 사무실 공유기 문제, 통신사 문제, 회사 보안 프로그램 문제를 하나씩 의심했다. 그런데 같은 파일도 브라우저에 따라 열리고 안 열리는 경우가 있고, 모바일 데이터로는 열리는데 유선 인터넷에서는 멈추는 경우가 반복됐다. 이쯤 되면 단순히 인터넷이 느린 게 아니라, 주소를 찾는 과정이나 접속 과정 중간에서 뭔가 걸린다고 보는 편이 맞았다.

태양광설치 쪽은 일정이 밀리면 바로 다음 공정까지 흔들린다. 구조물 반입, 모듈 배치, 전기 연결, 감리 대응까지 줄줄이 이어지기 때문에 자료 확인 하나가 늦어지면 현장에서는 기다리는 사람이 생긴다. 그래서 처음부터 큰 기능이 많은 프로그램을 찾기보다, 특정 사이트 접속이 막히거나 느려지는 문제를 줄이는 쪽으로 방향을 잡게 됐다.

기존 방식으로 버틴 기간이 길수록 반복 작업만 늘어났다

그 전까지는 문제가 생길 때마다 우회 방법을 바꿔 썼다. 브라우저를 바꾸거나, 휴대폰 테더링으로 잠깐 연결하거나, 직원에게 다른 회선에서 파일을 받아 달라고 요청했다. 급할 때는 제조사 문서를 미리 내려받아 폴더별로 저장해 두기도 했는데, 최신 버전이 아닌 경우가 있어 결국 다시 확인해야 했다.

겉으로 보면 대단한 문제가 아닌 것처럼 보이지만, 작업 단계를 쪼개 보면 낭비가 컸다. 예를 들면 문서 1건을 확인하려고 1) 주소 접속, 2) 실패 확인, 3) 브라우저 변경, 4) 다시 로그인, 5) 그래도 안 되면 모바일 회선 연결, 6) 직원에게 전달 요청 같은 순서가 붙었다. 원래 2단계면 끝날 일이 6단계 이상으로 늘어난 셈이다. 하루에 이런 일이 3번만 생겨도 체감이 컸다.

시간도 꽤 차이가 났다. 바로 열리는 경우는 10초 안쪽인데, 접속이 꼬이면 한 건 확인에 5분에서 15분까지 걸렸다. 현장에서 인버터 설정값이나 시공 기준 파일 4~5개만 다시 확인해도 20분 이상이 빠졌다. 설치팀 입장에서는 공구를 찾는 시간보다 문서를 다시 여는 시간이 더 길게 느껴질 때가 있었다.

대안도 검토했다. 하나는 전체 인터넷 경로를 바꾸는 방식이었다. 접속 문제는 줄 수 있지만 회사 PC 전체에 영향을 주기 쉽고, 금융 사이트나 공공 사이트까지 같이 꼬일 위험이 있었다. 다른 하나는 브라우저 확장 기능만 쓰는 방식인데, 이건 웹브라우저 안에서만 동작하니 프로그램 업데이트 도구나 다른 업무 프로그램 접속까지 같이 다루기 어렵다. 태양광설치 실무에서는 브라우저만 쓰는 게 아니라 제조사 유틸리티, 원격 점검 프로그램, 파일 내려받기 창도 같이 움직여서 한쪽만 해결하면 끝나지 않았다.

시크릿DNS를 고른 이유는 전체를 바꾸지 않고 필요한 곳만 건드릴 수 있어서다

여기서 중요하게 본 건 과한 변경을 피하는 것이었다. 시크릿DNS는 인터넷 설정값을 통째로 바꾸는 방식이 아니라, 접속 과정에서 필요한 부분만 따로 처리하는 쪽에 가깝다. 실무에서 이런 방식이 나은 이유는 단순하다. 정상적으로 잘 열리는 사이트까지 같이 흔들 필요가 없기 때문이다.

내가 주로 쓴 방식은 추천 옵션에 가까웠다. 주소를 찾는 과정은 암호화된 방식으로 바꾸고, 접속 우회가 꼭 필요한 도메인만 지정 목록에 넣는 식이다. 말이 어려워 보일 수 있는데, 사용자가 체감하는 순서는 단순하다. 먼저 사이트 주소를 찾을 때 중간에서 내용이 바뀌지 않도록 보호하고, 그다음 접속 도중 특정 주소에서만 잘게 나눠 보내는 방식을 적용하는 구조다. 모든 사이트에 일괄 적용하는 게 아니라 필요한 곳만 골라서 쓴다는 점이 핵심이었다.

이 방식이 맞았던 이유는 태양광설치 업무 특성 때문이다. 하루 종일 보는 사이트가 정해져 있다. 제조사 기술문서 페이지, 자재 발주처, 일부 해외 모니터링 페이지, 사내 공유 주소처럼 반복해서 들어가는 곳이 뚜렷하다. 그러면 우회가 필요한 주소만 목록으로 관리하는 편이 더 낫다. 접속 문제가 없는 일반 사이트는 그대로 두고, 자주 막히는 곳만 지정하면 불필요한 간섭이 줄어든다.

아쉬운 점도 있다. 처음부터 모든 상황이 깔끔하게 끝나는 건 아니다. 어떤 사이트는 보안 정책 때문에 파편화 적용이 오히려 맞지 않을 수 있고, 금융이나 학교, 공공기관 계열은 예외로 빼는 편이 안전하다. 즉 설치만 하면 만능으로 해결되는 종류는 아니다. 다만 어떤 주소에 적용하고 어떤 주소는 빼야 하는지가 눈에 보이기 시작하면 관리가 가능한 도구로 바뀐다.

입력부터 결과까지 어떤 순서로 움직이는지 알아야 덜 헷갈린다

실제로 쓸 때는 과정을 이해하고 들어가는 편이 훨씬 낫다. 시크릿DNS는 사용자가 주소를 입력하거나 사이트에 접속했을 때, 그 요청을 읽고 몇 가지 기준으로 나눠 본다. 그다음 필요한 처리만 적용하고, 마지막에 로그로 무엇이 처리됐는지 보여 준다.

순서를 작업 기준으로 풀면 1) 사용자가 사이트에 접속한다, 2) 프로그램이 접속 주소와 방식이 무엇인지 확인한다, 3) 지정 목록에 있는 도메인인지 먼저 본다, 4) 예외 목록에 들어 있으면 건너뛴다, 5) 우회 대상이면 주소 확인 과정은 암호화해서 보내고, 접속 신호는 나눠서 보낸다, 6) 처리 결과를 로그에 남긴다. 사용자는 복잡한 내부 구조를 몰라도 되지만, 이 여섯 단계 정도는 알고 있으면 문제가 생겼을 때 원인을 좁히기 쉽다.

여기서 동작이 갈리는 기준도 분명하다. 지정 목록에 없는 주소는 평소처럼 통과한다. 지정 목록에 있더라도 예외 목록에 있으면 나누지 않는다. 또 일반 웹사이트가 아닌 다른 종류의 연결은 적용 범위에서 벗어날 수 있다. 즉 아무 데나 무조건 개입하는 게 아니라 주소와 접속 상태를 보고 갈라지는 구조다.

처리 순서를 조금 더 쉬운 말로 바꾸면 이렇다. 먼저 주소를 찾는 단계에서 중간 변조를 막고, 그다음 접속 시작 부분에서 감청 장비가 읽기 쉬운 부분만 골라 잘게 나눠 보낸다. 수신 쪽 컴퓨터는 그 조각을 다시 원래 순서로 이어서 읽는다. 사용자는 사이트가 그냥 열리는 것처럼 보이지만, 중간 과정은 필요한 부분만 다르게 흘러간다.

로그 창도 단순한 부가 기능이 아니었다. 처리된 도메인이 바로 보이기 때문에, 어떤 주소가 실제로 우회 대상이 되었는지 확인할 수 있다. 반대로 적용되지 않은 항목은 따로 표시되니, 목록에 넣어야 할지 아니면 예외로 둘지 판단 근거가 생긴다. 현장에서는 이런 확인 단계가 중요하다. 안 되는 이유를 모르면 같은 시도를 계속 반복하게 되기 때문이다.

현장에서 써보며 바뀐 점은 속도보다 판단 시간이 줄었다는 쪽에 가깝다

처음 며칠은 지정 목록을 정리하는 데 시간이 들었다. 자주 접속하는 주소를 추려서 한 줄씩 넣고, 로그를 보면서 불필요한 항목은 빼는 식으로 손봤다. 대략 18개 도메인으로 시작했고, 한 달 정도 지나니 27개 정도로 정리됐다. 숫자가 늘었다고 해서 무조건 좋은 건 아니고, 자주 쓰는 곳 위주로 유지하는 편이 관리가 쉬웠다.

체감 변화는 두 가지였다. 첫째는 접속 실패 후 다른 방법으로 갈아타는 횟수가 줄었다. 예전에는 하루 4~6번 정도 브라우저 변경이나 테더링 전환을 했는데, 적용 후에는 1~2번 수준으로 내려갔다. 둘째는 문서 확인 시간 편차가 줄었다. 바로 열릴 때는 원래도 빨랐지만, 막힐 때 5분 넘게 끌던 일이 30초에서 1분 안쪽에서 끝나는 경우가 많아졌다. 평균 처리 시간을 정밀하게 재진 않더라도, 회의 직전이나 출고 직전에 멈추는 일이 줄어든 건 분명했다.

특히 협업 중 차이가 컸다. 설치 사진, 계통도, 자재 승인서처럼 팀원 둘 이상이 같은 자료를 봐야 할 때, 한 사람만 접속이 늦으면 결국 메신저 전달이나 캡처 공유로 돌아간다. 시크릿DNS를 적용한 뒤에는 각자 직접 원본 자료를 여는 비율이 올라갔다. 전달 과정이 줄어드니 최신 문서 기준이 맞춰졌고, 버전이 다른 파일을 보고 이야기하는 실수도 덜했다.

반면 한계도 남았다. 모든 느림이 이 문제 때문은 아니다. 서버 자체가 느린 날, 파일 용량이 큰 날, 현장 회선 품질이 나쁜 날은 당연히 별 차이가 없다. 예를 들어 도면 PDF가 80MB를 넘는 경우는 접속이 되더라도 내려받는 시간이 길 수밖에 없다. 그래서 이 프로그램으로 해결되는 문제와 회선 자체 문제를 구분해서 봐야 한다.

다른 선택지와 비교하면 어떤 환경에서 맞는지가 더 중요하다

같은 문제를 푸는 방법은 하나가 아니다. 브라우저 확장 기능 위주 방식은 설정이 간단하고 가벼운 대신, 브라우저 밖에서 움직이는 프로그램 접속까지 함께 다루기 어렵다. 태양광설치 업무에서 제조사 설정 도구나 업데이트 프로그램까지 같이 써야 한다면 범위가 좁게 느껴질 수 있다.

전체 경로를 바꾸는 방식은 적용 범위가 넓어서 강하게 해결될 때가 있다. 대신 잘 쓰던 사이트까지 영향이 갈 수 있고, 회사 PC 전체 설정이 달라졌을 때 문제가 생기면 원인 파악이 오히려 오래 걸린다. 현장 직원이 여러 명이고 컴퓨터 사용 수준이 제각각이면, 강한 방식일수록 관리자가 계속 붙어 있어야 한다.

시크릿DNS는 그 중간쯤에 있었다. 주소를 찾는 과정 보호와 특정 도메인 대상 처리라는 두 축이 있어서, 문제를 좁혀서 다루기 좋았다. 우회가 필요한 사이트만 지정하는 방식은 초반에 목록을 정리해야 하는 수고가 있지만, 한번 자리 잡으면 불필요한 적용이 적다. 업무 사이트가 몇 군데로 정해져 있고, 공공 사이트나 금융 사이트는 안정적으로 그대로 써야 하는 환경이면 이쪽이 더 맞는다.

선택 기준을 정리하면 이렇다. 브라우저 안에서만 해결하면 되는 사람은 확장 기능 쪽이 단순할 수 있다. PC 전체 접속을 한 번에 바꾸고 싶고 관리 부담을 감수할 수 있으면 전체 경로 변경 방식이 맞을 수 있다. 반대로 업무 사이트가 정해져 있고, 필요한 주소만 골라 다루고 싶다면 시크릿DNS 같은 접근이 더 현실적이다.

태양광설치에서 맞는 사람과 맞지 않는 사람은 분명히 갈린다

반복해서 접속하는 제조사 문서 사이트나 모니터링 주소가 있고, 그중 일부만 유독 느리거나 막히는 사람에게는 맞는다. 특히 현장과 사무실을 오가면서 같은 자료를 여러 번 열어야 하고, 자료 확인이 늦어져 설치 일정이나 감리 대응이 밀리는 상황이라면 써볼 이유가 있다. 로그를 보고 목록을 조금씩 손볼 수 있는 사람이라면 더 잘 맞는다.

반대로 인터넷 자체가 전반적으로 불안정한 환경, 즉 회선 품질이 낮거나 공유기 상태가 좋지 않은 곳에서는 기대를 크게 잡기 어렵다. 또 공공기관, 금융, 학교 계열 사이트를 주로 다루는 PC라면 예외 설정을 꼼꼼히 보지 않으면 오히려 불편할 수 있다. 목록 관리 자체가 번거로운 사람에게도 맞지 않을 수 있다.

태양광설치 실무 기준으로 보면 활용 장면은 분명하다. 마감 직전에 인버터 매뉴얼 최신본을 다시 확인해야 할 때, 해외 제조사 기술 페이지가 자주 멈출 때, 현장 PC와 사무실 PC에서 같은 주소를 반복해서 열어야 할 때 쓸 만하다. 반대로 하루에 한두 번 정도만 가끔 접속하고, 막히면 그냥 모바일로 보면 되는 수준이라면 굳이 손댈 필요는 없다. 결국 필요한 건 기능 수가 아니라, 반복해서 막히는 구간을 줄여서 작업 순서를 끊기지 않게 만드는지 여부였다.

공식 홈페이지로 가기