grep

테스트를 더 쓰기 전에, 어디에 쓸지부터: 동적 필터 ATDD 실험기

여기어때

2026년 8월 31일

원문에서 보기 ↗

글. 이예슬(Sophia) / 서비스웹개발팀

안녕하세요. 서비스웹개발팀 소피아입니다.

올여름 국내 숙소 검색에 다중 카테고리 선택과 동적 필터 를 적용하면서, 개발 프로세스 실험을 하나 함께 진행했습니다. QA가 테스트 케이스(TC)를 개발이 끝나기 전에 넘겨주면, 개발자가 그 TC를 실행 가능한 명세로 삼아 자동화하는 방식입니다.

다중 카테고리 선택과 동적 필터 작업은 웹 검색 필터를 개선하는 작업이었는데요, 숙소 유형을 모텔, 펜션처럼 여러 개 동시에 고를 수 있게 하고 , 필터를 조작할 때마다 각 항목 옆의 숙소 개수가 지금 조건 기준으로 다시 계산되게 만드는 작업입니다. 0건이 된 항목은 선택할 수 없도록 비활성화되고요. 동적 필터가 적용된 예시 사진

실험을 해보고 나니 얻은 것이 생각보다 많았습니다. 결함 1717건 안팎을 QA 시작 전에 미리 잡았고, QA가 TC를 처음 실행했을 때 약 95%가 한 번에 통과했으며, 오픈 이후로는 결함이 한 건도 나오지 않았습니다. 무엇보다 다음에 품질에 투자한다면 정확히 어디에 해야 하는지를 감이 아니라 데이터로 알게 됐습니다.

물론 다 좋았다는 이야기는 아닙니다. 사전에 합의했던 목표(QA 기간 결함 10건 미만)에는 14건으로 못 미쳤으니까요. 다만 그 14건이 어디서 왜 나왔는지 하나씩 따라가 봤고, 그 추적이 이 실험에서 가장 값진 수확이 됐습니다. 무엇을 얻었고 무엇을 바꾸면 좋을지를 중심으로 적어 보겠습니다.

적용하게 된 계기

시작은 7월 초 팀 AI 스터디였습니다. 사실 red/green으로 도는 TDD라는 개념을 제대로 접한 것도 그 자리가 처음이었어요. 그날 팀원들과 이런 이야기를 나눴습니다. 요즘 우리는 AI를 적극적으로 쓰면서 개발하는데, 생산성이 올랐을 거라는 기대만큼 일정도 전보다 타이트하게 잡힌다고요. 그리고 그 부담이 QA 기간에 티켓이 몰려 나오는 모습으로 이어지는 것 같다고요. 그렇다면 QA의 TC를 먼저 받아서 개발 단계의 테스트 케이스로 쓰면 그 몰림을 앞 단계에서 흡수할 수 있지 않을까 하는 가설이었습니다.

며칠 굴려 보니 질문이 하나 남더군요. 개발자끼리는 "괜찮은 그림"이라고 하기 쉬운데, QA 입장에서는 어떨까. 답을 찾으려고 자료를 뒤지다 ATDD라는 개념을 만났습니다. 개념이 잡히니 질문도 만들어졌습니다. 스쿼드의 QA 담당자에게 이 방식을 어떻게 생각하는지 물었고, 돌아온 답은 "궁금하면 한번 적용해 보자" 였습니다.

TDD와 ATDD에 대해

글에 계속 나올 두 단어를 정리하고 가겠습니다. 이름이 비슷해서 하나로 뭉뚱그리기 쉬운데, 실은 서로 다른 층에서 도는 별개의 프로세스입니다.

TDD (Test-Driven Development)는 코드를 먼저 쓰지 않고 실패하는 테스트를 먼저 쓰는 개발 방식입니다. 진행은 세 단계의 반복입니다. 만들려는 동작을 검증하는 테스트를 먼저 쓰고, 그 테스트가 실패하는 것, 즉 빨간불(red)을 눈으로 확인합니다. 그다음 그 테스트를 통과시키는 최소한의 코드를 써서 초록불(green)을 만들고, 마지막으로 초록불을 유지한 채 코드를 정리(refactor)합니다. 그리고 다음 동작으로 넘어가 같은 과정을 반복합니다.

이 글과 아래 그림에서는 이 red → green → refactor 반복을 "안쪽 루프" 라고 부르겠습니다. 함수 하나처럼 작은 코드 단위에서 개발자가 몇 분 단위로 빠르게 돌리는 검증이라는 뜻이고, 잠시 뒤에 나올 요구사항 단위의 "바깥 루프"(ATDD)와 짝을 이룹니다. TDD에 대한 설명

빨간불을 먼저 봐야 한다는 게 처음엔 유난스러워 보이는데, 이유는 단순합니다. 한 번도 실패한 적 없는 테스트는 실제로 무언가를 검증하고 있는지 확인할 길이 없기 때문입니다. 처음부터 통과하는 테스트는 "코드가 맞아서" 통과하는 건지 "아무것도 안 잡는 테스트라서" 통과하는 건지 구분이 안 되거든요. 이번 프로젝트에서도 실제로 겪은 일인데, 구현과 테스트가 같은 상수를 참조하는 바람에 상수가 잘못 바뀌어도 통과해 버리는 테스트를 발견해서 기대값을 문자 그대로 고정하도록 고친 적이 있어요. 빨간불 확인은 그런 헛도는 테스트를 걸러내는 최소한의 안전장치입니다.

또 하나, TDD는 이름과 달리 테스트 기법이라기보다 설계 도구 에 가깝습니다. 테스트를 먼저 쓰려면 "이 함수는 무엇을 받아서 무엇을 돌려주는가"를 코드보다 먼저 정해야 하니까, 인터페이스를 정하는 고민이 강제로 앞당겨집니다. 예를 들어 "선택된 카테고리 배열을 URL 파라미터 문자열로 바꾼다"는 함수를 TDD로 만들면, 빈 배열일 때, 하나일 때, 여러 개일 때, 전부 선택했을 때 각각 뭘 돌려줄지를 코드 첫 줄을 쓰기 전에 결정하게 됩니다. 그 결정들이 곧 설계고요. 그래서 TDD는 개발자의 도구이고, 함수나 모듈 같은 코드 단위에서 굴러갑니다.

ATDD (Acceptance Test-Driven Development)는 같은 "테스트 먼저"지만 먼저 쓰는 대상이 다릅니다. 여기서 앞당기는 것은 수용 기준 입니다. "모텔과 펜션을 같이 고르면 두 유형의 숙소가 다 나온다", "필터를 조작하면 하단 버튼의 숙소 개수가 실시간으로 바뀐다"처럼 코드가 아니라 사용자와 QA의 언어로 적힌 기대 동작이죠. 기획, QA, 개발이 개발 시작 전에 이 기준을 구체적인 예시 수준까지 합의해 두면, 개발은 그 예시들을 하나씩 통과시키는 일이 됩니다. ATDD에 대한 설명

이 방식의 힘은 자동화 이전에 합의 자체에서 나옵니다. "필터가 동작해야 한다" 같은 문장은 읽는 사람마다 다르게 해석할 수 있지만, "0건인 항목은 회색으로 비활성화되고 눌러도 반응이 없다"는 예시는 한 가지로만 읽히니까요. 모호함이 코드가 되기 전에, 문장 단계에서 드러납니다. 그리고 그 예시들을 자동화해 두면 이후의 모든 코드 변경마다 다시 채점되는 안전망이 됩니다.

주의할 점이 하나 있는데, ATDD는 "QA에게 개발자의 테스트를 쓰게 하자"는 말이 아닙니다. 저도 처음엔 "QA가 테스트를 먼저 쓰면 되겠네"로 뭉뚱그렸다가, 개념을 찾아보면서 이게 함정이라는 걸 알았어요. 단위 테스트는 코드 내부 구조를 알아야 쓸 수 있어서, QA가 쓸 수도 없고 쓸 이유도 없습니다. QA가 먼저 쓰는 건 어디까지나 자기 언어로 된 수용 기준이고, 그걸 코드 층의 테스트로 옮기는 건 개발자의 일입니다. 각자 잘하는 것을 각자의 층에서 먼저 쓰는 거죠.

둘의 관계는 건축 현장에 비유하면 이해하기 쉽습니다. 준공 검사관(QA)은 "문이 잘 열리고 물이 새지 않는다"는 합격 기준을 공사 전에 문서로 확정합니다. 이게 ATDD, 바깥 루프입니다. 목수(개발자)는 매 작업마다 자기 수평계를 대 봅니다. 이게 TDD, 안쪽 루프고요. 검사관에게 수평계를 쥐여 주는 게 아니라, 두 검증이 각자의 층에서 도는 이중 루프인 겁니다. 실제 작업 흐름도 그렇게 돕니다. 바깥 루프에서 수용 기준 하나를 골라, 그걸 통과시키기 위해 안쪽에서 red→green을 몇 바퀴 돌고, 바깥 기준이 통과되면 다음 기준으로 넘어가는 식입니다.

헷갈릴 땐 이 질문으로 갈라집니다. 이 테스트가 깨지면 누가 고치는가, 그리고 무엇의 실패인가. 요구사항의 실패면 바깥 루프의 일이고, 설계의 실패면 안쪽 루프의 일입니다.

이번 실험은 QA의 TC 197건을 바깥 루프의 합격 기준으로 삼고, 제가 안쪽에서 TDD를 돌리는 구조였습니다.

대상은 마침 진행 중이던 다중 카테고리와 동적 필터 작업으로 정했습니다. 필터라는 도메인 특성상 TC가 충분히 복잡하고, 앱에 이미 있는 기능을 웹으로 가져오는 작업이라 앱의 TC를 변형해 비교적 빨리 TC를 만들어 줄 수 있었기 때문입니다. "QA 결함 10건 미만이면 성공"이라는 기준도 이때 함께 잡았습니다.

한 문장으로 요약하면, QA의 테스트 케이스를 시험이 끝난 뒤의 채점 기준 에서 시험 전에 나눠주는 문제지로 바꾸는 실험입니다. 저는 그 문제지를 자동화해서, 코드가 바뀔 때마다 자동으로 다시 검증되게 만들었고요.

"잘 되면 좋고"가 아니라 실험으로

이런 시도는 흐지부지되기 쉬워서, 세 가지를 미리 정해 뒀습니다.

성공 기준을 사전에 합의했고 (끝난 뒤 유리한 지표를 골라잡지 않도록 10건 미만으로), 결함 수보다 한 겹 깊은 지표도 함께 정했습니다. 결함 수만 세면 치명적인 버그와 문구 오타가 똑같은 1건이 되니까, 팀 QA 표준의 5단계 심각도로 가중치를 두고 결함마다 어디서 새어 나왔는지 를 분류하기로 했습니다. TC가 애초에 그 경우를 다루지 않았는지(no-TC), TC는 있었는데 자동화하지 않았는지, 자동화까지 했는데 테스트가 틀렸는지, 아니면 프론트 테스트 밖의 일이었는지. 그리고 결과가 어느 쪽으로 나와도 그대로 보고하기로 미리 적어 뒀습니다. 이 세 번째 장치 덕분에 이 글도 쓸 수 있게 됐고요.

두 개의 루프, 그리고 에이전트

TC는 총 197건이 도착했습니다. 검색 결과 페이지 97건, 지도 100건, 21개 기능 영역. 이걸 세 계층으로 나눠 배치했습니다. 순수 로직은 Jest 단위 테스트로, 화면 동작은 React Testing Library로, 실제 서버가 필요한 검증은 실환경 브라우저에서 확인하기로요.

이 실험을 실제로 굴리는 데 빼놓을 수 없던 축이 AI 에이전트(Claude Code) 입니다. 197건을 사람 손으로 테스트 코드로 옮기고, 코드가 바뀔 때마다 전부 다시 확인하는 건 혼자 감당할 만한 양이 아닙니다. 역할을 이렇게 나눴습니다.

이 분업에서 의미가 컸던 사건이 둘 있었습니다. 하나는 반박 전담 검증 프로세스가 제가 만든 수정의 허점을 찾아낸 일입니다. 제가 쓴 코드라고 검증에서 빼면 실험이 의미가 없으니 제 수정도 똑같이 공격 대상에 넣었는데, 실제로 거기서 구멍이 나왔습니다. 다른 하나는 반대 방향입니다. 에이전트가 두 번을 훑고도 못 잡은 버그 2건을 제가 스테이지 환경에서 직접 눌러 보다가 찾았습니다. 에이전트가 잘 잡는 버그와 사람이라서 잡는 버그는 끝까지 달랐고, 이 경계를 아는 것 자체가 수확이었습니다.

개발 단계에서 미리 잡은 것들

이렇게 해서 QA가 시작되기 전에 소화한 문제가 17건 안팎입니다. TC 전체 점검이 찾아낸 명세 불일치, API 문서와 실제 동작이 달랐던 여덟 곳, TC를 테스트로 옮기다 드러난 스펙 충돌과 잠복 UI 버그, 반박 검증이 잡아낸 제 수정의 허점. 예전 방식이었다면 전부 QA 기간에 결함 티켓으로 돌아왔을 문제가, 코드의 맥락이 머릿속에 가장 생생한 개발 단계에서 결정과 수정으로 정리됐습니다.

개발 단계에서 발견했던 문제 중에서도 특히 스펙 충돌 건이 기억에 남습니다. "count가 0인 항목"의 처리가 API 문서와 TC에서 서로 반대였는데, 예전 순서였다면 QA 기간에 "버그냐 스펙이냐"로 한참 오갔을 문제가, TC를 미리 읽은 덕에 개발 중에 조용히 발견돼 기획 확인 한 번으로 끝났습니다. 충돌을 없앨 수는 없어도 충돌이 발견되는 시점은 옮길 수 있다는 확신을 여기서 얻었습니다.

QA에 넘긴 시점의 자산은 이랬습니다. 필터 도메인 테스트 16개 파일 266케이스, 전체 테스트 green. 프로젝트 기간에 추가된 코드의 63%가 테스트였습니다.

숫자가 말해준 것

QA 기간의 성적표를 보겠습니다. QA가 실행한 TC 시트를 나중에 대조해 보니, 처음 실행에서 약 95%가 통과했습니다. 결함이 나온 TC 행은 199행 중 10행이었고, 결함 하나가 여러 행을 한꺼번에 깨뜨리기 때문에 티켓으로는 7건입니다. 그러니까 TC가 기대한 동작의 95%는 이미 맞는 상태로 QA에 넘어간 겁니다. 팀 QA 표준이 품질 목표로 삼는 "테스트 성공률 95% 이상"을 첫 실행 기준으로 충족한 셈이고요.

결함은 총 14건이 등록됐습니다(치명적 등급 0건). 합의했던 10건 미만에는 못 미쳤죠. 그런데 "어디서 새어 나왔나" 분류를 채워 보니, 이 14건은 실망할 대상이 아니라 다음에 힘을 쏟을 곳을 그려 주는 지도였습니다.

자동화한 테스트가 검증하던 영역에서 새어 나간 건 1건뿐입니다 (테스트 데이터를 문서 기준으로 만들었는데 실제 서버 응답 타입이 달랐던 건). 두 번의 전체 점검과 반박 검증을 거친 곳은 사실상 뚫리지 않았어요. 이게 왜 중요하냐면, 만약 저희에게 "14건, 목표 초과"라는 숫자만 있었다면 자연스러운 결론은 "다음엔 테스트를 더 촘촘히 쓰자"였을 텐데, 분류는 정반대를 가리키고 있었거든요. 테스트로 검증한 영역은 이미 충분히 안정적이었고, 늘려야 할 것은 테스트의 양이 아니라 검증이 닿는 범위였습니다.

TC가 작성돼 있던 영역에서 나온 7건도 같은 방향을 가리킵니다. 하나씩 뜯어 보면 이렇습니다. 알고는 있었지만 프론트 혼자 고칠 수 없던 것(백엔드 소관, 배포 시차), TC 밑에 깔린 정책이나 데이터 형태가 미확정이었던 것, TC가 조합과 조건까지는 적지 않았던 것, 알아도 개발 단계에서 확인할 도구가 없던 것. "미리 알았다"와 "미리 확인할 수 있었다"는 다른 문제고, 그 간극 하나하나가 곧 다음에 만들 장치의 목록이 됩니다.

가장 큰 발견은 결함이 몰려 있던 지점입니다. 굵직한 결함의 절반 이상이 결국 한 문장으로 요약됩니다. 필터에 적힌 개수와 실제 리스트 결과가 다르다. 이 증상은 진입 화면을 바꿔가며 반복해서 나타났는데 파고들 때마다 원인이 달랐습니다. 파라미터, 검색 경로, 키워드, 가격 경계값, 지도 줌까지, 증상은 하나인데 원인은 다섯이었죠. 마지막 줌 레벨 건은 오픈 당일 정책이 확정되면서 핫픽스로 반영했습니다. 왜 이 문제만 계속 빠져나갔을까요? TC는 화면 단위로 짜여 있는데, "필터 API와 리스트 API가 같은 결과를 세고 있는가"는 어느 한 화면의 문제가 아니라 서비스 전체에 걸쳐 있는 조건이었기 때문입니다. 게다가 실제 서버 두 대가 맞아야 하는 문제라, 브라우저 없는 테스트 환경에서는 확인할 방법 자체가 없고요. 아무도 검증을 맡지 않은 영역이 있었다는 사실, 그리고 이제 그 영역이 어디인지 안다는 사실이 14건이 남긴 가장 큰 자산입니다.

또 하나, 회고에서 발견한 희망적인 사실이 있습니다. 문제가 된 지점 중 두 건은 누군가 이미 신호를 보냈던 자리였습니다. 하나는 QA 시작 전 명세 검증에서 발견돼 보고까지 됐고, 다른 하나는 QA 담당자가 며칠 앞서 위험을 지적했었죠. 발견 능력은 이미 팀에 있었다는 뜻입니다. 없었던 건 그 발견을 릴리스 결정으로 연결하는 자리 하나였고, 그 자리는 만들면 됩니다.

어떻게 적용할 수 있을 것인가

이번 경험을 바탕으로, 비슷한 시도를 한다면 해 볼 만하다고 생각하는 것들을 적어 둡니다. 어디까지나 한 프로젝트에서 나온 제안이니, 그대로 옮기기보다 각자의 상황에 맞는 것만 골라 쓰는 쪽이 맞겠습니다.

  1. TC는 개발 시작 전에. 이번엔 실험이 프로젝트 중간에 시작돼 TC가 구현 뒤에 도착했습니다. TC가 명세 노릇을 제대로 하려면 순서부터 맞추는 게 좋겠습니다.
  2. "항상 지켜져야 하는 조건"을 TC의 두 번째 축으로. "필터가 말한 개수 = 리스트가 보여주는 개수"처럼 서비스 전체에 걸친 조건을, 진입 화면과 조작을 조합한 표로 만들어 화면 단위 검증과 나란히 두면 이번 같은 유형의 문제를 미리 볼 수 있을 겁니다.
  3. 개수 대조는 상시 감시로. 두 API를 나란히 호출해 비교하는 가벼운 검사를 스테이지에 계속 돌려 두는 방법이 있습니다. 이번 TC의 일부 행에도 개수 일치 확인이 이미 들어 있었으니, 없던 것을 만드는 게 아니라 있는 확인을 넓히고 자동화로 받치는 일에 가깝습니다.
  4. 테스트 데이터는 실제 서버 응답을 저장해서 만들기. 문서는 의도를 말하고, 응답은 사실을 말하니까요.
  5. "어디서 새어 나왔나"를 결함 티켓의 필드로. 이번엔 회고에서 거슬러 올라가며 분류했지만, 등록할 때 적으면 실시간 지표가 됩니다.
  6. "개수가 안 맞는다"류의 발견은 릴리스 체크리스트로. 심각한지 아직 몰라도 일단 올려 두고, 수정할지 수용할지 미룰지를 명시적인 결정으로 내리는 겁니다. 앞서 말한 "신호를 결정으로 연결하는 자리"가 이것이고요.

어디까지 통할까

이 방식이 만능이 아니라는 점은 분명히 해 두고 싶습니다. 기획이 계속 움직이는 큰 프로젝트에서는 TC를 미리 받아도 그 밑의 기준이 함께 움직입니다. 기준이 바뀌면 미리 쓴 TC도, 그걸 옮긴 테스트도 같이 고쳐야 해서 앞당겨 둔 작업이 그대로 재작업이 되고요. 실제로 이번 결함 14건 중 4건이 QA 중에야 정책이 확정된 구간에서 나왔습니다.

프로젝트를 마치고 함께했던 QA 담당자와 회고를 나눴을 때도 비슷한 이야기가 나왔습니다. 이 프로젝트를 같이 한 한 사람의 경험이라는 전제를 달고 옮기면, 정책이 중간에 바뀌면 이미 검증한 부분을 다시 검증하고 영향 범위를 따져야 해서 비용이 가장 크고, 큰 피처일수록 개발 전에 TC 쓸 기간을 확보하기 어렵다고 합니다. 반대로 TC를 미리 쓰는 일 자체는 "어차피 쓸 걸 미리 쓴 정도"라 부담이 아니었고, TC 작성 기간을 좌우하는 진짜 변수는 기획 문서의 상세함이었다고요. 기준이 움직이는 구간에서 결함이 났다는 개발자 쪽 회고와 결이 같은 이야기였습니다. 명세를 일찍 세우고 고정하는 일은 개발만의 요구가 아니었던 겁니다.

그래서 저희가 내린 결론은 전면 도입이 아니라 골라서 적용입니다. 어떤 서비스에든 웬만해서는 바뀌지 않는 동작이 있습니다. 이번 프로젝트로 치면 "여러 유형을 고르면 결과를 합쳐 보여준다", "0건 항목은 비활성화한다" 같은 기본 동작이 그렇습니다. 이런 영역은 기획도 TC도 안정적이라, TC를 미리 받아 자동화하는 비용을 한 번만 치르면 이후의 모든 변경에서 별도 비용 없이 다시 검증됩니다. 반대로 기준이 아직 움직이는 영역은 미리 자동화할수록 재작업만 늘어나니, 기준이 굳은 뒤에 얹으면 됩니다.

이렇게 나누면 검증의 초점도 달라집니다. 안정 영역은 자동화가 지키고 있으니, 사람의 검증은 이번에 새로 만든 것과 기준이 아직 움직이는 것에 모을 수 있습니다. 이게 실제로 QA 쪽 일까지 가볍게 만들어 주는지는 제가 단정할 수 있는 문제가 아니라서, 함께 검증해 봐야 할 가설로 남겨 둡니다. 다만 방향은 분명하다고 생각합니다. 검증이 QA 기간 한 곳에 몰려 있으면 문제가 발견되는 시점도 배포 직전으로 몰립니다. 이번처럼 검증을 개발 기간 전체에 펼쳐 두면 QA 기간은 처음 검증하는 시간이 아니라 마지막으로 확인하는 시간이 되고, 첫 실행 통과율 95%는 그 그림이 실제로 가능하다는 증거였습니다.

마치며

이 실험에서 얻을 수 있던 것을 정리해 보면 이렇습니다. 첫째, 266개의 자동화된 도메인 테스트. QA 기간 42커밋의 수정이 서로를 망가뜨리지 않게 지켰고, 오픈 후 결함 0건의 바탕이 된 자산입니다. 둘째, 결함 17건을 앞 단계로 옮긴 경험. 충돌이 발견되는 시점은 옮길 수 있다는 확신이 됐습니다. 셋째, 다음에 무엇을 바꿀지 알려 주는 데이터. 테스트의 양이 아니라 검증이 닿는 범위, 그리고 명세를 고정하는 시점이라는 답을 얻었습니다. 넷째, 에이전트와의 분업 경계를 가늠하는 감각. 빠짐없이 확인하고 반박거리를 찾는 일은 에이전트가 압도하지만, 검증 범위 바깥을 알아차리는 일은 사람의 몫이라는 것.

돌아보면 이 실험의 목적은 방법론의 승패를 가리는 일이 아니었습니다. 개발자와 QA가 서로 덜 소모적으로 일하는 프로세스를 찾는 일이었고, 그 답의 절반쯤은 찾은 것 같습니다. "테스트를 먼저 쓴다"는 문장은 생각보다 여러 프로세스를 가리킵니다. 지금 하는 게 그중 무엇인지 이름을 붙이고, 결과가 어느 쪽으로 나와도 배울 수 있게 측정을 설계해 두는 습관. 이번 실험에서 얻은 가장 큰 소득은 그 습관입니다. 비슷한 시도를 이어 가는 분이 있다면 웬만해서는 바뀌지 않는 영역부터 골라, 위의 제안에 회고에서 나온 이야기(기획 문서를 함께 더 상세하게 만들기, TC 초안은 그 영역을 가장 잘 아는 사람이 먼저 쓰기)까지 얹어서 시작해 보면 좋겠습니다.

읽어주셔서 감사합니다. ATDD나 TDD를 한번 적용해 보고 싶다면, 거창하게 시작할 필요 없이 기능 하나를 골라 성공 기준과 유출 분류부터 정해 두고 시작해 보세요. 그러면 결과가 기대에 못 미치더라도 왜 그랬는지가 남고, 그 자체가 개선점이 됩니다.

테스트를 더 쓰기 전에, 어디에 쓸지부터: 동적 필터 ATDD 실험기 was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.