월요일, 10월 10, 2005

Focus does matter

소프트웨어 개발에서 뛰어난 능력을 보이는 존재는 그렇지 않은 존재의 30배 이상 기여를 한다고 흔히 말한다.

그 30배의 performance는 재능, 지식, 성실성 그리고 집중에 의한 문제 해결 능력의 차이에 있다고 보여진다.

소프트웨어 개발은 계속적인 판단의 연속이다.
좀더 나은 코드를 위한, 좀더 나은 아키텍처를 위한 판단을 지속적으로 해야 한다.
하나의 결정을 내리기 위해 테스트 코드와 논리적 고심을 거듭하지만, 결국 이 결정이 제대로 동작하고 추후에도 도움을 주기 위해서는 결정 시의 집중이 중요한 고리가 된다.

논리적 혼란 속에서 '어 된다' 라는 방식의 판단은 결국 스파게티 코드를 양산하고, 비논리적 아키텍처를 만든다.

손의 노동에 의해 판단을 내리면 안된다. 중요한 결정일수록 사고의 집중을 활용한 판단이 그 소프트웨어의 가치를 높인다.

더 나은 소프트웨어를 만드는 사람들의 가장 차별적인 특성은 바로 뛰어난 판단 능력에 있을 것이다.

주변을 돌아보면서 더 나은 코드를 더 빨리 생산해내는 코더, 아키텍트들을 발견하면 이러한 특질이 다른 누구와도 그들을 차별화시켜줌을 본다.

성실하게 투여한 시간도 중요하지만, 결국은 그 시간들 속에서도 집중해내는 능력이 더 나은 소프트웨어를 만든다.

월요일, 10월 03, 2005

Open source and best-of-breed...

갈수록 공개 소스 소프트웨어에 많이 의존하게 된다.
어쩌면 피할 수 없는 흐름인지도 모른다.

가장 많이 사용하는 부분은 XML 처리에 관련된 것들이다.

XML parser, XPath engine, XML-Java binding, ...

투자 대비 개선이 뚜렷하지 않은 부분에서 좋은 공개 소스를 가져다 쓰는 것은 개발 비용의 절감 뿐만 아니라 소프트웨어의 질적 향상을 기할 수 있다는 점에서 나쁘지 않은 일이다.

하지만, 수많은 공개 소스들로 인해 옥석을 가리기가 점점 어려워지고 있으며,
best-of-breed를 요구하는 제품의 핵심 부분을 공개 소스로 채울 경우 제품 자체의 수준이 떨어질 우려가 높아진다.

필요는 발명의 어머니여서, 다양한 소프트웨어 요구는 다양한 소프트웨어 개발로 이어진다.

공개 소스도 대부분 특정 요구에서 출발하게 되며, 이후 점차 다양한 요구를 수용하면서 일반화되는 양상을 보인다.

그것은 장점이자 단점이 될 수 있다.

각 소프트웨어에 대한 요구를 일반적 요구로 대체할 수 없듯이, 보다 특정한 요구에서 보다 잘 동작하는 소프트웨어를 만드는 것과 공개 소스 소프트웨어 모듈은 가끔씩 충돌하게 된다.

최고 수준의 공개 소스 소프트웨어 모듈을 잘 활용하는 것, 하지만 핵심적인 부분에서 잘 튜닝되고, 개선된 자체 코드를 사용하는 것이 필요할 것 같다.

공개 소프트웨어와 상용 소프트웨어를 비교할 때 흔히 리눅스가 솔라리스보다 나은가 하는 얘기를 하게 된다. (공개 소프트웨어 내에서도 리눅스와 FreeBSD를 비교하는 경우가 있지만...)

역시 요구에 따라 다른 판단을 내릴 수밖에 없으리라 생각한다. 보다 엄밀한 기업 환경에서 아직 리눅스가 솔라리스와 같은 상용 소프트웨어를 대체할 수 있다고 생각하지 않는다.
물론 비용의 문제도 있지만, 소프트웨어 가격 문제를 배제하고 요구에 따른 질적 수준만을 고려할 때, 리눅스가 더 낫다고 얘기하는 것은 아직 무리라고 생각된다. (리눅스가 새로운 기술을 적극 수용하면서 하나의 방향으로 개선되고 있는지에 대해서도 의문스럽다.)

사용해본 자바 공개 소프트웨어들에 대해 몇 가지 품평을 해본다. (S, A, B, C, D, F)

Apache XmlBeans : BEA에서 기증한 것으로 XML Schema의 사상을 충실히 반영하고 있고, 완성도가 높다. (S)

Apache Axis : 아키텍처나 성능 측면에서 만족스럽지 못하다. (C)

Apache Xerces : 기능적으로는 크게 나쁘지 않으나, 코드의 내적 긴밀성이 떨어지는 듯하다.(B)

Jaxen : 전체적으로 코드가 깔끔하고 간결하다. (A)

Hibernate : 기능적인 측면이나 코드 모두 잘 정돈되어있다. 상용 제품으로 손색이 없다.(A)

Jakarta Slide : 코드가 상당히 어지러우며, 확장성이 떨어진다. (D)

Spring Framework : 크리티컬한 상황에서 테스트가 필요하다. 덩치가 너무 크다. 필요에 따라 모듈화할 수 있어야 할 것 같다. (A-)

동일한 공개 소프트웨어의 가치도 필요한 측면에 따라 달라지기 마련이다.
하지만, 소스 코드를 들여다보면, 코드의 내적 긴밀성이나 잘 정의된 아키텍처의 유무는 소스 코드의 일반 가치를 드러낸다.

공개 소프트웨어를 사용한 소프트웨어의 책임과 한계는 사용된 공개 소프트웨어에 대한 책임과 한계를 포함하는 것이므로, 선택은 좀더 신중해야 한다.
공개 소스 소프트웨어 옹호자들이 주장하는 것과는 정반대로 공개 소프트웨어가 상용 소프트웨어보다 더 많이 테스트되거나 버그로부터 더 자유롭다는 주장은 사실이 아니다. 그것은 신속하고 적절한 소프트웨어 지원 체계가 있느냐 없느냐의 문제이다. 그리고 공개 소프트웨어든, 상용이든 더 엄밀한 요건에서 많이 사용되는 소프트웨어만이 그 엄밀성을 증명할 수 있다.
공개 소프트웨어를 사용하는 소프트웨어라면 그 엄밀성을 담보하는 지원 체계를 갖출 수 있어야 한다.