분류 전체보기 (328)
.NET (111)
S/W tip (35)
etc (63)
DB (34)
HOT item~! (48)
Disign pettens (4)
UX (6)
나의 S/W (2)
개발관련 이슈 (16)
Diary (1)
웹플러스 (1)
calendar
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
tags
archive
link
ColorSwitch 00 01 02
http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039162121

당신의 조직은 개발자를 올바르게 관리하고 있는가?
류한석(IT 컬럼니스트) IT칼럼니스트 hanseok.ryu@gmail.com
2007.10.10 / AM 09:25

[지디넷코리아]한국의 많은 소프트웨어 업체들이 개발자를 제대로 관리하지 못하고(또는 안하고) 있다. 소프트웨어 개발은 정신에 의한 작업이다. 누가 하는 가에 따라서, 어떤 동기부여를 하는 가에 따라서, 어떤 환경에서 하는 가에 따라서, 어떻게 관리하는 가에 따라서 엄청나게 다른 결과를 만들어낸다.

하지만 관리라는 이름 하에 개발자에게 모욕적인 대우를 하는 경우도 많다. 작업에 지장이 있을 정도의 저사양 개발장비를 제공하고, 좁아터진 공간에, 계속 울리는 전화벨과 시끄러운 대화 소리, 휴식공간이라고는 전혀 없는 조직도 많다. 직원들의 일거수일투족을 감시하고, 심지어는 복장 검사를 하는 경우도 있다.

또한 프로젝트 데드라인을 맞추기 위해 새벽에야 겨우 집에 들어갔음에도 불구하고, 출근시간에 몇 분 늦었다고 해서 지각을 체크하고 전체 직원이 모인 회의에서 실명을 거론하는 회사도 있다. 그런 회사일수록 야근수당이 없고 교통비도 지급하지 않으며 사소한 비용을 아낀다. 한마디로 작은 비용을 절약함으로써, 신뢰 상실이라는 큰 비용을 지불하는 것이다.

그런 회사에서 만들어지는 소프트웨어는 품질이 나쁘다. 불행한 개발자들은 품질이 나쁜 소프트웨어를 만들어 낸다. 어쩌면 잠을 못 자고 피로에 지친 개발자들이 내쉬는 서글픈 한숨이 소프트웨어의 영혼에 스며들어 가는 것은 아닐까? 저주받은 소프트웨어. 마치 호러영화의 한 장면처럼 느껴진다.

회사는 직원들을 사랑하지 않으면서, 직원들에게 애사심을 강요하는 회사를 보고 있자면 실소가 나온다. 물론 회사로서는 직원들에게 사랑을 보여줄 수 없는 가장 큰 이유가, 열악한 비즈니스 환경으로 인한 비용적 압박 때문이라고 얘기할 것이다. 백분 양보하여 그것을 인정한다고 할 지라도, 그렇다면 도대체 왜 부적절한 관리자에게 관리를 맡기고 있는 것일까?

나쁜 관리자가 프로젝트를 망치고 있다!
업계를 보면 관리자의 자격이 전혀 없는 사람이 관리를 맡고 있는 경우가 무척 많다. 나쁜 관리의 비용은 엄청나다. 단지 팀 구성원들의 작업에 지장을 주는 정도가 아니라, 조직의 목표 달성에 해악을 미치며 결국 상당한 대가를 치르게 만들고 프로젝트를 완전히 망치는 경우가 빈번하다.

필자는 단지 관리자를 잘못 배정했기 때문에 수백억 원의 손해를 본 어느 대기업의 프로젝트를 경험한 적이 있다. 팀원들은 모두 유능했고 각자의 마음 속에 일을 잘하고자 하는 열정이 있었지만, 관리자의 무능과 변덕과 학대로 인해 팀원들은 모두 좀비가 되어갔다. 일부는 떠났고 일부는 일을 하지 않았고 일부는 하는 척을 했다. 결국 수년간 프로젝트를 진행했으나 결과는 나오지 않았고 프로젝트는 취소됐다. 몇 가지 추가적인 원인이 없었던 것은 아니지만, 가장 주요한 요인은 ‘나쁜 관리자의 존재’ 그 자체였다.

나쁜 관리자는 팀원들이 무엇을 하고 있는지 알지 못하며(또는 관심이 없으며), 팀원들의 능력을 제대로 파악하지 못한 채로, 원칙 없이 업무를 지시하며, 부적절한 인력을 배치하고, 팀원들과 제대로 대화를 나누지 않으며, 펫프로젝트(pet project, 고위층 또는 자신의 개인적인 관심으로 만들어낸 프로젝트)로 인해 업무 우선순위를 마구 바꾸고, 결과가 나와도 잘했는지 못했는지 제대로 판단하지 못한 채 자신의 기호에 따라 결과를 재단한다. 한마디로 그들은 조직의 목표와 팀원의 성장에는 아무런 관심이 없으며 단지 자신의 안위만 생각하는 사람들이다.

그러한 나쁜 관리자의 존재가 지극히 예외적인 경우라고 생각하는가? 만일 그렇다면 당신은 조직 생활의 경험이 많지 않든가, 아니면 억세게 운이 좋은 경우일 것이다. 그런 나쁜 관리자로 인하여 젊은 시절의 소중한 경험을 빼앗기는 팀원들이 몹시 많다. 나쁜 관리자의 해악은 단지 프로젝트의 실패로 나타나는 것뿐만 아니라, 사람들의 인생에서 그 시기에 필히 겪어야 할 소중한 경험까지 앗아가 버리는 것에 있다. 좋은 관리를 받아보지 못한 사람은 좋은 관리를 할 수가 없다.

좋은 관리자가 되기 위한 지침
그렇다면 좋은 관리란 어떻게 관리하는 것인가? 하단과 같이 몇 가지 지침을 제시할 수 있을 것이다.

첫째, 바라는 결과를 명확히 알려주어야 한다. 어떤 관리자들은 자신이 무엇을 원하는지 자기 스스로도 정확히 모르는 채 작업을 지시하고, 팀원의 작업 결과를 그날그날의 기분에 따라 자신의 기호대로 판단하곤 한다. 그런 관리자는 관리자로서의 자격이 없다.

둘째, 위임을 적절하게 수행해야 한다. 어떤 사람의 그릇은 위임할 수 있는 양의 크기로 정해진다. 즉 어떤 사람이 이루어낼 수 있는 최대 성과치는 그가 팀원들에게 권한을 위임할 수 있는 능력에 의해서 결정된다는 뜻이다. 할 일이 너무나 많지만 일할 시간이 없고 혼자서 모든 일을 처리하려고 하는 관리자는 탈진증후군(burnout syndrome)에 빠지게 된다. 그리고 탈진증후군에 빠진 관리자는 결국 팀을 궤멸시킨다.

셋째, 방법보다는 결과에 초점을 맞추어야 한다. 이 말에 오해가 없기를 바란다. 오로지 결과만 중요시하라는 뜻이 아니라, 결과가 올바르다면 방법은 팀원에게 맡겨두라는 뜻이다. 개발자 출신의 관리자는 자신이 선호하지 않은 방법으로 구현을 했다는 이유로 팀원을 질책하거나 업무를 회수하는 잘못을 저지르는 경우가 많다. 그런 관리자는 좋은 결과도 팀원들의 신뢰도 얻지 못할 것이다. 결과가 옳다면 그 방법은 팀원에게 맡겨두는 포용력을 가져야 한다.

넷째, 피드백을 주고, 코칭을 하고, 경력 개발을 지원해야 한다. 피드백이란 해당 직원의 업무 결과에 대해 어떻게 생각하는지 그 내용을 전달하는 것이다. 코칭은 일종의 도움을 주는 것으로서 선택 가능한 사항들 속에서 실행 계획을 만들도록 도와주는 것이다. 그리고 팀원이 새로운 지식과 경험을 쌓음으로써 성장할 수 있도록 경력 개발을 지원해야 한다. 팀원의 경력 개발에 전혀 신경을 쓰지 않은 관리자들이 너무 많다. 그것은 팀원을 일회용품으로 취급하고 있음을 스스로 증명하는 것과 같다. 경력 개발에 도움을 받은 팀원은 관심을 갖고 도와준 관리자를 언제까지나 기억할 것이다.

다섯째, 좋은 관리자는 자기 자신을 관리하는 사람이다. 좋은 관리자는 감정의 폭발에 반응하기보다는 사건에 대응한다. 불필요한 감정을 발산하여 팀원에게 공포심을 조장해서는 안 된다. 만일 감정이 폭발했거나 또는 잘못된 지시를 했다고 판단될 시에는 즉각 솔직하게 인정하고 사과를 해야 한다. 실수를 인정하는 관리자는 인간적으로 보인다.

좋은 관리 방법을 배우기는 힘들다. 왜냐하면 그것은 눈에 잘 보이지 않기 때문이다. 하지만 우리는 그것을 배우고 실천해야 한다. 그것이야말로 업계에 만연된 악순환의 고리를 끊어버리는 유일한 방법이기 때문이다. 우리가 겪은 불행한 경험을 다시금 후배들에게 전달해서는 안 된다.

비록 기술 중심의 소프트웨어 업체라고 할 지라도, 기술 관리란 기술이 아니라 사람을 다루는 것임을 잊지 말아야 한다. 회사가 가능한 범위 내에서 최상의 업무 환경을 제공하고, 개발자 개개인을 세심히 배려하는 피드백, 코칭, 경력 개발을 지원하는 관리자가 있는 조직이라면 개발자는 결코 불행하지 않을 것이며 더 나아가 어려운 일도 기꺼이 극복해 낼 것이다.

하지만 지금 이 순간에도 많은 기업들이 사소한 비용 절감과 무의미한 규칙 준수를 위해 직원들의 신뢰를 잃고 있으며, 나쁜 관리자를 배정함으로써 프로젝트와 팀원의 인생을 망치고 있다. 나쁜 관리자는 개인, 회사, 사회 모두에 악영향을 미치는 존재이다.

반면에 좋은 관리자는 탁월한 결과를 만들어내고 팀원들을 성장시키고 사회 전반에 좋은 인재를 공급한다. 그런 훌륭한 관리자가 어디 흔하냐고 항변하는 기업의 목소리가 들린다. 하지만 기업들이여, 그런 변명보다는 좋은 관리자를 채용하려는 노력, 그리고 양성하려는 노력, 그리고 그가 ‘진짜 관리’를 제대로 수행하였는지 평가하려는 노력을 무엇보다 먼저 기울여야 하지 않을까? @

▣  애플!! - etc - 2009. 4. 24. 20:34
[불황에 강한 기업] <1> 시들지 않는 사과, 애플
위기 속에 최고실적… '마법의 사과' 비결은 혁신상품

IT거품붕괴 때 아이팟 '승부수'… 美 경제위기 초엔 아이폰 출시
'기술우위' 고집하다 위기 맞기도… 혁신적 디자인 집중해 연속히트

문준모 기자 moonjm@hk.co.kr
1 2 3 
클릭하시면 원본 이미지를 보실수 있습니다
1 2 3 
클릭하시면 원본 이미지를 보실수 있습니다
1 2 3 
클릭하시면 원본 이미지를 보실수 있습니다
스티브 잡스
글로벌 금융위기는 정보기술(IT) 시장도 초토화시켰다. 소니, 델, HP, 이베이, 야후 등이 전례 없는 구조조정에 돌입했으며, 도저히 흔들릴 것 같지 않던 구글과 마이크로소프트(MS)마저도 1만명이 넘는 직원을 대량해고할 것이라는 소문이 돈다.

하지만 이런 경제적 빙하기에도 꿈쩍 않는 기업이 있다. 오히려 사상 최고의 실적을 기록하며 기업 연혁을 새로 쓰고 있다. 바로 '시들지 않는 사과', 미국 애플사(社)이다.

혁신상품으로 불황을 넘다

애플은 지난 2009회계연도 1분기(2008년 10~12월)에 시장 예상치를 뛰어넘는 깜짝 실적을 내놓았다. 매출액 101억 6,000만달러, 순이익이 16억 1,000만달러(주당 1.78달러)로 전년 동기 대비 각각 5.8%, 1.9% 증가한 것이다. 거의 모든 업체들이 두자릿수가 넘는 마이너스(-) 실적을 내놓고 있는데도, 애플은 굳건히 플러스 성장을 유지하며 오히려 사상 처음 분기매출액이 100억 달러를 돌파하는 기염을 토했다. 업계는 애플의 성적을 '기적'으로 평가하고 있다.

애플이 불황을 이겨낸 힘은 히트상품에서 나왔다. '아이팟'(MP3플레이어), '아이폰'(휴대폰), '매킨토시'(PC) 등은 경제위기 속에서도 '베스트셀러' 지위를 잃지 않았다. 1분기에 아이폰은 436만대가 팔리며 전년 동기보다 88% 급증했고, 아이팟도 2,270만대가 판매돼 시장 예상치(1,860만대)를 크게 앞섰다. 매킨토시 컴퓨터도 고정 팬의 지속적 수요로 9% 늘어난 252만대가 팔렸다.

애플의 제품은 '혁신' 그 자체였다. 애플은 불황이나 경영위기를 누구도 생각치 못한 혁신상품으로 늘 돌파해 왔다. 2000년대 초 IT거품 붕괴로 PC산업이 심각한 불황에 빠지자 새로운 성장동력으로 MP3플레이어를 선택, 2001년 아이팟을 출시하며 승승장구한 것이 대표적 사례다. 애플은 새로운 사용자환경(인터페이스)을 가진 아이팟을 출시함과 동시에, 음악이나 동영상 콘텐츠를 판매하며 수익을 배가시켰다. 이후 미국 경제위기가 시작된 2007년에는 버튼 없는 휴대폰 '아이폰'을, 2008년에는 세계에서 가장 얇은 노트북 '맥에어'를 출시하며 불황으로 지갑을 닫았던 소비자들까지 열광의 도가니로 몰아넣었다.

소비자 기대를 실망시키는 법이 없는 애플은 이미 시대의 '혁신' 아이콘으로 자리매김했다. 이 같은 성과에 힘입어 애플은 2008년에 이어 2009년에도 미국 경제전문지 포춘이 선정하는 '존경받는 기업' 1위 자리를 굳건히 지켰다.

실패로부터 배우다

애플도 처음부터 승승장구했던 것은 아니다. 숱한 위기가 있었다.

1976년 스티브 잡스와 스티브 워즈니악, 로널드 웨인은 애플을 창립하고, 개인용 PC인 애플 1,2를 잇따라 내놓았다. 특히 애플 2는 당시 흑백의 PC환경을 컬러 그래픽으로 바꾼 최첨단 제품이었다. 그러나 애플이 시장에서 인기를 끌기 시작하자 '거함' IBM의 추격이 시작됐고, 애플은 결국 경쟁에서 밀리고 말았다. 소프트웨어 부문에서도 IBM과 손잡은 MS에 추격을 허용했다.

이에 스티브 잡스는 83년 사용자가 프로그램 언어를 몰라도 지금의 윈도시스템처럼 그래픽과 마우스로 조작할 수 있는 최초의 PC '애플 리사'를 출시하며 반전을 노렸지만, 이 역시 너무 비싼 가격과 폐쇄적 소프트웨어 환경 때문에 상업적으로 실패하고 말았다. '기술경쟁력 우위'가 모든 것을 해결해줄 거라는 애플의 믿음이 무너지는 순간이었다. 이 실패를 계기로 85년 스티브 잡스는 애플에서 쫓겨났고, 매킨토시 이후 이렇다 할 히트제품을 내놓지 못한 애플은 90년대 들어 '버려진 사과'가 되고 말았다.

디자인으로 부활하다

1997년 스티브 잡스가 해결사로 복귀했다. 그는 '혁신'을 위해 버릴 것은 과감히 버렸다.

우선 그간의 폐쇄적 정책을 버렸다. 그리고 경쟁자인 MS와도 기꺼이 손을 잡았다. 이런 전략적 제휴를 통해 애플은 중복사업에 대한 소모적 지출을 줄였고, 그만큼 온라인 스토어 등 콘텐츠 시장에 진출할 수 있는 여력을 확보했다.

'기술우위'에 대한 집착도 버렸다. 대신 소비자를 위한 창의적 디자인 역량에 집중했다. 그 결과 98년 출시된 투명한 플라스틱 소재 PC '아이맥'은 발매 첫 달에만 80만대가 판매되는 '잭팟'을 터뜨렸다. 2007년 출시된 아이폰은 3세대 휴대폰이 대세인 상황에서 2.5세대 통신기술을 채택하는 대신, 터치스크린을 이용한 획기적 디자인으로 휴대폰 시장의 물줄기를 바꿨다.

애플의 연속 히트는 올해도 계속될 전망이다. 애플은 6~7월께 아이팟 신제품 및 새로운 아이폰을 발표한다. 박성민 삼성경제연 연구원은 "1990년대까지 PC시장을 선도하던 컴팩은 2000년대 초반 불황기에 가격경쟁에 매달리다 결국 2002년 휴렛팩커드에 합병되고 말았지만 애플은 PC산업을 잠시 접고 MP3플레이어 시장에 승부수를 두는 과감한 결단으로 불황을 극복했다"면서 "지속적인 연구개발과 경영자의 결단, 실행력이 불황에도 지속 성장하는 열쇠"라고 설명했다.

"비용 절감보다 R&D 투자 늘려라"


■ 망할 뻔한 회사 '혁신의 상징'으로 변신시킨 스티브 잡스

'애플'신화의 중심에는 창업자 스티브 잡스가 있다. 그가 회사에 없었던 1980년대 중반~90년대 중반 애플은 쇠락의 길을 걸었다. 한때 매킨토시에 기반해 출판과 그래픽 분야에서 독보적 위치를 차지하던 애플은 90년대 들어 MS와 인텔의 협공으로 설 땅을 잃어갔다. 95년 9.4%였던 시장점유율은 97년 3%까지 떨어졌다. 뿐만 아니라 93년부터 97년까지 적자에서 한번도 벗어나지 못했다.

그가 경영권을 넘겨받아 진두지휘 하던 2000년대에는 IT거품 붕괴라는 악재도 있었다. 그러나 스티브 잡스의 리더십은 애플을 이 모든 경영위기와 불황으로부터 구해냈다.

지금 IT업계에선 스티브 잡스의 말 한마디, 행동 하나하나를 주목하고 있다. "그의 생각을 읽을 수만 있다면 불황도 무섭지 않다"는 얘기까지 있을 정도다. 그가 남긴 어록에서 애플신화의 힌트를 어느 정도 찾을 수 있다.

발상의 전환

잡스는 어려움에 처한 애플을 살리기 위해 '다르게 생각하라'는 이념을 주창했다. 다만 "생각만 다르게 할 것이 아니라, 제품으로 다름을 실현하라"고 요구했다.

사실 그는 애플 창업 때부터 그랬다. 커다란 메인 프레임 컴퓨터가 지배했던 70년대에 그는 이미 '다른 컴퓨터'인 개인용PC가 대세가 될 거라고 생각했으니 말이다.

절감 보다 혁신

그는 비용절감이 결코 위기를 이겨내는 처방은 될 수 없다고 강조했다. 2000년 IT버블 당시 대부분 회사들이 가장 먼저 비용절감에 나섰고, 애플 실무자들 역시도 같은 분위기였다. 하지만 그는 "애플사에 필요한 건 다른 게 아니라 현재의 궁지에서 벗어나도록 방법을 혁신하는 일이다"고 강조했다. 그는 한창 경기가 어렵던 1999~2002년 오히려 연구ㆍ개발(R&D) 투자를 42%나 늘리는 결단을 내렸다. 당시에는 많은 반대에 부딪쳤으나 결국 후일 성공한 전략으로 판가름 났다.

가격은 문제가 될 수 없다.

2001년 아이팟이 출시됐을 때 많은 전문가들이 회의적인 반응을 보였다. MP3플레이어 시장은 이미 일본이나 한국 제품이 이미 주도하고 있던 시장인데다, 불황에 누가 300달러라는 높은 가격을 주고 아이팟을 사겠냐는 것이었다.

그러나 그는 단호했다. 그는 당시 수많은 반대자에게 간단히 반박했다. "아이팟보다 더 비싼 운동화들도 있지 않느냐"고. 결국 불황이라도 싸다고 다 팔리는 게 아니라, 비싸도 고객이 원하는 가치를 제공하는 게 중요하다는 것. 이 말은 지금도 아이팟을 사기 위해 줄을 늘어선 소비자들에 의해 입증되고 있다. 물론 이런 자신감의 원천은 아이팟이 기존 MP3플레이어와는 완전히 '다르다'는 믿음, 그리고 튼실한 R&D 투자에 있었다.

▣  빌드 이벤트 part2 - .NET/C# - 2009. 4. 24. 16:12

출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1188


이 팁은 Visual Studio 2005에 관한 팁입니다.


문제 유형

C#을 이용해 독립적인 클래스를 하나의 DLL로 만들어 GAC에 등록하는 경우가 종종있습니다.

특히 서버용 구성요소를 만들다 보면 자주 이런 식으로 구현하게 되는데,

이 경우 자동으로 Gac에 등록되게 할 수 있도록 프로젝틔 속성 내에 있는 빌드 이벤트를 이용하곤 합니다.

빌드 이벤트 내에 아래와 같은 형태로 넣을 수 있습니다.




빌드 전 이벤트 명령줄(R)

 gacutil.exe /u $(ProjectName)


빌드 후 이벤트 명령줄(O)

 gacutil.exe /i $(TargetFileName)




해당 항목에 위의 굵은 줄 부분을 넣게 되면, 자동적으로 빌드 하기 전에 GAC에 등록되어 있는 어셈블리를

해제 했다가, 빌드가 완료된 후 다시 GAC 상에 등록 해주게 됩니다.

일반적으로 간단한 DLL에서는 위와 같이 작업하게되면 큰 문제없이 컴파일 되며 정상적으로 동작합니다.


그러나 팀 작업이나 기타 다른 이가 작성한 프로젝트를 가져와 작업하는 경우 위의 설정에서 오류가 발생할 수 있습니다.

저 같은 경우에는 아래와 같은 오류 메시지가 뜹니다.(XXX.XXXX.XXXXX는 어셈블리 이름입니다.)


오류    1   "gacutil.exe /u XXX.XXXX.XXXXXX" 명령이 9009 코드에서 끝났습니다.



문제 원인 분석

오류에서 나타내고 있는 9009 코드라는 것에 대한 정확한 의미를 찾을 수 없습니다.

일단 각종 포럼에서 제시한 문건들을 보면 Gacutil.exe 뿐만 아니라, 다양한 명령줄 실행 중에 발생한다는 것을 쉽게 발견하실 수 있습니다. 그래서 여기서는 Gacutil.exe 만을 가지고 판단하도록 하겠습니다.

제가 gacutil.exe를 버전 별로 실행해본 결과,

 위와 같은 오류가 발생되는 원인이 1.1.4X 버전의 .NET Framework 내에 있는 Gacutil.exe가 불려져서 발생되는 경우가 가장 많습니다.(최소한 저와 같은 환경에서는 그렇습니다.) 왜 그런지는 알 수 없지만 VS 2005의 빌드 이벤트 명령줄은 Gacutil.exe를 2.0 용이 아닌 1.0 버전용을 먼저 호출 되고 있다고 판단됩니다.



해결 방법


1. 전체 경로로 바꾸어 처리하기.

이 경우 외국 사이트 등을 방문하여 해당 문건에 대해 처리하는 방법에 대한 각종 질의 답변 글을 보면 다음과 같은 방법으로

해결하라고 적혀 있습니다.


 gacutil.exe /u $(ProjectName)

 -> "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /u $(ProjectName)


즉 실행하려면 파일에 대한 전체 경로와 파일명을 넣어주고 처리해주면 된다는 것입니다.

실제로 저 같은 경우에도 프로젝트의 속성에 들어가 빌드 이벤트 항목의 두 문장을 위와 같이 수정했으며

정상적으로 컴파일 되는 것을 확인했습니다.


2. 검색 경로에 포함시키기.

그러나 프로젝트 파일에 대한 수정권한이 없는 경우가 있습니다. 특히 팀 프로젝트를 하게 되는 경우 이 프로젝트 파일을

수정할 수 없습니다. 수정하지 않고 위의 방법을 적용하는 마땅한 방법이 없습니다.

그러나 %PATH% 경로의 내용에 위의 BIN 폴더의 경로를 넣으면 해결됩니다.

방법은 아래와 같습니다.


 - 내 컴퓨터 -> 속성 -> 고급 -> 환경 변수에 들어가 각종 환경 변수 설정 창을 띄웁니다.

 - 시스템 변수 쪽에서 Path 라는 항목을 더블 클릭해서 편집 창을 띄웁니다.

 - 각종 경로들 중 windows 시스템 폴더들을 가르키는 부분 뒤쪽에 넣습니다.
    (위치는 크게 관계 없지만, 가급적 앞쪽으로 배치하는 것이 좋습니다.

      저 같은 경우 %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem; 뒤에 놓았습니다. )  

 - Visual Studio 2005를 다시 시작합니다.


경로를 변경해 본 결과 큰 문제없이 컴파일이 되며 정상적으로 gacutil.exe가 실행된 것을 확인할 수 있었습니다.



마무리

해결방법이라고 두가지를 제시해 드렸지만, 소 뒷걸음 치다 쥐잡은 것과 같은 결과 입니다.

일단 컴파일 중 오류로 나타낸 코드 9009 의 정체는 아직 찾지 못했읍니다.

왜 갑자기 v1.0용 Gacutil.exe를 실행하는 것인지는 모르겠지만,

아마 다른 서버 제품이 설치되어 있어 발생되는 것인지도 모르겠습니다.

(현재 제 개발용 PC내에는 SQL 2005와 SPS 2007이 설치되어 있습니다.)

나중에 더 많은 내용을 알게 되면 추가해서 적어보도록 하겠습니다.



articles
recent replies
recent trackbacks
notice
Admin : New post