봇넷의 현황과 대응기술 방향

스마트 디바이스의 보급으로 사이버 공간이 지속적으로 확대되고 있고 수많은 정보가 옮겨지고 있다. 개인정보를 수집하여 악용하거나 경쟁사의 시스템을 못쓰게 하는 등 네트워크로 연결된 곳에서는 언제나 위험이 산재해 있다. 이번 회에서는 보안과 관련하여 많은 이슈가 되고 있는 봇넷(botnet)에 대해 글로벌 아웃소싱센터를 구축하고 담당하는 한용만 박사와 단국대학교 컴퓨터보안연구센터원을 만나 이야기를 들어본다.

Q: 안녕하세요. 봇넷은 인터넷 세상에서 가장 위험한 공격으로 알려져 있습니다. 봇넷에 대한 정의를 부탁합니다.

스팸 메일이나 악성 코드를 전파하도록 하는 봇(bot)에 PC가 감염되어 해커(bot master)가 마음대로 제어할 수 있는 좀비 PC들로 구성된 네트워크를 말합니다(그림1). 일단 악성 코드 하나가 심어지고 나면 순식간에 전파될 수 있어 최근에 가장 위험한 공격 중 하나로 꼽히고 있습니다.

<그림1> 봇넷의 공격 개념

출처: 인터넷침해대응센터

일단 좀비 PC로 감염이 되고 나면 봇 마스터가 지속적으로 좀비 PC를 제어할 수 있기 때문에 침해 사고의 범위가 무한대로 늘어날 수 있다는 높은 위험성을 가지고 있습니다. 봇넷의 경우 원천적으로 차단하거나 감염된 PC를 쉽게 치료할 수 있는 기술이 있는 것은 아니기 때문에 이번 회에서는 기술적 요소보다는 봇넷의 위험성과 위험에 노출되지 않기 위한 방법 등에 대해 기억했으면 합니다.

더보기

SI와 애자일에서 요구사항 수집

SI와 애자일에서 가장 크게 차이가 있는 부분이다. SI는 고객이 요청하는 요구사항을 기반으로 하기 때문에 요구사항 정의에 신중을 기하고 고객이 요구하는 것 외에는 개발에 반영하려는 노력을 하지 않는 것이 현실이다. 요구사항이 한번 정해지면 프로젝트 종료할 때까지 번복하기가 매우 어렵고 고객과 협의도 쉽지 않기 때문이다.

애자일은 커뮤니케이션을 기본으로 한다. 요구사항을 수집하기는 하지만 사용자 스토리 단위로 요구사항을 정리하기 때문에 고객이 미처 생각하지 못한 부분을 찾아내어 함께 정의할 수 있다. 그리고 프로젝트 중간에도 요구사항이 맞지 않으면 빠르게 변경하여 대응한다.

애자일에서는 요구사항을 사용자 스토리 단위로 정의하여 필요한 기능들을 정의하게 된다. 하나의 스토리에 필요한 기능이 정의되고, 기능이 모두 개발되면 한 개의 사용자 스토리가 완성이 되는 것이다(그림2). 사용자 스토리를 체계적으로 정리하기 위해 사용자 스토리 워크샵이라는 활동을 따로 하는 경우가 일반적이고, 이렇게 정리된 사용자 스토리를 개발 일정에 맞춰 프로젝트 계획을 수립하게 된다.

<그림2> 애자일의 사용자 스토리 기반 요구사항 정의

요구사항이 정의되는 시점에 SI와 애자일의 가장 큰 차이점은 SI는 단편적인 요구사항만 정의되는 경우가 많고 애자일은 스토리 단위로 정의되는 것이다. 스토리 단위로 정의하는 것의 장점은 고객이 얘기하지 않아도 스토리 전개 상 필요한 것들이 한 눈에 들어오고 설사 얘기되지 않은 기능들도 찾아낼 수 있는데 있다.

더보기

디자인 씽킹 - 펩시콜라와 코카콜라 이야기

• 펩시콜라와 코카콜라 이야기

• 문화인류학적 조사를 시행하라

• 문화인류학적 조사를 시행하라

더보기

ICBM 기반의 산업

Q: ICBM이 오늘 주제에서 나오리라고 생각은 못했습니다. 앞으로 인더스트리 4.0에 맞춰 재구성되는 산업은 ICBM 기반으로 만들어지겠다는 생각이 듭니다.

ICBM을 얘기하면 IT나 소프트웨어 전문가조차도 너무 개념적인 이야기라고 말을 많이 합니다. 하지만 ICBM은 미래형 산업에 가장 잘 적용되는 구성 방안이라고 볼 수 있습니다. 어느 미래 산업이든 빅데이터를 생산해낼 것이고 이를 위해서는 수집하는데 필요한 IoT 센서가 필요하고 체계적으로 분석하고 성장하기 위해 머신 러닝이 꼭 필요하기 때문입니다. 클라우드는 이 것들을 하나로 묶어주는 역할이겠지요.

Q: IT 기술이 발전하면서 여러 산업들은 더 많은 발전을 이루기 때문에 상상하지 못하는 형태의 제품들이 많이 나올 것이라 생각했는데 소프트웨어 입장에서 보면 표준화된 틀 내에서 움직이는 것 같습니다. 이번 이야기의 마무리를 부탁드립니다.

이번 이야기의 주제는 보는 시각에 따라 다양하게 해석될 수 있습니다. 아직 체계가 덜 잡힌 개념이라고 볼 수도 있지만, 그만큼 기대되는 것들이 많다는 얘기도 됩니다. 점점 단순해져 간다고 느끼던 소프트웨어가 산업 변화의 중심이 된다는 것은 매우 흥미롭고 장미빛 전망을 주기도 하지만 체계적이고 효율적인 접근이 없다면 모든 산업을 망칠 수도 있다는 위험도 안게 됩니다. 이러한 위험을 줄이기 위해서는 소프트웨어 개발자들이 소프트웨어만 공부할 것이 아니라 소프트웨어가 필요한 다양한 산업에 대한 심도 있는 학습이 필요한 시점입니다.

더보기

디자인 씽킹 디자인 사고 유형 사례

• 확산적 사고와 수렴적 사고

• 니즈 중심적 사고와 해결책 중심의 사고 사례

• 선 중심의 사고와 점 중심의 사고사례

더보기

SI와 애자일의 개발 방향성 비교

애자일은 SI 프로젝트보다는 솔루션 개발 프로젝트에 더 잘 어울리는 문화다. SI 프로젝트는 요구사항을 수집해 완성해 나가는 형태다 보니 사용자 스토리 중심으로 개발하고 만족할 때까지 계속 반복하는 애자일 특성과는 많은 차이를 보인다.

그림1은 애자일 개발 방법의 한 예를 나타내고 있다. 요구사항을 정의하고, 개발과 테스트를 3회 반복하는 것으로 나타나 있다. 완성이 되면 리뷰하고 피드백 받고 사용자가 만족하면 릴리즈하는 것으로 SI 프로젝트와 비슷해 보인다.

<그림1> 애자일 개발 방법의 예

출처: http://agilemethodology.org/

하지만 SI 프로젝트와 차이점을 살펴보면, 개발의 주체가 다르다. SI 프로젝트는 개발자만 개발에 참여하게 되지만 애자일에서는 개발자와 고객, 사용자가 함께 참여하여 개발을 진행한다. 코딩을 하는 것이 아니라 개발되는 과정이나 최종 소프트웨어를 리뷰하고 피드백을 수시로 주면서 보완 작업을 빠르게 진행한다. 이 외에도 다양한 차이점이 있는데 아래에서 조금 더 자세히 살펴본다.

더보기

제 72회 SW공학 Technical 세미나 안내(2/23(목))

신청하기