Broken Code (window31)

이 책은 SVN에 대해 다룹니다. SVN 에 대해 꽤나 상세하고 쉽게 설명하고 있기 때문에
큰 프로젝트를 하는 여러 개발자들에게 평가가 참 좋은 편이죠. 그 책 내용 일부중 참 마음에
드는 부분이 있어서 긁어왔습니다. 필자는 SVN의 필요성을 강조하려고 작성한 내용이겠지만,
그 필요성에 대한 예제들이 참 가슴에 와닿고, 전부 진짜 있었던 이야기들인 것 처럼 아주
생생합니다 :) 

아마도 이 작가분은 소스 프로젝트 관리를 엿같이 하고 퇴사한 전임자 때문에 고생한 사람들에
대한 얘기를 여기저기서 많이 들은게 아닌가 하는 생각이 듭니다. 어쨌든 직접 한번 읽어보세요.
특히 강추하는 부분입니다 (SVN 을 단지 WinMerge 등으로만 이용하고 Trac 이나 심볼 서버
등과의 작업을 병행하지 않으신 분들은 책을 통채로 사서 읽어보시는 것도 추천합니다)



일하기 편한 환경 만들기
("윈도우 프로젝트 필수 유틸리티" 中)
이재홍 (pyrasis) http://www.pyrasis.com


어떤 소프트웨어 개발팀이 있습니다. 물론 전담 테스트 팀도 갖추고 있습니다. 이 개발팀의 환경은 이렇습니다. 소스 코드는 개발자 각자 PC에서 알아서 관리하고, 고객에게 판매되는 제품도 개발자 PC에서 직접 빌드합니다. 그리고 빌드된 exe와 dll 파일을 취합하여 FTP 서버에 업로드합니다. 이제 테스트 팀은 FTP 서버에 접속하여 빌드된 파일을 받아들고 테스트를 시작합니다. 별 문제없이 돌아갈듯한 환경입니다. 모든 구성원이 정신 바짝 차려서 일한다면 말이죠.

이런 환경에서 일을 하다보니 여러가지 문제점이 보이기 시작합니다. 개발자는 개발을 하면서 소스 코드가 든 폴더를 날짜별로 복사해가며 관리를 하기 시작합니다. 그래도 이런 사람은 양반입니다. 어떤 개발자는 그냥 귀찮아서 소스 코드가 든 폴더 하나로 개발을 진행합니다.

테스트 팀은 개발팀에서 전달받은 파일로 테스트를 합니다. 마침내 여러가지 버그를 발견하였고, 버그에 대한 내용을 종합하여 엑셀로 작성한 뒤 개발팀에게 넘겨줍니다. 하지만 정해진 전달 경로가 없기 때문에 메일로 보내기도 하고, 메신저로 보내기도 합니다. 더 나아가서 버그 내용을 말로 전달하고 끝낼 때도 있습니다.

개발 업무에 쫓기는 개발자는 버그 내용을 기록한 엑셀 파일을 자신의 PC 어딘가에 방치한 채 그냥 넘어가기도 하고, 말로 전해들은 버그 내용은 쉽게 잊어버립니다. 이런 일이 반복되면서 제품의 버그는 점점 늘어나기 시작합니다. 결국에는 모든 것을 뒤엎고 새로 개발하자는 말이 나오기도 합니다. 테스트 팀 입장에서는 버그 보고를 해도 함흥차사가 되어버리고, 테스트를 제대로 안해서 제품 질이 떨어졌다는 비난만 받게 되니 일할 의욕을 잃게 됩니다.

그래도 이런 저런 고생 끝에 제품이 출시되었습니다. 이제 기술 지원 파트와 고객 지원 파트를 통해서 여러가지 버그가 보고되기 시작합니다. 그래서 개발팀은 버그를 수정하기 위해 담당자가 누구인지 찾게 되었는데, 버그가 발생한 파일의 담당자는 이미 퇴사를 하여 소스 코드가 다른 사람에게 인수인계된 상태였습니다. 물론 새 담당자가 버그를 처리하면 됩니다. 하지만 문제는 이것이 아니었습니다. 퇴사한 개발자는 소스 코드가 든 폴더 하나로 개발을 진행하던 사람이었고, 새 담당자도 이 소스 코드 폴더 하나만 달랑 받은 상태였습니다. 이미 소스 코드의 구조는 엄청나게 바뀌어 있었고, 하위 호환성도 고려되지 않은 채 개발되었기 때문에 버그를 고치려면 구 버전을 다시 만들어야 하는 상황이 되어버린것입니다.

인수인계 과정에서 소스 코드가 분실되는 경우도 비일비재 합니다. 새 담당자에게 소스 코드를 넘겨 줄 때 모두 넘겨주지 않고 실수로 한 두개 빼먹은 상태로 넘겨주기도 합니다. 사고가 터졌을 때에는 퇴사자의 PC는 이미 회수되어 소스 코드를 찾을 수 없을 때도 있습니다.

빌드된 파일 자체도 관리가 되지 않아 FTP 서버에 보관된 파일은 언제나 최신 버전뿐입니다. 버그가 보고되어도 해당 버전의 파일이 없으니 버그를 재현하는 것도 힘들어집니다.(고객 PC에서 해당 파일을 가져오는 수 밖에 없습니다.) 물론 소스 코드 관리가 제대로 되지 않으니 해당 버전을 빌드해서 만들어내는 것도 쉬운일이 아닙니다. 게다가 심볼(PDB) 파일도 따로 보관을 하지 않는 경우가 많아서 덤프 파일을 입수하여도 분석이 힘들때가 많습니다. 정말 디스어셈블된 코드를 보고 버그를 찾는 것도 한계가 있습니다. 고객에게 판매되는 제품을 개발자 각자가 빌드하다 보니 바이러스에 감염된 파일이 제품에 포함되어 배포되는 사고가 발생하기도 합니다. 정말 믿기지 않는 상황들이지만 필자도 겪은 일들이고, 지금도 어디선가 이러한 일들이 벌어지고 있을것입니다.

이제 엉뚱한 곳에 시간을 빼앗기지 않고 개발에만 집중할 수 있는 일하기 편한 환경을 구축한 개발팀의 일하는 모습을 들여다보겠습니다. 일하기 편한 환경을 구축한 이 개발팀은 소스 코드를 Subversion으로 관리합니다. 그리고 각 개발자는 TortoiseSVN을 사용하여 소스 코드를 체크아웃 및 업데이트하고 수정된 내용을 커밋 합니다. 고객에게 판매되는 제품은 빌드 서버에서 빌드합니다. 파일의 버전도 개발자가 올리지 않고 빌드 서버가 알아서 올려줍니다. 빌드 서버는 빌드된 파일을 버전 별로 차곡 차곡 모아둡니다. 물론 심볼(PDB) 파일도 심볼 서버 형식으로 보관을 해줍니다.

버그 보고는 Trac으로 받습니다. 테스트 팀은 버그를 발견하면 해당 프로젝트의 Trac 사이트에 접속하여 버그에 대한 내용을 자세히 기록한 티켓을 생성합니다. 개발팀은 버그 티켓을 확인하여 버그를 수정한 뒤 버그를 수정했다고 답글을 달아놓습니다. 다음날이 되면 자동빌드가 되어 버그가 수정된 새 버전이 올라와 있을것입니다. (급할때에는 강제 빌드 명령으로 즉시 빌드를 할 수 있습니다.) 테스트 팀은 빌드 서버에 접속하여 버그가 수정된 새 버전을 받아 테스트 한 뒤 버그가 수정된 것을 확인하고 해당 티켓을 닫습니다.

개발자는 버그 보고를 티켓으로만 받기 때문에 Trac 사이트만 잘 확인하면 버그 내용에 대해서 잊어버리고 넘어갈 일은 없습니다. 테스트 팀 또한 버그가 수정되면 버그가 수정되었다는 답글이 달리고, 빌드 서버에서 새 버전을 바로 받아 볼 수 있기 때문에 테스트에만 전념할 수 있습니다.

인수인계 과정에서 생기는 각종 문제점들도 이 개발팀에서는 다른 세상 이야기일 뿐입니다. 모든 소스 코드의 내용과 변경 사항에 대한 이력은 모두 Subversion으로 관리되기 때문에 따로 소스 코드를 넘겨줄 필요가 없습니다. 단지 담당하고 있는 프로젝트의 저장소 URL만 알려주면 끝입니다. 이전 버전에서 버그가 발생하더라도 Subversion을 이용하면 해당 버전의 소스 코드를 그대로 가져 올 수 있습니다. 또한 모든 소스 코드가 Subversion 서버에서 관리되기 때문에 특정 소스 코드를 분실하는 일도 발생하지 않습니다.

빌드된 파일도 버전별로 보관을 하기 때문에 버그가 보고되면 해당 버전을 빌드 서버에서 받아 곧바로 재현해 볼 수 있습니다. 그리고 자동빌드를 하면서 Subversion 저장소 정보를 심볼(PDB) 파일에 기록해놓았기 때문에, 덤프 파일을 열면 디스어셈블된 코드 대신 Subversion 저장소에서 소스 코드를 가져와 에러가 발생한 부분을 표시해줍니다. 또한 심볼 서버 형태로 심볼(PDB) 파일을 보관하므로 개발자가 따로 심볼(PDB) 파일을 보관할 필요가 없습니다.

빌드 서버에서 자동빌드를 하기 때문에 개발자들은 제품을 빌드하고 테스트 팀에 넘겨줄 때 소요되는 시간을 절약할 수 있습니다. 또한 제품의 모든 파일은 빌드 서버에서 빌드되므로 빌드 서버만 잘 관리하면 바이러스에 감염된 파일이 배포되는 일은 발생하지 않습니다.

여러분들은 어떤 개발팀에서 일하고 싶습니까?

어디서 퍼왔는지는 모르겠지만, 대략 이메일주소와 머 그런게 있으므로 별 문제 없으리라 봅니다.
사실 제가 가장 속상해 하는 것이 "개발자는 폐인에 옷차림도 별로 신경쓰지 않고 잘 씻지 않으며
항상 수염도 더부룩하게 기른 채 너덜너덜한 체크무늬 난방을 입고 다닌다" 라는 인식입니다.

특히 이 만화에서는 그 많은 개발자 중 보안 개발자를 비유했다는 모습에 더욱 안스럽습니다.
왜 개발자는 항상 대부분 그렇겠지 하는 고정관념에 매여 있을까요? 여기서 추가로 온라인 게임
개발 영화인 "후아유"에서 역시 게임개발자를 더욱 폐인같은 모습으로 그리며 프로그래머가 뭐하는
사람인지 잘 모르던 사람들에게조차 편협한 이미지를 만들어 주는데 동조를 합니다. 주인공
조승우는 집에도 잘 안가고 잘 안 씻고 지저분한 폐인의 이미지로 묘사되죠. 이런식으로 영화에서
조차 표현될 정도로 개발자의 지저분한 이미지는 사람들의 머릿속 깊은 곳에 자리잡고 있습니다.

보안 개발자 얘기가 나와서 말인데, 영화나 만화에서 해커를 묘사할 때도 그렇습니다. 항상 해커는
돈이나 도박밖에 모르는 음험한 사람이거나 배불뚝이 같은 형상에 사교성이 부족한 모습으로
묘사됩니다. 또, 대인기피증 증상이 있으며 일상생활에서도 항상 비정상적인 사고방식으로
일관합니다. 제가 요즘 즐겨보는 미드 프리즌 브레이크 시즌4 에 나오는 해커 Roland도 유사한
모습으로 등장하죠. 사실 일단 얼굴부터가 마음에 안듭니다 -_- 행동거지를 다 제치고서라도
얼굴에서 저런 느낌을 풍겨주는 캐릭터를 캐스팅 했다는 것 자체가 해커에 대한 편협한 인식을
살펴볼 수 있습니다. 정말 안타깝습니다.




사실 요즘 개발자나 해커의 경우 그렇지 않은 사람이 더 많음에도 불구하고, 과거에 그런 이미지로
시작했다는 것 때문에, 그 인식이 쉽게 바뀌고 있지 않습니다. 정말 사람들의 인식이라는 것은
무서운 것 같습니다. 또 그 인식이 무섭다는 생각이 드는 경우는 대부분 "인식"이라기보다는
"낙인"에 가까운 결과를 안겨주기 때문입니다. 긍정적인 인식이라면 무섭다는 생각이나 바꿔야
겠다는 생각이 굳이 들지를 않겠죠.

락 음악의 경우도 대부분의 사람들의 가죽잠바 혹은 가죽쫄바지에 머리는 허리 근처까지 기르고
체인을 주렁주렁 다는 이미지를 생각하는데, 사실 그건 80년대 헤비메탈의 이미지일 뿐입니다.
요즘의 락음악은 그 시절 뿌리가 여러 갈래로 나뉘고 다시 섞이고 하는 작업이 반복되며 이제
그 파생의 근거지조차 짐작하기 힘들 정도로 퓨전의 시대입니다. 따라서 저렇게 가죽쫄바지에
머리를 겁나 길러대는 트렌드는 잘 사용하지 않죠. 요즘 하드코어나 이모코어쪽은 오히려 머리가
짧은 경우가 많으며 힙합처럼 바지는 헐렁하게 입고 gothic 등의 이미지도 별로 내세우지 않습니다.
하지만 아직도 사람들은 락 음악 하면 체인에 가죽바지에 긴머리...이런걸 상상합니다. 인식이
바뀌는 것은 정말 어려운 것 같습니다.

그래서 저는 가급적 개발자라는 이미지를 풍기지 않도록 하고 다니려고 애를 씁니다.
머 제가 지저분한 넘이라 잘 씻지 않는다 해도 남들 눈엔 그렇게 보이지 않으려고 노력하며
하고다니는것도 어느정도 신경을 쓰려고 합니다. 머 그렇다보면 너는 ㅅㅂ 실력도 없는게
껍데기에만 신경쓰냐 라고 생각할 수도 있으므로 내부적인 부분도 꿀리지 않으려고 합니다만
내공과 외공을 같이 연마하는건 정말 힘들죠 ㅠ ㅠ 그래도 해야죠 그런 인식이 싫다면요.

제품이나 물건을 바꾸는 건 쉽습니다. 하지만 사람들의 머릿속에 들어있는건 바꾸기 어렵습니다.
그리고 그 사람들의 머릿속에 들어가 있는 개발자에 대한 이미지는 우리가 만든겁니다. 그러므로
우리가 다시 바꿔야겠죠. 그게 싫다면 아 ㅅㅂ 왜 다들 그렇다고 생각하는거야? 라고 말로만
말하지 말고 스스로 실천해야 한다고 생각합니다. 


window31. 2008년 11월.
 

아 할일은 많은데 머릿속은 잡생각이 가득하여 집중은 되지 않고 해서 졸음이나 내보낼 겸 쵸큼
여기저기 돌아다니다가 재밌는걸 발견하여 올립니다 (사실은 사진 민망해서 빨리 다음 페이지로
넘기려고 ;; )

AVG 에서 이번 V3에서와 같은 오진 사고를 저질렀군요.

user32.dll 을 Trojan Horses PSW.Banker4.APSA 또는 Generic9TBN 으로 오진하여
파일을 삭제해버립니다. 따라서 리붓하면 부팅이 제대로 되지 않겠죠 lol

이번에는 SP3 문제도 아닌 SP2 에서의 문제이므로 머, 일부 몇몇 SP2일지도 모르겠다만
어쨌든 제대로 테스트 안한건 빼도 박도 못하겠네요.

보안 프로그램들... 백신이든 다른 솔루션이든 엔진 설계시에 native process와
system dll 은 삭제하기 전에 한번 더 체크하는 루틴이 필수적이라고 생각합니다.
그래야 오진을 내더라도, 최소한 지우지는 않죠.

그리고 이번 얘기와 사실 별개지만, 요즘 사실 오진 문제는 V3나 AVG가
재수없어서 잇슈가 된거지 그외 대부분의 백신들 역시 무수히 많은 오진을 내고 있습니다.

그 상당히 많은 경우의 수가 바로 프로텍터/패커를 사용했을 경우인데,
시그너쳐 추출 툴이 예전에 프로텍터가 다양하지 않았던 시절에 제작한 것이라면
추출 알고리즘에 문제가 있을 수도 있으므로 그것에 대한 개량도 필요하다고 봅니다.
그래야 패킹만 하면 백신에 잡혀버리는 사태를 쵸큼이라도 줄일 수 있을테니까요.

또 테스트 환경도 다시 갖춰야 한다고 봅니다. 것이고요, 예를 들어 eXPressor, EXECryptor,
DingBoy 등 머 이딴 쵸큼 희귀한 패커로 된 바이러스 샘플에 대한 시그너쳐를 추출했을 때,
몇몇 샘플 애플리케이션을 제작하여 엔진 패치 전에 해당 샘플을 각 패커로 패킹해보고 혹시
그것을 오진하여 잡지 않는지 그런 테스트 또한 필요하다고 생각합니다.

어쨌든 패커가 다양해져서 바이너리 추출에 대한 애로점이 커지고, 저기서 본 코드가
여기도 있고 쟤 소스가 내 소스고 내 소스가 쟤 소스인 즉, 인간들이 짜는 코드가
포화 상태에 이르러 unique한 값을 찾기 힘들게 된 지금이라도 그런 안전장치가 없는 플그램은
이런 부분에 대해 다시 한번 체크하는 계기가 되었으면 합니다.

머 즉 결론은,,,,V3나 AVG에 대해 머라고 너무 하지 말자 ;; 라는 얘기...저도 무수한 사고
많이 쳐봤습니다 :$/  무조건 면죄부를 주자는 얘기는 아니지만 사실 사고 한두번 안쳐본
사람이 어디있나요... 동종업계에서 다들 사정 뻔히 잘 아시니 적어도 우리라도 이해하는 분위기를 ^^;


AVG 오진에 관한 글
http://securityandthe.net/2008/11/10/avg-virus-scanner-removes-critical-windows-file/

http://smokeys.wordpress.com/2008/11/09/severe-problems-with-winxp-after-avg-antivirus-marked-user32dll-as-trojan-horse-psw-banker4/


시스템 날라가서 괴로워하는 꼬꼼화
http://kristofmattei.be/2008/11/09/avg-8-update-marks-user32dll-as-false-positive-on-xp-sp2/


window31
2008년 11월.

밴드 공연을 할 때나 볼 때나, 한번씩 그런 때가 있습니다. 관객이 적으면 아무래도 무대 위에선
상대적으로 신이 좀 덜 나기 때문에 "아~ 왤케 반응이 없으세요~ 환호좀 해 주세요~" 라고 보컬이
찌질하게 읊어대는 경우죠. 아이러니 한 것은 무대 위에서 공연자들이 저런 "호소"를 하면 할수록
관객들은 더욱더 반응이 없다는 것입니다.

세미나나 강연자의 발표 때 역시 비슷한 상황이 있습니다. 강연자 중에서는 발표를 하면서 유독
사람들에게 질문아닌 질문을 해가며 (ex) 여기서 이 구조체는 뭐죠? 누구 말씀해보세요!" ) 청중의
반응을 무척이나 신경 쓰는 사람들이 있는데, 그 때 역시 듣는 사람이 별 반응이 없다면 위에서
얘기한 밴드처럼 "아? 대답이 아무도 없으시네" 하는 태도를 보인다는 겁니다. 비슷한 상황이죠?

저는 개인적으로 두 경우 모두 "너는 앞으로 공연을 하지마라" & "넌 앞으로 세미나 하지마라"
라고 말해주고 싶습니다. 공연을 보러 온 사람들이나 세미나를 들으러 온 사람들은 무대위의
사람을 위해서 이자리에 참석해 준 것이 아니고 현재 무대 위의 사람이 관객을 위해 선 것입니다.
즉 관객이 있기에 발표자가 있는거지, 관객을 발표자의 부속품 쯤으로 생각하는 것은
거대한 착각이라는 얘기입니다.

저는 이것이 공연과 세미나 공통점이라고 생각합니다. 즉 앞에 나선 자는 관객을 무시하면
안됩니다. 혹은 무시하는 듯한 질문이나 발언조차도 삼가해야 된다고 봅니다. 무대 위에서
기껏 보여준다는 모습이 "이건 뭐죠? 아 왜 반응이 없어요?" 등의 꼬라지는 정말 피해야 할
행동입니다. 관객은 그걸 몰라서 대답을 안하는게 아니고 발표자의 행태가 별볼일 없기
때문입니다. 또 이렇게 생각하는 분들도 상당수 됩니다. "아 ㅅㅂ 짜증나 그냥 계속
설명이나 하지 시간 때우려고 하는건가"

무대의 책임을 관객에게 넘기는 것은 발표자에게 있어 노상방뇨와 같은 수준의 실례라고
생각합니다. 다시한번 강조하지만 "그들"이 있기에 발표자가 있는거지, 발표자를 위해
관객들이 모여준게 아닙니다.


window31. 2008년 11월

한국 소프트웨어 커뮤니티 연합 (SCA) 에서 이번에 대규모 컨퍼런스를 합니다.
소속 커뮤니티에서는 각 분야의 주제로 발표를 하고, 참가자들은 뷔페 식으로
자기가 원하는 세미나를 이것저것 들을 수 있는데요,

거기서 저는 디버그랩쪽 강사로 참여하게 되었습니다.

발표 내용은 아직은 미정이라 정확히는 말씀드릴 내용이 없지만
(비공개라는 얘기가 아니고 아직 정해진 게 없다는 ;; )
리버스 엔지니어링 관련 내용을 요청받았으므로 아마 관련 주제가 될 것 같습니다.

윈도우 쪼물딱 거리기로 유명한 드라이버 개발자 somma님께서도 발표를 하시네요 ^^;

보시는 분 실망시키지 않아야 할텐데,,, 암튼 이것저것 연구해보도록 하겠습니다 :)

날짜 : 2008/11/15
장소 : 숭실대
참가비 : 무료

참가신청 : http://www.onoffmix.com/e/technobabbler/400
SCA 2008 Festival :http://www.scakorea.org/2008festival
DebugLab : http://www.debuglab.com/