BDD는 내가 가장 애착을 가지고 시도했던 방법론 중 하나다. 테스트를 통한 안정적인 코드 작성이라는 매력적인 약속 때문이었다. 하지만 이번 과제를 통해 그 도구를 제대로 다루지 못했을 때의 문제점을 뼈저리게 경험하게 되었다.
첫 도메인 개발: BDD의 빛나는 순간
첫 번째 도메인을 개발할 때는 시간이 걸리더라도 BDD 원칙을 철저히 지켰다. Given-When-Then 패턴을 따라가며 시나리오를 작성하고, 테스트를 먼저 작성한 뒤 구현하는 방식으로 진행했다. 결과적으로 안정적이고 견고한 코드가 완성되었다.
시간 압박과의 타협
하지만 첫 도메인 개발에 예상보다 많은 시간이 소요되면서, 남은 도메인들에 대해서는 BDD를 적용하지 않기로 했다. '일단 기능부터 빠르게 구현하자'는 조급한 마음이 앞섰던 거다.
회귀 버그의 고통
이게 웬걸, BDD를 적용하지 않은 도메인들에서는 지속적으로 회귀 버그가 발생했다. 하나를 고치면 다른 곳에서 문제가 발생하고, 그걸 고치면 또 다른 곳이 망가지고... 마치 두더지 잡기 게임을 하는 것 같았다.
뼈저리게 깨달은 BDD의 가치
아이러니하게도 이런 상황을 겪으면서 오히려 BDD의 진정한 가치를 깨달을 수 있었다. BDD를 적용한 도메인과 그렇지 않은 도메인의 품질 차이가 확연했거든. BDD는 단순한 테스트 방법론이 아니라, 안정적인 소프트웨어를 만들기 위한 필수적인 실천 방법이었던 거다.
앞으로의 계획
현재는 만족스럽지 못한 결과물이지만, 이대로 멈추지 않으려고 한다. DDD(Domain-Driven Design) 관련 학습을 마저 완료한 후, 전체적인 리팩토링을 진행할 계획이다. BDD와 DDD를 제대로 적용하여 더 나은 설계와 구현을 만들어내고 싶다.
교훈과 아쉬움
꼭, 꼭!!! 가고싶었던 회사인 만큼, 과제를 진행하면서 아쉬움이 컸다. BDD와 같은 새로운 방법론을 제대로 학습하고 적용할 시간이 부족했다.
조금 더 일찍 준비를 시작했다면, 혹은 학습할 시간이 더 있었다면 어땠을까 하는 생각이 든다.
이번 경험을 발판으로 더 체계적으로 공부하고 준비해서, 다음에는 더 나은 결과물을 만들어내고 싶다.
