AI 퍼스트 개발, 코딩 가드레일, 그리고 폐기 가능한 아키텍처를 탐구합니다.
AI 코딩은 검증 그레이디언트를 따른다. 백엔드는 밀리초 단위로 검증된다. 웹은 분 단위, 모바일은 시간 단위가 걸린다. 피드백 루프가 AI 코딩의 효과를 결정한다.
AI 모델이 스스로 코딩하는 것 자체는 흥미로운 부분이 아니다. 흥미로운 것은 코드를 생성한 다음에 일어나는 일이다. 모델이 코드가 올바른지 얼마나 빨리 알 수 있는가? 생성과 검증 사이의 피드백 루프가 얼마나 타이트한가? 그 루프가 모든 것을 결정한다. 모델이 자신의 출력을 스스로…
AI 코드 거버넌스는 주니어 개발자와 AI 에이전트에게서 도구를 빼앗는 것이 아닙니다. 부수적 피해 없이 모든 사격이 목표물에 맞도록 하는 guardrail을 설치하는 것입니다.
기관총은 이미 모두에게 나눠준 상태다. AdEspresso의 공동 창업자이자 Unkover의 최고 AI 책임자인 Massimo Chieruzzi는 이를 완벽하게 포착했다: "AI는 때때로 당신을 기관총을 든 원숭이처럼 느끼게 한다." 우리도 동의한다. 그리고 그 통찰에서 우리는…
대부분의 팀은 매 커밋마다 전체 뮤테이션 테스트 스위트를 실행하지 않는다. 엔지니어링 팀이 뮤테이션 테스트를 CI에 통합하면서도 빌드 파이프라인을 망가뜨리지 않는 실제 방법을 소개한다.
뮤테이션 테스트 스위트가 4시간이나 걸린다면, 축하한다. 모두가 이미 의심하던 사실을 증명한 셈이다. 당신의 테스트에는 구멍이 있다. 매 푸시마다 CI에서 이걸 돌릴 생각은 하지 마라. 그런 팀은 없다. 문제는 한 커밋당 4시간을 감당할 수 있느냐가 아니다. 테스트는 통과하는데…
모의 데이터베이스 테스트는 SQL 문법은 검증하지만, 행이 크래시나 동시 쓰기, 스키마 불일치에서 살아남는지는 검증하지 않는다. 여기 지속성을 진짜로 테스트하는 방법이 있다.
테스트에서 데이터베이스를 모킹하면, 리포지토리 레이어가 올바른 메서드를 호출하는지 검증하는 것이다. 데이터가 크래시에서 살아남는지, 고유 제약 조건이 실제로 중복을 차단하는지, 또는 트랜잭션이 실패할 때 롤백되는지는 테스트하지 않는다. 이 차이는 중요하다. 모킹된 는 지시한 대로…
AI 코딩은 어떤 난장판에서도 복구할 수 있는 엘리트 팀에게는 잘 통한다. 그 외 모든 사람은 두려움, 실패한 CI, 중단된 실험만 남는다. 격차는 모델이 아니다.
두 팀이 동일한 AI 모델을 사용하는 모습을 지켜보면, 완전히 다른 두 가지 결과를 목격하게 된다. 첫 번째 팀은 모델에게 화면을 만들라고 지시한다. 출력 결과는 비슷하지만 어딘가 어긋난다. 스타일링은 Figma 파일에서 벗어나 있다. 상태 관리는 건드려서는 안 될 파일까지 건드린다.…
모든 Redux action을 mock하면 테스트가 변경 로그 검증기가 된다. 대신 실제 상태 전환으로 store를 테스트하는 방법.
가 정확한 payload 형태로 호출되었는지 검증하는 테스트를 작성한 적이 있다면, 누군가 상수 이름을 바꿀 때마다 깨지는 테스트를 작성한 것이다. 이건 상태 로직을 테스트하는 게 아니다. 손가락이 올바른 문자열을 입력했는지 테스트하는 것이다. Redux 테스트 튜토리얼은 종종…
대부분의 팀은 AI 코딩을 시도했다가 QA를 통과하지 못하는 코드를 배포하고 포기합니다. 문제는 모델이 아닙니다—AI 출력을 신뢰할 수 있게 만드는 가드레일의 부재입니다.
AI 코딩을 시도하는 대부분의 팀은 같은 궤적을 따릅니다. 처음에는 들떠서 시작합니다. 모델이 몇 분 만에 기능을 생성하고, 팀은 이를 배포합니다. QA가 버그를 발견하고, 팀은 수정본을 배포합니다. QA가 또 다른 버그를 발견하는데, 이번에는 관련이 없어야 할 다른 모듈에서…
Property-based testing의 기본값인 100개 예제는 통계 전략이 아닌 사회적 타협이다. 자신의 신뢰도 요구사항과 CI 예산에 맞는 실행 횟수를 선택하는 방법을 알아보자.
property-based test를 기본값 100개 예제로 실행하고 있다면, 양쪽 모두 최악의 상황을 겪고 있는 것이다. CI는 필요 이상으로 느리고, 여전히 중요한 버그는 놓치고 있다. 이 숫자에 마법 같은 건 없다. Hypothesis를 포함한 대부분의 라이브러리가 100을…
타입 검사, 린트, 아키텍처 규칙은 갖췄다. 하지만 결정론적 체계는 복잡도, 중복, 명명 재앙을 전혀 보지 못한다. 비용 0원인 해결책은 이것이다.
솔직히 말해 보자. 지금 대부분의 AI 코드 생성 과정은 어떻게 생겼는가. Cursor나 Claude Code로 코드를 생성한다. TypeScript 엄격 모드가 타입 불일치를 잡아주니 을 돌린다. 세미콜론 논쟁을 병합 과정에서 하고 싶지 않으니 ESLint를 돌린다. 순환 임포트가…
Example-based testing은 당신이 생각해낸 입력만 커버한다. Property-based testing은 무작위 데이터를 생성하고, invariant를 검증하며, 실패를 최소한의 counterexample로 축소한다.
당신은 함수를 작성했다. 과 로 테스트했다. 통과했다. 배포했다. 한 사용자가 한 개의 원소를 가진 slice를 넘겼다. 당신의 함수는 그것을 무시하고 지나쳤다. 이슈가 열렸다. 당신은 테스트 파일을 응시하며 이렇게 뻔한 것을 어떻게 놓쳤는지 의아해한다. 놓친 이유는…