[아이티데일리] 오늘날 정적분석(Static Analysis)은 소프트웨어(SW) 개발 과정에서 매우 중요한 기술로 자리잡았다. 성능을 저해할 만한 위험 요소나 보안 취약점을 초기 개발 과정에서 사전에 파악하고 대응함으로써 향후 서비스 운영 중에 발생할 손실을 방지할 수 있기 때문이다. 특히 과거에는 개발자들의 불편함을 초래한다는 이유로 적지 않은 눈총을 받고는 했지만, 지속적인 편의성 향상과 생산성을 높이는 기술 고도화를 통해 성공적인 인식 개선을 이뤄냈다. 특히 최근AI에게 코드 대리 작성을 시키는 사례가 등장하면서 이로 인한 보안 위협 등을 방지할 수 있는 정적분석 기술에 대한 관심이 늘어나고 있다.

개발 단계에 내재화된 시큐어코딩

이미 출시된 자동차에서 중대한 결함이 발견되면 제조사와 판매사는 대대적인 리콜을 실시해야 한다. 해당 결함이 제품 자체의 구조적인 문제에 의한 것이든 국내법 상 안전기준을 준수하지 못했기 때문이든, 한 번 리콜이 발생하면 제조사와 판매사는 상당한 손실을 입게 된다. 만약 해당 결함을 제품 설계 혹은 개발 단계에서 미리 알아챘더라면 훨씬 적은 비용으로 리콜을 방지할 수 있었을 것이다.

SW 역시 마찬가지다. 제품 및 서비스 출시 이후에 심각한 결함이 발견되면 이를 수정하는 데에 무척 많은 비용과 노력이 들어갈뿐더러 기업의 이미지에도 나쁜 영향을 미치게 된다. 출시 직전에라도 문제가 발견되면 다행이지만 이미 개발이 거의 끝난 상황이라면 수정에 상당한 시일이 소요되는 것은 마찬가지다. SW 개발 라이프사이클에서 충분히 개발이 진행되기 전에 결함을 찾아낼 수 있다면 낭비될 시간과 비용을 크게 줄일 수 있을 것이다. 업계 일각에서는 제품 개발 초기 단계에서 결함을 찾아 해결할 수 있다면 출시 이후에 해결하는 것보다 수십 배 이상의 비용 절감을 기대할 수 있다고 주장한다.

이에 따라 최근 몇 년 사이에 시프트-레프트(shift-left)가 보안 업계의 주요 화두로 떠올랐다. 시프트-레프트는 SW 개발 과정에서 보안을 점검하는 시점을 보다 왼쪽으로, 다시 말해 보다 앞 단계로 옮겨야 한다는 의견이다. 기존에는 SW 개발이 어느 정도 마무리된 이후에 보안 취약점 테스트를 수행했다면, SW 설계 단계에서부터 문제가 발생할 가능성이 높은 부분을 사전에 예측하거나 소스코드의 보안 취약점 여부를 반복적으로 점검하는 식이다. 이는 개발과 운영 프로세스 전체에 걸쳐서 보안을 고려해야 한다는 데브섹옵스(DevSecOps) 개념과도 닮아있다.

개발 과정에서 소스코드의 보안 취약점을 사전에 예방하는 프로세스, 혹은 보안 가이드나 표준을 준수하며 소스코드를 작성하는 과정을 시큐어코딩(Secure Coding)이라 한다. 개발 초기 단계부터 소스코드 자체에 대한 취약점 점검을 반복적으로 수행한다는 점에서, 보다 왼쪽으로 이동(shift-left)하고 있는 보안 트렌드에서 매우 중요한 요소 중 하나라고 볼 수 있다.

‘시프트-레프트’ 실현하는 정적분석

국내에서는 공공기관을 중심으로 시큐어코딩의 필요성에 대한 인식이 상당히 확산돼 있는 상황이다. 공공기관에서는 SW 구축 및 도입 시 ‘SW 개발보안’, 즉 시큐어코딩 기술을 활용할 것을 의무화하고 있기 때문이다. 가령 행정안전부의 ‘행정기관 및 공공기관 정보시스템 구축‧운영 지침’은 공공기관이 신규 SW 사업을 발주할 때 SW 개발보안과 관련된 기술 적용을 의무화하고 있으며, 정보통신망법 역시 정보보호 최고책임자가 외부 공격으로부터 시스템을 보호할 수 있도록 위험 요소 식별과 대책 마련 등을 수행해야 한다고 설명한다.

또한 민간시장이라 할지라도 금융권 등 높은 수준의 보안성과 안전성이 필요한 분야에서는 시큐어코딩의 필요성을 강조하고 있다. 예를 들어 금융위원회는 전자금융감독규정 등을 통해 금융사의 침해방지 대책 마련과 함께 보안 시스템의 지속적인 점검과 관리를 요구하고 있으며, 개인정보보호위원회는 ISMS-P 인증(정보보호 및 개인정보보호 관리체계 인증, Personal information&Information Security Management System)은 개발 단계에서의 보안 시스템 적용을 주요 심사항목 중 하나로 삼고 있다. 이외에도 직불카드의 글로벌 보안 표준인 PCI DSS(Payment Card Industry Data Security Standard)는 서비스 제공자가 안전한 시스템과 애플리케이션을 개발 및 유지해야 하는 의무가 있다고 강조한다.

다만 개발 단계에서 소스코드의 취약점을 탐지하는 것이 비단 SW의 보안성에만 영향을 미치는 것은 아니다. 시큐어코딩이라고 하면 보안 문제만을 탐지하는 것으로 오해하기 쉽지만, 사실 소스코드의 품질과 안정성에 영향을 미칠 수 있는 문제 사항을 모두 찾아내는 과정이다. 이 과정에서는 대개 정적분석(Static Analysis) 기술을 활용한다.

정적분석은 소스코드를 실행하지 않은 채 코드 자체에 대한 분석을 수행해 문제 여부를 탐지하는 기술이다. 사전에 설정한 규칙과 가이드라인에 따라 소스코드를 분석하면서 잠재적인 실행 오류와 코딩 표준 준수 여부를 탐색한다. 이는 안전한 환경에서 소스코드를 실행하거나 모의해킹을 실행해 이상 여부와 취약점을 탐지하는 동적분석(Dynamic Testing)과 대비된다.

정적분석과 동적분석은 결함이 없는 SW를 개발하기 위해 양쪽 다 필요한 부분이지만, 분석 방법에 따라 서로 다른 특징을 갖는다. 동적분석은 실제 SW가 실행되는 과정을 모니터링하면서 성능을 안정화하거나 다양한 공격 패턴을 적용해보면서 취약점을 탐지할 수 있다. 반면 정적분석은 단순한 오탈자나 잠재적인 오류를 사전에 찾아내거나, 실행 단계에서는 알아채기 어려운 코딩 표준 위반 여부도 잡아낼 수 있다. 특히 소스코드를 실행시키지 않아도 되기 때문에 개발 초기 단계에서부터 적용 가능하다는 장점이 있다.

개발자 불편함 팽배…편의성 높여 인식 개선

하지만 프로그래밍을 수행하는 개발자 중에서 정적분석과 같은 프로세스를 달가워하는 사람은 거의 없다. 최종적인 SW 결과물의 품질과 보안성을 높이기 위해 꼭 필요한 과정임에는 틀림없지만, 개발 과정에서 정적분석을 반복적으로 수행하는 것은 번거로운 일이기 때문이다. 특히 정적분석 기술을 활용하기 시작한 초창기에는 멀쩡한 코드를 이상하다고 판단하는 경우가 상당히 많았기 때문에, 개발자에게는 정적분석이 개발 생산성을 떨어트리는 불편한 프로세스에 지나지 않았다.

정적분석 기술은 대부분 룰 기반의 분석을 수행한다. 소스코드를 실행하는 과정이 없고 코드 자체의 단어와 문법을 분석하는 것이기 때문에, 사전에 정상적인 코드와 비정상적인 코드가 무엇인지를 각각 설정해줄 필요가 있다. 하지만 개발에 참여하는 인원이 많으면 각각의 개발자들은 각자 자신의 스타일에 맞춰 소스코드를 짜기 마련이다. 이렇게 다양한 코드 스타일에 맞춰 완벽한 룰을 만드는 것은 불가능하므로 자연히 오탐이 많이 발생할 수 밖에 없었다. 실력있는 개발자가 오류 하나 없고 효율적인 코드로 기능을 구현했다고 하더라도 코드 스타일이 독특해 정적분석 도구에 설정된 룰을 벗어난다면 즉시 문제가 가득한 코드, 속칭 냄새나는 코드(code smell)로 분류될 수 있다. 이에 초창기에는 상당수의 개발자가 개발 과정에서 정적분석을 반복적으로 수행하는 것을 불편하게 여겼다. 아무리 필요한 기술이라도 사용자가 싫어해서는 한계가 있다.

다만 시간이 지나면서 최근에는 이런 거부감이 다소 누그러진 추세다. 기업이나 기관에서는 SW의 보안성과 안정성에 관심을 가지기 시작했고 개발자들 사이에서도 정적분석의 효과에 대한 인식이 달라졌다. 그러나 무엇보다 큰 이유는 정적분석 기술의 수준이 높아지면서 오탐이 크게 줄었다는 점이다. 초창기 정적분석 도구들이 가지고 있던 룰에 비해 최근의 정적분석 도구들은 훨씬 정교하고 정확하며 다양한 환경에 적용 가능한 룰을 가지고 있기 때문이다. 이에 따라 개발자들은 코드를 제대로 작성했는데도 문제가 있다는 오명을 뒤집어쓰는 경우를 피할 수 있게 됐다.

실제로 그간 정적분석 기술 공급업체들은 룰의 정교함을 높여 오탐을 줄이거나 사용자의 편의성을 향상시키는 방향으로 제품 고도화를 추진해 왔다. 다양한 프로젝트를 수행하고 정상‧비정상 소스코드에 대한 데이터를 확보하면서 더욱 정확하게 소스코드의 이상 여부를 구분할 수 있게 됐다. 동명의 정적분석 도구를 개발하는 스패로우(Sparrow) 관계자는 “초기의 정적분석은 단순히 단어와 문법만 보던 것이었다. 당시에는 어떤 프로젝트에서 10만 줄의 코드를 분석했더니 80% 이상 오탐이 발생한 경우도 있었다. 하지만 데이터가 축적되고 제품이 고도화되면서 지금은 90% 이상 정확하게 이상 여부를 탐지해낼 수 있게 됐다”고 설명했다.

생산성 저해하지 않는 ‘편리한 도구’로 진화

최근 개발되는 정적분석 솔루션 및 서비스들은 개발 생산성에 최대한 영향을 주지 않으면서 다양한 검증을 수행할 수 있도록 성능이 향상됐다. 기본적으로 상황에 맞는 다양한 룰을 학습해 선택적으로 적용할 수 있는 것은 물론, 특정한 코딩 가이드라인에 맞춰 새로운 룰을 설정해야할 경우에도 축적된 경험과 노하우를 살려 준비된 다양한 ‘룰 프리셋’을 이용할 수 있다.

또한 유사한 오탐이 반복적으로 발생할 경우 예외처리를 하거나, 전체 코드 중 변경 및 추가된 부분만 선별해 효과적인 분석을 수행하는 증분 분석(Incremental Analysis) 기능을 탑재하는 등 정적분석의 성능을 높이는 기술들도 상당수 개발됐다. 특히 스패로우는 검출된 보안 취약점에 대해 실제로 적용 가능한 수정 가이드를 제공하는 ‘액티브 서제스천(Active Suggestion)’ 기능 등을 개발해, 국내 정적분석 기술 공급업체 중에서 선제적으로 가트너 매직 쿼드런트에 이름을 올리기도 했다.

특히 IT 환경에 따라 개발 언어 역시 다양해지면서 정적분석 도구들 역시 검증 가능한 언어를 빠르게 늘려가고 있다. 한글 맞춤법 검사기로는 영어나 중국어 맞춤법을 검사할 수 없는 것처럼, 정적분석 도구의 활용성을 높이기 위해서는 보다 다양한 언어에 대한 분석이 가능해야 하기 때문이다. 과거에는 공급업체에 따라 자바(Java)와 같은 메이저급 언어를 중심으로 몇 가지 언어만을 제한적으로 지원했지만, 최근에는 고객사들이 다양한 언어를 하나의 플랫폼에서 사용하기를 원함에 따라 지원 언어를 확장해나가는 추세다.

업계 관계자는 “언어 지원은 정적분석 도구의 가장 중요한 부분 중 하나다. 최근 몇 년 사이에 점유율이 크게 늘어난 파이썬(Python)이나 R은 물론, 코틀린(Kotlin)이나 스위프트(Swift) 등 다양한 언어로 지원 범위를 확대하고 있다. 특히 최근에는 고(Go)나 러스트(Rust), 타입스크립트(TypeScript) 등에 대한 요구가 늘어나고 있어 관련 언어 지원을 준비 중이다”라고 설명했다.

코드 취약점 늘리는 ‘AI 코딩’

한편 최근 몇 년 사이에 로우코드‧노코드(이하 LCNC) 기술의 성능이 높아지면서 소스코드에 대한 정적분석 필요성이 더욱 높아지고 있다. LCNC는 개발자가 소스코드를 직접 작성하는 것을 최소화하고, 미리 만들어놓은 컴포넌트와 모듈들을 블록 조립하듯 연결해 원하는 기능을 구현한다. 이를 통해 IT 지식 수준이 부족한 사용자도 필요한 기능을 빠르게 개발해 사용할 수 있어, 만성적인 IT 인력난을 해결할 수 있는 방법 중 하나로 주목받고 있다.

하지만 일각에서는 LCNC 기술로 개발한 소스코드가 상당한 보안 취약점이나 한계를 드러낼 수 있다고 주장한다. 우수한 개발자가 개발 생산성을 높이기 위해 LCNC 기술을 활용하는 경우는 문제가 적지만, 비전문가가 LCNC 기술을 사용해 개발한 소스코드는 구조상 위험성을 내포하고 있을 수 있다는 지적이다. 한 업계 관계자는 “외부 프로그램으로 개발한 서비스는 사내 개발 표준을 준수하지 않았을 가능성이 높고, 결과물의 보안 수준도 신뢰할 수 없다”고 설명했다.

특히 챗GPT(ChatGPT)는 더 심각한 문제를 야기할 수 있다. 산업 분야를 불문하고 가장 큰 화두로 떠오르면서 챗GPT로 SW 개발을 일부 대체하는 것이 가능해졌다. 실제로 많은 인터넷 커뮤니티나 SNS 상에서 챗GPT를 활용해 비전문가가 간단한 서비스를 개발한 경험담을 확인할 수 있다. 하지만 사용자가 챗GPT에게서 얻은 소스코드를 검증할 수 있는 역량이 없다면 보안 위협이 있는 서비스를 그대로 사용하게 될 수 있다. 상대적으로 LCNC 기술에서 사용되는 컴포넌트와 모듈들은 사전에 준비하는 과정에서 문법적 오류나 보안 취약점 등이 없도록 최대한 주의를 기울이겠지만, 챗GPT가 작성한 소스코드는 이러한 과정조차 없다는 점에서 더욱 큰 위험성을 내재하고 있다.

업계 관계자는 “챗GPT는 AI가 학습한 과거의 자료에 기반해 코드를 대신 작성해준다. 하지만 과거에 안전했던 소스코드가 앞으로도 안전하리라는 보장은 없다. 로그포제이(Log4j)의 사례에서 알 수 있듯, 이미 수많은 검증을 거친 서비스들도 어느 날 갑자기 중대한 취약점이 발견돼 전 세계를 뒤집어 놓곤 한다. AI가 작성한 코드가 결과적으로 사용자가 원하는 기능을 수행한다고 해도 보안성 확보나 성능 최적화라는 측면에서는 블랙박스라는 한계를 가지고 있다. 따라서 사용할 수 있는 영역을 제한하고 사람의 개입이나 분석 도구의 힘을 적극적으로 빌려 검증하는 과정을 거쳐야 한다”고 조언했다.