|
|
|
|
자동 소스 코드 분석기 |
| 간편한 보안 S/W 개발, “만병 통치약 아니다”
‘포티파이 SCA’ 최고 점수 … 보안 중심 SDLC 일부로 이용돼야 |
 |
2007년 07월 31일 00:00:00 |
|
 |
|
|
업체들은 소스 코드 보안 분석기를 이용함으로써 비즈니스의 성벽을 튼튼히 하고 소중한 데이터를 보호할 수 있다고 주장하고 있다. 하지만 이들만으로 방어벽이 충분할까, 아니면 범죄자들이 여전히 배회하고 있는 와중에 단순히 IT 스태프를 달래는 것에 불과할까? 그 진실의 세계로 직접 들어가 보자.
공격자가 단순히 명성이나 영예를 찾아다니고, 애플리케이션 보안이 다른 누군가의 문제였던 시절을 기억하는가? 마이크로소프트나 오라클 같은 대형 타깃들이 이들의 마음에 불을 댕긴다. 엔터프라이즈 IT에서 해야 할 일이라고는 정기적으로 패치를 적용시키고 적절히 방화벽 구성이 유지되도록 하는 것뿐이었다.
하지만 이 모든 것들은 옛날 얘기다. 회사 네트워크 크래킹은 더 이상 아이들의 게임이 아니며, 수익성 좋은 범죄 성장 산업이다. TJX컴퍼니즈로부터 4천560만 개의 신용카드와 직불카드 번호를 훔친 공격자들은 적어도 10개월 동안 검거되지 않을 정도로 충분히 전문적이었다. 한편 마이크로소프트 같은 주요 소프트웨어 업체들은 보안 프랙티스를 개선했는데, 이로 인해 니치와 내부 개발된 소프트웨어와 웹 애플리케이션이 해커들의 눈에 그대로 드러났다.
애플리케이션 보안 프로세스 통합 필요
이제 엔터프라이즈 IT에서는 마침내 비보안 코딩 프랙티스로 인한 책임을 마침내 이해하고 있다. 2006 CSI/FBI 컴퓨터 범죄 및 보안 설문조사에 따르면, 2008년까지 가장 중요한 문제로 데이터 보호와 애플리케이션 소프트웨어 보안이 선정됐으며, 정책 및 규정 준수와 신원정보 절도/데이터 누출 방지 등이 그 뒤를 이었다.
만일, 회사 네트워크가 위험에 처해 있지 않다고 생각한다면, 대부분의 소프트웨어가 상용 배포판용으로 만들어지지 않았다는 사실을 고려하라. 이들은 내부적으로나, 혹은 특정 필요에 맞춘 계약에 따라 개발됐다. 특정 용도에 따라 개발된 애플리케이션은 역동적 사이트, SOA(Service Oriented Architecture) 및 전자상거래에서부터 비즈니스 프로세스 자동화 및 관리에 이르기까지 매우 다양한 비즈니스 프로세스에 대한 기본 틀을 제공한다. 하지만 이들은 또한 공격자가 될 수 있는 사람들에게는 타깃이 풍부한 환경을 제공하고 있기도 하다.
늘어나는 위협에 대응해, HIPAA나 PCI DSS(Payment Card Industry Data Security Standard) 같은 주요 규정준수 관련 표준들은 애플리케이션 보안 프로세스를 통합시키거나, 최소한 그 필요성을 언급하고 있다.
물론 규정이 있으면 시장에서도 움직임이 있기 마련이다. 이 경우에는 자동 소스 코드 분석 툴 업체들이 상용 소프트웨어 업체로부터 엔터프라이즈로 중심을 이동하고 있다. 이들은 자신들의 툴을 이용하면 회사의 개발자가 보다 안전한 소프트웨어를 만들 수 있으며, 규정준수의 부담을 덜 수 있다고 선전하고 있다.
그렇다면 과연 이들이 약속을 잘 지키고 있을까?
이것을 알아보기 위해, 우리는 세 가지 유명한 정적 소스 코드 분석기, 즉 포티파이 SCA(Fortify Source Code Analysis) 4.0, 클록워크(Klockwork) K7,5, 그리고 온스 랩스(Once Labs)의 온스 4.1 등을 시카고 네오햅시스 파트너랩으로 가져왔다. 커버리티(Coverity)에게도 프리벤트(Prevent) 분석기를 보내줄 것을 요청했지만 자원 부족을 이유로 거절당했다.
각 제품에는 저마다의 강점과 약점이 있지만, 어떤 것이든 성숙한 보안 프로세스에 유용한 보탬이 될 것이다. 그리고 사실 이 말 속에 우리가 하고 싶은 가장 중요한 요지가 담겨 있다. 즉 코드 스캐너는 얼마나 효과적이냐와 관계없이 전체 해답의 일부에 불과하다는 것이다. 보안을 우선순위에 놓이게 해주는 적절한 개발자 교육이나 SDLC(Software Development LifeCycle)가 없이는 어떤 툴도 네트워크를 보호해주지 못한다. 익숙한 말인가?
우리는 오랫동안 어떤 경계선도 없다고 인지하는 심층방어전략을 지지해 왔다. 보안 그룹에서는 호스트 침입 방지, NAC 및 데이터베이스 유출 방지 등과 같이, 공격자들이 민감한 정보에 액세스를 얻기 이전에 방어선 바깥쪽으로 스며들지 못하게 막고자 하는 기술들을 이행해 왔다.
하지만 이것으로는 더 이상 충분치가 못하다. 엔터프라이즈 IT는 이제 내부 개발자나 계약직 개발자와 협력해 보안을 제 1순위로 생각해야 한다. 보안 전문가들이 주로 비즈니스에서 요구하는 기능성을 제공하는 데 관심이 있는 개발자들과는 다른 시각을 갖고 있다 하더라도 애플리케이션 개발 그룹과 보안 그룹은 모두 CIO 아래 있기 때문에 이러한 정치적인 문제는 극복될 수 있다.
누구나 사용할 수 있다(?)
거의 모든 다른 IT 업체들과 마찬가지로, 애플리케이션 보안 스캐너 제조업체들도 규정준수를 이용한 돈벌이에 가세하고 있으며, QA 매니저에서부터 프로젝트 책임에 이르는 모든 사람들이 자신들의 웨어에서 가치 있는 정보를 제공할 수 있게 해준다고 주장하고 있다.
하지만 이것은 선전용 문구지 현실은 아니다. 이런 툴들은 개발자와 소프트웨어 보안 전문가용으로 만들어진 것들이다. IT 일반인들이 소스 코드 스캐너를 운용할 수 있다는 주장은 마치 외국어도 전혀 모르고 주제에 관해서도 알지 못하는 사람이 외국어로 된 문서에서 철자 검색기를 사용할 수 있다는 말과 마찬가지다. 이런 툴은 많은 레벨에서 유용한 결함 추적 기능을 제공하지만, 이 모든 것은 보안에 정통한 개발자에 의해 먼저 분석이 되는 결과에 따라 좌우된다.
궁극적으로 말하자면, 소프트웨어를 보안할 수 있는 방식을 자동화할 수는 없다. 분석 툴을 어떤 식으로 조합하든 사용자가 갖고 있는 보안 지식만큼만 효과를 발휘할 수 있기 때문이다.
보안코드 만들기(Writing Secure Code, Microsoft Press, 2002)의 공저자이자 마이크로소프트 현재 보안 상태의 수석 아키텍트들 중 한 사람인 마이클 하워드는 자신의 블로그에 다음과 같은 글귀를 남겼다. ‘잘 알지 못하는 개발자+뛰어난 툴=아주 약간 더 나은 보안 코드.’
공격에 저항할 수 있는 애플리케이션을 만들기 위해서는 개발자가 SDLC에 맞게 근본적인 조정작업을 해야 한다. 이를 위해 마이크로소프트의 SDL(Security Development Lifecycle) 등 문서화된 프로세스를 활용하기를 권한다. 오픈 웹 애플리케이션 시큐리티 프로젝트(Open Web Application Security Project)의 CLASP(Comprehensive Lightweight Application SEcurity Process)와 내셔널 사이버 시큐리티 디비전(National Cyber Security Division)의 ‘빌드 시큐리티 인(Build Security In)’ 포털에 있는 기술 전반의 자료들을 참고하라.
모든 업체들이 경쟁 업체를 이기기 위해 계속 노력함에 따라 분석 기술도 또한 빠른 속도로 발전하고 있다. 이것은 고객에게는 좋은 소식이지만 시장을 역동적으로 변화하게 만든다. 즉 이 기술은 분명 파일럿 테스트를 통해 특정 자동 소스 코드 분석기가 자신의 애플리케이션 및 개발 환경에 맞는지를 확인해야 할 필요가 있는, 그런 기술이다.
분석 툴을 멀티플레이어라고 생각하라. 보안 의식이 있는 개발자의 손에서, 그리고 적절한 지원 프로세스를 갖췄을 때, 좋은 코드 분석기는 회사에서 훨씬 더 많은 보안 소프트웨어를 만들어낼 수 있게 도와준다. 하지만 개발자가 보안 지식이 전혀 없고, 이들을 지원하는 프로세스가 전혀 없을 경우에는 돌아오는 혜택도 전혀 없다.
수동 분석의 한계
어떠한 실세계 프로그램에 버그가 전혀 없는 것을 보기는 불가능할 것이다. 그리고 보안 취약성이 특정 종류의 소프트웨어 버그라고 생각할 때는 아주 불리한 상황이라고 할 수 있다.
하지만 과학자와 수학자들이 들어가기 겁나 하는 곳에 엔지니어와 개발자들이 달려들지 않은 적이 언제 있었는가. 결국 소프트웨어가 실제로 효과적으로 보안이 되고 있는 한은, 이것이 보안이 된다고 입증할 필요가 없다. 그리고 이것이 바로 보안 전문가들이 자동 정적 소스 코드 분석기(automated static source-code analyzer)와 같은 소프트웨어 보안 기술을 고안해내느라 수십 년을 보낸 이유기도 하다.
정적 소스 코드 분석은 말 그대로 애플리케이션 소스 코드를 분석함으로써 소프트웨어에 있는 결함을 식별해내는 기술을 말한다. 숙련된 감사자라면 소스 코드를 읽어서 수동으로 분석하고, 애플리케이션이 작동하는 방식에 대한 정신적인 모델을 만들고, 취약성이 발생할 수 있는 원인을 찾아낼 것이다. 이것은 현재까지 소프트웨어를 평가하는 가장 철저한 방식으로 인정을 받고 있는데, 그 이유는 이것이 소프트웨어 자체의 내면에 대해서 가장 심도 깊은 이해 과정을 포함하고 있기 때문이다.
수동 정적 분석의 약점은 이것이 가장 느린 분석 형태며, 효과적으로 수행하기 위해서는 높은 숙련도가 필요하다는 점이다. 좀더 정확히 얘기하자면, 마이크로소프트는 복잡한 보안 버그를 잡아내기 위해 보통의 개발자가 하루에 약 1천100라인의 C++ 코드를 분석할 수 있다고 추산하고 있다. 이것이 비교적 작은, 즉 5만 라인 정도의 애플리케이션으로 확장이 됐을 때를 생각해 보라. 물론 노련한 감사자이거나, 팀이 처리한다면 이 창이 크게 줄어들 수도 있겠지만, 이는 곧 값비싼 보안 전문가를 쓰거나, 혹은 자체 사람들을 교육시키기 위해 많은 시간과 돈을 투자해야 한다는 뜻이기도 하다.
이렇듯 수동 분석과 연관된 경비로 인해 자동 분석 툴이 등장하게 됐다. 가장 먼저 등장한 것이 바로 유서 깊은 린트(lint)로, 이것은1979년 하나의 범용 품질 점검 툴로서 유닉스 7 배포판의 일부로 등장했다. 그 이래로 현대의 소스 분석기는 주로 컴파일러 연구 영역에서의 많은 발전에 힘입어 훨씬 더 진보된 모습으로 성장했다. 이런 툴들은 보안에 정통한 개발자나 전문 소프트웨어 보안 감사자에 의해 사용이 될 때 소프트웨어 보안 분석에 걸리는 시간을 대폭 줄여줄 수 있다.
자동 분석의 한계
자동 소스 코드 분석 기술을 효과적으로 사용하기 위해서는 먼저 이들이 할 수 있는 것과 없는 것을 알아야 한다.
첫 번째 한계로는 잠재적인 취약성의 범주를 구분해서 적절한 처리 방법을 결정하는 게 포함된다. 공격자가 웹 사이트에서 인증을 우회할 수 있게 해주는 SQL 삽입(injecton) 취약성을 생각해 보라. 이것을 SQL 삽입 취약성으로 분류하겠는가, 아니면 인증 우회로 분류하겠는가? 결과적으로 스택 버퍼 범람을 야기하는 수의 범람(integer overflow)은 어떠한가? 이런 취약성은 코드에서 어떤 특정 라인이 원인이 되는가?
인간 감사자는 이런 종류의 의문에 판단을 내리고, 취약성에 관여하는 논리적인 맥락을 발견하고, 어떠한 예외 상황이나 잠재적인 혼란을 설명해야 한다. 자동 분석 툴은 이러한 수준으로 판단을 내릴 수가 없기 때문에, 이들은 종종 비직관적인 방식으로 잠재적인 취약성을 식별해내곤 한다.
예를 들어 이들은 혼란스러운 등급분류 기준이나 부족한 상황 정보를 제공하기도 할 것이다. 같은 문제를 여러 번, 그것도 종종 서로 다른 취약성으로 표시할 수도 있으며, 혹은 논리적 인스턴스가 앞서 함수 호출(function call)에 있을 때 취약성 지점을 코드 속 깊이로 표시할 수도 있다. 범주화에 따른 이러한 문제들로 인해 툴에서 나가는 아웃풋이 진정으로 의미를 가질 수 있으려면 막대한 수동 분석 작업이 필요한 경우가 많다.
나아가, 논리적 취약성에는 자동 분석이 허용되지 않는다. 코드 스캐너는 기본적인 이행상의 결함 외에는 다른 어떤 것도 탐지할 수가 없으며, 그럴 때조차도 서브세트만 가능하다. 이들은 애플리케이션 로직과 설계에 대해 의미있는 분석을 수행할 수 있는 능력이 없는데, 그 이유는 이들이 개발자의 의도를 나타내는 추상적인 개념이기 때문이다. 이들은 프로그램 스트럭처에서 직접적으로 패턴에 매핑을 하지 않는다. 스캐너가 할 수 있는 것이라고는 사용자를 주무를 수 있는 데이터에 노출된, 알려진 취약성 패턴을 식별하는 게 전부며, 그럴 때조차도 적당한 시간에 분석을 마칠 수 있으려면 상당한 타협을 해야 한다.
결과적으로, 허가 정책, 백도어 자격증명, 알려진 패턴이 없는 취약성, 혹은 논리적 이행 및 설계 결함에서의 에러를 효과적으로 막을 수 있는 툴은 결코 기대해서는 안 된다는 얘기다. 불행히도 실세계 취약성에서는 이들이 절반 이상을 차지하고 있다. 그리고 스캐너가 어떤 취약성을 놓칠는지 정확히 판단하기도 결코 쉬운 일이 아니다.
완벽한 세상에서는, 소프트웨어 취약성이 모두 나이나 이행 문제에 따라 엄격한 등급으로 구분이 될 것이다. 이런 세상에서는 또한 스캐너를 이용해 이행을 해결하고 수동 작업은 하이레벨의 로직과 설계에 집중시킬 수 있을 것이다. 하지만 불행히도 현실세계에서는 가장 추상적인 설계 및 아키텍처 버그에서부터 가장 간단하고 구체적인 이행상의 결함에 이르기까지 끊임없이 취약성이 존재한다.
여기에는 어떤 명확한 구분이 없으며 분석기들은 탐지할 수 있는 것에 있어 엄청나게 다양하기 때문에, 로직이나 설계상의 취약성에 대해 코드의 상당 부분을 수동으로 검토할 필요가 있을 것이다. 잘 정리된 도큐먼트라면 이것이 보다 수월할 수도 있지만, 아무리 좋은 로직이라 하더라도 모든 이행 로직을 설명하지는 못할 것이다.
끊임없는 취약성 존재
실제로는 어떠한 분석 툴이든 본질적으로 풀릴 수 없는 문제를 공격하고 있다. 보다 상세히 보자면, 3가지 16비트 정수를 입력(input)으로 받아들이고, 다른 어떤 외부 인자의 영향도 받지 않는 간단한 함수가 있다고 하자. 분석기가 가능한 모든 입력을 처리하려고 시도할 경우 이것은 (216)3개의 서로 다른 케이스를 처리해야 할 것이다. 즉 280조 개가 넘는 테스트 케이스가 존재하게 된다! 물론 테스트 케이스가 엄청나게 늘어나면 아무리 간단한 프로그램에서도 관리는 불가능해진다.
모든 테스트 케이스를 컴퓨팅하기는 현실적으로 불가능하기 때문에, 분석기에서는 입력 경계선을 정하려 시도함으로써 테스트해야 하는 것을 줄인다. 아까의 16비트 정수 예에서 이것은 각 패러미터용으로 허용된 최대값과 최소값이 될 수 있다. 분석기는 주로 자신이 식별하는 경계 케이스에 대해서 테스트를 수행한다.
이렇게 되면 분명 분석 품질은 분석기가 경계라고 인식하는 것에 따라, 그리고 자신이 단순화된 애플리케이션 모델을 만들어내는 방식에 따라 직접적인 영향을 받게 된다. 이러한 단순화 과정에서의 실수는 결과적으로 분석기가 진짜 취약성을 탐지해내지 못하게 하며(false negatives), 취약성이 존재하지 않는 곳에서 취약성이라고 판단하게 한다(false positives). 이런 문제는 문자열 프로세싱 코드를 분석할 때 드러나며, 너무 다양한 잠재적인 입력을 만들어 내기 때문에 툴이 진정한 취약성을 가려내는 데 큰 어려움을 갖게 된다.
우리가 테스트한 세 제품은 모두 취약성의 등급을 매기는 데 있어 어느 정도의 신뢰도를 제공했다. 이들은 또한 사용자 정의 규정, 폴스 포지티브 억압, 그리고 기타 그 제품만의 수단을 통해 분석기의 성능을 미세 조정할 수 있는 기능을 포함하고 있었다. 하지만 포괄적인 튜닝을 했다 하더라도 스캐너 출력을 평가하고, 코드를 수동으로 검토해 볼 필요가 있다.
마지막으로 폴스 포지티브 비율이 높다는 것은 단순히 뉘앙스의 차이가 아니다. 결국 이들은 툴에 대한 사용자의 신뢰를 떨어뜨릴 것이다. 폴스 포지티브 비율이 너무 높으면, 대부분의 개발자들은 불확실한 결과물들까지도 어떤 것이든 폴스 포시티브로 표시하기 시작하거나, 혹은 툴의 출력을 전적으로 무시해버릴 것이다. 최악의 경우에는 개발자가 넌덜머리를 내며, 모든 결과가 잘못됐다고 가정하고, 취약성을 처리하지 못하는 것들을 제외한 앞으로의 경보들(트루거나 폴스거나)을 없애도록 코드를 바꿀 수도 있다.
분석기 테스트 결과
우리의 세 가지 소스 코드 분석기를 이용해 윈도상의 이클립스와 비주얼 스투디오에 있는 C/C++과 자바 소스를 분석한 결과, 몇 가지 일관적인 동향을 발견할 수 있었다. 우선 C 코드의 더블 프리(double-free) 버그나 포맷 문자열(format-string) 취약성 같은 결함은 매우 믿을 만하게 식별됐다. 하지만 다른 버그 등급의 처리는 우리 기대치 근처에도 가지 못했다.
특히 수의 범람이나 유형 전환 같은 산수적 취약성은 언제나 놓치거나 폴스 포지티브율이 극단적으로 높은 신뢰도에서만 탐지했다. 이런 취약성들에 대한 보고가 늘어나고 있음을 감안할 때 이것은 약간 당황스러운 결과다. 복합 문자열 처리 취약성도 C/C++ 애플리케이션에서 일상적인 다른 많은 문제들과 함께, 낮은 신뢰도에서 같은 현상을 보여주는 경우가 많았다.
하지만 세 가지 소스 코드 분석기 모두, 범용 퍼저(fuzzer)나 웹 애플리케이션 스캐너 등, 과거에 사용하던 자동 분석 툴보다는 일관성 있게 나은 성능을 보였다. 우리는 또한 약간만 손을 대면(코드 구조조정, 전체 청소 및 분석기 튜닝 등) 얼마간의 취약성이 탐지가 된다는 사실도 알 수 있었다. 하지만 모든 분석기가 일부 심각한 취약성들을 놓쳤으며, 훨씬 더 많은 것들을 매우 낮은 신뢰 등급으로 표시했다.
한 가지 기억해야 할 중요한 사실은 이러한 결과가 환경에 따라 매우 달라질 수 있다는 것이다. 우리는 물론 가능한 한 일반적이도록 테스트를 설계하고, 실세계 소프트웨어를 잘 대변하는 좋은 샘플을 제공했다. 하지만 아무리 작은 차이라 하더라도 분석기에는 심각한 영향이 미칠 수 있기 때문에, 툴의 성능을 진정으로 측정할 수 있는 유일한 방법은 이것을 자신의 코드에서 직접테스트해보는 것이다.
규정준수에 있어서의 역할
2000년 이후부터 규정준수 소송은 회사들의 애플리케이션 취약성과 연관된 데이터 유출이 타깃이었다. 현재 미 연방 통상위원회 웹 사이트에는 가이던스 소프트웨어(Guidance Software), DSW, 그리고 부동산 회사인 네이션즈 홀딩(Nations Holding) 등에서 해결된 사건 리스트가 올라와 있다. 자동 스캐닝 툴이 이런 조직들이 규정준수의 의무에서 탈출하는 데 도움을 줄 수 있을까?
그 자체만으로는 불가능하다. 자동 코드 스캐너로부터 확인된 것만 치료해서는 ‘합리적’이거나 ‘적합한’ 애플리케이션 보안 수단이 될 수가 없다. 이것은 마치 계산기를 갖고 있지 않은 사람이 계산기를 하나 사면 세금 계산에 도움이 되긴 하겠지만 감사에 사용하기는 무리가 있는 것과 같다. 마찬가지로, 스캐닝만으로 크고 확실한 취약성 등급을 찾지 못했다면(가장 결정적인 것을 포함해) 스캐닝 결과만을 기반으로 해서 치료를 한다고 해서 결코 규정준수를 할 수가 없다.
- Dave Stampley, 네오햅시스 총회
Microsoft Builds In Security Analysis
비주얼 스투디오 2005 팀 에디션을 사용하고 있다면 몇 번의 클릭으로 간편하게 보안 분석을 할 수가 있다. 현재 버전에는 프리패스트(PreFast) 정적 소스 코드 분석기가 포함돼 있는데, 이것은 프로젝트 옵션 아래서나, 혹은 명령어 라인에서 ‘/analyze’ 스위치를 이용해 가동시킬 수 있다.
프리패스트는 컴파일링 동안 실행이 되며, 잠재적인 C/C++ 취약성을 알려주는 컴파일러 경고문을 만든다. 우리는 몇 가지 기본적인 테스트를 수행했으며, 프리패스트는 수많은 간단한 취약성들을 어떠한 폴스 포지티브도 식별하지 않고 성공적으로 탐지해 냈다. IT는 폴스 포지티브를 제거하거나, 혹은 다양한 버퍼 길이와의 연관성 등과 같은 변수들간의 관계를 확인하는 데 있어 SAL(Standard Annotation Language)을 이용해 훨씬 더 효과적으로 분석을 할 수 있다.
비주얼 스투디오에는 또한 FxCop라는 유틸리티가 포함돼 있는데, 이것은 매니지드 코드 어셈블리에서 분석을 수행함으로써 마이크로소프트 닷넷 프레임워크 가이드라인(Microsoft .Net Framework Guidelines)에 따르는지를 검사한다. 그리고 이 검사에는 안전한 닷넷 어셈블리를 위한 26개의 보안 전문 테스트가 포함돼 있다. FxCop에 의해 식별된 문제들 가운데 상당수는 독립적인 취약성들은 아니지만, 사양 준수를 방해하는 위험한 코딩 프랙티스들이다.
비주얼 스투디오 2005 팀 이디션에는 FxCop 테스트외에도 자동화된 애플리케이션과 유니트 테스팅을 위한 기능성이 포함돼 있다. 이런 테스트 사양들이 비록 보안만을 위한 것은 아니지만 이들은 다양한 단계에서 보안 테스팅에 적용 가능하다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
