쪼개고 쪼개고 쪼개기

대학 시절 죽치고 있던 컴퓨터 동아리는 하드웨어와 소프트웨어를 함께 하는 곳이었다. 동아리에는 인두, 기판, 모터, LED와 같은 것들이 널려 있었다. 하드웨어를 하진 않았지만, 새내기 시절에 선배들이나 동기들이 납땜하는 모습을 옆에서 구경도 하고, 서울대에서 했던 마우스 대회에 구경도 가곤 했다.

처음 기판에 땜질을 하다 보면 LED에 불이 제대로 들어오지 않거나 모터가 동작하지 않는 경우가 자주 발생하는데, 그럴  때마다 구세주처럼 등장하는 것이 바로 측정기다. 이 장치를 사용하면 회로마다 전류가 제대로 흐르는지 확인할 수 있기 때문에 문제가 있는 지점을 찾을 때 큰 도움이 된다. 값이 올바른 부분을 제외하다 보면 어느새 잘못했거나 실수한 부분을 찾게 되는 것이다.

이는 테스트 범위를 좁히는 것이 얼마나 중요한지 보여준다. 테스트 범위를 좁힐 수 있어야 문제가 발생할 때 원인을 빨리 찾아 제거할 수 있는 것이다.

소프트웨어도 마찬가지다. 모든 코드를 다 만든 다음에 통합 테스트를 하는데 원하는 대로 동작하지 않을 때가 있다. 어떤 문제는 쉽게 발견할 수 있지만, 어떤 문제는 구석에 숨어 있어서 원인을 찾기 힘들 때가 있다. 이때 범위를 좁혀서  테스트할 수 있다면 숨어 있는 버그를 발견하는 시간을 줄일 수 있다.

테스트 범위를 좁힐 수 있으려면 코드를 쪼갤 수 있어야 한다. 메서드 하나가 너무 길면 엮이는 것들이 많아지기 때문에 특정 범위만 테스트할 수 없어 전체 메서드를 테스트해야 한다. 진짜 측정하고 싶은 범위가 전체 메서드에서 일부라면 그 일부만 발라내서 정상 여부를 측정할 수 있어야 하는데, 발라내지 못한다면 메서드 전체를 테스트하느라 시간을 더 많이 쓰게 된다.

그래서, 중요한 것이 발라내는 능력, 즉, 역할과 책임에 따라 모듈을 분리하는 능력이다. 이 능력이 부족하면 함수나 클래스 크기가 점점 커지게 되고 그에 따라 테스트하는 시간도 증가하게 된다. 즉, 개발 시간을 줄여서 빨리 개발하고 싶다면, 코딩력과 더불어 이 능력도 함께 키워야 한다. 이 능력이 떨어지면 범위를 좁혀서 테스트하는데 필요한 단위 테스트를 작성하는 것도 힘들어진다.

코딩력만큼이나 중요한 쪼개는 능력을 키우기 위해 난 오늘도 단위 테스트를 시도해본다.