검색어 '관리'에 대한 1 개의 검색 결과

  1. 2010/11/18 PM(Project Manager) 과 PL(Project Leader) by 젤라피

PM 과 PL 뜻과 실무에 대한 실제 예제의 좋은글이 있어 퍼왔습니다.
 읽고 출처에 한번 가보세요.

1. 프로젝트의 필요성
 오늘날 IT는 급진적 성장을 하고 있다.
 기술도 그러하며 다양한 정보를 어떻게 가공하는가에 커다란 차이를 보이기도 한다.
 프로젝트는 일정시간에 일정작업량을 어떻게 효율적으로 분배관리하여 효과를 보는가에 달린것이다.
 결국, 프로젝트는 한정된 IT의 인적/물적자원으로 요구사항을 최단시간 최대효과를 보게 만드는 방법론중 하나이다.
 1-2년의 프로젝트는 본인의 생각으로 거의 의미가 별로 없다. 해외에서는 종종 보는 경우지만
 국내에서는 프로젝트도 빨리 효과를 봐야하기에 대부분이 6개월미만으로 구성되는 경우가 많다.

 왜 프로젝트가 필요할까?
 그것은 단기간에 최대효과를 얻기위해서 필요하다. 2년간의 개발이라면 차라리 고정개발자를 쓰는것이 더욱더 효과적이다.
 2년정도 작업이라면 아에 직원이 필요한것이 더 맞을 것이다.
 프로젝트의 필요성으로 회사나 기업체는 다양한 프로젝트 팀을 구성/해체를 반복한다.
 팀을 구성하면서 구성원의 단순한 일거리 증대로만 이어진다면 팀원이나 팀장은 프로젝트를 기피하게 된다.
 프로젝트는 단기간에 효율을 보기위한 팀장/팀원의 능력확대의 기회로도 활용해야 한다.
 또한 프로젝트의 종료후에는 해당 프로젝트의 성과급이 동반되는 것이 좋다.
 프로젝트는 업무외 별도의 진행인 경우가 많으며 채찍보다는 당근만 사용해도 효율이 크다.
 그런 이유는 일이 힘들어도 승진이나 보수가 높아지는 기회로 구성원이 받아들이기 때문이다.


2. 프로젝트의 기여도
 프로젝트에서 효율성/성공률등 산출지표를 정하지 않고 프로젝트를 진행하는 팀이 많다.
 이는 먼저 선행되어야 할 지표계산을 하지 않고 시작한 경우이다. 옆회사가 하니까 보통 이렇게 하니까 보다
 왜 효율적으로 프로젝트를 진행할지의 계획과 지표를 정하는것이 낮다.
 주먹구구로 프로젝트를 진행하면 일반적으로 다음과 같은 문제점이 몇년후 돌아온다.
 1) 구축한 사이트는 많은데 관리될 문서가 하나도 없다.
 2) 사이트별 소스의 중심이 없다. 핵심소스가 어느것인지 모른다.
 3) 구축한 사이트에 인수인계한 개발자가 난해함을 표명한다. 아니면 운영자가 어떻게 운영하는지를 모른다.
 4) 구축후 회사가 얻은 이익에 대한 문서정리가 없다.
 5) 사이트마다 같은기능을 할때마다 만든다.
 6) 하고나면 납기일이나 완료일이 넘어선다.(미구축/지연구축)
 7) 프로젝트후 회사에 이익이 별로없다.

 이중 회사에 이익이 없는 프로젝트는 재빨리 포기하고 외주나 이관을 하여 손을 떼는것이 낮다.
 7번이 된다면 프로젝트를 할 이유가 없어진것이다.
 프로젝트는 어떤것이든 정상 업무보다 빠른 효율과 빠른 업무분배로 시간상의 여유가 없음을 해결하여 회사의 시간기회비용을 얻고자 함이다.
 보통 1,2,4,5를 많은 회사들이 경험한다. 프로젝트 종료후 데이터정리만 해도 1,2,4,5를 해결한다.
 3,6이 반복이 된다면 구조적으로 프로젝트구성을 다시 생각해봐야 한다. 특히 6번이 반복이 된다면 어딘가 문제가 계속생긴다는 것이다.
 이 문제가 어디인지 모를경우 다음 글을 읽고 한번 생각해보자.


3. PM과 PL의 업무
 PM과 PL의 업무의 분간성이 없다고 하나 분명히 분간성이 있다.
 PM의 일부의 업무를 대신하는 PLA, PLO가 있으며 PM을 감독하고 지시하는 Chief가 있다.
 대부분이 이러한 업무를 모르고 모두 PM이 하는것으로 알고 있는 경우도 있다. 왜 그럴까?
 프로젝트는 PM이 주관한다고 머리에 인식되었기 때문이 아닐까? 물론 일반적 프로젝트에서 PM의 역활은 상당히 중요하다.
 유능한 인재를 적재적소에 배정하는 업무자체가 PM의 몫이다. 프로젝트의 성공/실패의 수행여부도 PM의 몫이다.
 그러나 프로젝트의 채택이나 거절또한 PM에게 권한이 있다. 권한이 있는만큼 책임도 있는것이다.
 일부 프로젝트 PM이 문서를 안만든다는 황당한 소리를 하거나 문서를 PL에게 미루는 고질적 관행이 프로젝트에 있었다.
 소위 대기업이라는 S사의 Sxx의 업체가 대표적인거 같다. 관리자 1-2명 넣고(실제로 PM도 아닌데 명칭은 PM이다.)
 프로젝트 하청전문 컨설팅이 더 어울릴것이다. 컨설팅할때부터 외주인력 붙여서 다 한다.
 그리고 전체 프로젝트 계약금의 일부를 당당히 가져간다. 건설업체의 하청과 과히 다를것이 없겠다.

 일반적으로 프로젝트의 규모는 소중규모와 대규모가 있다. 오른쪽일수록 고위직이다.
 다음과 같이 일반적으로 팀원을 구성한다.
  Coder / PL / PM
 장기적 혹은 대규모는 다음과 같이 구성된다.
  Coder / monitor / PL / QA / PLA,PLO / PM / Cheif
 PL의 일반적으로 2-3년차부터 시작한다. PM은 5년차 이상이 보통 진행한다.
 그러나 2년차가 PM하는 경우도 봤다. 물론 내가 본 사람이 능력이 좋아서라 아니라 PM이 없어서였다.
 이중에 Coder가 단순노동이라고 인식하는 회사는 대부분이 Builder란 용어를 사용한다. 아무래도 용어의 위화감을 줄이기 위함이랄까?
 PL도 PL1, PL2등으로 계층을 나누기도 한다. 본인 생각으로 인적자원 관리에 모두 효율적이다.
 간혹 관리편의주의적으로 나눈거 보면 한심하단 생각도 든다. 프로젝트의 중요점을 모르고 외향에 치중하는 생각만 들기 때문이다.

 주먹구구 프로젝트의 예제를 보자.
 처음에 영업부 김차장이 이렇게 제안서를 들고 온다.
 'A사 신규 eCRM을 진행할때 이렇게 하기로 했다.'
 이건 프로젝트의 요구선행사항이 끝난다는 이야기를 말한다. 이정도 할정도면 영업부 김차장은 이미 PM의 역활을 한것이다.
 영업부 김차장은 프로젝트 PL한테 개발문서 및 요구사항 분석서 정도를 주면 된다. 그런데 김차장이 이 문서를 PM에게 준다.
 PM이 반문한다. '요구사항 분석서는 어디있나요?', '납기일 및 검수일자는요?'
 영업부 김차장은 '아, 정리 조금 더 해서 진행하세요' 이 회사 사장은 영업부 김차장에게 A사 eCRM을 수주했다고 보고받는다.
 PM은 A회사 담당자에게 요구사항 분석서가 없다고 하여 업무정의를 하자고 한다.
 A회사는 김차장이 다 OK했으니 정리할께 없다고 한다. 혹은 이제까지 김차장하고 다 정리했는데 무슨소리냐고 한다.
 PM은 김차장에게 업무정리가 덜 되었다고 한다. 김차장은 그냥 문서같은건 알아서 하라고 한다.
 과장급인 PM은 둘중 하나를 결정해야 한다. 그냥 업체가 하라는대로 따라갈것인지? 더 윗선에 보고해서 김차장이 업무소홀로 문서도 없다고 해야할지.
 안봐도 과장과 차장은 사이가 안좋게 가던가 PM이 죽자고 다시 업체 매달려고 업무정의 문서로 다시 쓴다.
 혹은 그냥 A업체가 하자는 대로 끌려가야 한다. 물론 PM도 문서 안만들고 진행할려고 한다.
 책임소재가 자신이 아니라 김차장이라고 보기 때문이다. 업무정의도 안한건 PM이 아닌 김차장이기 때문이다.
 이제 PM, PL은 요구사항 분석부터 노가다를 해야한다.
 소위말해서 '이쁘게 만들어달라는 지시'만 있기에 이쁘게의 기준부터 A업체한테 물어봐야 한다.
 그러나 김차장은 A업체와 아주 사이가 좋다. 원하는거 다 들어줬기 때문이다.

 정리하는 프로젝트의 예제를 보자.
 영업부 박차장이 제안서를 PM에게 보여준다.
 'A사 신규 eCRM 제안서인데 검토하고 회의합시다.'
 PM이 검토후 박차장에게 뺄것과 추가할것을 제의한다.
 수정된 eCRM 제안서를 A업체에게 제공되며 논의점이나 프로그램 관련사항을 PM과 재협의 혹은 모두 A업체에 가서 이야기한다.
 여기까지 진행되면 결론도 아직 나지 않았으며 위의 주먹구구 프로젝트보다 2-3배 걸린다.
 PM은 요구사항 분석서 / 진행도를 정리하고 회사를 온다. 박차장은 프로젝트 효율성 자료를 만들고 산출물과 평가기준을 만든다.
 PM과 박차장은 사장에게 보고한다.
 그리고 사장과 PM, 박차장은 모두 이 문제를 고민한다. 이제 어떤 요구조건인지 명확하다. 이를 어떻게 할것인지 방법론을 회의한다.
 이미 위의 주먹구구보다 1-2주 혹은 한달느려졌다. 여기까지는 상대적 비효율을 동반한다.
 박차장은 A업체와 걸끄럽다. A업체의 제안서를 변경수정했기 때문이다.

 이제 프로젝트 Kick off후 모습을 구경하자.

 주먹구구 프로젝트
 PM은 바쁘다. PL들에게 진행사항의 모습을 그려주지도 못했다. 프로젝트는 시작했는데 업무정의가 안끝났다.
 여기서 포기하자고 한다면 지체상금이나 위차금이 생겨야 한다. 포기는 할수도 없다.
 재정의 하는데 시간이 촉박하다. 대충 생각하고 PL들에게 구두전달한다 문서할 시간도 없고 문서할 생각도 없다.
 PL들은 노트에 열심히 적는다. PM이 하라는 대로 해야되기 때문에 정확히 적고 있다.
 PL들은 예상치 못한 문제점들을 PM에게 전달한다. 구성해야 할 요구사항이 상충되거나 상쇄되어서 할 필요가 없는것들.
 혹은 프로그램이 하기 어려운 난제들을 PM에게 손쉬운 다른방법은 없을것인지 묻는다.
 PM이 반정도는 다시 재정의하고 A업체에게 다른 방법의 방법안을 협의한다. A업체는 한번에 끝나지 않아서 짜증스럽다.
 프로젝트 반이 진행되었다. 이제 프로젝트의 거의 시작이다. 화면이나 DB나 프로그램 운영방안이 결정된것 같다.
 프로젝트의 원래의 시간이 절반밖에 없으니 PL, Coder에게 야근할것을 주문한다.
 밤새워 프로그램 짠다. 예정된 일정에 허덕이고 맞춘다. A업체는 자신이 말한 이쁘게(?) 제대로 안이쁘게 그렸다고 한다.
 디자인/버그 수정한다. 일정이 변경되고 늘어진다. PM/PL은 이미 올빼미를 초월할 초인이 되어간다.
 김차장은 A업체와 갈등이 생긴다. PM에게 뭐라한다. 프로젝트를 제대로 진행도 못한다고 핀잔을 준다.
 A업체에서는 김차장이나 PM이나 다시 CRM를 주지 않아야겠다는 생각을 한다.

 정리하는 프로젝트의 예제
 사장이 결정하면 박차장은 제안서와 PM의 프로젝트 기획서를 들고 A업체와 최종협의하러 간다.
 A업체가 승락하면 프로젝트를 진행한다. 물론 사장이나 A업체가 NO라고 말하면 프로젝트를 포기하거나 재구성하여야 한다.
 제안서/기획서를 PL들이 돌려본다. PM은 구성원들의 시간안배나 위기관리를 생각한다.
 프로젝트 시작과 동시에 이미 계획은 모두 세워졌다. PL의 시간안배를 위해서 PM은 PLO/PLA의 비상주를 생각한다.
 그리고 필요시 업무정의나 기획의 문제점을 같이 고민한다. PL이나 Coder는 어떻게 화면에 나올지도 다 안다.
 문서대로 어떻게 만드냐만 고민하면 된다.
 납기일부터 1-2주전에 완성된다. 이미 버그,수정후 PL은 프로젝트 퇴거를 했다. PM/PLO/QA들이 문제 점검 및 테스트를 진행한다.
 A업체는 자신들이 쓸 프로그램이 미리 완성하고 테스트를 하고 있으니 안도를 한다. 신뢰가 생긴다.
 A업체는 upgrade의 예상까지 박차장에게 넌지시 물어본다. 박차장과 A업체가 이전보다 신뢰가 올라간다.

 이 두가지가 끝나고 비교하자.

 주먹구구 프로젝트 전체 2달예정에 3달걸려서 완성했다. 고생은 고생대로 신뢰는 오히려 하락한다.
 때에 따라서 금전적 이익은 본다. 반면 팀원은 힘들어서 관둘까도 생각한다. PM도 마찬가지이다.
 A업체는 추가요구사항도 돈도 안주고 당당히 말한다.

 정리하는 프로젝트 전체 3달예정에 3달걸려서 완성했다. 고생은 일부했지만 신뢰는 상승한다.
 때에 따라서 금전적 손실도 본다. 팀원은 성취감이 올라간다. PM도 다음 upgrade를 주관하여 만들수 있다.
 추가금액을 줄테니 upgrade를 하지고 한다. 파생효과가 생긴다.


4. PLA? PLO?
 프로젝트 진행시 필요시 충원되는 인원으로 유동적이다.
 PL Advisor, PL operator로써 PM의 일부업무 및 PL의 업무의 진행/프로그램 코딩을 조언하거나 운영시험/테스트등을 도와주는 업무이다.
 이 두가지를 프로젝트에 유용하게 씀으로써 프로젝트가 유동적으로 진행이 될수 있으나 활용하지 않고 보통 QA만을 생각한다.
 이는 나무기둥은 안보고 잔가지를 화려하게 펼칠수 있는가를 고민하는것이다.
 물론 PM이 작은 프로젝트에서는 이 두가지를 병행해서 처리한다. 따로 둘필요없이 혼자 다 처리하는게 경험이 풍부한 PM이 대신하것도 된다.
 반대로 PL이 하는 경우도 있다. 어느쪽이든 상관은 없다. 그러나 PL이 하게 되면 QA는 잘 못하는 경우가 많다.
 대부분이 자신이 테스트하는대로 실제로도 그렇게 쓸것이라고 판단하여 테스트하기에 거의 양호하다는 판정을 한다.

 프로젝트를 본인도 진행시 이 두사람이 필요한경우는 몇번 보지 못했다. PM들이 우리나라는 대부분이 병행해야 한다는 생각으로 보인다.
 그러나 PM의 업무가 가중될시 이 두가지 점검은 패스할수도 있다. 왜냐하면 빨리 드러나지 않는 이유이기도 하다.
 프로젝트가 많은 회사일수록 이 두 인원을 더욱더 고려해야 한다. 단순히 임금더 들어가는 직원이라는 이유로 없어도 된다라고 보기보다
 나중을 생각해서 프로젝트 완성도를 높이고 고객신뢰를 높이기 위해서는 오히려 반드시 필요하고 있어야할 인원이기도하다.
 1,2년후의 프로젝트후 고객인지도와 신뢰를 높이고자 한다면 오히려 반드시 있어야 한다.

 이와 비슷한 Coder를 관리할 Monitor도 있다. PL이 기획한 프로그램 방법론을 coder의 코딩시 보조해 주고 support 및 PLO의 지시를 받는 사람이다.
 PL의 개발방법론을 원하는 대로 가고 있으며 PL이 원하는 화면이 제대로 나오는지 확인하고 수정하고 감시도 하는 일이다.
 프로그램의 구조론이 Coder에서 변경될수도 있다. 적합성이나 효율성등에서 더 좋은 코딩이 나올수도 있다.
 이러한 내용은 대부분이 Coder를 하면서 PL의 역활을 할수있는 중간프로그램머라고 볼수 있다.
 이러한 직원중 프로그램이 더 효율적이라면 추후 PL로 될것이며 검증이나 관리에 능하다면 QA로 승격이 될것이다.


5. QA?
 실질적 프로젝트에 기여도가 눈에 안보이는 직원이다. 그러나 멀리보면 대단히 중요한 업무이다.
 QA는 프로그램의 전체평가에 가장 큰 부분을 차지한다. 프로그램의 방법론은 보통 한두가지가 아니다.
 이러한 프로그램의 내용을 평가하는 사람이 PM과 QA이다. 같은 프로그램이라도 어느것이 효율적인지 판단해야 하는데 프로젝트의 QA는 거의 품질검사 요원으로 인식하고 있어서 아쉽다.
 QA의 평가서는 PL의 자격이나 성과급에 반영되고 PM의 역량에서도 영향을 미쳐야 한다.
 QA를 중시하면 PM/PL의 사기가 저하가 된다. 같은 작업이라도 QA가 반대하면 프로젝트와 상관없는 일도 해야 하기 때문이다.
 (이는 프로젝트보다 회사의 능력치나 성과급에 일을 함으로써 생긴다.)
 본인의 판단에 QA를 프로젝트에 1-2년차가 형식적으로 하는것을 봤는데 원래는 PM를 하던 사람이나 그 이상의 사람이 해야 한다.
 자신이 PL/PM/를 해봤어야 프로젝트의 성과급에도 정확한 지적을 할수 있을 것이다.
 QA의 품질검사란 기준을 머리속에서 지우자.
 실질적이고 유동적으로 대체하는 QA는 회사가 진행하는 모든 프로젝트에 영향력을 행사하여 고객만족이란 단어가 생기게 할것이다.
 그렇다고 QA가 고객의 말만 듣고 이리 고쳐라 저리 고처라 한다면 이는 없는것보다 못하다.
 QA월급은 고객이 주는게 아니라 소속회사가 준다는 걸 명심하자.


6. 중요도에 따라서 팀원의 자격위치가 바뀐다???
 자격이 바뀐다는 것은 역활의 중요도가 이를 반영하면 된다.
 아까의 대규모 프로젝트가 필요해서 구성했다고 치자
  Coder / monitor / PL / QA / PLA,PLO / PM / Cheif
 수주 요청 B회사는 어떤 특정 방식을 요구했다고 한다. 예를 들면 javascript는 버전 몇이하 어떤방식. 프로그램은 java applet으로.
 PM은 같은 프로그램의 방법론에 규약이 생긴것이다. 이를 지킬려면 다양한 방법론중 원하는 QA가 이를 지킬수있게 이렇게 프로젝트 계층을 구성해야 할것이다.
  Coder / PL / monitor / PLA,PLO / QA / PM / Cheif
 monitor,QA 위치가 한단계 승진했다고 보면 된다. 그렇다고 재량권을 맘대로 가진다는 것은 아니다. 이 프로젝트가 이렇게 될뿐이다.
 고객사의 요구를 검증하는 권한이 생겼다고 보면 된다. 이러한 구조는 직책과는 별도의 것이다. 혹은,
  Coder / PL,monitor / PLA,PLO,QA / PM,Cheif
 PL과 monitor를 동시에 PLA,PLO,QA는 같은 권한에 반대로 Cheif는 권한을 낮추어서 등등
 이러한 구성은 PM에게 권한이 주어지며 프로젝트를 진행할 책임도 동시에 PM에게 주어진다.


7. 더 효율적 구성원을 만들기 위한 방법
 어떻게 인원을 들여서 어떻게 효율적으로 프로젝트를 마치는가?
 위에서 언급한거와 같이 프로젝트는 시간을 줄여서 회사에 시간적기회비용을 늘려준다고 했다. 즉, 인원이 더 들여서라도 단기간에 끝나야 한다.
 프로젝트를 일부회사는 정규직 직원보다 사람을 줄여서 진행하는 것처럼 이야기한다. 즉, 인원의 임금을 줄여서 이익을 올린다라고 본다는 것이다.
 솔직히 회사는 이익을 올려야 한다. 직원들 월급도 그렇고 회사비용도 그렇고 돈의 이익이 없으면 안할것이다.
 왜 프로젝트란 것으로 이를 남용하는지는 모르겠다. 프로젝트의 원래의 목적과 상반될 것인데 회사는 이에 대한 불이익도 고스란히 회사로 간다.
 까짓것 회사 폐업하면 되지. 이렇게 생각하는 사장과 일한다면 당장 관두라고 본인은 말하고 싶다.
 누구를 프로젝트에 참여시킬 것인가? 이는 PM이 판단해야 한다.
 효율적 배분을 위해서는 직원의 능력치를 알아야 한다. 무엇을 얼만큼 잘하는 직원이 있는지 우선 알아야 한다.
 필요하면 과감히 비싼 프리랜서라도 고용해서 써야 한다. 또한 그만큼의 능력되는 직원이 없다면 직원으로 뽑던지 아니면 직원능력향상을 가지게 해야 될것이다.

 또한 정상적 프로젝트를 하면서 어떻게 인원을 분배 활용할것인가?
 같은 일을 하면서 같은 능력의 사람이라도 차이가 날것이다. 이는 사람이 기계가 아니기 때문이다. 어제와 오늘 같은 사람에게 같은 일을 시키면 보통
 어제보다 오늘 일을 더 빨리 끝낸다. 이미 경험을 하였기 때문이다. 과거의 경험으로 현재의 능력이 좋아졌다고 할수 있다.
 그런데 프로젝트는 틀에 정해진 일이 없는 경우가 더 많다. 프로그램도 다양하기 때문에 어떻게 사용되고 활용될지도 미지수이다.
 결국 PM은 이러한 과중한 진행적인 책임을 지고 있는것이다.

 프로젝트의 시작과 끝은?
 항상 주위사람에게 이렇게 말한다. PM이 시작하고 PM이 끝이라고 해야 프로젝트가 맞다고, PM이 역활이 가장 큰 중요한 부분이라는 것이다.
 그중 프로젝트를 잘하고 못하고는 이렇게 말할수 있다고 항상 주장했다. 잘해도 PM이 잘한것이고 못해도 PM이 못한것이다.
 프로젝트를 진행할때 보통 PM이 시작이라고 말하지 못해서 아쉽다. 그많큼의 권한을 안주는 것이다. 또한 끝도 PM이 끝이라고 못한다.
 그러나 책임은 다 PM에게 있다. 그래서 사람들이 PM의 업무를 거려한다. 권한도 없고 책임만 따르기 때문이다.
 보통 영업이 시작하고 관리부가 돈받고 처리되면 끝이라고 보는 현실이 아쉽다.


8. 마치면서.
 날 아는 사람이 이 글을 써달라고 해왔다. PM,PL그리고 프로젝트의 인원에 대한 대략적인 글을 써달라고 하였다.
 뭐에 쓸것이냐고 물었더니 현 다니는 회사에 내 글을 기초로 제안을 하겠다는 것이었다. 프로젝트가 말만 프로젝트지 하는것은 개판(?)이라고 하면서
 나는 대단하다고 속으로 느끼었다. 간헐적으로 필자도 프리노트에 이것저것의 정리를 하면서 살지만 구체적으로 제안하진 않았다.
 필자도 프리랜서를 하였다 뭐 길게 한사람에게는 우습게 보이는 몇년 안되는 일이었다. 하지만 정규직일때도 프리일때도 제안같은건 안했다.
 그러다가 문득 네이버에 올려야겠다는 생각이 들었다.

 드물지만 PM이나 PL이 뭔지도 모르고 오는 사람도 있었다. 참고로만 활용하길 바란다. 이 글은 정답이 아니다. 현실도 이렇치 않다.
 우리나라는 큰 프로젝트도 규모를 짜서 하지 않는다 보통 소위 큰 SI기업체에게 위탁하여 끝낸다. 그러다가 몇년후면 DB까지 몽창 뒤업고 다시 만든다.
 IT의 슬픈 현실같다. 외국은 10년 넘는 프로그램도 만들고 돌린다. 기획을 1년넘게도 한다. 과거 10년자료도 모두 있다.
 IT인으로서 정보강대국이라는 정부의 말이 허상이 더 많다고 본다. 그리고 그 IT의 기초기술은 전부 외국에게 있다. 이게 현실일것이다.

크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2010/11/18 09:47 2010/11/18 09:47
젤라피 이 작성.