TDD란

TDD란 Test Driven Development 약자로 ‘테스트 주도 개발’ 이라고 합니다. 즉, TEST CASE를 먼저 작성한 뒤 실제 코드를 작성하는 방법입니다.

의문점

2년동안 SI 프로젝트를 3건을 진행하고, 내부 프로젝트, REST API 개발 등 여러 가지를 개발 업무를 하면서 왜? 많은 기업에서 특히 중소기업에서는 TDD 방식을 선호하지 않을까? 라는 의문점과 그 이유를 경험을 기반으로 포스팅하려 합니다.

기존 개발 방식의 문제점

기존 개발방식은 설계 -> 코드개발 -> 테스트 -> 설계(수정)) 순서로 진행되며, 테스트를 하다가 설계 및 개발코드를 다시 수정하는 경우가 비일비재합니다. 실제로 SI 프로젝트를 진행할 때 보통 화면설계, DB설계를 마친 뒤 코드개발을 진행 합니다.
그 이후 테스트 시나리오를 작성하게 되는데, 보통 INPUT -> OUTPUT이 제대로 작동하고 있는지에 대한 테스트가 대부분이기 때문에 흔히 스파게티 코드, 하드코딩, 재사용성 Zero 여도 OUTPUT만 제대로 나온다면 통과가 됩니다.

뿐만 아니라 많은 문제점이 있는데, 크게 3가지로 정리해봤습니다.

[문제점 1] : 설계 및 개발 완료 후 테스트를 진행하므로, 잘못된 설계 및 개발코드의 재수정 필요

보통 개발이 완료된 후 테스트 시나리오를 작성하고 테스트를 진행하게 됩니다.
단순히 개발코드의 로직에 문제가 있으면 다행이지만(그냥 코드수정만 하면되므로) 설계 밑단부터 문제가 있으면 처음부터 다시 해야되는 상황이 발생하게 됩니다.
보통 기간 및 공수를 산정하고 프로젝트를 진행하기 때문에 이러한 문제가 발생하면 납기일에 차질이 생기게 됩니다.

[문제점 2] : 납기 위주의 프로젝트성이 강하다 보니 소프트웨어의 완성도가 떨어짐

SI 프로젝트의 최고의 단점은 소프트웨어의 품질보다 납기일 준수입니다. 즉, 소프트웨어의 퀄리티가 떨어지더라도 프로젝트 완료에 초점을 둔다는 것입니다.
실제로 SI 프로젝트를 하다보면, 재사용성 및 유지보수를 염두해서 개발하시는 분들은 극히 드물다고 생각합니다. 그 이유는 충분한 시간이 보장되지 않으며 납기일 준수에만 집중하기 때문입니다.

[문제점 3] : 유지보수의 어려움

만약, 화면상 데이터가 이상하게 나온다면 프론트 문제인지, 백엔드 문제인지, DB상의 문제인지, UI 문제인지 전부 하나씩 디버깅해야 한다. 왜냐하면 기능별로 테스트가 정의되어 있지 않기 때문에 어떤 에러가 발생했을 때 어떤 기능이 문제인지 알 방법이 없다.
따라서, 해당 섹터를 개발한 개발자가 아니라면 전체 로직을 이해하고 디버깅하는데 오랜 시간이 필요하다.

TDD 방식의 장/단점

TDD (테스트 주도 개발)은 기존 개발 방식과는 다르게 설계(디자인) <-> 테스트 코드 작성 -> 코드개발를 진행한다. 테스트 코드 작성 이라는 부분에서 기존의 테스트와 혼동할 수 있는데, 정확하게는 다르다. 또한 단위 테스트(unit Test)로 진행하기 때문에 실패시 최소한의 코드개선과 성공시 실제 코드개발로 적용하는 리팩토링 과정이 이루어진다.

[장점 1] : TDD의 테스트 코드는 해당 기능의 정상 작동여부를 검증하기 위한 것

기존 방식의 테스트는 어떤 값이 들어오면 어떤값으로 나오겠지?의 단순한 INPUT 대비 OUTPUT이다. 하지만 TDD의 테스트는 코드는 해당 기능이 정상적으로 작동하기 위한 테스트이다.
예를들어, SUM(INPUT1,INPUT2, INPUT3) 이라는 기능을 만들 때 SUM의 기능이 정상적으로 작동하기 위한 테스트 코드를 작성해 볼 수 있다.
1. INPUT1, INPUT2, INPUT3 이 INT 타입으로 들어 오는가? -> 맞으면 True, 아니면 False
2. INPUT1, INPUT2, INPUT3 이 2자리 수 인가? -> 맞으면 True, 아니면 False
3. INPUT1, INPUT2, INPUT3 의 총합은 0이상 300 이하인가? -> 맞으면 True, 아니면 False
단위 테스트를 통해 개선코드를 최소화 할 수 있으며, 이는 철저한 모듈화로 종속성과 의존성이 낮은 소프트웨어 개발이 가능하게 합니다.
디버깅 시간을 단축할 수 있으며, 어디서 발생한 에러인지 손 쉽게 찾을 수 있습니다.

[장점 2] : 불확실한 미래에 대비하여 큰 실패를 줄이기 위한 것

만약, 여러번 해본 개발이거나 어떤 결과가 나올지 뻔히 알고있는 경우라면 TDD가 비효율적이라고 생각한다. TDD를 하는 가장 큰 이유는
1. 처음 해보는 프로젝트 (어떤 에러가 발생할 지 전혀 예상할 수 없기 때문에)
2. 요구사항이 다양한 경우 (고객사의 요구사항이 매번 바뀌는 경우가 많음)

[장점 3] : 객체지향적인 개발로 재사용성 보장

TDD 방식의 목적이라고 말할 수 있을 정도로 중요합니다. 모든 코드는 재사용성을 기반으로 작성되어야 하기 때문입니다.
[장점 1] 이 가능하게 되는 이유가 여기에 있다고 말할 수 있습니다. 그 이유는 복잡한 기능을 모듈단위로 쪼개어 개발하기 때문에 테스트의 용이성을 보장하는 겁니다.

[장점 4] : 시간 단축

시간 단축은 많은 것을 내포하고 있습니다.
1. 디버깅 시간 단축
2. 코드 수정 시간 단축
3. 설계 수정 시간 단축
4. 유지보수 시간 단축

[단점 1] : 개발 생산성 저하

많은 개발자들은 TDD 방식이 생산성이 저하된다고 생각한다. 그 이유는 코드를 2번이나 짜야되기 때문이다. 많은 회사에서 TDD 방식을 사용하지 않기에 개발자들 또한 익숙하지 않다고 생각합니다. 대한민국 개발 생태계에서는 납기일 준수가 중요하기 때문에 큰 기업이 아니고서야 TDD방식을 사용하는 기업은 드물다고 생각합니다.

마무리

예전 만O SI 프로젝트를 진행하면서 느꼈던 경험을 기반으로 포스팅을 작성했습니다.
TDD 방식의 개발 경험은 없지만, 테스트를 일상화하는 개발자가 되고 싶어 해당 포스팅을 작성하게 되었습니다.
1년차때는 왜 회사는 핫한 view, react, angular를 사용하지 않는지?, 왜 코드리뷰나 TDD 방식을 하지 않는지? 등의 여러 의구심과 불만을 가졌지만
현재는 회사의 상황, 시대적 흐름, 개발 생태계와 같은 거시적인 관점으로 바라볼 필요성을 느끼게 되었습니다.
당장 내가 하고싶은 기술보다는 회사의 상황과 필요로하는 기술을 받아드리는게 우선이 아닐까? 라는 생각을 갖게 되었습니다.