As far as I know the Android emulator does not provide simulation of hardware sensors. I spent plenty of time searching for options to throw hardware sensor events to the emulator in Eclipse and the Android developers site. I came accross in the Android developer's guide where it describes means to send events to the emulator, but the explanation was so brief I had no idea what to do. Also, I'm not sure if that was the part which describes what I want to acheive. In other words, it isn't so clear in any of the reference I haved looked about how you can simulate the hardware sensors in the emulator. For this reason, if you are developing an Android application which operates based on the orientation(or acceleration) of the device, you might be having trouble debugging your app.
So be it... I was so sure there must be some way to do it. After googling a while, I was led to openintents' google code project page. There I was able to find a sub-project called "Sensor Simulator". It was exactly the thing I was looking for, and it served its purpose right. I was able to simulate hardware sensor and send events to the Android emulator using it. The wiki page in the goole code project site seems to be outdated and you must make modifications to the resulting code of the instructions listed there in order to get it work. So I thought I should share the information about how I managed to make it work along with my understanding of how the thing works since the document on the wiki page delivers partly false instructions.
The distributed zip file of Sensor Simulator contains the hardware sensor simulator server, client, and an external jar library file. The hardware sensor simulator server is where you can change the orientation of the device in a GUI environment and generates the sensory input values. The client is an Android package that must be installed in the emulator(the Android device) which will read generated sensory input from the hardware sensor simulator server. The external jar library file consists of classes that provide an abstract layer to the SensorManager for reading sensory input values generated from the sensor simulator client which was read from the server.
To reduce confusion for future readers, I might as well aknowledge the version I downloaded and worked on for the people who might refer to this post later on when there is an updated version available and this post becomes invalid. But it's already been a while since the last update was done to the distributed zip file which was in July 2009. Everything is working quite well, and I see no reason for future updates in the near future unless there is a major change in the Android class architecture that relates to hardware sensors. Anyway, The version I worked with is 1.0.0-beta1 on Android SDK 2.0.
And the distribution file I downloaded can be found here.
The following instructions are based on the project's wiki page, modified and added instructions and their description is based on my personal experience.
1. Installing the client in the Android emulator
Install SensorSimulatorSettings.apk in the bin directory to the Android emulator. I'm pretty sure there is a way to install Android packages from the DDMS perspective in Eclipse, but I personally prefer using the adb tool from the command prompt.
adb install SensorSimulatorSettings.apk
You might have to add options to adb if you have multiple devices connected or emulators running.
2. Execute the server and configure the cilent to make a connection
Execute sensorsimulator.jar in the bin directory which is the executable jar file of the server. The following is a screenshot of the server application. (The appearance of the server app may look weird as the layout is all messed up as the textboxes appear smaller than they are supposed to. You can correct this by resizing the window)
<An instance of the Sensor Simulator Server Application>
Scroll up the coresponding textbox which is marked with a red rectangle in the above picture in the server application. As you scroll up, you may see the possible IPs that the client can use to identify and connect to the server. Do not quit the server application.
Now start the Sensor Simulator client which you installed in your Android emulator by installing the sensorsimulatorsettings.apk to your emulator. The client Android app will look like the screenshot on the right.
Enter one of the possible IPs that was shown in the server application in the IP address field. If you did not make any modifications to the port number from the server application, you can use the default value 8010 which is the default value for the port number being used for the server application.
Then go to the Testing tab so you will see something like the screenshot on the left. Press the connect button and select the sensors you will like to retreive infromation from. The order of pressing the connect button and selecting the sensors does not seem to matter. Since the purpose of this post is demonstrating how to simulate hardware sensors, I will be enabling the orientation sensor only.
Now play around with the server. You can change the orientation of the device by clicking and dragging the mobile device looking like figure or by using slide bars. See if the values change in the client where it is marked with a red rectangle in the left picture.
If you can see the values change in the Android emulator by playing around with the server application, it means that the Android emulator is successfully retrieving the simulated hardware sensory input values.
3. Modifying the code to use simulated hardware sensory input
A portion of your application will have something similar to the following code if you were developing an Android application that reads hardware sensor values. The highlighted part is subject to change later on. This code is not tested on an actual device, so I will not guarantee it will work. But I have checked it is buildable. Also, keep in mind that this code contains a lot of deprecated API which I did not bother to make changes. I was referring to an outdated book published in the days of Android SDK 1.5 to make this quick example.
Here are the changes you must make to use the sensory values from the Sensor Simulator to simulate hardware sensors.
The type of mSensorManager must be changed to SensorManagerSimulator. Create a SensorManagerSimulator instance by using the static method SensorManagerSimulator.getSystemServices(Context, String).
Connect SensorManager to the simulator by calling static method SensorManagerSimulator.connectSimulator() before registering SensorListener.
The resulting code may look like the following. The lines highlighted in pink are the newly added lines and the yellow highlighted lines are lines that are modified.
There isn't much to modify after all. Here is how the instructions here are different from the project wiki page.
The instruction where it says to retrieve the content resolver and create an Intent instance to start an Activity with it is left out because it seems to be unnecessary code. It explains as if it is a very important step, but it causes syntax errors and I have no idea how to interpret in order to make proper modifications. And it still works without those lines.
The step where unregistering the SensorListener before registering a new SensorListener from the wiki page is also left out here because I see no reason to do that in my simple example. Maybe that step might be required for some special cases, but I don't think that should happen too often.
The way how the SensorManagerSimulator instance is created different. SensorManagerSimulator constructor is now private and the instance can be only created via the static method getSystemService().
4. The result
<You can see the simulated hardware sensory input value displayed in the TextView>
if your application stops unexpectedly, review the logs from logcat. See if you find anything similar to the following phrase from your log,
"Permission denied (maybe missing INTERNET permission)."
If this is the case, add the following line right before </manifest> at the end of AndroidManifest.xml.
약속했던대로 오늘은 영화 아바타를 보고 3D (3차원) 영상기술에 대해서 들었던 생각에 대해서 잠시 써보겠습니다.
3차원 영상기술이 새로 나온 기술은 아니죠. 오래 전부터 존재 했지만 제작비가 비싸서 그랬는지, 배급및 극장 시설 교체에 어려움이 있어서 그랬는지 많이 존재 하지는 않았습니다. 예전에 디스플레이 업계에 몸담고 있었던 적이 있어서 3차원 영상 기술에 대해서 조금 더 알게 되었는데, 미국에서는 이미 2006년쯤 부터 3D 영화가 많이 나오기 시작했고, 상영관도 많이 늘어났다고 합니다. 그래서 가전업계에서도 3D 기기 개발에 본격적으로 착수하기 시작했고, 조만간 대중앞에 시판될 것으로 보입니다. 예전에 컴퓨터용으로 3D 게임을 안경을 끼고 3차원으로 볼 수 있는 기기와 유사한 기술들은 많았는데, 이제 TV와 같이 가전제품으로 우리 생활 깊숙히 파고들 듯 합니다. 기대가 됩니다...
하지만 요근래에 개발되고 있는 3D TV나 3D 영화 상영관에서 관람할 수 있는 3D는 옛날에(80~90년대)에 보던 3D와는 차이가 좀 있습니다. 안경을 끼고 보느냐, 안끼고 보느냐, 끼는 안경은 passive 방식이냐, active 방식이냐의 차이가 아니라, 실제로 보이는 현실감의 차이라고나 할까요?
옛날에 디즈니 월드나 대전 엑스포에서 제가 봤던 3D영상은 정말 현실적이었습니다. 그렇다고 해서 아바타의 3D영상이 현실감이 없었다는 말은 아닙니다. 무슨 말이냐면, 디즈니월드나 대전 엑스포에서 봤던 3D 영상에서는 무엇이든지 화면에서 튀어나와 보였습니다. 돌이 날라오면 정말 바로 코 앞에서 손으로 잡을 수 있을것 같았다는 말이죠. 하지만 요새 3D TV나 3D 극장에서 볼 수 있는 3D는 푹 들어가 있습니다. 모든것이 푹 들어가 있는 것이 아니라, 화면을 기준으로 그 안쪽이 깊게 파여 있어서 그 안쪽에서만 원근이 느껴진다는 것입니다. 그러니까 다음 그림을 보시면 더 이해가 잘 가실것입니다.
<주된 영상이 상댇적으로 화면 앞쪽으로 나와있다는 느낌이 들었던 예전 방식과 주된 영상이 화면 뒤에 있다는 느낌이 드는 요즘 방식>
3차원 영상의 원리는 상당히 어렵지만, 본질적으로는 우리의 두 눈이 한 물체에 대해서 서로 다른 각도에서 보고 있다는 점을 이용해서 재현되는 것으로 알고 있습니다. 그래서 우리의 두 눈은 서로 다른 영상을 봐야 하는데, 가장 쉽고 값싼 방식이 바로 영화 아바타에서 이용한 편광 필름을 이용한 것입니다. 그래서 안경 없이 영화를 보면 뭔가 이상합니다. 상이 두개 맺힌듯한 영상을 보게 됩니다. 가까이 있는 물체는 양쪽 두눈과 이루는 각도가 크기 때문에 넓은 간격으로 상이 맺혀있는듯 보이고, 멀리 있는 물체는 양쪽 두눈과 이루는 각도가 작기 때문에 좁은 간격으로 상이 맺혀 있는듯 보이게 됩니다. 다시한번 그림을 통해서 제가 설명하고자 하는 것을 말씀드리겠습니다.
그러니까 왼쪽 그림과 같이 가까이 있는 물체 A와 조금 더 멀리 있는 물체 B 그리고 아주 멀리 있는 물체 C가 있다고 칩시다. 일단 가까운 곳에 있는 물체는 크게 보이고, 멀리 있는 곳의 물체는 작게 보이는 것은 당연한 것이고, 이미 2D 그림에서 원근을 그런식으로 자연스럽게 표현된다는 사실은 모두들 잘 알고 계실것입니다. 그래서 크기에 의한 원근 효과는 이미 2D 영상에서도 우리가 모르게 자연스럽게 주어졌다고 해도 무방할것이고요... C 가 아주 멀리 있는 물체라서 양쪽 눈으로 봐도 별차이가 없다고 가정했을때, A와 B가 상대적으로 더 가까이 있게 느껴지게 하기 위해서는 각 눈에서는 양쪽 눈으로 서로 다른 각도에서 본 물체의 상이 보여야 한다는 것입니다. A와 B가 양쪽 눈에서 각각 어떻게 상이 맺히는지의 기준은 C를 바라보고 있는 시선(초점)을 기준으로 만들어지게 되어있고, 두 물체의 상이 이중으로 맺혀질때 그 간격은 가까이 있는냐 멀리 있느냐의 거리에 따라 그 간격도 결정지어집니다.
이렇게 상이 이중으로 맺히는 영상을 만든 후에 양쪽 눈이 각각의 눈에 해당하는 상이 보이도록 해주면 영상이 3차원으로 보이게 됩니다. 서로 다른 각도에서 보이는 물체의 상은 약간 다를텐데 우리가 아무런 이상 없이 자연스럽게 사물을 인지할 수 있는 이유는 우리의 뇌 속에서 양쪽 눈으로 부터 보이는 영상을 자연스럽게 처리해 주기 때문인 것으로 알고 있습니다. 이것이 제가 대충 이해하고 있는 3D 영상 재현의 방법입니다. 이제 왜 3차원 영상을 관람할때는 영화관에서 제일 좋은 중앙자리가 좋은지 이해가 가나요?
위에서 설명한 3차원 영상의 재현 원리를 바탕으로 볼때 아마도 주된 영상이 앞으로 튀어나와 보이게 하려면 각 눈에 보이는 영상의 상의 간격이 많이 벌어져있어야 할것이라는 것이 제 추측입니다. 실제로 옛날에 보던 3차원 영상에 비해 이중상의 간격이 많이 좁아진 것을 느낄 수 있었습니다. 만약 이중상의 거리를 넓히면 비록 손에 닿을듯한 매우 현실감 넘치는 3차원 영상을 관람할 수 있겠지만, 영상을 정면으로 바라보고 있지 않으면 영상으로 보이는 것이 현실세계였다면 실제로 봐야 하는 두 눈의 시선 방향과 영상에서 제공하는 시선의 방향의 오차가 커져 3차원 영상이 제대로 재현되지 않고 여전히 이중상으로 보이기도 할 것입니다. 이렇게 된 경우에는 양쪽 눈에서 보이는 영상의 부자연스러움을 자연스럽게 처리해주는 일이 뇌에서 하기 때문에 뇌에 과부하가 걸리고, 기존에 우리가 눈으로 세상을 인지하고 있던 것과 다른 영상들이 두 눈으로 들어오기 때문에 눈이 피로하고 멀미가 나는 것이라고 생각합니다.
그래서 제가 내린 결론은... 3차원 입체 영화가 주된 영상이 화면 앞으로 튀어나와 보이던 방식에서 화면 뒤로 보이게 하는 방식으로 바뀌게 된 가장 큰 이유는 다음과 같습니다.
영상이 현실세계라고 가정했을때 나타나는 우리의 시선의 방향과, 실제 영상에서 가정하고 있는 시선의 방향과의 오차를 줄이기 위해서
오차를 줄임으로써 3차원 영상을 시청하는 관람객들의 눈의 피로를 덜어주고 멀미가 날 가능성을 덜어주기 위해
오차의 크기를 줄임으로써 영상을 보는 각도에서 발생하는 오차도 줄임으로써 대체로 영화관의 좌석 어디에서나도 비슷한 3차원 영상을 경험할 수 있게 하기 위해
오차의 크기를 줄임으로써 각각의 사람들의 눈이 벌어진 거리에 의해 발생할 수 있는 오차도 줄임으로써 전반적으로 많은 연령대 또는 다른 얼굴 형태의 사람들에게 비슷한 3차원 영상을 경험할 수 있게 하기 위해
입니다...
또한 요새는 디지털로 영화를 촬영하고 상영하기 때문에 영상의 화질이 더욱 좋아져서 3차원 효과는 더욱 정확하게 재현된다는 점도 잊지 말아야 할 것입니다.
따라서, 요즘 3차원 영상의 동향은 3차원의 효과는 예전에 비해 줄이는 대신에 더욱 많은 사람에게 비슷한 경험을 할 수 있도록 하고, 고해상도의 디지털 영상을 활용함으로써 선명한 3차원 영상을 재현하는 것이 동향이라고 할 수 있을것 같습니다...
결론에 이르기 위해서 3차원 영상의 재현 원리 설명이 불가피해져서 글이 길어졌네요...
이 글은 전문적인 지식이 없는 상태에서 주변에서 들은 것과 개인의 과학적 상식을 바탕으로 쓰여졌음을 명시하오니, 이 글을 참고하라 경우에는 위험을 감수하시기 바랍니다(Do it at your own risk). 사실과 다른 부분은 댓글로 지적해 주시면 모두의 지식 공유에 큰 도움이 될것 같습니다.
오늘 설 연휴 마지막날을 그냥 보내는게 너무 아쉬운 딱히 할일이 없는 사람 몇 만나서 놀았습니다... 모인 장소가 미금역에 있는 2001 아웃렛 건물에 있는 크리스피 크림이었는데... 가장 늦게 오는 한사람을 기다리면서 무엇을 마시기로 했습니다. 새뱃돈을 타온 동생이 사준다기에 저는 메뉴판에 있는 유기농 녹차를 보고 "Organic Green Tea"를 마시겠다고 재수없게 말했습니다... 그랬더니 그 동생이 제 바로 앞에 있는 우리나라에서 흔히 볼 수 없는 대따 큰 Arizona Green Tea를 마셔보는건 어떻겠냐고 물어봤습니다... 유기농 녹차를 마시겠다고 안하고 굳이 Organic Green Tea를 마시겠다고 해서 재수없게 느껴져서 그랬을지도 모르는데(그 동생은 제가 영어 하는것을 싫어합니다), 저는 오히려 그 Arizona Green Tea가 아주 반가웠습니다 !!!
<반갑다 Arizona Green Tea>
아~ 얼마만에 보는 Arizona Green Tea인가??? 우리나라에서 종종 보기는 했지만, 딱히 마실 기회는 없었는데, 저는 이 캔을 보고 무지 반가웠습니다... 그래서 저는 외쳤죠 !!!
그래 !!! 좋은 생각이야 !!!
그러더니 갑자기 그 동생이 이렇게 말하는 것이었습니다...
이것을 셋이서 나눠 먹을까???
그래서 저는 단호하게 말했습니다...
컵이 필요하기 때문에 안돼!!!
그리고 저는 갑자기 가게에 손님들이 많아지는 것을 보고 우리의 자리를 사수하러 자리에 갔습니다... 그런데 동생이 플라스틱 컵을 3개를 가지고 왔습니다...
<셋이서 Arizona Green Tea 한캔을 나눠먹어야 했던 슬픈 현실>
혼자 마시려고 했는데, 결국 셋이서 저것을 나눠 먹었습니다...
중요한 것은 셋이서 한캔을 나눠 먹었다는 사실이 아니고... 바로 그 어처구니 없는가격입니다... 아래 사진이 이해가 안되시는 분들은 여기를 참고하세요
<어처구니 없는>
미국에서는 저 큰 캔 하나에 $0.99입니다... 그러니까 요새 환율로 따지면 1,200원 정도나 할까요??? 그런데 크리스피 크림에서는 저것을 무려 3,500원에 팔고 있었습니다... 생각해보면 호프집이나 카페에서 콜라를 주문하면, 저것보다 용량이 훨씬 적은 캔이나 병이 나오면서 4,000~6,000씩 받아먹는 것을 감안하면 양호한 편이라고 할 수 있겠습니다만, 그래도 모두 다 똑같이 너무하다고 생각합니다...
제가 싸구려 음료수 Arizona Green Tea를 저렇게 비싼 돈을 주고 사서 마셔야 하는 현실에 대해서 한탄하자 같이 있던 형이 저보고 미국가서 사오라고 했습니다... 물론 수입해 오면서 들어가는 운송비를 따져보라고 한 말이겠지만... 그래도...
형 그래도 그건 아니잖아요 !!!
우리나라에서 가공되는 콜라 같은 경우도 사실 저런 곳에서 사먹게 되면 엄청 비싸게 사먹어야 하는 현실을 보면, 단순히 운송비 때문에 가격이 비싼것 같지는 않습니다... 그렇다면 희소성 또는 자리값 때문에 그렇다는 얘긴데... 그래도 너무한것 같습니다...
이런저런 얘기를 하다가 차라리 제조해 먹는게 낫겠다는 말이 나왔고, 분당 그린티도 나왔으면 좋겠다는 말로 마무리 되었습니다...
수요가 많아지면 운송 단가도 떨어질텐데, 조금이라도 저 음료수를 싸게 먹기 위해서는 우리 모두 Arizona Green Tea를 마셨으면 좋겠습니다... 달달하니 맛이 있으니 많이들 애용 바랍니다...
어릴때 Halloween 만 되면 변장한채 Jack-O'-Lantern 모양의 플라스틱 바구니를 한손에 들고 이집 저집에 "Trick or Treat~"하러 다니면서 많이 get 했던 사탕입니다. 이 사탕도 참 싸구려 축에 속하는 사탕이었던것 같은데, 이것보다 더 싸구려 주는 집도 있었습니다... 그런집은 친구들과 정보를 공유하고 pass 했을것이라고 생각했다면, 당신은 아마추어...
원래 halloween은 최대한 사탕을 끌어모으고, 그것으로 하루의 성과를 평가하는 날이기 때문에, 닥치는대로 문 두들기고 "Trick or Treat"해야 합니다. 그리고 친구들의 취향이 다 다르기 때문에, 사탕이 많으면 많을수록, 종류도 많으면 많을수록, 물물 교환의 기회도 많아지기도 했으니 그날은 절대로 Pass를 외치면 안됩니다. 그리고 부모님들도 간혹 제 사탕바구니에서 사탕을 먹기도 하셨을겁니다... <- 이제는 어머니께서 블로깅 하시게 되면서 제 블로그를 자주 방문 하시기 때문에 확실히 기억나지 않는 옛 일에 대해서 쉽게 단정지어 말할 수 없습니다.
어쩄든, 그날은 Pass 금물...
뭐 그건 그렇고, 저 사탕을 가장 맛있게 먹는 방법을 알려드리겠습니다... 카라멜과 같은 것이기 때문에 입안에서 사람의 체온으로 살짝 녹인 뒤에 혀로 쪼물딱 거리면 모양이 변합니다. 혀로 저 Tootsie Roll을 입 천장에 붙이고, 혀로 계속 낼름 낼름 핥습니다.
저만의 방법이라고 자부하고 있는데, 이 방법으로 먹으면 Tootsie Roll의 농축된 초코렛 맛을 혀로 최대한 맛보실 수 있습니다.
다음에 Costco에 가게 되면 한번 찾아봐야겠습니다...
참고로... 제가 어릴때는 Halloween 때 이 phrase가 유행이었는데...
Trick or Treat !!! Trick or Treat !!! Give me something good to eat~ If you don't, I don't care, I'll pull down your underwear !!!
제가 전생에 무슨 죄를 지었길래, 20대의 마지막에서 두번째 크리스마스날 쓸쓸하게 아무도 듣지 않는 친구의 인터넷 방송을 듣고 있습니다... 일명 dj cos와 함께하는 깜장촌(아마도 Blacksburg를 의미하는것 같네요) 사람들의 사는 이야기 방송...
<이건 자기 방송 배너>
방송 이름도 참 촌스럽지 않습니까??? 배너도 촌스럽고...
아... 크리스마스 당일 오후에... 이런 !!!
ㅜ.ㅜ
방송 듣는 사람은 별로 없음에도 불구하고 꽤나 프로페셔널하게 방송합니다. 사연도 받고, 1주일에 3일 정해서 정기적으로 정해진 시간부터 자기 졸릴때까지 방송합니다.
참 존경스러운 친구입니다. 누군가를 위해서 특별히 하는 방송도 아니고, 불특정 다수를 겨냥한, 소수의 청취자들을 타겟으로 하는 방송을 굉장히 열심히 합니다. 청취자가 늘 별로 없어 저라도 들어달라고 자꾸 조르는 것이 너무 안타까워서(사실은 귀찮아서) 청취자들을 늘려주고자 합니다. 이 기회를 통해서 제 친구는 제 블로그의 광고 효과를 눈여겨보겠다고 하네요... 쳇... 전 이미 1년이 약간 넘는 동안 에드센스로 $30 약간 넘는 돈을 벌었는데...
ㅋㅋㅋ
음... 어쨌든, 홍보나 해주렵니다...
"dj cos와 함께 하는 깜장촌 사람들의 사는 이야기" 방송 시간표는 다음과 같습니다...
컴퓨터 소사이어티 미팅에 가면, 젊은 프로그래밍 매니져가 다수의 그저그런 인력보다는 소수의 뛰어난 인력을 선호한다고 단언하는 것을 종종 들을 수 있다. 우리 모두 그렇다. 하지만 이 주장은 크고 복잡한 문제에 대해서는 해결책을 제시해줄 수 없다.
프로그래밍 매니져들은 개발자 각각의 생산성에 많은 차이가 있음을 예전부터 잘 알고 있었다. 하지만 실제로 실험적으로 측정된 생산성에 대한 각자의 결과는 놀랍다. Sackman, Erikson, 그리고 Grant에 의해 시행된 실험의 결과에 따르면 개발자들간의 퍼포먼스 차이는 최대 10배 까지 차이가 났으며, 일의 효율에 있어서는 5배까지 차이가 났다고 한다. 그리고 연봉은 퍼포먼스와 효율과 큰 연관성음 없었다고 한다(하지만 일반적으로 그럴 것이라고 생가하지는 않는다).
앞서 말했지만, 프로젝트의 비용의 대다수는 커뮤니케이션과, 잘못된 커뮤니케이션이 이루어짐에 따라 발생한 문제를 해결하는데서 발생한다. 이것 역시 왜 소수의 뛰어난 사람을 프로그래밍 매니져들이 선호하는지에 대한 증거가 될 수 있다. 그래서 결론은 간단하다. 200명이 투입된 프로젝트에서 25명의 매니져의 직분에 있는 사람만이 경쟁력이 있고, 실력이 있을만큼 경험이 풍부하다면, 나머지 175명은 해고하는 것이다.
하지만 이 결론을 너무 성급히 내린것은 아닌지 생각해 보자. 우선 25명은 이상적인 소규모 그룹이라고 하기에는 너무 많은 인원이다. 조사에 따르면 일반적으로 프로젝트 내에서의 소그룹은 10명 이상이 되지 않는 것이 좋다고 한다. 25명의 인원은 최소한 2단계의 관리 체계가 필요로 하여 5명의 중간 단계 매니져들이 필요로 하게 된다. 더욱더 나아가 200명의 인력은 아주 큰 프로젝트를 하기에도 너무나 적은 인원이다. OS/360의 예를 살펴보면, 가장 많은 인력이 투입된 시점에서는 프로그래머, 서기, 비서, 매니져, 개발지원 등의 여러가지 일이 분담된 1000명 이상의 인력이 개발에 참여하고 있었다. 1963년 부터 1966년까지 아마도 5000 man-years가 개발 과정에 투입되었던것 같다. 200명의 인력으로는 25년이 걸렸을 일이다. 이것이 작지만 뛰어난 그룹의 문제점이다. 아주 큰 프로젝트를 진행하기 위해서는 터무니 없이 작은 인력이라는 것이다.
이것이 딜레마다. 매니저는 효율성과 시스템 정체성 유지에 대한 문제 때문에 소수의 뛰어난 디자이너와 개발자를 선호한다. 하지만 아주 큰 프로젝트에 있어서는 아무리 뛰어난 소수의 인력만 가지고는 기한내에 일을 끝마치지 못한다. 이 두가지 문제점을 어떻게 해결할 수 있을까?
Harlan Mills는 우리에게 신선하고 창의적인 해결책을 제시해준다. 큰 일을 작은 일의 단위로 나누고, 나뉘어진 작은 단위의 일들은 수술실에 투입되는 수술팀과 같이 작고 잘 조직화된 팀으로 해결해 나아가는 것이다. 한 팀의 다수의 인력이 한 문제를 두고 달려들어 해결하는 것이 아니라, 수술실에서 시술자가 집도하고 나머지 사람들은 수술을 거들어주는 방식으로 일을 해결하면 일은 효과적이고 효율적으로 잘 진행될 것이라는 것이다. 이것이 과연 우리가 원하는 결과를 효과적으로 가져다 줄 수 있을지, 아니면 일이 진행되기나 할지 의문을 갖게 될 것이다. 여러 사람이 일을 모두 함께 한다고 해도, 직접적인 설계와 작업에는 소수의 사람만 투입된다. 가능하기나 한 일인가? 은유법을 사용하여 일이 어떻게 분담되는지 설명해 보겠다.
시술자 (The surgeon)
Mills는 chief programmer라고 말한다. 이 사람은 기능(functional) 및 성능(performance) 명세서(specification)를 정의하고, 설계하고, 구현하고, 검증하고, 문서화하는 일까지 한다. 경험이 매우 풍부해야 하며, 수학적인 지식이나 애플리케이션이 적용될 도메인에 대해서 잘 알아야 한다.
조수 (The copilot)
시술자의 일을 뭐든지 대신 할 수 있는 그의 분신. 그러나 시술자 보다 경험이 약간 부족한 사람. 시술자와 함께 같이 일을 하면서 사고하고, 논의하고, 그의 일을 평가해주는 사람. 하지만 모든 결정권은 시술자에게 있다. 현재 작업중인 코드에 대해서 굉장히 자세히 알고 있고, 다른 설계방안에 대해서 생각해볼 여유가 있는 사람. 가끔 코딩도 할 수 있지만, 그 코드들에 대해서는 책임을 지는 위치는 아니다.
관리자 (The administrator)
시술자가 두목이고, 시술자가 모든 인사 및 행정 결정권을 가지고 있지만, 그가 이런 일에 시간을 써서는 절대 안된다. 그러므로 돈, 사람에 대한 문제들을 전문적으로 다루는 관리자가 있어야 한다.
편집자 (The editor)
시술자는 생성되는 모든 문서에 대해서 책임을 져야 한다(최대한 명확하게 기술되어야 하기 때문에 본인이 직접 써야 한다). 편집자는 이런 문서들에 대해 비판하고, 수정하고, 참고문헌들까지 정리해서 최종적으로 온전한 문서가 될수 있도록 도와줘야 한다.
비서들 (Two secretaries)
관리자와 편집자는 비서들이 필요하여, 프로젝트의 대외적인 일을 담당할 것이며, 아울러 프로젝트와 직접적으로 관련이 없는 문서들을 정리하게 될 것이다.
서기관 또는 사무관 (The program clerk)
프로그램 개발 과정에 대한 모든 기록들을 관리하게 된다.
대장장이 (The toolsmith)
파일 편집기, 문서 편집기, 디버깅 서비스들은 요새는 대부분 주어진 상태에서 일이 진행되기 때문에 자체적인 기계 운용 요원들이 필요 없다. 하지만 위에서 언급된 기능들은 항상 개발자들이 만족할만한 수준과 높은 신뢰성이 유지될 것이 요구된다. 시술자의 판단하에 언제든지 필요한 서비스나 기능들이 제공되도록 툴의 제공, 업그레이드, 유지 및 보수에 대한 서비스를 제공할 수 있는 사람이 필요하다.
테스터 (The tester)
기능에 대한 요구 명세서에 따라 테스트 케이스를 만들어서 전문적으로 테스트를 하는 사람.
언어 변호사? (The language lawyer)
Algol과 같은 언어를 사용해 시스템을 유용하게 활용하는데 도가 터있어서 시술자에게 조언을 해줄 수 있고, 시술자가 언제든지 조언을 구할 수 있는 사람.
이렇게 구성된 수술팀과 유사한 팀은 효율적인 프로젝트 운용을 위한 요구사항에 딱 들어맞는다. 일반적으로 두명의 프로그래머들로 이루어진 팀과 시술자와 조수로 이루어진 수술팀과 유사한팀을 비교해 보자.
일반적인 두명의 프로그래머들로 이루어진 팀에서는 일을 분담하고 각 프로그래머가 자기가 맡은 부분의 디자인과 구현에 책임을 지게 된다. 하지만 수술팀과 같은 팀에서는 시술자와 조수 모두 같은 부분에 대해서 일을 하게 된다. 그 부분의 코드에 대해서 두명이 세밀한 정보까지 공유할 수 있게 되고 일의 분담에 대한 노력도 줄어든다. 그리고 무엇보다도 시스템의 정체성이 지켜질수 있다는 것이 가장 큰 수확일 것이다. 또, 만약 두 프로그래머가 동등한 위치에 있다고 가정한다면, 서로 이견이 있을 경우에는 타협이 이루어져야 한다. 일을 나눠서 하게 되는 경우에는 한정된 자원을 나눠서 해야 하는데, 자원 분배의 판단 기준은 전체적인 안목에서 결정되어야만 함에도 불구하고, 분업이 이루어지면 각자 맡은 일의 관점에 따라 판단이 이루어지게 되므로 편파적인 결정이 이루어질 수 밖에 없다. 따라서 시술자와 보조자로 이루어진 팀과 같은 경우는 일의 분담에 대한 문제가 없고, 상하 주종의 관계가 있기 때문에 두 프로그래머로 이루어진 팀 보다는 uno animo로 작업하는 것이 가능해 진다.
시스템 개발 이외의 일에 대해서는 각각 세분화시켜 전문가에게 맡기기 때문에 효율은 증대되고 커뮤니케이션의 구조는 매우 간단해져 일이 효과적으로 진행된다. 실제로 행해진 작은 규모의 실험에서는 위와 같이 일을 분담한 팀을 구성할 경우 좋은 결과를 가져온다는 것이 입증되었다. 하지만 이 방법을 큰 규모의 프로젝트에 많은 인력에 대해서 적용할 수 있을까? 오늘날의 많은 일이 5000 man-year가 필요한 것을 감안하면 매우 중요한 사안이다. 큰 프로젝트를 위와 같은 방식의 팀으로 나누는데 있어서 가장 중요한 것은 개발하는 시스템의 각 요소의 정체성이 보존될 수 있는 범위 내에서 일이 나누는 것이다. 이것에 대해서는 뒤에서 또 언급 한다. 여러개의 10명정도로 이루어진 수술팀이 큰 일을 분담하게 되면, 전체적인 사안에 대한 결정을 내려야 할 경우에는 각 팀의 시술자들만 모여서 협의하면 된다.
역시 요약하여 정리하는 것은 힘듭니다...
요약이 아니라 거의 번역이군요... 그렇다고 해서 수준높은 번역은 아닌데요... ㅡ.ㅡ;
조금이나마 도움이 되셨으면 좋겠습니다...
개인적으로 이 단원 마지막 소단원인 Scaling Up은 잘 이해가 안되는군요. 다른사람들이 요약한것을 보니 제가 잘못 이해 한듯 하여, 다른 사람들의 요약한 내용을 기반으로 정리했습니다. 혹시 이 책 읽어보신 분이나 읽게 되는 분 계시면 나중에 저랑 짧게 이 부분에 대해서 의견교환 해봤으면 좋겠습니다... 답글남겨주세요~
David Choi가 공연장에서 flip camcorder로 찍은 동영상을 드디어 YouTube에 올렸습니다~
그 비디오에 제가 살짝 나오네요... 저랑 같이 공연을 보러 갔던 웅기군도 나오고요!!! 개인적으로 저를 아시는 분이나, 블로그를 통해서 제 사진을 봐서 제 얼굴을 아시는 분들은 제 사진을 찾아보세요~ (참고글 2009/10/10 - David Choi 공연 보고 왔습니다...)
저를 찾으신 분께 선물을 드리는 이벤트를 한번 해볼까요? ㅎㅎㅎ
경품은... 글쎄요... 일단 저를 한번 찾아보세요~
찾은 장면을 캡쳐하셔서 표시를 해서 메일(dansoonie at gmail dot com)으로 보내주시면 경품은 생각해보도록 하겠습니다... David Choi CD를 또 경품으로 걸 수도 있겠지만, David Choi를 검색해서 제 블로그에 들어오신 분이라면 다들 CD 정도는 있지 않을까 싶네요...
어쨌든... 함 찾아보세요~
맨 마지막에 나오는 Canadian... 그 친구도 공연장에서 봤는데, 혼자 왔는지 공연 끝나고 David 한번 만나보려고 혼자 내내 기다리더라고요... 가서 같이 놀아줄까 생각도 해봤는데 생각만하고 말았습니다. 중간에 없어졌는데, 나중에 David이랑 밥도 같이 먹은 모양이네요... 저는 지하철이 끊기려고 하는 바람에 부랴부랴 집에 가느라 어차피 밥은 같이 못먹었겠지만... 그래도 참 부럽군요...
YouTube에서 많은 인기를 누리고 있는 재미교포 가수 David Choi가 내한을 하여 어제 공연을 하였습니다. 장소는 홍대 앞 클럽 타(打).
David Choi가 우리나라에 온다는 사실은 그의 YouTube channel을 통해서 이미 알고 있었고, 공연 기획하시는분으로 추정되는 분이 제 블로그에 친히 David Choi 관련 글 여러개를 일일이 찾아서 댓글로 공연정보를 남겨주시고, 심지어 방명록에도 글을 남겨주셔서 공연을 모르고 지나칠래야 지나칠 수 없었습니다.
그래서 가기로 마음 먹었는데, 혼자 가기는 싫고, 같이 갈만한 사람이 없었습니다... ㅜ.ㅜ
<빨간 네모로 표시되어 있는 곳이 클럽 타(打) 위치 (다음 지도 서비스)>
그래서 메신저 스크린네임을 "David Choi 공연 같이 가실분~" 이라고 바꾸고 같이 갈 동지를 찾고 있는데, David Choi를 사람들이 잘 모르니 같이 가겠다고 하는 사람이 없었던 겁니다 !!! 그러던 와중에 절친 후배 웅기군이 저에게 말 걸었습니다...
형, 꼭 여자랑 가야되는거죠?
그래서 제가 같이 가자고 했습니다... 자기가 생각해도 남자둘이서 남자 공연보러 가는것이 좀 이상했었나보죠???
어쨌든, 공연이 8시였는데, 입장권은 6시 반부터 받을 수 있고, 7시 반부터 표 구매 순서에 따라 입장할 수 있었습니다. 6시반 조금 넘게 도착하여, 입장권을 받고, 크라제버거에서 밥을 먹고, 7시 반쯤에 입장했습니다. 좌석이 50개 밖에 없었는데, 우리 앞번호 쪽에 아직 도착하지 않은 분들이 계셔서 그런지 빈자리가 조금 있어서 아주 좋은 자리는 아니었지만, 앉아서 David의 공연을 관람할 수 있었습니다.
David는 전문 YouTuber 답게 Flip camcoder를 가지고 입장하면서 관람객들의 반응을 동영상으로 찍었습니다. 우리나라에서
찍은 동영상들을 비교적 빠르게 업로드 하는 것 같던데, 어제 공연하면서 찍은 동영상은 아직 안올라왔군요...
제 카메라가 아주 구려서 사진이 잘 안나왔네요... 광량이 부족하면 사진이 잘 안찍혀서 공연관람을 몇일 앞두고 디지털 카레라를 새로 장만해볼까 생각도 했었는데, 역시 새로 장만하지 않은게 무척이나 후회 되었습니다.
이날 David는 한글날이라고, 자기가 오늘은 우리나라말을 많이 하기로 했다고 하면서 인사를 했습니다... 그리고 첫 노래로 Always Hurt이라는 노래를 불렀습니다.
동영상 촬영을 하다보니, 공연에 집중할 수 없어서 한동안 동영상 촬영을 하지 않았습니다. 그러다가 2nd Album에 수록될 노래를 부르겠다고 해서 동영상을 한 편 더 찍었습니다. 이미 다른 공연에서 몇번 불러봤지만, YouTube에는 아직 공개하지 않았다고 하는군요. 미리 한번 들어보세요~ This is the Way.
Club 타(打)는 지하에 밀폐된 공간이었는데, 150명의 관람객, 그리고 공연 관계자등 좁은 공간에 수많은 사람들이 원적외선을 발사하는데다가, 조명까지 한몫해서 무지 더웠습니다. 공연 내내 덥다고 하더니 결국 스웨터를 벗었습니다. 그러더니 더 열심히 노래를 불렀습니다.
마지막 곡을 끝내고 팬들은 일제히 앵콜을 외쳤습니다... 그러자 마지못해 하는척 하면서, 이럴줄 알고 미리 연습했다고 하면서 두곡을 더 불렀습니다. 마지막으로 부른 노래가 Beatles의 Hey Jude 였는데, 이 노래는 자신의 YouTube channel에서도 이미 cover로 불러서 올렸던 적이 있습니다. 쌩(Live)으로 들으니까 더 좋았습니다. 그리고 다같이 나~ 나나~ 나나나나~ 하면서 다같이 흥겹게 노래를 부르면서 공연이 마쳐졌습니다.
David는 공연이 끝나고 팬 하나하나 일일이 만나보고 싶다고, 자기를 만나보고 싶은 사람은 꼭 남아서 만나고 가달라고 당부했습니다. 그냥 가려고 했는데, David이 저를 만나보고 싶다고 해서 끝까지 남아서 David를 만나고 왔다고 말하면 저는 거짓말 쟁이입니다.
같이 갔던 웅기군이랑 같이 끝까지 남아서 CD 한장씩 구입하고 싸인 받고 간단한 대화도 나눴습니다. 예전에 David이 진행한 경품추첨에 당첨되어서 선물로 받은 그림(2008/11/21 David's Painting has Arrived...글 참고) 사진도 보여주면서, 내가 그 사람이다... 정말 팬이다... 이러 정말 유치한 말들을 많이 했습니다... 웅기군은 자신의 옷에다가 싸인을 받고 이젠 그 옷을 빨지 않겠다고 다짐도 했습니다... 어머니께 혼나지 않았나 모르겠습니다... 다 큰 친구인데 안 혼났겠죠? 이렇게 David Choi는 최초로 누군가의 배에 싸인을 해보게 되엇고, 웅기군은 배에 싸인을 당한(?) 팬 1호가 되었습니다.
이렇게 짧은 대화를 나누고, 같이 사진도 찍었습니다...
David라는 친구, 참 재미있는 친구였습니다. 다정하고, 유머감각도 있고, 작곡가로써, 그리고 가수로써 실력도 갖춘 친구라고 생각됩니다. 작은 키에 준수한 외모는 관람하러 온 많은 언니들이 계속 "귀엽다~"를 연발하게 만들었습니다... 앞으로도 좋은 음악 많이 만들고 많은 사람에게 사랑받았으면 좋겠습니다... 그리고 아울러 저를 기억해줬으면 좋겠네요... ㅋㅋㅋ
공연을 기획하고 주최한 분들도 공연 준비를 치밀하게 잘 한것 같습니다. 관람객들을 위해서 작은 기념품 가방도 나눠주기도 했고 공연장에 CD 판매를 준비하는 치밀함을 보여주기도 했습니다... 많은 팬들이 자신이 산 CD를 가져오기도 했지만, 저같은 경우는 그 생각은 못하고 있었습니다. David의 CD를 한장 더 소유하게 되긴 했지만. 원래 가지고 있었던 것은 미국판이고, 어제 공연장에서 산 것은 우리나라 판이라서 미국판에 없는곡 3곡이 더 들어있는데다가, 싸인도 받게 되었으니 CD 한장 구입한 것에 대해서는 후회가 없습니다.
