오피스 2010 에는 문서를 Skydrive 에 저장하거나, 원노트의 경우에는 Skydrive 에 공유 원노트를 올려놓고 쓸 수 있는 기능이 있다. 다만 Windows Live 가 업데이트 되어야 쓸 수 있었던 기능인데, 이번에 나온 베타 버전을 설치하면 그것들을 쓸 수 있다. 윈도우즈 라이브 필수 패키지 베타는 여기에서 다운로드 받아 설치하면 된다.
Office 2010 과 윈도우즈 라이브 필수 패키지 를 설치했으면, 시작-모든 프로그램-Windows Live-Windows Live Sync Beta 를 실행한다.
왼쪽 두번째에 보이는 Microsoft Office 를 클릭해서 Syncing turned on 으로 바꾸면 된다. 그 후 원노트를 실행하면, Web 에 싱크된 노트북을 사용하겠냐고 묻는다.
원노트 뿐만 아니라, 워드나 엑셀등에서도 문서를 바로 Skydrive 에 저장하는 기능이 활성화 된다.
어떤 버그에 대한 픽스를 두 명이서 동시에 썼다고 하자. A 의 것은 약 50 줄 정도를 수정했다. 반면 B 의 것은 약 200 줄 정도를 수정했다. LOC (Line Of Change)에 근거해서 볼 때, 누구의 픽스가 더 좋은 픽스일까?
생각
질문을 정제하기 위해 몇가지 기준들을 정해보자. 더 좋은 픽스란 무엇일까? 픽스에 포함되 bug 가 더 적은 것이 좋은 픽스라고 할 수 있겠다. 그럼 위 질문은 다시 말해
누구의 픽스가 더 적은 Defects(=bug) 를 가지고 있을까?
이걸 판단하려면, LOC 사이즈와 Change 안에 있는 defect 의 수에는 상관 관계가 있을까? 라는 질문을 먼저 해야 될 것 같다. 여기에 대해서는 예전에 읽은 Best Kept Secrest of Peer code review에서 그 영향력이 매우 적거나 증명된 바가 없다고 했다.
잠깐, 너무 빨리 답으로 뛰어들었다. 질문을 좀 더 정제해보자. LOC 를 어떻게 측정할 것인가? 단순한 Diff 의 크기로 비교할 것인가? 아니면 그 복잡도의 weight 를 고려한 값으로 계산할 것인가? 아니면 기계어로 바꾸어 놓고 그 차이를 비교해 볼 것인가? (LOC 를 셈하는 근원은 Assembly language 로 프로그래밍하던 시대에 기원하긴 한다.)
글쎄다. 이건 모르겠다. LOC 를 규정하는 방법은 너무 다양할 것 같다. 그럼 동일한 조건 하에서 비교한 실험등은 없을까? LOC metrics 로 인한 영향력을 없애려면, 동일한 프로젝트에서 측정된 연구 결과가 있으면 딱 좋을 것 같은데…
아 모르겠다. 논문을 쓸 것도 아니고 그냥 웹 검색을 하자. (라기 보다 논문을 써본적도 없고, 어떻게 쓰는 건지도 모른다.) 잽싸게 검색을 해보니 어쨋든 아주 재밌는 연구 결과가 하나 있다. 아니 있었나 보다.
…. Recent studies show a curvilinear relationship between defect rate and executable LOC. Defect density, or defects per KLOC, appears to decrease with program size and then increase again as program modules become very large (see Figure 3.1). Curiously, this result suggests that there may be an optimum program size leading to a lowest defect rate—depending, of course, on programming language, project size, product type, and computing environment …
그러니까, Defect density 가 최소가 되는 최적의 LOC 값이 존재한다는 이야기다. 물론 이 말을 곧이 곧대로 믿기에는 한계가 있다. 왜냐하면 LOC 와 # Defects 의 영향력을 무의미한 것으로 만들어버릴 정도로 이 결과는 외부 요소에 의해 크게 좌지우지 되기 때문이다. 어쨋거나 여기서 얻을 수 있는 것은 LOC 와 Defects Density 사이에는 선형적인 상관관계가 없다 정도 되겠다.
원점으로 돌아와서 다시 생각해보자. 방금 봤던 내용들은 머릿속 한 켠에 정리해두고 잊어버리자. 최초의 질문으로 돌아가서, 만약 A 와 B 의 픽스 둘 다 훌륭히 버그를 고쳤다면 우리는 둘 중 누구 것을 골라야 될까?
Occam’s razor 원칙에 따르자면, 일반적으로 더 단순한 것이 정답일 경우가 많단다. 그럼 다시 이렇게 물어보자. A 의 50 줄 짜리 fix 가 더 단순한 것일까? B 의 200 줄짜리 fix 가 더 단순한 것일까?
이렇게 질문을 바꾸고 나니, 내가 왜 이렇게 혼란스러워 했는지 알 것 같다. LOC 만으로는 Fix 의 단순함 또는 복잡함 정도를 나타낼 수 없기 때문이다. 만약 LOC 가 작은 픽스가 더 단순하다 라는 명제를 지지하려면, 다음과 같은 가설이 있어야 한다.
Reducing the code involved in a task will only help reduce the bug count IF THE PROCESS MAKES THE CODE MORE READABLE
역시 검색으로 나왔던 블로그인데, 참으로 내가 하고 싶은 말을 그대로 해주었다. code size 를 줄여서 얻고자 하는 이득이 # of defects 를 줄이고자 하는 것이라면, (즉 정답에 가까운 답으로 만들고자 하는 것이라면) 그 과정이 code 의 readability 를 높이는 방향이어야 된다는 이야기다.
결론
애시당초 코드를 고치지 않는다면, 버그가 더 생길 가능성도 없다. (줄지도 않겠지만) 그럼에도 우리는 버그를 고쳐야 하는 운명이다.
LOC 와 Defect density 는 선형적 상관관계가 아니다.
LOC 보다 # of defects 에 영향을 주는 것은 Readability 이다.
Readibility 가 좋은 코드가 # of defects 도 적은 코드일 가능성이 높다.
LOC 를 줄여서 Fix 의 Quality 를 높이고자 한다면, 그 과정이 Readability 를 높이는 방향이어야 한다.
왜 혼자서 질문던지고 답변하는 놀이를 하고 있느냐? 라는 질문을 할 만한데, 그것은 최근에 겪은 일 때문이다. 회사 업무와 관련이 있어서 블로그에 자세히 쓰지는 못할 것 같은데, 공개해도 괜찮은 내용들로 가다듬어서 글 한 자락 더 써보려고 한다. 언제가 될지는 모르겠지만.
책을 구입한지는 꽤 오래 전이었지만, 책상 구석에 놔뒀다 얼마 전부터 읽기 시작해서 이제 다 봤다. 처음 기대했던 내용은 생활 속에서 도움이 될만한 법 상식들이었으나, 책 내용은 그것과는 다른 몹시 철학적인 주제로 시작한다.
기계적인 법치주의와 영화 로보캅
도둑의 아들은 아버지를 신고해야 옳은가?
살인을 통해 ‘살인하지 말라’는 계명을 전하는 모순
정의란 ‘강자의 이익’?
권력의 법, 민중의 법
노예 해방법 과 지도자 링컨에 관한 오해
계급간의 이익추구가 낳은 삼권분립
마르크스와 부르주아 법
악법도 법?
등 법에 대한 다양한 철학적 주제를 가지고 재밌게 얘기를 풀어간다. 특히 소크라테스 이야기는 정말 흥미로웠는데, 소크라테스가 왜 70 살이 나 되어서 사형을 선고 받고 독을 마셔야만 했는지에 대해 당시의 정치적 상황과 함께 알려준다.
이상과 현실 사이에서 법이 가질 수 밖에 없는 한계. 그 가운데서 최선의 것을 찾기 위해서는 끊임없는 법적 투쟁이 있었다는 이야기도 인상 깊다.
늘 컴퓨터관련 책들만 보다가 오랜만에 신선한 글을 읽었더니, 그 개운함이 머릿속에 남아 있다. 예전에 과학철학 수업을 들을 때 이런 느낌을 받았었는데, 그 이후 철학관련 서적들을 몇 권 사서 혼자 읽어보려다 낭패를 봤던 것 같다. 아무튼 법에 대한 시야를 넓혀주는 책이다. 추천.
