수원으로 사라짐

http://seorenn.egloos.com/3698411
분류없음 :: 2008/04/11 13:14 :: RENN
Trackback : Comment

공정위에게 밥을 주지 마

공정함을 판단해야 할 기관에서 이 딴 공문이나 보내오는데 월급을 줄 가치가 있어?! 당장 그들의 밥그릇을 치워 버리고 밥을 주지 말고 굶겨야 된다. 하다 보면 주인에게 설설 길 테니깐.

자 그리고 오픈웹에 힘을! 파이어폭스에게 영광을!

아니 공정위 이 사람들아. 당신들이 지금 리눅스/맥 유저를 차별해 놓고 무슨 공정성을 판단한다는 거야? 욕 나오는거 겨우 참고 있는 상태라고. 설설 기어. 어쭈? 기어오르려고? 야 이봐 당신들 월급주는게 우리 국민이라는 거 알아 몰라? 늬들 밥주는 주인이라고!
잡상 :: 2008/03/18 14:20 :: RENN
Trackback : Comment

IE8 Beta1

얼마전에 IE8의 노선이 '표준 준수'로 바뀐다는 이야기를 듣고 기뻐하던 나였지만... IE8의 Beta1을 설치해 본 후 인상이 찌푸러지게 되었다.

아래에 C++변화 이야기를 쓸 때 사용한 브라우저가 IE8b1이다. 자 뭐라고 할까. 쓰레기? 아직 판단하기 일러서 평가는 유보하자.

우선 외관적인 변화는 안보인다. 단지 주소(URL) 부분에서 사이트의 도메인 이름 외에는 전부 흐리게 보여준다. 사이트가 어디인지 정확하게 알려주기 위한 아주 멋진 기능이라고 생각한다. 뭐 그래도 중요한 건 아니야.

단지 외관적인 모양에서 보면, mozilla firefox에서도 아주 잘 보이는 사이트, 예를 들자면 이 블로그 엔진인 TT와 TT의 관리툴의 디자인이 좀 깨진다. -_-;; firefox에 IE호환 기능이 약간이나마 들어가 있다는 걸 생각해보면 표준 준수가 안된다라고 평가하기엔 좀 그렇지만 어쨌든 좀 안되어(?) 보인다.

그 다음으로 form에 글을 쓸 때 무척 느리다! 심각한 문제군. 한글만 써 봐서 내부적인 다른 오류가 있을지도 모르겠지만 어쨌든 느리다.

그리고 정말 심각한 문제. TT의 에디터는 간단한 위지윅HTML에디터인데 여기다 글을 쓸 수가 없어! 커서가 안생겨. 그냥 무작정 form에 클릭해서 글을 쓰려 하면 오히려 이상한 링크가 선택되서 다른 페이지로 넘어가버려. 이거 정말 심각한 문제야.

하지만 아랫글과 함께 지금 이 글도 IE8으로 썼다면 정말 거짓말 같지? 글을 쓸 수 없는데 어떻게 썼어?

사실 지금 IE8을 IE7 emulation 으로 돌리고 있다. -_- 이렇게 하면 글 쓰기에도 무리가 없다. IE8이 확실히 페이지 로딩에는 빨라서 이렇게 쓰는게 IE7 쓰는 것 보다 훨신 빠른것 같아.

일단 정확한 평가는 좀 더 써 본후 판단하도록 하자...라고 말하고 싶지만 IE7 emul모드를 풀어야 하는걸까. 흠............ 고민된다.

- 일단 IE8의 표준준수는 매우 환영하는 입장이라 악평은 접어둘래. 화이팅 -_-;;

잡상 :: 2008/03/07 16:43 :: RENN
Trackback : Comment

C++도 바뀌고 있구나...

C가 바뀌는 건 종종 접할 수 있는 이야기였다. 오픈소스 계열, 리눅스 계열의 포럼이나 커뮤니티를 자주 눈팅하고 있으면 어쩔 수 없이 언어 중에는 C이야기가 나올 수 밖에 없으니깐. 확실히 C도 뭔가 눈부시게 바뀌고 있다. dynamic array라던가 dynamic label(label pointing?)이라던가 말이다.

VC6로 개발하던 프로젝트를 VC9(2008)로 빌드해 볼 기회가 생겨서 해 봤다. 우선은 workspace를 solution으로 바꾸면서 몇 가지 로그를 보여주는데 '이대로 빌드하면 에러 생긴다. 고쳐라'라는 문장에 몇 개 보인다. C++규격이 변했다는 걸 보여준다. 일단은 C++규격 같은건 참고하지 않고 VC9의 로그를 보고 판단해볼까.

...

int가 사라졌다! 이건 중대한 변화다. 내가 C++을 싫어하던 이유가 OO이면서도 가장 기본적인 Object를 지원하지 않았다 라는게 크다. int, char, float 같은 C의 기본 변수형 타입도 OO의 개념에서 본다면 class이고 그 class규격대로 object(instance)가 되어야 하지만 이런게 없었다. C++이라는 이름에서 보여지듯 C의 잔재를 그대로 가지고 오면서 기형적인 OOL이 되어버린 것이다.

근데 char은 왜 남겨놓은건가. 이해가 안되네. -_-??

이와 이어져서 operator overload의 type을 생략한것도 뭔가 문제가 생긴 듯 하다. 타입이 없으니 기본 타입인 int로 대체한다면서 C++에서 int는 쓸 수 없다라는 것도 친절하게 알려준다. -_-;; 무슨 변화가 생긴 걸까.

옛날에 C++공부할 때 생소했던게 include하는 헤더 파일의 확장자(.h)를 붙이지 않던 것이었다. 이게 표준인지 아닌지는 잘 모르겠지만 여전히 이런 관행(?)에 대해서는 철저히 묵인하던 VC9의 컴파일러 였다.

...

규격이 변한다는 것은 분명 positive한 방향으로 바뀌고 있다는 의미일거다. 불행히도 사내 MS 개발 환경은 아직까지도 VC6이 굳건히 버티고 있어서 원래 코드를 바꾸지도 못 하고, 아니 사실 귀찮아서 바꾸기는 싫기도 하군. 뭐 아직 대학 등에서도 VC6기준의 강의는 여전히 바뀌지 않았고 여전히 많은 개발자들이 VC6를 쓰고 있다는 점을 생각해보면 어째 우리나라가 IT강국이 되지 못 하는지를 알 수 있는 것 같기도 하다.

뭐 하여간 딱 이 한마디로 결론을 짓자.

- C++ 개새끼. 여전히 가장 싫어하는 언어 -

개발자적유희 :: 2008/03/07 16:34 :: RENN
Trackback : Comment

[WOW] 마법사 PVP용 특성 되짚어보기

마법사를 오래해서 그런가. 확실하게 말 할 수 있는 건 완벽한 특성트리는 존재하지 않는다는 점이다. 그냥 각각의 특성을 보며 장단점을 파악해 두고, 실제 전투에서 이를 이용해 이기거나 도망치거나 서포트 하는게 정말 중요하다 싶어 머리에 각인할 겸 한번 써 보자.

화염: 충돌/불타는 속도

화염계 특성에선 2가지를 꼽을 수 밖에 없다. 나머지는 딜에 특화된 특성에 가깝다. 이 두 녀석을 분석해볼까.

충돌의 경우 5포인트 투자 시 꼴랑 10% 확률로 화염공격이 적중했을 때 2초간 기절시키는 기술이다. 너무 운빨을 심하게 받아야 하지만, 공격시에 잘 터지면 상대를 유린할 수 있는 특성이고, 타갑 사용 시 공격 당할 때 상대가 충돌에 걸리는 행운을 노릴 수도 있다. 즉 공/방 양쪽에 사용할 수 있다. 근데 아무리 생각해도 너무 운빨이다.

타속(불속이라 해야겠지만 이 축약어가 익은 것 같다 -_-)은 화염 특성 중 가장 PVP다운 특성으로 꼽고 싶다. 밀리든 원거리이든 이동방해 효과를 제거하고 이속 까지 살려주니 집중타격 상황을 탈출하여 공격포인트를 차지할 때나, 공격 당할 때 운 좋게 발동하면 그 상황에서 탈출하는게 더 없이 좋은 특성이다. 근데 이것도 너무 운빨이다. 충돌 처럼 10%라니... 15~20% 수준이라면 정말 좋은 특성이었겠지만 아쉽다.

결론적으로 화염계 특성은 너무 운에 의지하는 면이 강하다. 공격적인 부분도 크리티컬에 상당 수 의존하고 있는 터라 현재의 탄력둘둘 세상에선 공격력 약세도 화염특성에 무력함을 한 몫 더한다.

냉기: 동상/얼음 보호막/물의 정령 소환

현재 법사 PVP계의 사기 특성이라 불리는 냉기. 조금만 살펴봐도 화염에 비해 너무나 좋은 특성을 보유하고 있다.

동상의 경우 공격 시 상대를 얼려 움직임 봉쇄+캐스팅 시간 확보+데미지 증가(산산조각)의 3단 효과를 준다. 얼갑 사용 시에는 밀리클래스 들의 집중 구타에서 탈출할 수 있게 도와주기도 한다. 하지만 그 무엇보다 특출난 점은 특성을 모두 투자했을 시 15%라는 확률을 가진다는 점이다. 화염은 고작 10% 확률 투성이인 점에 비추어서도 말이다.

얼음 보호막: 마나보호막과 너무 대조되게 좋은 스킬. 일단 현재 증뎀까지 적용되어서 보호수치도 제법 되고 마나효율도 더 뛰어나다. 사실 비교할 만한게 마나보호막 뿐이지만 너무나 차이가 나는 성능을 가지고 있다. 안그래도 탄력과 방어도(얼갑)을 보유하고 있으면서 얼보 여기다 마나보호막 까지 사용하면 바퀴벌레 법사가 되는셈이다.

물정령은 냉기의 방어적인 면과 공격적인 면(산산조각)과 합쳐져서 엄청난 시너지를 내는 특성기이다. 일단은 그 자체로 시간제한 있는 소환수지만 공격까지 하는 무서운 녀석인데 거기다 원거리 광역 얼회까지 갖추고 있으니 말이지. 얼회빨이 없으면 제 위력을 내지 못 하는 얼창을 빛나게 해 주는 녀석이 바로 이 물정령이다. 얼창 요정질의 장본인. -_-+

얼창과 함께 많은 특성의 잇점을 살려서 냉기법사는 공방 양쪽에 완벽한 존재가 되긴 했다. 아니 그나마 요즘은 도적과 냥꾼의 강세로 좀 약해진 감이 있긴 하지만 여전히 PVP에서 유용한 특성임에는 변함이 없다. 단지 그 모습이 마법사 유저인 내가 보기엔 약았고 기분 나쁜 그런 스타일이라고나 할까. 단순히 말해서 마음에 안든다. 그 뿐이다.

비전: 냉정/마법차단 연마/감속

냉정은 분명 보조용으로/공격용으로 쓰기에 정말 유용한 특성기이다. 변이로 상대 중 누군가를 저항도 못 하게 만들거나 불작과 함께 써서 공격으로 쓰거나 하는 유용성이 있지. 하지만 결국 보조적인 성격이 강하다. 3분이란 쿨도 문제라서 맘대로 쓰지도 못 하는데다가, 공격용도인 불작과의 활용도 크리가 터지지 않으면 거의 의미가 없어지니 현재의 탄력둘둘 세상에선 빛이 바랠 수 밖에 없다.

마반(이것도 손에 익은 단어 -_-)연마는 비전의 특성 중 유일하게 빛나는 특성인 것 같다. 일단 캐스터 상대 시에만 사용이 가능하겠지만 4초 침묵이라는 것은 냉기이든 화염이든 비전이든 4초간은 마음껏 공격이 가능하게 한다는 점이다. 마반을 맞은 대상은 물론 욕하겠지만 침묵이 없다면 법사는 캐스팅 시 차단만을 노릴 수 밖에 없어서 상대의 캐스팅을 주시할 수 밖에 없고 결국 이는 컨트롤 저하로 까지 이어진다고 생각된다. 그런 의미에서 4초 침묵의 힘은 엄청나다고 생각한다.

감속은 마법 해제가 되지 않는다면 분명 엄청난 스킬일 것이다. 하지만 사제/성기사는 마법해제를 하고 도적은 그망으로 해제하고 사냥꾼은 발기로 해제한다. 드루는 변신만 하면 무조건 사라진다. 일단 마나소모 때문에 파티 플레이 시에는 쓰기가 껄끄러울 수 밖에 없다. 41포인트 궁극 특성인 주제에 사용할 대상이 한정적이라는 의미이다. 그나마 전사/주술사/마법사를 상대할 때는 쓸 만 하다는 평가를 할 수 있다. (흑마는 어차피 즉시시전기 위주로 싸울테니까. -_-++)

문제는 비전의 이 좋은 특성들을 가지고서도 공격으로 제대로 잇지를 못 한다는 점이다. 말 그대로 다른 원소 마법의 보조 용도의 마법들로 무장되어 있다. 신화/비작/신폭을 공격에 사용하는 것도 물론 가능하지만 도망치는 상대에게 신화로 마무리를 노리거나, 혹은 근접한 적에게 탈출할 방법이 없어서 신폭 난사로 어떻게든 데미지를 주려고 하는 것을 제외하자면 마땅히 좋은 공격 방법이 없다는 것이다.

-----

유용한 특성기를 살펴봤지만 역시 답을 구하기는 힘들겠지. 아 현재는 33/28 특성을 위주로 가끔씩 전장을 뛰고 있지만 이게 과연 새로운 답안이 될 수 있을까는 아직 불명이야.

간단히 살펴보자. 이 특성은 일명 비화 슈팅특성과 거의 모델이 비슷해. 타속이 들어갔다는 점만 빼면 말이지.
  • 충돌: 공방 양쪽에 일단 어느 정도의 확률을 더해 준다. 타갑을 함께 사용해서 밀리에게 좀 더 효과를 볼 수 있지만 밀레엑 얼갑을 사용하는 것도 제법 좋은 선택이라 갑옷의 선택은 역시 하기 나름. 공격 콤보 시 터지는 운빨을 노려보자.
  • 타속: 밀리에게서 탈출하는데 의미가 더 크다. 특히 도적에게서 탈출하기에 말이지. 결국 치고 빠지기 전략이 가능하다는 점인데 운빨이라 제대로 사용하기는 힘들다. 그저 탈출기란 말인가.
  • 화작: 화작 쿨이 짧아 진다는 건 상당히 좋다. 어차피 화염구를 거의 못 쓰니 이게 더 좋은 선택일지도 모른다. 더불어 크리확률도 높으니 말이지.
  • 화폭/냉정/신마강/불작: 공격 콤보 라고 봐도 된다. 화폭은 이속 저하로 탈출기의 효과도 있겠지만 일단 신마강과 냉정이 포함된 순간콤보에선 역시 즉시시전기의 조합이 중요하다.
  • 침묵마반: 뭐 캐스터 대상 용이지. 유용성은 누구나 다 알 듯.
  • 마감연마/굴절망토: 1포인트씩 투자했기 때문에 의미는 적지만 그대로 생존력에 좀 더 도움이 될까 해서 찍어봤어. 지능을 좀 더 올리게 해서 마나보막 사용에 도움이 될 수도 있겠지만 마나보호막은 손해가 너무 크지?

현재의 PVP는 캐스팅을 배제한다. 즉 캐스팅이 긴 마법은 봉인할 수 밖에 없는게 트렌드(?)이다. 심지어 밥이라던 전사 조차도 반사를 이용해 캐스터를 바보 만드는게 가능한지라 캐스팅기는 가능하면 쓰지 않는게 효율이 좋다. 아니 쓸 수가 없다. -_- 그럼 기본적인 공격은 불태와 화작으로 제한된다. 가끔 얼회로 얼리고 얼창을 쏘는 것도 생각 할 수도 있지만 그다지 효율은 좋지 못 한 것 같다.

불태와 화작의 크리 확률이 조낸 높다. 비록 탄력둘둘 세상이라 크리는 잘 안터지겠지만 조금이라도 더 터트리려는 의미가 짙다. 짧은 캐스팅 혹은 즉시시전이라는 메리트는 좋지? 크리데미지도 올려주는 특성을 찍은 지라 극대화 위주의 아이템 세팅도 필수이다.

기본적인 상대법은 상대를 불태와 화작으로 가지고 놀다가 콤보로 보낼 시점이 되었을 때 신마강과 장신구 등을 켜고 냉정+불작, 화작, 화폭 등의 순간콤보로 유린하는 것이다. 하지만 3분에 한 번 이라는 제한을 생각해서 가능하면 쓰지 않는게 좋을 지도 모르겠다.

콤보기의 활용의 가장 큰 의미는 힐러전 혹은 힐러가 포함된 파티를 상대할 때이다. 힐러의 힐링 능력은 이제 딜러의 능력을 크게 초월해서 도저히 피를 깎기가 힘든 만큼 이 콤보의 존재는 힐러의 방심을 이용해서 적을 사살하는데 주요한 무기가 될 것이다. 특히 노래방 같은 데서 깃수를 처치할 때 말이지. 침묵기도 가지고 있으니 정말 이런 용도로 설계된 특성이라고 봐도 되겠다.

타속을 보유하고 있다는 건 도적/전사/징벌기사/고양술사에게서 탈출하는 데 도움이 된다. 냥꾼과의 전투 상황에서도 근접 혹은 탈출의 목적으로 활용이 가능하다. 단지 그 뿐이겠지만 냉기와는 다른 생존력을 보유하게 된다.

하지만 여전히 흑마와의 싸움은 거칠 수 밖에 없다. 단지 마반의 침묵 기능을 잘 활용하는 수 밖에 없다. 때리면 피가 차는 복원술사 상대로도 크게 힘을 내지는 못 한다. 공격 주기가 짧은 불태와 화작 위주이기 때문이지. (훔치기를 남발하는 것도 해법이 안되잖아! ㅠㅠ)

좀 더 생각해 보자 -_-

게임이야기 :: 2008/03/03 11:50 :: RENN
Trackback : Comment

OOP를 착각하지마

컴퓨터는 엄청 단순한 기계지. 전자계산기 이니깐 말이야. 뭐 좀 더 기능을 붙여서 읽고 쓰고 수치판단(if 같은거)이 더 붙어있는 조금은 뛰어난 계산기이지. 이 말의 의미는 인간의 사고방식과 컴퓨터의 사고방식을 매치시켜서 생각하면 안된다는 거야. 그 자식은 그저 명령 내리는 걸 실행하고 결과를 내 뱉을 뿐이야.

가장 기본적인 C언어를 공부해 봤다면 알거야. 함수 라는 것 하나만을 제외하면 무척 단순한 구조이지. 보통 순차형 프로그램이라고 말 그대로 순서대로 뭔가를 실행하는 거야. 단지 숫자를 이용해 조건을 걸어놓으면 거기서 분기가 가능하고, 그 분기가 가능하기에 함수 같은 조금은 인간에게 편리한 기능을 쓸 수도 있지.

와 장땡이네. 어차피 저걸로 모든 소프트웨어 제작이 가능해. 근데 세상은 왜 이렇게 많은 언어와 개념이 존재하는 걸까?

OOPL vs OOP

OOP(Object Orient Programming)을 위해 OOPL(OOP Language)이 존재한다고 생각해 보자. OOP개념은 저기 던져두고 대표적인 OOPL인 C++과 Java를 타겟으로 조준해보자.

근데 C++이나 Java로 개발하면 그게 OOP의 결과물이 되는걸까?
아니야.
OOP의 기본 개념, 즉 클래스와 멤버, 메소드, 상속 등을 이용하면 OOP의 결과물이 되는걸까?
아니야.

이건 뭔가 중요한 걸 착각하고 있는 거야. 혹시 이렇게 생각해 왔던 사람 있어?

OOP

던져 놓은 OOP를 다시 주워왔다. -_-; 한번 생각해보자. OOP가 도데체 뭔데?

이름을 보면 오브젝트 기반의 프로그래밍이다. 캬 멋지네. 그럼 오브젝트를 이용해서 프로그래밍 하면 되겠군. 그 오브젝트를 구성하기 위해 클래스와 상속이란 개념도 있고 말이지. 그대로 써서 코딩하면 되겠군.

근데 여기까지 보면 OOP가 아니게 되지. 단순히 순차적 언어였던 C에 좀 더 복잡한 문법을 끼워놓은 코드 수준에서 벗어날 수가 없어. 왜냐구? 왜냐니... 코드를 잘 봐. 그저 순서대로 움직이고 있을 뿐이야.

내 말은 이거야. 코드에서 OOP를 찾아보는건 바보짓이라고.

OOP는 설계를 위한 개념이야. 전에 설계가 개발에서 가장 큰 부분을 차지한다고 이야기 했는데 바로 그 설계 부분을 좀 더 인간적인 개념으로 만들기 위한 체계가 바로 OOP야.

좀 더 정확하게 이야기 하자면, OOP는 사람의 사고방식에 좀 더 편리하게 오브젝트 기반으로 설계를 하고 이 것을 언어로 표현하기 위한 설계 개념이지. 즉 OOP방식대로 설계하고 코딩은 C로 해도 그건 OOP가 될 수 있어. 아니 내가 무슨 이교도적인 사상을 가지고 있는걸까?

C++이나 Java같은 언어는 OOP용 언어가 아니라, OOP형식으로 설계된 것을 코드로 옮기기에 적합하도록 문법을 지원하고 있는 언어지. 착각하지 말라고. 이미 C로 OOP화 된 결과물은 상당히 많고, 그 매력을 알고 Objective-C같은 언어까지 나와버렸어.

개밥에 OOP

정말 좋아보이지? 우리 모두 OOP를 쓰자. 그리고 개밥그릇에 들어가자. -_-+

뭔가 유행을 타고 있으면 만능처럼 여기는 세대들이 많지. OOP가 아마 그런거일거야. 무슨 광신도들 처럼 C++과 Java를 공부하고 쓰는 사람들이 많아지고 있지. 지금에야 이미 기본적인 사항이 되었을거야.

OOP는 설계를 위한 개념이라고 말 했지? 즉 설계를 잘 하지 못 하면 오히려 말짱 꽝이야. 오히려 순차적인 설계가 더 나은 개발 속도와 더 나은 결과를 보여줄 수도 있어. OOP 의 목적과 장단점을 안다면 오히려 맹신하지 않는게 정말 전문가 다운 거야.

OOP의 장점이 뭐? 인간적인 설계? 재사용성? 개나 줘버려. 극단적인 것 같아? 아니, 그 전에 설계에 대해 좀 더 중점적인 사고를 가질 수 있도록 자신을 개발하는게 더 중요하다는 말이야. 개가 가지고 놀다가 너덜너덜 해 질 때 쯤 설계의 노우하우가 몸에 박혀 갈테고, 그 너덜너덜 해진 개념을 조금씩 짜 맞추어 가봐. 당신이 지금껏 설계하면서 느껴온 힘든 점이 OOP가 보완해 줄 수 있을까 생각을 해봐. 비OOP적인 경험이 많을 수록 오히려 OOP의 더 많은 것을 알게 될거야.

그리고 순차적 프로그래밍에 대한 매력을 더 잘 알게 될거야. 킥킥
개발자적유희 :: 2008/02/28 12:13 :: RENN
Trackback : Comment

개발자의 실체에 대한 이야기

당신이 대학생이고 컴퓨터 관련 학과를 선택했거나 혹은 학과를 선택하려 한다면 진지하게 '개발자'라는 것을 생각해 보는게 좋을거야.

개발자 라는게 뭘까. 뭔가를 개발하는 거지. 그럼 개발은? 만드는 거야. 뭘 만들어? 소프트웨어일 확률이 80% 겠지. 틀려?

정의가 나왔네. 그럼 실제로 하는건 뭐야?

보통 소프트웨어를 만들 때는 기획-설계-구현-테스트 라는 귀찮은 순서가 있어. 대충 분류해도 이렇게 4단계야. 근데 여기서 설계-구현-테스트 라는게 개발의 주요 단계가 될거야. 테스트는 빼도 될까? 뭐 중요한 거니 빼기는 좀 거시기 하군.

기획은 왜 뺐을까? 개발하는데 기획이 없으면 개발이 안되겠지? 근데도 난 기획은 뺐어. 왜냐하면 기획은 학과/전공/종족(?)/직업/나이/성별/생명체군분류(?)와 무관하니깐. 아이디어와 직결되는 뭔가 외형을 잡고 있는 단계이니깐 개발로 넣어야 할 것 같으면서도 사실은 귀찮다는 이유로 뺀거야. -_- 근데 그래도 문제는 없어. 보통 회사에선 기획팀은 따로 분리되어 있으니깐. 와 개발이란 용어가 딱 정리되지? 쳇 -_-

그럼 학과 선택에 기준이 생겼어? 생겼으면 다행이겠네. 아니야 -_- 좀 더 본질을 깨달으라구.

당신은 소프트웨어 개발에만 흥미가 있어? 근데 그건 코딩에 한해서야? 좀 더 시야를 넓게 가져야 될거야.

설계가 간단하다고 생각해? 하지만 설계는 개발의 가장 중요한 본질이야. 개발자라면 계획에서 설계를 가장 크게 잡아야 될걸? 그래. 설계는 중요해. 그래서 소프트웨어 공학이란게 있는거야. 엄청 귀찮고 졸리는 용어들이 난무하는 소공의 세계. 뭐 그래도 소프트웨어 개발 자체가 좋다면 이 쪽 학과가 꽤나 어울릴거야.

근데 사실 컴퓨터용 소프트웨어를 작성한다는 건 컴퓨터의 작동 방식이라는 큰 걸림돌이 있어. 하드웨어 분야이지. 물론 당신이 컴퓨터를 처음부터 만들어 내는건 아니겠지만. (이런 저런 부품 제품을 사서 조립하는거 말고!!) 컴퓨터를 잘 알면 좀 더 빠르고 메모리를 적게 차지하는 프로그램을 만들 수 있을지도 몰라. 그렇다면 소프트웨어 공학 쪽도 중요하지만 하드웨어 관련 학문 비중이 좀 더 높은 컴퓨터 공학 자체가 좋을거야.

자. 어느 학과는 언어를 가르칠거야. 근데 언어가 뭘까? 대화하는 수단이지? 비슷해. 아니 좀 달라. 컴퓨터에게 명령을 내릴 때 쓰는 말이 컴퓨터 언어야. 우리는 컴퓨터를 지배하고 컴퓨터를 가지고 편한 생활을 추구해야 되.

근데 개발자는 명령 내리면서 편하게 노예처럼 부려야 되는 컴퓨터에게 등쳐먹히는 관계라고 생각되는건 왜일까. -_-;;;

어쨌든 언어는 존재이유가 명령이야. 그리고 언어 종류는 무지 많지. 근데 컴퓨터의 원어는 기계어고 공용어로 어셈블리어를 사용한다고 대충 생각해봐. 사람이 이해하기 짜증나서 더 고차원 언어가 만들어지고 이걸 기계어 번역기(컴파일러)를 도입해서 보통 사용하지. 아아 그나마 세상은 살기 좋아.

언제 한번 물어봐. "어떤 언어가 제일 좋아?". 답변으로 싸대기를 날려주지. 후훗.

언어란 건 말 그대로 수단이지 목적이 아니야. 어떤 언어 하나만 사용하기 보다는 많은 언어를 접해보는게 중요할거야. 물론 숙련도가 언어별로 있어서 하나하나 오래 써 보는게 더 잘 다루겠지만, 정말 중요한 건 언어라는게 설계를 바탕으로 실체화 하는 도구라는 거야.

하지만 이런건 생각할 수 있지. 하드웨어와 밀접한 관련이 있다면 좀 더 하드웨어가 이해하기 편한 언어가 더 직관적이고 빠르겠지. 오히려 더 편할수도... 그래서 컴퓨터공학은 어셈블리어와 C언어 비중이 높아. (C는 그나마 고급언어류 중에서도 저급(?)하기에 중간세대로 불리우지)

하지만 당신이 소프트웨어공학이거나 전산공학 쪽이라면 생각을 바꿔. 언어는 정말 도구일 뿐이야. 자유자재로 사용이 가능해야 되. 왜냐하면 언어 자체는 그 목적이나 설계 방법에 따라서 편한 녀석이 이것 저것 존재하거든. 그러니깐 특정 언어에 구애받으면 고생 잔뜩 하게될거야.

뭐 요즘은 OOP라는게 뜨고 있어서 대부분 C++, Java 같은걸로 바로 넘어가는 경우가 많아서 좀 짜증이야. 그래도 대세는 어쩔 수 없겠지 -_-. 근데 이거 하난 기억해 둬. OOP는 설계와 그 설계를 코드로 이끌어 내는게 중요한 거지 OOP용 언어로 코드를 작성하는 건 의미가 없는 행위라는 거. 이걸 못 하면 걍 C로 코드 짜는게 더 나아. 괜히 C++이나 Java 쓰지 말라구.

정리 되지? 한가지 도구만 잘 쓰는 것도 좋지만 여러 도구에 두루두루 익숙해지면 이 도구 저 도구의 좋은 점과 안 좋은 점을 두루두루 알 수 있어. 그럼 좀 더 적합한 도구 찾기가 가능해지지.

연구 라는걸 들어봤겠지. 개발 과정에서 연구를 포함할 수도 있어. 하지만 연구 과정에선 개발을 포함하지는 않지. 잘 생각해봐. 연구라는건 실체화 하기 위한 이론을 만들어 내는 과정이거든. 그러니 연구를 게을리 하지마. 자료구조 이론과 알고리즘 학문은 이런 연구 쪽에서 중요한 학문이니 꼭 공부하라구.

자 이제 결론은 내 보자. 근데 좀 다른 이야기가 튀어나올 듯.
당신은 코딩 한다라는 것과 프로그래밍 한다는 것, 그리고 개발한다는 것의 의미를 제대로 알고 있는걸까?

코딩과 프로그래밍 자체는 비슷해. 설계한 내용과 이를 구현하기 위해 연구한 것들을 이제 실체화 해야 되니깐 그것을 코딩하거나 프로그래밍 하는 거야. 근데 많은 이들이 코딩 자체를 개발로 오해하는 경우가 많더라구.

명심해. 개발은 최종적으로 소스 코드로 탄생하기 위해 설계를 하고 그 설계 기반으로 필요한 것을 연구하고 그 설계와 연구 이론을 바탕으로 그냥 적으면 되. 코딩이란 아주 작은 부분이란 거지. 설계가 50% 연구가 20% 라면 테스트가 29%이고 코딩은 1%야. 극단적이야? 아니 이게 맞아. (아니 사실 상황에 따라 조금 틀리겠지만 코딩이 제일 적은건 맞아)

테스트 비중이 큰 거 같아? 아니야. 테스트 비중이 낮을 수록 당신의 프로그램은 그 가치가 떨어져. 고물이지. 근데 테스트를 하면서 문제를 찾아내고 고치면서 점점 빛이 나. 보석으로 변해가는 거야. 오우 이거 죽이네. 보석세공 하는 것 같아 +_+

자 이제 개발자의 실체를 알았겠지? 힘내. 그리고 고민해.. 학과를 바꿔. 성적이 안되면 어쩔 수 없지만 일단 의학이나 법학이 차라리 더 좋을거야. 결국 컴퓨터 관련 학과로 들어왔어? 어쩔 수 없지. 힘내서 공부해. 그리고 빨리 이민을 준비하는게 좋을거야.

아니면 우리나라에서 개발자 라는 3D 초절정 좌절 직업을 계속 하던가...

왜 이런 이야기를 하느냐. 기획팀과 개발팀이 분리되어 있는건 일반적이지? 선진국의 경우 기획=개발 이라는 가치를 가져. 어차피 개별 부서니깐. 근데 우리나라는 기획>개발 이런 가능성이 높아. 그리고 기획은 경영/영업쪽과 밀접해버리는 큰 문제가 있어. 결국 개발자는 초라하게 구석에 쳐박혀서 컴퓨터 앞에 앉아서 야근이나 하고 기획이나 경영 쪽에서 명령만 듣고 아무 반박도 안하는 그런 사람이야. 그게 현실이야.

왜 일정은 기획팀에서 잡는 건데?!! 왜 개발팀에서 일정을 바꾸질 못 하는 건데?!!!

이제 정말 본질을 아셨으리라 본다. 화이링.
개발자적유희 :: 2008/02/27 12:28 :: RENN
Trackback : Comment

보통 사람을 위한 몇 가지 용어: 오피스/워드/엑셀...

알고보면 오피스 라던가 워드, 엑셀이란 용어는 Microsoft에 의해 제작된 제품명이 널리 사용되면서 정착되어 버린 우리사회의 큰 문제점이라고 볼 수 있어. 이거 알고 있었어? Microsoft Excel(TM), Microsoft Word(TM), Microsoft Office-suite(TM). 전부 TM(Trade Mark)가 붙어있는 제품명이지.

그럼 정확한 용어를 살펴보자.

오피스 슈트(Office-suite):
오피스라는건 사무에 적합한 프로그램 묶음을 의미하지. 뭐 보통 통하는 용어이지. 정확히는 슈트까지 붙여서 말해야 할거야. 왜냐하면 오피스는 마이크로소프트의 제품을 지칭하는 대명사이니깐. Openoffice-suite의 경우도 비슷해. (난 물론 오픈오피스를 추천해. 오픈소스이고 무료로 사용이 가능하니깐)

스프레드 쉬트(Spread Sheet):
엑셀(Excel), Calc(오픈소스도 있고 Openoffice 제품군에도 있고), Lotus123 등등 표를 기반으로 문서를 작성하는 툴인데 주로 계산이나 통계 쪽에 적합하도록 만들어져 있지. 그래. 보통 엑셀이라고 말하는 프로그램의 분류이지.

워드 프로세서(Word Processor):
워드(Word), 아래아한글(HWP), 오픈오피스 라이터(Openoffice Writer) 등등 문서를 만드는 툴이야. 정말 문서 만드는데 유용하지. 그래. 워드라고 하지 말고 워드프로세서라고 해야 정상적인 제품군으로 분류가 가능해.

프리젠테이션 소프트웨어(Presentation Software):
아 이거 분류명이 맞는지 모르겠어. 보통 파워포인트라고 하지?  그거 마소의 제품명이야. 근데 대명사가 되어버려서 짜증나는 녀석이다. 오픈오피스에도 있고 애플에서 만든 다른 제품명의 것도 꽤나 유명한데 말이야.

--
보통 스프레드쉬트 라는 용어는 유명하지 않아서 잘 모르겠지? 이건 알아두면 좋을거야.
개발자적유희 :: 2008/02/27 11:35 :: RENN
Trackback : Comment

보통 사람을 위한 몇 가지 용어: 컴퓨터 관련 학과 이야기...

컴퓨터 공학 전공인 어떤 사람에게 전화가 왔다. '야 너 컴공이랬지. 엑셀에서 이거이거이거이거이거 어떻게 해?'

전산 공학 전공인 어떤 사람에게 전화가 왔다. '야 나 컴퓨터 좀 고쳐줘'

ㅆㅂ ㅆㅂ ㅆㅂ ㅆㅂ ㅆㅂ ㅆㅂ ㅆㅂ

컴퓨터 관련 학과라면 많아서 열거하긴 힘들겠지만 보통 컴퓨터 공학, 소프트웨어 공학, 전산 공학/과학 정도일 듯 하다.

이런 학과는 각자 특색이 있지만 중요한 일치점은 컴퓨터의 정말 원초적인 존재 이유(계산기 -_-)와 이것을 이용하는 방법론(알고리즘/소프트웨어 개발 등)에 있다. 단지 어디에 비중이 있냐 하는 점이 틀릴 것이다. 이를테면 알고리즘이나 소프트웨어 개발에 중점이 있다면 소프트웨어 공학(소프트웨어 설계가 중점) 혹은 전산 공학(알고리즘 등)에 가깝다. 하드웨어와 소프트웨어 양 쪽 사이의 궁합 쪽에도 포커스가 있다면 컴퓨터 공학 쪽에 가깝지. 하드웨어에 크게 관여한다면 전자 공학 쪽에 가까워 지는 점도 있고...

제일 위에 두 가지 예는 가장 크게 오해받는 거라고 생각한다. 이런 전공 학과를 공부한다고 특정 툴(예에서는 엑셀)이나 특정 하드웨어(컴퓨터 고장 등)를 모두 잘 하는건 말도 안되는 이야기이다.

모두들 알고 있도록.

이런 사람들에게 물어보고 이런걸  물어봐라.

1. 어떤 프로그램이 죽었다. 전공자에게 물어보자:
"이 프로그램이 죽었는데 에러가 segmentation fault래. 어느어느 지점에서 죽었고. 뭔가 이상한 파일이 하나 생기긴 했네. 관련 로그 파일도 찾았어. 혹시 알아봐 줄 수 있겠어? 필요한 정보 보내줄게."
올바른 질문 방법이다. 물론 해결 가능성은 낮아. 아니 그 전에 질문할 수 있겠어? 낄낄

2. 네트웍 잡는데 용어를 잘 모르겠다. 전화해보자:
"야 네트웍 잡는데 마스크가 뭐냐?"
"DNS는 또 뭐야? DHCP가 뭘까..."
학과에 따라 반응은 다를 수도 있지만 관련 학과 쪽에서 많이 배우는 이론이다.

3. 원초적인 전문 용어는 물어볼 만 하다:
"이더넷(ethernet)이 뭘까?"
"루아(lua)가 뭐야? 파이썬(python)이 뭐야?"
사람마다 관심 분야에 따라 답변 가능성이 틀려진다. 하지만 물어볼 만한 질문이다.

그리고 엑셀 같은건 경영/통계학 쪽에 물어보는게 훨씬 해답을 얻기가 빠를거야. 전산학과는 엑셀 쓸 이유가 별로 없어. 계산하는 프로그램 만드는게 더 원초적이거든.

워드 같은건 인문/사회학에게 물어봐. 워드 사용 빈도가 전산학 보단 훨신 높으니깐... 전산학에선 알고리즘을 pseudo-code로 짜거나 프로그램을 만들어서 제출하는게 훨신 많을테니깐.

전산학 쪽에서 많이 쓰는 툴은 컴파일러, 스크립트 에디터, 인터프리터, 디버거 정도가 다야. (IDE, RMD툴도 포함할 수도 있지만 원초적이진 않지) 이런 툴이 궁금하면 물어봐. 근데 이런 툴을 쓰는 거라면 당신도 전산학도일 가능성이 높군. 낄낄
개발자적유희 :: 2008/02/27 11:16 :: RENN
Trackback : Comment

보통 사람을 위한 몇 가지 용어: 바이러스/웜 등...

흔히 바이러스라 불리우는 군(바이러스/웜/트로이 등등)에 대해서...

컴퓨터 바이러스(Computer Virus):
바이러스라는 녀석은 특정한 감염 경로를 거쳐서 몸에 침투해서 이런 저런 악영향을 끼치고 또 다른 이에게 전염되기 위한 특별한 메커니즘을 가지고 있는 조그마한 생물(?)이다. 비슷하게 컴퓨터 세계에서 바이러스라 정의된 것도 특정 감염 경로를 거쳐서 특정OS에 의해 로드되어서 실행되면서 알 수 없는 뭔가 작업을 수행하고 다른 컴퓨터로 자신을 퍼트리려 하는 조그마한 프로그램이다.

특징이 있다면 대게 바이러스는 정상적인 프로그램 혹은 데이터의 일부분에 바이러스 코드가삽입된 채로 전파된다는 점이다. 즉 그 프로그램을 실행하는 순간 바이러스가 동작한다는 의미이다. 이런 식으로 바이러스가 실행되어 버리면 감염되는 것이다.

그리고 바이러스는 자신을 전파하기 위해 그 컴퓨터에서 실행되는 모든 프로그램에 자신을 집어넣어 버린다! 그리고 이렇게 감염된 프로그램이 누군가에게 옮겨 지길 기다린다. (즉 공유 사이트에 업로드 해서 누군가 다운로드 해서 실행한다면 어떻게 될까)

위에까지의 이야기는 좀 구시대적이긴 하지만 가장 기본적인 컴퓨터 바이러스의 메카니즘이다. 현재의 바이러스는 OS나 특정 애플리케이션의 보안 헛점을 이용해서 실행 프로그램이 아닌 데이터 파일에서 바이러스 코드를 실행시킬 수도 있는 등 상당히 많은 종류가 존재한다. 하지만 바이러스라 부르는 기준점은 자기자신이 아닌 무언가에 묻어서(!) 전파되고 증식 시킨다는 점이다. 그리고 또 다른 감염을 위한 수단도 가지고 있을 수가 있다.

바이러스는 이런 증식을 위해서 시스템을 급속도로 망가뜨리지는 않는다. 감염된 프로그램도 원본 그 상태를 거의 그대로 유지하고 있어서 프로그램 실행에도 거의 대부분 문제가 없다.  따라서 바이러스는 백신 등으로 치료가 가능한 경우가 많다. 물론 훼손 정도에 따라 차이가 있지만 말이지.

감기는 공기중의 감기바이러스나 누군가의 기침(프로그램)에 묻어 나온 바이러스 등이 자신의 몸에 들어와서 걸린다. 감기에 걸리면 아프다(악의적인 행동). 자신이 기침을 하거나 해서 감기 바이러스가 침(프로그램)에 묻어서 타인에게 전파(복사, 업로드 등)될수 있다. 이렇게 생각하면 편하겠지? --

웜(Worm):
웜이라 부르는 것도 바이러스와 비슷하게 작은 프로그램이다. 하지만 대게 웜은 다른 프로그램 내부에 숨어서 전파되는게 아니라 특정 OS나 소프트웨어의 헛점을 이용해서 자신을 전파하는 점이다. 프로그램을 감염시키는게 아니라 특정 컴퓨터로 자신을 복제시키고 웜을실행시킨다. 물론 웜도 대부분 악의적인 내용을 실행하는게 일반적이다.

간단히, 벌레가 들어와서 집 짓고 알까고, 알에서 새끼가 부화해서 딴데로 가버리는 거야. 벌레 있으면 기분 더럽지? 바로 그거야!

실제로 대표적인 예로 옛날에 윈도우의 특정 계정에 비밀번호를 설정하지 않으면 원격에서 그 컴퓨터의 프로그램을 실행할 수 있는 버그가 있었지. 가만히 있는데 아무짓도 안했는데 컴퓨터가 갑자기 오동작 하는거야. 기분이 어떨 것 같아?

바이러스와의 차이점은 특정 매개체를 이용한 감염이 없다는 점이다. 컴퓨터 내부에서 증식이라는 과정, 즉 타프로그램을 감염시키는작용도 물론 없다. 대신 자신을 복제해서 다른 컴퓨터에도 웜을 전파하기 위하 역시나 그 컴퓨터에서 다른 컴퓨터의 헛점을 찾아내고복제해서 실행시키려 한다. 그래서 그런지 웜은 치료가 간단한 경우도 많다. 어떤 것은 삭제하면 끝날 정도로...

잠 자는 사이에 왠 벌레가 몸에 기어 올라왔다. 잠이 깼다. 악 벌레다! 놀래서 이리저리뛰다가 어딘가 부딪혀서 다쳤다. 나는 망가지고 벌레는 내 방에 알 까고 다른 방으로 가버렸다. 미래는 어떻게 될 것인가!-_-;;;; (아 이거 비유가... 낄낄) --

트로이의 목마(Trojan):
트로이의 목마는 유명하니깐 알겠지. 거대한 목마에 병사들이 숨어서 기다리다 기습한 것. 컴퓨터 계의 트로이의 목마(축약해서 트로이라칭하겠다)도 비슷한 메커니즘이다. 즉 목마안에 숨은 병사 처럼 어떤 프로그램에 다른 프로그램이 숨어있다가 그 프로그램이 실행되는 순간 그 다른 프로그램도 실행되는 것이지.

바이러스 처럼 감염된 형태 같지만 실제론 좀 다르다. 트로이는 대체로 바이러스 처럼 감염되고 전파되는 형태가 아니라 누군가 직접 프로그램 내부에 트로이를 끼워 놓은 경우이다. 트로이는 그저 그 컴퓨터 내에서 실행되어서 그 컴퓨터에 악의적인 영향만을 끼치고 끝나는 형태가 많다. 다르게 본다면 fake-software(가짜 -_-) 와 비슷하게 볼 수도 있다. 즉 전파되는 경로는 트로이가 포함된 프로그램을 자신이 다운로드 받거나 해서 실행하는 방법 등이 있다.

(fake-software는 트로이로 분류하지는 않는다. 숨어있는건 아니니깐. 하지만 비슷한 느낌을 가질 수도 있기에 트로이로 착각하는건 실수가 아니겠지)

트로이는 치명적이라고 보면 된다. 누군가 유명한 프로그램에 이 트로이를 집어넣어서 배포한다면 다른 누군가 그것을 실행해보고 잘 돌아간다고 생각한다는 사이에 갑자기 트로이에 의해 공격받는다. 트로이의 공격은 시스템을 심각하게 망가뜨릴 수도 있다. 어차피 자신을 전파시킬 명분이 없기에 망가뜨리는 걸 너무 좋아한다. 대신 트로이가 숨어있는 프로그램은 정상적인 프로그램인 경우가 많다. 트로이 자신을 숨겨야 할테니 말이지. 말 그대로 기습을 위해서는 당연히 자신을 숨겨야 하는게 아니겠는가.

정체 불명의 사이트에서 뭔가를 다운로드 받았다. 압축을 풀어보니'섹시므흣.exe' 이런 파일이 나오더라. 아 실행하고 싶어져! 실행하고 싶어져! 참지 못 하겠어! 아아아아! 결국 실행했어!오오오 죽인다! 라고 잠시 즐기는데 갑자기 컴퓨터가 좀 느려지네. 리붓했더니 부팅이 안되. 악.... ;ㅁ; 엄마! --

투르킷(Root-kit):
루트킷은 좀 더 고수준의 지식을 요구하는 것 같다. 이 것도 악영향을 끼치는 프로그램인건 분명하지만 작동하는 방식은 좀 다르다.대개의 바이러스나 웜이나 트로이는 본체가 존재하지만 루트킷은 일명 후킹(hooking, 가로채기?) 방식을 통해 자신을 실행시키거나 혹은 정상적인 프로그램을 오동작 시킨다. 후킹을 설명하기는 좀 수준이 높아지니 포기할런다.

확실히 위의몇 가지 분류와의 차이점은 완벽한 프로그램이 아니라는 점이다. 즉 프로그램의 일부분 만을 가지고 있고 이것을 잘 실행되고 있는메모리상의 프로그램 코드와 바꿔치기 해버린다 라고 설명하면 되려나. 그래서 은폐가 잘 된다. 그래서 대게 치료가 힘든 경우가 많다. 대신 감염이라는 것이 메모리 상에서만 이루어지기 때문에 이 루트킷이 다시는 실행되지 않도록 잘 조취하고 컴퓨터를 리셋하는것 만으로 증상을 고칠 수도 있긴 하다. (문제는 실행 안되게 하는 방법이 어렵다 -_- 루트킷 자체가 로드 메커니즘을 보호하기 위한 메커니즘을 가지고 있기 때문이지)

윈도우 작업 관리자에서 죽여도 죽지 않고 다시 살아나는 프로세스를 본 적이 있는가? 정말 최악이야. 이것이야 말로 진정한 좀비이지. 유닉스의 좀비 저리가라 수준이야. -_-;;;; --

스파이웨어(Spy-ware):
이름에서 느껴지듯이 뭔가 정보를 뽑아내기 위한 소프트웨어인데 그 자체로 바이러스 군으로 포함하기는 좀 거시기 하다. 그래도 유명한 녀석이니 한번 정리해 보자.

스파이웨어는 웜과 트로이와 비슷한 실행경로를 가지고 있다. 심하게는 IE의 보안헛점을 이용하거나 active-x를 통해 사용자가 실행해 주길 기다리고 있기도 한다. 즉 전파 경로는 무궁무진하다.

스파이웨어는 컴퓨터를 망가뜨리기 위해 퍼지는 게 아니라 무언가 정보를 수집하기 위해 배포된다. 예를 들어 작게 보면 사용자의 OS통계를 내기 위해 정보를 모으는 녀석, 심한 경우는 키보드로 입력하는 패스워드 등을 가로채거나 사용하는 계좌 정보를 모으는 등 중요한 개인정보를 정리해서 누군가에게 알려주기도 한다. 이 외에도 수집 대상은 무궁무진하다.

생각해봐. 자신의 ID와 패스워드가 누군가에게 그냥 알려진다니 끔찍하지 않아?

그렇기에 스파이웨어는 시스템에 악영향을 끼치지는 않는다. 자신이 실행되지 않으면 의미가 없어지니깐 말이다. 그리고 대체로 감염이나 전파를 위한 메커니즘은 가지고 있지 않다. 대신 한번 실행되면 잡아내기 힘들게 루트킷의 메커니즘을 이용해 자신을 보호하기도 한다.

스파이웨어는 정상적인 소프트웨어로 생각할 수도 있다. 그 의도에 따라서 악의성을 판단해야 하겠지. 어딘가의 회사의 소프트웨어를 공짜로사용하는 대신에 이상한 프로그램이 설치되거나 하는 경우도 있는데 대게가 스파이웨어다. 하지만 중요 정보를 빼가지 않는 경우도 있고 Ad-ware등에서는 광고를 위한 수단으로 쓰이기도 하기에 무조건적으로 악영향을 끼치는 군으로 생각하기도 조금 어렵긴하다.

WOW하는 사람은 알겠지. 갑자기 튕기거나 할 때가 있을 거야. 특히 심하면 프로그램이 죽으면서 뭔가 에러메시지가 화면에 나오지. 그리고 그 창에는 send/cancel버튼도 보이고. 이것은 죽은 원인을 블리자드에서 파악할 수 있도록 하기 위해 에러 정보를 보내는 프로그램이라고 생각하면 되. 대신 좀 많은 시스템 정보가 함께 날아가. 만약 여기서 사용자가 send/cancel을 선택할 수가 없다면 그 프로그램은 스파이웨어가 되겠지. --

이상은 몇 가지 세부 분류이다. 문제는 요즘에 나오는 것들은 위의 메커니즘이 혼합된 경우가 많다는 점이다. 웜의 기능을 가진 바이러스 라던가, 웜이 루트킷 형태를 가져서 치료하기 힘들게 하던가 등등 말이다.

분명한 건 트로이의 목마라는 분류이다. 이 녀석은 감염이라는 것을 행하지는 않으니 말이다. 하지만 트로이는 가장 조심해야 할녀석일지도 모른다. 완벽하게 시스템을 망가뜨리려는 악의가 숨어있다. 반면 다른 종류는 자신을 배포하기 위해서 시스템을 완전히망가뜨리지는 않는다.

아니 이걸 정말 잘 명심해. 위의 바이러스 분류에서 나온 것 전부가 시스템에 악영향을 끼친다는건 명백한 사실이다. 작게는 시스템의 자원을 잡아먹고 크게는 시스템을 망가뜨린다. 바이러스 백신 등등의 보안툴에서 보내오는경고를 결코 소흘히 하지 말라. 안그럼 당신의 컴퓨터 뿐만 아니라 타인의 컴퓨터까지 위험해지는 결과를 초래하게 되니깐.
개발자적유희 :: 2008/02/27 10:24 :: RENN
Trackback : Comment
Admin :: RSS