처음엔 그냥 켜두면 끝날 줄 알았는데, 중간에 자꾸 손이 갔다
왜 굳이 이걸 만져보기 시작했냐면
처음 시크릿DNS를 건드린 건 거창한 이유는 아니었습니다. 회사에서 쓰는 몇몇 사이트가 이상하게 어떤 날은 잘 열리고, 어떤 날은 로딩이 길어지고, 가끔은 접속 자체가 튕기는 일이 있었어요. 브라우저 문제인가 싶어서 캐시도 지워보고, 네트워크 어댑터도 껐다 켰는데 딱히 달라지는 게 없었습니다.
그때 제일 먼저 든 생각은 “이거 DNS 쪽 문제 아닌가” 정도였어요. 사실 DNS는 평소엔 거의 신경 안 쓰는 영역인데, 한번 꼬이면 체감이 묘하게 큽니다. 페이지가 아예 안 뜨는 것도 아니고, 이상하게 한 박자씩 늦는 느낌이 계속 나니까요. 그래서 처음엔 운영체제 기본 DNS만 바꿔볼까 하다가, 어차피 만질 거면 조금 더 안전한 쪽으로 가보자는 생각으로 시크릿DNS를 써봤습니다.
처음 끌린 건 DNS over HTTPS 쪽이었어요. 설명만 보면 “DNS 요청을 HTTPS로 감싸서 보낸다” 정도인데, 실무에서는 이게 생각보다 마음이 편합니다. 적어도 중간에서 DNS를 훔쳐보거나 건드릴 가능성을 줄여준다는 점이 분명했고, 특히 공용망이나 외부 회의실 와이파이 쓸 때는 이런 게 괜히 신경 쓰이거든요.
설치하고 바로 편해질 줄 알았는데 첫날부터 막혔다
솔직히 처음엔 그냥 설치하고 기본값으로 켜면 끝일 줄 알았습니다. Cloudflare 기반으로 바로 돌아가니까 큰 설정 없이도 될 거라고 생각했거든요. 실제로 초반엔 꽤 멀쩡했습니다. 평소 열던 사이트들도 잘 열렸고, 체감상 응답도 나쁘지 않았어요.
문제는 사내에서 쓰는 내부 서비스 비슷한 페이지였습니다. 외부 웹은 잘 되는데 특정 주소만 유독 접속이 불안정했어요. 처음엔 사이트 문제라고 넘겼는데, 끄면 되고 켜면 안 되는 걸 몇 번 반복하고 나서야 시크릿DNS 쪽 설정을 의심하게 됐습니다.
여기서 첫 번째로 좀 막혔어요. 뭘 하려고 했냐면, 그냥 전체 트래픽은 안전하게 두고 문제 있는 도메인만 예외로 빼고 싶었습니다. 그런데 처음에는 화이트리스트 개념을 제가 반대로 이해해서, 보호할 대상을 넣어야 하는데 우회할 대상을 넣는 식으로 만져버렸습니다. 결과적으로는 “왜 설정했는데도 그대로지?” 상태가 됐고, 한참을 엉뚱한 로그만 보고 있었어요.
그때 알게 된 게, 이런 도구는 기능 이름이 쉬워 보여도 실제 동작 방향을 먼저 확인해야 한다는 점이었습니다. 특히 특정 도메인만 다르게 처리하는 옵션은, 내가 머릿속으로 생각한 예외 처리 방식이랑 프로그램이 기대하는 방식이 다를 수 있어요. 이건 시크릿DNS만의 문제라기보다, 네트워크 툴 전반에서 자주 겪는 함정 같았습니다.
SNI 쪽은 좋다는 말만 듣고 건드렸다가 한 번 돌아갔다
시크릿DNS 얘기할 때 고급 SNI 기능을 많이 말하길래 저도 좀 궁금해서 만져봤습니다. SNI 단편화 같은 건 그냥 설명만 볼 때는 “보안적으로 더 낫겠구나” 정도였는데, 막상 켜보면 생각보다 영향 범위가 애매합니다. 모든 사이트에서 티가 나는 건 아니고, 일부 사이트에서만 미묘하게 연결이 느려지거나 인증 단계에서 이상한 반응이 보였어요.
이게 두 번째 시행착오였습니다. 기능이나 설정에서 막힌 첫 번째 경우와는 다르게, 이번에는 제 선택 자체가 좀 성급했던 쪽이에요. 정확히는 “좋다니까 일단 켜보자” 식으로 접근한 게 문제였습니다. 저는 원래 특정 도메인에만 써야 하는 걸, 초반에 범위를 넓게 잡아버렸습니다.
결국 몇몇 서비스에서 로그인 화면이 늦게 뜨거나, 간헐적으로 새로고침을 해야 다음 단계로 넘어가는 일이 생겼어요. 이쯤 되니까 보안 강화가 중요한 건 맞는데, 업무 도중에 한 번씩 끊기는 쪽이 더 거슬렸습니다. 그래서 다시 범위를 줄였습니다. 진짜 필요한 도메인만 넣고, 평소에 문제 없는 사이트들은 건드리지 않는 방식으로 바꿨죠.
여기서 느낀 건, 이런 기능은 “전부 적용”보다 “문제 생기는 구간에만 적용”이 훨씬 덜 피곤하다는 겁니다. 특히 실무에서는 안정성이 체감 우선이라서, 보안 옵션이 좋아 보여도 범위를 좁게 시작하는 게 낫더라고요.
로그를 보기 시작하니까 그제야 어디가 꼬였는지 보였다
처음에는 로그 기능을 거의 안 봤습니다. 그냥 잘 되면 쓰고, 안 되면 끄면 된다고 생각했어요. 그런데 도메인별로 반응이 다르고, 같은 사이트도 시간대에 따라 다르게 느껴지니까 결국 기록을 보기 시작했습니다.
이 부분은 생각보다 괜찮았습니다. DNS 활동이 남아 있으니까 최소한 “아예 요청이 안 나간 건지”, “나가긴 했는데 응답이 이상한 건지” 정도는 감이 오더라고요. 물론 이걸 본다고 네트워크 분석가처럼 다 해석할 수 있는 건 아니지만, 적어도 문제 범위를 줄이는 데는 충분했습니다.
실제로 한 번은 특정 페이지가 계속 느려서 브라우저 확장 프로그램 충돌까지 의심했는데, 로그를 보고 나서 DNS 응답 경로를 먼저 의심하게 됐어요. 그래서 브라우저 설정을 건드리기 전에 시크릿DNS 쪽 서버 설정을 조금 바꿔봤습니다. 기본 Cloudflare가 대체로 무난하긴 했지만, 제 환경에서는 다른 쪽이 더 안정적인 순간도 있더라고요.
이건 짧은 팁처럼 말할 수 있을 것 같습니다. DNS 도구를 쓸 때 느리면 무조건 프로그램 자체를 의심하기보다, 서버 조합이나 예외 처리 목록을 먼저 보는 게 빠를 때가 있어요. 특히 회사망, 집 공유기, 모바일 핫스팟을 왔다 갔다 하는 사람은 환경 차이가 꽤 크게 납니다.
안 되는 이유를 찾다가, 해결은 의외로 단순하게 갔다
한 번은 정말 좀 이상했습니다. 웹 브라우저에서는 어느 정도 되는데, 특정 앱 안의 웹뷰만 유독 불안정했어요. 처음엔 앱 자체 문제라고 생각해서 재설치도 해봤는데 그대로였습니다. 이때는 솔직히 “괜히 DNS까지 손대서 일을 키웠나” 싶었어요.
그래도 끄고 켜는 테스트를 몇 번 하다 보니, 시크릿DNS를 켠 상태에서만 증상이 심해진다는 건 분명했습니다. 그래서 왜 그런지 고민하다가, 앱 내 웹뷰는 브라우저보다 네트워크 예외 처리에 둔감할 수 있겠다는 생각이 들었습니다. 그때 떠올린 방법이, 아예 해당 서비스 도메인을 예외로 분리해보는 거였어요.
설정 바꾸고 바로 완전히 해결된 건 아니었지만, 적어도 로딩 실패 빈도는 확실히 줄었습니다. 여기서 재미있었던 건, 처음에는 더 강하게 보호하면 다 좋아질 줄 알았는데 실제로는 덜 건드리는 쪽이 더 안정적이었다는 점입니다. 이런 류의 도구는 “많이 켠다 = 무조건 좋다”가 아니라, 내 환경과 맞는 선을 찾는 과정에 가깝더라고요.
비슷한 경험은 VPN 쓸 때도 있었습니다. VPN은 경로 자체를 바꾸니까 해결되는 문제도 있지만, 일상 업무에서는 속도나 인증 문제가 더 크게 다가올 때가 많아요. 반대로 시크릿DNS는 전체를 갈아엎기보다 DNS와 일부 연결 보호에 집중하니까 덜 무겁다는 장점이 있었습니다. 다만 앱별 예외 처리는 VPN보다 직관적이지 않게 느껴질 때도 있었어요.
다른 방법들도 같이 써봤는데, 결국 남은 건 기준 하나였다
중간에 아예 운영체제 DNS 설정만 바꿔서 쓰는 방법도 다시 해봤습니다. 제일 단순하고 귀찮지 않으니까요. 그런데 이 방법은 손은 덜 가도, 제가 원했던 “조회 자체를 좀 더 안전하게 처리하는 느낌”은 약했습니다. 잘 될 때는 조용히 잘 되는데, 문제 생겼을 때 어디서 꼬였는지 파악하기가 더 어려웠어요.
브라우저 자체의 보안 DNS 기능도 잠깐 켰다가 껐습니다. 웹 브라우징만 보면 이쪽도 꽤 편한데, 결국 브라우저 밖에서 움직이는 프로그램이나 앱은 또 별개였습니다. 저는 업무 중에 브라우저만 쓰는 게 아니라 메신저, 전용 클라이언트, 간단한 API 테스트 툴도 같이 쓰니까 이게 애매했어요. 그런 면에서는 시스템 쪽에서 어느 정도 일괄로 다루는 시크릿DNS가 더 손에 맞았습니다.
대신 기준은 생겼습니다. 평소에 별문제 없고 속도만 중요하면 단순 DNS 변경이나 브라우저 보안 DNS도 충분하고, 공용망 사용이 잦거나 특정 차단/감시를 좀 더 신경 쓰는 환경이면 시크릿DNS 쪽이 확실히 체감이 있습니다. 다만 SNI 같은 고급 옵션은 처음부터 욕심내지 않는 게 낫겠다는 쪽으로 생각이 바뀌었습니다.
지금은 이렇게 쓰고 있는데, 아직도 약간 애매하다
지금은 기본 DoH 설정을 중심으로 두고, SNI 관련 기능은 필요한 도메인만 최소한으로 넣어서 쓰고 있습니다. 처음처럼 이것저것 한꺼번에 켜두진 않아요. 그렇게 해보니 적어도 업무 중에 “왜 갑자기 이것만 안 되지?” 하는 순간은 줄었습니다.
좋아진 점은 분명합니다. 외부 네트워크에서 쓸 때 마음이 좀 편하고, DNS 관련해서 이상한 지연이 생길 때 확인할 수 있는 수단이 생겼어요. 예전엔 그냥 사이트 탓, 회선 탓 하고 넘겼던 걸 이제는 조금 더 구분해서 볼 수 있게 됐습니다.
반대로 애매하게 남은 부분도 있습니다. 모든 환경에서 무조건 더 빠르다고 말하긴 어렵고, 특정 서비스는 여전히 예외 처리가 필요했습니다. 또 이런 설정은 한 번 잡아두면 끝나는 게 아니라, 네트워크 환경 바뀌거나 서비스 쪽 정책 바뀌면 다시 손봐야 할 수도 있겠더라고요.
그래도 “설치만 하면 끝” 같은 기대만 버리면 꽤 쓸 만했습니다. 특히 직접 조금씩 만져가며 내 환경에 맞추는 걸 싫어하지 않는 사람이라면 더 그렇고요. 저처럼 괜히 한 바퀴 돌아가는 구간은 있을 수 있는데, 그 과정에서 기준이 생기는 건 맞았습니다.
아직도 저는 이게 완전히 정착한 상태라고 보진 않습니다. 어떤 사람은 그냥 브라우저 보안 DNS로 충분할 수도 있고, 어떤 사람은 아예 다른 도구가 더 편할 수도 있을 것 같아요. 저도 더 편한 조합이 나오면 또 바꿀 수 있을 것 같습니다. 비슷하게 써본 사람 있으면, 어떤 설정에서 덜 불편했는지 그런 경험은 좀 궁금하긴 합니다.
