어떤 버그에 대한 픽스를 두 명이서 동시에 썼다고 하자. 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 를 높이는 방향이어야 한다.
왜 혼자서 질문던지고 답변하는 놀이를 하고 있느냐? 라는 질문을 할 만한데, 그것은 최근에 겪은 일 때문이다. 회사 업무와 관련이 있어서 블로그에 자세히 쓰지는 못할 것 같은데, 공개해도 괜찮은 내용들로 가다듬어서 글 한 자락 더 써보려고 한다. 언제가 될지는 모르겠지만.
◇ SW융합 수요창출 = 현재 국산화율이 낮은 임베디드SW를 육성하기 위해 ‘제조-시스템반도체-임베디드SW’ 기업간 연계를 강화하고, 국방 R&BD를 민수용 임베디드SW의 Test-bed로 활용하여 현재의 1~15%의 수준에 불과한 임베디드SW 국산화율 제고할 계획이다
그런데 정말 소프트웨어에서 국산화율이 중요할까 하는 생각이 들어 글을 쓰게 되었다.
제조업은 비록 순수익이 낮지만 거대한 매출 그리고 관련 산업들의 일자리 창출 효과가 뛰어나기 때문에 국산화율이 중요하다. 하지만 소프트웨어 시장은 그 생리가 다르다. 이 곳에서는 1등이 시장을 독식하다시피 하기 때문에 -다른 말로 하자면 고객들의 이동성이 무척 높기 때문에- 시장을 장악하지 못할 바에야 그냥 다른 전략을 생각하는 게 보다 현명할 것이다.
그러니까 국산화보다 중요한 건 국산/외산에 상관없이 합리적인 본바탕 위에서 어떻게 수익을 창출할까에 집중해야 한다. OS 인프라는 이미 기존에 나와 있는 걸로도 충분하다. 문제는 어플리케이션을 활성화 시키는데 투자해주는 것이고, 그것이 만약 특정 기업을 지원하게 되어 중립이어야 할 정부의 입장이 애매해진다면, 합리적인 본바탕을 까는 데 충실하면 된다. 지금 눈을 돌려 시장을 보면 어떤 회사가 애플리케이션 활성화를 가로 막고 있는지 볼 수 있을 것이다.
뭐 어쨌든. 아이폰 충격이 MB의 후두부도 강타했나 보다. 닌텐도 DS 보고 우리는 왜 이런 거 못 만드나 소리를 했을 때만 해도, 아 그 분이 NDS 하드웨어를 말씀하시는 건가 보다 하고 넘어갔다. 그런데 이번엔 굴지의 핸드폰 제조업체가 있음에도 왜 아이폰을 못 만드나 고민하시다 답을 찾으셨나 보다. 아 삼성 핸폰엔 아이폰 OS 가 안 올라가서 그랬구나! 하고. 그리곤 답을 내놓으신 게다. 에휴
업무상 의무적으로 만들어야 하는 프로그램은 아닌데, 자신의 업무를 보조하기 위해 만들어 쓰는 프로그램으로 어떤 것이 있습니까?
업무 외로 자신의 삶을 위해 프로그래밍해 쓰는 것이 있다면?
올해 들어 자신을 위해 만든 프로그램이 몇 가지인가요?
자신이 가장 가치를 느끼는(혹은 느꼈던) 자작 프로그램을 보여주세요.
자신이 직접 사용자의 역할을 해본 프로그래머들은 단순함의 가치를 알고 있습니다. 그 사람들은 어떤 소프트웨어가 진정한 가치를 주는지 몸으로 알고 있습니다. 다른 프로그래머들이 1000줄에서 얻을 가치를 이 사람들은 10줄에서 얻어 냅니다. (하지만 계속 뭔가 자기를 위해 만들어 내지만 완성한 것도 드물고, 또 1년 이상 개선시켜 가며 써본 것이 하나도 없는 프로그래머라면 이야기가 다릅니다.)
나는 나를 위한 프로그래밍을 해본 적이 있던가? 내가 쓰기 위해 만들어본 프로그램은? 프로젝트가 잠시 소강상태를 맞이하고 있는 요즘, 딱히 할 일이 없어 빈둥거리며 시간을 보내고 있다. 프로그램을 만드는 방법은 알지만, 왜 만들어야 하는지 몸으로 배우지 못했다. 소프트웨어가 사람을 어떻게 이롭게 하는지 바닥부터 차근차근 생각해 볼 일이다.
소프트웨어 개발이라는 건 결국 무한히 계속되는 버그 수정이다. 아쉽게도 이 버그들은 결코, 절대, 바닥나지 않는데 그것은 현실의 불완전함에 기인한다. 음 표현이 조금 이상하다. 현실의 불완전함이라기 보다는 인간의 불완전함이 더 맞겠다. 세상은 그 자체로 완전하게 존재하고 있지 않은가! 다만 그것을 받아들이는 우리 인간이 불완전한 존재일 뿐이니까. 더 엄밀히 말하면 세상을 알아가는 우리의 인식이 완전치 못하다.
그리고 또 하나의 세계가 있다. 이건 순전히 허구속에 존재하는 세계인데, 가증스럽게도 한계가 명백한 인간들이 만든 세계다. 그것은 참 아니면 거짓이라는 흑백논리 속에 존재하며, 그 자체로는 완벽해 보이지만 허술하기 짝이 없다.
개발자들의 문제는 이 두 세계를 잇는 대서 출발한다. 불완전한 머리로 이해한 현실을 나름 완전해 보이는 논리 세계로 옮길 때, 이 두 우주의 간극에서 버그들이 튀어나온다. 그것도 끝도 없이. 그러니 이 직업을 평생 가져가기로 마음을 먹었다면 이 거대한 모순 앞에 당당히 마주설 각오부터 해야 할 것이다. 버그를 만드는 게 내 일이고 그걸 다시 고치는 게 내 일이다.
그럼 이 우주적 모순과 반복되는 일상에서 우리는 무엇을 추구해야 하는가? 그것은 통찰력이다. 하루에 천번의 정권 찌르기 연습을 하는 무도가처럼 우리는 일상의 반복에서 모종의 '득도'와도 같은 깨달음을 얻어야 한다. 그것은 작게는 함수와 클래스의 디자인에 대한 통찰력일 수도 있고, 보다 크게는 소프트웨어와 그 개발 프로세스에 대한 통찰일 수도 있다. 또한 요구사항 변경과 요동치는 현실에 대한 꿰뚫음일 수도 있다.
그럼 어떻게 해야 '득도'를 할 수 있는가? 여기에 명확히 알려진 방법 같은 건 없다. 다만 한가지 확실한 건 반복, 통찰, 성장의 과정이 행성계의 궤도들과 유사하다는 것이다. 계단형 성장이라고 봐도 비슷한데, 어느 순간에 성장을 통해 자신의 궤도를 능가해 다음 궤도를 달리게 되는 식이다. 그래서 궤도를 바꾸기 위해 우리가 첫번째로 성취해야 하는 것은 빠른 속도다. 일상의 반복들을 전보다 빠르게 해결할 수 있는 데 집중하면 구심력이 특정치를 넘어설때 성장이 일어나 다음 궤도를 돌고 있는 자신을 볼 수 있게 될 것이다.
급하게 쓰다 보니 글과 거기에 담긴 생각이 짧기 그지 없다. 딱히 결론이라고 낼 만한 것도 없지만, 그래도 일상의 반복들이 날 단련할 수 있는 기회라 믿고 오늘도 버그 잡고 스케쥴에 쪼이러 간다.
출장을 갔다오는 바람에 뒷북이긴 합니다만, 제가 쓰고 있는 블로그 툴이기도 한 텍스트 큐브의 개발사 TNC 가 구글에 합병되었다네요. 멋집니다. 구글 한국 지사의 합병이긴 하지만 더 넓은 시장으로 나아갈 기반이 닦여졌다는 데에 의의가 있습니다. 한국산 서비스가 세계에서도 통한다는 걸 앞으로 보여줬으면 좋겠습니다. TNC 의 향후 발전 기대됩니다.
한겨레에 올라온 기사가 국내 엔지니어 처우 논란에 다시 불을 지피네요. 이런 논의가 더욱 활발하게 이루어져야 된다고 봅니다. 왜냐하면 이건 벌써 엔지니어 개인의 문제를 넘어섰기 때문이지요. 자기에게 주어진 일을 제 때 못해 야근을 하게 되면 그것은 개인의 문제겠지만, 지금 논의되는 IT 개발자들의 야근은 그네들에겐 선택권 한번 주어지지 못한 채 결정된다는 점에서 사회적인 접근이 필요하다고 봅니다.
예전 모 SI 업체에서 일했던 기억을 떠올리지 않을 수 없네요. 1 년 반 밖에 일하지 않았지만 그 때 고생했던 기억은 평생 갈 것 같습니다. 특히나 ㅅㅇ은행에서 보냈던 5 개월, 도저히 잊을 수가 없네요. 그때까지만 해도 큰 폭으로 변해 본적이 없었던 제 몸무게가 반 년 만에 6 kg 이 빠지고 얼굴 살들이 모두 실종되는 등 성격까지 나빠져 아주 참담한 모습이 되었었죠. 특히나 인상 깊었던 일은 그 당시 ㅅㅇ 은행의 어떤 차장님이 막 개발중인 시스템을 클릭해보곤 했는데 한번씩 뜨는 에러가 보기 싫다고 해서 그 분이 업무종료를 하는 오후 4시 반부터 일을 시작했었습니다. 거의 새벽 3,4 시가 되어야 끝이 났고 항상 택시를 타고 집에 들어가서 대충 잠을 잔 뒤 다음날 오후 2,3시쯤에 출근을 하곤 했지요.
한국의 개발자여, 단결하라
그 계약도 피라미드 식으로 이루어져 있었습니다. ㅅㅇ 은행이 삼성 SDS 에 프로젝트를 허가했고 저희 회사는 삼성 SDS 와 다시 계약하여 들어가 갑을병 상태였습니다. 또 거기에서 다시 저희 회사와 계약하여 들어온 병정 관계의 회사가 있었고요. 그렇게 갑을 병정이 한 데 모여 있으니 제대로 된 근무환경이 만들어질 리가 없었지요.
현재의 국내 소프트웨어 개발 관행은 많이 고쳐야 합니다. SW사업 하도급 금지된다 에서 위와 같은 피라미드를 근절하려는 노력들이 있습니다만 그 외에 많은 부당한 대우들을 얘기하고 논의해야 된다고 봅니다. IT 에 종사하시는 분들의 이야기로 훨씬 더 시끌시끌해졌으면 하는 바램입니다.
SW 프로젝트를 따낸 뒤 하청을 주는 관행이 조금은 줄어들었으면 좋겠네요. 개발력을 가진 회사들이 보다 더 잘 먹고 살 수 있는 계기가 되기를 기대해봅니다. 더불어 개발자 몸값도 좀 올라가구요.
삼성이나 LG 같은 대기업이 입찰에 참여하면, 누구나 그들의 손을 들어주고 싶을 겁니다. 대기업의 인프라가 있으니 마음이 든든한 거지요. 그러나 실제 프로젝트에서 대기업이 직접 개발을 하는 경우는 거의 없습니다. 대부분 하청에 하청에 하청을 거치게 되지요. 하청을 주는 것이 나쁘다는 것은 아니지만, 소프트웨어 개발에 있어서 다뤄야 되는 것이 '사람' 이라는 것을 고려해본다면 부작용은 있습니다. 기업과 기업간의 계약으로 묶여 있을 때 '을' 의 입장에 있는 개발자는 자신의 생산력을 제대로 발휘할 수 없을 거라고 봅니다. 여러 가지 제약과 개발자가 속해 있는 회사 내부에서 들어오는 압력으로 팀의 일원으로 일하긴 힘들겁니다.
예전에 산업은행에서 인터넷 뱅킹 개발을 했던 기억이 납니다. 삼성 SDS 가 프로젝트를 따냈고, 우리 회사는 거기에 하청을 받아 들어간 다음, 다시 하청을 줘서 조그만 개발사를 불러다 개발을 시켰습니다. 이 거대한 하청 구조의 하부쯤에 도달할 때는 프로젝트 수주로 인한 이득은 이리저리 뜯기고 몇푼 남지도 않습니다. 돈이 없으니 실제 개발해야 하는 사람들도 그다지 실력이 좋은 사람들은 아니었지요. 게다가 프로젝트에 대한 불만 사항이나 개선하고자 하는 점이 있어도 얘기할 곳이 없다는 게 큰 문제였습니다. 고작 자기네 회사에 얘기해보지만 돌아오는 대답이라고는 회사가 힘들어서 그러니 조금만 참아다오 뭐 이런 얘기 뿐이었지요.
회사간에 계약을 해서 서로 주고 받는 게 물건이라면 차라리 속편하겠지만, 소프트웨어는 전적으로 사람을 가지고 하는 일들입니다. 프로젝트 하청은 이것을 갉아 먹는 짓이구요. 전 개인적으로 소프트웨어 하청이 완전 없어져 버렸으면 좋겠다고 생각하지만, 컨설팅이나 매니지먼트의 프로젝트에 대한 영향력도 무시할 수 없으니, 위의 기사에 올라온 시도만이라도 박수를 쳐주고 싶네요.
