Lean

일부 파일럿 프로젝트에서 진행해온 ‘Lean‘이 요즘 급물살을 타고 있습니다. 전 BST(Business Solutions & Technology) 조직에 적용해 갈 예정이라네요.

이곳 역시 소프트웨어 개발에 있어 이론과 현실 사이에 큰 Gap이 있는 편이고, Lean의 성격상 많은 이들의 반발을 사고 있는 편인지라 도입이 쉽지만은 않을 것 같습니다.

Betriebsrat(사원협의회)의 최근 소식지에는 Lean의 첫번째 원칙인 ‘Eliminate waste’를 언급하면서 이는 해고를 유발하는 것이 아니냐는 말을 하더군요.
뭐, 다양한 관점이 존재합니다만.

Michael Jackson

아침 뉴스로 Michael Jackson이 사망했다는 소식을 들었다. 충격이었다.
작년 최진실씨 자살 이후로 노무현 전대통령 사망에 이어 Michael Jackson까지, 왠지 일어날 것 같지 않은 일들이 계속 일어나고 있는 느낌이다.

80년대 나의 중고등학교 시절, 누구에게나 그는 단연 이슈의 중심이었다. 많은 이들이 그를 모방했고, 나 역시 그의 음악을 즐겨들었다. 특히 그의 엄청난 Billboard Chart 파괴력은 언제나 나를 흥분하게 했다.

다시 그 시절로 돌아가고 싶진 않지만, 그때를 항상 예쁘게 잘 보관하고 싶다. 나를 즐겁게 했던 것들을 잃고 싶지 않은 것이다.
Michael Jackson은 그 시절 나에게 있어 작지 않은 부분을 차지했고, 이제 그 부분은 다시 복구할 수 없는 곳으로 가버렸다.

그래서 가슴이 아프다.
Rest in Peace, Michael.

SQL 최적화, Locking vs. DML

… 데이터 액세스 양의 변화는 아래와 같은 요소들에 의해 큰 변화를 받는다.

  • 인덱스 사용 유무
  • 조인 방식
  • 클러스터 팩터
  • SQL 문

이와 같은 요소에 의해 10건을 추출하는 SQL은 100만 건의 데이터를 액세스한 후 10건의 데이터 만을 결과로 추출할 수 있고 진정으로 10건의 데이터만을 액세스하여 결과를 추출할 수도 있다.
결국 SQL 최적화는 보이지는 않지만 결과를 추출하기 위해 불필요한 데이터를 액세스하는 과정을 제거하는 일련의 활동이라고 할 수 있다…

권순용 님의 글을 읽다가 문득 어제 일이 생각이 났다.

Function Monitoring 쪽 SQL을 check 하다가 where 조건을 하나 더 추가했더니 소요시간이 99%나 줄었다.
데이터 양 자체는 별로 많지 않았지만 locking으로 인한 ‘경합’이 문제였다. 마침 해당 테이블에 PID란 칼럼이 있어서 이를 조건으로 추가했더니 – 즉 각 프로세스가 자기 PID에 해당하는 데이터만 액세스 – 더 많은 INSERT / UPDATE가 발생했지만 statement 당 소요시간은 99%나 줄었다. (예를 들어 총 10개의 DML을 5개의 프로세스가 경합하면서 작업하는 것보다 각 프로세스당 10개씩 총 50개의 DML을 실행시켜 버리는 것이 훨씬 싸게 먹힌다)

INSERT / UPDATE 횟수를 줄이는 것보다 경합이 있을 경우 이를 피하는 것이 더 현명하다.
발상의 전환이 필요하다고 할까.