우아한테크코스는 TDD(Test-Driven Development, 테스트 주도 개발) 를 굉장히 중시하는 교육 과정이라고 들었다.
여러 기수의 선배들이 공통적으로 “TDD"라는 키워드를 강조하였고
나도 예전부터 TDD에 관심이 많았다.
단순히 “테스트를 작성하는 기법”이 아니라, 문제를 정의하고 테스트를 통해 구현을 이끌어가는 사고방식이라는 점이 마음에 와닿았다.
그래서 언젠가 꼭 프로젝트에 TDD를 적용해 보고 싶다고 생각했었다.
그래서 이번 8기 프리코스에서 TDD를 익혀보는 걸 목표로 삼았다.
막막했던 첫 시도
프리코스 첫 미션은 문자열 덧셈 계산기였다.
TDD로 풀겠다고 마음먹었지만 막상 시작하려니 손이 쉽게 움직이지 않았다.
“작은 단위로 테스트를 만들고, 통과시키면서 점진적으로 구현을 완성해간다.”
이 문장은 머리로는 알겠는데, 실제로는 너무 막연했다.
그래서 방향을 바꿨다.
구현보다 먼저 요구사항을 세세하게 분해하는 것부터 시작했다.
“빈 문자열이면 0을 반환한다.”
“커스텀 구분자가 있다면, 해당 구분자 기준으로 분리한다.”
이렇게 한 줄씩 쪼개다 보니 자연스럽게 테스트의 단위가 눈에 들어왔다.
그제야 깨달았다.
TDD의 첫걸음은 테스트 작성이 아니라 문제 정의라는 걸.
Red–Green–Refactor의 리듬
요구사항을 나눈 뒤엔, 그중 가장 단순한 기능부터 테스트를 작성했다.
실패하는 테스트를 먼저 확인하고, 그걸 통과시키는 최소한의 코드를 작성했다.
책에서 배웠던 Red–Green–Refactor 사이클을 그대로 따라갔다.
이 과정을 반복하다 보니 점점 속도가 붙었다!
테스트가 잡아낸 의외의 예외들
테스트를 작성하며 TDD의 진짜 힘을 체감한 순간들이 있었다.
예를 들어 정규식을 다루던 중, 커스텀 구분자를 대괄호([])로 감싸는 정규식을 사용했을 때
contains() 함수가 의도치 않게 동작하는 문제가 생겼다.
테스트가 없었다면 이건 실제 실행 단계에서나 발견됐을 문제였다.
또 역슬래시(\) 같은 정규식 문자를 커스텀 구분자로 쓸 때도 예외가 발생했다.
테스트를 통해 이런 문제를 조기에 발견했고,
Pattern.quote(customDelimiter)로 감싸 안전하게 처리해줬다.
테스트 덕분에 예외 상황을 미리 예측하고 대비할 수 있었다.
리팩터링이 두렵지 않게 된 이유
리팩터링 단계에 들어서면서 TDD의 진가가 드러났다.
테스트가 든든히 받쳐주니, 코드를 바꾸는 게 두렵지 않았다.
이전에는 코드를 고칠 때마다 전체를 다시 실행해보고,
결과를 눈으로 일일이 확인해야 했다.
하지만 이제는 “리팩터링 → 테스트 실행” 한 번으로 바로 검증할 수 있었다.
그 덕분에 코드의 안정성을 유지하면서 구조 개선에만 집중할 수 있었다.
무엇보다 ‘깨지지 않을 코드’를 작성하고 있다는 자신감이 생겼다.
이건 이전의 나에게 없던 감정이었다.
동료들과 나눈 TDD의 리듬
현재 나는 우테코 참가를 위한 스터디에 참여하고 있다.
스터디원 중에는 아직 TDD가 낯설고 어렵게 느껴지는 사람들이 많았다.
그래서 내가 먼저 Red–Green–Refactor 사이클과
Given–When–Then 테스트 구조를 직접 설명해줬다.
테스트를 단순한 검증 도구가 아니라, 요구사항의 명세서로 바라보면 훨씬 이해하기 쉽다는 점도 함께 공유했다.
그렇게 서로 피드백을 주고받으며, 동료들이 점점 테스트를 자연스럽게 작성하기 시작했다.
그리고 나 역시 내가 배운 개념을 직접 설명하며 더 깊이 이해할 수 있었다.
도메인의 책임을 고민하다
이번 프리코스를 하면서 ‘도메인의 역할’에 대해서도 많이 고민했다.
이전에는 도메인을 단순히 데이터를 담는 객체로만 생각했는데,
테스트를 작성하다 보니 비즈니스 로직이 서비스 계층에 흩어져 있어서 테스트하기가 어렵다는 걸 깨달았다.
그래서 객체지향의 원칙에 맞게, 각 도메인이 자기 책임을 수행하도록 구조를 바꿨다.
그 과정에서 팩토리 메서드의 필요성도 느꼈다.
처음엔 생성자에서 모든 검증을 처리했는데,
규칙이 많아질수록 생성자가 지나치게 복잡해졌다.
하나의 생성자가 검증과 초기화를 모두 맡다 보니 책임이 불분명해졌고, 테스트도 불편했다.
그때 떠올랐다. 『이펙티브 자바』 1장의 조언.
“생성자 대신 정적 팩토리 메서드를 고려하라.”
그래서 from()이나 of() 같은 정적 팩토리 메서드를 도입했다.
검증은 팩토리에서 처리하고, 의미 있는 이름으로 의도를 드러내는 생성 구조를 만들었다.
이후 테스트가 훨씬 명확해졌고, 책임도 분리됐다.
1주차 주요 피드백!
- 메서드 이름 동사로 짓기 : 나도 모르게 명사로 메서드 이름을 지어서 깜짝 놀랐다! 앞으로 의식적으로 이름 짓는 연습을 해야할것 같다.
- 스트림 엔터치기 : 이건 안좋은 습관이 들어버린 예인데, 예전부터 자바 스트림 숙련도를 올리기 위해 프로그래머스 0렙을 한줄로 푸는 연습을 한 적이 있다. 이것도 의식적으로 사용해야겠다!
- Console.close() 사용 : 이것도 사소하다면 사소할진 몰라도 실제 프로그래밍에선 사이드이펙트가 엄청 크게 오는 행위중 하나일 것이다.1주차야 가벼운 프로그램이니 콘솔을 닫아서 아무 문제 없어도 해제 되지 않은 자원들이 계속 쌓일테니 의식적으로 닫아줘야겠다.
- 일급 객체를 사용했는데 사용이 아쉬운것 : Operand를 관리하는 Operands 객체를 만들었지만 그 책임을 온전히 다 가지고 있지 않은것이 아쉬운 것 같다. sum같은 역할을 맡겨도 됐을것 같기도 하고 일급 객체에 대해 좀 더 공부해서 2주차에 적용해보겠다.
- 추가 확장하지 않으면 무분별한 분리를 하지 말것 : 주로 메소드를 분리하는 이유는
1. 가독성을 위하여
2. 재사용을 위하여
일텐데 내가 분리한 parseToInt는 그 둘에도 해당하지 않는다는 피드백이 들어왔다. 앞으로 분리를 할때는 어떤 목적이 있는지, 어떤 효과가 있는지를 잘 살펴보고 분리해야겠다.
앞으로의 목표 — TDD와 설계의 연결고리
1주 차를 마치며 새로운 배움의 즐거움을 느꼈다.
하지만 한계도 분명했다.
테스트와 설계를 유기적으로 연결하는 아키텍처적 사고는 아직 멀게 느껴진다.
그래서 남은 프리코스 기간 동안은
『클린 아키텍처』를 공부하고, 객체들이 서로 조화롭게 협력하는 구조를 설계하는 감각을 익히고 싶다.
또 2주차부터는 받은 피드백을 적용하고 켄트 벡의 『테스트 주도 개발』을 다시 읽으며
테스트가 설계를 어떻게 이끌어가는지를 더 깊이 이해하고 싶다!
'외부활동 > 우아한테크코스 8기 프리코스' 카테고리의 다른 글
| 우아한테크코스 프리코스 4,5주차 회고 (0) | 2025.11.25 |
|---|---|
| 우아한테크코스 프리코스 8기 3주차 회고 (0) | 2025.11.24 |
| 우아한테크코스 프리코스 8기 2주차 회고 (0) | 2025.11.01 |