Unity3D

출처: http://blog.daum.net/jty71/15645104

길 찾기 알고리즘, A* 알고리즘, A Star라고 발음한다. 상당히 오래 전에 만들어진 알고리즘이다. 게임 제작에서 가장 기본적으로 가르치는 방법이라서 외국 글을 읽어 단순히 번역하지 않고 다시 정리해서 올린다. 유사한 방법에 Dijkstra[다익스트라]라는 사람이 만든 방법이 있다고 한다. 발음법이 특이한 것은 네덜란드 사람이라서 그렇다. 약간 독일어를 닮은 언어다. 아마 A*의 원형일 것이다. 컴퓨터 공학과에선 가르치는 것 같다. 우린 모르지만...

 <그림 : 기본 개념>

먼저 알아야 할 것부터 정리하면 이렇다. 컴퓨터는 봉사에 귀머거리다. 그래서 화면 전체를 볼 수 없다. 비유를 하면 봉사 슈퍼 개미가 빛의 속도로 화면을 돌아다니며 더듬어서 길을 찾는 것이다. 일을 간단하게 만들기 위해서 지도를 바둑판 형태로 나눈다. 이것을 격자(Grid)라고 부른다. 그래서 하나의 사각형, 육각형, 삼각형 안에서 다른 것 안으로 이동하거나 또는 바둑판처럼 하나의 교차점에서 다른 교차점으로 이동하는 형태로 생각한다. 사각형, 육각형, 삼각형은 평면을 알뜰하게 나누어 사용할 수 있는 도형이다. 주로 사각형을 많이 쓰지만 뭐를 써도 가능하다. 그렇게 구역을 나누고 각 구역은 뭔가 기억할 수 있는 능력이 있다고 하자! 즉, 각 바둑판 사각형이나 십자 교차점은 컴퓨터에서 말하는 2차원 배열이 된다. 다시 말하면 길을 찾기 위해 지도에 뭔가 표시할 수 있도록 하는 것이다! 여하튼 움직임은 연속적이지 않고 계단식으로 간격을 두고 움직인다! 그리고 그 지점에 뭔가 표시를 한다. 이런 것을 Node[노우드](마디)라고 부른다. 이 말은 원래 나무 형태의 구조에서 가지가 갈라지는 부분을 부르는 말이다. 이런 이름이 붙은 이유는 바둑판에 표시한 길을 보면 마치 나무 가지 형태를 하게 되기 때문이다. 보통 Node가 나오면 List가 따라 나온다. Linked List(연결 목록)이란 것은 배열이다. 그런데 서로 누가 먼저 누가 나중인지 연결된 정보를 가지고 있다. 그래서 순서를 자유롭게 바꾸고, 삽입과 삭제가 쉽다. 지도에 표시하는 대신 이 Linked List를 사용하여 길을 기억하는데 이 연결 상태를 그려보면 나무(Tree) 모양이 된다. 그래서 Node라고 부른다.(^^) 우리의 봉사 슈퍼 개미는 바로 옆의 8개 점만 검사할 수 있다. 그래서 8방향 탐색이다!(^^) 이 8방향에서 또 각자 다음 주변 8방향으로 물결처럼 퍼져나간다. 그런데 이렇게 무조건 8방향으로 퍼져나가면 좀 문제가 있다. 하나만 선택해서 계속 깊게 나가야 한다. 우린 넓이 우선 탐색을 하는 것이 아니라깊이 우선 탐색을 하는 것이다. A 스타는 깊이 우선 탐색 + 넓이 우선 탐색이다. 처음엔 계속 가능성이 높은 것 하나를 선택해서 깊게 나간다. 그러다 막히면 나머지 가능성 중에서 하나를 선택해서 넓게 나간다. 그 가능성 높은 방향을 선택하는 방법이 바로 A 스타 알고리즘이다.

 <그림 : 유사 방법>

<그림 : 진짜 방법>

 a star pathfinder v. 1.92.zip

A*란 8방향을 탐색해야 하며 8방향 중에 어느 하나를 선택하는 방법으로 이미 왔던 거리와 목표까지 예상 거리의 합을 사용해야 하는 것이다. 그렇지 않다면 A*라고 부르기 어렵다. 이 가장 기본적이고 가장 실용적이게 보이는 방법도 문제가 많다.(^^) 아주 긴 장벽을 넘는 것이 어렵게 보인다. 또한 호랑이 입이나 항아리 구조 같은 지형에서도 시간 소모가 많다. 가장 짧은 거리를 선택한다는 것은 말 그대로 Sorting을 한다는 것이고 그러면 시간이 많이 소모된다. 또한 검토할 지점과 이미 검토한 지점을 목록(Linked List)에 잘 저장해서 찾아야 한다. 다만 책에 이름이 자주 거론되니 궁금해서 공부했을 따름이다. 좀 더 간단하고 효과적인 방법이 있다. 이쪽에서 저쪽으로 가는 길을 찾는 것은 복잡하지만 반대로 저쪽에서 이쪽으로 오는 길을 찾는 것은 쉬울 수 있다. 항상 반대로 생각해 봐야 한다. 그래서 양방향 탐색을 한다. 또한 우리가 산 속에서 또는 사막에서 또는 초원에서 또는 바다에서 길을 잃었다고 하자! 그럼 제일 먼저 찾는 것이 뭔가? 산 속에선 계곡의 물줄기다. 따라가면 큰 강이 나온다. 사막이나 초원에선 강을 찾거나 산맥을 찾아야 한다. 바다에선 육지를 찾아야 한다. 모두 경계라는 특징이 있다. 마찬가지로 갈 수 있는 길과 갈 수 없는 장애물 사이의 경계가 바로 따라가야 할 길이다. 장애물이 없다면 무조건 목표 방향을 향해 직진하는 것이 빠르다. 실제 게임에서 Unit들의 움직임을 보면 장애물을 만나기 전까지는 일직선으로 이동한다. 장애물을 만나면 벽을 따라 이동하는 것을 알 수 있다. 물론 이 길을 찾는 방법을 개발해야 하지만 별로 어렵지 않다. 아래 그림을 봐라!

<그림 : 기타 방법>

A*와 유사한 결과를 내지만 더 간단하다. 이 방법은 내가 고민하다가 기억해 낸 것이다. 인터넷에 찾아 보면 우선법/좌선법(우수법/좌수법!? 뭐라고 하든 무슨 상관이냐?)이라는 벽 타기 기법이 유사하다는 것을 느낄 것이다. 미로에서 오른 손이나 왼 손을 벽에 붙이고 계속 가면 출구가 나온다는 그런 이야기다. 이 방법은 계속 벽에 붙어 있기 때문에 벽에서 떨어지는 상황에 대응한 위의 방법과는 다르다. 어느 경험 많은 프로그래머에게서 오래 전에 들은 이야기다. 당시 게임 제작에 대한 막연한 호기심으로 질문을 했었다. 그 사람들 경험으로는 게임 제작은 엄청 골치 아픈 분야라고 한다. 컴퓨터를 생각하도록 만드는 작업은 정말 어렵다. 이런 길 찾기는 아주 쉬운 편에 속한다고 한다. 한 참 후에 세월이 흘러 직접 게임 제작에 관한 글을 쓰다가 궁리 끝에 뭔가 아이디어가 떠올랐는데 알고 보니 옛날에 누군가에게 들은 것이었다.(^^) 진짜 실력이 있는 프로 게임 제작자들은 이미 답을 알고 있었다! 컴퓨터 공학과나 수학과에서 다루는 분야이니까! 컴퓨터는 컴퓨팅(계산)하는 장치이니 수학과와 친하다. 우리 아마추어만 모르고 있었다! 내가 게임 업체의 비밀 알고리즘을 하나 듣게 된 것이었다. 어디 가서 말하지 말라고 했지만 내가 게임 제작자가 될 수도 없는 입장에서 세월은 흘러 이미 늙어 버렸으니 내겐 더 이상 감출 비밀이 아닌 것 같다! 어린 학생들 좋은 꿈 꾸라고 이렇게 글을 올린다. 한국 게임 업체의 비밀은 외국 게임 업체에 비하면 비밀도 아니니까!(^^) 게임 분야는 너무 경쟁이 심하다. 장래 희망이라면 잘 고려해 보길 바란다!

이 글의 참고가 된 A* Path Finder C Code(압축 파일 첨부)를 분석하기 좋게 그림으로 정리한 것이다. 먼저 자료 구조를 이해하면 알고리즘 분석이 쉽다. 모든 프로그램에서 배열과 변수 등의 용도를 이해하면 알고리즘이 쉽게 분석 된다. 그림에선 10 x 10의 타일 방식 지도를 사용한다고 가정한다. 그리고 게임의 인구 수를 100명이라고 본다. 10 x 10의 지도에선 아무리 복잡한 경로가 나와도 10 x 10의 절반보다 약간 많은 길이의 배열이면 담을 수 있다. 10 x 10의 지도 경계에는 갈 수 없는 영역 표시를 하는 것이 편한데, 소스 코드에선 그런 방식을 사용하지 않았다. 지도에서 빨간 셀의 S는 시작 위치고 파란 셀의 T는 목표 지점이다. 빨간 색은 이미 검토한 셀이고, 노란 색은 검토할 셀이다. 노란 색의 검토할 띠 모양의 경계 부분에선 다음 경로를 선택하기 위해서 F값을 계산한다. 가장 작은 F값을 가진 위치를 찾아야 한다. 고로 노란 색의 좌표와 정보를 모아 두는 배열이 필요하다. 최대 탐색 크기는 지도 전체를 복잡하게 탐색하더라도 10 x 10이 되지 못 한다. 여하튼 100개까지 가능할 리는 없지만 100개의 목록에 노란 색의 좌표와 정보를 담아 둔다. 각 인구 수에 맞게 각자의 찾은 길을 기억할 배열을 만들어 연결시킨다. 

2D 배열 : walkability = 갈 수 있는지 없는지 여부

2D 배열 : whichList = 노란 색(검토 대상)에 속하는지, 검토 완료인지 여부

2D 배열 : parentX = 어디서 왔는지에 대한 정보 X방향(부모 좌표)

2D 배열 : parentY = 어디서 왔는지에 대한 정보 Y방향(부모 좌표)

2D 배열 : Gcost = 경로의 비용 누적 값

위의 배열은 지도의 형상과 그대로 대응되는 2차원 배열들이다. 이 지도에 찾은 경로가 기록된다. 찾은 경로는 목표 지점에서 출발 지점으로 거꾸로 역추적하여 힙 영역에 배열로 만든다.

1D 배열 : openList = 목록 관리용 배열 참조 값(포인터로 사용) 저장

1D 배열 : openX = 검토 대상 타일의 X좌표

1D 배열 : openY = 검토 대상 타일의 Y좌표

1D 배열 : Hcost = 검토 대상 타일의 H값(목표까지 직선 거리)

1D 배열 : Fcost = 검토 대상 타일의 F값(최소 값을 항상 선택)

검토 대상 타일(노란 셀)의 정보를 담고 최소 F값을 찾아 처리 후 그 셀의 정보를 목록에서 삭제하고, 새로운 0 ~ 7개의 검토 타일의 정보를 목록에 추가 삽입하는 목적의 배열들이다. 최소 값 찾기와 삽입 삭제가 자주 일어나는 목록이다.

1D 배열 : pathLength = 찾은 길의 길이

1D 배열 : pathLocation = 현재 가고 있는 단계

1D 배열 : *pathBank = 실제 길의 좌표를 담은 배열을 가리키는 포인터

1D 배열 : pathStatus = 경로의 상태

1D 배열 : xPath = 현재 가고 있는 단계의 X좌표(유닛의 좌표)

1D 배열 : yPath = 현재 가고 있는 단계의 X좌표(유닛의 좌표)

각 유닛이 각자의 찾은 길을 기억하고 어디쯤 가고 있는지 확인하기 위한 배열이다. 실제 경로는 지도에서 역추적하여 배열로 힙 영역에 만들고, 목적지에 도달하면 지우는 방식이다. 

노란 색 타일에서 자신의 부모를 결정할 때는 주변 8개 타일에서 빨간 색 타일을 고른 후에 자기 자신에게 오는 G 값을 계산하여 가장 작은 쪽을 부모로 선택한다. 대각으로 왔으면 2의 제곱근인 1.414배의 비용이 든다. 이 때 대각으로 진행이 불가능한 코너 구조가 있으니 이를 판단해야 한다. 대각으로 진행할 때는 그 타일의 주변이 모두 비어 있어야 한다. 노란 색 타일에서 앞으로 나아갈 방향을 결정하기 위해서 주변 8개 타일을 검토할 때는 빨강도 노랑도 아닌 영역일 것이다. 이것들은 새로운 노란 타일로 목록에 추가 되어야 한다. 아마도 0 ~ 7개까지 될 것이다. 최소 F값을 찾고 목록에 삽입, 삭제가 쉬운 형태의 자료 구조를 고안해서 목록을 다룬다. 항상 하나의 셀이 빠져 나가고 새로운 0 ~ 7개의 셀이 추가 된다. 최소 F값인 셀을 찾기 위해서 미리 정렬을 해서 순서를 맞출 것인지, 아니면 매번 비교를 통해 최소 F값인 셀을 선택할 것인지 효율성을 따져 봐야 한다. 정렬에 들어간 시간과 비교에 들어간 시간을 비교해 보아야 한다. 이 C 코드에선 구조체 배열 사용하지 않았다. 가능하면 1차원 배열을 사용하는 것이 속도가 빠르다. 배열의 차수가 높아지면 포인터의 첨자 계산 시간이 추가로 소모된다. 이 소스 코드에선 길이 있는지 없는지는 목표 지점의 정보(평지인지 장벽인지)를 보고 판단하는 방법만 사용한다. 길이 없을 때도 A* 알고리즘을 적용하여 지도의 모든 셀의 검토가 끝나야 길이 없다는 것을 알게 된다. 가장 시간이 많이 소모될 때가 길이 없을 때이다.

알고리즘 중에서 F값의 최소 값을 빨리 찾는 방법이 있다. 최소 값을 찾으면 그것을 뽑아 내기 때문에 배열의 중간에 틈이 생겨 불연속이 될 수가 있다. 중간에 틈이 생기면 배열을 처리하기 까다롭기 때문에 틈이 생기면 뒤의 것을 당겨 와서 연속으로 만들어야 한다. 매번 최소 값을 찾기 위해 비교를 하고, 뽑아 내면 나머지를 당겨 붙여야 하기 때문에 시간이 많이 소모된다. 이런 작업을 최소한으로 하기 위해서 이 C Code에선 2진 트리 형태를 이용하고 있다. 배열에 요소를 삽입할 때마다 약간의 비교 작업과 자리 바꾸기를 해서 항상 최소 값이 앞에 오게 하면서 배열을 연속적으로 붙여 놓는 방법이다. 허나 단순 비교와 삽입/삭제에 따른 데이터 이동 방식도 이미 어느 정도 순서가 잡힌 배열에선 계산 양이 많지 않기 때문에 2진 트리 같은 복잡한 방법을 사용할 필요는 없다. 하지만 2진 트리 알고리즘이 묘하기 때문에 분석해 본다.

그림에선 크기가 10개인 1차원 배열이 있다. 2진 트리 특성상 뿌리의 첨자는 1부터 시작해야 하기 때문에 0번 방이 빈다. 나의 경우는 0번 방에는 배열 내용의 길이를 넣는 방법을 쓴다. 문자열을 다룰 때도 문자열 끝에 Null을 넣는 것보다는 문자열 앞에 길이를 넣는 것이 더 효율적이다. 여하튼 1차원 배열을 2진 트리 형태로 배치하여 그 내용과 첨자를 나열해 보면 어떤 특징이 보인다. 부모와 자식과 형제 사이의 이동이 간단한 계산으로 이루어진다. 이 2진 트리는 항상 정상(뿌리)에 최소 값이 배치되도록 되어 있다. 고로 1번 첨자의 내용을 뽑아 내면 된다. 새로운 데이터를 추가할 때는 1번이나 마지막 번호(그림에선 9번)에 넣는다. 넣은 다음에는 부모 자식 간의 크기 비교를 통해서 가장 작은 값이 정상으로 올라 가도록 자리 바꾸기를 한다. 최악의 경우 자리 바꿈 횟수는 나무의 깊이(층)만큼이다. 자리 바꿈에는 3회의 대입이 필요하다. 3회의 대입은 3개 데이터 이동과 같다. 부모와 자식 간의 비교는 2회이다. 비교는 뺄셈과 같다. 고로 층의 깊이 x 2회의 비교 연산은 기본으로 소모된다. 층의 수는 n이라고 할 때, 2의 n승 – 1 = 데이터의 수량이 된다. 고로 많은 데이터를 처리할 때 시간이 절약 된다.

head에다가 집어 넣어줍시다.

출처 : http://cafe.naver.com/unityhub

프로그래밍을 처음부터 어떻게 공부해야 하는지 난감하기만하신 분들에게

조금이나마 도움이 될까해서 저의 경험들을 떠올리면서 몇 자 적어봅니다.

국민학교를 다닐 때 베이직을 수박겉핥기 수준으로 배우고, 컴퓨터는 오로지

오락기쯤으로 여겼던 제가 컴퓨터 학원을 다녔던 이유도 게임을 하기 위해서 였습니다.

그렇게 컴퓨터를 뜯었다 고쳤다 컴퓨터를 가지고 노는 데에만 미쳐있던 제가

17살 때 부터 본격적으로 C언어를 공부하기 시작한 이유는 조금은 황당합니다.

그날도 마찬가지로 컴퓨터를 가지고 놀다 어디선가 복사해 온 테트리스를 실행시켰는데

"만든이> 포항공대 김개똥!!" 이라고 적혀있는 겁니다.

저는 그런 대단한 프로그램은 특별한 기업에서만 만들어 내는 줄 알았지 사람?이

만들었다는건 생각도 못했습니다.

게임을 만드는 회사도 결국 사람이 일하는것이 분명했을 터인데 철없고, 무식했던 저에게

대학생이 게임을 만들었다는것이 엄청난 충격이 아닐 수 없었습니다.

그 때 친누나가 대학을 다니고 있었기 때문에 그런 누나(컴맹)와 친구?같은 사람이 이렇게 깔끔하고

멋진 테트리스를 만들었다는 말이야?하고 머리를 큰 헤머로 맞은듯 나도 맨날 납땜질만 할게 아니라

소프트웨어를 만들어야 겠구나 하고 마음을 먹었습니다.

그러고는 자취방 주변에 있던 컴퓨터 학원을 다짜고짜 찾아갔습니다.

학원을 두리번 거리던 저에게 수업을 하시던 선생님들이 나오셔서 무슨 용무냐고 물으시길래

제 상황을 설명드리고, "어떤 언어가 가장 좋은지? 개발툴이 있으면 복사해주시고, 책도 빌려주세요!"라고

다소 황당하게 말했습니다.

그 학원 선생님들은 참으로 고맙게도 "그럼 학원을 다니세요"라 하지는 않고, C언어가 지금은 가장 좋은것

같다. 그리고 Turbo-C 컴파일러와 "C언어 500예제"라는 책을 누군지도 모르는 저에게 빌려주셨습니다.

[Turbo-C 컴파일러]

집에 가서 위에 보이는 터보씨를 실행해보니 오류만 뜨고, 아무런 동작을 하지 않길래 또 찾아갔더니 

이번에는 그 여 선생님의 남편이 오셔서 문제를 해결해 주셨습니다.

(그 여 선생님은 신혼이셨는지 다른 회사에 근무하던 남편이 땀을 뻘뻘 흘리면서 학원에 도착했을 때

그 남편을 바라보던 눈빛이 아직도 기억납니다. 뭐라고 말하진 않아도 사랑이 철철 넘쳐 흐른다고 해야하나요. ^^

지금은 40~50정도 되셨을 그분들이 혹시나 이글을 보신다면 정말 다시 만나뵙고 싶습니다. ㅠㅠ

부산 동래구 온천장 부근의 금정 컴퓨터 학원이었던가? 네티즌 수사대님들 제발 찾아주셔요.)

어쨌거나 문제는 해결되었고, 집으로 돌아가 "Hello world" 예제를 실행했더니

내 눈 앞에 "Hello world.exe"라는 파일이 만들어 지고야 말았습니다.

그 날 저는 잠을 잘 수 없을 정도로 큰 기쁨을 느꼈고, 빌려주신 프로그래밍 500예제는 제가 만져 본 책 중에서는

가장 두꺼웠는데도 일주일만에 모두 다 읽었습니다.

처음에는 이해고 뭐고 없었습니다. 그냥 책을 읽고, 예제를 그대로 따라 타이핑 해보고, 실행되는 모습에 감탄하고...

지금 생각해보면 정말 별것 아닌 그런것이 저에게는 판타지 소설책을 읽는 기분이었습니다.

이 처럼 프로그래밍에 재미만 붙일 수 있다면 프로그래머가 되는것은 시간문제일 뿐입니다.

지금 부터는 제가 프로그래밍을 처음 하면서 고민했던것에 대한 효과적인 학습방법들을 설명하도록 하겠습니다.

첫째. 처음 이해가 안될때는 무조건 보고해라 (Copy and paste)

-------------------------------------------------------------------------------------------------

코딩을 하면서 책을 보거나 인터넷을 뒤져보는것을 초보라 생각하는 사람들이 있습니다.

절대 그렇지 않습니다. 제가 배울때는 딱히 적어둘곳이 없어서 수첩에다 일일이 적었습니다.

그 수첩을 재산처럼 가지고 다니면서 단순하게는 for문 사용법 부터 해서 그래픽 모드로 전환하는

방법까지 모두 적어 두었다가 필요할때가 되면 그 부분을 찾아서 그대로 응용했습니다.

요즘은 인터넷 세상이니 네이버의 개인 블로그에 참조할만한 예제나 문법들을 계속 적어두고 참조하세요.

(클래스나 함수 이름을 모두 기억해야 한다 생각하지 마세요. 프로그래밍은 수능이 아니니 절대로 컨닝을 하세요.)

둘째. 남들이 만든 프로그램이나 소스코드를 분석해라 (Bench Marking)

-------------------------------------------------------------------------------------------------

이론적인 공부만 하고도 프로그램을 뚝딱 만들 수 있다면, 엄청난 직관력을 가진 분이 아닌가 싶습니다.

대부분은 그러지 못하니 작은 프로그램들을 조금씩 분석하세요. 분석이 싫다면 남이 만든 프로그램들을

감상부터 하세요. (책을 사면 예제 위주로 만들어진 책의 소스코드나 인터넷 상에서 돌아다니는게 많습니다.)

그러면서 이런 프로그램이 있구나! 저런 프로그램이 있구나! 이렇게 구현했구나! 저렇게 구현했구나!

아니면 ~ 분석할려니 너무 머리가 아프게 복잡하게 만들어 졌구나! 정말 이해하기 편하게 만들어 졌구나!

하면서 많은것들을 느끼고, 남의것을 분석하는것이 쉽지는 않구나 라는것도 느낄겁니다.

이렇게 남의것을 보기도하고, 조금씩 자신의것을 구현하다 보면 어느 새 프로그래밍이라는게 편하게 다가 올 시기가 옵니다.

(처음 낯선곳에 갔을 때는 어색하다가 한달 두달 지나면 고향보다 더 익숙한 곳으로 변하는것 처럼 만드세요)

셋째. 프로그래밍 용어와 기능을 이해해라 (Technical Understanding)

-------------------------------------------------------------------------------------------------

대부분의 프로그래밍은 어떤 언어를 막론하고, 필요로하는 기술들은 다들 비슷비슷 합니다.

다만, 프로그래밍의 역사가 길어진 요즘에는 그 용어와 기술들이 엄청나게 많습니다.

그렇다고 하더라도 그런 프로그래밍 세계에서의 용어들을 마이동풍과 같이 흘려보내기만 한다면

고급 프로그래머가 되는데에는 시간이 더 많이 걸릴겁니다.

예를들어서 서버, 클라이언트, 네트워킹, 데이터베이스, 멀티스레드와 같은 큰 개념에서 부터

게임 그래픽 관련 용어나 리스트, 해쉬테이블, 트리와 같이 상세한 개념까지 처음듣는용어가 있다면

적어도 수박 겉핥기 정도는 해두셔야 합니다.

물리학자들이 어떤 이론을 설명할 때 수학식으로 설명하듯 수학에 대한 깊은 이해가 없다면

아무런 의사전달이 되지 않겠지요. 프로그래머들도 대부분의 이야기들이 기술적인 용어들이 많기 때문에

관련 용어들을 이해하지 못한다면 난감합니다.

(프로그래밍이라는 것이 단순한 개념 하나만으로 만들 수 있는것이 아니기 때문에 이 과정이 가장 오래 걸립니다)

넷째. 남들이 하는 이야기에 귀를 기울여라 (Communication)

-------------------------------------------------------------------------------------------------

위의 세번째에 익숙해 졌다면 이제부터는 프로그래머들의 이야기가 귀에 들리기 시작할겁니다.

책 중에는 당장 코딩에 도움이 되는 예제나 메뉴얼 형식의 책도 있지만, 특정분야나 개발툴에 대한 전반적인

이야기를 들려주는 책들이 있지요.

그런것 처럼 커뮤니티 사이트에서 많은 사람들이 하는 이야기와 문제점에 대해서

당장 필요하지는 않더라도 관심을 가질 필요가 있습니다.

제 아무리 뛰어난 프로그래머라도 혼자서 모든 상황을 겪어보기는 힘들것이고,

그런 문제에 봉착했을 때 ~ 아 옛날에 그런 이야기를 들었었는데, 문제가 거기에 있는걸까? 하고

문제해결의 실마리를 찾을수도 있습니다.

프로그래밍은 혼자 산속에 들어가 10년을 수양을 한다해서 고수가 될 수 있는것이 아니고,

많은 사람들과 소통하고 함께 이루어 가야한다는것을 알아야 합니다.

-------------------------------------------------------------------------------------------------

너무 조바심 내지말고, 포기하지 마세요.

가장 쉬운 방벙은

visual studio 에서 작업한 내용을  ms word에 붙이고 그걸 다시 복사해서 블로그에 붙이면 소스 코드 색을 그대로 입힐수 있음

다른 방법은 사이트를 통한 방법

http://markup.su/highlighter/

여기에서 코드를 입력하고 highlight버튼을 클릭하면 변형이 됨.