방탈출 사이클3 공통 피드백 전달합니다!!

해당 내용 읽고 이따 10시 40분에 질문 답변 받을게요~

## 진단

여러분은 답을 모르는 게 아니라, 답을 평가할 기준이 비어 있어요.

PR을 보면 트레이드오프 표는 다들 잘 그려요. “Mock의 장단점은 이거고, 통합의 장단점은 이거다"까지는 갑니다. 그런데 거기서 판단의 기준이 없어서, “내 토론조 규칙이 맞나요?“를 묻는 형태로 PR이 올라옵니다. 답을 더 줘도, 도구 정의를 더 명확히 해도 같은 막힘이 반복돼요.

## 테스트마다 “무엇을 무엇으로부터 보호하는가"를 박고 시작하세요

위 질문의 답을 얻은 크루들은 아래와 같은 기준을 가지고 있었어요.

  • “테스트가 보호하는 건 ‘지금 옳다’가 아니라 ‘바꿔도 유지된다’는 회귀 안전성”
  • 검증 가치 × 작성·실행 비용, 두 축으로 각 계층을 선택
  • “각 계층의 책임이 진짜로 깨지는 방식으로 검증한다”
  • “도메인 테스트는 규칙 자체를, 서비스 테스트는 그 규칙이 흐름에 포함됐는지를”

정답을 알아낸 게 아니에요. 보호 대상을 먼저 박고, 거기서 도구를 역산한 겁니다. 보호 대상이 흐릿한 상태에서 논쟁을 길게 하면 결론이 안 납니다.

## Mock 논쟁은 도구 문제가 아니라 목적 문제입니다

PR에 같은 표현이 반복됐어요 — “내가 짠 대본대로 움직이는 가짜를 검증하는 느낌”, “프레임워크 동작을 흉내 내는 데 에너지를 쏟는 기분”. 정확한 감각인데, 그게 “Mock이 나쁘다"는 결론으로 가면 안 돼요. 보호 대상이 흐릿한 상태에서 Mock을 쓰면 도구가 의미를 잃을 뿐입니다.

Mock·Fake·통합은 각자의 자리가 있어요. 자리는 보호 대상이 정합니다.

## 토론조마다 4계층 매트릭스가 다른 건 정상 신호입니다

이번 사이클 패턴이 네 가지로 갈렸어요.

  • 표준 피라미드 — 계층별로 책임을 나눠 각자의 자리에서 검증
  • Mock 배제 통합 중심 — 실제 동작 보장에 무게
  • Controller 단위 생략 — 분기 없는 위임 계층은 E2E로 충분하다고 판단
  • DAO 모킹 금지 — SQL이 mock 뒤에 숨으면 검증 가치가 0

같은 보호 대상을 정해도 트레이드오프가 다르면 매트릭스가 달라져요. 정답이 하나일 수 없어요. 본인 페어가 무엇을 보호하기로 했는지를 박아두고, 거기서 매트릭스를 역산해 보세요.

안 해도 됨

  • “정답 4계층 매트릭스” 찾기 — 없습니다
  • 컨트롤러 단위 테스트를 무조건 두기 / 무조건 빼기 — 보호 대상이 정하면 답이 나옵니다
  • Mock 안 쓰기로 결정한 뒤 죄책감 갖기 — 통합으로 풀리면 Mock은 자리가 없어도 돼요
  • 모든 분기·메서드 다 테스트 — 보호 대상에서 멀어진 검증은 비용만 늘립니다

## 왜 테스트를 짜는가

PR에 이 질문을 주신 분들이 있어요. 테스트의 효용은 _지금 옳다는 증명_이 아니라 바꿔도 안 깨진다는 자신감입니다. 자신감이 없으면 코드 베이스가 커질수록 바꾸는 게 무서워지고, 무서워지는 만큼 시스템이 굳어요. 우리가 테스트를 짜는 이유는 변경 가능성을 사두는 거예요.

미션 규모에서는 이 효용이 잘 안 올 수 있어요. 그럴 땐 미션에서는 “회귀 안전성을 어떤 도구로 사야 가장 싸게 살 수 있는가” — 이 감각을 손에 익히는 것을 목표로 잡아보세요. 왜 짜는가의 답은 다음 환경에서 더 선명해질 거예요.

이 피드백이 진짜 하려는 말

전체를 한 문장으로 누르면 이거예요:

“Mock이냐 통합이냐(도구)를 먼저 고르려 하지 말고, ‘이 테스트가 무엇을 무엇으로부터 지키는가’(보호 대상)를 먼저 박아라. 도구는 거기서 역산된다.”

나머지 섹션은 전부 이 한 문장의 적용 사례라고 보면 정리가 깔끔해져요.

  • 진단에서 말한 “비어 있는 기준” = 보호 대상. 트레이드오프 표를 그릴 줄 안다는 건 도구 지식은 있다는 뜻이에요. 그런데 그 표 중에서 _뭘 고를지 결정하는 기준_이 없으니까, 결국 “내 토론조 규칙 맞나요?“를 남한테 물어보게 되는 거죠. 답이나 도구 정의를 더 줘도 안 풀리는 이유 — 막힌 건 지식이 아니라 판단 기준이라서.
  • Mock 논쟁은 도구 문제가 아니라 목적 문제. “내 대본대로 움직이는 가짜를 검증하는 느낌"은 Mock이 나빠서가 아니라, 지킬 대상이 흐릿한 채로 Mock을 써서 도구가 헛도는 거예요. 보호 대상이 분명하면 Mock·Fake·통합은 각자 자리가 생기고, 그 자리는 보호 대상이 정해줍니다.
  • 조마다 매트릭스가 다른 게 정상인 이유. 보호 대상이 같아도 “그걸 어떤 비용으로 살래?“라는 트레이드오프 판단이 갈리면 매트릭스가 달라져요. 그래서 “정답 4계층 매트릭스"를 찾는 건 헛수고. 우리 페어가 뭘 지키기로 했는지부터 박고 → 거기서 매트릭스를 역산하는 게 순서.
  • 안 해도 됨 리스트는 전부 같은 실수의 변형. 정답 매트릭스 찾기, 컨트롤러 단위 무조건 두기/빼기, Mock 안 쓴 죄책감, 모든 분기 다 테스트 — 전부 보호 대상 없이 형식부터 맞추려는 행동이라 버리라는 거예요.
  • 가장 밑바닥 보호 대상 = 회귀 안전성. “왜 테스트를 짜는가"의 답. 테스트는 “지금 옳다"의 증명이 아니라 “바꿔도 안 깨진다"는 자신감이고, 그건 곧 미래에 코드를 겁 없이 바꿀 권리를 미리 사두는 것. 미션 규모에선 이 효용이 잘 안 느껴지니, 지금 목표는 “회귀 안전성을 제일 싸게 사는 도구 감각"을 손에 익히는 거.

물어볼 만한 질문들

보호 대상을 실제로 어떻게 박는가 (가장 핵심, 꼭 물어볼 만함)

  • 보호 대상은 어느 단위에서 정하나요? 테스트 메서드 하나하나마다? 계층(도메인/서비스/…) 단위? 아니면 유스케이스 단위? 어디서 정하는 게 실전에서 안 흔들리나요?
  • 보호 대상을 한 줄로 적는 좋은 템플릿이 있을까요? 예를 들어 “이 테스트는 ___이 ___(어떤 변경)으로부터 안 깨지는 걸 지킨다” 같은 문장으로 강제해보는 게 도움이 될지.

두 축(검증 가치 × 비용) 적용

  • ‘검증 가치’를 실제로 어떻게 가늠하나요? “깨질 확률 × 깨졌을 때 손해” 정도로 보면 되나요?
  • 검증 가치는 낮은데 비용도 거의 0인 테스트(단순 getter, 위임만 하는 컨트롤러)는 둬도 되나요, 빼는 게 맞나요? 비용이 0에 가까우면 보호 대상이 약해도 남겨도 되는 건지.

Mock의 경계

  • “가짜를 검증하는 느낌"이 들 때, 그게 _Mock을 잘못 쓴 신호_인지 _애초에 그 계층엔 지킬 보호 대상이 없다는 신호_인지 어떻게 구분하나요?
  • DAO 모킹 금지(SQL이 mock 뒤에 숨으면 검증 가치 0)는 이해돼요. 그럼 반대로 서비스 테스트에서 Repository를 Mock 하는 건 왜 괜찮은가요? Mock 해도 되는 것과 안 되는 것의 경계가 결국 뭐죠?

페어 합의 / 매트릭스 점검

  • 페어가 보호 대상을 같이 정했는데도 트레이드오프 판단이 갈리면 (예: 컨트롤러 단위 둘까 말까), 무엇을 근거로 한쪽으로 정하나요?
  • 우리 페어 매트릭스가 네 패턴(피라미드 / 통합 중심 / 컨트롤러 생략 / DAO 모킹 금지) 중 어디에 가까운지를, 보호 대상으로부터 거꾸로 점검하는 방법이 있을까요?

“잘 산 테스트"인지 자가 검증

  • 미션 규모에선 회귀 안전성 효용이 잘 안 느껴진다고 하셨는데, 지금 단계에서 “이 테스트는 잘 샀다/헛돈 썼다"를 스스로 판단할 체크법이 있을까요? (예: “이 테스트는 어떤 변경에서 빨간불이 켜져야 정상인가"를 상상해보고, 떠오르는 변경이 없으면 보호 대상이 없는 것 — 이런 식?)

원하면 이 중에 의찬님 페어가 실제로 정한 보호 대상이 뭐였는지 말해주면, 거기 맞춰서 질문을 더 날카롭게 좁혀줄게요.

켄트백 [테스트주도 개발] 책

김창준의 [함께 자라기] 책

테스트의 목적이 모호할 때

책 읽어보기

TDD 에센스가 무엇일까?

모카: 요구사항을 이해하고, 지금당장 미래에 나아가야할 ㅍ로젝트 방향을 바로 잡아간다.

마이찬: 내가 지금 어떤 요구사항을 보고 어떤 기능을 구현해야할지 테스트 코드를 통해 명세를 코드화하고, 그 기능을 구현하기 위한 방어막과 목표를 정의하여, 지속적인 개발의 싸이클을 유도한다.

피드백 받으려고 테스트 코드를 부산물로 남기게 된다.

테스트 코드는 유용한 부산물이다.

TDD 비유

잉크보다는 번개

잉크는 천천히 퍼지는 느낌이라서, 번개는 빠르게 핵심을 찌르게 된다.

GPT로 켄트 벡처럼 TDD하기

동화책을 쓴다면 전문가와 초보자는 어떤게 다를까

초보자는 옛날 옛적에로 시작한다. 전문가는 교훈을 먼저 정의한다.

TDD 전문가 켄트벡에게 물어보자

켄트벡이 TDD에 접근하는 과정 설명

  1. 요구사항 명확하게 이해하기
  2. 작은 단위로 분해하기

핵심 기능을 중심으로 작은 단위들로 본해해서 해결하기

  • 내가 가고 싶은 회사들의 제의 들을 찾아보고 분석해보기
  • 키워드 뽑아보고 내 영량으로 키워보기
  • 나의 커리어를 만들어보기
  • 나한테 잘맞는 회사나 팀 생각해보기
  • 나한테 잘맞는 환경 생각해보기