/****************************************
커서에들어갈데이터확인
*****************************************/
SELECT
CNT
FROM
(
SELECT 1 CNT
UNION ALL
SELECT 2 CNT
UNION ALL
SELECT 3 CNT
) A
/****************************************
커서에데이터생성
*****************************************/
DECLARE CUR CURSOR
FOR
SELECT
CNT
FROM
(
SELECT 1 AS CNT
UNION ALL
SELECT 2 AS CNT
UNION ALL
SELECT 3 AS CNT
) A
DECLARE @CNT INT
/****************************************
커서에들어있는데이터사용
*****************************************/
OPEN CUR
FETCH NEXT FROM CUR INTO @CNT
WHILE(@@FETCH_STATUS = 0)
BEGIN
SELECT @CNT AS CNT
--
FETCH NEXT FROM CUR INTO @CNT
END
CLOSE CUR
DEALLOCATE CUR
* 이부분(DEALLOCATE CUR)은 try ~catch(예외처리)를 이용하여 오류가 났을때도 꼭 실행해줘야한다.
실행하지 않게되면 다음에 사용할때 같은 alias가 존재한다며 실행되지 않는다.
커서를 이용하여 각 Row의 데이터를 사용할수있다.
테이블 형태로 조회된 값을 활용하기에 적합하다.
하지만 성능이 다소 떨어져 최근에는 잘사용하질 않는다.
그러나 어느순간 꼭 필요할때가 있다. 그때를 대비하여 알아두었으면한다.
저자같은경우 조회된 값들을 이용하여 다른 저장 프로시저에 여러번 호출해야할때 이용한적이 있다.
━━━━━━━━━━━━━━━
by 한상국(han3925)
MAIL han3925@gmail.com
han3925@hotmail.com
BLOG pointnet.tistory.com
━━━━━━━━━━━━━━━
닷넷채널 11호
링크 : http://www.winkey.pe.kr/MaillerContent/20070717/index.aspx
* 이번 특집 기사는 Taeyo.NET에 주로 활동하고 있으신 김석중 MVP님의 글을 실었습니다.
Silverlight와 관련된 글을 써주셨는데 직접 활용할 수 있는 소스도 함께 제공되고 있습니다.
이 글은 태요닷넷(www.taeyo.net)과 함께 동시에 기제되어습니다.
- 훈스닷넷 정기 세미나 후기 (한상국)
닷넷채널 9호 링크
9호에서는 대폭 변경된 IIS7.0에 관한 특집을 비롯해서 다양한 내용을 준비했습니다.
- 훈스닷넷 세미나 후기 기재 (한상국)
도대체 SOA란 무엇인가?
SOA는 서비스들이 중심인데, 여기서 서비스란 비즈니스 프로세스(예를 들면, 신용카드 거래를 인증하거나 구매 주문을 처리하는 일)를 수행하는 일련의 소프트웨어 컴포넌트들을 말한다. 가장 단순한 형태의 SOA는 네트웍 상에서 서로 통신을 하는 일련의 서비스들을 들 수 있다. 그 서비스들은 느슨하게 연결되어 있고(다시 말해 한 애플리케이션이 다른 애플리케이션과 대화하기 위해 그 애플리케이션의 기술적 세부사항을 알 필요는 없다는 의미), 잘 정의된 플랫폼 독립적 인터페이스들을 갖고 있으며, 재사용이 가능하다. SOA는 애플리케이션 개발 과정에서 더 높은 층을 의미하며[굵은 입도(coarse granularity)로도 불림], 비즈니스 프로세스에 초점을 맞추고 표준 인터페이스를 사용함으로써, IT 환경이 가진 근본적인 기술적 복잡성을 덮어준다. 이것은 고등학교 과학 교과서를 유치원 아이들에 맞게 번역하는 것과 같다. 다시 말해 심장의 승모판과 폐정맥을 다루지 않고도 심장이 피를 보내는 일에 대해 아이들에게 설명할 수 있는 것과 같다.
SOA는 코바에 새 옷을 입힌 것이 아닌가?
아니다. SOA는 기존의 밀접하게 결합된 애플리케이션 연결[코바(Corba: common object request broker architecture)]에서 느슨하게 결합된 애플리케이션 연결[웹서비스(Web services) 같은 것]로 진화한 것이다. 밀결합될 경우, 애플리케이션들은 변화하는 비즈니스 요구에 적응하기가 힘들어지는데, 하나의 애플리케이션을 손보면 이 애플리케이션에 결합된 다른 애플리케이션들도 모두 손봐야만 하기 때문이다. 또한 코바 같은 객체 중심(object-oriented) 개발방식은 가는 입도(finer level of granularity)를 사용하기 때문에, 객체들은 직원이나 고객 주문 수준에서 정의될 필요가 있다. 반면 SOA의 경우, 서비스는 더 추상적인 수준(예를 들면, 전화고지서를 찍어내는 등의 비즈니스 프로세스 수준)에서 정의된다.
|
SOA 용어정리 엔터프라이즈 서비스 버스(Enterprise service bus): 소프트웨어 인프라로, 표준 인터페이스와 메시징을 사용해 애플리케이션들을 통합한다. SOA를 구현하는 한 가지 방법(주: 가트너의 보고서에 나온 이 용어는 비교적 새로운 것이다.) 느슨한 연결(Loosely coupled): 잘 정의된 인터페이스들을 사용해 서비스들을 연결하는 것. SOA는 느슨하게 연결된 접근법을 사용해 구축되는데, 이 방법을 사용하면 1개 서비스를 손보더라도 이 서비스에 연결된 다른 서비스들을 손볼 필요가 없어진다. 메시지 중심 미들웨어(MOM: Message -oriented middleware): 때때로 메시지 중심 아키텍처(message-oriented architecture)로도 불리는 MOM은 여러 애플리케이션들, 심지어 이기종 플랫폼들의 애플리케이션들을 연결하기 위한 메커니즘을 제공한다. 데이터는 메시지 대기열(queues)에 위치하게 되며, 따라서 애플리케이션들은 데이터를 보내는 애플리케이션들에 대한 직접적인 연결선을 만들지 않고도 데이터를 검색할 수 있다. 출판-가입(Publish-subscribe): 한 서비스가 요청하면(또는 ‘가입하면’) 다른 서비스가 올리는(또는 ‘출판하는’) 시스템. 출판된 정보가 변경되면, 가입한 서비스들은 자동으로 업데이트된 데이터를 수신한다. 서비스 중심 아키텍처(SOA: Service-oriented architecture): 잘 정의된 인터페이스들을 가진, 재사용이 가능한 일련의 컴포넌트들로 구축되는 기술건축방식. |
SOA 도입에 따른 이익은?
SOA는 대부분의 기업에서 발견되는 ‘모든 것을 갖고 있는’ IT 환경을 통합하는 일을 더 쉽게 해 준다. “이것이 SOA가 제시하는 가장 큰 가치 가운데 하나다. 다시 말해 SOA는 이기종 환경에서 아주 잘 작동한다.”고 웹서비스 컨설팅 회사인 잽씽크 사의 선임분석가 제이슨 브룸버그는 말한다. SOA를 통하면, 개발자들은 애플리케이션들을 연결하는 새로운 코드를 작성하기 위해 과도한 시간을 낭비할 필요가 없어진다. 대신 개발자들은 웹서비스 같은 표준 프로토콜을 사용할 수 있다. 그리고 SOA 코드의 상당 부분은 재사용이 가능하기 때문에 개발 비용도 줄어든다. SOA는 CIO가 기존에 리거시에 투자했던 것(SAP, 시벨, 오라클 등)을 한데 묶어 더 잘(그리고 저렴하게) 활용할 수 있게 해 준다.
“SOA가 좋은 점은 기존의 포트폴리오를 활용할 수 있게 해 준다는 것이다.”라고 IT 컨설팅 회사인 실크로드 사의 사장 팀 바스는 말한다. CIO는 기존 시스템을 제거하고 새로운 시스템으로 대체할 필요가 없어진다. 기존 시스템의 기능들을 파악한 후 그것들을 활용함으로서, CIO는 위험을 최소화하면서 기존 IT 투자의 가치를 극대화할 수 있다고 바스는 말한다. 또 서비스[예를 들면, 단순객체접근프로토콜(SOAP: simple object access protocol)과 웹서비스기술언어(WSDL: Web services description language) 등을 사용하는 서비스]를 구축하면, 내부 프로세스가 부드러워질 뿐만 아니라, 고객과 비즈니스 파트너들과는 회사의 방화벽을 넘어서 더 쉽게 정보를 공유할 수 있게 된다.
SOA의 또 다른 이익은, SOA가 IT 스탭들로 하여금 기술 아키텍처가 아니라 비즈니스 아키텍처 측면에서 생각하도록 강요하기 때문에, CIO와 비즈니스 중역들 사이의 대화를 더 매끄럽게 해 줄 수 있다는 것이다. 예를 들어, 만약 비즈니스 측이 개선된 재고관리 시스템을 구축하고자 한다면, 비즈니스 측의 실무진은 비즈니스 흐름에 기반해 그것을 설계하는 최고의 방법과 비즈니스의 요구를 만족시키는 최선의 방안에 대해 IT 설계사들과 이야기할 수 있다. 그리고 그 디자인을 실제로 구현하는 일도(이 일은 종종 대규모의 통합 작업이 수반되는데) 훨씬 쉬워진다.
이런 대화가 유용성을 가지려면, 비즈니스 측도 그들의 비즈니스를 운영하는 최선의 방법에 대해 생각해야만 한다. 예를 들면, 고객을 최대로 수용하기 위해 구축할 필요가 있는 프로세스들은? 고객 서비스 수준을 높일 수 있는 방법은? 등이다. 기존의 사일로화된 애플리케이션들을 넘어서 정보를 전달하고 공유함으로써, 기업은 실시간으로 더 많은 비즈니스 성과 데이터를 추출할 수 있어 비즈니스 지능을 높일 수 있다. 또 공통의 아키텍처를 통할 경우, 기업의 반응 수준은 획기적으로 높아진다고 양키 그룹의 선임분석가 다나 가드너는 말한다. “미동부해안에서 허리케인이 발생할 경우, 그 결과로 미국의 다른 지역에서 합판을 옮겨야 할 필요성이 크게 높아질 것이다. 이에 대해 기업은 실시간으로 반응할 수 있다.”고 그는 말한다. “기업은 비즈니스에서 일어나고 있는 일에 대한 정보(이전에는 갖지 못했던 정보)를 갖게 된다.” SOA가 완벽하게 구축된다면, 변화하는 비즈니스 요구와 매순간 바뀌는 시장 조건들에 대한 기업의 적응력은 크게 높아질 것이다.
마지막으로 통합이 쉬워지고 민첩성이 높아짐으로써 ROI가 높아진다는 부수적 이익도 맛볼 수 있다. 부스카드는 SOA 투자에 대해 200%의 ROI를 달성했다고 말한다. AXA 파이낸셜의 가장 인기있는 SOA 기반 서비스 가운데 하나는 겟클라이언트(Get Client)로, 이를 통해 고객대면의 전방처리 애플리케이션은 모두 명령어를 발행할 수 있는데, 그러면 그 명령어는 리거시 시스템들을 모두 훑어본 후 특정 고객의 투자에 대한 완벽한 그림을 창출해 낸다. 겟클라이언트 사례는 AXA가 ROI를 달성하는 방법 가운데 하나라고 부스카드는 말한다. 다시 말해 개발자들은 모든 종류의 전방처리 시스템들과 작동하기에 충분할 만큼의 일반적인 형태의 서비스를 디자인할 수 있으며, 이로 인해 개발시간이 단축되고 개발자들은 비즈니스 솔루션에 더 많은 시간을 쏟을 수 있게 된다. 여기에 IT 스탭들은 새 기술을 SOA에 쉽게 결합할 수 있어, 위험과 비용을 줄이면서 새 애플리케이션의 개발 속도를 높일 수 있다.
웹서비스가 SOA에서 하는 역할은?
우선 SOA는 웹서비스를 반드시 필요로 하는 것이 아니라는 점, 그리고 웹서비스도 SOA 없이 배포될 수 있다는 점을 주목할 필요가 있다. 그러나 웹서비스를 이용해 SOA를 구축하는 것이 가장 이상적인 방법이라고 생각하는 사람도 있다. 가트너의 톰슨이 이런 사람 가운데 하나다. 그러나 그는 SOA를 구축하려면 먼저 웹서비스를 제대로 구현해야만 한다고 경고한다. 만약 정확하게 구현되어 있다면, 그 웹서비스는 SOAP와 WSDL을 사용하는 SOA와 다름이 없다.
이에 반해 부스카드는 웹서비스 없이 SOA를 구축했는데, 이 시점에서 회사 내외부 고객 가운데 어느 누구도 그것을 요청하고 있지 않기 때문이다.(하지만 그는 나중에 그런 요청이 들어올 경우를 대비해 항상 촉각을 곤두세우고 있다.) 대신 그는 아이비엠의 웹스피어 MQ를 메시징 및 통합층으로 사용해 리거시 시스템들을 전방처리 애플리케이션들과 결합하고 있다. 동시에 그는 캔들 사의 패스와이(PathWAI) 수트를 함께 사용하고 있는데, 이 제품은 웹스피어 MQ의 성능을 모니터함으로써 웹스피어 MQ의 최적화를 도와준다.
노스롭 그룸만 미션 시스템의 수석엔지니어 존 존슨도 웹서비스 없이 출판-가입 시스템에 기반한 SOA를 구축했다.<’SOA 용어정리’ 박스 참조> 그는 웹 서버와 애플리케이션 서버의 최상부에 메시징 계층으로서 자바 메시지 서비스를 설치했으며, 통합 작업과 데이터 이동 작업을 돕기 위해 소닉 소프트웨어 사의 엔터프라이즈 서비스 버스를 사용하고 있다. 존슨은 그 서비스들이 웹서비스처럼 설계되어 있지만, 웹서비스 인터페이스들을 사용하고 있지는 않다고 말한다.
SOA의 큰 이점 가운데 하나는 정확한 데이터를 필요한 사람이나 애플리케이션에 전달해 준다는 것이라고 존슨은 말한다. 예를 들면, 한 사용자가 ID를 사용해 로그인을 할 때, 시스템은 그 사용자가 누구인지를 확인한 후 그 사람이 볼 수 있도록 허용된 데이터(예를 들면, 지도와 업무 리스트)를 전달해 준다.
도전과제는 무엇인가?
보안이 가장 큰 과제다. “개방형 환경보다는 폐쇄형 환경을 보호하는 일이 항상 더 쉽다.”고 실크로드의 바스는 말한다. CIO는 웹서비스의 보안 표준들이 아직 확정되지 않았다는 점을 먼저 인지해야만 한다.<’계산된 위험(www.cio.com/archive/100103/risks.html)’ 박스 참조> 이런 보안 문제 가운데 몇 가지를 극복하려면, SOA를 구축할 때 높은 수준의 보안을 요구하지 않는 비즈니스 프로세스들에 우선 초점을 맞추는 식으로 천천히 진행하는 것이 좋다고 바스는 조언한다.
서비스 구성과 관련된 복잡한 일들을 관리하는 것 또한 까다로운 일이 될 수 있으며, 따라서 탄탄한 SOA 지배구조 모델이 필요하다고 바스는 말한다. 예를 들면, 서비스 중심적인 노드들을 네트웍에 갖고 있으며 100명의 사용자가 특정 인터페이스들을 사용하고 있을 경우, 만약 누군가 그 인터페이스를 변경한다는 결정을 내린다면 어떻게 다른 사용자들과 통신을 할 것인가?
또 다른 이슈는 네트웍 모니터링이다. “SOA를 통해 복잡한 인터넷 중심의 비즈니스 프로세스들을 조율하는 능력을 갖춘다는 말은 동시에 복잡한 모니터링과 감사 역량도 갖춰야 한다는 말이다.”라고 바스는 말한다. 예를 들면, 서비스 중심 네트웍에서 거래처리 작업 하나가 잘못될 경우(이 경우 여러 서비스 제공업체가 관련될 가능성이 높은데), 무엇이 잘못된 것인지, 어디에서 그것이 잘못된 것인지, 또는 누군가 네트웍에 잘못된 정보를 입력한 것인지를 파악하는 일이 아주 어려울 수 있다. “현재의 웹서비스 기술 표준들은 겉으로 드러나는 사항들만 다루고 있을 뿐이어서, 이 서비스 중심의 이상적인 분산 협업, 프로세스 조율, 모니터링 목표를 현실로 만들기에는 아직 부족한 면이 많다.”고 바스는 말한다.
마지막으로 비용 문제가 있다. SOA를 구축하는 것은 결코 값싼 일이 아니다. 기존 시스템 아키텍처를 리엔지니어링하기 위해서는 상당한 돈이 들어갈 것이다. 또 상당한 수준의 인적자산이 필요할 것이다. 예를 들면, 비즈니스 프로세스를 설계하기 위한 비즈니스 분석가, 프로세스들을 설계도로 만들기 위한 시스템 아키텍트, 새로운 코드를 개발하기 위한 소프트웨어 기술자, 그 모든 사람을 조율하기 위한 프로젝트 매니저 등이다.
SOA를 구축하는데 있어 일반적으로 수용되는 베스트 프랙티스가 있는가?
말할 필요도 없는 것처럼 들릴지 모르지만, SOA를 위한 청사진을 확보하는 것은 정말 중요한 일이다. 기업, 특히 여러 비즈니스를 펼치고 있는 대기업에서 전반적인 계획 아래 어떻게 그것이 들어맞을 것인가를 고려하지 않고 신기술을 구매하거나 애플리케이션들을 통합하는 일은 다반사로 일어난다. 따라서 SOA를 구축하는 것과 관련해 가장 큰 과제 가운데 하나는 사람들(IT와 비즈니스 양측 모두)로 하여금 그 아키텍처 목표들에 초점을 맞추도록 만드는 것이다.
그리고 CIO는 제공해야 할 정확한 수준의 서비스를 파악할 필요가 있다. 그리고 그런 서비스는 너무 가는 입자도를 가져서는 안된다. 그렇게 되면, 더 높은 비즈니스 프로세스 수준에서 기능을 발휘한다는 그 서비스의 목표가 훼손되기 때문이다. 다시 말해 초점을 너무 좁게 잡으면 더 많은 서비스가 필요하게 되고, 이것은 다시 개발 시간을 증가시킨다. 최악의 경우, 너무 많은 서비스가 네트웍에 흐를 수 있게 된다.
또한 CIO는 가장 큰 유용성을 보이는 곳에서 SOA를 사용해야 할 것이다. 바스는 SOA를 구현할 때 서비스 품질(QoS: quality of service)도 고려할 필요가 있다고 지적한다. 거의 실시간에 가까운 반응속도를 요구하지 않는 시스템에서는 느슨하게 연결된 아키텍처가 좋다고 바스는 말한다. 제시간에 필요한 정보를 얻지 못할 경우, 그 결과가 재앙이 아니라 사소한 문제로 그치는 그런 시스템을 골라 SOA를 적용한다.(예를 들면, SOA를 토대로 항공교통 제어 시스템을 구축한다는 것은 나쁜 생각이다.)
|
아키텍처에 대한 더 많은 정보 신기술에 대해, 그리고 SOA의 사촌인 웹서비스와 기타 협업 도구에 대해 더 많이 알고 싶다면, 태동기술 연구센터(Emerging Technology Research Center, 64.28.79.79/research/current/)를 참조 관련 정보 혼성 애플리케이션: 새로운 비즈니스 모델을 위한 자산 활용법(Composite Applications: Leveraging Assets for New Business Models, www2.cio.com/analyst/report1726.html) 웹서비스: 보편적인 통합이 비즈니스 서비스에 파워를 더해 준다(Web Services: Universal Integration Powers Business Services, www2.cio.com/consultant/report1641.html) SOA로의 오솔길(The pathway to a service-oriented architecture, www.computerworld.com/developmenttopics/ |
CIO들은 SOA에 대해 생각하고 있는가?
많은 CIO가 SOA에 대해 심각하게 고려중이다. 특히 웹서비스를 시험중인 CIO들이 그렇다. SOA의 잠재적 효과가 아주 매혹적이기 때문이다. 민첩성 증대, 통합 속도 증대/비용 절감, 기존 IT 자산의 활용, 비즈니스 프로세스에 대한 집중 등 그 이익은 아주 많다.
물론 SOA를 구축하려면 상당한 투자를 해야 한다. 또 아직 성숙하지 않은 웹서비스 시장과 관련해 많은 문제가 해결되지 않고 있는 상태다. 하지만 최소한 SOA는 전략적 측면에서 계속 주목할 만한 가치가 있다
=======================================================================
출처 : CIO코리아
| [이재권]IT개발자, ''제2의 전태일'' 될라 |
이재권 논설실장 jaylee@inews24.com  |
| ''고등학교시절 전국컴퓨터경진대회에서 2등을 했지만 이과 대신 문과를 갔습니다. 그 이유를 이 글이 모두 설명해주는군요.'' ''컴퓨터공학과를 올해 2월 졸업한 학생입니다. 국비 지원까지 받아 외국 가서 IT기술을 배우기도 했습니다. 하지만, 과감히 개발자의 길을 포기했습니다. 정말 이 나라에서는 개발자에게 미래가 없습니다. 개발자의 길을 포기한 걸 정말 잘했다고 생각합니다.'' ''IT 공부하는 학생입니다. 이번에 졸업인데, 이 글 보니까 걱정 많이 됩니다. 공무원 준비나 할까...'' ''정말 힘든 건 애들이 전화해서 거의 울다시피 하면서 ''아빠 보고 싶어, 언제 와'' 할 때입니다. 이러면 정말 일할 맛 안 납니다.'' 지난 10일 다음의 ''블로그뉴스''에 오른 글 한 편이 커다란 반향을 일으키고 있다. 제목은 ''IT맨, 내가 사직서를 쓴 이유''(http://blog.daum.net/moveon21/5423451).  이 글에는 요즘 흔해 빠진 사진이나 동영상 하나 붙어 있지 않다.분량도 A4 용지로 6장이나 된다. 글에 ''양념''도 없고 장황해서 재미없는 축에 든다. 끝까지 다 읽으려면 작심해야 한다. 그런 글을 무려 9만9천672명이 읽었다. 댓글도 621개가 달렸다. 11일에는 아이디 ''푸른바다''가 이 글을 퍼다가 다음 아고라의 ''네티즌 청원''에 띄웠다. ''노동부 건의''를 겨냥한 이 청원에는 현재 1천878여명이 서명했다. 목표는 1만명. 이 글은 누가 쓴 글인지 알려져 있지 않다. 하지만, 내용에 진실 성이 엿보인다. 621개의 댓글 중, 그 흔한 ''안티성 댓글''이 거의 없다. 희한할 정도다. 압도적으로 많은 댓글이 공감, 또 다른 문제 제기, 원인 분석, 대안을 말한다. 이 글과 댓글들이 교감하는 분위기 또한 매우 엄숙하고 진지하다. 이 정도면, 이 글은 한 개인의 사사로운 넋두리를 넘어섰다. 공적 가치를 얻고, 보편적인 공감대를 가졌다는 뜻이다. 도대체 무엇이 이 글로 하여금 그 같은 울림을 갖게 했을까. 이 글을 쓴 사람은 프로그래밍 언어 C/C++를 다루는 이른바 ''IT개발자''다. 그는 20대 초반이던 2000년 7월 프로그래머로 취업했다. 그런데 그는 ''이 땅에서 다시는 개발자 일을 안 한다''고 결심하고 지난 5월 사직서를 던졌다. 사직의 이유는 ''살인적인 노동환경'' 때문이란다. 그는 입사 초기엔 직장에서 날밤 새면서 프로그램을 짜도 그러려니 했다. 오히려 멋있어 보였다. 철야 작업을 ''진정한 프로그래머의 세계''라고 생각하기도 했다. 그러나 IT개발자로서 만 7년을 지낸 뒤 그가 다시 정의내린 프로그래머의 세계는 ''탈출하고 싶은 지옥''으로 바뀌었다. 정상 근무일, 오전 9시~오후 6시 근무 기준으로 두 달 걸릴 프로젝트는 항상 한 달로 뚝 줄어서 일이 떨어진다. 인력도 필요 분의 절반 밖에 배정되지 않는다. 이 ''반토막의 법칙''은 그가 직장을 옮겨도 어디나 다 똑같았다. 그 결과는? 기계도 감당하기 힘든 야근, 철야의 연속이다. 시간과 인력을 절반 밖에 주지 않고 프로젝트를 끝내라고 하면, 방법은 달리 없다. 토·일요일도 반납하고 야근·철야하는 수 밖에. 사규에는 ''회사가 주말 출근과 야근을 요구할 때 직원은 흔쾌히 동의한다''는 규정까지 있다. 야근 수당, 주말 출근 수당조차 그는 여태 받아보지 못했다. IT개발자 세계의 비정함도 그는 여러 차례 맛봤다. 한 달 내내 출근했는데, 추석에도 출근하래서 안 나간 적이 있다. 그랬더니 원청 업체 담당자가 그의 회사 사장에게 시말서를 쓰라고 했단다. 프로젝트를 제때 끝내고 6시 ''칼퇴근''을 몇 번 했더니 연봉협상 때 사장이 "그땐 별로 힘들게 일 안 했잖아"라는 소리를 했다. 일하면서 알러지성 폐질환을 얻었지만 ''쟤는 왜 저리 빌빌대냐''는 수근거림을 들어야 했다. 그가 내린 결론은 ''IT개발자는 싸게 사용하고 버리면 되는 도구''였다. 그가 마지막으로 받은 8년차 연봉은 4천만원 가까이. 퇴사 전 꽤 괜찮은 회사에서 연봉 4천500만원을 제시받았다. 하지만 그는 거절했다. 아침 9시 출근해서 밤 12시 퇴근하고, 한 달에 이틀 쉬는데 그마저 건너뛰기 일쑤고, 국경일 모두 출근하고 설날도 하루만 쉬는 회사였다. ''거기가 거기''인 셈이었다. 이런 관행과 문화가 IT개발자의 세계에 구조화돼 있는 것에 그는 절망했다. 그는 7년을 견뎠지만, 앞으로도 그런 관행이 개선될 전망을 발견하지 못했다. 끝내 사직서를 던졌다. 그가 쓴 ''IT맨, 내가 사직서를 쓴 이유''에 나타난 IT개발자의 처지는 사실 새삼스러운 게 아니다. 15년, 20년 된 개발자들도 댓글에서 ''예나 지금이나 바뀐 게 없다''고 하는 걸 보면 정말 해묵은 문제다. 언론도 이따금 IT개발자의 열악한 근무환경을 조명하며 이슈화한 바 있다. IT개발자들의 세계 내부에서도 비판적 문제제기가 수도 없이 있었을 것이다. 그러나 많은 세월이 지나도 본질적으로 개선된 것은 없다. 분신노동자 전태일은 17살이던 1965년 청계천 평화시장 노동자로 일하기 시작했다. 전태일은 자신도 그랬지만, 열두어 살의 어린 소녀들이 점심을 굶어가며 먼지 구덩이 다락방 작업장에서 온종일 햇빛도 못 보고 쏟아지는 졸음을 막기 위해 타이밍 약을 먹고, 뾰족한 바늘로 제살을 찌르며 일하는 것을 지켜봐야 했다. 하루 14~16시간을 일하고 일당으로 고작 70~80원(당시 다방의 커피 한잔에 50원) 을 받는 열악하기 짝이 없는 조건이었다. 요즘 IT개발자가 일하는 현실은 컴퓨터가 있는 풍경을 빼면, 전태일 시절의 평화시장과 많은 점이 흡사해 보인다. IT개발자들은 기본적인 권리도 보장받지 못하고 있고, 건강을 해치고 병을 얻을 정도로 고된 작업시간에 지칠 대로 지쳐 있다. IT개발자들이 반드시 이렇듯 열악한 조건에서 일해야 할 이유는 없다. IT개발업무의 특수성을 들먹이며 어쩔 수 없다는 현실론을 내세우는 축도 있다. 하지만 그리 타당해 보이지 않는다. 선진국은 물론이고 개도국에서도 IT개발자를 휴일 없이 출근시키고, 잠을 3~4시간만 재우는 나라는 없다. 외국에서 IT개발자는 다른 직업과 크게 다르지 않다. 한국 IT개발자의 세계는 60, 70년대식 ''평화시장 여공'' 부려먹듯 하는 관성이 오늘에도 되풀이되는 것일 뿐이다. 정말 걱정스러운 것은, 지금 우리 IT개발자들에게 ''전직, 탈출만이 살길''이라는 심리가 갈수록 확산되고 있다는 점이다. 과거엔 체념하고 고된 현실에 적응하며 살았지만, 지금은 달라졌다. 결혼한 IT개발자는 가정파탄의 ''실제적 위협''에 직면해 있고, 맞선 본 총각 IT개발자는 자신이 프로그래머임을 밝히는 순간 얼굴이 굳어지는 처녀를 보게 된다. 이런 분위기 속에서 IT개발자들은 자신의 직업을 계속할 이유와 의미를 찾기가 갈수록 힘들어진다. 때문에 직업을 아예 IT와 무관한 쪽으로 바꾸는 사람들이 속출한다. 외국어를 열심히 배워서 IT이민을 간 사람들은 성공담을 들려주며 ''한국을 떠나라''고 권유한다. 그 통에 실제로 이민 가는 IT개발자들이 크게 늘었다. 요즘 IT개발자 구하기 힘들어진 이유다. 어디 그 뿐인가. IT개발자의 길을 걷겠다는 새싹들에게는 주변에서 만류 일색이다. 컴퓨터공학과, 전산학과는 가장 인기 없는 과가 된지 오래다. 신입 개발자 10명중 8명은 취업 후 1~2년만에 그만둔다는 얘기도 널리 퍼져 있다. 있는 사람은 속속 떠나고, 신규 유입은 없는 분야가 IT개발자의 세계로 변해가고 있다. IT개발자들은 ''프로그래머, 신이 내린 마지막 노가다''라고 자조하고 있다. IT개발자는 IT생태계에서 뺄래야 뺄 수 없는 중요한 축이다. 온갖 IT시스템, IT서비스를 실제로 구현하는 것을 IT개발자들이 떠맡고 있기 때문이다. 지금처럼 IT개발자들이 절망해서 앞다퉈 전직, 탈출할 경우 장차 한국의 IT생태계는 심각한 공백상태를 맞을 수도 있다. IT개발자의 문제는 IT한국의 미래에도 심각한 그늘을 드리운다. IT개발자들의 세계가 이렇게 무너져 가는 것을 과연 언제까지 방치해야 할까? 인도 등지에서 데려와 메우면 된다고? 이제는 인도 개발자들도 사정을 알고, 한국을 기피대상으로 여긴다고 한다. 이걸 떠나서, 외국인력을 대안으로 보는 시각 자체가 바람직하지 않다. 세계적 수준의 IT개발인력을 육성하고 그들이 능력을 발휘할 수 있는 기회와 여건을 만들도록 문제를 해결하는 게 옳다. 우수한 국내 인력을 절망케 하여 내쫓고, 빈 자리를 외국인력으로 메운다는 것은 국력의 기회손실을 낳는 꼴이다. 더 늦기 전에, 지금이라도 노동부·정통부 등 관계부처가 나서서 손 쓸 필요가 있다. IT프로젝트가 이뤄지는 발주기업-원청기업-하청기업에서 벌어지는 불공정한 사례는 없는지, 하청기업 종사자들의 근로조건이 법 테두리를 벗어나지는 않은지 점검하고 개선조치를 취해야 한다. IT기업들 역시 지금처럼 우수인력을 내쫓는 ''착취적'' IT프로젝트의 구조와 관행을 과감하게 뜯어고치는 쪽으로 발상을 전환해야 한다. 전국 수십만의 IT개발자들이 지금도 속으로 ''악덕 기업''을 성토하고 있음을 귀 열고 들어야 한다. 한 개발자는 냉소적으로 이렇게 말한다. ''한국이 좋은 점이라면 외국에서는 한국처럼 경력 쌓기 불가능합니다. 그렇게 일할 기회가 전혀 없으니까요. 그러니, 노예처럼 구르더라도 자기 분야에서 실력 닦으세요. 한국서 3년 구르면 고급기술자 됩니다. 외국에서 충분히 인정받죠. 영어나 틈틈이 공부해 두시고, 적당한 시기에 이민가세요. 선진국에서 프로그래머는 해볼 만한 직업입니다. 기업들이 문제에요. 인력을 장기적으로 쓸 생각 안하고 몸 망가지더라도 당장 혹사시켜 써먹고 뒷 일은 신경 안 쓰는 한국기업 정말 나쁩니다. 다 나오세요. 기업들 정신차리게.'' 출처 : http://hoons.kr board에서.. |
