글 작성자: HEROHJK

(단위테스트 책 스터디 후 발표자료를 공유하기 위해 작성했습니다.)

 

저는 10월 ~ 1월까지 블라디미르 코리코프단위테스트 책을 가지고 북스터디를 진행했습니다.

 

단위테스트(Unit Test)란 무엇일까요?

 

소프트웨어 테스트 방식 중 하나로, 독립적으로 작동하는 코드 단위 중 가장 작은 코드를 테스트하는 것 입니다.

 

하나의 기능을 최대한 빠르고 가장 정확하게 테스트 하는 것을 목표로 하며, 이것들이 보장되어야 후에 진행할 통합테스트가 수월해집니다.

 

엔드투엔드 -> 통합 -> 단위로 이루어진 테스트 피라미드

 

그러면 왜 단위 테스트가 필요할까요? - 실패한 리팩토링 시나리오

 

1. 제품이 지속될수록 점점 길어지는 일정

단위 테스트 '만' 놓고 본다면 중요성은 그다지 크지 않습니다.

작은 코드 '만' 놓고 본다면, 실수할 여지도 크지 않고, 그저 발견된다면 고치면 되니까요.

 

어차피 테스트를 해주는 테스터 팀도 있고, 여태까지 우리 회사의 제품은 잘 굴려져 왔기에, 이번에도 어떻게든 잘 굴러갈거라고 믿어 의심치 않습니다.

 

분명 우리 제품의 초창기에는 기능의 추가나 수정요청이 들어오면.. 기능의 추가나 수정요청에 대한 일정이 합리적이었습니다.

 

소프트웨어를 개발하는 개발자도 납득이되고, 제품 개발에 참여하는 다른 팀원분들도 충분히 납득이 되는 시간과 기능입니다.

 

개발을 하고, 어디 빠진부분은 없나 제법 꼼꼼하게 체크도 합니다.

 

중간중간 아주 사소한 마찰이 있을수는 있겠지만.. 아주 사소한 마찰일 뿐 입니다.

 

그런데 생각해보면 뭔가 이상합니다.

 

1년이 지나고 2년이 지나고.. 마이너, 메이저버전이 올라가면 올라갈수록, 비슷한 규모의 기능 추가 / 수정이 개발자 입장에서는 점점 납득이 되지 않습니다.

 

하지만 이걸 설명하기는 귀찮습니다. 일단은 요구사항대로 개발을 진행합니다.

 

시켜서 하긴 하는데.. 자꾸 여기저기 걸리는부분이 많습니다..

중간중간 애로사항이 많이 꽃핍니다. 하지만 그래도 개발을 계속 합니다.

 

초기 설계에서 염두에두지 못한 기능이라 설계를 우회해야하고, 지금 당장 이 코드를 어디에 분류할지 몰라서 일단 바깥쪽에 둡니다.

 

미래의 내가 어떻게든 해줄겁니다.

 

이것은 절대 제가 게을러서 그런게 아닙니다. 시간이 모자란겁니다. 시간으로부터, 사회로부터 억까를 당하고 있는겁니다.

 

이렇게 기능개발을 또 하나 둘씩 마칩니다.

 

2. 회고를 해 보니..

개발을 마치고 회고를 해봅니다.

(거창하게 생각할것 없이 그냥 왜 이런가 생각만이라도 해볼수는 있으니까요)

 

더이상 미룰 수 없습니다.

 

구조 개선을 해야만 할 것 같습니다.

 

조금 더 지금 상황에 유연하게 대처가 가능한 구조를 짜고, 미뤄왔던 코드들(기술부채)을 정리하기로 결심합니다.

 

3. 리팩토링?!

리팩토링에 대한 시간을 보장받기는 상당히 어렵습니다. 그래도 반드시 필요한작업입니다.

 

보통은 개발 일정을 길게 잡아 남는 시간에, 혹은 정말 어렵게 어렵게 시간을 보장받아 진행합니다.

 

후자라면 다행이겠지만.. 전자라면 그것 마저도 시간이 모자랍니다.

 

대충 머릿속에서 생각해왔던 방식으로 구조 개선을 진행합니다.

 

처음에는 코드를 깔짝깔짝 건드리면서 리팩토링을 합니다.

 

처음에는 그럴싸하게 됩니다. 깔짝깔짝 건드리지만 나름 합리적으로 보입니다.

 

동작에도 크게 문제는 없어보이네요. 다른코드도 하나둘 건드려 봅니다.

 

내 생각과 다른부분이 조금씩 발견되지만.. 크게 이상한부분은 없어보이고, 여기까지 와서 중단하기도 좀 그렇습니다..

 

그러므로 계속해서 리팩토링을 진행합니다.

 

 

3.1 진행한 리팩토링이 가치가 있었을까?

의심되는 부분이 있었지만 어쨋든 리팩토링을 마쳤습니다.

 

기존 업무를 벗어난, 뭔가 코드에 대한 퀄리티를 높이는 작업이었기에 나름 성장했다는 기분도 들고 아주 뿌듯합니다 ㅎㅎ

 

하지만, 리팩토링의 가치는 무엇일까요?

 

코드가 유연해졌기에 추후 작업에 대한 일정을 단축시킬수 있을까요?

 

구조적 문제로 생긴 버그가 줄어들었을까요?

 

다 끝내고 보니, 업그레이드 되어있어야할 코드가 옆그레이드가 된건 아닐까요?

 

과연 그것을 어떻게 판단할 수 있을까요?

 

 

4. 리팩토링 이후에..

 

새로운 추가 개발건이 들어옵니다.

 

리팩토링한 코드를 검증할수 있는기회입니다.

 

'시간을 얼마나 줄일수 있을까?'

'얼마나 간단하게 추가할 수 있을까?'

'얼마나 깔끔하게 추가할 수 있을까?'

 

근데 요구사항을 들어보니 내 바램과 달라도 너무 다릅니다.

 

아.. 내가 개선한 코드가 빛을 보지 못합니다 ㅠㅠ

 

일정에 변화는 없습니다.

 

여전히 이상하게 걸리는 부분들이 있고, 기술부채를 힘들게 해결한게 엊그제인데, 

 

해결하자마자 또다른 기술부채가 쌓이게 됩니다.

 

그래도 어떻게든 되겠지.. 라고 위로하며 여차저차 개발 마무리 합니다.

 

힘겹고 고통스러운 개발 이후, 테스트 기간때 기둥 너머로 테스터분들의 눈치를 살핍니다.

 

표정이 안좋습니다. 얼굴이 울긋불긋 해집니다. 하필 그 타이밍에 저를 쳐다봅니다.

 

동료들과는 완만하게 지내는게 좋습니다.

처음에는 메시지로 전달해 줍니다.

'기존 기능이 작동을 안하네요~'

 

다음에는 자리에 와서 아주 상냥하게 여쭤봅니다.

'이 기능이 이렇게 바뀌었는데 왜 이러는걸까요~? ^^'

 

자리에 찾아오는 빈도가 높아집니다.

 

나도, 테스터도 퇴근하는 시간이 점점 늦어집니다.

 

말투도 건조해져 갑니다.

'아직이에요?'

'네..'

'언제 돼요?'

'...방 돼요...'

'뭐라고요? 크게좀 말해봐요'

'.... 금방 돼요...'

 

계획에 없는 야근때문에 예민해진 테스터와, 최대한 눈을 안마주치려고 노력하는 개발자, 그리고 무슨일인가 싶어 구경하는 동료 개발자들.

네.. 이번 리팩토링은 망했습니다. 개발 일정 단축도, 버그를 잡는것도 모두 실패했습니다.

 

무엇이 문제였으며, 이게 테스트와 무슨 상관이 있을까?

힘들게,, 어쩌면 개인 시간까지 투자해가며 리팩토링을 진행하는경우가 상당한데, 그 리팩토링이 과연 효율적인가? 성공적인가? 를 판단해야 합니다.

그리고 리팩토링의 성공 확률을 올려야 합니다.

 

단위테스트와 통합테스트를 이용한 개발 및 유지보수는 그것에 대한 아주 좋은 방법입니다.

 

테스트를 포함한 개발을 처음 한다면, 절대로 쉽지 않습니다.

 

단위테스트를 위한 작은 구조를 만들어야 하고,

 

지금 작성한 코드가 단위테스트의 영역인지, 통합테스트의 영역인지 구분해야 합니다.

 

구분이 안가면 분리해야합니다.

 

처음의 높은 러닝 커브(Learning Curve, 학습 곡선)를 감내하더라도, 초기 개발 이후 제품이 지속되는 단계에서는 그 초기 투자 비용이 빛을 볼수 있습니다.

 

개인적으로 생각하는 테스트를 포함한 개발은 어떤 이점이 있는지 생각 해 봤습니다.

 

1. 단위테스트, 통합테스트, Mockable 등을 구분하기 위해 코드를 명확하게 분리 하는것을 항상 염두에 둔다. 따라서 코드의 구분이 상대적으로 명확해진다.

2. 코드의 구분이 명확해지므로 이후 추가 개발, 수정에 대한 부담이 상대적으로 줄어든다.

3. 아주 기본적인 테스트를 개발자단계에서 진행하기에, 제품 자체를 테스트하는 테스터들의 부담이 그만큼 줄어들게 된다.

4. 따라서 테스트 기간이 짧아지며, 이는 제품 전체의 개발기간 단축으로 이어진다.

 

 

그래서, 개발할 때 테스트를 해야돼?

결론부터 얘기해서, 해서 손해볼게 그다지 없습니다.

처음부터 완벽한 코드를 만들수는 없습니다.

코드는 지속적으로 리팩토링을 해야합니다.

하지만 이왕 리팩토링 하는거, 잘 하는게 중요합니다.

앞에서 말했듯이, 테스트를 포함한 개발은 그것에 대한 명확하고 효과적인 방법중 하나입니다.

 

일정이 줄어든다고 생각이 되시나요?

 

줄어들기 전의 일정은 원래부터 빠듯한 일정이었습니다.

코딩 측면에서는 모르겠지만, 최소한 제품 개발의 측면에선 그렇습니다.

 

(아래는 만약에 PT자료나 영상을 만들게 되면 쓸 내용입니다. 아직 미완성..)

 

더보기

제가 좋아하는 시티즈 스카이라인이라는 게임으로 예시를 들어보겠습니다.

시티즈 스카이라인은 도시를 설계하는 게임입니다. 특히 도로 계획, 교통에 따른 트래픽에 많은 중점을 두고있는 꽤나 현실적인 게임입니다.

(실제로 우리나라 몇몇 시/도청에서 저 게임으로 도로계획 공모전을 실시한적이 있습니다)

 

게임을 하는 누구나 저 위에 스크린샷처럼 멋진 도시를 구현하고 싶어합니다.

 

처음에는 이렇게 소박하게 시작을 합니다. 작게나마 도로를 만들고, 주거지역을 설정하고, 상가를 설정하고, 산업지역도 설정을 합니다.

여기까진 괜찮습니다.

 

하지만 지속적으로 인구가 유입이 됩니다. 그러면 도시 확장을 해야합니다.

도로를 파고 다시 구획을 나눠야 하죠.

미리 생각해둔 계획이 없거나.. 미리 생각해둔 계획이 있더라도 뭐든지 일들은 내 예상과 바램대로 흘러가지 않습니다.

 

게임이기 때문에, 운석, 홍수같은 자연재해를 일으켜 다 없애 버리고 새로 시작해도 되긴 합니다.

순식간에 교통이 정체가 됩니다.

 

교통이 정체된다면 공공서비스가 중단이 됩니다.

 

소방차, 경찰차도 제시간에 운행되지 못하고 쓰레기차또한 마찬가지입니다.

 

즉, 잘못된 도시계획으로 가정이 무너지고 사회가 무너지게 됩니다.

 

 

반응형