[카테고리:] 미분류

2018년 4월부터 우리는 수없이 많은 사이트에서 “이용 약관 개정” 안내창을 봅니다. 바로 GDPR 때문인데요, 트위터 개발자 판 등에서 한 때 화제가 되었던 GDPR. 이게 무엇이고, 어떻게 인터넷을 뒤집게 되었을까요?

GDPR은 General Data Protection Regulation (기본 정보 보호 규칙)의 약자로, 유럽연합(EU)의 유럽의회에서 2016년 4월에 채택한 뒤로 많은 정부들이 이 규칙을 일종의 제도 개념으로 가져오게 됩니다. 즉, GDPR은 웹 사이트 등의 인터넷 서비스가 지켜야 하는 필수 개인 정보 취급 규칙입니다.

각 기업들은 2018년 5월 25일까지 GDPR을 준수하도록 사이트 이용 약관을 개정해야 하며, 그렇지 않을 경우 GDPR 실시 국가에서 시이트를 서비스할 수 없습니다.

GDPR은 애플, 구글, 페이스북, 아마존 등 IT계 공룡 기업에게는 엄청난 직격탄이 되었습니다.

특히, 개인정보 모으기를 포켓몬 잡듯이 좋아하는 페이스북은 더이상 그 행동을 할 수 없게 되었습니다. 사용자들의 개인 정보를 무단으로 모으고 있었는데, 법의 규제를 받게 된 것입니다. GDPR의 실시를 촉발한 주요 원인 중 하나인데, 2017년 12월 19일에 독일 정부가 사용자의 개인 정보와 사생활을 무단 수집하고 있는 점을 지적한 적이 있습니다.

이 글을 읽고 있는 여러분들이 인터넷 서비스를 운영하게 될지는 차선의 선택이지만, 만약 서비스하게 된다면 GDPR을 지켜서 약관을 만들고, 서비스해야 합니다.

세 줄 요약:

1. 개인 정보 보호 법률이다

2. 여러분들이 사이트 이용 방법을 바꿀 필요는 아마도 없을 것이다

3. 페북은 더 이상 여러분을 감시할 수 없다

참고 자료:

나무위키의 GDPR 항목

GDPR 공식 사이트 (영문)

영문 법률 전문

오늘은 지난날을 돌이켜보며, Segmentation (이하 세그폴트)와 코어 덤프에 관한 얘기를 해볼까 합니다.

아 오늘 너무 마셨어! 뇌내 세그폴트 날 것 같아!

취한 어느 개발자의 독백입니다. 네, 만들어 낸거예요. 다른 개발자들이 트위터 등에 세그폴트가 나니 뭐니 하는 것처럼 저 또한 세그폴트 소리를 해대고는 했습니다.

세그폴트? Segmentation Fault라니 이게 대체 뭔 소리일까요? 개발자가 아닌 사람들은 이게 대체 뭔 소린지 전혀 모를 겁니다.

그런데 한 가지 이상한 사실이라면, 여러분들은 컴퓨터를 쓰면서 한번씩은 Segmentation Fault를 경험했다는 겁니다. 다만 그게 세그폴트인지 아닌지는 전혀 모를 겁니다.

특히, 저사양 PC에서 3D 어드벤처 게임이라던지 뭐라던지 간에, 고사양을 요구하는 게임을 즐겨왔던 사람이라면 적어도 10 번 이상은 봐왔을 겁니다.

전 리눅스 유저라서 세그폴트가 세그폴트인지 아닌지 정확하게 나오지만(Kubuntu 16.04 LTS를 쓰는데 KDE Plasma 쉘이 세그폴트를 너무 자주 일으킵니다. 다음 LTS에서는 고치기를 희망합니다.), 이 글을 보는 모든 사람들은 Windows를 쓰실 테고, Windows는 세그폴트를 정확히 표기하지 않기 때문에, Windows에서의 예시를 한 번 보여 드리겠습니다.

이게 Windows에서의 세그폴트입니다. 이거 메모리 오류 아니냐고요? 아닙니다. 세그폴트 맞습니다.

세그멘테이션 결함 (Segmentation Fault, 줄여서 세그폴트 또는 Segfault) : 프로그램이 허용되지 않은 메모리 영역에 접근을 시도하거나, 허용되지 않은 방법으로 메모리 영역에 접근을 시도할 경우 발생하는 오류 (한국어 위키백과)

그리고 일부 개발자들은 뒤에 “(core dumped)”까지 붙여서 세그폴트 밈을 던집니다. core dumped? 그게 뭘까요? 이것 역시 일반인들은 모를겁니다.

코어 덤프는, 쉽게 말해서 세그폴트나 기타 오류를 일으킨 프로그램이 에러가 날 당시의 메모리 상태, 시스템 정보, CPU 상태 등이 덤프되어 기록되는 겁니다. 이 덤프 기록은 주로 디버깅에 사용됩니다. 즉, 내가 어떤 컴퓨터에서 돌아가고 있었는지, 어떻게 오류가 났는지, 그 이유는 무엇인지 등이 기록되는 것이 바로 코어 덤프입니다. 한 마디로 “경위서”죠.

코어 덤프는 일반적으로는 프로그램 제조사에게 보내거나, 또는 그냥 버려뒀다가 백신 프로그램 등에 내장된 PC 최적화 기능을 사용해서 밀어버립니다. 물론 자신이 개발자라면 코어 덤프를 분석할 수도 있겠죠.

세그폴트는 무조건 프로그램 제조사의 잘못이라고 볼 수는 없습니다. 운영체제의 문제거나, 또는 특정 프로그램(백그라운드에서 돌아가는 백신 등), 컴퓨터의 제조사, 심지어는 시스템을 사용하는 사용자의 문제일 수도 있다는 겁니다. 프로그램 자체를 정말 대충 만들어 놓지 않는 이상은 원인을 찾기가 쉽지 않은 특이한 오류입니다. 어쩌면 교통사고와 비교할 수도 있겠습니다.

블로그 포스팅 중에서는 여전히 어색하고 긴 글이지만, 읽어주셔서 감사합니다.

ps. 어차피 메모리 어디를 참조하려 했고 뭘 할 수 없었는지 풀어 써놔도 일반인들은 알아듣지 못할텐데 왜 Windows는 그런 식으로 언어를 순화했는지 모르겠네요.

많은 개발자들이 DROP TABLE이라는 농담을 알고 있으며, 실제로 그 농담을 하고 있습니다.

그런데 일반인이라면 대체 그 DROP TABLE이 뭔지 모를겁니다. 컴퓨터활용능력 1급의 어디를 뒤져봐도 DROP의 D도 보이지 않아요.

 

DROP TABLE이 뭐냐면

DROP TABLE : 테이블을 껍데기까지 삭제해버리는 SQL 쿼리 명령어

 

직접 예시로 설명해 드리겠습니다. (프로그램 : Microsoft Office Access 2010)

간단한 테이블을 만들었습니다. 이곳에는 3명의 이름과 이메일 주소가 저장되어 있습니다.

그리고 그 화제의 DROP TABLE 쿼리를 만들어 실행해 봅시다.

 

어떻게 될까요?

이름과 이메일을 기록했던 아까 그 테이블이 사라져 버렸습니다. 감춰진 게 아니라 “삭제” 된겁니다.

 

그냥 테이블 하나 없애는 건데 이게 왜 농담으로 사용되나? 라는 질문도 많을텐데, 이 쿼리는 데이터베이스를 엉망으로 만들어버리는 SQL 인젝션 방식 해킹에 많이 사용됩니다.

 

그러니 SQL로 데이터베이스를 관리하는 사람이라면 보안회사 Imperva와 OWASP에서도 수년동안 이 인젝션 방식에 대해 경고하는 만큼 보안에 각별한 주의가 필요합니다.

 

관련 문서 : SQL 인젝션 (나무위키)

 

2011년, 퀄컴에서 스냅드래곤 S2를 개량한 스냅드래곤 S3를 출시했습니다. 싱글코어였던 S2 대비 듀얼코어로 변경된 CPU 아키텍쳐가 큰 변경점입니다.

다만 듀얼코어화하면서 S1 때부터 지속해 오던 Scorpion 아키텍쳐가 개선되지 않은 채 그대로 2개나 들어가 화끈한 발열을 자랑했고, 졸지에 스냅드레기, 화룡으로 불리며 조롱당했습니다.

뜨거워서 욕먹은 물건이라지만, 글쎄요, 이 SoC에 대힌 제 생각은 달랐습니다.

이 SoC는 제겐 그렇게 뜨겁다고 느껴지지는 않습니다.

현재 갤럭시 S2 HD LTE(순정 4.1.2 젤리빈 펌웨어)를 사용중인데, 그렇게 뜨겁지는 않고 배터리도 적절하게 오래갑니다.

쓰면서 느낀 점이라면 ARM Cortex-A5과 A7 사이 중간급 성능을 가진 CPU를 듀얼코어로 쓰고 있는 것 같다는 점입니다.

옵티머스 뷰 또한 같은 스냅드래곤 S3를 탑재한 폰이지만, 쓰면서 뜨겁다는 느낌은 전혀 없었습니다. Linux deploy를 사용해서 리눅스 가상머신을 돌리는 데도 말이죠.

트위터 실트에 #산타가_없다는걸_알게된_계기 가 뜬 적이 있었습니다. 이걸 제 방식대로 설명해보죠.

일단 제가 태어난 해인 1999년에는 64비트 프로세서가 상용화 되어있지 않고 주로 32비트 프로세서를 많이 사용했습니다. 물론 당시에 닌텐도 64에 사용된 MIPS64나, 일부 워크스테이션 등지에 사용된 DEC Alpha, SPARC 등 64비트 프로세서가 고급 연산이 필요한 기업체에선 상용화가 되어있는 케이스도 있습니다. 여기서는 클라이언트, 즉 고객들을 위한 겁니다. 닌텐도 64처럼 64비트 게임기도 있지만 뭐, 산타를 집에 놓고 그 산타로 게임을 할 건 아니잖아요. 여기에서의 산타는 정수 연산 전용으로만 사용합니다.

1999년에 펜티엄 3가 나왔지만 너무 비쌌어요. 당시 펜티엄 2나 586(펜티엄 1)를 사용하는 사용자들이 태반이었고, 사무용에 국한한다면 486도 쓸만했습니다.

32비트 정수형 자료는 많아봐야 42억(2^32), 그것도 부호를 넣으면(음수를 고려한다면) 21억(2^32/2) 밖에 못 셉니다. 정확히 얘기하자면 4294967296과 2147483648입니다.

예를 들어서, 산타라는 이름의 특수목적 컴퓨터가 있다고 쳐보죠. 임베디드 시스템이라고도 부릅니다. 1일 안에 무조건 모든걸 해결해야 하니 리얼타임 시스템이라 볼 수 있겠습니다. 이 산타는 12월 25일에 1인당 1개씩 소프트웨어적인 선물을 주는 것을 목적으로 합니다. 제가 얘기하는 건 1가구당 1선물이 아니라 1인당 1선물을 얘기하는 겁니다. 1가구당 1선물이라니 좀 너무한 것 같습니다. 4명이 들어간 집에 단 1개의 선물이 놓여있다면 난리 좀 나겠군요.

이제 그 산타의 뇌가 32비트라고 가정해 봅시다. 지구 전체 인구가 약 60억이라고도 쳐 봅시다. 산타는 많아봐야 60억 인구 중 42억 인구에게만 선물을 보낼 수 있습니다. 그 42억을 모두 채우고 그 이상을 가버린다면, 산타는 몇 가구에 선물을 보냈는지 까먹게 됩니다. 0으로 돌아간다구요. 이것을 바로 오버플로우라고 부릅니다.

4294967295인에게 선물을 보낸 산타 : 호호호~ 메리 크리스마스! 이제 0번째 선물을 보내야지!

뭐, 할 말이 없군요. 32비트는 2^32가 한계니까요.

0에서 다시 시작하고, 또 다시 시작하니 무한 루프를 돌겠죠? 설상가상으로 산타에게 2038년 문제가 있다면 상황은 정밀 심각하게 악화됩니다. 산타는 12월 25일에 1번 작동하고 돌아가서 DRAM에 기억한 내용을 저장한 채 잠들고 있어야 하잖아요.

DRAM의 내용을 하드디스크에 저장하고 스스로를 꺼버리는 하이버네이션(최대 절전 모드) 기능이 Windows XP를 기점으로 생겨났지만 당시에 그런 기능은 아무리 봐도 좀 생소했습니다. 쓰는 사람이 없었죠. 지금도 하이버네이션을 자주 사용하는 경우는 노트북이나 태블릿을 포함한 모바일 기기가 아닌 이상 많이 없을겁니다.

어쨌든, 그런 루프를 반복하면 시스템이 노후화되고, 이상이 생길수도 있습니다. 그리고 ROM의 데이터 보존 기간, 부품들의 수명들까지 고려한다면 프로그래머들, 그래고 이 산타를 맏든 엔지니어들은 영원히 이 산타를 유지보수할 생각에 머리를 쥐어쌉니다.

아무리 잘 만든 프로그램이라 할 지라도 버그가 있는 것처럼, 산타도 버그가 있다고 싱상해 보세요. 정말 상상만 해도 끔찍하군요.

이런저런 문제들을 인식했다면, 그런 산타를 업그레이드 해야겠죠? 이 쯤 되면 낡아빠진 32비트 산타를 폐기하고 64비트 산타로 갈아치우는게 일반적입니다. 뭐, 제가 가장 좋아했던 시기는 2000년대 중후반입니다. 인텔 코어 2 프로세서가 히트를 치고 있죠.

64비트 중 유명한 것은? AMD 애슬론 64와 인텔 코어 2 프로세서가 있습니다. 그런 64비트가 셀 수 있는 숫자는? 부호를 넣어도 60억은 가볍게 뛰어넘습니다! 시대가 발전했으니 산타 자체의 처리 속도도 엄청나겠군요! 반도체 제작 공정이 250nm에서 65nm로 넘어가니 전력 당 성능 비도 전과 비교하면 대단할 겁니다! 이해가 안간다면 당장 펜티엄 3와 코어 2 듀오를 비교해 보세요.

이처럼 주기적으로 산타를 업그레이드 한다면 산타에 대한 고객들의 인식도 좋아질겁니다. 프로그래머들이 놀고 먹는데 어느정도 도움은 되겠습니다.

뭐, 이렇게 한다면 지금 산타가 있을 수는 있겠네요.

이상입니다. 감사합니다.