[루프백] 1주차 WIL(What I Learned)

✨ WIL은 왜 쓰는 걸까?
매주 배운 걸 기록하거나, 돌아보지 않으면 금방 잊히곤 합니다.
그래서 루프팩에서는 기술적인 개념 + 내가 느낀 점을 글로 정리해보는 습관을 만들어 갈 거예요.
그냥 단순히 회고가 아니라, 아래와 같이 학습하고, 체화한 흐름을 나만의 언어로 써보는 게 핵심이에요.

📌 무엇을 중점적으로 학습했는지
📌 어떤 것이 특히 헷갈렸는지
📌 결국 어떻게 이해하게 됐는지

---

이번 주에 새로 배운 것 + 이런 고민이 있었어요

 

1.  TDD (Test Driven Development)

 

미루고 미루던 테스트 주도 개발에 대해 학습하고, TDD를 사용해서 프로젝트를 진행했다.

 

▸ Red/Green/Refactor 사이클

테스트 먼저 → 구현 → 리팩토링 단계를 직접 개발해보면서 Claude Code와 함께하면 어떤 장점이 있는지에 대해서 많이 고민했다.

👉 TDD에 대한 포스팅 보러가기

 

▸ 컴파일 에러도 Red인가?

정확히 테스트를 먼저 작성하는 뜻에 대해서 이해하지 못하고 있었다. 그래서 Claude를 통해 요구사항을 주고 Red 단계를 먼저 요청했는데, 컴파일이 다 깨지는 코드를 주는 것이 아닌가?

 

내가 생각한 실패하는 코드의 기준은 "컴파일은 되어야 하는 코드"라고 생각했기 때문에 다소 헷갈렸던 것 같다.

 

Claude는 컴파일 에러도 Red 단계의 일부이고, Green 단계에서 문제를 해결하면 된다고 한다.

 

그런데 멘토링 시간에 팀원분께서 "DTO나 도메인 객체가 전혀 없는 상태에서 TDD를 시작할 때, 먼저 임시 인터페이스나 객체를 정의하고 테스트를 작성하는 방식이 맞는 접근일까요?"라는 질문을 하셨고, 그렇게 접근할 수 있겠구나라고 배우게 되었던 것 같다.

 

▸ TDD 커밋 전략

기능 완성 후 한 번에 커밋을 하는 게 맞는 걸까? 아니면 TDD 과정을 하나씩 커밋하는 게 좋은 걸까?

 

결론은 동시 작업에서는 완성되지 않은 테스트 코드는 누군가에게 혼란을 가져올 수 있다고 생각했다. 따라서 TDD 단계에서는 최소 Green 단계 이후에 커밋을 하는 것으로 결론지었다.

 

2.  테스트 종류

▸ 테스트 피라미드

단위 > 통합 > E2E (단위 테스트를 가장 많이 작성하고 통합, E2E 순으로 적게 작성)

 

왜? 단위는 빠르고 디버깅이 쉽지만, E2E로 갈수록 느리고 실패 원인을 찾기 어렵기 때문이다!

 

▸ 단위 테스트

하나의 클래스, 메서드를 격리해서 테스트하기 위해 Mock에 대해 학습하는 시간을 가졌고, Mock으로 의존성을 격리시켜 테스트 코드를 작성했다.

 

▸ 통합 테스트

Docker에 올린 예제 MySQL 환경에서 테스트를 진행했다. @SpringBootTest를 사용해서 여러 컴포넌트가 함께 동작하는지를 검증했다.

 

 현재까지 내가 회사에서 작성하고 있던 테스트 코드는 대부분이 통합 테스트였다는 것을 알았고, 단위 테스트와 테스트의 기능(범위?)이 분리되니 내가 테스트하고자 하는 개념이 좀 더 명확해진 것 같다.

 

▸ E2E 테스트

클라이언트 관점에서 전체 흐름을 검증하는 단계인데, 사실 처음 해봤다.

 

실무에서는 열심히 Swagger 접속해서 API 호출해가면서 테스트했었는데, 확실히 E2E 테스트로 진행하니 더 명확하고 엄격한 기준의 테스트가 가능하고, 테스트 코드를 잘못 작성하지 않는 한 실수할 확률이 적을 것 같다고 생각했다.

 

3.  테스트 더블

실제 객체 대신 테스트용으로 사용하는 가짜 객체이다.

 

Stub, Mock, Fake, Spy, Dummy 등의 종류에 대해 학습했고, 그중 특히 Stub과 Mock의 차이점과 사용하는 경우에 대해서 집중했다.

 

Stub	Mock
값을 검증	실행(호출)을 검증
whenever().thenReturn()	verify()

 

이번 1주차 프로젝트에서는 verify()를 사용하는 상황들이 대부분 assertThat()으로 검증되는 경우였기 때문에 Stub만 사용했던 것 같다.

 

4.  테스트 코드 작성

테스트 코드에 사용되는 어노테이션에 익숙해지는 시간을 가졌다.

@Nested + inner class	@DisplayName	@Testcontainers
테스트 그룹화	테스트 설명 한글 작성	통합 테스트용 실제 DB 환경

 

5.  아키텍처

헥사고날 스타일 레이어드	interfaces / domain / infrastructure 분리
Port & Adapter	인터페이스(domain) + 구현체(infrastructure)
Facade 패턴	다른 도메인 조합 시 사용 (같은 도메인이면 불필요)

 

예제 프로젝트의 아키텍처가 내가 지금 회사에서 사용하는 구조와는 약간 다른 스타일이었다.

 

좀 더 도메인 간의 역할을 확실히 구분하는 방법인 것 같은데, 도메인이 깔끔하게 분리되어 있으니까 테스트하기 쉬우면서 기술 변경에 유연할 수 있겠다는 생각을 했다.

 

6.  AI + TDD 시너지

TDD에 대한 포스팅에 생각했던 점을 명확히 적어두었다. 👉 TDD에 대한 포스팅 보러가기

 

요약하자면 Red 단계에서 Claude가 사람이 생각하지 못했던 부분까지 경계값/예외 케이스를 촘촘하게 생성하기 때문에 큰 이점이 있다고 느꼈다.

 

Red 단계가 잘 작성되어 있을수록 바이브 코딩의 퀄리티가 높아질 것이라고 생각하기 때문이다.

 

---

 

앞으로 실무에 써먹을 수 있을 것 같은 포인트

 

1. 앞으로 실무에서 신규 API 개발할 때는 TDD를 사용할 것 같다. 스스로 막막하게 생각했던 기술을 팀원들과 함께 학습하고, 명확한 장점을 느끼다 보니 자신감이 생긴 것 같다.

 

2. 시간이 있을 때마다 이미 테스트 없이 작성된 API에 E2E 테스트를 적용해볼 예정이다. 단위 테스트 또는 통합 테스트를 위해 기존 레거시 코드의 구현을 변경하는 것은 너무 리소스가 클 것 같아서 우선 그 정도 해볼 생각이다.

 

---

 

아쉬웠던 점 & 다음 주에 해보고 싶은 것

사실 TDD나, 코틀린이나, 헥사고날, Facade, Claude 모든 게 익숙하지 않은 상태였다.

 

회사 업무를 끝내고 집중력이 많이 떨어진 상태여서 몰입력이 부족했던 것 같다.

 

AI의 발전과 함께 깊게 아는 것보다 넓게 아는 것이 중요해지는 시기이지만, 그 말이 대충 알고 사용하라는 말은 아니라는 것을 잘 안다.

 

다음 주 과제를 진행하면서는 이번 주에 진행했던 내용들을 하나하나 복기해가며 완벽히 이해한 프로젝트를 만들어가는 것이 목표다. 🔥