[박경훈]한국은 왜 하드워킹일까? 박경훈 훈스닷넷 대표 hoonsbara@hotmail.com 2009.08.14 / PM 03:24 개발자, 박경훈
[콘퍼런스] 클라우드컴퓨팅의 가치조명 : 구축 및 서비스 사례 - 10.13(화) [지디넷코리아] 한국에서 개발자로 일을 해본 사람이라면 누구나 한국의 IT 문화를 비하하거나 그 일상에 지쳐 쓰는 많은 넋두리의 글들을 본 적이 있을 것이다.
“내 가 사직서를 낸 이유”서부터 시작해서 “영재들아 IT로 오지 마라”와 같은 글들이나 월화수목금금금과 같은 단어들은 이미 한국 IT의 현실을 잘 보여주고 있는 것들이다. 구구절절 설명하지 않아도 개발자로서 비전이 크지 않다는 것을 누구나 잘 알고 있을 것이다.
그렇다고 필자 또한 이 글을 통해서 한국의 IT 문화를 비하하고 넋두리나 늘어놓으려고 이런 글을 쓰는 것은 아니다. 그것보다는 왜 우리나라가 이렇게 된 것인지 왜 이렇게 하드워킹을 하고 있는 이유에 대해서 영국의 IT문화와 비교하여 분석해 보고자 하는 것이다. 그리고 과연 무엇이 잘못된 것이고 어떻게 하면 이 환경을 바꿀 수 있을지에 대한 주관적인 생각들을 한번 정리해 보고자 한다.
■한국 IT 직장 문화의 현실
한 국 작은 벤처에서 프로그래머로 일하고 있는 개발자가 있다. 이 개발자는 정시에 퇴근한 날을 손으로 꼽을 수 있을 만큼 잦은 야근 속에 하고 있다. 그렇다고 이 개발자는 그만한 대가를 더 받는 것도 아니다. 그저 대기업 초봉도 못 미치는 아주 작은 월급으로 그렇게 하드워킹을 하고 있는 것이다.
이렇게 일하고 있는 개발자를 보고 있으면 당장 회사를 그만두고 새로운 회사를 알아보라는 말이 목구멍까지만 올라오지만 결국 할 수 없다. 왜냐하면 그 개발자가 회사를 옮긴다고 더 삶이 나아 진다라는 보장이 크지 않기 때문이다.
분 명 70%이상의 개발자들은 이렇게 하드워킹을 하고 있을 것이다. 이 중에는 혹시나 자기 회사가 소위 말하는 대박이라는 것이 터지길 바라고 자기한테 그 몫이 떨어지길 위해서 참고 기다리는 것일 수도 있겠다. 하지만 그 대박이라는 수치는 10년 전 싸이월드가 10명 정도의 작은 벤처로 시작해서 SK에 인수될 만큼의 대박이 아닌 이상 큰 의미가 없다.
예 를 들어 어떤 개발자는 회사가 클 수 있는 믿음으로 자기의 청춘을 바쳐가며 열심히 일했다. 그리고 회사는 그 믿음에 부흥해서 회사가 10배 정도로 커졌다고 가정해 보자. 즉, 10명의 작은 벤처회사가 100명이 된 것이다. 그렇다고 해서 개발자가 소위 말하는 억대 연봉을 챙겨 갈 수 있다고 생각이 되는가? 아니면 하드워킹이라도 피할 수 있을까?
현실을 직시해 보면 슬픈 말이지만 기획하고 추진한 주체가 아닌 이상 대우는 크게 달라지지 않는다. 즉, 회사는 변해도 개발자에 대한 대우는 변하지 않는 다는 것이다. 오히려 사업 확장으로 인해 더 바빠지지나 않으면 다행일 수 있다.
■유럽에서 프로그래머의 위상
필자가 영국에서 생활을 한지 어느덧 4개월이 지나가고 있다. 짧은 4개월이라는 기간이지만 파트타임 잡을 하면서 또한 여러 개발자들을 만나보면서 영국의 직장 문화를 느끼기에는 충분한 시간이었다.
누 구나 이런 꿈은 꿔봤을 것이다. 5시에 퇴근해서 가족들과 공원을 산책을 하고 또한 운동이나 자신의 취미 활동을 하면서 여유롭게 인생을 즐겨 나가는 꿈 말이다. 하지만 영국은 이런 것이 절대 꿈이 아니고 현실이다. 물론 영국에서도 다양한 회사들이 있겠지만 가장 보편적인 회사에 대해서 이야기를 해보겠다. 영국은 평균 9시에 출근해서 5시에 정시 퇴근을 한다.
프 로그래머도 다르지 않고 5시에 바로 퇴근을 한다. 만약 프로그래머가 퇴근을 못하게 될 경우 그 책임은 매니저로 돌아가게 된다. 왜냐하면 매니저가 일을 잘 분배하지 못한 것이고 윗선에는 무능력한 사람으로 보여지게 된다. 때문에 매니저는 야근을 굉장히 싫어하고 프로그래머를 빨리 집에 보내려 노력한다.
이것보다도 더 놀라운 것은 신입이든 매니저든 1년 연차를 30일을 받게 된다. 일년 중에 주 5일로 근무를 하고도 한 달을 추가로 또 쉴 수 있다는 것이다. 영국의 홀리데이를 생각해보면 이 휴가만 잘 이용한다면 거의 주4일 근무로 일할 수 있는 것이다. 한국에서는 이런 30일짜리 연차는 적어도 5~10년 정도 근속을 해야만 받을 수 있는 명예 휴가 정도가 될 것이다.
또한 프로그래머라는 직업은 소위 말하는 한국의 “사”자 직업과 같은 위상을 가지고 있다. 영국에서 일반 직종의 평균 신입 사원의 연봉은 보통 20~25만 파운드(약 4~5000만원)에 해당된다. 하지만 프로그래머의 연봉은 25~30만 파운드(5~6000만원)로 다른 직종보다 상당히 높은 편이다. 뿐만 아니라 매년 발표되는 영국의 부족한 직종 군 탑 10에는 항상 소프트웨어 엔지니어가 포함되어 있다.
너무 과장된 것이 아니냐는 생각이 들 수도 있겠지만 완벽한 사실을 적었을 뿐이다. 그리고 영국 친구에게 한국의 문화를 설명해 준 적이 있었지만 오히려 영국 친구가 이거 너무 과장이 아니냐며 굉장한 유감을 표했다.
■영국과 한국의 차이
왜 이렇게 된 것일까? 같은 일을 하지만 왜 이 땅에서는 이렇게 일해야 하는 것일까? 이것은 변하기 어려운 문화적 차이가 큰 몫을 하고 있다고 할 수 있다. 그럼 한국에서 만약 유럽에서의 회사와 같은 복지를 가진 회사가 등장한다면 어떻게 될지 생각해보자. 즉, 5시에 정시 퇴근하는 것은 물론 30일의 연차를 가지고 있는 회사가 나타난 것이다. 과연 이런 회사가 한국에서 성공할 확률은 얼마나 될 것인가? 한국은 똑똑한 사람이 많은 사회이며 그만큼 경쟁이 치열한 사회로 분류된다.
한국 에서는 이렇게 쉬엄쉬엄 일해서는 이 치열한 한국사회의 경쟁에서 살아 남기란 불가능하다. 이 직업뿐만이 아니다. 한국이란 사회의 문화가 워낙에 스피드와 신뢰를 중요시 하고 있다. 빠른 시간에 보다 정확하게 일을 끝내지 못한다면 그 회사가 몰락하는 것은 한 순간일 것이다. 누가 이렇게 만들었냐고 불평한다 해도 아쉽게도 그 누구에게 책임을 물을 수 없다. 왜냐하면 바로 한국 사람들이 그렇게 만들었기 때문이다.
예를 들어 만약 우리가 인터넷 개통을 주문한다고 가정해보자. 만약 인터넷 개통이 당일 날 혹은 못해도 다음날 개통이 되지 않고서는 절대로 주문을 하지 않을 것이다. 하지만 영국은 그렇지 않다. 여기서 인터넷 주문을 했을 때 사람들은 기본 일주일을 예상한다.
이것뿐만 아니라 모든 서비스들이 이와 비슷하게 상당히 여유롭게 처리하려고 한다. 때문에 이런 문화에 적응이 안된 한국 사람이 여기에 산다면 굉장히 답답해 할 수도 있을 것이다. 이것이 바로 문화의 차이인 것이다. 우리는 그런 한국의 빠른 서비스 문화 덕에 편안한 삶을 누릴 수 있을지 몰라도 그 이면에는 하드워킹 이라는 딜레마가 존재하게 된다. 이러한 하드워킹의 한국 문화 속에서도 IT필드의 경우는 조금 더 심한 경우라 할 수 있다.
현재 한국에서 컴퓨터 공학과의 주가는 갈수록 하향세를 그리고 있을뿐더러 실제 컴공과 학생들에게 미래의 꿈이 무엇이냐고 물어보면 50% 이상이 프로그래머는 아니라고 말하고 있는 것이 지금 대한민국의 현실이라 할 수 있다. 실제로 업계에서는 4년제 혹은 2년제 그냥 무난하게 졸업한 학생보다 IT전문가 과정 6~7개월을 이수한 학생을 더 선호하기도 한다.
그렇다면 IT 전문가 과정이란 무엇일까? 이것은 정부가 대한민국의 실업난을 극복하기 위해서 정부가 미취업자와 실업자를 대상으로 만든 무료 교육과정이다. 이 과정은 몇 백 만원의 수업료를 대신 지불해 줄 뿐만 아니라 매달 생활비도 지원해주면서 개발자 양성에 힘을 쏟고 있다. 하지만 이 정책은 개인이나 IT업계 모두에게 벌써 실패한 정책으로 낙인 찍힌 지 오래이다.
그 동안 개인의 적성은 전혀 고려되지 않은 채 마구자비로 개발자들을 찍어내어 왔고 그렇게 양성된 개발자는 IT문화의 쓴 고배를 마신 후에야 현실을 받아드리며 하나 둘씩 필드를 이탈하고 있다. 하지만 그런 인력을 계속 해서 양성하려고 하는 것이 정부의 움직임이다.
즉, 이탈과 양성이라는 악순환만 반복되고 있을 뿐인데도 말이다. 앞서 이야기한 것처럼 영국은 IT가 부족 직종으로 꼽힐 만큼 개발자들의 수가 많지 않다. 그리고 정말로 적성에 맞고 즐길 수 있는 사람들이 직업을 선택하기 때문에 좋은 환경을 누리며 개발에 전념할 수 있는 이유이기도 하다.
이 러한 정책은 고급인력을 찾기 보다는 저임금에 마음대로 부릴 수 있는 인력을 선호하게 만들어 버렸다. 중급인력 한 명이 할 수 있는 것을 초급 인력 둘을 쓰면 된다는 계산에서 더 싼 인력들만 선호하게 되는 것이고 젊은 개발자가 자신의 청춘을 불사르며 일에 전념할 가능성이 더 높다는 이유도 있다.
IT 구인 사이트를 뒤져봐도 2~3년 차의 초급개발자를 원할 뿐 7~8년 이상의 중급 개발자를 원하는 구인을 찾기 힘들다는 것을 볼 수 있을 것이다. 때문에 중급/고급 개발자는 설 자리가 없어지고 전직이나 해외 취업을 고려하고 있고 이미 수많은 IT 인력들이 한국을 떠나 간지 오래이다.
■잘못된 열정의 정의
티 맥스 소프트 박대연 회장의 발언이 IT업계를 떠들석하게 만들고 있다. 개발자들이 회사를 위해서 자신의 모든 것을 투자하고 있다고 이야기 하였고 그 때문에 건강을 잃거나 이혼을 한 개발자가 있다는 것을 아무렇지 않게 이야기 하는 것이다. 물론, 그만큼 직원들이 지금 열정을 불사르며 열심히 윈도우를 개발해 왔다라는 것을 표현하고 싶어서 던진 말이라는 것을 알고 있다.
하 지만 회사에서 많은 시간을 할애하여 일하는 것이 열정이라는 잘못된 정의가 이런 현실을 만들어 낸 것이라고 생각하고 있다. 물론, 시간을 할애하는 것이 열정의 일부분이 될 수도 있지만 그것으로 모든 열정을 재는 잣대가 되어서는 안 되는 것이다.
영 국 IT에서 일하고 있는 지인을 만나서 현지회사 인터뷰에 대해서 조언을 받은 적이 있다. 여러 질문들 중에 자신의 장점이 무엇이냐고 물어보는 질문이 있었고 자신은 일에 대한 열정이 남보다 투철하다고 대답했다고 한다. 그리고 어떻게 그 열정을 보일 수 있냐는 질문에 자신의 시간을 할애하면서까지 맡은 일을 다할 수 있다라고 대답했다. 하지만 오히려 면접 관들은 그런 행동은 다음날 일을 진행하는데 있어서 영향을 주기 때문에 그런 열정은 사양한다고 말했다고 한다.
우리는 이것을 몰라서 야근을 하고 있는 것이 아니다. 개발자는 그저 회사에 대한 나의 열정을 보여주고 싶은 것일 뿐이고 그것을 표현하는 수단이 야근이라는 잘못된 문화가 결국 개발자들을 혹사시키고 있는 것일지도 모른다.
■그렇다면 해법은 없는 것일까?
이 외에도 언급하지 못했던 정말 너무나 많이 잘못된 문화들을 가지고 있다. 그렇다면 지금에서의 최선은 무엇일까? 한국에서의 문화가 그렇기 때문에 그냥 그 문화에 적응해서 살아가야 하는 것일까? 그리고 우리나라의 개발자들은 이렇게 부조리한 IT업계의 상황들을 몰라서 이런 문화가 계속 이어져 온 것일까?
지금부터 정리할 내용이 시원한 IT업계의 해법을 해법과 개발자를 위한 행동강령을 제시하는 것은 아닐 수 있겠지만 개발자로서 지내온 기간 동안 가슴 속에서 꺼내지 않은 말들을 차근차근 정리해 보고자 한다.
결 론부터 이야기 하자면 누구도 불평은 하지만 고치려 하지 않기 때문에 한국의 IT는 계속 제자리인 것이다. 그렇다면 누가 고쳐야 하는가? 업계의 힘있는 관리자들이 해야 하는 것인가? 개발자들의 경력을 관리해주겠다며 헛다리를 집고 있는 정부가 해주어야 하는가?
아니면 하도급 문제나 개발자들의 처우의 문제가 자연스럽게 풀리길 앉아서 바라고만 있어야 할 것인가? 이 문제는 그 누구도 아닌 개발자들이 풀어야 할 과제라 할 수 있다. 바로 잘못된 문화를 고치려 하지 않고 계속 계승하려고 하는 태도가 첫 번째로 고쳐야 할 태도이다. 예를 들어 보겠다.
“오늘은 첫날이니 무리하지 말고 일찍 들어가세요.”
“뭘 이 정도로 제가 신입 때는 사생활도 없었어요.”
약 간 비약적인 예라 생각될 수도 있겠지만 개발자를 혹독한 일정으로 이끌어 가고 있는 것은 결국 개발자다. 많은 개발자들은 안 좋은 문화를 알고는 있지만 계속 계승해나가고 있다. 그저 내가 하는 노력이 결국 의미 없는 몸부림이라 생각할 뿐이다.
하지만 이것은 닭이 먼저냐 달걀이 먼저냐는 문제가 아니다. 그 업계를 형성하고 있고 또한 가장 큰 영향력을 가지고 있는 것이 바로 개발자들이기 때문이다. 인식은 있지만 진정한 행동이 없다면 바뀌기 힘든 것이 문화이다.
조 금 더 자세한 예를 들어 보자면 프로젝트 발주처 즉, 소위 갑이 있고 갑과 PM 사이의 커뮤니케이션이 원활하지 못한 덕에 잡이 늘어났다고 가정하자. 하지만 갑과의 트러블이 있을 경우 대부분 책임은 PM이 지게 된다. 그 책임은 결국 개발자에게 전달되고 회사의 사정을 아니깐 혹은 어쩔 수 없지 않은 거냐며 희생을 요구하게 된다. 하지만 그런 희생에 대한 대가는 아무것도 없는 것이 현실이다.
그 희생으로 프로젝트가 성공적으로 끝나거나 제품이 잘 개발 되었다고 해서 개발자들에게 그에 상응하는 대가가 돌아오는 것이 있다고 생각되는가? 전혀 그렇지 않기 때문에 이러한 요청을 받아드리는 개발자의 태도 개선이 필요하다는 것이다. 회사의 사정을 알고 프로젝트의 사정을 아는 이들이 개발자들의 상황은 모른다는 것이 말이 되는가?
영 국 개발자들의 이야기를 해보도록 하겠다. 영국의 개발자가 일정을 여유롭게 잡는다고 해서 절대로 일을 천천히 하거나 놀거나 하는 것이 아니다. 영국 개발자는 그 시간에 충분한 커뮤니케이션을 가질뿐더러 완벽하고 버그 없는 시스템을 만들기 위해서 노력한다. 하지만 스피드를 중시하는 한국에서는 좋은 품질의 소프트웨어를 기대하기란 쉽지 않다는 것을 알고 있을 것이다.
개 발에 시간을 투자하기도 바쁜 것이 현실인지라 충분한 커뮤니케이션을 가지기도 상당히 부담스러운 것이 사실이다. 그 결과 가끔은 사용자가 의도하지 않았던 제3의 프로그램을 만들어 낼 경우도 다반사다. 그럼 사용자는 이런 문제투성이의 프로그램을 어떻게 사용할까?
때문에 한국에서는 SM(System Management)인력을 배치하여 길면 몇 년 동안 그 프로그램을 유지보수 하며 고쳐 나가는 것이 일반화 되고 있는 것이다. 하지만 우리가 조금 더 여유를 가지고 개발에 시간을 할애한다면 보다 충분한 커뮤니케이션과 좋은 품질로 SM에 투입되는 비용을 충분히 절약할 수 있을 것이다.
그 래서 우리 개발자들도 영국의 개발자들처럼 고품질의 코드를 생산하고자 하는 노력이 있어야 한다. 최소한 자기가 맡은 기능에서는 보다 완벽하게 마무리를 하고자 하는 태도가 있어야 한다는 말이다. 앞에서 이야기 했듯이 현재 나한테 할당 된 시간이 이런데 어떻게 품질까지 생각하냐며 앉아서 불평할 수도 있겠지만 당당히 자신의 시간을 요청하고 개선하고자 하는 노력과 행동이 필요하다. 그렇지 않고서는 변하는 것은 없기 때문이다.
길고 길었던 글을 요약하도록 하겠다. 개발자들은 앞으로 이런 피해의식 속에서 그 삶은 인정한 채로 삶을 살아가지 않았으면 좋겠다. 그렇다고 사회의 부조리를 꼽아가며 사회 즉, IT 문화가 바뀌어야 한다는 호소는 이제 더 이상 큰 의미가 없다. 누가 바꾸어 줄 것이라고 기대는 접고 이제는 개발자들 스스로 자신의 직업을 바라보는 인식을 바꾸고 행동으로 옮겼으면 하는 바람이다. 우리는 개발자다. 즉, 단순한 기술 노동자가 아닌 나의 코드로 사람을 삶을 풍요롭게 만드는 개발자라는 것을 잊지 말아야 한다.
필자의 이런 작은 호소가 차디찬 마룻바닥에 치는 몸부림과 같이 의미가 크지 않다는 것은 이미 알고 있다. 시원한 해법 보다는 오히려 이런 글이 가슴을 더 먹먹해지게 만들었을까 걱정스럽기도 하다. 하지만 이런 작은 노력이 언젠가는 미래의 밝은 빛을 비출 밑거름이나마 되길 간절히 소망하는 마음으로 이 글을 맺도록 하겠다.
검색이라는 환경은 IT엔지니어들이 만들어 왔습니다. 언제든 모르는 것을 "검색" 할 수 있는 환경. 편하고 좋습니다. 무엇보다 엔지니어 스스로의 발전에 큰 도움을 주었습니다. 하지만, 위 포스트에 나오듯이 "검색형 인간성"이 "단편적 지식"이라는 폐해를 주는 것은 스스로에게도 주변을 둘러보아도 쉽게 사례를 찾을 수 있습니다.
엔지니어의 세상은 너무나 빨리 발전해 갑니다.그리고 유기적으로 얽혀 있습니다. 그렇기에 "검색형 인간성"을 버릴 수많은 없습니다. 그래서 많은 이들이 "검색형 인간"이 되어가는 상황입니다. 하지만 반대로 기본기가 중요시되는 이유는 "지식형 인간성"의 중요성을 모두가 알고 있기 때문이 아닐까요?
"검색형 인간성" 으로 부터의 지식의 단편화는 시대의 흐름상 부정할수는 없습니다. 위의 포스트에서처럼 "경험" 을 정리하고 일반화하여 단편화된 지식에 "통찰력"을 더하는 노력이 필요합니다. 그런 노력은 "지식형 인간"에 가까와 지도록 도움을 줄 것 입니다. 하나 더해서 망각을 일삼는 우리의 뇌를 위해 꾸준히 기본기를 다듬는 것. 모두가 효과적인 방법이 아닐까...라고 생각해 보았습니다.
위 포스트의 마지막 내용이 머리속에 맴도네요.
자신이 현재까지 보유한 지식이 부족할 수 있음을 항상 염두에 두고, 결정해나가는 새로운 시대이다. 어차피 상대방의 지식도 단편적인데, 무엇이 두렵겠는가…
사람의 뇌는 "기억"이라는 행위를 하려고 지속적으로 조직을 만들고 연결한다고 합니다. 이러한 작용이 멈춘다면 우리에게 기억이라는 건 존재하지 않겠지요.
뇌가 작용을 하는데도 우선순위가 있는데, 뇌는 좋아하고 편안한 것 그리고 지금 당장 중요하다고 판단하는 것에 대해서는 기억을 담당하는 조직을 반대의 내용(싫어하고 불편하고 나중에 필요한 내용 들)보다 더 많이 배치한다고 합니다.
(여담으로 이렇게 보다 더 가치 있다고 생각하는 작업에 리소스를 많이 할당하는 형태는 얼마 전에 참가했던 컨퍼런스 플랫폼데이 에서 들었던 다음커뮤니케이션의 Tenth, yahoo hadoop 시스템과 같은 대용량 분산 데이터 시스템과 유사한 형태라는??....^.^ )
암튼 이런 이유로 머리속에 있는 지식이나 아이디어는 휘발성이고 그래서 어떤 형태로던 구조적으로 저장되어야 한다고 생각합니다. 단 이동하는 동선에서 자료들은 동기화되어야 하고 언제든 접근할 수 있어야 하는데...
이전에 제가 사용하는 방식은
주 사용PC(주로 사무실) <---> 모바일기기(PDA or 스마트폰) <----> 부 사용PC(주로 집)
위와 같은 형태로 모바일기기가 각각의 PC들을 싱크하거나 언제든 접근할 수 있는 저장소의 역할을 했었습니다. 하지만 "구조적인 저장"이 이루어 지지 않으면 결국은 자료가 쌓여서 찾기 어려워지고, 중복된 자료가 많아지면서 자료를 저장하는 것의 유용성이 없어지게 되었습니다.
이런 과정을 거치다 한 줄기 빛으로 등장하게 된 위키. 무엇보다 "구조적인 저장"의 면에서 뛰어난 위키를 찾기 위해서 여러가지 위키들을 섭렵해 보았습니다.
=============================================================================== = 빔 길잡이 (VIM Tutor) 에 오신 것을 환영합니다 - Version 1.5 = ===============================================================================
빔(Vim)은 이 길잡이에서 다 설명할 수 없을 만큼 많은 명령을 가진 매우 강력한 편집기입니다. 이 길잡이는 빔을 쉽게 전천후 편집기로 사용할 수 있도록 충분한 명령에 대해 설명하고 있습니다.
이 길잡이를 떼는 데에는 실습하는 데에 얼마나 시간을 쓰는 가에 따라서 25-30 분 정도가 걸립니다.
이 연습에 포함된 명령은 내용을 고칩니다. 이 파일의 복사본을 만들어서 연습하세요. (vimtutor 를 통해 시작했다면, 이미 복사본을 사용하는 중입니다.)
중요한 것은, 이 길잡이가 직접 써보면서 배우도록 고려되어 있다는 것입니다. 명령을 제대로 익히려면, 직접 실행해보는 것이 필요합니다. 내용을 읽는 것만으로는, 명령을 잊어버리게 될 것입니다.
자 이제, Caps Lock(Shift-Lock) 키가 눌려있지 않은지 확인해보시고, j 키를 충분히 눌러서 Lesson 1.1이 화면에 가득 차도록 움직여봅시다. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 1.1: 커서 움직이기
** 커서를 움직이려면, 표시된 대로 h,j,k,l 키를 누르십시오. ** ^ k 힌트: h 키는 왼쪽에 있으며, 왼쪽으로 움직입니다. < h l > l 키는 오른쪽에 있으며, 오른쪽으로 j 움직입니다. v j 키는 아래방향 화살표처럼 생겼습니다.
1. 익숙해질 때까지 커서를 스크린 상에서 움직여 보십시오.
2. 아래 방향키 (j)를 반복입력이 될 때까지 누르고 계십시오. ---> 이제 다음 lesson으로 가는 방법을 알게 되었습니다.
3. 아래 방향키를 이용하여, Lesson 1.2 로 가십시오.
참고: 원하지 않는 무언가가 입력이 되었다면, <ESC>를 눌러서, 명령 모드로 돌아가십시오. 그 후에 원하는 명령을 다시 입력하십시오.
참고: 커서키 또한 작동할 것입니다. 하지만 hjkl에 익숙해지면, 커서키보다 훨씬 빠르게 이동할 수 있을 것입니다.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 1.2: 빔을 시작하고 끝내기
!! 주의: 아래 있는 단계를 실행하기 전에, 이 lesson 전체를 읽으십시오!!
1. <ESC> 키를 눌러서 확실하게 명령 모드로 빠져 나옵니다.
2. 다음과 같이 입력합니다: :q! <ENTER>
---> 이렇게 하면, 바뀐 내용을 *저장하지 않고* 편집기를 빠져나갑니다. 저장한 후 빠져나가려면 다음과 같이 입력합니다: :wq <ENTER>
3. 쉘 프롬프트가 보인다면, 다시 길잡이로 돌아오기 위해 다음과 같이 입력합니다. vimtutor <ENTER> 또는 다음과 같을 수도 있습니다. vim tutor.ko <ENTER>
---> 'vim' 은 빔 편집기로 들어가는 것을 뜻하며, 'tutor.ko'는 편집하려는 파일을 뜻합니다.
4. 위에서 이야기한 단계를 기억하였으며, 확신이 서면, 1에서 3까지를 수행하여 편집기를 나갔다가 다시 들어와보십시오. 그 후 커서를 아래로 움직여 Lesson 1.3 으로 가십시오. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 1.3: 텍스트 편집 - 지우기
** 명령 모드에서 x 를 누르면 커서가 위치한 곳의 글자를 지울 수 있습니다. **
1. ----> 로 표시된 곳으로를 옮시오.
2. 오타를 수정하기 위해, 커서를 지울 글자 위로 움직여 보십시오.
3. x 키를 눌러서 지워야할 글자를 지우십시오.
4. 2에서 4까지를 반복하여 문장이 올바르게 되도록 하여 보십시오.
---> The cow jumped over the moon.
5. 문장이 정확해졌다면, Lesson 1.4로 가십시오.
주의: 이 길잡이를 보면서 외우려고 하지말고, 직접 사용해보면서 익히길 바랍니다.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 1.4: 텍스트 편집 - 삽입 (INSERTION)
** 명령 모드에서 i 를 누르면 텍스트를 입력할 수 있습니다. **
1. 커서를 첫번째 ---> 로 표시된 줄로 움직입니다.
2. 첫번째 줄을 두번째 줄과 똑같이 만들것입니다. 텍스트가 들어가야할 곳 다음부터 첫번째 글자 위에 커서를 옮겨 놓습니다.
3. i 키를 누른 후, 필요한 내용을 입력합니다.
4. 수정한 후에는 <ESC> 를 눌러서 명령 모드로 돌아갑니다. 문장을 올바르게 만들기 위해 2에서 4의 과정을 반복합니다.
---> There is text misng this . ---> There is some text missing from this line.
1. 커서를 움직일 때에는 화살표 키나 hjkl 키를 이용합니다. h (왼쪽) j (아래) k (위) l (오른쪽)
2. 쉘 프롬프트에서 빔을 시작하려면 vim FILENAME <ENTER>
3. 수정한 내용을 무시한 채로 빔에서 빠져나가려면 <ESC> :q! <ENTER> 저장한 후 빔에서 빠져나가려면 <ESC> :wq <ENTER>
4. 명령 모드에서 커서가 위치한 곳의 글자를 지우려면 x 를 입력합니다.
5. 명령 모드에서 커서가 위치한 곳에 텍스트를 삽입하려면 i 를 누른 후 텍스트를 입력하고 <ESC> 를 누릅니다.
참고: <ESC>는 명령 모드로 돌아가는 데 쓰며, 원치 않는 명령이나 완전히 입력되지 않은 명령을 취소하는 데에도 씁니다.
그럼 Lesson 2를 시작합시다.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 2.1: 삭제(DELETION) 명령
** 한 단어를 끝까지 지우려면 dw 라고 치면 됩니다. **
1. <ESC> 키를 눌러서 확실하게 명령 모드로 빠져 나옵니다.
2. 아래에 ---> 로 표시된 줄 까지 커서를 옮깁니다.
3. 지워야할 단어의 처음으로 커서를 옮깁니다.
4. dw 라고 쳐서 그 단어를 지웁니다.
주의: 위에서 말한대로 하면 화면의 마지막 줄에 dw 라는 글자가 표시됩니다. 잘못 쳤다면, <ESC> 를 눌러서 다시 시작하십시오.
---> There are a some words fun that don't belong paper in this sentence.
5. 3, 4번 과정을 다시 하여 문장을 정확하게 만든 뒤 Lesson 2.2로 가십시오.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 2.2: 다른 삭제 명령
** d$ 라고 치면 그 줄 끝까지 지워집니다. **
1. <ESC> 키를 눌러서 확실하게 명령 모드로 빠져 나옵니다.
2. 아래에 ---> 로 표시된 줄 까지 커서를 옮깁니다.
3. 올바른 줄의 끝으로 커서를 옮깁니다. (첫번째로 나오는 . 다음입니다.)
4. d$ 라고 쳐서 줄 끝까지 지웁니다.
---> Somebody typed the end of this line twice. end of this line twice.
5. 어떤 일이 일어났는지 이해하기 위해 Lesson 2.3 으로 가십시오.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 2.3: 명령과 적용 대상에 대해
삭제 명령 d의 형식은 다음과 같습니다.
[횟수] d 대상 또는 d [횟수] 대상 여기서 횟수 - 명령을 몇 번 수행할 지 (옵션, 기본값=1). d - 지우는 명령 대상 - 아래에 제시된 대상에 대해 명령을 수행
적용 가능한 대상의 종류: w - 커서에서 그 단어의 끝까지 (공백 포함.) e - 커서에서 그 단어의 끝까지 (공백을 포함하지 않음.) $ - 커서에서 그 줄의 끝까지
참고: 호기심이 있다면, 명령 모드에서 명령 없이 대상을 입력해보십시오. 위에서 이야기한 대상의 목록에 따라 커서가 움직이게 됩니다.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 2.4: '명령-대상' 에 대한 예외
** dd 라고 치면 줄 전체를 지웁니다. **
줄 전체를 지우는 일이 잦기 때문에, Vi를 디자인 한 사람들은, 간단히 d를 두번 연달아 치면 한 줄을 지울 수 있도록 하였습니다.
1. 커서를 아래 나온 단락의 두번째 줄로 가져가십시오. 2. dd 를 입력하여 그 줄을 지우십시오. 3. 그런 다음 네번째 줄로 가십시오. 4. 2dd 라고 입력하여 두줄을 지웁니다. ( 횟수-명령-대상을 기억하세요. )
1) Roses are red, 2) Mud is fun, 3) Violets are blue, 4) I have a car, 5) Clocks tell time, 6) Sugar is sweet 7) And so are you.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 2.5: 취소(UNDO) 명령
** u 를 누르면 마지막 명령이 취소되며, U 는 줄 전체를 수정합니다. **
1. 커서를 ---> 로 표시된 줄로 이동한 후 첫번째 잘못된 부분 위로 옮깁니다. 2. x 를 입력하여 첫번째 잘못된 글자를 지웁니다. 3. 그럼 이제 u 를 입력하여 마지막으로 수행된 명령을 취소합니다. 4. 이번에는 x 명령을 이용하여 그 줄의 모든 에러를 수정해봅시다. 5. 대문자 U 를 눌러서 그 줄을 원래 상태로 돌려놓아 보십시오. 6. 이번에는 u 를 몇 번 눌러서 U 와 이전 명령을 취소해봅시다. 7. CTRL-R (CTRL 키를 누른 상태에서 R을 누르는 것) 을 몇 번 눌러서 명령을 다시 실행해봅시다. (취소한 것을 취소함.)
---> Fiix the errors oon thhis line and reeplace them witth undo.
1. CTRL-g 는 파일의 상태와 파일 내에서의 현재 위치를 표시합니다. SHIFT-G 는 파일의 끝으로 이동합니다. 줄번호를 입력한 후 SHIFT-G를 입력하면, 그 줄로 이동합니다.
2. / 를 입력한 후 문구를 입력하면 그 문구를 아랫방향으로 찾습니다. ? 를 입력한 후 문구를 입력하면 윗방향으로 찾습니다. 검색 후, n 을 입력하면 같은 방향으로 다음 문구를 찾으며, Shift-N 을 입력하면 반대 방향으로 찾습니다.
3. 커서가 (,),[,],{,} 위에 있을 때에 % 를 입력하면 상응하는 짝을 찾아갑니다.
4. 어떤 줄에 처음 등장하는 old를 new로 바꾸려면 :s/old/new 한 줄에 등장하는 모든 old를 new로 바꾸려면 :s/old/new/g 두 줄 #,# 사이에서 치환을 하려면 :#,#s/old/new/g 파일 내의 모든 문구를 치환하려면 :%s/old/new/g 바꿀 때마다 확인을 거치려면 'c'를 붙여서 :%s/old/new/gc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 5.1: 외부 명령 실행하는 방법
** :! 을 입력한 후 실행하려는 명령을 입력하십시오. **
1. 친숙한 명령인 : 를 입력하면 커서가 화면 아래로 이동합니다. 명령을 입력할 수 있게 됩니다.
2. 이제 ! (느낌표) 를 입력하십시오. 이렇게 하면 외부 쉘 명령을 실행할 수 있습니다.
3. 시험삼아 ! 다음에 ls 를 입력한 후 <ENTER> 를 쳐보십시오. 쉘 프롬프트 에서처럼 디렉토리의 목록이 출력될 것입니다. ls 가 동작하지 않는다면 :!dir 을 시도해 보십시오.
참고: 어떤 외부 명령도 이 방법으로 실행할 수 있습니다.
참고: 모든 : 명령은 <ENTER> 를 쳐야 마무리 됩니다.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 5.2: 보다 자세한 파일 저장
** 수정된 내용을 파일로 저장하려면, :w FILENAME 하십시오. **
1. :!dir 또는 :!ls 를 입력하여 디렉토리의 리스트를 얻어옵니다. 위의 명령 후 <ENTER>를 쳐야한다는 것은 이미 알고 있을 것입니다.
2. TEST 처럼 존재하지 않는 파일 이름을 하나 고르십시오.
3. 이제 :w TEST 라고 입력하십시오. (TEST는 당신이 선택한 파일 이름입니다.)
4. 이렇게 하면 빔 길잡이 파일 전체를 TEST라는 이름으로 저장합니다. 확인하려면, :!dir 을 다시 입력하여, 디렉토리를 살펴보십시오.
참고: 빔을 종료한 후, 빔을 다시 실행하여 TEST라는 파일을 열면, 그 파일은 저장했을 때와 완벽히 같은 복사본일 것입니다.
5. 이제 그 파일을 지웁시다. (MS-DOS에서): !del TEST (Unix에서): !rm TEST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 5.3: 선택적으로 저장하는 명령
** 파일의 일부를 저장하려면, :#,# w FILENAME 하십시오. **
1. 다시 한번, :!dir 이나 !ls 를 입력하여 디렉토리의 목록을 받아온 후 TEST 같은 적합한 이름을 선택합니다.
2. 커서를 이 페이지의 처음으로 옮긴 후, Ctrl-g 를 입력하여 그 줄의 줄번호를 알아냅니다. 이 번호를 기억하십시오!
3. 이제 이 페이지의 마지막으로 가서 Ctrl-g 를 다시 입력하십시오. 이 줄의 줄번호 또한 기억하십시오!
4. 어떤 섹션만 파일로 저장하려면, :#,# w TEST 를 입력하면 됩니다. 이 때 #,# 는 아까 기억했던 시작과 끝 줄번호 입니다. TEST는 파일 이름입니다.
5. :!dir 을 이용하여 파일이 만들어졌는지 확인하십시오. 지우지는 마십시오.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 5.4: 파일 읽어들이기, 합치기
** 어떤 파일의 내용을 삽입하려면, :r FILENAME 하십시오 **
1. :!dir 을 입력하여 아까 만든 TEST 파일이 그대로 있는지 확인하십시오.
2. 커서를 이 페이지의 처음으로 움직이십시오.
주의: 3번째 단계를 실행하면, Lesson 5.3 을 보게 될 것입니다. 그렇게 되면 이 lesson으로 다시 내려오십시오.
3. 이제 TEST 파일을 읽어들입시다. :r TEST 명령을 사용하십시오. TEST 는 파일의 이름입니다.
참고: 읽어들인 파일은 커서가 위치한 지점에서부터 놓이게 됩니다.
4. 파일이 읽어들여진 것을 확인하기 위해, 뒤로 이동해서 기존 버전과 파일에서 읽어들인 버전, 이렇게 Lesson 5.3 이 두번 반복되었음을 확인하십시오.
유용한 예: (MS-DOS) (Unix) :!dir :!ls - 디렉토리의 목록을 보여준다. :!del FILENAME :!rm FILENAME - FILENAME이라는 파일을 지운다.
2. :w FILENAME 하면 현재 빔에서 사용하는 파일을 FILENAME이라는 이름으로 디스크에 저장합니다.
3. :#,#w FILENAME 하면 #부터 #까지의 줄을 FILENAME이라는 파일로 저장합니다.
4. :r FILENAME 은 디스크에서 FILENAME이라는 파일을 불러들여서 커서 위치 뒤에 현재 파일을 집어넣습니다.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 6.1: 새 줄 열기(OPEN) 명령
** o 를 누르면 커서 아래에 줄을 만들고 편집 모드가 됩니다. **
1. 아래에 ---> 로 표시된 줄로 커서를 옮기십시오.
2. o (소문자)를 쳐서 커서 *아래에* 줄을 하나 여십시오. 편집 모드가 됩니다. Insert mode.
3. ---> 로 표시된 줄을 복사한 후 <ESC> 를 눌러서 편집 모드에서 나오십시오.
---> After typing o the cursor is placed on the open line in Insert mode.
4. 커서 *위에* 줄을 하나 만드려면, 소문자 o 대신 대문자 O 를 치면 됩니다. 아래 있는 줄에 대해 이 명령을 내려보십시오. Open up a line above this by typing Shift-O while the cursor is on this line.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 6.2: 추가(APPEND) 명령
** a 를 누르면 커서 *다음에* 글을 입력할 수 있습니다. **
1. 커서를 ---> 로 표시된 첫번째 줄의 끝으로 옮깁니다. 명령 모드에서 $ 를 이용하십시오.
2. 소문자 a 를 커서 아래 글자 *다음*에 글을 추가할 수 있습니다. (대문자 A는 그 줄의 끝에 추가합니다.)
참고: 그렇게 하시면 고작 줄의 끝에 추가를 하기 위해 i를 누르고, 커서 아래에 있던 글자를 반복하고, 글을 끼워넣고, <ESC>를 눌러 명령 모드로 돌아와서, 커서를 오른쪽으로 옮기고 마지막으로 x까지 눌러야 하는 번거로움을 피하실 수 있습니다.
3. 이제 첫 줄을 완성하십시오. 추가 명령은 텍스트가 입력되는 위치 외에는 편집 모드와 완전히 같다는 것을 유념하십시오.
---> This line will allow you to practice ---> This line will allow you to practice appending text to the end of a line.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lesson 6.3: 치환(REPLACE) 의 다른 버전
** 대문자 R 을 입력하면 하나 이상의 글자를 바꿀 수 있습니다. **
1. 커서를 ---> 로 표시된 첫번째 줄로 옮기십시오.
2. 커서를 ---> 로 표시된 두번째 줄과 다른 첫번째 단어 위로 옮기십시오. ('last' 입니다.)
3. R 을 입력한 후 첫번째 줄의 예전 텍스트 위에 새로운 글을 입력하여 나머지 내용이 두번째 줄과 같아지도록 바꿉시다.
---> To make the first line the same as the last on this page use the keys. ---> To make the first line the same as the second, type R and the new text.
3. n 키를 눌러서 'ignore' 를 다시 찾아보십시오. n 키를 계속 눌러서 여러번 찾으십시오.
4. 'hlsearch' 와 'incsearch' 옵션을 설정합시다. :set hls is
5. 찾기 명령을 다시 입력하여, 어떤 일이 일어나는지 확인해 보십시오: /ignore
6. 찾은 내용이 강조(HIGHLIGHT)된 것을 없애려면, 다음과 같이 입력합니다: :nohlsearch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LESSON 6 요약
1. o 를 입력하면 커서 *아래에* 한 줄이 열리며, 커서는 편집 모드로 열린 줄 위에 위치하게 됩니다. 대문자 O 를 입력하면 커서가 있는 줄의 *위로* 새 줄을 열게 됩니다.
2. a 를 입력하면 커서 *다음에* 글을 입력할 수 있습니다. 대문자 A 를 입력하면 자동으로 그 줄의 끝에 글자를 추가하게 됩니다.
3. 대문자 R 을 입력하면 <ESC> 를 눌러서 나가기 전까지 바꾸기 모드가 됩니다.
4. ":set xxx" 를 하면 "xxx" 옵션이 설정됩니다.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LESSON 7: 온라인 도움말 명령
** 온라인 도움말 시스템 사용하기 **
빔은 폭 넓은 온라인 도움말 시스템을 제공합니다. 도움말을 보려면, 다음 세가지 중 하나를 시도해보십시오: - <HELP> 키를 누른다. (키가 있는 경우) - <F1> 키를 누른다. (키가 있는 경우) - :help <ENTER> 라고 입력한다.
도움말 창을 닫으려면 :q <ENTER> 라고 입력하십시오.
":help" 라는 명령에 인자를 주면 어떤 주제에 관한 도움말을 찾을 수 있습니다. 다음 명령을 내려 보십시오. ( <ENTER> 키를 누르는 것을 잊지 마십시오.)
:help w :help c_<T :help insert-index :help user-manual
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LESSON 8: 시작 스크립트 만들기
** 빔의 기능 켜기 **
빔은 Vi 보다 훨씬 많은 기능을 가지고 있지만, 대부분은 기본적으로 작동하지 않습니다. 더 많은 기능을 써보려면, "vimrc" 라는 파일을 만들어야 합니다.
1. "vimrc" 파일을 수정합시다. 이 파일은 사용하는 시스템에 따라 다릅니다: 1. Start editing the "vimrc" file, this depends on your system: :edit ~/.vimrc Unix의 경우 :edit $VIM/_vimrc MS-Windows의 경우
2. 이제 "vimrc"의 예제를 읽어들입니다:
:read $VIMRUNTIME/vimrc_example.vim
3. 다음과 같이 하여 파일을 저장합니다:
:write
다음 번에 빔을 시작하면, 구문 강조(syntax highlighting)이 사용될 것입니다. 모든 원하는 설정을 이 "vimrc" 파일에 넣어둘 수 있습니다.
이것으로 빔 길잡이를 마칩니다. 이 길잡이는 빔 편집기에 대한 간략한 개요를 보여주기 위한 의도로 제작되었으며, 이 편집기를 정말 간단히 사용하기에 충분할 뿐입니다. 빔에는 이 길잡이와는 비교할 수 없을 만큼 훨씬 많은 명령이 있습니다. 다음 사용자 매뉴얼을 읽으십시오: ":help user-manual"
보다 자세히 읽고 공부하려면, 다음 책을 추천해 드립니다: Vim - Vi Improved - by Steve Oualline 출판사: New Riders 이 책은 완전히 빔에 대해서만 다루고 있습니다. 특히 초보자들에게 유용합니다. 많은 예제와 그림이 있습니다. 다음을 참고하십시오: http://iccf-holland.org/click5.html
다음 책은 좀 오래된 책으로 빔보다는 Vi에 대해 다루고 있지만, 역시 추천할 만 합니다: Learning the Vi Editor - by Linda Lamb 출판사: O'Reilly & Associates Inc. Vi로 하고 싶은 거의 모든 것에 대해 알 수 있는 좋은 책입니다. 여섯번째 개정판은 빔에 관한 내용을 포함하고 있습니다.
이 길잡이는 Colorado School of Mines의 Michael C. Pierce 와 Robert K. Ware 가 Colorado State University의 Charles Smith 의 아이디어에 착안하여 썼습니다. . E-mail: bware@mines.colorado.edu.
Modified for Vim by Bram Moolenaar.
이 문서의 한국어 버전에 관한 문의는 다음 사이트로 해주십시오. http://wiki.kldp.org/wiki.php/VimTutorKo ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
주말내내 살아있는 버그(fly...)를 소탕하느라 시간이 어떻게 지났는지 모르겠습니다.(우리생애최고의 DEBUG) 미루고 미루던 소스관리를 위해서 Linux 서버에 TRAC + SVN 을 셋업했습니다. 과정이 조금 복잡했는데 결국은 아래의 문서를 통해서 해결되었습니다(mysql-python 컴파일 오류로 인해)
관련링크
centos svn 설정
http://tykim.wordpress.com/2007/06/04/centos-50%EC%97%90-subversionsvn-%EC%84%A4%EC%B9%98/
Recently I set up a virtual server to use as a development machine. It runs on CentOS 5 and hosts several Subversion repositories with associated Trac projects.
There are many guides and plenty of help on the net to help you
setup such a system. However, when I tried to do it I came across a few
problems and I hope this post may help at least a few people trying to
do the same as me. I am not going to rewrite the great tutorials out
there, I will just point you to them and note what things I did
differently.
This 'guide' should get you from a fresh install of CentOS 5 linux to one or more working Subversion (SVN)
repositories and associated Trac wiki's. Apache/WebDAV is used as the
network layer. I have only tested this on a fresh install of CentOS 5.
The Environment
I am aiming for the following:
CentOS 5, SVN installed. Apache2 as the network layer using mod_dav_svn.
Trac running on Apache with mod_python
SVN repositories located at: /srv/svn (e.g. /srv/svn/my-project), accessible via http://server/svn/my-project
Trac projects located at: /srv/trac (e.g /srv/trac/my-project) accessible via http://server/trac/my-project
How I did it
Not all the steps are vital (probably) but this is how I got it
working. Feel free to skip any non-relevant steps (i.e. there is
probably no need for a fresh install). Replace any occurence of <project> with the name of your first project.
1. Fresh install of CentOS. I followed most of the Perfect Setup Guide, except the mail and ISPConfig stuff. The important part is setting up the Apache2 web server.
2. Make sure SVN and mod_dav_svn are installed. As root:
yum install subversion mod_dav_svn
vim /etc/httpd/conf/httpd.conf
If the following two lines are not present, add them:
Where <username> represents the username of the Trac user you just created.
13. Restart Apache:
service httpd restart
You should now have SVN and Trac installed. You will have an SVN
repository setup (http://server/svn/<project>) and the Trac wiki
(http://server/trac/<project>) associated with the repository.
Please let me know if this helped you. If you come across any problems I will be happy to try and help.
아무 책방이든 상관없이 들어가서 보면, 7일 안에 자바(Java) 완성이외에 비주얼 베이직(Visual Basic), 윈도우(Windows), 인터넷(the Internet)을 불과 몇시간 또는 몇일에 정복하기의 제목의 책들을 끝없이 나란히 진열된 것을 볼 것이다. Amazon.com에서 다음과 같은 고급(파워) 검색을 했었을때
결과가 무려 248개나 나왔다. 첫 78개는 컴퓨터 관련 책 이었다 (79번은 30 일안에 벵골어 배우기였다.) 나는 "일"대신 "시간"를 입력해봤다. 몇일을 " 몇시간으로" 대체했었을때 놀랍게도 아주 근접한 결과을 얻었다: 곁에 따르는 253개의 책중에 77개의 컴퓨터 책이였고 제 78에 24 시간안에 문법 직접배우기이 있었다. 결과의 최고 200개에서, 96%은 컴퓨터 책 이었다.
이런 결과를 보고 결론 지을 수 있는 것은 컴퓨터를 배울려고 하는 사람들의 큰 붐이 있거나, 컴퓨터를 배우기는 그
어떤것보다도 엄청 배우기 쉽다는 것이다. 베토벤, 물리학, 또는 심지어 개 손질법을 단 몇일 안에 정복하기라는 책은 없다.
정복하기: 3 일 안에 규모있는 프로그램을 쓸 시간이 없다 그리고 그 프로그램을 쓰는데
성공 아니면 실펴함으로의 경험을 통해 배우지 못한다. 경험있는 프로그래머와 같이 일하고 그런 환경 속에서 일하는 것이 어떤
것이가를 알 수 없다. 짧게 말해서 많은 것을 배울 시간이 없다. 그러므로 이런 책 내용들은 깊은 내용들은 물론 못하거니와
표면상으로 이해 할 수 있는 내용들만 다룰 수 밖에 없다. Alexander 로마 교황 말했듯이, 조금만 배우는 것은 위험한 것
이다.
Pascal: 3일안에 Pascal의 문버은 배울 수 있을지는 몰라도 (특별이 미미 비슷한
언어를 알고 있다면) 그 분법을 어떻게 제대로 쓰는지를 배울 수는 없다. 예를 들어, 당신이 Basic 프로그래머이라면
Pascal의 분법으로 Basic 스타일의 프로그램을 짤 수 있을지는 몰라도 Pascal이 어떤 과제 위해 좋으며 무슨 일를
위해 나쁜지 배울 수 없다. 내 취지는 무엇인가? Alan Perlis는
이렇게 말했다: "당신의 프로그램잉 관한 생각 하는 부분에 영향을 미치지 않는 언어는 아니면 배울 가치가 없다. 당신이 업무를
때문에, 현재 쓰는 도구와 연결해서 쓰기 위해 Pascal(또는 더 현실적인 Visual Basic이나 JavaScript)를
약간 배웠다고 하자. 그러나 당신은 프로그램잉을 어떻게 하는 지를 배운 것이 아니라 업무를 어떻게 완수하는지를 배운 것이다.
몇일 안에: 다음 글에 설명하듯이 몇일 가지고는 터문이 없이 부족하다.
10년 안에 프로그램잉을 정복하기
체스, 음악 작곡, 미술, 피아노, 수영, 테니스, neuropsychology 연구, 위상 수학, 등, 어느 많고 다양한 분야에서 전문가가 되기 위해서는 보통 십년 정도가 걸린다고 연구자(Hayes와 Bloom)
들은 말한다. 지름길은 없다. 4살때 부터 신동이라 불려진 Mozart도 세계적인 음악을 만들기까지 13년이 더 결였다.
Beatles는 1964년도에 Ed Sullivan쇼에 출연하고, 연속 #1 히트들로 단숨에 유명해 졌다. 하지만, 그들은
1957년도 부터 Liverpool과 Hamburg의 작은 클럽에서 활동을 시작했었고, 일찍부터 mass appeal이
있었지만, critical success는 1967년도에 Sgt. Pepper로 비로써 이루어냈다. Samuel
Johnson는 10년보다 더 오래 걸린다고 생각했다: "탁월함은 일생의 노력과 노동에 의해여만 달성할 수 있다; 그 것은 그
이하의 값으로 이룰 수 있는 것이 아니다." Chaucer는 "the lyf so short, the craft so long
to lerne"라고 호소했다.
여기서 프로그램임을 정복하기 위한 나의 비법이 있다:
먼저 프로그램임에 흥미을 가지고, 재미로 조금만 해보십시오. 10년를 투자할 만큼 충분히 재미를 느끼는 것이란 걸 확인해라.
다른 프로그래머들과 대화를 하십시오; 다른 프로그램들의 소스를 읽으십시요. 이것은 어떤 책또는 훈련 과정보다는 더 중요하다.
프로그램잉을 하십시오. 최선의 학습방법은 하면서 배우는 것이다. 더 전문적으로 표현하자면, "특정 영역안에 개인의 성과 극대 수준은 장시간 경험의 기능으로서 자동 적으로 달성하지 않는다. 그러나 성과의 수준은 개량하는 의도적인 노력의 결과으로서 높은 경험자들도 증가될 수 있다(p. 366)." "효과적인 학습은 개인에게 적당한 수준에 어렵고 분명한 업무, 유익한 피드백과 반복과 과실을 고칠 수 있는 기회를 요구한다." (p. 20-21) 인식의 실제: 매일 생활 속의 마음, 수학 및 문화는 이 관점에 관련된 재밌는 참고서다.
원한다면, 대학에 4년을 (또는 대학원에 더) 투자하십시오. 학위는 자격증을 요구하는 직업에 취직 자격을 줄 것이다,
그리고 분야에 더 깊은 이해를 주지만, 학교에 관심이 없다면 (노력을 한다면) 직업을 통해서 비슷한 경험을 얻을 수 있다.
어찌됐든, 혼자서 책으로만 배우는 건 부족하다. "솔과 안료을 공부함으로 전문화가가 될 수 없듯이 아무나 컴퓨터 과학 교육으로만
전문프로그램어를 만들지 못한다."라고 Eric Raymond가 The New Hacker's Dictionary에 적었다. 내가
이제까지 고용한 최고의 프로그래머중 한 사람은 고졸이였다. 그는 좋은소프트웨어를 많이 만들었고, 그의 고유 뉴스 그룹도 가지고 있으며, stock option으로 나보다 더 부자임은 틀림없다.
다른 프로그래머들과 같이 프로젝트들을 하십시오. 때론 프로젝트의 가장 실력있는 프로그래머가 되고; 때론 프로젝트의 가장
실력없는 프로그래머가 되라. 가장 실력있는 프로그래머일땐 다른 사람들에게 비젼을 주고 그리고 사람들을 이끄는 능력을 시험하게
된다. 가장 실력없는 프로그래머일때는 고수들이 하는 것들과 그들이 싫어하는 것들을 배울 수 있다 (왜냐면, 싫어하는 것들은
당신에게 시킨다).
다른 프로그래머들을 시작한 프로젝트에 뒤늦게 동참하십시오. 다른사람이 짠 프로그램을 이해하도록 몰두하십시오. 원래
프로그래머가 없었을때 그 것을 이해하고 고치기 위해서 무엇이 요구되는지 보십시오. 당신의 프로그램을 다른 사람이 유지해야 할때
보다 더 쉽게 관리 할 수 있도록 어떻게 당신의 프로그램들을 디자인해야 할까를 고민하십시오.
최소 다섯가지 프로그램잉 언어를 배우십시오. class abstractions (자바 또는 C++) 지원하는 언어,
coroutines을 (Icon 또는 Scheme) 지원하는 언어, functional abstraction (Lisp 또는
ML) 지원하는 언어, syntactic abstraction (Lisp) 지원하는 언어, declarative
specifications를 (Prolog또는 C++ 템플렛) 지원하는 언어, 그리고 parallelism을 (Sisal)
지원하는 언어를 한개씩 배우십시오.
"컴퓨터 과학"안에 " 컴퓨터"가 있는 것을 기억하십시요. 당신의 컴퓨터가 한 명령을 실행할때, 메모리에서 word를
가지고 올때, 디스크에서 연속 word를 가지고 올때, 디스크안에 새로운 위치를 찾을 때 걸리는 시간과 속도를 아십시오. 답
언어 표준화 노력에 참여하십시오. ANSI C++ 위원회 일 수도 있거나, 당신의 현 코딩 스타일을 2칸 아니면 4칸
들여쓰기 할 것인가를 결정할 수도 있다. 다른사람들이 한 언어의 어떤 것을 좋아는지, 그들에게 그 것들이 얼마나 중요한 것인지,
어쩌면 왜 그것을 좋아하는지까지도 알게 될 것이다.
가능한한 빠르게 언어 규격화 노력에서 해방되는 좋은 느낌을 채험해 보십시오.
위것들을 고려할때, 책 학습으로만 어디까지 배울 수 있을까를 의심해볼 여지가 있다. 내 첫째 아이가 태어나기 전에, 찾을
수 있는 모든 How To 책들을 읽었지만, 그래도 초보자로 느껴졌다. 30달 후에, 둘째 아이가 태어났을때 쯤, 난 예전에
읽었던 책들을 다시 들여다 봤을까? 아니다. 대신 나는 전문가가 쓴 천장의 페이지보다도 나에게 더 유용고 자신감을준 내 개인
경험에 의지했다.
Fred Brooks는, 그의 에세이 No Silver Bullets에 굉장한 소프트웨어 디자이너들을 찾아주는 three-part계획을 확인했다:
체계적으로 가능한한 빨리 최고 디자이너들을 확인하십시요.
유력 후보자의 발달과 경력 파일을 책임질 경력 지도자을 선임하십시오.
성장하는 디자이너들이 서로 자극할 수 있는 기회들을 제공하십시오.
이 것들은 이미 굉장한 디자이너가 되기 위해 필요한 자질들을 가지고 있다고 가정한다. 직업이 그들을 적당하게 coax할 것이다. Alan Perlis은 그 것을 명확하게 표현한다: "조각하는 방법은 누구나에게 가르칠 수 있다: Michelangelo는 조각 방법을 못하는 방법을 가르켜 줬을야 했을 것이다. 훌륭한 프로그래머들도 마찬가지다."
이렇게 전방 가고 자바 저 책을 사십시요; 너는 사실 같게 그것의 얼마간 사용을 밖으로 얻을 것이다. 그러나 너는 24
시간, 일,또는 조차 개월안에프로그래머으로서 너의 일생, 또는 너의 진짜 전부전문가적 의견을 변경하지 않을 것이다.
T. Capey가 Amazon의 Complete Problem Solver Page에 "Teach Yourself
Bengali in 21 days"와 "Teach Yourself Grammar and Style" 책들을 "Customers
who shopped for this item also shopped for these items" 구역에 보여주고 있음을
지적했다. 이 책들을 본 사람들 중에 많은 사람들이 이 페이지에서 찾아 가고 있는 가보다.
댓글을 달아 주세요