Source : http://msdn.microsoft.com/en-us/goglobal/bb964664.aspx

Language - Country/Region LCID Hex LCID Dec
Afrikaans - South Africa 0436 1078
Albanian - Albania 041c 1052
Amharic - Ethiopia 045e 1118
Arabic - Saudi Arabia 0401 1025
Arabic - Algeria 1401 5121
Arabic - Bahrain 3c01 15361
Arabic - Egypt 0c01 3073
Arabic - Iraq 0801 2049
Arabic - Jordan 2c01 11265
Arabic - Kuwait 3401 13313
Arabic - Lebanon 3001 12289
Arabic - Libya 1001 4097
Arabic - Morocco 1801 6145
Arabic - Oman 2001 8193
Arabic - Qatar 4001 16385
Arabic - Syria 2801 10241
Arabic - Tunisia 1c01 7169
Arabic - U.A.E. 3801 14337
Arabic - Yemen 2401 9217
Armenian - Armenia 042b 1067
Assamese 044d 1101
Azeri (Cyrillic) 082c 2092
Azeri (Latin) 042c 1068
Basque 042d 1069
Belarusian 0423 1059
Bengali (India) 0445 1093
Bengali (Bangladesh) 0845 2117
Bosnian (Bosnia/Herzegovina) 141A 5146
Bulgarian 0402 1026
Burmese 0455 1109
Catalan 0403 1027
Cherokee - United States 045c 1116
Chinese - People's Republic of China 0804 2052
Chinese - Singapore 1004 4100
Chinese - Taiwan 0404 1028
Chinese - Hong Kong SAR 0c04 3076
Chinese - Macao SAR 1404 5124
Croatian 041a 1050
Croatian (Bosnia/Herzegovina) 101a 4122
Czech 0405 1029
Danish 0406 1030
Divehi 0465 1125
Dutch - Netherlands 0413 1043
Dutch - Belgium 0813 2067
Edo 0466 1126
English - United States 0409 1033
English - United Kingdom 0809 2057
English - Australia 0c09 3081
English - Belize 2809 10249
English - Canada 1009 4105
English - Caribbean 2409 9225
English - Hong Kong SAR 3c09 15369
English - India 4009 16393
English - Indonesia 3809 14345
English - Ireland 1809 6153
English - Jamaica 2009 8201
English - Malaysia 4409 17417
English - New Zealand 1409 5129
English - Philippines 3409 13321
English - Singapore 4809 18441
English - South Africa 1c09 7177
English - Trinidad 2c09 11273
English - Zimbabwe 3009 12297
Estonian 0425 1061
Faroese 0438 1080
Farsi 0429 1065
Filipino 0464 1124
Finnish 040b 1035
French - France 040c 1036
French - Belgium 080c 2060
French - Cameroon 2c0c 11276
French - Canada 0c0c 3084
French - Democratic Rep. of Congo 240c 9228
French - Cote d'Ivoire 300c 12300
French - Haiti 3c0c 15372
French - Luxembourg 140c 5132
French - Mali 340c 13324
French - Monaco 180c 6156
French - Morocco 380c 14348
French - North Africa e40c 58380
French - Reunion 200c 8204
French - Senegal 280c 10252
French - Switzerland 100c 4108
French - West Indies 1c0c 7180
Frisian - Netherlands 0462 1122
Fulfulde - Nigeria 0467 1127
FYRO Macedonian 042f 1071
Gaelic (Ireland) 083c 2108
Gaelic (Scotland) 043c 1084
Galician 0456 1110
Georgian 0437 1079
German - Germany 0407 1031
German - Austria 0c07 3079
German - Liechtenstein 1407 5127
German - Luxembourg 1007 4103
German - Switzerland 0807 2055
Greek 0408 1032
Guarani - Paraguay 0474 1140
Gujarati 0447 1095
Hausa - Nigeria 0468 1128
Hawaiian - United States 0475 1141
Hebrew 040d 1037
Hindi 0439 1081
Hungarian 040e 1038
Ibibio - Nigeria 0469 1129
Icelandic 040f 1039
Igbo - Nigeria 0470 1136
Indonesian 0421 1057
Inuktitut 045d 1117
Italian - Italy 0410 1040
Italian - Switzerland 0810 2064
Japanese 0411 1041
Kannada 044b 1099
Kanuri - Nigeria 0471 1137
Kashmiri 0860 2144
Kashmiri (Arabic) 0460 1120
Kazakh 043f 1087
Khmer 0453 1107
Konkani 0457 1111
Korean 0412 1042
Kyrgyz (Cyrillic) 0440 1088
Lao 0454 1108
Latin 0476 1142
Latvian 0426 1062
Lithuanian 0427 1063
Malay - Malaysia 043e 1086
Malay - Brunei Darussalam 083e 2110
Malayalam 044c 1100
Maltese 043a 1082
Manipuri 0458 1112
Maori - New Zealand 0481 1153
Marathi 044e 1102
Mongolian (Cyrillic) 0450 1104
Mongolian (Mongolian) 0850 2128
Nepali 0461 1121
Nepali - India 0861 2145
Norwegian (Bokm?l) 0414 1044
Norwegian (Nynorsk) 0814 2068
Oriya 0448 1096
Oromo 0472 1138
Papiamentu 0479 1145
Pashto 0463 1123
Polish 0415 1045
Portuguese - Brazil 0416 1046
Portuguese - Portugal 0816 2070
Punjabi 0446 1094
Punjabi (Pakistan) 0846 2118
Quecha - Bolivia 046B 1131
Quecha - Ecuador 086B 2155
Quecha - Peru 0C6B 3179
Rhaeto-Romanic 0417 1047
Romanian 0418 1048
Romanian - Moldava 0818 2072
Russian 0419 1049
Russian - Moldava 0819 2073
Sami (Lappish) 043b 1083
Sanskrit 044f 1103
Sepedi 046c 1132
Serbian (Cyrillic) 0c1a 3098
Serbian (Latin) 081a 2074
Sindhi - India 0459 1113
Sindhi - Pakistan 0859 2137
Sinhalese - Sri Lanka 045b 1115
Slovak 041b 1051
Slovenian 0424 1060
Somali 0477 1143
Sorbian 042e 1070
Spanish - Spain (Modern Sort) 0c0a 3082
Spanish - Spain (Traditional Sort) 040a 1034
Spanish - Argentina 2c0a 11274
Spanish - Bolivia 400a 16394
Spanish - Chile 340a 13322
Spanish - Colombia 240a 9226
Spanish - Costa Rica 140a 5130
Spanish - Dominican Republic 1c0a 7178
Spanish - Ecuador 300a 12298
Spanish - El Salvador 440a 17418
Spanish - Guatemala 100a 4106
Spanish - Honduras 480a 18442
Spanish - Latin America 580a 58378
Spanish - Mexico 080a 2058
Spanish - Nicaragua 4c0a 19466
Spanish - Panama 180a 6154
Spanish - Paraguay 3c0a 15370
Spanish - Peru 280a 10250
Spanish - Puerto Rico 500a 20490
Spanish - United States 540a 21514
Spanish - Uruguay 380a 14346
Spanish - Venezuela 200a 8202
Sutu 0430 1072
Swahili 0441 1089
Swedish 041d 1053
Swedish - Finland 081d 2077
Syriac 045a 1114
Tajik 0428 1064
Tamazight (Arabic) 045f 1119
Tamazight (Latin) 085f 2143
Tamil 0449 1097
Tatar 0444 1092
Telugu 044a 1098
Thai 041e 1054
Tibetan - Bhutan 0851 2129
Tibetan - People's Republic of China 0451 1105
Tigrigna - Eritrea 0873 2163
Tigrigna - Ethiopia 0473 1139
Tsonga 0431 1073
Tswana 0432 1074
Turkish 041f 1055
Turkmen 0442 1090
Uighur - China 0480 1152
Ukrainian 0422 1058
Urdu 0420 1056
Urdu - India 0820 2080
Uzbek (Cyrillic) 0843 2115
Uzbek (Latin) 0443 1091
Venda 0433 1075
Vietnamese 042a 1066
Welsh 0452 1106
Xhosa 0434 1076
Yi 0478 1144
Yiddish 043d 1085
Yoruba 046a 1130
Zulu 0435 1077
HID (Human Interface Device) 04ff 1279



현재 내가 개발중인 대부분의 어플리케이션의 경우 요 언어번호를 응용해서 작성하고 있다.


L18N은 어떤것을 참조하는지 알아보려고 하지도 않-_-았다..


요즘 추세에 어플리케이션 개발부분 레퍼런스는 볼랜드나 기타그룹보다는 MS가 가장 쓸만하니..


리눅스 개발자분들은 존경하지만 난 소켓서버+DB접근 이외의 용도를 위해 리눅스 개발을 하진 않으련다(하긴 이것들도 요샌 인디라던가 컴포넌트들이 잘 나와서 그걸로 그냥 대체해서 쓴다)..


IOCP가 퍼포먼스가 좋다던가 하는 그런 이유가 아니라 단지 삽질이 싫어서다..


까놓고 요샌 웬만한 언어들 최적화 잘 되어있어서(인기있는 제품일수록 더더욱) 만드는거나 컴포넌트 갖다 쓰는거나 퍼포먼스는 거기서 거기다..


퍼포먼스 최악이라고들 얘기하는 자바나 c#으로도 웬만한거 돌리는데는 무리없더라..



리눅스 문서가 잘되어 있다고들은 하는데, 아무래도 MSDN을 따라가긴 힘들지..


요즘 트렌드는 웹개발이지만, 그래도 난 내공이 좀 필-_-요하다..


실제로 웹프로그래머라고 자칭하는분들이라면 최소 List, View, Modify, Write 정도는 직접 만들줄 알아야 할텐데.. 그게 아닌거 같기도 하고..


제로보드같은 빌더로 페이지 만드는것만으로 ‘나는 웹개발자다’라고 말하기엔 무리가 있는건 아닌지..



어쨌건 MS가 직접 표준을 제창하는건 아니지만 그 기반을 만드는게 아닌가 하는 생각이 든다.


이 문서는 아무리 찾아봐도 Standard는 아니지만, 이것 이외에 쓸만한 Standard가 있다면 좀 알려주시라.


나도 표준에 부합하는 뭔가를 만들고 싶은데.. 정해진게 없으니 원..



덧> 웹표준이 만능인지 아는 사람들이 간혹 있는데.. 특히 오픈웹 관련자들..


오픈웹 관련자들에게 웹에서 실제 가동하는 프로그레스바를 당신네들이 말하는 표준만으로 만들수 있겠냐 했다.


난 표준지지가 아님에도 불구하고 ajax로 만들수 있는데, 입만 열면 표준타령하는 사람들은 그거 하나도 제대로 못하더라.


물론 오픈웹에서도 실력있는 사람이 있다고 생각은 한다만, 최소한 나한테 견발자라면서(난 지금 직업이 개발자도 아닌데 말이지) 모든 책임을 뒤집어 씌우는 사람들에게서 얻은건 알량한 우월감 뿐이다..


주장을 하려면 근거제시가 되어야 한다.


기본적으로 어떻게 설계하는지 정도는 알아야 한다는 얘기.


사용자 입장에서는 몰라도 되는 이야기지만, 논쟁을 하기 위해서는 최소한의 개발경험은 있어야 한다고 보는데..

'Hardware' 카테고리의 다른 글

USB 메모리 사용 흔적 삭제하기  (0) 2010.12.01
[하드웨어 계보] CPU / 메인보드 / 하드디스크  (2) 2010.11.25
LCID List  (0) 2010.01.26
디지털 방송  (0) 2009.10.29
USB Vendor ID List  (1) 2009.01.06
모니터 색상검사  (0) 2008.08.03

Source : http://honeybox.tistory.com/182

 

The Joel Test: 나은 코딩을 위한 12단계

글 : Joel Spolsky
번역 : B.K. Chung 정봉겸
감수 : Jang Han Goo 구장한
2000년 8월 9일

SEMA에 대해서 들어보신 적이 있습니까? 소프트웨어 팀이 얼마나 잘하는지를 재는 나름대로 복잡한 시스템입니다. 앗, 아니! 그 링크를 누르지 마세요. SEMA를 "이해"만 하는데 아마 6년정도가 걸릴것입니다. 그래서 소프트웨어 팀이 얼마나 좋은지 등급을 매길 수 있는 - 좀 무책임하고 되는대로의 - 자체적인 버젼의 테스트를 만들었습니다. 이 테스트의 장점은 3분정도밖에 걸리지 않는다는 것입니다. 절약되는 시간으로 의대에 가서 공부할 수도 있을 것입니다.

The Joel Test

  1. Source Control(소스 컨트롤)을 사용하십니까?
  2. 한번에 빌드를 만들어낼 수 있습니까?
  3. daily build(일별 빌드)를 만드십니까?
  4. 버그 데이타베이스를 가지고 있습니까?
  5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?
  6. up-to-date(최신) 스케줄을 가지고 있습니까?
  7. spec(설계서)를 가지고 있습니까?
  8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?
  9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
  10. 테스터들을 고용하고 있습니까?
  11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
  12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?

Joel Test이 특별한 점은 각 직문에 예/아니오로 바로 대답할 수 있다는 것이다. lines-of-code-per-day(하루동안 산출되는 코드의 줄수)나 average-bugs-per-inflection-point(산출 시점의 평균 버그수) 같은 것은 알 필요가 없습니다. "예"에 해당 하는 질문에 1점씬 가산됩니다. 하지만 이 테스트는 핵 원자로에 사용하는 소프트웨어가 안전한지를 검사하는등 에는 사용하지 말아주십시오.

12점은 완벽, 11은 충분한 점수이지만 10점이나 그 이하는 심각한 문제가 있다는 신호입니다. 사실은 대개의 소프트웨어 회사 들이 2~3점을 받고 있고, 심각한 도움을 필요로 하고 있습니다. Microsoft같은 회사는 12점 만점을 받고 있습니다.

당연한 이야기지만 이것들만으로 성공과 실패를 가를 수는 없습니다. 특히, 아무도 필요없는 제품을 굉장히 훌륭한 소프트웨어 팀이 만들고 있다면, 역시나 아무도 원하지 않을 것입니다. 반대로 이런 방식을 따르지 않는 명인들이 세상을 바꾸는 소프트웨어 를 만드는 경우로 생각할 수 있겠습니다. 그러나, 이 12가지 이외의 요소를 모두 동등하게 놓고 본다면, 이들만 제대로 한다면 지속적으로 좋은 결과를 내는 잘 훈련된 팀이 될 것입니다.

1. Source Control(소스 컨트롤)을 사용하십니까?

상용 소스 컨트롤 패키지들도 사용해보았고, 무료로 사용할 수 있는 CVS도 사용해보았습니다. CVS는 무료이기는 하지만 충분합니다. 그렇지만 소스 컨트롤이 없다면 프로그래머들을 조율하는 일이 상당히 피곤할 것입니다. 프로그래머들은 다른 사람들이 어떤 것을 했는지 알 수 있는 방법이 없습니다. 이를 사용하면 실수를 쉽게 롤백할 수 있습니다. 소스 컨트롤의 다른 장점은 소스코드 자체가 모든 프로그래머의 하드디스크에 체크아웃(check out)되어 있다는 것입니다. 소스 컨트롤을 사용하는 프로젝트에서 코드를 날렸다는 이야기를 들어본 적이 없습니다.

2. 한번에 빌드를 만들어낼 수 있습니까?

"최신의 소스로부터 몇단계를 거쳐서 완제품(shipping build)을 만들 수 있습니까?"라는 의미의 질문입니다. 잘 되어있는 팀인 경우라면 하나의 스크립트로 checkout부터 시작하여 각 소스를 리빌드(rebuild)하고 각 버젼, 언어, #ifdef같은 조건별로 실행파일을 만들어내어 마지막 CDROM 레이아웃, 다운로드할 수 있는 웹사이트를 만들어 내는 정도까지 되어 있을 수 있겠습니다.

만일 이 과정이 하나의 단계 이상을 거친다면, 여기서부터 에러가 발생할 확률이 생깁니다. 정해진 기일이 가까워질수록 "마지막" 버그를 수정하고 실행파일을 만드는 등을 위해 빠른 사이클을 필요로 할 것입니다. 코드를 컴파일하고 설치파일을 구성하는데에 20단계가 필요하다면 급박한 시간때문에 사소한 실수를 저지르게 될 것입니다.

필자가 마지막으로 근무했던 회사에서는 이런 이유로 WISE를 InstallShield(역자주 : 두 제품 모두 설치본을 만들기위한 도구 입니다.)로 교체하였습니다. 설치 과정을 스크립트를 통해서 NT 스케줄러로 밤새에 자동으로 실행하도록 하고자 하였는데, WISE는 스케줄러로 실행할 수 없던 이유입니다. (WISE의 친절한 분들이 최신 버젼에는 이것이 가능하다고 알려왔습니다.)

3. daily build(일별 빌드)를 만드십니까?

소스 컨트롤을 사용하다 보면 누군가가 빌드를 실패하게 만드는 코드를 체크인 할 수 있습니다. 예를 들면, 새로운 소스파일을 추가해서 그 사람의 컴퓨터에서는 잘 컴파일되지만, 이를 코드 레파지토리(repository)에는 추가를 하지 않았을 수 있습니다. 이 사람은 이를 잊고 만족한 상태에서 컴퓨터를 잠그고 집에 돌아갑니다. 그렇지만 이로 인해 다른사람들은 작업을 할 수 없게 되고 결국 찝찝하지만 결과없이 집으로 돌아갈 수 밖에 없습니다.

모르는 사이에 빌드를 실패하는 이런 컴파일 오류가 나지 않도록 daily build를 만들게 됩니다. 큰 팀에서는 이런 경우를 위해서 daily build를 매일 오후 - 점심시간등 - 에 합니다. 사람들은 점심시간 이전에 될 수 있는 한 많이 체크인을 합니다. 점심을 먹으로 갔다가 다시 돌아오면 빌드는 이루어져 있습니다. 빌드가 실패하면, 사람들은 빌드가 성공한 이전 소스로 작업을 하면 됩니다.

엑셀팀에서는 누군가 빌드를 깨면 벌칙으로 다른 사람이 다시 깰때까지 빌드를 관리하도록 벌칙을 주었습니다. 이는 빌드를 깨면 받는 벌칙으로써 뿐만 아니라 모든 이들이 돌아가면서 빌드를 관리할 수 있게하여, 어떻게 돌아가는 지를 익히게 하는 방법으로써도 좋았습니다.

daily build에 관해 더 자세히 아시려면 저의 기사 daily builds are your friend를 읽으십시오.

4. 버그 데이타베이스를 가지고 있습니까?

뭐라고 반박하셔도 확신합니다. 코드를 짜고 있다면 설령 혼자 짜더라도 정리된 버그 명세 데이타베이스를 가지고 있지 않다면 낮은 질의 코드로 제품을 출시할 것입니다. 많은 프로그래머들이 머리로 버그들을 모두 기억할 것이라고 생각합니다. 말도 안되는 이야기입니다. 제 경우에는 한번에 2~3개의 버그밖에 기억을 못하고, 다음날이 되거나 출시를 위해 급해지면 전부 잊어버리게 됩니다. 버그를 제대로 트래킹해야합니다.

버그 데이타베이스는 복잡할 수도 있고, 간단할 수도 있습니다. 최소한으로 갖추어야할 요소는 다음과 같습니다:

  • 버그를 완벽하게 재현할 수 있는 과정
  • 버그가 없었다면 이루어졌어야할 결과(동작)
  • 버그로 인하여 생긴 결과(동작)
  • 누가 이 버그에 할당되어 있는지
  • 고쳐진 버그인지 아닌지

버그 데이타베이스를 사용하지 않는 이유가 제품들이 너무 복잡해서라면, 이것들을 포함한 5컬럼의 테이블을 만들어서 사용하기 시작하세요.

버그 트래킹에 관해 더 읽으려면, Painless Bug Tracking을 읽으세요.

5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?

마이크로소프트 Windows용 Word의 첫 버젼은 죽음의 프로젝트였습니다. 끝이 없었습니다. 계속해서 스케줄을 펑크냈습니다. 팀 전체는 말도 안되는 시간동안 일했고, 계속해서 연기되고 또 연기되었습니다. 그 스트레스는 엄청났습니다. 빌어먹을 제품이 몇년 후에 출시되었을때, 마이크로소프트는 팀 전원을 Cancun으로 휴가보내고, 이 원인을 분석하기 시작했습니다.

그들이 깨닫게 된 것은 프로젝트 매니저들이 스케줄을 너무 강요하였기 때문에 프로그래머들은 코딩을 빨리 할 수 밖에 없었습니다. 게다가 버그를 고치는 단계는 스케줄에 아예 존재하지 않았습니다. 결과적으로 질이 아주 나쁜 코드를 만들게 되었습니다. 버그 갯수를 줄이려는 노력은 전혀 하지 않았습니다. 한 프로그래머는 텍스트의 높이를 계산하는 루틴 대신에 "return 12;"로 대체하여 버그 리포트로부터 이 값이 어떤 영향을 주었는지를 알고자 했습니다. 스케줄은 단지 버그일 수 밖에 없는 기능들을 모아 놓은 체크리스트였습니다. 나중에 이 상황을 "무한 결함 방식(infinite defects methodology)"이라고 이름지었습니다.

문제를 해결하기 위해서 마이크로소프트는 반대의 "무결함 방식(zero defects methodology)"라는 방식을 체택했습니다. 많은 프로그래머들은 경영진들의 명령에 의해서 버그 갯수를 줄일 수 있다고 생각했음직한 이 방식의 이름 탓에 이를 비웃었습니다. 하지만 실제로는 "무결함(zero defects)"이라는 이름은 주어진 시간에 가장 우선순위가 높은 것은 코딩하기전에 버그를 잡는 것이란 사실을 지칭하는 말이었습니다. 이유는 다음과 같습니다.

일반적으로 버그를 고치지 않고 방치하는 시간이 길어지면 길어질수록 고치는데 더 많은 시간과 금전이 요구된다는 것입니다.

예를 들면, 오타나 문법오류등은 컴파일러가 쉽게 잡아서 고치는데도 별로 문제가 되지 않습니다.

만일 버그가 처음 실행시에 발생하여 보이게 되면, 모든 코드가 머릿속게 생생하게 존재하기에 바로 고칠 수 있을 것입니다.

며칠전에 작성한 코드에서 버그를 찾게 되면 이를 고치기 위해 조금 시간이 더 걸릴 것입니다. 아마도 코드를 다시 보게 되면 대부분의 내용이 기억나고 적정한 시간내에 버그를 고칠 수 있을 것입니다.

하지만 몇달전에 작성한 코드에서 버그가 발견된다면 이미 그 코드에 관해서 많은 것이 이미 생각나지 않을 것이고, 고치기도 상대적으로 힘들 것입니다. 그때쯤 되면 다른 사람의 코드를 수정하고 있는 와중일지도 모르고, 그사람은 Aruba로 휴가를 떠나있을지도 모릅니다. 이렇게 된다면 버그를 고치는 것은 기술을 익히는 것같이 되어버릴 것입니다. 천천히 꼼꼼하게 그리고 주의 깊게 코드를 살펴봐야 하고, 물론 문제를 해결하는데에 얼마나 걸릴지 정확하게 판단하기 힘든 상황이 될 것입니다.

게다가 이미 출하된 코드에서 버그를 발견한다면, 이를 고치는데에 큰 대가를 치뤄야할지도 모를 것입니다.

이렇게 시간이 적게 들기 때문이라는 이유가 하나의 이유가 됩니다. 또다른 이유는 버그를 수정하는데 걸리는 시간을 예상하는 것보다는 새로운 코드를 작성하는데 걸리는 시간을 예상하기가 훨씬 쉽기 때문입니다. 예를 들면, 내가 당신에게 리스트를 소트하는 코드를 만드는데 얼마나 걸리냐고 물어본다면, 꽤 정확한 대답을 할 수 있을 것입니다. 그렇지만, 질문을 바꿔서 당신의 코드가 Internet Explorer 5.5만 설치되어있으면 동작하지 않는 버그를 고치는데 걸리는 시간을 묻는다면, 문제가 무엇인지도 모르는 상황이기 때문에 얼마나 걸릴지 추측하지도 못할 것입니다. 3일이 걸릴 수도 있을 것이고, 운좋으면 2분이 걸릴 수도 있을 것입니다.

이것이 의미하는 바는 고쳐야할 버그가 많이 존재하는 상태의 스케줄이라면 그 스케줄은 정확할 수가 없다는 것입니다. 그렇지만 이미 알고있는 버그들은 모두 고친 상태라면 그 스케줄은 상대적으로 상당히 정확하게 지킬 수 있는 스케줄일 것입니다.

버그 갯수를 0에 가깝게 하는 또하나의 좋은 점은 경쟁에서 훨씬 빠르게 대응할 수 있다는 것입니다. 어떤 프로그래머들은 이를 두고 제품을 바로 출하할 수 있는 항상 유지하는 것이라고 이야기합니다. 경쟁자가 고객들을 가로채갈만한 굉장히 좋은 기능을 새로 만들었다면 축척된 많은 버그를 수정할 필요없이 바로 이 기능을 추가할 수 있을 것입니다.

6. up-to-date(최신) 스케줄을 가지고 있습니까?

비즈니스에 당신의 코드가 조금이라도 중요한 부분이라면, 코드가 언제쯤 완성될 수 있는지를 아는 것 또한 중요하다는 것은 당연할 것입니다. 프로그래머들은 엉터리 스케줄을 만드는데 악명이 높습니다. "언젠가는 될꺼야!"하고 외칩니다.

불행하게도 그런 식으로는 해결할 수 있는것은 없습니다. 비즈니스에는 코드를 출하하기 전에 데모, 전시회, 광고등등 미리 많은 것들을 판단하여 결정해야합니다. 이를 할 수 있는 단 한가지 방법은 스케줄을 가지고 이를 계속해서 현실적으로 최신내용으로 유지하는 것입니다.

스케줄을 가져야하는 또다른 중요한 이유는 이를 통해서 어떤 기능이 필요한지를 결정하게끔 만들어준다는 것입니다. 때문에 어떤 기능이 덜 중요한지 결정해야하고 featuris 가 되기 전에 이들을 포기하도록 합니다.

스케줄을 관리하는 것이 어려울 필요는 없습니다. 제 글Painless Software Schedules 에 좋은 스케줄을 만드는 간단한 방법을 설명하였습니다.

7. spec(설계서)를 가지고 있습니까?

스펙을 만드는 것은 이빨을 쑤시는것과 같습니다: 모든 사람들이 좋다고 인정하지만, 아무도 하지 않습니다.

왜 그런 현상이 일어나는지는 정확히 모르겠습니다만, 아마도 프로그래머들이 문서를 만드는 것을 굉장히 싫어하는데에 기인하는 것 같습니다. 그 결과로, 프로그래머밖에 없는 집단에서 한가지 문제를 해결하고자 하면, 이들은 문서를 만들기 보다는 코드로 자신들의 의견을 표명하려 합니다. 스펙을 먼저 만들기보다는 차라리 코드를 짜서 보여주는 것을 택한다는 것입니다.

설계 단계에서 문제를 발견하면 몇줄을 고쳐서 이를 수정할 수 있습니다. 그렇지만 코드가 짜여진 상황이라면 이 문제를 수정하는 댓가는 감정적으로나(코드를 그냥 버리는 것을 좋아하는 사람은 없습니다) 시간적으로나 훨씬 높게 되고 더 힘든 작업이 되어버립니다. 스펙을 통해서 만들어지지 않은 소프트웨어는 대개 설계가 잘못되어 스케줄을 엉망으로 만들어놓습니다. Netscape에서도 이런 문제로 인해 브라우저의 초기 네개의 버젼이 너무 엉망이 되어 결국 관리자들이 멍청하게도 코드를 전부 버리고 다시 짜도록한 결정을 내려버리게 되는 상황이 벌어졌습니다. 거기다 한술 더 떠서 Mozilla에서 이런 실수를 다시 반복하여 겨우 Alpha 단계에 가는데 몇년이라는 시간이 걸리게 되었습니다.

필자의 지론은 이 문제는 프로그래머들이 문서를 작성하는데 거부감이 없도록 작문 강의를 듣도록 보내는 것으로 해결할 수 있다는 것입니다. 다른 해결책이라면 스펙같은 문서 작성에 능숙한 관리자를 두는 것입니다. 두 경우 모두 "스펙없는 코드는 금물"이라는 간단한 규칙을 따라야 할 것입니다.

저의 4부짜리 글에 스펙 작성하는 요령에 대해 이야기했습니다.

8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?

지식 근로자에게 공간, 조용함, 프라이버시를 줌으로해서 많은 생산성 향상을 얻는다는 것은 이미 증명된 사실입니다. 소프트웨어 관리의 고전인 Peopleware에서는 이 생산성 향상에 대해 자세히 기술합니다.

문제는 여기에 있습니다. 지식 근로자는 "in the zone"상태라고도 하는 "flow"상태에 들어섬으로써 가장 최상의 상태가 되어 일에 완벽히 집중하고 외부에 개의치 않게 됩니다. 완벽한 집중으로 시간 가는 것을 잊고 좋은 결과를 내게 됩니다. 이때에 바로 대부분의 생산적인 일들을 처리하게 됩니다. 작가, 프로그래머, 과학자 그리고 심지어 농구선수들까지도 "in the zone"상태가 있음을 이야기할 것입니다.

문제는 "zone"으로 들어가는 것이 쉽지 않다는 것입니다. 측정해보면, 최상의 생산성으로 일을 하기 위해서는 평균 15분이 걸립니다. 하지만 어떤 경우에는 피곤하고 이미 많은 일을 한 상태에서 "zone"상태에 들어가지 못하고 다른 일을 하거나 웹서핑이나 테트리스로 시간을 허비하게 될 수도 있습니다.

또다른 문제는 "zone"상태에서 빠져나가는 것이 매우 쉽다는 것입니다. 잡음, 전화소리, 점심식사, 잠시 스타벅스에 5분간 갔다오는 것 그리고 특히 동료에 의한 방해등에 의해 바로 "zone"에서 빠져나가게 됩니다. 동료가 1분이라는 짧은 시간 동안이라도 질문을 하여 "zone"상태에서 빠져나간다면 다시 되돌아가기 위해서 30분이 넘는 시간이 걸려 전체 효율에 치명적인 영향을 미칠 수 있습니다. 카페인 가득한 닷컴 회사들이 좋아하는 합숙소같은 곳에 옆의 마케팅 부서에서 계속해서 오는 전화에 대고 소리지르는 그런 시끄러운 환경이라면 계속된 방해로 지식 근로자들의 생산성은 추락하여 "zone"상태에 절대 이르지 못할 수도 있습니다.

프로그래머들에게 있어서 특히 어렵습니다. 생산성은 단기적인 기억력으로 한번에 얼마나 많은 작은 세부사항들을 다루느냐에 달려있습니다. 어떠한 방해도 이런 세부사항들을 잊어버리게 할 수 있습니다. 일을 다시 재개하면 그것들을 다시 기억하지 못하여 (사용하던 지역변수나 검색 알고리즘을 만들던 중에 어디에서 멈줬었는지등) 다시 찾아보게 되고, 이로 인해 다시 속도가 붙을때까지 느려지게 됩니다.

직관적으로 계산해보면 다음과 같습니다. 만일 프로그래머가 단 1분이라도 방해를 받아서(명백한 근거에 의해) 15분의 생산성을 날려버린다고 합시다. 철수와 영희 두 프로그래머가 낮은 칸막이로 주욱 늘어선(a standard Dilbert veal-fattening farm) 열린 사각 파티션 옆자리에 앉아 있다고 합시다. 영희가 strcpy함수의 유니코드 버젼 이름을 잊었습니다. 30초면 찾아볼 수 있겠지만, 철수한테 물어보면 15초가 걸립니다. 그래서 바로 옆에 앉아 있는 철수에게 묻습니다. 철수는 산만해지고 - 영희의 15초를 아끼기 위해 - 15분을 낭비하게 됩니다.

이번에는 벽과 문으로 나뉘어진 별도의 사무실로 가정을 합시다. 여전히 영희는 함수를 기억하지 못합니다. 다시 찾아보는 것으로 30초를 보낼 수 있을 것이고 옆 방에 있는 철수에게 물어보기 위해서 (일반적인 프로그래머의 평균 물리적인 건강상태를 봐서는 쉽지 않은) 일어나서 걷는 것을 포함한 45초를 보낼 수 있을 것입니다. 결국 찾아보는 것을 선택하여 30초를 보내게 되지만 철수의 15분을 벌어주게 됩니다. 대단하죠!

9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?

컴파일 되는 언어로 코드를 작성하는 것은 여전히 아무 PC에서 할 수 없는 것 중의 하나입니다. 컴파일을 하는데 몇초 이상 걸린다면 최상의 기종을 사용함으로써 시간을 절약할 수 있을 것입니다. 15초 이상 걸린다면 지루해서 그 시간동안 The Onion을 읽게 될 것이고 너무 재미있는 관계로 거기에 빠져 수시간의 생산성을 날려버릴 것입니다.

모니터 하나로 GUI코드를 디버깅한 것은 불가능하지는 않지만 고통스러운 작업입니다. GUI코드를 작성하고 있다면, 2대의 모니터로 훨씬 쉬운 작업을 할 수 있을 것입니다.

대개의 프로그래머들은 아이콘이나 툴바를 위해 비트맵을 수정해야하고 대부분의 프로그래머 역시 좋은 비트맵 에디터를 가지고 있지 않습니다. 마이크로소프트에서 기본적으로 제공하는 Paint 프로그램으로 비트맵을 수정하는 것은 웃긴 일이지만 대부분 이렇게 하고 있습니다.

필자의 가장 최근 직장에 서 시스템 관리자가 계속해서 자동적으로 스팸을 보냈습니다. 이유인 즉슨 220MB이상의 하드드라이브를 사용하고 있다는 것이었습니다. 필자는 요즘 HD가격을 본다면 이 공간의 환산된 가격은 내가 이용하는 화장실 휴지보다 싸다는 것을 지적했습니다. 디렉토리를 정리하기 위해 10분을 허비하는 정도로도 큰 생산성 저하일 것입니다.

"최고의 개발팀은 절대 그들의 프로그래머들을 고문하지 않습니다!" 후진 제품으로 인한 작은 불편함이 쌓여서 프로그래머들이 불만에 찰 수도 있습니다. 그리고 그로 인한 불만에 찬 프로그래머는 비생산적인 프로그래머이기 쉬울 것입니다.

이런 것들을 모두 종합하면 프로그래머들은 최고/최신의 것들로 쉽게 매수된다는 뜻이 됩니다. 이는 높은 연봉을 주는 것보다는 훨씬 싼 방법일 것입니다!

10. 테스터들을 고용하고 있습니까?

팀이 최소한 2~3명의 프로그래머에게 테스팅만 전담하는 테스터가 할당되어 있지 않다면, 버그가 많은 제품을 출하하고 있거나 시간당 $100짜리 프로그래머에게 시간당 $30의 일을 시키는 낭비를 하고 있는 것입니다. 테스터를 고용하는 것이 낭비로 생각하는 것은 정말 잘못된 계산을 하고 있는 것이며, 많은 사람들이 이를 깨닫지 못하고 있는데에 놀랍니다.

이에 관해 더 자세히 알고자 한다면 Top Five (Wrong) Reasons You Don't Have Testers 를 읽으십시오.

11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?

마법사를 고용하는데 그의 마법을 보지 않고 고용하시겠습니까? 당연히 그렇지 않겠죠.

결혼식에 요리사를 고용하는데 요리사가 만든 요리의 맛도 모르고 고용하시겠습니까? 그렇지 않을것입니다.(역자주: 실제로 결혼식장 요리사의 맛을 보는 비유는 우리나라에 맞지 않을 것 같네요. 이 문구의 뜻만 이해하세요)

하지만 현실에서는 매일 인상적인 이력서나 면접에서 맘에 든 이유로 고용하는 일들이 일어납니다. 혹은 ("CreateDialog()와 DialogBox()의 차이점은 무엇입니까")등의 문서만 보면 알 수 있는 사소한 질문으로 채용하기도 합니다. 프로그래머를 채용하는데 있어서 중요한 것은 그런 사소한 것들을 얼마나 많이 외웠느냐가 아니고 코드를 잘 작성할 수 있느냐입니다. 혹은 "아하!"류의 질문으로 채용하기도 합니다. "아하!"류의 질문이란 답을 알면 간단하지만 모르는 경우에는 절대 맞출 수 없는 질문을 이야기합니다.

제발 이런 방식을 그만 두십시오. 면접때 무얼해도 상관없지만 반드시 코드를 작성하도록 해야합니다.(더 많은 것을 알고 싶다면 Guerrilla Guide to Interviewing를 읽으십시오)

12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?

무작위 사용성 테스트(hallway usability test)는 복도를 지나가는 다음 사람을 붙잡고 방금 짠 코드를 사용하게 하는 방식입니다. 5명에게 이 테스트를 한다면 95%의 사용성 문제에 대해 배울 수 있을 것입니다.

좋은 사용자 인터페이스 설계는 생각처럼 어려운 것이 아니고 사용자들이 당신의 제품을 구입하고 사용하게 하는데 있어서 절대적으로 중요합니다. 짧은 프로그래머 입문서로 UI 설계에 관해 필자가 쓴 무료 온라인 책을 읽어보실 수 있습니다.

하지만 사용자 인터페이스에서 제일 중요한 것은 많은 사람들에게 당신의 프로그램을 보여주면(5~6명이면 충분합니다) 제일 큰 문제점을 빠른 시간에 발견할 수 있다는 것입니다. Jakob Nielsen의 글에서 그 이유에 대한 설명을 찾을 수 있습니다. UI 설계 경험이 별로 없다고 하더라도 - 비용이 전혀 들지 않는 - 무작위 사용성 테스트를 한다면 당신의 UI는 훨씬 좋아질 것입니다.

Joel Test를 사용하는 4가지 방식

  1. 자신이 속한 소프트웨어 팀의 점수를 매기고 그것에 대해 언급할 수 있도록 결과에 대한 이유를 필자에게 알려주십시오.
  2. 프로그래머 팀의 관리자라면, 당신의 팀이 최대한 잘 운영될 수 있는지 확인할 수 있는 지표로 사용하십시오. 12점을 받기 시작하면 프로그래머들을 간섭없이 그냥 두고 비즈니스쪽 사람들이 그들을 간섭하지 못하게 하는데에 모든 시간을 할 수 있습니다.
  3. 프로그래머 일을 맡을지를 결정해야하는 상황이라면 그 팀의 친한 사람에게 이 테스트 결과가 어떤지를 물어보십시오. 결과 점수가 너무 낮다면 이를 고칠 수 있는 권한을 받을 것인지를 확인하십시오. 그렇지 않으면 불만과 스트레스에 빠질 것입니다.
  4. 프로그래밍 팀을 평가하여야 하는 투자자이거나 당신의 회사가 다른 소프트웨어 회사와 합병을 한다면 이 평가가 급한대로 괜찮은 지표가 될 것입니다.

'장난치기' 카테고리의 다른 글

세계 10대 망언  (0) 2009.02.11
전세방은 왜 한국에만 있을까?  (1) 2009.01.21
The Joel Test: 나은 코딩을 위한 12단계  (0) 2009.01.14
명언들  (0) 2009.01.14
일본어 단어 연상 암기법  (0) 2008.12.28
Gnosticism of Evangelion  (2) 2008.08.04

Source : http://devnote.net/14

저는 한국에서 개발자 생활 7년 이상 미국에서 3년 이상 해오고 있습니다. 따라서 한국과 미국 생활의 다른점 들을 생각나는대로 적어 보도록 하겠습니다. 물론 소프트웨어 개발자의 관점입니다.

미국은 다민족 다인종 국가이며 거대한 면적의 국토를 소유한  세계 최강대국 중의 하나이며 컴퓨터관련 기술이 가장 발달된 나라이기도 합니다. 미국은 그 넓은 땅 덩어리 만큼이나 다양한 사람들이 있으며 물론 소프트웨어 회사나 개발자들을 보면 그 실력에 있어서나 하는 일에 있어서도 매우 다양함을 알 수 있습니다.

우리나라는 작은 국토에 같은 민족으로 구성된 사람들이 비숫한 교육을 받고 자랍니다. 따라서 사고방식도 비숫하고 개개인의 개성이나 성격 그리고 업무를 하는데 있어 실력차이도 그다지 큰 편차를 보이지 않습니다. 하지만, 모두 짐작하듯이 미국은 여러 민족이 모여 있으니 당연히 개개인이 매우 다른 점들이 많습니다. 따라서 미국인들은 개개인의 차이점을 존중하면서도 자신의 영역과 문화를 지키려고 노력합니다. 미국을 말할 때, 일단 이러한 한국과는 매우 다른 기본적인 문화적 차이를 이해해야  하겠습니다.

미국은 세계적으로 유명한 소프트웨어 회사나 개발자들의 대부분을 소유하고 있기도 합니다. 그러니까 컴퓨터 기술에 있어서는 종주국이라고 할 수 있겠죠. 그러나, 그렇다고 모든 사람이 첨단기술에 익숙한 것은 아닙니다. 첨단 기술에 종사하거나 하이테크 기술에 대해 잘 아는 미국인은 소수에 불과 합니다. 미국은 언제부터인가 국가적으로 IT산업을 발전시키려고 노력해왔으며 해외의 우수인력도 많이 받아들여 미국의 차세대 성장 동력으로 만들려고 한 것 같습니다.

미국에서는 한국과 같이 어주 어릴 때 부터 공부를 심하게 시키지 않습니다. 공부는 대학에서 가장 열심히 하게 되는데 그 때 자신이 원하는 분야에 흥미와 소질을 가진 학생들은 그 분야를 깊이 파고들 수 있는 기회가 주어지는 것 입니다. 한국에서는 대학에 가기 위해 엄청난 노력을 기울이고 일단 대학에 가면 그다지 열심히 하지 않는 것과는 반대입니다. 제가 느끼는 단점은 미국에서는 대학 이전까지 교육이 별로 대단치않고 한국에서는 자신 스스로 결정하고 노력하여 무엇을 하겠다고 하여 대학에 가는 사람이 적다는 것입니다.

회사에서 사람을 뽑는 것을 예로 들면 미국은 회사에서 필요한 어떠한 일을 수행할 능력이 있는가에 가장 큰 초점을 두고 사람을 뽑습니다. 한국도 요즘에는 비슷하지만 아직도 일단 괜찮은 사람을 뽑아 놓고 보자는 식이 많습니다. 물론 어느 편이 좋다 나쁘다고 단정할 수는 없습니다. 한국에서 하는 식의 동양적인 사고방식이 좋은 점도 많다고 생각합니다. 미국에서도 구글과 같은 회사는 좋은 사람이면 먼저 뽑아 놓고 일을 찾는 경우도 많습니다.

회사생활에 있어서도 한국은 인간 관계를 업무수행과 함께 매우 중요시되며 업무 중에 사적인 이야기나 잡담을 하는 경우도 많습니다. 미국은 회사에서 사적인 이야기나 잡담하는 일은 그리 많지 않습니다. 사실 그럴 시간적 여유가 많지 않습니다. 그리고 회식과 같은 회사 직원들끼리 정기적인 어울림도 매우 드문 편입니다. 공과사의 구별이 비교적 명확하여 회사에서는 최대한 바쁘게 일하여 빨리 업무를 처리하고 집으로 돌아가 자기 사생활을 즐기려는 경향이 강합니다.

미국에서 해고는 매우 자유롭습니다. 물론 퇴사도 자유롭습니다. 회사가 어렵거나 능력이 안되는 사람이 있다고 판단되면 가차없이 해고합니다. 또, 사원도 돈 더 준다는 회사가 있으면 별 눈치 보지 않고 옮겨가는 경우도 종종 있습니다. 한마디로 어느 정도 투명한 인력시장이 형성되어 있는 것입니다. 여기에 좀 비인간적인 면도 있지만, 효율적인 면도 있습니다.

미국에서 소프트웨어 개발자로 일하는 것은 한국에서와 완전히 다르지는 않습니다. 오히려 코딩을 하는 과정은 매우 비슷합니다. 좀 다른 점이라면 일이 매우 세분화 되어 있고, 앞서 얘기한 바와 같이 사람을 뽑을 때도 해당 업무를 할 수 있는 능력이 있는 사람을 찾아 뽑으려는 경향이 강합니다. 그리고 개개인에게 주어진 업무 영역에 집중하게 만들어 주려고 합니다. 한국에서는 개발 스케줄 자체도 매우 빡빡하고 개발자가 자신이 맡은 부분 외의 여러가지 부수적인 업무가 생겨나는 경우가 많습니다. 그리고 일단 결과를 보여주기 위해 빠른 속도의 코딩을 요구하며 프로그램 내부의 데이터 구조나 알고리즘을 최적화할 시간은 별로 주어지지 않는 편이고 무시되는 경우가 많습니다. 아마도 이점에서 미국이 좀 더 체계적인 개발 프로세스를 가지고 있다고 보여지는군요.

미국에서는 석박사 학위를 갖고도 40대 50대까지 그냥 프로그래머로 일하는 사람이 꽤 많습니다. 우리 나라는 나이와 직위라는 것이 매우 중요해서 일단 나이가 많거나 학위가 높으면 직위도 높아야하고 년봉도 많아야만 합니다. 실력이 좋든 안좋든 말이지요. 미국에서는 수직적 직위보다는 역할에 따른 타이틀이 붙습니다. 즉 xxx engineer, xxx associate, xxx manager, xxx specialist 등등입니다. 물론 group manager, vice president, ceo 이러한 타이틀은 직위가 높고 년봉도 많이 받겠지만 한국처럼 대리, 과장, 차장, 부장 등등 으로 마치 계급처럼 따라 붙지는 않습니다.

엔지니어의 경우는 사람관리, 프로젝트 관리와 같은 매니지먼트 역할을 하기 싫어하고 자신에게 주어진 개발에만 몰두하려는 사람들이 있는데 이러한 사람들은 은퇴할 때 까지도 그냥 엔지니어로 남습니다. 아무리 자신의 매니저라고 자신을 부리는 상사로 생각되진 않습니다. 보다 합리적인 시스템이라고 할 수 있죠. 우리나라에서와 같이 "시키면 한다"식은 좀 덜한 편입니다.  또, 한국회사의 경우 프로젝트를 관리하는 프로젝트 매니저와 그 보다 윗단계인 사람을 관리하는 매니저의 구분이 명확치 않습니다만, 제가 본 미국 소프트웨어 회사는 이런 구분이 보다 명확합니다. 프로젝트 매니저는 프로젝트의 일정이나 작업을 분류하고 개인에게 할당하는 임무를 맡습니다.  사람을 관리하는 매니저는 년봉과 같은 대우 문제, 동료나 다른 직원들간의 트러블을 상담해주는 사람입니다.

일이 마음에 들지 않거나 뭔가 잘못되었다고 생각되면 누구든 함께 토론하여 합리적인 결론을 이끌어 내려고 하는 토론 문화가 보다 발달되어 있다고 생각되는군요.

개발자들이 자존심이 센 것은 한국이나 미국이나 마찬가지 입니다. 실력이 좋을수록 자존심이 세지고 남에게 지기 싫어하는 것은 미국 개발자들이 더 심하다고 할 수 있습니다. 특히 그들은 학창시절 동안 이른바 사회성이 부족한 Geek이나 Nerd라 고 불리우며 때로는 놀림을 당하며 컴퓨터에만 매달린 사람들이 많습니다. 자신의 실력은 곧 년봉으로 연결되므로 다른 개발자보다 잘나기 위해 부단히 노력해야만 합니다.  해고가 자유로운 미국에서는 잘리지 않기 위해서라도 부단한 자기개발은 필수입니다.

그런데, 소프트웨어가 복잡해지고 일도 세분화 되면서 모든 면에서 최고인 천재 개발자는 사실 거의 불가능해졌습니다. 결국은 어떤 한 분야에서 뛰어나고 오랜 경험을 가진 사람들이 인정받고 년봉도 많이 받게 되는 것 같습니다.

마이크로소프트와 IBM과 같은 거대 기업을 살펴 봅시다. 이곳에는 세계적으로 내노라 하는 개발자들이 많이 모여 있습니다. 하지만, 각자의 맡은바 임무는 매우 세분화 조직화되어 자신의 영역이 아닌 부분을 자세히 알기도 힘듭니다. 큰 회사들에서 소프트웨어 개발은 점점 자동차나 비행기와 같은 복잡한 기계를 조립 생산하는 것과 같은 프로세스로 일반화 되어 가고, 개발자는 그 조그만 파트의 일부분을 담당하게 되어 가고 있습니다. 이것은 소프트웨어 분야가 이제 초창기 발전 단계를 벋어나고 있다는 것을 말합니다. 새로운 것을 모두 처음부터 끝까지 해볼 수 있는 즐거움은 점점 찾기 어려워지고 있기도 하지요.

미국의 IT회사들은 아직도 비교적 높은 이직률로 인하여 회사 내부의 많은 정보가 결국 사람을 따라 여러 회사를 돌고 있습니다. 다른 직종도 마찬가지지만, IT에서는 사람이 가장 중요하다고 하겠습니다. 미국 개발자들의 능력과 지능은 한국 개발자와 큰 차이는 없습니다. 오히려 일반인을 기준으로하면 대다수가 대학 교육을 받는 한국인들이 평균지능이 우수할 것입니다. 하지만, 누구나 자신의 능력을 최대한 발휘할 수 있으려면 주어진 인프라 혹은 환경이라고 할까요 이러한 것이 매우 중요합니다. 미국을 보면 IT기업들이 많이 있는 몇몇 도시는 그 도시 분위기 자체도 엔지니어 냄새가 납니다. 그리고 개발자에 대한 대우도 경험과 능력에 따라 다양하게 주어지고 비교적 나쁘지 않습니다. 이러한 환경은 자신의 업무에 보다 더 집중할 수 있도록 만들어 주는 것 같습니다.

  1. arribamission 2008.08.18 05:04 신고

    좋은 관찰력을 가지셨군요. 글 감사합니다. 종종 들어와서 읽겠습니다.

  2. Digital Angel Master 2008.08.18 06:36 신고

    arribamission // 출처를 따라가 보시면 좋은 정보를 많이 얻으실 수 있을듯 합니다.

Source : http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=32305

 

개발자들이 잠을 줄여 가며 열심히 일을 하는 데도 왜 개발 프로젝트는 늘 납기를 못 맞추고 비용을 초과하고 또 생각지도 못 한 인적/물적 리소스를 투입해야 하는 걸까? 이 질문을 하니 떠오르는 예가 있다. 호랑이 담배 피던 시절, 병이 나면 무당을 찾아 가서 주술과 신의 힘으로 병을 고치려 했단다. 무당이 드물게 영적 능력이 뛰어나거나 여러분이 착한 일을 많이 해서 신이 돕는다면 분명 뭔가 효험이 있었을 거다. 그렇지만 대부분의 경우는 ‘원인’을 밝혀 ‘치료’를 하는 게 상식이다. 위가 아프다면 위 염증 여부를 확인하고 염증을 없애는 게 답이다. 아직도 우린 소프트웨어 개발 프로젝트에 한한 한, 뭔가 잘못 되면 무조건 ‘개발자’만 탓하는 호랑이 담배 피던 시절에 머물고 있는 것은 아닐까? 영어 공부도 영어 공부지만 이런 아픈 현실을 잘 꼬집어 소개한 책이 있어서 일부 내용을 여기서 소개한다. ‘소프트웨어 개발 팀에서 성과를 이끌어 내는 비결’(가칭)(Getting Results From Software Development Teams, Microsoft Press 2008)에서 로렌스 피터스(Lawrence J. Peters)는 소프트웨어 엔지니어링 분야에서 40년을 일한 베테랑으로써 자신의 경험에서 우러나오는 ‘진실’을 들려 준다.

기영모 helenjoh1@dreamwiz.com|기술과 영어를 공부하는 모임이다. 개발자와 마케터가 함께 모여 기술과 영어를 교환하며 공부하는 모임으로 현재 MSDN magazine과 그 때 그 때 관심 있는 영역의 아티클을 공부하고 있다.

Myths Associated with Software
소프트웨어 개발 프로젝트의 12가지 오해

 

Myth #1: Software easier to change than hardware.
첫째, 소프트웨어는 하드웨어보다 변경 및 수정하기가 쉽다?

This Myth is more common and more counterintuitive than most managers would care to admit. At first glance, changing software looks a lot easier than changing hardware. For example, how easy would it be to change Hoover Dam? Not very.
이 오해는 사회적 통념으로 통용되고 있고 직관에 반하는 내용임에도 불구하고 대부분의 프로젝트 매니저들이 생각하는 것보다 더 많이 퍼져 있다. 언뜻 보아 소프트웨어를 변경하는 것이 하드웨어를 변경하는 것보다 훨씬 쉬워 보인다. 예를 들어, 후버 댐을 바꾸는 게 쉬울까? 그렇게 쉽지는 않을 것이다.

So what about software? The problem is that we take the ease-of-change issue for granted; we ?ee?solutions early on and often begin programming without really understanding the problem we are trying to solve and without looking to the future. The Year 2000 problem was a perfect example. People just did not realize that what they built in 1980 might still be in use in the year 2000. Furthermore, they took great pride at that time in achieving storage savings by storing only a two-digit number rather than a four-digit number to represent the year. A simple analysis or survey would have shown that a lot of software used in 1980 had been written much earlier, and it would be too expensive to replace it all every 20 or so years.
그럼, 소프트웨어를 바꾸는 건 어떨까? 소프트웨어를 바꾸는 게 쉽다는 통념을 당연한 것처럼 받아 들이는 데 근본적인 문제가 있다. 즉, 해결해야 하는 문제의 본질을 이해하려고 노력하거나 미래에 닥칠 문제들을 고려함 없이 초기에 ‘해결책’이라고 속단하고 종종 프로그래밍을 시작한다는 것이다. Y2K 문제가 대표적 예다. 1980년에 만든 소프트웨어를 2000년에도 계속 쓰게 될 거라는 걸 미처 생각지 못 한 거다. 어처구니없게도 당시에는 연도를 표기하기 위해 네 자리를 쓰는 것보다 두 자리를 쓰는 게 스토리지를 절감해서 좋다고 자랑스럽게 생각했다는 것이다. 간단한 분석이나 조사만 했더라도 1980년대의 많은 소프트웨어들이 훨씬 이전에 만들어 졌을 뿐만 아니라 그걸 20년마다 대체하는 게 매우 어려운 일이고 고비용이 든다는 것을 알았을 것이다.

 

Myth #2: We?e in maintenance mode, and it? rare that we write something new, so we don? need to measure what we?e doing, gather statistics, or define processes.
둘째, 늘 유지보수 모드이기 때문에 새로운 것을 만드는 건 드물다. 그러니, 우리가 뭘 하든 평가를 한다거나 이것을 통해 통계를 내거나 혹은 프로세스를 규명할 필요가 없다.

 

Myth #3: We don? need to document the code by including comments, because any proficient programmer can tell what the code does by looking at it.
셋째, 코멘트를 포함해서 코드에 대해 문서화할 필요가 없다. 이유는, 능력 있는 개발자라면 한 눈에 그 코드가 어떤 내용인 지 바로 알 수 있기 때문이다.

 

Myth #4: Quality can be tested into the system-What we should do is get it coded as rapidly as possible and then test it as thoroughly as possible.
넷째, 소프트웨어의 품질은 시스템에서 운영하는 단계가 되어야 테스트될 수 있다. 그래서 가능한 한 빨리 코딩을 끝내고 통째로 테스트하면 된다.

 

Myth #5; Why bother performing analysis and design? After all, the code, not these preliminary documents, results in a marketable product.
다섯째, 소프트웨어를 개발할 때 분석과 설계는 신경 쓸 필요 없다? 이런 문서는 중요 하지 않고 제품이 되는 것은 결국 코드이기 때문에 코드만이 중요하다.

Subscribers to this myth really don? understand the roles that analysis and design have played in engineering for more than two thousand years. There is evidence that the Romans built models, drew the equivalent of blueprints, and otherwise labored over a project before executing it.
이런 오해를 진실로 믿는 사람은 지난 2천년 동안 엔지니어링 분야에서 ‘분석과 설계’가 얼마나 중요한 역할을 해왔는지를 이해 못 하는 사람이다. ‘로마는 하루 아침에 이뤄진 것이 아니다’라는 말이 바로 증거다. 로마를 짓기 전에 분명히 상세계획을 세우고 프로젝트를 위해 많은 노력을 기울였기에 오늘 날의 로마가 생겨난 것이다.

 

Myth #6: We don? need a quality assurance group-we hire smart people, and they don? make mistakes.
여섯째, 품질보증팀(Quality Assurance)은 필요 없다. 그냥 뛰어난 인재를 뽑아서 쓰면 된다. 왜냐면 그들은 결코 실수를 하는 법이 없기 때문이다.

 

Myth #7: Increasing their compensation gets software professional to perform at a higher level.
일곱째, 프로 개발자들이 일을 더 잘하게 하려면 돈만 많이 주면 된다.

상세한 내용은 기회가 되면 책을 읽어 보기 바란다. 미국도 한국과 마찬가지인가 보다는 위안을 찾을 수 있다. 외국 개발자들도 사생활 없이 개발 프로젝트를 하고 있는 게 현실이란다. 그리고, 대부분의 매니저들은 돈만 올려 주면 개발자들이 그런 삶을 지속하면서 심지어 더 잘 일할 거라고 잘못된 생각을 갖고 있다고 한다.

 

Myth #8: The way to encourage people to get into management is to give them special perquisites.
여덟째, 개발자로 하여금 매니저가 되게 하는 길은 특별보너스를 주는 것이다.

 

Myth #9: Software processes are great, but when the project is behind schedule, we don? have time for such things.
소프트웨어 개발 프로젝트의 프로세스는 완벽하다. 그렇지만 프로젝트가 일정을 못 맞추고 있다면 프로세스를 따를 시간이 없다.

 

Myth #10: The marketplace requires that we get to market as quickly as possible. Using some sort of prescribed method or process is just going to slow things down.
열, 경쟁력을 유지하려면 가능한 한 빨리 시장을 공략해야 한다? 규정된 방법과 프로세스를 따르는 것은 시간을 빼앗을 뿐이다.

 

Myth #11: There is so much software out there that either is included with various development environments or can be licensed inexpensively-we can employ it and write very little new code.
열 하나, 다양한 개발 환경 제공하면서 저렴한 소프트웨어는 많이 있다? 그저 그걸 도입해서 조금만 고쳐 쓰면 된다.

 

Myth #12: If we institute processes into this organization, people will either leave the company or become unproductive.
열 둘, 학습 프로세스를 도입하면 결과적으로 개발자들은 회사를 떠나거나 생산성이 떨어진다.

Source : http://imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=32089

 

오늘도 개발자들은 고객의 요구사항에 따라 프로그램을 개발한다. 개발하는 틈틈이 최신 기술을 공부하면서 더 효율적이고 생산적으로 개발하는 방법을 익히고자 한다. 필자는 이 글을 통해 앞만 보고 열심히 일하는 개발자들에게 거시적인 관점에서 우리들의 주변 환경이 어떻게 돌아가고 있는지를 되돌아볼 시간을 마련해 주고자 한다.

한 용 희 woom33@korea.com
롯데정보통신 정보기술연구소에 재직 중이며, 닷넷 기반의 여러 프로젝트에 참여했다. 현재 Microsoft Visual C# MVP이며 MSDN 세미나 강사로도 활동 중이다. 처음에는 2D, 3D 게임 프로그래머로 시작하여 SQLServer 튜닝, 응용 애플리케이션 개발에 이르기까지 다양하게 경험하였으며, 주요 관심사는 DB와 애플리케이션의 연동 부분이다.

 

어렸을 적부터 필자는 개발하는 일 자체가 즐거웠다. 내가 어떤 것을 만들 수 있다는 것 자체가 매우 흥분되고 재미있는 일이었다. 기존의 장난감에는 창의력을 불어 넣을 수 없었다. 레고 블록과 같이 모양이 정해진 부품으로는 완전히 새로운 창작물을 만들 수 없었다. 하지만 프로그래밍은 훨씬 더 새로운 작품을 만들 수 있어서 좋았다. 필자는 그렇게 프로그래밍의 재미라는 것을 느꼈고 그 순간부터 커서 개발자가 될 것이라고 마음에 꿈을 가졌다.

프로그래밍의 재미를 알고부터는 시간이 나면 틈틈이 프로그래밍을 했다. 이러한 재미가 직업이 되면서부터 일은 필자에게 돈을 버는 수단인 동시에 재미를 느끼는 수단이 되었다. 하지만 언젠가부터 개발이라는 작업이 내가 원하는 것만 만들 수 있는 것도 아니었고, 내가 원하는 시간에 내 마음대로 혼자서 할 수 있는 것도 아닌 그런 존재가 되었다. 개발이라는 것이 결코 혼자만의 예술 작품이 아니었던 것이다.

필자는 대학 때까지 열심히 프로그래밍 기술을 익히고 기술 공부에 매진했다. 그러다가 지금의 SI 업체에 입사하게 되었는데, 그때 인사과장님이 하시던 말씀이 생각난다. “앞으로 여러분은 회사에 들어가서 열심히 업무를 배워야 합니다. 기술도 중요하지만 앞으로 하게 될 회사 업무(인사, 구매, 회계, 생산, 영업 등)를 파악하는 것이 더 중요합니다. 고객이 원하는 것을 알아야만 개발도 효과적으로 할 수 있기 때문입니다.” 그동안 기술 공부만 열심히 해왔던 필자에게는 충격적인 말이었다. 내가 지금껏 ‘헛공부’를 했단 말인가?

개발자로서 선택할 수 있는 다양한 진로가 존재한다. 대표적인 것이 바로 IT 제조업과 IT 서비스업이다. IT 제조업은 제품을 만드는 것이므로 기술 자체가 중요할지 모르겠다. 하지만 IT 서비스업은 서비스를 만드는 것이므로 그 해당 업무를 잘 아는 것이 더 중요했던 것이다.

필자는 회사에 들어가서 제일 먼저 회계 업무를 맡았다. 개발하는 것 자체에는 아무런 문제가 없었지만 현업이 요구하는 것을 개발하는 데 문제가 생겼다. 회계 업무를 모르다 보니 현업이 하는 말을 알아들을 수 없었고, 현업이 원하는 바를 이해해서 원하는 것을 정확하게 만들 수 없었다. 이때부터 회계 공부를 시작했다. 당장 회계학과 대학생들이 본다는 『회계원리』라는 책을 사서 공부를 시작했다. 하지만 처음부터 회계용어가 눈에 들어올 리가 없었다. 난생 처음 듣는 어려운 용어가 많았다. 그때마다 회계과 직원들의 도움을 받고, 스스로 다른 책도 찾아가면서 회계 공부를 했다.

처음에는 어렵기만 했던 회계 용어가 차츰 눈에 익고, 점점 업무 영역도 확대되어 갔다. 회계, 그룹웨어, 인사 등 여러 업무를 조금씩 하다가 이제는 직접 개발하기보다는 관리, 기획하는 업무의 비중이 점점 늘어가는 것을 느끼게 되었다. 바야흐로 개발자로서 선택의 갈림길이 나타난 것이다. 계속 개발자로 남느냐? 아니면 관리직으로 가느냐?

한국에서 개발자로 살아가기

개발자로 살아가다 보면 국내에서는 개발자로 살아가기가 힘들다는 소리를 여기저기서 많이 듣게 된다. 지난해 8월 자바개발자협의회(JCO)는 한국의 개발자 1,891명을 대상으로 설문 조사를 실시한 바 있다. 그 결과에 따르면 국내 소프트웨어 개발자의 72.2%는 45세까지(특히 58%는 40세까지)만 개발 업무를 계속하겠다고 응답했다. 대다수가 개발자의 수명을 40세 초반으로 바라보고 있는 셈이다. 경력 분포 면에서는 10년 이상된 개발자가 전체의 9.5% 밖에 되지 않아서 대부분이 경력이 짧은 초중급 개발자로 이뤄져 있음을 알 수 있다. 그만큼 숙련된 개발자가 부족하다는 의미이다.

개발자의 근무 실태를 보면, 응답자의 85%는 주2회 이상 야근을 하며 매일 야근하는 개발자도 28%나 되었다. 하지만 이들에게는 초과 근무 수당이 없는 경우가 대다수였다. 한 예로 노동부에서 2007년 6월부터 서울 지역 IT 업체 104곳을 점검한 결과, 93개 업체가 근로자의 수당을 미지급해서 시정 명령을 받았다고 한다. 

과거 2005년도에는 포털 서비스인 다음의 토론광장(아고라)에 ‘영재들아, 제발 IT로 오지마라’라는 글이 게재되어 한창 화제가 되기도 했다. 이 글은 한국 IT 개발 환경의 문제점을 적나라하게 표현해서 IT 종사자들 사이에서 대단한 관심을 끌었다. 이런 우울한 글을 보고 나면 정말 개발자로 남아서 살아가야 하는지 자신이 없다. 유독 한국의 개발자만 이렇게 고생하는 것은 아닐까?

임금 수준으로 본 우리 IT

이럴 때에는 선진국의 사례를 살펴보면 도움이 된다. 필자는 우리나라보다 IT 산업이 성숙한 미국의 자료를 찾아보기로 했다. PayScale이라는 연봉 정보 공개 사이트에는 각 직업의 연봉 정보가 공개되어 있다. 먼저 미국의 연봉 정보를 보자.

Array
<화면 1>에서 뜻밖에도 고급 개발자(Sr. Software Engineer / Developer / Programmer)의 연봉이 최고 수준으로 나와 있음을 볼 수 있다. 이 사이트에는 한국의 연봉 정보도 함께 소개되어 있다. 비록 등록된 정보가 얼마 없어 절대적인 기준으로 삼기는 어렵지만 그냥 참고용으로는 볼만 하다. <화면 2>는 한국의 연봉 정보를 나타낸 그래프다.

Array
이 자료에는 구체적인 수치가 나와 있진 않지만, 개발자의 임금 수준이 꽤 낮은 수준임을 짐작할 수 있다. 한국소프트웨어진흥원에서 한미일 3국의 소프트웨어 개발자 월평균 임금(2003년 기준)을 조사한 자료가 있는데 그 결과는 <표 1>과 같다.

Array

<표 1>은 해당 국가의 물가를 고려하지 않고 임금을 단순 비교한 자료이므로 이것으로 절대적인 비교는 어렵지만 대략적으로 보면 미국의 임금이 한국의 3배에 이른다. 단순 절대 임금의 비교보다는 상대적 임금 수준을 비교하기 위해 임금 프리미엄이라는 지수를 사용한다. 임금 프리미엄이란 현재 임금에서 기회 임금을 뺀 것으로 그 직업의 상대적인 임금 수준을 측정할 때 유용하다. 즉, 내가 IT 직업을 가짐으로써 다른 직업을 가졌을 때보다 더 많이 받는 수준이 임금 프리미엄이다.

정보통신정책연구원에서 2003년도 발간된 자료를 보면 한국 IT 산업 근로자의 임금 프리미엄은 10%, IT 직종 종사자의 임금 프리미엄은 IT 전문직이 61%, 준 전문직이 11%, 생산직이 3%였다. 반면에 미국 IT 산업 종사자의 임금 프리미엄은 110.8%로 나와 있다. 즉, 미국에 비해서는 그만큼 한국의 IT 직종 종사자가 상대적으로 임금을 덜 받고 있음을 알 수 있다.

근로 환경은 어떤가?
ww.esj.com이라는 사이트에 가보면 미국 IT 종사자에 대한 설문조사 결과를 볼 수 있다. 가장 최근의 자료는 2007년 10월에 조사한 것으로, 이 가운데 먼저 직업 만족도를 보면 <표 2>와 같다.
Array

미국의 IT 종사자들은 갈수록 직업 만족도가 떨어지기는 하지만 대체적으로 직업에 만족하고 있음을 알 수 있다. 그럼 이번에는 직업 안정성에 대해 알아보자. 이는 자신의 직장에서 퇴직 당하지 않고 얼마나 안정적으로 일할 수 있는지에 대한 설문조사 결과이다.
Array

<표 3>을 보면 대체적으로 직업 안정성이 높음을 알 수 있다. 마지막으로 주당 근무 시간에 대한 설문 조사 결과는 <표 4>와 같다. 
Array

아무래도 직원보다는 관리자가 더 업무를 오래하는 편인데, 직원들의 주당 근무 시간은 평균 43시간으로 조사됐다. 9시 출근 6시 퇴근이라 하고 점심시간 1시간을 제외하면 일일 근무시간은 8시간이다. 이는 주5일제라고 할 때 주당 40시간이 된다. 미국에서 43시간이라는 것은 결국 어느 정도 야근을 한다는 것을 의미한다.

그럼 우리나라의 경우는 어떨까? 2004년 전국IT산업노동조합연맹이 실시한 실태조사에서 소프트웨어 종사자들의 주당 평균 근로시간은 57.8시간이었다. 이는 미국과 비교해 보면 많은 차이를 나타내는 결과다. 결국 한국에서 개발자로 살아가는 것이 힘들다고 말하는 데에는 이런 이유가 있는 셈이다.

산업 분류에 따른 IT 전망

|앞서 말한 바와 같이 IT 산업은 크게 IT 제조업과 IT 서비스업으로 나눌 수 있다. 이중 우리나라는 IT 제조업의 비중이 매우 높은 편이다. <표 5>는 2005년도 IT 부문별 부가가치 및 고용 비중을 나타낸 것이다.

Array

한편 미국의 경우는 <표 6>과 같다.

Array

미국의 경우 IT 서비스업의 부가가치가 더 크고 인력도 더 많은 것으로 조사됐다. 하지만 우리나라의 경우에는 IT 제조업의 부가가치가 더 크고 인력도 더 많은 것으로 나타났다. 우리나라는 아직까지 IT 산업에 있어서 제조업의 비중이 더 크다는 의미다.

미국의 경우 IT 서비스업의 부가가치나 인력이 더 많은 것은 서비스 부문에서 IT를 활용한 전산화가 생산성 향상을 가져왔기 때문이다. 미국도 1995년 이전에는 제조업의 생산성이 서비스업보다 더 높았다. 하지만 IT 기술이 발전한 1995년 이후에는 IT 기술을 활용한 서비스 분야의 전산화를 통해서 생산성이 크게 향상됐다.

Array

반면에 우리나라의 경우 2000년대 들어 IT 생산 부문은 노동생산성 향상에 크게 기여하고 있으나, IT 이용 서비스의 경우에는 오히려 기여도가 하락하고 있다.

<그림 1>을 보면 우리나라는 생산성을 높이는 데 있어 IT 이용 서비스업의 기여도가 떨어지고 그 비중 또한 작다. IT 제조업의 경우 각종 IT 제품을 통해서 생산성 향상을 가져오는데 반해, IT 서비스업의 경우는 소프트웨어를 통해 업무의 효율화를 가져와야 하는데 그 비중이 작다는 것이다.

우리 개발자의 미래

과거 미국의 경제가 일본에 추월당했다는 소리가 있었지만 미국은 IT를 통한 기술 발전에 힘입어 생산성의 향상을 가져왔고 다시금 경제에 활력을 되찾았다. IT 산업이 경제 성장의 밑거름이 된 것이다. 특히 IT 서비스업의 경우 IT 제조업보다 더 큰 부가가치와 고용 증대 효과를 가져왔다.

Array

앞으로 우리나라도 경제가 더욱 성장하기 위해서는 미국이 그랬던 것처럼 각 산업에서의 생산성 증가가 이뤄져야 한다. 이러한 생산성 증대는 앞으로는 IT 기술을 통해 이뤄질 것이다. 특히 그동안 등한시되었던 IT 서비스를 통한 서비스업의 생산성 증가가 앞으로 중요한 이슈가 될 것이다. 이에 따라 IT 서비스업을 담당하는 소프트웨어 개발자가 앞으로는 더욱 많이 필요해지고 중요한 인력이 될 것으로 보인다.

앞서 살펴본 것처럼 우리나라에서 개발자에 대한 처우는 미국에 비해 그리 좋은 상황은 아니다. 하지만 앞으로 우리가 미국의 모델을 따라 IT 빅뱅을 통한 경제발전을 이룩한다면 소프트웨어 개발자는 그 주요한 원동력이 될 것이다. 필자는 그때쯤이면 우리나라의 개발자도 미국의 그들처럼 대우받지 않을까라는 나름대로 긍정적인 희망을 가져본다.

참고 자료

1. 자바개발자협의회 커뮤니티, http://www.jco.or.kr
2. 미국 연봉 정보 사이트, http://www.payscale.com
3. SW인력 임금수준의 국제 비교 - 한국소프트웨어진흥원(박능윤), http://www.software.or.kr
4. IT 인력의 취업률, 전공종사율, 임금수준에 대한 연구 - 정보통신정책연구원, http://www.kisdi.re.kr
5. Enterprise System, http://www.esj.com
6. 주력성장산업으로서 IT 산업에 대한 평가와 시사점 - 한국은행, http://www.bok.or.kr

Source : http://www.zdnet.co.kr/itbiz/reports/trend/0,39034651,39167780,00.htm

 

이 글을 보시는 여러분들 중에 CRM라는 단어의 의미를 모르시는 분들은 없으리라 생각이 듭니다.
본 칼럼에서는 CRM과 관련된 기본적인 이론부터 접근해서 실행과 관련된 이슈들을 소개하는 자리를 마련해 보려고 합니다.
특별히 데이터를 중심으로 편성된 eCRM(웹 로그 포함) 분야로 제한하고 말씀드리지는 않겠습니다.
다만 정리된 내용들의 기반은 데이터를 분석하고 해석하는 부분이 많기 때문에 온라인과 관련된 내용이 많다는 점은 분명히 밝혀둡니다. 적어도 설명을 드릴 때 자료의 논리성을 확보하려면 저 역시 데이터에 기반한 논리가 필요하기 때문입니다.
자, 시작해 볼까요?
수익의 극대화라는 절대명제를 가진 기업에서는 궁극적으로 아래의 CRM 구조를 잘 만드는 것이 목표입니다.

Array

오래된 자료이긴 합니다만, CRM의 대부분을 설명할 수 있는 그림 한 장을 뽑으라면 저는 이 그림을 추천해 드립니다.
(1번) 고객상호 작용
(2번) 고객식별
(3번) 고객접근 기록
(4번) (고객에게)적당한 오퍼(보상, 서비스) 결정
(5번) 오퍼(보상, 서비스) 실행
1번부터 3번까지를 ‘고객인지’ 부분이고, 4번부터 5번까지는 ‘고객응대’라고 보셔도 될 것 같습니다. 1번부터 5번까지의 모든 프로세스를 디지털화하여 운영하고 있는 기업도 있고, 직접 손님을 맞이하여 서비스를 제공하고 보내는 아날로그 기업도 있습니다. 또는 일부는 디지털, 나머지는 아날로그 등등 어떠한 형태로든 설명이 가능합니다.
문제는 여기서부터 시작이고 각 단계에서 얼마만큼 효율적으로 대응하는 하는가를 한번쯤 고민해 봐야 할 대목입니다.
Case1) 우리 식당에서는 고객이 방문도 많고 인사도 잘하는데(1번 고객상호작용) 단골 손님들은 없는 거 같네(4, 5번 고객 보상이나 서비스)?
Case2) 우리 웹 사이트 방문자수(3번 고객접근기록)는 감소하는 것 같은데 매출은 그대로네? 사이트 방문이 느는 것 하고 구매 고객(2번 고객식별)의 매출하고는 아무 상관없나 보다.
Case3) 월 매출이 성장해서 기분은 좋은데 이유가 뭐지?
다음으로 생각해 볼 것은 위의 그림에서 효율성 극대를 위해서 문제점을 적극적으로 해결할 수 있는 방안을 모색해야 하고 더 나아서는 각 단계별 처리 속도(고객대응)와 적재적소에서의 리소스 활용이 필요합니다. @

2. 고객알기
숨 고르기, CRM 알고 가자
기업에서의 CRM은 활동은 지난번 소개 드렸던 그림과 같이 순환구조(Closed-Loop)로 이해하셔야 하고, 순환구조의 개선이나 각 단계별로 병목현상이 발생하지 않게 하는 게 가장 중요하다고 볼 수 있겠습니다.
이번 시간의 주제는 “고객알기”입니다.
많은 기업들이 고객에 대한 정보를 획득(Acquisition)하기 위하여 노력하고 있습니다. 하지만 어디서부터 손을 대야 할지, 또는 고객과 관련된 데이터 너무 복잡하거나 많거나 하는 이유로 실제 고객과 관련된 정보에 안테나를 세우고 분석하는 업무담당자는 많지 않은 것 같습니다.
더욱이 오늘날 고객과 관련된 정보는 내부에도 있고 외부에도 많이 존재합니다. 컨설팅 업무를 진행하다 보면 랭키닷컴에 데이터로 이용자들이 경쟁사와 자사를 중복 방문하는 숫자가 점차 증가되고 있는 것을 보아도 쉽게 예측이 가능한 부분입니다.

Array

위 표의 왼쪽은 자사 내부에서 관리 하고 있는 정보들입니다. 인구통계학 정보는 기본적으로 사이트에 가입하는 시점에서 기본적으로 획득 가능한 정보이며, 이용행태와 고객성향정보는 웹 로그 분석이나 내부 운영정보에 Transaction(거래발생시 기록되는 정보)로 기록관리가 됩니다.
고객 등급 정보는 기업에 따라서 있는 경우도 있고 부분적으로 있는 경우도 있습니다. 마지막으로 고객 불만사항 정보는 Call Center나 ARS 또는 내부 Q&A를 통해 접수되는 정보들이 되겠습니다.
우측은 외부 고객 정보입니다. 기업에서 외부정보의 중요성은 점차 증대되어 가고 상황이며, 외부 고객 정보를 얻기 위해 다양한 리서치나 컨설팅, 그리고 최근에는 RSS를 통한 커뮤니티정보 획득과 커뮤니티 정보를 얻기 위한 솔루션까지 등장하고 있는 상황입니다.
이 시점에서 귀사의 고객정보들이 현재 파편정보로 획득되고 있지는 않은지, 혹은 이질적인 정보들로 인한 혼선이 생기지 않는지 판단해야 합니다.
좀더 심화하여 고객을 깊게 이해하기 위한 방법 몇 가지를 정리해 보았습니다.
첫째, 내부자료 검토
‘등잔 밑이 어둡다’는 말처럼 지금도 고객사에 방문하여 보면 내부에 엄청난 자료들이 있습니다. 특히 매출과 관련된 자료들은 다양한 분석을 하여 보고서로 활용하고 있습니다. 여기서 말하는 내부자료 검토란, 현재 매출과 상품위주로 구성된 보고서의 내용을 고객과 연결시켜 재검토 하자는 의미입니다.
예를 들어 ‘2007년 11월 A상품이 전월 대비 23% 증가하여 매출의 주요 점유율을 차지하였다.’ 라는 관점에서 ‘A상품은 신규고객의 매출 비중이 높음 상품’ 등의 고객과 관련된 정보를 함께 정리하는 방식입니다. 고객에 관련된 정보를 수록하는 것은 대상 고객층에 대한 마케팅 기획이나 대응논리를 전개해 나갈 수 있는 중요한 논리가 되기 때문입니다.
둘째, 원천 데이터를 분석해 보자
원론적인 이야기가 될 수도 있겠지만 고객의 가치를 산정하는 방식 중에 RFM(Recency, Frequency, Monetary) 방식이 있습니다. 고객 한 명에 대해 매출이 일어나는 시점을 기준으로 하여 최근성, 빈도, 금액의 가중 점수를 부과하여 고객의 점수를 산정하는 방식입니다.
RFM의 점수가 높다는 것은 자주 구매하거나 많은 매출을 발생시키거나 최근에 해당 상품을 인지하는 것을 의미합니다. 물론 기업들은 이러한 방식을 그대로 적용하지는 않습니다. 적용해야 될 변수들이 늘어났고, 이러한 측정치 만으로는 고객을 이해하는 것이 쉽지 않기 때문입니다.
그러나, 저는 이러한 데이터를 분석해 볼 것을 권합니다. 실제 데이터 가지고 분석을 하게 되면 고객에 대한 R/F/M 등과 같은 측정정보들에 대한 분포를 이해 하 실 수 있습니다. 고객들의 평균 객단가 수준이나 방문빈도 정보는 마케팅 기획업무를 하시는데 유용한 정보로 활용이 가능하고 이러한 측정지표를 가지고 응용하여 고객 세분화에 적용 하는 것이 가능합니다.
셋째, 외부 데이터 이용
고객 알기와 관련된 외부 데이터 이용에서는 일단 자사 이외에 고객의 프로파일 정보를 취득이 불가능 합니다. 다만, 고객들의 이용행태와 관련된 정보와 산업적인 특성 정보는 획득 가능한 정보입니다.
현재 랭키닷컴(rankey.com)에서는 기업에서 필요한 다양한 정보들을 제공하고 있습니다.
랭키통계 정보, 사이트 집중분석, 순위동향, 랭키순위 정보는 언제든지 열람이 가능한 형태로 제공되는 정보입니다. 보다 심도 있게 경쟁사와의 비교분석을 원하실 경우는 Insight2(ASP형태의 고급 데이터 제공 서비스)와 컨설팅 서비스(정량/정성분석 등)로 이용이 가능합니다.
넷째, 고객정보의 뷰(View) 작성
구슬도 꿰야 보배가 되듯이 고객과 관련된 정보 역시 정리가 필요합니다.
아래 그림은 고객을 중심으로 한 데이터의 관점을 정리한 것입니다.

Array

크게 4가지 주제로 고객과 프로모션, 고객과 가치, 고객과 트래픽, 고객과 거래 나눌 수 있으며, 보고서를 작성하거나 내부 리포트를 만드실 경우에 참조로 활용 하시기 바랍니다.
* 프로모션
- 구매 프로세스 이탈고객을 이메일 프로모션 대상 고객으로 활용
- 프로모션의 효율적 의사결정을 위한 분석(프로모션 ROI) 가치
- 기본 관리 항목 도출(기본/구매/회원등급)
관리 포인트 도출(이벤트 효과에 대한 효율분석, 카테고리 연관구매, 반복구매주기 분석, 등급유지 상승을 위한 CSF분석, 회원 프로모션 기획 시 반영)
* 트래픽
- 프로모션 기간 동안 외부 유입경로(배너, 등록기타, 이메일, 직접접속)별 방문과 아이템 매출 연계정보
이벤트 별 방문자가 어떤 외부 유입 경로/서비스로 접근하였는지에 대한 시간적 분석(이벤트 참여자의 구매효과)
- 온라인 활동성과 구매 기여도 측정
- 컨텐츠에 대한 개별 기호도 및 접근경로
* 거래
- 일자 별 매출종합 정보 분석 / 방문한 이용자 매출정보에 대한 분석 @

3. 고객모델 만들기
지금까지 ‘고객알기’를 주제로 해서 내부의 고객정보와 외부의 고객정보에 대한 설명과 고객을 알아가기 위한 방법 네 가지를 설명 드렸습니다.
오늘 이야기 나눌 부분은 ‘고객모델’입니다. 고객모델은 고객의 구매와 온라인의 이용패턴과 관련된 행위 정보를 기반으로 고객을 세분화 하거나 이용등급을 나누는 것을 의미합니다.
가장 궁극적으로 고객의 모델을 만드는 이유는 고객에 대한 전략적 가치 판단의 기준을 찾기 위해서 입니다.
통신사나 금융기관에서는 고객의 정보를 잘 세분화하여 고객들의 프로파일을 관리하고 있습니다. 고객에게 알맞은 요금제도의 설계나 포인트의 사용 정보를 잘 분석하여 고객에 입맛에 맞는 상품들을 추천하기까지 하는 것은 고객들의 모델을 전략적으로 잘 활용하고 있음을 보여주는 예입니다.
만약 기업을 방문하는 고객 전부에게 똑같은 형식의 보상을 주는 방식을 사용하고 계시다면 그것은 고객에 대한 기초적인 분석 활동이 이루어 지지 못했음을 의미하는 것이고, 향후 고객에 대한 전략이 없는 것을 말합니다.

Array

이 같은 고객모델의 구성은 어떻게 할 것인가?
지금 추천해 드리는 방식은 RFM(R : Recency, F : Frequency, M : Monetary)의 고객 가치(CE : Customer Equity)모델과 고객의 생애가치LTV(Life Time Value, 고객생애의 가치 = 거래횟수 X 고객의 잠재수익성 X 고객의 거래 기간)모델을 적절히 배분하여 구성하는 방식입니다. 이는 사업의 성격에 따라 조금씩 상이해 질 수 있는 모델이며, 필요에 의해서는 다양한 구매의 패턴정보도 함께 구성한다면 더욱 고객사에 알맞은 고객 모델이 구성될 것 입니다.
고객모델의 구성은 가장 먼저 고객의 측정 데이터(R/F/M/L)들을 산출하여야 합니다(1). 적어도 6개월에서 1년 전의 고객들의 구매나 온라인의 이용행태에 대한 측정 데이터 기초통계정보를 활용하여 분포도를 확인해 봐야 합니다.
예를 들어 구매빈도(F : Frequency)의 데이터 통계 구성이 1과 4에 집중적으로 구성되어 있다고 한다면 구매빈도의 기준을 1과 4로 각각 잡아서 상-중-하로 구성하는 것도 하나의 고객의 등급 속성별로 구분하는 방식이 될 것입니다.
다른 측정데이터를 모두 분석하여 통계적 기준이나 합의에 의한 기준점을 찾은 이후에는 고객의 데이터 측정값의 기준으로 고객들을 나누어 보는 것입니다(2).
이렇게 하여 나뉘어진 고객의 등급별 정보는 등급별 속성정보로서의 의미와 전략적인 측면에서의 세분화된 정보가 됩니다(3). 여기서 중요한 것은 나누어진 고객의 등급별 속성정보를 지속적으로 관리하고 피드백 해봐야 한다는 것입니다(4). 기준에 의하여 나누어진 고객등급의 고객들이 필요에 의하여 좀더 세분화 될 수도 있고, 비슷한 속성등급으로 병합을 시켜야 할 경우도 필요하기 때문입니다.
장기적으로는 고객모델의 구성 이후에 주간이나 월간 분석자료에 등급별 이용현황(매출, 상품 등의 활동)을 추가로 분석하여 보다 전략적인 측면에서의 고객모델 활용을 만드는 것이 가장 중요합니다. @

'장난치기' 카테고리의 다른 글

GoldWave를 통해 벨소리 만들기  (0) 2008.06.26
G메일의 새로운 기능 실험 - Gmail Labs  (0) 2008.06.15
성공적인 CRM을 위한 레시피  (0) 2008.06.11
마카로니샐러드  (0) 2008.06.08
Democracy 2.0  (2) 2008.06.03
88만원세대 - 일본 유학생의 관점에서.  (0) 2008.05.30

Source : http://a.tk.co.kr/409

 

개요..

프로그램 개발에서 소스 관리는 매일 강조해도 지나치지 않습니다.

때문에 대부분의 개발자들은 SVC, Tortoise SVN, 소스세이프(Source Safe)등을 활용하여 소스를 관리하는데, 팀 단위 개발은 물론이고 나 홀로 개발일지라도 소스관리 프로그램을 사용하는 것이 안전을 위해서나, 복구, 수정, 확인을 위해서 매우 편리하고 중요한 역할을 합니다.

이번에는 Tortoise SVN 을 활용하여 로그보기, 업데이트된 곳 찾기, Diff등을 활용해봅니다.

로그 보기

다음과 같은 방법으로 SVN 로그 보기를 하면 업데이트된 날짜와 사람, 수정되거나 추가, 삭제된 항목이 화면이 나타납니다.

Array

Array

바뀐점 보기

바뀐점 보기를 사용하면 프로그램 소스코드에서 수정, 삭제, 추가된 부분을 검사할 수 있습니다.

Array

Array

  프로그래머의 경우는 그냥 컴퓨터라는 것을 잘하면 된다라고 착각하는 경우가 많습니다. 실제로 게임 프로그래머 지망생이나, 게임 프로그래머라고 뽑히는 사람들을 보면, 그런 사람들이 많습니다.

  하지만, 프로그래머라면 반드시 잘 해야 하는 학교 과목이 있습니다. 수학과 물리입니다. 의외일지 모르지만, 사실입니다.

  컴퓨터가 일반적으로 할 수 있는 일, 계산, 문서작업, 음악, 영화플레이, 게임, 그림보기, 인터넷, ...  이것은 컴퓨터가 음악을 이해하고, 색깔을 이해해서 할 수 있는 것이 아닙니다. 전부가 숫자를 이용해 그것을 처리하는 것입니다.

  컴퓨터가 아는 것은 10진수도 아닌 2진수입니다. 즉, 1과 0을 조합한 복잡한 숫자( 000101, 0001011101 등 )를 이용해서, 어디로 옮기고, 어떻게 계산하고, 등의 작업을 통해, 모든 일을 합니다.

  예로, 스타크래프트의 적의 움직임 인공지능 역시도 숫자를 이용합니다. 적의 위치가 x, y좌표 어디에 있는가, 거기까지 가는 동안에 장애물이 있는 좌표는 어디고, 그 좌표를 피해서 거기까지 가려면, 어떤 좌표를 지나가야 하는가? 적이 얼마나 가까이에 있는가? 가까이에 있으면, 어떤 공격력으로 공격할 것인가? ( 전부 숫자입니다. )

  음악도 마찬가지입니다. 모든 음을 숫자로 나타내는 겁니다. 간단히 가정을 하면, 도는 0, 레는 1, 미는 2, 파는 3, ... 등으로 만들고, 그걸 사운드카드가 플레이 하기 위해 명령어( 이것도 숫자 )를 보내고, 그리고, 사운드카드가 원하는 메모리 공간에 음을 연주할 숫자를 넣어주면 됩니다.

  그림도 음악과 마찬가지입니다.

  3차원 그래픽은 진짜 수학 천지입니다. 기본적으로 행렬부터, Sin, Cos, ... 만약 물체의 움직임을 리얼하게 표현하겠다 싶으면 물리의 공식이 잔뜩 들어갑니다. 레이싱 게임의 경우, 물체와 바닥사이의 마찰계수, 가속, 미끄러짐, ... 심지어, 비가 오는 날의 마찰력, 가속, 미끄러짐 모두 프로그래머가 계산해야 하는 것 천지입니다. ( 기획자나 그래픽 디자이너가 해줄 수 있는 문제는 절대 아닙니다. )

  조금 구체적으로 이야길 해보죠.

  수학은 크게, 문제 분석력, 문제 해결능력, 공식 조합능력, ... 등 을 요구한다고 합니다. 이 모든 것이 사실 수학에서 지겹게 하는 겁니다. 어떤 특정한 문제가 있을 때, 그것을 분석하고, 그걸 해결하기 위해 필요한 공식들을 찾고, 그 공식을 이용해 조합하고, 마지막으로 문제를 종합적으로 해결하는 능력입니다.

  또한 버그가 발생했을 때, 찾아가는 순서도, 수학에서 사용하는 검산과 똑같은 방식을 사용합니다. ( 다시 풀기, 대입법, ... )

  간단한 프로그램은 수학을 못해도 할 수 있습니다. 하지만, 앞으로 갈수록 게임은 간단한 프로그래밍 기술로는 불가능합니다. 특히, 간단한 모바일 게임의 경우 누구나 할 수 있는 프로그램이라고 착각하고 한 때, 그렇게 프로그램을 했었지만, 점점, 복잡한 기술과 이론을 사용하기 때문에, 점점 더 수학을 잘 하는 사람을 필요로 할 겁니다.

  수학 못하는 사람 중에 게임 프로그래머로 잘 나가는사람이 있던데요. 그 사람은 크게 3가지 중 하나 입니다. 학교 공부에 적응하지 못해, 수학을 일부러 공부 안한 천재 또는 게임 프로그래머지만 복잡한 프로그램이 아닌 작은 게임이나 알고리즘만 만든 사람 아니면, 말만 그럴듯한 허풍쟁이.

  그 외에 C언어를 완벽히 활용할 수 있을 정도의 능력. ( 다른 자바나 베이직, 플레쉬로도 게임을 만들 수 있지만, 분명히 한계가 있습니다. C#이 차세대 언어가 될 거라는 소리가 있었지만, 역시나 향후 5년 동안도 C언어로 게임을 제작하는 것이 주류가 될 겁니다. 왜냐면, 어셈블리나 기계어와 똑같은 속도를 구현할 수 있는 최적화가 되어 있기 때문입니다.

[ 에이 그럼 느린 게임만 만들면 되지. ]

라고 말하고 싶은 사람도 있을지 모르겠지만, 그럴려면 차라리 빠르게 게임 만들어서 거기에 화면 효과나 다양한 시각효과를 하나라도 더 주자가 게임의 흐름입니다. 단순히 게임만 되는 게임과 스코어나 미니맵 그리고, 타격에 효과처리가 되어 있는 게임은 차원이 다릅니다.

  그리고 영어. 프로그래밍 최신 기술은 영어로 먼저 나옵니다. 알고리즘이나 하드웨어 개발시 프로그래밍 방법은 모두 영어로 먼저 나오기 때문에 빠른 기술 습득에 영어를 잘 하는 것이 좋습니다만, 저는 영어를 못하고도 프로그램을 했었습니다. ( 프로그래밍하면서 영어 잘하는 사람들이 부러웠답니다. )

  또 완벽주의자의 경향이 있어야 합니다. 이것은 게임 개발자의 공통된 자질에서 설명하려고 했습니다만, 여기서 언급하는 이유는 다른 분야 사람들보다 프로그래머는 가장 완벽주의자여야 하기 때문입니다. 완벽하지 못하면, 생기는 문제가 첫째 버그, 둘째 버그, 셋째, 버그, 넷째, 일정 차질입니다.

  첫째부터 셋째가지 버그라고 말장난 한 이유는, 버그가 프로그래머들의 최대 적입니다. 그리고 완벽하게 프로그래밍을 하지 못하면, 항상 생기는 것이 버그기 때문입니다. 일반 업무용 프로그램처럼 [ 판매 후에 패치하지 뭐. ] 이런 생각이라면, 게임을 말아먹겠다는 뜻입니다. 소프트맥스의 [ 마그나카르타 ]사건의 예를 보더라도, 버그가 얼마나 게임에 대한 흥미를 떨어뜨리고, 회사에 얼마나 심한 타격을 주는지 알 수 있습니다.

  C언어를 못하면 배우면 됩니다. 영어 못하면, 국내에 알려진 기술이나, 영어 잘 하는 사람의 도움을 받으면 됩니다. 수학 못하면, 작은 게임만 개발하던가, 보조 프로그래머로만 일하면 됩니다. 하지만, 완벽하게 만들려고 하지 못하는 사람은 게임 개발에 전혀 도움이 안됩니다. 오히려, 개발과 일정에 방해만 됩니다.

  마지막으로 게임 프로그래머로 성공하고 싶으시다면, 수학부터 완벽히 공부하십시오. 완벽히

+ Recent posts