문제

어떤 버그에 대한 픽스를 두 명이서 동시에 썼다고 하자. 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 …

(출처 : http://www.developer.com/design/article.php/10925_3644656_2/Software-Quality-Metrics.htm)

그러니까, 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

(출처 : http://www.callingshotgun.net/geekery/lines-of-code-dispelling-the-myths/)

역시 검색으로 나왔던 블로그인데, 참으로 내가 하고 싶은 말을 그대로 해주었다. code size 를 줄여서 얻고자 하는 이득이 # of defects 를 줄이고자 하는 것이라면, (즉 정답에 가까운 답으로 만들고자 하는 것이라면) 그 과정이 code 의 readability 를 높이는 방향이어야 된다는 이야기다.

결론

• 애시당초 코드를 고치지 않는다면, 버그가 더 생길 가능성도 없다. (줄지도 않겠지만) 그럼에도 우리는 버그를 고쳐야 하는 운명이다.
• LOC 와 Defect density 는 선형적 상관관계가 아니다.
• LOC 보다 # of defects 에 영향을 주는 것은 Readability 이다.
• Readibility 가 좋은 코드가 # of defects 도 적은 코드일 가능성이 높다.
• LOC 를 줄여서 Fix 의 Quality 를 높이고자 한다면, 그 과정이 Readability 를 높이는 방향이어야 한다.

왜 혼자서 질문던지고 답변하는 놀이를 하고 있느냐? 라는 질문을 할 만한데, 그것은 최근에 겪은 일 때문이다. 회사 업무와 관련이 있어서 블로그에 자세히 쓰지는 못할 것 같은데, 공개해도 괜찮은 내용들로 가다듬어서 글 한 자락 더 써보려고 한다. 언제가 될지는 모르겠지만.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

소프트웨어 개발이라는 건 결국 무한히 계속되는 버그 수정이다. 아쉽게도 이 버그들은 결코, 절대, 바닥나지 않는데 그것은 현실의 불완전함에 기인한다. 음 표현이 조금 이상하다. 현실의 불완전함이라기 보다는 인간의 불완전함이 더 맞겠다. 세상은 그 자체로 완전하게 존재하고 있지 않은가! 다만 그것을 받아들이는 우리 인간이 불완전한 존재일 뿐이니까. 더 엄밀히 말하면 세상을 알아가는 우리의 인식이 완전치 못하다.

그리고 또 하나의 세계가 있다. 이건 순전히 허구속에 존재하는 세계인데, 가증스럽게도 한계가 명백한 인간들이 만든 세계다. 그것은 참 아니면 거짓이라는 흑백논리 속에 존재하며, 그 자체로는 완벽해 보이지만 허술하기 짝이 없다.

개발자들의 문제는 이 두 세계를 잇는 대서 출발한다. 불완전한 머리로 이해한 현실을 나름 완전해 보이는 논리 세계로 옮길 때, 이 두 우주의 간극에서 버그들이 튀어나온다. 그것도 끝도 없이. 그러니 이 직업을 평생 가져가기로 마음을 먹었다면 이 거대한 모순 앞에 당당히 마주설 각오부터 해야 할 것이다. 버그를 만드는 게 내 일이고 그걸 다시 고치는 게 내 일이다.

그럼 이 우주적 모순과 반복되는 일상에서 우리는 무엇을 추구해야 하는가? 그것은 통찰력이다. 하루에 천번의 정권 찌르기 연습을 하는 무도가처럼 우리는 일상의 반복에서 모종의 '득도'와도 같은 깨달음을 얻어야 한다. 그것은 작게는 함수와 클래스의 디자인에 대한 통찰력일 수도 있고, 보다 크게는 소프트웨어와 그 개발 프로세스에 대한 통찰일 수도 있다. 또한 요구사항 변경과 요동치는 현실에 대한 꿰뚫음일 수도 있다.

그럼 어떻게 해야 '득도'를 할 수 있는가? 여기에 명확히 알려진 방법 같은 건 없다. 다만 한가지 확실한 건 반복, 통찰, 성장의 과정이 행성계의 궤도들과 유사하다는 것이다. 계단형 성장이라고 봐도 비슷한데, 어느 순간에 성장을 통해 자신의 궤도를 능가해 다음 궤도를 달리게 되는 식이다. 그래서 궤도를 바꾸기 위해 우리가 첫번째로 성취해야 하는 것은 빠른 속도다. 일상의 반복들을 전보다 빠르게 해결할 수 있는 데 집중하면 구심력이 특정치를 넘어설때 성장이 일어나 다음 궤도를 돌고 있는 자신을 볼 수 있게 될 것이다.

급하게 쓰다 보니 글과 거기에 담긴 생각이 짧기 그지 없다. 딱히 결론이라고 낼 만한 것도 없지만, 그래도 일상의 반복들이 날 단련할 수 있는 기회라 믿고 오늘도 버그 잡고 스케쥴에 쪼이러 간다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.