코드 소스 분석하기

 

한동안 접고 살던 Spring framework오픈 소스를 다시 꺼내 분석한다면 나는 어떻게 할까? 일단 생각해보고 정리를 하자니... 장강의 뒷물의 앞물을 밀어낸다고 - 이게 아닌가? 아무튼 생각이 유실될 우려가 있어 그냥 냅다 적어보기로 한다.

남의 소스를 분석한다는 것은 남의 생각 속을 여행하는 것에 비유할 수 있다. "여행"을 하려면 무엇이 필요한가? 아니, 길을 잃지 않기 위해서는 무엇이 필요한지 생각해보자. "GPS"과 "지도"가 필요할 것이다. 그리고, 내가 가야할 길은 아직 가보지 않은 길이기 때문에 욕심 부리지 않는 '자세'를 준비하자. (무심결에 나침판이라고 적고 보니... 21세기인데.. 라는 생각이 들어 고쳤다.)

항해(navigation)를 시작하기 전에 준비물이 잘 갖추어 있는지 확인해 보자.

 

 

 

1. GPS (Global Positioning System)

프로그래머에게필요한 GPS는당연히실제물리적인장치가아니다. 소스를분석할때, 내가어떤소스를분석하고있으며, 다음으로어느소스를분석해야하는지를판단하는데필요한도구이다.

내가 생각하는 소스 분석에 필요한 GPS 도구들은 다음과 같다. 프로그래밍 언어론에 대한 기초 지식 혹은 프로그래밍 언어 문법에 대한 정확한 지식이다. 언어를 모르는 사람이 소스를 분석하겠는가 라고 반문하겠지만, 남의 소스를 분석하다 보면 평소에 모르던 키워드나 연산자 혹은 문법을 마주치는 법이 생기게 마련이다. 막다른 골목에 다다르는 것과 같은 현상이 벌어진다. 즉, 머리속이 하얗게 지워진다. 이전까지 분석한 게 다 머리 속에서 지워지고 만다. goto 명령어는 자바에도 있다. 안쓸거라고 생각지 마라. 다중 루프에서 고속으로 탈출하기 위해 사용되는 경우도 간혹 있다. final 이 클래스에 붙어 있을 때 그 의미를 파악하지 못하거나, public 수식어가 없는 클래스의 의미를 모르면 오픈 소스 설계자의 진의를 절대 파악할 수 없다. 문법 공부할 때 뒷장은 건너뛴 사람은 분석하다가 오도가도 못하는 신세에 빠지는 경우가 많다. 언어의 문법을 일부만 알고 오픈 소스를 분석하는 것은 단어 몇개만 배우고, 사전도 없이 뉴욕 한복판에서 엠파이어 스테이트 빌딩을 찾는 것과 같다.

다음으로 상속과 합성에 대한 개념이다. 상속과 합성은 이정표에 해당한다. 객체지향이건 절차지향이건 간에 소프트웨어는 항상 '부품'들이 조립되는 방식으로 구축된다. 그런데, 상속과 합성의 개념을 제대로 모르면 위아래로 이동해야 하는지, 좌우로 움직이야 하는지 모르게 된다. 그리고 코드를 따라가다가 어떻게 되돌아 가야 하는지 모르게 된다. 미로에 빠지고 말 것이다. 그냥 상속만 익히면 된다고 생각지 말라. 인터페이스와 구현체 간의 관계 등을 모르면 지나쳐도 되는 코드와 코드들의 집합인 모듈 단위를 전혀 알아 볼 수 없게 된다. 코드는 단순히 작은 메소드들의 무수한 나열이 아니다. 작은 단위들이 모여 큰 단위를 이루고 작고 큰 구조를 표현하기 위해 인터페이스 상속과 패키지 개념들이 있는 것이다. 모르고 보면 아무리 보고 또 봐도 까만 건 코드, 하얀 건 배경일 뿐이다.

리팩토링은 몰라도 된다. TDD도 필요 없다. 다만, 디자인 패턴은 알아야 한다. 패턴을 이해하는 것은 운전 면허 시험을 배울 때, 교차로와 순환로 등 다양한 도로 형태를 배우는 것과 동일하다. 사람은 익숙한 지형이나 형태를 보면 깊이 생각할 필요도 없이 반사적으로 움직일 수 있다. 소스 분석도 이와 같다. 패턴을 모르면 그만큼 분석하는데 드는 시간이 기하급수적으로 늘어난다.

이클립스 혹은 IntelliJ 같은 IDE 사용 방법에도 능숙해야 한다. 탐색기를 이용해서 소스를 하나씩 열어보거나, notepad++ 로 수많은 소스를 열어 본다면? 노가다로 시간 낭비하지 말자. 상위 클래스, 하위 클래스, 참조 위치 등등 단축키만 알면 아무리 멀고 먼 위치도 워프(warp) 할 수 있는 순간이동 능력을 갖출 수 있게 된다. 다만, 앞서 말한 상속과 합성 개념이 머리에 박혀있지 않으면 금새 지나온 길을 잃어 버리게 된다.

API와 라이브러리에 대한 경험... 코드를 따라가다 보면 자칫 너무 깊이 파서 땅속으로 파고 들 수 있다. 궁금하다고 클릭하다 보면 어느새 JDK 소스를 보고 있다는 사실 조차 모르게 된다. 그럴리 없다고 생각지 말라. JDK를 설치하면 소스도 따라온다. IDE에 decompiler를 설치해두면 클릭 한 번에 지하세계로 떨어진다. 라이브러리도 마찬가지인데, 자칫 내가 프레임워크를 분석하고 있는 건지 라이브러리 코드를 분석하고 있는 건지 혼란에 빠지게 된다. 더 심하면, 프레임워크가 의존하고 있는 라이브러리와 프레임워크를 구분하지 못하는 일체의 경지에 빠지게 된다.

 

2. 지도 (map)

무턱대고서울간다고지도도없이나서면, 어느산골구석이나경찰서유치장에서발견될수도있다. 오픈소스를막무가내로이해하려는개발자라면, 소프트웨어에대한환멸을느끼고 IT 업계를영영떠날수도있다.

가급적 분석하고자 하는 오픈소스에 대한 설계에 대해 많은 정보를 제공하는 책을 구해야 한다. 오픈소스를 창작자가 서술한 책이면, 창시자의 철학을 옅볼 수 있기 때문에 가장 좋고, 없다면 가장 두꺼운 책을 사야 한다. 두꺼울수록 다루는 부분이 많기 때문에 분석하면서 낯선 코드를 만나는 경험이 줄어든다. 책을 통해 큰 흐름과 전체 얼개를 파악하면 많은 시간을 절약할 수 있다. 책을 사기 싫다면 해당 오픈 소스의 홈페이지의 introduction, user's guide, 그리고 각종 reference 문서를 최대한 많이 읽어두면 좋다. 책도 안사고, 홈페이지에도 안 가 봤다면 분석을 포기해라. 당신이 수재 이상의 머리를 가지고 있지 않다면... 샹 폴리옹인가? 그럼, 구글 가라.

영어가 싫다면 해당 오픈 소스에 대해 언급된 국내 블로거들의 글을 최대한 검색해서 많이 읽어라. 그 어떤 책이나 블로그 글도 오픈 소스 전체를 설명할 수는 없지만, 부분에 대한 이해만 해도 길을 찾는데 큰 도움이 될 것이다. 그리고, 사전에 해당 오픈 소스에서 많이 쓰이는 클래스/ 메소드 명칭에 익숙해지면 좀 더 소스가 자연스럽게 읽힌다. 인간의 두뇌는 익숙한 것일수록 해석 속도가 매우 빨라지기 때문이다.

마지막으로 종이와 연필을 준비해라. 소스를 분석하면서 눈에 띄는 소스 파일 명칭과 메소드 명칭들을 적고, 클래스 다이어그램과 시퀀스 다이어그램을 그려본다. 직접 지도를 만들라는 것이다. 종이에 적으라는 이유는 우선 컴퓨터 화면에는 소스만 띄워놓아야 집중이 잘되고 덜 산만하다는 것이고, 사람 머리는 손으로 무언갈 쓰거나 할 때 논리회로가 잘 돌아간다. 참고로 Robert C Martin 선생님이 말씀하시길 UML을 그리는데 있어서 가장 좋은 도구는 종이와 연필이라고 했다.

내가 선호하는 오픈 소스 분석 방법은 디버거(debugger) 혹은 로그 분석을 해보는 것이다.어플리케이션을 디버그 모드로 실행하면서 stack trace을 추적해보거나, 분석하고자 하는 위치에 break point를 걸어둔 후에 정지 시키고 나서 해당 위치가 실행되기 이전과 이후를 분석한다. 때로는 일부러 예외를 발생시킨후에 로그를 분석하기도 한다. 대다수의 오픈 소스는 debug, trace 로그 출력을 제어할 수 있기 때문에 상당히 긴 로그를 분석할 각오가 되어 있다면, 로그 출력 수준을 높이고 (TRACE 레벨) 프로그램을 실행시켜 보는 것도 한 방법이다. 당연히 log4j 혹은 logback 환경 설정을 선행하는 것은 필수 작업이다.