CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

당신이 도시가 성장하는 모습을 지켜보고 있다고 상상해 보십시오. 당신은 매일 얼마나 많은 벽돌이 놓이는지 셀 수도 있고, 시의회가 규칙을 준-수했는지 확인할 수도 있습니다. 하지만 도시를 바라보는 더 흥สนใจ로운 세 번째 방법이 있습니다. 바로 건물이 어떻게 변하는지를 관찰하는 것입니다. 사람들은 새로운 방을 만들기 위해 오래된 벽을 허뭅니까? 본채에는 닿지 않으면서 옆면에 새로운 별채를 붙여 짓습니까? 아니면 단순히 조명을 바꾸기 위해 스위치를 올립니까? 혹은 단순히 가구 배치만 바꿉니까? 소프트웨어 세계에서 이것은 바로 연구자들이 던지는 질문입니다. 소프트웨어는 단순한 코드가 아닙니다. 그것은 끊임없이 변화해야 하는 살아있는 시스템입니다. 만약 시스템이 자신의 벽을 허물며 변화한다면, 결국 흔들리고 위험한 엉망진창이 될 것입니다. 하지만 새로운 별채를 붙이거나 스위치를 올리는 방식으로 변화한다면, 시스템은 강하고 유연하게 유지될 수 있습니다. 이것이 바로 "소프트웨어 품질"의 핵심입니다. 단순히 오늘 코드가 작동하느냐가 아니라, 내일도 무너지지 않고 계속 성장할 수 있느냐의 문제입니다.

이 논문은 이 질문에 답하기 위해 CLEM(Change Localization and Externalization Measurement, 변경 국소화 및 외부화 측정)이라는 새로운 도구를 소개합니다. CLEM은 단순히 얼마나 많은 코드가 변경되었는지 세는 대신, 개발자들이 시스템을 수정하거나 업데이트하는 방식을 관찰하는 탐정 역할을 합니다. 이 도구는 모든 변경 사항을 네 가지 "페르소나" 중 하나로 분류합니다:

1. 수정 (Modification, M): "벽 허물기" 방식입니다. 핵심 코드를 직접 변경합니다. 빠르지만 위험하며, 문을 만들기 위해 벽에 구멍을 뚫는 것과 같습니다.
2. 확장 (Extension, E): "덧붙이기" 방식입니다. 핵심 코드에는 손을 대지 않고 시스템에 플러그인되는 새로운 기능을 구축하는 것으로, 집 옆에 새 방을 만드는 것과 같습니다.
3. 로우코드 (Low-code, L): "플로우 차트" 방식입니다. 코드를 작성하지 않고 시각적 도구나 규칙을 사용하여 동작을 변경하는 것으로, 비즈니스 매니저가 워크플로우를 재배치하는 것과 같습니다.
4. 설정 (Configuration, C): "스위치" 방식입니다. 볼륨 조절 다이얼을 돌려 소리를 조절하듯 설정이나 파라미터를 변경하는 것뿐입니다.

연구자들은 이 아이디어를 세 가지 소프트웨어 프로젝트(대형 기술 생태계의 공개 프로젝트 두 개와 하나의 비공개 헬스케어 앱)에서 테스트했습니다. 그들은 CLEM이 "건강한" 시스템(주로 덧붙이기와 스위치 사용)과 "병든" 시스템(끊임없이 핵심 코드를 해킹함)을 명확히 구분할 수 있다는 것을 발견했습니다. 그러나 그들은 또한 놀라운 사실을 발견했습니다. 시스템이 어떻게 변하는지 아는 것이 다음 달에 더 많은 버그가 발생할지를 자동으로 예측해주지는 않는다는 점입니다. CLEM은 시스템의 구조를 이해하는 데는 훌륭한 도구이지만, 미래의 오류를 예측하는 수정구슬은 아닙니다.

탐정의 새로운 노트: CLEM의 작동 원리

소프트웨어 개발을 바쁜 주방이라고 생각해 보십시오. 오랫동안 요리사(개발자)들은 얼마나 많은 요리를 만들었는지(활동량) 또는 밤이 끝날 때 주방이 얼마나 깨끗한지(정적 코드 검사)로 측정되어 왔습니다. 하지만 만약 새로운 향신료가 필요할 때마다 벽을 부수어야 한다면 주방은 무너지고 있는 것 아닐까요? 그것이 바로 CLEM이 해결하는 문제입니다. CLEM은 단순히 요리의 수를 세는 것이 아니라, 요리사들이 식재료를 얻기 위해 사용하는 방법을 관찰합니다.

논문은 소프트웨어 시스템이 업데이트될 때마다 변경이 네 가지 방식 중 하나로 일어난다고 제안하며, 이러한 방식들의 조합이 시스템의 건강 상태에 대한 모든 것을 말해준다고 주장합니다.

• **수정 (Modification)**은 "무력(Brute Force)" 방식입니다. 이는 마치 요리사가 새 선반을 만들기 위해 망치를 들고 벽을 부수는 것과 같습니다. 작업은 빠르게 처리되지만, 이를 너무 많이 하면 건물 전체가 불안정해집니다.
• **확장 (Extension)**은 "모듈형" 방식입니다. 이는 주방으로 굴러 들어오는 탈착식 카트를 만드는 것과 같습니다. 요리사는 벽을 건드리지 않고 새로운 도구를 추가할 뿐입니다. 이는 더 안전하며 핵심 구조를 온전히 유지합니다.
• **로우코드 (Low-code)**는 "청사진" 방식입니다. 매니저가 로봇을 재프로그래밍하지 않고도 로봇이 무엇을 할지 알려주는 새로운 흐름을 화이트보드에 그리는 것과 같습니다. 이는 더 높은 수준의 변경 방식입니다.
• **설정 (Configuration)**은 "다이얼" 방식입니다. 오븐을 더 뜨겁게 하거나 조명을 밝게 하기 위해 손잡이를 돌리는 것뿐입니다. 건설 작업은 전혀 필요 없습니다.

저자들은 건강하고 오래 지속되는 소프트웨어 시스템은 수정보다는 확장, 로우코드, 설정에 더 많이 의존해야 한다고 주장합니다. 만약 시스템이 끊임없이 핵심을 "수정"하고 있다면, 그것은 "기술 부채", 즉 미래의 안정성을 빌려 쓰고 나중에 이자와 함께 갚아야 하는 상태에 처해 있을 가능성이 높습니다.

실험: 세 개의 주방을 관찰하다

이 아이디어가 작동하는지 확인하기 위해 연구자들은 세 개의 서로 다른 "주방"(소프트웨어 저장소)으로 현장 학습을 떠났습니다. 그들은 단순히 최종 요리만을 본 것이 아니라, 몇 달 동안 요리사들의 손을 지켜보았습니다.

1. "Fit" 주방 (fit-framework): 이 프로젝트는 플러그인 시스템을 위해 설계된 공개 프로젝트입니다. 연구자들은 이곳에 "확장(E)"이 가득할 것으로 예상했습니다.
2. "App" 주방 (app-platform): 이 프로젝트 역시 공개 프로젝트이지만, 로우코드 시각적 설계를 위해 구축되었습니다. 연구자들은 이곳에 "로우코드(L)"와 "설정(C)"이 많을 것으로 예상했습니다.
3. "Antisuger" 주방: 이는 혈당 관리를 위한 비공개 헬스케어 앱입니다. 다른 팀과 다른 도구로 만들어졌습니다. 연구자들은 이곳이 초기 단계의 혼란스러운 상태이며, "수정(M)"이 많을 것으로 예상했습니다.

연구자들은 이 프로젝트들에 걸친 607개의 특정 업데이트(커밋)를 분석했습니다. 그들은 변경된 파일들을 살펴보기 위해 투명한 규칙 세트를 사용했습니다. 만약 파일이 "플러근" 폴더에 있다면 그것을 확장으로 계산했습니다. 만약 "플로우" 파일이라면 로우코드로 계산했습니다. 만약 핵심 코드 파일이라면 수정으로 계산했습니다.

결과: 시스템들은 서로 달랐다

결과는 "건강한 주방" 이론이 예측한 대로였습니다.

• App-platform은 실제로 매우 "외부화"되어 있었습니다. 변경 사항의 약 **69.5%**가 확장이었으며, 핵심을 직접 해킹하는 경우는 거의 없었습니다. 이 시스템의 "CLEM-ES" 점수(변화를 핵심에서 얼마나 밀어냈는지를 측정하는 척도)는 +0.685로 강력했습니다.
• Fit-framework는 혼합된 형태였습니다. 많은 양의 확장(33.4%)이 있었지만, 상당한 양의 수정(29.1%)도 존재했습니다. 이 시스템의 점수는 +0.418로, 완전한 엉망진창보다는 건강했지만 App platform만큼 "외부화"되지는 않았습니다.
• Antisuger 헬스케어 앱은 정반대였습니다. 변경 사항의 **83.0%**가 직접적인 핵심 편집인 "수정" 중심이었습니다. 이 시스템의 점수는 -0.659였으며, 이는 여전히 "벽을 해킹하는" 취약한 단계임을 나타냈습니다.

이는 CLEM이 벽을 허물며 성장하는 시스템과 벽을 부수며 성장하는 시스템의 차이를 성공적으로 포착할 수 있음을 증 증명했습니다. 연구자들은 또한 두 명의 사람이 160개의 무작위 업데이트를 검토하게 하여 규칙이 공정한지 확인했습니다. 그들은 주요 카테고리에 대해 100% 일치하는 의견을 보였으며, 이는 규칙이 견고하고 재현 가능하다는 것을 시사합니다.

반전: 구조가 버그를 예측하지는 못한다 (아직은)

이 부분이 논문이 매우 신중하게 다루는 대목입니다. 당신은 "만약 시스템이 자신의 벽을 해킹하고 있다면(높은 수정도), 더 자주 고장이 나야 하는 것 아닌가?"라고 생각할 수 있습니다. 연구자들은 이를 테스트했습니다. 그들은 CLEM 점수가 다음 달에 더 많은 "버그 수정"이 발생할지를 예측할 수 있는지 살펴보았습니다.

결과는? 뚜렷한 연관성이 없었습니다.
데이터에서 "수정" 점수는 다음 달이 버그 수정으로 가득 찰지를 안정적으로 예측하지 못했습니다. 이 특정 샘플에서 "CLEM-ES" 점수(변경이 얼마나 외부화되었는지)는 미래의 버그 수정과 거의 제로에 가까운 상관관계를 보였습니다.

이것은 매우 중요한 발견입니다. 저자들은 CLEM이 결함을 예측하는 마법의 수정구슬이 아님을 명시적으로 밝힙니다. CLEM은 기존의 버그나 코드 변화량을 세는 방식을 대체하는 것이 아닙니다. 대신, 그것은 다른 종류의 통찰력을 제공합니다. 그것은 시스템의 구조적 자세를 알려줍니다. 높은 수정 점수를 가진 시스템이 당장 버그가 더 많지는 않을 수 있지만, 유지보수가 더 어렵고 시간이 지남에 따라 더 취약해질 가능성이 높은 구조를 구축하고 있다는 뜻입니다. 이는 마치 구조적으로 불안정한 건물과 같습니다. 오늘 당장 무너지지는 않겠지만, 설계도가 잘못된 것입니다.

이것이 왜 중요한가

논문은 결론적으로 CLEM이 소프트웨어 관리자들에게 강력한 새로운 렌즈가 된다고 말합니다. 이는 대화의 주제를 "얼마나 많은 코드를 썼는가?"에서 "시스템을 어떻게 바꾸고 있는가?"로 옮겨놓습니다.

• 만약 팀이 끊임없이 수정을 하고 있다면, 이는 잠시 멈추고 이렇게 물어야 한다는 신호입니다: "왜 우리 스스로의 벽을 허물고 있나요? 대신 플러그인을 만들 수는 없나요?"
• 만약 팀이 주로 확장과 설정을 하고 있다면, 이는 시스템이 성숙해지고 더 안정적으로 변하고 있음을 시사합니다.

저자들은 자신들의 연구 한계를 솔직하게 인정합니다. 샘陪플 크기가 작았고(세 프로젝트에서 가져온 몇 달간의 데이터), "버그 예측" 부분이 기대만큼 작동하지 않았음을 인정했습니다. 그들은 CLEM이 보완적인 도구로서 사용되는 것이 가장 좋다고 제안합니다. 즉, 전통적인 지표와 함께 시스템의 구조적 건강을 감시하는 용도로 사용하는 것입니다. CLEM은 품질에 대한 최종 판결이 아니라, 소프트웨어 시스템이 성장하는 법을 배우고 있는지, 아니면 기초를 부수는 습관에 갇혀 있는지를 보여주는 매우 명확하고 감사 가능한 방법입니다.

요약하자면, CLEM은 우리에게 변화의 모양에 대해 이야기할 수 있는 어휘를 제공합니다. 그것은 우리의 소프트웨어가 마천루를 짓고 있는지, 아니면 그저 흔들리는 더미 위에 벽돌을 쌓고 있는지를 보게 해줍니다. 그리고 그 차이가 장기적인 디지털 시스템의 생존을 위해 우리가 측정할 수 있는 가장 중요한 것일지도 모릅니다.