Windows Phone 7
IT 2010. 2. 16. 10:29이번 MWC의 다양한 화젯거리 가운데에서도 단연 주목도가 높은 화제를 꼽으라면 오늘 정식으로 발표된 MS의 새로운 모바일 OS가 될 것이다. 몇년 전부터 개발에 대한 이야기가 나왔던 것을 생각해 보면 좀 늦은 감이 있는 발표인데, 특히 실제 기기가 출시될 시기(올해 4분기 즈음)과 함께 이미 WM기반의 기기들의 입지가 상당부분 축소된 것을 생각해 보면 그런 느낌이 쉬이 가시지는 않는다.
다만 그만큼의 개발 기간이 무색하지 않을 정도로 사람들의 기대치를 한껏 만족시킬 수 있는 첫인상을 보여주었다는 것이 좋은 소득이라고 하겠다. 이전까지 알음알음 누출되었던 Windows Mobile 7이라는 이름의 스크린샷들은 전반적으로는 기존 WM이 가지고 있던 설계 기반을 유지한 채로 UI만 현대적으로 외관을 바꾸어 내는 정도에 가까웠다. 개발기간이 길어지고 몇몇 사정이 더해지면서 이는 6.5x기반의 지향점이 되었고, 반대로 Windows Phone 7은 그 이상의 변화를 보여주게 되었다.
Windows Phone 7의 UI는 전체적으로 작년에 MS가 출시했던 미디어 단말인 Zune HD의 문자 기반 UI를 바탕으로 하고 있는데, 이는 Zune HD 출시때부터 줄기차게 끊이지 않던 Zune 기반의 모바일 단말기가 등장하리라는 예측이 맞아 떨어진 것이기도 하다. 작게 보면 Zune HD - Windows Phone 7의 관계는 애플의 iPod-iPhone이 보여주는 관계와도 비교적 유사하다. 이에 더해 이미 잘 구축된 Xbox 기반의 게이머 네트워크와의 융합, 전통적으로 MS가 강세였던 Office 제품군들과의 통합 등 전반적인 네트워크와 시스템 및 그 시스템을 이용하는 사용자들을 모바일 OS 수준에서 유기적으로 연동하려는 시도는 굉장히 기대가 된다.
물론 반대로, 이미 이에 관한 루머들이 흘러나오고 있지만 기존 WM단말을 기반으로 제작된 어플리케이션의 호환성은 어떠한 정책으로 관리할 것인지는 문제가 되지 않을까 한다. 현재 루머처럼 WM단말과의 호환성을 배제하고 WM라인업을 저가 라이센싱 정책으로 가져갈 경우, 두 개의 플랫폼이 공존하는 것은 큰 문제가 아니라 하더라도 (Symbian도 Maemo/S60라인업을 가지고 있다) Windows Phone 7 자체는 시장에 완전히 새로이 진입하는 신규 플랫폼이 된다는 사실은 문제가 된다. 현재 발표된 파트너들의 면면은 화려하지만, 이미 구축된 시장이 만만한 시장이 아니라는 것은 분명하기 때문이다.
어찌되었든 이미 죽어가는 자식이라는 표현이 틀리지 않을 정도로 힘을 쓰지 못하던 WM라인업을 과감하게 끊어내고, 완전히 새로운 기반을 선보인 것만으로도 사람들을 한번 더 기대하게 만든 제품이 아닌가 싶다. 첫 제품들이 출시될 즈음 시장은 매우 재미있어질 것 같다. 이미 세력을 굳힌 Apple이 타격이 더 클까, 아니면 본격적으로 세를 넓히기 위해 안간힘을 쓰는 안드로이드쪽에 타격이 더 클까?
p.s : 여러모로 열심히 준비한 것 같은 삼성의 바다에게 묵념. 여러모로 고생한 흔적이 보이지 않는 것은 아니지만 아무래도 좀....
게임 테스터의 미래는 장밋빛인가?
IT 2009. 7. 7. 21:15게임을 포함한 S/W 제작 공정에서 품질 보증 단계(이하 QA)는 항상 계륵에 가까운 존재라서, 필요성은 누구나 인식하고 있지만 그로 인한 프로세스의 지연이나 비용 발생 문제를 제작 단계에 포함시키지 않으려는 인식 또한 공존하고 있습니다. 이로 인해 QA 단계는 실제 개발 단계에 비해 상대적으로 낮은 비중으로 취급당해왔던 것이 보통이고, 관련 분야 종사자들 또한 상대적으로 좋지 못한 대우를 받았던 것도 사실입니다. 해외/국내 가리지 않고 전반적으로 이런 인식은 존재하지만 국내에서는 사정이 조금 더 좋지 못했는데, 다행히도 근래 들어서는 제법 주목할 만한 노력들을 통해 조금씩 상황이 나아지고 있습니다. 다만 아직까지도 이 분야는 명징하게 정리하기에는 부족한 부분이 적지 않아서, 일반적인 매체에서 이 분야를 다룰 때에도 그로 인한 오해가 생기는 경우가 종종 있습니다. 이번에 한국경제신문에서 게재한 기사 또한 그러한 맥락의 연장선이라고 볼 수 있을 것 같은데, 업계 종사 지망자들에게 꿈을 주는 것도 좋지만 명확하게 현실을 인식하는 것도 분명히 필요한 일이라고 생각해서 기사 내용을 보충해보고자 합니다.
1. 정말로 충분히 숙련된 테스터의 연봉이 5000만원 선인가?
특정 직군의 연봉을 명확하게 제시하는 것은 적지 않게 위험한 일입니다만, 헤드라인부터 자극적으로 작성된 기사인데 지망자들에게는 가장 중요한 부분이니 만큼 이 부분을 먼저 짚고 넘어갈 수 밖에 없을 것 같습니다. 국내에서는 아직까지 신빙성 있는 통계자료가 명확하게 공개되어 있지 않아서, 일단 해외 기준으로 통계를 참조한 후 국내 기준으로 외삽하였습니다. 통계자료의 모집단이라든가, 해외-국내간 연봉차이 등에서 실제로 많은 변수가 있으니 이를 명백한 사실로 받아들이는 것은 위험하지만, 일반적인 추세선을 확인하는 것에는 문제가 없으리라고 생각합니다. 이 통계에 참가한 직업 종사자는 대체로 북미지역에 거주하는 개발자들입니다.
먼저, 주요 직군인 프로그래머 쪽의 자료를 살펴보면 아래와 같습니다.
Game Developer Apr.09
6년차 이상을 기준으로 보았을때 팀장급이 아닌 일반 프로그래머의 평균 연봉은 대략 98,000$로, 한화로 환산하면 환율에 따라 변동이 있지만 약 1억이 넘는 수준입니다. 팀장급과 디렉터를 포함하면 이 평균은 다소 상승해서 107,000$ 수준이 되는데, 약 1.3-4억 정도가 된다고 생각하면 되리라고 봅니다. 수치에서도 바로 드러나지만 이 결과는 한국 기준과는 굉장히 상이한 차이를 보이게 되는데, 거주지역별 평균 임금 차이와 함께 IT종사자에 대한 연봉 차이가 상존하기 때문에 이러한 결과가 나타나고 있습니다. 같은 통계자료지만 이전(08년도 기준)을 이용하여 국내 기업과의 차이를 비교한 TIG의 기사(읽으러 가기)를 확인해 보면, 근무 기간을 밝히고 있지는 않지만 국내 기업인 PayOpen의 통계 기준으로 평균 4,000만원 가량이며, NHN과 엔씨소프트가 금융감독위원회에 보고한 평균연봉이 5,100만원 정도임을 확인할 수 있습니다. 통계자료의 불확실성과 단순 비교로 인한 문제를 감안하더라도 북미 기준으로 절반에 가까운 차이가 납니다. 그럼 본론으로 돌아와서 같은 통계자료에서 Q/A와 테스터에 대한 항목을 살펴보면 아래와 같습니다.
Game Developer Apr.09
특이한 점이 6년차 이상의 테스터 항목이 아예 없다는 점인데, 이 부분은 다음 항목에서 설명하기로 하고 일단 팀장급의 QA 담당자만 자료를 확인하면 약 80,000$ 정도를 년수입으로 가지고 있는 것을 볼 수 있습니다. 해외 쪽에서도 프로그래머 직군에 비해 상대적으로 대우가 조금 낮은 편이라 약 20,000$ 정도의 차이를 가지는 것을 볼 수 있는데, 국내에서는 이 직군에 대한 통계자료가 없으므로 프로그래머와 동일한 기준으로 국내에서 비슷하게 적용된다고 가정하고 생각해 보면 약 3000만원 정도가 된다고 추측해 볼 수 있습니다. 굉장히 거친 추측방법이라 이것이 사실이라고 이야기할 수는 없지만, 그렇다고 해도 기사에서 제시하고 있는 금액과는 무려 2,000만원에 가까운 차이가 발생한다는 점은 생각해 볼 만한 점이 아닌가 합니다. 이에 붙여 3-6년차와 6년차 이상의 수입 차이가 매우 큰 폭으로 증가한다는 점도 주목할 만 한데, 당연히 생각해 볼 수 있는 것은 충분한 경험을 쌓은 QA 팀장급에 대한 대우가 일반적인 QA/테스팅 종사자에 비해 좋다는 것이며, 역으로 생각하면 그러한 수요에 부응할 만큼 충분히 QA를 기반으로 경험을 쌓는 사람이 없다는 의미일 수도 있습니다. 이는 앞서 이야기한 대로 바로 다음 항목에서 이야기합니다.
2. 연봉 이전에, 10년차 테스터가 몇 명이나 되는가?
이전 말미에도 언급했지만, 추측에 기반한 수치보다도 사실 더 신경쓰이는 부분이 있습니다. 해외 통계자료에서 6년차 이상의 테스터가 공란으로 처리되어 있고 팀장급의 연봉만 제시되어 있다는 사실입니다. 작년이나 07년 통계자료를 살펴보아도 이 부분은 언제나 N/A로 처리되어 있습니다.
한 마디로 이야기하자면, 말 그대로 6년차 이상으로 테스터로 종사하는 사람들이 많지 않다는 이야기입니다. 물론 이 부분은 일반적인 S/W 제작 환경에 전부 적용되는 이야기가 아니며, 게임 제작이라는 특수한 환경에 적용되는 것임은 먼저 언급하겠습니다. 이러한 결과를 보이는 이유로 크게 두 가지를 들 수가 있는데,
1) QA직군 종사자의 커리어 패스 설정
2) 개발사의 QA 운영 방식의 변화
가 그것입니다.
폄하하는 것은 아닙니다만, 게임 개발 공정에서 비교적 비주요 직군으로 분류되는 직군이 있습니다. 상대적으로 기반 지식을 크게 요구하지 않으며, 공정의 진행을 인력과 시간의 투입으로 해결하는 경우가 많은 직군들이 그렇습니다. 이미 비교적 잘 알려져 있는 온라인 게임류의 GM이라든가, 지금 이야기하고 있는 게임에서의 테스팅과 같은 업무들이 그렇습니다. 게임에서의 QA도 종류가 많고 개발 프로세스와 깊은 연관이 있는 업무들도 있지만 일반적으로 테스팅 팀에서의 테스트는 그러한 개발 단계에서의 테스트라기보다는 빌드된 어플리케이션의 블랙박스 테스팅을 기준으로 하는 경우가 많고, 이러한 작업들은 다른 직군에 비해 상대적으로 고숙련자와 저숙련자의 차이가 크지 않은, 즉 장기적인 커리어로 설정하고 일하기에는 조금 무리가 있는 업무입니다. 해서 일정 이상 종사한 사람들의 경우 팀을 이끄는 사람이 되거나, 혹은 화이트박스 테스팅과 같이 개발 공정에 함께 참여하거나, 혹은 아예 다른 분야로 옮겨가는 경우가 적지 않습니다. 비단 국내 뿐만이 아니라 이는 해외에서도 마찬가지의 경우로, 실제로 몇 년 전의 통계 조사에서의 설문에서도 QA 직군의 종사 이유를 다른 게임 개발 공정에 참여하는 기회로 삼고 있다는 대답이 전체에서 적지 않은 비중을 차지했습니다. 이는 QA직군이 여타 직종에 비해 상대적으로 학력을 크게 필요로 하지 않으며 동시에 진입 장벽이 낮음에 기인하는 것으로, 이미 국내에서도 흔히 알려진 예인 [GM으로 시작해서 게임 개발에 참여하려는] 것과 유사한 경우라고 볼 수 있습니다.
"When it comes to getting paid, game testers don't get no love. They are the runts of the industry, and everyone-including the people who determine their salaries-knows it. It's no surprise that the Q/A department pulls in the lowest average salary, has the lowest chance of receiving additional income (like a bonus), is the least likely to have a graduate degree, and is the least likely to earn benefits.
The beauty of Q/A, of course, is that one needs zero formal experience to get a job. As long as you can show you know a thing or two about video games, are capable of breaking them, and can intelligently articulate what broke and when, you're hirable. It seems the difficult part is figuring out exactly how to rise above the daily duties of repetitively collision-testing while sitting in a super-air conditioned dungeon, all the while scheming about how the rent is going to get paid."
Jill Duffy의 [The Game industry salary survey 2007]의 QA/테스터 항목에서 발췌한 부분입니다. 국내 뿐만 아니라 해외에서도 아직까지 QA부분에 대한 인식이 당사자들 사이에서도 그리 좋지만은 않음을 보여주는 부분이라 하겠습니다.
이러한 개인적인 이유를 제외하고도 생각해야 하는 한 가지가 게임 개발사들이 QA 팀을 운영하는 방식입니다. 앞서 이야기한 소위 비주요 직군과 직접적인 개발이 이루어지는 직군과의 차이가 하나 더 있는데, 팀을 반드시 자체적으로 운영하지는 않는다는 점이 그것입니다. 어느 게임 개발사이든 프로그래밍 팀을 외주로 운영하는 경우를 찾기는 결코 쉽지 않지만, GM이나 QA과정을 외주로 맡겨서 진행하는 경우는 비교적 흔하게 찾아볼 수 있습니다. QA 과정은 특히나, 특별하게 개발 공정을 계획하지 않는 한 주로 게임 제작의 후반부에 가서야 어마어마한 부하가 걸리는 경우가 많습니다. 이러한 상황 때문에 상시적으로 QA팀을 내부에서 운용하는 것을 달가워하지 않는 회사들이 종종 있으며, 이러한 회사들을 위해 외주 계약을 한 다음 필요한 경우에 시간 단위로 급여를 지급하는 테스터들을 임시적으로 고용하여 테스팅을 진행하는 외주 회사들이 해외에는 제법 있습니다. 국내에도 형태는 약간씩 다르지만 이러한 외주 형태의 QA 전담회사를 만든 회사들이 있고 - N사 같은 경우 - 이를 이용해 대규모의 QA인력을 상시 보유하지 않은 경우가 생겼습니다. 이렇게 되는 경우 실제로 게임을 테스팅하는 테스터의 직업 안정성은 더욱 낮아지게 되는데, 국내에서도 해외에서처럼 각 게임단위별로 계약직 직원을 임시채용하는 경우가 생기지 않으리라는 보장이 없습니다.
실제로 개발사에서 QA를 운용하는 경우에도 각 테스터에 대한 채용대우는 비교적 박한 편인데, 연봉 수준을 논하지 않더라도 채용 형태에 있어서 몇몇 규모있는 회사들을 제외하고는 안정적인 정직원 형태로 테스터를 고용하는 경우를 찾기는 쉽지 않습니다. 이미 앞서 이야기했듯 비숙련자와 고숙련자의 차이가 다른 직군에 비할 때는 그렇게 크지 않은 경우가 있어서, 회사를 운영하는 입장에서는 정직원을 고용하는 것보다는 계약직으로 직원들을 회전시키는 것이 낫다는 판단을 하는 경우가 있기 때문입니다.
이러한 두 가지 경우가 함께 얽히게 되면서 장기적으로 QA 분야에서 일하려는 지망자를 찾는 일은 결코 쉽지 않아집니다. 실제로 QA나 테스팅이라고 뭉뚱그려 이야기하지만 그 직무분야 내에서도 다양한 형태의 일이 있고, 개발 공정에서부터 개발팀과 연계하여 코드 생산에 기여하는 테스팅 부분이 있는가 하면 일반적으로 외부에서 인식하는 단순 블랙박스 테스팅에 이르기까지 필요로 하는 기술과 수준은 전부 제각각입니다. 회사에서도 단순한 테스팅 인력을 장기적으로 보유하면서 숙련도를 높이는 것보다는 북미쪽 통계에서 그러하듯 일정 이상의 기술 수준을 보유한 전문 인력을 확보하는 것을 더욱 달가워 하고, 그렇지 않은 부분은 언급했듯 외주나 계약직과 같은 방법을 통해 적절한 수준에서 관리하려는 것이 사실입니다. 단순 테스팅 업무에서 시작하게 되는 사람이라면 당연히 시간이 흐르게 되면 전문성을 살린 QA 전문가로서의 경로를 생각하거나, 아니면 다른 분야로의 이동을 생각할 수 밖에 없는 환경이고 보면 어찌되었든 소수일 수 밖에 없는 [경력이 많은] 테스터가 받는 임금 수준을 포장해서 제시하는게 아닌가 합니다. 물론 실제로 그러한 경우가 없는 것은 아닙니다만, [그럴 수도 있다] 는 것과 [대체로 그러하다]는 것 사이의 간극은 생각해 볼 필요가 있겠습니다.
3. 결론
꿈과 희망으로 가득찬 기사에 대고 좀 우울한 소리를 해버린 것 같지만, 기사에서 언급하는 것처럼 테스팅 직군이 특별한 지식 없이 열심히만 하면 일정 이상의 대우를 받을 수 있는 직종은 아니라는 것은 명백한 사실입니다. 사실 저런 식의 발언은 실제로 현업에서 많은 고민을 하고, 연구하고 공부하면서 좀 더 나은 수준의 결과물을 만드려는 테스터들을 단순히 [게임만 열심히 하면서 돈을 받는] 수준으로 격하하는 부분도 조금 있다고 생각합니다. QA/테스팅 분야의 중요성은 S/W의 복잡도가 증가하는 만큼 중요성에 대한 인식이 증가하고 있고, 완성된 어플리케이션을 만드는 데 있어서 필수적인 과정이라는 점에서도 충분한 매력이 있는 부분입니다. 그만큼 매체에서 달콤한 포장뿐 아니라 조금 더 정확한 정보를 제공하고, 이를 기반으로 자신의 미래를 설계할 수 있도록 도울 수 있으면 좋겠습니다.
Balsamiq : fast UI prototyping
IT 2009. 2. 1. 00:39http://www.balsamiq.com
붓으로 글을 써내려가는데 있어서야 혼신의 힘을 다해 일필휘지로 내리그은 다음 덧대지 않는 것이 가장 바람직한 일이겠지만 코드를 작성하는 데 있어서만큼은 그러한 경우를 맞이하기란 거의 불가능에 가깝다. 특히나 다양한 사용자의 요구를 반영해야 하는 UI를 작성할 때는 한번에 완성된 작품을 만들어내기보다는 빠른 시간 안에 프로토타입을 만들고 이를 지속적으로 변경하는 것이 훨씬 유용하다.
종이에다가 슥슥 그려내는 가장 원초적인 방법에서부터 비지오나 파워포인트같은 툴을 이용한 간단한 드로잉, 그리고 기능하지 않는 더미 코드들을 이용하여 실제로 UI를 구현하는 방법까지 프로토타입을 만드는 방법을 꼽자면 그 수만 해도 손가락의 갯수를 족히 넘겠다. 개인적으로는 지금 만들고 있던 툴을 시작할 때 생각없이 코드로 UI를 구현하고 기능을 덧붙이는 방법을 택했었는데 변경사항이 늘어나면서 죽을 고생을 한두번 했던 경험이 있다. 코드를 작성하지 않는 사용자의 경우 요구사항이 구체적이지도 않거니와 UI요소와 기능 사이를 넘나드는 변경사항을 요구하는 경우가 굉장히 잦은데, 처음에 더미 코드를 이용해 UI를 먼저 만들고 기능을 추가하다가 변경사항때문에 UI요소를 다 뜯어내고 기능을 붙여야 하는 상황이 생기기 때문이다.
정확한 예는 아니지만 다음과 같은 상황을 생각해보면 되겠다. 프로그램 동작을 모니터링하는 로그 패널이 필요하다는 요구사항을 받고 단순히 텍스트 컨트롤이면 문제 없으리라고 생각하고 텍스트컨트롤을 이용해 UI요소에 대한 확정을 받고 기능을 구현하다가 사용자에게서 다음과 같은 요청을 받게 된다. [그런데 저 로그 패널은 맘대로 뜯었다 붙였다 할 수 있고 숨기기 기능이 있으면 좋을 것 같은데 말입니다] ...끄르르르륵.
이런 이유로 더미 어플리케이션을 이용한 UI 프로토타입을 집어치우고 Balsamiq을 이용하기 시작했다. Balsamiq은 앞서 이야기한 프로토타이핑의 방법 가운데 종이와 툴 사이 정도에 위치한 툴인데, 종이 프로토타이핑에 흔히 쓰이는 요소들을 추려내어 PC 기반의 툴로 다시 만들어 내었다. 종이에 그려대는 프로토타입이 빠른 작성에는 용이하지만 저장하고 공유하기에는 불편하고 비지오 같은 드로잉툴은 저장과 공유에는 비교적 편리하지만 범용의 툴이라 UI요소만을 작성하기에는 아무래도 복잡하다는 단점을 해결할 수 있는 도구가 될 수 있겠다.
실제 사용 장면. 종이 공책을 옮겨온 듯한 Look&Feel이 인상적이다.
팀원이나 사용자의 요구에 의해 지속적으로 UI를 변경해야 하는 상황이라면 충분히 고려해 볼 만한 어플리케이션이다. AIR 기반의 어플리케이션인데 AIR의 문제인지 어플리케이션의 문제인지 약간 불안정한 면이 있고 앞으로 UI요소가 지속적으로 증가할 경우 현재 버전이 가진 직관성을 해칠 수도 있다는 우려가 없지 않지만 현재로서는 사용해볼 만한 어플리케이션.
B모 플레이어를 보고 따라 그려본 프로토타입. 완성하는데 15분이 채 걸리지 않았다.
p.s 2 : 텍스트박스를 열고 영어 더미 텍스트인 Lorem Ipsum을 입력해보라.
Mercurial on Cafe24
IT 2008. 11. 26. 02:53사실 Mercurial은 분산 작업 환경을 염두에 두고 만들어진 버전 관리 시스템이기 때문에 중앙 서버 없이도 작업에 전혀 문제가 없지만, 편의성을 생각한다면 역시 항상 구동 가능한 형태의 서버가 하나 있는 편이 낫다. 특히나 한국같이 네트웍이 공유기라든가 각종 설정때문에 복잡하게 얽혀 있어 80포트를 이용하는 http 서버마저도 정상적으로 동작하지 않는 경우 - 특정 ISP에서는 저런 포트를 부러 차단하는 경우도 있고 - 를 가끔 보는 상황에서는 ChangeSet 동기화를 위해 서버를 열었더니 접속이 안된대더라, 는 문제가 생기지 말라는 법이 없기 때문에 더욱 그렇다. 다행히도 Mercurial의 서버는 SubVersion이나 CVS같은 중앙 집중식이 아니기 때문에 딱히 서버 셋팅에 공들일 필요 없이 그냥 상시 구동되는 PC하나에 Mercurial 서버를 열어두는 것 뿐이며, Python 기반의 코드 덕분에 어지간한 웹 호스팅 위에서도 문제 없이 구동이 된다. 개인 홈페이지를 올려두고 있는 호스팅 업체인 Cafe24에 계정을 하나 더 만들어서 서버를 설정해 보았는데, 문제 없이 깔끔하게 구동되어서 만족하고 있다. 다만 몇 가지 설정해 두어야 할 사항들이 있는데, 비단 Cafe24 뿐 아니라 일반적인 웹 호스팅에서 Mercurial을 서버로 구동하고자 한다면 대부분 해당될 사항들이기는 하다.
* Prerequisites
- 당연히, 호스팅 계정.
- 32Bit Linux : 64bit Linux에 설치되는 Python 모듈 일부에서 문제가 있다는 이야기가 있으니 안전하게.
- Python : 2.3 이상이면 되는 것 같지만 되도록이면 2.5 이상으로 업그레이드를 요청하는 것이 좋다.
- SSH : Mercurial은 http로도 동기화 할 수 있지만 일단은 SSH를 사용.
- 이건 말할 필요도 없지만 ssh나 telnet으로 접속 가능해야 한다.
* 설치하기
Mercurial을 설치할 수 있는 방법은 크게 두 가지인데, 한 가지는 전역으로 설치하는 방법이고 두 번째는 각 유저별로 설치하는 방법이다. 호스팅으로 제공받은 계정의 경우 전역 설치는 불가능하기 때문에 포기하고, 할당받은 유저에 대해 설치하는 것으로 한다. 먼저 최신 버전을
을 통해 다운로드받고 적절한 위치에 압축을 풀어 둔다. 윈도우로 다운받아 ftp로 재전송하는 경우 정상적으로 압축을 해제할 수 없는 경우가 가끔 있으니 원격 Shell에서 wget으로 바로 다운로드받는 편이 낫다. 다음 방법을 통해 압축을 풀고 설치를 마치도록 하자.
[ver]은 다운로드받은 최신 버전에 따라 달라진다
$ tar xvzf mercurial-[ver].tar.gz
$ cd mercurial-[ver]
$ make install-home
설치가 완료되면 bin / lib 디렉토리가 생긴 것을 볼 수 있다. 64bit 사용자의 경우는 lib대신 lib64 디렉토리가 생긴다.
다음은 Repositor들이 저장될 위치를 정하는 것인데, HOME 바로 아래에 적절하게 디렉토리 하나를 생성해 두면 된다. 현재 서버는 HOME/hgrepo로 지정해 두었다.
* 경로 설정하기
설치를 마치고 나서도 바로 Mercurial을 실행할 수가 없다. 경로가 정상적으로 지정되지 않았기 때문인데, 기본적으로는 .bashrc를 통해 사용자별로 기동할 때 경로를 지정하도록 해 두면 되지만 cafe24에서는 이상하게 이 방법이 동작하지 않아서 조금 무식하게 선택한 것이 .bash_profile을 직접 수정하는 것. .bash_profile을 연 후에 아래와 같이 경로를 추가해 주면 된다.
# .bash_profile
# Get the aliases and functions
if [ -f /etc/userbashrc ]; then
. /etc/userbashrc
fi
# User specific environment and startup programs
#LANG=ko_KR.eucKR
#export LANG
JAVA_HOME=/usr/local/jdk
export JAVA_HOME
PATH=/home/bin:/bin:$JAVA_HOME/bin[....]:${HOME}/bin
PYTHONPATH=${HOME}/lib64/python
export PYTHONPATH
export PATH
unset USERNAME
굵게 표시한 부분만 경로 설정을 위해 추가한 부분이다.
이걸로 끝이 아니라, ssh로 서버를 동기화할 때 모듈을 찾지 못하는 문제또한 해결해야 한다. 원래는 ssh 구동시 환경설정만 맞추어두면 되는데 어느 쪽에 문제가 있는지 도통 동작하질 않아서 Mercurial 구동부 중 일부를 직접 수정하였다. bin/hg를 연 후 다음과 같이 경로를 맞추어 준다.
#!/home/bin/python
#
# mercurial - scalable distributed SCM
#
# Copyright 2005-2007 Matt Mackall <mpm@selenic.com>
#
# This software may be used and distributed according to the terms
# of the GNU General Public License, incorporated herein by reference.
import sys
sys.path.append('/home/hosting_users/hgsvr/lib64/python')
sys.path.append('/home/hosting_users/hgsvr/bin')
# enable importing on demand to reduce startup time
from mercurial import demandimport; demandimport.enable()
import mercurial.util
import mercurial.dispatch
for fp in (sys.stdin, sys.stdout, sys.stderr):
mercurial.util.set_binary(fp)
mercurial.dispatch.run()
단순히 시스템 경로에 Mercurial의 설치 경로를 지정해 주기만 하면 정상적으로 동작함을 알 수 있다.
* 정상적인 동작 확인하기
총 세 가지 방법으로 동작을 확인한다.
1. Remote shell에서 [hg debuginstall] 실행 : 설치시에 문제가 없는지 확인하고 표시해 준다. 정상적으로 설치되었다면 다음과 같은 메시지를 볼 수 있다.
Checking encoding (ISO-8859-1)...
Checking extensions...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
No problems detected
처음 설치하고 바로 실행하면 username이 없다는 에러 메시지를 받을 텐데, .hgrc 파일이 생성되어 있지 않기 때문이다. 서버에 .hgrc를 전역으로 생성해버리면 동기화하는 모든 프로젝트의 유저명이 하나로 통일되기 때문에 신경쓰지 말고, 각 Repository가 각각의 .hgrc를 통해 설정하도록 놓아두면 된다.
2. plink로 [hg debuginstall] 실행 : 대부분의 클라이언트가 윈도우 환경에서 tortoisehg같은 GUI frontend를 쓰는데, 이 때 ssh 접속을 위해 이용하는 plink를 통해 hg가 정상적으로 구동되는지 확인한다. Plink를 다운로드받고
Plink.exe -ssh -2 -l [ID] -pw [PASS] [SERVERNAME] "hg debuginstall"
와 같이 실행한 뒤 로그메시지를 살펴보면 정상적으로 설정된 경우 위와 동일한 메시지를 출력하는 것을 볼 수 있다.
3. 실제 동기화 실행
실제로 동기화가 이루어지는지 마지막으로 확인해 본다. 로컬에서 사용하는 Repository가 있을 경우 바로 Clone을 실행해서 대상을 서버로 지정하면 되고, 그렇지 않은 경우 서버에서 [hg init]으로 Repository를 만들거나 혹은 로컬에서 만들고 서버를 대상으로 Clone해도 좋다. 어쨌든 Clone이 끝난 다음 로컬에서 작업 내용을 한 번 변경하고 Commit한 후에, 서버 쪽으로 Push하고 이력을 확인하거나 로컬 쪽 Repository를 지우고 서버에서 끌어와서 확인해도 좋다.
4. 번외 : 웹 페이지 설정
Mercurial은 웹에서 변경사항을 볼 수 있도록 하는 방법 몇 가지를 제공하는 데, 그 중 여러 Repository를 관리할 수 있는 hgwebdir.cgi를 설정해 두면 간편하게 브라우저로 접근이 가능하다. 먼저 hgwebdir.cgi를 www디렉토리 아래로 옮기고,
chmod a+x hgwebdir.cgi
로 권한을 변경한다. 그 후 hgwebdir.cgi 파일을 열고 Mercurial이 설치된 부분을 찾는 경로를 현재 위치에 맞게 수정한다. 그리고 나서 같은 위치에 hgweb.config 파일을 생성한 후
[collections]
/home/username/repo = /home/username/repo
를 자신의 경로에 맞추어 기입해 주면 된다. 나머지 설정은 기호에 맞추어 문서를 참조하여 변경하면 된다.
설치와 관련한 다른 문제들은
와 나머지 위키 페이지의 기술을 참조하면 된다.
PhysX enabled : Geforce 9800GTX+
IT 2008. 6. 21. 00:46지독한 경쟁의 시간이 돌아왔다. G80 기반의 GeForce 8 시리즈 이후 절대적인 경쟁우위에 서 있었다고 해도 틀린 말이 아닐 정도였던 NVIDIA의 위치가 NVIDIA-ATI(AMD) 양 사의 신제품 출시에 맞추어 변화할 조짐이 보이고 있기 때문. 새로이 발표된 NVIDIA의 GTX 2xx 시리즈의 성능에 대한 이야기가 먼저 나온 이후, ATI의 HD 4xxx시리즈의 인상적인 가격대 성능비에 나름 위기의식을 느낀 탓인지 NVIDIA에서는 전면적인 라인업을 급박하게 재정비하기 시작했다. 새로이 나오는 제품인 260/280을 상위라인에 배치하고 가격대를 조정하는 한편, 기존 라인업에 있던 제품들의 대폭적인 가격조정을 시작한 것.
9 시리즈의 상위에 있던 GeForce 9800GTX의 가격이 199$로 조정됨과 동시에, 그 자리를 메꾸는 것이 229$의 가격으로 책정되어 발표된 GeForce 9800GTX+이다. 기존의 GeForce 9800GTX에 비해 향상된 클럭을 통해 속도 향상을 도모함과 동시에, 얼마 전에 인수한 PhysX의 GPU 가속 지원 및 CUDA를 이용한 GPU Computing 등을 전면에 내세워 ATI에 대항하고자 하고 있다. PhysX의 GPU 가속 지원은 PhysX의 인수 시기를 생각해보면 의외로 빨리 이루어진 편인데, 지원하는 타이틀이나 성능에 대해서는 짚고 넘어가 볼 필요가 있겠다.
생긴건 달라진게 하나도 없다.
9800GTX+의 발매에 맞추어 준비된 타이틀은 UE3 기반의 UT3의 PhysX 맵 팩으로, PhysX 가속이 지원되는 3개의 맵이 제공되어 있다. 기존의 Heat Ray의 PhysX 버전과 함께 새로이 제작된 LightHouse/Tornado가 제공된다.
GeForce PhysX 지원이 활성화되어 있는 것을 확인할 수 있다.
PhysX 지원 드라이버와 맵팩까지 모두 설치한 후 UT3를 실행하면 하드웨어 가속 옵션을 설정할 수 있게 된다.
이런 옵션을 선택할 수 있으면 왠지 뿌듯한 느낌이 든다.
PhysX의 하드웨어 가속으로 얻을 수 있는 장점을 생각해 본다면 물리효과를 사용했을때 높은 프레임레이트를 얻을 수 있거나, 혹은 반대로 다양한 물리효과를 사용할 수 있다는 것이 될 텐데 추가된 맵들에는 많은 오브젝트를 추가하거나 기존 오브젝트에 물리효과를 추가하여 물리효과의 하드웨어 가속이 어떤 느낌을 주는지를 잘 보여주고 있다. 이러한 효과는 단순히 눈요기에 그치는 것이 아니라 게임플레이에 직접적인 영향을 미치기도 하는데, 단순히 벽이나 바닥을 파괴하여 새로운 진입 루트를 개척하는데서부터 특정한 오브젝트를 이용해 진로를 차단하거나 적을 공격하는 데 까지 활용할 수 있다. 아래에 소개할 영상 중 Tornado 맵에서는 특정 진로로 이동하는 토네이도를 볼 수 있는데, 이것에 휘말리게 되면 날아가게 되는 것은 물론이거니와 여기에 휩쓸린 물체들이 떨어질때 부딪히면서 충격을 받기도 하고, 영향권 내에 있을 경우 탄환형 무기(로켓 런처와 같은)의 경우 바람에 의해 진행경로가 달라지는 경우를 확인할 수도 있다.
PhysX를 지원하지 않는 기존의 HeatRay 맵
PhysX 가속을 지원하는 HeatRay 맵
LightHouse 맵. 지형지물 파괴를 확인할 수 있다.
Tornado 맵.
영상에서 확인할 수 있듯이 다채로운 물리효과가 적용된 것을 확인할 수 있다. 이러한 효과들은 사실 PhysX가 예전에 발매했던 PPU의 데모에서도 볼 수 있었던 것들이지만, 구입한 유저나 지원하는 게임수가 형편없이 적었던 것에 비교해 볼때 어지간한 GeForce 모델에서는 지원된다는 점과 앞으로 꽤 기대되는 타이틀들이 이러한 가속을 지원한다는 점에서 PPU보다 훨씬 나은 위치에 있다. 현재 GeForce 9800GTX+와 그 상위 모델인 GTX 260/280의 경우 PhysX 지원이 바로 가능하고, 나머지 Geforece 8/9 시리즈의 GPU 물리 가속 지원 드라이버도 7월 중으로 릴리즈 될 예정이니 손쉽게 체험이 가능하다. 공식적으로 PhysX의 하드웨어 가속을 지원하겠다고 밝힌 타이틀들은 현재 Mstar / Mirrors Edge / Empire : Total war / Backbreaker 외 다수가 있다.
0123
Backbreaker의 영상 (개발중)
추후 다시 한번 다룰 내용이지만, NVIDIA는 이번 세대의 GPU에서부터 개발 방향을 Visualization 이상의 용도로 사용할 수 있도록 하는데 주안점을 두고 있는 듯 하다. 일단 PhysX를 인수하고 GeForce에 통합한 것은 어느 정도 사람들이 기대하는 정도의 성과를 얻은 듯 하며, 남은 것은 PhysX가 처음 세상에 나타났을 때 부터 지속적으로 제기된 문제인 지원 타이틀의 확대를 어떤 식으로 꾀하느냐가 될 것이다. PPU에 비교해본다면 GeForce는 이미 매우 넓은 저변을 가지고 있으니만치 상대적으로 더 나은 결과를 얻을 가능성이 높지 않을까 한다.
9800GTX+라는 티나는 이름이나 급격한 가격대의 조절과 같은 외부 환경 때문에 단순한 우려먹기로 비칠 소지가 다분한 것이 이번 세대의 라인업이지만, GPU의 범용화를 위한 첫발이라고 볼 때는 충분히 주목할 만한 가치가 있다. 229$와 경쟁사 모델의 가격차이를 PhysX와 CUDA같은 기능들이 메울 수 있는 가치가 있다고 생각하는지는 소비자 자신이 판단해야 할 문제겠지만.