NDC 참관기: 변화량 추적을 중심으로 한 저비용 고효율의 지속적인 코드퀄리티 관리법

2011. 6. 3.

6/1일자 오후 세션이었던 네오플의 송창규 님의 강연입니다.

이하는 간략한 요약.

게임 업계의 패러다임 변화: 새 게임 만들기 => ‘성공한 게임’의 개선, 유지

그런 이유로 지속 가능성이 중요하다

깨진 창문 효과: 관리되지 않는다는 느낌을 주면 안된다.

하지만, 라이브 서비스의 경우, 그 규모에 압도 되서 (코드 베이스가) 슬럼화될 수 있다. 청소 메타포: 매일 매일 청소할 게 생기고, 하지 않는다고 못 버티는건 아니지만, 계속 해서 불편해짐..

코드 퀄리티 관리와 비슷하다. 그러나 프로젝트가 시간이 흘러 코드 베이스는 계속 해서 (무한정) 커지지만, 거기에 투입할 수 있는 프로그래머 수에는 한계가 있다는 점은 큰 차이

=> 학습된 무기력을 낳는다

자동화 + 시간에 따른 변화에 중점

(정적 분석에서는) 코드를 데이터로 보고 이를 분석한다. 여기에 시간 개념을 포함해서 소스 코드를 시간에 따라 `변화하는 데이터’로 보자.

어떻게 나눌까?

논리적 분류, 의존성에 따른 분류, 그리고 변동성에 따른 분류. 프로젝트 유지 비용을 낮게 하려면 변동성이 높은 것과 낮은 것을 잘 나눠야 한다.

단, 변동성의 개념에 따라, 낮은 변동성인 요소가 높은 변동성인 요소에 의존하면 높은 변동성인 요소가 되어버린다.

‘;정량적으로 측정?’ => ‘소스 저장소의 변화량을 측정’ 기대 효과: 많이 바뀐 곳이 (아마) 중요한 곳일 것이다

변동성이 높은 곳(파일)을 개선하면?

문제: 만약 파급력이 높고, 변동성도 높은 파일이 있다면? 명백히 좋지 않으니 어떻게 하지 않으면.

이런 파일을 어떻게 찾을까? 변동성, 파급력, 시간에 따른 파급력이 모두 높은 파일?

Python 스크립트로 소스 저장소 데이터를 측정해서,

(이 부분에서는 던파, 크아 BnB, 메이플 스토리(일부는 누락) 소스 저장소 데이터를 모아서 보여줬다. 개략적으로 자주 변하는 파일과, 그 부분에 대한 간략간략한 개선 방향을 언급함)

숫자의 함정에 유의하자:

잘 안된다 -> 공정 개선이 필요

Assertion: 특히 MT환경에서 효과가 좋았다.

등등.

Assertion을 나누는 것,

Validator는 지속 가능성이 낮다: 강제하기 힘듬

지속가능하게 하려면?

매우 재밌게 들었다.

연사가 충분한 케이스 스터디 ‘넥슨 내 장기간 지속된 프로젝트에서 추출한 데이터로 ‘쓸 만 하겠다’라는 생각을 충분히 줬다. 이 아이디어를 당장 팀 내 저장소에 넣고 돌려봐도 쓸모 있을 듯 함.

이런 류의 세션에서는 역시 “실제로 해보고”, “케이스 스터디도 있고” 란 점이 주는 신뢰도에 많은 영향을 준다.

Validator 같은 부분도 @ipkn 이 말하던 ‘스크립트 변수 edit-distance로 잘못 쓴거 찾자’랑 비슷한 느낌이기도 하더라.

첫 날 메이플 스토리 개발 스토리 세션에서도 말한 내용이지만, “기존 레거시 코드"에 대해서 예외를 인정하고, (특히나 변경되지 않는 부분이라면 더더욱) 새로 추가하거나 변경하는 부분에 중점을 두는 것은 “실제로 적용하기 위해선 꼭 필요한 정책"이라고 생각한다.

단순히 “새로 할 때 잘 하자"가 아니라, 라이브 서비스나 이미 충분히 진행 중인 서비스에서 적용할 수 있게, “저비용 고효율 방법론"을 제시한 점이 아주 좋았음.

[^1] 빌드 시간 개선; 봐야할 장소 줄이기 등등; 연사가 측정한 바로는 변동성 적은 것만 묶어서 unity build하면 효과가 좋다고 한다(던파 클라 빌드시간 3x분 -> 1x분.