오픈 소스 코드 분석을 위한 팁 - 펌글

MySQL, Apache, Tomcat 등과 같은 오픈 소스는 매뉴얼이나 문서, 책 등도 많이 나와 있으며 오픈 소스이지만 솔루션 자체도 안정적이라서 특별한 이유가 아니면 소스를 분석할 필요는 없습니다.
하지만 하둡이나  NoSQL  등과 같은 솔루션은 문서도 부족하지만 문서로만 설명할 수 없는 복잡한 내용으로 구성되어 있는 솔루션이 많습니다. 따라서 제대로 솔루션을 사용하거나 운영하기 위해서는 반드시 소스 분석이 필요하게 되었습니다.
  
최근 루씬 기반의 분산 검색 엔진 솔루션인 ElasticSearch를 분석할 필요가 있어 몇일간 삽질했었는데 삽질하면서 제 나름대로 오픈 소스 분석에 사용하는 몇가지 팁을 정리했습니다. 제가 주로 사용하는 프로그램언어가 자바라서 대부분 자바 기준으로 되어 있습니다.

- 해당 솔루션에 대한 기본 지식을 먼저 익혀라.
하둡을 분석하려면 구글에서 발표한 논문을 읽어 봐야하고  HBase를 분석하기 위해서는 BigTable 논문을 읽어야 한다,
분석하고자 하는 솔루션에 대한 이론적인 배경 지식이 없는 상태에서 소스 코드를 바로 보면 그냥 스파게티처럼 얽혀 있는 코드를 보고 있는 느낌이 들것이다. 

- 특정 알고리즘에 대해서는 코드가 더 보기 쉬울때도 있다.
전체 코드 중 일부는 어떤 알고리즘이나 기법을 구현한 코드가 있을 수 있는데 이 경우 해당 솔루션내에 있는 코드를 먼저 이해하기 보다는 그 알고리즘만 구현된 공개된 코드를 찾아서 보는 것이 알고리즘을 문서로 이해하는 것보다 훨씬 빨리 이해할 수 있다.

- 분석하고자 하는 프로그램 언어에 대한 기본 지식은 필수이다.
두말하면 잔소리...

- 본인 PC에 빌드 및 실행 환경을 구축하라.
코드 분석을 빨리하기 위해서는 분석에 필요한 로그를 추가하여 재 컴파일한 후 실행하면서 로그를 확인하는 것이 좋다. 단순 코드만 보면 특정 연산의 흐름이 어떻게 진행되고 있는지를 파악하기 어려운 경우가 많기 때문이다.
최근의 오픈소스들은 분산 환경에서 운영되는 경우가 많은데 이 경우라 하더라도 개발자의 PC(가능하면 노트북)에 빌드와 실행환경을 모두 구성하는 것이 좋다. "좋다"라는 정도가 아니라 필수 사항이라 할 수 있다. 
최근 오픈 소스는 복잡도의 증가와 연관된 다른 오픈 소스가 많아서 eclipse 등에 빌드 환경을 구성하는 것이 쉬운 작업은 아니다. 빌드 및 실행환경을 구성하는 것만으로 코드 분석의 50%는 진행되었다고 할 수 있다.
그리고 가능하면 노트북에 환경을 구성하여 회사, 집, 이동중에도 지속적으로 분석할 수 있는 환경을 갖추는 것이 좋다.
참고로 필자의 노트북은 맥북프로인제 최근 리눅스 기반 오픈 소스 솔루션이 많이 나오고 있는데 업무용 PC와 개발용 PC를 같이 사용하는데에는 이만한 노트북은 없는 것 같다. 메모리 8GB에 SSD(필자는 SATA) 정도면 왠만한 시스템은 다 실행할 수 있다.
필자의 경우 MySQL, ZooKeeper, Hadoop, Flume, ElasticSearch, HBase 등은 노트북에서 실행한다.  그리고 필자의 eclipse에는 프로젝트가 100개 이상으로 대부분은 오픈 소스 프로젝트 코드를 구성한 것이다.
일부 대기업의 경우 보안 등의 문제로 노트북의 외부 반출을 엄격하게 제한하고 있는데 이러면서 소프트웨어에 투자하겠다는 등의 소리는 하지 말았으면 한다. 소프트웨어에 대한 실력은 지정된 자리에 앉아서만은 결코 이룰수 없다. 

- 자신에게 질문을 많이 하라.
오픈 소스 개발자라고 해서 하늘에서 떨어진 개발자는 아니다. 대부분 비슷한 교육을 받고 비슷한 경험을 하고 있다. 따라서 특정 기능에 대해서 나라면 어떻게 개발했을까? 라고 자신에게 질문을 던지고 머리속에 어떻게 구현할 것인지를 먼저 그려본다. 처음에는 많이 틀리겠지만 코드를 많이 보고 연습을 많이 하면 이것도 얼추 많이 맞춘다. 

- 분석하면서 문서로 정리하라.
분석을 하면서 그림 또는 문서로 정리를 해라. 굳이 UML이 아니더라도 ppt 같은 도구로 정리하면 된다. 이렇게 중간 중간에 정리하면 머리속에서만 빙빙 돌던 생각이 정리될때가 많다. "분석이 다 된 다음에 깔끔하게 정리해야지" 라는 생각이면 거의 정리는 못한다고 봐야 한다. 나중에 정리하려면 정리도 어렵고 생각도 잘 나지 않는다.
다음은 필자가 2006년에 분석한 Hadoop의 MapReduce 처리를 정리한 그림이다.

-  LOG level을 DEBUG로 설정하라.
배포되는 패키지는 대부분 Logger의 설정이 INFO 또는 WARN으로 설정된 경우가 많다. 더 많은 정보를 얻기 위해서는 logger 설정의 DEBUG로 설정한다. DEBUG로 설정할 경우 너무 많은 로그 메시지가 나올 수 있는데 패키지 수준에 따라 적절하게 LOG level을 설정한다.

- 디버거의 breakpoint 기능을 활용하라.
집중적으로 분석하고 싶은 구간은 디버거의 breakpoint 기능을 이용하여 step 단위로 실행하면서 각 변수의 변화 상태를 확인한다.

-  System.out.println 보다는  Thread.dumpStack()을 활용하라.
객체지향 구현의 단점이 상속 관계에 있으면 어떤 클래스가 실제로 호출되는지 실행환경에서 결정되는 경우가 많다.
특히 자바의 경우 reflection이나 Injection을 사용하게 되면 어떤 객체가 호출되는지 코드만 봐서는 이해하기 어려운 경우가 많다. 그리고 해당 로직이 어떤 경로를 거쳐 호출되는지 찾기 어려운 경우가 많다.
이 경우 앞에서 설명한 디버거를 이용할 경우에도 어디에 breakpoint를 걸어야 할 지 애매한 경우가 많은데 이때 Thread.dumpStack() 코드를 적절한 위치에 추가하면 전체 호출 흐름을 볼 수 있다.

- 당장 관심있는 부분부터 집중적으로 파악하라.
방대한 시스템의 경우 전체를 보다 보면 금방 지루하고 갈 곳을 읽어 버리는 수가 많다. 당장 필요하거나 관심있는 부분부터 집중해서 보는 것이 좋다. 하둡 파일 시스템의 경우 클라이언트 모듈인 FileSystem과  DFSClient부터 보면서  해당 기능과 연결되어 있는  NameNode, DataNode의 method를 파악하는 것이 좋다.

 - 그래도 어려우면 초기 버전을  다운로드 받아 분석하라.
복잡해보이는 오픈소스도 초창기 버전은 단순하게 기본 기능만 구현되어 있는 경우가 많다. 버전이 올라가면서 개발자들이 많이 참여하게 되고 코드는 점점 복잡해지고 기능도 많아지게 된다. 초창기 버전에서는 핵심 기능에만 집중하는 경우가 많기 때문에 핵심 기능을 분석하기에는 초창기 버전이 좋다.

대충 생각나는 것만 정리해 보았습니다. 더 좋은 팁 있으면 댓글 환영합니다.

출처 - http://www.jaso.co.kr/462

babokim