사무 자동화와 공장 자동화, 홈 오토메이션 등의 용어가 일반화될 정도로 컴퓨터의 사용이 응용 확대되면서 점차 사람이 하는 일을 기계가 대신하는 세상이 되었습니다.
사무실에서나 공장에서 컴퓨터는 어떤 경우에 사람보다 더 우수한 정확성과 능률로 일을 처리하기도 합니다.
시스템 분석자가 시스템을 분석하고 시스템 설계자가 설계해서 만들어준 설계도에 따라 프로그램을 작성해서 테스트한 후 곧바로 기계에 넣을 수 있도록 완전한 프로그램을 작성하는 역할을 하는 것이 프로그래머입니다.
일반적으로 컴퓨터 프로그래머는 팀을 구성해서 팀내에서 일을 처리하므로 딱딱한 일반사무실과는 근무 분위기가 다르고 일 자체가 일상적, 반복적인 것이 아니라 항상 새로운 것을 추구하므로 만족감과 성취감이 높다고 합니다.
컴퓨터는 아직도 개발 단계에 있어서 계속해서 이전 것보다 성능이 좋은 신형이 나오고 있고, 프로그램 자체도 항상 새로운 것을 요구하여 수시로 연수 교육을 받거나 외국의 최신 서적을 읽어야 업무 수행이 원활하다고 합니다.
프로그래머의 일터로는 컴퓨터 메이커와 유저(User), 소프트웨어 회사 등 셋으로 분류됩니다. 그러나 소프트웨어 회사 프로그래머의 경우는 작업 관계상 메이커의 소프트웨어 개발에 종사하거나 유저의 프로그램 작성에 참여하므로 기본적으로는 메이커 프로그래머와 유저 프로그래머로 나누어진다고 해도 좋겠습니다.
메이커 프로그래머는 프로그래밍 관계 전반적인 지식을 갖춰야 합니다. 메이커 프로그래머는 다시 두 종류로 구분합니다.
유저 프로그램의 작성에 종사 하는 서비스 프로그래머와 오퍼레이팅 시스템 등의 개발에 종사하는 시스템 프로그래머로 분류됩니다.
서비스 프로그래머는 유저 프로그래머에 비해 더욱 폭넓은 지식과 경험이 필요하며 전반적으로 높은 수준의 프로그래머입니다. 한편 유저 프로그래머는 시니어 프로그래머,프로그래머, 코오더 세 단계로 나뉘어집니다.
시니어 프로그래머는 프로그래머 중에서도 경험과 지식이 가장 많아 프로그래밍 작업의 리더로 근무하며 시스템 엔지니어나 다른 그룹들과의 의견조정을 담당하는 위치에 섭니다.
프로그래머는 일반적인 의미로 통용되는 프로그래밍 작업의 중견적인 역할자로서 플로우챠트를 작성하고 프로그램의 체크, 테스트, 디버그 작업을 맡습니다.
프로그래머에 의해 작성된 플로우챠트에 따라 적당한 언어로 실제 코오딩을 하는 전문가가 코오더입니다. 이는 특정한 언어를 마스터하면 되고 양성도 단기간에 된다는 점에서 가장 흔한 프로그래밍 요원으로 우리나라에서는 통틀어 프로그래머라 부릅니다.
1. 정보모음에 소홀히 하지 말고 설명서를 읽음에 게을리 하지 말지어다. 오늘 필요 없는 정보는 내일 필요하리라. 가장 가치 있고도 저렴한 지식은 책 속에 있느니라. 서점과 동료의 책꽂이에 무엇이 꽂혀 있는지 때때로 살피어라. 무심코 흘렸던 종이 한 장이 너의 근심을 풀어 주었으리라. 설명서는 충분히, 꼼꼼히 읽을지어다. 모든 의문은 설명서를 안 보는데서 생기니라. 그렇더라도 모두 다 읽을 필요는 없느니라. 많은 정보가 능사는 아니니라. 정보의 가치를 찾는 법부터 배우라. 세상엔 너무나 많은 자료와 정보가 넘쳐난다.
알알이 모두 끌어 모을 생각을 하기 보단 정보를 하나로 꿰는 법부터 먼저 배우는것이 너의 근심에서 쉽게 벋어나게 하는 방법이 되리라. 일을 시작하기전에 필요한 정보를 꼼꼼히 먼저 챙기는 법부터 배워라. 너희는 먼저 개발 의뢰서를 꼼꼼히 읽을지어다. 만약 개발 의뢰서가 없다면 발주자에게 요구할 지어다. 개발 의뢰서 없는 프로그램은 존재하지 않으니라.
2. 너의 PC가 안전하다고 믿지 말지어다. 5분 후에 정전이 되고 내일 너의 하드가 맛이 가리라. 그러니 너의 소중한 소스코드는 정기적으로 여러 군데에 단계별로 백업해 두어라. PC는 평상시엔 안전하다. 그런 실수를 저지르는것은 네자신이거나 아니면 외부적인 요인에 기인한다. 항상 백업을 철저히 해두며 백업에 백업까지도 챙겨두라.그리고 백업을 했다면 리스트를 작성하라. 쓸데없는 백업은 백해 무익하나니 리스트를 항상 유지할 지어다. 너희는 노트를 옆에 끼고 살 지어다. 노트는 너의 생명이며, 너희가 기억하지 못하는 모든것을 상기시켜 줄지어다.
3. 변하는 수를 다룰 때에는 늘 조심할지어다. 정수가 절대로 그 한계를 넘지 않으리라 가정하는 것은 어리석음이라. 127 ,-128 ,255 ,32767 ,-32768 ,65535, 이 숫자들을 너의 골수에 새기어라. 0.0은 0이 아니니 실수는 원래부터 결코 정밀하지 않느니라. 부호 없는 것과 있는 것을 어울리거나 정수끼리 나눌 때에는 늘 조심하여라. 변수는 프로그램의 근원, 프로그램을 작성할때 가장 유의 할것이 바로 변수의 이름 짓기니라. 이름보고도 성격을 알 수 있게 해두라. 그러나 변수는 성질이 드러우니 변수에 성격을 부여할때는 조심스럽게 할지어다. 너희는 코딩하기 이전에 계획을 할 지어다. 이는 프로그래머가 코더가 아닌 것이니라.
4. 무슨 일을 반복시킬 때에는 처음과 끝에 유의할지어다. 너의 컴퓨터는 1보다는 0을 좋아 하니라. 배열의 첨자가 그 범위를 넘지 않을지 손 댈 때마다 따져 보아라. 수식에 1을 더하거나 뺄 때에는 늘 긴장하라. 너의 프로그램은 단지 한 번 덜해서 틀리고 한 번 더해서 다운되느니라. 프로그램을 작성할땐 계산, 판단, 비교를 그 모든걸 컴에게 되도록 맡기지말라. 네손으로 미리 계산하고 그 결과를 사용하는 방법이 최선이니라. 컴퓨터는 의지가 없나니 네가 잘못하든 잘하든 아무런 상관이 없느라. 너희는 머리가 악세사리가 아님을 기억하고 항상 생각하고 항상 노트에 적을 지어다.
5. 항상 모든 경우의 수를 고려하고 섣불리 생략하지 말지어다. 절대로 없어 나지 않을 일은 반드시 일어나고, 가장 드물게 일어날 일이 가장 너를 괴롭히리라. 그러하니 언제나 논리에 구멍이 없는지 꼼꼼히 따져 보고, if를 쓸때에는 else 부터 생각하라. 논리적인 오류는 성급함에서 생기나니 처음엔 항상 원리와 원칙을 지키라. 생각은 네가 하라 그리고 그 결과를 컴에게 시켜라. IF를 쓰기전에 규칙을 세우라. 먼저 IF의 결과에대한 규칙부터 세우고 따져라. 그리고 논리적인 계산을 IF문장안에서 하지 말라. 하나의 IF문장속에 수많은 논리연산은 버그의 원인이니라. 어느 정도의 프로그램에 대한 윤곽이 잡히면 프로토 타입을 만들지어다. 프로토타입은 프로그램에 대한 시뮬레이션이며 발주자의 요구를 빨리 수용 하는 방법이니라.
6. 함수 안에서 매개 변수값은 결코 믿지 말지어다. 지금 그 매개 변수가 결코 가질 수 없다는 값을 내일부터는 가지리라. 그러하니 매개 변수 값이 올바름을 항상 검사할지어다. 그렇더라도 처리 속도가 문제가 되는 경우는 예외이니라. 함수도 하나의 독립적인 프로그램이란것을 잊지말며, 네가 프로그램을 작성할땐 모든 함수가 돼도록이면 독립적으로 돌아가도록 할지어다. 함수의 매계변수는 항상 그옆에 작은 컴맨트와 초기화를 잊지말라. 처음부터 속도문제를 생각하지 말라. 모든 루틴을 최적화 할순 없다. 전체 프로그램중에 단 20%가 전체 실행시간에 80%를 점유한다. 프로토 타입에대한 발주자의 의견을 꼼꼼히 들을 지어다. 이는 발주자에 대한 신뢰도의 척도니라.
7. 오류를 알려 주는 기능은 있는 대로 모두 활용할지어다. 컴파일러의 경고는 모두 켜두어라. 경고는 곧 오류이니라. 오류를 알리는 함수의 결과를 확인하지 않는 우를 범하지 말지어다. 모든 파일 입출력과 모든 메모리 할당은 조만간 실패할 것이라. 컴파일러가 모든 경고기능을 동원해도 알려주지 않는 것은 많다. 중요한 건 오류가 생기기전에 규칙을 지켰는지 생각하라. 파일의 입출력과 메모리의 항당은 항상 쌍으로 생각해서 열었다면 닫아주고 활당받았다면 돌 려주라. 프로그램의 매인턴앤스를 게을리하지 말지어다. 이는 프로그램 만드는 일 보다 중요한 일이니라.
8. 한 번의 수정과 재컴파일만으로 연관된 모든 것이 저절로, 강제로 바뀌도록 할지어다. 어떠한 것을 수정했을 때에 연관된 것이 따라서 변하지 않는다면 그것이 곧 벌레이니라. 컴파일러로 하여금 매개 변수 리스트를 완전하게 검사하도록 하고 언젠가 손대야 하거나 따라서 변해야 하는 수치는 전부 매크로로 치환하며, 형 정의를 적극 활용하여라. 이미 완벽한 루틴을 손대지 말라. 프로그램이 무너지는 가장 첫번째이유는 도미노 현상 때문이나니 한번의 수정과 재컴파일로 쓸데없는것을 손대게 하지 말라. 컴파일러가 매개변수 리스트를 챙기지 말게 하라. 프로그램에 들어가기 전엔 미리 함수명과 매개변수 리스트를 만들어라. 너희는 프로그램의 도큐멘트를 만드는일에 게으르지말지어다. 이는 사용자가 너의 프로그램에 대해서는 바보이기 때문이니라.
9. 사용자가 알아서 잘 써 주리라고 희망하지 말지어다. 너의 프로그램은 항상 바보만이 쓰느니라. 사용 설명서를 쓸 때에는 결코 빠뜨리지 말아라. 빠뜨린 만큼 사용자는 너를 괴롭힐 것이니라. 사용자는 나쁜놈이다. 쓸데없는짓을 잘한다. 무식하다. 인간성도 더럽다. 대부분이 바보며 가끔 똑똑한 사람도 있는데 그 놈은 더 하다.모든것을 설명하지 말며 온갇기능을 가진 하나의 프로그램을 작성하려 들지 말라. 많은 기능이 필요한 프로그램은 나누어서 작게 따로 만들어주라. 너희는 공부하는데 게으르지 말지어다. 자고나면 새로운 하드웨어와 새로운 소프트 웨어가 나오기 때문이니라.
10. 매사에 겸손하고 항상 남을 생각할지어다. 가장 완벽한 프로그램일수록 가장 완벽하게 숨은 벌레가 있느니라. 네가 이 세상 최고의 프로그래머라고 떠들며 자만할 때, 옆집 곳간에서는 훨씬 더 뛰어난 것을 묵묵히 만들고 있느니라. 아무렴 프로그래밍은 혼자 잘나서 할 게 아니니, 너로 인해 다른 사람들도 더불어 잘 되면 그 얼마나 좋은 것이냐. 프로그래머는 논리적으로 생각하여야 하지만 프로그램은 비논리적으로 작성하라. 프로그래머가 경지에 들면 누가 누가 잘하는지 알수가 없는 법, 또한 프로그래머로서의 '무지'에 대해서 잊지마라. 프로그래머의 '무지'는 생략하고, 선택하고, 단순화시키고, 명백하게하는 것이니라. 항상 새로운 아이디어와 새로운 생각으로 무장하라. 그리고 나누라 나누는곳에 기쁨있나니 너희는 모든 프로그램에 대해서 위의 프로시줘를 따를 지니라.
//-------------------
대학 졸업이후 오랜만에 보는구나.
살아가면서 자꾸 기본을 잊어바리며 산다.
기초가 중요한 것이거늘.
밥먹을때 젓가락질이 가장 중요하듯이.
초심과 기본을 잃어버리지 말고 항상 되뇌이자~!
어제의 내가 오늘의 나이고 오늘의 내가 내일의 나일때,
근본은 같은 사람이길 바라듯이~!
언젠가 신문기사 중에서 10대들이 가장 선호하는 직업 중에 프로그래머도 끼어 있었던 기억이 난다. 그리고 국내에서도 프로그래밍에 관련된 잡지가 적지 않은 것을 보면 이제 프로그래밍이라는 것은 결코 낯선 말이 아니다. 이제 프로그래밍을 시작하는 사람이나 이미 직업으로써 일을 하고 있는 사람들과 이 프로그래밍이라는 것에 대해 생각해 보면 좋을 것 같다. 일단은 현재의 PC가 탄생하기까지의 과정을 잠시 살펴 보자.
사실 필자가 처음 컴퓨터라는 것을 접했을 80년도 중반 당시에는 프로그래밍이라는 것은 이상한 사람들이나 하는 것으로 여겨지던 시절이었다. 물론 당시에는 지금은 너무나도 친숙한 컴퓨터인 IBM PC라는 것이 컴퓨터 선진국이라는 미국에서조차 대중화 되지 않았던 시절이니 당연하다. 물론 이미 1981년에 IBM-PC는 세상에 첫 선을 보였고 그전에 나온 Apple II가 상업적으로 성공을 거두고 있던 시절이지만 대부분 상업적인 목적으로 사용되고 있었고 그때까지 일반인들에게는 컴퓨터에 관한 얘기는 먼 나라 얘기 였다.
일반인들이 알 수 있는 수준으로 보자면 만화뿐만 아니라 백과사전 같은데도 컴퓨터는 커다란 눈(사실은 자기테이프지만 모르는 사람에게는 눈처럼 보였고 필자도 그런 느낌을 받았었다.)이 달린 집채만한 아주 고가의 장비라서 그것을 만지는 사람은 대단한 사람으로 그려지던 당시에는 프로그래밍을 한다는 것은 생각하지도 못할 뿐만 아니라 프로그래머는 전세계를 통틀어도 많지 않았으므로 프로그래밍을 한다는 것은 특정 연구소의 연구원이나 대학의 교수진 등 극 소수의 사람만이 생각해 볼 수 있었다. 그때 쯤 국내에서는 겨우 대형 시스템에 터미널을 통해서 접속할 수 있는 기회를 학생들에게 제공하기 시작 했다. 비로소 국내에서 일반인들도 컴퓨터를 접해 볼 기회를 갖게 된 것이다. 물론 이전에도 천공카드를 통하여 작업은 이루어 지고 있었으나 터미널을 통하여 다수의 사람이 동시에 사용하게 된 것은 나름대로 중요한 의미를 갖는다. 하지만 이러한 대형 시스템은 프로그래밍이 대중화된 개념으로 다가오는데 큰 도움을 주지는 못했다.
반면에 지금도 많은 사람들이 기억하고 있을 Apple II는 전세계적으로 성공을 거둔 제품일 뿐만 아니라 컴퓨터의 대중화에 기여한 바가 크다. 스티브 워즈니악과 스티브 잡스가 창고 구석에서 만들어낸 애플이 태어나기 전에 이미 만들어진 알테어(Altair)라고 불리는 최초의 상업적인 컴퓨터는 의미가 크다. 그때가 1975년이었다. 폴 앨런과 빌 게이츠가 이 시절에 알테어를 위한 BASIC을 만들었다는 것은 우연일까? 그리고 그때 마이크로소프트를 설립했다. 그리고 워즈니악과 잡스도 그때쯤 Apple의 초기 모델을 만들고 그것을 1977년에 Apple II로 시장에 내 놓은 것이다. 그리고 그 이후 비지칼크(VisiCalc)라는 최초의 스프레드쉬트 (Spreadsheet)가 발표되면서 PC의 업무를 위한 제품으로서의 상업적 가치에 대하여 인정받기 시작하였으며 이런 가능성에 힘입어 1981년에는 IBM-PC가 첫 선을 보이고 마이크로소프트의 MS-DOS, 로터스의 Lotus 1-2-3 등이 시장에 나왔으며 그 이후로는 비약적인 발전을 거듭하여 지금의 PC까지 오게 된 것이다. 물론 다른 컴퓨터들도 있었으나 대중적인 인기를 얻은 Apple II와 IBM-PC는 그에 상응하는 많은 프로그래머들을 탄생하게 하는 기회를 제공해 주었으므로 그 가치가 더 높다고 보는 것이다. 많은 프로그래머가 없었다면 애플의 그 많은 게임과 IBM-PC의 그 많은 사무용및 개인용 어플리케이션과 게임들이 세상에 나올 수 없었을 것이다.
자 이제 다시 프로그래밍이라는 원래의 이야기로 돌아가 보자. 필자는 프로그래밍을 하는 사람을 크게 두 가지로 본다. 하나는 본인의 취미로 즉, 프로그래밍이라는 것 자체가 재미가 있어서 그렇고 다른 하나는 생계의 수단으로 자신의 프로그래밍 능력을 보수를 받고 제공하는 직업의 경우다. 물론 직업이자 취미일 수도 있다. 그리고 프로그래밍을 통하여 자신의 메시지를 전달하고자 하는 더 큰 목적이 있을 수도 있다. 하지만 취미와 직업으로 분류한 것은 책임을 지느냐 마느냐라는 것을 기준으로 하는 분류이므로 이런 기준을 가진다고 생각하며 얘기를 해 보겠다.
일단 취미로 프로그래밍을 하는 경우 대부분의 사람들은 재미있다고 한다. 그 이유는 단순하다. 어떤 취미든지 본인이 선택한 경우 재미 없을 리가 있겠는가. 프로그래밍이라도 예외는 아니다. 본인이 취미로 선택한 것이라면 아무리 어려운 일이라도 재미 있을 것은 당연하다. 등산을 취미로 하는 사람이 높은 산에 오르는 것이 힘들어서 그만두는 경우가 얼마나 있을까? 취미 생활에 심취한 사람일 수록 오히려 더 높은 산 힘든 코스를 고르는 경우가 많다. 따라서 프로그램이 취미인 사람도 신기술, 새로운 테크닉이 알려지면 하나라도 더 알려고 노력하는 경우가 많은 것이다. 하지만 취미로 프로그래밍을 하는 경우에 한계가 있을 수 있다. 모두 그런 것은 아니지만 너무 어려운 것은 피하려는 성향과 누구에게나 편하게 만들기 위한 노력을 덜 한다. 전문 산악인이 되기 위해서는 단지 취미로 등산을 좋아 하는 것으로는 부족한 것과 같은 경우라고 볼 수 있다. 본인이 취미로 만든 프로그램의 경우 대다수가 일반인이 사용하기에는 불편한 부분이 존재한다. 흔히 이야기 하는 UI부분에 신경을 많이 못쓰는 것도 그렇고, 예상하지 않는 동작에 대한 예외 처리가 미흡하며 특정한 환경에서만 동작하는 등 일반적이지 못하다는 평가를 많이 받게 된다. 하지만 이렇게 취미로 프로그래밍을 하는 경험 많은 아마추어 프로그래머들이 직업적인 프로그래머보다 기술적으로 뒤 떨어 진 것이라고 보기는 힘들다. 정확하게 표현하자면 직업 프로그래머로서의 훈련이 부족하다 라고 하는 것이 옳다.
그렇다면 직업 프로그래머는 취미로 프로그래밍을 하는 아마추어 프로그래머와 어떤 점이 다를까? 이외로 단순하다. 프로그래밍을 한다는 것은 같지만 그 프로그램이 상품적 가치가 있어야 하므로 기본 기능 이외에 훨씬 많은 곳에 신경을 쓴다는 것이다. 그리고 본인이 생각보다 타인의 생각이 제품에 많이 반영된다는 것도 다른 점일 것이다. 특히 최근의 제품들을 보면 편리한 UI라는 것을 강점으로 내세우는 것들이 많다. 하지만 이러한 UI에 관련된 코딩은 보기보다 시간이 많이 걸린다는 것을 안다면 직업적인 프로그래머의 고충을 짐작 할 수 있을 것이다. 프로그래밍을 조금 배우고 나서 누구나 한번쯤은 만들어 보게 되는 전화번호부 같은 프로그램을 예로 보자. 취미로 만든 경우에는 기본 기능과 본인이 특별히 원하는 기능에 치중하게 된다. 즉, 원하는 사람을 쉽게 찾을 수 있는 것이 가장 기본적인 기능이므로 이 기능을 구현하고 나면 이제 다 되었군 하는 생각을 하기가 쉽다. 하지만 그게 상업적 가치를 가지는 제품을 만드는 경우라면 얘기는 다르다. 나는 일년에 한번쯤 쓸까 말까 한 기능이지만 어딘가에 있을지 모르는 사용자의 요구를 위하여 여러 기능이 추가된다. 편지 봉투 찍기 같은 기능은 개인이 친구 몇 명의 전화번호를 관리하는데는 크게 필요하지 않은 기능이겠지만 전문적으로 광고문을 발송하는 업체 들에게는 꼭 필요한 기능이므로 추가 해야 할 것이며 전화번호로 찾기 등은 호출기를 많이 사용하는 사람에게는 필요할 것이며, 전자 우편 주소를 입력하는 난은 전자우편을 사용하지 않는 사람에게는 전혀 필요하지 않지만 그렇지 않은 사람에게는 꼭 필요한 데이타 일 것이다. 또한 마우스보다 키보드를 사용하는 게 더 편한 사람들을 위하여 단축키를 적절히 배치하고 보다 편리하게 사용하기 위하여 단축키 설정을 바꿀 수 있게 하기 위하여서는 그 만큼 더 시간과 노력이 필요하다.
이처럼 두 가지의 경우를 구분해서 얘기 해 놓았지만 실제는 조금 다르다. 많은 소프트웨어 회사는 뜻이 맞는 몇 사람이 모여 시작하게 된다. 그리고 그 뜻 이라는 것은 이미 서로 공감하는 어떤 제품이나 기술인 경우가 많다. 따라서 이런 경우 취미와 직업이 같은 경우가 되며 국내의 여러 소프트웨어 회사는 이러한 프로그래머가 많다고 보인다. 위의 구분을 가지고 보면 프로그래밍 그 자체에 대한 재미는 가지고 있지만 생존하기 위한 직업이 된 경우다. 사실 필자가 얘기 하고 싶은 것은 이러한 사람들에 대한 얘기다. 어차피 취미이거나 직업인 경우가 분리된다면 특별히 할 얘기도 없기 때문이다. 취미인데 뭐라고 한다는 것은 웃기는 얘기고 직업인데 좋다 나쁘다를 얘기한다는 것도 말이 안되기 때문이다.
컴퓨터를 좋아하고 프로그래밍이 취미인 많은 전문 프로그래머들은 가끔 혼자만의 고민에 빠지는 경우가 많다. "나는 취미와 직업이 같은 항상 재미 있는 일을 하고 있어", "훌륭한 프로그램을 만들어 성공해야지". 등 긍정적이고 미래지향적인 생각은 현실에 부딪혀 깨지기가 쉽기 때문이다. 대부분의 회사는 회사 나름대로의 독특한 색깔을 가지고 있다. 따라서 대부분이 그러한 색깔을 파악하고 취업하지만 실제 맡게 되는 일은 그러한 일과는 거리가 먼 작업이 되는 경우가 많다. 그래서 분명히 컴퓨터를 좋아하고 취미가 프로그래밍인 것도 맞지만 분야가 다른 일, 자신의 취향과 맞지 않는 일을 맡게 되는 경우 스스로의 벽에 부딪히게 된다.
그렇다면 이런 경우를 근본적으로 해결하는 방법은 없을까? 서로 다른 생각을 가진 사람이 워낙 많기 때문에 딱 부러지게 결론을 내릴 수는 없지만 필자의 생각으로는 가능하다고 생각한다. 흔히들 취미와 직업이 같은 경우 당연히 직업이 취미를 따라와 주길 바라게 된다. 하지만 이런 생각은 세상은 나를 중심으로 서 있다는 신세대의 생각으로는 당연한 것 일지 모르나 무엇인가는 만들어 내고 그 제품이 회사를 운영하는 밑거름이 된다는 일반적인 직업 논리와는 어울리지 않는 생각이다. 물론 방법론 중의 하나로서 회사가 그러한 개인의 취향을 십분 이해하여 그러한 방향으로 제품을 만들어 낸다면 문제는 없을 것이다. 하지만 더 중요한 것 중의 하나가 성공할 만한 제품을 기획해 내고 그 프로젝트를 추진하기 위해서 시행착오를 많이 겪어 왔던 선배들의 생각을 존중해 주고 선배는 후배들의 새로운 아이디어를 새로운 프로젝트에 접목하는 포용력을 발휘해 주는 서로간의 이해해 주는 마음가짐이다.
즉, 서로의 입장을 이해하고 조금씩 양보를 할 필요가 있다. 지금 당장 원하는 것을 해 줄 수 없다면 언제는 가능한지를 미리 이해 시켜주는 회사는 무조건 주어진 일을 정해진 시간 내로 해 놓기 만을 바라는 회사보다는 더 좋은 회사일 것이다. 물론 원하는 것을 들어줄 여력이 안되는 경우라면 그럴 수 없다고 미리 말 해 주는 것도 좋을 것이다. 프로그래머들이 재산인 소프트웨어 회사가 능력 있고 미래에 대한 생각이 뚜렷한 프로그래머들에게 비전도 심어주지 않고 적절한 보상도 해 주지 않고서 그 회사의 밝은 미래를 그릴 수는 없을 것이다. 물론 반대의 입장으로 프로그래머는 여러 가지 능력을 배양해야 한다. 그렇지 않고서는 쏟아지는 프로그래머들 중 더 나은 프로그래머를 선택할 수 있는 것이 회사의 고유 권한이기 때문이다.
자 다시 취미 얘기로 돌아와 보자. 사실 이 책을 읽고 있는 독자라면 이미 취미건 직업이건 프로그래밍에 대하여 관심이 있는 사람들일 것이다. 하지만 어떤 일을 하든지 그 일을 재미 있게 처리하기 위해서는 관심과 노력이 필요하다. 다른 말로 그 일에 취미를 가져야 한다. 어차피 관심은 가지고 있다면 강제로 취미를 갖기는 힘들기 때문에 노력이 필요한 것이다. 또 예전에는 취미가 있다고 생각했는데 지금은 직업이 되어서 재미가 없다는 사람도 있을 것이다. 역시 노력이 부족하다고 볼 수 있다. 취미라면 잘하든지 못하든지 재미가 있어야 한다. 다시 말해 재미를 찾는 것이 취미를 갖는데 혹은 다시 취미가 되기 위해 필요하다. 그럼 어떻게 재미를 가질까? 혹은 어떻게 재미를 되찾을 수 있을까?
프로그래밍이 재미가 없다고 하는 독자들은 한번쯤 같이 생각해 보자. 원래 처음부터 재미가 없다면 다른 프로그래머들이 재미 있다고 하는 일을 한번쯤은 해 보는 것이 좋다. 이미 다른 사람에 의해서 만들어진 프로그램을 아무것도 없는 상태에서 똑같이 만들어 보는 것, 아니면 조금 바꾸어서 만들어 보는 것, 혹은 세상에서 하나뿐인 새로운 프로그램을 만들어 보는 것 그 어떤 것이라도 좋다. 중요한 것은 직접 내 시간을 투자하여 만들어 본다는 것이다. 그리고 직업 프로그래머들인 경우에는 업무 시간이 아닌 혼자만의 시간에 해야 한다. 영화나 등산, 독서 등은 왜 내 시간을 투자하면서 취미를 갖고 싶은 프로그래밍에는 시간 투자를 하지 않는가? 그저 시간이 지나면 훌륭한 프로그래머가 될 수 있는 것은 아니다. 그것이 취미거나 아니거나 투자한 시간 만큼 더 숙련된 프로그래머가 되는 것이다. 그리고 예전에는 취미를 가졌었지만 지금은 아니라고 하는 사람들에게 물어 보고 싶은 것이 있다. 최근에 스스로 생각하고 혼자만의 시간을 투자해서 혼자만의 프로그래밍을 해 본 경험이 있는가? 그렇다면 다른 취미 생활 역시 하지 않았는가? 아니라면 스스로 프로그래밍이라는 취미를 놓아 버린 것은 아닐까?
많은 사람들이 취미를 직업으로 삼으면 취미를 잃는다고 한다. 하지만 좀 더 생각해 보면 그 만큼 행복한 경우가 또 없을 것이다. 그것은 사랑하는 연인과 결혼한다고 그 연인이 미워지는 것은 아닌 것과 같은 이유다. 단지 살아가는데 부딪히는 여러 가지 어려움들을 슬기롭게 극복하지 못하는 이유라면 그것을 당연하게 받아 들이지 말고 이겨나가야 되는 것이다. 필자는 특히 프로그래밍은 영원한 취미로 삼을 만 한 것이라고 생각한다. 어렸을 적에는 내가 즐기기 위한 게임을 만들 수 있고, 커서는 업무나 일상생활에 필요한 나만의 도구를 만들고, 나이가 들어서는 가물가물 해가는 기억을 도와주는 도구를 스스로 만들어 사용할 수 있다고 생각하기만 해도 얼마나 뿌듯한가. 물론 사서 쓰면 된다. 하지만 직접 해 먹는 요리가 나름대로 맛이 있듯이 프로그래밍이 취미라면 틈틈이 만들어 쓰는 것이 재미 있을 것이다.
세상에는 많은 취미 생활이 있다. 그리고 프로그래밍도 그 중의 하나다. 프로그래밍을 취미로 갖고 싶어하는 사람들, 취미를 잠시 잃어 버린 사람들 그리고 취미인 사람들 이제부터 자기 소개서에 당당하게 쓰자 내 취미는 프로그래밍이라고...
----------------------------------------------------------------------
Internet Explorer 대신 해당 Office 프로그램에서 Office 문서를 열도록 Internet Explorer를 구성하는 방법
현상
Microsoft Word 또는 Excel 문서와 같은 Microsoft Office 파일에 대한 HTML 링크를 누르면 해당 Office 프로그램에서 파일이 열리지 않고 Internet Explorer에서 파일이 열릴 수 있습니다.
위로 가기
원인
이 문제는 Internet Explorer가 컴퓨터에 설치된 Office 프로그램용 문서를 호스팅하도록 구성된 경우 발생할 수 있습니다. 기본적으로 Internet Explorer는 Office 프로그램용 문서를 호스팅하도록 구성됩니다.
위로 가기
해결 방법
Internet Explorer 대신 해당 Office 프로그램에서 Office 파일을 열도록 Internet Explorer를 구성하려면 다음 방법 중 하나를 사용합니다.
참고 다음 방법을 사용하면 모든 사용자에 대해 해당 Office 프로그램에서 Office 파일을 열도록 Internet Explorer가 구성됩니다.
위로 가기
방법 1: 폴더 옵션 도구 사용
참고 Windows NT 4.0을 실행 중인 경우 다음 절차를 사용하여 해당 Office 프로그램에서 Office 파일을 열도록 Internet Explorer를 구성할 수 없습니다. Windows NT 4.0을 실행하는 경우에는 방법 2를 사용하십시오.
참고 Windows 2000 또는 Windows Server 2003에서 Terminal Server를 실행 중인 경우 이 절차의 4단계에서 고급을 눌러 파일 형식 편집 대화 상자를 열지 못할 수 있습니다. 이 문제는 NoFileAssociate 정책을 사용하는 경우 발생합니다. 이 정책을 사용하면 관리자를 비롯한 사용자가 모든 사용자에 대한 파일 형식 연결을 변경할 수 없게 됩니다. 이 문제에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
257592 (http://support.microsoft.com/kb/257592/) Windows 2000 및 Windows Server 2003의 파일 형식 및 파일 연결 기능 변경
폴더 옵션 도구를 사용하여 해당 Office 프로그램에서 Office 파일을 열도록 Internet Explorer를 구성하려면 1. 내 컴퓨터를 엽니다.
2. 도구 메뉴(또는 보기 메뉴)에서 폴더 옵션(또는 옵션)을 누릅니다.
3. 파일 형식 탭을 누릅니다.
4. 등록된 파일 형식 목록에서 Microsoft Excel 워크시트와 같은 특정 Office 문서 형식을 누른 다음 고급(또는 편집)을 누릅니다.
5. 파일 형식 편집 대화 상자에서 같은 창에서 열기 확인란(또는 같은 위치에서 web 문서 열기 확인란) 선택을 취소합니다.
6. 확인을 누릅니다.
위로 가기
방법 2: Windows 레지스트리 편집
경고: 레지스트리 편집기를 잘못 사용하면 심각한 문제가 발생할 수 있으며 문제를 해결하기 위해 운영 체제를 다시 설치해야 할 수도 있습니다. Microsoft는 레지스트리 편집기를 잘못 사용함으로써 발생하는 문제에 대해 해결을 보증하지 않습니다. 레지스트리 편집기의 사용에 따른 모든 책임은 사용자에게 있습니다.
Windows 레지스트리를 편집하여 해당 Office 프로그램에서 Office 파일을 열도록 Internet Explorer를 구성하려면 해당 문서 형식에 대해 BrowserFlags DWORD 값을 8(Microsoft Excel 워크시트의 경우 9)로 설정합니다. 이렇게 하려면 다음과 같이 하십시오. 1. 레지스트리 편집기(Regedt32.exe)를 시작합니다.
2. 다음 레지스트리 키를 찾아 누릅니다.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes
3. 특정 Office 문서 형식에 해당하는 하위 키를 찾습니다. 다음 표는 여러 일반적인 Office 문서 형식에 해당하는 하위 키 목록입니다.
문서 형식 하위 키
Microsoft Excel 7.0 워크시트 Excel.Sheet.5
Microsoft Excel 97 워크시트 Excel.Sheet.8
Microsoft Excel 2000 워크시트 Excel.Sheet.8
Microsoft Word 7.0 문서 Word.Document.6
Microsoft Word 97 문서 Word.Document.8
Microsoft Word 2000 문서 Word.Document.8
Microsoft Project 98 프로젝트 MSProject.Project.8
Microsoft PowerPoint 2000 문서 PowerPoint.Show.8
이 표에 없는 문서 형식에 해당하는 하위 키를 찾으려면 문서 형식과 관련된 확장명에 해당하는 하위 키를 찾습니다. 하위 키의 기본값에는 해당 문서 형식의 하위 키 이름이 포함되어 있습니다. 예를 들어, .xls 확장명은 Excel 워크시트와 연결되어 있습니다. .xls 하위 키 아래에는 기본값으로 문자열 "Excel.Sheet.5"가 포함되어 있습니다. 따라서 Microsoft Excel 워크시트 문서 형식의 하위 키는 다음과 같습니다.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Excel.Sheet.5
4. 특정 Office 문서 형식의 하위 키를 확인한 후에 Excel.Sheet.5를 제외한 모든 하위 키에 대해 다음 값을 추가합니다.
값 이름: BrowserFlags
데이터 형식: REG_DWORD
값: 8
Excel.Sheet.5의 경우 아래와 같은 값을 추가합니다.
값 이름: BrowserFlags
데이터 형식: REG_DWORD
값: 9
5. 확인을 누른 다음 레지스트리 편집기를 종료합니다.
서울에서 부산 지사에 있는 스토리지에 저장된 데이터를 짧은 시간 안에 액세스할 수 있다면 굳이 많은 비용을 들여 각각의 지사에 스토리지를 구축할 필요성은 없을 것이다.
하지만 대부분의 기업들은 원거리에 있는 사무실과 거리가 멀어질수록 액세스 시간이 길어지기 때문에 각각의 지사에 스토리지를 배치해 액세스 시간을 최소화하는 것을 궁극적인 목표로 하고 있다.
그러나 이같은 방법은 비용 대비 저조한 스토리지 이용률, 데이터 보안에 대한 위험성 문제뿐만 아니라 글로벌 액세스 제한 등의 약점을 갖고 있다.
이러한 측면에서 기업들은 원거리 액세스에 있어서의 시간 단축을 비롯해 이에 따른 문제점을 보다 효과적으로 해결할 수 있는 ‘왑스(WAFS, Wide Area File Service)’를 주목할 필요성이 있다.
◆‘왑스(WAFS)' 의 개념과 기술적 환경
‘왑스’는 원거리통신(WAN)에서 데이터에 대한 느린 속도의 액세스를 개선해 마치 랜(LAN) 환경에서 데이터를 사용하는 것과 같은 기능을 제공하는 솔루션이다.
즉 지사에서 기업의 스토리지에 저장돼 있는 데이터를 보다 신속하게 액세스할 수 있도록 하는 ‘왑스’는 사무실 간 거리 확대, 데이터 보호 등 기업에게 기술적인 혁신을 가져다 줄 것으로 기대된다.
나아가 ‘왑스’는 현재 폭발적으로 증가하는 데이터의 처리문제와 원격지에서의 데이터 관리 기능에 대한 기업의 불안 문제 등을 효과적으로 해결할 것으로 생각된다. 보통 여기서 말하는 액세스의 최소 시간은 3초 미만으로 보고 있다.
그렇다면 기업에게 신속한 원격지 액세스를 제공하는 왑스에 대해 보다 자세히 알아보도록 하겠다.
우선, 이러한 ‘왑스’를 구성하는 기술들로는 보통 ‘NFS(Network File System)’, ‘CIFS(Common Internet File System)’, TCP/IP 프로토콜, 애플리케이션 프로토콜 최적화 그리고 관리 툴 등이 있다.
특히 획기적인 속도 향상은 프로토콜 최적화와 디스크 캐시를 통해 이뤄진다고 할 수 있다.
예를 들어, 100MB 이상의 데이터에 액세스를 하기 위해서는 원격지와 데이터 센터 사이에서 상호 교환되는 신호는 수십만개 이상에 달할 것이다.
그렇기 때문에 원거리 통신환경 속에서 액세스 시간이 지연되는 것은 당연한 이치일지도 모르지만 ‘왑스 ’는 보통 이러한 프로토콜을 간소화해 데이터 액세스를 용이하게 한다는 것이다.
물론 ‘왑스’ 이전에는 원거리 통신(WAN) 가속기 등 제품이 있었지만 WAN 가속기 시장은 기업들로 하여금 체감할 수 있을 정도의 높은 속도 향상을 경험토록 하지 못했기 때문에 스스로 도태되고 말았다.
두번째로 ‘왑스’ 구현에 대한 문제에 대해서 살펴보도록 하겠다.
‘왑스’를 구현해 기존 SAN과 백엔드 스토리지를 전면 교체할 필요는 없다. 그 이유는 ‘왑스’를 프론트엔드와 기존 NAS 및 CIFS 서버로 구성된 IP네트워크 및 NAS 게이트웨이 등에 추가하기만 하면 되기 때문이다.
원거리 사무실에 있는 데이터를 보다 효율적인 방법으로 관리하고자 할 경우에는 이러한 데이터를 데이터 센터에 호스팅해 보다 간편하게 원거리 사이트 설정 관리를 비롯, 이러한 데이터가 규제 요건에 부합하도록 보안 관리 및 유지를 가능케 한다.
이렇듯 ‘왑스’의 궁극적인 목표는 데이터 센터와 원거리 사무실 간의 지연 시간을 단 몇초의 LAN 환경까지 줄임으로써 데이터를 중앙 데이터 센터에서 호스팅하고 관리할 수 있도록 하는 것이다.
즉 ‘왑스’는 원거리 사무실에 있는 사람이 본사에서 보호 및 관리하는 파일들을 신속하게 액세스 할 수 있게 도와주는 것이다.
다만 이러한 과제를 해결하기 위해 ‘왑스’ 유지를 위한 운용비와 인프라 전반의 총소유비용(TCO)을 낮추는 작업이 선행돼야 할 것이다.
한 조사기관에 따르면 현재 전세계 기업 데이터의 75% 이상이 데이터 센터 외부에 존재하고 있으며 전체 데이터의 60% 이상이 보호를 받지 못하고 있는 실정으로 나타났다.
이렇듯 데이터 보호 및 관리를 위해서라도 ‘왑스’의 중요성을 인식해야 할 것이다.
◆왑스 솔루션 사업자간 움직임
‘왑스’ 시장에서 일어나고 있는 각 벤더들간 움직임들을 살펴보면 맥데이터는 GEDI 전략의 일환으로 서버와 스토리지 연결에서 애플리케이션과 데이터 연결로 그 가치를 확대하고자 하고 있다.
이렇게 함으로써 ‘왑스’는 SAN을 통해 데이터에 대한 블록 액세스와 파일 액세스를 통합할 수 있는 기회를 제공하며 기존 SAN과 결합함으로써 데이터 센터 내에 있는 데이터를 중앙집중적으로 저장 및 관리할 수 있다.
결국 MAN과 WAN을 통해 이러한 데이터를 원격으로 신속하게 액세스할 수 있도록 한다.
따라서 사용자는 데이터 관리 비용 절감, 데이터 손실 위험 절감, 원거리 사이트의 장비수 감소, CIFS 서버 및 백업용 테이프 드라이브, 스토리지 이용도 증대 등을 통해 TCO 절감의 효과를 누릴 수 있다.
브로케이드는 MS 오피스 환경에 최적화된 솔루션 테이프스트리 ‘왑스’ 솔루션을 공급중이다.
MS 오피스 관련 문서와 기타 CIFS 및 NFS 표준에 기반을 둔 응용 프로그램의 WAN 대기 시간에 대한 문제점를 완화한 것이다.
테이프스트리 왑스는 MS의 ‘브랜치 오피스 프로그램’을 활용하게 되는데 브랜치 오피스 프로그램은 MS가 지사 관리용 오피스 프로그램을 별도로 구성해 놓은 것이다.
시스코시스템즈 역시 EMC와 공동으로 시스코 ‘왑스’ 솔루션과 EMC의 NAS 솔루션을 연계해 지역별로 분산된 데이터 서버나 데이터 센터를 통합하는 시장 공략에 본격 나선다고 밝힌 바 있다.
결론적으로 데이터 센터와 지사간 지연 시간을 줄임으로써 데이터를 중앙 데이터 센터에서 호스팅하고 관리할 수 있도록 하는 ‘왑스’의 필요성과 보호받지 못하고 있는 데이터의 보호와 관리를 위해서 ‘왑스’의 중요성을 기업들은 간과해서는 안 될 것이다.
뿐만 아니라 ‘왑스’ 구현을 통해 갈수록 증가하는 소프트웨어 비용 절감 등 운영 및 관리에서의 비용을 50%까지 절감이 된다는 사실은 ‘왑스’의 비용 대비 효율성을 입증하는 좋은 예라고 할 수 있을 것이다
PL(Project Leader)은 그동안 많이 쓰여져 왔던 프로젝트 매니저에게 좀더 경영자적인 자질을 요구하면서 등장시킨 지위라고 보시면 되겠습니다.
그럼 프로젝트 리더의 역할과 자질에 대해서 알아보도록 하겠습니다.
PL(Project Leader)의 5가지 역할
1. 전략적 기획가(Strategic Planner)
-프로젝트 목표와 비전 설정
-목표달성을 위한 전략계획 수립
-연구업무와 연구원의 연계(Matching) 및 프로젝트 추진일정(Scheduling)
2. 동기부여자(Exciter)
-팀 응집력, 팀정신(Team Spirit)의 구축
-팀 구성원들에 대한 Empowering(신바람)
3. 기술적 전문가(Technical Expert)
-신선한 아이디어나 새로운 접근방법에 대한 제안
-기술적 문제점 파악과 대안있는 비판
-다양한 아이디어, 접근방법, 시각들을 통합
-개개인의 아이디어나 연구결과에 대한 피드백
4. 기술정보통(Gatekeeper)
-활발한 외부 기술정보원접촉과 Networking
-시장 및 수요자 욕구에 대한 민감한 탐색(Monitoring)
-의사소통의 구심점 역할(Communication Star)
-경우에 따라서는 대변인이나 통역 역할
5. 열성적 추진자(Champion)
-프로젝트 목표와 리더개인 목표의 합일
-프로젝트의 열성적 추구자
-프로젝트 실행을 위한 승인과 자원획득
-관련부서와의 제휴 및 연대구축
-대외적인 홍보와 Salesman 역할 (Ambassador)
프로젝트리더의 자격요건
-주인의식(Ownership)이 있어야 함.
-하고 있는 일에 전적으로 몰입하고 사명감이 있어야 함.
-성공을 위한 강한 에너지와 열정(Need for Achievement)이 있어야 함.
-부문별 목표보다는 조직전체를 생각하는 팀정신 소유자(Team Player)
-자유로운 의사소통(Communicator)을 할 수 있어야 함.
-거시적 안목에서 일을 처리할 수 있는 자신감(Confidence)이 있어야 함.
-팀원들을 격려하고 도와주며 활력을 줄 수 있어야(Empowerment) 함.
-팀원을 관리하기 보다는 계발, 육성(Develop)할 수 있어야 함.
