[IBM dW] Top 100 of 2009: developerWorks articles

Top 100 of 2009: developerWorks articles (and other favorite things)

[JDBC]일반 JDBC와 Oracle JDBC 성능비교(Java 배치) #2

[JDBC]일반 JDBC와 Oracle JDBC 성능비교(Java 배치) #1(이하 "성능비교 1차")

에서는 일반 JDBC와 Oracle JDBC간의 "조회+등록"이 함께 있는 시나리오에 대해 성능비교를 해보았다.

이번에는 "조회"만 있는 경우에 대해서 성능비교를 해보면 아래와 같다.

<시나리오>

□ 100건씩 조회(rownum <=100)

□ 위 작업을 1~100,000 반복

※ 타 조건은 "성능비교 1차"와 동일

<총 소요시간(총 응답시간) 비교>

※CASE1:일반JDBC, CASE2:Oracle JDBC

<결론>

1."조회"만 있은 경우 70% 이상의 성능개선효과 발생

   o 반복횟수가 증가할수록 개선율은 낮아지지만, 최소 70%이상의 개선효과 발생

2. "조회+등록"이 있는 경우가 성능개선 효과가 더 높은 것으로 판단

   o "조회+등록" 이 있는 경우, 90%이상 성능개선효과 발생

 ※ "조회+등록" 이 있는 경우, 등록에 대한 일괄처리로 인한 성능개선효과가 크게 나타나는 것으로

      조회 부분(Parse+Fetch)에 대한 성능개선은 상대적으로 미미해 짐.

      (조회부분은 약 5% 정도만 개선)

[사진] Apple Team

 (출처 : flickr.com)

From Left...

Tony Fadell(engineering vice president),

Jon Rubinstein(iPod head),

Jonathan Ive(industrial design chief),

Steve Jobs(CEO),

Philip Schiller(marketing director).

최고의 멤버! 최고의 팀!

(Force가 느껴진다...그들 뒤에 있는 사무실도 예사롭지 않아 보인다.)

[IBM dW] 자바 EE 6에서 의존성 주입

이창신씨가  IBM developerWorks에 연재한 글이다.

J2EE6 에서의 Dependency Injection의 Spec확정에 대한 내용이며,

이를 Servlet 예제와 함께 소개하고 있다.

IoC나 AOP의 개념이 이제 J2EE에서 표준 패러다임으로서 정착해가는 느낌이다.

자바 EE 6에서 의존성 주입

[FW] Application Framework in J2EE

J2EE 환경에서

Open Source Frameworks를 이용한 아키텍처 구성도(예시)

• Presentation Tier : Struts
• Business Tier : Spring
• Persistence Tier : iBatis

[dW]7 Roles of Architect

2003.11.2 IBM developerWorks에

"아키텍트가 갖출 일곱 가지 자질 "이라는 제목으로 실렸던 글이 새삼 와 닿는다.

("Applied Software Architecture" 책의 내용을 정리한 글이다.)

이 글에서 말하는 일곱가지 자질은 아래와 같다

1. 비전 제시자(creating vision)

2. 핵심 기술 조언자(the architect as a key technical consultant)

3. 의사 결정자(The architect makes decisions)

4. 코치(The architect coaches)

5. 조정자(The architect coordinates)

6. 구현 능력(The architect implements)

7. 대변자(The architect advocates)

[JDBC]일반 JDBC와 Oracle JDBC 성능비교(Java 배치) #1

만약, 한 아키텍트가 JAVA로 배치 아키텍처를 제안한다면,

그 아키텍트는 대용량처리 시 응답속도에 대한 것을 포기하는 것이냐는  핀잔을 들을지도 모른다.

(아마,  JAVA가 느린것도 모르냐며 무능한 아키텍트로 낙인찍힐 수도 있다.)

하지만,  Oracle JDBC 를 이용할 경우 이야기는 달라질수 있을 듯하다.

JAVA기반의 배치프레임워크를 지원하는 상용제품(CASE1)과

동일한 로직을 Oracle JDBC(CASE2)로 구현하여 총 소요시간(응답시간)을 비교하여 보면 아래와 같다.

※ 상용제품은 표준(일반) JDBC로 구현

<시나리오>

□ 100 건 select 후 insert

    ※ 모든 SQL(select, insert SQL)문은 동일

    ※ commit 단위 : 100건

□ 위 작업을 1/10/100/1,000회 반복 수행 후 총 소요시간(응답시간) 비교

<테스트 서버환경>

□ OS : IBM AIX 5.3(64 bit)

□ CPU / RAM : 12 / 3 GB

□ Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – 64bit

□ JVM : build 1.4.2, J2RE 1.4.2 IBM AIX 5L for PowerPC (64 bit JVM)

<설정비교>

※ JDBC 각 처리단계(Parse, Execute, Fetch)별 관련 클래스 및 메소드 비교표임

※ CASE2(Oracle JDBC)의 설정값은 테스트 및 관려자료를 참고하여 결정한 수치임.

<총 소요시간(응답시간)비교>

<결론>

위와 같이 일반 JDBC와  Oracle JDBC를 이용할 경우 98% 이상의 Dramatic한 성능개선을 보였다.

 

물론, 이는 지극히 단순화된 조건하의 극단적인 비교치일 수 있다.

즉, 일반 JDBC를 이용하더라도 addBatch등을 통해 Execute 등의 속도를 높일 수는 있으니 말이다.

 

하지만 확실한 것은,

Parse, Execute, Fetch 작업이 반복될수록 Oracle JDBC의 성능개선 효과가 더 커진다는 것이다.

 

JAVA 기반에 Oracle Database만 사용하는 환경에서 대용량 배치프로그램의 속도가 고민이라면,

Oracle JDBC를 이용한 속도향상에 대해 심각히 고려해 볼 필요가 있어 보인다.

 

<추신>

1) 테스트 소스나 DB 스크립트를 개시하지 못하는점 양해바람.

  -  소스는 상용프레임워크 소스가 그대로 보이고,

  -  DB스크립트는 실제 사용테이블 명이 나타나 보안상 문제가 될수 있어 생략함.

2) 위의 비교는 상용프레임워크의 문제점에 대한 논의가 아니라, 

    일반 JDBC와 Oracle JDBC 비교를 위해 편의상 현재 사용중인 상용프레임워크를 사용하였을 뿐임.

3)  각자 개발이나 운영중인 환경이 있다면 

     현재 사용하고 있는 JDBC방식을 Oracle JDBC 방식으로 변경하여 비교해 볼 것을 강력히 권장함

 

※ “Pro*C와 Java와의 Batch BMT(성능비교) “라는 흥미로운 글이 있어 소개한다. 

    JDBC의 addBatch를 이용해도 Pro*C보다도 빠를 수 있다는 내용이다.

    (아마 Oracle JDBC의 setExecuteBatch를 이용하였다면 더욱 높은 속도개선이  가능했을 듯 하다.)

[기사] 아이폰 구입하면 '매국노', 국산폰 사면 '애국자'?

오마이뉴스 김인성 기자(09.12.10 10:46)

아이폰 구입하면 '매국노', 국산폰 사면 '애국자'?

말이 필요없다. 읽어보면 다들 공감할듯.

완전공감, 개념기사다.

김인성 기자님께 감사드린다.

아이폰으로 인해 쓰레기 같은 Active-X좀 안쓰고,

웹환경도 표준좀 지키고 다양한 browser좀 쓸 수 있기를 간절히 바랄뿐이다.

(특히, 금융권들 제발....)

[Java] New Features and Enhancements J2SE 5.0 , 6.0

Java New Features and Enhancements

 

J2SE 5.0

J2SE 6.0

[Java] Effective Java - Still Effective After All These Years

 

Effective Java를 쓰신 Joshua Bloch(Chief Java Architect at Google)의 강의모습이다.

Java의 기본개념에 대한 내용들을 Quiz 형식을 통해 수강자들과 소통하며 즐겁게 진행하는 모습이 인상적이다.

<추신>

그의 모습에 열정과 즐거움이 묻어나온다... Google에 다녀서 그런가? ㅋ

(이런 Guru는 어디에서 일할까 궁금했는데, 역시.....Google에 있었다! ^^)

그리고 그가 공저한 "Java Puzzlers"라는 책도 한번 읽어봐야 겠다.

 

[Tx.]Connection Sharing 기능

[JEUS 5.0 #23 이상 버전 patch 기능 중 Connection Sharing 기능에 대한 설명]

UserTransaction tx = new UserTransaction();

tx.begin();

Connection con1 = ds.getConnection(); //ds : DataSource

Connection con2 = ds.getConnection();

Connection con3 = ds.getConnection();

...

tx.commit();

위와 같은 Global Transaction 로직에서,

일반적인 경우, con1, con2, con3은 3개의 다른 connection 객체이다.

connection sharing이란,

동일 Global Transaction에서는 여러번 connection객체를 요청하더라도

WAS단에서 동일한 connection 객체를 리턴시켜 주는 기능이다.

즉, con1, con2, con3은 모두 1개(con1)의 동일한 connection 객체이다.

즉, 위의 Connection Sharing 기능을 어플리케이션 측면에서는

tx.begin();

Connection con1 = ds.sgetConnection();

con2=con1;

con3=con1;

tx.commit();

와 같이 Connection을 재사용하도록 코딩한 것과 같은 의미가 된다.

정리하면, Connection Sharing 기능이란,

하나의 Global Transaction에서

어플리케이션에서 명시적으로 connection 객체를 재사용하지 않더라도

WAS단에서 동일한 connection 객체를 리턴하여 공유(재사용)하도록 하는 기능이다.

[장점]

이와 같은 기능은 하나의 Global Transaction에서 빈번히 getConnection을 수행하는 어플리케이션에서는

connection open 시간이 줄어들어 전체 response time 감소한다.

(즉, XA DataSource를 이용한 다수건 connection 사용환경에서 개선효과 발생)

[단점]

하지만, 단일 connection만 이용하는 어플리케이션에서는 connection 관리기능 추가로 인한 overhead로

connection open 시간이 더 늘어나서 전체 response time 증가한다.

(즉, Non XA DataSource를 이용한 connection 사용환경에서는 역효과 발생)

[Books]컨설팅의 비밀

누구에게 컨설팅이라는 행위를 하기 전에 컨설턴트로서 주의해야 할 사항들에 대한 정리!

특히, 돈이라는것을 받고 누구에게 충고(?) 할때에 고려해야할 사항들!

(※ 번역문맥이 다소 읽기에 어려웠음)

[기사] 아이폰의 성공 비밀

오마이뉴스 2009.12.05 김인성 기자 휴대폰 업체 구세주', 아이폰 성공 비밀

소비자 열광시킨 '편의성'...아이디어 중심으로 '선택과 집중' 애플의성공 비결을 논리적인 어조로 잘 써내려간 기사 결국 애플의 성공비결은 창의성! 과연 우리나라에 애플이 있었으면 성공할 수 있었을까? 아마 잡스형님도 꽉꽉막힌 군대식 문화와 어설픈 권위주위때문에 결코 쉽지 않았을 것이다. 이나라 대한민국에서도 애플과 같은 회사가 없는데 아이폰과 같은 제품이 나오기를 바라는건 닭이 없는데 달걀을 기대하는 것만큼이나 어리석은 일일지도 모른다. 이이폰의 놀라운 기능들을 눈으로 직접보면서 말로만 IT선진국이라고 떠들어 대며 IT에 아무런 비전이 없는 위정자들과 강이며 땅이며 삽질할 생각에만 가득한 현정부를 보면 대한민국의 IT는 밝지만은 않아 보인다.

[Books]Effective Java(Second Edition)

Java의 기본에 대한 생각을 하게 하는 책

Java Program Performance Tuning 관련 작업 전에 한번은 읽어봐야할 내용들

[JDBC] Oracle JDBC를 이용한 성능향상 방법

1. Statement Caching

① Implicit Statement Caching

// Statement cache 사이즈를 5로 설정
((OracleConnection) conn).setStatementCacheSize(5);
// Enable Implicit caching
((OracleConnection) conn).setImplicitCachingEnabled(true);

② Explicit Statement Caching

// Statement Cache 사이즈를 5로 설정
((OracleConnection) conn).setStatementCacheSize(5);
// Enable Explicit caching
((OracleConnection) conn).setExplicitCachingEnabled(true);

 

2. Implicit Connection Caching

private static final String CACHE_NAME =“ CacheSample”;
// Datasource 초기화
OracleDataSource ods = new OracleDataSource();

// Enable caching
ods.setConnectionCachingEnabled(true);
// Set the cache name
ods.setConnectionCacheName(CACHE_NAME);

// cache, datasource, cache properties를 지정하여 새로운 cache생성
connMgr.createCache(CACHE_NAME, ods, properties);
Connection conn = ods.getConnection();

 

3. Update Batching

① Standard Update Batching

Connection conn = ds.getConnection();
conn.setAutoCommit(false);

Statement s = conn.createStatement();

s.addBatch( “insert into dept values‘ ( 26’,‘HR’,‘Mongolia’)”);
s.executeBatch();

conn.commit();
s.close();

② Oracle Update Batching

Connection conn = ds.getConnection();
conn.setAutoCommit(false);

PreparedStatement ps =
conn.prepareStatement(“ insert into dept values (?, ?, ?)”);

((OraclePreparedStatement)ps).setExecuteBatch (3);

ps.executeUpdate();
((OraclePreparedStatement)ps).sendBatch();

conn.commit();
ps.close();

 

4. Standard Fetch Size and Oracle Row Prefetching

① Standard Fetch Size

Statement stmt = conn.createStatement();
stmt.setFetchSize(100);

② Oracle Row Prefetching

((OracleConnection)conn).setDefaultRowPrefetch(7);
((OracleStatement)stmt).setRowPrefetch (2);

 

 

<출처>
2007 Spring Oracle Korea Magazine
Oracle JDBC를 이용한 성능향상 방법
저자_김정식 Oracle ACE(oramaster@empal.com)

[FW] 전자정부 표준Framework

행정안전부에서 2009년 6월 24일(수)에

“전자정부 표준프레임워크 공개 및 활성화 계획 발표” 를 했다.

오픈소스에 기반한 표준프레임워크 발표는 긍정적인 부분이다.

 

전자정부 표준프레임워크 사이트는 http://www.egovframe.go.kr 이며,

전자정부 표준프레임워크에 포함된 오픈소스 리스트는 아래에서 확인할 수있다.

http://www.egovframe.go.kr/EgovEnvRun.jsp

 

아키텍처 구성에 대한 내용은 꼭 한번 읽어볼 필요가 있어보인다.

앞으로도 지속적으로 유지보수되고 더욱더 개선되어지길 기대한다.

 

무료교육을 통한 전파도 시도되고 있다. 기회가되면 참여하고 싶다.

 

<추신>

공공기관에 있어 표준프레임워크에 대한 시도는 분명 좋은시도이며 많은 잇점이 있을것으로 보인다.

하지만 표준이라는 이름으로 다양성이 무시되고 쏠림현항이 심화되는 부작용은 없었으면 한다.

[Timeout]UserTransaction과 SQL Timeout관계

javax.transaction.UserTransaction(ut)을 사용하는 Global Transaction의 기본적인 구조는 아래와 같다.

-----------------------

시간     소스

0초      ut.begin();

1초         select();        -> SQL Timeout

2초         insert()          -> SQL Timeout

3초         update();       -> SQL Timeout

4초         delete();        -> SQL Timeout

5초      ut.commit();    -> Transaction Timeout

-----------------------

* Transaction Timeout : begin() ↔ commit() 사이의 최대시간

* SQL Timeout : 각각 SQL 단위 수행 최대시간

 

이와 같이 UserTransaction을 사용하는 Global Transaction에서 고려해야 할 기본적인 Timeout은

Transaction Timeout과 SQL Timeout 이다.

 

즉, 위의 예제를 보면,

총 Transaction 수행 시간은 5초이므로, Transaction Timeout 은 5초 보다 커야 하고,

SQL 수행시간은 1초이므로, SQL Timeout은 1초보다 커야한다.

 

<Timeout 설정값 비교>

구분	UserTransaction	JEUS 5.0
Transaction Timeout	setTransactionTimeout	<active-timeout>
SQL Timeout	-	<stmt-query-timeout>

 

 

 

 

        

 

 

 

[Timeout]javax.transaction.UserTransaction

setTransactionTimeout

void setTransactionTimeout(int seconds)
                           throws SystemException

Modify the timeout value that is associated with transactions started by the current thread with the begin method.

If an application has not called this method, the transaction service uses some default value for the transaction timeout.

Parameters:

seconds - The value of the timeout in seconds. If the value is zero, the transaction service restores the default value. If the value is negative a SystemException is thrown.

Throws:

SystemException - Thrown if the transaction manager encounters an unexpected error condition

[Timeout]JEUS 5.0 Timeout 설정값

JEUS 트랜잭션 매니저는 예외 상황 처리를 위해서 다양한 타임 아웃 메커니즘을 사용한다. 타임 아웃 메커니즘의 값을 조정해서 어플리케이션 시스템에 가장 적합하도록 트랜잭션 매니저를 튜닝 할 수 있다.

• Resolution: 타임 아웃 메커니즘의 기본 시간 간격. 이 값을 작게 설정하면 타임 아웃이 세밀하게 작동한다. 값이 너무 크면 타임 아웃이 너무 느슨하게 작동한다. Client Container에서 이 값을 설정하려면 클라이언트 어플리케이션의 스크립트에 -Djeus.tm.tmResolution=<time in milliseconds>를 추가한다. Web Container나 EJB Container에 설정하려면 <resolution> 태그에 값을 설정한다.
• Active Timeout: Global Transaction이 시작되면 이 시간 안에 commit이 실행되어야 한다. 그렇지 않으면 트랜잭션 매니저가 rollback 시켜버린다. Client Container에서 이 값을 설정하려면 클라이언트 어플리케이션의 스크립트에 -Djeus.tm.activeto=<time in milliseconds>추가한다. Web Container나 EJB Container에 설정하려면 <active-timeout> 태그에 값을 설정한다.
• Prepare Timeout: Root Coordinator는 이 시간 내에 Sub Coordinator와 리소스매니저로부터 ‘prepare’ 신호를 받아야한다. 만약 받지를 못하면Root Coordinator는 Global Transaction을 rollback 시킨다. Client Container에서 이 값을 설정하려면 클라이언트 어플리케이션의 스크립트에 -Djeus.tm.prepareto=<time in milliseconds>를 추가한다. Web Container나 EJB Container에 설정하려면 <prepare-timeout> 태그에 값을 설정한다.
• Prepared Timeout: Sub Coordinator는 자신의Root Coordinator로부터 이 시간 안에commit을 해야 할지, rollback을 해야 할지를 나타내는 global decision을 받아야 한다. 만약 이 시간 내에 받질 못하면, Root Coordinator 로 다시 ‘prepare’에 대한 응답 메시지를 보낸다. 그래도 여전히시간 내에 global decision이 오지 않는다면, <heuristic-rollback>의 값이 true일 때 Global Transaction을 rollback 시켜버린다. <heuristic-rollback>이 false이면, Root Coordinator로 메시지를 보내고global decision을 기다리기를 계속 한다. Client Container에서 이 값을 설정하려면 클라이언트 어플리케이션의 스크립트에 - Djeus.tm.preparedto=<time in milliseconds>를 추가한다. Web Container나 EJB Container에 설정하려면 <prepared-timeout> 태그에 값을 설정한다.
• Commit Timeout: Root Coordinator는 이 시간 내에 Sub Coordinator와 리소스매니저로부터 ‘commit’이나 ‘rollback’ 에 대한 결과를받아야 한다. 만약 결과가오지 않으면, Root Coordinator는 Global Transaction을 ‘Uncompleted List’에 기록해서, 트랜잭션이 완전히끝나지 않았음을 남겨둔다. Client Container에서 이 값을 설정하려면 클라이언트 어플리케이션의 스크립트에 - Djeus.tm.committo =<time in milliseconds>를 추가한다. Web Container나 EJB Container에 설정하려면 <commit-timeout> 태그에 값을 설정한다.
• Recovery Timeout: 이 값은 트랜잭션 복구 시에 사용된다. 트랜잭션 매니저는 트랜잭션 복구를 위해서 복구될 트랜잭션 정보를 가져오려고 한다. 만약 다른 트랜잭션 매니저에서 이 시간 내에 복구 정보를 알려주지 않으면, <heuristic-rollback>이 true 일 때, 해당 트랜잭션을 rollback 시킨다. 값이 false이면 트랜잭션 복구를 시스템 관리자에게 남겨두고 더 이상 진행하지 않는다. Client Container에서 이 값을 설정하려면 클라이언트 어플리케이션의 스크립트에 -Djeus.tm.recoveryto=<time in milliseconds>를 추가한다. Web Container나 EJB Container에 설정하려면 <recovery-timeout> 태그에 값을 설정한다.
• Uncompleted Timeout: 트랜잭션 매니저는 전체 트랜잭션 처리를 완료하기 위해, 실패한 Global Transaction의 목록을 보관한다. 완료되지 못한 Global Transaction의 정보는 복구 처리시에 사용되므로, 이 타임 아웃 시간까지 보관된다. 그러므로 이 시간이 너무 짧으면 복구 정보가 빨리 지워지게 되고, 트랜잭션 매니저가 해당 Global Transaction의 무결성을 복구할 수 없게 된다. 그 결과 Global Transaction 복구를 위해서, 시스템 관리자가 많은 작업을 직접 처리해야만 한다. Client Container에서 이 값을 설정하려면 클라이언트 어플리케이션의 스크립트에 - Djeus.tm.uncompletedto=<time in milliseconds>를 추가한다. Web Container나 EJB Container에 설정하려면 <uncompleted-timeout> 태그에값을 설정한다.

      <출처> technet.tmax.co.kr - 매뉴얼

[IBM,SUN,HP]GC, Heapdump, Thread dump 분석툴 비교

Garbage Collection, Heapdump, Thread dump(javacore) 분석 시

IBM, SUN, HP 환경에서 각각 사용가능한 분석툴들을 정리하면 아래와 같다

 

 

※ 이보다 더 많은 툴이 있을 수 있으나 개인적으로 사용해 본 툴 위주로 정리하였다.

 

 

 

 

 

 

 

[JVM Options] IBM

IBM JVM의 버전별 Options을 정리하면 아래와 같다.

 

참고로 아래는 Garbage Collector command-line options 링크이며,

기본 페이지는 "Java Diagnostics Gude" 이다.

 

[JVM 버전]

1.4.2  /  5.0  /  6.0  

[JVM Options] SUN

All the JVM options for various versions of the JVM

 on primarily SPARC/Solaris Platform(1.3.1~1.6(6.0))

 

참고로, 아래는 1.4.2 / 5.0 / 6.0에 대한

Standard, Non-Standard and  Hidden Options 에 대한 설명이다

 

 

[Standard / Non-Standard Options]

1.4.2  /  5.0  /  6.0

 

[Hidden Options]

http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

 

 

[JDK] IBM JDK 다운로드

현재 서버 개발환경은 IBM JDK를 사용하고 있다.

따라서, Eclipse로 개발하기 위해 IBM JDK download를 찾던중,

javaservice.net에 제니퍼소프트의 이원영 사장님의 친절한 글을 발견하게 되었다.

http://www.javaservice.net/~java/bbs/read.cgi?m=etc&b=jdk&c=r_p&n=1171283145&p=6&s=t

 

정리하면 아래와 같다.

 

1. IBM JDK는 SUN JDK와 달리 별도의 윈도우용 JDK 설치파일(.exe)를 제공하지는 않는다.

2. 아래 주소에 있는 Eclipse zip파일을 다운받으면 파일 안에 버전별 JDK가 포함되어 있다.

http://www.ibm.com/developerworks/java/jdk/eclipse/index.html

→ "IBM Development Package for Eclipse" 클릭 → 로그인 → 아래 중 하나 선택

  1) JDK 1.4 포함  : 없음

  2) JDK 5.0 포함  : IBM Development Package for Eclipse, 32-bit Windows Version 211 선택
      → IBM_DevelopmentPackage_for_Eclipse_Win32_2.1.1.zip 에 포함

  6) JDK 6.0 포함 : IBM Development Package for Eclipse, 32-bit Windows Version 300 선택
      → IBM_DevelopmentPackage_for_Eclipse_Win32_3.0.0.zip 에 포함

 

 

[dW]Performance monitoring with AspectJ

처음 APM 툴을 보았을때, 그 원리가 참 궁금했다.

이후에, 대부분의 모니터링 툴이 AspectJ를 응용한 솔루션이라는 것을 알게 되었을때,

AspectJ의 멋진 AOP사상에 대해 신선한 충격을 받았던 기억이 난다.

 

역시, IT나 어느 분야를 막론하고 깨어있는 사람들에 의해서 발전함이 틀림없다.

 

아래 글은 IBM developerWorks에 실린 글이다.

(Part1 : 13 Sep 2005 / Part2 : 15 Nov 2005, Ron Bodkin(ron.bodkin@newaspects.com),

Founder, New Aspects of Software)

 

역시나 깔끔하게 정리 잘된 글이다.

 

AOP@Work: Performance monitoring with AspectJ, Part 1

A look inside the Glassbox Inspector with AspectJ and JMX

 

AOP@Work: Performance monitoring with AspectJ, Part 2

Putting the Glassbox Inspector to work with load-time weaving

 

AspectJ를 이용하여 간단한 성능 모니터링 툴을 만들어 사용해보자!

 

연봉 1억 개발자는 무엇을 하고 있을까?

ZDNet(2009.06.23일자, 송주영 기자)의 글을 읽고 신선한 충격을 받았던 기억이난다.

그 기사는 바로 아래 글이다.

 

"연봉 1억에 개발자 모십니다"

 

조봉한 하나아이앤에스 사장의 "깨어있는" 생각이 무척이나 마음에 들었다.

그런데 문득 과연 연봉 1억이 아깝지 않은 개발자들은 선발되었을까? 라는 생각이 들었다.

선발되었다면, 그들은 어떤 R&R을 수행하고 있으며, 조직에서 어떠한 위치에 있고,

어떠한 방식으로 일하는지, 조직내의 갈등은 없는지 등등...

이러한 새로운 시도에 대한 진행사항이 궁금해진다.

 

우리나라 CIO의 대부분은 업종을 불문하고 대부분 비 IT출신의 관리자들이다.

또한 CIO라는 자리가 회사내에서 크게 입지나 위상이 높지 않으며,

심지어 임원들이 잠시 머물며 경험한번 해보는 자리 정도로 여겨지기도 한다.

아마, 조봉한 CIO도 IT회사에서 일해본 경험이 있기에, 이와같은 생각이 가능했으리라 본다.

 

머니투데이(2008.10.30일자, 박창욱 기자)의 조봉한 CIO의 인터뷰기사

"그는 어떻게 30대에 은행임원이 됐나"

 

이러한 깨어있는 CIO 및 CEO가 늘어나야 하며,

이러한 생각이 몇몇 특이한 임원의 생각이 아닌 당연한 상식이 되어야 한다.

 

하나아이앤에스 가 지금처럼 단순하디 단순한 비용절감 논리로의 IT자회사 분리 및 아웃소싱이 아닌,

새로운 IT자회사 및 Biz를 리드하는 IT의 새로운 롤 모델을 제시하기를 기대한다.

 

금융권 IT 아웃소싱에 대한 단상

전자신문의 CIOBIZ 컬럼의 글중 IT 아웃소싱과 관련된  글이 눈에 들어왔다.

 

토털IT 아웃소싱, 하나대투증권 vs SK증권 

 

IT인력 이동없이 IT계열사로 시스템관리 이관

 

소위 신의 직장이라는 금융회사들에서 IT 아웃소싱을 한다는 기사를 읽을때면

한편으론, "IT인력들은 더이상 신의 직장에 입성할 기회조차 점점 없어지는 구나..."

라는 생각이 들어 씁쓸해 지곤 한다.

 

대부분 아웃소싱을 하게 되는 순간,

특히 위와 같이 자회사로 분리되고 인력이동이 되는 순간,

기존 몸담았던 모회사와는 급여나 복지혜택이 차이나게 된다.(최소 몇년간은 동일할지 모르겠지만...)

 

그리고 SK증권 처럼 SI업체로 이동되는 경우에는

결국 SI인력이 되어 SK증권 SM을 담당한도록 파견나온 외주직원의 신분이 되는것이다.

또한 언제 다른회사 SI 프로젝트에 투입될지도 모르게 될 것이다.

 

현재 IT인력들의 수준을 보면, 점점 하향평준화 되고 있는 듯 싶다.

이는 너무나 열악한 IT업체의 근무 여건(특히, SI 프로젝트)과 보상의 미흡,

낮은 사회적 대우 및 인식 등의 문제로 인해 이공계 기피 현상과 맞물려

우수인력이 IT업계로 진출을 꺼려하고 있기 때문이라는 생각이 든다.

 

문과 출신들과 똑같이 공부하고, 아니 더 치열하게 공부했건만,

사회에서는 "갑"과 "을"의 잣대로 모든 신분(?)을 정해버리고, (그속에서 항상 "을"일수 밖에 없고)

M/M의 잣대로(소위 머릿수로만) IT의 생산성을 평가하고 전문성을 인정하지 않는

사회 전반적인 분위기 속에서 몇명이나 과연 IT에 인생을 걸고 투자하겠는가?

 

IT전문가에게는 소위 "사"자 분들(변호사, 의사 등) 보다 더 높은 수준의

사회적 대우나 보상이 당연시 되는 사회기반이 마련되어야 한다.

 

더이상 공부하지 않는 낮은 수준의 개발자와

깊고 넓계 보는 expert 수준의 아키텍트의 차이를 확실히 구별하여 평가하고

그에 상응하는 차별화된 보상과 인정을 해주는 업체와 회사가 많아진다면,

IT인력들에게도 확실한 동기부여가 되고, 그 수준도 상당히 높아질 것이다.

 

이렇게 된다면 현재와 반대로 비 IT인력들이 IT인력들에게 신도 가고싶은 직장이라는

부러움을 보내지 않을까?

 

<추신>

산업별 IT 아웃소싱 동향분석에 대한 CIOBiZ(2009.7.12일자 신혜권, 성현희 기자)기획 기사가

눈에 들어왔다. 회사별 아웃소싱 회사에 대한 정리가 인상적이다.

 

[기획]산업별 IT아웃소싱 동향 분석

 

 

금융권 차세대시스템의 실패에 대한 단상

전자신문의 CIOBIZ컬럼을 읽다가 근래 진행되고 있는 금융권 차세대시스템 프로젝트 실패에 대한

공감가는 기사가 있어 소개한다.

 

차세대 IT 프로젝트 '실패'에서 배운다

 

사실 대규모의 차세대시스템 구축을 하면서 기한내에 오픈한 사이트는 전무하다 시피하다.

그나마 몇개월 지나서 간신히 오픈하고, 한 1년 정도 지나서 안정화가 되면 성공이라고 말하는 분위기다.

 

위의 기사에서도 좋은 지적을 했지만, 실제 차세대시스템을 구축하면서 개인적으로 성공과 실패를

가름하는 요소라고 느끼점은 아래와 같다.

 

첫째, CIO는 책임질줄 아는 카리스마가 있어야 하며,

실무자 레벨까지 다양한 소리를 듣고 올바른 의사결정을 내리는 능력이 가장 중요하다.

 

둘째, PM은 다양한 구축업체를 아우르고 고객을 비롯한 다양한 stakeholder간의 커뮤니케이션을 통해

조율하고 같은 비전을 공유하여  힘을 합쳐 시너지를 발휘할 수 있도록 리딩하는 능력이 중요하다.

 

셋째, 아키텍트가 중요하다.

 

특히, 아키텍트의 중요성을 절감하였다.

다양한 솔루션에 대한 이해를 통한 연계 및 Troubleshooting, Performance Tuning,

표준 및 가이드 작성, 개발자 교육 등 그야말로 컨트롤 타워가 바로 아키텍트였다.

 

얼마나 경험많고, 유능한 아키텍트를 중심으로 프로젝트를 진행하는냐가

결국 얼마나 많은 시행착오(소위 삽질)를 줄이고 프로젝트의 전체 리스크 또한 줄이느냐와 직결된다.

 

어떤 무식한 PM은 아키텍트는 초기에 몇달 가이드정도 작성하고 빠지면 되고,

그후 개발자들 잔뜩 투입해서 찍어내듯 개발하면 된다고 서슴없이 말하곤 한다.

이러한 무개념의 PM들이 결국 이런 대규모 프로젝트를 망치는 주연중에 하나다.

 

단언컨데, 초급 개발자 열댓명 투입하느니, 제대로된 아키텍트 한명이 더 훌륭한 아웃풋을 낸다

 

몇달전 정명훈 지휘로 서울시립교향악단의 공연을 본적이 있다.

중고등학교때 그토록 많이듣던 베토벤 교향곡이 이리도 감동적일 수 없었다.

이때, 문득 지휘자가 아키텍트랑 너무도 닮았다고 느낀것은 지나친 비약이었을까?

 

Java technology, IBM style: Garbage collection policies

Java technology, IBM style: Garbage collection policies, Part 1

Differing policies provide flexibility

 

Java technology, IBM style: Garbage collection policies, Part 2

 Use verbose GC and application metrics to optimize garbage collection

 

 

IBM JVM에서 GC Tuning을 하면서 읽었던 글들중에 가장 마음에 드는 글이다

(출처 : IBM developerWorks, Mattias Persson(Staff Software Engineer, IBM, Software Group)외)

 

part 2에서 subpool에 대한 설명을 논외로 한 것이 아쉽지만,

간결하고 명료하게 GC Policy를 정리 비교하였다.

 

<추신>

이런 좋은 글을 읽고나면 좋은 글을 쓴 저자에게 감사의 마음이 절로 생긴다.

답답한 관료주의적 환경에서 일하는 많은 한국 IT인들(나를 포함한)을 생각하면

이러한 연구를 계속할 수 있게 배려해주는 회사 분위기가 새삼 부러워 진다.

 

 

 

 

[IBM dW]3년을 기다렸다

3년을 기다렸다

 

이창신 iasandcb@gmail.com, http://iasandcb.pe.kr 씨가 한국 IBM developerWorks에 기고한
자바 EE 6 스펙에 대한 글이다.

"이창신" 이라는 이름이 눈에 띄여 읽었는데 역시, 기대를 져버리지 않는 좋은 글이다.

 

급속도로 발전하는 기술 사이클에 비해 Java의 발전은 더딘듯 싶다.

과도기 였던 5 버전을 넘어 진보의 발판이 되는 6 버전의 활약이 기대된다.

 

(추신)

올해 JCO에서 이창신씨를 봤을때도, 범상치 않은 Force가 느껴졌었는데, 역시 큰 결심을 한거 같다.

그가 애플 '앱스토어', 구글 '안드로이드마켓' 으로 대표되는 앱스토어 시장에 홀로서기를 시작했다.

그의 결정과 도전에 경의를 표하며, 수년안에 그의 성공스토리를 읽기를 기대한다.

 

[지디넷코리아] 이창신씨의 아이폰 인디SW 개발자 선언, 그 뒷이야기

 

 

 

[IBM dW]당신은 몇 년 차?

당신은 몇 년 차?

 

김창준 juneaftn@hanmail.net 씨가 한국 IBM developerWorks에 기고한

경력관리와 인재선발과 관련된 좋은 글이다.

 

SI나 기타 프로젝트 시 인권비 산정을 위해

개발자에게 붙여지는 년차(일명 짠밥(?))를 기준으로 하는 기술등급이

그 사람의 능력과 얼마나 상관도가 떨어지는지, 또한 이런 식의 년차에 근거한 급여산정이

얼마나 공정치 못한 보상이라는 것은 개발자라면 다들 경험을 통해 이미

뼈져리게 느끼고 있을 터이다.

 

무능한 관리자들이 득실대는 현재의 주위 환경을 보면

오히려 경력과 능력은 어느 시점 부터는 반비례하는 것이 아닌가 하는 생각도 지울 수 없다.

(내가 이해가지 않는 저 관리자도 입사 초기에는 기본(?)은 하지 않았을까?)

 

이러한 경험을 학문적으로 잘 접근하고 논리적으로 증명한 글이다.

 

이와 같은 허왕된 년차를 통한 M/M 산정을 대체할 만한 평가지표는 무엇일까?

 

깊은 생각과 반성을 함께 던지는 순간이다.