소스 코드 분석하는 현명한 방법? C++ 개발자 정리법

 

서론은 생략하고 본론입니다. 저는 c++ 소스코드 분석은 아래처럼 합니다.

사내 시스템이 있다면 아래처럼 해도 됩니다. 왜냐면 문서와 주석에 주요 성능 이슈나 기타 사항들이 많으니까요. 하지만, 문서도 없고 주석도 없는 상황이라면 어떡할까요? 개발자로선 방법이 없습니다.

 

그냥 코드만 바라보며 속된 말로 삽질을 반복하죠. 어느 누가 되었건, 소스코드 분석하려면 기본적으로 이런 건(아래 항목) 갖춰야 합니다. 해당 사항은 5가지로 간략하게 서술합니다.

 

- 제작 의도를 파악한다

- 이곳엔 이게 있고, 저곳엔 저게 있다는 걸 대충 파악한다

- 실행 환경을 갖춰본다 (100%가 아니어도 괜찮다)

 

- 일단 실행시킨다

- 막 써본다

- 버그가 나건 말건 일단 막 쓴다

 

- 그리고 코드를 본다

- 일단 본다

- 또 본다

- 담배 하나 핀다

 

- 봐선 안 되겠다 싶어 문서를 뒤진다

- 문서만 본다

- 문서만 보다가 졸기도 한다

- 문서와 코드를 매칭시킨다

 

- 잘 모르겠다며 도움을 청한다

  -- 도움 청할 개발자가 없으면 다시 처음으로 돌아간다

  -- 문서가 잘못되었으면 문서 만든 사람한테 따진다. 그래 봐야 바뀌는 건 없지만

- 한숨을 쉬며 퇴근한다

 

- 그리고 다시 반복한다

 

 

 

1. 시간을 갖고 침착하게

소스코드 분석 땐, 조급하면 안 됩니다.

간단한 테스트 프로그램이야 한 두 시간이면 응용할 수 있지만, 큰 프로젝트라면 단기간에 끝나지 않습니다. 소스 한 줄 한 줄을 파악하지 말고, 큰 그림에서 함수 콜~ 정도만 파악하며 전체 흐름을 이해합니다. 다음 2번에서도 다루지만, 소스를 제대로 이해하려면 소스만 봐선 안 됩니다. 주변 지식을 인지하고 왜 이런 소스가 탄생했는지도 살펴야 하기에 시간이 오래 걸리는 일입니다. 시간을 갖고 침착하게 해야 합니다.

 

2. 문서를 살펴볼 것

처음엔 문서를 잘 살펴야 합니다.

이걸 왜 만들었고, 어디서 사용하며, 누가 만들었고, 구동 환경은 어떻고, 누가 사용하고, 기타 등등 문서를 봐야 합니다. 그런 문서야말로 소스 코드의 삼신 할매나 다름없으니깐요. 그러나, 문서도 주석도 없는 회사라면 사표 쓰는 것도 좋은 방법입니다. 기본 개발 문서도 안 챙기는 회사에서 좋은 코드와 결과물을 제작할 확률은 낮습니다. 앞으로 살아갈 날을 위해서 일찌감치 다른 곳을 알아보는 게 더 나을 지도요.

 

 

3. 디자인 패턴 지식

디자인 패턴을 왜 배우냐면, 효율적인 소스 관리 때문입니다. 느슨한 결합을 통해 좀 더 효율적으로 소스를 관리하기 위함이죠. 그렇다 해도, 모든 소스에 디자인 패턴을 접목하지 않아도 됩니다. 꼭 해야 하는 곳에만 해도 됩니다. 너무 남발하는 것도 좋진 않아요.

 

디자인 패턴이 적용되지 않은 소스라 해도 디자인 패턴을 통해 습득한 지식으로 조금 더 빠르게 소스를 파악할 수 있습니다. 소스의 분할, 통합에 개념 및 구현 능력은 디자인 패턴을 아는 개발자가 모르는 사람보다 앞서는 이유 중 하나입니다. 디자인 패턴 지식이 전혀 없다면, 시간을 내어 공부하는 것을 추천합니다.

 

 

4. 주석을 흘리지 말 것 (=프로그래머 상식)

개발 과정에선 주석을 많이 적으며, 이 주석들은 산출 문서의 기반입니다. 또한, 주석의 양과 위치에 따라 개발 단계를 유추할 수 있습니다.

 

중요 부분에만 = 어느 정도 완료

많은 부분에 꼼꼼히 = 열심히 개발 중

 

주석은 프로세스와 컴파일러에 따라 영향을 줄 수도, 안 줄 수도 있기에 일반적으로 개발이 완료되어 가는 시점에 정리합니다. 필요한 부분에만 남겨두고 나머진 삭제하는데, 이때 대부분 소스는 개발 문서로 복사됩니다. 주석은 이슈가 될 만한 부분, 또는 빈번한 수정이 일어나는 지점에만 남기에, 개발 완료 이후에도 남아있는 주석이라면 주변 소스도 잘 봐야 합니다.

 

5. 소스 트리부터

소스 트리를 살펴보세요.

소스 트리는 대게 주제별, 코드별, 구조별로 분리됩니다. 이 트리만 파악해도 1%는 끝난 것이나 다름없습니다만, 한 폴더에 모든 파일이 옹기종기 모여있다면??? 음... 안타까운 상황이네요. 보통은 분리를 하는데... 그렇게 해야 하는데...

 

저는 소스 트리를 장치별로 분리합니다. 비슷한 소스를 쓸 일이 생긴다면 폴더 자체를 복사해서 사용할 수도 있죠. 물론 사내 라이브러리가 존재하지만, 테스트 프로그램을 만들 땐 소스를 직접 수정할 수 있는 파일들을 먼저 이용합니다.

 

-- 끝 --

 

 

 

위의 5가지를 통해 그나마 현명하게 소스코드 분석하는 방법을 언급해 봤습니다.

 

 

그러나 안 좋은 방법도 있습니다. 제가 겪어 본 일과 들어본 일을 아래에 적습니다.

 

예전 포스트 참조

 

1. 소스코드 분석 vs 언어 공부, 현업 흐름이 중요

2. 답답한 FA 분야 프로그래머 일하는 스타일, 개발자 자질 문제

 

1. 소스 타이핑

정말 해괴한 짓입니다. 아무짝에도 쓸모없는 짓입니다.

 

실제로 이렇게 해서 도움이 됐다는 사람이 있다면, 개발자로선 멀리하세요. 일반적인 사상을 받아들이지 않고, 자기 것만 외치는 사람일 가능성이 높습니다. 실제로 제가 해봤던 일인데, 타이핑을 하다 보면 나는 여기서 뭘 하고 있는 건지 뇌리를 스칩니다. 업무 지시를 한 상사는 ... 정말 좋지 않은 사람이었습니다. 저는 너무 비합리적인 이 업무 지시를 반나절만 따르다가 더 높은 상사에게 아닌 건 아니라 말해서 타이핑은 그만둔 적이 있습니다.

 

 

2. 이해될 때까지 설명해라

이것도 정말 말이 안 됩니다. 설명해 주는 프로그래머는, 인계자가 소스코드 분석 과정 중 궁금한 사항이 생겼을 때만 설명해야 합니다. 물론 이전에 관련 문서와 주변 정보에 관해선 먼저 설명을 해야겠죠. 그러나 이해될 때까지 옆에 앉아서 시시콜콜한 것까지 설명하라는 식의 태도는 정말 곤란합니다. 이해될 때까지 옆에 앉아서 계속 말로 떠드는 건, 서로에게 좋지 않습니다.

 

이것도 제가 겪었던 일인데, 인계자 그 녀석도 참 ... 한번은 저에게 변수 이름의 의미와 소스 트리의 구조를 반복해서 묻더군요. 계속 대답해 주다가 도대체 여러 번 묻는 이유가 뭐냐고 되물었더니, 변수 이름과 트리 구조가 마음에 안 들어 고치고 싶은데 자신이 없어서 계속 물었다는 겁니다. 이런 시시콜콜한 것까지 묻고 답하는 것을 계속 반복하는 건 좋지 않아요.

 

차라리, 수정해도 되느냐, 비슷한 사례가 있느냐, 수정할 시 발생할 문제가 무엇이냐고 묻는 것이 인계자의 태도입니다. 그리고 그런 시도를 실제로 해야 하고요. 그 녀석은 저에게 본인이 생각했던 것을 구현해 놓고 퇴사하라 압박하더군요. 당연히 저는 무시하고 약속된 날짜에 퇴사했습니다. 이해될 때 까지 계속 설명하라는 것은 어이없는 일에 불과합니다.

 

당시 요구사항

 

- 변수 이름 모두 교체

- 함수 이름 모두 교체

- 소스 다섯 줄마다 주석 달기

- 디자인 패턴 모르니 구현 소스 다시 작성

- 기타 등등 해괴한 사항들.

 

3. 소스 한 줄 한 줄...

c++ 라인 하나하나를 따라가며 이해하는 건, 제일 마지막에 해야 합니다. 종종, 라인 한 줄 마다 주석을 남기는 무모한 행위를 벌이는 사람들이 목격되는데.... 하지 마... 그렇게 하지 마....

 

모 SI 업체의 20대 초반 직원이 그렇게 하는 걸 목격하고, 왜 그러느냐 물은 적이 있습니다. 직장 상사의 노하우라고 하던데 ... 와 ... 당시 저는 회사 내부와 친구들을 통해 얻은 좋은 문서들은 그 직원에게 넘겨줬고, "읽기 좋은 코드가 좋은 코드다"라는 책을 읽어보라 권했었습니다. 지금은 어떻게 소스코드 분석하는지 궁금하네요.

 

 

4. 손으로 써보기

데브피아에서 읽었던 충격적인 일입니다. 손으로 직접 c++ 소스를 종이에 적으며 분석을 하라는 꼰대가 있었답니다. 정말 한심한 짓입니다. 나이와 인격은 비례하지 않는다는 말이 있는데, 프로그래머 경력과 실력도 비례하지 않는다는 것과 일맥상통합니다. 이런 해괴한 짓은 얼른 사라져야 합니다.

 

 

마지막으로 까까모리님이 남긴 다른 사람의 코드 분석하는 방법 소개하며 글을 마칩니다.

 

 

감사합니다.