반응형 소프트웨어품질3 AI를 어디까지 믿을지 설계하는 일 — 무너지는 네 곳 AI 페어 프로그래밍 바이브코딩은 어디서 무너지는가 AI를 어디까지 믿을지 설계하는 일 — 무너지는 네 곳 핵심 요약 바이브코딩의 진짜 기술은 코딩이 아니라 "AI를 어디까지 믿을지 정밀하게 보정하는 것"이다. 프로토타입까진 공짜지만, "동작한다"를 "믿을 수 있다"로 끌어올리는 건 다른 일이다. AI는 국소적 생성(한 함수·한 화면)은 믿어도 되지만, 검증 · 판단 · 기억 · 일관성에선 믿으면 안 된다 — 이 네 곳이 "믿으면 안 되는 지점의 지도"다(각각 따로 깊게 다뤘다). 네 곳의 뿌리는 하나 — 모델의 출력을 무조건 믿은 것. 대응도 하나 — 믿을 수 있는지를 모델 바깥에서 검증하는 .. 2026. 6. 14. AI는 7곳 중 1곳만 고치고 "완료"라고 한다 AI 페어 프로그래밍 AI는 7곳 중 1곳만 고치고 "완료"라고 한다 흩어진 계약을 다루는 법 핵심 요약 변경을 시키면 AI는 눈앞의 한 파일만 고치고 "완료"라고 한다. 컴파일도 되고, 그것이 본 테스트도 통과한다. 며칠 뒤, 건드리지도 않은 곳에서 터진다. 논리적으로 하나인 변경(필드 이름, 기능 제거)이 실제로는 여러 물리적 자리에 흩어져 산다 — 백엔드·프론트 타입·생성된 클라이언트·env 샘플·테스트·이벤트 스키마. 이게 계약(contract)이다. AI의 시야는 국소적이라 repo 전체에 퍼진 계약을 못 본다. 게다가 1곳을 고쳤든 7곳을 고쳤든 같은 자신감으로 "완료"라 한다. 대응 셋: ① 자리를 줄여라(단일 출처·codegen) ② 자리를 세라(계.. 2026. 6. 13. AI가 짠 테스트는 다 통과한다 — 그게 함정이다 AI 페어 프로그래밍 AI가 짠 테스트는 다 통과한다 — 그게 함정이다 AI에게 테스트를 맡길 때 알아야 할 것 핵심 요약 AI에게 "기능 + 테스트"를 시키면 테스트는 거의 항상 초록불로 돌아온다. 그런데 그 초록불은 생각보다 의미가 없다. AI는 "버그를 잡는 테스트"가 아니라 "통과하는 테스트"를 짜는 경향이 있다 — 코드와 테스트를 한 번에 만들면서, 테스트가 코드를 사후에 흉내 내기 때문이다(순환). 게다가 진짜 의존성(DB·외부 서비스)을 가짜(mock)로 갈아끼운다. 그래서 버그는 거의 항상 그 가짜로 치워버린 경계에 산다 — 코드와 실제 시스템이 만나는 자리. 대응 세 가지: ① 테스트를 먼저 쓴다(TDD) — 순환을 끊는다. ② 경계는 진짜로 테스.. 2026. 6. 13. 이전 1 다음 반응형
