안타깝게도 오늘의 TDD는 실패한 것 같군요. 내일은 가능할지도...? | 인프콘2023

인프런 inflearn·인프콘 2023 2023·2023년·

#refactoring#testing#backend#frontend#incremental-design#problem-solving#test-driven-development

AI 요약

TDD를 규칙 암기가 아니라 '원하는 결과에서 현재 상태로 거슬러 내려오는 거꾸로 연구하기'라는 문제 해결 패턴으로 재해석한다. 실패 테스트로 목표를 선언하고 답이 이미 있다고 가정한 뒤 그 전제를 질문하며 문제를 작은 단위로 분해하는 사고 흐름을, 여러 예제로 반복해 보여준다.

핵심 포인트

거꾸로 연구하기는 결과가 이미 만들어졌다고 가정하고 직전 조건을 역추론하는 방법으로, 9L·4L 물통으로 6L 만들기처럼 답에서 출발해 필요한 중간 상태를 하나씩 정의한다
실패 테스트=결과 선언, 최소 통과 코드=답을 이미 찾았다는 가정, 리팩터링=그 결과의 전제 질문으로 대응. 최빈 단어 찾기에서 정답 문자열을 먼저 반환한 뒤 정렬된 빈도 목록·빈도 객체로 거꾸로 축소
React/Redux 화면을 먼저 렌더링하게 만든 뒤 상태→비동기 액션으로 역추론하고, S3·API Gateway·CORS 같은 인프라도 최종 템플릿 반환부터 역분해. 목표가 모호하면 작은 목표로 시작해 이해가 생길 때 재정의

왜 읽나TDD를 어디서 시작할지 막막한 개발자에게, 테스트 사이클을 문제 해결 사고의 도구로 익히는 관점 전환을 준다.

챕터별 상세

010:05 – 4:00

우연한 해결을 반복 가능한 학습으로

TDD를 배우고 싶지만 어디서 시작할지 모르는 개발자를 위해 문제를 푸는 방식 자체를 연습하는 관점을 제안한다. 문제는 바라는 상태와 현재 인식의 차이이고 해결은 그 간격을 좁히는 일이지만, 시행착오 끝의 우연한 성공만으로는 다음 문제에 방법을 재사용하기 어렵다. 다양한 문제를 체계적으로 풀어 해법의 구조를 기억해야 새로운 상황에서도 이전 경험을 꺼내 쓸 수 있다.

거꾸로 연구하기는 원하는 결과가 이미 만들어졌다고 가정하고 그 직전에 어떤 조건과 과정이 있었는지를 현재 상태까지 역으로 찾는 방법이다. 9L와 4L 물통으로 6L를 만드는 문제에서 먼저 9L에서 3L를 덜었다고 놓고, 3L 공간을 만들기 위한 1L 상태를 다시 추론한다. 답에서 출발해 필요한 중간 상태를 하나씩 정의하면 무작위로 물을 옮기는 대신 설명 가능하고 다른 문제에 적용할 수 있는 해결 경로가 생긴다.

실패 테스트는 요구 결과를 선언하고, 최소 코드로 통과시키는 단계는 답을 이미 찾았다고 가정하며, 리팩터링은 그 결과가 어떤 전제에서 왔는지 질문하는 과정과 대응한다. 가장 자주 나온 단어를 찾는 예제에서 정답 문자열을 먼저 반환한 뒤 정렬된 빈도 목록, 빈도 객체와 문자열 분리로 거꾸로 내려가며 문제를 축소한다. 각 단계의 사용법과 기대값이 이미 테스트 역할을 하므로 작은 함수를 추출하고 구현을 일반화해도 전체 결과가 유지되는지 즉시 확인할 수 있다.

레스토랑 목록 컴포넌트가 원하는 화면을 먼저 렌더링하게 만든 뒤 목록이 상태에서, 상태가 비동기 API 액션에서 왔다고 역으로 추론한다. Redux Provider와 preloaded state, reducer와 dispatch를 필요한 순간마다 추가하면서 테스트 실패를 다음 작은 구현 단계의 안내로 사용한다. UI·상태·네트워크를 한꺼번에 설계하지 않고 각 결과의 출처에만 집중해 컴포넌트와 액션의 책임을 점진적으로 분리한다.

컴포넌트를 검증해 S3에 저장하고 API Gateway와 CORS·도메인·템플릿을 연결하는 복잡한 요구도 최종 템플릿 반환부터 시작해 URL 생성, 게이트웨이와 저장 기능으로 역분해한다. 실패 테스트로 희망 사항을 쓰고 복잡한 부분은 이미 구현됐다고 가정한 뒤 하나씩 실제 코드로 바꾸면 큰 문제를 집중 가능한 작은 문제로 줄일 수 있다. 목표가 모호하면 작은 목표로 시작해 이해가 생길 때 다시 정의하며, TDD 패턴을 익히는 경험은 다른 설계와 문제 해결 패턴을 발견하는 기반이 된다고 강조한다.