소스 분석 결과 관리하기

분명 리버스 엔지니어링 이라는 거창한 이름을 달았을 경우, 이를 정리하는 방법은 모델링이 최고라는데에는 이의를 달지 않습니다.
하지만 모델링이라는 것도 한계가 있다고 봅니다. 오히려 모델링은 OO개념에 촛점이 맞춰진 듯한 느낌이 들어 C 소스에 적용하기에는 문제가 있다고 생각됩니다. (사실 전 C 소스 작업을 하면서 로즈로 작업한 적이 없었고 로즈나 모델링 책을 봐도 거의 OO 개념의 모델링만 봐서 그런지...C와 모델링은 잘 안 어울린다는 생각이 듭니다.) 그리고 모델링이라는 것도 조금은 이해가 선행된 후, 분석한 내용을 정리를 해야 되므로 시간적으로 모델링에 빼았기는 시간이 너무 많다는 거죠. 저도 회사에서 언제나 모델링을 하고 코딩 작업을 하지만 모델링을 할 때마다 느끼는 생각이지만 왜 이런 거지 같은 노가다를 하는지 모르겠다는 생각이 듭니다.(모델링 신봉하시는 분들께는 죄송한 얘기지만....) 바쁠 경우에는 모델링 생략하고 코딩 먼저하고 나중에 모델링 문서만 대충 만드는 경우도 부지기수입니다. 분명 실제로는 모델링이 전부는 아니라는 거죠.

그리고, 리버스 앤지니어링에 대해서는 저의 생각은 이렇습니다. 소스가 있고 제대로된 makefile만 있다면, 리버스 엔지니어링은 크게 문제가 될 점은 없다고 봅니다. 디버거를 잘 사용한다면 어느정도 분석은 끝낼 수 있다고 생각됩니다. (물론 특출난 환경에서 디버거가 제공 안되거나, 디버깅이 골치아플 경우도 있겠지요...)

리버스 앤지니어링 보다는, 오히려 소스를 디버깅한 후 분석된 내용을 토대로 메모리 구조라든지, row level devic와의 연관성을 분석한 내용을 어떤 형식으로든지 정리를 해야할 필요성을 느꼈고, 동료들과 공유를 해야될 필요성이 생긴다는 것이 문제죠.

이때 과연 모델링으로만 모든 것이 커버가 안 된다는 것이 문젭니다. 특히 동료가 모델링에 대한 이해가 부족할 경우에는 더욱 그렇습니다. (물론 OO개발자들은 모델링에 대해 이해를 하겠지만 C 개발하시는 분들의 경우 모델링에 대한 이해가 없으신 분들이 많습니다.)

OO개발이 아닌 C개발하시는 분들의 경우, 엑셀을 이용해서 분석한 내용을 정리하는 경우가 많이 보이던데, 엑셀도 실은 소스 정리를 위한 용도가 아닌지라 한계가 있다는 생각입니다. 물론 워드보다는 훨씬 낫다고 봅니다. 그리고 엑셀로 내용을 정리하는 경우에도, 개발자마다 정리하는 방식이 모두들 달라서, 뭔가 체계적인 방식을 정해야 되겠다는 생각이 듭니다. 물론 세련된 형식으로요...

여기 토론의 방향은 이렇게 자신이 분석한 내용을 어떻게 체계적으로 정리된 형태로 생산을 해 내냐는 것에 맞춰 졌으면 하는 바램이 있습니다.

프로파일러에 대해 더 자세한 설명을 들을수 있을까요? 어떤건지(프로그램인지 혹은 리버스 엔지니어링의 한 방법인지) 알고 싶습니다.

그리고 전, top-down방식과 bottom-up 방식의 혼합사용을 하고 있습니다. 역변환 레벨은 항상 디스어셈블링 레벨과 맞쳐줘 있구요. 제가 하고 있는 이 방법에 대해 뭔가 더 도움될만한 조언하나 해주셨으면 합니다.