Week 1. 모든 게 처음이었다.

하나부터 열까지 다 생소했다.

 

3년 넘게 전자정부프레임워크 기반 스프링프레임워크만을 사용하며,

형상관리는 SVN 통해 진행하다 보니 스프링 부트와

깃허브는 손에 익지 않아 어색하기만 했다.

 

이름들만 들어봤던 레디스, 카프카, 살짝 발만 담갔던 도커,

그리고 클로드 코드 첫 결제까지.

 

통계 자료나 보고서 형식의 화면 단위를 개발하다 보니,

레거시 코드에서 새롭게 추가하거나 변형을 하기에는 어려움이 있어 

약간의 조회 속도 개선이나 코드 경량화 외에는 계속해서 쿼리만 작성했다.

 

그렇기에 발제를 듣고 프로젝트를 열어봤을 땐 한 없이 막막하기만 했다.

 

사실 신청 이전에 전기수들의 WIL을 훑어보고,

어떤 커리큘럼으로 진행되겠구나 정도는 파악하고 왔다.

 

하지만 막상 귀로 듣고 눈으로 보고 있자니,

'저 사람들이 무슨 말을 하는 거지', '뭘 알아야 질문을 할 텐데' 같이 다양한 생각이 들더랬다.

 

발제에 대한 과제 제출 기한은 일주일, 그 안에 PR과 Tech Note 작성을 끝내야 한다.

 

프로젝트 전체 구조부터 이해해야 할까? 클로드 코드 사용 방법부터 익혀야 할까?

TDD의 개념부터 알아야 할까?어디서부터 시작할지 고민은 커졌으나

데드 라인은 금방이었다.

 

에라 모르겠다 그냥 머리부터 집어넣기로 했다.

 

--

 

방대한 양의 내용은 머리를 과부하 상태로 만들기에 돌아가더라도 시작은 가벼운 게 좋다.

 

일단 TDD가 뭔지 제미나이에게 물어보니 테스트 주도 개발의 약자로,

기능 구현보단 테스트를 시작점으로 코드를 작성하는 것이라더라. 

 

그럼 왜 테스트를 우선 하는 건지도 물어보니

'요리를 하면서 중간중간 맛을 보는 것과 비슷하다.'라고 간단하게 설명해 줬다.

 

제미나이 답변

 

테스트 순서는 '실패 > 성공 > 다듬기'로, 대강 머릿속에 전체 흐름이 그려지긴 했다.

 

동시에 여러 의문점도 생겨났지만 이 의문들을 그대로 가지고

다음 단계인 발제 정독 및 다시 보기로 진입했다.

 

--

 

"단위/통합/E2E 테스트는 이론만 알지 실제 활용은 전무했다"라고 생각했지만 이론도 몰랐다고 봐야 했다.

 

외부 의존성을 제한하고 오로지 내부 로직으로만 규칙을 검증하는 단위 테스트,

외부 의존성을 살려서 실제와 동일한 구성으로 전체 흐름을 검증하는 통합 테스트, 

HTTP 요청부터 DB 접근까지의 전 과정을 검증하는 E2E 테스트.

 

스프링 부트 구조에 익숙지 않다 보니 Facade나 Annotation은 막 와닿지 않았으나

그건 구현 단계에서 이해하면 되었다.

 

실무에선 개발 혹은 로직 변경 요청 건이 들어오면 특정 샘플 몇 개만 골라 잘 나오게 개발한 뒤, 

실사용자가 건네준 데이터랑 검증 후 미처 잡지 못한 예외 케이스들을 잡아낸다.

 

물론 느슨한 환경에선 이런 방법 자체도 틀리진 않을 거다.

다만, 보다 정확하고 치밀한 개발 환경이 된다면 로직 수정이 빈번하게 발생할 수 있다.

 

처음 설계와 테스트부터 꼼꼼하게 잡고 가면 추후의 수고가 덜하니 당연한 방법이긴 하다.

 

테스트 더블은 각 테스트별 사용되는 객체인데,

이 또한 구현 단계에서 코드를 봐가며 이해하기로 했다.

 

그럼 왜 실패 테스트를 우선 하는가에 대한 의문을 풀어 볼 차례였으나

이때까진 명확한 답이 나오지 않아, 개발 단계로 넘어갔다.

 

--

 

코드 작성도 머리부터 들이밀었다.

 

우선 실패 테스트 케이스를 몇 가지 던져주고 테스트 코드를 작성하게 한 뒤

기능을 구현하고 검토를 진행했다.

 

클로드 코드는 똑똑하게 알아서 잘 만들어준다. 

다만 그 한계를 어디까지 끌어올릴 수 있을지는 내 프롬프트 작성 능력에 달렸다.

 

구멍이 송송 나 있는 허술한 코드를 보고, 롤백 후 구체적인 요구사항 작성을 시작했다.

 

테스트 우선 개발이기에, 각 파리미터별 유입될 가능성이 있는 테스트 케이스 목록을 작성한 뒤

적당한 기준점을 두어 걸러냈다.

 

목록을 끄집어낼 때, 기준점을 세워 몇 가지 케이스만 걸러낼 때,

보다 많은 테스트 케이스를 생각해두어야 하는 건지 고민을 많이 했다.

 

하지만 유지보수 측면에선 과한 것보단 적당한 게 좋기 때문에 적정선을 생각하여 정할 수 있었다.

 

 

요구사항 명세 작성

 

작성된 요구사항을 바탕으로 테스트 코드 작성 후 그에 맞는 기능 구현,

추가할 만한 테스트가 없는지 재확인 후 추가를 반복하다 보니 단단한 코드가 되었다.

 

여기서 주의할 점은 각 계층에 맞는 테스트 코드가 잘 작성되었는가를 확인하고,

중복 테스트 존재와 삭제 여부를 판단하는 것이다.

 

테스트 코드 작성 > 기능 구현 순서로 개발을 진행하니,

익숙지 않던 구조들도 점차 눈에 익어 전체 흐름을 파악할 수 있었다.

 

--

 

실제 코드 구현까지의 과정과 여러 팀들의 멘토링을 통해

실패 테스트부터 시작하는 이유를 나만의 결론으로 도출할 수 있었다.

 

결국 실패부터 테스트해 보는 습관은 복잡한 프로젝트 구조 속에서도 길을 잃지 않게 해주는 이정표와 같다.

기능을 만드는 데 급급하기보다 무엇을 어떻게 검증할지 먼저 고민하는 과정이 쌓이면서,

결과적으로 더 견고하고 유연한 설계를 고민할 수 있는 토대가 마련될 것이다.

 

또한 TDD는 코드의 퀄리티를 높이기 위함이며,

AI Agent가 구현한 코드를 보고서 내가 짜도 이렇게 짜겠다 싶으면 넘어가고

그렇지 않다면 의문을 갖고 끝까지 물고 늘어지는 습관이 필요하지 않나 싶다.

 

 

 

 

* 글에 형식은 없다. 그냥 의식의 흐름에 따라 끄적일 거다.

** Tech Note: https://byun-dev97.tistory.com/1