루퍼스 백엔드 코스 1주차 회고 - 테스트 주도 개발, 그리고 소통의 도구
올해 안에 개발 스킬에 대한 갈증을 해소하고 싶었다. 무언가 부족하다는 감각은 있었지만, 그걸 어디서부터 채워야 할지 잘 몰랐다. 그러다 루퍼스 백엔드 코스를 알게 됐고, 고민 없이 신청했다. 1주차 주제는 테스트 주도 개발이었다.
회사에서 받은 피드백 중 기억에 남는 게 있다. "현우님은 여러 관심의 포인트를 가지실 때가 아닌 것 같아요, 기본부터 합시다", "지금 기술적인 공부를 할 때가 아닌 것 같아요." 이 문장들이 꽤 오래 머릿속에 남아 있었다. 영어 대문자처럼 머리에 각인된 기분이었다.
내가 부족하다는 건 알고 있었는데, 그게 구체적으로 어떤 부분인지 설명하기 어려웠다. 코드를 작성하는 능력인지, 설계 감각인지, 아니면 일하는 방식 자체인지. 여러 가지가 섞여 있는 느낌이었다. 어쨌든 바꿔야 한다는 건 분명했다.
이번 주에 운영 배포를 네 번 했다. 그중 결제 시스템 관련 배포가 기억에 남는다. 구독 멤버십 적용 조건과, 장소별 정책 적용 여부를 다루는 작업이었다. 문제는 이 규칙들이 정책으로만 존재했다는 점이다. "이 정책은 8월까지만 유지한다", "특정 장소의 영업소는 포함한다" 같은 내용이 코드에도, 주석에도 드러나 있지 않았다. 게다가 이번 배포 전까지는 해당 정책이 실제로 적용되는 시점이 아니어서 문제가 없었다. 그러다 이번 배포에서 정책이 적용되기 시작하면서, 그동안 수면 아래에 있던 누락이 드러난 것이다. 타팀과 회의도 했고 지라(Atlassian JIRA)로도 소통했는데, 정책 문서에만 있고 코드에 반영되지 않은 규칙까지는 잡아내지 못했다.
같은 팀 동료가 이 문제를 엑셀로 풀었다. 구독 유형, 장소 정책 적용 여부, 결제 금액 같은 조건을 행과 열로 나열하고, 각 조합에 대한 예상 결과를 기록하는 방식이었다. 이 표를 보는 순간 빠져 있던 케이스가 바로 눈에 들어왔다. 개발자가 아닌 사람도 "이 조건이면 이 결과가 나와야 한다"를 바로 이해할 수 있었다. 소통 비용이 확 줄어드는 경험이었다.
1주차에 테스트 주도 개발을 배우면서 테스트 케이스 설계 기법이라는 주제를 접했다. 테스트 케이스는 소프트웨어가 예상대로 작동하는지 확인하기 위해 사용하는 조건과 단계의 묶음이다. 이걸 체계적으로 설계하는 방법이 여러 가지 있었는데, 결제 시스템 이슈를 떠올리면서 들으니까 하나하나가 와닿았다.
결제 시스템에서 겪었던 문제의 핵심은, 구독 멤버십 적용 여부와 장소 정책 적용 여부라는 두 가지 조건의 조합을 빠짐없이 확인하지 못한 것이었다. 이걸 의사결정표 테스트로 정리하면 이야기가 달라진다. 조건을 행과 열로 나열하고 모든 조합에 대한 기대 결과를 채워 넣으면, 빠진 케이스가 시각적으로 드러난다. 팀 동료가 엑셀로 했던 방식이 바로 이것이었다.
그리고 결제 금액에 대한 검증을 생각해 보면, 경계값 분석이 딱 맞는 기법이었다. 예를 들어 구독 할인이 적용되는 최소 금액이 정해져 있다면, 그 금액 바로 아래와 바로 위를 테스트해야 한다. 결함은 중간값보다 경계에서 더 자주 발생하기 때문이다.
구독 유형별 처리 방식이 다른 부분에는 동등 클래스 분할을 적용할 수 있었다. 월간 구독, 연간 구독, 체험 구독처럼 같은 할인율이 적용되는 유형끼리 하나의 그룹으로 묶고, 각 그룹에서 대표값 하나만 테스트하면 모든 값을 다 넣어보지 않아도 된다.
구독 상태가 변하는 흐름에는 상태 전이 테스트가 어울린다. 구독 활성, 일시정지, 해지, 만료처럼 상태가 이벤트에 따라 바뀌는 경우, 각 전이가 올바르게 동작하는지를 추적하며 테스트하는 방식이다.
마지막으로 오류 추측이라는 기법이 있었다. 과거 경험을 바탕으로 "여기서 문제가 생기겠다"고 예측하고 테스트하는 방식이다. 결제 시스템에서 겪었던 이슈도 결국은 "구독이 있는데 정책이 없는 장소에서 결제하면?"이라는, 경험에서 나온 의심이 출발점이었다. 이 기법은 경험이 쌓일수록 정확해진다는 점이 재밌었다.
1주차를 마무리하고 발제 세션에서 멘토님이 유비쿼터스 언어에 대해 이야기해 주셨다. 개발자와 비개발자가 같은 용어를 사용해서 오해를 줄이자는 개념이다. 완전히 처음 듣는 건 아니었고, 대충 알고는 있었다. 그런데 이번에 다시 듣는 타이밍이 좀 달랐다. 결제 시스템 배포 때 겪었던 소통의 어려움, 팀 동료의 엑셀 테스트 방식, 그리고 이번 주에 배운 의사결정표 테스트까지. 이 세 가지가 머릿속에서 겹쳐지면서 조금 개운해지는 느낌이었다. 팀 동료가 엑셀로 정리하던 방식이 바로 의사결정표 테스트였다는 것을, 그제서야 이름을 붙여서 이해하게 됐다. 같은 내용을 여러 번 말로 설명하는 것보다, 표 하나를 보여주는 것이 훨씬 명확하다. 이건 직접 경험으로 확인한 사실이다.
배운 내용을 바로 적용해 볼 기회가 있었다. 비밀번호 변경 기능을 구현하는 과제였다. 먼저 요구사항 문서를 작성하고, 구현을 다섯 단계로 나눠서 진행했다.
첫 번째 단계에서 비밀번호 검증 로직을 만들었다. 결제 시스템에서 배운 교훈을 살려서, 테스트 케이스 설계 기법을 의식적으로 적용해 봤다. 비밀번호 길이가 8자에서 16자 사이여야 한다는 규칙에는 경계값 분석을 썼다. 7자, 8자, 16자, 17자를 각각 테스트했다. 입력 문자 종류에 따른 검증에는 동등 클래스 분할을 적용했다. 영문만 입력한 경우, 숫자만 입력한 경우, 특수문자만 입력한 경우, 한글이 포함된 경우처럼 같은 결과를 내는 입력을 그룹으로 묶어서 대표값을 테스트했다. 생년월일 포함 여부, 연속 동일 문자, 연속 순서 문자, 로그인 아이디 포함 여부 같은 조건이 복합적으로 작용하는 부분에는 의사결정표를 활용했다. 이렇게 정리하니 테스트 케이스가 서른 개가 넘었다. 누구든 이 목록을 보면 비밀번호 규칙이 어떤 구조인지 파악할 수 있다.
그 다음 단계에서는 도메인 모델, 서비스, 파사드, 컨트롤러 순서로 구현했다. 매 단계마다 테스트 코드를 먼저 작성하고 실행해서 실패하는 것을 확인한 뒤, 그 테스트를 통과하는 최소한의 코드를 작성했다. 그리고 정리. 이 빨간불, 초록불, 정리의 반복이 테스트 주도 개발의 기본 흐름이다.
한 가지 더 느낀 점이 있었다. 요구사항 문서에 정리한 테스트 시나리오 표를 다른 팀에 보여주면, "이 기능이 정확히 무엇을 하는지"를 별도의 설명 없이 전달할 수 있을 것 같았다. 테스트 시나리오가 곧 기능 명세서이기도 한 셈이다.
이번 주를 돌아보면, 테스트 주도 개발은 코드 품질을 높이는 기법인 동시에 소통 도구이기도 하다는 생각이 든다. 테스트 케이스는 소프트웨어가 예상대로 작동하는지 확인하는 고정 핀 같은 것이라는 생각이 들었다. 코드를 수정해도 기존 동작이 깨지지 않는다는 걸 보장해 준다. 그리고 한번 작성한 테스트 케이스는 새로운 변경 사항이 생길 때 회귀 테스트용으로 재사용할 수 있다. 누가 실행해도 일관된 결과를 얻을 수 있다는 점도 크다. 버그를 찾는 것에서 끝나는 게 아니라, 품질과 신뢰성, 사용자 만족도까지 이어진다.
그리고 그 테스트 케이스를 표로 정리하면 다른 팀과의 소통 비용이 줄어든다. 말로 세 번 설명할 것을 표 하나로 대신할 수 있다. 회사에서 받았던 피드백, 배포 과정에서 겪은 소통의 어려움, 팀 동료의 엑셀 테스트 방식, 그리고 테스트 주도 개발 학습. 전혀 다른 맥락처럼 보였던 경험들이 1주차에 하나로 연결됐다.
참고자료.
- 대표 이미지: https://www.teamblind.com/kr/post/%ED%8C%90%EA%B5%90%EC%96%B4-%EA%B6%81%EA%B8%88%ED%95%9C%EA%B1%B0-%EC%9E%88%EB%8B%A4-jB5sW7Ju
- TDD 아티클: https://medium.com/@dev_90291/test-case-design-techniques-in-software-testing-d59a3e0dbc0e