내 남자의 길~!

최근 그 어느 때보다도 다양한 언어에 대한 관심이 높아지고 있습니다. 자바는 JRuby, 그루비(Groovy), 스칼라(Scala) 등을 통해 언어를 넘어 플랫폼으로 발전하고 있고, 닷넷은 CLR(Common Language Runtime), DLR(Dynamic Language Runtime)을 통해 다양한 언어를 지원하고 있습니다. 또한 동적 언어와 함수형 언어에 대한 관심도 뜨겁습니다.

• 의도적으로 디자인 패턴을 마음껏 사용해 보는 것은 어떨까요?
• 루비 등의 오리 타입(Ducking Type)을 한번 써보세요. 타입으로서 인터페이스는 과연 어떤 의미를 지니고 있는 것일까요?
• 함수형 언어를 이용해 작성하면 프로그램이 어떤 모습이 될까요?
• 자바스크립트로는 어떻게 프로그램을 구조화할 수 있을까요, 클래스 상속을 사용할까요, 프로토타입 기반 상속을 사용해 볼까요?

제가 자바로 작성해 본 간단한 예제가 있습니다. 어떤 언어, 어떤 방법도 좋습니다. 다양한 언어의 상상력에 여러분의 상상력을 더해 주세요.

마지막으로 여러분이 작성한 코드를 공유해 주세요. 블로그에 작성한 코드를 정리한 후, http://innolab.tistory.com/1173513751에 댓글이나 트랙백을 남겨주시거나 이메일(dwkorea@kr.ibm.com)로 보내주시면 됩니다. 창의적인 코드를 보내주신 분에게는 일정 기간에 한 번씩 선물도 드릴 예정입니다.

package codekata;

public interface Shape {
	public void draw();
	public void moveTo(int x, int y);
	public void moveBy(int dx, int dy);
}
 

package codekata;

public abstract class AbstractShape implements Shape{
	protected int x;
	protected int y;
	
	public void moveTo(int x, int y){
		this.x = x;
		this.y = y;
	}
	
	public void moveBy(int dx, int dy){
		this.x += dx;
		this.y += dy;
	}
	
	public String toString(){
		return "[X : " + x + " Y : " + y + "]";
	}
}
 

Package codekata;

public class Rectangle extends AbstractShape{
	private int width;
	private int height;

	public Rectangle(int x, int y, int width, int height){
		this.x = x;
		this.y = y;
		this.width = width;
		this.height = height;
	}
	
	@Override
	public void draw() {
		System.out.println("Drawing Rectangle - " + this.toString());
	}
	
	public String toString(){
		return super.toString() + " [Width : " + this.width + ", Height : " + this.height + "]";
	}

	public int getWidth() {
		return width;
	}

	public void setWidth(int width) {
		this.width = width;
	}

	public int getHeight() {
		return height;
	}

	public void setHeight(int height) {
		this.height = height;
	}
}
 

Package codekata;

public class Circle extends AbstractShape{
	private int radius;
	
	public Circle(int x, int y, int radius){
		this.x = x;
		this.y = y;
		this.radius = radius;
	}

	@Override
	public void draw() {
		System.out.println("Drawing Circle - " + this.toString());
	}
	
	public String toString(){
		return super.toString() + " [Radius - " + this.radius + "]";
	}

	public int getRadius() {
		return radius;
	}

	public void setRadius(int radius) {
		this.radius = radius;
	}
}
 

Package codekata;

public class Test {
	private static void doPolymorphicOp(Shape shape){
		shape.draw();
		shape.moveBy(10, 20);
		shape.draw();
		shape.moveTo(100, 130);
		shape.draw();
	}
	
	public static void main(String[] args) {
		Shape[] shapes = new Shape[]{new Rectangle(0, 0, 10, 15), new Circle(10, 10, 5)};
		
		for (Shape shape : shapes) {
			doPolymorphicOp(shape);
		}
	}
}
 

알고리즘은 아랍의 수학자 알콰리즈미 ( al-Khw ā rizm ī ) 의 이름에서 유래한 것으로 유한한 단계를 통해 문제를 해결하기 위한 절차나 방법을 말합니다. 쉽게 말해 어떤 문제를 해결하기 위해 사용 가능한 방법이란 뜻이죠. 여러분이 어떤 문제를 프로그래밍 언어를 통해 해결해 냈다면, 그 문제를 해결할 수 있는 한 가지 알고리즘 ( 문제 해결을 위한 절차 ) 을 찾아냈다고 보셔도 됩니다.

퀴즈 1. 프로시저 Both 를 완성해 봅시다.

우선 한 가지 문제를 해결해 볼까요? Listing 1 은 두 ArrayList 데이터 내에서 공통 원소만을 뽑아 모으는 프로시저, either 를 자바 언어를 이용해 만든 것입니다. 만일 두 ArrayList 내의 모든 원소를 합쳐 모으는 프로시저, both 가 필요하다면 어떻게 하면 좋을까요?

import java.util.*;
  public class FirstQuizSet {
    public static ArrayList both(ArrayList xs, ArrayList ys) {
      // TODO: 이 곳을 채우는 문제입니다.
    }

  public static ArrayList either(ArrayList xs, ArrayList ys) {
    ArrayList eitherList = new ArrayList();
    Object y = null; Iterator elems = ys.iterator();
    while (elems.hasNext()) {
      y = elems.next();
      if (xs.contains(y)) eitherList.add(y);
    }
    return eitherList;
  }

  public static ArrayList toArrayList(int[] xs) {
    ArrayList ys = new ArrayList();
    for (int i = 0; i < xs.length; i++) ys.add(new Integer(xs[i]));
    return ys;
  }

  public static void main(String[] args) {
    int[] xVec = { 1, 3, 4, 5, 6, 9, 7 };
    int[] yVec = { 4, 5, 8, 9, 10, 15, -1 };
    ArrayList xs = toArrayList(xVec); ArrayList ys = toArrayList(yVec);
    System.out.println( both(xs, ys) ); System.out.println( either(xs, ys) );
  }
}

[1, 3, 4, 5, 6, 9, 7, 8, 10, 15, -1] ß both 의 실행 결과
[4, 5, 9] ß either 의 실행 결과

첫 번째 퀴즈인 both 를 해결하셨나요? 실행 결과는 제대로 나오구요? 축하드립니다.

퀴즈 2. 수행 속도를 높인 fastEither 를 만들어봅시다.

저는 부산 토박이라 서울에서 차를 몰고 어디로 이동해야 하는 상황이라면 항상 네비게이션의 힘을 빌립니다. 그런데 제가 사용하는 네비게이션은 항상 큰길 중심으로 길을 찾아줘서, 지름길을 알고 나면 그 동안 다녔던 길이 비효율적이였던 적이 많더군요. 20 분이면 도착할 거리를 50 분이나 걸려서 다녔던 적도 있습니다.

이처럼 목적지를 향해 가는 길은 하나만 있는 것이 아닙니다. 여러 가지 대안이 존재하기 마련이고, 각 대안마다 나름대로 장점과 단점이 있습니다. 그러므로 단지 그 문제를 해결했다고 해서 만족하는 것은 올바른 프로그래머의 자세가 아니라고 생각합니다. 좀 더 고급 개발자로 올라서려면 원하는 품질을 확보했느냐를 따져보는 습관이 중요합니다.

이번 문제에서 요구되는 품질이 성능이라고 가정해 봅시다. 성능을 중요하게 여기는 문제라면, 위에서 샘플 코드로 소개한 either 프로그램은 만족스럽지 않은 답입니다. 샘플 코드에서 xs 와 ys 가 이미 오름차순으로 정렬되어 있다고 가정하면 훨씬 빠른 프로시저를 만들 수 있기 때문입니다.

아래는 이 아이디어에 바탕을 두고 both 를 개선한 fastBoth 입니다. 같은 방식으로 fastEither 도 한번 만들어보세요. 물론 더 빨리 실행될 수 있도록 하는 아이디어가 생각났다면, 그 방식으로 구현해도 좋습니다.

public class FastEitherQuiz {
  public static ArrayList fastEither(ArrayList xList, ArrayList yList) {
    // TODO: 이곳을 채우는 문제입니다.
  }

  public static ArrayList fastBoth(ArrayList xList, ArrayList yList) {
    ArrayList bothList = new ArrayList();
    final int xSize = xList.size(); final int ySize = yList.size();
    Comparable x, y;
    int order; int xpos, ypos;
    xpos = ypos = 0;
    while ( xpos < xSize && ypos < ySize ) {
      x = (Comparable)xList.get(xpos); y = (Comparable)yList.get(ypos);
      order = x.compareTo(y);
      if (order == 0) {
        bothList.add(x); // or y
        ++xpos; ++ypos;
      } else if (order < 0) {
        bothList.add(x); ++xpos;
      } else {
        bothList.add(y); ++ypos;
      }
  }
  if (ypos == ySize) bothList.addAll( xList.subList(xpos, xSize) );
  else bothList.addAll( yList.subList(ypos, ySize) );
  return bothList;
  }

  public static void main(String[] args) {
    int[] xVec = { 1, 3, 4, 5, 6, 9, 7 };
    int[] yVec = { 4, 5, 8, 9, 10, 15, -1 };
    Collections.sort( xs ); Collections.sort( ys );  // 먼저 정렬을 한 다음,
    System.out.println( xs ); System.out.println( ys );
    System.out.println(fastBoth(xs,ys)); System.out.println(fastEither(xs,ys));
  }
}

[1, 3, 4, 5, 6, 7, 9] ß xs 의 내용 
[-1, 4, 5, 8, 9, 10, 15] ß ys 의 내용 
[-1, 1, 3, 4, 5, 6, 7, 8, 9, 10, 15] ß fastBoth 의 결과 
[4, 5, 9] ß fastEither 의 결과 

다 완성했다면 얼마나 빨라졌는지 반드시 확인해야 합니다. 작성한 코드의 수행 속도를 계산할 수 있는 코드는 다음과 같습니다 ( 즐겨 사용하는 프로파일러가 있다면 해당 프로파일러를 사용해도 좋습니다 ). 과연 여러분이 기대한 만큼 성능이 향상됐나요? 그렇다면 이전 코드에 비해 몇 % 의 성능 향상을 얻으셨나요?

long start = System.currentTimeMillis(); 
// 시간을 잴 코드
long end = System.currentTimeMills();long time = end-start;

이러한 성능 최적화를 수행할 때 주의해야 할 점이 몇 가지 있습니다.

1. 최적화가 필요하다고 확인되지 않았다면 코드를 최적화하지 않는 것이 좋습니다. 최적화에 투입하는 개발자의 노력 역시 중요한 자원이기 때문입니다. 그리고 무작정 “ 이 부분이 느린 것 같으니까, 이렇게 고치면 빨라질 거야 ” 라는 막연한 생각으로 덤벼 들면 안 됩니다. 직접 수행 시간을 확인하거나, 프로파일러를 통해 성능 개선이 필요한 부분을 점검하고, 성능 개선 목표를 정하고, 적용한 기법이 기대한 효과를 얻어 내는지 확인해야 합니다.

2. 최적화를 매우 신중하게 끝맺지 못했다면 버그가 있을 수 있습니다. 그러므로 수정한 코드가 정상적으로 동작함을 반드시 테스트해야 합니다. 늦더라도 정확하게 동작하는 코드가, 빠르면서 버그 있는 코드보다 나은 법입니다.

3. 무작정 빠른 코드를 만들기 위해 전체적인 설계를 깨트리는 일이 있어선 안 됩니다. 사소한 성능 이득을 취하기 위해, 설계 과정에서 고치거나 다루기 쉬운 구조로 잡아놓은 프로그램의 틀을 스스로 깨버려야 한다면, 잃는 것과 얻는 것을 면밀히 검토해야만 할 것입니다. 이런 불행을 피하기 위해서는 설계를 튼튼히 하는 수 밖에 없습니다. 개발 초기에 프로그램 설계나 자료구조, 알고리즘 선택에 집중하게 되면, 정작 코드를 더 빠르게 돌아가도록 고쳐쓸 때, 훨씬 더 쉽게 적은 비용으로 코드 수정이 가능하게 됩니다.

4. 유행하는 기법이나 잘 알려진 속설에 의존하기보다, 스스로 주어진 환경에서 검증된 결과를 믿어야 합니다. 비어있는 메서드나 죽은 코드 없애기, 압축 연산자 사용하기, 반복문에서 불변 코드 빼내기, 반복문 펼치기, String 대신 StringBuffer 사용하기, 어떤 수준의 컴파일 최적화 옵션 사용하기 등 잘 알려진 최적화 기법들이 과연 내가 사용하는 환경에서도 적용될까요? 어떤 기법들은 컴파일러가 알아서 해주는 것을 불필요하게 작업한 것도 있을 것이고, JVM 기술이 발전하면서 오히려 역효과가 나는 것도 있으며, 언어의 버전이 올라가면서 더 나은 최적화 기법이 고안된 경우도 있을 겁니다. 결국 제대로 된 최적화 작업을 수행하기 위해서는, 유연하고, 확장성이 쉬운 구조로 프로그램의 틀을 만드는 큰 관점의 시각과 런타임 최적화 원리나 VM 의 클래스 로딩 절차, 각종 최적화 기법과 그 적용 범위 등을 깊이 있게 이해하는 작고 깊이있는 관점의 시각이 균형감있게 제공되어야 할 것 같습니다.

이처럼 프로시저나 함수 수준에서 해결해야 할 문제라고 하더라도, 성능이라는 한 가지 주제가 더해지면 많은 생각을 하게 되는 문제로 바뀝니다. 데이터나 객체 수준으로 추상화 수준이 올라가고, 고려해야 할 품질 속성이 더 많아지면 그 복잡성이란 이루 말할 수 없겠죠? 그래서 프로그래머란 직업이 평생 학습과 훈련을 반복해야 하는 고된 전문직이라 말할 수 있는 게 아닐까요?

비슷한 유형의 퀴즈 두 개를 더 풀어보는 것으로 이번 연재를 마무리하겠습니다.

퀴즈 3. isSubstring 을 작성해 봅시다.

세 번째 퀴즈는 두 개의 배열을 받아 왼쪽 배열에 들어있는 문자열이 오른쪽 배열에 포함되어 있는지 검사하는 프로그램, isSubstring 을 작성하는 것입니다.

public class PatternTest {
  public static boolean isSubstring(char[] left, char[] right) { ... }
  public static void main(String[] args) {
    char[] first = { ’a’, ’b’, ’c’ };
    char[] second = { ’a’, ’c’, ’b’, ’c’};
    char[] third = { ’a’, ’a’, ’b’, ’c’};
    isSubstring( first, second ); // false
    isSubstring( first, third ); // true
  }
}

퀴즈 4. 프로시저 match 를 작성해 봅시다.

네 번째 퀴즈는 문자열이 들어있는 배열을 받아 열고 닫는 괄호 문자가 짝이 맞는지 검사하는 프로시저 match 를 작성하는 것입니다. 괄호 이외의 문자는 무시하도록 합니다.

public class MatchTest {
  public static boolean match(char[] cs) { ... }
  public static void main(String[] args) {
    char[] first = { ’(’, ’[’, ’<’, ’{’, ’}’, ’>’, ’]’, ’)’ };
    char[] second = { ’(’, ’[’, ’<’, ’{’, ’>’, ’}’, ’]’, ’)’ };
    char[] third = { ’(’, ’a’, ’c’, ’)’, ’[’, ’{’, ’}’, ’]’ };
    match(first); // yes
    match(second); // no
    match(third); // yes
  }
}

자신이 알고 있는 언어의 특성을 마음껏 발휘해 다양한 해답을 만들어 보는 것도 흥미로울 것 같습니다. C 나 리스프 (LISP), 파이썬, 자바스크립트, Haskell, 펄 (Perl), C#, 자바 등이 그 대안이 될 수 있겠죠? 두 가지 이상의 언어를 알고 있다면 두 개의 문제를 각각 다른 언어로 해결하고, 그 언어가 가지는 표현력과 특징이 문제를 해결하는 데 어떤 영향을 나에게 끼치고 있는지를 실험해 보기 바랍니다. 다양한 언어를 다룸으로써 그 언어가 제공하는 패러다임을 경험한 만큼 내 사고가 유연해진 것을 느낄 수 있을 겁니다.

마지막으로 여러분이 작성한 코드를 공유해 주세요. 블로그에 작성한 코드를 정리한 후, 제 블로그에 댓글이나 트랙백 (http://seal.tistory.com/trackback/150) 을 남겨주시거나 이메일 (dwkorea@kr.ibm.com) 로 보내주시면 됩니다. 창의적인 코드를 보내주신 분에게는 일정 기간에 한 번씩 선물도 드릴 예정입니다. 적극적인 참여로 한걸음씩 같이 발전해봅시다

한 용 희 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이라는 연봉 정보 공개 사이트에는 각 직업의 연봉 정보가 공개되어 있다. 먼저 미국의 연봉 정보를 보자.



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



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

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

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

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




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

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


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

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

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

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

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

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

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

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

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



앞으로 우리나라도 경제가 더욱 성장하기 위해서는 미국이 그랬던 것처럼 각 산업에서의 생산성 증가가 이뤄져야 한다. 이러한 생산성 증대는 앞으로는 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

보안은 엔터프라이즈 IT 환경의 중요한 이슈로 많은 기업들이 다양한 보안 솔루션을 도입ㆍ활용하고 있습니다. 방화벽이나 VPN, 안티바이러스 솔루션 등이 보편화되고 있으며, IPS, UTM 등의 도입을 서두르고 있는 상황입니다. 그러나 엔터프라이즈 보안은 단지 회자되는 몇몇 솔루션의 도입만으로 이뤄질 수는 없습니다. 외부로부터의 해킹, 바이러스와 웜, DDoS의 공격에서부터 내부자의 고의 또는 실수에 따른 정보 유출에 이르기까지 수많은 경로로 발생하는 보안 사고에 대처하기 위해 네트워크에서부터, 애플리케이션, 콘텐츠, 사용자 등 IT 인프라 전 분야에 걸친 폭넓은 보안 솔루션과 전략이 요구되고 있습니다. NetFocus 2007 End-to-end Security Seminar는 네트워크 보안에서부터 엔드포인트, 애플리케이션, 콘텐츠, 사용자 인증 등 엔터프라이즈 환경을 위한 다양한 보안 기술과 응용과 함께, 안전하고 신뢰성 높은 IT 인프라 구현을 위한 명쾌한 해법을 제시하는 자리가 될 것입니다. - 월간 온더넷 　 행 사 명 : NetFocus 2007 End-to-end Security Seminar 　 주주주제 : 엔터프라이즈 환경을 위한 엔드 투 엔드 시큐리티 　 일주주시 : 2007년 10월 10일(수) 　 장주주소 : 리츠칼튼호텔 리츠칼튼룸(교보타워사거리) 　 주주주최 : 월간 on the NET 　 주주주관 : 정보시대 　 후주주원 : NRC 　 플래티넘 스폰서 : 　 골드 스폰서 :                       　 참석인원 : 300명(선착순 마감) 　 사전등록 : 2007년 9월 14일~10월 9일 　 참가비용: 사전 등록 : 7만 7,000원 (부가세 포함)/*회원 할인 : 6만 6,000원(부가세 포함) 현장 등록 : 9만 9,000천원 (부가세 포함) 　 참가혜택: 세미나 발표자료집, 중식, 전일 주차 지원, 기념품 제공, 추첨 통해 경품 제공 *회원 할인은 온더넷 정기구독자, 웹 회원, NRC 회원에 한함. 　 시간 주제 　 09:30~09:50 등록   09:50~10:30 기조연설 : 엔터프라이즈 환경에서 엔드 투 엔드 시큐리티 구현의 중요성 　파이오링크 조영철 대표이사 10:30~10:40 Break 　 10:40~11:20 전사적 통합 보안 솔루션 ESM & RMS 엔터라시스코리아 안종석 이사　 11:20~12:00 네트워크 가용성 확대를 위한 NAC 활용 방안 　미라지네트웍스 아태본부 남현우 SE 12:00~13:00 중식 　 13:00~13:40 네트워크 보안을 위한 개인 인증 디바이스 LG히다찌 U-Solution팀 이석희 부장 　 13:40~14:00 Coffee Break 　 14:00~14:40 Secure Mobility integrated with NAC 아루바코리아 김대선 부장 14:40~15:20 최신 네트워크 보안 기술 동향 주피터시스템즈 박광청 대표이사　 15:20~15:40 Break 　 15:40~16:20 UTM 솔루션을 이용한 엔트 포인트 보안 방안 워치가드코리아 세일즈 엔지니어 최철호 과장　 16:20~17:00 웹 파이어월을 통한 엔드 포인트 보안 방안 파이오링크　      　 　 　 정보시대 정혜승 02-521-3531(#200) 　 　 + Home : www.ionthenet.co.kr/netfocus200710/ + Email : info@infoage.co.kr

s