[SI 프로젝트 TDD 실천기] 1. 프로젝트 분석부터 개발 초기까지 느낀점

저는 주로 보험사 사이버창구 업무에 관해 SI프로젝트를 하고 있습니다. 운 좋게 이번 프로젝트에서는 킥오프부터 투입하게 되어 프레임워크 설정에 대해 적극적으로 참여할 수 있었습니다. 그래서 기존 소스분석 과정에서 불필요한 부분은 과감히 줄이고, 새로운 프로젝트에 필요한 라이브러리를 자유롭게 추가하기도 했습니다.

 

이런 상황에서 몇 가지 키워드를 중심으로 SI 프로젝트에서 TDD를 실천한 후기를 써보겠습니다.

오프라인 프로젝트의 문제점

보험사를 비롯하여 금융 프로젝트는 대부분 인터넷을 사용할 수 없습니다. 이런 제약 속에서 먼저 떠오르는 생각은 단연 구글링입니다. 구글링 없는 개발은 상상하기도 힘든 오늘날의 개발실정에 통감하게 됩니다.

하지만 시간이 지나면 진짜 문제는 프로젝트의 의존성 관리입니다. 의외로 구글링은 스마트폰, 테블릿 등 대체가 가능하지만, 의존성은 컴파일 시점에 인터넷에 연결되어 있지 않으면 문제가 발생하는 경우가 대부분입니다. 이런 환경에서 처음으로 프레임워크를 만들게 되면 꽤 오랜 시간을 뺏기게 됩니다.

하드웨어의 제약

M 생명사의 사이버창구 리뉴얼 프로젝트를 할 때는, 해당 업체에서 제공하는 17인치 정도 되는 모니터-본체 일체형 PC를 제공받아서 클라우드 환경에서 개발을 했습니다. 금융사들이 IT 신기술 도입에 보수적일 것 같지만, 보안과 관련된 문제에 있어서는 적극적이구나 싶구나 생각이 들었습니다.

다시 본론으로 돌아오면, 오늘날 대부분의 금융 프로젝트가 이런 환경에서 진행됩니다. 특히 이번 프로젝트 발주사는 이전에 그룹사 내에서 보안 문제로 큰 속앓이를 한 이력이 있어 장비나 보안에 있어 더욱 철저했습니다.(여담이지만 제가 외부장비에 도입에 대한 필요성을 구구절절 작성하여 개발PL님을 설득했더니 고객사에도 잘 전해져서 현재는 외부장비에 VPN 및 보안 프로그램을 설치하여 개발하게 되었습니다ㅎㅎ)

JUnit과 Mockito 라이브러리 도입

차장, 과장님들에게 JUnit을 써보고 싶다고 건의를 했습니다. TDD란 것이 무엇인지는 잘 모르시는 눈치였지만, JUnit이 테스트를 위한 도구라는 것은 잘 알고 계신 것 같았습니다. 아마 주니어 개발자가 새로운 것을 시도해 보고 싶다는 생각이 기특하게 느껴지셨는지 적극적으로 도와주셨으리라 생각됩니다.

처음에는 mvnrepository에서 하나씩 jar파일을 받아서 현업 담당자를 통해 적용했는데 문제는 글 앞에서 말했듯이, 오프라인 환경에서는 의존성 관리가 되질 않습니다. 따라서 다른 의존jar가 존재할 경우 어김없이 오류가 발생하고, 확인하고, 다른 jar를 반입하는 작업을 반복하게 되어 생각보다 순탄치 않았습니다.

적용 후 발생한 문제점

기간계 시스템 프로젝트가 아니다 보니, 대부분의 데이터는 인터페이스 통신에 의존합니다. 이 말이 무슨말인지 이해가 안가시는 분들이 계실수 있으니 조금 더 풀어서 말해보자면,

'개발자가 비즈니스 로직을 깊게 알 필요가 없고, 필요한 데이터만 파라미터로 세팅해 인터페이스 통신을 하면 비즈니스 로직을 통과한 결과 데이터를 받아볼 수 있습니다.'

이렇다 보니 컨트롤러 테스트, 서비스 테스트, DAO 테스트 등을 세분화 하자니 너무 형식적으로 테스트가 진행되는 문제점이 발생합니다. 작성된 서비스 코드는 통신 결과를 잘 가져오는지 확인하는 것이 전부였고, DAO는 인터페이스 통신을 확인하는 테스트 뿐이었습니다.

내가 작성한 로직이 틀렸는지 보다는 데이터가 올바르게 전달되고, 올바르게 돌아오는지 확인하는 코드가 전부가 되버린 것입니다. 

적용 후 얻게된 이점

아마 이 항목 때문에 글을 적겠다고 마음을 먹었던 것으로 생각됩니다. SI는 항상 시간에 쫒깁니다. 왜?? 라는 의문은 언제나처럼 고객의 요구사항이 변경되기 때문이라는 획일적인 답변으로 돌아오게 됩니다. 따라서 개발자들은 고객의 요구사항의 변경이 내 코드에 어떤 변화를 주는지 밥먹듯이 확인해야 합니다. 이때 미리 작성했던 테스트코드가 큰 힘이 됩니다.
새로운 요구사항을 받아 정신없이 코드를 수정하고 나면 이것이 정상 동작하는지 전체 테스트케이스를 실행해봅니다. 그러면 내가 모르게 영향을 준 코드에서 테스트가 실패하게 됩니다. 이런 과정이 결과적으로 개발자의 시간을 아끼게 해주는 선순환이 된다고 느끼게 되었습니다.

테스트 코드가 시간을 뺏는다고 생각하는 사람들은 조금 더 프로젝트를 멀리서 보길 바랍니다. 단기적으로는 불필요하게 시간을 뺏는 코드들이, 장기적으로는 야근없이 퇴근할 수 있게 해주는 원동력이 되기 때문입니다.

마치며

제목은 TDD 실천기라고 적었지만, 사실 TDD라고 할 수 없습니다. 개발의 중심은 테스트가 아니였기 때문이고, 단위 테스트를 '진짜' 단위로 쪼개지도 않았습니다. 그래도 넓은 개념에서는 TDD라고 생각하기에 제목은 이대로 유지할 생각입니다.

아마 다음 실천기는 통합테스트기간에 들어가면 적을 것 같지만, 그때까지 계속해서 테스트코드를 작성해 나갈 것입니다.

오늘도 이 글을 읽어주셔서 감사합니다. :)