훌라 hard 봇의 값을 동결하고, 한 번도 쓰지 않은 딜 256개에서 최종 검증을 합니다. 실험이 고른 값을 일부러 쓰지 않은 자리와 그 이유, 시험 문제를 열기 전에 합격선을 못 박는 절차, 인원이 늘수록 두 배씩 벌어진 결과, 그리고 Part 4 의 여덟 자리 중 무엇이 메워졌고 무엇이 메운 줄 알았는데 아니었는지를 결산합니다.

훌라 hard 봇을 시뮬레이터로 잽니다. 같은 딜에서 hard 와 easy 를 바꿔 앉혀 딜 운을 지우는 방법, 도구가 만들어지자마자 잡은 “다른 봇을 재고 있었다” 는 버그, 8 seed 로는 아무 말도 못 하고 32 seed 에서야 방향이 보인 첫 성적, 그리고 손으로 정한 추 열한 개를 하나씩 빼 보니 넷은 5만 번의 결정에서 수를 하나도 바꾸지 않았다는 사실까지 다룹니다.

두 스킬셋은 TDD 에서 같은 말을 하지 않습니다. superpowers 는 리팩터링을 루프 3단계로 넣고 테스트 없이 쓴 코드를 삭제하라고 명령하며, mattpocock 은 리팩터링이 루프의 일부가 아니라고 못박고 테스트 지점을 사전 합의하라고 요구합니다. 구현·리뷰·디버깅·검증 단계를 원문으로 대조했습니다.

Part 5 는 브라우저에서 한 판 돌려 찾은 결함을 고쳤습니다. 그 방법으로는 “조금 약하다"를 찾을 수 없어 시뮬레이터를 만들었더니, 도구가 전략을 재기도 전에 구현 버그부터 잡아냈습니다. 그리고 봇이 약한 이유를 세 번 틀리고 네 번째에 찾았습니다. 평가 함수는 처음부터 옳았고, 확률이 틀렸습니다.

Part 1~4 에서 설계한 렉시오 hard 봇을 실제로 구현했더니 봇이 거의 모든 턴을 패스했습니다. 개별 항은 전부 맞았고 항을 합치는 방식이 틀렸습니다. 평가 함수가 무너지는 네 가지 자리와, 그 회귀 테스트가 엉뚱한 이유로 통과한 이야기를 다룹니다.

Part 1부터 3까지의 설계안을 실제로 구현해 시뮬레이션으로 재봤더니, hard 봇이 easy 봇보다 평균 0.6601등 나빴습니다. 무엇을 어떻게 쟀는지, 세 개의 구조 결함이 무엇이었는지, 어떤 고급 기능이 살아남았는지, 그리고 정정 후의 정식 검증 수치를 정리합니다.

Superpowers 의 가장 강력한 부분은 “규율을 강제하는” 품질 보증 스킬들입니다. 3편에서는 TDD Iron Law, 4단계 systematic debugging, verification-before-completion, code review 흐름을 Java 프로덕션 버그 시나리오와 함께 분석합니다.

에이전트가 코드를 대신 쓰는 시대에 어떤 개발방법론이 살아남고 어떤 것이 의미를 잃었는지, Kent Beck, Birgitta Böckeler, Simon Willison 등이 2025-2026년에 남긴 1차 자료를 바탕으로 정리합니다.

테스트 피라미드는 테스트 스위트의 발전을 안내하는 정석적인 경험 법칙(heuristic)입니다. 이는 단순한 메시지를 전달합니다. 통합 테스트보다 더 많은 단위 테스트를 선호하고, 엔드 투 엔드(end-to-end) 테스트보다 더 많은 통합 테스트를 선호하라는 것입니다.

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다.

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다.

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다.

만약 당신이 과속 운전을 한다면(원인), 당신은 교통 딱지를 받게 될 것입니다(결과).

일반적으로 상태를 변경하지 않는 메서드가 호출되었는지 검증하는 것은 피해야 합니다.

과도하게 중첩된 코드는 가독성을 해치고 오류를 발생시키기 쉽습니다.

만약 당신이 과속 운전을 한다면(원인), 당신은 교통 딱지를 받게 될 것입니다(결과).

End-to-end(E2E) 테스트는 시스템의 한쪽 끝에서 다른 쪽 끝까지, 그 사이의 모든 것을 블랙박스로 취급하며 전체 시스템을 테스트합니다. E2E 테스트는 시스템 전반에 걸쳐 나타나는 버그를 잡아낼 수 있습니다. 단위 테스트, 통합 테스트와 더불어 E2E 테스트는 균형 잡힌 테스트 식단의 핵심적인 부분이며, 운영 환경과 거의 유사한 상태에서 시스템의 건전성에 대한 확신을 줍니다.

변경 감지 테스트는 부정적인 가치(- value)를 제공합니다. 테스트가 어떤 결함도 잡아내지 못하면서, 추가적인 유지보수 비용이 개발 속도를 늦추기 때문입니다. 이러한 테스트는 다시 작성되거나 삭제되어야 합니다.

Public API 는 수많은 사용자에 의해 호출될 수 있으며, 사용자들은 메서드에 가능한 모든 입력 조합을 전달할 수 있습니다. 여러분은 이 API들이 잘 테스트되었는지 확인하고 싶을 것입니다. 그래야 사용자들이 API를 사용할 때 문제를 겪지 않을 것이기 때문입니다.

테스트 이름에 시나리오와 예상 결과를 모두 넣는 것은 여러 가지 이점을 가집니다.