ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 불편한 공인인증서와 ActiveX, 완전 폐지는 어려울 듯 싶고 보완할 수 있는 방법은?
    Security 2017. 3. 14. 19:00
    반응형

    아래의 글은 디지에코에 보냈던 공인인증서와 ActiveX의 보완 방법에 대한 글이다. 디지에코는 가입을 해야만 글을 볼 수 있기 때문에 공유 차원에서 이 블로그에 내용을 공개한다. 실제 디지에코에 등재된 보고서는 이 글보다는 조금 더 정리가 되었다. 이 글은 초기 원고이기에 좀 거친(?) 부분이 있음을 미리 알려드리니 감안하고 보시길 바란다.


    3월 초에 들어 국내 ICT 업계에서 가장 화두가 되는 것은 인공지능, 커넥티드 자동차, 자율주행 자동차, 가상현실 등과 같이 CES 2017이나 MWC 2017에서 나왔던 기술이 아닐 것이다. 2017년 3월 2일에 더불어민주당의 유력 대선후보인 문재인 전 대표가 대선 공약으로 공인인증서와 ActiveX를 완전히 폐지하겠다고 얘기한 사건일 것이다. 지난 십 수년간 금융 서비스나 결제 서비스, 그리고 공공 서비스 등 은행권과 공공기관의 서비스에서 필수적으로 사용되어 왔던, 그리고 많은 사람들이 귀찮고 짜증난다고 아우성을 쳤던 그 공인인증서와 ActiveX를 제대로 없애겠다는 것이다. 그리고 이 얘기에 수많은 사람들이 만세를 불렀다. 물론 보안 전문가들은 우려의 시선을 보내기도 했고 말이다.


    ‘정보통신기술 현장 리더들과의 대화’에서의 문재인


    실제로 공인인증서와 ActiveX에 대한 개선은 수년전부터 진행되어 왔다. 현 정부의 천송이 코드 사태로 인해 본격화되기는 했지만 이전 정부부터 공인인증서의 사용을 기존의 ActiveX 뿐만이 아니라 다양한 방법으로 사용할 수 있도록 제도 개선 및 업체들의 노력들이 진행되어 왔다. 하지만 현재에 와서는 ActiveX가 아닌 다른 방식으로 공인인증서를 사용하도록 되었는데 방법만 바뀌었을 뿐 사람들이 느끼는 체감 온도는 무척이나 낮았다. 편해졌다는 것을 별로 못 느꼈다는 얘기다. ActiveX를 이용하는 것을 실행파일 형식(.exe 파일)을 이용하는 것으로 바뀌었을 뿐이며 실제로 웹브라우저에서 사용되는 방식은 기존과 동일하다는 것이 문제다. 이런 상황을 어떻게든 없애 보겠다는 것이 문재인 전 대표의 ICT 공약인 것이다.


    일단 결론을 먼저 얘기하자면 현재의 오프라인 계약 관행이 지속되는 한 완전 폐지는 어렵다는 것이다. 이유는 아래에 얘기를 하겠다. 좀 길어질 수 있으니 양해 부탁 바란다.


    공공의 적이 된 공인인증서와 ActiveX


    공인인증서와 ActiveX가 왜 이리도 많은 사람들의 공공의 적이 되었을까? 그것은 공공기관(대표적으로 민원24 사이트) 서비스나 인터넷뱅킹을 PC의 웹브라우저로 실행하게 되면 금방 이유를 알게 된다. 인터넷뱅킹을 예로 한번 들어보자. 어느 은행 서비스에 들어가서 인터넷뱅킹을 하기 위해서는 실행되기 전에 필수적으로 설치를 해야 하는 프로그램들이 있다. 웹브라우저에서 동작되기 때문에 보통 웹브라우저에서 사용할 수 있는 프로그램으로 플러그인 방식으로 설치가 된다. 그리고 국내의 경우 아직도 많은 서비스가 MS의 Windows OS 기반의 Internet Explorer 웹브라우저(이하 IE) 위에서 동작하도록 되어 있고 그렇기 때문에 IE의 플러그인인 ActiveX 형식으로 된 프로그램을 설치하게 된다. 어느 은행 서비스든 인터넷뱅킹을 하기 위해서는 거의 비슷하게 설치되는 ActiveX가 바로 키보드 보안, 안티 바이러스(백신), 구간 암호화 모듈이다. 그리고 거기에 공인인증서를 관리하는 모듈이 설치가 된다. 단지 인터넷뱅킹을 하기 위함 인데, 그리고 송금이 아닌 내 잔고를 보려고 하는 수준인 데도 불구하고 기본적으로 앞서 얘기한 다양한 모듈들이 설치가 된다.


    공인인증서를 사용하기 위해 설치해야 하는 보안 모듈들


    그런데 인터넷뱅킹을 실행하기 위해 앞서 언급한 ActiveX로 된 모듈들이 설치가 되는 이유는 안전한 거래를 위한 보안 때문이다. 인터넷뱅킹은 우리가 은행에 들어가서 창구에 앉아서 은행원과 마주 앉아서 하는 대면작업이 아닌 PC를 통해 은행에 가지 않고 은행원도 보지 않고 작업을 하는 비 대면작업이다. 대면작업의 경우 바로 눈 앞에서 직접 본인을 인증할 수 있고 안전하게 돈을 건네고 입금을 하거나 송금을 하고 또 인출을 할 수 있다. ATM을 이용해서 입, 출금, 송금을 하는 경우에도 카드의 소지 자체가 본인을 대표한다고 할 수 있다. 하지만 카드도 없고 바로 앞에서 은행원이 나를 인증하거나 인출한 돈을 나 한테 직접 건네 주는 것이 아닌 인터넷을 통해서 입, 출금 및 송금을 하려고 하다 보니 사용자 입장에서는 비 대면작업이지만 대면작업과 동일한, 동일하지 않더라도 거의 비슷한 수준의 보안을 요구하게 된다. 그렇다 보니 본인을 인증할 때 ID와 패스워드를 입력하는데 그 패스워드를 중간에 가로채지 못하게 키보드보안을 넣는 것이고 본인의 PC와 인터넷뱅킹의 서비스 서버 사이에 통신 내용을 가로채 조작하는 것을 막기 위해 구간 암호화를 넣는 것이다. 또한 사용자의 PC에 악성코드가 있으면 사용자가 입력하는 내용을 가로챌 수도 있으니 백신을 설치하는 것이다. 이런 안전장치를 한 이후에 공인인증서를 통해 인증하는 기능을 실행하도록 하는 것이다. 실제로 앞서 얘기한 모듈들은 ICT 업계에서는 보안 솔루션 카테고리에 들어가고 있고 취급하고 있다.


    하지만 불편하다. 웹브라우저에서 간단하게 처리할 수 있는 작업을 하기 위해 시작 전부터 저런 모듈들을 설치해야 한다. 또 설치하고 실행되면서 PC의 시스템 자원을 어느정도 소비하기 때문에 성능저하도 일어난다. 무엇보다 대다수가 ActiveX 기반으로 보안 모듈들이 만들어졌기 때문에 Windows OS에서만 동작이 되며 구글 크롬이나 모질라의 파이어폭스, 애플의 사파리 등 IE를 제외한 나머지 웹브라우저에서 사용할 수 없다. 물론 최근에 와서는 ActiveX가 아닌 다른 웹브라우저에서도 해당 웹브라우저에 맞는 플러그인으로 이런 보안 모듈들이 만들어져서 배포되고 있기 때문에 사용에 큰 불편은 없다. 하지만 여전히 Windows OS가 아닌 애플의 MacOS나 리눅스 등에서는 사용하는 것이 불가능하다. 즉, 성능저하도 있고 OS도 가리는 데다가 불필요하게 설치하는 과정 자체도 짜증나고 또 간혹 설치 중에 문제가 생겨서 제대로 동작을 안하는 경우도 허다하다. 거기에 뒤에서도 다루겠지만 공인인증서의 관리 방식도 일반 웹브라우저에서 사용하는 인증서 관리 방식과 다른 별개의 방식을 채택하고 있기 때문에 관리 방식 자체도 문제가 있다. 이런저런 이유들 때문에 사람들의 공공의 적이 되어버린 것이 공인인증서와 ActiveX다.


    하지만 생각을 해봐야 할 부분이 있다. 앞서 언급했던 것처럼 공인인증서를 사용하기 위해 수많은 ActiveX로 된 보안 모듈을 설치해야 하는 것으로 인해 공인인증서와 ActiveX를 동일시 생각하는 경우가 있다. 하지만 공인인증서와 ActiveX는 별개의 사안으로 봐야 한다. 공인인증서를 사용하기 위해서 어쩔 수 없이 ActiveX를 사용했을 뿐이다. 그리고 요즘은 ActiveX가 아닌 다른 웹브라우저의 플러그인으로도 공인인증서를 사용할 수 있다. 즉, 공인인증서와 ActiveX를 같은 레벨로 보고 문제제기를 하면 안되고 서로 별개로 생각하고 공인인증서를 보완하는 방법과 ActiveX가 아닌 다른 방법을 통해서 공인인증서를 효율적으로 사용할 수 있는 방안을 마련하는 것이 옳다. 무조건 없애는 것은 그렇게 좋아 보이지는 않는다.


    공인인증서의 구조 및 역할


    공인인증서는 전자서명법과 전자정부법을 기초로 하여 만들어진 본인확인용 인증서다. 비 대면 온라인 방식의 전자상거래에서 상대방과의 계약서 작성, 신원확인 등에 전자서명이 필요한데 그 전자서명을 공인인증서로 할 수 있으며 동시에 전자서명을 생성한 사람의 신원을 확인해주는 것이 공인인증서의 역할인 것이다. 한마디로 전자신분증 역할과 동시에 전자인감도장의 역할을 한다고 보면 된다.


    공인인증서는 공개키 기반 구조(PKI)로 되어 있는데 일반적으로 PKI는 전자서명을 생성하고 검증하는데 사용되는 개인키와 공개키를 안전하게 나눠주는 역할을 담당하는 신뢰할 수 있는 인증기관의 존재를 전제조건으로 하고 있으며 공인인증서 역시 PKI 구조를 그대로 가져와서 적용하고 있다. 참고로 PKI 기반의 인증서는 서버인증서와 개인인증서로 나눌 수 있으며 공인인증서 역시 서버인증서와 개인인증서를 모두 사용할 수 있지만 국내에서 사용하는 대다수의 웹브라우저가 공인인증서의 서버인증서를 신뢰하지 않기 때문에 개인인증서로만 사용되고 있는 현실이다. 그리고 앞서 언급했듯 공인인증서 자체의 가장 큰 문제는 공인인증서와 인증을 위해 필요로 하는 개인키의 파일 양식은 국제표준(X.501)을 따르고 있지만 그 파일들이 보관, 저장 등 관리되는 위치와 방법이 독특하여(NPKI 폴더나 GPKI 폴더가 생기며 그 안에 저장한다) 웹브라우저가 제공하는 표준방식이 아닌 별도의 방식을 이용하기 때문에 웹브라우저 자체에서는 관리가 안되며 ActiveX 등의 별도의 플러그인을 통해서만 사용할 수 있다는 점이다. 즉, 공인인증서는 형식 자체는 표준이지만 방법은 비 표준이다. 여기서부터 문제가 시작된다고 보면 된다.



    참고로 현재의 법은 공인인증서의 사용을 강제하지 않는다. 2014년 9월 30일에 전자금융거래법 개정안이 국회 본회의를 통과했고 2016년 10월 15일에 시행이 되었다. 또한 정부 및 공공기관의 서비스에서도 공인인증서의 사용을 반드시 필수로 강제하지는 않는다. 전자정부법 제10조(민원인 등의 본인 확인)는 ‘전자서명법 제2조 제3호에 따른 공인전자서명이나 국회규칙, 대법원규칙, 헌법재판소규칙, 중앙선거관리위원회규칙 및 대통령령으로 정하는 방법으로 그 신원을 확인할 수 있다’고 명시했다. 또, 전자서명법 제18조의2(공인인증서를 이용한 본인확인)는 ‘다른 법률에서 공인인증서를 이용해 본인임을 확인하는 것을 제한 또는 배제하고 있지 아니한 경우에는 이 법의 규정에 따라 공인인증기관이 발급한 공인인증서에 의하여 본인임을 확인할 수 있다’고 나온다. 즉, '하여야 한다'식의 강제조항이 아니다. 다만, 이것을 역으로 생각하면 공인인증서를 쓰지 말라는 조항도 아니기 때문에 정부 및 공공기관에서는 기존에 구축해서 잘 운영해오는 것을 바꾸는 위험을 감수하지 않기 위해 기존 방식인 공인인증서를 이용한 인증을 계속 진행하고 있는 것이다.


    앞서 언급했듯 공인인증서의 존재의 이유는 신원확인이 있고 또 부인방지의 기능이 있다. 부인방지는 내가 어떤 액션을 취했는데 그 액션을 취했다는 것을 반박하지 못하게 하는, 즉 내가 한 행동에 대해서 공증을 하는 그런 기능이다. 즉, 공인인증서로 전자서명을 하거나 인증을 한 후에 어떤 문제가 생기게 되면 그 문제가 나로 인해 생겼다는 것을 반박하지 못하게 하는 역할을 담당하는 것이 공인인증서의 또 다른 역할이다. 앞서 신원인증과 동일선상에서 해석할 수 있는 부분이다. 내가 서명한 것이니 내가 책임을 진다는 것을 공증하는 역할이라는 얘기다. 이런 막강한 기능이 있기 때문에 공공기관은 물론이고 은행권 서비스나 각종 전자상거래 서비스에서 공인인증서를 마치 필수요소처럼 이용하는 것이다. 시스템적으로 문제가 생겨서 뭔가 안좋은 일이 생겼더라도 공인인증서의 부인방지 기능으로 인해 고객의 잘못으로 떠넘길 수 있다는 부분이 서비스 제공자들에게는 마치 책임을 회피할 수 있는 면책특권처럼 여겨졌기 때문에 많이 도입을 했던 것이 사실이다. 그리고 그런 공인인증서를 사용하기 위해, 그리고 잘 관리하기 위해 서비스 제공자들은 다양한 공인인증서를 보안할 수 있는 모듈들을 설치하도록 강제를 하고 있는 것이다. 앞서 언급한 다양한 ActiveX를 이용한 키보드 보안, 구간 암호화, 안티 바이러스 등의 모듈은 공인인증서를 안전하게 사용할 수 있게 보조해주는 역할을 하며 이 정도면 서비스 사업자 입장에서는 해줄 수 있는 것들은 다 해줬다고 생각할 수 있다고 말하는 것이다. 


    철저히 사업자, 서비스 제공자 논리에 의해 시스템이 만들어지고 소비자에게 사용을 강요하는 상황이 되어버린 것이 현재의 공인인증서 시스템과 제도다. 그런 이유로 많은 사람들이 불편해하고 있으며 유력 대선후보도 이것을 없애겠다고 ICT 공약으로 까지 내세운 것이다. 하지만 공인인증서의 완전 폐지는 현실적으로 어려운 것들이 많다. 일단 우리나라의 계약 관행을 먼저 살펴보면 개인의 경우 부동산 거래 등의 금액 규모가 큰 거래에는 반드시 인감증명서를 필수적으로 넣도록 하고 있다. 기업간의 거래 역시 인감증명서가 필요하다. 인감증명서를 넣는 이유는 앞서 언급한 부인방지의 역할 때문이다(신원보증은 주민등록등본 정도로도 충분하다고 본다). 즉, 오프라인의 계약에는 인감증명서를 필요로 하며 많은 사람들이 오프라인과 온라인의 형평성을 고려하여 온라인에서도 오프라인의 인감증명서와 동등한 수준의 부인방지 장치를 요구한다. 그리고 그 역할을 현재는 공인인증서가 담당하고 있다. 이런 관행이 개선되지 않는 이상 공인인증서, 공인인증제도를 완전 폐지하겠다는 것은 어려운 일이라고 본다. 그렇다면 어떻게 해야 할까?


    불편한 공인인증서 사용 방법을 줄이기 위해서는?


    일단 공인인증서의 사용 용도를 제한할 필요가 있다. 지금은 인터넷뱅킹과 공공기관 서비스에서 공인인증서를 사용하고 있는데 보통 로그인 단계부터 공인인증서를 통한 로그인을 진행한다(물론 ID와 패스워드를 통한 로그인도 함께 제공하고 있지만 대부분 공인인증서를 통한 로그인을 쓴다고 생각한다). 즉, 단순한 본인인증 과정부터 공인인증서를 이용하는데 그렇게 하지 말고 일반적인 기능을 사용하는 경우라면 ID와 패스워드만으로도 로그인이 가능하도록 만들고 공인인증서를 사용하지 않도록 하면 된다. 그리고 우리가 주민센터에 가서 뭔가 서류를 떼어올 때는 신분증이 필요한데 그런 신분증을 필요로 하는 작업에만 공인인증서를 사용하도록 하면 된다. 즉, 주민등록등초본 등 관공서에서 본인의 확인이 필요한 상황에서만 제공하는 서류를 출력하고자 할 때만 공인인증서를 사용하도록 사용 범위를 제한하면 된다.


    인터넷뱅킹 역시 마찬가지다. 로그인부터 시작하여 통장 잔고를 보거나 거래내역을 보는 것도 다 공인인증서를 필요로 하는데(물론 ID와 패스워드로도 가능하다) 그렇게 하지 말고 송금(인터넷뱅킹은 입, 출금 기능이 없다)이나 대출, 통장개설 등의 본인확인을 필요로 하는, 또 부인방지를 필요로 하는 상황에서만 공인인증서를 사용하도록 제한을 두면 된다. 이 얘기는 지금은 인터넷뱅킹 사이트나 공공기관 서비스에 접속할 때부터 ActiveX나 다양한 플러그인을 설치하라고 나오는데, 아니면 로그인을 할 때 ID, 패스워드로 로그인을 함에도 불구하고 공인인증서 보안을 위한 모듈을 설치하라고 나오는 것이 문제가 되며 시작할 때부터가 아닌 실제로 공인인증서를 사용하려고 할 때 모듈을 설치하도록 유도하는 것이 맞다고 보는 것이다.


    두 번째로는 공인인증서 자체는 표준을 따른다고 하지만 관리 방식이 비 표준이기 때문에 관리 방식을 표준으로 변경해야 한다. 각 웹브라우저마다 각기 자신들이 정한 인증서 관리 방법이 있다. 그래서 HTTPS 보안 통신을 위한 서버 인증서를 받게 되면 웹브라우저에서 알아서 보관하고 관리한다. 별도의 플러그인이 필요 없다. 하지만 공인인증서는 관리방식을 자신들이 정한 방법으로 강제를 한다. 이것을 바꿔야 한다. 공인인증서도 웹브라우저에서 제공하는 인증서 관리 방식처럼 관리되도록 변경되어야 한다. 파일 방식 자체는 다른 서버 인증서나 개인 인증서와 같이 표준을 따르기 때문에 크게 문제가 되지 않을 것으로 보인다. 다만 인증서의 암호화 방식을 비 표준 암호화 방식을 사용하게 되면 문제가 되기 때문에 그것 역시도 국제 표준 암호화 방식으로 바꿔야 할 필요가 있다.


    이것이 해결되면 통신 보안 방식의 비 표준 문제가 해결될 수 있다. 공인인증서를 사용하기 위해 설치되는 구간 암호화 모듈은 일반적으로 우리가 보안 통신에서 사용하는 HTTPS 통신 방식을 그대로 사용한다. 그런데 왜 웹브라우저에서 제공하는 HTTPS 방식이 아닌 별도의 플러그인을 이용해야 하는가 하면 앞서 언급한 것처럼 관리 방식이 비 표준이기 때문에 그렇다. 그런데 공인인증서 관리 방식을 웹브라우저에서 제공하는 표준 방식으로 변경한다면 구간 암호화를 사용할 필요가 없다. 그 얘기인 즉, 별도의 플러그인을 따로 설치할 필요가 없다는 얘기다. 앞서 언급한 부분이 적용이 되면 통신 보안 방식은 자동으로 해결될 수 있다.


    세 번째로는 인증 방식이다. 공인인증서의 인증 방식은 패스워드 입력 방식이다. 그래서 사용자가 패스워드 입력하는 것을 중간에 가로채서 조작하는 것을 방지하기 위해 키보드 보안을 넣는 것이다. 그러면 패스워드 입력 방식이 아닌 다른 방식을 채택하도록 하면 된다. 일반적으로 2 채널 보안 방식을 많이 이용하는데 패스워드를 입력하고 그리고 또 다른 방법으로 한번 더 뭔가를 입력하는 방식을 많이 이용한다. 공인인증서의 패스워드 방식도 그런 방식으로 2 채널 보안 방식을 적용하면 어떨까 하는 생각을 해본다. 이메일 인증과 SMS 인증 방식이 있고 아니면 스마트폰의 지문인식을 이용하거나 홍채인식을 이용하는 방법도 존재한다. 즉, 공인인증서의 패스워드를 입력한 후 사용자가 기존에 설정했던 2채널 보안 방식으로 한번 더 인증을 시도하는 것이다. 이메일 인증이나 SMS 인증은 OTP(One Time Password) 방식으로 매번 다른 인증 값을 제공하여 인증하도록 하며 인증 값이 유출이 되더라도 다음에 다시 시도하면 다른 인증 값이 오기 때문에 인증 값 유출에 대한 불편이 없다. 지문인식이나 홍채인식의 경우에는 해당 기능을 제공하는 스마트폰이 존재해야 한다는 전제조건이 있지만 간편하면서도 더 안전하기 때문에 충분히 매리트가 있는 방법이라는 생각이 든다. 즉, 공인인증서의 인증 방식을 지금의 단순한 패스워드 한번의 입력보다는 2 채널 보안을 적용하는 것이 어떨까 하는 생각이 든다. 아니면 패스워드 입력이 아닌 처음부터 OTP 방식을 이용하는 것도 방법일 수 있다.


    마지막으로는 공인인증서와 병행해서 사용할 수 있는 인증방식을 지속적으로 개발해야 한다는 것이다. 공인인증서의 사용 용도를 제한하고 줄이게 되면 기존에 공인인증서를 사용해서 작업했던 부분에 대해서 대체할 수 있는 인증방식이 필요하다. 그리고 그 인증방식은 이미 앞서 언급했던 것처럼 생채 인증이 될 수도 있고 2 체널 보안이 될 수도 있다. 그리고 최근에 본인 인증을 본인 명의의 신용카드로 가능한 방법도 나왔는데 그 방법을 이용해도 된다. 이 방법은 본인 명의의 신용카드를 NFC 기능이 탑재된 스마트폰에 접촉하거나 스마트폰 전용 앱에 신용카드를 등록한 뒤 비밀번호만 입력하는 방식으로 본인 확인이 가능한 서비스로 언론에서는 방통위가 개발한 것처럼 소개하지만 한국 NFC에서 개발한 기술이다. 이 방법을 통해 본인인증을 대신하여 공인인증서와 병행해서 사용한다면 공인인증서의 의존도를 확 줄일 수 있다고 생각한다.


    관행이 계속되는 한 공인인증서 폐기는 현실적으로 불가능


    인감증명서


    많은 사람들이 지문인식이나 홍채인식 등의 생채인식으로 공인인증서를 대체할 수 있다고 얘기를 한다. 하지만 지문이나 홍채인식은 공인인증서 자체를 대체하는 것이 아닌 공인인증서를 인증하기 위한 패스워드를 대체하는 것이다. 공인인증서 안에는 인증에 필요한 다양한 정보들이 있는데(인증서라는 것 자체가 많은 정보를 담고 있다) 생채 정보는 그런 정보를 담고 있지 않으며 본인임을 확인하는 수단으로 이용할 수 있는 것이지 그것이 인증서를 대체한다고 할 수 없기 때문이다. 보통 서류에 도장 대신 지문을 찍는 경우가 있으며 그것이 도장을 대신하여 본인임을 확인하고 부인방지를 하는데 사용되곤 한다. 하지만 지문인식이나 홍채인식은 서류에 도장 대신 찍는 지문의 개념이 아니다. 전자서명이 아니라는 얘기다. 그렇기 때문에 공인인증서를 대체한다고 보기는 어렵다. 즉, 전자서명을 필요로 하는 서비스들이 현재 많으며 전자서명의 범위를 어디까지 보느냐에 따라 틀릴 수 있지만 현재의 전자서명의 적용 범위는 법적 효력을 갖기 때문에 공인인증서만큼의 법적 효력을 지닌 다른 것이 나오지 않으면 공인인증서를 완전 폐기한다는 것은 현실적으로는 어렵다고 본다. 하지만 앞서 언급했던 것처럼 사용처를 제한하고 방식을 표준으로 바꾸면서 불필요한 플러그인을 설치하는 것을 없앤다면 공인인증서 무용론, 폐지론은 아주 없어지지는 않겠지만 한풀 꺾이지 않을까 하는 생각을 해본다.

    반응형

    댓글

Designed by Tistory.