아이디어와 인사이트

AI 퍼스트 개발, 코딩 가드레일, 그리고 폐기 가능한 아키텍처를 탐구합니다.

테스트는 통과한다. mutation score는 40%다. surviving mutant가 실제로 말해주는 것

code coverage는 안전하다고 말한다. mutation testing은 테스트가 대부분 장식이라고 말한다. surviving mutant가 이 간극을 드러내는 방법과 그것을 메우는 방법을 알아보자.

테스트는 통과한다. coverage 리포트는 87%라고 한다. 하지만 mutation score는 40%이고, 절반의 mutant가 여전히 살아있다. 그 40%는 코드가 망가졌다는 뜻이 아니다. 테스트가 망가졌다는 뜻이다. coverage는 테스트 실행 중 어떤 줄이 실행되었는지를…

Rust에서 뮤테이션 테스트는 통하지만, 컴파일 시간이 복수한다

cargo-mutants는 코드를 검증하는 척만 하는 테스트를 찾아낸다. Rust에서 뮤테이션 테스트가 어떻게 작동하는지, 무엇을 잡아내는지, 그리고 컴파일 시간 비용이 감당할 만한 가치가 있는지 알아본다.

라인 커버리지는 100%다. 모든 분기를 커버한다. 모든 함수를 호출한다. 그런데 누군가 가격 책정 로직에서 를 로 바꾸고 테스트를 돌리면, 테스트가 모두 통과한다. 이것은 이론적인 문제가 아니다. 테스트가 코드를 실행하지만 실제로는 동작을 검증하지 않을 때 벌어지는 일이다.…

검증 스펙트럼: AI 코딩이 백엔드에서 가장 잘 작동하는 이유

AI 코딩은 검증 그레이디언트를 따른다. 백엔드는 밀리초 단위로 검증된다. 웹은 분 단위, 모바일은 시간 단위가 걸린다. 피드백 루프가 AI 코딩의 효과를 결정한다.

AI 모델이 스스로 코딩하는 것 자체는 흥미로운 부분이 아니다. 흥미로운 것은 코드를 생성한 다음에 일어나는 일이다. 모델이 코드가 올바른지 얼마나 빨리 알 수 있는가? 생성과 검증 사이의 피드백 루프가 얼마나 타이트한가? 그 루프가 모든 것을 결정한다. 모델이 자신의 출력을 스스로…

원숭이, 기관총, aimbot: 코딩 팀을 위한 AI 거버넌스

AI 코드 거버넌스는 주니어 개발자와 AI 에이전트에게서 도구를 빼앗는 것이 아닙니다. 부수적 피해 없이 모든 사격이 목표물에 맞도록 하는 guardrail을 설치하는 것입니다.

기관총은 이미 모두에게 나눠준 상태다. AdEspresso의 공동 창업자이자 Unkover의 최고 AI 책임자인 Massimo Chieruzzi는 이를 완벽하게 포착했다: "AI는 때때로 당신을 기관총을 든 원숭이처럼 느끼게 한다." 우리도 동의한다. 그리고 그 통찰에서 우리는…

뮤테이션 테스트는 4시간이 걸린다. 팀은 실제로 CI에서 어떻게 사용할까?

대부분의 팀은 매 커밋마다 전체 뮤테이션 테스트 스위트를 실행하지 않는다. 엔지니어링 팀이 뮤테이션 테스트를 CI에 통합하면서도 빌드 파이프라인을 망가뜨리지 않는 실제 방법을 소개한다.

뮤테이션 테스트 스위트가 4시간이나 걸린다면, 축하한다. 모두가 이미 의심하던 사실을 증명한 셈이다. 당신의 테스트에는 구멍이 있다. 매 푸시마다 CI에서 이걸 돌릴 생각은 하지 마라. 그런 팀은 없다. 문제는 한 커밋당 4시간을 감당할 수 있느냐가 아니다. 테스트는 통과하는데…

유닛 테스트는 통과하는데, 데이터는 여전히 사라진다

모의 데이터베이스 테스트는 SQL 문법은 검증하지만, 행이 크래시나 동시 쓰기, 스키마 불일치에서 살아남는지는 검증하지 않는다. 여기 지속성을 진짜로 테스트하는 방법이 있다.

테스트에서 데이터베이스를 모킹하면, 리포지토리 레이어가 올바른 메서드를 호출하는지 검증하는 것이다. 데이터가 크래시에서 살아남는지, 고유 제약 조건이 실제로 중복을 차단하는지, 또는 트랜잭션이 실패할 때 롤백되는지는 테스트하지 않는다. 이 차이는 중요하다. 모킹된 는 지시한 대로…

두려움 vs 밀어붙이기: AI 코딩의 두 가지 현실

AI 코딩은 어떤 난장판에서도 복구할 수 있는 엘리트 팀에게는 잘 통한다. 그 외 모든 사람은 두려움, 실패한 CI, 중단된 실험만 남는다. 격차는 모델이 아니다.

두 팀이 동일한 AI 모델을 사용하는 모습을 지켜보면, 완전히 다른 두 가지 결과를 목격하게 된다. 첫 번째 팀은 모델에게 화면을 만들라고 지시한다. 출력 결과는 비슷하지만 어딘가 어긋난다. 스타일링은 Figma 파일에서 벗어나 있다. 상태 관리는 건드려서는 안 될 파일까지 건드린다.…

모든 mock action에 매몰리지 않고 Redux 테스트하기

모든 Redux action을 mock하면 테스트가 변경 로그 검증기가 된다. 대신 실제 상태 전환으로 store를 테스트하는 방법.

가 정확한 payload 형태로 호출되었는지 검증하는 테스트를 작성한 적이 있다면, 누군가 상수 이름을 바꿀 때마다 깨지는 테스트를 작성한 것이다. 이건 상태 로직을 테스트하는 게 아니다. 손가락이 올바른 문자열을 입력했는지 테스트하는 것이다. Redux 테스트 튜토리얼은 종종…

프로덕션에서의 AI 코딩: 대부분의 팀이 포기하는 이유

대부분의 팀은 AI 코딩을 시도했다가 QA를 통과하지 못하는 코드를 배포하고 포기합니다. 문제는 모델이 아닙니다—AI 출력을 신뢰할 수 있게 만드는 가드레일의 부재입니다.

AI 코딩을 시도하는 대부분의 팀은 같은 궤적을 따릅니다. 처음에는 들떠서 시작합니다. 모델이 몇 분 만에 기능을 생성하고, 팀은 이를 배포합니다. QA가 버그를 발견하고, 팀은 수정본을 배포합니다. QA가 또 다른 버그를 발견하는데, 이번에는 관련이 없어야 할 다른 모듈에서…

100번 테스트 실행은 거짓말이다: Property-Based Test를 실제로 사이징하는 법

Property-based testing의 기본값인 100개 예제는 통계 전략이 아닌 사회적 타협이다. 자신의 신뢰도 요구사항과 CI 예산에 맞는 실행 횟수를 선택하는 방법을 알아보자.

property-based test를 기본값 100개 예제로 실행하고 있다면, 양쪽 모두 최악의 상황을 겪고 있는 것이다. CI는 필요 이상으로 느리고, 여전히 중요한 버그는 놓치고 있다. 이 숫자에 마법 같은 건 없다. Hypothesis를 포함한 대부분의 라이브러리가 100을…