[WIL] TDD로 회원가입/내정보조회/비밀번호 변경 구현

이번 주에 무엇을 학습했나

이번 주 과제의 주제는 TDD였고, 회원가입 / 내정보조회 / 비밀번호 변경 기능을 구현하는 것이었다.
스프링은 작년에 잠깐 접해보고 다시 시작하는 상황이라, 과제를 처음 봤을 때 가장 먼저 든 생각은
“도대체 TDD를 어디에 어떻게 넣으라는 거지?”였다.

프론트부터 만들지 말고 서버부터 구현하라는 요구사항도 부담이었다.
기존에는 화면 흐름을 기준으로 생각하면서 개발을 시작했는데, 그 기준이 사라지니까 손을 대기가 어려웠다.
예제 구조를 봤을 때 파일이 너무 많아 보여서, 시작도 하기 전에 해야 할 게 너무 많은 것처럼 느껴졌다.

처음에 가졌던 생각과 오해

과제를 시작하면서 머릿속에 계속 맴돌았던 생각은 “뭘 먼저 해야 하지?”였다.
솔직히 하기 싫다는 감정도 컸고, “내가 이걸 왜 또 한다고 했을까”라는 생각 때문에 짜증도 많이 났다.

README를 읽고 프로젝트를 실행해봤는데, localhost:5555에 접속하니 JSON만 떠서
“이거 에러 난 거 아니야?”라는 의심이 먼저 들었다.
회원가입 기능을 만들기도 전에 환경과 흐름이 낯설어서 진입장벽이 크게 느껴졌다.

해보면서 부딪힌 지점

회원가입부터 해야겠다고는 생각했지만, 실제로 코드를 쓰려고 하니 막막했다.
테스트부터 작성하라는 점도 부담이었고,
“도메인에 기능을 넣으라”는 말이 구체적으로 무엇을 의미하는지 잘 와닿지 않았다.

특히 서비스, 도메인, 엔티티의 역할 경계가 머릿속에서 정리되지 않아서
클래스를 열어두고도 한동안 아무것도 하지 못한 시간이 있었다.

접근 방식을 바꾸게 된 계기

먼저 같이 공부하는 사람에게 “이게 이렇게 뜨는 게 맞아?”라고 물어봤고,
JSON이 뜨는 것이 에러가 아니라 정상 동작이라는 걸 확인하면서 불안을 조금 내려놓을 수 있었다.

그 다음부터는 프론트 화면 대신, 사용자 흐름을 머릿속으로 그려보기 시작했다.

회원가입 페이지에서 정보를 입력하고 버튼을 누르면
API 요청이 들어오고, 컨트롤러를 타서 서비스로 넘어가고,
결국 DB에 저장되는 흐름일 거라고 생각했다.

이 과정에서
“회원가입 시 검증은 비즈니스 로직이고,
비즈니스 로직은 도메인에 두라는 의미였구나”라는 연결이 되었다.

그래서 member 도메인 엔티티를 만들고,
회원가입 시 검증해야 할 로직들을 그 안에 넣는 방식으로 구현을 시작했다.
이 구조를 정리하는 과정에서 Claude의 도움도 많이 받았다.

지금 시점에서 이해한 TDD와 구조

예전에는 Mock, Stub, assertThat 같은 것들이
익숙하지도 않고 뭔지 잘 모르겠는 도구처럼 느껴졌는데,
이번에는 예제를 보면서 따라 해보니 조금씩 이해가 되기 시작했다.

특히 다음과 같은 경계가 인상 깊었다.

• DB와 연결해서 검증해야 하는 로직은 서비스에서 처리하고, 서비스 테스트에서 검증한다.
• 컨트롤러로 들어오기 전후에 사용하는 객체와, DB와 직접 연결되는 엔티티는 분리한다.

E2E 테스트는 솔직히 너무 하기 싫어서 Claude의 도움을 받아서 만들었지만,
그 과정에서도 전체 흐름을 한 번 더 정리해보는 계기는 되었다.

아직 TDD를 완전히 이해했다고 말하기는 어렵지만,
테스트가 단순한 검증 코드가 아니라 설계를 정리하게 만드는 도구라는 감각은 조금 생겼다.
또 프론트 기준이 아니라, 서버 안에서 컨트롤러를 따라 흐름을 볼 수 있겠다는 생각도 들었다.

아쉬웠던 점과 다음 주 목표

멘토링 시간에 팀원들이 질문할 때는
“왜 저런 질문을 하지?”라고 생각했던 적이 있었는데,
막상 내가 과제를 직접 해보니 나중에서야
“아, 이래서 이런 질문이 나오는 거구나”라는 걸 이해하게 되었다.

결국 내가 과제를 늦게 시작해서,
팀원들의 질문이 어떤 맥락에서 나온 건지 따라갈 여유가 없었던 것 같다.

다음 과제는 조금 더 빨리 끝내서,
팀원들이 질문할 때 왜 그런 질문이 나왔는지,
어디에서 막혀서 그런 질문이 생긴 건지를 이해한 상태로 참여해보고 싶다.