15년 된 100만 줄 C#·React SaaS에 개발자 없이 AI 에이전트만 붙여 준비 2주, 구현 2주 만에 1만 3천 줄짜리 프로토타입을 만든 사람이 8월 엔지니어 리뷰 전에 무엇을 더 해둬야 할지 해커뉴스에 물었어요. 답변은 코드를 읽히게 만드는 쪽보다 테스트와 문서로 둘러싸는 쪽에 몰렸는데, 코드를 건드리기 전에 AI로 파일 단위부터 문서를 만들고 그 위에 단위·종단간 테스트를 깔라, 아키텍처 문서를 단일 기준으로 삼아 데이터 모델·API·역할까지 담아라, 회귀 테스트를 돌린 뒤 통과·실패를 표로 남겨 리뷰어가 현재 상태부터 보게 하라는 제안이 나왔어요. 질문자가 이미 쓰고 있는 장치도 공개됐는데, 별도 브랜치와 별도 데이터베이스로 격리하고 계획·구현·리뷰 에이전트를 나눴으며, 위험한 PR은 다른 계열 모델로 한 번 더 리뷰했더니 같은 계열 리뷰보다 의미 있는 문제를 훨씬 많이 찾았다고 해요.
- 회귀 테스트
- 코드를 고친 뒤 원래 잘 되던 기능이 망가지지 않았는지 다시 확인하는 테스트. regression test.
- 종단간 테스트
- 화면 조작부터 데이터 저장까지 실제 사용 흐름 전체를 한 번에 검증하는 테스트. end-to-end 테스트.
- 변이 테스트
- 코드를 일부러 조금 망가뜨렸을 때 테스트가 실패하는지 보고 테스트가 실제로 쓸모 있는지 재는 기법. mutation testing.
- 순환 복잡도
- 함수 안에서 조건·반복으로 갈라지는 실행 경로가 몇 갈래인지 세어 복잡함을 수치로 나타낸 지표. cyclomatic complexity.
AI가 만든 큰 덩어리를 리뷰해야 하는 자리는 곧 남 일이 아니에요. 여기서 바로 집어 쓸 장치는 셋이에요. 구현한 에이전트와 다른 에이전트에게 테스트를 맡겨 '테스트를 약하게 고쳐 통과시키는' 우회를 막고, 위험한 변경은 다른 계열 모델로 한 번 더 리뷰하고, 회귀 테스트 결과를 통과·실패 표로 남겨 리뷰어가 코드를 읽기 전에 현재 상태부터 확인하게 하는 거예요. 다만 '테스트 관문만 촘촘하면 코드는 안 읽어도 된다'와 '에이전트가 만든 테스트가 유효한지는 결국 사람이 봐야 한다'가 정면으로 갈렸고, 보안만큼은 안을 들여다봐야 한다는 단서도 붙었어요.
- 질문자가 실제로 돌린 구성 별도 브랜치와 별도 데이터베이스로 격리하고, 계획·구현·리뷰 에이전트를 나누고, 에이전트가 혼자 정하면 안 되는 항목을 '멈추고 물어봐' 목록으로 못 박은 구성이 그대로 적혀 있어요. Hacker News
- 코드는 안 읽고 테스트 관문으로 막자는 쪽 스레드에서 근거로 인용된 로버트 마틴의 방식인데, 함수 크기 제한·순환 복잡도 임계값·커버리지·변이 테스트·인수 테스트까지 관문을 겹겹이 세워두고 코드 자체는 읽지 않는다고 해요. ExplainX
- 결국 자격 있는 사람이 검증해야 한다는 쪽 '실서비스에 넣을 거면 지금 자격 있는 사람을 붙이는 것 말고는 대부분 시간 낭비'라는 반박의 근거로 걸린 켈시 하이타워의 PlatformCon 2026 강연이에요. YouTube