지난주 이런 저런 사고가 발생해서 정신없이 보내긴 했지만, 그래도 틈틈이 머리도 식힐 겸 JUnit 코드 분석을 시도했다.

3.8은 Cook’s Tour라는 JUnit 핵심설계의 과정을 담은 문서도 있고, Python이긴 하지만 TDDBE에 간단히 만드는 과정도 나와있고 해서 사실 분석하기가 어렵지 않았다. 3.8을 바로 보자면 조금 복잡한 느낌도 있지만, 초창기 버전인 1.0 소스부터 공개되어 있고, 2.0에서 살짝 확장되긴 했지만 거의 초기 설계와 코드를 그대로 유지해오고 있기 때문에 단계적으로 발전하는 과정을 보면서 분석하기에는 아무런 문제가 없었다.

오브젝트 프레임워크 구조인 1.0~3.x와는 달리 애노테이션을 사용하는 DSL스타일의 프레임워크로 바뀐 4.x의 코드는 처음 딱 열어볼 때부터 좀 복잡하다는 인상이 들었다. 단순한 setup-test-teardown구조가 아닌, 각종 애노테이션의 부가적인 기능의 조합(expected, timeout, ignore, beforeclass…, filtering, sorting)을 모두 처리해야 하고, 오브젝트 프레임워크가 아니니 8가지 패턴으로 깔끔하게 만들어진 3.x와는 다를 거라고 생각하기는 했지만, 좀 처럼 쉽게 눈에 들어오는 구조와 코드들이 아닌 것이 내심 불안했다.

켄트 벡이 소개한 JUnit 4.x에 적용했던 두가지 구현(혹은 설계) 패턴(nested method object, conditional factory)을 알고 있지만 그 것만으로는 프레임워크의 기본 구조를 이해하는 것도 쉽지 않았다. 코드를 따라 그림을 그려가면서 한참을 들여다 보고는 겨우 구조와 동작원리가 이해가 됐다. 3.x의 틀과는 완전히 딴판이다. 단지 애노테이션 방식으로 바뀌었기 때문은 아니다. 훨씬 더 근본적인 프레임워크의 확장과 유연성을 고려한 설계의 노력이 느껴지는 코드이다.

하지만 잠시 들여다본 코드는 그다지 인상적이지 않았다. 오히려 조금 실망스러웠다. 4.0이후로 메이저 업그레이드가 있었던 것도 아닌데.벌써 deprecated된 코드들이 제법 있다. 그러고 보니 켁트 벡이 JUnit의 공동개발자인 David Saff에게 "엉망인 코드를 정리하는데 함께 애써줘서 고맙다"는 얘기를 한 것이 기억난다. 그만큼 JUnit 4는 처음부터 실험적이고 모험적인 시도였던 것 같다. 한편으로는 오브젝트 프레임워크가 아니고, 그에 따라 테스트 클래스와 프레임워크의 결합이 거의 없는 수준이니 한편으로는 조금 자유롭게 다양한 실험을 해볼 수 있었던 것일지도 모르겠다.

4.7에서 도입되어서 열심히 실험중인 Inteceptor는 기존의 nested method object와 default runner builder 같은 개념을 좀 더 유연하게 확장하게 만들어준다. 예를 들면 @Test(expected=)를 이용해서 예외를 확인하는 기능을 이제는 인터셉터를 써서 대신할 수 있다. 아마도 테스트 메소드를 지정하는 것을 제외하면 거의 모든 기능을 인터셉터를 써서 새롭게 적용할 수 있을 것이다. 애노테이션이라는 이미 고정된 DSL 표현식을 넘어서서 다시금 오브젝트 프레임워크 시절의 무한한 확장가능성을 JUnit에 넣어줄 수 있는 것이 Inteceptor가 아닐까 싶다. 그래서 처음 이 Interceptor를 JUnit에 도입하던 날 켁트 벡이 흥분해서 트위터에 "JUnit geek들은 어서 최신 소스를 받아서 이 Interceptor를 써보라"고 했던 것 같다. 아마도 이 Interceptor가 중심이 되어서 JUnit이 새롭게 구성되는 시점이 5.0이 나오는 때가 아닐까 하는 예측을 해본다.

 

아무튼 JUnit 4.7는 아직 좀 지저분하다. 다양한 시도와 확장을 고려한 흔적들이 보인다. 어쩌면 필요없을 것 같은, 과도하게 유연하게 만든 코드들도 보인다. 언젠가 deprecated될지 모르겠다. 특히 internal 파트는 그렇다. 아직 4.x용 Cook’s tour가 나오지 않은 이유가 그런 것일지도 모르겠다. 어쨌든 좀 더 분석을 해보면 재밌는 모습을 찾을 수 있을 것 같다. 다양한 실험적인 시도들(theory, assume, maxcore, parallel, interceptor)도 살펴보는 것도 재밌을 것 같고.

 

한가지 떠오른 생각이 있다면. JUnit 4.x의 테스트 코드는 애노테이션을 제외하면 사실 프레임워크 구현에 매여있지 않다. 그렇다면 그 애노테이션을 그대로 사용하면서 새로운 테스트 프레임워크를 만들어보면 어떨까 하는 생각도 들었다. JUnit을 대치할 이유는 없으니, 뭔가 실험적이고 학습에 도움이 되는 시도를 해보는 것도 재밌을 것 같다는 생각이 들었다. JUnit의 nested object method 패턴을 스프링의 AOP나 callback/template를 이용해서 만들어보면 어떨까 하는 생각도 든다. 스프링으로 만드는 JUnit4 호환 테스팅 프레임워크라? 이거 구미가 땡기는데… 4.7 코드 분석이 모두 끝나면 한번 시도해 볼까?

자꾸 미루고 있던 JUnit 4.x의 설계와 코드 분석을 오늘부터 시작하기로 결심했다. 최근에 릴리스된 4.7 Snapshot 5/11 버전을 보고 더이상 미루면 안되겠다 싶었다. 오브젝트 프레임워크인 JUnit 1,2,3는 모두 분석해보았지만, DSL 프레임워크로 바뀐 4.x는 몇번 손을 대려다가 만만치 않은 분량의 새롭게 작성된 코드를 보고, 그걸 핑계 삼아 자꾸 미뤄왔는데 더 이상 미루면 안될 것이다.

내 시간관리 방침은 "중요한 일보다는 급한 일을 먼저하고, 급한 일보다는 재밌는 일을 먼저 하자" 인데(결국 중요한 일은 재밌는 일로 바뀌지 않으면 항상 뒷전이 되고 말 수 밖에 없다는…) 이 처럼 재밌는 것을 자꾸 미루면 되겠는가.

암튼 시작.

일단은 4.7에 추가된 Interceptor부터 살펴보고, 4.x의 바뀐 구조를 쭉 훝어볼 생각이다.

어제 내가 흥분해서 글을 쓴 이유는 방영준이라는 사람의 내 가짜 전문가 친구를 소개합니다라는 글과 그에 대한 답글을 보았기 때문이다. 인신공격을 통해서 자기의 주장(오픈웹 운동 반대)을 합리화 하려는 비겁한 태도나, 나보다 못한 너 따위가 유명해진게 싫어라는 질투에 가득찬 내용에 대해서는 더 이야기 하고 싶지 않다.

 

이 글에서 그는 channy님과 같은 분은 파이어폭스 브라우저 핵심개발에는 참여하지 않고 한글번역이나 현지 홍보나 하는 L10N(지역화) 담당자에 불과한데 오픈소스 전문가로 행세하고 다니는 것은 마치 싸이가 자기도 개발업체에서 테스트를 했으니 개발에 참여한 것이라고 우기는 것처럼 허풍이라고 비난한다.

여러 가지 중에서도 번역이 가장 낮은 급의 작업이다. 일정 규모 이상의 오픈 소스 프로젝트들은 대개 기여도가 높고 권위를 인정받는 소수의 개발자들로 이루어진 핵심 그룹이 전반적인 개발 방향을 결정하며, 그 밑에 나머지 대다수 개발자들이 개인적으로 또는 팀을 이루어 개발에 참여한다. 그리고 사이트 관리자나 번역자들이 있어 개발외적인 분야에서 프로젝트에 참여한다. 여기서 중요한 것은 번역자는 개발자가 아니기 때문에 개발에 참여하지 못한다는 점이다. 개발에 참여하지 못하므로 프로젝트에 행사할 수 있는 영향력도 거의 없다(돈이라도 많아서 거액을 후원한다면 모를까). 따라서 개발자가 아니면서 프로젝트 내에서 뭔가 중요한 일을 하는 것처럼 말하는 사람은 한마디로 허풍쟁이다.

한국은 영어권 국가가 아니므로 현지화/지역화 과정이 필수다. 오픈소스 제품은 영리를 위한 기업의 노력도 없으므로 당연히 자원자들에 의해서 문서와 메시지들이 번역되야 하고, 그 중에 일부는 고정적인 책임을 맡아서 정식으로 프로젝트 팀에 참여하게 된다. 프로젝트에 대한 기여도나 영향력 면에서 그들은 핵심 기술개발자에 비해서 파워도 적고 폼나는 것도 없기 때문에 사실 더 하기 힘든 일이라고 볼 수도 있다. 그런면에서 오랜동안 오픈소스 문서를 번역해서 올리고, 한글 메시지를 작성해 제공했던 동국이는 참 대단한 사람이다. 기선이도 최근에 Maven에 한글 메시지를 제공해서 최신 버전에 포함된 것으로 알고 있다. 내가 아는 한 channy님은 방영준님이 비난한 것처럼 한번도 자신이 개발자인 척 하거나 프로젝트에서 중요한 일을 하는 사람처럼 말한 적이 없다. 나는 channy님이 KLDP컨퍼런스에서 파이어폭스에 관해 발표하는 것을 본 적이 있다. 온라인보다 좀 부담이 적어서 과장도 하기 쉬운 오프라인 발표자리에서도 그분은 자신이 하는 일에 대해서 명확하게 선을 그어서 오해하지 않도록 잘 설명주었다.

 

channy님은 프로젝트 제품 개발자는 아니다. 그럼 오픈소스 프로젝트의 핵심 개발자, 그것도 리포지토리에 커밋 권한을 부여받은 극소수의 개발자가 아니라면 "오픈소스 전문가"라고 할 수 없는가? 방영준님의 주장대로 그것은 "남이 차려놓은 밥상에 숟가락만 하나 얹은 것"일까?

 

더 나아가서 사용자 커뮤니티를 이끌거나 보급을 위해 노력을 하는 일개 "사용자" 중에서 나름 전문가로 불리는 사람들은 그럼 뭘까? 그건 남이 숟가락으로 떠준 것에 입만 들이대는 사람일까?

나는 오래전에 개인적으로 오픈소스 프로젝트에 개발자로 참여한 적도 없으면서 오픈소스에 관해서 함부로 얘기한다고 심하게 공격당한 경험이 있다. 지금은 아무도 알아주지 않지만 OSAF1과 2를 공개했어서 그래도 좀 다르겠지만. 그때는 주로 물개와 함께 오픈시드에서 활동하면서 한국에도 스프링과 같은 좋은 자바 오픈소스 프레임워크를 활용해서 엔터프라이즈 애플리케이션 개발이 가능하다는 것을 알리고, 그 구체적인 기술과 전략을 홍보하는데에만 주력하고 있을 때다. 어쩌면 오픈소스 사용자 커뮤니티를 이끌고, 제품의 메시지는 아니지만(UI가 있는 제품도 아닌데 스프링에 메시지가 뭐 있겠나), 레퍼런스 문서나 API문서 또는 영문으로 된 소개자료 등에 나타난 정보를 보는데 부담을 느끼는 사람들을 위해서 한글로 작성한 정보들을 생산해 내려고 애쓰고 있었다. 그런 식의 비난이 많이 억울했지만 공격의 이유가 사실은 다른데 있다는 것을 눈치챘기 때문에 그냥 별 대응없이 넘어갔다.

방영준님의 주장대로라면 오픈소스 문서를 공식적으로 번역하는, 저급이지만 프로젝트 팀원도 아니고, 그저 사용이나 하면서, 정보들을 짜집기해서 한글로 좀 올리고, 여기 저기가서 소개나 활용에 관한 세미나를 하고, 잡지 기고도 하는 나나 영회, 물개 같은 사람이 전문가 취급을 받는 것은 거의 기절할만한 일일지도 모르겠다.

 

본인의 의도와 상관없이 한국에서 오픈소스 전문가로 취급당하는 것은 그래서 한편으로 씁쓸한 일이다. 진짜 고수들은 자기 자리에서 묵묵히 일하고 있는데 외국 오픈소스 제품 조금 먼저 써봤다고 잘난척 하고 다닌다는 식의 말을 들을 때는 더욱 그렇다.

 

솔지히 나는 오픈소스 전반에 관해서는 그다지 관심도 없고, 잘 알지도 못한다. 내가 관심있는 것은 생산성 높게 좋은 품질의 제품을 개발하게 도와주는 자바 프레임워크와 관련 기술 뿐이다. 그것이 오픈소스든 아니든 별 상관은 없다. 그래서 나는 스프링소스의 비공개소스/상용제품이나 아틀라시안의 오픈소스가 아닌 제품을 좋아하기도 하는 것이고. 나는 그저 내가 경험한 좋은 것을 남들에게도 나누고 싶을 뿐이다.

전문가는 일만시간을 수련을 위해서 투자해야 한다는데.. 전문가는 무슨!

http://kldp.org/node/99481 에 따르면 NHN이 조만간 여는 행사에서 오픈API와 함께 일부 오픈소스 제품을 공개한다고 한다. nForge, 큐브리드DB, 제로보드XE 등이 그 대상인듯 한다.

nForge는 정체를 정확히 모르겠지만 gForge와 유사한게 아닌가 싶다. 그 개발과정은 잘 모르겠고. 큐브리드DB는 업체를 통채로 인수해서 그 제품을 오픈소스화 한 것이다. 제로보드XE는 제로보드 개발자를 영입해서 제로보드 오픈소스화를 작업하도록 한 케이스라고 알고 있다. 결국 두가지는 외부에 이미 존재하단 제품과 개발자, 기업등을 영입해서 오픈소스화 해서 공개하는 케이스라고 볼 수 있다.

글에 따르면

우리나라에서 이정도 규모로 하나의 기업이 인력과 자본을 투자하여 그 결과물을 오픈소스로 공개하는 사례는 제가 알기로 전혀 없었고… 전 세계적으로도 상당히 드문 케이스로 꼽을 수 있을 만큼 획기적입니다.

라고 한다.

케이스를 찾아볼 수 없는 획기적인 일이라고 자화자찬을 하지만 사실 드물지 않은 케이스가 아닌가? 국내는 관심이 많지 않아 잘은 모르겠지만 그래도 최근에 삼성SDS가 공개한 Anyframe만 해도 SI업체의 핵심자원이라고 할 수 있는 최신 프레임워크를 상당한 기간동안 외국에 나가서 개발하기도 하고, 세계적인 전문가들에게 컨설팅을 받기도 하면서 개발하고 현장에 적용했던 기술인데 그것을 오픈소스로 공개한 것이니 상당한 인력과 자본을 들인 것이 분명하다. 대우정보통신의 애플리케이션 프레임워크도 오래전부터 오픈소스로 공개되어져 왔다.  따라서 국내에 사례가 없다는 것은 틀린 얘기다. 뭐 KLDP는 리눅스와 그 베이스의 제품이 아니면 오픈소스로 취급하지 않는 리눅스광들이 모인 곳이라서 자바 오픈소스제품은 오픈소스 취급을 안해주는 것이라서 그럴까?

또 해외의 케이스는 정말 부지기수다. 내가 아는 쪽은 자바에서도 극히 한정된 분야긴 하지만, 얼마나 많은 기업들이 그 크기와 상관없이 자사 제품 또는 영입한 회사의 제품을 오픈소스화 했는지 이루 헤아릴 수 없다. KODO라는 가장 성공한 JDO제품의 기업을 인수해서 그 코드베이스를 이용해서 OpenJPA를 만들어 아파치에 기증한 BEA의 예를 비롯해서, IBM은 정말 수도 없이 많은 자사 제품을 오픈소스로 공개하고 기증했는지 모른다. 이클립스, AXIS2, Equinox를 비롯한 관련 수많은 기술들이 IBM의 상용제품에 적용되고, 발전해온 코드를 기반으로 오픈소스화 된 것이다. 그뿐인가 오라클 또한 TopLink의 JPA버전을 Toplink Essential (최근에 이름이 바꼈는데 기억이 안나단..)이라고 오픈소스화 해서 공개했다. 개발자 영입은 훨씬 더 흔한 예다. 제로니모 개발자를 영입해서 Websphere Community Edition을 만들어서 오픈소스 WAS로 적극 보급을 하고 있다. 그 기업들이 들인 비용은 NHN이 큐브리드업체를 인수한 비용과는 비교할 수 없을 만큼 거금이었던 것으로 안다. SUN은 뭐 워낙 많아서 다 말하기도 귀찮다. 대기업 뿐인가 벤처기업들도 제품의 일부 또는 전체를 오픈소스로 공개하고 있다. 따라서 "세계적으로도 드문케이스"라는 것도 사실은 "그다지 드물지 않다"고 반박할 수 있겠다. 혹시 리눅스쪽에서는 드문 것인지는 모르겠지만.

기업들이 그렇게 하는데는 여러가지 이유가 있을 거다. 어쨌든 자사에 어떤 면으로든 장단기적으로 이익이 되기 때문일 것이니 하는 것 아니겠는가. 어쨌든 개발자로서는 고맙고 반가운 일이다. 비록 뒤에서는 자사 기술을 오픈소스로 뿌려서 시장을 독점화 하고 짭짤한 서포트와 관련 비즈니스로 돈을 긁어모으려는 생각이거나 자사 이미지개선 내지는 홍보용으로 투자하는 것일 수도 있고, 영입업체나 개발자 인력을 끌어들이기 위한 수단일지도 모르겠지만 뭐 비즈니스란 원래 그런 것이니까.

 

어쨌든 NHN의 이번 일은 환영할 만한 일이고 관심이 간다. 하지만 외부 기술을 끌어와 공개하는 것보다는 자사에서 개발하고 적용했던 핵심 기술의 일부를 공개해주는 것이 더 낫지 않았을까 싶다. 어쨌든 스프링을 적용한 국내의 최대 사이트 중 하나가 바로 NHN인데 스프링 기반의 자사 프레임워크를 오픈소스로 공개했줬다면 얼마나 좋았을까. 또 들리기는 OSGi를 이용한 플랫폼도 만들었다던데… 흠. 좀 욕심일까?

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha